A distributed control system and control network

Abstract

This application provides a distributed control system and control network. In this distributed control system, the computing module communicates with multiple I / O modules through a communication module and a custom CNET protocol. This application aims to customize a protocol stack for the specific data interaction needs of a distributed control system in a nuclear power plant by using a custom CNET protocol and corresponding CNET bus. This avoids the impact of redundant functional modules in general protocols on data transmission efficiency and reduces unnecessary data transmission overhead. Simultaneously, CNET adopts a master-slave architecture with the communication module as the master node and the I / O modules as slave nodes. The communication module leads the communication process between the computing module (i.e., the CPU module) and the I / O modules, thereby eliminating the latency caused by node contention in distributed protocols and improving communication efficiency.

Description

Technical Field

[0001] This application relates to the field of communication control technology, and in particular to a distributed control system and control network. Background Technology

[0002] Distributed control systems (DCS) are crucial systems in nuclear power plants for controlling various process systems and field devices. A control station typically consists of a CPU module, a communication module, and an I / O module. The I / O module collects operational data from field devices within the nuclear power plant and transmits the collected data to the CPU module. The CPU module performs logical operations based on the data transmitted from the I / O module and inputs the results back to the field devices via the I / O module, thereby achieving automated operation control of multiple field devices. The CPU module and I / O module communicate via a network, referred to as the control network. Current technologies often utilize mature bus protocols such as DP and CAN bus protocols for the control network. While these mature bus protocols offer high versatility, they are often used in traditional industrial applications and cannot fully adapt to the specific architecture of DCS systems in nuclear power plants, easily leading to low communication efficiency between the CPU module and I / O modules. Summary of the Invention

[0003] To address the aforementioned issues and improve the communication efficiency between the CPU module and I / O module in the DCS system of a nuclear power plant, this application provides a distributed control system and control network.

[0004] The embodiments of this application disclose the following technical solutions:

[0005] In a first aspect, embodiments of this application provide a distributed control system, including: a computing module, at least one communication module, and multiple I / O modules. Each communication module has a separately associated redundant communication module, and each I / O module is connected to the communication module and the associated redundant communication module through at least two CNET buses to form a redundant communication link. The CNET is a custom control network protocol, and the master node of the CNET is the communication module and the associated redundant communication module, while the slave node of the CNET is the I / O module.

[0006] The communication module is used to manage data communication between the computing module and the I / O module according to the preset communication interaction mechanism in the CNET, as well as to detect anomalies in each of the I / O modules, the communication module, and the multiple CNET buses.

[0007] In one possible implementation, multiple I / O modules are connected to each of the CNET buses; the preset communication interaction mechanism includes a periodic polling mechanism, and the communication module includes a periodic polling unit, which is specifically used for:

[0008] Receive upper-layer instructions from the computing module and convert the upper-layer instructions into the frame format corresponding to CNET to determine the request packets for each I / O module;

[0009] For each of the multiple I / O modules connected to the CNET bus, a request packet is sent sequentially to each I / O module based on the polling period specified by the periodic polling mechanism, and a response packet is received from each I / O module; the polling period includes the sending time of the request packet and the feedback time of the response packet.

[0010] If no response packet is received within the polling period or the response packet verification error occurs, it is determined that the associated I / O module has no response and the polling proceeds to the next I / O module.

[0011] The polling of the multiple I / O modules on each CNET bus is independent of each other, and the request packet sent by the periodic polling unit remains unique within a single polling cycle for each CNET bus.

[0012] In one possible implementation, the preset communication interaction mechanism includes a time synchronization mechanism; the communication module includes a time synchronization unit, which is specifically used for:

[0013] When the local clock of the communication module triggers the time synchronization processing time specified by the time synchronization processing mechanism, the time synchronization request sending process is initiated to send time synchronization requests to the multiple I / O modules connected to each of the CNET buses; the time synchronization request is a broadcast frame.

[0014] For the CNET bus with the most connected I / O modules, after all the I / O modules on the CNET bus have completed polling, the time synchronization request is sent to the multiple I / O modules connected to each CNET bus.

[0015] After the time synchronization requests for each of the CNET buses have been sent, a time synchronization completion instruction is sent to the periodic polling unit so that the periodic polling unit re-executes the periodic polling mechanism for each of the I / O modules.

[0016] In one possible implementation, the CNET includes: a physical layer, a data link layer, and an application layer;

[0017] The physical layer adopts a bus-type RS485 half-duplex link architecture, and a single communication module supports the connection of multiple CNET buses; the physical layer adopts an asynchronous transmission character encoding structure, and each character includes: a single start bit for synchronous data reception, multiple data bits for carrying valid data, a single parity bit for detecting single-byte transmission errors, and a single stop bit for indicating the end of the character;

[0018] The data link layer adopts an asynchronous transmission mode of DLPDU with non-fixed field length. The data link layer is used to define the request frame structure of the request packet and the response frame structure of the response packet. The request frame structure and the response frame structure both include: synchronization byte, start delimiter, length field, repeat length field, destination address, source address, function code, data unit, frame check sequence, and end delimiter.

[0019] The application layer is used to detect data interaction anomalies when the communication module and the I / O module interact with each other.

[0020] In one possible implementation, the data interaction anomaly detection includes: I / O address consistency detection, I / O address duplication detection, protocol number validity detection, and module type detection;

[0021] The execution steps of the I / O address consistency check include:

[0022] The target I / O module address is determined based on the request packet sent to the I / O module by the periodic polling unit.

[0023] If the target I / O module address is inconsistent with the DIP switch address of the I / O module receiving the request packet, the request packet is determined to be abnormal, and the I / O module is controlled to discard the request packet.

[0024] The execution steps of the I / O address repeatability detection include:

[0025] If, within a single polling cycle, the periodic polling unit receives at least two response packets with the same address, it is determined that the I / O module associated with the response packet has an address configuration conflict anomaly.

[0026] The execution steps for the protocol number validity check include:

[0027] For the request packets sent by the periodic polling unit, obtain the protocol number of the request packet;

[0028] If the protocol number of the request packet exceeds the preset range, the I / O module that receives the request packet will send the response packet back to the periodic polling unit based on the data acquisition format.

[0029] The response packet is analyzed to determine whether there is any protocol logic processing abnormality in the periodic polling unit;

[0030] The execution steps for the module type detection include:

[0031] For the request packets issued by the periodic polling unit, the module type of the associated communication module is determined based on the request packets;

[0032] When the module type does not match the module type of the I / O module receiving the request packet, the response packet fed back by the I / O module is set to a preset module quality bit to indicate the abnormal state of the communication module.

[0033] Based on the abnormal state and the response format of the protocol number corresponding to the request packet, it is determined whether the module type of the communication module is consistent with the hardware type of the I / O module, so as to determine whether there is a module type mismatch anomaly in the communication module.

[0034] In one possible implementation, the preset communication interaction mechanism includes a timeout detection mechanism, and the communication module includes a timeout detection unit, which is specifically used for:

[0035] If the periodic polling unit does not receive a response packet from the I / O module within a single polling cycle, it determines that the I / O module has no response and records the number of times the I / O module has no response.

[0036] If the number of unresponsive events reaches a preset threshold, the I / O module is determined to be faulty.

[0037] Secondly, embodiments of this application provide a control network applied to a distributed control system. The distributed control system includes: a computing module, at least one communication module, and multiple I / O modules. Each communication module has a separately associated redundant communication module. Each I / O module is connected to the communication module and the associated redundant communication module through at least two CNET buses to form a redundant communication link. The CNET is a custom control network protocol, and the master node of the CNET is the communication module and the associated redundant communication module, while the slave node of the CNET is the I / O module.

