Dual-system atomization upgrading method, device, controller and storage medium for embedded device

Abstract

The application relates to a dual-system atomization upgrading method and device of an embedded device, a controller, a computer readable storage medium and a computer program product. The method comprises the following steps: determining a system upgrading task for the embedded device, generating operation sequences for each function partition in a default system partition group and a recovery system partition group according to the system upgrading task; determining a target partition based on the operation sequences, upgrading the target partition according to the operation sequences, and dynamically updating the partition state of the target partition in the state mapping table during the upgrading process of the target partition; in the case that the target partition is upgraded, determining a next function partition based on the operation sequences, determining the next function partition as the target partition, returning to the step of upgrading the target partition according to the operation sequences, and performing the step until the dual-system upgrading process for the embedded device is completed. The method can realize fine control of the upgrading process.

Description

Technical Field

[0001] This application relates to the field of embedded systems technology, and in particular to a dual-system atomic upgrade method, apparatus, controller, computer-readable storage medium, and computer program product for embedded devices. Background Technology

[0002] In dual-system upgrades for embedded devices, a common approach is to partition the storage medium into two independent system partitions, using a boot pointer or environment variables to indicate the currently booting system. When an upgrade is needed, the upgrade tool writes the new system image to the inactive system partition, and after successful verification, switches the boot pointer. In this method, the entire upgrade process is a "black box" to the system; the outside world cannot obtain precise upgrade progress or partition health information. If an unexpected interruption, such as a power outage, occurs during the writing process, the system can only detect the image's inaccuracy through overall verification, but cannot pinpoint the specific failure location. Therefore, a complete rollback or re-upgrade recovery strategy must be adopted, making the upgrade process uncontrollable. Summary of the Invention

[0003] Based on this, it is necessary to provide a dual-system atomic upgrade method, apparatus, controller, computer-readable storage medium, and computer program product for embedded devices that can achieve fine-grained control over the upgrade process, addressing the aforementioned technical problems.

[0004] In a first aspect, this application provides a dual-system atomic upgrade method for an embedded device. The storage medium of the embedded device includes a default system partition group, a recovery system partition group, and an independent state management partition. The default system partition group includes a function partition of the default system, the recovery system partition group includes a function partition of the recovery system, and the state management partition includes a state mapping table that records the partition states of the default system partition group and the recovery system partition group respectively. The method includes:

[0005] Determine the system upgrade task for the embedded device, and generate an operation sequence for each functional partition in the default system partition group and the recovery system partition group based on the system upgrade task;

[0006] The target partition is determined based on the operation sequence, and the target partition is upgraded according to the operation sequence. During the upgrade process of the target partition, the partition status of the target partition in the status mapping table is dynamically updated.

[0007] Once the target partition upgrade is complete, the next functional partition is determined based on the operation sequence, and this next functional partition is designated as the target partition. The process then returns to execute the steps for upgrading the target partition according to the operation sequence, until the dual-system upgrade process for the embedded device is completed.

[0008] Secondly, this application also provides a dual-system atomic upgrade device for embedded devices, comprising:

[0009] The operation sequence generation module is used to determine the system upgrade task for the embedded device and generate an operation sequence for each functional partition in the default system partition group and the recovery system partition group based on the system upgrade task. The storage medium of the embedded device includes the default system partition group, the recovery system partition group, and an independent status management partition. The default system partition group includes the functional partition of the default system, the recovery system partition group includes the functional partition of the recovery system, and the status management partition includes a status mapping table that records the partition status of the default system partition group and the recovery system partition group respectively.

[0010] The partition upgrade module is used to determine the target partition based on the operation sequence, upgrade the target partition according to the operation sequence, and dynamically update the partition status of the target partition in the status mapping table during the upgrade process.

[0011] The loop upgrade module is used to determine the next functional partition based on the operation sequence after the target partition upgrade is completed, and to designate the next functional partition as the target partition. It then returns to execute the steps of upgrading the target partition according to the operation sequence until the dual-system upgrade process for the embedded device is completed.

[0012] Thirdly, this application also provides a controller, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the method provided in the first aspect above.

[0013] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method provided in the first aspect above.

[0014] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps in the method provided in the first aspect above.

[0015] The aforementioned dual-system atomic upgrade method, apparatus, controller, computer-readable storage medium, and computer program product for embedded devices, based on the embedded device's storage medium including a default system partition group, a recovery system partition group, and an independent state management partition, generates an operation sequence for each functional partition according to the system upgrade task. This refines the upgrade operation to the level of a single functional partition, and upgrades partition by partition during the upgrade process. The corresponding partition status in the state mapping table is dynamically updated during the upgrade of each partition, enabling real-time and accurate monitoring of the upgrade progress and status of each partition, achieving process state perceptibility. Only after the current target partition is upgraded is the next functional partition determined and upgraded according to the operation sequence. This sequential advancement of control logic ensures the orderliness and controllability of the entire upgrade process, transforming the dual-system upgrade process of embedded devices into a refined, controllable, and observable atomic process, achieving refined management of the upgrade process. Attached Figure Description

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

[0017] Figure 1 This is a diagram illustrating the application environment of a dual-system atomic upgrade method for an embedded device in one embodiment.

[0018] Figure 2 This is a flowchart illustrating a dual-system atomic upgrade method for an embedded device in one embodiment;

[0019] Figure 3 This is a schematic diagram of the interrupted continuation process in one embodiment;

[0020] Figure 4 This is a schematic diagram of the dual-system storage media partition layout in one embodiment;

[0021] Figure 5 This is a schematic diagram of the intelligent startup decision-making process for dual systems in Loader mode in one embodiment;

[0022] Figure 6 This is a schematic diagram of the dual-system atomic update workflow in uboot mode in one embodiment;

[0023] Figure 7 This is a schematic diagram of the dual-system atomic update workflow in rootfs mode in one embodiment;

[0024] Figure 8 This is a schematic diagram of the dual-system atomic symmetry processing workflow in rootfs mode in one embodiment;

[0025] Figure 9 This is a structural block diagram of a dual-system atomization upgrade device for an embedded device in one embodiment;

[0026] Figure 10 This is a diagram of the internal structure of the controller in one embodiment. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0028] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0029] The dual-system atomic upgrade method for embedded devices provided in this application embodiment can be applied to, for example... Figure 1 In the application environment shown, controller 102 can establish communication with embedded device 104. The storage medium of embedded device 104 includes a default system partition group, a recovery system partition group, and an independent state management partition. The default system partition group includes functional partitions of the default system, the recovery system partition group includes functional partitions of the recovery system, and the state management partition includes state mapping tables that record the partition states of the default system partition group and the recovery system partition group respectively. Controller 102 can determine the system upgrade task for embedded device 104 and generate an operation sequence for each functional partition in the default system partition group and the recovery system partition group based on the system upgrade task. Controller 102 can determine the target partition based on the operation sequence, upgrade the target partition according to the operation sequence, and dynamically update the partition state of the target partition in the state mapping table during the upgrade process. After the target partition upgrade is completed, controller 102 can determine the next functional partition based on the operation sequence, designate the next functional partition as the target partition, and return to execute the steps of upgrading the target partition according to the operation sequence until the dual-system upgrade process for embedded device 104 is completed.

[0030] The controller 102 may include computer devices such as terminals and / or servers. The controller 102 may also be an internal entity of the embedded device 104, such as a microcontroller unit (MCU), central processing unit, digital signal processor, field-programmable gate array, application-specific integrated circuit, etc. The terminal may include, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices may include smart speakers, smart TVs, smart air conditioners, smart vehicle devices, projection devices, etc. Portable wearable devices may include smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices may include virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. The server may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0031] In one exemplary embodiment, such as Figure 2 As shown, a dual-system atomic upgrade method for embedded devices is provided. In this embodiment, the method is applied to... Figure 1 The following steps are used as an example of the controller in the example, including steps 202 to 206. Wherein:

[0032] Step 202: Determine the system upgrade task for the embedded device, and generate an operation sequence for each functional partition in the default system partition group and the recovery system partition group based on the system upgrade task.

[0033] Embedded devices are dedicated computer systems that can be embedded into larger mechanical or electrical systems to perform specific, predefined functions. Examples of embedded devices include network video recorders and industrial gateways. Embedded devices are extremely sensitive to the risk of becoming "bricked" during upgrades, as their storage media (such as Flash memory) can run a complete system for booting and operation.

