An OTA upgrade method based on dynamic heartbeat sensing

Abstract

This invention discloses an OTA upgrade method based on dynamic heartbeat perception. The method calculates the appropriate heartbeat cycle for the target terminal based on basic information; collects upgrade-related status data in real time according to the appropriate heartbeat cycle and reports it to the server; verifies the integrity of the status data and determines whether the target terminal has abnormal status parameters based on network parameters, progress parameters, and / or resource parameters; if an abnormal status parameter occurs, a heartbeat enhancement command is sent to the target terminal and anomaly isolation is initiated, executing anomaly handling strategies; if no abnormal status parameter occurs, it determines whether the target terminal's upgrade is complete; if the determination result indicates that the target terminal's upgrade is incomplete, the appropriate heartbeat cycle is adjusted again for data collection; if the determination result indicates that the target terminal's upgrade is complete, the target terminal is marked as upgraded, until all target terminals are marked as upgraded.

Description

Technical Field

[0001] This invention relates to the field of Internet technology, and in particular to an OTA upgrade method based on dynamic heartbeat sensing. Background Technology

[0002] Currently, with the number of terminal devices growing exponentially (for example, the scale of terminals in industrial IoT scenarios can reach hundreds of thousands or more, and the batch upgrade needs of vehicle terminals can cover thousands of units at a time), the industry has put forward higher requirements for the efficiency, reliability, and bandwidth adaptability of remote batch OTA upgrades. The traditional on-site manual upgrade and offline flashing mode is completely unfeasible in the face of massive numbers of devices. Existing OTA upgrades have problems such as heartbeat cycle imbalance, high cost of full verification, and poor scenario adaptability.

[0003] Mainstream solutions rely on fixed heartbeat period status reporting mechanisms, which cannot balance the core contradiction between real-time performance and bandwidth consumption. Long-cycle heartbeats (30s-60s) lead to delayed detection of abnormal status parameters, easily causing batch terminal failures; short-cycle heartbeats (less than 5s) cause congestion from massive concurrent reporting by terminals, significantly increasing bandwidth costs. Furthermore, existing technologies use a full-scale verification mode, resulting in delayed data integrity feedback, requiring batch investigation for anomaly handling, and incurring high retry costs. They also fail to consider dynamic differences in terminal upgrade stages, network status, and resource utilization, lacking scenario adaptability and failing to meet the differentiated needs of IoT devices such as low power consumption and high stability of vehicle terminals.

[0004] The application document with application number CN202511552920.9, entitled "A Batch Task Progress Collaborative Management System and Method for OTA Upgrades," uses an upgrade decision component based on simulation modeling to intelligently select the most suitable full or differential upgrade method for each terminal. Secondly, it adopts a parallel evaluation and discrimination architecture to achieve rapid optimization of the upgrade path. Thirdly, it combines a dynamic resource scheduling strategy to adjust the network connection mode and bandwidth allocation of the terminals according to the real-time status, ultimately forming a closed-loop control from decision-making to execution. This existing technology is designed for massive-scale terminals such as IoT and vehicle terminals, and is primarily adapted to the needs of remote batch OTA upgrades. It breaks through the traditional fixed upgrade mode and solves the adaptation problem caused by differences in hardware configuration, network environment, and resource status of terminal groups, improving the compatibility of batch upgrades. However, it does not involve the dynamic adjustment of the heartbeat cycle and defaults to a fixed-cycle reporting mode, which still has the problems of short-cycle congestion and long-cycle lag, and cannot balance the real-time nature of status perception with the efficient use of bandwidth resources. Summary of the Invention

[0005] The purpose of this invention is to provide an OTA upgrade method based on dynamic heartbeat perception, which can balance real-time perception of upgrade status and bandwidth usage, and logically separate target terminals with abnormal status parameters from the batch queue to avoid the mass spread of faults.

[0006] This invention adopts the following technical solution: an OTA upgrade method based on dynamic heartbeat sensing, comprising the following steps:

[0007] S1: After receiving the upgrade task package, the target terminal uploads its basic information to the server. The server calculates the corresponding adaptation heartbeat cycle for the target terminal based on the basic information and sends it to the corresponding target terminal. The basic information includes the upgrade stage of the terminal, the terminal device model, the terminal network quality, and the resource utilization rate.

[0008] S2: The target terminal collects its own upgrade-related status data in real time based on the adaptive heartbeat cycle and reports it to the server. The upgrade-related status data includes network parameters, progress parameters, resource parameters and block verification results.

[0009] S3: After receiving the status data reported by the target terminals in batches, the server verifies the integrity of the status data and determines whether the target terminals have abnormal status parameters based on network parameters, progress parameters and / or resource parameters.

[0010] S4: If the target terminal has abnormal status parameters, the server first sends a heartbeat enhancement command to the target terminal and starts abnormal isolation. Then, it executes the corresponding abnormal handling strategy based on the abnormality type until the abnormal status parameters are repaired. Finally, the server determines whether the upgrade of the target terminal is complete.

[0011] If the server determines that the target terminal does not have any abnormal status parameters, the server will directly determine whether the upgrade of the target terminal is complete.

[0012] S5: If the server determines that the upgrade of the target terminal is not completed, return to step S1;

[0013] If the server determines that the upgrade of the target terminal is complete, the server marks the target terminal as having completed the upgrade, until all target terminals are marked as having completed the upgrade.

[0014] Furthermore, in step S1, the server collects the basic information uploaded by the target terminal, including the following steps:

[0015] S101: The server synchronously pushes upgrade task packages to a batch of target terminals;

[0016] S102: After receiving the upgrade task package pushed by the server, the target terminal performs integrity verification; if the verification fails, it sends a retransmission request for the upgrade task package to the server; if the verification succeeds, it reports the corresponding basic information to the server.

[0017] S103: After receiving the basic information sent by the target terminal, the server obtains the corresponding adaptive heartbeat cycle parameters of the target terminal and sends them to the corresponding target terminal.

[0018] Furthermore, the upgrade task package pushed in S1 includes upgrade package block information and initial parameters of the dynamic heartbeat algorithm; the upgrade package block information includes a checksum, block number, and block information table; the initial parameters of the dynamic heartbeat algorithm include a basic heartbeat period and weight correction parameters.

[0019] Furthermore, in S1, based on the basic heartbeat cycle, the terminal network quality, resource utilization rate, and current upgrade stage in the basic information are respectively weighted and corrected by weight correction parameters to calculate the current terminal's adaptation heartbeat cycle. The upgrade stage includes the download stage, verification stage, and installation stage, with the download stage as the default initial value for the upgrade stage. The weight correction parameters include the upgrade stage weight, network quality weight, and resource utilization rate weight.

[0020] Furthermore, in S2, the complete field or the core field is selected for uploading according to the length of the adaptive heartbeat cycle, and the range of the adaptive heartbeat cycle being short or long is known.

[0021] Furthermore, in S3, the integrity of the status data is verified by checking whether the block verification result matches the preset value.

[0022] Furthermore, in S3, determining whether the target terminal has abnormal status parameters involves the following steps:

[0023] If a network parameter is detected to be greater than or equal to a network parameter threshold, a progress parameter is detected to be greater than or equal to a progress parameter threshold, or a resource parameter is detected to be greater than or equal to a resource parameter threshold, then the target terminal is determined to have an abnormal status parameter.

[0024] If network parameters are detected to be less than the network parameter threshold, progress parameters are detected to be less than the progress parameter threshold, and resource parameters are detected to be less than the resource parameter threshold, then it is determined that the target terminal has no abnormal status parameters.

[0025] Furthermore, in S4, the heartbeat enhancement instruction refers to forcibly modifying the adapted heartbeat cycle to a preset heartbeat cycle; and the abnormal isolation is initiated to logically separate the target terminal with abnormal status parameters from the batch queue.

