A cross-protocol identification data intelligent parsing method and system

Abstract

The application provides a cross-protocol identification data intelligent analysis middleware method and system. A plurality of industrial communication protocol identifications are obtained in advance to form a metadata set, and a protocol feature meta-model library containing a non-standard protocol feature template is constructed. A programmable logic device is introduced to match the physical layer signal waveform features, and the corresponding communication protocol stack is dynamically switched at the hardware level according to the matching result. The communication data stream is received by the electrical domain processing unit of the programmable logic device, and the protocol analysis logic sequence is generated in combination with the state transition rules of the meta-model library and the pattern matching rules of the protocol stack. The structured feature template and the analysis logic sequence are combined and operated to generate executable cross-protocol data analysis rules. When unknown protocol features are detected, the template is dynamically reconstructed to adapt the analysis rules to the new protocol. The technical scheme provided by the application significantly reduces the development cost of protocol compatibility in the industrial multi-protocol scene.

Description

Technical Field

[0001] This application relates to the field of parsing technology, and in particular to a method and system for intelligent parsing cross-protocol identifier data. Background Technology

[0002] In industrial IoT scenarios, data interoperability is difficult for devices from multiple brands due to heterogeneous communication protocols. For example, standard protocols such as Modbus and Profinet coexist with vendor-specific protocols. When traditional factories upgrade or add equipment, they need to quickly achieve cross-protocol data parsing and plug-and-play functionality. This requires the parsing middleware to have protocol adaptive recognition capabilities without manual intervention, low-latency physical layer signal adaptation capabilities, and dynamic scalability.

[0003] The current mainstream solution adopts dynamic loading technology based on software protocol libraries. The implementation method is as follows: a standard protocol library is pre-installed in the middleware, and protocol identification is achieved by matching protocol fingerprints (such as data packet header feature codes); for unknown protocols, protocol field templates are manually defined offline and then imported into the protocol library; different physical layer interfaces are adapted by switching the software protocol stack (such as Ethernet to RS-485), and signal processing is achieved by relying on the operating system scheduling.

[0004] The existing solution has the following drawbacks: it cannot parse private protocols that are not predefined, requiring manual intervention to define templates, which violates the plug-and-play requirement; switching the software protocol stack requires operating system interrupt response and driver reloading, resulting in latency of hundreds of milliseconds, which cannot meet the requirements of high real-time scenarios; protocol matching and signal processing both rely on CPU computation, which can easily cause thread blocking in mixed protocol scenarios, resulting in a significant decrease in data parsing throughput. Summary of the Invention

[0005] This application provides a method and system for intelligent parsing of cross-protocol identifier data, which solves the problem of high development costs for protocol compatibility in the prior art.

[0006] Firstly, this application provides a cross-protocol identifier data intelligent parsing method, including: Extract the header features and field offsets of various industrial communication protocol identifiers to form a metadata set. Construct the metadata set into a protocol feature meta-model library according to the protocol identifier hierarchy. The protocol feature meta-model library contains structured feature templates for non-standard protocols. A programmable logic device is introduced to perform real-time matching of the physical layer signal waveforms associated with the protocol feature element model library. Based on the matching result, the physical layer signal waveforms are switched to the corresponding communication protocol stack at the hardware level of the programmable logic device, and the communication protocol stack is fed back to the middleware's parsing rule generation module. The communication data stream is received in real time by the electrical domain processing unit of the programmable logic device, and the communication data stream is converted into a protocol parsing logic sequence by the state transition rules of the protocol feature element model library and the pattern matching rules of the communication protocol stack. In the parsing rule generation module, the structured feature template is combined with the protocol parsing logic sequence to generate cross-protocol data parsing rules that can be executed by the middleware. If there are unknown protocol features in the communication data stream that do not match the protocol feature meta-model library, the dynamic reconstruction of the structured feature template is triggered. The reconstructed structured feature template enables the cross-protocol data parsing rules to adapt to the newly added industrial communication protocols.

[0007] This application provides a method for intelligent parsing of cross-protocol identifier data, and also includes: Based on the aforementioned protocol feature meta-model library, an automatic protocol feature extraction engine is used to decompose the message structure of various industrial protocols and generate protocol adaptation templates containing protocol syntax trees and semantic constraints. The protocol adaptation template is input into the protocol classifier of the deep learning algorithm. The contextual correlation of the unknown protocol features is extracted by the convolutional neural network to generate the semantic feature vector required for dynamic reconstruction of the protocol stack. The semantic feature vector is then fed back to the programmable logic device for dynamic loading of protocol stack parameters. Based on the reconstructed protocol parsing logic sequence, the fields in the multi-source heterogeneous data streams are topologically mapped according to the information model through the semantic gateway module to form a unified semantic index across CIM / BIM systems, so as to realize data association retrieval between multi-domain systems.

[0008] Optionally, the communication data stream is transformed into a protocol parsing logic sequence using the state transition rules of the protocol feature meta-model library and the pattern matching rules of the communication protocol stack, including: In the electrical domain processing unit of the programmable logic device, the communication data stream is scanned byte by byte, and the consecutively arranged byte segments in the communication data stream are extracted as data blocks to be parsed from the scan results. According to the state transition rules defined in the protocol feature meta-model library, the byte order of the data block to be parsed is dynamically traced. When the byte order displayed by the tracing result meets the preset trigger threshold in the state transition rules, it is marked as a valid protocol fragment. The valid protocol fragment is compared segment by segment with the feature code scanning window in the communication protocol stack. When the comparison result satisfies the pattern matching rules of the communication protocol stack, the protocol identifier boundary corresponding to the valid protocol fragment is determined. The byte segments within the protocol identifier boundary are combined according to the state transition rules and the feature code scanning window to generate a protocol parsing logic sequence containing protocol field segmentation markers.

[0009] Optionally, the step of introducing a programmable logic device to perform real-time matching of the physical layer signal waveforms associated with the protocol feature model library, and switching the physical layer signal waveforms to the corresponding communication protocol stack at the hardware level of the programmable logic device based on the matching results, includes: In the physical layer signal acquisition unit of the programmable logic device, the received physical layer signal waveform is periodically sampled, and the signal level change rate and pulse interval distribution in each sampling period are extracted as signal waveform characteristic parameters. The signal waveform feature parameters are compared with the predefined physical layer feature parameter range in the protocol feature element model library. When the signal level change rate is in the first parameter range and the pulse interval distribution falls into the second parameter range, it is determined that the physical layer signal features of the target protocol stack are matched. A protocol stack switching instruction is generated based on the physical layer signal characteristics of the target protocol stack. The physical layer signal waveform is switched to the corresponding communication protocol stack at the hardware level of the programmable logic device using the protocol stack switching instruction.

[0010] Optionally, if there are unknown protocol features in the communication data stream that do not match the protocol feature meta-model library, then the dynamic reconstruction of the structured feature template is triggered. The reconstructed structured feature template is used to achieve the adaptability of the cross-protocol data parsing rules to the newly added industrial communication protocols, including: In the matching monitoring unit of the protocol feature meta-model library, if a continuous byte segment in the communication data stream is detected that does not match the structured feature template, the starting position where the feature code difference first exceeds a preset threshold in the continuous byte segment is marked as an unknown protocol feature trigger point. A fixed-length byte sequence is extracted from the unknown protocol feature trigger point, and the offset of the repeated feature code position and the distribution of the interval between adjacent fields in the byte sequence are extracted as the structured feature parameters of the new protocol. The structured feature parameters of the newly added protocol are compared with the existing parameter ranges of the protocol feature meta-model library. When the comparison result shows that the offset of the feature code position exceeds the maximum value range, the reconstruction instruction of the structured feature template is triggered. Based on the reconstructed structured feature template, the field segmentation marker generation logic of the protocol parsing logic sequence is adjusted, and the cross-protocol data parsing rules are adapted to the new industrial communication protocols through the adjusted protocol parsing logic sequence.

[0011] Optionally, the step of dynamically tracing the byte order of the data block to be parsed according to the state transition rules defined in the protocol feature meta-model library, and marking it as a valid protocol fragment when the byte order displayed by the tracing result meets the preset trigger threshold in the state transition rules, includes: An initial tracing path is established from the starting byte of the data block to be parsed, and the direction of the initial tracing path is determined by the optional migration direction of the state transition rules defined in the protocol feature meta-model library; The data block to be parsed is scanned in byte order, and the current byte value in the scan result is matched with the current state allowed value of the state transition rule. When a match is successful, the state transition rule is updated to the state index of the next transition state. When the number of consecutive transitions of the state index reaches the trigger threshold defined in the state transition rule, the current scan position is marked as a valid protocol fragment trigger point; Tracing back from the trigger point of the valid protocol fragment to the starting position where the state index first migrates, and extending backward to the ending position where the state index can no longer migrate, the byte segment between the starting position and the ending position is marked as a valid protocol fragment.

[0012] Optionally, the step of generating a protocol stack switching instruction based on the physical layer signal characteristics of the target protocol stack, and switching the physical layer signal waveform to the corresponding communication protocol stack at the hardware level of the programmable logic device using the protocol stack switching instruction, includes: Based on the physical layer signal characteristics of the target protocol stack, a protocol stack switching instruction is generated, and the protocol stack switching instruction is decomposed into a signal conversion rule configuration instruction and a pulse interval configuration instruction. Write the signal conversion rule configuration instructions into the codec and update the signal conversion logic of the codec; Write the pulse interval configuration instruction into the clock synchronization unit and update the pulse interval generation logic of the clock synchronization unit; Based on the updated signal conversion logic and pulse interval generation logic, the hardware level of the programmable logic device is controlled to switch the physical layer signal waveform to the corresponding communication protocol stack.

