Embedded version management method supporting cross-version jump upgrade

Abstract

The invention discloses an embedded version management system supporting cross-version jump upgrade, and belongs to the technical field of embedded software upgrade management. The system comprises a version modeling module, an upgrade path planner, an upgrade package manager, an upgrade execution engine, a rollback control module and a configuration management module. The version modeling module analyzes a dependency relationship between management software versions and constructs a version relationship graph; the path planner calculates an optimal upgrading path; the upgrade package manager is responsible for resource storage and distribution; the execution engine executes upgrading according to the plan; the rollback module processes the failure condition; and the configuration module manages system parameters. The system adopts a graph theory algorithm for modeling, supports jump upgrade or multi-step path planning, and manages upgrade packages through hierarchical storage. The problem that a traditional system lacks flexible path planning and cross-version upgrading support is solved, and upgrading reliability and flexibility are improved.

Description

Technical Field

[0001] This invention relates to the field of embedded system software management, and more specifically to an embedded version management system that supports cross-version jump upgrades. Background Technology

[0002] With the widespread application of embedded systems in industrial control, smart homes, medical devices, and other fields, higher demands are being placed on the reliability, flexibility, and efficiency of software upgrades. Embedded system version management is a key technology for ensuring stable device operation and continuous functional updates, and its core lies in how to securely and efficiently upgrade and roll back software versions.

[0003] Traditional embedded system version upgrades typically employ a linear, incremental approach, meaning devices must be upgraded sequentially according to the release order. For example, upgrading from version 1.0 to version 4.0 requires going through versions 2.0 and 3.0 in turn, and cannot directly jump to the target version. This approach has many limitations in practical applications, especially when the device version is significantly outdated, resulting in a lengthy upgrade process and accumulated risks.

[0004] Currently, the industry offers various OTA (Over-The-Air) upgrade technologies. CN112230966B discloses an OTA upgrade method and apparatus. This method generates a path information table by rationally planning upgrade paths for registered versions, and determines the appropriate target version to push based on the current version on the vehicle's infotainment system, avoiding the inefficiency caused by upgrading sequentially according to the registration order. However, this solution is mainly designed for in-vehicle systems and does not fully consider the resource-constrained characteristics of embedded devices, nor does it accurately model the complex dependencies between versions.

[0005] CN113419771B proposes a method for creating application software upgrade packages. This method calculates the feature values ​​of the new and base versions of the program files, compares them, classifies and labels them, and adds an upgrade script to form the upgrade package. This method simplifies the upgrade process and improves efficiency, but it primarily focuses on upgrading single application software and does not address system-level version management issues, especially the complexity of multi-component collaborative upgrade scenarios.

[0006] CN116431170A (application publication number) describes a mobile terminal system upgrade method based on DAG (Directed Acyclic Graph) for multi-party collaborative ecosystem development. It constructs upgrade dependency and trust relationship data descriptions through a DAG data structure model, providing a verified optimal upgrade path. While this method is innovative in handling complex dependencies, it is primarily designed for mobile terminal systems and does not fully consider the special needs of embedded systems, such as resource constraints and power-off recovery.

[0007] CN119960819A discloses an OTA version management method that determines a stability assessment strategy based on the current version information and the version to be upgraded, and determines the upgrade path planning through automated test evaluation results. This method emphasizes stability assessment during the upgrade process, but lacks a flexible rollback mechanism for upgrade failures and does not provide visual management capabilities for inter-version dependencies.

[0008] Existing technologies suffer from the following major problems: First, traditional embedded system upgrade methods typically only support linear, incremental upgrades, failing to enable direct jumps between versions. This results in low upgrade efficiency, especially when the device version is significantly outdated, requiring multiple upgrade operations, which is not only time-consuming but also accumulates the risk of failure. Second, existing rollback mechanisms have limited capabilities, mostly supporting rollback to the previous version only, unable to flexibly roll back to any historically stable version, limiting the system's recoverability in case of upgrade failure or operational anomalies. Third, there is a lack of precise management of inter-version dependencies and compatibility. The upgrade process often relies on manually written scripts, which are prone to failure due to script errors. Finally, in the context of multi-project collaborative management, the complex version tree structure dramatically increases the difficulty and complexity of script management for cross-version upgrades, heavily relying on manual intervention, leading to high maintenance costs and significant upgrade risks.

[0009] Therefore, there is an urgent need for an embedded version management system that can support cross-version jump upgrades, has flexible rollback capabilities, accurately manage version dependencies, and reduce the complexity of multi-project collaborative management. Summary of the Invention

