Industrial internet of things heterogeneous protocol adaptive conversion method, system, device and medium

Abstract

The application discloses an industrial Internet of Things heterogeneous protocol adaptive conversion method, system, device and medium, relates to the technical field of data transmission processing, and comprises the following steps: acquiring a communication network comprising a host computer and terminal equipment, acquiring a communication protocol, acquiring a data header flag and a check bit, and generating a characteristic identifier; inserting the characteristic identifier, reading the characteristic identifier and converting to the communication protocol; if the communication protocol is successfully converted, matching and identifying a data stream according to the converted communication protocol, acquiring a reading time sequence, reducing a first length and generating a second length, acquiring a check bit of the second length, generating a new characteristic identifier, and marking the new characteristic identifier; if the communication protocol cannot be converted, increasing the first length and generating a third length, acquiring a check bit of the third length, generating a new characteristic identifier, and marking the new characteristic identifier. The application has the advantages of high conversion efficiency, good conversion accuracy and adaptive optimization.

Description

Technical Field

[0001] This invention relates to the field of data transmission processing technology, specifically to an adaptive conversion method, system, device, and medium for heterogeneous protocols in the industrial Internet of Things. Background Technology

[0002] In industrial IoT applications, the host computer needs to communicate with various terminal devices (such as sensors, actuators, PLC controllers, etc.). These devices usually come from different manufacturers and use different communication protocols, including Modbus, CAN bus, OPC UA, etc., forming a complex heterogeneous protocol environment. In such an environment, the host computer needs to continuously match the communication protocol of the current data stream in order to effectively identify the data stream and complete subsequent operations. However, the current conversion methods have many shortcomings.

[0003] First, existing methods require real-time parsing of protocol features for each transmitted data stream, which means that each conversion requires re-analyzing part or the entire data stream (e.g., parsing address code + function code + data field for Modbus messages). The average time consumption is too long, which cannot meet the requirements of high real-time control scenarios. At the same time, the host computer needs to continuously run the protocol analysis algorithm, resulting in serious resource consumption.

[0004] Secondly, existing methods lack an adaptive adjustment mechanism. Especially when device communication is relatively stable (e.g., the reading time sequence does not fluctuate significantly), the protocol conversion strategy cannot be dynamically adjusted to save computing resources, resulting in additional waste. More importantly, this makes it impossible to dynamically optimize the parity bit length to balance conversion efficiency and accuracy, and it also lacks self-healing logic after conversion failure. Summary of the Invention

[0005] To address the shortcomings of existing technologies, such as the lack of real-time communication quality perception, the absence of lightweight protocol index optimization mechanisms, and the lack of fault self-healing logic, which to some extent prevent the balance between efficiency, accuracy, and scalability, this invention provides an industrial Internet of Things (IoT) heterogeneous protocol adaptive conversion method, system, device, and medium.

[0006] An adaptive conversion method for heterogeneous protocols in the Industrial Internet of Things (IIoT) includes: acquiring a communication network including a host computer and multiple terminal devices based on the IIoT; acquiring the communication protocol of each terminal device when it first enters the communication network; acquiring the corresponding data header flag and a first-length checksum according to the communication protocol of each terminal device; generating a feature identifier for each terminal device based on the data header flag and the first-length checksum; inserting the feature identifier of the i-th terminal device into the front end of the data stream to be sent by the i-th terminal device; reading the feature identifier of the i-th terminal device in the data stream through the host computer and converting it to the corresponding communication protocol according to a protocol library; if the host computer successfully converts to the communication protocol of the i-th terminal device, matching and identifying the data stream according to the converted communication protocol, and acquiring the host computer's target for the i-th terminal device within a preset time period. The feature identifier reading time sequence is used to reduce the first length and generate a second length based on the feature identifier reading time sequence of the i-th terminal device. The check bit of the second length is obtained according to the communication protocol of the i-th terminal device. A new feature identifier of the i-th terminal device is generated based on the data header flag and the check bit of the second length. The new feature identifier is marked on the data to be sent of the i-th terminal device, and the protocol adaptive conversion continues in this way. If the host computer cannot convert to the communication protocol of the i-th terminal device, the first length is increased and a third length is generated. The check bit of the third length is obtained according to the communication protocol of the i-th terminal device. A new feature identifier of the i-th terminal device is generated based on the data header flag and the check bit of the third length. The new feature identifier is marked on the data to be sent of the i-th terminal device, and the protocol adaptive conversion continues in this way.

[0007] Optionally, reducing the first length and generating the second length based on the reading time sequence of the feature identifier of the i-th terminal device includes: obtaining the stability index of the i-th terminal device based on the reading time sequence of the feature identifier of the i-th terminal device; if the stability index of the i-th terminal device is less than a preset threshold, then reducing the first length and generating the second length.

[0008] Optionally, obtaining the stability index of the i-th terminal device based on the reading time sequence of the feature identifier of the i-th terminal device includes: obtaining the difference between adjacent reading time data in the reading time sequence of the feature identifier of the i-th terminal device; and obtaining the stability index based on the average of all differences in the reading time sequence of the feature identifier of the i-th terminal device.

[0009] Optionally, reducing the first length and generating the second length includes: obtaining the standard byte length; and subtracting the standard byte length from the first length to obtain the second length.

[0010] Optionally, increasing the first length and generating the third length includes: obtaining the standard byte length; and increasing the first length by the standard byte length to obtain the third length.

[0011] Optionally, obtaining the corresponding header flag and the first length of check bits according to the communication protocol of each terminal device includes: extracting consecutive bytes starting at a fixed position in the communication protocol of each terminal device as header flags; and selecting consecutive fields of length first length from the integrity check fields defined in the communication protocol specification of each terminal device as check bits of length first length.

