SlideShare ist ein Scribd-Unternehmen logo
Industrie 4.0
Statusreport
Auf dem Weg zu einem
Referenzmodell
April 2014
Inhalt
1 Zusammenfassung 1
2 Motivation 2
3 Referenzmodelle – Begriffe und Beispiele 3
3.1 ISO Reference Model for Open Distributed Processing (RM-ODP) 4
3.2 OASIS SOA Reference Model (SOA-RM) 4
3.3 Referenzmodell für das Internet der Dinge 6
4 Auswirkungen auf ein „Industrie 4.0“-Referenzmodell für den Themenbereich
„SA“ (Systemarchitektur) 8
5 Konformität zu einem SOA-Referenzmodell 10
6 Abkürzungen 11
7 Begriffe 11
8 Literatur 12
9 VDI/VDE-GMA-Fachausschuss „Industrie 4.0“ 13
Titelbild: VDI-Haus Düsseldorf
Industrie 4.0 – Auf dem Weg zu einem Referenzmodell 1
www.vdi.de
1 Zusammenfassung
Der vorliegende Statusreport wurde im VDI/VDE-
Gesellschaft Mess- und Automatisierungstechnik
(GMA), Fachausschuss 7.21 „Industrie 4.0“ im März
2014 erstellt und abgestimmt.
Der vorliegende Statusreport leistet einen Beitrag zu
den Grundüberlegungen für einen Weg zu einem
„Industrie 4.0“-Referenzmodell „Systemarchitektur“
(RM-SA) gemäß der deutschen Normungs-Roadmap
„Industrie 4.0“ [2]. Vor diesem Hintergrund erhebt es
keinen Anspruch auf Vollständigkeit oder Festlegung
auf gewisse Grundkonzepte.
Es besteht Konsens, dass ein RM-SA iterativ erstellt
werden sollte. Einerseits sollte es den Anforderungen
der „Industrie 4.0“-Anwendungsfälle folgen, anderer-
seits die Möglichkeiten neuer Technologien aus dem
Internet der Dinge und Dienste ausnutzen. Dies kann
nur in einem Prozess mit mehreren Iterationsschritten
und Versionen erfolgen.
Ein erstes Referenzmodell zur „Industrie 4.0“-
Systemarchitektur (RM-SA) sollte grob gesehen min-
destens folgende Aspekte abdecken:
 klare Definition von Begriffen, z. B. über den
Aufbau eines Glossars
 Identifikation und Spezifikation eines I40-
Domänenmodells, das eine grundlegende, mini-
male Menge von Konzepten definiert mit Bezug
zu den Begriffen des Glossars, insbesondere die
Konzepte
‒ Wertschöpfungskette
‒ I40-Komponente (auf der Grundlage von phy-
sischen und/oder virtuellen Entitäten)
‒ Gerät (Sensor, Aktor, Marke)
‒ Fähigkeiten (skill) [13] von I40-Komponenten
und Geräten
‒ Service inklusive einem zu einer I40-
Komponente und den verschiedenen Wert-
schöpfungsketten passenden Service-Meta-
Modellen
 Spezifikation weiterer, darauf aufbauender Mo-
delle für funktionale, informationelle und nicht
funktionale Aspekte gemäß den verschiedenen
Wertschöpfungsketten
 grafische Modellspezifikation der Konzepte und
deren Beziehungen, ggf. unter Nutzung von se-
mantischen Technologien und Standards [14]
 Definition von Sichten und Sichtweisen, die in
einer Architektur beschrieben werden müssen
 Vorgabe von Regeln, Notationen und Modellie-
rungssprachen (u. a. für Dienste und Informati-
onsmodelle) zur Spezifikation von konzeptionel-
len und Implementierungs-Architekturen
 Konformitätserklärungen
2 Industrie 4.0 – Auf dem Weg zu einem Referenzmodell
www.vdi.de
2 Motivation
Um ein gemeinsames Verständnis für „Industrie 4.0“
als Technologietrend oder Zukunftsszenario zu erlan-
gen, ist die Frage des Betrachtungsstandpunktes ent-
scheidend. Die Plattform „Industrie 4.0“ beschreibt
„Industrie 4.0“ aus betriebswirtschaftlicher Sicht als
eine „neue Stufe der Organisation und Steuerung der
gesamten Wertschöpfungskette über den Lebenszyk-
lus von Produkten“ [1]. Als technologische Anforde-
rung, um diese Stufe erreichen zu können, wird „die
Verfügbarkeit aller relevanten Informationen in Echt-
zeit durch Vernetzung aller an der Wertschöpfung
beteiligten Instanzen“ genannt sowie die „Fähigkeit,
aus den Daten den zu jedem Zeitpunkt optimalen
Wertschöpfungsfluss abzuleiten“ [1]. Wichtig sei
hierbei die „Verbindung von Menschen, Objekten und
Systemen“ zu „unternehmensübergreifenden Wert-
schöpfungsnetzwerken“ [1].
Aus technologischer Sicht der Informations- und
Kommunikationstechnik entspricht dies der Anwen-
dung der Prinzipien des entstehenden „Internet der
Dinge“ (Verbindung von Menschen, Objekten und
Systemen) und des „Internet der Dienste“ (Verfügbar-
keit der Daten und daraus basierende Auswertungen)
auf die industrielle Produktion. So beschreibt auch die
deutsche Normungs-Roadmap „Industrie 4.0“ [2] als
das grundlegende Ziel von „Industrie 4.0“ die „Nutz-
barmachung der in den Informations- und Kommuni-
kationstechnologien erreichten und in der nahen Zu-
kunft zu erwartenden Fortschritte für die produktions-
technischen Unternehmen“.
Entscheidend, wenn auch nicht das alleinige Erfolgs-
kriterium, ist die Frage der Interoperabilität oder gar
Austauschbarkeit der eingesetzten Komponenten in
einem System von Systemen
 einerseits sowohl unternehmensintern als auch
unternehmensübergreifend, und
 andererseits sowohl domänenintern als auch
domänenübergreifend (Produktion, Logistik,
Energieversorgung, Gebäudemanagement,
usw.[2]).
Dies erfordert letztlich Normung und Standardisie-
rung auf detaillierter, technischer Ebene. Allerdings
ist zunächst die Erstellung von Referenzmodellen zur
„schlüssigen Beschreibung von Aspekten in einem
Anwendungsbereich“ [2] eine notwendige Vorausset-
zung, um Standardisierungsarbeiten zu ordnen und
Standardspezifikationen beginnen zu können. Als
Konsequenz beinhaltet die deutsche Normungs-
Roadmap „Industrie 4.0“ [2] mehrere Themenberei-
che zu Referenzmodellen:
 SA: Systemarchitektur (Referenzmodell für die
Gesamtarchitektur)
 RT: Referenzmodelle der technischen Systeme
und Prozesse
 RL: Referenzmodelle der leittechnischen Funkti-
onen
 RB: Referenzmodelle der technisch-
organisatorischen Prozesse
 Mensch: Referenzmodelle zu Aufgaben und
Rollen des Menschen in „Industrie 4.0“
Der vorliegende Statusreport diskutiert, ob und in-
wieweit Referenzmodelle und Referenzarchitekturen
aus dem „Internet der Dinge und Dienste“ als Vorla-
ge, wenn nicht gar als Grundlage, für o.g. „Industrie
4.0“-Referenzmodelle dienen können. Der Fokus liegt
hierbei auf dem Themenbereich SA (Referenzmodell
für die Systemarchitektur, RM-SA). Es beschreibt
zudem Handlungsfelder und zu klärende Fragestel-
lungen auf dem Weg zur Spezifikation eines RM-SA.
Dieses Statusreport geht davon aus, dass es zur Kana-
lisierung des „Industrie 4.0“-Prozesses möglichst
genau ein grundlegendes Referenzmodell für den
Themenbereich SA geben sollte, das für Teilaspekte
verfeinert und ergänzt werden kann zu weiteren, er-
gänzenden Referenzmodellen. Dies ermöglicht dann
die Spezifikation spezifischer „Industrie 4.0“-
Referenzarchitekturen.
Zur Kategorisierung der Referenzmodelle und Refe-
renzarchitekturen dienen die spezifischen funktiona-
len, informatorischen und qualitativen Anforderungen
(z. B. Echtzeit, Zuverlässigkeit, Sicherheit) der jewei-
ligen Domänen [2] und Wertschöpfungsketten [18]
oder deren Bestandteile.
Industrie 4.0 – Auf dem Weg zu einem Referenzmodell 3
www.vdi.de
3 Referenzmodelle – Begriffe und Beispiele
Im Unterschied zu Kernmodellen, die anwendungsun-
abhängig weitgehend anerkannte Muster und Konzep-
te beschreiben, sind Referenzmodelle gemäß [17]
„schlüssige Beschreibungen von Aspekten in einem
Anwendungsbereich“. Sie sind daher vom Ansatz her
stärker anwendungsbezogen als Kernmodelle. In
diesem Statusreport wird unter einem Referenzmodell
ein Meta-Modell für Architekturbeschreibungen,
insbesondere für Dienstsysteme, verstanden.
Ein „Industrie 4.0“-Referenzmodell sollte also eine
schlüssige Beschreibung von Systemarchitekturen
ermöglichen, die gemäß den Umsetzungsempfehlun-
gen zu „Industrie 4.0“ [1] spezifiziert und implemen-
tiert werden können. Zu den Architekturmerkmalen
gemäß [1] gehören insbesondere:
M1 Verteilung der Systemkomponenten in einem
Netzwerk: Ein „Industrie 4.0“-System ist per
Definition ein verteiltes System.
M2 Dienstorientierung: Der Zugriff auf die Funk-
tionen der Systemkomponenten über wohlde-
finierte Dienste. Auf dieser Grundlage kann
durch gezielte und standardisierte Anwendung
von Dienstentwurfsmustern1)
sowie semanti-
schen Dienstbeschreibungen ein Internet der
Dienste aufgebaut werden.
M3 Internet der Dinge: Die Nutzung der Internet-
Technologie zur Verknüpfung von physischen
Objekten, Menschen und Systemen.
Zu den Merkmalen M1 und M2 wurden im Zuge der
internationalen Normung von verschiedenen Organi-
sationen Referenzmodelle entwickelt2)
(vgl. Bild 1
und [3]). Die Normung eines Referenzmodells für das
Internet der Dinge (M3) ist noch nicht abgeschlossen.
1)
Beispiele für wichtige Entwurfsmuster im Sinne eines Internets
der Dienste sind Dienstvermittlung (ggf. unterstützt durch eine
semantische Dienstbeschreibung), Dienstorchestrierung (zentral
gesteuerte Aufruffolgen von Dienstoperationen) und Dienstcho-
reographie (selbst-organisierende Interaktion von Dienstteilneh-
mern nach übergeordneten Vorgaben).
2)
Diese Referenzmodelle sind generisch, also anwendungsunab-
hängig. Teile dieser Referenzmodelle können im Sinne von [17]
als Kernmodelle angesehen werden, da sie „grundlegenden“ Cha-
rakter besitzen.
Die folgenden Referenzmodelle werden in diesem
Statusreport kurz beschrieben:
RM-M1 ISO Reference Model for Open Distributed
Processing (RM-ODP) [4]
RM-M2 OASIS SOA Reference Model (SOA-RM)
[5]
RM-M3 IoT-A Consortium: Architectural Refer-
ence Model for the Internet of Things [15;
[16]
Bemerkung:
Die Auswahl dieser Referenzmodelle ist keine Festle-
gung, sondern beschreibt nur beispielhaft anhand
ausgewählter, einschlägiger Spezifikationen und
Standards, welche Einflüsse auf dem Weg zu einem
„Industrie 4.0“-Referenzmodell Systemarchitektur zu
beachten sind.
4 Industrie 4.0 – Auf dem Weg zu einem Referenzmodell
www.vdi.de
3.1 ISO Reference Model for Open
Distributed Processing (RM-ODP)
RM-ODP ist ein ISO-Standard für den Architektur-
entwurf für offene, verteilte informations-
verarbeitende Systeme. RM-ODP schlägt architekto-
nische Grundmuster und Organisationsprinzipien vor
und bietet Richtlinien und Begriffliche für den inkre-
mentellen Entwurf verteilter Systeme. Das wichtigste
Strukturierungselement ist die Definition von fünf
Sichtweisen (viewpoints) zur Beschreibung von Ar-
chitekturen nach dem Prinzip des separation of
concerns:
 Enterprise Viewpoint beschreibt den Zweck, den
Anwendungsbereich und die grundsätzlichen Re-
geln eines verteilten Systems und seiner (Einsatz-)
Umgebung sowie typischerweise auch die Analy-
se der Benutzer- und Systemanforderungen [3].
 Information Viewpoint beschreibt die Semantik
der Information und der Informationsverarbei-
tung (Informationssichtweise).
 Computational Viewpoint beschreibt die Art, wie
das System in Funktionseinheiten aufgeteilt ist
(funktionale Sichtweise).
 Technology Viewpoint beschreibt die gewählte
Technologie (Hardware und Software).
 Engineering Viewpoint beschreibt die Mecha-
nismen zur Unterstützung von verteilten Interak-
tionen zwischen Objekten mithilfe der gewählten
Technologie (Engineering-Sichtweise).
Das RM-ODP ist sehr abstrakt gehalten und grund-
sätzlich nicht nur auf serviceorientierte Architekturen
(SOA) ausgerichtet. Es ist daher eine verfeinerte Be-
schreibung erforderlich, die spezifiziert, wie die ein-
zelnen Sichtweisen für eine bestimmte Anwendungs-
domäne interpretiert werden sollen. Ein Beispiel dafür
ist das Referenzmodell des Open Geospatial Consor-
tium (OGC) für serviceorientierte Umweltrisiko-
managementsysteme [6].
Bild 1. : Entwicklung von Referenzmodellen für
die Merkmale M1 und M2 [3]
3.2 OASIS SOA Reference Model (SOA-
RM)
Die Organisation for the Advancement of Structured
Information Standards (OASIS) verabschiedete 2006
als eine der ersten Standardisierungsorganisationen
ein Referenzmodell für serviceorientierte Architektu-
ren (SOA-RM) [5]. Das SOA-RM orientiert sich nicht
explizit am ISO RM-ODP, kann aber als Interpretati-
on der Informations- und funktionalen Sichtweisen für
eine generische SOA angesehen werden. Es ist ein
abstraktes, technologieneutrales Rahmenwerk, das die
folgenden grundsätzlichen Entitäten (SOA-Konzepte)
und deren Beziehungen untereinander beschreibt (vgl.
Bild 2). Die folgende Auflistung ist eine verkürzte,
aber originäre Wiedergabe der einzelnen Konzepte
[5]:
 Service is a mechanism to enable access to one or
more capabilities where the access is provided
using a prescribed interface and is exercised con-
sistent with constraints and policies as specified
by the service description.
 Service description represents the information
needed in order to use a service.
 Visibility is the relationship between service con-
sumers and providers that is satisfied when they
are able to interact with each other. Pre-
conditions to visibility are awareness, willingness
and reachability.
 Interaction deals with the question about how to
interact with the service in order to achieve the
required objectives. Key requirements for suc-
cessful interactions revolve around the service
description which references an information
model and a behavior model.
 Real world effect captures the consequence of
invoking a service, e.g. information returned in
response to a request, a change to the shared state
of defined entities, or some combination of these
two.
 Contract and Policy represents some constraint
or condition on the use, deployment or descrip-
tion of an owned entity as defined by any partici-
pant.
 Execution context is a set of infrastructure ele-
ments, process entities, policy assertions and con-
tracts that are identified as part of an instantiated
service interaction.
Open Distributed
Processing (ODP)
ISO RM-ODP
t
1998 2003 2007 20092006
serviceorientierte Architektur (SOA)
OASIS
Object Management Group (OMG)
OASIS
The OpenGroup
2010
Industrie 4.0 – Auf dem Weg zu einem Referenzmodell 5
www.vdi.de
Bild 2. Grundlegende Konzepte im OASIS SOA-RM
Bild 3. Beziehung zwischen den SOA Spezifikationen von OASIS, The Open Group und der OMG [10]
Das SOA-RM liefert zudem eine Liste von Richtli-
nien für und Erwartungen an Systementwürfe
(conformance guidelines), die Konformität zum SOA-
RM reklamieren (vgl. Kap. 5). Zudem hat OASIS
zwei weitere Spezifikationen erstellt:
1 Eine formale Spezifikation der SOA-RM Konzep-
te und deren Beziehungen in einer Ontologie
(SOA Meta-Modell) [7], und
2 Grundlagen für eine SOA-Referenzarchitektur
gemäß den SOA-RM Vorgaben [9].
Diese konkurriert mit ähnlichen Ansätzen der Open
Group [8] und der Object Management Group
(OMG), die mit SoaML eine Modellierungssprache
für SOA als UML-Erweiterung vorgeschlagen haben
[11].
Eine Vereinheitlichung der formalen SOA-Meta-
Modelle wurde 2009 versucht und beschrieben [10].
Das SOA-RM wird von den genannten Organisatio-
nen als grundlegendes Referenzmodell angesehen,
von dem die SOA-Meta-Modelle und Referenz-
architekturen von OASIS, OMG und The Open Group
abgeleitet werden können (vgl. Bild 3).
visibility
execution
context
service
service
description
real world
effect
contract &
policy
interaction
Service is a mechanism to enable access to
one or more capabilities where the access
is provided using a prescribedinterface and
is exercisedconsistentwith constraints and
policies as specified by the service
description.
• awareness
• willingness
• reachability
OASIS SOA-RM
OASIS SOA
Ontologie
OASIS SOA
Referenz-
architektur
The Open Group
SOA
Referenzarchitektur
OMG
SoaML
based on
similar
based on
The Open Group
SOA Ontologie
6 Industrie 4.0 – Auf dem Weg zu einem Referenzmodell
www.vdi.de
3.3 Referenzmodell für das Internet der Dinge
Bild 4. IoT Domain Model [16]
Für das Internet der Dinge gibt es bislang kein Refe-
renzmodell, das von einem internationalen Nor-
mungsgremium oder einer Standardisierungsorganisa-
tion anerkannt wurde. Das europäische Forschungs-
projekt IoT-A3)
(Internet of Things – Architecture) hat
im Juli 2013 einen Vorschlag für ein Architectural
Reference Model (ARM) veröffentlicht [16]. Eine
Einführung dazu findet sich in [15]. Seit Abschluss
des Projekts wird das ARM in der „Technology”-
Arbeitsgruppe des IoT-Forum weitergeführt. Das
ARM beinhaltet sowohl ein IoT-Referenzmodell
(IoT-RM) als auch die Beschreibung einer konzeptio-
nellen Referenzarchitektur. In diesem Statusreport
wird nur das IoT-RM vorgestellt (vgl. [16]; Kap. 3).
Das IoT-RM orientiert sich an dem OASIS-
Verständnis eines Referenzmodells [5] und definiert
grundlegende Konzepte und Modelle, die die Spezifi-
kation von IoT-Architekturen und -Systemen ermög-
licht. Es beinhaltet die folgenden Modelle:
 Das IoT Domain Model definiert die grundlegen-
