Iso 13374

INTERNATIONAL ISO
STANDARD 13374-1
First edition
2003-03-15
Condition monitoring and diagnostics

of machines — Data processing,
communication and presentation —
Part 1:
General guidelines
iTeh STANDARD PREVIEW

Surveillance et diagnostic d'état des machines — Traitement, échange
et présentation des données —
(standards.iteh.ai)
Partie 1: Lignes directrices générales
ISO 13374-1:2003
https://standards.iteh.ai/catalog/standards/sist/25e70465-e47d-457f-a090-
b07c457be7df/iso-13374-1-2003
Reference number
ISO 13374-1:2003(E)
© ISO 2003
ISO 13374-1:2003(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

(standards.iteh.ai)
ISO 13374-1:2003
b07c457be7df/iso-13374-1-2003
© ISO 2003
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2003 — All rights reserved

ISO 13374-1:2003(E)
Contents Page
Foreword ............................................................................................................................................................ iv
Introduction ........................................................................................................................................................ v
1 Scope...................................................................................................................................................... 1
2 Data processing .................................................................................................................................... 1
2.1 Overview ................................................................................................................................................ 1
2.2 Data-processing blocks........................................................................................................................ 1
2.3 Conceptual information schema guidelines ...................................................................................... 4
3 Data communication formats and methods for exchanging information ....................................... 6
3.1 Communication methodologies .......................................................................................................... 6
3.2 Selection guidelines for communication methodologies ................................................................. 7
4 Formats for presenting and displaying data ...................................................................................... 8
4.1 General ................................................................................................................................................... 8
4.2 Determination of work flow procedures ............................................................................................. 8
4.3 General information display architecture........................................................................................... 9
5 Responsible personnel....................................................................................................................... 14
5.1 iTeh STANDARD PREVIEW
Introduction ......................................................................................................................................... 14
5.2 Operators ............................................................................................................................................. 14
5.3 (standards.iteh.ai)
Operations engineer ........................................................................................................................... 14
5.4 Reliability analyst ................................................................................................................................ 14
5.5 Management ........................................................................................................................................
ISO 13374-1:2003 14
Annex A (informative) Machinery Information Management Open Systems Alliance (MIMOSA)
b07c457be7df/iso-13374-1-2003
specifications ...................................................................................................................................... 15
Bibliography ..................................................................................................................................................... 16
© ISO 2003 — All rights reserved iii

ISO 13374-1:2003(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 13374-1 was prepared by Technical Committee ISO/TC 108, Mechanical vibration and shock,
Subcommittee SC 5, Condition monitoring and diagnostics of machines.
ISO 13374 consists of the following parts, under the general title Condition monitoring and diagnostics of
machines — Data processing, communication and presentation:
(standards.iteh.ai)
 Part 1: General guidelines
ISO 13374-1:2003
 Part 2: Data-processing requirements
b07c457be7df/iso-13374-1-2003
 Part 3: Communication requirements
 Part 4: Presentation requirements
iv © ISO 2003 — All rights reserved

ISO 13374-1:2003(E)
Introduction
The various computer software programs written for condition monitoring and diagnostics of machines that are
currently in use cannot easily exchange data or operate in a plug-and-play fashion without an extensive
integration effort. This makes it difficult to integrate systems and provide a unified view of the condition of
machinery to users. The intent of ISO 13374 is to provide the basic requirements for open software
specifications which will allow machine condition monitoring data and information to be processed,
communicated and displayed by various software packages without platform-specific or hardware-specific
protocols.
Extensible Markup Language (XML) is a project of the World Wide Web Consortium (W3C), and the
development of the specification is being supervised by their XML Working Group. XML is a public format
written in the Standard Generalized Markup Language (SGML) (see ISO 8879[1] for details) for defining
descriptions of the structures of different types of electronic documents. The version 1.0 specification was
accepted by the W3C as a Recommendation in 1998. A W3C Recommendation indicates that a specification
is stable, contributes to Web interoperability, and has been reviewed by the W3C membership, who are in
favour of supporting its adoption by academic, industry and research communities. It is designed to improve
the functionality of the Web by providing more flexible and adaptable information identification.

(standards.iteh.ai)
ISO 13374-1:2003
b07c457be7df/iso-13374-1-2003
© ISO 2003 — All rights reserved v

(standards.iteh.ai)
ISO 13374-1:2003
b07c457be7df/iso-13374-1-2003
INTERNATIONAL STANDARD ISO 13374-1:2003(E)
Condition monitoring and diagnostics of machines — Data

processing, communication and presentation —
Part 1:
General guidelines
1 Scope
This part of ISO 13374 establishes general guidelines for software specifications related to data processing,
communication, and presentation of machine condition monitoring and diagnostic information.
NOTE Later parts of ISO 13374 (under preparation) will address specific software specification requirements for data
processing, communication and presentation.
2 Data processing iTeh STANDARD PREVIEW

2.1 Overview (standards.iteh.ai)
Relevant data processing and analysis procedures are required to interpret the data received from condition
ISO 13374-1:2003
monitoring activities.https://standards.iteh.ai/catalog/standards/sist/25e70465-e47d-457f-a090-
A synergistic combination of technologies should establish the cause and severity of
possible faults and provide the justification for operations and maintenance actions in a pro-active manner.
b07c457be7df/iso-13374-1-2003
A data processing and information flow of the type shown in Figure 1 is recommended either on a manual or
automatic basis, in order to implement condition monitoring successfully. The data flow begins at the top,
where monitoring configuration data are specified for the various sensors monitoring the equipment, and
finally results in actions to be taken by maintenance and operations personnel. As the information flow
progresses from data acquisition to advisory generation, data from the earlier processing blocks need to be
transferred to the next processing block and additional information acquired from or sent to external systems.
Similarly, as the data evolve into information, both standard technical displays and simpler graphical
presentation formats are needed. The flow progresses from data acquisition to complex prognostic tasks,
ending in the issuance of advisories and recommended actions (one of which may be a modification of the
monitoring process itself).
2.2 Data-processing blocks
2.2.1 Machine condition assessment processing blocks
Machine condition assessment can be broken into six distinct, layered processing blocks. The first three
blocks are technology-specific, requiring signal processing and data analysis functions targeted to a particular
technology. The following are some of the most commonly used technologies in condition monitoring and
diagnostics of machines:
 shaft displacement monitoring;
 bearing vibration monitoring;
 tribology-based monitoring;
© ISO 2003 — All rights reserved 1

ISO 13374-1:2003(E)
 infrared thermographic monitoring;
 performance monitoring;
 acoustical monitoring;
 motor current monitoring.

(standards.iteh.ai)
ISO 13374-1:2003
b07c457be7df/iso-13374-1-2003
Figure 1 — Data-processing and information-flow blocks
2 © ISO 2003 — All rights reserved

ISO 13374-1:2003(E)
The technology-specific blocks and the functions they should provide are as follows.
a) Data Acquisition (DA) block: converts an output from the transducer to a digital parameter representing
a physical quantity and related information (such as the time, calibration, data quality, data collector
utilized, sensor configuration).
b) Data Manipulation (DM block): performs signal analysis, computes meaningful descriptors, and derives
virtual sensor readings from the raw measurements.
c) State Detection (SD block): facilitates the creation and maintenance of normal baseline “profiles”,
searches for abnormalities whenever new data are acquired, and determines in which abnormality zone,
if any, the data belong (e.g. “alert” or “alarm”).
The final three blocks normally attempt to combine monitoring technologies in order to assess the current
health of the machine, predict future failures, and provide recommended action steps to operations and
maintenance personnel. These three blocks and the functions they should support are as follows.
d) Health Assessment (HA) block: diagnoses any faults and rates the current health of the equipment or
process, considering all state information.
e) Prognostic Assessment (PA) block: determines future health states and failure modes based on the
current health assessment and projected usage loads on the equipment and/or process, as well as
remaining useful life predictions.
f) Advisory Generation (AG) block: provides actionable information regarding maintenance or operational
changes required to optimize the life of the process and/or equipment.
2.2.2 Technical displays (standards.iteh.ai)

To facilitate analysis by qualified personnel, ISOrelevant technical displays showing data such as trends as well
13374-1:2003
as associated abnormality zones are necessary. These displays should provide the analyst with the data
required to identify, confirm or understand an abnormal state.
b07c457be7df/iso-13374-1-2003
2.2.3 Information presentation
It is important that the data be converted to a form that clearly represents the information necessary to make
corrective-action decisions. This may be done in a written format, numerically in order to demonstrate
magnitudes, graphically in order to show trends, or a combination of all three.
The information should include pertinent data describing the equipment or its components, the failure type or
fault, an estimate of the severity, a projection of condition and, finally, recommended action. Cost and risk
factors may also be displayed.
2.2.4 External systems
Retrieval of previous work histories from the maintenance system and previous operational data
(starts/stops/loads) from a process-data historian is important in the assessment of machinery health. After a
health assessment is made, the maintenance action to be taken may range from increasing the frequency of
inspection to repair or replacement of the damaged machinery or component. The effect on operations may
be an adjustment of operating procedures or a request to shutdown the equipment immediately. This need for
rapid communication to the maintenance and operational system requires software interfaces to maintenance
management systems and operational control systems. These interfaces are useful in order to communicate
recommended actions in the form of maintenance work requests and operational change requests.

ISO 13374-1:2003(E)
2.2.5 Data archiving
Data archiving is an important feature during all blocks of a machine condition monitoring program. Previous
data trends can be analysed for statistical relevance. Previous health assessments should be audited for
accuracy, and root cause information added upon its discovery.
2.2.6 Block configuration
Each data-processing block requires configuration information, some of which may be static information and
other data may be dynamically changed by the system during operation. For example, the configuration of the
Data Acquisition block may include identification of measurement monitoring locations, orientation and relative
transducer position, monitoring polling rates, sensor set-up data and calibration parameters.
2.3 Conceptual information schema guidelines
2.3.1 Overview
The conceptual information schema is a single integrated definition of the relative machinery and condition
monitoring information, which is unbiased toward any single application of data and is independent of how the
data are physically stored or accessed. The primary objective of the conceptual schema is to provide a
consistent definition of the meanings and interrelationship of data, which can be used to integrate, share and
manage the integrity of data. This information schema is a blueprint of the location of various data elements.
There are various forms of information schema.
The file description schema format has been used for years in the scientific programming community. It maps
the format for ASCII or binary data files, which can be exported from a computer system or imported into a
computer system. A complete record format description is published which specifies the data fields contained
(standards.iteh.ai)
in the file, their exact location in relation to the other data fields, whether the fields are in ASCII or binary
format, and the exact data format (scientific floating point, integer, character, varying character string) of each
field. ISO 13374-1:2003
The relational information schema format is b07c457be7df/iso-13374-1-2003
the definition language for relational database management
systems. The relational method is analogous to a blue-print drawing which defines the following:
 various “room names” (or tables) where data will be stored;
 the data “contents” (or columns) in the rooms;
 each data column's exact data format (scientific floating point, integer, varying character string, etc.);
 whether or not a data column can be empty or not (not null);
 each data row's unique “key” (primary key) which uniquely identifies it.
