Accendo Reliability

Your Reliability Engineering Professional Development Site

  • Home
  • About
    • Contributors
    • About Us
    • Colophon
    • Survey
  • Reliability.fm
  • Articles
    • CRE Preparation Notes
    • NoMTBF
    • on Leadership & Career
      • Advanced Engineering Culture
      • ASQR&R
      • Engineering Leadership
      • Managing in the 2000s
      • Product Development and Process Improvement
    • on Maintenance Reliability
      • Aasan Asset Management
      • AI & Predictive Maintenance
      • Asset Management in the Mining Industry
      • CMMS and Maintenance Management
      • CMMS and Reliability
      • Conscious Asset
      • EAM & CMMS
      • Everyday RCM
      • History of Maintenance Management
      • Life Cycle Asset Management
      • Maintenance and Reliability
      • Maintenance Management
      • Plant Maintenance
      • Process Plant Reliability Engineering
      • RCM Blitz®
      • ReliabilityXperience
      • Rob’s Reliability Project
      • The Intelligent Transformer Blog
      • The People Side of Maintenance
      • The Reliability Mindset
    • on Product Reliability
      • Accelerated Reliability
      • Achieving the Benefits of Reliability
      • Apex Ridge
      • Field Reliability Data Analysis
      • Metals Engineering and Product Reliability
      • Musings on Reliability and Maintenance Topics
      • Product Validation
      • Reliability by Design
      • Reliability Competence
      • Reliability Engineering Insights
      • Reliability in Emerging Technology
      • Reliability Knowledge
    • on Risk & Safety
      • CERM® Risk Insights
      • Equipment Risk and Reliability in Downhole Applications
      • Operational Risk Process Safety
    • on Systems Thinking
      • Communicating with FINESSE
      • The RCA
    • on Tools & Techniques
      • Big Data & Analytics
      • Experimental Design for NPD
      • Innovative Thinking in Reliability and Durability
      • Inside and Beyond HALT
      • Inside FMEA
      • Institute of Quality & Reliability
      • Integral Concepts
      • Learning from Failures
      • Progress in Field Reliability?
      • R for Engineering
      • Reliability Engineering Using Python
      • Reliability Reflections
      • Statistical Methods for Failure-Time Data
      • Testing 1 2 3
      • The Manufacturing Academy
  • eBooks
  • Resources
    • Accendo Authors
    • FMEA Resources
    • Glossary
    • Feed Forward Publications
    • Openings
    • Books
    • Webinar Sources
    • Podcasts
  • Courses
    • Your Courses
    • Live Courses
      • Introduction to Reliability Engineering & Accelerated Testings Course Landing Page
      • Advanced Accelerated Testing Course Landing Page
    • Integral Concepts Courses
      • Reliability Analysis Methods Course Landing Page
      • Applied Reliability Analysis Course Landing Page
      • Statistics, Hypothesis Testing, & Regression Modeling Course Landing Page
      • Measurement System Assessment Course Landing Page
      • SPC & Process Capability Course Landing Page
      • Design of Experiments Course Landing Page
    • The Manufacturing Academy Courses
      • An Introduction to Reliability Engineering
      • Reliability Engineering Statistics
      • An Introduction to Quality Engineering
      • Quality Engineering Statistics
      • FMEA in Practice
      • Process Capability Analysis course
      • Root Cause Analysis and the 8D Corrective Action Process course
      • Return on Investment online course
    • Industrial Metallurgist Courses
    • FMEA courses Powered by The Luminous Group
    • Foundations of RCM online course
    • Reliability Engineering for Heavy Industry
    • How to be an Online Student
    • Quondam Courses
  • Calendar
    • Call for Papers Listing
    • Upcoming Webinars
    • Webinar Calendar
  • Login
    • Member Home
  • Barringer Process Reliability Introduction Course Landing Page
  • Upcoming Live Events
You are here: Home / Articles / Understanding RPN Limitations – Problems and Solutions

by Carl S. Carlson 5 Comments

Understanding RPN Limitations – Problems and Solutions

Understanding RPN Limitations – Problems and Solutions