[0010] To address the technical problems of traditional embedded system upgrade methods, such as low efficiency of linear progressive upgrades, limited rollback mechanism capabilities, inaccurate version dependency management, and complex multi-project collaborative management, and to achieve technical effects such as flexible and efficient upgrade paths, powerful and flexible rollback capabilities, reliable compatibility assurance, automated upgrade process, and strong system adaptability, this invention provides an embedded version management system that supports cross-version skip upgrades.

[0011] The technical solution adopted by this invention to solve its technical problem is: to provide an embedded version management system that supports cross-version jump upgrades, including a version modeling module, an upgrade path planner, an upgrade package manager, an upgrade execution engine, a rollback control module, and a configuration management module.

[0012] The version modeling module is used to parse and manage the dependencies and compatibility rules between all software versions. By reading the predefined structured configuration file, it obtains the metadata of each version, builds and maintains a directed version relationship graph, where nodes represent versions and directed edges represent feasible upgrade paths between versions. It supports dynamic updates and automatically identifies and resolves version dependency loop conflicts.

[0013] Preferably, the version modeling module obtains the metadata for each version by reading a predefined structured configuration file. The metadata includes at least one of the following: version number, list of dependent predecessor versions, inter-version compatibility identifier, upgrade script path, and rollback script path.

[0014] Furthermore, when constructing the directed version relationship graph, the version modeling module uses graph theory algorithms for loop detection and conflict resolution, and supports dynamic updates to integrate new versions.

[0015] The upgrade path planner dynamically calculates the optimal upgrade path based on the version relationship graph, the current device version, and the user-specified target version. It supports direct skipping of upgrade paths or finding the optimal path through a graph search algorithm, thus possessing path optimization capabilities. Preferably, the upgrade path planner's operating logic includes: checking whether there is a compatible direct connection between the current version and the target version; if so, generating a direct skip upgrade path; if not, initiating a graph search algorithm to find a feasible path from the current version to the target version in the version relationship graph. The graph search algorithm is either breadth-first search or Dijkstra's algorithm. To adapt to the resource-constrained characteristics of embedded devices, the Dijkstra algorithm uses an adjacency list to store the graph structure. The adjacency list is stored in the device's local non-volatile memory (such as Flash). Actual testing shows that in a graph containing 50 version nodes, memory usage is less than 10KB, enabling efficient operation on mainstream embedded processors such as the Cortex-M7.

[0016] Furthermore, the upgraded path planner also has a path optimization function, which is used to merge redundant steps and provide multiple alternative path suggestions when a direct route is not possible.

[0017] The upgrade package manager is responsible for storing, verifying the integrity of, and distributing all upgrade package resources on demand. It adopts a hierarchical storage strategy and categorizes and stores upgrade packages according to logical dimensions such as the major version number.

[0018] Preferably, the upgrade package manager adopts a hierarchical storage strategy, classifies and stores upgrade packages according to their major version numbers, and indexes the links of all component versions under it through a top-level metadata file.

[0019] Furthermore, the standardized file set in the upgrade package includes at least the target version firmware image, upgrade script, rollback script, and configuration file describing version metadata.

[0020] The upgrade execution engine executes the upgrade operations sequentially according to the plan generated by the upgrade path planner, including the pre-verification stage, firmware flashing stage, script execution stage, and status recording and reporting.

[0021] Preferably, the execution process of the upgrade execution engine includes: a pre-verification stage: checking the device hardware status, remaining storage space, and battery power, and confirming the compatibility between the current version and the target version; a firmware flashing stage: writing the firmware image of the target version to the designated storage partition of the device; a script execution stage: atomically executing the upgrade script in the upgrade package, specifically recording the operation steps through a transaction log. The transaction log is stored in an independent Flash sector. After the device restarts, the system reads the log first. If an incomplete upgrade operation is detected, the rollback control module is automatically triggered to restore the system to the state before the operation, ensuring the atomicity of the upgrade operation and power failure safety; and a status recording and reporting stage: recording and persistently storing the key states and results during the upgrade process.

[0022] The rollback control module is activated when it detects an upgrade failure or receives a user rollback command. It supports rolling back to any historical version and executing firmware recovery operations and rollback scripts.

[0023] Preferably, the execution flow of the rollback control module includes: displaying a list of all available historical versions to the user; obtaining the corresponding firmware and rollback script from the upgrade package manager according to the selected version; performing a firmware recovery operation to roll back the system firmware to the target version; and executing the rollback script to restore the data state.