[0034] A default system partition group is a set of physical or logical storage areas partitioned on the storage medium of an embedded device. The default system partition group is designed to store a complete default system intended for booting first. A default system partition group can consist of multiple contiguous or non-contiguous, functionally independent functional partitions, collectively forming a bootable default system. Data within the default system partition group can be organized according to functional modules. For example, it can contain a configuration partition storing device initialization and hardware configuration data, a bootloader partition storing the first and second stage code of the bootloader, a kernel partition storing the operating system kernel, and a root file system partition storing the file system and applications. The default system is the operating system selected as the primary boot target when the embedded device is functioning correctly, without malfunctions or special instructions being executed. For example, if the embedded device is an industrial gateway, its default system partition group may contain firmware version V1.0 (the default system). When the device is powered on, its bootloader (such as uboot) will first check if the default system partition group is functioning correctly; if the check passes, the device will boot from the default system, running the V1.0 version of the operating system, drivers, and applications.

[0035] A function partition can be the smallest unit of storage on a storage medium with a clearly defined function and fixed boundaries. Unlike a single system partition, a function partition breaks down the complete operating system into multiple independent functional modules, each corresponding to a function partition. Each function partition can be dedicated to storing a specific type of data, such as boot code, kernel image, root file system, configuration parameters, or user data, allowing upgrade operations to be precise down to a single functional module, rather than the entire operating system. For example, it could contain a function partition named "kernel" with a fixed size of 3200KB, which only stores the operating system's kernel image; and another function partition named "rootfs" with a fixed size of 23616KB, dedicated to storing the root file system.

[0036] A recovery system partition group can be another set of physical or logical storage areas partitioned off from the storage medium of an embedded device. It is used to store a recovery system that is completely symmetrical to the default system as a backup. The structure and size of the recovery system partition group can be the same as the default system partition group, and it also consists of multiple functional partitions (such as configuration partitions, bootloader partitions, kernel partitions, etc.). The recovery system is the operating system selected as an emergency backup when the default system fails. The physical carrier of the recovery system is all the functional partitions in the recovery system partition group.

[0037] A status management partition refers to a physically independent partition specifically allocated on the storage medium. It exists independently, not belonging to the default system partition group or the recovery system partition group. The status management partition stores metadata about system status and upgrade progress. It can include a status mapping table, which maintains an independent status record for each functional partition in both the default and recovery system partition groups. The status management partition acts as a database for system status, recording the current health status and upgrade progress of each functional partition. Each status record can include a partition identifier (such as partition number or name), a partition-level status value (such as "Upgrading", "Upgrading Complete", "Abnormal", etc.), a data checksum (such as a hash value), and a status update timestamp. This table can be read by the controller to determine the system status and can be dynamically written to and updated by the controller during the upgrade process. A partition status can be a value maintained for each functional partition in the status mapping table, identifying different stages of the functional partition's lifecycle in the upgrade task. For example, the partition status may include, but is not limited to, the following: "Upgrading in progress" indicates that the controller has started data erasure and write operations on the functional partition, but the operation has not yet been completed or has not passed verification; "Upgrade complete" indicates that the controller has completed all upgrade steps for the functional partition and the data verification has passed; "Abnormal" indicates that an error occurred when the controller performed upgrade steps on the functional partition (such as verification failure).

[0038] A system upgrade task is a set of instructions generated by the controller when an embedded device needs a firmware update. It represents a complete operation from identifying the upgrade requirement to the completion of all partition upgrades. The controller can generate or determine a system upgrade task based on a received new firmware image package, user commands, or network trigger signals. The operation sequence is a specific upgrade plan and execution order for each functional partition (such as the bootloader partition, kernel partition, and root file system partition) within the default system partition group and recovery system partition group in the storage medium, generated based on the system upgrade task. The operation sequence can include an ordered list or array containing identifiers (such as partition numbers or names) of the functional partitions to be upgraded, the address ranges (start and end addresses) of these functional partitions on the physical storage medium, and possible dependencies. The controller can execute the upgrade actions in the order of the operation sequence.

[0039] Optionally, the embedded device's storage medium includes a default system partition group, a recovery system partition group, and an independent state management partition. The default system partition group is the primary environment for the embedded device to boot and run under normal conditions. The default system partition group can be further subdivided into multiple functional partitions, each carrying different parts of the default system, such as the bootloader, operating system kernel, and root file system. The recovery system partition group is a complete mirror of the default system partition group in structure and content, serving as a security backup. The state management partition is independent of the default system partition group and the recovery system partition group, and is used to store the state mapping table. The controller can perform read and write operations on the state management partition without affecting the default system partition group and the recovery system partition group. The state mapping table in the state management partition can maintain a record for each managed functional partition. Each record can contain the functional partition's identifier, current partition status (such as "normal," "upgrading," "upgrading complete," "abnormal," etc.), data checksum, and other information. The controller can accurately understand the health status and upgrade progress of each functional partition by reading this state mapping table.

[0040] In some embodiments, the embedded device may employ a Flash storage medium of a specific capacity, which is divided into the following key regions:

[0041] Default system partition group: contains multiple consecutive functional partitions, such as configuration partition, bootloader partition, kernel partition, root file system partition, etc.

[0042] Restore system partition group: It is completely symmetrical to the default system partition group in terms of structure and content, and includes the corresponding backup partition;

[0043] Status Management Partition: Two independent status partitions are set up to record the upgrade status mapping tables of the default system partition group and the recovery system partition group, respectively;

[0044] Data partition: Used to store user data.

[0045] The system includes a partitioned state management mechanism with multiple state values. This mechanism records not only the final state of the system (e.g., normal, abnormal) but also intermediate states during the upgrade process (e.g., during upgrade), providing a precise basis for resuming upgrades from breakpoints. This physically separated design ensures the independence of system image data and state management data, providing a hardware foundation for atomic upgrades.

[0046] The controller can determine system upgrade tasks in various ways. For example, it can receive management commands from the network, parse upgrade packages from local storage media, or respond to external trigger signals to obtain the system upgrade task for the embedded device. Based on the system upgrade task, the target scope of this upgrade (whether to update only the default system or both systems simultaneously), the target firmware version, and other information can be specified. The controller can dynamically generate an operation sequence based on the system upgrade task, combined with the physical layout information of the default system partition group and the recovery system partition group (i.e., the starting address and size of all functional partitions) and system dependencies. The operation sequence can include an array or linked list, where each element corresponds to an atomic operation unit. Each atomic operation unit can explicitly specify the functional partition to be operated on (e.g., "kernel partition"), the operation type (e.g., "erase and verify"), the data source address, and the expected final state. For example, the controller determines the system upgrade task as follows: upgrade the kernel and root file system of both the default system and the recovery system to the new version. Based on the system upgrade task and partition layout, the controller can generate the following operation sequence: Step 1, erase and verify the default system kernel partition; Step 2, erase and verify the default system root file system partition; Step 3, erase and verify the restored system kernel partition; Step 4, erase and verify the restored system root file system partition.

[0047] Step 204: Determine the target partition based on the operation sequence, upgrade the target partition according to the operation sequence, and dynamically update the partition status of the target partition in the status mapping table during the upgrade process.

[0048] The target partition is the specific functional partition that needs to be upgraded in the current operation sequence. The target partition can change dynamically as the operation sequence progresses. At different upgrade stages, the target partition can be any functional partition from the default system partition group or the recovery system partition group. The target partition corresponds to a contiguous physical address space in the storage medium, which is reserved for specific system functional modules. For example, on the storage medium, a target partition may be divided into fixed-size blocks, such as a 256KB bootloader partition, a 3200KB kernel partition, or a 23616KB root filesystem partition. Each target partition has its own independent start and end addresses and can be uniquely indexed in the state map table using a partition identifier.

[0049] For example, the operation sequence can explicitly list the identifier of each functional partition that needs to be upgraded, its system (default or recovery), and the priority order of the operations. The controller can retrieve the partition identifiers one by one according to the order of the operation sequence and determine them as the target partition to be processed. The controller can perform upgrade operations on the target partition. For example, the controller can erase the original data area of ​​the target partition, then write the new version data parsed from the upgrade package into the area, and perform integrity verification on the written data after the writing is completed (e.g., calculate the hash value and compare it with the expected value). During the upgrade process of the target partition, the controller can also dynamically update the partition status of the corresponding target partition in the status mapping table, thereby ensuring that the partition status is strictly synchronized with the actual physical data of the target partition, making the upgrade process transparent and traceable. In some embodiments, the upgrade operation performed on the target partition can be a single atomic operation unit containing an internal process: the controller can first update the partition status of the target partition in the status map to "upgrading"; then, the controller can erase and write the physical storage area of ​​the target partition with new data; next, the controller can verify the written data; finally, if the verification passes, the controller can update the partition status of the target partition in the status map from "upgrading" to "upgrading complete".

[0050] In some embodiments, the system upgrade task of an embedded device can be divided into multiple logically independent partition operation sequences according to functional modules. The upgrade of each functional partition is defined as an atomic operation unit, which must be executed strictly in the following four-step sequence, and its execution process is indivisible for the same upgrade task:

[0051] (1) Status preset: Before the data writing begins, the partition status of the target partition in the status mapping table is first updated to "Upgrading";

