An industrial communication fault locating method and device based on network layer packet encapsulation

Abstract

The application provides an industrial communication fault positioning method and system based on network layer packet encapsulation, and relates to the technical field of communication, wherein the method comprises the following steps: a first network node device receives a first industrial protocol packet; the first network node device generates a second industrial protocol packet according to the first industrial protocol packet. When a second network node device judges that a fault occurs, the alarm mark in the fault tracing field is set to an abnormal state, and the modified second industrial protocol packet is forwarded to an industrial monitoring platform; the industrial monitoring platform analyzes the fault tracing field in the second industrial protocol packet, and determines a fault link according to the fault tracing field. The application overcomes the problems in the traditional fault positioning scheme, such as lack of end-to-end transmission path record, lack of link details of alarm information, low efficiency of cross-node manual troubleshooting, and separation of fault information and communication packets, and cannot be synchronized and traced back, and significantly improves the positioning accuracy and real-time performance of the fault link in the industrial communication network.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to an industrial communication fault location method and apparatus based on network layer encapsulated messages. Background Technology

[0002] With the deepening development of the Industrial Internet, communication protocols of industrial control systems are widely used in key fields such as power, intelligent manufacturing, and chemical industry. However, industrial networks generally have complex topologies that span multiple factories and multiple network segments, and the communication protocols of industrial control systems have extremely high requirements for millisecond-level real-time transmission, resulting in frequent communication failures that are difficult to pinpoint accurately.

[0003] The existing fault location scheme for the communication protocol of industrial control systems is based on traditional IP networks. Independent monitoring probes are deployed at key nodes to capture the communication protocol messages of the industrial control system, extract basic information such as source IP, destination IP, and transmission delay, and compare them with preset thresholds. After an anomaly is detected, an alarm is reported to the monitoring platform through an independent control channel. Then, maintenance personnel log in to each node device to manually check and trace the fault link hop by hop.

[0004] However, this solution can only capture local link information, which can easily lead to misjudgment of fault points. In addition, cross-node troubleshooting relies heavily on manual labor, and fault location takes a long time in scenarios involving multiple factory areas and multiple network segments.

[0005] Therefore, there is an urgent need for an industrial communication fault location method that can achieve end-to-end path recording, provide fine-grained link status information, and support real-time synchronous fault backtracking. Summary of the Invention

[0006] This invention provides an industrial communication fault location method and system based on network layer encapsulated messages. This method can overcome the problems of traditional fault location schemes, such as lack of end-to-end transmission path records, lack of link details in alarm information, low efficiency of manual investigation across nodes, and separation of fault information and communication messages, which makes synchronous tracing impossible. It significantly improves the location accuracy and real-time performance of fault links in industrial communication networks.

[0007] Firstly, a method for locating industrial communication faults based on network layer encapsulated messages is provided, including: The first network node device receives a first industrial protocol message, which is generated by the industrial device. The first network node device performs network layer encapsulation on the first industrial protocol message to generate a second industrial protocol message, fills the information in the first industrial protocol message into the fault tracing field of the second industrial protocol message, and then sends the second industrial protocol message to the second network node device; wherein, the first industrial protocol message and the second industrial protocol message use different communication protocols; The second network node device determines whether a link has failed based on the fault tracing field in the second industrial protocol message. If a failure is determined, the alarm flag in the fault tracing field is set to an abnormal state, and the modified second industrial protocol message is forwarded to the industrial monitoring platform. The industrial monitoring platform parses the fault tracing field in the second industrial protocol message and determines the fault link based on the fault tracing field.

[0008] In this way, by encapsulating industrial protocol messages into network layer messages carrying fault tracing fields, synchronous transmission of fault information and service messages is achieved; intermediate nodes can determine the link status and mark alarm flags in real time during forwarding, without the need for independent probes and dedicated signaling; the industrial monitoring platform can directly locate faulty links by parsing the fault tracing fields, without the need for manual hop-by-hop troubleshooting, significantly improving the real-time performance and accuracy of fault location and the troubleshooting efficiency in cross-plant scenarios, while being compatible with existing industrial equipment and having low deployment costs.

[0009] In some possible embodiments, the first network node device performs network layer encapsulation on the first industrial protocol message to generate a second industrial protocol message, including: The first network node device adds an IP packet basic header and a segment routing extension header to the first industrial protocol message, and creates a fault tracing field in the optional TLV extension field of the segment routing extension header; Extract protocol-related information from the first industrial protocol message. The protocol-related information includes at least one of the following: message length field, transmission connection identifier, session identifier, device physical location identifier, and function code. The extracted protocol-related information is filled into the node information array of the fault tracing field, and the alarm flag is initialized to the normal state.

[0010] In this way, creating a fault tracing field using the optional TLV extension field in the SRv6 segment routing extension header fully complies with existing protocol specifications, requires no modification to the standard message structure, and has good compatibility and scalability. The fault tracing field and the path information carried by the SRH are in the same extension header, ensuring that fault monitoring is naturally bound to the segmented routing path, allowing subsequent nodes to directly obtain the complete path context. Furthermore, key information such as message length, transmission connection identifier, session identifier, device physical location identifier, and function code are extracted from the original industrial protocol message and populated into the node information array, enabling fault location to be precise down to the specific service connection and device, facilitating the monitoring platform to quickly associate faults with affected applications.

[0011] In some possible embodiments, the second network node device determines whether a link failure has occurred based on the fault tracing field in the second industrial protocol message, including: The second network node device determines the status information of the current link based on the fault tracing field, the status information including the communication latency and packet loss rate of the current link; The communication latency of the current link is compared with a preset latency threshold, and the packet loss rate of the current link is compared with a preset packet loss rate threshold. If the communication delay exceeds the preset delay threshold and / or the packet loss rate exceeds the preset packet loss rate threshold, then the current link is determined to have failed.

[0012] In this way, the second network node device performs real-time assessment of the link status based on two quantitative indicators: communication latency and packet loss rate, and uses a threshold comparison method to determine faults. The above judgment process is completed locally at the packet forwarding node, and the result is written to the fault tracing field in real time without additional signaling interaction. This ensures the real-time nature of fault perception while reducing the dependence on the computing and communication resources of the monitoring platform.

[0013] In some possible embodiments, it also includes: The target device receives the second industrial protocol message, strips the network layer encapsulation of the second industrial protocol message, and obtains the first industrial protocol message; The instructions in the first industrial protocol message are executed, and the execution result is filled into the fault tracing field of the second industrial protocol message through the network node directly connected to the target device to obtain the third industrial protocol message. The third industrial protocol message is then sent to the industrial monitoring platform.

