Low-power-consumption embedded device anti-bricking OTA method and system

Abstract

The application discloses a low-power-consumption embedded device anti-bricking OTA method, comprising the following steps: step 1, constructing an OTA multidimensional state vector of a wake-up period; step 2, based on the OTA state vector, composing an OTA state sequence, inputting a preset GRU predictor, and obtaining an OTA transmission capacity prediction value in the next wake-up period; step 3, constructing an OTA comprehensive scheduling factor, and sequentially calculating a total amount of firmware data allowed to be downloaded in the current wake-up period, a data block quantity planned to be downloaded and a data block size; step 4, performing CRC check on firmware fragment data corresponding to the data block quantity and the data block size by a device controller, writing a data block passing the check into a corresponding firmware offset address in a BackOTA partition, or adding a data block failing the check into a retransmission set; and step 5, updating an OTA upgrade completion ratio, and judging whether switching to a new APP operation is allowed according to the OTA upgrade completion ratio.

Description

Technical Field

[0001] This invention relates to the field of anti-brick OTA (Over-The-Air) technology, and more particularly to a method and system for preventing bricking OTA in low-power embedded devices. Background Technology

[0002] With the rapid development of IoT technology, remote firmware upgrades have become an important means of software maintenance and function updates for embedded devices. OTA (Over-The-Air) technology can upgrade device programs without on-site manual maintenance and is widely used in smart grids, ship monitoring, smart agriculture, industrial control, and environmental monitoring. However, for embedded devices operating in low-power, short-wake-up modes, traditional OTA upgrade methods are prone to problems such as upgrade failures, high communication traffic, and device degradation due to short online time, unstable communication links, and limited storage resources. Therefore, improving the reliability and efficiency of OTA upgrades for low-power embedded devices has become a current research hotspot.

[0003] To improve the reliability of OTA upgrades for embedded devices, scholars both domestically and internationally have conducted the following research: Halder et al. proposed an OTA upgrade security framework, studying key technologies such as authentication, integrity verification, rollback recovery, and secure communication, thus improving the security of the OTA upgrade process. However, this method mainly focuses on the security mechanisms during the OTA upgrade process, without in-depth research on how to improve upgrade efficiency and reduce communication overhead under short-term online conditions for low-power devices. Arakadakis et al. proposed a Firmware Over-The-Air (FOTA) technology for IoT devices, summarizing key OTA technologies such as firmware block transmission, breakpoint resumption, integrity verification, and security authentication, and pointing out that resource-constrained devices still suffer from long upgrade times, high communication overhead, and insufficient upgrade reliability. Although this research proposes using firmware block download and breakpoint resumption to improve the upgrade success rate, its data block size and download strategy are fixed, making it impossible to dynamically adjust the download process according to real-time network conditions. Abdelfadeel et al. proposed a firmware fragmentation upgrade method for low-speed wireless networks in Long Range Wide Area Networks (LoRaWAN), improving OTA upgrade efficiency in low-bandwidth network environments through multicast transmission and data fragmentation techniques. However, this method is primarily designed for LoRaWAN networks and does not consider the impact of network quality changes on download strategies, nor is it optimized for low-power short-term wake-up devices. Furthermore, many recent studies have proposed an A / B dual-partition upgrade mechanism, which establishes two application partitions (primary and backup) and automatically rolls back to the old version when a new firmware upgrade fails, improving the reliability of OTA upgrades. However, this method requires the device to store two complete copies of the application, consuming significant Flash storage space and is unsuitable for resource-constrained, low-cost embedded devices. Additionally, this type of method mainly relies on Cyclic Redundancy Check (CRC) failures, abnormal program exits, or watchdog resets to determine application anomalies; it is a passive recovery mechanism after a fault occurs and cannot predict device operational risks in advance.

[0004] In summary, existing OTA upgrade technologies mainly focus on upgrade security, dual-partition rollback, breakpoint resumption, and firmware fragmented transmission, achieving some results in improving upgrade reliability. However, most existing technologies still employ fixed data block download strategies, lacking intelligent prediction capabilities for network quality change trends and failing to dynamically adjust the upgrade process based on real-time communication status. Simultaneously, existing recovery mechanisms primarily rely on passive recovery after device failure, lacking the ability to predict application runtime status in advance, making it difficult to meet the high-reliability, low-power OTA upgrade requirements of low-power, short-wake-up embedded devices. To address these issues, this invention proposes a low-power embedded device anti-brick OTA method and system based on a three-partition architecture and fragmented transmission. Building upon the three-partition recovery architecture, a network state prediction mechanism based on a gated recurrent unit (GRU) is introduced to implement an adaptive fragmented download strategy. Combined with a device runtime status prediction mechanism, proactive prediction and recovery of application anomalies are achieved, thereby further improving the OTA upgrade success rate and reducing communication traffic and system power consumption. Summary of the Invention

[0005] Purpose of the invention: The technical problem to be solved by the present invention is to provide a low-power embedded device anti-brick OTA method and system to address the shortcomings of the existing technology.

