Model-Based Engineering and Virtual

Commissioning of Cyber-Physical Manufacturing

Systems – Transportation System Case Study
Petr Novák∗,k , Petr Kadera‡ , and Manuel Wimmer∗
∗ Christian
Doppler Laboratory on Model-Integrated Smart Production,
Business Informatics Group,
Institute of Software Technology and Interactive Systems,
TU Wien, A-1040 Vienna, Austria
Email: firstname.lastname@tuwien.ac.at
k Czech Technical University in Prague, CZ-16636 Prague, Czech Republic
‡ Czech Institute of Informatics, Robotics, and Cybernetics,

Czech Technical University in Prague, CZ-16636 Prague, Czech Republic

Email: petr.kadera@cvut.cz

Abstract—Emerging manufacturing systems are becoming

complex while their engineering and ramp-up phases have to
be as short as possible in order to decrease the reaction time
to new market demands as well as to minimize production line
down-times causing financial losses. Since engineering knowledge
is not shared satisfactorily, virtual commissioning of industrial
plants is very complicated. This paper contributes to a better
synthesis and analysis of manufacturing lines by integrating the
simulation of manufacturing systems with the tool Siemens Plant
Simulation and their engineering with Schmid P’X5 Configurator
for Montratec. The proposed approach is based on the model- Fig. 1. Simulation modeling as a transformation of engineering plans and
based techniques and it is demonstrated on a laboratory-scaled plant engineering as a transformation of optimized simulation models in the
use-case showing its efficiency. iterative loop.

