Design FMEA as Per AIAG - VDA

AIAG-VDA FMEA Workshop

Course Objectives
• Explain the difference between DFMEA and SFMEA.
– Demonstrate an ability to properly construct a Boundary (Block) Diagram.
• Explain the use of an inter-relationship matrix to identify relationships
between components and higher level systems.
• Demonstrate an ability to properly and effectively complete all items in the
DFMEA process.
– Identify Functions, Requirements, Failure Modes, Causes and Controls and
properly enter the information in a DFMEA.
• Explain how a DFMEA can help identify effects and severity for a process
failure mode.
• Explain how to prioritize continual improvements.

2
Agenda
• Course Outline and Overviews
• Chapter 1 – Introduction to FMEA
• Chapter 2 – How to Develop FMEA
• Chapter 3 – Design FMEA Requirements
– Group Activity 1: Boundary Diagram
– Group Activity 2: Structure Analysis
– Group Activity 3: Function Analysis
• Chapter 4 – Developing the Design FMEA
– Group Activity 4: Potential Design Failure Modes
– Group Activity 5: Failure Net (Effects  Failure Mode  Cause)
– Group Activity 6: Design Controls
– Group Activity 7: Risk Analysis (Indices and Action Plan)
• Chapter 5 – Test Planning and Reporting
• Chapter 6 – Effectively Using the AIAG-VDA FMEA Approach
• Summary

3
Course Overview
• Focus of the course is on the AIAG-VDA FMEA Handbook
1st Edition method for the development of Failure Modes and
Effects Analysis.
– Published by AIAG and VDA.
• All Learning Goals relate to the AIAG-VDA FMEA method.
• Groups will be conducted using the AIAG-VDA FMEA method
– There are two views of FMEA examples shown in the manual. The
Software View depicts what the user sees when developing a FMEA using
specialized software that utilizes system element structure, function net,
failure net, etc. The Form View depicts what the user sees when
developing an FMEA in a spreadsheet.
– This class will use the Form View during the Group Activity development,
but will demonstrate the results using the Software View.

4
Chapter 1

Introduction to FMEA
Chapter 1: Introduction to FMEA
Learning Goals Chapter Outline
In this Chapter you will learn to: • What is an FMEA?
• Describe an FMEA • Maintaining FMEAs
• Describe the benefits of an FMEA • System vs Design FMEAs
• Describe the types of FMEAs • Types of FMEAs
• Compare a System FMEA to a
Design FMEA

6
Arrangement of APQP Processes

7
WHAT IS FMEA?

Purpose and Benefits

8
FMEA: Process Definition
• The FMEA process is a disciplined analytical process that allows
the design team to anticipate potential failures and prevent their
occurrence early in product design, and manufacturing process
development.
• The FMEA is integrated into the work of the design and
development teams (departments) and aimed at system
optimization and risk mitigation.

9
Why Perform FMEA?
• Prevention is the only effective way to achieve zero defect
launch goals.
• Design & Process FMEA are used widely in the automotive
industry to effectively reduce defect levels:
• FMEA enables building an engineering knowledge base
providing shorter lead times and fewer delays.
• FMEAs are integral in Problem Solving.

We Need a Paradigm Shift from Detection to Prevention

10
Considerations of the FMEA
When an FMEA is performed, the following norms are observed:
• Clear:
Potential failure modes are described in technically precise, specific terms; enabling a
specialist to assess failure causes and possible effects.
Descriptions are free from possible misunderstanding. “Elastic” or emotionally laden
terms (dangerous, intolerable, irresponsible, etc.) are not appropriate.
• True:
The consequences of potential failures are described accurately, even if they may
sometimes be disagreeable (re-development, delivery backlog, etc.).
• Realistic:
Failure causes are reasonable. Extreme events are not considered.
• Complete:
Foreseeable potential failures are not concealed. Concern about revealing too much
know-how by creating a correct and competent FMEA does not lead to restricted
representations.

11
Purposes and Benefits of FMEA
• The FMEA process is a structured approach to…
– Improve the quality, reliability, and safety of products, processes, and
services.
– Increase customer satisfaction.
– Reduce development timing and cost.
– Document and track actions taken to reduce risk.
– Enable knowledge management

Concept

Identify ways the product or process can fail

Then plan to prevent those failures

12
Purposes and Benefits of FMEA
Feasibility / Risk Analysis
Technical Risks (FMEA) Financial Risks Time Risks Strategy Risks
Has the product or process Does the product remain Can the improvements be Are the improvements
been analyzed for profitable after counter realized within the time introduced, although the
potential failures? measures? schedule? product is unprofitable?

IN SCOPE OUT OF SCOPE OUT OF SCOPE OUT OF SCOPE

Information about Decision for Further Improvement

Product Risks of the Product and Process
Process Risks

Product and Process

with Reduced Risk

source: AIAG-VDA FMEA Handbook 1st Edition

13
Risk Reduction and FMEA
• FMEA distinguishes between System, Subsystem, and
Component design risk.
• Prevention is built into the FMEA format for S/DFMEA and
PFMEA.
• FMEA links with controls and strives for better and earlier
controls in design; e.g. DFMEA with DVP&R and PFMEA with
Control Plans.
• Links PFMEA with Control Plans to shop floor controls.
• FMEA focus is on improvement actions to reduce risk.

14
FMEA Advantage

16
FMEA Relation to Other Standards
• FMEA is part of APQP
• PPAP requires many components of FMEA:
– DFMEA (if design responsible)
– PFD (Process Flow Diagram showing special characteristics)
– PFMEA (Process FMEA)
– Control Plan (Showing special characteristics)
– Work Instructions (Special Characteristics)
• One of the tools for prevention of failures and continuous
improvement highlighted in 8D Problem Solving
• ISO 26262 requires FMEA
• IATF 16949 requires FMEA
• … and many others

17
MAINTAINING FMEAS

18
Maintaining FMEAs
The FMEA documents living information and should be reviewed
whenever there is a product design change, and should be updated
as required.

• To have value, FMEA updates must occur at these change points:

– New design or process is planned
– Modification to a component, system or process is planned
– Component or system is used in a new environment, location or
application
– Important – Update FMEA to capture continual improvement and
problem solving analyses and results (like 8D Problem Solving)

Knowledge Management

19
TYPES OF FMEAS

20
Primary Types of FMEAs
• System FMEA: Used to analyze systems and subsystems in the
early concept and design stages.
– Focuses on potential failure modes associated with the functions and
interfaces of a system inherent in the design.
• Design FMEA: Used to analyze products before they are released
to production.
– Focuses on potential failure modes associated with the functions of a
product inherent in the design.
– NOTE: VDA uses the term Product FMEA instead of Design FMEA

• Process FMEA: Used to analyze processes before they are

released for use in serial production.
– Focuses on potential failure modes associated with the deliverables of a
process due to design and operation.

21
Chapter 1: Introduction to FMEA
Learning Goals Chapter Outline
You should now be able to: • What is an FMEA?
• Describe an FMEA • Maintaining FMEAs
• Describe the benefits of an FMEA • System vs Design FMEAs
• Describe the types of FMEAs • Types of FMEAs
• Compare a System FMEA to a
Design FMEA
• Describe the different cases for
when to use an FMEA

22
Chapter 2

Developing an FMEA
Chapter 2: Developing an FMEA
Learning Goals Chapter Outline
In this Chapter you will learn to: • Conducting an FMEA
• Describe the structure of an FMEA • Basic Structure of an FMEA
• Describe the steps to conduct an
FMEA

24
CONDUCTING AN FMEA

25
 The intent is to provide a common foundation for FMEA
across the sectors of the automotive industry represented
by these organizations.

26
Not a “Blue Book”
• The VDA-AIAG Handbook is not part of the “Core Tools” set, but
will be required by the major OEMs.
• The core tools belong to GM-Ford-FCA….
the “Handbook” is co-owned by VDA and AIAG.

27
FMEA Model – AIAG-VDA FMEA Handbook
Linking Failure Mode
to Cause and Effect

Effect =
Cause
Effect Results in
Failure Mode Cause
Failure Mode Results in

TIME
We must understand the risks involved in these linkages

28
Conducting an FMEA – General Approach
• Complete necessary prerequisites
– Define the scope of the analysis
– Identify and list all the requirements
• For each requirement
– Identify potential failure modes

• For each failure mode

– Assess potential effects of failures
– Identify the cause(s)
• For each cause
– Identify what control(s) are/will be in place to prevent or detect the
cause or failure mode
– Identify and implement continual improvement actions

29
Cue-Biz 7-Step DFMEA Process
1 PLANNING & PREPARATION 5 RISK ANALYSIS

5Ts

LINK SPECIAL CHARACTERISTICS TO

5b
FUNCTIONS/REQUIREMENTS
2 STRUCTURE ANALYSIS

Boundary/Block Diagram
Structure Development
Interface Diagram 6 OPTIMIZATION

3 FUNCTION ANALYSIS 7 RESULTS DOCUMENTATION

Functions and Requirements

P-Diagram (optional) 7b LINK TO DVP&R

4 FAILURE ANALYSIS

Causes in Focus Level before

causes in Lower Levels

30
7-Step Process – AIAG-VDA FMEA Handbook

31
Transition Strategy
• Existing FMEAs conducted with an earlier version of the FMEA handbook may
remain in their original form for subsequent revisions.

• When practical, existing FMEAs used as a starting point for new programs
should be converted to comply with the new format. However, if the team
determines that the new program is considered a minor change to the
existing product, they may decide to leave the FMEA in the existing format.

• New projects can follow the FMEA method presented in this guidebook
unless company procedure defines a different approach. The transition date
and project milestone after which new projects follow this method should
be defined by the company taking into consideration any customer specific
requirements and standards.

AIAG-VDA FMEA Handbook 1st Edition

32
Optimizing the FMEA Process
• Communicate effectively
• Utilize / build upon existing product information
– Requires an acceptable DFMEA of the referenced product
– Focus is on the “new” stuff in the product; i.e. differences and changes in
the product requirements and use
– Can utilize design and process segments

• Acquire and deploy needed information before meetings

– Historical information on the same or surrogate products; this can impact
effects, causes, occurrence, etc.

33
FMEA STRUCTURE

34
AIAG-VDA FMEA Handbook Form
This process requires the identification / analysis for at least three
levels of product flow-down

35
AIAG-VDA FMEA Handbook Form
This process requires the identification / analysis for at least three
levels of product flow-down

Higher Higher Higher

Level Level Level
Focus Focus Focus
Level Level Level
Lower Lower Lower
Level Level Level

36
Sequence – AIAG-VDA FMEA Handbook
What is the What are the How often How effective
scope / functions and How bad is it? does this is the
structure requirements occur detection?

How does this

impact the
customers?

How can
What can go What is the
this be
wrong? risk?
prevented?

What are the How can

causes? this be
detected?

How can
this be
improved?

37
 7-Steps and the Form
1st Step
Planning and Preparation

System Analysis and Risk Mitigation

Step2nd 3rd Step
Structure Analysis Function Analysis
4th Step 5th Step
Failure Analysis Risk Analysis
STRUCTURE ANALYSIS FUNCTION ANALYSIS
3. Function of Component
1. Function of System and 2. Function of System Element
2. System Element / 3. Component Element Element and Requirement or
1. System (Item) Requirement or Intended and Intended Performance
Interface (Item / Interface) Intended Output or
Output Output
Characteristic

6th Step FAILURE ANALYSIS RISK ANALYSIS

(D) of FCFM
Occurrence
Severity (S)

Filter Code
(Optional)
Detection
(O) of FC
Current Detection
1 Failure Effects 2. Failure Mode 3. Failure Cause Current Prevention

of FE

AP
Optimization (FE) (FM) (FC) Control (PC) of FC
Control (DC) of FC or
FM

OPTIMIZATION
Status:

Occurrence

Detection
Target

Severity
[Untouched, Under Action Taken with Completion

(O)

(D)

AP
(S)
Prevention Action Detection Action Responsible Person Completion
Consideration, In Progress, Pointer to Evidence Date
Date
Completed, Discarded]

7th Step
Layout of document may be company-specific
Results
Documentation
38
7-Step Process and Spreadsheet
The FMEA Spreadsheet
DESIGN FAILURE AND EFFECTS ANALYSIS
(DFMEA)

Company Name:
Engineering Location: Subject: DFMEA ID Number:
Customer Name: DFMEA Start Date: Design Responsibility:
Model / Year / Platform DFMEA Revision Date: Security Classifcation:

STRUCTURE ANALYSIS FUNCTION ANALYSIS FAILURE ANALYSIS

3. Function of Component

Severity (S)
1. Function of System and 2. Function of System Element
Element and Requirement or

