PFMEA – can control be prevention?

(Note – text only for FMEA enthusiasts)

A very typical problem with FMEA analysis is distinguishing control from prevention. Undoubtedly an additional complication here is the obvious errors in the automotive standards for this method (AIAG and VDA):

• AIAG ed. 4 – work instructions are entered as a method of detection (“model” example of PFMEA).
• AIAG & VDA ed. 1 – in the figure distinguishing prevention from control, it is stated that control occurs only after the appearance of the product characteristics (defect) and yet there is such a thing as control of the cause which occurs before the defect “comes into the world”.

Definitions

In general it is useful to make some clear division (distinction):

• Prevention: action to PREVENT the occurrence of the cause.

• Control: an action to DISCOVER a defect or cause.

So the control according to the PFMEA will undoubtedly be among other things: visual assessment of the finished product (defect control), 100% automatic camera test for the presence of labels, sensor for the presence of a set of plates before the start of the riveting process (cause control).

But…will every control in terms of PFMEA be a detection actions?

What for example in the case of control of the cause of the cause (strange though it sounds). If control is applied in the process to detect the phenomenon that will lead to the appearance of the failure cause (that is the cause of the cause) then it becomes a form of preventive action.

This is clearly shown in the figure below:

Fig. 1 Checking the cause of the cause.

Therefore if we consider that prevention is an action aimed at reducing the possibility of the failure cause (and this is how it should be understood in the context of PFMEA) then the control of the cause of the cause should be considered as prevention.

This is how control becomes prevention. This is clearly illustrated by the following diagram:

 

 

Therefore when analysing the consistency of two important documents: PFMEA and control plan (CP) it will be vain to look for elements such as TPM or 5S audit in this definition.

But…* it is possible that sometimes you may have to go against the logic discussed above for pragmatic reasons.

*this is the second “but” in the context of the subject matter described here

This is about the situation when you control the cause of the cause during the process and this control you want to show in the control plan. Of course it is not about such analyses when both PFMEA and CP are documented in a spreadsheet because then you can enter “everything everywhere” for yourself.

However when dedicated good software (e.g. PQ-FMEA, IQ – RM, Plato) is used for FMEA we will be “watched over” by the logic built into it. And this one with PFMEA is obvious: the failure cause is due to faulty process characteristics, and in CP the cause control is process characteristics control. Therefore if we want to include control of the cause of the cause in CP then we need to slightly disrupt the logic discussed below.

For example:

Failure: the roughness of the plane after cutting worse than in the requirements

Cause: knife vibration during the cutting process

The cause of the cause: ineffective lubrication – the set amount of lubricant was not given

Supervising

Process characteristics – the amount of lubricant administered

Detection – flow meter control of the administered dose of lubricant

 

Summary

So sometimes there may be a desire to show in the CP control of something that is neither a defect nor something that may be its cause. The moderator will have two solutions in such a situation:

1. Adding a non-direct cause (here: the amount of lubricant) and assigning a control to it.
2. Assigning the control of the indirect cause to the direct cause (kind of like indirect detection) – but here there will be a small problem with CP logic.

So a way can be found for many unusual situations – you just need to have the right knowledge so that the solutions applied do not turn into chaos.