PFMEA vs MFMEA or DFMEA on equipment/machinery

[tugboat]

Hi everyone! I'm new around here and have a question. I've been tasked with creating a PFMEA on a dip painting operation on a large steel part that consists of the following steps, each with its own tank and controlled by an overhead shuttle:

1. Alkaline Cleaner
2. Rinse
3. Hot Rinse
4. Dryer
5. Cooling
6. Acrylic Enamel Dip
7. Flash dry
8. Cure Dry
9. Cool Off

The problem is that this is being done backwards and we're trying to put the cart before the horse. We have no DFMEA, and Quality is chomping at the bit for a control plan without a PFMEA. As I understand PFMEA the process requirements would be something like (and this is hardly an all encompassing list): No soil contaminants (Alkaline cleaner step), Cleaning solution removed (hot rinse step), part fully coated (acrylic enamel dip step), Paint dry film thickness 2 mil (cure dry).

This would mean root causes (again, hardly comprehensive) in the PFMEA would be things like Alkaline Cleaner pH too low (Alkaline Cleaner too low), water temperature too low (hot rinse step), paint level too low (acrilyc enamel dip step), paint concentration too low in dip tank (cure dry step).

Where I'm getting confused is that some of the process requirements that Quality is including in their (too early) control plan in the product/process specification/tolerance section is things like tank pH, paint viscosity, and solution temperature, and this seems to me to be root causes in a PFMEA, possibly to inform a DFMEA on this painting "machine" and not process requirements. After all, design isn't going to call out wet paint viscosity on a drawing, they're going to call out things like adhesion, DFT, paint hardness, and paint coverage. Then, my thinking goes, the PFMEA will drum up stuff in the root cause section such as cleaner pH, paint viscosity, etc... Then, ideally, this would parlay into other documents such as gage r&r or design FMEA on this new painting "machine" to help suss out the time to failure parameters like paint viscosity and cleaner pH.

Does anyone have any insight into this? Am I on the right track or should things like tank pH and wet paint viscosity be included as process requirements?

 

[John C. Abnet]

Good day @tugboat
First question. Does your organization do the product design work (or does your customer design the product requirements?)
The DFMEA needs to come from the design team/design source. If that is the customer...although it SHOULD be provided to your organization and your organization should make every attempt to gain, it is sometimes difficult.

Your implied sequence understanding is correct. Past problem history, lessons learned, DFMEA, "print" (product requirements), process flow map, etc... are indeed inputs into a proper PFMEA. The PFMEA is then the input into the control plan.

