FOA FMEA Course Notes v1.5 PDF

FAILURE MODE AND EFFECTS ANALYSIS PARTICIPANT GUIDE
Welcome
Failure Mode and

Effects Analysis
FTEP FMEA Version FOA 1.5 02/05 Page 1

FTEP Modules
Process Applied Consumer
Control Methods Focus
Process Systems
Fundamentals Engineering
Fundamentals
Global 8D FMEA
Ford
Manufacturing
Reliability Technical DV & PV
Education
Statistical Product
Engineering Program Reliability
Fundamentals of Experimental
Automotive Stats Design
Threaded Fastener Parameter
Joint Design Tolerance Design
Design
Welcome to Failure Mode and Effects Analysis

FMEA (with Robustness Linkages)
• FMEA (with Robustness Linkages) is one course in the sequence of
Ford Technical Education Program (FTEP) courses. The other
courses are shown in the graphic.

Introductions
• Your name
• Your responsibilities
• Prior FMEA experience
• What you hope to get out of this course
• Ground Rules

Course Purpose
• This course will help you understand:
– The three types of FMEAs used within
Ford
– The elements of an FMEA and how they
inter-relate
– How to create and review FMEAs
– New robustness methodologies in relation
to FMEAs
– How FMEAs fit into Ford’s quality
strategies, FPDS timings and FPS
strategies

Participant Materials
FMEA Handbook 4.1
Page
Number
Participant Guide
Participant Materials
In conjunction with this guide you have been provided with a copy of the
Ford FMEA Handbook
• The Handbook has the following features:
Complies with FAP 03-111 – Corporate Selection and
Identification of Significant and Critical Characteristics
(included in Appendix D)
Italic type font indicates the information is from SAE J1739
Revision 9/2000
• Throughout the participant guide there will be references to the
FMEA Handbook (Technical Reference Guide)
• The Book icon on lower left corner of screen will direct you to the
actual page in the FMEA Handbook

1.FMEA – An Introduction
• Why Do FMEAs?
• Definition, Purpose,
Benefits, Types
• Generating / Managing
• Roles and
Responsibilities
• FMEAs and FPDS
Introduction to FMEA
• Why FMEAs are done
• Definition, purpose, types, and benefits of FMEAs
• The basics of generating and managing FMEAs
• Roles and Responsibilities
• FMEA and Systems Engineering

Quality is Job 1
“The Quality of our products
and services must be our
number one priority today
and tomorrow. At Ford
Motor Company Quality is
Job 1.”
William Clay Ford, Jr

Chairman of the Board and CEO
Introduction to FMEA, continued

FMEAs (Design, Process, etc.) are primarily concerned with problem
prevention, aimed at improving quality and reducing customer
dissatisfaction for all customers - consumer, service, etc. FMEAs are a
key tool to allow us to design quality into the product and processes from
the very beginning.

FMEA -- Definition
Structured group of activities which ...
• Identify potential failure modes
• Identify and prioritize actions
• Document the process
2-3
FMEA Definition
A good guide:
• FMEAs identify and confirm potential Critical and Significant
Characteristics, which are addressed by changing designs or
processes.FMEAs evaluate the adequacy of proposed controls and
the need to mitigate risk by changes to the Design Verification Plan
or the Manufacturing Control Plan. The intent of the evaluation and
the proposed actions is to prevent failures from reaching the
customers, improving customer satisfaction.
A more thorough definition:
• An FMEA can be described as a systematized group of activities
intended to:
recognize and evaluate the potential failure of a
product/process and its effects,
identify actions that could eliminate or reduce the chance of the
potential failure occurring, and
document the process. It is complementary to the design
process of defining positively what a design must do to satisfy
the customer.

• A potential Failure Mode and Effects Analysis (FMEA) is an

analytical technique utilized by an engineer/team as a means to
assure that, to the extent possible, potential Failure Modes and their
associated Causes/mechanisms have been considered and
addressed. In its most rigorous form, an FMEA is a summary of the
engineer’s/team’s thoughts (including an analysis of items that could
go wrong based on experience and past concerns) as a product or
process is developed. This systematic approach parallels,
formalizes, and documents the mental discipline that an engineer
normally goes through in any design or manufacturing planning
process.

Why Do FMEAs?
1. Assessment of risk and the
determination of actions to
mitigate that risk
2. Significant savings in engineering
time due to a reduction in
changes before and after Job #1
3. Reduction of warranty cost and
avoidance of Vehicle Recall
Campaigns
Why Do FMEAs?
There are three main reasons for doing FMEAs:
1. Assessment of risk and the determination of actions to mitigate
that risk
2. Significant savings in engineering time due to a reduction in
changes before and after Job #1
3. Reduction of warranty cost and avoidance of Vehicle Recall
Campaigns

FMEA History
FMEA History
• FMEAs have been around for a long time. Before any documented
format was developed, most inventors and process experts would try
to anticipate what could go wrong with a design or process before it
was developed.
• The FMEA discipline was developed in the United States Military.
Military Procedure MIL-P-1629, titled Procedures for Performing a
Failure Mode, Effects and Criticality Analysis, is dated November 9,
1949. It was used as a reliability evaluation technique to determine
the effect of system and equipment failures. Failures were classified
according to their impact on mission success and
personnel/equipment safety.
• FMEAs were used by NASA in the 1960' s for space product
development and were a key part of the engineering of the Apollo
moon missions that put a man on the moon.
• Ford Motor Company introduced FMEAs in the late 1970' s for safety
and regulatory consideration after the disastrous "Pinto" affair. Since
then Ford has continued to use FMEAs for design and production
applications.

FMEA Purposes
Timing & Quality
of Potential Failures
FMEA Purpose
The overall purpose of an FMEA includes the following:
• Improves the quality, reliability, and safety of the evaluated products
• Aids in the development of robust product design and
manufacturing/assembly processes
• Reduces product redevelopment timing and cost
• Documents and tracks actions taken to reduce risk
• Aids in the development of robust design verification plans
• Helps engineers prioritize and focus on eliminating product and
process concerns and/or helps prevent problems from occurring
• Improves customer/consumer satisfaction
One of the most important factors for the successful implementation of an
FMEA program is timeliness. It is meant to be a "before-the-event" action,
not an "after-the-fact" exercise. To achieve the greatest value, the FMEA
must be done before a product or process Failure Mode has been
incorporated into a product or process. Up front time spent properly
completing an FMEA, when product/process changes can be most easily
and inexpensively implemented, will minimize late change crises.

FMEA Purposes
Unreliable Excellent
Products Products
Reliable
Disaster Products
Customer
Doesn't Want
FMEA -- Purpose, continued

Customer expects the right product which fulfills all functions
• DISASTER happens if we don’t deliver what the customer wants and
the product does not reliably function
• UNRELIABLE PRODUCTS result if we deliver what the customer
wants, but the product does not reliably function
• RELIABLE PRODUCTS / CUSTOMER DOES NOT WANT happens
when product fulfills all functions, but is not what customer expects
• EXCELLENT PRODUCTS results when we deliver what customer
wants and product fulfills all functions
VDS (Vehicle Design Specification) and SDS (System Design
Specification), respectively, are vehicle-level and systems-level
requirements
FMEAs eliminate, minimize, or control failure of products.

Campaign Background
CAMPAIGN RESPONSIBLE ORGANIZATIONS
100%
80%
60%
40%
20%
0%
Ford PD Supplier Ford Mfg
ORGANIZATION
2-6
Campaign Background
The chart above is from the North American Campaign Prevention
website.
Various organizations are responsible for the root cause of the Ford
vehicle campaigns for 1998 through 2002.
• Almost 75% of the campaigns were attributed to Product
Development (PD).
• This shows that greater emphasis must be placed during DFMEA to
identify failure modes in order to reduce vehicle campaigns.
• One of the key issues is to design for manufacturing and
assembly. This chart indicates that manufacturing is not a large
contributor to campaign and manufacturing/assembly errors can
usually be traced back to design.
Note: The graphic has been modified to reflect the Visteon spin-off. Here,
Visteon is categorized as a Supplier.

Best Practice FMEA

RELIABILITY NOISE FACTORS
100%
80%
60%
40%
20%
0%
System Deterioration Environment Mfg Variation Customer
Interactions Usage
NOISE FACTOR
2-6
Best Practice FMEA

• Analysis of the campaigns also reveals that System Interaction from
neighboring systems/subsystems (35%) and degradation over time
(24%) are major contributors to Ford Design-Responsible
Campaigns.
• One of the key elements of FMEA best practices is considering all
the interfaces and noise factors defined in a P-diagram.
• This FMEA course includes all of the Robustness tools that have
been incorporated into the existing FMEA process.

Former FMEA Process
Targets
FMEA
History Process FMEA
Cross-
Functional
Team
Robustness Tools are not specified
Former FMEA Process

The former FMEA Process relied on a cross-functional team, historical
data, and requirements as inputs.
The former process lacked a Robustness focus.


Quality History
Boundary Diagram
Interface Analysis
FMEA P-Diagram
RRCL
Design Changes
DVP DVP
RDM
Mistake Prevention DVP Robust Engineering
Design (RED)
FMEA (with Robustness Linkages) Process

Robustness linkages have been added to the FMEA process to reduce
vehicle campaigns significantly, enhance the corporate image, reduce
warranty claims, and increase customer satisfaction.
These Robustness linkages primarily emanate from the P-diagram, which
identifies noise factors. These factors need to be addressed early so the
design can be made insensitive to the five noise factors. This is the
essence of robustness.
The Robustness tools are inputs to the DFMEA process
•Boundary diagram – qualifies and clarifies the relationships
between systems
•Interface matrix – identifies and quantifies the strength of system
interactions
•P-diagram – identifies noise and control factors, as well as error
states
The Robustness and Reliability Checklist is a DFMEA process output
•Summarizes error states, noise factors, and the associated design
controls
•Is an input to the Design Verification Plan

FMEA -- Types
System
Design
Design/ FMEA Sub-System
Process
Concept Component
FMEA
System
Process Assembly Sub-System

Component
FMEA System
Manufacturing Sub-System
Component
Machinery
2-7 FMEA
FMEA -- Type
As a prevention tool, FMEA examines three phases where potential
failures can occur
CONCEPT FMEA (CFMEA)
• Specific to Ford only
• is used to analyze concepts in the early stages before hardware is
defined (most often at system and subsystem). There are Design
Concept FMEAs and Process Concept FMEAs.
Focuses on potential failure modes associated with the
proposed functions of a concept proposal caused by design
decisions including design of the process that introduce
deficiencies
Includes the interaction of multiple systems and interaction
between the elements of a system at concept stages

DESIGN FMEA (DFMEA)

• Standardized industry-wide
• is used to analyze products before they are released to production
Focuses on potential failure modes of products caused by
design deficiencies
Identifies potential designated characteristics called “special
characteristics”
DFMEAs are done at three levels -- system, subsystem and
component levels
PROCESS FMEA (PFMEA)
• Standardized industry-wide
• is used to analyze manufacturing and assembly processes at the
system, subsystem or component levels
Focuses on potential product failure modes of process caused
by manufacturing or assembly process deficiencies
Machinery FMEA
• An FMEA application - FMEA application to machinery being
designed or purchased

Change Point Approach

FMEAs are living documents,
and are updated when ...
• New design or process is planned
• Modification to a component,
process or system is planned,
including those due to Global 8D
• Component is to be used in new
2-11
environment, location, or application
Managing FMEAs
An FMEA is not necessary on every design or every process every
year. FMEAs are considered as living documents.
There are three basic cases for which FMEA’s are generated or updated,
each with a different scope or focus:
Case 1:
New designs (component or system), new technology, or new
process. The scope of the FMEA is the complete design,
technology, or process.
Case 2:
Modification to existing design (component or system) or
process (assumes there is a FMEA for the existing design or
process). The scope of the FMEA should focus on the
modification to design or process, possible interactions due to
the modification, and field history.
Case 3:
Use of existing design (component or system) or process in a
new environment, location, or application (assumes there is an
FMEA for the existing design or process). The scope of the
FMEA is the impact of the new environment or location on the
existing design or process.

Benefits/Uses--Concept
FMEAs
Design
• Helps select optimum concept
Concept
Process • Helps set targets for the concept
• Identifies testing requirements
• Helps determine if hardware

system redundancy is required
2-12
CFMEA Benefits and Uses

• A CFMEA is used to analyse concepts in the early stages before
hardware is defined, most often at system and sub-system levels
• There are two CFMEAs – Design concept and Process concept
• CFMEA includes the interaction of multiple systems and the
interactions between the elements of a system at design stages
• A CFMEA focuses on the potential failure modes associated with the
“proposed” functions of a concept proposal caused by design
decisions that introduce deficiencies

Benefits/Uses--Design FMEAs
• Aids in:
Design – evaluating requirements and
Concept alternatives
Process – initial DFM, DFA, DFS and DFR
• Helps:
– plan thorough and efficient
development and validation programs
– validate DVPs and SDSs
– identify potential special
characteristics
• Develops a prioritized list for
2-13 actions
DFMEA Benefits and Uses

• Aids in the initial DFM (Design for Manufacturability), DFA (Design
for Assembly), DFS (Design for Serviceability), and DFR (Design for
Recycleability)
• A DFMEA is used to analyse products before they are released into
production
• Focuses on potential failure modes caused by design deficiencies
• Identifies potential designated characteristics called “special
characteristics”
• Is performed at three levels – system/sub-system/component

Benefits/Uses--Process
FMEAs
Design • Assesses Effects on all customers
Concept • Identifies potential Manufacturing and
Process Assembly causes to focus controls on
reducing occurrence and/or increasing
detection
• Develops a prioritized list for actions
• Documents the results of the
manufacturing or assembly process
• Identifies confirmed special characteristics
requiring special controls
2-15
PFMEA Benefits and Uses

• Assesses Effects on all customers
• Identifies potential Manufacturing and Assembly causes to focus
controls on reducing occurrence and/or increasing detection
• Develops a prioritized list for actions
• Documents the results of the manufacturing or assembly
process
• Identifies confirmed special characteristics requiring special
controls

Generating FMEAs
Who initiates? Who prepares? Who updates?
When to When started

discard?
Failure
and updated?
Mode
FMEAsand
How is FMEA Effects Relationship
documented? Analysis to FPDS?
When is FMEA Who is FMEA

complete? customer?
2-17
Generating FMEAs
Although an FMEA is required, it is not necessary to begin an FMEA from
a clean sheet of paper. Previous FMEAs or "generic" FMEAs may be
employed as a Starting point.

Who initiates an FMEA?

• CFMEA:
– Scientific Research Labs (SRLs),
Research Vehicle Technology (RVT),
Advanced Manufacturing, or program team
• DFMEA
– Responsible Engineer or Supplier
• PFMEA
– Responsible Engineer or Supplier
Who initiates an FMEA?

• During the development of a Concept FMEA, the responsible activity
may be the Scientific Research Labs (SRLs), Research Vehicle
Technology (RVT), Advanced Manufacturing, or program team.
• Design FMEAs are initiated by an engineer from the responsible
design function or activity. For a proprietary design, this may be the
Supplier.
• Process FMEAs are initiated by an engineer from the responsible
process engineering department, which may be the Supplier.

When can FMEA

documents be discarded?
• FMEA Documents must be retained in
accordance with Global Information
Standards Record Retention Schedule:
– DFMEAs: Last use +10 years
– PFMEAs: Last use +5 years
When can FMEA documents be discarded?

• The record retention requirements for FMEAs developed by Ford
engineers are specified on the Global Information Standards Record
Retention Schedule.
• As currently laid out in FAP03-111, this is:
DFMEAs: Last use +10 years
PFMEAs: Last use +5 years

How is an FMEA
documented?
• On Industry Standard compliant (SAE
J1739) Forms
How is an FMEA documented?

• On the Industry Standard (SAE J1739) Forms.
• Printed output from Ford recommended software conforms to
industry standards for FMEA reports

When is an FMEA
complete?
• An FMEA is a living document
• The FMEA is "complete" when matched with
a released/signed-off product or process:
– CFMEA: when the System Design Specifications
are frozen and the design functions are defined.
– DFMEA: when the product design is released for
production.
– PFMEA: when all operations have been
considered, all Special Characteristics have been
addressed, and the Control Plan has been
completed.
When is an FMEA complete?

• An FMEA is a living document, and in that sense, it must be updated
whenever significant changes occur in the design or
manufacturing/assembly process. The FMEA is "complete" when
matched with a released/signed-off product or process. Remember
that subsequent updates may be required. At any point the FMEA
should reflect the actual present design or process. A periodic
FMEA review and update schedule should be developed and
followed.
• A Concept FMEA is considered "complete" when the System Design
Specifications are frozen and the design functions are defined.
• A Design FMEA is considered "complete" when the product design
is released for production or the program has reached sign-off.
• A Process FMEA is considered "complete" when all operations have
been considered, all Special Characteristics have been addressed,
and the Control Plan has been completed.

Who prepares an FMEA?

