PLC-bridging gateway internet-of-things automatic identification method, system, device and medium

Abstract

The invention relates to a PLC-bridging gateway internet-of-things automatic identification method, system and device and a medium. The method comprises the following steps: sequentially sending handshake detection signals to a plurality of PLC devices and receiving response messages; forming a candidate handshake data combination set, and completing handshake matching through a priority algorithm and an adaptive polling mechanism; verifying the response frame, analyzing the equipment information, and confirming the active state and communication parameters of the PLC equipment; generating a drive binding strategy according to a matching result, and distributing a session identifier for the drive binding strategy; generating a session identifier of the target PLC equipment, and updating a session routing table in the bridging gateway; and translating the industrial data collected by the target PLC device into an Internet of Things protocol data packet and uploading the Internet of Things protocol data packet to a cloud data center. According to the invention, automatic identification and rapid adaptation of various interfaces and protocols can be realized; the communication stability and real-time performance are improved through dynamic scheduling and route updating; uniform data uploading is supported, and efficient deployment of cloud analysis and the industrial Internet of Things is facilitated.

Description

Technical Field

[0001] This invention belongs to the field of industrial Internet of Things (IoT) technology, specifically relating to a PLC-bridging gateway IoT automatic identification method, system, device, and medium. Background Technology

[0002] A PLC (Programmable Logic Controller) is a digital computing device specifically designed for industrial control. It features high reliability, strong anti-interference capabilities, and flexible programming, enabling automatic control of equipment and processes in industrial settings. In typical industrial production systems, PLC devices communicate with host computers, execution units, or field sensors via physical interfaces to achieve real-time monitoring and scheduling of industrial processes. The performance of a PLC system depends on several factors, including the configuration of the communication interface, protocol compatibility, and driver adaptability. Therefore, in environments with multiple vendors and devices, device access and interoperability present significant challenges.

[0003] In practical applications, PLC devices from different manufacturers typically employ different physical interfaces and communication protocols. Traditional gateway access methods require manual configuration of communication parameters or rely on pre-built single driver modules. The parameter configuration process is cumbersome and prone to errors, resulting in low access efficiency and even communication failures. Especially in industrial environments with multiple interfaces and protocols, quickly identifying and matching the communication protocols and parameters of PLC devices to establish stable and reliable communication sessions has become a key issue in the deployment and operation of industrial IoT systems. Summary of the Invention

[0004] To address the aforementioned issues, this disclosure provides a PLC-bridging gateway IoT automatic identification method, system, device, and medium. This disclosure improves the efficiency and coverage of handshake detection by introducing a stable hash and multi-stage priority scheduling mechanism; it ensures the accuracy of protocol identification and device confirmation by employing CRC multi-algorithm verification and field validity judgment; it utilizes dynamic binding and delayed release update strategies to maintain communication link continuity during session switching, effectively avoiding data loss; and it supports multiple interfaces such as RS485, RS232, CAN, and Ethernet, as well as mainstream industrial protocols, improving compatibility and engineering deployment efficiency for cross-vendor PLC access.

[0005] According to a first aspect of this disclosure, a PLC-bridging gateway IoT automatic identification method is provided, comprising the following steps:

[0006] Connect the bridging gateway to the industrial site, send handshake detection signals to multiple PLC devices in the industrial site in sequence, and receive the response messages returned by the PLC devices.

[0007] By matching the protocol feature database, a driver binding strategy is automatically generated to identify the communication protocol and physical interface used by the PLC device. The response message is then verified and parsed, and the activity status and communication parameters of the PLC device are confirmed based on the parsing results.

[0008] Based on the matching results, a driver binding strategy is generated inside the bridging gateway, and the corresponding driver binding module is called to establish a data communication session with the PLC device.

[0009] The industrial data collected by the PLC device is uniformly formatted and cached, and then translated into data packets of the Internet of Things communication protocol.

[0010] The successfully matched communication parameters are dynamically bound to the drive module to generate a session identifier for the target PLC device and update the session routing table in the bridging gateway.

[0011] The standardized industrial data is uploaded to the cloud data center, enabling bridging communication between PLC devices and IoT systems.

[0012] According to a second aspect of this disclosure, a PLC-bridge gateway IoT automatic identification system is provided, the system comprising a communication interface module, a protocol feature matching and message verification module, a driver binding module, a data formatting module, a routing table update module, and an IoT interface module;

[0013] The communication interface module is used to sequentially send handshake detection signals to multiple PLC devices in the industrial field and receive response messages returned by the PLC devices.

[0014] The protocol feature matching and message verification module is used to match the response message with the protocol feature database to identify the communication protocol and physical interface used by the PLC device, and to verify and parse the response message to confirm the activity status and communication parameters of the PLC device.

[0015] The drive binding module is used to generate a drive binding strategy within the bridging gateway based on the matching result, and call the corresponding drive module to establish a data communication session with the PLC device.

[0016] The data formatting module is used to uniformly format and cache the industrial data collected by the PLC device, and translate it into data packets of the Internet of Things communication protocol.

[0017] The routing table update module is used to dynamically bind the successfully matched communication parameters to the drive module, generate the session identifier of the target PLC device, and update the session routing table in the bridging gateway.

[0018] The IoT interface module is used to upload the uniformly formatted industrial data to the cloud data center to achieve bridging communication between the PLC device and the IoT system.

[0019] According to a third aspect of this disclosure, a PLC-bridging gateway IoT automatic identification device is provided, including a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the method described above.

[0020] According to a fourth aspect of this disclosure, a computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described above.

[0021] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features and beneficial effects of this disclosure will become readily apparent from the following description. Attached Figure Description

[0022] This disclosure can be better understood by referring to the accompanying drawings, and its numerous features and advantages will be apparent to those skilled in the art. The same reference numerals are used in different drawings to indicate similar or identical items.

[0023] Figure 1 This is a schematic diagram illustrating an example environment for data interaction between a bridging gateway, a PLC device, and the cloud, as implemented in an embodiment of this disclosure.

[0024] Figure 2 A small hardware platform is shown in an embodiment of the present invention.

[0025] Figure 3 A flowchart of the PLC-bridging gateway IoT automatic identification method 200 provided in an embodiment of this disclosure is shown.

[0026] Figure 4 A flowchart of a method 300 for sequentially sending handshake probe signals to a plurality of PLC devices in an industrial field and receiving response messages returned by the PLC devices, according to an embodiment of the present disclosure, is shown.

[0027] Figure 5 A flowchart of a method 400 for forming a candidate handshake data combination set based on a preset communication template according to an embodiment of the present disclosure is shown.

[0028] Figure 6 The diagram illustrates a typical frame structure for an industry-standard serial interface.

[0029] Figure 7 A flowchart illustrating a method 400 according to an embodiment of the present disclosure is shown, which divides a plurality of candidate handshake data combinations that have not been initially divided into a plurality of subsets.

[0030] Figure 8 The real-time monitoring results of the bridging gateway in this application during the handshake detection and data transmission process are shown.

[0031] Figure 9 A flowchart of a method 500 for secondary scanning of interfaces that have abnormal responses but have physical connections, according to an embodiment of the present disclosure, is shown. This method selects the most likely successful combination of attempts using a priority algorithm and performs an adaptive polling mechanism.

[0032] Figure 10 The process of transferring and discarding candidate handshake data combinations in a multi-level container is illustrated schematically in method 500 of this disclosure embodiment.

[0033] Figure 11 This diagram illustrates a comparison of the number of successful handshake combinations across four different transmission slots under varying total load and low-load node percentages.

[0034] Figure 12 The results show the comparison of the number of successful handshakes in the four transmission slots under different total load levels and different proportions of low-load nodes.

[0035] Figure 13 A flowchart of a method 600 for performing a secondary scan of interfaces that have partially abnormal responses but have physical connections, according to an embodiment of the present disclosure, is shown.

[0036] Figure 14A The data stream of the response frame verification result for candidate handshake data combinations of RS485 interface type is shown as the bits change.

[0037] Figure 14B The data stream of the response frame verification result for a candidate handshake data combination for an Ethernet interface type is shown as the bits change.

[0038] Figure 14C The data stream of the response frame verification result for a candidate handshake data combination for a CAN interface type is shown as the bits change.

[0039] Figure 15 A flowchart is shown of a method 700 for generating a driver binding strategy and invoking the corresponding driver binding module according to an embodiment of the present disclosure.

[0040] Figure 16A flowchart of a method 800 for dynamically binding successfully matched communication parameters to a driver module and updating a session routing table according to an embodiment of the present disclosure is shown.

[0041] Figure 17 The process of dynamically updating the session routing table of method 800 according to an embodiment of the present disclosure is illustrated.

[0042] Figure 18 A block diagram of an example device 1100 for automatic IoT identification of a PLC-bridging gateway according to an example embodiment of this application is shown. Detailed Implementation

[0043] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0044] As described in the background section, PLC devices, as core control units, are widely used in industrial settings such as assembly lines, CNC machining, metallurgy, chemical engineering, and warehousing and logistics. However, PLC devices from different manufacturers often employ different physical interfaces and communication protocols, such as RS232 serial ports, RS485 serial ports, Ethernet, Modbus TCP, Siemens S7, and CAN. This results in complex manual configuration and debugging during system integration. This not only increases deployment costs and time but also easily leads to communication failures or data loss due to configuration errors. Especially in industrial environments with multiple interfaces and protocols, achieving rapid PLC device integration and reliable communication becomes a critical issue.

[0045] In existing industrial gateway applications, manual selection of communication parameters or pre-installation of specific protocol drivers are often required to support different types of PLC devices. This approach lacks versatility and scalability, and requires reconfiguration when equipment is updated or field conditions change, failing to meet the efficiency and automation requirements of smart manufacturing and the Industrial Internet of Things. Therefore, there is an urgent need for a technical solution that can automatically identify and bind multi-interface, multi-protocol PLC devices upon gateway access, in order to improve the scalability and communication stability of industrial field systems.

[0046] Traditional industrial IoT access technologies often require manual configuration of communication parameters and protocol drivers when dealing with PLC devices that have multiple interfaces and protocols. This not only leads to low access efficiency, but also, in some cases, can cause device identification failures or data loss due to incorrect parameter configuration or insufficient protocol compatibility, thus affecting the real-time performance and reliability of the industrial field.

[0047] In view of this, this disclosure proposes an automatic identification method for PLC-bridging gateway IoT devices. This method can automatically identify and connect multi-interface, multi-protocol PLC devices when the bridging gateway is connected to an industrial site. Through protocol feature matching and driver binding strategy generation, it automatically establishes data communication sessions and uniformly formats industrial data under different protocols into data packets of IoT communication protocols, ensuring the efficiency and stability of the data upload process.

[0048] Figure 1 An example environment in which embodiments of this disclosure can operate is illustrated. In this environment, a bridging gateway 112 is deployed in an industrial field to connect various types of PLC devices 114 and to communicate bidirectionally with a cloud data center 110. The bridging gateway 112 internally executes the automatic identification method, sequentially sending handshake probe signals to the PLC devices 114 through the communication interface, capturing the returned response messages, and verifying and parsing the messages. Based on the parsing results, the bridging gateway 112 can identify the communication protocol type of different PLC devices (e.g., Omron-FINS, Modbus TCP, Siemens S7, DeviceNet, etc.) and confirm their activity status and communication parameters.

[0049] After completing automatic identification, the bridging gateway 112 calls its internal driver binding module to generate a driver binding strategy based on the matching results, thereby establishing a data communication session with the target PLC device 114. During this process, the bridging gateway 112 can uniformly format and cache the industrial data collected by the PLC device 114, translating it into standardized IoT communication protocol data packets, such as MQTT, HTTP, CoAP, or private TCP.

[0050] Subsequently, the bridging gateway 112 uploads the processed data to the cloud data center 110 via the IoT interface. The cloud data center 110 can function as a host computer, remote monitoring center, or cloud platform, used for centralized storage, analysis, and scheduling of industrial data, enabling unified management and remote control of PLC devices from different sources. In this way, the cloud data center 110 in the example environment can maintain efficient and stable data interaction with multiple PLC devices 114, ensuring real-time monitoring and remote decision support in the industrial field.

[0051] Figure 2This invention illustrates a small hardware platform for verifying the feasibility of the PLC-bridging gateway IoT automatic method. In this platform, a Siemens S7 PLC serves as the control unit in an industrial field, collecting and outputting industrial control data. The PLC-bridging gateway IoT automatic identification system 101 is deployed on embedded hardware and connected to an external gateway device via an IoT interface module. A host computer, cloud platform, or remote monitoring center receives formatted data from the gateway via an Ethernet interface, enabling remote monitoring and management of the PLC device. Furthermore, the PLC device's data acquisition nodes can sample field parameters and forward data through the bridging gateway. This hardware platform intuitively reflects the system workflow of this application, providing a verification foundation for subsequent large-scale applications.

[0052] The PLC-bridge gateway IoT automatic identification system 101 includes a communication interface module, a protocol feature matching and message verification module, a driver binding module, a data formatting module, a routing table update module, and an IoT interface module.

[0053] Regarding the communication interface module, it is used to sequentially send handshake detection signals to multiple PLC devices in the industrial field and receive response messages returned by the PLC devices;

[0054] The protocol feature matching and message verification module is used to match the response message with the protocol feature database to identify the communication protocol and physical interface used by the PLC device, and to verify and parse the response message to confirm the activity status and communication parameters of the PLC device.

[0055] Regarding the driver binding module, it is used to generate a driver binding strategy within the bridging gateway based on the matching result, and call the corresponding driver module to establish a data communication session with the PLC device;

[0056] The data formatting module is used to uniformly format and cache the industrial data collected by the PLC device, and translate it into data packets of the Internet of Things communication protocol.

[0057] Regarding the routing table update module, it is used to dynamically bind the successfully matched communication parameters with the drive module, generate the session identifier of the target PLC device, and update the session routing table in the bridging gateway.

[0058] The IoT interface module is used to upload the uniformly formatted industrial data to the cloud data center to achieve bridging communication between the PLC device and the IoT system.

[0059] Figure 3 A flowchart of the PLC-bridging gateway IoT automatic identification method 200 provided in an embodiment of this disclosure is shown.

[0060] In step 202, the bridging gateway is connected to the industrial site, and handshake probe signals are sent sequentially to multiple PLC devices, and response messages are received. In some embodiments, the handshake probe signals can be sent one by one according to the interface type (such as RS485, CAN, Modbus TCP, PROFINET). In other embodiments, the system can adopt an adaptive polling mechanism to initiate probes on candidate handshake probe data of all physical interfaces in parallel to improve the overall identification efficiency.

[0061] In step 204, a drive binding strategy is automatically generated by matching the protocol feature database, and the response message is verified and parsed to confirm the PLC's activity status and communication parameters. In some embodiments, the verification methods include CRC check, function code parsing, and device station number validity judgment. In other embodiments, cross-vendor protocol matching can be achieved by expanding the protocol template database or using a machine learning-based message feature recognition algorithm.

[0062] In step 206, a driver binding strategy is generated within the bridging gateway based on the matching results, and the corresponding driver binding module is invoked to establish a data communication session with the PLC device. In some embodiments, the driver binding strategy can adopt a static mapping method, directly associating the protocol type with the corresponding driver module; in other embodiments, the driver binding can be dynamically adjusted based on indicators such as communication success rate and response latency to achieve optimal driver selection.

[0063] In step 208, the industrial data collected by the PLC device is uniformly formatted and cached, and then translated into data packets of the Internet of Things (IoT) communication protocol. In some embodiments, the formatting process only includes field standardization and timestamp alignment; in other embodiments, it may also be combined with aggregation compression, outlier filtering, and encryption mechanisms to make the data more suitable for uplink transmission and security management.

[0064] In step 210, the successfully matched communication parameters are dynamically bound to the driver module, a session identifier for the target PLC device is generated, and the session routing table in the bridging gateway is updated. In some embodiments, the session identifier can be generated by directly concatenating the device ID, subset number, and time window. In other embodiments, a hash function or encryption algorithm can be used to generate a unique identifier to enhance anti-collision and security.

[0065] In step 212, the uniformly formatted industrial data is uploaded to the cloud data center to achieve bridging communication between the PLC and the IoT system. In some embodiments, data packets are published to the cloud data center via the MQTT protocol. In other embodiments, reports can be made via HTTP, CoAP, or a private TCP protocol to achieve compatibility with different types of cloud platforms or host computers and remote monitoring centers.

[0066] Figure 4 A flowchart of a method 300 for sequentially sending handshake probe signals to a plurality of PLC devices in an industrial field and receiving response messages returned by the PLC devices, according to an embodiment of the present disclosure, is shown.

[0067] In step 302, the bridging gateway automatically configures the probe parameter combination for each interface according to a preset communication template. The communication template includes parameters such as baud rate, parity bit, data bits, and stop bits. Parameter combinations corresponding to different interface types are set as candidate values. The bridging gateway binds the interface type parameters to the corresponding probe parameter combinations, thereby forming multiple candidate handshake data combinations, and further organizes them into a candidate combination set for subsequent identification.

[0068] In step 304, to reduce the time and resource overhead of blind attempts, the system prioritizes the candidate handshake data combination set, selecting combinations with higher success probabilities for handshake attempts. This priority algorithm can be set based on historical recognition records, default configurations of common manufacturer devices, or the strength of real-time feedback signals, thereby improving the success rate and recognition efficiency of the first handshake.

[0069] In step 306, for interfaces that, although physically connected, exhibited an abnormal initial handshake response, the bridging gateway employs an adaptive polling mechanism to perform a secondary scan. This mechanism re-probes candidate combinations that failed to receive a correct response in the initial handshake, eliminating misjudgments caused by transient interference, jitter, or response delays. This secondary scan step effectively improves overall identification coverage, ensuring that more PLC devices are correctly identified and connected.

[0070] Figure 5 A flowchart of a method 400 for forming a candidate handshake data combination set based on a preset communication template according to an embodiment of the present disclosure is shown.

[0071] In step 402, based on the automatic adaptation PLC communication protocol driver of the bridging gateway, the combination of detection parameters for each structure is automatically configured, thereby forming the interface type set R and the protocol detection parameter set P, and then forming the candidate handshake data combination set U.

[0072] Define a set of interface types: R = {r1, r2, ..., r}N}, r n Let n be the nth interface type, n = 1, 2, ..., N; define a set of protocol probe parameter types C = {c1, c2, ..., c...} K}, c k Let k be the k-th parameter, where k = 1, 2, ..., K.

[0073] In step 404, for each candidate handshake data combination u in the candidate handshake data combination set... j The attribute fields in the string are concatenated in order to form the string of the j-th candidate handshake data combination. string The input is mixed into a stable hash function with a fixed seed s in each XOR operation. string Convert to a byte stream;

[0074] For each candidate combination u j The attribute fields in the string are concatenated into a single string in order. For example, when the protocol probe parameters include baud rate, data bits, stop bits, and parity check results... Here, port_type is the attribute field for the interface type, baud is the attribute field for the baud rate, databits is the attribute field for the data bits, stopbits is the attribute field for the stop bits, parity is the attribute field for parity, and concat() means concatenating multiple attribute fields into a single string in sequence.

[0075] The parameter set includes, but is not limited to, one or more of the following parameter types: baud rate, parity, data bits, and stop bits, as shown in Table 2.

[0076] The PLCs (Programmable Logic Controllers) used in industrial settings come from different manufacturers (such as Siemens, Omron, Mitsubishi, Schneider Electric, Beckhoff, etc.) and employ diverse communication protocols and physical interfaces, as shown in Table 1.

[0077] Table 1 PLC Protocol and Interface Correspondence Table

[0078]

[0079]

[0080] In Table 1, Modbus RTU is a serial protocol used for serial communication. The physical interface corresponding to this protocol is primarily RS485, supporting multiple slave devices; RS232 is only used for point-to-point network data transmission. Modbus TCP is a Modbus protocol implemented on top of TCP / IP and must rely on Ethernet for data transmission. The specific S7 protocol depends on the PLC series model. For example, the S7-300 typically uses the Siemens S7 protocol with a PROFINET interface, while the S7-200 uses the Siemens S7 protocol with an MPI or PPI interface. Omron FINS (Omron FINS protocol) is commonly used in Omron CJ, CS, and NX series PLC devices, connecting via Ethernet; there is also a serial version, FINS Host Link. Mitsubishi FX / Q refers to the Mitsubishi protocol's FX series or Q series. The Mitsubishi protocol's FX series mostly uses an RS422 serial port, while the Mitsubishi protocol's Q series supports an Ethernet interface. DeviceNet's protocol types are supported by Rockwell AB devices, while the CANopen protocol is typically used by Schneider-branded PLC devices. For example, the interface set R = {RS232, RS485, RS422, CAN, Ethernet} is just an example of an interface set and does not mean that the interface types are limited to those in this example; other interface types can also be included.

[0081] Table 2 Parameter Types and Optional Values

[0082] Parameter types Common optional values Baud Rate RS232 / RS485 Data Bits 5,6,7,8 Stop bits 1,1.5,2 Parity bit None, Even, Odd, Mark, Space

[0083] The specific parameter types in the protocol probe parameter set P are shown in the left column of Table 2. For example, c1 is the baud rate, c2 is the data bits, and c3 is the parity bit. In the parity bits in Table 2, None indicates no parity, Even indicates even parity, Odd indicates odd parity, Mark indicates constant 1 parity, and Space indicates constant 0 parity. For example, for even parity, the data bits 1010001 have three "1"s. If odd parity is used, the parity bit is 0 (keeping the total number of bits 3, an odd number). The communication mode can be formed from Table 2, which is usually 1 start bit + N data bits + parity bit + stop bit (combinations such as 8N1, 7E1, etc.). Figure 6This diagram illustrates a typical frame structure for an industry-standard serial interface (such as RS485 / RS232). This type of interface uses asynchronous serial transmission, with bit time as the smallest transmission unit. TXD is the data line, and its timing is determined by the baud rate clock at the transmitting end. The communication frame begins with a start bit. When the bus is idle and high, a high-to-low transition of TXD indicates the start of a transmission, entering the data phase. In the data phase, each frame contains 1 to N data bits, where N is typically configurable as 5, 6, 7, or 8 bits, corresponding to the "data bits" field in the candidate handshake parameter set. In multi-byte transmission scenarios, subsequent data bytes sequentially enter the same structure, i.e., a cycle of "start bit + data bits + parity bit + stop bit," as shown by the 1-N data bits and the subsequent stop bit in the diagram. In embodiments of this disclosure, the bridging gateway performs verification on the response frame by combining different data bit-parity bit-stop bit parameter modes (such as 8N1, 7E1, etc.) to confirm the PLC interface configuration, achieving automatic identification of multiple interfaces and protocols.

[0084] For each type of protocol probe parameter set P, there are different optional values, as shown in the right column of Table 2. Taking the k-th parameter as an example, its set of optional values ​​is V(c k )={v k1 ,v k2 ,…,v km ,…,v kM}, where v kM Let M be the m-th optional value of the k-th parameter, and M be the total number of optional values ​​for the k-th parameter. The total number of optional values ​​may be the same or different for different types of parameters. Therefore, the protocol probe parameter set P is: P = V(c1) × V(c2) × … × V(c... K In this equation, the "×" sign represents the Cartesian product of two possible values. For example, V(c1)×V(c2) indicates the Cartesian product of the possible values ​​V(c1) for the first parameter c1 and V(c2) for the second parameter c2. For instance, when the first parameter c1 is the baud rate, the second parameter c2 is the data bits, and the third parameter c3 is the parity bit, the possible value sets for each parameter are as follows:

[0085] V(c1) = {9600, 19200};

[0086] V(c2) = {5, 6, 7, 8};

[0087] V(c3) = {None, Odd};

[0088] The resulting protocol probe parameter combination P = V(c1) × V(c2) × V(c3) = {(9600,7,None),(9600,7,Odd),(9600,8,None),(9600,8,Odd),(19200,7,None)}.

[0089] The protocol probe parameter set represents the combination of multiple possible combinations (i.e., the Cartesian product of each parameter type) selected from its optional values. All possible combinations are enumerated to form the protocol probe parameter set P.

[0090] Therefore, the interface set and protocol probe parameter set constitute the candidate handshake data combination set U = R × P = {u1, u2, ..., u} when the bridging gateway sends handshake probe signals to various PLC devices in industrial applications. J}, u j Let j be the j-th candidate handshake data combination, where j = 1, 2, ..., J;

[0091] card(V(c k )) is a function that extracts the total number of possible values ​​for the k-th parameter. To ensure that each parameter of all types is always multiplied together, using the corresponding parameters and number of types in the above protocol probe parameter combination example, the first type of parameter c1 has two possible values ​​corresponding to the baud rate: 9600 and 19200. Therefore, card(V(c1)) = 2. Similarly, card(V(c2)) = 2, card(V(c3)) = 2.

[0092] In the stable hashing method, each candidate handshake data combination u j It will first be converted into its feature string For example, a string containing interface type, baud rate, data bits, stop bits, checksum, etc. Stable hash function. A fixed seed s will be introduced during the calculation. The purpose of this fixed seed is to ensure that the same candidate combination u is calculated correctly under different runs or different permutations. j It can always map to the same hash value h(u) j This avoids unstable partitioning caused by changes in order or differences in implementation. Furthermore, by using the calculation result of a stable hash function and then taking the modulo of the expected total number of partitioned subsets *b*, the entire allocation process is deterministic. That is, once the seed *s* is fixed, any candidate set will yield the same subset partitioning result during repeated runs. Simultaneously, the uniform distribution of the hash function ensures that candidate combinations are distributed as evenly as possible across multiple subsets, preventing extreme cases where one subset is excessive or another is empty.

[0093] The result of the stable hash function calculation, h(u) j The modulo operation on the expected total number of subsets *b* is then incremented by 1. This means that arbitrarily large hash values ​​are compressed and mapped to integer numbers between 1, 2, ..., *b*, which are used as subset numbers. Thus, the j-th candidate handshake data combination *u*... j It was assigned to Subset(u) j A subset of ).

[0094] Regarding the hash function h(u) j The fixed seed s in ) is an integer constant, which can be 42 in decimal or 0x9747b28c in hexadecimal.

[0095] For stable hash functions, MurmurHash3, FNV hash (Fowler–Noll–VoHash), Farm hash, or CityHash can be used. The specific hash calculation formula for MurmurHash3 is as follows:

[0096]

[0097] Where i is the total number of attribute fields in the j-th string, for example The attribute fields have four types: interface type RS485, baud rate 9600, communication mode 8N1 (data bits + parity + stop bits), and parity result None (in which case I = 4); ord(φ(u j [i] is used to calculate the u-th... j A string of candidate handshake data combinations The encoding of the i-th character in the array; ⊕ is the XOR operator; c1 and c2 are the first and second mixed constants respectively, r1 is the number of bits for the circular left shift, ord(φ(u j The meaning of the calculation of )[i])×c1)<<1 is that (ord(φ(u)) is first calculated as (ord(φ(u)) j The calculation result of )[i]) is amplified by a large prime number through the first mixing constant c1, and then the amplified binary result (ord(φ(u)) is used to calculate the binary result of )[i]). j The binary representation of (i) × c1 is shifted left by r1 bits, scrambling the bit positions. This mixes the high and low bits, further amplifying the input differences. r1 is typically 15. c1 can be 0xcc9e2d51 (hexadecimal), which is equivalent to 3432918353 in decimal. c2 can be 0x1b873593 (hexadecimal), which is equivalent to 461845907 in decimal. In hash function operations, all representations are equivalent, ultimately resulting in a 32-bit unsigned integer at the underlying level.

[0098] The formula for calculating the FNV hash is as follows:

[0099] h(u j )=(((h i-1 ⊕ord(φ(u j )[i]))×p)mod 2 32 );

[0100] Where p is the prime factor of the FNV hash, p = 16777619 (binary value); ⊕ is the XOR operator, which maintains the hash result at 2. 32 Within the range; h t-1 To process the intermediate hash value after the first i-1 characters, when initially calculating the first character, h0 = s, which means performing an operation between the initial hash value h0 and the ASCII value of the first character; or performing an XOR operation between the initial seed hash value hinit and the seed to obtain the initial hash value h0; × represents a multiplication operation;

[0101] The CityHash calculation formula is as follows:

[0102]

[0103] Where c is the hash constant, for example, c is 0x9ddfea08eb382d69. The Mix() function is an internal mixing function, including one or more of rotation, multiplication, and XOR; ⊕ is the XOR operator.

[0104] In step 406, the stable hash function h(u) is further used. j The result of the operation is moduloed to determine the j-th candidate handshake data combination u. j The subset number to which it is assigned (Subset(u)) j ):

[0105] Subset(u j )=1+(h(u j )mod b);

[0106] Where b is the total number of subsets expected to be partitioned from all elements in the candidate handshake data combination set U.

[0107] Figure 7 The flowchart illustrates the process of dividing multiple un-initialized candidate handshake data combinations into multiple subsets according to method 400. Figure 7The multiple squares in the first row represent 12 candidate handshake data combinations U that are initially in a mixed state and have not yet been preliminarily divided according to parameters such as baud rate in the interface type or protocol probe parameter set: denoted as R1-R4, C1-C4, and E1-E4 respectively. Table 3 shows the interface type parameters and protocol probe parameters of the 12 candidate handshake data combinations.

[0108] Table 3. Information and strings of 12 candidate handshake data combinations

[0109] Combination number Combined information String code representation R1 RS485, 9600, 8, 1, None RS485960081None R2 RS485, 19200, 8N1, None RS4851920081None R3 RS485, 38400, 8E1, Even RS4853840081Even R4 RS485, 57600, 8O1, Odd RS4855760081Odd C1 CAN, 125k, standard frame, CRC CAN125kSTDCRC C2 CAN, 250k, standard frame, CRC CAN250kSTDCRC C3 CAN, 500k, standard frame, CRC CAN500kSTDCRC C4 CAN, 1M, standard frame, CRC CAN1MSTDCRC E1 Modbus TCP, TCP, 502, Device Discovery MBTCPTCP502DISC E2 PROFINET DCP, UDP, 34964, Device Discovery PNIOUDP34964DISC E3 Modbus TCP, vendor-extended ports, device discovery MBTCPEXTDISC E4 PROFINET, multicast discovery, neighbor query PNIODISC

[0110] For example, the combination "RS485,9600,8,N,1,None" indicates that the interface type is RS485, the baud rate is 9600, the data bits are 8, the stop bits are 1, and there is no parity. The specific explanation of the combination information of R2-R4 is similar. The C1 combination "CAN,125k,standard frame,CRC" indicates that the interface type is CAN bus (Controller Area Network), the communication rate is 125kbps, and the standard frame format is used (i.e., 11-bit identifier frame structure, not 29-bit extended frame). The check method is CRC (Cyclic Redundancy Check), which is used to detect and correct bit-level errors during bus transmission to ensure the reliability of message data. When the bridging gateway is probing, it will send probe messages with a 125kbps standard frame + CRC check configuration to determine whether the target device is online / responsive. The specific explanation of the C2-C4 combinations is similar. The E1 combination "ModbusTCP, TCP, 502, Device Discovery" indicates that the interface type is Ethernet Modbus TCP, the transport layer protocol is TCP, and the port is 502. The bridging gateway uses device discovery (such as handshake / polling on port 502) to detect whether the target device is online and obtain basic identifiers. The E2 combination "PROFINET DCP, UDP, 34964, Device Discovery" indicates that the interface type is PROFINET, using the DCP (Discovery & Basic Configuration) mechanism, the transport layer is UDP, and the port is 34964. The gateway discovers nearby PROFINET devices by sending DCP messages such as Identify. The E3 combination indicates that the interface type is Modbus TCP, but it does not use the standard port 502; instead, it attempts to use vendor-extended / custom ports (such as specific port ranges opened by some devices). The gateway performs device discovery handshakes (or probes) on these ports. The E4 combination indicates that the interface type is PROFINET, and discovery / neighbor queries are performed via multicast (e.g., in conjunction with switch neighbor information or multicast probe messages) to quickly determine whether PROFINET devices exist in the field and collect basic topology clues.

[0111] Taking candidate handshake data combination R1 as an example, the process of its partitioning into subsets is explained in detail. FNV hashing (32-bit) is performed step-by-step on R1 = "RS485960081None". When R1 is the first candidate handshake data combination, the feature string corresponding to combination R1 is: The fixed seed in the FNV hash is s=7, h init =2166136261, then h0 = h init ⊕s, in the feature string When calculating each character in the text,

[0112] h i =((h) i-1 ⊕byte i )×p)mod 2 32 ;

[0113] in, byte i It is the integer value of the i-th character in the string after ASCII encoding (or UTF-8 single-byte encoding).

[0114] For feature strings: The ASCII codes (decimal) corresponding to each character in the text are as follows: 82, 83, 52, 56, 53, 57, 54, 48, 48, 56, 49, 78, 111, 110, 101.

[0115] The hash of each specific character is calculated to obtain the final feature string. The bitwise calculation of the hash value h(u1) is shown in Table 4.

[0116] Table 4. Hash values ​​of R1 candidate handshake data combinations calculated bit by bit.

[0117]

[0118]

[0119] Therefore, the final hash value h(u1) of combination R1 is 2,931,440,694 (it should be noted that the comma in the hash value in Table 4, i.e., the corresponding decimal calculation result, represents the thousands separator), which is 0xAF05C1F6 in hexadecimal; 2,931,440,694 mod 3 = 0, so the subset number to which combination R1 is assigned is Subset(u1) = 1 + 2931440694 mod 3 = 1. Therefore, as Figure 7As shown, combination R1 is assigned to the first subset, which consists entirely of red squares. Following the same calculation method, the assignment of each of the 12 candidate handshake data combinations in Table 3 above is calculated sequentially, resulting in the following: Figure 7 The data combinations shown, all with RS485 interfaces (i.e., R1-R4 combinations), are divided into the first subset, represented by red squares (each square represents a candidate handshake data combination); the data combinations with CAN interfaces (i.e., C1-C4 combinations) are divided into the second subset, represented by purple squares; and the data combinations with Ethernet interfaces (i.e., E1-E4 combinations) are divided into the third subset, represented by blue squares.