A table can be related to another table by including a “reference” (foreign key) to it.
Extensible Markup Language (XML) is a project of the World Wide Web Consortium (W3C) and the
development of the specification is being supervised by their XML Working Group. XML is a public format
written in the Standard Generalized Markup Language (SGML) (see ISO 8879[1] for details) for defining
descriptions of the structures of different types of electronic documents. It is called extensible because it is not
a fixed format like Hypertext Markup Language (HTML), which is a single, predefined markup language.
Instead, XML is actually a “meta-language” (a language for describing other languages) which allows one to
design customized markup languages for limitless different types of documents. XML uses the internationally
standardized 31-bit character repertoire specified in ISO 10646[2], which covers most human (and some non-
human) languages. This is currently congruent with Unicode and is planned to be superset of Unicode. XML is
intended to make it easy and straightforward to use SGML on the Web: easy to define document types, easy
to author and manage SGML-defined documents, and easy to transmit and share them across the Web. It
defines an extremely simple dialect of SGML, which is completely described in the XML Specification. The

ISO 13374-1:2003(E)
goal is to enable generic SGML to be served, received and processed on the Web in the way that is now
possible with HTML. For this reason, XML has been designed for ease of implementation, and for
interoperability with both SGML and HTML.
In 2001, the W3C issued XML Schema as a W3C Recommendation. XML Schemas define shared markup
vocabularies, the structure of XML documents, which use those vocabularies, and provide hooks to associate
semantics with them. By bringing datatypes to XML, XML Schemas increase XML's utility to the developers of
data interchange systems. XML Schemas allow the author to determine which parts of a document may be
validated, or identify parts of a document where a schema may apply. Furthermore, as XML Schemas are
XML documents themselves, they may be managed by XML authoring tools.
A software object information schema is now becoming widely used in the computer industry. Software
"objects" are defined using an object definition language, including their external characteristics and
operations, unique keys, data attributes available, data types, relationships, etc. The Unified Modelling
Language (UML) has emerged as the software industry's dominant modelling language. The Object
Management Group (OMG) adopted UML as its standard modelling language.
NOTE The OMG has submitted the UML specification to ISO as a Publicly Available Specification (PAS).
2.3.2 Information schema requirements
Regardless of which information schema format is chosen, the schema will define a minimum set of data
elements that should be included in the schema for compliance. In addition, a list of optional elements will be
included.

To support data communication between multiple condition monitoring modules supplied by various vendors,
a vendor-independent, open machine condition monitoring information schema architecture is required as an
(standards.iteh.ai)
underlying framework. This framework can be utilized in various communication implementations.
Vendor independence is vital. Many vendors and users have implemented various methods of machine
ISO 13374-1:2003
condition monitoring https://standards.iteh.ai/catalog/standards/sist/25e70465-e47d-457f-a090-
data storage. An open information schema allows for the integration of many sources of
machinery information, supports peer-to-peer databases, allows user-defined lookup entries, and utilizes
b07c457be7df/iso-13374-1-2003
standardized timestamps and engineering units. The schema should support unique site identifiers and site
database or data source identifiers to differentiate data taken at different physical locations. The schema
should also support unique, system-wide identifiers for plant segments containing machinery (service segment
locations) in a parent-child hierarchy. Also the schema should support a unique asset-specific identifier to
allow individual component monitoring and tracking in a parts hierarchy. The basic framework of storing sites,
site databases, process or machine segment information, asset nameplate data, model or part information,
measurement locations, data measurement sources, transducers, ordered lists, and alarms should be
specified in the schema. At a data level, the schema should support formats for communicating historical
single-valued numeric data, Fast-Fourier Transform (FFT) spectra data, constant percentage band (CPB)
spectra, time waveforms, sample-based test data, thermographic images, and binary large objects. The
schema should support a date/time notation that references back to a specific instance in time, using the
Gregorian (Common Era or CE) calendar, with a lexical representation based upon ISO 8601[3].
In order to communicate common machinery equipment types, measurement location types, orientations, etc.,
a standard set of reference entries should contain a set of common codes and associated text in various
languages as required. The architecture should allow for each database to create and maintain additional
reference table entries to allow maximum flexibility. An example of a publicly available XML Schema that
supports this architecture is given in Annex A.

COMMITTEE DRAFT ISO/CD 13374-2
Date Reference number
COMMITTEE 2004-06-11 ISO/TC 108 /SC 5 N 248
DRAFT Supersedes document
N 230
WARNING: This document is not an International Standard. It is distributed for review and comment. It is subject to change
without notice and may not be referred to as an International Standard.
ISO/TC 108/SC 5 Circulated to P- and O-members, and to technical committees

and organizations in liaison for:
Title
discussion at
Condition monitoring and [venue/date of meeting]
diagnostics of machines
Secretariat comments by
[date]
ANSI
approval for registration as a DIS in accordance with
2.5.6 of part 1 of the ISO/IEC Directives, by
2004-09-11
[date]
(P-members vote only: ballot form attached)

P-members of the technical committee or subcommittee
concerned have an obligation to vote.
Title (English)
Condition monitoring and diagnostics of machines – Data processing, communication,
and presentation – Part 2: Data processing
Title (French)
Reference language version: English French Russian
Introductory note
At its 2003 meeting in Paris, SC 5 adopted resolution 6/2003 which directed the
circulation of this draft as a CD for voting. Member bodies are urged to vote on
time to assure that the comments can be circulated prior to the October 2004 meeting.
Copyright notice
This ISO document is a committee draft and is copyright protected by ISO. While the reproduction of committee drafts in any
form for use by participants in the ISO standards development process is permitted without prior permission from ISO, neither
this document nor any extract from it may be reproduced, stored or transmitted in any form for any other purpose without prior
written permission from ISO.
Requests for permission to reproduce this document for the purpose of selling it should be addressed to the secretariat indicated
above or to ISO’s member body in the country of the requester.
Reproduction for sales purposes may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.
© ISO 2004 – All rights reserved
FORM 7 (ISO)
Version/V97.1.2
© ISO 2004 — All rights reserved
ISO TC 108/SC 5 N 248

Date: 2004-06-6
ISO/CD 13374-2
ISO TC 108/SC 5/WG 6
Secretariat: ANSI
Condition monitoring and diagnostics of machines — Data processing,

communication, and presentation — Part 2: Data processing
Élément introductif — Élément central — Partie 2: Titre de la partie
Warning
This document is not an ISO International Standard. It is distributed for review and comment. It is subject to
change without notice and may not be referred to as an International Standard.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of
which they are aware and to provide supporting documentation.
Document type: International Standard

Document subtype:
Document stage: (30) Committee
Document language: E
G:\WPFILES\TC108\SC5\13374-2\CD 13374-2\ISO_CD_13374-2_(E)[kb].doc STD Version 2.1

ISO/CD 13374-2
Copyright notice
This ISO document is a working draft or committee draft and is copyright-protected by ISO. While the
reproduction of working drafts or committee drafts in any form for use by participants in the ISO standards
development process is permitted without prior permission from ISO, neither this document nor any extract
from it may be reproduced, stored or transmitted in any form for any other purpose without prior written
permission from ISO.
Requests for permission to reproduce this document for the purpose of selling it should be addressed as
shown below or to ISO's member body in the country of the requester:
R. Maginniss
ANSI
25 W. 43rd St.
New York, NY 10036
Reproduction for sales purposes may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.
ii © ISO 2004 — All rights reserved

ISO/CD 13374-2
Contents Page
Foreword .........................................................................................................................................................iv
1 Scope ...................................................................................................................................................1
2 Normative references .........................................................................................................................1
3 CM&D information architecture requirements..................................................................................1
3.1 Overview ..............................................................................................................................................1
3.2 Semantic definition requirements .....................................................................................................2
3.3 Conceptual information model requirements ...................................................................................2
3.4 Implementation data model requirements ........................................................................................2
3.5 Reference data library requirements .................................................................................................3
3.6 Data document definition requirements............................................................................................4
3.7 Compliant specifications....................................................................................................................4
4 CM&D processing architecture requirements ..................................................................................4
4.1 Overview ..............................................................................................................................................4
4.2 Data Acquisition (DA) blocks .............................................................................................................6
4.3 Data Manipulation (DM) blocks ..........................................................................................................7
4.4 State Detection (SD) blocks ...............................................................................................................8
4.5 Health Assessment (HA) blocks ........................................................................................................9
4.6 Prognostic Assessment (PA) blocks...............................................................................................10
4.7 Advisory Generation (AG) blocks....................................................................................................11
4.8 Block configuration ..........................................................................................................................12
4.9 External systems ..............................................................................................................................12
4.10 Data archiving ...................................................................................................................................13
4.11 Technical displays ............................................................................................................................13
4.12 Information presentation..................................................................................................................13
4.13 Compliant specifications..................................................................................................................13
Annex A (informative) Compliant specifications .........................................................................................16
Bibliography...................................................................................................................................................23
© ISO 2004 — All rights reserved iii

ISO/CD 13374-2
Foreword
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
ISO 13374-2 was prepared by Technical Committee ISO/TC 108, Mechanical vibration and shock,
Subcommittee SC 5, Condition monitoring and diagnostics of machines.
machines — Data processing, communication, and presentation:
 Part 1: General guidelines
 Part 2: Data processing
 Part 3: Communication
 Part 4: Presentation
iv © ISO 2004 — All rights reserved

COMMITTEE DRAFT ISO/CD 13374-2

processing, communication, and presentation — Part 2: Data
processing
1 Scope
The various computer software systems written for condition monitoring and diagnostics (CM&D) of machines
that are currently in use cannot easily exchange data or operate in a plug-and-play fashion without an
extensive integration effort. This makes it difficult to integrate systems and provide a unified view of the
condition of machinery to users. The intent of ISO 13374 Parts 1 through 4 is to provide the basic
requirements for open CM&D software architectures which will allow CM&D information to be processed,
communicated, and displayed by various software packages without platform-specific or hardware-specific
protocols.
To adequately describe all data processing requirements, modern software design requires both an
information model and a processing model. This document details both the information model requirements
and the processing model requirements to which an open CM&D data processing architecture shall conform.
Parts 3 and 4 of the ISO 13374 series will address specific software specification requirements for
communication and presentation respectively.
2 Normative references
The following referenced document is indispensable for the application of this document:
ISO 13374-1:2003, Condition monitoring and diagnostics of machines – Data Processing, Communication,
and Presentation – Part One: General Guidelines
3 CM&D information architecture requirements
3.1 Overview
An information architecture describes all the data objects and their properties (or attributes), property data
types, data object relationships, reference data, and data documents for a given system or application. An
open CM&D information architecture specification shall describe their content for each of the five layers shown
in Figure 1.

