Machine Design #40: Mechanism FMEA — From Failure Mode to Design Action

Machine Design #40: FMEA for a Machine Mechanism — From Failure Mode to Design Action

Many teams open an FMEA only when the design is nearly finished and the customer asks for the document. Everyone meets, fills in a long table, scores a few numbers and files it. The drawings, the logic and the test plan barely change.

That is an FMEA "completed" on paper, and it has not necessarily made the machine any better.

The real value of an FMEA lies in the chain:

Function → failure mode → effect → cause → control → design action → verification

If the analysis does not lead to a design decision or to new evidence, the table becomes decoration. This article takes a practical route through an FMEA for a machine mechanism, from function to an action that can be verified.

An FMEA does not replace machinery risk assessment. Where a failure mode creates or changes a hazard, the design team still has to run the appropriate risk assessment and risk reduction process, for example to ISO 12100.

1. Start before the design is frozen

The right moment to open an FMEA is not after the drawings are released. Start once the team understands enough:

What the mechanism has to do.
What the main inputs and outputs are.
Where the important interfaces sit.
Which design options can still be changed.

Too early, and the team lacks data and writes generic failure modes. Too late, and even a good action becomes expensive or impossible to fit into the schedule.

A workable rhythm:

Open the FMEA when the concept is settled.
Update it when the actuator, the sensors and the guide structure are chosen.
Review it before the drawings are released.
Check it against reality during assembly and trial running.
Update it from FAT and SAT findings and from field data.

An FMEA is a living record of engineering decisions, not a photograph taken at one moment.

2. Choose scope by function, not by parts list

A scope as wide as "an FMEA for the whole machine" usually costs the meeting its focus. A scope as narrow as "an FMEA for sensor 3" misses the failures that live at interfaces.

Choose a functional assembly with a clear boundary:

What input does it receive?
What output does it produce?
Which assemblies does it exchange energy, material or signals with?
Where do the operator and the maintenance technician interact with it?
When it fails, how is the level above affected?

An example scope:

The infeed workpiece stop assembly, from receiving the stop request to confirming the workpiece is in a position that allows the next station to operate.

That scope covers the mechanics, the drive, the sensor, the control logic and the interface to the workpiece. It is more useful than a loose list of cylinder, valve, bracket and proximity switch.

3. Write the function before searching for failure

A failure mode is a way in which an element does not deliver its function. If the function is vague, the failure mode will be vague too.

A weak function:

Stop the workpiece.

A better function:

Raise the stop to hold the workpiece at a defined position, for the required time, under the specified load conditions.

A good function usually carries:

A verb: raise, hold, guide, detect, transmit, limit.
An object: the workpiece, the slide, a signal, energy.
A condition: mode, load, speed, environment or the relevant state.
A criterion: position, time, repeatability, force or the reliability required.

Not every line has to become a long specification. But the function has to be clear enough for the team to answer one question: "What does failure mean here?"

4. Separate failure mode, effect, and cause

Three ideas that are often written as one:

Failure mode: the way the function is not delivered correctly.
Effect: what happens locally, at system level, or to the user.
Cause or mechanism: the reason or the physical mechanism that produces the failure mode.

For example:

Element	Content
Function	Raise the stop to hold the workpiece in position
Failure mode	Does not reach the raised position after the command
Local effect	The mechanism stays down or somewhere mid-stroke
Next-level effect	The workpiece is not located; the next station has no permissive
End effect	The cycle stops; a collision is possible if other logic does not detect the state
Cause	Loss of energy, a jammed guide, wrong tolerance, wear, a shifted sensor, a loose connector or a wrong parameter

"Loss of air" is not a failure mode of the raising function; it is a potential cause. "The machine stopped" is usually an effect, not a cause. Separating them correctly is what sends the action to the right place.

5. Review effects at several levels

Writing only "the machine stopped" loses the information about how the failure propagated.

Look at three levels at least.

Local effect

What happens at the element or assembly being analysed.

For example: the stop does not rise fully; the mechanism drifts; the position signal does not change.

Next-higher-level effect

The effect on the adjacent assembly or function.

For example: the workpiece is not secured; the robot receives no permissive; the following operation times out.

End effect

The final effect on the user, the product, the machine or the operating target.

For example: a line stop, a product in the wrong position, equipment damage, or a hazard that has to be handled in the risk assessment.

The chain of effects is what lets the team see which failures only cost output, and which ones reach quality or safety.

6. Look for failures at interfaces

