An Industrial Bus IoT Collaborative Control Method

Abstract

This invention relates to an industrial bus IoT collaborative control method, belonging to the IoT field, and includes the following steps: extracting protocol features and synchronizing clocks of heterogeneous bus nodes to generate standard timing messages; forming a hierarchical data queue through periodic calculation and priority sorting; encrypting and encapsulating the queue and mapping topics to generate secure IoT messages; completing connection authentication and status synchronization of the IoT platform based on the messages, and obtaining instructions issued from the cloud; performing protocol reverse parsing and timing reconstruction on the instructions to generate bus control messages; and finally allocating time slots and executing commands on the heterogeneous bus nodes according to the messages to achieve collaborative device actions. This method solves the problem of how to achieve collaborative control between heterogeneous bus nodes and the IoT platform, thereby addressing the difficulty in effectively executing collaborative device actions due to protocol heterogeneity, timing asynchrony, and incompatible commands.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to an industrial bus IoT collaborative control method. Background Technology

[0002] Against the backdrop of the rapid development of the Industrial Internet of Things and intelligent control systems, heterogeneous bus nodes (such as CAN, Modbus, Profibus, OPC UA, etc.) are widely present in various devices and subsystems, with significant differences in their protocol formats, communication mechanisms, timing characteristics, and security strategies.

[0003] When these nodes need to be connected to a unified IoT platform for collaborative control, they often face problems such as data interoperability obstacles caused by protocol incompatibility, action disorder caused by lack of global time synchronization, delay of critical instructions due to undefined data priorities, weak communication link security that is vulnerable to attack, and mismatch between platform-issued instructions and local device control logic. These problems severely restrict the efficient, reliable and secure collaborative execution capabilities among multiple devices. Summary of the Invention

[0004] The purpose of this invention is to at least partially solve one of the technical problems existing in the prior art.

[0005] To achieve the above objectives, this invention provides an industrial bus IoT collaborative control method, applied to a control system comprising heterogeneous bus nodes and an IoT platform, including: Protocol features are extracted and clock synchronization is performed on the heterogeneous bus nodes to obtain standard timing messages. Period calculation and priority sorting are performed on the standard timing messages to obtain hierarchical data queues. The hierarchical data queue is encrypted and encapsulated with topic mapping to obtain a secure IoT message; Based on the secure IoT message, the IoT platform is connected for authentication and status synchronization, and instructions are sent from the cloud. The cloud-issued commands are subjected to protocol reverse parsing and timing reconstruction to obtain bus control messages; Based on the bus control messages, time slots are allocated and executed for the heterogeneous bus nodes to achieve coordinated device operation.

[0006] Furthermore, the step of extracting protocol features and synchronizing the clock on the heterogeneous bus nodes to obtain standard timing messages includes: The original data stream of the heterogeneous bus node is obtained and the frame header is delimited and the bit width is truncated to obtain the protocol field sequence; Data field extraction and checksum comparison are performed on the protocol field sequence to obtain payload data; the timestamp field in the payload data is extracted, and it is calculated whether there is a clock offset between the timestamp field and the local reference clock. If it exists, the payload data is timestamped based on the clock offset to obtain synchronized payload data; The synchronous payload data is concatenated and filled with fields of a preset unified frame format to obtain a standard timing message.

[0007] Furthermore, the standard time-series messages are subjected to periodic calculation and priority sorting to obtain a hierarchical data queue, including: Extract the consecutive timestamps and service attribute bits of the standard time sequence message, calculate the difference between adjacent consecutive timestamps, and obtain the message arrival interval; Calculate the statistical variance of the message arrival interval within a preset time window, and divide the statistical variance by the square of the mean of the message arrival intervals within the time window to obtain the normalized burst index. The business attribute bits are compared with the preset mapping table to obtain the basic business weights. The reciprocal of the sum of the normalized burst index and the preset constant 1 is calculated to obtain the stability coefficient. The product of the basic business weights and the stability coefficient is calculated to obtain the dynamic scheduling base. The dynamic scheduling base is compared with the preset dimensionless hierarchical division threshold to obtain the priority label. The priority label is written into the reserved field of the standard time sequence message to obtain the signed time sequence message. Based on the value of the priority tag, the tagged time-series message is allocated to the corresponding independent buffer block, and the independent buffer blocks are concatenated to obtain a hierarchical data queue.

[0008] Furthermore, based on the value of the priority tag, the tagged time-series message is allocated to the corresponding independent buffer block, and the independent buffer blocks are concatenated to obtain a hierarchical data queue, including: The priority tag in the signed timing message is compared with the preset hardware address mapping table to obtain the isolated memory base address; Based on the isolated memory base address, the signed time-series message is directly written to memory to obtain an independent cache block; Extract the first and last memory pointers of the independent cache block, and reconstruct the first and last memory pointers into a hardware linked list in descending order of the priority label value to obtain the scheduling pointer chain; The scheduling pointer chain is bound to a preset sending port descriptor to obtain a hierarchical data queue.

[0009] Furthermore, the hierarchical data queue is encrypted and encapsulated, and a topic is mapped to obtain a secure IoT message, including: Extract the queue metadata of the hierarchical data queue. The queue metadata includes at least a priority label, a unique device identifier, a data service type code, and a plaintext synchronization timestamp. The plaintext synchronization timestamp is the system clock value at the time the hierarchical data queue is generated or a unified reference time associated with the collection time of the first message in the hierarchical data queue. The device's unique identifier and the plaintext synchronization timestamp are input into the key derivation function in a preset concatenation order to generate the dynamic key bitstream used for this encryption. The ciphertext data block is obtained by performing a bitwise XOR operation between the byte stream to be encrypted in the hierarchical data queue and the dynamic key bit stream. The priority tag is combined with the data service type code to form a topic key value. The topic key value is compared with a preset cloud topic mapping table to obtain the topic path characters. The topic path characters, the plaintext synchronization timestamp, and the ciphertext data block are sequentially concatenated byte by byte to form the payload to be encapsulated. A preset frame delimiter is then appended to both ends of the payload to be encapsulated to obtain a secure IoT message.

[0010] Furthermore, based on the secure IoT message, connection authentication and status synchronization are performed on the IoT platform to obtain instructions issued from the cloud, including: Extract the identity identifier and encrypted payload of the secure IoT message, compare the identity identifier with the preset cloud registry to obtain the authentication certificate. The identity identifier is a device unique identifier encrypted block encrypted in advance using the platform master key. The encrypted payload is composed of topic path characters, plaintext synchronization timestamp and encrypted data block concatenated in sequence. Separate the plaintext synchronization timestamp and the ciphertext data block from the ciphertext payload; Using the authentication certificate as the decryption key, a symmetric decryption operation is performed on the identity identifier to recover the plaintext of the device's unique identifier. The device's unique identifier plaintext and the plaintext synchronization timestamp are input into the same key derivation function to generate a decryption key stream. The decryption key stream is then used to perform a bitwise XOR decryption on the ciphertext data block to obtain the legitimate state payload. Extract the original acquisition timestamp and status field from the legal state payload, calculate the difference between the original acquisition timestamp and the preset cloud clock to obtain the time difference offset, and compare the time difference offset with the preset effective time window. If the time difference offset is within the effective time window, generate a synchronization identifier. The synchronization identifier is concatenated with the status field to obtain a real-time snapshot. The real-time snapshot is then matched with a preset control logic table to obtain initial parameters. These initial parameters are then filled into a preset instruction template to obtain cloud-based instructions.