[0038] The communication module is used to manage data communication between the computing module and the I / O module according to the preset communication interaction mechanism in the CNET, as well as to detect anomalies in each of the I / O modules, the communication module, and the multiple CNET buses.

[0039] In one possible implementation, multiple I / O modules are connected to each of the CNET buses; the preset communication interaction mechanism includes a periodic polling mechanism, and the communication module includes a periodic polling unit, which is specifically used for:

[0040] Receive upper-layer instructions from the computing module and convert the upper-layer instructions into the frame format corresponding to CNET to determine the request packets for each I / O module;

[0041] For each of the multiple I / O modules connected to the CNET bus, a request packet is sent sequentially to each I / O module based on the polling period specified by the periodic polling mechanism, and a response packet is received from each I / O module; the polling period includes the sending time of the request packet and the feedback time of the response packet.

[0042] If no response packet is received within the polling period or the response packet verification error occurs, it is determined that the associated I / O module has no response and the polling proceeds to the next I / O module.

[0043] The polling of the multiple I / O modules on each CNET bus is independent of each other, and the request packet sent by the periodic polling unit remains unique within a single polling cycle for each CNET bus.

[0044] In one possible implementation, the preset communication interaction mechanism includes a time synchronization mechanism; the communication module includes a time synchronization module, which is specifically used for:

[0045] When the local clock of the communication module triggers the time synchronization processing time specified by the time synchronization processing mechanism, the time synchronization request sending process is initiated to send time synchronization requests to the multiple I / O modules connected to each of the CNET buses; the time synchronization request is a broadcast frame.

[0046] For the CNET bus with the most connected I / O modules, after all the I / O modules on the CNET bus have completed polling, the time synchronization request is sent to the multiple I / O modules connected to each CNET bus.

[0047] After the time synchronization requests for each of the CNET buses have been sent, a time synchronization completion instruction is sent to the periodic polling unit so that the periodic polling unit re-executes the periodic polling mechanism for each of the I / O modules.

[0048] In one possible implementation, the CNET includes: a physical layer, a data link layer, and an application layer;

[0049] The physical layer adopts a bus-type RS485 half-duplex link architecture, and a single communication module supports the connection of multiple CNET buses; the physical layer adopts an asynchronous transmission character encoding structure, and each character includes: a single start bit for synchronous data reception, multiple data bits for carrying valid data, a single parity bit for detecting single-byte transmission errors, and a single stop bit for indicating the end of the character;

[0050] The data link layer adopts an asynchronous transmission mode of DLPDU with non-fixed field length. The data link layer is used to define the request frame structure of the request packet and the response frame structure of the response packet. The request frame structure and the response frame structure both include: synchronization byte, start delimiter, length field, repeat length field, destination address, source address, function code, data unit, frame check sequence, and end delimiter.

[0051] The application layer is used to detect data interaction anomalies when the communication module and the I / O module interact with each other.

[0052] Compared to existing technologies, this application offers the following advantages: This application provides a distributed control system and control network. The distributed control system includes: a computing module, at least one communication module, and multiple I / O modules. Each communication module has a separately associated redundant communication module. Each I / O module is connected to the communication module and the associated redundant communication module via at least two CNET buses to form redundant communication links. The CNET is a custom control network protocol, and the master node of the CNET is the communication module and the associated redundant communication module, while the slave node of the CNET is the I / O module. The communication module is used to manage data communication between the computing module and the I / O modules according to a preset communication interaction mechanism within the CNET, and to detect anomalies in each I / O module, the communication module, and the multiple CNET buses. Through the custom CNET protocol, a protocol stack can be customized for the specific data interaction requirements of the distributed control system in a nuclear power plant, avoiding the impact of redundant functional modules in general protocols on data transmission efficiency and reducing unnecessary data transmission overhead. Meanwhile, CNET employs a master-slave architecture, with the communication module as the master node and the I / O module as the slave node. The communication module controls the communication flow between the computing module (CPU module) and the I / O module, thereby eliminating latency caused by node contention in distributed protocols and improving communication efficiency. Furthermore, each I / O module is connected to the communication module and redundant communication modules via at least two CNET buses, forming physical layer redundancy. When a single bus or communication module fails, the redundant link can seamlessly take over communication, avoiding retransmissions, interruptions, or system restarts caused by faults, ensuring data transmission continuity, reducing unnecessary waiting time, and thus improving communication efficiency. Attached Figure Description

[0053] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0054] Figure 1 This is a schematic diagram of the connection structure of a distributed control system provided in an embodiment of this application;

[0055] Figure 2 A schematic diagram of the physical layer of the CNET control network protocol provided in this application embodiment;

[0056] Figure 3A flowchart illustrating a periodic polling mechanism execution method provided in an embodiment of this application;

[0057] Figure 4 A schematic diagram illustrating a periodic polling mechanism provided in an embodiment of this application;

[0058] Figure 5 A flowchart illustrating a time synchronization mechanism execution method provided in an embodiment of this application;

[0059] Figure 6 This is a flowchart illustrating a timeout detection mechanism execution method provided in an embodiment of this application. Detailed Implementation

[0060] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and accompanying drawings. It should be particularly noted that the embodiments described in this application are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0061] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0062] As described earlier, current technologies often employ mature bus protocols for control networks, such as DP and CAN bus protocols. While these mature bus protocols offer high versatility, they are typically used in traditional industrial applications and cannot fully adapt to the specific architecture of DCS systems in nuclear power plants. This can easily lead to inefficient communication between CPU modules and I / O modules.

[0063] To address the aforementioned issues, this application provides a distributed control system and control network. The distributed control system includes: a computing module, at least one communication module, and multiple I / O modules. Each communication module has a separately associated redundant communication module. Each I / O module is connected to the communication module and its associated redundant communication module via at least two CNET buses to form redundant communication links. The CNET is a custom control network protocol, with the communication module and its associated redundant communication module as the master nodes and the I / O modules as slave nodes. The communication module is used to manage data communication between the computing module and the I / O modules according to a preset communication interaction mechanism within the CNET, and to detect anomalies in each I / O module, the communication module, and the multiple CNET buses. Through the custom CNET protocol, a protocol stack can be customized for the specific data interaction requirements of the distributed control system in a nuclear power plant, avoiding the impact of redundant functional modules in general protocols on data transmission efficiency and reducing unnecessary data transmission overhead. Meanwhile, CNET employs a master-slave architecture, with the communication module as the master node and the I / O module as the slave node. The communication module controls the communication flow between the computing module (CPU module) and the I / O module, thereby eliminating latency caused by node contention in distributed protocols and improving communication efficiency. Furthermore, each I / O module is connected to the communication module and redundant communication modules via at least two CNET buses, forming physical layer redundancy. When a single bus or communication module fails, the redundant link can seamlessly take over communication, avoiding retransmissions, interruptions, or system restarts caused by faults, ensuring data transmission continuity, reducing unnecessary waiting time, and thus improving communication efficiency.

[0064] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0065] See Figure 1 The figure is a schematic diagram of the connection structure of a distributed control system provided in an embodiment of this application. The distributed control system (corresponding to the DCS system in a nuclear power plant) is equipped with a computing module (corresponding to a CPU module), multiple I / O modules, at least one communication module, and associated redundant communication modules. Figure 1The diagram shows a DCS system with multiple communication modules. As shown, the computing module, as the system core, is responsible for data logic processing and control algorithm calculations. The output instructions of the computing module are transmitted to the field I / O modules through the communication modules, which in turn establish communication with the I / O modules. The communication modules and redundant communication modules form a dual-machine hot standby architecture. They are physically independent but logically backups of each other, ensuring uninterrupted system communication in the event of a single module failure.

[0066] Each I / O module is responsible for acquiring signals from field devices and executing data acquisition commands. It is connected to the communication module and the redundant communication module via two independent CNET buses, forming a redundant communication link of "dual master nodes and multiple slave nodes". This design allows each I / O module to interact with the master communication module or the redundant communication module in real time at any time, avoiding the risk of communication interruption caused by single point of failure.

