Basics of Failure Analysis

H Hu un nt ts sv vi il ll le e R Re eg gi io on na al l
C Ch ha ap pt te er r

April 26, 2002 1
INTERNATIONAL COUNCIL ON SYSTEMS ENGINEERING
Huntsville Regional Chapter

Terry A. Kuykendall, Instructor

Radisson Hotel
8720 Madison Blvd.
Madison, AL


April 26, 2002 2
Basics of Failure Analysis

Disclaimer:

This paper was prepared and presented by Dr. Terry A. Kuykendall as a tutorial and training course
sponsored by the Huntsville Chapter of the International Council on Systems Engineering (INCOSE), April
26
th
, 2002, for personnel seeking an introductory course in failure analysis. This paper, contents inclusive, are
the intellectual property of Dr. Terry A. Kuykendall and Evolve Engineering & Analysis, LLC. For permission to
reproduce any/all of the contents of this presentation, please contact the author at:

Terry A. Kuykendall
Evolve Engineering & Analysis, LLC
6020 Yorkridge Drive
Alpharetta, GA 30005
P: 770-888-0898
C: 678-371-0285
terry@evolve-eng-llc.com
www.evolve-eng-llc.com


April 26, 2002 3

Course Objectives:

1. Develop an understanding of failure
functions, concepts, and techniques
2. Review some of the techniques and
methods of failure analysis
3. Participate in a workshop on practical
application of failure analysis


April 26, 2002 4

Role of Failure Analysis
in Design and Engineering


April 26, 2002 5
Basics of Failure Analysis Role of Failure Analysis in Design and Engineering

Kuykendalls Fundamental Failure
Theorem #1:

Failure is the basis for all scientific and
engineering achievement.


April 26, 2002 6

Corollary to Failure Theorem #1:
Failure is Necessary to:
1. Establish a base of information upon which
successes may be expected or predicted;
2. Define the boundaries and extent of the
usefulness of an invention or discovery; and
3. Test the application of the Scientific
Method.


April 26, 2002 7

Theorem #2:

Failures have been an important,
dramatic, and sometime tragic (but
necessary) part of our history, lives
and evolution as a species.


April 26, 2002 8

Prehistoric Failure Analysis


April 26, 2002 9

Excerpt from the Code of Hammurabi*:

I f a builder build a house for a man and do not make its construction firm, and the house
which he has built collapse and cause the death of the owner of the house, that
builder shall be put to death.
I f it cause the death of the son of the owner of the house, they shall put to death a son of
that builder.
I f it cause the death of a slave of the owner of the house, he shall give to the owner of the
house a slave of equal value.
I f it destroy property, he shall restore whatever it destroyed, and because he did not make
the house which he built firm and it collapsed, he shall rebuild the house which
collapsed from his own property.
I f a builder build a house for a man and do not make its construction meet the
requirements and a wall fall in, that builder shall strengthen the wall at his own
expense.

* Sixth ruler, First Dynasty of Babylon, approx. 4000 years ago


April 26, 2002 10

The Pyramid of Dashur (the Bent Pyramid)


April 26, 2002 11

Tacoma Narrows Bridge


April 26, 2002 12

Three-Mile Island


April 26, 2002 13

Challenger Accident


April 26, 2002 14

Theorem #3:

It is the responsibility of the practicing
engineer or scientist to understand
failures and their role in discovery,
invention and design in order to
minimize adverse affects to people and
our environment.


April 26, 2002 15

Failure Analysis
Concepts and Techniques


April 26, 2002 16
Basics of Failure Analysis Failure Analysis Concepts and Techniques

Failure Analysis techniques are utilized to:

1. Obtain a better understanding of failure events and
causative factors;

2. Develop remedial actions for the prevention of
failure recurrence; and

3. Establish ownership of the failure (failed system)
and responsibility for remedial action.


April 26, 2002 17

Life Cycle Failures

Design-Related Failures typically occur when normal
operational stresses exceed the design-basis strength;

Production- or Process-Related Failures typically occur when
the design strength is degraded or overstressed by factors in
the production process;

Use-Related Failures typically occur when the normal
operating life is exceeded or abnormal operational stresses or
maintenance-related stresses exceed the design strength in
the use environment.


April 26, 2002 18

Types of Failure Analysis Activities