ISO/CD 13374-2
Data Document Definitions Layer 5
Reference Data Library Layer 4
Implementation Data Model Layer 3
Conceptual Information Model Layer 2
Semantic Definitions Layer 1
Figure 1 — CM&D Information Architecture Layers
3.2 Semantic definition requirements
To ease understanding among various parties utilizing the information architecture, an open CM&D
information architecture specification shall provide a set of semantic definitions for each major data object in
the system. Non-formal description terminology, such as English language definitions of the data objects,
may be used. Formal descriptions utilizing ontological schemas, such as the proposed Resource Description
Format (RDF) of the World Wide Web Consortium (W3C), may also be utilized.
3.3 Conceptual information model requirements
A conceptual information model is an integrated definition of all the primary data objects relevant to CM&D,
along with their major properties (also called "attributes"), property data types, object interrelationships, and
object or relationship constraints. An open CM&D information architecture specification shall provide a non-
proprietary conceptual information model, sometimes referred to as a "schema", which is independent of how
the data is physically stored or accessed. This conceptual information schema is a blueprint of the location of
various data elements which facilitates system integration and data integrity. Using a conceptual schema, an
implementation data model can be verified.
The Unified Modelling Language (UML) has emerged as the software industry's dominant modelling language
and includes a standardized Class Diagram representation for information modelling. The Object
Management Group (OMG) adopted UML as its standard modelling language. As an approved Publicly
Available Specification (PAS) submitter to the International Organization for Standardization (ISO), the OMG
is proposing the UML specification for international standardization.
3.4 Implementation data model requirements
Based on the conceptual information model, an implementation data model provides the exact representation
of data elements which shall be transferred or stored. An open CM&D information architecture specification
shall provide an open implementation data model which conforms to its conceptual data model.
The open CM&D implementation data model shall allow for the integration of many sources of machinery
information, support peer-to-peer databases, allow user-defined lookup entries, and utilize standardized
timestamps and engineering units. The schema should support unique enterprise, site, and database or data
source identifiers to differentiate data taken at different physical locations. The schema should also support
unique, system-wide identifiers for plant segments containing machinery (service segment locations) in a
parent-child hierarchy. Also the schema should support unique asset-specific identifier to allow individual
component monitoring and tracking in a parts hierarchy.

ISO/CD 13374-2
The basic framework of storing enterprise, site, site database, process or machine segment information (such
as physical orientation, drive type, mounting type, and shaft coupling type), asset nameplate data (including
entries such as rated speed, rated power, make and model, and bearing or other component information),
measurement locations, data measurement sources, transducers, transducer orientation, engineering units,
signal processing post-scaling types, ordered lists, and alarms should be specified in the schema. At a data
level, the schema should support formats for communicating historical single-valued numeric data, Fast-
Fourier Transform (FFT) spectra data, constant percentage band (CPB) spectra, time waveforms, sample-
based test data, thermographic images, and binary large objects. The schema should support a date/time
notation that references back to a specific instance in time, using the Gregorian (Common Era, or CE)
calendar, with a lexical representation based upon the ISO 8601 standard [3] referenced to Universal
Coordinated Time (UTC) and also stores the local time zone offset.
This specification can be specified using various schema definitions. The file description schema format has
been used for years in the scientific programming community. It maps the format for ASCII or binary data files,
which can be exported from a computer system or imported into a computer system. A complete record
format description is published which specifies the data fields contained in the file, their exact location in
relation to the other data fields, whether the fields are in ASCII or binary format, and the exact data format –
real floating point, integer, character, varying character string – of each field.
The relational information schema format is the definition language for relational database management
systems. The relational method is analogous to a blue-print drawing which defines the various "room names"
or (tables) where data will be stored, the data "contents" or (columns) in the rooms, each data column's exact
data format (scientific floating point, integer, varying character string, etc.), whether or not a data column can
be empty or not (not null) and each data row's unique "key" (primary key) which uniquely identifies it. A table
can be related to another table by including a "reference" (foreign key) to it.
An Extensible Markup Language (XML) schema definition (XSD) is a recommended definition language. XML
is a project of the World Wide Web Consortium (W3C), and the development of the specification is being
supervised by their XML Working Group. XML is a public format written in the Standard Generalized Markup
Language (SGML), the international standard (ISO 8879:1986 [1]) for defining descriptions of the structures of
different types of electronic documents. The version 1.0 specification was accepted by the W3C as a
Recommendation on February 10, 1998. On May 3, 2001, the W3C issued XML Schema as a W3C
Recommendation. XML Schemas define shared markup vocabularies, the structure of XML documents,
which use those vocabularies, and provide hooks to associate semantics with them. By bringing datatypes to
XML, XML Schemas increases XML's utility to the developers of data interchange systems. XML Schemas
allow the author to determine which parts of a document may be validated, or identify parts of a document
where a schema may apply. Further, as XML Schema are XML documents themselves, they may be
managed by XML authoring tools.
Regardless of which information schema format is chosen the data model shall define a minimum set of data
elements that should be included in the schema for compliance. In addition, a list of optional elements shall
be included.
3.5 Reference data library requirements
To effectively utilize an implementation data model, standard entries for various look-ups need to be stored in
a reference data library. An open CM&D information architecture specification shall provide an open
reference data library which conforms to its implementation data model. The specification should support
populating and maintaining industry-standard taxonomies and codes for the reference data and allow both
suppliers and end-users to add industry-specific and customer-specific entries to the library using database-
unique entries. The specification shall also support the creation of a standard set of reference codes in
various languages as required.
The reference data library specifies all code tables for segment (machine/component) type codes, asset type
codes, measurement location type codes, engineering unit type codes, sampling test codes,
diagnostic/prognostic event codes, health codes, failure codes, and root cause codes. The library also houses
engineering unit codes, measurement location type codes, and mounting orientation codes.

ISO/CD 13374-2
3.6 Data document definition requirements
An open CM&D information architecture specification shall also specify the format for the publication of a data
document. The specification allows the reference data library to be read or written in a standardized way and
supports applications which need data import/export capability.
Specifications which utilize the file description schema format as their implementation data model will most
likely utilize the same specification for the publication of an ASCII or binary data document. The complete
record format description shall be published, which specifies the data fields contained in the file, their exact
location in relation to the other data fields, whether the fields are in ASCII or binary format, and the exact data
format – real floating point, integer, character, varying character string – of each field.
Specifications which utilize the XML schema format as their implementation data model will most likely utilize
the same format for the publication of an XML data document. XML schema provides the definition of the
XML document and XML parsers and validation tools can verify the syntax of the document's content.
3.7 Compliant specifications
MIMOSA is a non-profit trade association which develops and encourages adoption of open information
standards for Operations and Maintenance. MIMOSA publishes an open CM&D specification which is
compliant with the above requirements. The specification is known as the MIMOSA Open Systems
Architecture for Enterprise Application Integration (OSA-EAI™) specification. Appendix A describes this
specification in more detail.
4 CM&D processing architecture requirements
4.1 Overview
A processing architecture describes all the interactions or transactions which are between modules internal to
the software system itself, external from end-user interactions, or external from other software system
interactions. An open CM&D processing architecture specification shall utilize the processing architecture
shown in Figure 2. This architecture is defined as blocks of data processing functionality. After each block in
the system has been properly configured, the basic data is converted into digital form in Data Acquisition (DA)
and is processed in various ways as it is transformed into actionable information, resulting in Advisory
Generation (AG). As the processing progresses from data acquisition to advisory generation, data from
preceding blocks needs to be transferred to subsequent blocks and additional information acquired from or
sent to external systems. Similarly, as the data evolves into information, both standard technical displays and
graphical presentation formats are required. In many applications, data archiving is required in order to
maintain a history of the output of each block. Each block is responsible for managing data quality, as required,
and flagging its output with the appropriate assessment. Output should be identified as good, bad, or
undetermined.

ISO/CD 13374-2
Figure 2 — Data processing block diagram

ISO/CD 13374-2
4.2 Data Acquisition (DA) blocks
As detailed in Figure 3, the data acquisition block has been generalized to represent the software module that
provides system access to digitized sensor or transducer data. The data acquisition module may represent a
specialized data acquisition module that has analog feeds from legacy sensors, or it may collect and
consolidate sensor signals from a data bus. Alternately, it might represent the software interface to a smart
sensor. The data acquisition module is basically a server of calibrated digitised sensor data records.
Data Acquisition (DA) Block

Transforms the output of a transducer or test to a scaled digital representation.
Analog Digital Manual
Input Input Input
DA Control
Triggers
(for operating state
DA Output notification)
Buffer / DA Processing
Archive • Gather digital and manual input data DA Synchronization
• Gather analog input data and perform analog Signals
to digital conversion (for multi-channel
simultaneous data
acquisition)
DA Configuration
(DA measurement
location data, DA
parameters,
DA Output DA Configuration etc.)
(digitized data with timestamp &
data quality)
Figure 3 — Data Acquisition block
The output of all DA blocks shall contain the following:
 digitized data
 timestamp of data collection with UTC reference and local time zone
Examples of the digitized data include:
 floating point values for scalar data
 magnitude and time series for dynamic data
 thermal radiation data with digitised image for thermographic data
 sample test results for lubricating fluid/air/water sample data

ISO/CD 13374-2
4.3 Data Manipulation (DM) blocks
As detailed in Figure 4, the data manipulation block processes the digital data from the DA block to convert it
to a desired form which characterizes specific descriptors (features) of interest in the machine condition
monitoring and diagnostic process. Often the functionality within this layer consists of some signal processing
algorithms.
Data Manipulation (DM) Block

Calculates descriptors (features) from sampled sensor data, other descriptors,
or the output of computations. The computation may be characterized as an
input-output mapping.
DA Input DM Input
DM Processing
• Gather current data from DA modules
and other DM blocks
DA Output
Buffer / • Retrieve DA or other DM historical data
Archive • Perform signal transformation (e.g., DM Configuration
FFT, and digital filtering) (DM measurement
location data, DM
• Perform synchronous and non- algorithm
DM Output synchronous averaging parameters, etc.)
Buffer / • Perform computations
Archive
• Perform feature extraction
DM Output DM Configuration
(descriptor data with timestamp &
data quality)
Figure 4 — Data Manipulation block
This block may contain speciality processing functions such as Fast Fourier Transforms, wavelets or simple
average values over a time interval.
Examples of the descriptor outputs of the DM block include:
 Extracted feature
 Conversion from time domain to frequency domain and vice versa
 Calculated, non-interpretative values
 Virtual sensor (differential pressure from inlet & outlet pressure)
 Integrating acceleration to velocity
 Filtering
 Normalization
 Time series including sample rate

ISO/CD 13374-2
4.4 State Detection (SD) blocks
As shown in Figure 5, the primary function of the state detection (sometimes referred to as “state awareness”)
is to compare DM and/or DA outputs against expected baseline profile values or operational limits and output
enumerated state indicators (e.g. level low, level normal, level high, "alert", "alarm", etc). The state detection
module may also generate alerts based on defined operational limits or baselines. When appropriate data is
available, the state detection block should generate assessments based on operational context, sensitive to
current operational state or operational environment.
State Detection (SD) Block