• An individual is usually responsible for the
preparation of an FMEA:
– Ford: responsible engineer
– Supplier: Supplier engineer
• All input should be a team effort.
• For proprietary designs (black/gray box),
suppliers are responsible. The Ford design
responsible activity approves the accuracy
and thoroughness of suppliers’ FMEAs.
Who prepares an FMEA?

• Although an individual is usually responsible for the preparation of
an FMEA, input should be a team effort. A team of knowledgeable
individuals should be assembled (e.g., engineers with expertise in
Design, Analysis/Testing, Manufacturing, Assembly, Service,
Recycling, Quality, and Reliability as appropriate.) The responsible
design or process engineer is expected to involve representatives
from all affected activities. Team members should also include
Purchasing, Testing, the Supplier, and other subject matter experts
as appropriate. Team members will vary as the concept, product,
and process designs mature.
• For proprietary designs (black/gray box), suppliers are
responsible. The Ford design responsible activity approves the
accuracy and thoroughness of suppliers’ FMEAs.
• The FMEA should be a catalyst to stimulate the interchange of ideas
between the functions affected and thus promote a team
approach. In addition, for any (internal/external) Supplier designed
items, the responsible design engineer should be involved.

Who updates an FMEA?

• FMEAs are updated by the responsible
System, Product, or
Manufacturing/Assembly Engineer
• Suppliers are responsible to keep their
own FMEAs up to date.
Who updates an FMEA?

• FMEAs are updated by the responsible System, Product, or
Manufacturing/Assembly Engineer
• Suppliers are responsible to keep their own FMEAs up to date.

Who is the FMEA

Customer?
• All FMEAs:
– End User
– Service activities
• CFMEA and DFMEA:
– Design responsible activities
– Manufacturing process activities
• PFMEA:
– subsequent or downstream manufacturing
or assembly operations
Who is the FMEA Customer?

• Concept FMEA –The definition of "CUSTOMER" for a Concept
FMEA is not only the "END USER" of the concept, but the design
responsible activities and teams for the vehicle systems or next level
assemblies where the concept will be utilized as well as the
manufacturing process activities such as assembly and service.
• Design FMEA – The definition of "CUSTOMER" for a Design
potential FMEA is not only the "END USER," but the design
responsible engineers/teams of the vehicle or higher–level
assemblies, and/or the manufacturing process responsible
engineers in activities such as Manufacturing, Assembly, and
Service.
• Process FMEA – The definition of "CUSTOMER" for a Process
potential FMEA should normally be seen as the "END USER."
However, the customer can also be a subsequent or downstream
manufacturing or assembly operation, as well as a service operation.

When is an FMEA started

or updated?
• DFMEA
– Initiated before or at finalization of design concept
– Updated throughout the phase of product
development
– Fundamentally completed before the production
drawings are released for tooling
• PFMEA
– Initiated before or at the feasibility state
– Fundamentally completed prior to tooling for
production
When is an FMEA started or updated?

• The Design FMEA is a living document and should:
Be initiated before or at finalization of design concept
Be continually updated as changes occur or additional
information is obtained throughout the phase of product
development
Be fundamentally completed before the production drawings
are released for tooling
• When fully implemented, the FMEA discipline requires a Process
FMEA for all new parts/processes, changed parts/processes, and
carry-over parts/processes in new applications or environments.
• The Process FMEA is also a living document. It should be initiated:
Before or at the feasibility state
Prior to tooling for production
• And take into account all manufacturing operations, for individual
components to assemblies.
• Early review and analysis of new or revised processes is promoted
to anticipate, resolve, or monitor potential process concerns during
the manufacturing planning stages of a new model or component
program.

FMEAs and Systems Engineering

System Engineering Implemented in FPDS
Customer Customer Focus Customer
Musts / Wants Customer Experience & Feedback Satisfaction
Vehicle Level Inputs

Corporate • Purchaser / owner / operator Customer Purchase, Oper ate
Knowledge & Maintain Disposal
• Regulatory (F MVSS, EPA, ...) Requirements
• Corp orate (WCR, ABS, Manuf , ...)
• Generic VDS & Requirements Feasibility

SDS Cas cade Feedbac k
• Competitive Vehicle Level Requirements

Benchmark Vehicl e
Data
• Vehicle At tributes DVM / DVP Production
• Vehicle System Specification - VDS Veri fi cation
• Reusabi lity
Constraints & Requirements Feasibility
Data Cas cade Feedbac k
• Product
Knowledge System / Subsystem Level
• System & DVM / DVP System
• Manufacturing • S ubsystem Design Specificat ion s - Veri fi cation
Knowledge & S DS
Reusabi lity
Requirements Feasibility
• Technology Cas cade Feedbac k
Part /
• Warranty Data
Part/ Component Fabricati on /
• Models Component Design Veri fication
• Component Design Specification - CDS
FDI/FTEP
SE Fu ndamen tals Highly Iterative Mostly serial
upd ated Aug 0 0
sev-119 7.ppt
KO SI SC PA PR J1 FPDS
2-22 CFMEA
DFMEA
PFMEA
FMEA and Systems Engineering

Concept, Design, and Process FMEAs follow the Systems Engineering "V"
model as implemented in FPDS. That is the inputs to the FMEA are
derived from Corporate Knowledge and an FMEA is completed at system,
subsystem and component levels.
Feedback loops within the Systems Engineering “V” ensure that the FMEA
at one level is cascaded downwards/upwards so that it can act as an input
to the next level.
The timing of when FMEAs should be started/completed also aligns to the
FPDS timeline with timing as shown:
Type Start Complete “First

Pass” Finish
Concept FMEA* Pre <SI> <SI>
Design FMEA <SI> <PA>
Process FMEA <SC> <PR>
*Where required

Section Summary
• Why Do FMEAs?
• Definition, Purpose,
Benefits, Types
• Generating /
Managing
• Team Approach
Section Summary
FMEAs are a planning technique aimed at improving customer satisfaction
for entire design life
• It is an up-front tool
• It is a preventative, structured technique
• Requires a team approach
• Recommended that they are facilitated
• The FMEA is a living document and experiences gained should be
used by future generations

1. What is NOT a reason for doing FMEAs?

To determine appropriate actions to be taken to reduce risk
Significant savings in engineering time
Reduction in changes immediately before and after Job 1
To lengthen the product development process in order to ensure quality
2. Select three of the types of FMEAs discussed in this course by ticking

the appropriate boxes.
Failure
Concept
System
Component
Assembly
Subsystem
Process
Design
Manufacturing
3. Some benefits of the different types of FMEAs are listed

below. Classify each as a benefit of a Concept (C), Design (D), or
Process (P) FMEA.
Determine if hardware system redundancy is required
Identify potential Manufacturing and Assembly causes
Help validate System Design Specifications
Increase the probability of detecting Failure Modes
Identify potential Special Characteristics
Select the optimum concept
Confirm Special Characteristics

2. Design FMEA – An
Introduction
• Identify DFMEA
Team
• Establish Scope
• Describe Function
– Brainstorming
– Function Trees
• Reliability and
Robustness
Checklist
Design FMEA -- Introduction

Of the three types of FMEAs, we will start with the two industry standards
-- Design FMEA and Process FMEA and then review the Ford specific
Concept FMEA

Design FMEA -- Team

Facilitator
Representatives
from:
• Customer
Service
Design Engineer
• Suppliers
Manufacturing /
• Global Test
Process Engineer
Operations
• Corporate
3-6 Quality
Design FMEA — Team

During the initial Design FMEA process, the responsible engineer is
expected to directly and actively involve representatives from all affected
areas.
These areas of expertise and responsibility should include, but are not
limited to: assembly, manufacturing, design, analysis/test, reliability,
materials, quality, service, and suppliers, as well as the design area
responsible for the next higher or lower assembly or system, sub-
assembly or component.
• It is important that employees with the correct skills and qualities are
brought to the core team and that roles are clearly defined
• Support team members provide specific expertise as needed
• Composition may change during analysis
The FMEA should be a catalyst to stimulate the interchange of ideas
between the functions affected and thus promote a team approach.
Ensure that all team members are documented in the header of the FMEA
form

Design FMEA -- Scope

• Is the boundary or extent of the analysis
• Defines what is included and excluded
• Scope incorrectly done:
– Lengthens analysis
– Misses target analysis
– Identifies wrong team membership
3-7
Design FMEA — Scope & Support

Early management support is crucial to motivating the team. Support must
be visible and active. For example, a chief program engineer reviews the
FMEAs for Priority Systems or components.
Open issues should be addressed prior to starting the FMEA. The design
of the product or process must be stable, which does not mean the final
release level has been reached or that the process is finalized. Changes
must be able to occur as the FMEA is developed so that Recommended
Actions can be implemented where possible.

Design FMEA -- Scope

Once core team is established...
• Create a boundary diagram
• Identify the boundary for analysis
• Confirm composition of support team
3-7
DFMEA Scope
In any FMEA, the core team needs to begin by determining the scope to
define the extent of the FMEA. To do this it is necessary to:
• Create a boundary diagram
• Identify the boundary
• Look for intended and unintended interfaces
Without properly determining the scope, the FMEA may either go too far
or not far enough
Once the scope has been determined, the composition of the support
team should be confirmed

Constructing Boundary
Diagrams
Oil Pan
Physical
Low pressure oil
High pressure oil
Oil
Torque
Screen
Tube
O-ring seal
Block Inlet Housing Outlet Relief Valve
Crank Rotor Set
Cover
Oil Pump System

3-8
Boundary Diagram
A boundary diagram is a mandatory tool used to divide a complex system
or assembly into manageable levels. It graphically illustrates the
relationships among the subsystems, assemblies, subassemblies, and
system components comprising a system.
Early in the design program, a boundary diagram may consist of a few
blocks representing major functions and their interrelationships at the
system level. As the design matures, boundary diagrams are revised to
illustrate lower levels of detail, down to the component level.
When correctly constructed, the boundary diagram provides detailed
information to the interface matrix, P-diagram, and the FMEA. It is
important to note that when completed or revised, the boundary diagram
must be attached to the FMEA.

Boundary Diagram
Construction
• Consider the system
• Add components in the higher level assembly
• Include system attachments and mechanisms
• Identify other interfaces with:
– Other systems
– Manufacturing/assembly tools
– Servicing/customer adjustment
• Draw the boundary of what is included and
excluded in the analysis of this FMEA
How to construct a boundary diagram

• Consider a system, subsystem or component which can be
represented as a boundary
• Then represent other components in the higher level assembly
Include all system attachments and mechanisms
• Then identify other interfaces with
Other systems
Manufacturing/assembly tools
Servicing/customer adjustment
Remember to consider all user interfaces
• Now construct the boundary, considering what is best included and
excluded in the analysis of this FMEA
The boundary will aid identification of the possible effects of
failures
• Once the scope is defined, the boundary diagram should be used to
focus the support team
Boundary diagrams will probably look different for each FMEA team, but
this is acceptable as long as the team agrees on the symbols used
(legend) and consistently uses the same symbols.

Boundary Diagram -- Example

! "" #!$
Boundary Diagram Example

Imagine a team is charged with revising an FMEA on a modified method
for mounting the headlamp with the aim of improved vertical adjustment.
The primary objective of the design engineer is to address the design
deficiencies of the vertical trimmer.


! "" #!$
Spring Lid
Adjusting Screw
Nose Piece
Base Plate
Boundary Diagram Example, continued

Since the only part that is being changed is the mounting method, the
scope and boundary should be narrower than that shown on the last
screen. The refined scope and boundary for analysis shown here is now
set at a more manageable level than on the previous screen.


Physical
Energy
Assembly Service Clearance
Hood Adjuster User

(Clearance) Socket
Vehicle Body Lateral Location screw Clips 2

Upper Cross H/lamp
Member Housing
Vibration
Boundary Diagram Example, continued

• Represent the vertical trimmer assembly as a boundary
• Represent other components in the higher level assembly
• Identify other interfaces
• Construct the boundary, considering what is best analyzed as part of
this FMEA
• Having defined scope, determine support team members or confirm
the team composition

Practice Exercise 1
Setting Scope Exercise and Creating a Boundary Diagram

The purpose of this exercise is to allow you to:
• Understand the importance of setting scope to determine both what
is and what is not included in an FMEA
• Practice setting scope by creating a boundary diagram
Your team has been assigned to perform an FMEA on a kettle.
The first step is to focus the FMEA by creating a boundary diagram and
establishing scope.
Your team will be allocated a sub-system or component for analysis.
Remember to represent the selected system, subsystem, or component
within the boundary. Then represent all other components in the higher
level assembly and any other interfaces in the boundary diagram.

Interface Matrix
• Recommended robustness tool that
acts as an input to a Design FMEA
• Identifies and quantifies the strength of
system interactions by:
– Showing whether the relationship is necessary or
adverse
– Identifying the type of relationship
3-10
Interface Matrix
The interface matrix is a recommended Robustness tool that acts as an
input to DFMEA. The interface matrix identifies and quantifies the
strength of systems interactions. Not addressing interactions at this point
can lead to potential warranty and recall issues; therefore the interface
matrix should be used at a minimum on new designs. The interface
matrix is an input to the Potential Causes/Mechanisms Failure column of
the DFMEA and also to the boundary diagram and the P-diagram. When
completed or revised, attach the interface matrix to the FMEA.
The interface matrix is also used to check the validity of the completed
Causes. Every interaction, both positive and negative, should be
verified. Negative values are analyzed for corrective action
recommendations.

Example Interface Matrix

To
Upper Cross Member

Headlamp Housing
P E P: Physically touching E: Energy transfer
Adjuster socket
I M I: Information exchange M: Material exchange
Adjuster
Hood
Numbers in each corner represent the above
Adjuster
interface types, with values
2 2 denoting the2 following:
2 2 -2 -1 2
From +2 Interaction is necessary
2 2 for
2 function
1 2 -1 2
Headlamp Housing
+1 Interaction is beneficial, but not absolutely necessary
2 2 2 -1 -1
for functionality
Upper Cross Member
Hood
0 Interaction does
-2 not
-1 -1affect
-1 -1 functionality
-1
-1 Interaction causes negative effects but does not

2 2 -1 2
Adjuster socketprevent functionality Numbers in each corner represent the above

interface types, with values denoting the following:
+2 Interaction is necessary for f unction
-2 Interaction must be prevented to achieve +1 Interaction is beneficial, but not absolutely necessary
functionality for functionality
0 Interaction does not affect functionality
prevent functionality
-2 Interaction must be prevented to achieve
functionality
3-11
Interface Matrix Example

Each square of the interface matrix is divided into four quadrants
• The placement of the values within the square represent the
interface types:
Physically touching
Information exchange
Energy transfer
Material exchange
The above interface matrix is partially complete to demonstrate technique

+2 Interaction is necessary for f unction
for functionality
prevent functionality
functionality

Example Interface Matrix
Adjuster
Adjuster
2 2
Headlamp Housing +2 Interaction is necessary for function
2 2 for functionality
Upper Cross Member
-2 -1 -1 Interaction causes negative effects but does not

Hood prevent functionality
2 2 functionality
Adjuster socket
Interface Matrix Example

• Using the Adjuster and Headlamp Housing as an example,
The +2 in the Top Left Quadrant means that there is physical
contact and that it is necessary for function
The +2 in the Top Right Quadrant means there is energy
transfer and that it is necessary for function
The remaining lower two quadrants have been left blank to
demonstrate that no interaction exists
• Using the Adjuster and Hood as another example,

The -2 in the Top Left Quadrant means that physical contact is
possible and must be prevented to achieve function. Hood
contact with the adjuster will compress or squash the adjuster
making it no longer adjustable.
The -1 in the Top Right Quadrant means there is energy
transfer which causes negative effects but does not prevent
function. In this instance the energy transfer from the hood to
the to the adjuster may cause the adjuster to self adjust and
we may not be able to prevent the energy transfer.

Practice Exercise 2
Interface Matrix
• Become familiar with the interface matrix tool
• See how the boundary diagram feeds the interface matrix
Use your boundary diagram created in exercise 1 to help your team create
an interface matrix for your sub-system or component of the kettle.
Select several key components/sub-systems and complete the interfaces
between them to get an understanding of how to use the tool – you do not
need to complete the full matrix.

P-Diagram
• Recommended structured tool to identify
intended inputs and outputs for a function
• Describes noise factors, control factors, ideal
function, and error states
• Assists in the identification of:
– Potential Causes for failure
– Failure Modes
– Potential Effects of failure
– Current Controls
– Recommended Actions
3-14
P-Diagram
A P-diagram is a mandatory structured tool that identifies intended inputs
(Signals) and outputs (Functions) for the subject under investigation.
Once these inputs and outputs are identified for a specific Function, error
states are identified. After the error states are identified, the noise factors
that could lead to the error states are listed.
The noise factors are listed according to the five basic sources of noise:
• Piece-to-piece variation
• Changes over time/mileage
• Customer usage and duty cycle
• Environmental
• Neighboring subsystems
Finally, control factors or design parameters are identified to compensate
for the noise factors.