[0052] (2) Data erasure: Perform physical erasure of the target partition and write new data;

[0053] (3) Data verification: Verify the integrity of the partitioned data after it has been written;

[0054] (4) Status confirmation: After the data verification is passed, the partition status of the target partition is updated to "upgrade completed".

[0055] The controller must wait for the atomic operation unit of the current target partition to be completely successful (the partition status changes to "upgrade complete") before it is allowed to start the atomic operation of the next functional partition. This constraint forms the "progressive" serial advancement of the upgrade task.

[0056] Step 206: If the target partition upgrade is completed, determine the next functional partition based on the operation sequence, and designate the next functional partition as the target partition. Then, return to execute the steps of upgrading the target partition according to the operation sequence until the dual-system upgrade process for the embedded device is completed.

[0057] The next functional partition is the next functional partition to be upgraded after the current target partition has been successfully upgraded, following a pre-defined logical order. The operation sequence contains a list of partitions to be upgraded and their processing order. After the controller completes the upgrade of the current target partition, it can query this operation sequence to obtain information about the next partition after the current partition; this information is the "next functional partition." This partition information can be a logical partition number (such as a partition identifier), a physical address range (such as a start and end address), or a partition name, ensuring that the controller can accurately locate the partition's position in the storage medium.

[0058] Optionally, the controller can read the current target partition's partition status from the status mapping table of the status management partition to confirm that it has been successfully updated to "upgrade complete," i.e., confirm whether the current target partition has been upgraded. After confirming that the current target partition has been upgraded, the controller can determine the next functional partition based on the operation sequence. For example, the controller can determine the position of the upgraded target partition in the operation sequence by traversing or moving pointers, and determine the next functional partition of the target partition. The controller can set the next functional partition as the new target partition and perform the complete upgrade process on the new target partition. The controller can repeat the series of actions of "determine target partition, upgrade, confirm completion, find next" until the dual-system upgrade process for the embedded device is completed. For example, when the controller checks the operation sequence and finds that the currently upgraded target partition is the last element in the operation sequence, it can no longer obtain a valid next functional partition. At this time, the entire system upgrade task (such as the update of the default system partition group) is completed. In order to ensure the complete upgrade of the entire dual system, the controller needs to continue to perform the same operation sequence on another group of system partitions (such as the recovery system partition group).

[0059] In some embodiments, two upgrade modes are supported to adapt to different application scenarios:

[0060] Bootloader mode: Applicable to contiguous address upgrade packages, it performs erase and write operations on partitions according to a predefined start address to end address;

[0061] Root file system mode: Suitable for upgrade packages organized by block device nodes, with erase and write operations performed on partitions according to the actual file size.

[0062] In some embodiments, when determining a system upgrade task for an embedded device, the controller may first receive and parse the upgrade package. If the header information or metadata of the upgrade package indicates that it is a contiguous address upgrade package, the controller selects the bootloader mode; if the upgrade package indicates that it is an upgrade package organized by block device nodes, the controller selects the root file system mode. In bootloader mode, the controller can define a contiguous range of physical addresses (e.g., from 0x000000 to 0x100000) as an upgrade target and treat all functional partitions within this range (such as uboot, kernel, rootfs, etc.) as a single target partition for erasure and writing in one go. In root file system mode, each functional partition (e.g., the / dev / mtdblock2 kernel partition and the / dev / mtdblock3 root file system partition) becomes an independent target partition, and erasure and writing are performed separately for each partition, with the operation sequence strictly arranged according to the order of the functional partitions.

[0063] In the aforementioned dual-system atomic upgrade method for embedded devices, based on the embedded device's storage medium including a default system partition group, a recovery system partition group, and an independent state management partition, an operation sequence for each functional partition is generated according to the system upgrade task. This refines the upgrade operation to the level of a single functional partition. During the upgrade, each partition is upgraded sequentially, and the corresponding partition status in the state mapping table is dynamically updated during the upgrade process of each partition. This allows for real-time and accurate monitoring of the upgrade progress and status of each partition, achieving process state awareness. Only after the current target partition is upgraded is the next functional partition determined and upgraded according to the operation sequence. By advancing the control logic step by step, the orderliness and controllability of the entire upgrade process are ensured, thereby transforming the dual-system upgrade process of the embedded device into a refined, controllable, and observable atomic process, achieving refined management and control of the upgrade process.

[0064] In an exemplary embodiment, the target partition is upgraded according to the operation sequence, and during the upgrade process, the partition status of the target partition in the status mapping table is dynamically updated, including: updating the partition status of the target partition in the status mapping table to "Upgrading in progress", and updating the data in the target partition according to the operation sequence; if the updated data in the target partition passes the data verification, the partition status of the target partition in the status mapping table is updated to "Upgrade complete".

[0065] The status mapping table records the upgrade progress and results of each functional partition in the dual-system of the embedded device. Stored in the status management partition, it is physically isolated from the default system partition group and the recovery system partition group to ensure that status data is not accidentally lost or corrupted during the upgrade process. The status mapping table can be represented as a table, array, or collection of key-value pairs. Each entry in the status mapping table corresponds to a managed functional partition, and this entry must at least contain a partition identifier (such as partition name or starting address) and the current partition status. The partition status is the status value contained in each entry in the status mapping table, used to accurately describe the stage the corresponding functional partition is in during the upgrade process. In some embodiments, the status mapping table may also include fields such as data verification values ​​(such as hash checksums) and status update timestamps for more accurate integrity and timeliness verification.

[0066] For example, the controller first determines the identifier of the target partition (e.g., partition name or offset address) based on the operation sequence, and then accesses the state mapping table stored in the state management partition. The controller can perform an atomic write operation on this state mapping table, modifying the partition status corresponding to the target partition from the current value (e.g., the previous state before "Not Started" or "Upgrade Complete") to "Upgrading". This write operation should be performed on the smallest erasable unit of the storage medium to ensure that even if this write process is interrupted, the status record is either completely updated to "Upgrading" or remains in its original state without data corruption. After completing the state presetting, the controller then performs data updates according to the operation sequence specified for the target partition by the system upgrade task. The specific method of data updates depends on the upgrade mode. For example, in bootloader mode, the controller erases the target partition entirely based on consecutive start and end addresses and writes data from the upgrade package; or in root file system mode, the controller erases and writes in units of block device nodes based on the actual size of the file. All data update operations are performed under the protection of the "Upgrading" state, and any interruption will keep the state in "Upgrading", thus ensuring accurate identification during recovery. After completing the data erasure and write operation, the controller can perform integrity verification on the target partition's data. The controller can read the newly written data from the target partition or directly calculate the digital digest of the entire partition using a hardware module, such as a SHA256 (Secure Hash Algorithm 256-bit) hash value. The controller can obtain or pre-store the expected checksum for the partition from the upgrade package; if both match, the data verification is considered successful. The controller can update the target partition's status from "Upgrading" to "Upgrading Complete" in the status map table. This write operation also needs to be executed atomically to ensure that no ambiguous state is left even if a power outage occurs during the status update process. After the status update is complete, the upgrade process for the target partition officially ends, and the controller can check the conditions of the next functional partition in the operation sequence and decide whether to initiate its upgrade.

[0067] In some embodiments, a state management partition, independent of the system image partition, is established on the storage medium to store a state mapping table. The state mapping table maintains a partition state for each managed functional partition. Updating the state mapping table is an indispensable step in the execution flow of atomic operation units. The physical state of the data (whether it has been written, whether it is correct) is strictly bound to the partition state (upgrading in progress / upgrading complete) in the state mapping table and updated synchronously. This allows the precise health status and upgrade progress of each functional partition to be obtained at any time by reading the state mapping table, thus achieving "white-box" upgrade process.

[0068] In this embodiment, the upgrade process of the target partition is decomposed into three stages: first, marking the upgrade in progress; then, updating the data; and finally, marking the upgrade as complete after verification. A partition-level atomic operation unit is constructed. By decoupling the execution and verification of the upgrade transaction and achieving traceability of each step through persistent partition status records, the controllability and observability of the upgrade process are realized.

[0069] In one exemplary embodiment, such as Figure 3 As shown, the dual-system atomic upgrade method for embedded devices also includes interrupt-driven upgrade processing, specifically steps 302 to 304. Wherein:

[0070] Step 302: When the dual-system upgrade process of the embedded device is interrupted, determine the functional partition that needs to be upgraded again based on the state mapping table.

[0071] Among them, the functional partitions requiring follow-up upgrade processing are those whose upgrade operations were not successfully and completely completed due to unexpected interruptions during the upgrade process. When the entire upgrade process is unexpectedly stopped due to power failure, system reset, or communication failure, some functional partitions may be in the "upgrading in progress" state (i.e., atomic operations have not been completed), some may be in the "upgrade completed" state, and some may not have even started (the state is "not started" or initial value). In this case, functional partitions requiring follow-up upgrade processing can precisely exclude functional partitions that have been confirmed to have completed the upgrade, and include the parts of the remaining functional partitions that need to be processed. In some embodiments, functional partitions requiring follow-up upgrade processing can include various functional partitions with partition states of "upgrading in progress," "verification failed," "not started," and "error."

