What Is Predictive Maintenance? Definition, Levels, and Requirements

Predictive maintenance means forecasting when equipment will fail, not just detecting that something's wrong right now. This post covers the formal EN 13306 definition, the four maintenance levels, and how to tell true prediction from condition-based detection.

Published

Author

Predictive maintenance uses equipment data to forecast failures before they happen. The standard's definition, the four maintenance levels, and how to tell detection from prediction.

Predictive maintenance means using measurements from equipment to forecast when it will fail, so maintenance can be scheduled before the failure instead of after it. The forecast is the defining feature. Watching sensor data and reacting when a limit is crossed is condition-based maintenance; projecting when the limit will be crossed, and ideally how long the equipment has left, is predictive maintenance.

That distinction is not ours; it is how the formal maintenance-terminology standard defines the term, as a subset of condition-based maintenance:

The Four Levels of Maintenance Strategy

Level Trigger Question answered What it requires
Preventive Calendar or runtime hours Is it due? A schedule
Condition-based (CBM) A threshold crossed right now Is it outside limits right now? Sensors and thresholds
Predictive (PdM) A trend projected to cross a threshold When will it fail? Sensors, history, and trend or prognostic models
Prescriptive Predicted failure plus diagnosed cause What should we do about it? All of the above, plus root-cause analytics

How to Tell Detection From Prediction

The standard's definition gives you a one-question test: does the system estimate *when*? A vibration alarm that fires at a fixed limit is condition-based monitoring. It becomes predictive when the system projects the trend and estimates time to failure, the remaining-useful-life concept standardized in ISO 13381-1.

Early detection is real value: catching an anomaly weeks before failure prevents the failure just the same. It is still detection of a present condition rather than a forecast of a future one, and the distinction is worth knowing when you plan a system, because forecasting needs historical failure data and degradation models that detection does not.

Threshold-based monitoring is not the lesser product for it. Well-built condition monitoring catches real problems on day one and has the strongest published evidence behind it; you can see monitoring of this kind running on commercial HVAC equipment at smarthvac.io.

What the Savings Evidence Shows

A PwC and Mainnovation survey of 268 companies in Belgium, Germany, and the Netherlands found adopters reporting 9 percent higher uptime, 12 percent lower costs, and 20 percent longer asset lifetimes.

The reason the category exists goes back further. In the 1970s, a landmark study of aircraft component reliability examined how equipment actually fails and found that only about 11 percent of the ways equipment fails were age-related; the rest could strike at any point in a component's life. Most failures do not follow the calendar, which is why measuring the equipment's actual condition beats maintaining purely on a schedule.

Documented Deployments

HeatMaster with Blynk (case study) HeatMaster, a Canadian solid-fuel furnace OEM, connected 190 furnaces in its first full heating season on Blynk. Connected equipment data identified the root cause behind a fault pattern, avoiding an estimated $100,000 recall, and replacing manual data collection and fly-out troubleshooting saves the company an estimated $50,000 to $60,000 a year in support costs.

Sprouts Farmers Market with Axiom Cloud. Over nine months across 115 stores, Axiom's software-only leak detection caught 32 refrigerant leaks early, 84 percent faster than the stores' other detection measures, and saved over $460,000 in refrigerant and maintenance costs. The figures are Axiom's own, published with the customer named.

What Prediction Requires

The gap between a threshold alert and a genuine forecast is a data problem before it is an algorithm problem. Models need a baseline of normal operation per equipment family, then failure examples to learn from, and industrial equipment is designed not to fail, so labeled failure data is scarce. Early deployments also produce false positives that take months of feedback to tune down, which is why so many programs stall at the pilot stage. We've broken down what each maintenance level costs to build, from schedules to forecasts, in a separate deep dive for teams adding intelligence to their own equipment lines. [link when published]

Frequently Asked Questions

Is predictive maintenance the same as condition-based maintenance?

No. Predictive maintenance is a subset of condition-based maintenance under EN 13306. Both act on measured equipment condition, but condition-based maintenance reacts to the current state (a threshold crossed now), while predictive maintenance acts on a forecast of a future state.

How is predictive maintenance different from preventive maintenance?

Preventive maintenance is triggered by time or usage: a calendar interval or runtime hours. Predictive maintenance is triggered by the equipment's measured condition and a projection of where that condition is heading.

What data does predictive maintenance need?

Three things: sensor measurements of the parameters that indicate degradation, a baseline of normal operation for each equipment type, and historical failure examples for models to learn from.

Start With Detection, Build Toward Prediction

For teams building monitoring into their own equipment, the definitional boundary doubles as a build sequence. Condition-based detection works from the first connected unit and needs no failure history. Prediction is earned later, as a deployed fleet accumulates the baselines and failure examples that forecasting models require. The infrastructure underneath both is the same, and it is ready to use rather than something to build: connected devices, reliable data collection, and fleet-scale device management on scalable, SOC 2 Type II compliant cloud infrastructure. A low-code IoT platform like Blynk covers that layer.

Much of the condition-based layer comes out of the box: automations and alerting for threshold rules, over-the-air firmware updates as detection logic evolves, Data Converters to bring already-deployed equipment onto the platform without firmware changes, and native mobile apps for the people who respond to the alerts. Your engineering effort goes into the degradation signatures and forecasting models only your team can write.

Every year a fleet runs unconnected is baseline and failure data the forecasting models will never get back.

Build toward the question that defines the category: when will it fail? Talk to us about your project at blynk.io.

Sign up for a newsletter
Get latest news from Blynk
Over 500,000 people already signed up our newsletter.
We never spam.
Thank you!
Your submission has been received.
Oops! Something went wrong while submitting the form.