of FE
2. System Element / 3. Component Element 1 Failure Effects 2. Failure Mode 3. Failure Cause
1. System (Item) Requirement or Intended and Intended Performance
Interface (Item / Interface) Intended Output or (FE) (FM) (FC)
Output Output
Characteristic

Higher Level
Focused Level
Lower Level

39
Chapter 2: Developing an FMEA
Learning Goals Chapter Outline
You should now be able to: • Conducting an FMEA
• Describe the structure of an FMEA • Basic Structure of an FMEA
• Describe the steps to conduct an
FMEA

40
Chapter 3

System Analysis (Prerequisites)

1st Step 2nd Step 3rd Step
Preparation StructureAnalysis FunctionAnalysis

Project Visualization of the Visualization of

Identification Analysis Scope Product or Process
Functions

Design FMEA Prerequisites

Chapter 3: Design FMEA Prerequisites –

Learning Goals Chapter Outline

In this Chapter you will learn to: • Step 1: Planning and Preparation
• Describe who the customer is for – Scope of Analysis
FMEAs – Group Activity 1
• Explain design functions • Step 2: Structure Analysis
• Complete a Function Analysis – Boundary Diagrams
• Describe Planning and Preparation – Group Activity 2
• Describe the scope of analysis • Step 3: Function Analysis –
• Complete a Boundary Diagram Product Design
– Interface Matrix
• Describe the purpose of a
– Group Activity 3
P-Diagram and Interface Matrix
• Robust Designs
– P-Diagram
– Interface Matrix

42
FMEA Prerequisites
“If I had six hours to cut down a tree, I would spend four hours
sharpening the axe.”– Abraham Lincoln

43
 The Design is Your Friend

Get to Know it Well

44
Steps 1-3 – AIAG-VDA FMEA Handbook
System Analysis (Prerequisites)
1st Step 2nd Step 3rd Step
Planning & Preparation StructureAnalysis FunctionAnalysis

Project Visualization of the Visualization of

identification Analysis Scope Product or Process
Functions
Project Plan: InTent, Structure Tree or Function Tree/Net or
Timing, Team, equivalent Process equivalent Process
Tasks, Tools (5Ts) Flow Diagram Flow Diagram
Analysis boundaries: Identify structural Identify functions and
What is included and relationships, requirements at all
excluded from interfaces and levels
analysis interactions among
the levels
Identification of Collaboration Collaboration between
baseline FMEA with between customer engineering teams
lessons learned and supplier (systems, safety, and
engineering teams components)
(interface
responsibilities)

Basis for the Basis for the Basis for the Failure
Structure Analysis Function Analysis Analysis step
step step

45
 1st Step Planning and
Preparation

PROJECT PLANNING
1 PLANNING & PREPARATION Project
identification
5Ts

2 STRUCTURE ANALYSIS 5 RISK ANALYSIS

Boundary/Block Diagram
Structure Development LINK SPECIAL CHARACTERISTICS TO
Interface Diagram 5b
FUNCTIONS/REQUIREMENTS

3 FUNCTION ANALYSIS
6 OPTIMIZATION
Functions and Requirements
P-Diagram (optional)
7 RESULTS DOCUMENTATION

4 FAILURE ANALYSIS
7b LINK TO DVP&R
Causes in Focus Level before
causes in Lower Levels

46
Step 1: Project Planning and Preparation
The purpose of the Design FMEA Preparation Step is to define
what is included and excluded in the FMEA based on the type of
analysis being developed, i.e. system, subsystem or component.

The main objectives of Design FMEA Preparation are:

– Project identification and boundaries
– Project plan: InTent, Timing, Team, Tasks, Tools (5T)
– Analysis boundaries: What is included and excluded
from the analysis
– Identification of baseline FMEA with lessons learned
– Basis for the Structure Analysis step

47
Step 1: Project Planning and Preparation
Project Identification and Boundaries
• As part of FMEA preparation, a clear understanding of
what is to be evaluated is to be determined. What to
exclude can be just as important as what to include in
the analysis.
• The scope of analysis is established at the start of the
project to assure consistent direction and focus.

48
Step 1: Project Planning and Preparation
The following criteria which may be considered in defining the
scope of a single FMEA include, but are not limited to:
• Novelty of Technology/ Degree of Innovation
• Quality / Reliability History (In-house, zero mileage, field failures,
warranty and policy claims for similar products)
• Complexity of Design
• Safety of People and Systems
• Cyber-Physical System (including cyber-security)
• Legal Compliance
• Catalog and Standard Parts

49
Understanding the Scope of the Analysis
1st Step: Planning and Preparation
5Ts Key Aspects:
• FMEA inTent • What to include and what to
– Why are we here? exclude in FMEA
• FMEA Team • FMEA project plan including
– Who needs to be on the team? important dates, responsible
• FMEA Timing persons, potential team
– When is this due? members, timelines...
• FMEA Task • Boundaries of the analysis
– What work needs to be done?
• FMEA Tool
– How do we conduct the analysis?

50
5Ts — 1. FMEA InTent
• It is recommended that members of the FMEA team are
competent in the method, based on their role on the team.
• When members of the team understand the purpose and intent
of the FMEA, they will be more prepared to contribute to the
goals and objectives of the project.

51
5Ts — 2. FMEA Timing
• One of the most important factors for the successful
implementation of an FMEA program is timeliness.
• Up-front time spent properly completing an FMEA, when
product/process changes can be most easily and inexpensively
implemented, will minimize late change crises.
• The FMEA as a method for system analysis and failure
prevention is best initiated at an early stage of the product
development process.

52
5Ts — 2. FMEA Timing
• It is used to evaluate the risks, valid at that time, in order to
initiate actions to minimize them. In addition, the FMEA can
support the compilation of requirements.
• The FMEA should be carried out according to the project plan
and evaluated at the project milestones according to the state of
the analysis.
• It is recommended that a company define desired maturity
levels for their FMEAs according to overall company-specific
development project milestones, etc.
NOTE: Exceptions to this FMEA timing include non-traditional development flows such as where
development of a "standard" process precedes the development of products that will be
manufactured using the process.

53
5Ts — 2. FMEA Timing
Senior Management Commitment to Timing:
• The FMEA workshop needs to start on time and should be part
of the Design Timing Schedule.
• Companies have more success with DFMEAs when allotted time
is built into the schedule.
• Engineers need to have built into the schedule and have interest
shown by senior management.
• Senior Management interest is shown by:
– Regular DFMEA gate reviews
– Being educated in DFMEA
– Supporting DFMEA education
– Supplying any resources required

54
5Ts — 3. FMEA Team
• The FMEA team consists of multi-disciplinary (cross-functional)
members who encompass the necessary subject matter
knowledge.
• This should include facilitation expertise and knowledge of the
FMEA process.
• The success of the FMEA depends on active participation of the
cross-functional team as necessary to focus on the topics of
discussion.

55
THE FMEA TEAM

Purpose and Benefits

56
Team Approach
• Conducting an FMEA is a “creative” process involving a
cross-functional team.

• A large portion of the benefit of the FMEA process comes from

the increase in knowledge generated by team discussions and
related activities.

This, in itself, is sufficient justification for using

the FMEA process.
FMEA 4th Edition

57
The FMEA Team
• Why?
– Shared experience
– Shared level of understanding
– Capture knowledge base
– Assist in problem solving
– Consensus decision-making

Without a team, very little analysis is likely to occur and the associated
risks may be either underestimated or missed entirely

58
FMEA Team
The Core Team may consist of the following people:
• Facilitator
• Design Engineer
• System Engineer
• Component Engineers
• Test Engineer
• Quality/Reliability Engineer
• Others responsible for the development of the product

59
FMEA Team
The Extended Team may consist of the following people:
• Technical Experts
• Process/Manufacturing Engineer
• Service Engineer
• Project Manager
• Functional Safety Engineer
• Purchasing
• Supplier
• Customer Representative
• Others that may have specialized knowledge which will help the
core team analyze specific aspects of the product

60
Roles on the FMEA Team
• Team Leader
– Typically the responsible engineer
• Facilitator / Moderator
– Is an FMEA process expert
• Skilled in the FMEA methodology and facilitation methods
– Not a requirement for every team
• May not need a full-time facilitator
• Applicable for novice teams
• Team Members
– Core Team
– Expanded Team
• Scribe or Recorder
– Skilled in the use of the appropriate software
– Role should be rotated, if possible

62
FMEA Meetings
• Acquire and deploy needed information before the meeting

• Book meetings in advance

• Prepare an agenda with objectives

• Assign roles

• Communicate effectively

• Define, assign and track

tasks

63
Keys to FMEA Team Success
Support by Management
• Ensure competency of team
members
• Team sized for the task
• Scope not too large
• Objectives well-defined
• Follow a well-defined process
• Objectives considered relevant and significant
• A measurable for success identified
• Time is allotted for analysis and improvement
• Activity integrated with organization’s development process
• Input information and data are available

64
Management Responsibility

“Ultimately, management has the responsibility and

ownership for development and maintenance of the
FMEAs”
FMEA 4th Edition

“Management carries the responsibility for the

application of FMEA. Ultimately, management is
responsible for acceptance of the risks and risk
minimization actions identified in the FMEA”
AIAG-VDA FMEA Handbook 1st Edition

65
5Ts — 4. FMEA Tasks
• The 7-Step Overview provides the framework for the
tasks and deliverables of the FMEA. In addition, the
FMEA team should be prepared to review the results of
their analysis with management and the customer,
upon request.
• The FMEA may also be audited by an internal auditor,
customer auditor, or third-party registrar to ensure
each task has been fulfilled.

66
5Ts — 4. FMEA Tasks

67
5Ts — 5. FMEA Tools
• There are numerous FMEA software packages that can
be used to develop a DFMEA and PFMEA as well as
follow up on actions.
• This software ranges from dedicated FMEA software to
standard spreadsheets customized to develop the
FMEA.
• Companies may develop their own in-house database
solution or purchase commercial software.

68
5Ts — 5. FMEA Tools
• In any case, the FMEA team needs to have knowledge of how to
use the FMEA software selected for their project as required by
the company.
• There are two views of FMEA examples shown in the manual.
• The software view depicts what the user sees when developing
a FMEA using specialized software that utilized e.g. system
element structure, function net, failure net, etc.
• The Matrix view depicts what the user sees when developing a
FMEA in a spreadsheet.

69
Project Plan
The Project Plan is the output from the 5T process.
• The DFMEA Project Plan (subset of the APQP Plan) should be
developed once the DFMEA project is known.
• The DFMEA activities (The 7-Step Process) should be
incorporated into the plan.

70
Identification of the Baseline or Foundation
FMEA
Part of the preparation for conducting the DFMEA is knowing
what information is already available.
• This includes the use of a baseline (foundation) DFMEA or
product family DFMEA which allows for variances based on
different customers buying similar product or systems.
• Like brake systems, in general they basically are the same, but
have variances based on the customer.

71
Identification of the Baseline or Foundation
FMEA
A Family DFMEA is a specialized foundation design FMEA for
products:
• Common Boundaries
• Related Functions
• A “New Product” in the family, the new specific components and
functions would be added to the family
Note: This requires a subject matter expert design engineer to decide if the
variance is unique or may drive a change to fundamental system.

72
DFMEA HEADER INFORMATION

73
Header Information
During Scope Definition, the header of the DFMEA document
should be completed. The header includes some of the basic
DFMEA scope information, as follows 
• The FMEA header should clearly identify the focus of the FMEA
as well as information related to the document development
and control process.
• This may include an FMEA number, identification of the scope,
design responsibility, completion dates, etc.
• Needs to be consistent with the other Design and Process
documentation information.

74
Header Information
• Company Name: Name of company of the DFMEA
• Engineering Location: Geographical Location
• Customer Name: Name of customer(s) for this document and System / Subsystem /
Component / Part
• Model Year / Platform: Starting vehicle model year and/or vehicle program as
applicable
• Subject: Name of DFMEA project
• DFMEA Start Date: The date the team initiates the DFMEA
• DFMEA Revision Date: The revision of the specific unique DFMEA document (latest
date it was changed)
• Cross-Functional Team: DFMEA development team members
• DFMEA ID Number: A unique identification number for the DFMEA document
• Design Responsibility: Name of person who is responsible for the design; this person
also accepts ownership of the content and findings of the DFMEA
• Confidentiality Level: The level of confidentiality determined by the DFMEA owner,
e.g. Internal Business Use, Proprietary, Confidential

75
 2nd Step
Structure Analysis

STRUCTURE ANALYSIS
1 PLANNING & PREPARATION Visualization of the
Analysis Scope
5Ts