[0006] To address the aforementioned technical problems, this invention discloses a low-power embedded device anti-brick OTA method and system. Addressing the issues of traditional low-power embedded device OTA upgrades failing to predict network changes and being prone to download failures due to network fluctuations, this invention introduces an OTA transmission capability prediction method based on a multi-dimensional state fusion GRU. This method integrates multi-dimensional information such as the device's historical network status, communication quality, remaining wake-up time, and OTA upgrade progress to predict the OTA transmission capability for the next wake-up cycle. This provides a predictive basis for firmware fragment downloads, effectively reducing download timeouts and duplicate transmission probabilities, and improving OTA upgrade efficiency and communication reliability.

[0007] To address the problem of fixed firmware fragment download strategies and the inability to dynamically adjust based on device operating status during traditional OTA upgrades, this invention proposes a method for constructing a comprehensive OTA scheduling factor based on multi-dimensional state fusion, and on this basis, builds a prediction-driven intelligent OTA scheduling mechanism. The comprehensive OTA scheduling factor integrates OTA transmission capacity prediction results, remaining wake-up time, upgrade progress, power margin, Flash write status, and APP operating health status to comprehensively and quantitatively evaluate the current OTA upgrade conditions of the device. Furthermore, based on the comprehensive OTA scheduling factor, the firmware data block size, the number of downloads per cycle, and the download order are dynamically determined, thereby improving communication link utilization, shortening the OTA upgrade cycle, reducing device power consumption and communication traffic consumption, and improving the stability and reliability of OTA upgrades for low-power embedded devices.

[0008] A method for preventing over-the-air (OTA) updates in low-power embedded devices, comprising the following steps:

[0009] Step 1: Construct the OTA multidimensional state vector of the wake-up cycle during the boot process phase after the device is powered on or periodically woken up;

[0010] Step 2: Normalize the OTA state vectors for each wake-up cycle and form an OTA state sequence. ,Will Input the preset GRU predictor to obtain the predicted value of OTA transmission capability in the next wake-up cycle;

[0011] Step 3: Using the OTA transmission capability prediction value obtained in Step 2 as input, construct the OTA comprehensive scheduling factor, and calculate the total amount of firmware data allowed to be downloaded, the number of data blocks to be downloaded, and the size of the data blocks in this wake-up cycle. Step 4: The device requests firmware fragment data corresponding to the number and size of the data blocks from the OTA server through the communication module. After the data blocks are received, the device controller performs CRC verification on them, and according to the verification result, writes the data blocks that pass the verification to the corresponding firmware offset address in the BackOTA partition, or adds the data blocks that fail the verification to the retransmission set.

[0012] Step 5: Update the OTA upgrade completion rate and determine whether to allow switching to the new APP (Application) to run based on this.

[0013] No. The OTA multidimensional state vector for each wake-up cycle is:

[0014]

[0015] In the formula, This represents the OTA multidimensional state vector corresponding to the k-th wake-up cycle; This indicates the current boot partition status read by Boot; This indicates the availability status of the Backup OTA (Backup OTA) upgrade partition. This represents the overall communication quality value during the wake-up cycle; This indicates the effective transmission rate observed during the wake-up cycle; This indicates the percentage of data blocks with errors during the wake-up cycle; This indicates the remaining data transmission time available for OTA within the wake-up cycle; Indicates the percentage of OTA upgrades completed; Indicates the power margin status of the device; Indicates that the Flash storage is in a write-safe state; This indicates the healthy running status of the app; the superscript T indicates that the vector is transposed.

[0016] Step 2 specifically includes:

[0017] Step 2-1: Normalize the OTA state vector of the kth wake-up cycle:

[0018]

[0019] In the formula, This represents the normalized OTA state vector; Represents the state normalization scaling matrix; This represents the OTA multidimensional state vector corresponding to the k-th wake-up cycle; The preset lower bound vector represents each state variable in each state vector;

[0020] Step 2-2: Form an OTA state sequence from the normalized state vectors of m consecutive wake-up cycles:

[0021]

[0022] In the formula, This represents the OTA multidimensional state fusion sequence used for prediction; represents the OTA state vector after normalization of multiple consecutive wake-up cycles; m represents the number of historical wake-up cycles involved in the prediction.

[0023] Steps 2-3: Fuse the multidimensional state sequence Input the preset GRU predictor to obtain the predicted OTA transmission capacity value for the next wake-up cycle:

[0024]

[0025] In the formula, This represents the predicted value of the OTA transmission capability that can be stably completed within the (k+1)th wake-up cycle. This represents the GRU mapping function used for OTA transmission capability prediction; This represents the OTA multidimensional state fusion sequence used for prediction.

[0026] Based on the above multi-dimensional state fusion GRU model, the predicted value of OTA transmission capability for the next wake-up cycle can be obtained, and this prediction result serves as the input for subsequent OTA integrated scheduling.

[0027] Step 3 specifically involves:

[0028] Step 3-1: Construct the OTA comprehensive scheduling factor, and then calculate the total amount of firmware data that can be downloaded in the current wake-up cycle based on the OTA transmission capacity prediction result, the OTA comprehensive scheduling factor, the remaining firmware data volume, the remaining wake-up time and the Flash write capability, and determine the number of data blocks planned to be downloaded in this cycle accordingly.

