Multi-protocol communication conversion module and communication method of intelligent safety guardrail

Abstract

The invention relates to a multi-protocol communication conversion module and a communication method of an intelligent safety fence, and belongs to the technical field of communication protocols. The multi-protocol communication conversion module comprises the following steps: step 1, performing protocol type identification on various protocol heterogeneous devices in the intelligent safety fence; step 2, constructing a data analysis rule base of the protocol according to the identified protocol type; 3, analyzing the data according to a data analysis rule base of the protocol, and converting the analyzed data into a uniform data format so as to facilitate data interaction among the heterogeneous devices; 4, performing protocol packaging on the data converted into the uniform format according to a protocol type supported by the target protocol heterogeneous equipment and a pre-constructed protocol mapping table; step 5, sending the packaged data to the target protocol heterogeneous device, and realizing interconnection and intercommunication among the protocol heterogeneous devices in the intelligent safety guardrail; the method has the beneficial effects that the analyzed data is converted into a uniform data format, and interconnection among protocol heterogeneous devices is realized.

Description

Technical Field

[0001] The present invention belongs to the technical field of communication protocols, and in particular relates to a multi-protocol communication conversion module and a communication method for an intelligent safety guardrail. Background Art

[0002] With the rapid development of intelligent transportation systems and urban infrastructure, the intelligent upgrade of safety guardrails, as crucial protective features on roads, bridges, and construction sites, has become an industry trend. Traditional safety guardrails rely primarily on mechanical structures for their protective functions, lacking real-time monitoring, remote control, and data exchange capabilities. Modern intelligent safety guardrails, by integrating sensors, communication modules, and data processing units, enable real-time monitoring of guardrail status (such as tilt, impact, and displacement) and collaborate with other intelligent devices (such as traffic lights, monitoring systems, and cloud platforms) to improve safety management efficiency.

[0003] However, the current communication technology of smart safety guardrails faces the following challenges: protocol heterogeneity: different sensors, controllers and cloud platforms usually use different communication protocols (such as Modbus, CAN, ZigBee, LoRa and MQTT, etc.), which makes interconnection between heterogeneous devices difficult and the system integration is highly complex.

[0004] Therefore, there is an urgent need for a multi-protocol communication conversion module and communication method dedicated to intelligent safety guardrails to achieve efficient interconnection between heterogeneous devices. Summary of the Invention

[0005] The present invention provides a multi-protocol communication conversion module and communication method for an intelligent safety guardrail, which is used to solve the technical problem of difficulty in interconnection and intercommunication between heterogeneous devices of various protocols in an intelligent safety guardrail. The module converts the parsed data into a unified data format to facilitate data interaction between heterogeneous devices, and realizes interconnection and intercommunication between heterogeneous devices of various protocols through a unified data format.

[0006] In order to achieve the above object, the present invention is implemented by the following technical solutions: The communication method of the multi-protocol communication conversion module of the intelligent safety guardrail includes the following steps: Step 1: Identify the protocol types of various protocol heterogeneous devices in the smart safety fence. Protocol heterogeneous devices include at least TCP / IP-based devices, MQTT-based devices, CoAP-based devices, and Zigbee-based devices. Step 2: Based on the identified protocol type, a protocol data parsing rule base is constructed. The protocol data parsing rule base includes data frame format parsing rules, data field meaning parsing rules, and data transmission timing parsing rules for different protocols. In the process of constructing the protocol data parsing rule base, hot plugging of protocols is supported to dynamically load or unload the protocol data parsing rule base, facilitating the access requirements of heterogeneous devices with different protocols. Step 3: Receive data sent by various heterogeneous devices, parse the data according to the protocol's data parsing rule base, and convert the parsed data into a unified data format to facilitate data interaction between various heterogeneous devices. The unified data format includes a specified data structure and a specified data encoding method; Step 4: The data converted into a unified format is encapsulated according to the protocol types supported by the target protocol heterogeneous devices based on a pre-built protocol mapping table; the protocol mapping table records the mapping relationship between different source protocols and target protocols; Step 5: Send the encapsulated data to the target protocol heterogeneous device to achieve interconnection and intercommunication between the protocol heterogeneous devices in the intelligent safety fence.

[0007] Optionally, in step one, TCP / IP-based devices are identified based on transport layer features, MQTT-based devices are identified based on application layer protocol features, CoAP-based devices are identified based on application layer protocol features, and Zigbee-based devices are identified based on physical layer and MAC layer features.

