AutomationML – the glue for seamless Automation Engineering
Dr. Rainer Drath Dr. Arndt Lüder, Jörn Peschke, Lorenz Hundt
ABB Corporate Research Ladenburg
Wallstadter Str. 59
68526 Ladenburg
rainer.drath@de.abb.com
Abstract
This contribution presents the basic architecture of
the neutral data format AutomationML developed by the
companies Daimler, ABB, Siemens, Rockwell, Kuka,
Zühlke, netAllied and the universities of Magdeburg and
Karlsruhe. AutomationML serves for the data exchange
between manufacturing engineering tools and therefore
supports the interoperability between them. It covers in-
formation about the plant structure (topology and geo-
metry) and the plant behaviour (logic and kinematics).
The first version of AutomationML has been presented at
the Hannover fair in 2008.
1. Motivation
The engineering of manufacturing plants usually is
characterized by a strong phase separation and a variety
of specialized engineering tools for each phase. This
leads to the problem of a broad heterogenous tool land-
scape with individual and often proprietary data formats
and insufficient data exchange support. Facing the
increasing number of tools and sub-suppliers in a typical
engineering value creation chain, data exchange is a
significant bottleneck.
Due to these reasons, the Daimler AG initiated the
foundation of a consortium together with leading ven-
dors and users of automation technology in order to de-
velop a neutral data exchange format usable within the
engineering process of manufacturing systems to
exchange data among the various used tools. ABB, Sie-
mens, Rockwell, Kuka, netAllied, Zühlke and the uni-
versities of Karsruhe and Magdeburg currently specify
and implement the technical concepts of this neutral data
exchange format named AutomationML .
®
This neutral data format follows the needs of engi-
neers regarding interoperability of tools within the to-
days heterogeneous tool landscape and is an important
step towards the vision of a seamless value creation
chain. It additionally intends to become an enabling
technology for the topic „virtual commissioning“, that
requires the reunification of interdisciplinary engineering
results which are usually spread to different tools.
1-4244-1506-3/08/$25.00 ©2008 IEEE
Otto-v.-Guericke University
Universitaetsplatz 2
D-39106 Magdeburg
[arndt.lueder/joern.peschke/lorenz.hundt]@ovgu.de
This contribution introduces technical basic concepts
of AutomationML and illustrates them by means of
corresponding examples.
2. AutomationML basic concepts
One of the challenges of AutomationML [5] is the in-
tended ability to store different facets of the plant engi-
neering. These facets are usually created and maintained
in different tools following various disciplines, guide-
lines, business rules and naming conventions. This leads
to complex and cross linked information.
A reliable well-tried concept for the control of com-
plexity is object orientation. Thus, AutomationML fol-
lows the object-oriented paradigm and describes real
plant components as data objects encapsulating different
aspects. An object can consist of sub objects and itself
may be part of a bigger composition. Such data objects
are grippers, values, signals, robots, tanks or complete
manufacturing cells. Typical aspects comprise its
geometry, its kinematic, its behaviour, its position within
the hierarchical plant topology and the relations to other
objects.
Since established data formats for these different as-
pects are already available, it is a goal of the Automa-
tionML consortium to cover required functionality out of
existing data formats and, if necessary, to influence the
extensions of them. AutomationML itself serves as
integration format between these standards and defines
how to use them in order to describe concrete and
interpretable plant components.
AutomationML supports the storage of the following
basic concepts:
• Plant topology: The plant topology describes the
plant as a hierarchical structure of plant objects.
This structure is the AutomationML top level for-
mat. Different aspects of an item are directly associ-
ated to the corresponding AutomationML object.
They are stored down to a certain level of detail
only, e.g. robot, gripper, but no axis or joints.
Objects have individual properties and interfaces.
As basis data format for the plant topology CAEX
[1,2,6] is beeing used whereas AutomationML de-
fines the specific usage of CAEX in detail. CAEX in
616
 consequence serves as the high level integration
