Industrial protocol conversion method and device, terminal and medium

Abstract

The invention provides an industrial protocol conversion method and device, a terminal and a medium, and relates to the industrial internet technology, and the method comprises the steps: respectively extracting a semantic entity and a physical operation entity from an upstream application protocol message and a downstream industrial equipment protocol message, and calculating the comprehensive similarity between the semantic entity and the physical operation entity; constructing an industrial protocol knowledge graph based on the similarity so as to execute bidirectional conversion between the upstream protocol request and the downstream protocol message based on the knowledge graph; acquiring access time sequence data of each downstream protocol entity in real time; and predicting the access demand of each downstream protocol entity in a future time window based on the data, and dynamically adjusting polling strategies and protocol conversion resource allocation for different downstream protocol entities according to a prediction result. According to the method, the industrial protocol knowledge graph is constructed, and the polling frequencies and protocol conversion resource allocation of different equipment registers are dynamically adjusted, so that instruction semantics can be intelligently understood, the mapping relation is adaptively learned, and load balancing is realized.

Description

Technical Field

[0001] This invention relates to the field of industrial internet technology, and in particular to an industrial protocol conversion method, device, terminal, and medium. Background Technology

[0002] Against the backdrop of the rapid development of the Industrial Internet of Things and intelligent manufacturing, protocol conversion technology, as a key bridge connecting upper-layer business systems and lower-layer physical devices, is becoming increasingly important.

[0003] With the deepening of Industry 4.0, upper-layer application systems need to interact with various lower-layer industrial devices, which typically communicate using industrial protocols such as Modbus TCP, PROFINET, and OPC-UA. However, a significant semantic gap exists between upper-layer business commands and lower-layer device operations; that is, there is no direct semantic correspondence between the abstract control commands at the business layer and the specific operations that the lower-layer devices need to perform. Furthermore, existing industrial protocol conversion technologies mainly rely on traditional rule-based mapping methods, such as using predefined static mapping tables or hard-coded conversion logic, and manually configuring the correspondence between upper-layer commands and lower-layer register operations. These methods have the following problems: First, it is highly dependent on manual configuration: engineers need to have a deep understanding of the register layout and operating logic of each device. The configuration process is tedious and error-prone, and the complexity increases exponentially in complex systems with multiple devices working together.

[0004] Second, it lacks generalization and adaptability: when a new equipment type is added or the process flow is modified, it cannot automatically learn the new mapping relationship and must be manually reconfigured, resulting in high maintenance costs.

[0005] Third, it cannot understand deep semantics and context: traditional rule engines have difficulty handling the diversity and ambiguity of instruction expressions, and cannot make intelligent decisions based on process context. For example, the instruction "start transportation" may correspond to different target locations at different stages.

[0006] Fourth, it is difficult to achieve load balancing: In high-concurrency scenarios, all device registers are usually polled at a fixed frequency, which leads to resource waste, high response latency, and difficulty in achieving load balancing.

[0007] Therefore, existing technologies have shortcomings and need to be improved and developed. Summary of the Invention

[0008] The technical problem to be solved by the present invention is to provide an industrial protocol conversion method, device, terminal and medium to address the above-mentioned defects of the prior art. It aims to overcome the defects of existing industrial protocol conversion technologies, such as high dependence on manual configuration, lack of generalization and adaptability, inability to understand deep semantics and context, and difficulty in achieving load balancing, and solve the semantic gap between upper-layer application protocols and lower-layer device protocols in industrial production scenarios.

[0009] The technical solution adopted by this invention to solve the technical problem is as follows: In a first aspect, the present invention discloses an industrial protocol conversion method, wherein the method includes: Semantic entities and physical operation entities are extracted from upstream application protocol messages and downstream industrial equipment protocol messages, respectively, and the comprehensive similarity between the semantic entities and the physical operation entities is calculated. An industrial protocol knowledge graph is constructed based on the comprehensive similarity, and bidirectional conversion between upstream protocol requests and downstream protocol messages is performed based on the knowledge graph. Real-time acquisition of access timing data for each downstream protocol entity; Based on the access time-series data, the access needs of each downstream protocol entity in the future time window are predicted, and the polling strategy and protocol conversion resource allocation for different downstream protocol entities are dynamically adjusted according to the prediction results.

[0010] Optionally, calculating the comprehensive similarity between the semantic entity and the physical operation entity includes: The semantic similarity, structural similarity, and contextual similarity between the semantic entity and the physical operation entity are calculated using a pre-built multi-layer similarity calculation framework. The semantic similarity, structural similarity, and contextual similarity are weighted and summed using a weighted fusion formula to obtain the corresponding comprehensive similarity. The multi-layer similarity calculation framework includes semantic similarity calculation based on pre-trained language models, structural similarity calculation based on grammatical structures, and contextual similarity calculation based on process context.

[0011] Optionally, constructing an industrial protocol knowledge graph based on the comprehensive similarity includes: By using the semantic entities and physical operation entities as nodes and the comprehensive similarity as edge weights, an industrial protocol knowledge graph with edge mapping relationships is constructed.

[0012] Optionally, the real-time acquisition of access time-series data for each downstream protocol entity includes: Real-time collection of historical access frequency data and status change frequency data for each downstream protocol entity.

[0013] Optionally, predicting the access needs of each of the downstream protocol entities within a future time window based on the access time-series data includes: Using a long short-term memory network model, the access demand frequency of each downstream protocol entity within a future time window is predicted based on the access time series data.

