Support Safety Analysis by Fault Simulation

Meta-Information

Origin: Sven Sieverding, Omar Kacimi, Eckard Böde / all OFFIS

Written: November 2014

Purpose: The intent is to avoid re-running an analysis technique that could be expensive in terms of execution time. After running the model-based safety analysis on an implementation model, a fault combination leading to a system failure is generated. This CEX is the starting point for this A&T pattern.

The MBSA should normally be run again to assess whether the safety mechanism mitigates the given fault combination. Since the MBSA can be quite time costly to run, the pattern proposes to make use of the generated counter-example. The pattern suggests to perform a simulation of the counter-example generated by the MBSA on a system model injected with faults. Hence, if the modifications introduced to the system are not sufficient for reaching the safety goal, this can be discovered prior to running the MBSA another time.

Context/Pre-Conditions: safety analysis, requirements.

To consider: This pattern requires the involvement of a safety engineer. Also, the execution of the MBSA might be fairly time and resources consuming. Furthermore, the execution of the counter-examples on the system requires the use of fault injection techniques during simulation.

.

Structure

(1) Model Creation:

(1.1) Engineering models creation:

(1.2) Link creation:

(2) MBSA Workflow:

(6,8) Faults Simulation:

Participants and Important Artefacts

Experts:

V&V Experts:

– Safety engineer

– Analysis and test execution expert

Development Experts:

– System engineer

– Developers

Tools:

Safety analysis tools:

– Fault injection tool

– Failure modes definition tool

– The model-based safety analysis

– Fault simulation tool

System and requirements design tools:

– Implementation model design tool

– Requirements formalization tool

Data:

Safety Requirements:

– In the form of contracts

– In a form of an RSL (requirements specification language, e.g. the OFFIS RSL)

Implementation Model (In the StateFlow modelling language)

Failure Modes (Modelling of possible failure behaviour):

– Variable stuck-at a value

– Variable changing its value randomly

– Specific fault behaviour defined by the user

.

Actions / Collaborations

(1) The engineering models are created on the basis of natural language requirements.

(2) The MBSA workflow is performed and the outcomes of the analysis are generated.

(3) The safety engineer assesses the results for safety requirements violation (caused by the injected faulty/dysfunctional behavior).

(4) The system designer will modify the system according to the analysis results, e.g., by introducing new safety mechanisms.

(5) Faults are extracted from the counter-examples generated by the MBSA and are injected in the system model.

(6) A fault-simulation of the extended system model is performed.

(7) If the fault-simulation shows that the introduced changes are not effective and the top level event can still be triggered by the CEX, step 4 needs to be repeated.

(8) If the faults simulation results in a failure start from 7 again. Otherwise, the test is successful and the MBSA can be run on the updated system.

.

Discussion

Benefits:

– The pattern reduces the analysis effort by supporting it with faults simulation.

– It saves regression analysis efforts by testing first whether applied correction fixes the found problem.

Limitation:

– It does not reduce the analysis effort for new injected faults.

Comment:

– The pattern supports the static analysis of the effects of a set of malfunctions on fufilling a safety property. In case additional malfunctions need to be analyzed, the pattern should be re-applied.

.

Relations to other Patterns

Pattern Name	Relation*
Model and Refinement Checking	Could be used for MBSA-CEX if model is too fine-grained
MBSA with Fault Injection	This pattern can use that pattern (for injecting faults)
Requirements Formalization	Could be used for task “Formalize requirements”
Target MBT to Suspect Areas Identified by Static Code Analysis	Also generates test cases (test vectors) from analysis

* “this pattern” denotes the pattern described here, “that pattern” denotes the related pattern