OTA program upgrading method and device, electronic equipment and storage medium

Abstract

The invention provides an OTA program upgrading method and device, electronic equipment and a storage medium. The method comprises the following steps: sending an upgrading request to a cloud by a to-be-upgraded device, loading a current network quality parameter, dynamically generating a fragmentation strategy according to the current network quality parameter, calculating a dynamic packet size under a current network condition according to a basic fragmentation unit and a dynamic scaling coefficient, executing packet level verification on each received data packet, and updating the current network quality parameter according to the packet level verification. And executing block-level verification on all the data packets in the current logic block, executing mirror image-level verification on the complete firmware mirror image, and executing firmware upgrading of the to-be-upgraded equipment if the mirror image-level verification is passed. According to the method, a dynamic fragmentation strategy can be adopted, so that the size of the data packet is adjusted along with the exponential level of the signal strength, the transmission efficiency in a weak network environment is improved, the detection rate of a cross-packet data logic error is improved by utilizing a block verification process, and a sliding window release rule is adopted, so that the memory resource consumption is reduced, and equipment with more configurations is adapted.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet of Things device firmware upgrade, and in particular to an OTA program upgrade method and device, an electronic device, and a storage medium. BACKGROUND

[0002] OTA (Over-the-Air) upgrade is a technology for remotely updating device software over a network. OTA upgrade technology is widely used in the fields of smart phones, cars, and Internet of Things devices. For example, the automotive industry can remotely update the control systems and software of vehicles through OTA technology, avoiding the cumbersome process of traditional recalls and manual updates. Through OTA upgrade, users can enjoy better user experience and higher device security.

[0003] The existing OTA upgrade scheme has several drawbacks: first, fixed fragmentation defects, using a fixed package size (such as 256 KB), with a packet loss rate as high as 58% under weak network (RSSI <-90 dBm), resulting in repeated transmission. Second, insufficient verification mechanism, only supporting package-level CRC verification, which cannot detect cross-package logical errors. Third, uncontrolled resource consumption, requiring full-amount caching of firmware to memory, with 1 GB of firmware upgrade requiring 1 GB of RAM, which cannot be supported by low-configuration devices. SUMMARY

[0004] Therefore, the embodiments of the present application provide an OTA program upgrade method and device, an electronic device, and a storage medium to solve the problems of severe packet loss, insufficient verification mechanism, and excessive resource consumption of the existing OTA upgrade in the case of poor network signal.

[0005] In a first aspect, the embodiments of the present application provide an OTA program upgrade method, which comprises:

[0006] The device to be upgraded sends an upgrade request to the cloud, attaching the current network quality parameters;

[0007] A fragmentation strategy is dynamically generated according to the current network quality parameters, and the first data packet and fragmentation configuration metadata are issued according to the fragmentation strategy. The fragmentation configuration metadata includes a basic fragmentation unit, a dynamic scaling coefficient, and a logical block size.

[0008] The dynamic package size under the current network condition is calculated according to the basic fragmentation unit and the dynamic scaling coefficient, and the data packet issued by the cloud is received according to the dynamic package size;

[0009] Package-level verification is performed on each received data packet, and if the package-level verification passes, the data packet is written to the staging area;

[0010] when the number of accumulated received data packets reaches the logical block size specified in the fragmentation configuration metadata, performing block-level verification on all data packets in the current logical block;

[0011] If the block-level verification passes, the data of the current logical block is transferred from the staging area to the permanent storage area, and the corresponding storage space in the staging area is released.

[0012] The loop is executed until all data packets are received, the image-level verification is performed on the complete firmware image, and if the image-level verification passes, the firmware upgrade of the device to be upgraded is performed.

[0013] In a second aspect, the embodiment of the present application provides an OTA program upgrade device, which comprises:

[0014] An upgrade request sending module is configured to send an upgrade request to the cloud by the device to be upgraded, and the current network quality parameter is attached.

[0015] A fragmentation strategy dynamic generation module is configured to dynamically generate a fragmentation strategy according to the current network quality parameter, and send the first data packet and the fragmentation configuration metadata according to the fragmentation strategy, wherein the fragmentation configuration metadata comprises a basic fragmentation unit, a dynamic scaling factor and a logical block size.

[0016] A data packet receiving module is configured to calculate a dynamic packet size under the current network condition according to the basic fragmentation unit and the dynamic scaling factor, and receive the data packet sent by the cloud according to the dynamic packet size.

[0017] A packet-level verification module is configured to perform packet-level verification on each received data packet, and if the packet-level verification passes, the data packet is written into the staging area.

[0018] A block-level verification module is configured to perform block-level verification on all data packets in the current logical block when the number of accumulated received data packets reaches the logical block size specified in the fragmentation configuration metadata.

[0019] A storage space release module is configured to, if the block-level verification passes, transfer the data of the current logical block from the staging area to the permanent storage area, and release the corresponding storage space in the staging area.

[0020] A firmware upgrade module is configured to perform a loop until all data packets are received, perform image-level verification on the complete firmware image, and perform the firmware upgrade of the device to be upgraded if the image-level verification passes.

[0021] In a third aspect, the embodiment of the present application provides an electronic device, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above method when executing the computer program.

[0022] In a fourth aspect, the application provides a readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the method.

