Condition-Based Maintenance vs Predictive Maintenance

I have sat in a lot of rooms where a vibration sensor programme was being presented as predictive maintenance, and in almost every one of them the thing on the screen was condition based maintenance. Nobody was lying. The words have been used interchangeably for so long, by vendors, by consultants and in a great deal of published material, that most people genuinely do not know there is a distinction. There is, and it is a useful one, because the two approaches need different data, cost different amounts, carry different risks and suit different asset classes. If you cannot tell which one you are buying, you cannot tell whether you are being overcharged for it.

The message up front: condition based maintenance acts on a measured present condition crossing a threshold. Predictive maintenance forecasts a future condition and estimates how long you have before functional failure. CBM is a decision rule. PdM is a decision rule plus a prediction. The prediction is where nearly all of the extra cost, data requirement and failure risk sits, and for most asset classes you do not need it. Doing CBM well beats doing PdM badly, every time.

1. The distinction, stated once and stated clearly

Strip away the marketing and both approaches rest on the same foundation: you measure something about the physical condition of an asset while it is running, rather than relying on the calendar. That shared foundation is condition monitoring, and it is why the two get conflated. The difference is entirely in what you do with the measurement.

Condition based maintenance compares the current measured value against a limit. Bearing vibration overall velocity reaches 7.1 mm/s, which your alarm band says is unacceptable, so a work order is raised and a technician investigates. Oil analysis comes back with iron particle count above the agreed limit, so the gearbox goes on the intervention list. Switchgear thermography shows a connection 25 degrees hotter than its neighbouring phases, so it gets retorqued at the next shutdown. In every case you are asking one question: is this asset outside acceptable condition now? If yes, act. That is the whole logic.

Predictive maintenance asks a harder question: given how this condition is changing, when will it become unacceptable, and how long until functional failure? The same vibration reading is no longer just a number to compare against a limit. It is the latest point on a trend, and the trend is extrapolated forward to produce a date, or a range of dates, or a remaining useful life estimate. Vibration is at 4.5 mm/s today, has climbed steadily for eleven weeks, and projects to cross the 7.1 mm/s alarm in roughly six weeks, so the intervention gets scheduled into the shutdown window five weeks out, parts ordered now.

Notice what changed. The sensor is the same. The technique is the same. The asset is the same. What was added is a forecast, and with the forecast came the requirement for history, for a defensible degradation model, and for somebody who can judge whether the projection is trustworthy. The predictive maintenance practitioner's guide covers that forecasting layer in depth; this article is about the line between the two, and how to decide which side of it you should be standing on.

2. Side by side: CBM vs PdM on the things that matter

The comparison below is the one I would put in front of a maintenance manager deciding where to spend. Read the data requirement and skills rows carefully, because that is where most programmes come unstuck.

The row I would underline is the last one. PdM is not an alternative to CBM, it is a layer built on top of it. Every predictive programme I have seen work was running competent condition based maintenance first, with clean thresholds and consistent measurement, and then added trending and forecasting to a subset of assets. Every one that struggled had tried to jump straight to forecasting on top of measurement discipline that was not there yet.

3. The condition monitoring techniques both approaches share

This is the part people find surprising: the technique list is identical. There is no such thing as a predictive sensor or a condition based sensor. There is vibration, thermography, oil analysis, ultrasound, motor current and process parameters, and whether the resulting data feeds a threshold check or a trend projection is a decision made downstream in software and in engineering judgement, not in the hardware.

What does differ is how well each technique supports forecasting. Some produce a smooth, monotonic degradation signal that extrapolates sensibly. Others produce a step change that tells you a fault has arrived but gives you very little to trend. The table below is the one I use when someone asks which techniques to deploy, and importantly it includes what each technique cannot see, because that column is usually missing from the vendor version.

The practical reading of that table: vibration, oil analysis and process parameters are where forecasting has a genuine chance. Thermography, ultrasound and insulation testing are superb condition based tools whose measurements are harder to extrapolate reliably, and pretending otherwise is how you end up with a predicted failure date that nobody in the engineering team believes. For an asset-class view of how these map onto the equipment most sites actually own, the generator, pump and motor maintenance guide is the companion piece.

Whatever technique mix you land on, the standards work is worth reading rather than taking a vendor's summary of it. ISO maintains the condition monitoring and machine vibration series that underpins most credible alarm-limit practice, and NFPA covers the electrical maintenance and safe-work side that governs how you actually get near energised switchgear to take a thermal reading.

4. Thresholds and alarm bands: the whole game for CBM

If CBM is a decision rule, the threshold is the programme. Everything else is plumbing. Get the threshold right and a modest, cheap, route-based CBM programme will find real faults with very few false calls. Get it wrong and you will either miss developing failures or drown your team in alerts until they stop reading them.

