An industrial network protocol packet capturing and analyzing method and system

Abstract

The application relates to an industrial network protocol data packet capturing and analyzing method and system, and solves the technical problem that existing industrial protocol analyzing technology has poor adaptability to unknown, private or non-standard protocols. The method comprises the following steps: capturing and screening network data packets for protocol identification. If the protocol is a known protocol, a preset analyzer is called for analysis; if the protocol is an unknown protocol, a protocol feature vector of the unknown protocol is extracted, a candidate protocol and a confidence degree are obtained through neural mapping model reasoning, and whether interactive reasoning is started is dynamically judged according to the candidate protocol and the confidence degree and in combination with a structure matching degree of an existing analyzer, user feedback is obtained, a parameterized protocol template is calibrated, and an executable analysis rule is instantiated and generated, and finally a new analyzer is registered and used, so that adaptive learning and analysis are realized. The application has the following effects: through an adaptive learning mechanism, intelligent identification of unknown protocols, dynamic construction of an analyzer and self-expansion of a system are realized, and a paradigm upgrade from manual reverse analysis to self-evolution of a system is completed.

Description

Technical Field

[0001] This invention relates to the field of industrial automation, and in particular to a method and system for capturing and parsing industrial network protocol data packets. Background Technology

[0002] In industrial control networks, to effectively monitor production status and debug systems, it is often necessary to capture and parse various industrial protocol data packets. Faced with the complex environment of industrial sites with inconsistent protocol standards, numerous proprietary protocols, and the continuous emergence of new protocols, enabling the monitoring system to adaptively identify and accurately parse various protocols, and then extract meaningful industrial variables in real time, has become crucial for ensuring reliable system operation and efficient maintenance.

[0003] Currently, industrial protocol parsing technologies mainly rely on pre-built fixed parsers to decode known protocols, or on pattern matching of surface features such as packet length, port, and fixed signature codes to assist in protocol identification. These methods typically treat protocol parsing as a relatively static, independent process based on syntax rule matching or feature comparison.

[0004] The core limitation of existing technologies lies in their insufficient adaptability and scalability to unknown or non-standard industrial protocols. When faced with communication data lacking predefined parsing rules, existing methods often struggle to achieve accurate identification and reliable parsing, typically requiring manual analysis and customized development by professionals. This not only reduces the system's automation level but also increases the complexity of deployment and maintenance, limiting the widespread application of such technologies in industrial environments with diverse protocol types and heterogeneous equipment. Summary of the Invention

[0005] In order to achieve intelligent identification of unknown protocols, dynamic construction of parsers, and system self-expansion through an adaptive learning mechanism, and to complete the paradigm upgrade from manual reverse analysis to system autonomous evolution, this application provides an industrial network protocol data packet capture and parsing method and system.

[0006] Firstly, this application provides a method for capturing and parsing industrial network protocol data packets.

[0007] Secondly, this application also provides an industrial network protocol data packet capture and parsing system, which adopts the following technical solution:

[0008] An industrial network protocol packet capture and parsing system includes:

[0009] A packet capture module for capturing raw data packets in industrial networks;

[0010] The packet filtering module, connected to the packet capture module, is used to filter the captured raw packets according to preset conditions;

[0011] Protocol resolver registry, used to store and manage multiple protocol resolvers;

[0012] The multi-protocol parsing module connects to the protocol parser registry and is used to call the parsers preset in the protocol parser registry to parse known protocols;

[0013] The variable management module, connected to the multi-protocol parsing module, is used to manage and update variables extracted from data packets;

[0014] The variable display module, connected to the variable management module, is used to display and update variable values ​​in real time.

[0015] The protocol feature extraction and reasoning module is used to extract protocol feature vectors based on the communication waveform and interaction sequence of data packets when the protocol is identified as an unknown or non-standard industrial protocol, and to obtain candidate protocols and their mapping confidence through neural mapping model reasoning.

[0016] The adaptive learning processing module is connected to the protocol feature extraction and inference module and the protocol parser registry, respectively. It is used to dynamically determine whether to start interactive inference based on the confidence distribution of candidate protocols and the structural matching degree of existing parsers. During the interactive inference process, it obtains user feedback, optimizes the neural mapping model, attempts to parse and calibrates parameterized protocol templates, and generates executable protocol parsing rules based on the calibrated or directly obtained parameterized protocol templates and registers them to the protocol parser registry.

[0017] The protocol knowledge base, connected to the adaptive learning processing module, is used to store parameterized protocol templates. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating an industrial network protocol data packet capture and parsing method according to an embodiment of this application. Detailed Implementation

[0019] The present application will be further described in detail below with reference to the accompanying drawings.

[0020] Reference Figure 1 This application discloses a method for capturing and parsing industrial network protocol data packets, comprising:

[0021] Step S1: Capture raw data packets in the industrial network and filter them according to preset conditions, and identify the protocol of the filtered data packets.

[0022] Industrial networks refer to networks used for communication between industrial automation equipment, including industrial Ethernet and fieldbus. For example, Modbus TCP typically runs on Ethernet, while Profibus is based on fieldbus. Raw data packets are unprocessed data frames captured at the network link layer, containing complete frame headers, trailers, and payloads. Network traffic is copied to monitoring ports by configuring port mirroring on a switch, and these data frames are captured using dedicated capture devices (such as a computer with packet capture capabilities). Preset conditions are filtering rules set by the user according to their needs, such as specific IP addresses, port numbers, and protocol types. For example, a user can configure the capture to only capture packets with a source IP of 192.168.1.100 and a destination port of 502 (the default port for Modbus TCP).

[0023] The necessary process is as follows: 1. Packet Capture: The packet capture module captures data frames in the network by creating raw sockets. In Linux systems, by setting the socket option to SOCK_RAW and binding it to a specific network interface, all data frames passing through that interface can be captured. 2. Packet Filtering: The captured data frames are filtered according to preset conditions. Filtering rules can be implemented by constructing BPF filters. For example, if the user-set filtering condition is "capture all packets with a destination port of 502", the BPF filter rule can be represented as tcpdstport502. By compiling these rules into BPF bytecode and loading them into the kernel, packets that meet the conditions can be efficiently filtered out, reducing unnecessary processing overhead. 3. Protocol Identification: Protocol identification is performed on the filtered packets, mainly by analyzing the packet header information to determine its protocol type. For example, for the Modbus TCP protocol, a preliminary judgment can be made by checking whether the destination port in the TCP header of the packet is 502. Furthermore, it is also possible to check whether the payload of the packet conforms to the frame structure of the Modbus protocol, such as whether the Modbus function code field exists. If the protocol type of the data packet is known, proceed directly to step S2; if the protocol type is unknown or non-standard, proceed to step S3 for further processing.

[0024] Step S2: If a known protocol is identified, the corresponding parser pre-installed in the protocol parser registry is invoked for parsing. Known protocols refer to pre-defined and supported industry protocols, such as Modbus TCP, Siemens S7, and EtherNet / IP. The format and semantics of these protocols are clearly defined, and the system can parse them using specific parsers. The protocol parser registry is a component that manages all protocol parsers, responsible for storing and invoking parsers for different protocols. It provides a unified interface, enabling the system to dynamically invoke the appropriate parser based on the protocol type of the data packet. A parser is a software module designed for a specific protocol, used to parse the content of data packets and extract useful information, such as protocol fields and industry variables. The specific execution process can be found in steps S21 to S23.

[0025] Step S3: If the protocol is identified as unknown or non-standard industrial, extract the protocol feature vector based on the communication waveform and interaction sequence of the data packet. Input this vector into the neural mapping model for inference to obtain candidate protocols and their mapping confidence scores. Here, "unknown or non-standard industrial protocol" refers to communication protocols that are not predefined by the system or do not fully conform to known protocol specifications. These protocols may originate from customized industrial equipment or protocol variants that are not widely supported. "Communication waveform" refers to the time-series characteristics of data packets, including packet length, time interval, frequency, etc. These features reflect the communication pattern of the protocol. "Interaction sequence" refers to the sequence of data packets interacting between devices, including request and response pairings. By analyzing the interaction sequence, the semantic features of the protocol can be extracted. "Protocol feature vector" is a vector formed by quantizing features such as the communication waveform and interaction sequence, used to describe the protocol characteristics of the data packet. "Neural mapping model" is a deep learning-based model used to classify and identify unknown protocols. By learning the features of a large amount of known protocol data, the model can infer unknown protocols and output candidate protocols and their confidence scores. For details, refer to steps S31 to S36.

[0026] Step S4: Based on the confidence distribution of candidate protocols and the structural matching degree of the existing parser, dynamically determine whether to initiate interactive reasoning. Here, confidence distribution refers to the set of confidence scores for each candidate protocol output by the neural mapping model. Structural matching degree: Based on multi-dimensional protocol feature vectors, the structural constraints of the existing parser are used to verify the protocol structure, and the calculated structural matching degree characterizes the degree to which the structural features of the current data packet conform to the processing capabilities of the existing parser. Interactive reasoning: A reasoning process requiring user participation, optimizing protocol identification and parsing through user feedback. When the system cannot determine the protocol type, interactive reasoning will be initiated to obtain user input and improve the accuracy of identification. For details, refer to steps S41 to S46.

[0027] Step S5: If the determination is yes, a verification request for fusing candidate protocol information is generated. User feedback containing at least the true identifier of the target protocol is obtained. Based on this feedback and the protocol feature vector, the neural mapping model is optimized, and a parameterized protocol template is obtained according to the true identifier. This template is used to perform trial parsing on the current data packet to obtain trial parsing industrial variables. Specifically: Verification request for fusing candidate protocol information: A request containing candidate protocol information (such as protocol name, confidence level, feature vector, etc.) used to confirm the true type of the protocol with the user. User feedback: The user's response to the verification request, containing the true identifier of the target protocol (such as protocol name, version, etc.). Parameterized protocol template: A configurable protocol parsing template obtained based on the true identifier in the user feedback and used to parse the data packet. Trial parsing industrial variables: Variables extracted after preliminary parsing of the data packet based on the parameterized protocol template, used to verify the accuracy of the parsing.

[0028] The necessary process is as follows: 1. Generate a verification request: When the system determines that interactive inference needs to be initiated, it generates a verification request containing candidate protocol information. This request displays the candidate protocol's name, confidence level, and other information to the user, prompting the user to confirm or provide the correct protocol type. For example, the system might prompt the user: "The current data packet may be a Modbus TCP protocol with a confidence level of 70%. Please confirm whether it is correct or provide the actual protocol name." 2. Obtain user feedback: The user provides feedback based on the prompts. The feedback should at least include the actual identifier of the target protocol, such as the protocol name and version. For example, the user might provide: "The actual protocol is Modbus TCP, version 1.0."