2 STRUCTURE ANALYSIS 5 RISK ANALYSIS

Boundary/Block Diagram
Structure Development LINK SPECIAL CHARACTERISTICS TO
Interface Diagram 5b
FUNCTIONS/REQUIREMENTS

3 FUNCTION ANALYSIS
6 OPTIMIZATION
Functions and Requirements
P-Diagram (optional)
7 RESULTS DOCUMENTATION

4 FAILURE ANALYSIS
7b LINK TO DVP&R
Causes in Focus Level before
causes in Lower Levels

76
Step 2: Structure Analysis
Boundary or Extent of the DFMEA
Defines what is included and excluded from the analysis
Need to know:
• What is included • Common Tools Used
• What is not included – Boundary (Block) Diagram
– That is, what is the scope – Step 2 Activities
of the analysis? • Structural (Tree) Analysis
• Component • Interface Matrix
• Assembly • Parameter (P) Diagram
• Subsystem
• System

77
BOUNDARY DIAGRAMS

78
Boundary Diagram
Graphical illustration of the relationships between the subsystems,
assemblies, subassemblies, and components within the object as
well as the interfaces with the neighboring systems and
environments.
• Early in the design program, a Boundary Diagram may be no
more than a few blocks representing major functions and their
interrelationships at the system level.
• As the design matures, Boundary Diagrams may be revised, or
additional ones developed to illustrate lower levels of detail – all
the way down to the component level.

79
Boundary Diagram
The Boundary or Block Diagram indicates the flow of information,
energy, force, fluid, etc. within the scope of the design.
• The objective is to understand the deliverables (input) to the
block, the process (function) performed in the block, and the
deliverables (output) from the block.
• The Block Diagram of the product shows the physical and logical
relationships between the components of the product.
• There are different approaches / formats to the construction of
a Block Diagram.

80
Group Activity 1

Boundary Diagram
Appreciation of a System
Dr. W. Edwards Deming includes Appreciation of a System within
his System of Profound Knowledge
• Synthesis – Explains the reason for the system and how the
system works.
– Take the thing you want to understand as part of a larger whole.
– Explain the behavior of the containing whole.
– Disaggregate the understanding of the containing whole into the role or
function of the parts.
• Understanding of a system never lies inside the system; it always
lies outside the system.
– To manage a system effectively, focus on the interactions.
– Improve the performance of a part only if it improves the performance of
the whole.

82
Step 2: Structure Analysis
Information gathered in the Planning step is transferred to visualize
the relationships and interactions between the design or process
elements.

System Subsystem Product Component

Car Safety Airbag Sensor

• Goal of Structure Analysis

– An overview of the system structure of the product
– Definition of the system boundaries/interface description
– Allows for the reuse of system elements

Note: the AIAG-VDA requires at least 3 levels in the structure:

Higher Level > Focus Level > Lower Level

83
Interface Analysis
An interface analysis describes the interactions between
elements of a system.
• There are five primary types of interaction:
– Physical Connection (Brackets, Bolts, Clamps, Adhesive, etc.)
– Material Exchange (Air, Hydraulic Fluid, Fuel, etc.)
– Energy Transfer (Heat, Friction, High Voltage, or Motion)
– Data Exchange (Inputs, Outputs, Carriers, information exchange, cyber
security items)
– Human-Machine (Controls, switches, mirrors, glass reflection, displays,
seating)
– Clearances
– Interfaces between subsystem and components
• The interface analysis document is the boundary diagram and
also the P-Diagram.

84
Structure Analysis: Structure Trees
The structure tree arranges system elements hierarchically and
illustrates the dependency via the structural connections.
• A clearly structured illustration of the complete system is
guaranteed to prevent redundancy by the fact that each system
element exists only once.
• The interactions between System Elements may be described
later as functions and represented by function nets (see
Step 3 Function Analysis).
• There IS always a system element present, even if it IS only
derived from the function and cannot yet be specified more
clearly.

85
Structure Analysis: System Structure
System Component

Component
Product System
Component

Component

System Component

86
Structure Analysis: System Structure in Excel
The system structure can be created in the Structure Analysis
section of the Spreadsheet:
STRUCTURE ANALYSIS (STEP 2)

3. Next Lower Level or

Characteristic Type
1. Next Higher Level 2. Focus Element [Geometry, Material,
Surface Finish, Coating,
etc.]

The term characteristic “type”

is used because the design
FMEA is a design “input” and
the focus is on features; i.e. you
do not have the characteristics
yet!
87
Example of Structure

Software
Version

STRUCTURE ANALYSIS (STEP 2)

3. Next Lower Level
1. Next Higher Level 2. Focus Element
Form or Matrix or Characteristic Type
Brush Card Base Body
Version Window Lifter Electrical Motor
Carbon Brush
Pole Housing
Etc.

Adapted from: AIAG-VDA FMEA Handbook 1st Edition

88
 System Structure
Left sensor

Impact Right sensor

Sensing

Safing
Class Case Study

sensor

Micro
controller
ABS

ECU software

Power
etc.

Air Bag inflator

Vehicle
System
Deployment Driver
system system
airbag
Passenger
speed system
etc.
sensor

89
Group Activity 2

Structure Analysis
Interface Matrix
• Illustrates relationships between the subsystems, assemblies,
subassemblies, and components within the object as well as the
interfaces with the neighboring systems and environments.
• Documents the details, such as types of interfaces,
strength/importance of interface, potential effect of interface,
etc.

91
 Interface Matrix – Airbag
Class Case Study

Initiator – Passenger

Passenger Airbag
Initiator – Driver

Driver Airbag
Front Sensor

Control Unit

0
0
Front Sensor 0 2 0 -2 0 -2 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
Control Unit 2 0 2 0 2 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
Initiator – Driver -2 2 0 -2 0 0 0 0 0 0
-2 0 2 0 -2 0 0 0
Initiator – Passenger -2 2 -2 0 0 0 0 0 0
-2 -2 0 2 0 0 0
Driver Airbag 0 0 0 0
2 -2 0 0 0 0
Passenger Airbag 0 0
-2 2 0 0

92
 3rd Step
FunctionAnalysis

FUNCTION ANALYSIS
1 PLANNING & PREPARATION
Visualization of Product
5Ts or Process Functions

2 STRUCTURE ANALYSIS 5 RISK ANALYSIS

Boundary/Block Diagram
Structure Development LINK SPECIAL CHARACTERISTICS TO
Interface Diagram 5b
FUNCTIONS/REQUIREMENTS

3 FUNCTION ANALYSIS
6 OPTIMIZATION
Functions and Requirements
P-Diagram (optional)
7 RESULTS DOCUMENTATION

4 FAILURE ANALYSIS
7b LINK TO DVP&R
Causes in Focus Level before
causes in Lower Levels

93
Goal of Function Analysis
• Overview of the product functionality
• Verification against the customer requirements / specifications
• Function tree/net, or equivalent function matrix parameter
diagram (P-diagram)
• Association of requirements or characteristics to functions
• Overview of cause and effect relationships
• Creating the basis for the failure analysis

94
Design Functions
• What SHOULD the product/service (structural elements) be
doing?
• What are the Functional Deliverables?
• What do we expect to see, in terms of:
– Functionality?
– Efficiency?
Consider the conditions
– Effectiveness?
Storage
– Under what conditions? Normal Use
– For each customer: Expected Misuse
Buyer Management Abuse
User Government Extreme Conditions
Manufacturing Society
Handling, etc.

95
Design Functions
Caution:
• Clearly distinguish between the basic functions of a product, its
detailed requirements and design constraints and assumptions.
• For example, a disk brake system has the basic function of
stopping a vehicle on demand but it could also have…
– A specific requirement that the vehicle stops within 200 feet of demand
on dry pavement.
– Design constraints: e.g. size, weight, environment, etc.

• A single function can have multiple requirements.

96
Requirements
List all the requirements/deliverables for each function.
• List each requirement separately.
– Recommended: Provide a name and number for each deliverable to be
evaluated.
– Show design level per engineering drawing.
• Requirements should be described by an action verb followed by
a noun.
– Describe the requirement in terms that can be measured.
• When the product/material must function under certain
conditions, document those conditions.

97
Example: Function Worksheet

Function Worksheet

Sl. Function When How much

Operated at 90 Bar and Zero amount of oil
1 Leak-free Steering
during Idle condition. over 300 seconds
Accelerated to full Less than audible
2 Quiet Steering
throttling. noise ( ~ 75 decibals )

3 Steering with Road feel / grip. At 100 km/h speed < x° play.

Requirements:
When = under what conditions
How Much = acceptance criteria

98
Function Analysis
• Allocates the identified functional requirements to the system
structural elements
• Flows down the functional requirements of the item to the
lower level elements
• Answers the question “What is the purpose of the specific level
(system) element?”

99
Function Analysis
In addition to the primary functions of an item, other functions
that may be evaluated include secondary functions such as
interface functions, diagnostic functions, and serviceability
functions.

Function of Item /
Input System Element Output

Interface
source: AIAG-VDA FMEA Handbook 1st Edition

100
 Function Analysis
Product or Process functionality is ensured by allocating a
description of activities, purposes or tasks intended for the product
performance.

System : Car Subsystem: Product : Airbag Component :

Safety Sensor

• Safe • Protect • Deploy on • Detect frontal

transportation passengers demand collision
of passengers during during
collision collision

101
 Example of
Functional
Analysis to
Form

FUNCTION ANALYSIS (STEP 3)

3. Next Lower Level
1. Next Higher Level 2. Focus Element
Function and
Function and Function and
Requirement or
Requirement Requirement
Characteristic
Raise and lower Commutation system Brush card body
window according transports the trans-ports forces
to electrical current between spring and
parameterization. between coil pairs of motor body to hold
the electromagnetic the brush spring
source: AIAG-VDA FMEA Handbook 1st Edition converter system in x, y, z
position (support
commutating contact
point)
102
Group Activity 3

Function Analysis
Group Activity 3: Function Analysis
Instructions
• For each entry (three levels) in the structure tree related to the
focused element, identify the product functions and
requirements.
– i.e. what product functions would the different customers find
important?

• Update the form.

• Prepare to present and review as a class.

104
ROBUST DESIGNS

P-Diagram

105
Robust Designs
• How could the product/service be affected by…
– Other systems (at the same level)?
– The producing processes?
– The customer use of the product?

• Tools
– Subject Matter Expertise
– Parameter Diagram  P-Diagram
• Robustness Checklist (RCL)
• Robustness Demonstration Matrix (RDM)
– Interface Matrix
– Quality Function Deployment (QFD) Matrix

106
Parameter (P) – Diagram
• A structured tool to help the team understand the physics
related to the function(s) of the design.
– The team analyzes the intended inputs (Signals) and outputs (Functions)
for the design as well as those controlled and uncontrolled factors which
can impact performance.

• Once the inputs and outputs are identified, error states, noise
factors, and control factors are then established.

107
Parameter (P) – Diagram Noise Factors
Sources that disrupt response that can not be controlled

● Piece to Piece ● Changes over Time/Usage ● Customer Usage

● External Environment ● Subsystem Interaction

Signal Response

INPUT System OUTPUT

Energy put into Intended function of

the system to the design
make it work
Control Factors Error States
Features of the design that Undesirable output or
can be controlled Failure Modes
● Compliance
● Functional
● Annoyance

108
P-Diagram Example

source: AIAG-VDA FMEA Handbook 1st Edition

109
 Project: Frontal Collision Air Bag

Parameter (P) – Diagram

P-Diagram
Manufacturing
Manufaturing Variation
Variation Closing Speed

Signal interferance Customer usage

Environment Contamination Noise Factors

Class Case Study

Front Impact Airbag System

Front Crash
Sensor

Signal Factor (M) A Response (Y)

G H
Vehicle Speed
Power
ECU
Sensor
(Ideal Function)
I-DA E F I-PA
Driver Airbag Passenger Airbag

Initiator Initiator

Power Deploy on Demand

Collision Signal response time

Speed Signal Impact force

Error States

Control Factors no deployment on demand

designed redundancies
delayed deployment
design parameters software algorithms
deployment without demand
component selection dimensional tolerances
too forceful deployment

late deflation 110

Robustness Linkages
Robustness is when the system does
Boundary not react to the expected noise factors
Diagram

Interface
P - Diagram
Matrix

FMEA
Robustness
Checklist
Robustness
Demonstration
Matrix
Quality
DVP&R
History

111
Chapter 3: Design FMEA Prerequisites –

Learning Goals Chapter Outline

