See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/249630419

ISO 15926 vs. IEC 62424 - Comparison of plant

structure modeling concepts

Conference Paper September 2012

DOI: 10.1109/ETFA.2012.6489662

CITATIONS READS

9 717

4 authors, including:

Thomas Holm Lars Christiansen

WAGO Kontakttechnik GmbH & Co. KG Evonik Industries
23 PUBLICATIONS 42 CITATIONS 22 PUBLICATIONS 86 CITATIONS

SEE PROFILE SEE PROFILE

Alexander Fay
Helmut Schmidt University
278 PUBLICATIONS 1,071 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Produktion Automation View project

Formal methods and software specification View project

All content following this page was uploaded by Lars Christiansen on 07 February 2014.

The user has requested enhancement of the downloaded file.

 ISO 15926 vs. IEC 62424
Comparison of Plant Structure Modeling Concepts
Thomas Holm1, Lars Christiansen1, Markus Gring1, Tobias Jger2, Alexander Fay1
1 2
Helmut Schmidt University, Hamburg
Department of Mechanical Engineering
Institute of Automation Technology
thomas.holm@hsu-hh.de
lars.christiansen@hsu-hh.de
markus.goering@hsu-hh.de
alexander.fay@hsu-hh.de
Abstract
In the domain of process automation there exist two
upcoming standards for the modeling of plant data,
namely ISO 15926 and IEC 62424 (CAEX). Both
standards objective is to describe the plant over the
whole lifecycle. Within this contribution both standards
will be compared. By using an example application of
the automation domain, i.e. a belt conveyor, the appli-
cation of both standards will be shown exemplarily.
Applying a list of criteria, both standards will be com-
pared in order to identify strengths and weaknesses.
1. Introduction
Within the engineering of automated plants, the ex-
change of planning data becomes more and more im-
portant. This addresses the exchange between different
tools, disciplines involved in the different engineering
phases and also the plant lifecycle. Consensus exists
that an efficient exchange is one lever to improve the
engineering, as well as the plant operation [1].
For this reason, different approaches in standardiza-
tion of useful meta-modeling concepts exist, which
enable such an exchange. ISO 15926 [2] is the standard
driven by the oil and gas industry. This ontological
approach aims for an overall lifecycle description.
Another approach, driven by automation, is IEC
62424 (Computer Aided Engineering eXchange -
CAEX) [3]. This standard defines a meta-model for
describing plant data. Based on the standard, the data
exchange format is utilized for AutomationML [4] in
the domain of production automation, as well as for
PandIX in the domain of process automation [5].
De facto, there exist two overall approaches beside
each other. This contradicts the given idea of a com-
plete and open exchange. In consequence, this paper
approaches a first general comparison of both upcom-
ing standards. A more comprehensive understanding is
978-1-4673-4737-2/12/$31.00 2012 IEEE
Siemens AG, Erlangen
CT SYE EMT-DE
Corporate Technology
jaeger.tobias@siemens.com
supported by a modeling example. The differences
between both meta-models can be shown by a compar-
ison, but an example is useful for the understanding.
The paper is structured as follows: section 2 points
out the concepts and mechanisms of the ISO 15926
standard. The concepts of the IEC 62424 standard are
described in section 3 of this paper, followed by a
qualitative comparison of both data models with re-
spect to an example in section 4. Section 5 summarizes
the results and gives an outlook about future directions
of both standards and next possible investigation steps.
2. ISO 15926
ISO 15926 is an international standard for the repre-
sentation and the exchange of life-cycle data of indus-
trial plants [2]. Although the title of the standard refers
to the oil and gas industry, the standard establishes
general concepts and thus, is applicable to various
domains. Table I lists the six parts of ISO 15926.
Table I. Parts of ISO 15926
Part 1 Overview and fundamental principles
Part 2 Data model
Part 3 Reference data for geometry and topology
Part 4 Initial reference data
Part 7 Implementation methods for the integration of
distributed systems: Template methodology
Part 8 Implementation methods for the integration of
distributed systems: Web Ontology Language
(OWL) implementation
The representation and the exchange of life-cycle
data is based on the generic data model introduced in
the second part of ISO 15926, which establishes differ-
ent basic entity types and their connections. The gener-
ic data model concepts are valid for industrial plants in
general and therefore the generic data model is associ-
ated with an upper ontology [6].

