<<< Back to Index
This Month's Article >>>

FMEA Corner 
This Month's Theme is Action Strategies to Reduce Detection Risk
Next month's theme will be common facilitation problems

Every month in FMEA Corner, join Carl Carlson, a noted expert in the field of FMEAs and facilitation, as he addresses a different FMEA theme (based on his book Effective FMEAs) and also answers your questions.

Questions and answers are a great way to learn about FMEAs, for both experienced and less experienced FMEA practitioners. Please feel free to ask any question about any aspect of FMEAs. Send your questions to Carl.Carlson@EffectiveFMEAs.com, and your contact information will be kept anonymous. All questions will be answered, even if they are not featured in the FMEA Corner.

 

 

 
de·tec·tion [di-tek-shuhn, noun]
The Oxford English Dictionary defines "detection" as "discovery (of what is unknown or hidden); finding out."

Detection risk

Detection risk is associated with the rating that is entered in the Detection column of the FMEA. There are two circumstances when the FMEA team may consider the detection rating too high.

  1. The effect of the failure mode has a severity rating that is high (such as 9 or 10 on a 10-point scale), and the detection is greater than 1. In this circumstance, the FMEA team should attempt to reduce the detection rating to as low as possible.
  2. The RPN value for the associated failure mode/cause is considered high, and a high detection rating is present.

In both of these circumstances, the FMEA team should develop action strategies to reduce the detection risk.

What are "action strategies to reduce detection risk"?

Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat. - Sun Tzu

FMEA teams can use a multitude of proven strategies to address risk associated with high detection. The following are two of these strategies. A full list of strategies is covered in chapter 7 of the Effective FMEAs book.

In all cases, when the FMEA team proposes actions that are different from what is already planned or in place, these actions should be entered in the Recommended Actions column of the FMEA.

Modify existing detection-type controls to increase the likelihood of detection of the cause

The FMEA team can recommend changes to the existing detection-type controls to increase the likelihood of detection of the cause.

Example: A manufacturer of irrigation valves experiences a field problem of valve sticking due to foreign material; yet the valve meets all current testing requirements. The FMEA team recommends changing the valve test regimen to include foreign material intrusion.

Develop new detection-type controls to increase the likelihood of detection of the cause

The FMEA team may decide to develop new detection-type controls that do not currently exist. In FMEA language, by adding the newly developed detection-type controls, the likelihood of detecting the cause of the failure can be increased.

Example: A metal parts manufacturing plant has a problem with corrosion due to inadequate thickness of galvanizing coating. The FMEA team recommends a new inline control that measures the precise thickness of the coating surface to ensure adequacy.

Multiple strategies to reduce risk

As discussed in the June 2015 FMEA corner, in most cases reduction of a high-risk issue from an FMEA requires the use of multiple tasks. These are recorded in the Recommended Actions column.

Below is an example in Xfmea of the use of recommended actions to reduce detection risk, as well as risk from severity and detection. It is an excerpt from a fictional Design FMEA on a projector lamp.

In this example, the FMEA team believes the action "Modify lamp durability test # 456 to include induced gas pressure buildup" can reduce detection from 8 to 3.


Recommended actions example

Note the multiple actions to address this high-severity, high-RPN issue.

!FMEA Tip of the Month

Some Design FMEA (DFMEA) practitioners identify the tests that are needed to verify or validate the requirement and put these tests in the Recommended Actions column of the FMEA. Tests are ideally tracked in the Design Verification Plan (DVP). If the execution of identified tests is also tracked in the FMEA, this is double tracking and can reduce the effectiveness of the FMEA, as execution of tests is not the objective of the FMEA process. When the FMEA team encounters a test that is needed as part of design verification, and if the test is not already in the DVP, the FMEA team should recommend that the test be added to the DVP, and place appropriate verbiage in the Recommended Actions column of the DFMEA.

*Problem

Which of the following are action strategies to reduce the detection risk? (Select all that apply) [Show/Hide Answers]

1. Make the design fault tolerant.

2. Introduce redundancy to the design.

3. Develop a new test that identifies the failure mode/cause.

4. Increase the design margin.

?Something I’ve always wanted to know about FMEAs
The important thing is not to stop questioning. - Albert Einstein

A HotWire reader submitted the following question to Carl Carlson. To submit your own question about any aspect of FMEA theory or application, e-mail Carl at Carl.Carlson@EffectiveFMEAs.com.

