How to do predictive maintenance for equipment
Predictive maintenance uses a machine’s condition data to decide which day to service or repair it, then hands that decision to a work order. A threshold can come before a model: when a measurement crosses a limit written in advance, open the order. Equipment that calendar servicing already covers does not need a model first.
On this page
Name the failure you are trying to get ahead of
Write what stops if this machine fails, and whether safety or a compliance duty requires it to be taken out of service. Predictive maintenance has to answer a narrower question: which measurement, once it changes, should open a service or repair order before that failure. If that failure is not named, later thresholds and models have nothing to be checked against.
If the same machine is also rented or shared, a failure blocks the calendar. The asset, the rental, and the repair need one identifier. See How to choose an equipment rental management system and the homepage block Buy, lease, or plan it with development.
Condition data has to point at that machine
ISO 17359:2018, Condition monitoring and diagnostics of machines — General guidelines, was published as edition 3 in January 2018 and was last reviewed and confirmed in 2023, so that edition remains current. The catalogue abstract says the standard gives guidelines for the general procedures to be considered when setting up a condition monitoring programme for machines, includes references to associated standards required in that process, and applies to all machines.
Each measurement in the programme carries the equipment identifier, what was measured, the time, and the unit. Vibration, temperature, current, running hours, or another quantity is in scope only when this machine’s documentation or the existing maintenance record can explain it. A string of numbers that does not match an identifier cannot open an order.
A threshold comes before a model
Write the limit first: which measurement, once it crosses a stated limit or crosses it on several readings in a row, opens an order. The limit comes from the equipment documentation, the maintenance conditions the manufacturer gave you, or a servicing rule your company has already approved, and the source is named. A number with no source does not go into a rule that opens orders on its own.
A model is the layer after the threshold. It uses a stretch of condition data and failures that were later confirmed, to see whether a pattern warns earlier than a single limit. The model’s output is still “suggest an order”. The maintenance lead decides whether to schedule it. Without a history that is long enough and tied to failure records, keep the threshold.
Hand the judgement to a work order
When a threshold is crossed, or a model suggests repair, the system opens a work order or sends the suggestion into the work orders you already use. The order names the equipment, the measurement and time that triggered it, the work suggested, and whether a threshold or a model produced it.
When a person accepts, reschedules, or closes the order, they record why. Closing it records what was actually done and whether a matching fault was found. That write-back is what the next change to a limit, or the next look at a model, is checked against. A colour on a dashboard with no work order does not change the maintenance schedule.
When calendar servicing is enough
Calendar servicing is enough when failure is weakly tied to how hard the machine is used, when the manufacturer or a regulation already requires service by date or by running hours, and when a reminder is enough to stop a missed interval. Turning each due date into a work order, and ticking it only when the work is done, is more direct than starting with a model.
If condition readings are occasional and long gaps sit between them, the calendar stays the schedule and the readings are spot checks. A spot check that crosses the limit still opens an order. A gap is not evidence that the machine was fine during the gap.
Do not fit a model to unstable measurements
A sensor that drops out, units that change from one period to the next, or a failure note that only says “repaired” with no symptom and no date, cannot be checked against a model. First make the identifier, the unit, the time, and the work-order write-back consistent. Then use a short stretch of records that have already been checked, and see whether the threshold opens orders it should not, or misses ones it should.
Whether that is worth connecting to the work-order system you already run is an Assessment, prototypes, and integration question. If the process and the location of the data are not written down, attaching a model that opens orders on its own only adds orders nobody can explain.
Read it next to the asset and the rental
The master record, the rental calendar, and the repair order for one machine share one identifier. When a repair order is open, the matching days on the calendar are marked unavailable until the responsible person sets the machine back to available. Closing the order in maintenance while the rental sheet still says available puts the next rental on a machine that is not ready.
This note does not state an availability figure or a drop in failures. Those figures have to come from your own work orders and downtime records, with the period and the definition written down. Until that record exists, check the programme by whether orders are opened under the written rule and whether a person closes them with a reason.