[0008] Optionally, in step 2, a data parsing rule base for the protocol is constructed based on the identified protocol type, including the following steps: Step 1: Construct data frame format parsing rules, which include frame structure analysis, field segmentation rules definition, and verification mechanism definition. Step 2: Construct data field meaning parsing rules; this includes field semantics definition, value mapping rules, and unit conversion rules. Step 3: Construct data transmission timing analysis rules; define message sequence, configure timing parameters, and define exception handling rules.

[0009] Optionally, in step 2, a directed graph topology sort is used for protocol hot plugging, specifically: given a dependency directed graph ,in, is a set of rule bases, The dependency edge is express rely , the necessary and sufficient condition for the existence of topological sorting of a directed graph is that there is no cycle in the graph.

[0010] Optional, the algorithm steps for topological sorting of directed graphs are: Step a: Calculate the in-degree of each node; Step b: Add the node with in-degree 0 to the queue; Step c: Take out the nodes one by one, reduce the in-degree of the neighboring nodes of the taken node, and add them to the queue if the in-degree becomes 0; Step d: If the number of nodes finally processed is equal to the total number of nodes, there is no cycle and a topological order exists; otherwise, there is a cycle.

[0011] Optionally, in step three, the data is parsed using the following steps: Step A: Device identification; Step B: Determine the protocol type; Step C: rule base call; Step D: data parsing and execution; Step E: Unify data model definition; Step F: protocol data mapping; Step G: Data validity check; Step H: Standardize data output.

[0012] Optionally, in step E, the parsed data is converted into a unified data format in the following manner: For multidimensional data, hierarchical processing is required: Single layer data: ;in, Original heterogeneous data, which is the original data from different devices / systems; Standardized data is converted into a unified format and can be universally parsed and interacted with by multiple devices / systems. A key-value pair is the basic unit of data: "field name-field value"; For the field mapping function, the original field name Convert to standard name; For type conversion function, the original value Convert to standard type; For traversal and reconstruction, they are processed one by one The key-value pairs in the map are and the converted Reassemble ; Multidimensional data: ;in, It is a nested data conversion function that recursively / hierarchically processes complex nested values ​​to ensure that deep data can also be standardized; For traversal and reconstruction, they are processed one by one Key-value pairs, using the original field name and the converted value Reorganized into .

[0013] Optionally, in step 4, the protocol mapping and data encapsulation are: The protocol mapping table is constructed using a dual-mode approach: basic mapping and dynamic learning. The basic mapping is pre-defined based on common protocol conversion scenarios, covering data field reorganization and protocol header adaptation rules. The dynamic learning module uses machine learning algorithms to analyze historical data conversion records and automatically identify conversion rules under new protocol combinations. During the encapsulation process, differentiated processing is performed based on the transmission characteristics of different protocols; To meet the concurrent data conversion needs of multiple devices, a microservice-based parallel processing architecture is designed. Each protocol conversion task is assigned an independent processing thread or container, and task scheduling and load balancing are achieved through message queues.

[0014] Optionally, in step 5, data reliable transmission and interactive verification are as follows: Adaptive transmission strategy: Before data is sent, the system monitors the network status in real time and dynamically adjusts the transmission strategy; Two-way interactive verification mechanism: After the data is sent to the target device, a two-way verification process is established; Enhanced secure transmission: Multi-level security protection is adopted during data transmission.

[0015] The multi-protocol communication conversion module of the intelligent safety guardrail includes: The protocol identification unit is used to identify the protocol types of various protocol heterogeneous devices in the intelligent safety fence. The protocol heterogeneous devices include at least TCP / IP-based devices, MQTT-based devices, CoAP-based devices, and Zigbee-based devices. A rule base construction unit is used to construct a protocol data parsing rule base based on the identified protocol type. The protocol data parsing rule base includes data frame format parsing rules, data field meaning parsing rules, and data transmission timing parsing rules for different protocols. During the construction process, the rule base supports hot plugging of protocols to dynamically load or unload the protocol data parsing rule base to meet the access requirements of heterogeneous devices with different protocols. The data parsing unit is used to receive data sent by various heterogeneous devices, parse the data according to the data parsing rule base of the protocol, and convert the parsed data into a unified data format. The unified data format includes a specified data structure and a specified data encoding method; The protocol encapsulation unit is used to encapsulate the data converted into a unified format according to the protocol types supported by the target protocol heterogeneous devices based on the pre-built protocol mapping table. The protocol mapping table records the mapping relationship between different source protocols and target protocols. The data sending unit is used to send the encapsulated data to the target protocol heterogeneous device, realizing the interconnection and intercommunication between the protocol heterogeneous devices in the intelligent safety fence; The protocol identification unit is connected to the rule base construction unit, the rule base construction unit is connected to the data parsing unit, the data parsing unit is connected to the protocol encapsulation unit, and the protocol encapsulation unit is connected to the data sending unit.