[0014] This further achieves end-to-end closed-loop fault information and traceability of command execution results. After receiving the encapsulated message, the target device first decapsulates and executes the original industrial protocol command, then writes the execution result into the fault tracing field through the network node directly connected to it, forming a third industrial protocol message and reporting it to the monitoring platform. This allows the monitoring platform to simultaneously know the command execution status on the target device side, such as successful execution, timeout, or return of error codes, effectively distinguishing whether the fault is caused by a link anomaly or by a problem with the target device itself, avoiding misjudgment.

[0015] In some possible embodiments, the fault tracing field contains an array of node information, and the method further includes: When the first network node device and / or the second network node device forwards the second industrial protocol message, they write the node identifier, forwarding timestamp, link quality level, and forwarding status of the network node device into the node information array of the fault tracing field.

[0016] This achieves complete visibility and refined quality awareness of the message transmission path. Each forwarding node, while transmitting the message, simultaneously writes its own identity information, time information, link quality, and forwarding result into the fault tracing field, forming an irrefutable chain of path evidence. This enables the industrial monitoring platform to accurately reconstruct the real-time quality of each hop the message passes through, as well as any potential forwarding anomalies, thereby quickly locating faulty nodes or degraded sections.

[0017] In some possible embodiments, it also includes: When the number of nodes recorded in the node information array exceeds the preset maximum value, the head node, tail node, and abnormal state node in the node information number are retained, and the node information to be written is overwritten by the earliest written normal node information in reverse timestamp order.

[0018] In this way, when the node information array is about to overflow, the head node, tail node, and all nodes in abnormal states are retained first, ensuring that the start and end points of the transmission path and the critical hop point where a failure occurs are not lost. This balances the integrity of the path and the integrity of the fault focus information.

[0019] In some possible embodiments, it also includes: The industrial monitoring platform sends the format rules of the fault tracing field, the device location mapping table, and the communication fault detection threshold to the first network node device and the second network node device. The communication fault detection threshold includes a latency threshold and a packet loss rate threshold.

[0020] In this way, the monitoring platform can update thresholds and format rules at any time according to the actual needs of the industrial scenario, enabling fault detection to adapt to changes in network status or adjustments in service levels, thus enhancing the system's flexibility and maintainability. Furthermore, the distribution of the device location mapping table allows node devices to directly associate physical location information when writing fault tracing fields, providing the monitoring platform with a more intuitive basis for fault location.

[0021] In some possible embodiments, it also includes: The industrial monitoring platform issues a handling instruction to the first network node device and / or the second network node based on the identified faulty link. The handling instruction includes at least one of switching to a backup path, restarting the faulty node, or adjusting the routing strategy.

[0022] In this way, after identifying a faulty link, the industrial monitoring platform can proactively issue handling instructions to relevant network nodes, such as switching to backup paths, restarting faulty nodes, or adjusting routing strategies, without manual intervention. The fault recovery time is reduced from the traditional hours to seconds or milliseconds, significantly improving the business continuity of the industrial network. The handling instructions are only issued to the node devices affected by the fault, with fine-grained operation, avoiding network-wide oscillations.

[0023] Secondly, an industrial communication fault location system based on network layer encapsulated messages is provided, including: A first network node device is used to receive a first industrial protocol message, which is generated by an industrial device. The first network node device is further configured to encapsulate the first industrial protocol message at the network layer to generate a second industrial protocol message, fill the information in the first industrial protocol message into the fault tracing field of the second industrial protocol message, and then send the second industrial protocol message to the second network node device; wherein the first industrial protocol message and the second industrial protocol message use different communication protocols; The second network node device is used to determine whether a link has failed based on the fault tracing field in the second industrial protocol message. If a failure is determined, the alarm flag in the fault tracing field is set to an abnormal state, and the modified second industrial protocol message is forwarded to the industrial monitoring platform. The industrial monitoring platform is used to parse the fault tracing field in the second industrial protocol message and determine the fault link based on the fault tracing field.

[0024] The first network node device is further configured to add an IP packet basic header and a segment routing extension header to the first industrial protocol message, and to create a fault tracing field in the optional TLV extension field of the segment routing extension header; Extract protocol-related information from the first industrial protocol message. The protocol-related information includes at least one of the following: message length field, transmission connection identifier, session identifier, device physical location identifier, and function code. The extracted protocol-related information is filled into the predefined fields of the fault tracing field, and the alarm flag is initialized to the normal state.

[0025] In some possible embodiments, the second network node device is configured to determine the status information of the current link based on the fault tracing field, the status information including the communication latency and packet loss rate of the current link; The communication latency of the current link is compared with a preset latency threshold, and the packet loss rate of the current link is compared with a preset packet loss rate threshold. If the communication delay exceeds the preset delay threshold and / or the packet loss rate exceeds the preset packet loss rate threshold, then the current link is determined to have failed.

[0026] In some possible embodiments, The target device is used to receive the second industrial protocol message, strip the network layer encapsulation of the second industrial protocol message, and obtain the first industrial protocol message. The instructions in the first industrial protocol message are executed, and the execution result is filled into the fault tracing field of the second industrial protocol message through the network node directly connected to the target device to obtain the third industrial protocol message. The third industrial protocol message is then sent to the industrial monitoring platform.

[0027] In some possible embodiments, When forwarding the second industrial protocol message, the first network node device and / or the second network node device write the node identifier, forwarding timestamp, link quality level and forwarding status of the network node device into the node information array of the fault tracing field.

[0028] In some possible embodiments, The first network node device and / or the second network node device are configured to retain the head node, tail node and abnormal state node in the node information number when the number of nodes recorded in the node information array exceeds a preset maximum value, and overwrite the earliest written normal node information with the node information to be written in reverse timestamp order.

[0029] In some possible embodiments, it also includes: The industrial monitoring platform is used to send the format rules of the fault tracing field, the device location mapping table, and the communication fault detection threshold to the first network node device and the second network node device, wherein the communication fault detection threshold includes a latency threshold and a packet loss rate threshold.

[0030] In some possible embodiments, it also includes: The industrial monitoring platform is used to issue handling instructions to the first network node device and / or the second network node according to the determined faulty link. The handling instructions include at least one of switching to a backup path, restarting the faulty node, or adjusting the routing strategy.

