ISO 13374 organizes condition monitoring and diagnostics into six functional blocks, covering acquisition, manipulation, detection, assessment, prognosis and advisory generation [S4].
ISO 13374-2:2007 defines the reference information and processing models, while ISO 13374-3:2012 addresses communication for an open CM&D architecture [S1][S3].
Six functional blocks define the data path
The Data Acquisition block converts physical machine conditions into digital measurements. Its inputs include signals from sensors such as accelerometers, thermocouples, pressure transducers, current clamps and acoustic-emission sensors; the acquired data are sampled, digitized and timestamped at the edge [S4].
The Data Manipulation block transforms digitized signals into engineering features. Documented operations include low-pass and band-pass filtering, FFT and wavelet transforms, statistical feature extraction, and normalization against baseline conditions [S4].
The State Detection block compares processed features with thresholds or expected behavior envelopes, producing machine states such as Normal, Warning and Alarm [S4]. For rotating machinery, the accelerometer is a common acquisition component for vibration measurements, while the downstream architecture determines how those measurements become diagnostics rather than isolated readings.
The final three blocks extend the pipeline from condition classification to actionable maintenance guidance. Health Assessment associates symptoms with failure modes and diagnoses the asset, Prognostics Assessment estimates future condition or remaining useful life, and Advisory Generation converts the results into maintenance recommendations [S4].
Reference models separate information from processing
ISO 13374-2:2007 specifies requirements for both a reference information model and a reference processing model within an open CM&D architecture [S1]. This division gives engineers two concrete design questions: which data objects and relationships must be represented, and which processing blocks must transform those objects into usable condition information.
ISO 13374-3:2012 states that the series is intended to provide basic requirements for open CM&D software architecture so that condition monitoring and diagnostics information can be exchanged between compatible systems [S2][S3].
A data logger can supply acquired samples and timestamps, but ISO 13374 does not reduce the implementation to a logging box. A compliant architecture must preserve the functional context from raw acquisition through manipulation, detection, health assessment, prognostics and advisory generation [S4].
Interface design determines interoperability
ISO 13374-3:2012, Part 3: Communication, supports the open CM&D software architecture intent of the ISO 13374 series [S3]. The architecture therefore depends on defined interfaces and interactions, not on a proprietary sensor protocol or one vendor's data model.
This division supports composition across sensors, acquisition equipment, processing servers, diagnostic applications and maintenance systems, provided that the exchanged objects and interactions conform to the applicable interface definitions.
A practical implementation should map each boundary before selecting hardware. The monitoring terminal may collect or display condition data, while server-side processing performs feature extraction and state classification. The architectural work is to identify which block owns each function and which interface carries the resulting information.
Interoperability also means more than accepting a CSV file.
Compare architectures by implementation criteria
A monolithic platform can link acquisition, processing and alarms inside one application, but its functions may remain difficult to exchange with other CM&D systems. An ISO 13374-aligned architecture separates six blocks with explicit outputs, making the data path visible to integrators [S4].
The comparison below organizes the principal implementation choices by block granularity, diagnostic reuse, communication control and AI placement. These criteria follow directly from the six-block reference model and the communication requirements defined in ISO 13374-3:2012 [S3][S4].
For pilot work, the ISO 13374-aligned option offers the clearest audit path because each stage has a named purpose. For large fleets, the same structure can reduce custom integration, but it requires disciplined data contracts and interface testing rather than vendor-feature counting alone [S4].
Not every monitoring project needs full architecture
ISO 13374 is suited to systems that acquire machine data, process condition information, diagnose condition and exchange results with other systems. It is less valuable for a single manual inspection, a fixed threshold panel without downstream data processing, or a stand-alone logger whose measurements are never consumed by an analytical workflow [S1][S4].
The standard also does not make every block mandatory in every deployed product. Its value comes from defining a reference structure and open communication requirements, not from requiring every organization to implement every capability at the same maturity level [S1][S3].
State detection and health assessment should not be confused. State Detection compares features with thresholds or expected envelopes and outputs Normal, Warning or Alarm states; Health Assessment evaluates the asset more broadly, combines evidence and identifies the likely condition or failure mode [S4].
Prognosis carries a different uncertainty profile because it estimates future condition, including remaining useful life in suitable degradation applications [S4]. A system with good alarm detection may still provide weak prognosis if it lacks representative history, suitable models or health-state history. The architecture exposes that gap, but it does not remove the need for validated models and representative data.
Data architecture needs support beyond the model
ISO 13374-3:2012 was issued in 2012 and addresses communication, not the complete operational burden of an analytics deployment [S3]. Singapore's SS ISO 13374-3:2019 identifies the document as an identical adoption of ISO 13374-3:2012 and classifies it under ICS 17.160 and 35.240.99 [S5].
The reference model requires reference data libraries, communications initiation and message content to be addressed [S3]. A production design should also test timestamp consistency, asset identity, feature naming, state semantics, missing data and version compatibility across each interface. These are implementation checks derived from the required communication functions, not additional numerical claims assigned to the standard.
For storage planning, teams should distinguish feature streams from raw waveform retention. The manipulation block can convert raw signals into RMS, peak, crest factor and spectral features [S4], but the architecture does not make a single retention policy valid for every machine class. The condition monitoring system must therefore document which processed and raw data are retained, where they are stored, and how downstream consumers retrieve them.
AI can be inserted at several points without breaking the functional sequence: feature manipulation, state detection, health assessment, prognosis or advisory generation all consume outputs from preceding blocks [S4]. The governance question is therefore not whether a model uses AI, but which ISO 13374 block consumes the model result, what inputs it receives and what output contract it must produce.
Build the interface contract before procurement
ISO 13374 gives engineering teams a six-block audit model for condition-monitoring architecture: Data Acquisition, Data Manipulation, State Detection, Health Assessment, Prognostics Assessment and Advisory Generation [S4]. Part 2 supplies the reference information and processing models, and Part 3 supplies the communication framework [S1][S3].
The next verifiable step is to map every existing or proposed component to one of the six blocks, name each external interface, and record the exchanged message content and communication initiator [S3]. A second check is to confirm that state flags, diagnostic conclusions, remaining-life estimates and maintenance advice remain distinguishable as they cross those interfaces.
That architecture map becomes a procurement control: it shows whether a proposed sensor, gateway, diagnostic package or detection and analysis apparatus fits an existing block or leaves an undefined interface. It also creates a measurable acceptance test, since each block should have a named input, output and receiving consumer before implementation begins.