A workable alarm structure has more than one level. A single trip point gives you no graded response, which means every exceedance is either ignored or treated as an emergency. The structure I would recommend:

• Baseline: the measured condition of the asset when it is known healthy, established after commissioning or after a confirmed good overhaul. Without a baseline you have no idea whether 3.5 mm/s is normal for this machine or already twice what it should be.
• Advisory or alert band: condition has moved measurably away from baseline but the asset is not at risk. The correct response is increased monitoring frequency and a note, not a work order. This band is where PdM, if you have it, does its useful work.
• Alarm band: condition is unacceptable and intervention must be planned. A work order is raised with a defined target date, parts are checked, and the asset is put on a shortened monitoring interval.
• Danger or trip band: condition threatens the asset or the people near it. Immediate action, up to and including shutdown. This band should be set conservatively and should almost never be reached, because the alarm band should have caught it.

Where do the numbers come from? Three sources, in descending order of reliability. First, the equipment manufacturer's stated limits, which are authoritative for that machine but often conservative and sometimes absent. Second, published generic limits by machine class and mounting, which are a reasonable starting point and are what most sites use on day one. Third, and best in the long run, your own baseline plus a statistical band derived from your own fleet's healthy operating spread, because your machines in your ambient conditions on your duty cycle are the only truly relevant population.

Two habits prevent this. First, treat thresholds as living settings with a named owner and a review cycle, not as configuration set once at go-live. Second, track your alert-to-genuine-fault ratio as an explicit metric. If fewer than roughly a third of alarms turn out to be real findings, your limits need work before you add another sensor. That discipline belongs in the same KPI conversation as the rest of the maintenance measures, and it is worth reading alongside the preventive maintenance strategies pillar so the condition triggers sit properly next to your time and meter based ones.

5. What each approach actually needs from your data

This section is the one that decides, in practice, which approach is available to you. It is not a matter of ambition. It is a matter of what is in your systems.

CBM needs one good threshold and one valid reading. That is genuinely all. You do not need failure history. You do not need years of trend data. You do not need a data platform. You need a measurement you trust, taken the same way each time, at the same point on the machine, under comparable operating conditions, and a limit you can defend. A site with no historian and a clipboard can run effective condition based maintenance, and plenty do. What it needs instead of data volume is measurement consistency: same transducer location, same mounting, same speed and load conditions, same analyst method. Inconsistent measurement is the CBM equivalent of bad data, and it is far more common than missing sensors.

PdM needs history and, ideally, failure examples. To project a trend you need enough evenly spaced points to establish that a trend exists and is not noise, which in practice means many months of consistent measurement per asset before a projection means anything. To estimate remaining useful life with real confidence you need something harder still: examples of similar assets that actually degraded to failure while instrumented, so the shape of the degradation curve is known rather than assumed. Most organisations have very few of those, because well-run maintenance intervenes before failure, which is exactly the outcome you wanted and exactly what starves the model of training data. That is a real and under-discussed tension.

There is also the quality question underneath both. Threshold exceedances and forecast outputs are only worth anything if the work that follows them is recorded properly. If your completion records say "checked, OK" with no finding and no failure code, you cannot later tell whether the alert was right, which means you can never tune the threshold or validate the forecast. Coded, honest closeout is the feedback loop that makes either approach improve. Without it both approaches are permanently frozen at their day-one accuracy.

6. The cost and complexity gap, stated plainly

I will not put invented figures on this, because the numbers swing wildly by asset, region and procurement route. What I can state confidently is the shape of the gap, and the shape is what governs your decision.

CBM cost is dominated by labour and instruments. You buy a handheld analyser or a set of periodic services, you train or hire an analyst, and you spend recurring time collecting and reviewing readings. Adding assets adds collection time roughly proportionally. There is little platform cost, integration is usually just raising work orders in the CMMS you already have, and the whole thing can be scaled up or down without stranding capital.

PdM cost is dominated by infrastructure and skill. Permanently installed sensors per monitoring point, gateways and network coverage into plant rooms and rooftops, a time-series data platform, recurring analytics licensing, integration engineering to get insights back into the CMMS as real work orders, and reliability or data-science capability to keep models and limits honest. Crucially, most of that cost lands before the first prediction arrives, and a meaningful part of it is recurring whether or not the programme finds anything.

