Multi-module parallel upgrading system and method of Internet of Things equipment

Abstract

The invention belongs to the field of Internet of Things, and provides an Internet of Things equipment multi-module parallel upgrading system and method. The system comprises a cloud server, a gateway and Internet of Things equipment, the gateway is configured to expand a multiplexing frame structure based on a YMODEM protocol and convert communication information between the cloud server and the Internet of Things equipment; the cloud server is configured to receive the state of each heterogeneous module reported by the gateway, then dynamically distribute a transmission sequence of an upgrading program, generate a compression difference packet of each heterogeneous module according to the upgrading program, and correspondingly issue the compression difference packet of each heterogeneous module according to the transmission sequence; the Internet of Things equipment is configured to receive a compression difference packet of a plurality of heterogeneous modules and temporarily store the compression difference packet to a backup area; and comparing the verification value of the firmware upgrading information in the upgrading program, and after confirming that the data is correct, decompressing the compressed difference packet and writing the upgrading program into the firmware.

Description

Technical Field

[0001] The present invention belongs to the field of Internet of Things, and in particular relates to a system and method for parallel upgrading of multiple modules of Internet of Things devices. Background Art

[0002] The statements in this section merely provide background information related to the present invention and do not necessarily constitute prior art.

[0003] The YMODEM protocol is a file transfer protocol used for serial communications, particularly between embedded systems and computers. While the existing YMODEM protocol supports 1024-byte packet transmission, multiple modules require serial upgrades, which is significantly time-consuming (e.g., total upgrade time for four modules = time for a single module × 4). Furthermore, when multiple modules initiate upgrade requests simultaneously, network bandwidth contention and memory access conflicts (such as flash memory erase / write conflicts) can occur, increasing the upgrade failure rate. Furthermore, YMODEM's CRC check only checks single-packet data and lacks a cross-module version consistency verification mechanism, potentially leading to firmware incompatibility issues across multiple modules.

[0004] In summary, the current YMODEM protocol is not suitable for the scenario of parallel firmware upgrade of multiple modules. Summary of the Invention

[0005] In order to solve the technical problems existing in the above-mentioned background technology, the present invention provides a multi-module parallel upgrade system and method for IoT devices, which collaborates with the IoT cloud platform and communication gateway based on the YMODEM protocol to realize multi-module parallel firmware upgrade.

[0006] In order to achieve the above object, the present invention adopts the following technical solutions: A first aspect of the present invention provides a multi-module parallel upgrade system for Internet of Things devices.

[0007] A multi-module parallel upgrade system for IoT devices, comprising: Cloud servers, gateways, and IoT devices; The gateway is configured to: convert communication information between the cloud server and the IoT device based on the YMODEM protocol extended multiplexing frame structure; The cloud server is configured to: receive the status of each heterogeneous module reported by the gateway, dynamically allocate the transmission order of the upgrade program, generate compressed differential packages for each heterogeneous module based on the upgrade program, and issue the compressed differential packages to each heterogeneous module according to the transmission order; The IoT device is configured to: receive compressed differential packages of multiple heterogeneous modules and temporarily store them in a backup area; compare the checksum of the firmware upgrade information in the upgrade program, and after confirming that the data is correct, decompress the compressed differential package and write the upgrade program into the firmware.

[0008] As an implementation method, the YMODEM protocol-based extended multiplexing frame structure is: |Channel identifier|YMODEM standard frame header|Packet sequence number|Inverter of packet sequence number|Data segment|Arithmetic checksum|.

[0009] As an embodiment, the IoT device is further configured to: synchronously decompress the differential packet and accelerate data reading using a separate dual-port RAM structure; the boot area firmware writes the differential row of each heterogeneous module into the application area according to the address based on the differential table.

[0010] As an implementation method, the IoT device is further configured to: uniformly switch to the new firmware after writing is completed; if it fails midway, retain the old version.

[0011] As an implementation method, in the cloud server, the LZO algorithm is used to generate differential packages for each module from the upgrade program.

[0012] As an implementation manner, in the gateway, the STX / SOH switching threshold is dynamically adjusted by monitoring the frequency of data transmission failures in each channel.