Fig. 1. ISO 15926 architecture [2]
In contrast the generality of the ISO 15926-2 data
model does not allow the representation of data about
an individual plant solely based on the entity types.
Instead, as it is shown in Fig. 1, the framework for the
modeling based on the entity types of the generic data
model is supplemented by reference data, which pro-
vides detailed information about the different plant
objects e.g. pipes and valves. The reference data com-
prise classes describing the plant objects and are orga-
nized in the reference data library (RDL). Within the
third and fourth part of ISO 15926 the reference data
are standardized, but because reference data are never
(and will never be) complete, they are work in pro-
gress. The present RDL is accessible via the reference
data services (RDS) [7], which constitute in the present
design part three and four of ISO 15926 and additional
reference data created by authorized users.
2.1. 4D-approach representation of life-cycle data
Throughout the life-cycle of industrial plants, from
the initial engineering phases to the decommissioning,
industrial plants are not static and different changes
have to be considered. These changes for example
comprise the plant development throughout the engi-
neering (ideas change into functional requirements,
followed by physical implementation), changes as a
consequence of maintenance activities (e.g. exchange
of a motor) or temporally limited changes due to fail-
ures. For this reason, ISO 15926 implements the four
dimensional (4D) approach for the representation of
life-cycle data [8].
The 4D-approach considers objects existing in three
dimensional space and time (it is also known as
perdurantism). Consequently objects comprise spatial
parts on the one hand and temporal parts on the other
hand. The spatial parts arise in the fact that e.g. a belt
conveyor comprises a belt and a motor. The temporal
parts are demonstrated e.g. by the change of a belt
conveyors usage in a plant A to its replacement for
maintenance purposes.
An example is given in Fig. 2, which utilizes the
space-time map according to ISO 15926 (three dimen-
sional (3D) space is mapped versus time in order to
represent an objects 4D extension; changes of the
Fig. 2. Example of the 4D-approach
spatial extension are indicated by the vertical axis,
whereas temporal changes are indicated by the hori-
zontal axis). Fig. 2 shows the three dimensional exten-
sion of a belt conveyor changing over time. In relation
to time, the belt conveyor consists of three different
temporal parts, i.e. its storage, its usage in plant A, and
its maintenance. The temporal part of storage is fol-
lowed by the usage in plant A (this temporal part is
highlighted to support understandability of the tem-
poral parts concept), which is followed by a removal
for maintenance purposes at some point in time. The
transitions between the temporal parts are shown as
diagonal beams.
The 4D approach implemented in ISO 15926 is
suitable for the representation of life-cycle data. It is
not only applicable to model the change of single ob-
jects, but can also be applied to model the temporal
change of several objects [9].
2.2. Generic Data Model ISO 15926-2
An excerpt of the generic data model showing some
of the basic entity types of ISO 15926 is given in Fig.
3. ISO 15926-2 consists of more than 200 entity types,
but this paper concentrates on the most basic entity
types relevant for the application in section 4. The
entity types are hierarchically ordered using subtype
and supertype specialization relationships.
At the top of the data model the abstract entity type
thing represents everything associated with the data
Fig. 3. Excerpt of the ISO 15926 generic data model
model. A Thing is specialized into the two subtypes:
PossibleIndividual and AbstractObject.
The entity type PossibleIndividual (PI) is required
for the representation of industrial plant data, because
it is a thing that exists in space and time. This includes
e.g. ideas, requirements, activities, and physical
objects. The universal definition of PI is specialized
with its subtypes, at which the specialization is related
to space, time, or a combination of both. An Event for
example has zero extent in time (it has the subtype
PointInTime), whereas the PeriodInTime is all space
for part of time. An Activity is defined as the cause of
an Event and results in change. The WholeLife-
Individual models objects existing in the past, present
and future, whereas the ActucalIndividual is
characterized by the existence in the universe that we
inhabit. The entity type of ArrangedIndividual defines
objects as being a composition of parts with specific
roles. An PhysicalObject defines a PI that is a
distribution of matter, energy or both. Its subtype
FunctionalPhysicalObject determines PhysicalObjects
by their function, whereas Materialized-
PhysicalObjects are identified by matter.
In contrast, the entity type AbstractObject is defined
as a thing that does not exist in space-time. Therefore,
AbstractObject models classification and relationships
between PIs. At this, ISO 15926-2 implements a
comprehensive classification schema. Relevant for this
paper is the subtype ClassOfIndividual of Class, which
is used for the classification of instances of PI.
Instances of ClassOfIndividual are part of the RDL.
The relevant Relationships for structural modelling
are shown in Fig. 4. In the focus of this paper is the
modelling of mereology, i.e. part-whole relationships
and topology, i.e. topological relations between
distributed objects. The modelling of mereology is
based on the entity type CompositionOfIndividual
modelling part-whole relationships between PIs. Its
subtype, i.e. Temporal-WholePart, implements the 4D
approach and models the temporal part-whole
relationships between objects. Furthermore,
TemporalBounding and its subtype Beginning connect
Fig. 4. Relationships of ISO 15926-2 relevant
for the application in section 4
an Event to a PI. Topology uses the two subtypes
DirectConnection and Indirect-Connection of
ConnectionOfIndividual. Direct-Connection models
the direct connection of PIs, whereas Indirect-
Connection models indirect connections between PIs,
i.e. there exist other PIs in between the indirectly
connected PIs and therefore dependencies are modeled.
3. IEC 62424 - Computer Aided Engineer-
ing eXchange (CAEX)
The standard IEC 62424 Representation of process
control engineering - Requests in P&I diagrams and
data exchange between P&ID tools and PCE-CAE
tools [3] defines a neutral data format for the ex-
change of plant information between heterogeneous
CAE-tools. Therefore, CAEX defines data types and
elements as well as structures for defining objects with
specific attributes and offers concepts for modelling
relations between those elements. Furthermore, CAEX
is the basis for a vendor-independent data exchange
format between the vendor-specific tool landscapes
within the engineering process, especially between
tools for creating P&IDs.
3.1. Basic concepts
The P&ID contains useful information for the engi-
neering process of automated systems in the process
industry. It comprises a defined number of elements,
describes the functional structure of the process run-
ning in the plant by graphical objects and the connec-
tions between them. The graphical objects themselves
do not represent the technical realization of the planned
resources, but rather describe the functions which
should be implemented by a resource. The objects
possess interfaces in order to connect them on the one
hand with the process control system and on the other
hand with plant objects like vessels and valves. The
single elements are combined to plant units, the units
can be combined to upper units, and altogether the
hierarchical structure of the plant is represented.
CAEX defines three types of classes and one con-
tainer-object representing the instance of the auto-
mated system. CAEX uses object-oriented concepts
like inheritance and class-instance-relation. The differ-
ent classes are stored in Libraries which are SystemU-
nitClass, RoleClass and InterfaceClass. The libraries
are shown in the left part of Fig. 5, complemented by
exemplary classes in the right part of Fig. 5.
The RoleClassLibrary contains RoleClasses. A role
models a function of an object that the technical im-
plementation has to fulfil. As an example, a resource
has to transport a good from point A to point B. The
function transport liquid can be realized by different
pumps like displacement pumps or flow pumps. Due to
the fact that the P&ID describes the functional struc-