Categorizes data and generates descriptors for a measurement location,
component, or system as normal or abnormal, including the degree of abnormality
in the associated operational context. Also known as “state awareness”.
DA Input DM Input SD Input
SD Processing
DM / DA Output • Gather current data from DM, DA, and SD Operational Data
Buffer / other SD blocks (load, etc. from external
• Retrieve DM, DA, and other SD system)
Archive
historical data
• Retrieve operational load data SD Configuration
SD Output • Calculate current values of (SD location/
Buffer / condition/statistical indicators component/
Archive system data,
• Evaluate state SD algorithm
parameters, etc.)
SD Output SD Configuration
(current enumerated state indicator, threshold
boundary alerts, and statistical analysis data
with timestamp & data quality)
Figure 5 — State Detection block
Typically, this block of processing provides data which will contribute to a diagnosis in the health assessment
block. The SD block may make use of current and historical DA and DM inputs to evaluate the current state.
It may provide data manipulation and sensor module control signals such as acquisition scheduling
commands, data triggers and processing instructions.
Examples of outputs of the SD block include:
 Enumerated state indicator
 Threshold boundary alerts
 Severity of threshold boundary deviation above/below
 Rate of change alert
 Anomalies
 Statistical analysis

ISO/CD 13374-2
4.5 Health Assessment (HA) blocks
As shown in Figure 6, the health assessment block is an information block which utilizes expertise from a
human or automated agent to determine the current health of the equipment and diagnose existing fault
conditions. It determines the state of health and potential failures by fusing the outputs of the DA, DM, SD,
and other HA blocks.
Health Assessment (HA) Block

Performs agent-specific assessments of a component’s or system’s current health
state with the associated diagnoses of discovered abnormal states in the associated
operational context. May also include evidence and explanation information.
DA DM SD HA
Input Input Input Input
HA Processing
• Gather data from SD, DM, DA,
SD / DM / DA and other HA blocks HA Operational Data
Output Buffer / • Retrieve SD, DM, DA, and other (load, etc. from external
system)
Archive HA historical data
• Retrieve operational data
• Estimate current health grade HA Configuration
(HA agent data,
HA Output • Diagnose failures HA component/system data,
Buffer / • Generate evidence, and HA algorithm parameters, etc.)
Archive explanation
HA Output HA Evidence & HA Configuration

(health grade & Explanation
diagnosed failures)
Figure 6 — Health Assessment block
An output of this block includes the component/system's current health grade and diagnosed failures with
associated likelihood probability. A calculation of the current Risk Priority Number (RPN) may also be
performed. Modelling of ambiguity groups and multiple hypotheses may be included in the output data
structures. The HA block may also output an explanation detailing the evidence for a diagnosis or health
grade.

ISO/CD 13374-2
4.6 Prognostic Assessment (PA) blocks
As shown in Figure 7, the primary function of the prognostic assessment block is to project the future state of
the monitored equipment, taking into account projected future operational usage. This block determines the
future state of health and future failure modes by combining the relevant outputs of the DA, DM, SD, and other
HA blocks and applying a prognostic algorithm or model based on supplied projected operational utilization.
To aid the algorithm or model, the HA block may also retrieve account historical failure data and operational
history, along with projected failure rates related to operational utilization.
Prognostic Assessment (PA) Block

Performs agent-specific assessments of a component’s or system’s future health
state with the associated predicted abnormal states and remaining life for a projected
operational context. May also include evidence and explanation information.
DA DM SD HA PA
Input Input Input Input Input
PA Processing
• Gather data from HA, SD, DM,
DA, and other PA blocks PA Operational Data
HA / SD /
• Retrieve HA, SD, DM, DA, and (projected future load, etc.
DM / DA
other PA historical data from external system)
Output Buffer /
• Retrieve projected future
Archive
operational data PA Configuration
PA Output • Estimate future health grade (PA agent data,
• Prognose failures PA component/system data,
Buffer / PA algorithm parameters, etc.)
Archive • Prognose remaining life
• Generate evidence & explanation
PA Output PA Evidence & PA Configuration

(future health grade, Explanation
future failures,
remaining life)
Figure 7 — Prognostic Assessment block
The prognostics layer may report health grade at a future time, or may estimate the remaining life of an asset
given its projected usage profile. Assessments of future health or remaining life may also have an associated
prognosis of the projected fault condition. A calculation of the future Risk Priority Number (RPN) may also be
performed. An output of this block includes the future component/system's future health grade and future
failure events with associated likelihood probability. Modelling of ambiguity groups and multiple hypotheses
may be included in the output data structures. The PA block may also output an explanation detailing the
evidence for a proposed failure event or health grade.

ISO/CD 13374-2
4.7 Advisory Generation (AG) blocks
As detailed in Figure 8, the primary function of advisory generation data processing block is to integrate
information from DA, DM, SD, HA, PA, other AG blocks, and external constraints (safety, environmental,
budgetary, etc.) and provide optimized recommended actions and alternatives to applicable personnel or
external systems. Recommendations may include prioritised operational and maintenance actions and
capability forecast assessments., or modifying operational profiles to allow mission completion. The decision
support module needs to take into account operational history (including usage and maintenance), current and
future mission profiles, high-level unit objectives, and resource constraints.
Advisory Generation (AG) Block

Integrates information (including safety, environmental, operational goals,
financial incentives, etc.) to generate advisories to operations & maintenance
and respond to capability forecast assessment requests.
DA DM SD HA PA AG
Input Input Input Input Input Input
AG Processing AG Operational Data

• Gather data from PA, HA, SD, (projected future load &
PA / HA / SD / DM, DA, and other AG blocks operational goals from
DM / DA • Retrieve PA, HA, SD, DM, DA, external system)
Output Buffer / and other AG historical data External Constraints
Archive • Retrieve projected future (safety, environmental,
operational goal data budgetary, etc. from
AG Output • Retrieve external constraints external system)
Buffer / • Generate O&M advisories AG Configuration
Archive • Generate evidence & explanation (AG agent data,
AG component/system data,
AG algorithm parameters, etc.)
AG Output AG Evidence & AG Configuration

(O&M advisories & Explanation
capability forecast
assessments)
Figure 8 — Advisory Generation block
Maintenance advisories from this block should detail future maintenance work required, which may include the
verification of monitoring data or the performance of additional monitoring. The structure of these advisories
should be put into a "work request" format for external maintenance work management systems. Based on
this request, maintenance work management systems can schedule work in advance and locate spare parts
and tools required for these jobs.
Operational advisories from this block can be immediate in nature, such as the current notification of operators
of alerts and resulting action steps. Other production-related advisories can be more strategic, such as
sending a notice to a production planning system about the high risk of failure on a production line due to a
soon-to-fail critical piece of equipment.
Capability forecast assessments from this block provide the results for requests of the likelihood of
accomplishing a specific mission or production run. These assessments are critical to production forecasting
systems when evaluating whether or not to accept certain missions/orders and where to assign the work
based on asset optimization principles.

ISO/CD 13374-2
4.8 Block configuration
Each data processing block requires configuration information, some of which may be static data and other
parameters may be changed dynamically by the system during operation.
As an example, the following is a sample of the configuration of the Data Acquisition block:
 Measurement Location Description (Measurement Location table)
 Orientation & Relative position
 Location Description
 Monitoring Intervals – Dynamic vs. Static
 On-line Continuous
 On-line Polled
 Default polling rate
 Default parameters
 Triggered vs. Non-triggered
 Set points
 Deadband
 Asynchronous vs. synchronous
 Transducer Information
 Response curve
 Measurement confidence
 Transducer electronic data sheet (TEDS) information
 Calibration
 Channels
 Single or Multiple channel collection
4.9 External systems
Retrieval of previous work histories from the maintenance system and previous operational data
(starts/stops/loads) from a process data historian is important in the assessment of machinery health. After a
health assessment is made, the maintenance action to be taken can range from increasing the frequency of
inspection, to repair or replacement of the damaged machinery or component. The affect on operations may
be an adjustment of operating procedures or a request to shutdown the equipment immediately. This need for
rapid communication to maintenance and operational system requires software interfaces to maintenance
management systems and operational control systems. These interfaces are useful in order to communicate
recommended actions in the form of maintenance work requests and operational change requests.

ISO/CD 13374-2
4.10 Data archiving
Data archiving is an important feature during all processing of a machine condition monitoring program.
Previous data trends can be analysed for statistical relevance. Previous advisories should be audited for
accuracy and root cause information added upon its discovery.
4.11 Technical displays
To facilitate analysis by qualified personnel, relevant technical displays showing data from each block is
necessary. These displays will be expanded in detail in ISO 13374 Part 4. These displays should provide the
analyst with the data required to identify, confirm, or understand an abnormal state.
4.12 Information presentation
Information from the HA, PA, and AG blocks are displayed by this processing block. These displays will be
expanded in detail in ISO 13374 Part 4. It is important that the data be converted to a form that clearly
represents the information necessary to make corrective action decisions. In some cases, the user will need
the ability to drill down into the SD, DM, and DA technical displays when anomalies are reported.
4.13 Compliant specifications
An open CM&D processing architecture specification shall utilize the processing architecture as described
above. Specifications shall specify a processing data model/schema and an application programming
interface (API) interface description which meets ISO/IEC 14750:1999 for the processing blocks which they
expose. This will allow various data processing blocks from various suppliers to be integrated into a complete,
functional system. MIMOSA publishes an open CM&D specification which is compliant with the above
requirements. The specification is known as the MIMOSA Open Systems Architecture for Condition Based
Maintenance (OSA-CBM™) specification. Appendix A describes this specification in more detail.
Figure 9 shows how these blocks can interact with each other to form a complete integrated system. The hub
of the wheel structure represents the communications medium between the modules, which may be
accomplished using popular communication and middleware technologies. Therefore, the modules do not
need to reside on the same machine but may reside anywhere on a local or worldwide network. Open
systems architecture design enables the integration of improved prognostic capability within new or existing
system designs, allowing maximum flexibility for future upgrades to the system.

ISO/CD 13374-2
Prognostic
Assessment
Advisory
Health Generation
Assessment
Faulty
Uncertain
Healthy
Distributed
Computing
State Technology External
Detection Systems
Envelope Detector
Band-Pass Envelope
Accelerometer Filtered Rectified Detected
Half-wave
Data Signal Signal Signal
Band-Pass or Peak-Hold
Filter Full-wave Smoothing
Rectifier
Data Data
Manipulation Acquisition
N
N ∑ (ri − r )4
NA4 = i=1
1 m  N 2 
2
Traditional
 ∑ ∑ (rij − rj ) 
 m j=1  i =1  Sensor
Smart Sensor
Figure 9 — Data processing Flow Within a Standard Architecture
A module may implement functionality of one or more data processing blocks from the processing architecture.
For example, module A from Figure 10 implements the functionality of the State Detection block. Module B, on
the other hand, implements functionality of two blocks: Health Assessment and Prognostic Assessment. A
module may implement one or more block APIs. Modules from other layers implement one or more layer APIs.
For instance, module D from Figure 10 implements the functionality of two blocks: Data Manipulation and
State Detection. In this case, the module provides information about manipulated data and computed
conditions.

ISO/CD 13374-2
Prognostic Assessment API
Prognostic Assessment
BB
Health Assessment API
Health Assessment
State Detection API

CC
State Detection AA
DD
Data Manipulation API
Data Manipulation
Data Acquisition API
Data Acquisition
Figure 10 — Example of Compliant Modules
An example of a complete OSA-CBM compliant system is shown in Figure 11. The system has the largest
number of Data Acquisition (DA) blocks which feed into more complex blocks until finally one Advisory
Generation (AG) block sends its maintenance and operations decision support to an external user display.
Generation
Advisory
6.1 Mntnce/Ops. Dec. Supp. User Display

