Project topics and materials
Get Complete Project Material File(s) Now! »
Model Instantiation
In this section, the instantiation principle of the modular PSA concept is precised. An instantiated model is a tuple hM; i where
M is the model to instantiate given in its generic form.
is a context called the instantiation context.
Models in a modular PSA need to be instantiated due to a specic context. Contexts re ect kind of specic circumstances, that are not directly encoded in models. At instantiation, models get specically adapted to the respective context.
A context denes instantiation parameters:
A ordered list of includes [Im; Im+1; : : : ; I1; I0; I1; : : : ; In1; In], ordered from -m to +n.
A ordered list of adaption rules [r1; r2; : : : ; rn].
Let includes(M; ) be a function that returns the list of includes for a model M respective a context .
Let rules(M; ) be a function that returns the list of adaption rules for a model M respective a context . Includes An include is a tuple hM; recursivei, whereas
M 2 Models is a model called the included model .
recursive 2 Boolean indicates whether the includes is recursive or not (non-recursive).
Modeling Operations
Modeling operations are always applied to the generic model. Then the generic model gets instantiated.
Note however that a user « sees » models always in their instantiated form. But as soon as he/she modi es a component, the modication itself is applied on the generic model and the model automatically reinstantiated.
The benet of the modular PSA framework is its generic specication that permits to express functionality and characteristics on a generic level. Consequently, modeling operations can be applied to models regardless their type. Some generic modeling operations are precised in the sequel.
Models can create components (modules) and components can dene further components (sub components). To create a new component C0 in a model M (or a component C), two criteria must be satised:
M must not contain another component that has the same name and type as C0.
The type of C0 must be a valid component type for M (or C).
Variant Management at Software Engineering
Variant handling is often treated to be an issue of conguration management (CM) and therefore it is often solved by version control systems (VCS). In [50], the management of variants by CM is investigated.
Based on CM or not, there are several approaches of variant management: One is the so-called Clone and Own [50] method. New variants are developed by creating an exact copy of an existing variant. Then,
modications for the variant are applied. The advantage is that variants can be developed independently from each other. But the downside is that this approach does not take into account that variants may share functionality. Future modications may have to be applied various times (once for each variant), what is not only time consuming but also error-prone.
Another approach (that mitigates some problems of Clone-and-Own) is to split a project (or a model) in various components, which can be developed independently from each other. A new variant is then created at integration phase when integrating a set of components in their appropriate versions. In [50], this approach is referred to as Independent Component Teams. It works quite well as long as components have relatively simple dependencies. But when dependencies between components get more complex, the selection of component versions at integration phase may become a complex issue. The diculty is to ensure compatibility between the integrated component versions.
Further, the concept of feature oriented software development (FOSD) extends the component based method to congure variants via so-called \features » [51, 52]. Each feature describes a characteristic (a constraint) about the software. Given a set of features the set of required components (in their appropriate versions) can be derived.
Primitive Forms of Variant Management
In this section, current methods of handling variants in PSA models are introduced. The drawbacks with those are mentioned.
Table of contents :
1 Introduction
1.1 Context of the Thesis
1.2 Objective of the Thesis
1.3 Organization of the Thesis
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
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
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
List of Tables
List of Publications
Bibliography