[0012] Optionally, generating the feature identifier of each terminal device based on the data header flag and the first length of the check bit includes: directly concatenating the data header flag corresponding to each terminal device with the first length of the check bit to form the feature identifier of each terminal device.

[0013] An industrial IoT heterogeneous protocol adaptive conversion system is also provided. The system includes a management platform, a sensor network platform, and an object platform connected sequentially. The management platform includes: a protocol and identifier acquisition module, used to acquire a communication network including a host computer and multiple terminal devices based on the industrial IoT, and acquire the communication protocol of each terminal device when each terminal device first enters the communication network, and acquire the corresponding data header flag and a first-length checksum according to the communication protocol of each terminal device, and generate a feature identifier for each terminal device based on the data header flag and the first-length checksum; an identifier insertion and reading conversion module, used to insert the feature identifier of the i-th terminal device into the front end of the data stream to be sent by the i-th terminal device, and read the feature identifier of the i-th terminal device in the data stream through the host computer and convert it to the corresponding communication protocol according to the protocol library; and a first conversion processing module, used to process the converted communication protocol when the host computer successfully converts to the communication protocol of the i-th terminal device. The data stream is matched and identified, and the reading time sequence of the feature identifier of the i-th terminal device by the host computer within a preset time period is obtained. The first length is reduced and a second length is generated according to the reading time sequence of the feature identifier of the i-th terminal device. The check bit of the second length is obtained according to the communication protocol of the i-th terminal device. A new feature identifier of the i-th terminal device is generated according to the data header flag and the check bit of the second length. The new feature identifier is marked on the data to be sent by the i-th terminal device, and the protocol adaptive conversion continues in this way. The second conversion processing module is used to increase the first length and generate a third length when the host computer cannot convert to the communication protocol of the i-th terminal device. The check bit of the third length is obtained according to the communication protocol of the i-th terminal device. A new feature identifier of the i-th terminal device is generated according to the data header flag and the check bit of the third length. The new feature identifier is marked on the data to be sent by the i-th terminal device, and the protocol adaptive conversion continues in this way.

[0014] An electronic device is also provided, comprising: a memory storing a computer program thereon; and a processor for executing the computer program in the memory to implement the above-described industrial Internet of Things heterogeneous protocol adaptive conversion method.

[0015] A non-transitory computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the above-described industrial Internet of Things heterogeneous protocol adaptive conversion method.

[0016] The beneficial effects of this invention are reflected in:

[0017] In the entire industrial IoT heterogeneous protocol adaptive conversion method, a device feature identifier (data header + check bit) is constructed. This allows the host computer to avoid real-time parsing of the main data stream and only needs to match the identifier header, thus compressing the protocol identification time and meeting the high real-time control requirements while reducing the host computer's computing power consumption. Furthermore, the check bit length is dynamically adjusted based on the stability of the reading time sequence. When the communication latency fluctuation is below the threshold, the check bit is gradually shortened, reducing the identifier length and further accelerating protocol matching. If the protocol conversion fails, the check bit is intelligently extended to improve noise tolerance and ensure accurate identification of critical commands. Furthermore, a negative feedback loop from monitoring, analysis, adjustment to verification is established. The check bit adjustment takes effect immediately and continuously tracks the new time sequence. If stable, it is further compressed; if fluctuating, it is maintained or expanded, forming a dynamic balance between efficiency and reliability. At the same time, it is seamlessly compatible with protocol expansion. New devices only need to generate a feature identifier when they first connect, without changing the core optimization logic, and it supports concurrent communication of cluster devices. Attached Figure Description

[0018] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0019] Figure 1 This is a partial flowchart of the industrial IoT heterogeneous protocol adaptive conversion method of the present invention;

[0020] Figure 2 This is another schematic diagram of the process of the industrial IoT heterogeneous protocol adaptive conversion method of the present invention;

[0021] Figure 3 This is a schematic diagram illustrating the steps of the industrial IoT heterogeneous protocol adaptive conversion method of the present invention;

[0022] Figure 4 This is a schematic diagram of some steps in S3 of the industrial IoT heterogeneous protocol adaptive conversion method of the present invention;

[0023] Figure 5 This is a schematic diagram of some steps in S31 of the industrial IoT heterogeneous protocol adaptive conversion method of the present invention;

[0024] Figure 6 This is a schematic diagram of some steps in S32 of the industrial IoT heterogeneous protocol adaptive conversion method of the present invention;

[0025] Figure 7 This is a schematic diagram of some steps in S4 of the industrial IoT heterogeneous protocol adaptive conversion method of the present invention;

[0026] Figure 8 This is a schematic diagram of some steps in S1 of the industrial IoT heterogeneous protocol adaptive conversion method of the present invention;

[0027] Figure 9 This is a schematic diagram of the composition of the industrial IoT heterogeneous protocol adaptive conversion system of the present invention;

[0028] Figure 10 This is a schematic diagram illustrating the composition of the optimized Industrial Internet of Things (IIoT) involved in this invention.

[0029] Figure 11 This is a block diagram illustrating an electronic device according to an embodiment of the present invention.

[0030] Figure label:

[0031] 700 - Electronic device; 701 - Processor; 702 - Memory; 703 - Multimedia component; 704 - I / O interface; 705 - Communication component. Detailed Implementation

[0032] 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. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0033] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0034] It should be noted that similar reference numerals 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. Furthermore, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0035] like Figure 1 , Figure 2 and Figure 3 As shown, an adaptive conversion method for heterogeneous protocols in the Industrial Internet of Things (IIoT) is provided. In one embodiment, the method includes:

[0036] S1. Based on the Industrial Internet of Things, acquire the communication network including the host computer and multiple terminal devices, and acquire the communication protocol of each terminal device when each terminal device enters the communication network for the first time. Acquire the corresponding data header flag and the first length check bit according to the communication protocol of each terminal device, and generate the feature identifier of each terminal device according to the data header flag and the first length check bit.

[0037] S2. Insert the feature identifier of the i-th terminal device into the front end of the data stream to be sent by the i-th terminal device, and read the feature identifier of the i-th terminal device in the data stream through the host computer and convert it to the corresponding communication protocol according to the protocol library;

[0038] S3. If the host computer successfully converts to the communication protocol of the i-th terminal device, it matches and identifies the data stream according to the converted communication protocol, and obtains the reading time sequence of the feature identifier of the i-th terminal device within a preset time period. Based on the reading time sequence of the feature identifier of the i-th terminal device, it reduces the first length and generates the second length. Based on the communication protocol of the i-th terminal device, it obtains the check bit of the second length, and generates a new feature identifier of the i-th terminal device based on the data header flag and the check bit of the second length. The new feature identifier is marked on the data to be sent by the i-th terminal device, and the protocol adaptive conversion continues in this way.

[0039] S4. If the host computer cannot switch to the communication protocol of the i-th terminal device, the first length is increased and a third length is generated. The check bit of the third length is obtained according to the communication protocol of the i-th terminal device. A new feature identifier of the i-th terminal device is generated according to the data header flag and the check bit of the third length. The new feature identifier is marked on the data to be sent of the i-th terminal device, and the protocol adaptive conversion is continued in this way.

[0040] In this embodiment, it should be noted that in S1, when the industrial IoT communication network is initially established, when any terminal device (such as a temperature sensor or PLC controller) first connects to the network, the host computer acquires the communication protocols of each terminal device. Specifically, this can be achieved by actively sending a probe frame of a specific format (e.g., a Modbus "Device Identification Request" or an OPC UA "GetEndpoints" command) to the device, triggering the device to return response data. After capturing this response, the host computer parses its original communication protocol specifications: First, it extracts the data header flag at the fixed start position of the protocol (e.g., the "slave address + function code" byte of the Modbus RTU protocol, or the 11 / 29-bit identifier of the CAN bus frame); simultaneously, it extracts a fixed-length check bit from the integrity check field defined by the protocol (e.g., the first byte of the Modbus CRC16 checksum, or the fixed signature field of the OPC UA message security header). The data header flag and the check bit are directly concatenated to generate the unique identifier of the device (e.g., "0x01+0x03+0xA1" represents a Modbus read register command at address 1). This feature serves as the device's protocol identity verification in subsequent communications, avoiding the need to repeatedly parse the complete data stream.

[0041] Furthermore, the construction of feature identifiers essentially transforms complex protocol identification into lightweight identifier matching by pre-extracting key static features (data header) and dynamic verification information (checksum). For example, the host computer only needs to compare the feature identifiers at the front end of the received data stream (such as detecting "0x01+0x03+0xA1" matching the Modbus read operation header) to directly index the corresponding parsing rules in the protocol library (Modbus RTU specification), without needing to scan the entire message in real time (such as skipping data field analysis). Simultaneously, the initial checksum length (first length) is set according to the protocol specification (such as 4 bytes by default for Modbus CRC16), providing a baseline for subsequent adaptive optimization (reducing or increasing the length). This mechanism not only avoids the deep parsing overhead of traditional methods for each data transmission but also achieves "zero-latency" matching of protocol types through pre-defined identifiers, providing a foundation for high real-time control scenarios.

[0042] In S2, when a terminal device needs to send a data stream (such as a sensor uploading a temperature value or a PLC controller issuing an execution command), a pre-generated feature identifier is embedded at the front end of the original data stream. For example, when a Modbus temperature sensor (identified as "0x01+0x03+0xA1") sends data, the actual data stream structure becomes "feature identifier + original data field" (i.e., "0x01, 0x03, 0xA1, temperature value byte"). After receiving the data stream, the host computer only needs to extract the feature identifier byte at the front end (skipping the parsing of the original data field) and accurately index the corresponding communication protocol in the protocol library using lightweight algorithms such as matching or binary tree retrieval (e.g., matching the identifier "0x01+0x03+0xA1" triggers the Modbus RTU parsing rule). This process completely avoids the real-time parsing of the main body of the data stream (such as the data field of a Modbus message or the payload of a CAN bus) as in traditional methods, achieving rapid location before protocol conversion.

[0043] Furthermore, the embedding of feature identifiers lays the physical foundation for subsequent protocol self-optimization: after the host computer successfully matches the identifier (e.g., successfully identifying the Modbus protocol), it immediately calls the corresponding protocol parser to process the main body of the data stream (e.g., unpacking the temperature value), while automatically recording the time taken to read the identifier (the time from receiving the first byte to completing the matching). These time sequences will be used in S3 to evaluate communication stability (e.g., minimal fluctuation in time taken for 10 consecutive reads), thereby triggering dynamic adjustment of the check bit length (shortening the check bit in S3 to optimize speed, or lengthening the check bit in S4 to enhance fault tolerance). For example, when the initial check bit of the temperature sensor's feature identifier occupies 4 bytes, after detecting stable communication, the check bit will be shortened to 3 bytes in the next transmission (the new identifier becomes "0x01+0x03+0xB"). The host computer only needs to parse the shorter identifier to complete the protocol switch, significantly improving real-time performance.

