Industrial automation systems and integration — Diagnostics, capability assessment and maintenance applications integration — Part 2: Descriptions and definitions of application domain matrix elements

ISO 18435-2:2012 defines the structures and templates for an application interaction matrix element; an application domain matrix element. ISO 18435-2:2012 also defines the relationship between these types of elements.

Systèmes d'automatisation industrielle et intégration — Diagnostics, évaluation des moyens et intégration des applications de maintenance — Partie 2: Descriptions et définitions des éléments de matrice du domaine d'application

General Information

Status
Published
Publication Date
20-Aug-2012
Current Stage
9060 - Close of review
Completion Date
03-Jun-2028
Ref Project
Standard
ISO 18435-2:2012 - Industrial automation systems and integration -- Diagnostics, capability assessment and maintenance applications integration
English language
28 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


INTERNATIONAL ISO
STANDARD 18435-2
First edition
2012-09-01
Industrial automation systems and
integration — Diagnostics, capability
assessment and maintenance
applications integration —
Part 2:
Descriptions and definitions of
application domain matrix elements
Systèmes d’automatisation industrielle et intégration — Diagnostics,
évaluation des moyens et intégration des applications de
maintenance —
Partie 2: Descriptions et définitions des éléments de matrice du
domaine d’application
Reference number
©
ISO 2012
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO’s
member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2012 – All rights reserved

Contents Page
Foreword .iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 Overview of application interaction matrix element (AIME) and application domain matrix
element (ADME) . 2
5.1 Concept of AIME and ADME . 2
5.2 Information exchanges between resources . 4
6 Application interaction matrix element (AIME) . 4
6.1 AIME concept . 4
6.2 AIME formal structure . 5
6.3 Graphical representation of the AIME . 6
6.4 Purpose of AIME in an integrated application . 8
7 Application domain matrix element (ADME) . 8
7.1 ADME concept . 8
7.2 ADME structure . 9
8 AIME and ADME construction .14
9 Conformance and compliance .16
9.1 Conformance aspects .16
9.2 Compliance aspects .16
Annex A (normative) Formal ADME/AIME schema .17
Annex B (informative) Information exchange example .23
Bibliography .28
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 18435-2 was prepared by Technical Committee ISO/TC 184, Automation systems and integration,
Subcommittee SC 5, Interoperability, integration, and architectures for enterprise systems and automation
applications.
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
The following part is under preparation:
— Part 3: Applications integration description method
iv © ISO 2012 – All rights reserved

Introduction
The relationship between the different parts of ISO 18435 is illustrated in Figure 1. The focus of each part is
indicated by dotted lines that bound specific portions of the unified modeling language (UML) class diagram
representing the integration model for an application and between applications.
ISO ISO 18435-3
ADME (ISO 18435-2)
18435-1
•Application •Application
1.*
•Process
1.*
•Resource
1.*
•Activities 1.*
•Information Exchange
AIME (ISO 18435-2)
Figure 1 — Relationship between the different parts of ISO 18435
ISO 18435-1 provides an overview of the elements 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. The focus is on the
production operations and maintenance operations domains, including the capability assessment activities.
This part of ISO 18435 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 that can be supported by a specific combination of a set of AIMEs are described.
ISO 18435-3 defines a recommended method to describe the interoperability and integration requirements
between applications in two or more automation domains within an enterprise. The focus is on the production
operations and maintenance operations domains, including the capability assessment activities.
INTERNATIONAL STANDARD ISO 18435-2:2012(E)
Industrial automation systems and integration — Diagnostics,
capability assessment and maintenance applications
integration —
Part 2:
Descriptions and definitions of application domain matrix
elements
1 Scope
This part of ISO 18435 defines the structures and templates for
— an application interaction matrix element;
— an application domain matrix element.
This part of ISO 18435 also defines the relationship between these types of elements.
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 18435-1, Industrial automation systems and integration — Diagnostics, capability assessment and
maintenance applications integration — Part 1: Overview and general requirements
ISO 15745-1, Industrial automation systems and integration — Open systems application integration
framework — Part 1: Generic reference description
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 18435-1 and the following apply.
3.1
application domain matrix
matrix depicting application domains
3.2
application domain matrix element
ADME
entry in an application domain matrix to organize information exchange among applications
3.3
application interaction matrix
AIM
matrix depicting information exchange among resources
3.4
application interaction matrix element
AIME
entry in application interaction matrix to denote the capabilities of the resource to support information exchange
3.5
application interoperability profile
AIP
single specification referencing a group of profiles that reference parts of base specifications which may
themselves be profiles
NOTE The group of profiles can include process profile(s), information exchange profile(s), resource profile(s) and
sometimes other AIPs.
3.6
capability
ability to perform actions, including attributes on qualifications and measures of the ability
NOTE If the software resource type is MSU (manufacturing software unit) as in ISO 16100, then the definition of
capability is the same as defined in ISO 16100-1.
4 Abbreviated terms
ADID Application Domain Integration Diagram
ADME Application Domain Matrix Element
AIM Application Interaction Matrix
AIME Application Interaction Matrix Element
AIP Application Interoperability Profile
CM Condition Monitoring
DA Data Acquisition
DM Data Manipulation
NC Numerical Controller
RC Robot Controller
SD State Detection
UML Unified Modeling Language
XML eXtensible Mark-up Language
5 Overview of application interaction matrix element (AIME) and application domain
matrix element (ADME)
5.1 Concept of AIME and ADME
This part of ISO 18435 provides a detailed definition of AIME and ADME. The general concept of an ADME
is to model the information exchanges between applications as shown in Figure 2 using the application
interoperability profile notation that shall be as described in ISO 15745-1.

