A runtime meter to CMMS PM trigger is the integration that turns live equipment operation into scheduled maintenance. SCADA accumulates how long a motor, pump, or engine has actually run, or how many cycles it has completed, and pushes that number into a meter on the asset record inside the maintenance system. When the meter crosses a defined interval, the CMMS automatically opens a preventive maintenance work order. This page covers how run hours are counted, how thresholds spawn work, and how to handle the awkward cases of meter rollover and counter resets.
Runtime meter to CMMS PM trigger in one line: A SCADA runtime meter to CMMS PM trigger streams accumulated run hours or cycle counts from the control system into a meter field on the asset in a maintenance management system. Once the meter passes a set interval, such as every 500 running hours, the CMMS generates a usage-based preventive maintenance work order instead of relying on a fixed calendar date.
The starting point is an honest count of how much the equipment has actually worked. In the PLC or RTU, a retentive running-hours timer accumulates elapsed time only while the motor contactor is energized or the drive reports it is running, so idle time does not inflate the number. For reciprocating or start-heavy assets the more useful figure is a cycle or start count, incremented once per start, because wear on bearings, seals, and starters tracks starts more closely than raw hours. Many assets carry both meters side by side.
These counters have to survive power loss, which is why they are held in retentive memory rather than volatile registers. A running-hours value that resets to zero every time the panel loses power would be worthless for maintenance planning. Well-built logic writes the accumulator to nonvolatile storage periodically and on shutdown, so a brief outage costs at most a few minutes of counted time rather than the whole history.
The value that matters to maintenance is the lifetime total, not an instantaneous rate, so SCADA reads the accumulator on a slow poll, every minute or few minutes is plenty, and stores it as the current meter reading. Because the number only ever climbs during normal operation, downstream systems can treat any decrease as a signal that something unusual happened, which becomes important when handling resets and rollover later on.
On the maintenance side, the asset record carries one or more meters and a set of usage-based PM definitions tied to them. A definition says something like open a bearing and lubrication PM every 2,000 running hours, or a full overhaul every 8,000 hours. The CMMS stores the meter reading at which the last PM was performed and the interval, so it always knows the next-due reading. Each time SCADA writes a fresh meter value, the CMMS compares it against the next-due figure and generates a work order when the reading reaches or passes it.
This usage-based approach differs from a plain calendar schedule in an important way. A pump that ran hard through a wet season and a pump that sat idle both age on the calendar at the same rate, but only one of them has accumulated the wear. Driving PMs from real run hours means the busy asset gets serviced sooner and the idle one is not torn down needlessly, which is the whole point of condition-based and usage-based maintenance. Many programs run both a usage trigger and a maximum calendar interval, so a rarely used but safety-critical asset still gets an annual inspection even if it never reaches the hour threshold.
The writeback itself is usually a scheduled push rather than a live stream, since a meter that updates once an hour is more than precise enough for a PM measured in hundreds or thousands of hours. The integration reads the current accumulator from the historian or SCADA tag, maps it to the asset by a stable identifier, and posts a meter reading to the CMMS through its API or an intermediate table. The CMMS handles the arithmetic of comparing readings to thresholds and issuing the work order, keeping the maintenance logic where the planners can see and adjust it.
The messy part of this integration is that the source counter does not always behave like a clean, ever-rising number. A running-hours register stored in a 16-bit or 32-bit word will eventually roll over to zero when it exceeds its maximum value, and a naive integration that simply forwards the raw reading would see the meter suddenly drop by a huge amount and either skip a PM or, if it is not guarded, throw the schedule into chaos. The fix is to detect the wrap, add the register's full-scale value to reconstruct the true cumulative total, and forward that corrected number to the CMMS.
Resets are the other common trap. A technician replaces a motor, swaps a control card, or clears the hour meter during service, and the accumulator legitimately returns to zero even though the asset itself has plenty of life behind it. If the integration blindly trusts the new low reading, the CMMS thinks the asset just went backward in time and may never fire the next PM. The durable pattern is to track the last known reading, treat any large unexplained decrease as either a rollover or a deliberate reset, and log it for a human to confirm which one it was, rather than silently rewriting maintenance history.
Because these meters underpin unattended, remote assets, a cloud SCADA platform such as Merobix is well placed to carry the running-hours and cycle counts from scattered pump stations, wellsites, and skids back to one place and hand them to the maintenance system on a schedule. Doing the rollover and reset handling once, in the integration layer, means every site's meters arrive at the CMMS as clean, monotonic lifetime totals, so planners see trustworthy usage figures and PMs fire when the equipment has truly earned them rather than on a guess.
A calendar PM fires on a fixed date interval, such as every 90 days, regardless of how much the asset actually ran. A runtime meter PM fires when accumulated run hours or cycles cross a threshold, so a heavily used asset is serviced sooner and a lightly used one later. Many programs combine both, using a usage trigger with a maximum calendar backstop so an idle but critical asset still gets a periodic inspection.
For meters measured in hundreds or thousands of hours, an update every hour or even every few hours is more than precise enough, since a work order that opens an hour late causes no practical problem. Pushing every second wastes bandwidth and API calls for no benefit. A slow scheduled writeback of the current cumulative reading is the standard approach.
A reset makes the raw counter drop to zero even though the physical asset still carries its history, which can confuse a CMMS that expects an ever-rising meter. A robust integration detects the sudden decrease, distinguishes it from a normal counter rollover, and logs it for confirmation rather than forwarding the bad value. The maintenance record should be adjusted deliberately, either by continuing the lifetime total in software or by recording the reset against the asset.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.