Industrial computer multi-protocol adaptive control system based on edge computing

Abstract

The application relates to an edge-computing-based industrial computer multi-protocol adaptive control system, which relates to the technical field of industrial automation control, and is used for performing three-level progressive protocol identification on new industrial equipment connected to an industrial network diagram, acquiring the communication protocol of the new industrial equipment or marking the new industrial equipment as a protocol unknown state; constructing a reverse representation tree of each communication protocol, performing protocol analysis on the new industrial equipment marked as the protocol unknown state based on the reverse representation tree, and performing protocol analysis on the new industrial equipment with a known communication protocol based on a Docker container image; dynamically converting the analysis result of the new industrial equipment according to real-time state data of the new industrial equipment and preset protocol conversion rules; setting an adaptive buffer area and a dynamic priority of a target device according to the communication protocol of the new industrial equipment; and performing temporary dynamic feedback detection on the new industrial equipment with a temporary dynamic feedback detection mechanism, so that the accuracy and efficiency of a multi-protocol identification process are significantly improved.

Description

Technical Field

[0001] This invention relates to the field of industrial automation control technology, specifically to an industrial computer multi-protocol adaptive control system based on edge computing. Background Technology

[0002] Chinese Patent Publication No. CN119232763A discloses an industrial control ring network monitoring system and its monitoring method, comprising: a data acquisition module for acquiring industrial control ring network data packets in the industrial control network; a data processing module for cleaning and organizing the acquired data, and performing protocol matching on the data packets to identify the industrial protocols in the data packets; and a data identification module for performing protocol matching on the data in the network data packets to identify the communication data of each network packet.

[0003] Chinese patent CN115190191A discloses a power grid industrial control system and control method based on protocol parsing, including: acquiring the protocol data stream generated by the communication between the controller of the power grid industrial control system and the host computer in real time; periodically parsing the acquired protocol data stream and encapsulating and reporting it; decapsulating the parsing results of the encapsulated and reported data stream, monitoring the behavioral characteristics of the specified fields of the decapsulated protocol data stream, and determining whether there is an anomaly in the protocol data stream; when the protocol data stream is determined to be abnormal, terminating the control process, alarm, and log recording of the power grid industrial control system, and transmitting the alarm information and log information to the terminal module.

[0004] Traditional industrial control systems rely on predefined protocol libraries, making it difficult to dynamically identify and be compatible with devices using unknown protocols. Adding new devices requires manual configuration of protocol parameters, resulting in low efficiency and poor scalability. Traditional systems lack adaptive mechanisms, failing to dynamically adjust buffer capacity and priority based on device communication characteristics, easily leading to data congestion or delays in critical business operations. When multiple devices communicate concurrently, network performance becomes unstable, impacting system reliability. Furthermore, existing systems rely on manual reverse engineering to parse unknown protocols, which is time-consuming and costly, hindering rapid response to new device access requirements. Enterprises must develop separate parsing modules for each new protocol, extending system deployment cycles. Additionally, existing systems lack real-time monitoring and dynamic feedback of device communication status, failing to promptly detect protocol misjudgments or network anomalies. Fixed protocol conversion rules prevent dynamic adjustment of conversion strategies based on real-time device status. Summary of the Invention

[0005] To address the aforementioned technical problems, the present invention aims to provide an industrial computer multi-protocol adaptive control system based on edge computing, comprising an industrial computer control center and edge computing nodes. The industrial computer control center is connected to several industrial devices in a distributed manner through the edge computing nodes. The edge computing nodes include a protocol identification module, a protocol parsing module, a protocol conversion module, an adaptive buffer management module, and a dynamic feedback detection module.

[0006] The protocol identification module is used to perform CRC matching and address feature Bayes classification on new industrial equipment connected to the industrial network graph. Based on the matching results, it sets a temporary dynamic feedback detection mechanism or performs lightweight feature matching on the new industrial equipment to obtain the communication protocol of the new industrial equipment or marks the new industrial equipment as having an unknown protocol.

[0007] The protocol parsing module is used to construct the reverse representation tree of each communication protocol, obtain the tree structure features, node attribute features, sequence features and Docker container images of each communication protocol, perform protocol parsing based on the reverse representation tree for new industrial equipment marked as having unknown protocol status, and perform protocol parsing based on the Docker container image for new industrial equipment with known communication protocols.

[0008] The protocol conversion module is used to collect real-time status data of new industrial equipment and dynamically convert the parsing results of the new industrial equipment according to the real-time status data and preset protocol conversion rules.

[0009] The adaptive buffer management module is used to set the adaptive buffer area and dynamic priority of the target device according to the communication protocol of the new industrial equipment;

[0010] The dynamic feedback detection module is used to perform temporary dynamic feedback detection on new industrial equipment with a temporary dynamic feedback detection mechanism.

[0011] Furthermore, the communication connection relationships between several industrial devices are obtained. These industrial devices are treated as nodes, and the communication connection relationships between them are used as the connection relationships between nodes to construct an industrial network graph. The industrial network graph is then used for real-time detection of new industrial device access. The network scanning tool Nmap is used to scan the IP address ranges of each industrial device in the industrial network graph to identify the IP addresses of existing industrial devices and the IP addresses of newly connected industrial devices. When a new industrial device is detected to be connected to the industrial network graph, the data generated by the new industrial device is packaged into a data packet and uploaded to the protocol identification module.

[0012] Furthermore, the protocol identification module performs CRC matching and address feature Bayesian classification on new industrial equipment accessing the industrial network graph. Based on the matching results, the process of setting up a temporary dynamic feedback detection mechanism or performing lightweight feature matching on the new industrial equipment includes:

[0013] Construct a public protocol fingerprint database, which includes CRC features and address features corresponding to several public protocols. The CRC features include CRC generator polynomial, initial value, check bit length, etc., and the address features include address value, address range, encoding rules, etc.

[0014] The data generated by the new industrial equipment is packaged into data packets. Feature extraction is performed on the data packets to obtain target CRC features and target address features. The target CRC features are input into the public protocol fingerprint database for CRC matching. Public protocols whose CRC features match the target CRC features are selected from the public protocol fingerprint database. The public protocols are classified according to address features based on the target address features to obtain the posterior probability that the target address features belong to each public protocol.

[0015] The specific process of performing address feature Bayesian classification on the public protocols based on the target address features to obtain the probability that the target address features belong to each public protocol includes:

[0016] Let C represent the public protocol category, and X represent the target address characteristics (such as address value, address range, encoding rules, etc.). Convert the target address characteristics X into a discrete feature vector. For example, address range (4x / 3x / 0x / 1x), register type (holding register / input register), slave address (0x0100-0x01FF), PDO mapped address (0x1C10-0x1C13). Vectorize the target address characteristics as follows: ,in For binary features (such as "whether it belongs to a Modbus4x register"), n represents the number of discrete feature vectors;

[0017] Since the address features of each public protocol are independent, a simplified posterior probability formula is constructed:

[0018] ;

[0019] in, Let X represent the posterior probability that the target address feature X belongs to the public protocol C. Let be the prior probability, representing the probability of the public protocol C appearing in the industrial network graph. Let be the likelihood, representing the target address characteristics generated by the public protocol C. The probability of;

[0020] A preset posterior probability judgment threshold is set to filter out the public protocol with the highest posterior probability. The posterior probability of the public protocol is compared with the posterior probability judgment threshold. If the posterior probability of the public protocol is greater than or equal to the posterior probability judgment threshold, the public protocol is marked as the communication protocol of the new industrial equipment. A temporary dynamic feedback detection mechanism is set for the new industrial equipment. If the posterior probability of the public protocol is less than the posterior probability judgment threshold, lightweight feature matching is performed.

