Fault tree analysis - Revision history

Jan: Add 5 watermarked SVG illustrations from the Expert visual plan

2026-11-02T16:43:57Z

Add 5 watermarked SVG illustrations from the Expert visual plan

← Older revision		Revision as of 17:43, 2 November 2026
Line 7:		Line 7:

	A standard set of symbols distinguishes the kinds of event in a tree.<ref name="MJ-36">Modarres and Joglar-Billoch (2002), p. 5-36.</ref> Primary events include basic events, conditioning events, undeveloped events and external events. An intermediate event is the output of a gate that is developed further down the tree. The two main gates are the AND gate and the OR gate, and transfer symbols connect parts of a tree that are drawn separately.<ref name="MJ-36" />		A standard set of symbols distinguishes the kinds of event in a tree.<ref name="MJ-36">Modarres and Joglar-Billoch (2002), p. 5-36.</ref> Primary events include basic events, conditioning events, undeveloped events and external events. An intermediate event is the output of a gate that is developed further down the tree. The two main gates are the AND gate and the OR gate, and transfer symbols connect parts of a tree that are drawn separately.<ref name="MJ-36" />
			[[File:fse-fault-tree-analysis-v1.svg\|thumb\|upright=1.5\|alt=Small fault tree: pump 1 fails through an OR gate over three causes; no power requires off-site power and generator both unavailable (AND gate).\|One branch of a fault tree for a water-based fire protection system: the pump fails if any of three causes occurs (OR gate), and loss of power needs both supplies to fail (AND gate). Based on Modarres and Joglar-Billoch (2002), pp. 5-36 and 5-38.]]

	The events in a tree are not limited to hardware. The causes found by the analysis may include component, equipment and system failures, operating actions and human errors.<ref name="ME-156" /> This breadth is one reason why fault trees suit complex systems. Simple reliability block diagrams become difficult to use when components have several failure modes, interact physically and operationally, or depend on human actions.<ref name="MJ-35" />		The events in a tree are not limited to hardware. The causes found by the analysis may include component, equipment and system failures, operating actions and human errors.<ref name="ME-156" /> This breadth is one reason why fault trees suit complex systems. Simple reliability block diagrams become difficult to use when components have several failure modes, interact physically and operationally, or depend on human actions.<ref name="MJ-35" />
Line 67:		Line 68:

	At first sight the top AND gate suggests that two independent failures are always required for the top event. Boolean reduction of the tree gives 23 minimal cut sets, a number derived from the tree rather than printed in the handbook.<ref name="MJ-38" /> Two of them contain only one event: the unavailable water tank and the failed actuating device. A third combines the loss of off-site power with the unavailable generator, and the other 20 each pair one failure on path 1 with one on path 2. Modarres and Joglar-Billoch note that the actuating device, the electric power and the water tank are shared by both paths, and they treat these as physical dependencies in the quantification.<ref name="MJ-37" />		At first sight the top AND gate suggests that two independent failures are always required for the top event. Boolean reduction of the tree gives 23 minimal cut sets, a number derived from the tree rather than printed in the handbook.<ref name="MJ-38" /> Two of them contain only one event: the unavailable water tank and the failed actuating device. A third combines the loss of off-site power with the unavailable generator, and the other 20 each pair one failure on path 1 with one on path 2. Modarres and Joglar-Billoch note that the actuating device, the electric power and the water tank are shared by both paths, and they treat these as physical dependencies in the quantification.<ref name="MJ-37" />
			[[File:fse-fault-tree-analysis-v2.svg\|thumb\|upright=1.5\|alt=Fault tree with an AND gate over two path failures; tank, actuating device and power feed both paths, so each of them alone can fail the system.\|Simplified fault tree for a two-path fire protection system. Events shared by both paths (orange, dashed outline) defeat the redundancy of the top AND gate. Based on Modarres and Joglar-Billoch (2002), pp. 5-37 to 5-38.]]

	== Worked example ==		== Worked example ==
Line 80:		Line 82:

	The two results differ by a factor of more than 100,000, although the components are identical. The AND result holds only if the three heads fail independently. A closed control valve upstream of all three heads would disable them at once. Barry reports a plant where the control valves of a sprinkler system were shut for four months each year for fear of freezing.<ref name="BA-203">Barry (2002), p. 5-203.</ref> A shared cause of this kind is a [[common cause failure]], and it must appear in the tree as an event of its own.<ref name="BA-204" />		The two results differ by a factor of more than 100,000, although the components are identical. The AND result holds only if the three heads fail independently. A closed control valve upstream of all three heads would disable them at once. Barry reports a plant where the control valves of a sprinkler system were shut for four months each year for fear of freezing.<ref name="BA-203">Barry (2002), p. 5-203.</ref> A shared cause of this kind is a [[common cause failure]], and it must appear in the tree as an event of its own.<ref name="BA-204" />
			[[File:fse-fault-tree-analysis-v3.svg\|thumb\|upright=1.5\|alt=Log-scale bar chart: three components near 0.003 to 0.01, OR gate 0.0169, AND gate 1.25 times ten to the minus seven.\|Failure probabilities within 1,000 h of three components, and of the top event when they are joined by an OR gate or an AND gate. Based on Modarres and Joglar-Billoch (2002), pp. 5-32 to 5-33.]]

	== Use in fire safety engineering ==		== Use in fire safety engineering ==