Assuming a DFMEA is not immediately available and your organization is forced to "cheat", then utilize the other inputs I described above. In addition, TALK to the operators \/manufacturing/process owners (i.e. find out what can go wrong, what does go wrong, what is their "stone in the shoe".

You want to take all the inputs that should lead to SUCCESSFUL dip painting (e.g. proper cleanliness ) and then consider if IMproper cleanliness can contribute to a POOR dip paint. In that example IMPROPER cleanliness may be a "Failure Mode". Your organization should then identify all of the potential contributors to IMPROPER cleanliness and the current controls and the risks associated.
Once a PFMEA has been created and the process is functioning, the created PFMEA can then be "stressed test" by using the actual process to test/challenge the PFMEA (so called "reveres PFMEA).

Keep in mind also, that during the PFMEA creation it should be assumed that SUPPLY COMPONENTS and product DESIGN are good.

From my limited familiarity with dip painting, I would assume EACH of the process steps you have listed should be stated on your PFMEA and addressed accordingly as I believe them all to have autonomous ability to negatively impact the dip painting process.

Does your organization have the AIAG PFMEA 4th edition manual? It should be well understood. Is your organization required or choosing to use the AIAG/VDA harmonized PFMEA approach? If "yes" then that manual should be well understood. Have you/your organization had sufficient training/mentoring of the PFMEA process? (These are key as lack of any can cause the foundation of your organization's PFMEA to be weak/poor, which is then manifested in the control plan and actual process).


Hope this helps.
Be well.

 

[tugboat]

Good day @tugboat
First question. Does your organization do the product design work (or does your customer design the product requirements?)
The DFMEA needs to come from the design team/design source. If that is the customer...although it SHOULD be provided to your organization and your organization should make every attempt to gain, it is sometimes difficult.

Your implied sequence understanding is correct. Past problem history, lessons learned, DFMEA, "print" (product requirements), process flow map, etc... are indeed inputs into a proper PFMEA. The PFMEA is then the input into the control plan.

Assuming a DFMEA is not immediately available and your organization is forced to "cheat", then utilize the other inputs I described above. In addition, TALK to the operators \/manufacturing/process owners (i.e. find out what can go wrong, what does go wrong, what is their "stone in the shoe".

You want to take all the inputs that should lead to SUCCESSFUL dip painting (e.g. proper cleanliness ) and then consider if IMproper cleanliness can contribute to a POOR dip paint. In that example IMPROPER cleanliness may be a "Failure Mode". Your organization should then identify all of the potential contributors to IMPROPER cleanliness and the current controls and the risks associated.
Once a PFMEA has been created and the process is functioning, the created PFMEA can then be "stressed test" by using the actual process to test/challenge the PFMEA (so called "reveres PFMEA).

Keep in mind also, that during the PFMEA creation it should be assumed that SUPPLY COMPONENTS and product DESIGN are good.

From my limited familiarity with dip painting, I would assume EACH of the process steps you have listed should be stated on your PFMEA and addressed accordingly as I believe them all to have autonomous ability to negatively impact the dip painting process.

Does your organization have the AIAG PFMEA 4th edition manual? It should be well understood. Is your organization required or choosing to use the AIAG/VDA harmonized PFMEA approach? If "yes" then that manual should be well understood. Have you/your organization had sufficient training/mentoring of the PFMEA process? (These are key as lack of any can cause the foundation of your organization's PFMEA to be weak/poor, which is then manifested in the control plan and actual process).


Hope this helps.
Be well.

I'm new to the company but FMEA's in general are a new thing here. I myself have limited experience with them (I used them quite a bit at my old job as a risk mitigation tool to major projects, not manufacturing processes). Regarding the AIAG PFMEA manual(s), I'm not sure, I'll have to check. We have an incomplete list of critical requirements from Design, effectively it must be fully coated, 1.5-2.0 mil DFT, and no excessive runs or sags on the exterior of the part.

My plan is to include each step listed above as a process step, but my main question, put a bit more concisely, is what exactly are the process requirements? My understanding, and it seems like you may be in agreement, is that the requirements of, say, the Alkaline Cleaner step would be something like:

1. No soil contaminants (or some minimum specified number if available)
2. No oil contaminants
3. No rust

This would put failure modes as the opposite of those:

1. Excessive soil contaminants
2. Oil on part
3. Rust on part

and the failure modes such as as

1. Touch-up
2. Strip & repaint
3. Premature warranty claims (which our plants get hit for)

and root causes such as:

1. Cleaner temp too low/high
2. Conductivity too high
3. Cleaner too dirty
etc...


What the quality rep is putting down on the control plan in the product/process specifications, which would IMO typically be the this:

1. No soil contaminants (or some minimum specified number if available)
2. No oil contaminants
3. No rust

they are instead writing the control plan as if these are the process requirements:

1. Cleaner temp too low/high
2. Conductivity too high
3. Cleaner too dirty
etc...

So...should a PFMEA focus on what the requirements are for the part or the requirements of the process to achieve a good part? Seems like, for a drilling operation the requirement would be X in. +/- Y, and a root cause would be "drill speed too high".

 

[John C. Abnet]

I'm new to the company but FMEA's in general are a new thing here. I myself have limited experience with them (I used them quite a bit at my old job as a risk mitigation tool to major projects, not manufacturing processes). Regarding the AIAG PFMEA manual(s), I'm not sure, I'll have to check. We have an incomplete list of critical requirements from Design, effectively it must be fully coated, 1.5-2.0 mil DFT, and no excessive runs or sags on the exterior of the part.

My plan is to include each step listed above as a process step, but my main question, put a bit more concisely, is what exactly are the process requirements? My understanding, and it seems like you may be in agreement, is that the requirements of, say, the Alkaline Cleaner step would be something like:

1. No soil contaminants (or some minimum specified number if available)
2. No oil contaminants
3. No rust

This would put failure modes as the opposite of those:

1. Excessive soil contaminants
2. Oil on part
3. Rust on part

and the failure modes such as as

1. Touch-up
2. Strip & repaint
3. Premature warranty claims (which our plants get hit for)

and root causes such as:

1. Cleaner temp too low/high
2. Conductivity too high
3. Cleaner too dirty
etc...


What the quality rep is putting down on the control plan in the product/process specifications, which would IMO typically be the this:

1. No soil contaminants (or some minimum specified number if available)
2. No oil contaminants
3. No rust

they are instead writing the control plan as if these are the process requirements:

1. Cleaner temp too low/high
2. Conductivity too high
3. Cleaner too dirty
etc...

So...should a PFMEA focus on what the requirements are for the part or the requirements of the process to achieve a good part? Seems like, for a drilling operation the requirement would be X in. +/- Y, and a root cause would be "drill speed too high".

These are specific and foundational questions. I hope you are being supported by your organization and not left to do this in a vacuum. These are "multi discipline" exercises. The level of question are getting specific and at some point can ONLY be answered by your organization. I recommend some GOOD (recommended) mentoring if not available in your company.

In regards to "product" vs "process".
Remember. the PFMEA is a PROCESS failure mode effect analyisis.

In regard to the control plan I always teach that PROCESS stays and PRODUCT moves on. For example in a bolt tightening process,.. ..
RPM is a characteristic of the process (i.e. it STAYS at the work center).
The resultant TORQUE is a resulting characteristic of the product (it MOVES on with the product).

Hope this helps.
Be well.

 

[tugboat]

These are specific and foundational questions. I hope you are being supported by your organization and not left to do this in a vacuum. These are "multi discipline" exercises. The level of question are getting specific and at some point can ONLY be answered by your organization. I recommend some GOOD (recommended) mentoring if not available in your company.

In regards to "product" vs "process".
Remember. the PFMEA is a PROCESS failure mode effect analyisis.

In regard to the control plan I always teach that PROCESS stays and PRODUCT moves on. For example in a bolt tightening process,.. ..
RPM is a characteristic of the process (i.e. it STAYS at the work center).
The resultant TORQUE is a resulting characteristic of the product (it MOVES on with the product).

Hope this helps.
Be well.

But in a PFMEA which is the process requirement? In your example as I understand it the requirement of the process will be to torque the bolt. Design would identify that as a critical characteristic and therefore would be a specific process step saying “Torque bolt” with the process requirement to be “to XX ft-lbs”.

the failure mode would be “overtorqued” and a potential root cause would be “RPM too high on torque gun” or something.

 

[John C. Abnet]

Again...these questions are getting specific...and show that some good understanding of the handbook and training sound needed

In the example I referenced...it might look something like this...

Function: PROPER fastener tightening.
Failure Mode: ONE potential could be "Improper RPM".
Effect is what SYMTPON may be experienced. This could include: Noise (rattle); Safety device impaired ; Will not function; Joint failure;
Cause: could include: No communicated RPM requirement; Wrong setting (DC runner); DC runner failure;
Controls could be: Integrated alarm; Communicated requirements via work instruction ABC-xyz; Proper ETC settings.

Don't confuse "root cause" with "cause" in the context of PFMEA. This is not a corrective action. These are "if not done correctly the intended FUNCTION" may not be realized". Process requirements are ALL the contributors that are needed to be correct in order to achieve the intended function (in this case PROPER fastener tightening). Each function may (likely will) have MULTIPLE associated failure modes.
Remember...provided templates (I'm speaking AIAG 4th edition examples right now), are likely overly simplistic and provide only a single row across . In reality, MANY failure modes may exist. Likewise, these failure modes may each have MULTIPLE effects and each effect may have MULTIPLE causes. Yes, when determining RPN (or AP if using AIAG/VDA harmonized method), only the "worst"" effect (severity) "cause" (control); "detection" are used to generate the score but all should be considered and shown to have been considered.

Remember, these are PROCESS inputs (not product results). The only time "product" comes into play is in regard the symptoms that
mis-performing product may cause.

Your are correct to approach to consider the FAILURE MODE(s) as "opposite" of the process function (intent).

Hoe this helps.

Be well.

 

[John C. Abnet]

...you could also be more general, and simply state...

FUNCTION: Proper Fastener Tightening.
FAILURE MODE: Improper Fastener Tightening
CAUSE: RPM too high; RPM too low; Torque too high; torque too low; Angle too high; Angle too low
EFFECT: Noise (rattle); Safety device impaired ; Will not function; Joint failure;
CONTROLS: work instruction "xyz'; ECT settings (proper RPM); ECT settings (proper angle settings; ECT settings (proper torque setting); integrated alarm

Hope this helps.
Be well.

 

[tugboat]

...you could also be more general, and simply state...

FUNCTION: Proper Fastener Tightening.
FAILURE MODE: Improper Fastener Tightening
CAUSE: RPM too high; RPM too low; Torque too high; torque too low; Angle too high; Angle too low
EFFECT: Noise (rattle); Safety device impaired ; Will not function; Joint failure;
CONTROLS: work instruction "xyz'; ECT settings (proper RPM); ECT settings (proper angle settings; ECT settings (proper torque setting); integrated alarm

Hope this helps.
Be well.

I don’t think you’re being consistent here. In two posts you consider rpm too high both as a failure mode and a cause. Which is it? I consider high rpm a cause. I fear if you start putting machine requirements to achieve a good part in the same column (Process Requirements) with product specifications or characteristics you’ll have product quality mixed up with “machine specifications”, which will result in the same items being considered both causes and product requirements in the same document.

I feel it’s an either - or situation.

 

[Jim Wynne]

I don’t think you’re being consistent here. In two posts you consider rpm too high both as a failure mode and a cause. Which is it? I consider high rpm a cause. I fear if you start putting machine requirements to achieve a good part in the same column (Process Requirements) with product specifications or characteristics you’ll have product quality mixed up with “machine specifications”, which will result in the same items being considered both causes and product requirements in the same document.

I feel it’s an either - or situation.

It's a process failure exercise. The AIAG manual is wrong on several fronts, imo, and this is one of them. Ask yourself how the process might fail, and what the consequences (effects) might be. Product defects are not process failure modes.

 

[John C. Abnet]

I don’t think you’re being consistent here. In two posts you consider rpm too high both as a failure mode and a cause. Which is it? I consider high rpm a cause. I fear if you start putting machine requirements to achieve a good part in the same column (Process Requirements) with product specifications or characteristics you’ll have product quality mixed up with “machine specifications”, which will result in the same items being considered both causes and product requirements in the same document.

I feel it’s an either - or situation.

It's simply contingent on how an organization lays out its process flow and the resultant level of granularity.

Consistent with my previous questions...
- Does your organization have/is familiar with the applicable AIAG / AIAG-VDA handbook(s) ?
- Do your organization provide access to training/mentoring?
- Does your organization approach to PFMEA creation provide the interdisciplinary teams/support needed to do a proper PFMEA?

Remember, the PFMEA is not a "one and done" activity/document. It is intended to be a living document that considers the process aspects which,
if not correct, cause risk that the intended function (process output) may not be realized, so the organization can apply controls to eliminate and/or mitigate those risks.

Hope this helps.
Be well.