Fault Tree Diagrams and System Analysis

BlockSim allows system modeling using both reliability block diagrams (RBDs) and fault trees. This chapter introduces basic fault tree analysis and points out the similarities (and differences) between RBDs and fault tree diagrams. Principles, methods and concepts discussed in previous chapters are used.

Fault trees and reliability block diagrams are both symbolic analytical logic techniques that can be applied to analyze system reliability and related characteristics. Although the symbols and structures of the two diagram types differ, most of the logical constructs in a fault tree diagram (FTD) can also be modeled with a reliability block diagram (RBD). This chapter presents a brief introduction to fault tree analysis concepts and illustrates the similarities between fault tree diagrams and reliability block diagrams.

=Fault Tree Analysis: Brief Introduction= Bell Telephone Laboratories developed the concept of fault tree analysis in 1962 for the U.S. Air Force for use with the Minuteman system. It was later adopted and extensively applied by the Boeing Company. A fault tree diagram follows a top-down structure and represents a graphical model of the pathways within a system that can lead to a foreseeable, undesirable loss event (or a failure). The pathways interconnect contributory events and conditions using standard logic symbols (AND, OR, etc.).

Fault tree diagrams consist of gates and events connected with lines. The AND and OR gates are the two most commonly used gates in a fault tree. To illustrate the use of these gates, consider two events (called "input events") that can lead to another event (called the "output event"). If the occurrence of either input event causes the output event to occur, then these input events are connected using an OR gate. Alternatively, if both input events must occur in order for the output event to occur, then they are connected by an AND gate. The following figure shows a simple fault tree diagram in which either A or B must occur in order for the output event to occur. In this diagram, the two events are connected to an OR gate. If the output event is system failure and the two input events are component failures, then this fault tree indicates that the failure of A or B causes the system to fail.



The RBD equivalent for this configuration is a simple series system with two blocks, A and B, as shown next.



=Basic Gates= Gates are the logic symbols that interconnect contributory events and conditions in a fault tree diagram. The AND and OR gates described above, as well as a Voting OR gate in which the output event occurs if a certain number of the input events occur (i.e., k-out-of-n redundancy), are the most basic types of gates in classical fault tree analysis. These gates are explicitly provided for in BlockSim and are described in this section along with their BlockSim implementations. Additional gates are introduced in the following sections.

A fault tree diagram is always drawn in a top-down manner with lowest item being a basic event block. Classical fault tree gates have no properties (i.e., they cannot fail).

Combining Basic Gates
As in reliability block diagrams where different configuration types can be combined in the same diagram, fault tree analysis gates can also be combined to create more complex representations. As an example, consider the fault tree diagram shown in the figures below.





=New BlockSim Gates=

In addition to the gates defined above, other gates exist in classical FTA. These additional gates (e.g., Sequence Enforcing, Priority AND, etc.) are usually used to describe more complex redundancy configurations and are described in later sections. First, we will introduce two new advanced gates that can be used to append to and/or replace classical fault tree gates. These two new gates are the Load Sharing and Standby gates. Classical fault trees (or any other fault tree standard to our knowledge) do not allow for load sharing redundancy (or event dependency). To overcome this limitation, and to provide fault trees with the same flexibility as BlockSim's RBDs, we will define a Load Sharing gate in this section. Additionally, traditional fault trees do not provide the full capability to model standby redundancy configurations (including the quiescent failure distribution), although basic standby can be represented in traditional fault tree diagrams using a Priority AND gate or a Sequence Enforcing gate, discussed in later sections.

Load Sharing Gate


A Load Sharing gate behaves just like BlockSim's Load Sharing containers for RBDs. Load Sharing containers were discussed in Time-Dependent System Reliability (Analytical) and RBDs and Analytical System Reliability. Events leading into a Load Sharing gate have distributions and life-stress relationships, just like contained blocks. Furthermore, the gate defines the load and the number required to cause the output event (i.e., the Load Sharing gate is defined with a k-out-of-n vote ). In BlockSim, no additional gates are allowed below a Load Sharing gate.

Standby Gate