[0067] CNET is a custom control network protocol used in this embodiment of the application, and the corresponding CNET bus adopts the following... Figure 1 The bus topology shown allows a single bus to support communication between one master node (communication module or redundant communication module) and multiple slave nodes (I / O modules). Figure 1 In the application scenario shown, the communication module can manage six independent CNET buses simultaneously, enabling parallel control of multiple I / O modules. The core purpose of the custom CNET control network protocol in this embodiment is to eliminate redundant functions from conventional general-purpose bus protocols, retaining only the core communication logic necessary for a nuclear power plant's DCS system, and precisely adapting to the nuclear power plant's DCS system architecture. This improves the communication efficiency between the computing module and the I / O module.

[0068] In this embodiment, the custom CNET control network protocol is divided into a physical layer, a data link layer, and an application layer. Each layer eliminates redundant communication functions through specific architecture settings and transmission mode settings. Next, the physical layer, data link layer, and application layer of CNET will be introduced in turn according to the accompanying drawings of the specific embodiment.

[0069] See Figure 2 This figure is a schematic diagram of the physical layer of the CNET control network protocol provided in an embodiment of this application. In this embodiment, the physical layer design of the CNET protocol closely revolves around the high real-time and high reliability requirements of nuclear power plant DCS systems, aiming to combine multi-path parallel transmission with a simple asynchronous encoding mechanism to build a low-cost, high-efficiency underlying communication channel. The core features and functions of the physical layer can be summarized in the following three aspects: multi-bus parallel transmission architecture, lightweight asynchronous character encoding, and industry-standard hardware adaptability.

[0070] Specifically, the physical layer adopts a bus-type RS485 half-duplex link architecture, and a single communication module supports connections to multiple CNET buses. Furthermore, the physical layer adopts an asynchronous transmission character encoding structure, and each character includes: a single start bit for synchronous data reception, multiple data bits for carrying valid data, a single parity bit for detecting single-byte transmission errors, and a single stop bit for indicating the end of the character.

[0071] Specifically, at the multi-bus parallel transmission architecture level, the physical layer uses RS485 as the transmission medium and adopts a half-duplex master-slave communication mode. This allows a single bus to support one master node (communication module or redundant module) and multiple slave nodes (I / O modules, with a maximum of 10 I / O modules in actual applications). A single communication module can simultaneously connect to multiple independent CNET buses (6 in actual applications). This design inherits the mature technological advantages of RS485: differential signal transmission has strong anti-interference capabilities, suitable for complex electromagnetic environments in industrial settings. In half-duplex mode, the master node exclusively controls the bus, while slave nodes only respond when a request is received, naturally adapting to the "polling-response" interaction logic of DCS systems. At the character encoding level, the physical layer adopts an asynchronous 11-bit character structure (1 start bit + 8 data bits + 1 parity bit + 1 stop bit), eliminating the need for an additional synchronization clock signal. Self-synchronization at the receiving end is achieved through the start and stop bits, simplifying hardware design complexity. Simultaneously, the parity bit provides real-time error detection capabilities for single-byte data, ensuring the fundamental reliability of the underlying transmission.

[0072] This physical layer design improves communication efficiency in multiple dimensions. First, the half-duplex master-slave architecture and multi-bus parallel mechanism directly increase system throughput. Traditional full-duplex buses need to handle bidirectional data conflicts, while CNET's half-duplex mode completely avoids bus contention through unified scheduling by the master node, thus improving bandwidth utilization. A single communication module supports the parallel operation of 6 buses, which is equivalent to distributing the communication tasks of the I / O module to 6 independent channels for synchronous execution—assuming that the polling cycle of a single bus polling 10 nodes is 20ms, 6 buses can compress the overall polling cycle to 3.3ms, meeting the stringent requirements of nuclear power plants for "millisecond-level response" to control commands.

[0073] Secondly, at the lightweight asynchronous character encoding level, the lightweight asynchronous design of the character encoding structure reduces transmission overhead and processing latency. The asynchronous transmission character structure eliminates the complex frame headers and trailers (such as Ethernet preambles) of synchronous protocols. Each character is transmitted independently, eliminating the need for the receiving end to maintain global clock synchronization. It only needs to trigger the receiving state machine via the start bit, significantly reducing the hardware processing complexity of the slave node. Taking 8 valid data bits as an example, the transmission efficiency (valid data percentage) of a single character reaches 72.7%, which is about 15% higher than some synchronous protocols (such as those containing more control bits). The introduction of a parity bit enables real-time detection of single-byte errors without significantly increasing the transmission load (only adding 1 bit). That is, when a slave node receives a character with a parity error, it can immediately discard it and wait for the master node to retransmit it, preventing invalid data from entering the link layer for processing and reducing the error correction pressure on upper-layer protocols from the source.

[0074] Finally, regarding industrial standard hardware compatibility, the widespread application of RS485 eliminates the need for dedicated communication chips in the CNET physical layer. It can be directly implemented via the UART interface of a common industrial-grade MCU (such as STM32), reducing hardware costs by more than 40% compared to dedicated buses (such as the Profibus-DP bus). This "de-specialization" design not only reduces chip procurement costs but also avoids the startup delays caused by complex initialization processes of dedicated protocol chips, allowing the communication module to quickly enter a working state after power-on. Furthermore, the bus topology supports hot-swappable maintenance. When a single I / O module or bus fails, the device can be replaced without interrupting communication on other buses, further reducing downtime caused by system maintenance and ensuring overall communication efficiency from an availability perspective.

[0075] The above is an introduction to the CNET physical layer in this embodiment. Next, the data link layer of CNET in this embodiment will be introduced.

[0076] It should be noted beforehand that data interaction between the computing module and the I / O module is achieved by the communication module forwarding request packets sent by the computing module to the I / O module and sending back response packets from the I / O module in response to those request packets. The main role of the data link layer is to define the frame format of the request and response packets during this data interaction process, thereby maximizing the precision and transmission efficiency of data interaction between the computing module and the I / O module.

[0077] Specifically, the data link layer adopts an asynchronous transmission mode using DLPDUs with non-fixed field lengths. The data link layer defines the request frame structure of request packets and the response frame structure of response packets. Both the request and response frame structures include: synchronization bytes, start delimiter, length field, repeat length field, destination address, source address, function code, data unit, frame check sequence, and end delimiter. The core characteristics and functions of the data link layer can be summarized in three aspects: a flexible adaptation mechanism for dynamic frame lengths, a precise addressing architecture for directional interaction, and dual verification and process optimization to ensure a balance between reliability and efficiency.

[0078] See Tables 1-3 below. Tables 1-2 are the request frame formats of the master station (i.e., the computing module), and Table 3 is the response frame format of the slave station (corresponding to the I / O module).

[0079] Table 1

[0080]

[0081] Table 2

[0082]

[0083] Table 3

[0084]

[0085] As can be seen from the design of request and response frames in Tables 1-3 above, both request and response frames defined by the data link layer include a synchronization byte (SYNC), a start delimiter (SD), a length field (LENGTH), a repeat length field (REP_LENGTH), a destination address (DEST_ADDR), a source address (SRC_ADDR), a function code (FUNC_CODE), a data unit (DATA_UNIT), a frame check sequence (FCS), and an end delimiter (ED). The non-fixed field length is a core innovation; the length of the data unit (carrying I / O module status data or control commands) can be dynamically adjusted according to actual business needs, avoiding redundant transmission caused by fixed frame formats in general protocols (such as Modbus fixed frame headers accounting for up to 40%). The asynchronous transmission mode is deeply adapted to the RS485 half-duplex architecture of the physical layer, achieving rapid frame boundary identification through "synchronization byte + delimiter," without relying on strict clock synchronization, simplifying the parsing logic of the slave node.