[0026] Furthermore, in S4, the network parameters, progress parameters, and resource parameters utilize packet loss rate, upgrade progress stagnation duration, and CPU utilization rate, respectively. The server identifies the corresponding anomaly type based on these parameters and executes the corresponding anomaly handling strategy, as follows:

[0027] If the detected packet loss rate is greater than or equal to the network parameter threshold, and the anomaly type is identified as network packet loss, then the network of the target terminal is switched.

[0028] If the upgrade progress stalls for a duration greater than or equal to the progress parameter threshold, and the anomaly type is identified as a single-block processing timeout, then the upgrade packet block that failed to be verified will be retransmitted.

[0029] If the CPU utilization rate is detected to be greater than or equal to the resource parameter threshold, and the anomaly type is identified as network connection interruption, the terminal will trigger a resume interruption.

[0030] Furthermore, in S5, the step of determining whether the upgrade of the target terminal is complete is as follows:

[0031] If all parts of the upgrade task package pass the verification and the current system version is consistent with the target version, then the target terminal is determined to have completed the upgrade.

[0032] If any part of the upgrade task package fails verification or the current system version is inconsistent with the target version, the target terminal is determined to have not completed the upgrade.

[0033] This invention can balance real-time perception of upgrade status and bandwidth usage, enabling precise monitoring of batch terminal upgrade status, millisecond-level capture and rapid processing of anomalies, reducing upgrade failure rate and retry costs, and is compatible with multiple scenarios such as IoT and vehicle terminals, improving the efficiency, reliability and compatibility of remote batch OTA upgrades. Attached Figure Description

[0034] To more clearly illustrate the technical solutions in the embodiments of the present invention or related technologies, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0035] Figure 1 This is a flowchart of the OTA upgrade method based on dynamic heartbeat sensing provided by the present invention. Detailed Implementation

[0036] To make the objectives, technical solutions, and advantages of the embodiments described herein clearer, the technical solutions in the embodiments will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments described herein, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments described herein without creative effort are within the scope of protection of this document. It should be noted that, unless otherwise specified, the embodiments and features described herein can be arbitrarily combined with each other.

[0037] The following is in conjunction with the appendix Figure 1 The present invention will be described in detail with reference to the embodiments:

[0038] An OTA upgrade method based on dynamic heartbeat sensing includes the following steps:

[0039] S1: After receiving the upgrade task package, the target terminal uploads its basic information to the server. The server calculates the corresponding adaptation heartbeat period T for the target terminal based on the basic information and sends it to the corresponding target terminal. The basic information includes the upgrade stage of the terminal, the terminal device model, the terminal network quality, and the resource utilization rate.

[0040] In step S1, the integrity of the received upgrade task package can be verified first. After successful verification, the corresponding basic information can be reported to the server to improve data integrity and upgrade stability.

[0041] Specifically, in this invention, the server collects basic information uploaded by the target terminal, including the following steps:

[0042] S101: The server synchronously pushes upgrade task packages to a batch of target terminals;

[0043] S102: After receiving the upgrade task package pushed by the server, the target terminal performs integrity verification; if the verification fails, it sends a retransmission request for the upgrade task package to the server; if the verification succeeds, it reports the corresponding basic information to the server.

[0044] S103: After receiving the basic information sent by the target terminal, the server obtains the corresponding adaptive heartbeat cycle parameter T of the target terminal and sends it to the corresponding target terminal.

[0045] In step S101, the target terminals in batches, such as IoT devices and vehicle terminals, are upgraded in a task package containing the target version, upgrade package block information, and initial parameters of the dynamic heartbeat algorithm.

[0046] In this invention, the upgrade task package of the target version is divided into blocks of a preset size (50MB-200MB / block). A unique CRC32 checksum and block number are generated for each data block, ultimately forming a block information table. Therefore, the upgrade package block information in the upgrade task package includes the checksum, block number, and block information table. This process is used to split the complete upgrade task package into smaller data blocks for easier transmission and verification. This process is a prerequisite for block-based upgrades and the implementation of the dynamic heartbeat mechanism. The initial parameters of the dynamic heartbeat algorithm include the basic heartbeat period and weight correction parameters.

