CN111159089A - 一种冗余主机链路冲突模式下设备通信方法和系统 - Google Patents
一种冗余主机链路冲突模式下设备通信方法和系统 Download PDFInfo
- Publication number
- CN111159089A CN111159089A CN201911393669.0A CN201911393669A CN111159089A CN 111159089 A CN111159089 A CN 111159089A CN 201911393669 A CN201911393669 A CN 201911393669A CN 111159089 A CN111159089 A CN 111159089A
- Authority
- CN
- China
- Prior art keywords
- link
- actual
- host
- equipment
- slave
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 230000006854 communication Effects 0.000 title claims abstract description 80
- 238000004891 communication Methods 0.000 title claims abstract description 79
- 238000000034 method Methods 0.000 title claims abstract description 37
- 230000004044 response Effects 0.000 claims description 46
- 230000005540 biological transmission Effects 0.000 claims description 8
- 230000008569 process Effects 0.000 claims description 8
- 238000012545 processing Methods 0.000 claims description 8
- 238000004364 calculation method Methods 0.000 claims 1
- 230000006870 function Effects 0.000 description 20
- 229920009441 perflouroethylene propylene Polymers 0.000 description 9
- 238000003745 diagnosis Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 238000013507 mapping Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
- G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
- G06F13/4282—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/22—Arrangements for detecting or preventing errors in the information received using redundant apparatus to increase reliability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45579—I/O management, e.g. providing access to device drivers or storage
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Hardware Redundancy (AREA)
Abstract
本发明公开了一种冗余主站链路冲突模式下设备通信方法，包括：在冗余主站链路冲突模式下，当串行总线链路下的设备出现交叉故障时，对所述串行总线链路下所有可以与所述冗余主站中任意一台主机正常通信的每一台设备分别按照以下方式执行轮询策略：当该设备在两台主机上所映射的两个虚拟设备中的实际主设备在线时，对该实际主设备执行第一轮询策略，对两个虚拟设备中的实际从设备执行第二轮询策略；当该设备在两台主机上所映射的两个虚拟设备中的实际主设备不在线，且实际从设备在线时，对实际从设备执行第一轮询策略，对实际主设备执行第二轮询策略；其中，冗余主站包括：互为冗余的两台主机。本发明还公开了一种冗余主站链路冲突模式下设备通信的系统。
Description
技术领域
本发明涉及设备通信领域，尤其涉及一种应用于串行总线链路下的冗余主机链路冲突模式下的通信方法和系统。
背景技术
工业控制系统的数据采集多采用冗余FEP(Front-End Processor，前端通信处理器，简称前置机，在本文中，FEP作为主站)来实现，而国内外大量设备的通信只支持串行单通道，如图1所示，通常设备只能提供一个串口(单通道)连接到冗余FEP主站的COMX串口。
作为从站的设备和作为冗余主站的FEP之间的通信规约大量采用主从应答方式，物理层一般采用双线制RS485半双工工作方式，即任何时候只能有一个通信节点(通信节点是指串行总线上所有参与通信的冗余主站FEP和从站设备)处于发送状态，这就是链路冲突模式。在链路冲突模式下，冗余主站负责管理链路通信，避免出现多主同时与设备通信从而引发链路冲突，导致通信故障。总之，主站控制通信以确保主从之间的通信稳定、可靠、实时。
首先，必须对串口链路的写操作加以管理，即两台互为冗余FEP要保证不同时向设备发送数据请求等指令，否则就会导致链路数据混乱，通信失效。发明专利《一种避免冗余主站对串行总线链路访问冲突的方法》(申请号200510115559.X，以下称为参考文件1)能保证主从应答规约中从站设备为单通道时，冗余主站不会同时对设备执行操作。
在冗余主站链路冲突模式下，实际通信过程中可能存在链路设备交叉故障(交叉故障是指同一链路下的N(N≥2)个设备中，其中的部分设备只能与一台FEP正常通信，有另一部分设备只能与另一台FEP正常通信)的情况，如图5所示：不妨假设冲突模式的链路下一共有6个物理设备，记为Dev1～Dev6，其中Dev1、Dev2、Dev3只能与FEP-A的COMX正常通信，Dev4、Dev5只能与FEP-B的COMX正常通信，而Dev6与FEP-A、FEP-B都不能正常通信。即冗余FEP综合互补来看，Dev1、Dev2、Dev3、Dev4、Dev5是通信正常的，只不过Dev1、Dev2、Dev3需要通过FEP-A通信才正常，而Dev4、Dev5需要通过FEP-B通信才正常。链路冲突模式下，FEP-A和FEP-B都作为通信主站，对同一个冲突链路的访问必须采用协商模式，即当FEP-A在与从站设备进行轮询通信会话时，FEP-B必须是静默的(静默的含义是指自身不能向链路发送任何报文)，反之亦然。
在已有的串行总线链路的冗余主站通信模式下，冗余主站包括一台主机和一台另主机，互为冗余；其主机可以是FEP。相应地，以主机为FEP为例，互为冗余的主机记为FEP和FEP-Peer。每个主机下完成对应链路下所有设备通信(包括数据采集和通信控制等功能)的软件单元记为驱动(Driver，简称Drv)，一般一个链路对应一个驱动；互为冗余的两个驱动记为Drv和Drv-Peer，Drv和Drv-Peer为相对概念。一个Drv下对应N个虚拟设备；N个虚拟设备是N个物理设备在主机FEP上的映射。两台主机FEP上互为冗余的两个虚拟设备记为Unit和Unit-Peer，Unit是FEP上对物理设备Dev的映射，Unit-Peer是FEP-Peer上对物理设备Dev的映射，Unit和Unit-Peer为相对概念。
往往把FEP-A/FEP-B下的链路驱动Drv作为整体单位，我们记FEP-A的COMX对应驱动DrvX-A，记FEP-B的COMX对应驱动DrvX-B,DrvX-A和DrvX-B互为冗余关系。传统方法下，DrvX-A下的所有设备具有相同通信优先级，DrvX-B下的所有设备具有另一相同通信优先级。例如，我们不妨假设链路下所有设备具有相同权重，则上例中，由于DrvX-A下在线设备多，则DrvX-A将为实际主Hot，DrvX-B为实际从Standby，作为Hot的DrvX-A下所辖Units将获得与链路上Devs的主要通信机会(主动发起通信的频率高，如图2)，而DrvX-B下所辖Units将获得与链路上Devs的次要通信机会(主动发起通信的频率低，每WatchTime时间才能获得发起通信的机会，如图3和图4)。即上文中的Dev1、Dev2、Dev3将获得链路上的快速通信机会，但同样在线的Dev4、Dev5却只能获得链路上的慢速通信机会。
在如上较为复杂的链路设备交叉故障的情况，对于如何确保Dev1、Dev2、Dev3、Dev4、Dev5通信的稳定、可靠和实时，特别是冲突链路设备交叉故障时如何确保所有综合通信正常设备(综合通信正常是指任意一个冗余主站可以通信正常)的数据实时性，传统方法往往顾此失彼，并没有给出令人满意的答案。
发明内容
针对串行总线链路的冗余主站链路冲突模式下链路设备交叉故障的情况，现有通信方案存在上述不足，本发明提供一种冗余主站链路冲突模式下设备通信方法和系统。
本发明提供一种冗余主站链路冲突模式下设备通信方法，包括：
在冗余主站链路冲突模式下，当串行总线链路下的设备出现交叉故障时，对所述串行总线链路下所有可以与所述冗余主站中任意一台主机正常通信的每一台设备分别按照以下方式执行轮询策略：
当该设备在两台主机上所映射的两个虚拟设备中的实际主设备在线时，对该实际主设备执行第一轮询策略，对两个虚拟设备中的实际从设备执行第二轮询策略；
当该设备在两台主机上所映射的两个虚拟设备中的实际主设备不在线，且实际从设备在线时，对实际从设备执行第一轮询策略，对实际主设备执行第二轮询策略；
其中，冗余主站包括：互为冗余的两台主机。
可选地，所述对所述串行总线链路下所有可以与所述冗余主站中任意一台主机正常通信的每一台设备还执行以下轮询策略：
当该设备在两台主机上所映射的两个虚拟设备中的实际主设备和实际从设备均不在线时，如果所述串行总线链路下至少有一个设备在线，则对实际主设备和实际从设备都执行第二轮询策略；如果所述串行总线链路下其他设备都不在线时，则对实际主设备和实际从设备都执行第一轮询策略。
可选地，其中，所述第一轮询策略对应的轮询周期小于所述第二轮询策略对应的轮询周期。
可选地，其中，所有虚拟设备的实际主从与对应链路的实际主从保持一致，包括：
当所述虚拟设备对应的链路为实际主链路时，所述虚拟设备无论在线与否，都为实际主；当所述虚拟设备对应的链路为实际从链路时，所述虚拟设备无论在线与否，都为实际从。
可选地，其中，实际主链路和实际从链路通过比较冗余主机各自的链路有效权重(LEW)确定，所述LEW的计算公式如下：
其中，n表示该链路下虚拟设备总个数；Wi表示虚拟设备i的权重值，Si表示虚拟设备i的在线状态，1表示虚拟设备在线，0表示虚拟设备不在线；
当冗余主站中一台主机A的链路有效权重LEW-A＞另一台主机B的链路有效权重LEW-B时，所述一台主机A对应的链路为实际主链路，所述另一台主机B对应的链路为实际从链路；
当LEW-B＞LEW-A时，所述另一台主机B对应的链路为实际主链路，所述一台主机A对应的链路为实际从链路；
当LEW-A＝LEW-B时，根据预定规则确定冗余主站中两台主机对应的链路中的实际主链路和实际从链路。
可选地，其中，所述根据预定规则确定冗余主站中两台主机对应的链路中的实际主链路和实际从链路，包括：
如果存在默认主优先原则，则所述一台主机A和所述另一台主机B中默认主的一方所对应的链路为实际主链路，默认从的一方所对应的链路为实际从链路；如果没有默认主优先原则，若当前已经有一方对应的链路为实际主链路，则不改变当前状态，若当前没有任何一方对应的链路为实际主链路，则所述一台主机A对应的链路为实际主链路，所述另一台主机B对应的链路为实际从链路。
可选地，对于所述串行总线链路下的每一台设备，如果该设备在一台主机上映射的虚拟设备为Unit，在另一台主机上映射的虚拟设备为Unit-Peer，则所述Unit和所述Unit-Peer中的一个为实际主设备，另一个为实际从设备；
所述方法还包括：驱动根据自己的链路实际主从状态执行如下策略：
当所述驱动判断所对应的链路为实际主链路时，
所述驱动以本链路对应主机的设备状态和另一主机的设备状态为输入参数，调用请求生成算法，获取当前需要发送的请求；
如果获取的需要发送的请求是本机驱动请求，则所述驱动发送请求给目标设备并启动接收超时定时器，记录第一超时时间TimeOut1；当所述驱动从设备收到应答报文后，处理报文，根据应答报文所对应的设备，更新对应Unit本地实时数据库，并更新对应Unit为在线状态；
如果获取的需要发送的请求是另机驱动请求，则通过链路同步管理功能发送给另机驱动并启动接收超时定时器，记录第二超时时间TimeOutPeer，其中所述TimeOutPeer＝TimeOut1+δT，δT为两次链路同步管理在所述一台主机和所述另一台主机之间传输所需的实际最大时间；当收到所述另机驱动返回的回执或者应答时，终止本次超时；
其中，所述驱动是指所述一台主机中完成对应链路下所有设备通信的软件单元；所述另机驱动是指所述另一台主机中完成对应链路下所有设备通信的软件单元。
可选地，对于所述串行总线链路下的每一台设备，如果该设备在一台主机上映射的虚拟设备为Unit，在另一台主机上映射的虚拟设备为Unit-Peer，则所述Unit和所述Unit-Peer中的一个为实际主设备，另一个为实际从设备；
所述方法还包括：驱动根据所对应的链路实际主从状态执行如下策略：
当所述驱动判断自己的链路为实际从链路时，
调用链路同步管理功能，如果没有收到请求，则结束处理；
如果有收到请求，则所述驱动发送请求给目标设备并启动接收超时定时器，记录第三超时时间TimeOut3；所述驱动收到设备应答后，根据应答报文所对应的设备，更新对应Unit为在线状态；如果对应的Unit-Peer不在线，则处理报文，更新对应Unit本地实时数据库，并给另机驱动发送回执；如果对应的Unit-Peer在线，则把所述设备应答作为响应通过链路同步管理功能转发给另机驱动；
其中，所述驱动是指所述一台主机中完成对应链路下所有设备通信的软件单元；所述另机驱动是指所述另一台主机中完成对应链路下所有设备通信的软件单元。
本发明还提供一种冗余主站链路冲突模式下设备通信的系统，包括：
一台主机、另一台主机和至少两台设备；其中，所述一台主机和所述另一台主机互为冗余，构成所述冗余主站，所述至少两台设备为从站；
在冗余主站链路冲突模式下，当串行总线链路下的所述至少两台设备出现交叉故障时，所述一台主机和所述另一台主机对所述串行总线链路下所有可以与其中任意一台主机正常通信的每一台设备分别按照以下方式执行轮询策略：
当该设备在两台主机上所映射的两个虚拟设备中的实际主设备在线时，对该实际主设备执行第一轮询策略，对两个虚拟设备中的实际从设备执行第二轮询策略；
当该设备在两台主机上所映射的两个虚拟设备中的实际主设备不在线，且实际从设备在线时，对实际从设备执行第一轮询策略，对实际主设备执行第二轮询策略。
可选地，其中，所述一台主机和所述另一台主机对所述串行总线链路下所有可以与其中任意一台主机正常通信的每一台设备还执行以下轮询策略：
当该设备在两台主机上所映射的两个虚拟设备中的实际主设备和实际从设备均不在线时，如果所述串行总线链路下至少有一个设备在线，则对实际主设备和实际从设备都执行第二轮询策略；如果所述串行总线链路下其他设备都不在线时，则对实际主设备和实际从设备都执行第一轮询策略。
本发明针对冗余主站在链路冲突模式下，在同一链路中的设备出现交叉故障时，采用上述方案确保该链路下所有综合通信正常的设备均能获得快速通信机会，提高了各综合通信正常的设备的通信实时性。
附图说明
图1串行总线冗余主站网络概貌图；
图2串行总线冗余主站FEP-A常规通信图；
图3串行总线冗余主站FEP-B WatchTime通信图；
图4串行总线冗余主站FEP-B WatchTime流程图；
图5链路设备交叉故障物理示例；
图6冗余主机链路冲突模式下设备通信系统及软件功能模块示意图；
图7FEP和设备间接入网络转串口适配器；
图8实施例一中一种冗余主站链路冲突模式下设备通信方法的流程图；
图9实施例二中一种冗余主站链路冲突模式下设备通信方法的流程图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚，下面将结合附图及具体实施例对本发明作进一步的详细描述。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。
首先，本发明涉及的相关定义说明如下，但不限于下述各具体情况：
串行总线链路通信中，主站负责管理链路通信，避免出现多主同时与设备通信从而引发链路冲突，导致通信故障。冗余主站包括至少2台主机作为互为冗余的主站。串行总线链路通信中作为从站的设备由主站控制，以确保主从之间的通信稳定可靠。FEP可以作为冗余主站中的主机。
在串行总线链路通信的冗余主站模式下，存在以下基本概念：
主机---Primary，指冗余主机默认为主的一方，也称FEP-A，是静态的。
从机---Secondary，指冗余主机默认为从的一方，也称FEP-B，是静态的。
热机---Hot，指冗余主机运行过程中实际为主的一方，也称实际主，是动态的。
备机---Standby，指冗余主机运行过程中实际为从的一方，也称实际从，是动态的。
主站---Master，指通信双方有权发起命令的一方，主机、从机、热机、备机都是主站。
从站---Slave，指通信双方无权发起命令的一方，也称设备。
串行总线链路是指物理上的串行总线链路；冗余主机中实际主的主机所控制的串行总线链路被称为主机对应的实际主链路，为逻辑链路，成为该主机对应的链路；冗余主机中实际从的主机所控制的串行总线链路被称为主机对应的实际从链路，为逻辑链路，成为该主机对应的链路。
驱动对应的链路，是指驱动所在的主机所对应的链路，为逻辑链路。
串行总线链路下的每一台设备，分别在两台主机上映射虚拟设备；如果该设备在一台主机上映射的虚拟设备为Unit，在另一台主机上映射的虚拟设备为Unit-Peer，则所述Unit和所述Unit-Peer中的一个为实际主设备，另一个为实际从设备。
虚拟设备对应的链路，是指虚拟设备所在的主机所对应的链路，为逻辑链路。
实施例一
如图8所示，本实施例提供一种冗余主站链路冲突模式下设备通信方法，包括：
步骤801：在冗余主站链路冲突模式下，当串行总线链路下的设备出现交叉故障时，对所述串行总线链路下所有可以与所述冗余主站中任意一台主机正常通信的每一台设备分别按照对应的方式执行轮询策略，包括如下：
当该设备在两台主机上所映射的两个虚拟设备中的实际主设备在线时，对该实际主设备执行第一轮询策略，对两个虚拟设备中的实际从设备执行第二轮询策略；
当该设备在两台主机上所映射的两个虚拟设备中的实际主设备不在线，且实际从设备在线时，对实际从设备执行第一轮询策略，对实际主设备执行第二轮询策略；
其中，冗余主站包括：互为冗余的两台主机。
可选地，所述对所述串行总线链路下所有可以与所述冗余主站中任意一台主机正常通信的每一台设备还执行以下轮询策略：
当该设备在两台主机上所映射的两个虚拟设备中的实际主设备和实际从设备均不在线时，如果所述串行总线链路下至少有一个设备在线，则对实际主设备和实际从设备都执行第二轮询策略；如果所述串行总线链路下其他设备都不在线时，则对实际主设备和实际从设备都执行第一轮询策略。
可选地，其中，所述第一轮询策略对应的轮询周期小于所述第二轮询策略对应的轮询周期。
可选地，其中，所有虚拟设备的实际主从与对应链路的实际主从保持一致，包括：
当所述虚拟设备对应的链路为实际主链路时，所述虚拟设备无论在线与否，都为实际主；当所述虚拟设备对应的链路为实际从链路时，所述虚拟设备无论在线与否，都为实际从。
可选地，其中，实际主链路和实际从链路通过比较冗余主机各自的链路有效权重(LEW)确定，所述LEW的计算公式如下：
其中，n表示该链路下虚拟设备总个数；Wi表示虚拟设备i的权重值，Si表示虚拟设备i的在线状态，1表示虚拟设备在线，0表示虚拟设备不在线；
当冗余主站中一台主机A的链路有效权重LEW-A＞另一台主机B的链路有效权重LEW-B时，所述一台主机A对应的链路为实际主链路，所述另一台主机B对应的链路为实际从链路；
当LEW-B＞LEW-A时，所述另一台主机B对应的链路为实际主链路，所述一台主机A对应的链路为实际从链路；
当LEW-A＝LEW-B时，根据预定规则确定冗余主站中两台主机对应的链路中的实际主链路和实际从链路。
可选地，其中，所述根据预定规则确定冗余主站中两台主机对应的链路中的实际主链路和实际从链路，包括：
如果存在默认主优先原则，则所述一台主机A和所述另一台主机B中默认主的一方所对应的链路为实际主链路，默认从的一方所对应的链路为实际从链路；如果没有默认主优先原则，若当前已经有一方对应的链路为实际主链路，则不改变当前状态，若当前没有任何一方对应的链路为实际主链路，则所述一台主机A对应的链路为实际主链路，所述另一台主机B对应的链路为实际从链路。
可选地，对于所述串行总线链路下的每一台设备，如果该设备在一台主机上映射的虚拟设备为Unit，在另一台主机上映射的虚拟设备为Unit-Peer，则所述Unit和所述Unit-Peer中的一个为实际主设备，另一个为实际从设备；
所述方法还包括：驱动根据自己的链路实际主从状态执行如下策略：
当所述驱动判断所对应的链路为实际主链路时，
所述驱动以本链路对应主机的设备状态和另一主机的设备状态为输入参数，调用请求生成算法，获取当前需要发送的请求；
如果获取的需要发送的请求是本机驱动请求，则所述驱动发送请求给目标设备并启动接收超时定时器，记录第一超时时间TimeOut1；当所述驱动从设备收到应答报文后，处理报文，根据应答报文所对应的设备，更新对应Unit本地实时数据库，并更新对应Unit为在线状态；
如果获取的需要发送的请求是另机驱动请求，则通过链路同步管理功能发送给另机驱动并启动接收超时定时器，记录第二超时时间TimeOutPeer，其中所述TimeOutPeer＝TimeOut1+δT，δT为两次链路同步管理在所述一台主机和所述另一台主机之间传输所需的实际最大时间；当收到所述另机驱动返回的回执或者应答时，终止本次超时；
其中，所述驱动是指所述一台主机中完成对应链路下所有设备通信的软件单元；所述另机驱动是指所述另一台主机中完成对应链路下所有设备通信的软件单元。
可选地，对于所述串行总线链路下的每一台设备，如果该设备在一台主机上映射的虚拟设备为Unit，在另一台主机上映射的虚拟设备为Unit-Peer，则所述Unit和所述Unit-Peer中的一个为实际主设备，另一个为实际从设备；
所述方法还包括：驱动根据所对应的链路实际主从状态执行如下策略：
当所述驱动判断自己的链路为实际从链路时，
调用链路同步管理功能，如果没有收到请求，则结束处理；
如果有收到请求，则所述驱动发送请求给目标设备并启动接收超时定时器，记录第三超时时间TimeOut3；所述驱动收到设备应答后，根据应答报文所对应的设备，更新对应Unit为在线状态；如果对应的Unit-Peer不在线，则处理报文，更新对应Unit本地实时数据库，并给另机驱动发送回执；如果对应的Unit-Peer在线，则把所述设备应答作为响应通过链路同步管理功能转发给另机驱动；
其中，所述驱动是指所述一台主机中完成对应链路下所有设备通信的软件单元；所述另机驱动是指所述另一台主机中完成对应链路下所有设备通信的软件单元。
实施例二
本实施例中，该实施例中涉及的系统及功能模块架构如图6所示，冗余主站包括的两台互为冗余的主机FEB-A和FEB-B，当其中一台记为FEP时，另一台记为FEP-Peer，FEP和FEP-Peer为相对概念。两台主机上互为冗余的驱动记为DrvX和DrvX-Peer，DrvX和DrvX-Peer也是相对概念
冗余主站在链路冲突模式下，同一链路中的设备出现交叉故障时，应用于冗余主站(FEP-A和FEP-B)对该链路的通信及诊断协调，所涉及的软件模块包括：冗余驱动DrvX-A和DrvX-B、数据同步管理(DataSync)、状态同步管理(StateSync)、链路同步管理(LinkSync)、请求生成算法(ReqGenAlg)。
DataSync通过心跳线(心跳线可以是基于FEP之间的既有的双网A、B网的连接，也可以是仅存在于FEP-A和FEP-B之间的单独直连网线C，甚至还可以是FEP之间的串口线，即冗余FEP之间的心跳线可以多达四重冗余)负责完成冗余FEP之间所有设备的数据实时同步，实时确保FEP-A和FEP-B所有设备数据一致。DataSync同步原则：以设备为单位，Unit和Unit-Peer都在线时，实际主Unit向实际从Unit同步数据；Unit和Unit-Peer只有一个设备在线时，在线Unit向离线Unit同步数据。
StateSync通过心跳线负责完成冗余FEP(FEP-A和FEP-B)之间所有驱动链路状态、Unit状态实时同步，实时确保FEP-A和FEP-B所有设备状态一致。驱动链路状态是指驱动链路层整体的实际主(Hot)/从(Standby)状态、在线(Online)/离线(Offline)状态等。Unit状态包括FEP-A和FEP-B对应链路下各自所有Unit的实际主(Hot)/从(Standby)状态、在线(Online)/离线(Offline)状态等。其中，链路层的在线是指链路层能初始化成功，比如所在串口存在并且能正常打开(串口为独占式工作模式，即假设FEP上有其他程序已经打开某串口时，FEP上的其他程序就不能再打开该串口)。注意：链路在线与否与该链路下Unit是否在线没有必然联系。
LinkSync通过心跳线负责完成冗余FEP(FEP-A和FEP-B)之间如下事务：当热机驱动需要通过备机驱动给Dev发送报文时，热机驱动生成设备请求报文并调用LinkSync发给备机驱动。当热机Unit在线时，称为备机诊断请求，记为StandbyDiagRequest，备机驱动收到StandbyDiagRequest并发给Dev，备机驱动收到Dev应答StandbyDiagResponse后，需要把StandbyDiagResponse通过LinkSync回传给热机驱动；当热机Unit离线时，称为备机常规请求，记为StandbyRequest，备机驱动收到StandbyRequest并发给Dev，备机驱动收到Dev应答StandbyResponse后，无须把StandbyResponse回传给热机驱动，只需给热机驱动发送回执StandbyReceipt以表示备机驱动成功收到Dev应答。
可选地，上述报文经由热机驱动或备机驱动发送给目标设备(物理设备)并接收应答报文的过程根据相关技术方案实现，在此不再赘述。
如图9所示，本实施例提供一种冗余主站链路冲突模式下设备通信方法，包括：
步骤901，驱动DrvX实时获取自己的链路实际主(Hot)/从(Standby)状态；
步骤902，驱动DrvX实时获取冗余FEP的设备状态，冗余FEP的设备状态包括FEP-A和FEP-B链路下各自所有Unit的实际主(Hot)/从(Standby)状态、在线(Online)/离线(Offline)状态等；
步骤903，驱动DrvX根据自己的链路实际主从状态与设备进行通信，包括：
驱动DrvX判断自己对应的链路为实际主链路时，执行步骤9031：
驱动DrvX以冗余FEP的设备状态为输入参数，调用请求生成算法(ReqGenAlg)，获取当前需要发送的请求，判断所获取的需要发送的请求的类型；
如果是本机驱动(DrvX)请求，则所述驱动DrvX执行本机发送所述请求给目标设备并启动接收超时定时器，记录第一超时时间TimeOut1，DrvX从设备收到应答报文后，处理报文，识别报文中的数字量输入(DI)、模拟量输入(AI)等数据信息，根据应答报文所对应的设备，更新相应Unit本地实时数据库的DI、AI等信息，并更新对应Unit为在线(Online)状态。
如果是另机驱动(DrvX-Peer)请求，通过LinkSync功能发送所述请求给另机驱动(DrvX-Peer)并启动接收超时定时器，记录第二超时时间TimeOutPeer，其中TimeOutPeer＝TimeOut+δT，δT约为两次LinkSync传输所需的实际最大时间(两次LinkSync传输包括：一次为DrvX通过LinkSync发送请求给DrvX-Peer，一次为DrvX-Peer收到设备应答后，通过LinkSync将应答报文回传给DrvX)，δT通常可以取1000毫秒(可配置为其他时长)，当收到另机驱动返回的回执(StandbyReceipt)或者应答(StandbyDiagResponse)时，终止本次超时。
其中，本机驱动请求是指需由当前驱动发送给目标设备的请求，另机驱动请求是指需经由另机驱动发送给目标设备的请求；可以根据所获取的当前需要发送的请求的相关属性确定。
当驱动DrvX判断自己链路为实际从(Standby)链路时，执行步骤9032：
调用LinkSync功能，如果没有从LinkSync收到请求，直接返回，不再执行以下步骤。如果从LinkSync收到请求，DrvX执行发送并启动接收超时定时器，记录第三超时时间TimeOut3，驱动DrvX收到设备应答后，根据应答报文所对应的设备，更新对应Unit状态为在线(Online)；如果该Unit对应的Unit-Peer(此时为实际主)不在线，则还需处理报文，识别报文中的DI、AI数据等信息，根据应答报文所对应的设备，更新相应Unit本地实时数据库的DI、AI等信息，并给另机驱动发送回执(StandbyReceipt)以表示备机驱动成功收到Dev应答，但无须给另机驱动转发设备应答；当该Unit对应的Unit-Peer在线时，Dev的这个应答就是StandbyDiagResponse，则不对Unit的本地实时数据库进行更新，但需要把StandbyDiagResponse通过LinkSync功能转发给另机驱动DrvX-Peer(此时为实际主)。对应的DrvX-Peer从LinkSync功能收到StandbyDiagResponse后，处理报文，识别报文中的DI、AI数据等信息，根据应答报文所对应的设备，更新Unit-Peer的本地实时数据库的DI、AI等信息。
可选地，请求生成算法(ReqGenAlg)获取需要发送的请求，步骤如下：
步骤1：先调用LinkSync功能，判断是否有来自另机驱动发过来的请求，如果有，则当前待发送请求就是该请求，不再执行以下步骤。
步骤2：检查是否有重要请求需要发送，如果有，则当前待发送请求就是该请求，不再执行以下步骤。其中，重要请求包括遥控请求以及遥控相关请求，其中遥控请求是FEP的上位机发给FEP进而传递给驱动的请求，FEP收到遥控请求时不能让驱动立即执行，因为驱动当时很可能正在执行其他请求或接收应答中，所以，遥控请求会先缓存到驱动的遥控缓存队列中。而遥控相关请求是指遥控发送后，驱动生成的遥控伴随报文，详见参考文件2(一种遥控返信读取的方法和装置，申请号2017102839630)，遥控相关请求还可以是遥控清零报文。
步骤3：检查是否有重发请求需要发送，如果有，则当前待发送请求就是该请求，不再执行以下步骤。
步骤4：判断当前Unit的本机的实际主(Hot)/从(Standby)状态、在线(Online)/离线(Offline)状态，以及另机Unit-Peer的实际主(Hot)/从(Standby)状态、在线(Online)/离线(Offline)状态，依据如下情形分别执行策略A或策略B产生对应的事务请求，则当前待发送请求就是所产生的请求：
情形1：当前本机Unit(实际主)在线，另机Unit-Peer(实际从)无论在线与否，对Unit执行策略A(第一轮询策略)产生对应的事务请求，对Unit-Peer执行策略B(第二轮询策略)产生对应的事务请求。
情形2：当前本机Unit(实际主)不在线，但另机Unit-Peer(实际从)却在线，此时，对Unit-Peer执行策略A(第一轮询策略)产生对应的事务请求，对Unit执行策略B(第二轮询策略)产生对应的事务请求。
情形3：当前本机Unit和另机Unit-Peer均离线，当链路下至少有一个其他设备在线(即其他设备对应的Unit或Unit-Peer在线)时，则对当前本机Unit和另机Unit-Peer都执行策略B(第二轮询策略)，产生对应的事务请求；当链路下其他设备也都离线(即其他设备对应的Unit和Unit-Peer都离线)时，对本机Unit和另机Unit-Peer都执行策略A(第一轮询策略)，产生对应的事务请求。
可选地，其中，策略A(第一轮询策略)——快速轮询策略。策略A中的Unit所对应的设备能得到快速轮询。每次给当前Unit所对应的设备发送一个请求后，下次轮转到下一Unit所对应的设备，依次循环。策略A占据大部分的链路通信次数。
策略B(第二轮询策略)——慢速诊断策略。策略B中的Unit所对应的设备只能得到大周期的慢速诊断，如分钟级的诊断周期(可配置)。当策略A存在时，策略B只占据小部分的链路通信次数。
其中，无论策略A还是策略B，当需要通过Drv-Peer发送时，一律通过LinkSync转发给Drv-Peer。其中，快速和慢速是相对概念，即策略A对应的轮询周期小于策略B对应的轮询周期；可选地，策略B对应的轮询周期是策略A对应的轮询周期的N倍，N为大于1的自然数。
实施例三
如图6所示，一种冗余主站链路冲突模式下设备通信的系统，其特征在于，包括：
一台主机(FEP-A)、另一台主机(FEP-B)和至少两台设备(Dev1,Dev2)；其中，所述一台主机和所述另一台主机互为冗余，构成所述冗余主站，所述至少两台设备为从站；
在冗余主站链路冲突模式下，当串行总线链路下的所述至少两台设备出现交叉故障时，所述一台主机和所述另一台主机对所述串行总线链路下所有可以与其中任意一台主机正常通信的每一台设备分别按照以下方式执行轮询策略：
当该设备在两台主机上所映射的两个虚拟设备中的实际主设备在线时，对该实际主设备执行第一轮询策略，对两个虚拟设备中的实际从设备执行第二轮询策略；
当该设备在两台主机上所映射的两个虚拟设备中的实际主设备不在线，且实际从设备在线时，对实际从设备执行第一轮询策略，对实际主设备执行第二轮询策略。
可选地，其中，所述一台主机和所述另一台主机对所述串行总线链路下所有可以与其中任意一台主机正常通信的每一台设备还执行以下轮询策略：
当该设备在两台主机上所映射的两个虚拟设备中的实际主设备和实际从设备均不在线时，如果所述串行总线链路下至少有一个设备在线，则对实际主设备和实际从设备都执行第二轮询策略；如果所述串行总线链路下其他设备都不在线时，则对实际主设备和实际从设备都执行第一轮询策略。
可选地，如图7所示，冗余主机(FEP-A\FEP-B)和设备之间接入网络转串口的适配器，由于设备层为串口单通道的属性没有改变，从而并不改变冗余主站链路冲突模式的特性。
可选地，其中，所述第一轮询策略对应的轮询周期小于所述第二轮询策略对应的轮询周期。
可选地，其中，所有虚拟设备的实际主从与对应链路的实际主从保持一致，包括：
当所述虚拟设备对应的链路为实际主链路时，所述虚拟设备无论在线与否，都为实际主；当所述虚拟设备对应的链路为实际从链路时，所述虚拟设备无论在线与否，都为实际从。
可选地，其中，实际主链路和实际从链路通过比较冗余主机各自的链路有效权重(LEW)确定，所述LEW的计算公式如下：
其中，n表示该链路下虚拟设备总个数；Wi表示虚拟设备i的权重值，Si表示虚拟设备i的在线状态，1表示虚拟设备在线，0表示虚拟设备不在线；
当冗余主站中一台主机A的链路有效权重LEW-A＞另一台主机B的链路有效权重LEW-B时，所述一台主机A对应的链路为实际主链路，所述另一台主机B对应的链路为实际从链路；
当LEW-B＞LEW-A时，所述另一台主机B对应的链路为实际主链路，所述一台主机A对应的链路为实际从链路；
当LEW-A＝LEW-B时，根据预定规则确定冗余主站中两台主机对应的链路中的实际主链路和实际从链路。
可选地，其中，所述根据预定规则确定冗余主站中两台主机对应的链路中的实际主链路和实际从链路，包括：
如果存在默认主优先原则，则所述一台主机A和所述另一台主机B中默认主的一方所对应的链路为实际主链路，默认从的一方所对应的链路为实际从链路；如果没有默认主优先原则，若当前已经有一方对应的链路为实际主链路，则不改变当前状态，若当前没有任何一方对应的链路为实际主链路，则所述一台主机A对应的链路为实际主链路，所述另一台主机B对应的链路为实际从链路。
可选地，对于所述串行总线链路下的每一台设备，如果该设备在一台主机上映射的虚拟设备为Unit，在另一台主机上映射的虚拟设备为Unit-Peer，则所述Unit和所述Unit-Peer中的一个为实际主设备，另一个为实际从设备；
所述方法还包括：驱动根据自己的链路实际主从状态执行如下策略：
当所述驱动判断所对应的链路为实际主链路时，
所述驱动以本链路对应主机的设备状态和另一主机的设备状态为输入参数，调用请求生成算法，获取当前需要发送的请求；
如果获取的需要发送的请求是本机驱动请求，则所述驱动发送请求给目标设备并启动接收超时定时器，记录第一超时时间TimeOut1；当所述驱动从设备收到应答报文后，处理报文，根据应答报文所对应的设备，更新对应Unit本地实时数据库，并更新对应Unit为在线状态；
如果获取的需要发送的请求是另机驱动请求，则通过链路同步管理功能发送给另机驱动并启动接收超时定时器，记录第二超时时间TimeOutPeer，其中所述TimeOutPeer＝TimeOut1+δT，δT为两次链路同步管理在所述一台主机和所述另一台主机之间传输所需的实际最大时间；当收到所述另机驱动返回的回执或者应答时，终止本次超时；
其中，所述驱动是指所述一台主机中完成对应链路下所有设备通信的软件单元；所述另机驱动是指所述另一台主机中完成对应链路下所有设备通信的软件单元。
可选地，对于所述串行总线链路下的每一台设备，如果该设备在一台主机上映射的虚拟设备为Unit，在另一台主机上映射的虚拟设备为Unit-Peer，则所述Unit和所述Unit-Peer中的一个为实际主设备，另一个为实际从设备；
所述方法还包括：驱动根据所对应的链路实际主从状态执行如下策略：
当所述驱动判断自己的链路为实际从链路时，
调用链路同步管理功能，如果没有收到请求，则结束处理；
如果有收到请求，则所述驱动发送请求给目标设备并启动接收超时定时器，记录第三超时时间TimeOut3；所述驱动收到设备应答后，根据应答报文所对应的设备，更新对应Unit为在线状态；如果对应的Unit-Peer不在线，则处理报文，更新对应Unit本地实时数据库，并给另机驱动发送回执；如果对应的Unit-Peer在线，则把所述设备应答作为响应通过链路同步管理功能转发给另机驱动；
其中，所述驱动是指所述一台主机中完成对应链路下所有设备通信的软件单元；所述另机驱动是指所述另一台主机中完成对应链路下所有设备通信的软件单元。
本发明针对冗余主站在链路冲突模式下，在同一链路中的设备出现交叉故障时，采用上述方案确保该链路下所有综合通信正常的设备均能被执行均等的轮询机会，获得快速通信机会，确保各综合通信正常的设备通信的实时性。
本领域普通技术人员可以理解上述实施例的全部或部分步骤可以使用计算机程序流程来实现，所述计算机程序可以存储于一计算机可读存储介质中，所述计算机程序在相应的硬件平台上(如系统、设备、装置、器件等)执行，在执行时，包括方法实施例的步骤之一或其组合。
可选地，上述实施例的全部或部分步骤也可以使用集成电路来实现，这些步骤可以被分别制作成一个个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。
上述实施例中的各装置/功能模块/功能单元可以采用通用的计算装置来实现，它们可以集中在单个的计算装置上，也可以分布在多个计算装置所组成的网络上。
上述实施例中的各装置/功能模块/功能单元以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。上述提到的计算机可读取存储介质可以是只读存储器，磁盘或光盘等。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求所述的保护范围为准。
Claims (10)
1.一种冗余主站链路冲突模式下设备通信方法，其特征在于，包括：
在冗余主站链路冲突模式下，当串行总线链路下的设备出现交叉故障时，对所述串行总线链路下所有可以与所述冗余主站中任意一台主机正常通信的每一台设备分别按照以下方式执行轮询策略：
当该设备在两台主机上所映射的两个虚拟设备中的实际主设备在线时，对该实际主设备执行第一轮询策略，对两个虚拟设备中的实际从设备执行第二轮询策略；
当该设备在两台主机上所映射的两个虚拟设备中的实际主设备不在线，且实际从设备在线时，对实际从设备执行第一轮询策略，对实际主设备执行第二轮询策略；
其中，冗余主站包括：互为冗余的两台主机。
2.根据权利要求1所述的方法，其特征在于，
所述对所述串行总线链路下所有可以与所述冗余主站中任意一台主机正常通信的每一台设备还执行以下轮询策略：
当该设备在两台主机上所映射的两个虚拟设备中的实际主设备和实际从设备均不在线时，如果所述串行总线链路下至少有一个设备在线，则对实际主设备和实际从设备都执行第二轮询策略；如果所述串行总线链路下其他设备都不在线时，则对实际主设备和实际从设备都执行第一轮询策略。
3.根据权利要求1或2所述的方法，其特征在于，
其中，所述第一轮询策略对应的轮询周期小于所述第二轮询策略对应的轮询周期。
4.根据权利要求1或2所述的方法，其特征在于，
其中，所有虚拟设备的实际主从与对应链路的实际主从保持一致，包括：
当所述虚拟设备对应的链路为实际主链路时，所述虚拟设备无论在线与否，都为实际主；当所述虚拟设备对应的链路为实际从链路时，所述虚拟设备无论在线与否，都为实际从。
5.根据权利要求4所述的方法，其特征在于，
其中，实际主链路和实际从链路通过比较冗余主机各自的链路有效权重(LEW)确定，所述LEW的计算公式如下：
其中，n表示该链路下虚拟设备总个数；Wi表示虚拟设备i的权重值，Si表示虚拟设备i的在线状态，1表示虚拟设备在线，0表示虚拟设备不在线；
当冗余主站中一台主机A的链路有效权重LEW-A＞另一台主机B的链路有效权重LEW-B时，所述一台主机A对应的链路为实际主链路，所述另一台主机B对应的链路为实际从链路；
当LEW-B＞LEW-A时，所述另一台主机B对应的链路为实际主链路，所述一台主机A对应的链路为实际从链路；
当LEW-A＝LEW-B时，根据预定规则确定冗余主站中两台主机对应的链路中的实际主链路和实际从链路。
6.根据权利要求5所述的方法，其特征在于，
其中，所述根据预定规则确定冗余主站中两台主机对应的链路中的实际主链路和实际从链路，包括：
如果存在默认主优先原则，则所述一台主机A和所述另一台主机B中默认主的一方所对应的链路为实际主链路，默认从的一方所对应的链路为实际从链路；如果没有默认主优先原则，若当前已经有一方对应的链路为实际主链路，则不改变当前状态，若当前没有任何一方对应的链路为实际主链路，则所述一台主机A对应的链路为实际主链路，所述另一台主机B对应的链路为实际从链路。
7.根据权利要求1或2所述的方法，其特征在于，
对于所述串行总线链路下的每一台设备，如果该设备在一台主机上映射的虚拟设备为Unit，在另一台主机上映射的虚拟设备为Unit-Peer，则所述Unit和所述Unit-Peer中的一个为实际主设备，另一个为实际从设备；
所述方法还包括：驱动根据自己的链路实际主从状态执行如下策略：
当所述驱动判断所对应的链路为实际主链路时，
所述驱动以本链路对应主机的设备状态和另一主机的设备状态为输入参数，调用请求生成算法，获取当前需要发送的请求；
如果获取的需要发送的请求是本机驱动请求，则所述驱动发送请求给目标设备并启动接收超时定时器，记录第一超时时间TimeOut1；当所述驱动从设备收到应答报文后，处理报文，根据应答报文所对应的设备，更新对应Unit本地实时数据库，并更新对应Unit为在线状态；
如果获取的需要发送的请求是另机驱动请求，则通过链路同步管理功能发送给另机驱动并启动接收超时定时器，记录第二超时时间TimeOutPeer，其中所述TimeOutPeer＝TimeOut1+δT，δT为两次链路同步管理在所述一台主机和所述另一台主机之间传输所需的实际最大时间；当收到所述另机驱动返回的回执或者应答时，终止本次超时；
其中，所述驱动是指所述一台主机中完成对应链路下所有设备通信的软件单元；所述另机驱动是指所述另一台主机中完成对应链路下所有设备通信的软件单元。
8.根据权利要求1或2所述的方法，其特征在于，
对于所述串行总线链路下的每一台设备，如果该设备在一台主机上映射的虚拟设备为Unit，在另一台主机上映射的虚拟设备为Unit-Peer，则所述Unit和所述Unit-Peer中的一个为实际主设备，另一个为实际从设备；
所述方法还包括：驱动根据所对应的链路实际主从状态执行如下策略：
当所述驱动判断自己的链路为实际从链路时，
调用链路同步管理功能，如果没有收到请求，则结束处理；
如果有收到请求，则所述驱动发送请求给目标设备并启动接收超时定时器，记录第三超时时间TimeOut3；所述驱动收到设备应答后，根据应答报文所对应的设备，更新对应Unit为在线状态；如果对应的Unit-Peer不在线，则处理报文，更新对应Unit本地实时数据库，并给另机驱动发送回执；如果对应的Unit-Peer在线，则把所述设备应答作为响应通过链路同步管理功能转发给另机驱动；
其中，所述驱动是指所述一台主机中完成对应链路下所有设备通信的软件单元；所述另机驱动是指所述另一台主机中完成对应链路下所有设备通信的软件单元。
9.一种冗余主站链路冲突模式下设备通信的系统，其特征在于，包括：
一台主机、另一台主机和至少两台设备；其中，所述一台主机和所述另一台主机互为冗余，构成所述冗余主站，所述至少两台设备为从站；
在冗余主站链路冲突模式下，当串行总线链路下的所述至少两台设备出现交叉故障时，所述一台主机和所述另一台主机对所述串行总线链路下所有可以与其中任意一台主机正常通信的每一台设备分别按照以下方式执行轮询策略：
当该设备在两台主机上所映射的两个虚拟设备中的实际主设备在线时，对该实际主设备执行第一轮询策略，对两个虚拟设备中的实际从设备执行第二轮询策略；
当该设备在两台主机上所映射的两个虚拟设备中的实际主设备不在线，且实际从设备在线时，对实际从设备执行第一轮询策略，对实际主设备执行第二轮询策略。
10.根据权利要求9所述的系统，其特征在于，
其中，所述一台主机和所述另一台主机对所述串行总线链路下所有可以与其中任意一台主机正常通信的每一台设备还执行以下轮询策略：
当该设备在两台主机上所映射的两个虚拟设备中的实际主设备和实际从设备均不在线时，如果所述串行总线链路下至少有一个设备在线，则对实际主设备和实际从设备都执行第二轮询策略；如果所述串行总线链路下其他设备都不在线时，则对实际主设备和实际从设备都执行第一轮询策略。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911393669.0A CN111159089B (zh) | 2019-12-30 | 2019-12-30 | 一种冗余主机链路冲突模式下设备通信方法和系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911393669.0A CN111159089B (zh) | 2019-12-30 | 2019-12-30 | 一种冗余主机链路冲突模式下设备通信方法和系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111159089A true CN111159089A (zh) | 2020-05-15 |
| CN111159089B CN111159089B (zh) | 2022-03-29 |
Family
ID=70559053
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911393669.0A Active CN111159089B (zh) | 2019-12-30 | 2019-12-30 | 一种冗余主机链路冲突模式下设备通信方法和系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111159089B (zh) |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6006017A (en) * | 1995-05-02 | 1999-12-21 | Motorola Inc. | System for determining the frequency of repetitions of polling active stations relative to the polling of inactive stations |
| CN1753377A (zh) * | 2005-11-04 | 2006-03-29 | 北京和利时系统工程股份有限公司 | 一种避免冗余主站对串行总线链路访问冲突的方法 |
| EP1731977A2 (en) * | 2005-06-09 | 2006-12-13 | Omron Corporation | Communication master station startup period control method |
| CN101079781A (zh) * | 2007-02-01 | 2007-11-28 | 北京东土科技股份有限公司 | 一种工业以太网快速冗余的实现方法 |
| CN101751020A (zh) * | 2008-12-17 | 2010-06-23 | 中国科学院沈阳自动化研究所 | 一种高可用性功能块冗余方法 |
| CN107528747A (zh) * | 2017-06-28 | 2017-12-29 | 北京和利时系统工程有限公司 | 一种诊断方法和装置及计算机可读存储介质 |
| KR101895948B1 (ko) * | 2016-09-02 | 2018-09-06 | 한전케이디엔 주식회사 | 원격 검침 시 상호 간의 fep 서버들에 의한 이중화 구현 방법 |
| CN109597723A (zh) * | 2018-11-26 | 2019-04-09 | 南京轨道交通系统工程有限公司 | 用于地铁综合监控系统的双机热备冗余实现系统及方法 |
| CN110287135A (zh) * | 2019-06-14 | 2019-09-27 | 北京和利时系统工程有限公司 | 一种总线轮询方法和装置 |
-
2019
- 2019-12-30 CN CN201911393669.0A patent/CN111159089B/zh active Active
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6006017A (en) * | 1995-05-02 | 1999-12-21 | Motorola Inc. | System for determining the frequency of repetitions of polling active stations relative to the polling of inactive stations |
| EP1731977A2 (en) * | 2005-06-09 | 2006-12-13 | Omron Corporation | Communication master station startup period control method |
| CN1753377A (zh) * | 2005-11-04 | 2006-03-29 | 北京和利时系统工程股份有限公司 | 一种避免冗余主站对串行总线链路访问冲突的方法 |
| CN101079781A (zh) * | 2007-02-01 | 2007-11-28 | 北京东土科技股份有限公司 | 一种工业以太网快速冗余的实现方法 |
| CN101751020A (zh) * | 2008-12-17 | 2010-06-23 | 中国科学院沈阳自动化研究所 | 一种高可用性功能块冗余方法 |
| KR101895948B1 (ko) * | 2016-09-02 | 2018-09-06 | 한전케이디엔 주식회사 | 원격 검침 시 상호 간의 fep 서버들에 의한 이중화 구현 방법 |
| CN107528747A (zh) * | 2017-06-28 | 2017-12-29 | 北京和利时系统工程有限公司 | 一种诊断方法和装置及计算机可读存储介质 |
| CN109597723A (zh) * | 2018-11-26 | 2019-04-09 | 南京轨道交通系统工程有限公司 | 用于地铁综合监控系统的双机热备冗余实现系统及方法 |
| CN110287135A (zh) * | 2019-06-14 | 2019-09-27 | 北京和利时系统工程有限公司 | 一种总线轮询方法和装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111159089B (zh) | 2022-03-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN115550191A (zh) | IoT云到云架构 | |
| CN109391655A (zh) | 服务灰度发布方法、装置、系统及存储介质 | |
| CN110580235B (zh) | 一种sas扩展器通信方法及装置 | |
| US9985893B2 (en) | Load sharing method and apparatus, and board | |
| EP2597818A1 (en) | Cluster management system and method | |
| CN112994981B (zh) | 时延数据的调整方法和装置、电子设备和存储介质 | |
| CN114285695B (zh) | 通信方法、装置、设备、系统和存储介质 | |
| CN107948063B (zh) | 一种建立聚合链路的方法和接入设备 | |
| CN108418859B (zh) | 写数据的方法和装置 | |
| US11005680B2 (en) | Reprogramming apparatus for vehicle, reprogramming method thereof, and vehicle including the same | |
| CN106230622A (zh) | 一种集群实现方法及装置 | |
| CN111159089B (zh) | 一种冗余主机链路冲突模式下设备通信方法和系统 | |
| US20130138856A1 (en) | Method and apparatus for node hot-swapping | |
| CN108667640B (zh) | 通信方法及设备、网络接入系统 | |
| CN113810216A (zh) | 一种集群的故障切换方法、装置及电子设备 | |
| JP2019097088A (ja) | シリアル通信システム | |
| CN114553900B (zh) | 一种分布式块存储管理系统、方法及电子设备 | |
| US9967163B2 (en) | Message system for avoiding processing-performance decline | |
| CN109542833A (zh) | 一种基于微服务器架构的服务器管理方法、装置、服务器 | |
| CN102118389B (zh) | 一种通过iSCSI多路径访问存储设备的方法和一种存储设备 | |
| CN104683153B (zh) | 一种集群路由器主备mpu控制方法及其系统 | |
| CN104301240B (zh) | 数据传输方法及系统 | |
| CN110166506B (zh) | 超文本传输协议Http的连接方法及节点设备 | |
| CN113919511A (zh) | 联邦学习方法及装置 | |
| CN111324492B (zh) | 一种冗余主机链路冲突模式下的诊断及切换方法和装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20211124 Address after: 100176 room 3412, floor 4, building 3, yard 2, Desheng Middle Road, Beijing Economic and Technological Development Zone, Daxing District, Beijing Applicant after: Beijing Helishi system integration Co.,Ltd. Address before: 100176 No.2, Disheng Middle Road, Yizhuang Economic and Technological Development Zone, Daxing District, Beijing Applicant before: BEIJING HOLLYSYS Co.,Ltd. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |