Communication protection method, system, electronic device and computer readable storage medium

Abstract

The application relates to the technical field of communication, in particular to a communication protection method and system, an electronic device and a computer readable storage medium, the method comprising: sequentially analyzing data packets, and constructing and maintaining the corresponding relationship between requests and responses according to the analysis results. The running state of the protected device is monitored through multi-dimensional indexes, and it is judged whether the protected device has a fault. When it is determined that the protected device has a fault, the requests in the waiting response state are acquired, an abnormal response conforming to a standard format is constructed for each waiting response request, and the abnormal response is sent to the corresponding upstream device. After the abnormal response is sent, a physical bypass switching is performed. The application can obtain an abnormal processing signal immediately after the fault occurs, avoids state abnormal problems such as protocol timeout and connection disconnection, and improves the real-time performance, stability and maintainability of the industrial control system.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication protection method, system, electronic device, and computer-readable storage medium. Background Technology

[0002] In mission-critical scenarios such as industrial control, fault-tolerance methods based on link redundancy are a common means of ensuring communication reliability. These existing technologies typically rely on physical layer signal fault detection, switching services from the faulty primary link to a backup link via hardware or software, and synchronizing data before and after the switch.

[0003] However, this type of solution has significant drawbacks: First, the lag in link switching causes upstream devices to experience communication interruptions of hundreds of milliseconds to several seconds, which can easily lead to protocol timeouts, connection drops, and abnormal states. Second, the processing granularity is coarse, limited to overall link or device-level switching, lacking fine-grained state tracking at the request level. This results in long system recovery times and high resource consumption, making it difficult to meet the needs of high real-time scenarios such as industrial automation. Summary of the Invention

[0004] This application provides a communication protection method, system, electronic device, and computer-readable storage medium that can immediately obtain abnormal handling signals after a fault occurs, avoiding abnormal status problems such as protocol timeout and connection disconnection, and improving the real-time performance, stability, and maintainability of industrial control systems.

[0005] Firstly, this application provides a communication protection method, comprising: sequentially parsing data packets, and constructing and maintaining a request-response correspondence based on the parsing results, wherein the request-response correspondence includes at least the response status corresponding to each parsed data packet; monitoring the operating status of the protected device through multi-dimensional indicators to determine whether the protected device has malfunctioned; when a malfunction is determined in the protected device, obtaining requests with a response status of "waiting for response" from the request-response correspondence; constructing an abnormal response conforming to a standard format for each "waiting for response" request according to the protocol specification, and sending the abnormal response to the corresponding upstream device; and performing a physical bypass switch after the abnormal response is sent, switching the communication link from the normal path to the bypass path.

[0006] In some implementations, parsing data packets sequentially includes parsing at least one of the physical layer, link layer, network layer, transport layer, and application layer, extracting protocol fields and identifying whether the data packet type is a request or a response, and identifying the pairing relationship between requests and responses.

[0007] In some implementations, the correspondence between requests and responses is a request-response pairing table. The request-response pairing table adopts a circular buffer structure and stores the sequence number, timestamp, and response status in the form of triples. The response status is waiting for response, completed, or timed out.

[0008] In some implementations, the operating status of the protected equipment is monitored using multi-dimensional indicators to determine whether a fault has occurred. This includes: real-time acquisition of multi-dimensional indicators of the protected equipment, which may include one or more of the following: operating current, operating voltage, heartbeat response status, protocol response time, and communication error rate. A weighted scoring mechanism is employed to calculate a fault score based on preset weights for each dimension and the multi-dimensional indicators. The fault score is positively correlated with the degree of anomaly in each dimension of the multi-dimensional indicators. When the fault score is greater than or equal to a preset fault threshold, the protected equipment is deemed to be faulty.

[0009] In some implementations, when the fault score is less than a preset fault threshold and greater than or equal to a preset warning threshold, the monitoring frequency of the protected equipment is increased, and requests with a response status of "waiting for response" in the request-response correspondence are obtained in advance.

[0010] In some implementations, a standard-formatted exception response includes at least one of the following: For the ModbusTCP protocol, the function code is set to the original requested function code plus 0x80, and the exception code is set to 0x04. For the Profinet RT protocol, IOPS and IOCS are set to an invalid state, and the IO data is set to a preset safe value. For the CAN bus protocol, an exception message frame conforming to the CAN protocol specification is constructed.

[0011] In some implementations, after the exception response is sent, the method further includes: buffering newly arrived data packets during the physical bypass switch, and replaying the buffered data packets according to timing and priority after the physical bypass switch is completed.

[0012] Secondly, this application provides a communication protection system, comprising: an upstream communication interface for receiving data packets from an upstream device and sending responses to the upstream device; a protocol parsing and caching module for parsing the transmitted data packets and constructing and maintaining a correspondence between requests and responses, wherein the correspondence between requests and responses includes at least the response status corresponding to each parsed data packet; a device health monitoring module for monitoring the operating status of the protected device through multi-dimensional indicators and determining whether the protected device has malfunctioned; a buffer scanning module for scanning the correspondence between requests and responses and obtaining requests with a response status of "waiting for response" when a malfunction of the protected device is determined; a proxy response generation module for constructing an abnormal response conforming to a standard format according to the protocol specification; a physical bypass control module for performing physical bypass switching, switching the communication link from the normal path to the bypass path; and a downstream communication interface for outputting data packets to downstream devices or bypass channels.

[0013] Thirdly, this application provides a chip for performing the method described in the first aspect above.

[0014] Fourthly, this application provides an electronic device including a processor and a memory, the processor being configured to execute a computer program stored in the memory to implement the method as described in the first aspect above. Alternatively, Electronic devices include chips, as described in the third aspect.

[0015] Fifthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0016] In a sixth aspect, this application provides a computer program product that stores a computer program, which, when executed by a processor, implements the method described in the first aspect above.

[0017] In the technical solution provided in this application, the communication protection system can sequentially parse data packets and construct and maintain a correspondence between requests and responses based on the parsing results. This correspondence includes at least the response status corresponding to each parsed data packet. The system monitors the operating status of the protected device using multi-dimensional indicators to determine if a fault has occurred. When a fault is detected, requests in the pending response state are retrieved from the request-response correspondence. According to the protocol specification, a standard-formatted abnormal response is constructed for each pending response request and sent to the corresponding upstream device. After the abnormal response is sent, a physical bypass switch is performed, switching the communication link from the normal path to the bypass path. The technical solution provided in this application can track the response status of each request by establishing a request-response correspondence, and proactively retrieve pending response requests and construct standard-formatted abnormal responses according to the protocol specification when a device fault occurs, sending them to the upstream device. This ensures that the upstream device receives a protocol-compliant response before the physical link switch, thereby avoiding protocol timeouts and connection interruptions and ensuring the continuous and stable state of the protocol stack.

[0018] Furthermore, by performing deep parsing of data packets and constructing a request-response pairing table, this application can understand the semantics of requests, accurately identify requests awaiting responses, and construct abnormal responses conforming to protocol specifications, thus achieving a leap from passive link switching to proactive protocol proxying. Moreover, the correspondence between requests and responses enables fine-grained processing at the request level, generating proxy responses only for requests awaiting responses, avoiding redundant processing of completed requests; simultaneously, through a timing design that prioritizes sending proxy responses before performing physical bypass switching, the total recovery time is shortened to less than 50ms. By proactively generating and sending abnormal responses conforming to protocol specifications when a fault occurs, this application can significantly improve the real-time performance and reliability of the communication network. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, 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.

[0020] Figure 1 This is a schematic diagram of a system topology for a communication protection method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the communication protection process of a communication protection method provided in an embodiment of this application; Figure 3 This is a schematic diagram of a single switch module of a communication protection method provided in an embodiment of this application; Figure 4 This is a timing interaction diagram of a communication protection method provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0022] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0023] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0024] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0025] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0026] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0027] In critical scenarios such as industrial control and rail transportation, a common solution to ensure data transmission reliability is a fault-tolerant method based on link redundancy and data synchronization. This type of solution constructs primary and backup paths at the physical or link layer to handle single-point failures. Its typical technical features include: relying on signal quality monitoring at the physical or link layer (such as optical power, electrical signal loss, link pulses, etc.) to determine the health status of the link or equipment; when a failure is detected in the primary link or primary equipment (such as signal loss exceeding a set threshold), the system triggers preset switching logic, forcibly migrating the service data flow from the primary path to the backup link or bypass channel; during or after the switching process, the system resynchronizes any untransmitted or unacknowledged data packets on the primary link to the backup link for transmission; when the primary equipment or primary link is repaired and reconnected, the system performs data synchronization again and smoothly switches communication traffic back from the backup link to the primary link, forming a complete closed-loop control.

[0028] However, although the above methods improve system availability to some extent, in actual deployments, especially in real-time scenarios such as industrial automation, the following shortcomings still need to be addressed: First, there is a significant communication interruption in upstream devices. Traditional link switching processes are significantly delayed, typically requiring hundreds of milliseconds or even seconds from the occurrence of a fault to completion. During this period, requests from upstream devices are "suspended," unable to receive timely responses, and are highly susceptible to protocol timeouts. After a timeout, the upstream protocol stack (such as the TCP / IP protocol stack) may trigger retransmissions, force disconnections, or enter an abnormal reset state, severely compromising the system's real-time performance and stability.

[0029] Secondly, the uncertainty of the protocol stack state increases. Because upstream devices may time out while waiting for a response, their protocol stacks are often forced into undefined abnormal states. For example, a TCP connection may be closed by the kernel due to prolonged lack of data exchange; industrial control protocol stacks such as Modbus may lock into error mode due to consecutive timeouts; and the application layer, unable to determine whether the underlying failure is a link failure or a device failure, may adopt inappropriate exception handling strategies. This uncertainty significantly increases the difficulty of system debugging and maintenance costs.

[0030] Furthermore, the overall system recovery time is excessively long. Traditional recovery processes are quite lengthy, typically requiring 3–10 seconds or even longer from the occurrence of a fault to the system fully restoring normal communication. This process includes multiple sequential steps such as fault detection, link switching, data synchronization, upstream device timeout retransmission, TCP connection reconstruction, and application layer initialization. For high real-time scenarios such as industrial automation, such a long recovery time can easily lead to production process interruptions or safety incidents.

[0031] Finally, there is a lack of fine-grained processing at the request level. Traditional solutions have a coarse-grained processing level, representing a link-level or device-level overall switchover. When a device fails, only a few specific requests may not receive a response, but existing solutions will still perform indiscriminate switching and synchronization on all data packets flowing through that link, resulting in significant processing overhead and resource waste. Due to the lack of a status tracking and management mechanism for individual requests, the system cannot distinguish which requests have been completed, which are waiting, and which have timed out, thus making targeted fault-tolerant intervention impossible.

[0032] In summary, traditional technical solutions have long system recovery times and high resource consumption, making them difficult to meet the needs of high real-time scenarios such as industrial automation.

[0033] In view of this, the embodiments of this application provide a communication protection method that can immediately obtain an abnormal handling signal after a fault occurs, avoiding abnormal status problems such as protocol timeout and connection disconnection, and improving the real-time performance, stability and maintainability of the industrial control system.

[0034] Figure 1 This is a schematic diagram of a system topology for a communication protection method provided in an embodiment of this application. Figure 1 As shown, the system may include: an upstream communication interface, a protocol parsing and caching module, a device health monitoring module, a buffer scanning module, a proxy response generation module, a physical bypass control module, a packet replay module, and a downstream communication interface.

[0035] The system includes the following components: An upstream communication interface receives data packets from upstream devices and sends responses to them. A protocol parsing and caching module performs deep protocol parsing on incoming data packets and builds and maintains a request-response pairing table. A device health monitoring module monitors the operating status of the protected device using multi-dimensional indicators to comprehensively determine whether the protected device has malfunctioned. A buffer scanning module scans the request-response pairing table to retrieve pending requests when a malfunction is detected in the protected device. A proxy response generation module constructs an exception response conforming to a standard format according to the protocol specifications. A physical bypass control module sends control signals to the physical bypass channel to perform a physical bypass switch, switching the communication link from the normal path to the bypass path. A packet replay module buffers newly arriving data packets during the physical bypass switch and replays the buffered data packets according to timing and priority after the switch is completed. A downstream communication interface outputs data to downstream devices or the bypass channel.

[0036] In the technical solution provided in this application embodiment, the system is connected in series in the network link where the protected device is located. The upstream communication interface connects to the upstream device, and the downstream communication interface connects to the protected device or a bypass channel. The protocol parsing and caching module performs deep parsing of data packets and maintains a pairing table in normal operating mode, while the data packets are transparently forwarded to the protected device. The device health monitoring module continuously monitors the operating status of the protected device. When a device fault is determined, the buffer scanning module obtains the waiting response request, the proxy response generation module constructs an abnormal response and sends it through the upstream communication interface, and the physical bypass control module performs a switching operation.

[0037] In normal operating mode, all data packets are transparently forwarded to the protected device, while the device health monitoring module continuously performs protocol parsing, cache mirroring, and health monitoring in the background. When a device failure is detected, the system immediately enters fault handling mode, determining the handling strategy through two levels of judgment (whether the device is faulty and whether there is a pending response request). In the case of a pending response request, a proxy response is first generated and sent, and then a physical bypass switch is performed to ensure the continuity of the protocol stack of the upstream device.

[0038] The following is a detailed description of the system's workflow and the implementation details of each module: Figure 2 This is a schematic diagram of the communication protection process of a communication protection method provided in an embodiment of this application. Figure 2 As shown, the communication protection process provided in this application embodiment may include the following steps S201 to S205, specifically: Step S201: Parse the data packets sequentially, and construct and maintain the correspondence between requests and responses based on the parsing results. The correspondence between requests and responses shall include at least the response status corresponding to each parsed data packet.

[0039] The technical solution provided in this application includes parsing data packets sequentially, which involves parsing at least one of the physical layer, link layer, network layer, transport layer, and application layer, extracting protocol fields, identifying the data packet type as a request or response, and identifying the pairing relationship between requests and responses. The request-response pairing relationship can be a request-response pairing table, which can adopt a circular buffer structure. The sequence number, timestamp, and response status are stored in the form of triples (an ordered set containing three elements, in this application, the three elements are a sequence number, a timestamp, and a response status). The response status is either waiting for a response, completed, or timed out. The circular buffer structure can achieve efficient data stream buffering by simulating a ring structure with its ends connected. When the buffer is full, new data will overwrite the oldest data.

[0040] The protocol parsing and caching module performs in-depth parsing on incoming data packets, processing the corresponding protocols at each layer of the OSI seven-layer model. Specifically, at the physical layer, it detects the electrical status of equipment using hardware such as current sensors and voltage monitors. At the data link layer, it parses the Ethernet frame header to extract information such as source MAC address, destination MAC address, and frame type to identify the source and destination of data packets. At the network layer, it parses the IP header to extract information such as source IP address, destination IP address, and protocol type (TCP / UDP) for routing and session management. At the transport layer, it parses the TCP / UDP header to extract information such as source port, destination port, sequence number, and acknowledgment number to maintain TCP connection state and manage keep-alive mechanisms to prevent connection timeouts. At the application layer, it performs specialized semantic parsing for different industrial communication protocols, identifying whether data packets are requests or responses, and using fields such as transaction identifiers and frame identifiers to identify the pairing relationship between requests and responses.

[0041] The request-response pairing table is implemented using a circular buffer, with a capacity set to store the amount of data within a time period T. T typically ranges from 50ms to 500ms, depending on the real-time requirements of the protocol and the system's memory resources. Each entry is stored as a triple (sequence number, timestamp, response status). The sequence number varies depending on the protocol type: for Modbus TCP, a Transaction ID is used; for Profinet, a combination of Frame ID and Cycle Counter is used; and for CAN, a combination of Arbitration ID and time window is used. The timestamp records the precise time (milliseconds or microseconds) the request arrived. Response statuses are categorized into three types: "Waiting for Response" (the request has been sent but no response has been received), "Completed" (the request and response have been successfully paired), and "Timeout" (the request waiting time has exceeded the timeout limit specified by the protocol).

[0042] The communication protection system can be configured with a periodic cleanup mechanism. Every certain interval (e.g., 10ms), it scans the request-response pairing table, deleting entries with a status of "completed" and a completion time exceeding T, and marking entries with a status of "awaiting response" and a waiting time exceeding the protocol timeout limit as "timeout". For "timeout" entries, the communication protection system records statistical information (such as the number of timeouts and average timeout duration) for health monitoring and fault prediction.

[0043] Step S202: Monitor the operating status of the protected equipment through multi-dimensional indicators to determine whether the protected equipment has failed.

[0044] In the technical solution provided in this application, the communication protection system monitors the operating status of the protected equipment through multi-dimensional indicators. The method for determining whether the protected equipment has malfunctioned may include: real-time acquisition of multi-dimensional indicators of the protected equipment, including one or more of the following: operating current, operating voltage, heartbeat response status, protocol response time, and communication error rate. A weighted scoring mechanism is employed to calculate a fault score based on preset weights for each dimension and the multi-dimensional indicators. The fault score is positively correlated with the degree of anomaly in each dimension of the multi-dimensional indicators. When the fault score is greater than or equal to a preset fault threshold, the protected equipment is determined to be faulty.

[0045] The equipment health monitoring module continuously monitors the operating status of the protected equipment through multi-dimensional indicators.

[0046] A current sensor is connected in series in the power supply circuit of the protected equipment to monitor the equipment's operating current in real time. The system sets current thresholds and duration thresholds; when the current exceeds the normal range and persists for a certain period, a current anomaly flag is triggered. Similarly, the equipment health monitoring module can also monitor the equipment's power supply voltage to detect voltage dips, voltage spikes, or voltage instability.

[0047] For devices that support heartbeat protocols, the communication protection system can periodically send heartbeat requests to the protected device (such as a Modbus request to read a specific register every 100ms, or a Profinet DCP Identify request), and check whether a heartbeat response is received within a specified time (such as 50ms). If no response is received for N consecutive heartbeat requests (e.g., 3 times), a heartbeat loss flag is triggered.

[0048] The communication protection system can analyze the request-response pairing table to statistically analyze the device's response performance. Specifically, it calculates the response time for each request (response timestamp minus request timestamp) and maintains the average and maximum response times within a sliding window. The communication protection system can set response time thresholds (e.g., 100ms) and timeout thresholds (e.g., 5 consecutive request timeouts). When continuous deterioration in response performance is detected, a response timeout flag is triggered.

[0049] For protocols with verification mechanisms (such as CRC checksum of Modbus RTU and FCS checksum of Profinet), the communication protection system can count the frequency of verification errors. The system calculates the error rate (number of erroneous packets divided by the total number of packets) within a sliding window. When the error rate exceeds a threshold (e.g., 1%) and persists for a certain period of time (e.g., 1 second), a communication error rate anomaly flag is triggered.

[0050] In the technical solution provided in this application embodiment, the communication protection system can adopt a weighted scoring mechanism, assigning scores to each dimension indicator. For example, current anomaly is assigned 30 points, heartbeat loss is assigned 40 points, response timeout is assigned 20 points, and communication error rate anomaly is assigned 10 points. The fault score is positively correlated with the degree of anomaly of the data in each dimension. When the fault score reaches or exceeds a preset fault threshold (e.g., 50 points), the equipment is determined to be faulty.

[0051] In the technical solution provided in this application, the weighted scoring mechanism has the characteristic of strong fault tolerance. If there is an occasional current fluctuation (which can be assigned a score of 30), it will not immediately trigger fault judgment. However, if there is an occasional current fluctuation and a heartbeat loss occurs at the same time (30+40=70 points>50 points), the communication protection system will immediately determine a fault.

[0052] When the fault score is less than the preset fault threshold and greater than or equal to the preset warning threshold, the communication protection system can increase the monitoring frequency of the protected equipment and obtain requests in the request-response pairing table that are in the waiting response state in advance.

