Condition monitoring vs predictive maintenance: what differs and when each is enough

Use condition monitoring when you need to know the state of a machine now and a trained person or a clear limit can decide what to do; use predictive maintenance when you also need a forecast of when it will fail, across enough similar assets and failure history to make that forecast credible. Condition monitoring measures and judges health. Predictive maintenance adds a prediction on top of those measurements and plans the work around it. The second cannot exist without the first, and many plants get most of the value from the first alone.

The two terms are often used as synonyms in sales material, which leads to projects that buy a forecasting platform when a trend chart and an alarm would have done. This guide separates them using the ISO framework, shows where each sits on the maintenance ladder, and lists what each needs in data, models and organization.

Aspect	Condition monitoring	Predictive maintenance
Question answered	Is this machine healthy now?	When will it fail, and when should we act?
Typical output	Trend, alarm level, diagnosis	Remaining useful life or failure probability in a time window
Data needed	Sensor readings and a healthy baseline	The same, plus operating context and failure history
Models	Thresholds, trends, anomaly scores	Degradation and survival models, fault classifiers
Failure history	Not required	Required, ideally many run-to-failure cases
Who decides	Analyst or maintenance planner	Planner, helped by the forecast

How do the standards define condition monitoring?

The international reference is ISO 17359, titled “Condition monitoring and diagnostics of machines” with the subtitle “General guidelines”. It sets out the general steps for establishing a condition monitoring program on any machine, from understanding the equipment and how it fails to choosing what to measure, setting alert criteria and deciding the maintenance action, and it points to the standards that cover each measurement technique.

The ISO 13374 series, with the subtitle “Data processing, communication and presentation”, describes the software side. It splits a condition monitoring system into six functional blocks, which MIMOSA’s OSA-CBM specification implements with data structures and interfaces:

Data acquisition: digitize sensor signals with timestamps.
Data manipulation: filter, transform and extract features such as spectra and RMS values.
State detection: compare features with a baseline or limits and flag deviations.
Health assessment: rate the current condition and diagnose the likely fault.
Prognostic assessment: estimate future health and remaining useful life.
Advisory generation: recommend actions and timing.

That list makes the boundary concrete. Blocks one to four are condition monitoring and diagnostics. Block five is the step that turns monitoring into prediction, and block six is what both approaches must deliver to be useful. Acting on blocks one to four is called condition-based maintenance; adding block five is what the industry calls predictive maintenance.

Where do they sit on the maintenance ladder?

Maintenance strategies are usually presented as a ladder of increasing information. The rungs are a convention, not a standard, but they are useful for placing a project:

Reactive: run to failure and repair. Sensible for cheap, redundant equipment.
Preventive: service on a calendar or a counter, such as operating hours. No sensors needed, but healthy parts are replaced and early failures are missed.
Condition-based: act when a measured parameter crosses a limit. This is condition monitoring connected to a work order.
Predictive: act on a forecast, scheduling the work for the best window before the predicted failure.
Prescriptive: the system also recommends what to do, weighing spares, production plans and risk.

Each rung needs the one below. A plant cannot forecast failures on assets it does not measure, and a forecast nobody can act on is a chart.

What data and models does each need?

Condition monitoring needs sensors placed for the failure modes that matter, a sampling rate high enough for the signal, and a reference for “healthy”. The reference can come from a standard, such as the vibration severity zones in ISO 20816-1, from the machine maker’s limits, or from a baseline learned on the machine itself. The models are simple: thresholds, rates of change, and anomaly detection that scores how far today’s features are from the baseline. None of this needs a single recorded failure, which is why it can start on day one and run on the sensor node as TinyML.

Predictive maintenance needs everything above plus three things that are often missing. First, operating context: speed, load and process state, usually read from the controller, so that a change in duty is not mistaken for degradation. Second, history: maintenance records that say what failed, when and why, joined to the sensor data at the right timestamps. Third, enough examples of degradation running to failure, per asset type, to fit a model of the trajectory. With those, the options are degradation models that extrapolate a health indicator to a failure threshold, survival models that give a probability of failure within a window, and classifiers that name the fault. Without them, a “predictive” model is an anomaly detector with a confident label.

The warning window matters for both. The time between the first detectable sign of a fault and functional failure, often called the P-F interval, must be longer than the time needed to plan the work, get parts and stop the machine. Monitoring with a long window already gives time to act; a forecast adds value mainly when that window is tight or the cost of choosing the wrong stop is high.

When is condition monitoring enough?

Condition monitoring alone is usually the right answer when:

The failure modes are well understood and show clear, rising symptoms, such as bearing wear in vibration or a clogged filter in pressure drop.
The warning window is long compared with your planning lead time, so an alarm today still leaves weeks to schedule.
You have a few critical assets and an analyst who reviews trends, rather than thousands of similar ones.
Failure history is thin or poorly recorded, which makes any forecast unreliable.
The asset is cheap or redundant, so an occasional surprise costs less than a modeling project.

Moving up is worth it when downtime is expensive and must be planned around production, when a fleet of similar assets provides the data to learn degradation curves, when spare parts have long lead times, and when the organization can act on a forecast weeks ahead. The predictive maintenance guide covers the signals and signal processing behind both approaches.

Where to go next

Predictive maintenance with IoT and AI explains the signals, features and model ladder in detail.
TinyML explained shows how anomaly detection runs on the sensor node.
AI agents on the factory floor covers turning alerts into work orders.
OPC UA explained shows how operating context is read from machine controllers.

Topics: condition monitoring, predictive maintenance, maintenance strategy, comparison