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

[email protected]

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

Reco

rd N

o.

Su

bsyste

m

or

Item

Fu

ncti

on

Fail

ure

M

od

e

Cau

ses

Lo

cal

Eff

ect

Next

Hig

her

Eff

ect

En

d E

ffect

Ch

em

ical

or

Exp

losiv

e

Ind

ustr

ial

Safe

ty

Syste

m

Dam

ag

e

Op

era

tio

nal

Ph

ase

Dete

cti

on

Pre

ven

tio

n

Mit

igati

on

Inte

rfaces;

C

om

men

ts

* 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:

Su

bs

yste

m

or

Item

Fu

nc

tio

n

Fa

ilu

re

Mo

de

Cau

ses

Lo

cal

Eff

ect

Next

Hig

he

r E

ffect

En

d E

ffect

Severi

ty o

f Im

pa

ct*

Dete

cti

on

Pre

ven

tio

n

or

Mit

iga

tio

n

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

Documents

Basics of Failure Analysis