[0024] The configuration management module serves as the system's control center, unifying the management of various configuration parameters and upgrade strategies, and providing both command-line interface and web graphical interface for interaction.

[0025] Preferably, the configuration management module provides at least one interaction method, either a command-line interface or a web graphical interface, for policy configuration, upgrade task triggering, status monitoring, and visualization of system upgrade history and version relationships.

[0026] The beneficial effects of this invention are as follows:

[0027] 1. Flexible and Efficient Upgrade Path: Through version relationship modeling and intelligent path planning, it supports direct jump upgrades from any historical version to the target version, breaking through the limitations of linear upgrades and greatly improving upgrade efficiency. Compared with traditional methods that require step-by-step upgrades, this invention can achieve a one-step upgrade while maintaining version compatibility, significantly shortening upgrade time and reducing the risk of accumulated failures. Actual testing showed that jumping from v1.0.0 to v3.0.0 reduced upgrade time by 70% compared to traditional linear upgrades and by approximately 35% compared to the existing DAG scheme (CN116431170A (application publication number)) (see Example 2 in the detailed implementation).

[0028] 2. Powerful and flexible rollback capabilities: It enables rollback to any historical version, providing stronger system fault tolerance and version management flexibility. When an upgrade fails or the system malfunctions, it is no longer limited to reverting to the previous version, but can choose any stable version for recovery according to actual needs, significantly improving system reliability and maintainability.

[0029] 3. Reliable Compatibility Guarantee: Through automated version dependency and compatibility checks, upgrade failures due to version incompatibility are fundamentally avoided, significantly improving system stability and reliability. The system performs a comprehensive compatibility check before upgrading to ensure the target version is fully compatible with the current hardware and software environment, avoiding upgrade failures caused by script errors in traditional methods.

[0030] 4. Automated upgrade process with power outage recovery capability: Utilizing standardized upgrade packages and an automated execution engine, the upgrade process is fully automated, significantly reducing manual intervention costs and operational risks. An independent Flash sector transaction log mechanism effectively handles unexpected power outages during the upgrade process, ensuring system robustness.

[0031] 5. High adaptability and low resource consumption: Supports both one-click upgrade and incremental upgrade modes, adapting to different network environments and version compatibility requirements, improving the system's applicability in complex scenarios. The core path planning algorithm is optimized for embedded devices, and the graph structure is stored in non-volatile memory, resulting in low memory consumption (<10KB), allowing for wide deployment in various resource-constrained embedded terminals. Attached Figure Description

[0032] Figure 1 : System module interaction architecture diagram of this solution;

[0033] Figure 2 : Flowchart of version relationship construction in this solution;

[0034] Figure 3 : Flowchart of the upgrade execution process for this solution;

[0035] Figure 4 : Flowchart of the rollback control scheme;

[0036] Figure 5 Flowchart of performance comparison analysis for this solution. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0038] Example 1

[0039] like Figure 1 As shown, an embodiment of the cross-version upgrade system

[0040] This embodiment provides a cross-version upgrade system that enables efficient and secure software upgrades, and is especially suitable for scenarios that require upgrades across multiple versions.

[0041] The cross-version upgrade system includes a version modeling module, an upgrade path planner, an upgrade package manager, an upgrade execution engine, a rollback control module, and a configuration management module.

[0042] The version modeling module parses and manages dependencies and compatibility rules between all software versions, and constructs and maintains a directed version graph where nodes represent versions and directed edges represent feasible upgrade paths between versions. This module obtains metadata for each version by reading predefined structured configuration files. This metadata includes the version number, a list of dependent predecessor versions, inter-version compatibility flags, upgrade script paths, and rollback script paths. The compatibility flags are based on semantic versioning (Major.Minor.Patch) rules and can be precisely defined through structured configuration. For example, the system uses a YAML-formatted configuration file to define version information.

[0043] Upgrades and rollbacks: When the system needs to be upgraded to version 2.1.0, dependencies and compatibility conditions are first verified to ensure the environment meets requirements. Then, the specified upgrade script is executed, which is responsible for implementing the specific steps of version change, such as updating files, modifying configurations, or migrating data. If an exception or failure occurs during the upgrade process, the system will automatically or manually trigger the rollback script to restore the system to its state before the upgrade, thereby ensuring service continuity and stability. Overall, this configuration file achieves automated version control and minimizes risks through a structured approach. This configuration clearly states that the current software version number is 2.1.0 and lists its dependent predecessor version 2.0.0. Crucially, the compatibility field defines that this version is only compatible with versions with a major version number of 2. This means that upgrading from v2.0.0 to v2.1.0 is allowed, but a direct jump upgrade from v1.5.0 (Major=1) is not permitted, ensuring strict compatibility control between major versions.

