A method and apparatus for performing and rolling back a stream upgrade based on a verification lag confirmation
By pre-writing upgrade data fragments to storage and verifying them in the background, the inefficiency caused by waiting for verification during streaming upgrades is solved, enabling accurate rollback and improving the reliability and stability of the system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- ASR MICROELECTRONICS CO LTD
- Filing Date
- 2026-03-24
- Publication Date
- 2026-06-05
Smart Images
Figure CN122152339A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of software upgrade technology, and in particular to a streaming upgrade execution and rollback method based on verification lag confirmation. Background Technology
[0002] With the rapid increase in the number of embedded devices, remote software upgrades have become an important means of device maintenance and feature updates. In many resource-constrained devices, due to limited storage space and memory capacity, streaming upgrades are typically used for software updates.
[0003] In existing technologies, streaming upgrades are typically performed in a strict sequence. Upon receiving upgrade data, the device first performs an integrity check on the data. Only after the check passes does it execute the write operation, and then it continues processing subsequent data. While this method ensures the security of upgrade data, it has several shortcomings in practical applications.
[0004] First, since the write operation must wait for the verification to complete, the upgrade execution process and the verification process are highly coupled. When the verification calculation takes a long time, it will cause the entire upgrade process to be blocked, thereby reducing the upgrade efficiency.
[0005] Secondly, in some differential upgrade or complex patch upgrade scenarios, data verification or semantic verification often requires a lot of computation, which further prolongs the upgrade time.
[0006] Furthermore, when a data block fails to be verified during the upgrade process, existing technologies typically require a rollback to an earlier system state, or even a re-execution of the entire upgrade process. This not only increases system recovery time but also increases the number of write / erase cycles on the storage device.
[0007] Therefore, there is still room for improvement in terms of upgrade efficiency, system reliability, and rollback flexibility of existing technologies. Summary of the Invention
[0008] Therefore, the purpose of this invention is to provide a streaming upgrade execution and rollback method and apparatus based on verification lag confirmation, which has the advantages of improving upgrade efficiency, reducing upgrade time, and realizing a precise rollback mechanism, thereby improving system reliability and stability.
[0009] To address the aforementioned technical problems, this invention provides a streaming upgrade execution and rollback method based on verification lag confirmation, comprising the following steps: S1: Upgrade process initialization: Receive upgrade trigger command, start upgrade process, and create execution context information to record the upgrade process; S2: Upgrade data reception and segmentation: Receive upgrade data stream, and divide the upgrade data stream into multiple continuous data segments according to a predetermined rule. Each data segment corresponds to a basic execution unit in the upgrade process. S3: Upgrade data pre-writing: The received data fragment is directly written to the pre-write storage area without waiting for the fragment verification to be completed; S4: Background verification processing: The verification module runs independently in the background and performs verification processing on the written data fragments; S5: Upgrade data activation control: Control the activation status of upgrade data according to the verification results in step S4. If the data segment passes the verification, it is marked as an effective state and the system activation boundary is updated. Data segments whose verification results are not determined remain in an ineffective state. S6: Upgrade anomaly handling and rollback: If the verification of one of the data segments is detected to be unsuccessful, the subsequent upgrade process is stopped immediately. Only the data segments that have not yet taken effect are discarded or cleaned up, while the data that has taken effect remains unchanged, so as to roll back the system to the most recent stable state.
[0010] In one embodiment of the present invention, in step S1, the execution context information is used to record the status of the current upgrade task.
[0011] In one embodiment of the present invention, in step S3, after the pre-writing is completed, the system records the writing status of the data segment and updates the writing progress information in the upgrade context.
[0012] In one embodiment of the present invention, the verification process in step S4 includes: data integrity verification, data structure legality verification, and semantic legality verification of patch or differential data; at the same time, after the verification module completes the verification, it generates a verification result corresponding to the data segment and feeds the result back to the upgrade management module.
[0013] In one embodiment of the present invention, in step S2, while generating the data fragments, the system records the target write position, data length and related verification information of each data fragment so that the verification module can perform verification.
[0014] The present invention also provides a streaming upgrade execution and rollback apparatus based on verification lag confirmation, comprising: The upgrade management module is used to receive upgrade trigger commands, start the upgrade process, create and maintain the upgrade execution context, coordinate the work of various modules, receive verification results, and control the progress of the upgrade process. The upgrade execution module is used to receive the upgrade data stream, divide it into multiple consecutive data segments, write the data segments into a pre-write storage area, record the write status, and update the write progress. The verification module is used to run independently in the background to perform verification processing on the written data fragments, generate verification results, and feed them back to the upgrade management module. The effectiveness control module is used to control the effectiveness status of the data fragment based on the verification result, update the system effectiveness boundary, and make the verified data included in the system's accessible range. The rollback control module is used to stop the subsequent upgrade process when a verification failure is detected, discard or clean up the data fragments that have not yet taken effect, and roll back the system to the most recent stable state.
[0015] In one embodiment of the present invention, the verification content of the verification module includes one or more of the following: data integrity verification, data structure legality verification, and semantic legality verification.
[0016] In one embodiment of the present invention, the upgrade execution module and the verification module work in parallel, and the data fragment writing operation does not need to wait for the verification to be completed.
[0017] In one embodiment of the present invention, the data activation control module implements data activation control by updating storage mapping relationships or system access pointers.
[0018] In one embodiment of the present invention, the rollback control module can also be used to record upgrade log information so that the system can restore or re-execute the upgrade process during the next upgrade.
[0019] Compared with the prior art, the above-described streaming upgrade execution and rollback method and apparatus based on verification lag confirmation of the present invention have the following advantages: First, this invention significantly improves upgrade efficiency by separating the upgrade execution and verification processes, enabling continuous writing of upgrade data.
[0020] Secondly, the present invention adopts a background verification mechanism, which enables the system to complete data verification in parallel during the upgrade process, thereby reducing the waiting time during the upgrade process.
[0021] Furthermore, by controlling the effective status of upgrade data, this invention enables the system to avoid accessing unverified data, thereby ensuring system operational security.
[0022] Furthermore, this invention only processes ineffective data when the upgrade fails, thereby achieving fine-grained rollback and improving system recovery speed.
[0023] This invention relates to a streaming upgrade execution and rollback method and apparatus based on verification-delayed confirmation. By pre-writing upgrade data fragments, the verification process can be executed independently in the background without waiting for verification to complete. The data activation status and rollback operation are precisely controlled based on the verification results. This solves the performance bottleneck problem caused by the deep binding of the upgrade process and the verification process in the prior art, as well as the inefficiency and risk caused by the inaccurate rollback mechanism. It has the advantages of improving upgrade efficiency, reducing upgrade time, and realizing a precise rollback mechanism, thereby improving system reliability and stability. Attached Figure Description
[0024] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0025] Figure 1 This is a flowchart of the streaming upgrade execution and rollback method based on verification lag confirmation of the present invention; Figure 2 This is a structural diagram of the streaming upgrade execution and rollback device based on verification lag confirmation of the present invention. Detailed Implementation
[0026] The embodiments of this application will now be described in detail with reference to the accompanying drawings.
[0027] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. This application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0028] It should be noted that the following description covers various aspects of embodiments within the scope of the appended claims. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this application, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number and aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.
[0029] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. The drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.
[0030] Additionally, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that practice can be carried out without these specific details.
[0031] Traditional streaming upgrade methods for embedded device software updates typically execute in a strict sequence. Upon receiving upgrade data, the device first performs an integrity check on the data before performing the write operation. While this method ensures the security of the upgrade data, the high coupling between the upgrade execution and verification processes, where the write operation must wait for verification, can lead to the entire upgrade process being blocked if the verification calculation is time-consuming, thus reducing upgrade efficiency. Furthermore, if the verification of a data block fails during the upgrade process, existing technologies usually require rolling back to an earlier system state or even re-executing the entire upgrade process, increasing system recovery time and the number of write / erase cycles on the storage device.
[0032] To address this, this invention proposes a streaming upgrade execution and rollback method based on verification lag confirmation. By dividing the upgrade data stream into multiple consecutive data segments, the received data segments can be directly written to the pre-write storage area without waiting for verification to complete. Simultaneously, a verification module runs independently in the background to perform verification processing on the written data segments. The effectiveness status of the upgrade data is controlled based on the verification results. Data segments that pass verification are marked as effective and the system's effectiveness boundary is updated; segments with uncertain verification results remain ineffective. If a data segment verification failure is detected, the subsequent upgrade process is immediately stopped, only discarding or cleaning up ineffective data segments, while effective data remains unchanged, thereby achieving system rollback to the most recent stable state.
[0033] The upgrade data stream consists of several components: **Upgrade Data Stream:** A continuous sequence of data used to update system software or firmware, which may include a complete system image, patch packages, or differential data. This data stream is typically transmitted to the target device via a network or other communication interface. **Data Segment:** A smaller, continuous block of data formed by dividing the upgrade data stream according to predetermined rules. Each data segment is considered a basic execution unit in the upgrade process and can be independently written and verified. **Pre-write Storage Area:** An area within the system used to temporarily store received data segments. This area stores data that has not yet been finalized before the data segments are verified and marked as effective. **Verification Module:** The functional unit in the system responsible for verifying the written data segments. This module runs independently of the main upgrade process, verifying data segments in the background to ensure their integrity, legality, and compatibility. **System Effective Boundary:** The logical or physical boundary of data segments that have been verified and marked as effective in the system. Updating this boundary indicates an expansion of the range of upgrade data that the system can access and use. **Rollback:** The operation of restoring the system to a previous stable state when an anomaly or error is detected during the upgrade process. The rollback mechanism in this embodiment avoids modifying the already effective data by only cleaning up data segments that have not yet taken effect, thereby achieving fast and localized recovery.
[0034] This application provides a streaming upgrade execution and rollback method based on verification lag confirmation, referring to... Figure 1 As shown, the specific steps include the following: S1: Upgrade Process Initialization: Receives the upgrade trigger command, starts the upgrade process, and creates execution context information to record the upgrade process; for example, the upgrade trigger command can be sent by a remote management platform or triggered by a local user interface operation. The execution context information can be a simple data structure used to store a unique identifier for the upgrade task, a current stage indicator, and a Boolean flag indicating whether the upgrade has started.
[0035] S2: Upgrade Data Reception and Fragmentation: Receive the upgrade data stream and divide it into multiple consecutive data fragments according to predetermined rules. Each data fragment corresponds to a basic execution unit in the upgrade process. For example, the upgrade data stream can be divided into fixed-size byte blocks, or divided according to a preset delimiter in the data stream. Each data fragment is treated as an independent unit for subsequent individual processing.
[0036] S3: Upgraded Data Pre-Write: The received data fragment is directly written to the pre-write storage area without waiting for the fragment verification to complete; for example, the data fragment can be written to a temporary partition in the flash memory or non-volatile memory inside the device. After the write operation is completed, the system can simply record that the fragment has been written without immediately performing detailed status tracking.
[0037] S4: Background Verification Processing: The verification module runs independently in the background, performing verification processing on the written data fragments. For example, the verification module can perform basic checksum calculations on each data fragment to check for errors during data transmission. This verification process is executed in a separate thread or process and does not block the main upgrade process.
[0038] S5: Upgrade Data Activation Control: Based on the verification results in step S4, the activation status of the upgrade data is controlled. If a data segment passes verification, it is marked as effective and the system's activation boundary is updated. Data segments for which verification results are uncertain remain inactive. For example, when the checksum calculation of a data segment passes, the segment is marked as "verified," and an internal pointer or index is updated to indicate the currently effective data range. Segments that fail verification or have not yet completed verification are not included in the effective range.
[0039] S6: Upgrade Anomaly Handling and Rollback: If a data segment verification failure is detected, the subsequent upgrade process is immediately stopped. Only inactive data segments are discarded or cleaned up, while active data remains unchanged, allowing the system to roll back to the most recent stable state. For example, when the verification module reports a checksum mismatch for a data segment, the upgrade management module will immediately stop receiving and writing subsequent data segments. The system will then identify all data segments that have been written but not yet marked as active and delete them from the pre-write storage area or mark them as invalid, thereby restoring the system to the most recent stable state where all data was active.
[0040] This application decouples the writing and verification processes of upgrade data, allowing data fragments to be verified asynchronously in the background. This effectively avoids process blocking caused by verification waiting in traditional streaming upgrades, significantly improving upgrade efficiency. Simultaneously, through fine-grained effectiveness control and a partial rollback mechanism, only data fragments that have not yet taken effect are processed, avoiding repeated operations on already effective data. This reduces system recovery time, decreases the number of write / erase cycles on storage devices, and enhances the system's recovery capabilities under abnormal conditions and the flexibility of the upgrade process.
[0041] In the above embodiments of this application, execution context information is proposed to record the upgrade process. However, in its implementation, unclear state recording may lead to inaccurate tracking of the upgrade task status, affecting the accuracy and efficiency of rollback. Therefore, this application further proposes that, in step S1, the execution context information is used to record the current status of the upgrade task.
[0042] Specifically, execution context information can be a dedicated data structure, such as a hash table, struct, or object, containing multiple fields to store different types of status data; alternatively, it can be represented as a centralized log or database record, indexed by a unique task ID, storing all dynamic information related to the upgrade task. The core function of this execution context information is to record the current status of the upgrade task. To achieve this, one or more status fields can be included in the execution context information, such as "Initializing," "Data Receiving," "Pre-writing," "Verifying," "Effecting," "Rolling Back," "Completed," or "Failed," and these fields can be updated in real time at each stage of the upgrade process. Furthermore, the current task status can be inferred by recording a series of timestamp events, such as "Data Fragment X Started Receiving," "Data Fragment Y Pre-writing Completed," and "Data Fragment Z Verified Passed." Simultaneously, recording progress metrics such as the number of processed data fragments, the amount of verified data, and the ID of the currently processed data fragment can also collectively reflect the real-time progress and status of the task.
[0043] Through the above technical solution, the system can obtain a clear and real-time view of the upgrade progress. During the upgrade process initialization phase (step S1), the status of the current upgrade task is accurately recorded by creating and utilizing execution context information, ensuring the centralization and real-time nature of status information and avoiding scattered or missing status updates. When a data fragment verification failure is detected during the upgrade process (step S6), the rollback control module can accurately identify the current stage of the upgrade task based on the precise status recorded in the execution context information, such as which data fragments have been pre-written, which have passed verification and taken effect, and which have not yet been processed. This precise status tracking avoids inaccurate or excessive rollback due to unclear status information, making the rollback operation more accurate and efficient. It only discards or cleans up data fragments that have not yet taken effect, without affecting data that has already taken effect, thereby reducing unnecessary system recovery time and reducing the number of write / erase cycles to the storage device. This significantly improves the transparency, manageability, and accuracy and efficiency of the upgrade process, ensuring that the system can quickly roll back to the most recent stable state in case of anomalies.
[0044] In the above embodiments of this application, upgrade data pre-writing is proposed to enable the writing of data fragments without waiting for verification, thereby improving upgrade efficiency. However, during its implementation, if the writing status of each data fragment is not recorded in a timely manner and the writing progress information in the upgrade context is not updated, the system may not be able to accurately track the completion status of the written fragments, resulting in a lack of reliable basis for subsequent verification, effectiveness control, or rollback operations, which can easily lead to data management chaos. For example, the verification module may not be able to process fragments specifically, the effectiveness boundary may be updated incorrectly, or written fragments may be mistakenly cleaned up during rollback, thereby reducing the reliability of the upgrade and the accuracy of the rollback. In this regard, this application further proposes that in step S3, after the pre-writing is completed, the system records the writing status of the data fragment and updates the writing progress information in the upgrade context.
[0045] Specifically, "after pre-write completion" refers to the point after the operation of writing the data fragment to the pre-write storage area is complete. Choosing this point for status recording and progress updates aims to ensure that related metadata management is only performed after the physical write operation of the data fragment has ended and its result (success or failure) is determined. One implementation is to trigger status recording and progress updates immediately after the file system or storage driver layer returns a success or failure status for the write operation. Another implementation is to have the module responsible for writing issue a completion event after the last byte of the data fragment has been written to the target storage medium and an acknowledgment signal has been received from the storage medium, thereby triggering subsequent status updates.
[0046] "The system records the write status of this data segment" refers to recording the write result of the data segment in the pre-write storage area, typically including success, failure (e.g., insufficient storage space, write error, etc.), or partial write. Recording this status is crucial for subsequent verification, activation, and rollback operations, providing reliability information for each data segment at the physical storage level. This can be achieved by maintaining a status field for each data segment in the upgrade context information, for example, using an enumeration type (such as `WRITTEN_SUCCESS`, `WRITTEN_FAILED`). Alternatively, the system can maintain a separate write status table containing the identifier of the data segment and its corresponding write result, and perform efficient lookups using data structures such as hash tables or B-trees.
[0047] "Updating write progress information in the upgrade context" refers to updating the overall write status of all data segments in the current upgrade task, such as the amount of data written, the number of data segments written, or the identifier of the last data segment written. Updating this information allows the upgrade management module to monitor the write progress of upgrade data in real time, thereby coordinating the work of other modules, such as notifying the verification module that it can start processing new data segments, or determining the scope that needs to be cleaned up during rollback. One approach is to maintain a pointer or index to the last data segment that has been successfully written in the upgrade context information. Another approach is to maintain a counter that accumulates the number of bytes written, incrementing the length of each data segment written successfully into the counter.
[0048] The above technical solution records the writing status and updates the writing progress information immediately after the data fragment is pre-written, ensuring the real-time nature and accuracy of the status information during the upgrade process. This instant feedback mechanism avoids status update delays, enabling the verification module to accurately identify which data fragments have been successfully written and are ready for verification, thus avoiding invalid verification of data that has not been written or has failed to be written. Simultaneously, the upgrade management module can monitor the writing progress in real time, effectively coordinating with the effectiveness control module to update the system's effectiveness boundaries, preventing data loss or duplicate processing. More importantly, in the event of an anomaly requiring rollback, the system can discard or clean up only those written but not yet effective data fragments based on precise writing status information, without mistakenly cleaning up effective data. This significantly improves the reliability of the upgrade, the accuracy of the rollback, and the coherence and controllability of the entire upgrade process.
[0049] In the above-described solution of this application, a verification process is proposed to independently verify data fragments in the background. However, in this process, the verification content may be incomplete and unable to effectively detect errors at the data structure or semantic level, thereby affecting the reliability of the upgrade and the stability of the system. To address this, this application further proposes that the verification process in step S4 includes: data integrity verification, data structure legality verification, and semantic legality verification of patch or differential data; simultaneously, after the verification module completes the verification, it generates a verification result corresponding to the data fragment and feeds this result back to the upgrade management module.
[0050] Specifically, data integrity verification aims to ensure that upgrade data fragments have not been damaged or tampered with during transmission and storage. For example, a Cyclic Redundancy Check (CRC) algorithm can be used to calculate a checksum for the data fragment and compare it with the expected checksum; alternatively, hash algorithms such as MD5 or SHA-256 can be used to generate a unique hash value for the data fragment and compare it with known correct hash values to confirm data consistency. Data structure validity verification checks whether data fragments conform to predefined data formats, protocol specifications, or file structures. For example, for structured data, verification can be performed based on a preset schema (such as XML Schema or JSON Schema) to ensure that the type, length, and nesting relationships of data fields meet requirements; alternatively, a specific parser can be used to attempt to parse the data fragment, and failure to parse indicates a problem with the data structure. Furthermore, the validity of the data fragment's structure can be determined by checking its metadata, such as header information and file type identifiers. Semantic validity verification of patch or differential data is a deep check of the logical meaning contained in the upgrade data, aiming to ensure that its application will not lead to system malfunctions, introduce security vulnerabilities, or compromise the stability of existing systems. In practical implementation, this can include dependency analysis of patches, i.e., checking whether the patch depends on specific system versions or components, and whether its application will conflict with other components; it can also perform security policy checks, such as scanning the patch content for potential malicious code, insecure configuration changes, or behaviors that violate system security specifications; furthermore, the patch can be simulated in an isolated sandbox environment to observe its impact on system behavior, in order to verify whether its functionality and logic meet expectations. After the verification module completes the various verifications of the data fragments, it generates a clear verification result. This result can be a simple Boolean value indicating whether the verification passed or failed; it can also be a more detailed enumeration type, for example, distinguishing specific reasons such as "integrity verification failed," "structural legality verification failed," or "semantic legality verification failed"; it can even be a structured report containing error codes, error descriptions, and suggested handling methods to facilitate subsequent troubleshooting and processing. The verification module passes the generated verification result to the upgrade management module, so that the upgrade management module can precisely control the upgrade process based on the verification status. This feedback mechanism can be implemented in several ways. For example, the verification module can publish the results to a message queue, and the upgrade management module can subscribe to and consume these messages; or, the verification module can directly call the application programming interface (API) or callback function provided by the upgrade management module and pass the results as parameters; in addition, the verification results can be made visible to the upgrade management module by sharing a memory region or registering with a global state service.
[0051] Through the above technical solutions, this application effectively solves the problem of incomplete verification content, significantly improving the reliability and system stability of streaming upgrades. Specifically, data integrity verification ensures the accuracy of upgrade data during transmission and pre-writing, avoiding upgrade failures due to data corruption. Data structure validity verification ensures that upgrade data conforms to the system's expected format specifications, preventing system anomalies or crashes caused by structural errors. Crucially, semantic validity verification of patches or differential data can thoroughly examine the logical correctness and security of upgrade content, effectively preventing system malfunctions or security vulnerabilities caused by patches with flawed application logic or security vulnerabilities. Given the parallel working mode of upgrade data pre-writing and background verification processing, even if the verification process is time-consuming, it will not block the data stream reception and pre-writing, thus maintaining upgrade efficiency. After the verification module completes the above comprehensive verification and generates detailed verification results, it promptly feeds back to the upgrade management module, enabling the upgrade management module to perform refined management of upgrade data activation control based on accurate verification status. Only data segments that pass the triple verification of integrity, structure, and semantics are marked as effective and the system's effective boundaries are updated. This ensures that only high-quality, error-free data can truly impact system operation. If any verification fails, the rollback control module can immediately stop subsequent processes and only discard or clean up problematic segments that have not yet taken effect, while the effective data remains unchanged. This enables the system to quickly and accurately roll back to the most recent stable state, greatly reducing rollback costs and system recovery time. It avoids the inefficiency of traditional upgrades where a complete rollback is required due to local errors, significantly improving the robustness of the upgrade process and user experience.
[0052] In some embodiments of this application, step S2 is proposed to divide data segments as the basic execution unit for the upgrade. However, during its implementation, the verification module lacks necessary information support, which may lead to delays, errors, or incompleteness in the verification process, thereby affecting upgrade efficiency and system reliability. To address this, this application further proposes that in step S2, while generating the data segments, the system records the target write location, data length, and related verification information for each data segment, so that the verification module can perform verification subsequently.
[0053] Specifically, during the generation of the data fragment, system recording refers to the immediate storage of metadata associated with the data fragment at the moment it is parsed, extracted, or constructed from the upgrade data stream. Implementation Method 1: After a data fragment is constructed or extracted from the data stream, the system immediately encapsulates its metadata (including the target write location, data length, and verification information) and stores it in a metadata structure associated with the data fragment. Implementation Method 2: When a data fragment is encapsulated into a processable unit and prepared for pre-writing, the system synchronously calculates and records all relevant verification information through a dedicated metadata generator, and writes it, along with its planned location and actual length in the target storage area, into a separate metadata log or index table.
[0054] The target write location for each data segment refers to the predetermined address or offset on the target storage medium where the data segment will ultimately be written. Providing this information allows the verification module to directly locate and access the data to be written without additional address resolution or lookups. Implementation Method 1: The system can pre-determine and record the starting physical address or logical block address on the target storage medium for each data segment based on the upgrade plan or storage allocation strategy. Implementation Method 2: At the file system level, the system specifies the starting offset within the target file or partition for each data segment and records it as the target write location.
[0055] Data length refers to the precise size of each data segment, typically measured in bytes. This information is crucial for verifying data integrity, ensuring that data segments are not truncated, padded, or corrupted during transmission and storage. One implementation method is to directly measure and record the number of bytes in each segment when dividing the data. Another implementation method is to record the number of data blocks contained in a segment for a segment composed of fixed-size data blocks, and calculate the total length by combining this with a preset block size.
[0056] Relevant verification information refers to data used to verify the integrity, authenticity, or legitimacy of data fragments. This information allows the verification module to quickly determine whether the data has been tampered with or corrupted. One implementation method is for the system to calculate the hash value (e.g., MD5, SHA-256) or cyclic redundancy check (CRC) of a data fragment when generating it, and record it as verification information. Another implementation method is for the system to use digital signature technology to sign the data fragment and record the signature result as verification information, providing a higher level of integrity and authenticity verification.
[0057] To facilitate subsequent verification by the verification module, the fundamental purpose of recording all the above information is clarified: to provide the verification module with the necessary and sufficient context, enabling it to perform verification tasks efficiently and accurately. Implementation Method 1: This recorded information is stored in a shared memory area, database, or message queue accessible to the verification module. Implementation Method 2: This information can be written as metadata headers or footers of data fragments, along with the data fragments, into a pre-write storage area, which the verification module can retrieve synchronously when reading the data fragments.
[0058] Through the above technical solution, while the system generates data fragments, it records the target write location, data length, and related verification information for each data fragment in real time, thus providing comprehensive and timely information support for the subsequent verification module. Specifically, the target write location allows the verification module to quickly locate and access the data fragment in the pre-written storage area, avoiding additional search or inference processes; the data length ensures that the verification module can accurately perform data integrity verification, preventing data truncation or redundancy; and the related verification information provides the verification module with direct verification basis, significantly improving the efficiency and accuracy of verification. Therefore, when the verification module runs independently in the background, it can perform verification processing on the written data fragments more efficiently and accurately, effectively avoiding verification delays, errors, or incompleteness caused by missing or delayed information. This not only further optimizes the parallel efficiency of pre-writing and background verification during streaming upgrades, reducing upgrade blocking, but also enables more accurate identification of problematic data in the event of anomalies, thereby improving the reliability of the entire upgrade process and the accuracy of rollback.
[0059] With the rapid increase in the number of embedded devices, remote software upgrades have become an important means of device maintenance and function updates. In many resource-constrained devices, due to limited storage space and memory capacity, streaming upgrades are typically used for software updates. In existing technologies, streaming upgrades are usually executed in a strict sequence: after receiving upgrade data, the device first performs integrity verification on the data; only after successful verification does it perform the write operation, and then it continues processing subsequent data. While this method ensures the security of upgrade data, it has several shortcomings in practical applications. First, because the write operation must wait for verification to complete, the upgrade execution process and the verification process are highly coupled. When verification calculations are time-consuming, the entire upgrade process can be blocked, thus reducing upgrade efficiency. Second, in some differential upgrade or complex patch upgrade scenarios, data verification or semantic verification often requires a lot of computation, which further prolongs the upgrade time. Furthermore, when the verification of a data block fails during the upgrade process, existing technologies usually require rolling back to an earlier system state, or even re-executing the entire upgrade process. This not only increases system recovery time but also increases the number of write / erase cycles on the storage device. Therefore, existing technologies still have room for improvement in terms of upgrade efficiency, system reliability, and rollback flexibility.
[0060] In response, this application proposes a streaming upgrade execution and rollback device based on verification lag confirmation. The verification lag confirmation mechanism is implemented through modular design, which solves the problems of low upgrade efficiency, long time consumption and inflexible rollback.
[0061] Reference Figure 2 As shown, the device specifically includes: an upgrade management module, an upgrade execution module, a verification module, an effectiveness control module, and a rollback control module.
[0062] The upgrade management module is used to receive upgrade trigger commands, start the upgrade process, create and maintain the upgrade execution context, coordinate the work of various modules, receive verification results, and control the progress of the upgrade process. For example, when an upgrade trigger command is received from the remote management platform, the upgrade management module starts the upgrade process and creates an execution context to record the unique identifier of the upgrade task and the current stage indicator.
[0063] The upgrade execution module is used to receive the upgrade data stream, divide it into multiple consecutive data segments, write the data segments into a pre-write storage area, record the write status, and update the write progress; for example, the upgrade data stream is divided into fixed-size byte blocks, and each data segment is directly written to a temporary partition in the device's internal flash memory without waiting for verification to complete.
[0064] The verification module is used to run independently in the background to perform verification processing on the written data fragments, generate verification results, and feed them back to the upgrade management module. For example, the verification module performs checksum calculations on the written data fragments in an independent thread to check data integrity, and this process does not block the main upgrade process.
[0065] The effectiveness control module is used to control the effectiveness status of the data fragment based on the verification result, update the system effectiveness boundary, and bring the verified data into the system's accessible range. The effectiveness control module implements data effectiveness control by updating storage mapping relationships or system access pointers. For example, when a data fragment passes verification, the effectiveness control module updates the system effectiveness boundary and marks the fragment as effective.
[0066] The rollback control module is used to stop the subsequent upgrade process when a verification failure is detected, discard or clean up the data segments that have not yet taken effect, and roll back the system to the most recent stable state; for example, when the verification module reports that a data segment verification has failed, the rollback control module immediately stops the subsequent process and only cleans up the data segments that have not yet taken effect.
[0067] This device decouples the data writing operation of the upgrade execution module from the verification processing of the verification module asynchronously, thereby avoiding process blocking caused by write waiting for verification and significantly improving upgrade efficiency. Simultaneously, through the collaborative work of the activation control module and the rollback control module, partial rollback is achieved only for ineffective data segments, reducing system recovery time and storage device write / erase cycles, thus enhancing system reliability and rollback flexibility. Specifically, since the upgrade execution module directly writes data segments to the pre-write storage area without waiting for verification to complete, the write operation is not blocked by the time-consuming verification calculation, thereby improving upgrade execution efficiency. Furthermore, the verification module runs independently in the background, asynchronously verifying the written data segments, separating the verification process from the main upgrade process and effectively shortening the overall upgrade time. In addition, the activation control module dynamically updates the system activation boundary based on the verification results, ensuring that only verified data is included in the system's accessible range, while the rollback control module only processes ineffective data segments when verification failure is detected, avoiding changes to already effective data, thereby minimizing the rollback scope and protecting system stability.
[0068] In the aforementioned solution of this application, a verification module is proposed to run independently in the background and perform verification processing on data fragments. However, in this process, the verification content may be too singular or fixed, failing to comprehensively cover potential errors at different levels, resulting in low verification efficiency or insufficient error detection, thereby affecting the reliability and efficiency of the upgrade process. To address this, this application further proposes that the verification content of the verification module includes one or more of the following: data integrity verification, data structure legality verification, and semantic legality verification.
[0069] Specifically, data integrity verification refers to checking received data segments to ensure they have not been damaged, lost, or tampered with during transmission and storage. Its purpose is to guarantee the originality and reliability of upgrade data, preventing system upgrade failures or malfunctions due to incomplete or incorrect data. Possible implementation methods include, but are not limited to: calculating and comparing data checksums (such as CRC32, MD5, SHA256, etc.), or performing preliminary verification using metadata such as data length and file size. For example, upon receiving each data segment, its hash value is calculated and compared with the expected hash value; if they do not match, the integrity verification is deemed to have failed.
[0070] Data structure validity validation refers to checking the internal structure, format, and field definitions of data fragments to ensure they conform to the system's expected specifications and standards. Its purpose is to prevent invalid or malformed data structures from being written into the system, thereby avoiding compatibility issues, parsing errors, or system crashes. Possible implementation methods include, but are not limited to: parsing and validating data fragments according to predefined data schemas (such as JSON Schema, XML Schema), or determining their validity by checking the type, length, and value range of specific fields. For example, for a configuration file fragment, validating whether it conforms to the syntax rules of INI, YAML, or a specific binary format.
[0071] Semantic validity verification refers to checking the logical meaning and business rules carried by data fragments to ensure that they conform to the current operating state of the system, business logic, or the expected effects of patches or differential data. Its purpose is to ensure that upgrade data is logically sound and secure, avoiding the introduction of potential logical errors, security vulnerabilities, or incompatible business behaviors. Possible implementation methods include, but are not limited to: simulating the execution of parts of the code logic to verify the expected behavior of the patch, checking whether differential data can be correctly applied to the current system version and generate a valid target version, or verifying whether the combination of configuration parameters meets specific business constraints. For example, for a module in a firmware upgrade package, verifying whether its version number is higher than the current version, or whether its dependencies meet system requirements.
[0072] Through the above technical solutions, the verification content of the verification module is made more specific and diversified, effectively solving the problems of incomplete or inflexible content in the verification process. Data integrity verification ensures that the upgrade data is not damaged or lost during reception and pre-writing to the storage area, avoiding system errors or upgrade interruptions caused by incomplete data. Data structure validity verification further checks whether the internal format of the data fragments conforms to the system specifications, effectively preventing parsing failures or compatibility issues caused by invalid structures. In addition, semantic validity verification assesses whether the logical meaning carried by the data fragments is consistent with the system's expectations. Especially for complex patches or differential upgrades, it can ensure that they are logically reasonable and safe, thereby avoiding the introduction of potential logical errors or incompatible business behaviors.
[0073] Furthermore, the upgrade execution module and the verification module work in parallel, and the data fragment writing operation does not need to wait for the verification to complete.
[0074] Specifically, in this technical solution, the upgrade execution module and the verification module can run independently and simultaneously, without interfering with each other, thus avoiding the situation in traditional serial processing where one module waits for another to complete. Specifically, this can be implemented using a multi-threaded or multi-process software architecture. For example, the upgrade execution module can be responsible for receiving the upgrade data stream and dividing it into data segments in an independent thread, then writing these data segments into a pre-write storage area; simultaneously, the verification module, in another independent thread or process, reads the written data segments from the pre-write storage area and performs verification processing on them. Alternatively, parallel work can be achieved through an asynchronous task scheduling mechanism. After completing data writing, the upgrade execution module only submits the verification task to the verification module's task queue, without blocking itself, and immediately returns to prepare for processing the next data segment, while the verification module asynchronously retrieves and executes the verification task from the task queue.
[0075] Meanwhile, the data fragment writing operation does not require waiting for verification to complete. This clarifies that after the upgrade execution module writes a data fragment to the pre-write storage area, it does not need to wait for the verification module's verification result for that data fragment before continuing with subsequent data reception and writing operations. One implementation is that after completing the writing of a data fragment, the upgrade execution module only updates the write progress information in the upgrade context and notifies the verification module that the data fragment is ready for verification, while immediately starting to process the reception and writing of the next data fragment. Another implementation is that the system can adopt a "write-and-forget" strategy, where the upgrade execution module only records the write status after writing data to the physical storage medium, without performing any synchronous waiting for verification results; the verification process is entirely handled independently by the background verification module.
[0076] Through the above technical solution, the upgrade execution module and the verification module can work in parallel, eliminating the need for data fragment writing operations to wait for verification completion. This parallel processing mechanism effectively decouples the two time-consuming stages of data writing and data verification, preventing the upgrade execution module from being stalled for extended periods while waiting for verification results, thus significantly reducing blocking time during the upgrade process. Consequently, the entire upgrade process can proceed continuously and efficiently, especially when processing large volumes of upgrade data or performing complex verifications on resource-constrained devices, significantly improving overall upgrade efficiency. Furthermore, this design allows the verification module to fully utilize system background resources for deep or time-consuming verification processing without impacting the real-time performance of data writing, further optimizing system performance and user experience.
[0077] Furthermore, the rollback control module can also be used to record upgrade log information so that the system can restore or re-execute the upgrade process during the next upgrade.
[0078] Recording upgrade log information refers to the persistent storage of key events, state changes, and error information during the upgrade process. This information may include, but is not limited to: the reception time, write status, verification result, error code, triggering reason for rollback operation, system state snapshot before rollback, and system state after rollback for each data segment. Specifically, this log information can be stored in the device's non-volatile memory in the form of structured log files, for example, using JSON or XML format to record detailed information for each event, facilitating subsequent parsing and querying. Furthermore, log information can also be written to a dedicated log partition or lightweight database within the device, enabling rapid retrieval and analysis of historical upgrade records through indexing and querying mechanisms. Resuming or re-executing the upgrade process means that after an upgrade is interrupted or fails, the system can intelligently resume the upgrade from the point of interruption using the recorded upgrade log information, or restart the upgrade process based on log analysis results. Specifically, when the system needs to resume the upgrade, it can parse the log information to identify the boundary of the last successfully implemented data segment, allowing the upgrade process to continue execution from the data segment after that boundary, avoiding duplicate processing of already successful parts. On the other hand, when re-executing the upgrade process, the system can adjust the upgrade strategy based on the error type and location recorded in the logs. For example, it can skip known problematic segments (if allowed) or request the retransmission of specific data segments, thereby improving the success rate and efficiency of the upgrade.
[0079] Through the above technical solution, when a verification failure occurs during the upgrade process and triggers a rollback operation, the rollback control module can simultaneously record detailed upgrade log information while executing the rollback. This log information comprehensively records each stage of the upgrade, the processing status of data segments, verification results, and details of any anomalies or errors. Therefore, if the system is interrupted or needs to be upgraded again, it no longer needs to start from scratch. Instead, it can utilize this log information to accurately identify the last stable state before the upgrade interruption or the specific reason for the failure. This allows the system to intelligently resume the upgrade from the point of interruption, avoiding unnecessary repetitive operations on successfully processed data segments, significantly shortening upgrade recovery time, and reducing the number of write / erase operations on storage devices. Simultaneously, the detailed log information provides valuable data support for diagnosing and resolving upgrade problems, thereby improving the reliability, efficiency, and user experience of the entire streaming upgrade execution and rollback method.
[0080] The following example will provide a more detailed explanation of the above technical solution: Suppose a smart home device B needs a firmware upgrade. Device B has relatively limited storage space and computing resources. Its upgrade management module, upgrade execution module, verification module, activation control module, and rollback control module work together to achieve an efficient and reliable streaming upgrade.
[0081] First, when user A sends an upgrade command to smart home device B via a mobile application, device B's upgrade management module receives the upgrade trigger command and initiates the upgrade process. At this time, the system creates an execution context to record the detailed status of this upgrade task, such as the unique identifier of the upgrade task, the target firmware version, the sequence number of the currently processed data segment, and the overall upgrade progress.
[0082] Next, the upgrade execution module of device B begins receiving the upgrade data stream from the cloud server. This upgrade data stream is divided into multiple consecutive data segments according to predetermined rules. For example, a 10MB firmware package may be divided into 10 1MB data segments, each corresponding to a basic execution unit in the upgrade process. While generating each data segment, the system records relevant verification information such as the target write location, data length, and hash value used for subsequent verification.
[0083] Subsequently, upon receiving a data fragment, such as the first 1MB fragment, the upgrade execution module immediately writes it to the pre-write storage area within device B (e.g., an inactive firmware partition). This write operation does not require waiting for the fragment's verification result, thus avoiding the problem of write operations being blocked by the verification process in traditional upgrade methods. After the pre-write is completed, the system records the write status of the data fragment and updates the write progress information in the upgrade context, such as "Fragment 1 has been written".
[0084] Almost simultaneously with data pre-writing, the verification module of device B runs independently in the background. Once the first data fragment is written to the pre-write storage area, the verification module immediately begins verification processing on that fragment. Verification processing includes: data integrity checks (e.g., calculating hash values and comparing them with recorded verification information), data structure validity checks (e.g., checking if firmware header information conforms to specifications), and semantic validity checks on patch or differential data (e.g., ensuring patches can be correctly applied to the current system version). After completing verification, the verification module generates a verification result (pass or fail) for the corresponding data fragment and feeds this result back to the upgrade management module. This parallel processing of writing and verification significantly improves upgrade efficiency, especially in scenarios where verification calculations are time-consuming, preventing the entire upgrade process from being blocked.
[0085] After receiving the verification result from the verification module, the upgrade management module instructs the activation control module to process it. If the first data fragment passes verification, the activation control module marks it as eligible for activation and includes it in the system's accessible range by updating storage mapping relationships or system access pointers, and updates the system's activation boundaries. For example, the system maintains a pointer to the currently activated firmware region; after successful verification, this pointer moves forward, covering the region containing the newly activated fragment. If the verification result of a subsequent data fragment is still uncertain, it will remain inactive, and the system will not include it in the accessible range.
[0086] Suppose that when processing the fifth data segment, the verification module detects a data integrity check failure for that segment. Upon receiving the verification failure feedback, the upgrade management module immediately notifies the rollback control module to stop the subsequent upgrade process. The rollback control module only discards or cleans up data segments that have not yet taken effect (i.e., all unverified or failed verification segments from the fifth segment onwards). Data segments that have already been verified and marked as effective (e.g., the first four segments) remain unchanged, and the system continues to use this effective data. In this way, the system can quickly roll back to the most recent stable state, i.e., the state after the fourth data segment took effect, avoiding the problem of needing to roll back to the initial state or re-execute the entire upgrade process in traditional methods, greatly reducing rollback costs and system recovery time. Furthermore, the rollback control module also logs the upgrade failure information so that the system can recover or re-execute the upgrade process in the next upgrade, for example, starting again from before the failed segment.
[0087] Through the above process, smart home device B can achieve parallel processing of data writing and verification when receiving upgrade data, significantly improving upgrade efficiency and avoiding process blockage caused by time-consuming verification in traditional methods. Simultaneously, when local data issues occur during the upgrade process, the system can accurately roll back to the most recent stable state, only cleaning up ineffective data and preserving the successfully upgraded portions to the maximum extent possible. This reduces rollback costs and system recovery time, improving the reliability and flexibility of the upgrade.
[0088] Obviously, the above embodiments are merely illustrative examples for clear explanation and are not intended to limit the implementation. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations here. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.
Claims
1. A streaming upgrade execution and rollback method based on verification lag confirmation, characterized in that, Includes the following steps: S1: Upgrade process initialization: Receive upgrade trigger command, start upgrade process, and create execution context information to record the upgrade process; S2: Upgrade data reception and segmentation: Receive upgrade data stream, and divide the upgrade data stream into multiple continuous data segments according to a predetermined rule. Each data segment corresponds to a basic execution unit in the upgrade process. S3: Upgrade data pre-writing: The received data fragment is directly written to the pre-write storage area without waiting for the fragment verification to be completed; S4: Background verification processing: The verification module runs independently in the background and performs verification processing on the written data fragments; S5: Upgrade data activation control: Control the activation status of upgrade data according to the verification results in step S4. If the data segment passes the verification, it is marked as an effective state and the system activation boundary is updated. Data segments whose verification results are not determined remain in an ineffective state. S6: Upgrade anomaly handling and rollback: If the verification of one of the data segments is detected to be unsuccessful, the subsequent upgrade process is stopped immediately. Only the data segments that have not yet taken effect are discarded or cleaned up, while the data that has taken effect remains unchanged, so as to roll back the system to the most recent stable state.
2. The streaming upgrade execution and rollback method based on verification lag confirmation according to claim 1, characterized in that: In step S1, the execution context information is used to record the status of the current upgrade task.
3. The streaming upgrade execution and rollback method based on verification lag confirmation according to claim 1, characterized in that: In step S3, after the pre-writing is completed, the system records the writing status of the data segment and updates the writing progress information in the upgrade context.
4. The streaming upgrade execution and rollback method based on verification lag confirmation according to claim 1, characterized in that: The verification process in step S4 includes: data integrity verification, data structure legality verification, and semantic legality verification of patch or differential data; at the same time, after the verification module completes the verification, it will generate the verification result corresponding to the data segment and feed the result back to the upgrade management module.
5. The streaming upgrade execution and rollback method based on verification lag confirmation according to claim 1, characterized in that: In step S2, while generating the data fragments, the system records the target write position, data length, and related verification information for each data fragment so that the verification module can perform verification later.
6. A streaming upgrade execution and rollback apparatus based on verification lag confirmation, employing the method of any one of claims 1-6, characterized in that: include: The upgrade management module is used to receive upgrade trigger commands, start the upgrade process, create and maintain the upgrade execution context, coordinate the work of various modules, receive verification results, and control the progress of the upgrade process. The upgrade execution module is used to receive the upgrade data stream, divide it into multiple consecutive data segments, write the data segments into a pre-write storage area, record the write status, and update the write progress. The verification module is used to run independently in the background to perform verification processing on the written data fragments, generate verification results, and feed them back to the upgrade management module. The effectiveness control module is used to control the effectiveness status of the data fragment based on the verification result, update the system effectiveness boundary, and make the verified data included in the system's accessible range. The rollback control module is used to stop the subsequent upgrade process when a verification failure is detected, discard or clean up the data fragments that have not yet taken effect, and roll back the system to the most recent stable state.
7. The streaming upgrade execution and rollback apparatus based on verification lag confirmation according to claim 6, characterized in that: The verification module's verification content includes one or more of the following: data integrity verification, data structure legality verification, and semantic legality verification.
8. The streaming upgrade execution and rollback apparatus based on verification lag confirmation according to claim 6, characterized in that: The upgrade execution module and the verification module work in parallel, and the data fragment writing operation does not need to wait for the verification to complete.
9. The streaming upgrade execution and rollback apparatus based on verification lag confirmation according to claim 6, characterized in that: The data activation control module implements data activation control by updating storage mapping relationships or system access pointers.
10. The streaming upgrade execution and rollback apparatus based on verification lag confirmation according to claim 6, characterized in that: The rollback control module can also be used to record upgrade log information so that the system can recover or re-execute the upgrade process during the next upgrade.