[0011] Furthermore, the real-time snapshot is matched with a preset control logic table using key-value pairs to obtain initial parameters, including: Extract the key field descriptor of the preset control logic table, extract the corresponding key value field from the real-time snapshot, and construct a matching key; Perform a binary search between the matching key and the key-value array of the control logic table to obtain the matching index; The static control word is read from the value field array of the control logic table according to the matching index; the instruction code segment and data code segment of the static control word are extracted, and the instruction code segment and the data code segment are concatenated byte by byte to obtain the initial parameters.

[0012] Furthermore, the cloud-issued commands are subjected to protocol reverse parsing and timing reconstruction to obtain bus control messages, including: Extract the business semantic characters and logical tag addresses from the cloud-issued instructions, compare the logical tag addresses with the preset addressing mapping table by key value, and obtain the physical hardware address; The business semantic characters are converted into bytes according to preset encoding rules to obtain binary raw data. The physical hardware address is then concatenated with the binary raw data to obtain the underlying control payload. Extract the preset local bus cycle duration and the current time value obtained from the local clock source, calculate the phase offset of the current time within the bus cycle, and use the phase offset as the time alignment deviation. Subtract the time alignment deviation from the local bus cycle duration to obtain the synchronization compensation delay. Write the synchronization compensation delay into a preset bus frame header to obtain an offset frame header. Concatenate the offset frame header with the underlying control payload to obtain a bus control message.

[0013] This invention provides an industrial bus IoT collaborative control method, comprising the following steps: extracting protocol features and synchronizing clocks on the heterogeneous bus nodes to obtain standard timing messages; performing period calculation and priority sorting on the standard timing messages to obtain hierarchical data queues; encrypting and encapsulating the hierarchical data queues and mapping topics to obtain secure IoT messages; performing connection authentication and status synchronization on the IoT platform based on the secure IoT messages to obtain cloud-based instructions; performing protocol reverse parsing and timing reconstruction on the cloud-based instructions to obtain bus control messages; and allocating time slots and issuing instructions to the heterogeneous bus nodes based on the bus control messages. This system enables collaborative operation of devices, solving the problem of how to achieve collaborative control between heterogeneous bus nodes and IoT platforms. It addresses the difficulty in effectively executing collaborative actions due to protocol heterogeneity, timing asynchrony, and incompatible commands. The system achieves technical effects such as multi-protocol adaptive access, high-precision timing alignment, differentiated data priority guarantee, end-to-end secure communication, and command semantic consistency mapping. As a result, it significantly improves the real-time performance, reliability, and security of collaborative control between heterogeneous bus devices and IoT platforms in complex industrial environments, effectively supporting the efficient linkage and intelligent scheduling of industrial equipment across vendors, protocols, and time domains. Attached Figure Description

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

[0015] Figure 1 This is a schematic diagram of the steps of an industrial bus IoT collaborative control method in one embodiment of the present invention; Figure 2 This is one embodiment of the present invention. Figure 1 Schematic diagram of step S4 The objectives, features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0016] The embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention. The step numbers in the following embodiments are set only for ease of explanation, and there is no limitation on the order between the steps. The execution order of each step in the embodiments can be adaptively adjusted according to the understanding of those skilled in the art.

[0017] Please see Figure 1 This invention discloses an industrial bus IoT collaborative control method, applied to a control system comprising heterogeneous bus nodes and an IoT platform, including: Step S1: Extract protocol features and synchronize clocks for the heterogeneous bus nodes to obtain standard timing messages, and perform period calculation and priority sorting on the standard timing messages to obtain hierarchical data queues.

[0018] Specifically, protocol feature extraction and clock synchronization are performed on the heterogeneous bus nodes. This is achieved by deploying a protocol parsing module at the access layer to identify the frame structure, baud rate, and periodic triggering mechanism of each bus node, extracting its communication timing fingerprint. Simultaneously, the local clocks of each node are calibrated using the IEEE 1588 precision time protocol or hardware synchronization signals, aligning the data sampling times of different buses to a unified time base, thereby generating standard timing messages with a unified timestamp. Subsequently, the communication cycle is calculated based on the transmission interval of these standard timing messages, and priority weights are assigned according to the function code or device type in the message content. For example, motion control messages are set to high priority, and status monitoring messages to low priority, thus constructing a hierarchical data queue based on priority and cycle constraints. In this embodiment, the above solution effectively solves the data scheduling conflict problem caused by asynchronous timing and mixed priorities in heterogeneous buses, improving the timing consistency of subsequent cloud-based collaborative control.

[0019] Step S2: Encrypt and encapsulate the hierarchical data queue and map it to a topic to obtain a secure IoT message.

[0020] Specifically, the hierarchical data queue is encrypted and mapped to topics. This involves using the national cryptographic standard SM4 or AES-128 algorithm in the edge gateway to encrypt the payload of each message in the queue, with the key dynamically distributed by the IoT platform. Then, based on pre-configured MQTT topic rules, high-priority control messages are mapped to the " / control / high" topic, and status messages are mapped to corresponding channels such as " / monitor / low," forming structured and encrypted secure IoT messages. In this embodiment, the above solution ensures the confidentiality of heterogeneous bus data transmission while achieving precise routing based on business semantics, avoiding mis-sending of instructions caused by unauthorized subscriptions and topic confusion.

[0021] Step S3: Based on the secure IoT message, perform connection authentication and status synchronization on the IoT platform to obtain instructions issued from the cloud.

[0022] Specifically, the IoT platform is authenticated and its status synchronized based on the secure IoT messages. Specifically, when establishing an MQTT connection, the edge node carries a device certificate and dynamic token pre-configured by the platform to complete two-way TLS authentication. After the connection is established, the latest device status in the hierarchical data queue is reported through the corresponding topic. The platform then compares this status with the digital twin model and generates cloud-based commands that match the current operating conditions. For example, in a multi-axis collaborative scenario, when a servo node's periodic offset exceeds the limit, the platform issues a phase compensation command. In this embodiment, the above scheme ensures strict alignment between control commands and the real-time status of the fieldbus, effectively suppressing malfunctions caused by state asynchrony.

[0023] Step S4: Perform protocol reverse parsing and timing reconstruction on the cloud-issued command to obtain the bus control message.

[0024] Specifically, the cloud-issued commands undergo protocol reverse parsing and timing reconstruction. This involves loading a protocol template library matching the target bus type at the edge, and reconstructing the corresponding Modbus register write format or CAN ID and data field structure based on the device address and function identifier carried in the command. Simultaneously, combining the period parameters from the previously extracted standard timing messages, the command is embedded into the time window of the next valid communication time slot, generating a bus control message that conforms to local bus timing constraints. For example, in a multi-axis synchronization scenario, the position compensation value issued by the platform is aligned to after the CANopen SYNC frame with a 2ms period. In this embodiment, the above scheme achieves accurate conversion of cloud commands to the native timing semantics of heterogeneous buses, avoiding execution anomalies caused by protocol mismatch or timing misalignment.

