ISO 17359 — Condition Monitoring

What ISO 17359 covers

ISO 17359 sets out general guidelines for condition-monitoring and diagnostics of machines — it tells you what a good monitoring programme looks like, but it doesn't prescribe software or hardware, and it isn't a certifiable management-system standard the way ISO 9001 is. AssetAI gives Indian plants a practical way to run the data-capture and work-order side of that guideline without pretending to be a vibration-analysis system.

What "condition monitoring" means in AssetAI today

Before rolling this out, it helps to be clear on scope. AssetAI's predictive maintenance type lets you define a monitored parameter and an alarm threshold on a schedule — for example, bearing vibration in mm/s with a threshold of 4.5 — and readings are logged against it from the Meter Readings screen, a QR-scan page with photo OCR, a WhatsApp message, or the API. What it does not do is pull data automatically from sensors or IoT devices: every reading is a point-in-time entry, whether typed in, scanned, or sent by field staff. There's no spectral or FFT analysis behind the scenes — the system checks a logged number against a static threshold, it doesn't diagnose the failure mode from a waveform. If your plant is expecting turnkey sensor integration on day one, that layer isn't part of the product yet; see /features for what is built today.

Rolling it out on the shop floor

Most Indian plants already run some form of manual condition checks — vibration pen readings on rotating equipment, thermal gun spot-checks on panels, running-hour logs on compressors or DG sets. The practical migration path looks like this:

• Start with the parameters you already measure by hand; don't wait for a parameter library, since the monitored-parameter and alarm-threshold fields are free text, so whatever your technicians call it today is what goes on the schedule.
• Standardise the units your team enters (mm/s vs in/s, °C vs °F) before go-live — the field doesn't enforce this for you.
• Use the source tag on every reading (manual, scan, WhatsApp, API) to keep an audit trail of how each data point was captured, which matters when a contract technician's reading is disputed later.
• Let usage-based schedules rebaseline themselves: once a reading hits the target, the next target resets from that reading plus the interval, so run-hour or cycle-based servicing keeps pace with actual asset use rather than a fixed calendar date.

Common mistakes to avoid

• Treating the alarm threshold as a live, auto-triggering alert: today it's descriptive reference data carried on the work order, not a documented real-time evaluator — plan your escalation process around technicians reviewing readings, not a system push.
• Backdating readings lower than the last logged value — the system rejects these by design, so trend data only moves forward; if a reading looks wrong, correct the process, not the number.
• Assuming closing the alert closes the loop: AssetAI enforces failure mode, cause, and remedy capture at work-order closure, so the diagnostic outcome — not just the alarm — feeds into RRR (repair/review/replace) scoring alongside breakdown history, downtime cost, and cumulative repair cost versus purchase price.

This is the same discipline that underpins broader reliability programmes like TPM — condition data is only useful if it's captured consistently and closed out properly. For a wider view of how this sits alongside preventive scheduling and spares control, see /standards, or book a demo and we'll walk through your current condition-check process on your own asset list.

What ISO 17359 helps

The mechanics behind the alarm matter as much as the alarm itself — a threshold is only useful if the trend data feeding it is trustworthy and if what happens after a breach is actually recorded. AssetAI's features around meter readings and work-order closure are built around that discipline.

Keeping the trend line honest

A vibration or temperature reading that's lower than the last one is usually a typo, a mis-scan, or someone reading the wrong gauge — not a genuine improvement in machine health. AssetAI rejects any new reading that falls below the previous value for that asset, so the trend line only ever moves forward and a bad data point can't quietly reset the baseline.

• Auto-rebaselining: once a usage or condition schedule fires, the next target resets from the current reading plus the configured interval — you don't have to manually recalculate the next due point after every reading.
• First-run baselining: when a schedule is first created, AssetAI seeds its target from the newest reading instead of raising a spurious work order because there was no prior history to compare against.
• Source tagging: every reading carries a tag for how it was captured — manual entry, QR scan with photo OCR, WhatsApp, or API — giving you an audit trail of who logged what, and from where, without having to ask the technician.

This matters more in Indian plant settings where the same reading might come from a contract technician on a walk-round, a WhatsApp update from a remote site, or a scanned gauge photo — the data discipline has to hold regardless of channel.

From alarm to closed loop

Logging a threshold breach is only half the job — what the technician actually found and fixed is the part that improves future decisions. AssetAI enforces failure mode, cause, and remedy capture at work-order closure, so a PdM work order raised off a condition schedule can't be closed with just "done" — the diagnostic outcome gets recorded against the asset.

That history then feeds RRR (Repair/Review/Replace) scoring per asset, combining breakdown and corrective failure counts, downtime cost, cumulative work-order spend against purchase cost, and asset age. It's a rules-based, readable calculation — not a predictive model — but it turns condition-monitoring history into a defensible answer to "should we keep repairing this asset or plan its replacement," which is usually the real question behind a condition-monitoring programme.

Fitting it into a broader reliability programme

Condition monitoring rarely stands alone — most plants run it alongside preventive PM calendars, spares planning, and OEE tracking. If you're building out that wider picture, our OEE explainer and the use cases page cover how condition data ties into uptime and loss tracking, and how the approach compares with broader TPM programmes. For a plant-by-plant view of what's realistic to roll out first, book a demo or check pricing to see what's included at each tier.