The Scale from Remote to Certain
Some FMEA teams associate occurrence ranking with Failure Mode; others associate it with Effect. Still others connect associate it with Cause? Which is correct? This article discusses occurrence risk, including examples, and answers this question.
“Reality is not always probable, or likely.”
Jorge Luis Borges
Definition of “occurrence”
The Oxford English dictionary defines “occurrence” as “the fact or frequency of something happening.”
What is the definition of “occurrence” in an FMEA?
“Occurrence” is a ranking number associated with the likelihood that the failure mode and its associated cause will be present in the item being analyzed. For System and Design FMEAs, the occurrence ranking considers the likelihood of occurrence during the design life of the product. For Process FMEAs the occurrence ranking considers the likelihood of occurrence during production. It is based on the criteria from the corresponding occurrence scale. The occurrence ranking has a relative meaning rather than an absolute value and is determined without regard to the severity or likelihood of detection..
How is Occurrence risk assessed in FMEAs?
The team determines the likelihood of the failure mode / cause based on the above definition, and using the agreed upon occurrence scale, carefully reviews the criteria column to establish the occurrence ranking. This assessment of occurrence ranking should be as objective as possible, using past field history of similar items, previous test results, experience with similar systems, and other sources of information. There will always be a subjective element to this ranking, as the FMEA is done on new designs, design changes, and/or new applications. However, the FMEA team should endeavor to be as objective as possible, using the criteria from the occurrence scale to help determine the appropriate rank. If the assessment of occurrence ranking falls between discreet occurrence numbers on the scale (such as between 4 and 5) the team should use the higher number.
Is it the occurrence of the failure mode or the cause?
This question has been debated in the FMEA community. Most FMEA standards, such as AIAG, SAE J1739 and VDA, attribute the occurrence ranking to the cause of the failure. The reason for this has to do with the value of the risk assessment. If we have two different causes for “cable breaks”, such as “corrosion of cable wiring due to wrong material selected” and “fatigue cracks in cable wiring due to inadequate cable thickness”, it helps to differentiate the likelihood of occurrence of the two cause. The priority of corrective actions is aided by this differentiation.
What does an Occurrence Scale look like for Design FMEAs?
The following is an example of an occurrence scale for Design FMEAs. It is based on “Potential Failure Mode and Effects Analysis (FMEA) 4th Edition, 2008 Manual.”
What does an Occurrence Scale look like for Process FMEAs?
The following is an example of an occurrence scale for Process FMEAs. It is based on “Potential Failure Mode and Effects Analysis (FMEA) 4th Edition, 2008 Manual.”
What is an example of Occurrence in a Design FMEA?
[In this fictitious example, the occurrence ranking is assessed based on estimate there will be 1 in 2000 failures due to the cause identified in the FMEA.]
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
What is an example of Occurrence in a Process FMEA?
[In this fictitious example, the occurrence ranking is assessed based on estimate there will be 1 in 100,000 failures due to the cause identified in the FMEA.]
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
Application Tip
Note that prevention-type controls are considered input to the occurrence ranking. Some practitioners place the Prevention Controls column before the Occurrence column in the FMEA worksheet to facilitate this sequence.
Next Article
Assessing the occurrence ranking is one of the most challenging aspects of FMEAs. The next article presents two problems that relate to this assessment, based on a fictitious case study, and highlights a common mistake.
Hi Carl,
I’m a big favorit of your articles about FMEA, which have given me the basic understanding of the FMEA facilitation and processes. In the past 7 years I have been working in the Wind Turbine industry. Here the FMEA has been some kind of papers needs to be filled out – only to keep the QA people happy . But now we are a group of people, that see the FMEA work of more and more importance in product reliability.
When I have been doing the facilitation I quite often have difficulties to keep the right attention from the team. I have tried to use “post it” sessions. Using the excel spread sheet typing in data is so time consuming that people nearly fall a sleep.
Do you have some good tricks to a “freshly baked” facilitator on how to keep a good flow and energy in a FMEA team. Look forward to your answer and have a nice evening. BR Mogens
Hello Mogens,
Thanks for your kind words about the FMEA articles. Here are my thoughts on how to keep a good flow and energy in FMEA team meetings.
As you have noted, one of the biggest complaints about FMEA is that it can take a long time and often moves along too slowly. Although we all agree that FMEAs must be done by a properly constituted team of subject matter experts, it takes excellent facilitation skills to keep the team engaged and interested in every meeting.
I’ll be publishing future articles on FMEA facilitation in the “Inside FMEA” series. Until then I’ll pass on some tips that may be useful to you.
1. Consider using a “scribe” for data entry in FMEA meetings.
In FMEA applications, a scribe is someone who is assigned the task of entering information into the FMEA worksheet. In some cases, the FMEA facilitator doubles as the scribe. In other cases, the FMEA facilitator asks one of the team members to act as scribe. Here is the key datum: The FMEA facilitator needs to have eyes on the team. He or she must above all maintain ongoing observation and interaction with each of the team members. Nothing slows or thwarts the team more than the team leader spending more time entering information into the FMEA worksheet than listening and communicating with the team. A scribe is useful when the FMEA facilitator believes that entering information into the FMEA worksheet will distract from interacting with the team on a real-time basis.
2. Make sure the FMEA team fully understands the definitions and concepts of FMEAs
There is no substitute for learning and applying the fundamental concepts and definitions of FMEA. Even the most experienced FMEA practitioners should continue to improve their understanding of the basics. FMEA teams that that are led by someone who has a rock-solid grasp of fundamentals will avoid lengthy discussions on trivial topics and wrong procedures.
3. Improve FMEA facilitation skills
FMEA facilitation is a different subject than FMEA methodology. Poorly led FMEA teams will not achieve excellent results. To be successful, FMEA leaders need to develop expert facilitation skills. FMEA teams that are led by a skilled facilitator will keep meeting discussions on topic and drive through the FMEA process without wasting time. Chapter 10 of my book, Effective FMEAs, covers the skills of FMEA facilitation. If you have a copy of the book, I suggest you read that chapter, and even supplement the learning with the end-of-chapter problems.
4. Consider use of “Generic” FMEAs
Generic FMEAs contain up to 80% or more of anticipated and known failure modes, effects, causes and controls. This can save considerable time when a new or modified design or process is based on current design or process. Change point analysis identifies the nature of the changes and the FMEA team conducts the FMEA procedure on the changes to the generic FMEA.
5. Limit in-meeting discussion to areas of concern
It’s a good practice to limit failure modes to those of concern to at least one member of a properly constituted FMEA team. If one person has a concern, the issue is taken up by the team. But if no team member has a concern, the issue is not entered into the FMEA. This avoids in-meeting time on low-risk issues.
6. Do a thorough job of pre-meeting preparation
Preparation tasks include defining the scope of the FMEA project, making the scope visible (FMEA Block Diagram, P-Diagram, etc.), establishing the correct cross-functional team, identifying relevant assumptions and gathering all needed information. If any of these preparation tasks are missing, valuable in-meeting time will be wasted.
7. Control in-meeting discussion
This is really a subset of the facilitation skills. One of the most common problems that team leaders have is keeping the discussion on topic and focused on risk, and limiting off-topic conversations. FMEA team leaders need to intervene when there are side discussions, or when the discussion is not beneficial to the objective.
8. Use “sticky notes” when brainstorming for new ideas
From your question, I can see you are using “sticky notes.” They are a great way to harness the creative energy of the FMEA team, and can be used at the beginning of the FMEA analysis in order to save valuable time spent in meetings. For each item’s function, ask the FMEA team to write “sticky notes” for the primary concerns they have, not emphasizing if the concern is worded as a failure mode, effect or cause. The writing of the notes is done concurrently and placed on a wall, easily visible to the FMEA team and organized into similar groupings.
9. Use pre-population, in selected circumstances
Care must be exercised when considering pre-populating any portion of the FMEA. There are potential benefits and potential downsides to pre-population, and the team should be fully aware of the benefits and downsides. Selective use of pre-population can speed up the in-meeting time. I will cover this subject in a future “Inside FMEA” article.
Summarizing, the best FMEA facilitators use strategies like the above to reduce in-meeting time and make the time more productive. The long-term success or failure of FMEAs in a company can depend in part on the perceived value the FMEA compared to the investment of the in-meeting time of the participants.
Best of luck to you!
Carl
Hi Carl, I have been involved with Design FMEAs over the years.
Severity seams relatively easy to rank, especially when the failure can result in inoperable or safety critical conditions. Ranking lower severity items is more subjective. Do you take an average of the individual team member severity ranking. Similar, issues occur with detection.
Sometimes it seems that team members pull the probability of occurrence out of the air. In your team meetings are the engineers asked to support their assessments with data?
Love to hear how you handle this.
Hi Dennis. Thanks for the question on how the FMEA team determines the risk rankings. My first comment is the importance of using good scales that have well defined criteria for each of the rankings. Poorly written criteria make it more difficult to identify the rank that best represents risk. If you are using one of the published scales such as SAE J1739 or AIAG, the criteria are reasonably well written. As to whether the team members are asked to support the risk assessment, my reply is “yes.” FMEA is a consensus process, and the team should agree on each of the entries in the FMEA worksheet, including risk rankings. This takes excellent facilitation, which is why I devote an entire chapter in my book on FMEA facilitation skills and techniques. I do not suggest averaging team member risk rankings. I would probe team members for their rationale and discuss which ranking best represents team thinking.
Hope that is helpful. Let me know if you have any other questions.
Carl
Hi Carl, I am facing challenges with rating occurrence in a Wind Industry where majority of the processes are manual. Although we have a rating criteria, it is not descriptive enough to support occurrence rating. Tracking each operation is not feasible here.
Would like to get some direction from you on this.
Hi Aditi,
Thanks for your question. Let me begin by saying it would be best if the assembly processes are supported by data. So, when you say, “tracking each operation is not feasible here,” you might consider at least tracking manufacturing / assembly issues that relate to individual processes, if you can. Having said that, occurrence ranking in an FMEA is subjective. Even though the criteria in most occurrence scales has objective information, the assessment is largely subjective. You take into account at least three factors: 1) manufacturing or assembly data of past failures for similar processes (if you don’t have actual data, you can ask the subject matter experts for their info on past failures), 2) the current prevention-type process controls in the PFMEA that are associated with the failure mode and associated cause, and 3) the degree of newness of the particular process you are analyzing with the PFMEA. You ask the team to make their best engineering judgment as to the likelihood that the failure mode and corresponding cause will be present during the manufacturing or assembly process. And then you assess the occurrence score based on your occurrence scale.
Please let me know if this answers your question, and feel free to ask any follow-up questions.
Carl
Good day Carl,
I have a question about occurrence as well. The context of the question is related to software design FMEAs. I have been going back and forth with the team that the occurrence rating should ALWAYS be a 10. The rationale for this is that if there is a bug in the software and it follows a specific branching path, the error will always occur. In other words, the software will always perform exactly the same as it did the previous time, assuming the same path is followed.
Do you know of any reference or guidance that I can use to underscore my position?
Thanks,
– Dominic
Hi Dominic,
Thanks for sharing your comments and question about the occurrence rating for software FMEAs.
I do not believe that the occurrence rating for software FMEAs will always be a 10. In my experience, the occurrence rating for software FMEAs follows the same general concept as for any other type of FMEA: the likelihood that the failure mode and associated cause will be present during the design life of the product. This will be evaluated against the specific criteria on the occurrence scale that is being used by the company, for software FMEAs. I’ve seen high occurrence and low occurrence, depending on the nature of the failure mode and associated cause, and the criteria in the occurrence scale.
I am planning an article on software FMEAs as part of the Inside FMEA series. I’ll be sure to provide more clarity on rating severity, occurrence and detection when performing a software FMEA.
Carl
Good day Carl,
first of all, thank for your article about FMEA.
I have one additional question, very often I could see, on web sites where FMEA takes place, the evaluation of occurrence for potential cuase of failure mode named “inccorect /inadequant / insuficient material specified” -> ranking, for instance, 2 or 4.
However, it does not give me sence. Gennerally, if we used “bad material” = “inccorect material specified”, then we would observe in any times 100propability of failure (it means ranking 10, not less 2, 4 etc.)
The same conclusion, I can feel for potential causes of failure modes such as:
– lubricant specification too viscous (= …too viscous… how much..? if it is out of spec., but it is closed to spec. then 2 or 4 can be O.K., however, too much realy to much then 10.
The problem is thaat the name for potentional cause of failure mode named “lubricant specification too viscous” does not give me directly image for occureance)
– inadequate design life assumption
– torque specification too low
– etc.
thnak you in advance.
BR,
Jan.
Hi Jan,
Thanks for asking this excellent question.
I’ll begin my reply with a definition of occurrence from my book.
“Occurrence is a ranking number associated with the likelihood that the failure mode and its associated cause will be present in the item being analyzed. For System and Design FMEAs, the occurrence ranking considers the likelihood of occurrence during the design life of the product.”
Now, let’s take the bicycle brake cable example in my book.
Item: Brake cable
Function: Provides adjustable and calibrated movement between the brake lever and brake caliper,
Failure Mode: Cable breaks
Cause: Corrosion of cable wiring due to wrong material selected
Occurrence: 5
You might ask, why is the occurrence not 10 if wrong material is selected? But, that is not the definition of occurrence. The team is not assessing the likelihood of occurrence if the cause is present. Rather, the team is assessing the likelihood that the failure mode and associated cause will be present sometime during design life. In essence, the team is assessing the occurrence risk of the Failure Mode / Cause, based on current design.
Please let me know if this answers your question.
Carl
Note: My examples above, nemally focused on Design FMEA
BR,
Jan.
Hello Mr. Carlson,
thank you for your quick feedback as well as for effort to explain to me the issue about occurance.
1)
in your example, you estimated by 5. In another words, failure rate is 1 in 2000.
For example, annual production volume is planed to be 600 000pcs (100%), then ranking of 5 means 60000/2000 = 300 failures which will be induces by potential cause in one year (i.e., cause = corrosion of cable wiring due to wrong material selected). 300 failures is your “likelihood” for given potential cause….Is this assumeption correct?
2) your definition of cause: “corrosion of cable wiring due to wrong material selected” is much better definition bacause in your definition there are both failure cause (i.e., wrong material selected) as well as failure mechanism (corrosion of cable wiring). However, the evalation of occurence is still tricky, becuase another DFMEA team could evaluate occurance by only number 4.
Anyway, trying to define a potetial cause by both, i.e., failure cause plus failure mechanism can give better image to correctly evaluate a posibble occurance during design life of product – do you agree?
BR,
Jan.
Hello Jan,
My answer to your question about the occurrence ranking of 5 is that occurrence ranking is subjective, not objective. The failure rate information in the occurrence rating scales in certain standards are only meant as a *guideline*. The best way to assess occurrence in an FMEA in my opinion is as follows: The FMEA team integrates various pieces of information to subjectively assess the likelihood of occurrence of the failure mode and associated cause. 1) occurrence of similar failures/causes in past products, 2) the degree of change between past and current products, and 3) the prevention controls that are implemented concerning the failure mode and associated cause. Then, the team does their best job to integrate this information and make a subjective assessment to rank the occurrence.
Since occurrence rating is subjective, I wouldn’t place too much emphasis on the failure rate info in the scales. In fact, future standards will be omitting failure rate guidelines to avoid this possible misinterpretation.
Regarding your second point about cause and failure mechanism, I’ve always believed that proper description of cause will help to assess occurrence and detection ratings.
Thanks.
Carl
Does prevention reduce your Occurrence?
Hello Ermias,
The short answer to your questions is “yes.” There are three inputs to Occurrence rating in an FMEA. For a DFMEA, the three inputs are 1) field history for similar items, 2) current prevention-type design controls, and 3) degree of new technology or change in design. For Process FMEAs, the three inputs are 1) manufacturing history for similar process steps, 2) current prevention-type process controls, and 3) degree of new technology or change in the manufacturing process.
As you can see, the prevention controls are input to the occurrence rating. Good prevention controls will typically reduce the occurrence risk.
Please let me know if this answers your question, and if you have any follow-up questions.
Carl
Hi Carl,
When determining post-mitigation occurrence level, is it appropriate to take into account confidence and/or reliability of your verification testing? For example, if you mitigated a risk by testing and with testing you determined with 95% confidence that 99% of the population will be passing, can/should you translate that to an occurrence level in the FMEA? For example, 1% will fail so .01 occurrence?
Thanks in advance!
Hi Alice,
Your question assumes that the final occurrence rating in a Design FMEA occurs after testing. This is often not the case. I’ll respond in two stages.
First, I usually do not use testing as a Recommended Action in a Design FMEA. Design verification and validation are a separate tool from Design FMEA. I prefer to use the Recommended Actions of a DFMEA to improve the product design or improve the tests or analyses. In other words, in a Widget DFMEA, the currently planned tests are entered in the Detection Controls column of the DFMEA, and potential improvements to the widget design or testing are entered in the Recommended Actions column. When the Recommended Actions are executed, the actions taken and resultant Severity, Occurrence and Detection risk ratings are documented.
Second, once the Recommended Actions are executed, the DFMEA team uses their best judgement to estimate the resulting S, O, and D after the actions have been taken. When estimating the Occurrence, the DFMEA team can use any information that is available, which could include available test results. However, if the DFMEA is performed early (which is ideal), test results are often not available. The DFMEA team makes its best estimate of the resulting Occurrence rating after the Recommended Actions have been implemented.
To illustrate, take a look at this excerpt of a Design FMFEA on a projector lamp. For the Cause “hot spots on glass due to over touching,” there are two Recommended Actions. When these actions are executed, the team reassesses the S, O, and D ratings. Most likely, the tests will not have been completed by the time of reassessment. The team will assess the likelihood of occurrence of the hot spots causing the lamp to burn out, after the new glass coating has been implemented.
https://accendoreliability.com/wp-content/uploads/2019/09/ProjectorLampDFMEAexcerpt.jpg
One last note, Occurrence ratings in an FMEA are usually subjective, not objective. The reason for this is the DFMEA is done in a timeframe when objective data is often not available.
Hope that helps. Please feel free to ask any follow-up questions.
Carl
Thank you! That is very helpful. Would you ever use verification results (conf/rel) in an FTA or would it be the same answer as you gave for FMEA?
Hi Alice,
As I wrote in my reply to you about DFMEA occurrence, “When estimating the Occurrence, the DFMEA team can use any information that is available, which could include available test results. However, if the DFMEA is performed early (which is ideal), test results are often not available.”
The same is true for FTA. If FTA is being done early in the product development process, test results may not be available. However, if FTA is being used to model complex failure information at a time when test data is available, such data can be input to the FTA modeling.
Hope that helps.
Carl
Hi Carl!
I’ve read a decent amount and have a copy of Effective FMEAs and spent some time in the automotive industry with FMEA experience. I’ve since switched to the med device industry where the current company I work for is in its infancy with FMEAS and also are attempting to combine with a Hazard Analysis. Given the shear scale of products produced the pFMEAs are set up at a very generic process level where failure effects attempt to account for any possible effect that may occur to all products that are subject to the process in question. Is this an approach you’ve seen before?
Thanks!
Hi Addison,
Thank you for your question.
When there are multiple products that undergo similar production assembly processes, I have seen cases where the “generic” process is analyzed with a single PFMEA, rather than each individual process. This can have pros and cons.
Before I answer your question in more detail, I’d like to ask you three questions.
1. Approximately how many different devices are being analyzed with a single PFMEA, and how different are the devices?
2. Can you clarify what is meant by, “failure effects attempt to account for any possible effect that may occur to all products that are subject to the process in question”? Are you saying the Effect description in the PFMEA is only entered is the Effect applies to all devices?
3. Are individual DFMEAs done for each unique device, and are these inputs to the PFMEA?
Thanks.
Carl
Hi Carl,
Thanks for taking the time to answer my question.
So for example, we have one pFMEA for “Milling” where this pFMEA attempts to account for all products that undergo milling. Given the breadth of products we manufacture these can be drastically different.
More Info:
There is an annual review to update occurrence values of causes/failure modes.
Severities are based off impact to the customer or “harm” as required per 14971
Outputs from the pFMEA are of course process improvement initiatives but also are primarily used to generate validation levels depending on risk level.
Concerns I have:
1. We’re missing controls that may be product specific since the FMEA is so generic
2. Occurrence values may be diluted. The process may not have great controls for a new novel product but a mature product may be well controlled. If we’re attempting to use the rating the pFMEA to validate new products then we’re putting ourselves at risk.
3. Its very unlikely that you can consider all the potential effects to the customer for one failure mode. As I mentioned previously, these there are hundreds of unique products that may be subject to “milling”, the process engineers are thinking from a high level and can’t consider how an “undersized diameter” may effect the end user for all devices.
I suppose the main issue is the shear amount of unique products we deal with. Creating unique pFMEAs for each product and understanding the impact of failure from a process engineer prospective may be difficult. The annual reviews also become a bit unscalable with more pFMEAs needing updates to occurrence each year.
I’m contemplating several solutions but not sure if there are any industry standards for these cases.
Any thoughts?
Thanks!
Hi Addison,
Thank you for the clarifications.
I understand your concerns. There are advantages to a generic PFMEA, however, you are outlining some of the limitations. I would consider preliminary risk assessment to identify the prioritized listing of individual PFMEAs that are most important. You can read about preliminary risk assessment here: https://accendoreliability.com/preliminary-risk-assessment/
Although this article focuses on DFMEA, the same approach works to prioritize PFMEAs.
Hope that is helpful.
Carl
Great! Thanks Carl
Hi Carl,
I really enjoy reading your posts related to FMEA. I’m a Reliability Engineer that have being facilitating FMEAs and RCMs several times already, majority DFMEAs, some PFMEAs and lately lots of RCMs in equipments that have been out there for several years.
1) My question is a little more related to the criteria for Occurrence, how to avoid the score to mild (between 4 and 6)?
2) Also, after getting my RPN calculated sometimes I can’t treat all the FMs. I need to decide which ones I will assign an action. What is your approach to that? How can we avoid to miss that FMs that may impact heavily in the future?
I was wondering about question 2 while thinking about COVID-19. Severity of an unknown disease should be high, detectability is difficult so it should be high as well, occurrence of aerial virus is quite high (flu is out there since 1900, for example). Have we mapped COVID-19 and not treat it properly? Or we just missed it?
Thanks!
Hi Geraldo,
I’m glad to hear you are enjoying reading the Inside FMEA articles.
Regarding your question about occurrence rating. If you want to reduce the occurrence rating to a value that is below the Moderate range (4 to 6), you and your FMEA team can use certain strategies to reduce occurrence rating. Please reference my article: https://accendoreliability.com/action-strategies-reduce-occurrence-risk/
Regarding your question about which RPN issues to address. Please reference my article: https://accendoreliability.com/understanding-prioritize-risk-corrective-actions-fmea/
Let me know if you have any other questions.
Carl
Dear Carl
Good day.
I have one question regarding the temperature and humidity control. Now we already apply the auto detect for the temperature. When the temperature and humidity is out of the limit, the system will automatic send email to triggle and adjust the air-cond. In this case Occurance will be in ranking 1
Regards
Poh Suan
Hello Poh Suan,
The answer to your question depends on the type of FMEA you are doing, the specific FMEA procedure (scales, worksheet columns, etc.), and the function you are analyzing.
I’ll assume, for the purpose of answering your question that you are doing a Design FMEA on a temperature and humidity control system. I’ll also assume you are using conventional SOD scales and worksheet columns, as outlined in one of the recent FMEA standards.
Starting with a definition, “Occurrence is a ranking number associated with the likelihood that the failure mode and its associated cause will be present in the item being analyzed. For System and Design FMEAs, the occurrence ranking considers the likelihood of occurrence during the design life of the product.”
For a hypothetical function “automatically send an email to the customer when temperature and humidity is out of the limit and tell the customer to adjust the air conditioning,” then you can analyze the failure modes, effect and causes for that function. The occurrence rating will depend on the specific failure mode and cause for that function.
For a hypothetical function “automatically send an email to adjust the air conditioning when temperature and humidity is out of the limit and make the correct adjustment,” then you can analyze the failure modes, effect and causes for that function. Similarly, the occurrence rating will depend on the specific failure mode and cause for that function.
I would not assume the occurrence is 1 without doing the appropriate FMEA to justify that rating.
Hope that helps. Feel free to ask any follow-up questions.
Carl
Dear Carl
Thanks for the reply and guide. i am doing PFMEA.
Meaning that, although we using auto detect also have failure and need to monitoring. am i right.
Regards
Poh Suan
Hi Carl,
Thanks for amazing inputs. I am an engineer in automative industry where we execute PFMEA so much in our processes.
My question is this, as you know for the SC characteristics, ranking is 5-8 for Severity; 4-10 for Occurence. When we do the correct pointing at first and just assume that we take action which effects occurence with preventive action; than can I reduce the occurence to 3-2-1 even though it is SC characteristic? Or regarding the rule, it has to be stayed at 4 even though It should be less after action?
Thanks in advance.
Hello Celal,
Thank you for your question relating to the application of special characteristics in Process FMEAs.
The proper use of special characteristics can help ensure that manufacturing processes achieve high quality products. There are many resources that can help guide you in the proper application of special characteristics.
Design FMEAs can help to identify Special Product Characteristics. See article:
https://accendoreliability.com/dfmeas-can-identify-special-product-characteristics/
Process FMEAs can help to identify Special Process Characteristics. See article:
https://accendoreliability.com/pfmeas-can-identify-special-process-characteristics/
This article answers a reader question about the use of special characteristics for components in a Process FMEA.
https://accendoreliability.com/fmea-q-special-characteristics-process-fmea/
I also provide guidance on the use of special characteristics in chapter 5 and 6 of my book, Effective FMEAs.
ISO/TS 16949:2009, VDA, and other standards offer explanation and guidance for the application of special characteristics. However, it is my experience that the procedure for the designation of special characteristics is up to the individual company, unless mandated by OEM or customer. The rules for designation of critical characteristics vs significant characteristics are likewise up to the company, unless mandated by OEM or customer.
The Process Control Plan includes Special Characteristics and inspection methods required to deliver products that meet the customer quality requirements. Proper use of Process FMEA can link to the Process Control plan. SAE J1739:2021 describes these linkages.
Regarding your question about whether you can reduce the PFMEA occurrence rating even though there is a special characteristic assigned, the answer is yes, it is possible. The revised occurrence rating depends on the FMEA Recommended Actions. When the Recommended Actions are implemented, the FMEA team reassesses S, O, and D, and the revised values depend on the effectiveness of the actions themselves.
I hope this helps with your question. Feel free to ask any follow-up questions.
Carl