View source for Fault Tree Diagrams and System Analysis

{{Template:bsbook|10}}



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 Tree and Reliability Block Diagrams=
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.
<br>
===Fault Tree Analysis: Brief Introduction===
<br>
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.).
<br>

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.  Figure “Fault tree where the occurrence of either ''A'' or ''B'' can cause system failure” shows a simple fault tree diagram in which either  <math>A</math>  or  <math>B</math>  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  <math>A</math>  or  <math>B</math>  causes the system to fail.  The RBD equivalent for this configuration is a simple series system with two blocks,  <math>A</math>  and  <math>B</math> , as shown in Figure “he RBD representation of the fault tree”.
<br>

[[Image:1.png|thumb|center|500px|Fault tree where the occurrence of either ''A'' or ''B'' can cause system failure.]]
<br>
<br>
[[Image:10.2.gif|thumb|center|200px|The RBD representation of the fault tree.]]
<br>
[[Category:Completed Theoretical Review]]

=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.  <math>k</math> -out-of- <math>n</math>  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.  
<br>

===AND Gate===
<br>
[[Image:I10.1.gif|thumb|center|400px|]]
<math></math>

In an AND gate, the output event occurs if all input events occur.  In system reliability terms, this implies that all components must fail (input) in order for the system to fail (output).  When using RBDs, the equivalent is a simple parallel configuration.
<br>
{{BlockSim Analytical Fault Tree Diagram Example}}

===OR Gate===
<br>
In an OR gate, the output event occurs if at least one of the input events occurs.  In system reliability terms, this implies that if any component fails (input) then the system will fail (output).  When using RBDs, the equivalent is a series configuration.
<br>
<br>
[[Image:I10.4.gif|thumb|center|400px|]]
<br>

====Example====
<br>
Consider a system with three components,  <math>A,</math>   <math>B</math>  and  <math>C</math> .  The system fails if  <math>A,</math>   <math>B</math>  or  <math>C</math>  fails.  Draw the fault tree and reliability block diagram for the system.  The next two figures show both the FTD and RBD representations.
<br>
[[Image:I10.5.gif|thumb|center|400px|]]
<br>
[[Image:I10.6.gif|thumb|center|400px|]]
<br>

<br>
The reliability equation for either configuration is: 
<br>

::<math>{{R}_{System}}={{R}_{A}}\cdot {{R}_{B}}\cdot {{R}_{C}}</math>

<br>

===Voting OR Gate===
<br>
[[Image:I10.7.gif|thumb|center|400px|]]
<br>

In a Voting OR gate, the output event occurs if  <math>k</math>  or more of the input events occur.  In system reliability terms, this implies that if any  <math>k</math> -out-of- <math>n</math>  components fail (input) then the system will fail (output).  
<br>

The equivalent RBD construct is a node and is similar to a  <math>k</math> -out-of- <math>n</math>  parallel configuration with a distinct difference, as discussed next.  To illustrate this difference, consider a fault tree diagram with a  <math>2</math> -out-of- <math>4</math>  Voting OR gate, as shown in Figure “Illustration of a 2-out-or-4 Voting OR gate”.  In this diagram, the system will fail if any two of the blocks below fail.  Equivalently, this can be represented by the RBD shown in Figure “Equivalent representation of the 2-out-of-4 Voting OR gate” using a  <math>3</math> -out-of- <math>4</math>  node.  
<br>

In this configuration, the system will not fail if three out of four components are operating, but will fail if more than one fails.  In other words, the fault tree considers  <math>k</math> -out-of- <math>n</math>  failures for the system failure while the RBD considers  <math>k</math> -out-of- <math>n</math>  successes for system success.

[[Image:10.3.gif|thumb|center|400px|Illustration of a 2-out-or-4 Voting OR gate.]]
<br>
[[Image:10.4.gif|thumb|center|400px|Equivalent representation of the 2-out-of-4 Voting OR gate.]]

<br>
 
====Expanding the Classical Voting OR Gate====
<br>
Classical Voting OR gates have no properties and cannot fail or be repaired (i.e. they cannot be an event themselves).  In BlockSim, Voting OR gates behave like nodes in an RBD; thus, they can also fail and be repaired just like any other event.  By default, when a Voting OR gate is inserted into an FTD within BlockSim, the gate is set so that it cannot fail (classical definition).  However, this property can be modified to allow for additional flexibility.   
<br>

====Example====
<br>
Consider a system with three components,  <math>A,</math>   <math>B</math>  and  <math>C</math> .  The system fails if any two components fail.  Draw the fault tree and reliability block diagram for the system.  The next two figures show both the FTD and RBD representations.

<br>
<center>[[Image:I10.8.gif|thumb|center|300px|]][[Image:I10.9.gif|thumb|center|300px|]]</center>

<br>
The reliability equation for either configuration is:


<br>
::<math>{{R}_{System}}=-2\cdot {{R}_{A}}\cdot {{R}_{B}}\cdot {{R}_{C}}+{{R}_{A}}\cdot {{R}_{B}}+{{R}_{A}}\cdot {{R}_{C}}+{{R}_{B}}\cdot {{R}_{C}}\ </math>
<br>