[0013] Optionally, the step of combining the structured feature template with the protocol parsing logic sequence in the parsing rule generation module to generate middleware-executable cross-protocol data parsing rules includes: Extract the field segmentation threshold and offset parameters from the structured feature template to generate a set of field segmentation parameters; The protocol parsing logic sequence is divided into field blocks containing start position markers and field type identifiers according to byte length; In the parsing rule generation module, the field block is cross-compared with the field segmentation parameter set. When the positional deviation between the starting position marker and the offset parameter is less than the field segmentation threshold, the cross-comparison result is output as a field mapping relationship pair. The field mapping pairs are logically combined with the field type identifiers, and middleware-executable cross-protocol data parsing rules containing field type and position constraints are generated based on the logical combination result.

[0014] Secondly, this application provides a cross-protocol identifier data intelligent parsing system, comprising: The extraction module is used to extract the header feature codes and field offsets of various industrial communication protocol identifiers to form a metadata set. The metadata set is then constructed into a protocol feature meta-model library according to the protocol identifier hierarchy. The protocol feature meta-model library contains structured feature templates for non-standard protocols. The feedback module is used to introduce a programmable logic device to perform real-time matching of the physical layer signal waveform associated with the protocol feature model library. Based on the matching result, the physical layer signal waveform is switched to the corresponding communication protocol stack at the hardware level of the programmable logic device, and the communication protocol stack is fed back to the middleware parsing rule generation module. The receiving module is used to receive communication data streams in real time through the electrical domain processing unit of the programmable logic device. The communication data streams are constrained by the state transition rules of the protocol feature element model library and the pattern matching rules of the communication protocol stack to generate a protocol parsing logic sequence. The generation process of the protocol parsing logic sequence does not depend on the preset protocol library file. The operation module is used to perform combined operations on the structured feature template and the protocol parsing logic sequence in the parsing rule generation module to generate middleware executable cross-protocol data parsing rules; The reconstruction module is used to trigger the dynamic reconstruction of the structured feature template based on the unknown protocol features in the communication data stream that are not matched with the protocol feature meta-model library. The reconstructed structured feature template enables the cross-protocol data parsing rules to adapt to the newly added industrial communication protocols.

[0015] Thirdly, embodiments of this application provide a computing device, including a processing component and a storage component; the storage component stores one or more computer instructions; the one or more computer instructions are invoked and executed by the processing component to implement a cross-protocol identifier data intelligent parsing method as described in the first aspect above.

[0016] In this embodiment, data packet header features and field offsets of various industrial communication protocol identifiers are extracted to form a metadata set. This metadata set is then constructed into a protocol feature meta-model library according to the protocol identifier hierarchy. The protocol feature meta-model library contains structured feature templates for non-standard protocols. A programmable logic device (PLD) is introduced to perform real-time matching of the physical layer signal waveforms associated with the protocol feature meta-model library. Based on the matching results, the PLD signal waveforms are switched to the corresponding communication protocol stack at the hardware level of the PLD, and the communication protocol stack is fed back to the middleware's parsing rule generation module. The PLD is then processed through the electrical domain of the PLD. The processing unit receives communication data streams in real time and transforms them into protocol parsing logic sequences using the state transition rules of the protocol feature meta-model library and the pattern matching rules of the communication protocol stack. In the parsing rule generation module, the structured feature template is combined with the protocol parsing logic sequence to generate middleware-executable cross-protocol data parsing rules. If the communication data stream contains unknown protocol features that do not match the protocol feature meta-model library, dynamic reconstruction of the structured feature template is triggered. The reconstructed structured feature template enables the cross-protocol data parsing rules to adapt to newly added industrial communication protocols.

[0017] The technical solution of this application has the following beneficial effects: By hierarchically modeling data packet header features and field offsets, a structured template library containing non-standard protocol features is formed, solving the problem of traditional protocol libraries being incompatible with private protocols and improving the generalization ability of protocol descriptions. Based on real-time matching of physical layer signal waveforms and hardware-level protocol stack switching using programmable logic devices, microsecond-level physical layer adaptation is achieved, breaking through the millisecond-level latency bottleneck of software protocol stack switching. Combining state transition rules and pattern matching rules, parsing logic sequences are directly generated in the electrical domain processing unit, avoiding reliance on pre-built protocol library files and improving the real-time parsing capability of unknown protocols. Through the combined operation of structured feature templates and parsing logic sequences, executable parsing rules are dynamically generated, eliminating the dependence on manually written parsing scripts. Based on the features of unknown protocols, the template parameter range is expanded to achieve adaptive updates of parsing rules, ensuring continuous system operation when new protocols are added.

[0018] Furthermore, based on the protocol feature meta-model library, an automatic protocol feature extraction engine performs syntax tree decomposition and semantic constraint modeling on industrial protocol messages to generate protocol adaptation templates. A protocol classifier using deep learning algorithms extracts the contextual relationships of unknown protocols, generates semantic feature vectors, and feeds them back to programmable logic devices to achieve dynamic loading of protocol stack parameters. Based on the reconstructed protocol parsing logic sequence, a semantic gateway module is used to perform topological mapping of multi-source data stream fields according to CIM / BIM information models, constructing a unified semantic index across systems. By realizing bidirectional parsing and dynamic adaptation of protocol syntax and semantics, the strong dependence on manual protocol definition in traditional methods is solved; the loading of hardware layer protocol stack parameters is driven by semantic feature vectors, improving the adaptation efficiency of non-standard protocols; and a unified semantic index across domains is constructed, improving the accuracy of data association retrieval between power CIM and building BIM systems and breaking through the barriers of data silos across multiple domains.

[0019] These or other aspects of this application will become more apparent in the following description of the embodiments. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A flowchart of a cross-protocol identifier data intelligent parsing method provided in this application is shown; Figure 2 This paper shows a schematic diagram of the structure of a cross-protocol identifier data intelligent parsing system provided in this application; Figure 3 A schematic diagram of the structure of a computing device provided in this application is shown. Detailed Implementation

[0022] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0023] In some of the processes described in the specification, claims, and accompanying drawings of this application, multiple operations appearing in a specific order are included. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or may be executed in parallel. The operation numbers, such as 101, 102, etc., are merely used to distinguish different operations and do not themselves represent any execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first," "second," etc., in this document are used to distinguish different messages, devices, modules, etc., and do not represent a chronological order, nor do they limit "first" and "second" to different types.

[0024] Researchers have discovered significant bottlenecks in data interoperability between heterogeneous devices using multiple protocols in Industrial Internet of Things (IIoT) scenarios. Existing parsing schemes rely on pre-built protocol libraries and software-level protocol stack switching, leading to difficulties in identifying non-standard protocols, high physical layer adaptation latency, and insufficient dynamic scalability. To address this, a cross-protocol identifier data intelligent parsing method is proposed. Specifically, it constructs a protocol feature meta-model library by extracting multi-protocol data packet header features and field offsets. This is combined with programmable logic devices to achieve real-time matching of physical layer signal waveforms and hardware-level protocol stack switching. Furthermore, it dynamically generates protocol parsing logic sequences based on state transition rules and pattern matching rules. Finally, through the combined operation of structured feature templates and parsing logic, along with an unknown protocol-triggered reconstruction mechanism, adaptive parsing rules are formed. This method enables millisecond-level identification and parsing of non-standard protocols, supports seamless integration of new industrial communication protocols, and reduces system development and maintenance costs in multi-protocol mixed scenarios.

[0025] The technical solution of this application can be applied to the plug-and-play parsing scenario of multi-protocol identifiers for industrial equipment.

[0026] 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 embodiments of this application, and not all embodiments. 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.

[0027] Figure 1 A flowchart of a cross-protocol identifier data intelligent parsing method is provided in this application embodiment, as follows: Figure 1 As shown, the method includes: 101. Extract the header feature codes and field offsets of various industrial communication protocol identifiers to form a metadata set, and construct the metadata set into a protocol feature meta-model library according to the protocol identifier hierarchy. The protocol feature meta-model library contains structured feature templates for non-standard protocols. In this step, the protocol feature meta-model library is a model library built based on the protocol identifier hierarchy, containing structured feature templates for standard and non-standard protocols.

[0028] In this embodiment, firstly, data packet header feature codes (such as function code 0x03) and field offsets (such as the data length field being located in the 5th byte) are extracted from industrial communication protocols such as Modbus and Profinet. Secondly, a tree-like metadata set is established according to the hierarchical relationship of protocol type → version → function code. Thirdly, the distribution of recurring feature code positions in the data frames of non-standard protocols is analyzed (such as 0xAA appearing every 10 bytes). Finally, a structured feature template containing field position ranges and allowed value ranges of feature codes is generated and integrated into the protocol feature meta-model library.

[0029] Suppose a car manufacturer needs to integrate a Siemens PLC (Profinet protocol) with a domestic sensor (proprietary protocol). First, extract the function codes (e.g., 0x8001 represents real-time data) and field offsets (data segment starts at byte 12) of the Profinet and proprietary protocols. Second, analyze the feature code 0x5A that appears repeatedly every 8 bytes in the sensor data frame. Finally, construct a protocol feature element model library, including structured templates of the Profinet and proprietary protocols (function code range 0x8000-0x8FFF, data segment offset 12-20 bytes) and sensor templates (feature code 0x5A offset 0, 8, 16 bytes).

[0030] 102. Introduce a programmable logic device to perform real-time matching of the physical layer signal waveform associated with the protocol feature element model library. Based on the matching result, switch the physical layer signal waveform to the corresponding communication protocol stack at the hardware level of the programmable logic device, and feed back the communication protocol stack to the middleware's parsing rule generation module. In this step, the programmable logic device is an integrated circuit that supports hardware logic reconfiguration and is used for physical layer signal waveform matching and protocol stack switching.