[0016] Beneficial effects of the present invention: The present invention constructs a data parsing rule base for the protocol based on the identified protocol type. In the process of constructing the data parsing rule base for the protocol, hot plugging of the protocol is supported to dynamically load or unload the data parsing rule base for the protocol, so as to adapt to the access requirements of heterogeneous devices with different protocols. The present invention receives data sent by heterogeneous devices of each protocol, parses the data according to the data parsing rule base of the protocol, and converts the parsed data into a unified data format to facilitate data interaction between the heterogeneous devices, thereby realizing interconnection and intercommunication between the heterogeneous devices of each protocol through the unified data format. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0018] Figure 1 It is a schematic diagram of the module structure of the present invention; Figure 2 Schematic diagram of the workflow of the present invention. DETAILED DESCRIPTION

[0019] The embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0020] Example 1 like Figure 1 As shown, this embodiment provides a multi-protocol communication conversion module for an intelligent safety guardrail, including: The protocol identification unit is used to identify the protocol types of various protocol heterogeneous devices in the intelligent safety fence. The protocol heterogeneous devices include at least TCP / IP-based devices, MQTT-based devices, CoAP-based devices, and Zigbee-based devices. A rule base construction unit is used to construct a protocol data parsing rule base based on the identified protocol type. The protocol data parsing rule base includes data frame format parsing rules, data field meaning parsing rules, and data transmission timing parsing rules for different protocols. During the construction process, the rule base supports hot plugging of protocols to dynamically load or unload the protocol data parsing rule base to meet the access requirements of heterogeneous devices with different protocols. The data parsing unit is used to receive data sent by various heterogeneous devices, parse the data according to the data parsing rule base of the protocol, and convert the parsed data into a unified data format. The unified data format includes a specified data structure and a specified data encoding method; The protocol encapsulation unit is used to encapsulate the data converted into a unified format according to the protocol types supported by the target protocol heterogeneous devices based on the pre-built protocol mapping table. The protocol mapping table records the mapping relationship between different source protocols and target protocols. The data sending unit is used to send the encapsulated data to the target protocol heterogeneous device, realizing the interconnection and intercommunication between the protocol heterogeneous devices in the intelligent safety fence; The protocol identification unit is connected to the rule base construction unit, the rule base construction unit is connected to the data parsing unit, the data parsing unit is connected to the protocol encapsulation unit, and the protocol encapsulation unit is connected to the data sending unit.

[0021] Example 2 like Figure 2 As shown, this embodiment provides a communication method for a multi-protocol communication conversion module of an intelligent safety guardrail, comprising the following steps: Step 1: Identify the protocol types of various protocol heterogeneous devices in the smart safety fence. Protocol heterogeneous devices include at least TCP / IP-based devices, MQTT-based devices, CoAP-based devices, and Zigbee-based devices. Step 2: Based on the identified protocol type, a protocol data parsing rule base is constructed. The protocol data parsing rule base includes data frame format parsing rules, data field meaning parsing rules, and data transmission timing parsing rules for different protocols. In the process of constructing the protocol data parsing rule base, hot plugging of protocols is supported to dynamically load or unload the protocol data parsing rule base, facilitating the access requirements of heterogeneous devices with different protocols. Step 3: Receive data sent by various heterogeneous devices, parse the data according to the protocol's data parsing rule base, and convert the parsed data into a unified data format to facilitate data interaction between various heterogeneous devices. The unified data format includes a specified data structure and a specified data encoding method; Step 4: The data converted into a unified format is encapsulated according to the protocol types supported by the target protocol heterogeneous devices based on a pre-built protocol mapping table; the protocol mapping table records the mapping relationship between different source protocols and target protocols; Step 5: Send the encapsulated data to the target protocol heterogeneous device to achieve interconnection and intercommunication between the protocol heterogeneous devices in the intelligent safety fence.

