Predictive Maintenance with Machine Learning: When It Pays Off and When It's Just an Expensive Alarm | Blog

# Predictive Maintenance with Machine Learning: When It Pays Off and When It's Just an Expensive Alarm

TL;DR: Without labeled failure history — and most operations in Angola don't have it — no supervised predictive-maintenance model holds up; the realistic alternative is anomaly detection on vibration and other condition signals, and even that only earns its keep when it beats a simple statistical baseline and doesn't flood the maintenance team with false alarms.

A term that has become too vague

"Predictive maintenance with machine learning" now gets used to describe three very different things: a wireless vibration sensor that checks a reading against a fixed ISO 20816-3 threshold, a statistical model that flags deviations from a pump's normal behaviour, and — far less often than the sales pitch implies — a supervised model trained on years of real failure history that estimates days until breakdown (remaining useful life, RUL).

These are three different maturity levels, with completely different data prerequisites. Confusing them is why so many "AI for maintenance" projects in industrial settings end up generating more noise than value. Let's go through each one.

Level 1: condition monitoring based on physical thresholds

This is the honest starting point, and it's what most of the pump and compressor fleet in Angola still doesn't have systematically in place. The international standard ISO 20816-3 (which consolidated the older ISO 10816-3) defines vibration severity zones — A, B, C and D — based on RMS velocity measured on the bearing housing, for machines above 15 kW. Zone A is a newly commissioned machine; Zone D is vibration already severe enough to cause damage and justify a shutdown.

This is not machine learning. It's physics instrumented with a sensor and a threshold table. And in practice, it's where most plants should start before buying anything labeled "predictive AI": if there isn't already consistent collection of vibration, bearing temperature and motor current at a regular cadence, there's no raw material for any model, simple or complex.

Vendors like SKF (Enlight Collect) and Baker Hughes' Bently Nevada (System 1) sell exactly this layer — wireless or hardwired sensors, plus a configurable alarm threshold — and it's a solid base even without any more sophisticated statistical layer on top.

Level 2: anomaly detection — the realistic alternative when there's no labeled failure data

This is where most industrial ML projects should actually land, and where most don't, because "anomaly detection" sounds less impressive in a slide deck than "AI predicts failures."

The underlying problem is easy to state and uncomfortable to accept: a supervised failure-prediction model needs labeled examples of failure — vibration, temperature, pressure, current, all aligned in time up to the exact moment of breakdown, repeated dozens of times per equipment type for the model to generalize. Even in a controlled lab environment, this is rare: the industry's reference dataset for this kind of work, the NASA/PHM Society Prognostics Data Repository's IMS Bearing Dataset, was produced by deliberately running bearings to physical destruction on a test rig — and even then it covers a handful of bearings, not a fleet. That is what a remaining-useful-life label actually costs.

On a real refinery, terminal or platform, nobody lets a process pump run to destruction to generate training data. Failures are rare events, censored (maintenance intervenes before total collapse), and specific to each machine, foundation and load regime. Put plainly: if your operation doesn't have years of labeled failure history aligned to sensor signals, you don't have the data to train a supervised failure-prediction model — and buying a platform that promises exactly that without that history means buying a generic model calibrated on someone else's assets, not yours.

The alternative that actually works with the data most operations already have — time series of vibration, temperature and current, with no failure label — is unsupervised anomaly detection: the model learns what "normal" looks like for that specific pump or compressor, instead of learning what a failure looks like. Isolation Forest and autoencoders are the most commonly used techniques here; a comparative study published on ScienceDirect on anomaly detection in oil and gas sensor data uses exactly these two techniques — KNN and Isolation Forest — on data labeled via moving average, precisely because real failure labels weren't available.

The advantage of this approach: it doesn't need failure examples to get started. The disadvantage, rarely stated in a sales proposal: a deviation from "normal" doesn't automatically tell you which failure mode it is, or how many days remain until breakdown. It says "this is different from how it used to be" — and it's still up to a reliability engineer to interpret whether that's bearing wear, misalignment, cavitation, or simply a legitimate change in operating regime.

The cost nobody discounts in the proposal: false positives

A predictive maintenance alarm isn't free when it fires. Someone has to go to the field, isolate the equipment, inspect it, and only then bring it back into service — time from a reliability team that's usually already stretched thin relative to the asset count, a common pattern across upstream operations in Angola.

A peer-reviewed study published in the journal Sensors (MDPI), a heavy-industry case study on sensor-based predictive maintenance with false-alarm reduction, documents exactly this problem: the method the authors proposed cut false alarms by 90.25% relative to a stand-alone outlier detector, precisely because the version without that extra correlation layer generated too many alarms for the operations team to treat as credible. The paper's central point, and the one worth keeping, isn't the number itself — it's the mechanism: an excess of false positives isn't just wasted time, it's what causes a team to start ignoring alarms, including the real one that shows up three weeks later buried in the noise.