[0047] In this embodiment, integrity verification can be performed by checking the integrity of the upgrade task package body using the built-in checksum in the upgrade task package.

[0048] In this invention, the basic information of the target terminal in step S1 includes the terminal device model, terminal network quality, and resource utilization rate; the terminal device model is used to apply upgrade package versions adapted to different terminals, the terminal network quality affects the subsequent heartbeat cycle calculation, and the resource utilization rate is collected to avoid resource overload during upgrades.

[0049] Existing technologies can achieve differentiated heartbeat cycle configurations by using feature extraction from multi-model fusion as input to pre-train an adaptive deep reinforcement learning model based on Markov decision processes (MDPs). However, this approach relies on a single, fixed dimension and cannot adapt to the computational needs of a batch of heterogeneous terminals.

[0050] In this invention, in step S103, the current terminal's adaptation heartbeat period T is calculated using a dynamic heartbeat algorithm. Based on the basic heartbeat period and combined with the terminal's network quality and resource utilization rate in the basic information reported by the terminal, as well as the current upgrade stage, the current terminal's adaptation heartbeat period T is calculated after weighting the above parameters using weight correction parameters. The weight correction parameters include upgrade stage weights. Network quality weight and resource utilization weight The upgrade phase includes a download phase, a verification phase, and an installation phase. The default download phase is the initial value for the upgrade phase. Minimum and maximum limits for the adaptation heartbeat period are set to obtain a possible range for the adaptation heartbeat period. After rounding the calculated adaptive heartbeat period T, the final output is an adaptive heartbeat period T within the acceptable range, as shown in the following formula:

[0051]

[0052] in, Indicates the basic heart rate cycle; Weighting for the upgrade phase; This represents the quantified value of the current upgrade stage of the terminal. Weighting for the upgrade phase; Network quality weights; This is a quantitative value for the terminal network quality. As a weight for resource utilization rate; This is a quantified value for resource utilization.

[0053] In this embodiment, the weights of the upgrade stage were adjusted through multiple experiments. Network quality weight and resource utilization weight The values ​​are set to 0.4, 0.3, and 0.3, respectively, to obtain the quantized values ​​of the current upgrade stage of the terminal, and the quantized values ​​of the upgrade stage during the download stage. 4. Meet the target scenario and verify the quantified value of the upgrade phase. 1.2, Reduce the quantization value to shorten the adaptation heartbeat cycle T, quantization value during the installation phase and upgrade phase. 0.8, further reducing the quantization value; the terminal network quality quantization value is obtained by quantifying the terminal network quality based on the packet loss rate. When the packet loss rate is less than or equal to 5%, The value is 1.0; when the packet loss rate is greater than 5% and less than 15%, The value is 0.8; resource utilization is quantified based on CPU utilization to obtain a quantified resource utilization value. When CPU utilization is less than or equal to 60%, The value is 1.0; when the CPU utilization is greater than 60% and less than 80%, The value is 0.8.

[0054] For example, when the terminal is in the download phase, the packet loss rate is less than 5%, and the CPU utilization rate is less than 60%, the heartbeat period is configured to be 11 seconds. At this time, the bandwidth usage of 1,000 terminals can be controlled at 50-80KB / s, maximizing the download efficiency while ensuring monitoring needs.

[0055] S2: The target terminal collects its own upgrade-related status data in real time based on the adaptive heartbeat cycle T and reports it to the server. The upgrade-related status data includes network parameters, progress parameters, resource parameters and block verification results.

[0056] The data is reported to the server, and the appropriate fields are selected for uploading: either complete fields or core fields, depending on the length of the adaptation heartbeat period T. Specifically, when the adaptation heartbeat period T is short, core fields are reported. The core fields are set during actual operation. When the adaptation heartbeat period T is long, complete fields are reported. In this embodiment, a adaptation heartbeat period T of less than or equal to 12s is considered a short period, and a adaptation heartbeat period T of greater than 12s is considered a long period.

