ISO 18435-3:2015

INTERNATIONAL ISO
STANDARD 18435-3
First edition
2015-08-01
Industrial automation systems and
integration — Diagnostics, capability
assessment and maintenance
applications integration —
Part 3:
Applications integration description
method
Systèmes d’automatisation industrielle et intégration — Diagnostics,
évaluation des moyens et intégration des applications de
maintenance —
Partie 3: Méthode de description pour l’intégration d’applications
Reference number
©
ISO 2015
© ISO 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative reference(s) . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 Applications integration description methods . 2
5.1 Introduction to the application integration concept . 2
5.1.1 General. 2
5.1.2 Inter-domain requirements . 4
5.1.3 Intra-domain requirements . 5
5.2 Profiling concept . 6
5.2.1 General. 6
5.2.2 Intra-domain information exchange compatibility . 6
5.2.3 Inter-domain information exchange compatibility . 7
5.3 Basic interoperability requirements for information exchange . 8
5.4 Procedure for the construction of AIMEs and ADMEs . 8
5.4.1 General. 8
5.4.2 Application interoperability requirements .10
5.4.3 Specify content section .11
5.4.4 Specify resource and conveyance requirements .11
5.5 AIME requirements .11
5.5.1 General.11
5.5.2 AIME detailed requirements .11
5.6 Construction of the ADME .12
5.6.1 General.12
5.6.2 Technical dictionary selection .12
5.6.3 Application framework selection .12
5.6.4 Contents section .12
6 Compliance .12
Annex A (normative) Ontology in AIME/ADME .13
Annex B (informative) Smart Pump Information exchange example .20
Annex C (informative) Jam detection example .28
Annex D (informative) EtherNet/IP to OPC Information Exchange .33
Bibliography .38
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is Technical Committee ISO/TC 184, Industrial automation
systems and integration, Subcommittee SC 5, Architecture, communication and integration frameworks.
ISO 18435 consists of the following parts, under the general title Industrial automation systems and
integration — Diagnostics, capability assessment, and maintenance applications integration:
— Part 1: Overview and general requirements
— Part 2: Descriptions and definitions of application domain matrix elements
— Part 3: Applications integration description method
iv © ISO 2015 – All rights reserved

Introduction
ISO 18435 defines a set of integration methods intended to be used when integrating diagnostics,
capability assessment, and maintenance applications with the applications in production, control, and
other manufacturing operations.
ISO 18435-1 provides an overview of the elements as shown in Figure 1 and the rules of a method to
describe an automation application’s integration requirements. The elements include the key aspects
when integrating an automation application with other applications and the relationships of these key
aspects. The rules include the information exchanges to support interoperability within an application
and between applications.
ISO 18435-2 provides the detailed definitions of the Application Interaction Matrix Element (AIME) and
Application Domain Matrix Element (ADME) structures and their relationships. In particular, the steps
for constructing an ADME from a set of AIMEs are described.
This part of ISO 18435 defines a recommended method based on templates to describe the
interoperability between applications in two or more automation domains within an enterprise, at all
levels of an enterprise’s functional and resource hierarchies. The focus is on the production operations
and maintenance operations domains.
Figure 1 — Relationships between the parts of ISO 18435
UML is used to represent information exchange requirements associated with the interoperability and
the integration of plant floor applications, in particular, diagnostics, control, maintenance and production.
The purpose is to focus on how to express the information exchanges:
— about the process, equipment, operators, and materials and other automation assets;
— that are conveyed from control and production systems to various diagnostics and maintenance
systems in order to perform asset management.
The intended benefits for representing information exchanges are to:
— facilitate specifying and procuring open systems that support interoperability among diagnostics
and maintenance applications;
— reduce the time to develop diagnostics and maintenance solutions that directly address the well-
defined integration requirements;
— provide a means to categorize tools intended to enable and verify interoperability and integration
across applications.
vi © ISO 2015 – All rights reserved

