L
ljazz
Hello all!.... new poster..... with a long post/question on the fmea 4th edition manual:
When it comes to process control, both prevention and detection, like in the previous edition, it says you are preventing / detecting the failure mode or cause. In my experience, most of the time this was taken as prevent the failure from occuring (be it through the cause or the actual failure prevention), and detecting when the actual failure mode occured (not the cause). There is a big difference between detecting the cause, and detecting the actual failure.
The latest edition of the manual muddles this up with it's new detection ranking criteria for #2. In the new manual, rankings 1 and 2 deal with cause. Ranking 1 has never been an issue, because it's always been looked at as "detection is not applicable", even with the old manual and in SAE. The new #2 ranking is a new twist, as it now deals with detecting cause. I believe it's a mistake to look at it this way, because it is in direct conflict with the direction in the manual to "assume the failure has occured" (as noted in this and previous editions) when making a determination of the ranking.
-The previous edition had detection ranking 2 as "in station gauging automatic gauging with auto stop." This would assume you've already run the part.
-The 4th edition has detection ranking 2 as "error (cause) detection in station by automated controls...." This would assume you haven't run the part yet, and the issue is detected ahead of running the part.
Now for an example scenario......
I have a prox sensor in a welder to detect for mis-load of a flange (which causes a failure). The sensor will "detect" when a flange has been mis-loaded, "preventing" the welder from cycling, and therefore not making a bad part. Is this detection, or prevention? Please keep in mind, you can't count this as both..... it's one or the other. The only time a prevention can be used to influence the detection ranking is in the case where you are "hard poka yoked" (can't physicaly load or cycle), in which case you rank it a 1 (detection is not applicable).
According to the new manual, this detection ranking would be a 2. However, this throws out "assume the failure has occurred and then assess capabilities to prevent shipment of the part." Making this assumption is reasonable, because unless you're hard poka yoked, then there is always the risk of detection device malfunction (for whatever reason).
I'll also point out that the occurence ranking is to be based on likelihood that a specific cause/mechanism will occur, yet goes on to say "incidents per items" is based on number of failures..... not causes of failure (although, I believe the intent here is occurance of failure mode by cause). That is just more contradiction. This contradiction was workable in the past, however, the specific inclusion of the detection ranking 2 criteria makes this even more difficult. This issue has always been around, even with the SAE process for PFMEA's.
In the past, I've always dealt with the occurence and detection rankings as the actual failure occurring. I've also worked with others who deal with the causes, however, their PFMEA documents are considerably longer, more detailed, and I would assume much more difficult to manage. In those cases, your detection devices failing now become a cause of failure, so you can imagine how much more involved those documents would be. If you don't include them as a cause of failure, then your pfmea may not account for malfunction.
In our case, this would mean occurrence would be low (getting actual mis-load info on a part that couldn't be run is next to impossible here), and the detection would be a 2. This would result in a very low RPN.
However, if we look at occurrence as the actual number of parts run mis-loaded, we would end up with a higher occurrence ranking, and a higher detection ranking (assuming it's visual and / or possible detection at the final gauge). This would result in a higher RPN number, and a higher likelihood of be addressed in RPN reduction activities.
I've spoken with some of my old colleagues about this, and they believe the contradiction is there so that the organization can determine how they will best benefit and improve.
So, what is your position on how this is to be looked at?
When it comes to process control, both prevention and detection, like in the previous edition, it says you are preventing / detecting the failure mode or cause. In my experience, most of the time this was taken as prevent the failure from occuring (be it through the cause or the actual failure prevention), and detecting when the actual failure mode occured (not the cause). There is a big difference between detecting the cause, and detecting the actual failure.
The latest edition of the manual muddles this up with it's new detection ranking criteria for #2. In the new manual, rankings 1 and 2 deal with cause. Ranking 1 has never been an issue, because it's always been looked at as "detection is not applicable", even with the old manual and in SAE. The new #2 ranking is a new twist, as it now deals with detecting cause. I believe it's a mistake to look at it this way, because it is in direct conflict with the direction in the manual to "assume the failure has occured" (as noted in this and previous editions) when making a determination of the ranking.
-The previous edition had detection ranking 2 as "in station gauging automatic gauging with auto stop." This would assume you've already run the part.
-The 4th edition has detection ranking 2 as "error (cause) detection in station by automated controls...." This would assume you haven't run the part yet, and the issue is detected ahead of running the part.
Now for an example scenario......
I have a prox sensor in a welder to detect for mis-load of a flange (which causes a failure). The sensor will "detect" when a flange has been mis-loaded, "preventing" the welder from cycling, and therefore not making a bad part. Is this detection, or prevention? Please keep in mind, you can't count this as both..... it's one or the other. The only time a prevention can be used to influence the detection ranking is in the case where you are "hard poka yoked" (can't physicaly load or cycle), in which case you rank it a 1 (detection is not applicable).
According to the new manual, this detection ranking would be a 2. However, this throws out "assume the failure has occurred and then assess capabilities to prevent shipment of the part." Making this assumption is reasonable, because unless you're hard poka yoked, then there is always the risk of detection device malfunction (for whatever reason).
I'll also point out that the occurence ranking is to be based on likelihood that a specific cause/mechanism will occur, yet goes on to say "incidents per items" is based on number of failures..... not causes of failure (although, I believe the intent here is occurance of failure mode by cause). That is just more contradiction. This contradiction was workable in the past, however, the specific inclusion of the detection ranking 2 criteria makes this even more difficult. This issue has always been around, even with the SAE process for PFMEA's.
In the past, I've always dealt with the occurence and detection rankings as the actual failure occurring. I've also worked with others who deal with the causes, however, their PFMEA documents are considerably longer, more detailed, and I would assume much more difficult to manage. In those cases, your detection devices failing now become a cause of failure, so you can imagine how much more involved those documents would be. If you don't include them as a cause of failure, then your pfmea may not account for malfunction.
In our case, this would mean occurrence would be low (getting actual mis-load info on a part that couldn't be run is next to impossible here), and the detection would be a 2. This would result in a very low RPN.
However, if we look at occurrence as the actual number of parts run mis-loaded, we would end up with a higher occurrence ranking, and a higher detection ranking (assuming it's visual and / or possible detection at the final gauge). This would result in a higher RPN number, and a higher likelihood of be addressed in RPN reduction activities.
I've spoken with some of my old colleagues about this, and they believe the contradiction is there so that the organization can determine how they will best benefit and improve.
So, what is your position on how this is to be looked at?