[0029] 3. Optimize the Neural Mapping Model: Optimize the neural mapping model based on the real identifiers provided by users and the previously extracted protocol feature vectors. Specifically, user-confirmed information is added to the model's training dataset as new training samples, and the model is retrained to improve its ability to identify similar unknown protocols. 4. Obtain Parameterized Protocol Templates: Obtain the corresponding parameterized protocol templates from the protocol knowledge base based on the real protocol identifiers provided by users. These templates contain information such as protocol field mappings, data types, and parsing rules, used for subsequent data packet parsing. 5. Trial Parse Industrial Variables: Use the obtained parameterized protocol templates to perform trial parsing of the current data packet. The parsing process includes extracting protocol fields, converting data formats, and generating trial parsing industrial variables. For example, the trial parsing result might show a register address of 40001, a value of 1234, and a timestamp of January 22, 2024, 14:30:00. These trial parsing industrial variables will be used for subsequent verification and calibration.

[0030] Step S6: Present the trial parsed industrial variables to the user for secondary verification, receive correction feedback, and use this feedback to calibrate the field mapping or data conversion rules of the parameterized protocol template.

[0031] The process includes: Secondary verification: The user confirms the trial parsing results to ensure their accuracy. Correction feedback: User-provided corrections to the trial parsing results, which may include adjustments to variable names, values, or data formats. Field mapping or data conversion rule calibration: Adjusting the field mapping relationships or data conversion rules in the parameterized protocol template based on user feedback to improve the accuracy and adaptability of the parsing. The necessary processes described above can be found in steps S61 to S64.

[0032] Step S7: If the determination is negative, then based on the candidate protocol with the highest confidence level, retrieve the corresponding parameterized protocol template from the protocol knowledge base. The protocol knowledge base is a database storing information related to various industrial protocols, including protocol field mappings, data types, and parsing rules. The protocol knowledge base provides the system with a rich set of protocol templates for parsing different types of industrial protocol data packets. The parameterized protocol template is a configurable protocol parsing template containing information such as protocol field mappings, data types, and parsing rules. Through parameterized design, the template can be adjusted and optimized according to specific needs.

[0033] The necessary process is as follows: 1. Determine the candidate protocol with the highest confidence: In step S3, the neural mapping model outputs multiple candidate protocols and their confidence scores. The system selects the candidate protocol with the highest confidence score as the target protocol. 2. Obtain the parameterized protocol template from the protocol knowledge base: Based on the determined target protocol name, the system retrieves the corresponding parameterized protocol template from the protocol knowledge base. The protocol knowledge base is a structured data storage where each protocol has a detailed template description. For example, for the "ModbusTCP" protocol, the template might contain the following:

[0034] Field Mapping: Defines the location and meaning of each field in the protocol, such as transaction identifier, protocol identifier, length, unit identifier, function code, register address, etc. Data Type: Specifies the data type of each field, such as integer, floating-point, boolean, etc. Parsing Rules: Provides specific rules on how to extract and convert field values ​​from data packets, such as how to handle byte order (big-endian or little-endian) and how to calculate checksums, etc.

[0035] 3. Loading the parameterized protocol template: After obtaining the parameterized template of the target protocol from the protocol knowledge base, the system loads it into the parser. The loading process includes:

[0036] Field Mapping Loading: Loads the field mapping information from the template into the parser's field mapping table. Data Type Configuration: Configures the parser's data processing rules based on the data types defined in the template. Parsing Rule Initialization: Initializes the parsing rules from the template into the parser, ensuring that the parser can parse data packets according to the correct rules.

[0037] 4. Parsing Preparation: After loading, the system will use the parameterized protocol template to parse the current data packet. The parsing process will strictly follow the field mappings, data types, and parsing rules in the template to ensure accurate extraction of industrial variables from the data packet.

[0038] Step S8: Based on the calibrated or directly obtained parameterized protocol template, and combined with key field information extracted from the protocol feature vector, an executable protocol parsing rule is instantiated and generated. The parameterized protocol template is a configurable protocol parsing template containing information such as protocol field mappings, data types, and parsing rules. Through parameterized design, the template can be adjusted and optimized according to specific needs. Key field information refers to important information extracted from the protocol feature vector, used to determine the position, length, and data type of specific fields in the data packet. Executable protocol parsing rules are specific parsing rules generated based on the parameterized protocol template and key field information, which can be directly applied to the data packet parsing process. The above necessary processes can be referred to steps S81 to S84.

[0039] Step S9 involves registering the instantiated protocol parsing rules as plugins to the protocol parser registry, forming a new protocol parser. The instantiated protocol parsing rules are the specific executable parsing rules generated in step S8, used to parse data packets of a specific protocol. The plugin format encapsulates the new parsing rules as independent modules or plugins, allowing them to be dynamically loaded and used without modifying the system's core code. The protocol parser registry is a component that manages all protocol parsers, responsible for storing and invoking parsers for different protocols. Through the registry, the system can dynamically manage and use various protocol parsers.

[0040] The necessary process is described below: 1. Encapsulation as a plugin: The instantiated protocol parsing rules generated in step S8 are encapsulated as a plugin. The plugin design needs to follow the system's plugin interface specification to ensure that it can be recognized and loaded by the protocol parser registry. A plugin typically contains the following:

[0041] Parser Interface Implementation: Implements the system-defined parser interface to ensure plugins can be called uniformly. Parsing Rules: Contains the specific parsing logic and rules used to parse data packets of a specific protocol. Metadata: Describes basic information about the plugin, such as protocol name, version, and author.

[0042] 2. Register to the protocol resolver registry: Register the packaged plugin to the protocol resolver registry. The registration process typically includes the following steps:

[0043] Loading Plugins: The system loads new plugins through the plugin manager. The plugin manager reads the plugin's metadata and verifies its validity and compatibility. Registering Parsers: The system registers the parser instances from the plugins into the protocol parser registry. The registry stores references to the parsers and associates them with the protocol names for easy subsequent calls.

[0044] 3. Establishing a new protocol parser: Once a plugin is successfully registered, the system will manage its instantiated parsing rules as new protocol parsers. These new parsers can be dynamically invoked by the system to parse data packets for the corresponding protocol. For example, if the newly registered protocol is "CustomProtocol," the system will automatically invoke the corresponding parser when it subsequently captures data packets for that protocol.

[0045] Step SA involves parsing the data packets using a parser from the protocol parser registry. The protocol parser registry is a component that centrally manages all protocol parsers, responsible for storing, retrieving, and invoking parsers for different protocols. It provides a unified interface, enabling the system to dynamically select and use the appropriate parser based on the protocol type of the data packet. A parser is a software module designed for a specific protocol, used to parse the content of data packets and extract useful information, such as protocol fields and industry variables.

[0046] The necessary process is as follows: The system calls the parser returned by the registry to parse the data packet. The parser extracts key information from the data packet, such as protocol fields and industry variables, according to its internal parsing rules. For example, the ModbusTCP parser will extract information such as transaction identifiers, function codes, register addresses, and values.

[0047] Step SB extracts industrial variables from the parsed data packet and displays the current values ​​of the extracted industrial variables in real time.

[0048] The necessary process is as follows: 1. Extracting Industrial Variables: In step SA, after parsing the data packet, the protocol parser extracts the key information contained in the data packet. This information is converted into the form of industrial variables, which typically include variable names, values, and timestamps. For example, the parser might extract the following variables from a Modbus TCP packet:

[0049] Variable name: Temperature_Sensor_1. Variable value: 25.5°C. Timestamp: 2024-01-22T14:30:00Z.

[0050] 2. Variable Storage and Updates: Extracted industrial variables are stored in the system's variable management module. This module is responsible for maintaining the latest values ​​of the variables and updating these values ​​after parsing new data packets. For example, if the value of Temperature_Sensor_1 in a new data packet becomes 26.0°C, the variable management module will update the value of that variable and record the new timestamp.

[0051] 3. Real-time display of variable values: The system displays the current values ​​of industrial variables in real time through a user interface or other display devices. Display methods may include:

[0052] Graphical Interface: Displays variable values ​​in numerical, chart, or dashboard format on the monitoring system's graphical interface. Text Display: Updates variable values ​​in real-time as text in the console or log window.

[0053] Data push: Pushing variable values ​​to other systems (such as SCADA systems) for further processing and display.

[0054] 4. Update Frequency and Optimization: The system sets the update frequency of variable values ​​based on actual needs. For critical variables, the update frequency may be higher (e.g., once per second), while for non-critical variables, the update frequency can be appropriately reduced. Furthermore, the system optimizes the display logic to ensure that the interface remains smooth and responsive even with high-frequency updates.

[0055] Capturing raw data packets in an industrial network and filtering them based on preset criteria includes:

[0056] Step S11: Initiate monitoring of the target industrial network communication link to capture raw data packets flowing through the link. The target industrial network communication link refers to the physical or logical link in an industrial network used for communication between devices, such as an Ethernet link or fieldbus. Monitoring involves real-time monitoring of data transmission on the link via a network interface or dedicated equipment to capture passing data packets. Raw data packets refer to unprocessed data frames captured at the network link layer, containing a complete frame header, frame trailer, and payload.

