Multi-mode check point design method based on embedded virtualization environment

Abstract

The invention relates to a multi-mode check point design method based on an embedded virtualization environment, and belongs to the field of embedded system simulation. The invention relates to an embedded system testing method combining a check point function and fault injection. According to the method, check points are regularly stored in the operational process so as to be quickly recovered when a fault occurs. Meanwhile, by introducing a fault injection mechanism, an embedded developer can combine a check point function and a fault injection module to store the specific state of one or more modules before fault injection, various abnormal conditions can be simulated and tested to verify the fault tolerance and stability of the system, and the fault injection efficiency is improved. And the state of the whole system or a specific module can be recovered at any time according to needs. According to the method, the storage and processing efficiency of the check points is optimized, the resource overhead is reduced, the efficient operation of the embedded system in a resource-constrained environment is ensured, and the reliability and the fault recovery capability of the system are improved.

Description

Technical Field

[0001] The invention belongs to the field of embedded system simulation, and in particular relates to a multi-mode checkpoint design method based on an embedded virtualization environment. Background Art

[0002] With the widespread application of embedded systems in the field of modern technology, embedded systems play an increasingly important role in various fields, and their requirements for real-time, reliability and stability are constantly increasing. Embedded systems are used in key fields such as aerospace, automotive electronics, industrial automation and medical equipment. Any failure or interruption of these systems may have serious consequences. Therefore, how to effectively detect and recover system failures during operation has become a key and difficult point of research. In the development of embedded systems, the checkpoint function has gradually attracted attention as a method to enhance the fault tolerance of the system. By regularly saving the current system state, i.e., "checkpoints", when the system is operating normally, once a failure occurs, the system can roll back to the most recent checkpoint and restart, thereby avoiding the impact of data loss or system crashes. This mechanism is particularly important in high availability and high security scenarios.

[0003] Existing simulation technologies still face some challenges in implementing the checkpoint function. First, existing checkpoint technologies are often limited by performance, and saving and restoring the state of the entire system requires a lot of time and computing resources, especially when the simulation involves a large number of peripherals and complex modules. Second, some simulation platforms may not be able to accurately restore the state of all peripherals and registers during the recovery process, resulting in inconsistent system behavior after recovery and when it was saved, thus affecting the accuracy of debugging.

[0004] Therefore, it is particularly important to be able to record and restore the status of the entire system or specific modules in virtualized embedded systems according to common fault scenarios in embedded environments. Under this requirement, an innovative method has been invented to ensure that the embedded system can recover quickly when an abnormality occurs, and the overall performance of the system is not affected, thereby meeting the application requirements in resource-constrained environments. Such a technical solution not only improves the fault tolerance and stability of the system, but also provides embedded system developers with more flexible system debugging and diagnosis methods.

[0005] Although the existing embedded system checkpoint technology provides valuable support in fault tolerance and recovery, it faces a series of defects and challenges in practice. First, most systems that implement the checkpoint function do not fully meet the requirements of embedded systems, do not include commonly used peripherals in embedded systems, and the state preservation and recovery functions do not meet the various fault scenarios of embedded systems. When the existing solutions are applied in embedded environments, they usually generate high storage and processing overhead, which affects the real-time and overall performance of the system.

[0006] In addition, although checkpoint technology can quickly restore the system state when a fault occurs, its application alone is insufficient in verifying the stability and fault tolerance of the system. For example, a system that relies solely on checkpoint recovery may not be able to fully understand and respond to specific failure modes. Without the introduction of fault injection methods, it is difficult to verify the system's recovery and fault tolerance under different types of failures during system development and testing. Therefore, the existing technology lacks a comprehensive, low-overhead solution to integrate checkpoint and fault injection functions to improve the reliability and stability of embedded systems without significantly sacrificing system performance. Summary of the invention

[0007] 1. Technical issues to be resolved

[0008] The technical problem to be solved by the present invention is how to provide a multi-mode checkpoint design method based on an embedded virtualization environment to solve the problems of large resource overhead and inability to verify multiple fault responses in the prior art.

[0009] (II) Technical solution