[0023] Compared with the prior art, the application has the beneficial effects that: the application sends an upgrade request to the cloud by the device to be upgraded, carries the current network quality parameter, dynamically generates a fragmentation strategy according to the current network quality parameter, issues the first data packet and fragmentation configuration metadata according to the fragmentation strategy, the fragmentation configuration metadata includes a basic fragmentation unit, a dynamic scaling factor and a logical block size, calculates the dynamic packet size under the current network condition according to the basic fragmentation unit and the dynamic scaling factor, receives the data packet issued by the cloud according to the dynamic packet size, performs packet-level verification on each received data packet, if the packet-level verification passes, writes the data packet to the temporary storage area, when the number of received data packets reaches the specified logical block size in the fragmentation configuration metadata, performs block-level verification on all data packets in the current logical block, if the block-level verification passes, transfers the data of the current logical block from the temporary storage area to the permanent storage area, and releases the corresponding storage space in the temporary storage area, and the cycle is repeated until all data packets are received, performs image-level verification on the complete firmware image, and if the image-level verification passes, performs firmware upgrade of the device to be upgraded. The application adopts a dynamic fragmentation strategy, so that the packet size is exponentially adjusted with the signal strength, the transmission efficiency in a weak network environment is improved, the problem that a large packet is easily lost as a whole in a weak network is solved, the block verification process is used to improve the detection rate of cross-packet data logical errors, the sliding window release rule is adopted, the memory resource consumption is reduced, and more configured devices are adapted. BRIEF DESCRIPTION OF DRAWINGS

[0024] In order to more clearly illustrate the technical solutions in the embodiments of the application, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are only some embodiments of the application, and for those skilled in the art, other drawings can also be obtained without creative labor based on these drawings.

[0025] Figure 1 is a scene diagram of an application scenario of the embodiments of the application;

[0026] Figure 2 is a flowchart of an OTA program upgrade method provided by the embodiments of the application;

[0027] Figure 3 is a schematic diagram of an OTA program upgrade device provided by the embodiments of the application;

[0028] Figure 4 is a structural schematic diagram of an electronic device provided by the embodiments of the application. DETAILED DESCRIPTION

[0029] In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular architectures, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application can be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known methods, devices, and circuits are omitted so as not to obscure the description of the present application with unnecessary detail.

[0030] OTA (Over-the-Air) upgrade is a technology that remotely updates device software through the network. OTA upgrade technology is widely used in the fields of smart phones, cars, Internet of Things devices, etc. For example, the automotive industry can remotely update the control system and software of vehicles through OTA technology, avoiding the cumbersome process of traditional recalls and manual updates. Through OTA upgrade, users can enjoy better user experience and higher device security.

[0031] The basic process of OTA upgrade usually includes the following steps: detecting updates, the device connects to the OTA server to detect whether there are available updates. Downloading the update package, if an update is detected, the device will download the update package to local storage. Verifying the update package, after downloading, the device will verify the integrity and security of the update package to ensure its reliable source. Installing updates, after verification, the device will restart and enter recovery mode to perform update installation. Restarting the device, after the update installation is complete, the device will restart and run the new version of the system.

[0032] The existing OTA upgrade scheme has several drawbacks: first, fixed fragmentation defects, using a fixed package size (such as 256KB), the packet loss rate is as high as 58% under weak network (RSSI <-90dBm), leading to repeated transmission. Second, the verification mechanism is insufficient, only supporting package-level CRC verification, which cannot detect cross-package logical errors. Third, resource consumption is out of control, requiring full-amount caching of firmware to memory, 1GB firmware upgrade requires 1GB RAM, low-configuration devices cannot support.

[0033] In view of the problems in the prior art, the embodiments of the present application provide a brand-new OTA program upgrading method, which comprises the following steps: a device to be upgraded sends an upgrading request to a cloud, and carries current network quality parameters; a fragmentation strategy is dynamically generated according to the current network quality parameters; a first data packet and fragmentation configuration metadata are issued according to the fragmentation strategy, the fragmentation configuration metadata comprising a basic fragmentation unit, a dynamic scaling coefficient and a logical block size; a dynamic packet size under current network conditions is calculated according to the basic fragmentation unit and the dynamic scaling coefficient, and the data packet issued by the cloud is received according to the dynamic packet size; a packet-level check is performed on each received data packet, and if the packet-level check is passed, the data packet is written into a temporary storage area; when the number of received data packets reaches the specified logical block size in the fragmentation configuration metadata, a block-level check is performed on all data packets in the current logical block; if the block-level check is passed, the data of the current logical block is transferred from the temporary storage area to a permanent storage area, and the corresponding storage space in the temporary storage area is released; the above steps are repeatedly performed until all data packets are received; a complete firmware image is subjected to an image-level check, and if the image-level check is passed, the firmware of the device to be upgraded is upgraded. The dynamic fragmentation strategy adopted by the present application enables the packet size to be exponentially adjusted with the signal strength, thereby improving the transmission efficiency in a weak network environment, solving the problem that a large packet is easily lost as a whole in a weak network, and improving the detection rate of cross-packet data logical errors by using a block check process, reducing the memory resource consumption by using a sliding window release rule, and adapting to more configured devices.

[0034] A OTA program upgrading method and device according to the embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0035] Figure 1 is a scene diagram of an application scenario of the embodiments of the present application. The application scenario can include terminal devices 101, 102 and 103, a server 104 and a network 105.

[0036] The terminal devices 101, 102 and 103 can be hardware or software. When the terminal devices 101, 102 and 103 are hardware, they can be various electronic devices with a display screen and supporting communication with the server 104, including but not limited to smart phones, tablet computers, laptop computers and desktop computers, etc.; when the terminal devices 101, 102 and 103 are software, they can be installed in the above electronic devices. The terminal devices 101, 102 and 103 can be implemented as multiple software or software modules, or as a single software or software module, and the embodiments of the present application do not limit this. Further, various applications can be installed on the terminal devices 101, 102 and 103, such as data processing applications, instant messaging tools, social platform software, search applications, shopping applications, etc.

[0037] The server 104 can be a server providing various services, for example, a background server receiving a request sent by a terminal device establishing a communication connection therewith, which can receive and analyze the request sent by the terminal device and generate a processing result. The server 104 can be a single server, a server cluster composed of several servers, or a cloud computing service center, and the embodiments of the present application do not limit this.