INTERNATIONAL STANDARD ISO 18435-3:2015(E)
Industrial automation systems and integration —
Diagnostics, capability assessment and maintenance
applications integration —
Part 3:
Applications integration description method
1 Scope
This part of ISO 18435 defines the profiling methodology to use the interoperability templates of
ISO 18435-2. These profiling methods describe the construction and the use of application domain
matrix elements (ADMEs), application interaction matrix elements (AIMEs), and an open technical
dictionary (OTD) to support the information exchange.
In particular, this part of ISO 18435 gives guidance related to profiling the information exchange
between two applications by establishing the context, conveyance, and contents defined in ISO 18435-2.
This part of ISO 18435 is intended to be used in conjunction with ISO 18435-1 and ISO 18435-2.
2 Normative reference(s)
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO 8000 (all parts), Data quality
ISO/IEC 10646, Information technology — Universal Coded Character Set (UCS)
ISO 15745-1, Industrial automation systems and integration — Open systems application integration
framework — Part 1: Generic reference description
ISO 18435-1:2009, Industrial automation systems and integration — Diagnostics, capability assessment
and maintenance applications integration — Part 1: Overview and general requirements
ISO 18435-2:2012, Industrial automation systems and integration — Diagnostics, capability assessment
and maintenance applications integration — Part 2: Descriptions and definitions of application domain
matrix elements
ISO/TS 29002 (all parts), Industrial automation systems and integration — Exchange of characteristic data
ISO/TS 29002-5:2009, Industrial automation systems and integration — Exchange of characteristic
data — Part 5: Identification scheme
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 18435-1 and ISO 18435-2 and
the following apply.
3.1
ontology
explicit and consensual specification of concepts of an application domain independent of any use of
these concepts
[SOURCE: ISO 13584-511:2006, 3.1.20]
4 Abbreviated terms
ADME Application Domain Matrix Element
AIME Application Integration Matrix Element
CBM Condition-Based Maintenance
OTD Open Technical Dictionary
UML Unified Modelling Language
XML eXtensible Markup Language
5 Applications integration description methods
5.1 Introduction to the application integration concept
5.1.1 General
The customer applications integration requirements determine the information exchange profiles
that are needed to support the application interoperability requirements. To develop the information
exchange profiles for the applications of interest, it is necessary to determine the existing customer
domain areas of interest.
Clause 5 describes the method for specifying the information contained in the AIME and the ADME for
the information exchange requirements using templates defined in ISO 18435-2. The use of this method
will provide interoperability for the applications in the defined context. As this methodology is used
for integrating additional applications from various domains, this method can be used for verifying if
the information exchange profiles (using the AIME structure) are interoperable as needed by the user.
Figure 2 shows an iterative process to verify the intended interoperability of the application integration.
2 © ISO 2015 – All rights reserved

Figure 2 — System design cycle for interoperability
The general structure for the application information exchange profiles are depicted in Figure 3. The
methods for assessing the AIME profile compatibility to support the information exchanges will depend
upon the context and domains of interest.
Figure 3 — Profile elements
The diagnostic and maintenance mission depends on the objectives of integration between different
application domains as shown in Figure 4. The description of this technical mission shall include the
identification of the associated assets for which the mission is defined and the application domains
involved.
The method for describing the information exchange profiles is dependent upon the context established
according to intra- or inter-domain information exchanges. The capability profiles of the resources to
support the information exchange shall be described by the AIME.
NOTE The information exchanges between the allocated resource and definition resources can be described
with a sequence diagram according to ISO 18435-2:2012, 5.2.
Application domain categories are defined in ISO 18435-1 as shown in Figure 4. In this part of ISO 18435,
interoperability templates are described for integration requirements as depicted in ISO 18435-1 for
the interoperability of applications.
As an illustration of the methodology using interoperability templates, the diagnostic and control
application domains are used as shown in Figure 4.
Figure 4 — Categories of application domains
5.1.2 Inter-domain requirements
Interoperability templates for inter-domain application interoperability shall require references to
either a specific domain standard or the profile of a specific domain standard, according to ISO 15745,
to specify the context of the integration model.
EXAMPLE 1 As shown in Figure 5, the application in the control application domain could use the IEC 61512
reference model to describe the model construction, terms, and definition used in the interoperability templates
for the ADME. The application in the diagnostic application domain could use the ISO 13374-2 reference model to
describe the corresponding diagnostic ADME.
Thus, when exchanging information between different domains, it is necessary to indicate the context
and then to describe the content information handled by the conveyance mechanism. The context,
conveyance and content information are contained in the ADME using profile specifications. The actual
contents of the information exchange shall be defined by profile specifications.
EXAMPLE 2 An ISO 13374 diagnostic information message, advisory generation, is sent from the diagnostic
application as an event to the IEC 61512 batch control application.
4 © ISO 2015 – All rights reserved

