Proceedings of the

1999 ASME Design Engineering Technical Conferences

September 12 - 15, 1999, Las Vegas, Nevada

DETC99/DFM-8939

ADVANCED FAILURE MODES AND EFFECTS ANALYSIS OF COMPLEX

PROCESSES

Steven Kmenta
Peder Fitch
Kosuke Ishii
Design Division
Mechanical Engineering Dept.
Stanford University
Stanford, CA 94305-4022

ABSTRACT
This paper presents the use of Advanced Failure Modes design, or process before the problems are actualized
and Effects Analysis (AFMEA) as a methodology to analyze (Omdahl, 1988). What is a failure mode? The literature
manufacturing process reliability. The proposed method offers many definitions of a “failure mode.” According to the
applies to early process design and seeks to improve product Automotive Industry Action Group (AIAG), a failure mode is
quality, process efficiency, and time to market. The method “the way in which a product or process could fail to perform
uses behavior modeling to relate process functions, its desired function” (AIAG, 1995). Some sources define
performance state variables, and physical entities. The model “failure mode” as a description of an undesired cause-effect
can be used to define process failures explicitly and provides a chain of events (MIL-STD-1629A, 1994). Others define
framework for assessing causes and effects. An example of a “failure mode” as a link in the cause-effect chain (Stamatis,
precision turning operation illustrates how AFMEA applies to 1995: Humphries, 1994). To avoid confusion, we introduce
the analysis of manufacturing processes. A pilot analysis of an the term failure scenario to describe an undesired sequence of
ultrasonic inspection process revealed that AFMEA is causes and effects.
comprehensive and adaptable to other processes. Ongoing Once development teams identify and prioritize failure
work for AFMEA is developing deployment strategies for scenarios, they can make design decisions leading to
minimal time burden and links to embedded error proofing. improved reliability, quality, and safety. Table 1 describes the
KEYWORDS: behavior modeling, process FMEA, reliability three main phases of FMEA.
Table 1. Three phases of FMEA
1. INTRODUCTION
Process reliability assessment is becoming an integral part Phase Question Output
of product development and is often based on statistical models
(DeVor et al., 1992). However, traditional process reliability Identify What can go wrong? Failures: causes & effects
methods require information that is usually not available until Analyze How likely is a failure Risk Priority Evaluation
late in the development process. At the detailed design stage, and what are the (likelihood × severity)
the majority of cost and reliability have already been consequences?
“designed-in” to the manufacturing process. Development
Act What can be done to Design solutions, test plans,
teams need to address product and process reliability up-front.
eliminate the cause or manufacturing changes,
Failure Modes and Effects Analysis (FMEA) is a tool for alleviate the severity? error proofing, etc.
analyzing both product and process reliability, potentially, at
an early-stage (Bowles, 1998). Identifying failures is a critical aspect of FMEA. It is
impossible to evaluate and alleviate a potential failure that is
1.1 Failure Modes and Effects Analysis not anticipated. This paper introduces a novel and systematic
FMEA is an engineering technique used to identify,
prioritize and alleviate potential problems from the system,

1 Copyright © 1999 by ASME

method to identify what can go wrong in complex
manufacturing processes. Ideal Actual
System, Design, Process, Service... Design Process

1.2 Process FMEA

