Security data acquisition method and system of industrial control network

Abstract

The invention discloses a security data acquisition system and method of an industrial control network, and belongs to the field of data acquisition, the security data acquisition system of the industrial control network comprises an abnormal target identification module used for capturing original traffic and identifying an abnormal data packet structure; comparing the standard protocol document with the abnormal data packet, and marking a difference field position; in combination with a debugging log of an equipment manufacturer, positioning the meaning of a field, and identifying the type and source of an abnormal field; the abnormal integrity identification module is used for analyzing the data packet by using a tool and identifying a fixed head and a variable field; deducing the meaning of the field through multiple interactive tests; compared with the prior art, the method has the beneficial effects that when the non-standard protocol field is detected, the standard protocol document is compared, the abnormal field is quickly marked, the meaning of the field is deduced, the protocol analysis rule is finally generated, the analysis plug-in is obtained, and the data is packaged into the standard protocol to be output; original disordered self-defined data can be directly used by an upper-layer system.

Description

Technical Field

[0001] The present invention belongs to the field of data acquisition, and in particular relates to a method and system for secure data acquisition in an industrial control network. Background Art

[0002] In industrial control networks, protocol fields are often non-standardized. Common non-standardization scenarios include:

[0003] 1. Private protocol extension: Manufacturers add custom fields (such as additional status bits and checksums) based on standard protocols (such as Modbus).

[0004] 2. Confused field formats: Different device manufacturers have inconsistent field definitions for the same protocol (for example, floating-point numbers are stored in big-endian or little-endian).

[0005] 3. Redundant fields: Unused padding bytes or historical fields are interspersed in the protocol.

[0006] 4. Dynamic field length: The field length changes according to the context (e.g., a variable-length string does not explicitly indicate the length).

[0007] Non-standardized protocol fields may lead to data parsing failure or misreading, which in turn affects the reliability of the acquisition system and needs to be improved. Summary of the Invention

[0008] Based on this, it is necessary to provide a secure data collection method and system for industrial control networks to address the above problems.

[0009] The embodiment of the present invention is implemented as follows: a secure data acquisition system for an industrial control network includes:

[0010] The anomaly identification module is used to capture raw traffic and identify abnormal packet structures (through small-scale, targeted data collection to quickly identify protocol anomaly characteristics). It compares standard protocol documents with abnormal packets and marks the locations of different fields. It also uses the device manufacturer's debug log to locate the meaning of the fields (such as the PLC register mapping table) and identify the type and source of the abnormal fields.

[0011] The complete anomaly identification module is used to collect complete communication traffic between devices (through complete and systematic data collection and the construction of protocol parsing rules); analyze data packets using tools (such as Scapy and Netzob) to identify fixed headers and variable fields; infer the meaning of fields through multiple interactive tests (such as modifying register values to observe changes in responses); decipher unknown protocol structures, generate parsing rules for the original protocol, and write protocol field offsets, lengths, and types into configuration files (such as YAML and JSON) to obtain parsing plug-ins;

[0012] The protocol adjustment output module is used to insert parsing plug-ins into protocol gateways (such as Node-RED and Kepware); remove meaningless padding bytes or private extension fields in the protocol, adjust the endianness (big endian ↔ little endian), unit (PSI → kPa), and encoding (BCD → decimal) as needed; and encapsulate data into standard protocol output (such as OPC UA information model and MQTT message).

[0013] In one embodiment, the present invention provides a secure data acquisition system for an industrial control network, wherein the abnormality identification module includes:

[0014] The abnormal data packet acquisition unit is used to capture the original traffic at the moment of the fault through an optical splitter when a device abnormality is triggered (such as a PLC alarm signal or SNMP Trap). Wireshark (a tool) is used to filter abnormal function codes (such as Modbus unconventional code 0x43) or data packets with excessive length to obtain abnormal data packets.

[0015] Anomaly comparison marking unit, used to compare abnormal data packets byte by byte with protocol specifications (such as the Modbus standard) using a Hex editor (such as 010 Editor), marking the offset (such as bytes 6-9), type (such as floating point number vs. integer), and encoding (such as big endian vs. little endian) of the difference fields;

[0016] The exception correlation unit is used to export PLC register mapping tables or debug logs through device vendor tools (such as Siemens TIA Portal), align log events (such as "temperature limit alarm") with captured packet timestamps, and correlate abnormal field value changes.

[0017] In one embodiment, the present invention provides a secure data acquisition system for an industrial control network, wherein the abnormal integrity identification module includes:

[0018] A full-traffic acquisition unit, used for full-traffic acquisition based on IEEE 1588 time synchronization, uses an industrial-grade optical splitter to capture all communication traffic between devices (including normal operation, failure, initialization, and other scenarios) and saves it as a PCAP file using tcpdump or a dedicated packet capture device (such as Keysight NTO) to ensure data integrity.

[0019] The packet analysis unit is used to analyze data packets using Scapy or Kaitai Struct (both tools), identifying fixed headers (such as transaction IDs and function codes), variable fields (such as sensor values), and check bits. Through interactive testing (such as forced modification of HMI parameters), it observes changes in field values and infers semantics (such as a 4-byte field that changes linearly with the temperature setting value);

[0020] The parsing plug-in acquisition unit is used to write field offsets, lengths, and types (such as uint16_be and float32_le) into the YAML / JSON configuration file, develop a Wireshark Lua plug-in or Python parsing script, implement automated decoding, and automatically obtain the parsing plug-in.

[0021] In one embodiment, the present invention provides a secure data acquisition system for an industrial control network, wherein the protocol adjustment output module includes:

[0022] The byte field removal unit is used to load and parse the plug-in configuration file in the protocol gateway (Node-RED / Kepware), initialize the field offset and type mapping rules, and remove private extension fields (such as manufacturer-defined checksums) and meaningless padding bytes (such as a 16-byte trailing 0xAA) through regular expression matching, retaining the core business data fields.

[0023] The conversion processing unit is used to perform endian conversion (such as converting little-endian floating-point numbers to big-endian), numerical unit conversion (such as multiplying the original PSI unit by 6.895 to convert it to kPa), transcode special encoding fields (such as converting the 4-byte BCD code "0x12345678" to decimal 12345678), align timestamps, and add metadata tags according to the configuration file;

[0024] The protocol standardization unit is used to encapsulate the processed structured data according to the target protocol specifications (such as OPC UA using the NodeId+DataValue information model and MQTT layered by topic), and finally output it through the gateway's standard interface (OPC UAServer / MQTT Broker) to complete the protocol standardization conversion.

