Predictive maintenance only works if the sensor data underneath it does

A predictive maintenance programme is only as good as the sensor readings feeding it, and on most plant floors nobody has actually checked whether those readings are good. The analytics dashboard gets bought before the instrumentation underneath it is verified, which is backwards — the same mistake as buying a model before the data pipeline that is meant to feed it exists.

The upside for getting the order right is well documented. The US Department of Energy's Federal Energy Management Program puts a mature predictive maintenance programme at cutting maintenance costs 25 to 30 percent and unplanned breakdowns 70 to 75 percent against a reactive baseline, with downtime down 35 to 45 percent, productivity up 20 to 25 percent, and a return on the programme of roughly tenfold. Compared to a preventive, calendar-based programme alone, the department's figures still show an 8 to 12 percent further saving.

What those figures assume

Every one of those numbers comes from a programme where the sensor feed was already reliable: sampling fast enough to catch the fault frequency it was meant to catch, placed where the failure mode actually shows up, and logged continuously enough that a gap in the data is rare and gets treated as a gap rather than quietly filled in.

Most plants adopting predictive maintenance for the first time do not have that yet. They have a scatter of retrofitted sensors, installed where a bracket happened to fit rather than where the bearing actually wears, reporting on a schedule set by battery life rather than by the physics of the failure being watched.

Where the instrumentation typically falls short

• Sampling rate too low to resolve the vibration frequency the fault would actually show up at, so the signal is there in principle and absent in the data.
• Sensor placement chosen for ease of installation rather than proximity to the failure mode being monitored.
• Gaps in continuous logging that get silently interpolated or dropped, rather than flagged as missing and handled as such.
• No defined data-quality check before the analytics layer is allowed to trust the feed — the model runs on whatever arrives.

What the gap costs, with a name attached

A 2022 peer-reviewed case study in the journal Sensors documented exactly this problem on wireless vibration and temperature monitoring deployed across a coal-fired power plant's crushers and a steelworks' gantry cranes. The analytics only became trustworthy once the team explicitly defined how to handle missing readings — gaps under 50 seconds for the crushers and 120 seconds for the gantries were bridged with the last recorded value, and anything longer was treated as missing data rather than papered over with an assumption.

That is not a machine-learning problem. It is a data-engineering decision made before any model ran, and it is the difference between an analytics layer that can be trusted and one that produces a confident number nobody has stress-tested.

The order that actually holds

Instrument first, and against the specific failure mode rather than wherever installation is convenient. Verify the feed — sampling rate, placement, and a stated rule for what happens when a reading is missing — before anything downstream is asked to trust it. Only then does an analytics layer buy the return the Department of Energy's figures describe.

Skip that sequence and the analytics layer inherits whatever gaps live in the sensor feed, silently, and a programme sold on a tenfold return can end up underperforming the reactive baseline it was meant to beat — which is a claim worth checking against your own downtime log before the next one is signed off.