A high-availability MCS cluster system supporting SECS protocol

Abstract

The application relates to the technical field of communication, in particular to a high-availability MCS cluster system supporting an SECS protocol, which comprises an ORACLE database cluster, an MQ cluster, a plurality of MCS servers and a plurality of MCS drivers, the MCS servers and the MCS drivers communicate through the MQ cluster, the ORACLE database cluster realizes data sharing of each application node, and a database service layer is built by adopting an ORACLE RAC mode; the application has clear architecture and strong adaptability, can flexibly assemble the MCS servers and the MCS drivers to adapt to other external control systems or device systems, and can be multi-dimensionally expanded horizontally according to the busy degree of FAB logistics conveying, is easy to construct and convenient to manage; the MCS message processing application and the device communication protocol are fully decoupled, the stable production of the FAB environment can be guaranteed to the maximum extent, the system development platform is above.NET5, is cross-platform compatible, supports the deployment of LINUX and WINDOW platforms, and the node instances required to be deployed are consistent under various scenes and platforms.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of communication technology, and in particular to a high-availability MCS cluster system supporting SECS protocol. BACKGROUND

[0002] In the process of semiconductor wafer production, the MCS system is responsible for the logistics scheduling of FOUP, and the STOCKERC, OHTC, LIFTC, AGVC, and other logistics-related equipment controllers usually use the SECS / GEM protocol to communicate with the MCS host. Figure 1 is a schematic diagram of a prior art MCS cluster system supporting driveless nodes, Figure 1 As can be seen in the prior art, the SECS communication mechanism and message processing logic are in the same application, and in the absence of an MCS SECS driver, the LINK-TEST method is used to implement failover and version replacement reconnection with the equipment. Under this architecture, when updating the application, the MCS NODE 410 needs to be closed for program updates, at which time the equipment connected to the MCS NODE 410 will be disconnected from the host, the MCS NODE 420 will change the SECS communication state of the disconnected equipment to ACTIVE state and reconnect, and the equipment online process will be executed, requiring a short pause in the equipment running state to accurately synchronize the on-site handling business information. When updating the program application of the MCS NODE 420, the above process needs to be repeated, and all devices will go through a process of disconnection and then reconnection, and after reconnection, all running devices need to pause the business, which has a significant impact on semiconductor wafer production.

[0003] In addition, it is relatively difficult to achieve load balancing of business processing in the traditional MCS system architecture. The MCS node that performs LINK-TEST with the equipment uses a competitive mechanism to establish a connection with the equipment, and the MCS node that successfully LINK-TESTs first monopolizes the connection with the equipment. This method is difficult to achieve an average connection of each device to multiple MCS applications, and is a system architecture between ACTIVE-STANDBY and ACTIVE-ACTIVE.

[0004] In the existing wafer production system, the MCS needs to face multiple handling equipment and diverse system architectures. When the device system architecture is in ACTIVE-STANDBY mode and no unique VIP is provided, the MCS may need to face multiple IPs exposed by the device. In summary, the traditional MCS system architecture cannot flexibly associate with the device system, cannot meet the flexible docking requirements, and cannot meet the stable production requirements. SUMMARY

[0005] The technical problem to be solved by the present invention is: to provide an MCS message processing application that is fully decoupled from the device communication protocol, so that the message processing can be relocated and the fault transfer can be performed when the MCS service fails due to factors such as server failure; the application can be patched and updated while maintaining the on-site transportation business service to achieve seamless version replacement; the use of SECS / GEM protocol for RPC remote process control of the equipment is supported; the architecture is clear and adaptable, and the MCS message processing application and the MCS device driver application can be flexibly assembled to adapt to other external control systems or equipment systems, and according to the busyness of FAB logistics transportation, the system can be multi-dimensionally expanded horizontally, and is easy to build and manage. A high-availability MCS cluster system that supports the SECS protocol.

