Heterogeneous equipment control instruction adaptive generation method based on protocol semantic mapping graph

Abstract

The invention discloses a heterogeneous equipment control instruction adaptive generation method based on a protocol semantic mapping graph, which comprises the following steps: constructing a three-layer core architecture, constructing a protocol semantic mapping graph on a semantic layer, receiving a user control intention through an intention layer, and generating a heterogeneous equipment control instruction based on the protocol semantic mapping graph. Analyzing the user control intention into a standard operation of a semantic layer, obtaining a protocol type and version information of target equipment, screening out an optimal protocol implementation path through graph matching and a retrieval algorithm of the semantic layer, and generating a pipeline through a parameterized template engine of a protocol layer in combination with equipment configuration information and an execution instruction in a version library. According to the method, the development complexity of multi-protocol equipment access is greatly reduced, and the method is suitable for heterogeneous equipment integration scenes in industrial automation, intelligent buildings, smart parks and smart homes.

Description

Technical Field

[0001] This invention relates to the fields of Internet of Things and intelligent control technology, and in particular to an adaptive generation method for control instructions of heterogeneous devices based on protocol semantic mapping graphs. Background Technology

[0002] With the rapid development of IoT technology, the number and types of devices in fields such as industrial automation and smart buildings continue to grow, forming a heterogeneous device network composed of various industrial protocols (such as Modbus, OPCUA, BACnet, etc.). However, devices from different manufacturers often use proprietary protocols or differentiated standard protocol implementations, resulting in incompatible control commands between devices, which brings many challenges to the integrated control of heterogeneous devices.

[0003] In existing technologies, the generation of control commands for heterogeneous devices mainly relies on the development of dedicated interfaces for specific protocols. Developers need to have a deep understanding of the instruction encoding format, parameter passing rules, verification logic, and other details of each protocol, and write separate control command generation modules for devices with different protocols. The above method has high development complexity, and when a new protocol device is connected, interface development and debugging need to be carried out again, which is time-consuming and costly. Therefore, it is necessary to design an adaptive generation method for heterogeneous device control commands based on protocol semantic mapping graphs. Summary of the Invention

[0004] To address the aforementioned problems, the purpose of this invention is to provide an adaptive generation method for heterogeneous device control commands based on protocol semantic mapping graphs.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: an adaptive generation method for heterogeneous device control commands based on protocol semantic mapping graphs, comprising the following steps: S1: Construct a three-layer core architecture, which includes an intent layer, a semantic layer, and a protocol layer. The intent layer is used to receive and parse user control intents. The semantic layer is used to construct and manage the protocol semantic mapping graph and complete graph matching. The protocol layer is used for instruction parameter binding, data type conversion, and check code generation. S2: Construct a protocol semantic mapping graph at the semantic layer, using a graph database storage structure. Standardized operation semantics are used as nodes, and the specific instruction implementations of different industrial protocols are used as edges connecting the nodes. Each node contains operation type, required parameters, and optional parameters. Each edge contains protocol type, instruction encoding format, parameter mapping rules, and verification algorithm. During construction, the standard operations are first extracted by analyzing industrial control scenarios. Then, for each protocol, its official documentation is parsed to extract the corresponding instructions, and parameter mapping relationships are established. Initial path weights are set based on historical execution success rate, response time, and resource consumption. Finally, the graph is stored in the Neo4j graph database and a composite index is built to achieve millisecond-level retrieval response. S3: Receive user control intent through the intent layer and parse the user control intent into standard operations of the semantic layer; S4: Obtain the protocol type and version information of the target device, and filter out the optimal protocol implementation path through semantic layer graph matching and retrieval algorithms; S5: Through the parameterized template engine of the protocol layer, combined with the device configuration information in the version library, the instruction generation pipeline is executed, including template selection, parameter verification and conversion, data type conversion, instruction assembly, checksum calculation, and instruction verification. The entire process adopts the chain of responsibility design pattern, and each link can be independently replaced and extended.

[0006] Furthermore, the standardized operation semantics described in step S2 include one or more of the following: equipment start / stop, parameter adjustment, status query, and fault alarm.

[0007] Furthermore, the different industrial protocols mentioned in step S2 include one or more of Modbus, OPCUA, and BACnet.

[0008] Furthermore, the user control intent mentioned in step S3 includes structured control instructions and natural language control intents. The intent layer has a built-in hybrid intent parsing system, including... I. Preprocessing module: Performs word segmentation and entity recognition on the input text; II. Rule Matching Module: Maintains an industrial control keyword library and directly outputs standard operations when a rule is matched; III. Machine Learning Module: When rule matching fails, a lightweight Transformer model is activated, trained on 100,000 industrial corpora, supporting the recognition of 4 major categories and 200+ subcategories of operations. IV. Post-processing module: Verifies the rationality of parameters; unreasonable parameters trigger secondary confirmation. V. Continuous Optimization Module: Records parsing accuracy, and automatically triggers incremental training when the accuracy drops by 10% continuously.

[0009] Furthermore, the graph matching and retrieval algorithm described in step S4 adopts a two-stage processing mechanism: the first stage is semantic matching, which performs precise or fuzzy matching between the user-parsed standard operations and graph nodes. Fuzzy matching uses the edit distance algorithm to calculate the similarity of operation names, sets 85% as the matching threshold, and generates a candidate node list; the second stage is path filtering, which filters available protocol implementations for each candidate node based on the protocol type and version number of the target device, and then sorts them according to priority rules; the algorithm is implemented using a priority queue data structure, and the retrieval time does not exceed 50ms with a scale of 1000 nodes. A 100ms timeout protection mechanism is set, and if the timeout occurs, it will automatically degrade to a preset default path.

[0010] Furthermore, the priority rules for path filtering are as follows: First, prioritize paths with a historical success rate higher than 95%; Second, when success rates are similar, choose the path with the shortest average response time; 3. When response times are similar, choose the path with the lowest CPU utilization.

[0011] Furthermore, in step S5, the template selection involves loading a JSON-formatted template from the template library based on the protocol type and device model determined in step S4. This template includes a fixed byte sequence, parameter placeholders and their data types, byte order, and range constraints. The parameter verification and conversion verifies whether the input parameters are within the device's allowed range, performing unit conversion and precision adjustment. The data type conversion handles conversions between 16 / 32-bit integers, single / double-precision floating-point numbers, strings, and boolean values, considering byte order and encoding differences. The instruction assembly concatenates fixed fields and converted parameters according to the template order. The checksum calculation calculates a CRC16 / 32 or parity checksum according to protocol requirements and appends it to the end of the instruction. The instruction verification checks the integrity of the generated instruction; if verification fails, an error log is recorded and a degradation mechanism is triggered, regenerating the instruction using a backup template.

[0012] Furthermore, the method also includes step S6, establishing an unknown protocol integration mechanism and providing a protocol intelligent access workbench, wherein the integration mechanism includes: I. Protocol Description Specification: The protocol is described in YAML format, including basic protocol information, data frame structure, and instruction set definition; II. Intelligent parsing: The system automatically verifies file formats, identifies protocol features, recommends existing protocol templates with a similarity greater than 70%, and suggests parameter mapping relationships; III. Interactive Verification: Provides a visual interface to display the analysis results, and the built-in protocol simulator allows engineers to input test parameters and verify the generated instructions in real time; IV. Learning Mechanism: Record engineers' modification behavior to optimize the accuracy of subsequent protocol parsing; V. Version Control: Generate a unique identifier for each new protocol, record modification history, and support rollback.

[0013] Furthermore, the method also includes step S7, establishing a multi-level exception handling mechanism, including: 1. Command generation error: When the parameter is out of range, it will be automatically corrected to the device's allowed boundary value. If the correction fails, the suboptimal protocol path will be tried, with a maximum of 3 alternative paths to try. II. Execution Failure Feedback: Record the error codes returned by the device, analyze the types of failure reasons, dynamically update the success rate weight of the path, and temporarily disable the path if it fails 3 times in a row. III. Resource Protection: Set the upper limit of the instruction generation queue to 1000. When the queue reaches 800, start flow control to reduce the priority of non-critical requests. IV. Offline Mode: When the network is interrupted, the latest device configuration and protocol template are cached locally to maintain basic control functions. Operation records are stored locally and automatically synchronized after the network is restored. V. Health Check: Perform a system self-check every 5 minutes to verify the integrity of the map, the availability of the template, and the consistency of the version library.

[0014] Compared with the prior art, the present invention has the following beneficial effects: This invention constructs a protocol semantic mapping graph at the semantic layer. This graph uses standardized operational semantics as nodes and specific instruction implementations corresponding to different industrial protocols as edges connecting the nodes, establishing a many-to-many mapping relationship between semantics and protocols. Upon receiving a user's control intent, the system first parses it into standard operations at the semantic layer. Then, based on the protocol type of the target device, it automatically selects the optimal protocol implementation path through graph matching and retrieval algorithms. Finally, through the parameterized template engine at the protocol layer, combined with device configuration information in the library, it completes dynamic binding of instruction parameters, accurate data type conversion, and automatic generation of checksums. For unknown protocols, the system provides a protocol-based intelligent access workbench and establishes a multi-level exception handling mechanism to handle anomalies and errors in a timely manner, ensuring normal system operation. It is suitable for heterogeneous device integration scenarios such as industrial automation, intelligent buildings, and smart parks. Detailed Implementation

[0015] The technical solution of the present invention will be further described in detail below with reference to the embodiments.

[0016] This embodiment of a method for adaptively generating control commands for heterogeneous devices based on protocol semantic mapping graphs includes the following steps: S1: Construct a three-layer core architecture, which includes an intent layer, a semantic layer, and a protocol layer. The intent layer is used to receive and parse user control intents, the semantic layer is used to build and manage the protocol semantic mapping graph and complete graph matching, and the protocol layer is used for instruction parameter binding, data type conversion, and checksum generation.

[0017] S2: Construct a protocol semantic mapping graph at the semantic layer, using a graph database storage structure. Standardized operation semantics are used as nodes, including one or more of equipment start / stop, parameter adjustment, status query, and fault alarm. Specific instruction implementations of different industrial protocols are used as edges connecting the nodes. These industrial protocols include one or more of Modbus, OPCUA, and BACnet. Each node contains operation type, required parameters, and optional parameters. Each edge contains protocol type, instruction encoding format, parameter mapping rules, and verification algorithm. During construction, first, standard operations are extracted from industrial control scenarios. Then, for each protocol, its official documentation is parsed to extract corresponding instructions, establishing parameter mapping relationships. Initial path weights are set based on historical execution success rate, response time, and resource consumption. Finally, the graph is stored in the Neo4j graph database and a composite index is built to achieve millisecond-level retrieval response.

[0018] S3: Receives user control intents through the intent layer and parses them into standard semantic layer operations. User control intents include structured control commands and natural language control intents. The intent layer has a built-in hybrid intent parsing system, including... I. Preprocessing module: Performs word segmentation and entity recognition on the input text, such as device names and parameter values; II. Rule Matching Module: Maintains an industrial control keyword library, such as 500+ keywords and 200+ equipment identifiers; directly outputs standard operations when a rule is matched; III. Machine Learning Module: When rule matching fails, a lightweight Transformer model is activated with less than 5M parameters. It is trained on 100,000 industrial corpora and supports the recognition of 4 major categories and 200+ subcategories of operations. IV. Post-processing module: Verify the rationality of parameters, such as ensuring that the temperature value does not exceed 1000℃; unreasonable parameters trigger secondary confirmation. V. Continuous Optimization Module: Records parsing accuracy, and automatically triggers incremental training when the accuracy drops by 10% continuously.

[0019] S4: Obtain the protocol type and version information of the target device, and filter the optimal protocol implementation path through semantic layer graph matching and retrieval algorithms. The graph matching and retrieval algorithm adopts a two-stage processing mechanism: The first stage is semantic matching, which performs precise or fuzzy matching between the user's parsed standard operations, such as starting the device, and graph nodes. Fuzzy matching uses the edit distance algorithm to calculate the similarity of operation names, sets 85% as the matching threshold, and generates a candidate node list. The second stage is path filtering, which filters the available protocol implementations for each candidate node based on the target device's protocol type and version number, and then sorts them according to the following priority rules: First, prioritize paths with a historical success rate higher than 95%; Second, when success rates are similar, choose the path with the shortest average response time; 3. When response times are similar, choose the path with the lowest CPU utilization.

[0020] The algorithm is implemented using a priority queue data structure. With a scale of 1000 nodes, the retrieval time does not exceed 50ms. A 100ms timeout protection mechanism is set, and if the timeout occurs, it will automatically degrade to the preset default path.

[0021] S5: Using the parameterized template engine at the protocol layer, combined with device configuration information from the version library, instructions are executed to generate a pipeline, including the following steps: 1. Template Selection: Based on the protocol type and device model determined in step S4, load a JSON format template from the template library, which includes a fixed byte sequence (such as Modbus function code), parameter placeholders and their data types, byte order and range constraints; II. Parameter Verification and Conversion; Verify whether the input parameters are within the allowable range of the equipment, such as temperature parameter check -40℃~85℃, unit conversion and precision adjustment; III. Data type conversion; handling conversions between 16 / 32-bit integers, single / double precision floating-point numbers, strings, and boolean values, considering byte order and encoding differences; IV. Instruction Assembly: Concatenate fixed fields and converted parameters according to the template order; 5. Checksum Calculation: Calculate the CRC16 / 32 or parity checksum according to the protocol requirements and append it to the end of the instruction; 6. Command Verification: Check the integrity of the generated commands. If verification fails, log the error and trigger the degradation mechanism to regenerate using the backup template. The entire process adopts the chain of responsibility design pattern, and each link can be independently replaced and expanded.

[0022] S6: Establish an unknown protocol integration mechanism and provide an intelligent protocol access platform. The integration mechanism includes: I. Protocol Description Specification: The protocol is described in YAML format, including basic protocol information, data frame structure, and instruction set definition. The data frame structure includes start symbol, length position, data offset, check area, and end symbol; the instruction set definition includes opcode, parameter list, and data type. II. Intelligent parsing: The system automatically verifies file formats, identifies protocol features, recommends existing protocol templates with a similarity greater than 70%, and suggests parameter mapping relationships; III. Interactive Verification: Provides a visual interface to display the analysis results, and the built-in protocol simulator allows engineers to input test parameters and verify the generated instructions in real time; IV. Learning Mechanism: Record engineers' modification behavior to optimize the accuracy of subsequent protocol parsing; V. Version Control: Generate a unique identifier for each new protocol, record modification history, and support rollback.

[0023] S7: Establish a multi-level exception handling mechanism, including: 1. Command generation error: When the parameter is out of range, it will be automatically corrected to the device's allowed boundary value. If the correction fails, the suboptimal protocol path will be tried, with a maximum of 3 alternative paths to try. 2. Execution Failure Feedback: Record the error codes returned by the device, analyze the types of failure reasons, such as parameter errors, protocol incompatibility, device offline, etc.; dynamically update the success rate weight of this path, and temporarily disable this path if it fails 3 times in a row. III. Resource Protection: Set the upper limit of the instruction generation queue to 1000. When the queue reaches 800, start flow control to reduce the priority of non-critical requests. IV. Offline Mode: When the network is interrupted, the latest device configuration and protocol template are cached locally to maintain basic control functions. Operation records are stored locally and automatically synchronized after the network is restored. V. Health Check: Perform a system self-check every 5 minutes to verify the integrity of the map, the availability of the template, and the consistency of the version library.

[0024] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for adaptive generation of control commands for heterogeneous devices based on protocol semantic mapping graphs, characterized in that, Includes the following steps: S1: Construct a three-layer core architecture, which includes an intent layer, a semantic layer, and a protocol layer. The intent layer is used to receive and parse user control intents. The semantic layer is used to construct and manage the protocol semantic mapping graph and complete graph matching. The protocol layer is used for instruction parameter binding, data type conversion, and check code generation. S2: Construct a protocol semantic mapping graph at the semantic layer, using a graph database storage structure. Standardized operation semantics are used as nodes, and the specific instruction implementations of different industrial protocols are used as edges connecting the nodes. Each node contains operation type, required parameters, and optional parameters. Each edge contains protocol type, instruction encoding format, parameter mapping rules, and verification algorithm. During construction, the standard operations are first extracted by analyzing industrial control scenarios. Then, for each protocol, its official documentation is parsed to extract the corresponding instructions, and parameter mapping relationships are established. Initial path weights are set based on historical execution success rate, response time, and resource consumption. Finally, the graph is stored in the Neo4j graph database and a composite index is built to achieve millisecond-level retrieval response. S3: Receive user control intent through the intent layer and parse the user control intent into standard operations of the semantic layer; S4: Obtain the protocol type and version information of the target device, and filter out the optimal protocol implementation path through semantic layer graph matching and retrieval algorithms; S5: Through the parameterized template engine of the protocol layer, combined with the device configuration information in the version library, the instruction generation pipeline is executed, including template selection, parameter verification and conversion, data type conversion, instruction assembly, checksum calculation, and instruction verification. The entire process adopts the chain of responsibility design pattern, and each link can be independently replaced and extended.

2. The method for adaptive generation of heterogeneous device control commands based on protocol semantic mapping graphs according to claim 1, characterized in that, The standardized operation semantics mentioned in step S2 include one or more of the following: equipment start / stop, parameter adjustment, status query, and fault alarm.

3. The method for adaptive generation of heterogeneous device control commands based on protocol semantic mapping graphs according to claim 1, characterized in that, The different industrial protocols mentioned in step S2 include one or more of Modbus, OPCUA, and BACnet.