frame of AutomationML.
• Geometry: The geometry of a data object comprises
its complete geometric 3D description. Geometry in-
formation is stored by means of the data format
COLLADA™ of the industry consortium “Khronos
group” [4] as separate XML files. AutomationML
defines special reference mechanisms to link CAEX
data objects with a COLLADA file. Out of these
distributed single geometry information; the
complete geometry scene can be calculated auto-
matically.
• Kinematic: Kinematic information describes the
physical interconnection of 3D objects and their
geometric dependencies for the motion planning.
This information is also stored by means of the data
format COLLADA™ as separate XML files.
COLLADA interfaces can be „published“ within
CAEX and can be interlinked using standard CAEX
link mechanisms.
• Behaviour description: The behaviour of objects is
described as a sequence of actions. These are stored
by means of the data format PLCopen XML [3] as
SFC including the corresponding I/O-relations and
logical variables. Variables of the SFCs can be
“published” within CAEX. This allows storing high
level interconnections between them in CAEX.
Even time diagrams (e.g. Gantt-Charts), which are
used by mechanical engineers in order to define the
motion sequences, can be stored as simplified SFC
with PLCopen XML and transformed into PLC
logic in a later engineering phase.
• References and relations: AutomationML distin-
guishes between relations and references. Refe-
rences on the one hand describe associations from
CAEX objects to externally stored files, e.g. from a
robot object to its corresponding geometry file. Re-
lations on the other hand specify interrelations bet-
ween CAEX objects, e.g. the link between a robot
signal with a certain channel of an I/O board. These
are additionally used in order to link information in
the top level format which is stored externally. For
this, corresponding interfaces must be “published”
in CAEX. They can be linked with standard CAEX
link mechanisms.
3. AutomationML basic architecture
Thus, the basic architecture of AutomationML (see
Figure 1) consists of the standards CAEX, PLCopen
XML and COLLADA. CAEX acts as the top level
format and stores the plant topology, COLLADA stores
geometric and kinematic information, while PLCopen
XML serves for the storage of sequences and behaviour.
617
This architecture results in an inherent distributed file
structure. The advantages of this concept are:
• Reuse of matured data formats - this reduces the
specification effort for AutomationML.
• Distribution of data into different files – this eases
the handling of bulk data.
• Simplified usage of library files – they can be stored
and exchanged separately.
• Different geometry or logic variants may be stored
separately, e.g. in order to distinguish between dif-
ferent degrees of detail.
AutomationML
Top level format CAEX
corresponding to IEC 62424
Topology of
Geometry and
Kinematic format
• Plants Object A COLLADA
• Cells
Object A1
• Components
• Attributes
Object A2 Init
Init
• Interfaces
• Relations Logic format
Step 1
• References
PLCopenXML
End
Figure 1: Basic architecture of AutomationML
4. AutomationML-Specifications
An important part of the AutomationML specification
comprises the application of CAEX. This file format
provides flexible mechanisms in order to store different
kinds of data whereas AutomationML specifies the con-
crete application of these concepts. For this, Automa-
tionML defines the following special attributes, classes,
interfaces and object identification rules:
• Object identification: AutomationML defines how
to identify AutomationML-objects and Automation-
ML-classes.
• InterfaceClassLib: Interfaces serves for the des-
cription of relations between objects. Automation-
ML delivers a predefined interface library, which
contains a number of abstract interface classes for
general automation systems. These classes are syn-
tactically and semantically well defined and allow
the modelling of user defined interface instances.
• RoleClassLib: A role library serves for the definion
of abstract role classes. A role class explains the
general functionality of a CAEX object within its
context. Examples are e.g. a robot, a rollerbed, a
PLC etc. Thus, they serve for the semantic interpre-
tability of user defined AutomationML-objects.
• SystemUnitClassLib: A system unit library allows
the storage of user defined AutomationML classes.
AutomationML does not specify a certain System-
UnitClassLib, but it defines rules how to design
 them. This contains a number of AutomationML