[0031] Thirdly, an electronic device is provided, comprising: one or more processors; one or more memories; and one or more programs, wherein the one or more programs are stored in the one or more memories, and the one or more programs include instructions that, when executed by the one or more processors, cause the configured device to perform the method as described in the first aspect.

[0032] Fourthly, a computer storage medium is provided, the computer storage medium storing instructions that, when executed by a computer, cause the computer to perform the method described in the first aspect or the second aspect.

[0033] Fifthly, a computer program product is provided, the computer program product storing instructions that, when executed by a computer, cause the computer to perform the method described in the first aspect or the second aspect.

[0034] The beneficial effects of the second to fifth aspects can be referred to the introduction of the beneficial effects of the first aspect above, and will not be repeated here. Attached Figure Description

[0035] Figure 1 A schematic diagram of the architecture of an industrial communication fault location system based on network layer encapsulated messages provided in an embodiment of the present invention; Figure 2 A flowchart illustrating the industrial communication fault location method based on network layer encapsulated messages provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of SRv6 message modification provided in an embodiment of the present invention; Figure 4 A flowchart illustrating the industrial communication fault location method based on network layer encapsulated messages provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of an industrial communication fault location system based on network layer encapsulated messages, which can be used to implement the method of the present invention; Figure 6 This is a schematic diagram of an electronic device provided by the present invention. Detailed Implementation

[0036] The solutions provided by the embodiments of the present invention will now be described with reference to the accompanying drawings. In the embodiments of the present invention, "multiple" refers to two or more objects, and "various kinds" refers to two or more types. Terms such as "first," "second," etc., are only used to distinguish similar objects and are not necessarily used to describe a specific order or number of objects.

[0037] SRv6 (Segment Routing over IPv6) is a next-generation network technology that inserts a special segment routing extension header (SRH) into standard IPv6 packets. The data source node plans the entire forwarding path at once, and subsequent relay nodes only need to forward the packets at high speed according to the IPv6 destination address. When the packet reaches the endpoint node, the destination address is updated step by step according to the instructions in the SRH until it is finally delivered to the destination. It is one of the core technologies supporting 5G bearer, industrial Internet and cloud-network convergence.

[0038] With the in-depth development of the Industrial Internet, the S7 protocol, as the core communication protocol of industrial control systems, has been widely used in key fields such as power, intelligent manufacturing, and chemical industry. Industrial networks often have complex topologies that span multiple factories and multiple network segments. In addition, the S7 protocol itself has high requirements for millisecond-level real-time transmission, which leads to frequent communication failures that are difficult to locate.

[0039] Traditional S7 fault location solutions in industrial networks are based on traditional IP networks. Independent monitoring probes are deployed at key nodes to capture S7 communication packets and extract transmission status information. The probes capture S7 packets in real time, parsing basic information such as source IP, destination IP, and transmission latency. The captured data is then compared with preset thresholds to determine if any anomalies are detected. If an anomaly is found, an alarm is generated and sent to the monitoring platform via an independent control channel. Maintenance personnel then log in to each node device based on the received alarm information to manually troubleshoot, tracing the faulty link and node step by step.

[0040] However, existing solutions can only capture information from partial links, lacking complete transmission path records and failing to achieve end-to-end fault tracing. Secondly, the location accuracy is low; alarm information only contains basic status data, lacking crucial information such as node forwarding details and link quality, easily leading to misjudgments of the fault location. Thirdly, cross-node troubleshooting is inefficient, relying entirely on manual checks of each node, which can drag on for hours in scenarios spanning multiple factory areas and network segments. Fourthly, real-time performance is poor; reporting alarms via independent signaling inherently involves latency, and fault information and communication packets are separate, making synchronous tracing impossible.

[0041] To address the aforementioned technical issues, this invention proposes an industrial communication fault location scheme based on network layer encapsulated messages. The scheme encapsulates the original industrial protocol messages into network layer messages carrying fault tracing fields through a first network node device. A node information array is created in the optional TLV extension field of the segment routing extension header. As the message is forwarded along the routing path, the node identifier, timestamp, link quality level, and forwarding status are recorded hop-by-hop. Intermediate nodes determine link faults in real time based on latency and packet loss rate in the fault tracing fields and modify alarm flags accordingly. Finally, the industrial monitoring platform parses the complete path information in the message to directly locate the faulty link. This method avoids reliance on independent monitoring probes and dedicated alarm signaling, achieving synchronous transmission of fault information and service messages. This significantly improves the real-time performance and accuracy of end-to-end fault location. Furthermore, through node information compression strategies and automatic handling command closed-loop, it greatly reduces maintenance overhead and fault recovery time in cross-plant, multi-network segment scenarios.

[0042] Figure 1 This is an architecture block diagram of an industrial communication fault location system based on network layer encapsulated messages, such as... Figure 1As shown, the industrial communication fault location system based on network layer encapsulated messages proposed in this invention adopts a layered architecture, consisting of a platform layer, SRv6 network nodes, and a device layer from top to bottom.

[0043] The platform layer, namely the industrial monitoring platform, serves as the control and decision-making center, integrating two core functional modules. The first module is the source tracing and analysis module, which performs in-depth analysis of the modified SRv6 packets reported by SRv6 network nodes, extracting S7 protocol-specific feature fields and SRv6 path tracing information. Based on this information, it achieves accurate location and root cause analysis of communication faults. The second module is the rule management module, which centrally configures and manages the network-wide rules required for fault location, including but not limited to: the format definition of fault tracing TLV, the mapping table from device IP to rack / slot number, communication latency thresholds, packet loss rate thresholds, and fault handling strategies. This module issues the above configuration parameters and handling commands to SRv6 network nodes and the device layer through control flow, supporting southbound interface protocols such as NETCONF.

[0044] The SRv6 network node, located between the platform layer and the device layer, is the core execution layer for packet modification and fault information collection. This layer integrates three collaborative functional modules. The TLV encapsulation / read / write module receives S7 packets from the device layer, performs SRv6 encapsulation, and inserts a custom fault tracing TLV (e.g., Type=0x13, Length=92 bytes) into the optional TLV area of ​​the SRH extended header. During hop-by-hop packet forwarding, it writes the node SID, forwarding timestamp, link quality level, and forwarding status of each hop into the node information array of the TLV according to pre-configured rules, while also updating the node count. The SID path forwarding module forwards packets based on the SRv6 Segment List, maintains the IPv6 basic header and SRH header, and updates the IPv6 destination address and segment remaining counter according to the SID list order to ensure packets are transmitted along the predetermined path. The fault diagnosis module monitors the communication latency and packet loss rate of the current link in real time during packet forwarding and compares them with thresholds issued by the platform layer. If the detected value exceeds the threshold, the alarm flag in the message TLV is set to the corresponding state, and the message is quickly directed to the platform layer through the pre-configured reporting SID.

