Вы находитесь на странице: 1из 18


Understanding of
FMEA - Failure Mode and Effects Analysis
Fourth Edition - June 2008
The FMEA Fourth Edition is a reference manual to be used by suppliers

Failure Mode and Effects to Chrysler, Ford Motor Company, and General Motors Corporation as
a guide to assist them in the development of both Design and Process
FMEAs. The manual does not define requirements; it is intended to
clarify questions concerning the technical development of FMEAs.


C.Shanmuga sundaram
System Consultant
1 2

• First used in 1960’s in the Aerospace industry during the Apollo Failure Mode and Effects Analysis (FMEA) is an engineering
technique used to define, identify, and eliminate known and / or
• In 1974, the Navy developed MIL-STD-1629 regarding the use of potential failures, problems, errors, and so on from the system,
design, process, and / or service before they reach the customer.

• In the late 1970’s, the automotive industry was driven by liability

costs to use FMEA

• Later, the automotive industry saw the advantages of using this tool
to reduce risks related to poor quality

3 4
• FMEA is one of the most important early preventive actions in
system, design, process or service which will prevent failures
FMEA and errors from occurring and reaching the customer.

• FMEA provides a systematic method of examining all the

ways in which a failure can occur.
DESIGN PROCESS • For each failure, an estimate is made of its effect on the total
system, design, process, or service, of its occurrence
(frequency) and its detection.

5 6

FMEA PROCESS • The FMEA will identify corrective actions required to prevent failures
from reaching the customer, thereby assuring the highest durability,
• Its most visible result is the documentation of the collective quality and reliability possible in a product or service.
knowledge of Cross-Functional Team (CFT).
• A good FMEA
• Part of the evaluation and analysis is the assessment of risk. v Identifies known and potential failure modes.

• The important point is that a discussion is conducted v Identifies the causes and effects of each failure mode.
regarding the design (Product or Process), review of the
v Prioritizes the identified failure modes according to the Risk
functions and any changes in application, and the resulting Priority Number (RPN) the product of frequency of occurrence,
risk of potential failure. severity and detection.

v Provides for problem follow-up and corrective action.

7 8
• There are three basic cases for which FMEA process is to be applied, Interpretation of the FMEA:
each with a different scope or focus.
• The essence of the FMEA is to identify and prevent known and
Case 1: New designs, new technology or new process.
potential problems from reaching the customer. To do that one has
The scope of the FMEA is the complete design, technology or made some assumptions, one of which is that problems have
process. different priorities. Thus, finding that priority is important and the
Case 2: Modifications to existing design or process. thrust of the methodology.
The scope of the FMEA should focus on the modification to • There are three components that help define the priority of
design or process, possible interactions due to the modification, failures:
and field history. This can include changes in regulatory
requirements. v Occurrence (O)
Case 3: Use of an existing design or process in a new environment, v Severity (S)
location, application or usage profile (including duty cycle,
v Detection (D)
regulatory requirements etc.)
The scope of the FMEA should focus on the impact of the new • Occurrence is the frequency of the failure.
environment, location or application usage on the existing • Severity is the seriousness (effects) of the failure.
design or process. • Detection is the ability to detect the failure before it reaches the
9 10

The Process of conducting a FMEA 2. Functional Block Diagram and / or Process Flow Chart

• To conduct a FMEA effectively one must follow a systematic • For System and design FMEAs the functional block diagram is
approach. applicable.

• The recommended approach is a Eight step method that facilitates the • For the process and service FMEA the process flow chart is
system, design, product, process and service FMEA. applicable.

1. Select the Team and brain storm • The idea is to make sure that everyone is on the same wave length.
Does everyone understand the problem ?
• The team must be cross-functional and multi-disciplined and the
team members must be willing to contribute. 3. Prioritize

• The team to prioritize the opportunities of improvement. Is the • After the team understands the problem, the actual analysis begins.
concern in a system, design, product, process or service ? Frequent questions are: What Part is important ? Where should the
team begin ?
• Sometimes, this step is completely bypassed because the
prioritization is defects. The customer has identified the priority or
some other input determination has been made by the management
to start at a given point.
11 12
4. Data Collection • Information from this step will be used to fill in the columns of the
FMEA form in relationship to the effects of the failure, existing
• This is where the team begins to collect the data of the failures controls and discussing the estimation of severity, occurrence and
and categories them appropriately. At this point the team begins detection.
to fill the FMEA form. The failures identified are the failure modes
of the FMEA. 6. Results
5. Analysis • The theme here is data driven. Based on the analysis, results are
• Now the data are utilised for a resolution.
The information from this step will be used to quantify the severity,
• The reason for the data is to gain information that is used to gain occurrence, detection and RPN. The appropriate columns of the FMEA
knowledge. Alternatively, that knowledge contributes to the will be completed.
7. Confirm / Evaluate / Measure
• The Analysis may be qualitative or quantitative. The team may
use brainstorming, cause and effect analysis, QFD, DOE, SPC After the results have been recorded, it is time to confirm, evaluate and
and anything else that team members think is suitable. measure the source of failure.

