A fault injection method for a QEMU-based all-digital digital prototype

Abstract

The present application belongs to the technical field of embedded software virtualization testing, and particularly relates to a fault injection method for a QEMU-based all-digital digital prototype. The present application divides faults into three layers, i.e. an atomic fault injection layer, a composite fault injection layer and a fault injection simulation test layer, provides four types of atomic fault injection, i.e. register fault, memory fault, bus protocol fault and bus load fault, and provides composite fault injection and fault case set injection. The present application takes the QEMU-based all-digital simulation digital prototype as an injection target, improves the reliability of fault injection results, and realizes fault injection at different levels from the physical layer to the application layer through the provision of three levels and four dimensions of fault injection modes and rich fault injection methods, thereby improving the fault tolerance and reliability of embedded software and improving the testing efficiency.

Description

Technical Field

[0001] The present invention belongs to the technical field of embedded software virtualization testing, and in particular relates to a fault injection method for a full-digital prototype based on QEMU. Background Art

[0002] For safety-critical industries like aviation and aerospace, embedded software must undergo not only normal functional testing but also fault tolerance and reliability testing under abnormal conditions, such as hardware failures or malfunctions. However, in actual testing, these abnormal conditions are often difficult to simulate or reproduce due to factors like on-site environment and cost, making it difficult to fully test the corresponding fault tolerance and reliability. This introduces uncertainties and potential safety hazards into embedded systems, potentially leading to safety incidents and casualties. To eliminate these potential instabilities in embedded software and improve its ability to handle anomalies and faults, fault injection is often used to simulate realistic software anomalies and hardware failures, improving the software's fault tolerance and reliability.

[0003] Fault injection technology involves artificially injecting specific faults into a target system and then observing its behavior to verify the system's fault tolerance and reliability. Depending on the injection method, fault injection techniques are categorized as hardware-based, software-based, and simulation-based. Hardware-based fault injection techniques typically require hardware modifications, resulting in high costs and a degree of disruption. Software-based fault injection techniques often require modifying the software source code, which limits their effectiveness. Excessive modifications can alter the application software's operational logic, increasing the risk of introducing faults. Simulation-based fault injection, based on a simulation system, changes the target of fault injection from real hardware to the simulation system. This offers advantages such as flexibility, low development costs, and easy control of the injection process.

[0004] However, the fault injection capabilities of simulations are limited by the level and dimensions of hardware system simulation. Most simulation systems can only simulate a single layer, from the physical layer to the application layer. Consequently, fault injection can only be developed at that layer, with limited means. No mature system has yet been developed to enable multi-level fault injection into embedded software using a single simulation system. Furthermore, the credibility of fault injection results depends on the fidelity of the simulation program. Currently, the fidelity of existing simulation programs for fault injection is unsatisfactory, and the credibility of the results cannot be guaranteed. Summary of the Invention

[0005] In view of this, the present invention provides a fault injection method for a fully digital prototype based on QEMU to solve many problems in the current fault tolerance and reliability testing of embedded software, such as the easy occurrence of hardware damage, high cost, poor flexibility, and the lack of fault injection means in existing fault injection systems, the single injection level, and the low credibility of fault injection results.

[0006] The technical solution of the present invention:

[0007] A fault injection method for a fully digital digital prototype based on QEMU, used to perform fault injection on the fully digital digital prototype built based on QEMU to test the fault tolerance and reliability of embedded software;

[0008] The injection levels of the fault injection method include: atomic fault injection layer, composite fault injection layer and fault injection simulation test layer;

[0009] The atomic fault injection layer provides register faults, memory faults, bus protocol faults and bus load faults; the composite fault injection layer provides a complete expression of real hardware faults through different atomic fault combinations; the fault injection simulation test layer forms a set of fault injection test cases through different composite fault combinations.

[0010] Furthermore, the digital prototype is built based on the following methods:

[0011] Use QEMU technology to build a fully digital simulation prototype of the device under test to simulate the processor, peripherals, storage devices, and bus devices of the device under test, and set corresponding register fault injection interfaces, memory fault injection interfaces, bus protocol fault injection interfaces, and bus load fault injection interfaces for the above component models;

[0012] Then, a fault injection command parsing module is set up for the digital prototype to support the parsing of the fault injection commands and related parameters sent by the front end of the fault injection system, and to support the execution of corresponding fault injection operations.

[0013] Furthermore, the method of performing fault injection on the digital prototype is:

[0014] Connecting the digital prototype to the fault injection system front end, and configuring various parameters of the atomic fault, compound fault and fault simulation test case set in the fault injection system front end interface;

[0015] The front end packages the fault injection parameters into a fault injection command and sends it to the digital prototype; after receiving the fault injection command, the digital prototype back end parses it and selects the injection location and injection timing according to the corresponding configuration parameters to perform fault simulation on the target device.

[0016] Furthermore, the methods for testing the fault tolerance and reliability of embedded software are:

[0017] After the digital prototype completely executes the fault injection command, the registers, memory addresses, embedded application software output and embedded software logs of the digital prototype are checked to view the injection results, and the fault tolerance and reliability of the embedded software are analyzed based on the injection results.

[0018] Furthermore, atomic faults include multiple types. Each type of fault corresponds to a different fault injection location, and each type of fault includes multiple fault injection modes:

[0019] The injection timings of atomic faults include: instantaneous injection, periodic injection, random time injection, and feedback injection; atomic faults include different fault modes: register faults support set 0 / 1 faults, fixed 0 / 1 faults, bit flip faults, bit concatenation faults, and random value faults; memory faults support set 0 / 1 faults, fixed 0 / 1 faults, bit flip faults, and random value faults; bus protocol faults support frame replacement faults, frame deletion faults, frame truncation faults, CRC faults, and EOF faults; bus load faults support extreme value faults, device abnormality faults, device offline faults, and synchronization faults.

[0020] Furthermore, the injection timing is defined as follows:

[0021] Instantaneous injection: indicates that the fault is only valid at injection time T0;

[0022] Time period injection: indicates that the fault is only valid within the configured [T0, Tn] time period;

[0023] Permanent injection: indicates that the fault is valid within the configured [T0,∞) time period;

[0024] Periodic injection: Indicates that the fault is valid at the configured time points T0, T0+1*P, T0+2*P...T0+n*P

[0025] Feedback injection: indicates that the fault is valid when the feedback signal of the digital prototype is received;

[0026] Random time injection: indicates that the fault is valid at the configured time point T0 = Random();

[0027] Furthermore, the register fault is defined as follows:

[0028] According to the characteristics of register fault injection, the following register fault injection model is established. RFI represents a register fault injection model, and RFI can be expressed as:

[0029] RFI={id,dstDevice,dstReg,mode,trigerTime,value};

[0030] Memory failures are defined as follows:

[0031] According to the characteristics of memory fault injection, the following memory fault injection model is established. MFI represents a memory fault injection model, and MFI can be expressed as:

[0032] MFI={id,dstDevice,injectAdress,mode,trigerTime,value};

[0033] The register failure mode and memory failure mode are defined as follows:

[0034] Set 0 / 1 fault: Set certain bits of the specified register of the specified device to logic 0 or logic 1. The fault injection period is instantaneous, that is, the fault injection is valid, and the subsequent read and write functions of the register are normal;

[0035] Fixed 0 / 1 fault: The specified bits of the specified register of the specified device are fixed to logic 0 or logic 1. The fault takes effect within a fixed time period or is permanently valid. During the effective period, the fault bit of the register is fixed to the fault setting value. If it is not within the effective period, the read and write functions of the register are normal.