den IoT-Konzepte und deren Beziehungen unter-
einander (vgl. Bild 4), wie z. B. physische Entität
(physical entity) und virtuelle Entität (virtual
3)
IoT-A (FP7 257521) – Internet of Things – Architecture
entity), Dienst (service), Ressource (resource) als
funktionstragende Softwarekomponente sowie
Gerät (device) mit den Subkonzepten Sensor, Ak-
tor (actuator) und Marke (tag). Einer physischen
Entität können eine oder mehrere virtuelle Entitä-
ten zugeordnet werden als Repräsentanzen in der
virtuellen Welt. Einer physischen Entität kann ein
Gerät zugeordnet sein. Es kann über eine oder
mehrere Marken identifiziert, durch einen oder
mehrere Sensoren beobachtet und über einen oder
mehrere Aktoren manipuliert werden. Informati-
onen über eine physische Entität werden in virtu-
ellen Entitäten und/oder assoziierten Ressourcen
gehalten (auf Geräten oder im „Netz“), grund-
sätzlich aber nur über Dienste extern zugänglich
gemacht.
 Das IoT Information Model ist Meta-Modell, das
die Struktur der den virtuellen Entitäten zugeord-
neten Informationen auf konzeptioneller Ebene
beschreibt. Gemäß dem Domänenmodell umfasst
dies auch die Struktur der Dienste-, Ressourcen-
und Gerätebeschreibungen.
 Das IoT Functional Model ist ein Meta-Modell,
das die funktionalen Eigenschaften eines IoT-
Systems beschreibt. Es kategorisiert IoT-
Funktionen in sieben aufeinander aufbauende
(longitudinal) Funktionsgruppen (device, com-
munication, IoT service, virtual entity, IoT pro-
virtual
entity
service
resource
physical
entity
device
actuator tag sensor
represents
n:1
acts on – identifies-
monitors
network
resource
on-device
resource
hosts
n:1
exposes
m:n
associatedwith
m:n
reads
is-a
associatedwith
m:n
is-a
hardware
software
physical entity
Industrie 4.0 – Auf dem Weg zu einem Referenzmodell 7
www.vdi.de
cess management, service organisation, applica-
tion) sowie zwei querschnittliche (transversal)
Funktionsgruppen (management, security).
 Das IoT Communication Model definiert die
hauptsächlichen Formen der Kommunikation und
Interaktion (communication paradigms) zwischen
den verschiedenen Instanzen von IoT-Domain-
Model-Konzepten. Die Beschreibung des IoT
Communication Model orientiert sich an den sie-
ben Schichten des ISO/OSI 7498-Modells.
 Das IoT Trust, Security and Privacy Model be-
schreibt die grundlegenden Konzepte zur Kon-
zeption und Umsetzung von Vertrauenswürdig-
keit (trust), IT-Sicherheit (security) und Privat-
heit (privacy) in einem IoT-System.
Für die Anwendbarkeit des IoT-Referenzmodells auf
eine „Industrie 4.0“-Umgebung und damit für das
RM-SA ist insbesondere das IoT Domain Model zu
prüfen, da dies grundlegend und verpflichtend ist für
die anderen Modelle. Folgende Diskussionspunkte
sind hierbei zu beachten bzw. zu klären:
 Kann, und wenn ja wie, eine I40-Komponente
gemäß dem IoT Domain Model definiert werden?
 Wie eng verschränkt sind die Lebenszyklusmo-
delle von virtuellen und physischen Entitäten?
 Welche Kardinalität soll die Relation zwischen
virtuellen und physischen Entitäten haben? Soll
z. B. eine virtuelle Entität ohne zugeordnete phy-
sische Entität existieren können?
 Wie passt das Konzept des Diensts aus dem IoT-
RM zu dem gewählten Kommunikations- und
Interaktionskonzept im I40-RM-SA, insbesonde-
re bezüglich der nicht funktionalen Aspekte, z. B.
Sicherheit (Authentifizierung, Autorisierung,
Verschlüsselung), Privatheit oder Dienstqualität?
 Welche Beziehung haben Funktionen aus dem
IoT Functional Model zu Diensten aus dem IoT
Domain Model?
 Sollen Funktionen ausschließlich über Dienste
umgesetzt werden können?
Für das gesamte IoT-RM, also über das IoT-Domain-
Model hinaus, ist die Frage zu klären, ob und inwie-
weit es eine Architektur ermöglicht, die auf den heute
in der industriellen Kommunikation gängigen Stan-
dards, z. B. Feldbusse und/oder OPC-UA [21] aufsetzt
oder inwieweit diese ergänzt bzw. angepasst werden
müssten.
8 Industrie 4.0 – Auf dem Weg zu einem Referenzmodell
www.vdi.de
4 Auswirkungen auf ein „Industrie 4.0“-
Referenzmodell für den Themenbereich „SA“
(Systemarchitektur)
Bild 5. Aufbau eines I40-RM-SA aus ISO RM-ODP, SOA und IoT-Referenzmodellen
Die Merkmale verteilter Systeme und serviceorien-
tierter Architekturen, die auch die Grundpfeiler für ein
Internet der Dienste bilden, sowie das Internet der
Dinge sind grundsätzlich zu betrachtende Ansätze auf
dem Weg zu einem „Industrie 4.0“-Referenzmodell
„Systemarchitektur“ (RM-SA). Diese Vorgehenswei-
se ist in Bild 5 beschrieben.
Dabei sind die genannten Referenzmodelle gemäß den
Anforderungen der bislang betrachteten „Industrie
4.0“-Anwendungsfälle zu bewerten. Es ist zu prüfen,
welche Änderungen notwendig sind oder ob grund-
sätzlich neue Modelle erstellt werden müssen.
Daher sind mindestens folgende Vorarbeiten zu leis-
ten, bevor mit der Spezifikation eines RM-SA begon-
nen werden kann:
1 Es ist unter den Beteiligten der „Industrie 4.0“-
Plattform zu klären, ob ISO RM-ODP oder wel-
ches andere Referenzmodell für verteilte Systeme
eingesetzt werden soll. Eine Übersicht über mög-
liche Alternativen gibt [19].
2 Die Ansätze des OASIS SOA-RM und des IoT-A
Architectural Reference Model (ARM) sollten auf
ihre Tauglichkeit in einer „Industrie 4.0“ Umge-
bung geprüft werden. Besonders zu beachten sind
hierbei, je nach Wertschöpfungskette, die nicht-
funktionalen Systemanforderungen der industriel-
len Produktion, z. B. Robustheit, Zuverlässigkeit,
Echtzeitfähigkeit, Betriebssicherheit (safety) und
IT-Sicherheit (security).
3 Es ist zu prüfen, inwieweit die betrachteten Refe-
renzmodelle für das Internet der Dinge und Diens-
te untereinander kompatibel sind. Dies betrifft
insbesondere die Frage, ob das IoT-
Domänenkonzept „Service“ zusammen mit seinen
zugeordneten Konzepten und Modellen (IoT ser-
vice model) mit dem Dienstverständnis des
OASIS SOA-RM verträglich ist.
4 Es sollten die Spezifika von konzeptionellen Ar-
chitekturen herausgearbeitet werden, die sich an
den Wertschöpfungsketten orientieren. Daraus
können weitere Anforderungen an ein RM-SA ab-
geleitet werden.
Gemäß SOA-RM ist ein Referenzmodell ein abstrak-
tes Rahmenwerk (vgl. Bild 6),
 das die grundlegenden Beziehungen zwischen
den Entitäten (z. B. die SOA-RM-Konzepte) ei-
ner Umgebung definiert,
verteilte Systeme
I40-Referenzmodell „Systemarchitektur“
serviceorientierteArchitektur
Internet der Dinge
Sicht-
weisen
Archi-
tektur
Trans-
parenz-
aspekte
Konzept
Service
Service-
Meta-
Modell
Konzept
„Ding“
(virtuell/physisch)
Fähigkeiten
Funktionsgruppen
Kommunikation
Konzept
Trust
Privacy
Security
Bewertung und Harmonisierung
Industrie 4.0 – Auf dem Weg zu einem Referenzmodell 9
www.vdi.de
 Regeln, Notationen, Begriffe und Modellierungs-
sprachen technologieneutral festlegt,
 Sichtweisen auf Architekturen definiert (z. B. die
Sichtweisen des RM-ODP),
 die Einhaltung von relevanten Standards vor-
schreibt oder vorschlägt (optional)
 und dadurch die Spezifikation von Architekturen
