ISO 17359:2018 gives guidelines for the general procedures to be considered when setting up a condition monitoring programme for machines [S1].
The third edition is titled “Condition monitoring and diagnostics of machines — General guidelines” and supersedes ISO 17359:2011 [S4][S5].
What ISO 17359 Covers and Which Edition Applies
ISO 17359:2018 is the applicable third edition, published in January 2018, and provides guidelines rather than prescriptive alarm limits or equipment-selection rules [S1][S5]. ISO 17359:2011 was Edition 2 and was withdrawn with a new version, ISO 17359:2018, available [S4].
ISO 17359:2018 is the third edition, published in 2018-01 [S5]. Its scope covers the general procedures for establishing a condition-monitoring program, while associated standards supply supporting requirements for the selected monitoring discipline [S3][S4].
That distinction matters during procurement. ISO 17359 is not a standalone vibration specification, thermography acceptance test, oil-analysis protocol, or route to automatic diagnosis. A compliant program must select supporting standards for the machine, defect, measurement, and decision process rather than treating ISO 17359 as a complete work instruction [S3][S5].
Build the Program Around Machine and Business Context
A condition-monitoring program must define its purpose before choosing sensors, because the published procedure addresses cost-benefit analysis and an equipment audit as distinct stages [S5]. The equipment audit identifies the equipment, its function, and its operating context before criticality and diagnostic requirements are finalized [S5].
ISO 17359:2011 was withdrawn with a new version, ISO 17359:2018, available [S4]. The 2018 edition therefore remains the edition identified by ISO for the general-guideline scope [S1][S4]. Older contracts that name ISO 17359:2003, 2011, or 2018 should be reviewed against the actual edition, since the scope remains similar but edition status and content change [S2][S4].
The program should connect each monitoring objective to an operational decision. A rotating-machine program may require trend-based defect detection, while a production asset may need evidence that the monitored condition can change a maintenance or operating decision. Steel-plant implementations identified asset criticality, monitoring techniques, alarm thresholds, and CMMS records as core program elements [S6].
Audit Equipment, Reliability, and Criticality
The published structure requires an equipment audit followed by a reliability and criticality audit, with identification of equipment and equipment function forming separate subsections [S5]. This sequence prevents a monitoring system from being specified around available sensors rather than actual failure exposure and machine function.
For each asset, the program file should identify the machine, its function, operating state, relevant defects, and monitoring objective. For steel plants, the operating context includes asset criticality, selected monitoring techniques, defined alarm thresholds, and records maintained in the CMMS [S6].
Reliability analysis should then determine which failure modes matter enough to justify monitoring, how the selected technique exposes them, and what action follows detection. A program without documented consequence, alarm response, and escalation rules cannot produce a defensible link between a measured change and maintenance action [S5][S6].
Select Monitoring Techniques Against Failure Modes
ISO 17359:2018 provides a general procedure for establishing condition monitoring and diagnostics for machines and identifies associated standards used in that process [S1][S3]. Technique selection should therefore be driven by the failure mode, machine geometry, operating environment, access, and required diagnostic result.
Vibration is suitable where mechanical disturbance, misalignment, imbalance, looseness, or bearing-related signals are relevant, but ISO 17359 does not assign universal acceptance or alarm limits to a machine. The detailed choice of sensors, mounting, frequency range, processing, and thresholds must be justified through the asset audit and the applicable supporting standards [S3][S5].
Other techniques address different objectives. Temperature measurement can identify thermal conditions, oil analysis can reveal lubricant or contamination trends, and motor-current analysis can provide drive-based fault information without adding a vibration sensor at every location [S5]. Drive-based condition monitoring provides a focused comparison of sensorless motor-current approaches.
The practical comparison is therefore by evidence, coverage, and response value. Vibration offers broad mechanical coverage where a suitable measurement point exists; thermography supports targeted thermal inspection; oil analysis supports lubricant and wear-chemistry trends; and current-based monitoring targets electrically observable drive faults. The audit, not the novelty of the technology, determines which combination is defensible [S5].
Convert Measurements Into Decisions and Records
A usable program links measured condition, diagnosis, decision, and work record. Steel-plant program descriptions identify alarm thresholds and CMMS records, while an AI-oriented implementation addresses program design, data collection, and diagnostic use under the ISO 17359 guideline structure [S6][S7].
Each alarm should carry a defined measurement basis, operating condition, threshold or trend rule, response action, and escalation path. That is more defensible than an ungoverned dashboard that flags every change. A monitoring terminal can act as the operator-facing layer for this workflow, as described in the reference entry for a monitoring terminal.
Historical values, diagnostic findings, work requests, and outcome evidence should be retained in the maintenance system. That chain supports verification of whether a monitoring program reduced failures, avoided unnecessary work, or produced warnings without actionable maintenance outcomes. AI-assisted diagnostics can support the workflow, but they do not replace program governance, measurement validity, or defined human decisions [S7].
Control Failure Modes and Program Boundaries
The principal implementation failure is sensor selection before failure-mode analysis. Without the equipment and function audit, a program can accumulate data from accessible points while leaving critical failure mechanisms unobserved [S5].
A second failure is treating diagnostics as automatic fault confirmation. Trend excursions can result from changing load, operating speed, ambient conditions, sensor placement, or instrumentation drift, so the diagnostic method must distinguish machine behavior from measurement variation. Asset context and standardized thresholds are therefore essential parts of the alarm record, not optional metadata [S5][S6].
ISO 17359 is also not a safety-function standard, a functional-safety specification, or a universal predictive-maintenance algorithm. It does not replace IEC 61508, ISO 13849, IEC 62061, or machinery-specific protection requirements. Its role is to organize condition monitoring and diagnostics as a managed program [S1][S5].
Review Benefits, Changes, and Program Effectiveness
ISO 17359:2018 includes cost-benefit analysis and benchmarks for measuring the effectiveness of a condition-monitoring program [S5]. The business case should identify the avoided failure consequence, monitoring cost, diagnostic burden, and the point at which continued monitoring becomes inefficient.
Program review should also consider equipment changes, new failure experience, sensor performance, alarm quality, false positives, missed detections, work-order closure, and verified maintenance outcomes. Any adopted AI diagnostic capability should be evaluated as part of the same controlled process rather than introduced as a separate predictive-maintenance project [S7].
For implementation, start with the current ISO 17359:2018 edition and identify every referenced supporting standard before issuing an alarm procedure. Then complete one asset pilot with documented audit fields, measurement definitions, alarm responses, CMMS records, and benefit benchmarks. Expansion should depend on verified results from that pilot, not on sensor count or dashboard complexity [S1][S5][S6].