A redundant PLC architecture data synchronization method

Abstract

The application provides a redundant PLC architecture data synchronization method, writes of any node to a local holding register are enabled through embedding of an incremental synchronization engine in a slave service, and conflict detection and arbitration are implemented based on a point level timestamp, so that a high consistency, low cost and strong compatibility redundant data service is implemented on a resource limited industrial controller; a unified incremental synchronization mechanism of multi-protocol writing is adopted, a standard Modbus and a non-standard batch writing are first unified into the same synchronization engine, protocol independence and writing synchronization are implemented, and a dependence on a private protocol of a traditional scheme is broken; multi-source concurrent writing is supported, a human-machine interface (HMI), a non-standard batch writing, a local program and the like can write different or same points at the same time, and the system automatically merges according to a timestamp, and there is no data covering risk.

Description

Technical Field

[0001] This invention relates to the technical field of data synchronization under a redundant PLC architecture, and specifically to a data synchronization method for a redundant PLC architecture. Background Technology

[0002] Industrial redundant PLC (Programmable Logic Controller) systems typically employ a master-slave synchronization model, where the master PLC periodically synchronizes its memory mirror or I / O status to the standby PLC via a dedicated link (such as fiber optic cable or backplane bus). Some systems support Modbus TCP as a monitoring interface, but its holding registers are read-only or locally written without propagation. While some manufacturers offer hot standby synchronization, it relies on proprietary protocols coupled with hardware and does not support transparent synchronization with third-party Modbus devices or non-standard protocols.

[0003] The shortcomings and deficiencies of existing data synchronization technologies are as follows: 1) Coarse synchronization granularity and low efficiency: Traditional solutions use whole memory blocks or periodic snapshots for synchronization, which cannot identify specific point changes, resulting in serious bandwidth waste and inability to support high-frequency local updates.

[0004] 2) Closed semantics of writing: Modbus write operations only affect the local machine and have no distributed semantics; non-standard batch writes (such as 2000 words at a time) of engineering software such as TIA Portal cannot be recognized by the synchronization mechanism.

[0005] 3) Lack of conflict handling: When multiple nodes write to the same register at the same time, the lack of timestamp or version mechanism can easily lead to inconsistency between primary and backup data, causing control accidents during switchover.

[0006] 4) Poor protocol scalability: The existing synchronization mechanism only adapts to the vendor's proprietary protocol and cannot be compatible with mixed write scenarios of Modbus and third-party engineering tools (such as TIA Portal).

[0007] Therefore, there is an urgent need to provide a new solution to address the defects and shortcomings of the existing technologies. Summary of the Invention

[0008] To address the shortcomings and deficiencies in existing technologies, this invention provides a data synchronization method for redundant PLC architectures.

[0009] The specific solution provided by this invention is as follows: A data synchronization method for a redundant PLC architecture, characterized in that the method includes the following steps: S100: Unified memory model and access to multiple protocols: Configure multiple sets of slave IDs for each PLC, configure a holding register for each set of slave IDs, and access multiple protocols adapted to the corresponding slave for the holding register; S200: Cluster Initialization and Node Addition: After any node PLC in the current cluster starts up or the network is restored, it first obtains the complete list of nodes in the current cluster through the preset management interface; then the node PLC initiates a data synchronization request to the nodes in the cluster according to the list order; when the node PLC successfully obtains the synchronization data of the nodes in the previous cluster, it is confirmed that the node has joined the current cluster. S300: Write-triggered incremental synchronization: When any node PLC receives a write request, it immediately records the update timestamp of the PLC, generates an incremental synchronization message, updates the corresponding local holding register, and sends the generated incremental synchronization message to the remaining node PLCs in the cluster one by one in a point-to-point manner. S400: Conflict Detection and Arbitration: After receiving an incremental synchronization message, any node PLC compares the timestamp in the incremental synchronization message with the timestamp stored locally on that node, and performs corresponding arbitration processing based on the comparison result. S500: Preset slave persistent linkage: any one of the slaves is predefined as a persistent slave, and the data written from that persistent slave is immediately written to the ferroelectric memory after synchronization is completed; S600: Batch write reassembly fragmentation: When the data written in a single operation exceeds the preset data threshold, the single write data is automatically split into multiple fragments. After receiving the multiple fragments, the receiving end reassembles them and performs conflict arbitration and update.