[0044] In S3, after the host computer successfully matches the protocol and completes data parsing (such as reading sensor temperature values) through the feature identifier (e.g., "0x01+0x03+0xA1" for Modbus devices), it continuously monitors the reading time sequence of the feature identifier (e.g., recording the time taken from receiving the data stream to completing protocol identification for 10 consecutive times). Based on this sequence, a communication stability index is calculated: first, the absolute difference between adjacent reading times is obtained (e.g., the time interval between the 2nd and 1st readings), and then the average fluctuation of all differences is calculated. If this index is less than a preset threshold (indicating stable communication latency and minimal fluctuation), parity bit length compression is triggered—for example, shortening the initial parity bit from 4 bytes to 3 bytes, generating a second-length parity bit, and reconstructing the feature identifier (e.g., the new identifier becomes "0x01+0x03+0xB").

[0045] Furthermore, after the new feature identifier takes effect, the terminal device only needs to carry a shorter identifier when sending data next time (e.g., the original identifier occupies 4 bytes, while the new identifier only requires 3 bytes). The host computer can significantly reduce the amount of bytes processed during parsing (by shortening the feature identifier length), thereby reducing the protocol matching time (e.g., from 0.5ms to 0.3ms). At the same time, a closed-loop optimization is formed: after the check bit is shortened, the new reading time sequence (the change in the matching delay of the new identifier) ​​continues to be monitored. If the stability continues to meet the standard, the length is further compressed until the minimum check bit length allowed by the protocol is reached (e.g., the minimum of 1 byte for Modbus CRC16). This mechanism, while ensuring the accuracy of protocol conversion (the data header flag remains unchanged), enables resources to be concentrated on processing core business data (such as actuator control instructions) by dynamically trimming redundant check information, essentially achieving fine-grained scheduling of computing power in stable scenarios.

[0046] In S4, when the host computer cannot match the protocol using the current feature identifier (e.g., due to network jitter causing a checksum error), it immediately triggers fault-tolerant self-healing logic: First, it increases the original checksum length (first length) by one standard byte to generate a third length (e.g., extending the original checksum length from 1 byte to 2 bytes). Based on this new length, it re-extracts a longer checksum from the protocol definition field (e.g., Modbus devices change from taking 1 byte from the original CRC16 field to taking 2 bytes), and reconstructs the feature identifier by combining it with the unchanged header flag (e.g., the CAN bus device identifier is extended from "0x18F+0x5" to "0x18F+0x5C3"). The new identifier takes effect immediately in the next communication cycle—the terminal device actively embeds the extended identifier when sending data, and the host computer improves its ability to shield against interference through the longer checksum.

[0047] Furthermore, the extended checksum essentially enhances the fault tolerance and redundancy of protocol identification: for example, in factory environments with severe electromagnetic interference, the new identifier for OPC UA devices, by increasing the length of the security header signature field (e.g., from 2 bytes to 3 bytes), makes it easier for the host computer to identify data streams contaminated by noise. This process simultaneously forms a bistable optimization closed loop: after fault repair, the reading time sequence continues to be monitored; if communication stabilizes, the process switches to S3 to shorten the checksum; if it remains unstable, the extension strategy is maintained or further extended (e.g., to 4 bytes). This mechanism dynamically optimizes between efficiency and reliability—sacrificing a small amount of parsing speed for robust communication, especially ensuring the accurate transmission of critical control commands (such as emergency stop signals), fundamentally solving the deficiency of existing methods requiring manual intervention after a failure.

[0048] In summary, the entire industrial IoT heterogeneous protocol adaptive conversion method constructs a device feature identifier (data header + checksum), enabling the host computer to perform lightweight matching of the identifier header without real-time parsing of the main data stream, thus compressing the protocol identification time and meeting high real-time control requirements while reducing the host computer's computing power consumption. Furthermore, the checksum length is dynamically adjusted based on the stability of the reading time sequence. When communication latency fluctuations are below a threshold, the checksum is gradually shortened, reducing the identifier length and further accelerating protocol matching. If the protocol conversion fails, the checksum is intelligently extended to improve noise tolerance and ensure accurate identification of critical commands. Furthermore, a negative feedback loop from monitoring, analysis, adjustment to verification is established. The checksum adjustment takes effect immediately and continuously tracks the new time sequence. If stable, it is further compressed; if fluctuating, it is maintained or expanded, forming a dynamic balance between efficiency and reliability. At the same time, it is seamlessly compatible with protocol expansion. New devices only need to generate a feature identifier upon initial access without changing the core optimization logic, supporting concurrent communication of cluster devices.

[0049] like Figure 2 and Figure 4 As shown, in one embodiment, step S3, reducing the first length and generating the second length based on the reading time sequence of the feature identifier of the i-th terminal device, includes:

[0050] S31. Obtain the stability index of the i-th terminal device based on the reading time sequence of the feature identifier of the i-th terminal device;

[0051] S32. If the stability index of the i-th terminal device is less than the preset threshold, then reduce the first length and generate the second length.

[0052] In this embodiment, it should be noted that in S31, the stability of device communication is quantified by analyzing the reading time sequence of the feature identifier. Specifically, the reading time of the feature identifier is obtained multiple times consecutively (e.g., the time taken for a Modbus sensor to match the protocol 10 times consecutively), and the absolute difference between two adjacent reading times is calculated (e.g., the time difference between the 2nd and 1st readings, the time difference between the 3rd and 2nd readings, etc.). The absolute difference represents the positive and negative fluctuations that eliminate communication delay. Finally, the average fluctuation amplitude of all adjacent differences is calculated (e.g., the average of 10 differences). The smaller this value, the more stable the communication delay (e.g., the sensor reading time sequence is almost unaffected in a constant temperature workshop with small temperature differences); conversely, the larger the value, the more drastic the fluctuation (e.g., the device reading time fluctuates wildly in a vibrating environment).

