Software fault tolerance confirmation method based on fault injection

Abstract

The invention provides a software fault tolerance confirmation method based on fault injection, which comprises the following steps of: classifying software fault modes, including software operation faults and task scene faults, according to the structure, operation control logic and environment dependency relationship of a software system; constructing a software fault injection scene model, and performing fault injection on tested software in combination with an interface test technology, program code variation, interactive behavior variation or a manual injection method; executing the multi-stage test case, and collecting system behavior data after fault injection in real time through a log capture module; and based on the fault detection rate, the fault isolation rate and the fault recovery time index, combining a Monte Carlo simulation method to evaluate the task completion probability of the software in the task scene, and generating a fault-tolerant capability comprehensive evaluation report. According to the technical scheme, by manually generating the fault and introducing the fault into the target software system, the feedback information after the injection fault of the target system is monitored and analyzed, and the purposes of improving the reliability of the software fault-tolerant system and the like are achieved.

Description

Technical Field

[0001] The present invention belongs to the technical field of software testing, and in particular relates to a software fault-tolerance confirmation method based on fault injection. Background Art

[0002] Software fault injection is an effective method for testing software fault-tolerance mechanisms. By artificially introducing faults into a target software system, it forces the target system to manifest potential faults and defects. By monitoring and analyzing the feedback information generated after the injected fault occurs in the target system, the reliability of the software fault-tolerance system can be evaluated and the defects of the fault-tolerance mechanism exposed.

[0003] Fault-tolerant software code is difficult to test using conventional methods. For example, a function signature is void foo(FILE*), and its parameter is a file pointer. Its function is to perform IO operations on a file. The function can determine whether the file pointer is valid at the beginning of the function. If it is a valid pointer, the file is read or written. However, during the file reading or writing process, the file may be accidentally removed (forced unlocking or hardware unplugging). In this case, the function still believes that the pointer parameter is normal, and continued execution is likely to cause an exception. Under this premise, white-box testing using non-fault injection methods (which can input a normal pointer or a null pointer) and black-box testing (which can select a valid file or input an invalid file name) cannot achieve the aforementioned effect. Although static code modification, dynamic hardware plugging and unplugging, or system forced unlocking can also achieve this, the former requires recompilation each time, and the latter may damage the hardware or fail to reproduce the fault every time.

[0004] Therefore, how to provide a software fault tolerance confirmation method based on fault injection, which aims to improve software code coverage by artificially generating faults and introducing them into the target software system, monitoring and analyzing the feedback information after the injected faults occur in the target system, etc., has become a technical problem that needs to be solved urgently. Summary of the Invention

[0005] The embodiment of the present invention provides a software fault-tolerance confirmation method based on fault injection, which can artificially generate faults and introduce them into the target software system, monitor and analyze the feedback information after the injected fault occurs in the target system, and improve the reliability of the software fault-tolerant system.

[0006] In one embodiment of the present invention, a method for confirming software fault tolerance based on fault injection is provided, comprising:

[0007] S101. Classify software failure modes based on failure mode and impact analysis according to the software system's structure, operational control logic, and environmental dependencies. The classification includes software operation failures and task scenario failures. Software operation failures are identified through static code analysis and dynamic execution path tracing. Task scenario failures are extracted by simulating hardware anomalies, network fluctuations, and human-computer interaction error scenarios in a real environment.

[0008] S102. Construct a software fault injection scenario model based on four elements: fault injection method, fault injection location, fault injection time, and fault injection data; the fault injection method simulates the sequential logic of fault occurrence using a Markov chain model, and the fault injection location is dynamically allocated using a memory address randomization algorithm; the model combines interface testing technology, program code mutation, interactive behavior mutation, or manual injection methods to inject faults into the software under test;

[0009] S103. Execute multi-stage test cases including unit level, integration level and system level, and collect system behavior data after fault injection in real time through the log capture module; based on the fault detection rate, fault isolation rate and fault recovery time indicators, combine the Monte Carlo simulation method to evaluate the software's task completion probability in the task scenario, and generate a comprehensive evaluation report on fault tolerance.