You should now be able to: • Step 1: Planning and Preparation
• Describe who the customer is for – Scope of Analysis
FMEAs – Group Activity 1
• Explain design functions • Step 2: Structure Analysis
• Complete a Function Analysis – Boundary Diagrams
• Describe Planning and Preparation – Group Activity 2
• Describe the scope of analysis • Step 3: Function Analysis –
• Complete a Boundary Diagram Product Design
– Interface Matrix
• Describe the purpose of a
– Group Activity 3
P-Diagram and Interface Matrix
• Robust Designs
– P-Diagram

112
Chapter 4

Failure Analysis and Risk Mitigation

4th Step 5th Step 6th Step
Failure Analysis Risk Analysis Optimization

Establishment of the Assignment of Identification of the

Failure Chain Existing and/or Actions Necessary
Planned Controls and to Reduce Risks
Rating of Failures

Developing the Design FMEA

Chapter 4: Developing the Design FMEA
Learning Goals Chapter Outline
In this Chapter you will learn to: • Design Failure Modes
• Explain design failure modes • Step 4: Failure Analysis
• Identify failure modes from – Group Activity 4
requirements – Potential Effects of Failure
• Explain causes of failure modes – Potential Causes of Failure
• Explain design controls
– Group Activity 5
• Distinguish between prevention
and detection controls • Step 5: Design Controls and Risk
• Explain the key elements of the Analysis
risk analysis – Group Activity 6
• Define requirements for Results – Evaluation: Indices and
Documentation and Action Plans
Communication – Group Activity 7
• Step 6: Optimization
• Step 7: Results Documentation

114
 4th Step
Failure Analysis

FAILURE ANALYSIS
1 PLANNING & PREPARATION Establishment of the
Failure Chain
5Ts

2 STRUCTURE ANALYSIS 5 RISK ANALYSIS

Boundary/Block Diagram
Structure Development LINK SPECIAL CHARACTERISTICS TO
Interface Diagram 5b
FUNCTIONS/REQUIREMENTS

3 FUNCTION ANALYSIS
6 OPTIMIZATION
Functions and Requirements
P-Diagram (optional)
7 RESULTS DOCUMENTATION

4 FAILURE ANALYSIS
7b LINK TO DVP&R
Causes in Focus Level before
causes in Lower Levels

115
Potential Design Failure Mode
1. Identify and List All the Requirements
2. For Each Requirement
– Identify Potential Design Related Failure Modes

How the design could potentially fail to provide a

defined function to a customer

116
Potential Design Failure Mode
Defines how the output of the design process could fail
to:
– Meet the functional requirements
– Meet the design intent (fit, form)
– Meet the processing intent

117
 Failure Analysis
Failures of functions are deduced from the functions already
identified in Step #3 and in this step (#4)

System : Car Subsystem: Safety Product : Airbag Component :

Sensor

• Safe • Protect • Deploy on • Detect frontal

transportation passengers demand during collision
of passengers during collision collision • Failure to Sense
• Unable to • Unable to • Airbag does not collision
provide safe provide deploy on
transportation passenger demand
safety during
collision

118
Potential Failure Mode
For each requirement – a description of what would be seen,
heard, felt, etc. if the deliverable does not meet the identified
requirement…
– Why would the item be unacceptable?
– How would the item not conform to the customer requirements?
– What would the customer consider unacceptable?
– How does the item fail to meet regulatory compliance?
Related Malfunctions
1. No function
Failure Modes are the details of 2. Partial function
the malfunction as applied to 3. Over function
the requirement 4. Under / degraded function
5. Intermittent function
6. Unintended function

119
Example

Item Function Requirement Failure Mode

Disk Brake system Stop vehicle on Stop vehicle traveling Vehicle does not stop
demand on dry pavement
demand within 70 Vehicle stops in
meters from 100 excess of 70 meters
km/hr Activates with no
demand; vehicle
movement impeded
Continues to activate
with no demand – no
movement
Stops vehicle with Stops vehicle with
less than specified more than xx g’s of
force on occupants force

120
Failure Net Analysis
Higher Level Focus Level Lower Level

Failure Effect Failure Cause

Failure Effect Failure Mode Failure Cause

List all potential List all potential

effects of failure. Focus is the causes of failure.
potential failure
mode.
Failure Effect Failure Cause

The relationships among the failure causes, modes and effects of the
different levels are identified to show their relationships to enable
risk assessment

121
Types of Failures

source: AIAG-VDA FMEA Handbook 1st Edition

122
The Failure Chain
There are three different aspects of failures analyzed in an FMEA:
– Failure Effect (FE) the consequences of a failure mode
– Failure Mode (FM) manner in which an item could fail to
meet or deliver the intended function
– Failure Cause (FC) indication of why the failure mode could
occur
Note: these are all failure modes at different levels
Higher Level Focus Level Lower Level

124
Failure Chain Analysis

source: AIAG-VDA FMEA Handbook 1st Edition

125
 Failure
Analysis as
Structure Tree
and Form

FAILURE ANALYSIS (STEP 4)

1. Failure Effects
3. Failure Cause
(FE) to the Next
2. Failure Mode (FM) (FC) of the Next
Higher Level
of the Focus Element Lower Element or
Element and/or
Characteristic
Vehicle End User
Window does not Commutation system Brush card body
lower intermittently bends in contact
connects the wrong area of the carbon
coils (L1, L3 and L2 brush
instead of L1, L2 and
L3)

source: AIAG-VDA FMEA Handbook 1st Edition

126
Example Failure Modes –
Unacceptable Description
• Poor Appearance • Noise
• Discoloration • Erratic Operation
• Vision Impaired • Unstable
• Cannot Fasten • Rough
• Loss of Pressure • Regulatory Nonconformance
• Loss of Power • Electromagnetic Capability (EMC)
• Fading • Radio Frequency Interference (RFI)
• Intermittent operation

Note: Explain with sufficient detail on subject, conditions, and location so

severity can be evaluated and appropriate actions taken.
The better the description/detail, the more use the FMEA will have in
problem solving activities.

128
Example Failure Modes – Better Descriptions
• Product will be rejected by customer • Noise (metal to metal) > 75 db
– Fisheyes on class A surface • Erratic operation cause loss of control
– Uneven color / streaking (hazard)
• Vision impaired due to oil spray; • Unstable shelf life; loss of adhesion
hazard • Misalignment due to rough mating
• Cannot be fastened to mating part surface
• Loss of steering control due to drop in • Unpleasant odor
hydraulic pressure • Thermal event
• Loss of power – hazard • Regulatory nonconformance to
• Fading brakes – potential hazard ISI 686-7
• Will not lock • Electromagnetic Capability (EMC)
• Intermittent operation – potential sporadic due to Radio Frequency
hazard Interference (RFI)

129
Group Activity 4

FAILURE ANALYSIS (STEP 4)

1. Failure Effects (FE) 3. Failure Cause (FC)

2. Failure Mode
to the Next Higher of the Next Lower
(FM) of the Focus
Level Element and/ Element or
Element
or Vehicle End User Characteristic

Failure Modes
POTENTIAL EFFECTS OF FAILURE

131
FMEA Process
1. Identify and List All the Requirements
2. For Each Requirement
– Identify Potential Design Related Failure Modes
3. For Each Failure Mode
– Assess Potential Effects of Failures Failure Net Analysis
– Identify the Cause(s)

132
Effect of a Failure Mode
“Potential effects 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.”
Source: FMEA Fourth Edition, 2008

• Customer includes:
– Manufacturing and Assembly processes of the Product
– Next higher assembly
– System
– Vehicle – End-User
– Government Regulation

133
Effect Linkages
Effects propagate through the design Process Failure Mode X due to
Process Causes Y1, Y2, … Yn
levels till they reach the customer.
Op 10 Op 20 Op... OP 120

Process for Part 2

The effect of a
Process Failure Mode is a
The effect of a Failure Mode at a Part 2 Failure Mode or a
downstream process effect
lower level is a Failure Mode at a
higher level and all its effects and Design Failure Mode X due to
Design Process Causes Y1, Y2, … Yn
severity.
Part 2

The effect of a
Part 2 Failure Mode is a
Module 3 Failure Mode

Part
3
Part Part Part
1 2 5
Part
4

Module 3

134
Effect Linkages

Effects propagate through

the design levels till they
reach the customer.

135
Effect in AIAG-VDA FMEA Handbook
In the AIAG-VDA FMEA approach, an effect is the failure mode of
the higher level structural element.
Higher Level Focus Level Lower Level

FAILURE ANALYSIS (STEP 4)

1. Failure Effects (FE) 3. Failure Cause (FC)

2. Failure Mode
to the Next Higher of the Next Lower
(FM) of the Focus
Level Element and/ Element or
Element
or Vehicle End User Characteristic

136
POTENTIAL CAUSES OF FAILURE

137
Potential Cause(s) of Failure
1. Identify and List All the Requirements
2. For Each Requirement
– Identify Potential Design Related Failure Modes
3. For Each Failure Mode
– Assess Potential Effects of Failures Failure Net Analysis
– Identify the Cause(s)

138
Potential Cause(s) of Failure
Potential cause of failure is defined as an indication of how the
design process could allow the failure to occur, described in terms
of something that can be corrected or can be controlled.
Source: FMEA Fourth Edition, 2008

• Potential cause of failure may be an indication of a design

weakness, the consequence of which is the failure mode.

• Causes are the circumstances that induce or activate a failure

mechanism.

139
Cause in AIAG-VDA FMEA Handbook
In the AIAG-VDA FMEA approach, a cause is the failure mode of the
lower level structural element.
Higher Level Focus Level Lower Level

FAILURE ANALYSIS (STEP 4)

1. Failure Effects (FE) 3. Failure Cause (FC)

2. Failure Mode
to the Next Higher of the Next Lower
(FM) of the Focus
Level Element and/ Element or
Element
or Vehicle End User Characteristic

140
Causes
Causes of Design Failure Modes can stem from
A. Lack of understanding of the actual customer needs
B. Lack of understanding of all functional, safety and reliability
requirements
C. Lack of understanding of the specific failure mechanisms
– Especially related to interfaces
– Including environmental impacts, expected abuses, etc.
D. Lack of understanding of variation and its propagation
and
E. Lack of communication of A – D to lower design levels

141
Potential Cause(s) of Failure
Potential cause of failure is defined as how the failure mode could
occur, described in terms of something that can be corrected or
controlled.
• Each cause assignable to a failure mode should be listed and
considered separately.

• In the development of the FMEA, the identification of all

potential causes of the failure mode is key to subsequent
analysis.
– Although varied techniques (such as brainstorming) can be used to
determine the potential cause(s) of the failure mode, it is recommended
that the team should focus on an understanding of the failure mechanism
for each failure mode.

142
Potential Cause(s) of Failure
• Investigation of causes needs to focus on the failure mode and
not on the effect(s).
• In determining the cause(s), the team should assume the
existence of the cause under discussion will result in the failure
mode.
– i.e. assume the failure mode does not require multiple causes to occur.
• FMEAs assume Single Point Failures (SPF); i.e. the cause will produce the
failure mode.
• Fault Tree Analysis (FTA) allows for analysis of Multiple Point Failures (MPF)
(i.e. redundancies).
• If there are several causes for a failure mode, this should result
in multiple lines (cause branches) for the failure mode.

Assume the product / service is produced correctly

143
 Example
Failure Mode Mechanism Cause

Vehicle does not stop No transfer of force from Mechanical linkage break due to design allowing
pedal to pads environmental corrosion
Master cylinder vacuum lock due to seal design

Loss of hydraulic fluid due to incorrect connector

torque specifications

Loss of hydraulic fluid due to hydraulic lines

crimped/compressed, inappropriate tube material
specified

Vehicle stops in excess of yy Reduced transfer of force Mechanical linkage joints stiff due to inappropriate
feet from pedal to pads lubrication specification

Mechanical linkage joints corroded due to

inadequate corrosion protection

Partial loss of hydraulic fluid due to hydraulic lines

crimped, inappropriate tube material specified

144
Example Using Spreadsheet Form
1. Failure Effects (FE)
1. Next Higher Level
1. Next Higher to the Next Higher
Function and
Level Level Element and/or
Requirement
Vehicle End User
Window Lifter Motor Raise and lower window Torque and rotating
according to velocity of the window
parameterization lifter motor too low

2. Focus Element
2. Failure Mode (FM) of
2. Focus Element Function and
the Focus Element
Requirement

Electrical Motor Commutation system Commutation system

transports the electrical intermittently connects the
current between coil wrong coils (L1, L3 and L2
pairs of the instead of L1, L2 and L3)
electromagnetic
converter

3. Next Lower 3. Failure Cause (FC)

3. Next Lower Level or Level Function of the Next Lower
Characteristic Type and Requirement Element or
or Characteristic Characteristic
Brush Card Base Brush card body Brush card body
Body transports forces bends in contact area
between spring of the carbon brush