13 14

This evaluation takes the form of three basic questions:

Process FMEA
- Is the situation better than before ?
Used to analyse manufacturing and assembly processes.
- Is the situation worse than before ?
- Is the situation the same as before ? A process FMEA focuses on failure modes caused by process or
assembly deficiencies.
The information from this step will be used recommend actions and to see
the results of those actions in the corresponding columns of the FMEA The output of the process FMEA is
• A potential list of failure modes ranked by the RPN.
8. Do it all over again • A potential list of critical and / or significant characteristics.

Regardless of how step 7 is answered, the team must pursue • A potential list of recommended actions to address the critical
and significant characteristics.
improvement all over again because of the underlying philosophy of
FMEA, which is continual improvement. • A potential list to eliminate the causes of failure modes, reduce
their occurrence and improve detection.

15 16
The benefits of the process FMEA are that it: Customer Defined
• Identifies process deficiencies and offers a corrective action plan.
The definition of “Customer” for a PFMEA should normally be the “End
• Identifies the critical and / or significant characteristics and helps in User”. However, the customer can also be a subsequent or
developing control plans.
downstream manufacturing or assembly operation, a service
• Establishes a priority of corrective actions.
operation, or regulator.
• Assists in the analysis of the manufacturing or assembly process.

• Documents the basis for changes.

17 18

Team Approach Design Considerations

The PFMEA is developed and maintained by a multi-disciplinary (or The team should assume the product as designed will meet the
cross-functional) team typically led by the responsible engineer. design intent.
During the initial development of the PFMEA, the responsible
During the development of a PFMEA, the team may identify design
engineer / team leader is expected to directly and actively involved
opportunities which, if implemented, would either eliminate or reduce
representatives from all affected areas. These areas should include
the occurrence of a process failure mode. For example, adding a
but are not limited to design, assembly, manufacturing, materials,
feature to a part and a matching feature to a fixture will eliminate the
quality, service, and suppliers, as well as the area responsible for the
possibility of an operator placing a part in the wrong orientation. Such
next assembly. The PFMEA should be a catalyst to stimulate the
information must be provided to the responsible design engineer as
interchange of ideas between the areas affected and thus promote a
well as the tooling / equipment / fixture design-responsible individual
team approach.
for consideration and possible implementation.

19 20
Development of a Process FMEA Prerequisites
• The process-responsible engineer / team leader has at his or her
disposal a number of documents that will be useful in preparing the • A PFMEA should begin with the development of information to
PFMEA. The PFMEA begins by developing a list of what the process understand the manufacturing and assembly operations being
is expected to do and what it is expected not to do, i.e., the process analyzed and define their requirements.
• The process flow diagram is a primary input to the PFMEA. The
• The PFMEA should begin with a flow chart of the general process.
flow diagram is used as a tool to help establish the scope of
This flow chart should identify the product / process characteristics
analysis during manufacturing system design.
associated with each operation. Identification of product effects from
the corresponding DFMEA should be included. Copies of the flow
chart used in the PFMEA preparation should accompany it.
• In order to facilitate documentation of the analysis of potential
failures and their consequences, example PFMEA forms have been
developed and are provided. The minimum information content
required for a PFMEA is discussed below: 21 22

Process Flow Diagram and Linkage to PFMEA High Level Process Map

A process flow diagram describes the flow of the product through the
process - from incoming to outgoing. This should include each step in
a manufacturing or assembly process as well as their related outputs
(product characteristics, source of variation, etc.,). The detail of the
process flow depends on the stage of process development Detailed Process Flow Diagram
discussion. The initial flow diagram is generally considered a high
level process map. It needs more detailed analysis to identify the
potential failure modes.

High Level to Detailed Process Maps