Example P-Diagram
Noise Factors (Causes)
System Interaction Customer Usage/Duty Cycle Environment
GOP align tabs to screws Frequent adjustments Road salt
Hood adj. depth to housing
Headlamp housing to attach Change Over Time
GOP Housing to headlamp Material wear
GOP housing to adj. screws
Elec. Sys. Location to housing Manufacturing Variation
Adj. screws to housing GOP alignment tabs
VOC
VOC Headlamp housing to Headlamp housing to
Beam to
connector attachment clearance
Adjust Elec. Sys to connector Headlamp housing to hood adjust in the
headlamp clearance right
angle Body to headlamp
direction
Input Output
Signal factor Headlamp Vertical 1. Adjust light beam A0 in
the Y plane
Revision (torque) of Trimmer Assembly 2. Maintain posn (+/- x
aiming feature
mm) once adjusted
Control Factors
(Design Controls) Error States (Effects)
SAE guidelines High effort to adjust
Material stiffness Does not hold newly adjusted setting
Difficult to determine upward adj.
3-16 Lamp load
Light beam angle Unsteady light beam/vibrates when driving
calculations
P-Diagram Example
The graphic is an example of a completed P (Parameter)-diagram.
The P-diagram includes:
Signal Factors
What the input, which triggers the function being analyzed,
is (i.e., revision (torque) of aiming feature of headlamp)
Responses
Ideal, intended functional output (i.e., quick, low effort
adjustment of aim which holds the new position)
Error States
What may happen when the ideal function does not happen
(i.e., does not hold revised aim setting)
Control Factors
A list of the factors already incorporated in the design that
tend to reduce the likelihood of the "error states" existing
Noise Factors
Uncontrollable factors which disrupt ideal function and cause
error states.

Practice Exercise 3
P-Diagram
• Become familiar with P-Diagrams
• See how the boundary diagram feeds the P-Diagram
• See how the Robustness Tool Excel template can be used to create
a P-Diagram
Use your boundary diagram created in exercise 1 to help your team create
an P-Diagram for your sub-system or component of the kettle.
Enter the data into the Excel Robustness Tool to create your teams P-
Diagram.

Header Information
• Complete each field
– System, Subsystem or Component Name and
Number
– Model Years/Program(s)
– Team
– Design Responsibility
– Key Date.
– FMEA Number
– Prepared By
– FMEA Date
3-17
FMEA Header
The FMEA form, slightly different for each FMEA type, is a repository for
FMEA data. It is very important to fill all header fields on the form. If the
header is completed correctly and stored in the EKB (Engineering
Knowledge Base), there is no need for distinct FMEA numbering as the
search engine may be used to locate the information.
The field names are:
• System, Subsystem or Component Name and Number
Model Years/Program(s)
• Team
• Design Responsibility
• Key Date.
• FMEA Number
• Prepared By
• FMEA Date
Instructions on how to fill in these fields are given on the following pages.

System, Subsystem or Component Name and Number:

• Indicate the appropriate level of analysis and enter the name and
number of the system, subsystem, or component being
analyzed. The FMEA team must decide on what constitutes a
system, sub-system, or component for their specific activities. The
actual boundaries that divide a System, Sub-System, and
Component are arbitrary and must be set by the FMEA team. Some
descriptions are provided below:
A system can be considered to be made up of various sub-
systems. These sub-systems have often been designed by
different teams. Some typical System FMEAs might cover the
following systems: Chassis System, or Powertrain System, or
Interior System, etc. Thus, the focus of the System FMEA is to
ensure that all interfaces and interactions between the various
sub-systems that make up the system as well as interfaces to
other vehicle systems and the customer are covered.
A sub-system FMEA is generally a sub-set of a larger
system. For example, the front suspension sub-system is a
sub-set of the chassis system. Thus, the focus of the Sub-
System FMEA is to ensure that all interfaces and interactions
between the various components that make up the sub-system
are covered in the Sub-System FMEA.
A component FMEA is generally an FMEA focused on the sub-
set of a sub-system. For example, a strut is a component of
the front suspension (which is a sub-system of the chassis
system).
• Enter the name and Corporate Product System Classification
(CPSC) code and number of the system or subsystem being
analyzed.
Model Years/Program(s)
• Enter the intended model year(s) and programs(s) that will utilize
and/or be affected by the design being analyzed. Enter Generic, if
appropriate.
Team
• List the names of core team members. It is recommended that all
team members'names, departments, telephone numbers,
addresses, etc. be included on a separate distribution list and
attached to the FMEA.
Design Responsibility
• Enter the organization, department, and group. Also, include the
supplier name if known.

Key Date
• Enter the next milestone FMEA due date. The date should not
exceed the scheduled design release date.
FMEA Number
• Enter the FMEA document number, which may be used for tracking.
It is recommended that each vehicle line and/or model year develop
and maintain a discrete numbering system.
Prepared By
• Enter the name, telephone number, CDS ID, and company of the
engineer responsible for preparing the FMEA.
FMEA Date
• Enter the date the original FMEA was compiled and the latest
revision date

Determine Function
Determine Function
Once the FMEA team (core and supporting) and scope have been
determined and the header has been completed, the team can move on
and begin by determining the Primary functions for the system identified.

What is Function?
• Design intent or engineering
requirement
• Written in verb-noun measurable format
• Representation of all wants, needs and
requirements, both spoken and
unspoken for all customers and systems
3-22
Define Function
Describe the Function in terms that can be measured. A description of the
Function should answer the question: “What is this item supposed to do?”
Functions are design intent or engineering requirements.
Functions are:
• Written in verb-noun measurable format
• Measurable, which includes all relevant SDSs
• Design intent or engineering requirements
• Representations of all wants, needs and requirements, both spoken
and unspoken, for all customers and systems
Remember, Functions cannot be “failed” if they do not have measurables
or specifications.
Most functions can be captured by considering documented inputs such
as:
• System and Subsystem Design Specification (SDS)
• Engineering Specifications (ES)
• Design Verification Plan & Report (DVP&R)
• Quality Function Deployment (QFD)
• Regulatory Requirements

Describe Function
Verb Noun
Indicates action, Indicates what the
occurrence, being action relates to
Generate Light
Control Speed
Dispense Fuel
Retain Seat Track
B-10 Prevent Rust
Define Function, continued

Functions must be stated as:
• A verb which indicates action, occurrence or being
• A noun (description) which indicates what the actions relate to
• Avoid general verbs such as provide, facilitate, and allow
• Aim for actionable/measurable level
Refer to Verb-Noun list in FMEA Handbook Appendix B pages B-10 and
B-11
There are several areas or categories that might help the FMEA team to
identify functions. Some possible thought starters include answers to the
following questions:
• How does this item function to satisfy users?
• How does this item function to attract users?
• How does this item function to assure convenience?
• How does this item function to assure dependability?
• How does this item function to meet governmental requirements?
• How does this item function to meet safety requirements?
Properly describing function will assist subsequent steps in the FMEA
process, such as identification of failure modes

Item Function Worksheet

ITEM FUNCTION
DESCRIPTION
FUNCTION:
What is the item supposed to do?
What is the item not supposed to do?
List all the functions and separate them from the specifications.
List All Functions Specifications
Function Description: How Much?

Verb - Noun When?
3-24

The Item/Function Worksheet is one tool that may assist the team in
determining Functions and its corresponding specifications and organizing
its work effort prior to completing the Item/Function or Process/Function
column of the FMEA Form
It reminds the teams of the measurables needed
It can be used to list functions as part of prework

Brainstorming
Exercise in creative thinking

Method to generate ideas
B-12
Brainstorming
Even though cultural norms tend toward analytical problem-solving
thinking (why did this happen?), FMEA requires problem prevention
thinking (what might go wrong?)
• As we mature, more emphasis is placed on a disciplined approach
which seeks out “the right answer,” rather than the wide choice of
possibilities we experienced at childhood play
FMEA teams must deliberately create an environment conducive to
innovative, rather than analytical thinking. One way to accomplish this is
by brainstorming
“What is brainstorming?”
• An exercise in creative thinking and a method of generating ideas
• A particularly effective technique to help build a list of functions and
to help identify the unspoken voice of the customer and the
expected misuse of the component/assembly

Rules for Brainstorming

There are several guidelines to follow for
effective brainstorming sessions:
1. Warm up
2. Suspend judgment
3. Anything goes
4. Quantity counts
5. Springboard
6. Keep Going
7. Warm down
Rules for Brainstorming

1. There are several guidelines to follow for effective brainstorming
sessions:
2. Warm up - Find a quiet place and make sure the team is ready.
3. Suspend judgment - Avoid criticism.
4. Anything goes - Encourage the team to come up with all kinds of
suggestions.
5. Quantity counts - First go for quantity; quality will come later.
6. Springboard - Combine ideas to come up with new ideas.
7. Keep Going - When ideas seem to be drying up, keep persevering.
8. Warm down - After active brainstorming, take a break and possibly go
into a reflective stage.

Function Trees
• Provide an organized approach to
identify the essential features of a
product (or process sometimes)
• Help ensure that ‘unspoken’ and
‘spoken’ requirements are defined
• Provide a graphical representation of
functions to ensure clear, total team
understanding
B-18
Function Trees
A function tree is a tool that may help FMEA teams move on to define
Functions after consensing on a brainstormed list. Function trees provide
an organized approach to identify the essential features of a product (or
process). They help to ensure that "unspoken" and "spoken"
requirements are defined. They also provide a graphical representation of
Functions to ensure clear, total team understanding.
A function tree can help to assure that the unspoken yet expected
customer requirements of a product or process are met. It provides an
organized approach to identifying the essential features of a product or
process that must be addressed by its design.
It is convenient to describe the functions of a product or process by a
verb-noun measurable combination. For example, consider the functions
of a vehicle climate control system. These are to:
• Warm the interior to x °C
• Cool the occupants to x °C
• Demist or defog the windshield in x seconds

Constructing Function Trees

HOW ? WHY ?
Second
Level
First Third
Level Level
B-20
Constructing Function Trees

Function trees are built from left to right
• Start at the first level,
• Then second, and
• Then third levels
Does not always need to go to third, but must terminate in
an “actionable” level
An actionable level is where an engineer can actually start
his/her development work
Must be measurable
• As the tree is being built from left to right, continuously ask the
question, “How?”
• To validate the accuracy of the function tree, move from right to
left and ask “Why?”

Vertical Trimmer Function Tree

HOW ? WHY ?
Permit / Maintain Adjust light beam horizontally X°° both
Horizontal directions
Adjustment To maintain posn X N
Adjust Permit / Maintain

Adjust light beam vertically X°° both
Directions
Headlamp Vertical Adjustment To maintain posn X N
Maintain posn (X +/- Y mm)

once adjusted
Function Tree -- Example

• First, brainstorm a list of functions (consense on)
• Put the 1st level(s) on left
Ask, “HOW” is this function provided?
• Enter that information as 2nd level
Ask, “HOW” are these 2nd levels provided?
• Enter that information as 3rd level
Ask, is the information at an actionable level?
• Validate by asking “WHY”
• The process is iterative: items from previously consensed
brainstormed list must be revised or items added
• Recommend that after creating a function tree, the team might
complete this form to guarantee all functions are at a measurable
level

Guidelines
• Brainstorm all functions (VERB - NOUN)
• Document individual functions by asking
“HOW is function achieved?”
• Repeat left to right, until actionable level
• Use worksheet to check that actionable
level is measurable
• Work right to left and check structure by
asking “WHY is function included?”
B-20

Design FMEA Functions

POTENTIAL
FAILURE MODE AND EFFECTS ANALYSIS
Item C O Current D Action Results

l Potential c Design e
Potential Potential Cause(s)/ Recommended Responsibility
Failure Effect(s) of S a c Controls t R. & Target Actions S O D R.
e s Mechanism(s) u e P. Action(s) e c e P.
Mode Failure – Prevention Completion Date Taken
Function v s of Failure r – Detection c N. v c t N.
Function
1
Function
2
Function
3 Sub- Sub-Sub-
Function Function
Function
n
Function Sub- Sub-Sub-
Function Function
Sub- Sub-Sub-
Function Function
Function Trees, continued

• Only the actionable level functions are recorded on the Design
FMEA form.
• After brainstorming and optionally creating a function tree to the
actionable level, the FMEA team would then enter the Functions in
the Item/Function column of the form
All actionable-measurable functions (shown in yellow on slide)

Practice Exercise 4
Brainstorming Exercise – Functions

• Brainstorm a list of functions for your component or sub-system of
the kettle
The P-Diagram you created in exercise 3 will give you many of
them
Be sure to include government regulations and safety issues
as basic (primary) functions

Design FMEA – Potential Failure

Modes
3-26
Design FMEA – Potential Failure Modes

A potential Failure Mode is defined as the manner in which a component,
subsystem, or system could potentially fail to meet or deliver the intended
Function described in the Item/Function column (i.e., intended Function
fails).
Potential Failure Modes that could only occur under certain operating
conditions (i.e., hot, cold, dry, dusty, etc.) and under certain usage
conditions (i.e., above average mileage, rough terrain, only city driving,
etc.) should be considered. That is the potential Failure Modes are all the
ways that the component, subsystem, or system could possibly fail, not
just the likely ones.

Potential Failure Modes

P O T E N T IA L
F A IL U R E M O D E A N D E F F E C T S A N A L Y S IS
Ite m C O C u rr e n t D A c tio n R e s u lts

l P o te n ti a l c D e s ig n e
P o t e n tia l P o t e n tia l C a us e(s)/ Re c om m e nde d R e s p o n s ib ility
F a ilu re E ffe c t (s ) o f S a c C o n tr o ls t R. & T a rg e t A c tio n s S O D R.
e s M e c h a n is m ( s ) u – P r e v e n t io n e P. A c t io n (s ) e c e P.
M o de F a ilu r e C o m p le tio n D a te T ak en
F u n c t io n v s o f F a ilu re r – D e te ct io n c N. v c t N.
Function
1
Function
2
Function
3
Potential Failure Modes:
• No function
Function
4
• Partial/Over Function/Degraded
Function
Over Time
n
• Intermittent function
• Unintended function
3-27
Potential Failure Modes

• For each function use the four Thought Starter Failure Modes to
determine the Failure Modes for this Function.
No Function
Partial Function
Over Function
Degraded Function Over Time
Intermittent Function
Unintended Function
• Be sure to consider each Function’s measurable or condition for its
Failure Mode list.

Failure Modes -- Vertical Trimmer

Function: Adjust Light Beam X° in Both Directions
Failure Mode Type Potential Failure Mode

No function No adjustment
Partial/Over Function/
Degraded Over Time Adjustment in one direction
Intermittent function Adjustment sometimes and
not at others (not in cold)
Unintended function None known
4-24
Failure Modes -- Examples

• “Unintended function” has always existed as a Failure Mode, but
was not previously listed as a thought starter
• Note that not every thought starter will always have Failure Modes
as in last one listed
• Ford FMEA Methodology is to list all Failure Modes for one
Function, then continue down the column to the next Function and
list its Failure Modes
Continue until the column is complete

Practice Exercise 5
Brainstorming Exercise – Potential Failure Modes

• Brainstorm a list of potential failure modes for your component or
sub-system of the kettle
The P-Diagram you created in exercise 3 will give you many of
them

Effects of Failure Modes
3-30
Effect of Failure Modes

• It is a natural tendency to go to Causes first, but considering effects
first is an effective strategy to identify the most severe failures to
work to eliminate or mitigate first
Determining Effects first also helps determine which root
causes need to be determined (root cause will be discussed
later)
• Potential Effect(s) of Failure are defined as the effects of the Failure
Mode on the Function as perceived by the customer.
• Describe the effects of the failure in terms of what the customer
might notice or experience, remembering that the customer may be
an internal customer as well as the ultimate end user.
• State clearly if the Function could impact safety or noncompliance to
regulations. The effects should always be stated in terms of the
specific system, subsystems, or component being analyzed.
• Remember that a hierarchical relationship exists between the
component, subsystem, and system levels. For example, a part
could fracture, which may cause the assembly to vibrate, resulting in
an intermittent system operation.


P O T E N T IA L
F A IL U R E M O D E A N D E F F E C T S A N A L Y S IS
Ite m C O C u rr e n t D A c tio n R e s u l ts
l P o te n tia l c D e s ig n e
P o te n tia l P o te n t ia l C a us e(s)/ R ec om m e nd ed R e s p o n s ib i lity
F a il u re E ff e c t( s ) o f S a c C o n t ro l s t R. & T ar ge t A c t io n s S O D R.
e s M e c h a n is m ( s ) u – P re ve n tio n e P. A c tio n (s ) e c e P.
M od e F a ilu re o f F a ilu re C o m p le tio n D a t e T a k en
F u n c t io n v s r – D e t e c tio n c N. v c t N.
Potential Effects of Failure Modes:

• Part / Sub-component
• Next Higher Assembly
• System
• Vehicle
• Government Regulations
• Customer (Internal and End User)
3-31