145
Failure Analysis as a Matrix
By inspecting the items in the Function Analysis, begin building the
Failure Chain.
• Failure Effects (FE):
The effect of failure associated with the “Function of System or
System Element” in the Function Analysis.
• Failure Mode (FM):
The mode (or type) of failure associated with the “Function of
System Element” in the Function Analysis.
• Failure Cause (FC):
The cause of failure associated with the “Function of Component
Element and Output or Characteristic” in the Function Analysis.

146
Failure Net Analysis
Higher Level Focus Level Lower Level

Failure Effect Failure Cause

Failure Effect Failure Mode Failure Cause

List all potential List all potential

effects of failure. Focus is the causes of failure.
potential failure
mode.
Failure Effect Failure Cause

The relationships among the failure causes, modes and effects of the
different levels are identified to show their relationships to enable
risk assessment

147
Failure Net Analysis
• At this point in the analysis, the functions and requirements and
their relayed failure modes have been determined for all levels.

• To determine the causes and effects for each failure mode in

each step, Failure Chains need to be developed.

148
The Failure Chain
There are three different aspects of failures analyzed in an FMEA:
– Failure Effect (FE) the consequences of a failure mode
– Failure Mode (FM) manner in which an item could fail to
meet or deliver the intended function
– Failure Cause (FC) indication of why the failure mode could
occur
Note: these are all failure modes at different levels
Higher Level Focus Level Lower Level

149
Group Activity 5

Failure Net
Link Effect  Failure Mode  Cause
Group Activity 5: Failure Net
Working with the Function and Requirements / Failure Modes
worksheet related to the previous Group:
• For each focused Failure Mode, identify related
Effects (higher level) and Cause (lower level).
• Update the form.
• Prepare to present and review as a class.

151
 5th Step
Risk Analysis

RISK ANALYSIS & DESIGN CONTROLS

1 PLANNING & PREPARATION Assignment of Existing
and/or Planned Controls
and Rating of Failures
5Ts

2 STRUCTURE ANALYSIS 5 RISK ANALYSIS

Boundary/Block Diagram
Structure Development LINK SPECIAL CHARACTERISTICS TO
Interface Diagram 5b
FUNCTIONS/REQUIREMENTS

3 FUNCTION ANALYSIS
6 OPTIMIZATION
Functions and Requirements
P-Diagram (optional)
7 RESULTS DOCUMENTATION

4 FAILURE ANALYSIS
7b LINK TO DVP&R
Causes in Focus Level before
causes in Lower Levels

152
Design Controls
1. Identify and List All the Requirements
2. For Each Requirement
– Identify Potential Design Related Failure Modes
3. For Each Failure Mode
– Assess Potential Effects of Failures
– Identify the Cause(s)
4. For Each Cause
– Identify what control(s) in the Design Process are/will be in place

153
Design Controls
“Current Design Controls are those activities conducted as part of
the design process that have been completed or committed to and
that will assure the design adequacy for the design functional and
reliability requirements under consideration.”
Source: FMEA Fourth Edition, 2008

Types of Design Controls:

Prevention (P): Detection (D):

• Prevent the cause thus • Detect the cause
preventing the failure mode • Detect the failure mode

154
Design Controls
• The preferred approach is to first use prevention controls, if
possible.
• The initial occurrence rankings will be affected by the prevention
controls provided they are integrated as part of the design
intent.

First consider how to prevent,

then how to detect

155
Prevention Controls in Design
These are analysis, testing, reviews, and other activities that will assure the
design adequacy:
• Fail-safe designs
• Error-proofing by product design
• Analysis of concepts to establish design requirements
– Studies on similar designs, phased testing from prototype through production,
lessons learned and feedback loops
– Designed Experiments to understand the variational model of the function
– Simulation studies / virtual analysis consistent with real life
• Benchmarking studies
• Design and Material standards (internal and external)
• Documentation – records of best practices, lessons learned, etc.
• Prevention Controls impact the occurrence ranking

156
Detection Controls in Design
Design Analysis Techniques
(to detect causes)
• Analysis of the specifications to establish
conformance to design requirements
– Designed Experiments
– Proven Modeling / Simulation / Virtual Analysis
• Tolerance Stack-up
• Material Compatibility
• Design Review
• Design Verification / Validation

157
Detection Controls in Design
Development Tests Techniques
(to detect causes or failure modes)
• Design Reviews If an analytical technique is used
to understand the variation model
• Vehicle Design Verification Tests (determine a specification), it is
– Prototype testing preventive.
– Product/process validation testing
– “Life of Product” validation testing If it is used to verify or validate a
design, it is detective.
• Mock-up using
– Similar parts
– Supplier organization qualified components
– Statistically significant quantity of engineering prototype samples
– Small quantity of pre-production samples
• Simulation Studies – Validation of Design
• Design of Experiments

158
 Example
Failure Mode Cause Preventive Detective

Vehicle does not stop Mechanical linkage Designed per material Environmental stress
break due to standard MS-845 test 03-9963
environmental
corrosion

Master cylinder vacuum Carry-over design with Pressure variability

lock due to seal design same duty cycle testing – system level
requirements

Loss of hydraulic fluid Designed per Torque Vibration step-stress

due to incorrect requirements - 3993 test 18-1950
connector torque
specification
Loss of hydraulic fluid Designed per material DOE – tube resiliency
due to hydraulic lines standard MS-1178
crimped / compressed;
inappropriate tube
material specified

159
Design Controls
• Design Control columns in the DFMEA describe the methods
that will be used to control the design process.
• The Test Plan (DVP&R) provides the details of those controls.

160
Confirmation of Current Prevention and
Detection Controls
• The effectiveness of the current prevention and detection
controls should be confirmed.
– This can be done during validation teardown reviews.
– Additional action may be needed if they are proven to not be effective.

• Such confirmation can be documented within the DFMEA, or

within other project documents, as appropriate, according to
the team's normal product development procedure and
controls.

161
Prevention and Detection in DFMEA

source: AIAG-VDA FMEA Handbook 1st Edition

162
Roadmap of Design Understanding

source: AIAG-VDA FMEA Handbook 1st Edition

163
 5th Step
Risk Analysis

Risk Analysis & Design Controls

1 PLANNING & PREPARATION Assignment of Existing
and/or Planned Controls
5Ts and Rating of Failures

2 STRUCTURE ANALYSIS 5 RISK ANALYSIS

Boundary/Block Diagram
Structure Development LINK SPECIAL CHARACTERISTICS TO
Interface Diagram 5b
FUNCTIONS/REQUIREMENTS

3 FUNCTION ANALYSIS
6 OPTIMIZATION
Functions and Requirements
P-Diagram (optional)
7 RESULTS DOCUMENTATION

4 FAILURE ANALYSIS
7b LINK TO DVP&R
Causes in Focus Level before
causes in Lower Levels

164
Special Characteristics
Special Characteristics are, as defined by IATF 16949,
a product characteristic or manufacturing process parameter that
can affect safety or compliance with regulations, fit, function,
performance or subsequent processing of product.
• Some companies require that all characteristics on the print be
part of the process review. That is, all characteristics need to be
included in the FMEA and Control Plan, and need to be studied
for capability in PPAP. All types of measurement systems need to
be studied for MSA as well.
• Control of characteristics designated as safety critical, function
critical, and customer interface need to follow the customer-
specific requirements or organization requirements, whichever
is most stringent.

165
Linkage to Special Characteristics
• This step should be used to highlight high-priority failure modes
and their associated causes.
• As a result of this analysis, the team may use this information to
update the preliminary list of special characteristic by identifying
those failure modes leading to special characteristics.
• A characteristic designated in the design record as special
without an associated design failure mode identified in the
DFMEA is an indication of a weakness in the design process.

166
Characteristics and Requirements –
Special Characteristics

Characteristics
Functions & Requirements Characteristics
Characteristics

Link the Design to Manufacturing to Shop Floor Controls

Sample rules for Special Functions:
Special Functions can be identified for Severity 9 & 10 requirements /
functions and Severity 8 & 7 requirements/functions with High
Occurrence?

167
 EVALUATIONS

Indices and Action Plans

NOTE : It is not appropriate to compare the ratings of one team's FMEA

with the ratings of another team, even if the product / process appear to
be identical, since each team's environment is unique and thus their
respective individual ratings will be unique (i.e. the ratings are subjective).

168
Severity of Effect
Severity is the rank associated with the most serious effect of the
failure mode on the customer:
– Assess the severity of each effect by team consensus using the ranking
table, in the Effects column.
– Enter the ranking for the most serious effect in the “S” (Severity) column.

Recommendation: record the severity for each effect

169
 DFMEA Severity – AIAG 4th Edition
Effect Criteria: Severity of Effect Rank

Potential failure mode affects product operation and/or involves noncompliance

Hazardous Without Warning 10
with government regulation without warning
Potential failure mode affects product operation and/or involves noncompliance
Hazardous With Warning 9
with government regulation with warning

Very High product inoperable (loss of primary function) 8

product operable but at a reduced level of performance.

High 7
Customer very dissatisfied
product operable but comfort/convenience feature(s) inoperable. Customer
Moderate 6
dissatisfied
product operable but comfort/convenience feature(s) operable at a reduced
Low 5
level of performance. Customer somewhat dissatisfied
Component does not conform to fit and finish/squeak and rattle requirements.
Very Low 4
Defect noticed by most customers (greater than 75%)
Component does not conform to fit and finish/squeak and rattle requirements.
Minor 3
Defect noticed by 50% of customers
Component does not conform to fit and finish/squeak and rattle requirements.
Very Minor Defect noticed by discriminating customers 2
(less than 25%)

No No discernible effect 1

RPN = severity X occurrence X detection 170

DFMEA Severity – AIAG-VDA FMEA Handbook
Corporate or Product
SEV Effect Severity Criteria
Line Examples

Affects safe operation of the vehicle and/or other vehicles, the health of
10
operator or passenger(s) or road users or pedestrians
Very High
9 Noncompliance with regulations The table may
be augmented
Loss of primary vehicle function necessary for normal driving during expected
8 to include
service life
High product specific
Degradation of primary vehicle function necessary for normal driving during examples.
7
expected service life

6 Loss of secondary vehicle function

5 Moderate Degradation of secondary vehicle function

4 Very objectionable appearance, sound, vibration, harshness, or haptics

3 Moderately objectionable appearance, sound, vibration, harshness, or haptics

Low
2 Slightly objectionable appearance, sound, vibration, harshness, or haptics
Safety is 10 regardless of warning – Split rating of 10 and 9
1 Very Low No discernible effect
171
Occurrence (Probability of)
The Occurrence rating (O) is a measure of the effectiveness of the
prevention control, taking into account the rating criteria.
• Occurrence is an index linked to the likelihood that a specific
cause will occur, resulting in the failure mode within the design
life.
– A consistent scale must be used to ensure continuity.

• Occurrence is directly related to the sensitivity of the design to

the identified (special) causes.

172
Occurrence
• Best-in-Class: identify whether the ranking is based on…
– Consensus
– Historical data on the same or similar designs
– Statistical study (e.g. DOE) on the design

• The likelihood of occurrence ranking number has a relative

meaning rather than an absolute value.

173
Occurrence
• In determining this estimate, questions such as the following
should be considered:
– What is the service history/field experience with similar components,
subsystems, or systems?
– Is the item a carryover or similar to a previous level item?
– How significant are changes from a previous level component,
subsystem, or system?
– Is the item radically different from a previous level item?
– Is the item completely new?
– Has the item’s application and/or operational stresses changed?
– Any environmental changes?
– Has an engineering analysis (e.g. reliability) been used to estimate the
expected comparable occurrence rate for the application?
– Have preventive controls been put in place?

174
Occurrence
• A consistent occurrence ranking system should be used to
ensure continuity.
• The occurrence ranking number is a relative rating within the
scope of the FMEA and may not reflect the actual likelihood of
occurrence.

Occurrence ranking will be affected by the

Prevention Design Controls

175
 DFMEA Occurrence Table – AIAG 4th Edition
Criteria: Occurrence of Cause – DFMEA
Likelihood of Failure Rank
(Design Life / Reliability of Product)

Very High New technology/new design with no history 10

Failure is inevitable with new design, new application, or change in duty

9
cycle/operating conditions

Failure is likely with new design, new application, or change in duty

High 8
cycle/operating conditions

Failure is uncertain with new design, new application, or change in duty

7
cycle/operating conditions

Frequent failures associated with similar designs or in design simulation and

6
testing

Occasional failures associated with similar designs or in design simulation and

Moderate 5
testing