Figure 5 — Inter-domain applications interoperability
The terms and definitions of the information models shall reference standards. The terminology and
models of the standards shall be identified and referenced using open technical dictionary (OTD)
concepts. In this part of ISO 18435, the information models and terminology use concepts of an open
technical dictionary as defined in ISO/TS 29002 (see Annex A). The use of a common set of models and
terms for applications in different domains establishes the basis for enabling information exchange.
This applications integration methodology enables the mapping of the inter-domain interoperability
requirements into the AIMEs for each application of interest and the ADMEs between applications.
5.1.3 Intra-domain requirements
Intra-domain application interoperability templates shall use a common context for the applications
information exchange reference model.
EXAMPLE As shown in Figure 6, the control applications and the diagnostic applications have the same
context for the information exchange such that the representation, terms, definitions have the same structure
and meaning. The conveyance and the content sections follow the syntax and semantics of IEC 61512.
Figure 6 — Intra-domain applications interoperability
5.2 Profiling concept
5.2.1 General
The general profiling concept is depicted in Figure 7. In ISO 18435-2, the general templates for context,
conveyance, and contents are specified. The template information for intra-domain information
exchange profiles is the information directly from the reference domain standards. For the inter-domain
profiles, the open technical dictionaries (OTDs) will need to be referenced to ensure compatibility
of terms and definitions for the information exchange information. The OTDs shall contain profiling
information for the referenced domains using the methodology of ISO 15745-1; the inter-domain
information exchange may require mapping concepts from two technical dictionaries.
Figure 7 — Profile aggregation
The AIME defines the capability profile to support the information exchange requirements of the
ADME. The capability profiles for intra-domain applications are by definition compatible. For instance
the device profile and communication profiles conform to a common set of specifications.
Devices can be selected and their relevant properties can be identified and referenced by using
component data dictionary such as IEC 61360 [Common Data Dictionary (CDD)]. Device class
identification codes and property identification codes can be used to refer to generic components
characteristics.
NOTE Descriptions of switchgear and controlgear classes are given by IEC 62683 and descriptions of process
equipment are given by IEC 61987.
The capability profiles for inter-domain applications can conform to different device and
communications profiles. The application information exchange profile defines the preferred context
and conveyance profiles to support the information exchange. The capability profiles defined in the
AIMEs shall be checked to verify compatibility. Since the context is specified as a profile referencing a
profile, multiple levels of profile checking are required.
5.2.2 Intra-domain information exchange compatibility
The intra-domain information exchange shall use the same context and conveyance profiles as shown in
Figure 8. For intra-domain information exchange, this reduces the complexity in the selection process
for resource profiles.
6 © ISO 2015 – All rights reserved

Figure 8 — Intra-domain information exchange
5.2.3 Inter-domain information exchange compatibility
The inter-domain information exchange requires additional compatibility checking to select the
appropriate resource profiles for the information exchange. The contexts shall be distinguished by
referencing the domains according to ISO 18435-1. The context shall reference a set of definitions
specified by an open technical dictionary. If the contexts use different open technical dictionaries,
the selection of the appropriate entries from each open technical dictionary shall be identified and a
common context established.
The selected resources in each domain shall be checked to provide the conveyance required by the
ADME as shown in Figure 9. Each resource (e.g. device, communications, equipment, software) shall
provide the requisite capabilities defined by the conveyance specification.
Figure 9 — Inter-domain exchange
5.3 Basic interoperability requirements for information exchange
The information to be exchanged shall be:
— Defined according to an open technical dictionary
— All information shall use concepts defined in an open technical dictionary. The open technical
dictionary shall meet the requirements of ISO/TS 29002.
NOTE 1 ISO/TS 29002 provides a basic set of requirements for open technical dictionaries. By use of
ISO/TS 29002, a mapping of different contexts is possible.
— Associated with a context by referencing the application domain integration diagram.
EXAMPLE Categories of domains are shown in Figure 4.
— Based on a publicly available information model
NOTE 2 The information may be profiled using the information model; i.e. the characteristic data in the
information exchange may be referenced to a publically available standard.
NOTE 3 The information model should indicate the purpose and use of the information exchange, such as
whether the information exchange is for design, operational, and/or maintenance purposes.
— Based on ISO 8000 data quality standards; the relevant parts shall be specified.
NOTE 4 The information to be exchanged has a formal specification with a syntax that can be checked by a
computer to verify that it meets the master data specification.
NOTE 5 ISO 8000-120 provides requirements for data provenance and provenance record; i.e. the history of
the data and information about the owner of the information (e.g. traceable for time and location). The traceability
can be realized by using the conveyance section of the ADME.
5.4 Procedure for the construction of AIMEs and ADMEs
5.4.1 General
The general concept and a procedure for construction of AIMEs and ADMEs is shown in the example of
Figure 10. The order of the tasks is only shown for illustration.
EXAMPLE 1 A procedure for the construction of AIMEs and ADMEs is shown in Figure 10 below.
8 © ISO 2015 – All rights reserved

