Status Report

Industrie 4.0 Components

Modeling Examples

November 2016
Preamble
This document has been elaborated in the working
group Modeling Example of the GMA Technical
Committee 7.21 Industrie 4.0 Terms, Reference
Models, and Architecture Concepts. The objective of
this document is to illustrate the concept and the man-
agement of data models within the asset administration
based on a concrete modeling example.

Dsseldorf, November 2016

Prof. Dr.-Ing. Ulrich Epple

Head of Technical Committee 7.21 Industrie 4.0 of
the VDI/VDE Society Measurement and Automatic
Control (GMA)

www.vdi.de
 Authors
The status report has been elaborated in the working group Modeling Example of the GMA Technical Committee
7.21 Industrie 4.0 Terms, Reference Models, and Architecture Concepts, especially by the following members and
guests:

Dr. Annerose Braune; TU Dresden

Markus Diesner; MPDV Mikrolab GmbH, Oftersheim

Guido Httemann; RWTH Aachen University

Matthias Klein; Universitt Stuttgart

Dr. Ulrich Lwen; Siemens AG, Erlangen

Mario Thron; ifak Institut f. Automation und Kommunikation e.V., Magdeburg

Guests

Tobias Manger; evosoft GmbH, Nrnberg

Dr. Michael Okon; Fraunhofer-Institut IOSB, Karlsruhe

www.vdi.de
 Modeling Examples for Industrie 4.0 3

Inhalt
Preamble 1
Authors 2
1 Summary 4
2 The I4.0 Demonstrator 4
2.1 Flexible transportation system (multi carrier system) 6
2.2 Application scenario Adaptable factories (AF) 6
2.3 Application scenario Value-based service (VBS) 6
2.4 Application scenario Seamless and dynamic plant engineering (SDP) 7
2.5 Value network on company level 7
3 Modeling assets of the I4.0 Demonstrator 9
3.1 Introduction and overview 9
3.2 Production Modeling the product and intermediate products 9
3.3 Order process Buying the transportation system and carriers from the
supplier 12
3.4 Design of the modular manufacturing cell 12
3.5 Analysis of data and providing data-driven services 14
3.6 Simulation of the manufacturing cell and virtual commissioning 15
3.7 Development documents 16
4 Summary of modeling of the I4.0 Demonstrator 17
4.1 Carrier 17
4.2 Transportation system 17
4.3 Virtual processing unit 17
4.4 Complete manufacturing cell 18
5 Statements for modeling I4.0 Components 19
5.1 Statement 1 What is modeled as an I4.0 Component is a design decision 19
5.2 Statement 2 Distinction between product and I4.0 Component 19
5.3 Statement 3 For an asset there may be multiple administration shells 19
5.4 Statement 4 The creator of an administration shell decides what
information he passes to others 19
References 20

www.vdi.de
4 Modeling Examples for Industrie 4.0
1 Summary
As subject for illustration the so called Industrie 4.0
Demonstrator was chosen. This is a representative
example of a production application. The Industrie 4.0
Demonstrator illustrates some core aspects of Indus-
trie 4.0 (I4.0) by concretization of various application
scenarios. At first glance, this task appeared quite sim-
ple. The concrete modeling however has quickly shown
a high degree of complexity and associated challenges
which a user in the context of I4.0 is confronted with.
The target audience of this document are users who
want to better understand the content and application of
the Reference Architecture Model Industrie 4.0 (RAMI
4.0), specifically the concept of I4.0 Components and
their administration shells, from an application perspec-
tive.
Some selected concepts of RAMI 4.0 are described and
concrete I4.0 Components of the I4.0 Demonstrator are
proposed and modeled. These descriptions do not claim
to be complete with respect to the concepts of RAMI
4.0 or I4.0 Components.
It should be emphasized that the focus is on concepts.
The realization of the I4.0 Demonstrator itself was
done without any guiding principle of RAMI 4.0 or
I4.0 Components. It was implemented based on cur-
rently commercially available products. The
I4.0 Demonstrator was largely driven by the intended
customer benefits which are addressed by the appro-
2 The I4.0 Demonstrator
User of I4.0 is the manufacturing industry. The manu-
facturing industry has to ensure the required quality of
products and is driven by the challenges to increase
efficiency, shorten time-to-market, and enhance flexi-
bility, see Figure 1.
In consequence, the value added processes along the
entire life cycle of the product have to be reorganized.
I4.0 postulates that this can be done by exploiting the
opportunities of digitization. To illustrate new ways of
organization of the value added processes, the platform
I4.0 has developed application scenarios, see [1]. These
application scenarios describe the vision of the German
industry of their digital future. The I4.0 Demonstrator
refines and implements selected aspects of three of
these application scenarios, namely adaptable facturies
www.vdi.de
priate application scenarios and less by new technical
concepts and solutions.
The I4.0 Demonstrator is based on commercially avail-
able products. I4.0 Components are proposed by en-
riching the existing implementation. This was based on
application scenarios, for which a qualitative benefit for
the involved stakeholders can be identified.
Therefore, the implementation of I4.0 does not require
complete new products, but as has been illustrated
the management of information related to the assets
will be organized in a more structured way. Of course,
it is assumed that in the context of I4.0 new products
will emerge in the market. But which specific products
this really will be, will ultimately be decided by their
market success.
Also, it seems not effective to transfer all the infor-
mation, which today is already available in form of data
sheets, (informal) engineering data, runtime data, etc.,
brute-force into a new formal structure. Organizing
data in a more structured way results in an expense,
partially in the development and production of prod-
ucts, but also in engineering of solutions. This will only
be accepted if there this generates a benefit in total with
respect to all stakeholders concerned.
(AF), value based services (VBS) and seemless and
dynamic plant (SDP), which are described in the fol-
lowing sections, see also Figure 2.
The I4.0 Demonstrator, see [2; 3], and Figure 3, was
built by companies from the management board of the
Platform I4.0. It is a manufacturing cell, where a flexi-
ble transportation system is set up physically and the
modular processing units are shown in the virtual
world. Specifically, there are processing units for fill-
ing, closing, and labeling of bottles, which are typical
production sequences in e.g. pharmaceutical, cosmet-
ics, beverage, or food industry. Energy consumption
and movement information of carriers of the transporta-
tion system are collected and analyzed centrally in the
cloud.
 Modeling Examples for Industrie 4.0 5