A Standby gate behaves just like a standby container in BlockSim's RBDs. Standby containers were discussed in Time-Dependent System Reliability (Analytical) and RBDs and Analytical System Reliability. Events leading into a Standby gate have active and quiescent failure distributions, just like contained blocks. Furthermore, the gate acts as the switch, can fail and can also define the number of active blocks whose failure would cause system failure (i.e., the Active Vote Number required ). In BlockSim, no additional gates are allowed below a Standby gate.

Example
Consider a system with two units, A and B, in a standby configuration. Unit $$A$$  is active and unit  B is in a "warm" standby configuration. Furthermore, assume perfect switching (i.e., the switch cannot fail and the switch occurs instantly). Units A and B have the following failure properties:


 * Block $$A$$  (Active):
 * Failure Distribution: Weibull; $$\beta = 1.5\,\!$$;  $$\eta = 1,000\,\!$$  hours.


 * Block $$B$$  (Standby):
 * Energized failure distribution: Weibull; $$\beta =1.5\,\!$$;  $$\eta = 1,000\,\!$$  hours.
 * Quiescent failure distribution: Weibull; $$\beta =1.5\,\!$$;  $$\eta = 2,000\,\!$$  hours.

Determine the reliability of the system for 500 hours.

Solution

The fault tree diagram for this configuration is shown next and $$R(t=500)=94.26%\,\!$$.



=Additional Classical Gates and Their Equivalents in BlockSim=

Sequence Enforcing Gate
Various graphical symbols have been used to represent a Sequence Enforcing gate. It is a variation of an AND gate in which each item must happen in sequence. In other words, events are constrained to occur in a specific sequence and the output event occurs if all input events occur in that specified sequence. This is identical to a cold standby redundant configuration (i.e., $$k$$  units in standby with no quiescent failure distribution and no switch failure probability). BlockSim does not explicitly provide a Sequence Enforcing gate; however, it can be easily modeled using the more advanced Standby gate, described previously.

Inhibit Gate
In an Inhibit gate, the output event occurs if all input events occur and an additional conditional event occurs. It is an AND gate with an additional event. In reality, an Inhibit gate provides no additional modeling capabilities but is used to illustrate the fact that an additional event must also occur. As an example, consider the case where events A and B must occur as well as a third event C (the so-called conditional event) in order for the system to fail. One can represent this in a fault tree by using an AND gate with three events, A, B and C, as shown next.



Classical fault tree diagrams have the conditional event drawn to the side and the gate drawn as a hexagon, as shown next.



It should be noted that both representations are equivalent from an analysis standpoint.

BlockSim explicitly provides an Inhibit gate. This gate functions just like an AND gate with the exception that failure/repair characteristics can be assigned to the gate itself. This allows the construction shown above (if the gate itself is set to not fail). Additionally, one could encapsulate event C inside the gate (since the gate can have properties), as shown next. Note that all three figures can be represented using a single RBD with events A, B and C in parallel.



Priority AND Gate


With a Priority AND gate, the output event occurs if all input events occur in a specific sequence. This is an AND gate that requires that all events occur in a specific sequence. At first, this may seem identical to the Sequence Enforcing gate discussed earlier. However, it differs from this gate in the fact that events can occur out of sequence (i.e., are not constrained to occur in a specific sequence) but the output event only occurs if the sequence is followed. To better illustrate this, consider the case of two motors in standby configuration with motor $$A$$  being the primary motor and motor B in standby. If motor A fails, then the switch (which can also fail) activates motor B. Then the system will fail if motor A fails and the switch fails to switch, or if the switch succeeds but motor B fails subsequent to the switching action. In this scenario, the events must occur in the order noted; however, it is possible for the switch or motor B to fail (in a quiescent mode) without causing a system failure, if A never fails. BlockSim does not explicitly provide a Priority AND gate. However, like the Sequence Enforcing gate, it can be easily modeled using the more advanced Standby gate.

Transfer Gate


Transfer in/out gates are used to indicate a transfer/continuation of one fault tree to another. In classical fault trees, the Transfer gate is generally used to signify the continuation of a tree on a separate sheet. This is the same as a subdiagram block in an RBD. BlockSim does not explicitly provide a Transfer gate. However, it does allow for subdiagrams (or sub-trees), which provide for greater flexibility. Additionally, a subdiagram in a BlockSim fault tree can be an RBD and vice versa. BlockSim uses the more intuitive folder symbol to represent subdiagrams.



