ISO 13374-2:2007
(Main)Condition monitoring and diagnostics of machines — Data processing, communication and presentation — Part 2: Data processing
Condition monitoring and diagnostics of machines — Data processing, communication and presentation — Part 2: Data processing
ISO 13374-2:2007 details the requirements for a reference information model and a reference processing model to which an open condition monitoring and diagnostics (CM&D) architecture needs to conform. Software design professionals require both an information model and a processing model to adequately describe all data processing requirements. ISO 13374-2:2007 facilitates the interoperability of CM&D systems.
Surveillance et diagnostic d'état des machines — Traitement, échange et présentation des données — Partie 2: Traitement des données
L'ISO 13374-2 :2007 décrit de manière détaillée les exigences relatives à un modèle d'information de référence et à un modèle de traitement de référence auxquelles une architecture ouverte de surveillance et diagnostic de l'état des machines (Condition Monitoring and Diagnostic, CM&D) doit se conformer. Les professionnels de la conception logicielle ont à la fois besoin d'un modèle d'information et d'un modèle de traitement pour décrire de manière appropriée toutes les exigences relatives au traitement des données. L'ISO 13374-2 :2007 facilite l'interopérabilité des systèmes CM&D.
General Information
Buy Standard
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 13374-2
First edition
2007-07-15
Corrected version
2008-01-15
Condition monitoring and diagnostics of
machines — Data processing,
communication and presentation —
Part 2:
Data processing
Surveillance et diagnostic d'état des machines — Traitement, échange
et présentation des données —
Partie 2: Traitement des données
Reference number
ISO 13374-2:2007(E)
©
ISO 2007
---------------------- Page: 1 ----------------------
ISO 13374-2:2007(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.
COPYRIGHT PROTECTED DOCUMENT
© ISO 2007
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 2007 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 13374-2:2007(E)
Contents Page
Foreword. iv
Introduction . v
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. 3
3.7 Compliant specifications . 4
4 CM&D processing architecture requirements . 4
4.1 Overview . 4
4.2 Data Acquisition (DA) blocks . 5
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 . 17
Annex B (informative) References to UML, XML and Middleware. 22
Bibliography . 32
© ISO 2007 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO 13374-2:2007(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-2 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
The following part is envisaged:
⎯ Part 3: Communication requirements
This corrected version includes amendments to:
⎯ Figure A.1 [deletion of "(see …)" references in the last four lines of the tabulated matter; deletion of
"AGENT …" from the "Technology types" list];
"[30], [31] " [29], [30]
⎯ p. 25 (B.2.3, first line, deletion of ", insertion of (see Reference ");
⎯ p. 29 (B.4.2, first line, deletion of "[21]", insertion of "[23]");
⎯ throughout this part of ISO 1337, the format “see Reference [x ]” has been adopted to cite references to
publications other than standards.
iv © ISO 2007 – All rights reserved
---------------------- Page: 4 ----------------------
ISO 13374-2:2007(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 integration effort. This makes it difficult to integrate systems and provide a unified view of the
condition of machinery to users. The intent of Parts 1 to 3 of ISO 13374 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.
© ISO 2007 – All rights reserved v
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO 13374-2:2007(E)
Condition monitoring and diagnostics of machines — Data
processing, communication and presentation —
Part 2:
Data processing
1 Scope
This part of ISO 13374 details the requirements for a reference information model and a reference processing
model to which an open condition monitoring and diagnostics (CM&D) architecture needs to conform.
Software design professionals require both an information model and a processing model to adequately
describe all data processing requirements. This part of ISO 13374 facilitates the interoperability of CM&D
systems.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 13374-1:2003, Condition monitoring and diagnostics of machines — Data processing, communication
and presentation — Part 1: General guidelines
ISO/IEC 14750:1999, Information technology — Open Distributed Processing — Interface Definition
Language
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 2007 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO 13374-2:2007(E)
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 are 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 is now an International Standard, ISO/IEC 19501. UML includes a standardized class diagram
representation for information modelling (see Annex B for additional information about UML).
3.4 Implementation data model requirements
Based on the conceptual information model, an implementation data model provides the exact representation
of data elements that shall be transferred or stored. An open CM&D information architecture specification shall
provide an open implementation data model that 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 look-up 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 a unique asset-specific identifier to allow individual
component monitoring and tracking in a parts hierarchy.
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,
2 © ISO 2007 – All rights reserved
---------------------- Page: 7 ----------------------
ISO 13374-2:2007(E)
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 (see Reference [1]) referenced to universal
coordinated time (UTC) and that 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), using ISO 8879, 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
10 February 1998. On 3 May 2001, the W3C issued an 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
the utility of XML 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 schemas are XML documents themselves, they may be managed by XML authoring tools
(see Annex B for additional information about XML).
Regardless of which information schema format is chosen, the implementation data model shall define a
minimum set of data elements that should be included in the schema for conformance. In addition, a list of
optional elements may 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.
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.
© ISO 2007 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO 13374-2:2007(E)
Specifications which utilize the file description schema format as their implementation data model will probably
utilize the same specification for the publication of an ASCII or binary data document. The complete record
format description shall be published, specifying 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 probably utilize
the same format for the publication of an XML data document. An 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
An open CM&D information architecture specification shall utilize the information architecture as described in
subclauses 3.1 to 3.6. MIMOSA, a non-profit association, publishes an open CM&D information 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. Annex 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 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 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 does not address the impact of errors and their propagation within and across the
various CM&D processing blocks. Sources of such errors include instrumentation calibration, environmental
noise, signal conditioning and processing, computational rounding, human-induced inputs, and their combined
effects.
4 © ISO 2007 – All rights reserved
---------------------- Page: 9 ----------------------
ISO 13374-2:2007(E)
Figure 2 — Data processing block diagram
4.2 Data Acquisition (DA) blocks
As detailed in Figure 3, the DA block has been generalized to represent the software module that provides
system access to digitized data entered automatically or manually. The DA 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. Alternatively, it might represent the software interface to a smart
sensor. The DA module is basically a server of calibrated digitized sensor data records.
© ISO 2007 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO 13374-2:2007(E)
Figure 3 — Data Acquisition block
The output of all DA blocks shall contain the following:
⎯ digitized data;
⎯ time-order/time-reference data, normally referenced with UTC and local time zone;
⎯ data quality indicator (e.g. “bad”, “good”, “unknown”, “under review”, etc.).
Examples of digitized data include:
⎯ floating point values for scalar data;
⎯ magnitude and time series for dynamic data;
⎯ thermal radiation data with digitized image for thermographic data;
⎯ sample test results for lubricating fluid/air/water sample data.
6 © ISO 2007 – All rights reserved
---------------------- Page: 11 ----------------------
ISO 13374-2:2007(E)
4.3 Data Manipulation (DM) blocks
As detailed in Figure 4, the DM 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.
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 and outlet pressures);
⎯ integrating acceleration to velocity/double integration to displacement;
⎯ filtering;
⎯ normalization;
⎯ time series including sample rate.
© ISO 2007 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO 13374-2:2007(E)
4.4 State Detection (SD) blocks
As shown in Figure 5, the primary function of the SD block (sometimes referred to as “state awareness”) is to
compare DM and/or DA outputs against expected baseline profile values or operational limits, in order to
generate enumerated state indicators with respective boundary exceedances. The SD block generates
indicators which may be utilized by the Health Assessment block to generate alerts and alarms. When
appropriate data are available, the SD block should generate assessments based on operational context,
sensitive to the current operational state or operational environment.
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 outputs 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;
8 © ISO 2007 – All rights reserved
---------------------- Page: 13 ----------------------
ISO 13374-2:2007(E)
⎯ degree of abnormality;
⎯ statistical analysis using parametric and non-parametric approaches, e.g. Weibull and Gaussian
distribution.
4.5 Health Assessment (HA) blocks
As shown in Figure 6, the HA block is an information block which utilizes expertise from a human or
automated agent to determine the current health of the equipment and to 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.
Figure 6 — Health Assessment block
An output of this block includes the component/system's current health grade and diagnosed faults and
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 2007 – All rights reserved 9
---------------------- Page: 14 ----------------------
ISO 13374-2:2007(E)
4.6 Prognostic Assessment (PA) blocks
As shown in Figure 7, the primary function of the PA block is to project the future state of the monitored
equipment using a combination of prognostic models and their algorithms, including future operational usage
model(s). This block determines the future state of health and failure modes by combining the relevant outputs
of the DA, DM, SD, HA and other PA 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.
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 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.
Figure 7 — Prognostic Assessment block
10 © ISO 2007 – All rights reserved
---------------------- Page: 15 ----------------------
ISO 13374-2:2007(E)
4.7 Advisory Generation (AG) blocks
As detailed in Figure 8, the primary function of the AG block is to integrate information from DA, DM, SD, HA,
PA and other AG blocks and external constraints (safety, environmental, budgetary, etc.), and to provide
optimized recommended actions and alternatives to applicable personnel or external systems.
Recommendations may include prioritized 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 the operational history (including usage and maintenance), current and future
mission profiles, high-level unit objectives and resource constraints.
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 exter
...
NORME ISO
INTERNATIONALE 13374-2
Première édition
2007-07-15
Version corrigée
2008-01-15
Surveillance et diagnostic d'état des
machines — Traitement, échange et
présentation des données —
Partie 2:
Traitement des données
Condition monitoring and diagnostics of machines — Data processing,
communication and presentation —
Part 2: Data processing
Numéro de référence
ISO 13374-2:2007(F)
©
ISO 2007
---------------------- Page: 1 ----------------------
ISO 13374-2:2007(F)
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier
peut être imprimé ou visualisé, mais ne doit pas être modifié à moins que l'ordinateur employé à cet effet ne bénéficie d'une licence
autorisant l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées
acceptent de fait la responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute
responsabilité en la matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la création du présent fichier PDF sont disponibles dans la rubrique General Info
du fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir
l'exploitation de ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation,
veuillez en informer le Secrétariat central à l'adresse donnée ci-dessous.
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2007
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous
quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit
de l'ISO à l'adresse ci-après ou du comité membre de l'ISO dans le pays du demandeur.
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
Publié en Suisse
ii © ISO 2007 – Tous droits réservés
---------------------- Page: 2 ----------------------
ISO 13374-2:2007(F)
Sommaire Page
Avant-propos. iv
Introduction . v
1 Domaine d'application. 1
2 Références normatives . 1
3 Exigences relatives à l'architecture d'information CM&D. 1
3.1 Vue d'ensemble. 1
3.2 Exigences relatives à la définition sémantique . 2
3.3 Exigences relatives au modèle informatif conceptuel. 2
3.4 Exigences relatives au modèle de données de mise en œuvre. 2
3.5 Exigences relatives à la bibliothèque de données de référence . 3
3.6 Exigences relatives à la définition du document de données . 4
3.7 Spécifications conformes . 4
4 Exigences relatives à l'architecture de traitement CM&D . 4
4.1 Vue d'ensemble. 4
4.2 Blocs d'acquisition des données (Data Acquisition, DA) . 5
4.3 Blocs de manipulation des données (Data Manipulation, DM) . 7
4.4 Blocs de détection d'un état (State Detection, SD). 8
4.5 Blocs d'évaluation de l'état (Health Assesment, HA). 9
4.6 Blocs d'évaluation du pronostic (Prognostic Assesment, PA) . 10
4.7 Blocs de formulation de conseils (Advisory Generation, AG). 11
4.8 Configuration des blocs. 12
4.9 Systèmes externes . 13
4.10 Archivage des données . 13
4.11 Affichages techniques. 13
4.12 Présentation des informations . 13
4.13 Spécifications conformes . 13
Annexe A (informative) Spécifications conformes . 17
Annexe B (informative) Références relatives à l'UML, au XML et aux services intergiciels . 23
Bibliographie . 34
© ISO 2007 – Tous droits réservés iii
---------------------- Page: 3 ----------------------
ISO 13374-2:2007(F)
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiée
aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire partie du
comité technique créé à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec
la Commission électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI,
Partie 2.
La tâche principale des comités techniques est d'élaborer les Normes internationales. Les projets de Normes
internationales adoptés par les comités techniques sont soumis aux comités membres pour vote. Leur
publication comme Normes internationales requiert l'approbation de 75 % au moins des comités membres
votants.
L'attention est appelée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable de ne
pas avoir identifié de tels droits de propriété et averti de leur existence.
L'ISO 13374-2 a été élaborée par le comité technique ISO/TC 108, Vibrations et chocs mécaniques, et leur
surveillance, sous-comité SC 5, Surveillance et diagnostic des machines.
L'ISO 13374 comprend les parties suivantes, présentées sous le titre général Surveillance et diagnostic d'état
des machines — Traitement, échange et présentation des données:
⎯ Partie 1: Lignes directrices générales
⎯ Partie 2: Traitement des données
La partie suivante est prévue:
⎯ Partie 3: Exigences relatives à l’échange des données
La présente version corrigée comprend les modifications suivantes:
⎯ Figure A.1: supression des références croisées dans les quatre dernières lignes du tableau et supression
de l’élément «AGENT» de la liste «Types de technologies [Tech]»;
⎯ B.2.3, premier tiret: les Références [30] et [31] ont été remplacées par les Références [29] et [30];
⎯ B.4.2, premier alinéa: la Référence [21] a été remplacée par la Référence [23];
⎯ dans tout le document, la manière de citer les Références bibliographiques a été harmonisée selon la
formule «(voir Référence [xx])».
iv © ISO 2007 – Tous droits réservés
---------------------- Page: 4 ----------------------
ISO 13374-2:2007(F)
Introduction
Les divers systèmes logiciels élaborés pour la surveillance et les diagnostics sur l'état des machines (CM&D)
et actuellement utilisés ne peuvent pas facilement échanger des données ou être prêts à l'emploi sans un
large effort d'intégration. Il est donc difficile d'intégrer des systèmes et de fournir aux utilisateurs une vision
uniforme de l'état des machines. Les Parties 1 à 3 de l'ISO 13374 ont pour but d'établir des exigences de
base pour les architectures de logiciels ouvertes CM&D qui permettront de traiter, d'échanger et d'afficher les
informations CM&D à l'aide de divers progiciels, sans protocoles propres à une plate-forme ou à un matériel.
© ISO 2007 – Tous droits réservés v
---------------------- Page: 5 ----------------------
NORME INTERNATIONALE ISO 13374-2:2007(F)
Surveillance et diagnostic d'état des machines — Traitement,
échange et présentation des données —
Partie 2:
Traitement des données
1 Domaine d'application
La présente partie de l'ISO 13374 décrit de manière détaillée les exigences relatives à un modèle
d'information de référence et à un modèle de traitement de référence auxquelles une architecture ouverte de
surveillance et de diagnostic de l'état des machines (Condition Monitoring and Diagnostic, CM&D) doit se
conformer. Les professionnels de la conception logicielle ont à la fois besoin d'un modèle d'information et d'un
modèle de traitement pour décrire de manière appropriée toutes les exigences relatives au traitement des
données. La présente partie de l'ISO 13374 facilite l'interopérabilité des systèmes CM&D.
2 Références normatives
Les documents de référence suivants sont indispensables pour l'application du présent document. Pour les
références datées, seule l'édition citée s'applique. Pour les références non datées, la dernière édition du
document de référence s'applique (y compris les éventuels amendements).
ISO 13374-1:2003, Surveillance et diagnostic d'état des machines — Traitement, échange et présentation des
données — Partie 1: Lignes directrices générales
ISO/CEI 14750:1999, Technologies de l'information — Traitement réparti ouvert — Langage de définition
d'interface
3 Exigences relatives à l'architecture d'information CM&D
3.1 Vue d'ensemble
Une architecture d'information décrit tous les objets de données et leurs propriétés (ou attributs), les types de
données de propriété, les relations données/objet, les données de référence et les documents de données
pour un système ou une application donné(e). Une spécification d'architecture d'information CM&D ouverte
doit décrire le contenu de chacune des cinq couches illustrées à la Figure 1.
© ISO 2007 – Tous droits réservés 1
---------------------- Page: 6 ----------------------
ISO 13374-2:2007(F)
Figure 1 — Couches de l'architecture d'information CM&D
3.2 Exigences relatives à la définition sémantique
Pour faciliter la compréhension des différentes parties utilisant l'architecture d'information, une spécification
d'architecture d'information CM&D ouverte doit fournir un ensemble de définitions sémantiques pour chaque
objet de données important dans le système. Il est possible d'utiliser une terminologie descriptive non formelle,
telle que des définitions en anglais des objets de données. Il est également possible d'avoir recours à des
descriptions formelles utilisant des schémas ontologiques, tels que le format de description de la ressource
(Resource Description Format, RDF) du World Wide Web Consortium (W3C).
3.3 Exigences relatives au modèle informatif conceptuel
Un modèle informatif conceptuel est une définition intégrée de tous les objets de données primaires relatifs à
CM&D, ainsi que de toutes leurs principales propriétés (également appelées «attributs»), des types de
données de propriété, des rapports entre les objets et des contraintes liées à l'objet ou aux relations. Une
spécification d'architecture d'information CM&D ouverte doit fournir un modèle informatif conceptuel non
propriétaire, parfois qualifié de «schéma», qui est indépendant du mode de stockage ou d'accès physique aux
données. Le schéma informatif conceptuel constitue un plan détaillé de l'emplacement des divers éléments de
données qui facilite l'intégration du système et l'intégrité des données. Il est possible de vérifier un modèle de
données de mise en œuvre à l'aide d'un schéma conceptuel.
Le langage de modélisation unifié (Unified Modelling Language, UML) s'est imposé comme principal langage
de modélisation dans l'industrie des logiciels et est maintenant une Norme internationale, l'ISO/IEC 19501.
L'UML comprend une représentation normalisée en diagramme de classes pour la modélisation de
l'information (voir Annexe B pour plus d'informations sur l'UML).
3.4 Exigences relatives au modèle de données de mise en œuvre
À partir du modèle informatif conceptuel, un modèle de données de mise en œuvre fournit la représentation
exacte des éléments de données qui doivent être transférés ou stockés. Une spécification d'architecture
d'information CM&D ouverte doit fournir un modèle de données de mise en œuvre ouvert conforme à son
modèle de données conceptuel.
Le modèle de données de mise en œuvre CM&D ouvert doit permettre l'intégration de nombreuses sources
d'informations relatives à la machine, prendre en charge les bases de données d'égal à égal (homologues),
permettre de consulter les entrées définies par l'utilisateur et utiliser des horodateurs standards et des unités
techniques. Il convient que le schéma prenne en charge des identificateurs uniques d'entreprise, de site et de
base de données ou des identificateurs de sources de données afin de différencier les données provenant
d'emplacements physiques différents. Il convient que le schéma prenne également en charge des
identificateurs uniques à l'échelle du réseau pour les sections d'installation comprenant des machines
(emplacements de section de service) au sein d'une hiérarchie parent-enfant. Il convient que le schéma
prenne également en charge un identificateur unique spécifique des biens, permettant la surveillance et le
suivi d'un composant individuel au sein d'une hiérarchie par pièces.
2 © ISO 2007 – Tous droits réservés
---------------------- Page: 7 ----------------------
ISO 13374-2:2007(F)
Il convient que le schéma spécifie le cadre de base de l'entreprise de stockage, du site, des bases de
données des sites, des informations relatives aux éléments du procédé ou de la machine (telles que
l'orientation physique, le type d'entraînement, le type de montage et le type d'accouplement d'arbres), des
données des plaques signalétiques des biens (y compris des données telles que la vitesse nominale, la
puissance nominale, la fabrication et le modèle, le palier ou des informations sur d'autres éléments), des
emplacements des mesures, des sources des mesures de données, des transducteurs, de l'orientation des
transducteurs, des unités techniques, des types de traitement des signaux après mise à l'échelle, des listes
numérotées et des alarmes. Concernant les données, il convient que le schéma prenne en charge des
formats pour l'échange de données numériques historiques monovaluées, des données spectrales de la
transformation de Fourier rapide, des spectres de bande passante relative constante, des signaux temporels,
des données d'essai échantillonnées, des images thermographiques et des objets binaires importants. Il
convient que le schéma prenne en charge une notation date/heure qui renvoie à une instance spécifique dans
le temps, utilisant le calendrier grégorien (ère chrétienne) avec une représentation lexicale fondée sur
l'ISO 8601 (voir Référence [1]) rapportée au temps universel coordonné (UTC) et qu'il mémorise également le
décalage par rapport au fuseau horaire local.
La présente spécification peut être spécifiée au moyen de différentes définitions de schéma. Le format du
schéma de description de fichier est utilisé depuis des années dans le domaine de la programmation
scientifique. Il présente le format des fichiers de données ASCII ou binaires qui peuvent être exportés vers un
système informatique ou importés d'un système informatique. Une description de la structure d'enregistrement
complète est publiée et spécifie les champs de données contenus dans le fichier, leur emplacement exact par
rapport aux autres champs de données, qu'ils soient de format ASCII ou binaire, et le format de données
exact — virgule flottante réelle, nombre entier, caractère, chaîne de caractères variables — de chaque champ.
Le format du schéma informatif relationnel représente le langage de définition des systèmes de gestion de
bases de données relationnelles. Le modèle relationnel est identique à un plan détaillé qui définit les divers
«noms de site» (ou tables) où les données seront stockées, le «contenu» des données (ou colonnes) dans les
sites, le format de données exact de chaque colonne de données (virgule flottante scientifique, nombre entier,
chaîne de caractères variables, etc.), la possibilité qu'une colonne de données soit vide ou non (non nulle), et
la «clé» unique de chaque rangée de données (clé primaire) qui l'identifie de façon unique. Une table peut
être associée à une autre table en ajoutant une «référence» (clé étrangère).
La définition de schéma XML (XSD) (Extensive Markup Language Schema Definition) est un langage de
définition recommandé. XML est un projet du World Wide Web Consortium (W3C), dont le groupe de travail
XML supervise l'élaboration de la spécification. Le langage de balisage extensible (XML) est un format public
écrit en langage normalisé de balisage généralisé (SGML), l'ISO 8879 définissant la description des
structures des différents types de documents électroniques. Le W3C a accepté la spécification, version 1.0,
sous forme de recommandation le 10 février 1998. Le 3 mai 2001, le W3C a publié un schéma XML sous
forme de recommandation W3C. Les schémas XML définissent des vocabulaires de balisage partagé et la
structure des documents XML qui utilisent ces vocabulaires. Ils fournissent également des points d'accueil
pour y associer la sémantique. En mettant les types de données en XML, les schémas XML augmentent la
fonctionnalité de XML pour les développeurs de systèmes d'échange de données. Les schémas XML
permettent à l'auteur de déterminer quelles parties d'un document peuvent être validées ou d'identifier les
parties d'un document dans lesquelles un schéma peut s'appliquer. En outre, comme les schémas XML sont
eux-mêmes des documents XML, ils peuvent être gérés par des systèmes auteurs XML (voir Annexe B pour
de plus amples informations sur XML).
Indépendamment du format de schéma informatif choisi, le modèle de données de mise en œuvre doit définir
un ensemble minimal d'éléments de données qu'il convient d'inclure pour assurer la conformité dans le
schéma. Une liste d'éléments optionnels peut également être comprise.
3.5 Exigences relatives à la bibliothèque de données de référence
Pour utiliser efficacement un modèle de données de mise en œuvre, des entrées standards pour différentes
consultations doivent être stockées dans une bibliothèque de données de référence. Une spécification
d'architecture d'information CM&D ouverte doit prévoir une bibliothèque de données de référence ouverte
conforme à son modèle de données de mise en œuvre. Il convient que la spécification prenne en charge les
taxonomies de norme de l'industrie relatives à la fourniture et à l'entretien ainsi que les codes pour les
données de référence. En outre, il convient qu'elle permette aux fournisseurs et aux utilisateurs finals
© ISO 2007 – Tous droits réservés 3
---------------------- Page: 8 ----------------------
ISO 13374-2:2007(F)
d'ajouter des entrées spécifiques à l'industrie et au client dans la bibliothèque en utilisant des entrées uniques
de base de données. La spécification doit également prendre en charge la création d'un ensemble standard
de codes de référence dans diverses langues si nécessaire.
La bibliothèque de données de référence spécifie toutes les tables de codes pour les codes de type de
section (machine/composant), les codes de type de biens, les codes de type d'emplacement de mesure, les
codes de type d'unité technique, les codes d'essai sur prélèvement, les codes d'événement de
diagnostic/pronostic, les codes d'état, les codes de défaillance et les codes de causes profondes. La
bibliothèque comprend également des codes d'unité technique, des codes de type d'emplacement de mesure
et des codes d'orientation de montage.
3.6 Exigences relatives à la définition du document de données
Une spécification d'architecture d'information CM&D ouverte doit également spécifier le format pour la
publication d'un document de données. La spécification permet à la bibliothèque de données de référence
d'être lue ou rédigée de manière normalisée et prend en charge les applications nécessitant une capacité
d'importation/d'exportation de données.
Les spécifications qui utilisent le format du schéma de description de fichier comme modèle de données de
mise en œuvre utiliseront très probablement la même spécification pour la publication d'un document de
données ASCII ou binaires. La description de la structure d'enregistrement complète doit être publiée et
spécifie les champs de données contenus dans le fichier, leur emplacement exact par rapport aux autres
champs de données, qu'ils soient de format ASCII ou binaire, et le format de données exact — virgule
flottante réelle, nombre entier, caractère, chaîne de caractères variables — de chaque champ.
Les spécifications qui utilisent le format de schéma XML comme modèle de données de mise en œuvre
utiliseront très probablement le même format pour la publication d'un document de données XML. Le schéma
XML fournit la définition du document XML et les analyseurs syntaxiques XML et les outils de validation
peuvent vérifier la syntaxe du contenu du document.
3.7 Spécifications conformes
Une spécification d'architecture d'information CM&D ouverte doit s'appuyer sur une architecture d'information
telle que décrite de 3.1 à 3.6. Une association à but non lucratif, MIMOSA, publie une spécification
d'architecture d'information CM&D ouverte qui est conforme aux exigences énoncées ci-dessus. Cette
spécification MIMOSA d'architecture des systèmes ouverts pour l'intégration des applications d'entreprise est
connue sous le nom de spécification OSA-EAI™ (Enterprise Application Integration). Sa description détaillée
est fournie dans l'Annexe A.
4 Exigences relatives à l'architecture de traitement CM&D
4.1 Vue d'ensemble
Une architecture de traitement décrit toutes les interactions ou transactions se produisant entre des modules
internes au système logiciel proprement dit, externes aux interactions avec l'utilisateur final ou externes à
d'autres interactions avec le système logiciel. Une spécification d'architecture de traitement CM&D ouverte
doit utiliser l'architecture de traitement illustrée à la Figure 2. Cette architecture est définie par des blocs de
fonctionnalité de traitement des données. Une fois chaque bloc du système configuré de manière appropriée,
les données de base sont converties en format numérique lors de l'acquisition des données (DA) et sont
traitées de diverses manières lorsqu'elles sont transformées en informations d'actions, ce qui entraîne la
formulation de conseils (AG). Dans la mesure où le traitement passe de DA à AG, il est nécessaire de
transférer les données des blocs précédents aux blocs suivants, et de recevoir des informations
supplémentaires de systèmes externes ou de les leur envoyer. De même, lorsque les données deviennent
des informations, des affichages techniques normalisés et des présentations sous forme de graphiques sont
requis. Dans de nombreuses applications, l'archivage des données est requis pour conserver un historique
des données de sortie de chaque bloc. Les blocs DA, DM et SD sont responsables de l'évaluation de la
qualité des données. Il convient que la sortie soit qualifiée de bonne, de mauvaise ou d'indéterminée.
4 © ISO 2007 – Tous droits réservés
---------------------- Page: 9 ----------------------
ISO 13374-2:2007(F)
La présente partie de l'ISO 13374 ne traite pas de l'impact des erreurs et de leur propagation à l'intérieur et
entre les différents blocs de traitement CM&D. De telles erreurs peuvent provenir de l'étalonnage de
l'appareillage de mesure, du bruit environnemental, du conditionnement et du traitement des signaux, de
l'arrondi de calcul, d'entrées saisies par l'homme et de leur action combinée.
Figure 2 — Organigramme du traitement des données
4.2 Blocs d'acquisition des données (Data Acquisition, DA)
Comme indiqué de manière détaillée à la Figure 3, le bloc DA a été généralisé pour représenter le module
logiciel qui fournit l'accès système aux données numérisées saisies automatiquement ou manuellement. Le
module DA peut représenter un module d'acquisition des données spécialisé qui reçoit des signaux
analogiques de capteurs existants, ou il peut recueillir et consolider des signaux du capteur à partir d'un bus
de données. Il peut également représenter alternativement l'interface logicielle vers un capteur intelligent. Le
module DA est généralement un serveur d'enregistrements de données de capteur numérisées et étalonnées.
© ISO 2007 – Tous droits réservés 5
---------------------- Page: 10 ----------------------
ISO 13374-2:2007(F)
Figure 3 — Bloc d'acquisition des données
La sortie de tous les blocs DA doit comporter les éléments suivants:
⎯ des données numérisées;
⎯ des données datées harmoniques et de référence, normalement rapportées au temps universel
coordonné (UTC) et au fuseau horaire local;
⎯ un indicateur de qualité des données (par exemple «mauvais», «bon», «inconnu», «à l'étude», etc.).
Exemples de données numérisées:
⎯ valeurs à virgule flottante pour les données scalaires;
⎯ grandeurs et séries chronologiques pour les données dynamiques;
⎯ données du rayonnement thermique avec image numérisée pour les données thermographiques;
⎯ résultats de l'essai échantillonné pour les données relatives à l'échantillon de fluide de
lubrification/d'air/d'eau.
6 © ISO 2007 – Tous droits réservés
---------------------- Page: 11 ----------------------
ISO 13374-2:2007(F)
4.3 Blocs de manipulation des données (Data Manipulation, DM)
Comme illustré de manière détaillée à la Figure 4, le bloc DM traite les données numériques du bloc DA pour
les convertir au format désiré qui caractérise des descripteurs spécifiques (caractéristiques) pertinents dans le
processus de surveillance et de diagnostic d'état des machines. La fonctionnalité au sein de cette couche est
souvent constituée de quelques algorithmes de traitement du signal.
Figure 4 — Bloc de manipulation des données
Ce bloc peut contenir des fonctions de traitement spécifiques, telles que la transformation de Fourier rapide,
des ondelettes ou des valeurs moyennes simples sur un intervalle de temps.
Exemples de sorties de descripteur du bloc DM:
⎯ caractéristique extraite;
⎯ conversion du domaine temporel au domaine fréquentiel, et inversement;
⎯ valeurs calculées, non interprétatives;
⎯ capteur virtuel (pression différentielle entre les pressions d'entrée et de sortie);
⎯ intégration de l'accélération à la vitesse/double intégration au déplacement;
⎯ filtrage;
⎯ normalisation;
⎯ série chronologique, y compris la fréquence d'échantillonnage.
© ISO 2007 – Tous droits réservés 7
---------------------- Page: 12 ----------------------
ISO 13374-2:2007(F)
4.4 Blocs de détection d'un état (State Detection, SD)
Comme illustré à la Figure 5, la principale fonction du bloc SD (parfois qualifié de «reconnaissance d'un état»)
est de comparer les sorties DM et/ou DA à des valeurs attendues de profils de référence ou à des limites
d'exploitation, afin d'émettre des indicateurs d'état énumérés avec des alertes de limites de seuil respectives.
Le bloc SD génère des indicateurs qui peuvent être utilisés par le bloc d'évaluation de l'état pour générer des
alertes et alarmes. Lorsque les données appropriées sont disponibles, il convient que le bloc SD produise une
évaluation fondée sur le contexte d'exploitation, tenant compte de l'état d'exploitation en cours ou de
l'environnement d'exploitation.
Figure 5 — Bloc de détection d'un état
De manière générale, ce bloc de traitement fournit des données contribuant à l'élaboration d'un diagnostic
dans le bloc d'évaluation de l'état. Le bloc SD peut utiliser les sorties courantes et historiques de DA et de DM
pour évaluer l'état courant. Il peut fournir des signaux pour la manipulation de données
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.