Industrial Internet of Things data transmission method

Abstract

The invention discloses an industrial Internet of Things data transmission method, and relates to the technical field of industrial Internet of Things. The system comprises a protocol adaptation analysis module, a data standardization processing module, a heterogeneous data fusion module and a deterministic transmission management module. The plug-in protocol analysis engine comprises a protocol feature fingerprint database and a plug-in engine maintenance unit, and breaks through the traditional curing mode of one protocol and one program: on one hand, the protocol feature fingerprint database can collect bottom features of more than 30 industrial protocols, and rapid matching is realized through a structured index table; and on the other hand, when the protocol is newly added or updated, only a new plug-in needs to be developed and put into a specified directory, the plug-in manager loads in real time without restarting an engine, the tedious operation of rewriting a program in a traditional scheme is reduced, meanwhile, the deep packet detection unit ensures the protocol analysis accuracy, and the protocol processing reliability is further improved through an abnormal alarm mechanism.

Description

Technical Field

[0001] This invention relates to the field of industrial Internet of Things (IoT) technology, and more specifically, to an industrial IoT data transmission method. Background Technology

[0002] In the field of Industrial Internet of Things (IIoT), devices manufactured by different vendors often use their own different transmission protocols, such as Modbus, OPCUA, and EtherCAT. This results in data that cannot be directly exchanged between devices, forming data silos. Although there are some protocol conversion methods in the existing technology, most of these methods are for specific protocols, have poor flexibility, are difficult to handle multiple types of data, and perform poorly in terms of data transmission latency and jitter control, failing to meet the high requirements of industrial scenarios for data transmission.

[0003] Chinese patent CN111930666A describes a high-speed configurable industrial protocol converter that extracts device addresses and function code features from protocol frames based on FPGA hardware logic to achieve conversion from fieldbus to industrial Ethernet. While the hardware parsing speed is fast and can reduce the conversion delay of a single protocol, it lacks a multi-modal data fusion unit and time synchronization mechanism. On the one hand, it cannot integrate PLC control data, sensor monitoring data, and vision inspection data, resulting in independent data from multiple devices, which cannot support advanced applications such as digital twins and collaborative control. On the other hand, the lack of a master-slave clock calibration mechanism means that cross-device data timestamp errors can reach the millisecond level, causing time misalignment between instructions and feedback data in industrial control, which can easily lead to problems such as robotic arm positioning deviation and false triggering of power grid protection instructions. Chinese patent CN201410019937 describes a multi-protocol conversion device based on wireless ZigBee, CAN bus, and Modbus / TCP. This device uses a microprocessor to create a fixed address mapping table to achieve targeted conversion between ZigBee, CAN, and Modbus / TCP protocols. While it supports data interoperability for some industrial protocols and avoids data silos between specific devices, its hard-coded fixed address mapping table only supports three preset protocols. When a new protocol is added or an existing protocol version is updated, the mapping table code must be rewritten and the system must be shut down for deployment, resulting in low efficiency for protocol expansion and maintenance. The downtime also disrupts industrial production continuity. Furthermore, this solution lacks a data standardization and fusion mechanism, making it unable to handle complex data types such as visual images and multi-device time-series data, hindering the collaborative mining of data value.

[0004] Therefore, we have made improvements to this and proposed an industrial IoT data transmission method. Summary of the Invention

[0005] This invention provides the following technical solutions: The application is as follows: An industrial Internet of Things (IoT) data transmission method includes: a protocol adaptation and parsing module, a data standardization processing module, a heterogeneous data fusion module, and a deterministic transmission management module, as detailed below: SA1, Begin; SA2: Protocol adaptation and parsing module, which parses and standardizes data packets of different industrial protocols through a pluggable protocol parsing engine. The pluggable protocol parsing engine includes a protocol feature fingerprint library, a deep packet detection unit, a semantic mapping unit, and a pluggable engine maintenance unit. SA3: Data standardization processing module, which receives the standardization instructions output by the protocol adaptation parsing module, and performs format conversion, semantic enhancement and edge preprocessing on the parsed data based on the five-tuple data model. The structure of the five-tuple data model is: timestamp, device ID, source protocol, data format and service tag. SA4: Heterogeneous data fusion module, including time synchronization unit, spatial association unit and multimodal fusion unit, receives standardized data output by the data standardization processing module, and realizes spatiotemporal integration of cross-device and multi-type data through time synchronization unit, spatial association unit and multimodal fusion unit; SA5: Deterministic transmission management module, including TSN transport layer traffic shaping unit, DDS-based publish and subscribe management unit and Bayesian network dynamic path selection unit, receives integrated data output by the heterogeneous data fusion module, and ensures the determinism and efficiency of data transmission through TSN transport layer traffic shaping unit, DDS-based publish and subscribe management unit and Bayesian network dynamic path selection unit. SA6, End.

[0006] The steps for constructing the protocol feature fingerprint database in the SA2 plug-in protocol parsing engine are as follows: SB1, Begin; SB2. Collect low-level characteristic parameters of more than 30 industrial protocols, including protocol port number, data frame start / end identifier, verification algorithm, and field offset; SB3. The feature parameters are stored in a structured manner, and an index table is established with the protocol name as the key and the feature parameter set as the value; SB4. Design a dynamic update interface that supports adding protocol feature parameters via plugins without modifying the core library structure; SB5, End.