Figure 1. Challenges of manufacturing industries (Quelle: Siemens AG)

Figure 2. Application scenarios of the Platform I4.0, see [1, page 6] (Quelle: Siemens AG)

Figure 3. Setup and picture of the I4.0 Demonstrator (Quelle: Siemens AG)

www.vdi.de
6 Modeling Examples for Industrie 4.0
Figure 4. Topology of flexible transportation system (multi carrier system) (Quelle: Siemens AG)
2.1 Flexible transportation system
(multi carrier system)
The transportation system, see Figure 4 consists of 15
linear drives, on which a carrier can be positioned
(largely 1)) independently.
2.2 Application scenario Adaptable
factories (AF)
This application scenario illustrates how the owner of
the manufacturing cell can respond to fluctuating mar-
ket and customer requirements in a flexible way (see
Figure 5). Thus addressing the driver flexibility as part
of the adaptable factory. The owner designs a modular
manufacturing cell based on individually exchangeable
processing units and a transportation system that intel-
ligently adapts to the manufacturing cell and can easily
be integrated into the existing intralogistics. Assuming
that the owner wants to produce bottles without spray
nozzles instead of bottles with spray nozzles, he is
confronted with the need to reconfigure his manufac-
turing cell. The reconfiguration itself can be done by
the user by removing the processing unit for spray
nozzle mounting. The manufacturing cell is intelligent
in the sense that it uses the flexibility offered by the
1)
It must be ensured that there is at most one carrier on a linear
drive. But the multicarrier system provides technical features to
also allow groups of carrier, where are two carriers on a linear
drive.
www.vdi.de
transportation system according to the new configura-
tion of processing units.
2.3 Application scenario Value-based
service (VBS)
In the context of this application scenario the I4.0 De-
monstrator illustrates, how the operator of the transpor-
tation system can increase efficiency 2) and the supplier
of the transportation system can take advantage of new
business models. Energy consumption and movement
information of the individual carriers are collected in a
cloud 3) and evaluated with regard to contamination of
carriers and use of the flexibility of the transportation
system, see Figure 6. Thus, based on data-driven ser-
vices the operator of the transportation system can
increase the availability of the transport system and
thus increase productivity by planning maintenance
timely. As a new business model, the supplier of the
transportation system can offer and bill the transporta-
tion service to the operator based on usage.
2)
This application scenario can be easily extended to illustrate
ensuring the required product quality as well.
3)
It is assumed that all operators of transportation systems provide
their energy consumption and movement information to the cloud
so that benchmarking between different usages of transportation
systems becomes possible.
 Modeling Examples for Industrie 4.0 7

Figure 5. Enhance flexibility reorganization of manufacturing cell (Quelle: Siemens AG)

2.4 Application scenario Seamless 2.5 Value network on company level

and dynamic plant engineering
(SDP) The I4.0 D emonstrator is based on the following cross-
company value network (see Figure 8).
In connection with this application scenario, the I4.0
The manufacturing cell is built by a system integrator
Demonstrator shows how the system integrator can
and then provided to the operator. The system integra-
decrease the time to take the manufacturing cell to
tor integrates the deliveries of the supplier of the trans-
operational state. Thus addressing the driver time-to-
portation system including the carrier and the supplier
market, see Figure 7. By coupling the real application
of the (here: virtual) processing units. He also connects
software (and optionally automation hardware) with a
the transportation system to the cloud so that data-
model of the production process, which for example is
driven services can be offered based on collection and
provided by the supplier of the transportation system
analysis of energy consumption and movement infor-
respectively processing units, errors in the application
mation of the carrier.
software can be detected and fixed prior to hardware
setup. By using this virtual commissioning approach, a
higher quality of the engineering deliverables is
achieved and thus speeding up the ramp up of the man-
ufacturing cell.