[0013] As an implementation method, in the gateway, channel identifiers are dynamically allocated according to the IDs of the modules to implement time-division multiplexing transmission of data packets of the modules.

[0014] A second aspect of the present invention provides a method for parallel upgrading of multiple modules of an Internet of Things device.

[0015] A method for parallel upgrading of multiple modules of an IoT device, comprising: The cloud server receives the status of each heterogeneous module reported by the gateway, and then dynamically allocates the transmission order of the upgrade program. The upgrade program generates compressed differential packages for each heterogeneous module and sends the compressed differential packages of each heterogeneous module according to the transmission order and sends them to the IoT device through the gateway; The gateway converts the communication information between the cloud server and the IoT device based on the YMODEM protocol extended multiplexing frame structure; The IoT device receives compressed differential packages from multiple heterogeneous modules and temporarily stores them in a backup area. It compares the checksum of the firmware upgrade information in the upgrade program, confirms that the data is correct, decompresses the compressed differential package, and writes the upgrade program into the firmware.

[0016] As an implementation method, the IoT device also synchronously decompresses the differential package and uses a separate dual-port RAM structure to accelerate data reading; the boot area firmware writes the differential row of each heterogeneous module into the application area according to the address based on the differential table.

[0017] As an implementation method, after writing is completed, the new firmware is switched to uniformly. If it fails midway, the old version is retained.

[0018] The beneficial effects of the present invention are: The gateway of the present invention utilizes an extended multiplexing frame structure based on the YMODEM protocol to convert communication information between a cloud server and an IoT device. The cloud server generates compressed differential packets for each heterogeneous module using an upgrade program and sends the compressed differential packets for each heterogeneous module in a corresponding order of transmission, thereby realizing multi-module parallel upgrades of IoT devices and improving the upgrade efficiency of IoT devices.

[0019] Advantages of additional aspects of the present invention will be given in part in the following description and in part will be obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The accompanying drawings, which constitute a part of the present invention, are used to provide a further understanding of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute improper limitations on the present invention.

[0021] Figure 1 This is a schematic diagram of the structure of a multi-module parallel upgrade system for IoT devices according to an embodiment of the present invention; Figure 2 This is a flow chart of a method for parallel upgrading of multiple modules of an IoT device according to an embodiment of the present invention; Figure 3 4 is a comparison chart of the effects of the embodiments of the present invention. DETAILED DESCRIPTION

[0022] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0023] It should be noted that the following detailed descriptions are illustrative and intended to provide further explanation of the present invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which the present invention belongs.

[0024] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit the exemplary embodiments according to the present invention. As used herein, unless the context clearly indicates otherwise, the singular form is intended to include the plural form. In addition, it should be understood that when the terms "comprise" and / or "include" are used in this specification, they indicate the presence of features, steps, operations, devices, components and / or combinations thereof.

[0025] The present invention belongs to the technical field of firmware upgrade for IoT devices, and specifically relates to a method and system for collaboratively implementing multi-module parallel firmware upgrades by an IoT cloud platform and a communication gateway based on the YMODEM protocol. The method and system are suitable for synchronous differential upgrade scenarios of multiple heterogeneous modules (such as communication modules, sensor modules, main control MCU modules, and security chip modules) in smart terminal devices.

[0026] Combine Figure 1 and Figure 2 , an embodiment of the present invention provides a multi-module parallel upgrade system for an Internet of Things device, which includes: Cloud servers, gateways, and IoT devices; The gateway is configured to: convert communication information between the cloud server and the IoT device based on the YMODEM protocol extended multiplexing frame structure; The cloud server is configured to: receive the status of each heterogeneous module reported by the gateway, dynamically allocate the transmission order of the upgrade program, generate compressed differential packages for each heterogeneous module based on the upgrade program, and issue the compressed differential packages to each heterogeneous module according to the transmission order; The IoT device is configured to: receive compressed differential packages of multiple heterogeneous modules and temporarily store them in a backup area; compare the checksum of the firmware upgrade information in the upgrade program, and after confirming that the data is correct, decompress the compressed differential package and write the upgrade program into the firmware.