Equation above assumes a classical Voting OR gate (i.e. the voting gate itself cannot fail).  If the gate can fail then the equation is modified as follows:
<br>

::<math>{{R}_{System}}={{R}_{Voting}}\left( -2\cdot {{R}_{A}}\cdot {{R}_{B}}\cdot {{R}_{C}}+{{R}_{A}}\cdot {{R}_{B}}+{{R}_{A}}\cdot {{R}_{C}}+{{R}_{B}}\cdot {{R}_{C}} \right)</math>
<br>

Note that while both the gate and the node are 2-out-of-3, they represent different circumstances.  The Voting OR gate in the fault tree indicates that if two components fail then the system will fail; while the node in the reliability block diagram indicates that if at least two components succeed then the system will succeed.  
<br>

===Combining Basic Gates===
<br>
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 figures below.  
<br>
<br>
[[Image:10.5.gif|thumb|center|500px|A sample FTD using different gates.]]
<br>
<br>
[[Image:10.6.gif|thumb|center|300px|RBD representation of the FTD shown in figure above.]]
<br>

===Discussion of Basic Gates and Events===
<br>
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).
<br>

=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.  
<br>

===Load Sharing Gate===
<br>
[[Image:I10.10.gif|thumb|center|400px|]]
<br>

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)|Time-Dependent System Reliability (Analytical)]] and [[RBDs_and_Analytical_System_Reliability|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  <math>k</math> -out-of- <math>n</math>  vote ).  In BlockSim, no additional gates are allowed below a Load Sharing gate.
<br>

====Example====
<br>
A component has five possible failure modes,  <math>A</math> ,  <math>{{B}_{A}}</math> ,  <math>{{B}_{B}}</math> ,  <math>{{B}_{C}}</math>  and  <math>C</math> , and the  <math>B</math>  modes are interdependent.  The system will fail if mode  <math>A</math>  occurs, mode  <math>C</math>  occurs or two out of the three  <math>B</math>  modes occur.  Modes  <math>A</math>  and  <math>C</math>  have a Weibull distribution with  <math>\beta =2</math>  and  <math>\eta =10,000</math>  and  <math>15,000</math>  respectively.  Events  <math>{{B}_{A}}</math> ,  <math>{{B}_{B}}</math>  and  <math>{{B}_{C}}</math>  have an exponential distribution with a mean of  <math>10,000</math>  hours.  If any  <math>B</math>  event occurs (i.e.  <math>{{B}_{A}}</math> ,  <math>{{B}_{B}}</math>  or  <math>{{B}_{C}}</math> ), the remaining  <math>B</math>  events are more likely to occur.  Specifically, the mean times of the remaining  <math>B</math>  events are halved.  Determine the reliability at  <math>1,000</math>  hours for this component.
<br>
====Solution to Example====
<br>
The first step is to create the fault tree as shown in figure below.  Note that both an OR gate and a Load Sharing gate are used.
<br>
[[Image:10.7.gif|thumb|center|400px| Fault tree for the example illustrating a Load Sharing gate.]]


<br>
The next step is to define the properties for each event block and the Load Sharing gate.  Setting the failure distributions for modes  <math>A</math>  and  <math>C</math>  is simple.  <br>
[[Image:10.8.gif|thumb|center|400px| Load sharing parameters.]]
<br>

The more difficult part is setting the properties of the Load Sharing gate (which are the same as an RBD container) and the dependent load sharing events (which are the same as the contained blocks in an RBD).  Based on the problem statement, the  <math>B</math>  modes are in a 2-out-of-3 load sharing redundancy.  When all three are working (i.e. when no  <math>B</math>  mode has occurred), each block has an exponential distribution with  <math>\mu =10,000</math> .  If one  <math>B</math>  mode occurs, then the two surviving units have an exponential distribution with  <math>\mu =5,000.</math> 
<br>
Assume an inverse power life-stress relationship for the components.  Then:

<br>
::<math>{{\mu }_{1}}= \frac{1}{KV_{1}^{n}}\ </math>

::<math>{{\mu }_{2}}= \frac{1}{KV_{2}^{n}}\ </math>
<br>

Substituting  <math>{{\mu }_{1}}=10,000</math>  and  <math>{{V}_{1}}=1</math>  in <math>{{\mu}_{1}}= \frac{1}{KV_{1}^{n}}\ </math> and casting it in terms of  <math>K</math>  yields:
<br>


::<math>\begin{align}
10,000= & \frac{1}{K} \\
K= & \frac{1}{10,000}=0.0001  
\end{align}</math>

<br>

Substituting  <math>{{\mu }_{2}}=5,000</math> ,  <math>{{V}_{2}}=1.5</math>  (because if one fails, then each survivor takes on an additional 0.5 units of load) and <math>10,000=\frac{1}{K} </math> for  <math>K</math>  in <math>{{\mu }_{2}}= \frac{1}{KV_{2}^{n}}\ </math> yields:

<br>

::<math>\begin{align}
5,000= & \frac{1}{0.0001\cdot {{(1.5)}^{n}}} \\ 
0.5= & {{(1.5)}^{-n}} \\ 
\ln (0.5)= & -n\ln (1.5) \\ 
n= & 1.7095  
\end{align}</math>

<br>

This also could have been computed in ReliaSoft's ALTA software or with the Load & Life Parameter Experimenter in BlockSim.  This was done in Chapter 5.
<br>

At this point, the parameters for the load sharing units have been computed and can be set, as shown in Figure "Load sharing parameters". (Note: when define the IPL-Exponential model, we just need to specify the value for K and n, the value for Use Stress is not a issue here, leave it as default number 10 or any number will be good.)

<br>

The next step is to set the weight proportionality factor.  This factor defines the portion of the load that the particular item carries while operating, as well as the load that shifts to the remaining units upon failure of the item.  To illustrate, assume three units (1, 2 and 3) are in a load sharing redundancy, represented in the fault tree diagram by a Load Sharing gate, with weight proportionality factors of 1, 2 and 3 respectively (and a 3-out-of-3 requirement).
<br>
:•	Unit 1 carries  <math>\left( \tfrac{1}{1+2+3} \right)=0.166</math>  or 16.6% of the total load.
:•	Unit 2 carries  <math>\left( \tfrac{2}{1+2+3} \right)=0.333</math>  or 33.3% of the total load.
:•	Unit 3 carries  <math>\left( \tfrac{3}{1+2+3} \right)=0.50</math>  or 50% of the total load.
<br>
<br>
The actual load on each unit then becomes the product of the entire load defined for the gate multiplied by the portion carried by that unit.  For example, if the load is 100 lbs, then the portion assigned to Unit 1 will be  <math>100\cdot 0.166=16.6</math>  lbs.

In the current example, all units share the same load; thus, they have equal weight proportionality factors.  Because these factors are relative, if the same number is used for all three items then the results will be the same.  For simplicity, we will set the factor equal to 1 for each item.
<br>

Once the properties have been specified in BlockSim, the reliability at 1000 hours can be determined. From the Analytical QCP, this is found to be 93.87%.

===Standby Gate===
<br>
[[Image:SB.gif|thumb|center|400px|]]
<br> 

A Standby gate behaves just like a standby container in BlockSim's RBDs.  Standby containers were discussed in [[Time-Dependent_System_Reliability_(Analytical)|Time-Dependent System Reliability (Analytical)]] and [[RBDs_and_Analytical_System_Reliability|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.
<br>
====Example====
<br>
Consider a system with two units,  <math>A</math>  and  <math>B</math> , in a standby configuration. Unit  <math>A</math>  is active and unit  <math>B</math>  is in a ``warm'' standby configuration. Furthermore, assume perfect switching (i.e. the switch cannot fail and the switch occurs instantly).  Units  <math>A</math>  and  <math>B</math>  have the following failure properties:
<br>
:•	Block  <math>A</math>  (Active):
::o	Failure Distribution: Weibull;  <math>\beta </math> =1.5;  <math>\eta </math> = <math>1,000</math>  hours.
:•	Block  <math>B</math>  (Standby):
::o	Energized failure distribution: Weibull;  <math>\beta </math> =1.5;  <math>\eta </math> = <math>1,000</math>  hours.
::o	Quiescent failure distribution: Weibull;  <math>\beta </math> =1.5;  <math>\eta </math> = <math>2,000</math>  hours.
<br>
Determine the reliability of the system for  <math>500</math>  hours.
 
<br>

====Example Solution====
<br>
The fault tree diagram for this configuration is shown next and  <math>R(t=500)=94.26%</math> .
<br>
[[Image:I10.11.gif|thumb|center|400px|]]
<br>

=Additional Classical Gates and Their Equivalents in BlockSim=
===Sequence Enforcing Gate===
<br>
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.  <math>k</math>  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.  
<br>
===Inhibit Gate===
<br>
[[Image:I10.12.gif|thumb|center|400px|]]
<br>

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  <math>A</math>  and  <math>B</math>  must occur as well as a third event  <math>C</math>  (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,  <math>A</math> ,  <math>B</math>  and  <math>C</math> , as shown in Figure "Using an AND gate to represent an inhibit relationship".  Classical fault tree diagrams have the conditional event drawn to the side and the gate drawn as a hexagon, as shown Figure "Traditional use of an Inhibit gate".  It should be noted that both representations are equivalent from an analysis standpoint.
<br>

<br>
[[Image:10.10.gif|thumb|center|400px|Using an AND gate to represent an inhibit relationship.]]
<br>
<br>
[[Image:10.11.gif|thumb|center|400px|Traditional use of an Inhibit gate.]]
<br>
<br>
[[Image:10.12.gif|thumb|center|400px|Including the conditional event inside the Inhibit gate.]]
<br>
<br>
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 in Figure "Traditional use of an Inhibit gate"(if the gate itself is set to not fail).  Additionally, one could encapsulate event  <math>C</math>  inside the gate (since the gate can have properties), as shown Figure "Including the conditional event inside the Inhibit gate".  Note that all three figures can be represented using a single RBD with events  <math>A</math> ,  <math>B</math>  and  <math>C</math>  in parallel.
<br>

===Priority AND Gate===
<br>
[[Image:I10.13.gif|thumb|center|400px|]]
<br>
<br>

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  <math>A</math>  being the primary motor and motor  <math>B</math>  in standby.  If motor  <math>A</math>  fails, then the switch (which can also fail) activates motor  <math>B</math> .  Then the system will fail if motor  <math>A</math>  fails and the switch fails to switch, or if the switch succeeds but motor  <math>B</math>  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  <math>B</math>  to fail (in a quiescent mode) without causing a system failure, if  <math>A</math>  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.   
<br>

===Transfer Gate===
[[Image:I10.14.gif|thumb|center|400px|]]
<br>
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.
<br>
[[Image:i10.15.gif|thumb|center|400px|]]
<br>
As an example, consider the fault tree of the robot manipulator shown in Figure figrobotall.  Figure robotsubdiagram 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).
<br>
The RBD representation of the fault tree shown in Figure "A" 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.
<br>
[[Image:BS10.13.png|thumb|center|400px|A: A sample fault tree for a robot manipulator, showing all items in a single tree.]]
<br>
[[Image:10.14.gif|thumb|center|400px|B: The fault tree of Figure 10.12 using subdiagrams (Transfer gates). The subdiagrams are shown in Figures "C" and "D".]]
<br>
[[Image:10.15.gif|thumb|center|400px|C: The fault tree of the robot arm mechanism. This subdiagram is referenced in Figure "B".]]
<br>
[[Image:10.16.gif|thumb|center|400px|D: The fault tree for the arm jams/collides event. This subdiagram is referenced in Figure "B". It also includes a subdiagram continuation to Figure "E".]]
<br>
[[Image:10.17.gif|thumb|center|400px|E: The brake shutdown event referenced from Figure "D". it also includes a subdiagram continuation to Figure "F".]]
<br>
[[Image:10.18.gif|thumb|center|400px|F: The watchdog ESD fails event referenced from Figure "F". It also includes a subdiagram continuation to Figure "G"]]
<br>
[[Image:10.19.gif|thumb|center|400px|G: The communication fails event referenced from Figure "G".]]
<br>
[[Image:10.20.gif|thumb|center|400px|H: This is the RBD equivalent of the complete fault tree of Figure "A".]]
<br>
[[Image:10.21.gif|thumb|center|400px|I: The RBD representation of Figure "B" with the subdiagrams in the RBD linked to the fault trees of Figures "C" and "D" and their sub-trees.]]
<br>

===XOR Gate===
<br>
[[Image:I10.16.gif|thumb|center|400px|]]
<br>

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 ( <math>dt)</math>  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.  
<br>

=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.
<br>
===Basic Event===
<br>
[[Image:5.png|thumb|center|300px|]]
<br>
A basic event (or failure event) is identical to an RBD block and has been traditionally represented by a circle.
<br>

===Undeveloped Event===
<br>
[[Image:diamond.gif|thumb|center|300px|]]
<br>
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.
<br>

===House Event===
[[Image:pentagon.gif|thumb|center|300px|]]
<br>

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.
<br>

===Conditional Event===
[[Image:oval.gif|thumb|center|300px|]]

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  <math>C</math>  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.
<br>
<br>
[[Image:10.10.gif|thumb|center|400px|Using an AND gate to represent an inhibit relationship.]]
[[Image:10.22.gif|thumb|center|400px|Using an ellipse attached to an inhubit gate (with no gate properties) to show the conditional event. This is mathematically equivalent to figure above.]]
<br>

=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.
<br>
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.
<br>
===Example Using Both RBDs and Fault Trees===
<br>
Assume that a component can fail due to six independent primary failure modes:  <math>A</math> ,  <math>B</math> ,  <math>C</math> ,  <math>D</math> ,  <math>E</math>  and  <math>F</math> .  Some of these primary modes can be broken down further into the events that can cause them, or sub-modes.  Furthermore, assume that once a mode occurs, the event also occurs and the mode does not go away.  Specifically:
<br>
:•	The component fails if mode  <math>A</math> ,  <math>B</math>  or  <math>C</math>  occurs.
:•	If mode  <math>D</math> ,  <math>E</math>  or  <math>F</math>  occurs alone, the component does not fail; however, the component will fail if any two (or more) of these modes occur (i.e.  <math>D</math>  and  <math>E</math> ;  <math>D</math>  and  <math>F</math> ;  <math>E</math>  and  <math>F</math> ).
:•	Modes  <math>D</math> ,  <math>E</math>  and  <math>F</math>  have a constant rate of occurrence (exponential distribution) with mean times of occurrence of  <math>200,000</math> ,  <math>175,000</math>  and  <math>500,000</math>  hours, respectively.
:•	The rates of occurrence for modes  <math>A</math> ,  <math>B</math>  and  <math>C</math>  depend on their sub-modes.
<br>
Do the following:

::#Determine the reliability of the component after 1 year ( <math>8,760</math>  hours).
::#Determine the B10 life of the component.
::#Determine the mean time to failure ( <math>MTTF</math> ) of the component.
::#Rank the modes in order of importance at 1 year.
::#Re-calculate results 1, 2 and 3 assuming mode  <math>B</math>  is eliminated.

To begin the analysis, modes  <math>A</math> ,  <math>B</math>  and  <math>C</math>  can be broken down further based on specific events (sub-modes), as defined next.
<br>
<br>
'''Mode  <math>A</math>'''
<br>
<br>
There are five independent events (sub-modes) associated with mode  <math>A</math> : events  <math>S1</math> ,  <math>S2</math> ,  <math>T1</math> ,  <math>T2</math>  and  <math>Y</math> .  It is assumed that events  <math>S1</math>  and  <math>S2</math>  each have a constant rate of occurrence with a probability of occurrence in a single year ( <math>8760</math>  hours) of  <math>1</math>  in  <math>10,000</math>  and  <math>1</math>  in  <math>20,000</math> , respectively.  Events  <math>T1</math>  and  <math>T2</math>  are more likely to occur in an older component than a newer one (i.e. they have an increasing rate of occurrence) and have a probability of occurrence of  <math>1</math>  in  <math>10,000</math>  and  <math>1</math>  in  <math>20,000</math> , respectively, in a single year and  <math>1</math>  in  <math>1,000</math>  and  <math>1</math>  in  <math>3,000</math> , respectively, after two years.  Event  <math>Y</math>  also has a constant rate of occurrence with a probability of occurrence of  <math>1</math>  in  <math>1,000</math>  in a single year.  There are three possible ways for mode  <math>A</math>  to manifest itself:
<br>
::#Events  <math>S1</math>  and  <math>S2</math>  both occur.
::#Event  <math>T1</math>  or  <math>T2</math>  occurs.
::#Event  <math>Y</math>  and either event  <math>S1</math>  or event  <math>S2</math>  occur (i.e. events  <math>Y</math>  and  <math>S1</math>  or events  <math>Y</math>  and  <math>S2</math>  occur).

'''RBD Solution for Mode  <math>A</math>'''

The RBD that satisfies the conditions for mode  <math>A</math>  is shown in figure below.

[[Image:6.png|thumb|center|400px|Reliability block diagram for mode A.]]
<br>

[[Image:7.png|thumb|center|400px|Fault tree for mode ''A''.]]
<br>

Each mode is identified in the RBD.  Furthermore, two additional items are included: a starting block ( <math>NF</math> ) and an end node (2/2).  The starting block and the end node are set so they cannot fail and, therefore, will not affect the results.  The end node is used to define a 2-out-of-2 configuration (i.e. both paths leading into the node must work).
<br>
<br>
'''Fault Tree Solution for Mode  <math>A</math>'''
<br>
<br>
The fault tree for mode  <math>A</math>  is shown in Figure "Fault tree for mode ''A''".  Each mode is identified as an event in the fault tree.  Figure below shows an alternative representation for mode  <math>A</math>  using mirrored events for  <math>S1</math>  and  <math>S2</math> .  Further discussion on mirrored events is provided in the next section.
[[Image:8.png|thumb|center|400px|An alternative representation of the fault tree for mode ''A'' using mirrored events.]]
<br>
<br>
'''Mode  <math>A</math>  Discussion'''
<br>
<br>
The system reliability equation for this configuration (regardless of how it is drawn) is:

<br>
::<math>\begin{align}
   R(t)= & -2{{R}_{T2}}\text{ }\!\!\cdot\!\!\text{ }{{R}_{S1}}\text{ }\!\!\cdot\!\!\text{ }{{R}_{S2}}\text{ }\!\!\cdot\!\!\text{ }{{R}_{T1}}\text{ }\!\!\cdot\!\!\text{ }{{R}_{Y}} \\ 
   & +{{R}_{T2}}\text{ }\!\!\cdot\!\!\text{ }{{R}_{S1}}\text{ }\!\!\cdot\!\!\text{ }{{R}_{S2}}\text{ }\!\!\cdot\!\!\text{ }{{R}_{T1}} \\ 
   & +{{R}_{T2}}\text{ }\!\!\cdot\!\!\text{ }{{R}_{S1}}\text{ }\!\!\cdot\!\!\text{ }{{R}_{T1}}\text{ }\!\!\cdot\!\!\text{ }{{R}_{Y}} \\ 
   & +{{R}_{T2}}\text{ }\!\!\cdot\!\!\text{ }{{R}_{S2}}\text{ }\!\!\cdot\!\!\text{ }{{R}_{T1}}\text{ }\!\!\cdot\!\!\text{ }{{R}_{Y}}  
\end{align}</math>
<br>

<br>
Based on the given probabilities, distribution parameters are computed for each block (either RBD block or the fault tree event block).  One way is to compute them using the Parameter Experimenter, as shown in figure below.  In this figure and for  <math>S1</math> , the probability is  <math>1</math>  in  <math>10,000</math>  in one year ( <math>8760</math>  hours), thus the exponential failure rate is 1.1416e-8.  This can be repeated for  <math>S2</math>  and  <math>Y</math> .
<br>

[[Image:10.26.gif|thumb|center|400px|BlockSim's Parameter Experimenter.]]
<br>
Events  <math>T1</math>  and  <math>T2</math>  need to be modeled using a life distribution that does not have a constant failure rate.  Using BlockSim's Parameter Experimenter and selecting the Weibull distribution, the parameter values for events  <math>T1</math>  and  <math>T2</math>  are shown in Figures below, respectively.
<br>
[[Image:10.27.gif|thumb|center|400px|Parameter vealues for event ''T''1.]]
<br>

[[Image:10.28.gif|thumb|center|400px|Parameter values for event ''T''2.]]
<br>
'''Mode  <math>B</math>'''
<br>
<br>
There are three dependent events associated with mode  <math>B</math> : events  <math>BA</math> ,  <math>BB</math>  and  <math>BC</math> .
<br>
:•	Two out of the three events must occur for mode  <math>B</math>  to occur.
::o	Events  <math>BA</math> ,  <math>BB</math>  and  <math>BC</math>  all have an exponential distribution with a mean of  <math>50,000</math>  hours.
::o	The events are dependent (i.e. if  <math>BA</math> ,  <math>BB</math>  or  <math>BC</math>  occurs, then the remaining events are more likely to occur).  Specifically, when one event occurs, the  <math>MTTF</math>  of the remaining events is halved.
<br>

This is basically a load sharing configuration.  The reliability function for each block will change depending on the other events.  Therefore, the reliability of each block is not only dependent on time, but also on the stress (load) that the block experiences.
<br>
<br>
'''RBD Solution for Mode  <math>B</math>'''
<br>
<br>
The reliability block diagram for mode  <math>B</math>  is shown in figure below.
[[Image:10.29.gif|thumb|center|400px|Reliability block diagram for mode ''B''.]]
<br>

<br>
'''Fault Tree Solution for Mode  <math>B</math>'''
<br>
The fault tree for mode  <math>B</math>  is shown in figure below.  A Load Sharing gate is used.
<br>
[[Image:10.30.gif|thumb|center|400px|Fault tree diagram for mode ''B''(using a Load Sharing gate unique to BlockSim).]]
::<math></math>

<br>

<br>
'''Mode  <math>B</math>  Discussion'''
<br>
<br>
To describe the dependency, a Load Sharing gate and dependent event blocks are used.  Since the failure rate is assumed to be constant, an exponential distribution is used.  Furthermore, for simplicity, an Arrhenius life-stress relationship is used with the parameters B=2.0794 and C=6250.
<br>

<br>
'''Mode  <math>C</math>'''
<br>
<br>
There are two sequential events associated with mode  <math>C</math> :  <math>CA</math>  and  <math>CB</math> .
<br>
:•	Both events must occur for mode  <math>C</math>  to occur.
:•	Event  <math>CB</math>  will only occur if event  <math>CA</math>  has occurred.
:•	If event  <math>CA</math>  has not occurred, then event  <math>CB</math>  will not occur.
:•	Events  <math>CA</math>  and  <math>CB</math>  both occur based on a Weibull distribution.
:•	For event  <math>CA</math> ,  <math>\beta </math>  =2 and  <math>\eta </math> =30,000 hours.
:•	For event  <math>CB</math> ,  <math>\beta </math>  =2 and  <math>\eta </math> =10,000 hours.
<br>
<br>
'''RBD Solution for Mode  <math>C</math>'''
<br>
<br>
To model this, you can think of a scenario similar to standby redundancy.  Basically, if  <math>CA</math>  occurs then  <math>CB</math>  gets initiated.  A Standby container can be used to model this, as shown in figure below.
<br>

[[Image:10.32.gif|thumb|center|400px|Standby container for mode C.]]
<br>

<br>
In this case, event  <math>CA</math>  is set as the active component and  <math>CB</math>  as the standby.  If event  <math>CA</math>  occurs,  <math>CB</math>  will be initiated.  For this analysis, a perfect switch is assumed.  The properties are set in BlockSim as follows:
<br>
Contained Items
<br>
:•	 <math>CA</math> : Active failure distribution, Weibull distribution ( <math>\beta </math> =2,  <math>\eta </math> =30,000).
:•	 <math>CA</math> : Quiescent failure distribution: None, cannot fail or age in this mode.
:•	 <math>CB</math> : Active failure distribution, Weibull distribution ( <math>\beta </math> =2,  <math>\eta </math> =10,000).
:•	 <math>CB</math> : Quiescent failure distribution: None, cannot fail or age in this mode.
<br>
Switch
<br>
:•	Active Switching: Always works (100% reliability) and instant switch (no delays).
:•	Quiescent Switch failure distribution: None, cannot fail or age in this mode.
<br>

'''Fault Tree Solution for Mode  <math>C</math>'''
The fault tree for mode  <math>C</math>  is shown in figure below.  Note that the sequence is enforced by the Standby gate (used as a Sequence Enforcing gate).

[[Image:10.31.png|thumb|center|400px|Standby (Sequence Enforcing) gate for model ''C'']]
<br>
<br>

'''Mode  <math>C</math>  Discussion'''
<br>
The failure distribution settings for event  <math>CA</math>  are shown in figure below.
[[Image:10.34.gif|thumb|center|400px|Failure distribution settings for event ''C'' ''A''.]]
<br>

The failure distribution properties for event  <math>CB</math>  are set in the same manner.
<br>



 
'''Modes  <math>D</math> ,  <math>E</math>  and  <math>F</math>'''
<br>
Modes  <math>D</math> ,  <math>E</math>  and  <math>F</math>  can all be represented using the exponential distribution.  The failure distribution properties for modes  <math>D</math> ,  <math>E</math>  and  <math>F</math>  are:
<br>
:•	 <math>D</math> :  <math>MTTF</math>  = 200,000 hours.
:•	 <math>E</math> :  <math>MTTF</math>  = 175,000 hours.
:•	 <math>F</math> :  <math>MTTF</math>  = 500,000 hours.
<br>
'''The Entire Component'''
<br>
The last step is to set up the model for the component based on the primary modes ( <math>A</math> ,  <math>B</math> ,  <math>C</math> ,  <math>D</math> ,  <math>E</math>  and  <math>F</math> ).  Modes  <math>A</math> ,  <math>B</math>  and  <math>C</math>  can each be represented by single blocks that encapsulate the subdiagrams already created.  The RBD in figure below represents the primary failure modes for the component while the fault tree in Figure "Fault tree of the component" illustrates the same.  The node represented by 2/3 in the RBD indicates a 2-out-of-3 configuration.  The Voting OR gate in the fault tree accomplishes the same.  Subdiagrams are used in both configurations for the sub-modes.
<br>
[[Image:10.35.gif|thumb|center|400px|RBD of the component.]]
<br>

Once the diagrams have been created, the reliability equation for the system can be obtained, as follows:
<br>
[[Image:10.36.gif|thumb|center|400px|Fault tree of the component.]]
<br>

::<math>\begin{align}
R{{(t)}_{System}}= & R{{(t)}_{A}}\text{ }\!\!\cdot\!\!\text{ }R{{(t)}_{B}}\text{ }\!\!\cdot\!\!\text{ }R{{(t)}_{F}}\text{ }\!\!\cdot\!\!\text{ }R{{(t)}_{D}}\text{ }\!\!\cdot\!\!\text{ }R{{(t)}_{C}} \\ 
  & +R{{(t)}_{A}}\text{ }\!\!\cdot\!\!\text{ }R{{(t)}_{B}}\text{ }\!\!\cdot\!\!\text{ }R{{(t)}_{F}}\text{ }\!\!\cdot\!\!\text{ }R{{(t)}_{C}}\text{ }\!\!\cdot\!\!\text{ }R{{(t)}_{E}} \\ 
  & +R{{(t)}_{A}}\text{ }\!\!\cdot\!\!\text{ }R{{(t)}_{B}}\text{ }\!\!\cdot\!\!\text{ }R{{(t)}_{D}}\text{ }\!\!\cdot\!\!\text{ }R{{(t)}_{C}}\text{ }\!\!\cdot\!\!\text{ }R{{(t)}_{E}} \\ 
  & -2(R{{(t)}_{A}}\text{ }\!\!\cdot\!\!\text{ }R{{(t)}_{B}}\text{ }\!\!\cdot\!\!\text{ }R{{(t)}_{F}}\text{ }\!\!\cdot\!\!\text{ }R{{(t)}_{D}}\text{ }\!\!\cdot\!\!\text{ }R{{(t)}_{C}}\text{ }\!\!\cdot\!\!\text{ }R{{(t)}_{E}})  
\end{align}</math>
<br>
Where  <math>R{{(t)}_{A}}</math> ,  <math>R{{(t)}_{B}}</math>  and  <math>R{{(t)}_{C}}</math>  are the reliability equations corresponding to the sub-modes.
<br>
'''Analysis'''
<br>


The questions posed earlier can be answered using BlockSim.  Regardless of the approach used (i.e. RBD or FTA), the answers are the same.
<br>
::1.	The reliability of the component at 1 year (8,760 hours) can be calculated using the Analytical Quick Calculation Pad (QCP) or by viewing the reliability vs. time plot, as displayed in Figure "Reliability vs. time plot for the component".  <math>R(t=8760)=86.4975%</math> .
::2.	Using the Analytical QCP, the B10 life of the component is estimated to be 7,373.94 hours.
::3.	Using the Analytical QCP, the mean life of the component is estimated to be 21,659.68 hours.
::4.	The ranking of the modes after 1 year can be shown via the Static Reliability Importance plot, as shown in Figure below.
::5.	Re-computing the results for 1, 2 and 3 assuming mode  <math>B</math>  is removed:
:::a)	 <math>R(t=8760)=98.72%.</math> 
:::b)	 <math>B10</math>  = 16,928.38 hours.
:::c)	 <math>MTTF</math>  = 34,552.89 hours.