The complexity gap is steeper than the cost gap, and it is the one that catches people. CBM has perhaps three things that can go wrong: bad measurement, bad threshold, or no action taken. PdM inherits all three and adds sensor and network reliability, data gaps and irregular sampling, model drift as operating conditions change, integration breakage, and the organisational problem of what to do when the forecast and the engineer disagree. Each of those needs an owner. If you cannot name the person who will own model tuning in year three, you are not ready for PdM. That decision belongs upstream, with the technology and integration architecture, and the IoT integration with CMMS guide sets out what that plumbing actually involves.

7. Condition based maintenance examples you can copy

The abstraction is easier to hold once you see the rule written out. These are the kinds of condition based rules I would expect to find in a sound programme. Each one names the measurement, the limit and the action, which is the minimum for a rule to be usable.

• Chilled water pump, vibration: overall velocity measured at drive-end and non-drive-end bearings on a monthly route. Above the advisory band, shorten the route to fortnightly and take a spectrum. Above the alarm band, raise a planned work order to inspect bearings and check alignment within the stated target days.
• LV switchboard, thermography: annual survey under representative load. Any connection more than the agreed delta above its sibling phases raises a planned retorque at the next available isolation. Anything beyond the danger delta triggers load reduction and same-week action.
• Diesel generator, oil analysis: sample at each scheduled service. Wear metal or viscosity result outside the laboratory's flagged range raises an investigation work order and a resample; two consecutive flagged results escalate to internal inspection.
• Compressed air system, ultrasound: quarterly leak survey on the distribution network. Every confirmed leak above the recording threshold becomes a tagged repair item on a ranked list, worked in descending order of estimated loss.
• AHU filters, differential pressure: continuous reading from the BMS. Filter change is triggered by pressure drop crossing its limit, not by calendar interval. This is the cleanest and cheapest CBM example in most buildings, and it replaces a genuinely wasteful time based task.
• Cooling tower and heat exchanger, performance parameters: approach temperature or heat transfer effectiveness from existing instrumentation. Degradation past the agreed limit triggers a clean, rather than cleaning on a fixed schedule regardless of fouling.
• MV motor, insulation resistance: measured at each planned outage with temperature correction. A polarisation index or resistance value below the agreed floor triggers a winding investigation before return to service.

Look at what those rules have in common. None of them requires a forecast. Every one of them replaces a calendar task with a condition trigger, or replaces a reactive failure with a planned intervention. That is the bulk of the available value, and it is reachable with instruments, discipline and a CMMS you already own.

8. What turning a CBM rule into a PdM rule actually requires

Take the pump vibration example and upgrade it, step by step, so the real cost of the upgrade is visible.

• Measurement frequency: monthly route data is too sparse and too irregular to trend confidently against a fault with a short development period. You need consistent, frequent sampling, which in practice means permanently mounted sensors on that pump.
• Data retention and structure: readings need to land in a time-series store with reliable timestamps and asset identity, not in a spreadsheet per route per month. Broken asset identity is the single most common reason historical condition data cannot be trended later.
• Operating context: a vibration rise means nothing without knowing the speed, load and process conditions at the time. Trending uncontextualised data produces a curve that reflects duty changes rather than degradation, and people then act on it.
• A defensible projection method: straight-line extrapolation to the alarm limit is the honest starting point, and its weakness is well known: real degradation tends to accelerate near the end, so linear projection is usually optimistic. Anything more sophisticated needs either degradation physics for this failure mode or examples of similar pumps that ran to failure.
• A confidence statement: the output must be a range with a stated confidence, not a date. "Projected to reach alarm in four to eight weeks at current duty, moderate confidence, review in two weeks" is usable engineering. A single date will eventually be wrong publicly, and the whole programme pays for it.
• A named owner and a review cadence: someone has to look at the projection, sanity check it against engineering judgement, and re-forecast as new data arrives. Unattended forecasting is worse than no forecasting because it carries unearned authority.

That is six substantial additions to get from "the pump is out of limits" to "the pump will be out of limits in roughly six weeks". Sometimes the extra planning lead time is worth every bit of it, on a single critical asset where an unplanned stop is very expensive and parts have long lead times. Frequently it is not, because the CBM rule was already catching the fault with enough notice to plan the work.

9. Decision guide: which to pursue, by asset class

This is the table I would work through with a client asset register in front of me. The recommendation column assumes CBM is already competent; if it is not, the answer for every row is "fix CBM first".

Applied across a typical register, that guide leaves genuine predictive maintenance justified on a small minority of assets, condition based maintenance appropriate on a large middle band, and calendar based or run-to-failure strategies correct on the tail. The ranking exercise that feeds it is asset criticality work, and if you have not done that properly, the asset criticality classification guide is the prerequisite. The failure-mode reasoning behind the "neither" rows comes from reliability centered maintenance, which exists precisely to stop you monitoring things that cannot be monitored usefully.