Fig. 5. Generic CAEX Concept
ture of the process by graphical representations and
their internal connections, the graphical elements
solely represents the functions of the technical imple-
mentation and can be seen as a placeholder. This
placeholder will be filled by the specific plant object,
but the function will still remain transport. Further-
more, roles are important for the correct semantic in-
terpretation of objects after the exchange process in the
target CAE system.
The InterfaceClassLibrary comprises different types
of interfaces for modelling the signal and information
flow between resources and the processes control sys-
tem and mechanical connections like flanges for con-
necting pipes and plant item for e.g. the product flow.
The SystemUnitClassLibrary (SUC-Library) con-
tains physical or logical plant objects and units from
which InternalElements (=instances) are being instan-
tiated. SystemUnits can be seen as an aggregation of
single plant objects, which are internally connected by
their interfaces by InternalLinks. CAEX does not de-
fine general or specific SystemUnitClasses. SUCs rep-
resent vendor- and project-specific classes for model-
ling the hierarchical structure of the specific plant in
the InstanceHierarchy. This type represents the auto-
mated plant with all its components as well as the func-
tional view. Each InternalElement which represents a
logical object of the plant e.g. item or function needs to
be referenced to a RoleClass in order to avoid inconsis-
tencies during the exchange and interpretation process.
3.2. Modelling Concepts based on CAEX
3.2.1. AutomationML
The aim of the neutral data format Automa-
tionML [4] is the storage and exchange of complex
engineering data within planning phases to bridge the
gap between separate and phase-specific CAE-Tools
within the engineering process. AutomationML is
currently in the standardization process.
So far, AutomationML proposes four parts which
are partly normative and informative. The difference
between the normative and informative parts is that the
informative parts contain e.g. discipline-specific defini-
tion of classes and can be easily implemented or ex-
tended without having an additional standardization
process. The first part of AutomationML describes the
architecture and general requirements for modelling
and exchanging plant information with CAEX. The
second part [10] defines different libraries of Role-
Classes and InterfacesClasses. Part three and four give
information about referencing geometry and kinematic
information as well as logical information by the inte-
gration of other (external) exchange formats like
COLLADA and PLCopenXML. Both, part three and
four, are not subject to this work and are not described
in more detail.
For the exchange process and subsequent interpreta-
tion in the target system it is important that the data
and information in the model are correctly interpreted.
Therefore, Part II of AutomationML defines different
RoleClasses to avoid misinterpretations. Part II is com-
posed of three categories: normative, informative and
informative user defined examples.
The normative RoleClasses are divided into general
base-RoleClasses and domain-specific-RoleClasses.
Base-RoleClasses contain general base roles for model-
ling different abstract functions like product, process
and resource resulting from the three-view concept of
the digital factory. With these general roles a rough
structural differentiation of the plant is possible. Be-
sides the base roles there are other domain-specific role
classes for defining functions in the field of manufac-
turing industry, process industry, control and commu-
nication equipment as well as mechatronic aspects.
Every additional user-, project- or application-
specific RoleClass must be inherited from one of the
mentioned Base-RoleClass to avoid misinterpretations.
3.2.2. PandIX
For the modelling of process-specific aspects in an
automated system with CAEX the data model PandIX
[5] can be used. PandIX offers a model specification to
capture the piping and instrumentation structure of a
process plant. Essentially, PandIX offers the possibility
to describe the existing relationships between objects
in a P&ID. This enables a computer-based processing
of data and information in the engineering process.
PandIX does not claim to model other aspects and
relations like design of components, chemical or physi-
cal reactions and balances. On the one hand it proposes
how to model structural aspects of process control tags.
On the other hand it provides a library for modelling
Fig. 6. Concept of PandIX
causal as well as spatial relations inside the plant based
on CAEX.
4. Application of ISO 15926 and CAEX
This section presents the comparative application of
the data models, based on their introduction in the
former two sections, followed by the qualitative com-
parison. The application is constituted by a conveyor as
a mechatronic system for moving material or articles
from place A to place B. The conveyor is specified as a
belt conveyor, which uses an endless belt arranged on
two rollers. The drive of the belt conveyor comprises
an electric motor, which mechanical power is transmit-
ted via a transmission to the belt. The indication of the
presence of material or articles on the belt is imple-
mented by two electronic sensors, so that the event of
entry or exit of material or articles is detectable. This
application example is generally valid, because it con-
tains different plant objects and their relationships,
Fig. 7. Representation of the belt conveyor utilizing ISO 15926
which can be found in every industrial, e.g. process or
manufacturing plant.
4.1. Representation of the belt conveyor utilizing
the data model of ISO 15926
The representation of the ISO 15926 data model can
either be based on the Web Ontology Language
(OWL), according to part eight of ISO 15926, or the
graphical representation EXPRESS-G [11] can be
used. For this paper EXPRESS-G is applied, because it
is utilized for the data model definition in ISO 15926-2
and clearly depicts the main modeling objectives.
Fig. 7 shows an excerpt of the graphical representa-
tion of the belt conveyor. Because of spatial re-
strictions, Fig. 7 solely includes the main objects of the
belt conveyor model in order to represent the ISO
15926 concepts. The graphical representation is sepa-
rated into three parts (in accordance with Fig. 1): the
ISO 15926 entity types (shown in the upper part), the
reference data classes (shown in the upper right part)
and the data, i.e. instances, about the belt conveyor.
Utilizing the implemented 4D-approach for the rep-
resentation of life-cycle information, the data about the
belt conveyor can be differentiated into data about the
functional depictions and data about the physical, i.e.
material, realization. This is in accordance with the
engineering approach, which first determines the func-
tions, followed by the physical implementation.
The required functions are represented by the six in-
stances: FPO-Conveyor, FPO-Motor, FPO-Belt, FPO-
Transmission, FPO-OutputSensor, and FPO-Input-
Sensor. These instances are instantiated from the entity
type FunctionalPhysicalObject. FPO-Conveyor addi-
tionally is instantiated from ArrangedIndividual, be-
cause it represents the entire function of the conveyor
(Instantiation is only shown for FPO-Conveyor). Con-
sequently, the relationship between FPO-Conveyor and
the remaining functional instances, i.e. its parts, are
modeled as CompositionOfIndividual. The functional
instances also comprise dependencies, of which Fig. 7
exemplarily shows the IndirectConnection between
FPO-Motor and FPO-Belt.
The required physical realization corresponding to
the functional instances is shown to the right of the belt
conveyor data, denoted as (and instantiated from
MaterializedPhysicalObject): MPO-Conveyor, MPO-
Motor, MPO-Belt, MPO-Transmission, MPO-
OutputSensor, and MPO-InputSensor. The
mereological relationships (only indicated for the phys-
ical realization) and the dependencies are the same as
for the functional instances. The physical realization in
addition comprises direct connections, which model
the physical, i.e. direct, connections between the in-
stances. In this case Fig. 7 shows the DirectConnection
between MPO-Motor and MPO-Belt.
In relation to the physical realization, the shown ex-
ample also indicates the classification of the instances
using the reference data of the RDL, respectively RDS.
For the reason of spatial restrictions, this is solely
shown for MPO-OutputSensor. Fig. 7 shows the corre-
sponding entity types of ISO 15926-2 (i.e.
ClassOfIndividual and its subtypes), followed by the
instances of the RDL - starting with the class
InanimatePhysical-Object and resulting in the class
ElectricalPositionSensor of the RDS [7]. The reference
data provide detailed information about the different
instances required for the physical realization. Howev-
er, according to the knowledge of the authors, the ref-
erence data does not provide the same quantitative and
qualitative data for the functional instances.
The functional data represent requirements resulting
from the engineering process, and the physical realiza-
tion in contrary has to fulfill these functional require-
ments. During the life-cycle these two approaches
come together in the phase of installation. This combi-
nation is represented utilizing the 4D approach, as it is
shown in the middle of the belt conveyor data. The
instances FMPO-Conveyor_001, FMPO-Motor_001,
FMPO-Belt_001, FMPO-Transmission_001, FMPO-
OutputSensor_001 and FMPO-Inputsensor_001 are all
PhysicalObjects and represent the combination of the
corresponding temporal parts of the
FunctionalPhysicalObjects and
MaterializedPhysicalObjects. Fig. 8 exemplarily shows
the combination of the functional and physical convey-
or instances in the space-time map. At the point in time
of the installation the temporal parts of the functional
and physical conveyor instances are the same, repre-
sented by the FMPO-Conveyor_001 instance. The time
point of the combination is modeled by the Events
subtype PointInTime, i.e. the instance Installation in
the example in Fig. 7, which is connected to the corre-
sponding temporal parts (FMPO-InputSensor_001)
using the Beginning relationship. The mereological and
topological relationships of the functional and physical
approaches are over the same for the combination (not
shown due to limited space).
Fig. 8. Space-time map for the installation
of the MPO-Conveyor
This example shows the possibilities offered by the
ISO 15926 data model for the representation of data of
industrial plants. The standards generic data model
offers different concepts allowing for structural model-
ing, so that mereology, topology, and the engineering
and the plant life-cycle can be comprehensively con-
sidered. In addition, the reference data allows the de-
tailed classification of the instances.
4.2. CAEX
Fig. 9 shows a possible hierarchical structure of the
conveyor belt example modelled with CAEX. As de-
scribed in the previous chapter the InstanceHierarchy
(IH) contains the instances of the automated systems.
In this case the InternalElement Conveyor_001 is an
item which is aggregated from different single items
instantiated from its classes. The sub-items (In-
put/OutputSensor_001, ElectricMotor_001, Transmis-
sion_001 and Belt_001) are instances from their
classes e.g. ElectricalPositionSensor. These classes are
described in the SystemUnitClass Library. This way of
modelling creates whole-part-relation (mereology).
The assigned role of each instance describes the
function. It should be noted that an object can have
more than one associated role. Besides the structural
and functional aspects the conveyor belt object has
internal connections. In this case there is exemplarily
shown one direct and indirect connection. The direct
connection describes a flange connection between the