[0010] In order to solve the above technical problems, the present invention proposes a multi-mode checkpoint design method based on an embedded virtualization environment. The method is based on a multi-mode checkpoint design system of an embedded virtualization environment, and comprises the following steps:

[0011] Step 1: Build an embedded virtualization environment

[0012] According to the modules contained in the embedded system, the logic of the hardware device is realized by software simulation, including the realization of virtualized memory, processor, peripherals, and bus modules. The relationship between simulation models is described according to the composition relationship of the actual hardware embedded system, and the embedded software under test is run;

[0013] Step 2: Implement virtualized memory page tracking

[0014] The virtualized memory allocated by the virtualization environment for running the application under test is divided into several pages, and the read-only flag is set for these pages each time a checkpoint is saved; if there is a write operation, a copy-on-write exception will be triggered, and the modified page will be marked as changed;

[0015] The third step is to implement the fault injection mechanism of each module

[0016] The fault injection module can provide flexible multi-mode fault injection capabilities for embedded systems, supporting various types of changes to the CPU, peripherals, bus and memory data, so as to simulate complex fault scenarios during the development and testing phases; the fault injection module allows users to introduce CPU register value tampering, peripheral register forgery, bus data interference and memory data corruption to evaluate response behaviors in various situations. The fault injection module is used in conjunction with the checkpoint module. The fault injection module saves single or multiple module states before fault injection, and can quickly restore to the previous stable state after a fault occurs, thereby achieving cross-validation of fault impact and recovery capabilities;

[0017] Step 4: Implement each module and the overall checkpoint mechanism

[0018] The checkpoint module implements multi-module checkpoint function. According to user needs, it can flexibly manage embedded system checkpoints, covering independent or combined capture and storage of processors, peripherals, buses and specific memory areas. Through modular design, it can selectively record the register status of a processor, peripheral registers and configurations, bus transmission data or the contents of a specified memory block. The overall mechanism includes state change detection and incremental storage to ensure efficient resource utilization. Users can create and restore checkpoints of specific modules based on actual needs to achieve targeted recovery and debugging.

[0019] Step 5: Implement multi-module checkpoint recovery mechanism

[0020] Supports flexible checkpoint recovery mechanism in embedded systems, allowing users to select specific single or multiple modules for state recovery during operation;

[0021] Step 6: Implement multi-module checkpoint status monitoring

[0022] The multi-module checkpoint status monitoring function supports status monitoring after setting checkpoints for each module in an embedded system, and provides data tracking after fault injection and recovery from multiple checkpoints. After recovering a specific module checkpoint, the data of these modules can continue to be monitored to ensure the correctness and stability of the recovery process. Through real-time data collection and comparison functions, it helps developers evaluate response behaviors, verify fault recovery effects, and optimize fault recovery strategies.

[0023] (III) Beneficial effects

[0024] The present invention proposes a multi-mode checkpoint design method based on an embedded virtualization environment. The multi-mode checkpoint technology of the embedded virtualization environment of the present invention has the following characteristics:

[0025] 1. Checkpoint saving based on virtualization environment can efficiently save and restore the status of multiple modules or the entire system in the simulation environment.

[0026] 2. Supports saving checkpoints and restoring checkpoints. Saving checkpoints is used to record the status of the system or module in real time during operation, and restoring checkpoints is used to trace back the system status during debugging and fault analysis.

[0027] 3. Efficient data compression and incremental storage technology, checkpoints can quickly save system status without occupying a lot of storage resources.

[0028] 4. Checkpoints are integrated with the fault injection module to simulate various failure scenarios and monitor the system's response.

[0029] 5. Checkpoints are combined with status monitoring. When the set checkpoints are reached, status monitoring is triggered to record and analyze the status of the system or module. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 It is a structural block diagram of the present invention;

[0031] Figure 2 It is a flow chart of the present invention. DETAILED DESCRIPTION

[0032] In order to make the purpose, content and advantages of the present invention more clear, the specific implementation methods of the present invention are further described in detail below in conjunction with the drawings and examples.

[0033] The purpose of the present invention is to provide an embedded system solution that combines checkpointing function and fault injection technology to overcome the defects of the prior art, such as large resource overhead and inability to verify multiple fault responses. By integrating checkpointing technology with fault injection function, the embedded system can not only quickly recover to the most recent stable state in the event of an abnormality or failure, but also actively introduce faults during the development and testing phase to verify the system's fault tolerance and recovery mechanism.

