Can You Find a Needle in a Haystack?
Failure modes and their causes can be detected in service, like tire pressure monitors on your vehicle. Is that what is assessed in the Detection column of the FMEA? This article discusses detection risk, including examples, and answers this question.
“There is nothing more deceptive than an obvious fact.”
Arthur Conan Doyle
Definition of “detection”
The Oxford English dictionary defines “detection” as “the action or process of identifying the presence of something concealed.”
What is the definition of “Detection” in an FMEA?
“Detection” is a ranking number associated with the best control from the list of detection-type controls, based on the criteria from the detection scale. The detection ranking considers the likelihood of detection of the failure mode/cause, according to defined criteria. Detection is a relative ranking within the scope of the specific FMEA and is determined without regard to the severity or likelihood of occurrence.
How is “Detection” assessed in FMEAs?
For each cause, The FMEA team assesses the detection ranking. This is the likelihood that the current detection-type controls will be able to detect the cause of the failure mode.
For Design FMEAs, detection is the ranking number corresponding to the likelihood that the current detection-type Design Controls will detect the failure mode/cause, typically in a timeframe before the product design is released for production. For Process FMEAs, detection is the ranking number corresponding to the likelihood that the current detection-type Process Controls will detect the failure mode/cause, typically in a timeframe before the part or assembly leaves the manufacturing or assembly plant.
A suggested approach is assuming the failure has occurred and then assessing the capability of the detection-type design or process control to detect the failure mode or cause. If there is no detection-type control for a given failure mode/cause, the detection ranking should be set to the highest level.
Chapter 6 of Effective FMEAs discusses an exception to this definition of detection for application in industries where the emphasis needs to be on detecting failures once the customer takes ownership (or the system is in operation).
What does a Detection Scale look like for Design FMEAs?
The following is an example of a detection scale for Design FMEAs. It is based on “Potential Failure Mode and Effects Analysis (FMEA) 4th Edition, 2008 Manual.”
What does a Detection Scale look like for Process FMEAs?
The following is an example of a detection scale for Process FMEAs. It is based on “Potential Failure Mode and Effects Analysis (FMEA) 4th Edition, 2008 Manual.”
What is an example of Detection in a Design FMEA?
[In this fictitious example, the detection ranking is assessed based on considering the criteria in the AIAG 4 scale and an estimate of a “moderately high” likelihood that the detection-type controls in the Design FMEA will detect the failure mode / cause.]
Item: Power steering pump
Function: Delivers hydraulic power for steering by transforming oil pressure at inlet ([xx] psi) into higher oil pressure at outlet [yy] psi during engine idle speed
Failure Mode: Inadequate outlet pressure (less than [yy] psi)
Effect (Local: Pump): Low pressure fluid goes to steering gear
Effect (Next level: Steering Subsystem): Increased friction at steering gear
Effect (End user): Increased steering effort with potential accident during steering maneuvers
Severity: 10
Cause: Fluid incorrectly specified (viscosity too low)
Occurrence: 5
Prevention Control: Design guidelines for hydraulic fluid selection
Detection Control: Vehicle durability testing #123
Detection: 4
What is an example of a Detection in a Process FMEA?
[In this fictitious example, the detection ranking is assessed based on considering the criteria in the AIAG 4 scale and an estimate of a “very low” likelihood that the detection-type controls in the Process FMEA will detect the failure mode / cause.]
Process Step: Induction harden shafts using induction hardening machine
Function: Induction harden shafts using induction-hardening machine ABC, with minimum hardness Brinell Hardness Number (BHN) “X”, according to specification #123.
Failure Mode: Shaft hardness less than BHN “X”
Effect (In plant): 100% scrap
Effect (End user): Shaft fractures with complete loss of performance
Effect (Assembly): Not noticeable during assembly
Severity: (Customer Effect): 8 (loss of primary function)
Severity: (Mfg/Assy Effect): 8 (major disruption)
Cause: Induction machine electrical voltage/current settings incorrect for part number
Occurrence: 3
Prevention Control: Shaft hardening setup instructions
Detection Control: audit of shaft hardness
Detection: 7
Application Tip
The most common misunderstanding or misapplication of the detection scale is to confuse or co-mingle the three types of detection risk:
1. Likelihood of detection by the identified controls – specifically, what is the likelihood that the current detection-type control will be able to discover the failure mode or its cause (remote, low, moderate, high, etc.)
2. Timing of the opportunity for detection – specifically, what is the timing of the current detection-type control (prior to design freeze, post design freeze, in service, etc.)
3. Type of test used to detect the cause of the problem – what is the quality of test method used to detect the failure mode or its cause (degradation test, test to failure, pass/fail test, etc.)
The detection scale must clearly identify which of the three types of detection risk is being assessed by the individual criteria of the scale.
Next Article
Can you find the error in detection ranking in the example problem for next week? It is a common error, highlighted in the intermediate problem. In the advanced problem, the topic of an in-service detection scale will challenge the most experienced readers.
If the severity is high more than 8, can detection be low may be less than 3.
Hello Reena Man. Thanks for the question. The answer to your question is “yes.” According to FMEA standards, Severity, Occurrence, and Detection are determined separately, without regard to one another. If Severity is high, the FMEA team should first see if it is possible to reduce severity through design change. If this is not feasible, the team should work to reduce both occurrence and detection to very low levels. There is no reason that high severity cannot be consistent with very low detection, if the detection scale criteria is met.
Please let me know if you have any follow-up questions.
Carl
Hello Carl,
Thank you for posting these great articles. I have a question: I read your article on Occurrence and if my understanding is right, it is assessed using the probability of failure of the system while in operation.
The measure of detection (again, according to my understanding of this article) is done through assessing the ability to catch the problem at production.
Regarding an electronic system. Would the occurrence be assessed through, or partly through, ageing (like MTTF)?
If yes, isn’t there a disconnect between “D” and “O” as one relates to detection in production and the other relates deals with failure occurence in the field due to ageing of the system?
Thank you,
Florent
Hi Florent,
Thanks for your questions.
I’ll reply to each of your comments.
Regarding, “I read your article on Occurrence and if my understanding is right, it is assessed using the probability of failure of the system while in operation,” if you are referring to Occurrence for a Design FMEA, occurrence is the likelihood that the failure mode and associated cause will be present during design life. So, I agree with your comment, with the change from probability to likelihood.
Regarding, “The measure of detection (again, according to my understanding of this article) is done through assessing the ability to catch the problem at production,” detection is the likelihood that the currently planned detection controls will be able to detect the failure mode and associated cause during product development. Preferably, detection is before production.
Regarding your question about an electronic system, “Would the occurrence be assessed through or partly through, ageing (like MTTF)?” I need to ask clarify the question. I’ not sure what you mean by occurrence assessed through or partly through aging. Can you expand on this question?
Thanks.
Carl
Hi Sir,
Can you explain detection rating of 5 in PFMEA, why it is written that set-up approval is only set-up causes??
Hello Suresh,
The criteria for rank 5 of the Process FMEA detection scale (AIAG 4th edition) says, “Failure Mode or Error (Cause) detection in-station by operator through variable gauging or by automated controls in-station will detect discrepant part and notify operator (light, buzzer, etc.). Gauging performed on setup and first-piece check (for set-up causes only).” This criteria specifically relates to problems detected at source.
The verbiage ” Gauging performed on setup and first-piece check (for set-up causes only)” was an attempt by the AIAG standards committee to differentiate the *type* of detection method. Notice rank 6 and 7 refer to “use of attribute gauging (go/no-go, manual torque check/clicker wrench, etc.)” The authors of this criteria are saying that (for set-up causes), gauging performed on setup or first-piece checks has less risk than attribute gauging.
In the criteria column of this scale, the authors have attempted to integrate three risk criteria: likelihood of detection, timing of detection and type of detection method. The gauging criteria relates to the *type* of detection method.
My opinion is that this scale is a bit confusing, and (hopefully) the new scales coming out by SAE this year will be an improvement.
Hope that answers your question.
Carl
Hi Carl,
In case of a sheet metal operation like draw, if we take case of wrinkle, dent defect. Then if we mention First Piece Check (FOA) & LOA as detection control. But this defect is only detected visually no attribute or variable check is there. So we should give this rating 5 considering detected at FOA/LOA or 7 considering visually detected in-station. Please reply fast I have an audit this weekend, need to update PFMEA of many parts.
Thanks in advance.
Hi Sumit,
Thank you for the question about application of PFMEA detection evaluation.
In your post, you did not mention the FMEA reference manual or standard that you are using to conduct your PFMEA. I will need to know the specific FMEA reference manual or standard that your company is required to use, and if there is any company policy that modifies the application of the scales.
Also, you said you will be updating the PFMEA for many parts. Are the PFMEAs being done by you alone, or are they being done by a cross functional team?
I’ll reply as soon as I hear back from you.
Thanks.
Carl
Hi Carl, just finding this thread after looking for clarification on Detection Ranking 5.
Can you clarify what exactly is meant by a “set-up cause”? I’m unclear why gauging performed on setup or first-piece inspections has less risk than attribute gauging for these causes.
Thanks
Hello Allison,
Thank you for your FMEA question about what is meant by set-up cause and why this is less risk than attribute gaging.
I’m assuming, for the purpose of answering your question, that you are referring to the Process FMEA scale for Detection in AIAG 4, not the new AIAG/VDA document.
The first thing to know about the “likelihood of Detection by Process Control” column in this scale is that the verbiage in each level is written by an AIAG team that wrote the AIAG4 standard. There is no universal agreement on this verbiage. So, by asking your question, we will need to evaluate what was meant by the AIAG4 authors.
The next thing to consider in answering your question is the rationale for Detection scale. One of the differentiators between higher and lower risk levels on the scale is the type of detection method. Most practitioners consider attribute gaging less meaningful as a method than variable gaging in detecting defects, especially as systems are more complex. Attribute gaging is more qualitative, whereas variable gaging is more quantitative. That is probably why the attribute gaging is placed higher on the Detection scale, by the authors of AIAG4.
The sentence at the end of the verbiage for Detection Ranking 5 says “Gauging performed on setup and first-piece check (for set-up causes only).” Setup refers to the preparation of a machine or production line to start producing a new product or batch. Setup causes refers to failure causes that are part of the setup process. Lower Detection risk is associated with gauging when it applies to *any* station in the manufacturing or assembly process.
I hope this answers your question.
Carl
Hello Carl,
When we do DFMEA in our company and discuss the detection rating we usually refer to detection methods like Design verification testing, CAE, Environmental testing etc. These are easier to be assessed and ranked.
In some cases, the failure modes are related to bad visual appearance, noise or problems during assembly due to bad design, where the only way to detect the failure prior production is to either do a drawing review or perform First off-tool parts inspection, assembly trial etc.
So far I haven’t seen any detection actions different than those provided by AIAG.
My questions are the following:
Is our interpretation for detection actions correct? How they correlate with the ranking provided by AIAG? Is there any list with standard detection actions which we can use as reference?
Thanks!
Best regards,
Nikolay
Hi Nikolay,
Thanks for your question.
I am not aware of any standard list of Detection methods for DFMEAs or PFMEAs. The only published information is examples in FMEA standards and other publications, such as my book, Effective FMEAs.
Regarding your question about failure modes related to bad visual appearance, noise or problems during assembly due to bad design, we have to be sure that the cause is properly identified as a potential design deficiency. The question then becomes what design methods are currently planned or in place to detect the cause during product development? If there are no tests or analyses currently planned or in place during product development time frame that would detect the cause, the detection risk is high, and the FMEA team can recommend improved detection methods. I, typically avoid using production detection methods in DFMEA detection controls column, as the timing is very late.
If you like, feel free to send a specific example to carl.carlson@effectivefmeas.com, and I’ll offer my comments.
Thanks.
Carl
Can you example for detection rank 7 and 8?
Dear Sir,
I have a question regarding the scoring of Detection. Can the detection rating get lowered when preventative measure (Process Control – Prevention) is installed? Thank you in advance.
Hi Santhini,
I’ll begin by posting the definition of “Detection.”
“Detection is a ranking number associated with the best control from the list of detection-type controls, based on the criteria from the detection scale. The detection ranking considers the likelihood of detection of the failure mode/cause, according to defined criteria. Detection is a relative ranking within the scope of the specific FMEA and is determined without regard to the severity or likelihood of occurrence.”
The last sentence is key to your question, as Prevention Controls are associated with likelihood of occurrence. Therefore, Detection will not be affected by implementation of Prevention Controls.
Let me know if this answers your question.
Carl
Dear Carls,
My field of work is indirectly related to DFMEA and would be helpful to me if I know more about this field.
being clearer I start with an example,
For the compressed Natural Gas (methane) fueled engine applications the fuel (methane) abandons the storage tank with very high pressure and then passes through the pressure regulator in order to be regulated to low pressure, convenient for injectors.
when gas passes through the Pressure Regulator, due to Joul Tampson effect, then loses its temperature by 40°, 50° C and in case of very low ambient temperature like Tamb=-30 °C this effect will be more and so there is a high possible risk of failure (leakage) from the Regulator (one of the causes of failure could be the deformation of the sealing o-ring ).
On the basis of the supplier DFMEA investigation, the severity rated to 10, occurrence 4 and the detection 3(based on CFD analysis and the validation).
One solution would be the mounting of a heater upstream of the pressure regulator in order ti heat up the gas before entering the pressure regulator.
In case of using the heater, then how should rate the Severity, Occurrence, Detection? (increase/decrease/constant)
For me:
severity: constant → because the design is the same
Occurrence: decreases→ due to effective suggestion
what about Detection? remains constant?
My main doubt is on Detection rating and understanding how it will change in the case of an effective solution.
hope I was clear enough and I would be glad if receive feedback from your side,
many thanks
Hello Moein,
Thanks for your question. I’ll reply to your concern about detection ranking, and how it might change based on the solution you mention.
I’ll begin my reply with a quote from the article.
“For Design FMEAs, detection is the ranking number corresponding to the likelihood that the current detection-type Design Controls will detect the failure mode/cause, typically in a timeframe before the product design is released for production.”
You said, “One solution would be the mounting of a heater upstream of the pressure regulator in order it heat up the gas before entering the pressure regulator.”
I do not see how this solution would change the likelihood that the current detection-type Design Controls will detect the failure mode/cause, before the product design is released for production. Detection risk would be reduced only if the detection-type controls are improved.
Hope this helps. Please feel free to ask any follow-up questions.
Carl
Hello Carl,
Thank you for publishing such great articles on the topics of FMEA.
One point I am still struggling with is placing FEA (Finite Element Analyses) within the S-O-D framework of a Design FMEA. We design products, where mechanical failure (a.k.a parts braking under load) is among the chief failure modes. Reccomended actions often involve conducting Finite Element Analyses. My understanding is, that this is a “Detection type Controll” as it is directed at catching an insufficient design before it would go into production. Conversly it should decrease “Detection points” in the FMEA matrix. However, once the analysis is completed (and the report comfirms that the design is strong enough), the logical consequence for me would be to decrease the Occurence, as it is now much less likely that the design is insufficient. Or should it decrease both? Please let me know what you think.
– Martin
Hello Martin,
FEA is one of a few of the reliability tools that can fit in either prevention or detection controls column of a DFMEA, depending on the circumstances of the application.
If the FEA application is conducted to identify design parameters, it could be a prevention-type control, and will directly influence the initial occurrence rating.
If the FEA application is conducted to detect design weaknesses, it could be a detection-type control, and will directly influence the initial detection rating.
As you point out, one of the side benefits of using FEA to improve detectability is the product design will most likely be improved, which can impact the *revised* occurrence rating.
Hope that helps. Please feel free to ask any additional questions.
Carl
My company is revamping its FMEA process and is implementing two changes.
1. We are doing away with the RPN. Our statisticians are opposed to the multiplication of ordinal numbers.
2. We are doing away with likelihood ranking altogether. The rationale being that estimates of probability are inherently wrong. I also suspect that there is a concern that the multiplication of a low likelihood by a high severity could lead an organization to the wrong conclusion, that the risk doesn’t require mitigation. Do you or any other FMEA scholars support or refute the use of likelihood rankings?
Hi Mike,
I share your concern for the viability of RPN. However, I am an advocate for the proper use of Occurrence. I’ll explain.
Regarding doing away with RPN. I’ve written extensively about the shortcomings of RPN in FMEA. The primary flaw is with high-severity issues. High severity – low RPN can be very high risk. The new FMEA standards are providing alternatives to RPN. The question is what to replace it with. I prefer the use of Action Priority Tables where companies can establish action priority levels of High (H), Medium (M) and Low (L) for each combination of Severity, Occurrence and Detection. I’ve written an article on this subject in Accendo Reliability’s Inside FMEA series called “Understanding how to prioritize risk for corrective actions in an FMEA.” If a company decides to continue using RPN, they need to address high-severity issues first before considering RPNs.
Regarding doing away with likelihood ranking altogether, I suggest reconsidering. Occurrence in an FMEA is very important in assessing the risk related to a given failure mode and associated cause. Although there is no perfect way to establish the likelihood of the failure mode and associated cause being present during design life, the FMEA team can make a good judgment. Occurrence ranking, like severity and detection, are mostly subjective assessments. They are not meant to be 100% objective. The FMEA team brings together subject matter experts and considers three sources of information: field failure data for similar items, degree of change from previous design, and current prevention controls. The team makes its best judgment, based on the agreed-upon occurrence scale.
Most international risk management standards use both severity and probability risk. Both are essential in my opinion, as is the risk of detection.
Regarding the concern that the multiplication of a low likelihood by a high severity could lead an organization to the wrong conclusion, I completely agree. This is why I suggest using an Action Priority Table. Each combination of severity, occurrence and detection is represented by a level of risk.
Please feel free to ask any follow-up questions.
Thanks.
Carl
Hello,
Please help me to figure it out. I have an example for process FMEA.
Process: Mount part on the base with screws
Failure mode -> Part attached loosely / screws not fully tightened
Failure cause -> Assembly mistake
Failure effect -> Part will not function well
We are able to detect failure effect in our test after part leaves manufacturing site. Should I rank detection 5 because we will eventually detect it? Or should I rank it 10 since this is not direct detection of failure mode or cause?
Maybe you can also let me know how this should look like in a Control Plan?
Thank you!
Hi Amelija,
I’ll reply to your question. But first, I’ll make a few comments on your example PFMEA excerpt. All of these comments can be reviewed by the PFMEA team, as it is the PFMEA team that decides the content of the PFMEA.
Regarding “Process: Mount part on the base with screws,” I would add the requirement to this process description. For example, what torque?
Regarding “Failure mode -> Part attached loosely / screws not fully tightened,” I’m OK with this wording, but if you had a requirement, you could associate the failure mode(s) with the requirement.
Regarding “Failure cause -> Assembly mistake,” I would take this further to root cause. What is the assembly error and what is the assembly deficiency that enables this error?
Regarding “Failure effect -> Part will not function well,” I like to see both the product effect as well as the process effect. If the part is not tightened sufficiently, what is the consequence to the system? To the end user? To the assembly plant?
Regarding your question: We are able to detect failure effect in our test after part leaves manufacturing site. Should I rank detection 5 because we will eventually detect it? Or should I rank it 10 since this is not direct detection of failure mode or cause?
I would ask the PFMEA team what is the likelihood that the current process controls will detect the failure mode and/or associated cause before the part leaves the plant? Detecting the problem after the part leaves the assembly plant is very late.
Your detection-type process controls are part of the Process Control Plan. The PFMEA can improve these controls. The Process Control Plan takes the improved process controls and follows up to ensure they are implemented in the assembly plant with guidance on how to react if there is deviation.
Hope that helps.
Carl
Hello Carl,
Thank you for your answer. It really helps!
I was using very abstract example.
I understand that detecting the problem after the part leaves the assembly plant is very late. But detecting it later is better than not detecting it at all. If probability is very low, we agree that detecting it later in the test is better then making extra tests on screws itself to detect it earlier.
I am still struggling with understanding if it is ok to give better scoring to detection when we detect failure effect. Normally we can give better scoring on detection when we detect failure mode or failure cause.
In this abstract example I would be able to detect that part is not working/functioning as it should be, but it will be unknown if the root cause is loose screws or something else.
Sincerely,
Amelija
Amelija,
If you are doing a PFMEA on a single assembly process step that mounts a part with screws, you are analyzing that particular step in the assembly process. You are not analyzing other process steps in that portion of the PFMEA. When you get to the Detection rating, you are asking how well the current process controls detect the failure mode or cause. Please note the word “or.” If the current process controls do not do a very good job in detecting the failure mode OR cause,, then the risk related to detection for that particular failure mode OR cause is high. The fact that the controls are also very late, adds to the detection risk. The team would weigh the S, O, and D to see if action is needed to change the process or improve the detectability.
I’ll next reply to your statement, “In this abstract example I would be able to detect that part is not working/functioning as it should be, but it will be unknown if the root cause is loose screws or something else.” First of all, loose screws is not a root cause. And detection relates to failure mode or cause. It is good that you can detect the part is not working as it should. However, PFMEA procedure for detection rating for the specific failure mode that relates to loose screws is as described above. Keep in mind that detection is only one of the three risk factors. Occurrence and severity also are important to consider when prioritizing corrective actions. It appears your detection risk for that particular failure mode is high, given that the test is not likely to detect the failure mode and the test is very late.
Hope that helps.
Carl
What will be the detection ranking for final inspection which is on sample basis
Hi Kk,
You asked, “What will be the detection ranking for final inspection which is on sample basis?”
First, let me ask you some questions. I can be more specific with my answers if you are able to provide a bit more information.
1) What is the process step you are analyzing? Are you analyzing “Final Inspection” as a station, or are you analyzing a process step where the process controls are conducted in final inspection?
2) What FMEA standard are you using?
3) Does your company have specific policy regarding application of FMEA detection scale?
4) How proven is the final inspection sampling?
In general, assessment of “Ability to Detect” for PFMEA is accomplished by assessing the likelihood that the current detection-type process controls will be able to detect the failure mode or associated cause, considering guidance from the detection evaluation criteria.
Detection risk has three factors. 1) the likelihood that the current detection-type process controls will be able to detect the failure mode or associated cause, 2) the timing of the process controls (in-station, end of line, etc.), and 3) the type of process controls (human inspection, testing, automated, proven or not, etc.).
I always consult the PFMEA team when assessing severity, occurrence, and detection. It should be carefully considered by the cross-functional team.
Therefore, in the scenario you pose, “What will be the detection ranking for final inspection which is on sample basis?” I would look at all three factors from above, and use the detection scale that your company has adopted, and make the best subjective assessment as possible.
If you are able to provide more information, I will reply a bit more specifically.
Thanks.
Carl
Hi Carl,
Can you give an example of using detectability in FMEA in Occupational Health and Safety risk analysis? For example, in Turkey FMEA is one of the commonly used methods for occupational health and safety risk analysis. However, when the detectibity issue is not fully understood, it can lead to misuse.
Hello Derya,
Thank you for your question.
I do not know of an agreed-upon standard for FMEA in Occupational Health and Safety (OHS FMEA). The OHS FMEAs I’ve seen use different approaches. There are some examples in the public domain, which you can find by literature search.
Regarding detection assessment in OHS FMEA, there are two approaches I’ve seen. The first approach does not use detection at all, and relies on Severity, Occurrence and Criticality. The second approach does use detection assessment, and the application is similar to what I describe in the article titled “Understanding FMEA Detection – Part 1.”
If you can share with me some details about your specific application, I will provide my view on how to use Detection assessment in an FMEA for that application.
Carl
Hi Carl,
Thank you for all the hard work you put into the blog. The articles are extremely informational!
I would like to ask if there is a general guideline of the threshold for the RPN score where the FMEA team needs to take action? For example, the highest possible RPN score is SxOxD=1000, at what level should the FMEA team consider taking it seriously? 125? 300?
Thank you so much!
Jiyi
Hi Jiyi,
Thank you for your question about RPN thresholds.
Here is an excerpt from the Inside FMEA article titled “Understanding ho to prioritize risk.”
RPN thresholds are not advised. 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. If management exerts sufficient pressure, through excessive consequences for RPN values exceeding thresholds, the FMEA teams or suppliers can bias the RPN components (S, O, and D) to lower the resulting RPN below the threshold. If RPN thresholds are used at all, they should only trigger a heightened level of review, not specifically mandated action.
Additionally, I refer you to the following podcast titled “Is There a Better Way Than RPN?”
https://fred-schenkelberg-project.prev01.rmkr.net/podcast/sor/sor-499-better-way-rpn/
Hope that helps to answer your question.
Thanks.
Carl
If the process control a supplier identifies for a given failure mode is 100% inspection using a variable gage, then the associated detection risk ranking should be a 1?
Yes or No?
Hi Yolanda.
Thank you for the question.
Application of FMEA scales for severity, occurrence, and detection are dependent on the FMEA standard that is being used, as well as whether or not the company has made modifications. Please let me know what FMEA standard you are using, and I will do my best to answer your question.
Thanks.
Carl
Hi, Carl. Thank you for your answer to other questions. I wanna ask you some questions because these are still make me confused. As we know In FMEA, we have severity, occurrence, and detectability. My questions are:
1. How if there are two or more different ratings for severity, which one we choose? Can we use mean to get one exact value for severity or can we choose the highest rating for severity as assumptions that the higher the severity give the worse impact?
2. And how if there are two or more different ratings for occurrence, how do we choose to get one exact value? Do we have to choose the highest rating as assumptions that the risk/the failure have a higher probability for happening in the next time?
Please respond to my questions, Thank You Carl!!
Our engineering management has just done away with Detection rating in our DFMEA format. I’m not comfortable with the change. I’ve seen this advocated in other industries as well. Do you know where this trend it coming from?
How would go about convincing management to keep the Detection rating?
Hi Paul,
In my experience, well over half of companies use Detection ratings as part of FMEA procedure. This has been a topic in the FMEA community for decades, and is not new. The new automotive standards include detection ratings.
I have heard many reasons for not using, or eliminating, Detection ratings from FMEA procedure. They include simplifying FMEAs and saving time, which are generally valid concerns. However, there are effective ways to simplify FMEAs and reduce time other than eliminating detection ratings.
I believe that detection risk is real and should be addressed. So, when I work with a client that is only using severity and occurrence ratings, I ask how they are addressing detection risk. One of the objectives of System and Design FMEAs (in addition to improving product designs) is to improve tests and analyses. One of the best ways to accomplish this objective is to identify current detection controls, and assess how well they can detect the failure mode and cause during product development timeframe.
Keep in mind that some detection scales can be confusing. So, it is important to keep detection scales as simple as possible. I would much prefer to simplify FMEA and simplify detection scales than eliminate detection ratings from FMEA procedure.
Hope that helps. Let me know if you have any follow-up questions.
Carl
Hi Carl!
I also want to thank you for sharing your knowledge. These post are very helpful!
In regards a previous comment thread, a question by Amelija.
I got a couple of questions related:
1. For those detection-type process control that downstream on the production line, rather than in the actual process step being analyzed, should they be reflected on the process control plan? My common sense says no. But I would love to hear your recommendation.
2. In regards flowing down the process controls from the PFMEA to the PCP, is it recommended only to reflect the detection type controls, or its also expected to list the prevention type as well?
We have been asked by IATF auditors to reflect both, which might by kind of tricky sometimes, especially when the preventive type controls are PMs, or other “administrative” controls.
Would you please give me your opinion on this?
Thanks a lot!
Hi Denise,
Thanks for you kind words on the Inside FMEA posts.
Regarding your first question, I’ll answer in two parts:
A. Detection-type Process Controls can be anywhere in the manufacturing or assembly process, as long as they meet the definition of Detection-type Process Controls. Where they are in the manufacturing or assembly process will impact the Detection *rating*. Controls that are later in the process, tend to be higher risk than controls that are in-station.
B. Which specific controls are reflected in the Process Control Plan is dependent on company or customer guidelines. This is often determined by risk prioritization. Generally, Process Controls need to be in place for higher risk areas.
Regarding your second question, the way I look at it is both Prevention and Detection Process Controls are candidates for inclusion in the Process Control Plan. The PFMEA team is guided by company or customer policy and uses engineering judgement to convert prevention and detection controls in the PFMEA to the control methods in the PCP.
Let me know if this answers your questions, and if there are any follow-up questions.
Carl
Hi Csrl,
Many thanks for yor article.
Mayi know the relationship between Detection and Mitigation in FMEA workings.
Hi James,
Here is my reply to your question: “May I know the relationship between Detection and Mitigation in FMEA workings.”
I’ll reply based on my best understanding of these terms.
Detection is a ranking number that assesses how well the currently planned tests and analyses detect the failure mode and associated cause during product development timeframe.
Mitigation, by definition, is the action of reducing the severity, seriousness or painfulness of something.
So, detection is measuring the likelihood that current tests/analyses will detect a problem before launch, and mitigation is taking action to reduce the severity of the problem.
Hope that is helpful. Please let me know if you have any further questions.
Carl
Hi Carl,
Is it possible to reduce severity, or we can only reduce occurrence or increase direction in terms of refusing risk associated with any process or activities.
I mean death of some one during any process is severity only, as per my understanding we can only reduce contributory factor, reduce occurrence and increase direction with help of mitigation plan or we can change the procedure to reduce the severity.
What if changing process is not possible.
Please explain
Tank you.
Hello Ashwani,
In my experience, it is sometimes possible to reduce severity risk in an FMEA. The following strategies can be considered by the FMEA team. The excerpts are from chapter 7 of my book Effective FMEAs.
Design for fail-safe
A fail-safe design is one that, in the event of failure, responds in a way that will cause minimal harm to other devices or danger to personnel. Fail-safe does not mean that failure is improbable; rather that a system’s design mitigates any unsafe consequences of failure. In FMEA language, fail-safe reduces the severity of the effect to a level that is safe.
Design for fault-tolerance
A fault-tolerant design is a design that enables a system to continue operation, possibly at a reduced level (also known as graceful degradation), rather than failing completely, when some part of the system fails. In FMEA language, fault-tolerance reduces the severity of the effect to a level that is consistent with performance degradation.
Design for redundancy
A redundant design provides for the duplication of critical components of a system with the intention of increasing reliability of the system, usually in the case of a backup or fail-safe. This means having backup components that automatically “kick in” should one component fail. In FMEA language, redundant design can reduce the occurrence of system failure and reduce system severity to a safe level. This strategy can be employed to address single-point failures.
Provide early warning
Failures that occur without warning are more dangerous than failures with warning. Catastrophic effects can be avoided by adding a warning device to system design. In FMEA language, adding early warning reduces the severity of the effect, potentially reduces the occurrence of system failure, and increases likelihood of detection of failure mode/cause during in-service usage.
Please let me know if you have any follow-up questions.
Carl
Hi Carl,
thanks for the article!
Can you shed some light on how to interpret detection measures for circuit design DFMEAs? More specifically, I have an issue with the fact that the detection controls – and consequently the detection number – is directly linked to the failure causes, when in reality, it is usually the effects that can be observed.
Let me give you an example: a typical failure cause could be parasitic capacitances, for which the prevention measures are well understood (post-layout simulation of the design, best layout practices, etc.), but the typical detection measures can only show us the effects – oscillation, incorrect settling time, noisy output, and so on. The problem is further complicated by the fact that a simple failure cause can result in several effects that do not necessarily have the same detectability. This makes me think that detection would be better suited for the failure effect, but that is not the usual approach, and some FMEA tools don’t even support such a solution (that is, detection measures are strictly a property of the failure causes).
Is there a good approach to avoid these kind of issues? One thing I can think of is using more specific failure causes that can only have a single outcome, but that seems very cumbersome with little actual benefit.
Best regards,
Viktor
Hi Carl,
In assemble line, suppose that
Failure mode: missing assemble one shim
Failure cause: operator not load the parts
And the action: we install a sensor, if not no parts on the defined place, the program can not start.
My question: for this failure cause, the action is a prevent or detect action?
My opinion is detect action. Because based on AIAG, prevent action minimize the possibility or failure occurrence. This failure cause is operator not load the parts, so when the sensor detect no parts, the operator have already made the mistake, the system can only remind him by stop the machine
Hello Curtis. Thanks for your question.
The first thing to consider is what FMEA column we are talking about. If the sensor was not part of current controls, and is being considered, it is a Recommended Action. If the sensor is part of current assembly controls, it will go in either Process Controls – Prevention Type or Process controls – Detection Type. The reason we put any action that is not currently planned or in place in Recommended Actions is for follow-up to be sure it is executed.
If the sensor is part of current controls, It is a Prevention Control if the currently planned action helps to prevent the failure mode and associated cause (thus impacting concurrent rating). It is a Detection Control if the currently planned action or method will help to detect the problem before it leaves the plant (thus impacting the detection rating).
In this case, if the sensor is currently in place, it appears to help detect the failure mode and associated cause, and would be a Detection-type control. Then you can ask what is the likelihood that the currently planned detection control will detect the cause, and use that as input to the detection rating.
It is up to the FMEA team, so always discuss this with the team you are working with and consult the FMEA standard you are using.
Hope that helps.
Carl
Hi Carl,
Thank you for your reply to my last question.
And I have a new quesition:
In assemble line, sometimes we will measure a final dimension after all parts have been assembled. The failure cause for the dimension NOK is the wrong assemble (position, orintation,etc) of the sub parts. However, we have analyzed them in the previous process. In the final measuring station, this dimension can not be put into product characteristics, because all the failure cause happened in previous stations and no one can link to this dimension.
Would you please give me your opinion?
Many thanks
Hi Curtis,
I suggest going a bit deeper in defining the cause of failure. Ask what is there about the assembly process that allows the wrong position or orientation. That way you will identify potential improvements, which is the purpose of Process FMEA. If the failure mode is noticed in the final station and the cause is from the previous station, that is not a problem. Just describe the cause to be the potential deficiency in the assembly process, which is often a process characteristic.
Hope that helps.
Carl
Hi Carl,
Thank you for your suggestion.
Sorry, I mischaracterized my previous question，that ture question is that: the wrong position or orientation is the failure mode(I typed the failure mode as failure cause) in the previous process, they have some failure cause and already be analysed. However, in the final station, we use one test to comprehensively evaluate whether the previous incorrect assembly(worng position or orientation) occurred. Because the test is only one detection method, so all the failure cause happened in the previous process, that can not connect to it. And this test is only a dimension check, so other failure cause happened in this station.
Finally no failure cause can connect to this test, and this became a problem that bothered me.
In my
Hi Curtis,
Thank you for the clarification. I understand better your question and concern.
To respond to your concern, I will need to ask you a few questions. You can respond on this public comment forum, or you can send me an email at carl.carlson@effectivefmeas.com
Here are my questions:
1. What is the process step that your PFMEA team is focusing on in this Process FMEA? Is the process step the final station? Or, are you trying to do a single PFMEA on all process steps?
2. What is the function of the process step you are focusing on?
The failure mode(s) will be the manner in which the process step does not accomplish the function. The cause(s) will be the potential process deficiency that brings about the failure.
Based on your answers, we’ll reconstruct the FMEA line that you are concerned about, and I’ll help you address your concern.
Thanks.
Carl
Hi Carl,
Sorry for late reply.
Question 1: this process step is a 100% online measuring station. After this station, this parts will be unloaded. So it is the final station of the assembling line.
Question2: it is hard to say. because this measuring station is just a automatic distance measuring device. As we always say, we don’t analyse MSA topic in process fmea. it just a detection method. However, for this station, the measuring is the only thing to do.
Thanks for the clarifications, Curtis.
This is an interesting subject, as the measuring station is both a Detection-type Process Control, as well as its own process step. I think in order to accomplish your objectives, you should analyze the Measuring Station as its own process step. This means you do the steps of Process FMEA on the Measuring Station. You will have to determine the function(s) of the measuring station, as a process step, and carry out the steps of Process FMEA on this station. You are not designing the Measuring Station, which would be a different analysis. You are using the Measuring Station as part of your assembly process.
Let me know if this answers your question.
Carl