•ADME
•Application •Application
Figure 2 — Application domain matrix element
2 © ISO 2012 – All rights reserved

The ADME, which shall be as defined in ISO 18435-1, uses a description method for detailing the information
exchanges between the applications. For each application, a set of interfaces shall be described using
the AIME. The AIME enumerates the interface profiles supported by the application and its corresponding
resources as shown in Figure 3.
Integrated Manufacturing
Application
Integration
1.*
Manufacturing
Requirements
Process
Manufacturing
1.*
Resource
Manufacturing
1.*
Activity
Manufacturing
Information Exchange
1.*
Application
Interaction
1.*
Matrix Element
Figure 3 — AIME concept
An AIME enumerates those resource capabilities, including interfaces, as noted in each application
interoperability profile. An application may have one or more AIMEs to support all the information exchanges
involving the application.
The set of AIMEs representing the resource capabilities that meet the information exchange requirements to
support the interoperability of two applications shall comprise a key part of an ADME.
An ADME that qualifies interoperability relationship between two applications noted in Figures 1 and 2 is further
elaborated in Figure 4. The ADME is constructed from interoperability profiles referenced in AIMEs. AIMEs
used for constructing ADME express compatibility of resources to support necessary information exchange
between applications to achieve interoperability.

Integrated  Integrated
Application X  Application Y
1.N 1.M
Resource Resource
1.*
1.*
Process
Process
Information
1.* Information 1.*
Exchange Exchange
1.*
ADME
(X, Y)
1.*
AIME  AIME  1.*
Activities
Activities
Figure 4 — Interoperability of applications
5.2 Information exchanges between resources
The manufacturing resources form an integrated system and enable a process that involves required flows
of material, information and energy. The interoperability of the resources requires the use of compatible
interfaces. These interfaces shall be configured to support characteristics of the flows between the resources.
The integration requirement of realizing the required flows constrains the resource interfaces.
Each flow can be modelled as a detailed UML sequence diagram showing the resources involved. Each
transfer between resources can be associated with a type of interface that is configured and deployed in each
resource participating in the particular transfer.
To support the information flows between the manufacturing resources, the information exchange interfaces
shall be configured in a compatible manner.
The interoperability of the resources is enabled by a set of information exchange interfaces. The number
and the type of interfaces required to support the information exchanges are assumed to be available and
configured appropriately in each resource participating in the information exchanges.
NOTE 1 Media-level interface types for information exchanges are transducer interfaces for physical signal acquisition
and actuation, human-machine interfaces for operator commands and displays, and communications network interfaces
for devices. Content-level interface services handle data type, structure, sequence, timing and semantics of the information
item exchanged.
Each information exchange interface shall be associated with a set of required information handling services,
where each service shall offer a particular grade of service and a specific quality of service. These interfaces
enable the interoperability of the resources whenever information items need to be exchanged in a specified
sequence, timing, throughput, latency, physical extent, fidelity and security.
NOTE 2 Conditions to be supported by the resources can consist of:
— exchanges at, before, after, or during, a certain time, period of time, event, or rate; or
— exchanges at, by, or within, a certain, volume of space, or location.
To support all the information exchanges of all the activities in each manufacturing process, each and every
manufacturing resource participating in the manufacturing process shall provide a required set of interoperability
interfaces. For each resource, the set of interfaces and configuration settings can be denoted in a resource
interoperability profile, as defined in ISO 15745.
6 Application interaction matrix element (AIME)
6.1 AIME concept
In Figure 3, each manufacturing application shall be associated with a set of manufacturing resources that
are deployed to perform a corresponding set of information exchanges. An AIME shall represent a set of
capabilities provided by a set of resources of an application, in order to exchange information with another set
of resources associated with another application.
In an AIME corresponding to a single resource, the set of information items that may be transferred from this resource
to another resource shall be a subset of the information items defined in the application denoted in the AIME.
An interface specified in an AIME may support multiple information item transfers with another resource. These
information transfers may be represented by a UML sequence diagram.
Each information exchange description may include the characteristics of the information being exchanged,
the frequency and the latency of the exchange, the criticality of the exchange and the resources involved. For
instance, an AIME associated with a single resource may specify a list of information exchange descriptions
that the resource is able to perform.
4 © ISO 2012 – All rights reserved