[0038] It should be noted that the server 104 can be hardware or software. When the server 104 is hardware, it can be various electronic devices providing various services for the terminal devices 101, 102 and 103. When the server 104 is software, it can be a plurality of software or software modules providing various services for the terminal devices 101, 102 and 103, or a single software or software module providing various services for the terminal devices 101, 102 and 103, and the embodiments of the present application do not limit this.

[0039] The network 105 can be a wired network connected by coaxial cables, twisted-pair wires and optical fibers, or a wireless network realizing interconnection of various communication devices without wiring, for example, Bluetooth, Near Field Communication (NFC), Infrared, etc., and the embodiments of the present application do not limit this.

[0040] A user can establish a communication connection with the server 104 via the network 105 through the terminal devices 101, 102 and 103 to receive or send information, etc. Specifically, the to-be-upgraded device sends an upgrade request to the cloud, carrying current network quality parameters, the server 104 dynamically generates a fragmentation strategy according to the current network quality parameters, issues a first data packet and fragmentation configuration metadata according to the fragmentation strategy, the fragmentation configuration metadata including a basic fragmentation unit, a dynamic scaling factor and a logical block size, the server 104 calculates a dynamic packet size under current network conditions according to the basic fragmentation unit and the dynamic scaling factor, receives the data packet issued by the cloud according to the dynamic packet size, performs packet-level verification on each received data packet, and if the packet-level verification is passed, writes the data packet to a temporary storage area, when the number of received data packets reaches the specified logical block size in the fragmentation configuration metadata, performs block-level verification on all data packets in the current logical block, if the block-level verification is passed, transfers the data of the current logical block from the temporary storage area to the permanent storage area, and releases the corresponding storage space in the temporary storage area, and the cycle is repeated until all data packets are received, the server 104 performs image-level verification on the complete firmware image, and if the image-level verification is passed, performs firmware upgrade of the to-be-upgraded device.

[0041] It should be noted that the specific types, quantities and combinations of the terminal devices 101, 102 and 103, the server 104 and the network 105 can be adjusted according to actual needs of an application scenario, and the embodiments of the present application do not limit this.

[0042] Figure 2 is a flow diagram of an OTA program upgrading method provided by an embodiment of the present application. Figure 2 The OTA program upgrading method can be executed by Figure 1 a terminal device or a server. As shown in Figure 2 , the OTA program upgrading method comprises the following steps.

[0043] S201, the device to be upgraded sends an upgrading request to the cloud, and carries the current network quality parameter;

[0044] S202, a fragmentation strategy is dynamically generated according to the current network quality parameter, a first data packet and fragmentation configuration metadata are issued according to the fragmentation strategy, and the fragmentation configuration metadata comprises a basic fragmentation unit, a dynamic scaling factor and a logical block size;

[0045] S203, the dynamic packet size under the current network condition is calculated according to the basic fragmentation unit and the dynamic scaling factor, and the data packet issued by the cloud is received according to the dynamic packet size;

[0046] S204, a packet-level check is performed on each received data packet, and if the packet-level check passes, the data packet is written into a temporary storage area;

[0047] S205, when the number of received data packets reaches the specified logical block size in the fragmentation configuration metadata, a block-level check is performed on all data packets in the current logical block;

[0048] S206, if the block-level check passes, the data of the current logical block is transferred from the temporary storage area to the permanent storage area, and the corresponding storage space in the temporary storage area is released;

[0049] S207, the loop is executed until all data packets are received, a mirror-level check is performed on the complete firmware mirror, and if the mirror-level check passes, the firmware upgrading of the device to be upgraded is performed.

[0050] Specifically, the device to be upgraded in this embodiment refers to a terminal device that needs to be upgraded by OTA program, such as an industrial sensor, a vehicle-mounted system, etc., which has network communication capability. The network quality parameter refers to a communication index collected in real time, including a signal strength indication (RSSI): the wireless signal power received by the device (unit: dBm), such as -82 dBm indicating a medium signal. A packet loss rate: the percentage of lost data packets in transmission (such as 12%). A transmission delay: the round-trip time of a data packet (such as 150 ms). The device to be upgraded can collect the above-mentioned parameters through a bottom layer driver (such as a cellular module AT instruction) and send them to the cloud through the MQTT protocol. By attaching the current network quality parameter, the network sensing capability is improved, and the environment signal is quantized to provide a basis for dynamic decision-making in the subsequent steps. For example, in the underground operation of a mine, when the device to be upgraded upgrades the firmware through a 2G network, the RSSI can be as low as -95 dBm. At this time, the reported parameters can trigger the cloud to dynamically adjust the upgrade strategy to avoid upgrade failure caused by traditional fixed parameters.

[0051] Further, the fragmentation strategy refers to a transmission rule generated by the cloud according to the current network quality parameter, the core of which includes: a dynamic scaling factor N: an exponential factor that determines the size of the packet. A logical block size: the number of packets that constitute a check unit (such as the default 32 packets). A basic fragmentation unit: the minimum fragmentation reference (fixed 4 KB). The current network quality parameter determines the basic packet size level and dynamically adjusts the logical block size to reduce the check unit in high packet loss. In some cases, the transmission delay in the current network quality parameter can also be used to assist in predicting network stability, such as automatically enabling forward error correction when the transmission delay > 500 ms. The above-mentioned determined fragmentation strategy forms a fragmentation configuration metadata, which is a control instruction set of the above-mentioned core, and the first data packet is issued according to the control instruction set. The data packet is part of the total data in the OTA program upgrade.