This is alarm fatigue, the same phenomenon the clinical literature documents in intensive care units — and a process unit's control room isn't so different from an ICU in this respect: when the false-positive rate is high, the rational human response is to start distrusting the system, not the equipment.

Why the simple statistical baseline often wins

This is the central argument of this piece, and the part most "predictive AI" vendors prefer not to discuss: a statistical process control (SPC) model — a control chart, an exponentially weighted moving average (EWMA), standard-deviation-based limits on a vibration trend — is frequently competitive with, or better than, a more complex machine learning model, when the available data is limited, noisy, or has few real degradation examples.

A well-regarded academic chapter on applying statistical quality control methods to predictive maintenance ("Predictive Maintenance 4.0") explores exactly this idea: SPC control charts, including EWMA — designed decades ago to detect small process shifts — apply directly to condition monitoring, and the more recent literature tends toward hybrid architectures (SPC upstream, ML only where it adds proven value), not replacing one with the other.

The practical reason behind this is easy to explain to a CFO: a machine learning model with few parameters and a well-calibrated control chart tend to generalize better with limited data than a neural network or a complex ensemble, which needs far more examples to avoid learning noise specific to the training period (overfitting). When the available history spans months, not years, and when each pump has its own "normal" vibration signature, the added complexity of a sophisticated model frequently doesn't translate into fewer false positives — it translates only into less explainability for the maintenance team that has to decide whether to send someone to the field.

An honest checklist before you buy

Question	If the answer is "no"
Is there already consistent vibration/temperature/current collection, at a regular cadence, for at least a few months?	Start at Level 1 (physical thresholds, ISO 20816) before talking about ML
Are there labeled failure records aligned in time with sensor data, for multiple events of the same equipment type?	You don't have the data for a supervised failure-prediction model — focus on anomaly detection instead
Can the reliability team investigate every pilot alarm without ignoring some due to overload?	The first project will die from alarm fatigue before it proves any value
Have you already tested a simple control chart (EWMA, standard-deviation limits) on the same time series?	Run that test first — it's days of work, not months, and gives an honest baseline to measure any more complex model against
Is the asset critical and expensive enough to justify the engineering cost of a dedicated data pipeline?	A cheap spare pump doesn't justify the same engineering investment as an export compressor with no redundancy

Where it actually pays off

This isn't an argument against machine learning in maintenance — it's an argument against buying it before you have the data foundation to support it. Investing in more sophisticated models makes sense when: there's a fleet of similar assets (multiple pumps of the same model, multiple compression units), which allows learning shared degradation patterns even with few failures per unit; there's already a mature, reliable data collection layer in place (not a three-month proof of concept); and there's a reliability team with the capacity and discipline to act on the alarms generated, including the false ones, without losing trust in the system.

Wise Hustlers builds and operates the maintenance and MRO module of its own oil & gas ERP — work orders, asset history, preventive maintenance plans, and the field-event log that any anomaly-detection model needs as raw material. The most underestimated part of such a project is never the algorithm. It's the data pipeline: making sure a wireless sensor's vibration reading arrives clean, correctly timestamped, tied to the right asset, and cross-referenced against the work order that confirms whether something actually failed in that window. Without that data discipline, no model — simple or complex — has anything to learn from. That's the data engineering and model-integration work we do through our machine learning service, usually starting with anomaly detection on data an operation already collects, before any conversation about more advanced predictive models.

Frequently asked questions

Without failure history, is it still worth installing vibration sensors?

Yes — but the immediate goal isn't "predict failures," it's establishing a reliable baseline of normal behaviour per asset. That baseline is the prerequisite for both anomaly detection and, later, any supervised model, if and when enough failure history exists.

Does an anomaly-detection model replace vibration analysis by an experienced reliability technician?

No. It flags that something changed; identifying what changed — misalignment, bearing wear, cavitation, looseness — still requires human interpretation of the vibration spectrum, or an additional diagnostic layer trained specifically for that.

How much history is needed before a project like this makes sense?

It depends on the equipment's natural degradation cycle, but as a practical reference: less than a few months of consistent data usually isn't enough even for a robust control chart, let alone a reliable anomaly model. Start collecting now, even if the ML project only kicks off later.

Is it worth comparing platforms like Augury, SKF or Baker Hughes' System 1 against a custom-built solution?

It depends on fleet scale and homogeneity. Platforms like Augury (now also integrated into Baker Hughes' System 1 offering) or SKF Enlight bring sensors, infrastructure, and models already calibrated across thousands of similar machines from comparable manufacturers — a real advantage for standard equipment. A custom solution pays off when the equipment, the operating regime, or the integration with the existing ERP and work orders is specific enough that a generic model won't serve it well.