AMDEC (Analyse des Modes de Défaillance, de leurs Effets et de leur Criticité), the French acronym for FMEA, is a method for analysing the dependability of a system: for each function or component, the possible failure modes are listed, their severity, occurrence and detectability are rated, and from those a criticality is derived that ranks the corrective actions. It is the tool for analysing product risk on a mechatronics project, used at concept to steer the safety measures and refined in the technical design file on the real components.
What is it for?
AMDEC is there to anticipate the failures of a system before they happen, rather than discover them at integration or, worse, in use. Where instinct deals with breakdowns one at a time, AMDEC lists them methodically and ranks them: not all failures are equal, and prevention effort should go first to where the risk is most critical.
Three roles:
- Listing the failure modes without missing any. Going through function by function (or component by component) brings up failures that a spontaneous review misses, especially the ones that are severe but rare, and therefore easy to overlook.
- Ranking by criticality. Rating on severity × occurrence × detectability sorts the modes against each other. A failure that is severe, frequent and undetectable takes the effort. A failure that is minor, rare and visible can be accepted.
- Steering the safeguards and the tests. The most critical modes become the safeguards to build into the architecture (at concept) and the points to check first during qualification testing (at integration and testing).
Watch out
AMDEC ≠ risk matrix. Both rate risks, but not on the same object and not on the same axes. The risk matrix rates project hazards (a component out of stock, a printer breakdown, a teammate away) on two axes (likelihood × severity) and is run from project planning and tracking. AMDEC rates the failure modes of the product (a bearing that seizes, a sensor that drifts, an emergency stop that fails to cut) on three axes (severity × occurrence × detectability) and belongs to dependability. One protects how the project runs, the other the reliability and safety of the delivered system.
Step by step
AMDEC runs in four stages: choose the level of analysis, identify the failure modes, rate the criticality, then decide and record the actions.
1. Choose the level and list what is to be analysed
Decide first on the grain of the analysis: an AMDEC is run either functionally (on the technical functions coming out of the breakdown or the FAST) or materially (on the physical components). On a school project the functional AMDEC is run early (at concept, before the components are chosen), and the material one later (in the technical design file, on the parts actually selected).
Then list what is to be reviewed. Do not aim to cover the whole system: focus on the critical functions, the ones whose failure affects the safety of the user or a requirement at F0 or F1 flexibility in the CdCF, the French functional requirements specification. F0 means mandatory and F1 barely negotiable, the two levels that leave the least room to negotiate.
2. Identify modes, effects and causes
For each item, answer three distinct questions that are not to be mixed up:
- Failure mode — how can the item fail? (a motor that no longer turns, that turns too much, that jams; a sensor that drifts, that saturates, that disconnects). One item often has several modes.
- Effect — what consequence for the system and for the user? The effect is what carries the severity (an effect like “loss of accuracy” does not carry the same severity as an effect like “a crushed finger”).
- Cause — why does this mode happen? The cause is what carries the occurrence and what points to the safeguard (you act on the cause, not on the effect).
3. Rate the criticality, G × O × D
Give each mode three ratings on a scale set in advance, typically 1 to 4 on a school project (a 1–10 scale exists in industry, but 1–4 is enough and discriminates better at this size). The letters are the French ones, and they are the ones the team will say out loud: G for gravité, severity, O for occurrence and D for détectabilité. The FMEA literature writes the same product as S × O × D and calls it the risk priority number.
| Rating | G — severity of the effect | O — occurrence (frequency) | D — non-detectability |
|---|---|---|---|
| 1 | minor, no consequence | very rare | certain to be caught before the effect |
| 2 | degraded service | occasional | often caught |
| 3 | loss of function | frequent | rarely caught |
| 4 | danger to the user | almost systematic | not detectable before the effect |
The criticality is the product C = G × O × D (from 1 to 64). It sorts the modes against each other. Watch the direction of the D axis: what is rated is non-detectability, because a severe mode that cannot be detected is more critical than a severe mode you see coming and can stop in time.
Tip
Any mode at G = 4 deserves an action, whatever its criticality. A danger to the user is not traded against a low occurrence: even rare and detectable (low C), a mode that can injure calls for a safeguard. Criticality ranks the ordinary modes. Maximum severity short-circuits the calculation.
4. Decide and record the actions
For the modes above the criticality threshold the team sets itself (and for every G = 4), define an action: act on the cause (lower the occurrence), strengthen detection (lower D), or reduce the effect (lower G). Each action names an owner and a deadline, then the residual criticality is rated again to check that the action really did bring the risk down. An AMDEC table that computes criticalities without leading to a single action has served no purpose.
Example — 3-axis teaching arm
A partial functional AMDEC of the 3-axis arm, focused on the functions that are critical for safety, consistent with the user risks identified in the safety and quality framework page (pinching, motor torque, stored energy). Scale 1–4, criticality C = G × O × D.
| Function / component | Failure mode | Effect | Likely cause | G | O | D | C | Action |
|---|---|---|---|---|---|---|---|---|
| Emergency stop | Fails to cut the power | No way to stop a dangerous movement | Cut driven by the firmware (can crash) | 4 | 2 | 3 | 24 | Wire the e-stop to cut the supply directly, outside the software |
| Joint (travel limit) | Maximum angle exceeded | Operator pinched, mechanical breakage | Software limit alone, not backed up | 4 | 2 | 2 | 16 | Add a mechanical stop (limit switch) |
| Axis 1 stepper | Step loss under load | Wrong position, accuracy outside F0 | Not enough torque under acceleration | 2 | 3 | 3 | 18 | Torque margin plus deviation detection through an encoder |
| 24 V supply | Overheating in continuous service | Nuisance cut-out, arm stops | Current margin too tight (+8%) | 2 | 2 | 2 | 8 | Thermal monitoring, otherwise acceptable as it stands |
Reading it. The two modes at G = 4 (emergency stop, travel limit) call for an action whatever their criticality. These are the safety measures that will go into the architecture at concept (an e-stop wired outside the firmware, a mechanical stop backing up the software limit), consistent with the safety and quality framework page. Step loss (C = 18) meets the torque under acceleration unknown already identified at concept. AMDEC and rough sizing converge. Supply overheating (C = 8) stays below the threshold for priority action, monitored but not blocking.
Pitfalls
Mixing up AMDEC and the risk matrix. AMDEC analyses the failures of the product, the risk matrix the hazards of the project. Putting both in a single table produces a document that sheds light neither on the reliability of the system nor on the running of the project.
Wanting an exhaustive AMDEC. Sifting the whole system drowns the analysis under dozens of trivial modes. AMDEC earns its value on the critical functions (safety, requirements at F0 and F1). The rest is dealt with in one line, or not at all.
Rating without a scale set in advance. Ratings given by feel, with no shared G/O/D grid, are not comparable between modes or between members of the team. The scale is fixed before rating, not during.
Forgetting the detectability axis. Many school AMDECs come down to severity × occurrence and miss the factor that discriminates most in safety: a severe mode that is undetectable is far more dangerous than a severe mode you see coming. Detection is often the cheapest lever to act on.
Computing criticality without acting. An AMDEC that produces numbers but no corrective action is a dead exercise. The Action column, with its owner and its residual criticality, is the whole point of the method.
An AMDEC frozen after the first draft. Modes and their ratings change with the project: the proof of concept confirms or disproves occurrences, and integration reveals modes nobody anticipated. An AMDEC is reread at every phase review, like the risk matrix.
Special case — a scaled-down AMDEC on a school project
A full AMDEC (every function, three axes, residual criticality) can be out of proportion for a one-semester project. The scaled-down teaching variant, mentioned in the safety and quality framework page, keeps what matters while trimming the scope:
- stick to the safety-critical functions (3 to 6 lines, not the full inventory);
- rate on two axes (severity × occurrence) if the team is not comfortable with detectability, at the cost of losing the finest factor;
- aim for the decision (which safeguards to build in) rather than the completeness of the table.
Trimming is legitimate as long as it keeps the underlying discipline — list the modes, rate them on a shared scale, end up with actions. A well-run 4-line AMDEC is worth more than a 40-line table nobody ever rereads.
Where it fits in the project
- The decision step of the concept phase — the functional AMDEC steers the safety measures to build into the architecture (emergency stop, travel limits, insulation), at the point where the architecture pins down the moving parts and the energy levels.
- Technical design file — the AMDEC is refined on the real components selected (material AMDEC), consistent with the BOM and the detailed drawings.
- Integration and testing — criticality ranks the safety tests of qualification level 4: what the AMDEC flagged as critical is tested first.
- The safety and quality framework page — AMDEC is the product-risk analysis tool of the product safety block. The framework page carries how it fits into the cycle, this page carries the method.
An AMDEC run early on the critical functions saves you from discovering a dangerous failure mode at integration, when the architecture is frozen and reworking it is expensive.
See also
- Safety and quality — the cross-cutting thread that fits AMDEC into the project cycle (product safety block)
- Risk matrix — the cousin tool not to be confused with it: project risk (P × G) against product failure (G × O × D)
- Functional breakdown — the source of the technical functions a functional AMDEC reviews
- Integration and testing — the downstream phase where criticality prioritises the safety tests
- Concept — the phase where the functional AMDEC steers the architecture safeguards