[0044] like Figure 2 As shown, when constructing the directed version relationship graph, the version modeling module uses graph theory algorithms for loop detection and conflict resolution, and supports dynamic updates to integrate new versions. For example, the system can construct a directed graph containing nodes such as v1.0.0, v1.1.0, v2.0.0, and v3.0.0, and define v1.0.0 and v3.0.0 as directly compatible, allowing direct skip upgrades.

[0045] The upgrade path planner dynamically calculates the optimal upgrade path from the current version to the target version based on the version relationship graph provided by the version modeling module, the current device version, and the user-specified target version. Its working logic includes checking if there are compatible direct edges between the current and target versions; if so, a direct jump upgrade path is generated. If not, a graph search algorithm is initiated to find a feasible path from the current version to the target version in the version relationship graph. The graph search algorithm preferably uses Dijkstra's algorithm and is optimized for the resource-constrained environment of embedded systems: an adjacency list storage graph structure is adopted, with the adjacency list persistently stored in the device's local non-volatile memory (such as Flash), rather than a more memory-intensive adjacency matrix. In actual testing, this optimization kept memory usage below 10KB in a graph containing 50 version nodes, enabling efficient operation on mainstream embedded processors such as the ARM Cortex-M7 and ensuring the system's broad applicability.

[0046] For example, when a user requests to upgrade from v1.5.0 to v2.1.0, the upgrade path planner queries the version graph and finds that there are no direct edges from v1.5.0 to v2.1.0, and according to compatibility rules (different major version numbers), v1.5.0 and v2.0.0 are known to be incompatible. Therefore, it plans the following path using a graph search algorithm: v1.5.0 -> v1.9.0 (assuming it's the last compatible version of v1.x) -> v2.0.0 -> v2.1.0. In actual optimization, the planner will either look for a fully compatible path or explicitly inform the user that there are incompatible nodes on this path.

[0047] The upgrade path planner also features path optimization capabilities, merging redundant steps and providing multiple alternative path suggestions when a direct route is not available. For example, when a user wants to upgrade directly from v1.0.0 to v3.0.0, the upgrade path planner will find a direct compatible edge from v1.0.0 to v3.0.0, thus generating a direct skip upgrade path that bypasses intermediate versions v1.1.0 and v2.0.0, improving upgrade efficiency.

[0048] The upgrade package manager is responsible for storing, verifying the integrity of, and distributing all upgrade package resources on demand. Each upgrade package is an independent, standardized collection of files. The manager employs a hierarchical storage strategy, categorizing upgrade packages by major version number and indexing links to all component versions below it through a top-level metadata file.

[0049] The upgrade package manager's storage directory structure is standardized as follows: The system first creates a top-level directory based on the software's major version number (e.g., 1.x series and 2.x series) to achieve physical isolation between different major versions. For each specific software version (e.g., 1.5.0, 2.0.0, 2.1.0), the system creates a separate dedicated directory. Within each version directory, all components necessary for performing the upgrade are stored, including firmware files, upgrade scripts, rollback scripts, and metadata files.

[0050] The standardized set of files in the upgrade package includes at least the target firmware image, upgrade scripts, rollback scripts, and configuration files describing version metadata. These files ensure the integrity and reliability of the upgrade process.

[0051] like Figure 3As shown, the upgrade execution engine executes the upgrade operations sequentially according to the upgrade path generated by the upgrade path planner. The execution process includes: a pre-verification phase: checking the device hardware status, remaining storage space, and battery power, and confirming the compatibility between the current version and the target version; a firmware flashing phase: writing the firmware image of the target version to the designated storage partition of the device; a script execution phase: atomically executing the upgrade script in the upgrade package, specifically recording the operation steps through a transaction log stored in a dedicated, protected, independent Flash sector. When the system starts (including after an unexpected reboot), it will first read this log area. If an upgrade transaction marked 'in-progress' is detected, it is determined that the previous upgrade process was abnormally interrupted, and the rollback control module is immediately and automatically triggered to restore the system to the stable state before the start of this upgrade operation, thereby ensuring the atomicity of the upgrade operation and the consistency of the system even in extreme situations such as power outages; and a status recording and reporting phase: recording and persistently storing the key states and results during the upgrade process.

[0052] For example, when performing a direct jump upgrade from v1.0.0 to v3.0.0, the upgrade execution engine performs a complete upgrade operation: pre-verification, flashing the v3.0.0 firmware, and executing the v3.0.0 upgrade script. After a successful upgrade, the system version changes to v3.0.0. The entire process requires only one reboot and one operation, making it far more efficient than a step-by-step upgrade.

[0053] like Figure 4 As shown, the rollback control module is used to perform a rollback operation to restore the system to any specified historical version when the upgrade fails or a rollback command is received. Its execution flow includes displaying a list of all available historical versions to the user; retrieving the corresponding firmware and rollback script from the upgrade package manager based on the selected version; performing a firmware recovery operation to revert the system firmware to the target version; and executing the rollback script to restore the data state.

[0054] The configuration management module is used to uniformly manage the system's configuration parameters and upgrade policies, and provides a user interface. This module offers at least one interaction method: a command-line interface or a web graphical interface, for policy configuration, upgrade task triggering, status monitoring, and visualization of system upgrade history and version relationships.

[0055] Through the collaborative work of the above modules, this cross-version upgrade system can achieve efficient, secure, and reliable software upgrades. Especially when upgrades need to be performed across multiple versions, it can provide the optimal upgrade path and ensure the security and rollback capability of the upgrade process.

[0056] Example 2

[0057] Example of an upgrade efficiency comparison experiment

[0058] To verify the significant improvement in upgrade efficiency of this invention, the following comparative experiment was designed and executed:

[0059] 1. Experimental objective: To quantitatively compare the differences in upgrade time between the traditional linear step-by-step upgrade method, the existing DAG upgrade scheme (CN116431170A (application publication number)) and the cross-version jump upgrade method of this invention.

[0060] 2. Test environment:

[0061] Hardware platform: An embedded development board based on the ARM Cortex-M7 core, with a main frequency of 400MHz, a Flash capacity of 2MB, and a RAM capacity of 1MB.

[0062] Software versions: A test suite was built containing four versions: v1.0.0, v1.1.0, v2.0.0, and v3.0.0. In the version relationship diagram, v1.0.0 and v3.0.0 are modeled as directly compatible, allowing for skip upgrades.

[0063] Network environment: A stable 100Mbps wired network, eliminating the impact of network fluctuations on the download time of the upgrade package.

[0064] 3. Testing Method:

[0065] like Figure 5 As shown, control group A (traditional linear method): simulates the traditional linear upgrade process, forcing the device to upgrade sequentially from v1.0.0 to v1.1.0, then to v2.0.0, and finally to v3.0.0. The total time taken from the start of the upgrade to successfully verifying version v3.0.0 was recorded. This process included 3 independent firmware flashes, 3 script executions, and 3 device reboots.

[0066] Control Group B (DAG Scheme): This scheme employs the DAG-based upgrade method disclosed in CN116431170A (application publication number), performing upgrade path planning and execution under the same hardware and version set conditions. This scheme can skip some unnecessary intermediate versions, but due to its relatively high model complexity and significant path computation overhead on embedded devices, the planned path may not be optimal, and the preparation time before execution is relatively long. The total execution time is recorded.

[0067] Experimental Group (This Invention): Using the system of this invention, the device was upgraded directly from v1.0.0 to v3.0.0. The total time taken from path planning to successful upgrade verification was recorded. This process consisted of only one firmware flash, one script execution, and one device reboot.

[0068] Each experiment was repeated 30 times, and the average time taken was taken as the final result.

[0069] 4. Experimental Results:

[0070] The average total time for control group A (traditional linear upgrade) was 210 seconds.

[0071] The average total time for control group B (upgraded DAG scheme) was 98 seconds.

[0072] The average total time for the experimental group (the invention's leapfrog upgrade) was 63 seconds.

[0073] 5. Experimental Conclusion:

[0074] The cross-version skip upgrade method of this invention reduces the time required to upgrade from v1.0.0 to v3.0.0 by 70% compared to the traditional linear step-by-step upgrade method, and by approximately 35% compared to the existing DAG scheme (CN116431170A (application publication number)). This data fully demonstrates the dual advantages of this invention in terms of the accuracy of upgrade path planning and execution efficiency. The improved efficiency mainly stems from: 1) more precise compatibility control and a lighter graph model, making path planning faster and more direct; 2) reducing redundant intermediate version flashing, script execution, and device restarts, significantly reducing time overhead and accumulated risks during the upgrade process.