[0045] SRv6 network nodes send the modified SRv6 packets to the platform layer through service flow / source tracing flow; at the same time, they receive configuration rules and real-time processing instructions issued by the platform layer through control flow, and dynamically adjust forwarding behavior and fault detection strategies.

[0046] The device layer consists of an S7 PLC and an industrial control human-machine interaction terminal, which sends S7 messages in the format of the native protocol stack through TCP port 102. The encapsulation structure of the message includes a TPKT header, a COTP header, and a dynamic-length S7 protocol data unit. The device layer does not make any modifications to the message at the protocol stack level, maintaining full compatibility with existing S7 devices. The device layer sends S7 messages to the SRv6 network node through a service flow, and can simultaneously receive control flow instructions transparently transmitted or directly issued by the platform layer via the SRv6 network node.

[0047] The service flow starts from the device layer, passes through the SRv6 network node, and finally converges to the platform layer. This data flow carries native S7 messages and modified SRv6 messages, realizing end-to-end transparent transmission of service data communication and fault traceability information. The control flow starts from the platform layer, passes through the SRv6 network node, and can further extend to the device layer. This data flow carries configuration rules and fault handling instructions, realizing centralized management and control of the system and hierarchical linkage response.

[0048] Figure 2 is a schematic flowchart of an industrial communication fault location method based on network layer encapsulated messages, such as Figure 2 shown in the figure, the industrial communication fault location method based on network layer encapsulated messages proposed by the present invention includes the following steps: In step 210, SRv6 pre-configuration is performed.

[0049] The industrial monitoring platform issues the format rule of the fault traceability TLV, the device rack / slot number mapping table, and the communication fault detection threshold to the SRv6 network node.

[0050] Specifically, the industrial monitoring platform, acting as a NETCONF client, performs centralized configuration on the SRv6 network node, and can perform configuration delivery, status query and policy update of network devices through the NETCONF protocol.

[0051] The format rules of the fault traceability TLV include a fixed Type value, a fixed Length, and the byte offset, encoding mode and value meaning of each field. After receiving the configuration, the network node can generate the TLV according to the rule when encapsulating the SRH, and has the ability to parse the received TLV in subsequent forwarding, where TLV is a data encoding format, the full name of which is Type-Length-Value.

[0052] In addition, the IP address or device identifier of the industrial device PLC can be pre-mapped to the corresponding Device_Rack_Slot field. After being delivered to the SRv6 edge network node, the node can quickly fill in this field according to the source IP of the message when modifying the message.

[0053] When fault triggering conditions are set, such as latency ≥30ms or packet loss rate ≥0.5%, SRv6 network nodes determine poor link quality and mark the Alarm_Flag in TLV as communication abnormal or link failure. Different thresholds can be configured for different services, and edge nodes can be treated differently according to service type to achieve fine-grained fault detection.

[0054] Furthermore, it should be understood that in this embodiment of the invention, the first industrial protocol message can be an S7 protocol message or a message of other industrial protocols, and the second industrial protocol message can be an SRv6 protocol message or a message of other protocols. The first network node device can be an SRv6 network node device or an SRv6 edge network node device, and the second network node device can be an SRv6 network node device or an SRv6 edge network node device.

[0055] In step 220, a native S7 message is initiated.

[0056] In this embodiment of the invention, the S7 PLC industrial equipment sends an S7 message, which includes a TPKT header, a COTP header, and an S7 PDU.

[0057] Specifically, S7 PLC industrial equipment can use TCP port 102 as the transport layer port number. The message encapsulation structure from innermost to outermost is as follows: The S7 PDU (Protocol Data Unit) carries specific control commands.

[0058] The COTP (Connection-Oriented Transport Protocol) header has a fixed length of 3 bytes and is used to identify the transport layer connection for S7 communication, ensuring the reliability of end-to-end sessions.

[0059] The TPKT (Transport Packet) header has a fixed length of 4 bytes, which includes a Length field to indicate the total length of the entire S7 message.

[0060] The device layer only acts as the generator and sender of standard S7 messages, without making any modifications to its own protocol stack. Therefore, S7 PLC industrial equipment does not need to support SRv6 parsing, does not need to recognize or process any extended fields, and does not require any firmware upgrades or configuration changes to controllers already deployed in the industrial field.

[0061] The S7 message is sent to the SRv6 network node through the service flow, and the TLV encapsulation / read / write module in the SRv6 network node performs subsequent SRv6 encapsulation and TLV insertion operations.

[0062] In step 230, SRv6 message modification is performed. After receiving the native S7 message, the SRv6 edge network node encapsulates it with SRv6, including adding an IPv6 basic header and an SRH extended header.

[0063] Figure 3 This is a schematic diagram of SRv6 message modification provided in an embodiment of the present invention, as shown below. Figure 3 As shown: In the Optional TLV extension field of the SRH header, add a new custom TLV with parameters defined as shown in Table 1 below: Table 1 TLV Field Parameter Table Type=0x13: Fixed value, used to identify this TLV as an S7 fault tracing TLV.

[0064] Length=0x5C: Fixed length, representing the total number of bytes in the TLV Value portion.

[0065] The subsequent Value field: 92 bytes in total, initialized and filled according to the field order and byte length shown in Table 1.

[0066] TLV field initialization assignment rules: TPKT_Length: The Length field value is read from the TPKT header offset by 0-1 bytes in the S7 message. This value represents the total length of the entire S7 message.

[0067] COTP_Conn_ID: The Connection Identifier is extracted from the COTP header offset of the S7 message between 2 and 5 bytes and is used to bind the underlying S7 transport connection.

[0068] Session_ID: Extracted from the session identifier field of the S7 PDU, used to uniquely identify the upper-layer communication session between the S7 PLC and the peer device.

[0069] Device_Rack_Slot: Based on the device mapping table pre-issued to the edge nodes by the platform layer, the physical location information of the corresponding device is obtained by looking up the table using the source IP address of the native S7 message as the key. The high 8 bits represent the rack number, and the low 8 bits represent the slot number.