Line 87:		Line 90:

	In a probabilistic analysis of fire scenarios, the International Fire Engineering Guidelines recommend event trees for identifying the scenarios. Where the probability of a branch is not available, fault trees may be used to calculate it from a logic model of the failure mechanisms of the system.<ref name="IFEG-2.2-4" /> Barry describes the same division of tasks for fire and explosion risk assessment in the process industries. An event tree follows a fire forward in time, but it may lack detail on why a protection system fails.<ref name="BA-180">Barry (2002), p. 5-180.</ref> In most fire and explosion risk assessments, the branch points must therefore be supported by fault trees for equipment failures, operational failures and external events such as windstorm, flood or earthquake.<ref name="BA-188" /><ref name="BA-190">Barry (2002), p. 5-190.</ref>		In a probabilistic analysis of fire scenarios, the International Fire Engineering Guidelines recommend event trees for identifying the scenarios. Where the probability of a branch is not available, fault trees may be used to calculate it from a logic model of the failure mechanisms of the system.<ref name="IFEG-2.2-4" /> Barry describes the same division of tasks for fire and explosion risk assessment in the process industries. An event tree follows a fire forward in time, but it may lack detail on why a protection system fails.<ref name="BA-180">Barry (2002), p. 5-180.</ref> In most fire and explosion risk assessments, the branch points must therefore be supported by fault trees for equipment failures, operational failures and external events such as windstorm, flood or earthquake.<ref name="BA-188" /><ref name="BA-190">Barry (2002), p. 5-190.</ref>
			[[File:fse-fault-tree-analysis-v4.svg\|thumb\|upright=1.5\|alt=Event tree from fire start with a sprinkler branch; a fault tree below, with an OR gate over three failure groups, gives the probability of the No branch.\|An event tree follows the fire forward in time; a fault tree gives the probability that the sprinkler branch fails. Based on National Research Council of Canada et al. (2005), p. 2.2-4 and Barry (2002), p. 5-190.]]

	Barry also uses short fault trees to separate two ways in which a fire protection system can fail. The system may be off-line when the fire occurs, or it may be on-line but fail to operate on demand.<ref name="BA-200">Barry (2002), p. 5-200.</ref> Downtime is the OR combination of inspection, maintenance and testing, false trips and unscheduled repairs, and other conditions. Online availability is one minus the probability of downtime.<ref name="BA-202" /> Failure on demand is built in the same way from subsystem failures and common causes.<ref name="BA-204">Barry (2002), p. 5-204.</ref> Barry suggests target availabilities between 0.98 and 0.999.<ref name="BA-203" />		Barry also uses short fault trees to separate two ways in which a fire protection system can fail. The system may be off-line when the fire occurs, or it may be on-line but fail to operate on demand.<ref name="BA-200">Barry (2002), p. 5-200.</ref> Downtime is the OR combination of inspection, maintenance and testing, false trips and unscheduled repairs, and other conditions. Online availability is one minus the probability of downtime.<ref name="BA-202" /> Failure on demand is built in the same way from subsystem failures and common causes.<ref name="BA-204">Barry (2002), p. 5-204.</ref> Barry suggests target availabilities between 0.98 and 0.999.<ref name="BA-203" />