[0010] As a further preferred embodiment of the present invention, in step S100, the multiple protocols for maintaining register access include at least the standard Modbus protocol and the non-standard bulk write protocol.

[0011] As a further preferred embodiment of the present invention, in step S200, when the node PLC initiates a data synchronization request to the nodes within the cluster according to the list order, if the first target node that initiated the request does not respond or the request fails, it will automatically try the second target node in the list in order until the synchronization data is successfully obtained.

[0012] As a further preferred embodiment of the present invention, in step S300, the read operation and the write operation are separated from each other, and the priority of the write operation triggering incremental synchronization is higher than the priority of the read operation triggering incremental synchronization.

[0013] As a further preferred embodiment of the present invention, in step S300, the generated incremental synchronization message includes at least the following information: slave ID, starting address, length, data, and timestamp.

[0014] As a further preferred embodiment of the present invention, in step S400, when comparing the timestamp in the incremental synchronization message with the local storage timestamp of the node, and performing corresponding arbitration processing based on the comparison result: The holding register and timestamp are only updated when the timestamp in the incremental synchronization message is later than the local storage timestamp. When the timestamp in the incremental synchronization message is earlier than the local storage timestamp, the update of the node's holding register and timestamp is abandoned; Furthermore, multiple conflict detection and arbitration processes can be conducted simultaneously.

[0015] As a further preferred embodiment of the present invention, in step S400, when a node comes back online after being offline, the following data recovery strategy is adopted: Offline nodes only request all incremental synchronization messages from other online nodes from the time they went offline to the current time, and apply them sequentially to quickly catch up with the latest cluster state; or: Configure an offline duration safety threshold and a preset upper limit for the number of messages. If the offline duration of the offline node exceeds the offline duration safety threshold or the number of incremental messages exceeds the preset upper limit for the number of messages, the system will automatically trigger a full synchronization.

[0016] As a further preferred embodiment of the present invention, in step S500, the priority of data recovery in the ferroelectric memory is higher than the priority of data recovery in other slave stations when the power is turned on.

[0017] As a further preferred embodiment of the present invention, in step S600, when the single-write data is automatically split into multiple groups of fragments, the data threshold of each group of fragments is not higher than a preset data threshold.

[0018] As a further preferred embodiment of the present invention, in step S600, When the receiving end receives multiple fragments, it reassembles them and performs conflict arbitration and update, performing conflict arbitration and update on each PLC point in the order of the timestamp corresponding to each point. When performing conflict arbitration and update, for the address of the holding register corresponding to each slice, the conflict detection and arbitration steps described in step S400 are executed independently once.

[0019] Compared with existing technologies, the technical effects that this invention can achieve include: 1) This invention provides a redundant PLC architecture data synchronization method. By embedding an incremental synchronization engine in the Modbus slave service, any node's writing to the local register (including standard Modbus and non-standard protocols, etc.) is subject to conflict detection and arbitration based on point-level timestamps, thereby achieving a highly consistent, low-overhead, and highly compatible redundant data service on resource-constrained industrial controllers.

[0020] 2) This invention provides a data synchronization method for redundant PLC architecture, which adopts a unified incremental synchronization mechanism for multi-protocol writing. For the first time, it integrates standard Modbus and non-standard batch writing into the same synchronization engine, achieving protocol independence and synchronization upon writing, breaking through the dependence of traditional solutions on private protocols. It supports concurrent writing from multiple sources, and human-machine interface (HMI), non-standard batch writing, local programs, etc. can be written to different or the same points at the same time. The system automatically merges them according to timestamps, eliminating the risk of data overwriting.

[0021] 3) This invention provides a data synchronization method for redundant PLC architecture. By arbitrating point-level timestamp conflicts, it maintains and updates timestamps at the register level, achieving fine-grained, lock-free, and eventually consistent conflict resolution. It is suitable for complex industrial scenarios such as multi-engineer debugging, concurrent writing of HMI and programs.

[0022] 4) This invention provides a data synchronization method for a redundant PLC architecture, which pre-defines the slave station as a persistent slave station, thereby ensuring the synchronization and persistence of critical data. Through hard binding with the ferroelectric memory, the automatic persistence of business-critical data is achieved without user intervention.

[0023] 5) This invention provides a data synchronization method for redundant PLC architecture, which has fast synchronization speed and low resource consumption. In actual tests, in a 6-PLC node cluster, after writing to any point, the time to achieve full cluster consistency is less than 200ms. The timestamp only needs to be increased by 8 bytes / point (which can be enabled as needed). The CPU utilization rate of the synchronization engine is less than 4%, and it is applicable to real-time operating systems such as SylixOS. Attached Figure Description

