Page 1 of 10

Fault Tree Analysis (FTA)

Fault Tree Analysis is the systematic decomposition of possible product or service failures into the component causes, based on the function of the product or service. Each failure may have several chains of causes, and the logic of failure often involves both AND and OR gates, which are used in the fault tree decompositions. After all important function have been decomposed into their respective fault trees, the design team must decide how best to design the product to prevent the failure. Sometimes probabilities are added to the elements of the tree, and the cost of design changes is justified by the reduction in probability of failure (improved reliability). Fault Tree Analysis (FTA) is an analytical tool that graphically renders the combinations of faults that lead to the failure of a system. This technique is useful for describing and assessing the event within a system. Such events can be either normal or abnormal, but it is their sequence and combination that are important. FTA shows the probabilities of systems failure caused by any event and is widely used in the aerospace, electronics, and nuclear industries. A fault tree is a qualitative model that also can be quantitatively evaluated. FTA is used for reliability, maintainability, and safety analysis and was originally used in 1961 at Bell labs to evaluate Minuteman Launch Control System to avoid inadvertent missile launches. One of the strength of FTA is that it is easy to read and understand. Because of the graphical presentation of the data, anyone can be shown within a few minutes how to read and understand the fault tree. Fault Tree Analysis uses two primary symbols called events and gates. There are three types of events. The first is the primary event. A primary event is a stage in the process of using the product where it might fail. For example, if you put a key into a lock, the key might fail to fit into the lock properly. Primary events are further subdivided into three categories. These are 1. basic events, 2. undeveloped events, and 3. external events. Basic events are initiating faults that do not require event below them to show how they occurred. The symbol used for a basic event is a circle. This can be seen in the Figure 1. Undeveloped events are faults that do not have a significant consequence or are not expanded because insufficient information is available. Undeveloped event are represented by a diamond. External events are normally expected to occur and thus are not considered a fault. External events do not require expanding and are symbolized by a house shape. All three primary events are located in the same place within the diagram. The second main form of an event is the intermediate event. An intermediate event is the result of a combination of faults, some of which may be primary events. This intermediate event is located in the middle of a fault tree. These events are described by rectangles.

Page 2 of 10 The third and last form of an event is called an expanded event. An expanded event requires a separate fault tree because of its complexity. For this new fault tree, the expanded event, designated by a triangle, is the undesired event and would be located at the top of the fault tree. Gates link the faults to the undesired events within the diagram. The purpose of a gate is to show how the faults are related. The position directly above a gate is called an output event and the position directly below the gate is called the input event. The position of a gate implies a cause-andeffect relationship. There are two states in a fault tree analysis. The first state is true and occurs when a part or factor is functioning correctly. The second state is false and happens when a part or factor is malfunctioning.

Fault tree analyses use Boolean logic to describe the combinations of events and states that constitute a hazardous state. Boolean logic assigns a value to both of these two states. The true state is assigned the value of one, whereas the false state is assigned a value of zero. There are eight steps in performing FTA. 1. Become familiar with the system. 2. Define the undesired events of the system with the related contributing and initiating events (e.g., component failure, human error, spontaneous reactions, and external conditions). 3. Develop fault trees for the undesired events. 4. Obtain probabilities for the events on the fault trees. 5. Evaluate fault trees. 6. Analyze the results and proposals for system improvement. 7. Change the fault trees to reflect proposed improvements and renewed fault tree evaluation. 8. Perform a worst-case analysis. The final step verifies whether a design will meet its requirements under the most extreme conditions. When performing the analysis, the designer must assume that anything can go wrong with both the internal and the external systems. Also, the designer must be aware of what can go wrong and what extremes could be reached. Then the designer must analyze the effects of the extremes on system operation and performance. The AND gate requires all evens below it to occur simultaneously to result in the event above it. The OR gate means that the events above it will result if any of the conditions below it are present.

Page 3 of 10 Figure 1: Fault Tree Diagram System failure

Event 1

Event 2

Basic event 1

Event 3

Basic event 2

Event 4

Event expanded

Event expanded

Figure 2: EVENTS & GATES

Page 4 of 10 Events: 1. Primary Event: a) Basic Failure Event (e.g., resistor fails open, etc.)

b) Undeveloped Event, or human error

c) External Event / Normally Occurring Event 2. Intermediate Event: Intermediate Event / Command Event (i.e., always commanded to occur by events below it) 3. Expanded Event: Expanded Event

Gates: And Gate all conditions below required for event above +

OR Gate any condition below gives event above

Figure 3: FLOW CHART

O
Light Bulb does not illuminate

Page 5 of 10

Filament open

Contaminated socket terminals

No electrical energy in socket

Light bulb not fully screwed in

2 1

Socket disconnected from wiring

No electrical energy on wiring to socket Wiring short circuit Wiring open circuit

4 5
No electrical energy on wiring to switch

Operator does not activate switch

Switch fails, & is open

No electrical energy on wiring to MAIN SWITCH Wiring short circuit Wiring open circuit

ELCB Trip

10
TNB electricity supply failure

11

12 Figure 4: LIGHT BULB CIRCUIT

Stand-by Generator not functioning

13

TNB

II
MAIN SWITCH

Stand-by Generator

Page 6 of 10 Indicator Light

I I

Switch

