Servicing a pump or engine every so many calendar months is easy to schedule but wasteful, because a machine that ran for a hundred hours and one that ran for a thousand get treated the same. A runtime-hours maintenance trigger fixes this by tying the service to actual usage. SCADA accumulates how long the equipment has genuinely been running, and when that running-hours total crosses a threshold, a preventive maintenance job is scheduled automatically. This guide explains how the runtime counter is built and crosses its threshold, why it must count only running hours rather than powered hours, how the counter resets on completion and blends with calendar-based intervals, and how to handle the awkward cases of counter rollover and equipment replacement.
Runtime-Hours Maintenance Trigger in one line: A runtime-hours maintenance trigger is a form of usage-based preventive maintenance in which a SCADA-accumulated running-hours counter for a piece of equipment automatically schedules a maintenance job when it crosses a defined threshold. The counter increments only while the equipment is actually running, so the service is driven by real wear rather than by the calendar, and it is reset or advanced when the maintenance is completed so the next interval starts fresh. In practice it is often blended with calendar-based intervals so that whichever comes first triggers the work, and it has to handle counter rollover and equipment replacement correctly to stay accurate.
The foundation of the trigger is a runtime counter, a value that accumulates the total hours the equipment has been running. SCADA builds it by watching a run signal - a motor contactor, a running status, a flow or current that indicates the machine is actually operating - and adding elapsed time to the counter only while that signal is true. Over days and weeks the counter grows into an honest record of how much the machine has actually worked, which is a far better proxy for wear than the passage of time on a calendar. That accumulated running-hours value is the meter the whole trigger is built on, and its accuracy depends entirely on the run signal being a true indicator of operation.
The trigger fires when the counter crosses a maintenance interval defined for that equipment, for example a service due every set number of running hours. The logic compares the accumulating counter against the interval, and when the counter reaches the next multiple of the interval, it raises the maintenance trigger. This is where the SCADA side meets the maintenance side, because crossing the threshold is the event that should create a preventive maintenance work order, carrying the asset identity and the reason so the maintenance team knows this is a usage-based service coming due rather than a fault. The trigger is essentially a meter reading crossing a set point, translated into a scheduled job.
How far in advance the trigger fires deserves thought, because maintenance has to be planned. Firing the work order exactly at the threshold gives the maintenance team no lead time, so a common refinement is to raise the trigger slightly ahead of the threshold, or to surface an approaching-due status as the counter nears the interval, so parts and crews can be arranged before the machine is actually due. This turns the runtime trigger from a last-minute alarm into a planning aid, giving operations a forecast of upcoming usage-based maintenance based on how fast the counter is climbing, which is one of the practical advantages of driving maintenance from a live running-hours meter.
The distinction between running hours and powered hours is central to getting this right. A machine that is energised but idle is not wearing the way a machine under load is, so counting hours whenever power is present would badly overstate usage and trigger maintenance far too early on equipment that spends much of its time on standby. The counter must therefore increment only while the equipment is genuinely running, which means the run signal has to reflect actual operation - the pump is turning and moving fluid, the engine is under load - not merely that the panel is powered up. Choosing the right signal to define running is the difference between a counter that reflects real wear and one that is systematically wrong.
This can be subtler than it first appears. For some equipment a simple contactor-closed signal is a fine indicator of running, but for others it is not, because a motor can be energised and drawing power while doing little useful work. In those cases a better run indication might be a flow, a discharge pressure, a current above a load threshold, or a dedicated running-status output from the equipment's own controls. The goal is a signal that is true when, and only when, the machine is doing the work that wears it, so that the accumulated hours correspond to accumulated wear. Time spent connecting the counter to the right signal pays off in a maintenance schedule that matches reality.
When the maintenance is done, the counter has to be handled so the next interval starts correctly. The usual approach is to reset the counter to zero on completion, or to advance the threshold to the next interval, so that the machine now has to run another full interval before the next service is due. This reset closes the loop between the maintenance system and the SCADA counter: the work-order completion is the event that tells the counter to start counting toward the next service. Handling this reliably matters, because a counter that is not reset will immediately re-trigger, and a counter reset without the work actually being done will let a service slip, so tying the reset to the confirmed completion of the maintenance is what keeps the cycle honest.
Meter-based intervals are rarely used entirely alone; they are usually blended with calendar-based ones so that whichever falls due first triggers the service. Some degradation is driven by use and some by time - seals and fluids age even when a machine sits idle - so a robust preventive maintenance scheme says a service is due after so many running hours or after so many calendar months, and acts on the earlier of the two. That way a heavily used machine gets serviced on hours before its calendar interval, while a lightly used one still gets serviced on the calendar before its hours ever accumulate. The runtime trigger provides the usage side of this either-or logic, complementing rather than replacing the calendar schedule.
Two awkward cases have to be handled or the counter will mislead. The first is rollover: a counter stored in a fixed-size register will eventually reach its maximum and wrap back to a low number, and a naive comparison against the interval will then behave wrongly, either firing spuriously or missing the threshold entirely. The design has to account for this, either by using a counter wide enough that rollover never occurs in the equipment's life or by detecting the wrap and handling it. The second is equipment replacement: when a worn machine is swapped for a new or rebuilt one, its accumulated hours no longer describe the new machine, so the counter has to be reset to reflect that the wear clock has started over, otherwise the fresh equipment will be scheduled for maintenance it does not need.
A cloud SCADA platform such as Merobix is a natural home for the runtime counter and the trigger, because it already watches the run signals and accumulates the operating time, and it can carry the threshold logic and hand the trigger to a maintenance system. Keeping the counter in the platform means the running-hours meter is visible remotely, so staff can see how close each machine is to its next usage-based service without a site visit, and the approaching-due forecast falls out of the live counter automatically. When the platform detects the crossing, it can raise the preventive maintenance job with the asset and reason attached, and reflect the completion back to reset the counter. For field operations running many unmanned machines, driving maintenance from a live SCADA runtime meter this way means services happen on real usage, planned in advance, without anyone manually reading hour meters in the field.
Because a machine that is energised but idle is not wearing the way a machine under load is, so counting every hour the panel is powered would badly overstate usage and trigger maintenance far too early on equipment that sits on standby. The counter should increment only while the equipment is genuinely running, using a signal that reflects actual operation such as flow, load current, or a running-status output rather than merely that power is present. Choosing the right run signal is the difference between a counter that tracks real wear and one that is systematically wrong.
The two are usually blended so that whichever comes first triggers the service, because some degradation is driven by use and some by time. A machine might be due for service after a set number of running hours or after a set number of calendar months, and the maintenance is scheduled on the earlier of the two. A heavily used machine then gets serviced on hours before its calendar interval, while a lightly used one still gets serviced on the calendar before its hours accumulate, so both use-based and time-based wear are covered.
The counter has to be reset when a worn machine is swapped for a new or rebuilt one, because the accumulated hours describe the old machine's wear, not the new one's. If the counter is left running, the fresh equipment inherits the old total and gets scheduled immediately for maintenance it does not need. Resetting the counter on replacement restarts the wear clock so the new machine accumulates its own hours from zero, and the same care applies to counter rollover, where a fixed-size register wrapping back to a low value must be handled so the threshold logic stays correct.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.