ISO 18436 — Condition Monitoring Competence
How AssetAI supports practices aligned with ISO 18436.
What ISO 18436 covers
ISO 18436 defines the training and certification categories (I–IV) that qualify people to perform vibration analysis, oil analysis, thermography, and ultrasound-based condition monitoring. AssetAI does not certify or track those personnel qualifications — it runs the mechanical side of a condition-based maintenance programme: storing monitored parameters, thresholds, and readings, and turning a breach or a due date into a costed, traceable work order.
What ISO 18436 Governs vs What AssetAI Records
It's worth being precise about the boundary, because the two are easy to conflate. ISO 18436 is a competence standard — it says who is qualified to interpret a vibration spectrum or an oil sample. You can read the standard's scope directly at iso.org. AssetAI does not perform that interpretation and does not hold a category, certificate ID, or expiry field for the person doing it.
What it does hold is the data trail around the decision:
- A predictive schedule with a monitored parameter (say, vibration in mm/s) and an alarm threshold (say, > 4.5) that generates a PdM work order the moment the condition is logged as breached.
- A parallel usage-based path — meter unit, interval, last and next reading — for equipment monitored by running hours or cycles rather than a condition threshold.
- A technician field on every CM-triggered work order (internal technician, supervisor, or external contact) with a labour line costed at that technician's hourly rate.
If your plant already has a qualified analyst reading the spectrum or the oil report, AssetAI is where the resulting inspection turns into a scheduled, assigned, and costed job — not where the analyst's qualification lives. For a broader look at how this fits into a maintenance system generally, see what is a CMMS.
Getting Readings Into the System Without a Data-Entry Team
A condition-monitoring programme is only as good as its reading discipline, and most Indian plants run into the same problem: readings taken on a clipboard never reach the CMMS. AssetAI accepts meter and condition readings through four channels — the Meter Readings screen, a QR scan page with photo OCR, a WhatsApp command, or the API — so a technician on the shop floor can log a value without opening a desktop app. Every reading carries a value, unit, date, note, and optional photo, and the system rejects any reading lower than the last recorded one, which keeps meter-driven due dates from being corrupted by a typo.
This matters for the same reason OEE tracking matters: the schedule downstream of a bad reading is only as trustworthy as the reading itself.
Why the Closure Gate Matters for CM Programmes
Every breakdown- or condition-triggered work order in AssetAI enforces a failure cause and a failure remedy, drawn from master lists, before it can be closed — alongside free-text root cause and closure remarks. That gate is enforced in two separate code paths, not just at the UI level, so a technician can't skip it under pressure to close the ticket. Over time this produces a failure Pareto that reflects what actually broke and why, rather than a log of "fixed" with no structure behind it. This is the layer that makes a CM programme auditable, whether or not the people running the analysis carry an ISO 18436 category.
If you're evaluating whether AssetAI's mechanical CM tooling fits your current condition-monitoring setup, compare it against your full requirements on /features, check the standards library for related pages, or book a 30-minute demo on your own plant's data.
Who Did the Job and What It Cost
A condition-monitoring programme is only as useful as the record it leaves behind. When a vibration threshold is breached or a meter reading crosses its due point, AssetAI generates a work order that carries a technician field — an internal technician or supervisor, or an external technician's contact — and a labour line costed at that person's hourly rate. This is deliberately narrow in scope: it answers "who worked on this asset and at what cost," not "is this person qualified under ISO 18436 Category II." The two questions look similar but serve different purposes, and a plant running condition-based maintenance needs both answered somewhere — just not necessarily in the same field.
For a maintenance head building out a CMMS, this distinction matters at budget time. Labour costed against real CM work orders rolls up into a defensible cost-of-maintenance figure per asset or per failure mode, independent of whatever certification records the plant keeps in HR or a training file. AssetAI doesn't try to own that certification record — it owns the transaction: parameter breached, work order raised, technician assigned, hours costed, job closed.
Setting Up a CM Programme Without Overreaching the Tool
Plants adopting condition-based maintenance for the first time often try to make one system do everything — readings, work orders, costing, and personnel qualification tracking. That's a reasonable instinct but not how AssetAI is built, and forcing it usually means bolting on spreadsheets that drift out of sync. A cleaner split looks like this:
- Keep ISO 18436 category records, certificate numbers, and renewal dates in whatever system your training or HR function already uses — a register, a document store, or a dedicated competency tool.
- Use AssetAI for the predictive schedule itself: monitored parameter and alarm threshold, or meter unit and interval, on each asset.
- Let readings — whether typed in, scanned by QR with photo OCR, sent by WhatsApp, or pushed by API — drive due dates and thresholds automatically, with the system rejecting any reading lower than the last recorded value.
- Let the resulting work order carry the technician and labour cost, closed only once a failure cause and remedy are selected from the master list.
This keeps each system doing what it's good at, and it avoids a false sense of compliance — a "technician certified" checkbox inside a maintenance tool is not a substitute for an actual ISO 18436 credential, and treating it as one creates risk rather than removing it.
Common Mistakes to Avoid
The most frequent error plants make when standing up a CM programme is assuming that because a system tracks technicians and costs, it must also be tracking their qualifications. It isn't, here — and being upfront about that boundary is safer than discovering it during an audit. A second common mistake is treating the inspection module's certificate-number field (used for statutory asset certificates, like a boiler certificate) as a place to store a person's CM qualification; the two are unrelated and mixing them corrupts both records.
If your programme's real gap is a competency register rather than a work-order and costing system, AssetAI is not the tool for that today — it's worth saying plainly. But if the gap is turning vibration and meter readings into costed, traceable, closure-gated work orders, that's the part AssetAI is built for. See how this fits alongside other condition-based practices under use cases, or compare it with the full feature set before deciding where the boundary should sit for your plant.
ISO 18436 — Condition Monitoring Competence FAQs
How do I set up vibration alarm thresholds in AssetAI so condition monitoring triggers work orders automatically?
You define a monitored parameter (such as vibration in mm/s) and an alarm threshold (for example, 4.5 mm/s); when a reading exceeds that threshold, the system generates a predictive maintenance work order automatically. The threshold acts as the decision boundary — readings feed in from your instruments or manual entry, the platform compares each new reading against your set limit, and crossing that limit triggers the workflow. This keeps condition-based maintenance from relying on manual inspection schedules or human memory, letting you respond to equipment degradation as it happens rather than on a calendar cycle.
What happens when a condition-monitoring work order is assigned to an external technician in AssetAI?
The work order captures the external technician's contact details and assigns labour cost at that technician's hourly rate, so your job record shows both who performed the work and what you paid for it. When the technician completes the job, they must record a failure cause and failure remedy before the system allows closure — this creates a structured failure history rather than unstructured notes, making it easier to spot repeat failures or systemic issues across your condition monitoring programme.
Can I log vibration readings via WhatsApp and have AssetAI convert them to work orders?
Yes — AssetAI accepts readings through multiple sources: manual entry, QR scan, WhatsApp message, or API integration, and each reading carries a value, unit, date, note, photo, and source identifier. Once a reading arrives, the platform compares it to your alarm threshold for that parameter; if it exceeds the limit, a predictive maintenance work order is generated. This flexibility means your technicians do not need to return to a desktop to record data — they can submit readings from the shop floor, and the system processes them into actionable work orders immediately.
How does meter-based condition monitoring work differently from threshold-based in AssetAI?
Meter-based monitoring uses equipment usage or running hours to set due dates, whereas threshold-based monitoring uses a specific parameter value and an alarm limit. In both cases, readings only move forward — the system does not backdate or skip readings — and the preventive maintenance schedule stores the logic. With meter-based, a reading of 500 operating hours might trigger a work order if your interval is 500-hour maintenance; with threshold-based, a vibration spike of 5.2 mm/s against a 4.5 mm/s alarm triggers immediately. AssetAI supports both, so you can mix strategies across different equipment or parameters.
Why do I need to record failure cause and remedy when closing a condition-monitoring work order?
Enforcing failure cause and remedy before work-order closure ensures your condition monitoring programme builds a structured failure history, not free-text notes scattered across job cards. Over time, this record reveals patterns — recurring causes, failed remedies, or equipment that degrades in predictable ways — which informs your monitoring strategy and helps you refine alarm thresholds. AssetAI uses this data to strengthen your predictive maintenance decisions, because a catalogue of "vibration spike → bearing wear → bearing replacement" is far more useful for future planning than vague or missing closure notes.
How does AssetAI help me understand whether condition monitoring is improving overall equipment performance?
AssetAI records every condition-triggered work order with technician identity, labour cost, failure cause, and remedy, creating a complete audit trail of your monitoring activities and their outcomes. You can then correlate this history with OEE explained and CMMS best practices to assess whether condition monitoring is reducing unplanned downtime and extending asset life. The platform does not calculate improvement automatically, but by centralizing all condition-monitoring events and their costs in one place, it gives you the data foundation to measure the return on your monitoring investment honestly.
What is the main focus of the ISO 18436 standard for condition monitoring competence in the context of AssetAI?
The ISO 18436 standard focuses on the competence of condition monitoring technicians, which can be demonstrated by following best practices for condition monitoring in AssetAI.
See AssetAI on your own assets
A 30-minute demo on your plant, not our slides.