[0010] Furthermore, the software operation type failures include at least: memory leak failures, null pointer reference failures, array out-of-bounds failures, illegal calculation failures, data assignment type mismatch failures, incomplete or overlapping judgment condition failures, functional failures and at least one of the software communication interface types.

[0011] Furthermore, the fault injection mode includes: a waiting mode and an impact mode;

[0012] In the waiting mode, the total number of fault injections is set to N, and each time a fault is injected at a random location for a preset time T. If the software fails, the current injection is terminated and the next injection is started;

[0013] The impact method sets the total number of fault injection rounds M, and injects n different faults continuously at random positions in each round. If the software fails, the current round is terminated and the next round of injection begins.

[0014] Furthermore, the fault injection time is ensured to be consistent with the actual environmental disturbance through a timestamp synchronization mechanism, and a sliding window algorithm is used to analyze the impact of fault propagation delay on system stability.

[0015] Furthermore, the fault injection time generates a random waiting time Tr after each fault injection round to simulate the randomness of environmental faults; the fault injection location is a random address of the register space, data storage space or memory space of the system under test.

[0016] Furthermore, a software fault injection scenario model is constructed, and the GDB debugger is used in combination with remote debugging scripts to automatically inject runtime faults, including:

[0017] Deploy GDB on the host and write fault injection test scripts;

[0018] Deploy GDB Server and the software under test on the target machine;

[0019] Through GDB remote debugging, the script is converted into fault injection instructions in the address space or register space of the software under test.

[0020] Furthermore, the fault injection location is a random address in the register space, data storage space or memory space of the system under test. The fault injection location dynamically identifies the memory address of the critical code segment through symbolic execution technology, and simulates the data bit flip fault of the register space in combination with hardware virtualization technology.

[0021] Furthermore, the software fault injection method for interface data faults analyzes software cross-linking interface faults and communication faults, designs an interface fault simulation operator, executes tests by injecting faults into the interface, detects errors in the node software, and evaluates the test adequacy of the node software based on the cross-linking interface, message coverage, fault coverage, and test results.

[0022] Interface data fault simulation designs a data fault injection operator based on the cross-link interface fault type and message type. The value of the field in the mutated message includes at least one of message field value replacement, blanking, bit flipping, message field integer, floating point, Boolean, character type unconventional value, error message type identifier, and error message length.

[0023] Communication fault simulation designs a communication fault injection operator based on the type of communication fault, the interaction behavior between the software and the peripheral cross-linking devices or subsystems. The communication error injection operator is designed based on the interaction behavior analysis between the node under test and the peripheral devices, by changing the interaction relationship, interaction process and interaction time, and injecting communication faults.

[0024] Furthermore, a fault-type fault injection method is run, and fault simulation is implemented using the GDP debugger simulation method; wherein, a test script based on the GDB debugger is combined with the GDB remote debugging method to implement fault injection and automatically control the fault process. According to the adopted GDB-based remote fault injection debugging structure, GDB is deployed on the host, and a fault injection test script file is written on the host; the GDB Server and the software to be fault-injected are deployed on the target machine. After GDB and GDBServer are connected, the host sends the test script file to the target machine, and the GDB Server of the target machine parses the test script file and converts the GDB script commands into the address space of the software under test or the register space of the target machine for fault injection; wherein, the script defines the sequence of fault execution and automatic control information. The debugger loads the script to execute the instruction sequence at each breakpoint, and then calls the given control information to automatically release the program, thereby realizing complete automated fault injection.

[0025] Furthermore, the software fault injection method for platform environment faults and human-machine operation faults uses unconventional operations, incorrect operations, and rapid operations to test the robustness of the interface, and tests the detection ability and prompt conditions of incorrect operation processes, incorrect commands or illegal data inputs on the interface;