Assessment Assessment
Prognostic
5.1 Motor/Pump Prognostics
4.4 Gnd-Bsd Mot./Pump Hlth.

Health
4.3 Int. Motor/Pump Health
4.1 Motor Health 4.2 Pump Health

Detection
3.2 Winding Cond. 3.3 Pump Cond. 3.4 Oper. Contxt.

State
3.1 Motor Cond.
2.5 Neural Anal.

Acquisition Manipulation
2.6 FFT Analyses

Data
2.1 Vel. Dec. 2.2 Curr. Dec. 2.3 Accelerometer. Dec. 2.4 Accelerometer. Dec.
Data
1.1 Encoder 1.2 Flow Comm 1.3 Curr. Sensor 1.4 Motor Acc. 1.5 Pump Acc.
Figure 11 — Example of an OSA-CBM Compliant Modular System

ISO/CD 13374-2
Annex A
(informative)
Compliant specifications
MIMOSA's OSA-EAI™ CM&D Information Architecture Specification

MIMOSA is a non-profit trade association, which develops and encourages adoption of open information
standards for operations and maintenance. MIMOSA is composed of industrial asset management system
providers and industrial asset system end-users who develop open information integration specifications for
managing physical assets.
MIMOSA’s Open Systems Architecture for Enterprise Application Integration (OSA-EAI) specification
(available for download at www.mimosa.org) is compliant as a CM&D information architecture specification
with ISO 13374 Parts 1 & 2 and facilitates the integration of asset management and CM&D information
throughout multi-site enterprises. MIMOSA’s OSA-EAI system specifications offer advantages for
maintenance and reliability users as well as technology developers and suppliers.
For users, the adoption of MIMOSA OSA-EAI specifications facilitates the integration of asset management
information, provides a freedom to choose from a broader selection of software applications, and saves
money by reducing integration and software maintenance costs.
For technology suppliers, the adoption of MIMOSA OSA-EAI specifications stimulates and broadens the
market, allows concentration of resources on core high-value activity rather than low value platform and
custom interface requirements, and provides an overall reduction in development costs.
The OSA-EAI Version 3.0 architecture is shown in Figure A.1 below:
MIMOSA OSA-EAI Architecture: May 2004
Tech-File XML File Import & Export Application Tech-Web HTTP Client & Server Application
By Access Type and Support Level V3.0 Spec. [PDF] By Access Type and Support Level V3.0 Spec. [PDF]
Tech-Doc Producer/Consumer Schemas [XSD] Tech-XML Client & Server Interface Schemas [XSD]
By Access Type and By Support Level V3.0 [PDF] By Access Type and Support Level V3.0 [PDF]
CRIS Reference Data Library V3.0 [XML & SQL]
Common Relational Information Schema (CRIS) V3.0 [XSD, PDF, & SQL]
Common Conceptual Object Model (CCOM) V3.0 [UML]
OSA-EAI Terminology Dictionary V3.0 [PDF]
Production Access Types Support Levels Technology Types [Tech-]

Read-Only 1 REG (Physical Asset Register Management)
Beta Write-Only 2 WORK (O&M Agent Work Management)
Read/Write DIAG (Diagnostics / Prognostics / Health Assessment)
Draft TREND (Operational Scalar Data & Alarms)
DYN (Dynamic Vibration/Sound Data & Alarms)
Design Phase SAMPLE (Oil/Fluid/Gas/Solid Test Data & Alarms)
BLOB (Binary Data/Thermography Data & Alarms)
OPC Foundation Specification REL (RCM/FMECA/Model Reliability Information)
Figure A.1 — MIMOSA OSA-EAI Architecture Diagram

ISO/CD 13374-2
OSA-EAI Terminology Dictionary

To ease understanding among all parties using MIMOSA's OSA-EAI specification, MIMOSA provides a
standard set of terminology in the OSA-EAI Terminology Dictionary. This provides the basic semantic
descriptions used throughout the OSA-EAI specifications.
Common Conceptual Object Model (CCOM)

The Common Conceptual Object Model (CCOM) provides the basic conceptual model basis for OSA-EAI.
Software designers familiar with class diagrams in Unified Modelling Language can utilize this model to
understand the basic classes, major attributes, and relationships between classes in OSA-EAI. CCOM V3.0 is
available in PDF document form and Visio (VSD) format.
Common Relational Information Schema (CRIS)

MIMOSA's Common Relational Information Schema (CRIS) provides a common implementation schema
which allows information from many systems to be communicated and integrated. The schema is in a
relational format, commonly used in most database systems. Each table in CRIS is assigned a unique table
reference number. CRIS V3.0 is published in PDF document form, Word document form (DOC), and XML
Schema (XSD) form.
Data sources which house asset information are not required to be physically re-designed to match CRIS, but
must be able to translate their information into CRIS tables and columns. In order to ease this translation and
for MIMOSA implementers who desire to implement a physical CRIS database, MIMOSA provides an
ORACLE and Microsoft SQLServer table creation scripts.
CCOM/CRIS contain standard enterprise, site, functional segment, asset, and agent identification
nomenclature. An enterprise is the corporate level of an organization, or the top organizational structure of a
non-profit or military body. An enterprise is composed of many sites. The enterprise uniquely identifies the
sites it manages. The enterprise ID is a globally-unique identifier and is defined as a 4-byte, non-negative
integer assigned by MIMOSA. Normally, MIMOSA will issue one enterprise ID per corporation/organization.
For some organizations, multiple enterprise IDs may be requested. In addition, MIMOSA will also assign the
enterprise with a globally-unique, alpha-numeric user tag identifier value. This can be used in conjunction with
the user tag identifier in the site table to form a globally unique text string. A representative from the
registration authority for an organization should e-mail the MIMOSA Enterprise Registrar at
info@mimosa.org with the name of the organization, requested enterprise User Tag Identifier, contact name,
title, phone number, and e-mail address. The MIMOSA Enterprise Registrar will then assign the enterprise ID
and enterprise User Tag Identifier and return the assigned non-negative integer and associated 8-byte string
to the point of contact.
A “site” is what an enterprise defines as an entity which can be decomposed into segments and which
generates new assets, agents, databases, and measurement locations. A given enterprise can contain many
sites. A site can contain many segments. For facility applications, the “site” normally represents a building.
For industrial applications, this entity normally represents a physical plant. For fleet applications, this entity
normally represents a “mobile platform”, which could be an aircraft carrier or a tank. Each enterprise must
uniquely identify its sites by a 4-byte, non-negative site ID integer to allow multiple sites to utilize the MIMOSA
standards without fear of duplication when combining information at the enterprise level. The site ID is a 4-
byte, non-negative integer. Each enterprise is free to assign site IDs in the range from 0 – 4,294967,295 (Hex
“00000000” – “FFFFFFFF”). Once this assignment has been made, the number should not be changed.
Because CCOM and CRIS are designed for multi-site collaborative asset lifecycle management, nearly all
table in CRIS (except MIMOSA-owned reference tables) include a reference to the enterprise/site/database.
To keep the number of primary key columns to a minimum, CRIS V3 combines the enterprise ID (also 4-
bytes) and the site ID into a fixed-length 16-character MIMOSA site code. This site code is composed of
these two 4-byte non-negative integers which are converted into their hexadecimal format (resulting in 8
characters per integer) and then concatenated into a fixed-length 16-character string.
Version 3 of CCOM & CRIS have also added the ability to build Site templates. Templates are like "models"
of sites which allows you to predefine characteristics of a Site, including its Segments, which software can
utilize when instantiating a new Site which matches that template. In addition, they provides for a method of
standard measurement location identification across various condition monitoring technologies. Trendable,
scalar data such as operational temperatures, pressures, and loads are modelled in CCOM/CRIS.
CCOM/CRIS support dynamic data, such as time waveforms and Fast Fourier Transforms (FFTs), which are

ISO/CD 13374-2
used in vibration analysis and sound monitoring. Binary data, known as Binary Large OBjects or (BLOBs),
are supported for communicating drawings, reports, diagrams, and photographs. CCOM/CRIS also manages
sampling test data results, such as used oil analysis test data and air quality monitoring data. CCOM/CRIS
also allows the communication of diagnostic, health, and prognostic information from smart systems and
eases the generation of advisory recommendations. Special maintenance and reliability tables define fields
for events (actual, hypothesized, proposed), health, estimated asset life assessment, and recommendations.
CCOM/CRIS model maintenance and production work request scheduling and the tracking of the completion
(or non-completion) of a maintenance or production job as related to an asset. CCOM/CRIS also provides
the information framework for storing reliability data for assets.
CRIS Reference Database Specification

CCOM/CRIS contain many "type" classes/tables, which allow users to associate types of enterprises, sites,
segments, assets, agents, measurement locations, engineering units, etc. with standard numeric codes,
common throughout all their various systems. MIMOSA generates and maintains industry-standard
taxonomies and codes for most of these tables, but CCOM/CRIS allow both suppliers and end-users to add
industry-specific and customer-specific entries to these tables. MIMOSA experts have generated a large
reference database, the CRIS Reference Database Specification in XML, and several popular relational
database formats. Version 3 of this database specification contains many useful codes which allow
standardization across many disparate systems—even those from various countries. For example, the asset
type table allows standard querying of common asset types such as “AC induction motor” which have
unchanging three-integer unique identifiers. Other standard code tables include service segment,
measurement location, engineering units, sampling test codes, diagnostic/prognostic event codes, health
codes, failure codes, and root cause codes. This allows systems to search across various systems for
common failures on certain equipment types.
Tech-XML Client/Server Interface Schemas

A key component of MIMOSA’s Open System Architecture for Enterprise Application Integration (OSA-EAI) is
the Tech-XML Client/Server interface schemas. These XML schemas provide a common set XML-based
client/server interface definitions for various communication protocols. The Tech-XML interfaces specify the
contents of a client/server data exchange, but do not specify the physical transport method.
Tech-Doc Producer/Consumer Interface Schemas

For XML document-based systems, MIMOSA provides the Tech-Doc Producer/Consumer interface schemas,
which publish/consume CRIS data from a given technology in an XML document format. Tech-Doc interfaces
specify the contents of an XML document, but do not specify the physical storage and transport method of the
produced/consumed document. Tech-Doc Consumer Read-only applications will utilize a Tech-Doc XML
document, but not change its permanent data storage based on this information. Tech-Doc Consumer Write-
only applications change their permanent data storage after successful file import.
Tech-XML and Tech-Doc Technology Types

Both of these OSA-EAI interface technologies (Tech-XML & Tech-Doc) are further sub-divided into eight (8)
Technology Types (see Architecture Diagram above). This allows developers to focus on supporting only
what is relevant to their particular application area, such as vibration analysis or maintenance management.
The technology types are listed in table A.1 below.
To refer to the entire set of 8 Application Technology Packages, the italicized prefix "Tech-" is used. Each
vertical application technology only has certain CRIS tables which are relevant. This allows implementers to
pair down the entire CRIS specification to only the application-specific tables. To support this, MIMOSA
publishes the Tech-XML Support Level n CRIS V3.0 Subset Specification for Tech-XML developers and
the Tech-Doc Support Level n CRIS V3.0 Valid Table Entity Specification for Tech-Doc developers.

