Example of Design Failure Mode and Effect Analysis
Design Failure Mode and Effect Analysis
Team Approach:
The DFMEA is developed and maintained by a multi- disciplinary (or cross-functional) team typically led by
the design responsible engineer from the responsible design source (e.g., OEM, Tier 1 supplier or Tier 2
supplier and below). The responsible engineer is expected to directly and actively involve representatives from
all affected areas. The areas of expertise and responsibility may include, but are not limited to, assembly,
manufacturing, design, analysis/test, reliability, materials, quality, service, and suppliers, as well as the design
area responsible for the next higher or lower assembly or system, subsystem, or component.
Manufacturing, Assembly, and Serviceability Consideration:
The DFMEA should include any potential failure modes and causes that can occur during the manufacturing or
assembly process which are the result of the design. Such failure modes may be mitigated by design changes
(e.g., a design feature which prevents a part from being assembled in the wrong orientation — i.e., errorproofed). When not mitigated during the DFMEA analysis (as noted in the action plan for that item), their
identification, effect, and control should be transferred to and covered by the PFMEA. The DFMEA does not
rely on process controls to overcome potential design weaknesses, but it does take the technical and physical
limits of a manufacturing and assembly process into consideration, for example:





Necessary mold drafts
Limited surface finish capability
Assembling space (e.g., access for tooling)
Limited hardenability of steels
Tolerances/process capability/performance
The DFMEA can also take into consideration the technical and physical limits of product serviceability and
recycling once the product has entered field use, for example:
The DFMEA focuses on the design of the product that will be delivered to the final customer (End User). The
prerequisite tasks for an effective analysis of the product design include: assembling a team, determining scope,
creating block diagrams or P-diagrams depicting product function and requirements. A clear and complete
definition of the desired product characteristics better facilitates the identification of potential failure modes.
The DFMEA process can be mapped to the customer or organization‟s product development process. A
DFMEA should begin with the development of information to understand the system, subsystem, or component
being analyzed and define their functional requirements and characteristics. In order to determine the scope of
By Pretesh Biswas (APB Consultant)
1
Tool access
Diagnostic capability
Material classification symbols (for recycling)
Materials/chemicals used in the manufacturing processes
Page




Example of Design Failure Mode and Effect Analysis
the DFMEA, the team should consider the following as applicable to component, subsystem or system
DFMEAs:




What processes, mating components, or systems does the product interface with?
Are there functions or features of the product that affect other components or systems?
Are there inputs provided by other components or systems that are needed to perform intended functions
of the product?
Do the product‟s functions include the prevention or detection of a possible failure mode in a linked
component or system?
These are some of the tools that may be applied, as appropriate, to assist the team in developing the DFMEA.
Block (Boundary) Diagram Example.
By Pretesh Biswas (APB Consultant)
Page
The block diagram indicates the interaction of components and subsystems within the scope of the design. This
interaction may include: flow of information, energy, force, or fluid. The objective is to understand the
requirements or inputs to the system, the activities acting on the inputs or function performed, and the
deliverables or output. The diagram may be in the form of boxes connected by lines, with each box
corresponding to a major component of the product or a major step of the process. The lines correspond to how
the product components are related to, or interface with each other. The organization needs to decide the best
2
The block diagram of the product shows the physical and logical relationships between the components of the
product. There are different approaches and formats to the construction of a block diagram.
Example of Design Failure Mode and Effect Analysis
approach or format for the block diagram. Copies of the diagrams used in DFMEA preparation should
accompany the DFMEA.
Parameter (P) diagram:
Example of Parameter (P) diagram
The P-Diagram is 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 (responses or functions) for the design as
well as those controlled and uncontrolled factors which can impact performance. The inputs to the product and
outputs from the product, i.e., the intended and unintended functions of the product, are useful in identifying
error states, noise factors, and control factors. The error states correspond to the Potential Failure Modes in the
DFMEA.
Other tools and resources that may help the team understand and define the design requirements may include:
By Pretesh Biswas (APB Consultant)
Page
Another step in the DFMEA process is a compilation of the functional and interface requirements of the design. This list
may include the following categories such as General (This category considers the purpose of the product and its overall
design intent), Safety, Government Regulations, Reliability (Life of the Function), Loading and Duty Cycles such as
Customer product usage profile, Quiet Operations such as Noise, vibration and harshness (NVH), Fluid Retention,
Ergonomics, Appearance, Packaging &Shipping , Service and Design for assembly & manufacturing.
3
Functional Requirements:
Example of Design Failure Mode and Effect Analysis






