3.2 Methods for Automation of Reliability Models
3.2.1 Decision Table Methods
3.2.3 Modified Decision Table method . . . 77 3.2.4 Cause-Consequence Diagrams . . . 79 3.2.5 Mini fault trees . . . 79 3.2.6 Faultfinder . . . 79 3.3 Summary . . . 85
3.1
Introduction
The ability to automate a reliability method is not a new concept. Most effort has been in the development of the automated construction of fault trees. Manual fault tree construction is inefficient and prone to error. Although a specialist would be able to complete this task themselves, there are two reasons that this is inefficient. The first is the number of man hours required to complete such a task particularly if the system is large. The second is fault tree construction can be subjective, meaning that different specialists might adopt inconsistent approaches. To reduce the amount of time that is needed to construct a fault tree and ensure that the tree is accurate, automated methods were needed to complete the task. This is the same for any reliability model.
3.2
Methods for Automation of Reliability Models
3.2.1 Decision Table Methods
Decision tables are a method of defining the behaviour of a component within a system. They can represent the different states, working or failed, of the component and how the component behaves as a result of different inputs from other components within the
Table 3.1: Complete decision table for component fuse
Row No. Input State Internal Mode Output State
1 0 0 0 2 0 1 0 3 0 2 0 4 1 0 1 5 1 1 0 6 1 2 1 7 2 0 0 8 2 1 0 9 2 2 2
Input/Output states: 0 - No Signal, 1 - Normal, 2 - High/Overload Internal mode: 0 - Good, 1 - Failed Open (without an overload input),
2 - Failed shorted (fails to open in the event of an overload)
Table 3.2: Reduced decision table for component fuse
Row No. Input State Internal Mode Output State
1 0 – 0 2 – 1 0 3 1 0 1 4 1 2 1 5 2 0 0 6 2 2 2
Input/Output states: 0 - No Signal, 1 - Normal, 2 - High/Overload Internal mode: 0 - Good, 1 - Failed Open (without an overload input),
2 - Failed shorted (fails to open in the event of an overload)
system. They have been commonly used as a method of describing components for use in constructing fault trees. This section describes decision tables in more detail and how they have been applied.
Salem et al (1977) discussed a method using decision tables to model the system behaviour. The decision tables represent the components in the system. For example the decision table for the component fuse has been given in Table 3.1. Decision tables are first created to account for every possible combination of inputs and state and showing the output as a result of the combinations. In the example given in Table 3.1 the inputs, outputs and the internal modes are represented by three values as described in the table.
From this full version of the decision table, modifications can be made in order to reduce its size. This is done by identifying which rows have the same output based on either inputs or states. This allows the rows to merge and therefore reduce the size of the table. An example of this reduction can be seen in rows 1, 2 and 3 where regardless of the internal mode of the fuse if the input state is 0 then the output is 0. By bringing these rows together and introducing ‘–’, which refers to a‘don’t care’ entry, the table is reduced to that seen in Table 3.2. It should be noted that only the input and internal states can be reduced to a ‘don’t care’ state.
A method of using decision tables to once again model components within a system is demonstrated by Salem et al. (1977). This method discusses how decision tables have been used in aiding the construction of fault trees. A piece of software, Computer Automated Tree (CAT), was developed as a result. The software was designed for the analyst to use as part of there work. The method discussed describes a way of producing an accurate fault tree to describe a system’s behaviour. The software was designed to cater for multiple fault trees at any one time, which could include the success of a system. The CAT allows an analyst to edit the produced fault tree including the gates and events of the fault tree. Another method for fault tree construction is presented by Han et al (1989) which describes a different piece of software, Automated Fault Tree Construction (AFTC). The AFTC code was designed as an improvement on the CAT software. This method combines the use of decision tables and flow diagrams to ensure that the system and its components can be modelled effectively. This method uses the concept of super component models, which are similar to flow diagrams, together with decision tables and flow diagrams in order to generate a fault tree. Common Cause Failures (CCFs) models, which show how a root cause can create multiple component failures, are then merged into the fault tree. Then the fault tree is modularised. The software holds within a library the decision tables and the flow diagram is a required input from the user. The flow diagram would incorporate the basic decision table of the components. The main feature of this software was the use of these super components and the ability to use CCF modelling and modularising fault trees.
A new method of describing a component’s behaviour was introduced by Majdara and Wakabayashi (2009). They introduce a new table, the state transition table, which describes the operational states of a component. An example of a component with operational states is a switch. This has the operational states of open and closed. Together with the function table is similar to the normal decision tables that have previously been discussed. The function table describes the input-output relationships. An example of both the functional and operational state tables can be seen in Tables 3.3 and 3.4. Figure 3.1 shows the visual relationship of the tables. Majdara and Wakabayashi introduced a new algorithm to generate a fault tree based on an occurrence of an undesirable event being defined. The algorithm uses the input and output connections between the components of a system in order to trace the cause of the undesirable event. The algorithm traces back from the occurrence and identifying component states or outputs that could cause the event. These would then be used to generate the fault tree.
When constructed the fault tree is checked for consistency. Where consistency means that two mutually exclusive events cannot occur at the same time. The algorithm would then remove these.
Operator
Valve
Command input Command output
Flow input Flow output
Figure 3.1: Operator-driven valve
Table 3.3: Operator-driven valve state transition table
First State Command Functionality Condition Next State
Open 2 OK Close
Open 2 Fail-to-close Open
Open 1 – Open
Close 1 OK Open
Close 1 Fail-to-open Close
Close 2 – Close
Open 0 – Open
Close 0 – Close
Table 3.4: Operator-driven valve function table
Flow input State Flow Output
0 – 0
– Close 0