FMEA for Automation Engineers: The AIAG-VDA Method Without the Jargon
The short answer
FMEA asks three questions about every way a design or a process can fail: how bad is it, how often will it happen, and will we catch it before the customer does. The AIAG-VDA handbook that replaced the separate American and German methods keeps that idea, adds a structured seven-step process, and replaces the Risk Priority Number with Action Priority, which sorts risks into High, Medium and Low rather than producing a number people negotiate with.
Why RPN went
The old method multiplied Severity by Occurrence by Detection, each 1 to 10, giving an RPN from 1 to 1000, and teams set a threshold: act above 100, for example.
Two things went wrong with that. Identical RPNs meant completely different things, because a severity 10 with occurrence 2 and detection 5 scores the same 100 as a severity 2 with occurrence 10 and detection 5, and only one of those can hurt somebody. And once a threshold existed, teams tuned the detection rating downwards until the number fell under it.
Action Priority uses a lookup table over the three ratings, weighted so severity dominates. High means action is required or a justification recorded for not acting. It removes the arithmetic and therefore the arithmetic games.
The seven steps, in plain terms
- Planning and preparation. Decide what is in scope, who is in the room, and what the boundary of the system is. Most bad FMEAs fail here by being too broad.
- Structure analysis. Break the system into its parts and their relationships.
- Function analysis. State what each part is supposed to do, in verb-plus-noun form. If you cannot state the function you cannot state the failure.
- Failure analysis. For each function, the failure mode, its effect, and its cause. Keep them distinct: "sensor fails" is not a failure mode, "sensor output stuck high" is.
- Risk analysis. Rate severity, occurrence and detection, list existing prevention and detection controls, and read off Action Priority.
- Optimisation. Decide actions, assign owners and dates, then re-rate once the action is done and verified.
- Results documentation. Record what was decided and why, including the decision not to act.
Where an automation engineer actually contributes
Three places, and they are the ones the quality team usually cannot fill:
Detection controls. Most detection ratings in a process FMEA depend on what the control system checks. An interlock, a light curtain, a torque monitor, a vision check or a poka-yoke sensor is a detection control, and you are the person who knows whether it genuinely detects the failure mode or only detects that the machine ran.
Failure modes of the control system itself. A stuck sensor reading valid data, a drive that runs at the wrong speed because the parameter set was overwritten, a PLC output that stays energised after a card fault. These are your failure modes and they rarely appear unless an automation engineer puts them there.
Honesty about occurrence. Alarm and event history from the SCADA historian tells you how often something actually happened, which beats an opinion. See SCADA historian and trend data.
The trap
An FMEA whose actions are all "operator to be trained" and "add to inspection checklist" has not reduced risk. The hierarchy is: eliminate the failure mode by design, then prevent it happening, then detect it automatically, and only then rely on a person noticing. Automation sits in the middle two, which is why it is the most useful thing in the room.
The automotive FMEA AIAG-VDA course works through the seven steps and the Action Priority tables, and six sigma green belt covers the measurement and analysis side.
Frequently asked questions
Is FMEA only for automotive? The handbook is automotive, the method is not. Pharma, food, aerospace and general machine building all use it, sometimes under other names.
DFMEA or PFMEA? Design FMEA covers the product's design; Process FMEA covers how it is made. Automation engineers usually sit in the PFMEA and increasingly in a Machinery FMEA for the equipment itself.
How long does one take? A genuine PFMEA for a moderately complex line is days of team time, not hours. One done in an afternoon to satisfy an auditor is a document, not an analysis.