Line 109:		Line 113:

	For complex systems in apartment buildings, this extreme combination gave reliabilities from 67.9% to 99.2%. A multi-scenario analysis with triangular input distributions gave a 5th to 95th percentile range of 79.4% to 91.9%, with a mean of 85.6%.<ref name="DS-115">Australian Building Codes Board (2020a), Data Sheet C3, p. 115.</ref> The data sheets attribute most of the difference between simple and complex systems to the probability of programming errors. This finding shows how strongly human errors can weigh in a quantified tree.<ref name="DS-115" />		For complex systems in apartment buildings, this extreme combination gave reliabilities from 67.9% to 99.2%. A multi-scenario analysis with triangular input distributions gave a 5th to 95th percentile range of 79.4% to 91.9%, with a mean of 85.6%.<ref name="DS-115">Australian Building Codes Board (2020a), Data Sheet C3, p. 115.</ref> The data sheets attribute most of the difference between simple and complex systems to the probability of programming errors. This finding shows how strongly human errors can weigh in a quantified tree.<ref name="DS-115" />
			[[File:fse-fault-tree-analysis-v5.svg\|thumb\|upright=1.5\|alt=Range chart of smoke detection reliability: extreme-input ranges are much wider than multi-scenario 5th to 95th percentile ranges.\|Reliability of addressable smoke detection systems in apartments from the same fault tree inputs: all-low/all-high combination versus multi-scenario analysis. Based on Australian Building Codes Board (2020a), Data Sheet C3, p. 115.]]

	A tree covers only the failure modes that the analyst identifies, and its result depends on the definition of each failure. Barry counts a control valve that fails partly or fully at the moment of demand, because of hidden mechanical degradation, as a failure on demand.<ref name="BA-203" /> A fault tree is also static. It describes logical combinations of events, not their order or timing, so the development of a fire over time is handled by event trees instead.<ref name="WH-5" /><ref name="BA-180" />		A tree covers only the failure modes that the analyst identifies, and its result depends on the definition of each failure. Barry counts a control valve that fails partly or fully at the moment of demand, because of hidden mechanical degradation, as a failure on demand.<ref name="BA-203" /> A fault tree is also static. It describes logical combinations of events, not their order or timing, so the development of a fire over time is handled by event trees instead.<ref name="WH-5" /><ref name="BA-180" />

Mark: FSE wiki: correct a rounded probability and mark the cut-set count as derived, after fact-check (written by Claude Opus 5.5)

2026-11-01T22:37:44Z

FSE wiki: correct a rounded probability and mark the cut-set count as derived, after fact-check (written by Claude Opus 5.5)

← Older revision		Revision as of 23:37, 1 November 2026
Line 66:		Line 66:
	A pump in this tree fails if it is unavailable, if the detector, alarm and actuator device fails, or if it has no power. Pump 2 also fails if the operator does not start it. Loss of power requires both the off-site supply and the diesel generator to be unavailable, which is itself an AND gate.<ref name="MJ-38" />		A pump in this tree fails if it is unavailable, if the detector, alarm and actuator device fails, or if it has no power. Pump 2 also fails if the operator does not start it. Loss of power requires both the off-site supply and the diesel generator to be unavailable, which is itself an AND gate.<ref name="MJ-38" />

	At first sight the top AND gate suggests that two independent failures are always required for the top event. Boolean reduction of the tree gives 23 minimal cut sets, ~~and two~~ of them contain only one event: the unavailable water tank and the failed actuating device. A third combines the loss of off-site power with the unavailable generator, and the other 20 each pair one failure on path 1 with one on path 2. Modarres and Joglar-Billoch note that the actuating device, the electric power and the water tank are shared by both paths, and they treat these as physical dependencies in the quantification.<ref name="MJ-37" />		At first sight the top AND gate suggests that two independent failures are always required for the top event. Boolean reduction of the tree gives 23 minimal cut sets, a number derived from the tree rather than printed in the handbook.<ref name="MJ-38" /> Two of them contain only one event: the unavailable water tank and the failed actuating device. A third combines the loss of off-site power with the unavailable generator, and the other 20 each pair one failure on path 1 with one on path 2. Modarres and Joglar-Billoch note that the actuating device, the electric power and the water tank are shared by both paths, and they treat these as physical dependencies in the quantification.<ref name="MJ-37" />

	== Worked example ==		== Worked example ==
	Two examples in the SFPE Handbook use the same three failure rates and show how strongly the choice of gate affects the result. The components have constant failure rates of 4.0 × 10<sup>−6</sup>, 3.2 × 10<sup>−6</sup> and 9.8 × 10<sup>−6</sup> per hour, and the mission time is 1,000 hours.<ref name="MJ-32" /> With the exponential model, the probabilities that each component fails within this time are 0.00399, 0.~~00320~~ and 0.00975. If the top event occurs when any one of the three components fails, the inputs are joined by an OR gate:		Two examples in the SFPE Handbook use the same three failure rates and show how strongly the choice of gate affects the result. The components have constant failure rates of 4.0 × 10<sup>−6</sup>, 3.2 × 10<sup>−6</sup> and 9.8 × 10<sup>−6</sup> per hour, and the mission time is 1,000 hours.<ref name="MJ-32" /> With the exponential model, the probabilities that each component fails within this time are 0.00399, 0.00319 and 0.00975. If the top event occurs when any one of the three components fails, the inputs are joined by an OR gate:

	<math display="block">P_\mathrm{OR} = 1 - (1 - 0.00399)(1 - 0.~~00320~~)(1 - 0.00975) = 0.0169</math>		<math display="block">P_\mathrm{OR} = 1 - (1 - 0.00399)(1 - 0.00319)(1 - 0.00975) = 0.0169</math>

	The sum of the three probabilities gives 0.0169 as well, only about 0.5% above the exact value. Rounded to the safe side, the failure probability is 0.017, which is the unreliability that the handbook gives for these components arranged in series.<ref name="MJ-32" /> If the top event instead requires all three components to fail, the inputs are joined by an AND gate:		The sum of the three probabilities gives 0.0169 as well, only about 0.5% above the exact value. Rounded to the safe side, the failure probability is 0.017, which is the unreliability that the handbook gives for these components arranged in series.<ref name="MJ-32" /> If the top event instead requires all three components to fail, the inputs are joined by an AND gate:

	<math display="block">P_\mathrm{AND} = 0.00399 \times 0.~~00320~~ \times 0.00975 \approx 1.25 \times 10^{-7}</math>		<math display="block">P_\mathrm{AND} = 0.00399 \times 0.00319 \times 0.00975 \approx 1.25 \times 10^{-7}</math>

	The exact product is 1.24 × 10<sup>−7</sup>, and rounding to the safe side gives 1.25 × 10<sup>−7</sup>. This matches the handbook's result for three sprinkler heads that are the only automatic suppression in a corridor.<ref name="MJ-33">Modarres and Joglar-Billoch (2002), p. 5-33.</ref> The heads are piped in series, yet the corridor loses its automatic suppression only if all three heads fail. The logic of a tree therefore follows the definition of failure, not the physical layout of the pipework.		The exact product is 1.24 × 10<sup>−7</sup>, and rounding to the safe side gives 1.25 × 10<sup>−7</sup>. This matches the handbook's result for three sprinkler heads that are the only automatic suppression in a corridor.<ref name="MJ-33">Modarres and Joglar-Billoch (2002), p. 5-33.</ref> The heads are piped in series, yet the corridor loses its automatic suppression only if all three heads fail. The logic of a tree therefore follows the definition of failure, not the physical layout of the pipework.