Fig. 9. Representation of the belt conveyor utilizing
CAEX
instances ElectricMotor_011 and the Transmis-
sion_001. For instance the indirect connection de-
scribes the relation for transmitting the kinetic energy
from the rotating shaft of Transmission_001 to
Belt_001. However, there is no statement made at
which position the instance Transmission_001 is lo-
cated at Belt_001. The relation of impact of kinetic
energy only describes the functional relation between
both instances. A similar problem becomes apparent if
a statement about the spatial position of both sensors is
needed. In this case the information about the spatial
position of the item e.g. by x-, y- and z-coordinates is
not given. Instead the name of the instances only marks
the assignment of the item to another. Such informa-
tion will follow step-by-step during the engineering
process. This way of modelling using direct and indi-
rect relation between instances describes the topologi-
cal structure of the system.
4.3. Qualitative Comparison of ISO 15926 and
CAEX
The comparative application of ISO 15926 and
CAEX to the belt conveyor example exposes the dif-
ferent modeling approaches, resulting in the qualitative
evaluation shown in Table II. The evaluation criteria
are explained within the table, as well as the reasoning
for the evaluation is also included in the table. A three-
stage evaluation is used, at which + represents com-
plete fulfillment of the criterion without additional
effort. o stands for (partial) fulfillment of the criteri-
on, supplemented by the outlook for complete fulfill-
ment based on additional efforts or approaches outside
the considered standard. And - represents the non-
fulfillment of a criterion, which, if possible at all, can
only be fulfilled with high effort.
The resulting evaluation is in favor of ISO 15926, as
the standard completely fulfils all criteria except the
last one for expandability. On the contrary, the evalua-
tion reveals some deficits for CAEX, which are based
on the narrow focus onto the standard IEC 62424 itself.
Looking at the utilization of CAEX within
AutomationML and PandIX, there only remains a ma-
jor non-fulfillment of the life-cycle representation
criterion.
However, the comparative application in the subsec-
tions 4.1 and 4.2 shows (more or less) equal results.
Both data models allow the comprehensive modeling
of the exemplary belt conveyor application. At this,
ISO 15926 provides comprehensive semantics, which
on the one hand offer pre-defined objects, but on the
other hand also restrict flexibility. In addition, the ge-
neric data model itself is quite complex and modeling
requires detailed knowledge. On the contrary, CAEX
solely provides the most basic concepts required for the
modeling, which is very flexible but also neglects se-
mantics (the problem of missing semantics is overcome
by PandIX and AutomationML).
Directly comparing the two data model objectives,
ISO 15926 presents a meta-model for the modeling of
industrial plants which is based on an ontological
framework, whereas the meta-model of CAEX is even
a little bit more abstract, i.e. a little bit more (meta-)
meta-model, even it is not a meta-meta-model because
the standard includes some semantics.
5. Conclusion
Within this paper two upcoming standards, ISO 15926
and IEC 62424, have been compared. Obviously, both
standards can be used for the data exchange in the
engineering of automated plants. Defining similar
concepts twice for nearly the same tasks contradicts the
idea of standardization and guidance.
The qualitative comparison reveals the similarities,
and the distinctions between the standards. ISO 15926
comprises a history based on the STEP initiative,
whereas IEC 62424 is a younger approach. Therefore,
the comprehensive semantics of ISO 15926 are a con-
sequence, but the utilization of IEC 62424 within
AutomationML and PandIX strives for the same direc-
tion. IEC 62424 does not provide a solution for the
consideration of the complete life-cycle, whereas ISO
15926 implements a reasonable approach. Though,
complete and open data exchange also relies on this
life-cycle aspect, so that integration of the 4D approach
(in case it is possible at all) into IEC 62424 could be a
future investigation step.
This paper solely represents a first step towards a
comprehensive comparison of both standards. Further
investigations should focus on a more detailed compar-
ison of the data model concepts and applications in
order find a clear boundary between them. Though, this
 Table II. Qualitative comparison of ISO 15926 and CAEX