[0014] Optionally, the step of dynamically adjusting the polling strategy and protocol conversion resource allocation for different downstream protocol entities based on the prediction results includes: Based on the frequency of access requests, each of the downstream protocol entities is divided into different popularity categories; Differentiated polling thread priorities and polling intervals, as well as protocol conversion resource quotas, are assigned to the downstream protocol entities of different popularity categories.

[0015] Optionally, classifying the downstream protocol entities into different popularity categories based on the access demand frequency includes: When the access demand frequency is not less than the first predicted frequency threshold, the downstream protocol entity is classified as a hot data category. When the access demand frequency is less than the first prediction frequency threshold and not less than the second prediction frequency threshold, the downstream protocol entity is classified as a warm data category. When the access demand frequency is less than the second predicted frequency threshold, the downstream protocol entity is classified as cold data. Specifically, the polling thread priority of the downstream protocol entity of the hot data category is higher than that of the downstream protocol entity of the warm data category and the downstream protocol entity of the cold data category, and the polling thread priority of the downstream protocol entity of the warm data category is higher than that of the downstream protocol entity of the cold data category.

[0016] Secondly, the present invention also discloses an industrial protocol conversion system, wherein the system comprises: The semantic entity extraction module is used to extract semantic entities and physical operation entities from upstream application protocol messages and downstream industrial equipment protocol messages, respectively, and to calculate the comprehensive similarity between the semantic entities and the physical operation entities. An industrial protocol knowledge graph construction module is used to construct an industrial protocol knowledge graph based on the comprehensive similarity, so as to perform bidirectional conversion between upstream protocol requests and downstream protocol messages based on the knowledge graph; An adaptive scheduling parameter adjustment module is used to collect access time sequence data of each downstream protocol entity in real time, predict the access demand of each downstream protocol entity in the future time window based on the access time sequence data, and dynamically adjust the polling strategy and protocol conversion resource allocation for different downstream protocol entities according to the prediction results.

[0017] Thirdly, the present invention discloses a terminal, comprising: a memory, a processor, and an industrial protocol conversion program stored in the memory and executable on the processor, wherein the industrial protocol conversion program, when executed by the processor, implements the steps of the industrial protocol conversion method as described above.

[0018] Fourthly, the present invention discloses a computer-readable storage medium storing a computer program that can be executed to implement the steps of the industrial protocol conversion method as described above.

[0019] This invention provides an industrial protocol conversion method, apparatus, terminal, and medium. The industrial protocol conversion method includes: extracting semantic entities and physical operation entities from upstream application protocol messages and downstream industrial equipment protocol messages, respectively, and calculating the comprehensive similarity between the semantic entities and the physical operation entities; constructing an industrial protocol knowledge graph based on the comprehensive similarity, and performing bidirectional conversion between upstream protocol requests and downstream protocol messages based on the knowledge graph; collecting access time-series data of each downstream protocol entity in real time; predicting the access needs of each downstream protocol entity within a future time window based on the access time-series data, and dynamically adjusting the polling strategy and protocol conversion resource allocation for different downstream protocol entities according to the prediction results. Therefore, this invention extracts semantic entities and physical operation entities from upstream and downstream protocol messages, calculates the comprehensive similarity between the two entities to construct a corresponding industrial protocol knowledge graph, thereby enabling intelligent instruction mapping. Furthermore, based on time-series data analysis, it predicts the access needs of each downstream protocol entity within a future time window, and dynamically adjusts the polling strategy and protocol conversion resource allocation for different downstream protocol entities according to the predicted access needs, achieving an intelligent scheduling strategy and significantly improving system throughput and response efficiency. In other words, the technical solution of this application can intelligently understand instruction semantics, adaptively learn mapping relationships, and achieve load balancing by constructing an industrial protocol knowledge graph and dynamically adjusting the polling frequency of different device registers and the allocation of protocol conversion resources. Attached Figure Description

[0020] Figure 1 This is a schematic diagram illustrating the technological gap between IT and OT in a specific intelligent manufacturing scenario disclosed in this invention; Figure 2 This is a flowchart of a preferred embodiment of the industrial protocol conversion method in this invention; Figure 3 This is a schematic diagram of a specific upper and lower layer protocol disclosed in this invention that constructs a knowledge graph through semantic entity alignment; Figure 4This is a schematic diagram of the overall architecture for entity alignment and adaptive scheduling in an industrial production scenario disclosed in this invention. Figure 5 This is a functional principle block diagram of a preferred embodiment of the industrial protocol conversion system of the present invention; Figure 6 This is a schematic diagram of communication between digital twins and physical production lines in a specific industrial manufacturing scenario disclosed in this invention; Figure 7 This is a functional principle block diagram of a preferred embodiment of the terminal in this invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0022] Currently, with the rapid development of the Industrial Internet of Things and intelligent manufacturing, protocol conversion technology, as a key bridge connecting upper-layer business systems and lower-layer physical devices, is becoming increasingly important.

[0023] With the deepening of Industry 4.0, upper-layer application systems (such as HTTP-based web services, cloud platforms, or mobile applications) need to interact with various lower-layer industrial devices (such as PLCs, sensors, actuators, etc.). These devices typically communicate using industrial protocols such as Modbus TCP, PROFINET, and OPC-UA. However, there is a significant semantic gap between upper-layer business commands and lower-layer device operations. That is, there is no direct semantic correspondence between abstract control commands at the business layer (such as "start AGV" or "conveyor belt starts transport," in the form of JSON data structures in HTTP messages) and the specific operations that the lower-layer devices need to perform (such as writing control words to specific register addresses or reading sensor status).