[0070] Func_Code: Obtained by parsing the function code field in the S7 PDU. For example, 0x03 indicates reading the holding register, and 0x05 indicates writing the coil. This is used to distinguish the specific control instruction type.

[0071] Node_Count: Initialized to 0, indicating that no SRv6 network node information has been recorded yet.

[0072] Alarm_Flag: Initialized to 0, indicating that the current communication is normal. If a fault is detected later, the SRv6 network node will set it to 1 (communication abnormal) or 2 (link failure).

[0073] Reserve: Reserved field, initialized to 0x00, for future feature expansion.

[0074] After the above encapsulation, the complete message structure output by the SRv6 edge network node includes the IPv6 basic header, SRH containing the S7 fault tracing TLV, and the native S7 message.

[0075] In step 240, the path information is written hop by hop.

[0076] In this embodiment of the invention, when forwarding modified SRv6 packets, SRv6 network nodes perform the following write operations hop-by-hop: obtain the current node's SID, forwarding timestamp, link quality level, and forwarding status. Write the above information into the Node_Info_Array field in the TLV; update Node_Count by 1. If the number of nodes exceeds a preset maximum value, retain the first and last nodes and nodes in abnormal status, and overwrite the earliest written normal node information in reverse timestamp order.

[0077] For example, the hop-by-hop continuation rule: the node information array can record a maximum of 10 nodes. When the number of nodes in the transmission path exceeds 10, the first and last nodes and abnormal state nodes are retained, and the earliest written normal node information is overwritten in reverse timestamp order. Encoding rules: Timestamps are encoded using "3 bytes for seconds + 1 byte for milliseconds" (total 4 bytes). Link quality is quantified as "0 = Excellent (latency < 10ms, packet loss rate < 0.1%), 1 = Good (10ms ≤ latency < 30ms, 0.1% ≤ packet loss rate < 0.5%), 2 = Poor (latency ≥ 30ms or packet loss rate ≥ 0.5%)". All numeric fields are encoded in big-endian mode.

[0078] In step 250, communication status monitoring and anomaly marking are performed.

[0079] In this embodiment of the invention, SRv6 network nodes monitor the communication latency and packet loss rate of the current link in real time during the forwarding process.

[0080] For example, if the communication latency or packet loss rate does not exceed the threshold, then keep Alarm_Flag=0; If the communication latency or packet loss rate exceeds the threshold, the Alarm_Flag in the TLV will be set to 1 or 2, and the pre-configured reporting SID will be loaded to prioritize forwarding the message to the industrial monitoring platform.

[0081] In step 260, the target device status feedback is received.

[0082] In this embodiment of the invention, after receiving the modified SRv6 message, the target device strips the SRv6 header, executes the native S7 command, and writes the communication execution result to the TLV through the nearest SRv6 network node.

[0083] The target device receives the modified message forwarded by the SRv6 network node, identifies and strips the IPv6 basic header and SRH extended header to obtain the S7 message.

[0084] The target device parses the function codes and parameters in the S7 PDU according to the standard S7 protocol process, executes the corresponding control commands, and generates execution results. Upon successful execution, a response message is generated according to the S7 protocol; upon failure, the corresponding error code or exception response is returned.

[0085] After executing the command, an S7 response message is generated. This response message is returned to the SRv6 network node connected to the target device via the reverse path or a path determined by the routing protocol. Since the response message itself is not in SRv6 format, the node needs to re-encapsulate it into an SRv6 message.

[0086] After receiving the request message, the target device retains the IPv6 / SRH header of the message. After execution, it associates the response data with the original TLV and returns the updated TLV along with the response message through the same SRv6 network node.

[0087] When an SRv6 network node directly connected to the target device forwards a request message for the first time, it records the relevant information of the message. When the node receives an S7 response from the same target device, it can identify which request the response corresponds to and write the execution result to the TLV cached at that time. Then, based on the pre-configured reporting rules, it sends an SRv6 message carrying the complete execution result to the industrial monitoring platform.

[0088] In step 270, fault tracing and location are performed.

[0089] In this embodiment of the invention, the industrial monitoring platform parses the dedicated fault tracing TLV in the received SRv6 message and extracts the following information: session ID, device rack number / slot number (Device_Rack_Slot), function code (Func_Code); abnormal node SID, abnormal node forwarding timestamp, link quality and forwarding status; alarm flag Alarm_Flag, and locates the specific location and cause of the faulty link or faulty node based on the above information.

[0090] In step 280, a coordinated action is taken.

[0091] In this embodiment of the invention, the industrial monitoring platform also issues handling instructions to the SRv6 network nodes based on the positioning results. The instructions include switching to a backup path, restarting the faulty node, or adjusting the routing strategy.

[0092] In addition, the following equipment is used to build the implementation environment: one programmable logic controller (PLC) configured in rack 0 and slot 1; one industrial control human-machine interface terminal; two SRv6 network node devices and one industrial monitoring platform.

[0093] Regarding communication parameters, the S7 protocol uses TCP port 102, with messages encapsulated in TPKT and COTP formats. The function code is 0x03 (read command), and the session ID is set to 0x1234567890ABCDEF. For SRv6 configuration, the dedicated traceability TLV is defined as type 0x13, and three segment identifiers are configured: access SID is fc00:s7::1, forwarding SID is fc00:s7::10, and reporting SID is fc00:s7::0. The fault detection threshold is set as follows: an alarm is triggered when the communication latency reaches or exceeds 30 milliseconds, or when the packet loss rate reaches or exceeds 0.5%.

[0094] The implementation process begins with pre-configuration. The industrial monitoring platform sends the format rules of the dedicated traceability TLV, the equipment rack and slot number mapping table, and the fault detection threshold to each SRv6 node via the NETCONF protocol. Subsequently, the PLC sends a native read command message, which is 27 bytes long and has a structure of 4 bytes TPKT, 3 bytes COTP, and 20 bytes S7 PDU.

[0095] After receiving the message, the SRv6 edge node adds an IPv6 basic header and a segment routing extension header (SRH) to it, initializes a dedicated traceability TLV in the optional TLV extension field of the SRH, fills in the device rack and slot number information 0x0001, indicating rack 0, slot 1, function (0x03), TPKT length, initializes the alarm flag to the normal state, and loads the access SID fc00:s7::1.