[0120] The final combination of each candidate handshake data in each subset is sent as a handshake probe signal by the bridging gateway to multiple PLC devices for handshake probe scanning. Figure 8 The real-time monitoring results of the bridging gateway in this application during the handshake detection and data transmission process are shown. Figure 8 The table at the top center displays the communication addresses and read / write operations at different points in time. For example, "23W" indicates a write command is sent to the PLC device with address 23, and "23R" indicates a read operation is initiated on the device with the same address. The waveforms below, such as 00a, 0C~a, 23Wa, and 23Ra, correspond to data frames or acknowledgment responses at different stages, reflecting the request-response interaction process between the gateway and the PLC device.

[0121] The monitoring results show that some write and read operations received valid responses, but there were also Missing Ack instances. This indicates that while some candidate handshake data combinations were successfully sent, they were not acknowledged by the PLC device. Therefore, it is necessary to perform a secondary scan of the handshake detection signal to achieve secondary handshake confirmation. This application uses statistical analysis of these real-time monitoring data, combined with an adaptive polling and secondary scanning mechanism, to achieve dynamic filtering of different communication parameter combinations, thereby improving the coverage and stability of communication parameter identification.

[0122] Figure 9 A flowchart of a method 500 according to an embodiment of the present disclosure is shown, which selects the most likely successful combination of attempts using a priority algorithm and performs a secondary scan of interfaces that have abnormal responses but have physical connections using an adaptive polling mechanism.

[0123] In some embodiments, the detection signals of multiple subsets obtained by dividing the candidate handshake data combination set U by method 400 are sent to multiple PLC devices in the industrial scenario, and the priority and rate of signal verification detection of each subset are graded according to the strength of the feedback signal.

[0124] In step 502, the total number of subsets after partitioning is S, and S is set to {S1, S2, ..., S}. b}, for the B-th subset S B (B=1,2,…,b), divide the feedback signal strength and signal verification detection rate, and obtain the priority of signal verification according to the division level of feedback signal strength;

[0125] The criteria for prioritizing feedback signals based on their strength are as follows:

[0126] 1) If an ACK, vendor signature, or error code is received, the case is classified as a strong positive.

[0127] 2) If an echo, garbled text, or electrical connection signal is received, it will be classified as a weak positive level;

[0128] 3) If the feedback signal reception fails continuously within the preset feedback reception time, it will be classified as neutral, and the number of attempts will gradually decrease as the handshake probe signal transmission time slot increases each time.

[0129] 4) If the feedback signal reception fails after exceeding the preset feedback reception time period, or if it is a newly added candidate handshake data combination, it will be classified as negative and will only be attempted occasionally.