[0036] Bit flip fault: Sets certain bits of a specified register of a specified device to be flipped. The fault takes effect for a fixed period of time or permanently. During the effective period, when data is written to the fault bit of the register, the expected value of the fault bit is logic 0 but actually written to logic 1, and the expected value of the fault bit is logic 1 but actually written to logic 0. Outside the effective period, the read and write functions of the register are normal.

[0037] Random value fault: Sets certain bits of a specified register of a specified device to random values. The fault takes effect in the following periods: instantaneous, time period, permanent, periodic, and random. When reading data from the fault bit of the register during the fault effect period, the fault bit will be a random, uncertain value. Outside the effect period, the read and write functions of the register are normal.

[0038] Bit series fault: associates certain bits of a specified register of a specified device with the specified bits of other registers of the device. The fault takes effect instantaneously, within a certain period of time, permanently, periodically, or at a random time.

[0039] Furthermore, the bus protocol fault is defined as follows:

[0040] According to the characteristics of bus protocol fault injection, the following bus protocol fault injection model is established. BPFI represents a bus protocol fault injection model, and BPFI can be expressed as:

[0041] BPFI={id,busType,mode,trigerTime,frameContent};

[0042] The bus protocol failure modes are defined as follows:

[0043] Replace frame fault: replace the specified part of the original frame with the specified content;

[0044] Frame deletion fault: Delete the specified frame in the link;

[0045] Frame truncation fault: The original frame is truncated from the frame header to the set n offset bytes, and only the frame content before the offset is retained;

[0046] CRC failure: Change the CRC check field in the original frame to the specified content;

[0047] EOF failure: Change the EOF field in the original frame to the specified content.

[0048] Furthermore, the bus load fault is defined as follows:

[0049] According to the characteristics of bus load fault injection, the following bus load fault injection model is established. BDFI represents a bus load fault injection model, and BDFI can be expressed as:

[0050] BDFI={id,busType,mode,trigerTime,frameContent};

[0051] The bus load failure modes are defined as follows:

[0052] Extreme value fault: A fault caused by setting certain fields in the data payload field, which represent the operating parameters of the device, to values ​​that exceed the limit allowed for normal operation.

[0053] Device abnormal fault: Faults caused by setting certain fields in the data payload representing the device operating status to conditions inconsistent with normal operating conditions, such as performance degradation, malfunction, overvoltage, and overcurrent.

[0054] Device offline failure: The heartbeat field in the data payload field is set to a condition that does not match expectations, thus causing a failure.

[0055] Synchronization failure: The field in the data payload field that represents the device synchronization status is set to abnormal data, thereby causing a failure.

[0056] Furthermore, the method for building the digital prototype is specifically as follows:

[0057] The QOM mechanism is used in the device model to add fault injection interfaces for the CPU, peripherals, storage devices, and bus models. Specifically, register fault injection interfaces are added to DeviceClass: FII_Device_GetRegInfo, FII_Device_GetRegValue, and FII_Device_SetRegValue; memory fault injection interfaces are added to DeviceClass: FII_Device_GetMemInfo, FII_Device_GetMemValue, and FII_Device_SetMemValue; bus protocol fault injection interfaces are added to DeviceClass: FII_Bus_GetBusInfo and FII_Bus_ReceiveBusProtocolData; bus load fault injection interfaces are added to DeviceClass: FII_Bus_GetBusInfo and FII_Bus_ReceiveBusPayloadData; and corresponding interfaces are implemented in device models that need to implement corresponding functions, so that various models support fault injection functions.

[0058] Add a fault injection command parsing module for the digital prototype. Specifically, the QMP custom command is used to provide the full digital simulation digital prototype with the ability to receive and parse fault injection commands. The commands are divided into:

[0059] Register fault injection commands, including FICMD_DEVICE_GETREGINFO, FICMD_DEVICE_GETREGVALUE, and FICMD_DEVICE_SETREGVALUE;

[0060] Memory fault injection commands, including FICMD_DEVICE_GETMEMINFO, FICMD_DEVICE_GETMEMVALUE, and FICMD_DEVICE_SETMEMVALUE;

[0061] Bus protocol fault injection commands, including FICMD_BUS_GETBUSINFO and FICMD_BUS_RECEIVEBUSPROTOCOLDATA;

[0062] Bus load fault injection commands, including FICMD_BUS_GETBUSINFO and FICMD_BUS_RECEIVEBUSPAYLOADDATA;

[0063] System query commands, including FICMD_DEVICE_GETDEVICELIST, FICMD_DEVICE_GETMEMLIST, and FICMD_DEVICE_GETBUSLIST.

[0064] Beneficial effects of the present invention:

[0065] 1. The present invention uses a fully digital simulation digital prototype based on QEMU to implement a fault injection system. By utilizing the feature of QEMU that can fully digitally simulate the entire embedded computer hardware system, the feasibility of the simulation-based fault injection method and the credibility of the fault injection results are greatly improved.

[0066] 2. The present invention uses a simulated digital prototype to implement a fault injection system, which solves the shortcomings of hardware-based fault injection technology, such as easy hardware damage, high cost, poor flexibility and usability. It greatly reduces the cost of implementing the fault injection system and improves the flexibility and usability of fault injection.

[0067] 3. The present invention divides faults into three layers, supporting atomic fault injection design and management, composite fault design and management, and simulation fault injection use case set design and management, meeting users' fault injection needs at different levels and improving the efficiency of fault injection.

[0068] 4. The present invention provides a rich set of atomic fault injection methods, including register fault, memory fault, bus protocol fault, and bus load fault injection in four dimensions. Each dimension can select different target devices, fault modes, injection timing, duration, injection sequence, etc., greatly expanding and enriching the ways and methods of fault injection. BRIEF DESCRIPTION OF THE DRAWINGS

[0069] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0070] Attachment Figure 1 This is the overall architecture diagram of the fault injection system for the fully digital simulation digital prototype based on QEMU of the present invention;

[0071] Attachment Figure 2 is a classification diagram of the failure modes in the present invention;

[0072] Attachment Figure 3 It is a schematic diagram of the ICD interface file in the present invention and its role in bus protocol failure;

[0073] Attachment Figure 4is a schematic diagram of the DCD interface file and its role in bus load failure in the present invention;

[0074] Attachment Figure 5 It is a schematic diagram of the fault injection interface implementation of the all-digital simulation digital prototype based on QEMU in the present invention;

[0075] FIG6 is a flowchart of the fault command analysis of the full digital simulation digital prototype based on QEMU in the present invention, Figure 6a 、 Figure 6b as well as Figure 6c Spliced ​​into a whole picture; Figure 6b Upper side stitching Figure 6a The lower side, Figure 6c Left side splicing Figure 6b the right side;

[0076] Attachment Figure 7 is a flow chart of register fault injection of the present invention;

[0077] Attachment Figure 8 is a flow chart of memory fault injection of the present invention;

[0078] Attachment Figure 9 is a flow chart of bus protocol fault injection of the present invention;

[0079] Attachment Figure 10 is a flow chart of bus load fault injection of the present invention;

[0080] Attachment Figure 11 is a flow chart of the composite fault injection of the present invention;

[0081] Attachment Figure 12 It is a flow chart of the fault use case set injection of the present invention. DETAILED DESCRIPTION

[0082] The embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0083] The following describes the embodiments of the present disclosure through specific examples, and those skilled in the art can easily understand other advantages and effects of the present disclosure from the contents disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all of the embodiments. The present disclosure can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present disclosure.

[0084] It should be noted that various aspects of the embodiments within the scope of the appended claims are described below. It should be apparent that the aspects described herein can be embodied in a wide variety of forms, and any specific structure and / or function described herein is merely illustrative. Based on this disclosure, it should be understood by those skilled in the art that an aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects described herein can be used to implement an apparatus and / or practice a method. In addition, other structures and / or functionalities other than one or more of the aspects described herein can be used to implement this apparatus and / or practice this method.