Figure 6. Increase efficiency analysis of data and providing data-driven services (Quelle: Siemens AG)

www.vdi.de
8 Modeling Examples for Industrie 4.0

Figure 7. Shorten time-to-market Simulation of the manufacturing cell and virtual commissioning
(Quelle: Siemens AG)

Figure 8. Value network on company level in the interaction of lead market and lead supplier
(Quelle: Siemens AG)

The operator of the manufacturing cell uses the manu-
facturing cell to produce the finished goods (filled and
labeled bottles) based on various intermediate products
based on various raw materials (bottles, caps, spray
nozzles, etc.).
Figure 9 illustrates the value chains of the I4.0 Demon-
strators by positioning them in the value creation pro-
cesses according to [4].

Figure 9. Value chains of I4.0 Demonstrator, based on ([3], page 3) (Quelle: Siemens AG)

www.vdi.de

3 Modeling assets of the I4.0 Demonstrator
3.1 Introduction and overview
Assets represent a value for a company. Assets can
either be part of the real (physical) or virtual world, see
[4; 6]. All assets are represented in the asset layer ac-
cording to the layer axis of RAMI 4.0, see [6]. It is
postulated that each feature, function, data, etc. located
somewhere in the other layers of RAMI 4.0 can be
assigned to an asset in the asset layer of RAMI 4.0.
Therefore we focus on the asset layer of RAMI 4.0. It
is distinguished between asset types and asset instances
according to the lifecycle & value chain axis of RAMI
4.0, for more detail with respect to types and instances
see [7].
Based on the vision of the Internet of Things, assets,
which represent a value for a company and should be
managed in the virtual world, are encapsulated by at
least one administration shell. Any administration shell
encapsulates representative data-models describing or
characterizing one or more aspects 4) of the asset. Con-
sequently, information on assets and the access to the
information are organized in a uniform way, which is a
basis for interoperability 5). The combination of asset
and administration shell is called I4.0 Component, see
[6]. Figure 11 illustrates selected assets of the I4.0
Demonstrator. The left side illustrates the assets of the
real world and the right side illustrates their administra-
tion shell (as part of the virtual word). Note that in
Figure 11, for reasons of simplicity, only assets of the
real world are shown, examples for assets in the virtual
world will be discussed later, too.
Following sections discuss various examples of assets
and information that can be assigned to these assets in
the context of the I4.0 Demonstrator. This was done
without any claim to completeness. The following table
in Figure 12 shows an overview of these assets (column
3) with their submodels (column 4) according to [9],
the other columns show an indication of the form of
interaction between participants of the value network
and the asset following the colour-code in Figure 8.
These interactions may differ and are refer-
red to as roles.
In the interest of brevity these are referred to as cre-
ate indicating that a participant in the value network
creates the asset respectively information and use
indicating access to the asset respectively information.
Note that create/use do not reflect access restrictions.
4)
The term aspect is used here in a colloquial sense.
5)
The focus of this document is on the concepts only and does not
consider implementation issues.
Modeling Examples for Industrie 4.0 9
A gray color in Figure 12 in the first column indicates
that the asset is an asset of the real (physical) world. A
gray color in the second column indicates that this is a
type object according to the lifecycle & value chain
axis of RAMI 4.0, see [7]. Figure 12 summarizes the
assets and their submodels. Note that submodels were
defined in such a way so that they reflect a unique
perspective (e.g. two order forms, one for the supplier,
one for the manufacturer).
Note that it is not discussed the benefits of modeling
the virtual representatives of an asset. Instead, a general
concept called asset administration shell is consid-
ered and this general concept is considered based on
selected scenarios respectively use cases illustrated by
the I4.0 Demonstrator. These examples of usage of
asset administration shells could be implemented
straight forward, i.e. not following the guiding princi-
ples of the asset administration shell as defined in [7;
9].
The following sections describe selected scenarios
respectively use cases. The sequence of scenarios re-
spectively use cases does not follow any systematic
structure, but some of the scenarios resp. uses cases
build on each other.
3.2 Production Modeling the product
and intermediate products
The assets described below are localized in the hierar-
chy levels axis of the RAMI 4.0 cube on the product
level. Note that here we apply the RAMI 4.0 cube is
applied to the operator of the manufacturing cell.
3.2.1 Raw materials
Examples in the case of the I4.0 Demonstrator are the
bottles, caps, or spray nozzles. These assets are only
known by anonymised data, see [5; 6 and 10]. Due to
quality control it is known that e.g. a cap was not
attached correctly, but it is not known, which specific
cap was affected. Thus, these physical assets have no
administration shell in this example and therefore are
not an I4.0 Components.
www.vdi.de
10 Modeling Examples for Industrie 4.0
Bild 10. Focus with respect to RAMI 4.0 (Quelle: Siemens AG)
Bild 11. Selected assets of the I4.0 Demonstrator and their asset administration shells
(Quelle: Siemens AG)
3.2.2 Label
The label is known individually (see [4; 5 and 9]), since
the printed identifier (e.g. QR-code) identifies the label
unambiguously. However, it is not managed along its
lifecycle, but only in conjunction with the manufac-
tured product consisting of bottle, liquid in the bottle,
cap, spray nozzle, label, etc. So the label is another
example with no administration shell and therefore is
no I4.0 Component.
Note that whether the label is known individually or
not is a design decision, see Section 5.1. For example, a
batch number of the charge of the liquid and the expiry
date may be sufficient.
3.2.3 Charge of liquid and finished
products
The charge of liquid is (possibly with reference to all
relevant information from the supplier of the charge of
liquid) managed by the operator of the manufacturing
www.vdi.de
cell along its lifecycle. The finished products, consist-
ing of bottle, liquid in the bottle, cap, spray nozzle and
label are managed by the operator of the manufacturing
cell along their lifecycle as well. The printing of the
label serves for unambiguous identification, so that the
administration shells of the finished products are real-
ized externally) 6), i.e. not attached to the physical prod-
uct.
After delivery a finished product is managed both by
the manufacturer and the user of the product. The man-
ufacturer will usually manage the product over the
entire lifecycle, whether the user still is a design deci-
sion of the user.
6)
A finished product is a bottle with content and label. The bottle
itself cannot provide an administration shell. Therefore the ad-
ministration shell is external from the perspective of the bottle,
for example, provided by sales, purchasing and inventory sys-
tems.
 Modeling Examples for Industrie 4.0 11