[0024] Taking a production line for laser engraving and packaging products as an example, this line involves multiple collaborative subsystems, including the scheduling of multiple workstations such as robotic arms, AGVs (Automated Guided Vehicles), conveyor belts, engraving machines, and packaging tables. In this complex process, business instructions issued by the upper-level production management system (such as "start engraving process" and "packaging complete") need to be accurately translated into specific operations of the underlying equipment, including writing a start signal to register address 0x0001, reading the engraving status to register 0x0010, and sending movement coordinates to the AGV controller in the Modbus TCP protocol. This multi-level, multi-device collaborative operation places extremely high demands on the accuracy and intelligence of protocol conversion.

[0025] However, existing industrial protocol conversion technologies mainly rely on traditional rule-based mapping methods, such as using predefined static mapping tables or hard-coded conversion logic, and establishing the correspondence between upper-layer instructions and lower-layer register operations through manual configuration. However, these methods have the following problems: First, it is highly dependent on manual configuration: engineers need to have a deep understanding of the register layout and operating logic of each device. The configuration process is tedious and error-prone, and the complexity increases exponentially in complex systems with multiple devices working together.

[0026] Second, it lacks generalization and adaptability: when a new equipment type is added or the process flow is modified, it cannot automatically learn the new mapping relationship and must be manually reconfigured, resulting in high maintenance costs.

[0027] Third, it cannot understand deep semantics and context: traditional rule engines have difficulty handling the diversity and ambiguity of instruction expressions, and cannot make intelligent decisions based on process context. For example, the instruction "start transportation" may correspond to different target locations at different stages.

[0028] Fourth, it is difficult to achieve load balancing: In high-concurrency scenarios, all device registers are usually polled at a fixed frequency, which leads to resource waste, high response latency, and difficulty in achieving load balancing.

[0029] Existing technologies still struggle to handle the diversity and ambiguity of instruction expressions. For example, "start engraving" and "start laser processing" are semantically equivalent, but existing technologies require additional manual process streamlining and instruction alignment. Treating them as different instructions can lead to conversion failures or misoperations, severely restricting the level of intelligence and operational efficiency of industrial systems.

[0030] For example, existing methods for protocol description based on XML Schema and semantic mapping frameworks based on ontology remain at the proof-of-concept stage, lacking large-scale application in real-world industrial scenarios. Alternatively, solutions for secure conversion of industrial protocols are still based on rule engines rather than semantic understanding. These existing technologies exhibit significant limitations when handling complex production line scenarios. While there is considerable research in entity alignment and semantic mapping in academia, primarily focusing on knowledge graph-based semantic modeling of industrial equipment and constructing industrial protocol frameworks using ontology, and IoT ontology alignment research providing some theoretical foundation for semantic interoperability between industrial devices, most of this research is still in the laboratory stage and has not yet developed into mature industrial-grade solutions. Especially in complex scenarios involving multi-device, multi-process production line scheduling, existing academic achievements still fall short in terms of generalization, robustness, and real-time performance.

[0031] For details, see Figure 1The diagram illustrates the communication flow between a web-based digital twin dashboard and a physical production line PLC workstation in a typical industrial manufacturing scenario. The operator issues operation requests through the digital twin system, which are then routed to the production line backend (i.e., the host computer) to send control commands. The goal is to control the underlying physical equipment, specifically the PLC workstation shown in the diagram. Because the production line backend uses the HTTP protocol with JSON-formatted messages, which is inconsistent with the Modbus TCP protocol supported by the underlying physical equipment, protocol parsing and conversion are necessary to align the entities and operations of the two protocols. This enables control and monitoring of the physical production line, while simultaneously feeding back equipment status information to the production line backend and the digital twin system. Furthermore, due to the incomplete information content parity between the HTTP protocol and the Modbus TCP message protocol, a gap exists between Information Technology (IT) and Operation Technology (OT). The upper-level computer / production line backend uses HTTP and JSON formatted information, containing more readable data, while the underlying physical devices use binary bytecode for control. If the middle layer uses inefficient fixed-frequency polling, it suffers from high protocol heterogeneity, poor data interoperability, and high transmission latency. Traditional methods require professional engineers to analyze and match protocols according to the process flow and related technical documents. Adding new processes and protocols necessitates a certain degree of restructuring and integration of hardware and software layouts and systems, making it difficult to quickly converge in high-efficiency production scenarios. In other words, in the Industrial Internet of Things (IIoT) scenario, there are problems such as high protocol heterogeneity, poor data interoperability, high transmission latency, and difficulty in quickly converging restructuring between upper-layer application protocols (e.g., HTTP) and lower-layer device protocols (e.g., Modbus TCP), leading to a semantic gap between upper-layer application protocols and lower-layer device protocols in industrial production scenarios.

[0032] To address this, this application provides an industrial protocol conversion scheme that overcomes the shortcomings of existing industrial protocol conversion technologies, such as high reliance on manual configuration, lack of generalization and adaptability, inability to understand deep semantics and context, and difficulty in achieving load balancing. This scheme solves the semantic gap between upper-layer application protocols and lower-layer device protocols in industrial production scenarios. When implementing industrial protocol conversion, it can intelligently understand instruction semantics, adaptively learn mapping relationships, and achieve load balancing.

[0033] Please see Figure 2 , Figure 2 This is a flowchart of the industrial protocol conversion method in this invention. For example... Figure 2 As shown, the industrial protocol conversion method described in this embodiment of the invention includes: Step S11: Extract semantic entities and physical operation entities from the upstream application protocol message and the downstream industrial equipment protocol message respectively, and calculate the comprehensive similarity between the semantic entity and the physical operation entity.

