Predictive maintenance machine learning uses sensor data such as vibration, temperature and motor current, together with your maintenance history, to spot a machine drifting towards failure early enough to fix it in a planned stop. For most UK manufacturers the practical first step is anomaly detection on one critical asset, not a plant-wide failure-prediction model.
You will often see a headline figure that downtime costs UK manufacturers £180bn a year. It traces back to 2017 research by the software company Oneserve, reported by The Manufacturer, and the method behind the number was not published. It makes a good headline but a weak business case. Your own downtime log, for one machine, is far more persuasive to a finance director.
What is the difference between reactive, preventive, condition-based and predictive maintenance?
The four approaches differ in what triggers the work. Most plants use a mix, and that is fine. Predictive maintenance is worth its cost only on assets where failure is expensive and gives some warning.
| Approach | What triggers maintenance | Data needed | Main drawback | Best suited to |
|---|---|---|---|---|
| Reactive | The machine breaks | None | Unplanned stops, secondary damage, emergency spares | Cheap, non-critical, redundant equipment |
| Preventive | Calendar or run hours | Run hours, schedules | Replaces healthy parts, still misses random failures | Wear parts with predictable life |
| Condition-based | A measured value crosses a set limit | Sensor readings, fixed thresholds | Fixed limits miss slow, combined changes | Assets with one clear indicator, such as oil temperature |
| Predictive | A model sees a pattern that precedes failure | Sensor history, operating context, failure records | Needs data, labels and ongoing upkeep | Critical assets with costly, detectable failure modes |
Condition-based monitoring is often the right answer on its own. If a single temperature threshold catches the failure you care about, you do not need machine learning. ISO 17359 gives general guidance on setting up a condition monitoring programme and is a sensible reference before you buy sensors.
What data do you need for predictive maintenance?
Three kinds of data, and the third is the one people underestimate.
Sensor data
Vibration, temperature, motor current, pressure and sometimes acoustic data. Vibration is the most informative for rotating equipment such as motors, pumps, fans and gearboxes, but it is sampled at high frequency and produces a lot of data. It is usually processed close to the machine and only summary features are sent on, which is where edge infrastructure comes in.
PLC and SCADA logs
Machine state, speed, load, product being run, alarms and stops. This context is essential. A motor running hot at full load on a dense product may be perfectly normal; the same temperature while idling is not. Models without operating context produce false alarms.
Maintenance history and failure labels
Work orders from your CMMS or maintenance logs: what failed, when, on which asset, what was replaced and why. This is how a model learns what "before a failure" looks like. In most plants it is also the weakest data set.
Why are failure labels usually the bottleneck?
A model that predicts failures needs examples of failures. Well-run plants have few of them, which is good for production and bad for training data. This is a well-documented problem. A 2025 study in Discover Applied Sciences describes scarce failure data as the main challenge in predictive maintenance, noting that some failures go unrecorded and normal operation dominates the data.
Three things make it worse in practice:
- Preventive replacement hides failures. If a bearing is changed every six months, you never see how it fails.
- Free-text work orders. "Fixed", "replaced part" and "see engineer" cannot be turned into reliable labels.
- Missing timestamps. The work order shows when the job was closed, not when the fault began.
The fix is unglamorous: add structured failure codes (asset, component, failure mode, cause) to your work orders now. Even if your first model does not use them, your second one will.
Why start with anomaly detection before failure prediction?
Anomaly detection learns what normal looks like for an asset in each operating state, then flags departures from it. It needs weeks of normal running data, not years of failure history. That makes it the realistic first step for most manufacturers.
The maturity path usually runs in this order:
- Anomaly detection. "This motor is behaving differently from its normal pattern at this load."
- Diagnosis. "The pattern looks like bearing wear rather than misalignment," once you have enough labelled cases.
- Remaining useful life. "Likely to need attention within three weeks," which needs the most data and the most validation.
Each step uses what the previous one taught you. Engineers' responses to anomaly alerts become the labels that make diagnosis possible.
How do you choose the right first asset?
Pick one asset, not a whole line. A good first candidate passes most of this checklist:
- Critical. It is a bottleneck or has no standby, so a failure stops output.
- Detectable. Its main failure mode gives physical warning (rising vibration, heat, current draw) days or weeks before it fails.
- Has failed before. You have at least a few recorded failures, so you know what to look for.
- Instrumentable. Sensors can be fitted safely, and PLC data can be read without disrupting control.
- Runs consistently. Enough runtime to learn normal behaviour within a few weeks.
- Has an owner. A maintenance engineer who will act on alerts and record what they find.
Avoid assets whose failures are sudden with no warning (some electrical faults) or that are already over-maintained. A short proof of concept on historical data from the chosen asset will show whether the signal is there before you commit to a wider rollout.
How do you measure the value of predictive maintenance?
Set the baseline before you start, using your own records for the chosen asset over the last 12 to 24 months:
- Unplanned downtime hours and the cost of an hour (lost contribution, overtime to catch up, late delivery penalties).
- Spares. Emergency purchases and expediting costs versus planned orders, plus any safety stock you could reduce.
- Maintenance labour. Callouts, overtime and contractor visits.
- Secondary damage. A failed bearing that takes out a shaft costs far more than the bearing.
Then track the system itself. The most useful single metric is alert precision: of the alerts raised, how many led to a real finding. If engineers check ten alerts and find nothing, they will stop checking.
How do predictive maintenance alerts reach the maintenance team?
An alert on a dashboard nobody watches achieves nothing. Alerts should create or suggest work orders in the CMMS your team already uses, with the evidence attached: the asset, the trend chart, the suspected component and a suggested check. This usually means integrating the model with your CMMS rather than adding another screen.
Close the loop. When the engineer completes the job, ask for a structured outcome: fault found, no fault found, or different fault. Those outcomes are your future training labels. They also strengthen your records under PUWER, which requires equipment to be maintained in good repair and any maintenance log to be kept up to date.
What are the common pitfalls?
Too few failures
If an asset has failed twice in five years, no model will learn its failure pattern from that alone. Stay with anomaly detection, and consider pooling data across identical machines, where you have several.
Sensor drift and changes
Sensors drift, get knocked, get replaced or are remounted after maintenance. Each change can look like an anomaly, or hide a real one. Monitor sensor health as well as machine health, log every sensor change, and re-baseline after major maintenance or product changes.
Alert fatigue
The fastest way to kill a project is too many alerts. Require an anomaly to persist for a set period before alerting, group related alerts, use severity tiers, and review precision with the maintenance team every month. Start strict and widen sensitivity once trust is established.
Frequently asked questions
How much data do we need for predictive maintenance?
For anomaly detection, a few weeks of normal running data across the asset's usual operating states is often enough to start. For predicting specific failures, you need several recorded examples of each failure mode with reliable timestamps. Most plants have the first and lack the second.
Can we use our existing PLC and SCADA data?
Usually, yes, and it is valuable context. PLC data shows load, speed and state, which explains much of the variation in sensor readings. It rarely captures early mechanical wear on its own, so vibration or current sensors are often added to critical assets.
Is predictive maintenance worth it for a small manufacturer?
It can be, on one or two assets where a failure stops the whole site. For general equipment, a good preventive schedule and simple condition-based limits are cheaper and often sufficient. Start with the asset whose failure costs you most.
What is the difference between condition monitoring and predictive maintenance?
Condition monitoring measures the state of a machine, usually against fixed limits. Predictive maintenance uses that data, plus operating context and history, to forecast when intervention is needed. Condition monitoring is the foundation, and predictive maintenance builds on it.
How do we avoid false alarms?
Include operating context in the model, require anomalies to persist before alerting, and set thresholds conservatively at first. Track alert precision with your maintenance team and adjust monthly. Fewer, more reliable alerts are worth more than complete coverage.
Where to start
Choose one critical asset, pull its downtime and work order history, and check whether its failures give physical warning. If you would like help assessing the data or building the first model, see our machine learning development service and get in touch.
