CN116192864A - 一种支持secs协议的高可用性mcs集群系统 - Google Patents

Abstract

本发明涉及通信技术领域，尤其涉及一种支持SECS协议的高可用性MCS集群系统，包括ORACLE数据库集群、MQ集群、多个MCSSERVER和多个MCS DRIVER，MCSSERVER与MCSDRIVER通过MQ集群进行通讯，ORACLE数据库集群实现各应用节点的数据共享，采用ORACLERAC模式搭建数据库服务层；本发明架构清晰，适配性强，可以灵活组装MCSSERVER和MCSDRIVER，以适应其他外部控制系统或设备系统，并且根据FAB物流搬送的繁忙程度，系统可以进行多维横向拓展，易于构建，便于管理；MCS消息处理应用与设备通讯协议充分解耦，可以最大程度的保证FAB环境的稳定生产，本系统开发平台为.NET5以上，跨平台兼容，支持LINUX和WINDOW平台的部署，需要部署的节点实例在各场景和平台下具有一致性。

Description

一种支持SECS协议的高可用性MCS集群系统

技术领域

本发明涉及通信技术领域，尤其涉及一种支持SECS协议的高可用性MCS集群系统。

背景技术

在半导体晶圆生产的过程中，MCS系统负责FOUP的物流调度工作，STOCKERC、OHTC、LIFTC、AGVC等物流相关设备控制器通常使用SECS/GEM协议与MCS主机进行通讯。图1是现有技术支持无驱动节点的MCS集群系统示意图，图1中可以看出，现有技术中SECS通讯机制与消息处理逻辑同处于一个应用之中，没有MCS SECS驱动程序的场景下，使用LINK-TEST方式与设备实现故障转移和换版重连。此架构下，在进行应用的更新换版时，需要关闭MCS NODE410进行程序更新，此时与MCS NODE 410连接的设备会与主机断开连接，MCS NODE 420与断开连接的设备SECS通讯状态变更为ACTIVE状态重新连线，执行设备上线流程，需要短时间暂停设备运行状态以准确同步现场搬送业务信息。更新MCS NODE 420程序应用时也需要重复上述流程，所有设备都会经历连接中断然后重新连接的一个过程，并且重连后需要所有正在运行的设备暂停业务，对半导体晶圆生产来说影响颇大。

此外，传统MCS系统架构的方式要实现业务处理的负载均衡相对困难，与设备进行LINK-TEST的MCS节点采用竞争机制与设备建立连接，较先LINK-TEST成功的MCS节点独占与设备的连接。这种方式难以实现各设备平均的连接到多个MCS应用上，是一种介于ACTIVE-STANDBY和ACTIVE-ACTIVE之间的系统架构。

在现有的晶圆生产体系中，MCS需要面对多元的搬送设备以及多样的系统架构，在设备系统架构为ACTIVE-STANDBY模式时，并且没有提供唯一的VIP时，MCS可能需要面对设备暴露的多个IP。综上所述，传统的MCS系统架构不能灵活的和设备系统关联，不能满足灵活对接需求，不能满足稳定生产的需求。

发明内容

本发明所要解决的技术问题是：提供一种MCS消息处理应用与设备通讯协议充分解耦，在服务器故障等因素造成MCS服务失效时可以实现消息处理的重定位，进行故障转移；可以在维护现场搬送业务服务的同时，对应用进行补丁更新，实现无缝换版；支持使用SECS/GEM协议对设备进行RPC远程过程控制；架构清晰，适配性强，可以灵活组装MCS消息处理应用和MCS设备驱动应用，以适应其他外部控制系统或设备系统，并且根据FAB物流搬送的繁忙程度，系统可以进行多维横向拓展，易于构建，便于管理的一种支持SECS协议的高可用性MCS集群系统。