[0025] Step S5: Based on the bus control message, allocate time slots and send execution requests to the heterogeneous bus nodes to achieve coordinated device operation.

[0026] Specifically, based on the bus control messages, time slots are allocated and executed for the heterogeneous bus nodes. Specifically, the edge controller reserves a dedicated transmission window for each node in the TDMA scheduling table according to the communication cycle and priority registered in the standard timing messages. For example, high-priority servo drive nodes are allocated to the initial micro-time slot of the CAN bus every 2ms cycle, while low-speed I / O modules are placed in subsequent non-critical time slots. Subsequently, a hardware timer is triggered in the corresponding time slot to convert the bus control messages into physical layer signals through the protocol adaptation layer and inject them into the bus. In this embodiment, the above scheme ensures precise coordination of multiple types of devices under a unified time axis, significantly reducing the loss of synchronization caused by bus contention or timing drift.

[0027] In a specific embodiment, the step of extracting protocol features and synchronizing the clock on the heterogeneous bus nodes to obtain standard timing messages includes: The original data stream of the heterogeneous bus node is obtained and the frame header is delimited and the bit width is truncated to obtain the protocol field sequence; Data field extraction and checksum comparison are performed on the protocol field sequence to obtain payload data; the timestamp field in the payload data is extracted, and it is calculated whether there is a clock offset between the timestamp field and the local reference clock. If it exists, the payload data is timestamped based on the clock offset to obtain synchronized payload data; The synchronous payload data is concatenated and filled with fields of a preset unified frame format to obtain a standard timing message.

[0028] Specifically, the process of extracting protocol features and synchronizing clocks for the heterogeneous bus nodes to obtain standard timing messages begins by acquiring the raw data streams from each bus interface at the physical layer. These data streams may originate from channels with different electrical specifications, such as CAN, Modbus RTU, or PROFIBUS. Then, at the link layer, a frame header delimitation operation is performed. For example, the synchronization point is identified by recognizing the start bit "0" of the CAN frame or the address fields 0x01~0xF7 of Modbus. Based on pre-configured bit width parameters (such as the 11-bit identifier of the CAN standard frame and the 8-bit data byte of Modbus), continuous bit streams are truncated to reconstruct the complete protocol field sequence. Next, the protocol field sequence is subjected to structured parsing to separate the address field, function code, data field, and tail check field. The checksum of the data field is then recalculated using CRC-16 or BCC algorithms and compared with the check field in the original message. Only when the two match is the data field marked as payload data; otherwise, it is discarded to prevent noise interference from introducing error states.

[0029] After obtaining the payload data, the system further scans its internal memory for a timestamp field. This field is typically located at the 47th bit of the data byte in the CAN message, or in a predefined high-precision time register in the Modbus register map (e.g., the combination 4000140002 represents millisecond-level UTC time). Once the timestamp field is identified, its value is interpolated with the local reference clock (provided by the IEEE 1588 master clock or GPS module). If the deviation exceeds a set threshold (e.g., ±50μs), a clock offset is determined to exist. At this point, the edge controller does not simply discard the message, but instead uses linear interpolation or phase-locked loop to estimate the current real time and rewrites the original timestamp field with the corrected time value to generate synchronized payload data. Finally, the synchronization payload data is reassembled according to the unified frame format requirements: the unified frame format specifies a fixed length of 64 bytes, including a preamble (4 bytes), device ID (2 bytes), synchronization timestamp (8 bytes), original payload (variable length, maximum 48 bytes) and padding fields (padded with zeros to 64 bytes for alignment). Through field concatenation and tail padding operations, a standard timing message with consistent structure and time alignment is formed.

[0030] For example, in a multi-axis servo cooperative control system, the original timestamp of the position feedback message reported by a CAN node is 123456789μs, while the local reference clock is 123456850μs, resulting in an offset of 61μs, which exceeds the tolerance range. The system then rewrites the timestamp based on the local clock and embeds the position data into the payload area of ​​a unified frame format, ensuring that subsequent cloud command scheduling is based on the same time baseline. In this embodiment, the above solution effectively eliminates the timing inaccuracy problem caused by local crystal oscillator drift or transmission delay on heterogeneous buses, enabling the device states from different manufacturers and with different communication protocols to be accurately aligned under a unified time coordinate, providing a reliable data foundation for high-precision cooperative control.

[0031] In a specific embodiment, the standard time-series messages are periodically calculated and prioritized to obtain a hierarchical data queue, including: Extract the consecutive timestamps and service attribute bits of the standard time sequence message, calculate the difference between adjacent consecutive timestamps, and obtain the message arrival interval; Calculate the statistical variance of the message arrival interval within a preset time window, and divide the statistical variance by the square of the mean of the message arrival intervals within the time window to obtain the normalized burst index. The business attribute bits are compared with the preset mapping table to obtain the basic business weights. The reciprocal of the sum of the normalized burst index and the preset constant 1 is calculated to obtain the stability coefficient. The product of the basic business weights and the stability coefficient is calculated to obtain the dynamic scheduling base. Compare the dynamic scheduling base number with a preset dimensionless level division threshold to obtain a priority label, and write the priority label into the reserved field of the standard timing message to obtain a signed timing message; According to the value of the priority label, allocate the signed timing message to the corresponding independent cache block, and splice the independent cache blocks to obtain a hierarchical data queue.

[0032] Specifically, the process of performing cycle calculation and priority sorting on the standard timing message to obtain a hierarchical data queue starts from extracting the continuous timestamp field and service attribute bits from the synchronized standard timing message. Among them, the continuous timestamp records the exact moment when each message arrives at the edge node under the unified time base, and the service attribute bits are preset by the device manufacturer to identify the control type to which the message belongs (such as position feedback, emergency stop signal, or status heartbeat); Subsequently, the system calculates the difference between two adjacent continuous timestamps in sequence to form a series of message arrival interval sequences. To evaluate the regularity of this sequence, further calculate its variance σ² within a sliding time window (for example, a 500ms window, including the last 250 interval samples), and divide this variance by the square of the mean μ of the message arrival intervals within the same window, that is, calculate the normalized burst index γ = σ² / μ². This index reflects the burst degree of the message flow - the smaller the value, the stronger the periodicity.

[0033] The system reads the service attribute bits in the standard timing message and compares them with a preset mapping table, which is pre-configured by the platform. For example, "01" corresponds to servo position feedback (basic service weight w = 0.8), "10" corresponds to safety emergency stop (w = 1.0), "00" corresponds to ordinary status reporting (w = 0.3), so as to obtain the corresponding basic service weight; Then, calculate the stability coefficient s = 1 / (γ + 1), which decays as the burst index increases, to suppress the scheduling priority of non-periodic interference messages; Then multiply the basic service weight by the stability coefficient to obtain the dynamic scheduling base number d = w × s, which combines the dual factors of service importance and timing stability. After that, compare the dynamic scheduling base number d with a set of preset dimensionless level division thresholds (such as T1 = 0.25, T2 = 0.55, T3 = 0.85): If d ≤ T1, mark it as the priority label "3" (low); If T1 < d ≤ T2, the label is "2" (medium); If T2 < d ≤ T3, the label is "1" (high); If d > T3, the label is "0" (urgent). This priority label is written into the reserved field of the standard timing message header to form a signed timing message.

