Introduction Since the 1990s, information technology has continuously developed and matured. Simultaneously, against the backdrop of increasingly strong economic globalization, the market environment for enterprise competition has undergone fundamental changes. The main characteristics of the market are now primarily driven by customer and enterprise demand creation. Market competition elements include industrial control time, quality, price, service, environment, and product update rates. To enhance enterprise competitiveness, companies must emphasize the organic integration of manufacturing technology with information technology, automation technology, modern management technology, and systems science. MES (Manufacturing Execution System), like Enterprise Resource Planning (ERP), has evolved from a concept to a software platform, a natural product of information technology development. However, currently, many domestic enterprises, especially factory enterprises, do not attach as much importance to MES as they do to ERP. In fact, applying MES in factory-type enterprises can not only rapidly improve their market competitiveness but also quickly generate returns on their existing information network investments. 1. MES Architecture Design MES occupies a pivotal position in the entire enterprise's information system, serving as the interface for obtaining real-time production information. As shown in Figure 1, 1.1 Traditional MES: In my country, most existing MES systems are single application systems designed for a specific field or work environment. These MES systems have poor versatility and are often suitable for continuous production enterprises, provided that the enterprise's production management is highly sophisticated and the production line is extremely efficient. Currently, most enterprises in my country, especially state-owned enterprises, are discrete production enterprises without automated production lines. Therefore, this type of MES is not suitable for widespread adoption in my country, and it also cannot adapt to changing market demands. 1.2 Current Status of MES Usage in my country: Currently, there is no domestically developed, mature MES software applicable to multiple production types. Most MES systems are designed for continuous production enterprises. Companies that have successfully implemented this type of MES include Guangzhou Honda, TCL, NUFO China, and Hangzhou Silan Integrated Circuit Co., Ltd. However, due to the imperfect management of most Chinese enterprises, many successful companies currently use imported MES systems, which are expensive. Implementing MES in a company typically costs at least several million yuan, and sometimes even tens of millions, and these costs only cover the software portion of the MES. Many enterprises struggle to afford the high costs of MES development. Furthermore, overseas MES systems are designed for companies with advanced manufacturing technologies and extensive production experience, and may not be suitable for domestic enterprises. Implementation often requires modifications, further lengthening the implementation cycle. Therefore, reducing MES development costs and increasing its flexibility to make it applicable to most discrete manufacturing enterprises in my country with relatively outdated production methods is a pressing issue for MES implementation in the country. 1.3 Service Program-Supported MES Service program-supported MES inherits the advantages of modular MES, with the service program serving as the core of the entire MES system. It acts as a bridge connecting data acquisition, submission, processing, and storage within the MES system. It can also handle production planning, sequencing, issuance (automatic and manual), pausing, resuming, inserting, and canceling—almost all operations related to production plan execution can be completed through the service program. As shown in Figure 2, the service program in the entire MES system connects the lower-level data acquisition module and the upper-level management module, and provides extended interfaces with other systems or devices. Adopting a service program architecture, it can connect the various discrete processing points that the product passes through during production, making the MES server the processing information processing center for each discrete processing point. Within the enterprise, to ensure system stability and security, reduce development costs, and improve the utilization of existing information networks, the upper-level design of the MES system should adopt a three-tier C/S architecture. In this way, the service program can serve as the middle layer of this three-tier C/S MES structure, and can integrate some business rules, data access, and validity checks into the service program. 2. Specific Design of the MES Service Program Based on the above MES concept, we designed a service program-supported MES, the basic architecture of which is shown in Figure 2. The service program is the core of this MES system, and its specific design and discussion are as follows: 2.1 Communication Protocol Design In this MES system, the service program needs to communicate with the lower-level communication module and the upper-level management module. The first consideration is the selection of the communication protocol. In computer-to-computer network communication, we use the TCP/IP protocol commonly used in local area networks. The selection of this protocol is mainly related to the hardware network environment established by the MES system. Besides the choice of the network hardware layer protocol, a request-response protocol also needs to be designed at the software layer. Many software developers believe that a unified request-response protocol should be used when the program communicates with different modules, and these programs should be placed in the same program file. Although this design approach helps reduce the program development cycle, it increases the difficulty of later software maintenance, especially when porting some MES modules, which may even cause protocol confusion and lead to porting failure. Therefore, when designing the request-response protocol of the MES service program, we place the protocols and programs for communicating with different modules in independent files to improve the efficiency of the service program's communication with other MES modules, as well as the readability and maintainability of this part of the code. For example, when communicating with the underlying communication module, the format can be: CMDFlag + Request Command Type + CMDSplit + Message 1 + DataSplit + Message 2 + DataSplit + ... + Message n + Data0ver. Here, CMDFlag is the start separator for the command type requested by the communication module from the service program, MDSplit is the end separator for the request command type and also indicates the beginning of the specific information within the request command. Specific information within the request command is separated by DataSplit, and the request command ends with Data0ver. Corresponding response protocols or request/response protocols for communication between other MES modules and the service program can also be formulated in a similar format. It is important to note that in the specific program design, the uniqueness of the command type must be maintained to avoid ambiguity when the system interprets the command type. Furthermore, the program must have a certain degree of fault tolerance when interpreting the protocol. 2.2 Service Program Initialization Design For a service-based MES to function properly, the service program must be initialized before operation. Service program initialization includes establishing a correct and reliable connection with the database, analyzing recent production data, determining the latest production parameters, updating the production plan queue, daily plan queue, material queue, operator queue, equipment queue, and refreshing the database. Its main purpose is to set up various elements involved in the production process in computer memory, maintaining synchronization between memory data and database data to correctly and effectively guide production. When designing the program, we can use dynamic queues and the concept of classes to organize production data, and we can use queue nesting and pointers to improve data utilization. When designing queues and classes, we must include all the production elements managed by the service program, and clarify the relationships between these elements. For example, the equipment queue MachList consists of multiple instantiated equipment classes MachTem?, and different equipment may be able to process different sets of operations. Therefore, each instantiated equipment class needs a queue Can-ProcList of the sets of operations it can process, which requires the use of queue nesting techniques. These situations are common in actual factory production. From a programming perspective, the essence of service program initialization is to assign initial values ​​to each queue and instantiated class, creating the foundation for subsequent production. 2.3 Key Points of Service Program Design The continuity and rationality of factory production depend on the normal operation of MES, which in turn depends on the normal operation of service programs. Improving the operating efficiency of service programs is to improve the operating efficiency of MES, which in turn improves the production efficiency of the factory. Service programs undertake tasks including production scheduling, production data storage, and quality data processing. The amount of data involved in processing these tasks is often very large. Therefore, in program design, it is necessary to improve the utilization rate of data in memory, minimize program disk operations, and reduce data exchange with the database server. 1) Independence of system parameter configuration: Many program designers directly put the system configuration in the program. Although this improves the system integration and saves users from configuring the system before using it, it reduces the system's portability. To improve the portability of the service program, system configurations and parameter settings are stored independently in an INI file. When the database server is moved to another location or the configuration of other modules of the MES changes, only the INI file needs to be modified, without modifying the source code of the service program. Sensitive configurations in the INI file, such as passwords and database locations, can be secured through various encryption measures. 2) Make good use of the concept of "pool": In actual production processes, discrete manufacturing processes generally encounter the following practical problems that cause backlog of pending plans for a certain process: 1. The time required for the same production plan at different process stages will not be the same. 2. The time consumed by different plans in the same process will also not be the same. 3. Different plans may have different processes but have overlapping processes. The above three points are the main reasons for the backlog of pending plans for a certain process. In addition, some factors such as equipment maintenance, worker leave, power outages, and worker skill levels also contribute to the backlog. While typical factory production can be addressed by adding equipment and workers, the problem lies in the constantly changing nature of inventory buildup, making it difficult to determine the exact number of additional equipment and workers needed. Therefore, the service program utilizes the concept of "other" to solve this problem. Specifically, a queue of planned work processes is designed for each process. This queue has two data interfaces: Input and Output (hereinafter, Input refers to the input interface, and Output refers to the output interface). This queue is the so-called "other," which can be called the "pool of planned work processes to be assigned." The input interface is the previous process, and the output interface is the current process. The data structure recorded in this queue includes at least the planned task's production attributes, process, and priority. Completed planned tasks from the previous process are placed into the corresponding pool of planned work processes from the Input interface according to their process. The priority of each planned task can be calculated based on the customer importance, delivery date, and batch size of the order to which the planned task belongs. When a terminal in the current process requests a plan, the service program will distribute the plan from the pool of planned work processes to the requesting terminal through the Output interface, based on the priority of the task and the processing attributes of the equipment corresponding to the requesting terminal. Furthermore, the total working hours required for each pending work plan in the pool of work plans can be dynamically calculated. This allows relevant personnel to easily calculate how to allocate production resources such as equipment and workers. 3) Priority Scheduling: In assembly line production, the processing sequence of products with different tasks within the line is scheduled according to the planned production order, making it relatively simple to handle. However, in discrete manufacturing, the arrival time and order of processed products from different tasks at the same work process do not entirely depend on the planned production order, but also on the planned production process and various related production factors. Thus, in discrete manufacturing, the biggest challenge and focus of service program design lies in the automatic scheduling of production plans, i.e., when to issue which work plan to which equipment terminal. Calculating the production plan priority is not too difficult; it can be calculated based on pre-given priority rules. However, if several pending work plans of the same priority exist, the problem of plan selection needs to be solved. Random Service (RS): This involves randomly issuing a pending work plan to the appropriate requesting terminal from several pending work plans of the same priority. Its advantage is that it is very easy to implement, and therefore it is used in many situations. However, it doesn't utilize the processing history of the equipment corresponding to the requesting terminal and lacks a subjective control interface. First-Come, First-Served (FCFS): This means that among the pending plans with the same priority, the plan added first to the queue is processed first. This scheduling method considers the factors of previous processes and reflects the urgency of the task to some extent, making it more scientific than the RS algorithm. However, it doesn't consider the processing history of the equipment in the current process, potentially increasing auxiliary time. The priority scheduling strategy of the service program considers how to reduce the auxiliary time of product processing. It adds consideration of the processing history of the equipment in the current process to FCFS, called the Optimized First-Come, First-Served (OFCFS) algorithm. This algorithm pre-scans the queue of pending plans. The pre-scan calculates whether there is a task in the queue that is the same as the last processing of the current process. If not, it calculates whether there is a pending plan task with the same parameters or within the same range as the last processing of the current process. If not, it continues to calculate other pending plans that can reduce auxiliary time. If a suitable pending plan is calculated in a certain process of the pre-scan, it immediately returns to that pending plan and ends the pre-scan. If no relevant pending plans are found, the FCFS algorithm is used for scheduling. Although this algorithm may perform multiple scans of the allocation plan during pre-scanning, considering that there are usually only a few plans of the same priority, the time spent on pre-scanning is negligible. 4) Synchronous modification of memory and database data: The service program is designed with data processing in mind, reasonably distributing data operations to the database server and the service program itself. Even so, it is difficult to meet the requirements of processing large amounts of real-time production data in factory production. No system can process multiple requests simultaneously, but the system must respond within the allowed waiting time of the request. This determines that the service program cannot frequently call the database to refresh the queues of various production elements in memory. One solution is to modify the corresponding values ​​in memory immediately while modifying the database. This avoids reading a large amount of database data at a certain time while ensuring the real-time performance of the service program's data. Transaction processing is also added to increase data security. As long as the factory is in production, the MES must operate continuously. As long as the MES is operating, the service program must run continuously. This means that the service program must accompany the MES throughout its operation. To ensure the continuity and accuracy of factory production, the service program must still be able to issue the correct production plan instructions when production data is incorrect. Therefore, when data deviations occur during the production process, erroneous data must be corrected. The service program provides online refresh and manual correction. 3. Operation Status Based on the above-mentioned design principles, the service program supporting the MES has been applied in actual discrete manufacturing enterprises. The relevant design information and operation status of the service program are as follows: System Structure: Three-tier Client/Serve; Development Tools: Windows 2000 Professional, Borland Delphi 6.0 Enterprise, Microsoft SQL 2000 Professional; Implementation Location: Huaiji Auto Parts Manufacturing Co., Ltd., Huaiji County, Zhaoqing City, Guangdong Province; Operating Environment: Windows 2000 Server; The following are the performance statistics of the service program: Table 1 summarizes the overall performance of the system up to June 2005. The statistics show that the MES supported by this service program has extremely high reliability, with a planned false trigger rate of less than 0.001%. The response time for terminal requests is less than 2 seconds under normal conditions and less than 4 seconds under peak conditions. Such response times are acceptable to most workshop production. It is worth noting that 90% of the terminal response time of this MES is due to network communication. To improve response time, one can start by improving the network. Fiber optic networks are currently the most ideal communication network; theoretically, if fiber optics are used as the communication network, the response time can be less than 0.5 seconds. 4. Conclusion This paper formally presents a design method for a service program supporting MES and applies this system to actual production. Tests show that the MES supported by the service program, compared with MES systems currently on the market, possesses the same adaptability, flexibility, real-time performance, and reliability, while also exhibiting extremely high planning and processing efficiency. This is due to the fact that the service program can run independently of other MES modules on a dedicated server, greatly reducing the system's operational burden and making the MES system more secure, ensuring that module upgrades do not adversely affect other modules. Because this MES can fully utilize the enterprise's existing network equipment, and the core service program is reusable, it significantly shortens the development cycle and effectively reduces development and implementation costs when developing MES systems for other enterprises. This paper also summarizes the implementation of the service program-supported MES system design scheme at Guangdong Huaiji Auto Parts Manufacturing Co., Ltd., achieving good results.