Meter-Based Preventive Maintenance: Stop Servicing the Machine That Sat Idle

You have two identical presses. Same model, same year, bought the same week.

One ran three shifts a day all quarter. The other sat idle for six weeks waiting on a customer approval.

On Monday, your maintenance schedule says both are due for service. So a technician spends the morning opening up a machine that has barely turned over, while the one that has been hammering since April waits its turn.

Nobody is doing anything wrong. The calendar simply does not know which machine did the work.

Meter-based preventive maintenance fixes that by scheduling on what a machine has actually done rather than on what month it is. The idea is old and uncontroversial. The reason most plants still do not use it is much more boring: nobody wants to be the person who walks the floor writing hour-meter readings on a clipboard.

This is about how Qualis gets those numbers without the clipboard, and without buying a single sensor.

Where the calendar quietly lies to you

A quarterly service is a promise about the calendar, not about the machine. It is right on average and wrong for every individual asset.

That cuts both ways, and both ways cost you:

• Too late. The machine that ran 900 hours gets serviced on the same day as the one that ran 100. You find out which one needed it sooner when something lets go mid-order.
• Too early. You shut down a healthy machine, take it apart and put it back together. That is a morning of labour, a drum of fluid, and lost capacity, spent on an asset that was fine.

That second one is not just waste. Opening up a healthy machine carries its own risk. NASA's Reliability-Centered Maintenance Guide puts it flatly: "in many cases scheduled overhaul increases the overall failure rate by introducing a high infant mortality rate into an otherwise stable system." The same guide, drawing on three separate failure-pattern studies, found that only 8 to 23 percent of failures showed age-related characteristics at all.

If you have ever heard a supervisor mutter that things only ever break right after a PM, they are not being superstitious.

The fix is not to service less. It is to service on evidence: this machine has run 412 hours since it was last touched, so it is due, and that one has run 60, so it is not.

The real reason you are not doing this already

Ask any maintenance planner why they schedule on the calendar and you will not hear "I prefer it." You will hear something about where the number comes from.

Today the market offers you two options, and both have a catch.

Option one: somebody writes it down. A person walks the floor, squints at an hour meter, writes 412, and the sheet sits in a tray until Thursday. The machine crossed its threshold on Tuesday. And when the walk-around gets skipped during a busy week, the schedule does not go quiet, it goes wrong.

SAP, which has the most mature counter-based maintenance in the business, documents exactly this failure in its own manual. Because its performance-based plans schedule forward from an estimated annual usage rate rather than purely from the last reading, SAP warns that "it is important that you enter the current counter reading regularly, even if it has not changed. Otherwise, the system generates call objects (for example, maintenance orders) based on the estimated annual performance entered for the counter, even though the counter reading has not in reality been reached."

Read that again. Stop entering readings and the system keeps issuing work orders for usage that never happened. The clipboard is not a nice-to-have in that model, it is load-bearing.

Option two: buy sensors. Instrument every machine and the readings arrive by themselves. It works, and for high-value condition monitoring it is the right answer. It is also a project rather than a setting, especially on the older machines that need the attention most. As Josh Eastburn of Opto 22 told Automation World, "establishing connectivity has been more difficult for un-instrumented equipment not designed to communicate externally." And Trevor Diehl of DelmiaWorks flagged the part everyone forgets: "making sure that sensors are calibrated appropriately is a long-term difficulty that few people plan for."

Most plants look at those two options and pick neither. IoT Analytics found that 54 percent of plants globally were still running manufacturing operations on pen, paper and spreadsheets as of 2024.

There is a third source, and you are already filling it in

Here is the thing about a discrete manufacturing plant: your operators are already telling you how hard every machine worked. They do it every time they close out an operation.

When a work order is completed, somebody records the machine time booked against it and the good quantity that came off. That is a usage report. It just never reached maintenance.

Qualis connects those two halves. Complete an operation, and the machine that ran it gets credited with the hours and the cycles. Automatically, with no extra data entry and no hardware.

Three meters are created the first time they are needed, so there is nothing to configure before your first completed operation:

1. Run hours, from the machine minutes booked on the operation.
2. Cycles, from the good quantity that came off it.
3. Shot count, the same quantity read from the tool's point of view, credited to the mould or die that was in the machine.

That last one matters more than it looks. A mould has a service life measured in shots, not in months, and it moves between machines. Because Qualis treats the tool as its own asset, it accumulates its own shot count wherever it happens to be running.

What it looks like on the asset

Open any machine you have registered as a maintenance asset and its meters sit on their own tab, with lifetime total, usage since the last service, and an average daily rate that tells you roughly when it will come due.

The green From production tag is the important part. It means nobody typed that number.

Expand the history and every single reading is there, stamped with where it came from and traceable to the work order that produced it:

The tooling side looks the same, except the counter is measuring how many times that mould has closed:

The details that decide whether you can trust the number

A usage counter is only useful if you believe it. Most of the engineering here went into the ways a counter can quietly go wrong.

A replayed message never counts twice. Every production-fed reading carries the work order that caused it as its identity. If the same completion is delivered twice, or a background job retries, or you re-run the history import, the system recognises the reading it already has and adopts it instead of adding it again.

Old machines start from zero, not from ten years ago. Register a machine that already has 40,000 hours on its physical hour meter and enter that number, and Qualis treats it as a baseline rather than as 40,000 hours of usage it just observed. Your averages stay honest.