[0085] It should also be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present disclosure. The illustrations only show components related to the present disclosure and are not drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component can be changed at will, and the component layout type may also be more complicated.

[0086] Additionally, in the following description, specific details are provided to provide a thorough understanding of the examples. However, one skilled in the art will appreciate that the aspects described can be practiced without these specific details.

[0087] In one embodiment of the present invention, a fault injection method for a fully digital prototype based on QEMU is proposed. The overall architecture is as follows: Figure 1 As shown, this embodiment takes a fully digital simulated digital prototype implemented based on QEMU as the injection target, and utilizes the feature of QEMU that can perform fully digital simulation of embedded hardware to implement three levels of atomic fault injection layer, composite fault injection layer and fault injection simulation test layer, and fault injection in four dimensions: register fault, memory fault, bus protocol fault and bus load fault. This effectively solves many problems of existing fault injection systems, such as the lack of fault injection means, single injection level and low credibility of fault injection results.

[0088] In this embodiment, fault injection is divided into the following four steps:

[0089] Step 1: Divide fault injection levels and failure modes

[0090] As attached Figure 2As shown, this embodiment divides fault injection into three layers according to the fault injection usage scenario, namely, the atomic fault injection layer, the composite fault injection layer and the fault injection simulation test layer. The atomic fault injection layer provides four types of atomic fault injections: register faults, memory faults, bus protocol faults, and bus load faults. The composite fault injection layer provides composite fault injections that can fully express a real hardware fault through different atomic fault combinations. The fault injection simulation test layer forms a set of fault injection test cases through different composite fault combinations.

[0091] 1.1 Atomic Fault Injection Layer

[0092] The atomic fault injection layer consists of four types of atomic fault injections: register fault injection, memory fault injection, bus protocol fault injection, and bus load fault injection. The atomic fault models in this layer are the basis for the system to represent various complex fault models. They represent the minimum granularity of fault injection in the fault injection system of the QEMU-based fully digital simulation digital prototype, and include the basic properties of the fault, defining key information such as the fault mode, fault injection location, injection timing, and injection content.

[0093] Among the four types of atomic fault injection, register fault injection and memory fault injection can directly target the underlying hardware model of the embedded system, thus corresponding to physical layer fault injection. Bus protocol fault injection targets data errors and interference during bus data transmission, thus corresponding to link layer and transport layer fault injection. Bus load fault injection can test embedded applications when receiving abnormal data such as extreme values ​​or errors, thus corresponding to application layer fault injection. This enables a single simulation system to perform fault injection on embedded software at multiple levels.

[0094] The four types of atomic fault injection have different fault modes, fault injection locations, and injection contents, but the definition of injection timing is the same. The atomic fault injection timing is defined as follows:

[0095] Instantaneous injection: Indicates that the fault is only valid at injection time T0.

[0096] Time period injection: Indicates that the fault is only valid within the configured [T0, Tn] time period.

[0097] Permanent injection: indicates that the fault is valid within the configured [T0,∞) time period.

[0098] Periodic injection: Indicates that the fault is valid at the configured time points T0, T0+1*P, T0+2*P...T0+n*P

[0099] Feedback injection: Indicates that the fault is valid when the feedback signal of the digital prototype is received.

[0100] Random time injection: Indicates that the fault is valid at the configured time point T0 = Random().

[0101] 1.1.1 Register Fault Injection

[0102] Registers are key components in embedded computer hardware. Within the CPU and various peripheral devices, registers play a crucial role in storing critical data, calculating intermediate results, controlling data flow and synchronization, configuring operating modes, and controlling interrupts. In actual hardware, registers often correspond to specific chip pins. Common hardware failures include abnormal states caused by desoldering, short circuits, and other factors, which can cause corresponding device failures. Hardware-based fault injection typically involves physically changing the state of the corresponding register pin or using the VHDL programming language to modify the chip pin state. However, with increasing chip integration, such methods are becoming increasingly difficult to implement. Fault injection in a fully digital simulation prototype based on QEMU relies on QEMU's fully digital simulation capabilities for embedded hardware devices. After modification, register fault injection interfaces can be directly called to access registers and perform read and write operations, achieving the desired register fault injection effect.

[0103] When modeling the CPU and components in a fully digital simulation prototype based on QEMU, all registers must be modeled as a tuple of {name, displayname, offset, length, regValue} according to the chip manual. The unified register fault injection read and write interface provided by the DeviceClass base class must be implemented to read and change register values. Based on the characteristics of register fault injection, the following register fault injection model is established. RFI represents a register fault injection model, and RFI can be expressed as:

[0104] RFI={id,dstDevice,dstReg,mode,trigerTime,value}

[0105] id: register fault injection ID, unique identifier of this operation;

[0106] dstDevice: The target device for register fault injection, which can be the CPU or peripheral components in a fully digital simulation digital prototype model;

[0107] dstReg: The target register for register fault injection, which can be any register of the target device;

[0108] mode: register fault injection mode, which can be one of the following: set 0 / 1 fault, fixed 0 / 1 fault, bit flip fault, bit cascade fault, and random value fault.

[0109] trigerTime: triggering time of register fault injection, which can be instantaneous injection, time period injection, permanent injection, periodic injection, feedback injection, or random time injection.

[0110] Value: The target value for register fault injection. This can be 0x00001111 or 0xmmmm1111. 0x00001111 means all 8 bits are injected, while 0xmmmm1111 means only the lower four bits are injected, leaving the upper four bits uninjected. m is the mask.

[0111] Register fault injection provides five fault modes: set 0 / 1 fault, fixed 0 / 1 fault, bit flip fault, bit cascade fault, and random value fault. Each fault mode is described below:

[0112] Set 0 / 1 fault: Sets specified bits of a specified register of a specified device to logic 0 or logic 1. The fault takes effect instantaneously, meaning that the fault injection is effective and subsequent read and write functions of the register remain normal.

[0113] Fixed 0 / 1 fault: The specified bits of the specified register of the specified device are fixed to logic 0 or logic 1. The fault takes effect within a fixed period of time or is permanently valid. During the effective period of the fault, the fault bit of the register is fixed to the fault setting value. If it is not within the effective period, the read and write functions of the register are normal.

[0114] Bit flip fault: Sets certain specified bits of a specified register of a specified device to be bit flipped. The fault takes effect for a fixed period of time or permanently. When data is written to the fault bit of the register during the fault effective period, the fault bit is actually written to logic 1 when expected to be written to logic 0, and is actually written to logic 0 when expected to be written to logic 1. The read and write functions of the register are normal outside the effective period.

[0115] Random value fault: Sets certain bits of a specified register of a specified device to random values. The fault takes effect instantaneously, within a certain period of time, permanently, periodically, or at a random time. When reading data from the fault bit of the register during the fault effect period, the fault bit is a random, uncertain value. Outside the effect period, the read and write functions of the register are normal.

[0116] Bit series fault: Associates certain bits of a specified register of a specified device with specified bits of other registers of the device. The fault takes effect instantaneously, within a certain period of time, permanently, periodically, or randomly. The associated fault bits are related. For example, if a bit series fault occurs between the lowest bit of RegA and the highest bit of RegB, writing a logic 1 to the lowest bit of RegA will modify the highest bit of RegB to a logic 1 regardless of its original value. The register's read and write functions are normal when the fault is not within the effective period.

[0117] 1.1.2 Memory Fault Injection

