What is machine learning for maintenance?

It is the use of algorithms trained on sensor data and failure history to predict equipment problems before they occur. Rather than servicing on a fixed schedule, the models estimate how much life a machine has left or which failure is developing, so maintenance is timed to the machine's actual condition.

What is remaining useful life (RUL)?

RUL is an estimate of how much time or how many cycles an asset has before it crosses a failure threshold. A regression model predicts it either directly from current sensor readings, or indirectly by modeling the degradation trend and extrapolating forward to the failure point.

What is the difference between regression and classification in maintenance ML?

Regression predicts a continuous number, such as remaining useful life, 'how long do we have?' Classification predicts a category, such as healthy versus failing or a specific failure mode, 'what is wrong?' Most maintenance machine learning is one of these two tasks.

How is ML-based maintenance different from preventive maintenance?

Preventive maintenance triggers work on a fixed interval regardless of condition, so it services healthy machines early and misses ones failing fast. ML-based maintenance triggers work on a prediction from live sensor data and history, putting effort where the machine actually needs it.

What data does machine learning for maintenance need?

It needs sensor streams (vibration, temperature, current, oil, plus process context), and critically, a history of past failures with labels marking which records preceded a failure and which mode. Labels are the scarcest and most valuable ingredient; without failure history, a supervised model cannot learn the pattern.

What if we have no failure history to train on?

That is the common starting point. Teams often begin with unsupervised anomaly detection, which learns what normal looks like and flags deviations without labeled failures. It gives fewer precise diagnoses but produces value while a labeled failure history accumulates for supervised models later.

Does machine learning replace maintenance technicians?

No. It focuses their time. A model points to the machines that actually need attention and, at best, to the likely fault, so scarce technician hours go where they matter. People still diagnose, plan, and do the work, and someone must own and maintain the model itself.

Machine Learning for Maintenance

How models predict remaining useful life and classify failures from sensor data, and where that beats a fixed maintenance schedule, and where it does not.

Machine learning for maintenance uses algorithms trained on sensor and failure history to predict equipment problems before they happen. Instead of following a fixed schedule, models estimate how much life a machine has left or classify which failure is developing, so repairs are timed to the machine's actual condition rather than the calendar.

That shift, from a schedule to a prediction, is what separates machine learning from the rule-based maintenance most plants run today. This guide covers the two core prediction tasks (remaining useful life and failure classification), the sensor features models learn from, how an ML model gets built and validated, and where it beats a fixed schedule and where it does not.

How is ML-based maintenance different from rule-based PM?

Rule-based preventive maintenance replaces or services parts on a fixed trigger, every 500 hours, every 90 days, every 10,000 cycles, regardless of how the machine is actually doing. It is simple and it works, but it is blind: it services healthy machines too early (wasting parts and labor) and misses machines degrading faster than the schedule assumes. Machine learning replaces the fixed trigger with a prediction based on the machine's real condition and the patterns in its history.

	Rule-based PM	ML-based maintenance
Trigger	Fixed interval (time, cycles, usage)	Predicted condition or remaining life
Uses	A schedule set once	Live sensor data plus failure history
Failure it misses	Anything faster than the interval	Failure modes absent from its training data
Wasted work	Servicing healthy machines early	Less, if the model is accurate and trusted
Needs	An interval and discipline	Data, labels, features, and someone who owns it

Rule-based PM follows a schedule; ML-based maintenance follows the machine's condition and history.

This is the data-driven end of condition-based maintenance and the engine behind serious predictive maintenance. It does not throw away the schedule for everything, a cheap, non-critical component is fine on a calendar, but for critical assets with real failure cost, a good model puts the work where it is actually needed.

What does ML actually predict? RUL and failure classification

Almost all maintenance ML reduces to two task types, and knowing which one you are doing shapes everything else. One predicts a number; the other predicts a category.

Regression, remaining useful life (RUL). The model outputs a continuous number: how much time or how many cycles until the asset crosses a failure threshold. RUL answers "how long do we have?"
Classification, failure detection and diagnosis. The model outputs a category: healthy or failing, or which specific failure mode is developing (bearing wear, imbalance, misalignment). Classification answers "what is wrong, and is it failing?"

Remaining useful life. A regression model estimates how far the machine is from the failure threshold.