Mark: FSE wiki: align reference entries and locators with the run's canonical reference list (written by Claude Opus 5.5)

2026-11-01T22:09:48Z

FSE wiki: align reference entries and locators with the run's canonical reference list (written by Claude Opus 5.5)

Show changes

Mark: New FSE wiki article: Fault tree analysis (written by Claude Opus 5.5)

2026-11-01T22:01:09Z

New FSE wiki article: Fault tree analysis (written by Claude Opus 5.5)

New page

'''Fault tree analysis''' ('''FTA''') is a deductive method that starts from one undesired event, the top event, and traces the combinations of failures, errors and conditions that can cause it.<ref name="ME-156">Meacham (2002), p. 5-156.</ref> The fault tree itself is a graphic model in which logic gates join these causes, so the tree is organised by logical dependency rather than by time.<ref name="WH-5">Watts and Hall (2002), p. 5-5.</ref> In fire safety engineering, an example of a top event is the failure of a fire protection system, such as a water-based extinguishing system that cannot deliver water to a fire.<ref name="MJ-38">Modarres and Joglar-Billoch (2002), p. 5-38.</ref> When probabilities are assigned to the basic causes, the tree yields the probability of the top event, and the method changes from a qualitative hazard tool into a quantitative one.<ref name="ME-156" />

Engineers use fault trees to estimate the [[reliability of fire protection systems]] and to supply branch probabilities for an [[event tree analysis]] within a [[quantitative risk assessment]].<ref name="IFEG-2.2-4">Australian Building Codes Board (2005), p. 2.2-4.</ref><ref name="DS-62">Australian Building Codes Board (2020), p. 62.</ref> The simple gate formulas assume that the basic events are independent of each other.<ref name="MJ-32" /> Components that are shared by several parts of a system break this assumption and need explicit treatment.<ref name="MJ-37">Modarres and Joglar-Billoch (2002), p. 5-37.</ref>

== Principle and terminology ==
Meacham describes fault tree analysis as a "reverse thinking" deductive technique. It begins with one event that could occur, or has occurred, and provides a structure for working out what could have caused it.<ref name="ME-156" /> The analyst places the top event at the head of the tree and breaks it down into subevents. These are broken down in turn until the tree reaches the level of elementary components.<ref name="MJ-35">Modarres and Joglar-Billoch (2002), p. 5-35.</ref> The events at the lowest level, such as an operator who fails to start a pump or an isolation valve that is closed, are the basic events of the tree.<ref name="MJ-38" />

A standard set of symbols distinguishes the kinds of event in a tree.<ref name="MJ-36">Modarres and Joglar-Billoch (2002), p. 5-36.</ref> Primary events include basic events, conditioning events, undeveloped events and external events. An intermediate event is the output of a gate that is developed further down the tree. The two main gates are the AND gate and the OR gate, and transfer symbols connect parts of a tree that are drawn separately.<ref name="MJ-36" />