Figure 5: The Failure Mode Assessment and Assignment Matrix (FMA&A)

Event No.

Description

Assess

Assignment

Page 7 of 10 ment
Likely Unlikely Unknown x x x

1 2 3 4 5 6 7 8 9 10 11 12

Filament Open Contaminated socket Terminals Light Bulb Not Fully Screwed In Socket Disconnected from wiring Wire Short Circuit Wiring Open Circuit Operator Does Not Activate Switch Switch Fails Open Wiring Short Circuit Wiring Open Circuit No Power From TNB Stand-by Generator Not Functioning

Examine bulb for open filament. Liew - 16 April 2007 Examine socket for contaminants. Liew - 16 April 2007 Inspect bulb in socket to determine if properly installed. Ali 18 April 2007 Examine wiring and perform continuity test. Ahmad 20 April 2007 Examine wiring and perform continuity test. Ahmad 20 April 2007 Examine wiring and perform continuity test. Ahmad 20 April 2007 Interview operator and check switch function. Wong 16 April 2007 Check switch function. Ali 18 April 2007 Examine wiring and perform continuity test. Ahmad 20 April 2007 Examine wiring and perform continuity test. Ahmad 20 April 2007 Check power supply with multimeter. Ahmad 20 April 2007 Check Stand-by generator function. Ali 18 April 2007

Figure 6: Systems Failure Analysis Flow Chart. The fault tree analysis develops all potential failure causes.

Page 8 of 10 The failure mode assessment and assignment matrix list each of the potential failure causes and actions required to evaluate them. Supporting analysis techniques allow converging on the most likely failure causes, and Corrective actions are implemented and evaluated for their effectiveness in eliminating recurrences.

Failure Occur

Fault Tree Analysis

Failure Mode Assessment And Assignment

Converge On Root Cause(s)

Hardware Analysis Pedigree Analysis Whats Different Analysis Other Supporting Analysis Special Test

Develop And Implement Corrective Action

Monitor Corrective Action Effectiveness

Figure 7: Organizing The Failure Analysis This approach helps bring the right information and team members together to prepare the fault tree and FMA&A, and to pursue a systematic identification and evaluation of all potential failure causes.

Page 9 of 10
Determine Team Makeup Failure Analysis Assignment Gather Preliminary Data Convene Team Meeting Brainstorm Fault Tree

Prepare FMA&A Matrix

Negotiate Assignments

Reconvene Often Update FMA&A

Converge On Most Likely Causes

Reliability Of Bulb

Chances Light Bulb illuminates is = ROR Gate 1 = R1 x R2 x R3 x ROR Gate 2 = R1 x R2 x R3 x [R4 x R5 x R6 x ROR Gate 3] = R1 x R2 x R3 x R4 x R5 x R6 x [R7 x R8 x ROR Gate 4] = R1 x R2 x R3 x R4 x R5 x R6 x R7 x R8 x [R9 x R10 x R11 x RAND Gate] = R1 x R2 x R3 x R4 x R5 x R6 x R7 x R8 x R9 x R10 x R11 x [1 (1 R12)(1 R13)]

Failure Analysis Reports Recording systems failure analysis results is important for several reasons. A well-written failure analysis report details the results of the failure analysis, and it defines required corrective actions. The failure analysis report provides a permanent record of the failure, the analysis to identify its causes, and required corrective actions.

Page 10 of 10 A narrative format for a system failure analysis, organized as described below is recommended. o Executive Summary. This section should provide a brief description of the failure, its causes, and recommended corrective actions. It is recommended to include it on the first page of the failure analysis report. o Description of the Failure. This section should provide a detailed description of the failure and the circumstances under which it occurred. o Conclusions and Recommendations. This section should present the failure analysis findings and recommended corrective actions. The information should be more detailed than that provided in the executive summary. o Whats Different? Analysis. This section should define any differences discovered during the analysis that are related to the failure. If no differences relate to the failure, the report should explain the differences that were found and why they were considered to be unrelated. o Pedigree Analysis. This section should define the documentation reviewed during the failure analysis, and the conclusion of the review. o Environment Analysis. This section should define the environment in which the system was attempting to operate when it failed. It should also define the rated environments of all the systems components and subassemblies (i.e., those identified in the fault tree analysis and FMA&A as potential contributors to the failure). This part of the analysis should state whether the systems operating environment contributed to the failure. o Hardware Analysis. This section should define the results of the hardware failure analysis. We recommend including photographs or other illustrations supporting the findings of the failure analysis. (Refer the details of hardware analysis to TQM Implementing Continuous Improvement by Joseph & Susan Berk.) o Other Analyses Done. Include also all other analyses, such as DOE, ANOVA, software analysis, etc., conducted. o Prior Failure History. This section should describe any previous similar failure (if any exist), and prior corrective actions. The relationship between the prior failures and the one being analyzed should be described. o Appendices. Include the fault tree analysis and the FMA&A as appendices to the failure analysis report. References 1. Taguchi Techniques for Quality Engineering, Philip J. Ross, McGraw-Hill Book Co. 1988. 2. Fault Tree Construction Guide, Armament Development Test Center United States Air Force, May 1974. 3. Fault Tree Analysis, Waldemar F. Armament Development Reliability Division, Picatinny Arsenal, United States Army, August 1968.