Isolated failures associated with similar design or in design simulation and

4
testing

Only isolated failures associated with almost identical design or in design

3
simulation and testing
Low
No observed failures associated with almost identical design or in design
2
simulation and testing

Very Low Failure is eliminated through preventive control 1

176
DFMEA Occurrence – AIAG-VDA FMEA Handbook
Corporate or
Prediction of Failure
OCC Product Experience Product Line
Cause Occurring
Examples
First application of new technology anywhere without operating experience and/or
under uncontrolled operating conditions. No product verification and/or validation
experience.
10 Extremely High
Standards do not exist and best practices have not yet been determined. Prevention
controls not able to predict field performance or do not exist.

First use of design with technical innovations or materials within the company. New
application, or change in duty cycle / operating conditions. No product verification
9 and/or validation experience.

Prevention controls not targeted to identify performance to specific requirements.

Very High
First use of design with technical innovations or materials on a new application.
New application or change in duty cycle / operating conditions. No product
verification and/or validation experience.
8
Few existing standards and best practices, not directly applicable for this design.
Prevention controls not a reliable indicator of field performance.

177
DFMEA Occurrence – AIAG-VDA FMEA Handbook
Corporate or
Prediction of Failure
OCC Product Experience Product Line
Cause Occurring
Examples

New design based on similar technology and materials. New application, or change
in duty cycle / operating conditions. No product verification and/or validation
experience.
7
Standards, best practices, and design rules apply to the baseline design, but not the
innovations. Prevention controls provide limited indication of performance.
High
Similar to previous designs, using existing technology and materials. Similar
application, with changes in duty cycle or operating conditions. Previous testing or
field experience.
6
Standards and design rules exist but are insufficient to ensure that the failure cause
will not occur. Prevention controls provide some ability to prevent a failure cause.

178
DFMEA Occurrence – AIAG-VDA FMEA Handbook
Corporate or
Prediction of Failure
OCC Product Experience Product Line
Cause Occurring
Examples

Detail changes to previous design, using proven technology and materials. Similar
application, duty cycle or operating conditions. Previous testing or field experience,
or new design with some test experience related to the failure.
5
Design addresses lessons learned from previous designs. Best Practices re-
evaluated for this design, but have not yet been proven. Prevention controls capable
of finding deficiencies in the product related to the failure cause, and provide some
indication of performance.
Moderate

Almost identical design with short-term field exposure. Similar application, with
minor change in duty cycle or operating conditions. Previous testing or field
experience.
4
Predecessor design and changes for new design conform to best practices,
standards, and specifications. Prevention controls capable of finding deficiencies in
the product related to the failure cause, and indicate likely design conformance.

179
 DFMEA Occurrence – AIAG-VDA FMEA Handbook
Corporate or
Prediction of Failure
OCC Product Experience Product Line
Cause Occurring
Examples
Detail changes to known design (same application, with minor change in duty cycle
or operating conditions) and testing or field experience under comparable operating
conditions, or new design with successfully completed test procedure.
3 Low
Design expected to conform to Standards and Best Practices, considering Lessons
Learned from previous designs. Prevention controls capable of finding deficiencies
in the product related to the failure cause, and predict conformance of production
design.
Almost identical mature design with long term field exposure. Same application,
with comparable duty cycle and operating conditions. Testing or field experience
under comparable operating conditions.

2 Very Low Design expected to conform to Standards and Best Practices, considering Lessons
Learned from previous designs, with significant margin of confidence. Prevention
controls capable of finding deficiencies in the product related to the failure cause,
and indicate confidence in design conformance.
design conformance.
Failure eliminated through preventive control and failure cause is not possible by
1 Extremely Low
design

180
DFMEA Occurrence – AIAG-VDA FMEA Handbook
Notes:
• Product Experience: History of product usage within the
company (novelty of design, application or use case). Results of
already completed detection controls provide experience with
design.
• Prevention Control: Use of Best Practices for product design,
Design Rules, Company Standards, Lessons Learned, Industry
Standards, Material Specifications, Government Regulations and
effectiveness of prevention oriented analytical tools including
Computer Aided Engineering, Math Modeling, Simulation
Studies, Tolerance Stacks and Design Safety Margins
• A 10, 9, 8, 7 can drop based on product validation activities

181
Detection
The Detection rating (D) is an estimated measure of the
effectiveness of the detection control to reliably demonstrate the
failure cause or failure mode before the item is released for
production.
• Detection is the index associated with the best detection control
shown in the Current Control (Detection) column.
– When more than one control is identified, it is recommended that the
detection ranking of each control be included as part of the description of
the control.
– Record the value with the lowest (most effective) ranking.
– Only detection controls are ranked and recorded.

182
 DFMEA Detection Table – AIAG 4th Edition
Opportunity for Criteria: Rank Likelihood of
Detection Likelihood of Detection by Design Control Detection

No detection Absolute
No current design control; Cannot detect or is not analyzed. 10
opportunity Uncertainty

Design analysis/detection controls have a weak detection

Not likely to detect
capability; Virtual Analysis (e.g. CAE, FEA, etc.) is not 9 Very Remote
at any stage
correlated to expected actual operating conditions.

Product verification/validation after design freeze and prior

to launch with pass/fail testing (e.g. Subsystem or system
8 Remote
testing with acceptance criteria such as ride and handling,
shipping evaluation, etc.)

Product verification/validation after design freeze and prior

Post-Design Freeze to launch with test to failure testing (e.g. Subsystem or
7 Very Low
and Prior to Launch system testing until failure occurs, testing of system
interactions, etc.)

Product verification/validation after design freeze and prior

to launch with degradation testing (Subsystem or system 6 Low
testing after durability test, e.g. Function checks, etc.)
183
DFMEA Detection – AIAG-VDA FMEA Handbook
DET Ability to Detection Maturity Method Opportunity for Detection Corporate or
Detect Product Line
Examples

10 Test procedure yet to be developed. Test method not defined.

Very Low
Test method not designed specifically Pass-Fail, Test-to-Fail,
9
to detect failure mode or cause. Degradation Testing

Pass-Fail, Test-to-Fail,
8 New test method, not proven.
Degradation Testing
Low

7 Pas-Fail Testing
Proven test method for verification of
functionality or validation of
performance, quality, reliability and
6 durability; planned timing is later in the Test-to-Failure
product development cycle such that
Moderate test failures may result in production
delays for re-design and/or retooling.
5 Degradation Testing
185
 DFMEA Detection – AIAG-VDA FMEA Handbook
DET Ability to Detection Maturity Method Opportunity for Detection Corporate or
Detect Product Line
Examples

4 Pass-Fail Testing
Proven test method for verification of
functionality or validation of
performance, quality, reliability and
3 High Test-to-Failure
durability; planned timing is sufficient to
modify production tools before release
for production.
2 Degradation Testing

Prior testing confirmed that failure mode or cause cannot occur, or

1 Very High detection methods proven to always detect the failure mode or failure
cause.

186
DFMEA Detection – AIAG-VDA FMEA Handbook
• Detection Controls shall be rated for each detection activity
performed prior to delivery of the design for production.
• The timing of the detection control (before or after technical
release) should also be considered as part of the detection
rating.
– Ratings 5 – 10: Post technical release and prior to production launch.
– Ratings 1 – 4: Prior to technical release.

Considers capability to detect and timing

187
Group Activity 6

Design Controls
Group Activity 6: Design Controls
Working with the DFMEA form from the previous Group:
• For each cause of failure, identify current design controls,
placing them, as appropriate, in the “Prevention” and
“Detection” columns in the form.
– Note that a current design control which operates by detecting the
presence of the “Cause” is listed in the Detection column.

Remember…
• “Current Design Controls are those activities conducted as part of the design
process that have been completed or committed to and that will assure the
design adequacy for the design functional and
reliability requirements under consideration.”
Source: FMEA Fourth Edition, 2008

189
Group Activity 6: Design Controls
Referring to the previous index tables:
• Determine the likelihood of occurrence of the failure mode due
to that cause, considering the effect of any preventive design
action.
– Since there is a greater or lesser likelihood of occurrence for each cause,
provide a separate occurrence rating for each.

• Rate each “Detection” control in the detection action column.

Select the rating for the most effective (lowest number) control.
– Note that the same controls may operate for different
causes, and are repeated.

190
Action Priority
• At this point in the FMEA process, the team needs to decide if
further efforts are needed to reduce any risks identified.

• Due to the inherent limitations on resources, time, technology,

and other factors, the team needs to choose how to best
prioritize these efforts.

191
Action Priority
• The initial focus of the team should be oriented towards failure
modes with the highest severity rankings.
– When the severity is 9 or 10, it is imperative that the team needs to
ensure that the risk is addressed through existing design controls or
recommended actions (as documented in the FMEA).

• The priority of an action should be based on the discussions

among the team considering the concerns and product/process
knowledge as well as based on information captured by the
FMEA process.

The actual logic to drive prioritization is left to each company

and is not on the form

192
Action Priority (AP) – AIAG 4th Edition
• Risk Priority Number (RPN)
– RPN is calculated as:

RPN = Severity x Occurrence x Detection

– RPN is used to rank relative risk associated with specific

failure modes.
– Corrective action is taken thereafter to reduce the RPN, as
appropriate.

193
Cautions
“The use of an RPN threshold is NOT an acceptable practice for
determining the need for recommended actions.”
Source: FMEA Fourth Edition, 2008

• There is no RPN value that requires mandatory action.

– Applying thresholds assumes that RPNs are an accurate measure of
relative risk (which they often are not) and that continuous improvement
is not required (which it is).

194
Action Priority (AP) – AIAG-VDA FMEA Handbook
The previous FMEA manuals include using RPN to determine action
priorities. The AIAG-VDA FMEA Handbook uses an Action Priority
(AP) Table.
• The AP Table provides the logic details for the FMEA team for all
1,000 possible combinations of S, O and D.
– It includes a logic-based description for each of the action priority levels.
– Actions may be prioritized based on individual evaluations of each of the
S,O,D values and combinations of the values to identify the possible need
to reduce risk.

195
Action Priority (AP) – AIAG-VDA FMEA Handbook
• IF the organization chooses to modify the S,O,D tables for
specific products, processes, or projects, the AP table should
also be carefully reviewed and modified if necessary.
• It is recommended that potential Severity 9-10 failure effects
and Action Priority High and Medium, at a minimum, be
reviewed by management including any recommended actions
that were taken.
Note — Interpretation:
• This is not a prioritization of High, Medium, or Low risk, it is
the prioritization of the need for actions to reduce risk.

196
Action Priority (AP) – AIAG-VDA FMEA Handbook
• Priority High (H): Highest priority for action
– The team needs to either identify an appropriate action to improve
prevention and / or detection controls or justify and document why
current controls are adequate.
• Priority Medium (M): Medium priority for action
– The team should identify appropriate actions to improve prevention and
/ or detection controls, or, at the discretion of the company, justify and
document why controls are adequate.
• Priority: Low (L) Low priority for action
– The team could identify actions to improve prevention or detection
controls.

At a minimum the statement that "No Further Action is Needed”

must be included.

197
 Action Priority (AP) – AIAG-VDA FMEA Handbook

DFMEA
S 9-10
O/D 1 2 3 4 5 6 7 8 9 10
1 L L L L L L L L L L
2 L L L L M M H H H H
3 L L L L M M H H H H
4 M H H H H H H H H H
5 M H H H H H H H H H
6 H H H H H H H H H H
7 H H H H H H H H H H
8 H H H H H H H H H H
9 H H H H H H H H H H
10 H H H H H H H H H H
198
 Action Priority (AP) – AIAG-VDA FMEA Handbook

DFMEA
S 7-8
O/D 1 2 3 4 5 6 7 8 9 10
1 L L L L L L L L L L
2 L L L L M M H H H H
3 L L L L M M H H H H
4 M M M M M M H H H H
5 M M M M M M H H H H
6 M H H H H H H H H H
7 M H H H H H H H H H
8 H H H H H H H H H H
9 H H H H H H H H H H
10 H H H H H H H H H H
199
 Action Priority (AP) – AIAG-VDA FMEA Handbook

DFMEA
S 4-6
O/D 1 2 3 4 5 6 7 8 9 10
1 L L L L L L L L L L
2 L L L L L L L L L L
3 L L L L L L L L L L
4 L L L L L L M M M M
5 L L L L L L M M M M
6 L M M M M M M M M M
7 L M M M M M M M M M
8 M M M M H H H H H H
9 M M M M H H H H H H
10 M M M M H H H H H H
200
 Action Priority (AP) – AIAG-VDA FMEA Handbook