manufacturing cell

System integrator

system (including

Supplier of data
processing unit

driven services
Type/Instance

transportation
Real/virtual

Operator of

Supplier of

Supplier of

Supplier of
Submodel

sensors
carrier)
Asset

Raw material bottle

Raw material spray head
Rwa material cap
Printed label
Charge of liquid use
Finished products create
Carrier type
Basis information use use create use use
Development documents,, e.g. internal quality control create
Product catalogue (Supplier) use use create
Order form (System Integrator) use create
Order form (Operator) create
Information about carrier-specific programming of the transportation system use create
Information about internal good inspection create
User documentation resp. inspection and maintenance plan (Supplier) use use create
User documentation resp. inspection and maintenance plan (System Integrator) use create
Usage create
Analysis algorithm create
Physical carrier
Basis information use use create use
Information about manufacturing create
Information about order (Supplier) use use create
Information about order (System Integrator) use create use
Information about order (Operator) create use
Information about engineering w.r.t. the transportation system use create
Information about usage, inspection, maintenance create use
Information about prognoses use create
Transportation system type
Development documents create
Configurability in the sense of considered variants create
Order form use create
Information about programming, e.g. application software, association algorithm use create
User documentation resp. inspection and maintenance plan use use create
Specific physical configuration of a transportation system
Information about manufacturing create
Information about order (Supplier) use use create
Information about order (System Integrator) use create
Information about engineering use create
Information about usage, inspection, maintenance create use use
Virtual processing unit type
Generic model (Supplier) use create
Model for X (System Integrator) create
Modularity model create
Concrete model (software asset) use use create
Executable model (software asset) use create
Physical processing unit
Manufacturing cell type
Modularization concept use create
Information about programming, e.g. application software use create
Complete manufacturing cell
Information about engineering use create
Information about test and commissioning use create
Information about throughput, quality, etc. create use use

Figure 12. Data models of selected assets and their stakeholder (Quelle: Siemens AG)

Figure 13. Modeling and localization of products and intermediate products in RAMI 4.0 Axis hierarchy
levels (Quelle: Siemens AG)