[0026] Among them, faults are injected into the target levels of memory and CPU to simulate faults in the running environment; according to the memory and CPU fault models, memory and CPU faults are injected by obtaining the memory address space and CPU register address of the program, and the response of the program after the fault injection is observed to realize the external fault injection test of the software system; for the device status message transmitted using the interface data class, the corresponding status is a fault, etc., and the system status type fault is simulated. The status information of the main weapon system and sensor is sent through the simulation tool to check whether the software supports the correct display of the status information of the weapon system and sensor in the form of icons and table pages; whether it supports the common graphics and color identification and text prompts of each device to display the status of each device.

[0027] The beneficial effects brought about by the present invention are as follows:

[0028] As can be seen from the above scheme, the embodiment of the present invention provides a software fault tolerance confirmation method based on fault injection. According to the structure, operation control logic and environmental dependency of the software system, the software fault mode is classified based on fault mode and impact analysis, and the classification includes software operation type faults and task scenario type faults; a software fault injection scenario model is constructed, and the model is based on four-dimensional elements: fault injection method, fault injection location, fault injection time and fault injection data; the model combines interface testing technology, program code mutation, interaction behavior mutation or manual injection method to inject faults into the tested software; executes multi-stage test cases including unit level, integration level and system level, and collects system behavior data after fault injection in real time through the log capture module; based on the fault detection rate, fault isolation rate and fault recovery time indicators, the Monte Carlo simulation method is combined to evaluate the task completion probability of the software in the task scenario, and generate a comprehensive fault tolerance evaluation report. The technical solution of the present invention can improve the reliability of the software fault tolerance system by artificially generating faults and introducing them into the target software system, monitoring and analyzing the feedback information after the injected fault occurs in the target system, etc. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 This is a flow chart of a software fault tolerance confirmation method based on fault injection according to an embodiment of the present invention;

[0030] Figure 2 A schematic diagram of a software fault injection scenario model illustrating a software fault tolerance confirmation method based on fault injection according to an embodiment of the present invention. DETAILED DESCRIPTION

[0031] To make the objectives, technical solutions, and advantages of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0032] Software fault injection artificially introduces faults into a target software system, forcing it to manifest potential faults and defects. The feedback from the injected faults can be monitored and analyzed, thereby evaluating the reliability of the software's fault-tolerant system, exposing flaws in its fault-tolerant mechanisms, and improving software code coverage. As a supplement to traditional software testing methods, software fault injection focuses on testing the target software's response to abnormal conditions. Therefore, evaluating fault-tolerant mechanisms through software fault injection is essential during the software testing process.

[0033] To confirm qualitative software reliability requirements, software fault injection techniques are used to verify fault tolerance, stability, and other requirements. As an unconventional testing technique, software fault injection involves intentionally introducing faults based on a selected fault model. This method then applies specific faults to the system under test, accelerating the occurrence of errors and failures in the system under test. By analyzing the system's behavioral responses after the faults are introduced, the software's reliability and fault tolerance capabilities can be confirmed.

[0034] like Figure 1 As shown, Figure 1 This is a flow chart of a software fault tolerance confirmation method based on fault injection according to an embodiment of the present invention.

[0035] Figure 1 A software fault tolerance confirmation method based on fault injection includes:

[0036] S101. Classify software failure modes based on failure mode and impact analysis according to the software system's structure, operational control logic, and environmental dependencies. The classification includes software operation failures and task scenario failures. Software operation failures are identified through static code analysis and dynamic execution path tracing. Task scenario failures are extracted by simulating hardware anomalies, network fluctuations, and human-computer interaction error scenarios in a real environment.

[0037] S102. Construct a software fault injection scenario model based on four elements: fault injection method, fault injection location, fault injection time, and fault injection data; the fault injection method simulates the sequential logic of fault occurrence using a Markov chain model, and the fault injection location is dynamically allocated using a memory address randomization algorithm; the model combines interface testing technology, program code mutation, interactive behavior mutation, or manual injection methods to inject faults into the software under test;

