Running-hours monitoring with IoT sensors: the basis for usage-based maintenance

Many machines and installations do not wear out with the calendar, but with use. A pump that runs day and night needs maintenance sooner than an identical pump switched on for a few hours a week. Yet many organisations still schedule maintenance on fixed dates. Monitoring running hours with IoT sensors makes it possible to tie maintenance to actual use rather than to an assumption. This article explains what running hours are, how sensors measure them and how to get from measured data to a concrete maintenance plan.

What running hours are and why they matter for maintenance

Running hours are the accumulated time that an asset is actually in operation. For much rotating and driven equipment, such as motors, pumps, compressors, fans and generator sets, this is a better measure of wear than elapsed calendar time. Bearings, belts, filters and lubricants degrade in proportion to load and operating time, not to the date on the calendar.

That makes running hours the natural unit for usage-based maintenance: maintenance tasks are tied to an hours threshold, for example a service every 2,000 operating hours. Anyone who logs running hours reliably knows not only how long an asset has run, but can also make a well-founded estimate of when the next intervention is due.

Manual reading versus automatic measurement

Traditionally, running hours are read manually from an hour meter on the machine and copied into a logbook or maintenance system. That approach works, but has clear drawbacks:

• Low frequency. Readings happen at most daily or weekly, so you have no view of usage between two readings.
• Error-prone. Mistyping, misread counters and forgotten entries lead to gaps and errors in the data.
• Labour-intensive. For dispersed or hard-to-reach assets, manual reading takes a lot of time.
• Not every asset has a meter. Older or simple equipment often lacks a built-in hour meter.

Automatic measurement with sensors removes these objections. Logging runs continuously, is consistent and requires no manual effort. That makes recording running hours scalable across an entire machine fleet.

How IoT sensors measure running hours

An IoT sensor typically determines running hours by establishing whether an asset is on or off. This can be done in several ways:

• On/off detection via current or voltage. A current sensor around a supply cable detects consumption; if there is current, the machine is running.
• Vibration or motion. A vibration sensor detects whether a motor or pump is active from its characteristic vibration pattern.
• Pulses or switching signals. Some machines emit a pulse or a switching contact per cycle or per running interval, which the sensor can count.

The sensor then keeps track of cumulative running hours: each time the asset is active, the time is added to a running total. That counter is the equivalent of the physical hour meter, but digital and centrally available.

Important to note: sensors usually report their reading periodically, for example every hour, rather than continuously. So the value is updated hourly or periodically, not in real time. For maintenance planning that is more than sufficient, because running hours build up over days and weeks.

Connectivity: how the data reaches you

The measured running hours have to travel from the sensor to a central environment. Several network technologies exist for this. For on-site industrial use, a wireless network with long range and low power consumption is often practical, such as LoRaWAN: this enables sensors that last for years on a battery and send a small data packet over long distances. Mobile networks (for example NB-IoT) or local Wi-Fi can also be used. The choice depends on distance, coverage, energy budget and the amount of data. For running hours, which involve small, periodic messages, a low-power, long-range network is usually a good fit.

From running hours to planning maintenance

The real value emerges when the measured hours drive the maintenance plan. This is the essence of usage-based maintenance: you schedule a task not on a fixed date, but when an asset reaches a certain number of operating hours. An intensively used machine is therefore serviced sooner, a lightly used one later. That avoids both unnecessary service and intervening too late.

This connects to the broader trade-off between preventive vs corrective maintenance. Running hours give preventive maintenance a real basis: not every month because that is how it is scheduled, but when usage calls for it. As soon as an asset approaches its threshold, you can have a task created automatically in your system for work orders and maintenance planning.

Making a projection to the maintenance threshold

Besides the current reading, the trend is valuable. If you know how many hours an asset averages per day or per week, you can calculate forward to the moment the maintenance threshold is reached. If a pump is at 1,700 hours, the threshold is 2,000 hours and it runs an average of 30 hours a week, the service is due in about ten weeks. This turns a single reading into a plannable outlook.

Importantly: a projection based on the usage trend is ordinary statistics, not AI or machine learning. It is a straightforward extrapolation of the measured usage. That is precisely its strength, because it is transparent, explainable and verifiable. When the usage pattern changes, the projection shifts along automatically at the next measurements.

Points of attention for reliable data

A monitoring system is only as good as the data underneath it. So pay attention to:

• Update frequency. Know how often a sensor reports and take that into account when interpreting the latest reading.
• Coverage and connectivity. Check that all sensors are within network range, so no gaps appear in the record.
• Data quality. Missing or duplicate messages must be recognised and corrected, otherwise they distort the count.
• Calibration and threshold setting. Tune detection to the behaviour of the asset, so brief spikes are not wrongly counted as running hours, and set the maintenance thresholds to the correct values.

With careful setup, monitoring running hours becomes a reliable basis for maintenance that matches actual use rather than the calendar.