[0057] In this embodiment, this step combines dynamic heartbeat cycles to achieve on-demand reporting. Short heartbeat cycles result in high monitoring density, transmitting only core fields to ensure fast transmission without consuming bandwidth; long heartbeat cycles result in low monitoring density, transmitting complete fields to allow the server to fully grasp the terminal status; thus balancing real-time performance and bandwidth consumption.

[0058] S3: After receiving the status data reported by the target terminals in batches, the server verifies the integrity of the status data and determines whether the target terminals have abnormal status parameters based on network parameters, progress parameters and / or resource parameters.

[0059] In this invention, network parameters include packet loss rate, network latency, and / or uplink and downlink bandwidth; progress parameters include upgrade progress stagnation time, download progress percentage, and / or download speed; resource parameters include CPU utilization, disk space remaining, and / or Flash usage.

[0060] In this invention, the integrity of the status data is verified by checking whether the block verification results match preset values; the process of determining whether the target terminal has abnormal status parameters based on the status data is as follows:

[0061] If a network parameter is detected to be greater than or equal to a network parameter threshold, a progress parameter is detected to be greater than or equal to a progress parameter threshold, or a resource parameter is detected to be greater than or equal to a resource parameter threshold, then the target terminal is determined to have an abnormal status parameter.

[0062] If network parameters are detected to be less than the network parameter threshold, progress parameters are detected to be less than the progress parameter threshold, and resource parameters are detected to be less than the resource parameter threshold, then it is determined that the target terminal has no abnormal status parameters.

[0063] In this embodiment, the network parameters, progress parameters, and resource parameters are based on packet loss rate, upgrade progress stagnation time, and CPU utilization, respectively. At this time, the network parameter threshold can be set to 15%; the progress parameter threshold can be set to 30s; and the resource parameter threshold can be set to 80%.

[0064] S4: If the target terminal has abnormal status parameters, the server first sends a heartbeat enhancement command to the target terminal and starts abnormal isolation. Then, it executes the corresponding abnormal handling strategy based on the abnormality type until the abnormal status parameters are repaired. Finally, the server determines whether the upgrade of the target terminal is complete based on the block verification results of the upgrade task package and / or the current system version.

[0065] If the server determines that the target terminal does not have any abnormal status parameters, the server will directly determine whether the upgrade of the target terminal is complete based on the block verification results of the upgrade task package and / or the current system version.

[0066] In this embodiment, the heartbeat enhancement command means to force the adapted heartbeat cycle to a preset heartbeat cycle; starting anomaly isolation means to logically separate the target terminal from the batch queue to prevent the fault from spreading; the preset heartbeat cycle is set to 1 second.

[0067] In this invention, the server has several types of anomalies based on the network parameters, progress parameters, and resource parameters used. The network parameters, progress parameters, and resource parameters respectively utilize packet loss rate, upgrade progress stagnation time, and CPU utilization rate. The corresponding anomaly types are network packet loss, single-block processing timeout, and network connection interruption. When an anomaly type is identified, an anomaly handling strategy is executed on the target terminal, and targeted repair is performed for the anomaly type. The above process solves the resource waste problem of traditional batch retries and achieves accurate repair. This invention only proposes a limited number of anomaly types, but does not represent all anomaly types.

[0068] The server identifies the corresponding exception type based on preset parameter thresholds and executes the corresponding exception handling strategy, including the following steps:

[0069] If the detected packet loss rate is greater than or equal to the network parameter threshold, and the anomaly type is identified as network packet loss, then the network of the target terminal is switched.

[0070] If the upgrade progress stalls for a duration greater than or equal to the progress parameter threshold, and the anomaly type is identified as a single-block processing timeout, then the upgrade packet block that failed to be verified will be retransmitted.

[0071] If the CPU utilization rate is detected to be greater than or equal to the resource parameter threshold, and the anomaly type is identified as network connection interruption, the terminal will trigger a resume interruption.

