Skip to content
Preventive Maintenance from Machine Data: Runtime, Cycles and Condition engineering guide from Metromotion Controls
Industrial Data & IIoT · SEPT 2026

Preventive Maintenance from Machine Data: Runtime, Cycles and Condition

Key points

Key points
1

Calendar intervals ignore how hard each machine worked

A machine that ran every shift and one that barely ran get the same service on a calendar plan. Runtime hours and cycle counts from the PLC let intervals follow actual use.

2

The PLC already holds most of the data

Run status, starts, cycles and fault codes are in the controller. They can drive usage-based intervals, and fault events and condition alarms can raise work orders directly.

3

Introduce it on a few critical assets first

Agree counters, thresholds and debounce rules with the maintenance planner, prove them on a handful of assets, and only then extend across the plant.

Preventive maintenance is maintenance carried out before a failure, to reduce the chance of one. Most plants schedule it by the calendar: a gearbox oil change every three months, a filler valve kit every six. The PLC that runs each machine already knows how many hours it has run, how many cycles it has done and which faults it has seen. This guide explains how that machine data can make preventive maintenance follow actual use, how fault events and condition data fit in, and how to introduce it without flooding the CMMS with work orders.

It is written for maintenance managers, maintenance planners and engineering leads in Australian food and beverage plants.

This guide is part of our Plant Intelligence section. For how we connect plant events and machine data to a CMMS, see maintenance from plant data.

Maintenance strategies, briefly

Maintenance terminology is standardised in EN 13306, and most CMMS products use the same ideas even when they name them differently.

StrategyWhen work is doneData it needs
Corrective (reactive)After a failureFault time, asset and cause
Predetermined, time-basedAt fixed calendar intervalsA calendar
Predetermined, usage-basedAfter a set amount of useRun hours, cycles, starts or throughput
Condition-basedWhen measured condition shows deteriorationVibration, temperature, current, pressure or similar
PredictiveWhen a forecast of condition says failure is approachingCondition history and a model

Every plant uses a mix. The point of machine data is to move work from the first two rows toward the middle rows where it pays off, not to replace every calendar task.

Why calendar intervals miss

A calendar plan assumes every asset works at a steady rate. In a food plant that is rarely true. Seasonal products run hard for a few months and then sit. A second filler runs only when the first is down. A line moves from one shift to three when a new customer lands. On a calendar plan, the busy asset is under-maintained and the idle one is over-maintained, and neither is visible in the CMMS.

What the PLC already knows

Most of the data usage-based maintenance needs is already in the controllers.

  • Run hours: accumulated from a motor's running feedback or the machine's running state.
  • Cycles and strokes: filler cycles, valve operations, cutter strokes, sealing jaw cycles.
  • Starts: motor starts, which matter for motors and soft starters as much as hours do.
  • Throughput: units or tonnes processed, where wear follows volume.
  • Fault events: which fault stopped the machine, when and how often.

Where a counter does not exist, adding one is usually a small, controlled PLC change. Counters should be retained through power loss, protected from accidental reset, and reset deliberately when the maintenance task is completed.

Usage-based intervals

A usage-based interval replaces "every three months" with "every 2,000 run hours" or "every 500,000 cycles". The thresholds come from OEM recommendations where they exist, adjusted by the site's own failure history.

There are two common ways to connect this to the CMMS.

  1. Meter readings. The plant sends each asset's counter value to the CMMS as a meter reading on a schedule, and the CMMS raises the preventive work order when the reading crosses the interval. Many CMMS products support meter-based preventive maintenance natively.
  2. Threshold events. The plant detects the threshold itself and raises the preventive work order directly through the CMMS interface.

Meter readings keep the maintenance plan in the CMMS where planners manage it, which is usually the better choice. Either way, the counter or its reference point should reset when the job is closed, so the next interval starts from the actual service.

Fault events that raise work orders

Corrective work starts faster when the fault raises the work order. The PLC knows which fault stopped the machine; passed through the SCADA layer to the CMMS, it becomes a work order against the right asset, with the fault code and time attached, before anyone makes a phone call. At Remedy Drinks, plant events in Ignition create work orders in the MEX CMMS automatically, which reduced the gap between a fault occurring and a work order being raised and assigned.

Fault history also improves preventive plans. An asset whose fault count rises between services is telling the planner the interval is too long.

Condition data and early warning

Some failures give warning. Bearing and gearbox wear show up in vibration, electrical problems in motor current, and heat in temperature, often weeks before a failure. Condition-based maintenance acts on that warning. On the Remedy Drinks can filler, vibration and condition data is collected over MQTT, trended in Ignition and alarmed against thresholds aligned to maintenance inspection intervals, giving the maintenance team early warning of developing faults.

The interval between a detectable problem and a failure, often drawn as the P-F curve, sets how often condition must be checked for the warning to be useful. Our guide to IIoT condition monitoring covers sensor choice, sampling and the P-F curve in detail.

Rules that keep the CMMS usable

The fastest way to lose the maintenance team's trust is to flood the CMMS. A few rules, agreed with the maintenance planner before any code is written, prevent it.

  • Debounce and repeat rules. A fault that trips forty times in a shift raises one work order, not forty.
  • Minimum duration. Stops cleared in seconds are logged but do not raise work.
  • Priority by asset criticality. A fault on a critical filler ranks above the same fault on a spare conveyor.
  • Asset mapping. Every PLC and SCADA asset name maps to one CMMS asset, so work lands on the right equipment.
  • Close-out. The work order closure resets the counter or confirms the fault is cleared, so the loop is complete.

Introducing it on a real plant

A staged introduction works best.

  1. Pick a few critical assets where failures are costly and the OEM gives usage-based guidance, such as a filler, a capper and a key conveyor drive.
  2. Agree the counters and thresholds with the maintenance planner, and add or protect the PLC counters under change control.
  3. Connect to the CMMS through its documented interface, with queuing so an outage delays a reading instead of losing it.
  4. Run it alongside the calendar plan for a period, compare what each would have scheduled, and adjust.
  5. Extend to more assets once the planner trusts the readings and the work orders.

What this means

The PLC already knows how hard each machine has worked and why it stopped. Runtime hours and cycle counts can drive preventive maintenance intervals, fault events can raise corrective work orders directly, and condition data can give warning before a stop. Introduced on a few critical assets with clear rules, machine data makes the maintenance plan follow the plant rather than the calendar.

If you want plant events and machine data connected to your CMMS, speak with an engineer.

Share:LinkedInX
Next step

Planning work in Industrial Data & IIoT?

Tell Metromotion Controls about the work you are planning and speak with an engineer about the next steps.