[0053] The technical solution provided in this application introduces a fault prediction mechanism. When the fault score reaches the warning threshold (e.g., 30-50 points) but does not reach the fault threshold, the system enters a "warning state". In this state, the communication protection system can increase the frequency of health checks (e.g., from once every 100ms to once every 10ms) and scan the request-response pairing table in advance to obtain requests in the waiting response state, prepare the data required for proxy response, and buy time for fault switching.

[0054] Step S203: When it is determined that the protected device has failed, obtain the requests with a response status of "waiting for response" in the correspondence between requests and responses.

[0055] When the device health monitoring module determines that the device is faulty, the system immediately enters the fault handling mode. The buffer scanning module scans the request-response pairing table, searches for all entries with a status of "waiting for response", and obtains these waiting response request transactions and their original data for subsequent construction of abnormal responses.

[0056] Step S204: According to the protocol specifications, construct an exception response conforming to the standard format for each pending response request, and send the exception response to the corresponding upstream device.

[0057] In the technical solution provided in this embodiment, the proxy response generation module constructs an abnormal response according to the protocol specification. The generation of the proxy response requires the simultaneous fulfillment of two conditions: first, device health monitoring determines that the device is faulty (fault score is greater than or equal to a preset fault threshold); second, a cache scan of the request-response pairing table reveals a request in a "waiting for response" state.

[0058] A standard-formatted exception response includes at least one of the following: For the Modbus TCP protocol, set the function code to the original requested function code plus 0x80, and the exception code to 0x04. For the Profinet RT protocol, set IOPS and IOCS to an invalid state, and set the IO data to a preset safe value. For the CAN bus protocol, construct an exception message frame conforming to the CAN protocol specification.

[0059] For the Modbus TCP protocol, the process of constructing an exception response algorithm conforming to the standard format is as follows: Retrieve the request in the "waiting for response" state from the request-response pairing table, extract its original data and parsing results, including the transaction identifier, unit identifier, function code, etc. Construct the MBAP header: Copy the transaction identifier of the original request to ensure the response matches the request; set the protocol identifier to 0x0000; calculate the length field, which is fixed at 3 for exception responses; copy the unit identifier of the original request. Construct the PDU section: Set the function code to the original request function code plus 0x80; set the exception code, using 0x04 (Slave Device Failure) for device hardware failure. Encapsulate the constructed proxy response frame into a TCP / IP packet, filling in the correct source IP address, destination IP address, source port (502), and destination port, setting the TCP flags, and calculating the IP checksum and TCP checksum.

[0060] For the Profinet RT protocol, the process for constructing an exception response algorithm conforming to the standard format is as follows: Identify the type of the request frame, determining whether it is a real-time data frame or a control frame based on the Frame ID. Construct the Profinet frame header: Copy the Frame ID of the original request; if the original request contains a Cycle Counter, continue incrementing the Cycle Counter in the proxy response to maintain the continuity of the cycle count. Set IOPS and IOCS: In the event of a device failure, set IOPS to 0x00 (Bad state), indicating invalid output data; set IOCS to 0x00 (Bad state), indicating invalid input data. Set the IO data section: According to Profinet's safety design principles, when the device fails, IO data should be set to safe values; for output data (control signals), it is usually set to all zeros. Calculate and add the FCS checksum to ensure frame integrity.

[0061] For the CAN bus protocol, construct an exception message frame that conforms to the CAN protocol specification and set the corresponding error flag.

[0062] After the proxy response (abnormal response) is generated, the communication protection system sends the generated proxy response to the upstream communication interface. The sending operation adopts a blocking mode to ensure that the data is actually sent to the network. The system waits for a network transmission delay time (usually 1-5ms) to ensure that the upstream device has enough time to receive the data.

[0063] Step S205: After the abnormal response is sent, perform a physical bypass switch to switch the communication link from the normal path to the bypass path.

[0064] Communication protection systems can employ a hybrid approach combining relays and solid-state switches. Relay selection can utilize reed relays or high-speed signal relays, with switching times ranging from 0.5 to 5 ms. Solid-state switch selection can utilize high-speed analog switches, with switching times less than 25 ns. Figure 3 This is a schematic diagram of a single switch module for a communication protection method provided in an embodiment of this application. Based on the above embodiments, as follows... Figure 3 As shown, a single switching module includes input differential pairs IN_1+ and IN_1-, output pairs OUT_1+ and OUT_1-, and bypass traces RLY_1+ and RLY_1-. The solid-state switch uses an enhancement-mode N-channel MOSFET array with a source-drain on-resistance Rds < 1Ω, supporting nanosecond-level initial switching.

[0065] The hybrid switching strategy is as follows: In normal operating mode, the relay is closed and the solid-state switch is open; when performing fault switching, the solid-state switch is closed first (bypass channel is established, taking much less than 1ms), and then the relay is opened (the protected device is isolated, taking 1-5ms); after the switching is completed, if it is necessary to maintain the bypass state for a long time, the solid-state switch can be opened after a delay to reduce system power consumption.

[0066] It should be understood that the communication protection system should perform the aforementioned physical bypass switching action after confirming that the proxy response has been sent. Therefore, the time window difference between the transmission of the proxy response and the execution of the physical switching can be set to 5-10ms to ensure that the upstream device has sufficient time to receive and process abnormal responses.