www.vdi.de
12 Modeling Examples for Industrie 4.0
3.3 Order process Buying the
transportation system and carriers
from the supplier
3.3.1 Carrier
The manufacturer of the carrier provides a product
catalogue for its carrier. This product catalogue de-
scribes characteristics of the carrier types. The system
integrator specifies his requirements based on an order
form. This order form is associated to the carrier type,
and will be based on the corresponding characteristics
as specified within the product catalogue 7).
In case of a specific order, the manufacturer of an in-
stance of a carrier will deliver specific information (e.g.
the serial number) to the system integrator, who buys
the carrier, but some information will not be disclosed
(e.g. information on manufacturer-internal quality
controls). The system integrator will also create specif-
ic information about the instance of the carrier (e.g.
information about his incoming goods inspection). The
system integrator will pass some but not all of this
information to his customer, i.e. the operator of the
manufacturing cell.
The operator of the manufacturing cell will also use a
carrier type, for example in order to be able to reorder a
carrier from the supplier of the carrier, without having
to involve the system integrator. But his carrier type
also includes additional information (e.g. carrier usage).
The design of the carrier-type typically will be done by
the system integrator, but the information of the specif-
ic instances is not available to the system integrator.
Note that Figure 14 illustrates a unique physical asset
and each stakeholder in the value network manages its
own (logical) administration shell of this physical asset.
3.3.2 Transportation system
The ordering process of a transportation system follows
the same principle as for ordering a carrier. However,
there will be no reorder by the operator of the transpor-
tation system. The operator typically will order spare
parts only, but not an entire transportation system.
The transportation system is a complex system. The
supplier of the transportation system will therefore
manage an internal configuration model, which de-
7)
At the moment such dependencies between submodels cannot be
modeled in the context of I4.0 Components.
8)
Typically the user of a carrier does not manage an own carrier
type for the ordering process, but only a reference to the carrier
type of the supplier of the carrier.
www.vdi.de
scribes all variants considered by the development of
the transportation system. Typically, the supplier will
not offer all of these variants to the market, but will
offer to his customer, e.g. based on a product configu-
rator, specific variants according to the sales releases
only. Some of the possible variants offered to the mar-
ket are described in [10].
3.4 Design of the modular
manufacturing cell
The system integrator designs a modular manufacturing
cell, where individual processing units can be replaced
so that the manufacturing cell can be reorganized with-
out requiring a reprogramming especially of the
transportation system. For this purpose the system
integrator designs a modularization principle in the
form of a type object of the manufacturing cell. This
modularization concept describes the pre-designed
possible reorganization options and defines require-
ments for the processing units. These requirements
must be satisfied by the modularity modes of the pro-
cessing units in order for them to be integrated seam-
lessly.
For example the modularization of the manufacturing
8) cell of the I4.0 Demonstrator is as follows, see Fig-
ure 15:
n The first linear drive is needed to identify the in-
coming carrier and to feed it in a targeted manner
to the first processing unit. The final linear drive is
needed to catapult the exiting carrier from the flex
route, i.e. the 15 linear drives, out to the surround-
ing intralogistics. Between the individual pro-
cessing units, at least one linear drive is required to
disconnect two neighboring processing units with
respect to the material flow and, for example, to
enable other group formations of the carriers.
n The control of the first, the last and the linear
drives between the processing units is managed by
the manufacturing cell. The control of the linear
drives associated actuators to a processing unit are
managed by the respective processing unit.
n The overall coordination of transportation is man-
aged by the manufacturing cell, for example by
implementing a pull-principle in which a pro-
cessing unit requests one (or more) carrier via the
transportation system from the preceding pro-
cessing unit. Other, completely different control
algorithms are possible.
 Modeling Examples for Industrie 4.0 13

Figure 14. Submodels for ordering a carrier (Quelle: Siemens AG)

Figure 15. Modularization of the manufacturing cell (Quelle: Siemens AG)

unit are necessary. Whether this will be entered man-

ually after physical reorganization or whether this can
be detected automatically after a successful physical
reorganization will not be discussed here.

The programming of the manufacturing cell and their

constituents is as follows:

n The application program of the transportation

Figure 16. Modeling of the transportation sys-
tem (Quelle: Siemens AG)
When reorganizing the manufacturing cell by replacing
a processing unit, notifications to the manufacturing
cell with respect to the new order of processing units
and the assignment, which linear drive is controlled by
which unit i.e. the manufacturing cell or a processing
system has to control the linear drives and read the
sensor values. The system integrator uses the engi-
neering environment for the transportation system
here specifically SIMOTION SCOUT to create
the application program. The application program
later runs on the drive control system here spe-
cifically SIMOTION. The linear drives, sensors,
drive control system, and other components ac-
cording to Figure 4 may be made available by the
supplier of the transportation system to the system
integrator as separate assets. It is also possible that
the supplier of the transportation system only pro-

www.vdi.de
14 Modeling Examples for Industrie 4.0
vides dedicated interfaces to the system integrator
and not assets with uniform administration
shells. This is the case here; where the supplier of
the transportation system delivers appropriate li-
braries together with the engineering system here
specifically SIMOTION SCOUT, see Figure 16.
For this reason and for the sake of clarity, the line-
ar drives, sensors 9), drive control system, and other
components of the transportation system are not
explicitly listed in Figure 12.
n The programming of the overall coordination will
not be described here, as there is no additional as-
pect on the modeling.
n The modularity model of the processing units has
to specify an interface between the commands and
requests exchanged between the processing unit
and transportation system as well as between the
processing unit and linear drives respectively sen-
sors. A challenge is the sharing of common re-
sources for execution of application programs, for
example, if the visualization of a processing unit
has to be displayed on a central human-machine-
interface station. The visualization (or for example
the control code) can be modeled as a submodel of
the processing unit, but there have to be considered
additional requirements resulting from the runtime
systems of the resources.
The type-instance concept according to [7] has some
limitations when it comes to software assets, which are
derived from several class descriptions. Strictly
speaking, the level of information is disregarded and
looked at at a functional level. In order to list software
assets in Figure 12, software assets are assigned to
submodels of type objects.
3.5 Analysis of data and providing
data-driven services
Here we focus on the additional role of the provider of
data-driven services. In contrast to other applications
described for example in section 3.3 or 3.4, which are
engineering scenarios, here we consider a runtime
scenario. Note that in this sense the description in sec-
tion 3.2 is a runtime scenario, too. If it comes to the
implementation of an administration shell in runtime-
scenarios, additional requirements with respect to effi-
9)
The supplier of the position sensor may provide an administration
shell for his product, but the supplier of the transportation system
does not pass this administration shell to his customers. Therefore
the supplier of the sensor is listed in Figure 12, but there is no
create/use relation, because there are no submodels for the sensor
in Figure 12.
www.vdi.de
cient communication and access have to be taken into
consideration, but this is not in the scope of this status
report.
An asset of the data driven service provider is the anal-
ysis algorithm, which takes usage information as input
and generates carrier prognoses with respect to contam-
ination of a carrier. This algorithm is modeled as part of
the carrier type of the data driven service provider.
Note that for profound analysis results in addition to
the usage information about the carrier appropriate
context information must be provided, for example, if
carriers are driven in groups or if special operating
conditions occurr. An example of a special operating
condition is the following: before a reconfiguration of
the manufacturing cell, the flex route is emptied. In this
case the carriers are catapulted with increased power
from the flex route. Such effects need to be removed by
the analysis algorithm. Thus, the data-driven service
provider will not only maintain a model of the carrier,
but also of the complete manufacturing cell.
The system integrator will ensure that the right infor-
mation is exchanged a secure way between operator of
the manufacturing cell and data-driven service provider
in. In our example, the system integrator will also im-
plement an association of the energy data from a drive
to the affected carrier. The carrier can only be identi-
fied when entering the flex route; therefore the trans-
portation system has to track the positions of the carri-
ers along the flex route and assigns the measured ener-
gy of a drive to the affected carrier.
At runtime this association algorithm will execute on
the drive control system (i.e. SIMOTION) according to
Figure 4 and requires the collection of position infor-
mation from the drives. Therefore the system integrator
has to decide whether he will model the drive control
system (i.e. SIMOTION) and the drives as independent
assets. This has been discussed already in the context of
the design of the modular manufacturing cell.
The IT infrastructure of the data-driven service provid-
er (i.e. the cloud, etc.) can be modelled also as an asset
with an administration shell. Doing this, represents a
move from a more conceptual modelling of technologi-
cal assets to a more implementation related modelling
of information technology. Therefore this aspect is not
included in Figure 12.