[0034] The present invention aims to reduce the performance impact of checkpoints in resource-constrained environments by optimizing the storage and processing efficiency of checkpoints, while enhancing the system's fault response capabilities in complex scenarios. The technical solution supports detailed analysis of the system's behavior under specific fault conditions, thereby helping developers optimize the system structure and improve the reliability and stability of the system. Ultimately, the present invention provides a cost-effective solution for the application of embedded systems under high reliability requirements, achieving lightweight and efficient checkpoint storage and fault-tolerant verification based on fault injection.

[0035] The present invention proposes a multi-mode checkpoint design method based on an embedded virtualization environment, which is an embedded system testing method that combines checkpoint functions and fault injection. The system regularly saves checkpoints during the operational process to quickly recover when a fault occurs. At the same time, by introducing a fault injection mechanism, embedded developers can combine the checkpoint function and the fault injection module to save the status of a specific module or modules before injecting the fault, and can simulate and test various abnormal situations to verify the fault tolerance and stability of the system, and can restore the status of the entire system or a specific module at any time as needed. This solution optimizes the storage and processing efficiency of checkpoints, reduces resource overhead, ensures the efficient operation of embedded systems in resource-constrained environments, and improves the reliability and fault recovery capabilities of the system.

[0036] Step 1: Build an embedded virtualization environment

[0037] According to the modules contained in common embedded systems, soft simulation is used to implement the logic of hardware devices, including virtualized memory, processor, peripherals, bus and other modules. The relationship between simulation models is described according to the composition relationship of the actual hardware embedded system, and the embedded software under test is run.

[0038] Step 2: Implement virtualized memory page tracking

[0039] The virtualized memory allocated by the virtualization environment for running the application under test is divided into several pages, and the read-only flag is set for these pages each time a checkpoint is saved. If there is a write operation, the system triggers a copy-on-write exception and marks the modified page as changed. This mechanism can help quickly track which memory pages have changed since the last checkpoint and reduce the overhead of traversing the entire memory.

[0040] The third step is to implement the fault injection mechanism of each module

[0041] The fault injection module can provide flexible multi-mode fault injection capabilities for embedded systems, supporting various types of changes to the CPU, peripherals, bus and memory data, so as to simulate complex fault scenarios during the development and testing phases. The fault injection module allows users to introduce various faults such as CPU register value tampering, peripheral register forgery, bus data interference and memory data corruption to evaluate the system's response behavior under various conditions. The fault injection module can be used in conjunction with the checkpoint module. The fault injection module saves single or multiple module states before fault injection, and can quickly restore the system to a previous stable state after a fault occurs, thereby achieving cross-validation of fault impact and system recovery capabilities.

[0042] Step 4: Implement each module and the overall checkpoint mechanism

[0043] The checkpoint module implements multi-module checkpoint functions, and can flexibly manage embedded system checkpoints according to user needs, covering independent or combined capture and preservation of processors, peripherals, buses, and specific memory areas. Through modular design, the system can selectively record the register status of a processor, peripheral registers and configurations, bus transmission data, or the contents of a specified memory block. The overall mechanism includes state change detection and incremental preservation to ensure efficient resource utilization. Users can create and restore checkpoints for specific modules based on actual needs, and achieve targeted recovery and debugging to improve the system's fault tolerance and operational flexibility.

[0044] Step 5: Implement multi-module checkpoint recovery mechanism

[0045] Supports flexible checkpoint recovery mechanism in embedded systems, allowing users to select specific single or multiple modules for state recovery during operation. For example, developers can restore the register state of a processor, peripheral configuration, bus activity or the content of a specific memory area according to needs, without restoring the entire system state. This mechanism achieves independent recovery of key modules through refined recovery strategies, ensuring fault recovery and debugging of the system without affecting the overall operation. This design achieves high efficiency and flexibility in recovery operations, meeting the high requirements of embedded systems for real-time performance and resource optimization.

[0046] Step 6: Implement multi-module checkpoint status monitoring