[0034] In this embodiment, key semantic entities are extracted from upstream and downstream protocol messages to construct a knowledge graph based on semantic entity alignment. Specifically, semantic entities are extracted from upstream application protocol messages, and physical operation entities are extracted from downstream industrial equipment protocol messages. Natural language processing (NLP) and Named Entity Resolving (NER) techniques can be used to extract semantic entities from upstream application protocol messages.

[0035] For example, for upper-layer HTTP protocol messages (i.e., upstream application protocol messages), there are protocol conventions for instruction type, device name, action description, instruction name (such as read, write, subscribe, etc.), and operation parameters (such as the value written to the register, etc.). For JSON messages sent by the host computer during actual production, natural language processing (NLP) and named entity parsing (NER) techniques are used to identify entities such as action words, target devices, operands, and expected ACKs in the control instructions. After the expected ACK is completed, the corresponding registers of the downstream physical production line equipment will undergo state changes. For lower-layer Modbus TCP protocol messages (i.e., downstream industrial equipment protocol messages), by acquiring and identifying fields such as the IP address, port number, device name, register address, function code, and data value of the downstream physical production line equipment, physical operation entities are extracted, including register type (such as holding register, input register, etc.), address range (such as 0x0001-0x0010), data format (such as BOOL, SHORT), and operation semantics (such as writing start signal, reading status value).

[0036] It should be noted that BiLSTM-CRF (Bidirectional Long Short-Term Memory Network-Conditional Random Field) models can also be used for entity recognition. By using pre-trained word vectors from the industrial production field (such as Word2Vec models trained on corpora in the fields of mechanical manufacturing and automation control, and fine-tuning with new entity data in real-world scenarios), the accuracy of entity recognition can be improved, which means that the accuracy and generalization ability of semantic entity recognition can be significantly improved.

[0037] In this embodiment, semantic entities and physical operation entities are extracted from the upstream application protocol message and the downstream industrial equipment protocol message, respectively, and then similarity calculation is performed, that is, the comprehensive similarity between the semantic entities in the upstream application protocol message and the physical operation entities in the downstream industrial equipment is calculated.

[0038] Specifically, a pre-built multi-layer similarity calculation framework is used to calculate the semantic similarity, structural similarity, and contextual similarity between semantic entities and physical operation entities; a weighted fusion formula is used to sum the semantic similarity, structural similarity, and contextual similarity to obtain the corresponding comprehensive similarity; the multi-layer similarity calculation framework includes semantic similarity calculation based on pre-trained language models, structural similarity calculation based on grammatical structures, and contextual similarity calculation based on process context.

[0039] It should also be noted that the multi-layer similarity calculation framework includes semantic similarity calculation based on pre-trained language models. Specifically, it uses pre-trained language models to calculate the semantic vectors of instruction texts and measures the degree of semantic matching through cosine similarity. The use of a semantic understanding framework based on pre-trained language models (such as BERT and RoBERTa) enables the model to have semantic generalization capabilities. The multi-layer similarity calculation framework also includes structural similarity calculation based on grammatical structure. This specifically analyzes the grammatical structure and data dependencies of instructions. For example, in the natural language description of a process flow, "robotic arm grips product to material platform" includes both equipment and actions, and its structural similarity is similar to "write register to data value" in the underlying Modbus TCP protocol message. Finally, the multi-layer similarity calculation framework includes contextual similarity calculation based on process context. This specifically considers the process context of instruction execution. In a process flow, the conveyor belt is started multiple times, but each start has a sequential dependency relationship; this temporal dependency relationship constitutes contextual features.

[0040] Furthermore, the semantic similarity, structural similarity, and contextual similarity between semantic entities and physical operational entities can be used to calculate the comprehensive similarity using a weighted fusion formula, namely: ; in, To assess overall similarity, For semantic similarity, For structural similarity, For context similarity, , , To achieve adaptive weight sparsity, the weights can be dynamically adjusted based on historical matching accuracy.

[0041] Step S12: Construct an industrial protocol knowledge graph based on the comprehensive similarity, and perform bidirectional conversion between upstream protocol requests and downstream protocol messages based on the knowledge graph.

[0042] Understandably, by extracting semantic entities and physical operation entities from the instruction sets of upstream and downstream protocols, and then aligning semantic entities with physical operation entities, the semantic similarity, structural similarity, and contextual similarity between semantic entities and physical operation entities are calculated to obtain a comprehensive similarity. Based on this comprehensive similarity, an industrial protocol knowledge graph of upstream application protocol messages and downstream industrial equipment protocol messages is constructed, thereby mapping upstream application protocols to downstream industrial equipment protocols and achieving matching of upstream and downstream protocol requests or messages. Compared to traditional manual hard-configuration of data mapping tables or matching through regular expressions, this embodiment improves the efficiency of message conversion and instruction mapping between upstream and downstream protocols through intelligent entity matching and alignment. It can handle the diversity of instruction expressions, significantly improves processing efficiency, and helps industrial production achieve equipment interconnection and digital upgrade of production processes. Moreover, compared to existing general entity matching and alignment algorithms, the intelligent entity matching and alignment in this embodiment also has practical application capabilities, and it has better capabilities in handling the diversity and ambiguity of complex scenarios involving multi-step processes and multi-equipment entity collaboration in industrial manufacturing.

[0043] Furthermore, in this embodiment, semantic entities and physical operation entities are specifically used as nodes, and the comprehensive similarity is used as the edge weight to construct an industrial protocol knowledge graph with edges representing mapping relationships. It can be understood that the industrial protocol knowledge graph is constructed based on the calculation results of comprehensive similarity, where nodes represent protocol entities (such as HTTP commands, Modbus registers, device names, read / write commands, etc.), edges represent mapping relationships, and edge weights are the comprehensive similarity values. This industrial protocol knowledge graph supports real-time querying, thereby enabling accurate semantic mapping and adaptive learning across protocol commands.