[0072] In this invention, if the exception type is network packet loss, the network of the target terminal is switched, for example, the network of the target terminal is switched from cellular network to Wi-Fi; if the exception type is single block processing timeout, the upgrade packet block that failed to be verified is retransmitted; if the exception type is network connection interruption, the terminal triggers breakpoint resume transmission to avoid full re-downloading and upgrade retry.

[0073] S5: If the server determines that the upgrade of the target terminal is not completed, return to step S1;

[0074] If the server determines that the upgrade of the target terminal is complete, the server marks the target terminal as having completed the upgrade, until all target terminals are marked as having completed the upgrade.

[0075] In this invention, the process of determining whether the upgrade of the target terminal is complete is as follows:

[0076] If all parts of the upgrade task package pass the verification and the current system version is consistent with the target version, then the target terminal is determined to have completed the upgrade.

[0077] If any part of the upgrade task package fails verification or the current system version is inconsistent with the target version, the target terminal is determined to have not completed the upgrade.

[0078] The server determines that the upgrade of the target terminal is complete, and the target terminal pushes a confirmation message of successful upgrade to the server. The confirmation message of successful upgrade includes data such as the final system version of the target terminal and the full verification result, which is used to ensure that the server can accurately verify the validity of the upgrade, complete the batch upgrade archiving, and provide complete data support for subsequent problem tracing. The content of the confirmation message of successful upgrade is not the main content of this invention and will not be described in detail here.

[0079] This invention employs a dynamic heartbeat cycle calculation mechanism that integrates three parameters: terminal network quality, resource utilization, and upgrade phase. This mechanism adaptively adjusts the heartbeat cycle to balance real-time monitoring and bandwidth consumption. When an abnormal status parameter is triggered, a heartbeat enhancement command is sent to the target terminal, and anomaly isolation is initiated. Subsequently, an anomaly handling strategy is executed on the target terminal, achieving millisecond-level response and preventing fault propagation. A multi-dimensional status parameter anomaly judgment and root cause localization mechanism uses preset thresholds for network parameters, progress parameters, and resource parameters to identify anomaly types and accurately locate the root cause. Target terminals exhibiting abnormal status parameters are logically separated from the batch queue and their repair processes are executed individually without affecting normal terminal upgrades, thus preventing the batch propagation of faults.

[0080] This invention can balance real-time perception of upgrade status and bandwidth usage, enabling precise monitoring of batch terminal upgrade status, millisecond-level capture and rapid processing of anomalies, reducing upgrade failure rate and retry costs, and is compatible with multiple scenarios such as IoT and vehicle terminals, improving the efficiency, reliability and compatibility of remote batch OTA upgrades.

[0081] The above are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. An OTA upgrade method based on dynamic heartbeat sensing, characterized in that, Includes the following steps: S1: After receiving the upgrade task package, the target terminal uploads its basic information to the server. The server calculates the corresponding adaptation heartbeat cycle for the target terminal based on the basic information and sends it to the corresponding target terminal. The basic information includes the upgrade stage of the terminal, the terminal device model, the terminal network quality, and the resource utilization rate. S2: The target terminal collects its own upgrade-related status data in real time based on the adaptive heartbeat cycle and reports it to the server. The upgrade-related status data includes network parameters, progress parameters, resource parameters and block verification results. S3: After receiving the status data reported by the target terminals in batches, the server verifies the integrity of the status data and determines whether the target terminals have abnormal status parameters based on network parameters, progress parameters and / or resource parameters. S4: If the target terminal has abnormal status parameters, the server first sends a heartbeat enhancement command to the target terminal and starts abnormal isolation. Then, it executes the corresponding abnormal handling strategy based on the abnormality type until the abnormal status parameters are repaired. Finally, the server determines whether the upgrade of the target terminal is complete; If the server determines that the target terminal does not have any abnormal status parameters, the server will directly determine whether the upgrade of the target terminal is complete. S5: If the server determines that the upgrade of the target terminal is not completed, return to step S1; If the server determines that the upgrade of the target terminal is complete, the server marks the target terminal as having completed the upgrade, until all target terminals are marked as having completed the upgrade.