[0031] In this embodiment, the RS-485 or CAN bus signal is first sampled at 1MHz in the physical layer signal acquisition unit of the programmable logic device. Then, the signal level change rate (e.g., 50 jumps per millisecond) and pulse interval distribution (e.g., standard deviation of 0.1ms) within each sampling period are extracted. The extracted parameters are then matched with the predefined physical layer feature parameter range (e.g., the level jump range of Modbus RTU is 40-60 times / ms) in the protocol feature element model library. When the matching result satisfies both the level jump count and pulse interval conditions, the final generated protocol stack switching instruction controls the FPGA to switch to the corresponding communication protocol stack and feeds it back to the middleware's parsing rule generation module.

[0032] For example, continuing the previous example, when a domestic sensor is connected via RS-485, the FPGA detects that its signal waveform level transition frequency is 55 times / ms and the pulse interval standard deviation is 0.09ms. This matches the predefined "private protocol A" parameters (50-60 transitions / ms, standard deviation <0.1ms) in the protocol feature element model library. This triggers the FPGA to switch the signal processing channel to the communication protocol stack corresponding to this protocol and feeds back the protocol identifier 0xA001 to the middleware's parsing rule generation module.

[0033] 103. The communication data stream is received in real time by the electrical domain processing unit of the programmable logic device, and the communication data stream is converted into a protocol parsing logic sequence by the state transition rules of the protocol feature element model library and the pattern matching rules of the communication protocol stack. In this step, the electrical domain processing unit is a module in the programmable logic device that directly processes the electrical signals of the communication data stream, supporting real-time scanning of the data stream at the microsecond level. The protocol parsing logic sequence is an instruction sequence generated by state transition rules and pattern matching rules, used to segment protocol fields.

[0034] In this embodiment, the real-time data stream is first scanned byte by byte and continuous byte segments are cached by the electrical domain processing unit of the programmable logic device (e.g., 16 bytes are read each time). Then, the byte arrangement path of the continuous byte segment is traced according to the state transition rules in the protocol feature model library (e.g., "if the first byte is 0x01, then the next state needs to check whether the third byte is 0xA0"). When the byte arrangement path meets the preset transition path (e.g., 5 consecutive bytes meet the state jump condition), the protocol parsing logic sequence containing the field start mark (e.g., "field 1 starts from the third byte") is finally generated by combining the pattern matching rules of the communication protocol stack (e.g., the feature code must appear in the first 3 bytes of the data block).

[0035] For example, continuing the previous example, after the FPGA receives the data stream "5A 00 23 5A 00 45..." sent by the sensor, the electrical domain processing unit scans byte by byte. According to the state transition rules, it finds the repeating pattern of "0x5A followed by 0x00". Combined with the constraint in the pattern matching rules that the feature code 0x5A must appear every 8 bytes, it generates the protocol parsing logic sequence "Field 1 starts at position 0x5A, length 8 bytes".

[0036] 104. In the parsing rule generation module, the structured feature template is combined with the protocol parsing logic sequence to generate cross-protocol data parsing rules that can be executed by the middleware; In this step, the combination operation involves cross-comparing the field segmentation threshold (allowed positional deviation range) in the structured feature template with the field start position marker in the protocol parsing logic sequence to generate a field mapping relationship.

[0037] In this embodiment, the field segmentation threshold (e.g., allowing ±1 byte deviation) and offset parameter (e.g., field 1 offset 0-8 bytes) of the structured feature template are first extracted from the protocol feature meta-model library. Then, the starting position markers of the fields in the protocol parsing logic sequence (e.g., bytes 0, 8, and 16) are used to calculate the position deviation with the offset parameter. When the deviation calculation result is less than the field segmentation threshold, it is marked as a valid field mapping relationship pair. Finally, an executable cross-protocol data parsing rule containing field type and position constraints is generated based on the field type identifier (e.g., "temperature data field") in the valid field mapping relationship pair.

[0038] For example, continuing the previous example, the parsing rule generation module compares the starting positions of the fields in the sensor parsing logic sequence (bytes 0, 8, and 16) with the templates in the protocol feature meta-model library (offset 0-8 bytes, threshold ±1). It finds that the deviation of the 16th byte is 0, generates the cross-protocol data parsing rule "temperature field starts at byte 16, length 4 bytes", and writes it to the middleware configuration file.

[0039] 105. If there are unknown protocol features in the communication data stream that are not matched in the protocol feature meta-model library, the dynamic reconstruction of the structured feature template is triggered. The cross-protocol data parsing rules are adapted to the newly added industrial communication protocols through the reconstructed structured feature template.

[0040] In this step, dynamic reconstruction is achieved by expanding the parameter range boundaries of the structured feature template to adapt the parsing rules to the new protocol.

[0041] In this embodiment, firstly, consecutive unmatched byte segments (e.g., 20 consecutive bytes that do not match any template) are identified in the matching monitoring unit. Secondly, the position where the first feature code difference in the consecutive unmatched byte segments exceeds the threshold is located (e.g., the difference between the 25th byte value 0xFE and the template expectation 0xA5 exceeds 30%). Then, the 128 bytes after this position are extracted and the offset of the recurring feature code is analyzed (e.g., 0xFE appears every 16 bytes). Finally, the offset range of the structured feature template is expanded according to the feature code offset (adjusted from 0-20 to 0-32) and the field segmentation threshold is updated, so that the cross-protocol data parsing rules can be adapted to the newly added industrial communication protocols.

[0042] For example, continuing the previous example, a new pressure sensor in the factory sends a data stream of "FE 12 34 FE 56 78...". It is detected that the difference between the 0th byte 0xFE and the existing template exceeds the threshold, triggering dynamic reconstruction. 128 bytes are extracted and analyzed to find that 0xFE is repeated every 16 bytes. The template offset is expanded to 0-32 bytes, and a new cross-protocol data parsing rule is generated: "Pressure field starts at 0 bytes and is 16 bytes long", which is adapted to the new industrial communication protocol.

[0043] Steps 101-105 achieve multi-protocol generalization description by constructing a protocol feature meta-model library, utilize programmable logic devices for hardware acceleration to complete physical layer signal matching and protocol stack switching, dynamically generate parsing logic by combining state transition and pattern matching rules, generate adaptive rules through the combination of templates and parsing logic, and trigger dynamic template reconstruction based on unknown protocol features. In industrial equipment multi-protocol mixed scenarios, this achieves millisecond-level parsing of non-standard protocols, plug-and-play functionality for new devices, and zero-downtime updates, reducing equipment interconnection costs.

[0044] To address the challenges of protocol identification, rigid parsing logic, and cross-system semantic fragmentation when accessing heterogeneous data from multiple protocols in industrial equipment, some embodiments also include: 201. Based on the aforementioned protocol feature meta-model library, an automatic protocol feature extraction engine is used to decompose the message structure of various industrial protocols and generate a protocol adaptation template containing a protocol syntax tree and semantic constraints. In step 201, the protocol feature automatic extraction engine is a tool that uses a rule engine and pattern matching algorithm to identify the protocol framework, dynamic fields and construct a syntax tree from the original message.

[0045] In this embodiment, the basic features of the target protocol (such as the message start identifier 0xA0 and the length field offset) are first loaded through a protocol feature meta-model library. A sliding window scan is then performed on the original message using an automatic protocol feature extraction engine, and a bidirectional longest matching algorithm is employed to locate the message's header and tail boundaries. Subsequently, based on a Hidden Markov Model (HMM), the fields within the located message are probabilistically segmented to identify fixed fields (such as the CRC checksum) and variable fields (such as payload data), constructing a multi-branch tree-structured protocol syntax tree. Finally, a constraint solver (such as Z3) is used to verify the logical relationships between the fields in the protocol syntax tree (e.g., "if the function code = 0x03, then the data length must be 4 bytes"), generating a protocol adaptation template containing the syntax tree and semantic constraints.

[0046] 202. Input the protocol adaptation template into the protocol classifier of the deep learning algorithm, extract the contextual correlation of the unknown protocol features through the convolutional neural network, generate the semantic feature vector required for dynamic reconstruction of the protocol stack, and feed the semantic feature vector back to the programmable logic device for dynamic loading of protocol stack parameters. In step 202, the semantic feature vector is a numerical representation that includes protocol context correlation, such as "conditional probability distribution of function code and data length" and "message timing dependency strength", which is used to guide protocol stack reconstruction.

[0047] In this embodiment, the protocol adaptation template is converted into graph-structured data (nodes represent fields, edges represent dependencies) and input into the protocol classifier. The classifier uses a graph convolutional network (GCN) to extract topological features between fields (such as the co-occurrence frequency of adjacent fields) and captures long-distance semantic associations (such as the impact of the message header length field on the tail checksum) through a multi-head attention mechanism. After the output layer generates semantic feature vectors, the vector dimension weights are optimized through reinforcement learning strategies (such as the PPO algorithm) to ensure that key features (such as periodic fields with high real-time requirements) are preferentially mapped to programmable logic devices. The FPGA dynamically allocates hardware resources according to the "timing urgency" parameter in the vector, for example, reserving a dedicated DMA channel for high-priority protocols (such as EtherCAT).

[0048] 203. Based on the reconstructed protocol parsing logic sequence, the fields in the multi-source heterogeneous data stream are topologically mapped according to the information model through the semantic gateway module to form a unified semantic index across CIM / BIM systems, so as to realize data association retrieval between multi-domain systems.

[0049] In step 203, the semantic gateway module is the engine that performs the mapping from data fields to the unified information model. Topology mapping establishes logical associations between data fields based on the physical connectivity of devices.

[0050] In this embodiment, the semantic gateway module classifies the parsed fields according to predefined OWL semantic rules (such as "temperature sensor data belongs to monitoring attributes") based on an ontology reasoning engine (such as Jena), and constructs a vector space mapping between fields and information model entities (such as CIM::CircuitBreaker) through a graph embedding algorithm (such as Node2Vec). Subsequently, a bidirectional LSTM model is used to analyze the temporal dependencies of multi-protocol data streams, identify cross-device semantic chains (such as "circuit breaker state change triggers current value alarm"), and finally generate data association retrieval with topology tags.