An AIM shall consist of a set of AIMEs to represent the complete set of information exchange requirements
among all the resources in a process, and these AIMEs shall denote the information exchange interfaces
required to coordinate the execution of the process.
An application consisting of a set of processes can be associated with a set of AIMEs specifying the information
exchange capabilities of its resources. These AIMEs denote the capability of an application to conduct
information exchanges with other applications.
6.2 AIME formal structure
6.2.1 General
An AIME represents a capability of an entity acting as a source to convey a set of information items to another
entity acting as a destination. The matrix element corresponds to a particular information flow between two
actors in a UML sequence diagram. The information exchange can also be illustrated in terms of activity
diagrams, as well as state diagrams.
The structure of an AIME shall consist of two parts: a header and a body. The body further consists of a context
section and a conveyance section. Each section may be represented as an XML schema segment.
6.2.2 AIME template header
The AIME template header section defines the attributes in Table 1.
Table 1 — AIME template header attributes
Attribute Description Example
MEidentification AIME identification ISO_AIME
MErevision Revision of the AIME V01.01.01a
MEname Descriptive name of the AIME D.2.2.Ay_D.2.2Az
MEsource Identification of the AIME developer AIMEsrc
MEclassID Identification of the AIME class AIP
MEdate The release data of this version of the 2007-03-29
AIME
MEregistry Registry name for this AIME Industry_specific_registry_name
6.2.3 AIME template context section
The AIME context section defines the attributes in Table 2.
Table 2 — AIME context section
Section Description Example
domainSection Domain ID where the source application Asset_Health_Assessment_domain
is resident
Asset_Health_Assessment_domain
Domain ID where the destination
application is resident
applicationSection Application ID corresponding to the Health_assessment
source application
Prognostics
Application ID corresponding to the
destination application
applicationRelationshipSection Application domain specific context(s) Condition_Monitoring_Context
processSection Process ID associated with the source Current_health_grade_evaluation
Resource
Future_health_grade_evaluation
Process ID associated with the
destination Resource
resourceSection Resource Pack Name PLC01
-  resourcePack Resource name MotionDrive
Available or planned capability profiles CIP_ISO_15745_profile
in the resource
6.2.4 AIME template conveyance section
The AIME conveyance section defines the attributes in Table 3.
Table 3 — AIME conveyance section
Section Description Example
informationType Types of information exchanged CavitationInformationRequest
roleType Enumeration of capabilities exhibited PumpControlRole
by the participant for a particular
CavitationDetectionRole
information exchange
relationshipType Identifies the application role types and CavitationDetection2PumpControl
behaviour
participantType Types of collaborating parties for CavitationDetection
information exchange
channelType Point of information item exchange CIP_FTLD_channel
between participants
6.3 Graphical representation of the AIME
Graphical representations of the AIME are shown in Figures 5, 6 and 7. These figures follow the convention
described in ISO/IEC 29500-2.
6 © ISO 2012 – All rights reserved

Figure 5 - AIME matrix element header and matrix element body
Figure 6 - AIME context section
Figure 7 - AIME conveyance section
The formal AIME template structure shall be as defined in Annex A.
6.4 Purpose of AIME in an integrated application
The purpose of an AIME is to express the information exchange capabilities of the resources in an application.
The AIME can be used to facilitate the task of verifying whether the resources of an application can support
specific information exchanges with a set of particular resources in another application.
7 Application domain matrix element (ADME)
7.1 ADME concept
The purpose of the ADME is to describe the interoperability and integration requirements that are required by
the applications as shown in Figure 8.
8 © ISO 2012 – All rights reserved

