Software-implemented fault injection

Software implemented fault injection consists in the deliberate insertion of upsets (faults or errors) in computer systems and/or components to evaluate its behaviour in the presence of faults or validate specific fault tolerance mechanisms in the target system.

Software-implemented fault injection, abbreviated as SWIFI, uses a variety of software-based techniques for inserting faults or errors in a system-under-study. These techniques may range from pre-runtime approaches, such as the modification of the binary executable or source code to introduce the fault [FIN1], to runtime approaches, such as using software traps to halt execution and inject a fault in specific locations of the processor and/or the program under execution [FIN2]. SWIFI is adaptable to various hardware architectures and can implement most fault models, including models that represent hardware faults (e.g., single and multiple bit-flips in CPU registers and memory) [FIN2] and software faults (e.g., code mutations that mimic the most common real software faults) [FIN1], [FIN3], [FIN4].  

Usually, fault injectionIt can be employed to evaluate the dependability of a system, identify failure modes and estimate their probability of occurrence, validate fault tolerance mechanisms and measure various fault and error coverages, as well as latencies (see, for example, [FIN5]). 

  • Capable of evaluating the dependability of real systems and validating fault tolerance mechanisms
  • Can significantly accelerate the generation of failure data (when compared to natural failure occurrence)
  • Can emulate realistic hardware and software faults
  • Portable to different hardware architectures, operating systems, etc.
  • Requires the existence of a prototype or a real system for evaluation
  • The used fault models should be realistic and represent faults that the system may experience
  • Intrusiveness in the system because of the fault injection tool may skew the results
  • Extensive fault injection campaigns may take a considerable amount of time, depending on the workload and number of experiment runs
  • [FIN1] João A. Durães and Henrique S. Madeira “Emulation of Software Faults: A Field Data Study and a Practical Approach”, IEEE Transactions on Software Engineering, vol. 32, no. 11, pp. 849-867, November 2006.
    [FIN2] João Carreira, Henrique Madeira e João Gabriel Silva, “Xception: Software Fault Injection and Monitoring in Processor Functional Units", IEEE Transactions on Software Engineering, Vol.24, No.2, February 1998.
  • [FIN3] R. Natella, D. Cotroneo, and H. Madeira, “Assessing Dependability with Software Fault Injection: A Survey”, ACM Computing Surveys, Volume 48 Issue 3, February 2016.
  • [FIN4] R. Natella, D. Cotroneo, J. Durães, H. Madeira, "On Fault Representativeness of Software Fault Injection", IEEE Transactions on Software Engineering, vol.39, no.1, pp. 80-96, January 2013.
  • [FIN5] F. Cerveira, R. Barbosa, H. Madeira and F. Araújo, "The Effects of Soft Errors and Mitigation Strategies for Virtualization Servers," in IEEE Transactions on Cloud Computing, doi: 10.1109/TCC.2020.2973146.
Method Dimensions
In-the-lab environment
Experimental - Testing
Hardware, Software
System testing, Acceptance testing
Thinking, Acting, Sensing
Non-Functional - Safety, Non-Functional - Other
V&V process criteria, SCP criteria
Relations
Contents

There are currently no items in this folder.