[0051] Here is a specific example: In a smart substation renovation project, it is necessary to connect relay protection devices (supporting IEC60870-5-104), environmental sensors (supporting Modbus RTU), and smart circuit breakers (supporting the GOOSE protocol) from different manufacturers. First, in step 201, feature extraction is performed on the original GOOSE protocol messages: a sliding window scan identifies the APDU start identifier 0x01, and HMM is used to segment fields such as AppID and DataSet length. A syntax tree containing "APDU header-status number-dataset" is constructed, and the constraint that "dataset length must match the status number" is verified, generating a GOOSE adaptation template. In step 202, the protocol classifier converts the GOOSE template into graph data, and GCN identifies the strong correlation between "status number and dataset length," generating a semantic feature vector (containing "real-time weight = 0.92"). Based on this, the FPGA dynamically loads high-priority parsing logic and allocates independent hardware threads to process GOOSE messages, ensuring microsecond-level response. In step 203, the semantic gateway maps the "Circuit Breaker Position Status" field in the GOOSE dataset to CIM::Breaker.Position and establishes a topological association with the "Current Exceedance Alarm" field in IEC 60870-5-104 (based on LSTM-recognized temporal causal relationships). Maintenance personnel can then retrieve "circuit breaker actions that caused the current alarm" using the unified semantic index. The system automatically associates GOOSE status change records with IEC 60870 alarm events to pinpoint the source of the fault.

[0052] Steps 201-203 utilize a protocol feature meta-model library and an adaptive extraction engine to automate the generation of parsing templates for multiple industrial protocols. Combining deep learning and dynamic hardware loading technologies significantly improves the accuracy and real-time performance of protocol identification. Finally, through topology mapping and unified indexing of a semantic gateway, semantic barriers between multi-source heterogeneous data are broken down, supporting cross-system collaborative analysis and decision-making. The entire solution reduces the manual configuration cost of protocol adaptation and enhances the plug-and-play capability of industrial equipment.

[0053] To address the issues of low real-time data parsing efficiency, large protocol boundary identification errors, and weak dynamic protocol adaptation capabilities in multi-protocol mixed communication scenarios of industrial equipment, some embodiments convert the communication data stream into a protocol parsing logic sequence using the state transition rules of the protocol feature element model library and the pattern matching rules of the communication protocol stack, including: 301. In the electrical domain processing unit of the programmable logic device, the communication data stream is scanned byte by byte, and the consecutively arranged byte segments in the communication data stream are extracted as data blocks to be parsed from the scan results; In step 301, the electrical domain processing unit is a hardware module in a programmable logic device responsible for signal level conversion and timing synchronization, for example, converting differential signals into parallel byte streams through the SerDes interface.

[0054] In this embodiment, the electrical domain processing unit introduces a sliding window mechanism, with the initial window width set to the minimum protocol message length (e.g., 4 bytes for Modbus RTU). A double-buffered ping-pong operation is employed to achieve uninterrupted byte-by-byte scanning of the communication data stream: when buffer A receives the current byte, buffer B performs start and end marker detection on the received bytes (e.g., 0x7E as the HDLC frame boundary). If a potential delimiter is detected, the window is expanded or contracted according to a dynamic window adjustment strategy (e.g., based on the entropy change rate), ultimately outputting a continuous sequence of byte segments as the data block to be parsed.

[0055] 302. According to the state transition rules defined in the protocol feature meta-model library, perform dynamic path tracing on the byte arrangement order of the data block to be parsed. When the byte arrangement order displayed by the tracing result meets the preset trigger threshold in the state transition rules, mark it as a valid protocol fragment. In step 302, the preset trigger threshold is the condition for determining the validity of the state transition. For example, if three consecutive state transitions conform to the protocol specifications, it is marked as valid.

[0056] In this embodiment, a nondeterministic finite automaton (NFA) is constructed based on the protocol feature meta-model library, loading the target protocol's state transition table (such as the APRD / APWR command jump rules of EtherCAT), to backtrack the byte sequence of the data block to be parsed. Starting from the initial state (such as "idle state"), a state transition is triggered according to the current byte value (such as 0x88A4 representing the EtherCAT header), and the optimal path probability is calculated using the Viterbi algorithm. When the path probability exceeds a preset threshold (such as 0.95) and the number of consecutive jumps meets the minimum frame length requirement, the byte segment is marked as a valid protocol fragment, and its state transition path is recorded.

[0057] 303. Compare the valid protocol fragment with the feature code scanning window in the communication protocol stack segment by segment. When the comparison result satisfies the pattern matching rules of the communication protocol stack, determine the protocol identifier boundary corresponding to the valid protocol fragment. In step 303, the signature scanning window is a predefined fixed-length signature template in the protocol stack, used for precise matching of protocol identifiers. The protocol identifier boundary is the absolute offset of the flag bits at the beginning and end of the protocol header.

[0058] In this embodiment, valid protocol fragments are compared with the feature code scanning window in a multi-level segment-by-segment manner: First, coarse-grained screening is performed, using a Bloom filter to quickly match the feature code hash values ​​(such as CRC32) in valid protocol fragments, eliminating obviously mismatched fragments and generating candidate fragments; second, precise matching is performed, using a bit-level sliding window (such as a 16-bit window) to perform a bit-by-bit XOR operation on the candidate fragments with the feature code template in the communication protocol stack (such as the MessageType field 0x48454144 of OPC UA) to calculate the similarity; finally, dynamic threshold determination is performed, dynamically adjusting the matching threshold according to the similarity (such as real-time protocols requiring 100% matching, and non-real-time protocols allowing 5% error tolerance) to determine the protocol identifier boundary.

[0059] 304. Combine the byte segments within the protocol identifier boundary according to the state transition rules and the feature code scanning window to generate a protocol parsing logic sequence containing protocol field segmentation markers.

[0060] In step 304, the protocol field segmentation tag is a metadata label that identifies the field type (such as a length field or a checksum field) and its boundaries. The protocol parsing logic sequence is a set of instructions that can be loaded into the parsing engine, containing field extraction rules.

[0061] In this embodiment, the byte segments within the protocol identifier boundary are combined using the reverse parse tree generation algorithm: First, field segmentation is performed, inserting segmentation markers (such as "Cmd:1") based on jump events in the state transition rules (such as "jumping from command field to data field"); second, semantic binding is performed, associating the byte segments within the protocol identifier boundary with semantic rules in the protocol metamodel (such as "data field needs to be decoded according to Big-Endian"); finally, logical sequence optimization is performed, arranging the parsing order of the semantically bound byte segments through an instruction scheduling algorithm (such as List Scheduling) to reduce hardware resource conflicts and generate a protocol parsing logical sequence containing protocol field segmentation markers.

[0062] Here is a specific example: Suppose that in a smart production line of an automobile manufacturing plant, the PLC simultaneously receives mixed data streams from a robot controller (EtherCAT protocol), a vision sensor (GigE Vision protocol), and an RFID reader (Profinet IO protocol). In step 301, the electrical domain processing unit performs real-time scanning of the Gigabit Ethernet link: a double-buffering mechanism is used to capture the data stream. When the EtherCAT start character "0xA0" is detected, the window is dynamically expanded to 64 bytes to generate a data block to be parsed. In step 302, the EtherCAT state transition rules ("start character → length → command → WKC count") are loaded, and a valid path with a probability of 0.98 is traced using the Viterbi algorithm. This data block is marked as a valid EtherCAT protocol fragment. In step 303, the valid protocol fragment is compared with the feature code scanning window: a Bloom filter quickly matches the hash value of the EtherCAT FrameType field, and a bit-level sliding window verifies the "0x88A4" header identifier, ultimately locating the protocol boundary as bytes 0-58. Step 304 inserts a segmentation marker (such as "WKC:2" to represent the work counter field) according to the migration path, and generates the protocol parsing logic sequence: "Read the length from byte 2 → Extract the command code from byte 4 → Parse the data by length starting from byte 8".

[0063] Steps 301-304 significantly improve the processing efficiency of multi-protocol mixed data streams through real-time block division and state transition path tracking of the electrical domain processing unit; combined with the multi-level comparison mechanism of the feature code window, the protocol boundary is accurately located and the false recognition rate is reduced; the final generated parsing logic sequence supports dynamic loading and hardware-level optimization, realizing adaptive protocol parsing.

[0064] To address issues such as high latency in physical layer protocol identification, low accuracy in signal feature adaptation, and insufficient efficiency in protocol stack switching in multi-protocol hybrid networking scenarios of industrial equipment, some embodiments introduce a programmable logic device (PLD) to perform real-time matching of the physical layer signal waveforms associated with the protocol feature meta-model library. Based on the matching result, the PLD signal waveforms are switched to the corresponding communication protocol stack at the hardware level of the PLD, including: 401. In the physical layer signal acquisition unit of a programmable logic device, the received physical layer signal waveform is periodically sampled, and the signal level change rate and pulse interval distribution in each sampling period are extracted as signal waveform characteristic parameters. In step 401, the physical layer signal acquisition unit is a module in the programmable logic device responsible for raw signal conditioning and digitization. The pulse interval distribution is the probability density of the time interval between the rising edges of adjacent pulses in a statistical signal.

[0065] In this embodiment, the physical layer signal acquisition unit performs segmented windowed sampling of the received physical layer signal waveform at a fixed sampling rate (e.g., 1 GHz), with each window covering a complete communication cycle (e.g., the 3.5-character silence time of a Modbus RTU). The instantaneous frequency of the physical layer signal waveform is extracted using the Hilbert-Huang Transform (HHT), and the signal level change rate curve is obtained by combining it with sliding differential calculation. Simultaneously, the pulse rising edge interval of the physical layer signal waveform is recorded using a timestamp queue, and the pulse interval distribution is generated using kernel density estimation (KDE). Finally, the signal level change rate and the pulse interval distribution are used as characteristic parameters of the signal waveform.