No. Criterion Explanation ISO 15926 IEC 62424 (CAEX)
1. Structuring aspects
Is it possible to model topology?
Are there different kinds of
+ Possible using direct and indirect + Possible using interfaces and
1.1 Topology connections. internal links, as well as represented
relationships between objects,
within system units.
e.g. dependency relationships?
Does the data model allow the
1.2 Mereology modelling of part-whole relation-
+ Possible using + Possible using the instance
CompositionOfIndividual. hierarchy and system units.
ships?
Which level/detail of semantics + The data model defines several o The standard itself does not
does the data model provide? Is (>200) entity types, additional semantics provide semantics, solely concepts.
2 Semantics
there the possibility to extend the are (can be) provided using the RDL, Semantics are added in the Automa-
semantics? which can also be extended. tionML and PandIX libraries.
3 Temporal aspects
+ ISO 15926 explicitly includes events, o CAEX does not consider these
Representation Does the data model include the points in time status, activities, and aspects, though they can be mod-
3.1 of time and representation of time? What temporal sequences. elled using attributes and additional
behaviour about behaviour? roles. AutomationML integrates
PLCopen.
Does the data model allow appli- + The 4D approach considers life-cycle - Roles allow bottom-up or top-
Life-cycle cation along the engineering life- representation explicitly; data is there- down modeling, versions could be
3.2
representation cycle? What happens to the data fore consistent over time. used for data consistency, but this
along the life-cycle? comes along with additional effort!
Object-oriented concepts: data
Object-
encapsulation, classes, class
+ ISO 15926 fulfils the characteristics, + The characteristics are explicitly
4 oriented con- but inheritance is more strictly compared stated in the standard.
libraries, instances, inheritance,
cepts to CAEX.
frameworks, attributes
5 Flexibility

