Project topics and materials
Get Complete Project Material File(s) Now! »
Fault Trees
A fault tree (static de nition) encodes a Boolean formula over events in order to express the likelihood of a so-called \top event ». The top event represents an unwanted situation (a hazard). Fault trees follow a deductive approach: Starting from the top event, combinations of causative events are investigated, recursively. Events that occur represent \failures » (this is the inverse logic of safety analysts). In PSA models of EDF, thousands of fault trees are used. The fault tree method is well-documented. Exhaustive documentation can be found at [7, 8, 9]. Fault trees are presented graphically in form of directed acyclic graphs (DAGs), referred to as fault tree diagrams. The nodes of a fault tree diagram represent events, denoted by a rectangle containing the event name and an event symbol. The di erent symbols are explained in the sequel of this section. The top-event is drawn at the top of the diagram. Its input events are drawn beneath, recursively.
Event Trees
Alike fault trees, event trees encode Boolean formulas. Contrary to fault trees, which follow a deductive (top-down) concept, event trees focus on the evolution of events and thus follow an inductive (bottom-up) concept. In PSA models of EDF hundreds of event trees are used. Starting from a so-called initiating event (the rst event to consider in an accident scenario), all consequen-tial events are derived, recursively. A consequential event is an event that occurs due to the occurrence / non-occurrence of another event. In the case of nuclear power plants, consequential events are called function events. Each function event represents a recovery action to mitigate a critical situation. The recovery action can be successful or failing. According to whether recovery actions are successful or not, di erent event evolutions (sequences) are deducted.
The deduction of events ends in so-called sequences. Each sequence describes one speci c event evolution. Sequences can lead to so-called consequences which describe a certain system state. Di erent sequences can lead to the same consequence. Also, a sequence can lead to various consequences at a time. Figure 2.2 shows an example of an event tree. The accident scenario is initiated by an obstacle that occurs in front of a bike (the obstacle occurrence is the initiating event). As mitigating actions (function events), the cyclist can brake in front and back. For avoiding a crash it is su cient to have one working brake. In case both brakes fail, the accident is unavoidable and the bike will break. However, wearing a helmet, the consequence hospital can be avoided.
Linking Event Trees with Fault Trees
Initiating events and function events of event trees can be linked to fault trees in order to model occurrence characteristics. Generally, there are two approaches: The rst approach is the \fault tree linking » approach (FTL), the second the \event tree linking » approach (ETL). In FTL, fault trees \behind » function events may share same basic events, i.e. function events may depend on each other. In ETL, the opposite is true, i.e. An exhaustive comparison between FTL and ETL is given in [6]. Practically, FTL leads to small event trees connected to large fault trees, whereas in ETL large event trees and small fault trees are created. Additionally, in ETL event trees are often linked to other event trees (though also in FTL event trees can be linked to each other).
PSA models at EDF are based on the FTL approach. Nevertheless, some event trees are quite large in size. In Figure 2.3 the FTL method is illustrated: All function events are linked to fault trees. A function event occurs (fails) in case the associated fault trees fail (and inverse). The example shows two of the linked fault trees, which are possibly dependent (same events may occur in both fault trees).
Probabilistic Risk Assessment
Probabilistic risk assessment (PRA), also named probabilistic safety analysis (PSA) targets to investigate risk associated with a complex engineered technological entity such as an airliner or a nuclear power plants. The goal of PSA is to determine system failures that may occur due to design, during operation, test or maintenance phases. A vast spectrum of PSA Literature exists, for example [12, 13, 14, 15, 16, 17]. In the case of nuclear power plants, risk quanti cation serves as diagnosis tools and justi cation base for safety authorities. The French safety authority is the ASN (Authorite Suret Nucleaire). Risk analysis answers primarily the following questions [12]:
What can happen?
What likely is it to happen?
Given that it occurs, what are the consequences?
Plenty of methods exist to answer these questions. One method is the analysis of fault and event trees, abbreviated as FTA (fault tree analysis) and ETA (event tree analysis). However, FTA / ETA should not be considered to be the best or the only methods for safety analysis. According to [18], modeling techniques for system / safety modeling should generally be evaluated against the capabilities to:
Detect unavailability of systems.
Be used for a variety of di erent situations Detect all failures (completeness).
Understand, communicate and use results.
Reveal principle risks and how to avoid them.
Table of contents :
1 Introduction
1.1 Context of the Thesis
1.2 Objective of the Thesis
1.3 Organization of the Thesis
I Introductory Part
2 PSA Concepts
2.1 PSA Models
2.1.1 Fault Trees
2.1.2 Event Trees
2.1.3 Linking Event Trees with Fault Trees
2.2 Probabilistic Risk Assessment
2.2.1 Quantitative Risk Assessment
2.2.2 Qualitative Risk Assessment
2.2.3 Risk Visualization
2.2.4 Risk Assessment Tools
2.3 Conclusion
3 PSA from the 60’s to Nowadays
3.1 Initial Fault- and Event Tree Assessment
3.2 Wash Report 1975
3.3 Three Miles Accident
3.4 Enhancements in Computer Science
3.5 Conclusion
4 Present and Future Challenges
4.1 PSA Models
4.1.1 Increasing Model Complexity
4.1.2 Modeling Redundancy
4.1.3 Low level Modeling Language
4.2 PSA Model Development
4.2.1 Two-Dimensional Model Development
4.2.2 Concurrent Model Development
4.2.3 Long Life Cycles
4.2.4 Evolving Safety Requirements
4.2.5 Evolving Tool Chains
4.3 Conclusion
5 Preliminary Work
5.1 Previous Thoughts About a Modular PSA
5.1.1 Context
5.1.2 Concept
5.1.3 Hybrid PSA
5.2 Open PSA Model Exchange Format
5.2.1 Objectives
5.2.2 A Four-Plus-One Layers Architecture
5.3 Conclusion
II Safety engineering in a modular PSA
6 Principle of a modular PSA
6.1 Concept of a Modular PSA
6.1.1 Modularization
6.1.2 Generic Models
6.1.3 Instantiated Models
6.1.4 Model Instantiation
6.2 Technical Specication
6.2.1 Domain Engineering
6.2.2 Model Composition
6.2.3 Model Instantiation
6.2.4 Consistency
6.2.5 Modeling Operations
6.3 Comparison to the Original Modular PSA
6.3.1 Module Denition
6.3.2 Context
6.3.3 Generic Model
6.3.4 Dependency Management
6.4 Format Specications
6.4.1 Generic Representation of a modular PSA
6.4.2 Format for Adaption Rules
6.5 PSA Models in a modular PSA
6.5.1 Fault Trees
6.5.2 Event Trees
6.5.3 Representation Format for PSA Models
6.6 Conclusion
7 Model Management
7.1 Variant Management
7.1.1 Variant Management at Software Engineering
7.1.2 Primitive Forms of Variant Management
7.1.3 Technical Concept
7.1.4 Application
7.1.5 Variant Management in Andromeda
7.1.6 Future Work
7.2 Version Management
7.2.1 The Idea of Version Control
7.2.2 Principle of VCS Systems
7.2.3 Managing PSA Models by VCS
7.3 Model Comparison
7.3.1 Concept
7.3.2 Conguration
7.3.3 Visualization
7.4 Model Fusion
7.4.1 Technical Concept
7.4.2 Model Fusion in Andromeda
7.5 Consistency Check
7.5.1 Detecting Inconsistencies
7.5.2 Consistency Check in Andromeda
7.6 Conclusion
8 PSA Model Analysis
8.1 Exploiting information from Documentation
8.1.1 Principle of a Documentation Network
8.1.2 Model Documentation in a modular PSA
8.1.3 Application
8.2 Dependency Analysis
8.2.1 Forward Dependencies
8.2.2 Backward dependencies
8.2.3 Cartography
8.2.4 Usage- and Call Hierarchy
8.3 Using Graphs to Visualize Systems
8.3.1 Problem Context
8.3.2 Graph Models
8.3.3 Modeling Systems of Systems
8.3.4 Application
8.3.5 Limitation
8.4 Visualization Techniques
8.4.1 Color Inking
8.4.2 Eliding Diagrams
8.5 Conclusion
9 Model Development Process
9.1 MDP Phases in a modular PSA
9.1.1 Requirements Engineering
9.1.2 Model Design
9.1.3 Model Development
9.1.4 Model Integration
9.1.5 Model Verication
9.1.6 Model Maintenance
9.2 Using ESDs to design Event Trees
9.2.1 Framework of Event Sequence Diagrams
9.2.2 Event Tree Generation
9.2.3 ESDs in Andromeda
9.2.4 Extension: Combining Event Sequence Diagrams (ESDs) with Graphs
9.3 Scripting Interface
9.3.1 Principle of a Scripting Interface
9.3.2 Implementation of a Scripting Interface
9.3.3 Application
9.4 Concurrent Model Engineering
9.4.1 Outsourcing of Model Engineering
9.4.2 Example of Concurrent Model Engineering
9.4.3 Model synchronization
9.5 Verication of PSA quantication
9.5.1 Quantication Process
9.5.2 Verication of quantication engines
9.6 Conclusion
10 Andromeda
10.1 The Problem with Evolving Software Requirements
10.2 Philosophy
10.2.1 Extensibility
10.2.2 Connecting Functionality
10.2.3 Connecting Models
10.3 Architecture
10.3.1 Eclipse Technology
10.3.2 Modular Architecture
10.3.3 Frameworks
10.4 Andromeda Development
10.4.1 Command Pattern
10.4.2 Extension Development
10.4.3 ADSL
10.5 Conclusion
III Conclusion
IV Appendices
A Images and Figures
A.1 Scheme for Andromeda Adaption Rules
A.2 Components of a PSA Model
A.3 Traditional Event Sequence Diagrams
A.4 Pseudo Code of Reference Resolver
A.5 Ruby Script for automatic fault tree generation
A.6 List of Shell Commands
A.7 Development Milestones
List of Figures
Bibliography