[0086] This design for the data link layer improves communication efficiency in several ways. First, regarding the aforementioned flexible adaptation mechanism for dynamic frame length, traditional fixed-frame protocols (such as Profibus-DP) require filling fixed fields to meet format requirements regardless of data size. In contrast, the CNET data link layer in this embodiment can dynamically generate the frame body based on the actual data unit length. When transmitting simple control commands (assuming a single-channel switch operation with a data unit of only 1 byte), the frame length can be compressed to a minimum of 12 bytes, reducing redundant bytes by 30%-50% compared to fixed-frame protocols. When transmitting multi-channel analog data (data units up to 50 bytes), the frame length automatically expands to avoid the overhead of multiple packet transmissions.

[0087] Secondly, at the level of the precise addressing architecture for targeted interaction, the destination address field (8 bits, supporting 256 slave nodes) allows the master node's processing module to precisely address specific I / O modules. Slave node I / O modules only continue processing subsequent fields when they parse their own address; otherwise, the frame is discarded. This mechanism, combined with the "address field at the front" frame structure design (the address field is located in the 3rd and 4th bytes after the delimiter), allows slave nodes to quickly complete address matching after receiving the first 4 bytes. Compared to the mechanism in general protocols that requires parsing the entire frame header to determine whether to receive, this improves single-frame filtering efficiency by 60%. For example, when the master node polls 10 slave nodes, each slave node only needs to process an average of 10% of the total number of frames, reducing the CPU load caused by invalid frame parsing by 70%. This frees up more resources for I / O modules to be used for real-time data processing, thereby improving communication efficiency.

[0088] Finally, regarding the balance between reliability and efficiency through dual verification and process optimization, the "dual verification" design of the length field and the repeat length field ensures that the receiving end verifies the length consistency before parsing the frame, avoiding invalid parsing of the entire frame due to transmission errors. The Frame Check Sequence (FCS) verifies the entire frame data, providing a more powerful error detection capability than physical layer parity checking, reducing the probability of frame retransmission due to bit errors to below 0.1%. This two-layer mechanism of "single-byte parity check + whole-frame CRC check" almost eliminates duplicate interactions caused by data errors with only a 1.5% increase in transmission overhead. Compared to the mechanism in general protocols that relies on upper-layer retransmission, the communication efficiency is significantly improved.

[0089] The above is an introduction to the CNET data link layer in this embodiment. Next, the application layer of CNET in this embodiment will be introduced.

[0090] In this embodiment, the application layer of the CNET protocol serves as the top layer for data interaction. The application layer is mainly used to detect data interaction anomalies in the request and response packets transmitted between the computing module and the I / O module when the computing module interacts with the communication module through the I / O module, thereby detecting possible data interaction anomalies during the communication process.

[0091] Specifically, the types of data interaction anomaly detection that the application layer can perform include: I / O address consistency detection, I / O address duplication detection, protocol number validity detection, and module type detection. These four anomaly detection methods will be introduced in turn below.

[0092] First, the execution steps of I / O address consistency detection are introduced. The application layer performs I / O address consistency detection in the following two steps:

[0093] Step 1: Determine the target I / O module address based on the request packet sent to the I / O module by the periodic polling unit.

[0094] The target I / O module address (DA field in Table 2) is dynamically filled by the application layer based on the I / O module's DIP switch address in the current interaction. For example, when the master node communication module needs to communicate with I / O module 1, the DA field of the request packet is assigned the value 0x01 (corresponding to the module's DIP switch address). This address is sent to the bus after being encapsulated by the data link layer along with the request packet. At this time, all I / O modules on the bus will receive the request packet, but the detection mechanism is only triggered after the receiving module parses the data link layer frame header. Specifically, after the slave node I / O module completes the decoding from 8 bits to 11 bits at the physical layer, it first extracts the DA field (destination address) of the data link layer and synchronously reads the physical address set by its own hardware DIP switch (range 0x01~0x0A), thus entering the I / O address consistency verification process.

[0095] Step 2: If the DIP switch address of the target I / O module is inconsistent with that of the I / O module receiving the request packet, the request packet is determined to be abnormal, and the I / O module is controlled to discard the request packet.

[0096] When an address consistency check detects an anomaly—that is, when the target I / O module address is inconsistent with the DIP switch address of this I / O module—the I / O module directly discards the request packet and does not respond to the corresponding response packet. This avoids the master node entering a retransmission process due to an incorrect response, reducing redundant bus traffic. On the other hand, this I / O module internally records this anomaly event, such as the incorrect address, the time of occurrence, and the link number. This information is reported to the communication module during the next normal interaction, allowing the operations and maintenance system to analyze the cause of the address misalignment. This design ensures that the efficiency of the current communication cycle is not affected by abnormal frames and provides complete traceability information for subsequent fault diagnosis.

[0097] The above is an introduction to the I / O address consistency detection process. Next, we will describe the execution process of I / O address duplication detection. Specifically, the execution process of I / O address duplication detection includes the following steps:

[0098] Step 1: If, within a single polling cycle, the periodic polling unit receives at least two response packets with the same address, it is determined that the I / O module associated with the response packet has an address configuration conflict anomaly.

[0099] It should be noted beforehand that the I / O address duplication detection applies to the polling communication process where the communication module polls multiple I / O modules on a single CNET bus. As mentioned earlier, in this embodiment, a single communication module can connect to multiple CNET buses, and each CNET bus can accommodate multiple I / O modules. Therefore, when the communication module communicates with multiple I / O modules on a CNET bus, to prevent multiple I / O modules from simultaneously competing for the same CNET bus, the communication module needs to sequentially poll all I / O modules on a CNET bus using a built-in periodic polling unit and a pre-set polling period.

[0100] The I / O address duplication detection process is specifically designed for the communication module's polling of various I / O modules. In this process, the communication module sends request packets to each I / O module on the CNET bus in a preset order. Each slave node, upon receiving a request packet, returns a response packet via the corresponding link. The application layer's duplication detection mechanism is only effective within a single polling cycle. According to the protocol definition, a complete polling cycle encompasses the master node's sequential polling and response reception process for all slave nodes on a given bus (e.g., a 20ms polling cycle for 10 I / O modules). When the master node receives a response packet, it first parses the SA field (source address, i.e., the I / O module's DIP switch address, ranging from 0x01 to 0x0A) of the data link layer and extracts it to the application layer's temporary buffer, forming the response address list for that cycle.

[0101] The key technical aspect of this process lies in real-time address caching and cycle isolation: the communication module maintains an independent address cache space for each CNET bus, clearing the cache at the start of each polling cycle to ensure that only the response addresses within the current cycle are stored. For example, when the communication module receives responses from 10 I / O modules sequentially within a 20ms cycle, the SA field of each response packet (e.g., 0x03, 0x05, 0x03) is stored in the cache list in the order of reception. The detection mechanism continuously monitors this list during the cycle, and if the same address (e.g., 0x03) appears twice or more, the duplicate address determination logic is immediately triggered. This cycle-based isolation design avoids cross-cycle address confusion and ensures that the detection results only reflect the immediate state during the current polling process.

[0102] The above describes the process for I / O address duplication detection. Next, we will describe the execution process for protocol number validity detection. Specifically, the protocol number validity detection execution process includes the following three steps:

[0103] Step 1: Obtain the protocol number of the request packet sent by the periodic polling unit.