+ The semantics provided allow direct o Data exchange involves more

effort for the involved disciplines. In
Is the data model instantly appli- data exchange, which is supported by
5.1 Applicability addition, there exists the risk of
cable for data exchange? project specific libraries.
sharing vendor and project specific
knowledge, i.e. the semantics.

Is it possible to extend the data

- ISO 15926 does not address expanda- o IEC 62424 offers concepts for
bility of the data model; solely the RDL expandability on an abstract level by
5.2 Expandability model? What about the integra-
can be extended. its external interfaces, shown with
tion of other data models?
AutomationML.

could also result in integration of and translation be-
tween both standards, so that their advantages are
combined.
References
[1] R. Drath, M. Barth: Concept for interoperability between
independent engineering tools of heterogeneous disciplines In
Proceedings: Emerging Technologies & Factory Automation
(ETFA), Toulouse, 2011.
[2] ISO 15926-1, Industrial automation systems and integration
Integration of life-cycle data for process plants including oil
and gas production facilities Part 1: Overview and fundamen-
tal principles, 2004.
[3] IEC 62424: Specification for Representation of process con-
trol engineering requests in P&I Diagrams and for data ex-
change between P&ID tools and PCE-CAE; 2008.
[4] AutomationML Whitepaper Part 1, AutomationML Architec-
ture, www.automationml.org, 2010.
[5] PandIX, www.plt.rwth-aachen.de/fileadmin/research/
PandIX/PandIX-Modellbeschreibung_V501.pdf, 2012/04/17.
[6] R. Batres et.al., An Upper Ontology based on ISO 15926,
Computers & Chemical Engineering, Volume 31(5-6), pp. 519-
534, 2007.
[7] Reference Data Services (RDS),
www.posccaesar.org/wiki/Rds, 2012/04/17.
[8] J.G. Stell, M. West, A 4-Dimensionalist Mereotopology,
International Conference on Formal Ontology in Information
Systems, 2004.
[9] D. Leal, ISO 15926 Life Cycle Data for Process Plant: An
Overview, Oil & Gas Science and Technology Rev. IFP,
Volume 60(4), pp. 629-637, 2005.
[10] AutomationML Whitepaper Part 2, AutomationML Libraries,
www.automationml.org, 2010.
[11] ISO 10303-11, Industrial automation systems and integration
Product data representation and exchange Part 11: Descrip-
tion methods: The EXPRESS language reference manual,
2004.

View publication stats