Model-Implemented Fault Injection with Pre-injection Analysis
Model-based development is often used to develop the systems with high safety requirements [MFP2]. Model-based development refers to the modelling of the intended SW based on the initial requirements and assumptions of the system [MFP3]. That model can then be used to test and verify the initial assumptions. Later in the model development process, the target system model is used to generate the SW code, executable on the target hardware. In model-implemented fault injection, the System Under Test (SUT) and faults that are to be injected are modelled allowing the dependability requirements to be tested in early development phases.
Pre-injection analyses [MFP4] [MFP5] [MFP6] [MFP7] allows the fault space to be reduced enabling the time, cost and effort needed to perform model-implemented fault injection experiments to be reduced. Pre-injection analysis is done before fault injection experiments are performed. The results of previous fault injection experiments may also be used, often referred to as post-injection analysis. Pre-injection may analyse the model structure to incorporate techniques such as inject-on-read, inject-on-write and error space pruning of signals.
The inject-on-read technique follows the rule that faults and attacks should only target resources, such as CPU registers and memory cells immediately before they are read. This way, faults and attacks that have identical activation are grouped into the same equivalence class, thereby reducing the fault/attack space.
The inject-on-write technique is similar to the inject-on-read technique. However, for inject-on-write the faults and attacks are only injected on a resource immediately after it has been produced. This way, faults and attacks that are injected into the resource any time after it has been produced, but before it is read the first time, have identical activation and may be grouped into the same equivalence class, thereby reducing the possible fault/attack space.
In error space pruning of signals, pre-injection analysis is performed to prune faults and attacks that are equivalent to other faults and attacks, where the equivalence is determined using a static analysis of the target system structure. For example, faults injected on an input signal may be considered equivalent to faults injected on the output signal connected to the input signal if only one propagation path exists between the input and output signal.
These techniques require detailed knowledge of the target system for efficient implementation making them suitable for use with MIFI.
- MIFI is aligned with the shift-left approach where the focus of the test and verification activities are shifted towards the early design and development process to find and improve the weaknesses of the software as much as possible and as early as possible with less effort and resources [MFP1].
- MIFI is used for testing and verification of the robustness of the simulated model of the intended software. This gives an early evaluation of the software behaviour under the presence of faults.
- MIFI gives valuable input to the design allowing the development engineers to get a holistic view of the dependability bottlenecks.
- MIFI can be used to evaluate the error and fault detection and handling mechanisms as well as system behaviour under the presence of faults.
- Measurements from MIFI may be useful in later V&V.
- The MIFI is limited to the fault injection on the simulation level (simulation-based fault injection). It is not possible to evaluate the actual physical system. There are other techniques used to inject faults on physical level such as SWIFI (Software Implemented Fault Injection), fault injection on pin-level, EMI (electromagnetic interference) and PSD (power supply distribution) etc
- Accuracy of the fault models w.r.t the actual faults in the physical system may not be adequate.
- To execute huge amounts of faults, a lot of computer resources are required. This limitation is partly addressed by the pre-injection techniques utilized in the method.
- Any change in the system design in the later stages of the product development cycle might decrease the usefulness of the measurements from the model and cannot be used for the comparison of the results between verification and validation stages.
- [MFP1] Bjerke-Gulstuen K., Larsen E.W., Stålhane T., Dingsøyr T. (2015) High Level Test Driven Development – Shift Left. In: Lassenius C., Dingsøyr T., Paasivaara M. (eds) Agile Processes in Software Engineering and Extreme Programming. XP 2015. Lecture Notes in Business Information Processing, vol 212. Springer, Cham. https://doi.org/10.1007/978-3-319-18612-2_23
- [MFP2] R. Svenningsson, J. Vinter, H. Eriksson, and M. T¨orngren, “Modifi: A model-implemented fault injection tool,” in Proc. of the 29th Int. Conf. on Computer Safety, Reliability, and Security, ser. SAFECOMP’10. Berlin, Heidelberg: Springer-Verlag, 2010, pp. 210–222.
- [MFP3] P. Folkesson, F. Ayatolahi, B. Sangchoolie, J. Vinter, M. Islam, and J. Karlsson, “Back-to-back fault injection testing in model-based development,” in Computer Safety, Reliability, and Security, 2015.
- [MFP4] J. Grinschgl, A. Krieg, C. Steger, R. Weiss, H. Bock and J. Haid, "Efficient fault emulation using automatic pre-injection memory access analysis," 2012 IEEE International SOC Conference, Niagara Falls, NY, 2012, pp. 277-282.
- [MFP5] B. Sangchoolie, F. Ayatolahi, R. Johansson and J. Karlsson, "A Comparison of Inject-on-Read and Inject-on-Write in ISA-Level Fault Injection," 2015 11th European Dependable Computing Conference (EDCC), Paris, 2015, pp. 178-189.
- [MFP6] Czeck, Edward W. and Daniel P. Siewiorek. “Observations on the Effects of Fault Manifestation as a Function of Workload.” IEEE Trans. Computers 41 (1992): 559-566.
- [MFP7] Folkesson P., Karlsson J. (1999) Considering Workload Input Variations in Error Coverage Estimation. In: Hlavička J., Maehle E., Pataricza A. (eds) Dependable Computing — EDCC-3. EDCC 1999. Lecture Notes in Computer Science, vol 1667. Springer, Berlin, Heidelberg.