[0072] For example, if an embedded device is powered on or reset under abnormal conditions, after the device starts up, the controller can check for any incomplete upgrade transactions. For instance, the controller can read the status mapping table in the independent status management partition. If it finds a partition with a status of "Upgrading" or "Error" and an in-progress upgrade transaction identifier, it can be determined that the previous upgrade process was abnormally interrupted. The controller can traverse all functional partition records participating in this upgrade task in the status mapping table, checking the status of each functional partition one by one. The controller makes judgments according to preset rules: if a functional partition's status is "Upgrade Completed," it indicates that the functional partition was successfully processed in the previous upgrade and requires no further action; if a functional partition's status is "Not Started," "Upgrading," "Verification Failed," or "Error," it indicates that the functional partition needs to be included in the continued upgrade process.

[0073] Step 304: Identify the function partition that needs to be upgraded as the target partition, and return to execute the steps of upgrading the target partition according to the operation sequence until the dual-system upgrade process for the embedded device is completed.

[0074] Optionally, the controller can reorganize the functional partitions requiring upgrade processing into a new, pending upgrade sequence according to their order in the original operation sequence. The controller can mark the first functional partition in this upgrade sequence whose status is not "upgrade complete" as a breakpoint. The controller can assign the first functional partition (breakpoint partition) of the upgrade sequence to the target partition variable and call the atomic operation unit to execute the process, upgrading the target partition. That is, the controller will re-execute the following four complete steps on this target partition: setting the status to "upgrading in progress," data erasure, data verification, and confirming the status as "upgrade complete" after verification. This process is consistent with the operation on a functional partition in the normal upgrade process. When the atomic operation unit of the target partition is successfully executed and its partition status becomes "upgrade complete," the controller can check whether there is another functional partition in the upgrade sequence that needs to be processed. If there is, the controller will determine the next functional partition as the new target partition and execute the atomic operation unit again. The controller will iterate repeatedly, traversing the entire upgrade sequence, until the status of all functional partitions in the upgrade sequence becomes "upgrade complete," completing the dual-system upgrade processing for the embedded device.

[0075] In some embodiments, when the upgrade process is unexpectedly interrupted, recovery logic is executed according to the status mapping table upon restart: the function partition with the partition status of "upgrade complete" is identified and skipped, and the complete atomic operation unit is re-executed for the function partition with the partition status of "upgrading" or "error", so as to achieve precise resume upgrade from the breakpoint.

[0076] In this embodiment, by introducing a breakpoint continuation mechanism based on a state mapping table, the functional partitions that need to be continued can be accurately identified when the upgrade is interrupted, instead of rolling back the entire upgrade task. This avoids repeatedly erasing and writing to functional partitions that have already been successfully upgraded, reduces unnecessary storage wear, and improves the robustness and availability of the system's atomic upgrade.

[0077] In an exemplary embodiment, the dual-system atomic upgrade method for an embedded device further includes: when the embedded device starts up, determining a target boot system from the default system and the recovery system based on the bootloader and the state mapping table, and starting the device through the target boot system; when the target boot system is the recovery system and the default system is abnormal, repairing the default system.

[0078] The bootloader is the first program executed after an embedded device powers on or resets. Stored in a dedicated partition of the storage medium (e.g., uboot, loader), the bootloader is responsible for initializing the hardware, establishing the basic operating environment, and ultimately loading and starting the operating system kernel. The controller can detect the validity of the bootloader image, which can be obtained through checksums, signature verification, etc. Bootloader validity is a key signal distinguishing whether the default system can boot normally. For example, if the bootloader image itself is corrupted, even if the data in other partitions of the default system is intact, the device cannot boot directly from the default system. The target boot system is the operating system that the controller ultimately selects and actually boots during the embedded device's boot process based on decision logic. The embedded device's storage medium contains two system partition groups: the default system and the recovery system, which are symmetrical backups of each other. The target boot system can be either the default system or the recovery system, determined by the controller based on the bootloader validity and the contents of the state mapping table.

[0079] For example, after the embedded device powers on, the controller executes the bootloader. The controller can detect the validity of the bootloader itself. For instance, it reads the bootloader image from a fixed address and calculates a checksum, comparing it with a pre-stored value to confirm that the bootloader itself is not corrupted, because if the bootloader is corrupted, any system that depends on it cannot be loaded normally. The controller can read the state mapping tables of the default system and the recovery system from the state management partition to obtain the current status values ​​of the partition states of critical functional partitions (such as the kernel partition and the root file system partition) in the two operating systems. The read operation can be completed by directly accessing the physical address. The state partition uses an independent storage unit, which does not affect the image integrity check performed simultaneously. The controller can make a comprehensive decision based on two pieces of data: if the bootloader is valid and the partition states of the critical functional partitions of the default system are all normal (such as "upgrade complete" or "data valid"), the controller can set the boot parameters to point to the kernel address of the default system and jump to that kernel entry point to complete the boot of the default system. If the bootloader is effective, but the default system's status map shows that critical function partitions are abnormal (e.g., "Upgrading" or "Error"), while the recovery system's status map shows that its critical function partitions are all in normal condition, the controller can set the boot parameters to point to the recovery system's kernel address and boot the recovery system. If neither system can meet the boot conditions, the controller can enter emergency recovery mode (e.g., waiting for external flashing or directly entering the built-in mini maintenance system).

[0080] After successfully booting from the recovery system, the controller is already running in the recovery system environment. The controller can read the status map table to confirm why the default system is abnormal, such as the kernel partition being in "upgrade" or the root file system verification failing. Specific exception information is encoded in the status field of the status map table. The controller can automatically trigger the repair process. The repair method can employ data copying between the two systems. For example, valid data from the corresponding functional partition in the recovery system can be directly copied to the abnormal partition in the default system. During the copying process, consistency can be ensured by following the execution order of atomic operation units (status presetting, erasing / writing, verification, status confirmation). The controller can update the target partition's status to "upgrade" before repair and update it to "upgrade complete" after repair and verification, thereby restoring the default system to a healthy state.

[0081] In some embodiments, when an embedded device boots, the bootloader simultaneously checks the bootloader's validity and reads the partition status values ​​from the status map table through an enhanced inspection interface, making a comprehensive decision: if the bootloader is valid and the default system status is normal, then the corresponding boot parameters are set to boot from the default system; if the default system bootloader is invalid or in an abnormal state, but the recovery system status is normal, then the corresponding boot parameters are set to boot from the recovery system. This intelligent decision-making based on multi-dimensional status significantly improves the reliability of embedded device booting.

[0082] In this embodiment, dual judgment based on the bootloader and state mapping table is performed at startup, which can avoid long-term hangs or repeated restarts caused by attempting to start from the default system when critical data is corrupted, thus improving the startup success rate and availability. After starting from the recovery system, abnormal partitions of the default system are automatically detected and repaired, shortening the window period of single-point backup risk and improving the overall system reliability in embedded devices.

[0083] In an exemplary embodiment, the dual-system atomic upgrade method for an embedded device further includes: when it is determined that the first system is normal and the second system is abnormal in the default system and recovery system, performing data copying on the second system through the first system to repair the second system.

[0084] Here, the first system and the second system refer to two operating systems with different health states in the default system and the recovery system, respectively. For example, after reading the status mapping table, the controller finds that all functional partitions of the default system are in a "normal" state, while the root file system partition of the recovery system is in a "data error" state. In this case, the controller can identify the default system as the first system (normal) and the recovery system as the second system (abnormal).

[0085] Optionally, the controller can periodically or be triggered by specific events (such as system startup completion, upgrade transaction completion, timer expiration, etc.) read two state mapping tables from the state management partition, which respectively record the states of the default system partition group and the recovery system partition group. These state mapping tables contain the partition status of each functional partition (e.g., "normal", "abnormal", "upgrading", etc.). The controller can combine the partition status of all critical functional partitions in each system to determine the overall health of each system. If the controller determines that one of the default system and the recovery system is completely normal and the other is abnormal, the controller can mark the normal one as the first system and the abnormal one as the second system. For each functional partition in the second system that needs repair (e.g., partitions with an abnormal status, or all partitions copied for safety), the controller can read data from the corresponding functional partition in the first system and write this data directly to the corresponding functional partition in the second system. During writing, the controller can erase and write sequentially according to the functional partition address order, or it can use atomic operation units (state preset, erase / write, verification, state confirmation) to ensure consistency. After the data replication is complete, the corresponding functional partition of the second system obtains the same data content as the first system. Therefore, the original anomaly is eliminated, and the second system is repaired. At this time, the functional partition data of the second system is consistent with that of the first system, and the partition status in the status mapping table can be updated to "normal" by the controller, thus restoring the dual systems to a completely symmetrical and healthy state.