为解决上述技术问题，本发明的技术方案是：一种支持SECS协议的高可用性MCS集群系统，包括ORACLE数据库集群、MQ集群、多个MCS SERVER和多个MCS DRIVER，所述MCSSERVER与所述MCS DRIVER通过所述MQ集群进行通讯，所述ORACLE数据库集群实现各应用节点的数据共享，采用ORACLE RAC模式搭建数据库服务层。

作为优选的技术的方案，所述ORACLE数据库集群包括多台数据库服务器和共享存储，所述MCS SERVER为消息处理程序模块，所述MCS DRIVER为设备通讯驱动模块。

作为优选的技术的方案，所述MCS SERVER和所述MCS DRIVER均可以进行横向拓展，部署多台生产服务器，所述MCS SERVER和所述MCS DRIVER按照m:n(m>1,n>1)的比例进行自定义调整。

作为优选的技术的方案，在系统开发阶段，接口相对稳定设备对应的所述MCSDRIVER集中部署，接口易变设备对应的所述MCS DRIVER独立部署，在系统版本更新时，仅更新接口易变设备对应的所述MCS DRIVER和所述MCS SERVER，避免接口相对稳定设备的所述MCS DRIVER反复更新。

作为优选的技术的方案，所述MCS集群系统的开发平台为.NET5以上，跨平台兼容，支持LINUX和WINDOW平台的部署。

作为优选的技术的方案，所述MCS SERVER是使用ASP.NET BLAZOR SERVER编写的，所述MCS DRIVER与设备通过SECS/GEM通讯协议进行通讯，多台所述MCS DRIVER启动后同时与设备进行LINK-TEST请求，请求成功的所述MCS DRIVER与设备连线成功，处于ACTIVE状态，并向所述MCS SERVER上报设备上线事件，其他所述MCS DRIVER继续与设备进行间歇式的LINK-TEST请求，但实质上并未与设备连线，不会发送SECS消息，处于STANDBY状态。

作为优选的技术的方案，每个所述MCS DRIVER可以与多个设备进行SECS连接，在开启多台所述MCS DRIVER的场景下，每个所述MCS DRIVER中始终是0至全部的SECS连接处于ACTIVE状态，当ACTIVE状态SECS连接的所述MCS DRIVER主动关闭或异常崩溃，或所部署的服务器异常宕机，或设备断线重连时，处于STANDBY状态的某一个所述MCS DRIVER与设备LINK-TEST成功，变更为ACTIVE状态，并且上报所述MCS SERVER设备上线消息。

作为优选的技术的方案，所述MCS DRIVER是使用ASP.NET BLAZOR SERVER编写的，内聚了MCS的搬送业务逻辑，响应生产环境的搬送请求任务，可以向搬送设备发送搬送指令等远程控制指令，追踪设备状态、报警等信息，所述MCS SERVER是按照负载均衡机制进行设计，设备上报的消息通过所述MQ集群随机分发给任一所述MCS SERVER进行消息处理。

作为优选的技术的方案，所述MCS SERVER消息接口对接格式统一为JSON格式。

作为优选的技术的方案，所述MQ集群采用开源消息代理软件Rabbit MQ进行构建，多个Rabbit MQ节点采用镜像集群模式实现MQ集群的高可用性，所述MQ集群在构建消息队列时采用RPC模式，支持MCS SERVER->MCS DRIVER->设备或者设备->MCS DRIVER->MCSSERVER的RPC接口调用。

由于采用了上述技术方案，一种支持SECS协议的高可用性MCS集群系统，包括ORACLE数据库集群、MQ集群、多个MCS SERVER和多个MCS DRIVER，MCS SERVER与MCS DRIVER通过MQ集群进行通讯，ORACLE数据库集群实现各应用节点的数据共享，采用ORACLE RAC模式搭建数据库服务层；本发明的有益效果是：本发明为构建稳定可靠、高可用、可以进行无缝换版的MCS集群系统提供了一条切实可行的途径。在服务器故障等因素造成MCS服务失效时可以实现消息处理的重定位，进行故障转移；可以在维护现场搬送业务服务的同时，对应用进行补丁更新，实现无缝换版；支持使用SECS协议对设备进行RPC远程过程控制。

