Fault tree analysis

Fault tree analysis (FTA) is a top down, deductive failure analysis in which an undesired state of a system is analyzed using boolean logic to combine a series of lower-level events. This analysis method is mainly used in the field of safety engineering and Reliability engineering to determine the probability of a safety accident or a particular system level (functional) failure.

In Aerospace the more general term "system Failure Condition" is used for the "undesired state" / Top event of the fault tree. These conditions are classified by the severity of their effects. The most severe conditions require the most extensive fault tree analysis. These "system Failure Conditions" and their classification are often previously determined in the functional Hazard analysis.

FTA can be used to:

• understand the logic leading to the top event / undesired state.
• show compliance with the (input) system safety / reliability requirements.
• prioritize the contributors leading to the top event - Creating the Critical Equipment/Parts/Events lists for different importance measures.
• monitor and control the safety performance of the complex system (e.g., is a particular aircraft safe to fly when fuel valve x malfunctions? For how long is it allowed to fly with the valve malfunction?).
• minimize and optimize resources.
• assist in designing a system. The FTA can be used as a design tool that helps to create (output / lower level) requirements.
• function as a diagnostic tool to identify and correct causes of the top event. It can help with the creation of diagnostic manuals / processes.

History

Fault Tree Analysis (FTA) was originally developed in 1962 at Bell Laboratories by H.A. Watson, under a U.S. Air Force Ballistics Systems Division contract to evaluate the Minuteman I Intercontinental Ballistic Missile (ICBM) Launch Control System. The use of fault trees has since gained widespread support and is often used as a failure analysis tool by reliability experts. Following the first published use of FTA in the 1962 Minuteman I Launch Control Safety Study, Boeing and AVCO expanded use of FTA to the entire Minuteman II system in 1963-1964. FTA received extensive coverage at a 1965 System Safety Symposium in Seattle sponsored by Boeing and the University of Washington. Boeing began using FTA for civil aircraft design around 1966. In 1970, the U.S. Federal Aviation Administration (FAA) published a change to 14 CFR 25.1309 airworthiness regulations for transport category aircraft in the Federal Register at 35 FR 5665 (1970-04-08). This change adopted failure probability criteria for aircraft systems and equipment and led to widespread use of FTA in civil aviation.

Within the nuclear power industry, the U.S. Nuclear Regulatory Commission began using probabilistic risk assessment (PRA) methods including FTA in 1975, and significantly expanded PRA research following the 1979 incident at Three Mile Island. This eventually led to the 1981 publication of the NRC Fault Tree Handbook NUREG–0492, and mandatory use of PRA under the NRC's regulatory authority.

Fault Tree Analysis (FTA) attempts to model and analyze failure processes of engineering and biological systems. FTA is basically composed of logic diagrams that display the state of the system and is constructed using graphical design techniques. Originally, engineers were responsible for the development of Fault Tree Analysis, as a deep knowledge of the system under analysis is required.

Often, FTA is defined as another part, or technique, of reliability engineering. Although both model the same major aspect, they have arisen from two different perspectives. Reliability engineering was, for the most part, developed by mathematicians, while FTA, as stated above, was developed by engineers.

Fault Tree Analysis usually involves events from hardware wear out, material failure or malfunctions or combinations of deterministic contributions to the event stemming from assigning a hardware/system failure rate to branches or cut sets. Typically failure rates are carefully derived from substantiated historical data such as mean time between failure of the components, unit, subsystem or function. Predictor data may be assigned. Assigning a software failure rate is elusive and not possible. Since software is a vital contributor and inclusive of the system operation it is assumed the software will function normally as intended. There is no such thing as a software fault tree unless considered in the system context. Software is an instruction set to the hardware or overall system for correct operation. Since basic software events do not fail in the physical sense, attempting to predict manifestation of software faults or coding errors with any reliability or accuracy is impossible, unless assumptions are made. Predicting and assigning human error rates is not the primary intent of a fault tree analysis, but may be attempted to gain some knowledge of what happens with improper human input or intervention at the wrong time.

FTA can be used as a valuable design tool, can identify potential accidents, and can eliminate costly design changes. It can also be used as a diagnostic tool, predicting the most likely system failure in a system breakdown. FTA is used in safety and reliability engineering and in all major fields of engineering.

Methodology

FTA methodology is described in several industry and government standards, including NRC NUREG–0492 for the nuclear power industry, an aerospace-oriented revision to NUREG–0492 for use by NASA, SAE ARP4761 for civil aerospace, MIL–HDBK–338 for military systems. IEC standard IEC 61025 is intended for cross-industry use and has been adopted as European Norme EN 61025.