[0038] S103. Execute multi-stage test cases including unit level, integration level and system level, and collect system behavior data after fault injection in real time through the log capture module; based on the fault detection rate, fault isolation rate and fault recovery time indicators, combine the Monte Carlo simulation method to evaluate the software's task completion probability in the task scenario, and generate a comprehensive evaluation report on fault tolerance.

[0039] In an embodiment of the present invention, a fault injection-based software fault tolerance validation method analyzes software fault modes based on the software system's software structure, operational control, and operating environment, including software runtime faults and task scenario-related faults. Software fault modes are classified into interface faults, operational faults, communication faults, and network faults, and fault tolerance requirements are proposed. A software fault injection scenario model is established. Based on fault tolerance criteria and in conjunction with software fault injection methods, fault injection is performed on the object under test. The software fault injection model includes the software fault injection method, fault injection location, fault injection time, and fault injection data. Based on the software fault injection model, various software fault injection methods are implemented using interface testing techniques, program code mutations, interaction behavior mutations, and manual injection. Test cases are then executed, data is collected, and fault tolerance is evaluated. Based on research on a fault injection-based software fault tolerance validation test case design method, test cases are executed, statistical data is collected, and software fault detection and isolation rates are derived to evaluate the software's fault tolerance. Simulating random fault interference in the task scenario confirms whether the software's task capability in the task scenario meets the task requirements.

[0040] In one embodiment of the present invention, the software operation type failure includes at least: memory leak failure, null pointer reference failure, array out-of-bounds failure, illegal calculation failure, data assignment type mismatch failure, incomplete or overlapping judgment condition failure, functional failure and at least one of the software communication interface types.

[0041] A software fault model, also known as a software modeled fault, abstracts fault characteristics and represents a typical fault type. A software fault model can reveal the patterns in program fault occurrence. Depending on the location of the fault, software fault patterns can be analyzed by looking at software operation control, software interfaces, and the software operating environment. Table 1 shows the classification and description of software faults.

[0042] Table 1 Software fault classification and description

[0043]

[0044] like Figure 2 As shown, Figure 2 A schematic diagram of a software fault injection scenario model illustrating a software fault tolerance confirmation method based on fault injection according to an embodiment of the present invention.

[0045] Figure 2In this paper, according to the software fault mode, the fault-induced behavior and data are described, and a software fault injection scenario model is established. According to the 4W analysis method, the software fault injection model includes four elements: fault injection behavior (InjectBehavior), fault injection location (Inject Location), fault injection time (Inject Time), and fault injection data (Inject Data).

[0046] In one embodiment of the present invention, the fault caused by the actual environmental disturbance may be a long-lasting disturbance or a multiple instantaneous disturbance. The fault injection method includes: a waiting method and an impact method.

[0047] The waiting method sets a total number of fault injections, N, and injects a fault at a random location each time for a preset time, T. If the software fails, the current injection is terminated and the next injection begins. For example, a total number of fault injections, N, is set, and the injection locations are random. First, a fault is injected at a certain location for a period of time, T. If the software fails within T, the current fault injection is terminated and the next fault injection begins again. If the software does not fail within T, the next fault injection is directly started after T expires and a random time has passed, and this process continues until N fault injections are completed.

[0048] The impact method sets the total number of fault injection rounds M, and injects n different faults continuously at random locations in each round. If the software fails, the current round is terminated and the next round of injection begins. For example, set the total number of fault injection rounds M, and the locations of the M rounds of injection are random. First, inject n different faults continuously at a certain location (assuming that the interval between each fault injection is very short, n is the set value, and the fault injection cycle is 1 / F). If n is completed, i After n times, the software has failed, so this round of fault injection is terminated and the next round of fault injection is restarted. If the software still has not failed after n times of fault injection, the next round of fault injection is directly started after the nth execution is completed and a random time is waited. This continues until M rounds of fault injection are completed.

[0049] In one embodiment of the present invention, the fault injection time is ensured to be consistent with the actual environmental disturbance through a timestamp synchronization mechanism, and a sliding window algorithm is used to analyze the impact of fault propagation delay on system stability.