[0130] In feedback signals, the ACK (acknowledgment signal) typically refers to an explicit confirmation response returned by the device. For example, in Modbus TCP and CAN protocols, when a PLC device receives a probe frame that matches the parameter combination, it returns an acknowledgment frame (ACK / response frame), indicating that the parameter combination is correct and the link and protocol have been successfully established. Therefore, this is classified as a strong positive feedback signal. Many PLCs or industrial devices return fixed identifiers during the handshake phase (i.e., the manufacturer's identifier can be the manufacturer ID, device model, or firmware version number). If the manufacturer's identifier is received during probing, the combination can be directly confirmed as highly reliable; therefore, this is classified as a strong positive signal. Error codes indicate that some PLC devices will still return the error response specified by the protocol when receiving illegal frames or incorrect parameters (e.g., the error code 0x83 in the Modbus TCP interface protocol). The error code indicates that both the physical layer and protocol decoding were successful, but the parameter combination was not completely matched. In this case, the interface and some parameters can be confirmed as correct; therefore, this is also a positive signal and is classified as a strong positive signal.

[0131] Echoing indicates that some devices, during serial communication, will return the received input as is. If the echoed content matches the sent frame, it indicates that the physical communication link is established, and the parameter combination may be correct; however, whether the protocol layer is correct needs further confirmation, therefore it is classified as a weak positive. A garbled feedback signal means that although the PLC or bus device received the probe frame, the returned data stream could not be parsed correctly due to inconsistencies in baud rate, parity bit, or frame format. Alternatively, overflow or bit sampling misalignment in the serial port or bus transmit / receive buffer can also cause garbled characters. The appearance of garbled characters at least indicates that physical layer connectivity is established (the line is passable), meaning the interface or channel is not completely invalid. However, due to incorrect protocol parameter configuration, reliable communication cannot be established above the data link layer. Therefore, it cannot be directly confirmed as a strong positive, but only as a weak positive, and is thus classified as a weak positive. Electrical connectivity signals refer to signals from the underlying hardware of an industrial interface (RS485, CAN, or Ethernet PHY) that are reflected when a link is established. These signals include voltage flips, differential level swings, and link pulses. Feedback signals are electrical connectivity signals that indicate that the interface is indeed connected to the device and the electrical link is normal. However, if the device does not return a frame that conforms to the protocol, it can only prove that the physical connection exists, but it cannot confirm that the parameters are correct or that the protocol handshake was successful. Therefore, it is classified as a weak positive level.

[0132] A strong positive feedback signal indicates that physical layer connectivity is established and protocol parsing is successful, but further verification is needed to confirm whether the parameters match completely. A weak positive feedback signal indicates that physical layer connectivity is established, but the protocol layer has not yet been established, or the feedback data cannot confirm that the parameters are correct.

[0133] In step 504, for each candidate handshake data combination in the B-th subset, a 4×4 probe signal transmission container matrix is ​​set according to the strength priority of the feedback signal and the preset handshake matching time. Vertically, four priorities are set according to the feedback signal priority, and each priority corresponds to a set of probe containers in the column direction. For each priority's set of probe containers, a set TW consisting of multiple transmission slots is divided according to the handshake matching time, TW = {TW1, TW2, TW3, TW4}; the β-th transmission slot is TW... β β = 1, 2, 3, 4; For the transmission time slot set TW, the fast handshake completion time slot is set as TW1, the medium handshake time slot as TW2, the long handshake time slot as TW3, and the ultra-long handshake time slot as TW4. That is, according to the duration, TW4 > TW3 > TW2 > TW1; For the probe container set, it can also be divided into four levels according to the duration of the transmission time slot.

[0134] Co α,B Co is the set of probe containers corresponding to the B-th subset with priority α; 1,B ={Co1,1,B Co 1,2,B Co 1,3,B Co 1,4,B};Co α,β,B This represents the probe container that is in the Bth subset with the αth priority and the βth transmission slot, where α = 1, 2, 3, 4; β = 1, 2, 3, 4;

[0135] Based on the strength and priority of the feedback signals, candidate handshake data from different feedback signals in the Bth subset are combined and placed in different probe container sets for verification of probe signal transmission.

[0136] In step 506, therefore, for multiple candidate handshake data combinations in the B-th subset, the Top-k method is used to select the top θ based on the strength of the initial feedback signal. B Each candidate handshake data combination is placed into the probe container set Co corresponding to the first priority. 1,B Inside, Figure 10 This diagram illustrates a scheduling mechanism where candidate handshake data combinations are progressively transferred and eliminated within probe containers of different priorities and transmission slots. If the first θ... B The number of candidate handshake data combinations exceeds the maximum total capacity C that the probe container corresponding to the first priority can send. 1,B For the detection container set Co 1,B Prioritize sending all combinations of priority 1 using the fast handshake time slot TW1. When the time window corresponding to TW1 ends and Co... 1,1,B If there are still unsent candidate combinations remaining in the container, they will be transferred to the Co of the first priority second transmission slot corresponding to TW2. 1,2,B Inside the container, a combination of probe signals is transmitted using the TW2 handshake time slot.

[0137] When the time window corresponding to TW2 ends and Co 1,2,B If there are still unsent candidate combinations remaining in the container, they will be transferred to the Co of the 1st priority 3rd transmission slot corresponding to TW3. 1,3,B Inside the container, a combination of probe signals is transmitted using the long-time handshake time slot TW3;

[0138] When the time window corresponding to TW3 ends and Co 1,3,B If there are still unsent candidate combinations remaining in the container, they will be moved up to the Co of the 4th transmission slot with the 1st priority corresponding to TW4. 1,4,B Inside the container, a combination of probe signals is transmitted in the longest time slot of TW4.

[0139] This forms the first priority probe container set Co, which is located within the green box in the first column of the diagram. 1,B Bottom-up based on detection time slot TW βContainers Co from shortest to longest 1,β,B Transfer mechanism: i.e. from Co 1,1,B (corresponding to TW1) → Co 1,2,B (corresponding to TW2) → Co 1,3,B (corresponding to TW3) → Co 1,4,B (Corresponding to TW4), combinations that are not scheduled by the end of each time slot will be automatically submitted to the container of the next higher time slot until the longest time slot ends.

[0140] This will exceed the maximum sendable capacity C. 1,B The remaining C 1,B -θ B Each candidate handshake data combination is placed in the probe container set Co corresponding to the second priority. 2,B Internally, for the top θ items appearing in the second row after ranking using the Top-k method... B The remaining Θ of the candidate handshake data combinations B -θ B Each candidate handshake data combination is then placed sequentially into the probe container set Co corresponding to priorities 2 through 4. 2,B To Co 4,B Inside, and:

[0141] It is placed first in the second priority container set Co 2,B In the middle, the remaining C 1,B -θ B The candidate handshake data combinations first enter the second priority to quickly complete the handshake time slot TW1 corresponding to Co. 2,1,B The container attempts to send in the fast handshake slot TW1; if there are still unscheduled combinations remaining when the TW1 slot ends, these combinations are transferred to the Co corresponding to the second priority handshake slot TW2. 2,2,B The container continues to transmit within the handshake time slot TW2; if there is still data remaining when the TW2 time slot ends, it is further transferred to Co. 2,3,B The long-time handshake time slot TW3 is used for transmission; if scheduling is not completed by the end of TW3, then it enters Co. 2,4,B Final scheduling is completed within the longest handshake slot TW4. Combinations that have not yet successfully completed the handshake within the 4th transmission slot of priority 2 are transferred to the container set Co of priority 3. 3,B Combined with the 4th priority detection signal, the container set Co is transmitted. 4,B Waiting for another poll (i.e., sending preset candidate handshake data combinations to unmatched PLC devices again for detection and matching).

[0142] In the third priority container set Co 3,B Combined with the 4th priority detection signal, the transmission container set Co 4,BSimilarly, it operates in a bottom-up, step-by-step transfer manner. Taking the third priority container set as an example, it transfers data that has not completed the handshake within the TW4 time slot corresponding to the second priority container to the container Co corresponding to the first transmission time slot of the third priority container. 3,1,B Within the TW1 transmission slot, attempt to transmit; if the handshake is not completed in TW1, transfer to the transmission container Co corresponding to the 2nd transmission slot of the 3rd priority container. 3,2,B If the handshake is not completed in TW2, transmission continues within the TW2 transmission slot; if the handshake is not completed in TW2, transmission is further transferred to the third priority container, the corresponding transmission container Co in the second transmission slot. 3,3,B If the transmission continues within the TW3 transmission slot, and is still not completed, it will enter the 4th priority container set and be placed in order from the shortest transmission slot TW1 to the longest transmission slot TW4, and probe transmission will be carried out in sequence.

[0143] Therefore, the container set corresponding to the yellow area also follows the scheduling mechanism of "priority-based, bottom-up, multi-slot progression". That is, the combination under each priority will first try quickly in a short time slot. If the handshake is not completed within the time slot of the time window, and a weak positive feedback is received, and the transmission time slot corresponding to the priority is not exceeded, the container Co will be sent. α,β,B The corresponding remaining amount that needs to be placed into the next level container exceeds the remaining amount threshold V. max,α,β,B Then, it is moved to the next level container Co as the remaining candidate handshake data combination. α′,β′,B Waiting for the handshake probe signal to be sent for the second scan; if the retry limit Cap has been reached. α,β,B If the target is still not hit, mark it with a red "×" in the current container Co. α,β,B If a neutral or negative feedback signal is received (invalid within the window, timeout), and there is still room for it to be moved up (the remaining amount does not exceed the remaining amount threshold V that needs to be placed in the next level container), it will be discarded. max,α,β,B And the next level container Co α′,β′,B Not frozen, i.e., TL α′,β′,B If the value is 0, then the handshake is allowed; otherwise, candidate handshake data combinations that have not completed the handshake within the time slot of this time window are marked with a red "×" and placed in the current container Co. α,β,B The data is discarded immediately. This decision is made by the ET module (Eligibility Test) in the gray area of ​​the diagram. The ET module is responsible for checking the yielding state (judging TL) of candidate handshake data combinations in each probe container of this priority. α,β,BThe system checks whether the handshake data combination is equal to 0, the real-time capacity and remaining capacity of the probe container, and the rate limit (i.e., whether the threshold is exceeded). Based on the feedback signal and corresponding conditions, it determines whether each candidate handshake data combination in each probe container can be transferred to the next level container to wait for the second scan of the handshake probe signal, whether it is discarded, or whether it can wait for the response frame verification. If the wait for the response frame verification is met, a "Yes" signal is given. If the transfer to the next level container to wait for the second scan of the handshake probe signal is met, it is moved up to the next transmission time slot container in the container set of this priority. If the handshake verification is not successful in the container of this priority, the ET module of this priority sends a "No" signal to the ET module of the next priority. The container set of the next priority continues to conduct handshake probe polling and verification from bottom to top until the container set of the last level has not been verified successfully, and the verification polling cutoff condition is reached. Then the polling terminates, and the remaining candidate combinations are marked with a blue "×" and are finally discarded.

[0144] The remaining candidate handshake data combinations that satisfy the transfer to the next level container are sequentially moved up to the longer time slot container until the longest time slot TW4 ends, or when the current level container is the probe container corresponding to the longest time slot of the priority, it is transferred to the probe container corresponding to the shortest transmission time slot of the next priority, thereby ensuring the hierarchical and phased probing of different priority candidate combinations under limited scheduling resources.

[0145] It should be noted that in some embodiments, Θ B Co is the total number of candidate handshake data combinations in the B-th subset obtained by method 400. α,β,B The probe container that transmits the probe signal combination in the Bth sub-focus of the α-priority β-transmission slot. α,B The maximum total transmittable capacity for the combination of probe signals sent to multiple probe containers of priority α for the B-th subset.

[0146] In step 508, the probe container Co of the B-th subset in the α-priority and β-transmission time slot is... α,β,B Configure the detection signal transmission rate R α,β .

[0147] That is, for any α and β, R satisfies α,β+1 ≤R α,β ;

[0148] The configuration of the probe signal transmission rate for the 16 probe containers consisting of 4 priorities and 4 transmission time slots forms the probe signal transmission rate matrix R:

[0149]

[0150] Rα,1 =min(BW α,1 G α,0 / TW1); G α,0 =C α,B -R α,4 TW4;

[0151] R α,2 =min(BW α,2 G α,1 / TW2); G α,1 =max(0,G α,0 -R α,1 TW1);

[0152] R α,3 =min(BW α,3 G α,2 / TW3); G α,2 =max(0,G α,1 -R α,2 TW2);

[0153] R α,4 =ρ α BW α,4 ;ρ α ∈[0,1],ρ α This is the guarantee factor for the minimum transmission rate of the probe container within the 4th transmission time slot. The element in the β-th row and α-th column of the R matrix is ​​R. α,β Specific R α,β The configured combined transmission rate of the detection signals is the element expression obtained by locating the row and column corresponding to the item in the detection signal transmission rate matrix R, where BW α,β The maximum transmission capacity of the probe signal combination per unit time for the probe container corresponding to the α-priority and β-transmission time slot is given in units of times / second.

[0154]

[0155] TW β For the βth transmission slot, different transmission slots have different durations. Therefore, with the maximum total transmittable capacity remaining unchanged, the maximum transmit rate achievable by the set of multiple probe containers of priority α for each column in the βth transmission slot is different. α,1 Allocate remaining capacity (i.e., the transmittable capacity of the set of containers of this priority remaining after transmission through the TW1 time slot) to the probe container of the α-priority 1st transmission slot, G α,2 Allocate remaining capacity to the probe container for the second transmit slot of priority α.

[0156] Therefore, the rule for the R matrix is ​​to prioritize ensuring the minimum transmission rate R of the priority within the 4th transmission slot. α,4 =ρ α BW α,4 Then, the transmission rates of the transmission slots TW1-TW3, corresponding to the priorities, are sequentially replenished from high priority (priority 1) to low priority (priority 3), that is, the remaining amount R of the guaranteed rate is replenished. α,4 TW4 can send a maximum total capacity C from this priority. α,B The initial remaining capacity G is obtained by removing from the middle. α,0 and set R α,1 Take BW α,1 With G α,0 The minimum value in the sequence is used as the transmission rate within that transmission slot of the corresponding priority. For G α,1 G α，0 -R α,1 TW1 is a combination of candidate handshake data R sent through TW1. α,1 After TW1, from the initial remaining capacity G α,0 After subtracting this portion, the remaining amount to be sent in TW2 is the amount that was already sent in TW1. α,0 -R α,1 If TW1 is fully used, there will be no more allocable space for subsequent windows. Therefore, the maximum value function max() is used to check 0 and G. α,0 -R α,1 The choice of the maximum value of TW1, for G α,2 They have similar meanings, which will not be elaborated upon here.

[0157] In the R matrix, the detection rate of different time slots corresponding to the same priority detection combination container in each column varies with TW. β The duration increased, BW α,β It is decreasing, therefore, BW in the fourth line. 1,4 BW 2,4 BW 3,4 and BW 4,4 This is the minimum probe signal transmission rate, or minimum probe signal transmission rate threshold, to ensure that negative-level candidate handshake data combinations that have failed to receive a correct or obvious feedback signal after multiple probe signal combinations are still sent for probing. This ensures that the data is still sent to the industrial scenario by the bridging gateway in the fourth transmission slot for PLC device matching attempts. These are used to support a final, tolerable transmission attempt for low-response candidate combinations that have failed multiple times but have not yet been ruled out, ensuring that the system has a certain degree of tolerance or worst-case probing capability.

[0158] BW in the third line 1,3 BW 2,3BW 3,3 and BW 4,3 All three times represent the maximum probe rate for each priority within the TW3 transmission slot. The third transmission slot (TW3) typically serves as a medium-delay compensation mechanism for candidate handshake data combinations that have experienced short-term probe failures (i.e., those failing to probe within the TW2 slot are transferred to the container within the corresponding TW3 slot to continue waiting to be transmitted for probing). This slot provides a more generous recovery opportunity for higher-priority candidate combinations that have not yet been fully verified. Its probe rate is higher than TW4, but slightly lower than the faster TW2 and TW1. It balances bandwidth efficiency and result conservatism, reflecting a delay recovery mechanism.

[0159] BW in the second line 1,2 BW 2,2 BW 3,2 and BW 4,2 These four elements represent the maximum transmission capacity per unit time for each priority probe container in the TW2 time slot. TW2 is configured as an intermediate time slot in the scheduling process and is the primary scheduling channel for most verified valid candidate combinations. Its configured rate is higher than TW3 and TW4, used to transmit probe signal combinations (i.e., candidate handshake data combinations) within each priority in the second transmission time slot TW2 (providing a longer time for transmitting probe signal combinations compared to quickly completing the handshake within the TW1 time slot). Therefore, the BW corresponding to the re-transmission of the probe signal combination can be completed within the second transmission time slot TW2. α,2 The element represents the core scheduling capabilities and bandwidth scheduling flexibility of containers of each priority level, and is used to cover combinations with positive feedback and a high probability of success.

[0160] BW in the first line 1,1 BW 2,1 BW 3,1 and BW 4,1 These four elements represent the highest combination capacity of probe signals that each priority probe container can support per unit time under the fastest probe time slot TW1. They are typically used to verify whether a candidate combination meets the high priority and most positive feedback criteria. Since TW1 has the shortest duration, BW... α,1 =C α,B / TW1 is also the highest, therefore these rates represent the combinations of probe signals that can quickly complete handshake verification within each scheduling priority. They ensure that combinations with a high probability of success receive scheduling resources first, quickly completing handshake identification and establishing the communication link.

[0161] In step 510, for the Bth sub-concentration, the detector container Co transmits the combination of detector signals in the α-priority β-transmission slot. α,β,B According to the transmission time slot TWβ The detection container Co is calculated within the βth transmission time slot. α,β,B Maximum detection capacity (Cap) of the combination of detection signals that can be transmitted α,β,B :

[0162] Cap α,β,B =R α,β ·TW β ;

[0163] In step 512, according to the priority-based, short-slot-to-long-slot transmission rules set in step 508, the candidate handshake data combinations in the B-th subset are preferentially placed in the transmission containers of high-priority short-slot transmission slots, thus constructing the optimal probe signal transmission container selection model (dpc) for the candidate handshake data combinations in the B subsets. B :

[0164]

[0165] The selection model is in The solution is performed under the given constraints, and the chosen model is defined as solving for the total detection capacity Cap. α,β,B The largest container Co α,β,B The container also needs to satisfy TL (Translation Lookahead) requirements. α,β,B =0,TL α,β,B =0 indicates that the container is not frozen. If the detection signal emitted from the container indicates that the remaining amount needs to be placed in the next level container, the remaining amount exceeds the remaining amount threshold V. max,α,β,B In such cases, the next-level container is frozen; for example, when the number V of unreviewed handshake-successful combinations remaining in the 4th time slot of the 2nd priority is... 2,4 It needs to be input to the 3rd priority 1st transmission slot to continue waiting for transmission, when V 2,4 The quantity is greater than the remaining quantity threshold V max,2,4 When that happens, the probe container Cap of the 3rd priority 1st transmission slot... 1,3,B The container is frozen during the next round of polling and verification probe signal transmission. Initially, all containers are not frozen during the first verification; TL is only dynamically changed after the first combination of verification probe signals is sent and feedback is received. α,β,B Simultaneously, dynamically change each element R in the R matrix of step 508. α,β The rate at which the probe signal combination is sent for the probe container must be updated before each round of scheduling to reflect which probe containers are frozen, which resources are released, and how the rate at which the probe signal combination is sent is updated; otherwise, the new round of container rate allocation will not have the timeliness of the current resource status.

[0166] Optimal detection signal transmission container selection model dpc B The selected container is the optimal container. Select the α * Priority β * Transmission slot The message was sent internally and successfully verified with the PLC device in the industrial scenario (i.e., it passed through the optimal container). The number of candidate handshake data combinations (the sent verification signal is recognized by the PLC device and a strong positive feedback signal is obtained) is

[0167]

[0168] In step 514, based on the optimal container Number of candidate handshake data combinations sent The number of combinations that yield strong positive feedback signals. like Then the delayed activation period of the next level container is updated to 0: TL α′,β′,B ←0,;If Update the delayed activation period of the next level container to include δ rounds: TL α′,β′,B ←TL α′,β′,B +δ, where δ is the next level container Co α′,β′,B Because of the previous container The number of delayed activation rounds caused by sending probe signals when the remaining quantity exceeds the remaining quantity threshold, for the parameter combination (α′, β′) of the next level container:

[0169]

[0170] For δ, δ = 1 or 2 indicates a delay of 1 or 2 rounds before thawing the next level container Co. α′,β′,B The left arrow (←) indicates an update assignment operation.

[0171] In step 516, if If all transmissions in this round are considered successful, and all candidate handshake data combinations currently scheduled have been verified, then the verification of the probe signals using steps 502-514 with the aforementioned 16 probe containers will end; if This indicates that there are still failed combinations in the currently scheduled combinations that have not completed the handshake matching. Therefore, for the remaining combinations that have not yet sent verification probes... The combination is transferred to the next level container Co. α′,β′,B Temporarily stored, awaiting the next level container Co α′,β′,B After thawing, Repeat steps 502-514 for each combination until the check polling cutoff condition is met; for the optimal container Number of candidate handshake data combinations sent The number N of combinations of all candidate handshake data in the B-th subset BIn other words, when At that time, steps 502-516 completed the transmission of verification probe signals and handshake matching for all candidate handshake data combinations in the B-th subset. At that time, it is necessary to... The remaining combinations and Each combination executes the complete steps 502-516 in batches, namely: evaluating the priority and rate matrix in batches, reselecting the optimal probe container and calculating the transmission combination capacity, continuing to probe and provide feedback until the verification polling termination condition is met.

[0172] Regarding the termination conditions for review polling, the system will determine that the review polling for a combination has ended and will not conduct further reviews when any of the following conditions are met: First, the number of polls reaches the preset upper limit, thus satisfying the termination condition for review polling and terminating the review polling to prevent excessive attempts; Second, for each combination of handshake probe signals sent within a container, its feedback confidence score is calculated. If the confidence score of the probe feedback is lower than the corresponding threshold, it indicates that the combination has no value for continued attempts; Third, all time slot containers under the current priority are in a frozen state, meaning that for all time slots of the current priority, the remaining backoff rounds are not less than the maximum threshold TL. max (That is, how many rounds of retesting opportunities are allowed after a combination of probes sent by a certain probe container fails consecutively or is yielded), TL max Configure according to the specific application scenario.

[0173] Figure 11 A comparative diagram showing the number of successful handshake combinations in four different transmission time slots (TW1, TW2, TW3, TW4) under different total load and low load node ratio conditions.

[0174] Figure 11 (a) shows the total number of successful handshake data combinations in the TW1-TW4 transmission slots for method 500 (red line) of the embodiments of this disclosure and the prior art sequential polling method (blue line) at different total system load levels (0.6, 0.8, 1.0, and 2.0). (The vertical axis represents the total number of successful handshake data combinations in the four transmission slots.) As the system load increases, the method maintains a high success rate in the TW1 and TW2 slots, while the number of successful handshakes for the sequential polling method decreases significantly with increasing load. Figure 11 (b) shows the number of successful handshakes per time slot for the proposed method and the sequential polling method at different levels of low-load node proportion (0.2, 0.4, 0.6, 0.8). As the proportion of low-load nodes increases, the proposed method can significantly improve the number of successful handshakes for low-load nodes in TW1 and TW2 time slots, while the sequential polling method hardly improves it.

[0175] Here, 1L / 4H, 2L / 3H, 3L / 2H, and 4L / 1H represent the ratio of low-load nodes (L) to high-load nodes (H) in the system. For example, 1L / 4H represents one low-load node and four high-load nodes. The values ​​of 0.6, 0.8, 1.0, and 2.0 in each low-load and high-load node combination indicate that the total bandwidth and communication capacity of the system in that low / high load combination are constrained at a load of 0.6 (i.e., 60% load). This load is not the CPU / IO load of the bridging gateway itself, but rather the communication load level of each PLC device during handshake detection. High-load nodes indicate frequent handshake attempts and high bandwidth requirements, while low-load nodes indicate sparse handshake attempts and low bandwidth requirements.

[0176] from Figure 11 (a) It can be seen that, in all the low / high load combinations, as the total load for communication with the PLC device gradually increases (0.6, 0.8, 1.0, 2.0), the total number of successful handshakes corresponding to the method 500 of this disclosure (represented by the red line) is always higher than the total number of successful handshakes corresponding to the sequential polling method (represented by the blue line). That is, the number of successful handshake combinations remains at a high level, while the sequential polling method decreases rapidly with increasing load, especially under high load conditions where it experiences severe collapse. This result shows that the method 500 of this disclosure has stronger anti-congestion capability in high load scenarios and does not cause a significant decrease in the total number of successful handshakes due to an increase in the total load level.

[0177] from Figure 11 (b) It can be seen that when the total system load is fixed at approximately 1.1, as the proportion of low-load nodes (0.2–0.8) increases, the total number of successful handshakes corresponding to Method 500 of this disclosure, represented by the red line, gradually increases, and the number of successful handshake combinations for low-load nodes is effectively improved; while the sequential polling method, represented by the blue line, remains almost unchanged and cannot compensate for low-load nodes. This result shows that Method 500 of this disclosure can dynamically release resources and achieve fair scheduling when the proportion of low-load nodes increases.

[0178] for Figure 11 (a) and Figure 11 (b) A longitudinal comparison, i.e., comparing the total number of handshakes for the same low / high load combination, such as comparing group A with 1L / 4H, also reveals that the method disclosed herein has a significantly higher number of successful handshake combinations than the sequential polling method. Figure 11 In (a), the total number of successful handshakes for each low / high load combination decreases only slowly with increasing load, while the sequential polling method decreases rapidly in the former; Figure 11In (b), the total number of successful handshakes for each low / high load combination increases significantly with the proportion; while the sequential polling method remains at a low level, with no significant fluctuations in each group. This indicates that the method 500 of this disclosure can maintain a stable handshake success rate under high load conditions, and can also flexibly adjust under low load node proportions, performing secondary scanning of the remaining transfer container in different transmission time slots of each priority and effectively compensating for the transmission of low-capacity probe containers.

[0179] In summary, the method 500 of this disclosure, through steps 502-516, combines priority partitioning, multi-slot container scheduling, and the gating mechanism of the ET module, not only ensures the efficiency and stability of the overall handshake detection process, but also significantly improves the fairness and availability of low-load nodes.

[0180] Taking a low / high load combination of 4L / 1H as an example, such as Figure 12 As shown in (a), under different total system load levels (0.6, 0.8, 1.0, 1.2), the total number of successful handshakes per unit time period decreases as the load increases. Specifically, when the load is 0.6, the total number of successful handshake combinations in the TW1-TW4 time slots is 11 (6 in TW1 time slot, 3 in TW2 time slot, 1.5 in TW3 time slot, and 0.6 in TW4 time slot). However, at a total load level of 1.2, the total number of successful handshakes decreases to approximately 8.7 (3.8 in TW1 time slot, 2.2 in TW2 time slot, 1.8 in TW3 time slot, and 0.9 in TW4 time slot). It can be seen that the number of successful handshakes in slot TW1 is the highest and most sensitive to load. As the total load level increases, the number of successful handshakes decreases from approximately 6 to approximately 3.8. Slot TW2 also shows a significant decrease, with the number of successful handshakes dropping from 3 to 2.2. Slot TW3 remains relatively stable or slightly increases. Slot TW4 shows a slight increase, indicating that under high load levels, the scheduling mechanism tends to supplement by using tail slots to maintain utilization. Overall, slots TW1 and TW2 consistently maintain a successful handshake rate exceeding 70% at all total load levels, demonstrating the effectiveness of the priority guarantee mechanism.

[0181] like Figure 12As shown in (b), under different low-load node ratios (0.2, 0.4, 0.6, 0.8), the total number of successful handshakes per unit time period increases significantly with the increase of the low-load ratio, showing an overall approximately linear growth. When the low-load node ratio is 0.2, the total number of successful handshakes is approximately 7.5 (3 in TW1 time slot, 2.2 in TW2 time slot, 1.3 in TW3 time slot, and 0.7 in TW4 time slot). When the low-load node ratio increases to 0.8, the total number of successful handshakes rises to approximately 11 (6 in TW1 time slot, 3.5 in TW2 time slot, 1.2 in TW3 time slot, and 0.7 in TW4 time slot). It can be seen that the number of successful handshakes in TW1 and TW2 time slots increases significantly with the low-load ratio, increasing from approximately 3 to 6 and from approximately 2.2 to 3.5, respectively; TW3 shows a slight decrease or remains flat, while TW4 is basically stable. At this point, the combined proportion of TW1 and TW2 can reach 85%–90%, indicating that the system's protection effect on high-priority time slots is more significant when the proportion of low-load nodes increases. The occurrence of decimal or non-integer values ​​in the number of successful handshakes is because the statistics are based on the average result of multiple nodes or multiple experimental runs, rather than the integer value of a single node / single experiment, thus potentially resulting in non-integer decimals. In the 10 experimental segments, a total of 15 successful handshakes occurred within a certain time slot, averaging 15 ÷ 10 = 1.5 per segment.

[0182] Combination Figure 12 (a) and Figure 12 The results in (b) show that the two exhibit regular differences under different regulatory dimensions. Figure 1 In the process, as the total system load gradually increased from 0.6 to 1.2, the total number of successful handshakes per unit time period decreased from approximately 11 to approximately 8.7, showing an overall decreasing trend; while Figure 2 In the above, as the proportion of low-load nodes increases from 0.2 to 0.8, the total number of successful handshakes increases from approximately 7.5 to approximately 11, showing an opposite growth trend. Further comparison reveals that at the same level of total successful handshakes (e.g., ... Figure 12 (a) The total load level is 0.6 and Figure 12 (b) When the proportion of low-to-medium load nodes is 0.8, the total number of successful handshakes is approximately 11. However, the distribution of successful handshakes differs: in the former case, TW3 is approximately 1.5 and TW4 is approximately 0.6, while in the latter case, TW3 is only approximately 1.1–1.2 and TW4 is approximately 0.7. This indicates that reducing the total load is beneficial for improving the performance of low-to-medium priority time slots, while "increasing the proportion of low-load nodes" tends to focus on ensuring the performance of high-priority time slots TW1 and TW2. Furthermore, from a sensitivity perspective… Figure 1 The TW1 was most sensitive to changes in total load (the number of successful handshakes decreased from approximately 6 to approximately 3.8), while Figure 2TW1 and TW2 are most sensitive to the low load ratio (the number of successful handshakes increased from about 3 and 2.2 to about 6 and 3.5, respectively). Whether reducing the total load or increasing the low load ratio, the total contribution of TW1 and TW2 has always remained between 70% and 90%, demonstrating the scheduling strategy's ability to stably guarantee high-priority time slots under different operating conditions.

[0183] Figure 13 A flowchart of a method 600 for performing a secondary scan of interfaces that have partially abnormal responses but have physical connections, according to an embodiment of the present disclosure, is shown.

[0184] In step 602, a response frame of the feedback signal after the combined detection signals are sent is received. Where e represents the e-th handshake attempt. Represents the nth element in the Bth subset. f Feedback signal response frames for candidate handshake data combinations; for the received response frames Perform the corresponding verification calculation on the response frame;

[0185] Perform CRC16 check to determine whether the response frame of the feedback signal is a feasible candidate handshake data combination of RS485 interface type; perform CRC32 check to determine whether the response frame of the feedback signal is a feasible candidate handshake data combination of Ethernet interface type; and perform CRC15 check to determine whether the response frame of the feedback signal is a feasible candidate handshake data combination of CAN interface type.

[0186] The CRC16 checksum formula is: Determine CRC calc,16 Is it equal to CRC? recv , If they are equal, the verification is successful; if they are not equal, the verification fails. For response frames The total length in bytes.

[0187] Figure 14A (a) Figure 14A (b) shows the bit changes in the response frame for successful and unsuccessful verification of candidate handshake data combinations for RS485 interface types. That is, CRC16 verification is used to determine the CRC16 checksum of the receiver. calc,16 Is it equal to the nth term in the B-th subset sent by the sender? f Candidate handshake data combinations CRC check value recv ;CRC16() is the standard Modbus CRC16 check function (usually polynomial 0xA001); This means that the frame data has the last two bytes removed (i.e., the CRC16 checksum bits, i.e., removed). Figure 14A The part of the check field corresponding to the bits in the gray area; Indicates the response frame obtained Extract the last two bytes (in hexadecimal), that is, from position... to No. byte and first The bytes are CRC checksums attached by the sender; for example, in a received response frame. There are a total of 8 bytes, then forward The first six bytes, [0x01, 0x03, 0x02, 0x00, 0x0A], are discarded when calculating the CRC checksum at the sending end. The last two bytes [0xC5, 0xCD] are then used as the final CRC checksum. It refers to the CRC value sent by the sending end, and the calculated CRC16 checksum of the receiving end. calc,16 If the value is 0xC5CD, then the verification is successful.

[0188] The CRC32 check formula is: Determine FCS calc,32 Is it equal to FCS? recv , If they are equal, the verification succeeds; if they are not equal, the verification fails. (FCS) recv For the sending end to the nth element in the Bth subset f Candidate handshake data combinations CRC check value, FCS calc,32 This is the CRC32 checksum value for the receiving end.

[0189] This indicates the calculation of the last 4 bytes of the received Ethernet frame, the CRC32 checksum calculated and attached by the sender, and the response frame received. Extract the FCS checksum value attached by the sender from the last 4 bytes. Figure 14B (a) Figure 14B (b) shows the bit changes of the response frame for successful and unsuccessful verification of candidate handshake data combinations for Ethernet interface types. Figure 14B (a) The experimental data related to the verification results shown are the FCS calculated by the receiver based on the MAC, IP, and Payload fields. calc,32 =0x5A3C9F20, while the CRC checksum (FCS) of the last 4 bytes of the Ethernet frame sent by the sending end is 0x5A3C9F20. recv=0x5A3C9F20, the two are equal, therefore the verification is successful. Figure 14B (b) The CRC checksum (FCS) of the last 4 bytes of the Ethernet frame sent by the transmitting end, as shown in the relevant experimental data of the verification results. recv =0x7D8E1234, at this time the receiver calculates the CRC32 checksum FCS. calc,32 (0x5A3C9F20) is not equal to the checksum FCS sent by the sender. recv (0x7D8E1234), therefore the verification failed.

[0190] For CRC15 verification using the CAN interface, the textual description of the CAN frame field verification is as follows: During Controller Area Network (CAN) communication, each frame contains several key fields. Each key field is used to uniquely identify the message content and ensure the correctness of data transmission. The CAN data frame structure generally includes:

[0191] The frame field (ID) is used to identify the message's priority and the sending node;

[0192] Data Length Code (DLC): Indicates the number of bytes in the valid data segment (Payload); the valid data segment is also the data payload;

[0193] Payload field: Carries the actual data being transmitted; its length is determined by the Data Length Code (DLC).

[0194] Cyclic Redundancy Check (CRC) field: usually a 15-bit CRC check value (with an additional 1-bit delimiter added on top of the 15-bit CRC check value), used to detect whether errors occur in the message during transmission;

[0195] The ACK delimiter field and the Error Frame Delimiter (EOF) field: These indicate received acknowledgment and end of frame, respectively, and are not involved in content verification. Therefore, the CRC15 verification process generally includes the following steps:

[0196] 1) Record the currently received CAN message as It contains the following fields:

[0197] in, For data load fields;

[0198] 2) Read the frame field from the received message. Data length code and data load field As a field for calculating cyclic redundancy check Input data.