[0022] Example 3 Based on Example 1, in step 1, a TCP / IP-based device is identified based on transport layer features, including detecting whether a TCP connection is established and analyzing whether the port number matches a known TCP / IP protocol; Identify MQTT-based devices based on application layer protocol features, including analyzing whether the message contains the MQTT fixed header and CONNECT / CONNACK control message type; Identify CoAP-based devices based on application layer protocol characteristics, including analyzing whether UDP packets contain CoAP-specific message formats, option fields, and method codes; Identify Zigbee-based devices based on physical and MAC layer characteristics, including detecting whether they use the IEEE802.15.4 wireless standard and analyzing the Zigbee network and application layer frame formats; For devices that cannot be clearly identified by a single feature, a multi-feature fusion analysis method is used to combine packet length distribution, communication frequency pattern, and protocol state machine behavior for comprehensive identification.

[0023] Example 4 Based on Example 1, in step 2, the protocol data parsing rule base is mainly a rule system, which together constitutes a complete parsing capability for different protocol data: Data frame format parsing rules: define the physical structure of the protocol data frame, including the byte distribution of the frame header, data segment, and check bit; Data field meaning parsing rules: define the semantics of each field in the data frame, including field type, value range, and unit; Data transmission timing analysis rules: specify the time sequence and logical flow of protocol data interaction, including the request-response mechanism.

[0024] Specifically, based on the identified protocol type, a data parsing rule base for the protocol is constructed, including the following steps: Step 1: Construct data frame format parsing rules; Frame structure analysis: Determine the frame start and end identifiers, analyze the structure of the frame header, data segment, and frame trailer, and define the length and position of each part.

[0025] Field segmentation rules: determine the field separation method (fixed length and delimiter), define the position and length of the field in the frame, and determine the data type of the field (integer, floating point number, and string).

[0026] Verification mechanism definition: Select an appropriate verification algorithm (CRC, Checksum), define the location and calculation method of the verification field, and formulate processing rules for verification failure.

[0027] Step 2: Constructing rules for parsing the meaning of data fields; Field semantic definition: Assign a unique identifier to each field, define the physical meaning and business meaning of the field, and determine the field's value range and validity conditions.

[0028] Numerical mapping rules: Establish a mapping table between enumeration values ​​and actual meanings, define the conversion rules from binary data to actual values, and formulate processing rules for special values ​​(such as invalid values ​​and missing values).

[0029] Unit conversion rules: define the conversion relationship between physical units and numerical values, determine data precision and rounding rules, and establish conversion rules for multiple unit systems.

[0030] Step 3: Constructing data transmission timing analysis rules; Message sequence definition: Analyze the message interaction process of the protocol, define the request-response message pairs, and determine the order and conditions for message sending.

[0031] Timing parameter configuration: set the message sending interval, define the timeout period and number of retries, and formulate the timing rules for connection establishment and disconnection.

[0032] Exception handling rules: define the detection conditions for communication anomalies, formulate anomaly recovery strategies, and establish an anomaly recording and reporting mechanism.

[0033] There are four key points for protocol hot-swap design: Protocol description language: Design a unified protocol description language, support standardized definition of rules, and provide rule verification tools to ensure the correctness and completeness of rules; Dynamic loading mechanism: Implement a plug-in-based architecture, support dynamic discovery and loading of protocols, design the format and loading interface of rule packages, and ensure cross-platform compatibility; Resource management strategy: Implement on-demand loading and release mechanisms for protocol resources, establish resource usage tracking mechanisms, and avoid memory leaks; Thread-safe design: Implement thread-safe protocol registry and parser management, design concurrent access control mechanism, and ensure stability in multi-threaded environment.

[0034] For protocol hot plugging, directed graph topology sorting is used, specifically: given a dependency directed graph ,in, is a set of rule bases, is the dependency edge (i.e. express rely ), the necessary and sufficient condition for the existence of topological sorting of a directed graph is that there are no cycles in the graph.

[0035] The algorithm steps for topological sorting of directed graphs are: Step a: Calculate the in-degree of each node (i.e., the number of edges pointing to it). In-degree is a fundamental concept in topological sorting of directed graphs, used to measure the degree of node dependency. In the protocol rule base scenario, if rule base A depends on rule base B, then an edge (B, A) exists, and A's in-degree is incremented by 1. A rule base with an in-degree of 0 has no dependencies and can be loaded directly. If the in-degree of a node never reaches 0 (e.g., A→B and B→A), a cycle exists, and topological sorting is impossible.