functional layout detailed
Process FMEA is similar to other types of FMEA: the manufacturing
design design design
goal is to identify what problems may occur within a
manufacturing process. Process failures fall into two Figure 1. Ideal vs. actual deployment of FMEA
categories: internal and external failures. Internal failures are Identifying potential failures is a critical step in assessing
detected within the process (e.g., scrap, rework, delays, reliability, and the literature does not prescribe systematic
equipment damage, false inspection rejections, safety procedures for identifying failures. Our industry
concerns). External failures are not detected within process collaborators have not had success using FMEA to identify
boundaries (e.g., process failures resulting in warranty cost, many in-service and in-process failure modes. It is difficult to
unscheduled maintenance). External failures are much more anticipate many problems associated with:
costly than internal failures (DeVor et al., 1992). Figure 2 • interfaces with other processes, systems, and suppliers;
illustrates internal and external failures. • interaction with controls;
process steps
• unexpected operating conditions;
inputs good
• errors between process operations;
signals
materials
step 1 step 2 step 3 product • unanticipated operator or user actions;
energy rework
internal
scrap
bad
• omitted operations that are difficult to detect.
internal
failure failure product Ideally, Process FMEA should be a systematic process
external
failure analysis tool that is repeatable (consistent), adaptable to any
process, and identifies a more comprehensive set of problems.
Figure 2. Basic process failures Section 2 gives an overview of an enhanced version of FMEA
called Advanced FMEA (AFMEA). Section 3 proposes a
1.3 Shortcomings of FMEA procedure for performing AFMEA on a manufacturing
Three problems with traditional FMEA, in order of process using a simple example. Section 4 applies AFMEA
importance, are: to a high-precision turning process. Section 5 discusses the
1) FMEA is performed to late and not used to influence relative advantages and drawbacks of structured process
design decisions. analysis compared to brainstorming. Section 6 outlines
2) FMEA does not capture many potential failures. limitations and potential extensions of this work.
3) The process for performing FMEA is subjective and
tedious. 2.0 ADVANCED FMEA
Examples of documented shortcomings of FMEA are: Reliability assessment is usually an in-depth engineering
analysis performed during detailed design. In-depth analyses
• FMEA is applied too late and in such detail that it misses
are important, yet prone to miss many system-wide failures.
key system-wide, in-service failure modes (Bednarz and
Reliability assessment could benefit from simple, system-wide
Marriott, 1988).
tools performed at an early stage.
• Performing FMEA late does not affect important design
Advanced FMEA, first proposed by Eubanks et al.
and process decisions (McKinney, 1991).
(1996), addresses some of the deficiencies associated with
• The analysis is often an afterthought, performed as a “box-
traditional FMEA. AFMEA uses behavior modeling to
checking” exercise (Kara-Zaitri et al., 1991).
simulate device operations and to help reason about causes
• Without a systematic approach, engineers produce a and effects. The goal of AFMEA is to provide a systematic
subjective analysis that depends on their experience level method of capturing a larger set of failure modes early in the
(Bell et al., 1992). design.
• FMEA is tedious and time-consuming (Ormsby et al.,
1991). 2.1 Behavior Modeling for Advanced FMEA
FMEA has the most leverage when applied at the early stages Two accepted approaches to FMEA are based on 1)
of product development since product and process cost and components, and 2) functions (AIAG, 1995: ARP926A, 1979)
reliability are already fixed after the concept and layout The two approaches are complementary but not mutually
design stages. Figure 1 compares the early and continuous exclusive. Hawkins and Woollens (1998) suggest that the
application of FMEA to what often happens: performing functional approach is suitable for early stages of design.
the FMEA late or not at all. Since functions can be abstracted prior to selection of specific
components, development teams can analyze products in this

2 Copyright © 1999 by ASME

manner before the majority of cost and reliability are locked We have show AFMEA to be useful in a wide variety of
into the design (Sturges et al, 1996). In order to leverage applications. Behavior modeling uses a simple framework for
reliability analysis at an early-stage, AFMEA uses a behavior representing systems at a high level and it is decomposable to
model that defines relationships between: model details of a system. The flexibility of the behavior
• functions; model lends itself to manufacturing processes as well.
• states: pre-conditions (“what is required”) and post- Process behavior models are analogous to other models
conditions (“what is expected”) of each function; (Figure 4).
• elements: physical entities that enable functions to pre-conditions desired behavior
achieve the desired post-conditions. product function
Such a behavior model represents a system as a causal
sequence of functions and states (Keuneke, 1991). Once the
model is built, we can insert failures in the form of undesired sub-function sub-function sub-function

state variables, propagate the effects, and assess causes. Figure

sub-function
3 shows a flowchart for Advanced FMEA.
Building the Behavior Model Analyzing the Model
raw materials desired geometry
define system sequence the behaviors
processfunction
insert failure state
list system inputs/outputs

propagate effects assess causes sub-step sub-step sub-step

decompose into sub-functions

compile cause-effect scenarios sub-step

list inputs/outputs of sub-functions

rank likelihood rank severity

