Machine Design #48: Root Cause Analysis — From “Sensor Failed” to Evidence of Cause

An alarm says “sensor error.” The team replaces the sensor, restarts the machine, and records “root cause: sensor failure.” The line runs again, but the same stop returns two weeks later.

The alarm may have described a symptom. The real cause could be a loose bracket, cable fatigue, contamination, unstable power, an incorrect threshold, a sequence race, an upstream condition, or a design that provides no robust diagnostic.

Root cause analysis is not a story that sounds convincing. It is a controlled investigation:

Preserve evidence → define the problem → build a timeline → form hypotheses → test safely → control and correct → verify effectiveness → feed learning back into design.

1. Do not mix symptom, failure mode, and cause

The symptom is what the operator observes: a stop, alarm, reject, timeout, or missing signal. The failure mode is how a function failed: signal absent, signal false, component open, communication lost, or mechanism out of position. The cause is the physical, electrical, software, human, environmental, or systemic condition that produced the failure.

“Sensor error” may be a diagnostic label. It is not automatically a failure mode or cause.

2. Recover first, but preserve evidence

Safety and production recovery come first. Before replacing, resetting, or cleaning, capture the machine state, alarm history, timestamps, recipe, counters, I/O, parameters, photos, environmental conditions, and removed parts where practical.

If a temporary action is necessary, record exactly what changed and who did it. Do not erase the only evidence in the name of speed.

3. Write a problem statement narrow enough to investigate

Include asset, function, time window, operating condition, observed behavior, expected behavior, frequency, impact, and boundaries. Avoid conclusions such as “bad sensor” in the problem statement.

Example:

Station 2 reports an intermittent clamp-closed timeout during model B, primarily after warm restart, between 09:00 and 11:00 on 1 August; the input sometimes changes without mechanical movement.

A narrow statement makes evidence and hypotheses testable.

4. A timeline must include time confidence

Align PLC events, HMI alarms, robot logs, drive history, maintenance notes, camera images, operator reports, and production records. Record whether each time is controller time, server time, human recollection, or an estimate. Note clock offsets and missing periods.

A timeline is stronger when it distinguishes observed sequence from interpretation. Do not place a guessed cause into the event chronology as if it were fact.

5. Evidence is not interpretation

Evidence is a raw value, waveform, log, photo, physical measurement, part condition, program revision, or repeatable observation. Interpretation is the meaning assigned to it. Keep both, but label them separately.

“The sensor was dirty” is an interpretation until contamination is documented, the sensing surface and signal are measured, and the mechanism is linked to the observed failure.

6. Create several hypotheses before choosing one

Consider sensor, mounting, target, cable, connector, power, I/O, software, timing, environment, operator interaction, upstream/downstream, and common-cause conditions. Rank hypotheses by evidence, consequence, testability, and prior knowledge, but do not discard a less familiar cause only because a replacement part is available.

7. Five Whys is a question sequence, not evidence

Five Whys can expose assumptions, but each answer needs support. “Why did the machine stop? Because the sensor failed. Why? Because it was old.” This is not proof. Add measurements, history, design requirements, failure analysis, and a test that could disprove the hypothesis.

8. Do not stop at “operator error”

If an operator selected the wrong recipe or skipped a check, ask whether the interface, role, prompt, training, access control, workflow, or recovery design made the error likely. Human action may be part of the event, but a robust RCA looks for system conditions that allowed it.

9. Test hypotheses without creating more risk

Use a controlled spare, simulator, isolated test, temporary instrument, A/B comparison, environmental challenge, or staged observation. Define precondition, variable, expected result, safety control, rollback, and evidence. Never defeat a safety function or create an unsafe production experiment to make a hypothesis fit.

10. Containment, correction, corrective action, and systemic action

Containment

Protect current production, people, or customers while the investigation continues.

Correction

Fix the observed nonconformance, such as replacing a broken part or clearing contamination.

Corrective action

Remove the verified cause so the same failure is less likely to recur.

Preventive or systemic action

Improve a broader process, standard, requirement, training, supplier control, or architecture when the learning applies beyond one asset.

Do not call a replacement alone a corrective action if the verified cause was poor mounting or a missing diagnostic.

11. Verification differs from effectiveness review

Verification asks whether the action was implemented as planned. Effectiveness asks whether the failure mechanism was reduced in real operation over an agreed sample or time. A new bracket can be installed correctly and still fail if the actual cause was electrical noise.

Define the success metric, observation window, conditions, and owner before closing the action.

12. Feed learning back into the lifecycle

Update requirement, drawing, risk assessment, software diagnostic, maintenance task, spare identity, supplier specification, inspection, training, FMEA, and configuration baseline where the evidence warrants it. A lesson in an RCA document that never changes the system is not a closed learning loop.

13. Hypothetical example: intermittent sensor signal

Focus event

A clamp-closed signal drops during model B after a warm restart. The alarm says sensor timeout.

Initial evidence

The event log shows a 220 ms gap. A photo shows a bracket mark. The sensor output is stable on the bench. The cable has a tight bend near the connector.

Hypotheses

Loose bracket, cable fatigue, thermal expansion, threshold setting, I/O noise, target misalignment, or a sequence race.

Test and assumed result

Measure vibration and gap, flex the cable under controlled conditions, compare cold and warm states, review input filtering, and run a controlled trace. Suppose the signal drops only while the cable flexes at the bend. The cause is now supported by repeatable evidence; replace the cable route, add strain relief, verify the input and sequence, and review similar assets.

14. Automation RCA checklist

[ ] Safety and production recovery were controlled.
[ ] Evidence was captured before it was changed where practical.
[ ] Problem statement separates symptom from conclusion.
[ ] Timeline records source and confidence of time.
[ ] Evidence and interpretation are labeled separately.
[ ] Multiple hypotheses were considered.
[ ] Tests have conditions, controls, expected results, and rollback.
[ ] Five Whys answers have supporting evidence.
[ ] Human action was examined as a system condition, not a convenient endpoint.
[ ] Containment, correction, corrective, and systemic actions are distinct.
[ ] Verification and effectiveness review have owners and windows.
[ ] Learning was fed into design, maintenance, configuration, and training.

Conclusion

“Sensor failed” may be a useful first observation, but it is rarely a complete cause. Strong RCA protects evidence, narrows the problem, tests competing explanations safely, separates immediate recovery from permanent action, and measures whether the change worked in the real machine.

The value of RCA is not a polished report. It is a machine, design system, and team that become less likely to repeat the same failure.

References

ISO 9001:2015 — Quality management systems: https://www.iso.org/standard/62085.html
IEC 60812:2018 — Failure modes and effects analysis: https://webstore.iec.ch/en/publication/60435

View all MINATA technical articles