[0096] The modified SRv6 message is forwarded along a pre-planned path. When the message reaches the SRv6 core node, the node writes its SID (fc00:s7::10), forwarding timestamp (including seconds and milliseconds), link quality level (0x01 in this example, indicating a good state with a latency of 25ms), and forwarding status (0x00, indicating successful continuation) into the node information array of the dedicated traceability TLV, increments the node counter, and then continues forwarding according to the SID path. The message eventually reaches the target device, which strips the SRv6 header, restores and executes the original read command, and fills the TLV back with the execution result through the directly connected SRv6 core node, forming a third industrial protocol message and sending it to the industrial monitoring platform.

[0097] To verify fault location capabilities, a link congestion was artificially simulated at a core node. This node detected a packet transmission delay of 45 milliseconds, exceeding the preset threshold of 30 milliseconds. Therefore, it set the alarm flag in the TLV to an abnormal state, loaded and reported the SID fc00:s7::0, and prioritized forwarding the modified packet to the industrial monitoring platform. After parsing the TLV data, the platform extracted the session ID and the abnormal node SID, located the faulty link within 2 seconds, and then automatically issued a "switch to backup path" command. The entire fault recovery time did not exceed 30 seconds.

[0098] The technical effects achieved by the embodiments of the present invention include: no need to modify the native protocol stack; 100% accuracy in locating communication faults, accurately distinguishing between node faults and link faults; a single node modification increases latency by approximately 0.2 milliseconds, and a rewrite latency of approximately 0.1 milliseconds, with the total communication latency controlled within 15 milliseconds, fully meeting the millisecond-level real-time requirements of the S7 protocol; a cross-node fault tracing success rate of up to 99.9%, reducing the troubleshooting time from hours (approximately 2 hours) in traditional solutions to 2 seconds, improving efficiency by approximately 99%; continuous operation for 72 hours without anomalies, with a fault recovery time of no more than 30 seconds, effectively ensuring the business continuity of industrial production.

[0099] Figure 4 This is a flowchart illustrating an industrial communication fault location method based on network layer encapsulated messages, such as... Figure 4 As shown, the industrial communication fault location method based on network layer encapsulated messages proposed in this invention includes the following steps: 410: The first network node device receives a first industrial protocol message, which is generated by the industrial equipment; 420: The first network node device performs network layer encapsulation on the first industrial protocol message to generate a second industrial protocol message, fills the information in the first industrial protocol message into the fault tracing field of the second industrial protocol message, and then sends the second industrial protocol message to the second network node device; wherein, the first industrial protocol message and the second industrial protocol message use different communication protocols; 430: The second network node device determines whether a link has failed based on the fault tracing field in the second industrial protocol message. If a failure is determined, the alarm flag in the fault tracing field is set to an abnormal state, and the modified second industrial protocol message is forwarded to the industrial monitoring platform. 440: The industrial monitoring platform parses the fault tracing field in the second industrial protocol message and determines the fault link based on the fault tracing field.

[0100] In this way, by encapsulating industrial protocol messages into network layer messages carrying fault tracing fields, synchronous transmission of fault information and service messages is achieved; intermediate nodes can determine the link status and mark alarm flags in real time during forwarding, without the need for independent probes and dedicated signaling; the industrial monitoring platform can directly locate faulty links by parsing the fault tracing fields, without the need for manual hop-by-hop troubleshooting, significantly improving the real-time performance and accuracy of fault location and the troubleshooting efficiency in cross-plant scenarios, while being compatible with existing industrial equipment and having low deployment costs.

[0101] In some possible embodiments, step 420 includes: The first network node device adds an IP packet basic header and a segment routing extension header to the first industrial protocol message, and creates a fault tracing field in the optional TLV extension field of the segment routing extension header; Extract protocol-related information from the first industrial protocol message. The protocol-related information includes at least one of the following: message length field, transmission connection identifier, session identifier, device physical location identifier, and function code. The extracted protocol-related information is filled into the node information array of the fault tracing field, and the alarm flag is initialized to the normal state.

[0102] In this way, creating a fault tracing field using the optional TLV extension field in the SRv6 segment routing extension header fully complies with existing protocol specifications, requires no modification to the standard message structure, and has good compatibility and scalability. The fault tracing field and the path information carried by the SRH are in the same extension header, ensuring that fault monitoring is naturally bound to the segmented routing path, allowing subsequent nodes to directly obtain the complete path context. Furthermore, key information such as message length, transmission connection identifier, session identifier, device physical location identifier, and function code are extracted from the original industrial protocol message and populated into the node information array, enabling fault location to be precise down to the specific service connection and device, facilitating the monitoring platform to quickly associate faults with affected applications.

[0103] In some possible embodiments, step 430 includes: The second network node device determines the status information of the current link based on the fault tracing field, the status information including the communication latency and packet loss rate of the current link; The communication latency of the current link is compared with a preset latency threshold, and the packet loss rate of the current link is compared with a preset packet loss rate threshold. If the communication delay exceeds the preset delay threshold and / or the packet loss rate exceeds the preset packet loss rate threshold, then the current link is determined to have failed.

[0104] In this way, the second network node device performs real-time assessment of the link status based on two quantitative indicators: communication latency and packet loss rate, and uses a threshold comparison method to determine faults. The above judgment process is completed locally at the packet forwarding node, and the result is written to the fault tracing field in real time without additional signaling interaction. This ensures the real-time nature of fault perception while reducing the dependence on the computing and communication resources of the monitoring platform.

[0105] In some possible embodiments, it also includes: The target device receives the second industrial protocol message, strips the network layer encapsulation of the second industrial protocol message, and obtains the first industrial protocol message; The instructions in the first industrial protocol message are executed, and the execution result is filled into the fault tracing field of the second industrial protocol message through the network node directly connected to the target device to obtain the third industrial protocol message. The third industrial protocol message is then sent to the industrial monitoring platform.

[0106] This further achieves end-to-end closed-loop fault information and traceability of command execution results. After receiving the encapsulated message, the target device first decapsulates and executes the original industrial protocol command, then writes the execution result into the fault tracing field through the network node directly connected to it, forming a third industrial protocol message and reporting it to the monitoring platform. This allows the monitoring platform to simultaneously know the command execution status on the target device side, such as successful execution, timeout, or return of error codes, effectively distinguishing whether the fault is caused by a link anomaly or by a problem with the target device itself, avoiding misjudgment.

