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