[0086] In some embodiments, after the embedded device is running normally, the dual-system status can be continuously monitored through a symmetric detection mechanism. When an anomaly is detected in one side of the system, a data copying operation from the normal system to the abnormal system is automatically triggered, thereby achieving automated maintenance of the dual systems.

[0087] In this embodiment, when it is determined that one side of the dual system is normal and the other side is abnormal, the normal system is used to copy and repair the abnormal system, thereby realizing automated fault handling during equipment operation without manual intervention or external intervention, which greatly reduces operation and maintenance costs and response time.

[0088] In an exemplary embodiment, the dual-system atomic upgrade method for an embedded device further includes: when the default system upgrade is completed, identifying, from the various functional partitions of the recovery system, partitions that differ from the corresponding functional partitions of the default system and need to be synchronized; and incrementally synchronizing and updating the partitions to be synchronized using the functional partitions in the default system that correspond to the partitions to be synchronized, until the upgrade process for the recovery system is completed.

[0089] In this context, "partitions to be synchronized" refers to those functional partitions in the recovery system whose stored data differs from the corresponding functional partitions in the default system after a dual-system upgrade. For example, the default system's kernel partition (mtdblock5_1) only underwent a firmware update, upgrading its kernel image from version 5.10 to 5.15. In the dual-system partition layout, the recovery system also has a corresponding kernel partition (mtdblock5_2). After the default system upgrade, the controller reads the data from both partitions, calculates hash values, and compares them. Finding a discrepancy, the recovery system's kernel partition (mtdblock5_2) is identified as the partition to be synchronized. Incremental synchronization updates, after the default system upgrade, do not involve completely erasing and rewriting the entire recovery system image. Instead, the controller identifies only those recovery system partitions with inconsistent data with the default system and performs atomic data update operations on these specific partitions to be synchronized, thus keeping the recovery system synchronized with the default system.

[0090] Optionally, after the default system upgrade is complete and running stably, or during maintenance tasks after the next system startup, the controller can obtain the partition layout information of the dual systems, clarify the correspondence between each functional partition in the default system partition group and the recovery system partition group, and read the data of each pair of corresponding functional partitions one by one. The controller performs a hash calculation on each pair of data to generate two hash values, which can then be compared. If the hash value of the default system kernel partition (e.g., located in mtdblock5) is the same as the hash value of the recovery system kernel partition (e.g., located in mtdblock15), the controller can determine that there is no difference between the two functional partitions and synchronization is unnecessary. Conversely, if the hash values ​​are different, the controller can determine that there is a difference between the recovery system kernel partition and the default system kernel partition. The controller can then mark the recovery system kernel partition as a partition to be synchronized and record it in a list of tasks to be synchronized. For each partition to be synchronized in the task list, the controller can initiate an atomic update process. First, the controller can pre-set the partition status of the target partition in the recovery system to "Upgrading". Then, the controller can perform an erase operation on the target physical partition in the recovery system, and subsequently read data from the corresponding functional partition in the default system, writing it completely into this erased recovery system partition. After the data is written, the controller can immediately perform integrity verification on the data in the partition, such as recalculating the hash value and comparing it with the source data hash value. If the verification passes, the controller can update the partition status in the status management partition to "Upgrade Complete". If the verification fails, the controller can update the partition status to "Error" or "Abnormal" and can choose to retry or mark the failure. The controller can process one partition in the list before moving on to the next, until all partitions in the task list have successfully undergone the above atomic operation unit, and their status is marked as "Upgrade Complete". At this point, the recovery system is completely consistent with the upgraded default system, and the controller can determine that the entire incremental synchronization upgrade process for the recovery system is complete. After the default system upgrade is completed, atomic operation units are performed only on functional partitions with inconsistent data through hash comparison to achieve incremental synchronization and significantly improve synchronization efficiency.

[0091] In this embodiment, only functional partitions with differences are synchronized, avoiding a large number of unnecessary erase and write operations in traditional full copying, thereby significantly shortening the system maintenance window and improving the continuity of device services.

[0092] This application also provides an application scenario in which the above-described dual-system atomic upgrade method for embedded devices is applied. Specifically, the application of the dual-system atomic upgrade method for embedded devices in this scenario is as follows:

[0093] The core challenge of firmware upgrades for embedded devices is ensuring that the device does not become "bricked" (i.e., unable to boot) due to upgrade failure, while applying new features or fixing vulnerabilities. Existing high-reliability upgrade solutions mainly revolve around dual-system backup architectures, but they generally suffer from the following technical bottlenecks:

[0094] This approach involves creating two completely independent system partitions on the storage medium and using a simple pointer or environment variable to indicate the system that should be booted. When an upgrade is needed, the tool writes the entire new system image to the inactive system partition, and switches the boot pointer after successful verification. The drawback of this approach is that the upgrade process is "atomic," meaning the entire image write operation either succeeds completely or fails completely. If an unexpected event such as a power outage occurs during the write process, the target partition will be in a state of data inconsistency, rendering the entire upgrade attempt invalid and requiring a rollback to the old system version to start over. This not only leads to a high concentration of risk within the upgrade window but also fails to retain any partially written valid data.

[0095] Further improvements include rapid loading of the backup system and data integrity verification (such as hash verification) after the upgrade. While this enhances post-upgrade reliability, it doesn't alter the coarse-grained nature of the upgrade process itself. The system still cannot perceive or control the intermediate states of the upgrade. When the upgrade is unexpectedly interrupted, the system can only detect that "the entire image is incorrect" through verification, but cannot pinpoint "which part is incorrect," thus necessitating a complete rollback recovery strategy, which is inefficient.

[0096] Furthermore, existing dual-system solutions typically employ full copying to maintain synchronization between the two systems. This means that after the primary system (default system) is upgraded, the entire image needs to be copied to the backup partition. This approach is inefficient, especially in common scenarios where only some system components (such as the kernel) are updated, resulting in unnecessary storage writes and time consumption. Moreover, traditional solutions store upgrade files contiguously according to partition size, lacking fine-grained state management and dual-system backup mechanisms, making it impossible to achieve controllable and recoverable upgrade processes.

[0097] In summary, the common shortcomings of traditional technologies are: coarse-grained upgrade operations, unknown process states, high failure recovery costs, and low system synchronization efficiency. There is an urgent need in this field for a dual-system management solution that can finely control the upgrade process, achieving interruptibility, recoverability, observability, and efficient synchronization. Based on this, this application aims to overcome the problems of coarse-grained upgrade processes, unknown states, and low recovery efficiency in traditional dual-system upgrade solutions. Through a partitioned atomized progressive upgrade and state-linked control mechanism, the system upgrade task is decoupled into a series of fine-grained, state-traceable atomic operations. This achieves a safe and controllable upgrade process, precise continuation after interruption, and significantly improves the synchronization efficiency between the two systems. It is suitable for embedded devices such as network video recorders and industrial gateways with extremely high system reliability requirements.

[0098] The dual-system atomic upgrade method for embedded devices provided in this application may include:

[0099] 1. Storage partition design and implementation

[0100] The storage medium is partitioned as follows: It is divided into multiple logical partitions, including a default system partition group, a recovery system partition group, a state management partition, and a data partition. The default system partition group contains multiple contiguous functional partitions, such as configuration partitions, bootloader partitions, kernel partitions, and root file system partitions. The recovery system partition group is structurally and content-wise symmetrical to the default system partition group, containing corresponding backup partitions. The state management partition includes two independent state partitions, which respectively record the upgrade state mapping tables for the default system partition group and the recovery system partition group. The data partition is used to store user data. The state partition is physically separated from the system image partition to ensure the security and independence of state data.

[0101] like Figure 4 The diagram shows a partition layout of a 64MB Flash dual-system storage medium in some embodiments. The files in the dual-system flash programming files are stored contiguously according to their functional partition size. During the upgrade process, the entire upgrade package is written contiguously according to its address. The programming files are shown in Table 1 below.

[0102] Table 1

[0103]

[0104] Here, `mtdblock` represents the MTD (Memory Technology Device) block device number. In the Linux kernel, Flash memory is abstracted as an MTD device, and the system registers a corresponding block device node (e.g., ` / dev / mtdblock0`) for each partition, allowing read and write operations like a regular disk. `mtdblock0` indicates that this is the first functional partition of the Flash memory. For example, `mtdblock0:loader.bin64KB` means that a 64KB MTD partition has been created at the beginning of the Flash storage medium (offset address 0x0). This functional partition is represented as the block device ` / dev / mtdblock0` and stores the raw binary data of the bootloader (`loader.bin`). The functional partitions with underscores are those that participate in the update process during a dual-system upgrade; that is, except for the `mtdblock0:Loader.bin` and `mtdblock17:database` functional partitions, all other functional partitions can participate in the update process during a dual-system upgrade.