23 24
• The PFMEA should be consistent with the information in the process
flow diagram. The scope of the process flow diagram should include
all manufacturing operations from processing of individual
components to assemblies including shipping, receiving,
transportation of materials, storage, conveyors, labeling, etc., A
preliminary risk assessment using the process flow diagram may be
performed to identify which of these operations or individual steps
can have an impact on the product manufacturing and assembly and
should be included in the PFMEA.
• The PFMEA development continues by identifying the
requirement(s) for each process / function. Requirements are the
outputs of each operation / step and relate to the requirements for
the product. The requirements provide a description of what should
be achieved at each operation / step. The requirements provide the
team with a basis to identify potential failure modes.
• In order to assure continuity, it is highly recommended that the same
cross-functional team develop the Process Flow Diagram, PFMEA,
and Control Plan.
• See Figure for an example process flow diagram. 25
Example Process Flow Diagram 26

Other Tools and Information Sources Research Information

Other sources of information that are useful in providing the team with After establishing the scope of the analysis effort, the team should
begin by reviewing historical information. The areas to review should
ways to focus and capture discussions on the requirements of the
process include:
• Lessons that have been learned from previous product and
• DFMEA process design implementation, and

• Drawings and design records • Any information available that establishes best practices including
items such as guidelines and standards, standard part
• Bill of Process identification, or error-proofing methods.

• Interrelationship (Characteristic) matrix Quality performance information available from similar, previous
product and process designs, including items such as: process yield,
• Internal and external (customer) non conformances (i.e. known first time capability (both end of line and at each operation). Parts per
failure modes based on historical data) Million (PPM), process capability indices (Cpk and Ppk) and warranty
• Quality and Reliability History The information can be useful input for determination of severity,
occurrence and detection rankings.

27 28
Basic Structure
• The FMEA format utilized should address:
- Functions, requirements and deliverables of the product or
process being analyzed.
- Failure modes when functional requirements are not met.
- Effects and consequences of the failure mode.
- Potential causes of the failure mode.
- Actions and controls to address the causes of the failure
mode and
- Actions to prevent recurrence and the failure mode.

29 30

Header of the Process FMEA Form (A-H) Key Date (E)

• The following describes the information to be entered on the form. • Enter the initial PFMEA due date, which should be exceed the
• The PFMEA header should clearly identify the focus of the PFMEA as well scheduled start of production date. In case of a supply
as information related to the document development and control Process. organization, this date should not exceed the customer required
This should include an FMEA number, identification of the scope, design Production Part Approval Process (PPAP) submission date.
responsibility, completion dates, etc., The header should contain the
following elements: FMEA Date (Original)_(F)
FMEA Number (A) • Enter the date the original PFMEA was completed and the latest
• Enter an alphanumeric string which is used to identify the PFMEA revision date.
document. This is used for document control. Core Team (G)
Item (B)
• Enter the team members responsible for developing the PFMEA.
• Enter the name and number of the system, subsystem or component for Contact information (e.g., name, organization, telephone number,
which the process is being analyzed. and email) may be included in a referenced supplemental
Process Responsibility (C) document.
• Enter the OEM, organization, and department or group who is process Prepared by (H)
design responsible. Also enter the supply organization name, if applicable.
Mode Year(s) / Program(s) (D) • Enter the name and contact information including the organization
(company) of the engineer / team leader responsible for preparing
• Enter the intended model year(s) and program(s) that will use or be
affected by the process being analyzed (if known).
the PFMEA.
31 32
Body of the PFMEA Form (fields a to n) Process Step (a1)
• The body of the PFMEA contains the analysis of risks related to
• Enter the identification of the process step or operation being
the potential failures and improvement action being taken.
analyzed, based on the numbering process and terminology. For
Process Step / Process Function / Requirements (a)
example, enter the number and identifier (e.g. name). Process
• Process Step / Function can be separated into two (or more) numbering scheme, sequencing, and terminology used should be
columns or combined into a single, bridged column which
consistent with those used in the process flow diagram to ensure
encompasses these elements. Process Steps may be listed in the
Process Step / Function column or additional column(s) may be traceability and relationships to other documents (Control Plans,
added containing the functions or requirements of that process operator instructions, etc.,) Repair and rework operations should
step. “Process Step”, “Function”, and “Requirements” are also be included.
described below:

33 34

Process Function (a1) Requirements (a2)

• List the process function that corresponds to each process step or
• List the requirements for each process function of the process
operation being analyzed. The process function describes the step or operation being analyzed. Requirements are the inputs to
purpose or intent of the operation. A risk analysis is recommended
the process specified to meet design intent and other customer
in order to limit the number of steps to be included to only those requirements. If there are multiple requirements with respect to a
that add value or otherwise are seen as likely to have a negative
given function, each should be aligned on the form with the
impact on the product. If there are multiple process functions respective associated failure modes in order to facilitate the
being analyzed with respect to a given operation, each should be
aligned on the form with its respective “Requirements” to aid in
• Requirements become a3 if Process Step and Process Function
the development of the associated failure modes.
are split into separate columns, e.g., a1 and a2.
• Process Function becomes a2 if Process Step and Process
Function are split.

