Note from the author:
I began writing the FMEA Corner series of articles in October 2013. I have long had a passion for the subject of FMEA, and wanted to share my experiences with readers. The idea was each month to highlight one FMEA concept, add application information and tips, and end with a selected Q and A from a reader. I sincerely hope it has been helpful to you as FMEA practitioners.
This month marks the 51st and final article written for HotWire in this series. It has been a joy sharing information about FMEA fundamentals and applications with the readership of HotWire.
I will continue to answer any and all questions on the subject of FMEA. If you have questions or comments, please send them to firstname.lastname@example.org.
As I say to my FMEA students at the conclusion of each FMEA course, "Best wishes for effective FMEAs!"
"Any goal worth achieving involves an element of risk." - Dean Karnazes
Risk [risk, noun]
The ISO 31000 (2009) Risk Management document says that "risk is the effect of uncertainty on objectives." Another definition is "the possibility that something unpleasant will happen." (Oxford English Dictionary)
Pri·or·i·ty [prai-awr-i-tee, noun]
Priority is defined as "the fact or condition of being regarded or treated as more important than others." (Oxford English Dictionary)
Num·ber [nuhm-buhr, noun]
Number is defined as "a quantity or amount."
What is RPN?
SAE J1739 (2009) page 12 states:
AIAG v4 page 57 states:
MIL-STD-1629A does not use RPN. It uses Criticality, which is comprised of severity and occurrence. Note that MIL-STD-1629A was cancelled in November 1984.
Although the VDA publication Product and Process FMEA has a section titled "Risk Priority Number" and defines it similarly to SAE and AIAG, it says, "In many cases inspection of the absolute value of risk priority number is misleading, and not appropriate as the basis for further actions."
What are the limitations of RPN?
The FMEA Corner article in Issue 161 describes the limitations of RPN. They are repeated here.
The most critical limitation is the first one discussed above. High severity, low RPN, can be very serious. For this reason alone, FMEA practitioners should be cautious of relying on RPN as the sole measure of risk prioritization.
Is there a better way than RPN?
One of the problems with RPN is that it purports to be a single number representing the prioritization of risk in an entire FMEA. There is no single number that can represent the entirety of risk in an FMEA.
An alternative to RPN is prioritizing actions based on the various combinations of severity, occurrence and detection. This has sometimes been called Action Priority, or in the case of Xfmea, Risk Ranking Logic.
Individual companies can review the various combinations of S, O and D, and assign red, yellow, green (or other variable designations) to the combinations. This can be done to each of the SOD combinations (a lengthy task) or to ranges of S, O and D combinations (a shorter task). There is no set combination of S, O and D (and corresponding red, yellow, green), that applies uniformly to all companies. It should depend on company policy and priorities.
How can Xfmea support Risk Ranking Logic?
To enable Risk Ranking Logic in Xfmea, choose Project > Management > Configurable Settings > Interface Style. Then navigate to the FMEA > RPNs page.
Click the Risk Ranking Logic button, then for each row enter criteria for SOD combinations according to company policy. You can also edit which colors you want associated with the levels of risk.
If you are using RPN to prioritize risk, always address high-severity issues first, regardless of RPN. Once high-severity issues are addressed, you can take up high RPNs.
I’ve always wanted to know about FMEAs
The important thing is not to stop questioning. - Albert Einstein
A 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 email@example.com.
How do you know when an FMEA is complete?
Carl: That is a very good question. Here's my answer.
An individual FMEA is completed when the recommended actions for that FMEA are implemented, and the risk is reduced to an acceptable level.
This brings up the subject of "living FMEA." What do you do with subsequent test and/or field problems that occur after the current FMEA has been implemented? Can the current FMEA become a "living FMEA," and act as a repository for post-analysis test and/or field problems?
Some FMEA references refer to the phrase "living document" or "living FMEA." The intent is to make the FMEA a repository for the latest failure information within the scope of the FMEA. When this strategy is used, the FMEA is updated with test or field failures that occur after the product has been tested and launched, so that future FMEAs will benefit from this information.
The "living FMEA" strategy can work for product lines with a single primary design. It does not work as well for product lines with multiple design variants. Take a hypothetical example of ABS brakes. The ABS subsystem for the model X is not the same as the ABS subsystem for the model Y or Z. If a DFMEA is performed on the ABS subsystem for model X, and there is a subsequent field problem that was not addressed in this DFMEA, using the "living FMEA" strategy, the DFMEA for model X ABS brakes is modified to incorporate the field issue. The problem is that the DFMEAs for the ABS subsystem for model Y and Z were not modified. When the next versions of the model Y and Z are being designed, the ABS subsystem for the model Y and Z will not benefit from the latest field information.
One solution for ensuring test and field problems are captured in future FMEAs is to use a "generic FMEA." Here is an excerpt from chapter 11 of my book:
Regardless of whether a generic FMEA is used, known field problems must be input to future DFMEAs as part of the preparation process. Reference the paragraph on "Field History" as part of preparation for new FMEAs, in my FMEA Corner article written for Issue 167 of HotWire.
About the Author
Carl S. Carlson is a consultant and instructor in the areas of FMEA, reliability program planning and other reliability engineering disciplines. He has 35 years of experience in reliability testing, engineering and management positions, and is currently supporting clients from a wide variety of industries, including clients of HBM Prenscia. Previously, 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.
Selected material for FMEA Corner articles 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. Carl Carlson can be reached at firstname.lastname@example.org.