attributes including their syntax and semantic as
well as references to AutomationML-classes. a) Rob1 PLC1
• InstanceHierarchy: Instance hierarchies store con-
crete project data and are therefore the core of Auto-
mationML data. The InstanceHierarchy is a hierar-
chy of object instances with its own individual b InternalLink
properties, interfaces, references and relations. )
4.1. Examples
The following examples demonstrate a selection of
AutomationML concepts and their mapping to Automa- Figure 3: Relations betweeen AutomationML
tionML.
objects
4.1.1. Storage of a plant topology
Figure 4 depicts the corresponding AutomationML re-
Figure 2 shows a simple example of a plant hierarchy
presentation. It becomes visible that the interfaces of
and how to store it in AutomationML. The storage of a
both objects “Rob1” and “PLC1” are mapped to CAEX
hierarchy is done with nested CAEX InternalElements.
ExternalInterfaces which are derived from the Automa-
Each object is chacterized by an arbitrary name and a
tionML standard interface class „DigitalInput“ or „Digi-
unique GUID.
talOutput“ respectively. The linking is done by means of
a CAEX-InternalLink.
ObjectA

ObjectA_1
a)
ObjectA_2

ObjectA_2_1

Internal-
Link

b)

Figure 4: Storage of a relation between

AutomationML objects

Figure 2: Plant hierarchy 4.2. Referencing external COLLADA-files

If an AutomationML object shall be associated to
geometry or kinematics (see Figure 5), those data must
4.1.2. Storage of relations between AutomationML
be stored in a separate COLLADA-file. The correspon-
objects
ding AutomationML object references this file. For this,
The example below illustrates how to store relations
the AutomationML-Attribute „COLLADAReference“
between plant objects. For this, Figure 3a considers two
has been defined. Additionally, AutomationML specifies
plant objects “Rob1” and “PLC1”, both objects have
a set of geometric position information, which describes
each one signal interface. They can be linked with
the geometric position and rotation relative to the scene
CAEX link mechanisms. On the other hand, Figure 3b
(„Frame“).
shows the corresponding hierarchical topology and em-
phasis the linked interfaces.

618
 CAEX File