35 36
Potential Failure Mode (b) List the potential failure mode(s) for the particular operation in terms of
the process requirement(s) (e.g., as documented in the process flow
• Potential failure mode is defined as the number in which the diagram). Assume that the failure could occur but may not necessarily
process could potentially fail to meet the process requirements occur. Potential failure modes should be described in technical terms,
(including the design intent). not as a symptom noticeable by the customer. See the example table
• In preparing the FMEA, assume that the incoming part(s) /
Process Step /
material(s) are correct. Exceptions can be made by the FMEA Requirement Potential Failure Mode
team where historical data indicate deficiencies in incoming part Operation 20: Four Screws Fewer than four screws
Attach seat cushion
quality. The team should also assume that the basic design of the to track using a
Specified screws Wrong screw used (larger dia.)

product is correct; however, if there are design issues which result torque gun Assembly sequence: First Screw placed in any other hole
screw in right front hole
in process concerns, those issues should be communicated to the
Screws fully seated Screw not fully seated
design team for resolution.
Screws torqued to dynamic Screw torqued too high
torque specification
Screw torqued too low

37 38

• If the requirements have been well defined, then the potential Potential Effect(s) of Failure (c)
failure mode is readily identifiable by determining the condition • Potential effects of failure are defined as the effects of the failure
when a specific requirement is not met. Each requirement may mode as perceived by the customer(s).
have multiple failure modes. A large number of failure modes • The effects of the failure should be described in terms of what the
customer might notice or experience, remembering that the
identified for a single requirement usually indicates that the
customer may be an internal customer as well as the ultimate End
requirement is now well defined. User. The customer(s) in this context could be the next operation,
subsequent operations or locations, the dealer, and / or the
• The assumption is made that the failure could occur but may not vehicle owner. Each must be considered when assessing the
necessarily occur - consequently the use of the word “potential”. potential effect of a failure. The product effects in the PFMEA
should be consistent with those in the corresponding DFMEA.
• Verification of completeness of the potential failure modes can be
• If the failure mode could impact safety or cause non compliance
made through a review of past things-gone-wrong, concerns, to regulations, this should be clearly identified in the PFMEA.
reject or scrap reports, and group brainstorming. Sources for this
• For the End User, the effects should be stated in terms of product
should also include a comparison of similar processes and a or system performance. If the customer is the next operation or
review of customer (End User and subsequent operation) claims subsequent operation(s) location(s), the effects should be stated
relating to similar components. in terms of process / operation.
39 40
In order to determine the Potential Effect(s), the following questions should be 2. What is the potential impact on the End User?
Independent of any controls planned or implemented including error or
1. Does the Potential Failure Mode physically prevent downstream
processing or cause potential harm to equipment or operators? mistake-proofing, consider what the End User would notice or experience.
This includes an inability to assemble or join to a mating component at any This information may be available within the DFMEA. Once determined, go
subsequent customer’s facility. If so, then assess the manufacturing to question 3. Examples could include:
impact. No further analysis is required. If not, then go to question 2.
Examples could include: • Noise

• Unable to assemble at operation x • High effort

• Unable to attach at customer facility • Unpleasant odor
• Unable to connect at customer facility • Intermittent operation
• Cannot bore at operation x
• Water leak
• Causes excessive tool wear at operation x
• Damages equipment at operation x • Rough idle
• Endangers operator at customer facility • Unable to adjust
Note: The location, station or operations at which the effect occurs should • Difficult to control
be identified. If at a customer’s facility, this should be stated.
• Poor appearance

41 42

Requirement Failure Mode Effect

3. What would happen if an effect was detected prior to reaching the
Four Screws Fewer than four screws End User: Loose seat cushion and noise.
End User?
Manufacturing and Assembly: Stop shipment
and additional sort and rework due to
The potential effect at the current or receiving locations also needs to be affected portion.
considered. Examples could include: Specified Screws Wrong screw used Manufacturing and Assembly: Unable to
(larger dia.) install screw in station.
• Line shutdown
Assembly sequence: Screw placed in any Manufacturing and Assembly: Difficult to
• Stop shipment First screw in right front other hole install remaining screws in station.
• Yard hold
Screws fully seated Screw not fully seated End User: Loose seat cushion and noise.
• 100% of product scrapped Manufacturing and Assembly: Sort and
rework due to affected portion.
• Decreased line speed
Screws torqued to Screw torqued too high End User: Loose seat cushion due to
• Added manpower to maintain required line rate dynamic torque subsequent fracture of screw and noise.
specification Manufacturing and Assembly: Sort and
Note: If more than one potential effect is identified when considering rework due to affected portion.
questions 2 and 3, all may be listed, but for purposes of the analysis, Screw torqued too low End User: Loose seat cushion due to gradual
only consider the worst case when documenting the resulting Severity loosening of screw and noise.
Manufacturing and Assembly: Sort and
ranking. rework due to affected portion.