[0029] Step 3-2: Based on the total amount of data allowed to be downloaded, the planned number of data blocks to be downloaded, and the historical error rate of data blocks, adaptively calculate the actual size of each data block.

[0030] The OTA overall scheduling factor for the kth wake-up cycle is:

[0031]

[0032]

[0033] In the formula, This represents the OTA comprehensive scheduling factor for the k-th wake-up cycle; Indicates the predicted first Predicted OTA transmission capability that can be stably completed within one wake-up cycle; Reference value for the maximum OTA transmission capacity allowed within a wake-up cycle; Indicates the percentage of OTA upgrades completed; This represents the remaining data transmission time available for OTA during the k-th wake-up cycle; The maximum time reference value available for OTA transmission within one wake-up cycle; Indicates the power margin status of the device; Reference upper limit for backup power margin; Indicates that the Flash storage is in a write-safe state; Indicates the app's healthy operating status; , , , , , This represents the scheduling weight corresponding to each state variable.

[0034] The number of data blocks to be downloaded in the k-th wake-up cycle is:

[0035]

[0036] In the formula, This indicates the number of data blocks scheduled to be downloaded in the k-th wake-up cycle; This represents the total amount of data that can be scheduled for download during the k-th wake-up cycle; Indicates the preset base data block size. This represents the schedulable download amount for the k-th wake-up cycle.

[0037] The CRC check described in step 4 specifically includes: when the first The wake-up cycle CRC check results of each data block At that time, the BackOTA partition will be the first The content of the i-th data block received in each wake-up cycle Write the corresponding firmware offset address to the Flash memory and record that the data block is complete; when When this happens, the BackOTA partition does not update the completion status of the data block and adds the data block to the retransmission set.

[0038] The specific update of the OTA upgrade completion rate in step 5 is as follows: The OTA upgrade completion rate at the start of each wake-up cycle is:

[0039]

[0040] In the formula, Indicates the first The percentage of OTA upgrades completed at the start of each wake-up cycle; This indicates the current percentage of OTA upgrades completed. Indicates the number of data blocks planned to be downloaded in this cycle; Indicates the first The wake-up cycle CRC check results for each data block; Indicates the size of the data blocks used in this cycle; This indicates the total amount of data in the firmware to be upgraded.

[0041] when At that time, the complete firmware in the BackOTA partition is hashed to verify the overall integrity of the firmware and to determine whether to allow switching to the new APP. The Boot partition starts the new APP according to the APP switching confirmation flag and enters the trial operation confirmation stage.

[0042] Beneficial effects:

[0043] Compared to existing technologies, this invention constructs a multi-dimensional OTA state vector and uses a gated loop unit to predict the OTA transmission capability for the next wake-up cycle, enabling the device to anticipate changes in firmware data transmission capability. Based on this, it dynamically determines the total amount of firmware data, the number of data blocks, and the size of data blocks that can be downloaded in the current wake-up cycle by integrating the predicted OTA transmission capability, upgrade completion rate, remaining wake-up time, power margin, Flash write security status, and APP operating health status, thus preventing the download volume from exceeding the capacity of the current communication link and device resources. The device receives firmware fragment data through the communication module and writes data blocks that pass CRC verification to the BackOTA partition. Only data blocks that fail verification or have missing sequence numbers are retransmitted, thereby reducing communication traffic caused by download timeouts, invalid transmissions, and duplicate transmissions, and reducing the working time of the wireless communication module and device power consumption. Meanwhile, through the collaborative management between the Boot partition, the current APP partition, and the BackOTA partition, and combined with firmware integrity verification, new APP trial run confirmation, and abnormal rollback mechanisms, the device can still maintain the original APP operation or perform recovery upgrades when OTA download is interrupted, firmware verification fails, or the new APP runs abnormally. This improves the success rate, reliability, and security of OTA upgrades for low-power embedded devices and reduces the risk of the device becoming bricked during the upgrade process. Attached Figure Description

[0044] Figure 1 This is a flowchart of the method.

[0045] Figure 2 This is the prediction result for OTA capabilities.

[0046] Figure 3 Upgrade success rate under different packet loss rates.

[0047] Figure 4 The average OTA upgrade time is given under different network environments.

[0048] Figure 5 This represents the average retransmission traffic for OTA under different network environments. Detailed Implementation

[0049] A method for preventing over-the-air (OTA) updates in low-power embedded devices, comprising the following steps:

[0050] Step 1: After the device powers on or is periodically woken up, it enters the Boot phase. The bootloader (Boot) first reads the status of the three partitions (current boot partition status, BackOTA partition availability status, and BackOTA partition availability status) and the upgrade status left over from the previous OTA process, including the current boot partition status, BackOTA partition availability status, completed upgrade progress, rollback partition status, and abnormal reset records. If the Boot detects that the current application (APP) can run normally and there are no incomplete OTA tasks, it jumps to the normal operation of the APP; if there are incomplete OTA tasks, upgrade interruption records, or APP abnormal flags, it enters the BackOTA partition to perform the recovery upgrade process.

