Runtime-Based TPM: Trigger Maintenance From Actual Machine Hours

Runtime-based TPM at a glance

Trigger wear-driven maintenance from measured runtime hours instead of the calendar, and leave prediction out of it entirely. A monthly interval is a guess that every machine accumulates wear at the same rate, which is false the moment one press runs twenty hours a week and another runs a hundred. The lightly used asset gets serviced too often, wasting parts and taking availability; the hard-run one gets serviced too late. Verified runtime is a closer proxy for wear, and it is a number you already have if machine state is being captured. This is not failure prediction and does not pretend to be.

Why calendar intervals drift

Because a date is a proxy for accumulated wear, and the proxy holds only if every asset runs the same amount.

Take two identical presses on the same monthly preventive schedule. Press A is the workhorse and runs 140 hours a month. Press B covers overflow and runs 30. Over a year, press A accumulates 1,680 running hours and press B accumulates 360. Both receive twelve services.

Press B has been serviced roughly five times more often than its use warrants. Every one of those services consumes parts, labour and availability, and most of them replaced components with most of their life remaining.

Press A has been serviced at intervals of roughly 140 running hours. If the component's real life is 100 hours of running, it has been failing between services all year, and the failures will have been recorded as unplanned breakdowns with no obvious pattern, because the pattern is only visible in running hours and nobody was counting those.

This is the drift, and it runs in both directions simultaneously on the same schedule. The plant is over-maintaining part of its fleet and under-maintaining another part, and the calendar cannot show it because the calendar is the thing hiding it.

The cost of the second direction is larger than it looks. Guidewheel's downtime analysis puts mechanical breakdowns at roughly 72 minutes per event, and an under-serviced asset generates them repeatedly. A maintenance team can be executing its schedule perfectly and still be producing avoidable breakdowns, which is a demoralising place to be and a difficult one to diagnose from within the schedule itself.

Runtime hours remove the proxy. The question is which assets that actually helps.

Which assets benefit and which do not

Runtime triggers help where degradation is driven by running. They do nothing, or harm, where it is not.

Good candidates. Bearings and rotating components. Belts and drive elements. Filters in a running fluid or air path. Tooling and contact surfaces. Lubrication intervals on moving assemblies. Anything whose wear mechanism is friction, load cycling or throughput.

Poor candidates, where the calendar is correct. Lubricant and fluid degradation, which is largely a function of elapsed time, oxidation and contamination rather than hours run. Seals and elastomers, which harden and crack on the shelf as readily as in service. Corrosion and environmental exposure, which continue whether or not the machine runs. Statutory and insurance inspections, which are legal obligations on a date regardless of any engineering argument. Battery and backup systems.

Mixed cases needing judgement. A hydraulic system has both: the pump wears with running hours, and the oil degrades with time. These need two triggers, not one, and forcing a single basis onto them is how plants end up with clean oil in a worn pump or a good pump full of degraded fluid.

The test to apply. For each asset, ask what physically causes the component to reach the end of its life. If the honest answer contains the word "running", runtime is the better trigger. If it contains "sitting", "ageing", "exposure" or "the regulator says so", the calendar is right and should stay.

Most plants find a genuine split, often close to half the schedule on each basis. That split is the useful output of the exercise, and it is worth doing even if you change nothing, because it surfaces which intervals nobody can currently justify on any basis.

For the assets where neither trigger fits and failure is expensive, condition-based monitoring is the answer rather than either interval. Guidewheel's guidance on predictive maintenance without PLCs covers when to go beyond current sensing for critical rotating equipment.

With the asset list split, the thresholds have to come from somewhere.

Calculating the threshold

Convert the interval you already trust rather than inventing a new one.

The method, in five steps