[0036] Step b: Add nodes with in-degree 0 to the queue; this is to determine the loading starting point. The queue follows the FIFO principle to ensure that nodes without dependencies are processed first. If the dependency graph is empty (no nodes), an empty topological order is returned directly. If the node has no dependencies and is not depended on by any node (in-degree 0 and out-degree 0), it still needs to be queued and processed.

[0037] Step c: Take out the nodes one by one, reduce the in-degree of the neighboring nodes of the taken node position, and add them to the queue if the in-degree becomes 0; among them, take out the node u from the head of the queue, add it to the topology sequence list, and mark it as processed. For all adjacent nodes v of u (i.e., the edge from u to v), execute the in-degree of the neighboring nodes Subtract 1: ;like If it becomes 0, it means that all of v's dependencies have been satisfied, and v is added to the queue. Each directed edge (u, v) indicates that task u is a prerequisite for task v (for example, module u must be compiled before module v can be compiled). The result of topological sorting corresponds to the feasible execution order of tasks, ensuring that all dependencies are satisfied and avoiding execution failures due to incorrect order.

[0038] Step d: If the final number of processed nodes equals the total number of nodes, then there is no cycle and a topological order exists; otherwise, there is a cycle. Specifically, if a cycle exists in the graph (e.g., A→B→A), the in-degree of all nodes within the cycle cannot be reduced to 0, resulting in the number of nodes processed by the topological sort being less than the total number of nodes. If the length of the topological sequence list equals the total number of nodes, then there is no cycle in the graph and the topological order is valid.

[0039] Directed graph topological sorting is used when rule base A depends on rule base B to ensure that B is loaded before A, avoiding parsing failures due to missing dependencies.

[0040] In dependency resolution (such as protocol rule base dependencies and software package dependencies), topological sorting is used to determine the order in which components are loaded to avoid circular dependencies. The protocol rule base is: Dependency graph modeling; Among them, the node is each protocol parsing module (such as Modbus parser, HTTP parser); Edge is a module Dependent modules (Right now Operational needs first), then there is an edge .

[0041] Dependency conflict detection; if topological sorting cannot be generated (there is a cycle in the graph), it means there is a circular dependency (such as: and ), which requires error reporting or manual adjustment.

[0042] The loading order is generated; the topological order is the legal loading order. For example, if the dependency graph is and , then the topological order may be or .

[0043] By quantifying dependencies (in-degree), dependency constraints are released in sequence (in-degree minus 1), and a legal loading order is finally generated. At the same time, circular dependencies are detected by comparing the number of nodes. This process provides support for the protocol hot-plugging mechanism, ensuring that the rule base is initialized in the correct order during dynamic loading. Topological sorting quantifies dependencies through partial order relations in graph theory, providing a loading order for hot-plugging of protocol rule bases. Its algorithm can not only detect dependency conflicts, but also construct dynamic loading.

[0044] Example 5 Based on Example 1, in step 3, the data is parsed using the following steps: Step A: Device identification; unique identification of device ID, MAC address, and communication port information; Step B: Protocol type determination; automatically identify the protocol type based on data features (such as frame header identifier, protocol port, and data length); Step C: rule base call; load the corresponding parsing rules from the rule base based on the protocol type; Step D: Data parsing execution; parsing the original data byte by byte according to the rules; Step E: Unify data model definition; define standardized data structure; Step F: Protocol data mapping: establish a mapping relationship between protocol fields and unified models; Step G: Data validity check; Check content: format check: JSON Schema verification based on the unified model; value range check: such as whether the temperature value is within the range of [-273, 1000]; integrity check: whether required fields are missing; Step H: Standardize data output; output method: message queue (Kafka, RabbitMQ), database storage (MySQL, InfluxDB), API interface (RESTful, GraphQL).

[0045] Convert the parsed data into a unified data format as follows: For multidimensional data (such as arrays and nested objects), hierarchical processing is required: Single layer data: ;in, Raw heterogeneous data comes from different devices / systems (such as sensor binary, APP JSON, and PLC custom protocol). Standardized data is converted into a unified format and can be universally parsed and interacted with by multiple devices / systems. A key-value pair is a basic unit of data: "field name - field value" (e.g., {"temperature":25} in JSON, k="temperature", v=25); For the field mapping function, the original field name Convert to standard name (e.g. tmp in sensor → standard temperature); For type conversion function, the original value Convert to a standard type (e.g., string "25" → value 25, timestamp 1696233600 → standard time format 2023-10-01 12:00:00); To traverse and reconstruct, we process them one by one The key-value pairs in the map are and the converted Reassemble ; The essence of single-layer data is the conversion rules from "heterogeneous data to standardized data" to solve the interaction between multiple devices / systems. Specifically: The fields are not uniform: A device uses tmp to represent temperature, while B system uses temperature. Unified into standard fields.