本发明架构清晰，适配性强，可以灵活组装MCS SERVER和MCS DRIVER，以适应其他外部控制系统或设备系统，并且根据FAB物流搬送的繁忙程度，系统可以进行多维横向拓展，易于构建，便于管理。在搬送业务繁重，系统性能受限时，MCS SERVER和MCS DRIVER均可以进行横向拓展，部署多台生产服务器，安装多个MCS SERVER和MCS DRIVER。MCS SERVER和MCS DRIVER可以进行灵活组合，按照m:n(m>1,n>1)的比例进行自定义调整，突破系统性能上限。

本发明的系统架构层次清晰，MCS消息处理应用与设备通讯协议充分解耦，即使设备与MCS SERVER的通讯方式并非SECS/GEM协议，开发者也仅需要开发通讯协议相应的MCS设备驱动程序，将设备消息进行转化，适配MCS SERVER需要的通用JSON格式消息即可，无需修改MCS SERVER的业务逻辑，使MCS集群系统能够更快地落地存在多种通讯协议的设备和对接系统的FAB环境，同时保证搬送业务逻辑的主体性不被侵蚀。

另外，在系统开发阶段，此时一部分设备接口相对稳定，另一部分设备还处于业务探讨阶段，可以将接口稳定的设备MCS DRIVER集中部署，接口易变的设备对应的MCSDRIVER独立部署，在系统版本更新时，仅更新接口易变的MCS DRIVER和MCS SERVER，避免稳定的设备MCS DRIVER也反复更新，造成设备重新连线进行初始化和生产暂停的问题，在这种精细化操作下，可以最大程度的保证FAB环境的稳定生产。本系统开发平台为.NET5以上，跨平台兼容，支持LINUX和WINDOW平台的部署，需要部署的节点实例在各场景和平台下具有一致性，正常来说并不需要安装其他中间件。

附图说明

以下附图仅旨在于对本发明做示意性说明和解释，并不限定本发明的范围。其中：

图1是现有技术支持无驱动节点的MCS集群系统架构示意图；

图2是本发明实施例一支持SECS协议的MCS高可用集群系统架构示意图；

图3是本发明实施例二主从对接系统无唯一IP的MCS集群系统变体架构示意图；

图4是本发明实施例三设备->MCS主机数据流和消息队列构建示意图；

图5是本发明实施例四MCS主机->设备数据流和消息队列构建示意图；

图6是本发明包含客户端和MES上位系统的完整MCS集群系统示意图。

具体实施方式

下面结合附图和实施例，进一步阐述本发明。在下面的详细描述中，只通过说明的方式描述了本发明的某些示范性实施例。毋庸置疑，本领域的普通技术人员可以认识到，在不偏离本发明的精神和范围的情况下，可以用各种不同的方式对所描述的实施例进行修正。因此，附图和描述在本质上是说明性的，而不是用于限制权利要求的保护范围。

实施例一：如图2所示，示出了支持半导体行业SECS/GEM通讯协议的高可用性MCS集群系统的基本架构示意图，必要元素包括ORACLE数据库集群，MQ集群，MCS SERVER集群(消息处理程序模块)，MCS DRIVER集群(设备通讯驱动模块)，支持平台包括WINDOWS和LINUX。本实施例中的ORACLE数据库集群包括ORACLE RAC和共享存储240，MQ集群采用开源消息代理软件Rabbit MQ进行构建，多个Rabbit MQ节点采用镜像集群模式实现MQ集群节点的高可用性；MCS SERVER集群包括MCS SERVER 110和MCS SERVER 120，MCS DRIVER集群包括MCS DRIVER 130和MCS DRIVER 140。

SECS/GEM通讯协议广泛的应用于半导体行业，规定了各种供应商的设备使用一致的标准和协议与主机系统进行通讯。标准定义了设备状态数据收集、跟踪数据收集、警报收集、远程命令等功能。

