ISO 17359 and ISO 13374: condition monitoring frameworks explained

ISO 17359 and ISO 13374 are the two condition monitoring standards that most other documents in the field refer back to, yet they are often cited without being read. One is a procedure for building a monitoring programme. The other is a reference architecture for the software that processes monitoring data. Neither tells you which accelerometer to buy or which threshold to set, and that is precisely why they remain useful as technology changes.

This article explains what each standard covers, how they fit together, and how we map them onto edge AI systems. Edition details were checked on iso.org in October 2026.

What is ISO 17359?

ISO 17359 is the international standard Condition monitoring and diagnostics of machines: General guidelines. The current version is ISO 17359:2018, the third edition, published in January 2018 and prepared by ISO/TC 108/SC 5. It was last reviewed and confirmed in 2023 and remains current. According to iso.org, it sets out general procedures for setting up a condition monitoring programme and "is applicable to all machines".

The introduction, visible in the ANSI preview, positions it as the parent document of a group of standards. It covers monitoring with parameters such as vibration, temperature and tribology, and directs monitoring towards detecting "symptoms of root cause failure modes". Individual techniques are only introduced briefly and are covered in detail by other standards.

The ISO 17359 procedure, step by step

The main clauses of ISO 17359 form a sequence. Reading the table of contents as a procedure, with our practical interpretation:

1. Cost-benefit analysis (clause 5). Establish whether monitoring a machine is worth it. A cheap, redundant pump may be better run to failure than monitored.
2. Equipment audit (clause 6). Identify the equipment and its function. Monitoring starts with knowing what each machine is for.
3. Reliability and criticality audit (clause 7). Reliability block diagrams, equipment criticality, failure modes, effects and criticality analysis (FMECA), and alternative maintenance tasks. This is where you decide which failure modes deserve monitoring.
4. Monitoring method (clause 8). Choose the measurement technique, required accuracy, feasibility, operating conditions during monitoring, monitoring interval, data acquisition rate, measurement locations, initial alert and alarm criteria, and baseline data.
5. Data acquisition and analysis (clause 9). Measurement and trending, quality of measurements, comparison with alert and alarm criteria, diagnosis and prognosis, and how to improve confidence in them.
6. Determine maintenance action (clause 10). Turn a diagnosis into an action.
7. Review (clause 11). Check whether the programme achieves what it was set up for, and adjust.
8. Training (clause 12). People need to understand the methods they rely on.

Four informative annexes support the procedure: examples of condition monitoring parameters, matching faults to measured parameters or techniques, typical information to record for machine types, and an overview of condition monitoring standards.

Two points are easy to miss. First, sensor and model choices come in clause 8, after the criticality audit, not before. Second, clause 9.2 on the quality of measurements makes sensor health part of the programme, a topic we covered in self-monitoring sensors.

What is ISO 13374?

ISO 13374 is the series Condition monitoring and diagnostics of machines: Data processing, communication and presentation. Its purpose, as the introduction to Part 1 puts it, is "to provide the basic requirements for open software specifications", so that monitoring data can be processed, communicated and displayed by different software packages without platform-specific or hardware-specific protocols. Part 1 includes an informative annex on the specifications of MIMOSA, the Machinery Information Management Open Systems Alliance.

The series has four parts. The status below is as listed on iso.org.

Part 1 "establishes general guidelines for software specifications related to data processing, communication, and presentation". Part 2 sets requirements for a reference information model and a reference processing model. Part 3 defines communication requirements for that open architecture, with an informative annex based on IEC 62264-5. Part 4 covers how diagnostic and prognostic data, health information, advisories and recommendations are presented on displays and in reports.

The six processing blocks of ISO 13374

Part 2 is the most cited part, because of its processing model. Its table of contents lists six types of data-processing block, followed by clauses on external systems, archiving and presentation. The block names below follow that table of contents; the short descriptions are ours, and the examples are from vibration monitoring. Mouzoune (2012) gives similar short descriptions in an e-maintenance paper; note that he counts information presentation and external systems as two further blocks, giving eight.

The blocks are functional, not physical. One device can host several blocks, and one block can be spread across devices. What matters is that the interfaces between blocks are defined, so that a state detector from one supplier can consume features from another.

How ISO 17359 and ISO 13374 fit together

The two standards answer different questions.

ISO 17359 sits above specific techniques. Vibration-specific evaluation criteria come from other documents, for example ISO 20816-3 for industrial machines above 15 kW, whose zones we explained in ISO 20816 vibration severity zones.

Applying the frameworks to edge AI systems

The ISO 13374 blocks map naturally onto modern edge systems, and the mapping is a useful design check.

• Data acquisition and data manipulation run on the sensor node or hub, close to the sensor, because that is where the data volume is. Feature extraction belongs here; see feature engineering for industrial signals.
• State detection and health assessment are where machine-learning models sit. Anomaly detection is a state detection block; fault classification and severity grading are health assessment. The ladder is described in anomaly detection, classification and severity grading.
• Prognostic assessment needs history and is often better placed where data from many periods is available.
• Advisory generation connects to maintenance planning and is usually a human decision supported by software.

The standard's emphasis on quality metadata in data acquisition is a good argument against systems that discard sensor health early. And its insistence on open interfaces is a good argument against systems that hide intermediate results. If you cannot export features and states, you cannot validate or replace a block.

A checklist for using the two standards

• Run the ISO 17359 criticality audit before choosing sensors or models.
• Document, for each monitored failure mode, the technique, location, interval and acquisition rate (clause 8).
• Record baseline data after installation and before setting alarm criteria.
• Map your software to the six ISO 13374-2 blocks and identify where each runs.
• Make sure measurement quality travels with the data from acquisition onwards.
• Define how results are exchanged with other systems and presented to operators.
• Schedule a review of the programme, with criteria agreed in advance.

How NeuroControls approaches this

Our systems are structured along the same lines. Nodes acquire and condition signals and compute signal statistics at the edge; the Edge AI Hub time-stamps every stream and records it on site with a versioned manifest; the operator dashboard on the hub presents status, alerts and events over the local network. Each sensor reports its own signal health and dropouts, so measurement quality is part of every record. The overall structure is on our architecture page.

Custom models trained by our engineers cover the state detection and health assessment blocks: anomaly detection, fault and multi-fault classification and severity grading. Exports in NWB, JSONL and CSV keep intermediate results open, and integration with Grafana, OpenSearch, Kafka or MES is available on request. Monitoring applications are described on our condition monitoring solutions page.