Predictive maintenance does not start with AI

The marketing version of predictive maintenance is simple: fit a few sensors, let the AI learn the machine, and it will warn you before anything breaks down.

Reality is less magical — but far more useful.

Machine learning can indeed recognise relationships and changes that would be hard to handle with simple thresholds. But only if the engineering, data acquisition and operational foundations are in place first.

That is why predictive maintenance does not begin as an AI project. It begins with a very specific question:

Which failure do we want to detect earlier, and what physical phenomenon precedes it?

You do not monitor “the machine” in general

A motor, pump or gearbox can fail in many different ways. Bearing wear, imbalance, lubrication problems, overload, insulation faults and insufficient cooling each leave a different signature.

The first step is therefore to define the failure modes and their consequences. You need to know:

• what can go wrong;
• how often it happens;
• how much downtime or damage it causes;
• whether it can be detected in advance;
• how much time is available to intervene;
• which measured signal carries usable information.

Without answers to these questions, it is easy to end up with expensive data collection that produces plenty of curves but supports very few maintenance decisions.

The right sensor matters more than an impressive model

Common data sources in industrial condition monitoring:

• vibration and acceleration;
• temperature;
• electrical current, voltage and power;
• acoustic signals;
• pressure and flow rate;
• rotational speed;
• humidity or other ambient parameters.

What matters, however, is where the sensor is placed, in which direction it measures, how it is mounted, and what its sampling rate, measuring range and noise level are.

A poorly mounted vibration sensor can do more harm than a weaker algorithm: the model will consistently learn from bad data. The same applies to an unsuitable current transformer, a slow temperature measurement or an acoustic signal isolated from its process context.

Sampling has to match the phenomenon

A slowly changing bearing temperature may be adequately monitored at intervals of a second or a minute. Spectral analysis of vibration, on the other hand, requires sampling that is orders of magnitude faster.

Sample too rarely and the relevant phenomenon disappears. Sample far more often than necessary and you needlessly increase data traffic and processing costs.

This is where edge processing can be particularly useful. The local device can calculate features from the high-frequency raw signal — such as RMS, peak value, kurtosis or energy in specific frequency bands — and send only how these change over time to the central system.

First, learn what normal operation looks like

A machine’s data is not normal or faulty in itself. The same current draw can mean different things at idle, at full load, during start-up or in a cleaning cycle.

Reliable condition assessment therefore requires operating context:

• current load;
• operating mode;
• product or recipe;
• ambient temperature;
• shift;
• maintenance status;
• start-up and shutdown events.

A baseline is not a single average value. It is the multidimensional range of normal operation, which may differ from one operating situation to another.

Without data quality, AI is confidently wrong

Real industrial data is incomplete, noisy and sometimes contradictory. A sensor replacement, a communication outage, a wrong timestamp, a firmware update or a changed process setting can all break a time series.

You need to handle:

• missing samples;
• duplicated data;
• error codes recorded as measured values;
• changes in scaling;
• time synchronisation problems;
• sensor drift;
• the new baseline after maintenance.

AI does not fix these problems automatically. If they go undetected, the model may even learn that a communication fault is a sign of an impending bearing failure.

Supervised machine learning is not always required

In industry, well-labelled failure events are often scarce. That makes sense: fortunately, not every machine breaks down a hundred times with every circumstance precisely documented.

Several approaches can therefore be considered:

• engineering thresholds and rule sets;
• statistical trend and change detection;
• unsupervised anomaly detection;
• condition estimation;
• supervised classification, if suitable labelled data is available;
• remaining useful life estimation, if the underlying data genuinely makes it possible.

A good solution is not advanced because it uses the most complex model possible. It is advanced because it supports the maintenance decision at the right time, with an acceptable false alarm rate.

Business value begins after the alert

An anomaly score does not repair anything on its own. You need to define what happens next:

• who receives the alert;
• what additional data they can see;
• what severity level the event is assigned;
• whether an on-site inspection is needed;
• whether a work order is opened;
• how the diagnosis and the outcome of the repair are fed back into the learning process.

This is precisely where OrigSmart is strong: handling the whole chain. From the design of sensors and gateways, through time-series data processing and automated analysis, to the maintenance task and the feedback loop, the same system can tie the process together.

Sources

• NIST – Smart Manufacturing Systems Design and Analysis Program
• NIST SP 800-82 Rev. 3 – Guide to Operational Technology Security
• OrigSmart – Assets and operations