ermöglicht.
Ein wesentliches Ziel ist, konzeptionelle Architektu-
ren zu beschreiben, die als Referenzarchitektur in der
„Industrie 4.0“-Community akzeptiert werden. Ein
mögliches Beispiel hierfür wäre eine Architektur auf
der Grundlage der OPC-UA-Spezifikationen und
zugehöriger Companion Standards [21].
Die Betrachtung der beiden Referenzmodelle ISO
RM-ODP und OASIS SOA-RM zeigt zudem die
Bedeutung der Unterscheidung von
 konzeptionellen Architekturen, die technolo-
gieunabhängig sind, aber als Vorlage dienen für
 technologiebezogene und zweckorientierte Im-
plementierungsarchitekturen. Diese zeichnen
sich durch die Verwendung bestimmter Architek-
turstile und Dienstmuster aus.
Im SOA-Bereich sollen hier die Architekturstile „re-
quest/reply SOA“, „REST“ oder „ereignisbasiert“
erwähnt werden. SOA-Dienstmuster, z. B. Enterprise
Service Bus (ESB) oder Event-Driven Messaging (mit
publish/subscribe-Mechanismen), sind beispielsweise
in [12] definiert.
Bild 6. : Referenzmodelle ermöglichen die Spezifikation von Architekturen
.
Meta-Modell für Architektur-
beschreibungen für Dienst-
systeme
Es definiert insbesondere:
• abstraktes Rahmenwerk
• Sichtweisen auf Architekturen
• Regeln, Notationen,
Terminologie,
Modellierungssprachen
• ggf. Standard-Vorgaben
Spezifikation
von
Architekturen
ermöglicht
konzeptionelle
Architektur
Implementierungs-
architektur
(zweckorientiert,
technologiebezogen)
Vorlage für
Architekturstile
Dienstemuster
pub/sub
publish/find/bind
….
request/response
REST
event-driven
….
www.SOApatterns.org
10 Industrie 4.0 – Auf dem Weg zu einem Referenzmodell
www.vdi.de
5 Konformität zu einem SOA-Referenzmodell
Für die letztendliche Auswahl des Referenzmodells
für die „Industrie 4.0“ Systemarchitektur ist die Frage
entscheidend, wie die Konformität zu einem Refe-
renzmodell festgestellt werden kann. Das OASIS
SOA-RM hat für serviceorientierte Architekturen die
Festlegung getroffen, das eine SOA-RM-konforme
Spezifikation die grundlegenden SOA-RM-Konzepte
referenzieren muss in folgendem Sinne:
 Der Entwurf eines SOA-Systems soll Konzepte
haben, die als services im Sinne des SOA-RM
angesehen werden können (Beschreibung eines
Dienste-Meta-Modells).
 Dienste sollen eine assoziierte Dienstbeschrei-
bung (service description) besitzen (nach einem
vorgegeben Muster und einer vorgegeben Notati-
on).
 Es soll spezifiziert werden, wie Sichtbarkeit
(visibility) zwischen Diensterbringer und Dienst-
nutzer hergestellt wird.
 Es soll spezifiziert werden, wie die Interaktionen
(interaction) zwischen den Systemkomponenten
gemäß dem Dienste-Meta-Modell vermittelt und
aufgebaut werden.
 Es soll spezifiziert werden, welcher Effekt (real-
world effect) eine Dienstenutzung mit sich bringt.
 Es soll der Ausführungskontext (execution
context) spezifiziert werden, der zur Unterstüt-
zung von Interaktionen notwendig ist.
 Es soll ersichtlich sein, wie Ausführungsregeln
(policies) gehandhabt werden und wie Verträge
(contracts) modelliert und durchgesetzt werden.
Analog dazu sollten zu allen wesentlichen Aspekten
und Konzepten eines „Industrie 4.0“-Referenzmodells
„Systemarchitektur“verpflichtende Konformitätsricht-
linien (conformance guidelines) erstellt werden, mit-
hilfe derer Konformität geprüft und getestet werden
kann.
Industrie 4.0 – Auf dem Weg zu einem Referenzmodell 11
www.vdi.de
6 Abkürzungen
ARM (IoT-A) Architectural Reference Model
ESB Enterprise Service Bus
I40 „Industrie 4.0“
IoT Internet of Things (Internet der Dinge)
IoT-A Internet of Things – Architecture (EU-
Projekt)
ISO International Organization for Standardiza-
tion
OASIS Organization for the Advancement of
Structured Information Standards
OMG Object Management Group
REST Representational State Transfer
RM-SA Referenzmodell für den Themenbereich
Systemarchitektur
RM-ODP Reference Model for Open Distributed
Processing
SOA Service-orientierte Architektur
SOA-RM (OASIS) Referenzmodell für service-
orientierte Architekturen
SOA-ML (OMG) Service oriented architecture Mod-
eling Language
7 Begriffe
Vorbemerkung
Die folgenden Begriffe sind für das Verständnis
dieses Statusreports definiert. Sie sind noch nicht
im Rahmen der Arbeiten zu einem „Industrie 4.0“-
Referenzmodell als Glossar vollständig abgestimmt
und anerkannt. Dies ist eine derzeit laufende Arbeit
im GMA-Fachausschuss 7.21.
Dienst
Abgegrenzter Funktionsteil, der von einer Entität oder
Organisation über Schnittstellen angeboten wird. (in
Anlehnung an [17] und [22])
Entität
Gegenstände, die in der Informationswelt eigene Ob-
jekte zu ihrer Verwaltung und Nutzung besitzen. [17]
„Industrie 4.0“-Komponente
Komponente, die folgende Voraussetzungen erfüllt:
‒ I40-konform kommunikationsfähig
‒ dem System zumindest individuell bekannt
‒ besitzt die für einen zuverlässigen und sicheren
Betrieb in einem I40-System von allen Teil-
nehmern geforderten Eigenschaften
z.B. bezüglich Robustheit, Verfügbarkeit,
Echtzeitfähigkeit usw. [20]
Kernmodell
Einfache modellmäßige Beschreibung von grundle-
genden Konzepten und Zusammenhängen, die einen
allgemeinen Aspekt von Systemen betreffen. [17]
Referenzarchitektur
Konzeptionelle Architektur, die in einer Community
als Referenz akzeptiert ist.
Referenzmodell
Schlüssige Beschreibung von Aspekten in einem
Anwendungsbereich. [2]
Referenzmodell
<verteilte (z.B. serviceorientierte) Systeme>
Meta-Modell für Architekturbeschreibungen (von
z. B. Dienstsystemen). Es definiert insbesondere
‒ ein abstraktes Rahmenwerk
‒ Sichtweisen, die in Architekturbeschreibungen
definiert werden sollen
‒ grundsätzliche Konzepte und Kernmodelle
‒ Begriffe, Regeln, Notationen und
Modellierungssprachen
‒ ggf. Standard-Vorgaben [5]
Wertschöpfungskette
Modell der Wertschöpfung als sequenzielle, abgestuf-
te Reihung von Tätigkeiten beziehungsweise Prozes-
sen von der Entwicklung über die Beschaffung, die
Produktion und die Distribution bis hin zu Vermark-
tung und Dienstleistungen [18]
12 Industrie 4.0 – Auf dem Weg zu einem Referenzmodell
www.vdi.de
8 Literatur
[1] Plattform „Industrie 4.0“: Was „Industrie 4.0“ (für
uns) ist.
http://www.plattform-i40.de/blog/was-industrie-40-
für-uns-ist (Stand 27.03.2014)
[2] VDE: Die Deutsche Normungs-Roadmap „Industrie
4.0“. Version 1.0 (Stand 11.12.2013).
http://www.dke.de/de/std/Seiten/Industrie40.aspx
[3] Usländer, T.: Service-oriented Design of Environmen-
tal Information Systems, Dissertation Karlsruher Insti-
tut für Technologie (KIT). KIT Scientific Publishing,
ISBN 978-3-86644-499-7, 2010
[4] ISO/IEC 10746-1:1998: Information technology –
Open Distributed Processing – Reference model.
Genf: ISO 1; 1998.
[5] OASIS: Reference Model for Service Oriented Archi-
tecture 1.0. OASIS Standard, 12 October 2006.
http://docs.oasis-open.org/soa-rm/v1.0/
[6] Usländer, T. (ed.): Reference Model for the OR-
CHESTRA Architecture Version 2.1”. OGC Best
Practices Document 07-097, 2007.
http://portal.opengeospatial.org/files/?artifact_id=232
86
[7] OASIS: Reference Ontology for Semantic Service
Oriented Architectures, Version 1.0 Public Review
Draft 01 5 November 2008.
http://docs.oasis-open.org/semantic-ex/ro-
soa/v1.0/see-rosoa-v1.0.pdf
[8] The Open Group: Service-Oriented Architecture
Ontology. The Open Group Technical Standard, refer-
ence C104. Oktober 2010. US ISBN 1931624887,
https://www2.opengroup.org/ogsys/catalog/C104
[9] OASIS: Reference Architecture Foundation for Ser-
vice Oriented Architecture Version 1.0. OASIS
Committee Specification 01, 04 December 2012.
http://docs.oasis-open.org/soa-rm/soa-
ra/v1.0/cs01/soa-ra-v1.0-cs01.html
[10] Kreger, H.; Estefan, J.: Navigating the SOA Open
Standards Landscape Around - Architecture White
Paper. http://www.opengroup.org/soa/source-
book/stds/index.htm
[11] OMG: Service oriented architecture Modeling Lan-
guage (SoaML) Specification Version 1.0.1, Mai
2012. http://www.omg.org/spec/SoaML/1.0.1
[12] Erl, T.: SOA design patterns. Prentice Hall, 2008.
ISBN 0-13-613516-1 http://soapatterns.org
[13] Pfrommer, J.; Schleipen, M.; Beyerer, J.: Fähigkeiten
adaptiver Produktionsanlagen. atp-Edition 55 (2013),
No.11, pp.42-49, ISSN: 2190-4111
[14] Schleipen, M.: Adaptivität und semantische Interope-
rabilität von Manufacturing Execution Systemen
(MES). Dissertation Karlsruher Institut für Technolo-
gie (KIT). KIT Scientific Publishing, 2013. 388 S.,
ISBN: 978-3-86644-955-8
[15] IoT-A Consortium: Introduction to the Architectural
Reference Model for the Internet of Things. 2013.
http://www.iot-a.eu/public/public-
documents/copy_of_d1.2/view
[16] IoT-A Consortium; Carrez, F. (ed.): Final architectur-
al reference model for the IoT v3.0.IoT-A Deliverable
D1.5, 2013. http://www.iot-a.eu/public/public-
documents/d1.5/view
[17] DIN TR-xx: Kernmodelle – Beschreibung und Bei-
spiele. Entwurfsvorlage zur Genehmigung durch den
K931 am 12.12.2013
[18] VDI Statusreport: „Industrie 4.0“ – Wertschöpfungs-
ketten. Düsseldorf: VDI e.V., VDI/VDE-Gesellschaft
Mess- und Automatisierungstechnik, April 2014
[19] Matthes, D.: Enterprise Architecture Frameworks
Kompendium. Springer Xpert.press, 2011. ISBN 978-
3-642-12954-4
[20] VDI Statusreport: „Industrie 4.0“ – Gegenstände,
Entitäten, Komponenten. Düsseldorf: VDI e.V.,
VDI/VDE-Gesellschaft Mess- und Automatisierungs-
technik, April 2014
[21] OPC Foundation: OPC Unified Architecture. Wegbe-
reiter der 4. Industriellen (R)Evolution.
http://www.opcfoundation-
events.com/uploads/media/OPC-UA-Wegbereiter-der-
IE40-DE-v2.pdf
[22] ISO 19119:2005: Geographic Information-Services.
Genf: ISO 2 2005
Industrie 4.0 – Auf dem Weg zu einem Referenzmodell 13
www.vdi.de
9 VDI/VDE-GMA-Fachausschuss „Industrie 4.0“
Das Gelingen des Projekts „Industrie 4.0“ und damit
der gemeinsamen Bemühungen der deutschen Indust-
rie und Hochschulen erfordert ein einheitliches Ver-
ständnis der grundlegenden Begriffe, Referenzmodel-
le und Architekturkonzepte, an denen sich die Ent-
wicklung ausrichten kann. Hierfür ist eine Standardi-
sierung unbedingt erforderlich. Viele Standards zu
den verwandten Themen „Industrielle Kommunikati-
on“, „Engineering“, „Modellierung“, „IT-Sicherheit“,
„Geräteintegration“ sowie zur „Digitalen Fabrik“ sind
bereits existent. Doch für den Erfolg des Projekts
„Industrie 4.0“ ergibt sich ein zusätzlicher Standardi-
sierungsbedarf.
Der GMA-Fachausschuss „Industrie 4.0“ fokussiert
derzeit auf folgende Punkte: Begriffe, Konzepte und
Referenzmodelle für „Industrie 4.0“. Im Vordergrund
steht die konsensbasierte Regelsetzung.
Prof. Dr.-Ing. Ulrich Epple (Vorsitzender)
RWTH Aachen
Dr. Thomas Bangemann
ifak e.V. Magdeburg
Dipl.-Ing. Matthias Barbian
Siemens AG
Dipl.-Inform. Christian Bauer
Siemens AG
Dr. Annerose Braune
TU Dresden
Dipl. Ing. (BA) Markus Diesner
MPDV Mikrolab GmbH
Dipl.-Ing. Jens Friedrich
ISW Uni Stuttgart
Florian Göbe, M. Sc.
RWTH Aachen
Prof. Dr. Thomas Greiner
Hochschule Pforzheim
Dipl.-Inform. Sten Grüner
RWTH Aachen
Eur. Ing. Roland Heidel
Siemens AG
Dr.-Ing. Werner Herfs
RWTH Aachen
Dr.-Ing. Klaus Hesselmann
Your Expert Cluster GmbH
Dipl.-Ing. Markus Janßen
RWTH Aachen
Prof. Dr.-Ing. Jürgen Jasperneite
Hochschule Ostwestfalen-Lippe
Dr. Heinrich Kehl
NuK Consulting UG
Dr.-Ing. Heiko Koziolek
ABB Forschungszentrum
Dipl.-Ing. Albrecht Lederer
Your Expert Cluster GmbH- i.G.
Dipl.-Ing. Sven Lohde
Bundesamt für Sicherheit in der Informationstechnik
Dr.-Ing. Matthias Loskyll
DFKI GmbH
Dr. Ulrich Löwen
Siemens AG
Dipl.-Ing. Frank Lubnau
Siemens AG
Dipl.-Ing. Julius Pfrommer
Fraunhofer- IOSB
Dr.-Ing. Miriam Schleipen
Fraunhofer IOSB
Dipl.-Ing. Matthias Schnurrer
unipo GmbH
Dipl.-Ing. Holk Traschewski
Your Expert Cluster GmbH
Dr.-Ing. Thomas Usländer (Korrespondenzautor)
Fraunhofer IOSB
Prof. Dr.-Ing. Clemens Westerkamp
Hochschule Osnabrück (FH)
Dipl.-Ing. Albrecht Winter
J. Schmalz GmbH
Prof. Martin Wollschlaeger
TU Dresden (FH)
Verein Deutscher Ingenieure e.V.
VDI/VDE-Gesellschaft Mess- und
Automatisierungstechnik
Tel. +49 211 6214-226
gma@vdi.de
www.vdi.de