[0052] Further, the dynamic packet size refers to the size of the transmission unit calculated in real time according to the current network condition. The dynamic packet size under the current network condition is calculated by using a calculation formula according to the basic fragmentation unit and the dynamic scaling factor, and the data packet issued by the cloud is received according to the dynamic packet size. So that in strong network, large packet improves throughput (4MB packet is 15 times faster than 256KB packet), and in weak network, small packet guarantees success rate. For example, the agricultural Internet of Things gateway automatically reduces the dynamic packet size from 1MB (dynamic scaling factor = 8) to 256KB (dynamic scaling factor = 6) in thunderstorm weather (packet loss rate 25%), the single packet transmission time is shortened from 1.2 seconds to 0.3 seconds, avoiding the phenomenon of packet loss caused by signal burst interruption.

[0053] Further, the packet-level verification in the embodiment refers to CRC-32 cyclic redundancy check on the single packet of the data packet issued in the previous step to generate a 4-byte check code. The staging area refers to a temporary cache (such as a 64 MB ring buffer) opened in the RAM. After the packet-level verification, the data packet enters the staging area in an append write manner, and a logical offset address is recorded. The packet-level verification can intercept real-time errors, and the CRC-32 cyclic redundancy check can improve the detection rate of single packet 4-bit internal errors. The staging area is separated from the running memory, avoiding the influence of upgrading on other functions of the device to be upgraded.

[0054] Further, when the number of accumulated received data packets reaches the logical block size specified in the slice configuration metadata, a block-level verification is performed on all data packets in the current logical block. The current logical block refers to a data unit composed of K consecutive data packets (such as 32 packets x 256 KB = 8 MB). The block-level verification refers to SHA-256 hash verification on the whole current logical block to generate a 32-byte digest. The device to be upgraded can call a hardware encryption engine (such as ARMCryptoCell) to accelerate SHA-256 calculation, and the block-level verification can realize cross-packet error detection, identify packet sequence disorder, and identify composite errors such as man-in-the-middle tampering. For example, when a medical device is upgraded, packet #15 and packet #16 are out of order due to memory overflow, and the recombined electrocardiogram algorithm code logic is broken. SHA-256 comparison finds that the local digest “9f86d…” does not match the cloud pre-stored block value digest “d4735…”, and the fatal error is intercepted.

[0055] Further, if the block-level verification passes, the data of the current logical block is transferred from the staging area to the permanent storage area, and the corresponding storage space in the staging area is released. The embodiment uses a sliding window to transfer the data of the current logical block from the staging area to the permanent storage area, where the permanent storage area can be the final storage location of the firmware, and the sliding window can be a cache pool managing 3 logical blocks (such as 3 x 8 MB = 24 MB). Through data transfer and space release, the memory occupancy is compressed: 1 GB firmware upgrade only needs 0.024 times of memory (24 MB vs 1 GB). And it guarantees data continuity, after the block-level verification passes, the current logical block is transferred and the corresponding storage space in the staging area is released, preventing firmware chain breakage. The following illustrates the specific process of data transfer and space release. Assuming that a smart watch is upgraded with 500 MB firmware, after completing the logical block 3 verification and transferring the current logical block 2, the logical block 1 space is immediately released, and only a 24 MB memory window is needed from beginning to end. Even if the device to be upgraded restarts, only the current window data (<24 MB) is lost, rather than the 500 MB loss of the traditional scheme.

[0056] Further, the cycle is executed until all data packet receiving is completed, image-level verification is performed on the complete firmware image, and if the image-level verification passes, firmware upgrade of the device to be upgraded is performed. The image-level verification is an important step to ensure the authenticity and integrity of the image file or software issued from the cloud. Through verification, it can be confirmed that the file has not been tampered with or damaged, thereby avoiding potential security risks. For example, the digital signature of the complete firmware is verified. The firmware (all data packets as a whole) that passes the verification is written to the boot partition of the device to be upgraded, and firmware upgrade is performed. In this way, through the above three-level verification chain (packet-level verification -> block-level verification -> image-level verification), deep defense in the OTA upgrade process is achieved.

[0057] According to the technical scheme provided by the embodiments of the present application, the device to be upgraded sends an upgrade request to the cloud, carries the current network quality parameter, dynamically generates a fragmentation strategy according to the current network quality parameter, issues the first data packet and fragmentation configuration metadata according to the fragmentation strategy, the fragmentation configuration metadata includes a basic fragmentation unit, a dynamic scaling factor and a logical block size, calculates the dynamic packet size under the current network condition according to the basic fragmentation unit and the dynamic scaling factor, and receives the data packet issued by the cloud according to the dynamic packet size, performs packet-level verification on each received data packet, if the packet-level verification passes, writes the data packet to the temporary storage area, when the number of received data packets reaches the specified logical block size in the fragmentation configuration metadata, performs block-level verification on all data packets in the current logical block, if the block-level verification passes, transfers the data of the current logical block from the temporary storage area to the permanent storage area, and releases the corresponding storage space in the temporary storage area, and the cycle is executed until all data packet receiving is completed, image-level verification is performed on the complete firmware image, and if the image-level verification passes, firmware upgrade of the device to be upgraded is performed. The present application adopts a dynamic fragmentation strategy, so that the packet size is adjusted exponentially with the signal strength, the transmission efficiency in a weak network environment is improved, the problem of easy overall loss of large packets in a weak network is solved, the detection rate of cross-packet data logical errors is improved by using the block verification process, the memory resource consumption is reduced by using the sliding window release rule, and more configured devices are adapted.

[0058] In some embodiments, the fragmentation strategy is dynamically generated according to the current network quality parameter, and the first data packet and the fragmentation configuration metadata are issued according to the fragmentation strategy, including:

[0059] The signal strength and the packet loss rate are determined according to the current network quality parameter;

[0060] The dynamic scaling factor is determined according to the signal strength;

[0061] When the signal strength is greater than or equal to -70dBm, the dynamic scaling factor is 10;

[0062] When -85dBm≤signal strength<-70dBm, the dynamic scaling factor is 8;

[0063] When the signal strength is <-85dBm, the dynamic scaling factor is 6;