[0034] Based on the priority tag values, the system routes tagged time-series messages to the corresponding independent buffer blocks—for example, tag "0" enters the high-priority FIFO buffer A, tag "1" enters buffer B, and so on. Each buffer block adopts a circular queue structure, with independent read / write pointers and overflow protection mechanisms. When the upper-layer scheduling module requests data, it concatenates the contents of each independent buffer block in ascending order of tag values ​​to form a complete hierarchical data queue. Taking a multi-axis collaborative scenario as an example, a servo node experiences slight periodic jitter due to mechanical vibration (γ≈0.04). Its basic business weight is 0.8, so d ≈ 0.8 / (1+0.04) ≈ 0.769, falling within the (T2, T3] interval. It is assigned tag "1" and enters the high-priority queue, ensuring that its position feedback is processed first before cloud instructions are generated.

[0035] In a specific embodiment, based on the value of the priority tag, the tagged time-series message is allocated to the corresponding independent buffer block, and the independent buffer blocks are concatenated to obtain a hierarchical data queue, including: The priority tag in the signed timing message is compared with the preset hardware address mapping table to obtain the isolated memory base address; Based on the isolated memory base address, the signed time-series message is directly written to memory to obtain an independent cache block; Extract the first and last memory pointers of the independent cache block, and reconstruct the first and last memory pointers into a hardware linked list in descending order of the priority label value to obtain the scheduling pointer chain; The scheduling pointer chain is bound to a preset sending port descriptor to obtain a hierarchical data queue.

[0036] Specifically, based on the value of the priority tag, the tagged time-series message is allocated to the corresponding independent buffer block and concatenated to form a hierarchical data queue. Its specific implementation first relies on the static configuration of the hardware address mapping table: this mapping table is loaded by the firmware during the system initialization phase, and the priority tags "0" to "3" are associated with pre-divided isolated memory base addresses in physical memory, for example, tag "0" corresponds to 0x2000_0000, and "1" corresponds to 0x2000_4000. The size of each block is fixed at 4KB and they do not overlap with each other, ensuring that data of different priorities are completely isolated at the physical level. When a tagged time-series message arrives, the priority tag field in its header is extracted and used as an index to perform address comparison in the mapping table, thereby quickly finding the corresponding isolated memory base address. Subsequently, the DMA controller directly writes the entire tagged timing message (including timestamp, synchronization payload and tag) into a contiguous memory region starting from the base address, bypassing the CPU cache to reduce latency. The write position is dynamically maintained by the write pointer inside the block, thus forming a compact and efficient independent cache block.

[0037] During the continuous reception of data across multiple independent buffer blocks, the system periodically extracts the current first memory pointer (pointing to the earliest unsent packet) and the last memory pointer (pointing to the latest written position) of each block, and encapsulates these two into a pointer pair structure. Then, based on the priority tag values, they are sorted in descending order—tag "0" being the highest priority and "3" the lowest—and linked in this order into a hardware-recognizable scheduling pointer chain by modifying the linked list register in the memory controller. This linked list structure is directly parsed by a dedicated scheduling logic unit without software polling intervention. Finally, this scheduling pointer chain is bound to a preset transmit port descriptor, which contains parameters such as the target bus interface number (e.g., CAN1 or ETH0), maximum burst length, and arbitration threshold. The binding operation essentially writes the head address of the linked list into the pointer field of the descriptor, enabling the network controller to automatically traverse the linked list in priority order at the beginning of each transmission cycle, reading packets sequentially from high to low and injecting them into the physical bus, thereby completing the construction of the hierarchical data queue.

[0038] Taking multi-axis servo cooperative control as an example, when the emergency stop signal (tag "0") and position feedback (tag "1") are ready at the same time, the scheduling pointer chain will first point to the first pointer of the block where the emergency stop is located, ensuring that it is sent immediately in the next CAN bus idle window, and the position data follows closely behind; even if the number of position messages is much greater than the number of emergency stop messages, the safety command will not be delayed due to queue accumulation.

[0039] In a specific embodiment, the hierarchical data queue is encrypted and encapsulated, and a topic is mapped to obtain a secure IoT message, including: Extract the queue metadata of the hierarchical data queue. The queue metadata includes at least a priority label, a unique device identifier, a data service type code, and a plaintext synchronization timestamp. The plaintext synchronization timestamp is the system clock value at the time the hierarchical data queue is generated or a unified reference time associated with the collection time of the first message in the hierarchical data queue. The device's unique identifier and the plaintext synchronization timestamp are input into the key derivation function in a preset concatenation order to generate the dynamic key bitstream used for this encryption. The ciphertext data block is obtained by performing a bitwise XOR operation between the byte stream to be encrypted in the hierarchical data queue and the dynamic key bit stream. The priority tag is combined with the data service type code to form a topic key value. The topic key value is compared with a preset cloud topic mapping table to obtain the topic path characters. The topic path characters, the plaintext synchronization timestamp, and the ciphertext data block are sequentially concatenated byte by byte to form the payload to be encapsulated. A preset frame delimiter is then appended to both ends of the payload to be encapsulated to obtain a secure IoT message.

[0040] Specifically, the process of encrypting and mapping the hierarchical data queue to obtain secure IoT messages first involves extracting its queue metadata from the constructed hierarchical data queue. This metadata is not additional information but rather fixed fields embedded in the queue structure header, including at least a priority label, a unique device identifier (such as a 64-bit hardware address in IEEE EUI-64 format), a data service type code (e.g., 0x11 for location feedback, 0x20 for emergency stop status), and a plaintext synchronization timestamp. The plaintext synchronization timestamp is taken as the system clock value at the moment the hierarchical data queue is spliced. If the system adopts an event-driven mode, this timestamp can also be associated with the collection time of the first signed time-series message in the queue, and this time is based on the aforementioned unified reference time to ensure consistency across the entire network. Subsequently, the device's unique identifier and the plaintext synchronization timestamp are combined into a 128-bit input block according to a preset concatenation order—for example, low bits first, high bits second, timestamp first, identifier last—and sent to the key derivation function (KDF). This function can use HMAC-SHA256 or the national cryptographic SM3-HMAC structure, and outputs a dynamic key bit stream with a length equal to that of the data to be encrypted. Each encapsulation generates a new key due to the change of timestamp, thus preventing replay attacks.