Since no system is perfect, dealing with a subsystem fault is a necessity, and any working system eventually will have a fault in some place. However, the probability for a complete or partial success is greater than the probability of a complete failure or partial failure. Assembling a FTA is thus not as tedious as assembling a success tree which can turn out to be very time consuming.

Because assembling a FTA can be a costly and cumbersome experience, the perfect method is to consider subsystems. In this way dealing with smaller systems can assure less error work probability, less system analysis. Afterward, the subsystems integrate to form the well analyzed big system.

An undesired effect is taken as the root ('top event') of a tree of logic. The logic to get to the right top events can be diverse. One type of analysis that can help with this is called the functional hazard analysis, based on Aerospace Recommended Practise. There should be only one Top Event and all concerns must tree down from it. Then, each situation that could cause that effect is added to the tree as a series of logic expressions. When fault trees are labeled with actual numbers about failure probabilities (which are often in practice unavailable because of the expense of testing), computer programs can calculate failure probabilities from fault trees.

File:Fault tree.png

A fault tree diagram

The Tree is usually written out using conventional logic gate symbols. The route through a tree between an event and an initiator in the tree is called a Cut Set. The shortest credible way through the tree from fault to initiating event is called a Minimal Cut Set.

Some industries use both fault trees and event trees (see Probabilistic Risk Assessment). An Event Tree starts from an undesired initiator (loss of critical supply, component failure etc.) and follows possible further system events through to a series of final consequences. As each new event is considered, a new node on the tree is added with a split of probabilities of taking either branch. The probabilities of a range of 'top events' arising from the initial event can then be seen.

Classic programs include the Electric Power Research Institute's (EPRI) CAFTA software, which is used by many of the US nuclear power plants and by a majority of US and international aerospace manufacturers, and the Idaho National Laboratory's SAPHIRE, which is used by the U.S. Government to evaluate the safety and reliability of nuclear reactors, the Space Shuttle, and the International Space Station. Outside the US, the software RiskSpectrum is a popular tool for Fault Tree and Event Tree analysis and is licensed for use at almost half of the worlds nuclear power plants for Probabilistic Safety Assessment.

Graphic Symbols

The basic symbols used in FTA are grouped as events, gates, and transfer symbols. Minor variations may be used in FTA software.

Event Symbols

Event symbols are used for primary events and intermediate events. Primary events are not further developed on the fault tree. Intermediate events are found at the output of a gate. The event symbols are shown below:

• FTA basic event.jpg

  Basic event

• FTA initiating event.jpg

  Initiating event

• FTA undeveloped event.jpg

  Undeveloped event

• FTA conditioning event.jpg

  Conditioning event

• FTA intermediate event.jpg

  Intermediate event

The primary event symbols are typically used as follows:

• Basic event - failure or error in a system component or element (example: switch stuck in open position)
• Initiating event - an external event (example: bird strike to aircraft)
• Undeveloped event - an event about which insufficient information is available, or which is of no consequence
• Conditioning event - conditions that restrict or affect logic gates (example: mode of operation in effect)

An intermediate event gate can be used immediately above a primary event to provide more room to type the event description. FTA is top to bottom approach.

Gate Symbols

Gate symbols describe the relationship between input and output events. The symbols are derived from Boolean logic symbols:

• FTA OR gate.jpg

  OR gate

• FTA AND gate.jpg

  AND gate

• FTA XOR gate.jpg

  Exclusive OR gate

• FTA priority AND gate.jpg

  Priority AND gate

• FTA inhibit gate.jpg

  Inhibit gate

The gates work as follows:

• OR gate - the output occurs if any input occurs
• AND gate - the output occurs only if all inputs occur (inputs are independent)
• Exclusive OR gate - the output occurs if exactly one input occurs
• Priority AND gate - the output occurs if the inputs occur in a specific sequence specified by a conditioning event
• Inhibit gate - the output occurs if the input occurs under an enabling condition specified by a conditioning event

Transfer Symbols

Transfer symbols are used to connect the inputs and outputs of related fault trees, such as the fault tree of a subsystem to its system.

• FTA transfer in.jpg

  Transfer in

• FTA transfer out.jpg

  Transfer out

Basic Mathematical Foundation

Events in a fault tree are associated with statistical probabilities. For example, component failures typically occur at some constant failure rate λ (a constant hazard function). In this simplest case, failure probability depends on the rate λ and the exposure time t:

P = 1 - exp(-λt)

P ≈ λt, λt < 0.1

A fault tree is often normalized to a given time interval, such as a flight hour or an average mission time. Event probabilities depend on the relationship of the event hazard function to this interval.