[0021] If no public protocol fingerprint database contains a corresponding CRC feature that matches the target CRC feature, then lightweight feature matching is performed.

[0022] Furthermore, the lightweight feature matching process includes:

[0023] Collect several consecutive data packets generated by new industrial equipment, perform multi-dimensional feature extraction on the consecutive data packets to generate time feature vector, structural feature vector and data content feature vector, and extract features based on the CRC matching results and address feature Bayes classification results of the new industrial equipment to obtain protocol fingerprint features;

[0024] A private protocol identification model is built based on a lightweight CNN+LSTM. The model is input with time feature vector, structural feature vector, data content feature vector and protocol fingerprint features. The model outputs the confidence scores of several private protocols.

[0025] A pre-set confidence threshold is used to filter out the private protocols with the highest confidence. The confidence of the private protocol is compared with the confidence threshold. If the confidence is greater than or equal to the confidence threshold, the private protocol is marked as the communication protocol of the new industrial equipment. If the confidence is less than the confidence threshold, the new industrial equipment is marked as having an unknown protocol.

[0026] The time feature vector includes the frame interval mean, frame interval standard deviation, frame interval maximum, and frame interval minimum; the structural feature vector includes the frame length and the number of fields; the data content feature vector includes the data field entropy value and the frequency of special values ​​(such as 0xFF (Modbus broadcast address) and 0x0000 (initial value)); and the protocol fingerprint features include the matching degree between the target CRC feature and the CRC features of each public protocol in the public protocol fingerprint database, and the posterior probability of each public protocol.