[0067] In the technical solution provided in this application embodiment, the communication protection system can also cache newly arrived data packets during physical bypass switching after the abnormal response is sent, and replay the cached data packets according to timing and priority after the physical bypass switching is completed.

[0068] Specifically, the packet replay module in the communication protection system can be used to process new data packets arriving during physical bypass handover, ensuring zero packet loss. At the start of the "proxy response priority transmission" phase, the system sets a buffer flag, indicating that all newly arriving data packets should be buffered instead of forwarded immediately. The buffer uses a separate circular buffer, with a capacity set to store the amount of data that may arrive during the physical handover, typically 50-100 packets. Each arriving data packet, in addition to storing the original data, also records a timestamp, sequence number, priority, and timeliness flag.

[0069] After the physical bypass switch is completed, the system clears the cache flags and starts the packet replay task. The packet replay task processes the cached data packets according to the following strategies: time-sequential replay, replaying in the order of timestamps; deduplication, deduplicating according to the protocol sequence number, keeping only the first one and discarding subsequent duplicate packets; timeliness judgment, for protocols with high real-time requirements, checking the timestamp of the data packets, and discarding them directly if they are outdated; priority replay, replaying high-priority packets first, and then replaying low-priority packets.

[0070] The complete workflow of this embodiment will be described below with reference to a specific example.

[0071] After power-on, the communication protection system enters normal operating mode. Data packets sent by upstream devices arrive at the upstream communication interface. The protocol parsing and caching module performs deep parsing of the data packets, creating entries in the request-response pairing table, recording the sequence number, timestamp, and "waiting for response" status. Simultaneously, the data packet image is stored in the cache. The data packet is then transparently forwarded to the protected device. After processing the request, the protected device returns a response. The protocol parsing module recognizes this as a response, looks up the corresponding request in the pairing table based on the sequence number, and updates the status to "completed." The response data packet continues to be forwarded to the upstream device. Throughout this process, the device health monitoring module runs continuously, all indicators are normal, and the overall score is below the fault threshold.

[0072] When the protected device malfunctions, the device health monitoring module detects abnormal indicators. If the comprehensive score reaches or exceeds 50 points, the device is deemed faulty. The communication protection system immediately enters fault handling mode, performs a buffer scan, scans the request-response pairing table, and searches for all entries with a status of "waiting for response." Assume three requests with waiting responses are found. The communication protection system enters the proxy response generation process, suspends physical bypass switching, and sets a cache flag (newly arriving packets enter the cache queue). For each request waiting for a response, the proxy response generation algorithm is invoked to construct the MBAP header and PDU, encapsulate them into a TCP / IP packet, and the generation process takes approximately 2ms. The generated proxy responses are then sent sequentially to the upstream communication interface, waiting for network transmission delay (approximately 3ms) to ensure the upstream device receives the response. From fault detection to the completion of proxy response transmission, the total time is approximately 10-20ms. Upon receiving the proxy response, the upstream device's protocol stack parses the response, identifies it as an abnormal response, interprets it as a "device malfunction," and operates according to the standard abnormal handling process. It will not trigger a timeout, will not disconnect the TCP connection, and its protocol stack status remains normal.

[0073] After the proxy response is sent and confirmed, the communication protection system releases the physical bypass switching suspension and executes the switching action. First, the solid-state switch is closed (taking less than 1ms) to establish the bypass channel; then the relay is disconnected (taking 3-5ms) to isolate the protected device. The total physical switching time is approximately 5-10ms. During the physical switching, it is assumed that two new requests are sent from upstream, which are captured and stored by the caching module. After the physical switching is completed, the communication protection system clears the cache flag and starts the packet replay task. The cache queue is scanned, and two packets to be replayed are found. These are sorted by timestamp, deduplication is checked, timeliness is checked, and the packets are replayed to the bypass channel. Once packet replay is complete, the cache queue is emptied. The communication protection system enters bypass mode, and thereafter all newly arriving data packets are directly forwarded downstream through the bypass channel.

[0074] In the technical solution provided in this application embodiment, the communication protection system can perform deep parsing on the incoming data packets through the communication interface, and construct and maintain a request-response pairing table based on the parsing results. The request-response pairing table includes at least the response status corresponding to each parsed data packet. The system monitors the operating status of the protected device through multi-dimensional indicators to determine whether the protected device has malfunctioned. When a malfunction is determined, the system retrieves requests in the waiting-for-response pairing table. According to the protocol specification, an abnormal response conforming to a standard format is constructed for each waiting-for-response request, and the abnormal response is sent to the corresponding upstream device. After the abnormal response is sent, a physical bypass switch is performed, switching the communication link from the normal path to the bypass path. The technical solution provided in this application embodiment can track the response status of each request by establishing a request-response pairing table, and proactively retrieve waiting-for-response requests and construct abnormal responses conforming to a standard format according to the protocol specification to send to the upstream device when a device malfunctions. This ensures that the upstream device receives a response conforming to the protocol specification before the physical link switch, thereby avoiding protocol timeouts and connection interruptions, and ensuring the continuous and stable state of the protocol stack.