[0057] The necessary process is as follows: 1. Selecting a monitoring interface: The system first needs to determine the target industrial network communication link to monitor. This can be achieved by configuring a network interface or connecting to a specific network device (such as the monitoring port of a switch). For example, if the target link is an Ethernet-based industrial network, the system can select a specific Ethernet interface for monitoring. 2. Configuring the monitoring mode: To capture all packets on the link, the system needs to configure the monitoring interface to promiscuous mode. In this mode, the interface captures all packets passing through the link, not just those destined for the local machine. This step ensures that the system can comprehensively monitor network communication. 3. Starting monitoring: The system starts the monitoring process and begins capturing raw packets flowing through the target link in real time. The monitoring process typically stores the captured packets in a memory buffer for later processing. For example, the system can use a dedicated network packet capture tool (such as Wireshark's backend tool pcap) to achieve this function. 4. Real-time packet capture: The system continuously captures packets and ensures the real-time nature of the capture process. This means that the system needs to process packets efficiently to avoid data loss due to buffer overflows or processing delays. For example, the system can use multi-threading or asynchronous processing mechanisms to optimize capture performance. 5. Preliminary Processing and Storage: The captured raw data packets undergo preliminary processing, such as removing Ethernet frame headers and verifying data integrity. The processed data packets are then stored in the system's memory buffer or temporary storage, awaiting subsequent filtering and parsing steps.

[0058] Step S12: The captured raw data packets are filtered in real time according to one or more filtering conditions preset by the user. The filtering conditions include at least one of the following: source IP address, destination IP address, port number, and protocol type.

[0059] The filtering criteria are user-defined rules used to select specific data packets of interest from a large volume of captured packets. Common filtering criteria include source IP address, destination IP address, port number, and protocol type. Real-time filtering immediately filters data packets while they are being captured, ensuring the system can efficiently process and analyze data of interest, reducing unnecessary computational and storage overhead.

[0060] The necessary procedures are as follows:

[0061] 1. User-defined filtering conditions: Users define the required filtering conditions through the system interface or configuration file. These conditions may include, but are not limited to:

[0062] Source IP address: Specifies the source IP address of the data packet, such as 192.168.1.100. Destination IP address: Specifies the destination IP address of the data packet, such as 192.168.1.200. Port number: Specifies the source or destination port of the data packet, such as 502 (the default port for Modbus TCP).

[0063] Protocol type: Specifies the protocol type of the data packet, such as TCP, UDP, or ModbusTCP.

[0064] Users can set single conditions or combinations of conditions to precisely filter out the desired data packets.

[0065] 2. Real-time filtering of captured data packets: The system applies user-defined filtering conditions in real time while capturing data packets. The filtering process is typically completed before the data packets enter the system memory buffer to improve efficiency. For example, the system can use the following logic for filtering:

[0066] Filtering based on IP address: Checks if the source and destination IP addresses of data packets meet user-defined criteria. Filtering based on port number: Checks if the source and destination ports of data packets meet user-defined criteria. Filtering based on protocol type: Checks the protocol field of data packets to determine if it matches the user-defined protocol type.

[0067] 3. Processing of screening results:

[0068] The filtered data packets were divided into two categories:

[0069] Data packets that meet the criteria: These data packets will be processed further, such as for protocol identification and parsing.

[0070] Data packets that do not meet the criteria: These data packets will be discarded to reduce the burden of subsequent processing.

[0071] The system can record the number and type of data packets that do not meet the criteria, so that users can understand the effectiveness of the filtering process.

[0072] The process of calling the corresponding parser pre-installed in the protocol parser registry includes:

[0073] Step S21: Submit the filtered data packets to the protocol resolver registry.

[0074] The necessary process is as follows: 1. Data packet caching and preparation: After filtering in step S12, data packets that meet the filtering criteria are stored in the system's memory buffer. These data packets have completed the initial filtering and are ready for further parsing. The system needs to perform simple preprocessing on these data packets, such as:

[0075] Ethernet header removal: If the data packet was captured from an Ethernet link, the system needs to remove the Ethernet frame header to extract the IP layer and above data. Integrity check: Ensure the integrity of the data packet, such as checking if the length of the IP header matches the actual length of the data packet. Data packet formatting: Convert the data packet into a format suitable for the parser to process, such as converting the binary content of the data packet into a byte stream.

[0076] 2. Submit to Protocol Parser Registry: The system submits the prepared data packet to the protocol parser registry. This step typically involves the following operations:

[0077] Create a parsing request: The system creates a parsing request for each data packet, which includes information such as the data packet content, capture timestamp, and protocol type.

[0078] Calling the registry interface: The parsing request is submitted to the registry through the interface provided by the protocol parser registry. The registry is responsible for receiving these requests and performing subsequent processing based on the protocol characteristics of the data packets.

[0079] Step S22: Through the protocol parser registry, match and select the corresponding target parser based on the protocol characteristics of the data packet.

[0080] The necessary process is as follows: 1. Extracting packet protocol features: The system extracts key protocol feature information from the submitted data packets. This information is used to match a suitable parser. Common protocol features include:

[0081] Protocol type: such as TCP, UDP, etc. Port number: such as port 502 for Modbus TCP, port 102 for Siemens S7. Protocol signature: Some protocols have fixed signatures at specific locations in the data packet, such as the Modbus TCP protocol identifier being 0x0000. Other characteristics: such as data packet length, values ​​of specific fields, etc.

[0082] For example, for a TCP packet, the system may extract features such as the protocol type being TCP, the destination port number being 502, and the protocol identifier being 0x0000.

[0083] 2. Query the protocol parser registry: The system matches the extracted protocol features with records in the protocol parser registry. The registry stores the mapping relationship between protocol features and parsers, for example:

[0084] Protocol type: TCP, port number: 502 → ModbusTcpParser. Protocol type: UDP, port number: 102 → SiemensS7Parser.

[0085] The system searches the registry for a corresponding parser based on the protocol characteristics of the data packets. If a matching parser is found, it is marked as the target parser.

[0086] 3. Matching logic:

[0087] The matching process is typically performed according to the following priority:

[0088] Exact match: First, attempt to match the protocol type, port number, and protocol signature exactly. If a complete match is found, select it as the target parser.

[0089] Partial match: If an exact match fails, try a partial match, such as matching only the protocol type and port number.

[0090] Default Match: If a partial match also fails, a default general parser can be selected to handle unknown or incompletely matched protocols.

[0091] 4. Select Target Parser: Once a matching parser is found, the system selects it as the target parser and prepares for subsequent parsing operations. If no matching parser is found, the system can log and prompt the user, or mark the packet as "unknown protocol" for further analysis. 5. Record Matching Results: The system records the matching process and results, including the protocol characteristics of the packet, the name of the selected parser, and other information. These records are used to monitor the system's operational status, help users understand the packet processing, and perform debugging and optimization when necessary.

[0092] Step S23: Invoke the target parser to perform protocol decoding and data extraction on the data packet.

[0093] The necessary process is as follows: 1. Invoking the parser: The system calls the target parser selected in step S22, passing the data packet to the parser for processing. 2. Decoding the data packet: The parser decodes the data packet, extracting key fields such as the protocol header, function code, and data area. For example, the ModbusTCP parser will extract the transaction identifier, function code, and register value. 3. Extracting industrial variables: Industrial variables are extracted from the decoded fields, including variable name, value, and timestamp. For example, Pressure_Sensor_1 is extracted, with a value of 1234.5 and a timestamp of 2024-01-22T14:30:00Z. 4. Storage and feedback: The extracted variables are stored in the system and fed back to the user or monitoring system in real time to ensure the timeliness and accuracy of the data.

[0094] Based on the communication waveform and interaction sequence of the data packet, the protocol feature vector is extracted, input into the neural mapping model for inference, and candidate protocols and their mapping confidence scores are obtained, including:

[0095] Step S31: Based on the current data packet to be identified, obtain the context information of the communication session to which the data packet belongs. The context information includes the byte sequence characteristics of the current data packet to be identified and the interaction sequence of multiple data packets that are sequentially consecutive in the session to which the current data packet to be identified belongs.

[0096] The necessary process is as follows: 1. Determine the communication session: The system first determines the communication session to which the data packet to be identified belongs. The session can be identified by the five-tuple of the data packet (source IP, destination IP, source port, destination port, protocol type). For example, a TCP session can be uniquely identified by the four-tuple of its TCP connection (source IP, destination IP, source port, destination port).

[0097] 2. Extract byte sequence features:

[0098] The system extracts the byte sequence features of the current data packet, including:

[0099] Data packet length: The total number of bytes in the data packet. Byte distribution: The distribution of different byte values ​​in the data packet, such as counting the frequency of occurrence of each byte value. Specific field value: Extracting the field value from a specific location in the data packet, such as the version number or type field in the protocol header.

[0100] 3. Constructing an Interaction Sequence: The system extracts multiple time-sequentially consecutive data packets from the current session to form an interaction sequence. This sequence reflects the interaction patterns between data packets, such as request-response pairs or continuous data transmission. The system can record information such as the timestamp, length, and direction (sending or receiving) of each data packet. 4. Integrating Context Information: The extracted byte sequence features and interaction sequence information are integrated into the context information of the current data packet. This context information provides rich background data for subsequent feature extraction and protocol identification, helping to improve the accuracy and reliability of protocol identification.

[0101] Step S32: Perform statistical analysis on the byte sequence features to extract static features that characterize the syntax structure of the data packet.

[0102] Among them, byte sequence features: the binary content of the data packet, reflecting the specific structure and content of the data packet. Static features: fixed features extracted from the byte sequence of the data packet, mainly reflecting the syntactic structure of the data packet, and not dependent on time series or interaction patterns.

[0103] The necessary process is as follows: 1. Preliminary processing of byte sequence: Convert the binary content of the data packet into an analyzable form, such as extracting the payload part of the data packet and removing irrelevant header information (such as Ethernet frame header, IP header, etc.) in order to focus on the core content of the data packet.

[0104] 2. Statistical Analysis:

[0105] Perform statistical analysis on the byte sequence to extract the following types of static features:

[0106] Byte value distribution: Statistics on the frequency of each byte value (0-255) in the data packet. For example, some protocols may frequently use certain byte values ​​at specific locations. Byte sequence length: Records the total length of the data packet and the length of specific fields. For example, the length of the protocol header, the length of the data area, etc. Byte values ​​at specific locations: Extracts byte values ​​at specific locations in the data packet; these locations may correspond to key fields of the protocol, such as function codes, command types, etc. Byte sequence entropy: Calculates the information entropy of the byte sequence, reflecting the randomness of the data. High entropy values ​​may indicate that the data is encrypted or irregular, while low entropy values ​​may indicate that the data has a certain structure.

[0107] 3. Feature Extraction: Based on the statistical analysis results, extract static features that characterize the syntax structure of the data packets. These features may include:

[0108] Byte value frequency vector: Converts the frequency distribution of byte values ​​into a fixed-length vector, such as a vector of length 256, where each element represents the frequency of a byte value. Field length feature: Extracts the length of the protocol header and data area to form a length feature vector. Key field value: Extracts the byte value at a specific location to form a key field feature vector. Entropy feature: Uses the calculated entropy value as a feature to reflect the regularity of the data.

[0109] 4. Feature Vector Construction: The extracted static features are combined into a feature vector. For example, the feature vector may include byte value frequency vectors, field length features, key field values, and entropy features. This feature vector will serve as input for subsequent protocol identification.

[0110] Step S33: Perform structural analysis and pattern mining on the interaction sequence to extract dynamic features that represent the application layer session logic.

[0111] Interaction sequence: A collection of multiple data packets arranged chronologically within the same communication session. These data packets demonstrate the interaction process between the communicating parties. Dynamic characteristics: Features reflecting the temporal relationships, interaction patterns, and session logic of data packets during the interaction process, typically related to the behavior and semantics of the protocol.

[0112] The necessary procedures are as follows:

[0113] 1. Interaction Sequence Extraction: Extract multiple temporally consecutive data packets from the current session to form an interaction sequence. Each data packet includes the following information:

[0114] Packet direction: Whether the packet is sent from the client to the server or from the server to the client. Packet length: The length in bytes of each packet. Timestamp: The time the packet was captured. Protocol fields: Key field values ​​in the packet, such as function code and command type.

[0115] 2. Structural Analysis: Perform structural analysis on the interaction sequence to identify the logical relationships between data packets. For example:

[0116] Request-response pattern: Identify which packets are requests and which are responses, and match the relationships between them.

[0117] Session phase division: Based on the content and timing of data packets, the session is divided into different phases, such as connection establishment, data transmission, and connection closure.

[0118] 4. Pattern Mining: Pattern mining techniques are used to extract typical patterns and behavioral features from interaction sequences. For example:

[0119] Periodic patterns: Identify the periodicity of data packet transmission, such as periodic heartbeat packets or data reporting.

[0120] Interaction frequency: Calculates the average time interval between requests and responses, reflecting the frequency of interactions. Packet length variation: Analyzes the trend of packet length changes during the interaction process, such as whether the packet length increases or decreases over time.

[0121] 4. Dynamic Feature Extraction: Based on the results of structural analysis and pattern mining, dynamic features representing the application layer session logic are extracted. These features may include:

[0122] Interaction pattern characteristics: For example, the matching degree of the request-response pattern can be represented by a numerical value.

[0123] Time interval characteristics: The time interval between a request and a response, which can be represented by statistics such as mean or standard deviation. Data packet length variation characteristics: The trend in data packet length variation, which can be represented by slope or fluctuation range. Session phase characteristics: The duration of different phases of a session, which can be represented by time length.

[0124] Step S34 involves fusing static and dynamic features to construct a multi-dimensional protocol feature vector. The specific process can be found in steps S341 to S343, and will not be elaborated upon here.

[0125] Step S35: Input the protocol feature vector into the pre-trained neural mapping model, and the neural mapping model performs inference based on the protocol feature vector.

[0126] Among them, the protocol feature vector is a multi-dimensional vector constructed by fusing static and dynamic features in step S34, used to characterize the protocol characteristics of data packets. The neural mapping model is a pre-trained deep learning model used to infer the protocol type and confidence level of data packets based on the protocol feature vector.

[0127] As an example and not a limitation, the neural mapping model used in this application can be constructed as follows:

[0128] Model Architecture: An improved Transformer encoder-based architecture is adopted. The input is the protocol feature vector generated in step S34 (assuming a dimension of 256). The model consists of an input embedding layer, a multi-head self-attention layer with 4 attention heads (for capturing internal dependencies of features), a feedforward neural network layer (FFN, dimension 512), and an output classification layer.

[0129] Training Data and Preparation: Over 500,000 data packet samples of known protocols (such as ModbusTCP, PROFINET, EtherNet / IP, OPCUA, etc.) were collected from public and private industrial protocol datasets. Steps S31 to S34 were performed on each sample to generate a protocol feature vector, with the protocol type as the label.

[0130] Training process and parameters: The PyTorch framework was used, employing the cross-entropy loss function and the AdamW optimizer. Training hyperparameters were set as follows: initial learning rate (lr) = 3e-4, batch size (batch_size) = 128, and training epochs (epochs) = 50. The learning rate was adjusted using a cosine annealing strategy with warm-up.

[0131] Output: The model output layer is a fully connected layer followed by a Softmax function, which generates a probability distribution representing the mapping confidence of the input data packet belonging to each candidate protocol type.

[0132] The necessary steps are as follows: 1. Prepare protocol feature vectors: Standardize or normalize the protocol feature vectors generated in step S34 to ensure that the data format of the input model meets the requirements of the pre-trained model. For example, scale the feature values ​​to the [0,1] interval or perform Z-score standardization. 2. Load the pre-trained model: Load the pre-trained neural mapping model. This model is usually a deep learning model, such as a multilayer perceptron (MLP), convolutional neural network (CNN), or recurrent neural network (RNN), specifically designed for protocol recognition tasks. The model has learned the mapping relationship between various protocol features and protocol types during the training phase. 3. Input feature vectors: Input the prepared protocol feature vectors into the neural mapping model. The model receives the feature vectors as input and processes them through its internal neural network structure.

[0133] 4. Model Inference: The neural mapping model infers from the input protocol feature vector, calculating the confidence score for each known protocol type. The model's output is typically a probability distribution representing the probability that a data packet belongs to different protocol types. For example, the model might output:

[0134] ModbusTCP:0.85.

[0135] Siemens S7:0.10.

[0136] EtherNet / IP:0.05.

[0137] 5. Obtain the inference results: Obtain at least one candidate protocol type and its corresponding confidence score from the model's output. Typically, the protocol with the highest confidence score is selected as the most likely protocol type, but multiple candidate protocols and their confidence scores can be retained for further processing in subsequent steps.

[0138] Step S36: Output at least one candidate protocol type and the mapping confidence level corresponding to each candidate protocol type through the neural mapping model.

[0139] The necessary procedures are as follows:

[0140] 1. Obtaining Model Output: After completing inference, the neural mapping model outputs a probability distribution representing the probability that data packets belong to different protocol types. For example, the model might output the following probability distribution:

[0141] ModbusTCP:0.85.

[0142] Siemens S7:0.10.

[0143] EtherNet / IP:0.05.

[0144] 2. Determine candidate protocols: Based on the probability distribution output by the model, select protocols with higher confidence levels as candidate protocol types. Typically, one or more protocols with the highest confidence levels are selected as candidates. For example, all protocols with confidence levels exceeding a certain threshold (e.g., 0.05) can be selected as candidate protocols.

[0145] 3. Output candidate protocols and their confidence scores: Output the selected candidate protocols and their corresponding confidence scores for use in subsequent steps. The output format typically includes the protocol name and the corresponding confidence score value. For example:

[0146] Candidate Protocol 1: ModbusTCP, confidence level: 0.85.

[0147] Candidate protocol 2: Siemens S7, confidence level: 0.10.

[0148] 4. Recording and Feedback: The system records candidate protocols and their confidence levels for subsequent analysis and verification. Simultaneously, this information can be fed back to users or monitoring systems to help users understand the protocol identification results of data packets.

[0149] By fusing static and dynamic features to construct a multi-dimensional protocol feature vector, the following is included:

[0150] Step S341: Calculate the cross-attention weights between static and dynamic features using a multi-head attention mechanism.

[0151] The necessary steps are as follows: 1. Feature Input Preparation: Represent the static features extracted in step S32 and the dynamic features extracted in step S33 as feature matrices. Assume the static feature matrix is ​​S and the dynamic feature matrix is ​​D, where each row represents a feature vector and each column represents a feature dimension. 2. Initialization of the Multi-Head Attention Mechanism: Initialize the parameters of the multi-head attention mechanism, including the query, key, and value matrices. These parameters are typically learned through the training process and are used to map the input features to the format required by the attention mechanism.

[0152] 3. Calculate cross-attention weights: Use a multi-head attention mechanism to calculate the cross-attention weights between static and dynamic features. The specific steps are as follows:

[0153] Mapping to query, key, and value: Mapping the static feature matrix S to the query matrix Q = SW Q The dynamic feature matrix D is mapped to the key matrix K=DW. K Sum matrix V=DW V .

[0154] Calculate the attention score: Calculate the dot product between the query and the key to obtain the attention score matrix A=QK. T Attention score represents the correlation between static and dynamic features.

[0155] Scaling and normalization: The attention score is scaled, typically using... (where d) k The attention weight matrix W is obtained by scaling the dimension of the key vector and then normalizing it using the Softmax function. attn : .

[0156] 4. Aggregation of Multi-Head Attention: Aggregate the outputs of the multi-head attention mechanism. For each head, calculate the weighted value matrix V. weighted =W attn V, and then concatenate the outputs of all the heads together to form the final cross-attention output.

[0157] Step S342: Based on cross-attention weights, adaptive weighted fusion of static and dynamic features is performed.

[0158] The necessary process is as follows: 1. Obtain the cross-attention weights: Obtain the calculated cross-attention weights W from step S341. attn These weights reflect the strength of the correlation between static and dynamic features. 2. Weighted Dynamic Features: Dynamic features are weighted using cross-attention weights. Specifically, the dynamic feature matrix D and the attention weight matrix W are weighted... attn Multiplying them together yields the weighted dynamic feature D. weighted :D weighted =W attn D. This step adjusts the contribution of dynamic features through attention weights, thus enhancing the dynamic feature components that are more relevant to static features. 3. Fusion of static features and weighted dynamic features: The static feature matrix S is fused with the weighted dynamic feature D. weighted Perform the fusion. Fusion can be achieved through simple addition, splicing, or other more complex operations. For example:

[0159] Additive fusion: F = S + D weighted Blending and splicing: F=[S;D weighted ]. Where F represents the fused feature matrix.

[0160] 4. Adaptive Adjustment of Fusion Weights: In some cases, an adaptive adjustment mechanism can be introduced to dynamically adjust the fusion weights of static and dynamic features through learning. For example, a learnable parameter α can be introduced to make the fusion process more flexible.

[0161] The parameter α can be learned automatically during the training process to achieve the optimal fusion effect.

[0162] Step S343: Input the fused features into the feature enhancement layer, and generate a multi-dimensional protocol feature vector through residual connection and layer normalization.

[0163] The necessary process is as follows: 1. Input fused features: Input the fused features F from step S342 into the feature enhancement layer. 2. Residual connection: In the feature enhancement layer, residual connections are used to directly pass the input features F to the output. Simultaneously, a transformation layer (such as a fully connected layer or a convolutional layer) processes the input features to obtain intermediate features F′. The final output is: F out =F+F′. This design helps to preserve the original feature information while introducing new feature representations. 3. Layer normalization: For the features F after residual connection... outLayer normalization is performed to stabilize the training process and improve the model's generalization ability. The layer normalization calculation is as follows: The layer normalization process normalizes each feature vector to have a mean of 0 and a standard deviation of 1. 4. Generating Protocol Feature Vectors: The feature Fnorm after residual connection and layer normalization is the final multidimensional protocol feature vector, used for subsequent protocol identification tasks.

[0164] Based on the confidence distribution of candidate protocols and the structural matching degree of existing parsers, the dynamic determination of whether to initiate interactive reasoning includes:

[0165] Step S41: Based on the candidate protocol and its mapping confidence, perform statistical analysis on the mapping confidence and calculate the quantitative evaluation index, which includes the highest confidence value, confidence concentration and distribution uncertainty.

[0166] Calculate the highest confidence value: Find the highest confidence value among all candidate protocols. For example, the highest confidence value is 0.85 (corresponding to ModbusTCP).

[0167] Calculating confidence concentration: Confidence concentration reflects the degree of concentration in the confidence distribution, and can be measured by calculating the entropy of the confidence level. The lower the entropy value, the more concentrated the confidence level. The calculation formula is as follows:

[0168] Concentration = Among them, p i It is the confidence level of the i-th candidate protocol.

[0169] Calculating distributional uncertainty: Distributional uncertainty reflects the dispersion of the confidence level distribution and can be measured by calculating the standard deviation of the confidence level. The larger the standard deviation, the higher the uncertainty. The formula is as follows: Uncertainty = Where n is the number of candidate protocols, It is the average confidence level.

[0170] Step S42: Based on the candidate protocol type with the highest confidence level, obtain the corresponding existing parser from the protocol parser registry.

[0171] The necessary process is as follows: 1. Determine the candidate protocol with the highest confidence level: From the candidate protocols and their confidence levels obtained in step S36, select the protocol type with the highest confidence level. For example, if the candidate protocols and their confidence levels are:

[0172] ModbusTCP:0.85.

[0173] Siemens S7:0.10.

[0174] EtherNet / IP:0.05.

[0175] The candidate protocol type with the highest confidence level is "ModbusTCP".

[0176] 2. Query the protocol resolver registry: Using the candidate protocol type with the highest confidence level, query the corresponding existing resolver from the protocol resolver registry. The registry stores the mapping relationship between protocol types and resolver instances. For example:

[0177] ModbusTCP→ModbusTcpParser.

[0178] Siemens S7 → Siemens S7 Parser.

[0179] EtherNet / IP→EtherNetIPParser.

[0180] The system retrieves the corresponding parser instance ModbusTcpParser from the registry using the protocol type "ModbusTCP".

[0181] 3. Obtain an existing parser instance: After retrieving the corresponding parser instance from the registry, the system marks that instance as the existing parser for the current data packet. For example, after obtaining the ModbusTcpParser instance, the system prepares it for subsequent data packet parsing.

[0182] Step S43: Based on the multi-dimensional protocol feature vector, the protocol structure is verified using the structural constraints of the existing parser, and the structure matching degree is calculated. The structure matching degree characterizes the degree to which the structural features of the current data packet conform to the processing capabilities of the existing parser.

[0183] The necessary processes are as follows: 1. Obtain the multi-dimensional protocol feature vector: Obtain the fused multi-dimensional protocol feature vector from step S343. This vector contains the static and dynamic features of the data packet, and can comprehensively characterize the protocol characteristics of the data packet. 2. Obtain the structural constraints of the existing parser: Extract the structural constraints of the existing parser obtained in step S42. These constraints typically include:

[0184] Field length: The expected length of each field.

[0185] Data type: The data type of each field (such as integer, floating-point number, boolean value, etc.).

[0186] Byte order: The byte order of data (big-endian or little-endian).

[0187] Protocol format: The fixed format or pattern of a protocol, such as a feature code at a specific location.

[0188] 3. Protocol Structure Verification: Using the structural constraints of the existing parser, the multi-dimensional protocol feature vectors are verified. The verification process includes:

[0189] Field length matching: Checks whether the length of each field in the data packet matches the parser's expectations.

[0190] Data type matching: Checks whether the data type of each field in the data packet meets the parser's requirements.

[0191] Byte order matching: Checks whether the byte order of the data packet is consistent with the byte order supported by the parser.

[0192] Protocol format matching: Checks whether the format of the data packet conforms to the protocol format supported by the parser.

[0193] 4. Calculate the structural matching degree: Based on the verification results, calculate the structural matching degree. The structural matching degree can be calculated in the following ways:

[0194] Field length matching degree: Calculates the proportion of fields that match in length.

[0195] Data type matching degree: Calculates the proportion of data types that match.

[0196] Byte order matching degree: Calculates the proportion of byte order matches.

[0197] Protocol format matching degree: Calculate the proportion of protocol formats that match.

[0198] These matching scores are combined to obtain an overall structural matching score. For example, a weighted average method can be used:

[0199] Structure matching score = w1 × field length matching score + w2 × data type matching score + w3 × byte order matching score + w4 × protocol format matching score. Where w1, w2, w3, and w4 are weights and can be adjusted according to actual needs.

[0200] 5. Output Structure Matching Degree: Output the calculated structure matching degree for use in subsequent steps. The structure matching degree is usually a value between 0 and 1. The closer the value is to 1, the better the structural characteristics of the data packet match the processing capabilities of the existing parser.

[0201] Step S44: The highest confidence value, confidence concentration, distribution uncertainty, and structure matching degree are input into the pre-trained decision evaluation model for comprehensive evaluation. The decision evaluation model generates attention scores for the four indicators through a multi-head attention layer, normalizes the attention scores to obtain the corresponding fusion weights, performs weighted fusion of the indicators according to the fusion weights, and inputs the fused feature vector into a multilayer perceptron for classification decision, and finally outputs a comprehensive decision score.

[0202] A specific embodiment of the decision evaluation model in step S44: The model is a lightweight multilayer perceptron (MLP), whose inputs are the four quantitative indicators (highest confidence value, confidence concentration, distribution uncertainty, and structure matching degree) calculated in step S41.

[0203] Network structure: Input layer (4 nodes) → Hidden layer (8 nodes, using ReLU activation function) → Output layer (1 node, using Sigmoid activation function, outputting the comprehensive decision score).

[0204] Training method: The binary classification model is trained under supervision by collecting data from historical recognition tasks and manually labeling "whether interactive reasoning should be initiated".

[0205] The necessary process is as follows: 1. Input Indicators: Input the highest confidence value, confidence concentration, distribution uncertainty, and structure matching degree calculated in steps S41 and S43 into the pre-trained decision evaluation model. These indicators collectively characterize the protocol identification status of the current data packet. 2. Multi-head Attention Layer Processing: The multi-head attention layer in the decision evaluation model generates attention scores for each of the four input indicators. The multi-head attention layer calculates the importance of each indicator through multiple attention heads, thereby capturing information from different dimensions. For example, for the input indicator X=[x1,x2,x3,x4], where x1 represents the highest confidence value; x2 represents the confidence concentration; x3 represents the distribution uncertainty; and x4 represents the structure matching degree, the multi-head attention layer outputs an attention score A=[a1,a2,a3,a4]. 3. Normalization Processing: Normalize the attention scores generated by the multi-head attention layer to obtain the fusion weight of each indicator. Normalization ensures that the sum of all weights is 1, facilitating subsequent weighted fusion. The normalization formula is as follows: Among them, w i It is the fusion weight of the i-th indicator, a i This is the attention score of the i-th indicator. 4. Weighted Fusion: The input indicators are weighted and fused according to the normalized fusion weights to generate a fused feature vector. The weighted fusion formula is as follows: Where F is the fused feature vector, w i It is the fusion weight of the i-th indicator, x iThis is the value of the i-th indicator. 5. Multilayer Perceptron Classification Decision: The fused feature vector F is input into a multilayer perceptron (MLP) for classification decision. The MLP further processes the fused features through learned nonlinear relationships, ultimately outputting a comprehensive decision score. The comprehensive decision score indicates the probability that the data packet needs to initiate interactive inference. 6. Output Comprehensive Decision Score: The comprehensive decision score output by the multilayer perceptron is a value between 0 and 1. The closer the value is to 1, the higher the probability that the data packet needs to initiate interactive inference; the closer the value is to 0, the higher the probability that the data packet does not need to initiate interactive inference.

[0206] Step S45 involves comparing the comprehensive decision score with a dynamic decision threshold. The dynamic decision threshold is adjusted based on the accuracy of historical interaction feedback and the risk level parameters of the current industrial scenario, using a preset threshold update strategy. The specific process can be found in steps S451 to S456.

[0207] Step S46: If the comprehensive decision score is lower than the dynamic decision threshold, then interactive reasoning is initiated; otherwise, interactive reasoning is not initiated.

[0208] The dynamic decision threshold is adjusted based on the accuracy of historical interaction feedback and the risk level parameters of the current industrial scenario, through a preset threshold update strategy, including:

[0209] Step S451: Based on a preset statistical period, extract valid feedback records from historical interaction feedback and calculate the current accuracy rate.

[0210] The necessary process is as follows: 1. Determine the statistical period: The system determines the time range to be evaluated based on the preset statistical period. For example, if the statistical period is 24 hours, all interaction feedback records from the past 24 hours are extracted. 2. Extract valid feedback records: Valid feedback records that match the current statistical period are selected from historical interaction feedback. The selection process may include:

[0211] Time filtering: Only retain feedback records within the statistical period.

[0212] Deduplication: Remove duplicate feedback records to ensure the independence of each feedback record.

[0213] Validity verification: Ensure that feedback records are complete and valid, for example, by excluding incomplete or incorrect feedback.

[0214] 3. Calculate the current accuracy rate: Based on the valid feedback records, calculate the current accuracy rate. The formula for calculating the accuracy rate is as follows: Current accuracy rate = Number of correct feedback records ÷ Total number of valid feedback records × 100%.

[0215] Among them, the number of correct feedback records: the number of feedback records in which users confirm that the system's recognition result is correct.

[0216] Total number of valid feedback records: The total number of all valid feedback records within the statistical period.

[0217] Step S452: Compare the current accuracy with the preset target accuracy to determine the direction and magnitude of the accuracy deviation.

[0218] The necessary procedures are as follows: 1. Obtain the current accuracy: Obtain the calculated current accuracy from step S451. For example, the current accuracy is 85%. 2. Obtain the preset target accuracy: The target accuracy preset by the system. For example, the preset target accuracy is 90%. 3. Calculate the accuracy deviation: Calculate the deviation between the current accuracy and the preset target accuracy. The formula for calculating the deviation is as follows: Accuracy deviation = Preset target accuracy - Current accuracy. For example, if the preset target accuracy is 90% and the current accuracy is 85%, then the accuracy deviation is: Accuracy deviation = 90% - 85% = 5%.

[0219] 4. Determine the direction and magnitude of the deviation:

[0220] Based on the accuracy deviation value, determine the direction and magnitude of the deviation:

[0221] Deviation direction: If the accuracy deviation is positive, it means that the current accuracy is lower than the preset target; if the accuracy deviation is negative, it means that the current accuracy is higher than the preset target.

[0222] Deviation magnitude: The absolute value of the accuracy deviation, representing the difference between the current accuracy and the preset target. For example, a deviation of 5% means that the current accuracy is 5 percentage points lower than the preset target.

[0223] Step S453: Obtain the risk level parameters of the current industrial scenario and query the corresponding risk adjustment coefficient from the preset risk level-adjustment coefficient mapping table.

[0224] The necessary process is as follows: 1. Obtain risk level parameters: The system obtains the risk level parameters of the current industrial scenario from the monitoring system or logs of the industrial environment. These parameters may include:

[0225] Equipment failure rate: The frequency or probability of equipment failure. Network attack frequency: The frequency of potential attack events detected in the network. Packet loss rate: The proportion of packets lost in the network. Other risk indicators: Other risk-related parameters defined according to the specific industrial scenario.

[0226] For example, the system may obtain information such as a current device failure rate of 0.05%, a network attack frequency of once per hour, and a packet loss rate of 0.1%.

[0227] 2. Pre-defined Risk Level-Adjustment Coefficient Mapping Table: The system pre-defines a risk level-adjustment coefficient mapping table, which maps different risk level parameter ranges to corresponding adjustment coefficients. For example:

[0228] Equipment failure rate <0.05% → Adjustment coefficient = 0.9.

[0229] 0.05%≤equipment failure rate<0.1%→adjustment coefficient=1.0.

[0230] Equipment failure rate ≥ 0.1% → Adjustment coefficient = 1.1.

[0231] Similarly, there are corresponding mapping relationships for other risk indicators such as network attack frequency and packet loss rate.

[0232] 3. Query the corresponding risk adjustment coefficient: Based on the obtained risk level parameters, query the corresponding adjustment coefficient from the preset mapping table. For example:

[0233] If the current device failure rate is 0.05%, the corresponding adjustment factor is 0.9. If the network attack frequency is once per hour, the corresponding adjustment factor might be 1.0. If the packet loss rate is 0.1%, the corresponding adjustment factor might be 1.1.

[0234] 4. Comprehensive Risk Adjustment Coefficient: If multiple risk level parameters exist, the system can combine the adjustment coefficients corresponding to these parameters to generate a comprehensive risk adjustment coefficient. For example, the average or weighted average of these adjustment coefficients can be used. Assuming the adjustment coefficient for equipment failure rate is 0.9, the adjustment coefficient for network attack frequency is 1.0, and the adjustment coefficient for packet loss rate is 1.1, then the comprehensive risk adjustment coefficient can be calculated as: Comprehensive Risk Adjustment Coefficient = (0.9 + 1.0 + 1.1) ÷ 3 = 1.0.

[0235] 5. Record risk adjustment coefficients: Record the retrieved risk adjustment coefficients for use in subsequent steps. This information can be stored in system logs or a database for long-term monitoring and analysis.

[0236] Step S454: Select a preset threshold adjustment algorithm based on the direction of the accuracy deviation: when the accuracy deviation is positive, use the first adjustment algorithm; when the accuracy deviation is negative, use the second adjustment algorithm; both the first and second adjustment algorithms use the magnitude of the accuracy deviation and the risk adjustment coefficient as inputs to calculate the threshold adjustment amount.

[0237] The necessary procedures are as follows:

[0238] 1. Determine the direction of accuracy deviation:

[0239] Based on the accuracy deviation calculated in step S452, determine the direction of the deviation:

[0240] If the accuracy deviation is positive (current accuracy < preset target accuracy), select the first adjustment algorithm.

[0241] If the accuracy deviation is negative (current accuracy > preset target accuracy), select the second adjustment algorithm.

[0242] 2. Obtain the magnitude of the accuracy deviation and the risk adjustment coefficient: Obtain the magnitude of the accuracy deviation from step S452, and obtain the risk adjustment coefficient from step S453. These parameters will be used as inputs to the adjustment algorithm.

[0243] 3. Select the adjustment algorithm and calculate the threshold adjustment amount:

[0244] Based on the direction of the accuracy deviation, select the appropriate adjustment algorithm and calculate the threshold adjustment amount:

[0245] First adjustment algorithm (positive deviation):

[0246] Inputs: the magnitude of accuracy deviation and the risk adjustment factor.

[0247] Output: Threshold adjustment amount.

[0248] Example calculation formula: Δthreshold = -α × |accuracy bias| × risk adjustment coefficient. Where α is a preset positive adjustment coefficient, and the negative sign indicates lowering the threshold to trigger more interactive inference.

[0249] Second adjustment algorithm (negative bias):

[0250] Inputs: the magnitude of accuracy deviation and the risk adjustment factor.

[0251] Output: Threshold adjustment amount.

[0252] Example calculation formula: Δthreshold = β × |accuracy deviation| × risk adjustment coefficient. Where β is a preset positive adjustment coefficient; a positive result indicates an increase in the threshold to reduce unnecessary interactions.

[0253] 4. Record threshold adjustment amounts: Record the calculated threshold adjustment amounts for use in subsequent steps. This information can be stored in system logs or a database for long-term monitoring and analysis.

[0254] Step S456: Update the current dynamic decision threshold according to the threshold adjustment amount, and ensure that the updated dynamic decision threshold is within the preset safety threshold range.

[0255] The necessary process is as follows: 1. Obtain the current dynamic decision threshold: The system obtains the current dynamic decision threshold. Assume the current dynamic decision threshold is T.current 2. Obtain the threshold adjustment amount: Obtain the calculated threshold adjustment amount ΔT from step S454. 3. Update the dynamic decision threshold: Update the current dynamic decision threshold based on the threshold adjustment amount. Where ΔT is the signed threshold adjustment amount calculated in step S454 (negative values ​​indicate a decrease, positive values ​​indicate an increase). 4. Check the safety threshold range: Ensure the updated dynamic decision threshold T new It is within the preset safety threshold range. Assume the safety threshold range is [T]. min ,T max If T new <T min Then T new Set to T min If T new >T max Then T new Set to T max The specific formula is as follows: 5. Record the updated dynamic decision threshold: Record the updated dynamic decision threshold T new Record and update the threshold settings in the system. This information can be stored in the system log or database for long-term monitoring and analysis. 6. Feedback on update results: The system can feed back the updated dynamic decision thresholds to the user or monitoring system so that the user understands the current status of the decision thresholds.

[0256] The trial parsing of industrial variables will be presented to the user for secondary verification, and corrective feedback will be received. This feedback will be used to calibrate the field mapping or data transformation rules of the parameterized protocol template, including:

[0257] Step S61: In the form of an interactive mapping topology diagram, the trial parsing industrial variables, key field information extracted from the protocol feature vector, and the current mapping rules of the parameterized protocol template are visualized and associated. Based on the preset anomaly detection rules, the mapping relationships in the mapping topology diagram are scored, and mapping relationships with scores lower than the preset first threshold are automatically highlighted.

[0258] A specific embodiment of the interactive calibration interface in step S61: The system graphical interface will display three columns of information side by side:

[0259] Left column (raw data): Hexadecimal byte stream of the current unknown protocol data packet, with highlighted key field boundaries (such as start bit, length field, and suspected data area) initially identified based on feature vectors.

[0260] The middle column (parse mapping) displays the current mapping relationship between the fields extracted from the byte stream and the parsed industrial variables (such as "the value of register 40101") in the form of a line graph.

[0261] Right column (context reference): Displays a list of real-time or historical process parameters (such as "Reactor No. 1 temperature" and "Feed pump frequency") related to the variable, obtained from the associated industrial monitoring system (SCADA / HMI).

[0262] Users can modify the mapping relationship by dragging and dropping field blocks from the left column to a specific process parameter in the right column, or by directly modifying the data conversion formula in the middle column (e.g., value = byte A * 256 + byte B). The system converts this interactive operation into real-time updates to the corresponding mapping rules and conversion operators in the underlying parameterized protocol template (a structured description file in JSON or XML format).

[0263] The necessary procedures are as follows:

[0264] 1. Prepare visualization data:

[0265] Trial parsing of industrial variables: Trial parsing results obtained from step S5, such as variable name, value, and timestamp. Key field information: Field information extracted from the protocol feature vector, such as field position, length, and data type. Current mapping rules: Field mapping and data transformation rules defined in the parameterized protocol template.

[0266] 2. Construct the mapping topology map: Use visualization tools (such as a graphical interface or web interface) to construct the mapping topology map. In the map:

[0267] Nodes: Represent the parsed industrial variables, key field information, and mapping rules. Edges: Represent the mapping relationships between nodes, such as how a certain field maps to a certain industrial variable.

[0268] 3. Visualized Relationships: The mapping topology diagram will display the interconnected industrial variables, key field information, and current mapping rules. Users can view detailed information through interactive operations (such as mouse hover and click).

[0269] 4. Anomaly Detection and Scoring:

[0270] Pre-defined anomaly detection rules: Define a series of rules to evaluate the rationality of mapping relationships. For example, check whether the field length conforms to the protocol specification, whether the data types match, etc.

[0271] Scoring mechanism: Each mapping relationship is scored, with the score range typically from 0 to 1, where 1 indicates that it is completely reasonable and 0 indicates that it is completely unreasonable.

[0272] Highlight anomalies: Based on a preset first threshold (e.g., 0.5), automatically highlight mapping relationships with scores below that threshold. These relationships are considered potential anomalies and require further investigation by the user.

[0273] 5. Interactive Feedback: Users can interact with the mapped topology through a visual interface, for example:

[0274] Mouse hover: Displays detailed information. Click: Selects a specific element for correction. Drag: Adjusts the mapping relationship.

[0275] 6. Record anomaly information: Record the mapping relationships for scores below the first threshold for use in subsequent steps. This information can be stored in system logs or a database for long-term monitoring and analysis.

[0276] Step S62: Receive user's modification operation on a specific element in the mapping topology map through a visual interface; parse the modification operation into a change instruction for one or more rule elements in the parameterized protocol template.

[0277] The necessary process is as follows: 1. Provide interactive functionality: Provide users with interactive functionality within the visual interface, allowing them to modify specific elements in the mapped topology graph. These functionalities may include:

[0278] Field mapping adjustment: Users can remap fields to different industry variables. Data type modification: Users can change the data type of a field (e.g., from integer to floating-point). Field length adjustment: Users can modify the length of a field. Add / delete mappings: Users can add new mappings or delete existing mappings.

[0279] 2. Receiving User Correction Operations: The system receives user correction operations through a visual interface. For example, users may adjust field mappings by dragging and dropping, or modify data types through input boxes.

[0280] 3. Parse Correction Operations: Parse the user's correction operations into specific change instructions. For example:

[0281] If a user remaps field A to variable B, the system generates a change instruction: "Change the mapping target of field A to variable B". If a user changes the data type of field A from integer to floating-point, the system generates a change instruction: "Change the data type of field A to floating-point".

[0282] Step S63: Based on the change instruction and combined with the preset protocol semantic constraints, iteratively adjust the parameterized protocol template; after each adjustment, use the adjusted template to simulate and parse the key field information in the protocol feature vector, calculate the similarity between the simulated parsing result and the trial parsing industrial variables or the expected result provided by the user through the visualization interface, until the similarity reaches the preset second threshold.

[0283] The necessary procedures are as follows:

[0284] 1. Initialization and adjustment process:

[0285] Obtain the change instruction from step S62.

[0286] Obtain the current parameterized protocol template from step S61.

[0287] Obtain key field information from the trial parsing of industrial variables and protocol feature vectors in step S5.

[0288] 2. Iterative adjustment protocol template:

[0289] Apply Change Instructions: Adjust the parameterized protocol template according to the change instructions. For example, if the change instruction is "Change the mapping target of field A to variable B", then update the mapping relationship of field A in the template. Check Protocol Semantic Constraints: After each adjustment, check whether the adjusted template conforms to the preset protocol semantic constraints. For example, ensure that the field length and data type conform to the protocol specification.

[0290] 3. Simulation Analysis: The adjusted protocol template is used to simulate and analyze the key field information in the protocol feature vector, generating simulation analysis results. The simulation analysis results can be the values ​​of one or more industrial variables.

[0291] 4. Calculate Similarity: Calculate the similarity between the simulation analysis results and the trial analysis of industrial variables or the expected results provided by the user through the visualization interface. Similarity can be calculated in the following ways:

[0292] Numerical similarity: For numerical variables, it calculates the difference between simulated and expected values, for example, using absolute or relative error.

[0293] Text similarity: For text-based variables, string similarity algorithms (such as Levenshtein distance) can be used.

[0294] Example of similarity calculation formula: Similarity = 1 − Absolute error / Maximum possible error.

[0295] 5. Determine if the similarity reaches the threshold: If the similarity reaches the preset second threshold (e.g., 0.9), the adjusted template is considered to meet the user's expectations, and the iterative adjustment ends. If the similarity does not reach the threshold, iterative adjustment continues until the similarity reaches the threshold or the maximum number of iterations is reached.

[0296] Step S64: Generate the calibrated parameterized protocol template.

[0297] Based on the calibrated or directly obtained parameterized protocol template, and combined with key field information extracted from the protocol feature vector, executable protocol parsing rules are instantiated and generated, including:

[0298] Step S81: Fill the specific parameters in the key field information into the corresponding placeholders of the parameterized protocol template according to the preset binding rules, generating an instantiated, intermediate representation of the protocol parsing rule description. The necessary process is as follows: 1. Prepare key field information and parameterized protocol template: Extract key field information from the protocol feature vector, such as field position, length, and data type. Obtain the parameterized protocol template, which contains information such as the protocol's field mapping, data type, and parsing rules, some of which exist in placeholder form. 2. Define binding rules: Preset binding rules to specify how to fill the specific parameters in the key field information into the placeholders of the parameterized protocol template. For example, the rules can specify how to fill the field length into a specific position in the template, or how to map the data type to a placeholder in the template. 3. Fill placeholders: According to the binding rules, fill the specific parameters in the key field information one by one into the corresponding placeholders of the parameterized protocol template. For example, if the length of a field in the key field information is 2 bytes and the data type is an integer, then these parameters are filled into the corresponding placeholder positions in the template. The populated template may contain specific field mappings and data processing rules, but it has not yet been optimized.

[0299] 4. Generate an intermediate representation of the protocol parsing rule description: After parameter filling, an instantiated intermediate representation of the protocol parsing rule description is generated. This description is a preliminary form of the protocol parsing rules, containing all necessary field information and parsing rules, but may still contain redundant or unoptimized parts.

[0300] 5. Record the protocol parsing rule description of the intermediate representation: Record the protocol parsing rule description of the generated intermediate representation for use in subsequent steps. This information can be stored in system logs or a database for long-term monitoring and analysis.

[0301] Step S82: Based on the preset optimization goals, the instantiated protocol parsing rule description is logically simplified and performance optimized to generate an optimized protocol parsing rule description.

[0302] The necessary process is as follows: 1. Define the optimization goal: Based on system requirements and actual application scenarios, preset the optimization goal. For example:

[0303] Reduce parsing time: Optimize the algorithm to reduce the time required to parse each data packet. Reduce memory usage: Optimize data structures to reduce memory usage. Improve parsing accuracy: Optimize rules to reduce false positives and false negatives.

[0304] 2. Logical simplification:

[0305] Merge duplicate rules: Examine the instantiated protocol parsing rule descriptions and merge duplicate or similar rules. For example, if multiple fields have the same parsing logic, they can be merged into a single general rule. Simplify logical expressions: Use methods such as Boolean algebra to simplify complex logical expressions. For example, combine multiple conditions into a simpler one.

[0306] Eliminate redundant rules: Remove redundant rules that do not affect the parsing results. For example, if a rule's condition will never be true, it can be deleted.

[0307] 3. Performance optimization:

[0308] Optimize the algorithm: Choose a more efficient algorithm to implement the parsing rules. For example, use a hash table instead of a linear search to find field mappings. Optimize the data structure: Choose a more suitable data structure to store the parsing rules and intermediate results. For example, use an array instead of a linked list to store fixed-length fields.

[0309] Reduce computational load: Reduce redundant calculations by pre-compiling and caching intermediate results. For example, cache the calculation results of certain fixed values ​​to avoid recalculating them each time the parsing is performed.

[0310] 4. Generate an optimized protocol parsing rule description: After logical simplification and performance optimization, an optimized protocol parsing rule description is generated. This description is an optimized version of the protocol parsing rules, containing all necessary field information and parsing rules, while reducing redundancy and improving execution efficiency.

[0311] Step S83: Using a preset rule compiler, the optimized protocol parsing rule description is compiled into an executable protocol parser plugin that conforms to the protocol parser registry interface specification.

[0312] The necessary process is as follows: 1. Prepare optimized protocol parsing rule descriptions: Obtain the optimized protocol parsing rule descriptions from step S82. These rule descriptions have undergone logical simplification and performance optimization to ensure efficiency and accuracy. 2. Load the rule compiler: The system loads the preset rule compiler. The rule compiler is a specially designed tool that can convert protocol parsing rule descriptions into executable code. It typically supports specific programming languages ​​and compilation targets. 3. Compile the protocol parsing rule descriptions: Use the rule compiler to compile the optimized protocol parsing rule descriptions into executable code. The compilation process includes:

[0313] Syntax parsing: Parses the rule description into an abstract syntax tree (AST).

[0314] Code generation: Generates code in the target language based on the AST. For example, it can generate C++, Python, or Java code.

[0315] Compiler optimization: Applying the compiler's built-in optimization techniques to further improve the performance of the generated code.

[0316] 4. Ensure compliance with interface specifications:

[0317] During compilation, ensure that the generated executable code conforms to the interface specification of the protocol resolver registry. This includes:

[0318] Interface Functions: Ensure the plugin implements all necessary interface functions, such as `initialize()`, `parse()`, and `finalize()`. Data Structures: Ensure the plugin uses correct data structures, such as the format of input / output buffers. Error Handling: Ensure the plugin can correctly handle error conditions and return standard error codes.

[0319] 5. Generate an executable protocol parser plugin:

[0320] After compilation, an executable protocol resolver plugin conforming to the interface specification is generated. The plugin is typically a dynamic link library (DLL) or shared object (SO) file, which can be dynamically loaded and used by the system.

[0321] Step S84: Perform a preset verification test on the executable protocol parser plugin. Once the verification is passed, the final executable protocol parsing rules are generated.

[0322] The necessary process is as follows: 1. Prepare the test environment: Set up a dedicated test environment, including test data packets, test scripts, and test tools. The test data packets should cover various typical scenarios and boundary conditions to ensure the robustness of the plugin. 2. Perform functional tests: Verify whether the plugin can correctly parse protocol data packets. Functional tests include:

[0323] Field parsing: Checks whether the plugin can correctly extract field values ​​from the data packet. Protocol consistency: Ensures that the parsing results conform to the protocol specifications. Exception handling: Tests the plugin's behavior when faced with abnormal data packets, such as incorrect data packet format or missing fields.

[0324] 3. Perform performance tests: Verify that the plugin's parsing speed and resource consumption meet performance requirements. Performance tests include:

[0325] Parsing speed: Measures the time required for the plugin to parse a large number of data packets. Memory usage: Monitors the plugin's memory usage during runtime. CPU utilization: Assesses the plugin's CPU resource requirements.

[0326] 4. Perform compatibility testing: Verify that the plugin is compatible with existing protocol resolver registry entries and other system components. Compatibility testing includes:

[0327] Interface compatibility: Ensure the plugin implements all necessary interface functions. Data format compatibility: Verify that the plugin's output data format conforms to system requirements. Multi-protocol support: Test the plugin's performance when handling multiple protocols.

[0328] 5. Generate Test Reports: Generate detailed test reports based on the test results, recording the results of functional testing, performance testing, and compatibility testing. Test reports should include:

[0329] Test Cases: List all test cases and their results. Problem Description: Record any problems found during testing. Improvement Suggestions: Propose improvements to address the identified problems.

[0330] An industrial network protocol packet capture and parsing system includes:

[0331] A packet capture module for capturing raw data packets in industrial networks.

[0332] The packet filtering module, connected to the packet capture module, is used to filter the captured raw packets according to preset conditions.

[0333] Protocol resolver registry, used to store and manage multiple protocol resolvers.

[0334] The multi-protocol parsing module connects to the protocol parser registry and is used to call the parsers pre-installed in the protocol parser registry to parse known protocols.

[0335] The variable management module, connected to the multi-protocol parsing module, is used to manage and update variables extracted from data packets.

[0336] The variable display module, connected to the variable management module, is used to display and update variable values ​​in real time.

[0337] The protocol feature extraction and reasoning module is used to extract protocol feature vectors based on the communication waveforms and interaction sequences of data packets when the protocol is identified as an unknown or non-standard industrial protocol, and to obtain candidate protocols and their mapping confidence through neural mapping model reasoning.

[0338] The adaptive learning processing module is connected to the protocol feature extraction and inference module and the protocol parser registry, respectively. It is used to dynamically determine whether to start interactive inference based on the confidence distribution of candidate protocols and the structural matching degree of existing parsers. During the interactive inference process, it obtains user feedback, optimizes the neural mapping model, attempts to parse and calibrates parameterized protocol templates, and generates executable protocol parsing rules based on the calibrated or directly obtained parameterized protocol templates and registers them to the protocol parser registry.

[0339] The protocol knowledge base, connected to the adaptive learning processing module, is used to store parameterized protocol templates.

[0340] It is important to note that the user feedback obtained during the packet capture, protocol feature extraction, and interactive reasoning processes involved in this invention has the sole purpose of constructing and calibrating parsing rules for specific industrial communication protocols. The entire process serves the purely technical objective of "achieving reliable decoding and monitoring of industrial network data streams." The user feedback only involves confirming or correcting the mapping relationship between packet fields and known industrial variables (such as temperature, pressure, and equipment status), falling within the scope of technical debugging and not involving the collection or processing of any personally identifiable information or non-technical preferences. The design and implementation of this invention fully comply with industrial data security and compliance requirements.

[0341] The embodiments described in this specific implementation are preferred embodiments of this application and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. A method for capturing and parsing industrial network protocol data packets, characterized in that, include: In industrial networks, raw data packets are captured and filtered according to preset conditions, and then the filtered data packets are identified by protocol. If the protocol is identified as a known protocol, the corresponding parser pre-installed in the protocol parser registry will be invoked for parsing. If the protocol is identified as unknown or non-standard industrial protocol, the protocol feature vector is extracted based on the communication waveform and interaction sequence of the data packet, and input into the neural mapping model for inference to obtain the candidate protocol and its mapping confidence. Based on the confidence distribution of candidate protocols and the structural matching degree between data packets and existing parsers, dynamically determine whether to initiate interactive reasoning; If the determination is yes, a verification request for fusing candidate protocol information is generated, user feedback containing at least the real identifier of the target protocol is obtained, the neural mapping model is optimized based on the feedback and the protocol feature vector, and a parameterized protocol template is obtained according to the real identifier. The template is used to try parsing the current data packet to obtain the trial parsing industrial variables. The trial will analyze industrial variables and present them to the user for secondary verification, receive correction feedback, and use this feedback to calibrate the field mapping or data conversion rules of the parameterized protocol template. If the determination is negative, then the corresponding parameterized protocol template is obtained from the protocol knowledge base based on the candidate protocol with the highest confidence. Based on the parameterized protocol template obtained after calibration or directly, and combined with the key field information extracted from the protocol feature vector, an executable protocol parsing rule is instantiated and generated. The instantiated protocol parsing rules are registered as plugins to the protocol parser registry to form a new protocol parser; Use the parser in the protocol parser registry to parse the data packets; Industrial variables are extracted from the parsed data packets, and the current values ​​of the extracted industrial variables are displayed in real time.

2. The method for capturing and parsing industrial network protocol data packets according to claim 1, characterized in that, Capturing raw data packets in an industrial network and filtering them based on preset criteria includes: Initiate monitoring of the target industrial network communication link to capture raw data packets flowing through the link; The captured raw data packets are filtered in real time according to one or more pre-defined filtering conditions, including at least one of the following: source IP address, destination IP address, port number, and protocol type.

3. The method for capturing and parsing industrial network protocol data packets according to claim 1, characterized in that, The process of calling the corresponding parser pre-installed in the protocol parser registry includes: Submit the filtered data packets to the protocol resolver registry; By using the protocol parser registry, the corresponding target parser is matched and selected based on the protocol characteristics of the data packets; The target parser is invoked to perform protocol decoding and data extraction on the data packets.

4. The method for capturing and parsing industrial network protocol data packets according to claim 1, characterized in that, Based on the communication waveform and interaction sequence of the data packet, the protocol feature vector is extracted, input into the neural mapping model for inference, and candidate protocols and their mapping confidence scores are obtained, including: Based on the current data packet to be identified, obtain the context information of the communication session to which the data packet belongs. The context information includes the byte sequence characteristics of the current data packet to be identified and the interaction sequence of multiple data packets that are sequentially consecutive in the session to which the current data packet to be identified belongs. Statistical analysis of byte sequence features is performed to extract static features that characterize the syntax structure of data packets; Perform structural analysis and pattern mining on the interaction sequence to extract dynamic features that represent the application layer session logic; Static and dynamic features are fused to construct a multi-dimensional protocol feature vector; The protocol feature vector is input into a pre-trained neural mapping model, which then performs inference based on the protocol feature vector. The neural mapping model outputs at least one candidate protocol type and the mapping confidence level corresponding to each candidate protocol type.

5. The method for capturing and parsing industrial network protocol data packets according to claim 4, characterized in that, By fusing static and dynamic features to construct a multi-dimensional protocol feature vector, the following is included: The cross-attention weights between static and dynamic features are calculated using a multi-head attention mechanism. Based on cross-attention weights, static and dynamic features are adaptively weighted and fused. The fused features are input into the feature enhancement layer, and multi-dimensional protocol feature vectors are generated through residual connections and layer normalization.

6. The method for capturing and parsing industrial network protocol data packets according to claim 5, characterized in that, Based on the confidence distribution of candidate protocols and the structural matching degree of existing parsers, the dynamic determination of whether to initiate interactive reasoning includes: Based on candidate protocols and their mapping confidence, statistical analysis is performed on the mapping confidence to calculate quantitative evaluation indicators, including the highest confidence value, confidence concentration, and distribution uncertainty. Based on the candidate protocol type with the highest confidence level, retrieve the corresponding existing parser from the protocol parser registry; Based on multidimensional protocol feature vectors, the protocol structure is verified using the structural constraints of existing parsers, and the structure matching degree is calculated. The structure matching degree characterizes the degree to which the structural features of the current data packet conform to the processing capabilities of the existing parser. The highest confidence score, confidence concentration, distribution uncertainty, and structure matching degree are input into the pre-trained decision evaluation model for comprehensive evaluation. The decision evaluation model generates attention scores for the four indicators through a multi-head attention layer, normalizes the attention scores to obtain the corresponding fusion weights, performs weighted fusion of the indicators according to the fusion weights, and inputs the fused feature vector into a multilayer perceptron for classification decision, and finally outputs a comprehensive decision score. The comprehensive decision score is compared with the dynamic decision threshold, which is adjusted based on the accuracy of historical interaction feedback and the risk level parameter of the current industrial scenario through a preset threshold update strategy. If the overall decision score is lower than the dynamic decision threshold, interactive reasoning is initiated; otherwise, interactive reasoning is not initiated.

7. The method for capturing and parsing industrial network protocol data packets according to claim 6, characterized in that, The dynamic decision threshold is adjusted based on the accuracy of historical interaction feedback and the risk level parameters of the current industrial scenario, through a preset threshold update strategy, including: Based on a preset statistical period, valid feedback records are extracted from historical interaction feedback to calculate the current accuracy rate; Compare the current accuracy rate with the preset target accuracy rate to determine the direction and magnitude of the accuracy deviation. Obtain the risk level parameters of the current industrial scenario and query the corresponding risk adjustment coefficient from the preset risk level-adjustment coefficient mapping table; Based on the direction of the accuracy deviation, a preset threshold adjustment algorithm is selected: when the accuracy deviation is positive, the first adjustment algorithm is used; when the accuracy deviation is negative, the second adjustment algorithm is used; both the first and second adjustment algorithms use the magnitude of the accuracy deviation and the risk adjustment coefficient as inputs to calculate the threshold adjustment amount. The current dynamic decision threshold is updated based on the threshold adjustment amount, and the updated dynamic decision threshold is ensured to be within the preset safety threshold range.

8. The method for capturing and parsing industrial network protocol data packets according to claim 7, characterized in that, The trial parsing of industrial variables will be presented to the user for secondary verification, and corrective feedback will be received. This feedback will be used to calibrate the field mapping or data transformation rules of the parameterized protocol template, including: In the form of an interactive mapping topology graph, the current mapping rules of the trial parsing industrial variables, key field information extracted from the protocol feature vector, and parameterized protocol template are presented in a visually related manner. Based on the preset anomaly detection rules, the mapping relationships in the mapping topology graph are scored, and mapping relationships with scores lower than the preset first threshold are automatically highlighted. The system receives user correction operations for specific elements in the mapped topology through a visual interface; and parses these correction operations into change instructions for one or more rule elements in the parameterized protocol template. Based on the change instructions and combined with the preset protocol semantic constraints, the parameterized protocol template is iteratively adjusted; after each adjustment, the key field information in the protocol feature vector is simulated and parsed using the adjusted template, and the similarity between the simulated parsing results and the expected results provided by the user through the visualization interface is calculated until the similarity reaches the preset second threshold. Generate the calibrated parameterized protocol template.

9. An industrial network protocol data packet capture and parsing system, characterized in that, include: A packet capture module for capturing raw data packets in industrial networks; The packet filtering module, connected to the packet capture module, is used to filter the captured raw packets according to preset conditions; Protocol resolver registry, used to store and manage multiple protocol resolvers; The multi-protocol parsing module connects to the protocol parser registry and is used to call the parsers preset in the protocol parser registry to parse known protocols; The variable management module, connected to the multi-protocol parsing module, is used to manage and update variables extracted from data packets; The variable display module, connected to the variable management module, is used to display and update variable values ​​in real time. The protocol feature extraction and reasoning module is used to extract protocol feature vectors based on the communication waveform and interaction sequence of data packets when the protocol is identified as an unknown or non-standard industrial protocol, and to obtain candidate protocols and their mapping confidence through neural mapping model reasoning. An adaptive learning processing module, connected to the protocol feature extraction and inference module and the protocol parser registry, is used to dynamically determine whether to initiate interactive inference based on the confidence distribution of the candidate protocols and the structural matching degree between the data packet and the existing parser. If interactive inference is initiated, the following steps are executed sequentially during the interactive inference process: obtaining user feedback containing at least the real identifier of the target protocol; optimizing the neural mapping model based on the user feedback and the protocol feature vector; obtaining a parameterized protocol template based on the real identifier and using the template to perform trial parsing of the current data packet; and receiving correction feedback based on the trial parsing result to calibrate the parameterized protocol template. If interactive inference is not initiated, the corresponding parameterized protocol template is obtained from the protocol knowledge base based on the candidate protocol with the highest confidence. Based on the parameterized protocol template obtained after calibration or directly, generate executable protocol parsing rules and register them to the protocol parser registry; The protocol knowledge base, connected to the adaptive learning processing module, is used to store parameterized protocol templates.

Images