DFMEA
S 2-3
O/D 1 2 3 4 5 6 7 8 9 10
1 L L L L L L L L L L
2 L L L L L L L L L L
3 L L L L L L L L L L
4 L L L L L L L L L L
5 L L L L L L L L
not defined L L
6 L L L L L L L L L L
7 L L L L L L L L L L
8 L L L L M M M M M M
9 L L L L M M M M M M
10 L L L L M M M M M M
201
 Action Priority (AP) – AIAG-VDA FMEA Handbook

DFMEA
S1
O/D 1 2 3 4 5 6 7 8 9 10
1 L L L L L L L L L L
2 L L L L L L L L L L
3 L L L L L L L L L L
4 L L L L L L L L L L
5 L L L L L L L L L L
6 L L L L L L L L L L
7 L L L L L L L L L L
8 L L L L L L L L L L
9 L L L L L L L L L L
10 L L L L L L L L L L
202
Group Activity 7

Indices and Action Plans

Group Activity 7: Indices and Action Plans
Working with the DFMEA form from the previous Group:
• For each failure mode identified:
– Referring to the index table, determine an appropriate rating for each
cause and control.
– In the appropriate columns, enter the “highest” (most severe) index from
among those identified.

204
 6th Step
Optimization

OPTIMIZATION
1 PLANNING & PREPARATION Identification of the
Actions Necessary
to Reduce Risks
5Ts

2 STRUCTURE ANALYSIS 5 RISK ANALYSIS

Boundary/Block Diagram
Structure Development LINK SPECIAL CHARACTERISTICS TO
Interface Diagram 5b
FUNCTIONS/REQUIREMENTS

3 FUNCTION ANALYSIS
6 OPTIMIZATION
Functions and Requirements
P-Diagram (optional)
7 RESULTS DOCUMENTATION

4 FAILURE ANALYSIS
7b LINK TO DVP&R
Causes in Focus Level before
causes in Lower Levels

205
Step 6: Optimization

Action Priority Rating

New Preventive New Detection

Severity Rating (S) Action Action

Lower Occurrence Lower Detection

Rating (O) Rating (D)

Lower Action Priority Rating

206
Recommended Actions
Intent of any recommended action is to reduce any one or all of the
occurrence, detection, and/or severity rankings.
To Reduce: Consider This Action: To Accomplish this:

Severity • Change the design • Eliminate or reduce the

severity of the failure
mode
Occurrence • Change the design or improve • Prevent the cause or
engineering specification failure and its effect from
• Error proofing occurring
Detection • Increase or change in the design • Detect that the cause has
validation / verification actions occurred and take
• Design change to enhance detection corrective action
likelihood • Detect that the failure
• Revised test plan mode has occurred and
correct

207
Recommended Actions
AIAG-VDA FMEA Handbook: Recommended actions are split into
prevention and detection actions.

New!

208
 Example of the AIAG-VDA FMEA Form
DFMEA RISK ANALYSIS (STEP 5) DFMEA OPTIMIZATION (STEP 6)

Filter Code (Optional)

Occurrence (O)

Occurrence (O)
Detection (D)

Detection (D)
Severity (S)
Current Current Action

DFMEA AP

DFMEA AP
of FC/FM
DFMEA DFMEA Responsible Target
Prevention Detection Taken with Completion
of FC

Preventive Detection Person's Completion Status

Control (PC) Controls (DC) of Pointer to Date
Action Action Name Date
of FC FC or FM Evidence

Simulation 2 Sample test: 2 L None final Test dd.mm.yyy planned 6 2 1 L

of dynamic measuring the product Engineer y
forces on elastics and test: Mr. Max
brush card plastic measuring Mueller
body acc. deformation the current
FEM 6370 effects of brush under
card body acc. worst case
test spec. conditions
MRJ82/60 acc. Test
spec.
MRJ1140

209
Recommended Actions
Suggested levels for Status of Actions:
• Open
The action has neither been defined nor discussed.
• Decision Pending (optional)
The action has been defined but has not yet been decided on. A decision paper is
being created.
• Implementation Pending (optional)
The action has been decided on but has not yet been implemented.
• Completed
Completed actions have been implemented and their effectiveness has been
demonstrated and documented. A final evaluation has been done.
• Discarded
Discarded status is assigned when a decision is made to not implement an action.
This may occur when risks related to cost, implementation timing, or business strategy
are greater than technical risks.

210
Recommended Actions
Status of the Actions
• The FMEA is not considered “complete” until the team assesses
each item’s Action Priority and either accepts the level of risk or
documents closure of all actions.
• Closure of all actions should be documented before the FMEA is
placed under revision control (or released) to Serial Production.

If no actions are recommended, at a minimum, the

statement that “No Further Action is Needed” must be
included

211
Recommended Actions – Assessment of
Action Effectiveness
• When an action has been completed, Occurrence and Detection
values are reassessed as a prediction of effectiveness, and a new
Action Priority may be determined.

• However, the status of the action remains "implementation

pending" until the effectiveness has been verified. Only then
should it be changed to "completed."

212
Action Priority (AP) – AIAG-VDA FMEA Handbook
• IF the organization chooses to modify the S,O,D tables for
specific products, processes, or projects, the AP table should
also be carefully reviewed and modified if necessary.
• It is recommended that potential Severity 9-10 failure effects
and Action Priority High and Medium, at a minimum, be
reviewed by management including any recommended actions
that were taken.
Note — Interpretation:
• This is not a prioritization of High, Medium, or Low risk, it is
the prioritization of the need for actions to reduce risk.

213
Continual Improvement
The DFMEA serves as a historical record for the process.
• Therefore, the original Severity, Occurrence, and Detection
(S, O, D) numbers need to be visible or, at a minimum, available
and accessible as part of version history.
• The completed analysis becomes a repository to capture the
progression of process decisions and design refinements.
• However, original S, O, D ratings may be modified for
foundation, family or generic DFMEAs because the information
is used as a starting point for a process specific analysis.

214
 7th Step
Results
Documentation

RESULTS DOCUMENTATION
1 PLANNING & PREPARATION Communication of
Actions Taken to Reduce
5Ts Risks

2 STRUCTURE ANALYSIS 5 RISK ANALYSIS

Boundary/Block Diagram
Structure Development LINK SPECIAL CHARACTERISTICS TO
Interface Diagram 5b
FUNCTIONS/REQUIREMENTS

3 FUNCTION ANALYSIS
6 OPTIMIZATION
Functions and Requirements
P-Diagram (optional)
7 RESULTS DOCUMENTATION

4 FAILURE ANALYSIS
7b LINK TO DVP&R
Causes in Focus Level before
causes in Lower Levels

215
FMEA Results Documentation
• The scope and results of an FMEA should be summarized in a
report.
• This report can be used for communication purposes within a
company, or between companies. In this way, it is also ensured
that all details of the analysis and the intellectual property
remain at the developing company.
Note
• The FMEA is not considered "complete" until the team assesses each item's
Action Priority and either accepts the level of risk or documents closure of
all actions.
• If "No Action Taken," then the Action Priority is not changed, and the risk of
failure is carried forward into the product. Actions are open loops that
need to be closed in writing.

216
FMEA Results Documentation
The content of the documentation must fulfill the requirements
of the intended reader and details may be agreed between the
relevant parties.
The layout of the document may be company specific. The content
may include the following:
A. A statement of final status compared to original goals
established in the Project Plan
a. FMEA InTent: Purpose of this FMEA?
b. FMEA Timing: FMEA due date?
c. FMEA Team: List of participants?
d. FMEA Task: Scope of this FMEA?
e. FMEA Tool: How do we conduct the analysis Method used?

217
FMEA Results Documentation
The layout of the document may be company specific. The content
may include the following:
B. A summary of the scope of the analysis and identify what is
new.
C. A summary of how the functions were developed.
D. A summary of at least the high-risk failures as determined by
the team and provide a copy of the specific S/O/D rating tables
and method of action prioritization (i.e. Action Priority table).
E. A summary of the actions taken and/or planned to address the
high-risk failures including status of those actions.

218
FMEA Results Documentation
The layout of the document may be company specific. The content
may include the following:
F. A plan and commitment of timing for ongoing FMEA
improvement actions.
a. Commitment and timing to close open actions.
b. Commitment to review and revise the DFMEA during mass production
to ensure the accuracy and completeness of the analysis as compared
with the production design (e.g. revisions triggered from design
changes, corrective actions, etc., based on company procedures.)
c. Commitment to capture "things gone wrong" in foundation DFMEAs for
the benefit of future analysis reuse, when applicable.

219
Chapter 4: Developing the Design FMEA –

Learning Goals Chapter Outline

You should now be able to: • Design Failure Modes
• Explain design failure modes • Step 4: Failure Analysis
• Identify failure modes from – Group Activity 4
requirements – Potential Effects of Failure
• Explain causes of failure modes – Potential Causes of Failure
• Explain design controls
– Group Activity 5
• Distinguish between prevention
and detection controls • Step 5: Design Controls and Risk
• Explain the key elements of the Analysis
risk analysis – Group Activity 6
• Define requirements for Results – Evaluation: Indices and
Documentation and Action Plans
Communication – Group Activity 7
• Step 6: Optimization
• Step 7: Results Documentation

220
Chapter 5

Test Planning and Reporting

Product Design Verification & Validation
Chapter 5: Test Planning and Reporting
Learning Goals Chapter Outline
In this Chapter you will learn to: • Design Verification and Validation
• Describe a Design Verification Plan • Elements of the DVP&R
• Describe the elements of the
DVP&R

222
 DESIGN VALIDATION

DVP&R: Design Verification Plan & Report

Note: ISO 9001 and IATF 16949 consider DVP&R to be a

validation test plan, not design verification

223
Design Validation Plan
Objectives
• Itemizes all tests necessary to assure criteria and targets can and will be met
– Specifies test responsibilities, quantities and timing requirements
• Provides test results and progress made toward design targets
• Allows the program/project to move forward

Uses
• Product development tool to layout plan to meet all requirements and
present results
• Product assurance tool and working document to aid engineering personnel
• Test Schedule

224
Design Validation Plan
Test Plan
• Test plan documents test activities during each phase of product
development.

Test Plan Development

• Developed early in design phase of all new products.
• Revised based on significant changes in environment, design,
government regulations, or customer requirements.

225
Test Plan Flow Format
BASIC INPUTS: DESIGN REQUIREMENTS ADDITIONAL INPUTS
Functional Performance Industry Standards
Manufacturability Prior DFMEA/PFMEA
Maintainability Prior DVP&Rs
Serviceability Customer Feedback and FMA
Durability/Reliability Manufacturing and Design Variation/Capability
Environmental Correlation Studies
Cost/Weight Technical and Timing Constraints
Chemistry and Functionality Test Lab Capability and Experience
Interactions at User Plant VSA

DVP&R
DFMEA STEP 2: Establish Test Specifications
Acceptance Criteria
STEP 1: Identify Appropriate Tests Performance Targets
Determine Current Design Controls Test Method
• Functional Sample Size
• Environmental
• Reliability
STEP 3: Document Test Plan
Test Description
Test Specifications
Test Stage
Timing

226
 Sample Test Plan – DVP&R
TEST PLAN
Item Procedure or Test Description Acceptance Target Test Test Sample Timing
No. Standard Criteria Requirements Responsibility Stage Qty Type Start Comp.
1 Inherent 1000 Hours R 95 ABC DV 8/30/95 9/30/95

Reliability
Prediction

8/30/95 9/2/95
2 PF 99 Opening Max & Min No Failures ABC DV 5 B
Effort Range Cp > 1.33 & ABC PV 30 D 10/19/95 10/22/95
Sec 4-8-2 No Failures ABC CC E 1/30/96
Cpk > 1.33
3 PF 99 Corrosion 48 Hours No Failures ABC DV 5 B 8/30/95 9/2/95
10/18/95 10/22/95
Test Sec 3-A-1 No Failures ABC PV 5 D

DV 6 8/28/95 9/5/95
4 PF 99 Life Test 10,000 R90 C90 ABC B 10/19/95 10/22/95
Cycles R90 C90 ABC PV 6 D
Sec 5-A-2

8/28/95 9/3/95
5 PF 99 PG Test 30 K VE Four Ford DV 8 B
Sec 5-A-3 Consecutive
Successes
227
Sample Test Report
TEST REPORT
Samples Tested Notes
Qty Type Phase Actual
R96
Result MIL - HDBK - 217 Prediction
Test Report # 24375

5 B I No Fail Test Report # 98476

No Fail
30 D I Cp = 1.8
Test Report # 4876

5 B I No Test Report # 9487

5 D I Failures
No
Failures

6 B I R93 6 Tests to Failure (Weibull Analysis)

