Meter-Based and Usage-Based PM in a CMMS

Meter-based preventive maintenance looks like the sophisticated option: instead of servicing a generator every six months whether it ran or not, you service it every 500 running hours, so the work follows the wear. The logic is sound and the manufacturers agree. What nobody warns you about is that a meter-based PM programme is not a maintenance configuration, it is a small data pipeline, with sources, latency, validation, gaps, resets and outliers. The most common failure is not a PM that fires too often. It is a PM that silently stopped firing eighteen months ago because a meter was replaced and nobody noticed.

The message up front: meter-based PM succeeds or fails on the reliability of the reading stream, not the elegance of the trigger. Get four things right and the rest is detail: pick a meter that genuinely tracks the wear, validate every reading before it moves a PM, handle rollover and replacement explicitly, and make missing data fail safe by falling back to a calendar trigger. Whether usage triggers are the right strategy belongs in the preventive maintenance strategies pillar; this guide assumes the decision is made.

1. What changes when a PM comes off the calendar

A calendar PM needs one thing the system already holds with perfect reliability: today's date. A meter PM needs a number from outside the system that arrives irregularly, may be wrong, may be missing, and may reset to zero without warning. That difference creates five obligations: a reading source with a named owner and a defined cadence; a validation layer, because one fat-fingered entry can push a PM two years out; a reading history rather than a current value, since rates and forecasts need the series; a lifecycle model for rollover, replacement and reset; and a defined behaviour when data is absent. If you cannot staff those five, calendar PM at a conservative interval is the more honest choice.

2. Meter types and choosing one that tracks the failure mode

The first decision is which quantity to count, and it is where the most durable mistakes are made. The temptation is to use whatever the asset already displays, usually running hours, because that is what controllers show. But hours only correlate with wear for failure modes driven by continuous operation.

The counter-example is the starting system on a standby generator. Hours accumulate slowly on a standby set, so an hours trigger on the starter and battery almost never fires, while that system is stressed on every test start. The wear driver there is number of starts. A motorised damper wears through cycles, not runtime. Name the dominant failure mode first, then pick the meter proportional to it. One asset can legitimately carry several meters feeding several PM routines.

A word on condition triggers, because CMMS products often implement them through the same meter mechanism. A usage meter is cumulative: it only goes up, and the trigger fires when it has advanced by a fixed amount since the last service. A condition reading is not: filter differential pressure drops back to baseline the moment the filter is changed. Configure a condition value as a cumulative meter and the arithmetic is wrong from the first service. Most platforms distinguish a "cumulative" meter from a "gauge" meter, with advance-by-N logic for the first and threshold-crossing for the second. Get the class right at creation; changing it later means rebuilding the history. The strategic distinction sits in the condition-based versus predictive maintenance pillar.

3. Reading sources and what each one is actually worth

Provenance determines how much you can trust a reading and therefore how tightly you can tune the trigger. A meter fed by a PLC every fifteen minutes can support a narrow PM window. A meter read by a technician on an inconsistent monthly walk cannot, and pretending otherwise is how PMs fire three weeks after the oil should have been changed.

• Manual entry. A technician reads the display and types the number, ideally on the mobile app at the asset rather than from a clipboard in the office. Cheapest, universally available, least reliable: transcription errors, missed rounds, unit confusion, readings entered against the wrong asset. Still right for low-criticality assets and sites with no automation, provided you accept looser tolerances. Capture it inside an existing PM or round, not as a separate task nobody owns.
• BMS or SCADA feed. For building and utility plant the runtime totaliser very often already exists in the control system, so you are integrating rather than instrumenting, which is usually the best value available. Watch tag mapping discipline, totaliser resets on controller reboot, and who owns the tag when the controls contractor renames a point. See the SCADA to CMMS integration pillar.
• Telematics. For fleet and mobile plant the unit already reports odometer, engine hours and idle time. Reliable and frequent, with two caveats: aftermarket units sometimes report their own accumulated hours rather than the vehicle's, which diverges from the dash reading and confuses technicians, and units get swapped between vehicles. See the fleet and truck PM pillar and the CMMS for fleet maintenance pillar.
• IoT sensor. A retrofit run-detection sensor, current clamp or cycle counter added specifically to produce the meter. Right where the asset has no controller and manual reading is impractical, such as distributed pumps in plant rooms nobody visits weekly. Plan for battery life, connectivity gaps, and the fact that a run-detect sensor infers hours rather than reading a real totaliser. See the IoT integration with CMMS pillar.
• PLC or local controller. The most accurate source, but the counter belongs to the controller, so a replacement or firmware reset takes your history with it. Treat every controller intervention as a meter event, which brings us to the part that breaks implementations.