Destructive Physical Analysis
Physics of Failure Analysis
Fault Tree Analysis
Common-Mode Failure Analysis
Failure Modes and Effects Analysis
Failure Modes, Effects, and Criticality
Analysis
Functional Failure Analysis
Sneak Circuit Analysis
Software Failure Analysis


April 26, 2002 19

Destructive Physical Analysis (DPA)

Involves methodical dissection, inspection and testing of
unfailed parts or equipment

Most often performed for initial performance testing, or as
a receiving inspection on samples of incoming items or
materials (and may serve a QA/QC function)

May be utilized as an element of in-process verification

Uses a wide range of tools and techniques to determine
physical abnormalities or process changes

Identifies unreported changes in design, materials, or
production processes


April 26, 2002 20

Physics of Failure Analysis

Sometimes called reliability physics, involves physical,
chemical, and/or electrical analysis of failed assemblies,
parts, equipment, or materials and investigation of the
failure mechanisms

Typically applied in situations where there is some
uncertainty with regard to the cause of failure (e.g., during
acceptance testing, development growth testing, reliability
demonstration tests, etc.)

May use equipment and processes similar to DPA, and
seeks to identify the cause-and-effect relationship involved
in the failure mechanism and process


April 26, 2002 21

Fault Tree Analysis (FTA)

Developed by the aerospace industry to apply logic
diagrams and Boolean algebra to represent and
summarize the different events that can lead to an
undesired event

Deductive, top-down method of analyzing system design
and performance

Involves specifying a top event to analyze, followed by
identifying all of the associated elements in the system
that could cause the top event to occur
Utilizes symbolic representation of the combination of
events resulting in the occurrence of the top event; events
and gates are represented by symbols


April 26, 2002 22

Example -- Simple Fault Tree


April 26, 2002 23

Common-Mode Failure Analysis

Developed to analyze redundancy as a design tool to
achieve reliability for the design of fault-tolerant systems

Evaluates failures that can bridge and defeat the
redundancy factor by causing system failure by
simultaneously sequentially impacting redundant elements

Considers failures that may be result from common
causes such as fires, electrical overloads, maintenance or
operations errors, etc.

The initiating event may be independent of, or external to,
the specific system/equipment addressed by the analysis


April 26, 2002 24

Failure Modes & Effects Analysis (FMEA)

Powerful tool that may be applied at any level of a system
or process, and at any stage of development or operation

Evaluates the potential modes or methods of failures
(single failure analysis), and estimates the postulated
effects of these failures on the item, system, equipment,
and/or operation

Aids in identifying design weaknesses and systems or
equipment that can be rendered inoperable by common
failure events

Provides a systematic method for documenting the results
of the analysis for future consideration


April 26, 2002 25

Example FMEA Worksheet (1)


April 26, 2002 26

Failure Modes, Effects & Criticality
Analysis (FMECA)

Uses the same approach and methodology as the FMEA
process

Adds an additional evaluation process to rank the relative
importance (or criticality) of the failures under evaluation

Supports the allocation of limited resources to the system
requiring the most consideration, or that requires design
optimization


April 26, 2002 27

Example -- Criticality Analysis Worksheet


April 26, 2002 28

Functional Failure Analysis (FFA)

Utilized to identify and document the system elements,
functions, and failure modes that are most important to
maintenance and logistics planning

Uses many of the same input sources as the FMEA
process; in addition, considers other input such as
logistical support activities, maintenance concepts, level of
repair assessments, and mission essential classification

Involves a worksheet format to evaluate each functionally
significant item


April 26, 2002 29

Sneak Circuit Analysis

Addresses failures in electrical or electronic systems when
a latent path or condition causes an undesired event to
occur, and/or inhibits the proper performance of a required
function with the occurrence of a component failure

Evaluates sneak circuit problems such as:
Sneak Paths -- A design error that permits the flow of current
over an unintended path
Sneak Timing -- The occurrence of a circuit function at an
improper time
Sneak Label or Indication -- Incorrect or misleading labeling
of a switch, display, or other interactive component


April 26, 2002 30

Patterns Used in Sneak Circuit Analysis


April 26, 2002 31

Software Failure Analysis

Evaluates problems and discrepancies occurring the in the
design or operation of software (software error analysis)
Addresses software problems including:
Errors -- not failures, but are incorrectly computed values or
conditions, or human errors that caused the fault in software
Faults resulting directly from software errors or accidental
conditions that may cause system or functional units to fail
Failures may be produced by faults, may represent the loss
of functional capability by a system element, or may involve
the operational departure of a program from requirements
May involve a combination of analytical techniques