[0025] In one embodiment, the present invention provides a secure data acquisition system for an industrial control network, wherein the abnormal integrity identification module further comprises:

[0026] The sample library establishment unit is used to collect communication traffic samples from devices from multiple vendors (such as Siemens S7 and Mitsubishi MC), extract static features (such as protocol header Magic Number: 0x32 / 0x72 for Siemens S7 and 0x5000 for Mitsubishi MC), dynamic features (function code distribution: read / write code 0x04 / 0x05 for Siemens S7 and 0x01 / 0x02 for MC), and port number (default 102 for Siemens S7 and 5001 for MC), and establish a labeled protocol feature sample library (CSV / YAML format).

[0027] The fingerprint library establishment unit is used to define the fingerprint library architecture, which includes the protocol name, version, feature field offset, and matching rules. The rules are extracted through sample library feature analysis to build a structured fingerprint library. For example, the Siemens S7 communication protocol V1.0 features "bytes 1-2 = 0x3272", while V2.0 features "bytes 1-2 = 0x7272 and byte 5 = 0x01". The Mitsubishi MC protocol distinguishes versions by "byte 3 function code ∈ [0x01, 0x0A]"

[0028] The protocol matching unit is used for precise matching of static features: it prioritizes scanning the packet header for matching predefined unique identifiers, including the protocol header magic number (such as 0x3272 for S7) and the port number. If they fully match, the protocol type and version are directly determined. Dynamic feature probabilistic matching: for feature conflict scenarios (such as multiple protocols on the same port), the frequency of function codes is counted (for example, if the proportion of Siemens S7 0x04 read instructions in the traffic is greater than 80%, the Siemens S7 is prioritized), and the weight of the device manufacturer distribution is combined (for example, if Siemens devices in the workshop account for 70%). Confidence grading decision-making: the confidence level is calculated based on the number of successfully matched features (for example, matching 3 / 5 features → 60%). If the confidence level is above a threshold (such as 90%), the result is output; if the confidence level is below the threshold, the manual review process is triggered, and unrecognized features are recorded and feedback is provided. Version differentiation processing: for different versions of the same protocol (such as S7 V1.0 / V2.0), the version flag field (such as the fifth byte = 0x01) is used for fine-grained differentiation. If there is no flag, the latest effective version rule is selected based on the timestamp.

[0029] The fingerprint library update unit is used to trigger automatic feature extraction (such as fixed header length and function code entropy analysis) when unidentified traffic is detected, generate candidate fingerprints, and manually review them before entering the fingerprint library.

[0030] In one embodiment, the present invention provides a method for secure data collection in an industrial control network, comprising the following steps:

[0031] (Quickly identify protocol anomalies through small-scale, targeted data collection) Capture raw traffic and identify abnormal packet structures; compare standard protocol documents with abnormal packets and mark the locations of different fields; combine with device vendor debug logs to locate field meanings (such as PLC register mapping tables) and identify the type and source of abnormal fields;

[0032] (Build protocol parsing rules through complete and systematic data collection) Collect complete communication traffic between devices; use tools (such as Scapy and Netzob) to analyze data packets and identify fixed headers and variable fields; infer the meaning of fields through multiple interactive tests (such as modifying register values and observing changes in responses); decipher unknown protocol structures, generate parsing rules for the original protocol, and write protocol field offsets, lengths, and types into configuration files (such as YAML and JSON) to obtain a parsing plug-in;

[0033] Insert a parsing plug-in into a protocol gateway (such as Node-RED or Kepware); remove meaningless padding bytes or private extension fields from the protocol, adjust the endianness (big endian ↔ little endian), unit (PSI → kPa), and encoding (BCD → decimal) as needed; and encapsulate the data into a standard protocol output (such as an OPC UA information model or MQTT message).

[0034] In one embodiment, the present invention provides a secure data collection method for an industrial control network. The steps of capturing raw traffic, identifying abnormal data packet structures, comparing standard protocol documents with abnormal data packets, marking the locations of different fields, and locating the meaning of fields based on the device manufacturer's debug logs, and identifying the type and source of abnormal fields, specifically include:

[0035] When a device anomaly is triggered (such as a PLC alarm signal or SNMP trap), the original traffic at the moment of the fault is captured through an optical splitter. Wireshark (a tool) is used to filter out abnormal function codes (such as the Modbus unconventional code 0x43) or packets with excessive length to obtain the abnormal data packets.

[0036] Use a Hex editor (such as 010 Editor) to compare the abnormal data packet byte by byte with the protocol specification (such as the Modbus standard), marking the offset (such as bytes 6-9), type (such as floating point number vs. integer), and encoding (such as big endian vs. little endian) of the different fields.

[0037] Export the PLC register mapping table or debug log using the device manufacturer's tool (such as the Siemens TIA Portal), align log events (such as "temperature exceeding limit alarm") with the captured packet timestamps, and correlate abnormal field value changes.

[0038] In one embodiment, the present invention provides a secure data collection method for an industrial control network. The method includes collecting complete communication traffic between devices through a mirror port or optical splitter; using a tool to analyze data packets to identify fixed headers and variable fields; inferring the meaning of fields through multiple interactive tests; deciphering unknown protocol structures, generating parsing rules for the original protocol, writing the protocol field offset, length, and type into a configuration file, and obtaining a parsing plug-in. The steps specifically include:

[0039] Full traffic acquisition based on IEEE 1588 time synchronization uses an industrial-grade optical splitter to capture all communication traffic between devices (including normal operation, failure, initialization, and other scenarios). TCPdump or dedicated packet capture equipment (such as Keysight NTO) is used to save the data as a PCAP file to ensure data integrity.

[0040] Use Scapy or Kaitai Struct (both tools) to analyze data packets, identify fixed headers (such as transaction IDs and function codes), variable fields (such as sensor values), and check bits. Through interactive testing (such as forcing HMI parameters to be modified), observe changes in field values and infer semantics (such as a 4-byte field changing linearly with the temperature setting);

[0041] Write the field offset, length, and type (such as uint16_be and float32_le) into the YAML / JSON configuration file, develop a Wireshark Lua plug-in or Python parsing script to implement automatic decoding and automatically obtain the parsing plug-in.

[0042] In one embodiment, the present invention provides a secure data collection method for an industrial control network, wherein the steps of inserting a parsing plug-in into a protocol gateway; removing meaningless padding bytes or private extension fields in the protocol, adjusting the endianness, unit, and encoding as needed; and encapsulating the data into a standard protocol output specifically include:

[0043] Load the parsing plug-in configuration file in the protocol gateway (Node-RED / Kepware), initialize field offsets and type mapping rules, and use regular expression matching to remove private extension fields (such as vendor-defined checksums) and meaningless padding bytes (such as a 16-byte trailing 0xAA), retaining the core business data fields.

[0044] Perform endian conversion (e.g., converting little-endian floating-point numbers to big-endian) and unit conversion (e.g., multiplying the original PSI unit by 6.895 to convert it to kPa) according to the configuration file. Transcode special encoding fields (e.g., converting the 4-byte BCD code "0x12345678" to decimal 12345678). Also, align timestamps and add metadata tags.

[0045] The processed structured data is encapsulated according to the target protocol specifications (such as OPC UA using the NodeId+DataValue information model, and MQTT layered by topic), and finally output through the gateway's standard interface (OPC UA Server / MQTT Broker) to complete the protocol standardization conversion.

[0046] In one embodiment, the present invention provides a secure data collection method for an industrial control network. The method includes collecting complete communication traffic between devices through a mirror port or optical splitter; using a tool to analyze data packets to identify fixed headers and variable fields; inferring the meaning of fields through multiple interactive tests; deciphering unknown protocol structures, generating parsing rules for the original protocol, writing protocol field offsets, lengths, and types into a configuration file, and obtaining a parsing plug-in. The method also includes:

[0047] Collect communication traffic samples from devices from multiple vendors (such as Siemens S7 and Mitsubishi MC), extract static features (such as protocol header Magic Number: 0x32 / 0x72 for Siemens S7 and 0x5000 for Mitsubishi MC), dynamic features (function code distribution: Siemens S7 read / write code is 0x04 / 0x05, MC is 0x01 / 0x02), and port numbers (Siemens S7 defaults to 102, MC 5001), and build a labeled protocol feature sample library (CSV / YAML format).

[0048] Define the fingerprint library architecture, which includes the protocol name, version, feature field offset, and matching rules. Extract the rules through sample library feature analysis to build a structured fingerprint library. (For example, the Siemens S7 communication protocol V1.0 features "bytes 1-2 = 0x3272," while V2.0 features "bytes 1-2 = 0x7272 and byte 5 = 0x01." Mitsubishi MC protocol uses "byte 3 function code ∈ [0x01, 0x0A]" to differentiate versions.)

[0049] Static feature precise matching: Prioritizes scanning the packet header for matching predefined unique identifiers, including the protocol header magic number (such as 0x3272 for S7) and the port number. If they fully match, the protocol type and version are directly determined. Dynamic feature probabilistic matching: For feature conflict scenarios (such as multiple protocols on the same port), the frequency of function codes is counted (for example, if the proportion of S7 0x04 read instructions in the traffic is greater than 80%, S7 is prioritized), combined with the distribution weight of equipment manufacturers (for example, if Siemens equipment in the workshop accounts for 70%). Confidence grading decision-making: Calculates the confidence level based on the number of successfully matched features (for example, matching 3 / 5 features → 60%). If the confidence level is above a threshold (such as 90%), the result is output; if the confidence level is below the threshold, a manual review process is triggered, unrecognized features are recorded, and feedback is provided. Version differentiation processing: For different versions of the same protocol (such as S7 V1.0 / V2.0), fine-grained differentiation is performed using the version flag field (such as the fifth byte = 0x01). If there is no flag, the latest effective version rule is selected based on the timestamp.

[0050] When unidentified traffic is detected, automated feature extraction (such as fixed header length and function code entropy analysis) is triggered to generate candidate fingerprints, which are manually reviewed and then entered into the fingerprint database.

[0051] Compared with the existing technology, the beneficial effect of the present invention is: when the present invention detects that the protocol field is not standardized, it will compare the standard protocol document, quickly mark the abnormal field, infer the meaning of the field, and finally generate the protocol parsing rules, obtain the parsing plug-in, and encapsulate the data into a standard protocol output, so that the originally messy custom data can be directly used by the upper-level system. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Figure 1 A schematic diagram of a secure data acquisition system for an industrial control network provided by an embodiment of the present invention.

[0053] Figure 2 A schematic diagram of a module for abnormal identification provided in an embodiment of the present invention.

[0054] Figure 3 This is a schematic diagram of the first part of the abnormal integrity identification module provided in an embodiment of the present invention.

[0055] Figure 4 A schematic diagram of a protocol adjustment output module provided in an embodiment of the present invention.

[0056] Figure 5 This is a schematic diagram of the second part of the abnormal integrity identification module provided in an embodiment of the present invention.

[0057] Figure 6 A flowchart of a secure data collection method for an industrial control network provided by an embodiment of the present invention.

[0058] Figure 7 A schematic diagram of a process for collecting and identifying the type and source of abnormal traffic provided by an embodiment of the present invention.

[0059] Figure 8 A schematic diagram of a process for obtaining a parsing plug-in according to an embodiment of the present invention.

[0060] Figure 9 A schematic diagram of the process of converting a protocol into a standard protocol output according to an embodiment of the present invention.

[0061] Figure 10 A schematic diagram of the process of establishing an automatic matching protocol for a fingerprint database according to an embodiment of the present invention. DETAILED DESCRIPTION

[0062] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0063] In one embodiment, Figure 1As shown in the figure, the secure data acquisition system for industrial control network includes:

[0064] Anomaly Targeted Identification Module 1 is used to capture raw traffic and identify abnormal packet structures (through small-scale, targeted data collection to quickly identify protocol anomaly characteristics). It compares standard protocol documents with abnormal packets and marks the locations of different fields. It also uses the device manufacturer's debug log to locate the meaning of the fields (such as the PLC register mapping table) and identify the type and source of the abnormal fields.

[0065] Anomaly Complete Identification Module 2 is used to collect complete communication traffic between devices (through complete and systematic data collection and the construction of protocol parsing rules); use tools (such as Scapy and Netzob) to analyze data packets and identify fixed headers and variable fields; infer the meaning of fields through multiple interactive tests (such as modifying register values and observing changes in responses); decipher unknown protocol structures, generate parsing rules for the original protocol, and write protocol field offsets, lengths, and types into configuration files (such as YAML and JSON) to obtain parsing plug-ins;