[0064] According to the packet loss rate adjustment logic block size, when the packet loss rate is >15%, the logic block size is automatically reduced by 50%.

[0065] Specifically, the signal strength (RSSI) refers to the power value (unit dBm) of the radio wave received by the device to be upgraded, and the smaller the negative value represents the weaker the signal. For example, -70dBm is a good signal in the city, and -95dBm is a weak signal in the tunnel. Its absolute value determines the physical layer stability of data transmission. The packet loss rate refers to the percentage of lost data packets during transmission, reflecting the degree of network congestion or interference. For example, a 22% packet loss rate means that 22 out of every 100 packets are lost, which triggers the fault tolerance mechanism. The dynamic scaling factor N is an exponential factor (values 6 / 8 / 10) that determines the packet size. Through the formula, packet size = 4KB x 2^N, the signal strength is quantified into transmission parameters. For example, N = 6 corresponds to a 64KB small packet, which is suitable for weak network environment. The logic block size constitutes the number of data packets in a single check unit (default 32 packets). When the packet loss rate is high, it is reduced to 16 packets, reducing the size of the single check unit to improve fault tolerance. The following illustrates the specific formation process of the fragmentation strategy. Taking the case of an electric vehicle passing through a tunnel as an example, the vehicle networking extreme scenario, the RSSI drops to -92dBm, triggering the weak network mode (N = 6), the packet size is automatically compressed from 1MB to 64KB, the amount of data retransmitted in a single time is reduced by 50%, and the upgrade success rate is increased from 41% to 86%. Multipath reflection makes the packet loss rate reach 25%, and the block reduction mechanism is activated, reducing the logic block size from 32 packets to 16 packets, avoiding the complete loss of 4MB large packets in the signal blind area, and the tunnel segment upgrade data integrity rate reaches 92%. According to the fragmentation strategy, the first data packet and fragmentation configuration metadata are issued, forming a dual mechanism to prevent "error avalanche", small packets reduce the impact of single transmission failure, and small blocks limit the amount of data retransmitted.

[0066] In some embodiments, calculating a dynamic packet size under current network conditions according to a base fragmentation unit and a dynamic scaling factor includes:

[0067] The base fragmentation unit is 4KB;

[0068] The dynamic packet size = base fragmentation unit x 2^N; where N is the dynamic scaling factor.

[0069] In particular, the basic fragmentation unit is the minimum reference unit (fixed 4KB) of data fragmentation. This value is strictly aligned with the physical page size of the NAND flash storage medium, ensuring that each write operation can be directly programmed in whole pages, avoiding the write amplification effect caused by misalignment in traditional solutions. The dynamic scaling factor N is an exponential parameter (values 6 / 8 / 10) determined by the signal strength (RSSI). Its essence is to discretize the continuous signal strength into transmission control instructions, for example, N=8 corresponds to medium network conditions (-85dBm≤RSSI<-70dBm). The dynamic packet size is the real-time calculated data transmission unit size (formula: 4KBx2^N). This design makes the packet size change exponentially (non-linear adjustment) with network quality, for example, when N=6, the dynamic packet size is 64KB; when N=10, the dynamic packet size is 4MB. Taking the fire-fighting drone upgrade scene as an example, the dynamic packet size determination process is explained. When the fire-fighting drone needs to urgently upgrade the navigation firmware over the fire field (RSSI=-68dBm), activate N=10, and the dynamic packet size=4KBx2 10 =4MB, take advantage of strong network bandwidth, 1GB firmware only needs 250 transmissions, traditional scheme needs 4000 times, upgrade time can be compressed from 210 seconds to 52 seconds, which saves critical time window for rescue. This embodiment adopts exponential granularity control: for every 15dB decrease in signal strength (e.g. from -70dBm to -85dBm), the packet size is reduced by 1 / 4 (4MB to 256KB), accurately matching the Shannon channel capacity formula. In a weak network environment, the transmission time of a small packet (64KB) is shorter than the typical signal fading period (about 800ms), avoiding transmission failure due to environmental changes. In addition, the N value adopts boundary protection, and the N value is automatically limited to 10 at most to prevent memory overflow (e.g. 4KBx2 12 =16MB exceeds device cache).

[0070] In some embodiments, performing block-level verification on all data packets within the current logical block includes:

[0071] calculating the pre-stored block digest of the current logical block by the SHA-256 algorithm on the original data of the current logical block;

[0072] calculating the local digest of the current logical block after receiving the data packet;

[0073] comparing the local digest with the pre-stored block digest, and if they are consistent, the block-level verification is passed.

[0074] In particular, the pre-stored block digest refers to a cryptographic fingerprint (256-bit SHA-256 value) calculated by the cloud on the original data of the logical block before transmission. The generation process embeds the device ID and a random salt value, ensuring that the digest cannot be forged. For example, the digest value of an 8MB block is d4735e...9f86d0. The local digest refers to the verification fingerprint calculated in real time by the device after reassembling the data packet. A SHA-256 engine with hardware acceleration is used, and the packet sequence number metadata is forced to be included during calculation to prevent packet sequence tampering. Constant-time comparison is performed on the two 256-bit digests to avoid timing attacks that reveal difference bit information. If the difference exceeds 3 bits, it is determined to be a failure. Traditional CRC check can only detect single packet errors, and is completely ineffective for cross-packet data logic errors (such as control instruction misplacement). The avalanche effect of SHA-256 ensures that any bit change causes more than 50% of the digest bits to flip, which can improve the single packet tampering detection rate and packet sequence disorder detection rate.

[0075] In some embodiments, if the block-level verification passes, the data of the current logical block is transferred from the temporary storage area to the permanent storage area, and the corresponding storage space in the temporary storage area is released, including:

[0076] A sliding window mechanism is used, and the size of the window is 3 current logical blocks.

[0077] When the earliest completed current logical block in the window passes the block-level verification, and the previous current logical block has been transferred to the permanent storage area, the storage space of the earliest current logical block in the temporary storage area is released.