Station
Robot1
Robot2
Attribute „COLLADAReference“
Attribute „Frame“
Figure 5: Referencing an external
COLLADA-file
Figure 6 represents the corresponding AutomationML
file. The object „Robot2“ references the corresponding
node by means of the AutomationML attribute „COL-
LADAReference“.
Figure 6: Storage of geometry references with
AutomationML
4.3. Referencing external logic files
If an AutomationML object shall be associated to
logic information stored in a separate PLCopen XML
file, this file is referenced similar to the referencing
mechanisms for geometry data by means of the Auto-
mationML attribute „LogicReference“.
CAEX File
Station
Attribute „LogicReference“
Figure 7: Referencing an external PLCopen XML
file
Figure 8 shows the corresponding AutomationML re-
presentation.
COLLADA File
Combination
Kinematic Geometry
Figure 8: Storage of logic references with Auto-
mationML
Beside the presented concepts, the mentioned “pub-
lished” logic and geometric interfaces can be linked in
the top level format. These links are a main feature of
AutomationML and allow connecting engineering infor-
mation to each other which is normally distributed to do-
main specific data formats without knowing its relation-
ships. In this way, Automation is the glue between other-
wise separated engineering information.
In sum, the described concepts provide powerful
means to store complex engineering information in a
vendor independent way. This opens up a variety of
application fields.
5. Application scenarios of AutomationML
The following application scenarios demonstrate how
AutomationML can simplify the engineering of manu-
facturing plants.
In the beginning of an engineering project, the 3D ge-
ometry and kinematic of the required mechanical com-
ponents are designed using a 3D engineering tools. By
means of AutomationML, this geometry information can
be imported into a plant simulation tool. There, the cell
and line layout is developed. In parallel, the mechanical
engineering defines the required sequences of operation.
Afterwards, the electrical engineering and the PLC and
robot programming are started. For this, the sequences of
the mechanical engineering are imported by means of
AutomationML and directly re-used. Finally, the com-
plete cell including the geometry, kinematic, logic and
I/O design can be overpassed into a virtual commissio-
ning environment.
Test
PLCopenXML file Quotation
Process
Engineering
Mechanical
Engineering
Electrical
Engineering
Robot
Engineering
PLC
Engineering
HMI
Engineering
Commissioning
Operation
Init
Step 1
End
Figure 9: Use cases for AutomationML
Figure 9 shows a simplified engineering workflow
and illustrates that AutomationML is usable in quite each
phase, whereas the direct data exchange between neigh-
bour phases is in the main focus. However, Auto-
mationML also supports iterations among the phases –
619
but it is important to understand that the required change
management in an iterative engineering workflow is tool
functionality and cannot be processed by means of a file
format.
Especially the phase of the virtual commissioning can
utilize AutomationML. Furthermore, even the quotation
phase can benefit from the re-use of proven engineering
data and can feed their results directly into the following
engineering steps.
6. Logic Data in AutomationML
One important aspect of AutomationML is the description
of logic data as required for electrical design, HMI deve-
lopment and programming of PLCs as well as robots.
Within the engineering process, the description of logic
information has not only to cover data of different tools
and disciplines, but also supports different phases in the
development process with various levels of detail.
AutomationML simplifies the engineering of production
systems by providing a common data format which can be
used continuously from the first engineering steps such as
plant design to the final commissioning of complete
systems. Hence, AutomationML must be able to store a
variety of different types of logic information belonging to
a production system or a single part. Examples for this
information are:
• Definition of sequences of operations during the first
planning phases described in different levels of detail
by e.g. Gantt charts.
• Sequences of tasks with timing boundary conditions
described by e.g. PERT charts.
• Detailed task sequences including signals specified by
e.g. Impulse diagrams.
• Detailed sequences including PLC programs with a
mapping to real control hardware described by
Sequential Function Charts (SFC).
All types of logic information are stored within one
common model: the Sequential Function Chart (SFC) as
one of the PLC programming languages defined in IEC
61131-3 [7] and the underlying data format PLCopen
XML. Therefore logic information is stored in separate
documents. As already mentioned above, the variables
within an SFC can be “published” in the top level format
for later interlinking.
One of the essential preconditions for using the Auto-
mationML logic concept is the definition of translation
rules which allows the transformation to and from SFCs
out of various logic data formats.
AutomationML distinguishes between two main con-
cepts of logic data which pursue different objectives:
• Description of behavior of AutomationML objects.
This models the uncontrolled reaction of e.g. a part on
external stimulations (signal inputs), typically used in a
white-box manner.
620
• Description of sequences - used in order to specify the
required controlled behavior of a system or part. Se-
quences finally lead to programs which are associated
to and executed by one or more controllers (e.g. robot
controllers, PLCs etc.)
Both concepts are illustrated by means of the follo-
wing examples for the three typical utilizations within
AutomationML and depicted in Figure 10 with focus on
the gripper, the station and the device.
Project
Mechatronical Units with:
sequencing
Station behavior
sequencing/
behavior
Robot
Gripper
Device
Figure 10: Logic descriptions in AutomationML
• Uncontrolled behavior of a single mechatronic unit
An example for this type is the internal uncontrolled
behavior of a gripper, which might be permanently as-
signed to a corresponding library element. The signal
interfaces of this are required for triggering the beha-
vior or retrieving the internal states. In most cases they
represent the same signals as the real physical element.
The behavior description is normally not changed rat-
her than rarely replaced by new versions.
• Sequencing for a cell / plant
This comprises the desired sequence of actions within a
cell as high level input for the PLC-program. It is typi-
cally bound to an unit object (e.g. the station) or if
available to an element representing an execution envi-
ronment, such as a controller. Communication inter-
faces are required for the interaction with other ele-
ments of the logic description and consist of real sig-
nals or simplifications of them. The evolution of this
description during a development process typically
starts with an abstract specification of required beha-
vior of a larger scale unit (cell, line, plant etc.) over a
refinement to more detailed sequences and an enhance-
ment with signals towards an executable program
(PLC/robot).
• Behavior and sequencing of intelligent devices
“Intelligent devices” can combine both behavior and
sequencing. From an external view, device programs
may be controlled by means of behavior. From an in-
ternal view each single program can be described as
 sequence. An example for this combined type is the
