Answer this first: how many failures do you have
A predictive maintenance request usually arrives as: “We want to see bearing failures coming, and we have two years of data.” The first question back is not which model, but how many failures happened in those two years.
If the answer is “three”, there is no model. Supervised learning needs many examples of an event to learn it; three failures teach a classifier the noise of those three events, not the physics. There is no fourth example left for validation either — no way even to measure whether the model works.
The paradox punishes plants with good maintenance: critical equipment has never failed, so labelled negatives do not exist. Three paths remain.
- Anomaly detection. A health model built from “normal” data only, flagging deviations. No labels needed, but the output is “this does not resemble what I learned”, not “a failure is coming” — present it that way.
- Fleet data. With dozens of copies of the same equipment, failure counts pool at fleet level. With one machine, it is closed.
- A physical model. Bearing pass frequencies follow from geometry and shaft speed, not from history.
The seven items below need answers when the first sensor is specified, not after data collection.
1. Tag dictionary and unit consistency
Every column needs a written record of what it measures, in which unit, from which point.
You can guess that TT_0421 is a temperature; not whether it is Celsius or Fahrenheit, raw
or filtered.
Two traps recur: the same quantity recorded at two points in two units (bar in the PLC, kPa in reporting), and scaling applied to some tags but not others. The model reads no error — a variable of twice the magnitude simply looks more important and gets the weight. Build the dictionary once, correctly, on the data acquisition and analytics side; every layer above feeds from it.
2. Sampling interval and the deadband
The duration of the event sets the sampling interval. One second is ample for bearing wear developing over hours. Cavitation, arcing and impact events live on a millisecond scale; once-per-second sampling never sees them.
The more insidious issue is the deadband. Most SCADA and historian software does not store changes smaller than the configured band — reasonable for disk usage. But the result is an event log, not an evenly spaced series; forward-filling it into a flat table invents a signal that never moved, and every variance-based feature collapses. So training needs a separate stream with the deadband disabled for the model’s tags — a second collection path, costed up front.
3. Clock synchronisation
When data is merged from several sources (PLC, power analyser, vibration meter, MES), all clocks need a common reference. NTP is enough; sub-millisecond alignment calls for PTP (IEEE 1588).
Without it, the cause lands behind the effect. An alarm from a device running 40 seconds fast appears before the pressure drop that triggered it, and the model treats the alarm as the precursor. The error is invisible in the data: each series is internally consistent. Log every source’s offset periodically. Carrying timestamps across protocols is its own task — which is why, on the industrial communication systems side, OPC UA delivering a source timestamp and quality flag with each value is worth the effort.
4. Matching maintenance records to machine data
Machine data is usually clean; the problem is the label. In most plants it comes from a free-text log:
14.03 — motor got hot, checked fan, ok
No time (which shift?), no equipment identity (which motor?), no failure type, no way to tell whether “ok” means a repair or an observation. Written up by three technicians, one fault becomes “bearing noise”, “housing rumble” and “abnormal sound” — three classes to the model.
The fix is forward-looking: a closed-list record with date and time, equipment code, failure type from a fixed list, downtime and part replaced. Keep the free-text field, but keep classification independent of it. Without this, labelling typically consumes half the project effort.
5. Anomaly detection without operating-regime context
Switching from product A to B changes the machine’s current profile, temperature and vibration signature. An anomaly model blind to the regime reads that as a failure and floods the first hour of every changeover with alarms. The consequence is social, not technical: by the second week nobody in maintenance is looking.
The remedy is context in the input: active recipe number, line speed, raw material batch, idle/loaded state, warm-up flag. With few regimes, a separate model per regime beats one large model. Most of this already sits in the PLC, just not in the data stream.
6. Concept drift and retraining
A line is not static: bearings replaced, valves refurbished, suppliers changed, seasons turned. The “normal” the model learned drifts from today’s normal, and a model that worked in month one produces false alarms in month three.
So an ML deployment is a maintenance item, not a delivery. The commissioning package needs three things: a monitor that flags drift in the input distribution, retained data plus a written retraining procedure, and a record of which model version produced each prediction. Without the third, a past false alarm can never be explained.
7. What the output tells whom
The model produces a number; turning it into an action is a separate design task.
Advisory mode. The output reaches the operator or planner as a recommendation; the decision stays with a person. A false alarm costs one inspection round. Nearly every first deployment starts here.
Closed loop. The output drives an action: speed reduced, line stopped, set point changed. The bar is far higher, because a statistical prediction now intervenes in process control. One rule is unambiguous: safety functions are never wired to a model. Emergency stop, guard door interlocking and over-pressure or over-temperature protection stay in the hardware safety chain and the safety PLC; the model layer only reads them. A probabilistic output cannot replace a function requiring a safety integrity level (SIL).
Sometimes the right answer is a threshold
The honest part: if a problem is explained by one physical quantity, a model is unnecessary and usually worse.
If filter clogging shows in differential pressure, the answer is a threshold and a delay timer; if motor overload shows in current, the answer is current monitoring. Those rules are transparent, and they need no upkeep for ten years. A model doing the same job brings a data pipeline, versioning and a retraining burden.
A model wins where one variable is not enough: when several signals only carry meaning together, when the relationship is non-linear, or when the threshold depends on the operating regime.
| Item | Minimum | If not met |
|---|---|---|
| Labelled failures | Tens per class plus validation events | No supervised model |
| Tag dictionary | Meaning, unit, measurement point | Mixed units distort weights |
| Sampling interval | One tenth of event duration | The event stays invisible |
| Deadband | Disabled for the model’s tags | Forward fill invents flatness |
| Clock sync | NTP everywhere; PTP if precise | Causality learned backwards |
| Maintenance record | Closed-list type, timestamp, equipment code | Labelling doubles the project |
| Regime context | Recipe, speed, load state in input | Changeovers read as failures |
| Retraining plan | Drift monitor, retained data, version log | Silent decay by month three |
What you can do tomorrow
No model selection required — about two hours of work.
- Count the failures on the target equipment over the last 24 months. A single digit takes supervised learning off the table; the conversation moves to anomaly detection.
- For each tag intended for the model, read the unit, the scaling and the deadband setting from the historian.
- Open the last ten maintenance log entries and ask whether each can be matched to a time window in the machine data. If not, fix the record form first.
Those three steps show whether the project is feasible before a line of code is written — the same preparation we do in the first session on the artificial intelligence and machine learning side. A model whose data is not ready produces, at best, a dashboard nobody reads.