[0066] The protocol adjustment output module 3 is used to insert parsing plug-ins into protocol gateways (such as Node-RED and Kepware); remove meaningless padding bytes or private extension fields in the protocol, adjust the endianness (big endian ↔ little endian), unit (PSI → kPa), and encoding (BCD → decimal) as needed; and encapsulate data into standard protocol output (such as OPC UA information model and MQTT message).

[0067] The purpose of the Anomaly Targeted Identification Module 1 is to quickly detect threats. This involves collecting small amounts of device communication traffic (such as real-time PLC data packets) and comparing it to standard protocol documentation (such as Modbus function code lists). This allows for rapid identification of anomalous fields (such as invalid register addresses or exceeding thresholds). This is then combined with device logs (such as PLC alarm records) to pinpoint the source of the problem, thereby identifying the type and source of the anomalous fields. The Complete Anomaly Identification Module 2 aims to thoroughly analyze protocol rules. This involves long-term collection of traffic across all scenarios (normal operation, faults, etc.), analyzing data patterns (such as fixed headers and variable value segments), and inferring field meanings through active testing (such as modifying parameters and observing responses). Ultimately, protocol parsing rules (such as field location, data type, and endianness) are generated, resulting in a parsing plug-in. The core of the Protocol Adjustment Output Module 3 is to standardize data formats. Loading a parsing plug-in into the industrial gateway removes redundant content (such as vendor-specific fields), converts data formats (such as adjusting numerical order and unit conversion), and encapsulates them into standard protocols (such as OPC UA or MQTT), enabling the previously complex custom data to be directly used by upper-layer systems.

[0068] In one embodiment, Figure 2As shown, the security data acquisition system of the industrial control network, the abnormality identification module 1 includes:

[0069] The abnormal data packet acquisition unit 11 is configured to capture the original traffic at the moment of the fault through an optical splitter when a device abnormality is triggered (such as a PLC alarm signal or an SNMP Trap), and use Wireshark (a tool) to filter out abnormal function codes (such as the Modbus unconventional code 0x43) or data packets with excessive length to obtain the abnormal data packets;

[0070] Anomaly comparison marking unit 12 is used to compare the abnormal data packet with the protocol specification (such as the Modbus standard) byte by byte using a Hex editor (such as 010 Editor), marking the offset (such as bytes 6-9), type (such as floating point number vs. integer), and encoding (such as big endian vs. little endian) of the difference field;

[0071] The abnormality correlation unit 13 is used to export the PLC register mapping table or debug log through the equipment manufacturer's tool (such as Siemens TIA Portal), align the log event (such as "temperature limit alarm") with the captured packet timestamp, and correlate the abnormal field value changes.

[0072] The Abnormal Packet Acquisition Unit 11 uses an optical splitter to capture raw communication data (such as network traffic triggered by a PLC alarm) at the moment of the fault in real time. Using tools to filter out abnormal features (such as unusual function codes or oversized packets), it identifies suspicious packets as the starting point for analysis. The Abnormal Comparison and Marking Unit 12 compares the abnormal packet byte by byte with the standard protocol (such as the Modbus function code table), noting the location and type of the discrepant fields (e.g., a field that should be an integer but contains a floating-point encoding), thereby pinpointing the specific offset of the abnormal point within the message. The Abnormal Correlation Unit 13 combines internal device data (such as the PLC register mapping table and alarm events in the debug log) to align the captured packet timestamp with the log record (e.g., a "temperature limit alarm" occurs synchronously with a sudden change in the abnormal field value), verifying the actual impact of the abnormal field (e.g., register tampering causing device loss of control).

[0073] In one embodiment, Figure 3 As shown, the abnormal integrity identification module 2 of the secure data acquisition system of the industrial control network includes:

[0074] Full traffic acquisition unit 21, used for full traffic acquisition based on IEEE 1588 time synchronization, uses an industrial-grade optical splitter to capture all communication traffic between devices (including normal operation, failure, initialization, and other scenarios), and uses tcpdump or a dedicated packet capture device (such as Keysight NTO) to save it as a PCAP file to ensure data integrity;

[0075] The data packet analysis unit 22 is used to analyze data packets using Scapy or Kaitai Struct (both tools), identify fixed headers (such as transaction IDs and function codes), variable fields (such as sensor values), and check bits, observe field value changes through interactive testing (such as forced modification of HMI parameters), and infer semantics (such as a 4-byte field changing linearly with the temperature setting value);

[0076] The parsing plug-in obtaining unit 23 is used to write the field offset, length, and type (such as uint16_be and float32_le) into the YAML / JSON configuration file, develop a Wireshark Lua plug-in or a Python parsing script, realize automatic decoding, and automatically obtain the parsing plug-in.

[0077] The Full Traffic Collection Unit 21 (Full Traffic Collection) uses high-precision time synchronization technology (such as IEEE 1588) and industrial optical splitters to capture raw communication data from all scenarios (including device initialization, normal operation, and failures). This data is saved as complete PCAP files, ensuring comprehensive data coverage and providing a reliable foundation for protocol reverse engineering. The Packet Analysis Unit 22 (Protocol Reverse Parsing) utilizes tools to analyze packet patterns (such as protocol headers and function codes) and their changing patterns (such as the floating range of sensor values). Combined with active testing (such as modifying parameters to observe field changes), it infers field meanings (such as which 4-byte field corresponds to a temperature value). Ultimately, it generates a configuration file that includes field locations, types, and conversion rules, and develops an automated parsing plug-in. Parsing plug-in acquisition unit 23 (protocol feature library construction) collects traffic samples from devices of multiple manufacturers (such as Siemens and Mitsubishi), extracts static features (such as protocol header identifiers) and dynamic features (such as function code distribution patterns), establishes a labeled protocol fingerprint library (such as "Siemens S7 protocol header is 0x3272"), and designs matching rules (such as determining protocol type based on function code frequency) to solve the problem of accurate identification in multi-protocol mixed scenarios.

[0078] In one embodiment, Figure 4 As shown, the secure data acquisition system of the industrial control network, the protocol adjustment output module 3 includes:

[0079] The byte field removal unit 31 is used to load and parse the plug-in configuration file in the protocol gateway (Node-RED / Kepware), initialize the field offset and type mapping rules, and remove private extension fields (such as manufacturer-defined checksums) and meaningless padding bytes (such as a 16-byte trailing 0xAA) through regular expression matching, retaining the core business data fields.

[0080] The conversion processing unit 32 is used to perform endian conversion (e.g., converting little-endian floating-point numbers to big-endian), converting numerical units (e.g., multiplying the original PSI unit by 6.895 to convert it to kPa), transcoding special encoding fields (e.g., converting the 4-byte BCD code "0x12345678" to decimal 12345678), aligning timestamps, and adding metadata tags according to the configuration file;