Physical meters that roll over are handled. If you do take manual readings from a counter that wraps back to zero, set the rollover point and mark the reading, and the wrap is calculated instead of showing up as an impossible negative.

A gauge is not a counter. Pressure and temperature measure a level, not usage. Qualis records them, charts them, and never lets them add to a lifetime total.

Multi-cavity tooling is divided properly. A 4-cavity mould makes four parts per shot, so 200 parts is 50 shots, not 200. Set the units per cycle on the meter and the arithmetic follows.

You can opt any asset out. Some equipment should not be tracked from production at all. One toggle on the asset stops the feed without deleting its history.

Manual readings still work. The production feed is a source, not a replacement. Type a reading on the same card whenever you want, and if you do have sensors, there is an API to post readings from them. Every reading shows which source it came from.

And the ledger cannot be forged. Meter readings are append-only and can only be written by the service that owns the arithmetic. There is no back door that lets a stray integration inject usage that never happened.

How other ERPs handle meter-based preventive maintenance

Meter-based maintenance is not new. It is just missing from the middle of the market.

At the top, SAP is the reference implementation and has been for decades: measuring points, counters, measurement documents and several plan shapes, in the core product. But readings still arrive by hand, by mobile app, or through an integration you build. Its closest equivalent to capturing usage from execution has a person keying readings into a confirmation screen, behind a business function an administrator has to switch on first.

At the other end, Odoo's standard Maintenance app, the most likely comparison for a mid-market manufacturer, recurs on a calendar: a preventive request repeats every so many days, weeks, months or years. Its reliability metrics, MTBF and an estimated next failure date, are advisory figures expressed in days rather than usage triggers. Meter-driven maintenance in Odoo comes from add-ons rather than from the standard app.

NetSuite has no native CMMS. What Oracle labels maintenance inside Fixed Assets Management is four fields: inspection, inspection period in months, warranty, warranty period in months. Its Field Service Management Programs schedule on date intervals.

In between, it is usually a question of which bundle you are on. Epicor puts Maintenance Management inside an optional Assets Bundle, and its runtime-and-cycles preventive maintenance lives in Advanced MES, a different product. Infor's own documentation says plainly that "APM is an CloudSuite Industrial add-on product that is a subset of the Service management solution." Katana has no maintenance surface at all. MRPeasy genuinely does count operating hours and units processed from what workers report, which is the same idea, but it is gated to its higher per-user tiers and scoped to workstations rather than to a general asset register that can also hold your moulds, compressors and forklifts.

None of that is a scandal. It is just why so many plants end up running maintenance in a spreadsheet beside an ERP they already pay for.

The honest limits of usage-based maintenance

This measures booked time, not powered-on time. Run hours come from the machine time recorded against operations. If a machine idles in the middle of a job, that time still counts. If somebody runs test shots or a quick rework without booking them, that time does not. At the granularity of a 500-hour service interval, that error is comfortably acceptable. For vibration analysis or true condition monitoring, it is not. This replaces the clipboard, not the sensor.

Frequently Asked Questions

What is meter-based preventive maintenance?

It is scheduling service against a measure of what the equipment has actually done, such as run hours, cycles, shots or units produced, instead of against the calendar. A press serviced every 500 operating hours is on a meter-based schedule. The same press serviced every quarter is on a calendar schedule, whether it ran hard or sat still.

How do I track machine run hours without an hour meter or IoT sensor?

Derive them from work you already record. In Qualis, completing a production operation credits the machine that ran it with the machine time booked and the quantity produced, so the counters fill themselves from shop-floor reporting. No walk-around, no gateway, no retrofit.

Where do meter readings come from, and which source should I trust?

There are three practical sources: a person reading a physical meter, a sensor, or your production records. People forget and transpose digits, sensors cost money and need calibrating, and production records are already being captured for other reasons. Qualis accepts all three and labels every reading with its source, so you can always see whether a number was typed, posted by an API, or derived from a completed operation.

Can I use both a calendar interval and a usage interval?

Yes, in the sense that matters: an asset can carry usage counters and still sit on a date-driven service plan, and you can look at both before deciding. Qualis does not yet fire a work order automatically at "500 hours or 6 months, whichever comes first"; today the counters and the average daily rate tell you when it is close, and you schedule the order.

What happens to a usage-based schedule if readings stop arriving?

This is the question that decides whether the whole approach is safe. Some systems extrapolate from an assumed usage rate, which means they keep raising work orders for machines that never ran. Because Qualis derives readings from completed operations, a machine that produced nothing simply records nothing, and its counter stops where it is. No usage, no phantom usage.

Which counters actually matter in discrete manufacturing?

Run hours for spindles, motors and hydraulics. Cycles or strokes for presses and stamping equipment. Shot count for injection moulds, where tooling life is quoted in shots and the tool moves between machines. Qualis creates all three from production automatically, and you can add your own for anything else you measure.

The bottom line

Usage-based maintenance has never been the hard part. Getting the usage number has been.

You can pay people to walk the floor with a clipboard and accept that the data is a few days stale and occasionally wrong. You can instrument the plant and take on a connectivity project. Or you can notice that every completed operation already says how long the machine ran and how much came off it, and let that count.

Qualis takes the third route. Register the machine, complete your work orders as you already do, and the run hours, cycles and shot counts accumulate on their own, each one traceable back to the operation that caused it.

Then service the press that did the work, and leave the one that sat idle alone.

Ready to see it on your own equipment? Start a free trial of Qualis and open the Maintenance module, or read how the same production data drives full lot and serial traceability.