As an example, consider the fault tree of the robot manipulator shown in the first figure ("A") below. The second figure ("B") illustrates the same fault tree with the use of subdiagrams (Transfer gates). The referenced subdiagrams are shown in subsequent figures. Note that this is using multiple levels of indenture (i.e., the subdiagram has subdiagrams and so forth).















The RBD representation of the fault tree shown in the first figure is given in Figure "H". This same RBD could have been represented using subdiagrams, as shown in Figure "I". In this figure, which is the RBD representation of Figure "B", the subdiagrams in the RBD link to the fault trees of Figures "D" and "C" and their sub-trees.





XOR Gate


In an XOR gate, the output event occurs if exactly one input event occurs. This is similar to an OR gate with the exception that if more than one input event occurs then the output event does not occur. For example, if there are two input events then the XOR gate indicates that the output event occurs if only one of the input events occurs but not if zero or both of these events occur. From a system reliability perspective, this would imply that a two-component system would function even if both components had failed. Furthermore, when dealing with time-varying failure distributions, and if system components do not operate through failure, a failure occurrence of both components at the exact same time ( $$dt)$$ is an unreachable state; thus an OR gate would suffice. For these reasons, an RBD equivalent of an XOR gate is not presented here and BlockSim does not explicitly provide an XOR gate.

=Event Classifications= Traditional fault trees use different shapes to represent different events. Unlike gates, however, different events in a fault tree are not treated differently from an analytical perspective. Rather, the event shapes are used to convey additional information visually. BlockSim includes some of the main event symbols from classical fault tree analysis and provides utilities for changing the graphical look of a block to illustrate a different type of event. Some of these event classifications are given next. From a properties perspective, all events defined in BlockSim can have fixed probabilities, failure distributions, repair distributions, crews, spares, etc. In other words, fault tree event blocks can have all the properties that an RBD block can have. This is an enhancement and a significant expansion over traditional fault trees, which generally include just a fixed probability of occurrence and/or a constant failure rate.

Basic Event


A basic event (or failure event) is identical to an RBD block and has been traditionally represented by a circle.

Undeveloped Event


An undeveloped event has the same properties as a basic event with the exception that it is graphically rendered as a diamond. The diamond representation graphically illustrates that this event could have been expanded into a separate fault tree but was not. In other words, the analyst uses a different symbol to convey that the event could have been developed (broken down) further but he/she has chosen not to do so for the analysis.

House Event


A house event is an event that can be set to occur or not occur (i.e., it usually has a fixed probability of 0 or 1). It is usually used to turn paths on or off or to make paths of a tree functional or non-functional. Furthermore, the terms failed house and working house have been used to signify probabilities of 0 and 1 respectively. In BlockSim, a house shape is available for an event and a house event has the same properties as a basic event, keeping in mind that an event can be set to Cannot Fail or Failed from the block properties window.

Conditional Event


A conditional event is represented by an ellipse and specifies a condition. Again, it has all the properties of a basic event. It can be applied to any gate. As an example, event $$C$$  in the first figure below would be the conditional event and it would be represented more applicably by an ellipse than a circle, as shown in the second figure below.





=Comparing Fault Trees and RBDs= The most fundamental difference between fault tree diagrams and reliability block diagrams is that you work in the success space in an RBD while you work in the failure space in a fault tree. In other words, the RBD considers success combinations while the fault tree considers failure combinations. In addition, fault trees have traditionally been used to analyze fixed probabilities (i.e., each event that comprises the tree has a fixed probability of occurring) while RBDs may include time-varying distributions for the success (reliability equation) and other properties, such as repair/restoration distributions. In general (and with some specific exceptions), a fault tree can be easily converted to an RBD. However, it is generally more difficult to convert an RBD into a fault tree, especially if one allows for highly complex configurations.

As you can see from the discussion to this point, an RBD equivalent exists for most of the constructs that are supported by classical fault tree analysis. With these constructs, you can perform the same powerful system analysis, including simulation, regardless of how you choose to represent the system thus erasing the distinction between fault trees and reliability block diagrams.

=Using Mirrored Blocks to Represent Complex RBDs as FTDs= A fault tree cannot normally represent a complex RBD. As an example, consider the RBD shown in the figure below.



A fault tree representation for this RBD is:



Note that the same event is used more than once in the fault tree diagram. To correctly analyze this, the duplicate events need to be set up as "mirrored" events to the parent event. In other words, the same event is represented in two locations in the fault tree diagram. It should be pointed out that the RBD in the following figure is also equivalent to the RBD shown earlier and the fault tree of the figure shown above.



=Fault Trees and Simulation=

The slightly modified constructs in BlockSim erase the distinction between RBDs and fault trees. Given this, any analysis that is possible in a BlockSim RBD (including throughput analysis) is also available when using fault trees.

As an example, consider the RBD shown in the first figure below and its equivalent fault tree representation, as shown in the second figure.





Furthermore, assume the following basic failure and repair properties for each block and event:


 * Block A:
 * o	Failure Distribution: Weibull; $$\beta = 1/5\,\!$$;  $$\eta = 1,000\,\!$$.
 * o	Corrective Distribution: Weibull; $$\beta = 1.5 \,\!$$ ;  $$\eta = 100\,\!$$.
 * Block B:
 * o	Failure Distribution: Exponential; $$\mu = 10,000 \,\!$$.
 * o	Corrective Distribution: Weibull; $$\beta = 1.5 \,\!$$;  $$\eta = 20\,\!$$.
 * Block C:
 * o	Failure Distribution: Normal; $$\mu = 1,000\,\!$$;  $$\sigma = 200\,\!$$.
 * o	Corrective Distribution: Normal; $$\mu = 6\,\!$$;  $$\sigma = 2\,\!$$.
 * Block D:
 * o	Failure Distribution: Weibull; $$\beta = 1.5\,\!$$;  $$\eta = 10,000\,\!$$.
 * o	Corrective Distribution: Exponential; $$\mu = 10\,\!$$.
 * Block E:
 * o	Failure Distribution: Weibull; $$\beta = 3\,\!$$;  $$\eta = 1,000\,\!$$.
 * o	Corrective Distribution: Weibull; $$\beta = 1.5\,\!$$;  $$\eta = 20\,\!$$.
 * Block F:
 * o	Failure Distribution: Weibull; $$\beta = 1.5\,\!$$;  $$\eta = 5,000\,\!$$.
 * o	Corrective Distribution: Weibull; $$\beta = 1.5\,\!$$;  $$\eta = 100\,\!$$.
 * Block G:
 * o	Failure Distribution: Exponential; $$\mu = 100,000\,\!$$.
 * o	Corrective Distribution: Weibull; $$\beta = 1.5\,\!$$;  $$\eta = 10\,\!$$.
 * Block H:
 * o	Failure Distribution: Normal; $$\mu = 5,000\,\!$$;  $$\sigma = 50\,\!$$.
 * o	Corrective Distribution: Normal; $$\mu = 10\,\!$$;  $$\sigma = 2\,\!$$.

A sample table of simulation results is given next for up to $$t=1,000\,\!$$, using  $$2,000\,\!$$  simulations for each diagram and an identical seed.



As expected, the results are equivalent (within an expected difference due to simulation) regardless of the diagram type used. It should be pointed out that even though the same seed was used by both diagrams, the results are not always expected to be identical because the order in which the blocks are read from a fault tree diagram during the simulation may differ from the order in which they are read in the RBD; thus using a different random number stream for each block (e.g., block G in the RBD may receive a different sequence of random numbers than event block G in the FT).

=Additional Fault Tree Topics=

Minimal Cut Sets
Traditional solution of fault trees involves the determination of so-called minimal cut sets. Minimal cut sets are all the unique combinations of component failures that can cause system failure. Specifically, a cut set is said to be a minimal cut set if, when any basic event is removed from the set, the remaining events collectively are no longer a cut set Kececioglu [10]. As an example, consider the fault tree shown in the figure below. The system will fail if {1, 2, 3 and 4 fail} or {1, 2 and 3 fail} or {1, 2 and 4 fail}.



All of these are cut sets. However, the one including all components is not a minimal cut set because, if 3 and 4 are removed, the remaining events are also a cut set. Therefore, the minimal cut sets for this configuration are {1, 2, 3} or {1, 2, 4}. This may be more evident by examining the RBD equivalent of the figure above, as shown in the figure below.



BlockSim does not use the cut sets methodology when analyzing fault trees. However, interested users can obtain these cut sets for both fault trees and block diagrams with the command available in the Analysis Ribbon.