Figure 10 — Procedure example
The procedure shall perform the following steps:
— Determine the application interoperability requirements for the information exchange
— Specify content section for information exchange using common information model
— Specify resource capabilities and conveyance sections using the rules of the selected application
integration framework.
— Define the identifiers for the AIMEs and ADMEs references as specified in Annex A.
NOTE The conveyance mechanism between the source and destination application must utilise the same
communication service; e.g. when those applications have a common information model of the content but not for
the conveyance, then one application needs to be adapted to send information.
EXAMPLE 2 When the conveyance is described in WSDL and uses web service, then the source application will
need to develop the necessary set of capabilities to serve the destination requirements. Alternatively the supplier
can propose to exchange the information using a “fieldbus” standard. The conveyance mechanism would be one
of the fieldbus services.
5.4.2 Application interoperability requirements
5.4.2.1 General
The minimum criteria for interoperability are given in ISO 18435-1:2009, 5.3.
The requirements for interoperability within a common context are defined with respect to
customer/supplier perspective or needs, e.g. using a particular field bus standard (IEC 61784), a
particular device model (ISO 15745-3), a particular application standards (IEC 61512), or using a
particular interface (ISO 13374-2). The aim is to use a common set of vocabulary already defined.
The interoperability will be enabled by completing the actions described in the following sub-clauses.
5.4.2.2 Identify candidate applications and their domain
The candidate applications shall be identified and shall be assigned to their associated domain(s) in
accordance with ISO 18435-1:2009, 5.4. The domain(s) involved within the information exchanges shall
be determined.
EXAMPLE Using ISO 18435-2:2012, Annex B, the Robot Monitoring application is assigned to domain
category identifier, D1.2, and the Robot Control application is assigned to D1.1.
NOTE The domain category identifier, e.g. D1.2 (see ISO 18435-1:2009, 5.4.8), is used to build the AIME.
5.4.2.3 Identify processes
The AIME process profiles (see ISO 18435-2:2012, 6.2.3) of the candidate applications shall be identified.
EXAMPLE 1 Using ISO 18435-2:2012, Annex B, the Robot Monitoring application is associated with the process
RobotConditionMonitoring and the Robot Control application is associated with the process MotionControl.
The AIME common resource profile (see ISO 18435-2:2012, 6.2.3) shall be identified.
EXAMPLE 2 Using ISO 18435-2:2012, Annex B, the Robot Monitoring application is associated with the
resource PLC and the Robot Control application is associated resources PLC, servo drive, and vibration monitor.
5.4.2.4 Select/create information models
The terms and definitions of the information models shall reference standards. The use of a common
set of models and terms for applications in different domains establishes the basis for enabling
information exchange.
EXAMPLE Using ISO 18435-2:2012, Annex B, the Robot Monitoring application is associated with the
industry specific standard for condition monitoring standard, ISO 13374.
The terminology and models of the standards shall be identified and referenced using open technical
dictionary (OTD) concepts. In this part of ISO 18435, the information models and terminology shall use
concepts of an open technical dictionary as defined in ISO/TS 29002 (see Annex A).
5.4.2.5 Define integration criteria
The application integration framework shall be specified for the information exchange.
NOTE 1 ISO 15745-1 specifies the set of rules and elements that comprise the application integration
framework. The set of elements and rules for constructing applications, systems, and components are consistent
within the application framework.
10 © ISO 2015 – All rights reserved