Many field faults do not sit entirely inside one component. They sit at the boundary between parts:

Actuator and load.
Workpiece and locating face.
Sensor and target.
Cable and connector.
PLC command and feedback.
Recipe and mechanical configuration.
Operator and HMI.
A wear part and the datum it is replaced against.

One way to review is to follow the flows across the boundary:

Flow	Question
Energy	What happens on too little, too much, an interruption, or residual energy?
Material / workpiece	What about the wrong model, wrong orientation, a jam, deformation, or no workpiece at all?
Motion	What about no movement, slow movement, over-travel, drift, or vibration?
Signal	What about a lost, wrong, delayed, intermittent or implausible signal?
Data	What about a wrong recipe, an old parameter, or a model mismatch?
People	What about wrong assembly, a wrong replacement, poor visibility, or poor access?

An interface review usually finds failure modes that a BOM review walks straight past.

7. Prevention control is different from detection control

The two kinds of control have different purposes.

Prevention control

Makes the cause less likely to occur.

For example:

Geometry that cannot be assembled the wrong way round.
A guide stiff enough, and restrained against rotation.
Standardised change parts.
A connector with a suitable lock.
Control of tolerance and material.
Wear parts designed so the replacement lands in the right position.

Detection control

Detects the failure mode or the cause before it becomes an end effect.

For example:

Confirming that two motion states are plausible together.
Checking for a model or recipe mismatch.
Measuring the characteristic during validation.
Checking for assembly errors before automatic running.
Alarms that keep the first-out condition and the diagnostic context.

Good detection does not make the failure disappear. Where the effect is severe, the first priority is still to remove the hazard, reduce the consequence, or reduce the likelihood by design — not to add one more sensor and declare the risk handled.

8. Do not let a total score hide a critical failure

A single combined number looks like a fast way to rank, but it can also create an illusion of precision.

Common problems:

Two different failures score the same while their consequences are nothing alike.
The occurrence score reflects a feeling, because there is no data yet.
Detection is scored well simply because "there is a sensor".
The team uses a total threshold to skip a severe effect.
After the action, the score is lowered before the evidence exists.

If the organisation applies a specific ranking method, use the approved handbook or procedure as written. Do not invent a scoring table and then call it AIAG/VDA or IEC.

More important than the score is the quality of the reasoning chain:

Is the function clear?
Is the failure mode written at the right level?
Does the effect run through to the end effect?
Is the cause specific enough to generate an action?
Does the current control have evidence behind it?
Does the action actually change the design?

9. An action must change design or evidence

Weak actions:

"Check again."
"Be careful during assembly."
"Monitor it."
"Periodic maintenance."

None of these states who does it, what is done, when it is complete, or what result proves it worked.

Better actions usually fall into one of three groups.

Change the design

Change the guide structure or the hard stop.
Reduce an unfavourable load on the actuator.
Remove the possibility of reversed assembly through geometry.
Separate the wear part from the primary locating datum.
Improve visibility and maintenance access.

Change the control

Add a plausibility check between command and feedback.
Keep the first-out alarm for diagnosis.
Prevent a mismatch between the model and the change part.
Derive the timeout from test data instead of a guess.

Create evidence

Test repeatability at the boundary conditions.
Measure the motion time across the permitted load and pressure range.
Attempt a deliberate wrong assembly during validation.
Test that the wear part can be replaced and the datum recovered.

Each action should carry:

An owner.
A due date.
A specific deliverable or change.
The way it will be verified.
The result and the evidence.
A re-assessment once it is complete.

An action that has not been verified is still an open action.

10. Example: FMEA for a workpiece stop assembly

Assume the assembly has this function:

Raise the stop to locate the workpiece before the next operation, under the required load and time conditions.

Part of the analysis could read as follows.

Failure mode 1: does not reach the raised position

Local effect: the stop stays down or mid-stroke.
Next-level effect: the workpiece is not located.
End effect: the cycle stops; the next operation may receive an invalid state if the confirming logic is not sufficient.
Causes to review: insufficient supply energy, a jammed guide, wrong assembly, increased friction, an output that does not operate.
Prevention: review the guide, the side load, the tolerances, the anti-rotation feature and the assemblability.
Detection: confirm the state after the command, use a timeout derived from testing, capture a context snapshot.
Example action: test the stroke at the boundary load conditions and change the guide design if the criterion is not met.

Failure mode 2: reaches the position, then drifts

