ISO 13374-3:2012

Condition monitoring and diagnostics of machines — Data processing, communication and presentation — Part 3: Communication

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.

Surveillance et diagnostic d'état des machines — Traitement, échange et présentation des données — Partie 3: Échange

General Information

• Status: Published
• Publication Date: 12-Feb-2012
• ICS: 17.160 - Vibrations, shock and vibration measurements
• ICS: 35.240.99 - IT applications in other fields
• Technical Committee: ISO/TC 108/SC 5 - Condition monitoring and diagnostics of machine systems
• Drafting Committee: ISO/TC 108/SC 5 - Condition monitoring and diagnostics of machine systems
• Current Stage: 9093 - International Standard confirmed
• Start Date: 12-Oct-2023
• Completion Date: 13-Dec-2025

Relations

• Consolidated By: ISO 374-1:2016 - Protective gloves against dangerous chemicals and micro-organisms — Part 1: Terminology and performance requirements for chemical risks
• Effective Date: 06-Jun-2022

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 13374-3
First edition
2012-02-15
Condition monitoring and diagnostics
of machines — Data processing,
communication and presentation —
Part 3:
Communication
Surveillance et diagnostic d’état des machines — Traitement, échange
et présentation des données —
Partie 3: Échange
Reference number
©
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.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2012 – All rights reserved

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
[1]
Annex A (informative) Open CM&D information architecture based on IEC 62264-5 .10
Bibliography .21
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-3 was prepared by Technical Committee ISO/TC 108, Mechanical vibration, shock and condition
monitoring, 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:
— Part 1: General guidelines
— Part 2: Data processing
— Part 3: Communication
The following part is planned:
— Part 4: Presentation
iv © ISO 2012 – All rights reserved

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.
INTERNATIONAL STANDARD ISO 13374-3:2012(E)
Condition monitoring and diagnostics of machines — Data
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.
2 Normative references
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.
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-1:2003, Condition monitoring and diagnostics of machines — Data processing, communication and
presentation — Part 1: General guidelines
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.
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.
4.3 Communications initiation requirements
An open CM&D information 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
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

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.
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
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.
Specific application
Selection of technology
UML
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
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.
5.2.3 Relationship to an information management system
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.
4 © ISO 2012 – All rights reserved

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
Figure 4 — Example implementation of a synchronous information request/response
In addition to processing a data request, 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
information to the consumer has been setup for the provider. Connections or data channels are established
and the requested information may then be sent continually without request as it becomes available.
5.3.2.3.2 Type 1 asynchronous interface
A type 1 asynchronous interface specifies to the provider the content and the method to return information
to the consumer as it becomes available. This return interface is termed a sink. Information is sent from the
provider to the consumer via the sink interface. The provider retains information on how to send information via
the consumer’s sink interface. This type of interface functions as a publish-subscribe type service.
The provider’s type 1 asynchronous interface shall implement a “notify connection” method that allows
consumers to specify how to return information via its sink implementation. It shall also implement a remove
connection interface, which allows the user to remove its reference from the provider. The consumer implements
a sink interface that allows the provider to indicate when the connection information has been received and
when the connection information has been removed. An example implementation is shown in Figure 6.
UserSink : EntryPointSinkAsynchronous Provider : EntryPointAsynchronous
requestConnection()
notifyConnection()
notifyInformation()
notifyInformation()
notifyInformation()
removeConnection()
connectionRemoved()
Asynchronous provider
Figure 6 — Example implementation of an asynchronous information request/response
The consumer shall be allowed to indicate the requested subset of information to be returned to its sink. The
consumer shall implement a sink interface for the receipt of all types of data that the consumer has subscribed to
and that a provider may send. The sink shall allow for unsolicited communication of information from the provider.
This interface allows for a number of modes of communication. There shall be the capability for a “send-
all-data“, “send-only-on-threshold-data”, and “send-only-on-request”. A user provides the information to the
provider about which mode is preferred. The provider has the option of sending more than requested to the
consumer, but not less than requested.
5.3.2.3.3 Type 2 asynchronous interface
Embedded systems often have special communication requirements. Some systems require non-blocking
one-way transfers of data. These systems may also have configuration constraints that do not allow the system
to push data updates to many asynchronous users.
For systems with these types of constraints, the connection to consumers via a sink “channel” shall be
established in an initialization process. Consumers shall receive data in an asynchronous manner from the
provider as it becomes available. The only requirement for this type of system is the capability to send data as
soon as possible in the standard format to predefined consumers. Users are required to implement the sink
interface that can receive all types of information that a provider can send.
6 © ISO 2012 – All rights reserved

5.3.3 Consumer services
A consumer service, such as a data historian/archiver, preventive maintenance scheduling system or operations
command advisory system may opt to be a user of CM&D results. The consumer service shall provide an
interface that allows a data provider to send it unsolicited information. The consumer service responds with an
indication of whether the information was successfully received and processed or if there were any errors. Errors
could include transmission problems as well as data content processing errors. An example implementation is
shown in Figure 7.
DataConsumer : ConsumerDataService
DataGenerator : DataGenerator
notifyInformation()
processInformation
errorStatus()
Consumer DataService
Figure 7 — Example implementation of consumer service
5.4 Specific ISO 13374-2 interface method requirements
5.4.1 Connection methods
The asynchronous interface type 1 shall implement a method to establish and remove connection information.
The associated asynchronous sink interface shall implement a method to indicate when the connection has
been established and when it has been removed.
5.4.2 Data event methods
Each block in the ISO 13374-2 data-processing architecture provides for data output. Every interface type shall
establish a method for the communication of such data output events. The synchronous and asynchronous
interface type 1 shall provide a method for requesting output data. The asynchronous interface sink type 1
shall provide a method for receiving data events. The asynchronous interface provider type 1 shall implement
a method for the transmission of data events.
5.4.3 Configuration methods
Each block in the ISO 13374-2 data-processing architecture provides for the input and output of configuration
information. The synchronous and asynchronous type 1 interfaces shall implement a method for input and output
of configuration information. The provider shall determine to what extent actual configuration content shall be
supported in accordance with application needs. If it is not supported, this shall be indicated to consumers.
5.4.4 Control methods
Control information is the ability to modify a process block. This can be in the form of expected operational
parameters or preferred thresholds for alarms. The synchronous and asynchronous type 1 interfaces shall
implement a method for returning control parameter setups. They shall also implement a method for changing
control parameters. The provider shall determine to what extent control information is supported in accordance
with application needs. If it is not supported, this shall be indicated to consumers.
5.4.5 Explanation methods
Explanation information is information that was used to develop a process block result output. It is an optional
capability. If supported, the synchronous and asynchronous type 1 interfaces shall implement a method for
returning explanation information. The provider shall determine to what extent explanation information is
supported in accordance with application needs. If it is not supported, this shall be indicated to consumers.
5.4.6 App
...