[0047] The multi-module checkpoint status monitoring function supports status monitoring after setting checkpoints for each module in an embedded system, and provides data tracking after fault injection and recovery from multiple checkpoints. For example, users can select specific variables or modules (such as processor registers, peripheral status, or memory areas) to set checkpoints, and monitor the status of each module in real time after setting to observe its changes under the influence of the fault. After restoring the checkpoints of specific modules, the system can continue to monitor the data of these modules to ensure the correctness and stability of the recovery process. Through real-time data collection and comparison functions, this module helps developers evaluate system response behavior, verify fault recovery effects, and optimize fault recovery strategies. This design implements detailed monitoring of each module in complex scenarios of embedded systems, enhancing the debugging capabilities and overall reliability of the system.

[0048] Embodiment 1:

[0049] The present invention provides a multi-mode checkpoint design system based on an embedded virtualization environment, comprising: a virtualization platform, a fault injection module, a checkpoint module and a state monitoring module. The checkpoint module comprises: a unit checkpoint submodule, a system checkpoint submodule, a snapshot library management submodule, a state preservation and recovery submodule and a state monitoring submodule. Figure 1 shown.

[0050] First, build an embedded system virtualization platform, including common processors, peripherals, buses, memory and protocols of embedded systems, to form a virtualization platform to support the operation of embedded applications;

[0051] Secondly, build a fault injection module to support the injection of various types of faults into each module of the embedded virtualization environment individually or in batches, including the register values ​​of the CPU, peripherals, and buses, memory data, etc., and can cooperate with the checkpoint module to set parameter values ​​and set the components of the embedded virtualization environment that need to be controlled. When the system reaches a certain checkpoint, it can automatically save the data of the corresponding module, and when a certain checkpoint is reached, it can manually or automatically restore a previously saved state entry from the checkpoint module;

[0052] Then, a status monitoring module is constructed, which can be combined with the checkpoint module and the fault injection module to monitor the various components of the embedded virtualization environment and display the value changes of the module after injecting a fault, reaching a certain checkpoint or resuming the check.

[0053] The specific implementation steps are:

[0054] The first step is to build an embedded virtualization environment

[0055] As an important platform supporting the operation of embedded applications, the embedded virtualization environment uses hardware virtualization technology to implement the logic of the core modules in the embedded system, achieving the same effect as the program running on the hardware platform. It mainly includes the implementation of the processor, peripherals, and bus, including the following implementation steps:

[0056] (1) Processor module implementation: This module simulates the CPU in the embedded system to execute the instruction set architecture (ISA) according to the official instruction set manual of the specific CPU. This module is responsible for executing program code, general registers, floating-point registers, control registers, program counter (PC) and other core components. This module accurately simulates instruction fetching, decoding and execution, as well as events such as pipeline processing and interrupt management, to ensure that the system behavior of embedded applications in the embedded virtualization environment is consistent with the actual hardware.

[0057] (2) Peripheral module implementation: The peripheral module simulates commonly used peripheral devices and protocols in embedded systems, such as IO, timers, and communication protocols. It provides applications in a virtualized environment with the ability to simulate interaction with external real hardware. This module simulates the input and output operations and state changes of real hardware peripherals in an event-driven manner to ensure that the behavior of the peripherals is consistent with the actual hardware. When the application accesses the address of a specific peripheral, it accesses the specific virtual device of the module.

[0058] (3) Memory module implementation: This module is responsible for simulating the memory structure in the embedded system, including RAM, ROM, and Flash, and managing memory access in the virtualized environment to ensure that the memory is correctly read and written during the virtualization process. The memory module handles different types of memory accesses by embedded applications at runtime, such as data, instruction storage, stack operations, etc., and accurately tracks the memory status to facilitate subsequent checkpoint saving and recovery.

[0059] The second step is to build a fault injection module

[0060] The fault injection module is closely integrated with the checkpoint module. According to the needs of program design, various types of faults can be injected into specific scenarios of the program to verify the fault tolerance and reliability of the system. When a fault occurs, the checkpoint module can be used to record the state of the system. When necessary, the checkpoint can be restored to the state before the fault to perform fault analysis and recovery verification. This fault injection module mainly includes the implementation of various types of faults and the implementation of fault injection and checkpoint interfaces:

[0061] (1) Fault injection type implementation: This module implements a variety of common fault injection methods for embedded systems, aiming to evaluate the fault tolerance of embedded applications under different types of hardware and software faults. This module supports multiple injection methods, mainly including verification of processor faults (such as inserting erroneous instructions, modifying instruction codes or register data changes), memory faults (such as abnormal data, address out of bounds, bit flipping) and peripheral faults (such as communication interruption, device register change).

[0062] (2) Implementation of the checkpoint interface: This function is the core interface of the checkpoint function, which aims to ensure that when a module in the system fails or the system status during the fault injection process can be saved promptly and accurately by the checkpoint function module, and can be restored after the failure occurs. When performing fault injection, the interface automatically calls the checkpoint module, which can selectively save the status of the current entire system or the related unit modules directly affected by the fault injection.

[0063] Step 3: Build unit and system checkpoint submodules

[0064] This module supports unit checkpoints and checkpoints of the entire system, and provides flexible state capture and recovery functions. The implementation steps are as follows:

[0065] (1) Initialization configuration: Before running the embedded system or during operation, initialize the checkpoint module, configure the capture type of the checkpoint, and set the save checkpoint and restore checkpoint of the trigger conditions. When the system reaches the save checkpoint, save the data of the set module to the snapshot library. When the system reaches the restore checkpoint, select the corresponding module data from the snapshot library and load it into the specified module.

[0066] (2) Unit checkpoint submodule implementation: Users can set capture logic for specific components (such as processor registers, specific memory areas, or peripheral status), allowing developers to perform more detailed debugging and recovery of each unit of the embedded application system, making it easier to analyze the behavior and performance of a single component in the entire system.

[0067] (3) System checkpoint submodule capture implementation: This function is used to capture the status of the entire system, including the processor status, complete memory content, and peripheral status. This function enables the system to completely restore its previous state when a failure occurs.

[0068] (4) Fault injection interface support: Provides an interactive interface with fault injection, which can selectively save the status of the unit or system after fault injection or when the system fails or reaches a certain abnormal value.

[0069] Step 4: Build the snapshot library management submodule

[0070] The snapshot library management submodule is responsible for organizing and managing the system snapshots generated after each checkpoint is triggered. The implementation steps are as follows:

[0071] (1) Snapshot capture: Each time a checkpoint is triggered, the current system state is captured and saved as a snapshot file. A unique identifier is generated for each snapshot as an important retrieval during recovery.

[0072] (2) Metadata Recording: A set of metadata is created for each saved snapshot, including timestamp, snapshot type (unit or system), trigger condition, and description information to facilitate classification and retrieval.

[0073] (3) Storage and Compression: Implement an efficient storage strategy for snapshot data, use data compression technology to reduce storage space usage, and support tiered storage to optimize performance.

[0074] (4) Automated management of snapshot libraries: Users can choose whether to regularly delete outdated or redundant snapshots based on actual needs to ensure effective use of host storage space. Version control is also provided to retain key snapshots to prevent important data from being overwritten or lost.

[0075] Step 5: State preservation and recovery submodule

[0076] The functional snapshot library management submodules work together to achieve efficient state preservation, classification management and recovery. The specific implementation steps are as follows:

[0077] (1) Saving unit modules and system status: When a certain checkpoint is reached, the simulation of the system is paused, and the status data of specific components (such as processor registers, memory blocks, or peripheral status) or the entire system status is obtained, which is encapsulated and called to store and compress the snapshot library. Each snapshot is managed by version for subsequent recovery. When the snapshot is saved, the current simulation system continues to run.

[0078] (2) Unit module and system status recovery: When the system runs to a recovery checkpoint set in advance, the snapshot data of the corresponding unit module or the entire system is read from the library of the "snapshot library management submodule" in combination with the indexing and retrieval functions of the snapshot library, and loaded into a specific component or the entire system for recovery.

[0079] Step 6: Status Monitoring Submodule

[0080] The status monitoring submodule can flexibly monitor the data of specific variables and modules, and provide effective fault analysis and debugging support in combination with the fault injection interface. The module is implemented as follows:

[0081] (1) Initialization and configuration: Monitor a single component (such as a register or memory unit) or an entire module (such as a processor or peripheral). At the same time, set the trigger conditions for monitoring (such as when a checkpoint or monitoring point is reached).

[0082] (2) Combined with checkpoint monitoring: realize intercommunication with the checkpoint interface. When the set checkpoint or monitoring point event arrives, call each module interface to obtain the corresponding data and display it in the monitoring module.

[0083] (3) Combined with the fault injection interface: By calling the fault injection interface, when the system injects a fault, the injection parameters set by the fault injection module are obtained to monitor the data of the specified module.

[0084] (4) Data analysis implementation: The captured data is saved in a log or buffer, and the data changes of each variable and module at different checkpoints, monitoring points, or the entire operation cycle are displayed through charts to help developers identify potential problems.

[0085] The key points of the present invention are:

[0086] 1. Checkpoint monitoring of each module:

[0087] As an important technology for setting checkpoint parameters, this technology is a core technology in embedded simulation software, which aims to provide users with flexible checkpoint settings and module monitoring functions. The key to the implementation of this technology is that users can customize the checkpoint parameters and save the status of the selected module when the specified checkpoint is reached during system execution. The implementation points include 2 parts, among which the common checkpoint saving and checkpoint recovery parameter settings are as follows:

[0088]

[0089] (1) Flexible checkpoint settings: Users can configure checkpoints at different program locations, time points, or event trigger conditions. Each checkpoint can be accompanied by custom parameters such as timestamps, trigger conditions (such as specific instructions or memory read and write operations), and module selection.

[0090] (2) Module selection and monitoring: Users can select the module range to be monitored, including processor registers, memory status, peripheral registers, interrupt controllers, etc. The system supports defining the specific module status to be saved when setting a checkpoint, and provides two modes: single module monitoring and multi-module combined monitoring. For example, at a certain checkpoint, users can choose to monitor only the processor registers and stack contents, or save the entire system status at the same time.

[0091] 2. State preservation and recovery technology:

[0092] This technology is a core technology in the embedded virtualization simulation environment. It aims to capture and save the current state of the system during operation, and restore the system to a saved state when needed. This technology is used for debugging, fault analysis and system backtracking, providing stable and accurate system state management. The specific implementation process is as follows: Figure 2 As shown:

[0093] The multi-mode checkpoint technology for an embedded virtualized environment of the present invention has the following characteristics:

[0094] 1. Checkpoint saving based on virtualization environment can efficiently save and restore the status of multiple modules or the entire system in the simulation environment.

[0095] 2. Supports saving checkpoints and restoring checkpoints. Saving checkpoints is used to record the status of the system or module in real time during operation, and restoring checkpoints is used to trace back the system status during debugging and fault analysis.

[0096] 3. Efficient data compression and incremental storage technology, checkpoints can quickly save system status without occupying a lot of storage resources.

[0097] 4. Checkpoints are integrated with the fault injection module to simulate various failure scenarios and monitor the system's response.

[0098] 5. Checkpoints are combined with status monitoring. When the set checkpoints are reached, status monitoring is triggered to record and analyze the status of the system or module.