ISO/CD 13374-2
Table A.1 — OSA-EAI Application Technology Packages

Technology Description
Types
Asset Register Allows retrieval of "as-designed" segment hierarchical breakdown of facility,

Management process, and machine systems, along with the "as-installed" asset information.
Also allows access to name plate and image data on individual assets and models,
including component part breakdowns.
(REG) Used by:

- OEM Model Information Systems
- Asset Registry Information Systems
- Maintenance Management Systems
- Piping & Instrumentation Design Systems
Work Allows the creation and audit tracking of a new work request in a work management
Management system for a service segment or a serialized asset. Allows the retrieval of work
orders and work order steps, and actual work completed information.. Also allows
the retrieval of pre-planned work packages ("solution packages").
(WORK) Used by:

- Maintenance Management Systems
Diagnostics / Enables retrieval of human or "smart-agent" generated current and/or future

Health / Rec. proposed asset health states, current and/or future proposed diagnostic failure
modes and casual trees, remaining useful life predictions, and recommendations.
Also allows access to measurement evidence supporting the diagnoses/prognoses.
(DIAG) Used by:

- Diagnostic Systems
- Prognostic Systems
Dynamic Enables the creation and retrieval of historical dynamic measurements (used with
Vibration / vibration and sound monitoring and including frequency spectra measurements and
Sound time waveforms), abnormal data alarms, and operational event logs.
(DYN) Used by:

- Vibration Condition Monitoring Systems
- Sound Condition Monitoring Systems
Static Enables the creation and retrieval of historical scalar measurements, abnormal data
Trends/Alarms alarms, and operational event logs.
(TREND) Used by:

- Process Data Historians
- Process Condition Monitoring Systems
- Used by Operational Data Systems
Oil/Fluid/Gas/So Enables the creation and retrieval of historical fluid, air, and solid sampling data,
lid Tests abnormal data alarms, and operational event logs.
(SAMPLE) Used by:

- Oil Sampling Condition Monitoring Systems

ISO/CD 13374-2
Technology Description
Types
- Air Sampling Condition Monitoring Systems

- Solid Sampling Condition Monitoring Systems
Binary Enables the creation and retrieval of historical binary large objects (BLOB)
Data/Thermo- measurements (used with thermography and imaging monitoring), abnormal data
graphy alarms, and operational event logs
(BLOB) Used by:

- Thermographic Condition Monitoring Systems
- Image Monitoring Systems
Tech-Web Specifications
The OSA-EAI Tech-Web specifications are used for building a server or a client which can communicate data
and information between condition monitoring systems, diagnostic systems, reliability management systems,
registry management systems, and work management systems via HTTP or HTTPS (secure) protocol using
XML messages. The interfaces are defined using XML Schema and specified in a client/server fashion.
Tech-Web servers must comply with MIMOSA's Tech-Web Client & Server HTTP Binding Specification
supporting interfaces defined for a given technology type (TREND, REG, WORK, etc), access type (Read-
Only, Write-Only, or Read/Write), support level (level 1 or 2), and version level (3.0).
MIMOSA's OSA-CBM™ CM&D Processing Architecture Specification

MIMOSA’s Open Systems Architecture for Condition-Based Maintenance (OSA-CBM) specification (available
for download at www.osacbm.org) is compliant as a CM&D processing architecture specification. In order to
standardize an architecture for a CBM system, the system must be broken down into generalized components
or functions. This software architecture has been described in terms of functional layers. Starting with data
acquisition and progressing towards decision support, the general functions of the layers are specified below.
Each layer has the capability of requesting data from any functional layer as needed, however data flow will
usually occur between adjacent functional layers.
• Layer 1 – Data Acquisition: The data acquisition module has been generalized to represent the
software module that provides system access to digitized sensor or transducer data. The data
acquisition module may represent a specialized data acquisition module that has analog feeds from
legacy sensors, or it may collect and consolidate sensor signals from a data bus. Alternately, it might
represent the software interface to a smart sensor (e.g. IEEE 1451 compliant sensor). The data
acquisition module is basically a server of calibrated digitized sensor data records.
• Layer 2 – Data Manipulation: The data manipulation module may perform single and/or multi-channel
signal transformations along with specialized CBM feature extraction algorithms.
• Layer 3 – State Detection: The primary function of the state detection module is to compare features
against expected values or operational limits and output enumerated condition indicators (e.g. level
low, level normal, level high, etc). The state detection module may also generate alerts based on
defined operational limits. When appropriate data is available, the condition monitor may generate
assessments of operational context (current operational state or operational environment).
• Layer 4 – Health Assessment: The primary function of the health assessment layer is to determine if
the health of a monitored system, subsystem, or piece of equipment is degraded. If the health is
degraded, this layer may generate a diagnostic record that proposes one or more possible fault
conditions with an associated confidence. The health assessment module should take into account
trends in the health history, operational status and loading, and the maintenance history.

ISO/CD 13374-2
• Layer 5 – Prognostic Assessment: The primary function of the prognostics layer is to project the
current health state of equipment into the future, taking into account estimates of future usage profiles.
The prognostics layer may report health status at a future time, or may estimate the remaining useful
life (RUL) of an asset given its projected usage profile. Assessments of future health or RUL may
also have an associated diagnosis of the projected fault condition.
• Layer 6 – Advisory Generation: The primary function of the advisory generation module is to provide
recommended actions and alternatives and the implications of each recommended action.
Recommendations include maintenance action schedules, modifying the operational configuration of
equipment in order to accomplish mission objectives, or modifying mission profiles to allow mission
completion. The decision support module needs to take into account operational history (including
usage and maintenance), current and future mission profiles, high-level unit objectives, and resource
constraints.
After the specification is defined and developed for each CBM module, the modules can be constructed into a
complete functional CBM system. Open systems architecture design enables the integration of improved
prognostic capability within new or existing system designs, allowing maximum flexibility and upgradeability of
the system.
OSA-CBM Framework
The OSA-CBM framework was developed around input from the functional layer descriptions and existing and
emerging standards for monitoring and maintenance, such as MIMOSA's OSA-EAI Information Schema, AI-
ESTATE, and IEEE 1451.2. The OSA-CBM framework currently excludes the decision support layer since it
is application specific. The presentation layer was designed as a client-only layer in order to stay open to any
user interface technology; no interfaces are therefore defined as part of the standard. The first step was
defining an object oriented data model in Unified Modeling Language (UML) for each layer that was then
converted into an abstract interface specification. The abstract specification can then be converted to the
desired middleware language for a specific interface definition. The components of the OSA-CBM
development architecture are shown in Figure A.2 below.
The UML object model defines interfaces only. For a given layer of the architecture, the data model does not
prescribe the object classes that would be required for a software implementation. The focus is on describing
the structure of the information that might be of interest to clients of that layer. OSA-CBM does not impose
any requirements on the internal structure of compliant software modules. The architectural constraints are
applied to the structure of the public interface and to the behavior of the modules. This approach allows
complete encapsulation of proprietary algorithms and software design approaches within the software module.

ISO/CD 13374-2
Advisory Generation
Prog. Assessment
Health Assessment
State Detection
Data Manipulation
Data Acquisition
Figure A.2 — OSA-CBM Development Architecture
Once the UML data model was defined for each layer, it was converted into a Pseudo-code language that
could be ported to concrete interface definition languages. Abstract Interface Definition Language (AIDL) was
selected as the Pseudo-code language. Using a custom Java program, this AIDL code was then converted
into an XML Schema. The AIDL file is also used to generate COM/DCOM IDL files and documentation. Note
that the UML, AIDL, COM/DCOM, OMG CORBA IDL, and XML Schema files are provided for each layer
(excluding the decision support layer), therefore generation of these files is not necessary by the system
developer. For a copy of the current open specifications including the UML, AIDL, XML, OMG CORBA IDL,
and COM/DCOM IDL files, see www.osacbm.org.

ISO/CD 13374-2
Bibliography
[1] ISO 8879:1986, Information processing – Text and office systems – Standard Generalized Markup
Language (SGML)
[2] ISO 10646 (all parts), Information technology – Universal Multiple-Octet coded Character Set (UCS)
[3] ISO 8601:2000, Data elements and interchange formats – Information interchange - Representation of
dates and times (available in English only)
[4] ISO/IEC 9579:2000 Information technology -- Remote database access for SQL with security
enhancement
[5] ISO/IEC 9075 (all parts), Information technology – Database languages
[6] ISO/IEC 9506 (all parts), Industrial automation systems – Manufacturing Message Specification
[7] ISO/IEC 19500-2, Information technology – Open Distributed Processing – GIOP/IIOP
[8] ISO/IEC 10746 (all parts), Information technology – Open Distributed Processing – Reference Model
[9] ISO/IEC 14750:1999, Information technology – Open Distributed Processing – Interface Definition
Language
The following documents, also prepared by ISO/TC 108, provide additional information about specific
diagnostic fields:
[10] ISO 13372:2004, Condition monitoring and diagnostics of machines - Vocabulary
[11] ISO 13373-1:2002, Condition monitoring and diagnostics of machines - Vibration condition monitoring
– Part 1: General procedures
[12] ISO 13379:2003, Condition monitoring and diagnostics of machines –General guidelines on data
interpretation and diagnostics techniques
[13] ISO 13380:2002, Condition monitoring and diagnostics of machines – General guidelines on using
performance parameters
[14] ISO/FDIS 13381-1, Condition monitoring and diagnostics of machines – Prognostics - Part 1: General
guidelines
[15] ISO 17359:2003, Condition monitoring and diagnostics of machines – General guidelines
[16] ISO/FDIS 18436-1, Condition monitoring of machines – Requirements for training and certification of
personnel – Part 1: Requirements for certifying bodies and the certification process
[17] ISO 18436-2:2003, Condition monitoring of machines – Requirements for training and certification of
personnel – Part 2: Vibration condition monitoring and diagnostics

INTERNATIONAL ISO
STANDARD 13374-3
First edition
2012-02-15

of machines — Data processing,
communication and presentation —
Part 3:
Communication
Surveillance et diagnostic d’état des machines — Traitement, échange
(standards.iteh.ai)
Partie 3: Échange
ISO 13374-3:2012
https://standards.iteh.ai/catalog/standards/sist/9b4c0b22-77c0-4727-8e51-
e3b4aa521349/iso-13374-3-2012
Reference number
ISO 13374-3:2012(E)
© ISO 2012
ISO 13374-3:2012(E)

(standards.iteh.ai)
ISO 13374-3:2012
e3b4aa521349/iso-13374-3-2012
COPYRIGHT PROTECTED DOCUMENT

© ISO 2012
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO’s
member body in the country of the requester.
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2012 – All rights reserved

