Condition-Based Maintenance
Maintain when the machine says so
Most Indian plants don't lack maintenance discipline — they lack a cheap way to know when a machine has actually done enough work to need attention. Calendar-based PMs get skipped or done early because nobody trusts the date; sensor-based condition monitoring gets shelved because a vibration or thermography rig for forty compressors is a capital decision, not a software one. AssetAI's condition-based maintenance module gives you the middle path: schedule work off real usage — run-hours, cycles, tonnage — captured by hand, and record condition parameters honestly, without pretending to watch them for you.
Usage-Based Scheduling: The Part That Actually Triggers Work
The workhorse here is the meter/usage schedule, not a sensor threshold. Each schedule stores a meter unit (hours, cycles, km, tonnes — whatever your asset runs on), an interval, and the last and next meter targets. The moment a logged reading reaches or crosses the next target, the schedule is due and a work order is raised.
- A schedule doesn't start counting from zero — it baselines the target from the first reading you log against it. Until then it correctly reports "not due," because there's nothing to compare against yet.
- A daily background job checks every active schedule, and each time the target is hit it rolls the next target forward by the interval — so a 250-hour filter change schedule keeps resetting itself at 250, 500, 750, without a planner re-entering it every cycle.
- The Meter Readings screen lists every active schedule in one place, with the current reading and a clear due/not-due flag, so a shift supervisor can glance at it instead of digging through work order history.
This suits equipment serviced on wear, not calendar — presses on stroke count, compressors on run-hours, DG sets on operating hours through a power-cut-heavy monsoon. It's a more honest trigger than "every 30 days" for machines that run three shifts one month and sit idle the next.
Getting Readings Off the Floor Without New Wiring
The realistic failure point of any usage-based system in an Indian plant isn't the software — it's getting the number logged consistently, shift after shift, by contract labour who may not all be comfortable with a desktop screen. AssetAI supports four ways to push a reading in, all landing in the same meter history:
- The internal Meter Readings screen, for planners and supervisors working at a desk or a shared terminal.
- The public QR scan page — a technician scans the asset tag on the machine, and if a photo of the gauge is uploaded with the value left blank, OCR reads the number off the photo.
- A WhatsApp command — `METER <asset code> <reading>` — for technicians who will always answer WhatsApp faster than they'll open an app.
- An authenticated API POST, for anyone who already has a script or a hand-held device pushing values in, rate-limited at 120 requests a minute.
Every reading carries value, unit, date, an optional note and photo (capped at 8 MB), and its source, so you can tell later whether a number came off a WhatsApp message or the QR page. Validation is deliberately simple and mechanical rather than clever: the reading must be numeric and zero or above, and — the one rule that matters most on a shop floor where someone will occasionally key in yesterday's number by mistake — a reading lower than the previous one is rejected. Meters only move forward. If a hand-entered figure looks wrong, the system stops it at the door instead of quietly corrupting the schedule.
What "Condition-Based" Honestly Means Here
Every predictive-type schedule also carries a monitored parameter and an alarm threshold as free text — say, "vibration, mm/s" and "> 4.5." Be clear about what happens to those fields: they are recorded, not read. There is no numeric validation on the threshold, no code evaluating whether a submitted reading breaches it, no trend chart, no alarm band, and no notification if a value crosses the line you defined. It's structured documentation of your condition-monitoring intent, useful for audits and for ISO-aligned maintenance records, not a live monitoring system.
If your plant is investing in IoT, SCADA, MQTT, OPC-UA or Modbus feeds to auto-trigger work orders on a sensor breach, this module isn't that, and we'd rather say so now than have you discover it after go-live. The only machine-data path into AssetAI is the authenticated meter-reading API — a person or a script pushing a number in, not a live tag subscription. For genuine sensor-driven alerting you'll want a dedicated condition-monitoring platform sitting alongside AssetAI; our Predictive Maintenance page covers where that boundary sits in more detail.
From Logged Numbers to OEE
Meter readings tell you when to service a machine; daily production logging tells you what that machine actually delivered. Log planned hours, units produced and good units per asset per day, and this feeds straight into per-asset OEE in Analytics — the same OEE framing used in TPM programmes, but built from numbers your own supervisors log rather than a data historian. Planned hours are validated between 0.1 and 24, and good units can never exceed units produced — small guardrails, but they stop the two most common data-entry errors that quietly wreck an OEE report.
Who This Is Actually Built For
- Plants that service equipment on run-hours or cycles and want that trigger automated without buying sensors — a stamping shop counting strokes, a bottling line counting cycles, a DG set counting hours.
- Maintenance heads who want defensible OEE and downtime-loss figures built from disciplined manual logging rather than no data at all.
- Multi-lingual, multi
Getting the Rollout Right on the Shop Floor
Condition-based scheduling only works if meter capture becomes a habit, not a monthly scramble. Start with the assets where run-hours or cycles genuinely predict wear — hydraulic presses, compressors, gearboxes — rather than rolling it out plant-wide on day one. For a 40-machine unit, that's usually 8-10 critical assets to begin with.
- Assign one person per shift to log readings, even if it's the same operator noting a panel counter by hand on the QR scan page or over WhatsApp — consistency matters more than precision.
- Decide the meter unit before you create the schedule. Switching a compressor from "hours" to "cycles" midway means the interval and baseline no longer mean anything.
- Expect the first few weeks to look "not due" everywhere — a schedule only starts counting once its first reading baselines the target, so don't assume the module is broken if nothing fires immediately.
Common Mistakes Plants Make
The most frequent failure isn't technical — it's treating the condition parameter field as if it does something. Since parameter and threshold are free text with no numeric validation and nothing evaluates them, typing "vibration > 4.5 mm/s" only documents intent; it will not raise a work order or send an alert on its own. Teams that expect an automatic escalation here end up disappointed, not because the software failed, but because they read a text field as a live sensor feed.
- Don't let contract labour log readings that go backward — the system rejects any value lower than the last one, which is correct behaviour for a meter, but it means a wrongly-reset counter or a swapped gauge needs a manual correction, not a re-entry.
- Don't skip the "note" and "photo" fields on borderline readings. When a reading is disputed later — especially with multi-lingual technicians across shifts — a photo settles it faster than an argument.
- Don't wire this to expectations of OPC-UA, MQTT or SCADA feeds. There is no such integration; the only machine-data path in is the authenticated meter POST, rate-limited to 120 calls a minute, which is plenty for manual or scripted entry but not a live telemetry pipe.
What to Measure Once It's Running
Once meter logging is steady, the useful signal isn't the condition field
Condition-Based Maintenance FAQs
How do I set up a usage-based maintenance schedule for a machine that runs on both hours and cycles?
You create two separate schedules, one per meter unit, rather than combining them into a single counter. Each schedule in the system stores exactly one meter unit — hours, cycles, km, tonnes — along with its own interval and last/next target, so a machine tracked on both operating hours and production cycles needs two independent schedules running in parallel. Each one only reacts to readings logged against its own unit, and each rolls its own next target forward once triggered. Neither schedule "knows" about the other's count. This keeps the logic simple and auditable instead of trying to build a composite formula. You can see how schedules are structured under features before setting one up for a multi-metric asset.
Do I need IoT sensors or a vibration monitoring system to do condition-based maintenance?
No — the core trigger here is a manually logged meter reading, not a sensor feed. A schedule only needs someone to record a run-hour, cycle count, or tonnage figure against the asset; there's no requirement for vibration probes, thermography cameras, or continuous telemetry. Condition parameters can also be recorded by hand, honestly, at whatever interval you choose to check them, rather than being watched automatically. This is what makes the approach usable on assets where a full sensor rig would be a capital decision nobody wants to make. It's a deliberate middle ground between doing nothing and instrumenting everything, which is why it fits plants across different industries with very different budgets for monitoring hardware.
What happens if nobody logs a meter reading for a few weeks — does the schedule fall apart?
No, the schedule just stays "not due" until a reading is logged — it doesn't drift, break, or assume usage happened in the gap. Because the next target only moves when an actual logged reading reaches or crosses it, a missed logging period simply delays the trigger rather than corrupting it; there's no clock running in the background pretending to count hours you didn't record. The daily background job still checks every active schedule, but it has nothing to compare until a fresh reading comes in. Once someone does log a reading, the schedule evaluates it against the existing next target immediately. Some worked examples of this are covered in the resources section.
How is condition-based maintenance different from a normal calendar-based preventive maintenance schedule?
The difference is what triggers the work order — a logged usage reading instead of a date on a calendar. A calendar PM fires because a day arrived, regardless of whether the machine actually ran; a condition/meter-based schedule only fires once a real reading — hours, cycles, tonnes — crosses the stored next target, so idle machines don't get serviced early and heavily used ones don't get skipped. Both approaches can coexist as preventive maintenance strategies within the same CMMS, but the meter-based version ties the work order to actual wear rather than the passage of time, which is closer to how the machine is actually being used on the floor.
Does condition-based maintenance in AssetAI help with ISO 55000 or TPM-style audit requirements?
It helps by creating a logged, timestamped record of usage and condition data, which is the kind of evidence auditors for asset management or TPM programs typically ask for. Every meter reading and condition parameter entry is recorded against a specific schedule and asset, along with when the next target was last rolled forward, so you have a traceable history of what triggered each work order and when. It doesn't certify you against any standard on its own, but the underlying records — real readings tied to real dates — are the raw material that standards-aligned programs need. It's worth comparing against how TPM documentation expects usage data to be tracked.
Can condition-based maintenance replace vibration analysis or thermography completely?
No — it's meant to sit alongside those methods where they're not financially or practically feasible, not replace them everywhere. The module works by scheduling off logged usage (run-hours, cycles, tonnage) and by letting you record condition parameters manually and honestly, rather than continuously monitoring them the way a vibration or thermography rig would. For assets where sensor-based monitoring already exists, that data can still inform decisions separately; for the much larger set of assets where instrumenting every unit isn't a realistic capital decision, usage-based scheduling gives you a working trigger instead of no system at all. You can review how this fits into broader maintenance planning under use-cases.
If a machine has multiple condition parameters (oil temperature, vibration, pressure), how do I set different action thresholds for each one in AssetAI?
AssetAI lets you define separate meter thresholds for each parameter independently. Set "alert" and "action" levels per meter—for example, oil temp alert at 65°C, action at 75°C, while vibration alert triggers at 7.5mm/s. When any meter crosses its action threshold, a work order generates. Check Meter Configuration for step-by-step setup of multi-parameter monitoring.
See Condition-Based Maintenance on your own machines
A 30-minute demo on your plant, not our slides.