EXAMPLE Using ISO 18435-2:2012, Annex B, the MEidentification (e.g. ADME) along with its MESource (ISO)
describes the reference application integration framework.
If the information exchange occurs between applications described using different application
integration frameworks, a set of rules and elements common to both frameworks shall be established.
NOTE 2 The development of a common set of rules for both frameworks is outside the scope of this part of
ISO 18435.
5.4.3 Specify content section
The ADME contents for the information exchange shall be specified using a common information model.
EXAMPLE 1 Using ISO 18435-2:2012, Annex B, the content section describes the information exchange name,
variables in the exchange, and interactions for the information exchange.
EXAMPLE 2 Annexes C and D depict examples using contents for domain category identifier, D1.1 to D1.2,
exchange.
5.4.4 Specify resource and conveyance requirements
Based on the application requirements and the resource capabilities, the context and conveyance
sections shall be specified using the selected application integration framework.
The AIME resource section specifies the resource profile that provides the capabilities needed for
the application.
EXAMPLE 1 Using ISO 18435-2:2012, Annex B, the resource section profiles the resources necessary to
support the information exchange, such as a PLC.
The AIME conveyance section specifies the particular communications requirements needed
for the application. The common informationType shall be identified in both AIMEs. The set of
channelType,roleType and participantType shall be identified in accordance with ISO 18435-2:2012, 6.2.4.
EXAMPLE 2 Using ISO 18435-2:2012, Annex B, the conveyance section profiles the channel type that is
supported by the particular application integration framework.
NOTE 1 The conveyance section can profile different channel types that are supported by a particular
application integration framework. If the application integration framework supports multiple channel types,
the informationType will have the common semantics across the channelType(s).
NOTE 2 The roleType identifies services for the resource (e.g., service description in WSDL)
5.5 AIME requirements
5.5.1 General
AIMEs are constructed according to the resource requirements established by the application
interoperability requirements. In diagnostic applications where equipment/device/software is involved
in the application, a series of steps are required before operational information exchanges can take place.
5.5.2 AIME detailed requirements
The AIME shall support the following aspects:
— Selection: The first step is to select the appropriate equipment/devices/software profiles to
support the information exchange. The equipment/device/software profiles are chosen to meet
the requirements established by the resource and conveyance requirements stated in 5.4.4.
Typical supported applications require selection of the appropriate profiles to support the
information exchange.
EXAMPLE 1 Annex D depicts an example of equipment/device profile for construction of an AIME that meets
the requirements of 5.4.4.
EXAMPLE 2 ISO 16100 describes manufacturing software capability profiles.
— Configuration: This step specifies the configuration parameters of the device/equipment/software
to meet the information exchange requirements. A specific set of configuration steps are required
according to the conveyance and context requirements established in 5.4.4.
— Operation: This step specifies operational scenarios of the information exchanges between the
applications. The operational scenarios define the informationType and the interactions to be
supported for the interoperability of the applications. The variable type definition is established by
the particular technical dictionary.
EXAMPLE 3 Annex B depicts an example of operational information to be exchanged that meets the
requirements of 5.4.4.
Annex A depicts the requirements for specification of variable type and instance definitions.
5.6 Construction of the ADME
5.6.1 General
ADMEs are constructed using the AIMEs to describe the relationships between the applications.
Any manufacturing resource shall have a unique identification using a standardized method, such as in
ISO/TS 29002.
When the complete ADME and the complete AIME’s are defined in accordance with ISO 18435-2, and
meet the criteria in ISO 18435-1:2009, 5.3, then the applications shall be considered interoperable.
5.6.2 Technical dictionary selection
The technical dictionary used in the application shall be selected and specified in the contents of the
ADME.
EXAMPLE Annex A depicts an example of selection of the technical dictionary in the ADME contents section.
5.6.3 Application framework selection
The application framework used in the application shall be selected and specified in the contents of the
ADME.
EXAMPLE Annex A depicts an example of selection of the application framework in the ADME contents section.
5.6.4 Contents section
Each item shall be described according to Clause A.6.
6 Compliance
An application can state compliance to this part of ISO 18435 by documentation of context,
conveyance, and contents templates specified in ISO 18435-2 and compliance with the requirements
as stated in this part.
NOTE This part provides guidance for using the templates defined in ISO 18435-2 with the concepts of an
open technical dictionary as shown in Annex A.
12 © ISO 2015 – All rights reserved