define map sub-functions to Figure 4. Comparison of product and process models
dependencies elements
calculate risk priority number
Behavior modeling can be an effective tool for simulating
refine model?
propose solutions complex manufacturing processes. We have used behavior
Figure 3. Flowchart for Advanced FMEA modeling to partially analyze several complex processes, such
as: ultrasonic inspection of titanium disks, rabbet joint
2.2 Applying Advanced FMEA to Complex Processes turning, and turbine disk assembly. Using behavior modeling
Our group has applied AFMEA to both detailed and for manufacturing processes offers several advantages:
conceptual designs, and the concurrent design of controls and • a more systematic method for identifying process
hardware (Table 2). failures;
• applicability to preliminary process designs, as well as
Table 2. Previous research applications of AFMEA for mature processes;
Applications of AFMEA Case Studies Primary Lesson • the ability to incorporate system level variables in a
process model, as well as interfaces to other
ICE MAKER AFMEA is more
Operating
Conditions
System Interfaces
System
comprehensive than
processes;
• the ability to link potential process failures to process
Installation
Process,
Service Assembly
Process Retroactive case traditional FMEA
study on an
(Eubanks et al., 1996
and customer requirements.
Components
existing design The next section proposes a procedure for identifying
Eubanks et al., 1997)
Process
(Supply Chain)

Boiler
process failures using behavior modeling.
POWER PLANT AFMEA is useful for
GT Exhaust
IP Steam

Cold Reheat HARDWARE early system 3.0 ADVANCED FMEA APPLIED TO PROCESSES
Steam
GT Cooling
HP Hot Reheat configuration
Steam
Steam Steam
LP Steam
decisions This section outlines the general procedure for building a
Comb
Conceptual layout
Generator design process model and then performing AFMEA. We will use a
T C HP IP / LP

Gas Turbine Steam Turbine

(Eubanks, 1997) simple example of attaching a cap to a tube of toothpaste
Air

If flow in pipe 1 using automated equipment.

PLANT CONTROLS AFMEA is effective for
behavior model A meta-
> min_flow
behavior
Air Cooling

& HARDWARE concurrent design of

Exhaust
to Stack
IP SteamLP Steam Exhaust
to Stack open
3.1 Building the Model
Cold Reheat IP Steam
Steam LP Steam

controls and hardware

HP Hot Reheat
Steam Steam
Cold Reheat
Steam
Exhaust valve B
Comb to Stack
IP SteamLP Steam
T C HP IP / LP Generator
Cold Reheat
Exhaust

systems The procedure for building the behavior model for a

Gas Turbine Steam Turbine Steam
Air HP Hot Reheat to Stack

Concurrent design
Steam Steam
Comb
IP SteamLP Steam
Cold Reheat
valve B open
Exhaust
T C HP IPHP Steam
/ LP Hot Reheat
Generator
to Stack
Gas Turbine Steam TurbineSteam Steam IP SteamLP Steam

of controls and manufacturing process parallels the procedure for system

Air Comb
Cold Reheat
T C Intermediate Steam
HP IP / LP Steam
Generator
Gas Turbine Steam Turbine
Cooling Exhaust

(Kmenta and Ishii,

Air
to Stack

hardware
IP SteamLP Steam
C

models outlined by Eubanks (1996).

Cold Reheat
Steam
on

HP Hot Reheat
Steam Steam

1998)
tro

Comb
lA

T C HP IP / LP Generator
Gas Turbine Steam Turbine
lg

Air
or
ith

behavior model B
m

3 Copyright © 1999 by ASME

Step 1 Define the boundary seal tube
When building a behavior model, one must scope the analysis import tube attach cap
by defining a boundary to the process. In the case of a
get cap sense tube
manufacturing process, the system boundary might be a plant,
sense cap translate cap
a manufacturing line, a manufacturing cell, etc. Once the
pick cap rotate cap
boundary is defined, we can begin to think about the inputs to
the system, what physical entities are contained within the
boundaries, and what are the desired outputs. Figure 5. The overall process
Example: Automated cap attachment station, the equipment We establish a hierarchy of behaviors by adding pre- and
associated with this area. post-conditions to all of the functions (Figure 6). More
detailed information could be incorporated, such as
Step 2 State the process function specification of the cap threads, the rotation torque, etc.
State the overall purpose of the process in a verb + noun
format. Seal Tube
pre-conditions post-conditions

c) <tube><present><0> Import Tube d) <tube><present><1>