Whatever the mix, record the source on every reading.

4. Validation rules: what to check before a reading is allowed to move a PM

Implement this before switching a single PM to meter-based. An unvalidated stream will eventually take a number that either cancels maintenance for years or generates a flood of work orders overnight. The rules are not complicated, simply often absent. In rough order of value:

• Monotonicity. For a cumulative meter, a reading lower than the last is a rollover, a replacement, a reset, or an error. Never accept it silently. Reject it into an exception queue and make a human classify which of the four it is.
• Maximum plausible rate. An asset cannot accumulate more than 24 hours of runtime per calendar day, and a vehicle cannot cover 4,000 km in one. Derive a per-asset-class ceiling from physics and duty and reject anything above it. This rule catches most transcription errors, because a digit in the wrong place nearly always breaches it.
• Minimum plausible rate. Zero usage on an asset in supposedly continuous duty is not good news, it is a broken meter. The mirror image of the rule above, and the one people forget.
• Magnitude sanity. A jump of exactly ten times expected is nearly always a decimal or unit error: hours where the field wants tenths, or miles into a kilometre field. Comparing against the rolling average catches it.
• Timestamp sanity. Readings dated in the future, or before the previous reading, corrupt every rate calculation downstream.
• Duplicate suppression. The same value and timestamp arriving twice from an integration retry should be idempotent. Deduplicate on source plus asset plus timestamp.
• Unit declaration. Store the unit on the meter definition and validate readings against it. Mixed units in one history is the hardest thing to unpick later, because every number looks individually plausible.

Rejections must go somewhere a human looks: a queue nobody reviews is worse than no validation, because it creates a false sense of control. Give it an owner and a cadence, and report its size as a data-quality metric. And resist auto-correction, which destroys the evidence you need to fix the cause.

5. Rollover, replacement and reset: the part that breaks implementations

If you remember one section, make it this one. Meter discontinuities are the leading cause of meter PM failing silently, and silently is the operative word. A PM that fires too often gets reported within a week because it annoys people. A PM that has stopped firing gives no signal until the asset fails. Four events need four handling paths:

• Rollover. A fixed-width counter hits its maximum and wraps to zero: a five-digit hour meter rolls at 99,999. The reading drops but the usage is genuine. Handling: declare a rollover point on the meter definition, and when a drop is consistent with wrapping there, compute usage as (rollover point minus previous reading) plus new reading. Automate it; the arithmetic is unambiguous once the wrap point is declared.
• Replacement. The meter is swapped and the new unit starts at zero while the asset carries on with all its accumulated wear. Handling: a lifecycle event, not a reading. Close the old meter with a final reading, open a new instance with a recorded offset equal to the asset's true accumulated usage at swap time, and run PM calculations against the offset-adjusted lifetime value. Never overwrite the reading.
• Reset. The counter is zeroed without being replaced, by a controller reboot, firmware update, battery change or a deliberate reset after overhaul. Handling: the same offset mechanism, but distinguish a spurious reset, where accumulated wear is unchanged and the offset must preserve it, from a legitimate post-overhaul reset, where the component is new and the PM clock should restart. Only a human can tell those apart, which is why the exception queue must exist.
• Component change under the meter. The asset keeps its meter but the serviced component is replaced, say a new pump on an existing skid. The lifetime meter continues, but the PM's counter must reset, because wear on the new component starts at zero. Handling: separate lifetime usage from PM-cycle usage and reset only the latter. Any CMMS tracking a single number per asset gets this wrong.

Underneath all four is one data-model rule: store lifetime cumulative usage as a derived value, separate from the raw display reading, and drive PM triggers from the derived value. The raw reading is what the meter says; the derived value is what the asset has actually done. Conflating them causes most of the pain here. Asking a vendor to demonstrate a meter replacement with a non-zero offset, live, is one of the most revealing items in a demonstration script. Do not accept a slide. Ask to see the reading history afterwards and confirm both series are intact.

6. Interpolation and estimation when readings are sporadic

Readings rarely arrive on the day you need them. A PM due at 500 hours must be evaluated today, but the last actual reading was eleven days ago at 486 hours. You either wait, so the PM is always late by the reading interval, or you estimate. Estimation is right, provided it is visibly an estimate. The standard approach is a rolling average usage rate: take the last several genuine readings, compute usage per day, and project forward. The choices that matter:

• Window length. Long windows are stable but slow to react to a duty change; short windows react quickly but are noisy. Steady duty favours longer, seasonal duty shorter.
• Calendar days versus operating days. In a five-day facility, averaging over calendar days understates weekday rates and mis-times a PM within the week.
• Exclude anomalies from the rate. A shutdown or commissioning burst skews the average badly. Ignore readings flagged as exceptional, another reason to keep flags rather than correcting values.
• Never let an estimate become a stored reading. Written into the history it becomes the base for the next estimate, and the error compounds until the projected meter has drifted far from the machine. Keep estimated and actual separate, and label which is which on screen.
• Trigger on actuals, plan on estimates. The default I would recommend: use the estimate to raise the PM into the planning window and get it scheduled, then confirm against an actual reading before the work is signed off as due. The technician is at the asset anyway.

If readings are so sporadic that the estimate outweighs the actuals, the trigger is calendar-based with extra steps. Improve the source, or convert it to a calendar PM at an interval derived from observed usage.

7. Setting the interval, the lead window and the tolerance

A trigger that fires the instant the meter crosses the threshold produces a work order that is already due, which is useless to a planner. Meter PMs need the same planning runway as calendar PMs, expressed in meter units rather than days. Three parameters do the work:

• The interval. How much usage between services. Start from the manufacturer figure, then adjust with evidence: if inspection consistently finds the oil in good condition at 500 hours there is a case to extend; if you find early wear, shorten it. Document any deviation, because the first question in a warranty dispute or an audit will be why you departed from it. Warranty terms sometimes remove your discretion entirely.
• The lead or generation window. How far before the threshold the work order is created, so the planner can schedule it, order parts and book access: raise it at 450 hours for a 500 hour service. Size it from the usage rate, not a round number. An asset accumulating 20 hours a day needs a far larger lead in meter units than one accumulating two. Roughly two planning cycles of usage at the current rate is a workable rule.
• The tolerance or compliance band. The range around the target within which work counts as on time, say 500 hours plus or minus 50. Without a declared tolerance every PM is early or late and the compliance figure is meaningless. With one you get an honest measure, and technicians get latitude to combine the service with an adjacent shutdown.

Two further behaviours to configure deliberately. Decide whether the next due point comes from the target or the actual completion reading: from-actual prevents a slow creep where every service runs late, from-target keeps a stable rhythm but can compress the next interval. For wear-driven work, from-actual is usually correct. Then decide what happens when several meter PMs on one asset come due together. Nesting, where the 500 hour service is absorbed into the 2,000 hour service, avoids duplicate labour and downtime wherever the task lists overlap. Broader scheduling mechanics are in the guide to building a PM schedule.

8. Combined triggers: whichever comes first, and why it is the right default

The most useful configuration in this subject is the combined trigger: service at 500 running hours or every 6 months, whichever comes first. It is not a hedge. It reflects two independent degradation processes running at once, and you need protection against both.

Usage drives mechanical wear. Time drives everything that degrades whether or not the asset runs: oil oxidises and absorbs moisture, seals harden, batteries self-discharge and sulphate, corrosion advances. A generator that ran 40 hours in two years needs nothing on wear grounds, but its oil, coolant, belts and battery have all aged regardless. An hours-only trigger never touches it; a time-only trigger over-services the same set when it is running hard. Whichever-comes-first covers both, which is why I would make it the default. The points that matter:

• Set the two thresholds independently. The meter interval comes from wear evidence and manufacturer guidance. The calendar interval comes from time-driven degradation, statutory requirements and the maximum period you will go without eyes on the asset. They are not two views of one number.
• Both counters reset on completion. Failing to reset the dormant one is a common slip that makes the second trigger fire again immediately afterwards.
• Record which trigger fired. Over a year, the ratio of hours-triggered to calendar-triggered completions tells you whether the asset's duty matches your assumptions. Always calendar-triggered means barely used, a candidate for a longer interval or for questioning whether the asset should exist. Always hours-triggered may deserve a tighter calendar backstop.
• Use whichever-comes-last rarely. It suppresses work on lightly used assets, and is defensible only where time-driven degradation genuinely is negligible, which is unusual for anything containing oil, rubber or a battery.

9. Forecasting PM load from projected usage

One genuine advantage of meter-based PM is rarely exploited: because you know each asset's usage rate, you can forecast when its next several services fall and therefore what the workload looks like months ahead. Calendar PM gives a fixed schedule but no way to see the effect of an operational change. Meter PM lets you ask what happens if the plant runs at 90 percent instead of 60. The mechanics, once the reading history exists:

1. Take each metered asset's lifetime usage and its rolling usage rate.
2. Project the meter forward across the horizon, applying known duty changes such as a seasonal chiller ramp or a shutdown.
3. Identify which thresholds the projection crosses and when, including the multi-level services such as the 2,000 and 6,000 hour events that carry far larger labour and parts requirements.
4. Apply the calendar leg of each combined trigger and take whichever comes first.
5. Aggregate the work by period, by trade and by parts requirement.