[[Image:10.37.gif|thumb|center|400px|Reliability vs. time plot for the component.]]
<br>

[[Image:10.38.gif|thumb|center|400px|Static reliability importance for each of the modes at ''t''=8,760 hours.]]
<br>

'''Discussion'''
<br>
There are multiple options for modeling systems with fault trees and RBDs in BlockSim.  The first figure below shows the complete fault tree for the component without using subdiagrams (Transfer gates) while the second figure below illustrates a hybrid analysis utilizing an RBD for the component and fault trees as the subdiagrams.  The results are the same regardless of the option chosen.
<br>
[[Image:10.37.png|thumb|center|600px|Fault tree for the component without using subdiagrams(Transfer gates)]] 

[[Image:10.40.gif|thumb|center|400px|A hybrid solution using an RBD for the component and fault trees as subdiagrams.]]
<br>

=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 figure below.
<br>
[[Image:10.41.gif|thumb|center|500px|A complex RBD that cannot be represented by a fault tree unless duplicate events are utilized.]]
<br>

A fault tree representation for this RBD is shown in the first figure below.  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 second figure below is also equivalent to the RBD of figure above and the fault tree of the first figure below.
<br>
[[Image:10.42.gif|thumb|center|500px|A fault tree representation using mirrored blocks (events) of the complex RBD.]]
<br>