I. I NTRODUCTION
Engineering and starting up manufacturing systems are
time-consuming issues. Simulations play crucial roles for
optimization of manufacturing system structures and configu-
rations, for virtual commissioning of automation and control
systems as well as for training human operators. However,
simulations are frequently represented as islands in the engi-
neering and runtime phases. This leads to inconsistencies and
inefficiencies that should be solved and improved, respectively.
This paper presents a new approach for coupling engineer-
ing and simulation of industrial manufacturing systems. The
method lies at the cutting edge between research and industrial
automation practice, as it is focused on techniques and tech-
nologies for modeling, analysis, and intelligent control; yet
considers them mainly in the conjunction with the two tools
that are frequently used in practice. The presented approach is
motivated in Fig. 1, which shows how the utilized tools P’X5
Configurator for Montratec1 by Schmid and Plant Simulation2
1 Available online: http://schmid-group.com/en/markets/automation/
montrac/montrac-configurator/
2 Available online: https://www.plm.automation.siemens.com/en/products/
tecnomatix/manufacturing-simulation/material-flow/plant-simulation.shtml
978-1-5090-6505-9/17$31.00
c 2017 IEEE
by Siemens can be integrated and fit together.
The proposed approach how to reach the aforementioned
vision is based on the usage of Model-Driven Engineering
(MDE) [1]. MDE is an emerging paradigm in software engi-
neering that counteracts the increased complexity of modern
software systems by developing systems on a higher-level of
abstraction, which provides the basis for enhanced engineering
support [2]. This shift is reflected in the emerging area of
Industrie 4.0 and thus MDE seems as one of the promising
methodological backbones for reaching the requirements on
modern industrial systems. Since system engineering and
analysis frequently rely on various models already, MDE in
this area typically proposes models of models, that are called
meta-models.
To overcome problems of a majority of models, which
are their actuality and required levels of abstractions, it is
beneficial to focus on “liquid” models and meta-models. The
term liquid stresses the fact that models as any kinds of
engineering artifacts should not be isolated and static, but
cooperative and evolutionary. The data included in the models
are then up-to-date and consistent. This is a very important
requirement because in many projects in practice, simulations
are built based on unfinished models and thus the system
under simulation and the actual created system are more or
less different. Furthermore, it is beneficial to leverage isolated
models to model repositories, which are not only a set of
models but they are accompanied by technical means how to
store and to access the liquid models as well [3].
The great advantage of MDE is a very easy and efficient
way how to develop transformers of data between various data
formats with different data models. In the proposed approach,
the data is not transformed directly, but with the use of an
intermediate format AutomationML, which is a promising
industrial standard being needed and adopted by industrial
companies [4].
The remainder of this paper is structured as follows. Sec. II
summarizes the state of the art. Sec. III discusses the proposed
solution in details. Sec. IV illustrates the proposed approach on
a laboratory-scaled manufacturing system, and finally, Sec. V
concludes and proposes further work.
II. R ELATED W ORK
Functional Mockup Interface3 (FMI) is a technical solution
for co-simulation and model exchange. In both cases, the
simulation modules are converted into an executable platform-
independent code in C language that are called Functional
Mockup Units (FMUs). FMUs are ZIP files and each of them
includes the simulation unit itself (i.e., the simulation module).
In addition, each FMU is accompanied with an XML model
description describing the interfaces of the unit. The benefits
of FMI/FMU are that (i) it enables bridging diverse simulation
languages and platforms, as well as (ii) it hinders details about
the implementation of simulation units. The FMI technology
could be used for seamless integration of both tools in future.
However, its support would be required for both tools, but
they are not available on the source code level and thus it
is currently not possible to modify them internally. For this
reason, the proposed approach solves the problem on the meta-
model level of the data formats and tool interfaces.
AutomationML is an industrial data format standardized
as IEC 62714 that is discussed in [4]. AutomationML can
be considered as an integration format for the following
standardized data representations: CAEX for plant topology
information, COLLADA for geometry and kinematic infor-
mation and PLCopen XML for logic information. News about
this format can be found at the web page of the AutomationML
Office4 . A survey among experts on the preferred way of
exchanging project data between tools is addressed in [5].
The majority of preferences was a standardized data exchange
format, which was followed by the common project data base
to integrate several tools. These preferences are in compliance
with the approach proposed in this paper, as the standardized
data exchange format that is supported here is AutomationML.
Although AutomationML is mainly intended for point-to-point
data exchange, it can be utilized within complex engineering
tool chains as well [6].
3 Available online: https://www.fmi-standard.org
4 Available online: https://www.automationml.org
P’X5 Configurator 1 2 Siemens
AutomationML
for Montratec Plant Simulation
Metamodel of 4 Metamodel of 3 Metamodel of
Pxpz files Transformations AutomationML Transformations tool API
Fig. 2. Proposed solution relying on the model-based techniques for data and
knowledge transformations.
In the CAEX part of the AutomationML data format, the
entire plant/system is represented as an “instance hierarchy”.
The devices are represented as “instances”, which are “internal
elements” of the instance hierarchy. The type of each device is
represented as “system unit class”, as each internal element is
in this case an instance of a system unit class. The connections
between devices are represented as “internal links”.
III. P ROPOSED S OLUTION
The proposed approach is depicted in Fig. 2. The transfor-
mations labeled 1 and 2 refer to transforming and inte-
grating data about available components in the transportation
system that can be used for creating a transportation line.
In addition, the topology information including the selection
of specific components and their connections could be trans-
formed and integrated in these steps as well. However, this data
are considered to be a result of performed simulations in the
Siemens Plant Simulation tool. Hence, topology information
transformation is not expected in these steps.
The transformations labeled 3 and 4 are related to
delivering the information about the topology of the transporta-
tion system to the engineering tool. From the perspective of
traditional simulation engineering, these transformations can
be considered as reverse engineering as the topology of the
real system is obtained from a simulation. However, we have
to emphasize that the topology is optimized based on the
simulations performed and based on built-in algorithms of the
Siemens Plant Simulation tool.
In more details, the transformation step 1 in Fig. 2 means
that available components of the manufacturing/transportation
systems are summarized and expressed in the appropriate
form. The AutomationML data format is highly suitable for
this purpose as it supports the system unit classes. Although
they are called classes, they do not pose classes from the
object-oriented programming point of view, but rather proto-
types. They combine features dedicated to classes with object
features, so that they can be considered as “clabjects”. The
benefit is that the system unit classes can for example define
attribute/parameter values beyond their declaration. In the
current version of P’X5 Configurator for Montratec, it seems
that this step has to be done manually as the tool does not
provide any satisfactory support for that. This issue can be
overcome by requiring delivery of the component library from
the industrial vendor as a mandatory condition when purchas-
ing a system. This is expected in the near future and industrial
companies with strong positions on the market already require
this kind of information in some cases nowadays. Within this
paper, the AutomationML system unit class library has to be
implemented manually, but this step could be enabled and
automated in future. For completeness, the specific topology of
the manufacturing/transportation system could be transformed
in this step as well, but this paper assumes that the topology
is a result of optimized simulations.
Having the available components represented as system unit
classes in the AutomationML data format, the transformation
can proceed with step 2 . In this step, the AutomationML
file is systematically analyzed and appropriate components
are instantiated on the library level in the Siemens Plant
Simulation tool via its API. For using model-based techniques,
the meta-model of AutomationML discussed in [7] is used.
Consequently, these library components are considered as
available entities for creating the topology of the system and
its simulation model.
After the human-centric creation of the topology of the
manufacturing system in the Siemens Plant Simulation tool,
optimization of the topology by built-in algorithms, and ver-
ification of all functional and non-functional requirements by
users by means of the process simulation, the transformation
of data can proceed with step 3 . This step is focused
on individual component realizations. All components from
Siemens Plant Simulation model are realized as instances
within the instance hierarchy of the AutomationML data
format. In principle, these objects are instances of the system
unit classes, but as we already mentioned, this relationship
should be better characterized as clones of the prototypes.
Step 4 expresses the transformations of instances from
the AutomationML instance hierarchy into the Pxpz files
of P’X5 Configurator for Montratec. This file is technically
a compressed folder of type gz that consists of a set of
compressed sub-folders including:
• Information about the project with time-stamp numbers;
• Article list;
• Structure of the system and its properties;
• Conflicts in the system design;
• Configuration of all of the artifacts.
The analysis done in relationship with the structure of Pxpz
files of the P’X5 Configurator for Montratec proved that it
should be possible to implement this transformation with the
model-based techniques as well. However, step 4 poses
the most laborious transformation step that requires further
investigations, which is the main reason why this paper is
written as a work-in-progress contribution.
IV. L ABORATORY T RANSPORTATION S YSTEM U SE -C ASE
To illustrate the proposed approach in practice, the manufac-
turing system for educational purposes is used. The main part
of the system is a transportation system Montrac by Schmid,
which is a monorail system frequently used in industrial
practice. The testbed considered in this paper includes two
Montrac shuttles for transporting pallets with goods weighting
up to 24 kg, and two positioning units guaranteeing precise
positions of shuttles with pallets that can be operated and
positioned by robots. The system is accompanied by two
robots Kuka iiwa, which are responsible for operating a stock,
and transporting goods between the transportation Montrac
system and 3D printers. Since the robots and 3D printers are
not yet physically available in the real laboratory system, we
focus on the transportation part of the manufacturing system
in this paper.
The simulation in Siemens Plant Simulation is shown in
details in Fig. 3. This tool enables to optimize the topology
of the system, to calculate approximate characteristics such as
maximal throughput, times needed for specific operations, and
other tasks to facilitate the engineering and operation phases of
manufacturing systems. These characteristics are estimations
only, more complex and advanced tools have to be utilized for
their detailed calculation and analysis. An example of a more
detailed tool is Siemens Process Simulate, which includes
specific control strategies of robots and other concrete parts
of the manufacturing line behavior description.
The transportation system in Schmid P’X5 Configurator
for Montratec is depicted in Fig. 4. This tool is used for
specification of the whole system in terms of listing part
numbers of all components, their quantities, and others.
The real-world realization of this educational transportation
and manufacturing system has been built at the Czech Institute
of Informatics, Robotics and Cybernetics5 (CIIRC) that was
established at the Czech Technical University in Prague. The
system is new, but in the ongoing work, we would like to
perform further and more complex experiments.
V. C ONCLUSION AND F UTURE W ORK
Modeling and analysis of manufacturing systems pose im-
portant issues for virtual commissioning of industrial plants
as well as their automation and control systems. However, the
engineering of simulations is time-consuming issue that suffers
from the problems with synchronizing engineering data with
the solutions that are realized in industry. This paper addresses
both issues under one roof, while the proposed solution is
focused on the two well-known tools by leading companies in
the respective areas.
The proposed approach can significantly simplify and speed
up the design and redesign of manufacturing systems including
the cyber-physical ones. It contributes to the emerging tech-
nologies and approaches in industrial automation classified as
Industrie 4.0 applications.
In future work, the proposed approach should be enhanced
for other tools having similar or wider functionalities. In
addition, we would like to implement all needed details and
discuss them with the tool providers.
ACKNOWLEDGEMENT
The authors Petr Novák and Manuel Wimmer would like to
thank industrial partners and the Christian Doppler Research
Society. This work has been funded by the Austrian Federal
Ministry of Science, Research and Economy and the National
Foundation for Research, Technology and Development.
5 Available online: www.ciirc.cvut.cz
 Fig. 3. Screenshot of the Siemens Plant Simulation tool including the laboratory transportation use-case.