[0051] To avoid relying solely on a single startup flag to determine whether a device should continue upgrading or revert to previous operation, this invention constructs a third [system / mechanism] during the Boot phase. OTA multidimensional state vector for each wake-up cycle:

[0052]

[0053]

[0054] In the formula, This represents the OTA multidimensional state vector corresponding to the k-th wake-up cycle; This indicates the current boot partition status read by Boot; This indicates the availability status of the Backup OTA (Backup OTA) upgrade partition. This represents the overall communication quality value during the wake-up cycle; This indicates the effective data transmission rate of the OTA firmware observed during the wake-up cycle. This indicates the percentage of data blocks with errors during the wake-up cycle; This indicates the remaining data transmission time available for OTA within the wake-up cycle; Indicates the percentage of OTA upgrades completed; Indicates the power margin status of the device; Indicates that the Flash storage is in a write-safe state; This indicates the health status of the app; the superscript T indicates that the vector is transposed. This represents the normalized received signal strength. Indicates the packet loss rate; Indicates the retransmission ratio; , and This indicates the corresponding weight.

[0055] By constructing the above-mentioned OTA multidimensional state vector, this invention provides a unified description of startup security, communication capabilities, upgrade progress, and device resource status, providing state input for subsequent OTA transmission capability prediction and fragment download scheduling.

[0056] 2) After BackOTA partition startup, this invention does not use a fixed-size, fixed-number data block download method. Instead, it first fuses the OTA states from multiple wake-up cycles to predict the data transmission capability that can be stably completed in the next wake-up cycle. The short online time of low-power devices and good communication quality in the current cycle do not guarantee stable transmission in the next cycle. Conversely, if the download strategy is determined solely based on the Received Signal Strength Indicator (RSSI) or the current rate, download timeouts or duplicate transmissions are likely to occur in the next cycle. Therefore, this invention utilizes a multi-dimensional state fusion GRU to predict OTA transmission capability. This prediction object is not RSSI, nor a single link indicator, but rather the data transmission capability that can be stably completed in the next wake-up cycle.

[0057] To ensure that states with different dimensions can be processed uniformly, the OTA state vector of the kth wake-up cycle is first normalized:

[0058]

[0059] In the formula, This represents the normalized OTA state vector; Represents the state normalization scaling matrix; This represents the OTA multidimensional state vector corresponding to the k-th wake-up cycle; This represents the preset lower bound vector for each state variable in each state vector.

[0060] Furthermore, the normalized state vectors of m consecutive wake-up cycles are used to form an OTA state sequence:

[0061]

[0062] In the formula, This represents the OTA multidimensional state fusion sequence used for prediction; represents the OTA state vector after normalization of multiple consecutive wake-up cycles; m represents the number of historical wake-up cycles involved in the prediction.

[0063] Will By inputting a preset GRU predictor, the predicted OTA transmission capacity for the next wake-up cycle can be obtained:

[0064]

[0065] In the formula, This represents the predicted value of the OTA transmission capability that can be stably completed within the (k+1)th wake-up cycle. This represents the GRU mapping function used for OTA transmission capability prediction; This represents the OTA multidimensional state fusion sequence used for prediction.

[0066] Based on the above multi-dimensional state fusion GRU model, the predicted value of OTA transmission capability for the next wake-up cycle can be obtained, and this prediction result serves as the input for subsequent OTA integrated scheduling.

[0067] 3) After obtaining the predicted OTA transmission capacity, this invention further establishes an OTA comprehensive scheduling model. The predicted OTA transmission capacity reflects the data transmission capacity for the next wake-up cycle, but whether the device continues to perform OTA upgrades and how much firmware data to download also requires comprehensive consideration of factors such as OTA upgrade progress, remaining wake-up time, power margin, Flash write status, and APP running status. Therefore, this invention constructs an OTA comprehensive scheduling factor to comprehensively evaluate the device's current upgrade capability.

[0068] Define the OTA comprehensive scheduling factor for the k-th wake-up cycle as:

[0069]

[0070]

[0071] In the formula, This represents the OTA comprehensive scheduling factor for the k-th wake-up cycle; Indicates the predicted first Predicted OTA transmission capability that can be stably completed within one wake-up cycle; Reference value for the maximum OTA transmission capacity allowed within a wake-up cycle; Indicates the percentage of OTA upgrades completed; This represents the remaining data transmission time available for OTA during the k-th wake-up cycle; The maximum time reference value available for OTA transmission within one wake-up cycle; Indicates the power margin status of the device; Reference upper limit for backup power margin; Indicates that the Flash storage is in a write-safe state; Indicates the app's healthy operating status; , , , , , This represents the scheduling weight corresponding to each state variable.

[0072] The OTA comprehensive scheduling factor comprehensively reflects the predicted transmission capacity, upgrade progress, and equipment operating status. When the comprehensive scheduling factor is large, it indicates that the equipment has good OTA upgrade conditions, and the data download volume of this wake-up cycle can be appropriately increased; when the comprehensive scheduling factor is small, the download scale should be reduced or the current round of OTA upgrade should be suspended to ensure the stability and security of the upgrade process.