ISO 13374-3:2012(E)
Contents Page
Foreword............................................................................................................................................................................. iv
Introduction......................................................................................................................................................................... v
1 Scope....................................................................................................................................................................... 1
2 Normative references.......................................................................................................................................... 1
3 Terms and definitions.......................................................................................................................................... 1
4 Open CM&D information architecture communication requirements................................................... 1
4.1 Overview................................................................................................................................................................. 1
4.2 Reference data library communication requirements................................................................................ 2
4.3 Communications initiation requirements...................................................................................................... 2
4.4 Message content requirements........................................................................................................................ 2
5 Open CM&D processing architecture communication requirements.................................................... 2
5.1 Overview................................................................................................................................................................. 2
5.2 Diverse technologies and UML representation............................................................................................ 3
5.3 Interface types and general interaction.......................................................................................................... 4
5.4 Specific ISO 13374-2 interface method requirements................................................................................ 7
5.5 Data provider specification support considerations.................................................................................. 8
Annex A (informative) Open CM&D information architecture based on IEC 62264-5[1] ................................ 10
Bibliography...................................................................................................................................................................... 21
(standards.iteh.ai)
ISO 13374-3:2012
e3b4aa521349/iso-13374-3-2012
© ISO 2012 – All rights reserved iii

ISO 13374-3:2012(E)
Foreword
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International
Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
ISO 13374‑3 was prepared by Technical Committee ISO/TC 108, Mechanical vibration, shock and condition
monitoring, Subcommittee SC 5, Condition monitoring and diagnostics of machines.
machines — Data processing, communication and presentation:
— Part 1: General guidelines
— Part 2: Data processing

— Part 3: Communication
(standards.iteh.ai)
The following part is planned: ISO 13374-3:2012
— Part 4: Presentation e3b4aa521349/iso-13374-3-2012
iv © ISO 2012 – All rights reserved

ISO 13374-3:2012(E)
Introduction
The various computer software systems written for condition monitoring and diagnostics (CM&D) of machines
that are currently in use cannot easily exchange data or operate in a plug-and-play fashion without an extensive
communication infrastructure. The lack of an all-purpose communication system makes it difficult to integrate
various CM&D sub-systems and provide a unified view of the condition of machinery to users. The intent
of ISO 13374 is to provide the basic requirements for open CM&D software architecture in order to allow
CM&D information to be processed, communicated and displayed by various software packages independent
of platform-specific or hardware-specific protocols.
ISO 13374‑1 gives a general overview of data processing, communication and presentation. ISO 13374‑2
provides greater details of the data-processing methodology and requirements present in today’s software-
enhanced systems. This part of ISO 13374 provides the requirements of the data communication architecture
for open CM&D systems.

(standards.iteh.ai)
ISO 13374-3:2012
e3b4aa521349/iso-13374-3-2012
© ISO 2012 – All rights reserved v

(standards.iteh.ai)
ISO 13374-3:2012
e3b4aa521349/iso-13374-3-2012

processing, communication and presentation —
Part 3:
Communication
1 Scope
This part of ISO 13374 specifies requirements for data communication for an open condition monitoring and
diagnostics (CM&D) reference information architecture and for a reference processing architecture. Software
design professionals require communications to be defined for exchange of CM&D information between
software systems. This part of ISO 13374 facilitates the interoperability of CM&D systems.
The following documents, in whole or in part, are normatively referenced in this document and are indispensable
for its application. For dated references, only the edition cited applies. For undated references, the latest edition
of the referenced document (including any amendments) applies.
(standards.iteh.ai)
ISO 8601, Data elements and interchange formats — Information interchange — Representation of dates and times
ISO 13372, Condition monitoring and diagnostics of machines — Vocabulary

ISO 13374-3:2012
ISO 13374-1:2003, Condition monitoring and diagnostics of machines — Data processing, communication and
presentation — Part 1: General guidelinese3b4aa521349/iso-13374-3-2012
ISO 13374-2:2007, Condition monitoring and diagnostics of machines — Data processing, communication and
presentation — Part 2: Data processing
ISO/IEC 19501, Information technology — Open Distributed Processing — Unified Modeling Language (UML)
Version 1.4.2
3 Terms and definitions

For the purposes of this document, the terms and definitions given in ISO 13372 apply.
4 Open CM&D information architecture communication requirements
4.1 Overview
An information architecture describes all the data objects and their properties (or attributes), property data
types, data object relationships, reference data, and data documents for a given system or application. As
specified in ISO 13374-2, an open CM&D information architecture describes the content for each of the five
layers shown in Figure 1.
© ISO 2012 – All rights reserved 1

ISO 13374-3:2012(E)
Figure 1 — CM&D Information architecture layers (from ISO 13374-2:2007)
During a communications exchange between applications in an open CM&D information architecture, the
message content shall reference and validate against a defined layer 5 data document definition and comply
with a defined layer 4 reference data library. Communication message implementations vary according to
application requirements. Annex A details options for implementation.
4.2 Reference data library communication requirements

An open CM&D information architecture shall specify the method for communication receivers to access the
defined layer 4 reference data library. The architecture shall also specify the methodology for the publication
of updates from the reference data library owner to predefined subscribers.
(standards.iteh.ai)
4.3 Communications initiation requirements
ISO 13374-3:2012
An open CM&D information https://standards.iteh.ai/catalog/standards/sist/9b4c0b22-77c0-4727-8e51-
architecture shall specify the initiation requirements of the provider application for
each method of communication the architecture includes. All date and time notations in the initiation information
e3b4aa521349/iso-13374-3-2012
should reference back to a specific instant in time using the Gregorian (Common Era or CE) calendar, with a
lexical representation based upon ISO 8601. Communication initiation shall also reference a defined layer 5
data document definition to which the subsequent message content complies.
4.4 Message content requirements

An open CM&D information architecture shall specify the message content requirements of the provider
application for each method of communication the architecture includes. The message content definition shall
reference the appropriate data document definition(s), along with the specific data format rendering of the
document(s), including the compression and encryption utilized.
5 Open CM&D processing architecture communication requirements
5.1 Overview
A processing architecture describes all the interactions or transactions between modules internal to the
software system itself, external to end-user interactions or external to other software system interactions. As
specified in ISO 13374‑1, an open CM&D processing architecture specification shall utilize the processing
architecture shown in Figure 2.
This architecture is defined as blocks of data-processing functionality. After each block in the system has been
properly configured, the basic data are converted into digital form in data acquisition (DA) and are processed
in various ways as they are transformed into actionable information, resulting in advisory generation (AG). As
the processing progresses from DA to AG, data from preceding blocks need to be transferred to subsequent
blocks and additional information acquired from or sent to external systems. Similarly, as the data evolve
into information, both standard technical displays and graphical presentation formats are required. In many
2 © ISO 2012 – All rights reserved

ISO 13374-3:2012(E)
applications, data archiving is required in order to maintain a history of the output of each block. The DA,
DM and SD blocks are responsible for assessing data quality. Output should be identified as good, bad or
undetermined.
This part of ISO 13374 defines the communication requirements for any open CM&D processing architecture.
With such an approach, the data-processing blocks from various suppliers can be integrated into a complete,
functional system.

(standards.iteh.ai)
ISO 13374-3:2012
e3b4aa521349/iso-13374-3-2012
Figure 2 — Data-processing block diagram (from ISO 13374-1:2003)
5.2 Diverse technologies and UML representation
5.2.1 Introduction
There are normally different software and hardware environments as data come from sensors and are analysed
by higher-level CM&D information systems. CM&D systems often start with data acquisition in embedded
environments with real-time constraints. Information is then processed and refined in subsequent system
blocks and made available for health assessment, prognostics, and advisory generation. These requirements
currently lead to disparate technology choices. The technologies and software used by the “analysis-oriented”
processing blocks (HA, PA and AG) are often different from those used in the “data-oriented” processing
blocks (DA, DM and SD).
The amount of data communicated in the data-oriented blocks is vast compared to the small quantity of
information generated by analysis-oriented blocks. The data-oriented blocks are normally designed for high-
speed processing and often with real-time methodologies. For analysis-oriented blocks, results should be

ISO 13374-3:2012(E)
timely, but are not usually required in milliseconds or real time. In addition, technology continues to evolve.
Programming languages, network protocols, and data storage methods change over time.
An ISO/IEC 19501-compliant Unified Modelling Language (UML) model shall be specified to support the
communications of the open CM&D data-processing architecture that holds the base information classes
and interfaces required. As shown in Figure 3, the UML shall then be utilized to directly map into specific
technologies such as XML-based web services or binary embedded system communications.
UML Selection of technology Specific application

technology mapping
Selection of interface
Interface(s) specification Interface(s) specification
Specific data format

Data format specification Data format specification
Figure 3 — UML to specific technology
5.2.2 Standard data content iTeh STANDARD PREVIEW

(standards.iteh.ai)
When the content of the data is standardized, the conversion from one technology form to another becomes a
simple one-to-one mapping effort. Thus, a binary formatted message in an embedded system can be converted
using a generic adapter to an XML format when required.
ISO 13374-3:2012
5.2.3 Relationship to an information management system
e3b4aa521349/iso-13374-3-2012
In the design and management of operations of a CM&D data-processing system, it is important to have an
information management system that is compliant with the open CM&D information architecture specified
in Clause 4. The information management system holds not only the operational information, but also the
metadata that describe the information that flows in a system. This can include the description and source
of sensor signals and the processing performed on those signals. It can also include information about the
agents, whether human or software, that perform analysis assessments.
These metadata enable engineering analysis and allow operational results to be used in higher-level enterprise
application processing for business, logistics, and command and control decision making.
5.3 Interface types and general interaction
5.3.1 Introduction
The diverse set of technologies used in CM&D systems that use information provided by those systems
requires multiple interface types. There are two major types of communication services: provider services and
consumer (also called “DataUser”) services. Provider services collect and process information and provide
results to interested users by some means. Consumer services utilize the provider’s CM&D data to deliver
additional capabilities.
The CM&D processing system shall support the implementation of provider and/or consumer service(s). An
EntryPoint shall provide the interface used for a particular service.

ISO 13374-3:2012(E)
5.3.2 Provider interface
5.3.2.1 Introduction
All the arrows that flow downwards from the blocks defined in Figure 2 indicate data content from a provider
interface. The data output of each block is a provider of information that interested consumers can receive.
There are two major types of provider interfaces: synchronous and asynchronous. Systems may implement
either or both types.
5.3.2.2 Synchronous interface
Providers that support the synchronous interface implement a direct call/return mechanism. A consumer block
makes a call indicating which information it is interested in and the call does not return until the information
requested is available. All of the requested information is then returned. A web service is a typical implementation
of this type of interface. An example implementation is shown in Figure 4.
DataUser : DataUser SynchProvider : EntryPointSynchronous
requestInformation()
prepareInformation
return information

Synchronous provider
(standards.iteh.ai)
Figure 4 — Example implementation of a synchronous information request/response
ISO 13374-3:2012
In addition to processing a data request, e3b4aa521349/iso-13374-3-2012
the provider system shall support the ability for any data-processing
block or external application to request processing modification. Configuration setups and threshold control are
two examples. A synchronous provider shall perform the modification, if possible, and return a status (success or
an error code) based on its ability to process the modification. An example implementation is shown in Figure 5.
DataUser : DataUser SynchProvider : EntryPointSynchronous
notifyInformation()
processInformation
return errorStatus
Synchronous provider
Figure 5 — Example implementation of a synchronous process modification request/response
5.3.2.3 Asynchronous interface
5.3.2.3.1 Introduction
An asynchronous interface implements a “call-but-do-not-wait” mechanism. An asynchronous interface

