Every reliable system needs a disciplined answer to one question: when does “unusual” become “fault”?
A vibration rises. A voltage shifts. A queue lengthens. A learner begins making a familiar error again. A payment service produces more timeouts than usual. None of these observations proves failure on its own. Systems vary, sensors are noisy and the environment moves.
Fault detection is the mechanism that decides whether observed behaviour has departed far enough from an expected model, threshold or pattern that the system should treat the condition as potentially faulty.
This is a narrower branch beneath How Failure Works and How Failure Mapping Works. The broader owners explain how function is lost and how damage propagates. Fault detection focuses on the first decision gate: has the system seen enough evidence to declare that normal explanation is no longer sufficient?
Normal Variation Is Not Failure
Good detection begins with a model of normal behaviour.
That model may be a fixed tolerance, a physics-based prediction, a statistical envelope, a learned baseline or a rule tied to operating state. The important point is that the detector compares observation against expectation.
If a bearing normally vibrates more at high speed than low speed, one universal vibration threshold may create false alarms. If website traffic triples every Monday morning, “high load” is not automatically abnormal. Context defines the expected range.
Residuals: The Difference Between Expected and Observed
A common detection idea is the residual: predicted output minus measured output, or expected behaviour minus actual behaviour.
Small residuals can be explained by noise and modelling error. A persistent or structured residual suggests the model no longer explains the system well.
Residuals are useful because they move detection away from raw measurements. A temperature of 60°C may be normal in one operating state and dangerous in another. The residual asks whether 60°C is consistent with what should be happening now.
Thresholds Turn Evidence Into Action
At some point the detector needs a decision rule.
- single threshold: alarm when a value exceeds a defined bound;
- persistence rule: alarm only if the deviation lasts long enough;
- rate-of-change rule: detect a fast shift before the absolute value becomes extreme;
- multi-signal rule: require several related signals to disagree together;
- probabilistic rule: alarm when the likelihood of normal behaviour becomes sufficiently low.
The threshold should reflect consequence, not convenience. A false fire alarm and a missed fire have different costs. A detector guarding safety-critical braking deserves a different error budget from one monitoring a non-essential office printer.
The wider logic of thresholds remains with How Thresholds Work.
False Positive vs Missed Detection
Fault detection has two fundamental error modes.
- False positive: declare fault when the system is actually healthy.
- False negative: miss a fault that is genuinely present.
Lowering the alarm threshold often catches faults earlier but increases false positives. Raising it reduces nuisance alarms but can delay or miss genuine failure.
Detection design is therefore a risk trade-off. The receiver determines which error is more expensive.
Detection Should Follow Operating State
A signal can be normal in one state and abnormal in another.
High motor current during acceleration may be expected. The same current while stationary may indicate a jam. Longer processing time during peak load may be normal. The same delay at low load may reveal a degraded dependency.
This is why fault detection often depends on state awareness, setpoint, load, environment and recent history rather than one isolated number.
See How State Machines Work and How Observability Works.
One Sensor Is Rarely the Whole Story
Strong detection often uses redundancy of evidence.
A pump fault may appear as changed vibration, current, pressure and flow. A database problem may appear as latency, error rate and queue depth. A railway problem may appear in current draw, wheel slip, speed response and diagnostic logs.
When several independent signals support the same abnormal explanation, confidence rises. When one sensor alone disagrees with everything else, the sensor itself may be faulty.
Trend Detection Finds Failure Before a Limit Is Crossed
Some faults develop gradually.
Bearing vibration increases over weeks. insulation resistance falls. a queue grows slowly. model accuracy drifts. a learner’s retrieval becomes less stable.
Trend detection looks for persistent movement toward a failure boundary rather than waiting for the final threshold breach.
This is the bridge from fault detection into predictive maintenance. The existing MRT branch, How MRT Predictive Maintenance Works Using Mathematics, shows the applied infrastructure version.
Worked Example: Railway Equipment
Suppose a traction motor normally produces a known vibration spectrum at a given speed and load. A new frequency component appears and grows across repeated journeys.
The detector should not merely say “vibration high.” It should compare the observed spectrum with operating-state expectations, sensor health and historical trend. If the residual is persistent and consistent with a plausible fault mechanism, the system can escalate from detection to isolation.
Worked Example: Digital Service
A payment service begins returning more timeouts.
Raw timeout count is not enough. Traffic volume may also have increased. The detector may examine timeout rate, latency distribution, queue depth and dependency health against the normal profile for that load.
If the anomaly survives those adjustments, the event becomes a credible fault candidate rather than ordinary peak variation.
A Careful Analogy: Learning
A teacher also needs to distinguish one unusual mistake from evidence of a stable learning fault.
One wrong answer may be fatigue, misreading or chance. Repeated errors with the same structure across varied questions suggest a more stable misconception or prerequisite gap.
The analogy is bounded: human learning is not industrial fault logic. Its value is in the evidence discipline — do not diagnose a learner from one noisy observation.
A Careful Analogy: Institutions
An institution can also remain superficially functional while early failure signals accumulate: rising exception rates, staff workarounds, complaint clustering, maintenance backlog or growing discrepancy between formal and actual process.
Institutional fault detection asks whether these signals exceed ordinary variation and deserve investigation before visible service collapse.
A Fault-Detection Sequence
- Define normal behaviour across relevant operating states.
- Choose measurements that reveal meaningful deviation.
- Model expected noise and variation.
- Calculate residuals or anomaly scores.
- Use thresholds, persistence and corroborating signals.
- Estimate false-alarm and missed-detection cost.
- Declare fault candidate only when evidence crosses the agreed rule.
- Preserve the evidence for isolation and diagnosis.
The CivDJ Rotation
- Forward: system behaviour → measurement → residual → threshold → fault declaration.
- Backward: start from a confirmed failure and ask which earlier signals should have become detectable first.
- Rotate: compare operator, maintainer, safety owner, customer and finance views of false alarms versus missed failure.
The Civilisation Lesson
Reliable civilisation depends on finding small wrongness before it becomes large failure. Inspection, audit, diagnostics, alarms and early-warning systems all perform versions of this job.
The mature system does not alarm at every deviation and does not wait for catastrophe. It builds a defensible boundary between ordinary variation and evidence that the mechanism has changed.
Fault detection is the moment a system stops saying “this is probably noise” and starts saying “something real may have changed; investigate now.”
Continue through How Failure Mapping Works, How Repair Routing Works and the master How X Works hub. The next question is fault isolation: once a fault is credible, where exactly is it?