[0024] Figure 1 The diagram shown is a flowchart of the steps of the method provided by the present invention. Detailed Implementation

[0025] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] In the description of this invention, it should be noted that the terms "upper," "lower," "inner," "outer," "front end," "rear end," "both ends," "one end," and "the other end," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0027] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installed," "equipped with," "connected," etc., should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be a connection within two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0028] [First Embodiment] like Figure 1 The figure shown is a data synchronization method for a redundant PLC architecture provided in the first embodiment of the present invention, which includes the following steps: S100: Unified memory model and access to multiple protocols: Configure multiple sets of slave IDs for each PLC, configure a holding register for each set of slave IDs, and access multiple protocols adapted to the corresponding slave for the holding registers; for example, in this embodiment, configure 20 sets of Modbus slave IDs (IDs range from 0 to 19) for each PLC, and configure a 10,000-word holding register for each set of slave IDs.

[0029] In this embodiment, to maintain the multiple protocols for register access, at least the standard Modbus protocol and non-standard bulk write protocols (such as TIA Portal, TIA Portal, up to 2000 words at a time) are included.

[0030] S200: Cluster Initialization and Node Addition: After any node PLC in the current cluster starts up or the network is restored, it first obtains the complete list of nodes in the current cluster through the preset management interface; then the node PLC initiates a data synchronization request to the nodes in the cluster according to the list order; when the node PLC successfully obtains the synchronization data of the nodes in the previous cluster, it is confirmed that the node has joined the current cluster. Preferably, in this step, when the node PLC initiates a data synchronization request to the nodes within the cluster according to the list order, if the first target node that initiated the request does not respond or the request fails, it will automatically try the second target node in the list in order until the synchronized data is successfully obtained.

[0031] By employing a sequential lookup strategy, it is ensured that new nodes can still complete initialization in the event of network partitioning or single point of failure.

[0032] After successfully acquiring all the data, the node completes its initialization, officially joins the cluster, and begins receiving and processing subsequent incremental synchronization messages, thus realizing the cluster's plug-and-play and elastic scaling capabilities.

[0033] S300: Write-triggered incremental synchronization: When any node PLC receives a write request (regardless of the source protocol), it immediately records the PLC's update timestamp (64-bit microsecond level), generates an incremental synchronization message, updates the corresponding local holding register, and sends the generated incremental synchronization message one by one in a point-to-point manner (e.g., via VSOA Datagram over UDP) to the remaining node PLCs in the cluster. In step S300, read and write operations are separated, and the priority of incremental synchronization triggered by write operations is higher than that of incremental synchronization triggered by read operations. Furthermore, the separation of read and write operations does not affect the read tasks of other services, making it more suitable for businesses that read large amounts of data.

[0034] This is because, in redundant systems, the core challenge to data consistency stems from write operations. Write operations alter the system state and must be synchronized to all nodes promptly and accurately to prevent data inconsistencies during master-slave failover. Read operations, on the other hand, do not change the state and therefore have a lower priority than write operations.

[0035] The read operation process is as follows: when any node (such as an HMI or local program) initiates a read request, data is directly read from the holding register of that node and returned. Since the write operation has ensured eventual consistency of data across nodes through high-speed synchronization, the read operation is completely localized, eliminating the need for cross-node communication, thus achieving read-write separation and significantly improving the overall throughput of the system. Because the core of this embodiment lies in the processing of the write path, rather than the read path, the read operation will not be described in detail.

[0036] By setting the priority of incremental synchronization triggered by write operations to be higher than that triggered by read operations, it can be ensured that when a large number of mixed read and write requests suddenly occur, the synchronization task (write operation) can be processed first, minimizing synchronization latency and ensuring the consistency of cluster data.