Schematics, drawings, etc.
Bill of Materials (BOM)
Interrelationship matrices
Interface matrix
Quality Function Deployment (QFD)
Quality and Reliability History
The use of these tools, supported by engineering experience and historical information, can assist in defining a
comprehensive set of requirements and functions. The example used with the sample form deals with a Front Door
assembly. The product has several functional requirements:
 Permit ingress to and egress from vehicle
 Provide occupant protection from
 Weather (comfort)
 Noise (comfort)
 Side impact (safety)
 Support anchorage for door hardware including
 Mirror
 Hinges
 Latch
 Window regulator
 Provide proper surface for appearance items
 Paint.
 Soft trim
 Maintain integrity of inner door panel
Page
4
The final DFMEA would include analysis of all these requirements. The example includes part of the analysis of them
requirement: “Maintain integrity of inner door panel”.
By Pretesh Biswas (APB Consultant)
Example of Design Failure Mode and Effect Analysis
FMEA Number (A)
Enter an alphanumeric string which is used to identify the FMEA document. This is used for document control.
System, Subsystem, or Component Name and Number (B).
Enter the name and number of the system, subsystem, or component which is being analyzed.
Design Responsibility (C)
Enter the OEM, organization, and department or group who is design responsible. Also enter the supply
organization name, if applicable.
Model Year(s)/Program(s) (D)
Enter the intended model year(s) and program(s) that will use or be affected by the design being analyzed (if
known).
Key Date (E).
Enter the initial DFMEA due date, which should not exceed the scheduled production design release date.
Page
Enter the date the original DFMEA was completed and the latest revision date.
5
FMEA Dates (F)
By Pretesh Biswas (APB Consultant)
Example of Design Failure Mode and Effect Analysis
Core Team (G)
Enter the team members responsible for developing the DFMEA. Contact information (e.g., name, organization,
telephone number, and email) may be included in a referenced supplemental document.
Prepared By (H)
Enter the name and contact information including the organization (company) of the engineer responsible for
preparing the DFMEA.
Body of DFMEA Form (Fields a-n)
The body of the FMEA contains the analysis of risks related to the potential failures, and improvement action
being taken.
Item / Function /Requirements (a)
Item/Function can be separated into two (or more) columns or combined into a single, bridged column which
encompasses these elements. Interfaces (as “items” of analysis) can be either combined or separate.
Components may be listed in the item/function column, and an additional column may be added containing the
functions or requirements of that item. “Item”, “Function”, and “Requirements” are described below:
Item (a 1)
Enter the items, interfaces, or parts which have been identified through block diagrams, P-diagrams, schematics
and other drawings, and other analysis conducted by the team. The terminology used should be consistent with
customer requirements and with those used in other design development documents and analysis to ensure
traceability.
Function (a1)
Enter the function(s) of the item(s) or interface(s) being analyzed which are necessary to meet the design intent
based on customer requirements and the team‟s discussion. If the item(s) or interface has more than one
function with different potential modes of failure, it is highly recommended that each of these functions and
associated failure mode(s) is listed separately. Function becomes a2 if Item and Function are split.
Requirements (a2)
An additional column, “Requirements”, may be added to further refine the analysis of the failure mode(s). Enter
the requirement(s) for each of the functions being analyzed (based on customer requirements and the team‟s
discussion). If the function has more than one requirement with different potential modes of failure, it is highly
recommended that each of the requirements and functions are listed separately.
By Pretesh Biswas (APB Consultant)
Page
Potential failure mode is defined as the manner in which a component, subsystem, or system could potentially
fail to meet or deliver the intended function described in the item column. Identify the potential failure mode(s)
associated with the function(s)/requirement(s). Potential failure modes should be described in technical terms,
and not necessarily as a symptom noticeable by the customer. Each function may have multiple failure modes.
A large number of failure modes identified for a single function may indicate that the requirement is not well
defined. The assumption is made that the failure could occur, but may not necessarily occur, consequently the
6
Potential Failure Mode (b)
Example of Design Failure Mode and Effect Analysis
use of the word “potential”. Potential failure modes: that could occur only under certain operating conditions
(i.e., hot, cold. dry, dusty, etc.) and under certain usage conditions (i.e., above-average mileage, rough; terrain,
city driving only, etc.) should be considered. After determining all the failure modes, a validation of the
completeness of the analysis can be made through a review of past things-gone-wrong, concerns, reports, and
group brainstorming. The potential failure mode may also be the cause of a potential failure mode in a higher
level subsystem or system, or lead to the effect of one in a lower level component.
Potential Failure Modes
Potential Effect(s) of Failure (c)
Page
7
Potential effects of failure are defined as the effects of the failure mode on the function, as perceived by the
customer(s). Describe the effects of the failure in terms of what the customer might notice or experience,
remembering that the customer may be an internal customer as well as the ultimate End User. State clearly if the
failure mode could impact safety or non-compliance to regulations. The effects should always be stated in terms
of the specific system, subsystem, or component being analyzed. Remember that a hierarchical relationship
exists between the component, subsystem, and system levels. For example, a part could fracture, which may
cause the assembly to vibrate, resulting in an intermittent system operation. The intermittent system operation
could cause performance to degrade and ultimately lead to customer dissatisfaction. The intent is to predict the
potential failure effects to the team‟s level of knowledge.
By Pretesh Biswas (APB Consultant)
Example of Design Failure Mode and Effect Analysis
Example of Potential Effect
Severity (d):
Severity is the value associated with the most serious effect for a given failure mode. Severity is a relative
ranking within the scope of the individual FMEA. The team should agree on evaluation criteria and a ranking
system and apply them consistently, even if modified for individual process analysis. It is not recommended to
modify criteria ranking values of 9 and10. Failure modes with a rank of severity 1 should not be analyzed
further.
Failure to Meet
Safety and/or
Regulatory
Requirements
Loss or
Degradation of
primary function
Loss or
Degradation of
secondaryfunction
Annoyance
10
9
8
7
6
5
4
3
2
1
Page
No effect
Potential failure mode affects safe vehicle operation and/or involves noncompliance
with government regulation without warning.
Potential failure mode affects safe vehicle operation and/or involves noncompliance
with government regulation with warning.
Loss of primary function (vehicle inoperable, does not affect safe vehicle operation)
Degradation of primary function (vehicle operable, but at reduced level of
performance)
Loss of secondary function (vehicle operable, but convenience functions inoperable).
Degradation of secondary function (vehicle operable, but comfort /convenience
functions at reduced level of performance).
Appearance or Audible Noise, vehicle operable, item does not conform and noticed
by most customers (> 75%)
Appearance or Audible Noise, vehicle operable, item does not conform and noticed
by many customers (50%).
Appearance or Audible Noise, vehicle operable, item does not conform and noticed
by discriminating customers (< 25%)
No discernible effect.
Example of DFMEA Severity Evaluation criteria
Rank
8
Criteria
Severity of Effect on Product(Customer Effect)
Effect
By Pretesh Biswas (APB Consultant)
Example of Design Failure Mode and Effect Analysis
Classification (e)
This column may 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 identify special characteristics. Customer specific requirements
may identify special product or process characteristic symbols and their usage. 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.
Potential Cause(s)/Mechanism(s) of Failure Mode (f)
This information can be separated into multiple columns or combined into a single column. 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.
Potential Mechanism(s) of Failure Mode (f1)
A failure mechanism is the physical, chemical, electrical, thermal, or other process that results in the failure
mode. It is important to make the distinction that a failure mode is an "observed" or "external" effect so as not
to confuse failure mode, with failure mechanism, the actual physical phenomenon behind the failure mode or
the process of degradation or chain of events leading to and resulting in a particular failure mode. To the extent
possible, list every potential mechanism for each failure mode. The mechanism should be listed as concisely
and completely as possible. For a system, the failure mechanism is the process of error propagation following a
component failure which leads to a system failure. A product or process can have several failure modes which
are correlated to each other because of a common failure mechanism behind them. Ensure that process effects
are considered as part of the DFMEA process.
Page
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. 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. In identifying potential causes of failure, use concise descriptions of
the specific causes of failures, e.g., specified bolt plating allows for hydrogen embrittlement. Ambiguous
phrases such as, poor design or improper design, should not be used. 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., the failure mode does not require multiple causes
to occur). Typically, there may be several causes each of which can result in the failure mode. This results in
multiple lines (cause branches) for the failure mode. To the extent possible, list every potential cause for each
failure mode/failure mechanism. The cause should be listed as concisely and completely as possible. Separating
the causes will result in a focused analysis for each cause and may yield different measurement, controls, and
action plans. In preparing the DFMEA, assume that the design will be manufactured and assembled to the
design intent. Exceptions can be made at the team‟s discretion where historical data indicate deficiencies in the
manufacturing process.
9
Potential Cause(s) of Failure Mode (f2)
By Pretesh Biswas (APB Consultant)
Example of Design Failure Mode and Effect Analysis
Failure Mode
Mechanism
Cause
Mechanical linkage break due to inadequate corrosion protection
Master cylinder vacuum lock due to seal design
No transfer of
Vehicle does not
Loss of hydraulic fluid from loose hydraulic line due to incorrect
force from pedal to
stop
connector torque specification.
pads
Loss of hydraulic fluid due to hydraulic lines
crimped/compressed, inappropriate tube material specified.
Mechanical linkage joints stiff due to inappropriate lubrication
specification,
Reduced transfer
Vehicle stops in
Mechanical linkage joints corroded due to inadequate corrosion
of force from
excess of yy feet
protection.
pedal to pads
Partial loss of hydraulic fluid due to hydraulic lines crimped,
inappropriate tube material specified
Stops vehicle
Excessive/rapid
Cumulative pressure build-up in master cylinder due to seal
with more than xx transfer of force
design
g‟s of force
from pedal to pads
Activate with no
Corrosion or deposit build up on rails or pad ears clue to surface
demand; Vehicle
finish not promoting adequate self-cleaning and corrosion
Pads do not release
movement is
protection
impeded
Activate with no
Hydraulic pressure
demand; Vehicle
Master cylinder vacuum lock due to seal design
does not release
cannot move
Examples of Potential Causes
Occurrence (g)
Occurrence is the likelihood that a specific cause/mechanism will occur resulting in the failure mode within the
design life. The likelihood of occurrence ranking number has a relative meaning rather than an absolute value.
A consistent occurrence ranking system should be used to ensure continuity. The occurrence number is a
relative ranking within the scope of the FMEA and may not reflect the actual likelihood of occurrence. The
team should agree on evaluation criteria and a ranking system and apply them consistently, even if modified for
individual process analysis. Occurrence should be estimated using a 1 to 10 scale. In determining this estimate,
questions such as the following should be considered:
Page
Is the item a carryover or similar to a previous level item?
How significant are changes from a previous level item?
Is the item radically different from a previous level item?
Is the item completely new?
What is the application or what are the 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?
 What is the service history and field experience with similar components, subsystems, or systems?
