ISO/TS 18876-1:2003

TECHNICAL ISO/TS
SPECIFICATION 18876-1
First edition
2003-11-01
Industrial automation systems and
integration — Integration of industrial
data for exchange, access and sharing —
Part 1:
Architecture overview and description
Systèmes d'automatisation industrielle et intégration — Intégration des
données industrielles pour l'échange, l'accès et le partage —
Partie 1: Vue d'ensemble et description de l'architecture

Reference number
©
ISO 2003
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 2003
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 2003 – All rights reserved

Contents Page
1 Scope . 1
2 Normative references . 2
3 Terms, definitions, and abbreviations . 2
3.1 Terms and definitions. 2
3.2 Abbreviations . 5
4 Organization of ISO 18876 . 5
5 Fundamental concepts and assumptions. 6
5.1 Integration models. 6
5.1.1 Principles . 6
5.1.2 Scope and context. 7
5.1.3 Integration model concepts. 10
5.1.4 A full integration model. 11
5.2 Mapping specifications. 12
6 Overview of the model integration process. 12
7 Integration architecture components . 16
8 Data mapping and consolidation . 17
9 Relationship to other standards . 18
Annex A (normative) Information object registration. 19
Bibliography. 20
Index. 21
Figures
Figure 1 — Model integration. 6
Figure 2 — Integration into more than one integration model. 7
Figure 3 — A limited integration model . 8
Figure 4 — Integrating an application model and a limited integration model. 8
Figure 5 — Using an integration model with a wide model context. 9
Figure 6 — Integrating additional application models . 9
Figure 7 — Primitive Concepts. 11
Figure 8 — A full integration model. 11
Figure 9 — Integrating application models with an integration model. 13
Figure 10 — Analyzing the application models. 14
Figure 11 — Adding any missing concepts to the integration model . 14
Figure 12 — Identifying the subset of the integration model. 15
Figure 13 — Creating the mapping specification between the integration model subset and the application
model. 15
Figure 14 — Integration architecture components . 16
Figure 15 — Data consolidation. 17

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.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of normative document:
— an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
— an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee
casting a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for a
further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is
confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an
International Standard or be withdrawn.
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/TS 18876-1 was prepared by Technical Committee ISO/TC 184, Industrial automation systems and
integration, Subcommittee SC 4, Industrial data.
This International Standard is organized as a series of parts, each published separately. The structure of this
International Standard is described in this part of ISO 18876.
iv © ISO 2003 – All rights reserved

0 Introduction
0.1 Overview of ISO 18876
This International Standard establishes an architecture, a methodology, and other specifications for integrating
industrial data for exchange, access, and sharing. It supports:
— data sharing and data integration;
— specification of mappings between models; and
— data transformation.
0.2 Organization of this part of ISO 18876
This part of ISO 18876 is organized as follows:
— Clause 1 specifies the scope and field of application of the International Standard and of this part of
ISO 18876;
— Clause 2 identifies additional standards that, through references in this part of ISO 18876, constitute provi-
sions of this part of ISO 18876;
— Clause 3 defines terms and abbreviations used in this part of ISO 18876;
— Clause 4 describes the organization of this International Standard;
— Clause 5 describes the fundamental concepts and assumptions on which this International Standard is based;
— Clause 6 provides an overview of the model integration process;
— Clause 7 identifies some components of the integration architecture;
— Clause 8 provides an overview of the processes of data mapping and consolidation;
— Clause 9 summarizes the relationships with other standards.
0.3 Target audiences
The target audiences for this part of ISO 18876 are as follows:
— technical managers wishing to determine whether ISO 18876 is appropriate for their business needs;
— implementers wishing to obtain an overview of its contents.