在本发明中，MCS DRIVER实例是ASP.NET BLAZOR SERVER编写的，MCS DRIVER 130和MCS DRIVER 140与设备通过SECS协议进行通讯，多台MCS DRIVER启动后同时与设备进行LINK-TEST请求，请求成功的MCS DRIVER与设备连线成功，处于ACTIVE状态，并向MCSSERVER上报设备上线事件。其他MCS DRIVER继续与设备进行间歇式的LINK-TEST请求，但实质上并未与设备连线，不会发送SECS消息，处于STANDBY状态。

每个MCS DRIVER可以与多个设备进行SECS连接，在开启多台MCS DRIVER的场景下，每个MCS DRIVER中应该是0至全部的SECS连接处于ACTIVE状态。当ACTIVE状态SECS连接的MCS DRIVER主动关闭，或MCS DRIVER异常崩溃，或所部署的服务器异常宕机，或设备断线重连时，处于STANDBY状态的某一个MCS DRIVER与设备LINK-TEST成功，变更为ACTIVE状态，并且上报MCS SERVER设备上线消息。

MCS SERVER实例同样是使用ASP.NET BLAZOR SERVER编写的，内聚了MCS的搬送业务逻辑，响应生产环境的搬送请求任务，可以向搬送设备发送搬送指令等远程控制指令，追踪设备状态、报警等信息。MCS SERVER 110和MCS SERVER 120是按照负载均衡机制进行设计，设备上报的消息通过MQ集群随机分发给MCS SERVER 110或MCS SERVER 120进行消息处理。无论是MCS DRIVER上报的消息，还是MES等外部系统接口调用，MCS SERVER消息接口对接格式统一为JSON格式。

MCS SERVER与MCS DRIVER通过MQ集群进行通讯，由于SECS定义了消息的有效方向，某些消息可以是双向的，因而可以进行设备的RPC远程过程控制，所以相应的MQ集群在构建消息队列时也采用了RPC模式，支持SERVER->DRIVER->设备或者设备->DRIVER->SERVER的RPC接口调用。消息在投递时可以配置是否需要回复，无需回复的消息仅投递到消息队列，不会等待MCS SERVER或者设备的回复，以优化系统消息转发效率。

实施例二：如图3所示，本发明提供的系统架构可以灵活调整MCS DRIVER和设备系统的关联关系，满足对接需求。同时运行两组MCS DRIVER，分别为MCS DRIVER 730和MCSDRIVER 770连接设备的MASTER系统，MCS DRIVER 740和MCS DRIVER 780连接设备的SLAVE系统，当设备MASTER系统宕机时，MCS DRIVER 740和MCS DRIVER 780连接到变更为MASTER状态的设备系统IP2；当MCS DRIVER GROUP 2所部署的服务器宕机时，MCS DRIVER 730连接到设备MASTER系统的IP1，不同节点故障时均能实现系统故障转移，达到MCS DRIVER的高可用性目标。MCS的应用程序逻辑没有变更，只调整了MCS DRIVER的配置方式，无需系统开发成员介入，具有较高的可拓展性和可维护性。

在搬送业务繁重，系统性能受限时，MCS SERVER和MCS DRIVER均可以进行横向拓展，部署多台生产服务器，安装多个MCS SERVER和MCS DRIVER。MCS SERVER和MCS DRIVER可以进行灵活组合，按照m:n(m>1,n>1)的比例进行自定义调整，突破系统性能上限；另外，在系统开发阶段，此时一部分设备接口相对稳定，另一部分设备还处于业务探讨阶段，可以将接口稳定的设备MCS DRIVER集中部署，接口易变的设备对应的MCS DRIVER独立部署，在系统版本更新时，仅更新接口易变的MCS DRIVER和MCS SERVER，避免稳定的设备MCS DRIVER也反复更新，造成设备重新连线进行初始化和生产暂停的问题，在这种精细化操作下，可以最大程度的保证FAB环境的稳定生产。此外，本系统开发平台为.NET5以上，跨平台兼容，支持LINUX和WINDOW平台的部署，需要部署的节点实例在各场景和平台下具有一致性，均为ORACLE数据库集群、MQ集群、多个MCS SERVER和多个MCS DRIVER，正常来说并不需要安装其他中间件。