[0050] Fault injection time refers to the random time between each (waiting mode) or each round (impact mode) of fault injection. Analysis shows that the time when the environmental fault occurs is random. Whether in the waiting mode or the impact mode, a random time T is required to prepare for the next / next round of fault injection (when no failure occurs). r, represents the randomness of fault injection, that is, from the time t when preparing for the next round of fault injection execution s Wait for a random time T r After that, the next round of fault injection begins.

[0051] In one embodiment of the present invention, the fault injection time generates a random waiting time Tr after each round of fault injection to simulate the randomness of environmental faults; the fault injection location is a random address in the register space, data storage space, or memory space of the system under test.

[0052] In one embodiment of the present invention, a software fault injection scenario model is constructed, and a GDB debugger is used in combination with a remote debugging script to automatically inject operational faults, including:

[0053] Deploy GDB on the host and write fault injection test scripts;

[0054] Deploy GDB Server and the software under test on the target machine;

[0055] Through GDB remote debugging, the script is converted into fault injection instructions in the address space or register space of the software under test.

[0056] In one embodiment of the present invention, the fault injection location is a random address in the register space, data storage space or memory space of the system under test. The fault injection location dynamically identifies the memory address of the critical code segment through symbolic execution technology, and combines hardware virtualization technology to simulate the data bit flip fault of the register space.

[0057] Whether using a wait-based or impact-based injection method, each round of fault injection occurs at a random address. Storage spaces include registers, data storage, and memory. Registers and data storage have fixed address ranges, while memory addresses are randomly assigned. Real-world disturbances can cause data mutations in registers, data storage, and memory. Because these effects are random, the randomness of the fault injection location must be considered during fault injection.

[0058] In one embodiment of the present invention, a software fault injection method for interface data faults analyzes software cross-linking interface faults and communication faults, designs an interface fault simulation operator, executes tests by injecting faults into the interfaces, detects errors in node software, and evaluates the test adequacy of the node software based on the cross-linking interfaces, message coverage, fault coverage, and test results.

[0059] Interface data fault simulation designs a data fault injection operator based on the cross-link interface fault type and message type. The value of the field in the mutated message includes at least one of message field value replacement, blanking, bit flipping, message field integer, floating point, Boolean, character type unconventional value, error message type identifier, and error message length.

[0060] Communication fault simulation designs a communication fault injection operator based on the type of communication fault and the interaction between the software and peripheral cross-linking devices or subsystems. This operator is designed based on the interaction between the node under test and peripheral devices, by modifying the interaction relationship, interaction process, and interaction time, and injecting communication faults. Network security fault simulation primarily simulates the impact on information transmission and some possible related attacks. This includes transmission fault simulations such as bit error rate, information noise, and data randomization, as well as active attack simulations such as malformed messages and tampered messages.

[0061] In one embodiment of the present invention, a fault injection method for a fault type is run, and a GDP debugger simulation method is used to implement fault simulation. A test script based on the GDB debugger is combined with GDB remote debugging to implement fault injection and automatically control the fault process. According to the adopted GDB-based remote fault injection debugging structure, GDB is deployed on a host, and a fault injection test script file is written on the host. A GDB server and software to be fault-injected are deployed on a target machine. After GDB and the GDB server are connected, the host sends the test script file to the target machine. The GDB server of the target machine parses the test script file and converts the GDB script commands into the address space of the tested software or the register space of the target machine for fault injection. The script defines the sequence of fault execution and automatic control information. The debugger loads the script to execute the instruction sequence at each breakpoint, and then calls the given control information to automatically release the program, thereby realizing complete automated fault injection.

[0062] In one embodiment of the present invention, a software fault injection method for platform environment faults and human-machine operation faults uses unconventional operations, incorrect operations, and rapid operations to test the robustness of the interface, and tests the interface's ability to detect and prompt incorrect operation processes, incorrect commands, or illegal data inputs;