[0007] The processing steps of the deep packet inspection unit in the SA2 pluggable protocol parsing engine are as follows: SC1, Start; SC2. The traffic splitting module performs initial filtering of data packets based on port number; SC3. Parse the data packet layer by layer to extract header identifiers, field lengths, and checksum characteristics; SC4. Compare the extracted features with the index table of the protocol feature fingerprint database. If the matching degree is ≥95%, determine the protocol type; otherwise, trigger an anomaly alarm. SC5, End.

[0008] The processing steps of the semantic mapping unit in the SA2 pluggable protocol parsing engine are as follows: SD1, Start; SD2. For a given protocol, extract its native instruction set; SD3 converts the native instruction set into standardized operations through a preset mapping rule base. The standardized operations include reading, writing, subscribing, and notification. SD4. Generate an intermediate message containing "protocol type + standardized operation + raw command parameters"; SD5, End.

[0009] The processing steps of the plug-in engine maintenance unit in the SA2 plug-in protocol parsing engine are as follows: SE1, Begin; SE2. Define a unified plugin interface, including protocol parsing, feature updating, and exception handling functions. All protocol plugins must implement this interface. SE3: When the engine starts, it scans the specified directory through the plugin manager and automatically loads plugins that conform to the interface specifications. When SE4 or the protocol is updated or added, you only need to develop a new plugin and put it in the specified directory. The plugin manager will detect and load it in real time without restarting the engine. SE5, End.

[0010] The steps for constructing a quintuple data model in SA3 are as follows: SF1, Begin; SF2. Generate a unique identifier for each piece of raw data. The timestamp is accurate to nanoseconds and based on the device's local clock. It will be calibrated by time synchronization later. The device ID uses a unique code of "manufacturer code + device model + serial number". The source protocol records the original protocol of the data. The data format marks the original format. The business label is initially empty. SF3. The data format in the quintuple is converted through a type conversion module. The type conversion module is based on the JSONSchema engine and supports the conversion of numerical formats. 16-bit integers are converted to 32-bit floating-point numbers. The conversion formula is float32=int16×0.001. The data structure is converted from PDO to JSON. The mapping rule is that the index 0x6040 of PDO is mapped to the JSON field 'Position'. Here, PDO is ProcessDataObject, a process data object. SF4. Add business tags to the quintuple through the semantic enhancement module: Load the industrial ontology library containing the association between "device type - data type - business tag", match the corresponding business tag according to the device ID and the converted data format and write it into the business tag field; SF5 employs a three-level filtering mechanism via an edge preprocessing module: the first level removes invalid data based on a threshold set by the business tag; the second level retains only the first and last data for continuously collected data with the same business tag, compressing redundant intermediate data; the third level uses the LZ77 algorithm for lossless compression, ensuring a data reduction of over 80%; the threshold for removing invalid data in the first level can be dynamically updated through the industrial ontology library, with the threshold update frequency matching the equipment data acquisition frequency.

[0011] SF6, End.

[0012] The specific steps of the heterogeneous data fusion module in SA4 are as follows: SG1, Begin; SG2. Through the time synchronization unit, a master clock and a slave clock are deployed in the industrial network. The master clock periodically sends a Sync synchronization message containing a transmission timestamp T1. After receiving the message, the slave clock records the reception timestamp T2. The slave clock sends a Delay_Req delay request message containing a transmission timestamp T3. After receiving the message, the master clock records the reception timestamp T4. The slave clock calculates the offset using the formula "clock offset = (T2-T1+T3-T4) / 2" and calibrates the local clock to ensure that the cross-device time synchronization error is ≤1μs. SG3. Using spatial association units, a device relationship graph is constructed based on GNN. An initial relationship graph is generated with devices as nodes and "physical connection", "control-controlled", and "data interaction" as edges. The GraphSAGE algorithm is used to train the model with node attributes and edge weights as input to learn the causal relationships between devices. Device interaction data is monitored in real time, and the edge weights are dynamically adjusted to update the relationship graph. The device relationship graph includes: device attribute type, model and location, physical wiring and communication links in the connection relationship, and historical interaction data. SG4, the multimodal fusion unit unifies multiple types of data into a digital twin model, including: defining mapping rules, associating multimodal data with the same time slice and related relationships based on the timestamps after time synchronization and the device relationship map, inputting the aligned multimodal data into the digital twin model, and updating the model's dynamic state to achieve real-time mapping between physical devices and virtual models. Specifically, the mapping rules are defined as follows: PLC control data is mapped to "actuator status", sensor monitoring data is mapped to "environmental parameters", and visual image data is mapped to "device appearance status" after CNN feature extraction. SG5, End.

[0013] The specific steps of deterministic transmission management in SA5 are as follows: SH1, Start; The SH2 and TSN transport layer traffic shaping units divide 1ms into N time slots, allocate dedicated time slots for critical data, and allocate shared time slots for non-critical data. Data is marked with priority levels 1 to 8. Critical data is set to level 1 and bound to a dedicated time slot, while non-critical data is set to levels 5 to 8 and shares the remaining time slots. A gating list is configured based on the 802.1Qbv protocol to specify the priority data allowed to be transmitted in each time slot. The gating switch is triggered by a hardware timer to ensure that the delay of critical data is ≤10μs. SH3, DDS-based publish and subscribe management unit: Define data topics by business tags, and associate each topic with a data structure based on the five-tuple model; configure QoS parameters for different topics (critical topics are configured with "reliable transmission + low latency", and non-critical topics are configured with "best-effort transmission + high throughput"); devices act as publishers to publish data to the DDS bus by topic, and subscribers receive data by matching topics and QoS parameters, supporting message routing efficiency of ≥100,000 messages / second when there are 100,000 concurrent devices; SH4, Bayesian Network Dynamic Path Selection Unit: Collects 12 parameters in real time (device type, data priority, network bandwidth, link load, transmission distance, packet loss rate, latency jitter, node processing capacity, protocol compatibility, security level, energy consumption index, and historical transmission success rate); trains a Bayesian network using historical transmission data as samples, learning the probabilistic relationship between each parameter dimension and the "path quality" evaluated by latency and reliability; inputs the current 12 parameters into the trained model, selects the path with the highest "optimal probability" to transmit data, and re-evaluates and adjusts the path every 100ms; SH5, End.