[0199] 3) Recalculate the CRC using the CRC15 polynomial G(x) specified in the standard CAN protocol. and The three fields are concatenated and then subjected to polynomial division to obtain a new check value, denoted as CRC. calc,15 .

[0200] For example It is 10110010101 (11 bits). 1000 (4 digits) The given values ​​are 0110010111110000 (2 bytes), which, when concatenated, result in a long bit string (binary): 1011001010110000110010111110000

[0202] For this long binary bit string (31 bits in total), each digit is used from right to left as the coefficient of the corresponding power (30th power in total) for message polynomial calculation: M(x) = x 30 +0·x 29 +x 28 +x 27 +…+x 4 +x 1 That is, M(x) = x 30 +x 28 +x 27 +x 24 +x 21 +x 15 +x 12 +x 11 +x 10 +x 9 +x 7 +x 5 +x 4 +x 1 The message bit string is shifted left by 15 bits (since the length of the CRC15 checksum is 15), which means appending 15 zeros to the end of the binary string obtained from the message polynomial calculation. Then, a modulo-2 division operation (i.e., binary division without carry, or XOR operation) is performed on the left-shifted message polynomial using the specified CRC15 polynomial G(x). The remainder obtained is the calculated CRC value. calc,15 In general, G(x) = x 15 +x 14 +x 10 +x 8 +x 7 +x 4 +x 3 +1; x in G(x) and M(x) is a formal variable representing bit shift.