[0104] In the data interaction scenario of this embodiment, the request packets sent by the communication module (specifically, its internal periodic polling unit) to each I / O module all contain a 16-bit protocol number field. This field is used to identify the protocol version and function type of the request packet. When the I / O module receives the request packet, the application layer first strips the data link layer encapsulation, extracts the protocol number, and compares it with a preset range (0x0001~0xFFFF): if the protocol number is 0x0000 or exceeds 0xFFFF, it is determined to be an invalid protocol number, and an exception response process is immediately triggered; if the protocol number is within the valid range, the request packet is allowed to enter the subsequent function code parsing stage.

[0105] Step 2: If the protocol number of the request packet exceeds the preset range, the I / O module that receives the request packet is controlled to send the response packet back to the periodic polling unit based on the data acquisition format.

[0106] When a protocol number is detected to be outside the preset range, the I / O module follows the "safety response first" principle, abandoning the execution of instruction logic and instead generating a response packet according to a fixed data acquisition format to send back to the master node. This response packet contains three key fields: the original error protocol number (fully preserving the illegal protocol number from the request packet for master node traceability), the error code 0xEE (used to identify an invalid protocol number exception), and the module status word (used to characterize the current hardware status of the I / O module, such as normal power supply and communication link connection status). It is worth noting that the generation of the response packet strictly follows the data link layer format of the CNET protocol, only filling in exception information in the application layer data unit to ensure that the master node can parse it correctly.

[0107] The core function of this step is to pre-filter illegal protocol formats. For example, when the communication module mistakenly sends a request packet with protocol number 0x0000 due to a software malfunction, the I / O module can directly identify the anomaly without parsing subsequent function codes, thus avoiding erroneous instruction execution due to protocol version mismatch. Compared to traditional mechanisms that require complete instruction parsing to detect protocol number errors, this mechanism significantly improves the response speed to protocol number anomalies and reduces the unnecessary computational overhead of slave nodes.

[0108] Step 3: Perform field analysis on the response packet to determine whether there are any protocol logic processing anomalies in the periodic polling unit.

[0109] After the master node receives the error response packet, the application layer initiates a three-level progressive analysis process: First, it parses the error code field to confirm whether the protocol number is abnormal. Second, it verifies whether the original protocol number does indeed exceed the preset range. Finally, it combines the historical communication records within the current polling cycle to determine whether there is a persistent protocol logic anomaly—if the same type of anomaly occurs three or more times within a single cycle, it is determined that the protocol processing function of the periodic polling unit in the communication module is faulty.

[0110] The above describes the process for validating the protocol number. Next, we will describe the execution process for module type detection. Specifically, the module type detection execution process includes the following three steps:

[0111] Step 1: For the request packet issued by the periodic polling unit, determine the module type of the associated communication module based on the request packet.

[0112] The module type detection mechanism is used to ensure the functional compatibility between the communication module and the I / O module, so as to avoid instruction failures caused by module type mismatch.

[0113] In the CNET custom protocol framework of this embodiment, the communication module type and I / O module type are defined by both hardware identifiers and protocol fields. The communication module embeds a 2-bit type code (0x01 for digital modules, 0x02 for analog modules, and 0x03 for special function modules) in the control field of the request packet, clearly indicating the instruction types it supports. The I / O module's type is fixed through hardware DIP switch combinations and firmware version information (e.g., 0x01 corresponds to a digital input module, and 0x02 corresponds to an analog output module). When the I / O module receives a request packet, the application layer first parses the control field to obtain the communication module type code, and simultaneously reads the module type identifier from the local hardware configuration, entering a bidirectional type comparison process.

[0114] Step 2: When the module type does not match the module type of the I / O module receiving the request packet, set the response packet fed back by the I / O module to a preset module quality bit to indicate the abnormal state of the communication module.

[0115] If the communication module type code is inconsistent with the I / O module hardware type, when the I / O module generates a response packet, it sets a preset "module type mismatch bit" (7th bit, 0 for normal, 1 for abnormal) in the status field of the data unit. At the same time, it retains key information from the original request packet (such as type code, protocol number, and timestamp) to ensure that the master node communication module can trace the source of the abnormality. It is worth noting that the response packet still follows the CNET protocol frame format for encapsulation, transmitting abnormal information only through changes in the quality bit's status. This does not block the communication link or affect the normal parsing of other fields, thus decoupling the abnormality identifier from functional communication.

[0116] Step 3: Based on the abnormal state and the response format of the protocol number corresponding to the request packet, determine whether the module type of the communication module is consistent with the hardware type of the I / O module, so as to determine whether there is a module type mismatch anomaly in the communication module.

[0117] After receiving the response packet with the quality bit set, the communication module initiates a two-layer logic judgment process. First, it confirms the existence of module type mismatch risk based on the abnormal status bit. Second, it verifies whether the I / O module hardware type supports the instruction function by combining the response format of the protocol number corresponding to the request packet. For example, if protocol number 0x0010 corresponds to an analog calibration instruction, and the target I / O module is a digital input type (hardware type 0x01), the calibration data field in its response format should be all 0s with a mismatch bit. In this case, the master node can clearly determine that the type mismatch causes the function to be unavailable.

[0118] The above provides a detailed description of the physical layer, data link layer, and application layer of the custom control protocol CNET in this embodiment. As mentioned earlier, in this embodiment, the data interaction and communication between the computing module and the I / O module are implemented based on the communication module and the custom CNET protocol architecture defined in this embodiment. The communication module aims to manage data communication between the computing module and the I / O module, and to detect anomalies in each I / O module, the communication module, and the multiple CNET buses, according to a preset communication interaction mechanism within CNET. The preset communication interaction mechanism specifically includes: a periodic polling mechanism, a time synchronization mechanism, and a timeout detection mechanism. Next, these three communication interaction mechanisms will be described in turn with reference to the accompanying drawings of specific embodiments.

[0119] First, let's introduce the periodic polling mechanism. See [link to relevant documentation]. Figure 3The figure is a flowchart illustrating a periodic polling mechanism execution method provided in an embodiment of this application, specifically including the following steps:

[0120] S101: Receive upper-layer instructions from the computing module and convert the upper-layer instructions into the frame format corresponding to CNET to determine the request packet for each I / O module.

[0121] The periodic polling interaction mechanism is implemented by a periodic polling unit set in the communication module. As mentioned earlier, a single communication module can connect to multiple CNET buses, and a single CNET bus can connect to multiple I / O modules. To prevent multiple I / O modules on a single CNET bus from competing for the bus, the periodic polling unit needs to poll the communication with each I / O module sequentially according to a pre-set polling period, thereby ensuring efficient collaboration among multiple I / O modules in a complex bus environment.

[0122] Specifically, the periodic polling unit first receives upper-level control commands from the arithmetic module, such as data acquisition, device control, and status queries. These commands carry key information such as the I / O module address, function code, and data parameters. Following the CNET protocol standard, the polling unit converts the upper-level commands into request packets with a specific frame format—the frame structure contains seven essential fields: synchronization header (2 bytes), source address (SA, 1 byte), destination address (DA, 1 byte), protocol number (2 bytes), data length (1 byte), data unit (N bytes), and frame check sequence (FCS, 2 bytes). The destination address DA directly corresponds to the I / O module's DIP switch address (0x01~0x0A), the protocol number identifies the command type (e.g., 0x0001 for analog signal acquisition, 0x0002 for digital signal output), and the data unit is filled with specific parameters based on the function code, such as the target value of the control command and the channel number of the acquisition command.

[0123] S102: For each of the multiple I / O modules connected to the CNET bus, based on the polling period specified by the periodic polling mechanism, request packets are sent sequentially to each of the I / O modules to receive response packets from each of the I / O modules; the polling period includes the sending time of the request packet and the feedback time of the response packet.

