ing
Fault tree analysis and model checking are two radically different methods with the same goal: the analysis of safety critical systems. While fault tree analysis is used by safety engineers to calculate the probability of undesired events and to discover the possible root-causes, model checking proves a property given in a formal language to be correct on a formal model of the system. The advantages of fault tree analysis are their wide acceptance in industry, the comparatively simple creation of fault trees, and the definition of the property to analyse from the specification. The latter is one of the difficulties of model checking, as system specifications are rarely written formally, but include natural
(F) Fast Front Slow Down Unfiltered Laser 3d
Bottom interface Fast Front Slow Down
Unfiltered Laser 3d All Centre
Fast Front Slow Down Unfiltered Laser 3d
All Right
Fast Front Slow Down Unfiltered Laser 3d
All Left Top interface
Figure 6.11: Abstracted network of the group (G) Fast Front Slow Down Unfiltered Laser 3D
language, figures, etc. A disadvantage of fault tree analysis is that its completeness is not naturally given.
The combination of fault tree analysis and model checking aims at taking the pros of both methods, while eliminating the cons. The great number of different research approaches show the various possibilities in which the methods can be combined. The intention of [Bieber 02] is to use both methods independently depending on the special task, and to represent the results on a common basis in order to combine them and make them available for both, safety engineers and system designers. [Thums 03, Schäfer 03] use model checking techniques to verify the proper design of a fault tree. Other approaches use the results of fault tree analysis, the minimal cut sets, to generate properties to be checked by the model checker [Santiago 05, Cha 12]. A different approach is used by [Akerlund 99], who creates fault trees according to counter-examples generated by the model checker. To overcome the difficulties in manually creating fault trees and formal queries, [Cha 12] present an approach that automates the whole process. In the remainder of this section, the possibilities to use similar approaches for the analysis procedure of behaviour-based systems are discussed.
Model Checking of Fault Tree Events
In Chap. 4.2 the application of fault tree analysis to behaviour-based systems was intro- duced. By the use of the structured composition of the software, the completeness of the fault tree can be achieved for the software part. But, another problem could be identified when using this technique: the size and complexity of the fault tree. One idea is therefore, to use model checking to eliminate parts of the fault tree by verifying their correctness. The approach proposed in this thesis models a faulty data signal output of a behavioural component as combination of its data calculation and its activity calculation (see Sec. 4.2.1 and Fig. 4.9). In both cases, the event structural fault is introduced which addresses the possibility that the behavioural component is not correctly interconnected with others. This problem is also covered by the model checking approach. Model checking can verify
the connection to be correct under given conditions, which would eliminate the event from the fault tree. By way of example, consider the network introduced in Sec. 4.2.2, Fig. 4.16 and Fig. 4.18. The structural fault considering the activity calculation of the component
Fast Front Slow Down Centre can be excluded by verifying whether it is possible that
the component can get active and inactive, respectively in case of obstacles. This result shows, that the state of the component is dependent on the sensor hardware, which is correct. The event can therefore be removed and therewith the size of the fault tree can be reduced.
Fault Tree Design Using Model Checking
Using model checking to design a fault tree has the goal to create a complete and correct tree. Some approaches build a formal model of the underlying system and build the fault tree from this model, others use series of queries for every leaf and use the counter-examples for further division. In the case of behaviour-based systems, the structuring of the software already enables a straight-forward fault-tree creation. The process can be automated in large parts and needs manually treating only in special cases. These are for example fusion behaviours (see Sec. 4.2.1) and behavioural components which interact with the environment (safety behaviours). In the case of safety behaviours, a negative result of the model checker provides a witness or backtrace including statements about the relation of the state of sensor hardware and behavioural components in the software network. For example, a behavioural component cannot be active in the case of a faulty sensor. The event faulty sensor can then be integrated in the fault tree. This procedure helps to create a correct and complete fault tree on the interface between (sensor) hardware and software. Combining the Results of Model Checking and FTA
Using both analysis methods provides the possibility to overcome the drawbacks of the single ones. In the case of behaviour-based systems, the abstraction level of the formal model limits the possible queries. These can be covered by fault tree analysis, which allows to integrate any states of behavioural components and to consider data signals, which are neglected in the formal model. However, the evaluation of structural faults must be done manually for fault tree analysis and can be easily executed with model checking. Thanks to the structured representation of behaviour-based software systems, both methods can work on the same basis. The same holds for the representation of the results, counter-examples can be displayed in the network view as well as the set of components belonging to a certain cut set.