[0053] In S32, optimization actions are triggered based on stability metrics. Specifically, if the stability metric is below a preset threshold (indicating consistently excellent communication quality, such as an OPC UA device experiencing a fluctuation of ≤0.05ms for one minute in a shielded room), the device is determined to be in a highly stable state. Following the smallest granularity allowed by the protocol specification (e.g., the CAN bus protocol supports 1-byte increments), the checksum is shortened by one standard unit (e.g., from 4 bytes to 3 bytes). The new checksum is extracted from the original integrity field (e.g., the first 3 bytes of the Modbus CRC16 field), ultimately generating a more concise feature identifier.

[0054] like Figure 2 and Figure 5 As shown, in one embodiment, obtaining the stability index of the i-th terminal device based on the reading time sequence of the feature identifier of the i-th terminal device in S31 includes:

[0055] S311. Obtain the difference between adjacent read time data in the read time sequence of the feature identifier of the i-th terminal device;

[0056] S312. Obtain the stability index based on the average of all differences in the reading time sequence of the feature identifier of the i-th terminal device.

[0057] In this embodiment, it should be noted that in S311, the instantaneous changes in communication delay are quantized. Specifically, firstly, the timing sequence of continuously acquired feature identifiers is read (e.g., the timing data of the last 5 protocol identifications of a PLC controller), and the absolute difference between two adjacent time points is calculated successively (e.g., the timing interval between the 2nd and 1st times, and the timing interval between the 3rd and 2nd times). Then, by taking the absolute value (e.g., recording +0.2ms and -0.2ms as 0.2ms), the positive and negative directions of delay fluctuations are masked, focusing on the fluctuation amplitude itself.

[0058] In S312, the stability judgment criterion for the difference sequence generation based on S311 is as follows: calculate the average of all adjacent differences (e.g., the average of 5 difference sequences for a certain OPC UA device), and then normalize the average value by reading the difference using the standard reading time of the communication protocol to obtain the final normalized value. This value directly reflects the overall stability of the communication delay. When the average value approaches 0 (e.g., the average value of CAN bus devices in a shielded room is ≈0.05ms), it indicates that the communication is almost stable; otherwise, there is significant instability (e.g., the average value of an outdoor wind sensor is 1ms).

[0059] It should also be noted that the stability index of the i-th terminal device obtained from the reading time sequence of the feature identifier of the i-th terminal device in S31 is expressed as follows:

[0060] ;in,

[0061] Let be the stability index of the i-th terminal device. The number of read time data items in the read time sequence of the feature identifier of the i-th terminal device. The (j+1)th read time data in the read time sequence of the feature identifier of the i-th terminal device. The j-th read time data in the read time sequence of the feature identifier of the i-th terminal device. This is the standard read time difference for the communication protocol of the i-th terminal device.

[0062] It should also be noted that the entire expression uses multi-level logical operations to precisely quantify communication stability. Among these, This method sums the absolute differences between adjacent reads (e.g., the time interval between the 2nd and 1st reads, or the time interval between the 3rd and 2nd reads). This avoids the limitations of existing methods that fail to detect dynamic changes in communication quality, preventing optimization of the parity bit. Furthermore, the absolute value operation eliminates the directionality of delay fluctuations (e.g., +0.3ms and -0.3ms are both recorded as 0.3ms), focusing on the intensity of the fluctuations themselves and characterizing the real-time impact of environmental interference or other factors on communication stability from a data perspective. For example, in a constant temperature workshop, the time difference sequence for adjacent reads of a sensor is [1ms, 0.5ms, 0.8ms], with a sum of absolute differences of 2.3ms; in a vibration environment, the sequence is [1.2ms, 0.3ms, 2.1ms], with a sum of differences reaching 3.6ms.

[0063] Furthermore, Convert the sum of absolute differences to an arithmetic mean to eliminate the amount of monitoring data. The impact of (e.g., 5 or 50 consecutive measurements) on the results is considered. Since different devices communicate at different frequencies (e.g., a sensor once per second, a PLC ten times per second), the data is normalized to the unit time fluctuation to ensure comparability of stability between different devices. For example, a temperature sensor obtains an average value A after 10 measurements; a PLC obtains an average value B after 50 measurements; directly comparing A and B can determine the stability difference between the devices without additional data alignment.

[0064] Furthermore, Introducing protocol-related standards for reading time difference (For example, Modbus RTU is defined as 0.5ms, and OPC UA as 0.2ms), scaling the mean fluctuation amplitude according to the protocol baseline. Different protocols have significantly different sensitivities to latency (e.g., the real-time control protocol CAN bus requires stringent low fluctuations, while the asynchronous protocol ModbusTCP tolerates higher jitter). Normalization ensures a unified metric across protocols, converting physical time (ms) into a protocol-independent stability scale, while triggering threshold consistency; a preset threshold (e.g., 0.8) applies to any protocol.

[0065] like Figure 2 and Figure 6 As shown, in one embodiment, reducing the first length and generating the second length in S3 or S32 includes:

[0066] S321. Obtain the standard byte length;

[0067] S322. Subtract the standard byte length from the first length to obtain the second length.

[0068] In this embodiment, it should be noted that in S321, the stepping rules for optimizing the check bit length are set. Specifically, the minimum adjustment unit is predefined according to the communication protocol specification (e.g., Modbus supports 1-byte steps, and CAN bus allows 2-byte adjustments). At the same time, it is ensured that the adjustment granularity does not violate protocol constraints (e.g., the minimum length of the OPC UA secure signature field is 2 bytes).