1. Measure the actual duty cycle of a representative asset currently on the calendar interval. Not the assumed duty cycle, the measured one. This is the step that requires runtime data and the reason the exercise was not practical before.
2. Compute the running hours the current interval delivers. Monthly interval, 95 measured running hours per month, gives 95 hours as the implicit threshold your existing schedule already uses.
3. Sanity-check it against the manufacturer's guidance where one exists. Manufacturers frequently specify in running hours, and plants convert to a calendar for administrative convenience. If so, you are simply recovering the original number.
4. Apply a margin, and state it. If the implicit threshold is 95 hours and the evidence is thin, set the trigger at 80 and record why. Tighten it later with evidence rather than guessing loosely now.
5. Set a maximum elapsed time alongside it. A runtime trigger on a rarely used asset can go years without firing, and time-driven degradation continues regardless. Every runtime trigger should carry a calendar backstop, typically the original interval doubled.

A worked case. Press B, 30 running hours a month, on a monthly service. Press A, 140 hours. Setting a threshold of 100 running hours with a six-month backstop gives press A a service roughly every three weeks and press B roughly every three months, with the backstop catching it if utilisation drops further. Both are now maintained on their use rather than on the calendar, and the total number of services across the pair falls while press A gets more attention than before.

Do not skip the backstop. It is the difference between a runtime programme and a slowly deteriorating asset that never triggered.

Once the threshold fires, something has to happen with it.

Wiring it into the maintenance workflow

The monitoring system counts hours. The CMMS does everything else.

The handoff, in four steps

1. Accumulated runtime crosses the threshold on a monitored asset.
2. A notification goes to the maintenance planner, carrying the asset, the hours accumulated, and the date the threshold was crossed.
3. The planner raises a work order in the CMMS, which remains the system of record for the work, the parts, the labour and the history.
4. On completion, the runtime counter for that asset resets.

Guidewheel does not raise the work order. It does not hold parts, labour, or maintenance history, and it is not a CMMS. The boundary between the two systems is covered in machine monitoring versus CMMS, and it matters here because a runtime programme that tries to live outside the CMMS creates a second, competing maintenance schedule, which is worse than the calendar it replaced.

Exception review is the part that gets skipped. Once a month, look at the assets whose triggers fired unusually early or unusually late relative to expectation. Early firing means utilisation went up and the plant should know why. Late firing means an asset is being used less than assumed, which may be a capacity question rather than a maintenance one. Both are useful signals that the calendar never produced.

Keep the reset honest. If a service is deferred, the counter keeps counting. A programme where deferrals silently reset the clock is a programme that has stopped measuring anything.

Start small. Three assets, one quarter, running in parallel with the existing calendar schedule rather than replacing it. Compare what each would have triggered. That comparison is the business case, and it costs nothing but attention.

Then measure whether any of it helped.

Measuring whether it worked

Measure production recovery, not schedule compliance.

Compliance measures whether the maintenance team did what the system told them, which is worth knowing and is not the point. The question is whether the plant lost fewer hours. Three measures answer it:

Unplanned stops on the affected assets, count and total minutes, compared against the same period before. Guidewheel's downtime analysis puts mechanical breakdowns at roughly 72 minutes per event, so a reduction in event count converts directly into recovered hours.

Services performed, compared against the previous basis. A working programme usually performs fewer total services while directing more of them at the assets that needed them.

Availability on the previously under-maintained assets. This is where the gain should appear first, and if it does not appear within two quarters the thresholds are probably wrong.

Give it two quarters before judging. One quarter is noise on most maintenance intervals.

Watch for the two failure modes. Runtime data that is not trustworthy produces triggers that are worse than the calendar, which is why state accuracy should be validated first using the method in validating run, idle and down accuracy. And a programme with no backstop lets rarely-used assets drift, which shows up as failures on exactly the equipment everyone stopped thinking about.

One boundary, restated. None of this is failure prediction. A runtime trigger says an asset has accumulated the hours at which you decided to intervene. It does not say the asset is about to fail, does not estimate remaining life, and does not diagnose a component. Guidewheel is not a predictive maintenance tool, and a runtime programme should not be sold internally as one, because the first unexpected failure will be held against a promise nobody actually made.

For the baseline against which recovery is judged, see ideal versus actual cycle time, and for the underlying state and runtime capture, automated downtime reason tracking. The honest limits of the product are in when Guidewheel is not the right tool.

Frequently asked questions

About the author