Reactive
Run until it breaks. Cheapest to plan, most expensive to live with: the stop lands at the worst moment, the part is not on the shelf and the line restarts with scrap.
Predictive maintenance
Predictive maintenance in manufacturing: what it is and how it works
Predictive maintenance uses the data a machine already produces to estimate when it will fail, so the repair happens in a planned window instead of in the middle of a shift. This guide explains the definition, the technologies behind it, what it costs, what it returns and how to start on one line.
Short answer
Predictive maintenance is a maintenance strategy that predicts the failure of a specific asset from its own measured behaviour — vibration, temperature, motor current, cycle time drift, alarm patterns and maintenance history — and schedules the intervention shortly before the failure would occur. It differs from reactive maintenance, which waits for the breakdown, and from preventive maintenance, which replaces parts on a calendar whether they need it or not.
Reactive, preventive, predictive
Preventive
Replace on a calendar or a running-hours counter. Safer, but it throws away component life on machines that were fine and still misses the ones degrading faster than average.
Condition-based
Act when a measured value crosses a threshold. Better, but a fixed threshold is a generic rule applied to a specific machine, so it fires late on some assets and cries wolf on others.
Predictive
Learn the normal behaviour of each asset and detect the drift away from it, with an estimated time to failure. The threshold is the machine's own history, not a number in a manual.
The Atherya approach: context before algorithms
Most predictive maintenance tools drop an algorithm on top of each machine and let it learn from raw signals alone. The result is a system that sees deviations without knowing what they mean — and turns them into false alarms the team learns to ignore. Atherya works the other way around: before any prediction, we build a context, a living knowledge of each machine, of how the team around it actually works, and of the environment the machine runs in. The algorithm reads its signals against that context, which is what annihilates false alarms instead of multiplying them.
What the system learns during onboarding
The only way these algorithms work is to let them know the machines deeply. During onboarding the system builds that knowledge itself, and every alert it later raises is judged against it — and proposed to a person for sign-off, never applied silently.
Machine defects
The known flaws and recurring failure modes of each asset, so a deviation that matches a harmless quirk of that machine stays quiet instead of paging someone at 3 a.m.
Vulnerabilities
The weak points where this specific machine degrades first — the bearing that runs hot, the axis that drifts under load — so attention concentrates where failure actually starts.
How the team works
Shifts, habits, changeover patterns and how the crew actually runs the line. A signal that looks anomalous to a generic model is often just the night shift doing things its own way.
The environment around the machine
Ambient temperature swings, humidity, the upstream line feeding it, the product mix of the week. The same vibration reading means different things in July and in January.
The technologies behind it
Vibration analysis
The classic signal for rotating equipment. Bearing wear, misalignment and imbalance show up in the spectrum weeks before the noise is audible.
Thermal and electrical signals
Temperature rise and motor current signature analysis reveal friction, load anomalies and winding problems, often from data the drive already exposes.
Process and cycle data
Cycle time drift, micro-stops and alarm sequences from PLC, SCADA and MES are the most underused predictive signals in a plant, and they need no new hardware.
Machine learning models
Anomaly detection learns each asset's baseline; supervised models learn the signature of failures you have labelled. Both need history, which is why the first step is always the archive.
IIoT and edge collection
Where a signal genuinely does not exist yet, a sensor and a gateway add it. This is a targeted addition on a few critical points, not a plant-wide retrofit.
Maintenance history
Work orders, spare part consumption and repair notes turn a statistical anomaly into a named failure mode a technician recognises.
Benefits you can measure
Fewer unplanned stops
The failures with a slow degradation signature become planned jobs. The sudden ones stay sudden, and no honest vendor promises otherwise.
Longer component life
Parts are replaced when their condition says so, not when the calendar does, which recovers the life preventive schedules throw away.
Cheaper interventions
A planned repair uses normal hours, stocked parts and a controlled restart. The same repair as an emergency typically costs several times more.
A maintenance window that fits production
The value is not only knowing that a bearing will fail. It is placing the fix where it costs the least output, against real orders and shifts.
How to calculate the ROI
The honest way to size the return is to start from failures that already happened. Take the twelve months behind you, list the unplanned stops on one critical line, and for each one write down three numbers: hours of downtime, lost output valued at contribution margin, and the emergency cost of the repair itself (overtime, express parts, scrap at restart). Add them up: that is the exposure. Predictive maintenance does not remove all of it — assume it catches the failures with a slow signature, typically half to two thirds of them, and that catching them converts an emergency repair into a planned one at roughly a third of the cost. Compare that number with the annual cost of the software plus the internal hours to run it. If the payback is not visible on one line in the first year, start smaller instead of starting bigger.
How to start on one line
1. Pick the line that hurts
One line, one bottleneck, the three failure modes that caused the most downtime last year. A pilot spread across the whole plant proves nothing in either direction.
2. Inventory the signals you already have
Before buying a sensor, list what PLC, SCADA, MES and CMMS already record and for how long. Most plants discover they are sitting on more usable history than they expected.
3. Validate on failures you already know
Replay the model over past breakdowns. If it would not have warned you before the ones you remember, it is not ready — and you learned that without touching production.
4. Route the alert to a decision
An alert nobody acts on is a cost, not a benefit. It has to arrive with evidence, a proposed window and a person who owns the sign-off.
Common questions
- What is predictive maintenance?
- It is maintenance triggered by the predicted condition of a specific asset rather than by a breakdown or a calendar. The system learns how the machine behaves when it is healthy, detects the drift that precedes a failure and estimates how long you have to act.
- What is the difference between predictive and preventive maintenance?
- Preventive maintenance acts on time or usage: every 2,000 hours, replace the part. Predictive maintenance acts on evidence: this specific machine is drifting, act within two weeks. Preventive wastes component life and still misses early failures; predictive targets the machine that is actually degrading.
- Does predictive maintenance require IoT sensors?
- Often not. Automated plants already generate cycle times, motor loads, alarm sequences and maintenance records, and those are enough for many failure modes. Sensors are worth adding on the specific assets where no existing signal carries the degradation.
- How much historical data do you need?
- As a rule of thumb, several months of process data and at least a handful of documented failures per failure mode. Anomaly detection can start earlier; predicting a named failure with a time estimate needs examples of that failure.
- How do you avoid false alarms?
- False alarms come from algorithms that see a deviation without knowing its context. Atherya builds that context first: during onboarding the system learns each machine's defects and vulnerabilities, how the team around it works and the environment it runs in, so a deviation that is normal for that machine, that shift or that season is recognised as such — and only what genuinely matters is proposed to a person for sign-off.
- How does predictive maintenance impact operational costs?
- It moves spend from emergency to planned work: less overtime, fewer express parts, less scrap at restart and better spare-part planning. It adds cost too — software, integration and the internal time to act on alerts — so the comparison has to be made per line, on your own downtime history.
- Does it replace the maintenance team?
- No. It changes what the team argues about: instead of debating whether a machine is fine, they debate a specific signal, a baseline and a proposed window. The decision stays human, and it should be logged so you can check the model against reality.
What makes Atherya different
Most predictive maintenance tools score signals. Atherya builds an operational memory of the plant first, then reasons on top of it — with the evidence in plain sight and the decision left to a person.
Operational memory
Every event, anomaly, intervention and shift becomes shared memory. What was a log yesterday is experience tomorrow, and the model reads new signals against it.
Déjà Vu: it has seen this before
Not just "anomaly detected", but when it already happened, how similar it was, how it evolved and which action worked. The senior maintainer's memory, available to everyone.
Context that kills false alarms
Machine defects, weak points, how the crew actually works and the environment around the line. A deviation that is normal for that machine, that shift or that season stays quiet.
Living FMEA
FMEA, manuals and procedures become an active part of the reasoning: causes, effects, sensors and suggested actions are connected, instead of sitting in a document nobody opens.
Explainable, not magic
Every alert arrives with the signals involved, the comparable history, the failure mode and a confidence level. Data, interpretation and decision stay separate and verifiable.
It acts, with your sign-off
Atherya does not stop at the warning: it proposes the maintenance window against real orders and shifts, and replans when something changes. Nothing is applied until a person approves it.
On the data you already have
It works on PLC, SCADA, MES, ERP, maintenance records and feedback as they are — fragmented and legacy included. Sensors are added only where no existing signal carries the degradation.
One brain, not a maintenance silo
Maintenance, production and planning read the same operational state, so a predicted failure immediately becomes a scheduling question instead of a separate dashboard.
Related guides
Predictive maintenance softwareIoT predictive maintenance: which sensors are worth itAI predictive maintenance: how the models workFalse alarms in predictive maintenancePredictive maintenance without new sensorsBest AI for manufacturing: platform comparisonAI for production planningAgentic scheduling in manufacturingAI on top of SAP and your ERP
Start from your own failures
Bring one line, a month of history and the three stops that hurt most. We show what the model finds in that data before you commit to anything.
Request a demo