That output earns its keep three ways. It reveals workload peaks early enough to smooth them, by pulling work forward within tolerance rather than discovering in the week that three major services have landed together. It gives procurement a demand signal for long-lead parts before the requisition is urgent. And it gives a defensible labour plan. The caveat: the forecast inherits every weakness in the rate estimate, so it is a planning aid with a widening error band, not a schedule. Present it as ranges and refresh it monthly. It is most reliable for the next quarter, conveniently the horizon where planning decisions are made.

10. When the meter data stops: fail safe, never fail silent

This failure mode does real damage, and it is almost always an omission. If the meter stops reporting, the naive implementation never reaches the threshold, so the PM never becomes due, no work order is raised, and nothing appears overdue on any report. The asset falls out of the programme while the system shows a clean compliance figure. I have seen this run for well over a year before an unrelated failure exposed it. The defences should be live before the first meter PM is:

• A calendar backstop on every meter PM. The whichever-comes-first pattern above is the primary defence, because a dead meter simply means the calendar leg fires. This alone converts a silent failure into a slightly over-serviced asset.
• Staleness monitoring, independent of the PM. Define an expected cadence per meter and alert when nothing has arrived within, say, twice it. Route it to the meter owner, not the work order queue: it is a data problem needing a data fix.
• Flat-line detection. A stream that keeps arriving with an unchanged value on an asset that should be running is worse than no stream, because it looks healthy to every staleness check. Compare reported usage against expected duty.
• A visible data-quality report. Stale meter count, exception queue size, and count of meter PMs whose last trigger was the calendar backstop, in the monthly review beside the compliance numbers.
• Never suspend the PM automatically. If a platform offers to hold a meter PM while data is unavailable, understand that you are choosing to stop maintaining the asset. The narrow legitimate cases, an asset genuinely out of service or in storage, belong in an explicit status change with an owner and a review date, not in a quiet side effect of a missing feed.

11. A configuration checklist you can lift

For each asset going onto a meter trigger, work through this before go-live:

• Failure mode named, with a reason why the chosen meter is proportional to it.
• Meter class correct: cumulative for usage, gauge for condition.
• Unit declared, and used by every source feeding the meter.
• Source and owner recorded, with an expected reading cadence.
• Rollover point declared for any fixed-width counter.
• Offset mechanism tested by simulating a replacement: the PM stays positioned, the history survives.
• Validation rules active: monotonicity, maximum rate, minimum rate, magnitude, timestamp, duplicates.
• Exception queue owned, with a named reviewer and a cadence.
• Interval, lead window and tolerance set in meter units, with the manufacturer basis documented.
• Calendar backstop configured, both counters resetting on completion.
• Nesting decided for overlapping interval levels.
• Staleness and flat-line alerts live, routed to the meter owner.
• Data-quality metrics on the monthly report, alongside PM compliance.

And keep the failure-mode table below beside it.

The idea to walk away with

Meter-based PM is a data engineering problem wearing maintenance clothing. The trigger arithmetic is trivial; the reading stream is the whole job. Every serious failure here traces to one of four omissions: a meter that does not track the failure mode, readings that were never validated, a discontinuity that was never modelled, or an absence of data allowed to mean "not due" instead of "fall back to the calendar".

Which is why the strongest configuration is the least clever one. Choose the meter that matches the wear. Validate every reading and give the rejections an owner. Model rollover, replacement and reset explicitly. Put a calendar backstop on everything. Monitor staleness independently of the PM. That is a far better use of effort than tuning intervals to a precision the data cannot support.

Final thoughts

The gap between a meter programme that works and one that has quietly stopped working is almost never visible on the PM record. It shows in the reading history, the exception queue and the staleness report, which is why those three deserve as much monthly attention as the compliance percentage. If you inherit a programme, find out which meters are still alive before optimising what the dead ones are supposed to trigger.

And keep the scope proportionate. Meter triggers earn their overhead where usage varies widely between periods or identical units, and earn little on steady-duty assets where a calendar interval derived from observed usage lands in almost the same place. For the wider frame, the complete guide to preventive maintenance and the core CMMS modules explainer cover how PM, meters, work orders and inventory fit together, and the CMMS buyer's introduction is where to start if you are evaluating platforms.

Worth reading alongside this: the asset management and maintenance terminology frameworks from ISO , the reliability and maintainability standards catalogue at IEEE , and the standard task schedules maintained by SFG20 , useful for setting the calendar leg on building services plant.

Related reading: Preventive maintenance strategies (time vs meter vs condition), How to build a PM schedule, SCADA to CMMS integration, IoT integration with CMMS, PM for fleets and trucks, Generator, pump and motor PM.