[0014] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention adopts a pluggable protocol parsing engine that includes a protocol feature fingerprint library and a pluggable engine maintenance unit, breaking through the traditional "one protocol, one program" fixed mode: On the one hand, the protocol feature fingerprint library can collect the underlying features of more than 30 industrial protocols and achieve fast matching through a structured index table; on the other hand, when adding or updating a protocol, only a new plug-in needs to be developed and placed in the specified directory. The plug-in manager loads in real time without restarting the engine, reducing the tedious operation of rewriting programs in traditional solutions. At the same time, the deep packet inspection unit ensures the accuracy of protocol parsing, and the anomaly alarm mechanism further improves the reliability of protocol processing.

[0015] 2. Based on the standardized processing of the five-tuple data model, the problem of "disorganized format, chaotic semantics, and excessive redundancy" in industrial data is solved: the timestamp is accurate to the nanosecond level and supports subsequent calibration; the device ID adopts "manufacturer code + device model + serial number" to ensure uniqueness, eliminating data identification chaos from the source; the type conversion module achieves accurate format conversion through the JSONSchema engine; the semantic enhancement module relies on the industrial ontology library to automatically match business tags; the three-level filtering of edge preprocessing can reduce the amount of data, greatly reduce the pressure of subsequent transmission and storage, and improve data processing efficiency.

[0016] 3. The heterogeneous data fusion module achieves deep collaboration across devices and multiple data types through "time synchronization, spatial association, and multimodal integration": The time synchronization unit adopts a master-slave clock mechanism and uses the clock offset formula (T2-T1+T3-T4) / 2 for calibration to ensure that the cross-device time synchronization error is ≤1μs, solving the traditional data "time misalignment" problem. The spatial association unit constructs a device relationship graph based on GNN, learns the causal relationship between devices through the GraphSAGE algorithm, dynamically updates the link weights, and clarifies the spatial association logic of data. The multimodal fusion unit maps PLC control data, sensor data, and visual image data to "actuator status," "environmental parameters," and "device appearance status," respectively, and inputs them into the digital twin model to achieve real-time physical-virtual mapping, enabling the originally isolated structured, semi-structured, and unstructured data to form effective associations and improving the utilization rate of data value.

[0017] 4. The deterministic transmission management module achieves "low latency, high reliability, and dynamic adaptation" transmission effects through multi-level optimization: The TSN transport layer traffic shaping unit divides 1ms into time slots, allocates a dedicated time slot for first-priority critical data, and ensures that the latency of critical data is ≤10μs based on the 802.1Qbv protocol; the DDS publish and subscribe management unit configures QoS parameters according to service tags, supporting message routing efficiency of ≥100,000 messages / second when there are 100,000 concurrent devices; the Bayesian network dynamic path selection unit collects 12-dimensional parameters in real time and re-evaluates the optimal path every 100ms to improve the data transmission success rate, fully meeting the high requirements of real-time control, fault early warning and other scenarios in industrial production. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the overall structure of the industrial Internet of Things data transmission method of this application; Figure 2 This is a schematic diagram illustrating the process of constructing the protocol feature fingerprint database for this application; Figure 3 This is a schematic diagram of the deep packet inspection unit processing flow in this application; Figure 4 This is a schematic diagram of the semantic mapping unit processing flow in this application; Figure 5 This is a schematic diagram of the processing flow of the plug-in engine maintenance unit in this application; Figure 6 A schematic diagram illustrating the process of constructing the quintuple data model for this application; Figure 7 This is a schematic diagram of the heterogeneous data fusion module processing flow in this application; Figure 8 This is a schematic diagram of the processing flow of the deterministic transmission management module in this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0020] Therefore, the following detailed description of embodiments of the present invention is not intended to limit the scope of the claimed invention, but merely illustrates some embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0021] It should be noted that, unless otherwise specified, the embodiments and features and technical solutions in the present invention can be combined with each other.

