Control Equipment & Fuel Usage
Track usage and service by real run-hours.
How to Control Equipment & Fuel Usage
For diesel generators, air compressors, boilers, and any equipment where duty cycles matter more than the calendar, AssetAI turns run-hour and fuel readings into a structured, forward-only log that drives servicing and surfaces cost — replacing the paper run-hour register most Indian plants still keep at the panel.
How a Reading Becomes a Work Order
Every usage-based schedule stores a unit, an interval, the last recorded meter value, and the next target. Operators log a new reading through manual entry, the QR scan page, a WhatsApp command, or the API — each entry carries value, unit, date, an optional note, and a photo. The moment a logged reading reaches or crosses the next target, AssetAI raises a work order automatically, inheriting the title, asset, and checklist steps from the schedule, exactly as a time-based PM would.
A few mechanics keep this reliable:
- Forward-only readings — any value lower than the previous one is rejected outright, so the usage history can't be walked back or manipulated to delay a due service.
- Auto-baselining on first run — if no target exists yet for a schedule, the daily job seeds the next target from the newest reading instead of firing a work order prematurely on day one.
- The "why am I logging this" panel — the meter entry screen lists every active schedule against that asset, its current reading, and whether it's now due, so operators aren't guessing which meter matters.
- OCR-assisted QR entry — on the scan page, leaving the value field blank triggers OCR to auto-fill the meter reading from a photo, useful for gauges that are read manually today.
Due detection itself runs through the same daily 06:00 job that raises other PM and PdM work orders — there's no separate real-time "usage limit crossed" push alert, so plants should plan around that daily cadence rather than expect instant notification the moment a threshold is crossed.
What This Does — and Doesn't — Replace
Fuel and run-hours are logged as generic meter readings (litres, hours, cycles), which is enough to trigger servicing but stops short of a dedicated fuel-consumption module — there's no unit conversion engine or fuel-cost report, and no live tank-gauge or telemetry feed. If your generators or compressors already push data via API, that shows up simply as an API-tagged reading source; anything beyond that, like a purpose-built fuel-sensor integration, would need to be confirmed separately.
Where AssetAI does add clear financial visibility is on the cost side:
- Downtime cost per asset (downtime cost/hour × downtime hours) feeds a top-8 Pareto and rolls into 30/90/180/365-day KPI windows, so the plant sees which equipment's usage-driven breakdowns are actually expensive.
- Parts, outside services, and labour costs attach to the same work-order record, giving a per-asset view of what a usage-triggered service actually cost to execute.
- The Pareto can optionally show units of output lost, calculated from the asset's rated output, connecting downtime directly to production impact.
For equipment with a production log, this cost data complements OEE-style thinking on availability and performance — see OEE explained and the broader concept of TPM — but machines without a production log are simply skipped for efficiency figures rather than estimated. If you're new to the category, the What is a CMMS primer covers the fundamentals this use case builds on, and the full features list shows how meter-based PM fits alongside condition-based and time-based scheduling.
What Shows Up on the Cost Side
Run-hours matter to a maintenance team because they eventually turn into money — breakdowns, parts, and labour. AssetAI ties usage data to cost so a plant can see which generator, compressor, or boiler is actually expensive to keep running, not just which one runs the most.
- Downtime cost per asset is calculated as downtime cost/hour × downtime hours, and rolls into a top-8 Pareto view so the worst offenders are visible at a glance.
- KPI windows at 30/90/180/365 days let a plant manager check whether a machine's cost is trending up as usage climbs, rather than only reacting after a failure.
- Work-order cost lines — parts, outside services, labour — attach to the same BM/CM/PM/PdM record that the usage trigger created, so the service cost tied to a specific run-hour threshold is traceable, not buried in a general ledger.
- Output lost, optionally — the same Pareto can show units of output lost during downtime, computed from the asset's rated output, giving a production-side view of the same event.
None of this requires a separate fuel-cost module. It works because every usage-triggered work order already carries its cost lines back to the asset, which is enough to answer "what is this machine costing us" without a dedicated report.
Where This Fits Alongside OEE and Condition Monitoring
Run-hour tracking answers "when should this be serviced," but plants running duty-cycle-heavy equipment usually want two more views next to it, and AssetAI keeps them distinct rather than blending them into one number.
- Production-linked efficiency — OEE figures depend on a production log existing for the asset in question; a generator or compressor without one is simply skipped, so efficiency isn't guessed at or estimated from usage alone. Where a production log does exist, the same run-hour data feeds into standard OEE thinking without a separate calculation layer.
- Condition-based schedules — vibration, temperature, or any monitored parameter with an alarm threshold (say, vibration above 4.5 mm/s) generates PdM work orders on its own basis, independent of meter readings. A compressor can have both a run-hour PM and a vibration-based PdM schedule active at once, each firing on its own logic.
- No streaming feed, by design — every reading is a point-in-time entry, whether typed in, scanned via QR, sent by WhatsApp, or pushed through the API. There's no live tank gauge or telemetry dashboard here, and being upfront about that boundary matters more than overselling a feature that isn't there.
This layered approach — usage schedules, condition schedules, and cost visibility — sits inside AssetAI's broader set of features, built around the same maintenance discipline described in TPM practice and referenced against frameworks like ISO standards for asset management. If your plant is still deciding whether a structured system is worth the change from a panel logbook, the What is a CMMS primer is a reasonable starting point, and the industries page covers how this plays out across sectors beyond generators and compressors. For a plant-specific walkthrough, book a demo.
Control Equipment & Fuel Usage FAQs
How do I stop operators from logging false fuel readings to avoid maintenance?
AssetAI rejects any reading lower than the previous one, so usage history cannot be walked backward or faked downward. Once a fuel-litre reading is logged with a date and source, the system treats it as locked. If an operator tries to enter a lower value, the entry is refused immediately. This creates an audit trail where every reading moves forward only, making it impossible to hide consumption or delay preventive maintenance work orders by under-reporting fuel use.
When does a maintenance work order trigger if I use meter readings instead of calendar intervals?
A work order is raised automatically the moment the latest logged reading reaches or exceeds the next target threshold you set. You define a usage interval (e.g. every 500 litres) and AssetAI tracks when that target is hit. On the first run, if no target exists yet, the system auto-baselines from the newest reading instead of firing a premature order, so you don't get false alarms during initial setup. Once the target is set, the trigger fires only when actual usage crosses it.
Can I log fuel readings from my phone or WhatsApp instead of typing them into a dashboard?
Yes. AssetAI accepts fuel readings via manual entry, QR scan page, WhatsApp command, or API. Each reading captures the value, unit, date, optional note, optional photo, and the source method used. This flexibility lets operators log litres or run-hours from the shop floor without visiting a computer, and the source tag tells you later whether the reading came from a manual entry, a barcode scan, or an automated system connection.
How do I see which assets are costing the most due to downtime and fuel inefficiency?
AssetAI rolls downtime cost (downtime cost per hour × actual downtime hours) into a top-8 Pareto chart and into 30/90/180/365-day KPI windows by asset. Work-order cost lines—parts, outside services, labour—attach to the same maintenance record, so you see the total service cost tied to each usage trigger. This binds fuel and maintenance spending to the same asset view, making it visible which machines are the biggest cost drivers. Check your glossary/oee to understand how this feeds into overall equipment effectiveness tracking.
If I use an API to push fuel readings from my fuel-monitoring device, how does AssetAI handle them?
AssetAI logs API-fed readings just like manual or WhatsApp entries: it records the value, unit, date, and tags the source as "API" so you know the reading came from an automated system. The reading still follows the forward-only rule—no value can drop below the previous one—and it still triggers work orders when the next meter target is reached. However, AssetAI does not offer fuel-specific unit conversion or a dedicated fuel-consumption dashboard; fuel is treated as a generic meter reading and tracked within the general usage framework.
Why do I need to log fuel readings in a CMMS when I already have a fuel-purchase invoice?
Purchase invoices tell you what you bought, not what you burned. Usage readings tied to work orders and downtime cost let you connect fuel spending to maintenance events and asset performance. When you log fuel litres as a meter reading, AssetAI can trigger preventive maintenance schedules based on consumption instead of calendar days, and tie the cost of that maintenance back to the same asset record. This closes the loop between fuel consumption, maintenance timing, and total cost of ownership—something an invoice alone cannot do.
Our plant has 15 diesel generators, but operators sometimes forget to log fuel consumption. How do I ensure consistent fuel data collection?
Set up automated meter reading integration if your generators have fuel gauges or flow meters—AssetAI can pull readings on a schedule without operator intervention. For manual logging, create shift checklists tied to work orders so fuel entry becomes part of routine handover. You can also flag assets in predictive maintenance rules to alert supervisors when readings are overdue, reducing gaps in your fuel consumption history.