• Identify the consequences (effects) of each Failure Mode on each
item:
Parts or sub-components
Next higher assembly
System
Vehicle
Customer
Government regulations
If the effect is non compliance with a regulatory requirement or
hazard, state this clearly
• All effects are listed in one field or box
• Optional effects table can be seen in Appendix B of the FMEA
Handbook.
• Ford FMEA Methodology is to list all effects of Failure for each
failure mode, then continue down the column to the next failure
mode and list its effects

Design FMEA -- Severity
3-32
Severity
• Severity is linked to the effect of failure and each effect identified in
the list must be assigned a severity rating
• What does Severity mean?
Definition FMEA Handbook page 3-32: Severity is the rank
associated with the most serious effect from the previous
column. Severity is a relative ranking, within the scope of the
individual FMEA. A reduction in Severity ranking index can be
effected only through a design change.

Suggested Severity
Evaluation Criteria
Effect Criteria: Severity of Effect Ranking
Hazardous ... affects safe vehicle operation and/or
Without government regulation without warning 10
Warning
Hazardous ... affects safe vehicle operation and/or

With Warning government regulation with warning 9
… operable at reduced level of

Low performance. Customer experience some 5
dissatisfaction
None No Effect
1
3-33
Severity Ranking Table

• The full table is available in the FMEA handbook (3-33), or on the
FMEA Quick Reference Card.
• Note that the rating table is not linear
The difference between 2 and 3 is not the same as the
difference between 6 and 7
It team disagrees between a 9 or 10, use the 10 and move on
Severities of 9 and 10 will require the same types of FMEA scrutiny
and actions
• Ford FMEA Methodology is to move down the column on the form,
completing the effect set for each Failure Mode.

DFMEA Severity Rating Example

Item Potential S
Potential
Failure Effects of Failure E
Function Mode V
Part: May be stripped during
Does not
Vertical
maintain
adjustment 10
Trimmer/ Next Higher Assembly: Headlamp
adjustment cannot be adjusted
Retains System: Misaligned light beam
Setting Vehicle: Impaired night/fog
performance
Govt Regs: Non-compliance
Customer: Impaired night/ fog
Severity Rating Table

• The team should consense on Severity ratings for each effect (go to
the next higher rating if agreement cannot be reached)
• On the form, enter the rating for the most serious Effect only
• Use the narrative in the table to decide, starting at the highest level,
working down the list and record the value on the Effects list
• All effects will have Severity values, but only the largest value, for
each Failure Mode, will be transferred to the Severity column
NOTE: Each severity rating is listed after the effect in
parenthesis or highest (worse) is noted in Effects column
This exercise is not mandatory, but good practice for historical
purposes
• In the event of a design action reducing Severity, the next highest
figure might then become important

Potential Special Characteristics
3-34

This column may be used to classify any special product characteristics
(e.g., critical, key, major, significant) for components, subsystems, or
systems that may require additional design or process controls.

Identify Potential Special

Characteristics
Design FMEA
S=9
S=10
YC
3-34

For Severity values of 9 or 10, that is where safety and/or government
regulations are effected,
• Enter YC in the Classification column
• Develop a pro-active design Recommended Action
• Assure that information is communicated to the PFMEA after causes
have been generated
Example:
• Failure Mode is that the vertical trimmer does not hold its horizontal
setting
• Recommended Action might be a design change to the mechanism
which would make the original factory setting permanent
• NOTE: This action will however now force us into a problem
satisfying another function: horizontal adjustment

Practice Exercise 6
Effects Exercise
• For two of the failure modes your team identified from Exercise 5:
List all the effects
Rate severity for each effect
Rate the overall severity for the failure modes

Potential Cause of Failure
3-37


An indication of a design weakness,
the consequence of which is the failure
mode
3-38

For YC failure modes (Severity 9 or 10) the cause must be determined
down to the root cause level.
The P-Diagram, RRCL and the Interface Matrix provide a good resource
to understand potential causes.

What Might Cause Failure?

Two Assumptions for Cause ...
• Item is manufactured and assembled
within engineering specifications
• Design may include a deficiency that
may cause unacceptable variation
(misbuilds, errors, etc.)
3-39
Causes of Failure
• There are two assumptions to begin with when brainstorming
potential causes of each failure for which some of the thought
starters include for Assumption 1:
What could cause item to fail?
What circumstance(s) could cause item to fail to perform?
How or why could item fail to meet engineering intent?
What could cause item to fail to deliver its intended function?
How can interacting items be incompatible or mismatched?
What specifications drive compatibility?
• For Assumption 2:
Is orientation or alignment important to how the item will fail to
function?
Can the component be assembled upside down or backwards?
Are the engineering specifications or tolerances compatible
with manufacturing process?

Manufacturing Misbuilds
Due to Design Deficiencies
+ +
- -
Causes of Failure -- Example

• FMEA teams should consider that manufacturing misbuilds and/or
variation can result from design induced causes
• “Poka Yoke” (mistake-proof) is a useful tool

Manufacturing Misbuilds
Due to Design Deficiencies
+ +
- -
Causes of Failure -- Example, continued

• To avoid these deficiencies
Including a manufacturing representative on your cross-
functional team will help identify these problems
• Support team composition needs to be carefully considered
• Causes can also come from Global 8D, warranty data, test data and
process evaluation sheets
• Just as we used brainstorming to get to functions, other tools help
FMEA teams get to cause
“Ishikawa” or fishbone diagrams
Why Ladders

Causes of Failures
POTENTIAL

e s Mechanism(s) u – Prevention e P. Action(s) e c e P.
Mode Failure of Failure Completion Date Taken
Function v s r – Detection c N. v c t N.
Function Failure
1 Mode 1
Failure
Mode 2
WHY?
Failure
Mode n
M E P E M
Tools for Analyzing Causes of Failure

Ishikawa “fishbone” diagrams and the “Why Ladder” are recommended
tools for determining Causes of Failure.
In the “fishbone” diagram, the major (first level) Causes are often shown
as the major “bones”: people, machines (equipment), methods, materials,
or environment.
Equipment Method
Failure
Mode
Material Environment People

Example of a "Why Ladder" for a "broken bracket" failure:
Material
cracked
Part
Level 1 WHY? bends
Level 2 WHY? Support area
too small
Level 3
WHY?

Causes of Failure
Use a Fishbone Diagram
Broken Bracket Interface not

Support Area
Understood by User
too Small
No
Adjustment
Thread Fusion
Material Propagation
Screw Thread Specification

Thread Geometry Oversize
B-24 Thread Seizure
Root Cause: Fishbone Diagrams

Ishikawa / Fishbone diagram:
• The box represents the Failure Mode
• Large, major bones represent first level Causes -- often seen as the
immediate Cause of the failure
• Smaller bones represent root causes
Root cause is the underlying or basic cause for a failure
Root cause must be determined for all Failure Modes with
Severity of 9 or 10
Root causes are identified and described in terms of part
characteristics, such features as dimension, size, form,
location, orientation, texture, harness, tensile strength,
appearance, coating and reflectivity
• Especially with the second assumption, the major cause might be
looked at in terms of:
Material, Environment, People, Equipment, Method, (MEPEM)

Causes of Failure -- Why Ladder

Broken Bracket
Material
cracked
Part
Level 1 WHY? bends
Level 2 WHY? Support area
too small
Level 3
WHY?
Root Cause -- Why Ladders

Keep asking the question Why? For each cause until the root cause is
reached.
Note that this method is not very effective where multiple root causes are
involved.

Sentencing Technique
Due to
Cause
Failure Could result in
Effect
Leads Mode
to
TIME
B-25
Confusing Cause with Effect

• One of the major problems encountered with FMEAs is getting
Failure Modes, Effects and Causes mixed up
This is complicated by the level at which the analysis is carried
out
To guarantee proper identification, use the sentencing
technique to relate Cause back to Failure Mode, not back to
Effect
This is a particularly common problem in Ford of Australia
FMEAs

Example
Due
to
Thread Misaligned
No Beams
Seizure Could
Leads
to
Adjustment result
in
TIME
B-25
Confusing Cause with Effect, continued

• State the Failure Mode
Ask what could that failure mode result in
The answer is the EFFECT
Ask what could that Failure Mode be due to
The answer is the CAUSE
• The sentencing technique will help confirm that Cause relates back
to Failure Mode, not back to Effect

Design FMEA - Occurrence
3-42
Occurrence
• FMEA Handbook page 3-42: Occurrence is the likelihood that a
specific cause/mechanism (listed in the previous column) will occur
during the design life. The likelihood of occurrence ranking number
has a relative meaning rather than an absolute value.
• Preventing or controlling the causes/mechanisms of the failure mode
through a design change or design process change (e.g. design
checklist, design review, design guide) is the only way a reduction in
the occurrence ranking can be effected.

Suggested Occurrence
Evaluation Criteria
Probability of Failure Possible Failure Rates Ranking
≥ 100 per thousand vehicles/items 10

Very High:
Persistent failure 50 per thousand vehicles/items 9
5 per thousand vehicles/items 6

Moderate:
Occasional failures 2 per thousand vehicles/items 5
1 per thousand vehicles/items 4
Remote: Failure unlikely ≥ 0.01 per thousand vehicles/items 1
Occurrence Ranking Table

• The Occurrence table is used to estimate the failure rate and/or
criteria to develop a rating for each Cause.
For each potential cause listed, enter a rating from the
Occurrence rating table for the Design FMEA
If the failure rate is between ranges, use the next higher rating
If the Failure rate cannot be estimated, then judge the
likelihood that the Cause and its resultant Failure Mode will
occur over the design life (150,000 miles or 10 years in
service.)
If the Occurrence rating cannot be estimated, or the team
cannot reach consensus, then enter a rating of 10
• Note that an Occurrence rating of one (1) should be rare, and must
always be questioned (See Tip on FMEA Handbook page 4-42)

Identify Potential Special Characteristics
Design FMEA
S=9 S=5-8
S=10 O=4-10
YC YS
3-45

If a Failure Mode/Cause combination has a Severity rating of 5 to 8 and
an Occurrence rating of 4 or higher there is a potential Significant
Characteristic.
When a potential Significant Characteristic is identified, the letters “YS”
are entered in the Classification column and a Process FMEA is initiated.
10
9
8
7
6
5
4
3
2
1
1 2 3 4 5 6 7 8 9 10

Practice Exercise 7
Causes Exercise
• For the same two failure modes your team used in exercise 6:
List all possible causes using the criteria and tools just covered
Rate each cause for occurrence

Design FMEA Design Controls
3-48

DFMEA - Design Controls

Type 1 Prevention:
– Prevent the cause/mechanism or failure
mode/effect from occurring, or reduce
the rate of occurrence
Type 2 Detection:
– Detect the cause/mechanism or failure
mode, either by analytical or physical
methods, before the item is released to
production
3-49
Current Design Controls

FMEA Handbook page 4-47:
• Type 1: Prevention – Prevent the cause/mechanism or failure
mode/effect from occurring, or reduce the rate of occurrence.
Example preventive controls:
WCR/SDS, design guidelines
CAD Reviews
CAE
Design Calculations
• Type 2: Detection – Detect the cause/mechanism or failure mode,
either by analytical or physical methods, before the item is released
to production. Must be performed prior to the design being released
to production
Example detective controls:
fatigue test
mud bath
simulation
Current design controls might include design reviews, analytical studies,
computer model programs, and any specific test done as part of DV
FMEA SAE standards state it may be helpful that D or P designations be
added behind the controls

Design FMEA -- Detection
3-51
Definition of Detection
Detection is the rank associated with the best type 2 design control from
the list in the previous column. Detection is a relative ranking, within the
scope of the individual FMEA. In order to achieve a lower ranking,
generally the planned design control (e.g. validation, and/or verification
activities) has to be improved.

Suggested Detection Evaluation Criteria

Detection Criteria: Likelihood of Ranking
detection by design control
Absolute Design control will not and/or cannot
Uncertainty detect a potential cause/mechanism 10
… or there is no design control
Moderately Moderately high chance the design

High control will detect potential cause/ 4
mechanism and ...
Almost Design control will almost certainly

Certain detect a potential cause/ 1
mechanism ...
3-53
Detection Ranking Table

• When several controls are listed for a particular failure mode:
Estimate a Detection rating for each control
Select the best (lowest) rating
Optionally, if all controls will be used, determine a composite
Detection rating based on the accumulated controls
Note that a Detection of one is rare because it implies that
Detection is guaranteed
• “No Detection”/Only prevention controls equals a 10 rating
• The timeliness of the test should also be included in the assessment
– i.e. a later test ranks higher as the team will have lest time to
react. For example, for a component, R310 vehicle durability should
be rated very high (8 plus) as it occurs far too late for the team to
react with FPDS timing.

Design FMEA -- RPN
3-54
RPN
The Risk Priority Number (RPN) is the product of Severity (S) times
Occurrence (O) times Detection (D) ranking.
• FORMULA: RPN = (S) x (O) x (D)

RPN -- Examples
S X O X D = RPN
2 10 10 200
10 10 2 200
10 2 10 200
Risk Priority Number (RPN) Examples

As shown by the above examples, RPN alone is not an adequate method
to assess the risk.
Therefore, threshold values for RPNs should not be established. In other
words, there is no value above which it is mandatory to take a
Recommended Action or below which the team is automatically excused
from an action.

RPN -- Examples
S X O X D = RPN
10 2 2 40
3 10 2 60
2 5 10 100
RPN -- Example 2
Which of these three RPNs should cause the most concern
• Answer: we need more information than just RPN:
Most concern: 40 because it is Severity 10
Least concern: 100 because Criticality is low

Assessing Risk
Order of Assessment:
• Severity (S)
• Criticality
– Severity X Occurrence (SO = Criticality)
• RPN (Risk Priority Number)
– Severity X Occurrence X Detection
(SOD = RPN)
Assessing Risk
The purpose of Recommended Actions is to eliminate potential Failure
Modes.
The FMEA team should prioritize Failure Modes based on the following
characteristics:
• Effects that have the highest Severity ratings
For all Severities of 9 or 10 the team must drive to root cause
• Causes that have the highest Severity times Occurrence (Criticality)
ratings
For all YS characteristics causes, root cause should be
determined
• The highest RPNs
RPN values are used to rank risk order
The RPNs have no value or meaning in themselves
It is an unsound practice to establish “threshold values” for RPN to
characterize actions
• Each RPN value must be evaluated on its own

DFMEA -- Recommended
Actions
3-55

Recommended Actions
• Enter an action as required and
appropriate
• Assign each action to a team member
with a specific due date
• If no action is planned, enter “None” or
“None at this time”
3-55
Recommended Actions
In general practice, when the Severity is a 9 or 10, special attention must
be given to assure that the risk is addressed through existing design
controls or preventative or corrective action(s), regardless of the RPN.
In all cases where the effect of an identified potential Failure Mode could
be a hazard to the end-user, preventive/corrective actions should be
considered to avoid the Failure Mode by eliminating, mitigating or
controlling the Cause(s).
After special attention has been given to Severity(s) of 9 or 10, the team
then addresses other Failure Modes, with the intent of reducing Severity,
then Occurrence and then Detection.
The control factors from the P-diagram will provide insight to
Recommended Actions. Some Recommended Actions may be
modifications to the DV Plan. Be sure that these are included on both the
DVP&R as well as the robustness and reliability checklist.
Guidelines:
• Do not leave any fields in Recommended Actions blank if no action
is to be taken enter “none” or “none at this time”
• Each action must be assigned to someone with a specific due date

Document Correlation
Customer
wants/GQRS/
brand profile
Interface Matrix/ DVMs,
P-diagrams*
dissatisfiers
Boundary KLTs,
Error states
Satisfiers/
Diagram* CETP etc.
Prioritized
targets/ Degradation
cascades*
sources
Control
n
factors
te em
io
Noise
ct
in yst
ra
S
DESIGN FMEA
Duration of perceived Shift takes longer than X ... Low satisfaction, smooth # Too much D/L # D/L system compliance # D/L system (Engineer names)
shift less than X sec ... trans & overall trans suspension wind-up ... test, engine to tires ... compliance
operation ... requirements
cascaded to
components
DVP/Robustness/Reliability
Checklist*
• Key preventive design actions DVP prioritization Design actions,
• Coordinated DV plan (Criticality/RPN) new SDSs, DVMs,
— Reuse plans subsystem FMEA, DOE
— CAE plans
— Bench/rig test plans
— Prototype build/test plans
* Tools applied from vehicle to subsystem level, then cascaded from subsystems to components
Document Correlation
The illustration above shows where the Robustness tools are input into the
DFMEA.
The following process elements/tools provide input to the DFMEA:
• Failure Mode – Degradation from the P-diagram
• Effect – Error states from the P-diagram
• Cause of Failure – Noise factors from the P-diagram and system
interactions from the boundary diagram and interface matrix
• Actions – Control factors from the P-diagram
The Recommended Actions should drive updates to the SDS, the
DVM and the DVP
Historically Ford has been weak in the correlation of this information and
especially the archiving of it for future reuse


Quality History
Boundary Diagram
Interface Analysis
FMEA P-Diagram
RRCL
Design Changes
DVP DVP
RDM
Mistake Prevention DVP Robust Engineering
Design (RED)
FMEA (with Robustness Linkages) Process FOA