[0041] The system iterates through the payload portion of the hierarchical data queue, constructing a byte-by-byte stream to be encrypted. This stream is then XORed with the aforementioned dynamic key stream, i.e., for the i-th byte, the ciphertext C[i] = P[i]⊕ K[i], where P is the plaintext and K is the corresponding byte in the key stream. This generates an irreversible ciphertext data block. The original priority label and service type code are not involved in encryption to preserve scheduling semantics. Simultaneously, the priority label and data service type code are concatenated in binary (e.g., the high 4 bits are the label, and the low 8 bits are the type code) to form a 12-bit topic key. This key is used to query a pre-loaded cloud-based topic mapping table, which is pre-loaded by the edge configuration module. For example, key 0x011 (label "0" + type 0x11) maps to " / factory / line3 / axis5 / emergency", and key 0x120 maps to " / factory / line3 / safety / estop". The corresponding UTF-8 encoded topic path characters are obtained through precise key-value comparison. Subsequently, the subject path characters, the unencrypted plaintext synchronization timestamp (represented in 8-byte big-endian order), and the aforementioned ciphertext data block are sequentially concatenated byte-by-byte to form the payload to be encapsulated. Finally, 0x7E is added to the beginning of the payload as a start frame delimiter, and 0x7E and a 2-byte FCS checksum (based on the CRC-16-CCITT algorithm) are appended to the end to form a secure IoT message with a complete frame structure.

[0042] In a multi-axis servo collaborative scenario, after an emergency stop event is triggered, its hierarchical data queue contains a tag "0", a device ID of 0x123456789ABCDEF0, a service code of 0x20, and a timestamp of 1717020800123456μs. After being encrypted by a unique key stream generated by KDF, the topic key value 0x020 is used to look up the path " / plantA / zone2 / estop". The final message starts with 0x7E, carrying this path, the original timestamp, and the ciphertext, which is then directly routed to the cloud security processing module by the MQTT gateway.

[0043] In a specific embodiment, the IoT platform is authenticated and its status synchronized based on the secure IoT message to obtain instructions issued from the cloud, including: Extract the identity identifier and encrypted payload of the secure IoT message, compare the identity identifier with the preset cloud registry to obtain the authentication certificate. The identity identifier is a device unique identifier encrypted block encrypted in advance using the platform master key. The encrypted payload is composed of topic path characters, plaintext synchronization timestamp and encrypted data block concatenated in sequence. Separate the plaintext synchronization timestamp and the ciphertext data block from the ciphertext payload; Using the authentication certificate as the decryption key, a symmetric decryption operation is performed on the identity identifier to recover the plaintext of the device's unique identifier. The device's unique identifier plaintext and the plaintext synchronization timestamp are input into the same key derivation function to generate a decryption key stream. The decryption key stream is then used to perform a bitwise XOR decryption on the ciphertext data block to obtain the legitimate state payload. Extract the original acquisition timestamp and status field from the legal state payload, calculate the difference between the original acquisition timestamp and the preset cloud clock to obtain the time difference offset, and compare the time difference offset with the preset effective time window. If the time difference offset is within the effective time window, generate a synchronization identifier. The synchronization identifier is concatenated with the status field to obtain a real-time snapshot. The real-time snapshot is then matched with a preset control logic table to obtain initial parameters. These initial parameters are then filled into a preset instruction template to obtain cloud-based instructions.

[0044] Specifically, the process of authenticating and synchronizing the IoT platform based on the secure IoT message to obtain cloud-issued instructions first involves extracting the identity identifier and encrypted payload from the received secure IoT message. The identity identifier is not the original device unique identifier, but rather a ciphertext block encrypted with the platform's master key (such as AES-128 key K0) during the device's network registration phase, with a fixed length of 16 bytes. The encrypted payload is composed of the subject path characters, plaintext synchronization timestamp, and ciphertext data blocks concatenated sequentially, located in the main body between frame delimiters. The platform compares this identity identifier with a pre-set cloud registry, which stores the encrypted identifiers of all legitimate devices and their corresponding authentication credentials—the authentication credentials being the platform's master key K0 itself or its derived subkeys. A successful match signifies successful initial access authentication.

[0045] The system parses the encrypted payload structure: According to the predefined format, the first few bytes are the UTF-8 encoded topic path (e.g., " / factory / line3 / axis5 / emergency"), followed by an 8-byte plaintext synchronization timestamp (big-endian), and the remaining part is the encrypted data block. Next, using the previously obtained authentication credential as the decryption key, an AES-128 decryption operation is performed on the identity identifier to recover the device's unique plaintext identifier (e.g., 0x123456789ABCDEF0). The plaintext synchronization timestamp extracted from the plaintext and ciphertext payloads is input into a key derivation function that is exactly the same as that on the edge side (e.g., HMAC-SHA256(key=ID, data=timestamp) truncated to the first N bytes) to generate a decryption key stream consistent with the encryption end; then the key stream is XORed byte by byte with the ciphertext data block to restore the legitimate status payload, which contains the original acquisition timestamp (from the synchronization payload in the signed timing message) and specific status fields (such as the servo position value 0x0A3F or the emergency stop trigger flag 0x01).

[0046] The platform extracts the original acquisition timestamp from the valid state payload and calculates the time difference offset Δt by subtracting it from the cloud clock maintained by the local high-stability crystal oscillator. This offset is then compared with a preset valid time window (e.g., ±2ms). If |Δt| ≤ 2ms, the state data is determined to be not expired, and a synchronization flag "1" is generated; otherwise, it is marked as invalid. The synchronization flag is concatenated with the state field (e.g., the synchronization flag occupies 1 byte, and the state field occupies 4 bytes) to form a real-time snapshot. This snapshot is used as a key-value input to a preset control logic table—configured by the process engineer. For example, the key-value [1, 0x01] (synchronization and emergency stop trigger) matches the initial parameters {target_velocity: 0, torque_limit: 0, mode: emergency_stop}. Finally, these initial parameters are filled into a standard instruction template (e.g., a JSON structure {"cmd":"set_mode","args":{...}}), encapsulated as a cloud-based instruction, and returned to the corresponding device topic via the MQTT protocol.

[0047] In a multi-axis collaborative control scenario, the position snapshot reported by a servo node is Δt=1.8ms due to network latency, which falls within the valid window. The synchronization flag is set to 1, and the position value 0x0A3F is matched with the "fine-tuning compensation" logic to generate a speed correction command. Meanwhile, another expired message (Δt=5ms) is discarded to avoid issuing erroneous commands.

[0048] In a specific embodiment, the real-time snapshot is matched with a preset control logic table using key-value matching to obtain initial parameters, including: Extract the key field descriptor of the preset control logic table, extract the corresponding key value field from the real-time snapshot, and construct a matching key; Perform a binary search between the matching key and the key-value array of the control logic table to obtain the matching index; The static control word is read from the value field array of the control logic table according to the matching index; the instruction code segment and data code segment of the static control word are extracted, and the instruction code segment and the data code segment are concatenated byte by byte to obtain the initial parameters.

[0049] Specifically, the real-time snapshot is matched with a preset control logic table using key-value pairs to obtain initial parameters. This process begins with parsing the control logic table structure: this table is loaded into memory by the configuration file when the platform starts, and it is organized as two parallel arrays—a key-value array and a value-domain array, which are strictly aligned by indexes. Each item in the key-value array corresponds to a valid state combination, while the value-domain array stores the corresponding static control words. The system first reads the key-domain descriptor of the table, which defines the position and length of the fields required for matching, for example, "byte 0: synchronization identifier (1 byte), bytes 1–4: status field (4 bytes)". Subsequently, the corresponding bytes are extracted from the real-time snapshot according to this descriptor to form a 5-byte matching key, the content of which directly reflects the valid state reported by the current device.