Example of Effects
43 44
Criteria: Criteria:
Severity (S) (d) Effect Severity of Effect on Product
(Customer Effect)
Effect Severity of Effect on Process
(Manufacturing/Assembly Effect)

Potential failure mode affects safe vehicle operation May endanger operator (machine or assembly) without
• Severity is the value associated with the most serious effect for a Failure to Meet
Safety and/or
and/or involves noncompliance with government 10 Failure to Meet
Safety and/or
regulation without warning.
given failure mode. Severity is a relative ranking within the scope Requirements Potential failure made affects safe vehicle operation
and/or involves noncompliance with government 9 May endanger operator (machine or assembly) with
of the individual FMEA. regulation with warning. warning.
Loss of primary function (vehicle inoperable, does not 100 %of product may have to be scrapped. Line
8 Major Disruption
Suggested Evaluation Criteria Loss or affect safe vehicle operation). shutdown or stop ship.
Degradation of
Degradation of primary function (vehicle operable, but at A portion of the production run may have to be
Primary Significant
reduced level of performance). 7 scrapped. Deviation form primary process including
• The team should agree on evaluation criteria and a ranking Function Disruption
decreased line speed or added manpower.

system and apply them consistently, even if modified for individual Loss or
Loss of secondary function (vehicle operable, but comfort
/ convenience functions inoperable). 6
100 % of production run may have to be reworked off
line and accepted.
process analysis (See Table below for criteria guidelines). Degradation of
Secondary Degradation of secondary function (vehicle operable, but
Disruption A portion of the production run may have to be
Function comfort / convenience functions at reduced level of 5 reworked off line and accepted.
• It is not recommended to modified criteria for ranking values 9 and
Appearance or Audible Noise, vehicle operable, item 100% of production run may have to be reworked in
10. Failure modes with a rank of 1 should not be analyzed further. does not conform and noticed by most customers (> 75%)
station before it is processed.

Appearance of Audible Noise, vehicle operable, item does Disruption A portion of the production run may have to be
not conform and noticed by many customers (50%). 3 reworked in-station before it is processed.

Appearance or Audible Noise, vehicle operable, item Slight inconvenience to process, operation, or
Annoyance does not conform and noticed by discriminating 2 Minor Disruption operator.
customers (< 25%)

No effect No discernible effect. 1 No effect No discernible effect.

45 Suggested PFMEA Severity Evaluation Criteria 46

Classification (e) Potential Cause(s) of Failure Mode (f)

• Potential cause of failure is defined as an indication of how the failure
• This column may be used to highlight high priority failure modes could occur, and is described in terms of something that can be
or causes that may require additional engineering assessment. corrected or can be controlled. Potential cause of failure may be an
• This column may also be used to classify any special product or indication of a design or process weakness, the consequence of which
is the failure mode.
process characteristics (e.g., critical, key, major, significant) for
components, subsystems, or systems that may require additional • To the extent possible, identify and document every potential cause for
process controls. each failure mode. The cause should be detailed as concisely and
completely as possible. Separating the causes will result in a focused
• Customer specific requirements may identify special product or analysis for each and may yield different measurement, controls, and
process characteristic symbols and their usage. action plans. There may be one or more causes that can result in the
failure mode being analyzed. This results in multiple lines for each
• Where a special characteristic is identified with a severity of 9 or cause in the table or form.
10 in the PFMEA, the design responsible engineer should be
notified since this may affect the engineering documents. • In preparing the PFMEA, the team should assume that the incoming
part(s) / material(s) are correct. Exceptions can be made at the team’s
discretion where historical data indicate deficiencies in incoming part
• Only specific errors or malfunctions (e.g. seal not installed or seal
installed inverted) should be listed. Ambiguous phrases (e.g., operator
error or seal mis-installed, etc.,) should not be used. See Table for
47 48
Example of Causes and Controls.
Occurrence (O) (g) Criteria: Occurrence of Cause – PFMEA (Incidents per
Likelihood of Failure Rank
• Occurrence is the likelihood that a specific cause of failure will occur. The > 100 per thousand
likelihood of occurrence ranking number has a relative meaning rather Very High 10
> 1 in 10
than an absolute value (See Table). 50 per thousand
• Estimate the likelihood of occurrence of a potential cause of failure on a 1 1 in 20
to 10 scale. A consistent occurrence ranking system should be used to 20 per thousand
High 8
ensure continuity. The occurrence ranking number is a relative ranking 1 in 50
within the scope of the FMEA and may not reflect the actual likelihood of 10 per thousand
occurrence. 1 in 100
2 per thousand
• The “Incident per items / vehicles” is used to indicate the number of 6
1 in 500
failures that are anticipated during the process execution. If statistical .5 per thousand
data are available from a similar process, the data should be used to Moderate 5
1 in 2,000
determine the occurrence ranking. In other cases, a subjective .1 per thousand
assessment can be made by using the word descriptions in the left hand 4
1 in 10,000
column of the table, along with input from the appropriate process .01 per thousand
knowledge source to estimate the ranking. 3
1 in 100,000
Suggested Evaluation Criteria <.001 per thousand
1 in 1,000,000
• The team should agree on evaluation criteria and a rankings system and Very Low Failure is eliminated through preventive control 1
apply them consistently, even if modified for individual process analysis.
Occurrence should be estimated using a 1 to 10 scale based upon Table Suggested PFMEA Occurrence Evaluation Criteria
49 50
as a guidelines.

Current Process Controls (h) • The preferred approach is to first use prevention controls, if
possible. The initial occurrence rankings will be affected by the
• Current Process Controls are descriptions of the controls that can
either prevent to the extent possible, the cause of failure from prevention controls provided they are integrated as part of the
occurring or detect the failure mode or cause of failure should it process. The initial detection rankings will be based on process
occur. controls that either detect the cause of failure, or detect the failure
• There are two types of Process Controls to consider:
• Because, statistical charting methods (i.e. Statistical Process
Control) typically use sampling to assess process stability and
• Eliminate (prevent) the cause of the failure or the failure mode detect out-of-control conditions they should not be considered
from occurring, or reduce its rate of occurrence. when evaluating the effectiveness of specific Detection Controls.
Detection SPC may, however, be considered as a Prevention Control for
specific causes whose trends are identifiable in advance of an
• Identify (detect) the cause of failure or the failure mode, leading to actual non-conformance being produced, such as tool wear.
the development of associated corrective action(s) or counter-

51 52
• The example PFMEA form in this manual has two separate Requirement Failure Mode Cause Prevention Control Detection Control

columns for Prevention Controls and Detection Controls to assist Screws

torqued until
Screw not fully
Nut runner not held
perpendicular to
Operator training Angle sensor included in nut
runner to detect cross-threading
fully seated work surface by not allowing part to be removed
the team in clearly distinguishing between these two types of operator from fixture until value is satisfied
controls. This allows for a quick visual determination that both Screws Screw torqued Torque setting set too Password protected Torque validation box included in
torqued to to high high by non-set-up control panel (only set- set-up procedure to validate
types of process controls have been considered. dynamic personnel up personnel have setting prior to running.
torque assess)
• If a one-column (for process controls) form is used, then the Torque setting set too Training of set-up Torque validation box included in
high by set-up personnel set-up procedure to validate
following prefixes should be used. For prevention controls, place a personnel setting prior to running.

‘P’ before or after each prevention control listed. For detection Setting added to set-
up instructions.
controls, place of ‘D’ before or after each detection control listed Screw torqued Torque setting at too Password protected Torque validation box included in
(See Table Example of Causes and Controls). too low low by non-set-up
control panel (only set-
up personnel have
set-up procedure to validate
setting prior to running.

Torque setting set too Training of set-up Torque validation box included in
low by set-up personnel set-up procedure to validate
personnel setting prior to running.

Settings added to set-

up instructions.

53 Example of Causes and Controls 54

Detection (D) (i) • Random quality checks are unlikely to detect the existence of an
• Detection is the rank associated with the best detection control isolated problem and should not influence the detection ranking.
listed in the Detection Controls column. Detection is a relative
ranking within the scope of the individual FMEA. In order to achieve Suggested Evaluation Criteria
a lower ranking, generally the planned detection control has to be
• The team should agree on evaluation criteria and a ranking
• When more than one control is identified, it is recommended that
the detection ranking of each control be included as part of the system and apply them consistently, even if modified for individual
description of the control. Record the lowest ranking value in the product analysis. Detection should be estimated using Table as a
Detection column.
• Assume the failure has occurred and then assess the capabilities of
all “Current Process Controls” to prevent shipment of the part • The ranking value of one (1) is reserved for failure prevention
having this failure mode. Do not automatically presume that the
detection ranking is low because the occurrence is low, but do through proven process design solutions.
assess the ability of the process controls to detect low frequency
failure modes or prevent them from going further in the process.

55 56
Criteria: Likelihood of
Opportunity for Detection Rank
Likelihood of Detection by Process Control Detection Determining Action Priorities
No current process control; Cannot detect or is not analyzed. Almost
No detection opportunity 10
Impossible • Once the team has completed the initial identification of failure
Not likely to detect at any
Failure Mode and/or Error (Cause) is not easily detected (e.g., random audits)
9 Very Remote modes and effects, causes and controls, including rankings for
Problem Detection Post Failure Mode detection post-processing by operator through visual / tactile / severity, occurrence and detection, they must decide if further efforts
8 Remote
Processing audible means. are needed to reduce the risk. Due to the inherent limitations on
Problem Detection at Source
Failure Mode detection in-station by operator through visual/ tactile/audible
means or post-processing through use of attribute gauging (go/no-go, manual 7 Very Low
resources, time, technology, and other factors, they must choose
torque check/clicker wrench, etc.). how to best prioritize these efforts.
Failure Mode detection post-processing by operator through use of variable
Problem Detection Post
gauging or in-station by operator through use of attribute gauging (go/no-go, 6 Low • The initial focus of the team should be oriented towards failure
manual torque check/clicker wrench, etc.).
modes with the highest severity rankings. When the severity is 9 or
Failure Mode or Error (Cause) detection in-station by operator through use of
variable gauging by automated controls in-station that will detect discrepant 10, it is imperative that the team ensure that the risk is addressed
Problem Detection at Source 5 Moderate
part and notify operator (light, buzzer, etc.). Gauging performed on setup and
first-piece check (for set-up causes only).
through existing design controls or recommended actions (as
Problem Detection Post Failure Mode detection post-processing by automated controls that will detect Moderately documented in the FMEA).
Processing discrepant part and lock part to prevent further processing. High
Failure Mode detection in-station by automated controls that will detect
• For failure modes with severities of 8 or below the team should
Problem Detection at Source discrepant part and automatically lock part in station to prevent further 3 High consider causes having the highest occurrence or detection
Error Detection and/or Error (Cause) detection in-station by automated controls that will detect error
rankings. It is the team’s responsibility to look at the information,
Problem Prevention and prevent discrepant part from being made.
2 Very High decide upon an approach, and determine how to best prioritize their
Detection not applicable;
Error (Cause) prevention as a result of fixture design, machine design or part
Almost risk reduction efforts which best serve their organization and
design. Discrepant parts cannot be made because item has not error-proofed 1
Error Prevention by process product design. Certain customers.
57 58
Suggested Process FMEA Detection Evaluation Criteria

Risk Evaluation; Recommended Action(s) (k)

Risk Priority Number (RPN) (j) • In general, prevention actions (i.e., reducing the occurrence) are
• One approach to assist in action prioritization has been to use the Risk Priority Number: preferable to detection actions. An example of this is the use of
RPN = Severity (S) x Occurrence (O) x Detection (D)
process design error proofing rather than random quality checks or
associated inspection.
Within the scope of the individual FMEA, this value can range between 1 and 1000.
• The use of an RPN threshold is NOT a recommended practice for determining the • The intent of any recommended action is to reduce rankings in the
need for actions. following order: severity, occurrence, and detection. Example
• Applying thresholds assumes that RPNs are a measure of relative risk (which they approaches to reduce these are explained below:
often are not and that continuous improvement is not required (which it is).
• To Reduce Severity (S) Ranking: Only a design or process revision
• For example, if the customer applied an arbitrary threshold of 100 to the following, the
supplier would be required to take action on the characteristics B with the RPN of 112.
can bring about a reduction in the severity ranking.
• To Reduce Occurrence (O) Ranking: To reduce occurrence,
Item Severity Occurrence Detection RPN
process and design revisions may be required. A reduction in the
A 9 2 5 90 occurrence ranking can be effected by removing or controlling one or
B 7 4 4 112 more of the causes of the failure mode through a product or process
design revision.
• In this example, the RPN is higher for characteristic B than characteristics A. However,
the priority should be to work on A with the higher severity of 9, although its RPN is 90 • Studies to understand the sources of variation of the process using
which is lower and below the threshold. statistical methods may be implemented. These studies may result in
actions that reduce occurrence.
59 60
Further, the knowledge gained may assist in the identification of • If the assessment leads to no recommended actions for a specific failure
mode / cause / control combination, indicate this by entering “None” in this
suitable controls including ongoing feedback of information to the column. It may be useful to also include a basis if “None” is entered,
appropriate operations for continuous improvement and problem especially in case of high severity.
prevention. • For process actions, the evaluation may include but is not limited to a review
• To Reduce Detection (D) Ranking: The preferred method is the
• Results of process DOE or other testing when applicable.
use of error / mistake proofing. A redesign of the detection
• Modified process flow diagram, floor plan, work instructions or
methodology may result in a reduction of the detection ranking. In preventive maintenance plan.
some cases, a design change to a process step may be required to • Review of equipment, fixtures or machinery specifications.
increase the likelihood of detection (i.e. reduce the detection
• New or modified sensing / detection device.
ranking). Generally, improving detection controls requires the
• Table below provides an example of the application of causes (Column f),
knowledge and understanding of the dominant causes of process controls (Column h) and recommended actions (Column k).
variation and any special causes. Increasing the frequency of Responsibility & Target Completion Data (l)
inspection is usually not an effective action and should only be used • Enter the name of the individual and organization responsible for completing
as a temporary measure to collect additional information on the each recommended action including the target completion date. The
process-responsible engineer / team leader is responsible for ensuring that
process so that permanent preventive / corrective action can be
all actions recommended have been implemented or adequately addressed.
61 62

Action Results (m-n) Severity, Occurrence, Detection and RPN (n)

• This section identifies the results of any completed actions and their • After the preventive / corrective action has been completed,
effect on S, O, D rankings and RPN. determine and record the resulting severity, occurrence, and
detection rankings.
Action(s) Taken and Completion Date (m)

• After the action has been implemented, enter a brief description of • Calculate and record the resulting action (risk) priority indicator (e.g.,
the action taken and actual completion date.
• All revised rankings should be reviewed. Actions alone do not
guarantee that the problem was solved (i.e., cause addressed), thus
an appropriate analysis or test should be completed as verification. If
further action is considered necessary, repeat the analysis. The
focus should always be on continuous improvement.

63 64
Process Step / Failure Prevention Detection Recommended
Function Requirement Mode Cause Controls Controls Actions Maintaining PFMEAs
Op. 20 (attach Four screws Fewer Too few Visual aids Visual In-station torque
seat cushion to than four screws illustrating inspection in monitoring: Line • The PFMEA is a living document and should be reviewed whenever
track using a
torque gun)
screws inadvertently
correct quantity station lockout if fewer
than four
there is a product or process design change and updated, as
Operator training
select four required.
Specified Wrong Similar screws Visual aids Visual In-station torque
screws screw available at illustrating inspection in angle monitoring: • Another element of on-going maintenance of PFMEAs should
used station correct screw station Line lockout if
(larger angle not met. include a periodic review. Specific focus should be given to
Error proof by Occurrence and Detection rankings. This is particularly important
design: use one
type screw for where there have been product or process changes or
station / product
improvements in process controls. Additionally, in cases where either
Op. 20 (attach Assembly Screw More than Visual aids Visual Add position sensor
seat cushion to sequence: placed in one hole identifying inspection in to nut runner not field issues or production issues, such as disruptions, have occurred,
track using a First screw in any other available to location of first station allowing tool to
torque gun) right front hole operator screw operate unless
the rankings should be revised accordingly.
Beginning with hole runner is aligned
right front hole, Operator training with correct hole Leveraging PFMEAs
torque each
screw to the
required torque
• The use of a fundamentally sound PFMEA is the starting point that
provides the greatest opportunity to leverage the use of past
Example of Causes, Controls and Actions experience and knowledge.
65 66

• If a new project or application is functionally similar to the existing

product and the process to be used is similar, a single PFMEA • The PFMEA is not a “stand-alone” document. Figure below shows
some common linkages.
may be used with customer concurrence. If there are differences,

the team should identify and focus on the effect of these

DFMEA, Process Flow
differences. Diagram, etc.


Process Control Plans

PFMEA Information Interrelationship Flow

67 68
To Control Plan

• In addition to the list of Recommended Actions and their

subsequent follow-up as a result of the PFMEA activity, a Control
Plan should be developed. Some organizations may elect not to
specifically identify the related product and process characteristics
portion of the Control Plan may be derived from the
“Requirements” portion of the “Process Function / Requirements”
column and the “Process Characteristics” portion may be derived
from the “Potential Cause(s) of Failure Mode” column.
• When the team develops the Control Plan, they need to assure
that the PFMEA current controls are consistent with the control
methods specified in the Control Plan.

69 70

Thank You