[0046] Type incompatibility: C sensor outputs string "25", D system requires value 25, Conversion type.

[0047] Difficulty in intercommunication: the scattered and chaotic raw data ( ), "clean and reconstruct" according to unified rules into a format that can be understood by all devices ( ), let heterogeneous data become the same data.

[0048] Multidimensional data: ;in, This is a nested data conversion function that recursively / hierarchically processes complex nested values ​​(such as arrays and nested objects) to ensure that deep data can also be standardized; To traverse and reconstruct, we process them one by one Key-value pairs, using the original field name and the converted value Reorganized into .

[0049] Multidimensional data is a heterogeneous data standardization rule with nested processing, which solves the conversion problem of complex data (such as multi-layer JSON, nested or multi-dimensional arrays, and nested objects), namely: Ordinary key-value pairs: use directly Convert values ​​(e.g., convert strings to numeric values, format timestamps).

[0050] Nested structure: It will recursively process deep data (such as objects in arrays, arrays in objects) to ensure that the entire nested structure conforms to the standard format.

[0051] Supports standardized abstract expression of nested heterogeneous data. In scenarios such as the Internet of Things, industrial data integration, and multi-system interaction, it solves the problem of complex nested data being difficult to unify in a unified format. No matter how deep or nested the data is, it follows a unified rule ( ) Convert data at all levels into a standard format so that devices / systems can interact.

[0052] Example 6 Based on Example 1, in step 4, the protocol mapping and data encapsulation depth optimization is as follows: Dynamic construction and intelligent learning of protocol mapping tables: The protocol mapping table is constructed using a dual mode of "basic mapping + dynamic learning." Basic mapping is pre-defined based on common protocol conversion scenarios (e.g., TCP / IP to MQTT), covering rules such as data field reorganization and protocol header adaptation. The dynamic learning module uses machine learning algorithms to analyze historical data conversion records and automatically identify conversion rules under new protocol combinations. For example, when a Zigbee device interacts with a CoAP device for the first time, temporary mapping rules can be quickly generated by analyzing the data characteristics of both parties, and continuously optimized in subsequent interactions. At the same time, a version management mechanism is introduced to record mapping table changes and support version rollback to address compatibility issues caused by rule adjustments.

[0053] Refined data encapsulation: During the encapsulation process, differentiated processing is performed based on the transmission characteristics of different protocols. For the TCP / IP protocol, the appropriate transmission mode (e.g., TCP long connection or UDP fast transmission) is selected based on the target device's requirements, and necessary checksum fields and transmission control information are added during data encapsulation. For the MQTT protocol, a corresponding topic tree structure is constructed during encapsulation based on the message subject and QoS level, and parameters such as message retransmission and retention flags are processed. In addition, a data compression mechanism is introduced to perform lossless compression on larger data volumes before encapsulation (e.g., the Snappy algorithm), reducing transmission bandwidth usage and improving transmission efficiency.

[0054] Multi-protocol Parallel Processing: To address the concurrent data conversion needs of multiple devices, a microservices-based parallel processing architecture is designed. Each protocol conversion task is assigned a separate processing thread or container, with task scheduling and load balancing implemented through message queues (such as Kafka). For example, when multiple TCP / IP devices are simultaneously transmitting data to an MQTT device, the system dynamically allocates resources to ensure that conversion tasks do not interfere with each other, improving overall processing performance. Furthermore, an integrated circuit breaker mechanism automatically isolates the faulty task when a protocol conversion anomaly occurs, preventing it from impacting communications with other devices.

[0055] Example 7 Based on Example 1, in step 5, data reliable transmission and interactive verification are as follows: Adaptive transmission strategy: Before data is sent, the system monitors network status (such as bandwidth, latency, and packet loss rate) in real time and dynamically adjusts the transmission strategy based on the target device's performance parameters (such as processing power and cache capacity). If the network environment is poor, block transmission is implemented with an ACK confirmation mechanism to ensure data integrity. For devices with high real-time requirements (such as TCP / IP video surveillance devices), low-latency transmission paths are prioritized. Furthermore, by introducing edge computing nodes, some data processing and packaging tasks are moved to the edge of the network, reducing pressure on the core network and improving transmission response speed.

