Model-Implemented Fault Injection

In this method, the faults are injected in the model of the system under test (SUT). MATLAB and LabVIEW are examples of tools used to build such system models. This method is used to verify and validate the system’s capability to handle faults. The fault handling includes attributes such as fault detection, correction, or fallback with or without the fault handling mechanisms implemented. This type of fault injection method is used for the system’s evaluation in the early design stages.

Method Purpose Short description of the method's purpose and main benefits

Method description A detailed description of the method

Model-based development is often used to develop the systems with high safety requirements [MIF2]. Model-based development refers to the modelling of the intended SW based on the initial requirements and assumptions of the system [MIF3]. That model can then be used to test and verify the initial assumptions. In the model-implemented fault injection method the System Under Test (SUT) and faults that are to be injected are modelled. The model-implemented fault injection is a subcategory of simulation-based fault injection.

Later in the model development process, the same model is used to generate the SW code, executable on the target hardware. In MIFI different types of faults are injected by adding separate blocks modelling the faults into the target system model [MIF3], allowing the dependability requirements to be tested in early development phases.

Method Strengths A listof the strengths of the method

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 [MIF1].
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.

Method Limitations The limitations of the method

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.
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.

Method References Bibliography references to papers about the method.

[MIF1] 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
[MIF2] 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.
[MIF3] 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.

Method Dimensions

Evaluation Environment Type Type of environment where the method is applied. It can be more than one type of environment. (Dimension 1)

Evaluation Type Type of evaluation performed with that method. If a method is hybrid, more than one type can be selected. (Dimension 2)

Type of Component Under Evaluation Type of components that can be evaluated with that method. It can be more than one type. (Dimension 3)

Evaluation Stage The evaluation stage where the method is used. (Dimension 5)

Purpose of the Component Under Evaluation The type of purpose that can be evaluated by a method. It can be more than one type. (Dimension 6)

Type of Requirement Under Evaluation The type of requirements that a method is able to evaluate. It can be more than one type. (Dimension 7)

Evaluation Performance Indicator The type of evaluation criteria or KPI that a method is able to improve. It can be more than one type. (Dimension 8)

Relations

Related Methods A method could be related to other methods.

Tools A method can use zero or more tools.

Part Method A method (when it is a combination: Combination of method artefact that is a specialization of a V&V Method) could be composed of a set of V&V Methods.

Test Case or Verification and Validation activity Test Case or V&V activity performed in a Use Case. We will link to the method to the test cases where the method is used.

Standards A method can be linked with standards.

Context

Workflow

Contents

There are currently no items in this folder.