RUL is usually predicted one of two ways. The direct approach maps current sensor readings straight to a remaining-life number. The indirect approach models the degradation trend first, then extrapolates it forward to the failure threshold; the length of that extrapolation is the RUL. Both need examples of machines that ran to failure so the model can learn what the road to failure looks like. This is why RUL is genuinely hard in practice: healthy, well-maintained plants deliberately avoid running assets to failure, which starves the model of the very examples it needs. Teams often bootstrap with accelerated-life tests, physics-based degradation models, or public benchmark datasets until enough real failures accumulate.

What sensor features do the models learn from?

Models do not learn from raw waveforms so much as from features extracted from them, compact numbers that carry the signal of degradation. The same condition-monitoring streams that feed human analysts feed the model:

Vibration is the richest source: time-domain features like RMS and kurtosis, and frequency-domain features from an FFT, including the specific defect frequencies that flag bearing and gear faults.
Temperature trends and thermal patterns that rise as friction or electrical resistance grows.
Motor current signatures that reveal electrical and mechanical faults without a separate sensor.
Oil analysis wear-metal counts and contamination that track internal degradation.
Process context load, speed, ambient conditions, so the model can tell a real problem from a machine simply working harder.

Feature engineering is where domain knowledge earns its keep. A model handed a defect frequency that a reliability engineer knows matters will learn faster and generalize better than one left to find everything from scratch. Good features are often worth more than a fancier algorithm.

The ML maintenance pipeline. The last step, turning a prediction into acted-on work, is the one plants most often skip.

How is an ML maintenance model built?

A maintenance model is not a product you switch on; it is a pipeline you build and maintain. The steps are consistent across assets:

Collect data with history. Gather sensor streams and, critically, records of past failures. Without run-to-failure examples, a supervised model has nothing to learn the failure pattern from.
Label the data. Tag which records preceded a failure and, ideally, which failure mode. Labels are the scarcest and most valuable ingredient in industrial ML.
Engineer features. Turn raw signals into the RMS, spectral bands, trends, and ratios that carry the degradation signal, using reliability knowledge to choose them.
Train the model. Fit a regression model for RUL or a classifier for failure mode on the labeled, feature-rich data.
Validate honestly. Test on machines and periods the model never saw, and judge it on cost, a missed failure and a false alarm are not equally expensive.
Deploy into the workflow. A prediction that does not become a work order changes nothing. Wire the output into the CMMS and the people who act.
Monitor and retrain. Machines, sensors, and processes drift; a model that was accurate last year quietly degrades. Watch its accuracy and refresh it.

When failure labels do not exist yet, the common starting point, teams often begin with unsupervised anomaly detection which learns "normal" and flags deviations without needing labeled failures. It generates fewer precise diagnoses but starts producing value while the labeled history accumulates.

Where does ML for maintenance actually pay off?

ML pays off on critical, expensive assets that fail in ways sensors can see and history can teach. A high-value pump, motor, gearbox, or spindle whose failure stops a line and whose degradation shows up in vibration or current is an ideal candidate. The math is simple: the model has to save more in avoided failures and better-timed work than it costs in sensors, data work, and upkeep.

There is a sequencing lesson buried in that math. The assets worth modeling are usually the ones a plant already worries about, the recurring bad actors that show up again and again in the downtime record. That is the honest way to pick a first model: not the newest asset or the flashiest sensor, but the one machine whose failures have hurt the most and whose warning signs are measurable. Prove the model there, on an asset the team already understands, and you earn the credibility to expand. Start with a moonshot across the whole plant and you will drown in data work before a single prediction lands.

It does not pay off everywhere. Cheap components, assets with no failure history, and failure modes that give no measurable warning are poor fits, a fixed schedule or run-to-failure is often the rational choice there. And every model rests on prerequisites the demos skip: instrumented assets, a real failure history, features someone engineered, and an owner who keeps it current. ML bolted onto a plant that cannot yet say which machines stopped last night, or why, will fail, not because the algorithm is wrong, but because it is starving for the data underneath.

That data foundation is the real first step, and it is where an operational layer earns its place. Before a model can predict anything, a plant needs its machine signals, downtime reasons, and maintenance history in one place and trustworthy. That is the wedge Harmony takes as a manufacturing operating system: read what your PLCs already produce, capture the paper and tribal knowledge that hold the failure context, and connect what you run with no rip-and-replace, the way plants like CLS made their records live. From there, machine learning, broader smart-factory analytics, and agentic AI have clean inputs to work from instead of guesses.