[0124] For multiple I / O modules on each CNET bus, the periodic polling unit addresses them according to the polling cycle execution order. The specific process is as follows: At the start of the polling cycle, the bus counter is initialized, a request packet is sent to the module at the current address, and an acknowledgment timeout timer is started. If an acknowledgment packet is received before the timeout, an FCS check is immediately performed. If successful, the data unit is parsed and forwarded to the arithmetic module; otherwise, the module's status is marked as "checking error." Conversely, if no acknowledgment packet is received within the timeout period, it is determined as "no acknowledgment," the number of failures for that I / O module is recorded, and the module is skipped. The counter is incremented to point to the next address. After traversing the addresses of all I / O modules, a single bus polling cycle is completed, and each bus polling runs independently (e.g., three CNET buses can be polled simultaneously).

[0125] The core of this step lies in avoiding bus application conflicts among multiple I / O modules through a periodic polling mechanism. For example, when the polling unit sends a request to module 0x03, even if module 0x01 does not respond midway, the request packet for 0x01 will not be sent again until the next cycle re-traversal. This "sequential unicast + timeout skip" strategy, compared to the traditional polling mechanism, can ensure the throughput of effective data even when the bus is fully loaded (i.e., the CNET bus has already handled the maximum number of I / O modules).

[0126] S103: If the response packet is not received within the polling period or the response packet verification is incorrect, it is determined that the associated I / O module has no response and the polling proceeds to the next I / O module.

[0127] When no response or a response packet verification error occurs, the polling unit performs tiered fault tolerance: upon the first anomaly, only the log is logged and polling continues. If the same module experiences anomalies for three consecutive cycles, a deep diagnostic process is triggered. This involves sending a dedicated diagnostic frame (protocol number 0xFFFF) to request the I / O module to return its hardware status. If the diagnostic frame still receives no response, the module is deemed faulty, and the maintenance system is notified via a redundant channel, switching to a backup module. This progressive fault determination mechanism effectively distinguishes between temporary link interference and actual device failure.

[0128] To better understand the periodic polling mechanism executed by the periodic polling unit, the implementation process of the periodic polling mechanism will be summarized and described below with specific diagrams.

[0129] See Figure 4This figure illustrates a periodic polling mechanism provided in an embodiment of this application. The polling period between the communication module and a single I / O module is strictly fixed at 2ms. This polling period can be divided into: the request packet sending time (T1=2ms) and the response packet feedback time (T2=2ms), which together form a complete communication cycle loop. The request packet adopts a segmented structure of "header + body," with an interval T3 between the two segments exceeding 20μs to provide the I / O module with the necessary address resolution window. The specific process is as follows: the communication module first sends a header (containing key identifiers such as the I / O address and frame synchronization code), keeping the bus silent during the T3 interval, allowing the I / O module to complete address resolution within 20μs. If the address matches (i.e., the target address in the header matches the local DIP switch address), the I / O module continues to receive the subsequent instruction body; if the address does not match, the request packet is immediately discarded without response. This segmented design prioritizes address identification, preventing invalid data from consuming bus resources. Real-world testing shows that it can reduce redundant data transmission by 30%, while ensuring that the time margin for address resolution meets industrial-grade real-time requirements.

[0130] The above is an introduction to the periodic polling mechanism. Next, we will introduce the time synchronization mechanism handled by the communication module, which is implemented by the time synchronization unit set in the communication module.

[0131] See Figure 5 The figure is a flowchart illustrating a time synchronization mechanism execution method provided in an embodiment of this application, specifically including the following steps:

[0132] S201: When the local clock of the communication module triggers the time synchronization processing time specified by the time synchronization processing mechanism, the time synchronization request sending process is initiated to send time synchronization requests to the multiple I / O modules connected to each of the CNET buses; the time synchronization request is a broadcast frame;

[0133] S202: For the CNET bus with the most connected I / O modules among all the CNET buses, after all the I / O modules on the CNET bus have completed polling, the time synchronization request is sent to the multiple I / O modules connected to each of the CNET buses.

[0134] The time synchronization mechanism is a core function ensuring clock synchronization between all I / O modules and communication modules. When the local clock count reaches a preset time, the time synchronization unit immediately initiates the time synchronization request transmission process. First, it performs bus status detection. If an ongoing polling cycle exists (e.g., the polling of an I / O module on a CNET bus is incomplete), it prioritizes waiting for that bus to complete its current polling cycle, avoiding time synchronization broadcast interference with normal data interaction. Specifically, for the CNET bus with the most connected I / O modules (i.e., the bus with the heaviest load, such as a bus with 8 modules), the time synchronization unit mandates that it complete all module polling before sending the time synchronization request, ensuring the bus is in a low-load state when the broadcast frame is sent, reducing the probability of communication conflicts.

[0135] The time synchronization request is sent in the form of a broadcast frame. The frame structure includes a 32-bit timestamp, a time synchronization command code, a bus identifier, and other key information. Before transmission, the time synchronization unit performs three CRC checks on the timestamp (covering the year / month / day / hour / minute / second / μs fields) to ensure the integrity of the synchronization data. Taking a typical nuclear power plant scenario as an example, when the local clock reaches 10:00:00.100, the time synchronization unit detects that a bus is still polling the 7th module. It then waits for the module to complete its response (approximately 2ms) before broadcasting the time synchronization frame to all buses, ensuring that each I / O module receives the synchronization signal in an environment free from data conflicts.

[0136] S203: After the time synchronization requests for each of the CNET buses have been sent, a time synchronization completion instruction is sent to the periodic polling unit so that the periodic polling unit re-executes the periodic polling mechanism for each of the I / O modules.

[0137] The transmission of time synchronization broadcast frames follows a "no-acknowledgment" mechanism. When the I / O module receives a broadcast frame, it does not need to send an acknowledgment packet; instead, it directly parses the timestamp field and compares it with the local clock. This design avoids the acknowledgment storm problem of traditional time synchronization protocols, compressing the bus occupancy time of the time synchronization process to the transmission time of a single broadcast frame, thereby improving communication efficiency. Simultaneously, the time synchronization processing unit embeds a "time synchronization priority flag" in the broadcast frame to ensure that the bus arbiter prioritizes forwarding time synchronization data. Even under high bus load scenarios, the transmission delay of the broadcast frame can be controlled within 20μs.

[0138] After all time synchronization broadcasts on the CNET buses are completed, the time synchronization processing unit sends a "time synchronization complete command" to the periodic polling unit, thereby triggering the restart of the polling mechanism on each CNET bus. Upon receiving the command, the periodic polling unit immediately resets the polling counter of each bus, ensuring that the first poll after time synchronization is based on the synchronized clock, thus achieving a seamless "time synchronization-data interaction" process. In the restart logic, the polling unit prioritizes handling any delays that may occur during time synchronization: if the time synchronization operation causes the cumulative deviation of the polling cycle to exceed 10μs, an "empty polling cycle" is automatically inserted to ensure that subsequent polling strictly adheres to a fixed 2ms cycle.

[0139] The above is an introduction to the time synchronization mechanism. Next, we will introduce the timeout detection mechanism handled by the communication module. The timeout detection mechanism is implemented by the timeout detection unit set in the communication module.

[0140] See Figure 6 The figure is a flowchart illustrating a timeout detection mechanism execution method provided in an embodiment of this application, specifically including the following steps:

[0141] S301: If the periodic polling unit does not receive a response packet from the I / O module within a single polling cycle, it determines that the I / O module has no response and records the number of times the I / O module has no response.

[0142] In this embodiment, the core function of the timeout detection mechanism is to ensure the reliability of data interaction between master and slave nodes (i.e., the communication module and the I / O module). The timeout detection unit, as the executing entity of this mechanism, is tightly coupled with the periodic polling process. By dynamically recording the number of unanswered requests and comparing them with a threshold, it effectively distinguishes between temporary link interference and actual device failures.

