Predictive Maintenance
Act on condition, not just the calendar
A hydraulic press that runs 18 hours a day during a export order surge wears out its seals faster than one running 8 hours a day — but most Indian plants still service both on the same 30-day calendar, because that's what the maintenance planner can track by hand. The gap between "what the asset has actually done" and "what the maintenance schedule assumes" is where premature failures and wasted PM visits both come from. Predictive Maintenance in AssetAI closes that gap by tracking real usage — run-hours, cycles, kilometres — and triggering work the moment an asset earns it, not the moment the calendar says so.
What "predictive" means here — and what it doesn't
Worth being upfront about this, because the term gets used loosely. AssetAI does not ingest sensor data. There's no IoT gateway, no SCADA or PLC tag mapping, no MQTT or OPC-UA pipe, and no vibration spectrum or thermography analysis running in the background. If your plant already has an online condition-monitoring system reading bearing vibration in real time, this isn't a replacement for it.
What this module does well is the far more common shop-floor reality:
- A technician walks the line, notes down hour-meter and cycle-counter readings — on paper, in a register, in someone's phone notes.
- An experienced fitter says "that compressor sounds off" and acts on judgement, rarely written down at all.
- Maintenance still fires by date, even on assets that clearly wear by usage.
AssetAI turns the first two into structured data and the third into usage-based triggers. It's meter-driven maintenance and text-threshold condition logging — not a forecasting or anomaly-detection engine. If you're evaluating full sensor-based predictive maintenance, our industries and use-cases pages will tell you plainly where AssetAI fits and where it doesn't.
Meter readings as the source of truth
Every asset with a meter — a genset's run-hour counter, a CNC's cycle count, a forklift's odometer — gets logged with a value, a unit, the read date, an optional note, and a photo of the meter face so a supervisor can audit it later without walking back to the machine. Each reading also carries a source: manual entry, a QR scan, a WhatsApp message, or an API push from a system you already run.
A few rules keep this data trustworthy rather than decorative:
- Readings only move forward. If someone logs 4,200 hours after the last reading of 4,500, the system rejects it and asks whether a meter was replaced — a real Indian shop-floor scenario when a gauge fails and gets swapped mid-life.
- Readings are immutable. Nobody can delete a bad entry to cover a missed round; corrections go in as new readings, so the audit trail stays intact even with high contract-labour turnover.
- Logging still requires work-order or breakdown-report permission, so it's not open to anyone with the link — except through the QR scan route, which we'll come to.
Usage-based PM: how the trigger actually works
Once an asset has a meter target set — say, service due every 500 run-hours — the logic is simple and visible, not a black box:
- When the latest reading reaches or crosses the next target, AssetAI generates the PM work order automatically.
- On generation, it rebaselines: the new target becomes the current reading plus the interval, so the next trigger point moves forward from where the asset actually is, not from a fixed calendar grid.
- The very first time a meter is used, there's no target yet to compare against. Rather than firing a false work order, the nightly job auto-baselines — it seeds the target from the newest reading and waits for the next cycle. No manager needs to remember to configure a starting point.
This is meaningfully different from calendar-based preventive maintenance, and it's worth reading alongside our Preventive Maintenance page if you're deciding which trigger type fits which asset — usage-based suits equipment where wear tracks hours or cycles more than time, like presses, compressors, and material-handling fleets.
The "why am I logging this" panel
The single biggest reason meter programs die in Indian plants isn't lack of interest — it's that the person logging the reading has no idea why they're being asked, so it slips. The meter entry screen addresses this directly: it shows every active meter schedule on that asset, the current reading, and whether it's now due. A technician logging a genset's hours sees immediately that the reading is 40 hours short of triggering the next service, or that it's already overdue — context that turns a data-entry chore into an obviously useful five-second task.
Condition monitoring, honestly
The predictive (condition) type captures a monitored parameter and an alarm threshold as plain text — "vibration mm/s," "greater than 4.5," or "bearing temperature," "greater than 70°C." This is deliberately simple: it's built for the plant where condition monitoring today means a technician's trained ear and a mental threshold, not a plant with online vibration sensors and automatic spectrum analysis.
Two things to be clear about:
- AssetAI does not evaluate the threshold automatically. There's no engine watching a live feed and comparing it to 4.5 mm/s. A human takes the reading, compares it to the stated threshold, and decides to raise a predictive work order.
- There's no trend forecasting or remaining-useful-life modelling here. This captures a judgement call in a structured, auditable form — it doesn't predict when a bearing will fail.
If your maintenance strategy needs true condition-based triggers evaluated automatically off live readings, that's covered on our Condition-Based Maintenance page, which is a distinct capability from this one.
QR scans, WhatsApp, and the daily production log
Two details matter for adoption on an actual shop floor. First, meters can be logged through a public QR scan route with no login required — useful when the person walking the floor with a reading is a contract technician who doesn't have (or shouldn't have) a system account. Second, the same screen where readings get logged also captures the daily production log: planned hours, units produced, and good units, validated so planned hours sit between 0.1 and 24, good units never exceed units produced, and only one entry exists per asset per date. That log feeds directly into OEE in Analytics, so the same five-minute floor round that keeps your PM triggers honest also keeps your OEE numbers real, rather than backfilled at month-end from memory.
None of this replaces a TPM program built on ISO-aligned asset care or a proper Overall Equipment Effectiveness study — it's the data layer that makes those programs enforceable day to day. If you're trying to work out whether us
Getting Meters Onto the Floor Without a Sensor Rollout
Most Indian plants running a mix of vintage machines and newer lines can't justify a sensor and IoT-gateway project just to start tracking run-hours. AssetAI's meter capture is built for that reality: readings arrive by manual entry, barcode/QR scan, WhatsApp, or API — never by wiring up SCADA, PLC, MQTT, or OPC-UA feeds. That keeps the module usable from week one, whether the asset is a decades-old compressor or a new CNC line, and it means rollout is a process change, not a capital project.
The public QR scan route extends this further — a technician or even a contract operator can log a reading against an asset without needing a login, which matters on shop floors where not everyone carries an AssetAI account but everyone can scan a code. Every reading still carries a value, unit, read date, an optional note, and a photo of the meter face, so accountability doesn't get traded away for convenience.
- Manual entry — for control-room clerks doing rounds
- QR scan — for technicians and contractors without logins
- WhatsApp — for readings phoned or messaged in from remote assets
- API — for whatever system of record already holds the number
Data Integrity Rules That Protect the Schedule
A meter-driven PM programme is only as trustworthy as its history, so AssetAI enforces a few hard rules rather than leaving them to discipline:
- Readings only move forward. A value lower than the previous one is rejected outright, with a message prompting the user to note a meter replacement instead of silently corrupting the trend.
- Readings are immutable. Deletes are blocked entirely; a correction is logged as a new reading, so the audit trail never gets rewritten after the fact.
- Logging requires permission. Work-order or breakdown-report access is needed to add a reading, keeping the log tied to people who are actually responsible for the asset.
These constraints matter more in an Indian manufacturing context than they might elsewhere: multi-shift operations, contract labour turnover, and shared meters across sister units all create pressure to "just fix" a bad number. AssetAI's answer is to make correction visible rather than invisible.
Where This Fits Alongside Production Tracking
The same entry screen that captures meter readings also captures a daily production log — planned hours, units produced, and good units — with validation that keeps the numbers usable: planned hours between 0.1 and 24, good units never exceeding units produced, and one row per asset per date. That log feeds directly into OEE calculations in Analytics, so the discipline of logging a meter reading and logging a production figure become one habit instead of two separate reporting burdens.
This pairing reflects how TPM-style programmes are meant to work — maintenance and production data reinforcing each other rather than living in separate spreadsheets. If you're building a maintenance function from scratch, the What is a CMMS primer covers where predictive maintenance sits in the broader picture, and the full features list shows how meters, condition watches, and production logs connect to work orders and inventory elsewhere in AssetAI. For a structured look at rollout across shifts and asset classes, book a demo and walk through your own meter list.
Predictive Maintenance FAQs
How does AssetAI decide when an asset has actually "earned" its next service, since usage isn't the same every day?
It compares the latest logged run-hour, cycle, or kilometre reading against a threshold set for that specific asset — not against the calendar, and not through any predictive algorithm forecasting failure. A technician records the meter reading during a walk-round, the system adds it to that asset's usage history, and the moment the cumulative figure crosses the defined threshold, a work order is triggered — whether that takes ten days or forty. This is why two identical presses running different shift patterns can end up on different service dates even though they were commissioned on the same day. You can see how this sits alongside other scheduling logic on the features page.
Can I run usage-based triggers alongside my existing calendar-based PM schedules, or do I have to pick one?
You can run both — nothing forces you to convert every asset to usage tracking at once. Some equipment genuinely wears by time (seals degrading from ambient exposure, for instance) and is fine on a date-based schedule; others wear by usage and are better served by run-hour or cycle triggers. AssetAI doesn't require an all-or-nothing switch — each asset's maintenance plan is configured on its own, so a plant can keep date-based PM on low-variability equipment and move high-variability equipment like the export-surge hydraulic press onto usage triggers. The use-cases page walks through how different asset types typically get set up.
What happens if a technician forgets to log a reading for a few days — does the system estimate the missing usage?
No, it doesn't interpolate or estimate — the last logged reading is what the system works with until a new one comes in. If nobody records the hour-meter for five days, the asset's usage total simply doesn't move during that gap, and any threshold-based trigger waits accordingly. This means the accuracy of the whole approach depends on how consistently readings get logged on the floor — it digitises the walk-round register, but it doesn't replace the discipline of doing the walk-round. Some plants build a simple checklist into their rounds to avoid missed entries; there are templates for this kind of routine on the resources page.
How do I set usage thresholds when different machines are measured in hours, cycles, or kilometres?
Each threshold is configured per asset, in whatever unit that asset is actually tracked in — hours for a compressor, cycles for a press, kilometres for a forklift or delivery vehicle. There's no single global rule; a maintenance planner sets the trigger point individually for each machine based on its manual, its OEM recommendation, or its own failure history, and AssetAI simply watches the logged readings against that number. This keeps the logic asset-specific rather than forcing every machine onto the same convention. Setup details for different asset categories are covered on the use-cases page.
Does tracking run-hours and cycles instead of sensor data count as "predictive maintenance" under ISO or TPM definitions?
It's a recognised usage-based maintenance strategy, but it's worth being precise about where it sits — standards bodies generally distinguish usage-based tracking from condition-based monitoring, which relies on measured physical parameters like vibration or temperature. AssetAI's module is the former: it closes the gap between actual usage and calendar assumptions using run-hours, cycles, and kilometres logged by people, not sensors reading equipment condition in real time. If you need the formal terminology for audits or documentation, the ISO standards reference and background on TPM practices are useful starting points, and our own standards page maps out how AssetAI's features relate to them.
Our spindle motors run 24/7 but consumption varies wildly by product — how do we set realistic usage thresholds without over-servicing?
AssetAI lets you baseline thresholds from actual historical data, not guesswork. Log 2–3 weeks of normal runs, then set alerts at 80% of observed peak usage. You can also create product-specific profiles so a textile spindle and injection mold don't share the same limit. Adjust quarterly as product mix changes.
If a pump fails at 60% of its scheduled threshold, will AssetAI flag that retroactively to help us recalibrate future thresholds?
Yes. The failure analysis dashboard logs the actual usage at failure point and compares it against your threshold. Use this to tighten thresholds on high-risk assets or extend them where data shows you're over-conservative. This feedback loop prevents repeat failures.
See Predictive Maintenance on your own machines
A 30-minute demo on your plant, not our slides.