A reliability engineer opens the meter history on a fleet of 42 gearboxes and finds that the running hours meter has read 4,321 for the last six weeks on 11 of them. The condition-based PM was written to fire at 5,000 hours. Nothing has fired. Nothing will. The library looks like it is running condition-based maintenance because the PM records carry a meter frequency; the operation is running calendar maintenance with a duty sticker on the front. This is the failure mode that Maximo meter readings, done well, quietly prevent.
This is about the configuration and operating discipline that keep meter-driven PMs honest in IBM Maximo Manage, including under MAS. The applications, objects and rules have been part of the product for years and apply equally to Maximo 7.6.1 estates that have not yet upgraded.
What a Maximo meter reading actually is
Maximo Manage separates four records that tend to be discussed as one. A meter is a system-level definition in the Meters application, typed CONTINUOUS, GAUGE or CHARACTERISTIC. An asset meter or a location meter is an instance of that definition attached to a specific asset or location record; this is what carries readings, a rollover value, an average calculation method and a running Average Units per Day figure. A meter reading, on the MeterReading object, is the value stamped with a date that the PM engine and any reliability report actually read from. A condition monitoring point, separate again, links a GAUGE or CHARACTERISTIC meter to action limits, a job plan and, optionally, a PM.
A programme that talks about “meters” without being clear which of those four records it means is usually the programme with the 4,321-hour problem.
Rung 1: the meter is defined against the right record
Where the meter measures the duty of equipment that gets removed, refurbished and reinstalled, it belongs on the location, so history is uninterrupted when the asset in the slot changes. Where it measures the life of a serial-numbered unit that moves between locations, it belongs on the asset, so cumulative hours travel with it. Rotating item records, with a meter group attached, propagate the same set of meters onto every asset created from the item master. Getting this wrong produces meters that reset when nothing physical has changed, and PMs that fire on the wrong equipment.
Meter groups propagate a consistent set of meters onto every asset without hand-editing. A curated library has a small number of them, one per equipment class, each carrying the two or three meters the class genuinely needs.
Rung 2: the reading actually reaches the record
A PM frequency means nothing if no reading arrives. There are four capture paths in normal use, and the estate should pick one per meter and commit to it.
- Mobile crew entry against the asset on a work order or route. Correct for meters only the crew can see: a hydraulic pressure gauge, a filter differential, a running-hour counter behind a locked cabinet. Works only if the mobile step is on a task the crew will always complete.
- Control-room end-of-shift entry through a Start Center portlet or a lightweight web action. Defensible for a small number of high-value meters, not for a fleet of hundreds.
- Integration into the asset or location meter through the MXMETERDATA object structure. The correct route for a historian or SCADA feed, and it scales.
- A scheduled job pulling from a business system such as telematics, energy management or a BMS, writing through the same object structure.
For every meter in the library, one of these paths owns the reading and the owner is named. Meters without an owner are the ones that stop updating six weeks after the supervisor changes role.
Rung 3: the arithmetic behaves under real conditions
Continuous meters carry two settings that decide whether the numbers make sense at all. The reading type, ACTUAL or DELTA, decides how each value is interpreted: ACTUAL is a cumulative counter, DELTA is the increment since the last reading. Mix the two on a single meter, or send one from an integration while the field enters the other, and no report can trust the history.
The rollover value decides what happens when the physical counter reaches its maximum and returns to zero. A five-digit hour counter that reads 99,999 today and 15 tomorrow has either recorded a 99,984 hour negative delta or, with the rollover value set to 100,000, a correct rollover event. Get this wrong and the Average Units per Day figure is polluted, which in turn shifts every meter-based PM that depends on it.
The Average Calculation Method (ALL, STATIC, SLIDING-DAYS, SLIDING-READINGS) decides how the next-due date is projected. Where duty varies across the year, ALL over-smooths and lags. A SLIDING window sized to the operating cycle produces a next-due date the planner can plan against.
Rung 4: the PM frequency is genuinely tied to the meter
A meter-based PM in Maximo Manage carries a meter frequency in the units of that meter. The PMWoGenCronTask evaluates it, uses the asset’s Average Units per Day to project the next due date, and generates a work order when the meter reaches the threshold or the estimated date falls inside the lead time. A PM that carries both a calendar frequency and a meter frequency will fire on whichever comes due first, unless the “Use this PM only when meter frequency is reached” option is set. Estates that intend to run duty-driven maintenance and leave that option unchecked end up with calendar-driven work orders they did not ask for, which is the mechanism behind the fleet with the 4,321-hour reading.
A meter-driven PM assumes the meter is read, the reading is trustworthy, and the average is meaningful. The rungs above are what make that true for a PM library that holds up in the work order queue.
Rung 5: condition monitoring closes the loop for gauges and observations
GAUGE and CHARACTERISTIC meters do not drive PMs directly; they drive condition monitoring points. A condition monitoring point links the reading to upper and lower action limits (for GAUGE) or to domain values (for CHARACTERISTIC), and to a job plan or a PM. The MeasurePointWoGenCronTask evaluates the readings, and when one falls outside the limits or matches an action value, a work order is generated at WAPPR against the asset. A crossover domain on the WORKORDER object is the usual way to stamp work type and priority so the generated work order lands somewhere the supervisor sees it.
The value only materialises when the reading discipline is real. A pressure differential entered as an estimate by a crew that never opens the cabinet is worse than no reading; it creates a false floor for the condition monitoring engine.
What stays hard
Three things do not get easier with configuration. Instrument reliability is not a CMMS problem to solve, and a meter reading a stuck instrument reports a stuck asset; the operating model has to include a routine check on the instrument itself. Asset moves and rebuilds interrupt continuous meter history in ways that require a deliberate meter reset, not a silent one. Mobile crews will occasionally still work from paper, particularly in areas with no signal; where they do, the meter path has to include a supervised transcription step or the reading arrives a week late with the wrong date.
None of these are reasons to abandon meter-driven maintenance. They are reasons to design for it.
The position
A PM library that trusts its calendar frequencies more than its meter frequencies is telling the reliability team what it believes about its own readings. The fix is not a bigger data programme. It is a decision, per meter, about where the reading is defined, who owns the capture path, how the arithmetic is configured and how the PM is tied to it. Estates that have made that decision run a smaller and more accurate library. Estates that have not run a large library that quietly reverts to a calendar. For how programmes of this shape are usually scoped, see the MaxIron services overview.