TECHNICAL SPECIFICATION ISO/TS 18876-1:2003(E)
Industrial automation systems and integration —
Integration of industrial data for exchange, access and
sharing —
Part 1:
Architecture overview and description
1 Scope
This Technical Specification establishes an architecture, a methodology, and other specifications for integrating
industrial data for exchange, access, and sharing. The following activities are supported:
— integrating data which may be:
— from different sources or different contexts,
— described by different models, or
— defined in different modelling languages;
— sharing data among applications through systems integration architectures;
— resolving conflict between models developed with different objectives;
— translating data between different encodings;
— translating models between different modelling languages.
The following are within the scope of ISO 18876:
— integration models;
— methods for creating, extending, and updating integration models;
— methods for creating a mapping specification to map data instances between an integration model and an
application model that falls within its scope;
— encoding and decoding of data and models with different formats, such as SGML [1], XML [7], EXPRESS
[3], UML [6] and ISO 10303-21 [4];
— methods for consolidating data sets from different sources and different models;
— modelling and mapping specification languages.
The following is within the scope of this part of ISO 18876:
— the architecture and an outline of the methodology.
The following are outside the scope of this part of ISO 18876:
— integration models;
— detailed specifications of the methodology;
NOTE Such specifications can be found in other parts of ISO 18876 or in other standards.
— translating data between different encodings;
— encoding and decoding of data and models with different formats;
— modelling and mapping specification languages.
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.
1)
ISO/IEC 8824-1:— , Information technology — Abstract Syntax Notation One (ASN.1) — Part 1: Specification
of basic notation
ISO 10303-1:1994, Industrial automation systems and integration — Product data representation and exchange —
Part 1: Overview and fundamental principles
3 Terms, definitions, and abbreviations
3.1 Terms and definitions
For the purposes of this document, the following terms, definitions and abbreviations apply; those taken from
ISO 10303-1 are repeated below for convenience.
NOTE 1 Definitions copied verbatim from other standards are followed by a reference to the standard in brackets, such
as “[ISO 10303-1]”. In these cases the definition in the referenced document is normative; its repetition here is informative
and in the case of any discrepancy the definition in the referenced document has precedence. An explanatory note follows
definitions that have been adapted from other standards. In these cases, the definition given here is normative for the pur-
poses of this part of ISO 18876.
3.1.1
application model (AM)
model that represents information used for some particular purpose
NOTE Some application models are also integration models (see 3.1.12).
3.1.2
class
category or division of things

1)
To be published. (Revision of ISO/IEC 8824-1:1998)
2 © ISO 2003 – All rights reserved

NOTE There are a number of ways that class can be defined. This definition is intended to be as broad as possible, and
is broader than that used in ISO 15926-2.
EXAMPLE Pump, power station, engineer, and fictional space vehicle are examples of classes.
3.1.3
concept
general notion or idea of something
3.1.4
data
representation of information in a formal manner suitable for communication, interpretation, or processing by
human beings or computers
[ISO 10303-1]
3.1.5
data model
set of constructs that provides the definition, structure, and format of data, whether physical or abstract in the
sense of being bound to some recording medium
3.1.6
derived concept
concept in an integration model that is wholly defined in terms of primitive concepts
3.1.7
encoding transformation
transformation of the way data elements are represented for computer processing
EXAMPLE Conversion of data governed by an EXPRESS schema from an ISO 10303-21 file to an XML document is an
example of an encoding transformation.
3.1.8
foundation concept
primitive concept that determines the underlying world viewpoint of an integration model
NOTE There can be a number of integration models. Each will have its own modelling paradigm which is characterised
by the foundation concepts that it contains.
EXAMPLE The concepts of class and individual are foundation concepts for a general integration model.
3.1.9
general concept
primitive concept that has very wide applicability, but is a specialization of some foundation concept
NOTE A concept may be considered to be a foundation concept by one community, while it is considered to be a gen-
eral concept by another.
3.1.10
individual
thing that exists in space and time
NOTE This includes things that actually exist, or have existed, and things that possibly exist (past, present, and future)
in space and time.
EXAMPLE The pump with serial number ABC123, Battersea Power Station, Sir Joseph Whitworth, and the Starship
“Enterprise” are examples of individuals.
3.1.11
information
facts, concepts, or instructions
[ISO 10303-1]
3.1.12
integration
activity that creates, modifies, or extends an integration model
3.1.13
integration model (IM)
application model that can represent the information that is represented by two or more application models
NOTE Being an integration model is about the role one model plays with respect to one or more application models.
3.1.14
mapping
correspondence between instances of one model and instances of another model that represent the same mean-
ing
NOTE A mapping can be uni-directional or bi-directional.
3.1.15 mapping specification
definition of the transformations necessary to take information according to one data model and represent the
same information according to another data model
NOTE 1 A mapping specification can include data structure transformations, data value transformations, data encoding
transformations, and terminology transformations.
NOTE 2 Mapping specifications can be procedural, or declarative, or a combination of these.
3.1.16
model
limited information representation of something suitable for some purpose
3.1.17
model context
sum of implicit concepts and constraints that limit the possible extension of a model without changing any exist-
ing declarations
NOTE 1 The model context is therefore the class of all possible extensions to a model.
NOTE 2 This term is more general than application context as defined in ISO 10303-1.
3.1.18
model scope
range of information that an application model can describe
3.1.19
primitive concept
concept in an integration model that is not wholly defined in terms of other concepts
3.1.20
specific concept
primitive concept that is a specialization of some general concept and has a limited range of applicability
EXAMPLE Car, process plant, quark, purchase order, and XML document are examples of specific concepts.
4 © ISO 2003 – All rights reserved