April 26, 2002 32

Software Failure Analysis Techniques

Stress Testing

Path Testing

Equivalence Classes

Symbolic Execution

Storage Testing

Boundary Value Analysis

Diagnostics

Logic Testing

Cause-Effect Graphing

Postfunctional Analysis

Simulation

Algorithm Evaluation

Top-Down or Bottom-Up
Testing

Timing Analysis

Function Testing

Volume Testing

Execution Analysis

Static Analysis

Security Testing

Modeling


April 26, 2002 33

The Future of Failure Analysis

Modern failure analysis may involve the deployment of
multidisciplinary teams or task groups to study complex
systems and functions that interact with operating and
maintenance personnel, procedures and protocol,
government regulations, legislation, political action, the
environment, and the general public.

Examples of modern systems and operations that have required
failure analyses include nuclear power, missile ranges,
food and chemical processing, offshore oil drilling, rail
transportation, and automobiles.


April 26, 2002 34

Relationship of Failure
Analysis to Other Studies
and Evaluations


April 26, 2002 35
Basics of Failure Analysis Relationship of Failure Analysis to Other Studies and
Evaluations

Failure analyses receive input from, provide output
to, and interact with a number of engineering
studies such as:

Safety/Hazards Analyses
Reliability, Availability, and Maintainability (RAM) Analyses
Human Factors Analyses
Design Criteria and Specifications
Engineering Studies and Analyses
Operations Procedures and Protocol


April 26, 2002 36
Evaluations

Typical Failure Analysis Interactions

Reliability, Availability,
and Maintainability
Analysis
Failure
Analysis
Human Factors
Analysis
Preliminary Design
Information and
Documentation
Preliminary
Hazards/Safety
Analyses
Design/Operations:

Facility Design Documentation

System Design Documentation

Process Hazards Analyses

Hazards and Operability Studies

Safety Analyses and Reports

Time and Motion Studies

Dynamic Process Analyses

Mathematical/Parametric Studies

Data Base Development

Computer Modeling

Statistical Analysis


April 26, 2002 37
Evaluations

Input to Failure Analyses

Preliminary design information provides the description of the
systems/equipment to be analyzed, and some insight on potential
failure modes

Preliminary design information also provides the basis for
comparison of failure mechanisms to industry standards, failure
data bases, and vendor specifications that identify expected
failure and reliability data

Preliminary safety and hazards analysis information establishes
where hazardous materials and energies exist, and where failure
may manifest in the most severe conditions and results


April 26, 2002 38
Evaluations

Relationship to RAM Analyses

Failure and reliability are (in general) inverse functions, so there is
a natural relationship between the rate of failure and the projected
reliability of systems, equipment, and processes

Reliability, Availability, and Maintainability (RAM) analyses
typically are conducted utilizing information provided by failure
analyses

Failure information may provide input and the basis for reliability
analyses; however, in situations where reliability information is
known or is considered to be design basis criteria (e.g., an
established process throughput), reliability data can serve as input
for failure analyses


April 26, 2002 39
Evaluations

Relationship to Human Factors Analyses

Human action, process intervention and control, and human error
are often contributors to failure modes and events that exacerbate
failure scenarios

Human Factors Analyses provide summaries of conditions,
situations, and functions where human actions may induce failure,
thereby identifying areas where additional considerations are
required for failure detection, prevention, and mitigation

Human Factors Analyses may be developed concurrently with
failure analyses, or may precede or follow failure analyses; ideally,
the information associated with human failure will be included in
both analyses and will address failure concerns from the different
perspectives of the specific analytical processes


April 26, 2002 40
Evaluations

Output of Failure Analyses

The information on process, equipment, and operational failure
compiled by failure analyses provides specific criteria that can be
integrated into design and operations to ensure that adequate
functionality has been incorporated

Failure analyses identify situations where failure is the initiating or
contributing cause of scenarios and event sequences that can
include accident conditions, thereby providing input for safety and
hazards analyses

Failure analyses also aid in defining the limitations, boundaries,
and constraints on designed systems and operations that are
required for the development of process models, simulations, and
detailed engineering analyses


April 26, 2002 41

Failure Classification
and Categorization


April 26, 2002 42
Basics of Failure Analysis Failure Classification and Categorization