[0027] Furthermore, based on the CRC matching results of the new industrial equipment and during the feature extraction process, a hierarchical scoring method is used to obtain the matching degree between the target CRC feature and the CRC features of various public protocols in the public protocol fingerprint database. For example, weights are assigned according to parameter importance (example weights: polynomial 40%, bit length 20%, byte order 20%, initial value 15%, check position 5%) to obtain the target CRC feature. Step 1: Match the bit length. The bit length must be the same; otherwise, it is directly excluded (e.g., if the target is a 16-bit CRC, the matching degree of CAN bus (15-bit) is 0%). Step 2: Match the polynomial. A perfect polynomial match earns full marks; otherwise, points are deducted based on the Hamming distance (binary difference bits). (For example, if the target polynomial 0x8005 (binary 1000 0000 0000 0101) is completely identical to Modbus, it scores 100%; however, it differs from Zigbee's 0x1021 (0001 0000 0010 0001) by 6 bits, resulting in a score of 1 - 6 / 16 = 62.5%). Step 3: Match byte order, initial value, and checksum position. Byte order: 100% if the high and low bits are identical, otherwise 0%. Initial value: 100% if the hexadecimal values ​​are identical, otherwise points are deducted proportionally based on the difference. Checksum position: 100% if the positions are identical (e.g., both are at the end of the frame), otherwise 0%. Step 4: Calculate the weighted total match rate. .

[0028] Furthermore, the protocol parsing module constructs inverse representation trees for each communication protocol, and the process of obtaining the tree structure features, node attribute features, sequence features, and Docker container images for each communication protocol includes:

[0029] A protocol parsing database is constructed to obtain the parsing logic of several communication protocols (including public protocols and private protocols). The parsing logic includes parsing fixed fields (such as slave address and function code) and variable fields (such as register address and data value) of data packets. The parsing logic of each communication protocol is encapsulated into a Docker container image. The Docker container image contains independent code, dependency libraries and configuration files.

[0030] Obtain sample data packets corresponding to several communication protocols;

[0031] The sample data packets of the communication protocol are segmented and hierarchically analyzed to obtain the properties of each field and the hierarchical relationships between them. Different types of nodes are defined based on the properties and hierarchical relationships of the fields. Corresponding instance nodes are created for each field, and their attributes are set (basic fields → basic nodes, setting type, length, etc.; composite fields → composite nodes, setting a list of child nodes; validation fields → validation nodes, specifying the validation algorithm and associated fields). Based on the hierarchical relationships between the fields, the hierarchical relationships between the instance nodes created for each field are determined. Starting from the root node, the instance nodes are connected according to the hierarchical relationships to generate the inverse representation tree of the communication protocol. Feature extraction is performed on the inverse representation tree of the communication protocol to generate tree structure features, node attribute features, and sequence features.

[0032] The tree structure features, node attribute features, and sequence features of each communication protocol are associated with the Docker container images of each communication protocol and stored in the protocol parsing database.

[0033] Furthermore, the process of performing protocol parsing on new industrial equipment marked as having an unknown protocol state based on a reverse representation tree, and performing protocol parsing on new industrial equipment with known communication protocols based on Docker container images, includes:

[0034] If a new industrial device is marked as having an unknown protocol, the data packets of the new industrial device are segmented and analyzed hierarchically to construct an inverse representation tree corresponding to the data packets. Features are extracted from the inverse representation tree to generate tree structure features, node attribute features, and sequence features. These features are then input into a protocol parsing database for matching. The similarity of the representation trees of each communication protocol in the database is obtained, and the communication protocol with the highest similarity is selected and marked as the communication protocol of the new industrial device. A Docker container image of the communication protocol is downloaded from the protocol parsing database, and the data packets of the new industrial device are parsed based on the Docker container image to obtain key data. For example, for the Modbus protocol, parsing the data packets based on the Docker container image can accurately extract key data such as register addresses and data values ​​from the data packets, providing a foundation for subsequent data processing and control.

[0035] The tree structure features, node attribute features, and sequence features are input into the protocol parsing database for matching. The formula for calculating the similarity of the representation trees of each communication protocol in the protocol parsing database is as follows:

[0036] Preset tree structure features T, Where d represents the depth of the tree, n represents the total number of instance nodes, and b represents the average branching factor (number of leaf nodes / number of non-leaf nodes). This represents the number of instance nodes in the i-th layer. Indicates the total number of floors;

[0037] The attribute characteristic of each node is preset to A. , where t represents the field type (such as Int, String, which is encoded as a vector using one-hot encoding), l represents the field length (such as the number of bytes), and r represents the value range (such as [0,255], which is normalized to 0-1). Indicates whether a field is a reserved field (0 or 1) and can be merged into the encoding of t (e.g., adding a Reserved type);

[0038] The default field type sequence is S. , where m represents the number of field types;

[0039] ;

[0040] ;

[0041] ;

[0042] ;

[0043] in, Represents two inverse representation trees and Structural similarity, Representing feature dimensions, such as =5 corresponds to , This represents the average attribute similarity across all instance nodes of the two inverse representation trees. This represents the number of instance nodes that match between the two inverse representation trees. Indicates type weight, Represents the cosine similarity of vectors. Used to measure the directional consistency between two attribute vectors (mainly t and r). This represents the normalized absolute difference, used to measure length differences, with a result range of [0,1]. Indicates sequence feature similarity. Represents a sequence of field types and The length of the longest common subsequence; This indicates the similarity between two inverse representation trees. , and As a weighting factor;

[0044] If the new industrial equipment is not marked as having an unknown protocol, obtain the communication protocol of the new industrial equipment, download the Docker container image of the communication protocol of the new industrial equipment from the protocol parsing database, parse the data packets of the new industrial equipment according to the Docker container image, and obtain the key data in the data packets.

[0045] When a new industrial device is not detected in the industrial network graph, the Docker container image corresponding to the communication protocol of the new industrial device is removed.

[0046] Furthermore, the protocol conversion module collects real-time status data of the new industrial equipment. Based on the real-time status data and preset protocol conversion rules, the process of dynamically converting the parsed results of the new industrial equipment includes:

[0047] An intermediate conversion model is constructed to obtain industrial equipment that is connected to the new industrial equipment for communication. The industrial equipment is marked as the target equipment. An equipment information database is pre-built to record the communication protocol types supported by each industrial equipment. The communication protocol types supported by the target equipment are obtained based on the equipment information database.

[0048] Several protocol conversion rules are preset. Each protocol conversion rule includes conversion conditions and target protocol. The conversion conditions include network load, device type, and device status. Real-time status data of the new industrial equipment is collected and matched with the conversion conditions of each protocol conversion rule.

[0049] If there is a corresponding conversion condition that matches the real-time status data, for example, rule 1: if the network load is <30% and the device is a PLC, then execute Modbus→MQTT (high bandwidth efficiency); rule 2: if the device power is <20%, execute Modbus→CoAP (low power consumption). According to the protocol conversion rule, obtain the target protocol of the new industrial equipment, determine whether the communication protocol type supported by the target device includes the target protocol of the new industrial equipment. If not, perform a bidirectional protocol conversion operation. If it includes, input the target protocol and key data in the data packet into the intermediate conversion model, output the target protocol representation of the key data according to the intermediate conversion model, and transmit the target protocol representation of the key data to the target device.

[0050] If there is no corresponding conversion condition and protocol conversion rule that matches the real-time status data, then it is determined whether the communication protocol type of the new industrial equipment and the target equipment is consistent. If they are consistent, the key data is transmitted to the target equipment. If they are inconsistent, the key data in the data packet and the communication protocol of the target equipment are input into the intermediate conversion model. The intermediate conversion model outputs the communication protocol representation of the key data and transmits it to the target equipment.

[0051] Furthermore, the process of performing bidirectional protocol conversion includes:

[0052] The target protocol of the new industrial equipment and the key data in the data packet are input into the intermediate conversion model. The target protocol representation of the key data is output according to the intermediate conversion model. The target protocol representation of the key data is uploaded to the industrial computer control center. The industrial computer control center converts the target protocol representation of the key data into the communication protocol representation of the target device. Then, the communication protocol representation of the key data is transmitted to the target device.

[0053] Furthermore, the adaptive buffer management module sets the adaptive buffer area and dynamic priority of the target device according to the communication protocol of the new industrial equipment, including the following process:

[0054] The initial capacity of independent buffers for different communication protocols is preset. If the communication protocol of the target device is inconsistent with that of the new industrial equipment, an independent buffer is set for the target device according to the initial capacity of the independent buffer of the new industrial equipment. Protocol indicators are monitored for the independent buffer of the target device to obtain the protocol indicators, which include: latency: the time from data entering the buffer to exiting the buffer, queue length: the number of data packets to be processed in the current buffer, and a preset protocol indicator threshold range. The protocol indicators are compared with the protocol indicator threshold range. If the protocol indicators are not within the protocol indicator threshold range, the capacity of the independent buffer is adaptively adjusted.

[0055] The specific formula for adaptive capacity adjustment of independent buffers is as follows:

[0056] ;

[0057] in, Indicates the new capacity. Indicates the current capacity. Indicates the delay threshold. Indicates a delay. Indicates the queue length. Indicates the queue length threshold. , These are the weighting coefficients for latency and queue length, respectively. ;

[0058] If the target device is simultaneously connected to k (k>1) new industrial devices, and the communication protocol of the target device is inconsistent with the communication protocols of the k new industrial devices, then k independent buffers are set for the target device according to the initial capacity of the independent buffer of the communication protocol of each new industrial device. The protocol index of each independent buffer and the protocol real-time level of the communication protocol corresponding to each independent buffer are obtained. The dynamic priority of each independent buffer is obtained according to the protocol index and protocol real-time level of each independent buffer.

[0059] The specific formula for obtaining the dynamic priority of each independent buffer is as follows:

[0060] ;

[0061] in, Indicates dynamic priority. Indicates the real-time performance level of the protocol.

[0062] Furthermore, the process by which the dynamic feedback detection module performs temporary dynamic feedback detection on new industrial equipment with a temporary dynamic feedback detection mechanism includes:

[0063] A feedback detection cycle is set for new industrial equipment with a temporary dynamic feedback detection mechanism. Data logs of the new industrial equipment and the target equipment are collected during the feedback detection cycle. Statistical analysis is performed on the data logs to obtain the interaction indicators between the new industrial equipment and the target equipment. The interaction indicators include data loss frequency, data latency, connection establishment time, number of disconnections and reconnections, and function execution results.

[0064] A preset threshold range for interaction indicators is defined. If the interaction indicators of the new industrial equipment are not within the threshold range, the communication protocol of the new industrial equipment is used to perform lightweight feature matching on the new industrial equipment.

[0065] If the interaction index of the new industrial equipment is within the threshold range of the interaction index, the temporary dynamic feedback detection mechanism for the new industrial equipment will be removed.

[0066] Compared with the prior art, the beneficial effects of the present invention are:

[0067] 1. Efficient protocol identification and adaptive detection mechanism

[0068] CRC matching and Bayesian classification: By matching CRC and address features from a publicly available protocol fingerprint database and combining this with Bayesian posterior probability determination, the recognition accuracy of known protocols is improved to over 98.7% (compared to 85%-90% for traditional methods). For example, the recognition time for the Modbus protocol is reduced from the traditional 300ms to 80ms.

[0069] Lightweight Feature Matching: For devices with unknown protocols, multi-dimensional analysis of time features, structural features, and data content features is employed, combined with a proprietary protocol identification model, to increase the success rate of unknown protocol parsing to 92% (compared to 75% for traditional rule-based methods). For example, the identification speed for a certain proprietary industrial protocol is reduced from 2 hours to 15 minutes.

[0070] Dynamic feedback detection: A temporary dynamic feedback detection mechanism is used to verify the communication stability of devices with unknown protocols in real time, reducing system failures caused by misjudgments. For example, the communication anomaly detection cycle for a certain sensor device is shortened from 4 hours to 15 minutes.

[0071] 2. Intelligent and standardized protocol parsing

[0072] Reverse representation tree and Docker containerization: Encapsulating protocol parsing logic into a Docker image enables plug-and-play parsing modules, reducing system upgrade costs. For example, the deployment time for adding OPC UA protocol parsing functionality is reduced from the traditional two weeks to two hours.

[0073] Tree structure feature matching: By matching the structural features, node attribute features, and sequence features of the tree inverse representation of the protocol, fast parsing of unknown protocols can be achieved. For example, the parsing time for the BACnet protocol has been reduced from the traditional 400ms to 120ms.

[0074] Intermediate conversion model: By standardizing the intermediate data model, the complexity of protocol conversion is reduced by more than 60%. For example, the code size for bidirectional conversion between Modbus and MQTT is reduced from 2000 lines to 500 lines.

[0075] 3. Real-time performance and compatibility of dynamic protocol conversion

[0076] Bidirectional protocol conversion: Supports a hybrid mode of local conversion at edge nodes and collaborative conversion in the cloud, reducing data transmission latency. For example, local conversion at edge nodes can achieve latency in the 1ms range, while the average latency of cloud conversion is reduced from 500ms to 150ms.

[0077] Real-time status awareness: Dynamically selects the optimal switching path based on the real-time status of the device (such as network load and device battery level) to improve system resource utilization. For example, when the network load is higher than 80%, it automatically selects the Protobuf protocol with a higher compression ratio, reducing data transmission volume by 40%.

[0078] Multi-protocol adaptation: Supports simultaneous processing of more than 10 heterogeneous protocols. For example, in a smart factory scenario, it enables mixed communication of protocols such as Modbus, EtherCAT, and MQTT, increasing system throughput by 300%.

[0079] 4. Reliability and efficiency of adaptive buffer management

[0080] Independent buffers and dynamic priorities: Independent buffers are allocated for each protocol, and combined with dynamic priority scheduling, the latency of real-time protocols (such as EtherCAT) can be controlled within 2ms, and the packet loss rate is reduced from the traditional 12% to 0.05%.

[0081] Dynamic capacity adjustment: An adaptive adjustment algorithm based on latency and queue length ensures that buffer utilization is always maintained within the optimal range of 60%-80%. For example, the response time for expanding / shrinking the Modbus protocol buffer is reduced from the traditional 2 seconds to 100ms.

[0082] 5. High system-level reliability and scalability

[0083] Distributed architecture: The distributed deployment of edge computing nodes reduces the impact of single-point failures to less than 10%. For example, a failure of an edge node on a production line only affects three local devices and does not affect other production lines.

[0084] Docker containerized deployment: The containerized encapsulation of parsing modules enables the system to quickly add new protocols, reducing maintenance costs by 70%. For example, when a factory adds 5 new device protocols, it does not need to restart the entire system.

[0085] Closed-loop feedback mechanism: Through a dynamic feedback detection module, the entire process of protocol identification, parsing, and conversion is optimized. For example, the iteration cycle of the parsing model for a device with an unknown protocol is shortened from the traditional 3 months to 1 week.

[0086] This system addresses four major pain points in the Industrial Internet of Things (IIoT) through five core innovations: intelligent protocol identification, standardized parsing, dynamic conversion, adaptive buffering, and closed-loop feedback. It achieves 99.9% communication reliability, 1ms-level real-time protocol latency, a 300% increase in system throughput, and a 70% reduction in maintenance costs, providing an efficient and reliable solution for the convergence of heterogeneous networks in Industry 4.0. Attached Figure Description

[0087] Figure 1 This is a schematic diagram of an edge computing-based industrial computer multi-protocol adaptive control system according to an embodiment of this application.

[0088] Figure 2 This is a schematic diagram of the reverse representation tree of a Modbus RTU protocol frame according to an embodiment of this application. Detailed Implementation

[0089] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0090] like Figure 1 As shown, the industrial computer multi-protocol adaptive control system based on edge computing includes an industrial computer control center and edge computing nodes. The industrial computer control center is connected to several industrial devices in a distributed manner through the edge computing nodes. The edge computing nodes include a protocol identification module, a protocol parsing module, a protocol conversion module, an adaptive buffer management module, and a dynamic feedback detection module.