[0044] It should be noted that when adding new instructions, implicit relationships can be discovered through context similarity analysis and the graph structure characteristics of the knowledge graph. This allows for the rapid learning of the corresponding process flow relationships, upstream HTTP message protocol information, and downstream physical production line Modbus addresses and operands.

[0045] For example, in a production line, based on this industrial protocol knowledge graph, the "start conveyor belt" instruction can be mapped to the process step of "products are sent from the AGV cart to the finished product station via the conveyor belt", and accurately mapped to the AGV cart IP, its conveyor belt control register Modbus address 0x0005, and the direction of the conveyor belt can be controlled by the written operation parameter values.

[0046] For example, see Figure 3As shown, when the HTTP message of the upper-layer protocol is {"sbid": "0102", "cmd": 2, "datas": [{"tag": "popmaterial", "value": 1}]}, it indicates that a write command (cmd=2) is sent to machine number 0102 to write the register value named popmaterial to 1. The operation performed is that the robotic arm retrieves product number 1 from the storage station. When this command is received, the robotic arm 0102 is automatically identified as the target device entity, and "retrieve product" is the action entity. That is, the BiLSTM-CRF model is used to identify the corresponding semantic entities in the HTTP message of the upper-layer protocol to clarify the corresponding entity tags. In the corresponding underlying ModbusTCP protocol, the protocol is parsed to perform address function mapping. That is, it should be mapped to 10.0.0.2 as the robotic arm IP, 0x0016 as the robotic arm status register, function code 0x06 as the write register, and data value 0x0001 as the start signal and tag number. Then, metadata association is performed, semantic annotation is performed, and finally a knowledge graph is constructed.

[0047] Step S13: Collect access timing data of each downstream protocol entity in real time.

[0048] In this embodiment, time-series data is collected in real time. Specifically, historical access frequency data and status change frequency data of each downstream protocol entity are collected in real time. It can be understood that two types of time-series data are collected in real time: historical access frequency data (i.e., request frequency data): recording the historical access timestamps of each Modbus register and calculating the request frequency within the sliding window; and status change frequency data (i.e., device status change frequency characteristics): recording the frequency of value changes in each Modbus ACK register and analyzing the frequency and periodicity of status bit changes.

[0049] Step S14: Based on the access time sequence data, predict the access needs of each downstream protocol entity in the future time window, and dynamically adjust the polling strategy and protocol conversion resource allocation for different downstream protocol entities according to the prediction results.

[0050] In this embodiment, after collecting the access time sequence data of each downstream protocol entity in real time, the access needs of each downstream protocol entity in the future time window can be predicted based on this data, and the polling strategy and protocol conversion resource allocation can be dynamically adjusted.

[0051] In this embodiment, predicting the access needs of each downstream protocol entity within a future time window based on access time-series data can specifically include: using a Long Short-Term Memory (LSTM) network model to predict the access frequency of each downstream protocol entity within a future time window based on access time-series data. It is understood that the access logs and value changes of each register can be collected every second by a data collector, and the LSTM model (i.e., the Long Short-Term Memory network model) predicts the access frequency of each register within a short future period based on the collected historical time-series data.

[0052] Furthermore, in this embodiment, the polling strategy and protocol conversion resource allocation for different downstream protocol entities are dynamically adjusted based on the prediction results. Specifically, this may include: classifying each downstream protocol entity into different popularity categories based on the access demand frequency; and allocating differentiated polling thread priorities, polling intervals, and protocol conversion resource quotas to downstream protocol entities of different popularity categories. It is understood that by monitoring production line time-series data in real time, the load of the protocol conversion program on different instruction processing can be dynamically adjusted even when there are significant differences in the concurrency of upstream and downstream requests and responses, thereby achieving load balancing by using different scheduling frequencies for hot and cold data requests.

[0053] It should be noted that when the access demand frequency is not less than the first prediction frequency threshold, the downstream protocol entity is classified as a hot data category; when the access demand frequency is less than the first prediction frequency threshold but not less than the second prediction frequency threshold, the downstream protocol entity is classified as a warm data category; when the access demand frequency is less than the second prediction frequency threshold, the downstream protocol entity is classified as a cold data category. Among these, the polling thread priority of the downstream protocol entity in the hot data category is higher than that of the downstream protocol entity in the warm data category and the downstream protocol entity in the cold data category, and the polling thread priority of the downstream protocol entity in the warm data category is higher than that of the downstream protocol entity in the cold data category.

[0054] For example, the first prediction frequency threshold can be 20Hz, and the second prediction frequency threshold can be 1Hz. Based on the prediction results, registers can be divided into three categories: hot data (prediction frequency > 20Hz), warm data (1Hz < frequency < 20Hz), and cold data (frequency < 1Hz). Different polling threads and protocol conversion resource quotas are allocated to different categories. Hot data registers are assigned dedicated high-priority threads, while cold data registers are polled in batches. Finally, the system load is monitored in real time. When CPU utilization exceeds 80%, the polling frequency of cold data registers is automatically reduced, allocating resources to hot data registers. This achieves dynamic optimization of resource allocation and a significant improvement in system throughput. Furthermore, compared to traditional protocols that detect data through a fixed high-frequency polling method, this embodiment uses time-series analysis and traffic prediction to dynamically adjust parameters, distinguishing between "hot" and "cold" protocol requests, and achieving load balancing under high concurrency of protocol data.