[0066] 402. The signal waveform feature parameters are compared with the predefined physical layer feature parameter range in the protocol feature element model library. When the signal level change rate is in the first parameter range and the pulse interval distribution falls into the second parameter range, it is determined that the physical layer signal features of the target protocol stack are matched. In step 402, the first parameter range is the range of level change rates allowed by the target protocol stack. The second parameter range is the pulse interval distribution constraint specified by the target protocol stack.

[0067] In this embodiment, the physical layer feature parameter range of the target protocol is loaded from the protocol feature meta-model library: the first parameter range is the rate of change of level [20V / μs, 80V / μs], and the second parameter range is the pulse interval KS test P value ≥ 0.9 (consistent with the theoretical distribution), and a multi-dimensional joint judgment is performed: firstly, the similarity between the measured rate of change curve and the template curve is calculated by dynamic time warping (DTW). If it exceeds the threshold (e.g., 0.85), it proceeds to the next stage; the next stage uses a two-sample Kolmogorov-Smirnov test to verify the cumulative probability difference between the measured pulse interval distribution and the template distribution. If the statistic D < 0.3, it is determined to be a physical layer signal feature that matches the target protocol stack.

[0068] 403. Generate a protocol stack switching instruction based on the physical layer signal characteristics of the target protocol stack, and use the protocol stack switching instruction to switch the physical layer signal waveform to the corresponding communication protocol stack at the hardware level of the programmable logic device.

[0069] In step 403, the protocol stack switching instruction is a control instruction that includes the physical layer configuration parameters of the target protocol.

[0070] In this embodiment, the protocol stack switching instruction generates hardware configuration parameters, including baud rate, level threshold, and encoding method, based on the physical layer signal characteristics of the target protocol stack (such as the HART protocol). Hardware layer switching is achieved through the following sub-steps: first, the pre-stored physical layer configuration is read from the protocol feature meta-model library; second, the physical layer configuration parameters are directly written into the control register of the programmable logic device; finally, the physical layer processing module corresponding to the target protocol is activated, and the physical layer signal waveform is switched to the corresponding communication protocol stack.

[0071] Here is a specific example: Suppose that in the intelligent sensor network of an oil drilling platform, a pressure transmitter supporting the HART protocol (FSK modulation) and a temperature controller supporting the Modbus RTU protocol (RS-485) need to be connected. Step 401 extracts HART signal characteristics: alternating frequency changes between 1200Hz and 2200Hz are detected within the sampling period (level change rate conforms to FSK characteristics); the pulse interval distribution shows a main frequency of 1200Hz and a duty cycle error <3%. In step 402, the protocol feature model library determines that the first parameter range (frequency switching rate 1150-1250Hz) and the second parameter range (duty cycle error <5%) of the HART protocol are both satisfied, triggering protocol matching. Step 403 performs hardware-level switching: the HART protocol configuration (1200Hz FSK, 500Ω impedance) is read from the library; the ADC sampling rate is adjusted to 2kHz, and the IO drive strength is set to 500Ω mode; the RS-485 differential signal receiving module is turned off, the physical layer processing module corresponding to the target protocol is activated, and the physical layer signal waveform is switched to the corresponding communication protocol stack.

[0072] Steps 401-403 simplify the protocol stack switching process and avoid complex reconfiguration operations by quickly loading physical layer signal features and hardware parameters; direct register writing and modular switching design ensure microsecond-level response and improve the compatibility and real-time performance of multi-protocol plug-and-play scenarios in industrial equipment.

[0073] To address issues such as weak unknown protocol identification, delayed feature template updates, and rigid parsing rules in multi-protocol dynamic access scenarios for industrial equipment, some embodiments involve triggering dynamic reconstruction of the structured feature template if an unknown protocol feature in the communication data stream does not match the protocol feature meta-model library. The reconstructed structured feature template then enables the cross-protocol data parsing rules to adapt to newly added industrial communication protocols, including: 501. In the matching monitoring unit of the protocol feature meta-model library, if a continuous byte segment in the communication data stream that does not match the structured feature template is identified, the starting position where the feature code difference first appears in the continuous byte segment and exceeds a preset threshold is marked as an unknown protocol feature trigger point. In step 501, the module in the protocol feature meta-model library of the matching monitoring unit monitors the matching status of the data stream and the template in real time. The unknown protocol feature trigger point is the byte offset position of the first feature code difference exceeding the limit in the data stream.

[0074] In this embodiment of the application, the matching monitoring unit compares the communication data stream with the structured feature template byte by byte using a sliding window comparison algorithm: the window size is the minimum known protocol message length (e.g., 64 bytes), and the window slides in steps of 1 byte; a bitwise XOR operation is performed on each byte in the window, and the difference value is accumulated (e.g., the sum of the difference bits per byte); when the difference values ​​of 3 consecutive windows all exceed the preset threshold (e.g., the total difference bits > 40), the starting position of the first window that exceeds the limit is recorded as the unknown protocol feature trigger point.

[0075] 502. Extract a fixed-length byte sequence from the unknown protocol feature trigger point, and extract the position offset of the recurring feature code and the distribution of the interval between adjacent fields in the byte sequence as the structured feature parameters of the new protocol; In step 502, the signature position offset is the byte distance of a fixed signature relative to the trigger point in the unknown protocol. The adjacent field interval distribution is the frequency distribution of fixed intervals between statistical fields.

[0076] In this embodiment, a fixed-length (e.g., 256 bytes) sequence is extracted from the trigger point and processed as follows: The Apriori algorithm is used to identify frequently occurring byte combinations (e.g., 0xA0 0xB1 repeating at 16-byte intervals); the relative offset between the feature code occurrence position and the trigger point in the byte combination is recorded (e.g., 0xA0 appears in the 8th, 24th, and 40th bytes of the extracted sequence), generating the feature code position offset; the periodicity of field intervals is calculated using an autocorrelation function (e.g., a peak interval of 8 bytes indicates a fixed-length field structure), obtaining the distribution of adjacent field intervals; finally, the feature code position offset and the distribution of adjacent field intervals are used as structured feature parameters for the new protocol. 503. Compare the structured feature parameters of the newly added protocol with the existing parameter range of the protocol feature meta-model library. When the comparison result shows that the offset of the feature code position exceeds the maximum value range, trigger the reconstruction instruction of the structured feature template. In step 503, the extreme value range is the boundary value of the existing protocol feature parameters in the protocol feature meta-model library. The reconstruction instruction is the control signal that triggers the meta-model library update mechanism.

[0077] In this embodiment, the structured feature parameters of the new protocol are compared with the existing parameter ranges in the protocol feature meta-model library: if the feature code offset exceeds the maximum and minimum range of all existing protocols (e.g., the offset of the new protocol function code is 10 bytes, while the maximum of the existing protocols is 5 bytes), it is marked as abnormal; at the same time, the KL divergence between the adjacent field interval distribution and the existing protocols is calculated. If the divergence value is >1.5, it is determined to be a new protocol feature; when the offset and the interval distribution do not match, a reconstruction instruction is triggered and the abnormal parameter set is associated.

[0078] 504. Based on the reconstructed structured feature template, adjust the field segmentation marker generation logic of the protocol parsing logic sequence, and realize the adaptability of the cross-protocol data parsing rules to the new industrial communication protocols through the adjusted protocol parsing logic sequence.

[0079] In step 504, the field segmentation tag generation logic defines how to insert parsing tags based on the feature code position. The cross-protocol data parsing rules are the unified parsing engine logic that supports multi-protocol field mapping.

[0080] In this embodiment, based on the reconstructed structured feature template, the parsing logic is adjusted according to the following process: Based on the feature code offset of the new protocol (e.g., the start code is located at byte 8), a corresponding segmentation marker (e.g., "Header:4" indicates extracting a 4-byte header field starting from byte 8) is inserted into the protocol parsing logic sequence; the adjacent field spacing distribution rule (e.g., a fixed 4-byte interval between each field) is written into the priority queue of the parsing engine, and the field extraction order is dynamically adjusted (e.g., extracting the length field first and then parsing the data by length). The adjusted protocol parsing logic sequence is directly loaded into the programmable logic device to achieve automatic parsing of the new protocol.

[0081] Here is a specific example. Suppose a smart water plant needs to connect to a new water quality monitoring instrument (private protocol Q-Protocal), and its data stream is not recognized by the existing protocol library: In step 501, the matching monitoring unit detects that the consecutive difference values ​​at byte 92 of the data stream exceed the limit (Hamming distance 48 bits), marking it as a trigger point; in step 502, the sequence of bytes 92-220 is truncated, and the feature code 0xC1 is extracted, which appears repeatedly in bytes 8, 24, and 40, with the interval between adjacent fields always being 4 bytes; in step 503, the comparison finds that the feature code offset of 8 bytes exceeds the maximum and minimum range of the meta-model library (originally a maximum of 5 bytes), triggering a reconstruction instruction; in step 504, after reconstructing the template, a segmentation marker "" is added to the parsed logical sequence.<Q_Header:4> (Bytes 8-11 are the header fields), and subsequent field markers are generated at 4-byte intervals (e.g., "Data1:4", "Data2:4"). The adjusted protocol parsing logic sequence is loaded into the FPGA in real time, enabling cross-protocol data parsing rules to adapt to new industrial communication protocols.

[0082] Steps 501-504 achieve adaptive generation of field segmentation rules for unknown protocols by dynamically reconstructing feature templates and parsing logic sequences; based on hardware-level real-time loading capabilities, it ensures zero latency in parsing new protocols, effectively improving the plug-and-play compatibility of industrial equipment with private protocols and reducing protocol extension and maintenance costs.