[0073] 4) After obtaining the OTA comprehensive scheduling factor, the present invention calculates the total amount of firmware data that can be downloaded in the current wake-up cycle based on the OTA transmission capacity prediction result, the OTA comprehensive scheduling factor, the remaining firmware data volume, the remaining wake-up time and the Flash write capability, and determines the number of data blocks planned to be downloaded in this cycle accordingly.

[0074] Define the schedulable download amount for the k-th wake-up cycle as:

[0075]

[0076] In the formula, This represents the total amount of data that can be scheduled for download during the k-th wake-up cycle; This indicates the predicted OTA transmission capability for the next wake-up cycle; Indicates the OTA overall scheduling factor; This indicates the amount of firmware data that remains to be downloaded; This indicates the remaining data transmission time available for OTA within the current wake-up cycle; Indicates the current effective transmission rate; Indicates that the Flash storage is in a write-safe state; This indicates a reference value for the amount of data that can be written to the current Flash memory.

[0077] Furthermore, the number of data blocks scheduled to be downloaded in the k-th wake-up cycle is defined as:

[0078]

[0079] In the formula, This indicates the number of data blocks scheduled to be downloaded in the k-th wake-up cycle; This represents the total amount of data that can be scheduled for download during the k-th wake-up cycle; This indicates the preset base data block size.

[0080] The above calculations can be used to dynamically determine the data download size for this wake-up cycle based on the current state of the device, providing a basis for subsequent data block size calculations.

[0081] 5) After determining the number of data blocks to be downloaded in this wake-up cycle, the present invention further adaptively calculates the actual size of each data block based on the total amount of data allowed to be downloaded, the number of data blocks to be downloaded, and the historical data block error ratio, so as to balance data transmission efficiency and transmission reliability.

[0082] Define the data block size for the k-th wake-up cycle as:

[0083]

[0084] In the formula, This indicates the size of the data block used in the k-th wake-up cycle; This indicates a limit calculation that restricts the calculation results to between a preset lower limit and a preset upper limit; Indicates the total amount of data that is allowed to be downloaded during the scheduling process; Indicates the number of data blocks planned to be downloaded; Indicates the percentage of data blocks with errors; Indicates the lower limit of the data block size; This indicates the upper limit of the data block size.

[0085] Based on the above calculations, the data block size can be dynamically adjusted according to the device's current communication status and historical transmission data. When the data block error rate is low, the size of a single data block can be increased appropriately to improve data transmission efficiency; when the error rate is high, the data block size can be decreased appropriately to reduce the retransmission overhead caused by a single transmission failure, thereby improving the stability of the OTA upgrade process.

[0086] 6) Based on the number and size of data blocks determined in step 5, the device requests the corresponding firmware fragment data from the OTA server via the communication module and temporarily stores the received data in the BackOTA partition. Each data block contains a data block sequence number, data length, CRC reference value, and firmware offset address. After receiving the data block, the device controller immediately performs a CRC check and determines whether to write it to the corresponding Flash firmware offset address in the BackOTA partition or add it to the retransmission set based on the check result. Define the... The wake-up cycle The CRC check results for each data block are as follows:

[0087]

[0088] In the formula, This represents the CRC check result of the i-th data block in the k-th wake-up cycle; CRC stands for Cyclic Redundancy Check. Indicates the first The content of the i-th data block received in each wake-up cycle; This represents the CRC reference value corresponding to the i-th data block in the k-th wake-up cycle issued by the server.

[0089] when At that time, the BackOTA partition will Write the corresponding firmware offset address to the Flash memory and record that the data block is complete; when When this happens, the BackOTA partition does not update the completion status of the block and adds the block to the retransmission set.

[0090] Definition of the first The set of retransmission requests for each wake-up cycle is:

[0091]

[0092] In the formula, Indicates the first Each wake-up cycle requires a set of data block sequence numbers that need to be retransmitted. Indicates the first The wake-up cycle CRC check results for each data block This indicates that the CRC check failed. Indicates the first The wake-up cycle Results of the sequence number continuity assessment for each data block This indicates that the sequence number of this data block is not consecutive relative to the previous confirmed data block or that there is a missing sequence number.

[0093] Data blocks in the retransmission request set are prioritized for re-downloading within the remaining time of the current wake-up cycle; if the remaining time of the current cycle is insufficient, they are saved to the OTA status record and retransmitted with priority in the next wake-up cycle.

[0094] 7) After completing the data reception, CRC verification and retransmission processing of the current wake-up cycle, this invention updates the OTA upgrade completion ratio and synchronously updates the OTA multidimensional state vector to provide the latest state information for OTA transmission capability prediction and comprehensive scheduling in the next wake-up cycle.

[0095] Definition of the first The OTA upgrade completion rate at the start of each wake-up cycle is:

[0096]

