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 speci cations 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 speci cation 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 En-gineering { 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 sys-tem [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 speci cations 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 di erent stake-holders 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 di erent 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 de ned. 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 im-possible 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 inter-actions 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 di erent 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.
Timed/Stochastic Guarded Transition Systems
A probabilistic timed structure can be put on the top of Guarded Transition Systems.
Timed Guarded Transition Systems
De nition 2.18 (Timed Guarded Transition System). A Timed Guarded Transition System is a tuple hV; E; T; A; ; delayi, where hV; E; T; A; i is a Guarded Transition System, delay : E ! R+ is a function, that associates to each event a non-negative real number. The state of a Timed Guarded Transition System is a couple ( ; d) 2 D, where is a variable assignment as de ned previously and d : T ! R+Qis a delay assignment (i.e. a function that associated for each transition tr 2 T a delay d(tr)), = dom(v) is a set of all variable assignments, called v2V states, and D = R+#T is a set of delay assignments. If d(tr) = 0 then the transition tr should be red.
The semantics of a Timed Guarded Transition System is de ned in terms of Timed Transition Systems, including transitions labeled by the events from E and timed transitions labeled by real delays. De nition 2.19 (Timed Transition System). A Timed Transition System S is a quadruple (S; s0; ! ; E), where S is a set of states, E is a set of events, s0 2 S is an initial state, ! S (E [ R+) S is a transition relation. De nition 2.20 (A run). A run of a Timed Transition System S is a sequence of transitions l0 ln 1 i n li . A state 2 is reachable if there is a = s0 ! s1 : : : sn 1 ! sn, where 8 0 1; si ! si+1 run from 0 to .
De nition 2.21 (Semantics of Timed Guarded Transition Systems). Given a Timed Guarded Tran-sition System T GT S = hV; E; T; A; ; delayi, the semantics of T GT S is a Timed Transition System ST GT S = (S; s0; !; E), such that: S= D, s0 = ( 0; d0), where 0 is the initial state of the Guarded Transition System hV; E; T; A; i, calculated as follows: 0 = P ropagate(A; ; );
and for each transition tr = he; G; P i 2 T; e 2 E, its initial delay is calculated as follows: 8 < d0(tr) = : delay(e); if 0(G) = T RU E; +1; otherwise. ! S (E [ R+) S describes two types of transitions: e { transitions labeled by events: ( i; di) ! ( i+1; di+1) i 1. 9 tr = he; G; P i 2 T; e 2 E such that di(tr) = 0, 2. i+1 = F ire(P; A; ; i), 3. for each transition tr = he; G; P i 2 T; e 2 E, its delay is calculated according to the new state i+1 8 di+1(tr) = < delay(e); if +1(G) = T RU E; + 1 ; otherwise.i
: { timed transitions: ( i; di) ! ( i; di+1) i 1. = min(di(tr)),
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