In this week’s FMEA problems and solutions article, the intermediate problem challenges readers to prioritize a series of RPNs (with their corresponding S, O, and D). In the advanced problem, readers are asked to weigh in on a fictitious debate between advocates of traditional RPN, and advocates of criticality assessment, using only severity and occurrence.

If you haven’t yet read the article titled “Prioritizing risk for corrective actions in an FMEA – Know before you go!“, you can access it by clicking on the link.

Beginner’s Problem

In an FMEA, which of the following is true about “Risk Priority Number (RPN)”? (Select the best answer.)

1. An “RPN” is the sum of Severity, Occurrence, and Detection rankings.
2. An “RPN” is the product of Severity and Occurrence rankings.
3. An “RPN” is the product of Severity, Occurrence, and Detection rankings.
4. None of the above.

Beginner’s Solution

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, Occurrence, and Detection rankings.)
3. An “RPN” is the product of Severity, Occurrence, and Detection rankings. (True)
4. None of the above. (False)

Intermediate Problem

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:
A) RPN 42  (S = 7, O = 3, D = 2)
B) RPN 140 (S = 7, O = 5, D = 4)
C) RPN 200 (S = 10, O = 5, D = 4)
D) RPN 40  (S = 10, O = 2, D = 2)

Using the letters A, B, C, D, what is the priority sequence for addressing issues in this FMEA excerpt?

Intermediate Solution

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, which is letter C. The next priority is severity 10, RPN 40, which is letter D. Once the high severity issues area addressed, the team can take up high RPNs. The next priority is RPN 140, which is letter B. If the team wishes, it can finally address RPN 42, which is letter A.

Advanced 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, instead using “criticality” (product of severity and occurrence).

Summarize briefly the pros and cons for both approaches.

Advanced Solution

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 action’s 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.

Next Article

Can you take into account reliability or durability functions in an FMEA? How can this be done? A reader asks this question, and it  is discussed and answered in the next FMEA Q and A article.

[display_form id=415]

Filed Under: Articles, Inside FMEA, on Tools & Techniques

About Carl S. Carlson

Carl S. Carlson is a consultant and instructor in the areas of FMEA, reliability program planning and other reliability engineering disciplines, supporting over one hundred clients from a wide cross-section of industries. He has 35 years of experience in reliability testing, engineering, and management positions, including senior consultant with ReliaSoft Corporation, and senior manager for the Advanced Reliability Group at General Motors.

« Reliability Benefits from Product Support
The Good DFMEA The Bad DFMEA and Ugly outcomes »