[0050] Since the key-value array was sorted in ascending lexicographical order during initialization (e.g., 0x0100000001, 0x0100000A3F, 0x0100000200, etc.), the system uses a binary search algorithm to locate the matching key in the array: setting the left boundary L=0 and the right boundary R=N. 1 (N is the total number of entries), iteratively calculate the midpoint M=(L+R) / 2, compare the matching key with the key-value array [M], gradually narrowing the interval until a completely equal item is found or no match is determined; if a match is found, the corresponding matching index idx is returned. This index is then used to access the value range array, from which a fixed-length static control word is read, such as an 8-byte structure, where the high 2 bytes are the instruction code segment (e.g., 0x10 represents "speed limit", 0x20 represents "emergency stop"), and the low 6 bytes are the data code segment (e.g., 0x0000000000 represents zero speed, 0x00000003E8 represents 1000rpm).

[0051] The system concatenates the instruction code segment and the data code segment in big-endian order—first writing the two bytes of the instruction code segment, and then appending the six bytes of the data code segment in sequence—to form a complete 8-byte initial parameter, which can be directly embedded into subsequent instruction templates. Taking a multi-axis servo collaborative scenario as an example, when the real-time snapshot is [synchronization identifier=0x01, status field=0x00000001] (emergency stop triggered), the matching key is 0x0100000001. The matching index is found to be 3 in the control logic table, corresponding to the static control word 0x200000000000. After disassembly, the instruction code segment 0x20 and the data code segment are all zeros. The concatenation result is the initial parameter 0x200000000000, which is used to generate the "immediate stop" command. If the status is normal position feedback 0x0A3F (decimal 2623), the matching key 0x0100000A3F may correspond to the instruction code segment 0x10 and the data code segment 0x0000000A3F, forming the speed limit fine-tuning parameter.

[0052] In a specific embodiment, such as Figure 2 As shown, the cloud-issued commands are subjected to protocol reverse parsing and timing reconstruction to obtain bus control messages, including: S41, extract the business semantic characters and logical tag addresses from the cloud-issued instructions, compare the logical tag addresses with the preset addressing mapping table by key value, and obtain the physical hardware address; S42, the business semantic characters are converted into bytes according to preset encoding rules to obtain binary raw data, and the physical hardware address is concatenated with the binary raw data to obtain the underlying control payload; S43, extract the preset local bus cycle duration and the current time value obtained from the local clock source, calculate the phase offset of the current time within the bus cycle, and use the phase offset as the time alignment deviation; S44, subtract the time alignment deviation from the local bus cycle duration to obtain the synchronization compensation delay, write the synchronization compensation delay into a preset bus frame header to obtain an offset frame header, and concatenate the offset frame header with the underlying control payload to obtain a bus control message.

[0053] Specifically, the process of performing protocol reverse parsing and timing reconstruction on the cloud-issued commands to obtain bus control messages first involves extracting business semantic characters and logical tag addresses from the received cloud-issued commands. Business semantic characters are typically in ASCII string form (e.g., "set_mode:emergency_stop"), while the logical tag address is the virtual node identifier assigned by the platform (e.g., 0x103). Subsequently, this logical tag address is used as a key to perform a comparison operation in a preset addressing mapping table. This mapping table is synchronously generated during the device registration phase and stored in the edge gateway's non-volatile memory. Its content is a static mapping relationship of {logical tag → physical hardware address}, for example, 0x103 corresponds to the physical hardware address 0x205 on the CAN bus (i.e., the CAN ID of the servo driver). Upon successful matching, the physical hardware address used for underlying communication is obtained.

[0054] The system performs byte-level conversion on business semantic characters according to preset encoding rules. These rules define the mapping method from specific semantics to binary fields. For example, "emergency_stop" is encoded as 0x02, and "velocity_limit=1000" is converted to 0x10 followed by a 4-byte integer 0x000003E8. The conversion process is implemented through table lookup or state machine, and the output is compact binary raw data. Subsequently, the previously obtained physical hardware address (such as 0x205) is placed in the frame target field position and concatenated with the binary raw data according to the protocol specification—for example, in the CAN FD format, the address occupies the ID field, and the data occupies the payload field after DLC—to form the underlying control payload.

[0055] The system reads the preset local bus cycle duration (e.g., 1ms for an industrial Ethernet TSN cycle, or 1000μs) and the current time value obtained from a local high-precision clock source (e.g., a local clock synchronized with PTP) (e.g., 1717020800123678μs). By calculating the modulo operation of the current time with respect to the bus cycle, i.e., phase offset = current time value modulo local bus cycle duration, the system obtains the offset position within the current cycle (e.g., 123678 mod 1000 = 678μs). This phase offset is considered the time alignment deviation, reflecting the lag between the instruction processing time and the next bus transmission window. To achieve precise alignment, the system subtracts this time alignment deviation, i.e., 1000, from the local bus cycle duration. 678 = 322μs, yielding the synchronization compensation delay. This value is written into a dedicated delay field in the preset bus frame header (such as EtherCAT's SyncManagers configuration register or CANopen's SYNC response offset field), forming an offset frame header. Finally, this offset frame header is concatenated byte-level with the underlying control payload to encapsulate a bus control message conforming to the physical layer specification.

[0056] Taking a multi-axis servo emergency stop scenario as an example, when the cloud-issued command contains the logical tag 0x103 and the semantic "emergency_stop", it is mapped to the physical address 0x205 and encoded as raw data 0x02. If the current time is 678μs within the cycle, the synchronization compensation delay is 322μs. After setting the frame header, it is ensured that the message is sent exactly at the beginning boundary of the next cycle. In this embodiment, the above scheme achieves precise timing reconstruction from cloud commands to deterministic bus messages through logical-physical address mapping and dynamic delay compensation based on the local clock phase. This effectively eliminates the impact of network transmission jitter on control synchronization and ensures the strict periodic consistency of the high-dynamic industrial control loop.

[0057] In a specific embodiment, time slot allocation and execution are performed on the heterogeneous bus nodes based on the bus control message to achieve device coordinated operation, including: Extract the control cycle field and node identifier sequence from the bus control message, count the number of independent nodes contained in the node identifier sequence, and obtain the total number of nodes; The candidate time slot width is obtained by calculating the quotient of the control period field divided by the total number of nodes; Extract the total byte length of the bus control message and the preset bus physical transmission rate, calculate the quotient of the total byte length of the bus control message and the bus physical transmission rate, and obtain the minimum message transmission time; The candidate timeslot width is compared with the minimum message transmission duration, and the larger of the two values ​​is taken as the base timeslot width. The node trigger time is calculated by multiplying the basic time slot width with the node sequence number of the node identifier sequence, and the node trigger time is written into the reserved offset bit of the bus control message to obtain the bandgap scheduling sequence. Extract the node trigger time and control instruction byte of the bandgap scheduling sequence, and compare the node trigger time with the current count value of the preset local hardware clock to obtain the time slot matching pulse; Based on the time slot matching pulse, the control instruction byte is converted from digital to analog to obtain a physical drive waveform, and the physical drive waveform is injected into the hardware execution port of the heterogeneous bus node to realize the device cooperative operation state.

