=Paper=
{{Paper
|id=Vol-2428/paper10
|storemode=property
|title=centurio.work – Industry 4.0 integration assessment and evolution
|pdfUrl=https://ceur-ws.org/Vol-2428/paper10.pdf
|volume=Vol-2428
|authors=Jürgen Mangler,Florian Pauker,Stefanie Rinderle-Ma,Mathias Ehrendorfer
|dblpUrl=https://dblp.org/rec/conf/bpm/ManglerPRE19
}}
==centurio.work – Industry 4.0 integration assessment and evolution==
https://ceur-ws.org/Vol-2428/paper10.pdf
centurio.work - Industry 4.0 Integration
Assessment and Evolution
Juergen Mangler1 , Florian Pauker2 , Stefanie Rinderle-Ma1 , Mathias
Ehrendorfer3
1
University of Vienna, Faculty of Computer Science,
Research Group Workflow Systems and Technology, Vienna, Austria,
{juergen.mangler, stefanie.rinderle-ma}@univie.ac.at
2
EVVA Sicherheitstechnologie GmbH, Vienna, Austria,
f.pauker@evva.com
3
CDP GmbH, Vienna, Austria,
matthias.ehrendorfer@acdp.at
Abstract. The introduction of Cyber-physical Systems (CPS) in the
manufacturing domain leads to new concepts of how things such as ma-
chines can interact. While on the traditional shop-floor the communica-
tion is restricted by the strict concepts of the automation pyramid, in
CPS everything can be connected to everything. While the connections
between machines, computing resources and UIs (humans) can be explicit
(i.e., semi hard-coded connections of components through a service bus),
the alternative is a context of how things are connected, in order to foster
maintainability and understandability as well as to enforce the notion of
a loosely coupled system. Therefore, the Workflow Systems and Tech-
nology Group of the University of Vienna in cooperation with the CDP
GmbH is developing a process-based framework utilizing the BPMN no-
tation for orchestration and control of manufacturing use-cases. This
submission focuses on a 4-step integration approach which is intended to
allow small and medium companies a defined evolution towards flexible
and reliable digitalization and automation, utilizing BPM technology. In
order to explain the ideas behind our approach, we present a real-world
scenario realizing the interaction between a lathe, a robot and a loading
station for an autonomous transport system, which is common for our
partners and customers.
1 Introduction
Production companies find themselves in a difficult situation. They are faced
with smaller batch sizes, more variants and reduced throughput time. Digital-
ization and smart factories [10,12] are supposed to be the catalyst to solve all
these problems. Digitalization, in particular, is intended to lead to (i) a higher
transparency of the processes in the company, (ii) better traceability of the prod-
ucts, and (iii) increased productivity caused by a better understanding of the
processes.
Copyright © 2019 for this paper by its authors. Use permitted under Creative
Commons License Attribution 4.0 International (CC BY 4.0).
Juergen Mangler, Florian Pauker, Stefanie Rinderle-Ma, Mathias Ehrendorfer
Yet in the real world introducing the changes to achieve features i) – iii)
requires (1) human resources (programmers and domain experts), (2) a detailed
action plan, and (3) to potentially interrupt the ongoing production. While the
benefits of digitalization are potentially high, especially for small and medium
enterprises (SME) it is hard to find the time, money and human resources to
do so. A further issue is that the gap between information systems and the
shop-floor [8] – the Business Manufacturing Gap [5] – proves hard to close,
especially for highly customized production, as it requires programmers with
intimate domain-knowledge.
To overcome these problems the WST Group of the University of Vienna
is working together with the CDP Center for Digital Production GmbH on the
centurio.work framework [7]. The idea of the framework is to describe everything
on the shop-floor with BPMN processes, to enact this processes with a process
engine, and to describe a step-by-step integration approach.
One major goal is to reduce the effort of integrating machines, humans and
information systems, particularly for SME. For this, we developed the centu-
rio.work framework and a step-by-step integration approach which allows for
– Assessment of the current level of integration.
– Steady build-up of domain knowledge for developers.
– A means for developers and domain-experts to cooperate through BPMN
process models, producing reusable artefacts (process models) for evolving
digitalization / automation efforts.
– Defining milestones for and structuring evolving digitalization / automation
efforts.
The case presented in this paper introduces the centurio.work framework
and the connected step-by-step integration approach and how it is applied to a
real-world manufacturing scenario deployed in a pilot factory1 , closely tracking
the requirements provided by the partners of the CDP GmbH2 , especially the
EVVA Sicherheitstechnologie GmbH3 .
We are focusing on a robotized manufacturing cell, consisting of an industrial
robot by ABB Ltd., a lathe by EMCO GmbH and a custom designed loading
station. Additional elements in the cell (which are not discussed in this sub-
mission) are a presetter by Zoller GmbH, a coordinate measuring machine by
Micro-Vu Europe GmbH, a cobot by Universal Robot (UR) and an automated
guided vehicle (AGV) from Neobotix GmBH. Figure 1 depicts the simplified
layout of the scenario. The red area shows the machines covered in this paper.
This flexible manufacturing cell produces a part called “GV12” which is part of
a valve from a gas motor. The complexity of this product is caused by the small
tolerances, which necessitates the complex overall scenario.
In Sect. 2 we describe challenges as well as methodological and technical
frameworks, that guide the ongoing development of our solutions. In Sect. 3 we
1
http://pilotfabrik.tuwien.ac.at/en/
2
https://acdp.at
3
https://www.evva.com/int-en/
centurio.work - Industry 4.0 Integration Assessment and Evolution
Measuring
Machine
AGV
Robot
Loading
Robot
Station
Scenario Sub-set
Presetter
Lathe Machine Bar Loader
Fig. 1: Simplified layout scenario
describe the step-by-step plan-of-action when introducing BPM technology with
our partners and customers, in order to give us the flexibility and a safety-net
to explore various degrees of automation. In Sect. 4 we present a set of process
models that realize a subset of the scenario mentioned above: the machining by
a lathe and handling by a robot, include human interactions with the system.
We conclude with lessons learned in Sect. 5.
2 Situation faced
Based on the day-to-day work with our customers and partners, we abstracted
the need for a step-by-step approach to digitalization, covering the following
topics. We need step-by-step ...
– ... introduction of BPM notation and technology, to introduce a unified way
of describing manufacturing orchestrations, while not disrupting ongoing
production as well as stable and working production procedures.
– ... build-up of domain knowledge when working with involved information
systems (ERP, MES, CAD-CAM) and machines, which are often tailored to
fit the produced items.
– ... closing of digitalization gaps, when dealing with human-machine interac-
tion or dealing with external partners.
This step-by-step approach is intended to ensure the natural evolution of how
(1) processes and sub-processes are structured, and how (2) the functionality of
individual task is defined.
This is especially important, as digitalization should not be seen as a step
a company takes, but as a progressive journey. While one task, for example
measuring the quality of a produced part, might at first be performed by (a)
a human, it might later be performed fully automatic by a (b) machine, and
Juergen Mangler, Florian Pauker, Stefanie Rinderle-Ma, Mathias Ehrendorfer
eventually be replaced by (c) a prediction algorithm which operates based on
data collected earlier. In all these cases, the process model stays the same and
the label of the task stays the same. But functionality realized by the task
changes. The progress for this particular case thus might be from (a) Worklist
component, to (b) OPC UA4 machine adaptor component, to (c) Data Analytics
(DA) component.
In order to design a robust system, it has to be taken into consideration that
individual components might fail, e.g., when (c) has no access to data, because
of some data collection problem, it might be very well necessary to switch back
to (a). Also, situations where over-automation5 becomes a problem should be
planned for. We thus conclude that digitalization/automation should be tackled
as a step-by-step journey, where decisions can easily be reverted or circumvented
until a suitable problem solution presents itself.
Thus our ongoing work tries to standardize the digitalization journey, based
on already available BPM technology, and based on standard digitalization mod-
els and architectures such as [3], or [9].
In the remainder of this section we will describe components which are part of
the scenario outlined in Sect. 1, as well as technologies, standards and methods
which were considered.
2.1 BPMN-Based Automation
As proposed by [4] CPS-based automation architecture will replace the automa-
tion pyramid architecture (see Fig. 2). This new architecture can be seen as kind
of network where different functions of the previous layers are connected. In the
automation pyramid architecture only modules on neighbouring layers can com-
municate with each other, which gives some kind of structure. This constraint
does not exist in a CPS-based automation, so there is a need for some kind of
other system which creates the context between the functions.
Enterprise ressource
planning level
s
|||
Plant management
level
{..}
|||
+ s
Process control
+ level
Control
||| |||
(PLC) level
Field
level
BPMN/Process-based Automation Hierarchy CPS-based Automation
Automation
Fig. 2: CPS-based and BPMN based Automation [7]
4
https://opcfoundation.org/about/opc-technologies/opc-ua/
5
https://www.businessinsider.de/tesla-robots-are-killing-it-2018-3
centurio.work - Industry 4.0 Integration Assessment and Evolution
As presented in [7] a BPMN-based automation can be the solution. Fig. 2
shows the architecture. Processes seen as functions can be coupled and thus grant
some context. This reduces the complexity and increases flexibility, transparency
and maintainability.
The result of this is centurio.work6 . centurio.work is an orchestration frame-
work based on BPMN processes [7]. It allows context-based dynamic orchestra-
tion of machines, humans and software services. These are the key features of
highly adaptable manufacturing processes necessary for realizing a production
based on Cyber-Physical Production Systems.
2.2 Information Systems
Manufacturing companies are faced with numerous software solutions classified
to their functionality. Fig. 3 shows the different systems from commercial process
to technical processes.
Commercial processes
ERP
FIN
DIS PPS
MES
Customer
Suppliers
SCM Production CRP
CAM / NC
DMS CAD / CAE
PDM
PLM
Technical processes
Fig. 3: Required Software systems in a production company [6]
Traditional systems are generally not yet prepared for the decentralization
necessary for realizing self-controlling production with Cyber-Physical-Systems
[11]. Solutions must become ”smarter” and more flexible.
Additionally, the boundaries between the different systems are blurring. E.g.
modern ERP systems are increasingly being given executive and controlling roles
in addition to their production planning role.
2.3 Theoretical Framework
Important for realizing a modern production is standardization, to combat a
plethora of competing approaches and technologies. Fig. 4 shows the Reference
6
https://centurio.work
Juergen Mangler, Florian Pauker, Stefanie Rinderle-Ma, Mathias Ehrendorfer
Architecture Model Industry 4.0 (RAMI) standardized as DIN SPEC 91345 [3].
It is a three-dimensional map that describes a structured approach to the topic
“Industry 4.0”. It has three dimensions, (i) the product life-cycle based on the
IEC 62890, (ii) the hierarchy levels based on IEC 62264 and IEC 61512 and (iii)
the functional hierarchy in the third dimension.
Life C
IEC 6 ycle & V vels 512
2890 alue
Strea r chy Le IEC 61
m Hiera 264 / /
62
Business IEC
Functional
Information
Communication
Integration
Asset Co
Ente nnected
Wor rpris Wor
Stat k C e ld
ion ente
Typ Con rs
e Field trol
Dev
Prod Dev ice
Inst uct ice
anc
e
Fig. 4: Reference Architecture Model Industry 4.0 [3]
Our solution, centurio.work, is inspired by the design and realizes the run-
time features formalized by RAMI. Type and Instance correlate with well-know
BPM model and instance concepts. centurio.work offers services on the Busi-
ness, Functional, Information and Communication layer. The top three levels
are covered by a process engine, communication is realized by a set of reusable
modelling artefacts (tasks) which implement standard protocols such as OPC
UA, MQTT, REST or even proprietary protocols such as Siemens S7. These
tasks can cover all hierarchy levels from Product to Connected World.
The reason to imagine centurio.work in the context of RAMI is, that in
modern manufacturing scenarios experts from different domains have to work
together. RAMI provides the common vocabulary for people with different do-
main knowledge to talk about a common goal.
3 Action Taken
In order to tackle the needs mentioned in Sect. 2, we developed a step-by-step
integration approach, which encompasses four evolution steps:
1. Soft Integration
2. Process Modelling
3. Augmentation
centurio.work - Industry 4.0 Integration Assessment and Evolution
4. Control
In the remainder of this section we will explain how going through these
evolutions allows for a smooth realization of the scenario outlined in Sect. 1,
Fig. 1. This section also explains process models contained in Sect. 4 which are
the manifestation of the implemented scenario.
3.1 Evolution 1 - Soft Integration
Evolution step 1 focuses on a soft integration approach. By design this step is
intended to not disturb an existing production. The goal is to model and monitor
what is going on on the shop-floor for individual easy to identify resources. This
includes:
a) Tracking new orders from an ERP system.
b) Sourcing of material and scheduling of production resources from an MES
system.
c) Collecting data from all machines, robots and other equipment on the shop-
floor.
This will result in simple runnable process models that collect and structure
data – in effect very similar to software like [1,2].
Most resources already log data into their own private data-tanks, the afore-
mentioned software concentrates on providing adaptors to collect, combine and
present data from these data-tanks.
For our approach this is just a side-effect which materializes in Evolution 2.
Instead of an ex-post view on data the goal is to drive production. The context for
the collected data are processes, and in Evolution 1, the initial contextualization
is done.
Of course the challenge is to connect to custom developed and highly special-
ized machines and writing the glue (adapter) software that realizes something
such as the “Monitoring” depicted in Fig. 5. For this particular task, we experi-
mented with OPC UA interfaces, as well as collecting data through the Siemens
S7 communication protocol. The result is a set of standard tasks, that can be
used and parametrized during modelling, and reused for future customers.
3.2 Evolution 2 - Process Modelling
Evolution step 2 still focuses on not disturbing the manufacturing. The difference
to the previous step is, that the focus is now on how the resources interact with
each other. Main points which should be covered are:
a) How are orders scheduled?
b) How does the sourcing of material interact with the scheduling?
c) Which machines participate in which order in the manufacturing of a part?
Juergen Mangler, Florian Pauker, Stefanie Rinderle-Ma, Mathias Ehrendorfer
The result is the knowledge of how things work together. The contextualiza-
tion of existing data flows is now fully realized through BPM technology. The
data in the private data-tanks is ignored, the data flowing through the process
engine runs the process such as the one shown in Fig. 6b. In this evolution step
the task “Manually Measure” seen in Fig. 6b is a mere placeholder for something
that a human does. In this evolution, the process depicted in Fig. 6b checks if a
human presses a button that starts the machine, and subsequently instantiates
the collection process mentioned in Evolution 1.
3.3 Evolution 3 - Augmentation
Evolution step 3 focuses on digitalization gaps on the shop-floor, i.e., mainly
targets the interaction of humans with machines. As the processes passively
monitor what is going on for the production of individual parts, it becomes
possible to introduce active functionality. For example a machine operator might
take notes on a piece of paper about the quality of produced parts, and later
on write a document in his office that is sent to the customer as a protocol.
Augmentation can take the form of placing a screen at the machine, where the
user is asked to (1) directly input the data for each task with a keyboard, or (2)
giving him a connected caliper to avoid keyboard input.
Thus goals are:
a) Establishing a set of supporting User Interfaces (UI).
b) Setting up independent scheduling – model logic that shows e.g. machine
setup UIs if necessary.
c) Quality Assurance – capture data (e.g. notes) from part prototyping and
production phases.
d) Semantic Machining – capture information about repair of machines and
machined parts.
For all of these goals, the process models are to be extended. The desired
result is to close existing semantic and digitalization gaps that are typically filled
by humans and their knowledge.
In this evolution step the task “Manually Measure” (cf. Fig. 6b) is replaced
by a user interface which can be parametrized from the process model to collect
certain indicators (e.g., the diameter of a produced part).
3.4 Evolution 4 - Control
Evolution step 4 is the final expansion state of centurio.work. In this phase
centurio.work assumes control of the manufacturing.
Typical functions are:
a) Management of software artefacts necessary for production e.g. NC-programs.
b) Triggering the execution of production based on scheduling data.
centurio.work - Industry 4.0 Integration Assessment and Evolution
The result is that humans are guided and are supervising production, not
driving it by their actions such as pressing buttons. As can be seen in the process
presented in Fig. 6a the humans are scanning a product code to start produc-
tion, “MT45 Start” is a sub-process that actively starts the machine, while in
Evolution 3 it might have triggered an UI to tell the user to press that start
button (in evolution 2 nothing of this existed).
4 Results Achieved
The (BPMN) process models7 digitalization and automation effort of the real-
world scenario presented in Sect. 1. Particularly, they realize the scenario de-
picted by the red area in Fig. 1, i.e., the interaction between lathe, robot, and
loading area. Fig. 5 shows how the process models presented in this section (see
) are connected, as well as for which evolution they have been created (see
).
In order to see the interaction depicted in processes models, we also provide
a video8 ., video which demonstrates the concepts explained below.
Orders & Items Handling & Transport
Fig. 6a Fig. 7
≥4 ≥4
≥2 ≥1 ≥1
Manufacturing Steps MI / HMI Monitoring
Fig. 6b
Fig. 5: Process Models: Connections & Evolution (Red Bubble)
Fig. 6b shows which steps are necessary to produce on single GV12 item.
It spawns sub-processes for a truing operation on the lathe, then shows a UI
for manually measuring the parts, and finally collects data from an additional
automatic measuring machine. In an Evolution 4 scenario, this a spawned by a
process model such as Fig. 6a.
In lower evolutions Fig. 6a did not exist, e.g. in Evolution 1 no human inter-
action was modelled, but instead “MI / HMI” just detected he pressing of the
start button on the lathe and then spawned “Monitoring”, as depicted in Fig. 5.
Fig. 7, such as 6a, is a process that has been introduced much later, in
Evolution 4. As depicted in 1, a robot picks produced items out of the machine,
and puts it on a tray, to be transported to the manual measurement station, and
subsequently to the automatic measurement station.
7
Please note the two differences to standard BPMN for the following figures: (1) the
diagrams are auto-layouted by our designer to improve comparability between model
versions, thus the labels are left of the task, not on the task itself; (2) conditions for
decisions, are depicted by {..} on the edge to improve usability on touch screens
8
https://centurio.work/casts/gv12.mp4, Evolution 3
Juergen Mangler, Florian Pauker, Stefanie Rinderle-Ma, Mathias Ehrendorfer
◤ Scan GV12
s
◤ data.num > 0 && data.trays.any? (⭱)
◤ Get Machine State
s
◤ exclusive
{..} ◤ data.state == 'Cancelled'
◤ Spawn GV12 Production
◤ GV12 Turn
◤ MT45 Start
◤ Signal Machining End
◤ Wait For Machining End
◤ Manually Measure
s
◤ GV12 MT45 Take Out
s ◤ exclusive
s ◤ Next Position on Tray {..} ◤ data.qc1_raw.inject(0){ ... } == 0
◤ GV12 IRB2600 Put On Tray
s ◤ Next QR
◤ Measure with MicroVu
s
(a) Coordinate Prod. & Robot Han- (b) Prod. One Single Item
dling
Fig. 6: Part Specific Processes
It shows the interaction with a low-level robot-interface. Robot programs
are managed and loaded from a GIT repository. This includes programs for
extracting the part from the machine, and placing it on a tray, as shown in Fig.
6a, tasks “GV12 MT45 Take Out” and ”GV12 IRB2600 Put On Tray”. After the
programs have been assembled they are load, started, and the robot is monitored
until successful completion of the tasks.
The robot handling is always to be triggered after the step “GV12 Turn”
in Fig. 6b, thus “Signal Machining End” sends a message back to the process
shown in 6a.
5 Lessons Learned
BPM technologies proved very efficient for driving digitalization and automation
efforts on the shop-floor. The strategic value as perceived by our customers is the
high flexibility when combining different technologies (as required by a hetero-
geneous shop-floor) while still providing maintainability and understandability
of the resulting system.
This maintainability and understandability is a direct result of (1) the expres-
siveness of the BPMN notation, and the (2) use of process engine that allows
domain-experts to directly try and modify models and see the effects in the
real-world.
centurio.work - Industry 4.0 Integration Assessment and Evolution
◤ data.state.to_s == "MotorsOn" && ...
◤ data.state.to_s == "MotorsOn"...
◤ data.state.to_s != "MotorsOn"
◤ data.urls.length > 0 (⭱)
◤ Assemble Porgram
◤ Set Fetch Endpoint
◤ Assign Program
◤ Fetch Program
◤ Set Program
◤ Check State
◤ Not started
◤ exclusive
◤ true (⭱)
◤ Logon
◤ Start
s
{..}
{..}
s
{..}
s
s
s
s
Fig. 7: Generic Machine-Tool and Robot Processes (1)
While an exploratory digitalization and automation approach proved success-
ful, it became clear that streamlining the exploration can yield many advantages:
– Structured assessment of the current situation, regarding the integration of
different machines, can highlight problem areas.
– Monitoring the progress in terms of the proposed Evolution steps, gives a
quick situation overview, and allows to efthe old UI drivenllocate existing
human resources. For example Evolution step 1+2 are potentially require
the most software development resources.
– After achieving Evolution step 1, Data Analytics efforts can start.
When looking at Fig. 5 it is important to note “Monitoring”, “Manufactur-
ing Steps”, “MI (Machine Interface) / HMI (Human Machine Interface”, and
“Handling and Transport” have not changed much after they have been created:
– At first “MI” was directly linked to “Monitoring”. As for each order / item
a specific NC Program is started, it is just necessary to monitor the start of
that program. “Monitoring” never changed again.
– “Manufacturing Steps” was then linked to “MI”, to track the multiple ma-
chining steps in the sequence they occurred.
– After that, “MI” was transformed to “MI / HMI”, and “Manufacturing
Steps” was extended to include UIs for collecting manual measurements.
– The introduction of “Order & Items” did free the user from pressing the
button on the lathe, as the lathe is started automatically based on input
from an ERP. But the “MI” part is still the same, because pressing the
button physically, or triggering the machining through software is the same.
– “Order & Items” was evolving over multiple iterations, with the introduction
of new hardware.
Juergen Mangler, Florian Pauker, Stefanie Rinderle-Ma, Mathias Ehrendorfer
Also especially interesting for our partners proved, that versions of the func-
tionality developed for tasks in Evolution 1, 2, 3, 4 still have their purpose as
a fallback mechanism if problems during production occur. Easy switching back
individual tasks from full automation to human work proved to be very trans-
parent and simple to achieve, while introducing no additional complexity for
the factory operators or the process models. While switching back, when done
manually is time consuming, luckily it can be done through logic in the process.
E.g. when the lathe can not be started automatically (error detection logic), the
old UI driven sub-process can be spawned.
Acknowledgments: This work has been partially supported and funded by
the Austrian Research Promotion Agency (FFG) via the “Austrian Competence
Center for Digital Production” (CDP) under the contract number 854187.
References
1. MindSphere: The Cloud-Based, Open IoT Operating System, https://www.
siemens.com/global/en/home/products/software/mindsphere.html, [Accessed
2019-02-15]
2. Predix Platform | GE Digital, https://www.ge.com/digital/iiot-platform, [Ac-
cessed 2019-02-15]
3. DIN SPEC 91345:2016-04 Referenzarchitekturmodell Industrie 4.0 (RAMI4.0).
Tech. rep., DIN Deutsches Institut für Normung e. V. (2016)
4. Bettenhausen, K.D., Kowalewski, S.: Cyber-physical systems: Chancen und Nutzen
aus Sicht der Automation. VDI/VDE-Gesellschaft Mess-und Automatisierung-
stechnik pp. 9–10 (2013)
5. Gifford, C.: The Hitchhiker’s Guide to Manufacturing Operations Management:
ISA-95 Best Practices Book 1.0. ISA, Research Triangle Park, NC (Jun 2007)
6. Kletti, J.: Manufacturing Execution System-MES. Springer (2007)
7. Pauker, F., Mangler, J., Rinderle-Ma, S., Pollak, C.: centurio. work - Modular Se-
cure Manufacturing Orchestration. In: Business Process Management Workshops.
pp. 649–661. Lecture Notes in Business Information Processing, Springer, Berlin,
Heidelberg (2018)
8. Rother, M., Shook, J.: Learning to See: Value-Stream Mapping to Create Value and
Eliminate Muda : Version 1.3 June 2003: Value Stream Mapping to Add Value and
Eliminate Muda. Lean Enterprise Institute,US, Cambridge, Mass, spi edn. (1999)
9. SCE-Cisco-IBM Sgra Team 2011: Smart Grid Reference Architecture. Interna-
tional Business 1, 1–118 (2011)
10. Schuh, G., Gottschalk, S.F., Nöcker, J.C., Wesch-Potente, C.: Flexible Vernetzung
statt starrer Integration : die Zukunft der digitalen Fabrik. wt Werkstattstechnik
online 98(3), 127–131 (2008)
11. e. V. Fachverband Automation, Z.Z.E.E.: Industrie 4.0: MES – Voraussetzung
für das digitale Betriebs- und Produktionsmanagement. Tech. rep., ZVEI - Zen-
tralverband Elektrotechnikund Elektronikindustrie e. V. Fachverband Automation
(2017), https://bit.ly/2HPPF6P, [Accessed 2019-05-31]
12. Westkämper, E., Zahn, E. (eds.): Wandlungsfähige Produktionsunternehmen: Das
Stuttgarter Unternehmensmodell. Springer-Verlag, Berlin Heidelberg (2009)