[0006] To solve the above technical problems, the technical solution of the present invention is: a high-availability MCS cluster system that supports the SECS protocol, including an ORACLE database cluster, an MQ cluster, multiple MCS servers and multiple MCS drivers. The MCS servers communicate with the MCS drivers through the MQ cluster. The ORACLE database cluster realizes data sharing among various application nodes, and the database service layer is built using the ORACLE RAC model.

[0007] As a preferred technical solution, the ORACLE database cluster includes multiple database servers and shared storage, the MCS SERVER is a message processing program module, and the MCS DRIVER is a device communication driver module.

[0008] As a preferred technical solution, both the MCS SERVER and the MCS DRIVER can be horizontally expanded to deploy multiple production servers, and the MCS SERVER and the MCS DRIVER are customized and adjusted according to the ratio of m:n (m>1, n>1).

[0009] As a preferred technical solution, during the system development phase, the MCSDRIVER corresponding to devices with relatively stable interfaces is centrally deployed, and the MCS DRIVER corresponding to devices with variable interfaces is independently deployed. When the system version is updated, only the MCS DRIVER and the MCS SERVER corresponding to devices with variable interfaces are updated to avoid repeated updates of the MCS DRIVER of devices with relatively stable interfaces.

[0010] As a preferred technical solution, the development platform of the MCS cluster system is .NET5 or above, which is cross-platform compatible and supports deployment on LINUX and WINDOW platforms.

[0011] As a preferred technical solution, the MCS SERVER is written using an ASP.NET BLAZOR SERVER, the MCS DRIVER communicates with the equipment through a SECS / GEM communication protocol, multiple MCS DRIVERS are started and simultaneously request LINK-TEST to the equipment, the MCS DRIVER that successfully requests is successfully connected to the equipment, is in an ACTIVE state, and reports an equipment online event to the MCS SERVER, and the other MCS DRIVERS continue to intermittently request LINK-TEST to the equipment, but in essence are not connected to the equipment and do not send SECS messages, and are in a STANDBY state.

[0012] As a preferred technical solution, each MCS DRIVER can be connected to multiple equipment through SECS, in the scenario of starting multiple MCS DRIVERS, 0 to all of the SECS connections in each MCS DRIVER are always in an ACTIVE state, when the ACTIVE state SECS connection MCS DRIVER is actively closed or abnormally crashes, or the deployed server abnormally crashes, or the equipment is disconnected and reconnected, a certain MCS DRIVER in a STANDBY state successfully LINK-TESTs with the equipment, changes to an ACTIVE state, and reports an equipment online message to the MCS SERVER.

[0013] As a preferred technical solution, the MCS DRIVER is written using an ASP.NET BLAZOR SERVER, and the transport business logic of the MCS is integrated, responds to transport request tasks in a production environment, can send transport instructions and other remote control instructions to the transport equipment, tracks equipment states, alarm information, and the like, the MCS SERVER is designed according to a load balancing mechanism, and messages reported by the equipment are randomly distributed to any MCS SERVER for message processing through the MQ cluster.

[0014] As a preferred technical solution, the message interface of the MCS SERVER is uniformly in a JSON format.

[0015] As a preferred technical solution, the MQ cluster is constructed using open source message broker software Rabbit MQ, multiple Rabbit MQ nodes use a mirror cluster mode to achieve high availability of the MQ cluster, and the MQ cluster uses an RPC mode when constructing a message queue, and supports RPC interface calls of MCS SERVER->MCS DRIVER->equipment or equipment->MCS DRIVER->MCS SERVER.

[0016] Due to the adoption of the above technical scheme, the high-availability MCS cluster system supporting the SECS protocol comprises an ORACLE database cluster, an MQ cluster, a plurality of MCS SERVERs and a plurality of MCS DRIVERS, the MCS SERVERs and the MCS DRIVERS communicate through the MQ cluster, the ORACLE database cluster realizes data sharing of each application node, and the database service layer is built by using the ORACLE RAC mode; the MCS cluster system provided by the application is stable, reliable, high-availability, and can realize seamless version switching; when the MCS service is invalid due to server failure and other factors, the message processing can be relocated, and the fault transfer can be performed; the application can be updated by patches while the business service is carried out on site, and seamless version switching is realized; the SECS protocol is supported to control the equipment by RPC remote process control.