[0078] Specifically, the sliding window mechanism in the embodiment can be a dynamic memory management model, and the window size is fixed to 3 logical blocks (e.g., 3 x 8 MB = 24 MB). The window slides with the upgrade progress, and always keeps the latest 3 blocks in the staging area. For example, the window is initially [block 1, 2, 3], and slides to [block 2, 3, 4] after receiving block 4. The embodiment releases the staging area space as early as possible to store subsequent block data while ensuring data security storage, and ensures that data loss does not occur due to early release. The earliest completed current logical block refers to the block that is first received and verified in the window (e.g., block 3 in the window [3, 4, 5]). Its release needs to meet two conditions: the self-verification passes and the previous block (block 2) has been transferred to the permanent storage area. The permanent storage area refers to the firmware storage partition in the non-volatile memory, which has power failure protection characteristics. The transfer operation uses atomic write transactions to ensure data integrity. The space complexity of the embodiment is constant, and the memory occupancy = 3 x logical block size (e.g., 24 MB), which is independent of the total size of the firmware. Compared with the traditional full cache solution, the memory requirement for 1 GB firmware upgrade is reduced from 1 GB to 24 MB (reduced by 97.6%). The 64 MB memory device supports 2 GB firmware upgrade, and only needs to adjust the logical block size to 5.3 MB, which is compatible with low-end devices.

[0079] In some embodiments, further comprising:

[0080] If the execution of the package-level verification fails, the sequence number and failure reason of the failed data package are recorded, and the failure count is updated;

[0081] If the failure count of the same failed data package does not exceed the maximum retry number specified in the shard configuration metadata, the cloud is requested to retransmit the failed data package;

[0082] If the maximum retry number is exceeded, an incremental repair package is requested to be sent from the cloud according to the location of the failed data package in the logical block.

[0083] Specifically, the failure count in this embodiment can be a retransmission attempt number counter for a specific data packet, initially 0. A maximum number of retries (3 by default) in the sharding configuration metadata constitutes a fuse mechanism, for example, a certain data packet fails 3 times in a row to trigger incremental repair. The incremental repair packet refers to the difference data unit generated by the cloud, with a size of 5%-20% of the original packet, containing only the repair data of the damaged part and the positioning metadata. For example, when 12KB of core code in a 256KB packet is damaged, the incremental packet only needs to transmit 12KB of repair data + 128B of positioning header. The logical block position can be the sequence number of the failed data packet in the logical block (such as block 3, packet 7), used for accurate positioning of the damaged interval by the cloud. The logical block position can be encoded as a block number and packet offset two-tuple (such as 0x0307). This embodiment adopts a hierarchical fault-tolerant system, primary defense: when the failure count is less than or equal to the maximum number of retries, traditional retransmission is used (suitable for temporary errors); advanced repair: when the threshold is exceeded, incremental repair is enabled (to deal with persistent damage), reducing the amount of retransmitted data.

[0084] The following details this embodiment according to two scenarios. Scenario one: the steel plant temperature controller upgrade encounters continuous interference, data packet #1027 fails CRC twice in a row due to electromagnetic pulses (failure count = 2), the third transmission still fails, the failure count reaches the threshold of 3, triggering incremental repair. The cloud analyzes the damaged interval of the failed data packet as 0x8000-0x9000 (temperature calibration table), and issues a 12KB incremental repair packet (containing a backup of the calibration table + CRC patch), reducing the number of retransmissions and avoiding the interference period to complete the repair.

[0085] Scenario two: vehicle networking tunnel scenario, electric vehicle enters signal blind area during upgrade: packet #1521 transmission is interrupted (failure reason: TCP timeout), failure count does not reach threshold (current 1<3), requests original packet retransmission, and retransmission is successful after driving out of the tunnel.

[0086] In some embodiments, further comprising:

[0087] Monitoring the power of the device to be upgraded in real time during the firmware upgrade, and sending a power saving mode request to the cloud when the power is lower than a threshold;

[0088] Re-determining the sharding configuration metadata in response to the power saving mode instruction issued by the cloud, wherein the dynamic scaling factor is increased by 2 to increase the dynamic packet size; suspending the request for non-critical data packets until the power is restored.

[0089] Specifically, the core of the energy-saving mode in the embodiment is the dual optimization of dynamic packet size adjustment and non-critical packet filtering. The threshold refers to the critical power value that triggers the energy-saving mode, for example, 20%. The threshold is set based on the lithium-ion battery discharge curve, and below this value, large current discharge will accelerate voltage drop. The energy-saving mode request can be an optimization instruction request sent by the device to be upgraded. When the first data packet and the slice configuration metadata are issued according to the energy-saving mode instruction issued by the cloud, the dynamic scaling factor is increased by 2 to increase the dynamic packet size, and the mathematical essence of the dynamic scaling factor increment of 2 is that the packet size is exponentially expanded by 4 times (because 2^{N+2} = 4 x 2^N). For example, when N = 8, the packet size is increased from 256KB to 1024KB. Increasing the packet size at low power can save energy by reducing the number of radio frequency wake-ups. Non-critical data packets refer to auxiliary data that can be delayed (such as log files, localized resources), which usually account for 18-35% of the firmware size. Non-critical data packets are identified by file path features (such as / i18n / ,.log suffix). Pausing the transmission of non-critical data packets can reduce data volume by 15-30%. Taking the fire emergency scenario of a firefighting drone as an example: when the firmware is upgraded during fire monitoring, the power drops to 19%, and the energy-saving mode request is sent (current N = 6, power 19%), after the cloud responds, N + 2 = 8, the packet size 64KB is increased to 256KB, and the pause of German, French, and Spanish language packs (non-critical data packets account for 22% of the firmware) can reduce the number of wake-ups from 80 to 20, and the total energy consumption from 1520mAh to 486mAh (a decrease of 68%), and the remaining power after upgrading is 12%, which ensures continuous fire monitoring.