10






By Pretesh Biswas (APB Consultant)
Example of Design Failure Mode and Effect Analysis
Likelihood of
Failure
Criteria: Occurrence of Cause –
DFMEA (Design life/reliability of
item/vehicle)
Very High
New technology/new design with no
history.
High
Moderate
Low
Very Low
Criteria: Occurrence
of Cause DFMEA
(Incidents per
Items/vehicles)
100 per thousand
1 in 10
Rank
Failure is inevitable with new design,
new application, or change in duty
cycle/operating conditions.
Failure is likely with new design, new
application, or change in duty
cycle/operating conditions.
50 per thousand
1 in 20
9
20 per thousand
1 in 50
8
Failure is uncertain with new design, new
application, or change in duty cycle/
operating conditions.
Frequent failures associated with similar
designs or in design simulation and
testing.
Occasional failures associated with
similar designs or in design simulation
and testing.
Isolated failures associated with similar
designs or in design simulation and
testing.
Only isolated failures associated with
almost identical design or in design
simulation and testing.
No observed failures associated with
almost identical design or in design
simulation and testing.
Failure is estimated through Preventive
controls.
10 per thousand
1 in 100
7
2 per thousand
1 in 500
6
0.5 per thousand
1 in 2,000
5
0.1 per thousand
1 in 10,000
4
0.O1 per thousand
1 in 1,00,000
3
0.OO1 per thousand
1 in 1,000,000
2
Failure is estimated
through Preventive
controls.
Example of DFMEA Occurrence Evaluation Criteria
10
1
Current Design Controls (h)
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.
Eliminate (prevent) the cause of the mechanism of failure or the failure mode from occurring, or reduce its rate
of occurrence.
By Pretesh Biswas (APB Consultant)
Page
Prevention:
11
There are two types of design controls to consider:
Example of Design Failure Mode and Effect Analysis
Detection:
Identify (detect) the existence of a cause, the resulting mechanism of failure or the failure mode, either by
analytical or physical methods, before the item is released for production.
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. Detection control
should include identification of those activities which detect the failure mode as well as those that detect the
cause. The team should consider analysis, testing, reviews, and other activities that will assure the design
adequacy such as:
Prevention Controls