[0022] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0023] In the description of this invention, it should be noted that the terms "upper," "lower," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship commonly used when the product of this invention is in use, or the orientation or positional relationship commonly understood by those skilled in the art. These terms are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention. In addition, the terms "first," "second," etc., are only used to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0024] This invention provides the following technical solutions: Please refer to Figure 1-6 An industrial Internet of Things (IoT) data transmission method includes: a protocol adaptation and parsing module, a data standardization processing module, a heterogeneous data fusion module, and a deterministic transmission management module, as detailed below: SA1, Begin; SA2: Protocol adaptation and parsing module, which parses and standardizes data packets of different industrial protocols through a pluggable protocol parsing engine. The pluggable protocol parsing engine includes a protocol feature fingerprint library, a deep packet detection unit, a semantic mapping unit, and a pluggable engine maintenance unit. SA3: Data standardization processing module, which receives the standardization instructions output by the protocol adaptation parsing module, and performs format conversion, semantic enhancement and edge preprocessing on the parsed data based on the five-tuple data model. The structure of the five-tuple data model is: timestamp, device ID, source protocol, data format and service tag. SA4: Heterogeneous data fusion module, including time synchronization unit, spatial association unit and multimodal fusion unit, receives standardized data output by the data standardization processing module, and realizes spatiotemporal integration of cross-device and multi-type data through time synchronization unit, spatial association unit and multimodal fusion unit; SA5: Deterministic transmission management module, including TSN transport layer traffic shaping unit, DDS-based publish and subscribe management unit and Bayesian network dynamic path selection unit, receives integrated data output by the heterogeneous data fusion module, and ensures the determinism and efficiency of data transmission through TSN transport layer traffic shaping unit, DDS-based publish and subscribe management unit and Bayesian network dynamic path selection unit. SA6, End.

[0025] The steps for constructing the protocol feature fingerprint database in the SA2 plug-in protocol parsing engine are as follows: SB1, Begin; SB2. Collect low-level characteristic parameters of more than 30 industrial protocols, including protocol port number, data frame start / end identifier, verification algorithm, and field offset; SB3. The feature parameters are stored in a structured manner, and an index table is established with the protocol name as the key and the feature parameter set as the value; SB4. Design a dynamic update interface that supports adding protocol feature parameters via plugins without modifying the core library structure; SB5, End.

[0026] The processing steps of the deep packet inspection unit in the SA2 pluggable protocol parsing engine are as follows: SC1, Start; SC2. The traffic splitting module performs initial filtering of data packets based on port number; SC3. Parse the data packet layer by layer to extract header identifiers, field lengths, and checksum characteristics; SC4. Compare the extracted features with the index table of the protocol feature fingerprint database. If the matching degree is ≥95%, determine the protocol type; otherwise, trigger an anomaly alarm. SC5, End.

[0027] The processing steps of the semantic mapping unit in the SA2 pluggable protocol parsing engine are as follows: SD1, Start; SD2. For a given protocol, extract its native instruction set; SD3 converts the native instruction set into standardized operations through a preset mapping rule base. The standardized operations include reading, writing, subscribing, and notification. SD4. Generate an intermediate message containing "protocol type + standardized operation + raw command parameters"; SD5, End.

[0028] The processing steps of the plug-in engine maintenance unit in the SA2 plug-in protocol parsing engine are as follows: SE1, Begin; SE2. Define a unified plugin interface, including protocol parsing, feature updating, and exception handling functions. All protocol plugins must implement this interface. SE3: When the engine starts, it scans the specified directory through the plugin manager and automatically loads plugins that conform to the interface specifications. When SE4 or the protocol is updated or added, you only need to develop a new plugin and put it in the specified directory. The plugin manager will detect and load it in real time without restarting the engine. SE5, End.

[0029] The steps for constructing a quintuple data model in SA3 are as follows: SF1, Begin; SF2. Generate a unique identifier for each piece of raw data. The timestamp is accurate to nanoseconds and based on the device's local clock. It will be calibrated by time synchronization later. The device ID uses a unique code of "manufacturer code + device model + serial number". The source protocol records the original protocol of the data. The data format marks the original format. The business label is initially empty. SF3. The data format in the quintuple is converted through a type conversion module. The type conversion module is based on the JSONSchema engine and supports the conversion of numerical formats. 16-bit integers are converted to 32-bit floating-point numbers. The conversion formula is float32=int16×0.001. The data structure is converted from PDO to JSON. The mapping rule is that the index 0x6040 of PDO is mapped to the JSON field 'Position'. Here, PDO is ProcessDataObject, a process data object. SF4. Add business tags to the quintuple through the semantic enhancement module: Load the industrial ontology library containing the association between "device type - data type - business tag", match the corresponding business tag according to the device ID and the converted data format and write it into the business tag field; SF5 employs a three-level filtering mechanism via an edge preprocessing module: the first level removes invalid data based on a threshold set by the business tag; the second level retains only the first and last data for continuously collected data with the same business tag, compressing redundant intermediate data; the third level uses the LZ77 algorithm for lossless compression, ensuring a data reduction of over 80%; the threshold for removing invalid data in the first level can be dynamically updated through the industrial ontology library, with the threshold update frequency matching the equipment data acquisition frequency.

[0030] SF6, End.

[0031] The specific steps of the heterogeneous data fusion module in SA4 are as follows: SG1, Begin; SG2. Through the time synchronization unit, a master clock and a slave clock are deployed in the industrial network. The master clock periodically sends a Sync synchronization message containing a transmission timestamp T1. After receiving the message, the slave clock records the reception timestamp T2. The slave clock sends a Delay_Req delay request message containing a transmission timestamp T3. After receiving the message, the master clock records the reception timestamp T4. The slave clock calculates the offset using the formula "clock offset = (T2-T1+T3-T4) / 2" and calibrates the local clock to ensure that the cross-device time synchronization error is ≤1μs. SG3. Using spatial association units, a device relationship graph is constructed based on GNN. An initial relationship graph is generated with devices as nodes and "physical connection", "control-controlled", and "data interaction" as edges. The GraphSAGE algorithm is used to train the model with node attributes and edge weights as input to learn the causal relationships between devices. Device interaction data is monitored in real time, and the edge weights are dynamically adjusted to update the relationship graph. The device relationship graph includes: device attribute type, model and location, physical wiring and communication links in the connection relationship, and historical interaction data. SG4, the multimodal fusion unit unifies multiple types of data into a digital twin model, including: defining mapping rules, associating multimodal data with the same time slice and related relationships based on the timestamps after time synchronization and the device relationship map, inputting the aligned multimodal data into the digital twin model, and updating the model's dynamic state to achieve real-time mapping between physical devices and virtual models. Specifically, the mapping rules are defined as follows: PLC control data is mapped to "actuator status", sensor monitoring data is mapped to "environmental parameters", and visual image data is mapped to "device appearance status" after CNN feature extraction. SG5, End.