[0083] To address issues such as low protocol fragment recognition accuracy, insufficient state transition tracking efficiency, and blurred effective data boundaries in multi-protocol mixed communication scenarios of industrial equipment, some embodiments involve dynamically tracking the byte order of the data block to be parsed according to the state transition rules defined in the protocol feature meta-model library. When the byte order displayed in the tracking result meets a preset trigger threshold in the state transition rules, it is marked as a valid protocol fragment, including: 601. Establish an initial tracing path from the starting byte of the data block to be parsed, wherein the direction of the initial tracing path is determined by the optional transition direction of the state transition rules defined in the protocol feature element model library; In step 601, the initial tracing path is the parsing path formed from the starting byte of the data block to be parsed, according to the state transition directions preset by the protocol rules. Optional transition directions are the set of allowed state transition directions defined in the protocol feature meta-model library.

[0084] In this embodiment, the state transition table (such as the state jump rule table of the EtherCAT protocol) of the protocol feature meta-model library is loaded from the first byte of the data block to be parsed, and the tracing path is initialized: the starting byte is associated with the initial state (such as "idle state") defined in the protocol library; a path branch list is generated according to the optional transition direction of the initial state (such as "idle state" allows jump to "header state" or "error state"); and initial weights are assigned to the path branches according to the frequency of protocol occurrence (such as setting the weight of commonly used protocol paths to 0.9) to form the initial tracing path.

[0085] 602. Scan the data block to be parsed in byte order, match the current byte value in the scan result with the current state allowed value of the state transition rule, and update the state transition rule to the state index of the next transition state when the match is successful; In step 602, the allowed values ​​for the current state are the range of byte values ​​allowed for a given state as defined in the protocol library. The state index is an encoding that identifies the current state position.

[0086] In this embodiment, the data block is scanned in byte order and the status index is updated: the current byte (e.g., the value of the 5th byte is 0x03) is checked for inclusion with the allowed range of status values ​​(e.g., "function code state" allows 0x01~0x04); if the inclusion check passes, the path branch is retained and the status index is updated (e.g., jumping from index 1 to index 2); if the match fails, the current path branch is discarded; finally, the weight is dynamically adjusted, and the path weight is updated according to the byte matching degree (e.g., the degree to which the value deviates from the mean) (e.g., if it is a complete match, the weight is +0.1, and if it is a partial match, the weight is +0.05).

[0087] 603. When the number of consecutive transitions of the state index reaches the trigger threshold defined in the state transition rule, the current scan position is marked as a valid protocol fragment trigger point; In step 603, the consecutive migration count is the valid number of consecutive jumps in the state index. The trigger threshold is the minimum number of migrations required to determine a valid protocol segment.

[0088] In this embodiment, the migration count of each path is counted in real time: each time a valid state transition is completed (e.g., from index 2 to index 3), the migration count counter of the corresponding path is incremented by 1; when the counter of a certain path reaches the threshold (e.g., 4 migrations), the current scan position (e.g., the 20th byte) is recorded as the trigger point of a valid protocol fragment; finally, only the path with the highest weight that meets the threshold (e.g., the path with a weight of 0.95) is retained, and the tracking of the remaining paths is terminated.

[0089] 604. Trace backward from the trigger point of the valid protocol fragment to the starting position where the state index first migrates, and extend backward to the ending position where the state index can no longer migrate, and mark the byte segment between the starting position and the ending position as a valid protocol fragment.

[0090] In step 604, the starting position is the byte offset at which the state index first jumps. The ending position is the byte position at which the state index can no longer jump.

[0091] In this embodiment, the segment boundary is determined with the trigger point of the valid protocol segment as the center: First, backtracking is performed to scan backward from the trigger point to locate the first state transition position (such as the 5th byte jumping from the "header state" to the "length state"); then, the backward extension is performed to continue scanning from the trigger point until three consecutive bytes cannot match any state transition rule (such as no match after the 28th byte); finally, segment marking is performed, and the data between the start position (the 5th byte) and the end position (the 28th byte) is marked as a valid protocol segment.

[0092] Here is a specific example: Suppose that in a car production line control system, the PLC receives a mixture of Profinet IO protocol (real-time control instructions) and custom sensor protocol (temperature data). The control system performs protocol parsing on the sensor data block: Step 601 loads the custom protocol status table from the first byte of the data block, with the initial path being "start state → type code state" (weight 0.8); Step 602 scans to the 3rd byte (value 0xA1), matches the allowed values ​​of "type code state" (0xA0~0xAF), and jumps to the "data length state" (index updated to 2, weight increased to 0.85); In Step 603, after 4 consecutive jumps (reaching the threshold), the effective protocol segment trigger point is marked at the 12th byte; In Step 604, backtracking reveals that the first jump is located at the 3rd byte, extending to the 24th byte (no subsequent match), and the effective protocol segment is marked as bytes 3~24.

[0093] The parsing engine extracts the temperature value (bytes 8-11) and status flag (byte 16) from this data to enable plug-and-play parsing of unknown sensor protocols.

[0094] Steps 601-604 accurately identify the boundaries of valid protocol segments through dynamic tracking and weight optimization of state transition paths; combined with threshold triggering and bidirectional calibration mechanisms, significantly reduce noise data interference; and based on predefined rules of the protocol feature library, achieve highly reliable parsing in multi-protocol mixed scenarios of industrial equipment, improving the plug-and-play compatibility of equipment and the real-time performance of data parsing.

[0095] To address issues such as high physical layer protocol adaptation latency, poor coordination between signal conversion and clock synchronization, and frequent hardware resource conflicts in multi-protocol dynamic switching scenarios of industrial equipment, some embodiments include generating a protocol stack switching instruction based on the physical layer signal characteristics of the target protocol stack, and using the protocol stack switching instruction to switch the physical layer signal waveform to the corresponding communication protocol stack at the hardware level of the programmable logic device, comprising: 701. Generate a protocol stack switching instruction based on the physical layer signal characteristics of the target protocol stack, and decompose the protocol stack switching instruction into a signal conversion rule configuration instruction and a pulse interval configuration instruction; In step 701, the signal conversion rule configuration instruction is a set of parameters that defines the physical layer signal encoding / decoding method. The pulse interval configuration instruction is a set of parameters that specifies the timing characteristics of signal pulses.

[0096] In this embodiment, the protocol stack switching instruction is decomposed into two parts based on the physical layer characteristics of the target protocol (such as RS-485 differential level, 9600bps baud rate): the signal conversion rules corresponding to the target protocol (such as drive current intensity 48mA, stop bits 1.5 bits) are extracted through the protocol feature meta-model library to generate a signal conversion rule configuration instruction; the pulse interval requirement (such as baud rate division coefficient 104 corresponding to 9600bps) is converted into the configuration parameters of the clock unit to generate a pulse interval configuration instruction.

[0097] 702. Write the signal conversion rule configuration instruction into the codec and update the signal conversion logic of the codec; In step 702, the codec is a hardware module in a programmable logic device that is responsible for physical layer signal modulation and demodulation.

[0098] In this embodiment, the signal conversion rule configuration instruction is written to the codec through the following process: The encoding type is selected according to the instruction (e.g., switching from NRZ to 4B5B encoding), and the hardware description code of the corresponding encoding module is loaded. The hardware description code and the level threshold (e.g., the -7V / +12V threshold of RS-485) are written to the analog front-end comparator register, completing the instruction writing. Finally, the additional functions required by the target protocol are activated, and the signal conversion logic of the codec is updated.

[0099] 703. Write the pulse interval configuration instruction into the clock synchronization unit and update the pulse interval generation logic of the clock synchronization unit; In step 703, the clock synchronization unit is a hardware module for generating control signal timing. The pulse interval generation logic is a set of parameters that defines the clock division coefficient and duty cycle adjustment rules.

[0100] In this embodiment, the pulse interval configuration command takes effect through the following process: The system clock division value (e.g., 43 corresponds to a 100MHz main frequency) is calculated based on the target baud rate (e.g., 115200bps); the pulse edge alignment accuracy is adjusted through a digital delay-locked loop (DLL) to eliminate the offset of the system clock division value. Finally, the high and low level duration ratio is set (e.g., 1:1 for RS-232, 3:1 for CAN bus dominant level), and the pulse interval generation logic of the clock synchronization unit is updated.

[0101] 704. Based on the updated signal conversion logic and pulse interval generation logic, control the hardware level of the programmable logic device to switch the physical layer signal waveform to the corresponding communication protocol stack.

[0102] In step 704, hardware-level switching is achieved by dynamically configuring the underlying circuit parameters of the programmable logic device to realize the instantaneous switching of the physical layer protocol.

[0103] In this embodiment, the physical layer switching is implemented according to the updated signal conversion logic and pulse interval generation logic as follows: the signal conversion rule configuration instructions of the codec (such as Manchester encoding enable and differential drive strength) are written into the hardware register, and the pulse interval parameters of the clock synchronization unit (such as baud rate division value and synchronization pulse width) are updated to the timer control module; a hardware switching instruction is sent to the programmable logic device so that the new configuration of the codec and clock unit takes effect immediately, and the physical layer signal waveform switching is completed.

[0104] Here is a specific example: Suppose a smart factory needs to switch the communication protocol of its production line controller from RS-485 (Modbus RTU, 9600bps) to Profinet IRT (100Mbps real-time Ethernet): Step 701 decomposes the Profinet IRT protocol features, generating signal conversion instructions (enabling Manchester encoding and MII interface driver) and pulse interval instructions (125MHz clock division); in step 702, the codec writes Manchester encoding rules, disables the RS-485 differential module, and activates the physical layer driver of the MII interface; in step 703, the clock synchronization unit configures a 125MHz division coefficient and adjusts the TX / RX clock phase alignment; in step 704, a hardware switching instruction is triggered, the codec and clock unit synchronously apply the new configuration, and the physical layer signal waveform immediately switches to the Profinet IRT standard. After the switch is completed, the controller directly parses the real-time control instructions of Profinet IRT, while retaining the Modbus RTU link in standby mode, realizing parallel communication of the two protocols.