Figure 17. Submodels for analysis of data and providing data-driven services (VBS) (Quelle: Siemens AG)
Figure 18. Submodels for simulation of the manufacturing cell and virtual commissioning (SDP)
(Quelle: Siemens AG)
3.6 Simulation of the manufacturing
cell and virtual commissioning
We assume that the system integrator purchases a phys-
ical processing unit from the supplier, which is done in
analogy to the transportation system and is therefore
not described in more detail. But the supplier of the
processing unit also provides an executable model of
the ordered physical processing unit. Therefore, the
supplier of the processing unit manages internally a
generic model of its processing unit, which includes the
configurability in the sense of avoidable variants and
further aspects. Certain aspects will be made available
to the system integrator, similar as discussed in the
context of ordering a transportation system.
The system integrator develops a model of the pro-
cessing unit, which he has derived from the model
provided by the supplier and which in addition satisfies
Modeling Examples for Industrie 4.0 15
the requirements of his modularity model; see Sec-
tion 3.4. This is the basis for the engineering services of
the system integrator with respect to this scenario. The
supplier of the processing unit provides a concrete
model of the physical and delivered processing unit,
which is a software asset (see Figure 12, Concrete
model (software asset)). Via appropriate engineering
services the system integrator creates an executable
model from the concrete model (see Figure 18). The
engineering services include e.g. a parameterization of
the model, but also the preparation for using the model
in a suitable simulation environment. The system inte-
grator integrates this executable model
n the executable models for the other processing
units,
n an executable model with respect to the coordina-
tion of the processing units by the manufacturing
cell,
www.vdi.de
16 Modeling Examples for Industrie 4.0

Figure 19. Development documents as assets (Quelle: Siemens AG)

n and an executable model of the transportation 3.7 Development documents

system.
The result is a simulation environment for the complete
manufacturing cell.
Assume that the supplier of the transportation system
does not provide a simulation model. In this case, the
system integrator will create a corresponding simula-
tion model, for example based on a hardware-in-the-
loop approach:
n he couples a real drive control system (e.g. SIMO-
TION) with a simulation tool (e.g. SIMIT),
n he loads the application software for the drive
control system created when programming the
transportation system on the drive control sys-
tem,
n he creates a process model of the transportation
process, which replicates
via the simulation tool
This section shortly discusses the modeling of typical
development documents, such as requirement and
design specifications, but also user documentation, in
the form of assets 10).
Typically, there are company's policies, according to
which such documents have to be created. Often there
exist in this context template documents, for example
based on MS Word, but also on different specific soft-
ware tools, which are used as a basis for a concrete
development document. These template documents are
assets in the form of type objects. Specific development
documents are created based on a copy & modify pro-
cedure from these template documents. These specific
development documents are modeled in Figure 12 as
submodels of type objects, for example of the carrier or
transportation system. Documents that are made avail-
able to a customer typically are created by an additional
editorial process taking the development documents as
basis. Here as well, the type-instance model according
to [7] has its limits.

the actuator and sensor level of the manufactur-

ing cell, and

n he provides the instructions between the higher

control level and the drive control system over the
simulation tool

This scenario provides a view only on some basic prin-

