Model-Based Safety Analysis - Failure Logical Analysis

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

Method description A detailed description of the method

Model-Based Safety Analysis (MBSA) is an approach in which the system and safety engineers share a common system model created using a model-based development process. The method improvement regards the possibility to enhance the Hazard analysis and Risk Assessment (HARA), manually performed by system and safety experts, with the automatic generation of FMEA tables and FTs, supporting the safety assessment process. Starting from the system functional model, describing the system functional blocks, relevant in the context of the fault generation and propagation analysis, and their relationships, the system model is extended with the annotations and decorations required to describe the fault behaviours of the functional blocks, as well as with relevant portions of the physical system to be controlled. This extended model, called Failure Mode and Error Propagation Model, allows for the automatic generation of FMEA tables and FTs. See the image below for a description of the workflow.

Workflow description of MSA-FLA

The method improvement is a consequence of an update of the CHESS tools that is now able to:

generate FMEA tables, and
generate the relevant Fault Trees.

Method Strengths A listof the strengths of the method

FMEA generation is now automated, as well as FT generation.
Improves the communication between the system engineer and safety experts, by facilitating understanding of the logic and the eventual failures of the system
Achieves a systematic and comprehensive safety assessment that allows to early identify the greatest number of possible critical problems related to the impact of failures on the functionality of the system
Makes it easier to keep the system design aligned with the safety assessment
Carries out the main safety analyses (FMEA, FTA) in automatic mode, thus receiving rapid feedback, with a consequent immediate impact on the design
Since the anomalous behaviour of the system is calculated from components, the impact of modifying a component is easier to define, and the derived incremental safety analysis is cheaper, therefore reducing the costs of system maintenance and reuse.
Part of the CHESS Eclipse project.

Method Limitations The limitations of the method

The failure propagation algorithm is not optimized for large systems, impacting FMEA and FT generation.

Method References Bibliography references to papers about the method.

Wallace, Modular Architectural Representation and Analysis of Fault Propagation and Transformation, in proceedings of 2nd International Workshop on Formal Foundations of Embedded Software and Component-Based Software Architectures (FESCA 2005).
R. F. Paige, L. M. Rose, X. Ge, D. S. Kolovos, and P. J. Brooke. FPTC: automated safety analysis for domain-specific languages. In Models in Software Engineering, M. R. Chaudron (Ed.). Lecture Notes In Computer Science, Vol. 5421. Springer-Verlag, Berlin, Heidelberg, pp. 229-242, 2009Space Product Assurance: Software product assurance, id. ECSS-Q-ST-80 issue C, 06.03.2009.
B. Gallina and S. Punnekkat, “FI4FA: A Formalism for Incompletion, Inconsistency, Interference and Impermanence Failures Analysis,” in Proc. of EUROMICRO, ser. SEAA ’11. IEEE Computer Society, 2011, pp. 493–500.
B. Gallina, M. A. Javed, F. U. Muram, and S. Punnekkat, “Model-driven dependability analysis method for component-based architectures,” in Euromicro-SEAA Conference. IEEE Computer Society, 2012.
Gallina, B., Sefer, E., and Refsdal, A. (2014). Towards safety risk assessment of socio-technical systems via failure logic analysis. In Proceedings of the 2014 IEEE International Symposium on Software Reliability Engineering Workshops, pages 287–292.
B. Gallina and Z. Haider, A. Carlsson, S. Mazzini S. Puri, “Multi‐concern Dependability‐centered Assurance for Space Systems via ConcertoFLA”, International Conference on Reliable Software Technologies- Ada-Europe 2018, Lisbon, June 2018
Mazzini S., J. Favaro, S. Puri, L. Baracchi., “CHESS: an open source methodology and toolset for the development of critical systems”, 2nd International Workshop on Open Source Software for Model Driven Engineering (OSS4MDE), Saint-Malo, October 2016.
CHESS Dependability Guide – FLA (https://www.eclipse.org/chess/publis/CHESS_DependabilityGuide.pdf)

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.