[0091] The protocol identification module is used to perform CRC matching and address feature Bayes classification on new industrial equipment connected to the industrial network graph. Based on the matching results, it sets a temporary dynamic feedback detection mechanism or performs lightweight feature matching on the new industrial equipment to obtain the communication protocol of the new industrial equipment or marks the new industrial equipment as having an unknown protocol.

[0092] The protocol parsing module is used to construct the reverse representation tree of each communication protocol, obtain the tree structure features, node attribute features, sequence features and Docker container images of each communication protocol, perform protocol parsing based on the reverse representation tree for new industrial equipment marked as having unknown protocol status, and perform protocol parsing based on the Docker container image for new industrial equipment with known communication protocols.

[0093] The protocol conversion module is used to collect real-time status data of new industrial equipment and dynamically convert the parsing results of the new industrial equipment according to the real-time status data and preset protocol conversion rules.

[0094] The adaptive buffer management module is used to set the adaptive buffer area and dynamic priority of the target device according to the communication protocol of the new industrial equipment;

[0095] The dynamic feedback detection module is used to perform temporary dynamic feedback detection on new industrial equipment with a temporary dynamic feedback detection mechanism.

[0096] It should be further explained that, in the specific implementation process, the communication connection relationship between several industrial devices is obtained, and the several industrial devices are regarded as nodes. The communication connection relationship between the several industrial devices is regarded as the connection relationship between the nodes. An industrial network diagram is constructed, and the industrial network diagram is used to detect the access of new industrial devices in real time. The network scanning tool Nmap is used to scan the IP address range of each industrial device in the industrial network diagram to identify the IP address of existing industrial devices and the IP address of new industrial devices. When a new industrial device is detected to be accessing the industrial network diagram, the data generated by the new industrial device is packaged into a data packet and uploaded to the protocol recognition module.

[0097] It should be further explained that, in the specific implementation process, the protocol identification module performs CRC matching and address feature Bayesian classification on new industrial equipment accessing the industrial network graph. Based on the matching results, the process of setting up a temporary dynamic feedback detection mechanism or performing lightweight feature matching on the new industrial equipment includes:

[0098] Construct a public protocol fingerprint database, which includes CRC features and address features corresponding to several public protocols. The CRC features include CRC generator polynomial, initial value, check bit length, etc., and the address features include address value, address range, encoding rules, etc.

[0099] The data generated by the new industrial equipment is packaged into data packets. Feature extraction is performed on the data packets to obtain target CRC features and target address features. The target CRC features are input into the public protocol fingerprint database for CRC matching. Public protocols whose CRC features match the target CRC features are selected from the public protocol fingerprint database. The public protocols are classified according to address features based on the target address features to obtain the posterior probability that the target address features belong to each public protocol.

[0100] The specific process of performing address feature Bayesian classification on the public protocols based on the target address features to obtain the probability that the target address features belong to each public protocol includes:

[0101] Let C represent the public protocol category, and X represent the target address characteristics (such as address value, address range, encoding rules, etc.). Convert the target address characteristics X into a discrete feature vector. For example, address range (4x / 3x / 0x / 1x), register type (holding register / input register), slave address (0x0100-0x01FF), PDO mapped address (0x1C10-0x1C13). Vectorize the target address characteristics as follows: ,in For binary features (such as "whether it belongs to a Modbus4x register"), n represents the number of discrete feature vectors;

[0102] Since the address features of each public protocol are independent, a simplified posterior probability formula is constructed:

[0103] ;

[0104] in, Let X represent the posterior probability that the target address feature X belongs to the public protocol C. Let be the prior probability, representing the probability of the public protocol C appearing in the industrial network graph. Let be the likelihood, representing the target address characteristics generated by the public protocol C. The probability of;

[0105] A preset posterior probability judgment threshold is set to filter out the public protocol with the highest posterior probability. The posterior probability of the public protocol is compared with the posterior probability judgment threshold. If the posterior probability of the public protocol is greater than or equal to the posterior probability judgment threshold, the public protocol is marked as the communication protocol of the new industrial equipment. A temporary dynamic feedback detection mechanism is set for the new industrial equipment. If the posterior probability of the public protocol is less than the posterior probability judgment threshold, lightweight feature matching is performed.

[0106] CRC matching does not require complex calculations. In industrial scenarios, more than 80% of protocols have unique CRCs, and direct matching can quickly filter out a large number of irrelevant protocols.

[0107] Bayesian classification has a computational complexity far lower than deep learning but higher than direct CRC matching, making it suitable as a second-step filtering method (where the first step, CRC, has already filtered out most protocols, leaving only a small number to process). For example, assuming there are 100 protocols in the protocol library, after fast CRC filtering, only 10 remain. Bayesian classification only needs to calculate the probability of these 10 protocols based on their address features, with a total processing time of <5ms, meeting the real-time requirements of industrial applications. This progressive design logic of fast filtering followed by fine-grained analysis achieves a balance between efficiency and accuracy, meeting the dual requirements of real-time performance and robustness in industrial scenarios.

[0108] If no public protocol fingerprint database contains a corresponding CRC feature that matches the target CRC feature, then lightweight feature matching is performed.

