Fault Detection and Diagnosis¶
Monitoring method — instantiates Fault-Tolerant Operation
Makes a local failure observable and names it — sensing that something is wrong and classifying which component failed and how, so the right continuation response can be chosen.
Fault Detection and Diagnosis is the sensing and classification front end of fault tolerance: it turns a silent failure into a named, located fault. Detection answers "is something wrong?"; diagnosis answers "what is wrong, where, and of which kind?" — mapping the observed symptoms onto a fault model so the system knows which continuation response applies. Its defining trait is that it produces knowledge, not action: it does not fence, reroute, correct, or repair. A monitor that identifies a failing bearing has changed nothing about the machine's operation — but every other fault-tolerance mechanism depends on it, because you cannot isolate, bypass, or degrade against a fault you cannot see or cannot name. It is necessary and, deliberately, insufficient on its own.
Example¶
A power utility runs a fleet of gas turbines, each spinning at thousands of RPM with blades under enormous thermal and mechanical load. On one unit, a set of accelerometers, thermocouples, and pressure taps feeds a condition-monitoring system that continuously watches for deviation from each turbine's healthy baseline. One afternoon the vibration signature on bearing three drifts: a rising component at a frequency the diagnostic model associates with bearing wear rather than, say, blade imbalance or combustion instability. The system does not merely raise a generic alarm — it classifies the fault ("bearing-three degradation, early stage, trending"), which is a categorically different call to action than "combustor fault" or "sensor glitch."
That diagnosis is the whole payoff. Operators now know which fault they have and can choose the matching response — schedule the bearing for the next maintenance window, or, if the trend accelerates, derate the unit before failure. The monitoring system itself never touches a valve or reroutes a load; it hands a named, located fault to the people and systems that will. Crucially, it also distinguishes a real fault from a failing sensor, because a bad thermocouple that reads hot is a different problem from a genuinely hot bearing.
How it works¶
- Instrument the healthy state. Sensors and telemetry capture the signals whose deviation would betray a fault — vibration, temperature, discrepancy checks, health probes, reconciliation results.
- Compare against a model of normal. Detection fires when observed signals depart from a baseline or a physical model by more than a set margin.
- Classify against a fault model. Diagnosis maps the symptom pattern onto which fault, distinguishing fault types from each other and from instrument error — this is the step that separates diagnosis from a bare alarm.
- Report a named fault. The output is a located, typed fault (with confidence, ideally), handed to whatever mechanism will act.
What this mechanism pointedly withholds is the response: it does not correct the signal, contain the component, or switch modes.
Tuning parameters¶
- Detection sensitivity — how large a deviation trips the alarm. High sensitivity catches faults early but raises false alarms; low sensitivity is quiet but misses or lags real faults.
- Detection latency — how fast a fault is flagged after onset. Low latency buys response time but often forces looser thresholds; high latency is surer but can flag the fault too late to matter.
- Diagnostic granularity — how finely faults are classified. Fine classes point to precise responses but demand a richer model and more data; coarse classes are robust but leave the response ambiguous.
- Sensor coverage / redundancy — how many independent signals feed the diagnosis. Broad coverage helps separate real faults from sensor faults but adds cost and its own failure surface.
- Confidence threshold — how sure the diagnosis must be before it is announced. A high bar suppresses false diagnoses but delays action; a low bar is responsive but noisier.
When it helps, and when it misleads¶
Its strength is that it is the eyes of every other mechanism: fast, well-aimed detection with a real diagnosis is what lets isolation fence the right element and degradation shed the right function. Nothing downstream can be better than the fault picture it is given.
Its two failure modes pull against each other, and both are dangerous. Tuned too sensitive, it drowns operators in false alarms until they stop trusting it — alarm fatigue, where a flood of low-value alerts trains people to ignore the one that matters.[n1] Tuned too coarse, it misses or misnames the fault, and a wrong diagnosis is worse than none because it steers the whole response astray — the archetype's warning that faults detected too late (or mislabeled) defeat the design. The related misuse is trusting a detector that has never been tested against the failure it claims to catch. The guarding discipline is to tune sensitivity to the real cost of misses versus false alarms, cross-check diagnoses against independent signals, and separate genuine faults from instrument faults before acting.
How it implements the components¶
fault_detection_signal— its core output: the signal that makes a local failure observable, from monitoring, health checks, discrepancy checks, or reconciliation.fault_model— the classification step is the fault model in use: the enumerated fault types the diagnosis maps symptoms onto.observability_instrumentation— the sensors and telemetry that expose the system's internal state to the detector.
It does not implement a fault_isolation_boundary or a compensation_or_bypass_path — it produces knowledge, not containment or a workaround. Acting on the named fault by fencing the element is Fault Isolation's job; reconstructing a corrupted value from redundancy is Error Correction's, its nearest twin. The one-line split from error correction: detection localizes and names which component failed, while error correction masks a corrupted symbol in place without ever diagnosing the source.
Related¶
- Instantiates: Fault-Tolerant Operation — detection and diagnosis is the sensing front end every continuation response depends on.
- Sibling mechanisms: Fault Isolation · Error Correction · Redundant Voting · Bypass Routing · Degraded Operation Mode · Manual Continuity Workaround · Self-Healing Repair Loop · Service Continuity Runbook
Editorial Notes¶
Form Classification¶
Form family: Monitoring, Sensing & Alerting
Rationale: Fault Detection and Diagnosis operates as an ongoing sensing arrangement that repeatedly observes actual state and surfaces changes or alerts because it makes a local failure observable and names it — sensing that something is wrong and classifying which component failed and how, so the right continuation response can be chosen.
Independent corroboration: The frozen evidence defines Fault Detection and Diagnosis as 'Makes a local failure observable and names it — sensing that something is wrong and classifying which component failed and how, so the right continuation response can be chosen', so its operative form is Monitoring, Sensing & Alerting.
Nearest alternative: Analysis, Modeling & Optimization — Fault classification computes a diagnostic result, but repeated telemetry observation and deviation detection make ongoing sensing primary.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Fault detection and diagnosis arose in reliability, control, and systems engineering as the discipline of sensing and localizing equipment failures.
Related originating lineages:
- Computer Science & Software Engineering — Computing independently developed software fault detection, health checks, and diagnostic observability.
- Robotics & Automation — Control and automation practice materially developed model-based and sensor-based fault diagnosis.
- Systems Thinking & Cybernetics — Cybernetic state estimation and feedback theory materially formalized model-based diagnosis.
Review resolution: Both reviewers agree that engineering_design is primary. I retain systems_cybernetics, computer_science, robotics_automation only as formative origin lineage(s), without treating every later application as an origin. convergent is appropriate because the same operational structure arose through materially independent professional lineages. Reach is multi_domain as a separate applicability judgment: it does not widen or narrow the recorded provenance. Encyclopedia synthesis is false because the artifact is already established enough that encyclopedia-specific synthesis is not required. The secondary differences are reconciled with no unresolved primary-provenance ambiguity.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Alarm fatigue — the well-documented pattern (studied extensively in clinical and control-room settings) in which operators exposed to frequent false or low-priority alarms become desensitized and begin to miss or ignore genuine ones. It is the concrete cost of over-tuned detection sensitivity, and the reason the sensitivity dial must be set against the real balance of missed-fault harm versus false-alarm harm. ↩