[0090] All the optional technical solutions described above can be combined to form optional embodiments of the present application, which will not be described here.

[0091] The following is an apparatus embodiment of the present application, which can be used to execute the method embodiments of the present application. For details not disclosed in the apparatus embodiments of the present application, please refer to the method embodiments of the present application.

[0092] Figure 3 is a schematic diagram of an OTA program upgrading apparatus provided by an embodiment of the present application. As shown in Figure 3 , the OTA program upgrading apparatus comprises:

[0093] The upgrade request sending module 301 is configured to send an upgrade request to the cloud by the device to be upgraded, and attach the current network quality parameter;

[0094] The slice strategy dynamic generation module 302 is configured to dynamically generate a slice strategy according to the current network quality parameter, issue the first data packet and the slice configuration metadata according to the slice strategy, and the slice configuration metadata comprises a basic slice unit, a dynamic scaling factor, and a logical block size;

[0095] The data packet receiving module 303 is configured to calculate a dynamic packet size under current network conditions according to a basic fragmentation unit and a dynamic scaling factor, and receive data packets issued by the cloud according to the dynamic packet size.

[0096] The packet-level verification module 304 is configured to perform packet-level verification on each received data packet, and write the data packet to a temporary storage area if the packet-level verification passes.

[0097] The block-level verification module 305 is configured to perform block-level verification on all data packets in a current logical block when the number of accumulated received data packets reaches a logical block size specified in the fragmentation configuration metadata.

[0098] The storage space releasing module 306 is configured to transfer data of the current logical block from the temporary storage area to the permanent storage area and release the corresponding storage space in the temporary storage area if the block-level verification passes.

[0099] The firmware upgrade module 307 is configured to perform image-level verification on a complete firmware image by repeatedly performing until all data packets are received, and perform firmware upgrade of the device to be upgraded if the image-level verification passes.

[0100] In some embodiments, Figure 3 The fragmentation strategy dynamic generation module 302 includes:

[0101] determining signal strength and packet loss rate according to current network quality parameters;

[0102] determining a dynamic scaling factor according to the signal strength;

[0103] when the signal strength is greater than or equal to -70 dBm, the dynamic scaling factor is 10;

[0104] when -85 dBm≤ signal strength < -70 dBm, the dynamic scaling factor is 8;

[0105] when the signal strength is less than -85 dBm, the dynamic scaling factor is 6;

[0106] adjusting the logical block size according to the packet loss rate, and automatically reducing the logical block size by 50% when the packet loss rate is greater than 15%.

[0107] In some embodiments, Figure 3 The data packet receiving module 303 includes:

[0108] the basic fragmentation unit is 4 KB;

[0109] the dynamic packet size = the basic fragmentation unit x 2^N; where N is the dynamic scaling factor.

[0110] In some embodiments, Figure 3The block-level verification module 305 of the application comprises:

[0111] The original data of the current logical block is calculated by the SHA-256 algorithm to determine the pre-stored block digest;

[0112] The current logical block is calculated to determine the local digest of the current logical block after receiving the data packet;

[0113] The local digest is compared with the pre-stored block digest, and if they are consistent, the block-level verification is passed.

[0114] In some embodiments, Figure 3 The storage space release module 306 of the application comprises:

[0115] The sliding window mechanism is adopted, and the size of the window is 3 current logical blocks;

[0116] When the earliest completed current logical block in the window passes the block-level verification, and the previous current logical block has been stored in the permanent storage area, the storage space of the earliest current logical block in the temporary storage area is released.

[0117] In some embodiments, Figure 3 The packet-level verification module 304 of the application further comprises:

[0118] If the packet-level verification fails, the sequence number and failure reason of the failed data packet are recorded, and the failure count is updated;

[0119] If the failure count of the same failed data packet does not exceed the maximum retry number specified in the shard configuration metadata, the cloud is requested to retransmit the failed data packet;

[0120] If the maximum retry number is exceeded, the cloud is requested to send an incremental repair packet according to the position of the logical block where the failed data packet is located.

[0121] In some embodiments, Figure 3 The firmware upgrade module 307 of the application further comprises:

[0122] The power of the device to be upgraded is monitored in real time during the firmware upgrade process, and when the power is lower than the threshold, a power saving mode request is sent to the cloud;

[0123] The shard configuration metadata is re-determined in response to the power saving mode instruction issued by the cloud, wherein the dynamic scaling factor is increased by 2 to increase the dynamic packet size; the request of non-critical data packets is suspended until the power is restored.

[0124] It should be understood that the size of the sequence number of each step in the above embodiments does not mean the order of execution, and the execution order of each process should be determined according to its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the application.

[0125] Figure 4 is a schematic diagram of an electronic device 4 provided by an embodiment of the present application. As shown in Figure 4 the electronic device 4 of this embodiment includes a processor 401, a memory 402, and a computer program 403 stored in the memory 402 and executable on the processor 401. The processor 401 implements the steps in each of the above method embodiments when executing the computer program 403. Alternatively, the processor 401 implements the functions of each module / unit in each of the above apparatus embodiments when executing the computer program 403.

[0126] The electronic device 4 can be a desktop computer, a notebook computer, a palm computer, a cloud server, or the like. The electronic device 4 can include but is not limited to the processor 401 and the memory 402. Those skilled in the art can understand that Figure 4 The electronic device 4 is merely an example and does not constitute a limitation on the electronic device 4, and can include more or fewer components or different components than those shown.

[0127] The processor 401 can be a central processing unit (CPU), or other general purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic components, discrete hardware components, etc.