[0081] The protocol standardization unit 33 is used to encapsulate the processed structured data according to the target protocol specification (such as OPC UA using the NodeId+DataValue information model, MQTT layered by topic), and finally output it through the gateway's standard interface (OPC UAServer / MQTT Broker) to complete the protocol standardization conversion.

[0082] The byte field removal unit 31 (data cleaning and field mapping) loads and parses the plugin configuration file to identify and remove redundant fields (such as manufacturer-defined padding bytes or private checksums), retaining only core business data (such as sensor readings and control instructions), reducing the burden of data transmission and processing. The conversion processing unit 32 (data format conversion) adjusts data details according to actual needs: for example, converting little-endian numbers to the universal big-endian format, converting original units (such as imperial PSI) to standard units (kPa), or decoding special formats (such as BCD to decimal), ensuring that data values comply with the specifications of the upper-layer system. The protocol standardization unit 33 (standardized encapsulation) restructures the processed data according to the target protocol (such as OPC UA or MQTT) (such as defining hierarchical topics, adding timestamps and metadata tags), and ultimately outputs it through a universal interface, allowing the originally dispersed proprietary protocol data to be directly parsed by a unified monitoring platform (such as a SCADA system or cloud platform).

[0083] In one embodiment, Figure 5 As shown, the security data acquisition system of the industrial control network, the abnormal integrity identification module 2 also includes:

[0084] The sample library establishment unit 24 is used to collect communication traffic samples from devices of multiple manufacturers (such as Siemens S7 and Mitsubishi MC), extract static features (such as protocol header Magic Number: 0x32 / 0x72 for Siemens S7 and 0x5000 for Mitsubishi MC), dynamic features (function code distribution: read / write code 0x04 / 0x05 for Siemens S7 and 0x01 / 0x02 for MC), and port number (default 102 for Siemens S7 and 5001 for MC), and establish a labeled protocol feature sample library (CSV / YAML format);

[0085] The fingerprint library establishment unit 25 is used to define the fingerprint library architecture, which includes the protocol name, version, feature field offset, and matching rules. The rules are refined by analyzing the sample library features to build a structured fingerprint library (for example, the Siemens S7 communication protocol V1.0 features "bytes 1-2 = 0x3272", while V2.0 features "bytes 1-2 = 0x7272 and byte 5 = 0x01"; the Mitsubishi MC protocol distinguishes versions by "byte 3 function code ∈ [0x01, 0x0A]");

[0086] The protocol matching unit 26 is used for precise matching of static features: it preferentially scans the packet header and matches a predefined unique identifier, which includes the protocol header Magic Number (such as 0x3272 for S7) and the port number. If they fully match, the protocol type and version are directly determined. Dynamic feature probabilistic matching: for feature conflict scenarios (such as multiple protocols on the same port), the frequency of function codes is counted (for example, if the proportion of Siemens S7 0x04 read instructions in the traffic is greater than 80%, it is preferentially determined to be Siemens S7), combined with the distribution weight of equipment manufacturers (such as if Siemens equipment in the workshop accounts for 70%). Confidence grading decision-making: the confidence level is calculated based on the number of successfully matched features (such as matching 3 / 5 features, the confidence level is 60%). If the confidence level is above a threshold (such as 90%), the result is output; if the confidence level is below the threshold, the manual review process is triggered, and unrecognized features are recorded and feedback is provided. Version differentiation processing: for different versions of the same protocol (such as S7V1.0 / V2.0), the version flag field (such as the fifth byte = 0x01) is used for fine-grained differentiation. If there is no flag, the latest effective version rule is selected according to the timestamp.

[0087] The fingerprint library update unit 27 is used to trigger automatic feature extraction (such as fixed header length and function code entropy analysis) when unidentified traffic is detected, generate candidate fingerprints, and manually review them before entering the fingerprint library.

[0088] Industrial scenarios often involve a mix of device protocols from multiple vendors (for example, the coexistence of Siemens S7 and Mitsubishi MC), and protocol fields may change with firmware upgrades. Therefore, it's necessary to add a protocol fingerprint library to the generated parsing rules to automatically match device types and versions based on characteristic fields (such as the Magic Number in the header and function code distribution).

[0089] The Sample Library Establishment Unit 24 (Multi-vendor Sample Collection) collects communication traffic from various devices (e.g., Siemens and Mitsubishi), extracts static features (e.g., protocol header identifiers and port numbers) and dynamic features (e.g., function code distribution patterns), and builds a tagged protocol sample library, providing a data foundation for subsequent analysis. The Fingerprint Library Establishment Unit 25 (Fingerprint Library Architecture Design) extracts matching rules based on sample features (e.g., "If the first two bytes of the protocol header are 0x3272, it identifies a Siemens S7"), constructs a structured fingerprint library, and clearly identifies distinguishing features between different protocol versions (e.g., the location of the version number field). The Protocol Matching Unit 26 (Hierarchical Matching Decision) combines static exact matching (prioritizing unique identifiers) with dynamic probabilistic matching (counting function code frequencies). Through confidence calculation (e.g., the proportion of matching features) and weight adjustment (taking into account device vendor distribution), it improves recognition accuracy in complex scenarios and triggers manual review of conflicting results. The Fingerprint Library Update Unit 27 (Unknown Protocol Handling) automatically extracts new features from unidentified traffic to generate candidate rules. After manual verification, the fingerprint library is updated, enabling the continuous expansion of protocol knowledge.

[0090] In one embodiment, Figure 6 As shown, the secure data collection method for industrial control networks includes the following steps:

[0091] Step S1: (Using small-scale, targeted data collection to quickly identify protocol anomaly characteristics) captures raw traffic and identifies the structure of abnormal data packets. Compares the standard protocol document with the abnormal data packets and marks the locations of the different fields. Combined with the device manufacturer's debug log, locates the meaning of the fields (such as the PLC register mapping table) and identifies the type and source of the abnormal fields.

[0092] Step S2 (constructing protocol parsing rules through complete and systematic data collection) collects the complete communication traffic between devices; uses tools (such as Scapy and Netzob) to analyze the data packets and identify fixed headers and variable fields; infers the meaning of the fields through multiple interactive tests (such as modifying register values to observe changes in responses); deciphers the unknown protocol structure and generates parsing rules for the original protocol. The protocol field offset, length, and type are written into a configuration file (such as YAML or JSON) to obtain a parsing plug-in;

