Executive summary
25–30%
maintenance cost reduction from a mature predictive programme, per the US DOE
~10x
return on the programme, per the same DOE figures
Key conclusions
- Every DOE figure assumes the sensor feed was already reliable: it sampled fast enough, sat where the failure shows up and logged data without unflagged gaps.
- Most plants starting predictive maintenance for the first time have retrofitted sensors mounted where a bracket happened to fit, some distance from where the bearing actually wears.
- Instrument against the specific failure mode and verify the feed. Only then will the analytics layer deliver the return the department's figures describe.
A predictive maintenance programme depends on the sensor readings that feed it, and at most plants nobody has checked whether those readings are good. Plants usually buy the analytics dashboard before they verify the instrumentation underneath it. This is the wrong order. It is the same mistake as buying a model before the data pipeline that should feed it exists.
The benefits of getting the order right are well documented. The US Department of Energy's Federal Energy Management Program reports what a mature predictive maintenance programme achieves against a reactive baseline. Maintenance costs fall by 25 to 30 percent and unplanned breakdowns by 70 to 75 percent. Downtime falls by 35 to 45 percent, productivity rises by 20 to 25 percent and the programme returns roughly ten times its cost. Compared with a preventive, calendar-based programme alone, the department's figures still show a further saving of 8 to 12 percent.
The DOE figures assume the sensor feed is already reliable
Every one of those figures comes from a programme where the sensor feed was already reliable. The sensors sampled fast enough to catch the fault frequency they were meant to catch. They were placed where the failure mode actually shows up. They logged continuously, so gaps in the data were rare and were treated as gaps.
Most plants adopting predictive maintenance for the first time do not yet have this. They have scattered retrofitted sensors, installed wherever a bracket happened to fit. The sensors report on a schedule set by battery life rather than by the physics of the failure they are meant to watch.
Instrumentation usually falls short in four ways
- The sampling rate is too low to resolve the vibration frequency at which the fault would appear. The signal exists in principle but is missing from the data.
- Sensors are placed where they are easy to install, away from the failure mode being monitored.
- Gaps in continuous logging are filled by interpolation or dropped without notice, instead of being flagged as missing.
- No data-quality check is defined before the analytics layer starts to trust the feed, so the model runs on whatever data arrives.
A published case study shows how one team handled missing readings
A 2022 peer-reviewed case study in the journal Sensors documented this problem. The study covered wireless vibration and temperature monitoring on a coal-fired power plant's crushers and a steelworks' gantry cranes. The analytics became trustworthy only after the team defined how to handle missing readings. Gaps under 50 seconds for the crushers and under 120 seconds for the gantries were filled with the last recorded value. Any longer gap was treated as missing data.
The team made that data-engineering decision before any model ran. It decides whether the analytics layer can be trusted or whether it produces a confident number that nobody has tested.
Instrument first, verify the feed, then add analytics
Install the instruments first, and target the specific failure mode. Verify the feed before anything downstream relies on it: check the sampling rate and the placement, and state a rule for what happens when a reading is missing. Only then will an analytics layer deliver the return the Department of Energy's figures describe.
If you skip that sequence, the analytics layer inherits every gap in the sensor feed without anyone noticing. A programme sold on a tenfold return can then perform worse than the reactive baseline it was meant to beat. Check the proposal against your own downtime log before you sign off the next one.