Annex A
(normative)
Ontology in AIME/ADME
A.1 General concepts for OTD
A number of terms are defined in ISO 18435-2. The definition of these terms can be entered into an open
technical dictionary (OTD). The use of an OTD enables concept identifiers to be associated with the
terms. Since for a particular domain, a different set of terms may be preferred, as long as the concepts
are the same, a mapping between the domains is possible. A particular set of terms and their use in a
domain may be referred to ontology for that domain. The use of an “identification guide” provides a
mapping between the OTD and the particular domain ontology.
NOTE ISO/TS 22745-30 describes methods for construction of identification guides (or data requirements).
ISO/TS 22745-40 describes methods for construction of catalogues. The requirements can be specified for the
domain ontology; the particular application specifies (via a catalogue description), the support of the particular
data requirements.
The terms defined in ISO 18435-2 are defined in Tables A.2 to A.5. Each term can be mapped into an
OTD according to ISO/TS 29002-5.
A.2 Format of concept identifier according to ISO/TS 29002-5
The concept identifiers shall be as specified in ISO/TS 29002-5:2009, Clause 7; reference information is
shown in Table A.1.
A.2.1 Overview
Figure A.1 summarizes the identifier format.
Figure A.1 — Identifier format
A.2.2 Character set
An identifier shall use only the characters listed in Table A.1.
Table A.1 — Character set
Designation ISO/IEC 10646 code (hexadecimal) Description
digits 0030 – 0039 ‘0’ – ‘9’
upper case letters 0041 – 005A ‘A’ – ‘Z’
hyphen 002D ‘-’
pound sign 0023 ‘#’
Period 002E ‘.’
Colon 003A ‘:’
Underscore 005F ‘_’
In this part of ISO 18435, the term “upper case alphanumeric” refers to an upper case letter or digit.
In this part of ISO 18435, the term “safe character” refers to an upper case letter, a digit, a colon, a
period, or an underscore.
A.2.3 Minimum length of attributes
Unless otherwise specified, the minimum length of each attribute specified in this part of ISO 18435 is 1.
14 © ISO 2015 – All rights reserved