[0032] The specific steps of deterministic transmission management in SA5 are as follows: SH1, Start; The SH2 and TSN transport layer traffic shaping units divide 1ms into N time slots, allocate dedicated time slots for critical data, and allocate shared time slots for non-critical data. Data is marked with priority levels 1 to 8. Critical data is set to level 1 and bound to a dedicated time slot, while non-critical data is set to levels 5 to 8 and shares the remaining time slots. A gating list is configured based on the 802.1Qbv protocol to specify the priority data allowed to be transmitted in each time slot. The gating switch is triggered by a hardware timer to ensure that the delay of critical data is ≤10μs. SH3, DDS-based publish and subscribe management unit: Define data topics by business tags, and associate each topic with a data structure based on the five-tuple model; configure QoS parameters for different topics (critical topics are configured with "reliable transmission + low latency", and non-critical topics are configured with "best-effort transmission + high throughput"); devices act as publishers to publish data to the DDS bus by topic, and subscribers receive data by matching topics and QoS parameters, supporting message routing efficiency of ≥100,000 messages / second when there are 100,000 concurrent devices; SH4, Bayesian Network Dynamic Path Selection Unit: Collects 12 parameters in real time (device type, data priority, network bandwidth, link load, transmission distance, packet loss rate, latency jitter, node processing capacity, protocol compatibility, security level, energy consumption index, and historical transmission success rate); trains a Bayesian network using historical transmission data as samples, learning the probabilistic relationship between each parameter dimension and the "path quality" evaluated by latency and reliability; inputs the current 12 parameters into the trained model, selects the path with the highest "optimal probability" to transmit data, and re-evaluates and adjusts the path every 100ms; SH5, End.

[0033] To further illustrate the technical solution and implementation effects of the present invention, a detailed explanation is given using the "Intelligent Automobile Welding Production Line Industrial Internet of Things Data Transmission System" as an example: Example 1: 1. Implementation scenarios and equipment configuration This embodiment focuses on an intelligent automotive welding production line, which requires real-time data transmission and collaborative control of multiple types of equipment. The equipment and protocols involved are as follows: Temperature sensors: 20 units, using Modbus RTU protocol, to collect temperature data of the welding area, with a sampling frequency of 10Hz; Welding PLC controllers: 5 units, using OPCUA protocol, outputting welding current and voltage control commands, command frequency 50Hz; Robotic arm actuators: 8 units, using the EtherCAT protocol, receiving motion control commands, with a control frequency of 100Hz, which is critical data; Visual inspection cameras: 3 units, using the Profinet protocol, outputting weld seam image data, with an image resolution of 1920×1080 and a frame rate of 20fps; System Deployment: The data transmission device of the present invention is deployed in the production line control cabinet, including a protocol adaptation and parsing module, a data standardization processing module, a heterogeneous data fusion module, and a deterministic transmission management module. The modules are interconnected through industrial Ethernet.

[0034] 2. Implementation process of each module (1) Protocol adaptation and parsing module (corresponding to SA2) Protocol feature fingerprint database construction: Collect 35 industrial protocols according to steps SB1-SB5, including the underlying features of ModbusRTU, OPCUA, EtherCAT, and Profinet involved in this scenario, such as the port number 502 of ModbusRTU, the data frame start identifier 0x01, and the CRC16 check algorithm. Establish an index table of "protocol name - feature set" and reserve expansion space for subsequent newly added protocols through a dynamic update interface; Deep Packet Inspection: Following steps SC1-SC5, the traffic splitting module first filters data packets by port number, then parses the data packets layer by layer to extract features. After comparison with the fingerprint database, the matching degree is ≥98%, successfully identifying the protocol type of each device, and no abnormal alarms are triggered. Semantic mapping: Following steps SD1-SD5, extract the native instructions of each protocol, convert them into standardized operations through a preset mapping rule base, "Write - Robotic arm position - Target coordinates X=100mm, Y=200mm", and generate intermediate messages; Plug-in engine maintenance: Following the SE1-SD5 steps, define a unified plug-in interface, including ParseProtocol(), UpdateFeature(), and HandleError() functions. When the engine starts, it automatically loads the protocol plug-ins for the four types of devices. When adding a laser rangefinder that uses the ProfinetIRT protocol later, only the corresponding plug-in needs to be developed and placed in the specified directory. The plug-in manager will complete the loading within 10 seconds without restarting the engine.

