L

ljazz

#1
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?
 

Jim Wynne

Super Moderator
#3
Re: Cause vs mode in process control and rankings

Again..... sorry for the long post.
Welcome to the Cove. :bigwave:

The rankings in the AIAG manual (and its SAE counterpart) are clearly described as suggestions, and the manual says that alternate schemes may be used so long as they're used consistently. Of course, that might not help if you have a customer who requires use of the (mostly useless) AIAG rankings.

Here's the way I've always preferred to do it, and the way I encouraged suppliers to do it while working for a vehicle OEM:

Occurrence: The likelihood that the cause will occur, because it's the cause that I want to prevent.

Detection: The likelihood that a defective product will go undetected prior to being shipped or having additional value added.

IMO, a PFMEA should be about process control and prevention. Thus I also encourage using potential process failures as the failure modes, and product defects as effects. I want to know with as much certainty as possible how the process might fail, and what I can do to prevent each potential failure. In similar fashion, I think that far too little attention is paid to process characteristics in automotive control plans. The output PFMEA should inform me what what needs to be controlled in the process such that the need for inspection is minimized. It should be a Process Control plan.
 
L

ljazz

#4
Re: Cause vs mode in process control and rankings

I completely agree with it being about process control. I do agree, you should be trying to prevent actual cause where ever and when ever possible. I also agree that far to little attention is given to process characteristics.

So then, based on your preferences, where would you count cause detection that prevents you from welding a bad part? And where/how would that reflect in your rankings (occ or det)?

The number 2 detection ranking suggestion would lead you to believe there..... but again, that does NOT assume you've run the bad part (that is a very specific and direct conflict..... suggested use or not). SAE was training in the late 80's/early 90's that you MUST assume the part was run. I'll also point out that SAE was directing that "likehood" of cause occurrence was to be used in lue of having actual failure rates from the subject process or similar processes.

Why after 20 years do we still have these types of conflicts in the documents?

For my organization, I believe it makes the most sense to count any control in the station that prevents the running of a bad part in that station as a prevention control........ and then take an accurate and realistic look at my detection systems for finding bad parts. I'm afraid that looking at a prox in the station that prevents running the part as my detection, is not going to put a realistic ranking on the detection. From there, I'd be covering the prox failure in another row of the fmea (or several rows)...... then I'll end up with a huge, unwieldy FMEA, that no one will even bother to try to navigate through later (I have welders here with up to 12 prox's)....... the living document will die from obesity.
 
Last edited by a moderator:

Jim Wynne

Super Moderator
#5
Re: Cause vs mode in process control and rankings

I completely agree with it being about process control. I do agree, you should be trying to prevent actual cause where ever and when ever possible. I also agree that far to little attention is given to process characteristics.

So then, based on your preferences, where would you count cause detection that prevents you from welding a bad part? And where/how would that reflect in your rankings (occ or det)?

The number 2 detection ranking suggestion would lead you to believe there..... but again, that does NOT assume you've run the bad part (that is a very specific and direct conflict..... suggested use or not). SAE was training in the late 80's/early 90's that you MUST assume the part was run. I'll also point out that SAE was directing that "likehood" of cause occurrence was to be used in lue of having actual failure rates from the subject process or similar processes.

Why after 20 years do we still have these types of conflicts in the documents?

For my organization, I believe it makes the most sense to count any control in the station that prevents the running of a bad part in that station as a prevention control........ and then take an accurate and realistic look at my detection systems for finding bad parts. I'm afraid that looking at a prox in the station that prevents running the part as my detection, is not going to put a realistic ranking on the detection. From there, I'd be covering the prox failure in another row of the fmea (or several rows)...... then I'll end up with a huge, unwieldy FMEA, that no one will even bother to try to navigate through later (I have welders here with up to 12 prox's)....... the living document will die from obesity.
If something in your process prevents something bad from happening, it's a prevention control. "Detection" is about bad things that have already happened. As far as occurrence is concerned, you take the efficacy of your prevention controls into account when deciding how to assign the occurrence value. Given all of the possible causes you've identified, the prevention methods and history with similar items, what's the likelihood of occurrence?
 
L

ljazz

#6
Re: Cause vs mode in process control and rankings

If something in your process prevents something bad from happening, it's a prevention control. "Detection" is about bad things that have already happened. As far as occurrence is concerned, you take the efficacy of your prevention controls into account when deciding how to assign the occurrence value. Given all of the possible causes you've identified, the prevention methods and history with similar items, what's the likelihood of occurrence?

I would agree..... prevention of something bad happening. I'm just getting caught up in the re-emphasized "Detection of cause" stuff with the addition of detection ranking #2.

I'm pouring through 20 year old notes here (from SAE training.... I wish my handwriting was better!!!) and it looks like the detection of cause had to do with failure mechanisms from upstream processes. For instance, I may have a sensor that detects an incorrect component, thus preventing me from misloading and running (so a prevention control), but it would be a detection for the upstream component repack operation that sent me mixed parts. Does that make sense?

BTW.... Thanks for your input!!!
 

Jim Wynne

Super Moderator
#7
Re: Cause vs mode in process control and rankings

I would agree..... prevention of something bad happening. I'm just getting caught up in the re-emphasized "Detection of cause" stuff with the addition of detection ranking #2.

I'm pouring through 20 year old notes here (from SAE training.... I wish my handwriting was better!!!) and it looks like the detection of cause had to do with failure mechanisms from upstream processes. For instance, I may have a sensor that detects an incorrect component, thus preventing me from misloading and running (so a prevention control), but it would be a detection for the upstream component repack operation that sent me mixed parts. Does that make sense?

BTW.... Thanks for your input!!!

Everything depends on the scope of the FMEA. Nonetheless, for each operation you should assume that the incoming material is good, and only consider the potential failure modes of the current process. That's another reason I like to use process failures as modes.
 

It Was I Who

Involved In Discussions
#8
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?
Hi
See if got this right and understand it right
i would have set the prevention into 1 becuase you can't produce the after comming part (Right)
" Error (Cause) prevention as a result of fixturing design, Machine design or part design. Discrapent part cannot be made because items has been error proofed by process/Product design, and for detection i would have placed a description on how i would have control over the prevention, Like a poka yoke tester at start up (1 bad part to test the preventiv and 1 good part) to make shure that i find all the bad parts

Due to as You said that it's "preventing" the welder from cycling

The step i would have taken from there is to get back to where the bad part has been made and made a control point of the failure


Tommy
 

Top Bottom