The events in a tree are not limited to hardware. The causes found by the analysis may include component, equipment and system failures, operating actions and human errors.<ref name="ME-156" /> This breadth is one reason why fault trees suit complex systems. Simple reliability block diagrams become difficult to use when components have several failure modes, interact physically and operationally, or depend on human actions.<ref name="MJ-35" />

The same logic can be built in success space instead of failure space, and the result is then called a success tree. Modarres and Joglar-Billoch note that experience favours a success orientation for defining system functions.<ref name="MJ-35" /> They add that fault descriptions are easier to grasp when the aim is to understand how a piece of equipment or a process fails. In that case the analyst looks at the system from the point of view of a failure that has already happened.<ref name="MJ-36" />

== Logic gates and probability ==
An OR gate states that its output event occurs if at least one of its input events occurs. An AND gate states that its output event occurs only if all of its input events occur. In reliability terms, an OR gate over component failures describes a series system, which fails when any one of its items fails.<ref name="MJ-31">Modarres and Joglar-Billoch (2002), p. 5-31.</ref> An AND gate describes a parallel or redundant system, which fails only when all of its units fail.<ref name="MJ-32">Modarres and Joglar-Billoch (2002), p. 5-32.</ref>

The probability of a gate output follows from two basic rules of probability.<ref name="HA-184">Hall (2002), p. 1-184.</ref> The probability that at least one of two events occurs equals the sum of their probabilities minus the probability that both occur. Two events are independent when the probability that both occur equals the product of their separate probabilities. For independent inputs, an AND gate therefore multiplies the input probabilities:

<math display="block">P_\mathrm{AND} = \prod_{i=1}^{n} p_i</math>

The output of an OR gate is avoided only when none of its inputs occurs. For two inputs, the result is the same as adding the two probabilities and subtracting the probability that both occur.<ref name="HA-184" /> For any number of independent inputs, the probability of the output is therefore one minus the product of the probabilities that each input does not occur:<ref name="MJ-32" />

<math display="block">P_\mathrm{OR} = 1 - \prod_{i=1}^{n} \left( 1 - p_i \right)</math>

Many basic events describe a component that may fail during a stated mission time. For a component with a constant failure rate, the probability of surviving the mission time is an exponential function of that time.<ref name="MJ-32" /> The probability of a failure within the mission time is one minus the probability of survival:

<math display="block">p_i = 1 - \exp\left( -\lambda_i t \right)</math>

Other basic events are estimated directly from operating records. Barry gives the example of a fire protection system that is taken off-line for 80 hours per year for inspection, maintenance and testing. Dividing 80 hours by the 8,760 hours in a year gives an annual probability of unavailability of about 0.009.<ref name="BA-201">Barry (2002), p. 5-201.</ref>

When all input probabilities are small, the OR gate is often simplified to the sum of its inputs. Barry's fault trees for fire protection systems use this sum. The probability that a system is off-line, for example, is the sum of the probabilities of three causes of downtime.<ref name="BA-202">Barry (2002), p. 5-202.</ref> The sum is never smaller than the exact result, so it errs on the side of a higher failure probability.<ref name="MJ-35" /> All of these formulas are valid only for independent events, and the exponential model also assumes a constant failure rate.<ref name="MJ-32" /> The summation shortcut is accurate only when every input probability is small.<ref name="MJ-35" />

{| class="wikitable"
! Symbol !! Description !! Unit
|-
| <math>P_\mathrm{AND}</math> || probability of the output event of an AND gate || dimensionless
|-
| <math>P_\mathrm{OR}</math> || probability of the output event of an OR gate || dimensionless
|-
| <math>P_\mathrm{top}</math> || probability of the top event || dimensionless
|-
| <math>p_i</math> || probability of input event or basic event <math>i</math> || dimensionless
|-
| <math>n</math> || number of input events of a gate || dimensionless
|-
| <math>\lambda_i</math> || constant failure rate of component <math>i</math> || h−1
|-
| <math>t</math> || mission time || h
|-
| <math>C_j</math> || minimal cut set <math>j</math> (the event that all its basic events occur) || dimensionless
|-
| <math>m</math> || number of minimal cut sets || dimensionless
|}

== Minimal cut sets ==
A cut set is a combination of basic events that, if all of them occur, causes the top event. A minimal cut set is the smallest such combination, so the top event no longer follows once any one of its events is taken away.<ref name="MJ-35" /> In practice, the minimal cut sets list the combinations of component failures that make a system fail. A fault tree is reduced to its minimal cut sets with Boolean algebra, and Barry points to the standard references on fault tree structuring, Boolean algebra, cut sets and sensitivity analysis.<ref name="BA-188">Barry (2002), p. 5-188.</ref>