[0017] The application has clear architecture, strong adaptability, and can flexibly assemble MCS SERVERs and MCS DRIVERS to adapt to other external control systems or equipment systems, and according to the busy degree of FAB logistics carrying, the system can be expanded in multiple dimensions, is easy to construct, and is convenient to manage; when the carrying business is heavy and the system performance is limited, the MCS SERVERs and the MCS DRIVERS can be expanded in the horizontal direction, a plurality of production servers are deployed, and a plurality of MCS SERVERs and MCS DRIVERS are installed. The MCS SERVERs and the MCS DRIVERS can be flexibly combined, and are self-defined according to the ratio of m:n (m>1, n>1), so that the upper limit of system performance is broken through.

[0018] The system architecture of the application is clear, the MCS message processing application and the device communication protocol are fully decoupled, even if the communication mode of the device and the MCS SERVER is not the SECS / GEM protocol, the developer only needs to develop the corresponding MCS device driver of the communication protocol, transform the device message, and adapt the general JSON format message required by the MCS SERVER, without modifying the business logic of the MCS SERVER, so that the MCS cluster system can be quickly landed in the FAB environment of the device and the interfacing system existing in a variety of communication protocols, while ensuring that the subjectivity of the carrying business logic is not eroded.

[0019] In addition, during the system development stage, when part of the device interface is relatively stable, and the other part of the device is still in the business discussion stage, the stable interface device MCS DRIVER can be deployed, and the interface variable device corresponding MCS DRIVER is independently deployed. When the system version is updated, only the interface variable MCS DRIVER and MCS SERVER are updated, avoiding the problem of repeatedly updating the stable device MCS DRIVER, causing the device to be reconnected for initialization and production suspension. Under this fine operation, the stable production of the FAB environment can be guaranteed to the greatest extent. The system development platform is.NET5 or later, cross-platform compatible, supporting LINUX and WINDOW platform deployment, and the node instance needs to be deployed consistently in each scene and platform. Normally, no other middleware needs to be installed. BRIEF DESCRIPTION OF DRAWINGS

[0020] The following drawings are merely intended to schematically illustrate and explain the present application, and do not limit the scope of the present application. Among them:

[0021] Figure 1 is a schematic diagram of an MCS cluster system architecture supporting driverless nodes in the prior art;

[0022] Figure 2 is a schematic diagram of an MCS high-availability cluster system architecture supporting SECS protocol in the embodiment of the present application;

[0023] Figure 3 is a schematic diagram of a MCS cluster system variant architecture without unique IP in the master-slave docking system in the second embodiment of the present application;

[0024] Figure 4 is a schematic diagram of device->MCS host data flow and message queue construction in the third embodiment of the present application;

[0025] Figure 5 is a schematic diagram of MCS host->device data flow and message queue construction in the fourth embodiment of the present application;

[0026] Figure 6 is a schematic diagram of a complete MCS cluster system containing a client and an MES upper system in the present application. DETAILED DESCRIPTION

[0027] The present application will be further described below in conjunction with the drawings and embodiments. In the following detailed description, only certain exemplary embodiments of the present application are described by way of illustration. It is self-evident that those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present application. Therefore, the drawings and description are illustrative in nature and are not intended to limit the scope of the claims.

[0028] Embodiment one: as shown, the basic architecture diagram of the high-availability MCS cluster system supporting the semiconductor industry SECS / GEM communication protocol is shown, the necessary elements include ORACLE database cluster, MQ cluster, MCS SERVER cluster (message processing program module), MCS DRIVER cluster (device communication driver module), and the support platform includes WINDOWS and LINUX. The ORACLE database cluster in this embodiment includes ORACLE RAC and shared storage 240, the MQ cluster is built using open source message broker software Rabbit MQ, and multiple Rabbit MQ nodes are used in mirror cluster mode to realize high availability of the MQ cluster node; the MCS SERVER cluster includes MCS SERVER 110 and MCS SERVER 120, and the MCS DRIVER cluster includes MCS DRIVER 130 and MCS DRIVER 140. Figure 2