Example: “seal tube”
Get Cap
e) <cap><present<1>
Step 3 List the desired output g) <cap><orientation><nom> Sense
Cap h) <signal><cap><present>
List the resulting desired state, or post-conditions, of the e) <cap><present<1>
process in <variable><attribute><value> (Eubanks, 1996) format. g) <cap><orientation><nom>
h) <signal><cap><present>
Pick f) <cap><fixtured><1>
Cap
These can include process requirements. We indicate i) <vacuum><pressure><nom>

true/false values using [1, 0] and list nominal conditions as Attach Cap
“nom.” a) <tube><sealed><0> Sense
d) <tube><present><1> j)<signal><tube><present>
Tube
Example: <tube> <sealed> < 1 > f) <cap><fixtured><1>
k) <fixture><position><retracted> Translate m) <fixture>
j) <signal><tube><present> Cap <position><extended>
Step 4 List the inputs as system pre-conditions l) <supply_air><pressure><nom>
a) <tube><sealed><0>
List the required external inputs, or pre-conditions to the d) <tube><present><1>
Rotate
Cap
b) <tube><sealed><1>
system including signals, materials, and energy that are m) <fixture><position><extended>

entering the process boundary. Inputs can usually be b) <tube><sealed><1>

categorized in the following areas:

Figure 6: Pre-conditions and post-conditions included
Energy: power, force, friction in model
Information: data, bar codes, paperwork
Material: fluid flow, components Step 6 Assign influences
Use arrows to assign dependencies between states and
Example: <tube> <present> <1>, functions
<cap> <present> <1>,
<supply air> <pressure> <60psia>, Example: (Figure 9).
<vacuum line> <pressure> <nom>
Get Cap
e, g
Sense Cap i
h Pick Cap
Step 5 Decompose the process
Decompose the process into sub-functions (corresponding to
sub-steps) and list the desired outputs and required inputs. c Import Tube d
f

Example: Figure 5 shows the overall function “seal tube” a

Sense Tube
decomposed into sub-functions, e.g., “import tube,” “get cap,” and Rotate Cap b
“attach cap.” We can decompose sub-functions further into sub- j
sub-functions; for example, “get-cap” contains sub-sub-functions m
k Translate Cap
“sense cap,” and “pick cap.” This is the manner in which functions l Attach Cap
are decomposed into a functional hierarchy. For the rest of this
paper, the term “function” will also refer to sub-functions, sub- Figure 7. Influence diagram based on a behavior
sub-functions, etc. model

4 Copyright © 1999 by ASME

Step 7 Map elements to functions Table 4. The re-ordered sequence using DM
Elements are the physical entities and agents responsible for decomposition
performing functions and achieving post-conditions. Map a c d e g h i f j k l m b
each function to one or more element(s). a •
c •
d • •
Example: We map the function “pick cap” to these elements: e •
g •
{ fixture, vacuum line, controller } h • • •
i •
f • • • •
3.2 Performing the Analysis j • • •
k •
This section lists the steps for applying Advanced FMEA l •
to a process model. The steps continue from the previous m • • • • •
b • • • • •
section and propose a method for analyzing a model for failure
modes and effects, and reasoning about their causes. We will
The re-ordered sequence does not violate precedence
continue to use the attachment of the cap to the toothpaste tube
conditions and improves the efficiency of analysis. The
as an example.
analyst might be able to generate this sequence by inspection.
However, DM Decomposition helps select an appropriate
Step 8 Sequence the behaviors for analysis analysis sequence for models with many nodes and feedback
Many behavior models, particularly models of manufacturing
loops.
processes, have functions and states that only influence
downstream functions and states, with very little feedback. It
Step 9 Insert failures
is desirable to simulate failure conditions straight from the
For a given behavior (pre-conditions + function + post-
beginning of the model to the end. However, not all models
conditions) we define failure as any deviation from the
are linear and free from feedback loops.
desired post-condition. We can generically represent a failure
For complicated models we recommend optimizing the
as the negation of the a desired post-conditions:
order used to analyze the model in such a way that precedence
is maintained as much as possible. When analyzing a not(<variable><value><nom>)
behavior, we would like to have already analyzed failures of An undesired state is any deviation from the intended
preceding behaviors. Maintaining precedence helps us to state. For example, for the function “provide flow” with the
identify causes before effects. Dulmage Mendelsohn (DM) post-condition <water><flowrate><5-6 lpm>, anything other than
Decomposition is a graph theoretic ordering technique that the nominal range is considered a failure. Our classification
computes the block triangular form of sparse asymmetric of variable values is as follows:
matrices. DM Decomposition is a means of maintaining
precedence and minimizing feedback loops in a directed graph. nom nominal condition
This approach is a systematic answer the question "where do I 1 True
begin the analysis?" given a behavior model. 0 False
+ too-high
Example: From the influence diagram, shown in Figure 7, we - too-low
establish the dependency matrix for state variables a to m, ∅ none or absence
shown in Table 3. We initially choose the sequence: a, b, c, d,
e, f, g, h, i, j, k, l, m. Using this convention, not(<value>) could include any of the set
of {< + >, < - >, < ∅ >, <other-value>}. The use of the general
Table 3. Dependency matrix for the analysis sequence failure states too-high and too-low are useful in many
a b c d e f g h i j k l m practical examples, giving a good compromise between
a •
b • • • • • simplicity and completeness of analysis (Chittaro, et al.,
c • 1998).
d • •
e •
f • • • •
Example: For the failure “cap is not fixtured”
g •
h • • • not(<cap><fixtured><1>) (equivalent to <cap><fixtured><0>)
i •
j • • •
k • Step 10 Propagate effects
l •
m • • • • •
Given an undesired post-condition, what other behaviors will
be affected? Post-condition failures can become pre-condition
Marks above the diagonal (such as states b and f) represent
violations for subsequent behaviors.
violations of precedence. Table 4 shows the ordering using DM
Decomposition. Example: For the failure: not(<cap> <fixtured> <1>)

