Start with what is already logged
Predictive maintenance is usually pitched as a sensor programme - vibration monitors, thermal imaging, a network to carry it. That is a substantial capital project to start from.
Most operations already generate relevant data without realising: control system logs, motor current, cycle counts, energy consumption, temperature setpoints and actuals, alarm histories, and the maintenance record itself.
Signals hiding in ordinary data
- Energy consumption - a machine drawing more power for the same output is usually deteriorating
- Cycle time drift - gradual slowing before a mechanical failure
- Alarm frequency - minor alarms often increase before a major fault
- Setpoint deviation - a system working harder to hold the same condition
- Run hours since service - basic but frequently not tracked properly
- Restart frequency - repeated resets are a symptom nobody logs formally
Energy is the most widely available and most under-used. Sub-metering at machine level, where it exists, frequently supports useful condition monitoring on its own.
The maintenance record is your labels
Detecting deterioration requires knowing when failures occurred, which comes from the maintenance system. That record is usually the weak link.
| Problem | Effect |
|---|---|
| Failure date recorded as repair date | Misaligns the signal by days or weeks |
| Free-text fault descriptions | Cannot group failures by mode |
| Preventive and reactive work not distinguished | Cannot tell a failure from a service |
| Minor interventions unrecorded | Early symptoms invisible |
The first row causes real damage. If you are looking for signals before failure and the failure timestamp is wrong, the model learns from the wrong window.
Prove it before the capital request
- Pick a small number of assets with reasonable existing data and known failure history.
- Check whether any signal precedes past failures - often visible in a chart before any modelling.
- Quantify what earlier warning would have been worth: avoided downtime, secondary damage, expedited parts.
- Use that to justify sensors only for assets where existing data is genuinely insufficient.
This sequence produces a business case grounded in your own equipment rather than a vendor's figures, and it usually costs very little to run.
Be honest about how few failures you have
The awkward constraint in predictive maintenance is that critical equipment fails rarely, which is the point of maintaining it. A model needs examples of failure to learn from, and you may have very few.
Where failures are genuinely rare, anomaly detection - learning normal behaviour and flagging departures - is usually the better approach than trying to predict a specific failure mode. Our note on predicting failure with little failure data covers this.
Before buying sensors, check whether the data you already throw away would have told you.