实施例三：如图4所示，图4中存在两个MCS SERVER节点，分别为MCS SERVER 830节点和MCS SERVER 840节点，还存在两个MCS DRIVER节点，分别为MCS SERVER 850节点和MCSSERVER 860节点，并以一台支持SECS协议的设备870为例，展示了设备上报消息，并且需要MCS SERVER对上报消息做出反馈的数据回路示意图。

MCS DRIVER启动时，MCS DRIVER 850与设备创建了SECS连接，处于ACTIVE状态，MCS DRIVER 860待命处于STANDBY状态。MCS DRIVER与设备连线成功时申明设备上报消息需要投递的MQ队列REQUEST QUEUE 810和MCS SERVER响应消息的回复消息MQ队列REPLYQUEUE 820。

MQ队列REQUEST QUEUE 810不排外并且在没有消费者时不自动删除(EXCLUSIVE：FALSE，AUTO-DELETE：FALSE)，MQ队列REPLY QUEUE 820是MCS DRIVER与设备连线时自动生成的匿名队列，被每个MCS DRIVER独享，在没有消费者时自动删除(ANONYMOUS，EXCLUSIVE：TRUE，AUTO-DELETE：TRUE)。

MCS SERVER 830和MCS SERVER 840在启动后会自动订阅MCS DRIVER上报消息的MQ队列REQUEST QUEUE 810(E->H)。设备870上报的SECS消息通过MCS DRIVER 850转译为JSON格式消息并投递到MQ队列REQUEST QUEUE810，随机派发给消费者MCS SERVER 830或MCS SERVER 840进行业务处理，MCS SERVER处理后反馈结果回复到MQ队列REPLY QUEUE820。MCS DRIVER 850是MQ队列REPLY QUEUE 820的消费者，接收到反馈消息后转译为SECS消息，并回复给设备870，完成设备上报消息，MCS系统反馈设备的闭环数据回路。

当MCS SERVER 830节点故障时，设备上报的消息由MCS SERVER 840处理并回复MCS DRIVER，达到MCS SERVER节点故障转移的效果。当MCS DRIVER850节点故障时，匿名的排他MQ队列REPLY QUEUE 820消费者丢失，消息队列被自动删除。MCS DRIVER 860节点与设备LINK-TEST成功重新连线，变更为ACTIVE状态，并且申明新的匿名排他队列取代原来的MQ队列REPLY QUEUE820节点，用于接收MCS SERVER反馈的消息。MCS DRIVER节点切换流程结束后，设备上报消息按照上述流程正常处理，从而实现了设备上报消息场景下的MCSDRIVER节点故障转移。

实施例四：如图5所示，系统中存在两个MCS SERVER 910和MCS SERVER920节点，以及两个MCS DRIVER 960节点和MCS DRIVER 970节点，并以一台支持SECS协议的设备980为例，展示了MCS SERVER主动发送远程过程控制指令给设备，并且需要设备进行反馈的数据回路示意图。MCS DRIVER启动时，MCS DIRVER 960与设备创建了SECS连接处于ACTIVE状态，MCS DIRVER 970待命处于STANDBY状态。MCS SERVER 910和MCS SERVER 920节点启动时申明请求MQ队列REQUEST QUEUE 930，并且分别申明H->E请求消息的回复MQ队列REPLY QUEUE950和MQ队列REPLY QUEUE 940。

