1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice
You must be a registered member in order to post messages and view/download attached files in this forum.
Click here to register.

OCC and DET score for "Error Proof" prevention control

Discussion in 'FMEA - Failure Modes and Effects Analysis' started by Pongsakorn, Apr 12, 2025.

  1. Pongsakorn

    Pongsakorn Active Member

    Joined:
    Aug 10, 2015
    Messages:
    73
    Likes Received:
    16
    Trophy Points:
    7
    When the prevention control is "Error Proof", the OCC score can be "1" since the failure cannot occur due to the potential cause is totally eliminated. Some of my customer defined in the procedure and ask me to follow that "if OCC score is 1, DET score must be also 1".
    I think that it is incorrect since the the Error Proof control is for only 1 potential cause only, the failure can still occur from other potential causes. I understand that DET score can be 1 when the failure mode is eliminated through product or process design only.
    Please comment if my understanding is correct.
     
  2. Andy Nichols

    Andy Nichols Moderator Staff Member

    Joined:
    Jul 30, 2015
    Messages:
    5,412
    Likes Received:
    2,691
    Trophy Points:
    112
    Location:
    In the "Rust Belt"
    Can you post a “clean” example so we can review the first few columns of your pfmea?
     
  3. Bev D

    Bev D Moderator Staff Member

    Joined:
    Jul 30, 2015
    Messages:
    672
    Likes Received:
    730
    Trophy Points:
    92
    Location:
    Maine
    There is a lot of confusion and mixed messaging regarding whether or not you score occurence and detection on the causes of failures or only on the failure modes themselves. This is likely what is leading to confusion here.

    Since severity is almost always assessed against the failure mode’ effects I have alwasy directed my people to assess the occurence and detection against the failure mode as well (this is backed up a bit by the RPN being the multiplication of the severity, occurence and detection ratings for the failure mode’s effect.***)
    Of course if you have a control on a cause then you should assess the occurrence of the cause before deciding what kind of error proofing should be applied. Once an error proofing is applied you should assess the occurence the effectiveness of the error proofing this will tell you is the error proofing is effective (detection) at catching - hopefully - all occurrences of the error. Then you can update the occurence of the failure mode based on the reduction of that cause. But I cannot see updating the detection of the control/inspection of the failure mode unless the effectiveness of the detection of the failure mode was dependent somehow on the type of cause. Occurrence and detection are typically not completely independent of each other…

    This convoluted situation you describe occurs frequently when we treat the FMEA as a form to be filled out instead of an aid to preventing problems/failures.

    Please not that I DO NOT EVER calculate an RPN. (Or SO). But I didn’t have a Customer that demanded it…
     
    Andy Nichols likes this.
  4. Miner

    Miner Moderator Staff Member

    Joined:
    Jul 30, 2015
    Messages:
    655
    Likes Received:
    562
    Trophy Points:
    92
    Location:
    Greater Milwaukee USA
    I always refer back to the Ford FMEA Handbook as the Gold standard. It is way more detailed than the AIAG manual for pre-AIAG/VDA FMEAs. Their guidance for PFMEA states:
    • Severity - Enter the Severity rating for only the most serious effect in the Severity column. Therefore, there will be one Severity column entry for each Failure Mode. upload_2025-4-15_7-12-53.png
    • Occurrence - Estimate the rate of Occurrence for each Cause listed. If the Occurrence of the Cause cannot be estimated, then estimate possible Failure rate. The Failure rate can be based upon historical manufacturing and assembly Failure rates experienced with similar or surrogate parts. If available from a similar process, statistical data should be used to determine the Occurrence ranking. In all other cases, a subjective assessment can be made by utilizing the word descriptions in the left column of the table, along with any historical data available for similar processes. An Occurrence value is entered for each Cause. After the Occurrence rating is established, the team then returns to the Classification column to designate Significant Characteristics (SC) in the Process FMEA. Consider existing process controls and/or methods that are intended to prevent, or reduce, the Occurrence of the Cause of the Failure Mode. Also, consider the quantity and magnitude of potential incoming sources of variation when estimating Occurrence.
    • Detection - Detection is the rank associated with the best Detection (Type 2) control listed in the process control column. Detection is a relative ranking, within the scope of the individual FMEA. In order to achieve a lower ranking, generally the planned process control has to be improved.
    Assume the failure has occurred and then assess the capabilities of all "Current Process Controls" to prevent shipment of the part having this Failure Mode or defect. Do not automatically presume that the Detection ranking is low because the Occurrence is low (e.g., when Control Charts are used), but do assess the ability of the process controls to detect low frequency Failure Modes or prevent them from going further in the process.

    Random quality checks are unlikely to detect the existence of an isolated defect and should not influence the Detection ranking. Sampling done on a statistical basis is a valid Detection control.

    When estimating a Detection rating, consider only those controls that will be used to detect the Failure Mode or its cause. Controls intended to prevent or reduce the Occurrence of a Cause of a Failure Mode are considered when estimating the Occurrence rating. Since prevention controls do not detect, these controls would be rated 10.

    The FMEA team should collectively rate the capability of each process control to detect the Cause of the Failure Mode. When several Detection controls are listed, enter the lowest rating (the best Detection method or lowest in combined Detection ratings). Optionally, if all controls will be used concurrently, determine a composite Detection rating based upon the accumulated controls.

    First, determine if any of the process controls listed can be used to prevent the Cause of a Failure Mode. If a control is a prevention control, enter it into the prevention section of the Controls column. Remember that the Occurrence rating may be affected. Next, estimate the effectiveness of each Type 2 process control mode listed. When estimating effectiveness, consider the effectiveness factors on the next page. Estimate the capability of each process control to detect the Failure Mode or the Cause. Assume the Failure Mode has occurred. Rate the Detection control based upon its overall effectiveness.

    Use the Detection ranking table for Process FMEA to select a Detection rating number. Rate only those controls intended to detect. If the ability of the controls to detect is unknown, or cannot be estimated, then use a Detection rating of 10. If there is no detective control, use a 10.

    If 100% automatic gaging is listed as a control, the FMEA team should consider its effectiveness based upon the following factors:
    • Condition of gage
    • Calibration of gage
    • Variation of gage measurement system
    • Likelihood of gage failure
    • Likelihood gaging system will be bypassed

    If 100% visual inspection is listed, the team should consider its effectiveness based upon the following factors:
    • 100% visual inspection is 80% – 100% effective depending upon local conditions
    • The number of individuals who may potentially observe the Failure Mode
    • The nature of the Failure Mode – is it obvious, or is it obscure?
    Single visual inspection is typically rated for Detection not lower (not better) than 8.

    upload_2025-4-15_7-27-46.png
     
    Bev D and Andy Nichols like this.
  5. Bev D

    Bev D Moderator Staff Member

    Joined:
    Jul 30, 2015
    Messages:
    672
    Likes Received:
    730
    Trophy Points:
    92
    Location:
    Maine
    One issue that at times gets overlooked is that not all causes are known and while an effective control on a cause is better (it prevents or substantially reduces the failures and lessens the cost) if there is no inspection/test on the failure itself a new cause can rise up and create the failure which would escape undetected.

    So the focus of FMEA activity in development is, and should be, focused on the inputs and determining which of these have a major effect on the output characteristics, setting specifications that guarantee in-specification outputs and establishing controls to maintain the specifications. AND in the end it is the final failure or defect that will need a control/inspection/test….
     
    Andy Nichols and Miner like this.
  6. Andy Nichols

    Andy Nichols Moderator Staff Member

    Joined:
    Jul 30, 2015
    Messages:
    5,412
    Likes Received:
    2,691
    Trophy Points:
    112
    Location:
    In the "Rust Belt"
    Very well said. It's common for the FMEA to be misunderstood in that it's not "dreaming up" potential failure modes. It's based on simply determining what can happen and then updating as new failure occur.
     
  7. John C. Abnet

    John C. Abnet Well-Known Member

    Joined:
    May 23, 2017
    Messages:
    767
    Likes Received:
    538
    Trophy Points:
    92
    Location:
    Upper Midwest- USA
    Lots of considerations here.
    1-Why is the customer 'dictating' how your PFEMA is developed?
    2- Detection assumes the defect WAS created. Occurrence and Detection are not tied together in this context.
    The only real "rule" has to do with "Severity", which of course can not be changed unless a redesign or reapplication.

    Ask your customer directly. ...what are they hoping to actually accomplish?....how do they believe your organization and/or they (customer) will be more protected if you follow their 'guidance' ?

    Only do what is beneficial. The PFMEA is a tool. Use it as a tool to ACCOMPLISH a goal.

    Hope this helps.

    Be well
     
  8. Bev D

    Bev D Moderator Staff Member

    Joined:
    Jul 30, 2015
    Messages:
    672
    Likes Received:
    730
    Trophy Points:
    92
    Location:
    Maine
    One point of clarification:
    There is a sequence to certain types of failure creation and escape that goes like this: (backwards)

    Failure is detected before the effect occurs
    Defect is detected before Failure occurs
    Defect is prevented from occurring by detecting the error or out of spec condition before the defect is created.
    The Error is prevented.

    …and of course we shouldn’t get caught up in the semantics of this in order to ‘properly’ fill out the form. We simply need to be aware and knowledgable about these things so we can prevent functional failures…
     
    Andy Nichols likes this.