5 Copyright © 1999 by ASME

The function-state behaviors would be affected as follows: • specific physical causes for an improper behavior can be
not(<cap> <fixtured> <1>)
incorporated later as pre-conditions, for example
<fixture><alignment><nom>.
→ not(translate cap)
→ not(<fixture><position><extended>)
Step 12 Compile failure scenarios
→ not(rotate cap)
Failure scenarios are the links of an undesired cause-effect
→ not (<tube><sealed><1>) − the tube is not sealed.
chain, and include a list of element failures, state failures, and
Step 11 Assess causes function failures. Several failure scenarios can be associated
The causes of the failures can be reduced to two categories: with each function.
1) Element failures: failure of elements mapped to a Example: For the failed function not(pick cap), all failures can
function. be traced to elements and result in an unsealed tube. Eight
2) Pre-condition failures: failures of other behaviors within failure scenarios associated with not(pick cap):
the system (internal) or of inputs to the system (external). (1) not(hopper)
Pre-condition failures are generally linked to element → not(<cap><present><1>) [state “e”]
failures elsewhere in the model.
The compiled list of element and pre-condition failures (2) not (hopper)
comprises a set of potential causes for a failure scenario. → not(<cap><orientation><nom>) [state “g”]

Example: For the failure <cap><fixtured><0> we can reason (3) not(sensor)

about potential causes. Figure 8 shows the behavior-structure → not(sense cap)
fragment for the function “pick cap.” → not(<signal> <cap> <present>) [state “h”]

<vacuum><pressure><nom> Pick Cap <cap> (4) not(controller)

<fixtured>
<1>
→ not(sense cap)
<cap><present><1>
elements : → not(<signal> <cap> <present>) [state “h”]
<cap><orientation><nom> fixture
vacuum line (5) not(vacuum pump)
<signal><cap><present> controller → not(<vacuum><pressure><nom>) [state “i”]

Figure 8. Behavior fragment for analyzing causes (6) not(fixture)

Generic element failures would include the set: (7) not(controller)