[0118] Storage devices in embedded systems are primarily used to store various types of information, whether long-term or temporary, for operating systems, applications, and user documents. In practice, they often suffer from physical damage or electromagnetic interference, leading to data read errors, data write errors, or even write failures. Hardware-based fault injection can only physically simulate such failures. However, a modified QEMU-based fully digital simulation prototype can directly call memory fault injection interfaces, access specific addresses on storage devices, and perform read and write operations on them, effectively injecting memory device faults.

[0119] When modeling storage devices in a QEMU-based fully digital simulation prototype, it is necessary to define the storage device attributes {name, displayname, startAddress, length} to complete the modeling. The unified memory fault injection read and write interface provided by the DeviceClass base class is implemented to read and change the value of the corresponding address of the storage device. Based on the characteristics of memory fault injection, the following memory fault injection model is established. MFI represents a memory fault injection model, and MFI can be expressed as:

[0120] MFI={id,dstDevice,injectAdress,mode,trigerTime,value}

[0121] id: memory fault injection ID, unique identifier of this operation;

[0122] dstDevice: target device for memory fault injection, which can be any storage device in the fully digital simulation digital prototype model;

[0123] injectAdress: the address of the memory fault injection, which can be any address of the target device, but must be within the range of {startAdress, startAdress+length} of the memory device;

[0124] mode: Memory fault injection mode, one of the following: set 0 / 1 fault, fixed 0 / 1 fault, bit flip fault, and random value fault.

[0125] trigerTime: triggering time of memory fault injection, which can be instantaneous injection, time period injection, permanent injection, periodic injection, feedback injection, or random time injection.

[0126] value: The target value for memory fault injection. This can be 0x00001111 or 0xmmmm1111. 0x00001111 means injecting all 8 bits, while 0xmmmm1111 means injecting only the lower four bits and omitting the upper four bits. m is the mask.

[0127] Memory fault injection provides four fault modes: set 0 / 1 fault, fixed 0 / 1 fault, bit flip fault, and random value fault. Each fault mode is defined as follows:

[0128] Set 0 / 1 fault: Set the value of the injectAddress address of the specified storage device to logic 0 or logic 1. The fault injection period is instantaneous, that is, the fault injection is valid, and the subsequent read and write functions of the injectAddress address are normal.

[0129] Fixed 0 / 1 fault: The value of the injectAddress address of the specified storage device is fixed to logic 0 or logic 1. The fault takes effect for a fixed period of time or permanently. During the effective period, the fault bit of the injectAddress address of the storage device is fixed to the fault setting value. Outside the effective period, the read and write functions of the injectAddress address are normal.

[0130] Bit flip fault: The value of the injectAddress address of the specified storage device is set to bit flip. The fault takes effect within a fixed period or permanently. During the fault effect period, when data is written to the fault bit of the injectAddress address of the storage device, the fault bit is actually written to logic 1 when it is expected to be written to logic 0, and to logic 0 when it is expected to be written to logic 1. Outside the effect period, the read and write functions of the injectAddress address are normal.

[0131] Random value fault: Sets the injectAddress address value of a specified storage device to a random value. The fault takes effect instantaneously, within a certain period of time, permanently, periodically, or at a random time. When reading data from the fault bit of the injectAddress address of the storage device during the fault effect period, the fault bit is a random, uncertain value. Outside the effect period, the read and write functions of the injectAddress address remain normal.

[0132] 1.1.3 Bus Protocol Fault Injection

[0133] Bus protocol faults are mainly used to detect the fault tolerance and reliability of embedded systems when facing bus protocol-related faults. This embodiment modifies the frame header and frame footer of the bus data frame, sends the fault data frame to the simulation target module, and detects whether the embedded software system can execute bus protocol exception handling processes such as alarm and line switching after receiving the bus protocol fault frame.

[0134] This embodiment mainly uses ICD (Interface Control Documents) to describe the bus frame format, and provides ICD interface definition documents for Ethernet, RS422A, RS485, CAN bus, 1553B, IEEE1394, and FC-AE.

[0135] The following frame field model is established based on the ICD definition format and the front-end display requirements. BP_ICD represents a bus protocol frame field model, so BP_ICD can be expressed as:

[0136] BP_ICD={id,enName,cnName,offset,length,type,valueEnum,defaultValue}

[0137] id: frame field ID, which is the unique identifier of the field in the corresponding bus protocol;

[0138] enName: English name of the frame field, used to display on the front-end interface of the fault injection system;

[0139] cnName: Chinese name of the frame field, used to display on the front-end interface of the fault injection system;

[0140] offset: frame field offset, used to construct a complete bus frame format.

[0141] Length: Frame field length, used to construct a complete bus frame format.

[0142] type: frame field type, which can be Boolean, integer, enumeration, floating point, etc.

[0143] valueEnum: frame field enumeration description. If the frame field type is enumeration, this field lists all values ​​and describes the meaning of each enumeration value.

[0144] defaultValue: The default fill value of the frame field, used to display the default value on the fault injection system front-end interface.

[0145] The usage process of the ICD interface control document in this embodiment is shown in the attached figure. Figure 3 As shown in the figure, before performing bus protocol fault injection, the ICD interface control document corresponding to the bus protocol needs to be imported. The fault injection system front end generates a bus protocol fault injection interface by parsing the ICD document. The interface will list all frame fields defined in the ICD. Each field supports fault injection. After filling in the fault value, the system front end will combine the ICD document and the fault injection value to generate the corresponding bus protocol fault injection data frame and send it to the fault injection system back end.

[0146] According to the characteristics of bus protocol fault injection, the following bus protocol fault injection model is established. BPFI represents a bus protocol fault injection model, and BPFI can be expressed as:

[0147] BPFI={id,busType,mode,trigerTime,frameContent}

[0148] id: bus protocol fault injection ID, unique identifier of this operation;

[0149] busType: The bus type for bus protocol fault injection. It can be one of common communication buses such as Ethernet, RS422A interface, RS485 interface, CAN bus interface, 1553B interface, FC-AE interface, etc. It must be consistent with the ICD definition and the bus device type in the fully digital simulation digital prototype.

[0150] mode: bus protocol fault injection mode, one of the following modes: frame replacement fault, frame deletion fault, frame truncation fault, CRC fault, and EOF fault.

[0151] trigerTime: The triggering time of bus protocol fault injection, which can be instantaneous injection, time period injection, permanent injection, periodic injection, feedback injection, or random time injection.

[0152] frameContent: The data frame content for bus protocol fault injection, including the complete frame header, data payload, and frame trailer.

[0153] Bus protocol fault injection provides five common bus protocol fault modes: replacement frame fault, deletion frame fault, truncation frame fault, CRC fault, and EOF fault. However, these modes can be expanded based on bus fault characteristics. The supported bus protocol fault modes are defined as follows:

[0154] Replace frame fault: Replace the specified part of the original frame with the specified content.

[0155] Frame deletion fault: Delete the specified frame in the link.

[0156] Frame truncation fault: The original frame is truncated from the frame header to the set n offset bytes, and only the frame content before the offset is retained.

[0157] CRC failure: Change the CRC check field in the original frame to the specified content.

[0158] EOF failure: Change the EOF field in the original frame to the specified content.

[0159] 1.1.4 Bus load fault injection

[0160] Bus load failure is mainly used to detect the fault tolerance and reliability of the embedded system when facing bus protocol related failures. This embodiment modifies the frame header and frame footer of the bus data frame, sends the fault data frame to the simulation target module, and detects whether the embedded software system can execute bus protocol exception processing processes such as alarm and line switching after receiving the bus protocol fault frame.

[0161] This embodiment primarily uses DCD (Data Control Documents) to describe the bus frame format. The content of a DCD data control document is agreed upon by both parties in data communication. This embodiment only provides a method for defining fields. Based on the DCD definition format and front-end display requirements, the following frame field model is established. BD_ICD represents a frame field model, and BD_ICD can be expressed as:

[0162] BD_ICD={id,enName,cnName,offset,length,type,valueEnum,defaultValue,minValue,maxValue}

[0163] id: payload field ID;

[0164] enName: English name of the load field, used to display on the front-end interface of the fault injection system;

[0165] cnName: The Chinese name of the payload field, which is displayed on the front-end interface of the fault injection system;

[0166] offset: Payload field offset, used to construct complete bus payload data.

[0167] Length: Payload field length, used to construct complete bus payload data.

[0168] type: payload field type, which can be Boolean, integer, enumeration, floating point, etc.

[0169] valueEnum: payload field enumeration description. If the payload field type is enumeration, this field lists all values ​​and explains the meaning of each enumeration value.

[0170] defaultValue: The default value filled in the payload field, used to display the default value on the fault injection system front-end interface.

[0171] minValue: payload field, used to display on the front-end interface of the fault injection system;

[0172] maxValue: Load field, used to display on the front-end interface of the fault injection system.

[0173] The usage process of the DCD interface control document in this embodiment is shown in the attached figure. Figure 4 As shown in the figure, before performing bus load fault injection, the DCD data control document and the ICD interface control document need to be imported. The fault injection system front end generates a bus complex fault injection interface by parsing the DCD data control document. The interface will list all load fields defined in the DCD, and each field supports fault injection. After filling in the fault value, the system front end will combine the ICD document, DCD document and fault injection value to generate the corresponding bus load fault injection data frame and send it to the fault injection system back end.

[0174] According to the characteristics of bus load fault injection, the following bus load fault injection model is established. BDFI represents a bus load fault injection model, and BDFI can be expressed as:

[0175] BDFI = {id, busType, mode, triggerTime, frameContent}; the meaning of each field is the same as that of bus protocol fault injection.

[0176] Bus protocol fault injection provides four common bus load failure modes: extreme value failure, device abnormality failure, device offline failure, and synchronization failure. However, these modes can be expanded based on load data characteristics. The supported bus load failure modes are defined as follows:

[0177] Extreme value fault: A fault is caused by setting certain fields in the data payload field representing equipment operating parameters (such as temperature, pressure, etc.) to exceed the limit allowed for normal operation;

[0178] Device abnormal failure: Certain fields in the data payload field that represent the device operating status are set to conditions that are inconsistent with the normal operating status, thereby causing failures such as performance degradation, malfunction, overvoltage, overcurrent, etc.

[0179] Device offline failure: The heartbeat field in the data payload field is set to a situation that does not meet expectations, thereby causing a failure.

[0180] Synchronization failure: The field in the data payload field that represents the device synchronization status is set to abnormal data, thereby causing a failure.

[0181] 1.2 Composite Fault Injection Layer

[0182] With the continuous advancement of science and technology, the scale and complexity of various systems, whether aerospace control systems or industrial automation production lines, are increasing dramatically. In actual operation, these systems may encounter multiple faults occurring simultaneously or multiple faults occurring in a specific order, causing system failures or failures. A single atomic-level fault injection method is difficult to simulate such complex situations, and it is difficult to meet the needs of comprehensively evaluating system reliability and fault tolerance.

[0183] The composite fault injection layer is designed to simulate real-world scenarios where multiple faults occur simultaneously or in a specific order, causing system failures or malfunctions. This fault injection layer supports the selection of different types of atomic faults and specifies the timing for injecting each atomic fault. Finally, it generates an atomic fault entry sequence based on the timing of each atomic fault injection to complete the injection of composite faults.

[0184] Since composite faults are ultimately composed of a series of atomic faults, the following composite fault injection model is established based on the characteristics of composite faults and atomic faults. CFI represents a composite fault injection model, and CFI can be expressed as:

[0185] CFI={CFI0{moduleID,atomFIID,trigerTime}....CFIn{moduleID,atomFIID,trigerTime}}

[0186] moduleID: the target module ID of the atomic fault injection;

[0187] atomFIID: the reference ID of the atomic fault injection;

[0188] TriggerTime: The triggering time for the atomic fault injection. This can be instantaneous, time-segmented, permanent, periodic, feedback, or random. The definitions for each injection time are the same as for atomic fault injection. The injection time for a single atomic fault injection in a composite fault injection is based on the trigerTime defined in the CFI, not the atomic fault injection's triggerTime.

[0189] 1.3 Fault Simulation Test Layer

[0190] The fault simulation test layer uses a suite of fault injection test cases to comprehensively and systematically evaluate the reliability and fault tolerance of embedded software. This suite consists of a composite fault injection sequence. Each composite fault injection case initializes a fully simulated digital prototype at the start of execution. Multiple composite fault injection cases run completely independently, with no sequential dependencies.

[0191] Step 2: Build a QEMU-based fully digital simulation prototype that supports fault injection

[0192] Fault injection techniques are divided into hardware-based fault injection, software-based fault injection, and simulation-based fault injection. Hardware-based fault injection techniques usually require the modification of hardware equipment, so the cost is high and it is somewhat destructive. Software-based fault injection techniques mostly require the modification of software source code, which makes this method have certain limitations. Excessive modifications may change the operating logic of the application software and increase the risk of introducing faults. Simulation-based fault injection is based on the simulation system. The fault injection target changes from real hardware to the simulation system. Therefore, it has the advantages of good flexibility, low development cost, and easy control of the injection process. However, the fault injection capability of this method depends entirely on the degree of realism of the simulation system to the hardware system. How to ensure the restoration degree of the simulation system to the hardware system has always been a key issue in whether this method can be applied to embedded software testing.

[0193] With the emergence of QEMU in recent years, simulation-based fault injection technology has seen a significant advancement. QEMU is a general-purpose, open-source full-system simulator that fully digitally simulates the entire embedded computer hardware system, including the processor, memory devices, storage, and peripherals. This fully modeled, fully digitally simulated digital prototype is capable of running a complete loop, supporting the normal operation of embedded operating systems, embedded drivers, and embedded application software on the fully digitally simulated prototype without any modifications. From the perspective of embedded software, QEMU accurately simulates every component of the embedded hardware, making it indistinguishable from running on real hardware.

[0194] However, the current version of QEMU does not provide any support for fault injection. Therefore, the QEMU-based fully digital simulation prototype needs to be modified to add fault injection capabilities. This modification is divided into two steps. First, fault injection interfaces are added to the CPU, peripherals, bus, and other models. This step mainly increases the model's ability to handle fault injection. Second, a module for receiving fault injection commands is added to the QEMU digital prototype. This step mainly increases the ability to receive and interpret fault injection commands.

[0195] 2.1 Model Support for Fault Injection

[0196] QEMU uses QOM (QEMU Object Model) to manage and organize various CPU, peripheral and bus models. All models are inherited from DeviceClass. Therefore, register fault injection (FII_Device_GetRegInfo, FII_Device_GetRegValue, FII_Device_SetRegValue), memory fault injection (FII_Device_GetMemInfo, FII_Device_GetMemValue, FII_Device_SetMemValue), bus protocol fault injection (FII_Bus_GetBusInfo, FII_Bus_ReceiveBusProtocolData) and bus load fault injection (FII_Bus_GetBusInfo, FII_Bus_ReceiveBusPayloadData) related interfaces are added to DeviceClass, and the corresponding interface logic is implemented in the device model that needs to implement the corresponding function. This can realize the support of various models for fault injection functions, as shown in the attached figure. Figure 5 As shown, the fault injection related interfaces and functions are shown in Table 1.

[0197] Table 1 Fault injection interface list

[0198]

[0199]

[0200] 2.2 Digital prototype supports fault injection command reception and parsing

