Design FMEA

Design Failure Mode and Effects Analysis (DFMEA) is used to uncover design risk, which includes possible failure, degradation of performance and potential hazards. The DFMEA is typically the first FMEA tool used in product development. When performed properly, there are many benefits of DFMEA. Quality-One has been facilitating DFMEAs for decades and has developed a list of helpful activities to make your DFMEA beneficial.

Create an Effective DFMEA Cross Functional Team

Collect Pre-Work for Faster DFMEA Development

Use an Efficient DFMEA Path Development

Determine Recommended Actions as Soon as Possible

Link the Design Verification Plan & Report and Design Reviews to FMEA Outputs

 

Create an Effective DFMEA Cross Functional Team

Cross Functional Teams (CFTs) have been developing DFMEAs since the late 1940’s, when they were used to uncover risk of failure on aerospace products. The DFMEA uncovers opportunities to prevent failure prior to an actual failure. The DFMEA treats risk as actual failure and therefore takes actions as if a failure has already occurred.

Path 1 Team includes:

  • Responsible Design Engineer
  • Contrarian of the same Function
  • Data or Reliability Function / Facilitator

Path 2 Team includes:

  • Members from Path 1
  • Selected Subject Matter Experts (SMEs) related to high severity Failure Modes
  • Neighboring Systems (interfaces)
  • Process Engineer of the targeted process

Path 3 Team includes:

  • Members from Path 1
  • Testing or CAE Engineers

Return to top

Collect Pre-Work for Faster DFMEA Development

Design FMEA can be brutal if the correct information is not available during development. Some of the information that is most beneficial is listed as follows:

  • Comprehensive list of Past Failures and Lessons Learned from various sources
    • Problem Solving Activities (such as 8Ds)
    • Warranty and Recall Information
    • Plant Problems relating to Scrap and / or Rework
    • Past Test Failures
  • Applicable legacy documents
    • Similar Product FMEAs
    • Fault Tree Analysis (FTA)
    • Test Results
  • Similar or Surrogate Design examples or advanced prototypes
  • Engineering Drawings and CAD / Math Data
  • Statistical Data and past Tolerance Studies
  • Robustness Tools to assist in discovering Causes of Failure in Interfaces and Noises
    • Boundary Diagram
    • Reliability Block Diagram
    • Parameter Diagram

Return to top

Use an Efficient DFMEA Path Development

Many teams start a DFMEA by opening a blank form and filling it in horizontally across the page. This approach is very inefficient. DFMEAs should be created vertically down the page in three paths.

  • Path 1 includes Requirements, Potential Failure Modes, Effects of Failure and Severity Ranking
  • Path 2 includes Causes, Prevention Controls, Occurrence and Class Column (if applicable)
  • Path 3 includes Detection Controls

Insert the FMEA Development three-path model picture here

Return to top

Determine Recommended Actions as Soon as Possible

When using the Three-Path Model and the FMEA Risk and Detection Matrices, the need for actions becomes apparent prior to calculating the Risk Priority Number (RPN). Actions should include the person responsible and timing for completion. A milestone date linked to a project timeline may also be used for the completion date.

pic slash pic

The RPN (Risk Priority Number) is the product of Severity, Occurrence and Detection (RPN = S∗O∗D), and is often used to determine the relative risk of a DFMEA line item. In the past, RPN has been used to determine when to take action. Quality-One does not recommend using an RPN Threshold to determine when an action should be taken. Actions are created based on the following:

  • High Severity of 9 or 10 (Can a design be changed to eliminate a Failure Mode?)
  • High Occurrence when linked to severity
  • High Detection linked to high Occurrence-Severity items

Return to top

Link the Design Verification Plan & Report (DVP&R) and Design Reviews to FMEA Outputs

The Detection column in the DFMEA is an input into the Design Verification Plan & Report (DVP&R). Design Controls should be developed to excite failure modes through their causes and related mechanisms. The likelihood of Occurrence provides the test planning activity with possible changes to current test or the need of an additional test if the cause/mechanism is not currently used in the test.

Design Review must address risks to ensure prevention of the risk in the final design. The Design Review and DFMEA relationship has historically been poor. DFMEA provides risks, which are substitutes for failure. The risks must be treated as if a test has failed and requires counter measures or a design change. Using DFMEA risks as Design Review topics will provide a focal point for engineers prior to design release.

The illustration above depicts a process flow of the design review, where inputs come from many sources (upper left) and eventually are mitigated and tracked using a ROY chart (illustrated below). ROY stands for Red, Orange, and Yellow. These colors correspond with the FMEA Criticality Matrix.

  • Red is associated with Severity of 9 or 10 and drives design changes to eliminate Failure Modes
  • Orange is associated with high Severity and Occurrence combinations and drives Occurrence actions
  • Yellow is a transition zone which may drive actions to lower Occurrence or Detection Rankings

A Pareto of Risk and/or a Glideslope Chart can be used to discuss progress in Project or Program Gateway Reviews.

Return to top