Fig. 4. Screenshot of the Schmid P’X5 Configurator for Montratec tool including the laboratory transportation use-case.

The work done by Petr Kadera has been supported by
institutional resources for research by the Czech Technical
University in Prague, Czech Republic.
R EFERENCES
[1] M. Broy and A. Schmidt, “Challenges in engineering cyber-physical
systems,” Computer, vol. 47, no. 2, pp. 70–72, Feb 2014.
[2] M. Brambilla, J. Cabot, and M. Wimmer, Model-Driven Software Engi-
neering in Practice, 1st ed. Morgan & Claypool Publishers, 2012.
[3] J. D. Rocco, D. D. Ruscio, L. Iovino, and A. Pierantonio, “Collaborative
repositories in model-driven engineering,” IEEE Software, vol. 32, no. 3,
pp. 28–34, May 2015.
[4] N. Schmidt and A. Lüder, AutomationML in a Nutshell. AutomationML
e.V. Office, 2015.
[5] N. Schmidt, A. Lüder, H. Steininger, and S. Biffl, “Analyzing require-
ments on software tools according to the functional engineering phase in
the technical systems engineering process,” in Proceedings of the 19th
IEEE International Conference on Emerging Technology and Factory
Automation (ETFA), 2014.
[6] S. Biffl, E. Mätzler, M. Wimmer, A. Lüder, and N. Schmidt, “Linking
and versioning support for AutomationML: A model-driven engineering
perspective,” in Proceedings of the 13th IEEE International Conference
on Industrial Informatics (INDIN), July 2015, pp. 499–506.
[7] L. Berardinelli, E. Mätzler, T. Mayerhofer, and M. Wimmer, “Integrating
performance modeling in industrial automation through AutomationML
and PMIF,” in Proceedings of the 14th IEEE International Conference
on Industrial Informatics (INDIN), July 2016, pp. 383–388.