[0201] The digital prototype fault injection interface module mainly provides the fully digital simulation digital prototype with the ability to receive and parse fault injection commands. The module uses the QMP (QEMU Monitor Protocol, QEMU interactive command protocol) command protocol to communicate data with the front end. QMP is a JSON-based interactive protocol provided by QEMU, allowing external tools or users to communicate with QEMU virtual machine instances in real time through a network connection. It defines a series of commands and corresponding response formats, allowing users to easily obtain virtual machine status information, control virtual machine operation, and perform various specific operations. The most important thing is that the QMP command protocol supports user extensions.

[0202] The commands are mainly divided into bus fault injection commands (FICMD_DEVICE_GETREGINFO, FICMD_DEVICE_GETREGVALUE, FICMD_DEVICE_SETREGVALUE), memory fault injection commands (FICMD_DEVICE_GETMEMINFO, FICMD_DEVICE_GETMEMVALUE, FICMD_DEVICE_SETMEMVALUE), bus protocol fault injection commands (FICMD_BUS_GETBUSINFO, FICMD_BUS_RECEIVEBUSPROTOCOLDATA), bus load fault injection commands (FICMD_BUS_GETBUSINFO, FICMD_BUS_RECEIVEBUSPAYLOADDATA) and system query commands (FICMD_DEVICE_GETDEVICELIST, FICMD_DEVICE_GETMEMLIST, FICMD_DEVICE_GETBUSLIST). The definitions of fault injection related commands are shown in Table 2.

[0203] Table 2 Definition of fault injection related commands

[0204]

[0205]

[0206] The command reception and parsing diagram of the digital prototype fault injection interface module is shown in Figure 6. The specific steps are as follows:

[0207] Step 2.2.1, start the full digital simulation prototype based on QEMU, and wait in a loop to receive the fault injection command;

[0208] Step 2.2.2: After receiving the fault injection command, the qmp_marshal_acoredp_request function forwards the QMP custom command received by QEMU and enters the custom command processing process qmp_acoredp_request;

[0209] Step 2.2.3: Parse the fault injection command ID and command parameters, and determine whether the command ID and parameters are valid;

[0210] Step 2.2.4: Go to the corresponding command processing branch according to the command ID (Table 2), otherwise go to step 2.2.X;

[0211] Step 2.2.5: Search for the device object based on the device name. If the device is found, proceed to step 2.2.6; otherwise, proceed to step 2.2.7.

[0212] Step 2.2.6: Call the interface of the device object corresponding to the command (see the "Fault Injection Command Name" column and the "Fault Injection Interface" column in Table 2 for the corresponding relationship) to complete the specified fault injection function;

[0213] Step 2.2.7. Return the fault injection result.

[0214] Step 2.2.8: Continue to wait for receiving the fault injection command and repeat steps 2.2.2 to 2.2.8.

[0215] Step 3: Perform fault injection

[0216] 3.1 Execution Register Fault Injection

[0217] The flowchart for executing register fault injection is shown in the attached figure. Figure 7 The specific steps are as follows:

[0218] Step 3.1.1, start the full digital simulation prototype based on QEMU;

[0219] Step 3.1.2: Configure the name, IP address, and fault injection port of the fully digital simulation prototype in the fault injection front-end interface.

[0220] Step 3.1.3: Connect the digital prototype. If the connection is successful, proceed to step 3.1.4; otherwise, proceed to step 3.1.2.

[0221] Step 3.1.4, select the atomic fault injection and register fault injection categories respectively;

[0222] Step 3.1.5. Open the device list and select the device to be injected.

[0223] Step 3.1.6. Open the register list and select the register to be injected in the device register list;

[0224] Step 3.1.7. Open the injection mode list and select the required fault injection mode in the injection mode list;

[0225] Step 3.1.8. Open the injection timing list interface, select the required injection timing in the injection timing list, and set the corresponding time parameters;

[0226] Step 3.1.9. Set the register fault injection value and click the Fault Injection button.

[0227] Step 3.1.10. Use QEMU commands or register view interface to view the fault injection results.

[0228] Step 3.1.11: If you need to add a register fault set, set the register fault injection ID and fault injection description and add it to the fault injection list;

[0229] Step 3.1.12: If the fault injection result does not meet expectations, repeat steps 3.1.4 to 3.1.10 until it meets expectations. Otherwise, close the connection and complete the register fault injection.

[0230] 3.2 Performing Memory Fault Injection

[0231] The flowchart for executing memory fault injection is shown in the attached figure. Figure 8 The specific steps are as follows:

[0232] Step 3.2.1, start the full digital simulation prototype based on QEMU;

[0233] Step 3.2.2: Configure the name, IP address, and fault injection port of the fully digital simulation prototype in the fault injection front-end interface.

[0234] Step 3.2.3: Connect the digital prototype. If the connection is successful, proceed to step 3.2.4; otherwise, proceed to step 3.2.2.

[0235] Step 3.2.4, select the atomic fault injection and memory fault injection categories respectively;

[0236] Step 3.2.5. Open the memory device list and select the memory device to be injected.

[0237] Step 3.2.6. Open the injection mode list and select the required fault injection mode in the injection mode list;

[0238] Step 3.2.7. Open the injection timing list interface, select the required injection timing in the injection timing list, and set the corresponding time parameters;

[0239] Step 3.2.8. Set the memory fault injection address and injection value, and click the Fault Injection button;

[0240] Step 3.2.9. Use QEMU commands or the memory viewing interface to view the fault injection results.

[0241] Step 3.2.10: If you need to add a memory fault set, set the ID and fault injection description of the memory fault injection and add it to the memory fault injection list;

[0242] Step 3.2.11: If the fault injection result does not meet expectations, repeat steps 3.2.4 through 3.2.9 until it meets expectations. Otherwise, close the connection and complete the memory fault injection.

[0243] 3.3 Performing Bus Protocol Fault Injection

[0244] The flowchart for executing bus protocol fault injection is shown in the attached figure. Figure 9 The specific steps are as follows:

[0245] Step 3.3.1, start the full digital simulation prototype based on QEMU;

[0246] Step 3.3.2: Configure the name, IP address, and fault injection port of the fully digital simulation prototype in the fault injection front-end interface.

[0247] Step 3.3.3. Connect the digital prototype. If the connection is successful, proceed to step 3.3.4; otherwise, proceed to step 3.3.2.

[0248] Step 3.3.4, select the atomic fault injection and bus protocol fault injection categories respectively;

[0249] Step 3.3.5. Open the bus device list and select the bus device to be injected in the bus device list;

[0250] Step 3.3.6. Select the ICD bus interface control document for the corresponding bus;

[0251] Step 3.3.7. Open the injection mode list and select the required fault injection mode in the injection mode list;

[0252] Step 3.3.8. Open the injection timing list interface, select the required injection timing in the injection timing list, and set the corresponding time parameters;

[0253] Step 3.3.9. Set the bus protocol fault injection parameters and click the Fault Injection button.

[0254] Step 3.3.10. Check the fault injection results.

[0255] Step 3.3.11: If a bus protocol fault set needs to be added, set the ID and fault injection description of the bus protocol fault injection and add it to the bus protocol fault injection list;

[0256] Step 3.3.12: If the fault injection result does not meet expectations, repeat steps 3.3.4 to 3.3.10 until it meets expectations. Otherwise, close the connection and complete the bus protocol fault injection.

[0257] 3.4 Performing Bus Load Fault Injection

[0258] The flowchart for executing bus load fault injection is shown in the attached figure. Figure 10 The specific steps are as follows:

[0259] Step 3.4.1, start the full digital simulation prototype based on QEMU;

[0260] Step 3.4.2: Configure the name, IP address, and fault injection port of the fully digital simulation prototype in the fault injection front-end interface.

