Why
The motivating slide for every fault-detection project says the same thing, and it says more than it means to. Unplanned downtime costs multiples of planned maintenance; the failure modes underneath it are safety, quality and throughput. That is a correct and well-known argument. What is usually missed is that it has already specified the model — a statement that missing a failure costs ten to a hundred times more than an unnecessary inspection is a statement about where the alert threshold goes, and it was available before anyone touched the data.
The part the slide does not say is that the saving is a function of time, not of correctness. Three different problems share the name: detection asks whether behaviour is abnormal now, diagnosis asks what is abnormal, and prognosis asks when it will fail. The economics quoted are prognosis economics, and they only pay out if the warning arrives with enough room to act. A model that flags a bearing two hours before seizure, in a plant where the spare takes three days, has converted an unplanned stop into a slightly better-documented unplanned stop. The lead time has to exceed the time to repair, and the time to repair is an organisational fact that can be measured this week without a single model.
That reframing changes what the first deliverable is. Not accuracy on a held-out set, but a horizon: given how long a repair actually takes, how much warning is required before an alert is worth acting on. Every modelling decision downstream — the label horizon, the feature window, the sampling rate — is set by that number. Projects that skip it end up optimising a metric that is real and a product that is not, and the failure is invisible in every plot they produce.
Then the data problem, which is the opposite of what people expect. The machines whose downtime is expensive are the machines that rarely fail — that is the same sentence said twice. So labelled failures are scarce, often a few dozen across years, and frequently not labelled at all: a maintenance log records that a bearing was replaced, not that degradation began eleven days earlier. Supervised classification on that is not a hard problem, it is an under-specified one. The workable route is to model normal behaviour and score deviation from it, which trades a labelling problem for a different and more honest one — an anomaly is not a failure. Most deviations in real plant data are sensor faults, maintenance actions, product changeovers and ambient shifts. The base rate of "anomaly that turns out to be an impending failure" is the number that decides whether an alarm is worth anything, and it is almost never measured.
Finally, this domain triggers every leak in the-split-is-the-experiment at once, plus one of its own. Sensor data is ordered in time, grouped by machine, and labelled by a forward window — so a random split lets the future predict the past, a time-only split lets the model memorise machine identity and then fail on a new installation, and a forward-horizon label overlaps the validation period even after a clean date cut. The extra one is specific to this literature: run-to-failure datasets are pre-truncated, ending at the failure they document, so remaining useful life is partly inferable from position in the file. A model can learn that the recording is ending rather than that the bearing is degrading, and it will score beautifully right up until it meets a machine that is still running.
How it works
Three problems wearing one name
| The question | The output | What it is worth | |
|---|---|---|---|
| Detection | Is behaviour abnormal now? | An anomaly score at time t | An alarm. Nothing more |
| Diagnosis | What is abnormal? | Component or failure mode | Routes the work order |
| Prognosis | When will it fail? | Remaining useful life, or P(fail within H) | The schedule — this is where the slide's economics live |
The value of the whole thing is a function of lead time minus time to act, and that difference can be negative while every accuracy metric looks excellent. A detector that is perfect and late is worth zero, which is not a statement about models at all.
The cost ratio is the threshold
Let k = cost(missed failure) / cost(false alarm). The motivating slide asserts k is somewhere between ten and a hundred. Three consequences follow immediately:
- F1 assumes k = 1. Precision and recall are weighted equally, which is a claim that an unnecessary inspection costs exactly as much as a destroyed machine. Nobody believes that, and models are tuned on it constantly.
- At k = 10 you should accept roughly ten false alarms per catch. That feels wrong to operators and is arithmetically correct, which is exactly the conversation the number exists to make possible.
- The threshold precedes the data. This is the same point
the-70-has-to-be-wrongmakes about probabilistic output — a threshold is a statement about costs, not a property of the model — and here the costs were written on slide one.
One honest correction to the arithmetic. Alarm fatigue is a real cost that does not appear in cost(false alarm). If operators stop investigating after the twentieth false alarm, the effective k collapses toward one, because a missed failure is now certain rather than unlikely. So "ten false alarms per catch" is an upper bound set by economics, not a target, and the binding constraint is usually the credibility budget rather than the inspection cost.
Why the first model should not be supervised
| Approach | What it needs | Why it usually fails here |
|---|---|---|
| Supervised classification | Many labelled failures | The valuable machines rarely fail; labels are dozens, and often mark the repair rather than the onset |
| Model normal, score deviation | Only healthy history | Workable — but an anomaly is not a failure |
| Residual against a physics model | A model of the machine | Strongest signal where it exists, since the residual has units and meaning |
The cheapest first artifact is not a model at all. Take the anomalies the plant already noticed and label their causes from the maintenance log. If most of them are changeovers and sensor faults, the honest conclusion is that the project's first deliverable is a changeover detector, and finding that out costs a day rather than a quarter.
The build: a cost curve, not a model
- Time to repair — from maintenance, not from data. Sets H.
- The cost ratio — from the motivating slide. Sets the threshold.
- Any scorer — a moving-average residual on one sensor is enough to draw the curve.
indicators-add-a-decisionapplies directly: the transform adds no information, it adds a decision, and the decision is where the value is. - Sweep the threshold, plot expected cost per machine-month, and report the threshold, the lead time it buys, and the false-alarm rate at that point.
The baseline is the part people get wrong. It is not "do nothing". Almost every plant already runs schedule-based maintenance, which prevents some failures at a known cost. A model that beats doing nothing and loses to replacing the part every six months is a negative result that looks like a positive one, and only the cost curve shows it.