Questions this answers
- What data does AI predictive maintenance require?
- Can we start without a failure history?
- What are the stages of a predictive maintenance project?
- Do we need to install new sensors?
Predictive maintenance means noticing before a machine stops rather than fixing it afterwards. The idea is simple; the difficulty is knowing what to prepare. This is an answer to that question.
First: not every machine needs it
Predictive maintenance costs money, and applying it everywhere is not efficient. Start with equipment meeting at least two of these three conditions.
- High loss when it stops — the whole line halts, or an entire batch has to be scrapped
- Repeated failures — the same component causes trouble on a cycle
- Expensive to inspect — teardown inspection takes significant time and labor
Conversely, machines that can be swapped immediately and whose failure stays local are low priority.
What data you need
1. Equipment signals
The foundation is what the machine itself emits.
| Signal | What it typically reveals | Suggested sampling |
|---|---|---|
| Vibration | Bearing wear, misalignment, imbalance | High frequency (kHz) or periodic snapshots |
| Current | Load changes, motor faults | Per second |
| Temperature | Overheating, cooling faults | Seconds to minutes |
| Pressure / flow | Leaks, blockages | Per second |
Vibration carries the most information but also the most data. Rather than fitting high-frequency vibration sensors everywhere, it is usually more realistic to start with current and temperature signals you are already collecting.
2. Operating conditions
The same vibration reading means something different under a different load. Output volume, run/stop state, product type and speed all have to be there before a signal can be interpreted.
This is missing more often than you would expect. Equipment signals exist, but there is no record of what was being made and at what rate — which makes separating normal from abnormal difficult.
3. Failure and maintenance history
A record of what failed when and what was done about it. A model cannot learn “this pattern preceded a failure” without it.
This is the most commonly missing piece. Maintenance logs are often on paper, or recorded as little more than “checked, found fault.”
Can we do it without a failure history?
Yes — the approach simply changes.
With sufficient history — supervised learning can predict failure some days ahead. That said, it takes at least dozens of instances of the same failure type before learning becomes meaningful.
Without much history — start with anomaly detection trained only on normal states. Because it detects “different from usual,” no failure cases are required. In exchange, whether a detected anomaly actually precedes a failure is something you accumulate in operation.
In practice, most projects begin with the latter and move to the former as history builds up.
How much data?
There is no fixed answer, but there is a test.
Has the equipment been through a full cycle of the variation it experiences? If ambient temperature shifts with the seasons, both summer and winter need to be in there. If conditions change by product type, all the main products should appear.
Typically a first model is built on three to six months of data and improved in operation. Waiting for perfect data means never starting.
The stages
1. Target selection and data check. Decide which equipment to cover and verify what data is actually being stored. This stage regularly turns up data everyone assumed existed and does not.
2. Collection. Fill the gaps, standardize formats that differ by machine, and bring it together. Aligning timestamps with operating conditions matters — if the clocks disagree, everything downstream is unstable.
3. Modeling. Build the anomaly detection or failure prediction model.
4. Field validation. Run it and measure the false alarm rate. This is the critical stage. Alerts that fire too often get ignored on the floor, and an ignored system might as well not exist.
5. Operation and retraining. Equipment condition and process conditions keep shifting. A model built once will lose accuracy over time, so set a retraining cycle.
Commonly missed
Not costing false alarms. Looking only at missed failures and ignoring false alarms erodes trust on the floor. Both need to be weighed to find an operable point.
No procedure after the alert. If nobody has decided who does what when “anomaly detected” appears, nothing happens. Settling that procedure is often more valuable than the system itself.
Rolling out everywhere at once. Validate on one machine, then extend. Conditions differ enough between machines that models rarely transfer unchanged.
IMPIX supports equipment data collection and standardization (B²LAB), AI model building (A²) and operational automation on one platform (A²LAB). If it is not clear which equipment to start with, reviewing the current state of your data together is a reasonable first step.