[0035] (2) Data standardization processing module (corresponding to SA3) Five-tuple data model construction: Following steps SF1-SF6, generate five-tuples for each data stream. For example, the five-tuples for robotic arm data are: Timestamp: 2024-05-2014:30:00.123456789, nanosecond level, based on the robotic arm's local clock; Device ID: KUKA-KR16-202405001, Manufacturer code KUKA + Model KR16 + Serial number 202405001; Source protocol: EtherCAT; Data format: EtherCATPDO; Business tags: Initially empty; Type conversion: The 16-bit integer position data of the robotic arm is converted to a 32-bit floating-point number by using the JSONSchema engine, which is float32=100000×0.001=100.0. The PDO index 0x6040 is mapped to the JSON field "Position". The data format is unified to JSON after conversion. Semantic enhancement: Load the industrial ontology library, which contains the association between "robotic arm - position data - welding positioning", and match the business tag "welding robotic arm positioning data" and write it according to the device ID "KUKA-KR16-202405001" and the converted data format "JSON - position". Edge preprocessing: Level 1: Based on the business tag "welding robot arm positioning data", the threshold is retrieved from the industrial body library. Positioning error > 5mm is invalid data, and 3 invalid data are removed. Level 2: For location data with 10 consecutive identical business tags, only the first and last data entries are retained, and 8 redundant data entries are compressed; Level 3: After compression using the LZ77 algorithm, the data size was reduced from the original 1.2MB to 0.2MB, achieving a compression rate of 83.3%, which meets the transmission requirements.

[0036] (3) Heterogeneous data fusion module (corresponding to SA3) Time synchronization: Following steps SG1-SG2, deploy one master clock and 26 slave clocks built into each device on the production line. The master clock sends a Sync message containing T1 every 10ms. After receiving the message, the slave clock records T2 and then sends a Delay_Req message containing T3. The master clock records T4. Spatial Association: Following the SG3 steps, a device relationship graph is constructed based on GNN: 20 sensors, 5 PLCs, 8 robotic arms, and 3 cameras are used as nodes, with attributes including "temperature sensor - model PT100 - welding station 1". Edges are the data interaction "sensor → PLC", the control-controlled "PLC → robotic arm", and the data interaction "camera → PLC". The GraphSAGE algorithm is used to train the model. When the welding current of robotic arm 1 is abnormal, the model identifies the causal relationship between it and PLC1 and sensor 5 through historical interaction data, dynamically adjusts the edge weight from 0.6 to 0.9, and updates the relationship graph. Multimodal fusion: Following the SG4 steps, define the mapping rules: PLC welding current data → "Actuator welding power status", sensor temperature data → "Welding environment temperature parameters", and camera weld seam images with features extracted by CNN → "Weld seam appearance status". Based on the timestamps after time synchronization and the equipment relationship map, associate the "power status + temperature parameters + appearance status" data of the same time slice, input them into the digital twin model of the welding production line, and the model updates the robotic arm motion trajectory and welding temperature field distribution in real time to achieve a 1:1 mapping between physical equipment and virtual model.

[0037] (4) Deterministic transmission management module (corresponding to SA4) TSN flow shaping: Following the SH2 procedure, 1ms is divided into 10 time slots, each 100μs. Critical data robotic arm control commands are assigned priority level 1 and bound to time slots 1-3. Non-critical temperature data is assigned priority level 6 and shares time slots 4-10. A gating list is configured based on the 802.1Qbv protocol, specifying that only level 1 data transmission is allowed in time slots 1-3. The gating switch is triggered by a hardware timer. Actual measurements show that the robotic arm control command delay is stable at 8μs, meeting the ≤10μs requirement. DDS Publish and Subscribe: Following the SH3 steps, four topics are defined by business tags: "Welding Robotic Arm Control" (critical), "Welding Ambient Temperature" (non-critical), "Weld Appearance Inspection" (non-critical), and "PLC Operating Status" (critical). QoS parameters "Reliable Transmission + Low Latency" are configured for "Welding Robotic Arm Control," and "Best Effort Transmission + High Throughput" is configured for "Welding Ambient Temperature." Devices, acting as publishers, send data to the DDS bus, and subscribers receive data by matching topics and QoS parameters. In a concurrent test with 100,000 devices, message routing efficiency reached 120,000 messages / second with no packet loss. Bayesian path selection: Following the SH4 steps, collect 12-dimensional parameters in real time; train the Bayesian network using transmission data from the past 30 days, and the model learns that when "link load < 40% + packet loss rate < 0.05%", the probability of a good or bad path is ≥ 95%; input the current parameters every 100ms, and when the load of link 2 increases from 30% to 45%, the model switches the optimal path from link 2 to link 1 to ensure that the data transmission success rate remains at 99.995%.

[0038] 3. Implementation effect verification This embodiment achieves efficient data transmission in the intelligent automotive welding production line through the collaborative work of the above modules. The key performance indicators are verified as follows: Protocol parsing success rate: 99.8%, with only 2 Profinet data packets triggering anomaly alarms due to link interference and a matching degree of 92%. Data compression rate: 83.3%, original data 1.2MB / s, compressed data 0.2MB / s; Cross-device time synchronization error: ≤0.8μs, meeting industrial-grade time accuracy requirements; Key data transmission latency: 8μs; Device concurrent routing efficiency: 120,000 routes / second; Data transmission success rate: 99.995%; Through this invention, the welding defect rate of the production line has been reduced from 2.5% to 0.8%, and the equipment failure response time has been shortened from 20 seconds to 1 second, fully demonstrating the practicality and advanced nature of this invention in industrial scenarios.