[0056] Bidirectional Interactive Verification Mechanism: After data is sent to the target device, a bidirectional verification process is established. Upon receiving the data, the target device first performs reverse parsing based on the protocol type to verify that the data format and content conform to expectations. The verification result (success / failure and error details) is then encapsulated as a feedback message and sent back to the source device. If the source device receives this feedback and verification fails, a retransmission mechanism is automatically triggered, and data conversion or encapsulation strategies are adjusted based on the error type. For example, if parsing fails due to an error in the protocol mapping rules, the system will retrieve the mapping table for correction and update the dynamic learning module.

[0057] Enhanced secure transmission: Multi-layered security measures are employed during data transmission. The transport layer uses the TLS / SSL encryption protocol to encrypt encapsulated data, preventing data theft and tampering. The application layer utilizes device authentication (such as digital certificates and dynamic tokens) and access control lists (ACLs) to ensure only authorized devices can interact with data. Furthermore, regular security audits of transmitted data analyze abnormal traffic patterns to promptly identify and block potential network attacks, ensuring secure communication for the intelligent safety guardrail system.

[0058] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any modifications or substitutions that can be easily conceived by a person skilled in the art within the technical scope of the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. The communication method of the multi-protocol communication conversion module of the intelligent safety guardrail is characterized in that: The steps include: Step 1: Identify the protocol types of various protocol heterogeneous devices in the smart safety fence. Protocol heterogeneous devices include at least TCP / IP-based devices, MQTT-based devices, CoAP-based devices, and Zigbee-based devices. Step 2: Based on the identified protocol type, a protocol data parsing rule base is constructed. The protocol data parsing rule base includes data frame format parsing rules, data field meaning parsing rules, and data transmission timing parsing rules for different protocols. In the process of constructing the protocol data parsing rule base, hot plugging of protocols is supported to dynamically load or unload the protocol data parsing rule base, facilitating the access requirements of heterogeneous devices with different protocols. Step 3: Receive data sent by various heterogeneous devices, parse the data according to the protocol's data parsing rule base, and convert the parsed data into a unified data format to facilitate data interaction between various heterogeneous devices. The unified data format includes a specified data structure and a specified data encoding method; Step 4: The data converted into a unified format is encapsulated according to the protocol types supported by the target protocol heterogeneous devices based on a pre-built protocol mapping table; the protocol mapping table records the mapping relationship between different source protocols and target protocols; Step 5: Send the encapsulated data to the target protocol heterogeneous device to achieve interconnection and intercommunication between the protocol heterogeneous devices in the intelligent safety fence.

2. The communication method of the multi-protocol communication conversion module of the intelligent safety guardrail according to claim 1 is characterized in that: In step 1, TCP / IP-based devices are identified based on transport layer features, MQTT-based devices are identified based on application layer protocol features, CoAP-based devices are identified based on application layer protocol features, and Zigbee-based devices are identified based on physical layer and MAC layer features.

3. The communication method of the multi-protocol communication conversion module of the intelligent safety guardrail according to claim 1, characterized in that: In the second step, a data parsing rule base for the protocol is constructed based on the identified protocol type, including the following steps: Step 1: Construct data frame format parsing rules, which include frame structure analysis, field segmentation rules definition, and verification mechanism definition. Step 2: Construct data field meaning parsing rules; this includes field semantics definition, value mapping rules, and unit conversion rules. Step 3: Construct data transmission timing analysis rules; define message sequence, configure timing parameters, and define exception handling rules.

4. The communication method of the multi-protocol communication conversion module of the intelligent safety guardrail according to claim 1, characterized in that: In the step 2, the protocol hot plug adopts directed graph topology sorting, specifically: given a dependency directed graph ,in, is a set of rule bases, The dependency edge is express rely , the necessary and sufficient condition for the existence of topological sorting of a directed graph is that there is no cycle in the graph.

5. The communication method of the multi-protocol communication conversion module of the intelligent safety guardrail according to claim 4 is characterized in that: The algorithm steps for the directed graph topological sorting are: Step a: Calculate the in-degree of each node; Step b: Add the node with in-degree 0 to the queue; Step c: Take out the nodes one by one, reduce the in-degree of the neighboring nodes of the taken node, and add them to the queue if the in-degree becomes 0; Step d: If the number of nodes finally processed is equal to the total number of nodes, there is no cycle and a topological order exists; otherwise, there is a cycle.