shall allow a provider to send unsolicited information to consumers once the information about how to send

INTERNATIONAL ISO
STANDARD 13374-4
First edition
2015-12-01

of machine systems — Data
processing, communication and
presentation —
Part 4:
Presentation
Surveillance et diagnostic d’état des machines — Traitement, échange
(standards.iteh.ai)
Partie ISO4: 13374-4:2015
Présentation
https://standards.iteh.ai/catalog/standards/sist/de76b55f-e1cf-41ef-b804-
4b3b5120805b/iso-13374-4-2015
Reference number
ISO 13374-4:2015(E)
© ISO 2015
ISO 13374-4:2015(E)


(standards.iteh.ai)
ISO 13374-4:2015
4b3b5120805b/iso-13374-4-2015
COPYRIGHT PROTECTED DOCUMENT

© ISO 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – All rights reserved

ISO 13374-4:2015(E)

Contents Page
Foreword......................................................................................................................................................................................................................................... iv
Introduction...................................................................................................................................................................................................................................v
1 Scope.................................................................................................................................................................................................................................. 1
2 Normative references....................................................................................................................................................................................... 1
3 Terms and definitions...................................................................................................................................................................................... 1
4 Open CM&D information architecture presentation requirements................................................................ 1
4.1 Overview....................................................................................................................................................................................................... 1
4.2 Basic requirements.............................................................................................................................................................................. 2
4.3 Authentication and authorization requirements....................................................................................................... 2
4.4 Internationalization and localization requirements............................................................................................... 2
4.5 User tracking requirements.......................................................................................................................................................... 2
4.6 User configuration requirements............................................................................................................................................ 2
5 Open CM&D processing architecture presentation requirements.................................................................... 3
5.1 Overview....................................................................................................................................................................................................... 3
5.2 Technical display (TD) module requirements.............................................................................................................. 4
5.3 Information presentation (IP) module requirements............................................................................................ 4
Bibliography................................................................................................................................................................................................................................. 5

(standards.iteh.ai)
ISO 13374-4:2015
4b3b5120805b/iso-13374-4-2015
© ISO 2015 – All rights reserved iii

ISO 13374-4:2015(E)

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
(standards.iteh.ai)
The committee responsible for this document is ISO/TC 108, Mechanical vibration, shock and condition
monitoring, Subcommittee SC 5, Condition monitoring and diagnostics of machine systems.
ISO 13374-4:2015
machine systems — Data processing, communication and presentation:
4b3b5120805b/iso-13374-4-2015
— Part 1: General guidelines
— Part 2: Data processing
— Part 3: Communication
— Part 4: Presentation
iv © ISO 2015 – All rights reserved

ISO 13374-4:2015(E)

Introduction
The various computer software systems written for condition monitoring and diagnostics (CM&D) of
machines that are currently in use cannot easily exchange data or operate in a plug-and-play fashion
without an extensive communication infrastructure. The lack of an all-purpose communication system
makes it difficult to integrate various CM&D sub-systems and provide a unified view of the condition of
machinery to users. The intent of ISO 13374 is to provide the basic requirements for open CM&D software
architecture in order to allow CM&D information to be processed, communicated, and displayed by
various software packages independent of platform-specific or hardware-specific protocols.
ISO 13374-1 gives a general overview of data processing, communication, and presentation. ISO 13374-2
provides greater details into data processing methodology and requirements that should be present in
today’s software-enhanced systems. ISO 13374-3 provides the requirements of the data communication
architecture for open CM&D systems. This part of ISO 13374 provides the requirements for the
presentation of CM&D information for diagnostic analysis and decision support.

(standards.iteh.ai)
ISO 13374-4:2015
4b3b5120805b/iso-13374-4-2015
© ISO 2015 – All rights reserved v

(standards.iteh.ai)
ISO 13374-4:2015
4b3b5120805b/iso-13374-4-2015
Condition monitoring and diagnostics of machine

systems — Data processing, communication and
presentation —
Part 4:
Presentation
1 Scope
This part of ISO 13374 details the requirements for presentation of information for technical analysis
and decision support in an open architecture for condition monitoring and diagnostics. Software
design professionals need to present diagnostic/prognostic data, health information, advisories,
and recommendations on computer displays and in written report formats to end-users. This part of
ISO 13374 provides standards for the display of this information in CM&D systems.
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
(standards.iteh.ai)
references, the latest edition of the referenced document (including any amendments) applies.
ISO 13372, Condition monitoring and diagnostics of machines — Vocabulary
ISO 13374-4:2015
ISO 13374-1, Condition monitoring and diagnostics of machines — Data processing, communication and
4b3b5120805b/iso-13374-4-2015
presentation — Part 1: General guidelines
ISO 13374-2, Condition monitoring and diagnostics of machines — Data processing, communication and
presentation — Part 2: Data processing
3 Terms and definitions

For the purposes of this document, the terms and definitions given in ISO 13372 apply.
4 Open CM&D information architecture presentation requirements
4.1 Overview
An information architecture describes all the data objects and their properties (or attributes), data
types, data object relationships, reference data, and data documents for a given system or application.
As specified in ISO 13374-2, an open CM&D information architecture describes the content for each of
the five layers shown in Figure 1.

ISO 13374-4:2015(E)

Data Document Deinitions Layer 5

Reference Data Library Layer 4
Implementation Data Model Layer 3
Conceptual Information Model Layer 2
Figure 1 — CM&D information architecture layers (from ISO 13374-2:2007)
4.2 Basic requirements

To support the continuous improvement of end-user interfaces, including graphical user interfaces
(GUIs), displays, and reports, an open CM&D information architecture shall separate presentation and
display functionality from the information content and logic. Presentation interface functionality is
often described using templates which specify the method of formatting end-user displays and reports
and allow customization. The presentation interfaces in an open CM&D information architecture shall
communicate with a layer 5 data document definition and comply with a defined layer 4 reference data
library. Implementations will vary according to application requirements.
4.3 Authentication and authorization requirements
(standards.iteh.ai)
In computing, authentication is the mechanism by which a software system may securely identify
who is using the system. Authorization, by contrast, is the mechanism by which a system determines
ISO 13374-4:2015
what level of access and functionality a particular authenticated user should have to secure resources
controlled by the system. An open CM&D4b3b5120805b/iso-13374-4-2015
information architecture shall support user authentication
and should support user authorization. The architecture shall also specify the supported methods
utilized for authentication and authorization, if authorization is supported.
4.4 Internationalization and localization requirements

In computing, internationalization and localization are the mechanisms by which a software system
can readily adapt to different languages, time zones, regional differences, and technical requirements
of an end-user population. Internationalization is the process of designing a software application so
that it can be adapted to various languages and regions without engineering changes. Localization is
the process of adapting internationalized software for a specific region or language by adding locale-
specific components and translating text. An open CM&D information architecture shall specify the
supported methods for end-user internationalization and localization.
4.5 User tracking requirements

The tracking of user interactions with a software system is often necessary to meet regulatory
requirements. An open CM&D information architecture should specify the supported user tracking
methodology and the methods of reporting on this information.
4.6 User configuration requirements

Software systems often permit users to configure a system to meet their specific needs. This
configuration information should then be captured and utilized during each subsequent user session.
An open CM&D information architecture should specify the supported user configuration options.

ISO 13374-4:2015(E)

5 Open CM&D processing architecture presentation requirements
5.1 Overview
A processing architecture describes the interactions or transactions between modules internal to the
software system itself, external from end-user interactions, or external from other software system
interactions. As specified in ISO 13374-1, an open CM&D processing architecture specification shall
utilize the processing architecture shown in Figure 2.
Sensor / Transducer / Manual Entry
Data Acquisition (DA)
Data Manipulation (DM)

External
(standards.iteh.ai)
State Detection (SD)
Systems, Technical
Data ISO 13374-4:2015 Displays &
Archiving & Information
Block 4b3b5120805b/iso-13374-4-2015 Presentation
Coniguration
Health Assessment (HA)
Prognostic Assessment (PA)
Figure 2 — Data processing block diagram (from ISO 13374-1:2003)
This architecture is defined as blocks of data processing functionality. After each block in the system
has been properly configured, the basic data are converted into digital form in data acquisition (DA)
and are processed in various ways as they are transformed into actionable information, resulting in
advisory generation (AG). As the processing progresses from DA to AG, data from preceding blocks
need to be transferred to subsequent blocks and additional information acquired from or sent to
external systems. Similarly, as the data evolve into information, both standard technical displays and
graphical presentation formats are required. This part of ISO 13374 defines the technical displays (TD)

Iso 13374

Uploaded by

Copyright:

Available Formats

You might also like

Iso 13374

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Iso 13374

Uploaded by

Copyright:

Available Formats

INTERNATIONAL ISO

Condition monitoring and diagnostics

iTeh STANDARD PREVIEW

iTeh STANDARD PREVIEW

ii © ISO 2003 — All rights reserved

© ISO 2003 — All rights reserved iii

 Part 4: Presentation requirements

iv © ISO 2003 — All rights reserved

iTeh STANDARD PREVIEW

© ISO 2003 — All rights reserved v

Condition monitoring and diagnostics of machines — Data

2 Data processing iTeh STANDARD PREVIEW

2.2 Data-processing blocks

2.2.1 Machine condition assessment processing blocks

 shaft displacement monitoring;

 bearing vibration monitoring;

© ISO 2003 — All rights reserved 1

 infrared thermographic monitoring;

 motor current monitoring.

iTeh STANDARD PREVIEW

Figure 1 — Data-processing and information-flow blocks

2 © ISO 2003 — All rights reserved

2.2.2 Technical displays (standards.iteh.ai)

2.2.3 Information presentation

2.2.4 External systems

© ISO 2003 — All rights reserved 3

2.2.5 Data archiving

2.2.6 Block configuration

2.3 Conceptual information schema guidelines

 various “room names” (or tables) where data will be stored;

 the data “contents” (or columns) in the rooms;

 whether or not a data column can be empty or not (not null);

4 © ISO 2003 — All rights reserved

2.3.2 Information schema requirements

iTeh STANDARD PREVIEW

© ISO 2003 — All rights reserved 5

ISO/TC 108/SC 5 Circulated to P- and O-members, and to technical committees

(P-members vote only: ballot form attached)

Reference language version: English French Russian

© ISO 2004 – All rights reserved

ISO TC 108/SC 5 N 248

ISO TC 108/SC 5/WG 6

Condition monitoring and diagnostics of machines — Data processing,

Document type: International Standard

G:\WPFILES\TC108\SC5\13374-2\CD 13374-2\ISO_CD_13374-2_(E)[kb].doc STD Version 2.1

Violators may be prosecuted.

ii © ISO 2004 — All rights reserved

© ISO 2004 — All rights reserved iii

 Part 1: General guidelines

 Part 2: Data processing

iv © ISO 2004 — All rights reserved

Condition monitoring and diagnostics of machines — Data

3 CM&D information architecture requirements

© ISO 2004 — All rights reserved 1

Data Document Definitions Layer 5

Reference Data Library Layer 4

Implementation Data Model Layer 3

Conceptual Information Model Layer 2