[0143] Specifically, the timeout detection unit is deeply integrated with the periodic polling mechanism, monitoring the response packet reception status in real time within each 2ms polling cycle. When the periodic polling unit sends a request packet to the target I / O module, the timeout detection unit simultaneously starts a 2ms countdown timer (equal in length to the polling cycle). If a complete response packet (including a valid frame with a passed CRC check) is not received before the countdown ends, the module is immediately determined to have "no response in a single cycle," and the number of times the I / O module has not responded is recorded. After recording, the timeout detection unit sends a "skip instruction" to the periodic polling unit, causing it to immediately terminate the current module interaction and proceed to the next module's polling. This "periodic real-time detection" mechanism ensures that communication anomalies in a single module do not occupy the polling time of subsequent modules, guaranteeing the temporal independence of parallel communication among multiple modules.

[0144] S302: If the number of unanswered attempts reaches a preset threshold, the I / O module is determined to be faulty.

[0145] Furthermore, to avoid misjudgments caused by single interference, the "deep fault diagnosis process" is triggered only when the no-response counter of a certain I / O module reaches a preset threshold (usually 3 times), that is, when no valid response is received for 3 consecutive polling cycles (6ms). Before this, the first two no-response attempts are only recorded as early warnings and do not trigger hardware fault determination, giving time for temporary link recovery (e.g., a momentary poor contact at a terminal block may recover within 2ms). During the deep diagnosis phase, the detection unit, in conjunction with the periodic polling unit, sends dedicated test frames. If the test frame still has no response or a verification error, the module is officially determined to be "faulty," its status is marked as "offline," and a fault alarm is sent to the maintenance system through redundant communication channels to effectively distinguish between occasional and permanent faults of the I / O module.

[0146] This application provides a distributed control system and control network. The distributed control system includes: a computing module, at least one communication module, and multiple I / O modules. Each communication module has a separately associated redundant communication module. Each I / O module is connected to the communication module and the associated redundant communication module via at least two CNET buses to form redundant communication links. The CNET is a custom control network protocol, and the master node of the CNET is the communication module and the associated redundant communication module, while the slave node of the CNET is the I / O module. The communication module is used to manage data communication between the computing module and the I / O modules according to a preset communication interaction mechanism within the CNET, and to detect anomalies in each I / O module, the communication module, and the multiple CNET buses. Through the custom CNET protocol, a protocol stack can be customized for the specific data interaction needs of the distributed control system in a nuclear power plant, avoiding the impact of redundant functional modules in general protocols on data transmission efficiency and reducing unnecessary data transmission overhead. Meanwhile, CNET employs a master-slave architecture, with the communication module as the master node and the I / O module as the slave node. The communication module controls the communication flow between the computing module (CPU module) and the I / O module, thereby eliminating latency caused by node contention in distributed protocols and improving communication efficiency. Furthermore, each I / O module is connected to the communication module and redundant communication modules via at least two CNET buses, forming physical layer redundancy. When a single bus or communication module fails, the redundant link can seamlessly take over communication, avoiding retransmissions, interruptions, or system restarts caused by faults, ensuring data transmission continuity, reducing unnecessary waiting time, and thus improving communication efficiency.

[0147] The following describes a control network provided by an embodiment of this application. The control network described below can be referred to in correspondence with the distributed control system described above.

[0148] This application provides a control network for a distributed control system. The distributed control system includes a computing module, at least one communication module, and multiple I / O modules. Each communication module has a separately associated redundant communication module. Each I / O module is connected to the communication module and the associated redundant communication module through at least two CNET buses to form redundant communication links. The CNET is a custom control network protocol, and the master node of the CNET is the communication module and the associated redundant communication module, while the slave node of the CNET is the I / O module.

[0149] The communication module is used to manage data communication between the computing module and the I / O module according to the preset communication interaction mechanism in the CNET, as well as to detect anomalies in each of the I / O modules, the communication module, and the multiple CNET buses.

[0150] In one possible implementation, multiple I / O modules are connected to each of the CNET buses; the preset communication interaction mechanism includes a periodic polling mechanism, and the communication module includes a periodic polling unit, which is specifically used for:

[0151] Receive upper-layer instructions from the computing module and convert the upper-layer instructions into the frame format corresponding to CNET to determine the request packets for each I / O module;

[0152] For each of the multiple I / O modules connected to the CNET bus, a request packet is sent sequentially to each I / O module based on the polling period specified by the periodic polling mechanism, and a response packet is received from each I / O module; the polling period includes the sending time of the request packet and the feedback time of the response packet.

[0153] If no response packet is received within the polling period or the response packet verification error occurs, it is determined that the associated I / O module has no response and the polling proceeds to the next I / O module.

[0154] The polling of the multiple I / O modules on each CNET bus is independent of each other, and the request packet sent by the periodic polling unit remains unique within a single polling cycle for each CNET bus.

[0155] In one possible implementation, the preset communication interaction mechanism includes a time synchronization mechanism; the communication module includes a time synchronization module, which is specifically used for:

[0156] When the local clock of the communication module triggers the time synchronization processing time specified by the time synchronization processing mechanism, the time synchronization request sending process is initiated to send time synchronization requests to the multiple I / O modules connected to each of the CNET buses; the time synchronization request is a broadcast frame.

[0157] For the CNET bus with the most connected I / O modules, after all the I / O modules on the CNET bus have completed polling, the time synchronization request is sent to the multiple I / O modules connected to each CNET bus.

[0158] After the time synchronization requests for each of the CNET buses have been sent, a time synchronization completion instruction is sent to the periodic polling unit so that the periodic polling unit re-executes the periodic polling mechanism for each of the I / O modules.

[0159] In one possible implementation, the CNET includes: a physical layer, a data link layer, and an application layer;

[0160] The physical layer adopts a bus-type RS485 half-duplex link architecture, and a single communication module supports the connection of multiple CNET buses; the physical layer adopts an asynchronous transmission character encoding structure, and each character includes: a single start bit for synchronous data reception, multiple data bits for carrying valid data, a single parity bit for detecting single-byte transmission errors, and a single stop bit for indicating the end of the character;

[0161] The data link layer adopts an asynchronous transmission mode of DLPDU with non-fixed field length. The data link layer is used to define the request frame structure of the request packet and the response frame structure of the response packet. The request frame structure and the response frame structure both include: synchronization byte, start delimiter, length field, repeat length field, destination address, source address, function code, data unit, frame check sequence, and end delimiter.

[0162] The application layer is used to detect data interaction anomalies when the communication module and the I / O module interact with each other.

[0163] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for distributed control systems and control networks, since they are basically similar to the method embodiments, the description is relatively simple, and relevant parts can be referred to the descriptions in the method embodiments. The distributed control systems and control networks described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0164] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A distributed control system, characterized in that, include: The system comprises a computing module, at least one communication module, and multiple I / O modules. Each communication module has a separately associated redundant communication module. Each I / O module is connected to the communication module and the associated redundant communication module via at least two CNET buses to form a redundant communication link. The CNET is a custom control network protocol, and the master node of the CNET is the communication module and the associated redundant communication module, while the slave node of the CNET is the I / O module. The communication module is used to manage data communication between the computing module and the I / O module according to the preset communication interaction mechanism in the CNET, as well as to detect anomalies in each of the I / O modules, the communication module, and the multiple CNET buses. Multiple I / O modules are connected to each of the CNET buses; The preset communication interaction mechanism includes a periodic polling mechanism, and the communication module includes a periodic polling unit, which is specifically used for: Receive upper-layer instructions from the computing module and convert the upper-layer instructions into the frame format corresponding to CNET to determine the request packets for each I / O module; For each of the multiple I / O modules connected to the CNET bus, a request packet is sent sequentially to each I / O module based on the polling period specified by the periodic polling mechanism, and a response packet is received from each I / O module; the polling period includes the sending time of the request packet and the feedback time of the response packet. If no response packet is received within the polling period or the response packet verification error occurs, it is determined that the associated I / O module has no response and the polling proceeds to the next I / O module. The polling of multiple I / O modules on each CNET bus is independent of each other, and the request packet sent by the periodic polling unit remains unique within a single polling cycle for each CNET bus. The CNET includes: the physical layer, the data link layer, and the application layer; The physical layer adopts a bus-type RS485 half-duplex link architecture, and a single communication module supports the connection of multiple CNET buses; the physical layer adopts an asynchronous transmission character encoding structure, and each character includes: a single start bit for synchronous data reception, multiple data bits for carrying valid data, a single parity bit for detecting single-byte transmission errors, and a single stop bit for indicating the end of the character; The data link layer adopts an asynchronous transmission mode of DLPDU with non-fixed field length. The data link layer is used to define the request frame structure of the request packet and the response frame structure of the response packet. The request frame structure and the response frame structure both include: synchronization byte, start delimiter, length field, repeat length field, destination address, source address, function code, data unit, frame check sequence, and end delimiter. The application layer is used to detect data interaction anomalies when the communication module and the I / O module interact with each other.