Application x Application y
Information Exchange
Information Exchange

Figure 8 — Purpose of the ADME
The ADME supports the information exchange between the applications based upon the capabilities identified
in the AIMEs.
The information exchanges between applications will be described using a path description method. A set
of path descriptions shall be represented by an ADME and corresponding profiles. This description method
distinguishes the source entity, the destination entity, as well as the other attributes of the exchange, such as
constraints, types of exchange and interface type.
The complete set of AIMEs that represents the information exchange requirements for realizing the interoperability
of two applications shall comprise an ADME. As shown in ISO 18435-1:2009, Figure 7, some of the resources
in each application are involved in conducting these information exchanges between the applications. Each
application remains integrated while conducting information exchanges with another application.
7.2 ADME structure
7.2.1 General
The ADME element represents information transfer involving a set of information records, which is defined in
the ADME template between source and destination entity. The contents are organized using a schema which
represents elements in the diagram and relationships.
The structure of an ADME shall consist of two parts: a header and a body. The body further consists of a
context, a conveyance and a content section. Each section may be represented as an XML schema segment.
7.2.2 ADME template header
The ADME header section defines the attributes in Table 4.
Table 4 — ADME template header attributes
Attribute Description Example
MEidentification ADME identification ISO_ADME
MErevision Revision of the ADME V01.01.01a
MEname Descriptive name of the ADME D.2.2.Ay_D.2.2Az
MEsource Identification of the ADME developer ADMEsrc
MEclassID Identification of the ADME class AIP
MEdate The release data of this version of the 2007-03-29
ADME
MEregistry Registry name for this ADME Industry_specific_registry_name
7.2.3 ADME template context section
The ADME context section defines the attributes in Table 5.
Table 5 — ADME template context section
Section Description Example
domainSection Domain ID where the source application Asset_Health_Assessment_domain
is resident
Asset_Health_Assessment_domain
Domain ID where the destination
application is resident
applicationSection Application ID corresponding to the Health_assessment
source application
Prognostics
Application ID corresponding to the
destination application
applicationRelationshipSection Application domain specific context(s) Robot_Control_Context
processSection Process ID associated with the source Current_health_grade_evaluation
Resource
Future_health_grade_evaluation
Process ID associated with the
destination Resource
resourceSection Resource Pack Name PLC01
-  resourcePack Resource name MotionDrive
Available or planned capability profiles CIP_ISO_15745_profile
in the resource
7.2.4 ADME template conveyance section
The ADME conveyance section defines the attributes in Table 6.
10 © ISO 2012 – All rights reserved

Table 6 — ADME template conveyance section
Section Description Example
informationType Types of information exchanged CavitationInformationRequest
roleType Enumeration of capabilities exhibited by PumpControlRole
the participant for information exchange.
CavitationDetectionRole
Behaviour captures the elementary
interactions of the participant by
interface
relationshipType Identifies the role types and behaviors CavitationDetection2PumpControl
participantType Types of collaborating parties for CavitationDetection
information exchange
channelType Describes the medium used to CIP_FTLD_channel
exchange information between two role
types
7.2.4.1 ADME template information exchange section
The ADME information exchange section defines the attributes in Table 7.
Table 7 — ADME template information exchange section
Section Description Example
Name Name of the information exchange SmartPumpInformationExchange
relationship Relationship type for information PumpControl2CavitationDetection
exchange
variableDefinitions definitions for the variables used for DiagRequest
information exchange
CavDetectionResponse
7.2.4.2 ADME template interaction section
The ADME interaction section defines the attributes in Table 8.
Table 8 — ADME template interaction section attributes
Section Description Example
Name Name of the interaction CavitationInformationElicitation
exchange basic unit of information exchange CavitationInformationRequest
interaction
send/receive Send/receive information per action
defined in exchange using variables
7.2.5 Graphical representation of the ADME
Graphical representations of the ADME are shown in Figures 9 to 13. These figures follow the convention
described in ISO/IEC 29500-2. These figures illustrate Tables 5 to 8, and the XML schema in Clause A.2.
Figure 9 – ADME matrix element header and matrix element body
12 © ISO 2012 – All rights reserved

Figure 10 - ADME context section