[0039] Example 2: Implementation Scenarios and Equipment Configuration: For a 110kV smart grid, this project aims to achieve data acquisition, fusion, and transmission from multiple devices in a substation. The equipment includes: Current transformers: 30 units, IEC61850-9-2, 50Hz sampling; Relay protection devices: 10 units, IEC60870-5-104, 20Hz directive, key data; Environmental sensors: 15 units, LoRaWAN, 1Hz sampling; Video cameras: 8 units, ONVIF, 15fps image output; The system is deployed in the main control room of the substation, and the modules are interconnected via fiber optic Ethernet, covering three substation zones.

[0040] Implementation process of each module: (1) Protocol adaptation and parsing module: Collect relevant protocol features, including IEC61850 and DL / T645, with a deep packet inspection matching degree of ≥99%, and semantic mapping converts "trip command" into a standardized "write" operation; Add a DL / T645 meter plugin, which loads in 5 seconds; (2) Data standardization processing module: Generates a quintuple, timestamp "2024-06-10 09:15:30.123456789", device ID "ABB-RS600-202406001", converts 16-bit current data to 32-bit floating-point numbers, matches the "power grid relay protection trip data" label, and reduces the data volume by 84% after three-level filtering; (3) Heterogeneous data fusion module: GPS master clock synchronization error ≤0.5μs, GNN constructs the relationship map of "current transformer-relay protection device", multi-modal data is mapped to the digital twin model of the power grid, and the line current distribution is updated in real time; (4) Deterministic transmission management module: TSN critical data delay 7μs, DDS routing efficiency 115,000 links / second, Bayesian path selection switches to backup links when the link load is 50%, with a success rate of 99.998%.

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

[0042] It should be noted that, unless otherwise specified, the embodiments and features and technical solutions in the present invention can be combined with each other.

[0043] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0044] The above embodiments are only used to illustrate the present invention and are not intended to limit the technical solutions described herein. Although the present invention has been described in detail with reference to the above embodiments, the present invention is not limited to the specific embodiments described above. Therefore, any modifications or equivalent substitutions to the present invention, as well as all technical solutions and improvements that do not depart from the spirit and scope of the invention, are covered within the scope of the claims of the present invention.

Claims

1. An industrial Internet of Things (IoT) data transmission method, characterized in that, include: The protocol adaptation and parsing module, data standardization processing module, heterogeneous data fusion module, and deterministic transmission management module are as follows: SA1, Begin; SA2: Protocol adaptation and parsing module, which parses and standardizes data packets of different industrial protocols through a pluggable protocol parsing engine. The pluggable protocol parsing engine includes a protocol feature fingerprint library, a deep packet detection unit, a semantic mapping unit, and a pluggable engine maintenance unit. SA3: Data standardization processing module, which receives the standardization instructions output by the protocol adaptation parsing module, and performs format conversion, semantic enhancement and edge preprocessing on the parsed data based on the five-tuple data model. The structure of the five-tuple data model is: timestamp, device ID, source protocol, data format and service tag. SA4: Heterogeneous data fusion module, including time synchronization unit, spatial association unit and multimodal fusion unit, receives standardized data output by the data standardization processing module, and realizes spatiotemporal integration of cross-device and multi-type data through time synchronization unit, spatial association unit and multimodal fusion unit; SA5: Deterministic transmission management module, including TSN transport layer traffic shaping unit, DDS-based publish and subscribe management unit and Bayesian network dynamic path selection unit, receives integrated data output by the heterogeneous data fusion module, and ensures the determinism and efficiency of data transmission through TSN transport layer traffic shaping unit, DDS-based publish and subscribe management unit and Bayesian network dynamic path selection unit. SA6, End.

2. The industrial Internet of Things (IoT) data transmission method according to claim 1, characterized in that, The steps for constructing the protocol feature fingerprint database in the SA2 plug-in protocol parsing engine are as follows: SB1, Begin; SB2. Collect low-level characteristic parameters of more than 30 industrial protocols, including protocol port number, data frame start / end identifier, verification algorithm, and field offset; SB3. The feature parameters are stored in a structured manner, and an index table is established with the protocol name as the key and the feature parameter set as the value; SB4. Design a dynamic update interface that supports adding protocol feature parameters via plugins without modifying the core library structure; SB5, End.

3. The industrial Internet of Things (IoT) data transmission method according to claim 1, characterized in that, The processing steps of the deep packet inspection unit in the SA2 pluggable protocol parsing engine are as follows: SC1, Start; SC2. The traffic splitting module performs initial filtering of data packets based on port number; SC3. Parse the data packet layer by layer to extract header identifiers, field lengths, and checksum characteristics; SC4. Compare the extracted features with the index table of the protocol feature fingerprint database. If the matching degree is ≥95%, determine the protocol type; otherwise, trigger an anomaly alarm. SC5, End.

4. The industrial Internet of Things (IoT) data transmission method according to claim 1, characterized in that, The processing steps of the semantic mapping unit in the SA2 pluggable protocol parsing engine are as follows: SD1, Start; SD2. For a given protocol, extract its native instruction set; SD3 converts the native instruction set into standardized operations through a preset mapping rule base. The standardized operations include reading, writing, subscribing, and notification. SD4. Generate an intermediate message containing "protocol type + standardized operation + raw command parameters"; SD5, End.

5. The industrial Internet of Things (IoT) data transmission method according to claim 1, characterized in that, The processing steps of the plug-in engine maintenance unit in the SA2 plug-in protocol parsing engine are as follows: SE1, Begin; SE2. Define a unified plugin interface, including protocol parsing, feature updating, and exception handling functions. All protocol plugins must implement this interface. SE3: When the engine starts, it scans the specified directory through the plugin manager and automatically loads plugins that conform to the interface specifications. When SE4 or the protocol is updated or added, you only need to develop a new plugin and put it in the specified directory. The plugin manager will detect and load it in real time without restarting the engine. SE5, End.