Weitere ähnliche Inhalte

Was ist angesagt?

Prevolution auf der CEBIT 2018: Integriertes Service- und Informationsmanagement
Prevolution auf der CEBIT 2018: Integriertes Service- und InformationsmanagementPrevolution auf der CEBIT 2018: Integriertes Service- und Informationsmanagement
Prevolution auf der CEBIT 2018: Integriertes Service- und Informationsmanagement
bhoeck
 
PLM Open Hours - Durchgängige Produktstrukturen als zentrales Element der Dig...
PLM Open Hours - Durchgängige Produktstrukturen als zentrales Element der Dig...PLM Open Hours - Durchgängige Produktstrukturen als zentrales Element der Dig...
PLM Open Hours - Durchgängige Produktstrukturen als zentrales Element der Dig...
Intelliact AG
 
PLM Open Hours - Mehrsprachigkeit
PLM Open Hours - MehrsprachigkeitPLM Open Hours - Mehrsprachigkeit
PLM Open Hours - Mehrsprachigkeit
Intelliact AG
 
Requirements-Management: Nutzen im Kontext PLM und wie es sich ins PLM integr...
Requirements-Management: Nutzen im Kontext PLM und wie es sich ins PLM integr...Requirements-Management: Nutzen im Kontext PLM und wie es sich ins PLM integr...
Requirements-Management: Nutzen im Kontext PLM und wie es sich ins PLM integr...
Intelliact AG
 
PLM Open Hours - Agile Produktentwicklung
PLM Open Hours - Agile ProduktentwicklungPLM Open Hours - Agile Produktentwicklung
PLM Open Hours - Agile Produktentwicklung
Intelliact AG
 
Eine Referenzarchitektur für das Digitale Produkt
Eine Referenzarchitektur für das Digitale ProduktEine Referenzarchitektur für das Digitale Produkt
Eine Referenzarchitektur für das Digitale Produkt
Intelliact AG
 
«Schnittstellen sind kompliziert, darum kann ich die Digitalisierung nicht mi...
«Schnittstellen sind kompliziert, darum kann ich die Digitalisierung nicht mi...«Schnittstellen sind kompliziert, darum kann ich die Digitalisierung nicht mi...
«Schnittstellen sind kompliziert, darum kann ich die Digitalisierung nicht mi...
Intelliact AG
 
TOGAF Architecture Content Framework
TOGAF Architecture Content FrameworkTOGAF Architecture Content Framework
TOGAF Architecture Content Framework
Roland Bruggmann
 
Vom Redakteur zum Informationsmanager - Fachvortrag auf der tekom-Jahrestagun...
Vom Redakteur zum Informationsmanager - Fachvortrag auf der tekom-Jahrestagun...Vom Redakteur zum Informationsmanager - Fachvortrag auf der tekom-Jahrestagun...
Vom Redakteur zum Informationsmanager - Fachvortrag auf der tekom-Jahrestagun...
Intelliact AG
 
Product Value Added - IoT als Chance für Produktmanager
Product Value Added - IoT als Chance für ProduktmanagerProduct Value Added - IoT als Chance für Produktmanager
Product Value Added - IoT als Chance für Produktmanager
Intelliact AG
 
PLM Open Hours - PLM und Kennzahlen
PLM Open Hours - PLM und KennzahlenPLM Open Hours - PLM und Kennzahlen
PLM Open Hours - PLM und Kennzahlen
Intelliact AG
 
PLM Open Hours - Nutzen von PLM
PLM Open Hours - Nutzen von PLMPLM Open Hours - Nutzen von PLM
PLM Open Hours - Nutzen von PLM
Intelliact AG
 
Mit PLM zum erfolgreichen Service-Geschäft
Mit PLM zum erfolgreichen Service-GeschäftMit PLM zum erfolgreichen Service-Geschäft
Mit PLM zum erfolgreichen Service-Geschäft
Intelliact AG
 
PLM Open Hours - Änderungsmanagement so einfach und transparent wie möglich
PLM Open Hours - Änderungsmanagement so einfach und transparent wie möglichPLM Open Hours - Änderungsmanagement so einfach und transparent wie möglich
PLM Open Hours - Änderungsmanagement so einfach und transparent wie möglich
Intelliact AG
 
Wie Sie durchgängige Produktdaten über den Prozess sicherstellen
Wie Sie durchgängige Produktdaten über den Prozess sicherstellenWie Sie durchgängige Produktdaten über den Prozess sicherstellen
Wie Sie durchgängige Produktdaten über den Prozess sicherstellen
Intelliact AG
 
PLM Open Hours - Stand der Digitalisierung in der Industrie und Bedeutung fü...
PLM Open Hours - Stand der Digitalisierung in der Industrie und Bedeutung fü...PLM Open Hours - Stand der Digitalisierung in der Industrie und Bedeutung fü...
PLM Open Hours - Stand der Digitalisierung in der Industrie und Bedeutung fü...
Intelliact AG
 
Machine Learning, AI, KI, Deep Learning und wo man es im PLM gebrauchen kann
Machine Learning, AI, KI, Deep Learning und wo man es im PLM gebrauchen kannMachine Learning, AI, KI, Deep Learning und wo man es im PLM gebrauchen kann
Machine Learning, AI, KI, Deep Learning und wo man es im PLM gebrauchen kann
Intelliact AG
 
Mehrwert durch Konnektivität und Interoperabilität - Interview technik report...
Mehrwert durch Konnektivität und Interoperabilität - Interview technik report...Mehrwert durch Konnektivität und Interoperabilität - Interview technik report...
Mehrwert durch Konnektivität und Interoperabilität - Interview technik report...
Thomas Schulz
 
TOGAF Architecture Content Framework
TOGAF Architecture Content FrameworkTOGAF Architecture Content Framework
TOGAF Architecture Content Framework
Roland Bruggmann
 
PLM Open Hours - Zugriffsrechte in einem globalen PDM mit verteilter Entwicklung
PLM Open Hours - Zugriffsrechte in einem globalen PDM mit verteilter EntwicklungPLM Open Hours - Zugriffsrechte in einem globalen PDM mit verteilter Entwicklung
PLM Open Hours - Zugriffsrechte in einem globalen PDM mit verteilter Entwicklung
Intelliact AG
 

Was ist angesagt? (20)

Prevolution auf der CEBIT 2018: Integriertes Service- und Informationsmanagement
Prevolution auf der CEBIT 2018: Integriertes Service- und InformationsmanagementPrevolution auf der CEBIT 2018: Integriertes Service- und Informationsmanagement
Prevolution auf der CEBIT 2018: Integriertes Service- und Informationsmanagement
 
PLM Open Hours - Durchgängige Produktstrukturen als zentrales Element der Dig...
PLM Open Hours - Durchgängige Produktstrukturen als zentrales Element der Dig...PLM Open Hours - Durchgängige Produktstrukturen als zentrales Element der Dig...
PLM Open Hours - Durchgängige Produktstrukturen als zentrales Element der Dig...
 
PLM Open Hours - Mehrsprachigkeit
PLM Open Hours - MehrsprachigkeitPLM Open Hours - Mehrsprachigkeit
PLM Open Hours - Mehrsprachigkeit
 
Requirements-Management: Nutzen im Kontext PLM und wie es sich ins PLM integr...
Requirements-Management: Nutzen im Kontext PLM und wie es sich ins PLM integr...Requirements-Management: Nutzen im Kontext PLM und wie es sich ins PLM integr...
Requirements-Management: Nutzen im Kontext PLM und wie es sich ins PLM integr...
 
PLM Open Hours - Agile Produktentwicklung
PLM Open Hours - Agile ProduktentwicklungPLM Open Hours - Agile Produktentwicklung
PLM Open Hours - Agile Produktentwicklung
 
Eine Referenzarchitektur für das Digitale Produkt
Eine Referenzarchitektur für das Digitale ProduktEine Referenzarchitektur für das Digitale Produkt
Eine Referenzarchitektur für das Digitale Produkt
 
«Schnittstellen sind kompliziert, darum kann ich die Digitalisierung nicht mi...
«Schnittstellen sind kompliziert, darum kann ich die Digitalisierung nicht mi...«Schnittstellen sind kompliziert, darum kann ich die Digitalisierung nicht mi...
«Schnittstellen sind kompliziert, darum kann ich die Digitalisierung nicht mi...
 
TOGAF Architecture Content Framework
TOGAF Architecture Content FrameworkTOGAF Architecture Content Framework
TOGAF Architecture Content Framework
 
Vom Redakteur zum Informationsmanager - Fachvortrag auf der tekom-Jahrestagun...
Vom Redakteur zum Informationsmanager - Fachvortrag auf der tekom-Jahrestagun...Vom Redakteur zum Informationsmanager - Fachvortrag auf der tekom-Jahrestagun...
Vom Redakteur zum Informationsmanager - Fachvortrag auf der tekom-Jahrestagun...
 
Product Value Added - IoT als Chance für Produktmanager
Product Value Added - IoT als Chance für ProduktmanagerProduct Value Added - IoT als Chance für Produktmanager
Product Value Added - IoT als Chance für Produktmanager
 
PLM Open Hours - PLM und Kennzahlen
PLM Open Hours - PLM und KennzahlenPLM Open Hours - PLM und Kennzahlen
PLM Open Hours - PLM und Kennzahlen
 
PLM Open Hours - Nutzen von PLM
PLM Open Hours - Nutzen von PLMPLM Open Hours - Nutzen von PLM
PLM Open Hours - Nutzen von PLM
 
Mit PLM zum erfolgreichen Service-Geschäft
Mit PLM zum erfolgreichen Service-GeschäftMit PLM zum erfolgreichen Service-Geschäft
Mit PLM zum erfolgreichen Service-Geschäft
 
PLM Open Hours - Änderungsmanagement so einfach und transparent wie möglich
PLM Open Hours - Änderungsmanagement so einfach und transparent wie möglichPLM Open Hours - Änderungsmanagement so einfach und transparent wie möglich
PLM Open Hours - Änderungsmanagement so einfach und transparent wie möglich
 
Wie Sie durchgängige Produktdaten über den Prozess sicherstellen
Wie Sie durchgängige Produktdaten über den Prozess sicherstellenWie Sie durchgängige Produktdaten über den Prozess sicherstellen
Wie Sie durchgängige Produktdaten über den Prozess sicherstellen
 
PLM Open Hours - Stand der Digitalisierung in der Industrie und Bedeutung fü...
PLM Open Hours - Stand der Digitalisierung in der Industrie und Bedeutung fü...PLM Open Hours - Stand der Digitalisierung in der Industrie und Bedeutung fü...
PLM Open Hours - Stand der Digitalisierung in der Industrie und Bedeutung fü...
 
Machine Learning, AI, KI, Deep Learning und wo man es im PLM gebrauchen kann
Machine Learning, AI, KI, Deep Learning und wo man es im PLM gebrauchen kannMachine Learning, AI, KI, Deep Learning und wo man es im PLM gebrauchen kann
Machine Learning, AI, KI, Deep Learning und wo man es im PLM gebrauchen kann
 
Mehrwert durch Konnektivität und Interoperabilität - Interview technik report...
Mehrwert durch Konnektivität und Interoperabilität - Interview technik report...Mehrwert durch Konnektivität und Interoperabilität - Interview technik report...
Mehrwert durch Konnektivität und Interoperabilität - Interview technik report...
 
TOGAF Architecture Content Framework
TOGAF Architecture Content FrameworkTOGAF Architecture Content Framework
TOGAF Architecture Content Framework
 
PLM Open Hours - Zugriffsrechte in einem globalen PDM mit verteilter Entwicklung
PLM Open Hours - Zugriffsrechte in einem globalen PDM mit verteilter EntwicklungPLM Open Hours - Zugriffsrechte in einem globalen PDM mit verteilter Entwicklung
PLM Open Hours - Zugriffsrechte in einem globalen PDM mit verteilter Entwicklung
 

Andere mochten auch

Mobile Trends 2014
Mobile Trends 2014Mobile Trends 2014
Mobile Trends 2014
Martin Gutberlet
 
Reshaping IT - Reshaping Business
Reshaping IT - Reshaping BusinessReshaping IT - Reshaping Business
Reshaping IT - Reshaping Business
Martin Gutberlet
 
M2M Scenario
M2M ScenarioM2M Scenario
M2M Scenario
Martin Gutberlet
 