[0097] In the formula, Indicates the first The percentage of OTA upgrades completed at the start of each wake-up cycle; This indicates the current percentage of OTA upgrades completed. Indicates the number of data blocks planned to be downloaded in this cycle; Indicates the first The wake-up cycle CRC check results for each data block; Indicates the size of the data blocks used in this cycle; This indicates the total amount of data in the firmware to be upgraded.

[0098] Furthermore, based on the transmission, verification, retransmission, and device status changes in this cycle, the OTA state vector for the next wake-up cycle is updated:

[0099]

[0100] In the formula, Indicates the first The OTA multidimensional state vector corresponding to each wake-up cycle; This represents the OTA status update function; This represents the OTA multidimensional state vector corresponding to this cycle; Indicates the number of data blocks planned to be downloaded in this cycle; Indicates the size of the data blocks used in this cycle; This represents the set of data block sequence numbers that need to be retransmitted in this cycle; Indicates the first The percentage of OTA upgrades completed at the start of each wake-up cycle; Indicates the remaining available time at the end of this period; This indicates the power margin status of the equipment at the end of the current cycle. Indicates that the Flash storage is in a write-safe state; This indicates the healthy status of the app.

[0101] The above formula ensures that only data blocks that pass the CRC check will be included in the OTA completion ratio; data blocks that fail the check or have missing sequence numbers will not be incorrectly added. Simultaneously, the number of downloaded blocks, block size, retransmission set, completion rate, and device status of this cycle are fed back to the next cycle, enabling the next round of GRU prediction and OTA integrated scheduling to be executed based on the latest status. This indicates that the firmware download is not yet complete, and the device will proceed according to... and Decide whether to continue downloading for a short period or hibernate early; if If the result is positive, it means that all firmware data blocks have been received and the system will proceed to the next step of performing a complete hash verification (HashVerification, Hash).

[0102] 8) When In this invention, the complete firmware in the BackOTA partition is hashed to verify the overall integrity of the firmware and to determine whether to allow switching to the new APP.

[0103] Define the hash verification result of the complete firmware in the BackOTA partition as follows:

[0104]

[0105] In the formula, This represents the hash value calculated from the complete firmware received in the BackOTA partition; This represents the complete firmware hash calculation function; This represents all data blocks concatenated according to the firmware offset address order; This indicates the total number of data blocks contained in the complete firmware.

[0106] Furthermore, the APP switching confirmation flag is defined as:

[0107]

[0108] In the formula, This indicates the confirmation flag for app switching; This represents the hash value calculated from the complete firmware received in the BackOTA partition; This represents the complete firmware hash reference value issued by the OTA server; Indicates the first Percentage of OTA upgrades completed; This indicates that the Flash storage is in a safe write state.

[0109] when When the bootloader marks the new app as ready for trial operation, it will switch to the new app on the next boot; otherwise, it will keep the original app running and retain the upgrade status in the BackOTA partition, and continue to perform the recovery upgrade in the next OTA upgrade task.

[0110] 9) The Boot partition starts the new APP based on the APP switching confirmation flag and enters the trial operation confirmation phase. Passing the hash verification only indicates that the firmware integrity meets the requirements, but it cannot guarantee that the new APP can run stably in the current device environment. Therefore, this invention monitors the trial operation of the new APP and decides whether to officially launch the new APP based on its running status.

[0111] Define the confirmation result of running the new APP as follows:

[0112]

[0113] In the formula, This indicates the confirmation result of the new app running; This indicates the new app is running healthily; This indicates the health status threshold that allows the new app to run; This indicates the number of abnormal resets that occurred during the trial operation phase of the new app; This indicates the maximum number of allowed abnormal resets.

[0114] when When =1, the Boot partition updates the new APP status to the official running state and clears the temporary upgrade flag, retransmission set, and OTA upgrade record in the BackOTA partition; when At this time, Boot will prevent the launch of new apps and revert to the original app, and re-execute the OTA recovery process according to the current upgrade status.

[0115] 7. Experimental Verification

[0116] (1) Analysis of OTA transmission capability prediction results of different methods

[0117] from Figure 2 As can be seen, the actual OTA transmission capacity fluctuates significantly with changes in network status. During periods of rapid network quality degradation, the fixed-means prediction method exhibits substantial prediction lag, resulting in a large deviation between its prediction curve and the actual trend. While the single-state GRU can learn historical patterns, it still suffers from errors during sudden network fluctuations because it relies on only a single network state for prediction. This invention employs a multi-dimensional state fusion GRU, using information such as communication quality, effective transmission rate, remaining wake-up time, OTA upgrade progress, power margin, and Flash write status as prediction inputs, making the prediction results closer to the actual transmission capacity.

[0118] As shown in Table 1, the mean absolute error (MAE), root mean square error (RMSE), and mean absolute percentage error (MAPE) of the method of the present invention are all lower than those of the comparative methods, indicating that the proposed multi-dimensional state fusion prediction model can more accurately predict the OTA transmission capability in the next wake-up cycle, providing a reliable basis for subsequent dynamic scheduling.

[0119] Table 1. OTA transmission capability prediction errors of different methods