[0027] In the gateway, based on the YMODEM protocol extended time-division multiplexing frame structure, multiple virtual transmission channels are created within a single physical channel (for example, four virtual transmission channels are created corresponding to four modules), |channel identifier|YMODEM standard frame header|packet sequence number|inverse code of the packet sequence number|data segment|arithmetic checksum|.

[0028] The channel identifiers of all the following data communication processes are not repeated here. Two-digit channel identifiers are added before each message header to achieve multi-channel data interactive parallel transmission without being affected by single-channel serial results.

[0029] In this embodiment, the data frame structure adopts the following structure:

[0030] Among them, the protocol header: SOH=0x01, indicating that this data frame contains 128 bytes of data; STX represents 1024 bytes of data; Frame number, frame number complement: indicates the number of frames transmitted. If it is greater than 0xFF, it will restart from 0x00. The complement is to ensure the correctness of the transmission. File name: The file name to be transferred, ending with '\0'; File size: The size of the file to be transferred, expressed as a string, immediately following the file name. For example, if you want to transfer a file of 1234 bytes, then it is: 0x31 0x32 0x33 0x34 0x00; Empty: remove the file name and file size, and fill the remaining data with 0; CRC high 8 bits: high 8 bits of CRC-16 check data; CRC lower 8 bits: the lower 8 bits of the CRC-16 check data.

[0031] In this embodiment, the data transmission process is as follows:

[0032] The remaining data in the last frame is greater than 128 bytes: 1024 bytes of STX are used for transmission, but the remaining space is filled with 0x1A (Ctrl-Z); The remaining data of the last frame is equal to 128 bytes: 128 bytes of SOH are used for transmission; The remaining data in the last frame is less than 128 bytes: 128 bytes of SOH are used for transmission, but the remaining space is filled with 0x1A (Ctrl-Z).

[0033] In this embodiment, the structure of the tail frame is:

[0034] In this embodiment, in the process of sending the compressed difference packages of each heterogeneous module to each other according to the transmission order, a multi-file continuous transmission method is adopted, and the specific process is as follows: Step 1. The receiver sends C to the sender, telling the sender that data transmission can begin. After receiving C for the first time, the receiver will transmit the file name and file size information. Step 2. After the receiver sends C to the sender for the second time, the file content transmission officially begins; Step 3. When the receiver receives the correct data, it returns an ACK (Acknowledge character). If it is incorrect, it returns a NAK (Negative Acknowledgment). At this time, the sender will resend the previous data. Step 4. When the file transfer is complete, the sender sends an EOT (end-of-transmission). The receiver should return a NAK the first time it receives an EOT. If it receives an EOT again, it should return an ACK. This ensures that the file transfer is complete and not other interfering data. Step 5. After receiving a file, the receiver sends C to the sender again. If the sender has files to send, it sends a SOH frame with the file name and size. If the sender has no files to send, it sends an SOH data frame with 128 bytes of data all 0x00.

[0035] In the gateway, channel identifiers (00 / 01 / 10 / 11) are dynamically allocated based on the module ID to achieve time-division multiplexing transmission of four-module data packets, increasing bandwidth utilization by 40%.

[0036] In some optional embodiments, a heterogeneous module collaborative verification mechanism is used to implement consistency verification between the cloud and device firmware. Specifically, based on the standard YMODEM CRC check, a cross-module version hash tree check is added: a Merkle tree root hash containing the firmware version numbers of the four modules is generated and embedded in the padding area of ​​the start frame (the original 0x00 padding area is changed to store the hash value); After receiving all module data, the IoT device compares the locally calculated hash tree with the cloud value to ensure the global consistency of multi-module firmware versions.

[0037] Suppose a terminal device contains four heterogeneous modules, each module can be upgraded independently, and each module has an independent firmware version number. According to the traditional serial upgrade mode, the consistency of the four module version numbers cannot be guaranteed. Therefore, the hash value of the four module version numbers can be added during the initial communication with the device. When the device receives the hash value, it can verify the version numbers of the four modules at the same time to achieve consistency verification between the cloud and the device firmware. If the hash is consistent, the upgrade can be rejected.

[0038] The data frame structure used in the heterogeneous module collaborative verification mechanism to implement consistency verification between the cloud and device firmware is explained as follows:

[0039] The data structure construction principle of the tree root hash in the embodiment is: Leaf node initialization: Take the four device version numbers (denoted as V1, V2, V3, and V4) as leaf nodes, and generate the corresponding hash value for each version number using a hash algorithm (such as SHA-256): H1 = Hash(V1) H2 = Hash(V2) H3 = Hash(V3) H4 = Hash(V4) Function: Ensure the uniqueness and tamper-proofness of each version number.

[0040] Parent node generation: The hash values ​​of adjacent leaf nodes are combined in pairs and then hashed twice to form the parent node of the previous layer: First-level parent node: H12 = Hash(H1 + H2) H34 = Hash(H3 + H4) Second-level parent node (root node): Root = Hash(H12 + H34) Logic: By recursively merging hash values, a tree structure is generated layer by layer, and finally a unique Merkle root hash is obtained.

[0041] Balance processing: If the number of leaf nodes is odd (for example, 5 version numbers), the last hash value needs to be copied to form an even-numbered node, for example, H5 = H4, and then the merge calculation is performed.

[0042] This embodiment uses the tree root hash, which has the following advantages: (1) Tamper resistance: Any modification of the version number (e.g. V1 → V1') will cause its hash value H1 to change, which in turn affects H12 and Root layer by layer. Data integrity can be quickly detected by comparing the root hash; (2) Efficient verification path: If you need to verify whether a device version number (such as V3) belongs to the current Merkle tree, you only need to provide the adjacent hash path (H4, H12) and the root hash to reconstruct the verification chain without traversing all the data.

[0043] The root hash is a unique summary of all version numbers and has the following characteristics: Fixed length: Regardless of the amount of input data, the root hash length remains constant (e.g., 256 bits for SHA-256).

[0044] Uniqueness: Different version number combinations will inevitably generate different root hashes (collision resistance).

[0045] In one or more embodiments, in the cloud server, the LZO algorithm is used to generate differential packages for each module from the upgrade program.

[0046] LZO uses a dictionary-based sliding window algorithm to detect repeated strings and replace the original data with tuples (repetition length L, back-pointing distance D). For example, the string "ABCDEFGHABCDEF" is compressed into the format "(08)hABCDEFGH(6,8)", achieving high compression speed (approximately five times that of traditional algorithms) and lossless real-time compression. The compressed data is encoded in a specific format, supporting fast decompression without requiring additional memory. The data is divided into independent compressed blocks, supporting parallel compression / decompression, and is suitable for distributed scenarios (such as four modules processing in parallel).

[0047] In the specific implementation process, in the cloud server, the transmission order of the upgrade program is dynamically allocated according to the status of each heterogeneous module reported by the gateway: Assume that four modules of the same device are upgraded in parallel. The data interaction with each module is distinguished based on the channel identifier. Assume that the identifier of module 1 is 01, the identifier of module 2 is 02, the identifier of module 3 is 11, and the identifier of module 4 is 12. During an upgrade, assuming the cloud platform collects device information once a minute, including the RAM and Flash resource allocations for the four modules, the cloud server can prioritize the upgrade based on the module's current resource allocation. For example, if modules 2 and 4 have better resources and signals during the first update, the firmware for these modules will be upgraded first. Specifically, data for channel identifiers 02 and 12 will be sent first. One minute later, the module information collected by the cloud server is updated, and the transmission order is dynamically adjusted based on the latest information.

[0048] In the gateway, the STX / SOH switching threshold is dynamically adjusted by monitoring the NAK frequency of each channel (automatically downgraded to 128B packets when network latency is low): Among them, NAK 0x15 / / Does not recognize the response (receiver only).

[0049] The process of monitoring the NAK frequency of each channel and dynamically adjusting the STX / SOH switching threshold is implemented by the device's NAK response code during data exchange. The reply to this code is used to address blocking factors such as device failure to receive data, incomplete received data, packet unpacking and sticking caused by network fluctuations, reception timeouts, and triggering the breakpoint resume mechanism.

[0050]

[0051] Protocol header: SOH=0x01, indicating that this data frame contains 128 bytes of data, STX represents 1024 bytes of data; Frame number, frame number complement: indicates the number of frames transmitted. If it is greater than 0xFF, it will restart from 0x00. The complement is to ensure the correctness of the transmission. File name: The file name to be transferred, ending with '\0'; File size: The size of the file to be transferred, expressed as a string, immediately following the file name. For example, if you want to transfer a file of 1234 bytes, then it is: 0x31 0x32 0x33 0x34 0x00; Empty: remove the file name and file size, and fill the remaining data with 0; CRC high 8 bits: high 8 bits of CRC-16 check data; CRC low 8 bits: low 8 bits of CRC-16 check data.

[0052] When the frequency of failure of the device to receive data increases, that is, the frequency of NAK uploaded by the device is high, the packet size of the file issued dynamically can be changed from 1024 bytes to 128 bytes: that is, the protocol header is changed from STX to SOH, the size of each packet is reduced, and the number of packets is increased, so as to improve the transmission success rate, resist external influences such as network fluctuations, and realize adaptive flow control.

[0053] Compared with the total time of four-module upgrade, the peak value of network bandwidth occupation, the failure rate of version consistency and the recovery time of breakpoint resume of the conventional single-channel YMODEM, the indicators of the present application are all better than those of the conventional single-channel YMODEM, as shown in the following table. Figure 3

[0054] Embodiment 1 (difference packet generation scenario): When the master MCU module needs to be upgraded from V2.1 to V2.3: The cloud platform calls the BSDiff algorithm to generate a difference packet (only containing 367 bytes of modified data), and adds a module ID identifier 0x01 in the header of the difference packet; The difference packet is embedded in an extended YMODEM start frame, and the file name field is in the format "MCU_V2.1→V2.3.bin".

[0055] Embodiment 2 (network jitter response): If the sensor module (channel 3) receives a NAK for three consecutive times; The gateway automatically switches to the SOH mode (128B / packet), and adds RS error correction code at the end of the data area; After completing the transmission, the RS code is compared to repair possible bit errors.

[0056] In some other embodiments, in the gateway, a dynamic priority retransmission queue is also designed, when a certain module fails to transmit: The missing packet position is quickly located through the packet number inverse code (such as triggering retransmission when the received packet inverse code ≠ 255-packet number); The retransmission priority is set according to the criticality of the module function (such as communication module > master module > sensor module), to ensure that the core function is restored first.

[0057] In the present embodiment, the difference comparison has the following advantages: row-level difference extraction: the current firmware and the new firmware are compared by 16 bytes per row to generate a difference row set. The difference rows are sorted by address to form the original difference packet. ​This embodiment uses parallel module allocation: four modules process different areas of the firmware (such as the boot area, application area, backup area, etc.), and each module independently generates corresponding differential blocks; and a block tag dictionary structure is used to avoid the time-consuming problem of traditional initialization. The current and historical data blocks are distinguished by identifiers (such as 0 / 1), reducing RAM write-zero operations.

[0058] In this embodiment, differential packet encoding and compression has the following advantages: structured packaging; firmware differential table: using BIT bits to mark the difference row position (such as BIT bit 0 represents the difference in the first row) to ensure the accuracy of the write address; compression format: the differential packet of each module is encapsulated into a fixed-length data packet after LZO compression, which is convenient for bus transmission; enhanced security: adding a total check value (such as CRC32) to the differential data to prevent transmission errors.

[0059] The IoT scenario adaptation of the embodiments of the present invention has the following advantages: (1) Low resource consumption: Compression requires only 64KB of memory and decompression has almost zero CPU overhead, making it suitable for embedded devices; (2) High compression rate: The average compression rate is about 50%, which significantly reduces the amount of transmitted data; (3) Adjustable parameters: support the balance between compression rate and speed, for example, high-level compression optimizes bandwidth, and low-level compression saves memory.

[0060] In one or more embodiments, a method for concurrently upgrading multiple modules of an IoT device includes: The cloud server receives the status of each heterogeneous module reported by the gateway, and then dynamically allocates the transmission order of the upgrade program. The upgrade program generates compressed differential packages for each heterogeneous module and sends the compressed differential packages of each heterogeneous module according to the transmission order and sends them to the IoT device through the gateway; The gateway converts the communication information between the cloud server and the IoT device based on the YMODEM protocol extended multiplexing frame structure; The IoT device receives compressed differential packages from multiple heterogeneous modules and temporarily stores them in a backup area. It compares the checksum of the firmware upgrade information in the upgrade program, confirms that the data is correct, decompresses the compressed differential package, and writes the upgrade program into the firmware.

[0061] The IoT device also synchronously decompresses the differential package and uses a separate dual-port RAM structure to accelerate data reading; the boot area firmware writes the differential row of each heterogeneous module into the application area according to the address based on the differential table.

[0062] Among them, when writing is completed, it is uniformly switched to the new firmware. If it fails midway, the old version is retained.

[0063] The foregoing description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Those skilled in the art will readily appreciate that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention are intended to be within the scope of protection of the present invention.

Claims

1. A multi-module parallel upgrade system for IoT devices, characterized in that: include: Cloud servers, gateways, and IoT devices; The gateway is configured to: convert communication information between the cloud server and the IoT device based on the YMODEM protocol extended multiplexing frame structure; The cloud server is configured to: receive the status of each heterogeneous module reported by the gateway, dynamically allocate the transmission order of the upgrade program, generate compressed differential packages for each heterogeneous module based on the upgrade program, and issue the compressed differential packages to each heterogeneous module according to the transmission order; The IoT device is configured to: receive compressed differential packets from multiple heterogeneous modules and temporarily store them in a backup area; Compare the checksum of the firmware upgrade information in the upgrade program. After confirming that the data is correct, decompress the compressed difference package and write the upgrade program to the firmware.

2. The multi-module parallel upgrade system for IoT devices according to claim 1, wherein: The extended multiplexing frame structure based on the YMODEM protocol is: |Channel identifier|YMODEM standard frame header|Packet sequence number|Inverter of packet sequence number|Data segment|Arithmetic checksum|.

3. The multi-module parallel upgrade system for IoT devices according to claim 1, wherein: The IoT device is further configured to: synchronously decompress the differential packet and accelerate data reading using a separate dual-port RAM structure; and the boot area firmware writes the differential row of each heterogeneous module into the application area according to the address based on the differential table.

4. The multi-module parallel upgrade system for IoT devices according to claim 1, wherein: The IoT device is further configured to uniformly switch to the new firmware upon completion of writing, and retain the old version if writing fails midway.

5. The multi-module parallel upgrade system for IoT devices according to claim 1, wherein: In the cloud server, the LZO algorithm is used to generate differential packages for each module from the upgrade program.

6. The multi-module parallel upgrade system for IoT devices according to claim 1, wherein: In the gateway, the STX / SOH switching threshold is dynamically adjusted by monitoring the frequency of data transmission failure in each channel.

7. The multi-module parallel upgrade system for IoT devices according to claim 1, wherein: In the gateway, channel identifiers are dynamically allocated according to the IDs of the modules to implement time-division multiplexing transmission of data packets from the modules.

8. A method for parallel upgrading of multiple modules of an Internet of Things device, characterized in that: include: The cloud server receives the status of each heterogeneous module reported by the gateway, and then dynamically allocates the transmission order of the upgrade program. The upgrade program generates compressed differential packages for each heterogeneous module and sends the compressed differential packages of each heterogeneous module according to the transmission order and sends them to the IoT device through the gateway; The gateway converts the communication information between the cloud server and the IoT device based on the YMODEM protocol extended multiplexing frame structure; The IoT device receives compressed differential packets from multiple heterogeneous modules and temporarily stores them in the backup area; Compare the checksum of the firmware upgrade information in the upgrade program. After confirming that the data is correct, decompress the compressed difference package and write the upgrade program to the firmware.

9. The method for parallel upgrading of multiple modules of an Internet of Things device according to claim 8, wherein: The IoT device also synchronously decompresses the differential package and uses a separate dual-port RAM structure to accelerate data reading; the boot area firmware writes the differential row of each heterogeneous module into the application area according to the address based on the differential table.

10. The method for parallel upgrading of multiple modules of an Internet of Things device according to claim 8, wherein: When writing is completed, switch to the new firmware. If it fails midway, the old version will be retained.

Images