[[Image:10.43.gif|thumb|center|500px|An RBD using mirrored blocks that is equivalent to both the RBD and FTD.]]
<br>

=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.
<br>
===Example===
<br>
Consider the RBD shown in the first figure below and its equivalent fault tree representation, as shown in the second figure below.  
<br>
[[Image:10.44.gif|thumb|center|400px|RBD for a repairable system.]]
<br>
[[Image:10.45.gif|thumb|center|400px|Fault tree equivalent of the repairable system shown in figure above.]]
<br>

<br>
Furthermore, assume the following basic failure and repair properties for each block and event:
<br>
:•	Block  <math>A</math> :
::o	Failure Distribution: Weibull;  <math>\beta </math> =1.5;  <math>\eta </math> =1,000.
::o	Corrective Distribution: Weibull;  <math>\beta </math> =1.5;  <math>\eta </math> =100.
:•	Block  <math>B</math> :
::o	Failure Distribution: Exponential;  <math>\mu </math> =10,000.
::o	Corrective Distribution: Weibull;  <math>\beta </math> =1.5;  <math>\eta </math> =20.
:•	Block  <math>C</math> :
::o	Failure Distribution: Normal;  <math>\mu </math> =1,000;  <math>\sigma </math> =200.
::o	Corrective Distribution: Normal;  <math>\mu </math> =6;  <math>\sigma </math> =2.
:•	Block  <math>D</math> :
::o	Failure Distribution: Weibull;  <math>\beta </math> =1.5;  <math>\eta </math> =10,000.
::o	Corrective Distribution: Exponential;  <math>\mu </math> =10.
:•	Block  <math>E</math> :
::o	Failure Distribution: Weibull;  <math>\beta </math> =3;  <math>\eta </math> =1,000.
::o	Corrective Distribution: Weibull;  <math>\beta </math> =1.5;  <math>\eta </math> =20.
:•	Block  <math>F</math> :
::o	Failure Distribution: Weibull;  <math>\beta </math> =1.5;  <math>\eta </math> =5,000.
::o	Corrective Distribution: Weibull;  <math>\beta </math> =1.5;  <math>\eta </math> =100.
:•	Block  <math>G</math> :
::o	Failure Distribution: Exponential;  <math>\mu </math> =100,000.
::o	Corrective Distribution: Weibull;  <math>\beta </math> =1.5;  <math>\eta </math> =10.
:•	Block  <math>H</math> :
::o	Failure Distribution: Normal;  <math>\mu </math> =5,000;  <math>\sigma </math> =50.
::o	Corrective Distribution: Normal;  <math>\mu </math> =10;  <math>\sigma </math> =2.
<br>
A sample table of simulation results is given next for up to  <math>t=1,000</math> , using  <math>2,000</math>  simulations for each diagram and an identical seed.
<br>

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  <math>G</math>  in the RBD may receive a different sequence of random numbers than event block  <math>G</math>  in the FT).
<br>

=Additional Fault Tree Topics=

===Minimal Cut Sets===
<br>
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 [[Appendix_B:_References | Kececioglu [10]]].  As an example, consider the fault tree shown in Figure "Minimal cut set example".  The system will fail if {1, 2, 3 and 4 fail} or {1, 2 and 3 fail} or {1, 2 and 4 fail}.
<br>

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 first figure below, as shown in the second figure below.
<br>

[[Image:9.png|thumb|center|400px|Minimal cut set example.]]
<br>

[[Image:10.png|thumb|center|400px|RBD of the fault tree shown in figure above.]]
<br>

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 Tools menu.