[0105] 2. Implementation of Status Management Mechanism

[0106] Define a state management mechanism, including the following state values:

[0107] System-level status: Default system normal, Default system abnormal, System restored to normal, System restored to abnormal;

[0108] Partition-level status: Partition upgrade in progress, Partition upgrade complete, Partition data valid, Partition data error.

[0109] The state mapping table maintains a state record for each functional partition, including partition identifier, data checksum, partition status, and state update timestamp. The state update operation ensures that it is an atomic operation on the smallest erasable unit of the storage medium.

[0110] 3. Implementation of atomic operation units

[0111] Atomic operation units are executed according to the following logic:

[0112] Read the partition status of the target partition from the status map table; update the partition status to "Upgrading" and immediately write it back to the status map table; erase the target system image partition and write new image data; calculate the checksum of the written data and compare it; if the checksum passes, update the partition status to "Upgrade Complete", record the checksum and timestamp, and write it back to the status map table; if the checksum fails, update the partition status to "Abnormal" and write it back to the status map table.

[0113] 4. Implementation of progressive controller upgrade

[0114] The controller organizes the operation sequence according to system dependencies, for example: configuration partition → firmware partition → bootloader partition → kernel partition → root file system partition.

[0115] Controller execution logic:

[0116] Generate a new upgrade transaction identifier; sequentially traverse each functional partition in the operation sequence as a target partition; for each target partition (except the first partition), check if the status of the previous partition is "upgrade complete". Only when the status of the previous partition is "upgrade complete" is atomic operation of the current target partition allowed to begin; execute the atomic operation unit of the current target partition; if the atomic operation fails, decide whether to continue the upgrade of subsequent partitions based on the importance of the functional partition; after all functional partitions have been upgraded, complete the upgrade transaction.

[0117] 5. Implementation of intelligent start-up decision

[0118] The following logic is implemented in the bootloader: check the validity of the bootloader image; read the status values ​​of the partitions in the status map table; and check the partition status of the default system critical function partitions.

[0119] Boot decision: If the bootloader is valid and the default system critical function partition is in normal condition, boot from the default system; if the bootloader is invalid or the default system critical function partition is abnormal, but the recovery system check passes, boot from the recovery system; if neither system meets the conditions, enter emergency recovery mode.

[0120] 6. Implementation of breakpoint recovery

[0121] After the embedded device restarts, the following recovery logic is executed:

[0122] Read the status mapping table; check if there are any ongoing upgrade transactions; if there are no ongoing upgrade transactions, proceed to the normal startup process; if there are ongoing upgrade transactions, find the functional partitions with a status of "Upgrading" or "Error" as breakpoints; if no functional partitions with a status of "Upgrading" or "Error" are found, but functional partitions with a status of "Not Started" exist, then the first "Not Started" partition is considered a breakpoint; if all partitions are in a status of "Upgrade Completed" or "Valid", clear the upgrade transaction flags and proceed to normal startup; if there is a serious inconsistency in the status mapping table, enter emergency recovery mode; starting from the breakpoint partition, locate all functional partitions with a status of "Not Started" to form a new upgrade sequence; the controller executes the new upgrade sequence, skipping functional partitions with a status of "Upgrade Completed", and only performing atomic operations on the breakpoint and subsequent functional partitions.

[0123] 7. Implementation of dual-system symmetrical maintenance

[0124] After the operating system boots up, it executes a symmetric maintenance process: simultaneously reading the state mapping tables of the default system and the recovery system; and determining the dual-system status.

[0125] If both are normal, continue operating normally.

[0126] If the recovery system fails while the default system is normal, mark the data copy operation from the default system to the recovery system.

[0127] If the default system malfunctions but the system is restored to normal, mark the data copy operation from the restored system to the default system.

[0128] If both are abnormal, analyze the system startup parameters to determine the currently running system and mark the data copy operation from the current system to the damaged system.

[0129] Perform maintenance operations: Prompt the user that the system is under maintenance; update the status marker to "under maintenance"; perform a data copy operation; update the status marker to "normal".

[0130] Restart the system main process after maintenance is complete.

[0131] 8. Implementation of incremental synchronization

[0132] After the default system upgrade is completed, the incremental synchronization process is initiated: For each pair of corresponding functional partitions of the default system and the backup system, the hash values ​​of the current data of the two functional partitions are calculated and compared; if the hash values ​​are inconsistent, the status of the partition is marked as "upgrading" in the status table of the backup system, and an atomic operation unit is executed on the functional partition on the recovery system, with the data source being the current data of the corresponding functional partition of the default system; the recovery system maintains an independent status mapping table to record the status of the synchronization process.

[0133] In some embodiments, such as Figure 5 The diagram shows the workflow for intelligent dual-system boot decision-making in Loader mode. Specifically, in Loader mode, embedded devices implement intelligent switching between the default system and the recovery system through enhanced boot checks. The core of this process is the state awareness capability of the bl_chk_uboot() interface, which automatically selects either the default system or the recovery system for booting, ensuring device reliability. This includes:

[0134] 1. Startup trigger: Embedded device powers on.

[0135] When an embedded device is powered on, the physical boot process begins. After hardware initialization is complete, the bootloader takes over control.

[0136] 2. Loader initialization and core checks: bl_chk_uboot() interface

[0137] After the Loader starts, it calls the enhanced bl_chk_uboot() interface, which contains two layers of core logic:

[0138] uBoot self-validation check: Verifies the integrity of the uBoot image (such as CRC check, signature verification, etc.) to ensure that the bootloader is not damaged.

[0139] Status partition linkage check: Read the hierarchical status (normal / abnormal / upgrading) of status (default system status partition) and status.restore (restored system status partition) to indirectly determine whether the critical partitions (kernel, root file system, etc.) after uboot are normal (for example, if the kernel partition is tampered with, the status partition will be marked as abnormal).

[0140] 3. Branch decision: Default system or restore system

[0141] Based on the check results of bl_chk_uboot(), the process is divided into two branches:

[0142] Branch A: Default system startup (check passed)

[0143] If bl_chk_uboot() determines that "uboot is valid and the status mapping table indicates that other functional partitions are normal", then the default system boot process will be entered:

[0144] uboot loading: Reads and loads the uboot image from the default system partition into memory.

[0145] uboot startup: Executes uboot initialization logic to prepare for booting the kernel and root file system.

[0146] uboot loads the boot logo: reads and displays the default system boot screen (brand / system identifier).

[0147] uboot boots the kernel: uboot loads the default kernel image into memory and passes boot parameters (such as device tree and command line parameters).

[0148] The kernel boots the rootfs: the kernel mounts the default root file system (rootfs) and completes system initialization (such as driver loading and service startup).

[0149] The device is running the default system: The device enters the working environment of the default system and provides normal business functions.

[0150] Branch B: Restore system startup (check failed)

[0151] If bl_chk_uboot() determines that "uboot is invalid / status mapping table indicates that other function partitions are abnormal", then the system recovery boot process is entered (for fault repair):

[0152] uboot.restore loading: Reads and loads the recovery version of uboot (uboot.restore) from the recovery system partition.

[0153] uboot.restore startup: Executes the initialization logic for restoring uboot, preparing to boot the kernel and root file system of the restored system.

[0154] uboot.restore loads the boot logo.restore: reads and displays the boot screen of the restored system (usually containing the "Restore Mode" indicator).

[0155] uboot.restore boots kernel.restore: restores uboot and loads the restored kernel (kernel.restore).

[0156] kernel.restore boots rootfs.restore: restores the kernel, mounts and restores the root file system (rootfs.restore), and enters the system repair environment.

[0157] The device has entered the recovery system: The device enters the recovery system, and the fault can be resolved through repair tools (such as firmware upgrades and data recovery).

[0158] 4. Final stage: RootFS execution

[0159] Whether booting into the default system or restoring the system, the final stage involves running the root file system (rootfs / rootfs.restore). The root file system is the foundation for system services and user interaction, providing core capabilities such as file storage, process management, and network communication.

[0160] In some embodiments, such as Figure 6 The diagram shown illustrates the dual-system atomic update workflow in U-Boot mode, including:

[0161] 1. Process Start and Initialization

[0162] uboot startup: uboot (the bootloader of an embedded system) completes its own initialization and has the ability to execute upgrade logic.

[0163] 2. Dual-system atomic update begins

[0164] Dual-system atomic update begins: uboot officially enters the dual-system atomic upgrade process, and all subsequent operations will proceed in the order of default system → restored system.

[0165] 3. First stage: Atomic update of default system partitions