[0063] Among them, faults are injected into the target levels of memory and CPU to simulate faults in the running environment; according to the memory and CPU fault models, memory and CPU faults are injected by obtaining the memory address space and CPU register address of the program, and the response of the program after the fault injection is observed to realize the external fault injection test of the software system; for the device status message transmitted using the interface data class, the corresponding status is a fault, etc., and the system status type fault is simulated. The status information of the main weapon system and sensor is sent through the simulation tool to check whether the software supports the correct display of the status information of the weapon system and sensor in the form of icons and table pages; whether it supports the common graphics and color identification and text prompts of each device to display the status of each device.

[0064] In one embodiment of the present invention, fault injection data refers to the fault data written to storage space (including registers and memory addresses) each time. In the waiting fault injection mode, the fault data can be the same or different each time. In the impact fault injection mode, the fault injection data is different in each round, and can be the same or different in different rounds of fault injection. Fault data is generated by applying the aforementioned memory and register fault injection operators to the data at the memory and register addresses.

[0065] In one embodiment of the present invention, a method for confirming software fault tolerance based on fault injection is provided. According to the structure, operation control logic and environmental dependencies of the software system, software fault modes are classified based on fault mode and impact analysis, and the classification includes software operation faults and task scenario faults. A software fault injection scenario model is constructed, and the model is based on four-dimensional elements: fault injection method, fault injection location, fault injection time and fault injection data. The model combines interface testing technology, program code mutation, interaction behavior mutation or manual injection method to inject faults into the tested software. Multi-stage test cases including unit level, integration level and system level are executed, and system behavior data after fault injection is collected in real time through a log capture module. Based on the fault detection rate, fault isolation rate and fault recovery time indicators, the Monte Carlo simulation method is combined to evaluate the task completion probability of the software in the task scenario and generate a comprehensive evaluation report on fault tolerance. The technical solution of the present invention can monitor and analyze the feedback information after the injection fault occurs in the target system by artificially generating faults and introducing them into the target software system, thereby improving the software code coverage rate and other purposes.

[0066] The above is 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 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 software fault tolerance confirmation method based on fault injection, characterized in that: The method comprises: S101. Classify software failure modes based on failure mode and impact analysis according to the software system's structure, operational control logic, and environmental dependencies. The classification includes software operation failures and task scenario failures. Software operation failures are identified through static code analysis and dynamic execution path tracing. Task scenario failures are extracted by simulating hardware anomalies, network fluctuations, and human-computer interaction error scenarios in a real environment. S102. Construct a software fault injection scenario model based on four elements: fault injection method, fault injection location, fault injection time, and fault injection data; the fault injection method simulates the sequential logic of fault occurrence using a Markov chain model, and the fault injection location is dynamically allocated using a memory address randomization algorithm; the model combines interface testing technology, program code mutation, interactive behavior mutation, or manual injection methods to inject faults into the software under test; S103. Execute multi-stage test cases including unit level, integration level and system level, and collect system behavior data after fault injection in real time through the log capture module; based on the fault detection rate, fault isolation rate and fault recovery time indicators, combine the Monte Carlo simulation method to evaluate the software's task completion probability in the task scenario, and generate a comprehensive evaluation report on fault tolerance.

2. A software fault tolerance confirmation method based on fault injection according to claim 1, characterized in that: The software operation failures include at least one of the following: memory leak failure, null pointer reference failure, array out-of-bounds failure, illegal calculation failure, data assignment type mismatch failure, incomplete or overlapping judgment condition failure, functional failure and software communication interface failure.

3. The software fault tolerance confirmation method based on fault injection according to claim 1, characterized in that: The fault injection mode includes: waiting mode and impact mode; In the waiting mode, the total number of fault injections is set to N, and each time a fault is injected at a random location for a preset time T. If the software fails, the current injection is terminated and the next injection is started; The impact method sets the total number of fault injection rounds M, and injects n different faults continuously at random positions in each round. If the software fails, the current round is terminated and the next round of injection begins.