2. The OTA upgrade method according to claim 1, characterized in that: In step S1, the server collects basic information uploaded by the target terminal, including the following steps: S101: The server synchronously pushes upgrade task packages to a batch of target terminals; S102: After receiving the upgrade task package pushed by the server, the target terminal performs integrity verification; if the verification fails, it sends a retransmission request for the upgrade task package to the server; if the verification succeeds, it reports the corresponding basic information to the server. S103: After receiving the basic information sent by the target terminal, the server obtains the corresponding adaptive heartbeat cycle parameters of the target terminal and sends them to the corresponding target terminal.

3. The OTA upgrade method according to claim 2, characterized in that: The upgrade task package pushed in step S1 includes upgrade package block information and initial parameters of the dynamic heartbeat algorithm; The upgrade package block information includes checksum, block number, and block information table; the initial parameters of the dynamic heartbeat algorithm include basic heartbeat period and weight correction parameters.

4. The OTA upgrade method according to claim 3, characterized in that: In S1, based on the basic heartbeat cycle, the terminal network quality, resource utilization rate and current upgrade stage in the basic information are adjusted by weight correction parameters to calculate the current terminal's adaptation heartbeat cycle. The upgrade stage includes the download stage, verification stage and installation stage, with the default download stage as the initial value of the upgrade stage. The weight adjustment parameters include upgrade phase weight, network quality weight, and resource utilization weight.

5. The OTA upgrade method according to claim 1, characterized in that: In step S2, the complete field or core field is selected for uploading according to the length of the matching heartbeat cycle, and it is known whether the matching heartbeat cycle belongs to the short cycle or the long cycle range.

6. The OTA upgrade method according to claim 1, characterized in that: In step S3, the integrity of the status data is verified by checking whether the block verification results match the preset values.

7. The OTA upgrade method according to claim 1, characterized in that: Step S3, The steps to determine whether the target terminal has abnormal status parameters are as follows: If a network parameter is detected to be greater than or equal to a network parameter threshold, a progress parameter is detected to be greater than or equal to a progress parameter threshold, or a resource parameter is detected to be greater than or equal to a resource parameter threshold, then the target terminal is determined to have an abnormal status parameter. If network parameters are detected to be less than the network parameter threshold, progress parameters are detected to be less than the progress parameter threshold, and resource parameters are detected to be less than the resource parameter threshold, then it is determined that the target terminal has no abnormal status parameters.

8. The OTA upgrade method according to claim 1, characterized in that: In step S4, the heartbeat enhancement instruction refers to forcibly modifying the adapted heartbeat cycle to a preset heartbeat cycle; and the abnormal isolation is initiated to logically separate the target terminal with abnormal status parameters from the batch queue.

9. The OTA upgrade method according to claim 7, characterized in that: In step S4, the network parameters, progress parameters, and resource parameters utilize packet loss rate, upgrade progress stall duration, and CPU utilization, respectively. The server identifies the corresponding anomaly type based on these parameters and executes the corresponding anomaly handling strategy. The steps are as follows: If the detected packet loss rate is greater than or equal to the network parameter threshold, and the anomaly type is identified as network packet loss, then the network of the target terminal is switched. If the upgrade progress stalls for a duration greater than or equal to the progress parameter threshold, and the anomaly type is identified as a single-block processing timeout, then the upgrade packet block that failed to be verified will be retransmitted. If the CPU utilization rate is detected to be greater than or equal to the resource parameter threshold, and the anomaly type is identified as network connection interruption, the terminal will trigger a resume interruption.

10. The OTA upgrade method according to claim 1, characterized in that: In step S5, the steps for determining whether the upgrade of the target terminal is complete are as follows: If all parts of the upgrade task package pass the verification and the current system version is consistent with the target version, then the target terminal is determined to have completed the upgrade. If any part of the upgrade task package fails verification or the current system version is inconsistent with the target version, the target terminal is determined to have not completed the upgrade.

Images