NOTE The boundary between a general concept and a specific concept may be arbitrary; some concepts may be thought
of as both general concepts and specific concepts.
3.1.21
structural transformation
type of mapping specification that is a transformation to the structure of data
NOTE The change in structure could be due to the rearranging of attributes, the splitting of attributes across entity types,
or the creation of new attributes.
3.1.22
terminology transformation
transformation of the term used to refer to a thing
NOTE This could be between synonyms in one language, or between different languages.
3.1.23
transformation
change of form
3.1.24
view
constrained representation of a data model
3.2 Abbreviations
For the purposes of this part of ISO 18876, the following abbreviations apply:
AM application model
NOTE In ISO 10303 the abbreviation AM is used for Application Module. An Application Module is not the same as an
Application Model.
IM integration model
4 Organization of ISO 18876
ISO 18876 is divided into a number of parts.
ISO/TS 18876-1, this part, provides an overview and specifies an architecture for the integration of industrial data.
ISO/TS 18876-2 specifies methods for integrating application models and for developing and extending integration
models.
NOTE Other specifications may be developed to extend the capability of ISO 18876, such as:
— models designed to integrate two or more other models;
— models designed to meet the needs of a particular application;
— mapping specifications designed to specify how a data population of one model may be migrated to another model;
— mapping specifications designed to specify how a model in one language may be migrated to another language;
— methods and languages to support the definition of models and mapping specificatios between different modelling lan-
guages;
— methods and specifications for the encoding of models and transformation between encodings;
— the specification of services and interfaces to be provided by conforming implementations.
5 Fundamental concepts and assumptions
The following fundamental concepts and assumptions apply to this Technical Specification.
5.1 Integration models
5.1.1 Principles
The three-schema architecture for data models shows that for any data model it is possible to construct views on
the original model.
NOTE 1 The three schema architecture is described in ISO/TR 9007 [2].
In this Technical Specification this principle is extended to cover other types of model and modelling languages.
In the integration of models this process is reversed: a model is created for which the initial models are views. A
model created in this way is an integration model with respect to the initial models in that it is capable of repre-
senting information with the scope of either or both of the original models. This is illustrated in Figure 1 below.
Integration Model
Integration Model Integration Model
1 2
Application Application Application Application Application Application
Model Model Model Model Model Model
1 2 6 3 4 5
Figure 1 — Model integration
An integration model can be created if a common understanding of the application models to be integrated can
be established.
NOTE 2 This has been shown by Barwise and Seligman [9].
NOTE 3 Difficulties in creating such a model point to a gap in human knowledge about the subject of the application
models.
There may be more than one integration model to which an application model can be integrated, where the inte-
gration models support different ways of looking at the world. See Figure 2 below.
6 © ISO 2003 – All rights reserved

Integration Model Integration Model
1 2
Application Application Application Application
Model Model Model Model
1 2 3 4
Figure 2 — Integration into more than one integration model
Models that have been created as integration models can themselves be integrated. This means that any arbitrary
set of models can, in principle, be integrated at the cost of creating a new model; this is supported by the archi-
tecture defined in this Technical Specification.
NOTE 4 One possible use for the architecture defined here is the development of an integration model that is stable in
the face of the integration of additional models. Here stable means that the existing integration model does not need to be
changed as more models are integrated, though extensions of the integration model may be necessary.
Integration models sometimes represent concepts that are more generic than the models they integrate. This is
necessarily the case when the models being integrated have conflicting constraints affecting the information that
is to be represented. These constraints should be preserved by the integration process, and held in some form
other than in the structure of the integration model.
NOTE 5 The constraints can be held in the mapping specification or as data within the integration model.
5.1.2 Scope and context
The scope of a model is what the model actually covers. The context of a model is the sum of constraints that
limit the ability to extend the scope of the model without changing any existing declarations. These constraints
include:
— activities that produce or use the data;
— organizations that produce or use the data;
— concepts that the model is “about” but that are not explicitly represented in the model;
— constraints inherent in the structure of the model.
Integration models can be created that consider two or more application models of interest – the scope and con-
text of such an integration model can be no smaller than the combined scope and context of the application
models being integrated. The relationship between such an integration model and the other application models
that it integrates is shown in Figure 3 below.
Scope and context of
Integration Model
integration model cover
only the combined
scope and context of
the application models
Application Application
Model Model
1 2
Figure 3 — A limited integration model
If requirements subsequently emerge to integrate additional application models with Application Model and
Application Model (and hence with Integration Model ) it is unlikely that the context of these further models
2 1
will fit within that of Integration Model . This implies that Integration Model cannot support the information
1 1
represented by the further application models, and will itself have to be integrated with another integration
model (created for this purpose or selected from candidate integration models). This is shown in Figure 4 be-
low.
Scope and context of
integration model covers
Integration Model
only the combined scope
and context of Integration
Model and Application
Model
Application
Integration Model
Model
Application Application
Model Model
1 2
Figure 4 — Integrating an application model and a limited integration model
However, the initial integration model (IM) can be chosen to have a wide model context. This means that it can
support the information needs of many different applications, even though its initial model scope is limited to
that of the models that it integrates, as shown in Figure 5 below. A potential integration model can be tested by
looking at the statements it makes and checking that these statements are true under all circumstances, not just
in a particular context. Whilst this will make it less likely that a
...