Predictive maintenance: what it is, examples and how to start

What predictive maintenance is

Machines rarely fail without warning. A wearing bearing vibrates more for weeks before it seizes, a clogging filter pushes up the differential pressure, a motor under strain draws more current. Predictive maintenance measures these signals, compares them with the machine's normal behaviour and schedules the work when the degradation becomes visible, before it turns into a stop.

The standard on maintenance terminology (EN 13306) treats it as condition-based maintenance carried out following a forecast, derived from repeated analysis of the degradation parameters. The difference from condition-based maintenance is one of degree: condition-based acts when a value crosses a limit, predictive also tries to estimate how much time is left. Many people use the two terms interchangeably, and that is fine as long as it is clear what is measured and who decides.

The aim is not to do away with preventive maintenance but to move part of the work from the calendar to the actual condition: a component is replaced when it needs to be, not too early and, ideally, not too late.

Four strategies compared

The strategies are not mutually exclusive: in a plant they coexist, and the choice is made asset by asset, depending on what a failure costs and how well you can see it coming.

Which signals are used and what they reveal

The signal follows from how the component fails, not from the sensor you happen to have. These are typical examples, not a complete list.

Currents, temperatures, pressures, cycle counters and states are often already in the PLC; vibration and oil analysis usually need an extra sensor or sampling. The RMS value of vibration is enough to follow a trend; telling a bearing defect from an imbalance takes the spectrum, the signal broken down by frequency.

The P-F curve: from the first sign to the failure

The P-F curve describes how a component deteriorates. Point P (potential failure) is when the degradation becomes detectable with a measurement; point F (functional failure) is when the component no longer does its job. The time between them is the P-F interval: the window in which the work can still be planned.

For many mechanical failures the signs appear in a recurring order: first ultrasound and the vibration spectrum, then particles in the oil, then overall vibration and noise, and finally heat. By the time a bearing is hot, the window has almost closed. The interval ranges from weeks or months for a slowly wearing bearing to minutes for many electrical faults.

• Check more often than the P-F interval: a common rule of thumb is to inspect at intervals no longer than about half the interval; continuous measurement removes the problem altogether.
• Pick the signal that shows up first: the further from F you see the degradation, the more time you have to order the spare and stop at a convenient moment.
• Accept that not everything has a point P: failures with no measurable warning call for redundancy, spares or another strategy, not a model.

Thresholds, anomalies and remaining life

Different approaches go under the same name, and they need different data and skills.

• Thresholds: a fixed or statistical limit on a signal, for example a bearing above 80 °C for more than ten minutes. A statistical threshold is derived from normal behaviour, like the limits of a control chart. It is simple, fits in one sentence and already covers many useful cases.
• Anomaly detection: a model learns how the machine behaves when it is healthy, possibly on several signals together, and flags when the data moves away from it. It needs no failure examples. It tells you something has changed, not what or when it will break.
• Remaining useful life (RUL): a model estimates how much time or how many cycles are left before the limit. It is the closest to the idea of predicting, but it needs many degradation episodes followed to the end, which are rare in a small or mid-size company.

A health index, which combines several deviations into one value from 0 to 100, sits between the first two: it reads at a glance and helps decide which machines to look at first. Either way the result is an estimate: the decision to stop the machine stays with the people who know it.

What data you need, and why failures are few

• A suitable reading rate: a temperature can be read every minute, a pressure every few seconds; for vibration, values already computed by the sensor are usually read.
• The context: high current at full load is normal, at idle it is not. Without machine state, product or load, the comparison with normal mixes different situations.
• Stable names and units, the same on every machine and across the whole history.
• A usable maintenance history: date, component, failure mode and what was done, not just «repaired».

The most common obstacle is the last point. A well-kept machine has few failures, each with its own causes: two or three episodes a year are not enough to train a model that recognises the failure. That is why it pays to start with thresholds and anomalies, which learn what normal looks like rather than what failure looks like, and to record every intervention in a structured way from now on: a year from now that history will be worth more than any model chosen today.

How to start in a small or mid-size plant

You do not need a plant-wide project: start with one machine and widen the scope after a first result.

• Pick one critical asset: it stops the department when it fails, has long repairs or expensive spares, and fails in known ways. Compressors, pumps and gearboxes are frequent candidates.
• List with the maintenance team how it fails: components, symptoms, warning time. That tells you which signals you need.
• Connect the signals: first the ones the PLC already has, read over Modbus TCP or OPC UA (the guide Modbus or OPC UA helps you choose), then a sensor where the one that matters is missing. A machine interconnected for Industry 4.0 often exposes much of the data already.
• Set thresholds first, a few of them, each with an owner who knows what to do and has the time to do it.
• Add a model after a few months, once the history shows what normal looks like in the different conditions: anomalies or a health index, and only later, if the data allows, remaining life.
• Record the outcome of every warning: useful intervention, false alarm, no action. It is what lets you tune thresholds and models and say whether the project pays.

How to measure whether it pays off

Use the usual maintenance numbers, before and after on the same asset, with a baseline set before you start.

• Unplanned stops: how many and the hours lost, the main indicator.
• [MTBF and MTTR](/guide/mtbf-mttr): MTBF tends to rise, because part of the failures become planned work; MTTR often falls, because the spare is already there.
• Planned work, overtime and emergency call-outs against total maintenance hours.
• Spare parts: fewer rush orders and, sometimes, less stock.
• Warnings that lead nowhere: too many false alarms use up people's trust before the budget.

Worked example: the sums on a compressor

A compressor supplies air to the whole department: when it stops, production stops. It is planned for 6,000 hours a year and has six unplanned stops a year, averaging 5 hours each. The figures are an example.

The hypothesis is that half of the failures give signs early enough to become planned work during the weekend shutdown. It is something to test on your own machine, not an industry average.

MTBF goes from (6,000 − 30) ÷ 6 = 995 hours to (6,000 − 15) ÷ 3 = 1,995 hours, because the planned work falls in the shutdown. Availability with respect to failures rises from 99.5% to 99.75%.

Weigh the result against the cost of sensors, installation, software and the team's hours to follow the warnings. Run the sums again with a cautious hypothesis, only one failure in six caught early, which brings the difference down to €6,900 a year: if the project only holds up with the optimistic hypothesis, the asset to start from may be a different one.

Common mistakes

• Starting from the model instead of the problem: choosing an algorithm before knowing which failure you want to see and with which signal.
• Covering the whole plant at once: many assets, few results, and the project loses credibility.
• Warnings without an owner, or too many warnings: either way people stop reading them.
• Not closing the loop: without the outcome of each intervention, thresholds and models do not improve and nobody knows whether the project pays.
• Dropping basic preventive work: lubrication, cleaning and tightening are still needed. Predictive maintenance adds to them; it does not replace them.

Where Muvia Industrial fits

With Muvia Industrial the edge node next to the machine reads the PLCs with its Siemens S7, OPC UA and Modbus TCP drivers and keeps the readings in a local buffer if the network drops. In the cloud, ready-made analysis computes the deviation from normal, the health index recipe combines several measures into a value from 0 to 100, and predictors flag anomalies or estimate the probability that an episode starts within a horizon; a model your team trained can also run next to the data. Thresholds can be tried on the past before they are switched on, and every alarm has its register and can arrive with a few hypotheses about its causes.

It is not a turnkey module: Muvia provides the pieces with which your team builds rules and models on its own machines, and how many failures they catch early depends on the machine and on its history. The path is in the use case anomalies and predictive maintenance and, on one machine from the first signal to the repair, in the article on predictive maintenance on a compressor.