ISO 13374 — Condition Monitoring Data Processing
How AssetAI supports practices aligned with ISO 13374.
What ISO 13374 covers
ISO 13374 describes a reference architecture for condition-monitoring systems — data acquisition, manipulation, state detection, health assessment, prognostics and advisory generation — as six named blocks. AssetAI does not implement that pipeline; instead it gives plants a lightweight, auditable way to log readings against a threshold and convert a breach into a work order, which is enough for most Indian manufacturing sites that don't run a dedicated CMS.
What AssetAI actually gives you
Rather than a formal six-block architecture, AssetAI's condition-monitoring layer is built from a small number of concrete, practical mechanisms:
- A monitored parameter and alarm threshold set directly on a predictive schedule (for example vibration mm/s > 4.5), which drives one of six schedule types alongside preventive, usage/meter, calibration, statutory inspection and lubrication — see the full list under features.
- Forward-only meter readings — value, unit, date, note, photo, source — captured per asset, with any reading lower than the last rejected at entry. This validation step is the closest thing AssetAI has to the "data manipulation" stage in the ISO sense.
- Auto-baselining of usage targets from the newest reading on first run, then a rebaseline of current reading + interval every time a usage-based PM fires, so targets stay realistic without manual recalculation.
- A "why am I logging this" panel per asset, showing active meter schedules, current reading and due status — a basic, human-readable state-detection view rather than an automated one.
- A daily 06:00 job that checks due schedules across all tenants and raises the PdM/CM work order, plus a "Generate due" button to force the same check on demand.
None of this involves FFT, waveform capture or vibration signature analysis — the "monitored parameter" is a number entered against a threshold, not a sensor feed, and there's no MIMOSA/OSA-CBM export or import. If your plant needs sensor-level acquisition or remaining-useful-life modelling, that belongs to a dedicated condition-monitoring system, with AssetAI at most consuming its output as a manual or API-fed reading.
Where readings come from, and where they go
Breadth of capture matters more here than depth of signal processing. Readings can arrive through:
- The Meter Readings screen (manual entry)
- A public QR scan page with OCR-assisted value fill
- A WhatsApp command
- A direct API call
Every reading can carry a photo of the meter face, giving an auditable record of what was read and when — useful during an internal audit or a customer quality visit, without needing a data-science team to interpret it.
Once readings and work orders exist, they don't sit idle: the Downtime Cost, OEE & Analytics module reuses the same work-order and production-log data to compute availability × performance × quality per asset (see OEE explained) and to rank downtime cost per asset as a Pareto. It's a trend and reporting layer built on top of condition-adjacent data, not a health-assessment engine — the closest thing to a health verdict in AssetAI is RRR, which weighs cost, failure and downtime history to recommend repair, review or replace, distinct from any ISO 13374 health index.
If you're evaluating this against the full ISO & standards landscape — including how AssetAI's approach compares with the formal architecture described on the ISO website — it's worth reading alongside What is a CMMS to understand where lightweight logging ends and dedicated condition monitoring begins. For plants layering this on top of a TPM programme, see how it fits total productive maintenance practice before you commit to a rollout.
What ISO 20816 helps.
Most Indian plants don't need — or budget for — a certified condition-monitoring system; they need a way to know when a threshold has been crossed and to see that turn into a work order without anyone chasing a spreadsheet. That's the gap AssetAI is built to close, and it's worth being explicit about how the pieces fit together operationally.
Where this fits without a dedicated CMS
If your plant already runs vibration analysis, oil analysis or a proper condition-monitoring system, AssetAI isn't trying to replace it — it can sit downstream, taking a reading fed in manually or via API and turning it into a scheduled check and a work order. For plants without that layer, AssetAI's meter readings and threshold-driven schedules are often the first structured condition data they've captured at all. That's a reasonable starting point for teams moving from reactive to planned maintenance, a shift covered in more depth under what is a CMMS and in use cases across different plant types.
Common mistakes plants make with threshold-based monitoring
Because the "monitored parameter" is a manually entered number against a threshold — not a sensor feed — the discipline around who reads what, and when, matters more than the tooling itself.
- Setting thresholds once and forgetting them. A vibration or temperature alarm value set at commissioning rarely stays right as an asset ages; review thresholds on the same cadence as the schedule itself, not as a one-off.
- Treating every reading channel the same. A value scanned off a meter face via the QR/OCR page is faster to capture than a WhatsApp text reading, but both should carry a photo where the asset criticality justifies it — the photo is your audit trail, not a formality.
- Assuming a threshold breach means imminent failure. It doesn't forecast time-to-failure; it tells you a condition basis has been met and a PdM work order is due. Treat it as a trigger for inspection and planning, not a prognosis.
- Ignoring the "why am I logging this" view. Skipping the per-asset panel that lists active schedules, current reading and due status is the most common reason meter programs decay — operators stop trusting readings they don't understand the purpose of.
- Expecting formal conformance. If your plant, customer contract, or auditor requires demonstrable conformance to the ISO 13374 architecture — data acquisition through advisory generation as six discrete blocks — AssetAI's schedules-and-readings model won't satisfy that on its own; plan for a dedicated CM system instead.
Getting the most from it, practically
The mechanism that makes this work in Indian plant conditions — multiple shifts, mixed literacy on shop floors, patchy connectivity in some areas — is breadth of capture rather than depth of analysis. A reading can come in from the Meter Readings screen, a public QR scan page, a WhatsApp command, or an API call, so the same discipline holds whether the person logging it is a technician with a tablet or an operator with only a phone. Once readings are flowing, the same data feeds downtime, MTTR, MTBF and OEE reporting alongside your production logs, so the condition layer isn't isolated from the rest of your maintenance analytics — see industries for sector-specific context, or book a demo to see the threshold-to-work-order flow on your own asset list.
ISO 13374 — Condition Monitoring Data Processing FAQs
How do I set up vibration monitoring to automatically trigger a PdM work order when it exceeds safe limits?
You define a monitored parameter (vibration in mm/s) and set an alarm threshold (e.g., > 4.5) on a predictive schedule. When a reading hits that threshold, a work order generates automatically. The system captures each reading with a timestamp and optional photo of the meter, creating an auditable record. This works within AssetAI's scheduling framework, which lets you decide how often readings are taken and which assets are monitored.
What happens if my technician logs a meter reading that's lower than the previous one?
The system rejects any reading lower than the last recorded value, ensuring your trend data only moves forward. This prevents accidental data entry errors or misreadings from corrupting your condition baseline. The rejection happens silently at submission—you'll see the previous valid reading remain active until a higher reading is recorded.
Can I capture meter readings via photo instead of typing numbers manually?
Yes. You can submit a photo of the meter face alongside every reading. The photo serves as evidence of what was actually observed and when, building an auditable trail. You can also log readings manually, via barcode scan, WhatsApp message, or API integration depending on your AssetAI features setup.
How does the system know when to recalculate my usage-based PM schedule?
On first setup, the system auto-baselines your usage target from the newest reading. Each time a usage-based PM work order fires, the system rebases the next target by taking your current reading and adding the interval you specified—so targets always stay relative to actual asset consumption, not calendar drift.
Where can I see downtime and MTBF trends for a single asset?
AssetAI feeds downtime, MTTR, MTBF and OEE analytics from your work-order and production-log data into a reporting layer built on the same readings you log. You can track these metrics over time per asset to spot patterns in failure frequency and repair duration. This connects condition monitoring data directly to your overall equipment effectiveness metrics.
Why does the system ask me "why am I logging this" every time I record a meter reading?
The system surfaces a panel showing all active meter schedules for that asset, the current reading, and whether each schedule is due. This state-detection view tells the operator exactly which readings matter and why, reducing confusion about what to measure and when—essentially providing context for every data point before it's logged.
What is the primary focus of the ISO 13374 standard in condition monitoring data processing?
The ISO 13374 standard focuses on processing condition monitoring data, which can be explored in more detail on our condition monitoring page.
See AssetAI on your own assets
A 30-minute demo on your plant, not our slides.