Benchmarking studies
Fail-safe designs
Design and Material standards (internal and external)
Documentation — records of best practices, lessons learned, etc. from similar designs
Simulation studies — analysis of concepts to establish design requirements
Error-proofing
Detection controls






Design reviews
Prototype testing
Validation testing
Simulation studies — validation of design
Design of Experiments; including reliability testing
Mock-up using similar parts
Failure
Mode
Cause
Mechanical linkage break due to
inadequate corrosion protection
Master cylinder vacuum lock due to
seal design
Designed per material
standard MS-845
Carry-over design with
same duty cycle
requirements
Designed per torque
requirements -3993
Detection Control
Environmental stress test
03 -9963
Pressure variability
testing — system level
Loss of hydraulic fluid from loose
Vibration step stress test
hydraulic line due to incorrect
18-195O
connector torque specification
Loss of hydraulic fluid due to
Designed per Material
Design of Experiments
hydraulic lines crimped/compressed, standard MS-1178
(DOE) — tube resiliency
inappropriate tube material specified
Examples of Prevention and Detection Design Controls
Page
12
Vehicle
does
not stop
Preventive Control
By Pretesh Biswas (APB Consultant)
Example of Design Failure Mode and Effect Analysis
Detection (i)
Detection is the rank associated with the best detection control listed in the Current Design 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 lowest ranking value in the Detection column. A
suggested approach to Current Design Control Detection is to assume the failure has occurred and then assess
the capabilities of the current design controls to detect this failure mode. Do not automatically presume that the
detection ranking is low because the occurrence is low. It is important to assess the capability of the design
controls to detect low frequency failure modes or reduce the risk of them going further in the design release
process. Detection is a relative ranking within the scope of the individual FMEA. In order to achieve a lower
ranking, generally the design control has to be improved. The team should agree on evaluation criteria and a
ranking system and apply them consistently, even if modified for individual process analysis.
No current design control; Cannot detect or is not analyzed.
Rank
10
Design analysis/detection controls have a weak detection
Not likely to
capability; Virtual Analysis (e.g., CAE, FEA, etc.) is not correlated
9
detect at any stage
to expected actual operating conditions.
Product verification/validation after design freeze& prior to launch
with pass/fail testing (Subsystem or system testing with acceptance
8
criteria such as ride and handling, shipping evaluation, etc.)
Post Design
Product verification/validation after design freeze and prior to
Freeze and
launch with test to failure testing (Subsystem or system testing until
7
prior to launch
failure occurs, testing of system interactions, etc.).
Product verification/validation after design freeze and prior to
launch with degradation testing (Subsystem or system testing after
6
durability test, e.g., function check).
Product validation (reliability testing, development or validation
tests) prior to design freeze using pass/fail testing (e.g., acceptance
5
criteria for performance, function checks, etc.)
Prior to Design
Product validation (reliability testing, development or validation
Freeze
tests) prior to design freeze using test to failure (e.g., until leaks,
4
yields, cracks, etc.)
Product validation (reliability testing, development or validation
tests) prior to design freeze using degradation testing (e.g., data
3
trends, before/after values, etc.)
Virtual
Design analysis/detection controls have a strong detection
Analysis capability. Virtual analysis (e.g. CAE, FEA, etc.) is highly
2
Correlated
correlated with actual or expected operating conditions prior to
design freeze.
Detection not
Failure cause or failure mode cannot occur because it is fully
applicable;
prevented through design solutions (e.g., proven design standard,
1
Failure Prevention best practice or common material, etc.)
Suggested DFMEA/PFMEA Prevention/Detection Evaluation Criteria
By Pretesh Biswas (APB Consultant)
Likelihood
for
Detection
Almost
Impossible
Very
Remote
Remote
Very low
low
Moderate
Moderately
high
High
Very High
Almost
Certain
13
No detection
opportunity
Criteria:
Likelihood of Detection by Design Control
Page
Opportunity for
Detection
Example of Design Failure Mode and Effect Analysis
Determining Action Priorities
Once the team has completed the initial identification of failure modes and effects, causes and controls,
including rankings for severity, occurrence, and detection, they must decide if further efforts are needed to
reduce the risk. Due to the inherent limitations on resources, time, technology, and other factors, they must
choose how to best prioritize these efforts.
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 must ensure that the risk is addressed through existing
design controls or recommended actions. For failure modes with severities 8 or below the team should consider
causes having highest occurrence or detection rankings. It is the team‟s responsibility to look at the information
identified, decide upon an approach, and determine how to best prioritize the risk reduction efforts that best
serve their organization and customers.
Risk Priority Number or RPM (i)
One approach to assist in action prioritization has been to use the Risk Priority Number:
RPN = Severity (S) x Occurrence (O) x Detection (D)
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 need for actions. Applying
thresholds assumes that RPNS are a measure of relative risk (which they often are not) and that continuous
improvement is not required (which it is). For example, if the customer applied an arbitrary threshold of 100 to
the following, the supplier would be required to take action on the characteristic B with the RPN of 112.
By Pretesh Biswas (APB Consultant)
Page
(e.g., vehicle launch) is desirable, it should be based on an analysis of severity, occurrence and detection and
not through the application of RPN thresholds. Use of the RPN index in the discussions of the team can be a
useful tool. The limitations of the use of RPN need to be understood. However, the use of RPN „thresholds to
determine action priority is not recommended.
14
In this example, the RPN is higher for characteristic B, but the priority should be to work on A with the higher
severity of 9, although the RPN is 90 which is lower and below the threshold. Another concern with using the
threshold approach is that there is no specific RPN value that requires mandatory action. Unfortunately,
establishing such thresholds may promote the wrong behavior causing team members to spend time trying to
justify a lower occurrence or detection ranking value to reduce RPN. This type of behavior avoids addressing
the real problem that underlies the cause of the failure mode and merely keeps the RPN below the threshold. It
is important to recognize that while determining “acceptable” risk at a particular program milestone
Example of Design Failure Mode and Effect Analysis
Recommended Action (k)
In general, prevention actions (i.e., reducing the occurrence) are preferable to detection actions. An example of
this is the use of proven design standard or best practice rather than product verification/validation after design
freeze. The intent of recommended actions is to improve the design. Identifying these actions should consider
reducing rankings in the following order: severity, occurrence, and detection.
Example approaches to reduce these are explained below:
 To Reduce Severity Ranking:
Only a design revision can bring about a reduction in the severity ranking. High severity rankings can
sometimes be reduced by making design revisions that compensate or mitigate the resultant severity of failure.
For example: The requirement for a tire is to “retain applied air pressure under use”. The severity of the effect
of the failure mode “rapid loss of air pressure” would be lower for a "run flat" tire. A design change, in and of
itself, does not imply that the severity; will be reduced. Any design change should be reviewed by the team to
determine the effect to the product functionality and process. For maximum effectiveness and efficiency of this
approach, changes to the product and process design should be implemented early in the development process.
For example, alternate materials may need to be considered early in the development cycle to eliminate
corrosion severity.
 To Reduce Occurrence Ranking:
A reduction in the occurrence ranking can be effected by removing or controlling one or more of the causes or
mechanisms of the failure mode through a design revision. Actions such as, but not limited to, the following
should be considered:
 Error proof the design to eliminate the failure mode
 Revised design geometry and tolerances
 Revised design to lower the stresses or replace weak (high failure probability) components
 Add redundancy
 Revised material specification
 To Reduce Detection (D) Ranking:
The preferred method is the use of error/mistake proofing. An increase in design validation/ verification actions
should result in a reduction of the detection ranking only. In some cases, a design change to a specific part may
be required to increase the likelihood of detection (i.e., reduce, the detection ranking). Additionally, the
following should be considered:
If the assessment leads to no recommended actions for a specific failure mode/cause/control combination,
indicate this by entering “None” in this column. It may be useful to also include a rationale if “None” is entered,
especially in case of high severity. For design actions consider using the following:
By Pretesh Biswas (APB Consultant)
15