{ not(fixture), not(controller), not(vacuum line) }
(8) not(vacuum line)
Pre-condition failures include the set:
All scenarios result in these effects:
{ not(<cap><present><1>), not(<signal><cap><present>),
not(<vacuum><pressure><nom>), not(<cap><orientation><nom>) } → not(pick cap)
→ not(<cap><fixtured><1>) [state “f”]
Pre-condition failures can be linked to element failure: → not(translate cap)
{ not(hopper), not(sensor), not(vacuum pump), not(controller) } → not(<fixture><position><extended>) [state “m”]
→ not(rotate cap)
There may be many specific causes for a generic element → not(<tube><sealed><1>) [state “b”]
failure “not(element)” and the exact nature of the failure may
vary. Specific causes can be included explicitly into the Failure scenarios can be represented in a diagram (Figure 9).
analysis. When detailed causes of failure are not known, we (1) not(hopper) (2) not(hopper) (5) not(vacuum pump) (6) not(fixture) (7) not(controller)
recommend including generic element failures for several
not(e) not(g) not(i)
reasons:
• they act as placeholders for more specific information; not(sense cap) not(h) not(pick cap) (8) not(vacuum line)
• they account for the relationship between physical
elements and behaviors; not(h) not(f) not(translate cap) not(m)

• generic failure modes are amenable to the early (3) not(sensor) (4) not(controller) not((b)<tube><sealed><1>) not(rotate cap)
application of FMEA;
• we can reason about impact on the system performance Figure 9: Failure scenarios associated with “pick cap”
even without specific information about causes of failure;

6 Copyright © 1999 by ASME

4.0 AFMEA EXAMPLE: TURNING APPLICATION 1.2 1.3 3.2 3.1 6.2 6.1
This section gives a demonstration of Advanced FMEA
applied to a turning application with tight tolerance 1.1 1.4 3.3 6.4 6.3 5.2 5.1
requirements on large-diameter parts.
2.1 7.2 7.1 5.3 4.3 4.2 4.1
4.1 Behavior Model of Process
Following steps 1-7 from Section 3, we developed a model
2.2 8.1 5.4 4.4
for the turning process shown partially in Figure 10.
1) Setup Controls 4) Setup Fixture
9.3 9.2 9.1
1) clear program 1-mount fixture
2) scan identification 2-align fixture
3) scan paperwork 3-measure y-runout 14.1 10.1 10.2 10.3 11.1
4) enter operation 4-measure z-runout

<operation> paperwork fixture

NC table <fixture> 15.1 13.1 12.3 12.2 12.1
<loaded> keypad
<1> operator tools <runout>
keypad entry indicator <nom>
operator Figure 11. Functions with state dependencies
2) Select Toolpath
5) Load Part
1) call up programs
1-load part
4.2 Performing the Analysis
2) select program
2-align part We applied DM Decomposition to the numerical
3-measure y-runout
paperwork 4-measure z-runout sequence of behaviors and the ordering did not change. Next,
keypad <part>
operator <runout>
we inserted a failure state, simulated the effects, and traced
part
fixture
<nom> back to find a set of potential causes.
3) Setup Turret <part>
operator
<loaded>
1) mount block <1> Insert failure: Fixture y-runout is too high
2) mount holder 6) Measure Part

<program>
3) mount insert 1-zero gage <fixture><y-runout>< + >
2-measure part
<loaded>
<1> tool block 3-read dimension → <part> <y-runout> < + >
<insert> tool holder 4-accept part
<mounted> insert <gage> resulting in either
<dimension>
(1) → <tool> <y-axis> < - > or,
<1> operator gage
<value>
master
7) Reset Axes part (2) → <tool> <y-axis> < + >
operator
1-set y-axis
2-set z-axis
9) Measure Part Propagate effects: case (1) the tool y-axis offset is too small
<tool>
<axes> shim
<part>
1-zero gage
2-measure part
→ <tool> <y-axis> < - >
→ <part> <diameter> < - >
<nom> operator
<diameter> 3-read gage

→ <gage> <dimension> < - >

8) Cut Part <value>
gage
master
<gage>
<dimension>
→ <part> <dimension> < - >
tool
program
part
operator
<value> → “scrap part”
part

