Conference PaperPDF Available

Implementation of an AutomationML-Interface in the digital factory simulation

  • inpro Innovationsgesellschaft für fortgeschrittene Produktionssysteme in der Fahrzeugindustrie mbH

Abstract and Figures

The role of virtual commissioning and manufacturing plant simulation in the process planing is getting more important every day (Reinhart & Wünsch, 2007). However the heterogenous environment of engineering tools and the need of data exchange between them cause big costs and time waste. (Kiefer, 2008) A concept to transfer information types like topology, geometry, kinematics, logic, physical behavior is currently one of the main requirements of the mechatronical engineering process. In this paper, a practical attempt of solving the data exchange problem with the help of AutomationML® format will be introduced.
Content may be subject to copyright.
Implementation of an AutomationML-Interface in the digital factory
M.Sc. Ender Yemenicioğlu
tarakos GmbH
Werner-Heisenberg-Str. 1
D-39106 Magdeburg
Prof. Dr. Ing. habil. Arndt Lüder
Otto-von-Guericke University
Universitätsplatz 2
D-39106 Magdeburg
The role of virtual commissioning and manufacturing plant simulation in the process planing is
getting more important every day (Reinhart & Wünsch, 2007). However the heterogenous
environment of engineering tools and the need of data exchange between them cause big costs and
time waste. (Kiefer, 2008) A concept to transfer information types like topology, geometry,
kinematics, logic, physical behavior is currently one of the main requirements of the mechatronical
engineering process. In this paper, a practical attempt of solving the data exchange problem with the
help of AutomationML® format will be introduced.
The term „digital factory“ is defined as a network of digital models and methods which among others
consists of simulation and 3D visualization. Its purpose is the integrated planning, implementation,
control and continuous improvement of all essential plant processes and resources in connection
with the product. (VDI, 2008)
Many engineering fields, separate software tools and their associated data models are used in the
engineering chain of production planning, which contains disciplines from technical, economical and
natural sciences. It is required to have project wide observation and controlling independent of indi-
vidual engineering tools. Therefore data management is one of the major tasks within digital factory.
(Lüder, Rosendahl, & Schmidt, 2013)
Essential basement of the digital factory are digital data models of all relevant components of a pro-
duction system including products and production systems covering structure, behavior, and rela-
tions/dependencies. Thus, one required input is a visual scene of a production system modeling the
structure, geometry, kinematics and behavior of the production system in a way applicable for simu-
lation based analysis. To create such a scene is usually a task of the OEMs or the production system
developer / user.
The accumulated data can further be used by other software tools, which are specialized in a certain
field like mechatronic, physic simulations, control design, virtual commissioning or maintenance.
Therefore, data exchange is an important part of production system engineering exploiting the digital
factory. Nevertheless this data exchange is also a cost factor in the workflow (Drath, Lüder, Peschke,
& Hundt, 2008) as bad implementations of this data exchange (for example exploiting only PDF files
or proprietary data formats) can cause errors and redundant engineering actions.
AutomationML, which combines the topology, geometry, kinematic, logic information as well as pos-
sibly other XML based information, has the potential to overcome the problems by providing a gen-
erally accepted data exchange format able to model and transfer the required data.
However, the format itself does not ensure the quality of exchanged information. Errors such as
unique identity key violation or defective normal vectors in geometry are not uncommon. The evalu-
ation of external references is also a challenge for most importing tools. These aspects should be
taken into consideration during the development of an interface. This work presents a practice of
implementing AutomationML-format importing and exporting functionality for the purposes of digi-
tal factory simulation in taraVRBuilder and taraVRControl software tools.
An essential part of the digital factory is the virtual commissioning. It is related to the validation of
production system behavior before system physical implementation to avoid system malfunctioning
(Reinhart & Wünsch, 2007). Virtual commissioning requires information from system engineering,
mechanical engineering, electrical engineering, and control engineering (at least) and is therefore the
ultimate example for required data exchange within the engineering of production systems.
Definition of task
The particular steps of data exchange on the way to virtual commissioning should be clarified to de-
fine the task considered in this paper. Mostly the need of a new product is first determined, and pro-
cess engineers make a concept design for the manufacturing tools and workflow. If the geometry and
kinematic information of manufacturing tools already exist, it can be transferred to layout planning
tools. If not, it should be created with the help of 3D engineering tools. The layout plan can also be
transmitted as manual sketches or 2D drawings to a layout planning tool. With the help of these in-
formation a 3D scene of the manufacturing plant can be created.
The outcome of the layout planning should be transferred to other engineering tools, which are spe-
cialized in particular fields: PLC programming tools, robot programming tools, electrical design tools,
physical behavior definition tools, etc. Theoretically all of these tasks can be fulfilled parallel, and the
outcome of each process can be merged into one container file.
Figure 1 Plant simulation process and implementation of AutomationML®
The result data can be used for the purpose of creating a virtual scene with physics engine for a real-
istic visualization. With the help of co-simulation other engineering solvers can be added to the simu-
lation. An automatic test generation is also a possible task, which can be supplied with the result of
co-simulation. Simulation results can be visualized at real-time (runtime visualization) or a post run
visualization could be necessary because of performance issues and to provide high fidelity of the
outcome. Post run visualization is more realistic than the runtime visualization because the simula-
tion output is more accurate and precise due to longer timing constraints.
But the problem is that there is no existing usage of a data exchange format, which supports all these
steps in the simulation planning process. As a neutral data exchange format which includes the dif-
ferent facets of plant engineering AutomationML® is a strong candidate to be the solution. However
an implementation of import and export functions for the above explained tool chain is needed. (cf.
Figure 1)
In the following the example of a tool chain used for behavior simulation within virtual commission-
ing is considered.
Components of exchanged information
In a simulation process a manufacturing plant consists of several components, which includes me-
chanical, electrical, automation relevant and other information aspects. These components can be
named as mechatronical engineering objects. Mechatronical engineering object is the representation
of a mechatronical unit in the real component, which is the combination of energy, information and
material flows that are connected via sensor and actuators to an information processing unit, usually
establishing a hierarchical structure. (Foehr, Lüder, Hundt, & Wagner, 2010)
A conveyor unit from materials handling field can be taken as a simple example of a mechatronical
engineering object. The main geometrical properties of a conveyor are the length, width, height and
degree of bending angle. The kinematic property is the direction of the material flow. A conveyor
consists of load-carrier system (e.g. Rollers) and a frame with supporting legs. They can be consid-
ered as sub-components. The connection points with other system components should also be de-
fined for a conveyor object. (cf. Figure 2)
Figure 2 View of an example conveyor object in AutomationML®-Editor
As easily visible in this example, the relevant information within the considered application of virtual
commissioning are geometry and kinematics information of the system components and its geo-
graphical relations describing the visual scene and the behavior information modeling the controlled
and the uncontrolled behavior of the production system (Lüder, Rosendahl, & Schmidt, 2013). These
information sets have to be exchanged.
Functional requirements
There are two main functional requirements in the tool chain: 1) Describing and exporting the own
data model as AML-file, 2) Importing an AML-file from different type of sources.
For a successful export function, the quality of the exported information should be considered as an
important factor. Not only the position and the geometry of the object but also the hierarchical
structure and workflow should be transferred. For the identification of objects all exported compo-
nents must have a unique identifier and they are not allowed to be changed in the further phases of
tool chain. (Drath & Schleipen, Grundarchitektur: das Objektmodell, 2010) The tool itself should have
an inner mapping of the objects and their identifiers for the recognition of the own objects after the
export. The versioning of the file should also be supplied.
Inside the tool chain three types of importing tasks can be defined: 1) Importing the own created files
(i.e. from taraVRBuilder to taraVRControl), 2) Importing a file which is created by own tool but
changed from another tool afterwards (i.e. exporting from taraVRBuilder, further editing by an ex-
ternal tool and importing to taraVRControl), 3) Importing a file from a completely foreign origin.
It can be guessed that importing an own file is the easiest task among these. The scene can be creat-
ed with the known hierarchical structure and the objects can be established via intern mapping of
identifications. The possible changes in the attributes could be applied with known intern software
The second type of importing is more challenging than the first one. It is possible that some unknown
attributes or properties are additionally in the scene, and they should not be overwritten during the
further work in the tool.
The third type of import is the most difficult one. But it does not mean there are no information in
the file which can be recognized. The topology of the internal elements can be definitely identified.
The position of the objects can be determined with the help of element attributes, which are derived
from standard role class “Frame”. “Frame” role class defines the relative positions and the rotations
compared to the parent object’s coordinate system. The geometry of the object is defined with a
standard external reference interface “COLLADAInterface”. The logic behavior definition can also be
recognized with the standard interface “PLCopen-XMLInterface” Further properties and structures,
which are defined in the whitepaper (for example connections of objects via port interface and so
on), could also be found out. (AutomationML consortium, 2013.)
Co-simulation requirements
The digital factory simulation requires the modeling and solving of behavior for multi-disciplinary
systems, which cannot be achieved with only one simulation tool. For complex physical behaviors
there are some specific modelling languages like object-oriented Modelica or data flow based graph-
ical language Simulink. (Moriz, et al., 2011)The software tools which can solve these models and
equations should work together with other simulation components like visualization, physics-engine,
FEM-Solvers, etc.
Co-simulation is an approach for coupling the simulation systems where each specific tool engages
with one part of the task. Intermediate outcomes such as variables and status information are ex-
changed between these tools after a predefined time step. A co-simulation master is responsible for
coordinating the transfer of the data. The sub-systems are defined as slaves in master-slave concept.
The Functional Mock-up Interface (FMI) is an interface standard for such a co-simulation. Functional
Mock-up Unit (FMU) is a component implementing the FMI. It consists of a zip package which con-
tains an XML description file and the implementation in source code as C language or as binary form.
(Bastian, Clauß, Wolf, & Schneider, 2011)
For cooperation with physical solvers a FMU object can be referenced in AutomationML® as an ex-
ternal reference like for COLLADA and PLCOpen-XML. A new interface class “FMUInterface” which is
inherited from the standard “ExternalDataConnector” can be implemented for this purpose. For fur-
ther explanation see (Moriz, et al., 2011) and (Graeser, Kumar, Niggemann, Moriz, & Maier, 2013)
Implementation of the data exchange functionality
In this paper the plant topology and the geometry of the objects are the main interest points for the
implementation, as the practical work is first succeeded for the visualization of these aspects for
taraVRControl and taraVRBuilder tools. The future implementation of visualization with physics-
engine interface and co-simulation environment will not be discussed further in this chapter.
For the realization of AutomationML® data exchange functionality a total of seven C#.NET libraries
are used. First one is a foreign library named AutomationML®-Engine, which is provided by Automa-
tionML® consortium for free use under the terms of the GNU Library General Public License. One
library is used to convert the inner structure of the own software into CAEX instance hierarchy, and
another one is to gather the inner structure back from the CAEX file. The other 4 libraries are used to
convert the geometry between COLLADA and native geometry format (in this case VRML-Virtual Re-
ality Modeling Language). The interactions between the libraries can be seen in Figure 3.
Figure 3 Software components of the AutomationML® importing and exporting functionalities
The import function parses the CAEX file with the help of AutomationML-Engine, goes through the
“Frame” attributes to position the objects, if an extern COLLADA file is referenced, converts the ge-
ometry to the VRML format with the help of own converter functionality (see Figure 4 ).
Figure 4 Imported pneumatic station demonstrator from AVANTI-Project in taraVRcontrol (AVANTI, 2014)
By export function the quality of the outcome is relatively higher; the hierarchy of objects is repre-
sented as instance hierarchy in CAEX format. A system unit class library, which contains the collection
of own object library components, is used for the classification of instance objects, which is refer-
enced as an extern file in the instance hierarchy file (see Figure 5). The role classes are also refer-
enced externally. The connection points are defined as CAEX “InternalLink” with the help of interface
class “PortConnector”. The position of the objects are written as “Frame” attribute in the instance
hierarchy, and the geometry is converted to COLLADA via own software components and attached as
extern reference in the file.
Figure 5 Extern reference for SystemUnitClassLibrary file
A challenging task in the implementation is the geometry conversion between COLLADA and native
format VRML. COLLADA primitive geometry types, which are defined in “mesh” element, can be
transferred directly as indexed geometry types under “shape” element in VRML. However the indices
of the coordinates, normal vectors, texture coordinates and color vectors should be calculated again
because one to one convergence is not possible. Triangulation methods are used for VRML geometry
types like “box”, “cone”, “cylinder” and “sphere” to represent them as triangle/polygon meshes in
COLLADA. Effect properties like color, ambiance and transparency are parallel in “appearance” in
VRML and “library_materials”, “library_effects” in COLLADA. Even so the differences in the represen-
tation should be regarded.
Discussion and Conclusion
Within this paper an implementation of data exchange interface with the purpose of integrating a
plant layout planning tool to engineering chain of digital factory simulation is presented. The solution
is based on the standardized data exchange format AutomationML. Description of hierarchical object
structure of the plant layout and converting the geometry information were the subjects of main
effort till now.
During this practice some bottlenecks are noticed too. The boundaries of the conversion between
COLLADA and VRML/X3D is reached quickly if boundary representation (BREP) should be handled,
which is supported in COLLADA but not yet in X3D. Non-uniform rational basis spline (NURBS) are
existent in both formats, however it is rare to see in industrial applications. In case of need a compar-
ison of syntaxes in both formats for NURBS should be examined. The kinematic properties of the
elements in COLLADA are also a challenge for the transfer. Rigid body components” in X3D specifica-
tion offers a solution for the kinematic information, but the tool support for these components are
not yet sufficient.
Another requirement is to enhance the data exchange of plant topology in the tool chain. The classi-
fication and transformation of objects in AutomationML® are carried out with the help of role class
libraries. The identification of an imported object or the compatibility of an exported object to exter-
nal tools is only possible if the role class of the object is defined and the role is known for the related
tools. (Hundt & Prinz, AutomationML - Datenaustausch, 2013) Therefore there is a need of develop-
ing a common role class library for the specific purposes such as material flow, logistics, etc. which
are not yet wide defined in the whitepaper of AutomationML®. However these task cannot be ful-
filled without the participating of all partners in the process tool chain.
The data exchange occurs till now only unidirectional, that means a new scene is created with the
import function and with export the previous status of the data is lost. All objects have a unique sig-
nature as “Globally Unique Identifier” (GUID) and header information for the project identification is
also provided. The future steps to allow bidirectional data exchange is a support of versioning in the
whole file and each instance objects. A “ChangeMode” attribute for the objects, which shows the
status of the object if it is “created”, “changed” or logically “deleted”, can be implemented to track
the changes in object-level. In this consideration no object is allowed to be erased physically from the
file and the changed objects should exist with its former and actual form. (Hundt & Prinz,
AutomationML − Engineering Workflow, 2013)
The next step for the defined task is creating a physical scene with help of accumulated data. An
adapter, which describes the elements defined in AutomationML® as objects for the data model of
physics engine, is in progress. An interface to communicate with the co-simulation environment is
also required, which means a content pipeline to FMI should also be implemented.
AutomationML consortium. (2013.). AutomationML Whitepaper. Part 1 - Architecture and general
requirements. Retrieved from
AVANTI. (2014). Test methodology for virtual commissioning based on behaviour simulation of
production systems. Retrieved from
Bastian, J., Clauß, C., Wolf, S., & Schneider, P. (2011). Master for Co-Simulation Using FMI. 8th
International Modelica Conference, Dresden.
Drath, R., & Schleipen, M. (2010). Grundarchitektur: das Objektmodell. In R. Drath, Datenaustausch
in der Anlagenplanung mit AutomationML (p. 55). Springer-Verlag Berlin Heidelberg.
Drath, R., Lüder, A., Peschke, J., & Hundt, L. (2008). AutomationML the glue for seamless
Automation Engineering. Emerging Technologies and Factory Automation, 2008. ETFA 2008.
IEEE International Conference, (pp. 616-623).
Foehr, M., Lüder, A., Hundt, L., & Wagner, T. (2010). Manufacturing System Engineering with
Mechatronical Objects. Otto-von-Guericke University.
Graeser, O., Kumar, B., Niggemann, O., Moriz, N., & Maier, A. (2013). AutomationML as a Shared
Model for Offline-and Realtime-Simulation of Production Plants and for Anomaly Detection.
In Informatics in Control, Automation and Robotics (pp. 195-209). Springer Berlin Heidelberg.
Hundt, L., & Prinz, J. (2013, March 19). AutomationML - Datenaustausch. SPS Magazin 4. Retrieved
Hundt, L., & Prinz, J. (2013, October 29). AutomationML − Engineering Workflow. SPS Magazin 11.
Retrieved from
Kiefer, J. (2008). Mechatronikorientierte Planung automatisierter Fertigungszellen im Bereich
Lüder, A., Rosendahl, R., & Schmidt, N. (2013). Validation of behavior specifications of production
systems within different phases of the engineering process. Emerging Technologies & Factory
Automation (ETFA). IEEE 18th Conference.
Moriz, N., Faltinski, S., Graeser, O., Niggemann, O., Barth, M., & Fay, A. (2011). Integration und
Anwendung von objektorientierten Simulationsmodellen in AutomationML. In Automation
2011 (pp. 37-40).
Reinhart, G., & Wünsch, G. (2007). Economic application of virtual commissioning to mechatronic
production systems. In Production Engineering 1.4 (pp. 371-379).
VDI. (2008). Digitale Fabrik Grundlagen VDI-Richtlinie 4499, Blatt 1. VDI-RICHTLINIEN. Retrieved from
... Therefore they don't need to implement a full fledged AutomationML interface in the most cases. For example software used in simulation or virtual commissioning is built on data structures perfected for computation, feature optimization and visualization like the products of tarakos [1] or EKS InTec [2]. The standardized exchange of "Automation Project Configurations (AR-APC)" [3] is another example where AutomationML is used as an exchange format between applications with heterogeneous specific internal models realized with im-/export logic like in Siemens TIA Portal, EPlan P8, MELSOFT iQ Works or ABB Robot Studio [4]. ...
Conference Paper
Full-text available
The exchange of information about and within production systems at engineering- as well as runtime of the system is a major task within recent industrial applications. Information and communication models or architectures are key enablers for this purpose. One powerful data format in this field is AutomationML. It is an XML based exchange format with meta-modeling capabilities for semantical richness. Due to its expressiveness and broad range of applications the implementation of software solutions with support for AutomationML raise high demands on system design. To help developers to get started general requirements as well as suitable architectures for the implementation of AutomationML applications are collected and discussed in this paper. Based on the collected arguments a reasonable implementation strategy for reference APIs in object-oriented programming languages fitting the specifications of AutomationML is given.
... But an advanced knowledge about the underlying models and concepts is required when applying AML for systems engineering purpose. The utilization of industrial solutions like the taraVRbuilder 2 have shown the advantages of manipulating AML data in an intuitive manner [20]. Still, most of these tools are designed to support engineers at the phase of PLC programming and Virtual Commissioning and lack in capabilities regarding modern skill-based programming approaches. ...
... no kinematics). The kinematic properties of COLLADA 1.5 are a challenge for the transfer [14]. This is due to the absence of automatic kinematics collection and generation from CAD tools. ...
Full-text available
The data interoperation between VF (virtual factory) platform and MES (Manufacturing Execution System) plays an important role in intelligent factory construction. The study focuses on the integration strategy between the VF and the MES by incorporating VF manufacturing assets in two ways, i.e., vertical integration (used for production line performance evaluation) and the horizontal integration (cloud manufacturing based on manufacturing assets services discovery and their composition). The VF platform which integrates the manufacturing assets in two manners is designed as the bottom layer in the entire integration framework. It has been applied to build a four tiers integration model in an intelligent production system construction of a domestic ship manufacturer and verified its feasibility and availability.
Full-text available
The growing complexity of production plants leads to a growing complexity of the corresponding automation systems. Two significant challenges have to be faced: (i) the control devices have to be tested before they are used in the plant. (ii) The diagnosis functions within the automation systems become more and more difficult to implement; this entails the risk of undetected errors. Both challenges may be solved using a joint system model of the plant and the automation system: (i) Offline simulations and HIL tests use such models as an environment model and (ii) diagnosis functions use such models to define the normal system behaviour. Modular models like this can be represented with AutomationML. Additionally, testing and diagnosis require the simulation of these models. Therefore, a corresponding simulation system for AutomationML models is presented here. A prototypical tool chain and a model factory (MF) are used to show results for this approach.
Conference Paper
Full-text available
Simulation bildet ein zunehmend wichtiges Werkzeug in Automatisierungsprojekten. Sie wird bereits erfolgreich für planerische Aktivitäten, wie beispielsweise die Auslegung von Steue-rungsstrategien, Taktzeitoptimierungen, Isometrie- und Netzwerkauslegungen, aber auch als testunterstützendes Mittel eingesetzt. Da die für die Modellierung notwendigen Tätigkeiten (Datensammlung, Modellgenerierung und Parametrierung) i.d.R. manuell und iterativ durch-geführt werden müssen, gilt es auch hier, analog zu den Engineering-Phasen der Automati-sierungstechnik, effizienzsteigernde Methoden anzuwenden. Hierfür erforderlich sind geeig-nete Modell-Datenformate für die Software-basierte Unterstützung der zuvor genannten Tä-tigkeiten in Kombination mit der Nutzung vorhandener Planungsunterlagen. Im Rahmen dieses Beitrags wird hierzu eine Methode vorgestellt, mithilfe derer wiederver-wendbare Simulations-Module in das Beschreibungsmodell einer bestehenden Anlage inte-griert werden können. Die sich hieraus ergebenden Möglichkeiten und Grenzen werden an-hand von Beispielen aus der Fertigungs- und Prozessindustrie erläutert.
Conference Paper
Due to increasing complexity of production systems as well as necessary reduction of time-to-market engineers are faced with new challenges within the engineering process today. To make this process more efficient and to improve the quality of engineering results the use of a previous simulative validation of these results is increasing. But within each engineering phase different simulation tools and models are used which are usually not consistent to each other respectively not reusable in other tools. In this paper a modular, adaptable, and extensible simulation framework will be presented. It is applicable in multiple engineering phases by using libraries of engineering artifacts depending on the process.
Die Architektur von AutomationML ist darauf ausgerichtet, verschiedene Aspekte des Anlagen-Engineerings abbilden und vernetzen zu können: Anlagenhierarchie, Geometrie, Kinematik, Ablaufplanung und Verhalten. Diese Daten werden üblicherweise in unterschiedlichen Werkzeugen aus verschiedenen Domänen erstellt. Folglich muss AutomationML komplexe und vernetzte Informationen abbilden können.
Co-Simulation is a general approach to simulate coupled technical systems. In a master-slave concept the slaves simulate sub-problems whereas the master is responsible for both coordinating the overall simu-lation as well as transferring data. To unify the inter-face between master and slave the FMI for Co-Simulation was developed. Using FMI a master was implemented with simple and advanced algorithms which can be applied depending on the properties of the involved slave simulators. The master was tested amongst others by coupling with SimulationX.
The interaction of heterogenous control hard and software plays a key role in enabling mechatronic production systems to become flexible and agile systems. Nevertheless, control software engineering still tends to be the last step within the development process. To a large extent it is carried out during the commissioning phase of the production ramp-up. On the first hand this leads to a loss of time and quality as well as to a loss of reputation and future orders on the second hand. A method that is referred to as Virtual Commissioning tries to overcome this situation. The aim is to enable control software engineering to, both take over the initiative in system design and to perform important activities earlier in the design process of production equipment. In this paper, the technological and economical scalability of Virtual Commissioning is analyzed. Based on the analysis, a technical concept for a scalable simulation environment is presented. The paper concludes with a new method for the economic application of Virtual Commissioning.
Conference Paper
Within the engineering of manufacturing systems the paradigm mechatronical units is of important interest. To deal properly with mechatronical units within manufacturing system engineering they have to be defined, described and used in an appropriate way establishing a mechatronical engineering process. This paper describes from good practice experience how mechatronical units can be modeled and used within the mechatronical engineering process, how the data describing mechatronical units can be structured within tools and exchange formats, and how mechatronical units can be derived to be re-usable within the mechatronical engineering process. Thereby, this paper gives advices for an efficient and proper application of mechatronical units within engineering processes of manufacturing systems.
AutomationML -the glue for seamless Automation Engineering. Emerging Technologies and Factory Automation
  • R Drath
  • A Lüder
  • J Peschke
  • L Hundt
Drath, R., Lüder, A., Peschke, J., & Hundt, L. (2008). AutomationML -the glue for seamless Automation Engineering. Emerging Technologies and Factory Automation, 2008. ETFA 2008. IEEE International Conference, (pp. 616-623).
  • L Hundt
  • J Prinz
Hundt, L., & Prinz, J. (2013, March 19). AutomationML-Datenaustausch. SPS Magazin 4. Retrieved from