2. The system according to claim 1, characterized in that, The preset communication interaction mechanism includes a time synchronization processing mechanism; the communication module includes a time synchronization processing unit, which is specifically used for: When the local clock of the communication module triggers the time synchronization processing time specified by the time synchronization processing mechanism, the time synchronization request sending process is initiated to send time synchronization requests to the multiple I / O modules connected to each of the CNET buses; the time synchronization request is a broadcast frame. For the CNET bus with the most connected I / O modules, after all the I / O modules on the CNET bus have completed polling, the time synchronization request is sent to the multiple I / O modules connected to each CNET bus. After the time synchronization requests for each of the CNET buses have been sent, a time synchronization completion instruction is sent to the periodic polling unit so that the periodic polling unit re-executes the periodic polling mechanism for each of the I / O modules.

3. The system according to claim 1, characterized in that, The data interaction anomaly detection includes: I / O address consistency detection, I / O address duplication detection, protocol number validity detection, and module type detection; The execution steps of the I / O address consistency check include: The target I / O module address is determined based on the request packet sent to the I / O module by the periodic polling unit. If the target I / O module address is inconsistent with the DIP switch address of the I / O module receiving the request packet, the request packet is determined to be abnormal, and the I / O module is controlled to discard the request packet. The execution steps of the I / O address repeatability detection include: If, within a single polling cycle, the periodic polling unit receives at least two response packets with the same address, it is determined that the I / O module associated with the response packet has an address configuration conflict anomaly. The execution steps for the protocol number validity check include: For the request packets sent by the periodic polling unit, obtain the protocol number of the request packet; If the protocol number of the request packet exceeds the preset range, the I / O module that receives the request packet will send the response packet back to the periodic polling unit based on the data acquisition format. The response packet is analyzed to determine whether there is any protocol logic processing abnormality in the periodic polling unit; The execution steps for the module type detection include: For the request packets issued by the periodic polling unit, the module type of the associated communication module is determined based on the request packets; When the module type does not match the module type of the I / O module receiving the request packet, the response packet fed back by the I / O module is set to a preset module quality bit to indicate the abnormal state of the communication module. Based on the abnormal state and the response format of the protocol number corresponding to the request packet, it is determined whether the module type of the communication module is consistent with the hardware type of the I / O module, so as to determine whether there is a module type mismatch anomaly in the communication module.

4. The system according to claim 1, characterized in that, The preset communication interaction mechanism includes a timeout detection mechanism, and the communication module includes a timeout detection unit, which is specifically used for: If the periodic polling unit does not receive a response packet from the I / O module within a single polling cycle, it determines that the I / O module has no response and records the number of times the I / O module has no response. If the number of unresponsive events reaches a preset threshold, the I / O module is determined to be faulty.

5. A control network, characterized in that, This invention relates to a distributed control system, comprising: a computing module, at least one communication module, and multiple I / O modules. Each communication module has a separately associated redundant communication module. Each I / O module is connected to the communication module and the associated redundant communication module via at least two CNET buses to form a redundant communication link. The CNET is a custom control network protocol, and the master node of the CNET is the communication module and the associated redundant communication module, while the slave node of the CNET is the I / O module. The communication module is used to manage data communication between the computing module and the I / O module according to the preset communication interaction mechanism in the CNET, as well as to detect anomalies in each of the I / O modules, the communication module, and the multiple CNET buses. Each of the CNET buses connects to multiple I / O modules; the preset communication interaction mechanism includes a periodic polling mechanism, and the communication module includes a periodic polling unit, which is specifically used for: Receive upper-layer instructions from the computing module and convert the upper-layer instructions into the frame format corresponding to CNET to determine the request packets for each I / O module; For each of the multiple I / O modules connected to the CNET bus, a request packet is sent sequentially to each I / O module based on the polling period specified by the periodic polling mechanism, and a response packet is received from each I / O module; the polling period includes the sending time of the request packet and the feedback time of the response packet. If no response packet is received within the polling period or the response packet verification error occurs, it is determined that the associated I / O module has no response and the polling proceeds to the next I / O module. The polling of multiple I / O modules on each CNET bus is independent of each other, and the request packet sent by the periodic polling unit remains unique within a single polling cycle for each CNET bus. The CNET includes: the physical layer, the data link layer, and the application layer; The physical layer adopts a bus-type RS485 half-duplex link architecture, and a single communication module supports the connection of multiple CNET buses; the physical layer adopts an asynchronous transmission character encoding structure, and each character includes: a single start bit for synchronous data reception, multiple data bits for carrying valid data, a single parity bit for detecting single-byte transmission errors, and a single stop bit for indicating the end of the character; The data link layer adopts an asynchronous transmission mode of DLPDU with non-fixed field length. The data link layer is used to define the request frame structure of the request packet and the response frame structure of the response packet. The request frame structure and the response frame structure both include: synchronization byte, start delimiter, length field, repeat length field, destination address, source address, function code, data unit, frame check sequence, and end delimiter. The application layer is used to detect data interaction anomalies when the communication module and the I / O module interact with each other.

6. The control network according to claim 5, characterized in that, The preset communication interaction mechanism includes a time synchronization processing mechanism; the communication module includes a time synchronization processing module, which is specifically used for: When the local clock of the communication module triggers the time synchronization processing time specified by the time synchronization processing mechanism, the time synchronization request sending process is initiated to send time synchronization requests to the multiple I / O modules connected to each of the CNET buses; the time synchronization request is a broadcast frame. For the CNET bus with the most connected I / O modules, after all the I / O modules on the CNET bus have completed polling, the time synchronization request is sent to the multiple I / O modules connected to each CNET bus. After the time synchronization requests for each of the CNET buses have been sent, a time synchronization completion instruction is sent to the periodic polling unit so that the periodic polling unit re-executes the periodic polling mechanism for each of the I / O modules.

7. The control network according to claim 5, characterized in that, The CNET includes: the physical layer, the data link layer, and the application layer; The physical layer adopts a bus-type RS485 half-duplex link architecture, and a single communication module supports the connection of multiple CNET buses; the physical layer adopts an asynchronous transmission character encoding structure, and each character includes: a single start bit for synchronous data reception, multiple data bits for carrying valid data, a single parity bit for detecting single-byte transmission errors, and a single stop bit for indicating the end of the character; The data link layer adopts an asynchronous transmission mode of DLPDU with non-fixed field length. The data link layer is used to define the request frame structure of the request packet and the response frame structure of the response packet. The request frame structure and the response frame structure both include: synchronization byte, start delimiter, length field, repeat length field, destination address, source address, function code, data unit, frame check sequence, and end delimiter. The application layer is used to detect data interaction anomalies when the communication module and the I / O module interact with each other.

Images