4. The method for adaptive generation of heterogeneous device control commands based on protocol semantic mapping graphs according to claim 1, characterized in that, The user control intent mentioned in step S3 includes structured control commands and natural language control intents. The intent layer has a built-in hybrid intent parsing system, including... I. Preprocessing module: Performs word segmentation and entity recognition on the input text; II. Rule Matching Module: Maintains an industrial control keyword library and directly outputs standard operations when a rule is matched; III. Machine Learning Module: When rule matching fails, a lightweight Transformer model is activated, trained on 100,000 industrial corpora, supporting the recognition of 4 major categories and 200+ subcategories of operations. IV. Post-processing module: Verifies the rationality of parameters; unreasonable parameters trigger secondary confirmation. V. Continuous Optimization Module: Records parsing accuracy, and automatically triggers incremental training when the accuracy drops by 10% continuously.

5. The method for adaptive generation of heterogeneous device control commands based on protocol semantic mapping graphs according to claim 1, characterized in that, The graph matching and retrieval algorithm described in step S4 adopts a two-stage processing mechanism: the first stage is semantic matching, which performs precise or fuzzy matching between the user-parsed standard operations and graph nodes. Fuzzy matching uses the edit distance algorithm to calculate the similarity of operation names, sets 85% as the matching threshold, and generates a candidate node list. The second stage is path filtering. For each candidate node, the available protocol implementations are filtered according to the protocol type and version number of the target device, and then sorted according to priority rules. The algorithm is implemented using a priority queue data structure. With a scale of 1000 nodes, the retrieval time does not exceed 50ms. A 100ms timeout protection mechanism is set, and if the timeout occurs, it will automatically degrade to the preset default path.

6. The method for adaptive generation of heterogeneous device control commands based on protocol semantic mapping graphs according to claim 5, characterized in that, The priority rules for path filtering are as follows: First, prioritize paths with a historical success rate higher than 95%; Second, when success rates are similar, choose the path with the shortest average response time; 3. When response times are similar, choose the path with the lowest CPU utilization.

7. The method for adaptive generation of heterogeneous device control commands based on protocol semantic mapping graphs according to claim 1, characterized in that, The template selection in step S5 involves loading a JSON-formatted template from the template library based on the protocol type and device model determined in step S4. This template includes a fixed byte sequence, parameter placeholders and their data types, byte order, and range constraints. The parameter verification and conversion verifies whether the input parameters are within the device's allowed range, performing unit conversion and precision adjustment. The data type conversion handles conversions between 16 / 32-bit integers, single / double-precision floating-point numbers, strings, and boolean values, considering byte order and encoding differences. The instruction assembly concatenates fixed fields and converted parameters according to the template order. The checksum calculation calculates a CRC16 / 32 or parity checksum according to protocol requirements and appends it to the end of the instruction. The instruction verification checks the integrity of the generated instruction; if verification fails, an error log is recorded and a degradation mechanism is triggered, regenerating the instruction using a backup template.

8. The method for adaptive generation of heterogeneous device control commands based on protocol semantic mapping graphs according to claim 1, characterized in that, The method further includes step S6, establishing an unknown protocol integration mechanism and providing a protocol intelligent access workbench, wherein the integration mechanism includes: I. Protocol Description Specification: The protocol is described in YAML format, including basic protocol information, data frame structure, and instruction set definition; II. Intelligent parsing: The system automatically verifies file formats, identifies protocol features, recommends existing protocol templates with a similarity greater than 70%, and suggests parameter mapping relationships; III. Interactive Verification: Provides a visual interface to display the analysis results, and the built-in protocol simulator allows engineers to input test parameters and verify the generated instructions in real time; IV. Learning Mechanism: Record engineers' modification behavior to optimize the accuracy of subsequent protocol parsing; V. Version Control: Generate a unique identifier for each new protocol, record modification history, and support rollback.

9. The method for adaptive generation of heterogeneous device control commands based on protocol semantic mapping graphs according to claim 1, characterized in that, The method further includes step S7, establishing a multi-level exception handling mechanism, including:

1. Command generation error: When the parameter is out of range, it will be automatically corrected to the device's allowed boundary value. If the correction fails, the suboptimal protocol path will be tried, with a maximum of 3 alternative paths to try. II. Execution Failure Feedback: Record the error codes returned by the device, analyze the types of failure reasons, dynamically update the success rate weight of the path, and temporarily disable the path if it fails 3 times in a row. III. Resource Protection: Set the upper limit of the instruction generation queue to 1000. When the queue reaches 800, start flow control to reduce the priority of non-critical requests. IV. Offline Mode: When the network is interrupted, the latest device configuration and protocol template are cached locally to maintain basic control functions. Operation records are stored locally and automatically synchronized after the network is restored. V. Health Check: Perform a system self-check every 5 minutes to verify the integrity of the map, the availability of the template, and the consistency of the version library.