WORKING PAPER
Exemplification of the Industrie 4.0
Application Scenario Value-Based
Service following IIRA Structure
In collaboration with
Imprint
Publisher
Federal Ministry for
Economic Affairs and Energy (BMWi)
Public Relations
10119 Berlin
www.bmwi.de
The Federal Ministry for Economic Affairs and
Energy was awarded the audit berufundfamilie®
for its family-friendly staff policy. The certificate
is granted by berufundfamilie gGmbH, an initiative of the Hertie Foundation.
Text and editing
Plattform Industrie 4.0
Bertolt-Brecht-Platz 3
10117 Berlin
Design and production
PRpetuum GmbH, Munich
Status
April 2017
Print
Bonifatius GmbH, Paderborn
Illustrations
iStock – zoranm (title), iStock – Fertnig (p. 4),
iStock – danchooalex (p. 6), iStock – AlexRaths (p. 8),
iStock – danchooalex (p. 23)
This brochure is published as part of the public relations work
of the Federal Ministry for Economic Affairs and Energy. It is
distributed free of charge and is not intended for sale. The
distribution of this brochure at campaign events or at information stands run by political parties is prohibited, and political
party-related information or advertising shall not be inserted
in, printed on, or affixed to this publication.
This publication as well as further publications
can be obtained from:
Federal Ministry for Economic Affairs
and Energy (BMWi)
Public Relations
E-mail: [email protected]
www.bmwi.de
Central procurement service:
Tel.: +49 30 182722721
Fax: +49 30 18102722721
2
Content
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
The Industrie 4.0 Demonstrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Introduction to IIRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Industrie 4.0 Demonstrator mapped to IIC Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Setup and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Application Scenario VBS – Value-Based Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Usage in the Context of the Industrie 4.0 Demonstrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Business Viewpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Stakeholder and Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Values and Experiences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Key Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Fundamental Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Usage Viewpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Activity “replacement of a carrier” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Activity “recording on request additional data” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Activity “analysis of energy consumption information of a carrier” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Activity “generation of a cleaning recommendation” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Activity “benchmarking of a transportation system” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Functional Viewpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Implementation Viewpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Cross-cutting Relations between the Viewpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Lifecycle Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Lifecycle Perspective of Plattform Industrie 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Examples for Life of a Transportation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Examples for Life of Assets related to a Carrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Lifecycle Perspective of IIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Mapping of the Lifecycle Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors and Guests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3
Foreword
Objectives
In the context of Industrie 4.0 and the Industrial Internet
different architecture models (RAMI 4.0, IIRA …) have been
developed in the past. The presented paper documents the
successful endeavor for a better understanding of different
viewpoints. This is generated by mapping the scenario
approach of the Plattform Industrie 4.0 to the Industrial
Internet Reference Architecture (IIRA).
This document has been elaborated in the working group
“modeling example” of VDI/VDE-GMA Technical Committee 7.21 “Industrie 4.0 – Terms, Reference Models, and
Architecture Concepts”. It includes contributions of and the
discussion with the working group “Research and Innovation” of the Plattform Industrie 4.0. In addition, the content
of the paper has been discussed with various persons
involved in the IIC with the result that this paper was
endorsed by the Steering Committee of the IIC. The objective of this document is to illustrate the concept of viewpoints of the Industrial Internet Reference Architecture
(IIRA) based on a concrete modeling example
We like to thank the members of the working group
“modeling examples” of VDI/VDE Society Measurement
and Automatic Control (VDI/VDE-GMA) Technical Committee 7.21 “Industrie 4.0 – Terms, Reference Models and
Architecture Concepts” for having taken this approach and
the members of the working group “Research and Innovation” of the Plattform Industrie 4.0 for their contribution
and open discussion.
The presented elaboration is an important part for moving
forward to a unified point of view, which is required for
solving the challenges of the vertical and horizontal integration including the aspects of related life cycles. And its
results are supported by the strong committee of VDI/VDEGMA and the Plattform Industrie 4.0 thanks to the open
minded and integrating procedure chosen.
Prof. Dr. Ulrich Epple
Johannes Diemer
“The Industrial Internet Consortium applauds Plattform
Industrie 4.0 on its newly published body of work entitled
'Exemplification of the Industrie 4.0 Application Scenario
Value-Based Service following IIRA Structure'. We look forward to continuing our collaborative efforts with Industry
4.0 as works similar to this and others continue to advance
IIoT.”
John Tuccillo, Chairman of the IIC Steering Committee
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 Industrie 4.0 by concretization of various application scenarios. In this paper we focus
on the application scenario VBS – Value-Based Service,
which was proposed as a joint scenario of Plattform Industrie 4.0 and Industrial Internet Consortium (IIC).
The target audience of this document is users who want to
better understand the application of IIRA especially in the
area of manufacturing industries. Some selected concepts
of IIRA are illustrated, but these descriptions do not claim
to be exhaustive with respect to the concepts of IIRA.
The working group “Modeling Example” of VDI/VDE-GMA
7.21 contributed with the report “Modeling Examples of
Industrie 4.0 Components”, see [1], to a better understanding from an application perspective of various conceptual
approaches in the context of Industrie 4.0 (RAMI4.0, Industrie 4.0 component, assets, etc.). In a similar way there is a
need to understand the approaches and concepts of IIC
compared to Plattform Industrie 4.0 from an application
perspective. Examples are the viewpoints of IIRA, functional viewpoint of IIRA versus layer axis of RAMI4.0, solution lifecycle of IIC versus lifecycle & value chain axis of
RAMI4.0. Therefore the same subject for illustration was
chosen.
4
The Industrie 4.0 Demonstrator
A primary user of Industrie 4.0 is the manufacturing industry.
The manufacturing industry has to ensure the required
quality of products and is driven by the challenges to
increase efficiency, shorten time-to-market and enhance
flexibility, see Figure 1.
As a consequence the value added processes along the
entire life cycle of the product have to be reorganized.
Industrie 4.0 postulates that this can be done by exploiting
the opportunities of digitalization. To illustrate new ways
of organizing the value added processes, the Plattform
Industrie 4.0 has developed application scenarios, see [2], [3]
and Figure 2. These application scenarios describe the
vision of the German industry to guide their digital future.
The Industrie 4.0 demonstrator refines and implements
selected aspects for three application scenarios, namely AF,
VBS and SDP. In this paper we focus on the application
scenario VBS – Value-Based Service, which was proposed as
a joint scenario of Plattform Industrie 4.0 and IIC, see [4].
The Industrie 4.0 demonstrator, see [5], [6] and Figure 3, was
built by the companies serving on the management board
of the Plattform Industrie 4.0. It is a manufacturing cell,
where a flexible transportation system is set up physically
and the modular processing units are modeled in the information1 world. Specifically, there are processing units for
Figure 1: Challenges of manufacturing industries ([1] derived from Siemens AG)
ensure required
increase
shorten
enhace
quality
efficiency
time-to-market
flexibility
Source: Siemens
1
We use information world and virtual world as synonyms.
T H E I N D U S T R I E 4 . 0 D E M O N S T R ATO R
Figure 2: Application scenarios of Plattform Industrie 4.0 ([3, page 6])
customer
Marketing
Sales
IPD
Product Line
Product
Product Development
Lifecycle
Management
Planning
SP2
SDP
Factory and
Product Line
Maintenance
SAL
Maintenance
Production
Production System Lifecycle Management
and Disposal
Production
Engineering
Planning
Planning
AF
Discontinuation
Management
Disposal
Factory
HTI
TAP
VBS
Production
Operation
Service
After-Sales
Services
OCP
Production System
Erection
Lifecycle Management
Recycling
Maintenance
Basis GMA 7.21
Service
Manufacturing Company
supplier
Product-type related
Production system related
Order related
Service related
Source: Siemens
filling, closing, and labeling of bottles, which are typical
production sequences in e. g. pharmaceutical, cosmetics,
beverage, or food industries. Energy consumption and
movements of carriers in the transportation system are
collected and analyzed centrally in a service platform.
Figure 3: Setup of the Industrie 4.0 demonstrator (Siemens AG)
MindSphere
simulation PC
HANA
transportation system
simulation unit
motion control system connector box
visualization system
Source: Plattform Industrie 4.0
5
6
Introduction to IIRA
The Industrial Internet of Things (IIoT) describes systems
that connect and integrate industrial control systems with
enterprise systems, business processes, and analytics. Existing industrial control systems mostly focus on optimizing
the IIoT assets2 in a single physical plant. The control sys-
tems of the Industrial Internet must move up a level, and
optimize operations across IIoT asset types, fleets and customers located all over the world, see Figure 4, where the
different colors in the figure indicate IIoT assets from different suppliers:
Figure 4: Industrial Internet of Things systems (according to [7])
Industrial Internet
Customer A
Customer B
Customer C
Source: IIC
2
The definition of “asset” in the context of IIC is more specific than the understanding of Plattform Industrie 4.0, for more details see chapter
“Lifecycle Perspective” in this report. To make this difference clear we use here the term “IIoT asset” for “asset” in the understanding of IIC.
I N T R O D U C T I O N TO I I R A
7
Validation
Figure 5: Industrial Internet Architecture Viewpoints (according to [7])
Business Viewpoint
Guidance
Usage Viewpoint
Functional Viewpoint
Implementation Viewpoint
Source: IIC
The Industrial Internet Reference Architecture (IIRA), see
[7], provides guidance and assistance in the development,
documentation, communication, and deployment of IIoT
systems. The corresponding document is primarily for IIoT
system architects, which can use the IIRA systematically as
an architectural template to define their unique IIoT system requirements and design concrete architectures to
address them.
Core of the IIRA are the so called IIRA viewpoints, see
Figure 5:
• Business viewpoint – attends to identification of stake-
holders and their business vision, values, and objectives
in establishing an IIoT system in its business and regulatory context.
• Usage viewpoint – addresses expected system usage. It is
typically represented as sequences of activities involving
human or logical users that deliver intended functionality to ultimately achieve the fundamental system capabilities.
• Functional viewpoint – focuses on the functional com-
ponents in an IIoT system, their structure and interrelation, the interfaces and interactions between them, and
the relationships and interactions of the system with
external elements in the environment, to support the
usages and activities of the overall system.
• Implementation viewpoint – deals with the technologies
needed to implement functional components, their
communication schemes, and their lifecycle procedures.
These elements are coordinated by activities (usage
view­point) and support the system capabilities (business
viewpoint).
There are cause and effect dependencies between the viewpoints. Typically a viewpoint guides the design of the viewpoint below and a viewpoint serves for validation of the
viewpoint above.
8
Industrie 4.0 Demonstrator mapped to
IIC Concepts
Setup and Scope
Application Scenario VBS – Value-Based Service
In order to have a common understanding of the setup and
considered scope of the Industrie 4.0 demonstrator we first
explain the usage of the application scenario VBS – Value-­
Based Service in the context of the Industrie 4.0 demonstrator.
Today typically a product provider delivers a product to a
customer and does not have any feedback from the usage
of his product by the customer. The application scenario
VBS – Value-Based Service is based on the innovation
hypothesis that in the future delivered products will be
Figure 6: Value-network of application scenario VBS – Value-Based Service (Plattform Industrie 4.0)
today
tomorrow
Product
Provider
Customer
product
Customer
Service
Provider
Platform
Provider
product
usage data
Source: Plattform Industrie 4.0
Product
Provider
9
I N D U S T R I E 4 . 0 D E M O N S T R ATO R M A P P E D TO I I C CO N C E P T S
connected to a service platform, data from the usage of the
product by the customer will be fed to the service platform,
and based on the usage data a service provider can offer
data-driven value-added services to the customer. Figure 6
illustrates the participating stakeholder3, the underlying
value network, and the new information flow from the
customer to the service platform as the basis for new datadriven services. For more details we refer to [4].
Factory) and SDP (Seamless and Dynamic Engineering of
Plants) shown in Figure 2 –, thus, we do not consider these
subsystems in this context.4
Usage in the Context of the Industrie 4.0 Demonstrator
• Stakeholders have a major stake in the business and
Within the context of this application scenario we consider
the setup of the Industrie 4.0 demonstrator according to
Figure 7. The IIoT asset under consideration is the physical
transportation system of the Industrie 4.0 demonstrator,
and alternative transportation systems operating at other
customers have to be considered in this context. Note that
the simulation PC, the simulation unit, and the visualization system serve primarily for the purpose to illustrate the
other application scenarios – namely AF (Adaptable
9
Business Viewpoint
The business viewpoint includes the following concepts,
for details see [7]:
strong influence over its direction. These participants
include those who drive the conception and development of IIoT systems in an organization. They are often
recognized as key strategic thinkers and visionaries
within a company or an industry.
• Vision describes a future state of an organization or an
industry. It provides the business direction towards
which an organization executes.
Figure 7: Setup of Industrie 4.0 demonstrator in the context of VBS – Value-Based Service
(modified according to Siemens AG)
MindSphere
simulation PC
HANA
transportation system
simulation unit
motion control system connector box
Scope of IIoT asset
...
visualization system
Scope of IIoT
Source: Plattform Industrie 4.0
3
To be more precise there should be distinguished between platform provider and platform operator. These different roles could be implemented by different companies. The key role for the considered scenario is the platform operator.
4
Of course simulation and visualization can be part of IIoT systems as mentioned in the description of the Functional Viewpoint, but simulation and visualization according to Figure 7 has another focus.
10
I N D U S T R I E 4. 0 D E M O N S T R ATO R M A P P E D TO I I C CO N C E P T S
Figure 8: Usage of application scenario VBS – Value-Based Service
today
tomorrow
System
integrator
System
integrator
transportation system
carrier
transportation system
carrier
Operator of
transportation
system
Supplier of
transportation
system
usage data of transportation system
Operator of
transportation
system
Provider of
data-driven
services
Operator of
service
platform
Supplier of
transportation
system
Source: Plattform Industrie 4.0
• Values and experiences reflect how the vision may be
perceived by the stakeholders who will be involved in
funding the implementation of the new system as well
as by the users of the resulting system. They provide the
rationale as to why the vision has merit.
• Key objectives are quantifiable high-level technical and
ultimately business outcomes expected of the resultant
system in the context of delivering the values and experiences. Key objectives should be measurable and timebound.
the operator of a service platform, who delivers and operates a service platform5. Today, typically a supplier of a
transportation system provides this to a system integrator,
who configures and installs the transportation system at
the site of the operator. Therefore we have introduced an
additional role of a system integrator. Note that other
usages of the application scenario could be possible also.
We will use a color code according Figure 9 for stakeholders, parties (see chapter Usage Viewpoint), and their interests in this paper continuously:
• Fundamental capabilities refer to high-level specifica-
tions of the essential ability of the system to complete
specific core business tasks. Key objectives are the basis
for identifying the fundamental capabilities.
Stakeholder and Vision
Figure 9: Color code for stakeholder and parties
Operator of transportation system
Supplier of transportation system and
provider of data-driven services
System integrator
To the setup of the Industrie 4.0 demonstrator as illustrated
in Figure 7 we apply the application scenario VBS – Value-­
Based Service as shown in Figure 8. The product under
consideration is a machine, i. e. the transportation system,
and the role of the service provider is implemented by the
product provider, i. e. the supplier of the transportation system. We assume the establishment of a new stakeholder, i. e.
5
Operator of service platform
Figure 10 shows the involved business stakeholders in form
of a value-network:
We focus on small and medium companies. Larger companies often wish to operate the service platform by themselves.
I N D U S T R I E 4 . 0 D E M O N S T R ATO R M A P P E D TO I I C CO N C E P T S
11
Figure 10: Value-network of Industrie 4.0 demonstrator ([1] derived from Siemens AG)
tomorrow
lead market
System integrator
lead supplier
Operator of transportation system
Supplier of transportation system
Supplier of transportation system
value creation processes
System integrator
Provider of datadriven services
Operator of
service platform
Operator of transportation system
today
information flow
Source: Siemens
Today’s value chain is preserved, but in the future enlarged
in the sense that the transportation system is connected to
a service platform. We assume that this will be done by the
system integrator, but of course this could also be executed
by the supplier of the transportation system or even by the
operator itself. With this connection of the transportation
system to the service platform, usage data of the transportation system can be collected by the operator of the service platform. The operator of the service platform provides access to the supplier of the transportation system
and thereby enables him to analyze the usage data of all of
his transportation systems in productive operation. The
findings of the analysis will be provided in the form of new
data-driven services by the supplier of the transportation
system to the operator.
Values and Experiences
The main idea of the application scenario VBS – Value-­
Based Service as we consider it in the context of the Industrie 4.0 demonstrator is illustrated in Figure 11. The operator of the transportation system can increase efficiency
because of early detection of faults and the supplier of the
transportation system can take advantage of new offerings
and business models.
Figure 11: Value propositions of application scenario VBS – Value-Based Service (Siemens AG)
Increase of efficiency, e.g. by early fault detection
service platform
service platform
supplier of machine
Source: Siemens
New offerings, e.g. benchmarking of machines
12
I N D U S T R I E 4. 0 D E M O N S T R ATO R M A P P E D TO I I C CO N C E P T S
Experiences
Example
Generally the operator expects optimized usage of his
machines. But he typically does not have the subject matter
expertise for realizing this value for (unplanned) events
because of the complexity of the machines. Therefore he
requests for higher availability of the machines. On the
other hand, the supplier of the machine could offer higher
availability if he has access to usage and health information
for his machines. In analyzing this information he can offer
new data-driven services to increase the availability of his
machines. In addition, the supplier of a machine could
offer and bill the manufacturing services of the machine to
the operator based on usage.
An example in the context of the Industrie 4.0 demonstrator is the collection of energy consumption and movement
information of the individual carriers in a service platform.
This information is analyzed and evaluated with regard to
contamination of carriers and the flexibility of the transportation system. A typical new service could be a recommendation from the supplier to the operator to clean a carrier. Thus, based on this data-driven services provided by
the supplier of the transportation system the operator of
the transportation system can increase the availability of
the transportation system by scheduling timely main­
tenance.
Values for the Operator of the Machine
Key Objectives
The data-driven services of the supplier of the machine
contribute to early fault detection and rapid fault isolation
and therefore result in higher availability of the machine
and the entire plant. In addition the operator saves main­
tenance expenses and resources.
Key objectives should be that the system is measurable and
time-bound. To accomplish these objectives, there should
be a concrete business plan. Since all activities of VDI/VDEGMA and Plattform Industrie 4.0 are precompetitive, we
focus in this context on the principal revenue mechanisms
as shown in Figure 12.
In the case of continuous data access by the machine supplier the operator could take advantage of longer warranty
periods for the machine offered by the supplier of the
machine.
In the longterm the operator could even lower investment
costs through leasing the machines with usage-based billing, i. e. “machine as a service”.
The operator of a machine will pay for the new data-driven
services from the supplier of the machine. Various business
models are possible including adequate gain and risk sharing models. The supplier of the machine will pay, on a payper-use basis, for his usage of the service platform. Various
business models are possible depending on the number of
connected machines, the amount of usage data over time,
and the use of basic analytic capabilities provided by the
operator of the service platform.
Values for the Supplier of the Machine
The supplier can offer new data-driven services, e. g. the
prediction of downtimes of the machine, and based on the
knowledge of the usage of the machine he can offer new
warranty models.
The supplier gets transparency about its own fleet of
machines. This knowledge can be fed back into the design
and engineering to improve the machine and can be used
to offer new benchmarking services to the operators.
In the long-term the supplier could offer and bill for
manufacturing services of his machines based on usage.
The operator of the service platform will amortize his
upfront costs for development, and the running costs for
operation of the service platform, over all suppliers of
machines using the service platform. The development of
the data-driven services is an upfront investment of the
service provider. The connection of a machine is a onetime process; it must ultimately be amortized on a case-­­bycase consideration.
I N D U S T R I E 4 . 0 D E M O N S T R ATO R M A P P E D TO I I C CO N C E P T S
13
Figure 12: Principal revenue mechanisms
different operators of
different instances of
machine n
different operators of
different instances of
machine 1
Pay-per-use cash flow
Upfront investment
pay-per-use for
data-driven services
pay-per-use for usage
of service platform
...
machine 1
...
development of
service platform
development of datadriven services
connection of machine
to service platform
...
machine n
Source: Plattform Industrie 4.0
A concrete businessplan should answer the following
questions:
• From the perspective of a supplier of a machine and
data-driven services the number of expected connected
machines over time, the costs for the connection of a
machine, and the upfront costs for the development
of data-driven services have to be estimated and the
pricing model for data-driven services has to be defined.
• From the perspective of an operator of a service plat-
form the number of expected products (e. g. machines)
connected to the service platform and the upfront costs
for the development of the service platform have to be
estimated and the pricing model for the usage of the
service platform has to be defined.
Perspective of the Operator of the Machine
The operator of a machine is ready to invest only if he has
appropriate benefits, i. e. the operator of a machine has primary interests in automation, reliability and quality, but to
be competitive in the market the supplier of the machine
and provider of data-driven services and the operator of
the service platform have to offer specific capabilities creating additional benefits for the operator of the machine.
As a consequence, the operator of the machine does not
request specific additional capabilities in the initial negotiations with the suppliers of machines, but when presented
with enhanced value propositions hopefully he will use the
new data-driven services offered by the supplier of the
machines.
The operator of the machine has the following interests:
Fundamental Capabilities
• From a strategic business point of view he is not willing
We structure the fundamental capabilities according to the
involved stakeholder. In addition to the capabilities we discuss the main interests of the stakeholder, see [8]6. We will
focus on a migration scenario, where an existing plant will
be upgraded, effectively modernized in the sense that new
data-driven services will be available to the operator of the
machine.
6
to pass on any competitiveness relevant information to
anybody else, i. e. the operator of machine will define
which information about his production is passed on to
others. For example, the production process could be a
core competence of the operator or the utilization rate
of the machine could lead to conclusions on his pricing
strategy.
This paper addresses in the following concepts of core modeling: stakeholder, tasks, and interests. We follow this approach, but instead of
“tasks” we use in alignment with IIRA “capability”.
14
I N D U S T R I E 4. 0 D E M O N S T R ATO R M A P P E D TO I I C CO N C E P T S
• From a financial point of view he wants to optimize
his cash flow. For example, the operator could request
for a pay per use model for the machine. This aspect is
addressed by the fundamental capability “manufacturing
as a service” of the supplier of the machine.
• From a customer and market point of view he wants to
guarantee the ability to deliver his own products and to
guarantee satisfaction of his customers. For example, the
operator wants to guarantee the time to deliver or the
required quality.
• From a technical point of view he wants to monitor the
machines with regard to quality guarantees, availability
guarantees, etc. to avoid unforeseen downtime of the
machines. He is interested in increased productivity
through better use of the machine, for example to create
less wear or maximize energy savings. He also wants to
increase productivity through better planning, for example by suggestions for optimized maintenance or optimized order sequences. These aspects are addressed by
the fundamental capability “new data-driven services” of
the supplier of the machine.
In addition the operator will not accept unnecessary
restrictions caused by the new data-driven services, for
example in the case of a physical conversion of the
machine such as the changing of a carrier or the provider of data-driven services request for additional
information to validate his conclusions. A refinement of
this interest is addressed by the activities “replacement of
a carrier” and “recording on request additional data” as
illustrated in the Usage Viewpoint.
Furthermore the operator is interested in ensuring
maintenance with increasing complexity of the
machines and decreasing availability of qualified specialists. Thus, he is interested in new ways for efficient
execution of maintenance.
Perspective of the Supplier of the Machine and Provider of
Data-driven Services
The supplier of the machine is the “driver” with respect to
creating a compelling value proposition for the operator of
the machine by providing new data-driven services, but he
relies on an operator of a service platform.
The supplier of the machine and provider of data-driven
services has to provide the following fundamental capabilities:
• The supplier of the machine will offer “new data-driven
services”. He will evaluate usage information of the
machine in order to draw conclusions based on his
knowledge of the machine. He will sell these findings to
the operator of the machine in the form of new datadriven services.
A refinement of these capabilities is addressed by the
activities in the “analysis of energy consumption information of a carrier”, “generation of a cleaning recommendation”, and “benchmarking of a transportation system” as
illustrated in the Usage Viewpoint. “Generation of a
cleaning recommendation” and “benchmarking of a transportation system” are examples for potential new datadriven services.
• The supplier of the machine will offer “manufacturing
as a service”. He will offer and bill manufacturing services of his machines based on the usage of the machine
by the operator. This requires transparency of the usage
of the machine, i. e. the business model relies on the
availability of specific usage data defined by the supplier
of the machine, what may contradict the intellectual
property and strategic business of the operator.
The supplier of the machine and provider of data-driven
services has the following interests:
• He wants to be a reliable partner for his customers, i. e.
he will try to address and resolve all objections voiced by
the operators of his machines. He does not want to lose
the direct customer contact to a service provider or an
operator of a service platform.
• He evaluates and selects an enabler in form of a service
platform, to which all of his worldwide located machines
can be connected. The service platform has to provide
the capability to collect usage information and the ability to evaluate the asset data intelligently (or let the supplier evaluate intelligently). He will request for reliable
data, i. e. that manipulation by a user or third party is not
possible. Therefore, trustworthiness of the service platform operator will be a key issue. Finally, the solution of
the service platform operator has to be technically controllable by the supplier of the machine, i. e. the connec-
I N D U S T R I E 4 . 0 D E M O N S T R ATO R M A P P E D TO I I C CO N C E P T S
tion of the machine, its maintenance, and the algorithmic content of the services.
• He will request for a new contractual framework with
his customers, because the responsibilities between
machine provider and operator of the machine are now
different. The supplier will not take on risks due to
improper use of his machines by the operator. He wants
to ensure that the operator sticks to the supplier instructions and best practices regarding the correct use of the
machine, especially that the operator implemented service provided recommendations.
• He is interested in a feedback of lessons learnt on the
usage of the machines to his internal product management and development to initiate improvements of the
machine.
• He has a strong interest that the structure of the data
collected is neither transparent to the operator nor to
the operator of the service platform. The collected data
probably formally belongs to the operator, but the data
structure is protected by IP.
15
• He has to provide some basic applications for visualiza-
tion and analysis of usage data to the supplier of datadriven services. Examples are dashboards or generic fleet
management applications.
• He has to provide capabilities to analyze usage data by
the provider of data-driven services or a third party, in
particular he has to provide capabilities for application
development.
• He has to guarantee security to all stakeholders involved.
The operator of the service platform has the following
interests:
• He wants to be established in a new business role for the
market.
• He wants to connect as many products (e. g. machines)
as possible. Typically this requires low barriers for
on-boarding products to the service platform.
• He wants to make use of network effects, i. e. the attrac-
tiveness of the service platform increases with an
increasing number of users.
Perspective of the Operator of the Service Platform
The operator of the service platform is the “driver” with
respect lowering the total service cost for the supplier of
machines. He wants to offer capabilities that the supplier of
machines can develop and offer new data-driven services.
He wants to connect as many products (e. g. machines) as
possible to his service platform.
The operator of the service platform has to provide the
following fundamental capabilities:
• He has to provide the capability to (easily) connect a
product (e. g. machine) to the service platform.
• He has to guarantee connectivity and availability of the
service platform to collect (usage) data from products
(e. g. machines) located all over the world.
• He has to provide usage data of products (e. g. machines)
to the provider of data-driven services.
Perspective of the System integrator
We do not detail the perspective of the system integrator in
this context. We assume that the system integrator is necessary for “difficult” tasks which neither the operator of the
machine nor the machine and data-driven service provider
nor the service platform operator are willing to execute.
Examples are the (re-)programming of the transportation
system, i.e. application logic in the control domain, software-updates for the transportation system, i. e. system
software of the control devices, the connection of the
transportation system to the service platform, which can be
typically executed by the supplier of the machine also, or
the replacement of linear drives or sensors for the transportation system, which can be typically executed by the
supplier of the machine also.
16
I N D U S T R I E 4. 0 D E M O N S T R ATO R M A P P E D TO I I C CO N C E P T S
Usage Viewpoint
•
The usage viewpoint comprises the following concepts, for
details see [7]:
• The basic unit of work is a task. A task is carried out by a
•
An effect is the difference in the state of the IIoT
system after successful completion of an activity.
Constraints are system characteristics that must be
preserved during execution and after the new state is
achieved.
party assuming a role.
• A role is a set of responsibilities assumed by an entity to
initiate and participate in the execution of, or consume
the outcome of, some tasks or functions in an IIoT system
as required by an activity. Roles are assumed by parties.
In the context of the Industrie 4.0 demonstrator we have
restricted the parties and roles according to Figure 12,
because we will illustrate selected examples for activities
only7. As parties we consider the stakeholders of the business viewpoint plus computing resources; and we consider
the following roles:
• A party is an agent, human or automated, that has
autonomy, interest and responsibility in the execution of
tasks. A party executes a task by assuming a role that has
the necessary authorizations for the execution of the
task. A party may assume more than one role, and a role
may be fulfilled by more than one party.
• User – People having the responsibility to use the trans-
portation system. This role could be assumed by the
operator of transportation system, supplier of transportation system, or system integrator.
• Technical health expert – People having the responsibil-
• An activity is a specified coordination of tasks required
to realize a well-defined usage or process of an IIoT system. An activity has the following elements:
•
•
A trigger is one or more condition(s) under which the
activity is initiated.
A workflow consists of a sequential, parallel, conditional, iterative organization of tasks.
ity to assess the health of the transportation system. This
role could be assumed by the provider of data-driven
services or system integrator.
• Computing resource
If the usage viewpoint is elaborated in more detail, additional roles have to be considered. For the system under
consideration, i. e. the IIoT system, we refer to a common
logical structure as shown in Figure 13 also:
Figure 13: Setup for usage viewpoint in the context of the Industrie 4.0 demonstrator
Parties
Roles
Operator of transportation
system
User
Supplier of transportation
system and provider of datadriven services
System under consideration
IoT system
Technical health expert
data-driven services
Computing resource
System integrator
service platform
Operator of service platform
Computing resource
...
connected assets
Source: Plattform Industrie 4.0
7
The examples do not claim to be exhaustive with respect to the various roles to be considered; our main objective is to illustrate the
application of the Usage Viewpoint of IIRA.
I N D U S T R I E 4 . 0 D E M O N S T R ATO R M A P P E D TO I I C CO N C E P T S
Figure 19. The Implementation Viewpoint will be
used to describe these implementations in detail.
Figure 14: Activity “replacement of a carrier”
IoT system
data-driven services
•
•
service platform
•
...
connected assets
17
Task 2 “replace physical carrier”: role “user”
Task 3 “update virtual representation, i. e. remove resp.
update virtual representative of replaced resp. to be
used physical carrier”: role “user”
Task 4 “acknowledge replacement”: role “user”
• Effects: It is ensured that the physical system and its
virtual representative are consistent.
• Constraints: If necessary, the transportation system has
Source: Plattform Industrie 4.0
to be stopped at the beginning of the workflow and
restarted after the workflow. Depending on the concrete
realization, the tasks executed in the virtual world only
(i. e. task 1, task 3, and even possibly task 4) can be automated completely.
Activity “replacement of a carrier”
Figure 14 illustrates the activity “replacement of a carrier”.
Activity “recording on request additional data”
• Triggers: The activity will be initiated by the role “user”
To generate recommendations to the user additional information could be helpful to be analyzed on request by the
technical health expert. In this case the user connects temporally additional sensors to the transportation system
without changing the current automation solution of the
transportation system, records the required data and sub-
in an explicit way.
• Workflow:
•
Task 1 “identify the virtual representative of the physical carrier to be replaced resp. to be used”: role “user”.
An example for a functional component related to
this task is the retrieving of a virtual representative
unambiguously based on a unique identification of
physical objects. This functional component is part of
the Operations – Provisioning and Deployment
domain, see Figure 18. The Functional Viewpoint will
be used to describe this functional component in
detail.
This function could be implemented by identifying
the physical carrier using some handheld device via
an identification stored physically on the carrier, for
example a QR-code. Another implementation could
be based on RFID-tags for identification of the carrier
and using a RFID-scanner as part of the transportation system. In this case a separate identification by
some handheld device may be not necessary. These
implementations are part of the Edge Tier, see
Figure 15: Activity “recording on request additional data”
IoT system
data-driven services
service platform
...
Source: Plattform Industrie 4.0
connected assets
18
I N D U S T R I E 4. 0 D E M O N S T R ATO R M A P P E D TO I I C CO N C E P T S
mits the data to the technical health expert. Figure 15 illustrates the activity “recording additional data on request”.
Activity “analysis of energy consumption information of
a carrier”
• Trigger: The activity is triggered by the role “technical
Figure 16 illustrates the activity “analysis of energy
consumption information of a carrier”.
health expert” in an explicit way.
• Workflow:
•
•
•
•
•
• Triggers: The activity is triggered by a cyclic or event-
Task 1 “select suitable sensor(s)”: role “user”.
Task 2 “connect sensor(s) to transportation system”:
role “user”.
Task 3 “record required data”: role “computing
resource”.
based measurement of energy consumption as configured by system integrator when installing the transportation system.
• Workflow:
•
Task 1 “execution of analysis algorithm”:
role “computing resource”.
An example for a functional component related to
this task is the functional description of the analysis
algorithm. This functional component is part of the
Operations – Prognostics domain, see Figure 18. The
Functional Viewpoint will be used to describe this
functional component in detail.
Task 4 “disconnect sensor(s) from transportation
system”: role “user”.
Task 5 “notify technical health expert”: role
“computing resource”.
• Effects: It is ensured that the temporally recorded data is
The implementation of this function will be part of
the Platform Tier, see Figure 19. The Implementation
Viewpoint will be used to describe such an implementation in detail.
available to the technical health expert.
• Constraints: not applicable
Figure 16: Activity “analysis of energy consumption
information of a carrier”
IoT system
data-driven services
service platform
•
Task 2 “generation of an alarm in the case that some
threshold is passed”: role “computing resource”.
An example for a functional component related to
this task is the functional description of a message
transmission system. This functional component can
be considered as a cross-cutting basic function, but it
may also be associated to the Operations – Monitoring and Diagnostics or even Information domain, see
Figure 18. The Functional Viewpoint will be used to
describe this functional component in detail.
• Effects: An up-to-date prognosis of status of carrier with
...
Source: Plattform Industrie 4.0
connected assets
respect to the intended prediction, for example contamination, is ensured.
• Constraints: The execution time of the analysis algo-
rithm has to be aligned with the cycle time resp. the possible time courses of the incoming measurement events.
I N D U S T R I E 4 . 0 D E M O N S T R ATO R M A P P E D TO I I C CO N C E P T S
Figure 17: Activity “generation of a cleaning
recommendation”
•
•
IoT system
19
Task 3 “discussion of cleaning recommendation with
customer” (optional): roles “technical health expert”
and “user”.
Task 4 “accounting of delivered service” (optional):
roles “technical health expert” and “user”.
• Effects: Data-driven services will be provided to the
data-driven services
service platform
operator of the transportation system based on specific
findings of an analysis of energy consumption data of a
carrier.
• Constraints: not applicable
...
connected assets
Source: Plattform Industrie 4.0
Activity “generation of a cleaning recommendation”
Figure 17 illustrates the activity “generation of a cleaning
recommendation”.
Activity “benchmarking of a transportation system”
Figure 18 illustrates the activity “benchmarking of a
transportation system”.
• Triggers: The activity is triggered cyclic or event-based as
configured by the various system integrators when
installing the various transportation systems.
• Workflow:
• Triggers: The activity is triggered by a specific alarm
generated in the case that some threshold is passed.
• Workflow:
•
Task 1 “transforming specific alarm into cleaning
recommendation”: roles “computing resource” and
“technical health expert”.
•
Task 1 “transforming the specific information about
the usage of a transportation system into general performance indicator”: role “computing resource”.
Figure 18: Activity “benchmarking of a transportation
system”
An example for a functional component related to
this task is the functional description of transforming
an alarm into a cleaning recommendation. This functional component is part of the Information domain,
see Figure 18. The Functional Viewpoint will be used
to describe this functional component in detail.
IoT system
data-driven services
The implementation of this function could be based
on an algorithm or done by a human expert. The latter case this will typically result in the description of
additional activities.
•
Task 2 “provision of cleaning recommendation to
customer” (optional): role “technical health expert”.
service platform
...
Source: Plattform Industrie 4.0
connected assets
20
I N D U S T R I E 4. 0 D E M O N S T R ATO R M A P P E D TO I I C CO N C E P T S
•
•
Task 2 “provision of the concrete performance indicator value of a transportation system to the customer;
relating this specific value to the (anonymous) distribution of the values of all other connected transportation systems”: role “computing resource”.
Task 3 “displaying the delivered information via an
appropriate dashboard”: roles “computing resource”
and “user”.
Functional Viewpoint
During our discussion of the Usage Viewpoint we have set
some selected links to the Functional Viewpoint. But
never­theless we will not discuss the Functional Viewpoint
in detail. We will only make a rough assignment of the
functionalities of the Industrie 4.0 demonstrator to the
domains according to Figure 19.
• Physical System: Physical transportation system, i. e.
•
Task 4 “accounting of data-driven benchmarking
service” (optional): roles “technical health expert” and
“user”.
multi carrier system
• Sense and Actuation: Functions of linear drives, position
sensors, etc.
• Effects: Data-driven services will be provided to the
operator of the transportation system based on anonymous benchmarking of connected transportation systems.
• Control: Function for controlling the transportation
system, i. e. functions of the application program of the
motion control system, and linking of position values of
linear drives to the corresponding carrier
• Constraints: The triggering and updating of the dash-
board information has to be aligned with the number of
connected transportation systems, which depends on
the scalability of the service platform. The access rights
with respect to the specific performance indicator values
have to be managed.
• Operations:
•
Provisioning and Deployment, Management: Comprises all functions related to the management of the
virtual representation of all transportation systems
Figure 19: Structure of Functional Viewpoint ([7])
Functional Domains
Operations
Provisioning
& Deployment
Management
Application
Monitoring & Diagnosis
Information
Optimization
Operations
Prognosis
Business
Control
Sense
Actuation
Physical System
Source: IIC
I N D U S T R I E 4 . 0 D E M O N S T R ATO R M A P P E D TO I I C CO N C E P T S
and carriers worldwide connected to the service
platform.
•
•
21
Implementation Viewpoint
Monitoring and Diagnosis, Prognosis: Includes the
function for monitoring of the carrier, prognostics of
contamination of carrier, and the benchmarking of
the usage of the transportation systems.
The Implementation Viewpoint was not the focus of these
considerations. Figure 20 illustrates a high level view of the
Implementation Viewpoint of the Industrie 4.0 demonstrator. During our discussion of the Usage Viewpoint we have
set some selected links to the Implementation Viewpoint.
Optimization as automated process: not applicable
for Industrie 4.0 demonstrator
Cross-cutting Relations between the Viewpoints
• Information: Functional concept of sending which
information of a carrier at which time to the service
platform and the functional description of the analysis
algorithm of carrier including the generation of recommendations.
Figure 21 summarizes the cross-cutting relations between
the various concepts of the different viewpoints of the
IIRA as elaborated by detailing the application scenario
VBS – Value-­Based Service following the IIRA structure.
• Application: not detailed for Industrie 4.0 demonstrator
• Business: Functions necessary for automated execution
of business processes between involved stakeholder, for
example the billing of transportation services based on
usage or the recommendations to clean a carrier.
Figure 20: Implementation Viewpoint of Industrie 4.0 demonstrator (modified according to Siemens AG)
Edge Tier
Platform Tier / Enterprise Tier
MindSphere
HANA
physical Multi Carrier System
motion control system
Source: Siemens
connector box
22
I N D U S T R I E 4. 0 D E M O N S T R ATO R M A P P E D TO I I C CO N C E P T S
Figure 21: Cross-cutting relations between viewpoints of IIRA
Manufacturing
as a service
New datadriven services
Capabilities
supplier
Business
Viewpoint
Functional Viewpoint
Interests operator
Manufacturing as a service
Unique identification of physical objects
Increased productivity
Description of analysis algorithm
No unnecessary restrictions
Description of message transmission system
Usage Viewpoint
Description of transformation alarm into
cleaning recommendation
Activities
Replacement of a carrier
Recording additional data on request
Analysis of energy consumption
information of a carrier
Generation of a cleaning recommendation
Benchmarking of a transportation system
…
Implementation Viewpoint
Identification via QR-code
Identification via RFID
Implementation of analysis algorithm
Implementation of message transmission
system
Implementation of algorithm to transform
alarm into cleaning recommendation
Implementation of transforming alarm into
cleaning recommendation by human expert
Source: Plattform Industrie 4.0
23
Lifecycle Perspective
One important issue in the collaboration between the
Plattform Industrie 4.0 and the IIC is to create a mutual
understanding of strategic approaches and concepts of
the Plattform Industrie 4.0 and the IIC. One aspect is to
sharpen the mutual understanding of the lifecycle concepts, i. e. the lifecycle and value chain axis of RAMI 4.0
with respect to a “product” and the solution lifecycle with
respect to an “IIoT solution”. It was proposed to guide these
discussion based on scenarios.
Having proposed the application scenario VBS – Value-­
Based Service as a joint scenario of Plattform Industrie 4.0
and IIC, see [4], and having illustrated selected concepts of
RAMI 4.0 and IIRA based on the same example, namely the
Industrie 4.0 demonstrator, we now propose how the lifecycle perspectives of Plattform Industrie 4.0 and IIC can be
mapped to each other.
8
Lifecycle Perspective of Plattform Industrie 4.0
Figure 22 shows the structure of the object worlds in the
context of digitalization in manufacturing industries with
examples. For more details we refer to [9] and [10].
In this context an entity is a uniquely identifiable object,
which is administered in the information world due to
its importance. An asset8 is an object, which has a value
for an organization. Assets are intentionally created in
order to ful­fill a specific purpose. They possess a common
life-­de­scription and during their lifetime have associated
changes in value. Figure 23 shows this common
life-description:
As already mentioned in chapter “Introduction to IIRA” of this report the definition of “asset” in the context of IIC is more specific.
24
L I F E C YC L E P E R S P E C T I V E
Figure 22: Structure of the object worlds with examples ([10])
Human world
Human
Model world
• Meta-documents (standards,
directives)
• Technical documentation (functional
diagrams, plant diagrams, product
descriptions, procedural descriptions)
• Operative plans (production plans,
project plans)
• Business process descriptions
State world
• Current measurements
• Effective target values
• Current configuration
parameters
Archive world
• Life cycle
documentation
• Events
• Status histories
• Project histories
• Processes
Information world
Physical world
• Products
• Resources
• Production systems (equipment items,
sensors, actuators)
• IT systems, control systems
(computer, programs, data carriers,
cables)
• Cabinets, paper
Physical world
Source: IEC
• Order: Initiation to create an asset
• Usage: In this process the asset performs its intended
• Production: The usual name of this creation process
depends on the type of the asset, e. g. development (of a
description, model), measurement (of a status), or production (of a product).
• Transfer: Includes all processes between the time the
product is created and the time it is ready and working
at the place of use, e. g. shipping, transport, warehousing,
configuration and assembly, and for software assets, processes such as release, downloading, and installation.
role, e. g. production (as part of a production system),
information provision (as part of a simulation system).
• Maintenance: The functionality of an asset must be
maintained or restored. This can be carried out by the
user or somebody else. Maintenance is typically not
necessary for non-physical assets.9
• Re-engineering: Feeding back information from usage
resp. maintenance, involving e. g. a renewed manufacturing, or a design-change
• Removal: Disposal of the asset including termination of
maintenance contract, service agreement, license, etc.
Figure 23: Common life-description of assets ([10])
Transfer
Order
Production
Usage
Maintenance
Removal
Re-engineering
Source: IEC
9
Software source code is part of the information world, whereas software programs are part of the physical world. Software updates to correct
defects or enhance functionality typically require a reprogramming (i. e. production) or even engineering of the source code. Security patches
can be considered as maintenance of software programs.
L I F E C YC L E P E R S P E C T I V E
25
Figure 24: Mapping RAMI 4.0-axis “Lifecycle & Value-Chain” to life of an asset
Value-chain from development of a product to production of the product to maintenance/usage of the product
Development
Maintenance / Usage
Production
Maintenance / Usage
Type
Instance
Transfer
Order
Production
Transfer
Usage
Maintenance
Removal
Order
Production
Re-engineering
“type” asset with its own life
Usage
Maintenance
Removal
Re-engineering
“instance” asset with its own life
Source: Plattform Industrie 4.0
Figure 24 shows how the life of an asset can be mapped to
the RAMI 4.0-Axis Lifecycle and Value-Chain. It is important to understand that the “type” asset and the “instance”
asset are two distinguished assets with their own life. For
more details about RAMI 4.0 we refer to [9], [10], or [11].
It is important to distinguish between assets of the physical
and the information world, see Figure 22. Any object can be
unequivocally classified into the physical or information
world. Regardless of this classification, each object has a
real presence in real time and each object has its individual
life. Real objects are continuously part of an (aging) process
due to their physical presence, whereas objects of the information world (see Figure 22) remain unchanged within
themselves, changes can be inflicted through targeted
external interventions only. As an example the real transportation system is an asset of the physical world, whereas
the simulation model of the transportation system is an
asset of the information world.
Examples for Life of a Transportation System
“Type” of a transportation system:
• Order: Idea to create a product transportation system10
• Production: Development of the transportation system
• Transfer: Not applicable
• Usage: Using guidance of development documentation
of transportation in production of physical transportations systems
• Maintenance: Not applicable11
• Re-engineering: Improving the design of the transporta-
tion system
• Removal: Not applicable
In the following section we illustrate the life of an asset for
various assets of the Industrie 4.0 demonstrator. For more
information about assets of the Industrie 4.0 demonstrator
we refer to [1].
10
This includes the interoperability with other information models.
11
Managing versions and traceability of history to associated type revision is part of development of the transportation system.
26
L I F E C YC L E P E R S P E C T I V E
Simulation model of a transportation system:
• Order: Order to create a simulation model of a transpor-
Examples for Life of Assets related to a Carrier
Usage data of a carrier:
tation system
• Order: Setup to create usage data of a physical carrier
• Production: Development of the model of the transpor-
tation system
• Production: Creating usage data during use of physical
carrier
• Transfer: Transforming the simulation model to an
executable simulation program
• Usage: Using the simulation program to execute simula-
• Transfer: Storing resp. archiving the usage data
• Usage: Using stored resp. archived usage data for analysis
tion experiments
• Maintenance: Not applicable
• Maintenance: Not applicable12
• Re-engineering: Not applicable
• Re-engineering: Improving the simulation model
• Removal: Deletion of usage data if it is not any longer
• Removal: Not applicable
“Instance” of a (physical) transportation system:
• Order: Order of a specific customer
needed for regulatory considerations.
Order form of a carrier:
• Order: Order to create an order form (as part of an
overall development process)
• Production: Production of the customer specific
transportation system
• Transfer: Shipping the customer specific transportation
system to customer site and configuration, installation
and commissioning at site
• Usage: Transportation of the carriers of the transporta-
• Production: Design of the order form13
• Transfer: Providing the order to customers
• Usage: Usage of the order form by customers
• Maintenance: Not applicable
tion system as part of an overall production system
• Re-engineering: Updating the order form in case of
• Maintenance: Maintenance of the transportation system
• Re-engineering: Changing the configuration of the
transportation system (e. g. replacement of a sensor,
linear drive, etc.)
design changes of the carrier
• Removal: Discontinuation of possibility to order a
carrier
• Removal: Disposal of the transportation system
12
Migration of a model because of a change of a modelling tool is part of development of the simulation model.
13
The order form is typically versioned. The management of those revisions for historical purposes is part of the design of the order form.
L I F E C YC L E P E R S P E C T I V E
27
Figure 25: Solution lifecycle of IIC ([12])
$
Idea2Funding
Plan/Build/Run
Validation & Improvements
Source: IIC
Lifecycle Perspective of IIC
Figure 25 shows the IIoT solution lifecycle of IIC. For more
details, especially the early phases of the so-lution lifecycle,
we refer to [12].
The solution lifecycle consists of three main phases:
It is important to understand that the object under
consideration with respect to the solution lifecycle is an
IT solution partially consisting of embedded components
deployed on an IIoT asset and partly of a (usually) remote
enterprise application in the backend.
Mapping of the Lifecycle Perspectives
• From idea to funding
Figure 26 shows how the solution lifecycle of IIC and the
life of an asset according to Plattform Industrie 4.0 can be
mapped to each other.
• Planning, implementation (build) and operations (run)
of the solution
• Continuous validation and improvement
Figure 26: Mapping of solution lifecycle and life of an asset
Transfer
$
Idea2Funding
Plan/Build/Run
Validation & Improvements
Source: Plattform Industrie 4.0
Order
Production
Usage
Maintenance
Re-engineering
Removal
28
L I F E C YC L E P E R S P E C T I V E
There is no general discrepancy between the different lifecycle perspectives. But it is important to distinguish the
different objects under consideration. In the context of the
IIC, a technical IIoT system is the information and operational technology that monitors and manages industrial
assets. Aspects of this technology could be integrated with
the manufactured products as well. In the context of Industrie 4.0 a technical IIoT system is a specific entity with its
specific life, but there are typically many other objects,
which have to be administered in the information world
due to their importance also. Which object is an asset resp.
an entity is a design decision. Whether the technical IIoT
system is an asset in the sense of Industrie 4.0 depends on
the fact whether it is owned by an organization. As illustrated in the previous section the technical IIoT system can
be split into subsystems owned by different organizations.
The overall system (e. g. transportation system) is composed
of roles and realization units, where a role specifies the
demands on a realization unit (e. g. carrier, drive for flex
belt). It is beneficial that roles and realization unit are
modeled as entities with individual life cycles. On the one
hand the role specifies requirements at a time when typically the realization unit has not yet been designed nor
exists. On the other hand, the role can contain lifecycle
information about realization objects that have been
exchanged in the meantime. For more details we refer to
[13].
Therefore it is important to have a concept for modelling
composition of systems.14 Typically in manufacturing
industries composition of systems is modelled as shown in
Figure 27:
Figure 27: Modeling composition of systems, example transportation system15
transportation system
role carrier 1
role carrier 2
…
is element of
implements role
role carrier n
carrier 1
…
carrier18
role drive for flex belt
drive for flex belt
…
Source: Plattform Industrie 4.0
14
A system is a “set of interrelated elements considered in a defined context as a whole and separated from their environment” (IEC 60050-351).
15
This is one modeling example only, other structures are possible.
29
Conclusions
There are many ongoing discussions how to come to a
technical alignment between the conceptual and technical
approaches of Plattform Industrie 4.0 and IIC. We focused
in this paper on the business and examples for the usage
viewpoint and postulate that each application scenario of
AG2 of Plattform Industrie 4.0 describes a specific business
mechanism in the context of digitalization of manufacturing industries. We do not claim that the application scenarios describe their business viewpoint according to the
IIRA – particularly as each application scenario does not
claim the realization of an IIoT system –, nevertheless the
application scenarios include basic business logic. We do
not intervene in the numerous ongoing discussions for
mapping the functional viewpoint and the layers axis of
RAMI 4.0, see e. g. [14]. Thus we propose a “big picture” as
shown in Figure 28:
Plattform Industrie 4.0 and IIC – if limiting to the clientele
of the manufacturing industry – pursue the same goal,
nevertheless they follow similar but different ways:
• Industrie 4.0 pursues the organization and management
of value-added processes in the manufacturing industry
with means of digitalization: Industrie 4.0 signifies the
4th industrial revolution, a new stage of organization
and control of the entire value chain along the lifecycle of
products. This cycle orients itself by increasing individual customer requirements and ranges from idea, order
via development and production, delivery of product to
the customer to recycling, including associated services,
see [15].
Figure 28: Proposal for a “big picture”
IIRA
Business Viewpoint
Guidance
Usage Viewpoint
ongoing discussions in “Architecture Alignment RAMI4.0 and IIRA”
Validation
application scenarios of
Plattform Industrie AG 2
RAMI4.0
Functional Viewpoint
Implementation Viewpoint
technical IIoT system
IIoT solution lifecycle
Source: Plattform Industrie 4.0
„Lifecycle“ Industrie 4.0
30
CO N C LU S I O N S
• IIC pursues the dissemination and evolution of IIoT
systems: The Industrial Internet Consortium is a global,
member-supported, organization that promotes the
accelerated growth of the Industrial Internet of Things
by coordinating ecosystem initiatives to securely connect, control and integrate assets and systems of assets
with people, processes and data using common architectures, interoperability and open standards to deliver
transformational business and societal outcomes across
industries and public infrastructure, see [16].
There are applications addressing digitalization in manufacturing industries, but they do not address the realization
of IIoT systems in the narrower sense. Typical examples for
this are:
• Manufacturing execution systems with focus on a single
(manufacturing site of a) company, because the IIC
addresses in particular IIoT assets of different stakeholders distributed worldwide, whereas a manufacturing
execution system considers one IIoT asset, i. e. the factory, only. A similar example is the order management
with focus on a single company or factory.
• Support of product lifecycle management with focus on
design and engineering processes.
As a consequence, Figure 29 shows the positioning of the
application scenarios of Plattform Industrie 4.0 illustrated
by the Industrie 4.0 demonstrator in the so-called “T-slide”.
The core of the application scenari-os AF – Adaptable Factory and SDP – Seamless and Dynamic Plant Engineering
do not address the development of an IIoT system.
If we consider the application scenarios more precisely
with respect to the applications running in the Edge Tier,
we can derive more detailed requirements for the comprehensive modeling of assets over their life. As a consequence
the Plattform Industrie 4.0 strongly promotes the concept
of the socalled Industrie 4.0 component resp. administration shell. It seems that there does not exist a similar
concept in the context of IIRA. On the other hand IIRA
describes a methodology how to develop an IIoT system
and there is no corresponding methodology in the context
of Plattform Industrie 4.0.
Figure 29: Complementary domain focus areas of Plattform Industrie 4.0 and IIC ([4])
ENERGY
IIC
HEALTHCARE
MANUFACTURING
VBS
PUBLIC DOMAIN
TRANSPORTATION
Source: Plattform Industrie 4.0
Cross-domain &
Interoperability
in IIoT
I4.0
AF
Detailed model for
SDP next-gen Manufacturing
value chain
CO N C LU S I O N S
The lessons learnt in using the viewpoint of IIRA can be
summarized as followed:
• Business Viewpoint: Substantial content to this view-
point has already been provided as part of the description of the application scenarios. An adequate formulation of the fundamental capabilities is certainly the most
challenging task because of an adequate balancing of
level of detail and focus on core aspects. Nevertheless it
is important to distinguish between the development of
an IIoT system from the perspective of its developer or
the postulation of a future value creation network,
because this causes different argumentation chains.
• Usage Viewpoint: The examples according to IIRA are
already very detailed, for example with regard to actors –
such as administrator or security agent – with the IIoT
system. In the context of our activities, we have chosen a
more abstract level and have considered business roles,
and we presented some selected examples only. There is
the challenge that the usage viewpoint will not become
too complex, if the consideration takes place on a too
detailed level; then the link to the fundamental capabilities could be lost.
31
• Functional Viewpoint: The concepts and description of
this viewpoint are very close to the usual way of thinking in automation technology. However, the usage of the
terms operation, information and application are rather
unfamiliar in this application domain.
• Implementation Viewpoint: This viewpoint was not the
focus of these considerations, especially as the Industrie
4.0 demonstrator uses commercially available products.
It was not intended to discuss how such products could
possibly be further developed from a technical point of
view.
32
References
[1]
VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik: Modeling Examples of Industrie 4.0 Components,
https://www.vdi.de/nc/technik/fachthemen/mess-und-automatisierungstechnik/artikel/industrie40-components-modeling-examples/
[2]
Aspects of the Research Roadmap in Application Scenarios, http://www.plattform-i40.de/I40/Redaktion/EN/
Downloads/Publikation/aspects-of-the-research-roadmap.html
[3]
Fortschreibung der Anwendungsszenarien der Plattform Industrie 4.0, http://www.plattform-i40.de/I40/
Redaktion/DE/Downloads/Publikation/fortschreibung-anwendungsszenarien.html
[4]
Proposal for a joint “scenario” of Plattform Industrie 4.0 and IIC,
http://www.plattform-i40.de/I40/Redaktion/DE/Downloads/Publikation/joint-scenario.html
[5]
Industrie 4.0-Demonstrator, https://www.youtube.com/watch?v=4dmA1QtAUzo
[6]
„Industrie 4.0“-Demonstrator, Rahmenprogramm Hannover Messe 2016,
http://sf-eu.net/wp-content/uploads/2016/08/siemens-2016-industrie-4.0-demonstrator-praesentation-de.pdf
[7]
The Industrial Internet Reference Architecture Technical Report, https://www.iiconsortium.org/IIRA.htm
[8]
R. Kochseder et al.: Komplexität beherrschen mit Core Modeling, Tag des Systems Engineering 2016
[9]
VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik: Technical Assets – Basic terms, concepts, life cycles and
administration, https://www.vdi.de/fileadmin/vdi_de/redakteur_dateien/gma_dateien/6092_PUB_E_TW_GMA_
Status_Report_ZVEI_-_Industrie_4_0_-_Technical_Assets_Internet.pdf
[10] IEC PAS 63088 ED1: Reference Architecture Model Industry 4.0 (RAMI4.0), draft publicly available specification
[11] 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
[12] Business Strategy and Innovation Framework, http://www.iiconsortium.org/BSIF.htm
[13] IEC 62424: Specification for Representation of process control engineering requests in P&I Diagrams and for data
exchange between P&ID tools and PCE-CAE
[14] White Paper “Interoperability between IIC Architecture & Industry 4.0”, https://www.infosys.com/engineering-
services/white-papers/Documents/industrial-internet-consortium-architecture.pdf
[15] Memorandum der Plattform Industrie 4.0, http://www.plattform-i40.de/I40/Redaktion/DE/Downloads/
Publikation/memorandum-der-plattform-industrie-4-0. pdf?__blob=publicationFile&v=5
[16] Industrial Internet Consortium, http://www.iiconsortium.org/about-us.htm
AUTHORS
The working paper has been elaborated in the working group “Modeling Example” of the VDI/VDE-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 Hüttemann;
RWTH Aachen University | Matthias Klein; Universität Stuttgart | Dr. Ulrich Löwen; Siemens AG, Erlangen | Mario Thron;
ifak – Institut für Automation und Kommunikation e. V., Magdeburg
GUESTS
Robert Kochseder; Siemens AG, Erlangen | Tobias Manger; evosoft GmbH, Nürnberg | Dr. Michael Okon; Fraunhofer-­
Institut IOSB, Karlsruhe
ACKNOWLEDGMENT
The authors would like to thank Prof. Dr. Alexander Fay (Helmut-Schmidt-Universität/Uni­versität der Bundeswehr
Hamburg), Claus Hilger (HARTING IT System Integration GmbH & Co. KG), and Eric Harper (ABB and IIC JTG1) for their
valuable comments and suggestions.
The working paper has been elaborated in the working group “Modeling Example” of the
VDI/VDE-GMA Technical Committee 7.21 “Industrie 4.0 – Terms, Reference Models, and Architecture Concepts”
in cooperation with the working group on research and innovation (Plattform Industrie 4.0)
www.plattform-i40.de