The top event occurs when at least one minimal cut set occurs, so its probability is the probability of the union of all cut sets. Cut sets usually share basic events, which makes an exact calculation laborious. A simpler and safer estimate adds the probabilities of the individual cut sets:<ref name="MJ-35" />

<math display="block">P_\mathrm{top} = \Pr\left( C_1 \cup C_2 \cup \dots \cup C_m \right) \le \sum_{j=1}^{m} \Pr\left( C_j \right)</math>

Modarres and Joglar-Billoch describe this bound as appropriate in practice, because most engineering components have reliabilities above 0.9 over their mission time.<ref name="MJ-35" /> The failure probabilities of the cut sets are then small, and the sum stays close to the exact value of the union. Where it differs, the sum gives the higher failure probability and so errs on the safe side.

The fault tree for a water-based fire protection system in the SFPE Handbook shows why the reduction matters.<ref name="MJ-38" /> The system has two injection paths, each with its own nozzle, pump and isolation valves, and each able to control the fire on its own. Pump 1 starts automatically on a signal from a detector, alarm and actuator device, while operators start pump 2 by hand.<ref name="MJ-36" /> The top event, failure of the on-site system, is an AND gate over the failure of both paths. Each path fails through an OR gate if its nozzle is unavailable, an isolation valve is closed, its pump fails or the water tank is unavailable.<ref name="MJ-38" />

A pump in this tree fails if it is unavailable, if the detector, alarm and actuator device fails, or if it has no power. Pump 2 also fails if the operator does not start it. Loss of power requires both the off-site supply and the diesel generator to be unavailable, which is itself an AND gate.<ref name="MJ-38" />

At first sight the top AND gate suggests that two independent failures are always required for the top event. Boolean reduction of the tree gives 23 minimal cut sets, and two of them contain only one event: the unavailable water tank and the failed actuating device. A third combines the loss of off-site power with the unavailable generator, and the other 20 each pair one failure on path 1 with one on path 2. Modarres and Joglar-Billoch note that the actuating device, the electric power and the water tank are shared by both paths, and they treat these as physical dependencies in the quantification.<ref name="MJ-37" />

== Worked example ==
Two examples in the SFPE Handbook use the same three failure rates and show how strongly the choice of gate affects the result. The components have constant failure rates of 4.0 × 10−6, 3.2 × 10−6 and 9.8 × 10−6 per hour, and the mission time is 1,000 hours.<ref name="MJ-32" /> With the exponential model, the probabilities that each component fails within this time are 0.00399, 0.00320 and 0.00975. If the top event occurs when any one of the three components fails, the inputs are joined by an OR gate:

<math display="block">P_\mathrm{OR} = 1 - (1 - 0.00399)(1 - 0.00320)(1 - 0.00975) = 0.0169</math>

The sum of the three probabilities gives 0.0169 as well, only about 0.5% above the exact value. Rounded to the safe side, the failure probability is 0.017, which is the unreliability that the handbook gives for these components arranged in series.<ref name="MJ-32" /> If the top event instead requires all three components to fail, the inputs are joined by an AND gate:

<math display="block">P_\mathrm{AND} = 0.00399 \times 0.00320 \times 0.00975 \approx 1.25 \times 10^{-7}</math>

The exact product is 1.24 × 10−7, and rounding to the safe side gives 1.25 × 10−7. This matches the handbook's result for three sprinkler heads that are the only automatic suppression in a corridor.<ref name="MJ-33">Modarres and Joglar-Billoch (2002), p. 5-33.</ref> The heads are piped in series, yet the corridor loses its automatic suppression only if all three heads fail. The logic of a tree therefore follows the definition of failure, not the physical layout of the pipework.

The two results differ by a factor of more than 100,000, although the components are identical. The AND result holds only if the three heads fail independently. A closed control valve upstream of all three heads would disable them at once. Barry reports a plant where the control valves of a sprinkler system were shut for four months each year for fear of freezing.<ref name="BA-203">Barry (2002), p. 5-203.</ref> A shared cause of this kind is a [[common cause failure]], and it must appear in the tree as an event of its own.<ref name="BA-204" />

== Use in fire safety engineering ==
Fault trees are one of the usual ways to estimate the reliability of a fire protection system, alongside historical data, technical literature and expert judgement.<ref name="DS-62" /> The data sheets of the Australian Building Codes Board summarise a study of wet-pipe sprinkler systems in Australian high-rise office buildings. Moinuddin and Thomas built fault trees from a survey of 26 buildings, supplemented by overseas data, and calculated reliabilities between 86.6% and 97.9%.<ref name="MT-81">Moinuddin and Thomas (2014), as cited in Australian Building Codes Board (2020), p. 81.</ref> Zone shut-off during tenancy changes and out-of-specification sprinkler heads were the main causes of failure. The trees also showed that a zone isolation valve on each floor reduces the failure probability to between 10% and 63% of its original value.<ref name="MT-81" />