[0093] In step S3, insert a parsing plug-in into the protocol gateway (such as Node-RED or Kepware). Remove meaningless padding bytes or private extension fields from the protocol, adjust the endianness (big endian ↔ little endian), unit (PSI → kPa), and encoding (BCD → decimal) as needed, and encapsulate the data into a standard protocol output (such as an OPC UA information model or MQTT message).

[0094] In step S3, adjusting the endianness, unit, and encoding are all common techniques. Here, a brief introduction to adjusting the endianness is provided, and the adjustment of the unit and encoding will not be elaborated further;

[0095] Endianness adjustment: According to the protocol field definition (for example, "float32_le" marked in the configuration file indicates a little-endian floating-point number), through byte manipulation functions in a programming language (such as Python), for example, struct.unpack('<f', bytes) is used to read the original bytes. If the big-endian order is required for the target, then struct.pack('>f', value) is used to repackage. For example, the little-endian byte stream b'\x00\x00\x80\x3f' is parsed as 1.0, and after being converted to big-endian, it becomes b'\x3f\x80\x00\x00'.

[0096] In one embodiment, as Figure 7 shown, for the method of secure data collection in an industrial control network, in the step S1, capturing the original traffic and identifying the abnormal packet structure; comparing the standard protocol document with the abnormal packet and marking the positions of the different fields; combining the debugging logs of the device manufacturer to locate the meanings of the fields and identifying the types and sources of the abnormal fields, specifically includes:

[0097] Step S11, when a device exception is triggered (such as a PLC alarm signal or an SNMP Trap), capture the original traffic at the moment of the fault through an optical splitter, and use Wireshark (a tool) to filter abnormal function codes (such as Modbus non-conventional code 0x43) or packets with an over-limit length to obtain abnormal packets;

[0098] Step S12, use a Hex editor (such as 010 Editor) to compare the abnormal packet and the protocol specification (such as the Modbus standard) byte by byte, and mark the offsets (such as bytes 6-9), types (such as floating-point number vs integer), and encodings (such as big-endian vs little-endian) of the different fields;

[0099] Step S13, export the PLC register mapping table or debugging logs through the device manufacturer's tool (such as Siemens TIA Portal), align the log events (such as "temperature over-limit alarm") with the capture timestamps, and associate the changes in the abnormal field values.

[0100] Automated root cause analysis tools (such as knowledge graphs or causal inference models) can be introduced in step S11. By associating the historical fault case library with the real-time abnormal traffic characteristics (such as abnormal function codes and sudden changes in field values), fault hypotheses can be automatically generated.

[0101] In one embodiment, as Figure 8As shown, the secure data collection method for industrial control networks, in step S2, collects complete communication traffic between devices through a mirror port or a splitter; uses a tool to analyze data packets to identify fixed headers and variable fields; infers the meaning of fields through multiple interactive tests; deciphers unknown protocol structures, generates parsing rules for the original protocol, writes the protocol field offset, length, and type into a configuration file, and obtains a parsing plug-in step, specifically including:

[0102] Step S21: Full traffic collection based on IEEE 1588 time synchronization. Use an industrial-grade optical splitter to capture all communication traffic between devices (including normal operation, failure, and initialization scenarios). Use tcpdump or a dedicated packet capture device (such as Keysight NTO) to save the data as a PCAP file to ensure data integrity.

[0103] Step S22: Use Scapy or Kaitai Struct (both tools) to analyze the data packet, identify the fixed header (such as transaction ID, function code), variable fields (such as sensor values), and check bits, and observe changes in field values through interactive testing (such as forcibly modifying human-machine interface (HMI) parameters) to infer semantics (such as whether a 4-byte field changes linearly with the temperature setting value).

[0104] In step S23, the field offset, length, and type (such as uint16_be and float32_le) are written into the YAML / JSON configuration file, and a Wireshark Lua plug-in or Python parsing script is developed to implement automatic decoding and automatically obtain the parsing plug-in.

[0105] In step S23, metadata such as device model and firmware version (e.g., device information collected via SNMP) can be integrated to dynamically match protocol signatures. For example, if a device's firmware version is known to be V2.1, its historical protocol rules (e.g., specific validation algorithms) will be prioritized to avoid repeated reverse engineering analysis. This expansion uses device context to narrow the scope of protocol matching, improving parsing accuracy and efficiency.

[0106] In one embodiment, Figure 9 As shown, the secure data collection method for industrial control networks, said step S3, inserting a parsing plug-in into the protocol gateway; removing meaningless padding bytes or private extension fields in the protocol, adjusting the end sequence, unit, and encoding as needed; encapsulating the data into a standard protocol output step, specifically includes:

[0107] Step S31: Load the parsed plug-in configuration file in the protocol gateway (Node-RED / Kepware), initialize the field offset and type mapping rules, remove private extension fields (such as manufacturer-defined checksums) and meaningless padding bytes (such as a 16-byte trailing 0xAA) through regular expression matching, and retain the core business data fields.

[0108] Step S32 , performing endian conversion (e.g., converting little-endian floating-point numbers to big-endian) and unit conversion (e.g., multiplying the original PSI unit by 6.895 to convert it to kPa) according to the configuration file, transcoding special coded fields (e.g., converting the 4-byte BCD code "0x12345678" to decimal 12345678), aligning timestamps, and adding metadata tags.

[0109] In step S33, the processed structured data is encapsulated according to the target protocol specification (e.g., OPC UA uses the NodeId+DataValue information model, and MQTT is layered by topic), and finally output through the gateway's standard interface (OPC UA Server / MQTTBroker), completing the protocol standardization conversion.

[0110] In step S31, the scrubbing granularity is dynamically adjusted based on the data's intended use (e.g., real-time monitoring or long-term storage). For example, in high-bandwidth scenarios, only key fields are retained, while in low-bandwidth scenarios, compression algorithms (e.g., LZ4) are enabled to process redundant bytes. Alternatively, private fields may be selectively retained based on business rules (e.g., compliance requirements), improving data processing flexibility and resource utilization.

[0111] In one embodiment, Figure 10 As shown, the secure data collection method for industrial control networks, in step S2, collects complete communication traffic between devices through a mirror port or a splitter; uses a tool to analyze data packets to identify fixed headers and variable fields; infers the meaning of fields through multiple interactive tests; deciphers unknown protocol structures, generates parsing rules for the original protocol, writes the protocol field offset, length, and type into a configuration file, and obtains a parsing plug-in step, further comprising:

[0112] Step S24: Collect communication traffic samples from devices from multiple vendors (e.g., Siemens S7 and Mitsubishi MC), extract static features (e.g., protocol header Magic Number: 0x32 / 0x72 for Siemens S7, 0x5000 for Mitsubishi MC), dynamic features (function code distribution: Siemens S7 read / write code is 0x04 / 0x05, MC is 0x01 / 0x02), and port number (Siemens S7 defaults to 102, MC defaults to 5001), and create a labeled protocol feature sample library (CSV / YAML format);

[0113] Step S25: Define the fingerprint library architecture, which includes the protocol name, version, feature field offset, and matching rules. The rules are extracted through sample library feature analysis to construct a structured fingerprint library (for example, the Siemens S7 communication protocol V1.0 features "bytes 1-2 = 0x3272", while V2.0 features "bytes 1-2 = 0x7272 and byte 5 = 0x01"; the Mitsubishi MC protocol distinguishes versions by "byte 3 function code ∈ [0x01, 0x0A]").

[0114] Step S26, static feature precise matching: Prioritize scanning the packet header to match a predefined unique identifier, which includes the protocol header Magic Number (such as 0x3272 for S7) and the port number. If they fully match, the protocol type and version are directly determined. Dynamic feature probabilistic matching: For feature conflict scenarios (such as multiple protocols on the same port), the frequency of function codes is counted (for example, if the proportion of S7 0x04 read instructions in the traffic is greater than 80%, S7 is prioritized), combined with the distribution weight of equipment manufacturers (such as Siemens equipment in the workshop accounts for 70%). Confidence level decision-making: Calculate the confidence level based on the number of successfully matched features (such as matching 3 / 5 features → 60%). If the confidence level is above the threshold (such as 90%), the result is output; if the confidence level is below the threshold, the manual review process is triggered, and unrecognized features are recorded and feedback is provided. Version differentiation processing: For different versions of the same protocol (such as S7 V1.0 / V2.0), fine-grained differentiation is performed through the version flag field (such as the fifth byte = 0x01). If there is no flag, the latest effective version rule is selected according to the timestamp.

[0115] In step S27, when unrecognized traffic is detected, automated feature extraction (such as fixed header length and function code entropy analysis) is triggered to generate candidate fingerprints, which are manually reviewed and then entered into the fingerprint database.

[0116] In step S27, an automated feature extraction and verification process is designed. For example, traffic clustering (such as the DBSCAN algorithm) is used to identify similar protocol variants, automatically generate candidate rules (such as new magic numbers), and verify their confidence based on historical samples, reducing the frequency of manual review. Device manufacturers can also submit protocol specifications, which are automatically parsed into fingerprint library entries, enabling dynamic accumulation of protocol knowledge.

[0117] It should be understood that, although the various steps in the flow chart of each embodiment of the present invention are shown in sequence according to the indication of the arrows, these steps are not necessarily performed in sequence according to the order indicated by the arrows. Unless otherwise specified herein, the execution of these steps is not strictly limited in order, and these steps can be performed in other orders. Moreover, at least a portion of the steps in each embodiment may include a plurality of sub-steps or a plurality of stages, and these sub-steps or stages are not necessarily performed at the same time, but can be performed at different times, and the execution order of these sub-steps or stages is not necessarily performed in sequence, but can be performed in turn or alternately with at least a portion of other steps or sub-steps or stages of other steps.

[0118] The technical features of the above-mentioned embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above-mentioned embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0119] The above-described embodiments merely illustrate several implementations of the present invention, and while their descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art would be able to make numerous variations and improvements without departing from the spirit of the present invention, all of which fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be determined by the appended claims.

[0120] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

[0121] In addition, it should be understood that although this specification is described in terms of implementation methods, not every implementation method contains only one independent technical solution. This narrative method of the specification is only for the sake of clarity. Those skilled in the art should regard the specification as a whole. The technical solutions in each embodiment can also be appropriately combined to form other implementation methods that can be understood by those skilled in the art.

Claims

1. A secure data acquisition system for industrial control networks, characterized in that: The secure data acquisition system for the industrial control network includes: The anomaly identification module is used to capture raw traffic and identify abnormal packet structures. It compares standard protocol documents with abnormal packets and marks the locations of different fields. It also uses the device manufacturer's debug logs to locate the meaning of the fields and identify the type and source of the abnormal fields. The anomaly complete identification module is used to analyze data packets using tools to identify fixed headers and variable fields; infer the meaning of fields through multiple interactive tests; crack unknown protocol structures, generate parsing rules for the original protocol, write protocol field offsets, lengths, and types into the configuration file, and obtain a parsing plug-in; The protocol adjustment output module inserts a parsing plug-in into the protocol gateway; removes meaningless padding bytes or private extension fields in the protocol, adjusts the end sequence, unit, and encoding as needed; and encapsulates the data into a standard protocol output.

2. The secure data acquisition system for an industrial control network according to claim 1, characterized in that: The abnormality identification module includes: The abnormal data packet acquisition unit is used to capture the original traffic at the moment of the fault through the optical splitter when the device is triggered by an abnormality, and use Wireshark to filter the data packets with abnormal function codes or excessive length to obtain the abnormal data packets; The exception comparison marking unit is used to compare the abnormal data packet with the protocol specification byte by byte using a Hex editor, marking the offset, type and encoding of the difference field; The exception correlation unit is used to export the PLC register mapping table or debug log through the device manufacturer's tools, align log events with the captured packet timestamps, and correlate abnormal field value changes.

3. The secure data acquisition system for an industrial control network according to claim 1, characterized in that: The complete anomaly recognition module includes: Full-traffic collection unit, used for full-traffic collection based on IEEE 1588 time synchronization, uses an industrial-grade optical splitter to capture all communication traffic between devices and saves it as a PCAP file using tcpdump or a dedicated packet capture device to ensure data integrity; The packet analysis unit is used to analyze packets using Scapy or Kaitai Struct, identify fixed headers, variable fields, and check bits, observe field value changes, and infer semantics through interactive testing; The parsing plug-in acquisition unit is used to write field offsets, lengths, and types into the YAML / JSON configuration file, develop Wireshark Lua plug-ins or Python parsing scripts, implement automated decoding, and automatically obtain the parsing plug-in.