[0029] The SECS / GEM communication protocol is widely used in the semiconductor industry and specifies that various suppliers' devices use consistent standards and protocols to communicate with the host system. The standard defines device state data collection, tracking data collection, alarm collection, remote command, and other functions.

[0030] In the present application, the MCS DRIVER instance is written by ASP.NET BLAZOR SERVER, the MCS DRIVER 130 and the MCS DRIVER 140 communicate with the device through the SECS protocol, multiple MCS DRIVERS are started at the same time to request LINK-TEST from the device, the MCS DRIVER that successfully requests is connected to the device and is in the ACTIVE state, and reports the device online event to the MCS SERVER. Other MCS DRIVERS continue to perform intermittent LINK-TEST requests with the device, but in essence are not connected to the device and do not send SECS messages, and are in the STANDBY state.

[0031] Each MCS DRIVER can perform SECS connection with multiple devices, in the scenario of starting multiple MCS DRIVERS, 0 to all SECS connections in each MCS DRIVER should be in the ACTIVE state. When the ACTIVE state SECS connection MCS DRIVER is actively closed, or the MCS DRIVER abnormally crashes, or the deployed server abnormally crashes, or the device is disconnected and reconnected, a certain MCS DRIVER in the STANDBY state successfully performs LINK-TEST with the device and changes to the ACTIVE state, and reports the MCS SERVER device online message.​

[0032] The MCS Server instance, also written using ASP.NET Blazor Server, integrates the MCS transport business logic, responds to transport requests from the production environment, sends remote control commands such as transport instructions to transport equipment, and tracks equipment status, alarms, and other information. MCS Server 110 and MCS Server 120 are designed with a load balancing mechanism. Messages reported by devices are randomly distributed to MCS Server 110 or MCS Server 120 for processing via the MQ cluster. Whether reporting messages from the MCS Driver or invoking external system interfaces like MES, the MCS Server message interface uses a unified JSON format.

[0033] The MCS server and MCS driver communicate through an MQ cluster. Because SECS defines the valid direction of messages, some messages can be bidirectional, enabling RPC remote process control of devices. Therefore, the corresponding MQ cluster also adopts the RPC model when building message queues, supporting RPC interface calls from server to driver to device, or device to driver to server. Message delivery can be configured to require a reply. Messages that do not require a reply are delivered only to the message queue and do not wait for a reply from the MCS server or device, optimizing system message forwarding efficiency.

[0034] Example 2: Figure 3 As shown, the system architecture provided by the present invention can flexibly adjust the relationship between MCS drivers and device systems to meet docking requirements. Two groups of MCS drivers are run simultaneously: MCS driver 730 and MCSDRIVER 770 connect to the device's master system, and MCS driver 740 and MCS driver 780 connect to the device's slave system. When the device's master system fails, MCS drivers 740 and 780 connect to device system IP2, which has changed to master status. When the server deployed by MCS driver group 2 fails, MCS driver 730 connects to IP1 of the device's master system. System failover can be achieved when different nodes fail, achieving the high availability goal of the MCS driver. The MCS application logic remains unchanged; only the MCS driver configuration method is adjusted. This eliminates the need for intervention from system development staff and offers high scalability and maintainability.