Classification and Categorization
Failures may be classified based on the severity of the results
of the final manifestation of the failure

Classification can be based on the unmitigated results of the
failure (typical FMEA approach), and/or by taking credit for
planned prevention and mitigation measures

Failures can be categorized based on importance to the
program, operations, and other functional concerns (e.g.,
safety, environmental protection, quality assurance)


April 26, 2002 43

Failure Classification
Based on grouping by severity (consequence) of failures

Number of levels of severity may be assigned based on the
complexity and types of consequences relevant to the specific
operations

Levels of severity typically are associated with the types and
levels of hazards associated with the facility or processes


April 26, 2002 44

Typical 4-Part Classification Scheme*
Category I Catastrophic: A failure that may cause death or high/major
system loss
Category II -- Critical: A failure that may cause severe injury, major
property damage or major system damage that will result in mission
loss
Category III Marginal: A failure that may cause minor injury, minor
property damage, or minor system damage that will result in delay or
loss of availability or mission degradation
Category IV Minor: A failure not serious enough to cause injury,
property damage, or system damage, but that will result in
unscheduled maintenance or repair

* Similar to that proposed in MIL-STD-1629A, Procedures for Performing a Failure Mode,
Effects and Criticality Analysis


April 26, 2002 45

Example Categorization Approach
High Priority/Consideration -- Failures that have the potential for
severe safety or environmental consequences, or that can
impact mission success

Intermediate Priority/Consideration -- Failures that have the
potential for moderate safety or environmental consequences,
or that can impact process throughput

Low Priority/Consideration -- Failures that have only minor potential
for safety impact, little or no environmental consequences,
and that have only temporary impact on operations


April 26, 2002 46

The Failure Modes and
Effects Analysis (FMEA)
Process


April 26, 2002 47
Basics of Failure Analysis The Failure Modes and Effects Analysis (FMEA)
Process

Objectives
1. Present the basis, rationale and decision criteria for the
application and implementation of FMEAs

2. Discuss the philosophy and approach for the setup and
conduct of FMEAs

3. Explore tools and techniques useful for the implementation of
the FMEA process


April 26, 2002 48
Process

The FMEA Process
Evaluates failure modes of a given system, subsystem,
component or process for the effects on other components
and ultimate effects on the overall parent system or facility.
Examines structures, systems, and/or components (SSCs) to
analyze and evaluate normal operating modes, off-normal
and transient modes, failure modes, and consequences.
Identifies failures, weaknesses and hazards that have the
potential to exceed design basis and/or accident criteria.
Identifies problem areas and supports development of
corrective actions for any condition that could jeopardize the
project integrity, imperil human safety or result in
unacceptable system damage.


April 26, 2002 49
Process

FMEA Philosophy
Bottoms-up approach to analyzing system design and
performance
Lowest levels of systems/components are outlined and
defined
Potential failures of lower level items are defined, and effects
of failures are determined
Failures are summed to provide an analysis of systemic
failure
Involves evaluation of the likelihood and severity of failure,
and effects on related/embedded systems


April 26, 2002 50
Process

It is important to remember:
There are many ways that FMEAs can be formatted; there is
no one way or right way
As long as the process completes the objective of evaluating
failure at the appropriate or desired level, the process and
format are valid
FMEAs may be tailored to the needs of the analyst on a case-
by-case and project-by-project basis
FMEAs may be conducted in sequences of increasing
complexity or to provide additional detail in subsequent
design development


April 26, 2002 51
Process

FMEA Team Composition
FMEA team lead (systems engineer)
Technical/design representatives (discipline engineers)
Operations and maintenance personnel
Safety, environmental, and quality assurance specialists
Topical/technical specialists
Equipment suppliers/vendors (as appropriate)


April 26, 2002 52
Process

FMEA Worksheets
Allow organization and cataloging of FMEA information
Ensures a uniform formatting and approach for efforts
Provide a means of grouping information and data
Promote integration into a data base management and results
tracking system
Serves as a guide to the analyst to ensure that important
information is captured and logged


April 26, 2002 53
Process

Example -- FMEA Worksheet (2)


April 26, 2002 54
Process

Two Functional Categories of FMEAs
1. Components-Level FMEAs
2. Systems-Level FMEAs


April 26, 2002 55
Process