4. The secure data acquisition system for an industrial control network according to claim 1, characterized in that: The protocol adjustment output module includes: The byte field removal unit is used to load the parsing plug-in configuration file in the protocol gateway, initialize the field offset and type mapping rules, remove private extension fields and meaningless padding bytes through regular matching, and retain the core business data fields; The conversion processing unit is used to perform endian conversion and numerical unit conversion according to the configuration file, transcode special encoding fields, align timestamps and add metadata tags; The protocol standardization unit is used to encapsulate the processed structured data according to the target protocol specification, and finally output it through the standard interface of the gateway to complete the protocol standardization conversion.

5. The secure data acquisition system for an industrial control network according to any one of claims 1 to 4, characterized in that: The complete anomaly recognition module also includes: The sample library establishment unit is used to collect communication traffic samples from devices of multiple manufacturers, extract static features, dynamic features and port numbers, and establish a protocol feature sample library with labels; The fingerprint library establishment unit is used to define the fingerprint library architecture, which includes the protocol name, version, feature field offset, and matching rules. It extracts rules through sample library feature analysis and builds a structured fingerprint library. The protocol matching unit is used to preferentially scan the packet header and match the predefined unique identifier, which includes the protocol header Magic Number and port number. If they fully match, the protocol type and version are directly determined. In feature conflict scenarios, the frequency of function codes is counted and the weight of the device manufacturer distribution is combined. The confidence level is calculated based on the number of successfully matched features. If it is above the threshold, the result is output. If it is below the threshold, the manual review process is triggered, and unrecognized features are recorded and feedback is provided. Different versions of the same protocol are fine-grainedly distinguished through the version flag field. If there is no flag, the latest effective version rule is selected according to the timestamp. The fingerprint library update unit is used to trigger automatic feature extraction when unidentified traffic is detected, generate candidate fingerprints, and enter them into the fingerprint library after manual review.

6. A method for secure data collection in an industrial control network, characterized in that: The method for collecting secure data in an industrial control network comprises the following steps: Capture raw traffic and identify abnormal data packet structures; compare standard protocol documents with abnormal data packets and mark the locations of different fields; combine with the device manufacturer's debug logs to locate the meaning of the fields and identify the type and source of the abnormal fields; Collect complete communication traffic between devices; use tools to analyze data packets and identify fixed headers and variable fields; infer the meaning of fields through multiple interactive tests; decipher unknown protocol structures, generate parsing rules for the original protocol, write protocol field offsets, lengths, and types into the configuration file, and obtain a parsing plug-in; Insert a parsing plug-in into the protocol gateway; remove meaningless padding bytes or private extension fields in the protocol, adjust the endianness, unit, and encoding as needed; and encapsulate the data into a standard protocol for output.

7. The method for secure data collection in an industrial control network according to claim 6, characterized in that: The steps of capturing original traffic, identifying abnormal data packet structures, comparing standard protocol documents with abnormal data packets, marking the locations of different fields, and locating the meaning of fields based on the device manufacturer's debug logs, and identifying the types and sources of abnormal fields, specifically include: When a device anomaly is triggered, the original traffic at the moment of the fault is captured through an optical splitter. Wireshark is used to filter out packets with abnormal function codes or lengths exceeding the limit to obtain the abnormal data packets. Use a Hex editor to compare the abnormal data packet with the protocol specification byte by byte, marking the offset, type, and encoding of the different fields; Use the device manufacturer's tools to export the PLC register mapping table or debug log, align log events with packet capture timestamps, and correlate abnormal field value changes.

8. The method for secure data collection in an industrial control network according to claim 6, wherein: The complete communication traffic between devices is collected through a mirror port or optical splitter; tools are used to analyze data packets to identify fixed headers and variable fields; and the meaning of the fields is inferred through multiple interactive tests; Crack the unknown protocol structure, generate the parsing rules of the original protocol, write the protocol field offset, length, and type into the configuration file, and obtain the parsing plug-in steps, specifically including: Full traffic collection based on IEEE 1588 time synchronization uses an industrial-grade optical splitter to capture all communication traffic between devices and saves it as a PCAP file using tcpdump or dedicated packet capture equipment to ensure data integrity; Use Scapy or Kaitai Struct to analyze data packets, identify fixed headers, variable fields, and check bits, and observe changes in field values through interactive testing to infer semantics. Write the field offset, length, and type into the YAML / JSON configuration file, develop a Wireshark Lua plug-in or Python parsing script to implement automatic decoding and automatically obtain the parsing plug-in.

9. The method for secure data collection in an industrial control network according to claim 6, wherein: Inserting a parsing plug-in into the protocol gateway; Remove meaningless padding bytes or private extension fields in the protocol, and adjust endianness, units, and encoding as needed; The steps of encapsulating data into standard protocol output include: Load the parsing plug-in configuration file in the protocol gateway, initialize the field offset and type mapping rules, remove private extension fields and meaningless padding bytes through regular matching, and retain the core business data fields; Perform endian conversion, numerical unit conversion, transcoding of special encoding fields according to the configuration file, aligning timestamps and adding metadata tags; The processed structured data is encapsulated according to the target protocol specifications and finally output through the standard interface of the gateway to complete the protocol standardization conversion.

10. The method for secure data collection in an industrial control network according to any one of claims 6 to 9, characterized in that: The complete communication traffic between devices is collected through a mirror port or optical splitter; tools are used to analyze data packets to identify fixed headers and variable fields; and the meaning of the fields is inferred through multiple interactive tests; Cracking the unknown protocol structure, generating the parsing rules for the original protocol, writing the protocol field offset, length, and type into the configuration file, and obtaining the parsing plug-in steps also include: Collect communication traffic samples from devices from multiple vendors, extract static features, dynamic features, and port numbers, and build a labeled protocol feature sample library; Define the fingerprint library architecture, which includes the protocol name, version, feature field offset, and matching rules. Analyze the sample library features to extract the rules and build a structured fingerprint library. Prioritize scanning the packet header and matching predefined unique identifiers, including the protocol header MagicNumber and port number. If they fully match, the protocol type and version are directly determined. For feature conflict scenarios, the frequency of function codes is counted and combined with the device manufacturer's distribution weight. The confidence level is calculated based on the number of successfully matched features. If it exceeds the threshold, the result is output. If it falls below the threshold, the manual review process is triggered, and unrecognized features are recorded and feedback is provided. Different versions of the same protocol are fine-grainedly distinguished through the version flag field. If there is no flag, the latest effective version rule is selected according to the timestamp. When unidentified traffic is detected, automated feature extraction is triggered, candidate fingerprints are generated, and they are manually reviewed and entered into the fingerprint database.

Images