11) Cut Part <offset> 10) Enter Offset Assess causes: potential causes of this failure mode include:
<dimension> 1-compare value
<value> 2-calculate delta { not(fixture), not(NC table), not(tools), not(operator), not(indicator) }
tool 3-update offset
<part>
program Compile failure scenarios: (Figure 12)
<diameter>
part operator
<value>
keypad <part>
12) Measure Part
<dimension> causes effects
<+>
1-zero gage
<gage>
<dimension>
(1) not(fixture) <fixture><y-runout>< + >
13)
(2) not(NC table)
2-measure part
3-read gage
<value> Decide <part> Accept → <part> <y-runout> < + >
<dimension> (3) not(tools)
<nom.>
Part
(4) not(operator) → <tool> <y-axis> < - >
gage
master operator <part> (5) not(indicator) → <part> <diameter> < - >
→ <gage> <dimension> < - >
part <dimension> Scrap
operator <-> Part
→ <part> <dimension> < - >
Figure 10. Partial behavior model of a turning process → “scrap part”
Once we added states and dependencies to all the sub- Figure 12. Failure scenarios associated with <y-
functions we discovered some other dependencies not shown in runout>
the initial process map. Figure 11 shows how <part><y-runout>
(step 5.3) is affected by <fixture><y-runout> (step 4.3).

7 Copyright © 1999 by ASME

5.0 DISCUSSION: FREE FORMAT VS. STRUCTURED Structured AFMEA is transferable to other processes and
FMEA does not rely on a process-specific expert. In addition, the
This section discusses some of the benefits and limitations structured approach identifies a large number of potential
of structured process analysis compared to free-format problems, and could be useful for situations where a specific
brainstorming. When initially evaluating “process AFMEA,” problem or error is unknown. However, the structured
we took part in a workshop analyzing an ultrasonic inspection analysis may limit the team’s thinking to items closely related
process for titanium disks. The workshop used two different the process model. The structured approach also may seem
approaches fir identifying potential failures: too dry or tedious compared to brainstorming. Table 6 lists
1) free format brainstorming session the advantages and disadvantages of AFMEA as perceived by
2) a version of structured AFMEA the participants.
The objectives were to predict error sources for this specific
Table 6: Collected responses to the structured FMEA
process and to develop a technique for analyzing other
Approach
processes. Table 5 compares the results of the two approaches.
Advantages Disadvantages
Table 5. Comparison of brainstorming and a structured Clear structure Broad scope limits depth
AFMEA analysis Logical approach Less "off-the-wall- thinking"
Completeness
BRAINSTORMING STRUCTURED AFMEA
The next steps are to reconcile the structured approach of
Question asked How could a defect What problems might
escape? occur?
AFMEA with information gathered from less formal
Technique Asked probing analyzed the process by workshops and brainstorming efforts. For example, an
questions related to sub-steps, using a cause- individual or small team could begin the AFMEA without
process steps effect diagram intimate knowledge of the process. Then, the team could
Facilitator knowledge
of process high low augment the analysis with information from focused meetings
Adherence to process with process experts and test results. AFMEA could provide
flowchart moderate high a structured framework to be populated with detailed
No. of problems information from many sources.
identified 32 119
No. of external failures
(defects escaping) 32 25 6.0 CONCLUSIONS AND FUTURE WORK
No. of internal failures This paper demonstrated a new use of behavior modeling
(scrap, rework, delays) 0 96
for Advanced FMEA of manufacturing processes. The model
No. of overlapping
failures 19 19 related process functions and states using causal
dependencies. The paper described a method for analyzing
The brainstorming group went into more detail regarding processes and demonstrated its application on a high-
scenarios for escaping defects, but neglected internal process precision turning example. A pilot study compared some of
problems (e.g. false rejections). The structured FMEA group the benefits of a structured approach, such as a broad scope
covered more ground regarding general process problems, but and portability, to some of its shortcomings, such as its lack of
neglected the specifics of some failures (e.g. mechanical depth.
problems). Figure 13 compares the failures identified by the Advanced FMEA can help facilitate concurrent
two approaches qualitatively in terms of expected risk. engineering efforts throughout both product and process
development. Moreover, the method lends itself to
automation as a product development tool and to act as a
= ( Likelihood x Severity )

single repository for failure identification throughout product

development. In the future, application of AFMEA could
Risk Priority

errors resulting in a include broader areas such as supply chain management, the
defect escaping
product development process, and other business processes.
other errors (re-work,
false rejections, etc.) Extension and validation of AFMEA as a design methodology
will include:
• integrating AFMEA with information from other
methodologies (QFD, DFA, etc.);
• linking AFMEA with human error proofing;
Brainstorming Structured • automating the procedure using software;
Analysis
• developing improved methods for using AFMEA with
Figure 13. Comparison of relative failure risk minimal time and resources;