[0107] In some possible embodiments, the fault tracing field includes an array of node information, and further includes: When the first network node device and / or the second network node device forwards the second industrial protocol message, they write the node identifier, forwarding timestamp, link quality level, and forwarding status of the network node device into the node information array of the fault tracing field.

[0108] This achieves complete visibility and refined quality awareness of the message transmission path. Each forwarding node, while transmitting the message, simultaneously writes its own identity information, time information, link quality, and forwarding result into the fault tracing field, forming an irrefutable chain of path evidence. This enables the industrial monitoring platform to accurately reconstruct the real-time quality of each hop the message passes through, as well as any potential forwarding anomalies, thereby quickly locating faulty nodes or degraded sections.

[0109] In some possible embodiments, it also includes: When the number of nodes recorded in the node information array exceeds the preset maximum value, the head node, tail node, and abnormal state node in the node information number are retained, and the node information to be written is overwritten by the earliest written normal node information in reverse timestamp order.

[0110] In this way, when the node information array is about to overflow, the head node, tail node, and all nodes in abnormal states are retained first, ensuring that the start and end points of the transmission path and the critical hop point where a failure occurs are not lost. This balances the integrity of the path and the integrity of the fault focus information.

[0111] In some possible embodiments, it also includes: The industrial monitoring platform sends the format rules of the fault tracing field, the device location mapping table, and the communication fault detection threshold to the first network node device and the second network node device. The communication fault detection threshold includes a latency threshold and a packet loss rate threshold.

[0112] In this way, the monitoring platform can update thresholds and format rules at any time according to the actual needs of the industrial scenario, enabling fault detection to adapt to changes in network status or adjustments in service levels, thus enhancing the system's flexibility and maintainability. Furthermore, the distribution of the device location mapping table allows node devices to directly associate physical location information when writing fault tracing fields, providing the monitoring platform with a more intuitive basis for fault location.

[0113] In some possible embodiments, it also includes: The industrial monitoring platform issues a handling instruction to the first network node device and / or the second network node based on the identified faulty link. The handling instruction includes at least one of switching to a backup path, restarting the faulty node, or adjusting the routing strategy.

[0114] In this way, after identifying a faulty link, the industrial monitoring platform can proactively issue handling instructions to relevant network nodes, such as switching to backup paths, restarting faulty nodes, or adjusting routing strategies, without manual intervention. The fault recovery time is reduced from the traditional hours to seconds or milliseconds, significantly improving the business continuity of the industrial network. The handling instructions are only issued to the node devices affected by the fault, with fine-grained operation, avoiding network-wide oscillations.

[0115] Figure 5 This is a schematic diagram of an industrial communication fault location system based on network layer encapsulated messages, such as... Figure 5 As shown, an industrial communication fault location system based on network layer encapsulated messages is provided, comprising: A first network node device is used to receive a first industrial protocol message, which is generated by an industrial device. The first network node device is further configured to encapsulate the first industrial protocol message at the network layer to generate a second industrial protocol message, fill the information in the first industrial protocol message into the fault tracing field of the second industrial protocol message, and then send the second industrial protocol message to the second network node device; wherein the first industrial protocol message and the second industrial protocol message use different communication protocols; The second network node device is used to determine whether a link has failed based on the fault tracing field in the second industrial protocol message. If a failure is determined, the alarm flag in the fault tracing field is set to an abnormal state, and the modified second industrial protocol message is forwarded to the industrial monitoring platform. The industrial monitoring platform is used to parse the fault tracing field in the second industrial protocol message and determine the fault link based on the fault tracing field.

[0116] The first network node device is further configured to add an IP packet basic header and a segment routing extension header to the first industrial protocol message, and to create a fault tracing field in the optional TLV extension field of the segment routing extension header; Extract protocol-related information from the first industrial protocol message. The protocol-related information includes at least one of the following: message length field, transmission connection identifier, session identifier, device physical location identifier, and function code. The extracted protocol-related information is filled into the predefined fields of the fault tracing field, and the alarm flag is initialized to the normal state.

[0117] In some possible embodiments, the second network node device is configured to determine the status information of the current link based on the fault tracing field, the status information including the communication latency and packet loss rate of the current link; The communication latency of the current link is compared with a preset latency threshold, and the packet loss rate of the current link is compared with a preset packet loss rate threshold. If the communication delay exceeds the preset delay threshold and / or the packet loss rate exceeds the preset packet loss rate threshold, then the current link is determined to have failed.

[0118] In some possible embodiments, The target device is used to receive the second industrial protocol message, strip the network layer encapsulation of the second industrial protocol message, and obtain the first industrial protocol message. The instructions in the first industrial protocol message are executed, and the execution result is filled into the fault tracing field of the second industrial protocol message through the network node directly connected to the target device to obtain the third industrial protocol message. The third industrial protocol message is then sent to the industrial monitoring platform.

[0119] In some possible embodiments, When forwarding the second industrial protocol message, the first network node device and / or the second network node device write the node identifier, forwarding timestamp, link quality level and forwarding status of the network node device into the node information array of the fault tracing field.

[0120] In some possible embodiments, The first network node device and / or the second network node device are configured to retain the head node, tail node and abnormal state node in the node information number when the number of nodes recorded in the node information array exceeds a preset maximum value, and overwrite the earliest written normal node information with the node information to be written in reverse timestamp order.

[0121] In some possible embodiments, it also includes: The industrial monitoring platform is used to send the format rules of the fault tracing field, the device location mapping table, and the communication fault detection threshold to the first network node device and the second network node device, wherein the communication fault detection threshold includes a latency threshold and a packet loss rate threshold.

[0122] In some possible embodiments, it also includes: The industrial monitoring platform is used to issue handling instructions to the first network node device and / or the second network node according to the determined faulty link. The handling instructions include at least one of switching to a backup path, restarting the faulty node, or adjusting the routing strategy.

[0123] Those skilled in the art will readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, the present invention can be implemented in hardware or a combination of hardware and computer software. Whether a function is implemented in hardware or by computer software driving hardware 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 implementations should not be considered beyond the scope of the present invention.

[0124] It should be noted that, Figure 5 The division of modules / units is illustrative and represents only one logical functional division; in actual implementation, other division methods are possible. For example, two or more functions can be integrated into a single data acquisition module. The integrated modules described above can be implemented either in hardware or as software functional modules.