[0035] When the handling business is heavy and system performance is limited, both the MCS Server and MCS Driver can be expanded horizontally to deploy multiple production servers and install multiple MCS Servers and MCS Drivers. The MCS Server and MCS Driver can be flexibly combined and customized according to the ratio of m:n (m>1,n>1) to break through the system performance limit. In addition, during the system development phase, when some equipment interfaces are relatively stable and other equipment is still in the business exploration phase, the MCS Drivers for devices with stable interfaces can be deployed centrally, and the MCS Drivers corresponding to devices with volatile interfaces can be deployed independently. When the system version is updated, only the MCS Driver and MCS Server with volatile interfaces are updated to avoid repeated updates of the MCS Driver for stable equipment, which may cause equipment reconnection for initialization and production suspension. With this refined operation, stable production in the FAB environment can be guaranteed to the greatest extent. In addition, the development platform of this system is .NET5 or above, which is cross-platform compatible and supports deployment on LINUX and WINDOW platforms. The node instances that need to be deployed are consistent in various scenarios and platforms, all of which are ORACLE database clusters, MQ clusters, multiple MCS SERVERs and multiple MCS DRIVERs. Normally, no other middleware needs to be installed.

[0036] Example 3: Figure 4 As shown, Figure 4 There are two MCS SERVER nodes, namely MCS SERVER 830 and MCS SERVER 840, and two MCS DRIVER nodes, namely MCS SERVER 850 and MCS SERVER 860. Taking a device 870 that supports the SECS protocol as an example, a data loop diagram is shown in which the device reports a message and the MCS SERVER needs to provide feedback on the reported message.

[0037] When the MCS driver starts, MCS driver 850 establishes a SECS connection with the device and is in the ACTIVE state. MCS driver 860 is in the STANDBY state. When the MCS driver successfully connects to the device, it declares the MQ queue REQUEST QUEUE 810 to which the device's report message needs to be delivered, and the MQ queue REPLYQUEUE 820 to which the MCS server's response message should be delivered.

[0038] MQ queue REQUEST QUEUE 810 is not exclusive and not auto-deleted when there is no consumer (EXCLUSIVE: FALSE, AUTO-DELETE: FALSE), and MQ queue REPLY QUEUE 820 is an anonymous queue automatically generated when the MCS DRIVER is connected with the device, is exclusively used by each MCS DRIVER, and is automatically deleted when there is no consumer (ANONYMOUS, EXCLUSIVE: TRUE, AUTO-DELETE: TRUE).

[0039] After being started, the MCS SERVER 830 and the MCS SERVER 840 automatically subscribe to the MQ queue REQUEST QUEUE 810 (E->H) for reporting messages of the MCS DRIVER. The SECS message reported by the device 870 is translated into a JSON format message by the MCS DRIVER 850 and is delivered to the MQ queue REQUEST QUEUE 810, and is randomly distributed to the consumer MCS SERVER 830 or the MCS SERVER 840 for business processing. After being processed by the MCS SERVER, the feedback result is replied to the MQ queue REPLY QUEUE 820. The MCS DRIVER 850 is a consumer of the MQ queue REPLY QUEUE 820, and after receiving the feedback message, the MCS DRIVER 850 translates the feedback message into a SECS message and replies to the device 870, thereby completing the closed-loop data circuit of the device reporting message and the feedback of the MCS system to the device.

[0040] When the MCS SERVER 830 node fails, the message reported by the device is processed by the MCS SERVER 840 and is replied to the MCS DRIVER, thereby achieving the effect of the failover of the MCS SERVER node. When the MCS DRIVER 850 node fails, the consumer of the anonymous exclusive MQ queue REPLY QUEUE 820 is lost, and the message queue is automatically deleted. The MCS DRIVER 860 node is successfully reconnected with the device LINK-TEST, is changed to the ACTIVE state, and declares a new anonymous exclusive queue to replace the original MQ queue REPLY QUEUE 820 node, for receiving the feedback message of the MCS SERVER. After the MCS DRIVER node switching process is completed, the message reported by the device is normally processed according to the above process, thereby realizing the failover of the MCS DRIVER node in the device reporting message scenario.