[0109] It should be further explained that, in the specific implementation process, the lightweight feature matching process includes:

[0110] Collect several consecutive data packets generated by new industrial equipment, perform multi-dimensional feature extraction on the consecutive data packets to generate time feature vector, structural feature vector and data content feature vector, and extract features based on the CRC matching results and address feature Bayes classification results of the new industrial equipment to obtain protocol fingerprint features;

[0111] A private protocol identification model is built based on a lightweight CNN+LSTM. The model is input with time feature vector, structural feature vector, data content feature vector and protocol fingerprint features. The model outputs the confidence scores of several private protocols.

[0112] A pre-set confidence threshold is used to filter out the private protocols with the highest confidence. The confidence of the private protocol is compared with the confidence threshold. If the confidence is greater than or equal to the confidence threshold, the private protocol is marked as the communication protocol of the new industrial equipment. If the confidence is less than the confidence threshold, the new industrial equipment is marked as having an unknown protocol.

[0113] The time feature vector includes the frame interval mean, frame interval standard deviation, frame interval maximum, and frame interval minimum; the structural feature vector includes the frame length and the number of fields; the data content feature vector includes the data field entropy value and the frequency of special values ​​(such as 0xFF (Modbus broadcast address) and 0x0000 (initial value)); and the protocol fingerprint features include the matching degree between the target CRC feature and the CRC features of each public protocol in the public protocol fingerprint database, and the posterior probability of each public protocol.

