Multi-center redundant arbitration method and system based on SCADA system

Abstract

The present invention provides a multi-center redundant arbitration method and system based on a SCADA system, including: a server allocation sequence number step: the server will be allocated a sequence number according to the priority; a master-slave switching step: the active node is switched according to the priority of the server sequence number, and the server with a higher priority is selected as the current active node; at the same time, all inactive nodes will count the received heartbeats, and a voting request will be initiated to all nodes after a delay, and a new active node will be selected. The present invention uses a reliable third party to perform arbitration, so that when the redundant network card goes offline, the multi-network card server can determine that it is the local machine that goes offline instead of the active node, thereby maintaining the inactive node and avoiding the related services from affecting the applications of other servers through the remaining network cards due to the change of the redundant state.

Description

Technical Field

[0001] The present invention relates to the field of redundancy judgment of monitoring systems, and in particular to a multi-center redundancy arbitration method and system based on a SCADA system. Background Art

[0002] With the rapid development of industrial automation, higher requirements are placed on the reliability of production equipment. People hope to improve hardware reliability while having more reliable solutions to meet the requirements of control system reliability in the field of industrial communication control. The redundant hot standby system based on network control is currently a more reliable control system. This system usually uses two servers, one server as the main server and the other as the slave server. Under normal circumstances, the main server executes the program and controls the I / O devices, and the slave server continuously monitors the status of the main server. If the main server fails, the slave server immediately takes over the control of the I / O and continues to execute the program, thereby realizing redundant hot standby control of the system.