[0037] It is worth noting that in this embodiment, write-triggered incremental synchronization means that the synchronization action is not triggered periodically by a timer, but is directly driven by the write event itself. When any node PLC fully receives and verifies a write request data packet at the protocol parsing layer (whether it's a standard Modbus protocol stack or a non-standard protocol adapter), the event immediately triggers the incremental synchronization engine. The incremental synchronization engine then records the current high-precision update timestamp, generates an incremental synchronization message, and sends it. The entire triggering process is on the main path of write request processing, without waiting for any scheduler or periodic task. This event-driven synchronization mechanism fundamentally eliminates the inherent latency of periodic synchronization, which is key to achieving microsecond-level response and low CPU usage.

[0038] Meanwhile, the generated incremental synchronization message includes at least the following information: slave ID, starting address, length, data, and timestamp.

[0039] S400: Conflict Detection and Arbitration: After receiving an incremental synchronization message, any PLC at any location compares the timestamp in the incremental synchronization message with the local storage timestamp of that node, and performs corresponding arbitration processing based on the comparison result; In step S400, the timestamp in the incremental synchronization message is compared with the local storage timestamp of the node, and corresponding arbitration processing is performed based on the comparison result: The holding register and timestamp are only updated when the timestamp in the incremental synchronization message is later than the local storage timestamp. When the timestamp in the incremental synchronization message is earlier than the local storage timestamp, the update of the node's hold register and timestamp is abandoned to avoid the old data unexpectedly overwriting the new data.

[0040] By arbitrating timestamp conflicts at the point level, while maintaining and updating timestamps at the register level, fine-grained, lock-free, and eventually consistent conflict resolution is achieved. This approach is suitable for complex industrial scenarios such as multi-engineer debugging and concurrent writing of HMI programs. As a further preferred option, multiple conflict detection and arbitration can be performed simultaneously in this step, such as in scenarios where multiple engineers modify code at the same time during debugging. This enables fine-grained, lock-free, and eventually consistent conflict resolution, making it suitable for complex industrial scenarios such as multi-engineer debugging, HMI (Human Machine Interface) and concurrent program writing.

[0041] As a preferred approach, the following data recovery strategy is adopted when a node comes back online after being offline: When a node in the cluster briefly goes offline due to network issues or a failure and then comes back online, it defaults to an incremental synchronization recovery strategy. That is, the node only requests all incremental synchronization messages from other online nodes from the time it went offline to the current time, and applies them sequentially to quickly catch up with the latest cluster state. Alternatively: As a further preferred option, configure an offline duration safety threshold and a preset upper limit for the number of messages. If the offline duration of the node exceeds the offline duration safety threshold (e.g., 30 minutes), or the number of incremental messages exceeds the preset upper limit for the number of messages, the system will automatically trigger a full synchronization to ensure the integrity and security of data recovery and avoid permanent data inconsistency caused by missing incremental messages.

[0042] S500: Preset Slave Persistence Linkage: Any one of the slave stations is predefined as a persistent slave station. For example, in this embodiment, slave station ID=19 is predefined as a persistent slave station. Data written from this persistent slave station is immediately written to the ferroelectric memory (FRAM) after synchronization is complete. Furthermore, upon power-up, data recovery in the ferroelectric memory has a higher priority than data recovery from other slave stations, ensuring that critical parameters are not lost. Thus, through preset slave station persistence linkage, by predefining any one of the slave stations as a persistent slave station, the persistent synchronization of critical data is guaranteed. Through hard binding with the ferroelectric memory, automatic persistence of critical business data is achieved without user intervention.

[0043] S600: Batch write reassembly fragmentation: When the data written in a single operation exceeds the preset data threshold, the single write data is automatically split into multiple fragments. After receiving the multiple fragments, the receiving end reassembles them and performs conflict arbitration and update.

[0044] In this step, when automatically splitting a single write operation into multiple fragments, the data threshold for each fragment does not exceed a preset data threshold. For example, if the preset data threshold is 1400 bytes, and the single write operation exceeds the preset data threshold, such as 2000 bytes, the single write operation can be automatically split into multiple fragments, with each fragment having a data threshold of 1400 bytes, not exceeding the preset data threshold of 1400 bytes.

[0045] Meanwhile, when the receiving end receives multiple fragments, reassembles them, and performs conflict arbitration and updates, it performs conflict arbitration and updates one by one according to the timestamp order corresponding to each PLC point, ensuring the atomicity and consistency of large block writes.

[0046] During conflict arbitration and updates, the conflict detection and arbitration steps described in step S400 are executed independently once for the address of the holding register corresponding to each slice. This breaks down large-block write operations into multiple independent bit-level write operations. For each bit, the timestamp in the incremental synchronization message is compared with the local storage timestamp, and a write operation is only performed if the former is larger.

[0047] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A data synchronization method for a redundant PLC architecture, characterized in that: The method includes the following steps: S100: Unified memory model and access to multiple protocols: Configure multiple sets of slave IDs for each PLC, configure a holding register for each set of slave IDs, and access multiple protocols adapted to the corresponding slave for the holding register; S200: Cluster Initialization and Node Addition: After any node PLC in the current cluster starts up or the network is restored, it first obtains the complete list of nodes in the current cluster through the preset management interface; then the node PLC initiates a data synchronization request to the nodes in the cluster according to the list order; when the node PLC successfully obtains the synchronization data of the nodes in the previous cluster, it is confirmed that the node has joined the current cluster. S300: Write-triggered incremental synchronization: When any node PLC receives a write request, it immediately records the update timestamp of the PLC, generates an incremental synchronization message, updates the corresponding local holding register, and sends the generated incremental synchronization message to the remaining node PLCs in the cluster one by one in a point-to-point manner. S400: Conflict Detection and Arbitration: After receiving an incremental synchronization message, any node PLC compares the timestamp in the incremental synchronization message with the timestamp stored locally on that node, and performs corresponding arbitration processing based on the comparison result. S500: Preset slave persistent linkage: any one of the slaves is predefined as a persistent slave, and the data written from that persistent slave is immediately written to the ferroelectric memory after synchronization is completed; S600: Batch write reassembly fragmentation: When the data written in a single operation exceeds the preset data threshold, the single write data is automatically split into multiple fragments. After receiving the multiple fragments, the receiving end reassembles them and performs conflict arbitration and update.

2. The data synchronization method for a redundant PLC architecture according to claim 1, characterized in that: In step S100, the multiple protocols for maintaining register access include at least the standard Modbus protocol and a non-standard bulk write protocol.

3. The data synchronization method for a redundant PLC architecture according to claim 2, characterized in that: In step S200, when the node PLC initiates a data synchronization request to the nodes within the cluster according to the list order, if the first target node that initiated the request does not respond or the request fails, it will automatically try the second target node in the list in order until it successfully obtains the synchronized data.

4. The data synchronization method for a redundant PLC architecture according to claim 3, characterized in that: In step S300, the read operation and the write operation are separated, and the priority of the write operation triggering incremental synchronization is higher than the priority of the read operation triggering incremental synchronization.

5. The data synchronization method for a redundant PLC architecture according to claim 4, characterized in that: In step S300, the generated incremental synchronization message includes at least the following information: slave ID, starting address, length, data, and timestamp.

6. The data synchronization method for a redundant PLC architecture according to claim 5, characterized in that: In step S400, when comparing the timestamp in the incremental synchronization message with the local storage timestamp of the node, and performing corresponding arbitration processing based on the comparison result: The holding register and timestamp are only updated when the timestamp in the incremental synchronization message is later than the local storage timestamp. When the timestamp in the incremental synchronization message is earlier than the local storage timestamp, the update of the node's holding register and timestamp is abandoned; Furthermore, multiple conflict detection and arbitration processes can be conducted simultaneously.

7. The data synchronization method for a redundant PLC architecture according to claim 6, characterized in that: In step S400, when a node comes back online after being offline, the following data recovery strategy is adopted: Offline nodes only request all incremental synchronization messages from other online nodes from the time they went offline to the current time, and apply them sequentially to enable their own data to quickly catch up with the latest state of the cluster. or: Configure an offline duration safety threshold and a preset upper limit for the number of messages. If the offline duration of the offline node exceeds the offline duration safety threshold or the number of incremental messages exceeds the preset upper limit for the number of messages, the system will automatically trigger a full synchronization.

8. The data synchronization method for a redundant PLC architecture according to claim 7, characterized in that: In step S500, when power is applied, the data recovery priority in the ferroelectric memory is higher than the data recovery priority of other slave stations.

9. A data synchronization method for a redundant PLC architecture according to claim 8, characterized in that: In step S600, when the data written in a single transaction is automatically split into multiple groups, the data threshold of each group of groups is not higher than the preset data threshold.

10. A data synchronization method for a redundant PLC architecture according to claim 1, characterized in that: In step S600 When the receiving end receives multiple fragments, it reassembles them and performs conflict arbitration and update, performing conflict arbitration and update on each PLC point in the order of the timestamp corresponding to each point. When performing conflict arbitration and update, for the address of the holding register corresponding to each slice, the conflict detection and arbitration steps described in step S400 are executed independently once.

Images