In DFMEA work, would you ever use "manufacturing procedure" as a prevention control, and "manufacturing final test" as a detection control? I understand that it's always better to prevent/detect up front in the design process. But suppose that a design related issue which could cause problems during mfg/assy would be very costly to fix in terms of changing the design, but could be prevented by issuing explicit manufacturing standard work, or special tools, or whatever to ensure that the assembly is done correctly. Or it could be detected before reaching the customer by requiring that a 'final test' be done on the unit before shipping. This would not be just 'throwing it over the wall' to the process FMEA, as the standard work or test procedure would be developed by the design team as their action to close the item. The whole notion seems similar to using the idea of 'in-service' detection, brought forward into the factory before the customer ever gets it. Again, I understand that this is less than ideal, but it seems like it might have some value in certain cases.

Carl: Let's begin with an example. A wiring harness is being designed and has a connector that can only be connected to the adjacent harness in one way. If it is connected in the wrong orientation, it will not function properly. The design team can modify the design of the connector to prevent any connection other than the correct orientation. That would be called error proofing the product design. If the design team concludes it is too expensive to error proof the design, they can request modification to the manufacturing process to ensure the harness is properly connected. This would be called error proofing the manufacturing process. They could use color coding, visual charts or other techniques. In your scenario, the design deficiency (wiring harness is not error proofed and can be mis-assembled) is not directly addressed in the assembly process. There is no design fix. Rather, the assembly process is modified to mitigate the likelihood that there will be mis-assembly.

The question becomes how to document these tasks in a Design FMEA.

I'll use definitions from my book to answer your question:

Cause is the specific reason for the failure, preferably found by asking "why" until the root cause is determined. For Design FMEAs, the cause is the design deficiency that results in the failure mode. For Process FMEAs, the cause is the manufacturing or assembly deficiency (or source of variation) that results in the failure mode.

Prevention-type design controls describe how a cause, failure mode or effect in the product design is prevented based on current or planned actions; they are intended to reduce the likelihood that the problem will occur, and are used as input to the occurrence ranking.

Detection-type design controls describe how a failure mode or cause in the product design is detected, based on current or planned actions, before the product design is released to production, and are used as input to the detection ranking. Detection controls are intended to increase the likelihood that the problem will be detected before it reaches the end user.

Prevention-type Process Controls describe how a cause, failure mode or effect in the manufacturing or assembly process is prevented, based on current or planned actions. They are intended to reduce the likelihood that the problem will occur, and are used as input to the occurrence ranking.

Detection-type Process Controls describe how a failure mode or cause in the manufacturing or assembly process is detected, based on current or planned action, before the item is shipped from the manufacturing or assembly plant, and are used as an input to the detection ranking.

You have an interesting point about using the idea of "in-service" detection, brought forward into the factory before the customer ever gets it. However, based on these definitions and my experience, if the Design FMEA team is not able to fix the design-related deficiency, I would prefer to address the problem in the Process FMEA. I would use the prevention-type design controls to identify current or planned actions that reduce the likelihood that the design problem will occur, and detection-type design controls to identify current or planned actions that increase the likelihood that the design problem will be detected. I would use the Recommended Actions column of the Design FMEA to communicate the tasks that should be addressed in the Process FMEA. That way the Process FMEA team can take whatever actions they deem necessary to ensure the mfg/assy process is robust (free of manufacturing or assembly deficiencies), regardless of design problems. I would prefer to address the problem this way because the Process FMEA team has the right people to address manufacturing/assembly issues and recommend changes that ensure processes are robust. The Design FMEA team typically does not have the right people to address these issues.


About the Author

Carl S. CarlsonCarl S. Carlson is a consultant and instructor in the areas of FMEA, reliability program planning and other reliability engineering disciplines. He has 30 years of experience in reliability testing, engineering and management positions, and is currently supporting clients of ReliaSoft Corporation with reliability and FMEA training and consulting. Previous to ReliaSoft, he worked at General Motors, most recently senior manager for the Advanced Reliability Group. His responsibilities included FMEAs for North American operations, developing and implementing advanced reliability methods and managing teams of reliability engineers. Previous to General Motors, he worked as a Research and Development Engineer for Litton Systems, Inertial Navigation Division. Mr. Carlson co-chaired the cross-industry team that developed the commercial FMEA standard (SAE J1739, 2002 version), participated in the development of SAE JA 1000/1 Reliability Program Standard Implementation Guide, served for five years as Vice Chair for the SAE's G-11 Reliability Division and was a four-year member of the Reliability and Maintainability Symposium (RAMS) Advisory Board. He holds a B.S. in Mechanical Engineering from the University of Michigan and completed the 2-course Reliability Engineering sequence from the University of Maryland's Masters in Reliability Engineering program. He is a Senior Member of ASQ and a Certified Reliability Engineer.

Effective FMEAsMaterial for the FMEA tips, problems and solutions is excerpted from the book Effective FMEAs, published by John Wiley & Sons, ©2012. Information about the book Effective FMEAs, along with useful FMEA aids, links and checklists can be found on www.effectivefmeas.com.