[0105] Steps 701-704 implement atomic configuration loading of signal conversion and pulse interval to achieve seamless switching of physical layer protocols; the hardware-level instant activation mechanism avoids the initialization delay of traditional protocol stack switching, significantly improving the real-time performance and reliability of multi-protocol dynamic networking of industrial equipment.

[0106] To address the issues of low efficiency in generating field mapping rules, insufficient cross-protocol semantic alignment accuracy, and strong reliance on manual configuration in multi-protocol heterogeneous data parsing scenarios for industrial equipment, some embodiments include combining the structured feature template with the protocol parsing logic sequence in the parsing rule generation module to generate middleware-executable cross-protocol data parsing rules, including: 801. Extract the field segmentation threshold and offset parameters of the structured feature template to generate a set of field segmentation parameters; In step 801, the field splitting threshold is the maximum allowable deviation (e.g., ±2 bytes) between the field start position and the template offset. The offset parameter is the predefined field start byte position in the protocol template.

[0107] In this embodiment of the application, parameters are extracted from the structured feature template: based on the fluctuation range of the field position in historical data statistics (e.g., the length field is located in 3-5 bytes in 99% of scenarios), the field segmentation threshold is set to ±2 bytes; the starting position of all fields in the template is traversed (e.g., function code = 2nd byte, data segment = 6th byte), and a set of field segmentation parameters {(function code, 2), (data segment, 6)} is generated.

[0108] 802. Divide the protocol parsing logic sequence into field blocks containing start position markers and field type identifiers according to byte length; In step 802, the field type identifier is a label that describes the semantics of the field and is associated with the standard semantics in the protocol metamodel library.

[0109] In this embodiment of the application, the protocol parsing logical sequence is divided into blocks: the sequence is cut according to the field length defined by the protocol template (e.g., the header field is fixed at 4 bytes); a start position label (e.g., “Offset:4”) and a type identifier (e.g., “Temperature:Float”) are added to each field block formed after the cut; finally, for fields with undefined lengths (e.g., variable-length data), the maximum length is inferred based on the interval between adjacent fields.

[0110] 803. In the parsing rule generation module, the field block and the field segmentation parameter set are cross-compared. When the position deviation between the starting position mark and the offset parameter is less than the field segmentation threshold, the cross-comparison result is output as a field mapping relationship pair. In step 803, the positional deviation is the absolute difference between the starting position of the field block and the template offset. The field mapping pair is the matching result between the field block and the template parameters.

[0111] In this embodiment, a cross-comparison operation is performed: the starting position of the field block is traversed, and the deviation value is calculated item by item with the offset parameter (e.g., |5-4|=1); if the deviation value is ≤ the segmentation threshold (e.g., 1≤2), the cross-comparison operation result is output as a field mapping relationship pair. At the same time, for the case where multiple field blocks match the same template offset (e.g., both field blocks are mapped to template position 4), the block with the smallest deviation is selected (e.g., deviation 1 is preferred over deviation 2).

[0112] 804. Logically combine the field mapping relationship with the field type identifier, and generate a middleware-executable cross-protocol data parsing rule containing field type and position constraints based on the logical combination result.

[0113] In step 804, the position constraint is the position rule of the field in the protocol.

[0114] In this embodiment, the parsing rules are generated according to the following process: Field mapping pairs (e.g., "Profinet field position 8 → Modbus field position 6") are associated with field type identifiers (e.g., "temperature value") to generate the preliminary rule "position 8 → temperature value"; according to the field order rules of the protocol template (e.g., "temperature value must be 2 bytes after the length field"), the constraint condition "IF preceding field is length field AND offset = length field position + 2" is added to the rule; the constrained rule is converted into middleware executable code (e.g., "READ(offset=8, type=float) AS Temperature"); finally, similar field constraints are merged and the middleware executable code is executed to generate the final cross-protocol parsing rules.

[0115] Here is a specific example: Suppose a smart factory needs to unify the parsing of data from a Modbus RTU temperature controller (temperature field in byte 6) and a Profinet IO pressure sensor (pressure field in byte 8) into a CIM model: Step 801: Extract the Modbus template field segmentation threshold ±2 bytes, and the offset parameter set {(temperature, 6)}. Step 802: Segment the Profinet parsing logic sequence to generate a field block {starting position 8, type identifier "pressure value"}. Step 803: Cross-checking reveals that the deviation between Profinet position 8 and Modbus position 6 is 2 ≤ threshold 2, generating a mapping pair "position 8 → temperature value". Step 804: Associating the mapping pair with the type identifier "pressure value" generates a conflict (due to type mismatch); according to the semantic mapping table of the protocol meta-model library, "pressure value" is corrected to an independent type; the position constraint "pressure value is 4 bytes after the synchronization header" is injected, and the output rule "READ(offset=8, type=float) AS CIM::Sensor.Pressure" is set; finally, the middleware synchronously parses the data of the two protocols according to this cross-protocol parsing rule.

[0116] Steps 801-804 achieve adaptive generation of cross-protocol parsing rules through dynamic binding of mapping pairs and type identifiers and constraint injection; combined with semantic conflict resolution and rule optimization mechanisms, the accurate alignment of multi-protocol data is ensured, significantly reducing manual configuration costs and providing flexible and efficient parsing support for the integration of heterogeneous data from industrial equipment.

[0117] Figure 2 This application provides a schematic diagram of the structure of a cross-protocol identifier data intelligent parsing system, as shown in the embodiments of this application. Figure 2 As shown, the system includes: Extraction module 21 is used to extract the header feature codes and field offsets of various industrial communication protocol identifiers to form a metadata set, and to construct the metadata set into a protocol feature meta-model library according to the protocol identifier hierarchy. The protocol feature meta-model library contains structured feature templates for non-standard protocols. Feedback module 22 is used to introduce a programmable logic device to perform real-time matching of the physical layer signal waveform associated with the protocol feature element model library, and to switch the physical layer signal waveform to the corresponding communication protocol stack at the hardware level of the programmable logic device according to the matching result, and to feed back the communication protocol stack to the middleware parsing rule generation module. The receiving module 23 is used to receive communication data streams in real time through the electrical domain processing unit of the programmable logic device. The communication data streams are constrained by the state transition rules of the protocol feature element model library and the pattern matching rules of the communication protocol stack to generate a protocol parsing logic sequence. The generation process of the protocol parsing logic sequence does not depend on the preset protocol library file. The operation module 24 is used to perform combined operations on the structured feature template and the protocol parsing logic sequence in the parsing rule generation module to generate middleware executable cross-protocol data parsing rules; The reconstruction module 25 is used to trigger the dynamic reconstruction of the structured feature template based on the unknown protocol features in the communication data stream that are not matched with the protocol feature meta-model library. The reconstructed structured feature template enables the cross-protocol data parsing rules to adapt to the newly added industrial communication protocols.

[0118] Figure 2 The aforementioned cross-protocol identifier data intelligent parsing system can perform... Figure 1 The implementation principle and technical effects of the cross-protocol identifier data intelligent parsing method described in the illustrated embodiment will not be repeated here. The specific methods by which each module and unit of the cross-protocol identifier data intelligent parsing middleware system in the above embodiments perform operations have been described in detail in the embodiments related to this method, and will not be elaborated upon here.

[0119] In one possible design, Figure 2 The cross-protocol identifier data intelligent parsing system of the embodiment shown can be implemented as a computing device, such as... Figure 3 As shown, the computing device may include a storage component 31 and a processing component 32; The storage component 31 stores one or more computer instructions, wherein the one or more computer instructions are invoked and executed by the processing component 32.

[0120] The processing component 32 is used for the above Figure 1 The embodiment describes a method for intelligent parsing of cross-protocol identifier data.

[0121] The processing component 32 may include one or more processors to execute computer instructions to complete all or part of the steps in the above-described method. Alternatively, the processing component may be implemented as one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above-described method.

[0122] Storage component 31 is configured to store various types of data to support operations at the terminal. The storage component can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0123] Of course, computing devices may also include other components, such as input / output interfaces, display components, communication components, etc.

[0124] Input / output interfaces provide interfaces between processing components and peripheral interface modules, which can be output devices, input devices, etc.

[0125] The communication components are configured to facilitate wired or wireless communication between computing devices and other devices.

[0126] The computing device can be a physical device or an elastic computing host provided by a cloud computing platform. In this case, the computing device can refer to a cloud server, and the aforementioned processing components, storage components, etc., can be basic server resources rented or purchased from the cloud computing platform.

[0127] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for intelligent parsing of cross-protocol identifier data, characterized in that, include: Extract the header feature codes and field offsets of various industrial communication protocol identifiers to form a metadata set. Construct the metadata set into a protocol feature meta-model library according to the protocol identifier hierarchy. The protocol feature meta-model library contains structured feature templates for standard protocols and non-standard protocols. A programmable logic device is introduced to extract the signal level change rate and pulse interval distribution of the physical layer signal waveform associated with the protocol feature element model library as signal waveform feature parameters. The signal waveform feature parameters are then compared with the range of predefined physical layer feature parameters in the protocol feature element model library to achieve real-time matching. Based on the matching result, the communication protocol stack hardware processing channel corresponding to the physical layer signal waveform is activated at the hardware level of the programmable logic device through a protocol stack switching instruction, and the communication protocol stack is fed back to the middleware parsing rule generation module. The programmable logic device's electrical domain processing unit performs level conversion and timing synchronization on the physical layer signal waveform to receive the communication data stream in real time. The state transition rules of the protocol feature element model library are used to dynamically track the byte order of the communication data stream. Combined with the pattern matching rules of the communication protocol stack, the communication data stream is transformed into a protocol parsing logic sequence containing protocol field segmentation markers. The structured feature template's field segmentation threshold and offset parameters are extracted in the parsing rule generation module and cross-compared with the field start position marker in the protocol parsing logic sequence. When the position deviation is less than the field segmentation threshold, a field mapping relationship pair is output. Based on the field mapping relationship pair and the associated field type identifier, a middleware-executable cross-protocol data parsing rule is generated for intelligent parsing. If there are unknown protocol features in the communication data stream that do not match the protocol feature meta-model library, then the dynamic reconstruction of the structured feature template is triggered to obtain the reconstructed structured feature template so that the cross-protocol data parsing rules can be adapted to the new industrial communication protocol.