[0099] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the technical principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A multi-mode checkpoint design method based on an embedded virtualization environment, characterized in that: The method is based on a multi-mode checkpoint design system for an embedded virtualization environment, and includes the following steps: Step 1: Build an embedded virtualization environment According to the modules contained in the embedded system, the logic of the hardware device is realized by software simulation, including the realization of virtualized memory, processor, peripherals, and bus modules. The relationship between simulation models is described according to the composition relationship of the actual hardware embedded system, and the embedded software under test is run; Step 2: Implement virtualized memory page tracking The virtualized memory allocated by the virtualization environment for running the application under test is divided into several pages, and the read-only flag is set for these pages each time a checkpoint is saved; if there is a write operation, a copy-on-write exception will be triggered, and the modified page will be marked as changed; The third step is to implement the fault injection mechanism of each module The fault injection module can provide flexible multi-mode fault injection capabilities for embedded systems, supporting various types of changes to the CPU, peripherals, bus and memory data, so as to simulate complex fault scenarios during the development and testing phases; the fault injection module allows users to introduce CPU register value tampering, peripheral register forgery, bus data interference and memory data corruption to evaluate response behaviors in various situations. The fault injection module is used in conjunction with the checkpoint module. The fault injection module saves single or multiple module states before fault injection, and can quickly restore to the previous stable state after a fault occurs, thereby achieving cross-validation of fault impact and recovery capabilities; Step 4: Implement each module and the overall checkpoint mechanism The checkpoint module implements multi-module checkpoint functions. According to user needs, it can flexibly manage embedded system checkpoints, covering independent or combined capture and storage of processors, peripherals, buses and specific memory areas. Through modular design, it can selectively record the register status of a processor, peripheral registers and configurations, bus transmission data or the contents of a specified memory block. The overall mechanism includes state change detection and incremental saving to ensure efficient resource utilization; users can create and restore checkpoints of specific modules based on actual needs to achieve targeted recovery and debugging; Step 5: Implement multi-module checkpoint recovery mechanism Supports flexible checkpoint recovery mechanism in embedded systems, allowing users to select specific single or multiple modules for state recovery during operation; Step 6: Implement multi-module checkpoint status monitoring The multi-module checkpoint status monitoring function supports status monitoring after setting checkpoints for each module in an embedded system, and provides data tracking after fault injection and recovery from multiple checkpoints. After recovering a specific module checkpoint, the data of these modules can continue to be monitored to ensure the correctness and stability of the recovery process. Through real-time data collection and comparison functions, it helps developers evaluate response behaviors, verify fault recovery effects, and optimize fault recovery strategies.

2. The multi-mode checkpoint design method based on embedded virtualization environment as claimed in claim 1, characterized in that: The multi-mode checkpoint design system includes four parts: a virtualization platform, a fault injection module, a checkpoint module and a state monitoring module. The checkpoint module includes a unit checkpoint submodule, a system checkpoint submodule, a snapshot library management submodule, a state preservation and recovery submodule and a state monitoring submodule.

3. The multi-mode checkpoint design method based on embedded virtualization environment as claimed in claim 2, characterized in that: Build a fault injection module to support the injection of various types of faults into each module of the embedded virtualization environment individually or in batches, including the register values ​​of the CPU, peripherals, and bus, and the data in the memory. It can also cooperate with the checkpoint module to set parameter values ​​and set the components of the embedded virtualization environment that need to be controlled. When the system reaches a certain checkpoint, it can automatically save the data of the corresponding module, and when a certain checkpoint is reached, it can manually or automatically restore a previously saved state entry from the checkpoint module.

4. The multi-mode checkpoint design method based on embedded virtualization environment as claimed in claim 2, characterized in that: Construct a status monitoring module, combine the checkpoint module and the fault injection module to monitor the various components of the embedded virtualization environment, and display the value changes of the module after injecting a fault, reaching a certain checkpoint or resuming the check.

5. The multi-mode checkpoint design method based on embedded virtualization environment according to any one of claims 2 to 4, characterized in that: The first step comprises: Processor module implementation: This module simulates the CPU in the embedded system to execute the instruction set architecture according to the official instruction set manual of the specific CPU; this module is responsible for executing program code, general registers, floating-point registers, control registers, and program counter (PC). This module accurately simulates instruction fetching, decoding, and execution, as well as pipeline processing and interrupt management events, ensuring that the system behavior of embedded applications in the embedded virtualization environment is consistent with the actual hardware; Peripheral module implementation: The peripheral module simulates peripheral devices and protocols in embedded systems, including IO, timers, and communication protocols, and provides applications in a virtualized environment with the ability to simulate interaction with external real hardware. This module simulates the input and output operations and state changes of real hardware peripherals in an event-driven manner to ensure that the behavior of the peripherals is consistent with the actual hardware. When the application accesses the address of a specific peripheral, it accesses the specific virtual device of the module; Memory module implementation: This module is responsible for simulating the memory structure in the embedded system, including RAM, ROM and Flash, and managing memory access in the virtualized environment to ensure that the memory is read and written correctly during the virtualization process. The memory module handles different types of memory accesses by embedded applications at runtime and accurately tracks the memory status to facilitate subsequent checkpoint saving and recovery.