[0055] In the simulated production line test, 15% of the registers were identified as hot data categories and 30% as warm data categories. The polling interval for cold data category registers was adjusted from a fixed 1 second to a periodic polling of 5 times per second every 30 seconds. Through resource allocation, the response latency of hot data category registers can be reduced from polling every 100ms to 10ms. Under simulated high-load scenarios, the CPU utilization fluctuation range can be stabilized from 40% to 95% to 60% to 75%, effectively avoiding resource overload and waste.

[0056] As can be seen, in this embodiment of the invention, semantic entities and physical operation entities are extracted from upstream and downstream protocol messages, and the comprehensive similarity between the two entities is calculated to construct a corresponding industrial protocol knowledge graph. This enables intelligent instruction mapping. Furthermore, based on time-series data analysis, the access needs of each downstream protocol entity within future time windows are predicted. The polling strategies and protocol conversion resource allocations of different downstream protocol entities are dynamically adjusted according to the predicted access needs, achieving an intelligent scheduling strategy and significantly improving system throughput and response efficiency. In other words, the technical solution of this application, by constructing an industrial protocol knowledge graph and dynamically adjusting the polling frequency of different device registers and the allocation of protocol conversion resources, can intelligently understand instruction semantics, adaptively learn mapping relationships, and achieve load balancing.

[0057] For example, in the construction of industrial production lines that involve multi-step, multi-device collaborative operations, the technical solution of this invention aims to solve the semantic gap between upper-layer application protocols and lower-layer device protocols in industrial production scenarios, while optimizing system performance under high-concurrency scenarios. See also Figure 4As shown, the technical solution of this invention mainly includes "industrial protocol conversion technology based on semantic entity alignment to construct a knowledge graph" and "adaptive scheduling parameter adjustment technology". Through machine learning models, semantic analysis of upstream and downstream protocol instructions can be performed to construct an industrial protocol knowledge graph containing semantic, structural, and contextual relationships, achieving intelligent instruction mapping. Simultaneously, based on time-series data analysis, the polling frequency of different device registers and the allocation of protocol conversion resources are dynamically adjusted to achieve an intelligent scheduling strategy of "separating hot and cold data", significantly improving system throughput and response efficiency.

[0058] In one embodiment, such as Figure 5 As shown, based on the above-described industrial protocol conversion method, the present invention also provides an industrial protocol conversion system, comprising: The semantic entity extraction module 11 is used to extract semantic entities and physical operation entities from upstream application protocol messages and downstream industrial equipment protocol messages, respectively, and calculate the comprehensive similarity between the semantic entities and the physical operation entities. The industrial protocol knowledge graph construction module 12 is used to construct an industrial protocol knowledge graph based on the comprehensive similarity, so as to perform bidirectional conversion between upstream protocol requests and downstream protocol messages based on the knowledge graph; The adaptive scheduling parameter adjustment module 13 is used to collect access time sequence data of each downstream protocol entity in real time, predict the access demand of each downstream protocol entity in the future time window based on the access time sequence data, and dynamically adjust the polling strategy and protocol conversion resource allocation for different downstream protocol entities according to the prediction results.

[0059] In some specific embodiments, the semantic entity extraction module 11 may specifically include: The similarity calculation unit is used to calculate the semantic similarity, structural similarity and contextual similarity between the semantic entity and the physical operation entity using a pre-built multi-layer similarity calculation framework; The weighted summation unit is used to perform a weighted summation of the semantic similarity, the structural similarity, and the contextual similarity using a weighted fusion formula to obtain the corresponding comprehensive similarity. The multi-layer similarity calculation framework includes semantic similarity calculation based on pre-trained language models, structural similarity calculation based on grammatical structures, and contextual similarity calculation based on process context.

[0060] In some specific embodiments, the industrial protocol knowledge graph construction module 12 may specifically include: The knowledge graph construction unit is used to construct an industrial protocol knowledge graph with the semantic entities and physical operation entities as nodes and the comprehensive similarity as the edge weights.

[0061] In some specific embodiments, the adaptive scheduling parameter adjustment module 13 may specifically include: The frequency data acquisition unit is used to collect historical access frequency data and status change frequency data of each downstream protocol entity in real time.

[0062] In some specific embodiments, the adaptive scheduling parameter adjustment module 13 may specifically include: The access demand prediction unit based on the LSTM model is used to predict the access demand frequency of each downstream protocol entity in a future time window based on the access time series data using a long short-term memory network model.

[0063] In some specific embodiments, the adaptive scheduling parameter adjustment module 13 may specifically include: A popularity category division unit is used to divide each of the downstream protocol entities into different popularity categories based on the access demand frequency. The allocation unit is used to allocate differentiated polling thread priorities and polling intervals, as well as protocol conversion resource quotas, to the downstream protocol entities of different popularity categories.

[0064] In some specific embodiments, the heat category division unit may specifically include: The hot data category division subunit is used to classify the downstream protocol entity into a hot data category when the access demand frequency is not less than the first prediction frequency threshold. The warm data category division subunit is used to classify the downstream protocol entity into the warm data category when the access demand frequency is less than the first prediction frequency threshold and not less than the second prediction frequency threshold. The cold data category division subunit is used to classify the downstream protocol entity into a cold data category when the access demand frequency is less than the second prediction frequency threshold. Specifically, the polling thread priority of the downstream protocol entity of the hot data category is higher than that of the downstream protocol entity of the warm data category and the downstream protocol entity of the cold data category, and the polling thread priority of the downstream protocol entity of the warm data category is higher than that of the downstream protocol entity of the cold data category.

[0065] Furthermore, it is worth noting that the working process of the industrial protocol conversion system provided in this embodiment is the same as that of the industrial protocol conversion method described above, and will not be repeated here. For details, please refer to the working process of the industrial protocol conversion method described above.