[0075] Finally, it should be noted that the above descriptions are merely preferred embodiments of this application, and this application is not limited to the above embodiments. It is understood that other improvements and variations directly derived or conceived by those skilled in the art without departing from the spirit and concept of this application should be considered to be included within the protection scope of this application.

Claims

1. An embedded version management system that supports cross-version jump upgrades, characterized in that, The system is deployed on an embedded device with Flash capacity ≤2MB and RAM capacity ≤1MB, and includes: a version modeling module, used to parse and manage the dependencies and compatibility rules between all software versions, and to build and maintain a directed version relationship graph, where nodes represent versions and directed edges represent feasible upgrade paths between versions; The upgrade path planner is used to dynamically calculate the optimal upgrade path from the current version to the target version based on the version relationship diagram provided by the version modeling module, the current version of the device, and the target version specified by the user; the upgrade package manager is responsible for the storage, integrity verification, and on-demand distribution of all upgrade package resources, where each upgrade package is an independent set of standardized files; the upgrade execution engine is used to execute upgrade operations sequentially according to the upgrade path generated by the upgrade path planner. The rollback control module is used to perform a rollback operation to restore the system to any specified historical version when the upgrade fails or a rollback instruction is received. The configuration management module is used to unify the system's configuration parameters and upgrade strategies, and provides a user interface. The upgrade path planner uses an adjacency list to store the version relationship graph. The adjacency list is persistently stored in the device's non-volatile memory, and its memory usage is less than 10KB in a scenario containing 50 version nodes. The upgrade execution engine achieves atomicity and power failure recovery capability for the upgrade operation through transaction logs stored in an independent Flash sector.