Components-Level FMEAs
Evaluates failure modes and effects at the components level
(i.e., smallest functioning unit) of design, engineering or
operation
Addresses components [typically]as complete functioning
units (rather than as parts)
Facilitates analysis of complex components by subdividing
the component into operational subcomponents
Provides evaluation of probability (likelihood) and frequency
(rate) of failure


April 26, 2002 56
Process

When to Use Components-Level FMEAs
When information is required on the anticipated failure of
parts or components in order to assess the effect on the
parent system or operation
When design has been developed to the stage where details
on the most likely components are available
When detailed design assessments are required for design
completion and failure is a criterion
When components alternatives are under consideration, and
comparative information is required


April 26, 2002 57
Process

Output of Components-Level FMEAs
Identifies hazards and safety issues of specific parts of
equipment or systems

Focuses the designation and specification of safety and non-
safety related parts, components, and systems

Develops information that can be utilized for specifications,
procurement, and operations/maintenance

Defines the basis for component tolerance, operating
conditions, and limitations


April 26, 2002 58
Process

Summary -- Components-Level FMEAs:

Are used when specific information is required at the lowest
(most detailed) level of design

Provide criteria that is used to support specification of parts
and components

Determine the lowest level of system function that must be
classified as safety significant


April 26, 2002 59
Process

Systems-Level FMEAs
Addresses failure modes and effects at the systems level
(e.g., higher level of design detail than components)
Divides the facility, structure, or operation into functional
groupings or systems
Defines the functional boundaries and interfaces between
systems
Treats each system as a compilation of subsystems that
comprise a black box
Provides no evaluation of probability or frequency of failure
(e.g., all failures occur, effects are instantaneous)


April 26, 2002 60
Process

When to Use Systems-Level FMEAs
When information is needed for decision-making processes
(e.g., trade studies), but design is not sufficiently progressed
for components analysis
When making preliminary determinations of which systems
are critical, and therefore deserve early emphasis and design
focus
When making preliminary assessments of which systems are
important to safety


April 26, 2002 61
Process

Output of Systems-Level FMEAs
Identifies the hazards most likely to be of concern to the processes
and operations

Allows the preliminary identification of safety and non-safety related
systems

Provides a mechanism to reduce the number of systems, hazards,
and scenarios that must be submitted for more rigorous safety
evaluation

Develops information to be utilized in other systems engineering
and/or safety analyses (e.g., HAZOPS, PHA, ETA/FTA, etc.)

Provides input for RAM analysis information to support design
decisions


April 26, 2002 62
Process

Summary -- Systems-Level FMEAs:

Are useful for application when limited input is available, but
output information is necessary for design to progress

Provide an important base of information that supports
subsequent engineering analyses and evaluations

Allow limited resources to be applied to the most important
and critical systems design


April 26, 2002 63
Process

FMEA Software
Commercially-available software packages (e.g., FMEA data base
software) may be utilized to:

1. Expedite the conduct of multiple/concurrent FMEA efforts;

2. Maintain consistency among a large number of FMEA
modules, and among multiple analysts;

3. Guide the FMEA effort by providing a reference-based format;

4. Ensure compatibility of the FMEA with future, more detailed
efforts (e.g., Components-Level FMEAs)

5. Provide a ready (translational) basis for performing RAM
analyses.


April 26, 2002 64
Process

Examples of FMEA Software
FMEA/FMECA, Relex Software Corporation

FMECA, FRACAS, Advanced Logistics Developments, Inc.

FMEA Software Tool, International SEMATECH, Inc.

Process & Design FMEA, SoHar Corporation

FMEA-Pro5 Dyadem International Limited

FMEA Investigator (Training Software), Resource Engineering, Inc.


April 26, 2002 65
Process

References and Information Sources
Guidelines for Hazard Evaluation Procedures, Center for Chemical
Process Safety, American Institute of Chemical Engineers
MIL-STD-1629A, Procedures for Performing a Failure Mode, Effects
and Criticality Analysis
Handbook of Reliability Engineering and Management, Ireson, W.G.
and C.F. Coombs, Jr.
RADC-TR-83-72, The Evolution and Practical Applications of Failure
Modes and Effects Analyses, Rome Air Development Center, Air Force
Systems Command
ARP-926, Design Analysis Procedure for Failure Mode, Effects, and
Criticality Analysis (FMECA), Society of Automotive Engineers
NASA Bibliography data base:
http://www.sti.nasa.gov/new/fmec33.html


April 26, 2002 66

FMEA Workshop


April 26, 2002 67
Basics of Failure Analysis FMEA Workshop