[0058] Specifically, based on the bus control message, time slot allocation and execution are performed on the heterogeneous bus nodes to achieve coordinated device operation. This process begins with parsing the message structure: the system first extracts the control cycle field (e.g., 1000μs) and the subsequent node identifier sequence from the bus control message. This sequence lists the logical IDs of all target nodes in a compact array, such as [0x205, 0x206, 0x207]. Then, the system iterates through this sequence, counting the number of unique nodes, resulting in a total node count N=3. Next, the control cycle field is divided by the total number of nodes, i.e., 1000μs ÷ 3 ≈ 333.33μs, which is rounded down to obtain a candidate time slot width of 333μs.

[0059] The system reads the total byte length of the bus control message (including frame header, address, instruction, and checksum, e.g., 48 bytes) and the preset bus physical transmission rate (e.g., 2 Mbps for CAN FD, i.e., 2 × 10⁻⁶ bytes per second). 6 To calculate the minimum message transmission time, first convert the bytes to bits (48 × 8 = 384 bits), then divide by the rate to get 384 ÷ 2 × 10. 6 = 192μs. This value represents the shortest time required for the physical layer to send a complete frame and cannot be compressed. Subsequently, the candidate time slot width (333μs) is compared with the minimum message transmission time (192μs), and the larger value of 333μs is taken as the base time slot width to ensure that each node has enough time to complete reception and processing and avoid time slot overlap.

[0060] The system iterates through the node identifier sequence. For the i-th node (i starts counting from 0), its node number i is multiplied by the base timeslot width to obtain the node trigger time T_i = i × 333μs; for example, the trigger time for node 0 is 0μs, for node 1 it is 333μs, and for node 2 it is 666μs. These times are written into the reserved offset field in the bus control message (usually located in the extended frame header or dedicated scheduling segment), forming a bandgap scheduling sequence. This sequence not only contains control instruction bytes but also embeds precise time trigger information.

[0061] The edge controller continuously reads the current count value of the local hardware clock (driven by a high-stability crystal oscillator, with a resolution of 1μs) and compares this value with the node trigger time of each node in the bandgap scheduling sequence. When the local count value equals the trigger time of a certain node, a single-cycle high-level signal is immediately generated, which is the time slot matching pulse. This pulse serves as an enable signal, triggering the corresponding channel's digital-to-analog converter module: the control instruction byte (such as 0x02 indicating an emergency stop) is sent to the DAC circuit and converted into a standard industrial voltage signal (such as 0–10V or ±5V), forming a physical drive waveform. After power amplification, this waveform is injected into the hardware execution port of the heterogeneous bus node (such as a servo driver, PLC I / O module, or pneumatic valve island) to drive it to perform corresponding actions.

[0062] In the aforementioned multi-axis emergency stop scenario, the three servo axes received synchronous stop waveforms at 0μs, 333μs, and 666μs, respectively. Although there were microsecond-level peaks, all of them completed their actions within a 1ms control cycle, avoiding bus conflicts and maintaining mechanical coordination.

[0063] In a specific embodiment, the physical drive waveform is injected into the hardware execution port of the heterogeneous bus node to achieve a device cooperative operation state, including: Extract the load impedance of the hardware execution port, and perform bias compensation on the physical drive waveform based on the load impedance to obtain the hard injection waveform; The preset global synchronization clock is phase-aligned with the hard-injected waveform to obtain the synchronization drive waveform; The hardware execution port is driven based on the synchronous drive waveform to obtain the underlying execution level, and the underlying execution level is logically latched with a preset cooperative instruction to obtain a device trigger signal; The device trigger signal is input to a preset device actuator for physical drive to obtain the device's coordinated action state.

[0064] Specifically, the physical drive waveform is injected into the hardware execution port of the heterogeneous bus node to achieve coordinated device operation. The specific implementation process first involves adapting the electrical characteristics of the execution link: the system reads the load impedance parameter from the register or configuration storage area of ​​the hardware execution port. This parameter characterizes the equivalent impedance value of the connected actuator (such as a servo motor winding, solenoid valve coil, or relay contact) at its static operating point, for example, 120Ω ± 5%. Subsequently, based on this load impedance, bias compensation is applied to the aforementioned generated physical drive waveform—the compensation strategy is preset according to Ohm's law and the output characteristic curve of the drive amplifier. If the load impedance is too low, resulting in excessive voltage drop, a positive bias voltage (such as +0.3V) is superimposed on the waveform reference level to offset line losses; otherwise, negative compensation is applied. After this adjustment, the output hard-injected waveform can accurately reproduce the target amplitude when it reaches the execution port, avoiding insufficient drive or overshoot due to impedance mismatch.

[0065] To ensure strict time alignment of multi-node actions, the system invokes a preset global synchronization clock signal (distributed by the master station via IEEE 1588 PTP or a hardware SYNC line, with jitter less than ±50ns) to phase-align the rising edge or critical transition point of the hard-injected waveform with the period boundary of the global synchronization clock. Specifically, the waveform output timing is fine-tuned through a programmable delay unit (such as the IODELAY module in an FPGA) to control the alignment error between the trigger edge of the hard-injected waveform and the rising edge of the synchronization clock within one clock cycle (e.g., 10ns@100MHz). The aligned signal is the synchronous drive waveform, and its timing reference is consistent with the entire production line control system.

[0066] The synchronous drive waveform is fed into the power drive circuit (such as an H-bridge or MOSFET array), driving the hardware execution port to generate a low-level execution level—for example, converting a 0–10V analog signal into a 24V digital enable signal, or generating the average voltage corresponding to the PWM duty cycle. This low-level execution level does not directly trigger the action, but rather performs a logical latching operation with a preset coordination instruction (a logical flag issued from the cloud and cached in the local coprocessor, such as "three-axis synchronous emergency stop"). The latch only outputs a high level when the coordination instruction is valid and the low-level execution level reaches a threshold (such as >20V), forming a device trigger signal. This prevents malfunctions due to single-point interference or local faults, ensuring that the action triggering has dual condition constraints.

[0067] The equipment trigger signal is fed into a preset equipment actuator—such as the Enable pin of a servo driver, the solenoid coil of a pneumatic valve, or the brake release circuit of a robotic arm joint—driving it to complete a physical response. In the aforementioned multi-axis emergency stop scenario, the actuators of the three axes receive the trigger signal, which has been impedance compensated, clock aligned, and logic latched, within their respective time slots. They almost simultaneously cut off the power output and activate the mechanical brake, forming a coordinated emergency stop state.

Claims