6. The multi-mode checkpoint design method based on embedded virtualization environment as claimed in claim 5, characterized in that: The fault injection module includes the implementation of various types of faults and the implementation of fault injection and checkpoint interfaces, including: Fault injection types implemented: This module implements multiple fault injection methods for embedded systems, aiming to evaluate the fault tolerance of embedded applications under different types of hardware and software faults. This module supports multiple injection methods, including: verifying processor faults, memory faults, and peripheral faults; Implementation of the checkpoint interface: This function is the core interface for the checkpoint function, which aims to ensure that when a module in the system fails or the system status during the fault injection process can be saved promptly and accurately by the checkpoint function module, and can be restored after the failure occurs; when fault injection is performed, the interface automatically calls the checkpoint module, which can selectively save the status of the current entire system or related unit modules directly affected by the fault injection.

7. The multi-mode checkpoint design method based on embedded virtualization environment as claimed in claim 6, characterized in that: The unit checkpoint submodule and system checkpoint submodule construction include: Initialization configuration: Before running the embedded system or during operation, initialize the checkpoint module, configure the capture type of the checkpoint, and set the save checkpoint and restore checkpoint of the trigger condition. When the system reaches the save checkpoint, save the data of the set module to the snapshot library. When the system reaches the restore checkpoint, select the corresponding module data from the snapshot library and load it into the specified module. Unit checkpoint submodule implementation: Users can set capture logic for specific components, allowing developers to debug and recover each unit of the embedded application system in a more detailed manner, making it easier to analyze the behavior and performance of a single component in the entire system; System checkpoint submodule capture implementation: This function is used to capture the status of the entire system, including the processor status, complete memory content, and peripheral status. This function enables the system to completely restore the previous status when a failure occurs. Fault injection interface support: Provides an interactive interface with fault injection, which can selectively save the state of the unit or system after fault injection, or when the system fails or reaches a certain abnormal value.

8. The multi-mode checkpoint design method based on embedded virtualization environment as claimed in claim 7, characterized in that: The snapshot library management submodule construction includes: Snapshot capture: When each checkpoint is triggered, the current system state is captured and saved as a snapshot file, and a unique identifier is generated for each snapshot as an important retrieval during recovery; Metadata Recording: Create a set of metadata for each saved snapshot, including timestamp, snapshot type, trigger condition and description information, to facilitate classification and retrieval; Storage and compression: Implement efficient storage strategies for snapshot data, use data compression technology to reduce storage space usage, and support tiered storage to optimize performance; Automatic management of snapshot library: Users can choose whether to regularly delete outdated or redundant snapshots based on actual needs to ensure effective use of host storage space. Version control is also provided to retain key snapshots to prevent important data from being overwritten or lost.

9. The multi-mode checkpoint design method based on embedded virtualization environment as claimed in claim 8, characterized in that: The state preservation and recovery submodule construction includes: Unit module and system status preservation: When a certain checkpoint is reached, the simulation of the system is paused, and the status data of a specific component or the entire system status is obtained, which is encapsulated and stored and compressed by calling the "snapshot library management submodule". Each snapshot is managed by version for subsequent recovery. When the snapshot is saved, the current simulation system continues to run; Unit module and system status recovery: When the system runs to a recovery checkpoint set in advance, combined with the indexing and retrieval functions of the snapshot library, the snapshot data of the corresponding unit module or the entire system is read from the library of the "snapshot library management submodule" and loaded into a specific component or the entire system for recovery.

10. The multi-mode checkpoint design method based on embedded virtualization environment according to claim 9, characterized in that: The state monitoring submodule construction includes: Initialization and configuration: monitor a single component or the entire module; at the same time, set the trigger conditions for monitoring; Combined with checkpoint monitoring: realize intercommunication with the checkpoint interface. When the set checkpoint or monitoring point event arrives, call each module interface to obtain the corresponding data and display it in the monitoring module; Combined with the fault injection interface: By calling the fault injection interface, when the system injects a fault, the injection parameters set by the fault injection module are obtained to monitor the data of the specified module; Data analysis implementation: Save the captured data to logs or buffers, and use charts to display the data changes of each variable and module at different checkpoints, monitoring points or the entire operation cycle to help developers identify potential problems.

Images