4. A software fault tolerance confirmation method based on fault injection according to claim 3, characterized in that: The fault injection time is ensured to be consistent with the actual environmental disturbance through a timestamp synchronization mechanism, and a sliding window algorithm is used to analyze the impact of fault propagation delay on system stability.

5. The software fault tolerance confirmation method based on fault injection according to claim 3, characterized in that: The fault injection time generates a random waiting time Tr after each fault injection round to simulate the randomness of environmental faults; the fault injection location is a random address in the register space, data storage space or memory space of the system under test.

6. The software fault tolerance confirmation method based on fault injection according to claim 1, characterized in that: Build a software fault injection scenario model and use the GDB debugger combined with remote debugging scripts to automatically inject runtime faults, including: Deploy GDB on the host and write fault injection test scripts; Deploy GDB Server and the software under test on the target machine; Through GDB remote debugging, the script is converted into fault injection instructions in the address space or register space of the software under test.

7. The software fault tolerance confirmation method based on fault injection according to claim 1, characterized in that: The fault injection location is a random address in the register space, data storage space or memory space of the system under test. The fault injection location dynamically identifies the memory address of the critical code segment through symbolic execution technology, and simulates the data bit flip fault of the register space in combination with hardware virtualization technology.

8. A software fault tolerance confirmation method based on fault injection according to any one of claims 1 to 7, characterized in that: The software fault injection method for interface data faults analyzes software cross-link interface faults and communication faults, designs an interface fault simulation operator, executes tests by injecting faults into the interface, detects errors in the node software, and evaluates the test adequacy of the node software based on the cross-link interface, message coverage, fault coverage, and test results. Interface data fault simulation designs a data fault injection operator based on the cross-link interface fault type and message type. The value of the field in the mutated message includes at least one of message field value replacement, blanking, bit flipping, message field integer, floating point, Boolean, character type unconventional value, error message type identifier, and error message length. Communication fault simulation designs a communication fault injection operator based on the type of communication fault, the interaction behavior between the software and the peripheral cross-linking devices or subsystems. The communication error injection operator is designed based on the interaction behavior analysis between the node under test and the peripheral devices, by changing the interaction relationship, interaction process and interaction time, and injecting communication faults.

9. A software fault tolerance confirmation method based on fault injection according to claim 8, characterized in that: A fault injection method for running fault classes is implemented, and fault simulation is implemented using the GDP debugger simulation method. Among them, a test script based on the GDB debugger is combined with GDB remote debugging to implement fault injection and automatically control the fault process. According to the adopted GDB-based remote fault injection debugging structure, GDB is deployed on the host, and a fault injection test script file is written on the host. The GDB Server and the software to be fault-injected are deployed on the target machine. After GDB and the GDB Server are connected, the host sends the test script file to the target machine. The GDB Server of the target machine parses the test script file and converts the GDB script commands into the address space of the tested software or the register space of the target machine for fault injection. Among them, the script defines the sequence of fault execution and automatic control information. The debugger loads the script to execute the instruction sequence at each breakpoint, and then calls the given control information to automatically release the program, realizing complete automated fault injection.

10. The software fault tolerance confirmation method based on fault injection according to claim 8, characterized in that: Software fault injection methods for platform environment faults. Human-machine operation faults use unconventional operations, incorrect operations, and rapid operations to test the robustness of the interface. The detection and prompting capabilities of the interface for incorrect operation processes, incorrect commands, or illegal data input are tested. Among them, faults are injected into the target levels of memory and CPU to simulate faults in the running environment; according to the memory and CPU fault models, memory and CPU faults are injected by obtaining the memory address space and CPU register address of the program, and the response of the program after the fault injection is observed to realize the external fault injection test of the software system; for the device status message transmitted using the interface data class, the corresponding status is a fault, etc., and the system status type fault is simulated. The status information of the main weapon system and sensor is sent through the simulation tool to check whether the software supports the correct display of the status information of the weapon system and sensor in the form of icons and table pages; whether it supports the common graphics and color identification and text prompts of each device to display the status of each device.

Images