behavior of a robot, which is realized by robot pro-
grams which interact with a PLC as overall cell con-
troller. It is important to note, that this example can be
interpreted as behavior or sequencing depending on the
point of view. Thus, communication interfaces may be
used for the interaction with other elements in terms of
triggering a behavior.
6.1. Logic transformation rules
For the engineer, the application of AutomationML
requires transforming his existing input logic format into
a SFC and to transform an existing SFC back into the de-
sired output logic format which might be the same as the
input format. Nevertheless, AutomationML does not pro-
vide any mean to compensate different modeling power
of the various formats. Thus depending on the formats
there may be an information loss during this procedure.
Those transformations require rules, which are in the
focus of the following explanations. These rules follow
the approach to decouple the neutral format PLCopen
XML from concrete input and output data formats by
introducing an intermediate modeling layer (IML). This
layer provides advantages for a conceptual mapping of
different formats and eases the implementation of ex-
and importer tools. By defining an IML, the transfor-
mation of an input format is virtually divided into two
steps. As shown in Figure 11, first the input format is
mapped to IML, while in a second step the resulting
IML-model will be translated into an XML represen-
tation according to PLCopen XML SFCs.
Mapping Rules based
on transformation of
Model elements
Ganttchart
PERT
IML
Impulse
diagram
...
Specific models and charts Set of model elements
(Proprietary data format)
Figure 11: Logic models during transformation
process
This approach allows:
• On the one hand to define the complex transformation
rules from and to PLCopen XML which have to take
XML specifics into account only once, but not for any
new input format. A software implementation could
provide this translation as standard functionality as a
reusable component with a well defined API.
• On the other hand for specific input formats (models,
diagrams etc.) only transformation rules to the inter-
mediate layer have to be defined. This can be done on a
modeling level without knowledge of PLCopen XML
details and thus eases the introduction of new input
formats for AutomationML. As described above, for
the realization of new ex- or importer functionality, the
IML/PLCopen-component is reusable for several diffe-
rent formats reducing the implementation effort to the
more simple transformation to IML.
Independent of these advantages it is important to
note, that IML is a concept which eases the definition of
transformations rules as well as the implementation of
corresponding software, but is not mandatory for the use
of the AutomationML logics features. If feasible, the di-
rect way from a given input format to and from PLCopen
XML under consideration of the appropriate rules is also
possible.
The Intermediate Modeling Layer defines abstract
elements representing the main categories of data usually
exploited within logic models. IML consist of a set of
different system entities containing 11 types of elements
as described in table 1.
IML Sys- Description of the IML Entity
tem Entity
State States describe a stable situation within a system
present for a certain amount (larger than zero) of
time.
State transi- A state transition is the change over from one
tion state to next state(s) by interpreting the state
transition condition.
Activity An activity will describe one or more processes
executed during the evolution of the modeled
system.
Mapping of IML
elements to Jump A jump represents a state it belongs to. It has no
XMLstructures
own modeling meaning.
Selection Selection divergences are logical associations
divergence between three or more description elements,
PLCopen XML
representing a selection divergence.
Simultanious Simultaneous divergences are logical asso-
divergence ciations between three or more description ele-
ments, representing a simultaneous divergence.
Selection Selection convergences are logical associations
XML convergence between three or more description elements,
representing a selection convergence.
Simultanious Simultaneous convergences are logical associ-
convergence ations between three or more description ele-
ments, representing a simultaneous convergence.
Event Events will happen, if some properties within a
modeled system have been changed.
Variable Variables will be used to characterize states and
activities and to enable/disable transitions.
Thereby, variables are mostly used to describe
detailed information about the modeled system.
Comment Comments are not structured additional infor-
mation attached to system nodes.
Table 1: Overview IML entities
621
 The modeling power of this set of elements is close