description
informationType description
1.∞
description
roleType
1.∞
behavior description
Conveyance_Section description
relationshipType
1.∞
roleType
1.∞
description
participantType
1.∞
roleType
channelType description
1.∞
Figure 11 - ADME conveyance section
Figure 12 - ADME content section
Figure 13 - ADME information exchange
The formal ADME template structure shall be as defined in Annex A.
8 AIME and ADME construction
The general procedure for constructing AIME and ADME shall be as follows:
a) define the applications;
b) allocate to the domain integration diagram – retrieving/assigning domain numbers to ADID;
c) identify the assets and resources, then allocate them to the applications;
d) define the information exchanges;
e) identify the interfaces required in terms of ISO 15745 templates to reference the corresponding profile;
f) fill out the AIMEs for each application being described;
g) use AIMEs to construct ADMEs that capture the interoperability requirements between the applications.
EXAMPLE In Figure 14, in order to identify the necessary AIME(s) for integrating the applications, the resources
involved for the integration are classified into two groups: the resource which executes the application and the resource
which is maintained or operated by the application. The rest of the resources are not considered. Once the resources are
classified and the roles and participation identified, the applications are associated with these two groups of resources.
14 © ISO 2012 – All rights reserved

Figure 14 illustrates how to identify necessary AIMEs and ADMEs for a particular integration scenario. This example
shows the interaction among data acquisition (DA), data manipulation (DM) and state detection (SD) application as defined
in ISO 13374.
level R4
enterprise
Resources execung applicaons
level comp.
RC Robot controller
level R3
production
capability
NC Numerical controller
mgmt. comp.
assessment
RC/NC monitoring
CM
(condion monitoring)
level R2
supervisory asset
controller prognosis
Resources operated/maintained
level R1
RC/NC
RC NC
RT Robot tool
monitoring
MT Machine tool
level R0
RT MT
Figure 14 —Integration scenario example
The necessary ADMEs are marked by an “X” in Table 9. In this integration scenario, three different types of applications
are identified (DA, DM and SD, in accordance with ISO 13374) and three different types of relevant resources are identified
[robot controller (RC), numerical controller (NC) and condition monitoring (CM)]. In this integration scenario, there are four
ADMEs altogether, i.e. one ADME is necessary for each of the following:
— DA being executed on RC to DM being executed on CM;
— DM being executed on RC to SD being executed on CM;
— DA being executed on NC to DM being executed on CM;
— DM being executed on NC to SD being executed on CM.
Table 9 illustrates the information flow from row (source) to column (destination). For example, the levels R0 to R4 in
Figure 14 are related to the ADID diagram of ISO 18435-1:2009, Figure 5.
Table 9 — Necessary ADMEs for the integration
Resource destination RC NC CM
source Application DA DM SD DA DM SD DM SD
DA   X
RC DM    X
SD
DA   X
NC DM    X
SD
DM
CM
SD
The necessary sets of AIMEs for this integration scenario are marked by an “X” in Table 10. One set of AIMEs is necessary
for the resource RC to CM and the other set for the resource NC to CM. Examples of the AIMEs and the ADME for the RC
to CM application are included in Annex B.
Table 10 — Necessary AIMEs for the integration
Resource RC NC CM
RC X
NC X
CM
9 Conformance and compliance
9.1 Conformance aspects
Conformance with this part of ISO 18435 shall be stated by implementation providers in accordance with the
following guidelines:
a) a conformance statement shall declare which clauses in this part of ISO 18435 are referenced in a
particular implementation;
b) when several clauses in this part need to be implemented as a group, these set of clauses shall be
referenced as a group in a particular implementation;
c) certain diagrams in this part of ISO 18435 that have been constructed in accordance with UML conventions
shall be part of a conformance statement, as needed.
9.2 Compliance aspects
Compliance with this part of ISO 18435 shall be stated by specification providers in accordance with the
following guidelines:
a) the purpose of a compliance statement shall be to declare which clauses in this part of ISO 18435 are
referenced in a particular specification;
b) when several clauses in this part need to be referenced as a group, these set of clauses shall be referenced
as a group in a particular specification;
c) certain diagrams in this part of ISO 18435 that have been constructed in accordance with UML conventions
shall be part of a compliance statement, as needed.
16 © ISO 2012 – All rights reserved

Annex A
(normative)
Formal ADME/AIME schema
A.1 AIME schema
The formal definition of AIME is as follows:

www.iso.org/aime” xmlns=”http://www.w3.org/2001/XMLSchema”>































































































































18 © ISO 2012 – All rights reserved




































A.2 ADME schema
The formal definition of ADME is as follows:

www.iso.org/adme” xmlns=”http://www.w3.org/2001/XMLSchema”>







































































































20 © ISO 2012 – All rights reserved
...

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...