ciples. Depending on the conceptual and technical
approach with respect to the simulation models provid-
ed by the supplier there will be a wide variety of con-
cepts and implementations of the simulation of the
manufacturing cell. An important aspect is also the
extent to which the system integrator uses the simula-
tion only for his own purpose, or whether it is also
delivered to the operator of the manufacturing cell.

10) These explanations can be transferred and applied also

to design and engineering processes, which are based on
product families and lines respectively platforms.

www.vdi.de

4 Summary of modeling of the
I4.0 Demonstrator
4.1 Carrier
The carrier is located in the hierarchy levels axis on
the field device level (see Figure 10). Information
about the lifecycle of each instance is managed by the
supplier of carriers (e.g. information about the produc-
tion of the carrier), the operator of the manufacturing
cell (e.g. the energy consumption and movement in-
formation of the carrier) and the cloud provider (e.g.
predicted degree of contamination).
But each stakeholder in the value chain uses different
type models of the carrier: For example,
n the supplier of the carrier intends to manage the
development documents,
n the system integrator intends to program the trans-
portation system (e.g. assigning energy values
from the drives to the affected carrier),
n the operator intends to reorder carriers, and
n the cloud provider intends to analyze contamina-
tion.
As already mentioned, Figure 20 illustrates a unique
physical carrier and each stakeholder in the value net-
work manages its own (logical) administration shell of
this physical asset. The access rights for the specific
(logical) submodels have to be defined and managed by
the owner of the (logical) administration shell accord-
ing to the principles summarized in Figure 12.
Figure 20. Localization of carrier in axes hierarchy levels and lifecycle & value-chain
(Quelle: Siemens AG)
Modeling Examples for Industrie 4.0 17
4.2 Transportation system
The transportation system is located in the hierarchy
levels axis on the station level. The supplier pro-
vides the transportation system (including engineering
tools, libraries, etc.) to the system integrator as an in-
stance object.
The supplier also manages the delivered configurations
of the individual transportation systems over their
lifecycles. He also manages in the context of devel-
opment and sales a transportation system of a specific
type (e.g. development documents or configurability in
terms of released variants). The system integrator or-
ders a specific variant from the supplier and manages
his own derivative of the generic transportation system
type (e.g. for ordering or programming). The operator
uses the transportation system supplied by the system
integrator and manages this instance through its lifecy-
cle with respect to usage and maintenance.
4.3 Virtual processing unit
The virtual processing unit is located in the hierarchy
levels axis on the station level. The basic principles
are similar to those explained for the carrier and the
transportation system.
www.vdi.de
18 Modeling Examples for Industrie 4.0

Figure 21. Localization of transportation system in axes hierarchy levels and lifecycle & value-chain
(Quelle: Siemens AG)

Figure 22. Localization of processing unit in axes hierarchy levels and lifecycle & value-chain
(Quelle: Siemens AG)

Figure 23. Localization of manufacturing cell in axes hierarchy levels and lifecycle & value-chain
(Quelle: Siemens AG)

Only the following special aspects are noted here: it is
assumed that the simulation is performed by the system
integrator internally only and will not be delivered to
the operator; therefore the operator is not shown in
Figure 22. In addition, the focus here is on software
assets; as already mentioned are modelled software
assets as submodels of type objects. Modeling of the
physical processing station is done similar to that of the
transportation system.
4.4 Complete manufacturing cell
The complete manufacturing cell is located in the hi-
erarchy levels axis on the work center level. This
I4.0 Component is designed by the system integrator.
The system integrator designs type information of the
manufacturing cell and delivers instance information to
the operator. The operator will manage information
about the usage and maintenance of the manufacturing
cell over its lifecycle.

www.vdi.de