[0166] The default system is the main system currently running on the device (or the target system to be upgraded), and its update process is broken down into four atomic operation units: state preset → erase → write → state confirmation.

[0167] (1) Status preset: Mark the default system to start updating

[0168] Operation: Update the default_system=0 status to the status partition (the update process includes erase and write operations).

[0169] Technical Logic:

[0170] The status partition is a status management partition independent of the system image, used to record upgrade progress and fault points.

[0171] default_system=0: This indicates that the default system upgrade process has started (status value 0 is a custom upgrade in progress indicator).

[0172] The update process includes erasure and writing: ensuring the atomicity of state writing (avoiding old state from interfering with new state).

[0173] (2) Partition data erase + write: Update the default system kernel partition

[0174] Operation: Erase according to the default system start address to end address; Write (nvt-all, uboot, kernel, rootfs, logo) according to the default system start address to end address; start address = nvt-all.start_addr; end address = logo.end_addr.

[0175] Technical Logic:

[0176] Erasure + Write address range: By using nvt-all.start_addr (partition start address) and logo.end_addr (partition end address), the core functional partitions of the default system such as nvt-all, uboot, kernel, rootfs, etc. (these are the key components for system startup / running) are accurately located.

[0177] Atomicity guarantee: Eraser → Write is an indivisible atomic operation (if interrupted, it will resume from this step after restarting to avoid system damage).

[0178] (3) Status confirmation: Mark the default system rootfs update as complete.

[0179] Operation: Update the rootfs=1 status to the status partition.

[0180] Technical Logic:

[0181] rootfs=1: Marks the default system's rootfs partition (root file system) as updated (status value 1 is a custom upgrade completion identifier).

[0182] Purpose: To provide a basis for subsequent breakpoint resume upgrades (if the upgrade is interrupted, the rootfs can be identified as completed after restart, and there is no need to repeat the operation).

[0183] 4. Second stage: Restore system partition atomic update

[0184] The recovery system is a backup system for the device (used to take over when the default system fails). Its update logic is symmetrical to that of the default system, but its status management and partition addresses are independent.

[0185] (1) Status preset: Mark the recovery system to start updating

[0186] Operation: Update the status of restore_system=2 to the status.restore partition (the update process includes erase and write operations).

[0187] Technical Logic:

[0188] Status.restore partition: A dedicated status partition for the recovery system, physically isolated from the status partition, to avoid status interference.

[0189] restore_system=2: This indicates that the system upgrade process has been started (status value 2 is a custom identifier for system upgrade).

[0190] (2) Partition data erase + write: update and restore the system core partition

[0191] Operation: Erase according to the start address to the end address of the restored system; Write (nvt-all.restore, uboot.restore, kernel.restore, rootfs.restore, logo.restore) according to the start address to the end address of the restored system; start address = nvt-all.restore.start_addr; end address = logo.restore.end_addr.

[0192] Technical Logic:

[0193] The address range for erasure and write: using nvt-all.restore.start_addr and logo.restore.end_addr, locate the symmetric function partitions of the recovery system such as nvt-all.restore, uboot.restore, kernel.restore, rootfs.restore, and logo.restore (consistent with the default system structure to ensure backup availability).

[0194] Atomicity guarantee: Similar to the default system, erase → write is an atomic operation, and can be resumed after interruption.

[0195] (3) Status confirmation: Mark the recovery system update as complete.

[0196] Operation: Update the status of restore_system=3 to the status.restore partition.

[0197] Technical Logic:

[0198] restore_system=3: Marks that all partitions of the recovery system have been updated (status value 3 is a custom indicator of recovery system upgrade completion).

[0199] 5. Process Closure and Business Regression

[0200] Dual-system atomic update complete: Atomic upgrades for both the default system and recovery system are complete, and the final results have been recorded in the state partition.

[0201] uboot performs other tasks: uboot exits upgrade mode and returns to the normal boot process (such as loading the default system, responding to boot parameters, etc.).

[0202] In some embodiments, such as Figure 7 The diagram shown illustrates the atomic update workflow for a dual-system system in rootfs mode, including:

[0203] 1. Process Startup (Initial State → RootFS Running)

[0204] Running in rootfs → Specifying the execution environment for the update: The system is running stably under rootfs (root file system) and has the resources required for the update (such as memory and storage access permissions).

[0205] 2. Dual system update startup

[0206] Dual-system atomic update begins → triggers upgrade process, system switches from "normal operation" to "update mode", preparing to perform subsequent partition update operations.

[0207] 3. Default system partition atomic updates

[0208] This stage focuses on updating the partitions of the default system (the currently running main system). Through the logic of "state pre-update → partition update one by one → state post-update", the traceability and atomicity of the update are guaranteed.

[0209] 3.1 Initialize the default system state

[0210] Operation: Update the default_system=0 status to the status partition (the update process itself is also an erase-to-write operation).

[0211] logic:

[0212] In the status partition (the status management partition of the default system), the status of default_system is marked as 0 (which can be understood as "default system update initialization" or "pending update").

[0213] The state update itself is an atomic operation (first erase the old state, then write the new state), which avoids state chaos and prepares for state tracking in subsequent partition updates.

[0214] 3.2 The default system partition is updated one by one (time-sharing erase and write).

[0215] Operation: Time-sharing erase write to the following partitions: nvt-all, uboot, kernel, rootfs, logo

[0216] logic:

[0217] Process each partition sequentially and in stages (non-parallel) to reduce the risk of hardware resource conflicts and ensure the atomicity of updating a single partition (either all succeed or all fail).

[0218] 3.3 Default system status update (marked as complete)

[0219] Operation: Update rootfs=1 status to the status partition.

[0220] logic:

[0221] In the status partition, the status of rootfs is marked as 1 (which can be understood as "the default system rootfs partition update is complete").

[0222] The status is updated again through atomic operations to record the success status of the partition, which is convenient for subsequent breakpoint resume (if the update is interrupted, it can identify "which partitions have been completed" after restart).

[0223] 4. Restore system partition atomic updates

[0224] This stage focuses on updating the partitions of the recovery system (the backup / standby system of the default system). The logic is the same as that of the default system, but a separate status partition (status.restore) is used for management to ensure the state isolation and reliability of the two systems.

[0225] 5. Update complete → Business operation

[0226] Dual-system atomic update complete → This indicates that all partitions and status partitions of the default system and recovery system have been updated, completing the upgrade process loop.

[0227] Running other business logic in rootfs → The system exits "update mode" and returns to the rootfs environment to continue executing application, service management, and other business logic.

[0228] In some embodiments, such as Figure 8 The diagram shown illustrates the workflow of dual-system atomic symmetric processing in rootfs mode, including:

[0229] After the Rootfs boots normally, symmetric maintenance is triggered, entering detection mode to determine if the default system and recovery system are functioning correctly. If both the default and recovery systems are functioning correctly, maintenance can be skipped and the process can terminate directly. If the default system is functioning correctly but the recovery system is malfunctioning, data replication from the default system to the recovery system can be marked to allow the recovery system to be repaired via the default system. If the default system is malfunctioning but the recovery system is functioning correctly, data replication from the recovery system to the default system can be marked to allow the default system to be repaired via the recovery system. If both the default and recovery systems are malfunctioning, the currently running operating system can be determined, and data replication from the currently running operating system to the other operating system can be performed.

[0230] Compared to traditional upgrade methods, the dual-system atomic upgrade method for embedded devices proposed in this application has the following differences:

[0231] 1. Fundamental difference in operation granularity: Existing technology upgrades are performed at the system level, with the entire system image as the smallest unit. This application refines the operation granularity to the partition level, achieving more precise control.

[0232] 2. Breakthrough in process visibility: The upgrade process of existing technologies is a black box, and the intermediate state cannot be known from the outside. This application makes the entire upgrade process white box through a state linkage mechanism, and the progress can be known in real time.

[0233] 3. Significantly improved recovery efficiency: Existing technologies require a complete rollback after an interruption, resetting the upgrade progress to zero. This application supports resuming the upgrade from where it left off, requiring only the unfinished parts to be redone, greatly improving recovery efficiency.

[0234] 4. Dual-mode upgrade support: Existing technologies typically only support a single upgrade mode. This application supports both bootloader mode and root file system mode for upgrades, adapting to different scenarios.

[0235] 5. Intelligent maintenance automation: Existing solutions lack automatic maintenance during runtime. This application achieves automatic status monitoring and repair during runtime through dual-system symmetrical detection.

[0236] 6. Optimization and innovation of synchronization method: Existing technology uses inefficient full replication for dual-system synchronization, while this application adopts incremental synchronization based on hash comparison, which greatly reduces synchronization time and data volume;

[0237] 7. Risk model redistribution: The risks of existing technologies are concentrated in the long window of the entire upgrade process. This application disperses the risks into multiple short-lived, independent partition-level atomic operation windows, making the system more robust.

