What predictive maintenance is
Predictive maintenance is the strategy of deciding when to service equipment based on its actual condition, measured with data, rather than on a fixed calendar or after it breaks. The idea is simple: most mechanical and electrical failures give warning before they happen. A worn bearing vibrates differently; a motor with insulation problems runs hot. If you measure those signals and know how to read them, you can schedule the repair at the right moment: not too early, replacing parts that still had life in them, and not too late, with the line down.
Predictive maintenance with AI adds a layer. Instead of a technician reviewing charts against fixed thresholds, a model learns how each asset behaves when it is healthy, detects when it drifts from that pattern, and estimates how much time is left before a failure. AI does not replace the maintenance team. It warns them earlier and tells them where to look.
The four types of maintenance
Before getting into techniques, it helps to place predictive maintenance among the other strategies. In practice, a plant combines several of them depending on the asset.
| Type | When you intervene | Advantage | Limitation |
|---|---|---|---|
| Reactive (corrective) | After the equipment has failed | No planning or upfront investment | Unplanned downtime, collateral damage, costly emergencies |
| Preventive | On a schedule or by run hours, regardless of condition | Easy to plan and audit | Healthy parts get replaced and failures still happen between visits |
| Predictive | When the asset's data shows degradation | You intervene only when needed, and ahead of time | Requires sensors, reliable data, and someone to interpret it |
| Proactive | On the root cause, so the failure does not recur | Removes underlying causes (misalignment, lubrication, design) | Requires root cause analysis and process changes |
Preventive vs predictive maintenance
Preventive says "replace the bearing every six months." Predictive says "this specific bearing has started to degrade, plan to replace it in the next few weeks." Preventive treats every asset of a kind the same; predictive looks at each one. They are not mutually exclusive: predictive is added on the assets where a surprise failure is expensive.
Proactive maintenance uses what predictive learns to go after the cause. If the model shows that the same pump wears out its bearings every few months, the proactive question is why: misalignment, the wrong lubricant, or operation outside its design conditions.
Predictive maintenance techniques
These are the five most common condition monitoring techniques. Each one catches a different kind of failure, so a single technique is rarely enough.
- Vibration analysis. The reference technique for rotating equipment: motors, pumps, fans, compressors, gearboxes. Each defect (imbalance, misalignment, looseness, bearing damage) leaves a signature at specific frequencies. It is measured with permanently mounted accelerometers or with periodic route-based readings.
- Infrared thermography. A thermal camera reveals hot spots that point to loose electrical connections, excessive friction, degraded insulation, or leaking steam traps, without stopping the equipment.
- Ultrasound. Picks up high-frequency sound produced by friction, compressed air or gas leaks, partial electrical discharges, and early-stage bearing faults, sometimes before they show up in vibration.
- Oil analysis. A lubricant sample reveals wear particles, contamination (water, dust), and degradation of the oil itself. It is key for engines, gearboxes, hydraulic systems, and transformers.
- Motor current analysis. Analyzing the current and power a motor draws can reveal mechanical and electrical problems without installing anything on the machine, just by measuring at the electrical panel.
On top of these, many plants already log process variables in their SCADA or PLC systems: pressure, flow, process temperature, speed, run hours. For an AI model, those variables are as valuable as dedicated sensors.
How AI predictive maintenance works
The classic approach relies on thresholds: if vibration goes above a set value, an alarm fires. It works, but it has two problems. A fixed threshold cannot tell the difference between an asset running harder because production went up and one that is failing. And by the time a value crosses the threshold, the failure is often well advanced.
AI addresses both problems in three ways:
- Anomaly detection. The model learns each asset's normal behavior across its operating conditions (load, speed, ambient temperature) and flags deviations from that pattern, even when no single variable has crossed a limit. It does not need a long failure history: data from the healthy asset is enough to start.
- Failure classification. When there is a record of past failures, the model learns which data patterns precede each failure type and can suggest the likely cause: bearing, misalignment, electrical fault.
- Remaining useful life estimation. With enough degradation history, the model estimates how much time or how many run hours a component has left. That is what lets you plan the intervention around a scheduled shutdown or the arrival of a spare part.
The output is not a black box that decides on its own. It is a prioritized alert that reaches the maintenance lead with the asset, the signal that changed, since when, and how serious it looks. The decision to intervene stays with people.
What data you need
You need three kinds of data, and much of it often already exists:
- Condition data: vibration, temperature, current, pressure, whatever fits the asset type. It can come from new sensors or from those already feeding the plant's SCADA or historian.
- Operating data: when the asset was running, at what load, and what product was being made. Without this context, the model mistakes a production change for a fault.
- Maintenance history: work orders, recorded failures, and replaced parts, with dates. It usually lives in a CMMS, in the ERP, or in spreadsheets.
Maintenance history is usually the weak link: work orders logged days late, failures described as "not working," approximate dates. It does not need to be perfect to start, but part of the initial work is cleaning it up and, from then on, logging every intervention with a minimum of rigor.
How to get started: begin with one critical asset
The most common mistake is trying to monitor the whole plant from day one. The path that works is narrower.
- Pick one critical asset. One whose failure stops production, has no backup, is expensive to repair, or has long lead times for parts. Even better if it has failed before and those failures were recorded.
- Define the failure you want to anticipate. Not "keep it from breaking," but a concrete failure mode: main motor bearings, gearbox overheating, loss of pump performance.
- Map the data that already exists. Install only what is missing to measure the chosen failure mode.
- Collect data over a representative period. It should cover the different operating conditions: shifts, products, seasons if they matter.
- Build and validate the model (see the next section).
- Decide what happens with each alert. Who receives it, through which channel, what they check first, and how they record what they found. An alert without a procedure ends up ignored.
- Measure, then scale. With results on the first asset, replicate on similar equipment.
How to validate the model against the past before trusting it
No model should send alerts to the plant floor before proving it works on real data. The most direct method is backtesting: train the model on data up to a certain date, then run it over the following period, which the model has never seen, as if it were live. Then compare what it would have said with what actually happened.
The questions a backtest answers are concrete:
- How many of the real failures would it have caught? If there were five failures in the period and the model flagged two, that is what will happen on the floor.
- How far in advance? An alert two hours ahead lets you shut down in an orderly way; an alert three weeks ahead lets you order the part. The value depends on that lead time.
- How many false alarms would it have raised? This is the most underestimated number. If the model alerts every week and there is almost never anything wrong, the team stops looking within a month.
- Does it beat what you do today? The model has to outperform the current preventive plan or the judgment of your most experienced technician. If it does not, it is not ready.
When the history has few failures, validation is complemented by a shadow period: the model runs live for a while, its alerts are reviewed with the maintenance team without triggering work orders yet, and it is tuned based on what they find.
When predictive maintenance is not worth it
Predictive maintenance is not for every asset:
- Cheap, non-critical equipment with spares on hand or installed redundancy. Run-to-failure or simple preventive maintenance makes more sense there.
- Failures that give no warning. Some failures are random and sudden, with no measurable degradation beforehand. No model predicts what leaves no signal.
- No way to act on the alert. If there are no people, parts, or windows to intervene, anticipating the failure does not change the outcome.
- No data and no intention to record it. If there is no history and operations are not willing to log interventions, start by organizing maintenance before bringing in AI.
Predictive maintenance software or a custom model
There are two paths, and both are valid depending on the case.
Off-the-shelf predictive maintenance software comes in two forms: predictive modules inside maintenance management systems, and platforms that sell sensors bundled with their own models. It makes sense when your equipment is standard (common motors, pumps, compressors), you want to start fast, and you are comfortable working within the vendor's logic and data.
A custom model makes sense when the data already exists but is spread across SCADA, the historian, the ERP, and spreadsheets; when your equipment or process is specific and a generic model does not understand it; or when you want the data and the model to belong to your company, run in your own cloud, and integrate with your systems without depending on a license. This is data engineering and analytics work: integrating sources, cleaning up the history, building the model, validating it against the past, and putting alerts to work inside operations.
You can also combine them: off-the-shelf software for standard equipment and a custom model for the asset that defines your output.
Where to start
If you have an asset whose failure worries you and you are not sure whether the data you already have is enough to anticipate it, the first step is not buying sensors. It is reviewing what information exists, which failure matters, and whether the case justifies a model. At Axlan we run that assessment at no cost: tell us about the asset and we will tell you what data would be needed, what you can reuse from what you already have, and whether predictive maintenance makes sense for you.