[0114] It needs further explanation that, based on the CRC matching results of the new industrial equipment and during the feature extraction process, a hierarchical scoring method is used to obtain the matching degree between the target CRC feature and the CRC features of various public protocols in the public protocol fingerprint database. For example, weights are assigned according to parameter importance (example weights: polynomial 40%, bit length 20%, byte order 20%, initial value 15%, check position 5%) to obtain the target CRC feature. Step 1: Match the bit length. The bit length must be the same; otherwise, it is directly excluded (e.g., if the target is a 16-bit CRC, the matching degree of CAN bus (15-bit) is 0%). Step 2: Match the polynomial. A perfect polynomial match earns full marks; otherwise, points are deducted based on the Hamming distance (binary difference bits). (For example, if the target polynomial 0x8005 (binary 1000 0000 0000 0101) is completely identical to Modbus, it scores 100%; however, it differs from Zigbee's 0x1021 (0001 0000 0010 0001) by 6 bits, resulting in a score of 1 - 6 / 16 = 62.5%). Step 3: Match byte order, initial value, and checksum position. Byte order: 100% if the high and low bits are identical, otherwise 0%. Initial value: 100% if the hexadecimal values ​​are identical, otherwise points are deducted proportionally based on the difference. Checksum position: 100% if the positions are identical (e.g., both are at the end of the frame), otherwise 0%. Step 4: Calculate the weighted total match rate. .

[0115] It should be further explained that, in the specific implementation process, the process of constructing the private protocol identification model includes:

[0116] Standard data packets of publicly available protocols are obtained from data sources such as PLCopen and OPC Foundation. Simultaneously, data packets of several variant protocols of publicly available protocols are collected in cooperation with equipment manufacturers. Private protocol type labeling is applied to these variant protocols. Multi-dimensional feature extraction is performed on both the standard data packets of publicly available protocols and the data packets of private protocols to generate time feature vectors, structural feature vectors, and data content feature vectors. The data packets of private protocols are then compared with a publicly available protocol fingerprint database using CRC matching and address feature Bayesian classification. Protocol fingerprint features are obtained based on the CRC matching and address feature Bayesian classification results. The time feature vectors, structural feature vectors, data content feature vectors, and protocol fingerprint features are used as training and testing sets. The training set is input into the private protocol recognition model for training until the loss function stabilizes, and the model parameters are saved. The private protocol recognition model is then tested using a test set until it meets preset requirements, at which point the private protocol recognition model is output.

[0117] Since protocol recognition requires capturing both static structural features (such as frame header patterns) and dynamic temporal features (such as frame interval patterns), this embodiment selects a lightweight CNN+LSTM to build a private protocol recognition model. The specific architecture includes: CNN layer: 3 convolutional blocks to extract local features (such as the first 5 bytes pattern); LSTM layer: 2 bidirectional LSTM layers to capture temporal dependencies (such as the interval pattern of 10 consecutive frames); fully connected layer: using Dropout to prevent overfitting and outputting the probability distribution of 200+ protocols; loss function: cross-entropy loss + Focal Loss (to solve class imbalance). During training, the weights are continuously updated through the backpropagation algorithm, causing the loss function to gradually decrease until it reaches a stable state. After the model training is completed and the parameters are adjusted, a final evaluation is performed using a test set to obtain the model's evaluation results. The evaluation results include classification metrics such as accuracy, recall, and F1 score. Based on the evaluation results on the test set, it is determined whether the model has met the expected standards. If the requirements are met, the model parameters are saved and deployment is prepared; if not, it is necessary to return to a previous stage to re-examine issues such as data quality, model structure, or training strategy.

[0118] It should be further explained that, in the specific implementation process, the protocol parsing module constructs the inverse representation tree of each communication protocol, and obtains the tree structure features, node attribute features, sequence features, and Docker container images of each communication protocol. This process includes:

[0119] A protocol parsing database is constructed to obtain the parsing logic of several communication protocols (including public protocols and private protocols). The parsing logic includes parsing fixed fields (such as slave address and function code) and variable fields (such as register address and data value) of data packets. The parsing logic of each communication protocol is encapsulated into a Docker container image. The Docker container image contains independent code, dependency libraries and configuration files.

[0120] Obtain sample data packets corresponding to several communication protocols;

[0121] The sample data packets of the communication protocol are segmented and hierarchically analyzed to obtain the properties of each field and the hierarchical relationships between them. Different types of nodes are defined based on the properties and hierarchical relationships of the fields. Corresponding instance nodes are created for each field, and their attributes are set (basic fields → basic nodes, setting type, length, etc.; composite fields → composite nodes, setting a list of child nodes; validation fields → validation nodes, specifying the validation algorithm and associated fields). Based on the hierarchical relationships between the fields, the hierarchical relationships between the instance nodes created for each field are determined. Starting from the root node, the instance nodes are connected according to the hierarchical relationships to generate the inverse representation tree of the communication protocol. Feature extraction is performed on the inverse representation tree of the communication protocol to generate tree structure features, node attribute features, and sequence features.

[0122] The tree structure features, node attribute features, and sequence features of each communication protocol are associated with the Docker container images of each communication protocol and stored in the protocol parsing database.

[0123] The properties of a field include its type, length, position, and semantics.

[0124] Field types include numeric fields (determined by unsigned integers, signed integers, floating-point numbers, etc.), enumerated fields (determined by the uniqueness of statistical field values), and check fields (verified through algorithms such as CRC16 and CRC32).

[0125] Field length and position include fixed-length fields (determined by their position and length remaining constant throughout all data packets, such as the slave address in the Modbus protocol (byte 1, fixed byte 1)) and variable-length fields (determined by length fields or delimiters).

[0126] Field semantics are determined through protocol interaction logic: for example, the correspondence between request packets and response packets, which determines the purpose of the field (such as request ID, response data).

[0127] The hierarchical relationships of fields include nested structures (parent-child relationships) and parallel relationships. Nested structures include those based on field position (e.g., a data packet structure is [header][data area][checksum], where the data area contains subfields [address][value], then the data area is the parent node, and the address and value are child nodes), and hierarchical relationships based on field type. Hierarchical relationships based on field type include composite fields: containing multiple subfields, for example, a Modbus request frame consists of [slave address][function code][data][CRC], where the request frame is the composite node, and the others are child nodes; and parallel fields: without nesting relationships, belonging to the same parent node as sibling child nodes, such as the address and value in the data area.

[0128] Node types include basic nodes (leaf nodes), composite nodes (non-leaf nodes), root nodes, and check nodes.

[0129] Figure 2 This is a schematic diagram of the reverse representation tree of a Modbus RTU protocol frame. The data packet (hexadecimal) of the Modbus RTU protocol frame is: 01 03 00 01 00 02 C4 0B, slave address (01, 1 byte, unsigned integer → basic node), function code (03, 1 byte, enumeration → basic node), start register address (00 01, 2 bytes, unsigned integer → basic node), number of registers (00 02, 2 bytes, unsigned integer → basic node), CRC check (C4 0B, 2 bytes, CRC16 → check node).

[0130] It should be further explained that, in the specific implementation process, the process of performing protocol parsing based on the reverse representation tree for new industrial equipment marked as having an unknown protocol, and performing protocol parsing based on Docker container images for new industrial equipment with known communication protocols, includes:

[0131] If a new industrial device is marked as having an unknown protocol, the data packets of the new industrial device are segmented and analyzed hierarchically to construct an inverse representation tree corresponding to the data packets. Features are extracted from the inverse representation tree to generate tree structure features, node attribute features, and sequence features. These features are then input into a protocol parsing database for matching. The similarity of the representation trees of each communication protocol in the database is obtained, and the communication protocol with the highest similarity is selected and marked as the communication protocol of the new industrial device. A Docker container image of the communication protocol is downloaded from the protocol parsing database, and the data packets of the new industrial device are parsed based on the Docker container image to obtain key data. For example, for the Modbus protocol, parsing the data packets based on the Docker container image can accurately extract key data such as register addresses and data values ​​from the data packets, providing a foundation for subsequent data processing and control.

[0132] Among them, tree structure features include tree depth, number of nodes, node hierarchical relationships, etc. Different protocols have different data packet structures. For example, some protocols may have data packets with deep nesting levels, while others are relatively flat.

[0133] Node attribute characteristics: These include the attribute information of instance nodes, such as field types, value ranges, and dependencies between fields. For example, a protocol might stipulate that the values ​​of certain fields must be within a certain range, or that there are specific computational relationships between certain fields;

[0134] Sequence characteristics: This includes the order and arrangement of fields in the data packet. The order of fields may differ between different protocols, which is an important basis for determining the protocol type;

[0135] The tree structure features, node attribute features, and sequence features are input into the protocol parsing database for matching. The formula for calculating the similarity of the representation trees of each communication protocol in the protocol parsing database is as follows:

[0136] Preset tree structure features T, Where d represents the depth of the tree, n represents the total number of instance nodes, and b represents the average branching factor (number of leaf nodes / number of non-leaf nodes). This represents the number of instance nodes in the i-th layer. Indicates the total number of floors;

[0137] The attribute characteristic of each node is preset to A. , where t represents the field type (such as Int, String, which is encoded as a vector using one-hot encoding), l represents the field length (such as the number of bytes), and r represents the value range (such as [0,255], which is normalized to 0-1). Indicates whether a field is a reserved field (0 or 1) and can be merged into the encoding of t (e.g., adding a Reserved type);

[0138] The default field type sequence is S. , where m represents the number of field types;

[0139] ;

[0140] ;

[0141] ;

[0142] ;

[0143] in, Represents two inverse representation trees and Structural similarity, Representing feature dimensions, such as =5 corresponds to , This represents the average attribute similarity across all instance nodes of the two inverse representation trees. This represents the number of instance nodes that match between the two inverse representation trees. Indicates type weight, Represents the cosine similarity of vectors. Used to measure the directional consistency between two attribute vectors (mainly t and r). This represents the normalized absolute difference, used to measure length differences, with a result range of [0,1]. Indicates sequence feature similarity. Represents a sequence of field types and The length of the longest common subsequence; This indicates the similarity between two inverse representation trees. , and As a weighting factor;

[0144] If the new industrial equipment is not marked as having an unknown protocol, obtain the communication protocol of the new industrial equipment, download the Docker container image of the communication protocol of the new industrial equipment from the protocol parsing database, parse the data packets of the new industrial equipment according to the Docker container image, and obtain the key data in the data packets.

[0145] When a new industrial device is not detected in the industrial network graph, the Docker container image corresponding to the communication protocol of the new industrial device is removed.

[0146] It should be further explained that, in the specific implementation process, the protocol conversion module collects real-time status data of the new industrial equipment. Based on the real-time status data and preset protocol conversion rules, the process of dynamically converting the parsed results of the new industrial equipment includes:

[0147] An intermediate conversion model is constructed to obtain industrial equipment that is connected to the new industrial equipment for communication. The industrial equipment is marked as the target equipment. An equipment information database is pre-built to record the communication protocol types supported by each industrial equipment. The communication protocol types supported by the target equipment are obtained based on the equipment information database.

[0148] Several protocol conversion rules are preset. Each protocol conversion rule includes conversion conditions and target protocol. The conversion conditions include network load, device type, and device status. Real-time status data of the new industrial equipment is collected and matched with the conversion conditions of each protocol conversion rule.

[0149] If there is a corresponding conversion condition that matches the real-time status data, for example, rule 1: if the network load is <30% and the device is a PLC, then execute Modbus→MQTT (high bandwidth efficiency); rule 2: if the device power is <20%, execute Modbus→CoAP (low power consumption). According to the protocol conversion rule, obtain the target protocol of the new industrial equipment, determine whether the communication protocol type supported by the target device includes the target protocol of the new industrial equipment. If not, perform a bidirectional protocol conversion operation. If it includes, input the target protocol and key data in the data packet into the intermediate conversion model, output the target protocol representation of the key data according to the intermediate conversion model, and transmit the target protocol representation of the key data to the target device.

[0150] If there is no corresponding conversion condition and protocol conversion rule that matches the real-time status data, then it is determined whether the communication protocol type of the new industrial equipment and the target equipment is consistent. If they are consistent, the key data is transmitted to the target equipment. If they are inconsistent, the key data in the data packet and the communication protocol of the target equipment are input into the intermediate conversion model. The intermediate conversion model outputs the communication protocol representation of the key data and transmits it to the target equipment.

[0151] Real-time status data is dynamically matched with protocol rules to achieve a dynamic balance between transmission efficiency (bandwidth), real-time performance (latency), and device power consumption.

[0152] Traditional solutions employ a one-to-one mapping: a dedicated converter needs to be developed for each protocol pair (e.g., Modbus→OPC UA, Profinet→EtherCAT). When adding the Nth protocol, N×(number of existing protocols) conversion logics need to be developed. For example, if there are 10 existing protocols, adding one requires 10 conversion modules, resulting in quadratic growth in complexity and poor scalability. Intermediate conversion models can unify these differences, making conversions more universal. An intermediate conversion model includes a parsing module and a conversion module. The parser is only responsible for converting the raw data into an intermediate format, while the conversion module only needs to process the intermediate format to the target protocol. This allows each part to be developed and modified independently. For example, adding a new protocol only requires adding the parsing module and the corresponding conversion rules, without modifying other parts. The process of building an intermediate conversion model includes: identifying the types of communication protocols to be supported; collecting sample data of different protocols from various data sources; analyzing the characteristics of the sample data, such as data type (numerical, string, boolean, etc.), value range, data frequency, etc.; identifying common data elements present in different protocols, such as device identifiers, data timestamps, physical quantity values, etc.; and using these elements as the basis for the intermediate data model.

[0153] Define attributes for each data element, including data type, length, and unit. Choose JSON as the data representation format. Design a reasonable data hierarchy based on the relationships between data elements. For example, place device information, data, and metadata in different layers, and consider each supported protocol.

[0154] Define the mapping rules from data of each communication protocol to the intermediate data model. These rules describe how to map specific fields in the protocol to the corresponding data elements in the intermediate data model. For example, in the Modbus protocol, register address 40001 corresponds to the "temperature" data element in the intermediate data model. Based on the designed mapping rules, write code to implement the conversion from data of different protocols to the intermediate data model.

[0155] The collected sample data was used to validate the intermediate data model, ensuring that the process of converting data from different protocols to the intermediate data model was correct.

[0156] It should be further explained that, in the specific implementation process, the bidirectional protocol conversion operation includes:

[0157] The target protocol of the new industrial equipment and the key data in the data packet are input into the intermediate conversion model. The target protocol representation of the key data is output according to the intermediate conversion model. The target protocol representation of the key data is uploaded to the industrial computer control center. The industrial computer control center converts the target protocol representation of the key data into the communication protocol representation of the target device. Then, the communication protocol representation of the key data is transmitted to the target device.

[0158] It should be further explained that, in the specific implementation process, the adaptive buffer management module sets the adaptive buffer area and dynamic priority of the target device according to the communication protocol of the new industrial equipment, including:

[0159] Because different protocols have significantly different communication cycles (e.g., Modbus 10 times per second, EtherCAT 1000 times per second), this frequency difference can cause the amount of data generated by high-speed protocols to far exceed that of low-speed protocols within the same network, potentially exceeding network bandwidth and leading to data congestion. To avoid this problem, this embodiment allocates an adaptive buffer for each protocol and sets a dynamic priority for each independent buffer. For example, when the EtherCAT delay exceeds 2ms, the buffer capacity is expanded and the priority of Modbus is reduced to avoid bandwidth preemption.

[0160] Pre-set the initial capacity of independent buffers for different communication protocols. For example: for high-speed real-time protocols (such as EtherCAT, 1000 times / second): the initial buffer capacity is set to be small (e.g., 50KB), but can be quickly expanded; for low-speed non-real-time protocols (such as Modbus, 10 times / second): the buffer capacity is set to be large (e.g., 200KB), and can be delayed. Allocate independent buffers for each protocol to avoid priority conflicts caused by mixing data from different protocols. Allocate small-capacity but quickly expandable buffers for high-speed protocols and process them first; use large-capacity but shrinkable buffers for low-speed protocols and delay processing non-urgent data. If the communication protocol of the target device is inconsistent with the communication protocol of the new industrial equipment, set an independent buffer for the target device according to the initial capacity of the independent buffer of the new industrial equipment's communication protocol. Monitor the protocol indicators of the independent buffer of the target device and obtain the protocol indicators, which include: latency: the time from data entering the buffer to exiting the buffer; queue length: the number of data packets to be processed in the current buffer; preset protocol indicator threshold range; compare the protocol indicators with the protocol indicator threshold range; if the protocol indicators are not within the protocol indicator threshold range, then adaptively adjust the capacity of the independent buffer.

[0161] The specific formula for adaptive capacity adjustment of independent buffers is as follows:

[0162] ;

[0163] in, Indicates the new capacity. Indicates the current capacity. Indicates the delay threshold. Indicates a delay. Indicates the queue length. Indicates the queue length threshold. , These are the weighting coefficients for latency and queue length, respectively. ;

[0164] If the target device is simultaneously connected to k (k>1) new industrial devices, and the communication protocol of the target device is inconsistent with the communication protocols of the k new industrial devices, then k independent buffers are set for the target device according to the initial capacity of the independent buffer of the communication protocol of each new industrial device. The protocol index of each independent buffer and the protocol real-time level of the communication protocol corresponding to each independent buffer are obtained. The dynamic priority of each independent buffer is obtained according to the protocol index and protocol real-time level of each independent buffer.

[0165] The specific formula for obtaining the dynamic priority of each independent buffer is as follows:

[0166] ;

[0167] in, Indicates dynamic priority. Indicates the real-time performance level of the protocol.

[0168] It should be further explained that, in the specific implementation process, the process of the dynamic feedback detection module performing temporary dynamic feedback detection on new industrial equipment with a temporary dynamic feedback detection mechanism includes:

[0169] A feedback detection cycle is set for new industrial equipment with a temporary dynamic feedback detection mechanism. Data logs of the new industrial equipment and the target equipment are collected during the feedback detection cycle. Statistical analysis is performed on the data logs to obtain the interaction indicators between the new industrial equipment and the target equipment. The interaction indicators include data loss frequency, data latency, connection establishment time, number of disconnections and reconnections, and function execution results.

[0170] A preset threshold range for interaction indicators is defined. If the interaction indicators of the new industrial equipment are not within the threshold range, the communication protocol of the new industrial equipment is used to perform lightweight feature matching on the new industrial equipment.

[0171] If the interaction index of the new industrial equipment is within the threshold range of the interaction index, the temporary dynamic feedback detection mechanism for the new industrial equipment will be removed.

[0172] The above embodiments are only used to illustrate the technical methods of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical methods of the present invention without departing from the spirit and scope of the technical methods of the present invention.

Claims

1. An industrial computer multi-protocol adaptive control system based on edge computing, characterized in that, It includes an industrial computer control center and edge computing nodes. The industrial computer control center is connected to several industrial devices in a distributed manner through the edge computing nodes. The edge computing nodes include a protocol identification module, a protocol parsing module, a protocol conversion module, an adaptive buffer management module, and a dynamic feedback detection module. The protocol identification module is used to construct a public protocol fingerprint database, which includes CRC features and address features corresponding to several public protocols. The data generated by the new industrial equipment is packaged into data packets, and feature extraction is performed on the data packets to obtain the target CRC feature and the target address feature. Public protocols whose CRC features are consistent with the target CRC feature are selected from the public protocol fingerprint database. The public protocols are classified according to the address feature Bayesian classification based on the target address feature to obtain the posterior probability of each public protocol. A preset posterior probability judgment threshold is set to filter out the public protocol with the highest posterior probability. The posterior probability of the public protocol is compared with the posterior probability judgment threshold. If the posterior probability of the public protocol is greater than or equal to the posterior probability judgment threshold, the public protocol is marked as the communication protocol of the new industrial equipment. A temporary dynamic feedback detection mechanism is set for the new industrial equipment. If the posterior probability of the public protocol is less than the posterior probability judgment threshold, lightweight feature matching is performed. If there is no publicly available protocol in the public protocol fingerprint database whose CRC feature matches the target CRC feature, then lightweight feature matching is performed. The protocol parsing module is used to construct the reverse representation tree of each communication protocol, obtain the tree structure features, node attribute features, sequence features and Docker container images of each communication protocol, perform protocol parsing based on the reverse representation tree for new industrial equipment marked as having unknown protocol status, and perform protocol parsing based on the Docker container image for new industrial equipment with known communication protocols. The protocol conversion module is used to dynamically convert the parsing results of the new industrial equipment according to the real-time status data of the new industrial equipment and the preset protocol conversion rules; The adaptive buffer management module is used to set the adaptive buffer area and dynamic priority of the target device according to the communication protocol of the new industrial equipment; The dynamic feedback detection module is used to perform temporary dynamic feedback detection on new industrial equipment with a temporary dynamic feedback detection mechanism.

2. The industrial computer multi-protocol adaptive control system based on edge computing according to claim 1, characterized in that, The system acquires the communication connection relationships between several industrial devices, treats these industrial devices as nodes, and uses the communication connection relationships between these industrial devices as the connection relationships between the nodes to construct an industrial network graph. The system performs real-time detection of new industrial device access to the industrial network graph. When a new industrial device is detected to be accessing the industrial network graph, the data generated by the new industrial device is packaged into a data packet and uploaded to the protocol recognition module.

3. The industrial computer multi-protocol adaptive control system based on edge computing according to claim 2, characterized in that, The lightweight feature matching process includes: Collect several consecutive data packets generated by new industrial equipment, perform multi-dimensional feature extraction on the consecutive data packets to generate time feature vector, structural feature vector and data content feature vector, and extract features based on the CRC matching results and address feature Bayes classification results of the new industrial equipment to obtain protocol fingerprint features; A private protocol identification model is constructed. The time feature vector, structural feature vector, data content feature vector and protocol fingerprint feature are input into the private protocol identification model. Based on the private protocol identification model, the confidence scores of several private protocols are output. A pre-set confidence threshold is used to filter out the private protocols with the highest confidence. The confidence of the private protocol is compared with the confidence threshold. If the confidence is greater than or equal to the confidence threshold, the private protocol is marked as the communication protocol of the new industrial equipment. If the confidence is less than the confidence threshold, the new industrial equipment is marked as having an unknown protocol.

4. The industrial computer multi-protocol adaptive control system based on edge computing according to claim 3, characterized in that, The protocol parsing module constructs inverse representation trees for each communication protocol, and the process of obtaining the tree structure features, node attribute features, sequence features, and Docker container images for each communication protocol includes: Build a protocol parsing database, obtain the parsing logic of several communication protocols, and encapsulate the parsing logic of each communication protocol into a Docker container image; Obtain sample data packets corresponding to several communication protocols; The sample data packets of the communication protocol are segmented and hierarchically analyzed to obtain the properties of each field in the sample data packets and the hierarchical relationship between each field. Different types of nodes are defined according to the properties and hierarchical relationship of the fields. Instance nodes are created for each field and their attributes are set. The hierarchical relationship between the instance nodes created for each field is determined according to the hierarchical relationship between each field. Starting from the root node, each instance node is connected according to the hierarchical relationship to generate the reverse representation tree of the communication protocol. Feature extraction is performed on the reverse representation tree of the communication protocol to generate tree structure features, node attribute features, and sequence features. The tree structure features, node attribute features, and sequence features of each communication protocol are associated with the Docker container images of each communication protocol and stored in the protocol parsing database.

5. The industrial computer multi-protocol adaptive control system based on edge computing according to claim 4, characterized in that, The process of parsing protocols for new industrial equipment marked as having unknown protocols based on inverse representation trees, and parsing protocols for new industrial equipment with known communication protocols based on Docker container images, includes: If a new industrial device is marked as having an unknown protocol, the data packets of the new industrial device are segmented and analyzed hierarchically to construct an inverse representation tree corresponding to the data packets. Features are extracted from the inverse representation tree to generate tree structure features, node attribute features, and sequence features. The tree structure features, node attribute features, and sequence features are input into the protocol parsing database for matching. The similarity of the representation trees of each communication protocol in the protocol parsing database is obtained. The communication protocol with the highest representation tree similarity is selected and marked as the communication protocol of the new industrial device. The Docker container image of the communication protocol is downloaded from the protocol parsing database. The data packets of the new industrial device are parsed based on the Docker container image to obtain the key data in the data packets. If the new industrial equipment is not marked as having an unknown protocol, obtain the communication protocol of the new industrial equipment, download the Docker container image of the communication protocol of the new industrial equipment from the protocol parsing database, parse the data packets of the new industrial equipment according to the Docker container image, and obtain the key data in the data packets.

6. The industrial computer multi-protocol adaptive control system based on edge computing according to claim 5, characterized in that, The protocol conversion module collects real-time status data from the new industrial equipment. Based on this real-time status data and preset protocol conversion rules, the process of dynamically converting the parsed results of the new industrial equipment includes: Construct an intermediate conversion model, obtain industrial equipment that is connected to the new industrial equipment, mark the industrial equipment as the target equipment, and obtain the communication protocol types supported by the target equipment; Several protocol conversion rules are preset, each including conversion conditions and target protocol. Real-time status data of the new industrial equipment is collected, and the real-time status data of the new industrial equipment is matched with the conversion conditions of each protocol conversion rule. If there is a corresponding conversion condition that matches the real-time status data, the target protocol of the new industrial equipment is obtained according to the protocol conversion rule. It is determined whether the communication protocol type supported by the target equipment includes the target protocol of the new industrial equipment. If not, a bidirectional protocol conversion operation is performed. If it includes, the target protocol and key data in the data packet are input into the intermediate conversion model. The target protocol representation of the key data is output according to the intermediate conversion model, and the target protocol representation of the key data is transmitted to the target equipment. If there is no corresponding conversion condition and protocol conversion rule that matches the real-time status data, then it is determined whether the communication protocol type of the new industrial equipment and the target equipment is consistent. If they are consistent, the key data is transmitted to the target equipment. If they are inconsistent, the key data in the data packet and the communication protocol of the target equipment are input into the intermediate conversion model. The intermediate conversion model outputs the communication protocol representation of the key data and transmits it to the target equipment.

7. The industrial computer multi-protocol adaptive control system based on edge computing according to claim 6, characterized in that, The process of performing bidirectional protocol conversion includes: The target protocol of the new industrial equipment and the key data in the data packet are input into the intermediate conversion model. The target protocol representation of the key data is output according to the intermediate conversion model. The target protocol representation of the key data is uploaded to the industrial computer control center. The industrial computer control center converts the target protocol representation of the key data into the communication protocol representation of the target device. Then, the communication protocol representation of the key data is transmitted to the target device.

8. The industrial computer multi-protocol adaptive control system based on edge computing according to claim 7, characterized in that, The adaptive buffer management module sets the adaptive buffer area and dynamic priority of the target device according to the communication protocol of the new industrial equipment. The process includes: The initial capacity of independent buffers for different communication protocols is preset. If the communication protocol of the target device is inconsistent with that of the new industrial equipment, the independent buffer of the target device is set according to the initial capacity of the independent buffer of the new industrial equipment. The protocol index of the independent buffer of the target device is monitored, the protocol index is obtained, and the protocol index threshold range is preset. If the protocol index is not within the protocol index threshold range, the capacity of the independent buffer is adaptively adjusted. If k new industrial devices are connected to the target device at the same time, and the communication protocol of the target device is inconsistent with the communication protocols of the k new industrial devices, then k independent buffers of the target device are set according to the initial capacity of the independent buffer of the communication protocol of each new industrial device, the protocol index of each independent buffer and the protocol real-time level of the corresponding communication protocol of each independent buffer are obtained, and the dynamic priority of each independent buffer is obtained according to the protocol index and protocol real-time level of each independent buffer.

9. The industrial computer multi-protocol adaptive control system based on edge computing according to claim 8, characterized in that, The process of the dynamic feedback detection module performing temporary dynamic feedback detection on new industrial equipment with a temporary dynamic feedback detection mechanism includes: Set a feedback detection cycle for new industrial equipment with a temporary dynamic feedback detection mechanism, and obtain the interaction indicators between the new industrial equipment and the target equipment within the feedback detection cycle; If the interaction indicators of a new industrial device are not within the threshold range, the communication protocol of the new industrial device is removed, and lightweight feature matching is performed on the new industrial device. If the interaction index of the new industrial equipment is within the threshold range of the interaction index, the temporary dynamic feedback detection mechanism for the new industrial equipment will be removed.

Images