[0069] In S322, length reduction is performed when stability is achieved. When shortening in increments, the current check bit length (first length) is first reduced by a standard granularity (e.g., 4 bytes of Modbus check bits minus 1 byte equals 3 bytes) to obtain the second length. Then, a new check field is extracted using the second length. Specifically, the shortened contiguous portion is extracted from the integrity field defined by the protocol (e.g., the first 3 bytes of Modbus CRC16), and combined with the original header to generate a new identifier.

[0070] like Figure 2 and Figure 7 As shown, in one embodiment, increasing the first length and generating the third length in S4 includes:

[0071] S41. Obtain the standard byte length;

[0072] S42. Increase the first length by the standard byte length to obtain the third length.

[0073] In this embodiment, it should be noted that, similar to S321, S41 further sets the stepping rules for parity bit length optimization. S41 presets the minimum adjustment unit (standard byte length) based on the specification definition of the terminal device communication protocol (e.g., Modbus allows 1-byte step adjustment, while CAN bus requires expansion in 2-byte units). At the same time, it ensures that the step size design meets the protocol validity requirements (e.g., OPC UA security field expansion is prohibited from exceeding the maximum allowed length).

[0074] In S42, fault tolerance enhancement is performed based on the standard units defined in S41. The original check bit length (first length) is increased by one standard byte unit (e.g., from 1 byte to 2 bytes) to generate a third length. Then, the new check field is extracted using the third length, and a continuous field of the third length is extracted from the integrity field defined in the protocol (e.g., the first 2 bytes of the CRC16 field are taken from the Modbus device), and the feature identifier is reconstructed by combining it with the original data header.

[0075] like Figure 8 As shown, in one embodiment, obtaining the corresponding data header flag and the first length check bit according to the communication protocol of each terminal device in S1 includes:

[0076] S11. Extract consecutive bytes starting at a fixed position in the communication protocol of each terminal device as data header markers;

[0077] S12. Select a continuous field of length 1 from the integrity check fields defined in the communication protocol specifications of each terminal device and use it as the check bit of length 1.

[0078] In this embodiment, it should be noted that in S11, the unique static characteristics of the locking protocol are defined. Specifically, the communication protocol specification of the terminal device (such as Modbus RTU or OPC UA document) is analyzed to locate the marker field with a fixed starting position (such as "slave address + function code" starting from the first byte in Modbus, or the preamble in the OPC UA security header). A continuous byte sequence (such as the first 4 bytes of the CAN bus identifier) ​​is extracted from the fixed offset defined by the protocol and used as the data header marker for device communication.

[0079] In S12, an adaptive verification field is generated based on protocol integrity constraints. First, the verification field is located by identifying a dedicated data integrity verification field according to the protocol specification (such as the Modbus CRC16 field or the CAN bus CRC sequence). Then, an initial length truncation is performed by extracting a continuous segment of the first length from the beginning of the verification field (e.g., the first 2 bytes of Modbus CRC16) as the dynamically optimized baseline check bit.

[0080] like Figure 8As shown, in one embodiment, the generation of the feature identifier of each terminal device in S1 based on the data header flag and the check bit of the first length includes:

[0081] S13. The data header flags corresponding to each terminal device are directly concatenated with the first length of the check bits to form the feature identifier of each terminal device.

[0082] In this embodiment, it should be noted that in S13, the data header flag and the check bit are fused to form a device feature identifier. The data header flag extracted in S11 and the check bit truncated in S12 are directly concatenated end to end (e.g., data header "0x01 + 0x03" + check bit "0xA1" form "0x01030xA1"). Furthermore, the generated feature identifier serves as the device's protocol identity verification in the communication network. The host computer only needs to match this identifier to trigger the corresponding protocol parsing rules, completely bypassing data domain parsing.

[0083] like Figure 9 As shown, an industrial IoT heterogeneous protocol adaptive conversion system is also provided. The system includes a management platform, a sensor network platform, and an object platform that are sequentially connected in communication. The management platform includes:

[0084] The protocol and identifier acquisition module is used to acquire the communication network including the host computer and multiple terminal devices based on the Industrial Internet of Things, and to acquire the communication protocol of each terminal device when each terminal device enters the communication network for the first time, and to acquire the corresponding data header flag and the first length of the check bit according to the communication protocol of each terminal device, and to generate the feature identifier of each terminal device according to the data header flag and the first length of the check bit.

[0085] The identifier insertion and reading conversion module is used to insert the feature identifier of the i-th terminal device into the front end of the data stream to be sent by the i-th terminal device, and to read the feature identifier of the i-th terminal device in the data stream through the host computer and convert it to the corresponding communication protocol according to the protocol library.

[0086] The first conversion processing module is used to match and identify the data stream according to the converted communication protocol when the host computer successfully converts to the communication protocol of the i-th terminal device, and obtain the reading time sequence of the feature identifier of the i-th terminal device by the host computer within a preset time period. The first length is reduced and a second length is generated according to the reading time sequence of the feature identifier of the i-th terminal device. The check bit of the second length is obtained according to the communication protocol of the i-th terminal device. A new feature identifier of the i-th terminal device is generated according to the data header flag and the check bit of the second length. The new feature identifier is marked on the data to be sent by the i-th terminal device, and the protocol adaptive conversion is continued in this way.

[0087] The second conversion processing module is used to increase the first length and generate a third length when the host computer cannot convert to the communication protocol of the i-th terminal device, obtain the check bit of the third length according to the communication protocol of the i-th terminal device, generate a new feature identifier of the i-th terminal device according to the data header flag and the check bit of the third length, mark the new feature identifier on the data to be sent of the i-th terminal device, and continue to perform protocol adaptive conversion in this way.