•The corporate model is to use the DFMEA to input to the RRCL.
•It is more effective and efficient to create the RRCL first and use it
to feed the FMEA
•The RRCL is a structured approach to map the interaction
between the P-Diagram noises (potential causes) and Error States
(Failure Modes)

P-Diagram/FMEA Inputs into

DVM
Failure Mode Potential Cause of Failure (P-diagram Noise factor
alignment)
Vertical Trimmer Thread Seizure – Thread •Thread radius variation

Assembly DFMEA Fusion (from Fishbone •Temperature
diagram) •Humidity
No adjustment •Water
•Contamination
Broken Bracket – support •Material stiffness variation
area too small (from •Temperature
Fishbone diagram) •Humidity
•Water
•Road Loads
•Thread hole radius variation
P-Diagram/FMEA Inputs into the DVM

• The P-diagram and FMEA are both important inputs into the
development of a DVM, because they help identify key potential
causes of failure (error states) and the causes of such failures (the
Noise factors).
• The verification process needs to ensure that the product design is
robust to such potential causes of failure.
• The headlamp vertical trimmer assembly team has now considered a
number of data and information sources in relation to the DVM (ie:
Boundary Diagram, P-diagram, Interface Matrix, Quality History,
Warranty Data etc). On the basis of these findings, they are now in a
position to consider how to modify the previous DVM to ensure that it
represents the most appropriate verification test method for the new
Vertical Trimmer Assembly.

Modification of DVM Test

Description
Previous Test Apply a vertical load (0.5kg) to the vertical trimmer headlamp
assembly whilst the headlamp is on a test rig subject to cycles that
Description correlate to 10 years/250,000kms.
The deformation of the bracket after test should not exceed 2mm;
measure using a calibrated vernier scale. Visually inspect for any
cracks or loose fittings. Sample size 3.
The following question will focus attention on exactly how the DVM
should be modified:
Does the previous test allow for Noise factor levels to be
manipulated in order to verify the robustness of the Vertical
Trimmer to these Noise factors?
Do you think that the measurement system and observations will
generate results representative of what to expect in the field?
Clearly the test method needs improvement.

Modification of DVM Test

Description
Previous Apply a vertical load (0.5kg) to the vertical trimmer headlamp
assembly whilst the headlamp is on a test rig subject to cycles that
Test correlate to 10 years/250,000kms.
Description The deformation of the bracket after test should not exceed 2mm;
measure using a calibrated vernier scale. Visually inspect for any
cracks or loose fittings. Sample size 3.
Modified Test Rig to include the effect of fatigue loading on bracket and thread
subject to cycles that correlate to 10 years/250,000kms. The effect of
Test the following are to be included as Noise factors:
Description •Cust Usage - (Different levels of) loading (including worst case)
•Deg. Over Time – Corrosion, aging/durability of bracket and thread
•Internal Env – Heat from Engine
•External Env. – Dust, Humidity
•Piece to Piece Variation - Bracket Radii curvature,
The following should be monitored at 0, 50, 75, 100% stages of the
test
•Torque monitoring of thread.
•Die Penetrant test for cracks on Bracket. The deformation of the
bracket after test should not exceed 2mm; measure using a calibrated
vernier scale
The modified test description is an improvement upon the previous test

description since it incorporates the Robustness ideas identified through
•P-diagram Noise Factors

•Potential Failure Mode from the DFMEA (Error states from P-diagram)
A DVM taken from the SDS should not be used without a careful cross
check from the P-diagram and DFMEA to ensure all the failure modes and
Noise Factors are included. This may involve changing the test
description like the example above and this should be done for new model
programs regardless of whether the system is carry over or parts are not
changing.

Actions Taken
POTEN TIA L
FAILU RE M OD E AN D EFFEC TS AN ALY SIS
Item C O C urrent D A ction R esults

l Potential c D esign e
Potential Potential Cause(s)/ R ecom m ended R esponsibility
Failure Effect(s) of S a c C ontrols t R. & Target Actions S O D R.
e s M echanism (s) u – P revention e P. Action(s) e c e P.
M ode Failure of Failure C om pletion D ate Taken
Function v s r – D etection c N. v c t N.
Action Results
Responsibility & S O DR
TaFMEA Handbooket
Actions e c e P
Action(s) Completion Date t N
e
c
Action Results
Actions S O D R
Taken e c e P
v c t N
3-57
Actions Taken
• After an action has been implemented:
Enter a brief description of the actual action and effective date.
Re-rate any of the Severity, Occurrence or Detections based
on the actions taken and enter into the revised Severity,
revised Occurrence or revised Detection columns
• The DFMEA team leader is responsible for implementing a follow-up
program to ensure all Recommended Actions have been adequately
addressed.
• Note: The design engineer’s goal is to make designs robust so that
special manufacturing/assembly controls are not required. Detection
controls do not decrease Criticality. Remember, the design engineer
CANNOT rely on manufacturing/assembly process controls to
overcome potential design weaknesses.
• The DFMEA team leader is responsible for updating the Design
FMEA. The FMEA is a living document and should reflect the latest
item level and the latest relevant actions. The responsibility could
also belong to a supplier.
• A thorough Design FMEA will be of limited value without positive and
effective actions to prevent failures

1. What is the first task of the core team of a DFMEA?

Focus the support team
Define scope
Complete the header on the FMEA form
Create a function tree
2. When is a function tree complete from left to right?

(Select the best answer.)
At an actionable level
At the third level
When the Function is in a measurable format
When you can no longer answer "Why?"
3. What is a potential special characteristic?

A characteristic with a Severity rating from 5 to 8 (inclusive) and an
Occurrence rating of 4 or greater
A characteristic with an Occurrence rating greater than 7
A characteristic with a Severity rating of 9 or 10
A and C

Practice Exercise 8
Detection and Actions Exercise

• Continue through the FMEA your team has started by:
Identifying prevention and detection controls for the two failure
modes
Rating the overall detection
Calculating the RPNs
Identifying any actions to:
Eliminate the failure mode
Eliminate the cause of failure
Improve detection

Reliability and Robustness Checklist
Test Interactions
Records which test can
detect which Error States and
check for Ideal function
Noises and Metrics Error State NFMS Test Coverage Test Coverage Test Interactions
Noises identified with metric, and upper Interactions Strategy that the team have Required to Test Shows the composite of the two Records which test includes
and lower limits. Noises that could adopted (X) or are indicates which error Test Interaction matrices. It the noise
Contract column to indicate possibly cause the investigating (I) to become states (letter indicates for each noise, and each Not shown on the printed
agreement between the creator of error state. more robust to the noise. correspond to error test, which error states will be version
the noise and the receiver. X indicates a Description records basic states) should be tested for. This provides a
Blue highlighted X indicates a key strong interaction, details tested for this noise, measure of the efficiency of the
noise that the team are concerned 0 indicates a weak base on the Error test - a test with very few letters is
about based on history or interaction State Interactions. inefficient, while a test with a
engineering judgement. Key noise Plan Shortfall column full of letters is very
rows are indicated by a larger font. indicates which error efficient. Resource should be
states no test is focused on the efficient tests.
planned for that
includes this noise.
DV Status indicates
which error states
have been tested for
against this noise, with
a pass results.
Overall Shortfall is the
combination of the
plan shortfall, and
tests which have not
yet been completed.
Reliability and Robustness Check List (RRCL)

The purpose of the RRCL is to improve robustness through extending the
P-diagram to cover robustness and testing. To do this a number of
methods are used:
• Establishing a better understanding of the effects of noises and
quantifying those noises.
• Establishing a Noise Factor Management Strategy (NFMS)
wherever possible, to become robust to the noise.
• Identifying what testing is being done for each noise leading to an
improved DVP that covers as many noises as possible.
To do this, the RRCL steps the engineers through:
• Identifying the ideal functions of the system.
• Identifying the Error States of the system.
• Identifying the noises that may influence the system
• Quantifying the magnitude of the noises – how is the variation
measured, what are the upper and lower limits.
• Establishing an agreement with the creator of the noise.
• Establishing, based on knowledge and engineering judgement,
which Noises may cause which Error States.

• Identifying a NFMS for each Noise if possible, from the six available
strategies:
Change Technology
Apply Parameter Design
Upgrade Design Specification
Reduce or Remove the Noise
Add a Compensation Device
Disguise or Divert the Error State
• Identifying what Tests are available
• Identifying which Tests can detect each Error State, and test for
each Ideal Function.
• Identifying which Tests include which Noises
• Identifying the overall coverage of noises and Error States in the
planned testing, and where testing falls short.
• Develop extra Tests or refine existing Tests as required to cover
gaps.
Within the Ford of Australia Reliability Tool, a cross check to the FMEA
can also be produced which shows the error states, what noises may
cause them, and what test are detecting them in an FMEA style format.
This can be used to both create and review FMEAs

Practice Exercise 9
RRCL Exercise
• Using the P-Diagram from Exercise 3
Complete the RRCL
Use the FMEA Cross Check function to check your FMEA

FMEA Software
FMEA Software
• Byteworx FMEA is the corporate standard used to create a soft copy
FMEA. Previously FMEA plus, Star FMEA and/or Excel based
FMEA templates were used by various engineering communities
To obtain a copy of Byteworx FMEA call the help desk and ask
to have the software installed on your computer
To convert your existing FMEA to a Byteworx FMEA format
instructions can be found at:
http://www.quality.ford.com/cpar/fmea/FMEAplusFileToByteWo
rx.htm
• To get more information please visit the FMQ homepage:
http://www.foa.ford.com/fmq/web/reliability/fmeas.htm

FMEA Working Model

% & % & % & '
What YC – Severity 9 & 10 What can be done?
How bad
are the • Design Changes
is it?
Effect(s)?
• Process Changes
What are the
Functions, Severity < 9 • Special Controls
Features, or
Requirements? • Changes to
YS or
Standards,
What How often YC Procedures, or
are the does it
Guides
Cause(s)? happen?
What can go wrong?

Not YS
• No Function
or YC
• Partial/Over
Function/Degraded How can
Over Time the cause
be
• Intermittent prevented
Function and
detected? How good
• Unintended is this
Function method at
detecting
it?
FMEA Working Model

The FMEA Working Model will help team members perform FMEAs. The
Working Model is now an SAE standard.
It is a "flow diagram" of the FMEA thought process overlaid on an FMEA
form.
• Although there are minor differences in the forms for the different
types of FMEAs, the thinking process is the same for all types of
FMEAs.
• The key steps of the Working Model are grouped into three Steps
Working Path Model Path/Step 1
• Step 1 consists of the following steps:
Define Function of the part or process being analyzed.
Identify the Failure Modes of the Function.
Identify the Effects of the Failure Modes.
Assess the Severity of the Effect on a scale of 1 to 10.
If possible, recommend actions to eliminate Failure Modes
without addressing "Causes".
Note: This is a very rare event and is discussed later in the
course.
If the Failure Mode cannot be eliminated, then continue with Step 2.


Identify all of the Causes of the Failure Mode.
Assess how often the Causes occur on a scale of 1 to 10.
(Occurrence)
Defining Recommended Actions for high S x O (Severity x
Occurrence = criticality)
Recommend actions to eliminate the Cause.
• If the Causes cannot be eliminated, then continue with Step 3.
Identify Prevention controls to reduce occurrence.
Identify Detection controls (e.g., tests, inspection) to address
Failure Modes and Causes.
Assess the effectiveness of the Detection controls on a scale
of 1 to 10.
Recommend the appropriate Detection controls.
(Recommended Actions)
Note:
If the Failure Mode is eliminated in Step 1, then Steps 2 and 3 are not
necessary. If the Failure Mode/Causes are eliminated in Step 2, then
Step 3 is not necessary.

1. What is the goal of Path/Step 1

Eliminate a Cause
Eliminate a Failure Mode
Improve detection of an Effect or Cause

Eliminate a Cause

Eliminate a Cause
4. Which of the following statements regarding when an FMEA is

"complete" are true?
An FMEA is a living document that must be updated whenever
significant changes occur.
An FMEA is "complete" when the core team determines it is done
An FMEA is "complete" when matched with a released/signed-off
product or process
An FMEA is "complete" when all Failure Modes have been eliminated
A and C
B and C

Practice Exercise 10
Working Path Exercise

• Review your teams FMEA:
Would you have worked differently if you had used the working
path model?
Report your results briefly to the class

DFMEA – Summary
• Scope
• Functions
• Effects – Severity
• Causes – Occurrence
• Special Characteristics
• Design Controls –
Detection
• Assessing Risk
• Actions
• Working Path Model

3. Process FMEA
• PFMEA Paths/Steps
1, 2 & 3
• Special Characteristics
' %
• Special Controls
Process FMEA
• At the beginning of the course three types of FMEAs were identified
-- the first was Design, the second Process and the third Concept; in
this section PFMEAs will be discussed
Process FMEA is the technique employed to analyze
manufacturing and assembly process design during the
planning stage
PFMEA focuses on potential failure modes of the
manufacturing and assembly process
The stages are similar to Design FMEA except that it
concentrates on process function/purpose as opposed to
component function

Process FMEA
POTENTIAL

4-4
Inputs to a PFMEA
Some typical inputs to a PFMEA include:
• Recommended actions from the DFMEA
• RRCL (Reliability and Robustness Checklist)
• Characteristic Matrix
• P- diagrams
• Historical Manufacturing Performance Information
• Gauging Information using GDT
• Potential Critical and/or Significant Characteristics
• And Design information related to potential strategies to name a few
There is a strong correlation between many of the columns in a DFMEA
and PFMEA. Effects and their corresponding severity will relate directly,
with unique process effects added to the PFMEA. Other relationships are
more subtle, for example, design causes relate to process failure modes.

Process FMEA -- Team

Facilitator or Application Engineer
Representatives
from:
• Specialists
Manufacturing / • Suppliers
Process Engineer • Maintenance
Design Engineer • Production
• Next Process
Engineer
4-5
PFMEA Team
The core team is established and begins by defining the scope of the
PFMEA. By first defining the scope, it is more likely that employees with
the correct skills and qualities are brought to the core team and that roles
are clearly defined.
• The core team is typically composed of design and manufacturing
representatives who will see the FMEA through to its conclusion and
are empowered to make decisions regarding the item being
analyzed. The team leader is the process person most responsible
for this item.
The support team provides expertise as needed, and its composition may
change during the analysis.
• Support Team The support team can consist of representatives from
areas such as customer service, Technical Specialists, suppliers,
Global Test Operations, Corporate Quality, maintenance,
production, process engineering, maintenance, hourly operators,
and next and process operation engineering. The composition of
this team depends on the type of FMEA and can change as needed
throughout the life of the FMEA.
Ensure that all team members and their departments are listed in the
header of the FMEA form. This is the Ford standard; the industry
standard is to list only core team members in the FMEA header.

Process FMEA -- Scope

• Create macro flow diagram
• Identify boundary for analysis
• Create micro flow diagram
• Define support team composition
4-5
PFMEA Scope
Previously the scope in Design FMEA was set by creating a boundary
diagram
In any FMEA, the core team needs to begin by determining the scope
The scope is set differently in PFMEA than in a DFMEA
• Scope for a PFMEA can be determined by:
Creating a macro flow diagram
Identifying the boundary
Creating a micro flow diagram
Without properly determining the scope, the FMEA may either go too far
or not far enough
Process flow MUST be created for the PFMEA
Defining the composition of the support team is also necessary in
determining the scope

Headlamp Assembly -- Macro

Assemble Bulb to 50
Assemble Bulb
10 Reflector
Holder
Bulb Test 60
Assemble Lens
20
to Reflector
Assemble Rear Cover 70
Assemble
Vertical Trimmer to 30
Reflector Photometric Test 80
Assemble Horizontal 40
Trimmer to Reflector Load onto Pallet
Inspection Operation Storage Transportation
4-6
Process Flow – Macro

Flowcharting is a useful quality tool to identify both the macro and the
micro levels of a process
• This flowchart shows all the macro operations in the manufacture of
the headlamp assembly
• All nine of these operations would need to be included in a full
Process FMEA
• There is a change that is going to be made to operation 30 where
the vertical trimmer is assembled to the reflector so a boundary
needs to be drawn on the macro flow chart to indicate the area being
looked at
• A Process flow is mandatory for a PFMEA just like a boundary
diagram was mandatory for a DFMEA

Headlamp Assembly -- Micro

Op 30 - Assemble Vertical Trimmer to Reflector
Locate and fix (2 screws)
30.1
base plate to reflector
Insert nose and positively

locate pre-assembled 30.2
screw and spring
Visually inspect trimmer 30.3

assembly
4-6
Process Flow – Micro

The diagram shown is a micro flow chart of OP-30. The macro flow chart
shown on the previous screen set the scope based on the operation
where change will occur as Operation 30. It shows three subsets
• 30.1 Locate and fix (2 screws) base plate to reflector
• 30.2 Insert nose and positively locate pre-assembled screw and
spring
• 30.3 Visually inspect the trimmer assembly
By establishing the boundaries on the macro flow chart, the boundaries of
the micro flow chart are also established, and the scope of this FMEA is
determined.
This also determines the relevant composition of the support team which
may need to change during the analysis -- operation by operation