A.2.4 Maximum length of identifier
The maximum length of an identifier is 290 characters.
Identifier elements are as specified in ISO/TS 29002-5:2009, Clause 8.
Syntax is as specified in ISO/TS 29002-5:2009, Clause 9.
An IRDI string for a normal identifier shall consist of the RAI string, the DI string, and the VI string,
separated by pound sign characters (#).
An RAI string shall consist of the ICD, OI, OPI, OPIS and AI strings, separated by hyphen characters (-).
The OPI, OPIS, and AI are optional. If the OPI, OPIS and AI are omitted, the last three hyphens shall be
omitted. If the OPIS and AI are omitted, the last two hyphens shall be omitted. If the AI is omitted, the
last hyphen shall be omitted.
EXAMPLE The following are some correct and incorrect RAIs.
Correct: RAI = “0123-45-678-9-abc”
ICD = “0123”, OI = “45”, OPI = “678”, OPIS = “9”, AI = “abc”
Correct: RAI = “0161-1”
ICD = “0161”, OI = “1”, OPI = (null), OPIS= (null), AI = (null)
Incorrect: RAI = “0161-1---”
Trailing hyphens are not allowed.
Correct: RAI = “0112-1-18435-AAA001”
ICD = “0112”, OI = “1”, OPI = (null), OPIS = (null), AI = “18435_3”
The concept types, as defined in ISO/TS 29002-5:2009, Clause 6, are:
Class, property, datatype, document, and ontology.
A.3 Header section
The AIME and ADME header sections are defined by the following set of terms as shown in Table A.2.
Table A.2 — Header section
Term ICID Term Identifier Definition Example Variable ICID Concept Remarks
Identifier Type Text 1
(OTD=0112-1-18435)
ISO/IEC 11578
Identifier Mandatory – M Mandatory – M
Optional - O Optional - O
MEIdentification AAA001 M Identification SmartPumpControlAIME M P ICID reference
of AIME/ADME technical dic-
tionary identi-
fier
MErevision AAA002 M Revision of 1a M P
AIME/ADME
MEname AAA003 M Name of AIME/ D.1.2.Ay_D.1.1Az M P ADID category
ADME d e s c r ip t i ve
name
MEsource AAA004 M Source of ISO M P
AIME/ADME
MEclassID AAA005 M Identification AIP M C P r of i le iden-
of AIME/ADME t i f ic a t io n
class (ISO 15745
example)
MEdate AAA006 M Release date of 2012-12-30 M P
AIME/ADME
MEregistry AAA007 M Registry name Industry_specific_regis- M P Industry stand-
of AIME/ADME try_name_ISO_13774 a rd re g is t r y
name – regis-
tered in the ICID
dictionary
Text 1 C=class, P=property, DT=datatype, D=document. O=Ontology
A.4 “Context” ontology
The AIME and ADME context sections are defined by the following set of terms as shown in Table A.3.
Table A.3 — Context section
Term ICID Term Identifier Definition Example Variable ICID Concept Remarks
Identifier Type
(OTD=0112-1-18435)
ISO/IEC 11578 Text 1
Identifier Mandatory – M Mandatory – M
Optional - O Optional - O
domainSourceHandle AAB001 M S o u r c e D1.1 M C Domain for Con-
domain ID trol, I/O, oper-
for this AIME ational data
from ADID historian, and
panel display
domainDestinationHandle AAB002 M Destination D1.2 M C Domain for
domain ID Asset utiliza-
for this AIME tion, condition
from ADID monitoring, and
quality moni-
toring
applicationSourceHandle AAB003 M ID of the PumpControl M C
s o u r c e
ap pl i c a -
tion for the
information
exchange
Text 1 C=class, P=property, DT=datatype, D=document. O=Ontology
16 © ISO 2015 – All rights reserved

Table A.3 (continued)
Term ICID Term Identifier Definition Example Variable ICID Concept Remarks
Identifier Type
(OTD=0112-1-18435)
ISO/IEC 11578 Text 1
Identifier Mandatory – M Mandatory – M
Optional - O Optional - O
applicationDestinationHandle AAB004 M ID of the PumpDiagnostics M C
destination
ap pl i c a -
tion for the
information
exchange
applicationRelationshipSection AAB005 O List of con- M C
texts for the
application
applicationDomainRelation- AAB006 O Sp e c i f ic a- P ump_Cont rol _ M C List of the
shipName tion for the Context, Pump_ names
domain spe- Diagnostics_Con-
cific context text
of the appli-
cation
processSourceHandle AAB007 O ID for the FlowPIDControl O C A process con-
source pro- sists of a set of
cess associ- activities. Each
ated with activity is asso-
ciated with a set
of functions.
Functions are
implemented
through a set
of resources.
processDestinationHandle AAB008 O ID for the CurrentHealthEv- O C
destination aluation
p r o c e s s
associated
with
resourcePack AAB009 O List of PLC, MMD O C Each resource
r es o u r c es in the list has
involved in corresponding
information ISO 15745 com-
exchange pliant resource
profile
resourceName AAB010 O In s t a n ce PLC02 O C
name of
MMD00
resources
resourceProfile AAB011 M Re s o u r c e PLCiso15745pro- M C
profile infor- file
mation
MMDiso15745pro-
file
Text 1 C=class, P=property, DT=datatype, D=document. O=Ontology
A.5 “Conveyance” ontology
The AIME and ADME conveyance are defined by the following set of terms as shown in Table A.4 and
the example of use of the ontologies for information exchange between domains.
Table A.4 — Conveyance section
Term ICID Term Identifier Definition Example Variable ICID Concept Remarks
Identifier Type Text
(OTD=0112-1-18435)
ISO/IEC 11578 1
Identifier Mandatory – M Mandatory – M
Optional - O Optional - O
informationType AAC001 M Ty p e s o f CavInfoRequestType O C Information type
information defintions
exchanged
roleType AAC002 O E nu m e r - PumpDiag nost icsRole O C Role type defini-
ation of PumpControlRole tions
capabilities
e x h i b i t e d
by the par-
ticipant for
a particular
information
exchange
behaviour AAC003 O Behav iour PumpCavitationDetection O C
for the spec-
PumpControl
i f ie d r ole
type
relationshipType AAC004 O I d e n t i f i e s PumpControl2PumpDi- O C
the appli- agnostics
cation role
t y pes and
behaviour
participationType AAC005 O Types of col- PumpFlowControl Cavita- O C
laborat ing tionDetection
parties for
in
...