[0041] Embodiment Four: as Figure 5As shown, there are two MCS SERVER 910 and MCS SERVER 920 nodes and two MCS DRIVER 960 and MCS DRIVER 970 nodes in the system, and a SECS protocol supported device 980 is taken as an example to show the data loop diagram in which the MCS SERVER initiatively sends remote process control instructions to the device and the device needs to feed back data. When the MCS DRIVER is started, the MCS DIRVER 960 creates a SECS connection with the device in an ACTIVE state, and the MCS DIRVER 970 is on standby in a STANDBY state. When the MCS SERVER 910 and the MCS SERVER 920 nodes are started, a REQUEST QUEUE 930 is declared, and a reply MQ queue H->E request message is declared respectively as a REPLY QUEUE 950 and a REPLY QUEUE 940.

[0042] The REQUEST QUEUE 930 is shared by the MCS SERVER 910 and the MCS SERVER 920, and is used for sending the RPC request message of the MCS SERVER, and is not automatically deleted when there is no consumer (EXCLUSIVE: FALSE, AUTO-DELETE: FALSE). The REPLY QUEUE 950 and the REPLY QUEUE 940 are anonymous queues automatically generated when the SERVER is started, and are exclusively used by each MCS SERVER, and are used for ensuring the safety of the data loop and are automatically deleted when there is no consumer (ANONYMOUS, EXCLUSIVE: TRUE, AUTO-DELETE: TRUE).

[0043] When the MCS SERVER 910 node fails, the corresponding reply message queue REPLY QUEUE 950 is automatically deleted, and the MCS SERVER 920 continues to work normally according to the above mode, and the function of sending remote process control instructions to the device by the host is not affected. When the MCS DRIVER 960 fails, the MCS DRIVER 970 LINK-TEST is successful, and subscribes to the request message REQUEST QUEUE 930 of H->E, undertakes the function of device message request, and realizes the high availability of the system.

[0044] Figure 6 is a complete MCS cluster system diagram of the application comprising a client and an MES upper system. As can be seen from the above embodiment, the MCS cluster system in the application relies on a database cluster to realize data sharing of each application node, and an ORACLE RAC mode is adopted to build Figure 1The database service layer shown in the middle comprises 610-640 nodes. If the production environment is less busy, the conveying equipment is less, and the data volume is small, open source MySQL combined with KeepAlive mode can be used to build high-availability database nodes to reduce costs.

[0045] The present application provides a practical way to build a stable and reliable MCS cluster system with high availability and seamless version switching. When the MCS service is disabled due to server failure and other factors, the message processing can be relocated and failover can be performed. The application can be patched and updated while maintaining the on-site business service, enabling seamless version switching. The SECS protocol can be used to support RPC remote process control of the device.

[0046] The present application has a clear architecture and strong adaptability, and can flexibly assemble MCS SERVER and MCS DRIVER to adapt to other external control systems or device systems. According to the busy degree of FAB logistics transportation, the system can be expanded in multiple dimensions, making it easy to build and manage. When the conveying business is heavy and the system performance is limited, both MCS SERVER and MCS DRIVER can be expanded horizontally, deploying multiple production servers and installing multiple MCS SERVER and MCS DRIVER. MCS SERVER and MCS DRIVER can be flexibly combined and customized according to the ratio of m:n (m>1, n>1), breaking through the upper limit of system performance.

[0047] The system architecture of the present application is clear, and the MCS message processing application and the device communication protocol are fully decoupled. Even if the communication method between the device and the MCS SERVER is not the SECS / GEM protocol, the developer only needs to develop the corresponding MCS device driver for the communication protocol, convert the device message, and adapt the general JSON format message required by the MCS SERVER. The business logic of the MCS SERVER does not need to be modified, so that the MCS cluster system can be quickly deployed in a FAB environment with multiple communication protocols and interfaced systems, while ensuring that the main body of the conveying business logic is not eroded.

[0048] In addition, during the system development stage, when part of the device interface is relatively stable, and the other part of the device is still in the business discussion stage, the stable interface device MCS DRIVER can be deployed centrally, and the interface variable device corresponding MCS DRIVER is deployed independently. When the system version is updated, only the interface variable MCS DRIVER and MCS SERVER are updated, avoiding the problem of repeated updating of stable device MCS DRIVER, causing the device to be reconnected for initialization and production to be suspended. Under this fine operation, the stable production of the FAB environment can be guaranteed to the greatest extent. The system development platform is.NET5 or later, cross-platform compatible, supporting LINUX and WINDOW platform deployment, and the node instances that need to be deployed are consistent in each scene and platform, and normally do not need to install other middleware.