Characteristic Matrix
Operations
Product Characteristics 30.1 30.2 30.3
• Correct orientation –base
A
plate
• Correct location –base
X
plate
• Two (2) XYZ screws A
• Correct torque X +-y X
• Correct orientation
X
spring/screw assembly
• Correct location X
• Positively located
X
Legend
X– Characteristic is created or changed
C– Characteristic is used for clamping
L– Characteristic is used for locating
T– Common tool creates more than one characteristic
M– Characteristic is automatically monitored
A– One finished product characteristic has a strong
effect on another
4-7
Characteristic Matrix
• A part characteristic is a feature about the part, which when
compromised, generates a Failure Mode. It may be a dimension,
such as a hole’s inside diameter, or it may be a specification such as
material composition.
• Anytime a YC or YS is identified when doing a DFMEA, the Failure
Mode must be reviewed to determine if part characteristics, which if
compromised during the process, causes the process Failure
Mode. An effective way to do this is to go to the Cause column on
the DFMEA form. Then, look at each cause and determine if there
is an associated part characteristic, which when compromised,
initiates a Cause.
• Once all the Failure Mode’s associated part characteristics are
identified, they must be summarized and communicated to the
corresponding PFMEA team. These characteristics are then placed
on a Characteristic Matrix, aligning them individually with each of the
process steps where they can potentially be compromised. It is
important to understand that anytime one of these part
characteristics is compromised, the associated DFMEA Failure
Mode is reintroduced along with its effects. Therefore, the part
characteristic is the link between the DFMEA and PFMEA


ITEM FUNCTION
DESCRIPTION
FUNCTION:
What is the item supposed to do?
What is the item not supposed to do?
List all the functions and separate them from the specifications.
List All Functions Specifications
Function Description: How Much?

Verb - Noun When?
3-24

The Item/Function worksheet or Process/Function worksheet when
relating to PFMEA is a tool that may assist the team in determining
Functions and its corresponding specifications. It can also be used as an
upfront tool in organising work efforts prior to completing the
Process/Function column of the PFMEA form

Process Purpose Statements

POTENTIAL

Process Function/Requirements
It is essential that all process functions/purposes are considered. If one is
omitted, the associated potential failures will not be
considered. Documentation including regulatory requirements, process
flow charts, characteristic matrices, and DFMEAs should be reviewed for
previously found functions of the process being analyzed.

Define Process Purpose

• What does the process do at this
operation?
• Written in verb/noun/measurable format
• Measurables which include all end
product and in process requirements
4-13
Define Process Function/Purpose

It is essential that all process functions/purposes are considered
• If one is omitted, the associated potential failures will not be
considered
The team needs to:
• Know what the process does at this operation
• Ensure that all process purposes are considered
• Share understanding of function/purpose and requirements
The function/purpose of a process operation is what is achieved at that
operation
• What the operation is there to do
• It needs to be precise, expressed in verb-noun-measurable format

Micro Flow -- Process Purpose

Purpose
Locate and fix (2 screws) • Locate base plate -- correct
orientation
30.1
base plate to reflector • Secure 2 screws to specified
torque
• Insert nose to correct
Insert nose and positively position per visual aid
locate pre-assembled 30.2 • Positively locate

screw/spring
sub-assembly
screw and spring
• Visually inspect (to comply
with part drawing): screw,
spring, location, fixing
Visually inspect trimmer 30.3
assembly
Process Flow with Function/Purpose

• Process purposes should be documented on the FMEA form. The
Item Function worksheet that was described in the DFMEA module
can also be useful for PFMEAs. A PFMEA team can simply change
the headings for a PFMEA.
• All micro steps/specifications and any special operating conditions
should be transferred to the PFMEA form. Some micro steps and
specification information can be gleaned from existing work
instructions. The micro steps and operating conditions can then
become output from the FMEA for new revised work instructions.
• Don’t forget that the process must operate under certain conditions,
e.g., Ford rates, line speed, manpower, etc., called
process characteristics.
Note: Process function contains both product and process characteristics.

Determine What Can Go Wrong

POTENTIAL

4-16
Determine Failure Modes

• The next step in a PFMEA is to examine each purpose statement for
how it might fail to happen. For each identified purpose, the PFMEA
team must identify what can go wrong, i.e., the Failure
Mode(s). Recall that Failure Modes fall within four groupings that
are useful as thought starters:
No Function
Partial/Over Function/Degraded Over Time
Intermittent Function
Unintended Function
• Potential Failure Mode is defined as the manner in which the
process could potentially fail to meet the process requirements
and/or design intent as described in the Process
Function/Requirements column. Examples of potential Failure
Modes in a PFMEA include part hole off-center, paint blistered, tool
mark on part, etc.
• List each potential Failure Mode for the particular operation in terms
of a component, subsystem, system, or process characteristic. Most
failures will be expressed in terms of the reason an item can be
rejected, e.g., dimension, size, form, location, appearance, etc.


POTENTIAL

4-21
Define Effects
Once the team has identified and listed the potential Failure Modes, it
should next consider the effects of each Failure Mode.
Potential Effects of Failure are defined as the effects of the Failure Mode
on the customer(s). The customer(s) in this context could be the next
operation, subsequent operations or locations, the dealer, and/or the
vehicle owner. Each must be considered when assessing the potential
effect of a failure.
It is a natural tendency to go to Causes first, however determining Effects
first helps determine which root causes need to be determined. This
prioritizes which Failure Modes the team should consider for
Recommended Actions in Step 1

Effects of Failure
• Operator safety
• Next user
• Downstream users
• Machines/equipment
• Vehicle operation
• Ultimate customer
• Compliance with government
regulations
4-22
Effects of Failure
Identify the consequences of each Failure Mode for:
• Operator safety
• Next user
• Downstream users
• Machines/equipment
• Vehicle operation
• Ultimate consumer
• Compliance with government regulations
For a PFMEA, downstream users can include an assembly operation/plant
or a service (dealer) operation.
Place all effects for the Failure Mode being analyzed in one field or box.
Note: All error states from the P-diagram need to be included in the
Failure Mode Effects column of the FMEA.
Caution: A PFMEA that does not list product functional effects or end
customer effects is not complete or accurate.
Examples of Potential Effect(s) of Failure

Describe the effects of the failure in terms of what the customer(s) might
notice or experience. For the end user, the effects should always be
stated in terms of product or system performance, such as:
• Noise
• Rough
• Erratic operation
• Excessive effort
• Inoperative
• Unpleasant odor
• Unstable Operation
• Repairs Leaks
• Customer dissatisfaction
If the customer is the next operation or subsequent
operation(s)/location(s), the effects should be stated in terms of
process/operation performance, such as:
• Cannot fasten
• Does not fit
• Cannot bore/tap
• Does not connect
• Cannot mount
• Does not match
Caution: If the Failure Mode could affect safe vehicle operation, or result
in noncompliance with government regulations, then enter an appropriate
statement. For example, if there is an adverse effect on an environmental
regulation, enter "May not comply with government regulation XYZ."

Process FMEA - Severity

POTENTIAL

4-23
Severity
• Once the Effects have been documented, they need to be allocated
a Severity rating.
• Severity is linked to the effect of failure, and each effect identified in
the list must be assigned a Severity rating. These should be noted
in parentheses following each effect.
• Once all Severities have been identified in the Effects column using
the Severity Rating Table, the highest Severity is written in the
Severity column.

Suggested Severity
Evaluation Criteria
Effect Criteria: Severity of Effect Ranking
Hazardous May endanger machine or assembly
Without operator … noncompliance with 10
Warning government regulation … without warning
Hazardous May endanger machine or assembly
With Warning operator … noncompliance with 9
government regulation … with warning
Very High Major disruption to production line. 100%

… may have to be scrapped ... vehicle/ 8
item inoperable
None No discernible effect or no effect

1
4-24
Severity Ranking Table

Unlike DFMEA, there are two criteria for the Severity Rating Table in
PFMEA. Since error in Process can affect product/customer and/or the
process (manufacturing/assembly) itself, there are two columns for
Severity.
• The first column deals with Product or Customer Effects and the
criteria are the same as DFMEA.
• The second deals with Process or Manufacturing and Assembly
Effects. Examples of such effects are injuring plant operators and
scrapping parts.
The differences need to be noted as the same numerical value for
Severity may mean two different things. The Classification for
customer/product related effects are and SC and require Special
Controls. Classification for process related errors are HI and OS and do
not require Special Controls

PFMEA Path/Step 1 Actions

POTENTIAL

Recommended Actions for Path/Step 1

After ranking Severity, the team must focus on the highest Severity. The
team should try to recommend actions for severity ratings of 9s and 10s to
eliminate the Failure Mode.
For Customer Effects, Severity ratings of 9 or 10 are identified as Critical
Characteristics, designated by an inverted delta ( ) in the Classification
column.
For Manufacturing/Assembly Effects, Severity ratings of 9 or 10 are
identified as Operator Safety (OS) in the classification column. This is
summarized in this chart. Corrective actions should first be directed at the
highest ranked concerns and critical items.
Appropriate actions to consider to eliminate Failure Mode or reduce
Severity include actions such as changing the process if operator safety is
involved.
It is important at this point to assign who will perform what action and
when. If these actions do not eliminate the Failure Mode, continue with
the analysis in Step 2.
Note: In the DFMEA module, Special Characteristics were discussed
next. They will be discussed for PFMEA later in this module.

Process FMEA Path/Step 2

POTENTIAL

What can be done?

• Design Changes
• Process Changes
• Changes to
What How often Standards,
are the does it Procedures, or
Cause(s)? happen? Guides
What can go wrong?

• No Function
• Partial/Over
Function/Degraded
Over Time
• Intermittent
Function
• Unintended
Function
4-26
Process FMEA Path/Step 2

According to the Working Model, the team should move through Step 2 for
all Failure Modes that still exist after completing Step 1. Step 2 in a
PFMEA consists of:
• Identifying Causes
• Rating the Occurrence for each Cause
• Defining Recommended Actions for high criticality (S x O)
• Indicating the appropriate characteristic designation in the
Classification column
Note: Use of a P-Diagram is recommended for PFMEA, whereas it is
required for DFMEA

Assumptions for Cause

Two Assumptions for Cause ...
• Assume in-coming parts are correct,
what would cause the operation to fail in
this manner?
• What incoming sources of variation
could cause the operation to fail in this
manner?
4-31
Find Potential Causes

Potential Cause of failure is defined as how the failure could occur,
described in terms of something that can be corrected or can be
controlled.
Remember, potential Causes of Failure are an indication of weakness, the
consequence of which results in the Failure Mode.
When brainstorming potential Causes, there are two assumptions to begin
with. These two assumptions are not mutually exclusive, but each must
be considered sequentially.
Assumption 1: Incoming parts/materials to the operation are correct.
Assumption 2: Consider that there are incoming sources of
variation.
The FMEA Handbook assumes a one-to-one correlation between a Cause
and its resultant Failure Mode: i.e., if the Cause occurs, then the Failure
Mode occurs.

Process FMEA -- Causes

POTENTIAL

Failure
Mode 1
Function
1
Failure
Mode n
WHY?
Function
2
Function
M E P E M
n
Causes
As in DFMEA, to identify Causes, use the Ishikawa "Fishbone" diagram. It
may help to look for the causes in terms of Materials, Environment,
People, machines (Equipment), Methods (MEPEM).
Brainstorm potential Cause(s) of each Failure Mode by asking:
• What could cause the item to fail in this manner?
• What circumstance(s) could cause the item to fail to perform its
function?
• How could the item fail to meet its engineering specifications?
• What could cause the item to fail to deliver its intended function?
• How could interacting items be incompatible or mismatched?
What specifications drive compatibility?
• What information developed in the P-diagram and characteristic
matrix may identify potential Causes?
• What information in the boundary diagram may have been
overlooked and which may provide causes for this Failure Mode?
• What can historic 8Ds and FMEAs provide for potential Causes
For all Failure Modes with a Severity of 9 or 10, root causes must be
listed. However, do not list "operator error" or "machine malfunction" —
these are too general.

Could result in Effect
Failure
Mode Due to
Cause
B-25
Confusing Cause with Effect

The sentencing technique is the same as for DFMEA.
• State the Failure Mode.
• Ask "What could that Failure Mode result in?"
The answer is the EFFECT.
• Ask "What could that Failure Mode be due to?"
The answer is the CAUSE.
Asking these questions will help confirm that Cause relates back to Failure
Mode, not back to effect.
As you move through the development of a PFMEA, you will notice that
the same event may take on different definitions. What is a Failure Mode
in one operation can be a cause in a later operation.
For example, if OP 10 in a process is to drill a hole to X depth, one Failure
Mode might be that the diameter of the hole is too small. In a later
operation where we secure Part B to this part with a bolt, one Cause for
not securing the parts might be that the hole is too small.
Using the correct sentencing technique will help differentiate Failure Mode
from Cause and from Effect.

Process FMEA -- Occurrence

POTENTIAL

4-34
Occurrence
The next step in Step 2 is to determine the Occurrence rating for each
cause.
• Occurrence is the likelihood that a specific cause/mechanism (listed
in the previous column) will occur. The likelihood of occurrence
ranking number has a relative meaning rather than an absolute
value. Preventing or controlling the causes/mechanisms of the
failure mode through a design or process change is the only way a
reduction in the occurrence ranking can be effected.
If the Occurrence of the Cause cannot be estimated, then estimate the
possible Failure rate. The Failure rate can be based upon historical
manufacturing and assembly Failure rates experienced with similar or
surrogate parts. If available from a similar process, statistical data should
be used to determine the Occurrence ranking. In all other cases, a
subjective assessment can be made by utilizing the word descriptions in
the left column of the table, along with any historical data available for
similar processes.
Caution: Consider existing process controls and/or methods that are
intended to prevent, or reduce, the occurrence of the Cause of the Failure
Mode. Preventive controls do not detect.

Suggested Occurrence Evaluation Criteria
Probability of Ranking
Likely Failure Rates
Failure
Very High: > 100 per thousand pieces 10
Persistent failures 50 per thousand pieces 9
Low: Relatively few 0.5 per thousand pieces

failures 33
Remote: Failure is ≤ 0.01per

0.01 thousand pieces 1
unlikely
4-35
Occurrence Rating Table

• Occurrence in PFMEA is the same as it is in Design FMEA.
• Once Occurrence has been determined for each Cause, the need
for a Significant Characteristic (Severity of 5-8 and Occurrence of 4-
10) needs to be determined.
• Question any Occurrence of 1 – do you have proof that the
occurrence is this low?
• If Occurrence is 4 -- 10 on Causes with Severities of 5 through 8,
then a root cause must be determined

Recommended Actions
POTENTIAL

Recommended Actions
• In DFMEA classifications for any special characteristics were
considered next -- it will be covered in PFMEA later in this section
• The ranking of the Severity and Occurrence ratings results in a
Failure Mode/first level Cause combination that is ranked higher
relative to other combinations
• Once Cause and Occurrence have been determined,
Recommended Actions should be considered. For the highest
Criticality (S x O) Failure Mode/Cause combinations, the FMEA
team should determine if an appropriate Recommended Action can
be taken.
• Remember to designate who is responsible for what action and
when it should be completed. Aim for prevention!

Process FMEA - Path/Step 3

POTENTIAL

Mode Failure Completion Date Taken
What can be done?

• Design Changes
• Process Changes
• Changes to
Standards,
Procedures, or
Guides
What can go wrong?

• No Function
How can
• Partial/Over this be
Function/Degraded prevented
Over Time and
detected?
• Intermittent
How good
Function
is this
method at
• Unintended
detecting
Function
it?
4-37
PFMEA -- Path/Step 3
For all Failure Modes that still exist after completing Step 2, the FMEA
team needs to complete Step 3, which consists of the following steps:
• Identify Prevention controls to reduce occurrence.
• Identify Detection controls (e.g., tests, inspection) to address Failure
Modes and Causes.
• Assess the effectiveness of the Detection controls on a scale of
1 to 10.
• Defining Recommended Actions
Remember that Steps 1 and 2 must have been completed prior to moving
on to Step 3

Process Controls
Type 1 Prevention: Prevent the
cause/mechanism or failure
mode/effect from occurring or
reduce their rate of occurrence
Type 2 Detection: Detect the
cause/mechanism and lead to
corrective actions
4-38
Process Controls
In design we referred to verification; in process we focus on process
control -- the two are very different
Current Process Controls are descriptions of the controls that either
prevent to the extent possible the failure mode/cause from occurring or
detect the failure mode or cause should it occur. These controls can be
process controls such as error/mistake proofing or Statistical Process
Control (SPC), or can be post-process evaluation. The evaluation may
occur at the subject operation or at subsequent operations.
There are two types of process controls/features to consider:
• Type 1: Prevention
Prevent the Cause/Mechanism or Failure Mode from occurring,
or reduce their rate of Occurrence
Example : operator training; preventative maintenance; limit
switch; thermocouples
• Type 2: Detection
Detect the Cause/Mechanism and lead to corrective actions
Example : go/no go gauges; visual inspection; pressure decay
tests

