|
|
This Month's Theme is RPN
Next month's theme will be "the philosophy of effective FMEAs"
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. Please send your questions about any aspect of FMEAs to Carl.Carlson@EffectiveFMEAs.com. Your contact information will be kept anonymous and all questions will be answered, even if they are not featured in the FMEA Corner.
Special Request — We Need Your Feedback!
We would appreciate it if you would answer three brief questions about FMEA Corner, so we can learn from our readers and improve the value of this series. Please respond directly to Carl.Carlson@EffectiveFMEAs.com. Your answers will be kept strictly confidential.
- What do you like about the current format and content of FMEA Corner?
- What can be improved about FMEA Corner to make it more useful to FMEA practitioners?
- How can we make FMEA Corner more interactive with readers?
Thank you for your support.
risk pri·or·i·ty
num·ber [risk prai-awr-i-tee
nuhm-buhr, noun]
In an FMEA, the Risk Priority Number (RPN) is a numerical ranking of the risk of
each potential failure mode/cause, made up of the arithmetic product of the
three elements: severity of the effect (S), likelihood of occurrence of the
cause (O) and likelihood of detection of the cause (D).
FMEA Tip of the Month
Tip 1: The entire purpose of the RPN value is to help the FMEA team prioritize issues for corrective action, within the scope of the specific FMEA project. In application, it is always necessary to separately review and address all high severities as well as high RPNs. The reason is that high severity - low RPN has the potential to result in high risk to end users and to the company.
Tip 2: There are limitations to the usefulness of RPNs, and FMEA teams need to understand the limitations. These include:
- High severity by itself – As covered in the tip above, high severity is high risk, regardless of the RPN value. Therefore, it is always necessary to address high severity in addition to high RPN.
- Subjectivity of RPN - Since the components of RPN (severity, occurrence and detection) are each subjective ratings, the RPN value is subjective in nature. It has application only in helping the FMEA team prioritize issues for corrective action within a given FMEA, and cannot be used to assess risk across different FMEAs.
- Limitations of detection – The detection scale is controversial for some companies and practitioners, and as a result, some have chosen not to use the detection ranking at all. Some companies use the severity and occurrence scales (without detection) and then prioritize issues by the product of SxO, called "criticality." If the FMEA team chooses to use SxO instead of RPN, then the team needs to consider how to address the risk associated with detection.
- Duplicate RPN numbers - All possible products of S, O and D include many duplicate numbers. For example, a severity of 1, occurrence of 8 and detection of 8 has the same RPN value as a severity of 8, occurrence of 4 and detection of 2. Clearly, there is very different risk associated with each of these examples.
- RPN thresholds - It is enticing for management to use thresholds for RPN values and require defined action if the RPN value exceeds the given threshold. In most cases, this is a flawed approach, as it can easily become a numbers game.
Beginner’s Problem
In an FMEA, which of the following is true about "Risk Priority Number (RPN)"? (Select the best answer.) [Show/Hide Answers]
1. An "RPN" is the sum of Severity, Occurrence and Detection rankings.
(False. An "RPN" is the product of Severity, Occurrence and Detection rankings, not the sum.)
2. An "RPN" is the product of Severity and Occurrence rankings.
(False. An "RPN" is the product of Severity, Occurence and Detection rankings.)
3. An "RPN" is the product of Severity, Occurrence and Detection rankings.
(True)
Intermediate Problem
Scenario: You are performing an FMEA on a bicycle brake cable. The team has identified two failure modes for one of the primary functions, with two causes for each of the two failure modes (see illustration). This results in four RPNs:
- RPN 42 (S = 7, O = 3, D = 2)
- RPN 140 (S = 7, O = 5, D = 4)
- RPN 200 (S = 10, O = 5, D = 4)
- RPN 40 (S = 10, O = 2, D = 2)
Problem: Using the letters A, B, C, D, what is the priority sequence for addressing issues in this FMEA excerpt? [Show/Hide Answer]
Answer: C, D, B, A.
Recall the rule that FMEA teams should always address high severity first, regardless of RPN value. Therefore, the first priority is severity 10, RPN 200 (letter C). The next priority is severity 10, RPN 40 (letter D). Once the high severity issues are addressed, the team can take up high RPNs. The next priority is RPN 140 (letter B). If the team wishes, it can finally address RPN 42 (letter A).
Advanced Problem
Problem: A debate is raging in your company about the use of RPN. One side wants to adhere to the AIAG/SAE standards that recognize three risks: severity, occurrence and detection, and the resulting RPN value. The other side wants to limit risk characterization to severity and occurrence by instead using "criticality" (i.e., the product of severity and occurrence). Summarize briefly the pros and cons for both approaches. [Show/Hide Answer]
Answer: There is no perfect answer to this problem. This debate has been going on for many years in the FMEA community. Use of RPN is predicated on the assumption that detection risk is sufficiently important that it needs to be addressed in FMEAs, and characterized in the risk priority number.
The argument in favor of including detection risk within FMEA risk prioritization goes something like this. Detection-type controls should be able to detect the failure mode/cause in order to ensure problems are not discovered by users, especially for higher-risk issues. Where detection-type controls are not able to detect the failure mode/cause, there is a potential for detection risk. FMEA teams can improve detection-type controls through the recommended actions column, in order to reduce detection risk and ensure anticipated problems are discovered through testing and analysis during product development.
The argument against including detection risk within FMEA risk prioritization focuses on the classical definition of risk. The classical characterization of risk from ISO standards says, "Risk is often expressed in terms of a combination of the consequences of an event and the associated likelihood of occurrence." The argument continues with the limitations to detection scales published by AIAG or SAE. Many consider the detection scales to be confusing and difficult to apply. Therefore, according to this argument, the use of "criticality" (SxO) is a better way to identify risk.
If RPN will be used, the company needs to understand the limitations of RPN and detection risk and act accordingly. For example, high severity must always be addressed regardless of RPN value. The company will need to develop a detection scale that makes sense, and detection-scale criteria verbiage that is clear and represents the varying risk due to likelihood of detection of failure modes and associated causes.
If "criticality" (SxO) is used, the company needs to understand the risk from lack of detection of failure modes/causes during product development, and find a way to address this risk. It is not acceptable for the end user to be the one to discover problems that were missed by testing during the product development timeframe.
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.
My question is about things that should not be done in production and are happening. For example, in work instructions, we include the method for cleaning a component; but in actual production, they clean with another substance, or they clean in another way. This kind of problem is giving us a lot of customer complaints or some failures that we did not think about. In other words, I do not have in P-FMEA some failures that appear because production is implementing the process in another way with other tools or substances.
What is your opinion about this?
Carl: The problem you describe (production worker cleaning with wrong substances, or cleaning with wrong methods) can be included in the Process FMEA. One of the operations would be cleaning, the function describes how the cleaning should be done and the failure mode is the manner in which the cleaning step does not accomplish the function. Continuing the analysis will reveal the effect and cause of the failure, current controls and recommendations to improve the cleaning process.
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 carl.carlson@effectivefmeas.com.