Because a tree shows how each component contributes to the top event, it can also show how the reliability of a system could be improved. This use requires failure data for the individual components.<ref name="DS-133">Australian Building Codes Board (2020), p. 133.</ref> A detailed tree can be built for a single project to reflect its specific design features. The data sheets warn that such trees must be fully developed, so that no failure modes are left unidentified. They must also cover human factors in design, commissioning and maintenance.<ref name="DS-135">Australian Building Codes Board (2020), p. 135.</ref>

In a probabilistic analysis of fire scenarios, the International Fire Engineering Guidelines recommend event trees for identifying the scenarios. Where the probability of a branch is not available, fault trees may be used to calculate it from a logic model of the failure mechanisms of the system.<ref name="IFEG-2.2-4" /> Barry describes the same division of tasks for fire and explosion risk assessment in the process industries. An event tree follows a fire forward in time, but it may lack detail on why a protection system fails.<ref name="BA-180">Barry (2002), p. 5-180.</ref> In most fire and explosion risk assessments, the branch points must therefore be supported by fault trees for equipment failures, operational failures and external events such as windstorm, flood or earthquake.<ref name="BA-188" /><ref name="BA-190">Barry (2002), p. 5-190.</ref>

Barry also uses short fault trees to separate two ways in which a fire protection system can fail. The system may be off-line when the fire occurs, or it may be on-line but fail to operate on demand.<ref name="BA-200">Barry (2002), p. 5-200.</ref> Downtime is the OR combination of inspection, maintenance and testing, false trips and unscheduled repairs, and other conditions. Online availability is one minus the probability of downtime.<ref name="BA-202" /> Failure on demand is built in the same way from subsystem failures and common causes.<ref name="BA-204">Barry (2002), p. 5-204.</ref> Barry suggests target availabilities between 0.98 and 0.999.<ref name="BA-203" />

Fire probabilistic risk assessment (PRA) of nuclear power plants applies the method on a large scale. The methodology of the Electric Power Research Institute and the U.S. Nuclear Regulatory Commission builds on the plant's existing model of event trees and fault trees.<ref name="EN-5-1">Electric Power Research Institute and U.S. Nuclear Regulatory Commission (2005), p. 5-1.</ref><ref name="EN-19-6">Electric Power Research Institute and U.S. Nuclear Regulatory Commission (2005), p. 19-6.</ref> It notes two established modelling approaches, known as fault tree linking and event trees with boundaries.<ref name="EN-5-1" />

In this methodology, equipment damaged by a fire is represented by setting the corresponding basic events to failed, with a probability of 1.0. The PRA software then carries these failures through the system and sequence logic.<ref name="EN-5-2">Electric Power Research Institute and U.S. Nuclear Regulatory Commission (2005), p. 5-2.</ref> Operator errors enter the model as human failure events, which are basic events caused by human inaction or inappropriate action.<ref name="EN-19-6" /> The minimal cut sets are then ranked by their contribution to the core damage frequency, which reveals the fire scenarios, compartments and operator actions that dominate the risk.<ref name="EN-14-4">Electric Power Research Institute and U.S. Nuclear Regulatory Commission (2005), p. 14-4.</ref>

In building fire safety, fault tree logic also underlies the [[fire safety concepts tree]] of the National Fire Protection Association. Watts and Hall describe its guide, NFPA 550, ''Guide to the Fire Safety Concepts Tree'', as one of the most widely cited and used fault tree formats in fire risk analysis.<ref name="WH-7">Watts and Hall (2002), p. 5-7.</ref> The 1995 edition of the guide was developed by the former Systems Concepts Committee, and its maintenance passed to the association's new Technical Committee on Fire Risk Analysis.<ref name="WH-7" />

== Relation to event trees and other methods ==
An event tree is organised by temporal sequence and identifies the outcomes that can follow an initiating event. A fault tree is organised by logical dependency and explains how one particular outcome can arise.<ref name="WH-5" /> Meacham summarises the difference in the starting point of each method. Fault tree analysis starts from a failure and looks for its causes, while event tree analysis starts from an initiating event and looks for its outcomes.<ref name="ME-156" /> In a fault tree, consequences are usually defined in an either/or form, so the probabilities of failure and success are enough to express the risk.<ref name="WH-5" />

Simpler screening methods often come first. Failure modes and effects analysis (FMEA) tabulates components, their failure modes and the effects of each failure. It usually focuses on single failures and leaves out human failures.<ref name="ME-156" /> When such a screening shows that a failure mode needs a closer look, fault tree analysis or event tree analysis is often the next step.<ref name="ME-156" />

