How much failure history do we need before a model is honest?

For a supervised model, dozens of examples of the same failure mode on comparable assets — not two. Below roughly ten labelled events, the defensible options are physics-based condition indicators with agreed thresholds, or anomaly detection reviewed by someone who knows the equipment. Both are useful, and both should be described as what they are rather than sold as prediction.

Can we do predictive maintenance with the SCADA data we already historize?

For some failure modes, yes: fouling and blockage from differential pressure, valve degradation from stroke times and cycle counts, motor load drift, and anything else that develops over days. For bearing and gear defects, no — those need high-rate vibration data. Before deciding either way, check the compression and deadband settings on the tags, because the archive frequently holds much less detail than the sensor produced.

Do we need an AI platform before we start?

No. Start with one asset class, one failure mode and a retrospective look at the last few failures; that costs nothing and answers the only question that matters at this stage. What you do eventually need is unglamorous: stable asset identity, operating context, one time base, and history kept long enough to contain more than one failure. Our free diagnostic is a preliminary, self-reported screening that helps frame those gaps — it is a starting point for a conversation, not an assessment of your data.

Predictive Maintenance Readiness

The model is the easy part. The prerequisites are not.

Predictive maintenance estimates when a specific failure mode on a specific asset will develop, so the work can be scheduled before the failure happens. It becomes viable only when three things exist together: a measurable precursor of that failure mode, measurement dense enough to see the precursor develop, and a history that records what actually failed and when. Missing any one of them, what you can build is condition monitoring or anomaly detection — both useful, neither a prediction — and calling it prediction is how programmes lose their audience.

The Prerequisites

Seven checks to run before anyone buys a model.

Name the failure mode, not the asset“Predict pump failures” is not a project. “Detect outer-race bearing degradation on the transfer pumps” is: it has a physical mechanism, a measurable precursor and a maintenance action. One asset can have a dozen failure modes with nothing in common.

Establish the P-F intervalThe time between the point at which the failure becomes detectable and the point at which the asset stops doing its job. Detection has to be at least twice as frequent as that interval, and the interval has to be long enough for parts and a window. A perfectly accurate prediction with four hours of warning and a two-week spare-part lead time changes nothing.

Match sampling to the physicsSampling has to exceed twice the highest frequency of interest, and spectral practice usually works to about 2.56 times. Bearing defect frequencies and their harmonics live in the kilohertz range; a one-minute average in a historian cannot represent them at any price. Conversely, fouling and wear are slow, and a well-chosen daily figure is plenty.

Check what the archive actually keptHistorians commonly apply exception and compression deadbands, so the archive is not what the sensor saw. Before you conclude the signal is absent, confirm the compression settings on those tags — a great deal of “there was no warning” is really “the warning was discarded on the way to storage”.

Find labelled failuresSupervised prediction needs examples: work orders that say which mode failed, using a consistent taxonomy such as the failure-mode vocabulary of ISO 14224, timestamped precisely enough to line up with sensor data. Below roughly ten labelled events for a mode, the honest options are physics-based condition indicators or anomaly detection with human review — not a classifier with a confident accuracy figure.

Carry the operating contextLoad, speed, product, ambient conditions and operating state. Without them, every changeover looks like a fault and every seasonal shift looks like degradation. This is the single most common reason a pilot that worked in the lab produces false alarms on the floor.

Start from criticality, not from sensorsRun to failure is a legitimate and cheaper strategy for assets that are inexpensive, redundant or non-critical, and time-based maintenance is fine where the failure is genuinely age-related. Predictive effort belongs where a failure is expensive, the mode is detectable and someone can act on the warning.

Failure-mode family	What actually reveals it	What the data layer has to carry
Rolling-element bearing degradation	High-frequency vibration, envelope or demodulated acceleration, ultrasound.	Waveform or spectra at kilohertz rates with a known shaft speed; a temperature trend arrives far too late to be called prediction.
Imbalance, misalignment, looseness	Amplitude and phase at one and two times running speed.	Synchronous speed reference for every measurement, and a stable measurement point identity across route changes.
Motor and rotor faults	Motor current signature: sidebands around line frequency, current imbalance.	Current sampled fast enough to resolve those sidebands, plus load context so a lightly loaded motor is not read as a healthy one.
Fouling and filter blockage	Differential pressure or approach temperature, normalised to flow.	Flow, setpoint and product context; an unnormalised pressure rise is just as likely to be a production change.
Lubrication and wear	Oil analysis, particle counts, wear metals.	Lab results joined to the asset and to a timestamp as data, not filed as PDFs nobody can query.
Valve and actuator degradation	Stroke time, position error, cycle count against a baseline.	Event counts and timings per asset, with an identity that survives control-system upgrades and renaming.

The honest ladder

Reactive, then time-based preventive, then condition-based, then predictive. Each rung needs the one below it to be working: an organisation that cannot execute a planned work order on schedule will not benefit from knowing three weeks earlier. Most plants get more value from finishing the rung they are on than from skipping two.

Test readiness retrospectively, for free

Pick one asset class and one failure mode, find the last five failures in the maintenance history, and look at the data that existed around each one. If a precursor is visible in retrospect, you have a case; if the data is missing, ambiguous or too coarse, you have found your real project — and you found it before spending anything.

Anomaly is not failure

An anomaly score says the current data is unlike the training data. That can mean a developing fault, or a new product, a rebuilt machine, a replaced sensor, or summer. Anomaly detection without a route to a named failure mode produces alerts that get muted exactly like nuisance alarms.

How predictive programmes fail, honestly.

No labelled failures, so nothing can be validated, and confidence is asserted rather than measured.
Accuracy quoted on a data set where 99% of samples are healthy. A model that always predicts “healthy” scores 99% and is worthless; precision, recall and lead time are the numbers that matter.
Leakage: training on data recorded after the repair, or on fields that only exist because the failure was already known.
Sensors installed after the historical failures happened, leaving you with instruments and no history to learn from.
Drift after a rebuild, a new product mix or a re-instrumented asset, with no owner watching for it. Models decay quietly.
Alerts with no defined response and no spare part, which teach the crew to ignore them — the same fate as an unrationalized alarm.
A pilot on the newest, best-instrumented machine, which is rarely the one that costs the plant money.

Related Concepts

What has to exist underneath.

Predictive work is the clearest test of whether the data layer is real: it needs asset identity, operating context, aligned time and retained history, which is exactly what contextualization supplies and what a Unified Namespace makes available without rebuilding an integration per model, with ISA-95 naming the equipment consistently across OT and the maintenance system. Whether the high-rate signal ever reaches a place it can be analysed is largely the MQTT versus OPC UA question, and the broader prerequisites are the same ones that decide industrial AI readiness. Downstream, avoided breakdowns show up as availability in the OEE breakdown, repeat nuisance alarms on one asset are often an unread condition signal, and the confirmation of any prediction ends up in a root cause analysis.

Work The Maintenance Data

Most plants have more evidence in their work orders than in their sensors.

Maintenance Copilot reads a maintenance data bundle you supply — work-order history, asset context, condition indicators, downtime events — and helps you see repeat offenders, the modes that actually recur, and where a predictive case is realistic against where it is not. It reasons over the export you give it; it does not stream vibration, connect to your CMMS or write work orders. Five free runs, then it is part of the agents plan.

See Maintenance Copilot