[0003] However, the redundant design based on two servers still has hidden dangers. In order to ensure the stability and reliability of the communication network, people have developed a redundant design with three or more servers (such as Google's ETCD algorithm). The selection of the main server, that is, the main selection mode, is as follows:

[0004] A group of service nodes form a cluster, and there is a master node to provide external services. When the cluster is initialized or the master node hangs up, a master election is required. Each node in the cluster is in one of the three roles of Leader, Follower, and Candidate at any time. The election features are as follows:

[0005] When the cluster is initialized, each node plays the role of Follower;

[0006] There is at most one valid master node in the cluster, which synchronizes data with other nodes through heartbeats;

[0007] If a Follower does not receive a heartbeat from the master node within a certain period of time, it will change its role to Candidate and initiate a vote to elect a master. If more than half of the nodes, including itself, agree, the election is successful. If less than half of the votes are received, the election fails, or the election times out. If the master node is not elected in this round, the next round of elections will be held (this happens because multiple nodes are elected at the same time, and all nodes have received more than half of the votes).

[0008] After the Candidate node receives the information from the master node, it will immediately terminate the election process and enter the Follower role.

[0009] To avoid a loop of failed leader elections, the time each node takes to initiate an election without receiving a heartbeat is a random value within a certain range. This can prevent two nodes from initiating leader elections at the same time.

[0010] Since the voting system may cause the problem of never electing a leader in some cases (for example, when the heartbeat between all servers is unavailable), a new method is needed to determine the leader server. Summary of the invention

[0011] In view of the defects in the prior art, the object of the present invention is to provide a multi-center redundant arbitration method and system based on the SCADA system.

[0012] A multi-center redundant arbitration method based on a SCADA system provided by the present invention includes:

[0013] Server assigns serial number steps: The server will assign serial numbers according to priority;

[0014] Active / standby switching steps: switch the active node according to the priority of the server serial number, and select the server with higher priority as the current active node; at the same time, all inactive nodes will count the received heartbeats, and initiate a voting request to all nodes after a delay to vote and select a new active node.

[0015] Preferably, the server serial number starts from 1, and the smaller the number, the higher the priority. The server with a higher priority is more likely to become the active node during the active-standby switch;

[0016] All servers are divided into four states:

[0017] Active Node: Only servers in the active node state will provide services;

[0018] Inactive nodes: Servers in inactive node status do not provide services;

[0019] Candidate: When an inactive node initiates a vote, it becomes a candidate and changes to other states based on the election results, and does not provide services;

[0020] Locked: When an inactive node receives a voting request, it becomes locked and changes to other states based on the election results, and does not provide services;

[0021] The message types between all servers are as follows:

[0022] Heartbeat messages are used by inactive nodes to confirm the status of active nodes;

[0023] Heartbeat reply message, used by the active node to confirm whether there is a heartbeat conflict;

[0024] Voting request message, used to ask other nodes whether they agree with the election;

[0025] Voting request reply message, used to approve or disapprove of an election initiated by a certain node;

[0026] Notification message, used to notify other nodes to change the currently considered active node sequence number.

[0027] Preferably, the active / standby switching step includes:

[0028] Heartbeat information sending step: the active node sends a heartbeat message to all other servers through the TCP protocol, and the content of the heartbeat message includes the sequence number of the current active node and the sequence number of the heartbeat message sent;

[0029] Node sequence comparison step: After all nodes receive the heartbeat message, they compare the active node sequence number of the message with the sequence number of the locally considered active node, and select the node with the higher priority as the current active node;

[0030] Node election step: All inactive nodes count the received heartbeats, initially 0. If no heartbeat message is received within the first preset time, the count is increased by 1. When the count reaches the preset count threshold, the inactive node considers the active node offline. After waiting for the second preset time multiplied by the local serial number, it initiates a voting request to all nodes, and the local state is set to candidate.

[0031] Voting result waiting step: After the server status changes to candidate, wait for the voting result, and end the waiting when it meets the preset conditions;

[0032] Node status change step: After the server finishes waiting in the candidate state, it determines whether it has received a voting request reply message and no objection message: if so, the state is set to an active node and the notification message sending step continues; otherwise, the state is set to an inactive node;

[0033] Notification message sending step: After the candidate becomes the active node, it sends a notification message to all other nodes, with the content being the serial number of the active node;

[0034] Active node status change steps: When the active node receives a notification message, it determines the priority of the local and message content sequence numbers. If the message content is higher, the local state is set to an inactive node and the sequence number of the active node is changed to the message content. If the local priority is higher, the state is not changed and the notification message is replied with the local sequence number.

[0035] Steps for changing the candidate or locked state: When the server receives a notification message in the candidate or locked state, it sets the state to an inactive node and changes the sequence number of the considered active node to the sequence number in the message content;

[0036] Inactive node status change steps: When the server receives a notification message in the inactive node state, it determines the priority of the local active node sequence number and compares it with the sequence number in the notification message content. If the sequence number in the message content is higher, the local active node sequence number is changed to the message content. If the local active node priority is higher, it only replies to the notification message with the content of the local active node sequence number.

[0037] Count judgment step: After receiving the voting request, the inactive node determines whether the count of the node election step has reached the preset count threshold. If it has reached it, it replies to agree, and after replying to agree, its own status is set to locked state; if it has not reached it, it replies to disagree;

[0038] In the locked state, all voting requests received will be replied with "no". Any heartbeat message received will set the state to an inactive node. The local active node sequence number will be changed according to the content of the heartbeat message. If no heartbeat message is received within the fourth preset time from the time the locked state is changed, the state will be set back to an inactive node and the heartbeat count will be reset to zero.

[0039] Preferably, the voting result waiting step:

[0040] The preset conditions include:

[0041] Any node replies to the message of opposing the vote;

[0042] The number of reply voting messages is equal to the number of all nodes minus 1;

[0043] The waiting time reaches the third preset time;

[0044] Received a voting request from a higher priority node, replied with approval and entered the locked state;

[0045] Received a heartbeat message from any machine;

[0046] Received a notification message from any machine.

[0047] Preferably, the node status changing step;

[0048] After the server finishes waiting in the candidate state, if it receives a reply message to the voting request and there is no objection message, it sets the state to the active node and enters the notification message sending step to continue execution;

[0049] If a voting request reply message has been received and there are more than or equal to 1 opposing messages, the status will be set to an inactive node;

[0050] If no voting reply is received, a ping request is sent to a reliable third-party node: if the ping is successful, the status is set to an active node; if the ping is unsuccessful, the status is set to an inactive node.

[0051] Preferably, the node sequence comparison step:

[0052] After all nodes receive the heartbeat message, they will first compare the sequence number of the active node in the message with the sequence number of the locally considered active node:

[0053] If they are consistent, the heartbeat is replied with the content of the currently considered active node and the sequence number of the heartbeat reply message sent; if they are inconsistent, the priorities are compared: if the active node contained in the received heartbeat message has a higher priority, the locally considered active node is changed to the active node sequence number in the heartbeat message, and then a heartbeat reply message is sent;

[0054] If the active node contained in the received heartbeat message has a lower priority, a reply message will be sent to request the heartbeat sender to change the currently considered active node.

[0055] A multi-center redundant arbitration system based on a SCADA system is provided according to the present invention, comprising:

[0056] Server allocation sequence number module: the server will be allocated sequence numbers according to the priority;

[0057] Active / standby switching module: switches the active node according to the priority of the server serial number, and selects the server with higher priority as the current active node; at the same time, all inactive nodes will count the received heartbeats, and initiate voting requests to all nodes after a delay to vote and select a new active node.

[0058] Preferably, the server serial number starts from 1, and the smaller the number, the higher the priority. The server with a higher priority is more likely to become the active node during the active-standby switch;

[0059] All servers are divided into four states:

[0060] Active Node: Only servers in the active node state will provide services;

[0061] Inactive nodes: Servers in inactive node status do not provide services;

[0062] Candidate: When an inactive node initiates a vote, it becomes a candidate and changes to other states based on the election results, and does not provide services;

[0063] Locked: When an inactive node receives a voting request, it becomes locked and changes to other states based on the election results, and does not provide services;

[0064] The message types between all servers are as follows:

[0065] Heartbeat messages are used by inactive nodes to confirm the status of active nodes;

[0066] Heartbeat reply message, used by the active node to confirm whether there is a heartbeat conflict;

[0067] Voting request message, used to ask other nodes whether they agree with the election;

[0068] Voting request reply message, used to approve or disapprove of an election initiated by a certain node;

[0069] Notification message, used to notify other nodes to change the currently considered active node sequence number.

[0070] Preferably, the active / standby switching module comprises:

[0071] Heartbeat information sending module: The active node sends a heartbeat message to all other servers through the TCP protocol. The heartbeat message content includes the sequence number of the current active node and the sequence number of the heartbeat message sent;

[0072] Node sequence comparison module: After all nodes receive the heartbeat message, they compare the sequence number of the active node in the message with the sequence number of the locally considered active node, and select the node with higher priority as the current active node;

[0073] Node election module: All inactive nodes count the received heartbeats, initially 0. If no heartbeat message is received within the first preset time, the count is increased by 1. When the count reaches the preset count threshold, the inactive node considers the active node offline. After waiting for the second preset time multiplied by the local serial number, it initiates a voting request to all nodes, and the local status is set to candidate.

[0074] Voting result waiting module: after the server status changes to candidate, wait for voting results, and end the waiting when the preset conditions are met;

[0075] Node status change module: After the server finishes waiting in the candidate state, it determines whether it has received a voting request reply message and no objection message: if so, the state is set to an active node and the notification message sending module is called; otherwise, the state is set to an inactive node;

[0076] Notification message sending module: After a candidate becomes an active node, it sends a notification message to all other nodes, with the content being the serial number of the active node;

[0077] Active node status change module: When an active node receives a notification message, it determines the priority of the local and message content serial numbers. If the message content is higher, the local state is set to an inactive node and the considered active node serial number is changed to the message content. If the local priority is higher, the state is not changed and a notification message is replied with the local serial number.

[0078] Candidate or lock status change module: When the server receives a notification message in the candidate or lock state, it sets the state to an inactive node and changes the sequence number of the considered active node to the sequence number in the message content;

[0079] Inactive node status change module: When the server receives a notification message in the inactive node state, it determines the priority of the local active node sequence number and compares it with the sequence number in the notification message content. If the sequence number in the message content is higher, the local active node sequence number is changed to the message content. If the local active node priority is higher, it only replies to the notification message with the content of the local active node sequence number.

[0080] Count judgment module: After receiving the voting request, the inactive node judges whether the count of the node election module has reached the preset count threshold. If it has reached the preset count threshold, the inactive node replies "yes" and sets its own status to locked status. If it has not reached the preset count threshold, the inactive node replies "no";

[0081] In the locked state, all voting requests received will be replied with "no". Any heartbeat message received will set the state to an inactive node. The local active node sequence number will be changed according to the content of the heartbeat message. If no heartbeat message is received within the fourth preset time from the time the locked state is changed, the state will be set back to an inactive node and the heartbeat count will be reset to zero.

[0082] Preferably, the voting result waiting module:

[0083] The preset conditions include:

[0084] Any node replies to the message of opposing the vote;

[0085] The number of reply voting messages is equal to the number of all nodes minus 1;

[0086] The waiting time reaches the third preset time;

[0087] Received a voting request from a higher priority node, replied with approval and entered the locked state;

[0088] Received a heartbeat message from any machine;

[0089] Received a notification message from any machine;

[0090] The node status changing module;

[0091] After the server finishes waiting in the candidate state, if it receives a reply message to the voting request and there is no objection message, it sets the state to the active node and calls the notification message sending module;

[0092] If a voting request reply message has been received and there are more than or equal to 1 opposing messages, the status will be set to an inactive node;

[0093] If no voting reply is received, a ping request is sent to a reliable third-party node: if the ping is successful, the status is set to an active node; if the ping is unsuccessful, the status is set to an inactive node;

[0094] The node sequence comparison module:

[0095] After all nodes receive the heartbeat message, they will first compare the sequence number of the active node in the message with the sequence number of the locally considered active node:

[0096] If they are consistent, the heartbeat is replied with the content of the currently considered active node and the sequence number of the heartbeat reply message sent; if they are inconsistent, the priorities are compared: if the active node contained in the received heartbeat message has a higher priority, the locally considered active node is changed to the active node sequence number in the heartbeat message, and then a heartbeat reply message is sent;

[0097] If the active node contained in the received heartbeat message has a lower priority, a reply message will be sent to request the heartbeat sender to change the currently considered active node.

[0098] Compared with the prior art, the present invention has the following beneficial effects:

[0099] 1. The present invention solves the problem in the prior art that a Leader can never be elected in certain circumstances due to the voting system.

[0100] 2. The priority setting of the present invention allows the user to set the order in which inactive nodes become active nodes according to the server performance, thereby making full use of the performance of the hardware device.

[0101] 3. The present invention utilizes a reliable third party to perform arbitration, so that when a redundant network card goes offline, the multi-network card server can determine that it is the local machine that is offline rather than the active node, thereby maintaining the inactive node and avoiding the related services affecting the applications of other servers through the remaining network cards due to the change of the redundant status. BRIEF DESCRIPTION OF THE DRAWINGS

[0102] Other features, objects and advantages of the present invention will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings:

[0103] Figure 1 A schematic diagram of the process flow of an inactive node provided by the present invention when the heartbeat is not connected.

[0104] Figure 2 A schematic diagram of a state machine provided by the present invention. DETAILED DESCRIPTION

[0105] The present invention is described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but are not intended to limit the present invention in any form. It should be noted that, for those of ordinary skill in the art, several changes and improvements can also be made without departing from the concept of the present invention. These all belong to the protection scope of the present invention.

[0106] A multi-center redundant arbitration method based on a SCADA system provided by the present invention includes:

[0107] Server assigns serial number steps: The server will assign serial numbers according to priority;

[0108] Active / standby switching steps: switch the active node according to the priority of the server serial number, and select the server with higher priority as the current active node; at the same time, all inactive nodes will count the received heartbeats, and initiate a voting request to all nodes after a delay to vote and select a new active node.

[0109] Specifically, the server serial number starts from 1, and the smaller the number, the higher the priority. The server with a higher priority is more likely to become the active node during the active-standby switch;

[0110] All servers are divided into four states:

[0111] Active Node: Only servers in the active node state will provide services;

[0112] Inactive nodes: Servers in inactive node status do not provide services;

[0113] Candidate: When an inactive node initiates a vote, it becomes a candidate and changes to other states based on the election results, and does not provide services;

[0114] Locked: When an inactive node receives a voting request, it becomes locked and changes to other states based on the election results, and does not provide services;

[0115] The message types between all servers are as follows:

[0116] Heartbeat messages are used by inactive nodes to confirm the status of active nodes;

[0117] Heartbeat reply message, used by the active node to confirm whether there is a heartbeat conflict;

[0118] Voting request message, used to ask other nodes whether they agree with the election;

[0119] Voting request reply message, used to approve or disapprove of an election initiated by a certain node;

[0120] Notification message, used to notify other nodes to change the currently considered active node sequence number.

[0121] Specifically, the active / standby switching step includes:

[0122] Heartbeat information sending step: the active node sends a heartbeat message to all other servers through the TCP protocol, and the content of the heartbeat message includes the sequence number of the current active node and the sequence number of the heartbeat message sent;

[0123] Node sequence comparison step: After all nodes receive the heartbeat message, they compare the active node sequence number of the message with the sequence number of the locally considered active node, and select the node with the higher priority as the current active node;

[0124] Node election step: All inactive nodes count the received heartbeats, initially 0. If no heartbeat message is received within the first preset time, the count is increased by 1. When the count reaches the preset count threshold, the inactive node considers the active node offline. After waiting for the second preset time multiplied by the local serial number, it initiates a voting request to all nodes, and the local state is set to candidate.

[0125] Voting result waiting step: After the server status changes to candidate, wait for the voting result, and end the waiting when it meets the preset conditions;

[0126] Node status change step: After the server finishes waiting in the candidate state, it determines whether it has received a voting request reply message and no objection message: if so, the state is set to an active node and the notification message sending step continues; otherwise, the state is set to an inactive node;

[0127] Notification message sending step: After the candidate becomes the active node, it sends a notification message to all other nodes, with the content being the serial number of the active node;

[0128] Active node status change steps: When the active node receives a notification message, it determines the priority of the local and message content sequence numbers. If the message content is higher, the local state is set to an inactive node and the sequence number of the active node is changed to the message content. If the local priority is higher, the state is not changed and the notification message is replied with the local sequence number.

[0129] Steps for changing the candidate or locked state: When the server receives a notification message in the candidate or locked state, it sets the state to an inactive node and changes the sequence number of the considered active node to the sequence number in the message content;

[0130] Inactive node status change steps: When the server receives a notification message in the inactive node state, it determines the priority of the local active node sequence number and compares it with the sequence number in the notification message content. If the sequence number in the message content is higher, the local active node sequence number is changed to the message content. If the local active node priority is higher, it only replies to the notification message with the content of the local active node sequence number.

[0131] Count judgment step: After receiving the voting request, the inactive node determines whether the count of the node election step has reached the preset count threshold. If it has reached it, it replies to agree, and after replying to agree, its own status is set to locked state; if it has not reached it, it replies to disagree;

[0132] In the locked state, all voting requests received will be replied with "no". Any heartbeat message received will set the state to an inactive node. The local active node sequence number will be changed according to the content of the heartbeat message. If no heartbeat message is received within the fourth preset time from the time the locked state is changed, the state will be set back to an inactive node and the heartbeat count will be reset to zero.

[0133] Specifically, the voting result waiting step:

[0134] The preset conditions include:

[0135] Any node replies to the message of opposing the vote;

[0136] The number of reply voting messages is equal to the number of all nodes minus 1;

[0137] The waiting time reaches the third preset time;

[0138] Received a voting request from a higher priority node, replied with approval and entered the locked state;

[0139] Received a heartbeat message from any machine;

[0140] Received a notification message from any machine.

[0141] Specifically, the node status change step;

[0142] After the server finishes waiting in the candidate state, if it receives a reply message to the voting request and there is no objection message, it sets the state to the active node and enters the notification message sending step to continue execution;

[0143] If a voting request reply message has been received and there are more than or equal to 1 opposing messages, the status will be set to an inactive node;

[0144] If no voting reply is received, a ping request is sent to a reliable third-party node: if the ping is successful, the status is set to an active node; if the ping is unsuccessful, the status is set to an inactive node.

[0145] Specifically, the node sequence comparison step:

[0146] After all nodes receive the heartbeat message, they will first compare the sequence number of the active node in the message with the sequence number of the locally considered active node:

[0147] If they are consistent, the heartbeat is replied with the content of the currently considered active node and the sequence number of the heartbeat reply message sent; if they are inconsistent, the priorities are compared: if the active node contained in the received heartbeat message has a higher priority, the locally considered active node is changed to the active node sequence number in the heartbeat message, and then a heartbeat reply message is sent;

[0148] If the active node contained in the received heartbeat message has a lower priority, a reply message will be sent to request the heartbeat sender to change the currently considered active node.

[0149] A multi-center redundant arbitration system based on a SCADA system is provided according to the present invention, comprising:

[0150] Server allocation sequence number module: the server will be allocated sequence numbers according to the priority;

[0151] Active / standby switching module: switches the active node according to the priority of the server serial number, and selects the server with higher priority as the current active node; at the same time, all inactive nodes will count the received heartbeats, and initiate voting requests to all nodes after a delay to vote and select a new active node.

[0152] Specifically, the server serial number starts from 1, and the smaller the number, the higher the priority. The server with a higher priority is more likely to become the active node during the active-standby switch;

[0153] All servers are divided into four states:

[0154] Active Node: Only servers in the active node state will provide services;

[0155] Inactive nodes: Servers in inactive node status do not provide services;

[0156] Candidate: When an inactive node initiates a vote, it becomes a candidate and changes to other states based on the election results, and does not provide services;

[0157] Locked: When an inactive node receives a voting request, it becomes locked and changes to other states based on the election results, and does not provide services;

[0158] The message types between all servers are as follows:

[0159] Heartbeat messages are used by inactive nodes to confirm the status of active nodes;

[0160] Heartbeat reply message, used by the active node to confirm whether there is a heartbeat conflict;

[0161] Voting request message, used to ask other nodes whether they agree with the election;

[0162] Voting request reply message, used to approve or disapprove of an election initiated by a certain node;

[0163] Notification message, used to notify other nodes to change the currently considered active node sequence number.

[0164] Specifically, the active / standby switching module includes:

[0165] Heartbeat information sending module: The active node sends a heartbeat message to all other servers through the TCP protocol. The heartbeat message content includes the sequence number of the current active node and the sequence number of the heartbeat message sent;

[0166] Node sequence comparison module: After all nodes receive the heartbeat message, they compare the sequence number of the active node in the message with the sequence number of the locally considered active node, and select the node with higher priority as the current active node;

[0167] Node election module: All inactive nodes count the received heartbeats, initially 0. If no heartbeat message is received within the first preset time, the count is increased by 1. When the count reaches the preset count threshold, the inactive node considers the active node offline. After waiting for the second preset time multiplied by the local serial number, it initiates a voting request to all nodes, and the local status is set to candidate.

[0168] Voting result waiting module: after the server status changes to candidate, wait for voting results, and end the waiting when the preset conditions are met;

[0169] Node status change module: After the server finishes waiting in the candidate state, it determines whether it has received a voting request reply message and no objection message: if so, the state is set to an active node and the notification message sending module is called; otherwise, the state is set to an inactive node;

[0170] Notification message sending module: After a candidate becomes an active node, it sends a notification message to all other nodes, with the content being the serial number of the active node;

[0171] Active node status change module: When an active node receives a notification message, it determines the priority of the local and message content serial numbers. If the message content is higher, the local state is set to an inactive node and the considered active node serial number is changed to the message content. If the local priority is higher, the state is not changed and a notification message is replied with the local serial number.

[0172] Candidate or lock status change module: When the server receives a notification message in the candidate or lock state, it sets the state to an inactive node and changes the sequence number of the considered active node to the sequence number in the message content;

[0173] Inactive node status change module: When the server receives a notification message in the inactive node state, it determines the priority of the local active node sequence number and compares it with the sequence number in the notification message content. If the sequence number in the message content is higher, the local active node sequence number is changed to the message content. If the local active node priority is higher, it only replies to the notification message with the content of the local active node sequence number.

[0174] Count judgment module: After receiving the voting request, the inactive node judges whether the count of the node election module has reached the preset count threshold. If it has reached the preset count threshold, the inactive node replies "yes" and sets its own status to locked status. If it has not reached the preset count threshold, the inactive node replies "no";

[0175] In the locked state, all voting requests received will be replied with "no". Any heartbeat message received will set the state to an inactive node. The local active node sequence number will be changed according to the content of the heartbeat message. If no heartbeat message is received within the fourth preset time from the time the locked state is changed, the state will be set back to an inactive node and the heartbeat count will be reset to zero.

[0176] Specifically, the voting result waiting module:

[0177] The preset conditions include:

[0178] Any node replies to the message of opposing the vote;

[0179] The number of reply voting messages is equal to the number of all nodes minus 1;

[0180] The waiting time reaches the third preset time;

[0181] Received a voting request from a higher priority node, replied with approval and entered the locked state;

[0182] Received a heartbeat message from any machine;

[0183] Received a notification message from any machine;

[0184] The node status changing module;

[0185] After the server finishes waiting in the candidate state, if it receives a reply message to the voting request and there is no objection message, it sets the state to the active node and calls the notification message sending module;

[0186] If a voting request reply message has been received and there are more than or equal to 1 opposing messages, the status will be set to an inactive node;

[0187] If no voting reply is received, a ping request is sent to a reliable third-party node: if the ping is successful, the status is set to an active node; if the ping is unsuccessful, the status is set to an inactive node;

[0188] The node sequence comparison module:

[0189] After all nodes receive the heartbeat message, they will first compare the sequence number of the active node in the message with the sequence number of the locally considered active node:

[0190] If they are consistent, the heartbeat is replied with the content of the currently considered active node and the sequence number of the heartbeat reply message sent; if they are inconsistent, the priorities are compared: if the active node contained in the received heartbeat message has a higher priority, the locally considered active node is changed to the active node sequence number in the heartbeat message, and then a heartbeat reply message is sent;

[0191] If the active node contained in the received heartbeat message has a lower priority, a reply message will be sent to request the heartbeat sender to change the currently considered active node.

[0192] The present invention will be described in more detail below through preferred examples.

[0193] Preferred Example 1:

[0194] In order to achieve a master-slave switching speed of seconds, ensure that at least one server is in an active state, and can be switched according to priority at the same time, the present invention adopts the following implementation method.

[0195] All servers will only be in four states: Active node (Leader): Only servers in the active node will provide services; Inactive node (Follower): No service; Candidate: When an inactive node initiates a vote, it becomes a candidate and switches to other states based on the election results and does not provide services; Lock: When an inactive node receives a voting request, it becomes a locked state and switches to other states based on the election results and does not provide services.

[0196] All servers will be assigned serial numbers based on their priority, starting from 1. The smaller the number, the higher the priority. The higher the priority of the server, the more likely it is to become the active node during the primary-slave switch.

[0197] The message types between all servers are as follows: heartbeat messages, which are mainly used by inactive nodes to confirm the status of active nodes; heartbeat reply messages, which are mainly used by active nodes to confirm whether there are heartbeat conflicts; voting request messages, which ask other nodes whether they agree with this election; voting request reply messages, which agree or disagree with the election initiated by a certain node; notification messages, which are mainly used to notify other nodes to change the serial number of the currently considered active node.

[0198] The active node will send a heartbeat message to all other servers via the TCP protocol. The content includes the sequence number of the current active node and the sequence number of the heartbeat message sent.

[0199] After all nodes receive the heartbeat message, they will first compare the sequence number of the active node in the message with the sequence number of the locally considered active node. If they are consistent, they will reply with the heartbeat, and the content is the sequence number of the currently considered active node and the heartbeat reply message. If they are inconsistent, the priorities are compared. If the priority of the active node contained in the received heartbeat message is higher, the locally considered active node is changed to the sequence number of the active node in the heartbeat message, and then the heartbeat reply message is sent. If the priority of the active node contained in the received heartbeat message is lower, a reply message will be sent to request the heartbeat sender to change the currently considered active node.

[0200] All inactive nodes will count the received heartbeats. If no heartbeat message is received within 200ms, the count will be increased by 1. When the count reaches 5, the inactive node considers the active node offline. After waiting for 50ms multiplied by the local serial number, it will send a voting request to all nodes and set the local status to candidate. Figure 1 FIG. 1 is a flow chart of an inactive node provided by the present invention when the heartbeat is not connected.

[0201] like Figure 2 As shown, it is a schematic diagram of the state machine provided by the present invention.

[0202] After becoming a candidate, wait for the voting results. The waiting ends when the following conditions are met: any node replies to an opposing voting message; the number of reply voting messages is equal to the number of all nodes minus 1; the waiting time reaches 500ms; a voting request is received from a node with a higher priority (at this time, reply with an agreement and enter the locked state); a heartbeat message is received from any machine; a notification message is received from any machine.

[0203] After the waiting is finished in the candidate state, if a voting reply has been received and there is no objection message, the state is set to an active node. If a voting reply has been received and there are more than or equal to 1 objection message, the state is set to an inactive node. If no voting reply is received, a ping request is sent to a reliable third-party node. If the ping is successful, the state is set to an active node. If the ping is unsuccessful, the state is set to an inactive node. Ping is a command in the operating system that is used to detect whether the target machine is connected to the local network. The ping request is to call this command to detect the network status with the third party.

[0204] After a candidate becomes an active node, it will send a notification message to all other nodes, containing the serial number of the active node.

[0205] When the active node receives a notification message, it determines the priority of the serial number of the local machine and the message content. If the message content is higher, the local state is set to an inactive node and the sequence number of the considered active node is changed to the message content. If the local priority is higher, the state is not changed, and a notification message is replied with the local sequence number.

[0206] When a notification message is received in the candidate or locked state, the state is set to an inactive node, and the sequence number of the considered active node is changed to the sequence number in the message content.

[0207] When a notification message is received in the inactive node state, the local node will determine the priority of the active node sequence number and the sequence number in the notification message content. If the sequence number in the message content is higher, the local node sequence number will be changed to the message content. If the local node has a higher priority, only the notification message will be replied with the sequence number of the active node considered by the local node.

[0208] After receiving the voting request, the inactive node determines whether the count has reached 5. If so, it replies with approval. If not, it replies with disapproval. After replying with approval, its own status is set to locked.

[0209] In the locked state, all voting requests received will be replied with "no". Any heartbeat message received will set the state to an inactive node. The local active node sequence number will be changed according to the content of the heartbeat message. If no heartbeat message is received within 200ms from the time of changing to the locked state, the state will be set back to an inactive node and the heartbeat count will be reset to zero.

[0210] In the description of the present application, it should be understood that the terms "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside", etc., indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the referred device or element must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be understood as a limitation on the present application.

[0211] Those skilled in the art know that, in addition to implementing the system, device and its various modules provided by the present invention in a purely computer-readable program code, it is entirely possible to implement the same program in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers and embedded microcontrollers by logically programming the method steps. Therefore, the system, device and its various modules provided by the present invention can be considered as a hardware component, and the modules included therein for implementing various programs can also be considered as structures within the hardware component; the modules for implementing various functions can also be considered as both software programs for implementing the method and structures within the hardware component.

[0212] The above describes the specific embodiments of the present invention. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which does not affect the essence of the present invention. In the absence of conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.

Claims

1. A multi-center redundant arbitration method based on a SCADA system, characterized in that: include: Server assigns serial number steps: The server will assign serial numbers according to priority; Active / standby switching steps: Switch the active node according to the priority of the server serial number, and select the server with higher priority as the current active node; at the same time, all inactive nodes will count the received heartbeats, and after a delay, they will initiate a voting request to all nodes to vote and select a new active node; The server serial number starts from 1, and the smaller the number, the higher the priority. The server with a higher priority is more likely to become the active node during the active / standby switch. All servers are divided into four states: Active Node: Only servers in the active node state will provide services; Inactive nodes: Servers in inactive node status do not provide services; Candidate: When an inactive node initiates a vote, it becomes a candidate and changes to other states based on the election results, and does not provide services; Locked: When an inactive node receives a voting request, it becomes locked and changes to other states based on the election results, and does not provide services; The message types between all servers are as follows: Heartbeat messages are used by inactive nodes to confirm the status of active nodes; Heartbeat reply message, used by the active node to confirm whether there is a heartbeat conflict; Voting request message, used to ask other nodes whether they agree with the election; Voting request reply message, used to approve or disapprove of an election initiated by a certain node; Notification message, used to notify other nodes to change the currently considered active node sequence number; The master-slave switching step includes: Heartbeat information sending step: the active node sends a heartbeat message to all other servers through the TCP protocol, and the content of the heartbeat message includes the sequence number of the current active node and the sequence number of the heartbeat message sent; Node sequence comparison step: After all nodes receive the heartbeat message, they compare the active node sequence number of the message with the sequence number of the locally considered active node, and select the node with the higher priority as the current active node; Node election step: All inactive nodes count the received heartbeats, initially 0. If no heartbeat message is received within the first preset time, the count is increased by 1. When the count reaches the preset count threshold, the inactive node considers the active node offline. After waiting for the second preset time multiplied by the local serial number, it initiates a voting request to all nodes, and the local state is set to candidate. Voting result waiting step: After the server status changes to candidate, wait for the voting result, and end the waiting when it meets the preset conditions; Node status change step: After the server finishes waiting in the candidate state, it determines whether it has received a voting request reply message and no objection message: if so, the state is set to an active node and the notification message sending step continues; otherwise, the state is set to an inactive node; Notification message sending step: After the candidate becomes the active node, it sends a notification message to all other nodes, with the content being the serial number of the active node; Active node status change steps: When the active node receives a notification message, it determines the priority of the local and message content sequence numbers. If the message content is higher, the local state is set to an inactive node and the sequence number of the active node is changed to the message content. If the local priority is higher, the state is not changed and the notification message is replied with the local sequence number. Steps for changing the candidate or locked state: When the server receives a notification message in the candidate or locked state, it sets the state to an inactive node and changes the sequence number of the considered active node to the sequence number in the message content; Inactive node status change steps: When the server receives a notification message in the inactive node state, it determines the priority of the local active node sequence number and compares it with the sequence number in the notification message content. If the sequence number in the message content is higher, the local active node sequence number is changed to the message content. If the local active node priority is higher, only the notification message is replied, and the content is the local active node sequence number; Count judgment step: After receiving the voting request, the inactive node determines whether the count of the node election step has reached the preset count threshold. If it has reached it, it replies to agree, and after replying to agree, its own status is set to locked state; if it has not reached it, it replies to disagree; In the locked state, all voting requests received will be replied with "no". Any heartbeat message received will set the state to an inactive node. The local active node sequence number will be changed according to the content of the heartbeat message. If no heartbeat message is received within the fourth preset time from the lock state, the state will be reset to an inactive node and the heartbeat count will be reset to zero. The node status changing step; After the server finishes waiting in the candidate state, if it receives a reply message to the voting request and there is no objection message, it sets the state to the active node and enters the notification message sending step to continue execution; If a voting request reply message has been received and there are more than or equal to 1 opposing messages, the status will be set to an inactive node; If no voting reply is received, a ping request is sent to a reliable third-party node: if the ping is successful, the status is set to an active node; if the ping is unsuccessful, the status is set to an inactive node; The node sequence comparison step: After all nodes receive the heartbeat message, they will first compare the sequence number of the active node in the message with the sequence number of the locally considered active node: If they are consistent, the heartbeat is replied with the content of the currently considered active node and the sequence number of the heartbeat reply message sent; if they are inconsistent, the priorities are compared: if the active node contained in the received heartbeat message has a higher priority, the locally considered active node is changed to the active node sequence number in the heartbeat message, and then a heartbeat reply message is sent; If the active node contained in the received heartbeat message has a lower priority, a reply message will be sent to request the heartbeat sender to change the currently considered active node.

2. The multi-center redundant arbitration method based on the SCADA system according to claim 1 is characterized in that: The voting result waiting steps: The preset conditions include: Any node replies to the message of opposing the vote; The number of reply voting messages is equal to the number of all nodes minus 1; The waiting time reaches the third preset time; Received a voting request from a higher priority node, replied with approval and entered the locked state; Received a heartbeat message from any machine; Received a notification message from any machine.

3. A multi-center redundant arbitration system based on the SCADA system, characterized in that: include: Server allocation sequence number module: the server will be allocated sequence numbers according to the priority; Active / standby switching module: switches the active node according to the priority of the server serial number, and selects the server with higher priority as the current active node; at the same time, all inactive nodes will count the received heartbeats, and after a delay, they will initiate a voting request to all nodes to vote and select a new active node; The server serial number starts from 1, and the smaller the number, the higher the priority. The server with a higher priority is more likely to become the active node during the active / standby switch. All servers are divided into four states: Active Node: Only servers in the active node state will provide services; Inactive nodes: Servers in inactive node status do not provide services; Candidate: When an inactive node initiates a vote, it becomes a candidate and changes to other states based on the election results, and does not provide services; Locked: When an inactive node receives a voting request, it becomes locked and changes to other states based on the election results, and does not provide services; The message types between all servers are as follows: Heartbeat messages are used by inactive nodes to confirm the status of active nodes; Heartbeat reply message, used by the active node to confirm whether there is a heartbeat conflict; Voting request message, used to ask other nodes whether they agree with the election; Voting request reply message, used to approve or disapprove of an election initiated by a certain node; Notification message, used to notify other nodes to change the currently considered active node sequence number; The active / standby switching module comprises: Heartbeat information sending module: The active node sends a heartbeat message to all other servers through the TCP protocol. The heartbeat message content includes the sequence number of the current active node and the sequence number of the heartbeat message sent; Node sequence comparison module: After all nodes receive the heartbeat message, they compare the sequence number of the active node in the message with the sequence number of the locally considered active node, and select the node with higher priority as the current active node; Node election module: All inactive nodes count the received heartbeats, initially 0. If no heartbeat message is received within the first preset time, the count is increased by 1. When the count reaches the preset count threshold, the inactive node considers the active node offline. After waiting for the second preset time multiplied by the local serial number, it initiates a voting request to all nodes, and the local status is set to candidate. Voting result waiting module: after the server status changes to candidate, wait for voting results, and end the waiting when the preset conditions are met; Node status change module: After the server finishes waiting in the candidate state, it determines whether it has received a voting request reply message and no objection message: if so, the state is set to an active node and the notification message sending module is called; otherwise, the state is set to an inactive node; Notification message sending module: After a candidate becomes an active node, it sends a notification message to all other nodes, with the content being the serial number of the active node; Active node status change module: When an active node receives a notification message, it determines the priority of the local and message content serial numbers. If the message content is higher, the local state is set to an inactive node and the considered active node serial number is changed to the message content. If the local priority is higher, the state is not changed and a notification message is replied with the local serial number. Candidate or lock status change module: When the server receives a notification message in the candidate or lock state, it sets the state to an inactive node and changes the sequence number of the considered active node to the sequence number in the message content; Inactive node status change module: When the server receives a notification message in the inactive node state, it determines the priority of the local active node sequence number and compares it with the sequence number in the notification message content. If the sequence number in the message content is higher, the local active node sequence number is changed to the message content. If the local active node priority is higher, it only replies to the notification message with the content of the local active node sequence number. Count judgment module: After receiving the voting request, the inactive node judges whether the count of the node election module has reached the preset count threshold. If it has reached the preset count threshold, the inactive node replies "yes" and sets its own status to locked status. If it has not reached the preset count threshold, the inactive node replies "no"; In the locked state, all voting requests received will be replied with "no". Any heartbeat message received will set the state to an inactive node. The local active node sequence number will be changed according to the content of the heartbeat message. If no heartbeat message is received within the fourth preset time from the lock state, the state will be reset to an inactive node and the heartbeat count will be reset to zero. The node status changing module; After the server finishes waiting in the candidate state, if it receives a reply message to the voting request and there is no objection message, it sets the state to the active node and calls the notification message sending module; If a voting request reply message has been received and there are more than or equal to 1 opposing messages, the status will be set to an inactive node; If no voting reply is received, a ping request is sent to a reliable third-party node: if the ping is successful, the status is set to an active node; if the ping is unsuccessful, the status is set to an inactive node; The node sequence comparison module: After all nodes receive the heartbeat message, they will first compare the sequence number of the active node in the message with the sequence number of the locally considered active node: If they are consistent, the heartbeat is replied with the content of the currently considered active node and the sequence number of the heartbeat reply message sent; if they are inconsistent, the priorities are compared: if the active node contained in the received heartbeat message has a higher priority, the locally considered active node is changed to the active node sequence number in the heartbeat message, and then a heartbeat reply message is sent; If the active node contained in the received heartbeat message has a lower priority, a reply message will be sent to request the heartbeat sender to change the currently considered active node.

4. The multi-center redundant arbitration system based on the SCADA system according to claim 3 is characterized in that: The voting result waiting module: The preset conditions include: Any node replies to the message of opposing the vote; The number of reply voting messages is equal to the number of all nodes minus 1; The waiting time reaches the third preset time; Received a voting request from a higher priority node, replied with approval and entered the locked state; Received a heartbeat message from any machine; Received a notification message from any machine.

Images