Reliability block diagrams describe the same logic as series and parallel arrangements of components. They work well when a system has few units, but fault trees are more practical for systems with many units.<ref name="MJ-35" /> A master logic diagram extends success tree logic by adding the support systems that cool, actuate, power, lubricate or control the main systems.<ref name="MJ-36" /> Challenges to a system often originate in such support equipment, which is why these relationships belong in the logic model.<ref name="MJ-36" />

== Limitations and uncertainty ==
The product rule of the AND gate is valid only for independent events. Hall points out that two events can be dependent without either causing the other, for example because both depend on a third variable.<ref name="HA-184" /> In a fire protection system, a shared water supply, power supply or control device creates such a dependence. The minimal cut sets then contain single events that bypass the intended redundancy.<ref name="MJ-37" />

A fault tree can be no better than its basic event data. Barry warns that plant-specific failure data are often limited, so a reliability estimate may be accurate only in an order-of-magnitude sense.<ref name="BA-204" /> The way uncertain inputs are combined also matters. The data sheets of the Australian Building Codes Board discuss fault trees for addressable smoke detection systems, built with low, most likely and high values for each input.<ref name="DS-114">Australian Building Codes Board (2020), p. 114.</ref> Combining all low inputs for the low estimate and all high inputs for the high estimate probably overstates the range of the result.<ref name="DS-114" />

For complex systems in apartment buildings, this extreme combination gave reliabilities from 67.9% to 99.2%. A multi-scenario analysis with triangular input distributions gave a 5th to 95th percentile range of 79.4% to 91.9%, with a mean of 85.6%.<ref name="DS-115">Australian Building Codes Board (2020), p. 115.</ref> The data sheets attribute most of the difference between simple and complex systems to the probability of programming errors. This finding shows how strongly human errors can weigh in a quantified tree.<ref name="DS-115" />

A tree covers only the failure modes that the analyst identifies, and its result depends on the definition of each failure. Barry counts a control valve that fails partly or fully at the moment of demand, because of hidden mechanical degradation, as a failure on demand.<ref name="BA-203" /> A fault tree is also static. It describes logical combinations of events, not their order or timing, so the development of a fire over time is handled by event trees instead.<ref name="WH-5" /><ref name="BA-180" />

== See also ==
* [[Uncertainty analysis]]
* [[Monte Carlo simulation]]
* [[Fire risk assessment]]
* [[Fire statistics]]

== Notes ==
<references />

== References ==
* Australian Building Codes Board. (2005). ''International fire engineering guidelines'' (2005 ed.).
* Australian Building Codes Board. (2020). ''Data sheets: Fire safety verification method'' [Handbook annex].
* Barry, T. F. (2002). Quantitative risk assessment in chemical process industries. In P. J. DiNenno, D. Drysdale, C. L. Beyler, W. D. Walton, R. L. P. Custer, J. R. Hall, Jr., & J. M. Watts, Jr. (Eds.), ''SFPE handbook of fire protection engineering'' (3rd ed., pp. 5-176–5-213). National Fire Protection Association.
* Electric Power Research Institute & U.S. Nuclear Regulatory Commission. (2005). ''EPRI/NRC-RES fire PRA methodology for nuclear power facilities: Volume 2. Detailed methodology'' (NUREG/CR-6850, EPRI 1011989).
* Hall, J. R., Jr. (2002). Probability concepts. In P. J. DiNenno, D. Drysdale, C. L. Beyler, W. D. Walton, R. L. P. Custer, J. R. Hall, Jr., & J. M. Watts, Jr. (Eds.), ''SFPE handbook of fire protection engineering'' (3rd ed., pp. 1-182–1-192). National Fire Protection Association.
* Meacham, B. J. (2002). Building fire risk analysis. In P. J. DiNenno, D. Drysdale, C. L. Beyler, W. D. Walton, R. L. P. Custer, J. R. Hall, Jr., & J. M. Watts, Jr. (Eds.), ''SFPE handbook of fire protection engineering'' (3rd ed., pp. 5-153–5-175). National Fire Protection Association.
* Modarres, M., & Joglar-Billoch, F. (2002). Reliability. In P. J. DiNenno, D. Drysdale, C. L. Beyler, W. D. Walton, R. L. P. Custer, J. R. Hall, Jr., & J. M. Watts, Jr. (Eds.), ''SFPE handbook of fire protection engineering'' (3rd ed., pp. 5-24–5-39). National Fire Protection Association.
* Watts, J. M., Jr., & Hall, J. R., Jr. (2002). Introduction to fire risk analysis. In P. J. DiNenno, D. Drysdale, C. L. Beyler, W. D. Walton, R. L. P. Custer, J. R. Hall, Jr., & J. M. Watts, Jr. (Eds.), ''SFPE handbook of fire protection engineering'' (3rd ed., pp. 5-1–5-7). National Fire Protection Association.

[[Category:Fire Risk Analysis]]