[0238] The beneficial effects of the dual-system atomic upgrade method for embedded devices in this application include:

[0239] 1. Security: Partition atomic operation limits the upgrade risk to a very small range. Combined with the ability to resume upgrades from breakpoints, it makes it almost impossible for the device to become unusable due to unexpected events during the upgrade process.

[0240] 2. Availability: Fine-grained status management and intelligent startup decisions ensure that devices can always start from the healthiest system, and incremental synchronization shortens maintenance windows and improves service continuity;

[0241] 3. Highly efficient operation and maintenance: The upgrade process is observable and controllable, and can be quickly and accurately recovered after an interruption, which greatly reduces operation and maintenance time and manpower costs. Incremental synchronization also improves maintenance efficiency.

[0242] 4. Extend device lifespan: Reducing unnecessary full erase / write operations helps reduce wear and tear on the Flash memory and extend the device's lifespan;

[0243] 5. Supports intelligent operation and maintenance: The provided fine-grained status interface lays the foundation for advanced operation and maintenance functions such as remote monitoring and predictive maintenance;

[0244] 6. Flexible scenario adaptation: Supports two upgrade modes: bootloader and root file system, adapting to different scenario needs such as production line burning, on-site manual upgrade, and network automatic upgrade.

[0245] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0246] Based on the same inventive concept, this application also provides a dual-system atomic upgrade apparatus for embedded devices to implement the dual-system atomic upgrade method for embedded devices described above. The solution provided by this apparatus is similar to the implementation described in the above method. Therefore, the specific limitations in one or more embodiments of the dual-system atomic upgrade apparatus for embedded devices provided below can be found in the limitations of the dual-system atomic upgrade method for embedded devices described above, and will not be repeated here.

[0247] In one exemplary embodiment, such as Figure 9 As shown, a dual-system atomic upgrade device 900 for embedded devices is provided, comprising: an operation sequence generation module 902, a partition upgrade module 904, and a cyclic upgrade module 906, wherein:

[0248] The operation sequence generation module 902 is used to determine the system upgrade task for the embedded device and generate an operation sequence for each functional partition in the default system partition group and the recovery system partition group based on the system upgrade task. The storage medium of the embedded device includes a default system partition group, a recovery system partition group, and an independent status management partition. The default system partition group includes the functional partition of the default system, the recovery system partition group includes the functional partition of the recovery system, and the status management partition includes a status mapping table that records the partition status of the default system partition group and the recovery system partition group respectively.

[0249] The partition upgrade module 904 is used to determine the target partition based on the operation sequence, upgrade the target partition according to the operation sequence, and dynamically update the partition status of the target partition in the status mapping table during the upgrade process.

[0250] The loop upgrade module 906 is used to determine the next functional partition based on the operation sequence after the target partition upgrade is completed, and to determine the next functional partition as the target partition. Then, it returns to execute the steps of upgrading the target partition according to the operation sequence until the dual-system upgrade process for the embedded device is completed.

[0251] In some embodiments, the partition upgrade module 904 is further configured to update the partition status of the target partition in the status mapping table to "upgrading in progress" and update the data in the target partition according to the operation sequence; if the updated data in the target partition passes the data verification, the partition status of the target partition in the status mapping table is updated to "upgrade complete".

[0252] In some embodiments, the dual-system atomic upgrade apparatus 900 for embedded devices further includes a continuous upgrade processing module, which is used to determine the functional partition that needs to be upgraded based on a state mapping table when the dual-system upgrade process of the embedded device is interrupted; determine the functional partition that needs to be upgraded as the target partition; and return to execute the steps of upgrading the target partition according to the operation sequence until the dual-system upgrade process for the embedded device is completed.

[0253] In some embodiments, the dual-system atomic upgrade device 900 for embedded devices further includes a startup module, which is used to determine a target startup system from the default system and the recovery system based on the bootloader and the state mapping table when the embedded device starts up, and to start the device through the target startup system; and to repair the default system when the target startup system is the recovery system and the default system is abnormal.

[0254] In some embodiments, the dual-system atomic upgrade apparatus 900 for embedded devices further includes a repair module for repairing the second system by performing data copying from the first system to the second system when it is determined that the first system is normal and the second system is abnormal in the default system and recovery system.

[0255] In some embodiments, the dual-system atomic upgrade device 900 of the embedded device further includes a partition synchronization module, which is used to determine, when the default system upgrade is completed, the partitions to be synchronized that differ from the corresponding functional partitions of the default system from the various functional partitions of the recovery system; and to perform incremental synchronization updates on the partitions to be synchronized through the functional partitions corresponding to the partitions to be synchronized in the default system until the upgrade process for the recovery system is completed.

[0256] Each module in the dual-system atomic upgrade device of the aforementioned embedded device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the controller in hardware form or independent of it, or stored in the memory of the controller in software form, so that the processor can call and execute the operations corresponding to each module.

[0257] In one exemplary embodiment, a controller is provided, the internal structure of which can be shown in the following diagram. Figure 10 As shown, the controller includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores various data involved in the dual-system atomic upgrade method for embedded devices. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a dual-system atomic upgrade method for embedded devices.

[0258] Those skilled in the art will understand that Figure 10 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the controller to which the present application is applied. A specific controller may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0259] In one embodiment, a controller is also provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps in the above method embodiments.

[0260] In one embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0261] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0262] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0263] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0264] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0265] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A dual-system atomic upgrade method for embedded devices, characterized in that, The embedded device's storage medium includes a default system partition group, a recovery system partition group, and a separate state management partition. The default system partition group includes a function partition for the default system, the recovery system partition group includes a function partition for the recovery system, and the state management partition includes a state mapping table that records the partition states of the default system partition group and the recovery system partition group respectively. The method includes: Determine the system upgrade task for the embedded device, and generate an operation sequence for each functional partition in the default system partition group and the recovery system partition group based on the system upgrade task; The target partition is determined based on the operation sequence, the target partition is upgraded according to the operation sequence, and the partition status of the target partition in the status mapping table is dynamically updated during the upgrade process of the target partition. Once the target partition upgrade is complete, the next functional partition is determined based on the operation sequence, and the next functional partition is identified as the target partition. The process then returns to the step of upgrading the target partition according to the operation sequence until the dual-system upgrade process for the embedded device is completed.

2. The method according to claim 1, characterized in that, The step of upgrading the target partition according to the operation sequence, and dynamically updating the partition status of the target partition in the status mapping table during the upgrade process, includes: Update the partition status of the target partition in the status mapping table to "Upgrading", and update the data in the target partition according to the operation sequence; If the updated data in the target partition passes data verification, the partition status of the target partition in the status mapping table is updated to "upgrade complete".

3. The method according to claim 1, characterized in that, The method further includes: When the dual-system upgrade process of the embedded device is interrupted, the functional partition that needs to be continued upgrade is determined based on the state mapping table. The function partition that needs to be upgraded is identified as the target partition, and the process returns to execute the steps of upgrading the target partition according to the operation sequence until the dual-system upgrade process for the embedded device is completed.

4. The method according to claim 1, characterized in that, The method further includes: When the embedded device starts up, a target boot system is determined from the default system and the recovery system based on the bootloader and the state mapping table, and the device is started through the target boot system. When the target boot system is the recovery system and the default system is abnormal, repair is performed on the default system.

5. The method according to claim 1, characterized in that, The method further includes: If it is determined that the first system is normal and the second system is abnormal in the default system and the recovery system, data is copied from the first system to the second system to repair the second system.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: When the default system upgrade is completed, identify the partitions to be synchronized that differ from the corresponding functional partitions of the default system from the various functional partitions of the restored system; Incremental synchronization updates are performed on the partition to be synchronized using the functional partition corresponding to the partition to be synchronized in the default system until the upgrade process for the recovery system is completed.

7. A dual-system atomization upgrade device for an embedded device, characterized in that, The device includes: An operation sequence generation module is used to determine a system upgrade task for an embedded device and generate an operation sequence for each functional partition in the default system partition group and the recovery system partition group based on the system upgrade task. The storage medium of the embedded device includes the default system partition group, the recovery system partition group, and an independent status management partition. The default system partition group includes a functional partition of the default system, the recovery system partition group includes a functional partition of the recovery system, and the status management partition includes a status mapping table that records the partition status of the default system partition group and the recovery system partition group respectively. The partition upgrade module is used to determine the target partition based on the operation sequence, upgrade the target partition according to the operation sequence, and dynamically update the partition status of the target partition in the status mapping table during the upgrade process of the target partition. The loop upgrade module is used to determine the next functional partition based on the operation sequence after the target partition upgrade is completed, and to determine the next functional partition as the target partition, and then return to execute the step of upgrading the target partition according to the operation sequence until the dual-system upgrade process for the embedded device is completed.

8. A controller comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images