Process FMEA -- Detection

POTENTIAL

4-41
Detection
Once prevention controls (Type 1) have been recommended, we can
move on to the Detection step of Step 3. Detection controls (Type 2) are
generally inspections conducted in the plant to assure that no defective
part leaves the plant.
Detection is the rank associated with the best Type 2 process control
listed in the previous column. Detection is a relative ranking, within the
scope of the individual FMEA. In order to achieve a lower ranking,
generally the planned process control has to be improved.
Note: In order to achieve a lower ranking, generally the planned process
control has to be improved.

Suggested Detection Evaluation Criteria

Detection
Criteria A B C Suggested Range of Detection Methods Ranking
Almost Absolute certainty of non- Cannot detect or is not checked.

Impossible Detection. 10
Very Remote Controls will probably not Control is achieved with indirect or random checks
detect. only. 9
Remote Controls have poor chance of Control is achieved with visual inspection only.
Detection. 8
Very Low Controls have poor chance of Control is achieved with double visual inspection
Detection. only. 7
Low Controls may detect. Control is achieved with charting methods, such
as SPC {Statistical Process Control}. 6
Moderate Controls may detect. Control is based on variable gauging after parts
have left the station, OR Go/No Go gauging
performed on 100% of the parts after parts have 5
left the station.
Moderately Controls have a good chance Error Detection in subsequent operations, OR

High to detect. gauging performed on setup and first-piece check 4
(for set-up Causes only).
High Controls have a good chance Error Detection in-station, OR error Detection in
to detect. subsequent operations by multiple layers of
acceptance: supply, select, install, verify. Cannot 3
accept discrepant part.
Very High Controls almost certain to Error Detection in-station (automatic gauging with
detect. automatic stop feature). Cannot pass discrepant 2
part.
Very High Controls certain to detect. Discrepant parts cannot be made because item
has been error proofed by process/product 1
design.
Inspection Types:
A. Error Proofed
4-44 B. Gauging
C. Manual Inspection
Note: Shaded areas indicate the inspection type(s) used for a given rank.
Detection Rating Table

The process detection rating table is similar to the design detection rating
table. When several controls are listed for a particular failure mode:
• Estimate a detection rating for each control.
• Select the best (lowest) rating.
• Optionally, if all controls will be used, determine a composite
detection rating based on the accumulated controls.
• A detection of 1 should be considered as guaranteed.
• New guidelines have been added by SAE to better define the
detection ratings. Clearly, Error Proofing (A) is preferred to Gauging
(B) and Gauging (B) is preferred over Manual Inspection (C). For
example, single visual inspection should not be rated lower (better)
than 8.
• If no detective control is listed, or the team cannot reach consensus
on the detection rating, enter a rating of 10

Assessing Risk
• Severity (S)
• Severity X Occurrence (SO = Criticality)
• Severity X Occurrence X Detection

(SOD = RPN)
Assess Risk
When ratings have been assigned and entered into the Severity,
Occurrence and Detection columns, actions are then prioritized
accordingly
• An effect of a Failure Mode with Severity rated 9 or 10
• The ranking of the Severity and Occurrence ratings results in a
Failure Mode/first level Cause combination that is ranked higher
relative to other combinations (criticality)
• A Failure Mode/Cause/Process Control method combination has a
higher RPN ranking than other combinations
RPN = Severity x Occurrence x Detection
• RPN values are used to rank risk order
• The RPNs have no value or meaning in themselves
• For all Severities of 9 or 10 the team must drive to root cause
It is an unsound practice to establish “threshold RPN values” to
characterize actions
• Each RPN value must be evaluated on its own

Recommended Actions
POTENTIAL

4-46
Recommended Actions
• For the remaining Failure Mode–Cause combinations that have not
had any action(s) already listed, the team should determine if an
appropriate Recommended Action can be taken. Typically, the
Recommended Actions at this stage of the FMEA will improve the
Detection rating.
When recommending actions, corrective actions should first be
directed at the highest ranked concerns and critical items. The team
should not be interested specifically in increasing detection methods;
rather, it should aim for prevention.
• The FMEA team should prioritize actions based on those Failure
Modes:
With Effects that have the highest Severity (S) ratings
With Causes that have the Severity times Occurrence
(Criticality or S x O) ratings
With the highest RPNs (S x O x D)
• This is the same as addressing Severity (S) first, Occurrence (O)
second, and Detection (D) third. Again, it is important to re-
emphasize that establishing threshold values for RPN is not
recommended.
• For each action, be sure to set a projected completion date and
assign a specific person to the task.

Actions Taken
POTENTIAL
FAILURE MODE AND EFFECTS ANALY SIS
Item C O C urrent D A ction R esults

l Potential c D esign e
Potential Potential Cause(s)/ R ecom m ended R esponsibility
Failure Effect(s) of S a c C ontrols t R. & Target Actions S O D R.
e s M echanism (s) u – P revention e P. Action(s) e c e P.
M ode Failure of Failure C om pletion D ate Taken
Function v s r – D etection c N. v c t N.
Action Results
Responsibility & S O DR
TaFMEA Handbooket
Actions e c e P
Action(s) Completion Date t N
e
c
Action Results
Actions S O D R
Taken e c e P
v c t N
4-48
Actions Taken
• After an action has been implemented:
Enter a brief description of the actual action and effective date.
Re-rate any of the Severity, Occurrence or Detections based
on the actions taken and enter into the revised Severity,
revised Occurrence or revised Detection columns
• The PFMEA team leader is responsible for implementing a follow-up
program to ensure all Recommended Actions have been adequately
addressed.
• The PFMEA team leader is responsible for updating the Process
FMEA. The FMEA is a living document and should reflect the latest
item level and the latest relevant actions.
• A thorough Process FMEA will be of limited value without positive
and effective actions to prevent failures

Special Characteristics
Special Characteristics involve those
products and/or process characteristics
which affect ...
• Vehicle or process safety
• Compliance with government
regulations
• Customer satisfaction
6-1
• All products and processes have features described by
characteristics that are important and need to be
controlled. However, some characteristics, called Special
Characteristics, require extra efforts called Special Controls to
minimize the risk of potential adverse consequences. Special
characteristics involve those product and/or process characteristics
that affect vehicle safety, compliance with government regulations or
major customer satisfaction
Manufacturing process must be controlled to ensure products
will meet all engineering requirements
• In the DFMEA module, we covered potential Special
Characteristics. In a PFMEA, potential Special Characteristics are
confirmed as special only after the ability to detect them is
established (Step 3), and, therefore, this is performed as part of Step
3.

CRITICAL: Requirements that affect
compliance with government regulations
or safe vehicle / product function and
require special controls (S = 9 or 10)
SC SIGNIFICANT: Product and/or test

requirements important for customer
satisfaction, summarized on Control Plan and
require special controls
(S = 5 to 8, O > 3)
6-5
Types of Characteristics
All products and processes have features described by characteristics
which are important and need to be controlled
There are four types of special characteristics
Critical Characteristics:
• Critical characteristics are those product and/or process
requirements that affect compliance with government regulation or
safety of vehicle/product function or process. They require special
actions/controls that must be listed on a Control Plan. Product or
process requirements can include dimension, specification, tests,
processes, assembly sequences, tooling, joints, torques, and other
characteristics. Special actions/controls can include manufacturing,
assembly, supplier, shipping, monitoring, and/or inspection.
• A DFMEA indicates the potential of Critical Characteristics. A
PFMEA confirms that a characteristic is Critical by the need for the
implementation of Special Controls. The design responsible
organization must sign off on all Control Plans as part of the PFMEA
team.
• Critical Characteristics are designated by an inverted delta ( ) in
the Classification column of a PFMEA form.

Significant Characteristics:
• Significant Characteristics are those product requirements that are
important for customer satisfaction and for which Quality Planning
actions (i.e., Special Controls) must be summarized on a Control
Plan.
• These are Failure Modes with a Severity Rating of 5 to 8 (inclusive)
with an Occurrence greater than or equal to 4 related to an Effect on
the product.
• A DFMEA indicates potential Significant Characteristics. A PFMEA
confirms that a characteristic is Significant by the need for the
implementation of Special Controls. The design responsible
organization must sign off on all Control Plans as part of the PFMEA
team.
Significant Characteristics are designated by "SC" in the
Classification column of a PFMEA form.
Note: Critical or Significant Characteristics are related to product
requirements that can include key methods of assembly requirements
driven from design performance. Both of these types can be described by
parameters from design.

OS OPERATOR SAFETY: Related to process
parameter that does not affect product but may
have an impact to safety, or government
regulation applicable to process operation
HI HIGH IMPACT: Product or process
characteristics when outside of specification
tolerance severely affect the operation of
process itself or subsequent operations (does
not require special controls)
6-6
Types of Characteristics, continued

The remaining two Special Characteristics are:
Operator Safety Characteristics:
• Operator safety related characteristics are characteristics related to
a process parameter that does not affect the product but may have
an impact on the safety or governmental regulations applicable for
the process operation (e.g., Occupational Safety and Health
Administration (OSHA) requirements, Ford Health and Safety
Specifications, etc.).
• These are Failure Modes with a Severity rating of 9 or 10 due to an
effect on the process or process operator.
• Operator Safety Characteristics are designated by "OS" in the
• These characteristics should be included on a safety sign-off.

High-Impact Characteristics:
• High-Impact Characteristics are related to a process parameter that
does not affect the product but may have an impact on the operation
of the process itself or subsequent operations.
• These are Failure Modes with a Severity rating of 5 to 8 and
Occurrence of 4 to 10.
• High-Impact Characteristics are designated by "HI" in the
• These characteristics are used to emphasize the severity of the
impact to preclude future misbuilds.

Where To Find Generic Special Characteristics

• The Critical Characteristic folder is located at www.ekb.ford.com
(EKB Home > Product Development > Quality & Reliability) which is
the corporate repository for the Critical Characteristics identified for
all the vehicle systems. The Critical Characteristic list stored in this
folder is a minimum mandatory list for the related systems.
Additional Critical Characteristics should be added per the programs
needs.
• Program teams having concerns about individual items on the list
must contact the affected Campaign Prevention Specialist (CPS) or
Tech Club leader, and follow the change control process established
in FAP 03-111.

Special Controls
Above normal and customary which drive
process Detection rating to 1 ...
• Interim control directed by
manufacturing
• Aimed at detecting and containing a
Special Characteristic-related defect
prior to shipment,
• Documented on Control Plans
6-7
Special Controls
• Special controls are those manufacturing and assembly process
methods, administrative actions, techniques and tests
Beyond the normal control required by the Ford/GM/Chrysler
QS-9000 (Quality System Requirements) Manual
• Special controls are implemented to ensure that products affecting
safe vehicle function, regulatory compliance or major customer
satisfaction will be produced and assembled to meet engineering
requirements
• If special characteristics are required, they are documented in the
Recommended Actions column of the PFMEA and also on the
control plan

Section Summary
• PFMEA Paths/Steps
1, 2 & 3
• Special
% Characteristics
% &" " ( ('

1. Which of the following is NOT part of setting the scope of a PFMEA?

Creating function tree
Creating a macro flow diagram
Identifying the boundary
Creating a micro flow diagram
2. All of the Severity ratings for an Effect set (i.e., all of the effects that go
with one Failure Mode) are listed in the Severity column of the FMEA
form.
A. True
B. False
3. In Step 1 of a PFMEA, for what characteristic(s) should the team first

recommend actions?
The characteristic(s) with the highest RPN
The characteristic(s) with the highest Criticality
The characteristic(s) with a Severity of 9 or 10
The characteristic(s) which can be revised fastest to eliminate Failure
Mode
4. Match the following assumptions under which to brainstorm Causes

with the correct type of FMEA — DFMEA (D) or PFMEA (P)
The design may include a deficiency that may cause unacceptable
variation in the manufacturing or assembly process.
The item is manufactured/assembled with engineering
specifications.
Consider that there are incoming sources of variation.
Incoming parts/materials to the operation are correct.
5. If an Effect of a Failure Mode has a Severity rating of 9 or 10 or a

Severity rating between 5 and 8 (inclusive) and an Occurrence rating
greater than or equal to 4, what must the team do?
Place a YC in the Classification column.
Drive through to an Occurrence rating of 2.
Ask the Design team to redesign the item.
Determine the root cause

4. Managing FMEAs

Managing FMEA Meetings

• Circulate all relevant information ahead
of meeting
• Book meetings well in advance and
schedule adequate breaks
• Clearly define objectives
• Establish / adhere to effective roles
• Communicate effectively

Managing FMEAs
• Project manage to complete agreed
actions
• Re-issue a revised FMEA
• Be sure facility is conducive to the work
• Arrange for a facilitator if possible

5. Concept FMEA
• Definitions
• Functional Boundary
Diagrams
• Differences in
)
– Path/Step 1
– Path/Step 2
– Path/Step 3
• Other FMEAs
Concept FMEA
The course has dealt with Design and Process FMEA thus far:
• The third type of FMEA is the Concept FMEA
• Even though we are presenting it here, it would be the first to be
done in actual practice
• Section 3 in the FMEA Handbook covers CFMEA in detail
• Prior to 1994 Concept FMEA was called System FMEA

Concept FMEA
System
Design
Design/ FMEA Sub-System
Process
Concept Component
FMEA
System
Process Assembly Sub-System

Component
FMEA System
Manufacturing Sub-System
Component
Machinery
FMEA
Concept FMEAs
• As indicated in the introduction, Concept FMEA is Ford specific, and
is not covered under SAE J1739.
• Concept FMEA is used to analyze concepts at early stages
• Very rare (<4%) of all FMEAs – fundamentally new ideas
• The scope of a Concept FMEA can be a Design Concept at system,
subsystem, or component level, or a manufacturing or assembly
Process Concept FMEA.
• Typically performed for systems and subsystems
• Can also be performed on components
Focuses on potential Failure Modes associated with the
functions of a concept proposal caused by design deficiencies
or design decisions that introduce variability
Includes interaction of multiple systems and the interaction
between elements of a system at concept stages
• Concept FMEAs are performed prior to the availability of hardware,
between <KO> and <SI>.
• Most Concept Design FMEAs are performed like "normal" Design
FMEAs. Most of the Concept Process FMEAs are performed like
"normal" Process FMEAs.

Concept FMEA
New forward illumination
Design
Design/ system
FMEA
Process Headlight without bulb
Concept
FMEA New aiming element
Process
Electrostatic painting
FMEA
of lighting housing
Machinery New method of creating

FMEA holes
CFMEA
• The technique for developing CFMEAs is similar to that of
DFMEA and PFMEA, so in this section only the differences will be
pointed out
• Note that this walk through is for both Concept Design and
Concept Process FMEAs

Concept FMEA -- Team

Facilitator
Representatives
from:
Advanced ...
• Service
• Component
Engineer • Specialists
• Manufacturing • Suppliers
Engineer • System Testing
• Quality Engineer
• Marketing Rep
CFMEA Team
• The team is similar to the DFMEA team, with the exception that
most members are from advanced activities.
• To achieve early buy-in, engineers downstream from these activities
should be informed of the progress of the CFME

Functional Boundary Diagram

Electrical Power Body
User Input Light

Optic Light
Mechanism Source
Auto Aiming
Mechanism
Electrical Power
Functional Boundary Diagram

• A functional boundary diagram is an important and valuable tool for
creating a CFMEA, especially because hardware is not available at
this stage of the program.

Concept FMEA -- Path/Step 1

POTENTIAL

What What can be done?

How bad
are the • Design Changes
is it?
Effect(s)?
• Process Changes
What are the
Functions, • Special Controls
Features or
Requirements? • Changes to
Standards,
Procedures, or
Guides
What can go wrong?

• No Function
• Partial/Over
Function/Degraded
Over Time
• Intermittent
Function
• Unintended
Function
Path/Step 1 CFMEA
A CFMEA is similar to a DFMEA. However, there are differences. Some
differences are listed below:
• Measurables for the Functions may not yet be known, although the
unit of measure may be known. Often then, measurables in the first
iteration of the Design CFMEA will be TBD cycles, TBD ohms, etc.
In a Process CFMEA many process parameters may not be known
• Potential Failure Mode — There may be less detail available in this
field in a Concept Design FMEA and a Concept Process FMEA than
in a "normal" Design of Process FMEA.
• The Classification column is not normally used for Concept Design
or Concept Process FMEAs. In the early stages of development,
hardware is not defined. Therefore, until hardware is defined,
potential Special Characteristics cannot be identified because
Special Characteristics are hardware-specific.
After hardware is defined, a Design FMEA can be used to
identify potential Special Characteristics or a Process FMEA to
confirm Special Characteristics.

• Recommended Actions - CFMEA provides more opportunity to take

actions in Path/Step 1 because it is so early in the development
cycle
Path/Step 1 changes are typically major design or process
changes
Changes tend to improve robustness
Recommended actions also include updates to design
guidelines, WCR, SDS, machinery specifications, maintenance
schedules, process flows, etc.


POTENTIAL

What can be done?

• Design Changes
• Process Changes
• Changes to
Standards,
What How often
are the does it Procedures, or
Guides
Cause(s)? happen?
What can go wrong?

• No Function
• Partial/Over
Function/Degraded
Over Time
• Intermittent
Function
• Unintended
Function
Path/Step 2 CFMEA
A Concept FMEA is similar to a DFMEA. However, there are differences.
Some of the differences are listed below:
• It is rarely possible to provide root cause in this field in a CFMEA
because hardware has not been defined.
• However, analyzing the interfaces and interactions is especially
important. A major benefit of the Concept FMEA is the identifying of
potential Failure Modes caused by interactions that must be
addressed before the concept can be approved and implemented.
• CFMEA often has Occurrence of 10, because the rating cannot be
estimated.
• If an Occurrence rating of 10 is entered because the rating cannot
be estimated, a Recommended Action should be immediately
enforced. The first priority of the action should be to eliminate the
Cause.
There will be NO classification, because hardware is not yet
defined
Cannot have part characteristic level detail in Cause, therefore no
special characteristics


POTENTIAL

What can be done?

• Design Changes
• Process Changes
• Changes to
Standards,
Procedures, or
Guides
What can go wrong?

• No Function
How can
• Partial/Over this be
Function/Degraded prevented
Over Time and
detected?
• Intermittent
How good
Function
is this
method at
• Unintended
detecting
Function
it?
Path/Step 3 CFMEA
A Concept FMEA is similar to a DFMEA.
• Examples of controls used include engineering analysis tools (e.g.,
load calculation, finite element analysis), tests, design review, or
other advanced inspection or control methods. Specific examples of
methods may include some of the following:
Computer simulation
Mathematical models
Breadboard tests
Laboratory tests on surrogate elements
• In a Concept FMEA, there may be instances of "no detection at this
time," which requires a rating of 10 to be entered in the Detection
column. If a Detection rating of 10 is entered, a Recommended
Action should also be listed to identify and implement a detection
method.

• Typical actions may include:

Modify proposal to eliminate Failure Mode or reduce rate of
Occurrence
Add redundant system that allows system operation to
continue at same functional level
Provide other modes of operation that allow proposed
operation to continue at same, or at a degraded functional level
Add built-in detection devices to alert customer to take action
that will prevent a failure mode, or reduce rate of Occurrence
Specify certain type of material

FMEA -- Types
Design Concept
FMEA
Environment
Machinery
Software
Process Concept
FMEA
Service
Environment
Other FMEAs
The course has dealt with Design, Process and Concept FMEA thus far,
but other types of FMEAs are sometimes discussed
• FMEAs can be applied to anything:
Food services, medical devices, software, machinery, etc.
Machinery, for example, would be interested in analysis to
enhance reliability, maintainability and operator safety
It is a design FMEA which might use different occurrence or
detection tables
It is considered an “application” of a DFMEA
• Design FMEA and Process FMEA, as well as Machinery FMEA as
an application are standardized by Ford’s adoption of SAE J1739.
FMEAs are referenced in corporate procedures including FPDS and
FPS

Other FMEAs -- Working

Model POTENTIAL

Other FMEAs and Working Model

• Appendix E in the FMEA Handbook includes the following FMEA
applications:
Machinery FMEA
Environment FMEA
Software FMEA
Attribute FMEA
• Regardless of the topic of an FMEA, the thought processes of the
working model will assist with the analysis
• Just as an FMEA is a living document, the application of FMEAs is a
living process

Section Summary
• Definitions
• Functional Boundary
Diagrams
• Differences in ...
) – Path/Step 1
– Path/Step 2
– Path/Step 3
• Other FMEAs

