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
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 2007
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.
© 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
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
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
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.
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.
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
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.
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
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.
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
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.
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
⎯ 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.
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
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 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 about 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.
Figure 8 — Advisory Generation block
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:
a) measurement location description (measurement location table)
1) orientation and relative position,
2) location description;
b) monitoring intervals – dynamic vs. static
1) on-line continuous,
2) on-line polled,
⎯ default polling rate,
⎯ default parameters;
c) triggered vs. non-triggered
1) set points,
2) deadband;
d) asynchronous vs. synchronous;
e) transducer information
1) response curve,
2) measurement confidence,
3) transducer electronic data sheet (TEDS) information;
f) calibration;
g) channels
1) 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 effect 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 systems 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.
12 © ISO 2007 – All rights reserved
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. The data archiving system should provide rules
for the archiving rate and amount of data stored. Previous advisories should be audited for accuracy and root
cause information added upon its discovery.
4.11 Technical displays
Relevant technical displays showing data from each block are necessary to facilitate analysis by qualified
personnel. 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 is displayed by this processing block. 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
abnormalities 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) description which meets ISO/IEC 14750 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. Annex 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 (see Annex B for an understanding
of middleware). 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.
A module may implement the 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.
An example of a 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.
Figure 9 — Data processing flow within a standard architecture
14 © ISO 2007 – All rights reserved
Figure 10 — Example of compliant modules
Figure 11 — Example of a compliant modular system
16 © ISO 2007 – All rights reserved
Annex A
(informative)
Compliant specifications
A.1 MIMOSA's OSA-EAI™ CM&D information architecture specification
A.1.1 Introduction
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 (publicly
released version available for free download at http://www.mimosa.org/) is compliant as a CM&D information
architecture specification with ISO 13374-1 and this part of ISO 13374, 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.
MIMOSA regularly updates the OSA-EAI standard to add additional capabilities. Users and technology
suppliers are encouraged to refer to MIMOSA's Web site (http://www.mimosa.org/) for the latest version of the
standard.
A.1.2 Architecture
A.1.2.1 Diagram of architecture
The OSA-EAI Version 3.1 architecture is shown in Figure A.1.
Tech-XML-Services
Tech-Doc-File Tech-CDE-Services for Tech-XML-Web for
For Web Service EAI Application
For XML File Web Service Tech-XML HTTP Tech-XML
Tech-XML Interoperability
Imports & Export Clients & Servers Clients & Servers
Clients & Servers
Tech-Doc CRIS
Tech-CDE-Aggregate Tech-XML Atomic
Unpackaged
CRIS XML Transaction CRIS XML Transaction XML content
XML Content
Clients & Server Schema Client & Server Schema
Producer/Consumer
CRIS Reference data library MetaData taxonomy
Common Relational Information Schema (CRIS) Implementation model
OSA-EAI Common Conceptual Object Model (CCOM) Conceptual model
OSA-EAI Terminology dictionary Semantic definitions
Technology types [Tech-]
REG (Object Registry Management)
WORK (O&M Agent Work Management)
DIAG (Diagnostics/Prognostics/Health Assessment)
TREND (Operational Scalar Data & Alarms)
DYN (Dynamic Vibration/Sound Data & Alarms)
SAMPLE (Oil/Fluid/Gas/Solid Test Data & Alarms)
BLOB (Binary Data/Thermography Data & Alarms)
REL (RCM/FMECA/Model Reliability Information)
TRACK (Physical Asset GeoSpatial Tracking Information)
Figure A.1 — MIMOSA OSA-EAI architecture diagram
A.1.2.2 Definition of terms
A.1.2.2.1 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.
A.1.2.2.2 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.
A.1.2.2.3 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
18 © ISO 2007 – All rights reserved
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 redesigned 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 ORACLE
and Microsoft SQLServer table creation scripts.
A.1.2.2.4 Common Conceptual Object Model and Common Relational Information Schema
(CCOM/CRIS)
CCOM/CRIS contains standard enterprise, site, functional segment, asset and agent identification
nomenclature for the corporate level of an organization or the top organizational structure of a non-profit or
military body. Each Enterprise is associated with exactly one Enterprise Type. An enterprise uniquely
assigns Site Unique Integration Codes to new Sites and may control one or more Sites (which could have
formerly been controlled by other enterprises). In order for multiple enterprises to exchange MIMOSA
information, every Enterprise must request and utilize its unique, unchanging Enterprise Unique Integration
Code.
A Site is what an enterprise defines as an entity that 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 tangible as-built building.
For industrial and manufacturing applications, this entity normally represents a physical plant. For fleet
applications, this entity might represent a maintenance depot which has responsibility for assets. Some very
large assets, such as an aircraft carrier, may be defined as a Site itself. Each Enterprise uniquely assigns
every Site its unique, unchanging Site Unique Integration Code.
Because CCOM and CRIS are designed for multi-site collaborative asset life cycle management, nearly all
tables 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.1 of CCOM and CRIS have also added the ability to break up functional locations at a site into
multiple hierarchies of segments where serialized assets can be installed over time. In addition, CCOM/CRIS
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 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),
...
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 2007
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
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
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
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.
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.
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
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
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
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.
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
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.
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 et des signaux de
commande pour le module de capteur, tels que des commandes de planification de l'acquisition, des signaux
de déclenchement de données et des instructions de traitement.
Exemples de sorties du bloc SD:
⎯ indicateur d'état énuméré;
⎯ alertes de limite de seuil;
⎯ gravité de l'écart au-dessus/au-dessous de la limite de seuil;
8 © ISO 2007 – Tous droits réservés
⎯ fréquence d'alerte de changement;
⎯ degré d'anomalie;
⎯ analyse statistique utilisant des approches paramétriques et non paramétriques, par exemple distribution
de Weibull et gaussienne.
4.5 Blocs d'évaluation de l'état (Health Assesment, HA)
Comme illustré à la Figure 6, le bloc HA est un bloc d'information qui utilise l'expertise d'un humain ou d'un
agent automatisé pour déterminer l'état courant de l'équipement et diagnostiquer les états défectueux
existants. Il détermine l'état et les défaillances potentielles en fusionnant les données de sortie des blocs DA,
DM, SD et d'autres blocs HA.
Figure 6 — Blocs d'évaluation de l'état
Une sortie de ce bloc comprend l'état courant du composant/du système, les défauts et défaillances
diagnostiqués avec la probabilité de vraisemblance correspondante. Il est également possible de calculer le
coefficient de criticité courant (Risk Priority Number, RPN). Les structures de données de sortie peuvent
comprendre la modélisation des groupes d'ambiguïté et des hypothèses multiples. Le bloc HA peut également
produire une explication détaillée des preuves d'un diagnostic ou d'un état.
4.6 Blocs d'évaluation du pronostic (Prognostic Assesment, PA)
Comme illustré à la Figure 7, la principale fonction du bloc PA est de prévoir l'état futur de l'équipement
surveillé en utilisant une combinaison de modèles de pronostic et leurs algorithmes, y compris le(s) modèle(s)
d'utilisation opérationnelle future. Ce bloc détermine l'état futur et les modes de défaillance en combinant les
sorties pertinentes des blocs DA, DM, SD, HA et d'autres blocs PA et en appliquant un algorithme ou un
modèle de pronostic fondé sur l'utilisation opérationnelle envisagée. Pour assister l'algorithme ou le modèle,
le bloc HA peut également extraire des données historiques sur les défaillances du compte et l'historique
d'exploitation, ainsi que les fréquences de défaillance envisagées par rapport à l'utilisation opérationnelle.
La couche de pronostic peut rendre compte de l'état à une date ultérieure ou évaluer la durée de vie restante
d'un bien, compte tenu de son profil d'utilisation envisagé. Les évaluations de l'état futur ou de la vie restante
peuvent également s'accompagner d'un pronostic concernant l'état défectueux envisagé. Il est également
possible de calculer le coefficient de criticité future (RPN). Une sortie de ce bloc comprend l'état futur du
composant/du système et les défaillances futures avec la probabilité de vraisemblance correspondante. Les
structures de données de sortie peuvent comprendre la modélisation des groupes d'ambiguïté et des
hypothèses multiples. Le bloc PA peut également produire une explication détaillée des preuves d'une
défaillance envisagée ou d'un état.
Figure 7 — Bloc d'évaluation du pronostic
10 © ISO 2007 – Tous droits réservés
4.7 Blocs de formulation de conseils (Advisory Generation, AG)
Comme indiqué de manière détaillée à la Figure 8, la principale fonction du bloc AG est d'intégrer des
informations provenant des blocs DA, DM, SD, HA, PA et d'autres blocs AG, et des contraintes externes (liées
à la sécurité, à l'environnement, au budget, etc.) et de produire des actions recommandées optimisées et des
solutions alternatives pour le personnel concerné ou les systèmes externes. Les recommandations peuvent
comprendre des actions d'exploitation et de maintenance prioritaires et des évaluations de prévision des
capacités ou des modifications du profil d'exploitation pour permettre la réalisation de la mission. Le module
d'aide à la décision doit tenir compte de l'historique d'exploitation (y compris l'utilisation et la maintenance), les
profils de mission courants et futurs, les objectifs d'unités de niveau élevé et les contraintes de ressource.
Il convient que les conseils de maintenance émis par le bloc décrivent de manière détaillée les futurs travaux
de maintenance requis, pouvant comprendre la vérification des données relatives à la surveillance ou la
réalisation d'une surveillance complémentaire. Il convient que la structure de ces conseils soit mise au format
de «requête de travaux» pour les systèmes de gestion des travaux de maintenance externes. À partir de cette
requête, les systèmes de gestion des travaux de maintenance peuvent planifier les travaux à l'avance et
localiser les pièces de rechange et les outils requis pour l'exécution de ces travaux.
Figure 8 — Bloc de formulation de conseils
Les conseils d'exploitation émis par ce bloc peuvent être de nature immédiate, tels que la notification courante
d'alerte aux opérateurs et les mesures à prendre qui en résultent. D'autres conseils afférents à la production
peuvent être plus stratégiques, tels que l'envoi d'un avis à un système de planification de la production
concernant le risque élevé de défaillance sur une ligne de production en raison de la défaillance imminente
d'un organe critique.
Les évaluations de prévision de capacité de ce bloc fournissent les résultats pour les requêtes concernant la
vraisemblance de réalisation d'une mission spécifique ou d'un cycle de production. Ces évaluations sont
critiques pour les systèmes de prévision de la production lorsqu'il s'agit de déterminer l'acceptation ou le rejet
de certaines missions/requêtes et le lieu d'attribution des travaux en fonction des principes d'optimisation des
biens.
4.8 Configuration des blocs
Chaque bloc de traitement des données nécessite des informations relatives à sa configuration, dont
certaines peuvent être des données statiques; d'autres paramètres peuvent être modifiés de façon dynamique
par le système au cours de son fonctionnement.
L'exemple suivant est un échantillon de la configuration du bloc d'acquisition des données.
a) Description de l'emplacement de mesure (table d'emplacement de mesure):
1) orientation et position relative;
2) description de l'emplacement.
b) Intervalles de surveillance — Dynamique vs statique:
1) en continu en ligne;
2) interrogé en ligne;
⎯ taux d'interrogation par défaut,
⎯ paramètres par défaut.
c) Déclenché vs non déclenché:
1) valeurs de consigne;
2) zone morte.
d) Asynchrone vs synchrone.
e) Information du transducteur:
1) courbe de réponse;
2) confiance du mesurage;
3) information sur la fiche de données électroniques du transducteur (Transducer Electronic Data Sheet,
TEDS).
f) Étalonnage.
g) Canaux:
1) collecte à canal unique ou multicanaux.
12 © ISO 2007 – Tous droits réservés
4.9 Systèmes externes
La récupération de travaux antérieurs du système de maintenance et de données antérieures d'exploitation
(départ/arrêts/charges) d'un historique de traitement des données est importante pour l'évaluation de l'état
des machines. Après évaluation de l'état, l'action de maintenance à entreprendre peut aller de l'augmentation
de la fréquence de contrôle à la réparation ou au remplacement de la machine ou du composant endommagé.
Les modifications apportées aux opérations peuvent consister en un réglage des modes opératoires de
fonctionnement ou en une demande d'arrêt immédiat des équipements. Ce besoin de communiquer
rapidement avec le système de maintenance et d'exploitation nécessite des interfaces de logiciel avec les
systèmes de gestion de la maintenance et les systèmes de contrôle opérationnels. Ces interfaces sont utiles
pour transmettre les actions recommandées sous forme de requêtes de travaux de maintenance et de
requêtes de modification de l'exploitation.
4.10 Archivage des données
L'archivage des données est important pendant tout le traitement d'un programme de surveillance d'une
machine. Les tendances des données antérieures peuvent être analysées dans un but statistique. Il convient
que le système d'archivage des données fournisse des règles relatives à la fréquence d'archivage et à la
quantité de données stockées. Il convient de vérifier la précision des conseils antérieurs et d'ajouter des
informations relatives à la cause profonde lors de l'analyse.
4.11 Affichages techniques
Afin de faciliter l'analyse réalisée par du personnel qualifié, il est nécessaire de disposer d'affichages
techniques pertinents présentant des données pour chaque bloc. Il convient que ces affichages fournissent à
l'analyste les données requises pour identifier, confirmer ou comprendre un état anormal.
4.12 Présentation des informations
Les informations provenant des blocs HA, PA et AG sont affichées par le bloc de traitement. Il est important
de convertir les données sous une forme représentant clairement les informations nécessaires pour décider
d'actions correctives. Dans certains cas, par exemple en présence d'anomalies, l'utilisateur devra pouvoir faire
un zoom avant sur les affichages techniques SD, DM et DA.
4.13 Spécifications conformes
Une spécification d'architecture de traitement CM&D ouverte doit s'appuyer sur l'architecture de traitement
décrite ci-dessus. Les spécifications doivent spécifier un modèle/un schéma de données de traitement et une
description d'interface de programmation (Application Programming Interface, API) conforme aux exigences
de l'ISO/CEI 14750 pour les blocs de traitement présentés dans lesdites spécifications. Cela permettra
d'intégrer divers blocs de traitement des données provenant de différents fournisseurs dans un système
complet et fonctionnel. MIMOSA publie une spécification d'architecture de traitement CM&D ouverte qui est
conforme aux exigences 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-CBM™ (Open
Systems Architecture for Condition Based Maintenance). Sa description détaillée est fournie dans l'Annexe A.
La Figure 9 illustre comment ces blocs peuvent interagir pour former un système intégré complet. Le noyau
au centre de la roue représente le support des communications entre les modules. Celui-ci peut être réalisé
au moyen de technologies de communication courantes et des intergiciels (voir Annexe B pour de plus
amples informations sur les intergiciels). Par conséquent, il n'est pas nécessaire que les modules soient
localisés sur la même machine. Ils peuvent se situer à n'importe quel endroit sur un réseau local ou mondial.
Le concept d'architecture des systèmes ouverts permet d'intégrer une capacité de pronostic améliorée dans
des conceptions de systèmes nouveaux ou existants, contribuant ainsi à une flexibilité maximale pour les
futures mises à niveau du système.
Figure 9 — Circulation du traitement des données au sein d'une architecture standard
Un module peut mettre en œuvre la fonctionnalité d'un ou de plusieurs blocs de traitement des données dans
l'architecture de traitement. Par exemple, le module A de la Figure 10 met en œuvre la fonctionnalité du bloc
de détection d'un état. Le module B, d'autre part, met en œuvre la fonctionnalité de deux blocs: l'évaluation de
l'état et l'évaluation du pronostic. Un module peut mettre en œuvre une ou plusieurs API de bloc. Les modules
d'autres couches mettent en œuvre une ou plusieurs API de couche. Par exemple, le module D de la
Figure 10 met en œuvre la fonctionnalité de deux blocs: la manipulation des données et la détection d'un état.
Dans ce cas, le module fournit des informations sur les données manipulées et les conditions calculées.
La Figure 11 illustre un exemple de système conforme. Le système dispose du nombre le plus élevé de blocs
d'acquisition des données (DA) qui alimentent des blocs plus complexes jusqu'à ce qu'un bloc de formulation
de conseils (AG) envoie finalement son aide à la décision de maintenance et d'exploitation vers un affichage
d'utilisateur externe.
14 © ISO 2007 – Tous droits réservés
Figure 10 — Exemple de modules conformes
Figure 11 — Exemple d'un système modulaire conforme
16 © ISO 2007 – Tous droits réservés
Annexe A
(informative)
Spécifications conformes
A.1 Spécification MIMOSA d'architecture d'information CM&D (OSA-EAI™)
A.1.1 Introduction
MIMOSA est une association professionnelle à but non lucratif qui développe et favorise l'adoption de normes
d'information ouvertes pour l'exploitation et la maintenance. MIMOSA est constituée de fournisseurs de
systèmes de gestion de biens industriels et d'utilisateurs finals de systèmes de biens industriels qui
développent des spécifications d'intégration de sources ouvertes pour la gestion des biens matériels.
La spécification MIMOSA d'architecture des systèmes ouverts pour l'intégration des applications d'entreprise
(OSA-EAI™) (version disponible au public téléchargeable gratuitement sur http://www.mimosa.org/) est une
spécification d'architecture d'information CM&D, conforme à l'ISO 13374, Parties 1 et 2, qui facilite
l'intégration de la gestion des biens et de l'information CM&D dans des entreprises multisites. Les
spécifications de système OSA-EAI de MIMOSA offrent de nombreux avantages aux utilisateurs en termes de
maintenance et de fiabilité et aux développeurs et fournisseurs de technologie.
Pour les utilisateurs, l'adoption des spécifications OSA-EAI de MIMOSA facilite l'intégration des informations
de gestion des biens, permet de choisir librement une application logicielle parmi une large sélection et de
faire des économies en réduisant les coûts liés à l'intégration et à la maintenance logicielle.
Pour les fournisseurs de technologie, l'adoption des spécifications OSA-EAI de MIMOSA stimule et élargit le
marché. Elle permet de concentrer les ressources sur une activité clé à valeur supérieure plutôt que sur une
plate-forme à valeur inférieure et sur des exigences d'interface sur mesure et elle entraîne une réduction
global
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...