[0049] The above shows and describes the basic principles, main features and advantages of the present application. Those skilled in the art should understand that the present application is not limited to the above embodiments, and the above embodiments and descriptions in the specification are only to illustrate the principles of the present application. Without departing from the spirit and scope of the present application, various changes and improvements can be made to the present application, and these changes and improvements all fall within the scope of the claimed present application. The scope of protection of the present application is defined by the appended claims and their equivalents.

Claims

1. A high-availability MCS cluster system supporting the SECS protocol, characterized by: It includes an ORACLE database cluster, an MQ cluster, multiple MCS servers and multiple MCS drivers. The MCS servers communicate with the MCS drivers via the MQ cluster. The ORACLE database cluster enables data sharing among application nodes. The database service layer is built using the ORACLE RAC model. The ORACLE database cluster includes multiple database servers and shared storage, the MCS SERVER is a message processing module, and the MCS DRIVER is a device communication driver module; Both the MCS SERVER and the MCS DRIVER can be expanded horizontally to deploy multiple production servers. The MCS SERVER and the MCS DRIVER can be customized according to the ratio of m:n (m>1, n>1); During the system development phase, the MCS DRIVER corresponding to devices with relatively stable interfaces is centrally deployed, and the MCS DRIVER corresponding to devices with variable interfaces is independently deployed. When the system version is updated, only the MCSDRIVER and the MCS SERVER corresponding to devices with variable interfaces are updated to avoid repeated updates of the MCS DRIVER of devices with relatively stable interfaces. The MCS server is written using ASP.NET BLAZOR SERVER. The MCS driver communicates with the device via the SECS / GEM communication protocol. After startup, multiple MCS drivers simultaneously make LINK-TEST requests to the device. The MCS driver that succeeds in the request successfully connects to the device and is in the ACTIVE state. It also reports the device online event to the MCS server. The other MCS drivers continue to make intermittent LINK-TEST requests to the device, but are not actually connected to the device, do not send SECS messages, and are in the STANDBY state. Each MCS DRIVER can establish SECS connections with multiple devices. When multiple MCS DRIVERs are enabled, 0 to all SECS connections in each MCS DRIVER are always in ACTIVE state. When the MCS DRIVER in ACTIVE state is actively closed or crashes abnormally, or the deployed server is abnormally down, or the device is disconnected and reconnected, one of the MCS DRIVERs in STANDBY state successfully LINK-TESTs with the device, changes to ACTIVE state, and reports the MCS SERVER device online message; The MCS DRIVER is written using ASP.NET BLAZOR SERVER, which integrates the MCS transportation business logic, responds to the transportation request tasks of the production environment, sends transportation instructions and remote control instructions to the transportation equipment, and tracks equipment status and alarm information. The MCS SERVER is designed according to the load balancing mechanism. The messages reported by the equipment are randomly distributed to any of the MCS SERVERs through the MQ cluster for message processing.

2. A high-availability MCS cluster system supporting the SECS protocol according to claim 1, characterized in that: The development platform of the MCS cluster system is .NET5 or above, which is cross-platform compatible and supports deployment on LINUX and WINDOW platforms.

3. The high-availability MCS cluster system supporting the SECS protocol according to claim 1, characterized in that: The MCS SERVER message interface docking format is unified into JSON format.

4. A high-availability MCS cluster system supporting the SECS protocol as claimed in claim 1, characterized in that: The MQ cluster is built using the open source message broker software Rabbit MQ. Multiple Rabbit MQ nodes use a mirror cluster mode to achieve high availability of the MQ cluster. The MQ cluster uses the RPC mode when building the message queue and supports RPC interface calls of MCS SERVER->MCS DRIVER->device or device->MCS DRIVER->MCS SERVER.

Images