Design of Experiments (particularly when multiple or interactive causes of a failure mode are
present)
Revised test plan
Page

Example of Design Failure Mode and Effect Analysis
 Results of design DOE or reliability testing
 Design analysis (reliability, structural or physics of failure) that would confirm that the solution is effective
and does not introduce new potential failure modes
 Drawing, schematics, or model to confirm physical change of targeted feature
 Results from a design review
 Changes to a given Engineering Standard or Design Guidelines
 Reliability analysis results
Item
Failure
Mode
Cause
Mechanical linkage
break due to
inadequate corrosion
protection
Master cylinder
vacuum lock due to
seal design
Disk
Brake
System
Vehicle
does not
stop
Loss of hydraulic
fluid from loose
hydraulic line due to
incorrect connector
torque specification
Prevention
Controls
Designed per
material
standard MS845
Carry-over
design with
same duty cycle
requirements
Designed per
torque
requirements3993
Detection
Controls
Environmental
stress
test 03-9963
Pressure
variability
testing system level
Recommendatio
n Action
Change material
to stainless steel
Use carry-over
seal design
Vibration step- Modify connector
stress
from bolt-style to
test 18-1950
quick-connect
Loss of hydraulic
fluid due to
Designed per
Modify hose
hydraulic lines
material
DOE -tube
design from MScrimped/
standard MSresiliency.
1178 to MS-2025
compressed,
1178
to increase
inappropriate tube
strength
material specified
Examples of Causes, Controls and Recommended Actions
Responsibility & Target Completion Date (I)
Enter the name of the individual and organization responsible for completing each recommended action
including the target completion date. The design-responsible engineer/team leader is responsible for ensuring
that all actions recommended have been implemented or adequately addressed.
Action Results (m-n)
This section identifies the results of any completed actions and their effect on S, O, D rankings and RPN
Page
After the action has been implemented, enter a brief description of the action taken and actual completion date.
16
Action(s) Taken and Completion Date (m)
By Pretesh Biswas (APB Consultant)
Example of Design Failure Mode and Effect Analysis
Severity, Occurrence, Detection and RPN (n)
Page
17
After the preventive/corrective action has been completed, determine and record the resulting severity,
occurrence, and detection rankings. Calculate and record the resulting action (risk) priority indicator (RPN). 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.
By Pretesh Biswas (APB Consultant)