Local effect: the stop leaves its holding position.
Next-level effect: the workpiece moves during the operation.
End effect: a quality defect, a jam or a collision.
Causes to review: loss of energy, leakage, a load above the assumption, a mechanism that lowers itself, or no mechanical holding.
Action: define the loss-of-energy state from the risk assessment; change the concept if that failure state is not acceptable.

Failure mode 3: feedback says "reached" while the real position is wrong

Local effect: the logic state does not reflect the mechanics.
Next-level effect: a permissive is issued wrongly.
End effect: the cycle continues with an unlocated workpiece.
Causes to review: a loose sensor target, a shifted sensor, a deformed sensor bracket, wrong wiring or logic, a detection zone that is too wide.
Prevention: design the target and the sensor bracket against movement, with adjustment that stays under control.
Detection: plausibility checks, deliberate misalignment during validation, and a physical check at trial running and commissioning.

Failure mode 4: the mechanism works, but the time keeps growing

Local effect: the stroke slows and approaches the timeout.
Next-level effect: an unstable cycle and repeated alarms.
End effect: lost output and stoppages that are hard to reproduce.
Causes to review: wear, contamination, friction, a degrading energy supply, incorrect maintenance.
Action: define the characteristic to be monitored and its check limits; design the maintenance points to be accessible.

The example needs no assumed dimension, pressure or priority number. Its purpose is to show how a failure leads to a design action and to validation.

11. Link the FMEA to other deliverables

An FMEA is only strong when it is not isolated in a spreadsheet.

Finding from the FMEA	Deliverable to update
Function or requirement not clear	Requirement or specification
Failure caused by tolerance or interface	Drawing, tolerance stack or design review
Failure needing poka-yoke	Mechanical design, change part or work instruction
Failure needing diagnosis	Alarm list, HMI and diagnostic design
Failure caused by wear	Maintenance plan and spare or wear-part list
Failure needing evidence	DVP, FAT/SAT or validation protocol
Failure related to a hazard	Machinery risk assessment and safety validation
Failure introduced by a change	Change management and revision history

Every action should point to the place where the change is really controlled. If the FMEA says "add a check" but the test protocol does not change, the loop is not closed.

12. When must the FMEA be updated?

Not only on a schedule. There have to be clear triggers:

The concept or the mechanism architecture changes.
The actuator, sensor, material or supplier changes.
A model or a recipe is added.
Speed, load or environment changes.
Logic, timeouts or alarms are modified.
A wear part or a maintenance datum changes.
A fault appears during FAT or SAT.
There is a field failure, a near miss or a quality complaint.
An earlier action is completed and new evidence exists.

Each trigger has to answer:

Which function is affected?
Which failure mode, cause or control changes?
Does a new interface appear?
Does the risk assessment or the validation need updating?

Do not simply change the revision date. Write down the reason and the scope of the change.

13. Design-review checklist for a mechanism FMEA

Is the scope and the boundary defined?
Have the energy, material, signal, data and human interfaces been reviewed?
Does the function carry a verb, an object, a condition and a suitable criterion?
Is the failure mode separated from the effect and the cause?
Are local, next-level and end effects all present?
Are prevention and detection controls distinguished?
Does the current control have evidence, or is it an assumption?
Is a severe failure hidden behind a total score?
Does each action have an owner, a due date, a deliverable and a verification?
Do closed actions have their evidence attached?
Have the drawing, logic, alarms, maintenance and test protocol been updated accordingly?
Have hazard-related failures been passed to the risk assessment?
Have change points and field lessons been fed back into the FMEA?

Conclusion

A good FMEA is not measured by the number of rows in the table. It is measured by the quality of the decisions it produces.

Start from the function, keep failure mode, effect and cause separate, look for faults at the interfaces, separate prevention from detection, and require every action to be verified. Done that way, the FMEA becomes the bridge between what the engineering team knows and what appears in the drawings, the logic, the alarms, the maintenance plan and the test schedule.

If an important failure mode still ends with the phrase "check it again", the work is not finished. The next question has to be:

What will change in the design, and what evidence proves that the change is effective?

Public references

IEC 60812:2018 — Failure modes and effects analysis (FMEA and FMECA): https://webstore.iec.ch/en/publication/26359
ISO 12100:2010 — Safety of machinery — Risk assessment and risk reduction: https://www.iso.org/standard/51528.html
AIAG & VDA FMEA Handbook: https://www.aiag.org/training-and-resources/manuals/details/FMEAAV-1

View all MINATA technical articles