[0120] method MAE (Byte) RMSE (Byte) MAPE (%) Fixed Mean Forecasting 67.843 82.841 12.049 Single-state GRU 24.781 30.609 4.4966 Multidimensional State Fusion GRU 9.6486 11.424 1.7532

[0121] (2) Analysis of OTA upgrade success rate under different packet loss rates

[0122] Figure 3The success rates of various OTA upgrade methods under different network packet loss rates were compared. It can be seen that when the network packet loss rate is low, all methods maintain a high upgrade success rate; as the network packet loss rate gradually increases, the upgrade success rate of all methods decreases, but the method of this invention consistently maintains the highest upgrade success rate. When the network packet loss rate reaches 20%, the upgrade success rate of the method of this invention remains at around 90%, while the fixed-block OTA method has dropped to around 70%. The main reason for this is that the fixed download strategy cannot dynamically adjust the data block size according to the network status, easily leading to duplicate transmissions due to data block download failures; although A / B dual-partition OTA can achieve rollback recovery after upgrade failures, it still uses a fixed download strategy, thus offering limited improvement. This invention dynamically adjusts the data block size and the number of downloads per cycle based on the predicted OTA transmission capacity, enabling the device to complete more reasonable data transmission under current network conditions, effectively reducing the probability of upgrade failures and improving the reliability of OTA upgrades in complex network environments.

[0123] (3) OTA upgrade time analysis under different network environments

[0124] Figure 3 The average time required to complete firmware upgrades using different OTA methods under three network environments—good, average, and poor—is presented. Experimental results show that in a good network environment, the upgrade times of each method are relatively similar; however, as the network environment gradually deteriorates, the fixed-block OTA method experiences a significant increase in upgrade time due to the increased number of retransmissions. The method of this invention has an average upgrade time of approximately 11 minutes in an average network environment and approximately 17 minutes in a poor network environment, both significantly shorter than the fixed-block OTA method. Compared to fixed-block OTA, the upgrade time of this invention is reduced by approximately 28% in a poor network environment. This is because this invention can dynamically determine the data download scale of the current wake-up cycle based on the OTA comprehensive scheduling factor, avoiding requests for data exceeding the current network transmission capacity, thereby reducing data download timeouts and duplicate transmissions, and improving OTA upgrade efficiency.

[0125] (4) OTA retransmission traffic analysis under different network environments

[0126] Figure 4The average retransmission traffic generated by various OTA methods under different network environments was compared. As the network environment deteriorates, the retransmission traffic of the fixed-block OTA method increases rapidly, reaching over 220kB in poor network conditions. The method of this invention, under the same conditions, only generates approximately 110kB, reducing retransmission traffic by about 50%. This is because the fixed-block strategy uses a uniform data block size; when a data block fails verification, the entire data block needs to be re-downloaded, resulting in a large amount of redundant communication. This invention, by combining historical data block error rates and predictive transmission capabilities, adaptively adjusts the data block size and only retransmits data blocks that fail CRC verification, thus effectively reducing communication traffic and improving link utilization. Simultaneously, the reduction in communication traffic further reduces the operating time of the wireless communication module, which is beneficial for reducing the overall energy consumption during the OTA upgrade process of low-power embedded devices and improving system operational stability.

[0127] This invention provides a low-power embedded device anti-over-application (OTA) method and system for preventing device bricking. Many methods and approaches exist for implementing this technical solution; the above description is merely a preferred embodiment. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this invention, and these improvements and modifications should also be considered within the scope of protection of this invention. All components not explicitly stated in this embodiment can be implemented using existing technologies.

Claims

1. A method for preventing over-the-air (OTA) bricking in low-power embedded devices, characterized in that, The steps include the following: Step 1: Construct the OTA multidimensional state vector of the wake-up cycle during the boot process phase after the device is powered on or periodically woken up; Step 2: Normalize the OTA state vectors for each wake-up cycle and form an OTA state sequence. ,Will Input the preset GRU predictor to obtain the predicted value of OTA transmission capability in the next wake-up cycle; Step 3: Using the OTA transmission capability prediction value obtained in Step 2 as input, construct the OTA comprehensive scheduling factor, and calculate the total amount of firmware data allowed to be downloaded, the number of data blocks to be downloaded, and the size of the data blocks in this wake-up cycle. Step 4: The device requests firmware fragment data corresponding to the number and size of the data blocks from the OTA server through the communication module. After the data blocks are received, the device controller performs CRC verification on them, and according to the verification result, writes the data blocks that pass the verification to the corresponding firmware offset address in the BackOTA partition, or adds the data blocks that fail the verification to the retransmission set. Step 5: Update the OTA upgrade completion rate and determine whether to allow switching to the new app.

2. The method for preventing over-the-air (OTA) bricking in low-power embedded devices according to claim 1, characterized in that, No. The OTA multidimensional state vector for each wake-up cycle is: In the formula, This represents the OTA multidimensional state vector corresponding to the k-th wake-up cycle; This indicates the current boot partition status read by Boot; Indicates the availability status of the backup OTA upgrade partition; This represents the overall communication quality value during the wake-up cycle; This indicates the effective transmission rate observed during the wake-up cycle; This indicates the percentage of data blocks with errors during the wake-up cycle; This indicates the remaining data transmission time available for OTA within the wake-up cycle; Indicates the percentage of OTA upgrades completed; Indicates the power margin status of the device; Indicates that the Flash storage is in a write-safe state; This indicates the healthy running status of the app; the superscript T indicates that the vector is transposed.