[0125] An electronic device according to an embodiment of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-mentioned industrial communication fault location methods based on network layer encapsulated messages. That is, an electronic device according to an embodiment of the present invention may include, but is not limited to: a processor and a memory; the memory is used to store the computer program; the processor is used to execute the industrial communication fault location method based on network layer encapsulated messages shown in any embodiment of the present invention by calling the computer program.

[0126] In one alternative embodiment, an electronic device is provided, such as Figure 6 As shown, Figure 6The illustrated electronic device 600 includes a processor 601 and a memory 603. The processor 601 and the memory 603 are connected, for example, via a bus 602. Optionally, the electronic device 600 may further include a transceiver 604, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 604 is not limited to one type, and the structure of the electronic device 600 does not constitute a limitation on the embodiments of the present invention.

[0127] Among them, electronic devices can also be terminal devices, which can be any device that can install applications, including at least one of smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, smart TVs, and smart in-vehicle devices.

[0128] It should be noted that, Figure 6 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of the present invention.

[0129] An embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-mentioned industrial communication fault location methods based on network layer encapsulated messages.

[0130] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

[0131] It should be noted that the terms "first," "second," etc., used in the specification and claims of this invention are used to distinguish similar objects and represent a limitation on a specific order or sequence. Where appropriate, the order of use for similar objects can be interchanged so that the embodiments of the invention described herein can be implemented in an order other than that shown or described.

[0132] Those skilled in the art will recognize that this invention can be implemented as a system, method, or computer program product. Therefore, this invention can be specifically implemented in the following forms: it can be entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system." Furthermore, in some embodiments, this invention can also be implemented as a computer program product contained in one or more computer-readable media, which includes computer-readable program code.

[0133] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for locating industrial communication faults based on network layer encapsulated messages, characterized in that, include: The first network node device receives a first industrial protocol message, which is generated by the industrial device. The first network node device performs network layer encapsulation on the first industrial protocol message to generate a second industrial protocol message, fills the information in the first industrial protocol message into the fault tracing field of the second industrial protocol message, and then sends the second industrial protocol message to the second network node device; wherein, the first industrial protocol message and the second industrial protocol message use different communication protocols; The second network node device determines whether a link has failed based on the fault tracing field in the second industrial protocol message. If a failure is determined, the alarm flag in the fault tracing field is set to an abnormal state, and the modified second industrial protocol message is forwarded to the industrial monitoring platform. The industrial monitoring platform parses the fault tracing field in the second industrial protocol message and determines the fault link based on the fault tracing field.

2. The method according to claim 1, characterized in that, The first network node device performs network layer encapsulation on the first industrial protocol message to generate a second industrial protocol message, including: The first network node device adds an IP packet basic header and a segment routing extension header to the first industrial protocol message, and creates a fault tracing field in the optional TLV extension field of the segment routing extension header; Extract protocol-related information from the first industrial protocol message. The protocol-related information includes at least one of the following: message length field, transmission connection identifier, session identifier, device physical location identifier, and function code. The extracted protocol-related information is filled into the node information array of the fault tracing field, and the alarm flag is initialized to the normal state.

3. The method according to claim 1, characterized in that, The second network node device determines whether a link failure has occurred based on the fault tracing field in the second industrial protocol message, including: The second network node device determines the status information of the current link based on the fault tracing field, the status information including the communication latency and packet loss rate of the current link; The communication latency of the current link is compared with a preset latency threshold, and the packet loss rate of the current link is compared with a preset packet loss rate threshold. If the communication delay exceeds the preset delay threshold and / or the packet loss rate exceeds the preset packet loss rate threshold, then the current link is determined to have failed.

4. The method according to claim 1, characterized in that, Also includes: The target device receives the second industrial protocol message, strips the network layer encapsulation of the second industrial protocol message, and obtains the first industrial protocol message; The instructions in the first industrial protocol message are executed, and the execution result is filled into the fault tracing field of the second industrial protocol message through the network node directly connected to the target device to obtain the third industrial protocol message. The third industrial protocol message is then sent to the industrial monitoring platform.

5. The method according to claim 1, characterized in that, The fault tracing field contains an array of node information, and the method further includes: When the first network node device and / or the second network node device forwards the second industrial protocol message, they write the node identifier, forwarding timestamp, link quality level, and forwarding status of the network node device into the node information array of the fault tracing field.

6. The method according to claim 5, characterized in that, Also includes: When the number of nodes recorded in the node information array exceeds the preset maximum value, the head node, tail node, and abnormal state node in the node information number are retained, and the node information to be written is overwritten by the earliest written normal node information in reverse timestamp order.

7. The method according to claim 1, characterized in that, Also includes: The industrial monitoring platform sends the format rules of the fault tracing field, the device location mapping table, and the communication fault detection threshold to the first network node device and the second network node device. The communication fault detection threshold includes a latency threshold and a packet loss rate threshold.

8. The method according to claim 1, characterized in that, Also includes: The industrial monitoring platform issues a handling instruction to the first network node device and / or the second network node based on the identified faulty link. The handling instruction includes at least one of switching to a backup path, restarting the faulty node, or adjusting the routing strategy.

9. An industrial communication fault location system based on network layer encapsulated messages, characterized in that, include: A first network node device is used to receive a first industrial protocol message, which is generated by an industrial device. The first network node device is further configured to encapsulate the first industrial protocol message at the network layer to generate a second industrial protocol message, fill the information in the first industrial protocol message into the fault tracing field of the second industrial protocol message, and then send the second industrial protocol message to the second network node device; wherein the first industrial protocol message and the second industrial protocol message use different communication protocols; The second network node device is used to determine whether a link has failed based on the fault tracing field in the second industrial protocol message. If a failure is determined, the alarm flag in the fault tracing field is set to an abnormal state, and the modified second industrial protocol message is forwarded to the industrial monitoring platform. The industrial monitoring platform is used to parse the fault tracing field in the second industrial protocol message and determine the fault link based on the fault tracing field.

10. The industrial communication fault location system based on network layer encapsulated messages according to claim 9, characterized in that, The first network node device is further configured to add an IP packet basic header and a segment routing extension header to the first industrial protocol message, and to create a fault tracing field in the optional TLV extension field of the segment routing extension header; Extract protocol-related information from the first industrial protocol message. The protocol-related information includes at least one of the following: message length field, transmission connection identifier, session identifier, device physical location identifier, and function code. The extracted protocol-related information is filled into the predefined fields of the fault tracing field, and the alarm flag is initialized to the normal state.

Images