Basics of Failure Analysis

HHuunnttssvviillllee RReeggiioonnaall
CChhaapptteerr
April 26, 2002 1
INTERNATIONAL COUNCIL ON SYSTEMS ENGINEERING
Huntsville Regional Chapter
Terry A. Kuykendall, Instructor
Radisson Hotel
8720 Madison Blvd.
Madison, AL

CChhaapptteerr
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
26th, 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

CChhaapptteerr
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

CChhaapptteerr
April 26, 2002 4
Role of Failure Analysis
in Design and Engineering

CChhaapptteerr
April 26, 2002 5
Basics of Failure Analysis – Role of Failure Analysis in Design and Engineering
Kuykendall’s Fundamental Failure
Theorem #1:
“Failure is the basis for all scientific and
engineering achievement.”

CChhaapptteerr
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.”

CChhaapptteerr
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.”

CChhaapptteerr
April 26, 2002 8
Prehistoric Failure Analysis

CChhaapptteerr
April 26, 2002 9
Excerpt from the Code of Hammurabi*:
If 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.
If it cause the death of the son of the owner of the house, they shall put to death a son of
that builder.
If 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.
If 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.
If 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

CChhaapptteerr
April 26, 2002 10
The Pyramid of Dashur (the Bent Pyramid)

CChhaapptteerr
April 26, 2002 11
Tacoma Narrows Bridge

CChhaapptteerr
April 26, 2002 12
Three-Mile Island

CChhaapptteerr
April 26, 2002 13
Challenger Accident

CChhaapptteerr
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.”

CChhaapptteerr
April 26, 2002 15
Failure Analysis
Concepts and Techniques

CChhaapptteerr
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.

CChhaapptteerr
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.

CChhaapptteerr
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

CChhaapptteerr
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

CChhaapptteerr
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

CChhaapptteerr
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

CChhaapptteerr
April 26, 2002 22
Example -- Simple Fault Tree

CChhaapptteerr
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

CChhaapptteerr
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

CChhaapptteerr
April 26, 2002 25
Example – FMEA Worksheet (1)

CChhaapptteerr
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

CChhaapptteerr
April 26, 2002 27
Example -- Criticality Analysis Worksheet

CChhaapptteerr
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

CChhaapptteerr
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

CChhaapptteerr
April 26, 2002 30
Patterns Used in Sneak Circuit Analysis

CChhaapptteerr
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

CChhaapptteerr
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

CChhaapptteerr
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.

CChhaapptteerr
April 26, 2002 34
Relationship of Failure
Analysis to Other Studies
and Evaluations

CChhaapptteerr
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

CChhaapptteerr
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

CChhaapptteerr
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

CChhaapptteerr
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

CChhaapptteerr
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

CChhaapptteerr
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

CChhaapptteerr
April 26, 2002 41
Failure Classification
and Categorization

CChhaapptteerr
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)

CChhaapptteerr
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

CChhaapptteerr
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”

CChhaapptteerr
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

CChhaapptteerr
April 26, 2002 46
The Failure Modes and
Effects Analysis (FMEA)
Process

CChhaapptteerr
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

CChhaapptteerr
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.

CChhaapptteerr
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

CChhaapptteerr
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

CChhaapptteerr
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)

CChhaapptteerr
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

CChhaapptteerr
April 26, 2002 53
Process
Example -- FMEA Worksheet (2)

CChhaapptteerr
April 26, 2002 54
Process
Two Functional Categories of FMEAs
1. Components-Level FMEAs
2. Systems-Level FMEAs

CChhaapptteerr
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

CChhaapptteerr
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

CChhaapptteerr
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

CChhaapptteerr
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

CChhaapptteerr
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)

CChhaapptteerr
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

CChhaapptteerr
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

CChhaapptteerr
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

CChhaapptteerr
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.

CChhaapptteerr
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.

CChhaapptteerr
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

CChhaapptteerr
April 26, 2002 66
FMEA Workshop

CChhaapptteerr
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

CChhaapptteerr
April 26, 2002 68
Example -- Systems-Level
FMEA Worksheet (3)
Failure Identification Failure Effects Severity Class* Operations and Protective Features Comments
RecordNo.
Subsystem
orItem
Function
Failure
Mode
Causes
LocalEffect
NextHigher
Effect
EndEffect
Chemicalor
Explosive
Industrial
Safety
System
Damage
Operational
Phase
Detection
Prevention
Mitigation
Interfaces;
Comments
* Range from Minor Impact (1) to Extremely Severe (5 or 6)

CChhaapptteerr
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.

CChhaapptteerr
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.

CChhaapptteerr
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.

CChhaapptteerr
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.

CChhaapptteerr
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.

CChhaapptteerr
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.

CChhaapptteerr
April 26, 2002 75
Exercise - FMEA Worksheet
System Analyzed:
Subsystem
orItem
Function
Failure
Mode
Causes
LocalEffect
NextHigher
Effect
EndEffect
Severityof
Impact*
Detection
Prevention
orMitigation
* Apply a scale of Minor Impact (1), Moderate Impact (2) and High Impact (3)

CChhaapptteerr
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.

CChhaapptteerr
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.

CChhaapptteerr
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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Basics of Failure Analysis

Similar to Basics of Failure Analysis (20)

Recently uploaded

Recently uploaded (20)

Basics of Failure Analysis