Project topics and materials
Get Complete Project Material File(s) Now! »
Model-Based approach for Safety Analysis
Nowadays, traditional risk assessment methods (Fault Tree Analysis, Event Trees Analysis), presented in Section 1.2 of this chapter, have reached their limits. They rely on too low level modeling formalisms.
As a consequence, there is always a gap between the system specications and the associated safety models. This gap makes safety models hard to design, to share amongst stakeholders and to maintain through the life cycle of systems. Even a minor change in the specication may require a total revisiting of the safety model, which is both time consuming and error prone.
Model-Based Safety Assessment { the reliability engineering branch of Model-Based System Engineering { focuses more and more worldwide attention. The idea is to write models in high level
modeling formalisms so as to keep them close to the functional and physical architecture of the system [55]. The high level model can be assessed directly or by its compilation into a low level model, e.g. Fault Tree or Markov chain.
Advantages of Model-Based approach
Compared to classical approaches such as Fault Tree Analysis, Model-Based Safety Assessment presents many advantages:
Safety models are kept close to functional and physical architectures of the systems under study. Therefore, it is much easier to propagate changes in system specications as well as to trace changes in safety models.
Safety models are structurally close to models designed by other system engineering disciplines
(system architecture, dynamic system modeling, etc.). This proximity is of a great help to better integrate Safety Analyses with other system design processes.
Models can be graphically animated. The incident or accident scenarios can be visualized and discussed. In a word, high level models are much easier to share amongst the dierent stakeholders than lower level ones.
In general high level modeling languages have a greater expressive power than Boolean formalisms such as Fault Trees or Reliability Blocks Diagrams. It is therefore possible to capture phenomena, such as spare redundancies, shared components, etc.
High level modeling favors the reuse of models at the component level (via the design of libraries) and at the system level (via the adaptation of a model designed for a project to another project). Experience shows that this is a great source of cost saving.
For the same reasons, high level modeling favors knowledge capitalization.
Prerequisites for a high level modeling language for Safety Analyses
In this section we discuss dierent properties that a high level modeling language for Safety Analyses should have.
First of all, a high level modeling language should be formal, i.e. its semantics should be formally dened. In order to be assessed (compiled into a low level formalism, e.g. Fault Tree or Markov chain, simulated, etc.) the model interpretation must not be ambiguous. The formal semantics ensures the correctness of the obtained results. Second, a high level modeling language should combine the advantages of both Boolean and States/Transitions formalisms:
It should be event-based. The goal of Safety and Reliability studies is to determine the most probable failure scenarios, i.e. sequences of events leading the system from its nominal state to a failure state (an incident or an accident). As it was seen in Section 1.2 all classical formalisms are event-based. It should be possible to associate probability distributions to events.
It should have the expressive power of at least States/Transitions formalisms to be able to represent dynamic models.
At the same time the language must be compositional in order to make it possible to describe systems as hierarchies of components, like in Fault Trees and Reliability Block Diagrams.
For any reasonable size system, the number of reachable states is just astronomical. It is impossible to represent all the states the system may reach. Therefore, the state space should be represented in an implicit way.
Fault Trees and Reliability Block Diagrams make it possible to represent instant remote interactions between components of the system under study. The language should make it easy to assemble components \in a Lego way » and to represent the propagation of ows through the system.
Third, the language should be textual but it must be possible to associate dierent graphical representations with textual models. From our point of view, it is not possible to have a unique graphical representation of the whole model due to its expressiveness: it would be just unreadable. Diagrams like Markov Chains or Generalized Stochastic Petri Nets are very convenient for small systems but their interest is lost in case of industrial scale systems. Graphical representations must be seen as partial views on the whole model, which in practice can be very complex. Finally, the language must favor models reuse and knowledge capitalization.
High level formalisms for Safety Analysis
Dierent high level modeling formalisms have been proposed to perform Model-Based Safety Assessment. As suggested in [60], these formalisms can be classied according to the engineering semantics of components interfaces, as follows:
Failure logic modeling formalisms;
Failure eects modeling formalisms;
Hybrid approaches. In the following section we introduce some high level modeling formalisms dedicated to Safety Analysis.
Table of contents :
Remerciements
Introduction
Table of contents
List of gures
List of tables
1 Model-Based Safety Assessment
1.1 Safety and Reliability studies
1.1.1 Probabilistic indicators
1.1.2 Redundancies
1.1.3 Safety Assessment
1.2 Classical approach for Safety Analysis
1.2.1 Boolean Formalisms
1.2.2 States/Transitions Formalisms
1.2.3 Extensions of classical formalisms for Safety Analysis
1.3 Model-Based approach for Safety Analysis
1.3.1 Advantages of Model-Based approach
1.3.2 Prerequisites for a high level modeling language for Safety Analyses
1.3.3 High level formalisms for Safety Analysis
1.4 AltaRica
1.4.1 Assessment tools
1.4.2 AltaRica 3.0
2 Guarded Transition Systems (GTS)
2.1 Motivations
2.2 Informal presentation
2.2.1 Data-Flow components
2.2.2 Acausal components
2.2.3 Hierarchical models
2.3 Formal denition
2.3.1 Expressions
2.3.2 Instructions
2.3.3 Denition
2.4 Composition of GTS
2.4.1 Free product
2.4.2 Connection
2.4.3 Synchronization
2.5 Semantics
2.5.1 Semantics of instructions
2.5.2 Reachability graph
2.6 On the modeling of ow propagation
2.6.1 Dependency relation
2.6.2 Handling looped models
2.6.3 Algorithms to calculate assertions
2.6.4 Dierent approaches to interpret assertions
2.7 Timed/Stochastic Guarded Transition Systems
2.7.1 Timed Guarded Transition Systems
2.7.2 Stochastic Guarded Transition Systems
2.8 Comparison with classical formalisms for Safety Analyses
3 System Structure Modeling Language (S2ML)
3.1 Motivations
3.2 Object-oriented paradigm vs. prototype-oriented paradigm
3.3 Structural constructs
3.3.1 Blocks
3.3.2 Classes
3.3.3 Using Classes or Blocks?
3.4 Structural operations
3.4.1 Composition (declaration clause)
3.4.2 Inheritance (extends clause)
3.4.3 Aggregation (embeds clause)
3.4.4 Relations between components
3.5 Flattening
3.5.1 Flattening of the hierarchy
3.5.2 Flattening of the synchronizations
3.5.3 Hiding
3.6 Discussion
3.6.1 About models reuse
3.6.2 About parametric models and scripts
3.6.3 About graphical representation of models
4 Compilation into Fault Trees or critical sequences of events
4.1 Motivations
4.2 Related Works
4.2.1 Algorithms based on backward analysis
4.2.2 Algorithms based on fault injection
4.3 Compilation algorithm
4.3.1 Compilation of labeled Kripke Structures into Boolean formulae
4.3.2 Partitioning
4.3.3 Reachability Graph generation
4.3.4 Compilation of Reachability Graphs
4.3.5 Compilation of the independent assertion
4.3.6 Results
4.4 Compilation of stochastic models
4.5 Complexity Analysis and correctness
4.5.1 Complexity
4.5.2 Correctness
5 AltaRica 3.0 Modeling, Simulation and Assessment Platform
5.1 Motivations: the AltaRica 3.0 project
5.2 Overall architecture of the platform
5.3 XGTSCore library
5.3.1 Optimization of Guarded Transition Systems
5.4 Stepwise simulator
5.5 AltaRica 3.0 compiler
5.6 Fault Tree compiler
6 Conclusion
A Mobility modeling
B AltaRica and Safety Analysis Modeling Language (SAML)
C Graphical representation and animation of models
D Modeling patterns
Bibliography