but not restricted to the SFC-model. With additional ele-
ments, such as events, it allows to easily map common
logic representations to IML.
6.2. Example: transformation of Gantt Charts
One possible input format for IML is the wellknown
Gantt Chart [8]. The following example illustrates the
transformation process into a SFC.
Gantt charts are typically used to describe the order
and execution time of activities on a high level in early
states of the engineering of a plant. The main informa-
tion stored is start and end time of activities and prede-
cessor/successor relations. In AutomationML, Gantt-dia-
grams can be represented as SFC according to the fol-
lowing principles:
• Each Gantt activity is represented by a SFC step
with two actions and a successor transition. The
time behavior of the Boolean variables is represen-
ted by actions and describes the start and end time
of the Gantt activities. If no explicit relations bet-
ween Gantt activities are defined, the SFC-steps are
parallel.
• If relations are described (predecessor/successor)
the resulting structure is a sequence of SFC-steps
and transitions.
• Mixtures of both structures are possible. If choices
have to be described, this shall be done using selec-
tion divergences.
• For each SFC representing a Gantt chart, an initial
step shall be created followed by a transition with
condition “true” as link for all further elements.
The application of these rules is illustrated in the fol-
lowing Figure 12 showing a simple Gantt chart with
three activities and an explicit successor relation
between activity A2 and A3. It can be seen, that this
relation results in a sequence of steps (S2 and S3) in the
SFC, while A1 and A2 with no relations lead to parallel
branches for steps S1 and S2/S3.
A1
A2
A3
t
Initial-
step
true
D VA1 D VA2
S1 S2
D TA1 D TA2
D VA3
S3
D TA3
Figure 12: Gantt chart transformed to an SFC
622
The following example presents the handling of time.
In a Gantt chart, the time comsuption of a process is de-
picted by the length of a bar. In an executable SFC, the
start time and the time consumtion of a process is depic-
ted by corresponding actions and transition conditions.
To enable the unambiguous backwards transformation
from SFCs to Gantt chart, some additional naming con-
ventions for actions are defined by the AutomtionML
consortium in order to ensure the correct identification of
these SFC elements. As described above, the timing in-
formation of each Gantt activity is represented by a step
with two actions and a successor transition. The first ac-
tion directly represents the time behaviour of the related
SFC-activity and may be delayed in execution using a D-
qualifier. Thus, the action starts “synchronously” to the
appropriate Gantt bar (DA._1._Activity 1 in Figure 13).
The second action is responsible for enabling the suc-
cessor transition to “synchronously” deactivate the step
and end the first action according to the end time of the
Gantt activity. Hence the action will also contain a D-
Qualifier in order to delay the start of the action (TA._1).
The condition for the following transition has to be en-
abled when this action is executed.
Figure 13: Execution of time related
SFC-actions
Gantt charts typically have a global time concept.
SFCs however only have a local time derived from the
activation time of the step. Therefore, a mapping of a re-
ference point to the global time is needed.
Figure 14 gives another example of a Gantt chart to be
transformed into SFC.
T1
T2
T3
T4
T5
t0 t1 t2 t3 t4 t5 t6 t
Figure 14: Example 2 of a Gantt Diagram
 T1, T2 and T3 have no explicit predecessors; whereas signed for storing and data exchange of engineering