[0075] Furthermore, by performing deep parsing of data packets and constructing a request-response pairing table, this application can understand the semantics of requests, accurately identify requests awaiting responses, and construct abnormal responses conforming to protocol specifications, thus achieving a leap from passive link switching to proactive protocol proxying. Moreover, the request-response pairing table enables fine-grained processing at the request level, generating proxy responses only for requests awaiting responses, avoiding redundant processing of completed requests; simultaneously, by prioritizing the sending of proxy responses before performing physical bypass switching, the total recovery time is shortened to less than 50ms. By proactively generating and sending abnormal responses conforming to protocol specifications when a fault occurs, this application can significantly improve the real-time performance and reliability of the communication network.

[0076] The technical solution of this application is based on a modular hardware architecture design. Through modular protocol parsing and proxy response generation algorithms, it can be extended to support multiple industrial communication protocols. In addition to the Modbus TCP protocol, Profinet RT protocol, and CAN bus protocol described in detail in the embodiments of this application, the system can also be extended to support other mainstream industrial Ethernet protocols such as EtherCAT protocol, Ethernet / IP protocol, and Profinet IO protocol through corresponding protocol parsing plug-ins and proxy response generation modules, which has good scalability and forward-looking capabilities.

[0077] Figure 4 This is a timing interaction diagram illustrating a communication protection method provided in an embodiment of this application. Figure 4 As shown, it can include five interaction stages from T0 to T4: T0: Data arrived.

[0078] The PHY (Physical Layer) receives data packets (also called receive packets) and sends them to the protocol parsing and caching module for protocol parsing.

[0079] T1: Protocol processing and fault detection.

[0080] The protocol parsing and caching module parses the data packets and creates a table (i.e., establishes a request-response pairing table), and synchronizes the data to the device health monitoring module to perform health monitoring. The device monitoring module can monitor the operating status of the protected device through multi-dimensional indicators, and determine whether the protected device has failed by calculating a fault score. If the fault score is greater than or equal to a preset fault threshold (e.g., 50), then step T2 is executed.

[0081] T2: Scan the pairing table.

[0082] The device health monitoring module then triggers a scanning process, scanning requests that are in a waiting-for-response state in the request-response pairing table.

[0083] T3: Generate proxy response.

[0084] The cache scanning module searches for all entries in the request-response pairing table with a status of "waiting for response", obtains the request transactions waiting for response and their original data, and constructs an exception response through the proxy response generation module to generate a proxy response.

[0085] T4: Send response and switch.

[0086] After the proxy response generation module generates the proxy response, it sends an ACK (Acknowledge character) at the PHY layer, and the physical bypass control module performs physical bypass switching (switching relays).

[0087] It should be understood that, provided there are no logical conflicts, the above-described embodiments can be combined and implemented to adapt to actual application needs. These combined embodiments or implementation schemes are still within the scope of protection of this application.

[0088] Corresponding to the communication protection method in the above embodiments, this application provides a communication protection system, including: an upstream communication interface for receiving data packets from an upstream device and sending responses to the upstream device; a protocol parsing and caching module for performing deep parsing on the transmitted data packets and constructing and maintaining a request-response pairing table, wherein the request-response pairing table includes at least the response status corresponding to each parsed data packet; a device health monitoring module for monitoring the operating status of the protected device through multi-dimensional indicators and determining whether the protected device has malfunctioned; a buffer scanning module for scanning the request-response pairing table and obtaining requests in a waiting response state when it is determined that the protected device has malfunctioned; a proxy response generation module for constructing an abnormal response conforming to a standard format according to the protocol specification; a physical bypass control module for performing physical bypass switching, switching the communication link from the normal path to the bypass path; and a downstream communication interface for outputting data packets to downstream devices or bypass channels.

[0089] In this embodiment, the system is connected in series in the network link where the protected device is located. The upstream communication interface connects to the upstream device, and the downstream communication interface connects to the protected device or a bypass channel. The protocol parsing and caching module performs deep parsing of data packets and maintains a pairing table in normal operating mode, while simultaneously forwarding data packets transparently to the protected device. The device health monitoring module continuously monitors the operating status of the protected device. When a device fault is detected, the buffer scanning module obtains a waiting response request, the proxy response generation module constructs an abnormal response and sends it through the upstream communication interface, and the physical bypass control module performs a switching operation.

[0090] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0091] Based on the same inventive concept, embodiments of this application also provide an electronic device.

[0092] Figure 5 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. For example... Figure 5 As shown, the electronic device 50 of this embodiment includes: at least one processor 510 ( Figure 5Only one is shown in the diagram), memory 520, and communication module 530. Memory 520 stores a computer program 540 that may run on processor 510. When processor 510 executes computer program 540, it implements the functions of each module / unit in the above-described communication protection method embodiment, for example... Figure 2 The steps S201 to S205 are shown. The communication module 530 can be a separate communication unit used to communicate with an external server or terminal device.

[0093] Electronic device 50 may include, but is not limited to, a processor 510 and a memory 520. Those skilled in the art will understand that... Figure 5 This is merely an example of electronic device 50 and does not constitute a limitation on electronic device 50. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device 50 may also include input transmitting devices, network access devices, buses, etc.