[0088] In this embodiment, it should be noted that the specific method of performing the operation of the above-mentioned industrial IoT heterogeneous protocol adaptive conversion system has been described in detail in the embodiments of the industrial IoT heterogeneous protocol adaptive conversion method, and will not be elaborated here.

[0089] It should also be noted that the entire industrial IoT heterogeneous protocol adaptive conversion system can be applied to the optimized industrial IoT. Figure 9 This is a schematic diagram of the composition of the industrial Internet of Things heterogeneous protocol adaptive conversion system of the present invention. Figure 10 This is a schematic diagram illustrating the optimized industrial Internet of Things (IIoT) involved in this invention. (See diagram below.) Figure 9 and Figure 10 As shown, the optimized Industrial Internet of Things (IIoT) includes a user platform, a service platform, a management platform, a sensor network platform, and an object platform that establish communication in sequence.

[0090] The user platform is configured to provide front-end services to users; users obtain the necessary perception service information through the user platform, process the perception service information, and transform it into user perception information; users analyze the user perception information and make corresponding decisions based on their own wishes, and transform the user perception information into user control information through the corresponding information system and send it to the service platform, thereby demonstrating the user's corresponding service needs and wishes.

[0091] The physical entities of the user platform include various user terminals, such as mobile phones, computers, and dedicated terminals, which provide user services through integration with user information system software.

[0092] The service platform is configured as an API server or other server used to establish communication between the management platform and the user platform to achieve corresponding functions; the physical entity of the service platform includes various servers.

[0093] The management platform is configured to perform at least one of the following: device operation status monitoring and management, data monitoring and management, device parameter management, and lifecycle management; the management platform is the overall operation platform for the Internet of Things, which may include various management sub-platforms, with different management sub-platforms performing different management tasks; the physical entities of the management platform include various servers.

[0094] The sensor network platform is configured to perform at least one of the following functions: network management, command management, device status management, data protocol management, data parsing, data classification, data transmission monitoring, and data transmission security management. The sensor network platform provides functions such as data communication, transmission, parsing, identification, and classification, avoiding the direct aggregation of data from various object platforms onto the management platform, which would otherwise result in data redundancy and low data processing efficiency. The physical entities of the object platforms include various gateways, edge computing devices, etc.

[0095] The object platform is configured to perform specific production control, detection, measurement and other production tasks; the physical entities of the production objects include various production equipment, sensors and so on.

[0096] Figure 11 This is a block diagram of an electronic device illustrating an adaptive conversion method for heterogeneous protocols in the Industrial Internet of Things (IIoT) according to an exemplary embodiment. For example... Figure 11 As shown, the electronic device 700 may include: a processor 701 and a memory 702. The electronic device 700 may also include one or more of a multimedia component 703, an I / O interface 704 (input / output interface), and a communication component 705.

[0097] The processor 701 controls the overall operation of the electronic device 700 to complete all or part of the steps in the aforementioned industrial IoT heterogeneous protocol adaptive conversion method. The memory 702 stores various types of data to support the operation of the electronic device 700. This data may include, for example, instructions for any application or method operating on the electronic device 700, and application-related data such as contact data, sent and received messages, images, audio, video, etc. The memory 702 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, disk, or optical disk. Multimedia component 703 may include a screen and an audio component. The screen may be, for example, a touchscreen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in memory 702 or transmitted via communication component 705. The audio component also includes at least one speaker for outputting audio signals. I / O interface 704 provides an interface between processor 701 and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual or physical buttons. Communication component 705 is used for wired or wireless communication between the electronic device 700 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, 4G, NB-IoT, eMTC, or other 5G technologies, or combinations thereof, is not limited here. Therefore, the corresponding communication component 705 may include: a Wi-Fi module, a Bluetooth module, an NFC module, etc.

[0098] In an exemplary embodiment, the electronic device 700 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to execute the above-described industrial Internet of Things heterogeneous protocol adaptive conversion method.

[0099] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided. When executed by a processor, these program instructions implement the steps of the above-described industrial Internet of Things (IIoT) heterogeneous protocol adaptive conversion method. For example, the computer-readable storage medium may be the memory 702 including program instructions, which may be executed by the processor 701 of the electronic device 700 to complete the above-described industrial Internet of Things (IIoT) heterogeneous protocol adaptive conversion method.

[0100] In another exemplary embodiment, a computer program product is also provided, the computer program product comprising a computer program executable by a programmable device, the computer program having a code portion for performing the above-described industrial Internet of Things heterogeneous protocol adaptive conversion method when executed by the programmable device.

[0101] The preferred embodiments of this disclosure have been described in detail above with reference to the accompanying drawings. However, this disclosure is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this disclosure, various simple modifications can be made to the technical solutions of this disclosure, and these simple modifications all fall within the protection scope of this disclosure.

[0102] It should also be noted that the various specific technical features described in the above embodiments can be combined in any suitable manner without contradiction. To avoid unnecessary repetition, this disclosure will not describe the various possible combinations separately.

[0103] Furthermore, various different embodiments of this disclosure can be combined in any way, as long as they do not violate the spirit of this disclosure, they should also be regarded as the content disclosed in this disclosure.

[0104] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be covered within the scope of the claims and specification of the present invention.

Claims