Workshop Objectives
1. Understand the fields and required inputs for an example
FMEA worksheet

2. Implement the FMEA process by utilizing a systems-level
FMEA worksheet

3. Divide into working groups (FMEA teams) and prepare
systems-level FMEAs on common topics

4. Present the results of the FMEA process


April 26, 2002 68

Example -- Systems-Level
FMEA Worksheet (3)

Failure Identification Failure Effects Severity Class* Operations and Protective Features Comments
R
e
c
o
r
d

N
o
.

S
u
b
s
y
s
t
e
m

o
r

I
t
e
m

F
u
n
c
t
i
o
n

F
a
i
l
u
r
e

M
o
d
e

C
a
u
s
e
s

L
o
c
a
l

E
f
f
e
c
t

N
e
x
t

H
i
g
h
e
r

E
f
f
e
c
t

E
n
d

E
f
f
e
c
t

C
h
e
m
i
c
a
l

o
r

E
x
p
l
o
s
i
v
e

I
n
d
u
s
t
r
i
a
l

S
a
f
e
t
y

S
y
s
t
e
m

D
a
m
a
g
e

O
p
e
r
a
t
i
o
n
a
l

P
h
a
s
e

D
e
t
e
c
t
i
o
n

P
r
e
v
e
n
t
i
o
n

M
i
t
i
g
a
t
i
o
n

I
n
t
e
r
f
a
c
e
s
;

C
o
m
m
e
n
t
s

* Range from Minor Impact (1) to Extremely Severe (5 or 6)


April 26, 2002 69

Input for Worksheet Columns (Part 1)
Record #: Tracking numbers for the FMEA data base system.
Subsystem: Utilized to specify the subsystem or subprocess within the scope of
each individual systems-level FMEA. A subsystem is a functional unit within
the parent system that has been separated out as a distinct operation that
can be analyzed as a separate entity.
Item: Utilized when the previous Subsystem column addresses a functional unit that
is so complex that it requires additional subdivision, or a unit that is difficult to
define as a discrete function so that related systems or processes are
included for convenience of analysis.
Function: The function of each subsystem or process is described briefly in a
manner that provides a distinct statement of the system or process being
evaluated. The description of function considers that the loss or degradation
of the identified function or functions as a result of the relevant failure mode
will be the subject of the subsequent analysis.


April 26, 2002 70

Failure Mode: The failure mode specifies the consequence of the mechanism
through which a failure occurs. A failure mechanism may include physical,
chemical, electrical, thermal, or other processes that result in failure. In
general, a failure mode describes an event or inoperable state in which any
system or subsystem does not, will not, or cannot perform as originally or
previously specified (normal operating state).
For the most part, the systems-level FMEAs consider only single-point
failures where the failure of an item would result in the failure of the system
and does not have redundancy or alternative operational procedures. Items
such as redundancy and procedures may be addressed in the columns for
Prevention and Mitigation. Each failure is considered to be an independent
occurrence, with no relation to other failures in the system except for the
subsequent effects produced by the failure under evaluation.


April 26, 2002 71

Causes: Presents the root causes directly related to the relevant failure mode. The
causes specify the physical or chemical processes, design defects, quality
defects, operational misapplication, or other processes that are the basic
reason for the failure or that indicate the physical process by which
deterioration leads to failure.
Phase: Refers to the operational mode of the subsystem or process under
evaluation (e.g., normal operations, maintenance, standby operations,
shutdown conditions, etc.). If the subsystem or item is subject to different
modes of operation, each operational mode is identified and analyzed
separately.
Detection Method: This column documents the means by which the failure mode is
detected. These detection methods may include equipment such as visual or
warning devices, automatic sensing devices, sensing instrumentation, or
other unique indicators. If no means of detecting a failure event are provided,
this should be indicated.


April 26, 2002 72


Local Effect: The consequence of a failure on the operation, functions, or status of
the specific item being analyzed for the failure. For some simple failures, the
local effect may be the only effect of the failure.
Next Higher Effect: Builds upon the information provided in the Local Effect column,
and provides further development of the failure scenario. Some failures may
have only a local affect and the next effect, which would represent a
combination next higher effect and end effect.
End Effect: The final effect of the failure within the confines of the boundaries
established for the FMEA system under scrutiny. The end effect should
postulate the ultimate results of the potential failure in terms of effects on
subsystems, processes, and environs of the system being analyzed.