MQ队列REQUEST QUEUE 930被MCS SERVER 910和MCS SERVER 920共享，用于发送MCS SERVER的RPC请求消息，在没有消费者时不自动删除(EXCLUSIVE：FALSE，AUTO-DELETE：FALSE)。MQ队列REPLY QUEUE 950和MQ队列REPLY QUEUE 940是SERVER启动时自动生成的匿名队列，被每个MCS SERVER独享，用于保证数据回路安全，在没有消费者时自动删除(ANONYMOUS，EXCLUSIVE：TRUE，AUTO-DELETE：TRUE)。

当MCS SERVER 910节点故障时，相应的MQ队列REPLY QUEUE 950消息回复队列自动删除，MCS SERVER 920按照上述模式继续正常工作，不会影响主机向设备发送远程过程控制指令的功能。当MCS DRIVER 960故障，MCS DRIVER 970LINK-TEST成功，并订阅H->E的请求消息MQ队列REQUEST QUEUE930，承担设备消息请求职能，实现系统的高可用性。

图6是本发明包含客户端和MES上位系统的完整MCS集群系统示意图。从以上实施例可以看出，本发明中MCS集群系统依赖数据库集群实现各应用节点数据共享，采用ORACLERAC模式搭建了图1中所示的包含610～640节点的数据库服务层。如果生产环境搬送繁忙程度较低，搬送设备较少，在数据量较小时也可以采用开源的MySQL结合KeepAlive模式构建高可用数据库节点以降低成本。

本发明为构建稳定可靠、高可用、可以进行无缝换版的MCS集群系统提供了一条切实可行的途径。在服务器故障等因素造成MCS服务失效时可以实现消息处理的重定位，进行故障转移；可以在维护现场搬送业务服务的同时，对应用进行补丁更新，实现无缝换版；支持使用SECS协议对设备进行RPC远程过程控制。

本发明架构清晰，适配性强，可以灵活组装MCS SERVER和MCS DRIVER，以适应其他外部控制系统或设备系统，并且根据FAB物流搬送的繁忙程度，系统可以进行多维横向拓展，易于构建，便于管理。在搬送业务繁重，系统性能受限时，MCS SERVER和MCS DRIVER均可以进行横向拓展，部署多台生产服务器，安装多个MCS SERVER和MCS DRIVER。MCS SERVER和MCS DRIVER可以进行灵活组合，按照m:n(m>1,n>1)的比例进行自定义调整，突破系统性能上限。

本发明的系统架构层次清晰，MCS消息处理应用与设备通讯协议充分解耦，即使设备与MCS SERVER的通讯方式并非SECS/GEM协议，开发者也仅需要开发通讯协议相应的MCS设备驱动程序，将设备消息进行转化，适配MCS SERVER需要的通用JSON格式消息即可，无需修改MCS SERVER的业务逻辑，使MCS集群系统能够更快地落地存在多种通讯协议的设备和对接系统的FAB环境，同时保证搬送业务逻辑的主体性不被侵蚀。

另外，在系统开发阶段，此时一部分设备接口相对稳定，另一部分设备还处于业务探讨阶段，可以将接口稳定的设备MCS DRIVER集中部署，接口易变的设备对应的MCSDRIVER独立部署，在系统版本更新时，仅更新接口易变的MCS DRIVER和MCS SERVER，避免稳定的设备MCS DRIVER也反复更新，造成设备重新连线进行初始化和生产暂停的问题，在这种精细化操作下，可以最大程度的保证FAB环境的稳定生产。本系统开发平台为.NET5以上，跨平台兼容，支持LINUX和WINDOW平台的部署，需要部署的节点实例在各场景和平台下具有一致性，正常来说并不需要安装其他中间件。

以上显示和描述了本发明的基本原理、主要特征及本发明的优点。本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施例和说明书中描述的只是说明本发明的原理，在不脱离本发明精神和范围的前提下，本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内。本发明要求保护范围由所附的权利要求书及其等效物界定。

Claims (10)