1. An adaptive conversion method for heterogeneous protocols in the Industrial Internet of Things (IIoT), characterized in that, include: Based on the Industrial Internet of Things, the communication network including the host computer and multiple terminal devices is acquired. When each terminal device enters the communication network for the first time, the communication protocol of each terminal device is acquired. According to the communication protocol of each terminal device, the corresponding data header flag and the first length of the check bit are acquired. The feature identifier of each terminal device is generated according to the data header flag and the first length of the check bit. Insert the feature identifier of the i-th terminal device into the front end of the data stream to be sent by the i-th terminal device, and read the feature identifier of the i-th terminal device in the data stream through the host computer and convert it to the corresponding communication protocol according to the protocol library; If the host computer successfully converts to the communication protocol of the i-th terminal device, it matches and identifies the data stream according to the converted communication protocol, obtains the reading time sequence of the feature identifier of the i-th terminal device within a preset time period, reduces the first length and generates the second length according to the reading time sequence of the feature identifier of the i-th terminal device, obtains the check bit of the second length according to the communication protocol of the i-th terminal device, generates a new feature identifier of the i-th terminal device according to the data header flag and the check bit of the second length, marks the new feature identifier on the data to be sent of the i-th terminal device, and continues to perform protocol adaptive conversion in this way. If the host computer cannot switch to the communication protocol of the i-th terminal device, the first length is increased and a third length is generated. The check bit of the third length is obtained according to the communication protocol of the i-th terminal device. A new feature identifier of the i-th terminal device is generated according to the data header flag and the check bit of the third length. The new feature identifier is marked on the data to be sent by the i-th terminal device, and the protocol adaptive conversion continues in this way.

2. The industrial IoT heterogeneous protocol adaptive conversion method according to claim 1, characterized in that, The step of reducing the first length and generating the second length based on the reading time sequence of the feature identifier of the i-th terminal device includes: The stability index of the i-th terminal device is obtained based on the reading time sequence of the feature identifier of the i-th terminal device. If the stability index of the i-th terminal device is less than the preset threshold, then the first length is reduced and a second length is generated.

3. The industrial IoT heterogeneous protocol adaptive conversion method according to claim 2, characterized in that, The process of obtaining the stability index of the i-th terminal device based on the reading time sequence of the feature identifier of the i-th terminal device includes: Obtain the difference between adjacent read time data in the read time sequence of the feature identifier of the i-th terminal device; The stability index is obtained by averaging all differences in the reading time sequence of the feature identifier of the i-th terminal device.

4. The industrial IoT heterogeneous protocol adaptive conversion method according to claim 2, characterized in that, The process of reducing the first length and generating the second length includes: Get the standard byte length; The second length is obtained by subtracting the standard byte length from the first length.

5. The industrial IoT heterogeneous protocol adaptive conversion method according to claim 1, characterized in that, The process of increasing the first length and generating the third length includes: Get the standard byte length; The third length is obtained by adding the standard byte length to the first length.

6. The industrial IoT heterogeneous protocol adaptive conversion method according to claim 1, characterized in that, The step of obtaining the corresponding header flag and the first length of check bits according to the communication protocol of each terminal device includes: Extract consecutive bytes starting at a fixed position from the communication protocol of each terminal device as the data header marker; Select a continuous field of length 1 from the integrity check fields defined in the communication protocol specifications of each terminal device and use it as the check bit of length 1.

7. The industrial IoT heterogeneous protocol adaptive conversion method according to claim 1, characterized in that, The process of generating the feature identifier for each terminal device based on the data header flag and the checksum of the first length includes: The data header flag corresponding to each terminal device is directly concatenated with the first length of the check bit to form the feature identifier of each terminal device.

8. An industrial Internet of Things (IoT) heterogeneous protocol adaptive conversion system, characterized in that, The system includes a management platform, a sensor network platform, and an object platform that are sequentially connected in communication. The management platform includes: The protocol and identifier acquisition module is used to acquire the communication network including the host computer and multiple terminal devices based on the Industrial Internet of Things, and to acquire the communication protocol of each terminal device when each terminal device enters the communication network for the first time, and to acquire the corresponding data header flag and the first length of the check bit according to the communication protocol of each terminal device, and to generate the feature identifier of each terminal device according to the data header flag and the first length of the check bit. The identifier insertion and reading conversion module is used to insert the feature identifier of the i-th terminal device into the front end of the data stream to be sent by the i-th terminal device, and to read the feature identifier of the i-th terminal device in the data stream through the host computer and convert it to the corresponding communication protocol according to the protocol library. The first conversion processing module is used to match and identify the data stream according to the converted communication protocol when the host computer successfully converts to the communication protocol of the i-th terminal device, and obtain the reading time sequence of the feature identifier of the i-th terminal device by the host computer within a preset time period. The first length is reduced and a second length is generated according to the reading time sequence of the feature identifier of the i-th terminal device. The check bit of the second length is obtained according to the communication protocol of the i-th terminal device. A new feature identifier of the i-th terminal device is generated according to the data header flag and the check bit of the second length. The new feature identifier is marked on the data to be sent by the i-th terminal device, and the protocol adaptive conversion is continued in this way. The second conversion processing module is used to increase the first length and generate a third length when the host computer cannot convert to the communication protocol of the i-th terminal device, obtain the check bit of the third length according to the communication protocol of the i-th terminal device, generate a new feature identifier of the i-th terminal device according to the data header flag and the check bit of the third length, mark the new feature identifier on the data to be sent of the i-th terminal device, and continue to perform protocol adaptive conversion in this way.

9. An electronic device, characterized in that, include: A memory on which computer programs are stored; A processor for executing the computer program in the memory to implement the industrial Internet of Things heterogeneous protocol adaptive conversion method according to any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the industrial IoT heterogeneous protocol adaptive conversion method as described in any one of claims 1 to 7.

Images