2. The method according to claim 1, characterized in that, Also includes: Based on the aforementioned protocol feature meta-model library, an automatic protocol feature extraction engine is used to decompose the message structure of various industrial protocols and generate protocol adaptation templates containing protocol syntax trees and semantic constraints. The protocol adaptation template is input into the protocol classifier of the deep learning algorithm. The contextual correlation of the unknown protocol features is extracted by the convolutional neural network to generate the semantic feature vector required for dynamic reconstruction of the protocol stack. The semantic feature vector is then fed back to the programmable logic device for dynamic loading of protocol stack parameters. Based on the reconstructed protocol parsing logic sequence, the fields in the multi-source heterogeneous data streams are topologically mapped according to the information model through the semantic gateway module to form a unified semantic index across CIM / BIM systems, so as to realize data association retrieval between multi-domain systems.

3. The method according to claim 1, characterized in that, The communication data stream is dynamically path-tracked based on the state transition rules of the protocol feature meta-model library, and combined with the pattern matching rules of the communication protocol stack, the communication data stream is transformed into a protocol parsing logic sequence containing protocol field segmentation markers, including: In the electrical domain processing unit of the programmable logic device, the communication data stream is scanned byte by byte, and the consecutively arranged byte segments in the communication data stream are extracted as data blocks to be parsed from the scan results. According to the state transition rules defined in the protocol feature meta-model library, the byte order of the data block to be parsed is dynamically traced. When the byte order displayed by the tracing result meets the preset trigger threshold in the state transition rules, it is marked as a valid protocol fragment. The valid protocol fragment is compared segment by segment with the feature code scanning window in the communication protocol stack. When the comparison result satisfies the pattern matching rules of the communication protocol stack, the protocol identifier boundary corresponding to the valid protocol fragment is determined. The byte segments within the protocol identifier boundary are combined according to the state transition rules and the feature code scanning window to generate a protocol parsing logic sequence containing protocol field segmentation markers.

4. The method according to claim 1, characterized in that, The process involves introducing a programmable logic device, extracting the signal level change rate and pulse interval distribution of the physical layer signal waveform associated with the protocol feature model library as signal waveform feature parameters, and comparing these signal waveform feature parameters with the predefined range of physical layer feature parameters in the protocol feature model library to achieve real-time matching. Based on the matching result, the communication protocol stack hardware processing channel corresponding to the physical layer signal waveform is activated at the hardware level of the programmable logic device via a protocol stack switching instruction, including: In the physical layer signal acquisition unit of the programmable logic device, the received physical layer signal waveform is periodically sampled, and the signal level change rate and pulse interval distribution in each sampling period are extracted as signal waveform characteristic parameters. The signal waveform feature parameters are compared with the predefined physical layer feature parameter range in the protocol feature element model library. When the signal level change rate is in the first parameter range and the pulse interval distribution falls into the second parameter range, it is determined that the physical layer signal features of the target protocol stack are matched. A protocol stack switching instruction is generated based on the physical layer signal characteristics of the target protocol stack. The physical layer signal waveform is switched to the corresponding communication protocol stack at the hardware level of the programmable logic device using the protocol stack switching instruction.

5. The method according to claim 1, characterized in that, If the communication data stream contains unknown protocol features that do not match the protocol feature meta-model library, then the dynamic reconstruction of the structured feature template is triggered to obtain a reconstructed structured feature template so that the cross-protocol data parsing rules can be adapted to the new industrial communication protocol, including: In the matching monitoring unit of the protocol feature meta-model library, if a continuous byte segment in the communication data stream is detected that does not match the structured feature template, the starting position where the feature code difference first exceeds a preset threshold in the continuous byte segment is marked as an unknown protocol feature trigger point. A fixed-length byte sequence is extracted from the unknown protocol feature trigger point, and the offset of the repeated feature code position and the distribution of the interval between adjacent fields in the byte sequence are extracted as the structured feature parameters of the new protocol. The structured feature parameters of the newly added protocol are compared with the existing parameter ranges of the protocol feature meta-model library. When the comparison result shows that the offset of the feature code position exceeds the maximum value range, the reconstruction instruction of the structured feature template is triggered. Based on the reconstructed structured feature template, the field segmentation marker generation logic of the protocol parsing logic sequence is adjusted, and the cross-protocol data parsing rules are adapted to the new industrial communication protocols through the adjusted protocol parsing logic sequence.

6. The method according to claim 3, characterized in that, The process involves dynamically tracing the byte order of the data block to be parsed according to the state transition rules defined in the protocol feature meta-model library. When the byte order displayed by the tracing result meets the preset trigger threshold in the state transition rules, it is marked as a valid protocol fragment, including: An initial tracing path is established from the starting byte of the data block to be parsed, and the direction of the initial tracing path is determined by the optional migration direction of the state transition rules defined in the protocol feature meta-model library; The data block to be parsed is scanned in byte order, and the current byte value in the scan result is matched with the current state allowed value of the state transition rule. When a match is successful, the state transition rule is updated to the state index of the next transition state. When the number of consecutive transitions of the state index reaches the trigger threshold defined in the state transition rule, the current scan position is marked as a valid protocol fragment trigger point; Tracing back from the trigger point of the valid protocol fragment to the starting position where the state index first migrates, and extending backward to the ending position where the state index can no longer migrate, the byte segment between the starting position and the ending position is marked as a valid protocol fragment.

7. The method according to claim 4, characterized in that, The step of generating a protocol stack switching instruction based on the physical layer signal characteristics of the target protocol stack, and switching the physical layer signal waveform to the corresponding communication protocol stack at the hardware level of the programmable logic device using the protocol stack switching instruction, includes: Based on the physical layer signal characteristics of the target protocol stack, a protocol stack switching instruction is generated, and the protocol stack switching instruction is decomposed into a signal conversion rule configuration instruction and a pulse interval configuration instruction. Write the signal conversion rule configuration instructions into the codec and update the signal conversion logic of the codec; Write the pulse interval configuration instruction into the clock synchronization unit and update the pulse interval generation logic of the clock synchronization unit; Based on the updated signal conversion logic and pulse interval generation logic, the hardware level of the programmable logic device is controlled to switch the physical layer signal waveform to the corresponding communication protocol stack.

8. The method according to claim 1, characterized in that, The process involves extracting the field segmentation threshold and offset parameters of the structured feature template from the parsing rule generation module, performing a cross-comparison operation with the field start position markers in the protocol parsing logic sequence, and outputting a field mapping pair when the position deviation is less than the field segmentation threshold. Based on the field mapping pair and the associated field type identifier, a middleware-executable cross-protocol data parsing rule is generated for intelligent parsing, including: Extract the field segmentation threshold and offset parameters from the structured feature template to generate a set of field segmentation parameters; The protocol parsing logic sequence is divided into field blocks containing start position markers and field type identifiers according to byte length; In the parsing rule generation module, the field block is cross-compared with the field segmentation parameter set. When the positional deviation between the starting position marker and the offset parameter is less than the field segmentation threshold, the cross-comparison result is output as a field mapping relationship pair. The field mapping pairs are logically combined with the field type identifiers, and middleware-executable cross-protocol data parsing rules containing field type and position constraints are generated based on the logical combination result.

9. A cross-protocol identifier data intelligent parsing system, characterized in that, include: The extraction module is used to extract the header feature codes and field offsets of various industrial communication protocol identifiers to form a metadata set. The metadata set is then constructed into a protocol feature meta-model library according to the protocol identifier hierarchy. The protocol feature meta-model library contains structured feature templates for standard protocols and non-standard protocols. The feedback module is used to introduce a programmable logic device, extract the signal level change rate and pulse interval distribution of the physical layer signal waveform associated with the protocol feature element model library as signal waveform feature parameters, and perform interval judgment between the signal waveform feature parameters and the predefined physical layer feature parameter range in the protocol feature element model library to achieve real-time matching. Based on the matching result, the communication protocol stack hardware processing channel corresponding to the physical layer signal waveform is activated at the hardware level of the programmable logic device through a protocol stack switching instruction, and the communication protocol stack is fed back to the middleware parsing rule generation module. The receiving module is used to perform level conversion and timing synchronization processing on the physical layer signal waveform through the electrical domain processing unit of the programmable logic device to receive the communication data stream in real time. It performs dynamic path tracking on the byte order of the communication data stream through the state transition rules of the protocol feature element model library, and combines the pattern matching rules of the communication protocol stack to convert the communication data stream into a protocol parsing logic sequence containing protocol field segmentation markers. The generation process of the protocol parsing logic sequence does not depend on the preset protocol library file. The operation module is used to extract the field segmentation threshold and offset parameters of the structured feature template from the parsing rule generation module, and perform cross-comparison operation with the field start position marker in the protocol parsing logic sequence. When the position deviation is less than the field segmentation threshold, the module outputs the field mapping relationship pair, and generates middleware executable cross-protocol data parsing rules based on the field mapping relationship pair and the associated field type identifier for intelligent parsing. The reconstruction module is used to trigger the dynamic reconstruction of the structured feature template based on the unknown protocol features in the communication data stream that are not matched with the protocol feature meta-model library, so as to obtain the reconstructed structured feature template so that the cross-protocol data parsing rules can be adapted to the new industrial communication protocol.

10. A computing device, characterized in that, It includes a processing component and a storage component; the storage component stores one or more computer instructions; the one or more computer instructions are invoked and executed by the processing component to implement the cross-protocol identifier data intelligent parsing method as described in any one of claims 1 to 7.

Images