1.一种支持SECS协议的高可用性MCS集群系统，其特征在于：包括ORACLE数据库集群、MQ集群、多个MCS SERVER和多个MCSDRIVER，所述MCS SERVER与所述MCSDRIVER通过所述MQ集群进行通讯，所述ORACLE数据库集群实现各应用节点的数据共享，采用ORACLE RAC模式搭建数据库服务层。

2.如权利要求1所述的一种支持SECS协议的高可用性MCS集群系统，其特征在于：所述ORACLE数据库集群包括多台数据库服务器和共享存储，所述MCS SERVER为消息处理程序模块，所述MCSDRIVER为设备通讯驱动模块。

3.如权利要求1所述的一种支持SECS协议的高可用性MCS集群系统，其特征在于：所述MCS SERVER和所述MCSDRIVER均可以进行横向拓展，部署多台生产服务器，所述MCS SERVER和所述MCSDRIVER按照m:n(m>1,n>1)的比例进行自定义调整。

4.如权利要求1所述的一种支持SECS协议的高可用性MCS集群系统，其特征在于：在系统开发阶段，接口相对稳定设备对应的所述MCSDRIVER集中部署，接口易变设备对应的所述MCSDRIVER独立部署，在系统版本更新时，仅更新接口易变设备对应的所述MCSDRIVER和所述MCS SERVER，避免接口相对稳定设备的所述MCSDRIVER反复更新。

5.如权利要求1所述的一种支持SECS协议的高可用性MCS集群系统，其特征在于：所述MCS集群系统的开发平台为.NET5以上，跨平台兼容，支持LINUX和WINDOW平台的部署。

6.如权利要求1所述的一种支持SECS协议的高可用性MCS集群系统，其特征在于：所述MCS SERVER是使用ASP.NET BLAZOR SERVER编写的，所述MCSDRIVER与设备通过SECS/GEM通讯协议进行通讯，多台所述MCSDRIVER启动后同时与设备进行LINK-TEST请求，请求成功的所述MCSDRIVER与设备连线成功，处于ACTIVE状态，并向所述MCS SERVER上报设备上线事件，其他所述MCSDRIVER继续与设备进行间歇式的LINK-TEST请求，但实质上并未与设备连线，不会发送SECS消息，处于STANDBY状态。

7.如权利要求6所述的一种支持SECS协议的高可用性MCS集群系统，其特征在于：每个所述MCSDRIVER可以与多个设备进行SECS连接，在开启多台所述MCSDRIVER的场景下，每个所述MCSDRIVER中始终是0至全部的SECS连接处于ACTIVE状态，当ACTIVE状态SECS连接的所述MCSDRIVER主动关闭或异常崩溃，或所部署的服务器异常宕机，或设备断线重连时，处于STANDBY状态的某一个所述MCSDRIVER与设备LINK-TEST成功，变更为ACTIVE状态，并且上报所述MCS SERVER设备上线消息。

8.如权利要求1所述的一种支持SECS协议的高可用性MCS集群系统，其特征在于：所述MCSDRIVER是使用ASP.NET BLAZOR SERVER编写的，内聚了MCS的搬送业务逻辑，响应生产环境的搬送请求任务，可以向搬送设备发送搬送指令等远程控制指令，追踪设备状态、报警等信息，所述MCS SERVER是按照负载均衡机制进行设计，设备上报的消息通过所述MQ集群随机分发给任一所述MCS SERVER进行消息处理。

9.如权利要求8所述的一种支持SECS协议的高可用性MCS集群系统，其特征在于：所述MCS SERVER消息接口对接格式统一为JSON格式。

10.如权利要求1所述的一种支持SECS协议的高可用性MCS集群系统，其特征在于：所述MQ集群采用开源消息代理软件Rabbit MQ进行构建，多个Rabbit MQ节点采用镜像集群模式实现MQ集群的高可用性，所述MQ集群在构建消息队列时采用RPC模式，支持MCS SERVER->MCSDRIVER->设备或者设备->MCSDRIVER->MCS SERVER的RPC接口调用。

Images