Unlike conventional logic gate diagrams in which inputs and outputs hold the binary values of TRUE (1) or FALSE (0), the gates in a fault tree output probabilities related to the set operations of Boolean logic. The probability of a gate's output event depends on the input event probabilities.

An AND gate represents a combination of independent events. That is, the probability of any input event to an AND gate is unaffected by any other input event to the same gate. In set theoretic terms, this is equivalent to the intersection of the input event sets, and the probability of the and gate output is given by:

P(A and B) = P(A ∩ B) = P(A) P(B)

An OR gate, on the other hand, corresponds to set union:

P(A or B) = P(A ∪ B) = P(A) + P(B) - P(A ∩ B)

Since failure probabilities on fault trees tend to be small (less than .01), P(A ∩ B) usually becomes a very small error term, and the output of an OR gate may be conservatively approximated by using an assumption that the inputs are mutually exclusive events:

P(A or B) ≈ P(A) + P(B), P(A ∩ B) ≈ 0

An exclusive OR gate with two inputs represents the probability that one or the other input, but not both, occurs:

P(A xor B) = P(A) + P(B) - 2P(A ∩ B)

Again, since P(A ∩ B) usually becomes a very small error term, the exclusive OR gate has limited value in a fault tree.

Analysis

Many different approaches can be used to model a FTA, but the most common and popular way can be summarized in a few steps. A single fault tree is used to analyze one and only one undesired event or top event, which may be subsequently fed into another fault tree as a basic event. Though the nature of the undesired event may vary dramatically, a FTA follows the same procedure for any undesired event; be it a delay of 0.25 msec for the generation of electrical power, an undetected cargo bay fire, or the random, unintended launch of an ICBM. Due to labor cost, FTA is normally only performed for more serious undesired events.

FTA analysis involves five steps:

1. Define the undesired event to study
   • Definition of the undesired event can be very hard to catch, although some of the events are very easy and obvious to observe. An engineer with a wide knowledge of the design of the system or a system analyst with an engineering background is the best person who can help define and number the undesired events. Undesired events are used then to make the FTA, one event for one FTA; no two events will be used to make one FTA.
2. Obtain an understanding of the system
   • Once the undesired event is selected, all causes with probabilities of affecting the undesired event of 0 or more are studied and analyzed. Getting exact numbers for the probabilities leading to the event is usually impossible for the reason that it may be very costly and time consuming to do so. Computer software is used to study probabilities; this may lead to less costly system analysis.
     System analysts can help with understanding the overall system. System designers have full knowledge of the system and this knowledge is very important for not missing any cause affecting the undesired event. For the selected event all causes are then numbered and sequenced in the order of occurrence and then are used for the next step which is drawing or constructing the fault tree.
3. Construct the fault tree
   • After selecting the undesired event and having analyzed the system so that we know all the causing effects (and if possible their probabilities) we can now construct the fault tree. Fault tree is based on AND and OR gates which define the major characteristics of the fault tree.
4. Evaluate the fault tree
   • After the fault tree has been assembled for a specific undesired event, it is evaluated and analyzed for any possible improvement or in other words study the risk management and find ways for system improvement. This step is as an introduction for the final step which will be to control the hazards identified. In short, in this step we identify all possible hazards affecting in a direct or indirect way the system.
5. Control the hazards identified
   • This step is very specific and differs largely from one system to another, but the main point will always be that after identifying the hazards all possible methods are pursued to decrease the probability of occurrence.

Comparison with other analytical methods

FTA is a deductive, top-down method aimed at analyzing the effects of initiating faults and events on a complex system. This contrasts with failure mode and effects analysis (FMEA), which is an inductive, bottom-up analysis method aimed at analyzing the effects of single component or function failures on equipment or subysystems. FTA is very good at showing how resistant a system is to single or multiple initiating faults. It is not good at finding all possible initiating faults. FMEA is good at exhaustively cataloging initiating faults, and identifying their local effects. It is not good at examining multiple failures or their effects at a system level. FTA considers external events, FMEA does not. In civil aerospace the usual practice is to perform both FTA and FMEA, with a failure mode effects summary (FMES) as the interface between FMEA and FTA.

Alternatives to FTA include dependence diagram (DD), also known as reliability block diagram (RBD) and Markov analysis. A dependence diagram is equivalent to a success tree analysis (STA), the logical inverse of an FTA, and depicts the system using paths instead of gates. DD and STA produce probability of success (i.e., avoiding a top event) rather than probability of a top event.

See also

• Root cause analysis
• Ishikawa diagram
• Why-Because analysis

External links

• fault-tree.net - Dedicated to the Proper use of Fault Trees
• RIAC - The Reliability Information Analysis Center
• FAA System Safety Handbookde:Fehlerbaumanalyse