8 Copyright © 1999 by ASME

 • documenting additional case examples; Kmenta, S., and K. Ishii, 1998, “Advanced FMEA Using
• applying the behavior model to supply chain logistics Meta Behavior Modeling for Concurrent Design of
and product development processes. Products and Controls,” Proceedings of the 1998 ASME
Design Engineering Technical Conference, Atlanta, GA.
ACKNOWLEDGEMENTS Keuneke, A., 1991, “Device Representation: The Significance
The authors would like to thank General Electric and the of Functional Knowledge,” IEEE Expert, 6(2), pp. 22-25.
Department of Energy for providing support for this research. McKinney, B., 1991, "FMECA, The Right Way,"
The authors express sincere appreciation to Gene Wiggs, Jeff Proceedings of the 1991 IEEE Annual Reliability and
Keller, and Richard Menzies for facilitating the application of Maintainability Symposium, pp. 253-259.
Advanced FMEA and providing valuable feedback. Thanks to Omdahl, T.P. (ed.), 1988, Reliability, Availability, and
Toshiki Mori, Mark Martin and Catherine Rose for their Maintainability Dictionary, ASQC Quality Press,
valuable ideas and assistance. Milwaukee, WI.
Ormsby, A., J. Hunt, M. Lee, 1991, “Towards an Automated
REFERENCES FMEA Assistant,” Artificial Intelligence in Engineering,
Aerospace Recommended Practice ARP926A, 1979. Computational Mechanics Publications, Southampton,
Automotive Industry Action Group, 1995, Potential Failure Boston, pp. 739-752.
Modes and Effects Analysis (FMEA) Reference Manual, Stamatis, D.H., 1995, Failure Mode and Effect Analysis:
Detroit, MI. FMEA from Theory to Execution, ASQC Quality Press,
Bednarz, S. and D. Marriott, 1988, “Efficient Analysis for Milwaukee, WI.
FMEA,” Proceedings of the 1988 IEEE Annual Reliability Sturges, R.H., K. O’Shaughnessy, and M.I. Kilani, 1996,
and Maintainability Symposium, pp. 416-421. “Computational Model for Conceptual Design Based on
Bell, D., L. Cox, S. Jackson, and P. Shaefer, 1993, “Using Extended Function Logic,” Artificial Intelligence for
Causal Reasoning for Automated Failure Modes & Effects Engineering Design, Analysis, and Manufacturing,
Analysis (FMEA),” Proceedings of the 1992 IEEE Annual Cambridge University Press, 10(4), pp. 255-274.
Reliability and Maintainability Symposium, pp. 343-353.
Bowles, J., 1998, “The New SAE FMECA Standard,”
Proceedings of the 1998 IEEE Annual Reliability and
Maintainability Symposium, pp. 48-53.
Chittaro, L., R. Ranon, and A. Soldati, 1998, “Introducing
Deviations and Multiple Abstraction Levels in the
Functional Diagnosis of Fluid Transfer Systems,” Artificial
Intelligence in Engineering, 12(4), Elsevier Science Limited,
Oxford, pp. 355-373.
DeVor, R.E., T. Chang, and J.W. Sutherland, 1992, Statistical
Quality Design and Control, Macmillan, New York, pp. 51-
57.
Eubanks, C.F., S. Kmenta, and K. Ishii, 1996, "System
Behavior Modeling as a Basis for Advanced Failure Modes
and Effects Analysis," Proceedings of the 1996 ASME
Design Engineering Technical Conferences, Irvine, CA.
Eubanks, C.F., S. Kmenta, and K. Ishii, 1997, "Advanced
Failure Modes and Effects Analysis Using Behavior
Modeling," Proceedings of the 1997 ASME Design
Engineering Technical Conferences, Sacramento, CA.
Hawkins, P.G., and D. J. Woollons, 1998, “Failure Modes and
Effects Analysis of Complex Engineering Systems Using
Functional Models,” Artificial Intelligence in Engineering,
12(4), Elsevier Science Limited, Oxford, pp. 375-397.
Kara-Zaitri, C., Keller, A., Barody, I., and Fleming, P. (1991),
"An Improved FMEA Methodology," Proceedings of the
1991 IEEE Annual Reliability and Maintainability
Symposium, pp. 248-252.

9 Copyright © 1999 by ASME