Comments

  1. apisak sri-amorntham says

    March 29, 2020 at 9:28 PM

    i have seen a website describing RPN by considering only Consequences and it refers this website.

    what is your advice if we use only consequences to define criticality?

    https://www.fiixsoftware.com/blog/criticality-analysis-what-is-it-and-how-is-it-done/

    Reply
    • Carl Carlson says

      March 30, 2020 at 11:40 AM

      Hello, and thanks for your question.

      The article you reference is written for maintenance applications. My initial comment is that Maintenance FMEAs are not the same as Design or Process FMEAs. Maintenance FMEAs share many of the fundamentals with Design and Process FMEAs, but there are significant differences. I cover the similarities and differences in chapter 15 of my book, Effective FMEAs.

      The author discusses two ways to carry out a criticality analysis.

      The first approach the author mentions is a visual grid approach where severity of a given consequence (on the X axis) is plotted against the probability of that consequence occurring (Y axis). This approach is used in many FMEA applications and is a good way to visually show risk on a matrix diagram. Two comments: FMEA does not calculate the probability of a consequence occurring. To get the probability of harm, it usually takes a Fault Tree Analysis or Probabilistic Risk Assessment. And, if you only focus on severity and occurrence, there is still risk related to detection.

      The second approach the author mentions is to separate the consequence categories by type (for example, health and safety, environmental, and operational), assess the severity of each type, and multiply the resulting ratings together. My personal view is this approach does not take into account the occurrence risk nor the detection risk, so it may be useful to prioritize equipment, but may miss higher risk issues inside the FMEA.

      As you can see from my article that you reference, I have concerns about RPN. Fred Schenkelberg and I podcasted on this subject: SOR 499 “Is There a Better Way than RPN?” https://fred-schenkelberg-project.prev01.rmkr.net/podcast/sor/sor-499-better-way-rpn/

      Let me know if this answers your question.

      Carl

      Reply
  2. Thomas says

    May 27, 2020 at 10:21 PM

    Thanks Carl for this very informative article. From my personal perspective RPN taking in account the detectability is not very useful to assess the importance of a risk. Detectability can easy change but identifying the right indicators or combination of indicators. I would weight the impact and the probability much higher.

    Reply
    • Carl Carlson says

      May 28, 2020 at 5:30 AM

      Hello Thomas,

      I understand your comments about the efficacy of detection risk in prioritizing risk within an FMEA. I’ll begin my reply with two additional references and then make a couple of comments.

      Reference my article “Understanding how to prioritize risk for corrective actions in an FMEA,” specifically the portion at the end of the article about Action Priority Table.

      https://fred-schenkelberg-project.prev01.rmkr.net/understanding-prioritize-risk-corrective-actions-fmea/

      Reference also the podcast “Is there a better way than RPN?”

      https://fred-schenkelberg-project.prev01.rmkr.net/podcast/sor/sor-499-better-way-rpn/

      Both the referenced article and podcast are published since the article “Understanding RPN Limitations – Problems and Solutions,” and offer more perspective.

      My personal view is I prefer the approach that uses an Action Priority table, rather than RPN. This methods allows a company to weight severity, occurrence and detection in any way that makes sense. In your case, you may wish to de-emphasize detection risk. I would not suggest eliminating the use of detection rating, as it is important to be able to detect an issue (failure mode and associated cause) before the problem gets to the user/customer. I typically place more emphasis on severity and occurrence, but still consider detection risk.

      Thanks again for your comments. Hope this added information is helpful.

      Carl

      Reply
  3. Chris says

    October 25, 2020 at 11:03 AM

    Hi Carl,

    Considering different milestones of product development, e.g., NPI > NPD > design frozen > engineering build > mass production.

    Since FMEA is a live document, a new risk that is highlighted during engineering build will have very high detection rating such as 8. Let’s say RPN = S*O*D = 7*3*8 = 168.

    Despite being able to complete the testing quickly, this detection rating will still remain as 8. This risk, if it had been highlighted and tested by design frozen, will have much lower detection rating.

    The essence of my question is, detection rating seems to be very dependent on project time line, despite pointing to the same risk. And there no way to lower the detection rating (unlike making design change to reduce severity or likelihood).

    Could you kindly share your thoughts in this?

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Articles by Carl Carlson
in the Inside FMEA series

[popup type="" link_text="Logo Info" ]

Information about FMEA Icon

Inside FMEA can be visually represented by a large tree, with roots, a solid trunk, branches, and leaves.

- The roots of the tree represent the philosophy and guiding principles for effective FMEAs.
- The solid trunk of the tree represents the fundamentals for all FMEAs.
- The branches represent the various FMEA applications.
- The leaves represent the valuable outcomes of FMEAs.
- This is intended to convey that each of the various FMEA applications have the same fundamentals and philosophical roots.

 

For example, the roots of the tree can represent following philosophy and guiding principles for effective FMEAs, such as:

1. Correct procedure         2. Lessons learned
3. Trained team                 4. Focus on prevention
5. Integrated with DFR    6. Skilled facilitation
7. Management support

The tree trunk represents the fundamentals of FMEA. All types of FMEA share common fundamentals, and these are essential to successful FMEA applications.

The tree branches can include the different types of FMEAs, including:

1. System FMEA         2. Design FMEA
3. Process FMEA        4. DRBFM
5. Hazard Analysis     6. RCM or Maintenance FMEA
7. Software FMEA      8. Other types of FMEA

The leaves of the tree branches represent individual FMEA projects, with a wide variety of FMEA scopes and results. [/popup]

Join Accendo

Receive information and updates about articles and many other resources offered by Accendo Reliability by becoming a member.

It’s free and only takes a minute.

Join Today

Recent Posts

  • Gremlins today
  • The Power of Vision in Leadership and Organizational Success
  • 3 Types of MTBF Stories
  • ALT: An in Depth Description
  • Project Email Economics

© 2025 FMS Reliability · Privacy Policy · Terms of Service · Cookies Policy