2

GENERAL ANALYSIS TECHNIQUES

A number of general techniques are useful for problem solving. While many com-
mon, or overlapping, methodologies are associated with these techniques, there also
are differences. This chapter provides a brief overview of the more common methods
used to perform an RCFA.
FAILURE MODE AND EFFECTS ANALYSIS
A failure mode and effects analysis (FMEA) is a design-evaluation procedure used to
identify potential failure modes and determine the effect of each on system perfor-
mance. This procedure formally documents standard practice, generates a historical
record, and serves as a basis for future improvements. The FMEA procedure is a
sequence of logical steps, starting with the analysis of lower-level subsystems or com-
ponents. Figure 2-1 illustrates a typical logic tree that results with a FMEA.
The analysis assumes a failure point of view and identifies potential modes of fail-
ure along with their failure mechanism. The effect of each failure mode then is
traced up to the system level. Each failure mode and resulting effect is assigned a
criticality rating, based on the probability of occurrence, its severity, and its delecta-
bility. For failures scoring high on the criticality rating, design changes to reduce it
are recommended.
Following this procedure provides a more reliable design. Also such correct use of the
FMEA process results in two major improvements: (1) improved reliability by antici-
pating problems and instituting corrections prior to producing product and (2)
improved validity of the analytical method, which results from strict documentation
of the rationale for every step in the decision-making process.
6
General Analysis Techniques 7
Primarily qualitative
reiiabilily disciplines
Primarily quantitative
rellabUity disciplines
m A c ap t failure elTed
j
Figure 2-1 Failure mode and effects analysis (FMEA)Jlow diagram.
Eliminate failure effect
Two major limitations restrict the use of FMEA: (1) logic trees used for this type of
analysis are based on probability of failure at the component level and ( 2) full applica-
tion is very expensive. Basing logic trees on the probability of failure is a problem
because available component probability data are specific to standard conditions and
extrapolation techniques cannot be used to modify the data for particular applications.
I
I
i ---c
I
Tmde-al kandadi on
dedsions
Determine corndive
actions I
I I
FAULT-TREE ANALYSIS
Fault-tree analysis is a method of analyzing system reliability and safety. It provides
an objective basis for analyzing system design, justifying system changes, performing
trade-off studies, analyzing common failure modes, and demonstrating compliance
with safety and environment requirements. It is different from a failure mode and
effect analysis in that it is restricted to identifying system elements and events that
lead to one particular undesired event. Figure 2-2 shows the steps involved in per-
forming a fault-tree analysis.
Reduce failure e M ----*
Many reliability techniques are inductive and concerned primarily with ensuring that
hardware accomplishes its intended functions. Fault-tree analysis is a detailed deduc-
tive analysis that usually requires considerable information about the system. It
ensures that all critical aspects of a system are identified and controlled. This method
represents graphically the Boolean logic associated with a particular system failure,
8 Root Cause Failure Analysis
Define top event
Q
Establish boundaries
Understand system
Construct fault tree
0
Analyze tree
4
Take corrective action
Figure 2-2 apical fault-tree process.
called the top event, and basic failures or causes, called primary events. Top events
can be broad, all-encompassing system failures or specific component failures.
Fault-tree analysis provides options for performing qualitative and quantitative reli-
ability analysis. It helps the analyst understand system failures deductively and points
out the aspects of a system that are important with respect to the failure of interest.
The analysis provides insight into system behavior.
A fault-tree model graphically and logically presents the various combinations of pos-
sible events occurring in a system that lead to the top event. The term event denotes a
dynamic change of state that occurs in a system element, which includes hardware,
software, human, and environmental factors. A fault event is an abnormal system
state. A normal event is expected to occur.
The structure of a fault tree is shown in Figure 2-3. The undesired event appears as
the top event and is linked to more basic fault events by event statements and logic
gates.
General Analysis Techniques 9
Motor Oveheats
OR
- Exm%ive Cumnl To Mobr
(closed)
Figure 2-3 Example of a fault-tree logic tree.
CAUSE-AND-EFFECT ANALYSIS
Cause-and-effect analysis is a graphical approach to failure analysis. This also is
referred to as fishbone analysis, a name derived from the fish-shaped pattern used to
plot the relationship between various factors that contribute to a specific event. Typi-
cally, fishbone analysis plots four major classifications of potential causes @e.,
human, machine, material, and method) but can include any combination of catego-
ries. Figure 2-4 illustrates a simple analysis.
Like most of the failure analysis methods, this approach relies on a logical evaluation
of actions or changes that lead to a specific event, such as machine failure. The only
difference between this approach and other methods is the use of the fish-shaped
graph to plot the cause-effect relationship between specific actions, or changes, and
the end result or event.
This approach has one serious limitation. The fishbone graph provides no clear
sequence of events that leads to failure. Instead, it displays all the possible causes that
10 Root C a w Failure Analysis
- Methods
/
Materials
Figure 2-4 OpicalJishbone diagram plots four categories of causes.
may have contributed to the event. While this is useful, it does not isolate the specific
factors that caused the event. Other approaches provide the means to isolate specific
changes, omissions, or actions that caused the failure, release, accident, or other event
being investigated.
SEQUENCE-OF-EVENTS ANALYSIS
A number of software programs (e.g., Microsoft's Visio) can be used to generate a
sequence-of-events diagram. As part of the RCFA program, select appropriate soft-
ware to use, develop a standard format (see Figure 2-5), and be sure to include each
event that is investigated in the diagram.
Using such a diagram from the start of an investigation helps the investigator organize
the information collected, identify missing or conflicting information, improve his or
her understanding by showing the relationship between events and the incident, and
highlight potential causes of the incident.
The sequence-of-events diagram should be a dynamic document generated soon after
a problem is reported and continually modified until the event is fully resolved.
Figure 2-6 is an example of such a diagram.
Proper use of this graphical tool greatly improves the effectiveness of the problem-
solving team and the accuracy of the evaluation. To achieve maximum benefit from
General Analysis Techniques 11
EVENTS:
Events are displayed M retangular boxes, which are mrmected by flow
direction allows that provide the proper sequence for events.
Each box should contain only one event and the date and time that it
olxumd.
Use predse, factual nonjudgemental words and quantify when possible.
QUALIFIERS:
Each event should beclarified by using oval data bl& that provide
qualifying data pertinent to that event
Each oval should contain only one qualifier that provides clarification
a unique restriction, or other condition that may have influenced the event.
Each qualifier oval should be connected to the appropriate event box using
a direction m w that confirms its assahtion to a specific event.
FORCING FUNCllONS
Factors that could have contributed to the event should be displayed as a
hexagon- shaped data box.
Each hexagon should contain one concisely defined forcing f unai on
Forcing functions should be conrmted to a BpecitL event using a direction
umw that confirms its assaiation with that event.
INCIDENT:
The Incident box contains a brief statement of the r e m for the
investigation.
The Incident box should bei nserted at the proper point in the event
sequence and c o md to the event boxes using direction allows.
'Ihere should be only one incident data box included in each
investigation
ASSUMPIIONS
Unconfirmed conditions or contributing factors CUI beincluded in
the flow diagram by using annotations. This method permits the
inclusion of multiple assumptions or unanswered questions that may
help Clarify an Went.
Figure 2-5 Symbols used in sequence-of-events diagram.
w-,
I - /
this technique, be consistent and thorough when developing the diagram. The follow-
ing guidelines should be considered when generating a sequence-of-events diagram:
Use a logical order, describe events in active rather than passive terms, be precise, and
define or qualify each event or forcing function.
12 Root Cause Failure Analysis
Figure 2-6 Typical sequence-of events diagram.
In the example illustrated in Figure 2-6, repeated trips of the fluidizer used to transfer
flake from the Cellulose Acetate (CA) Department to the preparation area triggered an
investigation. The diagram shows each event that led to the initial and second fluidizer
trip. The final event, the silo inspection, indicated that the root cause of the problem
was failure of the level-monitoring system. Because of this failure, Operator A over-
filled the silo. When this happened, the flake compacted in the silo and backed up in
the pneumatic-conveyor system. This backup plugged an entire section of the pneu-
matic-conveyor piping, which resulted in an extended production outage while the
plug was removed.
Logical Order
Show events in a logical order from the beginning to the end of the sequence. Initially,
the sequence-of-events diagram should include all pertinent events, including those
that cannot be confirmed. As the investigation progresses, it should be refined to show
only those events that are confirmed to be relevant to the incident.
General Analysis Techniques 13
Active Descriptions
Event boxes in a sequence-of-events diagram should contain action steps rather than
passive descriptions of the problem. For example, the event should read: Operator A
pushes pump start button not The wrong pump was started. As a general rule, only
one subject and one verb should be used in each event box. Rather than Operator A
pushed the pump stop button and verified the valve line-up, two event boxes should
be used. The first box should say Operator A pushed the pump stop button and the
second should say Operator A verified valve line-up.
Do not use peoples names on the diagram. Instead use job functions or assign a code
designator for each person involved in the event or incident. For example, three oper-
ators should be designated Operator A, Operator B, and Operator C.
Be Precise
Precisely and concisely describe each event, forcing function, and qualifier. If a con-
cise description is not possible and assumptions must be provided for clarity, include
them as annotations. This is described in Figure 2-5 and illustrated in Figure 2-6. As
the investigation progresses, each assumption and unconfirmed contributor to the
event must be either confirmed or discounted. As a result, each event, function, or
qualifier generally will be reduced to a more concise description.
Define Events and Forcing Functions
Qualijiers that provide all confirmed background or support data needed to accurately
define the event or forcing function should be included in a sequence-of-events dia-
gram. For example, each event should include date and time qualifiers that fix the time
frame of the event.
When confirmed qualifiers are unavailable, assumptions may be used to define uncon-
firmed or perceived factors that may have contributed to the event or function. How-
ever, every effort should be made during the investigation to eliminate the
assumptions associated with the sequence-of-events diagram and replace them with
known facts.