5 Statements for modeling I4.0 Components
Based on the modeling executed by the members of the
team the following statements are important:
5.1 Statement 1 What is modeled as
an I4.0 Component is a design
decision
This statement has been illustrated at various points in
the previous sections. The use case or the purpose
drives the structuring of a system in assets respectively
I4.0 Components.
Various scenarios how on the concept of asset admin-
istration shell can be used from an application point of
view have been illustrated. Nevertheless, individual
decisions are necessary whether an asset is modeled as
an I4.0 Component (with asset administration shell) or
the asset is modeled in a traditional way. Although for
each described scenario that asset administration shells
are not mandatory, sometimes conventional approaches
not following the guiding principles of an asset admin-
istration shell are sufficient. This depends on the bene-
fits generated by the concept asset administration
shell for the specific use case.
5.2 Statement 2 Distinction between
product and I4.0 Component
Not every product has to be an I4.0 Component and
vice versa not every I4.0 Component has to be a prod-
uct:
n Examples for products that are not I4.0 Compo-
nents, are raw material (bottle, cap, spray nozzle,
etc.), if they are purchased from a supplier who
does not manage his products along their lifecycle.
n An example for an I4.0 Component which is not a
product is the modularity model of the processing
units. This asset will be managed by the system in-
tegrator internally and will not be provided as
product to the outside.
n A system integrator can create an asset, this asset
is provided as an I4.0 Component to a user, but
this I4.0 Component cannot be bought on its own
as a product, but only in the context of an overall
solution. As example the system integrator could
provide the executable models of the processing
units as an I4.0 Components, but the user can use
Modeling Examples for Industrie 4.0 19
these I4.0 Components only in the context of an
appropriate simulation environment supplied by
the system integrator.
n Even the complete manufacturing cell could be
delivered not as an I4.0 Component, but neverthe-
less the manufacturing cell contains several I4.0
Components.
5.3 Statement 3 For an asset there
may be multiple administration
shells
This statement is already illustrated in the previous
section using the example of the carrier. In particular,
the various stakeholders in the value network can speci-
fy individual administration shells for their specific
purposes.
After the production of a product, there are usually (at
least) two administration shells: on the one hand an
administration shell held by the producer of the product
and on the other hand an administration shell held by
the user of the product.
The one and only administration shell, in this respect
for an asset does not exist. Just as models are always
specific representations of an original driven by a spe-
cific purpose, this also applies to the administration
shell.
5.4 Statement 4 The creator of an
administration shell decides what
information he passes to others
For example, a system integrator decides typically in
negotiation with his suppliers and its customers what
information of an administration shell will be provided
to others. As a consequence, the administration shell of
assets, which have been composed to an overall sys-
tem, may not be accessible for the user of the overall
system.
The sensors of the transportation system could be pro-
vided by the supplier of the sensors as an
I4.0 Component with an administration shell, but the
supplier of the transportation system does not provide
these administration shells to a system integrator of the
complete production cell, see Figure 16.
www.vdi.de
20 Modeling Examples for Industrie 4.0

References
[1] Aspects of the Research Roadmap in Application Sce-
narios, http://www.plattform-i40.de/I40/
Redaktion/EN/Downloads/Publikation/
aspects-of-the-research-roadmap.html (02.11.2016)
[2] Industrie 4.0-Demonstrator,
https://www.youtube.com/watch?v=4dmA1QtAUzo
(02.11.2016)
[3] VDI/VDE-Gesellschaft Mess- und Automatisier-
ungstechnik: VDI-Statusreport Industrie 4.0 Wert-
schpfungsketten, April 2014, https://www.vdi.de/
fileadmin/vdi_de/redakteur_dateien/sk_dateien/
VDI_Industrie_4.0_Wertschoepfungsketten_2014.pdf
(02.11.2016)
[4] VDI/VDE-Gesellschaft Mess- und Automatisierungs-
technik: VDI-Statusreport Industrie 4.0 Gegenstn-
de, Entitten, Komponenten, April 2014,
https://www.vdi.de/fileadmin/vdi_de/redakteur
_dateien/sk_dateien/VDI_Industrie_4.0_Komponenten
_2014.pdf (02.11.2016)
[6] Das Referenzarchitekturmodell RAMI 4.0 und die
Industrie 4.0-Komponente,
http://www.zvei.org/Themen/Industrie40/Seiten/
Das-Referenzarchitekturmodell-RAMI-40-und-die-
Industrie-40-Komponente.aspx (02.11.2016)
[7] Life-Cycle-Management for Automation Products and
Systems, ZVEI 2012, http://www.zvei.org/
publikationen/guideline_lifecycle_en.pdf (02.11.2016)
[8] VDI/VDE-Gesellschaft Mess- und Automatisier-
ungstechnik: VDI-Statusreport Fortentwicklung des
Referenzmodells fr die Industrie 4.0 Komponente
Struktur der Verwaltungsschale, https://www.vdi.de/
fileadmin/vdi_de/redakteur_dateien/gma_dateien/
6146_PUB_GMA_ZVEI_Statusreport_-_RAMI
_4-0_Struktur_der_Verwaltungsschale_Internet.pdf
(02.11.2016)
[9] M. Diesner: CP-Klassifizierung Benennung von
Komponenten im Industrie 4.0-Umfeld, Automation
2015

[5] VDI/VDE-Gesellschaft Mess- und Automatisier- [10] Multi Carrier System, http://w3.siemens.com/
ungstechnik: VDI Status Report Industrie 4.0 Tech- mcms/mc-solutions/en/mechanical-engineering/
nical Assets Basic terminology concepts, life cycles packaging-machine/mcs/Pages/multi-carrier-
and administration models March 2016 (02.11.2016) system.aspx (02.11.2016)

The VDI

Speakers, Designers, Network Engineers

The fascination for technology drives us forward: For 160 years, the VDI Association of German Engineers has provid-
ed vital impetus for new technologies and technical solutions for improved quality of life, a better environ-ment and
greater standard of living. With some 155,000 personal members, the VDI is the largest technical and scientific associa-
tion in Germany. As a voice for engineers and technology, we actively help shape the future. Each year, more than
12,000 volunteer experts process the latest findings to promote our technology base. As the third largest issuer of tech-
nical regulations, the VDI is a partner for the German economy and science.

www.vdi.de
VDI Verein Deutscher Ingenieure e.V.
VDI/VDE Society Measurement and Automatic Control (GMA)
Dr. Heinz Bedenbender
Phone. +49 211 6214-485
bedenbender@vdi.de
www.vdi.de