T4 follows T2 and the start of T5 depend on the information. Interconnecting those distributed engi-
finalization of T3 and T4. The SFC model resulting from neering information is a key functionality of Auto-
the transformation is shown in Figure 15. mationML. In this way, AutomationML is the glue bet-
ween otherwise separated engineering information.
Initial
step
AutomationML enables the storage of plant topology infor-
true mation as well as references and relation information by
D t0 VA_ID01_T1 D t1 VA_ID02_T2 D t3 VA_ID03_T3
exploiting the CAEX standard (IEC 62424), geometry and
S1
D t1 TA_ID01
S2
D t2 TA_ID02
S3
D t5 TA_ID03
kinematic information by exploiting the COLLADA™ and
TA_ID01 = 1 TA_ID02 = 1 TA_ID03 = 1
behaviour information by exploiting the PLCopen XML
S4
D (t3-t2) VA_ID04_T4 standard.
D (t4-t2) TA_ID04
The re-unification of engineering data in Auto-
TA_ID04 = 1
mationML delivers a variety of advantages. Engineering
Buffer Buffer
step step data are extracted out of their host tools and thus neu-
tralized. This protects the engineering investments which
true
are otherwise bound to the tools.
Furthermore, these data can be re-used for training
D (t5-t5) VA_ID05_T5
S5 purposes, for tests, standardization activities and for the
D (t6-t5) TA_ID05

TA_ID05 = 1
support of maintenance or for the iterative comparison of
different versions.
AutomationML is designed by vendors, and end users
Figure 15: SFC representing Example 2
of automation systems in closed cooperation with
As mentioned above, the Gantt activities with no ex- scientists in the field of industrial control. Therefore, it
plicit predecessor result in parallel steps with a time de- covers a broad range of requirements and takes up the
lay derived from the start point of the diagram. The pre- newest developments within this field. Hence, the
decessor/successor relation between T2 and T4 results in expectations on AutomationML are very high. At
a similar relation between S2 and S4. Hanover fair 2008 a first version of AutomationML has
For the dependency of T5 from two predecessors, ac- been published to a broad audience. All interested
tivities buffer steps are required to decouple the different experts and scientists are now asked to join the efforts
deactivation times of predecessor steps. These additional and to extend AutomationML.
steps and transition have no effects on timing behavior
of the SFC, beside of “storing” the successor information References
of S4.
These transformation rules allows storing logic infor- [1] IEC 62424 CDV: Specification for representation of pro-
mation from various logic data formats in a vendor inde- cess control engineering requests in P&I diagrams and
pendent way and several levels of detail. This enables a for data exchange between P&ID tools and PCE-CAE
transparent and seamless evolution from abstract high tools. Beuth-Verlag, 2007.
level logic information down to executable programs [2] Fedai M., Drath R.: CAEX - a neutral data exchange for-
without a conceptual break. mat for engineering data. In: atp/international 1/2005, S.
43-51, Oldenbourg Industrieverlag, 2005.
7. Summary and outlook [3] http://plcopen.org/
[4] http://de.wikipedia.org/wiki/Khronos_Group
AutomationML is a data exchange format with the objec- [5] http://www.automationml.org/
tive to provide the seamless automation engineering. The [6] Fedai M., Epple U., Drath R., Fay A.: A Metamodel for
need for such data format is derived form the bordering generic data exchange between various CAE Systems.
conditions of the existing tool landscape and the problems In: Troch, Inge und Felix Breitenecker (Herausgeber):
arising of the incompatibility of these tools. Proceedings of 4th Mathmod Conference, Band 24 der
AutomationML provides concepts to store infor- Reihe ARGESIM Report, Seiten 1247-1256, Vienna, 5.-
mation about topology, geometry, kinematics, logic, 7. Januar 2003, ISBN 3-901608-24-9.
references and relations in order to close existing gaps [7] IEC 61131-3 International Electrotechnical Commission:
during the engineering of production systems. It follows IEC 61131 -Programmable controllers - Part 3: Pro-
the concept of object orientation and describes real plant gramming languages, www.iec.ch.
components as objects encapsulating different aspects of [8] Adam, Dietrich: Produktionsmanagement, Wiesbaden
the engineering. These aspects are stored separately in Gabler Lehrbuch, 9. Auflage, 1998.
existing data formats which are already available and de-

623