6. The communication method of the multi-protocol communication conversion module of the intelligent safety guardrail according to claim 1, characterized in that: In step three, the data is parsed using the following steps: Step A: Device identification; Step B: Determine the protocol type; Step C: rule base call; Step D: data parsing and execution; Step E: Unify data model definition; Step F: protocol data mapping; Step G: Data validity check; Step H: Standardize data output.

7. The communication method of the multi-protocol communication conversion module of the intelligent safety guardrail according to claim 6, characterized in that: In step E, the parsed data is converted into a unified data format in the following manner: For multidimensional data, hierarchical processing is required: Single layer data: ;in, Original heterogeneous data, which is the original data from different devices / systems; Standardized data is converted into a unified format and can be universally parsed and interacted with by multiple devices / systems. A key-value pair is the basic unit of data "field name-field value"; For the field mapping function, the original field name Convert to standard name; For type conversion function, the original value Convert to standard type; To traverse and reconstruct, we process them one by one The key-value pairs in the map are and the converted Reassemble ; Multidimensional data: ;in, It is a nested data conversion function that recursively / hierarchically processes complex nested values ​​to ensure that deep data can also be standardized; To traverse and reconstruct, we process them one by one Key-value pairs, using the original field name and the converted value Reorganized into .

8. The communication method of the multi-protocol communication conversion module of the intelligent safety guardrail according to claim 1, characterized in that: In step 4, the protocol mapping and data encapsulation are as follows: The protocol mapping table is constructed using a dual-mode approach: basic mapping and dynamic learning. The basic mapping is pre-defined based on common protocol conversion scenarios, covering data field reorganization and protocol header adaptation rules. The dynamic learning module uses machine learning algorithms to analyze historical data conversion records and automatically identify conversion rules under new protocol combinations. During the encapsulation process, differentiated processing is performed based on the transmission characteristics of different protocols; To meet the concurrent data conversion needs of multiple devices, a microservice-based parallel processing architecture is designed. Each protocol conversion task is assigned an independent processing thread or container, and task scheduling and load balancing are achieved through message queues.

9. The communication method of the multi-protocol communication conversion module of the intelligent safety guardrail according to claim 1, characterized in that: In step 5, the data reliable transmission and interactive verification are as follows: Adaptive transmission strategy: Before data is sent, the system monitors the network status in real time and dynamically adjusts the transmission strategy; Two-way interactive verification mechanism: After the data is sent to the target device, a two-way verification process is established; Enhanced secure transmission: Multi-level security protection is adopted during data transmission.

10. A multi-protocol communication conversion module for an intelligent safety guardrail, configured to execute the communication method for the multi-protocol communication conversion module for an intelligent safety guardrail according to any one of claims 1 to 9, characterized in that: include: The protocol identification unit is used to identify the protocol types of various protocol heterogeneous devices in the intelligent safety fence. The protocol heterogeneous devices include at least TCP / IP-based devices, MQTT-based devices, CoAP-based devices, and Zigbee-based devices. A rule base construction unit is used to construct a protocol data parsing rule base based on the identified protocol type. The protocol data parsing rule base includes data frame format parsing rules, data field meaning parsing rules, and data transmission timing parsing rules for different protocols. During the construction process, the rule base supports hot plugging of protocols to dynamically load or unload the protocol data parsing rule base to meet the access requirements of heterogeneous devices with different protocols. The data parsing unit is used to receive data sent by various heterogeneous devices, parse the data according to the data parsing rule base of the protocol, and convert the parsed data into a unified data format. The unified data format includes a specified data structure and a specified data encoding method; The protocol encapsulation unit is used to perform protocol encapsulation on the data converted into a unified format according to the protocol types supported by the target protocol heterogeneous devices based on a pre-built protocol mapping table, which records the mapping relationship between different source protocols and target protocols; The data sending unit is used to send the encapsulated data to the target protocol heterogeneous device, realizing the interconnection and intercommunication between the protocol heterogeneous devices in the intelligent safety fence; The protocol identification unit is connected to the rule base construction unit, the rule base construction unit is connected to the data parsing unit, the data parsing unit is connected to the protocol encapsulation unit, and the protocol encapsulation unit is connected to the data sending unit.

Images