Evaluating FMEAs
• What to look for
• Identify weaknesses
in an existing FMEA
* + ! ,
"
Evaluating FMEAs
• The purpose of the course is to prepare FMEA team members. One
thing that team members will be expected to do is to evaluate other
FMEA (as well as their own)
• Use the FMEA you brought with you to go through the review points

Intentionally Blank

FMEA Header
• Use correct FMEA form
• Include accurate dates, including
revisions
• Identify process step /
component name / system name, etc.
• Identify all team members
• FMEA number
• Who prepared FMEA
• No blank fields

FMEA Checklist
Note “P” refers to Process FMEA and “D” refers to Design FMEA.
For a Concept FMEA, use the Design or Process checkbox column
that is appropriate for the Concept proposal format.
Inputs P D
Is the correct form used?
Are all the functions listed?
Is a comprehensive boundary diagram evident and
attached to the FMEA?
Was a process flowchart prepared and attached?
Has a comprehensive P-diagram been created and
attached to the FMEA?
Has a cross-functional FMEA team been formed?
Has an interface matrix been created and attached to the
FMEA?
Has a characteristic matrix been created and attached to
the FMEA?
Is there evidence that background information has been
checked?
Are the part characteristics produced, or evaluated, at each
operation listed on the process flow? (Optional, but
preferred)
Are the sources of incoming variation identified, where
applicable on the process flow? (Optional, but preferred)
Header P D
Information
Are all the applicable entries in the header completed?
Continued

Function / Purpose
• Written as verb-noun-measurable
construction
• Include technical specifications and
engineering requirements, process
requirements stated
• Describe any special conditions
• Identify all Functions
Potential Failure Mode

• Failure Modes address: no, Partial/Over
Function/Degraded Over Time, intermittent, and
unintended
• PFMEA: describes Failure Mode as what product
would be rejected for
• No Causes or Effects listed as Failure Modes
• Associate each failure with a Function special
conditions identified for similar Failure Modes
• Question any Function with only 1 Failure Mode

FMEA Checklist, Continued
Description/ P D
Purpose/
Function Are all functions listed using the functional (not hardware)
approach?
Is the concept function, design intent or purpose of each
operation clear and complete?
Are functions or purposes described in verb/noun/
measurable format?
Are the functions or purpose measurable?
Are the process characteristics at each operation listed?
Are all regulatory requirements considered and addressed
in the Function/Purpose column?
Are functions for all customers including service, assembly,
and manufacturing included?
Failure Modes P D
Are failure modes identified as loss of function using the
4 Thought Starters? (Partial/intermittent, over/degraded,
unintended)
Do the failure modes relate directly to the functions?
Are process failure modes listed in terms of “What would
the part be rejected for” or as a negative impact on process
capability or integrity?
Do the failure modes list part characteristics produced at
the operation for which the part would be rejected if the part
characteristic were outside the specification limits?
Do failure modes include inspection/testing operations; i.e.,
accepting bad part or rejecting a good part?
If a failure mode adversely affects an operation downstream:

• Is the failure mode listed as a cause for the downstream
operation?
• Is the downstream failure mode identified?
Continued

Potential Effect(s) of Failure

• All Effects considered, including
customer, government, vehicle?
• Does Effect relate to Failure Mode?
• Any Causes incorrectly listed?
• Note the Severity behind each Effect or
behind the worst for historic purposes
• “Correct” Effect phrasing — clear,
concise, accurate?
Severity
• Government regulations or safety for 9
and 10
• Question any rating of 1
• Only highest severity ranking entered
for each Failure Mode

Failure P D
Effects
Are effects on safe vehicle operation and government
regulations considered?
Are effects on part, next higher assembly, system, the
vehicle, machines, equipment and the customer
considered?
Are all effects listed in one box or field?
Is there evidence that the P-diagram has been used to
determine effects?
Is the severity ranking for the worst effect noted? (or,
optionally, for all the effects?)
Severity P D
Rating
Is there one severity rating per failure mode?
Are severity ratings of 9 or 10 only and always shown
when the effects include regulatory non-compliance or
hazard?
Are ratings based upon the most serious effect of the failure
mode?
Do the ratings for vehicle/consumer effects agree with the
ratings shown in Design FMEA?
Continued

Classification
• Classification marks for each special
characteristic
– Are they correct?
• DFMEA -- YC and YS only
• PFMEA -- confirm s, SCs, OSs and
HIs
• Verify special controls for each and
SC
Potential Causes/Mechanism(s)
Failure
• Causes with government / safety effects (9- 10) are
at root level? Note part characteristic if appropriate
• Failure Modes have multiple Causes listed
• Both assumptions used in development of Causes
• Any Effects incorrectly listed?
• DFMEA -- no “operator error” or “machine
malfunction” listed
• PFMEA -- no “operator error” or “machine
malfunction” listed especially for significant or
critical characteristics or OS
• Have noise factors been considered?

Classification P D
Are potential Special Characteristics identified?
Are Special Characteristics and their special controls clearly
identified?
Have potential Special Characteristics been communicated
to the process team?
Are Critical Characteristics identified with an inverted Delta
symbol on the Process FMEA?
Are Special Characteristics identified as a process (or part)
characteristic?
Were Special Characteristics and their Special Controls
communicated to the responsible design engineer?
Failure P D
Causes/
Mechanisms Is there evidence that the interface matrix has been used to
determine causes?
Is there evidence the P-diagram has been used to determine
causes?
Are all causes for each failure mode identified?
Are causes in terms of element failure modes or a part
characteristic, where appropriate?
Are causes described in terms of a characteristic that can be
fixed or controlled?
Are process characteristics considered?
Are material or parts incoming to each operation considered?
Are operator actions considered?
Are design deficiencies considered that may induce
manufacturing/assembly variation? (Cause Assumption 2)
Are manufacturing/assembly causes excluded from the
DFMEA (but addressed in Process FMEA)?
Are design causes excluded (but addressed in the Design
FMEA)?
Continued

Occurrence
• Was Occurrence table followed?
• Question any rating of 10 – Does a
rating of 10 have an action?
• Set controls to determine Occurrence
rating
• One rating per Cause
Appropriate Controls Applied

• DFMEA and D-CFMEA controls up-front?
(Early test strategies, not down-stream
production controls
• No process controls on DFMEA
• Detection and prevention mechanisms
identified in correct columns
• Careful consideration given to identifying
specific controls
• Actual, planned controls, not “wished for”
• Prevention methods not rated as Detection

Occurrence P D
Rating
Is there one Occurrence rating per cause?
Are ratings based on the occurrence of the cause?
Do ratings consider the ability of prevention controls to
reduce the occurrence of a failure mode?
Are ratings based on the cumulative number of failures that
could occur for each cause over the proposed life of the
system?
Do ratings of 1 have documentation to support the rating?
Current P D
Controls
Can methods listed detect the causes or failure modes?
Can design controls listed detect the cause(s) of failure
modes before engineering release?
Are manufacturing/assembly detection methods excluded?
Are the controls to be implemented to detect bad parts
listed?
Are both detection and prevention controls properly
identified in the Current Controls column?

Detection
• Verify that visual inspection is not rated
less than 4
• Verify that sampling is not overrated
• Best Detection rating used for more
than one control
• One (best) rating per control set
Risk Priority Number

• One RPN per cause
• Any “threshold” levels being
established?

Detection P D
Rating
Are prevention type controls rated 10 when several controls
are listed?
Was the best (lowest) rating used to provide one detection
per control set?
Are ratings based on the likelihood of detecting the first
level causes (element failure modes) or the failure mode
prior to engineering, manufacturing, or assembly release?
Do ratings of 1 have documentation to support the rating?
Risk Priority P D
Number (RPN)
Are the Risk Priority Numbers calculated?
Does it appear that an RPN threshold strategy has been
incorrectly applied?

Recommended Actions
• Recommended Action taken in priority for each S, or
S X O or RPN
• DFMEA -- Recommended Actions are not process
actions or controls
• DFMEA -- All Recommended Actions point at design
itself
• PFMEA -- Recommended Actions for Special
Characteristics list the Special Controls to be put in
place
• Use of “none” or “none at this time” -- no blanks
• Recommended Action on all “classified” items
Responsibility & Target Completion Date
• Name and date specified for each

Recommended Action
• Not “TBD” or “Ongoing”
• Should be assigned to team member

Recommende P D
d Actions
Are remedial actions considered that reduce the ratings
prioritized by Severity, Occurrence, and Detection?
Are responsibility and timing for the Recommended Actions
listed?
Are actions directed at eliminating causes or reducing the
occurrence of the causes of the failure modes?
Do actions address all potential Critical Characteristics?
Are actions aimed at making the design more robust?
Are the actions listed design actions, not manufacturing/
assembly controls?
Are special manufacturing/assembly controls identified for
Special Characteristics?
Are preventative, instead of detection, actions listed where
appropriate?
Are actions considered to eliminate/reduce the occurrence
of potentially hazardous failure modes, where applicable?

Actions Taken/Revised
Ratings
• Action taken listed only after the action is
completed
• List the action results, not just “completed” or
done
• Dates completed and document reference
numbers may be helpful for historic purposes
• Enter revised ratings when actions taken are
listed – even if there is no rating change
• Consider additional actions if first action was
not successful
Follow Up P D
Was the FMEA updated after Recommended Actions were
implemented?
Did the Process FMEA team determine whether normal and
customary or whether special controls were required for the
identified Critical Characteristics?
Has the FMEA been submitted to the core book?
Has the reliability and robustness checklist been updated?

1. Which of the following is true of a CFMEA?

Focuses on potential Effects and Causes associated with the functions
of a concept proposal caused by design deficiencies or design decisions
that introduce variability
Includes interaction of multiple systems and the interaction between
elements of a system at concept stages
Can only be performed on system, subsystem, and component designs
Is more common than PFMEAs
2. In which step does CFMEA provide more opportunity to take actions?

Step 1
Step 2
Step 3
3. What is the main difference in determining Cause in a CFMEA vs.

PFMEA or DFMEA?
Cause is related to Effect rather than Failure Mode.
You cannot use a fishbone diagram for CFMEA.
The actionable level occurs at the second level.
Cause refers to a deficiency in the concept rather than the hardware.
4. Which of the following FMEAs are standardized for the automotive

industry?
DFMEA
PFMEA
CFMEA
All of the above
A and B only

Course Close
Group Discussion

FOA FMEA Course Notes v1.5 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FOA FMEA Course Notes v1.5 PDF

Uploaded by

Copyright:

Available Formats

FAILURE MODE AND EFFECTS ANALYSIS PARTICIPANT GUIDE

Failure Mode and

FTEP FMEA Version FOA 1.5 02/05 Page 1

Welcome to Failure Mode and Effects Analysis

FTEP FMEA Version FOA 1.5 02/05 Page 2

FTEP FMEA Version FOA 1.5 02/05 Page 3

FTEP FMEA Version FOA 1.5 02/05 Page 4

FTEP FMEA Version FOA 1.5 02/05 Page 5

FTEP FMEA Version FOA 1.5 02/05 Page 6

William Clay Ford, Jr

Introduction to FMEA, continued

FTEP FMEA Version FOA 1.5 02/05 Page 7

FTEP FMEA Version FOA 1.5 02/05 Page 8

• A potential Failure Mode and Effects Analysis (FMEA) is an

FTEP FMEA Version FOA 1.5 02/05 Page 9

FTEP FMEA Version FOA 1.5 02/05 Page 10

FTEP FMEA Version FOA 1.5 02/05 Page 11

FTEP FMEA Version FOA 1.5 02/05 Page 12

FMEA -- Purpose, continued

FTEP FMEA Version FOA 1.5 02/05 Page 13

FTEP FMEA Version FOA 1.5 02/05 Page 14

Best Practice FMEA

Best Practice FMEA

FTEP FMEA Version FOA 1.5 02/05 Page 15

Former FMEA Process

Robustness Tools are not specified

Former FMEA Process

FTEP FMEA Version FOA 1.5 02/05 Page 16

FMEA (with Robustness Linkages)

FMEA (with Robustness Linkages) Process

FTEP FMEA Version FOA 1.5 02/05 Page 17

Process Assembly Sub-System

FTEP FMEA Version FOA 1.5 02/05 Page 18

DESIGN FMEA (DFMEA)

FTEP FMEA Version FOA 1.5 02/05 Page 19

Change Point Approach

FTEP FMEA Version FOA 1.5 02/05 Page 20

• Identifies testing requirements

• Helps determine if hardware

CFMEA Benefits and Uses

FTEP FMEA Version FOA 1.5 02/05 Page 21

DFMEA Benefits and Uses

FTEP FMEA Version FOA 1.5 02/05 Page 22

PFMEA Benefits and Uses

FTEP FMEA Version FOA 1.5 02/05 Page 23

When to When started

When is FMEA Who is FMEA

FTEP FMEA Version FOA 1.5 02/05 Page 24

Who initiates an FMEA?

Who initiates an FMEA?

FTEP FMEA Version FOA 1.5 02/05 Page 25

When can FMEA

When can FMEA documents be discarded?

FTEP FMEA Version FOA 1.5 02/05 Page 26

How is an FMEA documented?

FTEP FMEA Version FOA 1.5 02/05 Page 27

When is an FMEA complete?

FTEP FMEA Version FOA 1.5 02/05 Page 28

Who prepares an FMEA?

Who prepares an FMEA?

FTEP FMEA Version FOA 1.5 02/05 Page 29

Who updates an FMEA?

Who updates an FMEA?