3. The method for preventing over-the-air (OTA) bricking in low-power embedded devices according to claim 1, characterized in that, Step 2 specifically includes: Step 2-1: Normalize the OTA state vector of the kth wake-up cycle: In the formula, This represents the normalized OTA state vector; Represents the state normalization scaling matrix; This represents the OTA multidimensional state vector corresponding to the k-th wake-up cycle; The preset lower bound vector represents each state variable in each state vector; Step 2-2: Form an OTA state sequence from the normalized state vectors of m consecutive wake-up cycles: In the formula, This represents the OTA multidimensional state fusion sequence used for prediction; represents the OTA state vector after normalization of multiple consecutive wake-up cycles; m represents the number of historical wake-up cycles involved in the prediction. Steps 2-3: Fuse the multidimensional state sequence Input the preset GRU predictor to obtain the predicted OTA transmission capacity value for the next wake-up cycle: In the formula, This represents the predicted value of the OTA transmission capability that can be stably completed within the (k+1)th wake-up cycle. This represents the GRU mapping function used for OTA transmission capability prediction; This represents the OTA multidimensional state fusion sequence used for prediction.

4. The method for preventing over-the-air (OTA) bricking in low-power embedded devices according to claim 1, characterized in that, Step 3 specifically involves: Step 3-1: Construct the OTA comprehensive scheduling factor, and then calculate the total amount of firmware data that can be downloaded in the current wake-up cycle based on the OTA transmission capacity prediction result, the OTA comprehensive scheduling factor, the remaining firmware data volume, the remaining wake-up time and the Flash write capability, and determine the number of data blocks planned to be downloaded in this cycle accordingly. Step 3-2: Based on the total amount of data allowed to be downloaded, the planned number of data blocks to be downloaded, and the historical error rate of data blocks, adaptively calculate the actual size of each data block.

5. A method for preventing over-the-air (OTA) bricking in low-power embedded devices according to claim 4, characterized in that, The OTA overall scheduling factor for the kth wake-up cycle is: In the formula, This represents the OTA comprehensive scheduling factor for the k-th wake-up cycle; Indicates the predicted first Predicted OTA transmission capability that can be stably completed within one wake-up cycle; Reference value for the maximum OTA transmission capacity allowed within a wake-up cycle; Indicates the percentage of OTA upgrades completed; This represents the remaining data transmission time available for OTA during the k-th wake-up cycle; The maximum time reference value available for OTA transmission within one wake-up cycle; Indicates the power margin status of the device; Reference upper limit for backup power margin; Indicates that the Flash storage is in a write-safe state; Indicates the app's healthy operating status; , , , , , This represents the scheduling weight corresponding to each state variable.

6. A method for preventing over-the-air (OTA) bricking in low-power embedded devices according to claim 4, characterized in that, The number of data blocks to be downloaded in the k-th wake-up cycle is: In the formula, This indicates the number of data blocks scheduled to be downloaded in the k-th wake-up cycle; This represents the total amount of data that can be scheduled for download during the k-th wake-up cycle; Indicates the preset base data block size. This represents the schedulable download amount for the k-th wake-up cycle.

7. A method for preventing over-the-air (OTA) bricking in low-power embedded devices according to claim 1, characterized in that, The CRC check described in step 4 specifically includes: when the first The wake-up cycle CRC check results of each data block At that time, the BackOTA partition will be the first The content of the i-th data block received in each wake-up cycle Write the corresponding firmware offset address to the Flash memory and record that the data block is complete; when When this happens, the BackOTA partition does not update the completion status of the data block and adds the data block to the retransmission set.

8. A method for preventing over-the-air (OTA) bricking in low-power embedded devices according to claim 4, characterized in that, The specific update of the OTA upgrade completion rate in step 5 is as follows: The OTA upgrade completion rate at the start of each wake-up cycle is: In the formula, Indicates the first The percentage of OTA upgrades completed at the start of each wake-up cycle; This indicates the current percentage of OTA upgrades completed. Indicates the number of data blocks planned to be downloaded in this cycle; Indicates the first The wake-up cycle CRC check results for each data block; Indicates the size of the data blocks used in this cycle; This indicates the total amount of data in the firmware to be upgraded.

9. A method for preventing over-the-air (OTA) bricking in low-power embedded devices according to claim 8, characterized in that, when At this time, the complete firmware in the BackOTA partition is hashed to verify the overall integrity of the firmware, and based on this, it is determined whether to allow switching to the new APP. The Boot partition starts the new APP according to the APP switching confirmation flag and enters the trial operation confirmation stage.

10. A low-power embedded device anti-brick OTA system, characterized in that, The system comprises the method described in any one of claims 1-9.

Images