[0128] The memory 402 can be an internal storage unit of the electronic device 4, for example, a hard disk or a memory of the electronic device 4. The memory 402 can also be an external storage device of the electronic device 4, for example, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. The memory 402 can also include both the internal storage unit and the external storage device of the electronic device 4. The memory 402 is used to store computer programs and other programs and data required by the electronic device.

[0129] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above functional units and modules is exemplified, and in actual application, the above functions can be completed by different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the above described functions. Each functional unit and module in the embodiment can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit, and the integrated unit can be realized in the form of hardware or software.

[0130] If the integrated module / unit is realized in the form of a software function unit and sold or used as an independent product, it can be stored in a readable storage medium (for example, a computer readable storage medium). Based on this understanding, all or part of the processes in the above embodiment methods can also be completed by a computer program instructing related hardware, and the computer program can be stored in a readable storage medium. When the processor executes the computer program, the steps of each method embodiment described above can be implemented. The computer program can include computer program code, which can be in the form of source code, object code, executable files or some intermediate forms, etc. The computer readable storage medium can include any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc.

[0131] The above embodiments are only used to illustrate the technical solutions of the present application, but not limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. An upgrade method of an OTA program, characterized by, The method comprises: The device to be upgraded sends an upgrade request to the cloud, carrying the current network quality parameters; According to the current network quality parameters, a fragmentation strategy is dynamically generated, and the first data packet and fragmentation configuration metadata are issued according to the fragmentation strategy, wherein the fragmentation configuration metadata comprises a basic fragmentation unit, a dynamic scaling coefficient and a logical block size; According to the basic fragmentation unit and the dynamic scaling coefficient, the dynamic packet size under the current network condition is calculated, and the data packet issued by the cloud is received according to the dynamic packet size; A packet-level check is performed on each received data packet, and if the packet-level check passes, the data packet is written to a temporary storage area; When the number of accumulated received data packets reaches the logical block size specified in the fragmentation configuration metadata, a block-level check is performed on all data packets in the current logical block; If the block-level check passes, the data of the current logical block is transferred from the temporary storage area to the permanent storage area, and the corresponding storage space in the temporary storage area is released; The cycle is executed until all the data packets are received, a mirror-level check is performed on the complete firmware mirror, and if the mirror-level check passes, the firmware upgrade of the device to be upgraded is performed.

2. The method of claim 1, wherein, The method comprises: According to the current network quality parameters, the signal strength and the packet loss rate are determined; According to the signal strength, the dynamic scaling coefficient is determined; When the signal strength is greater than or equal to -70 dBm, the dynamic scaling coefficient is 10; When the signal strength is between -85 dBm and -70 dBm, the dynamic scaling coefficient is 8; When the signal strength is less than -85 dBm, the dynamic scaling coefficient is 6; According to the packet loss rate, the logical block size is adjusted, and when the packet loss rate is greater than 15%, the logical block size is automatically reduced by 50%.

3. The method of claim 2, wherein, The method comprises: The basic fragmentation unit is 4 KB; The dynamic packet size = basic fragmentation unit x 2^N; wherein N is the dynamic scaling coefficient.

4. The method of claim 1, wherein, The method comprises: The original data of the current logical block is calculated by the SHA-256 algorithm to determine the pre-stored block digest; The current logical block is calculated to determine the local digest of the current logical block after receiving the data packet; The local digest is compared with the pre-stored block digest, and if they are consistent, the block-level check passes.

5. The method of claim 1, wherein, The method comprises: A sliding window mechanism is adopted, and the size of the window is 3 current logical blocks; When the earliest completed current logical block in the window passes the block-level check, and its previous current logical block has been stored in the permanent storage area, the storage space of the earliest current logical block in the temporary storage area is released.

6. The method of claim 1, wherein, Further comprising: If the execution of the package-level check fails, record the sequence number and failure reason of the failed data package, and update the failure count; If the failure count of the same failed data package does not exceed the maximum retry number specified in the shard configuration metadata, request the cloud to retransmit the failed data package; If the maximum retry number is exceeded, request the cloud to send an incremental repair package according to the location of the logical block where the failed data package is located.

7. The method according to any one of claims 1 to 6, characterized in that, Further comprising: Real-time monitoring of the power of the device to be upgraded during the firmware upgrade process, and sending a power saving mode request to the cloud when the power is below a threshold value; In response to the power saving mode instruction issued by the cloud, re-determine the shard configuration metadata, wherein the dynamic scaling factor is increased by 2 to increase the dynamic package size; pause the request for non-critical data packages until the power is restored.

8. An apparatus for upgrading an OTA program, characterized by comprising: Comprising: An upgrade request sending module for sending an upgrade request to the cloud by the device to be upgraded, and attaching the current network quality parameters; A shard strategy dynamic generation module for dynamically generating a shard strategy according to the current network quality parameters, issuing a first data package and shard configuration metadata according to the shard strategy, and the shard configuration metadata including a basic shard unit, a dynamic scaling factor, and a logical block size; A data package receiving module for calculating a dynamic package size under the current network conditions according to the basic shard unit and the dynamic scaling factor, and receiving the data packages issued by the cloud according to the dynamic package size; A package-level check module for performing a package-level check on each received data package, and writing the data package into a temporary storage area if the package-level check passes; A block-level check module for performing a block-level check on all data packages in the current logical block when the number of accumulated received data packages reaches the logical block size specified in the shard configuration metadata; A storage space release module for storing the data of the current logical block from the temporary storage area to the permanent storage area if the block-level check passes, and releasing the corresponding storage space in the temporary storage area; A firmware upgrade module for cyclically performing until all the data packages are received, performing an image-level check on the complete firmware image, and performing firmware upgrade of the device to be upgraded if the image-level check passes.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to realize the steps of the method of any one of claims 1 to 7.

10. A readable storage medium, the readable storage medium storing a computer program, characterized in that, The computer program is executed by the processor to realize the steps of the method of any one of claims 1 to 7.

Images