[0203] 4) Compare the results: Compare the calculated CRC values. calc,15 The CRC field included in the message Comparison:

[0204] If the two are equal (i.e.) This indicates that no errors were detected during the transmission of the message, and the frame is determined to be a valid frame.

[0205] If the two are not equal (i.e. This indicates that an error may have occurred during the transmission of the message. The frame is determined to be invalid and needs to be discarded or retransmitted.

[0206] If the CRC check is successful, it indicates that the response frame is valid, further demonstrating that the interface combination being tested is a feasible candidate handshake combination. If the CRC check fails, it indicates that the response frame parameter combination is configured incorrectly. An incorrect response frame parameter combination configuration will cause the feedback message to be unrecognizable, which means that the set candidate handshake data combination is incorrect (in some embodiments, it means that the candidate handshake data combination set by method 400 in step 402 is incorrect), and is an infeasible candidate handshake data combination. Therefore, the candidate handshake data combination that failed the check needs to be discarded.

[0207] Figure 14C (a) Figure 14C (b) shows the bit changes of the response frame for successful and unsuccessful verification of candidate handshake data combinations for CAN interface type. Figure 14C (a) The message fields of the CAN interface related to the verification result shown are ID=0x1AC, DLC=8, Payload=0x65F0; the CRC15 checksum calculated by the receiving end based on the message fields is CRC. calc,15 =0x2D9C; The CRC checksum sent by the sending end and the CRC15 checksum sent by the sending end. Therefore, the CRC15 check was successful. Figure 14C (b) The CRC check value sent by the sending end in the relevant experimental data of the verification results shown. At this time, the receiver calculates the CRC15 checksum. calc,15 It is not equal to (0x3A4F), therefore the verification failed.

[0208] It should be noted that the CRC16 checksum field is 16 bits long (2 bytes), the CRC32 checksum field is 32 bits long (4 bytes), and the CRC15 checksum field is 15 bits long plus a 1-bit delimiter, which is generally considered to be 16 bits in equivalent length. Figure 14A , Figure 14B and Figure 14C The CRC checksum fields appear to be the same length in the diagrams because each sub-graph normalizes the range of the horizontal axis during plotting. The gray areas are logical "checksum" placeholders; they simply indicate "this is the CRC field," rather than being drawn strictly according to the actual protocol bit length ratio. Therefore, in the RS-485, Ethernet, and CAN sub-graphs, the gray areas marking the CRC checksum fields appear to be the same length, but actually represent different numbers of bits. The reason they are drawn as appearing to be the same length in the diagrams is to facilitate comparison of the logical differences in CRC checksum verification between successful and unsuccessful checks for the three protocols, rather than representing a strict bit length scale.

[0209] In step 604, the verified response frame is... Parsing as fields

[0210]

[0211] For the nth element in the Bth subset f The response frame obtained and verified after the e-th transmission of the candidate handshake data combination. The parsed device address field; The function code field indicates the function code of this response frame. For example, Modbus read holding register (0x03), write single coil (0x05), etc. In CANopen or DeviceNet, the function code may be mapped to the device address field. High bit or load field middle. The payload field contains the actual data content carried in the response message, which may include PLC memory register values, status bytes, error codes, etc. The CRC calculated in step 602 is used for verification. calc,16 or FCS calc,32 Specifically, each interface type corresponds to a different interface.

[0212] For RS485 interface type Preset legal address range The value is [1,247]. Set of valid function code fields The standard ID is typically {01, 03, 05, 10}. For CAN interface types, the standard frame (11-bit ID) is... The value is [0x000, 0x7FF] (in hexadecimal), and [0, 2047] in decimal; the extended frame (29-bit ID) The value is [0x00000000,0x1FFFFFFF] (in hexadecimal), and [0,536870911] in decimal. This is the DeviceNet protocol type. [0, 63], CANopen protocol type For [1,127], the set of valid function code fields in CANopen is generally {PDO,SDO}. The DeviceNet function code set can be understood as the set of explicit message service codes (common commands in the range of 0x01–0x4F) + the set of I / O message types (Poll,COS,Cyclic,Strobe); where the set of I / O message types is equivalent to the function codes for real-time communication, and the set of explicit message service codes is equivalent to the function codes for configuration / diagnosis.

[0213] The PLC device activity value is determined based on whether each variable in the parsed field is within its respective valid range.

[0214]

[0215] Wherein, ∧ indicates that both conditions are met simultaneously, and the validation field matches. This indicates that the validated response frame simultaneously meets the requirements. Parsed fields The check fields of each independent variable in the code match (e.g., CRC). calc,16 =CRC recv Meanwhile, the address fields of each independent variable exist within their legal range, and the function code fields of each independent variable exist within the corresponding set of legal function code fields.

[0216] This indicates that the response frame is valid, and that the PLC device sending the feedback signal back to the bridging gateway is active and the communication parameters are correct.

[0217] This indicates that the response frame is invalid, that the feedback signal sent back to the bridging gateway may be a bit error, or that the PLC device sending the feedback signal back to the bridging gateway is not responding or has a protocol mismatch. Therefore, this candidate data combination should be discarded.

[0218] Figure 15 A flowchart of a method 700 for generating a driver binding policy within a bridging gateway based on the matching result and invoking a driver binding module to establish a data communication session with the PLC device, according to an embodiment of the present disclosure, is shown.

[0219] In some embodiments, the step of generating a driver binding strategy and invoking the corresponding driver binding module includes: First, the bridging gateway receives a message returned from the PLC device, and determines the communication protocol type used by the PLC device by parsing the protocol feature fields in the message, such as the function code, device address (Addr), and protocol type identifier in the message header. Based on this parsing result, the bridging gateway can clearly determine whether the device uses standard industrial communication protocols such as Modbus, CANopen, DeviceNet, or Ethernet / IP, thereby avoiding the complex process of manual configuration.

[0220] In other embodiments, after determining the communication protocol type, the bridging gateway will automatically retrieve the corresponding driver binding submodule from the driver binding module library and load the driver binding submodule upon successful retrieval. For example, when the PLC device message feature field conforms to the Modbus TCP protocol, the system will automatically call the Modbus TCP driver binding submodule; if the feature field conforms to the CAN bus protocol, the CAN bus driver binding submodule will be called to achieve protocol layer compatibility and adaptation.

[0221] In some embodiments, when the driver binding module is invoked, the session management unit of the bridging gateway assigns it a unique session ID. This session ID serves as a unique index in subsequent data transmission, enabling the system to accurately distinguish the communication context of each PLC device when multiple devices access it concurrently, thereby ensuring that communication between different PLC devices is not confused.

[0222] In other embodiments, based on an assigned session identifier, the bridging gateway establishes an independent data communication channel with the target PLC device. This channel supports periodic data acquisition, real-time status monitoring, and parameter distribution, and maintains consistency with the data format of the cloud-based IoT system. For example, in one embodiment, the established data communication channel not only supports standard register read / write operations but also extended exception code reporting and multi-session parallel multiplexing functions, thereby improving the system's flexibility and scalability.

[0223] Figure 16 A flowchart of a method 800 for dynamically binding successfully matched communication parameters to a drive module, generating a session identifier for the target PLC device, and updating a session routing table according to an embodiment of the present disclosure is shown.

[0224] In step 802, the bridging gateway performs dynamic consistency verification on the bound communication parameters based on the real-time monitoring results of the session routing table. Figure 17This illustrates an example where, upon detecting a change in communication parameters, the session routing table is updated from its initial state to the new session identifier parameters via an unbinding and rebinding process. For example... Figure 17 As shown, before the routing table is updated, the communication parameters of PLC#1 with Session ID=1001 are "Start=1,Data=8,Parity=None,Stop=1", and the status is "Established"; the parameters of PLC#2 with Session ID=1002 are "ID=0x1AC,DLC=8,CRC=0x3F2A", and the status is "Established"; the parameters of PLC#3 with Session ID=1003 are "Port=502,FC=03,Length=10", and the status is "Pending Verification". At this time, the system performs a consistency check on the above parameters and the parsed protocol fields to confirm that the communication link remains correct.

[0225] In step 804, when a change in communication parameters is detected, the driver module is triggered to automatically unbind and rebind. For example... Figure 17 As shown in the intermediate stage, the serial port parity bit of PLC#1 changes from "Parity=None" to "Parity=Odd", and its status is marked as "Delayed Release"; simultaneously, the CRC checksum value of PLC#2 changes from "0x3F2A" to "0x2D9C", and its status switches to "Pending Verification"; the parameters of PLC#3 are confirmed to be correct and updated to "Established". During this stage, the bridging gateway automatically performs driver unbinding and rebinding operations for PLC#1 and PLC#2 to ensure uninterrupted communication.

[0226] In step 806, according to a preset priority update strategy, the new session identifier is written into the session routing table, and the old identifier is marked as a delayed release state. For example... Figure 17 As shown at the bottom, PLC#1 completes parameter rebinding, and its new parameters "Start=1,Data=8,Parity=Odd,Stop=1" are written into the routing table and remarked as "Established"; PLC#2's new parameters "ID=0x1AC,DLC=8,CRC=0x2D9C" are written into the routing table, and its old session identifier remains in the "delayed release" state; PLC#3 continues to remain "Established". Through this priority update mechanism, the routing table gradually replaces session identifiers during the update process, thereby ensuring uninterrupted communication and maintaining overall stability, thus guaranteeing the stability and correctness of communication when multiple PLC devices are connected simultaneously.

[0227] Figure 18A block diagram of an example device 1100 for automatic identification of PLC-bridging gateway IoT according to an exemplary embodiment of this application is shown. For example, in the embodiment shown above, the device may be a bridging gateway deployed in an industrial field, connected to multiple PLC device sensor modules 120 (which may consist of multiple and / or one sensor from multiple PLC devices, or multiple sensors from a single PLC device), and remotely communicate and interact with data through a cloud data center 110. In some embodiments, data collected in real time by the multiple PLC device sensor modules 120 is received through a communication interface module in the PLC-bridging gateway IoT automatic identification system 101. In some embodiments, the device 1100 is provided with multiple communication interfaces, and the driver binding module includes driver binding sub-modules for different communication interface types, used to generate driver binding strategies. The communication interfaces include one or more of RS485 interface, RS232 interface, CAN bus interface, and Ethernet interface; the communication interfaces support one or more of the following communication protocols: Modbus TCP, Modbus RTU, Siemens S7, Omron-FINS, Mitsubishi FX / Q, DeviceNet, and CANopen.

[0228] like Figure 18 As shown, the example device 1100 may include at least one processor 1102 and at least one memory 1104. The memory 1104 may store instructions that, when executed by the at least one processor 1102, cause the device 1100 to perform at least the steps in the PLC-bridging gateway IoT automatic identification method, such as methods 200, 300, 400, 500, 600, 700, and 800. These include communication interface scanning, protocol feature matching, driver binding, data formatting, routing table updating, and IoT data uploading.

[0229] In some example embodiments, the processor 1102 in device 1100 may include, but is not limited to, an industrial control processor implemented with a central processing unit (CPU), microcontroller unit (MCU), digital signal processor (DSP), field-programmable gate array (FPGA), or application-specific integrated circuit (ASIC). The processor 1102 may be a general-purpose processor or a dedicated hardware logic unit designed for industrial protocol identification and IoT data forwarding optimization. In some embodiments, the processor 1102 may also include components not included in... Figure 18 Other circuits or components shown in the diagram.

[0230] In some example embodiments, the memory 1104 of device 1100 may include various forms of storage media. Methods 200, 300, 400, 500, 600, 700, and 800 may be implemented as computer software programs and tangibly contained within various forms of storage media in memory 1104. These storage media include transient and non-transient memory. Transient memory may be random access memory (RAM), cache, etc., used to cache real-time data from multiple PLC devices during handshake identification and response message verification. Non-transient memory may include read-only memory (ROM), flash memory, or hard disk, used to store protocol feature databases, drive binding strategies, and long-term communication parameter configurations. In this application, "non-transient" refers to a tangible storage medium, not the signal itself.

[0231] In addition, in some embodiments, the example device 1100 may also include at least one interface circuit or other element, such as a wired / wireless I / O interface, an Ethernet interface, a LoRa interface, or a communication module with MQTT, HTTP, or CoAP protocols, to support interconnection with external PLC devices and cloud data center 110.

[0232] In various example embodiments, the circuits, components and interfaces of device 1100, including processor 1102 and memory 1104, can be coupled to each other through buses, wiring or wireless links, thereby realizing automatic identification of multiple interfaces and protocols and IoT bridging functions, ensuring that industrial field data can be reliably and efficiently transmitted to host computers, remote monitoring centers or cloud platforms.

[0233] Furthermore, although the operations are described in a specific order, this should be understood as requiring that such operations be performed in the specific order shown or in sequential order, or requiring that all illustrated operations be performed to achieve the desired result. In certain environments, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented individually or in any suitable sub-combination in multiple implementations.

[0234] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. PLC-bridging gateway IoT automatic identification method, including the following steps: Connect the bridging gateway to the industrial site, send handshake detection signals to multiple PLC devices in the industrial site in sequence, and receive the response messages returned by the PLC devices. By matching the protocol feature database, a driver binding strategy is automatically generated to identify the communication protocol and physical interface used by the PLC device. The response message is then verified and parsed, and the activity status and communication parameters of the PLC device are confirmed based on the parsing results. Based on the matching results, a driver binding strategy is generated inside the bridging gateway, and the driver binding module is called to establish a data communication session with the PLC device. The industrial data collected by the PLC device is uniformly formatted and cached, and then translated into data packets of the Internet of Things communication protocol. The successfully matched communication parameters are dynamically bound to the drive module to generate a session identifier for the target PLC device and update the session routing table in the bridging gateway. The standardized industrial data is uploaded to the cloud data center, enabling bridging communication between PLC devices and IoT systems.

2. The method as described in claim 1, characterized in that, The steps of sequentially sending handshake detection signals to multiple PLC devices in the industrial field and receiving response messages returned by the PLC devices include: Based on the preset communication template, the probe parameter combination for each interface is automatically configured, and the interface type parameter and probe parameter combination are used as candidate handshake data combinations to form multiple candidate handshake data combination sets. A priority algorithm is used to select the most likely successful combination for testing in order to improve recognition efficiency; An adaptive polling mechanism is used to perform a secondary scan on some interfaces that have abnormal responses but still have physical connections, in order to improve the identification coverage.

3. The method as described in claim 2, characterized in that, The steps for forming a candidate handshake data combination set based on a preset communication template include: Based on the automatically adapted PLC communication protocol, a set of interface types and a set of protocol detection parameters are generated, which in turn form a set of candidate handshake data combinations. The attribute fields of the candidate handshake data combination are concatenated into a string and input into a stable hash function to obtain the corresponding hash value; Modulo operation is performed based on the hash value to determine the subset number to which the candidate handshake data combination belongs.

4. The method as described in claim 2, characterized in that, The steps of selecting the most likely successful combination using a priority algorithm and performing a secondary scan on interfaces with abnormal responses but existing physical connections using an adaptive polling mechanism include: Candidate handshake data combinations are prioritized based on different characteristics of the feedback signals; Set multi-stage transmission timing and scheduling conditions for candidate combinations of each priority level; Candidate combinations are initially screened within the priority range and then deployed in sequence according to a predetermined order. Dynamically configure sending resources and rates for different priority and duration phases; Calculate the transmission capacity that each stage can support to ensure the rationality of scheduling; Select the scheduling phase that can achieve the maximum effective transmission capacity for combined transmission; The scheduling strategy for subsequent stages is dynamically updated based on the actual success of the handshake. If there are incomplete handshake matchings, the remaining combinations are submitted to subsequent stages for repeated scheduling until the termination condition is met.

5. The method as described in claim 2, characterized in that, The step of using an adaptive polling mechanism to perform a secondary scan of interfaces that have abnormal responses but exist with physical connections also includes: Polling probes are performed on the set of candidate communication parameter combinations for the interface, and each probe response frame is captured; Each response frame is subjected to CRC check. If the check is successful, its device station number, function code and response content are further parsed. If the station number and function code are valid and the response content is correct, the candidate handshake data combination is marked as a successful communication.

6. The method as described in claim 1, characterized in that, The steps of generating a driver binding strategy within the bridging gateway based on the matching result and calling the driver binding module to establish a data communication session with the PLC device include: The communication protocol type of the PLC device is determined based on the protocol feature field returned by the PLC device; Select the corresponding driver binding module from the driver binding module library according to the communication protocol type; Invoke the driver binding module and assign it a unique session identifier; A data communication channel with the PLC device is established based on the session identifier.

7. The method as described in claim 1, characterized in that, The steps of dynamically binding the successfully matched communication parameters to the drive module, generating the session identifier of the target PLC device, and updating the session routing table include: Based on the real-time monitoring results of the session routing table, perform dynamic consistency checks on the bound communication parameters; When a change in communication parameters is detected, the driver module is triggered to automatically unbind and rebind. According to the preset priority update strategy, the new session identifier is written into the session routing table, and the old identifier is marked as a delayed release state.

8. A PLC-bridging gateway IoT automatic identification system, characterized in that, The system includes a communication interface module, a protocol feature matching and message verification module, multiple driver binding modules, a data formatting module, a routing table update module, and an IoT interface module. The communication interface module is used to sequentially send handshake detection signals to multiple PLC devices in the industrial field and receive response messages returned by the PLC devices. The protocol feature matching and message verification module is used to match the response message with the protocol feature database to identify the communication protocol and physical interface used by the PLC device, and to verify and parse the response message to confirm the activity status and communication parameters of the PLC device. The drive binding module is used to generate a drive binding strategy within the bridging gateway based on the matching result, and call the corresponding drive module to establish a data communication session with the PLC device. The data formatting module is used to uniformly format and cache the industrial data collected by the PLC device, and translate it into data packets of the Internet of Things communication protocol. The routing table update module is used to dynamically bind the successfully matched communication parameters to the drive module, generate the session identifier of the target PLC device, and update the session routing table in the bridging gateway. The IoT interface module is used to upload the uniformly formatted industrial data to the cloud data center to achieve bridging communication between the PLC device and the IoT system.

9. A PLC-bridging gateway IoT automatic identification device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the method as described in any one of claims 1-7.

Images