[0066] The industrial protocol conversion system can be deployed on edge devices, such as industrial edge servers. The semantic entity extraction module can use the PyTorch framework to implement the BiLSTM-CRF model. The industrial protocol knowledge graph can use Neo4j, and the adaptive scheduling parameter adjustment module can be developed based on Python's APScheduler library. Furthermore, the HTTP service can use FastAPI and uvicorn to support high-concurrency scenarios, and Modbus communication can use the pymodbus library. In the distributed semantic mapping architecture, semantic understanding execution is deployed on edge computing nodes, while the learning and optimization of mapping rules are centralized on the cloud platform. Knowledge sharing across devices and production lines is achieved through cloud-based data aggregation.

[0067] It should be noted that for resource-constrained edge devices, instructions, messages, industrial protocol knowledge graphs, and LSTM predictions can be deployed in the cloud. Edge devices retain only lightweight inference and physical device control capabilities, synchronizing critical data via the MQTT protocol. Furthermore, given sufficient computing power on the edge devices, a federated learning architecture can be adopted. Each edge device uses a smaller-scale network model for graph construction and time-series prediction, while the central server aggregates the models from all edge devices. Additionally, reinforcement learning strategies can be employed in resource scheduling, using system load, request latency, and data change rate as state inputs, and resource allocation ratios as action outputs. The polling strategy is optimized through a reward function (throughput - latency).

[0068] It should also be noted that the adaptive scheduling parameter adjustment module 13 performs intelligent scheduling based on the "mapping relationship after protocol conversion". The adaptive scheduling parameter adjustment module 13 does not directly perceive the upper-layer protocol, but rather, through the constructed and used industrial protocol knowledge graph, it learns which downstream protocol entities (registers) are frequently accessed and which belong to critical equipment, thus distinguishing between hot data, warm data, and cold data. By real-time monitoring and collecting the historical access sequence of downstream protocol entities (registers), it predicts the probability of their future access and adjusts the polling frequency and computing resource allocation for that entity accordingly. Therefore, the adaptive scheduling parameter adjustment module 13 essentially optimizes the downstream communication links during the protocol conversion process, ensuring that the system can still quickly respond to critical instructions in high-concurrency scenarios, while avoiding unnecessary polling of non-critical registers, thereby improving system throughput and reducing latency. Furthermore, for forwarding from upper-layer protocols to lower-layer protocols, the industrial protocol conversion system of this invention can, in a pre-built microservice-based architecture, efficiently send HTTP requests from upper-layer protocols to the lower-layer production line through event-driven listening, without needing to actively poll and scan for incoming HTTP requests. However, when listening for messages from the lower-level production line and sending them to the upper level, the lower-level physical devices cannot send messages to the protocol conversion system through event-driven mechanisms. The system needs to actively poll and scan the registers of the lower-level production line.

[0069] For example, in laser engraving and product packaging production lines, the upstream digital twin system and the host computer send operation requests. In this embodiment, the industrial protocol conversion system can receive HTTP instructions from the MES system through REST API, convert them into Modbus TCP messages, and send them to the device controller. At the same time, it feeds back the device status to the host computer in real time.

[0070] For example, see Figure 6As shown, in a product packaging production line scenario, clicking the "Start" button on the digital twin screen sends a request to the production line backend (host computer). When the HTTP message used by the production line backend is {"sbid": "0102", "cmd": 2, "datas": [{"tag": "popmaterial", "value": 1}]}, it indicates that a write command (cmd=2) is sent to machine number 0102 to write the register value named popmaterial to 1. The semantics are that the robotic arm retrieves product number 1 from the storage station. When the protocol parsing and conversion system (i.e., the industrial protocol conversion system) receives this command, it uses the industrial knowledge graph constructed through semantic entity alignment to match "robotic arm 0102" as the target device entity (i.e., sbid=0102, whose IP address on the physical production line is 10.0.0.2), "retrieve product" as the action entity (i.e., popmaterial, whose register address on the physical production line is 0x0016), "write single register" as the actual command operation (corresponding to function code 0x06 on the physical production line), and the data value 0x0001 as the start signal and tag number. Through the above matching and conversion process, the HTTP message is converted into a Modbus TCP message and sent to the PLC workstation. When the PLC workstation completes its current operation, it automatically sets the corresponding ACK register to 1 (in this operation, corresponding to ackpopmaterial). The protocol parsing and conversion system needs to monitor the value change of this register in real time. When the value changes from 0 to 1, it matches the "product retrieval action completed" entity using the industrial knowledge graph, matches it with the ACK signal of the upper-layer protocol, and encapsulates it into an HTTP message. {"type":"ack",datas:[{"tag":"ackpopmaterial","value":1}]} The HTTP message is sent to the production line backend. After receiving the message, the production line backend displays the results and equipment status on the digital twin screen.

[0071] As can be seen, in this embodiment of the invention, semantic entities and physical operation entities are extracted from upstream and downstream protocol messages, and the comprehensive similarity between the two entities is calculated to construct a corresponding industrial protocol knowledge graph. This enables intelligent instruction mapping. Furthermore, based on time-series data analysis, the access needs of each downstream protocol entity within future time windows are predicted. The polling strategies and protocol conversion resource allocations of different downstream protocol entities are dynamically adjusted according to the predicted access needs, achieving an intelligent scheduling strategy and significantly improving system throughput and response efficiency. In other words, the technical solution of this application, by constructing an industrial protocol knowledge graph and dynamically adjusting the polling frequency of different device registers and the allocation of protocol conversion resources, can intelligently understand instruction semantics, adaptively learn mapping relationships, and achieve load balancing.

