Post on 06-Sep-2019
RAMI 4.0 und ARVIDA –
Referenzarchitekturmodelle für die
Industrie 4.0 im Vergleich
Autor: Sarah Brauns
Ausarbeitung im Rahmen des Master-Studiengangs „Automotive Production“ an der Ostfalia
Hochschule für angewandte Wissenschaften in Wolfenbüttel
Inhaltsverzeichnis I
Inhaltsverzeichnis
ABKÜRZUNGSVERZEICHNIS II
ABBILDUNGSVERZEICHNIS IV
1 EINLEITUNG 5
2 RAMI 4.0 6
2.1 DAS MODELL 6 2.2 INDUSTRIE 4.0-KOMPONENTE 11 2.3 LIFE-CYCLE-MANAGEMENT 13 2.4 DIE UMSETZUNGSSTRATEGIE 15
3 ARVIDA 18
3.1 DAS PROJEKT 18 3.2 DIE REFERENZARCHITEKTUR 20
3.2.1 ARCHITEKTURSPRACHE 21 3.2.2 DATENMODELLE 23 3.2.3 ENTWICKLUNGSZIELE 24
3.3 DIE GENERISCHEN ANWENDUNGSSZENARIEN 25
4 VERGLEICH DER MODELLE 29
5 ZUSAMMENFASSUNG UND AUSBLICK 31
6 QUELLENVERZEICHNIS 32
Abkürzungsverzeichnis II
Abkürzungsverzeichnis
3D
API
AR
ART
ARVIDA
BITKOM
BMBF
DKE
DFKI
DIN SPEC
EDV
ERP
GMA
GPS
GSM
HDR
HMD
HMI
HTTP
IEC
IGD
JT
KIT
KMU
QoS
OWL
PbAR
RAMI 4.0
RDF
RDF-S
Drei Dimensionen
Application Programming Interface
Augmented Reality
Advanced Realtime Tracking
Angewandte Referenzarchitektur für virtuelle Dienste und Anwendungen
Bundesverband Informationswirtschaft, Telekommunikation und neue
Medien
Bundesministerium für Bildung und Forschung
Deutsche Kommission Elektrotechnik
Deutsches Forschungszentrum für Künstliche Intelligenz
Deutsche Industrienorm mit Spezifikationen
Elektronische Datenverarbeitung
Enterprise-Resource-Planning
Gesellschaft für Mess- und Automatisierungstechnik
Global Positioning System
Global System for Mobile Communications
Homogene Daten Ressourcen
Head Mounted Display
Human Machine Interface
Hypertext Transfer Protocol
International Electrotechnical Commission
Fraunhofer Institut für graphische Datenverarbeitung
Jupiter Tessellation
Karlsruher Institut für Technologie
Kleine und Mittelständische Unternehmen
Quality of Services
Web Ontology Language
Projektionsbasierte Augmented Reality
Referenzarchitekturmodell für Industrie 4.0
Resource Description Framework
Resource Description Framework Schema
Abkürzungsverzeichnis III
REST
SDR
SGAM
SW
TKMS
TUM
URI
URL
VDE
VDI
VDMA
vrpn
VT
W3C
XML3D
X3D
X3DOM
ZVEI
Representational State Transfer
Strukturierte Daten Ressourcen
Smart Grid Architecture Model
Software
ThyssenKrupp Marine Systems
Technische Universität München
Uniform Resource Identifier
Uniform Resource Locator
Verband der Elektrotechnik und Elektronik
Verein Deutscher Ingenieure
Verband Deutscher Maschinen- und Anlagenbau
Virtual Reality Peripheral Network
Virtuelle Techniken
World Wide Web Consortium
Extensible Markup Language in 3D
Extensible 3D
X-Freedom
Zentralverband der Elektroindustrie
Abbildungsverzeichnis IV
Abbildungsverzeichnis
Abbildung 2.1: Das RAMI 4.0-Modell [HAN15] ....................................................................... 7
Abbildung 2.2: Vier wichtige Aspekte von Industrie 4.0 [ADO15] ............................................... 10
Abbildung 2.3: Vom Gegenstand zur Industrie 4.0-Komponente [KOS15].................................... 12
Abbildung 2.4: Relevante Lebenszyklen für I4.0-Komponenten [ADO15] .................................... 14
Abbildung 2.5: Kernbausteine der Industrie 4.0 [PLA15] .......................................................... 16
Abbildung 3.1: ARVIDA-Logo [ARV15] ................................................................................ 18
Abbildung 3.2: ARVIDA Projektstruktur [ARV15] .................................................................... 19
Abbildung 3.3: ARVIDA Referenzarchitektur [ARV15] ............................................................. 20
Abbildung 3.4: ARVIDA RDF-Vokabular [WIK15] ................................................................... 22
Abbildung 3.5: Szenegraphen [BER12] ............................................................................... 23
Abbildung 3.6: Bewegungserfassung in der LKW-Fahrerkabine [WIK15] ..................................... 25
Abbildung 3.7: Soll-Ist-Vergleich der CAD-Daten eines Motors [ARV15] ...................................... 26
Abbildung 3.8: Werkerunterstützung durch PbAR am Beispiel des XL1 ...................................... 27
Abbildung 3.9: Interaktive Sitzkiste [ARV15] ......................................................................... 28
Einleitung 5
1 Einleitung
In der vorliegenden Ausarbeitung werden Referenzarchitektur-Modelle zum verein-
fachten und standardisierten Umgang mit Umgebungen der Industrie 4.0 vorgestellt.
Diese werden in Form von Verbundprojekten von Wirtschaftsvertretern sowie For-
schungseinrichtungen erarbeitet und haben das Ziel, Richtlinien für Datenstrukturen
und Kommunikationsverhalten sowie eine Referenzarchitektur als Basis für sämtliche
Systeme im Bereich Industrie 4.0 zu entwickeln.
Zum einen wird RAMI 4.0, das Referenzarchitekturmodell für die Industrie 4.0, be-
trachtet, das vom Zentralverband der Elektroindustrie und weiteren Partnern entwi-
ckelt wird und vor allem die Normung und Festlegung übergreifender Regeln beab-
sichtigt. Dazu wird zunächst das Modell mit seinen einzelnen Schichten erläutert.
Anschließend werden die Begriffe „Industrie 4.0-Komponente“ sowie das „Life-Cycle-
Management“ genauer definiert, die ein wichtiger Bestandteil des Modells sind.
Schließlich wird auch die Umsetzungsstrategie beschrieben, mit der die Projekt-
partner die Grundlagen des Modells in die Wirtschaft übertragen wollen.
Zum anderen beschäftigt sich diese Ausarbeitung mit ARVIDA, der angewandten
Referenzarchitektur für virtuelle Dienste und Anwendungen. In diesem Parallelprojekt
vom Bundesministerium für Bildung und Forschung (BMBF) sowie Vertretern aus
Wirtschaft und Forschung soll ebenso eine Referenzarchitektur für Industrie 4.0-
Umgebungen, insbesondere für den Bereich virtueller Techniken entwickelt und an
dafür benötigte Dienste und Anwendungen angebunden werden. Somit wird eine
Austauschbarkeit einzelner Komponenten in modularen Systemen ermöglicht. Zuerst
wird dafür das Projekt beschrieben und auf die Referenzarchitektur allgemein einge-
gangen. Diese wird im Folgenden detailliert in ihrer Architektursprache, den Daten-
modellen sowie den Entwicklungszielen charakterisiert. Zuletzt werden die generi-
schen Anwendungsszenarien vorgestellt, durch die die Umsetzung der Referenzar-
chitektur beispielhaft dargestellt wird.
Im Anschluss werden beide Modelle vor allem im Hinblick auf Ebenen, einbezogene
Bereiche und die Ausbildung der Architektur verglichen, um Unterschiede und Ge-
meinsamkeiten hervorzuheben und die Strukturen gegeneinander abzuwägen.
Zum Schluss der vorliegenden Ausarbeitung wird eine kurze Zusammenfassung vor-
genommen und ein Ausblick auf weitere Schritte der vorgestellten Projekte sowie die
Übertragung der Referenzarchitekturen in die Wirtschaft gegeben.
RAMI 4.0 6
2 RAMI 4.0
Unter der Leitung des Zentralverbandes der Elektroindustrie (ZVEI) sowie im Ver-
bund mit weiteren Institutionen (VDI/VDE; VDMA; GMA; DKE) haben sich Experten
mit den Anforderungen beschäftigt, die der Wandel hin zu Industrie 4.0 für die Unter-
nehmen mit sich bringt. Dazu haben sie grundlegende Bestandteile und Komponen-
ten von Industrie 4.0 in einem Modell zusammengeführt, dem Referenzarchitektur-
modell RAMI 4.0. Dieses wird im Folgenden vorgestellt und dessen Aufbau detailliert
erläutert. Zudem werden die zugrunde liegenden wichtigsten Aspekte der vierten In-
dustrialisierung kurz erläutert. Weiterhin wird auf die Umsetzungsstrategie des Mo-
dells und die damit verbundenen Auswirkungen auf die Wirtschaft sowie die Realisie-
rung der einzelnen Bestandteile eingegangen.
2.1 Das Modell
Das Referenzarchitekturmodell RAMI 4.0 ist eine Anpassung sowie Erweiterung des
Smart Grid Architecture Models (SGAM), das 2012 von Siemens Infrastructure & Ci-
ties entwickelt wurde, um Systemaspekte intelligenter Stromversorgungsnetzwerke
darzustellen. [Vgl. BIE12] Dieses Modell wurde durch die Experten im Rahmen von
RAMI 4.0 um den Ansatz einer Anbindung an die vierte Industrialisierung erweitert.
Nach Angaben der Projektpartner soll es die „Kombination von Lebenszyklus und
Wertschöpfungskette mit einem hierarchisch strukturierten Ansatz für die Definition
von I4.0-Komponenten“ charakterisieren. [ADO15, S. 6] Weiterhin soll es dazu bei-
tragen, die Anpassung und Umsetzung bestehender Systeme im Hinblick auf die
Veränderungen und Anforderungen von Industrie 4.0 schneller zu bewältigen. Auch
eine elektronische Erfassung von Beziehungen der einzelnen Bereiche und Kompo-
nenten untereinander soll ermöglicht werden. [Vgl. HAN15]
Um möglichst viele Bereiche der Industrie in einem Modell zusammenführen zu kön-
nen, bedient sich RAMI 4.0 drei wichtiger Kriterien, die auf jeweils einer Achse dar-
gestellt wurden (s. Abb. 2.1).
RAMI 4.0 7
Abbildung 2.1: Das RAMI 4.0-Modell [HAN15]
Die Hierarchie-Ebenen der Unternehmenssoftware sind auf der rechten horizontalen
Achse abgebildet. Sie charakterisieren die verschiedenen Funktionalitäten innerhalb
einer Fabrik oder Anlage in Anlehnung an die IEC 62264 und die IEC 61512, die sich
mit der Integration von Unternehmens-EDV und Leitsystemen sowie der damit ver-
bundenen chargenorientierten Ablaufsteuerung befassen. In RAMI 4.0 sind die Inhal-
te um das Werkstück „Product“ sowie um das Internet der Dinge „Connected World“
ergänzt, um eine Industrie 4.0-Umgebung systematisch abbilden zu können. Damit
dieses Kriterium der Hierarchieebenen auf vielfältige Branchen übertragbar ist, wer-
den im Referenzarchitekturmodell verallgemeinernd die Begriffe „Enterprise“, „Work
Unit“, „Station“ und „Control Device“ verwendet. Die Hierarchieebene „Field Device“
stellt die funktionale Ebene eines intelligenten Sensors o.Ä. dar. Mithilfe dieser Achse
des Modells kann eine geschlossene Betrachtung von Entität1, Anlage und den damit
verbundenen Abhängigkeiten erfolgen. Durch die Ebene der „Connected World“ sind
auch ein übergreifender I4.0-Fabrikverbund sowie Big Data2-Prinzipien innerhalb und
zwischen den Unternehmen skizzierbar. [Vgl. HAN15]
1 Eindeutig bestimmbares Objekt in der Informatik, über das Informationen gespeichert oder verarbei-
tet werden [ENT15] 2
Massendaten [BIG15]
RAMI 4.0 8
Ein weiteres Kriterium, das im Modell auf der linken horizontalen Achse repräsentiert
ist, bezieht sich auf den Lebenszyklus von Anlage und Produkt sowie die damit ein-
hergehenden Wertschöpfungsprozesse. Der Bereich „Life Cycle and Value Stream“
wurde in Anlehnung an die IEC 62890 eingefügt, die sich mit den Grundlagen des
Life-Cycle-Managements von Unternehmenssoftware befasst. Der Bereich des Life
Cycle, der in „Typ“ und „Instanz“ unterteilt ist, ermöglicht die Skizzierung der durch-
gängigen Datenerfassung entlang des Produkt-Lebenszyklus. Dabei bezeichnet der
Typ den Bereich der Produktentwicklung und Prototypenfertigung aus Unterneh-
menssicht. Das für den Kunden zum Verkauf angebotene fertige Produkt ist ebenfalls
zunächst ein Typ. Zur Instanz wird ein Typ im Unternehmen, wenn das Produkt ge-
fertigt wurde. Baut der Kunde dieses wiederum in eine Anlage ein, wird der Typ glei-
cherweise zur Instanz. [Vgl. HAN15, PLA15]
Das dritte Kriterium des Modells ist in Layer unterteilt, die die sechs Schichten der IT-
Repräsentanz innerhalb eines Unternehmens abbilden sollen. In diesem Bereich sol-
len digitale Schichtmodelle z.B. von Maschinen geclustert und in Teilbereiche zerlegt
werden, um diese komplexen Modelle verständlich darzustellen. Der unterste „Asset
Layer“ charakterisiert dabei die Beschreibung von Maschinen, Komponenten sowie
der Produktionsstruktur und repräsentiert die Realität. Darauf folgt der „Integration
Layer“. Dieser kennzeichnet die digitale Umsetzung der Assets in virtuelle Kompo-
nenten. Darunter wird auch der Bereich des Human Machine Interface (HMI) be-
trachtet, der die Interaktion von Industrie 4.0-Komponenten mit dem Menschen ein-
bezieht. Im Integration Layer werden zudem die Asset-Informationen bereitgestellt,
da jedes reale Ereignis hier direkt auf ein virtuelles Ereignis hinweist.
Auf der nächsten Ebene der Achse, im „Communication Layer“ sind Kommunikati-
onsstrukturen wie Protokolle und Standards der Datenübertragung festgehalten. Die-
se werden durch ein einheitliches Format vereinfacht. Weiterhin stellt der Communi-
cation Layer Dienste zur Steuerung des Integration Layer bereit. In der darauf fol-
genden Ebene der IT-Repräsentanz, dem „Information Layer“, sind Beschreibungen
und Ausführungen von Regeln hinterlegt. Dieser Layer dient gleichzeitig der Ereig-
nisvorverarbeitung und stellt Daten mittels Dienstschnittstellen bereit. Der darüber
liegende „Functional Layer“ beschreibt existenzielle Funktionen wie beispielsweise
Enterprise-Resource-Planning (ERP) und dient als Basis für die horizontale Integrati-
on. Zudem charakterisiert er Dienste hinsichtlich deren Laufzeit- und Modellierungs-
umgebung und erzeugt Regeln sowie Entscheidungslogiken. In der obersten Ebene,
RAMI 4.0 9
dem „Business Layer“, sind Geschäftsprozesse abgebildet und mit rechtlichen sowie
regulatorischen Rahmenbedingungen verknüpft. Hier erfolgt ebenfalls die Regelmo-
dellierung. Für alle Layer gilt, dass innerhalb der Schichten eine starke Kohäsion vor-
liegt wohingegen die Zwischenbereiche nur lose verbunden sind. Somit ermöglichen
die drei Achsen des Referenzarchitekturmodells eine schrittweise Eingliederung der
Entitäten in die Industrie 4.0-Welt. [Vgl. ADO15, HAN15]
Mithilfe des RAMI 4.0-Modells soll eine systematische Einordnung und Weiterent-
wicklung von Industrie-4.0-Technologien erreicht werden. Das Architekturmodell
dient als Referenz für die Eingliederung. Es soll dabei helfen, Normen, Standards
und Beziehungen zu erkennen und zu identifizieren sowie daraus allgemeingültige
Regeln zu definieren. Die Projektpartner erhoffen sich dabei, dass durch RAMI 4.0
ein gemeinsames Verständnis für Technologien und komplexe Verhältnisse der vier-
ten Industrialisierung erzielt werden kann. Durch das Modell, als Basis für Diskussio-
nen bezüglich der Anforderungen aus betreffenden Branchen, sollen Standards und
Normen einfacher festgelegt und Anwendungsbeispiele schneller erschlossen wer-
den. Zudem kann die Vereinigung von Problemstellungen der Anwenderindustrie mit
globalen Standards leichter erfolgen. [Vgl. HAN15]
Um die Ziele von RAMI 4.0 umzusetzen, haben sich die Beteiligten auf weitere
Schritte und Prinzipien geeinigt, die die Vernetzung und das Finden von Standards
vorantreiben sollen. Zunächst soll die Identifikation betrachtet werden, mithilfe derer
das selbständige Finden von Entitäten in der vernetzten Produktion unterstützt wird.
Des Weiteren sollen mittels Semantik Rahmenbedingungen und Richtlinien für den
herstellerübergreifenden Datenaustausch festgelegt werden. Der Bereich des „Quali-
ty of Services“ (QoS) definiert wichtige Dienste für Komponenten von Industrie 4.0
wie z.B. die Echtzeitfähigkeit von Systemen. Um das zu ermöglichen, werden für die
Industrie 4.0-Kommunikation geeignete Verbindungen und Protokolle festgelegt. [Vgl.
HAN15]
RAMI 4.0 10
Abbildung 2.2: Vier wichtige Aspekte von Industrie 4.0 [ADO15]
Das Referenzmodell für Industrie 4.0 stützt sich für die Einordnung auf vier Aspekte
(s. Abb. 2.2). Zum einen dient die horizontale Integration über Wertschöpfungsstruk-
turen hinweg als Ansatz zur Gliederung, da sie die globale Vernetzung über Fabriken
hinweg darstellt und Ansätze für den Datenaustausch und Umgang mit Big Data bie-
tet. Zum anderen ist auch die vertikale Integration innerhalb von Fabriken oder Anla-
gen von Bedeutung, da hier Grundlagen für die Bereitstellung aller notwendigen Da-
ten festgelegt sind. Weiterhin wird im Modell auch das Lifecycle-Management in Be-
tracht gezogen. Nur durch übergreifendes Engineering in Form einer Vernetzung und
eines übergreifenden Datenaustauschs von Produktdesign und entlang des Produkt-
entwicklungsprozesses sowie des Produktlebenszyklus bis hin zu Service und In-
standhaltung können Unternehmen den Anforderungen von Industrie 4.0 gerecht
werden. Zuletzt spielt ebenfalls der Mensch als koordinierender Faktor im Hinblick
auf HMI eine wichtige Rolle, da dessen Einbindung den größten Einfluss auf den Er-
folg besitzt. Somit ist eine konsequente Betrachtung dieser vier wichtigen Aspekte für
eine Einordnung in die vierte Industrialisierung unabdingbar. [Vgl. ADO15]
RAMI 4.0 11
2.2 Industrie 4.0-Komponente
Für die Beschreibung von Grundlagen der vierten Industrialisierung bedient sich das
Projekt RAMI 4.0 des Begriffs „Industrie 4.0-Komponente“. Dieser bezeichnet ein
Modell, das die genauere Beschreibung der Eigenschaften cyber-physischer Syste-
me, also realer Objekte, die mit virtuellen Objekten und Prozessen vernetzt sind, er-
möglicht. Somit kann die Industrie 4.0-Fähigkeit von Produktionskomponenten dar-
gestellt werden. Eine in diesem Maße fähige reale Komponente besitzt die Beson-
derheit, dass sie spezifische Daten und Funktionen an einen virtuellen Repräsentan-
ten kommunizieren kann. Zudem ist dieser Gegenstand mit einer Verwaltungsschale
(s. Abb. 2.3) verknüpft, die die Zugänglichkeit aller relevanten Daten für an der Wert-
schöpfung beteiligten Unternehmen und Bereiche gewährleistet und dadurch Mehr-
wert schafft.
Zum einen wird somit der Umgang mit Daten charakterisiert, sodass Datensicherheit,
Verfügbarkeit, Vertraulichkeit und Integrität von Daten klar geregelt sind. Die Verwal-
tungsschale speichert Informationen über die Entität einmalig und stellt diese Daten
dem IT-Dienst bereit. Weiterhin trägt sie zur Integration bei, da die Kombination des
I4.0-konformen Protokolls und der Verwaltungsschale für die horizontale und vertika-
le Integration der Produktion von enormer Bedeutung ist. Nur so kann gewährleistet
werden, dass ein übergreifendes Datenmanagement möglich ist. Dabei gibt dieser
elektronische Container sein Wissen lückenlos weiter. Dies kann auch modular erfol-
gen, indem Informationen über bedeutsame Maschinenbereiche gespeichert werden,
die zukünftig mithilfe von zentralen Wartungssystemen direkt erfasst werden können.
Der Nutzen der Verwaltungsschale für die Unternehmen besteht in der beliebigen
Erweiterung der Daten, der Realisierung smarter Dienste durch neue Informationen
sowie des Vorhaltens von Wissensmodellen sowie fachlicher Funktionen über den
gesamten Integrationsprozess hinweg. Somit leistet dieser Container einen wichtigen
Beitrag zur Industrie 4.0-Fähigkeit der Komponenten. [Vgl. HOF15]
RAMI 4.0 12
Abbildung 2.3: Vom Gegenstand zur Industrie 4.0-Komponente [KOS15]
Welche Gegenstände zu I4.0-Komponenten werden können, ist im Rahmen des
RAMI 4.0-Projektes ebenfalls klar definiert. So müssen alle Gegenstände Entitäten
sein, um mit Daten und Funktionen verknüpft werden zu können. Schließlich sollen
sie dem Informationssystem virtuell Auskunft über ihre reale Beschaffenheit geben.
Daher muss ein solcher Gegenstand eine Kommunikationsfähigkeit besitzen, da das
Informationssystem permanent Verbindung zu ihm hält. Die Informationen des realen
Gegenstandes werden in seiner virtuellen Repräsentation oder im hinterlegten IT-
System festgehalten und sind dort jederzeit abrufbar. Weiterhin besitzt die Kompo-
nente eine fachliche Funktionalität in Form von Software oder anderer Mehrwerte,
die über den realen Gegenstand mithilfe virtueller Daten Auskunft geben. Dabei
macht die Verwaltungsschale aus der Entität eine I4.0-Komponente, indem sie die
virtuelle Repräsentation und Funktionalität des Objektes darstellt. Die Hersteller bzw.
Planer übernehmen die Ausführung als Komponente. Deren Kommunikationsfähig-
keit kann auch passiv sein. Sind Gegenstand und Verwaltungsschale entkoppelt,
bildet ein übergeordnetes IT-System die Funktionalitäten ab.
RAMI 4.0 13
Die Komponenten können weiterhin folgende Eigenschaften besitzen, um für Indust-
rie 4.0 tauglich zu sein: Alle Querverbindungen der virtuellen Repräsentation können
innerhalb einer Fabrik existieren, sodass die Komponente kapselfähig ist. Zudem
kann sie mehrere Gegenstände wie z.B. Zusammenbauten oder Entitäten gleicher
Funktionalität umfassen, um die Darstellung von Zusammenhängen zu vereinfachen.
Komponenten können ebenfalls logisch temporär schachtelbar sein, indem durch
eine logische Abstraktion mehrere Komponenten vereinheitlicht werden und dadurch
die Übersichtlichkeit in übergeordneten Systemen sichergestellt wird. Besitzt die vir-
tuelle Repräsentation eines realen Gegenstandes eine dieser Eigenschaften, kann
sie gemäß RAMI 4.0 als Industrie 4.0-fähig bezeichnet werden und lässt sich in das
Architekturmodell eingliedern. [Vgl. PLA15]
2.3 Life-Cycle-Management
Das Kriterium der Lebenszyklen im Architekturmodell betrachtet alle für eine Fabrik
im Hinblick auf Industrie 4.0 relevanten Aspekte. Dabei können die Lebenszyklen
mehrere Dimensionen besitzen. Zum einen muss für ein Produkt dessen Produkt-
Lebenszyklus beurteilt werden. Dieser setzt sich aus den Planungs- und Konstrukti-
onsphasen zusammen und endet sowohl mit dessen Nutzung als auch dem dazuge-
hörigen Service. Einen weiteren möglichen Lebenszyklus stellt ein Auftrag dar, der
von seinem Eingang über die Ausführung bis hin zum Ausgang in der Fabrik bearbei-
tet wird. Auch die Fabrik selbst besitzt eine eigene Abfolge, die sich von der Planung
und Finanzierung über den Aufbau sowie die Nutzung bis hin zur Wiederverwertung
erstreckt. Die darin eingeplanten Maschinen haben wiederrum einen unabhängigen
Lebenszyklus. Sie werden in Auftrag gegeben, vom Zulieferer konstruiert, in Betrieb
genommen, gewartet, umgebaut und schließlich wiederverwertet. Selbst hinter jeder
Komponente steckt eine eigene Reihenfolge, da die Entität ebenfalls geplant, kon-
struiert, abgesichert, produziert und genutzt wird und somit ihren eigenen Lebenszyk-
lus besitzt. Daher wird auch jede Dimension von Lebenszyklen in individuellen Stufen
zunächst als Typ und schließlich als Instanz bezeichnet und gebraucht. Jedoch liegt
der Übergang von Typ zu Instanz hierbei einheitlich in der Produktion sowie der Inbe-
triebnahme in der Fabrik. [Vgl. ADO15]
Abbildung 2.4. verdeutlicht, dass sich anhand von RAMI 4.0 sämtliche Entitäten in
die Ebene des Life-Cycle eingliedern lassen.
RAMI 4.0 14
Abbildung 2.4: Relevante Lebenszyklen für I4.0-Komponenten [ADO15]
Die einzelnen Lebenszyklen hängen trotzdem voneinander ab, da sich die Kompo-
nenten und Entitäten in einem Verbund befinden. Oft wirken diverse Bereiche zu-
sammen, die am Produkt beteiligt sind. Somit sind auch deren Lebenszyklen unwei-
gerlich miteinander verbunden, weshalb die Abhängigkeiten im Planungsprozess und
im Datenmanagement berücksichtigt werden müssen. Dabei werden die potenziellen
Gegenstände je nach Betrachtungsweise als verschiedene Typen charakterisiert. So
nennt der Zulieferer seine Produkte zunächst Teiletypen, die erst als Zuliefererteil zu
einer Instanz werden. Maschinenhersteller dahingegen planen Maschinentypen. Die-
se werden nach der Realisierung schließlich als Maschineninstanzen bezeichnet.
Anders verhält es sich mit dem Fabrikbetreiber, der zunächst den Produkttypen ent-
wickelt und anschließend die Produktinstanz ausliefert. Aufgrund dieser gegenseiti-
gen Abhängigkeiten ist es wichtig, dass die Datengenerierung bereits beim Typ er-
folgt und bis hin zur Instanz verwendet werden kann, damit die Entität über den ge-
samten Lebenszyklus kommunikationsfähig ist und bereits im frühen Entwicklungs-
stadium Daten an das IT-System übermittelt. [Vgl. ADO15]
RAMI 4.0 15
2.4 Die Umsetzungsstrategie
Mithilfe des Referenzarchitekturmodells RAMI 4.0 soll ein gemeinsames Vorgehen
zum Umgang mit den Anforderungen von Industrie 4.0 über verschiedenste Bran-
chen hinweg erarbeitet werden. Dazu werden gemeinschaftliche Ansätze von For-
schungseinrichtungen und Wirtschaftsvertretern entwickelt. Anhand des Modells sol-
len komplexe Systeme veranschaulicht und erfasst werden können. Daraus sollen
standardisierte Anforderungen für den Datenaustausch in I4.0-Umgebungen und
damit verbundene Sicherheitsaspekte abgeleitet und umgesetzt werden. Gleichsam
zielt das Projekt darauf ab, rechtliche Rahmenbedingungen zu schaffen. Auch der
Bereich der Ressourcen ist ein Kernbaustein für die Projektpartner, da der Umgang
mit diesen einen wichtigen Erfolgsfaktor in zukünftigen Umgebungen darstellt. [Vgl.
PLA15]
Durch die Einordnung der Entitäten und Prozesse in die Referenzarchitektur und die
konsequente Umsetzung der Vorschläge in den Fabriken sollen kleinere Losgrößen
rentabler werden, da Planungsprozesse vereinfacht sind. Zudem ermöglichen dyna-
mische Prozesse sowie der durchdachte Umgang mit Big Data eine neue Form der
Flexibilität innerhalb der Unternehmen. Aufgrund der Durchgängigkeit von Daten-
mengen können Entscheidungsprozesse verbessert und vereinfacht werden. Die
sich daraus ergebende höhere Produktivität sowie der verantwortungsvolle Umgang
mit Ressourcen führen zu einer Steigerung der Produktionseffizienz. Für den Men-
schen ergeben sich durch die Industrie 4.0-Komponenten völlig neue Arbeitskonzep-
te und Unterstützungsmöglichkeiten. Die Projektpartner von RAMI 4.0 erhoffen sich
durch diese Vorteile vor allem den Ausbau des Vorsprungs Deutschlands als Indust-
riestandort. [Vgl. PLA15]
Für diese Umsetzungsstrategie haben sie in Form einer Roadmap konkrete Kern-
bausteine der Industrie 4.0 definiert, die die Digitalisierung von Wertschöpfungsket-
ten und –netzwerken unterstützen (s. Abb. 2.5).
RAMI 4.0 16
Abbildung 2.5: Kernbausteine der Industrie 4.0 [PLA15]
Die Kernbausteine der Umsetzungsstrategie befinden sich im Bereich der Forschung
und Innovation. Dieser Arbeitsschritt soll die firmenübergreifende Kooperation sowie
ein durchgängiges Engineering entlang der Wertschöpfungsprozesse und des Le-
benszyklus darstellen. Dazu werden Methoden für neue Geschäftsmodelle sowie
Rahmenbedingungen für Wertschöpfungsnetzwerke benötigt. Diese können auch
automatisiert werden, um die Durchgängigkeit zu vereinfachen. Für das durchgängi-
ge Engineering sind die Integration von realer und virtueller Welt sowie das Systems
Engineering3 von Bedeutung, um die komplexen Zusammenhänge darzustellen. Die
vertikale Integration fordert intelligente Sensoren und Sensornetze, die flexibel und
wandelbar sind, um auf veränderte Bedingungen des Umfelds reagieren zu können.
Gleichermaßen soll die Vernetzung der Produktion mithilfe der durchgängigen Da-
3 interdisziplinärer Ansatz in großen Projekten zur Entwicklung und Realisierung von komplexen Sys-
temen [Vgl. SYS15]
RAMI 4.0 17
tenübertragung in Echtzeit vorangetrieben werden. Dies geschieht vor allem durch
die Querschnittstechnologien im Zusammenhang mit Big Data. Dazu gehören Ansät-
ze für die Netzkommunikation, Mikroelektronik, Sicherheit sowie Datenanalyse- und
Semantik-Standards. Ungeachtet aller technischen Kernbausteine ist auch vor allem
der Mensch als positiver Faktor in der Arbeitswelt konsequent zu berücksichtigen, da
seine Technologieakzeptanz und Arbeitsgestaltung den wichtigsten Erfolgsfaktor der
Zusammenarbeit und Produktivität in einer Industrie 4.0-Umgebung darstellt. Durch
multimodale Assistenzsysteme ergeben sich neue Formen der Unterstützung sowie
veränderte soziale Infrastrukturen innerhalb einer Firma. [Vgl. PLA15]
Die Referenzarchitektur sowie die damit einhergehende Standardisierung und Nor-
mung soll durch die Erstellung einer lösungsneutralen Architektur ermöglicht werden.
Sie ist von großer Bedeutung, da sie alle Kernbausteine der Industrie 4.0 umfasst. In
gleicher Weise ist die Systemsicherheit zu betrachten, da diese ebenfalls mit allen
Aspekten verknüpft ist. In einer Industrie 4.0-Umgebung ist es unabdingbar, dass die
IT-Sicherheit gewährleistet wird und Sicherheitsprinzipien auf Basis allgemeiner An-
forderungen verwendet werden, um Störungen des Systems zu vermeiden. Zuletzt
umfasst auch der Bereich der rechtlichen Rahmenbedingungen alle Baustein-
Ebenen, da die Gestaltung von Produktionsprozessen und horizontalen Firmennetz-
werken klar definierten Regeln folgen muss. Nur so können Richtlinien konsequent
durchgesetzt und die Zusammenarbeit verschiedener Firmen ermöglicht werden.
[Vgl. PLA15]
ARVIDA 18
3 ARVIDA
„ARVIDA“ steht für „Angewandte Referenzarchitektur für virtuelle Dienste und An-
wendungen“ und ist ein vom Bundesministerium für Bildung und Forschung geförder-
tes Verbundprojekt, an dem derzeit 21 Projektpartner aus Industrie, kleinen sowie
mittelständischen Unternehmen (KMU) als auch aus der Wissenschaft beteiligt sind.
Die Konsortialleitung liegt bei der Volkswagen AG in Person von Prof. W. Schreiber.
Dieses Projekt hat im September 2013 begonnen und eine Laufzeit von drei Jahren.
Im folgenden Kapitel wird das Projekt mit allen Teilprojekten beschrieben und die
generischen Anwendungsszenarien erläutert. Weiterhin wird die dem Projekt zu-
grunde liegende Referenzarchitektur detailliert aufgeführt und auf das verwendete
Vokabular eingegangen. Zudem erfolgt ein Überblick über die Umsetzungsstrategie,
die weiteren Projektschritte sowie den Transfer in die Unternehmen.
Abbildung 3.1: ARVIDA-Logo [ARV15]
3.1 Das Projekt
Im Rahmen der Industrie 4.0 und dem zunehmenden Einfluss von virtuellen Techni-
ken in den Unternehmen soll das Forschungsprojekt ARVIDA dazu beitragen, eine
einheitliche Referenzarchitektur zur Modularität und Austauschbarkeit der Systeme
ohne bisher notwendige Implementierungen in andere Programmiersprachen zu
schaffen. Diese soll mithilfe der Projektpartner entwickelt, umgesetzt und schluss-
endlich weiteren Unternehmen zur Verfügung gestellt werden. Dazu forschen ver-
schiedene Unternehmen sowie Institute aus Industrie, KMU und Wissenschaft geför-
dert vom BMBF an generischen Anwendungsszenarien und arbeiten übergreifend an
Teilprojekten, in denen die Umsetzung der entwickelten Methoden und Komponenten
dargestellt werden soll. Die Projektpartner sind in Architekten, Technologen und An-
wender aufgeteilt. Dabei besteht die Aufgabe der Architekten, zu denen u.a. das
Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI), das Karlsruher Insti-
tut für Technologie (KIT) oder auch die Technische Universität München (TUM) zäh-
len, darin, das Vokabular für eine Referenzarchitektur zu entwickeln. Mithilfe dieser
können verschiedenste Systeme und Komponenten virtueller Techniken auf einheitli-
ARVIDA 19
cher Basis kommunizieren. In der Projektstruktur in Abbildung 3.2 ist dieses durch
das „Teilprojekt 1 Referenzarchitektur“ definiert. Im „Teilprojekt 2 Tracking und Um-
felderkennung“ hingegen erarbeiten die Technologen, wie z.B. das Fraunhofer Insti-
tut für graphische Datenverarbeitung (IGD), die Firmen Advanced Realtime Tracking
(ART) und 3DExcite, im Rahmen von ARVIDA einen Trackingalgorithmus, der spezi-
ell für das industrielle Umfeld geeignet sein soll und schließen diesen an die von den
Architekten erarbeitete Referenzarchitektur an. Dieser Algorithmus soll ebenfalls mo-
dular und ohne spezielles Wissen nutzbar sein. Um dieses Ziel zu erreichen, fokus-
sieren sich die Technologen auf markerloses Outside-In-Tracking4. Die an dem Ver-
bundprojekt beteiligten Anwender, wie u.a. Daimler und Volkswagen, setzen die ent-
wickelte Technologie schließlich im Rahmen sogenannter generischer Anwendungs-
szenarien im Teilprojekt 3 um.
Abbildung 3.2: ARVIDA Projektstruktur [ARV15]
4 Trackingverfahren ohne optische Messpunkte (Marker) mit fest installierter, unbeweglicher Kamera
ARVIDA 20
3.2 Die Referenzarchitektur
Im ARVIDA-Verbundprojekt entwickeln die Architekten eine Referenzarchitektur für
virtuelle Dienste und Anwendungen (s. Abb. 3.3). Diese ist in ARVIDA-Dienste, Re-
presentational State Transfer (RESTful), ARVIDA-Architekturkonzepte sowie VT-
Anwendungen strukturiert und basiert auf den vom World Wide Web Consortium
(W3C) anerkannten Standards. Dabei beinhalten die ARVIDA-Dienste Konzepte für
das Rendering, die Navigation, die Interaktion, Tracking, Daten-Transcoding, Multi-
agenten, Simulationen, Datenbanken, generische Menschmodelle sowie Animatio-
nen. Diese Dienste sind mithilfe von RESTful, einem Programmierschema für verteil-
te Systeme, an die Architekturkonzepte angebunden. Die einzelnen Architekturkon-
zepte von ARVIDA bestehen in den RDF-Vokabularen (Resource Description
Framework), den Linked Data Prinzipien, den standardisierten Rückgabewerten, ein-
heitlichen Dienstverhalten sowie der Komposition und der DataFu Engine. Diese Ar-
chitekturkonzepte lassen sich schließlich direkt für die Anwendungen im Bereich der
virtuellen Techniken nutzen.
Abbildung 3.3: ARVIDA Referenzarchitektur [ARV15]
ARVIDA 21
3.2.1 Architektursprache
Mithilfe des Representational State Transfer (REST) werden die Eigenschaften von
Architekturkandidaten via Hypertext Transfer Protocol (HTTP) beschrieben. HTTP-
Zeichenfolgen, sogenannte Uniform Resource Identifier (URI), besitzen festgelegte
Befehle, die die Zustände der Ressourcen beschreiben und zur deren Identifikation
beitragen. So kann beispielsweise mithilfe des Befehls „HTTP GET“ eine Ressource
von einem Server angefordert, durch „HTTP PUT“ eine Ressource angelegt oder ge-
ändert oder eine Ressource mit „HTTP DELETE“ gelöscht werden. [Vgl. WIK15]
Wichtig dabei ist, dass der REST-Dienst adressierbar ist, also eine eindeutige Adres-
se (URL oder URI) besitzt. Dieses Prinzip liegt auch dem Linked Data-Standard zu-
grunde, der offene und vernetzte Datenstrukturen durch diese einheitlichen Adress-
formate ermöglicht. Zudem müssen die dargestellten Dienste durch unterschiedliche
Repräsentationen in Form verschiedener Sprachen oder Formate zu beschreiben
sein. Auch muss das Protokoll eines Dienstes zustandslos sein, was bedeutet, dass
es in sich geschlossen ist und alle Anwendungsinformationen durch den Client vor-
gehalten werden. Weiterhin muss eine Ressource mit RESTful Operationen aufwei-
sen, die durch HTTP definiert sind, um das Ausführen oder Verändern eines Diens-
tes zu ermöglichen. Diese vier Prinzipien sind zwingend für eine Architektur in REST
einzuhalten. [Vgl. WIK15]
Die Architektur in RESTful besteht aus einem Satz von Beschränkungen, die Cons-
traints genannt werden und spezifische Eigenschaften der Ressource übertragen.
Somit kann eine lose Kopplung von Clients und Diensten erreicht werden. Weitere
Ziele des Architekturformates sind einheitliche Interfaces, die Austauschbarkeit von
Komponenten ohne Vermittlungsinstanz sowie die Bildung universeller Schnittstellen
zwischen den Systemen. [Vgl. RES15]
Das universelle Datenformat in ARVIDA wird dabei dem W3C-Standard entspre-
chend durch RDF ermöglicht, das logische Aussagen über Ressourcen formuliert
sowie eine Modellierung in Klassen, Attributen und Instanzen erlaubt. Somit können
sowohl Konzepte modelliert als auch Zustände repräsentiert werden, die durch Ma-
schinen interpretierbar und lesbar sind. Die einzelnen Aussagen sind mithilfe von
Subjekt, Prädikat und Objekt beschrieben. Sind diese drei Bestandteile Ressourcen,
dann ist die Aussage ein Triplet, also ein mathematisch gerichteter Graph.
ARVIDA 22
Den Aufbau eines solchen Graphen, der durch drei Subjekte beschrieben ist, ver-
deutlicht die folgende Abbildung. Die Kommunikationsebenen und -richtungen sind
eindeutig festgelegt. In der dargestellten Art und Weise in Abbildung 3.4 entspricht
der RDF-Graph dem ARVIDA-konformen Vokabular.
Abbildung 3.4: ARVIDA RDF-Vokabular [WIK15]
Um Ontologien5 darstellen zu können, bedient sich die Architektur ebenfalls der Web
Ontology Language (OWL). Mithilfe dieser Sprache innerhalb des RDF können Ab-
hängigkeiten erstellt, publiziert sowie verteilt werden. Die dadurch beschriebenen
Termini der Ressourcen können durch die Software verarbeitet werden. [Vgl.
OWL15]
Die Abfrage der Ressourcen erfolgt mittels Polling6. Auf eine Anfrage nach dem
Request/Response-Prinzip wird immer eine Antwort geschickt. Sollten sich die Daten
der Ressource ständig ändern, empfängt der Server demnach bei jedem GET einen
veränderten Datensatz. Mithilfe dieser weltweit anerkannten Grundlagen für die
ARVIDA-Referenzarchitektur lässt sich eine Modularität und Vernetzung der
Systeme darstellen. [Vgl. WIK15]
5 System von Informationen mit logischen Relationen in der Informatik [DUD15]
6 Methode der Statusermittlung eines Gerätes oder der Wertänderung in der Informatik [POL15]
ARVIDA 23
3.2.2 Datenmodelle
Die Datenmodelle, die in ARVIDA verwendet werden, sind durch die am Projekt be-
teiligten Architekten definiert und festgelegt. Bei der Entwicklung der Anwendung
wird auf eine objektorientierte Struktur in Form von Szenegraphen zurückgegriffen,
die durch bestimmte Datenformate charakterisiert sind. Die folgende Abbildung zeigt
die Struktur eines ARVIDA-Szenegraphen. Mithilfe dessen kann die logische sowie
räumliche Anordnung einer dreidimensionalen Szene beschrieben werden. [Vgl.
BER12]
Abbildung 3.5: Szenegraphen [BER12]
Die ARVIDA-Szenegraphen sind aus heterogenen Knoten und Kantenausprägungen
aufgebaut. Letztere beinhalten schwergewichtige homogene Attribute wie Bilder oder
Simulationsdaten. Diese sind mittels definierten dreidimensionaler Text-, Grafik- so-
wie Raumdaten beschrieben. Als Ressource für die Graphen werden URIs oder Con-
tent-Types verwendet, um die Daten zu klassifizieren. So kann z.B. ein Kinect Sen-
sor die benötigten Daten im RDF-Format erhalten. Um externe Daten anzubinden
wird HDR (Homogene Daten Ressourcen) genutzt. Mit dieser Sprache können ein-
zelne Datenausprägungen von Attributen sowie Inhalte ohne Beziehungen wie bei-
spielsweise Track-Daten im Szenegraphen beschrieben werden. Sollen komplette
Teilgraphen oder standardisierte Graph-Container definiert werden, sind im Graphen
die SDR (Strukturierte Daten Ressourcen) zu verwenden. Hiermit kann auch eine on-
ARVIDA 24
the-fly-Datenaufbereitung erfolgen. Durch die definierte Datenstruktur innerhalb der
Szenegraphen kann auch eine dreidimensionale Szene ARVIDA-konform beschrie-
ben und von verschiedenen Ausgabegeräten dargestellt werden.
3.2.3 Entwicklungsziele
Die Ziele des Verbundprojektes ARVIDA sind vielfältig und sollen vorranging der
Vereinfachung von Systemen der Industrie 4.0 im Bereich virtueller Dienste und An-
wendungen dienen. Die entwickelte Referenzarchitektur soll schlussendlich grundle-
gend kompatibel zu einer Industrie 4.0-Architektur sein. Dies soll durch festgelegte
Architektur-Bestandteile erreicht werden. Insgesamt soll durch ARVIDA eine dienst-
orientierte Struktur eingeführt werden, die klar beschrieben ist. Zudem ist der Nutzen
des REST-Prinzips zur Beschreibung von Diensten als auch Ressourcen aufzuzei-
gen. Der Vorteil durch den Einsatz semantischer Web-Technologien wie u.a. RDF,
OWL und Linked Open Data für verteilte VT-Anwendungen (virtuelle Techniken) soll
bewiesen werden. Auch sollen offene, semantische Ressourcenbeschreibungen mit
RDF und OWL die Modularität von verschiedenen Systemen innerhalb der Refe-
renzarchitektur gewährleisten. Um die Anwendungsbereiche zu erweitern, ist VT-
spezifisches RDF-Vokabular für die VT-Anwendungsentwicklung bereitzustellen. Die
einfache Austauschbarkeit von Software- und Hardware-Komponenten soll auch
durch eine einfache Ressourcenerstellung, einheitliche Ressourcenbeschreibungen
sowie standardisiertes Ressourcenverhalten ermöglicht werden.
Zusammenfassend erhoffen sich die Beteiligten, durch das Projekt eine vereinfachte
Verbindung unterschiedlichster Systeme zu schaffen, die auch mit verschiedenen
Programmiersprachen aufrechterhalten bleiben kann. Dieses Ziel soll durch die Aus-
tauschbarkeit funktionaler Module ohne hohen Implementierungsaufwand ermöglicht
werden. Weiterhin basiert die Referenzarchitektur auf einem RDF-Vokabular, da
dessen Pflege einfacher ist, als das eines Application Programming Interface (API),
wodurch auch in Zukunft der Erweiterung des bestehenden Konzeptes keine Barrie-
ren entgegenstehen sollten.
ARVIDA 25
3.3 Die generischen Anwendungsszenarien
Die einzelnen generischen Anwendungsszenarien, die im Rahmen von ARVIDA be-
arbeitet werden, beschäftigen sich hauptsächlich mit dem Motion Capturing, dem
Soll-Ist-Vergleich von Bauteilen und Bauzuständen, der Werkerassistenz im industri-
ellen Umfeld sowie der Produktabsicherung und dem Produkterlebnis. Diese sollen
verdeutlichen, dass die Referenzarchitektur als die Basis für modulare, interoperable
Systeme nutzbar ist. [Vgl. ARV15]
Beim Szenario des Motion Capturing wird versucht, die Bewegungen von Menschen
im und am Fahrzeug zu erfassen, um so die Ergonomie des Fahrers als auch der
weiteren Insassen abzusichern. Dieses wird unter Mitwirkung von Daimler Trucks am
Beispiel einer LKW-Fahrerkabine versucht (s. Abb. 3.6). Sowohl der Außenbereich
um die Kabine als auch das Innere der Kabine sind mithilfe von Kameras und opti-
schen Tracking-Sensoren vermessen. Dem Fahrer selbst wird ebenfalls ein Schie-
nensystem angelegt, das mit optischen Sensoren versehen ist, um seine Position in
der Kabine und seine Bewegungen detailliert erfassen zu können.
Abbildung 3.6: Bewegungserfassung in der LKW-Fahrerkabine [WIK15]
ARVIDA 26
Mithilfe der ARVIDA-Referenzarchitektur soll es möglich werden, die Tools, die bis-
her zur Bewegungserfassung verwendet werden, zu einer generischen Lösung zu-
sammen zu führen. Die virtuelle Absicherung der Ergonomie im Fahrzeug soll somit
durch die Parametrisierung von einzelnen Bewegungsabläufen, der Erstellung einer
Bibliothek aus Teilsequenzen typischer Abläufe sowie des Zusammensetzens dieser
zu einer Ablaufszene bereits in der frühen Konzeptphase ermittelbar und bewertbar
sein. Weiterhin können diese Bausteine parallel bereits auf die Absicherung von
Montagekonzepten übertragen werden, wodurch auch die Ergonomie des Werkers
mithilfe der Datenbank ausgewertet und verbessert werden kann. [Vgl. ARV15]
Die Projektpartner Daimler Protics und ThyssenKrupp Marine Systems (TKMS) be-
schäftigen sich mit dem Szenario des Soll-Ist-Vergleichs. Hierbei wird in zwei Teilpa-
keten an integrierten Lösungen für die Baubarkeitsbewertung im Automobilbereich
sowie der Unterstützung von Tätigkeiten des operativen Personals mittels virtueller
Techniken geforscht. Es soll eine system- und quellenübergreifende Datenverarbei-
tung auf geometrischer Basis ermöglicht werden. In Abbildung 3.7 ist ein erster An-
satz dieser Lösung basierend auf der ARVIDA-Referenzarchitektur dargestellt. Mithil-
fe mehrerer statischer, dreidimensionaler Scans wurde das Messvolumen des Mo-
torblocks erfasst und mit den Planungsdaten verglichen, um eine frühe Aussage über
die Baubarkeitsbewertung treffen zu können. Dies kann auch mit verschiedensten
Trackingsystemen der Projektpartner erfolgen, was gemäß des Projektziels einen
hohen Grad an Modularität darstellt. [Vgl. ARV15]
Abbildung 3.7: Soll-Ist-Vergleich der CAD-Daten eines Motors [ARV15]
ARVIDA 27
Ein weiteres Anwendungsszenario, das von Volkswagen und TKMS entwickelt wird,
ist das Thema der Werkerassistenz. Durch Mixed Reality Engineering, mobile projek-
tionsbasierte AR-Systeme als auch ein Instandhaltungs- und Trainingsszenario sol-
len die Möglichkeiten der Unterstützung der Werker durch eine mobile, generische
Anwendung vorangetrieben werden. Dabei soll die Austauschbarkeit von Tracking-
sowie Rendering-Systemen, mobiler Hardware und Möglichkeiten der Datenanbin-
dung bewiesen werden. Hierzu werden mit Datenbrillen und Projektoren (s. Abb. 3.8)
AR-Inhalte angezeigt, die den Prozess des Werkers am Band oder in der Service-
Werkstatt unterstützen, ihn dabei aber nicht behindern. Gerade die gleichzeitige An-
wendung von Projektor und Head-Mounted Display (HMD) steht dabei im Fokus, da
diese Systeme vielfältige Darstellungsmöglichkeiten bieten. [Vgl. ARV15, WIK15]
Abbildung 3.8: Werkerunterstützung durch PbAR am Beispiel des XL1 [ARV15]
Das vierte ARVIDA-Anwendungsszenario stellt das Gebiet der Produktabsicherung
sowie des Produkterlebnisses dar. Daimler Protics und Volkswagen entwickeln im
Rahmen dessen Strategien zum Erleben eines Fahrzeugs in einer dreidimensionalen
Umgebung sowie des Ergänzens von realen Modellen mit virtuellen Details, z.B. zum
Vergleich verschiedener Designstände von Oberflächen und Multimedia-Screens an
einem Armaturenbrett (s. Abb. 3.9). Somit können sowohl für den Fahrer als auch für
ARVIDA 28
den Entwickler bereits in frühen Konstruktionsphasen Fahrzeugentwürfe oder die
Interaktion eines Fahrzeugs mit der Umgebung erlebbar gemacht werden. Als Basis
für komplexe dreidimensionale Umgebungsdaten und die ästhetische sowie sicher-
heitstechnische Absicherung von Produktkomponenten dienen unabhängige Syste-
me und Datenquellen, die mit der ARVIDA-Referenzarchitektur an die virtuelle Welt
angebunden werden und untereinander austauschbar sind, sodass eine Übertragung
von Informationen jederzeit problemlos möglich ist. [Vgl. ARV15, WIK15]
Abbildung 3.9: Interaktive Sitzkiste [ARV15]
Nach dem Projektabschluss Ende 2016 soll der Transfer der ARVIDA-
Referenzarchitektur in weitere interessierte Unternehmen erfolgen, damit auch ande-
re große Wirtschaftsbereiche, die im Bereich der virtuellen Techniken arbeiten, die
Möglichkeit haben, ihre Systeme ohne großen Implementierungsaufwand und hohe
Investitionskosten untereinander auszutauschen und beliebig zu koppeln. Dadurch
soll sich die entwickelte Referenzarchitektur ständig erweitern und die Modularität um
neue Systeme ergänzt werden, sodass die Unternehmen auch untereinander auf
dieser Basis Wissen sowie Daten austauschen und im Bereich der virtuellen Techni-
ken ihre Anwendungen und Fähigkeiten ausbauen können. [Vgl. ARV15]
Vergleich der Modelle 29
4 Vergleich der Modelle
Die in den vorherigen Kapiteln beschriebenen Referenzarchitektur-Modelle RAMI4.0
und ARVIDA werden nun gegenübergestellt und verglichen. Dazu werden zunächst
die Bereiche der Modelle sowie die darin betrachteten Ebenen abgewogen. An-
schließend werden besonders die Aspekte der Modularität, der Vokabular-Gestaltung
sowie der Vergleich der Umsetzungsstrategie und möglicher Anwendungsbeispiele in
einzelnen Unternehmen betrachtet.
Im Rahmen des Modells RAMI 4.0 werden eine Semantik sowie die Syntax für einen
einheitlichen Datenaustausch entwickelt, die auf europäische Normen übertragen
werden sollen. Dazu werden verschiedene Ebenen eines Unternehmens herangezo-
gen, sodass Hierarchien, Lebenszyklen, Wertschöpfungsprozesse und Layer der Un-
ternehmenssoftware abgebildet und mit Regeln für Datenstrukturen und Kommunika-
tionsprotokolle belegt werden können. Dies geschieht vorrangig auf der Ebene von
Industrie 4.0-Komponenten, deren Kommunikationsfähigkeit durch IT-Systeme oder
Verwaltungsschalen genau definiert wird. Die dafür verwendete Architektursprache
ist nicht konkret beschrieben. Dahingegen ist dieses Vokabular in ARVIDA bereits
genau festgelegt und in Form von Programmierbeispielen und Kommunikationsbe-
fehlen aufgezeichnet. Zwar beschränkt sich dieses Referenzarchitektur-Modell vor-
rangig auf die Umgebung virtueller Dienste und Anwendungen, konkretisiert jedoch
die Vorstellung eines allgemeinen, einheitlichen Vokabulars, mithilfe dessen Kompo-
nenten beliebig ausgetauscht werden und trotzdem problemlos kommunizieren kön-
nen. Die entwickelte Referenzarchitektur soll schlussendlich grundlegend kompatibel
zu einer Industrie 4.0-Architektur sein, sodass sich auch weitere Unternehmensbe-
reiche damit erschließen lassen. Dabei basiert ARVIDA auf Diensten, die Teile von
Unternehmenssoftware darstellen und mithilfe des RESTful-Vokabulars in Architek-
turkonzepte von Industrie 4.0-Umgebungen erweitert werden können. Obwohl sich
diese Dienste spezifisch auf virtuelle Techniken beziehen (Tracking, generisches
Menschmodell), lässt sich dieser Ansatz jedoch auf sämtliche Unternehmensberei-
che übertragen, die mit diesen Technologien arbeiten, um z.B. virtuelle Prototypen
zur frühzeitigen Produktabsicherung zu erstellen. Hierfür bietet ARVIDA bereits eine
weit entwickelte Architektursprache an, die es durch REST ermöglicht, verschiedens-
te Systeme aufgrund dieses einheitlichen Vokabulars miteinander kommunizieren zu
lassen. Dies kann und soll schließlich auch unternehmensübergreifend erfolgen, um
Vergleich der Modelle 30
gegenseitig Expertise im Bereich virtueller Techniken auszutauschen. Diesen Ansatz
erweitert RAMI 4.0 um generelle Kommunikationsstrukturen auf horizontaler Ebene,
sodass auch mithilfe dieses Modells zwischen einzelnen Unternehmen Daten ausge-
tauscht werden können. Allerdings bietet diese Referenzarchitektur keinen konkreten
Lösungsansatz in Form eines Datenformates. Somit ist die Architektur in ARVIDA
zwar spezifischer, aber auch detaillierter und anschaulicher beschrieben, weshalb sie
einfacher und unkomplizierter in den Unternehmen umgesetzt werden kann. Dieses
wird bereits durch die generischen Anwendungsszenarien des Projektes bewiesen.
Dahingegen zielt RAMI 4.0 auf eine weniger detailgetreue, allgemein gültige und
abstrahierte Modellstruktur, in die sich sämtliche Unternehmen und Komponenten
eingliedern lassen. Deshalb werden Teile des Modells auch in spezifische Normen
überführt und dadurch erweitert. Somit wird das Ziel des Projektes erreicht, die euro-
päische Standardisierung und Normung für Unternehmensstrukturen von Industrie
4.0-Umgebungen voran zu treiben. Einige Wirtschaftskonzerne wie z.B. Siemens
passen ihre bestehenden Systeme bereits an die Anforderungen von RAMI 4.0 an,
um u.a. auf Feldbus- und Industrial Ethernet7-Ebene einen übergreifenden und stan-
dardisierten Datenaustausch zu ermöglichen. [Vgl. SCH15]
Im Rahmen von ARVIDA werden bereits konkrete Unternehmen eingebunden, die in
generischen Anwendungsszenarien konkrete Fragestellungen bearbeiten und Lö-
sungsansätze entwickeln, die direkt in andere Wirtschaftsbereiche übertragbar sind.
Somit wird die schrittweise Implementierung und Integration der in diesem Projekt
erarbeiteten Referenzarchitektur in die Wirtschaft ermöglicht. Zudem können Inhalte
und vertiefte Fragestellungen von ARVIDA in einem Folgeprojekt ausgebaut und de-
taillierter betrachtet werden.
Alles in allem können die beiden Referenzarchitekturmodelle problemlos nebenei-
nander existieren und gegebenenfalls ergänzend verwendet werden, da RAMI 4.0
eine allgemeine Struktur und Normung für Industrie 4.0-Umgebungen erstrebt, wo-
hingegen ARVIDA ein konkretes Vokabular und spezifische Datenstrukturen für den
Bereich virtueller Techniken entwickelt. Somit können Unternehmen allgemeine
Kommunikationsstrukturen aus RAMI 4.0 verwenden und sich gleichzeitig für virtuelle
Dienste und Anwendungen der ARVIDA-Architektursprache bedienen.
7 Schaffen eines industriellen Standards für die Technologie zur Spezifikation von Software und
Hardware kabelgebundener Datennetze [Vgl. IND15]
Zusammenfassung und Ausblick 31
5 Zusammenfassung und Ausblick
Mit RAMI 4.0 und ARVIDA werden in zwei Verbundprojekten Ansätze für Datenstruk-
turen und Referenzarchitekturmodelle entwickelt, die Unternehmen die Kommunika-
tion und Anbindung von Systemen in Industrie 4.0-Umgebungen und den übergrei-
fenden Informationsaustausch ermöglichen sollen. Somit können die Anforderungen
der vierten Industrialisierung konsequent in den Wirtschaftsbereichen umgesetzt und
durchgängig implementiert werden, um auch den Umgang mit großen Datenmengen
und den horizontalen sowie vertikalen übergreifenden Austausch von Eigenschaften
oder Systemen zu vereinfachen.
Die Umsetzung der Referenzarchitekturmodelle von RAMI 4.0 und ARVIDA geht da-
bei über die jeweilige Projektlaufzeit hinaus. Teile des Modells RAMI 4.0 werden im
Januar 2016 in die DIN SPEC 91345 überführt und dienen somit als Basis für die
Normierung. Weitere Veröffentlichungen spezifischer Normen mit entwickelten Stan-
dardisierungsansätzen aus RAMI 4.0 sollen in unterjährigen Zeitabständen folgen.
[Vgl. MOS15]
ARIVDA-Lösungsansätze sollen nach Projektabschluss weitere Interessenten aus
Wirtschaft und Forschung zur Verfügung gestellt werden, um die Anwendung der
Referenzarchitektur zu fördern und um die Anbindung und Austauschbarkeit weiterer
Systeme und Komponenten zu erweitern. Somit ist die Weiterentwicklung der Refe-
renzarchitektur für Industrie 4.0 und die Anbindung dieser an weitere Wirtschaftsbe-
reiche einer der nächsten Schritte. Weiterhin werden auch verschiedenste Systeme
an die Anforderungen der Referenzarchitektur angepasst und mit dem dazugehöri-
gen Vokabular belegt, so dass sie modulare Komponenten der Industrie 4.0-
Umgebung darstellen können. Dies erfolgt sowohl aufgrund von neuen Normen für
RAMI 4.0 als auch auf freiwilliger Basis für ARVIDA. Durch die Erweiterung in Folge-
projekten können weitere Fragestellungen der Industrie 4.0 bearbeitet und von Wirt-
schafts- und Forschungsvertretern mithilfe von Lösungsansätzen erschlossen wer-
den.
Dadurch können die Unternehmen den Anforderungen an neue Datenstrukturen und
Kommunikationsprinzipien sowie dem übergreifenden Datenmanagement zuneh-
mend gerecht werden und sich auch strukturell in ihren Prozessen an die vierte In-
dustrialisierung anpassen, um dadurch z.B. an Flexibilität und Produktivität zu ge-
winnen.
Quellenverzeichnis 32
6 Quellenverzeichnis
[ADO15] Dr.-Ing Peter Adolphs, Prof. Dr. Ulrich Epple et al: „Statusreport – Refe-
renzarchitekturmodell Industrie 4.0 (RAMI 4.0)“; VDI, VDE, ZVEI; Stand
April 2015; Zugriff am 16.12.2015 unter
http://www.zvei.org/Downloads/Automation/Statusreport-
Referenzmodelle-2015-v10.pdf
[ARV15] ARVIDA Projekthomepage, Zugriff am 21.12.2015 unter www.arvida.de
[BER12] Johannes Behr: „Datenmodelle – Verteilte Graphen für VR/AR Anwen-
dungen“, ARVIDA-Präsentation, Fraunhofer IGD, Stand 28.11.2012
[BIE12] Dietrich Biester: Siemens entwickelt europisches Architekturmodell für
Smart Grids“, Siemens Infrastructure & Cities/Division Smart Grid,
Pressemitteilung, Nürnberg, 11.05.2012; Zugriff am 29.12.2105 unter:
http://www.siemens.com/press/de/pressemitteilungen/?press=/de/press
emitteilungen/2012/infrastructure-cities/smart-
grid/icsg201205018.htm&content[]=ICSG&content[]=EM&content[]=EM
SG
[BIG15] Wikipedia: „Big Data“; Zugriff am 28.12.2015 unter
https://de.wikipedia.org/wiki/Big_Data
[DUD15] Online-Duden, Zugriff am 22.12.2015 unter http://www.duden.de
[ENT15] Wikipedia: „Entität (Informatik)“, Zugriff am 21.12.2015 unter
https://de.wikipedia.org/wiki/Entität_(Informatik)
[HAN15] Martin Hankel: „Industrie 4.0: Das Referenzarchitekturmodell Industrie
4.0 (RAMI 4.0)“; ZVEI; Version 1.0 zur Hannover Messe 2015; Stand
April 2015; Zugriff am 16.12.2015 unter
http://www.zvei.org/Downloads/Automation/ZVEI-Faktenblatt-
Industrie4_0-RAMI-4_0.pdf
Quellenverzeichnis 33
[HOF15] Dr. Michael Hoffmeister: „Industrie 4.0 – Die Industrie 4.0-Komponente“;
ZVEI; Version 1.0 zur Hannover Messe 2015; Stand April 2015; Zugriff
am 16.12.2015 unter
http://www.zvei.org/Downloads/Automation/Industrie%204.0_Kompone
nte_Download.pdf
[IND15] Wikipedia: „Industrial Ethernet“, Zugriff am 29.12.2015 unter
https://de.wikipedia.org/wiki/Industrial_Ethernet
[LIN15] “Linked Data – Connect Distributed Data across the Web“; Zugriff am
21.12.2015 unter http://linkeddata.org/
[MOS15] Christian Mosch: „RAMI 4.0 wird in DIN SPEC 91345 überführt”;
id795662, VDMA-Artikel, Zugriff am 29.12.2015 unter
http://industrie40.vdma.org/article/-/articleview/7956662
[OWL15] W3C: „Web Ontology Language (OWL)“; Zugriff am 20.12.2015 unter
http://www.w3.org/2001/sw/wiki/OWL
[PLA15] Plattform Industrie 4.0, diverse Autoren: „Umsetzungsstrategie Industrie
4.0 – Ergebnisbericht der Plattform Industrie 4.0“; BITKOM e.V., VDMA
e.V., ZVEI e.V.; Stand April 2015; Zugriff am 18.12.2015 unter
http://www.zvei.org/Downloads/Automation/Umsetzungsstrategie_I40_E
rgebnisbericht_2015-04.pdf
[POL15] Wikipedia: „Polling“, Zugriff am 22.12.2015 unter:
https://de.wikipedia.org/wiki/Polling_(Informatik)
[RAM15] ZVEI: Das Referenzarchitekturmodell RAMI 4.0 und die Industrie 4.0-
Komponente; Zugriff am 16.12.2015 unter
http://www.zvei.org/Themen/Industrie40/Seiten/Das-Referenzarchitektur
modell-RAMI-40-und-die-Industrie-40-Komponente.aspx
[RDF15] W3C: „Resource Description Framework (RDF)“; Zugriff am 20.12.2015
unter http://www.w3.org/RDF/
Quellenverzeichnis 34
[RES15] Wikipedia: „Representational state transfer (REST)“; Zugriff am
20.12.2015 unter
https://en.wikipedia.org/wiki/Representational_state_transfer
[SCH15] Karsten Schneider: „Intelligentes Zusammenspiel“; Profibus & Profinet
Journal, Ausgabe 3/2015, S. 4-5; Zugriff am 29.12.2015 unter
http://www.profibus.com/fileadmin/media/eMag/PNOJournal_32015/ind
ex.html#/4/
[SYS15] Wikipedia: „Systems Engineering“; Zugriff am 28.12.2015 unter
https://de.wikipedia.org/wiki/Systems_Engineering
[WIK15] ARVIDA WIKI: Grundlagen, Konzepte, Modellierung und Implementie-
rung; Zugriff am 22.12.2015 unter www.wiki.arvida.de