1. An industrial bus IoT collaborative control method, applied to a control system comprising heterogeneous bus nodes and an IoT platform, characterized in that, include: Protocol features are extracted and clock synchronization is performed on the heterogeneous bus nodes to obtain standard timing messages. Period calculation and priority sorting are performed on the standard timing messages to obtain hierarchical data queues. The hierarchical data queue is encrypted and encapsulated with topic mapping to obtain a secure IoT message; Based on the secure IoT message, the IoT platform is connected for authentication and status synchronization, and instructions are sent from the cloud. The cloud-issued commands are subjected to protocol reverse parsing and timing reconstruction to obtain bus control messages; Based on the bus control messages, time slots are allocated and executed for the heterogeneous bus nodes to achieve coordinated device operation.

2. The industrial bus IoT collaborative control method according to claim 1, characterized in that, The process of extracting protocol features and synchronizing the clock on the heterogeneous bus nodes to obtain standard timing messages includes: The original data stream of the heterogeneous bus node is obtained and the frame header is delimited and the bit width is truncated to obtain the protocol field sequence; Data field extraction and checksum comparison are performed on the protocol field sequence to obtain payload data; the timestamp field in the payload data is extracted, and it is calculated whether there is a clock offset between the timestamp field and the local reference clock. If it exists, the payload data is timestamped based on the clock offset to obtain synchronized payload data; The synchronous payload data is concatenated and filled with fields of a preset unified frame format to obtain a standard timing message.

3. The industrial bus IoT collaborative control method according to claim 1, characterized in that, The standard time-series messages are periodically calculated and prioritized to obtain a hierarchical data queue, including: Extract the consecutive timestamps and service attribute bits of the standard time sequence message, calculate the difference between adjacent consecutive timestamps, and obtain the message arrival interval; Calculate the statistical variance of the message arrival interval within a preset time window, and divide the statistical variance by the square of the mean of the message arrival intervals within the time window to obtain the normalized burst index. The business attribute bits are compared with the preset mapping table to obtain the basic business weights. The reciprocal of the sum of the normalized burst index and the preset constant 1 is calculated to obtain the stability coefficient. The product of the basic business weights and the stability coefficient is calculated to obtain the dynamic scheduling base. The dynamic scheduling base is compared with the preset dimensionless hierarchical division threshold to obtain the priority label. The priority label is written into the reserved field of the standard time sequence message to obtain the signed time sequence message. Based on the value of the priority tag, the tagged time-series message is allocated to the corresponding independent buffer block, and the independent buffer blocks are concatenated to obtain a hierarchical data queue.

4. The industrial bus IoT collaborative control method according to claim 3, characterized in that, Based on the value of the priority tag, the tagged time-series message is allocated to the corresponding independent buffer block, and the independent buffer blocks are concatenated to obtain a hierarchical data queue, including: The priority tag in the signed timing message is compared with the preset hardware address mapping table to obtain the isolated memory base address; Based on the isolated memory base address, the signed time-series message is directly written to memory to obtain an independent cache block; Extract the first and last memory pointers of the independent cache block, and reconstruct the first and last memory pointers into a hardware linked list in descending order of the priority label value to obtain the scheduling pointer chain; The scheduling pointer chain is bound to a preset sending port descriptor to obtain a hierarchical data queue.

5. The industrial bus IoT collaborative control method according to claim 1, characterized in that, The hierarchical data queue is encrypted and encapsulated, and a topic is mapped to obtain a secure IoT message, including: Extract the queue metadata of the hierarchical data queue. The queue metadata includes at least a priority label, a unique device identifier, a data service type code, and a plaintext synchronization timestamp. The plaintext synchronization timestamp is the system clock value at the time the hierarchical data queue is generated or a unified reference time associated with the collection time of the first message in the hierarchical data queue. The device's unique identifier and the plaintext synchronization timestamp are input into the key derivation function in a preset concatenation order to generate the dynamic key bitstream used for this encryption. The ciphertext data block is obtained by performing a bitwise XOR operation between the byte stream to be encrypted in the hierarchical data queue and the dynamic key bit stream. The priority tag is combined with the data service type code to form a topic key value. The topic key value is compared with a preset cloud topic mapping table to obtain the topic path characters. The topic path characters, the plaintext synchronization timestamp, and the ciphertext data block are sequentially concatenated byte by byte to form the payload to be encapsulated. A preset frame delimiter is then appended to both ends of the payload to be encapsulated to obtain a secure IoT message.

6. The industrial bus IoT collaborative control method according to claim 1, characterized in that, Based on the secure IoT message, the IoT platform is authenticated and its status synchronized to obtain instructions from the cloud, including: Extract the identity identifier and encrypted payload of the secure IoT message, compare the identity identifier with the preset cloud registry to obtain the authentication certificate. The identity identifier is a device unique identifier encrypted block encrypted in advance using the platform master key. The encrypted payload is composed of topic path characters, plaintext synchronization timestamp and encrypted data block concatenated in sequence. Separate the plaintext synchronization timestamp and the ciphertext data block from the ciphertext payload; Using the authentication certificate as the decryption key, a symmetric decryption operation is performed on the identity identifier to recover the plaintext of the device's unique identifier. The device's unique identifier plaintext and the plaintext synchronization timestamp are input into the same key derivation function to generate a decryption key stream. The decryption key stream is then used to perform a bitwise XOR decryption on the ciphertext data block to obtain the legitimate state payload. Extract the original acquisition timestamp and status field from the legal state payload, calculate the difference between the original acquisition timestamp and the preset cloud clock to obtain the time difference offset, and compare the time difference offset with the preset effective time window. If the time difference offset is within the effective time window, generate a synchronization identifier. The synchronization identifier is concatenated with the status field to obtain a real-time snapshot. The real-time snapshot is then matched with a preset control logic table to obtain initial parameters. These initial parameters are then filled into a preset instruction template to obtain cloud-based instructions.

7. The industrial bus IoT collaborative control method according to claim 6, characterized in that, The real-time snapshot is matched with a preset control logic table using key-value matching to obtain initial parameters, including: Extract the key field descriptor of the preset control logic table, extract the corresponding key value field from the real-time snapshot, and construct a matching key; Perform a binary search between the matching key and the key-value array of the control logic table to obtain the matching index; The static control word is read from the value field array of the control logic table according to the matching index; the instruction code segment and data code segment of the static control word are extracted, and the instruction code segment and the data code segment are concatenated byte by byte to obtain the initial parameters.

8. The industrial bus IoT collaborative control method according to claim 1, characterized in that, The cloud-issued commands are subjected to protocol reverse parsing and timing reconstruction to obtain bus control messages, including: Extract the business semantic characters and logical tag addresses from the cloud-issued instructions, compare the logical tag addresses with the preset addressing mapping table by key value, and obtain the physical hardware address; The business semantic characters are converted into bytes according to preset encoding rules to obtain binary raw data. The physical hardware address is then concatenated with the binary raw data to obtain the underlying control payload. Extract the preset local bus cycle duration and the current time value obtained from the local clock source, calculate the phase offset of the current time within the bus cycle, and use the phase offset as the time alignment deviation. Subtract the time alignment deviation from the local bus cycle duration to obtain the synchronization compensation delay. Write the synchronization compensation delay into a preset bus frame header to obtain an offset frame header. Concatenate the offset frame header with the underlying control payload to obtain a bus control message.

Images