2. The system according to claim 1, characterized in that, The version modeling module obtains the metadata for each version by reading a predefined structured configuration file. The metadata includes at least one of the following: version number, list of dependent predecessor versions, inter-version compatibility identifier, upgrade script path, and rollback script path.

3. The system according to claim 2, characterized in that, When constructing the directed version relationship graph, the version modeling module uses graph theory algorithms for loop detection and conflict resolution, and supports dynamic updates to integrate new versions.

4. The system according to claim 1, characterized in that, The working logic of the upgrade path planner includes: Check if there is a compatible direct connection between the current version and the target version. If so, generate a direct jump upgrade path. If no path exists, the graph search algorithm is initiated to find a feasible path from the current version to the target version in the version relationship graph. The graph search algorithm is Dijkstra's algorithm.

5. The system according to claim 1, characterized in that, The upgrade package manager adopts a hierarchical storage strategy, classifying and storing upgrade packages according to their major version numbers, and indexing the links of all component versions under it through a top-level metadata file.

6. The system according to claim 1, characterized in that, The execution process of the upgraded execution engine includes: Pre-verification phase: Check device hardware status, remaining storage space and battery level, and confirm compatibility between the current version and the target version; Firmware flashing stage: Write the target version of the firmware image to the specified storage partition of the device; Script execution phase: The upgrade script in the upgrade package is executed atomically. The atomic execution of the upgrade script is achieved through transaction logs, which specifically includes: recording operation steps in an independent Flash sector; if the execution fails, rolling back to the previous state point according to the log; after the device restarts, the log is read first, and if an incomplete operation is detected, a rollback is automatically triggered. Status recording and reporting phase: Record key statuses and results during the upgrade process and persist them.

7. The system according to claim 1, characterized in that, The execution flow of the rollback control module includes: Show users a list of all available historical versions; Based on the selected version, obtain the corresponding firmware and rollback script from the upgrade package manager; Perform a firmware restore operation to revert the system firmware to the target version; Execute the rollback script to restore the data state.

8. The system according to claim 1, characterized in that, The configuration management module provides at least one interaction method, either a command-line interface or a web graphical interface, for policy configuration, upgrade task triggering, status monitoring, and visualization of system upgrade history and version relationships.

9. The system according to claim 1, characterized in that, The standardized set of files in the upgrade package includes at least the target version firmware image, upgrade script, rollback script, and configuration file describing version metadata.

10. The system according to claim 1, characterized in that, The upgraded path planner also has a path optimization function, which is used to merge redundant steps and provide multiple alternative path suggestions when a direct route is not possible.

Images