6. The industrial Internet of Things (IoT) data transmission method according to claim 1, characterized in that, The steps for constructing a quintuple data model in SA3 are as follows: SF1, Begin; SF2. Generate a unique identifier for each piece of raw data. The timestamp is accurate to nanoseconds and is based on the device's local clock. It will be calibrated through time synchronization later. The device ID uses a unique code of "manufacturer code + device model + serial number". The source protocol records the original protocol of the data. The data format marks the original format. The business label is initially empty. SF3. The data format in the quintuple is converted through a type conversion module. The type conversion module is based on the JSONSchema engine and supports the conversion of numerical formats. 16-bit integers are converted to 32-bit floating-point numbers. The conversion formula is float32 = int16 × 0.

001. The data structure is converted from PDO to JSON. The mapping rule is that the index 0x6040 of PDO is mapped to the JSON field 'Position'. Here, PDO is ProcessDataObject, a process data object. SF4. Add business tags to the quintuple through the semantic enhancement module: Load the industrial ontology library containing the association between "device type - data type - business tag", match the corresponding business tag according to the device ID and the converted data format and write it into the business tag field; SF5 employs a three-level filtering process via an edge preprocessing module: the first level removes invalid data based on a threshold set by the business tag; the second level retains only the first and last data for continuously collected data with the same business tag, compressing redundant intermediate data; the third level uses the LZ77 algorithm for lossless compression, ensuring a data reduction of over 80%; the threshold for removing invalid data in the first level can be dynamically updated through the industrial ontology library, with the threshold update frequency matching the equipment data acquisition frequency. SF6, End.

7. The industrial Internet of Things (IoT) data transmission method according to claim 1, characterized in that, The specific steps of the heterogeneous data fusion module in SA4 are as follows: SG1, Begin; SG2. Through the time synchronization unit, a master clock and a slave clock are deployed in the industrial network. The master clock periodically sends a Sync synchronization message containing a transmission timestamp T1. After receiving the message, the slave clock records the reception timestamp T2. The slave clock sends a Delay_Req delay request message containing a transmission timestamp T3. After receiving the message, the master clock records the reception timestamp T4. The slave clock calculates the offset using the formula "clock offset = (T2-T1+T3-T4) / 2" and calibrates the local clock to ensure that the cross-device time synchronization error is ≤1μs. SG3. Using spatial association units, a device relationship graph is constructed based on GNN. An initial relationship graph is generated with devices as nodes and "physical connection", "control-controlled", and "data interaction" as edges. The GraphSAGE algorithm is used to train the model with node attributes and edge weights as input to learn the causal relationships between devices. Device interaction data is monitored in real time, and the edge weights are dynamically adjusted to update the relationship graph. The device relationship graph includes: device attribute type, model and location, physical wiring and communication links in the connection relationship, and historical interaction data. SG4, the multimodal fusion unit unifies multiple types of data into a digital twin model, including: defining mapping rules, associating multimodal data with the same time slice and related relationships based on the timestamps after time synchronization and the device relationship map, inputting the aligned multimodal data into the digital twin model, and updating the model's dynamic state to achieve real-time mapping between physical devices and virtual models. Specifically, the mapping rules are defined as follows: PLC control data is mapped to "actuator status", sensor monitoring data is mapped to "environmental parameters", and visual image data is mapped to "device appearance status" after CNN feature extraction. SG5, End.

8. The industrial Internet of Things (IoT) data transmission method according to claim 1, characterized in that, The specific steps of deterministic transmission management in SA5 are as follows: SH1, Start; The SH2 and TSN transport layer traffic shaping units divide 1ms into N time slots, allocate dedicated time slots for critical data, and allocate shared time slots for non-critical data. They mark data with priority levels 1 to 8, setting critical data to level 1 and binding it to a dedicated time slot, while setting non-critical data to levels 5 to 8 and sharing the remaining time slots. Based on the 802.1Qbv protocol, they configure a gating list to specify the priority data allowed to be transmitted in each time slot. The gating switch is triggered by a hardware timer to ensure that the delay of critical data is ≤10μs. SH3, DDS-based publish and subscribe management unit: Define data topics by business tags, and associate each topic with a data structure based on the five-tuple model; configure QoS parameters for different topics (critical topics are configured with "reliable transmission + low latency", and non-critical topics are configured with "best-effort transmission + high throughput"); devices act as publishers to publish data to the DDS bus by topic, and subscribers receive data by matching topics and QoS parameters, supporting message routing efficiency of ≥100,000 messages / second when there are 100,000 concurrent devices; SH4, Bayesian Network Dynamic Path Selection Unit: Collects 12 dimensions of parameters in real time (device type, data priority, network bandwidth, link load, transmission distance, packet loss rate, latency jitter, node processing capacity, protocol compatibility, security level, energy consumption index, and historical transmission success rate); trains the Bayesian network using historical transmission data as samples, learning the probabilistic relationship between each dimension of parameters and the "path quality" evaluated by latency and reliability; inputs the current 12 dimensions of parameters into the trained model, selects the path with the highest "optimal probability" to transmit data, and re-evaluates and adjusts the path every 100ms; SH5, End.

Images