10. Where neither approach works, and saying so

Both approaches share a hard limit, and it is worth being blunt about it because a great deal of money is wasted ignoring it. Condition monitoring only works on failure modes that produce a detectable signal over a usable period before functional failure. Where that period is absent or too short to act within, neither CBM nor PdM can help you.

• Sudden failures: a control board failing, a brittle fracture, an electronic component going open circuit. There is no gradual signal to catch. Redundancy, spares holding and design change are the answer.
• Failure modes whose development period is shorter than your monitoring interval: a fault that develops over ten days, monitored monthly, will still arrive as a surprise. This is a real and frequent mismatch, and the fix is either more frequent monitoring or accepting a different strategy, not pretending the coverage exists.
• Hidden failures: a standby function that has already failed but will not reveal itself until called upon. Functional testing finds these, condition monitoring generally does not.
• Assets you cannot safely or economically instrument: buried, submerged, enclosed, hazardous-area or access-restricted equipment. The measurement cost can exceed the failure cost.
• Assets where the organisation will not act on the result: the most common limitation of all, and not a technical one. A condition alert that cannot be converted into executed work because there is no window, no budget line and no spare is a cost with no return.

11. Most organisations calling themselves predictive are doing CBM, and that is fine

Here is the conclusion I have reached from a lot of these conversations, and it is not a criticism. The great majority of programmes branded predictive maintenance are, on inspection, condition based maintenance with trend charts attached. Condition is measured, a threshold decides the action, and a chart on the wall shows how the number has moved. Nobody is producing a calibrated forecast of time to functional failure, and nobody is scheduling work against one.

That is genuinely fine, for three reasons. First, the large majority of the benefit is already captured. Catching a developing bearing fault before it destroys a shaft delivers almost all of its value whether you caught it at a threshold or predicted it eight weeks out. Second, it is dramatically cheaper and more robust. A threshold does not drift, does not need retraining, and does not silently degrade when duty patterns change. Third, it is honest engineering. A defensible statement that this asset is out of limits is worth more than an undefended forecast that it will fail on a specific Tuesday.

The only thing worth correcting is the vocabulary, and only where it causes harm. It causes harm in two places. In procurement, where predictive branding on a CBM capability justifies a price premium that the capability does not warrant. And in expectation setting, where leadership is told it now has failure forecasting, plans on that basis, and is then blindsided when an asset fails between readings, because a threshold system never promised to catch it. Being precise internally about which you have protects you in both places.

The one caution: if you are genuinely going for the prediction layer, whether by trend projection or by anomaly and pattern models, go in knowing it is a different kind of commitment with different failure modes. The anomaly detection and early fault warning guide covers the model-based route and where it is realistic, and the preventive versus predictive versus reactive comparison places both inside the wider strategy mix.

The idea to walk away with

Condition based maintenance is a decision rule: measure the present condition, compare it to a defensible limit, act when it is exceeded. Predictive maintenance is that same rule with a forecast bolted on: project the trend, estimate time to functional failure, and buy yourself planning lead time. The techniques are identical. The sensors are identical. What differs is the data you need, the skills you must keep, the cost you must carry, and the ways it can go wrong.

For most assets in most organisations, CBM done properly is the right answer and the complete answer. Prediction earns its place on the narrow set of assets where you need lead time you do not currently have: long parts lead times, rare shutdown windows, or a failure consequence severe enough that an extra six weeks of notice is worth real money. Everywhere else, the money spent chasing a forecast would return more if it were spent tuning thresholds, fixing measurement consistency, and making sure somebody acts on the alerts you already generate.

Final thoughts

If you take one practical action from this, audit your own programme against the one-sentence test. Look at what your monitoring system actually outputs. If it says "out of limits", you have condition based maintenance, and your improvement path runs through better thresholds, more consistent measurement and faster closeout, not through buying an analytics platform. If it says "will be out of limits by roughly this date, with this confidence", you have predictive maintenance on those assets, and your improvement path runs through validating those forecasts against what actually happened.

Either answer is respectable. What is not respectable, and what costs organisations real money, is not knowing which one you have. Vendors will not clarify it for you, because the ambiguity is commercially useful to them. Clarify it internally, name the approach per asset class honestly, and you will make better decisions about where the next pound of maintenance budget goes than any amount of additional instrumentation will give you. Fix the thresholds, fix the measurement discipline, close the loop into the CMMS, and then, only on the assets that truly need lead time, add the forecast.

Related reading: Predictive maintenance: a practitioner's guide, Preventive maintenance strategies, Preventive vs predictive vs reactive maintenance, Asset criticality classification, Reliability centered maintenance: an introduction, IoT integration with CMMS.