Io t standardization jan2015 mg strategy
Io t standardization jan2015 mg strategyIo t standardization jan2015 mg strategy
Io t standardization jan2015 mg strategy
Martin Gutberlet
 
Ijetae 0413 59
Ijetae 0413 59Ijetae 0413 59
Ijetae 0413 59
Harish Verma
 
M2M Journal Issue 24 December 2014
M2M Journal Issue 24 December 2014M2M Journal Issue 24 December 2014
M2M Journal Issue 24 December 2014
Martin Gutberlet
 

Andere mochten auch (6)

Mobile Trends 2014
Mobile Trends 2014Mobile Trends 2014
Mobile Trends 2014
 
Reshaping IT - Reshaping Business
Reshaping IT - Reshaping BusinessReshaping IT - Reshaping Business
Reshaping IT - Reshaping Business
 
M2M Scenario
M2M ScenarioM2M Scenario
M2M Scenario
 
Io t standardization jan2015 mg strategy
Io t standardization jan2015 mg strategyIo t standardization jan2015 mg strategy
Io t standardization jan2015 mg strategy
 
Ijetae 0413 59
Ijetae 0413 59Ijetae 0413 59
Ijetae 0413 59
 
M2M Journal Issue 24 December 2014
M2M Journal Issue 24 December 2014M2M Journal Issue 24 December 2014
M2M Journal Issue 24 December 2014
 

Ähnlich wie Industrie 4.0 Referenzmodell 2014

Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
Peter Affolter
 
Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...
Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...
Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...
Peter Affolter
 
PLM Open Hours - Industrie 4.0 – so beginnen sie heute
PLM Open Hours - Industrie 4.0 – so beginnen sie heutePLM Open Hours - Industrie 4.0 – so beginnen sie heute
PLM Open Hours - Industrie 4.0 – so beginnen sie heute
Intelliact AG
 
Meilensteine der Instandhaltung 4.0
Meilensteine der Instandhaltung 4.0Meilensteine der Instandhaltung 4.0
Meilensteine der Instandhaltung 4.0
Georg Guentner
 
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSPSoftware Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Christian Guenther
 
Microservice-Architektur-Prozess für Software-Plattformen und Microservice-Ec...
Microservice-Architektur-Prozess für Software-Plattformen und Microservice-Ec...Microservice-Architektur-Prozess für Software-Plattformen und Microservice-Ec...
Microservice-Architektur-Prozess für Software-Plattformen und Microservice-Ec...
Peter Schrey
 
Developer Best Practices (Robotic Enterprise Framework REF) – Anwendung und d...
Developer Best Practices (Robotic Enterprise Framework REF) – Anwendung und d...Developer Best Practices (Robotic Enterprise Framework REF) – Anwendung und d...
Developer Best Practices (Robotic Enterprise Framework REF) – Anwendung und d...
Cristina Vidu
 
chapter zürich rpa best practices
chapter zürich rpa best practiceschapter zürich rpa best practices
chapter zürich rpa best practices
Cristina Vidu
 
Arbeitsbericht Nr. 118: 'IT-Service Management - Ein neues Paradigma für das ...
Arbeitsbericht Nr. 118: 'IT-Service Management - Ein neues Paradigma für das ...Arbeitsbericht Nr. 118: 'IT-Service Management - Ein neues Paradigma für das ...
Arbeitsbericht Nr. 118: 'IT-Service Management - Ein neues Paradigma für das ...
servicEvolution
 
DOAG BPM SIG 2009
DOAG BPM SIG 2009DOAG BPM SIG 2009
DOAG BPM SIG 2009
kriweber
 
[DE] MoReq2 Roadshow 2008 | Dr. Ulrich Kampffmeyer | "Der MoReq2 Standard" | ...
[DE] MoReq2 Roadshow 2008 | Dr. Ulrich Kampffmeyer | "Der MoReq2 Standard" | ...[DE] MoReq2 Roadshow 2008 | Dr. Ulrich Kampffmeyer | "Der MoReq2 Standard" | ...
[DE] MoReq2 Roadshow 2008 | Dr. Ulrich Kampffmeyer | "Der MoReq2 Standard" | ...
PROJECT CONSULT Unternehmensberatung Dr. Ulrich Kampffmeyer GmbH
 
Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...
Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...
Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...
Thomas Schulz
 
Microservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary PatternMicroservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary Pattern
Brockhaus Consulting GmbH
 
Prozessoptimierung mit ITIL
Prozessoptimierung mit ITILProzessoptimierung mit ITIL
Prozessoptimierung mit ITIL
Christian Reinboth
 
Checkliste für die Digitale Transformation - checklist for digital transforma...
Checkliste für die Digitale Transformation - checklist for digital transforma...Checkliste für die Digitale Transformation - checklist for digital transforma...
Checkliste für die Digitale Transformation - checklist for digital transforma...
Gernot Sauerborn
 
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Peter Affolter
 
2011 07-13 collaboration solutions day - cedros
2011 07-13 collaboration solutions day - cedros2011 07-13 collaboration solutions day - cedros
2011 07-13 collaboration solutions day - cedros
Philipp_Koenigs
 
Navigator im Compliance-Dickicht - computerworld.ch - Matthias Leisi
Navigator im Compliance-Dickicht - computerworld.ch - Matthias LeisiNavigator im Compliance-Dickicht - computerworld.ch - Matthias Leisi
Navigator im Compliance-Dickicht - computerworld.ch - Matthias LeisiMatthias Leisi
 
Roadmap zum Modernen Arbeitsplatz: Praxisszenario. Rainer Haselmeier, YAVEON AG
Roadmap zum Modernen Arbeitsplatz: Praxisszenario. Rainer Haselmeier, YAVEON AGRoadmap zum Modernen Arbeitsplatz: Praxisszenario. Rainer Haselmeier, YAVEON AG
Roadmap zum Modernen Arbeitsplatz: Praxisszenario. Rainer Haselmeier, YAVEON AG
InboundLabs (ex mon.ki inc)
 
2016 pcc presse_03_dcc_ontras_dcc_ver05
2016 pcc presse_03_dcc_ontras_dcc_ver052016 pcc presse_03_dcc_ontras_dcc_ver05
2016 pcc presse_03_dcc_ontras_dcc_ver05
Ulrich Schmidt
 

Ähnlich wie Industrie 4.0 Referenzmodell 2014 (20)

Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
 
Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...
Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...
Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...
 
PLM Open Hours - Industrie 4.0 – so beginnen sie heute
PLM Open Hours - Industrie 4.0 – so beginnen sie heutePLM Open Hours - Industrie 4.0 – so beginnen sie heute
PLM Open Hours - Industrie 4.0 – so beginnen sie heute
 
Meilensteine der Instandhaltung 4.0
Meilensteine der Instandhaltung 4.0Meilensteine der Instandhaltung 4.0
Meilensteine der Instandhaltung 4.0
 
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSPSoftware Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
 
Microservice-Architektur-Prozess für Software-Plattformen und Microservice-Ec...
Microservice-Architektur-Prozess für Software-Plattformen und Microservice-Ec...Microservice-Architektur-Prozess für Software-Plattformen und Microservice-Ec...
Microservice-Architektur-Prozess für Software-Plattformen und Microservice-Ec...
 
Developer Best Practices (Robotic Enterprise Framework REF) – Anwendung und d...
Developer Best Practices (Robotic Enterprise Framework REF) – Anwendung und d...Developer Best Practices (Robotic Enterprise Framework REF) – Anwendung und d...
Developer Best Practices (Robotic Enterprise Framework REF) – Anwendung und d...
 
chapter zürich rpa best practices
chapter zürich rpa best practiceschapter zürich rpa best practices
chapter zürich rpa best practices
 
Arbeitsbericht Nr. 118: 'IT-Service Management - Ein neues Paradigma für das ...
Arbeitsbericht Nr. 118: 'IT-Service Management - Ein neues Paradigma für das ...Arbeitsbericht Nr. 118: 'IT-Service Management - Ein neues Paradigma für das ...
Arbeitsbericht Nr. 118: 'IT-Service Management - Ein neues Paradigma für das ...
 
DOAG BPM SIG 2009
DOAG BPM SIG 2009DOAG BPM SIG 2009
DOAG BPM SIG 2009
 
[DE] MoReq2 Roadshow 2008 | Dr. Ulrich Kampffmeyer | "Der MoReq2 Standard" | ...
[DE] MoReq2 Roadshow 2008 | Dr. Ulrich Kampffmeyer | "Der MoReq2 Standard" | ...[DE] MoReq2 Roadshow 2008 | Dr. Ulrich Kampffmeyer | "Der MoReq2 Standard" | ...
[DE] MoReq2 Roadshow 2008 | Dr. Ulrich Kampffmeyer | "Der MoReq2 Standard" | ...
 
Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...
Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...
Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...
 
Microservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary PatternMicroservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary Pattern
 
Prozessoptimierung mit ITIL
Prozessoptimierung mit ITILProzessoptimierung mit ITIL
Prozessoptimierung mit ITIL
 
Checkliste für die Digitale Transformation - checklist for digital transforma...
Checkliste für die Digitale Transformation - checklist for digital transforma...Checkliste für die Digitale Transformation - checklist for digital transforma...
Checkliste für die Digitale Transformation - checklist for digital transforma...
 
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
 
2011 07-13 collaboration solutions day - cedros
2011 07-13 collaboration solutions day - cedros2011 07-13 collaboration solutions day - cedros
2011 07-13 collaboration solutions day - cedros
 
Navigator im Compliance-Dickicht - computerworld.ch - Matthias Leisi
Navigator im Compliance-Dickicht - computerworld.ch - Matthias LeisiNavigator im Compliance-Dickicht - computerworld.ch - Matthias Leisi
Navigator im Compliance-Dickicht - computerworld.ch - Matthias Leisi
 
Roadmap zum Modernen Arbeitsplatz: Praxisszenario. Rainer Haselmeier, YAVEON AG
Roadmap zum Modernen Arbeitsplatz: Praxisszenario. Rainer Haselmeier, YAVEON AGRoadmap zum Modernen Arbeitsplatz: Praxisszenario. Rainer Haselmeier, YAVEON AG
Roadmap zum Modernen Arbeitsplatz: Praxisszenario. Rainer Haselmeier, YAVEON AG
 
2016 pcc presse_03_dcc_ontras_dcc_ver05
2016 pcc presse_03_dcc_ontras_dcc_ver052016 pcc presse_03_dcc_ontras_dcc_ver05
2016 pcc presse_03_dcc_ontras_dcc_ver05
 

Mehr von Martin Gutberlet

M2M Journal - 22nd edition
M2M Journal - 22nd editionM2M Journal - 22nd edition
M2M Journal - 22nd edition
Martin Gutberlet
 
M2M Journal - No. 21
M2M Journal - No. 21M2M Journal - No. 21
M2M Journal - No. 21
Martin Gutberlet
 
The disruption of industry logics
The disruption of industry logicsThe disruption of industry logics
The disruption of industry logics
Martin Gutberlet
 
Mobile Payment Trends 2014
Mobile Payment Trends 2014Mobile Payment Trends 2014
Mobile Payment Trends 2014
Martin Gutberlet
 
FTTH Demand Drivers
FTTH Demand DriversFTTH Demand Drivers
FTTH Demand Drivers
Martin Gutberlet
 
M2M Journal No. 20
M2M Journal No. 20M2M Journal No. 20
M2M Journal No. 20
Martin Gutberlet
 
M2M Summit 2013 - grosse Hoffnungen, leidige Details
M2M Summit 2013 - grosse Hoffnungen, leidige DetailsM2M Summit 2013 - grosse Hoffnungen, leidige Details
M2M Summit 2013 - grosse Hoffnungen, leidige DetailsMartin Gutberlet
 
Mobile Payment - Will NFC finally unlock a new value chain?
Mobile Payment - Will NFC finally unlock a new value chain?Mobile Payment - Will NFC finally unlock a new value chain?
Mobile Payment - Will NFC finally unlock a new value chain?
Martin Gutberlet
 
Die Zukunft des TK Marktes - Trends und Perspektiven
Die Zukunft des TK Marktes - Trends und PerspektivenDie Zukunft des TK Marktes - Trends und Perspektiven
Die Zukunft des TK Marktes - Trends und Perspektiven
Martin Gutberlet
 
Beratungsfelder IT & Technologie Beratung
Beratungsfelder IT & Technologie BeratungBeratungsfelder IT & Technologie Beratung
Beratungsfelder IT & Technologie Beratung
Martin Gutberlet
 

Mehr von Martin Gutberlet (10)

M2M Journal - 22nd edition
M2M Journal - 22nd editionM2M Journal - 22nd edition
M2M Journal - 22nd edition
 
M2M Journal - No. 21
M2M Journal - No. 21M2M Journal - No. 21
M2M Journal - No. 21
 
The disruption of industry logics
The disruption of industry logicsThe disruption of industry logics
The disruption of industry logics
 
Mobile Payment Trends 2014
Mobile Payment Trends 2014Mobile Payment Trends 2014
Mobile Payment Trends 2014
 
FTTH Demand Drivers
FTTH Demand DriversFTTH Demand Drivers
FTTH Demand Drivers
 
M2M Journal No. 20
M2M Journal No. 20M2M Journal No. 20
M2M Journal No. 20
 
M2M Summit 2013 - grosse Hoffnungen, leidige Details
M2M Summit 2013 - grosse Hoffnungen, leidige DetailsM2M Summit 2013 - grosse Hoffnungen, leidige Details
M2M Summit 2013 - grosse Hoffnungen, leidige Details
 
Mobile Payment - Will NFC finally unlock a new value chain?
Mobile Payment - Will NFC finally unlock a new value chain?Mobile Payment - Will NFC finally unlock a new value chain?
Mobile Payment - Will NFC finally unlock a new value chain?
 