[0072] Figure 7 A schematic diagram of the structure of a terminal provided in an embodiment of this application. The terminal may include: The memory 501, the processor 502, and the computer program stored on the memory 501 and capable of running on the processor 502.

[0073] When the processor 502 executes the program, it implements the industrial protocol conversion method provided in the above embodiments.

[0074] Furthermore, the terminal also includes: Communication interface 503 is used for communication between memory 501 and processor 502.

[0075] The memory 501 is used to store computer programs that can run on the processor 502.

[0076] Memory 501 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0077] If the memory 501, processor 502, and communication interface 503 are implemented independently, they can be interconnected via a bus to communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, only one line is used in the diagram, but this does not imply that there is only one bus or one type of bus.

[0078] Optionally, in a specific implementation, if the memory 501, processor 502, and communication interface 503 are integrated on a single chip, then the memory 501, processor 502, and communication interface 503 can communicate with each other through an internal interface.

[0079] Processor 502 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0080] This embodiment also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described industrial protocol conversion method.

[0081] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of the invention are indicated by the claims.

[0082] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0083] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can read and execute instructions from and from an instruction execution system, apparatus or device).

[0084] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. If implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0085] It should be understood that the application of the present invention is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. An industrial protocol conversion method, characterized in that, The method includes: Semantic entities and physical operation entities are extracted from upstream application protocol messages and downstream industrial equipment protocol messages, respectively, and the comprehensive similarity between the semantic entities and the physical operation entities is calculated. An industrial protocol knowledge graph is constructed based on the comprehensive similarity, and bidirectional conversion between upstream protocol requests and downstream protocol messages is performed based on the knowledge graph. Real-time acquisition of access timing data for each downstream protocol entity; Based on the access time-series data, the access needs of each downstream protocol entity in the future time window are predicted, and the polling strategy and protocol conversion resource allocation for different downstream protocol entities are dynamically adjusted according to the prediction results.

2. The industrial protocol conversion method according to claim 1, characterized in that, The calculation of the comprehensive similarity between the semantic entity and the physical operation entity includes: The semantic similarity, structural similarity, and contextual similarity between the semantic entity and the physical operation entity are calculated using a pre-built multi-layer similarity calculation framework. The semantic similarity, structural similarity, and contextual similarity are weighted and summed using a weighted fusion formula to obtain the corresponding comprehensive similarity. The multi-layer similarity calculation framework includes semantic similarity calculation based on pre-trained language models, structural similarity calculation based on grammatical structures, and contextual similarity calculation based on process context.

3. The industrial protocol conversion method according to claim 1, characterized in that, The construction of the industrial protocol knowledge graph based on the comprehensive similarity includes: By using the semantic entities and physical operation entities as nodes and the comprehensive similarity as edge weights, an industrial protocol knowledge graph with edge mapping relationships is constructed.

4. The industrial protocol conversion method according to claim 1, characterized in that, The real-time acquisition of access time-series data for each downstream protocol entity includes: Real-time collection of historical access frequency data and status change frequency data for each downstream protocol entity.

5. The industrial protocol conversion method according to any one of claims 1 to 4, characterized in that, The prediction of the access needs of each downstream protocol entity within a future time window based on the access time-series data includes: Using a long short-term memory network model, the access demand frequency of each downstream protocol entity within a future time window is predicted based on the access time series data.

6. The industrial protocol conversion method according to claim 5, characterized in that, The dynamic adjustment of the polling strategy and protocol conversion resource allocation for different downstream protocol entities based on the prediction results includes: Based on the frequency of access requests, each of the downstream protocol entities is divided into different popularity categories; Differentiated polling thread priorities and polling intervals, as well as protocol conversion resource quotas, are assigned to the downstream protocol entities of different popularity categories.

7. The industrial protocol conversion method according to claim 6, characterized in that, The process of classifying downstream protocol entities into different popularity categories based on the frequency of access requests includes: When the access demand frequency is not less than the first predicted frequency threshold, the downstream protocol entity is classified as a hot data category. When the access demand frequency is less than the first prediction frequency threshold and not less than the second prediction frequency threshold, the downstream protocol entity is classified as a warm data category. When the access demand frequency is less than the second predicted frequency threshold, the downstream protocol entity is classified as cold data. Specifically, the polling thread priority of the downstream protocol entity of the hot data category is higher than that of the downstream protocol entity of the warm data category and the downstream protocol entity of the cold data category, and the polling thread priority of the downstream protocol entity of the warm data category is higher than that of the downstream protocol entity of the cold data category.

8. An industrial protocol conversion system, characterized in that, The system includes: The semantic entity extraction module is used to extract semantic entities and physical operation entities from upstream application protocol messages and downstream industrial equipment protocol messages, respectively, and to calculate the comprehensive similarity between the semantic entities and the physical operation entities. An industrial protocol knowledge graph construction module is used to construct an industrial protocol knowledge graph based on the comprehensive similarity, so as to perform bidirectional conversion between upstream protocol requests and downstream protocol messages based on the knowledge graph; An adaptive scheduling parameter adjustment module is used to collect access time sequence data of each downstream protocol entity in real time, predict the access demand of each downstream protocol entity in the future time window based on the access time sequence data, and dynamically adjust the polling strategy and protocol conversion resource allocation for different downstream protocol entities according to the prediction results.

9. A terminal, characterized in that, include: The memory, the processor, and an industrial protocol conversion program stored on the memory and executable on the processor, wherein the industrial protocol conversion program, when executed by the processor, implements the steps of the industrial protocol conversion method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that can be executed to implement the steps of the industrial protocol conversion method as described in any one of claims 1 to 7.

Images