6 D I C90 6 Tests to Failure (Weibull Analysis)
R93
C90

8 D I No Test Report # 02943

Failures

228
DVP&R Program Management Responsibility
To ensure that:
• Design engineer is responsible for plan execution
• Multi-disciplinary team is formed for completion of Design
Verification Plan
• Specified tests, methods, equipment, acceptance criteria,
sample size, design level and timing are clearly documented
• Test samples, equipment, facilities, services and resources are
available and utilized for verification
• Tests are accomplished according to the DVP and project timing
chart
• Results are reviewed, analyzed and addressed

229
DVP&R Summary
• DVP&R process is used to verify designs and production parts
will fully meet design intent.

• In conjunction with the Control Plan, provides evidence of the

ability to continue meeting product requirements.

• Continuing Conformance Testing may be incorporated into the

Production Control Plan.

230
Chapter 5: Test Planning and Reporting
Learning Goals Chapter Outline
You should now be able to: • Design Verification and Validation
• Describe a Design Verification Plan • Elements of the DVP&R
• Describe the elements of the
DVP&R

231
Chapter 6

Effectively Using the AIAG-VDA

FMEA Approach
Chapter 6: Effectively Using the AIAG-VDA FMEA
Learning Goals Chapter Outline
In this Chapter you will learn to: • Key Changes to DFMEAs
• List the top changes to the • Evaluating DFMEAs
AIAG-VDA DFMEA • Changes to the Organization and
• Evaluate Supply Chain
• Identify the linkages from design – Supply Chain Standards
to shop floor using AIAG-VDA – Requirements Management and
FMEAs Decomposition
• Describe Change Management, • Organization of DFMEA and
PPM and Design Reuse and PFMEA Libraries
application of AIAG-VDA FMEAs – Design and Process Reuse
• Make the organizational changes – PPM Defect History, Cost of Poor
Quality and FMEA Linkages
necessary and get started with
– APQP and Supply Chain Changes
AIAG-VDA FMEA
– Change Management

233
Key Changes to DFMEA (AIAG-VDA FMEA)
• 7-Step FMEA Development Process
• More prescriptive Risk Analysis forms, which include a significant addition to
the number of columns of data
• Introduction of three product levels: Higher, Focus, and Lower levels
– Failures at the Focus Level, effects at the Higher Level and causes at the Lower
Level
• New definitions of Severity, Occurrence and Detection indices for Design and
Process FMEA analyses
• Use of a new composite index called “Action Priority” to categorize relative
risk
• Introduction of a new, supplemental Design FMEA for the risk analysis of
“Monitoring and System Response“ associated with a very specific type of
electronic product (FMEA-MSR)

234
EVALUATING DFMEAS

235
Evaluating DFMEAs —
Did the Supplier Use the Seven Steps?
Step 1 – Planning and Preparation
• Is there evidence of the use of the 5Ts?
Project Plan – inTent, Timing, Team, Tasks, Tools
• Has supplier defined the scope of the analysis (e.g. using a Boundary
Diagram)?
• Does the scope of analysis include the interfaces and interactions necessary?
• Was this DFMEA event planned with a family DFMEA document for design
reuse?
• Is failure history from Warranty, Customer, and internal plant data for
surrogate parts available and considered for design improvement purposes?
• Are DFM and DFA being considered in functional requirements related to
manufacturability.
• Is there a System DFMEA, Subsystem DFMEA, and Component DFMEA
planned? What is the planning for linkages between the documents?

236
Evaluating DFMEAs —
Did the Supplier Use the Seven Steps?
Step 2 – Structure Analysis:
• Was the Structure Analysis conducted? The structure should include the
Focus Element, and the Higher and Lower Elements at the very least.
• Is there an interface diagram or P-Diagram included? Does it include all the
Key Functions and its requirements including the following:
– Noise Factors – Input/Output
– Control Factors – Non-functional Requirements
– Unintended Output?
Step 3 – Function Analysis
• Does the Function Analysis include Functions and Requirements?
• Are the functions defined as “verb-noun” and do the requirements have the
following characteristics – unambiguous; understandable; atomic (singular);
achievable; verifiable?
• Are there interface functions for an assembly?

237
Evaluating DFMEAs —
Did the Supplier Use the Seven Steps?
Step 4 – Failure Analysis
• Are the failure modes in terms of not achieving the
requirement?
– Are there failure modes for all requirements, as applicable?
• Is the effect a failure caused by the focus element failure?
• Is the cause focused on the “Focus Element” design and how the
requirements or design at the Focus Element could cause the
failure?

238
Evaluating DFMEAs —
Did the Supplier Use the Seven Steps?
Step 5 – Risk Analysis
• Has the DFMEA applied the Severity, Occurrence and Detection correctly
from the tables? Have a few been sampled for consistency?
– The Severity should be based on the “highest” failure looking at the cause and
effect linkage up to the customer.
– The Occurrence is based on prevention controls. Is significant error-proofing
applied?
– Is the Detection control and rating based on the most effective detection control?
• Was the Action Priority (AP) logic correctly applied and sampled?
• Are the prevention and detection controls carefully transferred to the DVP&R
or test plans and sampled?
• Are the Special Functions identified for Severity 9 & 10 Requirements /
Functions and Severity 8 & 7 Requirements / Functions with High
Occurrence?

239
Evaluating DFMEAs —
Did the Supplier Use the Seven Steps?
Step 6 – Optimization
• Does the recommended action follow the logic of the AP tables:
– Severity 9 & 10 with High and Medium AP rating?
– Severity 8 & 7 with High Occurrence or High Detection?
– Is “none” recorded when there are no recommended prevention and detection
controls actions?
• Is collaboration between the customer or supplier (including internal
supplier) considered for severity reduction?
• Are there opportunities for error-proofing or ability to move a detection
control up earlier in the design cycle?
• Is there a responsible party, promised date, status, and action taken with
evidence of actions taken, completion date, and a reassessment of Severity,
Occurrence, and Detection?
• Are there promised dates which have been missed? Are promised dates too
far out into the future? Are action taken dates and promised dates showing
consistent discrepancies?

240
Evaluating DFMEAs —
Did the Supplier Use the Seven Steps?
Step 7 – Results Documentation
• Is there evidence of risk communication? Did it go to the right
parties?
• How is the organization communicating and linking to supplier
DFMEAs? Customer DFMEAs?
• How much improvement was seen as a result of this AIAG-VDA
DFMEA activity?
• How is this information captured for change management and
lessons learned?

See Appendix for a Suitability Review checklist

that can be used to evaluate DFMEAs

241
Getting Started Checklist and Action Plan
• Conduct Executive Overview
• Train Facilitators and Team
• Procure AIAG-VDA Software that incorporates the 7 steps and
provides linkages to DVP&R and Control Plans
• Incorporate AIAG-VDA FMEA into APQP Process
• Establish Customer and Supply Chain Linkages
• Update Purchasing
• Establish Requirements Management Process
• Procure Software and Establish Libraries and Reuse Strategy
• Develop strategy for pilot and launch program

242
ORGANIZATION OF THE DFMEA AND
PFMEA LIBRARIES

Design and Process Reuse

243
Linkage Between DFMEA and DVP&R
• The third step of the 7-Step Process, Functional Analysis, links
the function-requirements.
• The fifth step, Risk Analysis, identifies “preventive and
detective controls” linked to the function and the requirement.
• These controls are the same controls in the DVP&R or test plan.
– Cue-Biz recommends that DVP&R house both controls.
• The linkage between the requirements and the test plan in the
“V” is provided by the DFMEA and DVPR linkages.

244
Linkages Between DFMEA, PFMEA and the Shop
Floor

245
Design and Process Reuse Libraries
3
1 Pick the Process you need from
Manufacturing the Library
Process
Libraries
Receivin
Polish
g
Product A Product B Product C
Mill Wash
2 Receivin
g
Receivin Receivin
g g

Drill Pack For each Process, Mill Drill Heat

Treat
create PFD, PFMEA,
Heat Heat
Treat
Assembly Control Plan Drill
Treat Grind

Grind Ship Grind

Wash Pack

Pack
Pack Polish

Assembly
Ship Ship
Ship

PROCESS EXAMPLE

246
 PPM Defect History, Cost Of Poor Quality And
FMEA Linkages
PPM History

Failure
Mode
AIAG-VDA FMEA

Pareto Failures
Occurrence

Cost of Quality can be calculated by Scrap,

Rework and Customer and Warranty failure costs

247
APQP and Supply Chain Changes

Sales and Purchasing may need to have language on

collaboration between customer, supplier and subsupplier

Phase IV -
Phase II - Phase III - Product
Phase I - Planning Feedback
Design Process and
Process

AIAG-VDA DFMEA and

Early PFMEA &
Sourcing Requirements Flow
Down

248
Change Management and AIAG-VDA FMEA

AIAG-VDA DFMEA 8D

Includes Customer, Supplier and Subsupplier Information

Change
Subsupplier
Change

249
Chapter 6: Effectively Using the AIAG-VDA FMEA
Learning Goals Chapter Outline
You should now be able to: • Key Changes to DFMEAs and
• List the top changes to the PFMEAs
AIAG-VDA DFMEA and PFMEA • Evaluating DFMEAs
• Evaluate DFMEAs and PFMEAs • Evaluating PFMEAs
using checklists • Changes to the Organization and
• Identify the linkages from design Supply Chain
to shop floor using AIAG-VDA – Supply Chain Standards
FMEAs – Requirements Management and
• Describe Change Management, Decomposition
PPM and Design Reuse and • Organization of DFMEA and
application of AIAG-VDA FMEAs PFMEA Libraries
• Make the organizational changes – Design and Process Reuse
necessary and get started with – PPM Defect History, Cost of Poor
AIAG-VDA FMEA Quality and FMEA Linkages
– APQP and Supply Chain Changes
– Change Management
250
FMEA Summary
FMEA Summary
• FMEA is a systematic analysis tool that, if used by an
experienced team of qualified SMEs and performed with reliable
evaluation of concepts, allows for fewer potential failures in
systems, products or processes
• FMEA ensures that potential failure modes and their causes are
recognized and prevented
• FMEA puts process and product knowledge together
• FMEA provides the strategic underpinnings to make
development and operational processes as bug-free as possible

Knowledge Management!
252
FMEA Objectives
Risk reduction through:
• Support of the development and improvement processes
• Identification of potential types of errors and their causes, and the effects in
products, and process-related activities
• Assistance in the analysis of new or modified products, machinery,
manufacturing and assembly processes
• Evaluation of potential failure consequences for the customer, the operator
of the process or the environment
• Identification and development of process characteristics and key variables
on which inspection checks are to be concentrated
• Development of a ranking for errors, mainly for instituting corrective and
preventive actions

253
Analytical Approach
• How could the product fail and not meet expectations?
– In the application?
– In the assembly process?
– In the field / service, or in testing?

• What would be the consequence of error?

– For customers?
– For the sites?
– During the life of the program?
– How might the failure effects be noticed or perceived?

254
Analytical Approach
• How could the failure mode occur?
– What potentially caused the failure mode?
– Brainstorm with SMEs
– How often has the error occurred in the past?

• What is in place to catch our mistakes (Detection)?

– Current detection actions?
– Avoidance, verification, validation?
– How effective are our actions?

255
FMEA Advantage

256
FMEA Summary
• FMEA is a systematic analysis tool that, if used by an
experienced team of qualified SMEs and performed with reliable
evaluation of concepts, allows for fewer potential failures in
systems, products or processes
• FMEA ensures that potential failure modes and their causes are
recognized and prevented
• FMEA puts process and product knowledge together
• FMEA provides the strategic underpinnings to make
development and operational processes as bug-free as possible

Knowledge Management!
257
Analytical Approach
• What is the acceptable level of risk?
– Health, safety, compliance?
– Compared to others products / processes?

• What should we do about those potential risks?

– Who is responsible for corrective actions?
– What actions are appropriate?
– What risks will we accept?
– How can we reduce the RPN?

258
Maintaining FMEAs
The FMEA documents living information and should be reviewed
whenever there is a product design change, and should be updated
as required.

• To have value, FMEA updates must occur at these change points:

– New design or process is planned
– Modification to a component, system or process is planned
– Important – Update FMEA to capture problem solving analyses and
results
– Component or system is used in a new environment, location or
application

Knowledge Management

259
FMEA Keys
• Manage Quantified Risk
– Focus on Known Potential Risks First

• Act
– Improvement Proposals
– Responsibility, Timing, Tracking
– Verification

The Design FMEA must not rely on the process controls to

overcome potential design weaknesses, and must take into
account the limitations of the manufacturing process
(concurrent engineering).

260
Thank You!
Questions?
info@cue-biz.com

261