Die Zukunft des TK Marktes - Trends und Perspektiven
Die Zukunft des TK Marktes - Trends und PerspektivenDie Zukunft des TK Marktes - Trends und Perspektiven
Die Zukunft des TK Marktes - Trends und Perspektiven
 
Beratungsfelder IT & Technologie Beratung
Beratungsfelder IT & Technologie BeratungBeratungsfelder IT & Technologie Beratung
Beratungsfelder IT & Technologie Beratung
 

Industrie 4.0 Referenzmodell 2014

  • 1. Industrie 4.0 Statusreport Auf dem Weg zu einem Referenzmodell April 2014
  • 2. Inhalt 1 Zusammenfassung 1 2 Motivation 2 3 Referenzmodelle – Begriffe und Beispiele 3 3.1 ISO Reference Model for Open Distributed Processing (RM-ODP) 4 3.2 OASIS SOA Reference Model (SOA-RM) 4 3.3 Referenzmodell für das Internet der Dinge 6 4 Auswirkungen auf ein „Industrie 4.0“-Referenzmodell für den Themenbereich „SA“ (Systemarchitektur) 8 5 Konformität zu einem SOA-Referenzmodell 10 6 Abkürzungen 11 7 Begriffe 11 8 Literatur 12 9 VDI/VDE-GMA-Fachausschuss „Industrie 4.0“ 13 Titelbild: VDI-Haus Düsseldorf
  • 3. Industrie 4.0 – Auf dem Weg zu einem Referenzmodell 1 www.vdi.de 1 Zusammenfassung Der vorliegende Statusreport wurde im VDI/VDE- Gesellschaft Mess- und Automatisierungstechnik (GMA), Fachausschuss 7.21 „Industrie 4.0“ im März 2014 erstellt und abgestimmt. Der vorliegende Statusreport leistet einen Beitrag zu den Grundüberlegungen für einen Weg zu einem „Industrie 4.0“-Referenzmodell „Systemarchitektur“ (RM-SA) gemäß der deutschen Normungs-Roadmap „Industrie 4.0“ [2]. Vor diesem Hintergrund erhebt es keinen Anspruch auf Vollständigkeit oder Festlegung auf gewisse Grundkonzepte. Es besteht Konsens, dass ein RM-SA iterativ erstellt werden sollte. Einerseits sollte es den Anforderungen der „Industrie 4.0“-Anwendungsfälle folgen, anderer- seits die Möglichkeiten neuer Technologien aus dem Internet der Dinge und Dienste ausnutzen. Dies kann nur in einem Prozess mit mehreren Iterationsschritten und Versionen erfolgen. Ein erstes Referenzmodell zur „Industrie 4.0“- Systemarchitektur (RM-SA) sollte grob gesehen min- destens folgende Aspekte abdecken:  klare Definition von Begriffen, z. B. über den Aufbau eines Glossars  Identifikation und Spezifikation eines I40- Domänenmodells, das eine grundlegende, mini- male Menge von Konzepten definiert mit Bezug zu den Begriffen des Glossars, insbesondere die Konzepte ‒ Wertschöpfungskette ‒ I40-Komponente (auf der Grundlage von phy- sischen und/oder virtuellen Entitäten) ‒ Gerät (Sensor, Aktor, Marke) ‒ Fähigkeiten (skill) [13] von I40-Komponenten und Geräten ‒ Service inklusive einem zu einer I40- Komponente und den verschiedenen Wert- schöpfungsketten passenden Service-Meta- Modellen  Spezifikation weiterer, darauf aufbauender Mo- delle für funktionale, informationelle und nicht funktionale Aspekte gemäß den verschiedenen Wertschöpfungsketten  grafische Modellspezifikation der Konzepte und deren Beziehungen, ggf. unter Nutzung von se- mantischen Technologien und Standards [14]  Definition von Sichten und Sichtweisen, die in einer Architektur beschrieben werden müssen  Vorgabe von Regeln, Notationen und Modellie- rungssprachen (u. a. für Dienste und Informati- onsmodelle) zur Spezifikation von konzeptionel- len und Implementierungs-Architekturen  Konformitätserklärungen
  • 4. 2 Industrie 4.0 – Auf dem Weg zu einem Referenzmodell www.vdi.de 2 Motivation Um ein gemeinsames Verständnis für „Industrie 4.0“ als Technologietrend oder Zukunftsszenario zu erlan- gen, ist die Frage des Betrachtungsstandpunktes ent- scheidend. Die Plattform „Industrie 4.0“ beschreibt „Industrie 4.0“ aus betriebswirtschaftlicher Sicht als eine „neue Stufe der Organisation und Steuerung der gesamten Wertschöpfungskette über den Lebenszyk- lus von Produkten“ [1]. Als technologische Anforde- rung, um diese Stufe erreichen zu können, wird „die Verfügbarkeit aller relevanten Informationen in Echt- zeit durch Vernetzung aller an der Wertschöpfung beteiligten Instanzen“ genannt sowie die „Fähigkeit, aus den Daten den zu jedem Zeitpunkt optimalen Wertschöpfungsfluss abzuleiten“ [1]. Wichtig sei hierbei die „Verbindung von Menschen, Objekten und Systemen“ zu „unternehmensübergreifenden Wert- schöpfungsnetzwerken“ [1]. Aus technologischer Sicht der Informations- und Kommunikationstechnik entspricht dies der Anwen- dung der Prinzipien des entstehenden „Internet der Dinge“ (Verbindung von Menschen, Objekten und Systemen) und des „Internet der Dienste“ (Verfügbar- keit der Daten und daraus basierende Auswertungen) auf die industrielle Produktion. So beschreibt auch die deutsche Normungs-Roadmap „Industrie 4.0“ [2] als das grundlegende Ziel von „Industrie 4.0“ die „Nutz- barmachung der in den Informations- und Kommuni- kationstechnologien erreichten und in der nahen Zu- kunft zu erwartenden Fortschritte für die produktions- technischen Unternehmen“. Entscheidend, wenn auch nicht das alleinige Erfolgs- kriterium, ist die Frage der Interoperabilität oder gar Austauschbarkeit der eingesetzten Komponenten in einem System von Systemen  einerseits sowohl unternehmensintern als auch unternehmensübergreifend, und  andererseits sowohl domänenintern als auch domänenübergreifend (Produktion, Logistik, Energieversorgung, Gebäudemanagement, usw.[2]). Dies erfordert letztlich Normung und Standardisie- rung auf detaillierter, technischer Ebene. Allerdings ist zunächst die Erstellung von Referenzmodellen zur „schlüssigen Beschreibung von Aspekten in einem Anwendungsbereich“ [2] eine notwendige Vorausset- zung, um Standardisierungsarbeiten zu ordnen und Standardspezifikationen beginnen zu können. Als Konsequenz beinhaltet die deutsche Normungs- Roadmap „Industrie 4.0“ [2] mehrere Themenberei- che zu Referenzmodellen:  SA: Systemarchitektur (Referenzmodell für die Gesamtarchitektur)  RT: Referenzmodelle der technischen Systeme und Prozesse  RL: Referenzmodelle der leittechnischen Funkti- onen  RB: Referenzmodelle der technisch- organisatorischen Prozesse  Mensch: Referenzmodelle zu Aufgaben und Rollen des Menschen in „Industrie 4.0“ Der vorliegende Statusreport diskutiert, ob und in- wieweit Referenzmodelle und Referenzarchitekturen aus dem „Internet der Dinge und Dienste“ als Vorla- ge, wenn nicht gar als Grundlage, für o.g. „Industrie 4.0“-Referenzmodelle dienen können. Der Fokus liegt hierbei auf dem Themenbereich SA (Referenzmodell für die Systemarchitektur, RM-SA). Es beschreibt zudem Handlungsfelder und zu klärende Fragestel- lungen auf dem Weg zur Spezifikation eines RM-SA. Dieses Statusreport geht davon aus, dass es zur Kana- lisierung des „Industrie 4.0“-Prozesses möglichst genau ein grundlegendes Referenzmodell für den Themenbereich SA geben sollte, das für Teilaspekte verfeinert und ergänzt werden kann zu weiteren, er- gänzenden Referenzmodellen. Dies ermöglicht dann die Spezifikation spezifischer „Industrie 4.0“- Referenzarchitekturen. Zur Kategorisierung der Referenzmodelle und Refe- renzarchitekturen dienen die spezifischen funktiona- len, informatorischen und qualitativen Anforderungen (z. B. Echtzeit, Zuverlässigkeit, Sicherheit) der jewei- ligen Domänen [2] und Wertschöpfungsketten [18] oder deren Bestandteile.
  • 5. Industrie 4.0 – Auf dem Weg zu einem Referenzmodell 3 www.vdi.de 3 Referenzmodelle – Begriffe und Beispiele Im Unterschied zu Kernmodellen, die anwendungsun- abhängig weitgehend anerkannte Muster und Konzep- te beschreiben, sind Referenzmodelle gemäß [17] „schlüssige Beschreibungen von Aspekten in einem Anwendungsbereich“. Sie sind daher vom Ansatz her stärker anwendungsbezogen als Kernmodelle. In diesem Statusreport wird unter einem Referenzmodell ein Meta-Modell für Architekturbeschreibungen, insbesondere für Dienstsysteme, verstanden. Ein „Industrie 4.0“-Referenzmodell sollte also eine schlüssige Beschreibung von Systemarchitekturen ermöglichen, die gemäß den Umsetzungsempfehlun- gen zu „Industrie 4.0“ [1] spezifiziert und implemen- tiert werden können. Zu den Architekturmerkmalen gemäß [1] gehören insbesondere: M1 Verteilung der Systemkomponenten in einem Netzwerk: Ein „Industrie 4.0“-System ist per Definition ein verteiltes System. M2 Dienstorientierung: Der Zugriff auf die Funk- tionen der Systemkomponenten über wohlde- finierte Dienste. Auf dieser Grundlage kann durch gezielte und standardisierte Anwendung von Dienstentwurfsmustern1) sowie semanti- schen Dienstbeschreibungen ein Internet der Dienste aufgebaut werden. M3 Internet der Dinge: Die Nutzung der Internet- Technologie zur Verknüpfung von physischen Objekten, Menschen und Systemen. Zu den Merkmalen M1 und M2 wurden im Zuge der internationalen Normung von verschiedenen Organi- sationen Referenzmodelle entwickelt2) (vgl. Bild 1 und [3]). Die Normung eines Referenzmodells für das Internet der Dinge (M3) ist noch nicht abgeschlossen. 1) Beispiele für wichtige Entwurfsmuster im Sinne eines Internets der Dienste sind Dienstvermittlung (ggf. unterstützt durch eine semantische Dienstbeschreibung), Dienstorchestrierung (zentral gesteuerte Aufruffolgen von Dienstoperationen) und Dienstcho- reographie (selbst-organisierende Interaktion von Dienstteilneh- mern nach übergeordneten Vorgaben). 2) Diese Referenzmodelle sind generisch, also anwendungsunab- hängig. Teile dieser Referenzmodelle können im Sinne von [17] als Kernmodelle angesehen werden, da sie „grundlegenden“ Cha- rakter besitzen. Die folgenden Referenzmodelle werden in diesem Statusreport kurz beschrieben: RM-M1 ISO Reference Model for Open Distributed Processing (RM-ODP) [4] RM-M2 OASIS SOA Reference Model (SOA-RM) [5] RM-M3 IoT-A Consortium: Architectural Refer- ence Model for the Internet of Things [15; [16] Bemerkung: Die Auswahl dieser Referenzmodelle ist keine Festle- gung, sondern beschreibt nur beispielhaft anhand ausgewählter, einschlägiger Spezifikationen und Standards, welche Einflüsse auf dem Weg zu einem „Industrie 4.0“-Referenzmodell Systemarchitektur zu beachten sind.
  • 6. 4 Industrie 4.0 – Auf dem Weg zu einem Referenzmodell www.vdi.de 3.1 ISO Reference Model for Open Distributed Processing (RM-ODP) RM-ODP ist ein ISO-Standard für den Architektur- entwurf für offene, verteilte informations- verarbeitende Systeme. RM-ODP schlägt architekto- nische Grundmuster und Organisationsprinzipien vor und bietet Richtlinien und Begriffliche für den inkre- mentellen Entwurf verteilter Systeme. Das wichtigste Strukturierungselement ist die Definition von fünf Sichtweisen (viewpoints) zur Beschreibung von Ar- chitekturen nach dem Prinzip des separation of concerns:  Enterprise Viewpoint beschreibt den Zweck, den Anwendungsbereich und die grundsätzlichen Re- geln eines verteilten Systems und seiner (Einsatz-) Umgebung sowie typischerweise auch die Analy- se der Benutzer- und Systemanforderungen [3].  Information Viewpoint beschreibt die Semantik der Information und der Informationsverarbei- tung (Informationssichtweise).  Computational Viewpoint beschreibt die Art, wie das System in Funktionseinheiten aufgeteilt ist (funktionale Sichtweise).  Technology Viewpoint beschreibt die gewählte Technologie (Hardware und Software).  Engineering Viewpoint beschreibt die Mecha- nismen zur Unterstützung von verteilten Interak- tionen zwischen Objekten mithilfe der gewählten Technologie (Engineering-Sichtweise). Das RM-ODP ist sehr abstrakt gehalten und grund- sätzlich nicht nur auf serviceorientierte Architekturen (SOA) ausgerichtet. Es ist daher eine verfeinerte Be- schreibung erforderlich, die spezifiziert, wie die ein- zelnen Sichtweisen für eine bestimmte Anwendungs- domäne interpretiert werden sollen. Ein Beispiel dafür ist das Referenzmodell des Open Geospatial Consor- tium (OGC) für serviceorientierte Umweltrisiko- managementsysteme [6]. Bild 1. : Entwicklung von Referenzmodellen für die Merkmale M1 und M2 [3] 3.2 OASIS SOA Reference Model (SOA- RM) Die Organisation for the Advancement of Structured Information Standards (OASIS) verabschiedete 2006 als eine der ersten Standardisierungsorganisationen ein Referenzmodell für serviceorientierte Architektu- ren (SOA-RM) [5]. Das SOA-RM orientiert sich nicht explizit am ISO RM-ODP, kann aber als Interpretati- on der Informations- und funktionalen Sichtweisen für eine generische SOA angesehen werden. Es ist ein abstraktes, technologieneutrales Rahmenwerk, das die folgenden grundsätzlichen Entitäten (SOA-Konzepte) und deren Beziehungen untereinander beschreibt (vgl. Bild 2). Die folgende Auflistung ist eine verkürzte, aber originäre Wiedergabe der einzelnen Konzepte [5]:  Service is a mechanism to enable access to one or more capabilities where the access is provided using a prescribed interface and is exercised con- sistent with constraints and policies as specified by the service description.  Service description represents the information needed in order to use a service.  Visibility is the relationship between service con- sumers and providers that is satisfied when they are able to interact with each other. Pre- conditions to visibility are awareness, willingness and reachability.  Interaction deals with the question about how to interact with the service in order to achieve the required objectives. Key requirements for suc- cessful interactions revolve around the service description which references an information model and a behavior model.  Real world effect captures the consequence of invoking a service, e.g. information returned in response to a request, a change to the shared state of defined entities, or some combination of these two.  Contract and Policy represents some constraint or condition on the use, deployment or descrip- tion of an owned entity as defined by any partici- pant.  Execution context is a set of infrastructure ele- ments, process entities, policy assertions and con- tracts that are identified as part of an instantiated service interaction. Open Distributed Processing (ODP) ISO RM-ODP t 1998 2003 2007 20092006 serviceorientierte Architektur (SOA) OASIS Object Management Group (OMG) OASIS The OpenGroup 2010
  • 7. Industrie 4.0 – Auf dem Weg zu einem Referenzmodell 5 www.vdi.de Bild 2. Grundlegende Konzepte im OASIS SOA-RM Bild 3. Beziehung zwischen den SOA Spezifikationen von OASIS, The Open Group und der OMG [10] Das SOA-RM liefert zudem eine Liste von Richtli- nien für und Erwartungen an Systementwürfe (conformance guidelines), die Konformität zum SOA- RM reklamieren (vgl. Kap. 5). Zudem hat OASIS zwei weitere Spezifikationen erstellt: 1 Eine formale Spezifikation der SOA-RM Konzep- te und deren Beziehungen in einer Ontologie (SOA Meta-Modell) [7], und 2 Grundlagen für eine SOA-Referenzarchitektur gemäß den SOA-RM Vorgaben [9]. Diese konkurriert mit ähnlichen Ansätzen der Open Group [8] und der Object Management Group (OMG), die mit SoaML eine Modellierungssprache für SOA als UML-Erweiterung vorgeschlagen haben [11]. Eine Vereinheitlichung der formalen SOA-Meta- Modelle wurde 2009 versucht und beschrieben [10]. Das SOA-RM wird von den genannten Organisatio- nen als grundlegendes Referenzmodell angesehen, von dem die SOA-Meta-Modelle und Referenz- architekturen von OASIS, OMG und The Open Group abgeleitet werden können (vgl. Bild 3). visibility execution context service service description real world effect contract & policy interaction Service is a mechanism to enable access to one or more capabilities where the access is provided using a prescribedinterface and is exercisedconsistentwith constraints and policies as specified by the service description. • awareness • willingness • reachability OASIS SOA-RM OASIS SOA Ontologie OASIS SOA Referenz- architektur The Open Group SOA Referenzarchitektur OMG SoaML based on similar based on The Open Group SOA Ontologie
  • 8. 6 Industrie 4.0 – Auf dem Weg zu einem Referenzmodell www.vdi.de 3.3 Referenzmodell für das Internet der Dinge Bild 4. IoT Domain Model [16] Für das Internet der Dinge gibt es bislang kein Refe- renzmodell, das von einem internationalen Nor- mungsgremium oder einer Standardisierungsorganisa- tion anerkannt wurde. Das europäische Forschungs- projekt IoT-A3) (Internet of Things – Architecture) hat im Juli 2013 einen Vorschlag für ein Architectural Reference Model (ARM) veröffentlicht [16]. Eine Einführung dazu findet sich in [15]. Seit Abschluss des Projekts wird das ARM in der „Technology”- Arbeitsgruppe des IoT-Forum weitergeführt. Das ARM beinhaltet sowohl ein IoT-Referenzmodell (IoT-RM) als auch die Beschreibung einer konzeptio- nellen Referenzarchitektur. In diesem Statusreport wird nur das IoT-RM vorgestellt (vgl. [16]; Kap. 3). Das IoT-RM orientiert sich an dem OASIS- Verständnis eines Referenzmodells [5] und definiert grundlegende Konzepte und Modelle, die die Spezifi- kation von IoT-Architekturen und -Systemen ermög- licht. Es beinhaltet die folgenden Modelle:  Das IoT Domain Model definiert die grundlegen- den IoT-Konzepte und deren Beziehungen unter- einander (vgl. Bild 4), wie z. B. physische Entität (physical entity) und virtuelle Entität (virtual 3) IoT-A (FP7 257521) – Internet of Things – Architecture entity), Dienst (service), Ressource (resource) als funktionstragende Softwarekomponente sowie Gerät (device) mit den Subkonzepten Sensor, Ak- tor (actuator) und Marke (tag). Einer physischen Entität können eine oder mehrere virtuelle Entitä- ten zugeordnet werden als Repräsentanzen in der virtuellen Welt. Einer physischen Entität kann ein Gerät zugeordnet sein. Es kann über eine oder mehrere Marken identifiziert, durch einen oder mehrere Sensoren beobachtet und über einen oder mehrere Aktoren manipuliert werden. Informati- onen über eine physische Entität werden in virtu- ellen Entitäten und/oder assoziierten Ressourcen gehalten (auf Geräten oder im „Netz“), grund- sätzlich aber nur über Dienste extern zugänglich gemacht.  Das IoT Information Model ist Meta-Modell, das die Struktur der den virtuellen Entitäten zugeord- neten Informationen auf konzeptioneller Ebene beschreibt. Gemäß dem Domänenmodell umfasst dies auch die Struktur der Dienste-, Ressourcen- und Gerätebeschreibungen.  Das IoT Functional Model ist ein Meta-Modell, das die funktionalen Eigenschaften eines IoT- Systems beschreibt. Es kategorisiert IoT- Funktionen in sieben aufeinander aufbauende (longitudinal) Funktionsgruppen (device, com- munication, IoT service, virtual entity, IoT pro- virtual entity service resource physical entity device actuator tag sensor represents n:1 acts on – identifies- monitors network resource on-device resource hosts n:1 exposes m:n associatedwith m:n reads is-a associatedwith m:n is-a hardware software physical entity
  • 9. Industrie 4.0 – Auf dem Weg zu einem Referenzmodell 7 www.vdi.de cess management, service organisation, applica- tion) sowie zwei querschnittliche (transversal) Funktionsgruppen (management, security).  Das IoT Communication Model definiert die hauptsächlichen Formen der Kommunikation und Interaktion (communication paradigms) zwischen den verschiedenen Instanzen von IoT-Domain- Model-Konzepten. Die Beschreibung des IoT Communication Model orientiert sich an den sie- ben Schichten des ISO/OSI 7498-Modells.  Das IoT Trust, Security and Privacy Model be- schreibt die grundlegenden Konzepte zur Kon- zeption und Umsetzung von Vertrauenswürdig- keit (trust), IT-Sicherheit (security) und Privat- heit (privacy) in einem IoT-System. Für die Anwendbarkeit des IoT-Referenzmodells auf eine „Industrie 4.0“-Umgebung und damit für das RM-SA ist insbesondere das IoT Domain Model zu prüfen, da dies grundlegend und verpflichtend ist für die anderen Modelle. Folgende Diskussionspunkte sind hierbei zu beachten bzw. zu klären:  Kann, und wenn ja wie, eine I40-Komponente gemäß dem IoT Domain Model definiert werden?  Wie eng verschränkt sind die Lebenszyklusmo- delle von virtuellen und physischen Entitäten?  Welche Kardinalität soll die Relation zwischen virtuellen und physischen Entitäten haben? Soll z. B. eine virtuelle Entität ohne zugeordnete phy- sische Entität existieren können?  Wie passt das Konzept des Diensts aus dem IoT- RM zu dem gewählten Kommunikations- und Interaktionskonzept im I40-RM-SA, insbesonde- re bezüglich der nicht funktionalen Aspekte, z. B. Sicherheit (Authentifizierung, Autorisierung, Verschlüsselung), Privatheit oder Dienstqualität?  Welche Beziehung haben Funktionen aus dem IoT Functional Model zu Diensten aus dem IoT Domain Model?  Sollen Funktionen ausschließlich über Dienste umgesetzt werden können? Für das gesamte IoT-RM, also über das IoT-Domain- Model hinaus, ist die Frage zu klären, ob und inwie- weit es eine Architektur ermöglicht, die auf den heute in der industriellen Kommunikation gängigen Stan- dards, z. B. Feldbusse und/oder OPC-UA [21] aufsetzt oder inwieweit diese ergänzt bzw. angepasst werden müssten.
  • 10. 8 Industrie 4.0 – Auf dem Weg zu einem Referenzmodell www.vdi.de 4 Auswirkungen auf ein „Industrie 4.0“- Referenzmodell für den Themenbereich „SA“ (Systemarchitektur) Bild 5. Aufbau eines I40-RM-SA aus ISO RM-ODP, SOA und IoT-Referenzmodellen Die Merkmale verteilter Systeme und serviceorien- tierter Architekturen, die auch die Grundpfeiler für ein Internet der Dienste bilden, sowie das Internet der Dinge sind grundsätzlich zu betrachtende Ansätze auf dem Weg zu einem „Industrie 4.0“-Referenzmodell „Systemarchitektur“ (RM-SA). Diese Vorgehenswei- se ist in Bild 5 beschrieben. Dabei sind die genannten Referenzmodelle gemäß den Anforderungen der bislang betrachteten „Industrie 4.0“-Anwendungsfälle zu bewerten. Es ist zu prüfen, welche Änderungen notwendig sind oder ob grund- sätzlich neue Modelle erstellt werden müssen. Daher sind mindestens folgende Vorarbeiten zu leis- ten, bevor mit der Spezifikation eines RM-SA begon- nen werden kann: 1 Es ist unter den Beteiligten der „Industrie 4.0“- Plattform zu klären, ob ISO RM-ODP oder wel- ches andere Referenzmodell für verteilte Systeme eingesetzt werden soll. Eine Übersicht über mög- liche Alternativen gibt [19]. 2 Die Ansätze des OASIS SOA-RM und des IoT-A Architectural Reference Model (ARM) sollten auf ihre Tauglichkeit in einer „Industrie 4.0“ Umge- bung geprüft werden. Besonders zu beachten sind hierbei, je nach Wertschöpfungskette, die nicht- funktionalen Systemanforderungen der industriel- len Produktion, z. B. Robustheit, Zuverlässigkeit, Echtzeitfähigkeit, Betriebssicherheit (safety) und IT-Sicherheit (security). 3 Es ist zu prüfen, inwieweit die betrachteten Refe- renzmodelle für das Internet der Dinge und Diens- te untereinander kompatibel sind. Dies betrifft insbesondere die Frage, ob das IoT- Domänenkonzept „Service“ zusammen mit seinen zugeordneten Konzepten und Modellen (IoT ser- vice model) mit dem Dienstverständnis des OASIS SOA-RM verträglich ist. 4 Es sollten die Spezifika von konzeptionellen Ar- chitekturen herausgearbeitet werden, die sich an den Wertschöpfungsketten orientieren. Daraus können weitere Anforderungen an ein RM-SA ab- geleitet werden. Gemäß SOA-RM ist ein Referenzmodell ein abstrak- tes Rahmenwerk (vgl. Bild 6),  das die grundlegenden Beziehungen zwischen den Entitäten (z. B. die SOA-RM-Konzepte) ei- ner Umgebung definiert, verteilte Systeme I40-Referenzmodell „Systemarchitektur“ serviceorientierteArchitektur Internet der Dinge Sicht- weisen Archi- tektur Trans- parenz- aspekte Konzept Service Service- Meta- Modell Konzept „Ding“ (virtuell/physisch) Fähigkeiten Funktionsgruppen Kommunikation Konzept Trust Privacy Security Bewertung und Harmonisierung
  • 11. Industrie 4.0 – Auf dem Weg zu einem Referenzmodell 9 www.vdi.de  Regeln, Notationen, Begriffe und Modellierungs- sprachen technologieneutral festlegt,  Sichtweisen auf Architekturen definiert (z. B. die Sichtweisen des RM-ODP),  die Einhaltung von relevanten Standards vor- schreibt oder vorschlägt (optional)  und dadurch die Spezifikation von Architekturen ermöglicht. Ein wesentliches Ziel ist, konzeptionelle Architektu- ren zu beschreiben, die als Referenzarchitektur in der „Industrie 4.0“-Community akzeptiert werden. Ein mögliches Beispiel hierfür wäre eine Architektur auf der Grundlage der OPC-UA-Spezifikationen und zugehöriger Companion Standards [21]. Die Betrachtung der beiden Referenzmodelle ISO RM-ODP und OASIS SOA-RM zeigt zudem die Bedeutung der Unterscheidung von  konzeptionellen Architekturen, die technolo- gieunabhängig sind, aber als Vorlage dienen für  technologiebezogene und zweckorientierte Im- plementierungsarchitekturen. Diese zeichnen sich durch die Verwendung bestimmter Architek- turstile und Dienstmuster aus. Im SOA-Bereich sollen hier die Architekturstile „re- quest/reply SOA“, „REST“ oder „ereignisbasiert“ erwähnt werden. SOA-Dienstmuster, z. B. Enterprise Service Bus (ESB) oder Event-Driven Messaging (mit publish/subscribe-Mechanismen), sind beispielsweise in [12] definiert. Bild 6. : Referenzmodelle ermöglichen die Spezifikation von Architekturen . Meta-Modell für Architektur- beschreibungen für Dienst- systeme Es definiert insbesondere: • abstraktes Rahmenwerk • Sichtweisen auf Architekturen • Regeln, Notationen, Terminologie, Modellierungssprachen • ggf. Standard-Vorgaben Spezifikation von Architekturen ermöglicht konzeptionelle Architektur Implementierungs- architektur (zweckorientiert, technologiebezogen) Vorlage für Architekturstile Dienstemuster pub/sub publish/find/bind …. request/response REST event-driven …. www.SOApatterns.org
  • 12. 10 Industrie 4.0 – Auf dem Weg zu einem Referenzmodell www.vdi.de 5 Konformität zu einem SOA-Referenzmodell Für die letztendliche Auswahl des Referenzmodells für die „Industrie 4.0“ Systemarchitektur ist die Frage entscheidend, wie die Konformität zu einem Refe- renzmodell festgestellt werden kann. Das OASIS SOA-RM hat für serviceorientierte Architekturen die Festlegung getroffen, das eine SOA-RM-konforme Spezifikation die grundlegenden SOA-RM-Konzepte referenzieren muss in folgendem Sinne:  Der Entwurf eines SOA-Systems soll Konzepte haben, die als services im Sinne des SOA-RM angesehen werden können (Beschreibung eines Dienste-Meta-Modells).  Dienste sollen eine assoziierte Dienstbeschrei- bung (service description) besitzen (nach einem vorgegeben Muster und einer vorgegeben Notati- on).  Es soll spezifiziert werden, wie Sichtbarkeit (visibility) zwischen Diensterbringer und Dienst- nutzer hergestellt wird.  Es soll spezifiziert werden, wie die Interaktionen (interaction) zwischen den Systemkomponenten gemäß dem Dienste-Meta-Modell vermittelt und aufgebaut werden.  Es soll spezifiziert werden, welcher Effekt (real- world effect) eine Dienstenutzung mit sich bringt.  Es soll der Ausführungskontext (execution context) spezifiziert werden, der zur Unterstüt- zung von Interaktionen notwendig ist.  Es soll ersichtlich sein, wie Ausführungsregeln (policies) gehandhabt werden und wie Verträge (contracts) modelliert und durchgesetzt werden. Analog dazu sollten zu allen wesentlichen Aspekten und Konzepten eines „Industrie 4.0“-Referenzmodells „Systemarchitektur“verpflichtende Konformitätsricht- linien (conformance guidelines) erstellt werden, mit- hilfe derer Konformität geprüft und getestet werden kann.
  • 13. Industrie 4.0 – Auf dem Weg zu einem Referenzmodell 11 www.vdi.de 6 Abkürzungen ARM (IoT-A) Architectural Reference Model ESB Enterprise Service Bus I40 „Industrie 4.0“ IoT Internet of Things (Internet der Dinge) IoT-A Internet of Things – Architecture (EU- Projekt) ISO International Organization for Standardiza- tion OASIS Organization for the Advancement of Structured Information Standards OMG Object Management Group REST Representational State Transfer RM-SA Referenzmodell für den Themenbereich Systemarchitektur RM-ODP Reference Model for Open Distributed Processing SOA Service-orientierte Architektur SOA-RM (OASIS) Referenzmodell für service- orientierte Architekturen SOA-ML (OMG) Service oriented architecture Mod- eling Language 7 Begriffe Vorbemerkung Die folgenden Begriffe sind für das Verständnis dieses Statusreports definiert. Sie sind noch nicht im Rahmen der Arbeiten zu einem „Industrie 4.0“- Referenzmodell als Glossar vollständig abgestimmt und anerkannt. Dies ist eine derzeit laufende Arbeit im GMA-Fachausschuss 7.21. Dienst Abgegrenzter Funktionsteil, der von einer Entität oder Organisation über Schnittstellen angeboten wird. (in Anlehnung an [17] und [22]) Entität Gegenstände, die in der Informationswelt eigene Ob- jekte zu ihrer Verwaltung und Nutzung besitzen. [17] „Industrie 4.0“-Komponente Komponente, die folgende Voraussetzungen erfüllt: ‒ I40-konform kommunikationsfähig ‒ dem System zumindest individuell bekannt ‒ besitzt die für einen zuverlässigen und sicheren Betrieb in einem I40-System von allen Teil- nehmern geforderten Eigenschaften z.B. bezüglich Robustheit, Verfügbarkeit, Echtzeitfähigkeit usw. [20] Kernmodell Einfache modellmäßige Beschreibung von grundle- genden Konzepten und Zusammenhängen, die einen allgemeinen Aspekt von Systemen betreffen. [17] Referenzarchitektur Konzeptionelle Architektur, die in einer Community als Referenz akzeptiert ist. Referenzmodell Schlüssige Beschreibung von Aspekten in einem Anwendungsbereich. [2] Referenzmodell <verteilte (z.B. serviceorientierte) Systeme> Meta-Modell für Architekturbeschreibungen (von z. B. Dienstsystemen). Es definiert insbesondere ‒ ein abstraktes Rahmenwerk ‒ Sichtweisen, die in Architekturbeschreibungen definiert werden sollen ‒ grundsätzliche Konzepte und Kernmodelle ‒ Begriffe, Regeln, Notationen und Modellierungssprachen ‒ ggf. Standard-Vorgaben [5] Wertschöpfungskette Modell der Wertschöpfung als sequenzielle, abgestuf- te Reihung von Tätigkeiten beziehungsweise Prozes- sen von der Entwicklung über die Beschaffung, die Produktion und die Distribution bis hin zu Vermark- tung und Dienstleistungen [18]
  • 14. 12 Industrie 4.0 – Auf dem Weg zu einem Referenzmodell www.vdi.de 8 Literatur [1] Plattform „Industrie 4.0“: Was „Industrie 4.0“ (für uns) ist. http://www.plattform-i40.de/blog/was-industrie-40- für-uns-ist (Stand 27.03.2014) [2] VDE: Die Deutsche Normungs-Roadmap „Industrie 4.0“. Version 1.0 (Stand 11.12.2013). http://www.dke.de/de/std/Seiten/Industrie40.aspx [3] Usländer, T.: Service-oriented Design of Environmen- tal Information Systems, Dissertation Karlsruher Insti- tut für Technologie (KIT). KIT Scientific Publishing, ISBN 978-3-86644-499-7, 2010 [4] ISO/IEC 10746-1:1998: Information technology – Open Distributed Processing – Reference model. Genf: ISO 1; 1998. [5] OASIS: Reference Model for Service Oriented Archi- tecture 1.0. OASIS Standard, 12 October 2006. http://docs.oasis-open.org/soa-rm/v1.0/ [6] Usländer, T. (ed.): Reference Model for the OR- CHESTRA Architecture Version 2.1”. OGC Best Practices Document 07-097, 2007. http://portal.opengeospatial.org/files/?artifact_id=232 86 [7] OASIS: Reference Ontology for Semantic Service Oriented Architectures, Version 1.0 Public Review Draft 01 5 November 2008. http://docs.oasis-open.org/semantic-ex/ro- soa/v1.0/see-rosoa-v1.0.pdf [8] The Open Group: Service-Oriented Architecture Ontology. The Open Group Technical Standard, refer- ence C104. Oktober 2010. US ISBN 1931624887, https://www2.opengroup.org/ogsys/catalog/C104 [9] OASIS: Reference Architecture Foundation for Ser- vice Oriented Architecture Version 1.0. OASIS Committee Specification 01, 04 December 2012. http://docs.oasis-open.org/soa-rm/soa- ra/v1.0/cs01/soa-ra-v1.0-cs01.html [10] Kreger, H.; Estefan, J.: Navigating the SOA Open Standards Landscape Around - Architecture White Paper. http://www.opengroup.org/soa/source- book/stds/index.htm [11] OMG: Service oriented architecture Modeling Lan- guage (SoaML) Specification Version 1.0.1, Mai 2012. http://www.omg.org/spec/SoaML/1.0.1 [12] Erl, T.: SOA design patterns. Prentice Hall, 2008. ISBN 0-13-613516-1 http://soapatterns.org [13] Pfrommer, J.; Schleipen, M.; Beyerer, J.: Fähigkeiten adaptiver Produktionsanlagen. atp-Edition 55 (2013), No.11, pp.42-49, ISSN: 2190-4111 [14] Schleipen, M.: Adaptivität und semantische Interope- rabilität von Manufacturing Execution Systemen (MES). Dissertation Karlsruher Institut für Technolo- gie (KIT). KIT Scientific Publishing, 2013. 388 S., ISBN: 978-3-86644-955-8 [15] IoT-A Consortium: Introduction to the Architectural Reference Model for the Internet of Things. 2013. http://www.iot-a.eu/public/public- documents/copy_of_d1.2/view [16] IoT-A Consortium; Carrez, F. (ed.): Final architectur- al reference model for the IoT v3.0.IoT-A Deliverable D1.5, 2013. http://www.iot-a.eu/public/public- documents/d1.5/view [17] DIN TR-xx: Kernmodelle – Beschreibung und Bei- spiele. Entwurfsvorlage zur Genehmigung durch den K931 am 12.12.2013 [18] VDI Statusreport: „Industrie 4.0“ – Wertschöpfungs- ketten. Düsseldorf: VDI e.V., VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik, April 2014 [19] Matthes, D.: Enterprise Architecture Frameworks Kompendium. Springer Xpert.press, 2011. ISBN 978- 3-642-12954-4 [20] VDI Statusreport: „Industrie 4.0“ – Gegenstände, Entitäten, Komponenten. Düsseldorf: VDI e.V., VDI/VDE-Gesellschaft Mess- und Automatisierungs- technik, April 2014 [21] OPC Foundation: OPC Unified Architecture. Wegbe- reiter der 4. Industriellen (R)Evolution. http://www.opcfoundation- events.com/uploads/media/OPC-UA-Wegbereiter-der- IE40-DE-v2.pdf [22] ISO 19119:2005: Geographic Information-Services. Genf: ISO 2 2005
  • 15. Industrie 4.0 – Auf dem Weg zu einem Referenzmodell 13 www.vdi.de 9 VDI/VDE-GMA-Fachausschuss „Industrie 4.0“ Das Gelingen des Projekts „Industrie 4.0“ und damit der gemeinsamen Bemühungen der deutschen Indust- rie und Hochschulen erfordert ein einheitliches Ver- ständnis der grundlegenden Begriffe, Referenzmodel- le und Architekturkonzepte, an denen sich die Ent- wicklung ausrichten kann. Hierfür ist eine Standardi- sierung unbedingt erforderlich. Viele Standards zu den verwandten Themen „Industrielle Kommunikati- on“, „Engineering“, „Modellierung“, „IT-Sicherheit“, „Geräteintegration“ sowie zur „Digitalen Fabrik“ sind bereits existent. Doch für den Erfolg des Projekts „Industrie 4.0“ ergibt sich ein zusätzlicher Standardi- sierungsbedarf. Der GMA-Fachausschuss „Industrie 4.0“ fokussiert derzeit auf folgende Punkte: Begriffe, Konzepte und Referenzmodelle für „Industrie 4.0“. Im Vordergrund steht die konsensbasierte Regelsetzung. Prof. Dr.-Ing. Ulrich Epple (Vorsitzender) RWTH Aachen Dr. Thomas Bangemann ifak e.V. Magdeburg Dipl.-Ing. Matthias Barbian Siemens AG Dipl.-Inform. Christian Bauer Siemens AG Dr. Annerose Braune TU Dresden Dipl. Ing. (BA) Markus Diesner MPDV Mikrolab GmbH Dipl.-Ing. Jens Friedrich ISW Uni Stuttgart Florian Göbe, M. Sc. RWTH Aachen Prof. Dr. Thomas Greiner Hochschule Pforzheim Dipl.-Inform. Sten Grüner RWTH Aachen Eur. Ing. Roland Heidel Siemens AG Dr.-Ing. Werner Herfs RWTH Aachen Dr.-Ing. Klaus Hesselmann Your Expert Cluster GmbH Dipl.-Ing. Markus Janßen RWTH Aachen Prof. Dr.-Ing. Jürgen Jasperneite Hochschule Ostwestfalen-Lippe Dr. Heinrich Kehl NuK Consulting UG Dr.-Ing. Heiko Koziolek ABB Forschungszentrum Dipl.-Ing. Albrecht Lederer Your Expert Cluster GmbH- i.G. Dipl.-Ing. Sven Lohde Bundesamt für Sicherheit in der Informationstechnik Dr.-Ing. Matthias Loskyll DFKI GmbH Dr. Ulrich Löwen Siemens AG Dipl.-Ing. Frank Lubnau Siemens AG Dipl.-Ing. Julius Pfrommer Fraunhofer- IOSB Dr.-Ing. Miriam Schleipen Fraunhofer IOSB Dipl.-Ing. Matthias Schnurrer unipo GmbH Dipl.-Ing. Holk Traschewski Your Expert Cluster GmbH Dr.-Ing. Thomas Usländer (Korrespondenzautor) Fraunhofer IOSB Prof. Dr.-Ing. Clemens Westerkamp Hochschule Osnabrück (FH) Dipl.-Ing. Albrecht Winter J. Schmalz GmbH Prof. Martin Wollschlaeger TU Dresden (FH)
  • 16. Verein Deutscher Ingenieure e.V. VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik Tel. +49 211 6214-226 gma@vdi.de www.vdi.de