[0261] Step 3.4.3: Connect the digital prototype. If the connection is successful, proceed to step 3.4.4; otherwise, proceed to step 3.4.2.

[0262] Step 3.4.4, select the atomic fault injection and bus load fault injection categories respectively;

[0263] Step 3.4.5. Open the bus device list and select the bus device to be injected in the bus device list;

[0264] Step 3.4.6. Select the ICD bus interface control document for the corresponding bus;

[0265] Step 3.4.7. Select the DCD bus data control document for the corresponding bus;

[0266] Step 3.4.8. Open the injection mode list and select the required fault injection mode in the injection mode list;

[0267] Step 3.4.9. Open the injection timing list interface, select the required injection timing in the injection timing list, and set the corresponding time parameters;

[0268] Step 3.4.10. Set the bus load fault injection parameters and click the Fault Injection button.

[0269] Step 3.4.11. Check the fault injection results.

[0270] Step 3.4.12: If a bus load fault set needs to be added, set the ID and fault injection description of the bus load fault injection and add it to the bus load fault injection list;

[0271] Step 3.4.13: If the fault injection result does not meet expectations, repeat steps 3.4.4 through 3.4.11 until it meets expectations. Otherwise, close the connection and complete the bus protocol fault injection.

[0272] 3.5 Performing Composite Fault Injection

[0273] The flowchart for executing composite fault injection is shown in the attached figure. Figure 11 The specific steps are as follows:

[0274] Step 3.5.1, start the full digital simulation prototype based on QEMU;

[0275] Step 3.5.2: Configure the name, IP address, and fault injection port of the fully digital simulation prototype in the fault injection front-end interface.

[0276] Step 3.5.3: Connect the digital prototype. If the connection is successful, proceed to step 3.5.4; otherwise, proceed to step 3.5.2.

[0277] Step 3.5.4. Select the composite fault injection category.

[0278] Step 3.5.5: Check whether to inject register fault. If yes, proceed to step 3.5.6; otherwise, proceed to step 3.5.7.

[0279] Step 3.5.6. Open the register fault injection set, select the required fault, and configure the register fault injection parameters;

[0280] Step 3.5.7: Check whether to inject memory fault. If yes, proceed to step 3.5.8; otherwise, proceed to step 3.5.9.

[0281] Step 3.5.8. Open the memory fault injection set, select the required fault, and configure the memory fault injection parameters;

[0282] Step 3.5.9: Check whether to inject a bus protocol fault. If yes, proceed to step 3.5.10; otherwise, proceed to step 3.5.11.

[0283] Step 3.5.10. Open the bus protocol fault injection set, select the required fault, and configure the bus protocol fault injection parameters;

[0284] Step 3.5.11: Check whether to inject bus load fault. If yes, proceed to step 3.5.12; otherwise, proceed to step 3.5.13.

[0285] Step 3.5.12. Open the bus load fault injection set, select the required fault, and configure the bus load injection parameters;

[0286] Step 3.5.13. Open the injection timing list interface, select the required injection timing in the injection timing list, and set the corresponding time parameters;

[0287] Step 3.5.14: Check whether the atomic fault has been added. If so, proceed to step 3.5.15. Otherwise, repeat steps 3.5.5 to 3.5.13.

[0288] Step 3.5.15. Click the Fault Injection button to view the fault injection results.

[0289] Step 3.5.16: If you need to add a composite fault set, set the composite fault injection ID and fault injection description and add it to the composite fault injection list;

[0290] Step 3.5.17: If the fault injection result does not meet expectations, repeat steps 3.5.4-3.5.15 until it meets expectations. Otherwise, close the connection and complete the bus protocol fault injection.

[0291] 3.6 Execute Fault Test Case Injection

[0292] The flowchart for executing the fault test case set injection is as shown in the attached Figure 12 The specific steps are as follows:

[0293] Step 3.6.1. Select the simulation test fault case set to be injected;

[0294] Step 3.6.2. Open the composite fault set and select the required composite fault;

[0295] Step 3.6.3: Check whether the compound fault addition is complete. If not, repeat step 3.6.2; otherwise, proceed to step 3.6.4.

[0296] Step 3.6.4: After adding the compound fault, perform the simulation test fault case set injection;

[0297] Step 3.6.5. Check the fault injection results.

[0298] Step 3.6.6, save the fault use case set and the running results;

[0299] Step 4: Collection and display of injection results

[0300] After the fully digital simulation digital prototype executes the fault injection command, the injection results can be viewed by checking the registers, memory addresses, embedded application software outputs, embedded software logs, etc. of the fully digital simulation digital prototype to analyze the fault tolerance and reliability of the embedded software.

[0301] Through the above four steps, this embodiment uses a fully digital simulated digital prototype based on QEMU as the injection target, improving the credibility of the fault injection results. By providing three levels and four dimensions of fault injection and a rich set of fault injection methods, it improves the fault tolerance and reliability of embedded software and improves its testing efficiency. The specific improvements are mainly reflected in the following four aspects:

[0302] 1. This embodiment uses a fully digital simulation digital prototype based on QEMU to implement a fault injection system. By utilizing the feature of QEMU that can fully digitally simulate the entire embedded computer hardware system, the feasibility of the simulation-based fault injection method and the credibility of the fault injection results are greatly improved.

[0303] 2. This embodiment uses a simulated digital prototype to implement the fault injection system, which solves the shortcomings of hardware-based fault injection technology, such as easy hardware damage, high cost, poor flexibility and usability. It greatly reduces the cost of implementing the fault injection system and improves the flexibility and usability of fault injection.

[0304] 3. This embodiment divides faults into three layers, supporting atomic fault injection design and management, composite fault design and management, and simulation fault injection use case set design and management, to meet users' fault injection needs at different levels and improve the efficiency of fault injection.

[0305] 4. This embodiment provides a rich set of atomic fault injection methods, including register fault, memory fault, bus protocol fault, and bus load fault injection in four dimensions. Each dimension can select different target devices, fault modes, injection timing, duration, injection sequence, etc., greatly expanding and enriching the ways and methods of fault injection.

[0306] The above description is only used to illustrate the technical solution of this embodiment, rather than to limit it. For ordinary professional and technical personnel in this field, the specific technical solution recorded in the above implementation can be modified, or some of the technical features therein can be replaced by equivalents. These modifications or replacements do not cause the essence of the corresponding technical solution to deviate from the scope of the technical solution protected by this embodiment.

[0307] The above description is merely a specific embodiment of the present disclosure, but the scope of protection of the present disclosure is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this disclosure should be included in the scope of protection of the present disclosure. Therefore, the scope of protection of the present disclosure should be based on the scope of protection of the claims.

Claims

1. A fault injection method for a fully digital prototype based on QEMU, characterized in that: Used to perform fault injection on the fully digital digital prototype built based on QEMU to test the fault tolerance and reliability of the embedded software; The digital prototype is built in the following way: using QEMU technology to build a full digital simulation digital prototype of the device under test, realizing the simulation of the processor, peripherals, storage devices and bus devices of the device under test, and setting corresponding register fault injection interfaces, memory fault injection interfaces, bus protocol fault injection interfaces and bus load fault injection interfaces for the component models; Then, a fault injection command parsing module is set up for the digital prototype to support parsing the fault injection commands and related parameters sent by the fault injection system front end, and to support the execution of corresponding fault injection operations; The injection levels of the fault injection method include: atomic fault injection layer, composite fault injection layer and fault injection simulation test layer; The atomic fault injection layer provides register faults, memory faults, bus protocol faults, and bus load faults; the composite fault injection layer provides a complete representation of real hardware faults through different atomic fault combinations; the fault injection simulation test layer forms a set of fault injection test cases through different composite fault combinations; There are many types of atomic faults. Each type of fault corresponds to a different fault injection location, and each type of fault includes multiple fault injection modes. The injection timings of atomic faults include: instantaneous injection, periodic injection, random time injection, and feedback injection; atomic faults include different fault modes: register faults support set 0 / 1 faults, fixed 0 / 1 faults, bit flip faults, bit concatenation faults, and random value faults; memory faults support set 0 / 1 faults, fixed 0 / 1 faults, bit flip faults, and random value faults; bus protocol faults support frame replacement faults, frame deletion faults, frame truncation faults, CRC faults, and EOF faults; bus load faults support extreme value faults, device abnormality faults, device offline faults, and synchronization faults.