[0094] The processor 510 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0095] In some embodiments, memory 520 may be an internal storage unit of electronic device 50, such as a hard disk or memory of electronic device 50. Memory 520 may also be an external storage device of electronic device 50, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on electronic device 50. Memory 520 may include both internal and external storage units of electronic device 50. Memory 520 is used to store operating system, applications, bootloader, data, and other programs, such as the program code of computer program 540. Memory 520 may also be used for temporary storage of data that has been sent or will be sent.

[0096] Furthermore, those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. In the various embodiments of this application, each functional unit can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0097] This application provides a computer-readable storage medium storing a computer program that, when run on an electronic device, causes the electronic device to perform the steps described in the various method embodiments above.

[0098] This application provides a chip, which includes a processor and a memory. The memory stores a computer program, which, when executed by the processor, implements the steps in the various method embodiments described above.

[0099] This application provides a computer program product that, when run on an electronic device, causes the electronic device to execute the steps described in the various method embodiments above.

[0100] It should be understood that the processor mentioned in the embodiments of this application can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0101] It should also be understood that the memory mentioned in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0102] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0103] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0104] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0105] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0106] The units described as separate components may or may not be physically separate. The components shown 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0107] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0108] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a large-screen device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0109] Finally, it should be noted that the above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions 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 communication protection method, characterized in that, include: The data packets are parsed sequentially, and a correspondence between requests and responses is constructed and maintained based on the parsing results. The correspondence between requests and responses includes at least the response status corresponding to each parsed data packet. By monitoring the operating status of the protected equipment through multi-dimensional indicators, it can be determined whether the protected equipment has malfunctioned. When it is determined that the protected device has failed, the request with a response status of "waiting for response" is obtained from the correspondence between the request and the response. According to the protocol specifications, an abnormal response conforming to a standard format is constructed for each pending response request, and the abnormal response is sent to the corresponding upstream device; After the abnormal response is sent, a physical bypass switch is performed to switch the communication link from the normal path to the bypass path.

2. The communication protection method according to claim 1, characterized in that, The sequential parsing of data packets includes parsing at least one of the physical layer, link layer, network layer, transport layer, and application layer, extracting protocol fields and identifying whether the data packet type is a request or a response, as well as identifying the pairing relationship between requests and responses.

3. The communication protection method according to claim 1, characterized in that, The correspondence between requests and responses is a request-response pairing table. The request-response pairing table adopts a circular buffer structure and stores the sequence number, timestamp, and response status in the form of triples. The response status is waiting for response, completed, or timed out.

4. The communication protection method according to claim 1, characterized in that, The method of monitoring the operating status of the protected equipment through multi-dimensional indicators to determine whether the protected equipment has malfunctioned includes: The protected device can acquire multi-dimensional indicators in real time, including one or more of the following: operating current, operating voltage, heartbeat response status, protocol response time, and communication error rate. A weighted scoring mechanism is adopted to calculate the fault score based on the preset weights of each dimension and the multi-dimensional indicators. The fault score is positively correlated with the degree of abnormality of the data in each dimension of the multi-dimensional indicators. When the fault score is greater than or equal to a preset fault threshold, the protected device is determined to be faulty.

5. The communication protection method according to claim 4, characterized in that, The method further includes: When the fault score is less than the preset fault threshold and greater than or equal to the preset warning threshold, the monitoring frequency of the protected equipment is increased, and requests with a response status of "waiting for response" in the correspondence between requests and responses are obtained in advance.

6. The communication protection method according to claim 1, characterized in that, The exception response conforming to the standard format includes at least one of the following: For the Modbus TCP protocol, set the function code to the original request function code plus 0x80, and the exception code to 0x04; For the Profinet RT protocol, IOPS and IOCS are set to an invalid state, and IO data is set to a preset safe value; For the CAN bus protocol, construct an exception message frame that conforms to the CAN protocol specification.

7. The communication protection method according to claim 1, characterized in that, After the exception response is sent, the method further includes: Newly arriving packets are buffered during physical bypass switching, and the buffered packets are replayed according to timing and priority after the physical bypass switching is completed.

8. A communication protection system, characterized in that, include: The upstream communication interface is used to receive data packets from upstream devices and send responses to upstream devices. The protocol parsing and caching module is used to parse the incoming data packets and build and maintain the correspondence between requests and responses. The correspondence between requests and responses includes at least the response status corresponding to each parsed data packet. The equipment health monitoring module is used to monitor the operating status of the protected equipment through multi-dimensional indicators and determine whether the protected equipment has malfunctioned. The buffer scanning module is used to scan the correspondence between requests and responses when it is determined that the protected device has failed, and to obtain requests with a response status of "waiting for response". The proxy response generation module is used to construct exception responses that conform to the standard format according to the protocol specifications. The physical bypass control module is used to perform physical bypass switching, switching the communication link from the normal path to the bypass path; Downstream communication interface, used to output data packets to downstream devices or bypass channels.

9. An electronic device, characterized in that, It includes a processor and a memory, the processor being configured to execute a computer program stored in the memory to implement the communication protection method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the communication protection method as described in any one of claims 1 to 7.

Images