April 26, 2002 73

Severity Level: Provides a subjective ranking of severity of worst consequence of
the failure mode being analyzed. Severity evaluation includes assessment of
the degree of injury, release of energy and/or hazardous materials, and
systems damage. Each category has interrelated levels of impact (in order of
increasing severity), such as: Minor Impact, Limited Impact, Moderate
Impact, Significant Impact, Serious Impact, and Extremely Serious Impact.
Detection: Devices and processes utilized to detect an aberrant condition,
undesirable trend, or a failed condition.
Prevention: Presents any features, devices, or other mechanisms that can prevent
the failure from happening.
Mitigation: Those features, devices, procedures, or other mechanisms that can
lessen the likelihood of an occurrence or lessen the severity of the impact of
an occurrence, but that cannot actually prevent the occurrence.


April 26, 2002 74

Interfaces/Comments: Utilized to establish and document the interfaces of the
subsystem under scrutiny to other systems and subsystems. Items that are
included are the systems, external to the system being analyzed, that provide
a common boundary or service and are necessary for the system to perform
its mission in an undegraded mode (e.g., power, cooling, control systems,
etc.). This is especially important where the results of a failure within the
system under analysis have effects on other systems in a chain-of-events
sequence. This column also is important for establishing operating interfaces
that may be of concern for process/materials flow and plant functionality.


April 26, 2002 75

Exercise - FMEA Worksheet

System Analyzed:
S
u
b
s
y
s
t
e
m

o
r

I
t
e
m

F
u
n
c
t
i
o
n

F
a
i
l
u
r
e

M
o
d
e

C
a
u
s
e
s

L
o
c
a
l

E
f
f
e
c
t

N
e
x
t

H
i
g
h
e
r

E
f
f
e
c
t

E
n
d

E
f
f
e
c
t

S
e
v
e
r
i
t
y

o
f

I
m
p
a
c
t
*

D
e
t
e
c
t
i
o
n

P
r
e
v
e
n
t
i
o
n

o
r

M
i
t
i
g
a
t
i
o
n

* Apply a scale of Minor Impact (1), Moderate Impact (2) and High Impact (3)


April 26, 2002 76

Exercise -- FMEA Worksheet Instruction (Part 1)
Systems Analyzed: Input the title of the topic your team is evaluating.
Subsystem or Item: If the topic (system) that you are analyzing is more easily
evaluated by breaking it down into smaller pieces, list these pieces (no more
than three for this exercise) in the rows of this column. If not, the first row will
be the same as the System Analyzed.
Function: Describe (in very general terms) the function of each subsystem or item
that is being analyzed in a manner that promotes the explanation of the
failure mode in the subsequent analysis.
Failure Mode: State the failure mode of the subsystem, describing the type of failure
that may occur and/or the inoperable state in which any system or subsystem
does not, will not, or cannot perform as it is supposed to function.


April 26, 2002 77

Exercise -- FMEA Worksheet Instructions (Part 2)
Causes: Provide a brief statement of the root cause of the failure in terms of the
initiating event and other contributing processes that are the basic reason for
the failure.
Local Effect: State the consequence of the failure on the operation, functions, or
status of the specific item being analyzed for the failure.
Next Higher Effect: State the effect of the failure on the next larger function or
system in which the Local Effect is imbedded. .
End Effect: State the final effect of the failure within the confines of the boundaries
established for the FMEA system under scrutiny, such as the total system or
process affected by the final expression of the selected failure.


April 26, 2002 78

Exercise -- FMEA Worksheet Instructions (Part 3)

Severity of Impact: Provide a subjective ranking of severity of worst consequence of
the failure being analyzed (e.g., injury, damage, etc) using a scale of (1)
Minor Impact, (2) Moderate Impact, and (3) High Impact.
Detection: List any devices or processes that could be used to (1) detect the
upcoming failure before it occurs, (2) recognize a failing condition or
undesirable trend, (3) report the failed condition after failure.
Prevention or Mitigation: List any features, devices, or other mechanisms that
could be used to prevent the failure from happening, or those features,
devices, procedures, or other mechanisms that can lessen the impact of the
failure after occurrence.

Basics of Failure Analysis

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Basics of Failure Analysis

Enviado por

Direitos autorais:

Formatos disponíveis

H Hu un nt ts sv vi il ll le e R Re eg gi io on na al l

Você também pode gostar