2. The fault injection method for a QEMU-based all-digital prototype according to claim 1, characterized in that: The fault injection method for the digital prototype is as follows: Connecting the digital prototype to the fault injection system front end, and configuring various parameters of the atomic fault, compound fault and fault simulation test case set in the fault injection system front end interface; The front end packages the fault injection parameters into a fault injection command and sends it to the digital prototype; After receiving the fault injection command, the digital prototype backend parses it and selects the injection location and injection timing according to the corresponding configuration parameters to perform fault simulation on the target device.

3. The fault injection method for a QEMU-based all-digital prototype according to claim 2, characterized in that: The ways to test the fault tolerance and reliability of embedded software are: After the digital prototype completely executes the fault injection command, the registers, memory addresses, embedded application software output and embedded software logs of the digital prototype are checked to view the injection results, and the fault tolerance and reliability of the embedded software are analyzed based on the injection results.

4. The fault injection method for a QEMU-based all-digital prototype according to claim 1, characterized in that: The injection timing is defined as follows: Instantaneous injection: indicates that the fault is only valid at injection time T0; Time period injection: indicates that the fault is only valid within the configured [T0, Tn] time period; Permanent injection: indicates that the fault is valid within the configured [T0,∞) time period; Periodic injection: indicates that the fault is valid at the configured time points T0, T0+1*P, T0+2*P, ..., T0+n*P; Feedback injection: indicates that the fault is valid when the feedback signal of the digital prototype is received; Random time injection: Indicates that the fault is valid at the configured time point T0=Random().

5. The fault injection method for a QEMU-based all-digital prototype according to claim 4, characterized in that: Register faults are defined as follows: According to the characteristics of register fault injection, the following register fault injection model is established. RFI represents a register fault injection model, and RFI can be expressed as: RFI={id, dstDevice, dstReg, mode, trigerTime, value}; Memory failures are defined as follows: According to the characteristics of memory fault injection, the following memory fault injection model is established. MFI represents a memory fault injection model, and MFI can be expressed as: MFI={id, dstDevice, injectAdress, mode, trigerTime, value}; The register failure mode and memory failure mode are defined as follows: Set 0 / 1 fault: Set certain bits of the specified register of the specified device to logic 0 or logic 1. The fault injection period is instantaneous, that is, the fault injection is valid, and the subsequent read and write functions of the register are normal; Fixed 0 / 1 fault: The specified bits of the specified register of the specified device are fixed to logic 0 or logic 1. The fault takes effect within a fixed time period or is permanently valid. During the effective period, the fault bit of the register is fixed to the fault setting value. If it is not within the effective period, the read and write functions of the register are normal. Bit flip fault: Sets certain bits of a specified register of a specified device to be flipped. The fault takes effect for a fixed period of time or permanently. During the effective period, when data is written to the fault bit of the register, the expected value of the fault bit is logic 0 but actually written to logic 1, and the expected value of the fault bit is logic 1 but actually written to logic 0. Outside the effective period, the read and write functions of the register are normal. Random value fault: Sets certain bits of a specified register of a specified device to random values. The fault takes effect in the following periods: instantaneous, time period, permanent, periodic, and random. When reading data from the fault bit of the register during the fault effect period, the fault bit will be a random, uncertain value. Outside the effect period, the read and write functions of the register are normal. Bit series fault: associates certain bits of a specified register of a specified device with the specified bits of other registers of the device. The fault takes effect instantaneously, within a certain period of time, permanently, periodically, or at a random time.

6. The fault injection method for a QEMU-based all-digital prototype according to claim 5, characterized in that: The definition of bus protocol fault is as follows: According to the characteristics of bus protocol fault injection, the following bus protocol fault injection model is established. BPFI represents a bus protocol fault injection model, and BPFI can be expressed as: BPFI={id, busType, mode, trigerTime, frameContent}; The bus protocol failure modes are defined as follows: Replace frame fault: replace the specified part of the original frame with the specified content; Frame deletion fault: Delete the specified frame in the link; Frame truncation fault: The original frame is truncated from the frame header to the set n offset bytes, and only the frame content before the offset is retained; CRC failure: Change the CRC check field in the original frame to the specified content; EOF failure: Change the EOF field in the original frame to the specified content.

7. The fault injection method for a QEMU-based all-digital prototype according to claim 6, characterized in that: A bus load fault is defined as follows: According to the characteristics of bus load fault injection, the following bus load fault injection model is established. BDFI represents a bus load fault injection model, and BDFI can be expressed as: BDFI={id, busType, mode, trigerTime, frameContent}; The bus load failure modes are defined as follows: Extreme value fault: A fault caused by setting certain fields in the data payload field, which represent the operating parameters of the device, to values ​​that exceed the limit allowed for normal operation. Device abnormal fault: Faults caused by setting certain fields in the data payload representing the device operating status to conditions inconsistent with normal operating conditions, such as performance degradation, malfunction, overvoltage, and overcurrent. Device offline failure: The heartbeat field in the data payload field is set to a condition that does not match expectations, thus causing a failure. Synchronization failure: The field in the data payload field that represents the device synchronization status is set to abnormal data, thereby causing a failure.

8. The fault injection method for a QEMU-based all-digital prototype according to claim 7, characterized in that: The method for building the digital prototype is specifically as follows: The QOM mechanism is used in the device model to add fault injection interfaces for the CPU, peripherals, storage devices, and bus models. Specifically, register fault injection interfaces are added to DeviceClass: FII_Device_GetRegInfo, FII_Device_GetRegValue, and FII_Device_SetRegValue; memory fault injection interfaces are added to DeviceClass: FII_Device_GetMemInfo, FII_Device_GetMemValue, and FII_Device_SetMemValue; bus protocol fault injection interfaces are added to DeviceClass: FII_Bus_GetBusInfo and FII_Bus_ReceiveBusProtocolData; bus load fault injection interfaces are added to DeviceClass: FII_Bus_GetBusInfo and FII_Bus_ReceiveBusPayloadData; and corresponding interfaces are implemented in device models that need to implement corresponding functions, so that various models support fault injection functions. Add a fault injection command parsing module for the digital prototype. Specifically, the QMP custom command is used to provide the full digital simulation digital prototype with the ability to receive and parse fault injection commands. The commands are divided into: Register fault injection commands, including FICMD_DEVICE_GETREGINFO, FICMD_DEVICE_GETREGVALUE, and FICMD_DEVICE_SETREGVALUE; memory fault injection commands, including FICMD_DEVICE_GETMEMINFO, FICMD_DEVICE_GETMEMVALUE, and FICMD_DEVICE_SETMEMVALUE; Bus protocol fault injection commands, including FICMD_BUS_GETBUSINFO and FICMD_BUS_RECEIVEBUSPROTOCOLDATA; Bus load fault injection commands, including FICMD_BUS_GETBUSINFO and FICMD_BUS_RECEIVEBUSPAYLOADDATA; System query commands, including FICMD_DEVICE_GETDEVICELIST, FICMD_DEVICE_GETMEMLIST, and FICMD_DEVICE_GETBUSLIST.

Images