SlideShare ist ein Scribd-Unternehmen logo
1 von 32
Downloaden Sie, um offline zu lesen
Statusreport
Referenzarchitekturmodell
Industrie 4.0 (RAMI4.0)
April 2015
Titelbild: VDI-Haus Düsseldorf
Vorwort
Der Einzug von Technologien aus der Welt des Inter-
nets in die Fertigungsautomation ist nicht mehr auf-
zuhalten. Vielfach mit dem Begriff „4. Industrielle
Revolution“ oder „Industrie 4.0“ bezeichnet, hat sich
in den Medien ein regelrechter Hype um das Thema
ergeben. Aufgabe der Plattform Industrie 4.0, in der
sich Vertreter von Automatisierungsindustrie, Ma-
schinenbau und der ITK-Branche zusammengetan
haben, wird seit einigen Monaten intensiv an der
Konkretisierung der Ideen gearbeitet. Ein wesentli-
ches Element war dabei die Entwicklung einer Refe-
renzarchitektur durch die Arbeitsgruppe 2 (AG2) der
Plattform Industrie 4.0. Um eine möglichst breite
Basis für diese Überlegungen zu legen, haben die
AG2, der Fachausschuss 7.21 „Industrie 4.0“ der
VDI/VDE-Gesellschaft Mess- und Automatisierungs-
technik (GMA) und die Arbeitsgruppe SG2 des ZVEI
eng zusammengearbeitet und ein gemeinsames Papier
erstellt, das hier in Auszügen veröffentlicht wird. Die
dargestellten Ergebnisse basieren auf einem breiten
Konsens in den diversen Industriebranchen, aber auch
in der Wissenschaft. Insofern darf davon ausgegangen
werden, dass darauf für die nächsten Schritte aufge-
baut werden kann.
Düsseldorf, im April 2015
Dr.-Ing. Peter Adolphs
Sprecher der AG2 in der Plattform Industrie 4.0
Mitglied des Vorstands der VDI/VDE-Gesellschaft
Mess- und Automatisierungstechnik (GMA)
Mitglied der SG2 im ZVEI
Prof. Dr. Ulrich Epple
Leiter des Fachausschusses 7.21 „Industrie 4.0“ der
VDI/VDE-Gesellschaft Mess- und Automatisierungs-
technik (GMA)
Vorsitzender des Steuerkreises Industrie 4.0 der DKE
Mitglied der SG2 im ZVEI
www.vdi.de
www.vdi.de
Referenzarchitekturmodell Industrie 4.0 3
Inhalt
Vorwort 1
1 Zusammenfassung 4
2 Referenzarchitektur 5
2.1 Konsens der Verbände 5
2.2 Einleitung 5
2.3 Referenzarchitekturmodell Industrie 4.0 (RAMI4.0) 6
2.4 Referenzmodell für die I4.0-Komponente 11
2.5 Glossar Industrie 4.0 25
Autoren 26
Schrifttum 26
www.vdi.de
4 Referenzarchitekturmodell Industrie 4.0
1 Zusammenfassung
Physische und virtuelle Welt wachsen zunehmend
zusammen. Immer mehr physische Objekte verfügen
über intelligente Sensor- und Aktortechnologie und
werden durch die evolutionäre Entwicklung des Inter-
nets der Dinge vernetzt. Die Verfügbarkeit aller rele-
vanten Informationen in Echtzeit mittels Vernetzung
aller an der Wertschöpfung beteiligten Instanzen
sowie die Fähigkeit, aus den Daten den zu jedem
Zeitpunkt optimalen Wertschöpfungsfluss abzuleiten,
löst eine neue weitere industrielle Revolution (als
Industrie 4.0 bezeichnet) in den Geschäftsprozessen
aus und ermöglicht neue Geschäftsmodelle. Dabei
steht die Optimierung der folgenden industriellen
Kernprozesse im Fokus: Forschung & Entwicklung,
Produktion, Logistik und Service.
Um die Zukunftsfähigkeit des Standorts Deutschland
und seiner Industrie abzusichern, wurden durch die
Plattform Industrie 4.0 in Zusammenarbeit der Ver-
bände BITKOM, VDMA, ZVEI und den Unterneh-
men der Deutschen Industrie die Umsetzungsstrategie
Industrie 4.0 erarbeitet. Das Kapitel 6 der Umset-
zungsstrategie Industrie 4.0 wurde von vornherein so
konzipiert, dass es extrahiert und als GMA-Statusre-
port veröffentlicht werden kann. Das Ergebnis liegt
Ihnen hier vor.
In diesem VDI-Statusreport wird ein Referenzarchi-
tekturmodell für semantische Technologien und deren
Nutzen für die Automatisierung und ihr zugeordneten
relevanten Technologien vorgestellt (RAMI4.0). Da-
rin werden auch der Aufbau und die Arbeitsweise von
sogenannten Industrie-4.0-Komponenten (im Folgen-
den I4.0-Komponenten genannt) beschrieben. Wo es
sinnvoll ist, setzen Teile des Referenzarchitekturmo-
dells und der I4.0-Komponenten auf bestehende und
relevante Normen auf, um schneller handlungsfähig
zu sein. Wo notwendig, wurden in der Umsetzungs-
strategie zusätzliche identifizierte Standardisierungs-
bedarfe identifiziert und beschrieben.
Aufgrund der zunehmenden Vernetzung und Steuer-
barkeit von physischen Objekten und der gleichzeitig
steigenden Bedrohungslage durch Hacker, Geheim-
dienste, Spionage usw. sind besondere Sicherheitsan-
forderungen erforderlich. Diese werden im Kapitel 7
der Umsetzungsstrategie Industrie 4.0 umrissen.
Der Statusreport wendet sich an Leser aus der Deut-
schen Industrie, den relevanten technologieorientier-
ten Branchen, der Forschung und der Politik. Im Be-
sonderen sind Führungskräfte, Fachkräfte und Berater
angesprochen sowie alle Personen, die an einem dem
Zukunftsbild der Industrie 4.0 in Deutschland interes-
siert sind oder dieses mitgestalten wollen.
www.vdi.de
Referenzarchitekturmodell Industrie 4.0 5
2 Referenzarchitektur
2.1 Konsens der Verbände
Die hier beschriebene Referenzarchitektur für Indus-
trie 4.0 ist das Ergebnis der Kooperation mehrerer
Institutionen. Insbesondere haben Experten der Fach-
ausschüsse 7.21 „Industrie 4.0“ und 7.20 „Cyber-
Physical Systems“ der VDI/VDE-Gesellschaft Mess-
und Automatisierungstechnik (GMA) zu den Ergeb-
nissen beigetragen. Vorarbeiten sind die bislang ver-
öffentlichten fünf Statusreports, die ebenso wie dieser
und der neue Report zu „IT-Security auf dem Weg zur
Industrie 4.0“ unter www.vdi.de/industrie40 kosten-
frei zum Download zur Verfügung stehen. Der vorlie-
gende Statusreport ist in Kooperation mit dem Spie-
gelgremium SG2 des ZVEI entstanden, das inhaltlich
das hier beschriebene Modell vorangebracht hat.
Auch die DKE (Deutsche Kommission Elektrotech-
nik) wurde in alle Arbeiten einbezogen.
Damit fiel der AG2 der Plattform Industrie 4.0 primär
die Rolle der Koordination der Aktivitäten in den
zahlreichen Untergremien und die Sicherstellung
einer konsistenten Linie zu. So hat die Plattform ihrer
zugedachten Aufgabe, ein konzertiertes Vorgehen
unterschiedlichster Organisationen und Verbände
sicherzustellen, entsprochen. Die nachfolgend vorge-
stellten, breit getragenen Ergebnisse sind damit ein
wichtiger Schritt zur Wahrung der Wettbewerbsfähig-
keit der deutschen Industrie.
2.2 Einleitung
Einer der grundlegenden Gedanken zur Referenzar-
chitektur von Industrie 4.0 ist das Zusammenführen
unterschiedlichster Aspekte in einem gemeinsamen
Modell. Die vertikale Integration innerhalb der Fabrik
beschreibt die Vernetzung von Produktionsmitteln
z. B. von Automatisierungsgeräten oder Diensten
untereinander. Als neuer Aspekt kommt bei Indus-
trie 4.0 die Einbeziehung des Produkts bzw. Werk-
stücks hinzu. Das zugehörige Modell muss dies
reflektieren. Doch Industrie 4.0 geht noch deutlich
weiter. Mit durchgängigem Engineering über die
ganze Wertschöpfungskette ist gemeint, dass techni-
sche, administrative und kommerzielle Daten, die
rund um ein Produktionsmittel oder auch das Werk-
stück entstehen, über die komplette Wertschöpfungs-
kette konsistent gehalten werden und jederzeit über
das Netzwerk zugreifbar sind. Ein dritter Aspekt bei
Industrie 4.0 ist die horizontale Integration über Wert-
schöpfungsnetzwerke, die über den einzelnen Fab-
rikstandort hinausgeht und die dynamische Bildung
von Wertschöpfungsnetzwerken ermöglicht.
Die Aufgabe, diese Aspekte in einem Modell darzu-
stellen, war zu lösen. Schließlich sollen Regelkreise
mit Abtastungen im Millisekundentakt die dynami-
sche Kooperation mehrerer Fabriken untereinander
innerhalb eines gemeinsamen Wertschöpfungsnetz-
werks mit zusätzlichen kommerziellen Fragestellun-
gen in einem Modell darstellbar sein. Hier galt es, die
Sichtweisen aus den unterschiedlichen Anwendungs-
domänen zu verstehen, das Wesentliche zu erfassen
und in einem gemeinsamen Modell zu vereinen.
Bevor die eigentlichen Arbeiten zum Referenzarchi-
tekturmodell RAMI4.0 begonnen werden konnten,
war es daher notwendig, einen Überblick über vor-
handene Ansätze und Methoden zu gewinnen. Schnell
wurde klar, dass es bereits eine Reihe existierender
und nutzbarer Ansätze gibt, die allerdings in der Re-
gel nur Teilaspekte der oben beschriebenen ganzheit-
lichen Sicht auf Industrie 4.0 adressieren. Im Einzel-
nen wurden folgende Ansätze näher betrachtet:
 Ansatz für die Realisierung eines
Communication Layers
‒ OPC UA: Basis IEC 62541
 Ansatz für die Realisierung des
Information Layers
‒ IEC Common Data Dictionary
(IEC 61360 Series/ISO13584-42)
‒ Merkmale, Klassifikation und Werkzeuge nach
eCl@ss
‒ Electronic Device Description (EDD)
‒ Field Device Tool (FDT)
 Ansatz für die Realisierung von
Functional und Information Layer
‒ Field Device Integration (FDI) als Integrati-
onstechnologie
 Ansatz für das durchgängige Engineering
‒ AutomationML
‒ ProSTEP iViP
‒ eCl@ss (Merkmale)
Im ersten Schritt ging es dabei um die grundsätzliche
Prüfung, ob diese Ansätze zum im Kapitel 2.3 vorge-
stellten Referenzarchitekturmodell passen. Dies wird
grundsätzlich bejaht, allerdings bedürfen die betrach-
teten Konzepte und Methoden noch detaillierteren
Betrachtungen.
www.vdi.de
6 Referenzarchitekturmodell Industrie 4.0
2.3 Referenzarchitekturmodell
Industrie 4.0 (RAMI4.0)
In der Diskussion über Industrie 4.0 kommen ganz
unterschiedliche Interessen zusammen. Branchen von
Prozess- bis Fabrikautomation mit unterschiedlichsten
Standards, die Technologien der Informations- und
Kommunikationstechnik und die Automatisierungs-
technik, die Verbände Bitkom, VDMA, ZVEI und
VDI sowie die Normungsorganisationen IEC und ISO
mit ihren nationalen Spiegelgremien DKE und DIN.
Zum Zweck eines gemeinsamen Verständnisses, wel-
che Standards, Use Cases, Normen, usw. für Indus-
trie 4.0 notwendig sind, entstand die Notwendigkeit,
ein einheitliches Architekturmodell als Referenz zu
entwickeln, anhand dessen Zusammenhänge und
Details diskutiert werden können.
Das Ergebnis ist das Referenzarchitekturmodell In-
dustrie 4.0 (RAMI4.0), siehe Bild 1.
Es beinhaltet die wesentlichen Aspekte aus Industrie 4.0.
Es ergänzt die Hierarchiestufen aus IEC 62264 am
unteren Ende um die Stufe des Produkts bzw. Werk-
stücks („Product“) und am oberen Ende über die ein-
zelne Fabrik hinaus um die „Connected World“. Die
waagrechte Achse dient der Darstellung des Lebens-
zyklus von Anlagen bzw. Produkten, wobei auch der
Aspekt der Unterscheidung zwischen Typ und Instanz
abgebildet wird. Über die sechs Layer wird schluss-
endlich die IT-Repräsentanz einer I4.0-Komponente
strukturiert beschrieben.
Somit sind die besonderen Charakteristika des Refe-
renzarchitekturmodells die Kombination von Lebens-
zyklus und Wertschöpfungskette mit einem hierar-
chisch strukturierten Ansatz für die Definition von
I4.0-Komponenten. Damit ist ein Höchstmaß an Fle-
xibilität zur Beschreibung einer I4.0-Umgebung ge-
geben. Der Ansatz erlaubt auch die sinnvolle Kapse-
lung von Funktionalitäten.
Somit sind die Voraussetzungen geschaffen mittels
des Referenzarchitekturmodells hoch flexible Kon-
zepte zu beschreiben und zu realisieren. Dabei erlaubt
das Modell die schrittweise Migration aus der heuti-
gen in die I4.0-Welt und die Definition von Anwen-
dungsdomänen mit speziellen Vorgaben und Anforde-
rungen.
Das Referenzarchitekturmodell RAMI4.0 wird als
DIN SPEC 91345 der Standardisierung zugeführt.
2.3.1 Anforderungen und Ziele
Ziele
Industrie 4.0 ist eine Spezialisierung des „Internet of
Things and Services“. Es sind ca. 15 Branchen in die
Überlegungen einzubeziehen. Mit dem Referenzarchi-
tekturmodell können Aufgaben und Abläufe in über-
schaubare Teile zerlegt werden. Es soll einen Sach-
verhalt so anschaulich machen, dass eine zielgerichte-
te Diskussion z. B. bezüglich Standardisierung und
Normung möglich wird. Es sollen also auch die infra-
ge kommenden vorhandenen Standards und Normen
verortet werden können, damit sichtbar wird, wo
eventuell noch Erweiterungs-/Modifizierungsbedarf
besteht bzw. Normen und Standards fehlen. Über-
schneidungen werden dabei ebenfalls sichtbar und
können diskutiert werden. Existieren für denselben
oder ähnlichen Sachverhalt aus der Modellbetrach-
tung heraus mehrere Standards, kann ein Vorzugs-
standard im Referenzarchitekturmodell diskutiert
werden.
Ziel ist, mit möglichst wenigen Standards auszukom-
men.
Erfüllung von Standards
Die ausgewählten Normen und Standards werden
daraufhin geprüft, inwieweit deren beschriebene Kon-
zepte und Methoden für die Anwendungen im Umfeld
von Industrie 4.0 geeignet sind. Für eine erste I4.0-
Anwendung kann die Umsetzung einer Teilmenge
einer Norm/eines Standards genügen. Dies würde die
Umsetzung und Einführung von herstellerübergrei-
fenden Lösungen, wie sie für Industrie 4.0 unerläss-
lich sind, beschleunigen und auch kleineren Unter-
nehmen die Chance eröffnen, die Umsetzung und
Anpassung an Industrie 4.0 schneller zu bewältigen.
Use Cases
Das Referenzarchitekturmodell bietet auch die Mög-
lichkeit, I4.0-Use-Cases zu verorten, um z. B. die für
den jeweiligen Use Case notwendigen Normen und
Standards zu identifizieren.
Verortung von Beziehungen
Verschiedene Themen können als Unterräume des
Referenzarchitekturmodells dargestellt werden. Indus-
trie 4.0 lebt wesentlich davon, dass Beziehungen z. B.
zwischen diesen Unterräumen elektronisch erfasst und
bearbeitet werden können.
www.vdi.de
Referenzarchitekturmodell Industrie 4.0 7
Definition übergeordneter Regeln
Das Referenzarchitekturmodell erlaubt die Ableitung
von Regeln für die Umsetzung von I4.0-Implemen-
tierungen auf einer übergeordneten Ebene.
Die Ziele im Überblick
 anschauliches und einfaches Architekturmodell als
die Referenz
 Verortung von vorhandenen Normen und
Standards
 Identifikation und Schließen von Lücken in
Normen und Standards
 Identifikation von Überschneidungen und
Festlegung von Vorzugslösungen
 Minimierung der Zahl der eingesetzten Normen
und Standards
 Identifikation von Untermengen einer Norm bzw.
eines Standards zur schnellen Umsetzung von Tei-
linhalten für Industrie 4.0 („I4.0-ready“)
 Verortung von Use-Case-Inhalten
 Verortung von Beziehungen
 Definition übergeordneter Regeln
2.3.2 Kurzbeschreibung des
Referenzarchitekturmodells
Ein dreidimensionales Modell kann den I4.0-Raum
am besten darstellen. Dabei orientiert sich das Modell
in seinen Grundzügen am Smart Grid Architecture
Model (SGAM – Anmerkung: CEN/CENELEC/
ETSI SG-CG, Overview of SG-CG Methodologies,
Version 3.0, Annex SGAM User Manual, 2014), das
von der europäischen Smart Grid Coordination Group
(SG-CG) definiert wurde und weltweit akzeptiert ist.
Es wurde anhand der I4.0-Erfordernisse angepasst
und erweitert.
In der senkrechten Achse werden Layer/Schichten für
die Darstellung der unterschiedlichen Sichtweisen,
wie Datenabbild, funktionale Beschreibung, Kommu-
nikationsverhalten, Hardware/Assets oder auch Ge-
schäftsprozesse, verwendet. Dies entspricht der Denk-
weise der IT bei der Clusterung komplexer Projekte in
überschaubare Teileinheiten.
Ein weiteres wichtiges Kriterium ist der Produktle-
benszyklus mit seinen darin enthaltenen Wertschöp-
fungsketten. Dieser Sachverhalt wird auf der waag-
rechten Achse dargestellt (Bild 1). Damit können in
dem Referenzarchitekturmodell auch Abhängigkeiten
gut dargestellt werden, z. B. die durchgängige Daten-
erfassung über den gesamten Lebenszyklus.
Das dritte wichtige Kriterium, in der dritten Achse
dargestellt, ist die Verortung von Funktionalitäten und
Verantwortlichkeiten innerhalb der Fabriken/Anlagen.
Es geht um eine funktionale Hierarchie und nicht um
Geräteklassen oder Hierarchieebenen der klassischen
Automatisierungspyramide.
Bild 1. Referenzarchitekturmodell Industrie 4.0 (RAMI4.0)
www.vdi.de
8 Referenzarchitekturmodell Industrie 4.0
2.3.3 Schichten des Referenzarchitek-
turmodells (Layers)
Das Smart Grid Modell (SGAM) stellt einen guten
ersten Ansatz zur Darstellung der zu beschreibenden
Sachlage dar. Es behandelt das Stromnetz von der
Erzeugung über die Übertragung und Verteilung bis
zum Verbraucher. Bei Industrie 4.0 stehen Produkt-
entwicklungs- und Produktionsszenarien im Mittel-
punkt. Das heißt, es muss beschrieben werden, wie
Entwicklungsprozesse, Produktionslinien, Fertigungs-
maschinen, Feldgeräte und die Produkte selbst be-
schaffen sind bzw. funktionieren.
Für alle Komponenten, ob Maschine oder Produkt, ist
nicht nur die informations- und kommunikationstech-
nische Funktionalität von Interesse. Für die Simulati-
on eines Systems z. B. einer kompletten Maschine
werden auch deren Kabel, der Linearantrieb oder auch
die mechanische Konstruktion mitbetrachtet. Sie sind
Teil der Realität ohne aktiv kommunizieren zu kön-
nen. Ihre Informationen müssen als „Virtuelle Reprä-
sentation“ vorhanden sein. Dafür werden sie z. B.
passiv über einen 2D-Code mit einem Datenbankein-
trag verbunden.
Um sowohl Maschinen, Komponenten und Fabriken
besser beschreiben zu können, wurde gegenüber
SGAM dessen Component Layer durch einen Asset
Layer ersetzt, als untere Schicht in das Modell einge-
fügt und darüber der Integration Layer neu hinzuge-
fügt. Dieser ermöglicht die digitale Umsetzung der
Assets für die Virtuelle Repräsentation. Der Commu-
nication Layer behandelt Protokolle und Übertragung
von Daten und Dateien, der Information Layer bein-
haltet die relevanten Daten, der Functional Layer alle
notwendigen (formal beschriebenen) Funktionen und
im Business Layer ist der relevante Geschäftsprozess
abgebildet.
Hinweis: Innerhalb der Schichten soll eine hohe
Kohäsion und zwischen den Schichten eine lose
Kopplung herrschen. Der Ereignisaustausch darf nur
zwischen zwei benachbarten Schichten und innerhalb
einer Schicht erfolgen.
Mehrere Systeme werden zu größeren Gesamtsyste-
men zusammengefasst. Dabei müssen die Einzelsys-
teme und das Gesamtsystem dem Referenzarchitek-
turmodell folgen. Die Inhalte der Schichten müssen
zueinander kompatibel sein.
Nachfolgend werden die einzelnen Schichten und ihre
Beziehung untereinander beschrieben.
Geschäftssicht (Business Layer)
 Sicherstellung der Integrität der Funktionen in der
Wertschöpfungskette
 Abbildung der Geschäftsmodelle und dem sich
daraus ergebenden Gesamtprozess
 rechtliche und regulatorische Rahmen-
bedingungen
 Modellierung der Regeln, denen das System
folgen muss
 Orchestrierung von Diensten des Functional
Layers
 Verbindungselement zwischen verschiedenen
Geschäftsprozessen
 Empfang von Ereignissen für die Weiterschaltung
des Geschäftsprozesses
Der Business Layer bezieht sich nicht auf konkrete
Systeme wie beispielsweise ein ERP. ERP-Funk-
tionen, die im Prozesskontext arbeiten, finden sich
typischerweise im Functional Layer wieder.
Funktionsschicht (Functional Layer)
 formale Beschreibung von Funktionen
 Plattform für die horizontale Integration der
verschiedenen Funktionen
 Laufzeit- und Modellierungsumgebung für
Dienste, die Geschäftsprozesse unterstützen
 Laufzeitumgebung für Anwendungen und
fachliche Funktionalität
Innerhalb des Functional Layer werden Regeln/
Entscheidungslogiken erzeugt. Diese können auch
abhängig vom Anwendungsfall in den unteren Schich-
ten (Information Layer oder Integration Layer) ausge-
führt werden.
Fernzugriffe und horizontale Integration finden nur
innerhalb des Functional Layer statt. Damit werden
die Integrität der Informationen und Zustände im
Prozess und die Integration der technischen Ebene
sichergestellt. Zu Wartungszwecken können auch
temporäre Zugriffe auf Asset Layer und Integration
Layer stattfinden.
Solche Zugriffe werden insbesondere verwendet, um
auf Informationen und Prozesse, die nur für unterge-
ordnete Schichten relevant sind, zuzugreifen. Beispie-
le hierfür sind das Flashen von Sensoren/Aktoren oder
www.vdi.de
Referenzarchitekturmodell Industrie 4.0 9
das Auslesen von Diagnosedaten. Die wartungsbezo-
genen temporären Fernzugriffe sind für eine perma-
nente funktionale oder horizontale Integration nicht
relevant.
Informationsschicht (Information Layer)
 Laufzeitumgebung für die Ereignis(vor)-
verarbeitung
 Ausführung von ereignisbezogenen Regeln
 formale Beschreibung von Regeln
 Kontext: Ereignisvorverarbeitung
Dabei werden aus einem oder mehreren Ereignissen
über Regeln ein oder mehrere weitere Ereignisse
erzeugt, die dann im Functional Layer die Verarbei-
tung anstoßen.
 Persistieren der Daten, die die Modelle repräsen-
tieren
 Sicherstellung der Datenintegrität
 konsistente Integration verschiedener Daten
 Gewinnung von neuen, höherwertigen Daten
(Daten, Informationen, Wissen)
 Bereitstellung strukturierter Daten über Dienst-
schnittstellen
 Entgegennahme von Ereignissen und deren Trans-
formation passend zu den Daten, die für den
Functional Layer verfügbar sind
Kommunikationsschicht
(Communication Layer)
 Vereinheitlichung der Kommunikation, unter
Verwendung eines einheitlichen Datenformats, in
Richtung des Information Layer
 Bereitstellung von Diensten zur Steuerung des
Integration Layer
Integrationsschicht (Integration Layer)
 Bereitstellung der rechnerverarbeitbaren Informa-
tionen der Assets Physik/Hardware/Dokumente/
Software usw.
 Rechnergestützte Steuerung des technischen
Prozesses
 Generierung von Ereignissen aus den Assets
 enthält die mit der IT verbundenen Elemente,
wie RFID Reader, Sensoren, HMI
Die Interaktion mit dem Menschen erfolgt ebenfalls in
dieser Ebene, z. B. mittels der Mensch-Maschine-
Schnittstelle (HMI).
Hinweis: Jedes wichtige Ereignis in der Realität weist
auf ein Ereignis in der Virtualität, das heißt im Inte-
gration Layer. Ändert sich die Realität, wird das Er-
eignis mit geeigneten Mechanismen an den Integrati-
on Layer gemeldet. Relevante Ereignisse können
Ereignisse über den Communication Layer an den
Information Layer auslösen
Gegenstandsschicht (Asset Layer)
 repräsentiert die Realität, z. B. physikalische Ele-
mente wie Linearachsen, Blechteile, Dokumente,
Schaltpläne, Ideen, Archive
 Der Mensch ist ebenfalls Bestandteil des Asset
Layers und ist über den Integration Layer an die
virtuelle Welt angebunden.
 passive Verbindung der Assets mit der Integrati-
onsschicht über z. B. QR-Codes
2.3.4 Lebenszyklus und Wertschöp-
fungskette (Life Cycle &
Value Stream)
Lebenszyklus (Life Cycle)
Industrie 4.0 bietet über den gesamten Lebenszyklus
von Produkten, Maschinen, Fabriken, usw. großes
Verbesserungspotenzial. Um Zusammenhänge und
Verknüpfungen zu visualisieren und zu standardisie-
ren, repräsentiert die zweite Achse des Referenzarchi-
tekturmodells den Lebenszyklus und die damit ver-
bundenen Wertschöpfungsketten.
Für die Betrachtung des Lebenszyklus bietet der Ent-
wurf zur IEC 62890 eine gute Orientierung. Dabei ist
die grundsätzliche Unterscheidung von Typ und In-
stanz ein zentraler Teil für die Betrachtungen.
www.vdi.de
10 Referenzarchitekturmodell Industrie 4.0
Typ (Type)
Ein Typ entsteht immer mit der ersten Idee, also der
Entstehung des Produkts in der Phase „Development“.
Damit sind die Beauftragung, die Entwicklung, die
Tests bis hin zum ersten Muster und der Prototypenfer-
tigung gemeint. In dieser Phase entsteht also der Typ
des Produkts, der Maschine, usw. Nach Abschluss aller
Tests und Validierung wird der Typ für die Serienpro-
duktion frei gegeben.
Instanz (Instance)
Auf Basis des allgemeinen Typs werden in der Pro-
duktion Produkte hergestellt. Jedes gefertigte Produkt
stellt dann eine Instanz dieses Typs dar und erhält
z. B. eine eindeutige Seriennummer. Die Instanzen
gelangen in den Verkauf und werden an Kunden aus-
geliefert. Für den Kunden sind die Produkte zunächst
wieder nur Typen. Zur Instanz werden sie, wenn sie in
eine konkrete Anlage eingebaut werden. Der Wechsel
vom Typ zur Instanz kann sich mehrmals wiederho-
len.
Aus der Verkaufsphase zurückgemeldete Verbesse-
rungen können beim Hersteller eines Produkts zur
Anpassung der Typunterlagen führen. Mit dem neu
entstandenen Typ können wieder neue Instanzen
hergestellt werden. Der Typ unterliegt damit einer
Nutzung und Pflege genauso wie jede einzelne In-
stanz.
Beispiel
Die Entwicklung eines neuen Hydraulikventils stellt
einen neuen Typ dar. Das Ventil wird entwickelt,
erste Muster werden aufgebaut und getestet und zum
Abschluss wird eine erste Prototypenserie in der Pro-
duktion aufgelegt und anschließend validiert. Nach
erfolgreichem Abschluss der Validierung erfolgt die
Freigabe dieses Hydraulikventiltyps für den Verkauf
(Materialnummer und/oder Produktbezeichnung im
Verkaufskatalog). Und damit startet auch die Serien-
produktion. In der Serienproduktion erhält nun jedes
hergestellte Hydraulikventil z. B. seine eineindeutige
Kennzeichnung (Seriennummer) und ist eine Instanz
zu dem einmal entwickelten Hydraulikventil.
Rückmeldungen zu den verkauften Hydraulikventilen
(Instanzen) im Feld führen z. B. zu einer kleinen An-
passung der mechanischen Konstruktion und Zeich-
nungsunterlage sowie zu einer Softwarekorrektur in
der Firmware des Ventils. Diese Anpassungen sind
Anpassungen am Typ, das heißt, sie fließen in die
Typunterlagen ein, werden wieder freigegeben und
somit entstehen neue Instanzen des geänderten Typs
in der Produktion.
Wertschöpfungsketten
Die Digitalisierung und Verknüpfung der Wertschöp-
fungsketten bietet ein hohes Verbesserungspotenzial
durch Industrie 4.0. Dabei ist eine funktional über-
greifende Verknüpfung von entscheidender Bedeu-
tung.
Logistikdaten können in der Montage verwendet
werden, die Intralogistik organisiert sich selbst an-
hand der Auftragsbestände. Der Einkauf sieht in Echt-
zeit Bestände und wo sich Zulieferteile zu einem
bestimmten Zeitpunkt befinden. Der Kunde sieht den
Fertigstellungsgrad seines bestellten Produkts in der
Fertigung usw. Mit der Verknüpfung von Einkauf,
Auftragsplanung, Montage, Logistik, Maintenance,
Kunde, Zulieferer usw. bestehen große Verbesse-
rungspotenziale. Daher muss der Lebenszyklus mit
den enthaltenen Wertschöpfungsprozessen zusammen
betrachtet werden; und dies nicht isoliert mit Blick auf
eine Fabrik, sondern im Verbund aller Fabriken und
allen Partnern vom Engineering über Zulieferer bis
hin zum Kunden.
Zu den Wertschöpfungsketten sei auch auf die Veröf-
fentlichung des GMA-Fachausschusses 7.21 zu
„Wertschöpfungsketten“ [1] verwiesen.
2.3.5 Hierarchieebenen
(Hierarchy Levels)
Die dritte Achse des Referenzarchitekturmodells
beschreibt die funktionale Einordnung einer Sachlage
innerhalb Industrie 4.0. Dabei geht es nicht um eine
Implementierung, es geht allein um funktionale Zu-
ordnungen.
Für die Einordnung innerhalb einer Fabrik orientiert
sich das Referenzarchitekturmodell für diese Achse an
den Normen IEC 62264 und IEC 61512 (siehe Bild 2).
Für eine einheitliche Betrachtung über möglichst viele
Branchen von Prozessindustrie bis Fabrikautomation
wurden aus den dort aufgeführten Optionen die Be-
griffe „Enterprise“, „Work Unit“, „Station“ und „Con-
trol Device“ verwendet.
Für Industrie 4.0 ist neben dem Control Device (z. B.
einer Kopfsteuerung) auch die Betrachtung innerhalb
einer Maschine oder Anlage entscheidend. Daher wur-
de unterhalb des Control Device das „Field Device“
hinzugefügt. Dies stellt die funktionale Ebene eines
intelligenten Feldgeräts z. B. eines intelligenten Sen-
sors dar.
Außerdem ist neben der Anlage zur Herstellung von
Produkten in Industrie 4.0 auch das herzustellende
Produkt selbst für die Betrachtungen wichtig. Daher
ist es als untere Ebene zusätzlich als „Product“ einge-
www.vdi.de
Referenzarchitekturmodell Industrie 4.0 11
führt. Damit wird im Referenzarchitekturmodell eine
homogene Betrachtung von herzustellendem Produkt
und Produktionsanlage mit deren Abhängigkeiten
untereinander möglich.
Am oberen Ende der Hierarchy Levels wurde eben-
falls eine Ergänzung vorgenommen. Die beiden er-
wähnten IEC-Normen stellen nämlich nur die Ebenen
innerhalb einer Fabrik dar. Industrie 4.0 geht aber
einen Schritt weiter und beschreibt auch den Fabrik-
verbund, die Zusammenarbeit mit externen Enginee-
ring-Büros, Zulieferern und Kunden usw. Daher wur-
de für die Betrachtungen über den Enterprise Level
hinaus noch zusätzlich die Ebene „Connected World“
eingeführt.
2.4 Referenzmodell für die
I4.0-Komponente
Die nachfolgend beschriebene Version 1.0 des „Refe-
renzmodell I4.0-Komponente“ soll die erste von meh-
reren Verfeinerungen sein, die in unterjährigen Zeit-
abständen veröffentlich werden sollen.
In einem weiteren Schritt sollen daher Kapitel mit
genaueren Definitionen folgen, eine Formalisierung
mit UML ist vorgesehen.
Der Text bemüht sich, genau auszuweisen, wenn
Texte/Zitate aus anderen Quellen im I4.0-Umfeld
übernommen werden. Im Endstand sollen die Be-
griffsverwendungen identisch mit dem abgestimmten
und vom GMA-Fachausschuss 7.21 veröffentlichten
Glossar (siehe Kapitel 2.5) sein. Beispiele werden
ebenfalls explizit gekennzeichnet, um Ausschlüsse,
die im Beispiel nicht explizit genannt werden, zu
vermeiden.
Bild 2. Ableitung der Hierarchieebenen des RAMI4.0
www.vdi.de
12 Referenzarchitekturmodell Industrie 4.0
2.4.1 Einordnung in die Diskussion zu
Industrie 4.0
Die Diskussion Industrie 4.0 lässt sich grob als Zu-
sammenspiel von vier Aspekten auffassen, wie Bild 3
aus dem Abschlussbericht des Arbeitskreises Indus-
trie 4.0 [4] illustriert:
Nach Bild 3 sind diese vier Aspekte:
 I4.0-Aspekt (1) Horizontale Integration über
Wertschöpfungsnetzwerke
 I4.0-Aspekt (2) Vertikale Integration,
z. B. innerhalb einer Fabrik/Fertigung
 I4.0-Aspekt (3) Lebenszyklus-Management,
Durchgängigkeit des Engineering
 I4.0-Aspekt (4) Der Mensch als Dirigent im
Wertschöpfungsnetzwerk
Die in diesem Text beschriebene I4.0-Komponente
gibt einen flexiblen Rahmen vor, mit dem Daten und
Funktionen beschrieben und bereitgestellt werden
können, die die oben angeführten I4.0-Aspekte för-
dern und möglich machen. Die in diesem Text be-
schriebenen Konzepte bedienen zum jetzigen Zeit-
punkt vor allem Aspekt (2) und berücksichtigen An-
forderungen aus Aspekt (3).
2.4.2 Inhalte aus weiteren relevanten
Publikationen
Gegenstände, Entitäten, Komponenten
Hierzu wird verwiesen auf den VDI-Statusreport
„Industrie 4.0: Gegenstände, Entitäten, Komponen-
ten“ des GMA-Fachausschusses 7.21 [3]. Definitio-
nen hieraus finden sich in den vorausgegangenen
Kapiteln des hier vorliegenden Statusreports.
Typen und Instanzen
Hierzu wird ebenfalls auf den VDI-Statusreport
„Industrie 4.0: Gegenstände, Entitäten, Komponen-
ten“ des GMA-Fachausschusses 7.21 [3] verwiesen.
Es wird auf den Stand der Technik bezüglich der
Unterscheidung von Typen und Instanzen in der
Industrie 4.0. eingegangen.
Lebenszyklen
Nach Fraunhofer IPA, Dr. Carmen Constantinescu
und Prof. Thomas Bauernhansl, sind für den Betrieb
einer Fabrik Lebenszyklen mehrerer Dimensionen
von Relevanz für Industrie 4.0.
 Produkt: Eine Fabrik produziert mehrere Produk-
te. Jedes Produkt hat einen eigenen Lebenszyklus.
 Auftrag: Jeder Auftrag, der gefertigt werden soll,
durchläuft einen Lebenszyklus und muss seine
Spezifitäten während der Auftragsausführung in
den Produktionsbetrieb abprägen können.
 Fabrik: Auch eine Fabrik hat einen Lebenszyklus:
Sie wird finanziert, geplant, aufgebaut und wie-
derverwertet. Eine Fabrik integriert Produktions-
systeme und Maschinen verschiedener Hersteller.
 Maschine: Eine Maschine wird in Auftrag gege-
ben, konstruiert, in Betrieb genommen, betrieben,
gewartet, umgebaut und verwertet.
Bild 3. Vier wichtige Aspekte von Industrie 4.0 (Quellen: Siemens, Festo)
www.vdi.de
Referenzarchitekturmodell Industrie 4.0 13
Bild 4. Relevante Lebenszyklen für I4.0-Komponenten; Quelle: M. Hankel, Bosch Rexroth. Basiert auf
Plattform Industrie 4.0 AG3. Basiert auf Prof. Bauernhansl, Fraunhofer IPA
Der Maschinenhersteller bezieht dazu einzelne Zulie-
ferteile, die in diesem Text als Gegenstände bezeich-
net werden. Der Zulieferer (in der Regel ein Kompo-
nentenhersteller) realisiert einen Lebenszyklus auch
für diese Zulieferteile:
 Komponente: Planung und Entwicklung, Rapid
Prototyping, Konstruktion, Produktion, Nutzung
bis hin zum Service
Bild 4 verdeutlicht die Zuordnung von Typen und
Instanzen zum Lebenszyklus.
Verbindung von Lebenszyklen
Ursächlich für die notwendige Unterscheidung von
Typen und Instanzen sind das Zusammenwirken ver-
schiedener Geschäftspartner und deren jeweiliger
Lebenszyklen mit den Planungsprozessen. Während
einer Planung werden verschiedene Hypothesen und
Alternativen erwogen. Die Planung geht von potenzi-
ellen Gegenständen aus und nennt diese „Typen“:
 Der Zulieferer nennt diese „Teiletypen“: Erst die
Fertigung und die anschließende Auslieferung an
den Kunden (Maschinenhersteller) „erschafft“
eine Instanz, die dieser als Zulieferteil weiterver-
wendet.
 Der Maschinenhersteller bespricht mit seinen
Kunden und plant „Maschinentypen“: Die Kon-
struktion einer speziellen Maschine und deren Re-
alisierung erschafft eine Instanz, die der Fabrikbe-
treiber weiterverwendet.
 Der Fabrikbetreiber entwickelt ein Produkt
ebenfalls zunächst als Produkttyp. Erst der Auf-
trag stößt die Fertigung an und realisiert die Ferti-
gung konkreter Produktinstanzen, die ausgeliefert
werden.
Bemerkenswert ist nun, dass während der Konzeption
und Planung eines jeweiligen Typs viele Informatio-
nen und Daten generiert werden, die bei der Verwen-
dung der jeweiligen Instanz durch den nachfolgenden
Geschäftspartner im Wertschöpfungsnetzwerk genutzt
werden können. Weitere Informationen kommen
während der Produktion einer bestimmten Instanz
hinzu (z. B. Tracking-Daten und Qualitätsdaten). Das
Referenzmodell für I4.0-Komponenten behandelt
daher Typen und Instanzen gleichwertig und gleichar-
tig.
www.vdi.de
14 Referenzarchitekturmodell Industrie 4.0
Bild 5. Typen und Instanzen im Lebenszyklus
Referenzarchitekturmodell Industrie 4.0
(RAMI4.0)
Für die Definitionen des „Referenzarchitekturmodell
Industrie 4.0 (RAMI4.0)“ sei auf die vorausgegange-
nen Kapitel verwiesen. Die in Bild 5 vorgestellte
I4.0-Komponente ordnet sich in die Schichten des
RAMI4.0 ein. Sie kann verschiedene Positionen des
Life-Cycle und Value-Streams genauso wie verschie-
dene Hierarchieebenen abbilden; hier bedarf es der
konkreten Instantiierung zur eindeutigen Festlegung
2.4.3 I4.0-Komponente
In diesem Kapitel wird eine erste allgemein anerkann-
te Definition einer I4.0-Komponente hergeleitet.
Bild 6. Abgrenzung „Office floor” und „Shop floor”
www.vdi.de
Referenzarchitekturmodell Industrie 4.0 15
Abgrenzung der I4.0-Komponente zwi-
schen „Office floor“ und „Shop floor“
Um eine Abgrenzung der Verantwortlichkeiten vor-
nehmen zu können, wird in Unternehmen gewöhnlich
zwischen „Office floor“ und „Shop floor“ unterschie-
den. In modernen Unternehmen sind allerdings diese
Bereiche zunehmend miteinander verzahnt. Wird ein
Augenmerk auf die Automatisierungstechnik gelegt,
so nimmt die Relevanz des „Office floor“ ab, während
immer mehr Anforderungen des „Shop floor“ relevant
werden. Gleiches gilt auch in anderer Richtung. Auf-
grund der Forderung in Bild 6 nach Konnektivität zu
beliebigen Endpunkten und einem gemeinsamen se-
mantischen Modell müssen Komponenten bestimmte
gemeinsame Eigenschaften unabhängig von den Ebe-
nen aufweisen. Sie sind in Form der I4.0-Komponente
spezifiziert.
Eine I4.0-Komponente kann ein Produktionssystem,
eine einzelne Maschine oder Station oder auch eine
Baugruppe innerhalb einer Maschine repräsentieren.
Damit bewegt sich jede I4.0-Komponente, so ver-
schieden sie sein mag, im Spannungsfeld der Rele-
vanzen „Office floor“ und „Shop floor“, entlang des
Lebenszyklus der Fabrik und in Kontakt mit so zent-
ralen und signifikanten Fabriksystemen wie dem PLM
(Product Lifecycle Management), ERP (Enterprise
Ressource Planning), Industrial Control und Logistik-
Systemen.
Anforderung: Ein Netzwerk von I4.0-Komponen-
ten muss so aufgebaut sein, dass Verbindungen
zwischen beliebigen Endpunkten (I4.0-Komponen-
ten) möglich sind. Die I4.0-Komponenten und
deren Inhalte sollen einem gemeinsamen semanti-
schen Modell folgen.
Anforderung: Das Konzept einer I4.0-Komponen-
te muss so ausdifferenziert werden können, dass es
verschiedenen Anforderungsschwerpunkten, also
„Office floor“ oder „Shop floor“, gerecht werden
kann.
Vom Gegenstand zur I4.0-Komponente
Im folgenden Abschnitt sollen die einzelnen Festle-
gungen der VDI/VDE-Gesellschaft Mess- und Auto-
matisierungstechnik (GMA) miteinander in Bezug
gesetzt werden, um zu einer Definition einer
I4.0-Komponente zu gelangen:
Gegenstandsklassen
Die GMA benennt vier Gegenstandklassen:
 nicht bekannt,
 anonym bekannt,
 individuell bekannt und
 Entitäten.
Um Daten und Funktionen an einen Gegenstand bin-
den zu können, muss dieser als Entität vorliegen.
Software, die im herkömmlichen Sinne auch physisch
oder nicht physisch ausgeliefert wird, ist ebenfalls ein
Gegenstand. Auch Ideen, Archive und Konzepte sind
Gegenstände in diesem Sinne.
Bemerkung 1: Da ein Ziel einer I4.0-Komponente ist,
Daten und Funktionen in einem Informationssystem
bereitzustellen, ergibt sich für individuell bekannte
Gegenstände im Sinne der GMA per se ein Übergang
zu einer Entität.
Bemerkung 2: Im Folgenden wird immer von Gegen-
stand gesprochen, wenn ein Gegenstand/Entität be-
zeichnet wird.
Bild 7. I4.0-Komponente
Typ/Instanz
Gegenstände können als Typ oder als Instanz bekannt
sein. Als Typ ist ein Gegenstand z. B. in der Pla-
nungsphase bekannt; sind die Bestellinformationen
eines geplanten Gegenstands bekannt, kann dieser als
individuell bekannter Typ aufgefasst werden. Als
Instanzen sind z. B. alle Gegenstände einer real exis-
tierenden Maschine aufzufassen. Scheinbare Instan-
zen, die durch mehrfache Instantiierung eines Typs im
Sinne einer Abzählbarkeit entstehen (Chargen), sind
www.vdi.de
16 Referenzarchitekturmodell Industrie 4.0
zurzeit nicht gesondert berücksichtigt. Hier sollte die
Instantiierung konkret ausgeführt werden und ein
Rückbezug auf den Typ vorgesehen werden.
Kommunikationsfähigkeit
Um Eigenschaften einer I4.0-Komponente bereitstel-
len zu können, muss mindestens ein Informationssys-
tem eine Verbindung zum Gegenstand halten. Daher
wird mindestens passive Kommunikationsfähigkeit
für den Gegenstand vorausgesetzt, was bedeutet, dass
ein Gegenstand nicht unbedingt die Fähigkeit einer
I4.0-konformen Kommunikation entsprechend GMA-
Fachausschuss 7.21 aufweisen muss. Damit können
bereits bestehende Gegenstände zu I4.0-Komponenten
„erweitert“ werden. In diesem Fall übernimmt ein
übergeordnetes IT-System einen Teil der I4.0-konfor-
men Kommunikation im Sinne einer SOA-Architektur
und eines Stellvertreterprinzips.
Beispielsweise kann so eine identifizierbare Klemm-
leiste eine I4.0-Komponente werden oder ein Profi-
Net-Gerät (identifizierbar über seine I&M-Daten).
Virtuelle Repräsentation
Die Virtuelle Repräsentation hält Daten zu dem Ge-
genstand. Diese Daten können entweder „auf/in“ der
I4.0-Komponente selbst gehalten und durch eine I4.0-
konforme Kommunikation der Außenwelt zur Verfü-
gung gestellt werden. Oder sie werden auf einem
(übergeordneten) IT-System gehalten, das sie durch
I4.0-konforme Kommunikation der Außenwelt zur
Verfügung stellt.
Im Referenzarchitekturmodell RAMI4.0 findet die
Virtuelle Repräsentation auf der Informationsschicht
statt. Damit kommt der I4.0-konformen Kommunika-
tion eine hohe Bedeutung zu.
Anforderung: Die I4.0-konforme Kommunikation
muss so ausgeführt sein, dass die Daten einer Vir-
tuellen Repräsentation einer I4.0-Komponente
entweder im Gegenstand selbst oder aber in einem
(übergeordneten) IT-System gehalten werden kön-
nen
Ein wichtiger Teil der Virtuellen Repräsentation ist
das „Manifest“ [Gewählt wegen .JAR-Datei, s. Mani-
fest bei: http://docs.oracle.com/javase/7/docs/
technotes/guides/jar/jar.html#JAR_Manifest], das als
Verzeichnis der einzelnen Dateninhalte der Virtuellen
Repräsentation angesehen werden kann. Damit enthält
es sogenannte Meta-Informationen. Es enthält außer-
dem verpflichtende Angaben zu der I4.0-Komponente,
unter anderem zur Verbindung mit dem Gegenstand
durch die entsprechende Identifikationsmöglichkeit.
Mögliche weitere Daten in der Virtuellen Repräsenta-
tion sind Daten, die einzelne Lebenszyklusphasen
umfassen, wie CAD-Daten, Anschlussbilder oder
Handbücher.
Fachliche Funktionalität
Neben Daten kann eine I4.0-Komponente auch eine
fachliche Funktionalität besitzen. Diese Funktionalität
kann beispielsweise umfassen:
 Software zur „lokalen Planung“ in Verbindung mit
dem Gegenstand. Beispiele: Schweißplanung,
Software zum Beschriften der Klemmleisten usw.
 Software zur Projektierung, Konfiguration, Bedie-
nung, Wartung
 Mehrwerte zum Gegenstand
 weitere fachliche Funktionalitäten, die für die
Ausführung der Geschäftslogik relevant sind
Im Referenzarchitekturmodell RAMI4.0 findet die
fachliche Funktionalität auf der Funktionsschicht statt.
Eine „Verwaltungs-Schale“ macht einen
Gegenstand zu einer I4.0-Komponente
Wie der obige Abschnitt beschreibt, können verschie-
denartige Gegenstände mit verschiedenartigen Kom-
munikationsfähigkeiten zu einer I4.0-Komponente
ausgeführt werden. Dieser Abschnitt soll diese ver-
schiedenen Ausführungsformen anhand von Beispie-
len näher beleuchten. Im Sinne des Konzepts „I4.0-
Komponente“ sind diese Ausführungsformen gleich-
wertig.
www.vdi.de
Referenzarchitekturmodell Industrie 4.0 17
Bild 8. Ein Gegenstand wird zur I4.0-Komponente
Bild 8 zeigt, dass ein Gegenstand, gleich welcher Art,
zunächst keine I4.0-Komponente ist. Erst wenn dieser
Gegenstand, der eine Entität und mindestens passiv
kommunikationsfähig sein muss, mit einer „Verwal-
tungs-Schale“ umgeben wird, kann er als I4.0-Kom-
ponente bezeichnet werden.
Im Sinne des obigen Abschnitts umfasst dabei die
Verwaltungs-Schale die Virtuelle Repräsentation und
die fachliche Funktionalität des Gegenstands.
Für einen möglichen Gegenstand gibt Bild 8
vier Beispiele:
1 Eine ganze Maschine kann vor allem aufgrund
ihrer Steuerung als I4.0-Komponente ausgeführt
werden. Diese Ausführung der I4.0-Komponente
übernimmt dann beispielsweise der Maschinen-
hersteller.
Auch eine strategisch wichtige Baugruppe von ei-
nem Zulieferer kann als eigenständige I4.0-Kom-
ponente aufgefasst werden, um sie beispielsweise
von Asset-Management- und Wartungssystemen
eigenständig zu erfassen. Die Ausführung der
I4.0-Komponente übernimmt dann beispielsweise
der Komponentenhersteller.
2 Ebenso ist es möglich, einzelne konstruierte Bau-
gruppen (um den Begriff Komponente zu vermei-
den) der Maschinen als I4.0-Komponente aufzu-
fassen. Beispielsweise ist es für einen Klemmen-
block wichtig, die Beschaltung mit einzelnen Sig-
nalen festzuhalten und über den Lebenszyklus der
Maschine aktuell zu halten. Diese Ausführung der
I4.0-Komponente übernimmt dann beispielsweise
der Elektro-Planer und Elektriker.
3 Letztlich kann eine bereitgestellte Software ein
wichtiges Asset eines Produktionssystems und
somit eine I4.0-Komponente darstellen. Eine sol-
che Standardsoftware könnte z. B. ein eigenstän-
diges Planungs- oder Engineering-Werkzeug sein,
das heute oder in Zukunft für den Betrieb der Fer-
tigung wichtig ist. Auch ist es denkbar, dass ein
Zulieferer eine Bibliothek, die erweiterte Funktio-
nen zu seinen Produkten bereitstellt, als reine
Software verkaufen möchte. Diese Ausführung der
I4.0-Komponente übernähme dann beispielsweise
der Bereitsteller der Software; eine Verteilung auf
einzelne IEC-61131-Steuerungen würde dann von
den verschiedenen I4.0-Systemen geleistet.
Bild 8 stellt in einer logischen Sicht dar, dass zu
einem Gegenstand eine „Verwaltungs-Schale“ gehört.
Im Hinblick auf eine Verteilungssicht können Ge-
genstand und Verwaltungs-Schale durchaus entkop-
pelt existieren. So kann bei passiv kommunikations-
fähigen Gegenständen die Verwaltungs-Schale in
einem übergeordneten IT-System abgebildet („gehos-
tet“) werden. Mithilfe der passiven Kommunikations-
www.vdi.de
18 Referenzarchitekturmodell Industrie 4.0
fähigkeit des Gegenstands und einer I4.0-konformen
Kommunikation des übergeordneten IT-Systems wird
die Verbindung zwischen Gegenstand und Verwal-
tungs-Schale gewahrt. Gleiches gilt, wenn der Gegen-
stand aktiv, aber nicht I4.0-konform kommunikations-
fähig ist. Erst bei einer I4.0-konformen Kommunika-
tionsfähigkeit kann die Verwaltungs-Schale „im“
Gegenstand abgebildet werden (sie wird beispielswei-
se in der Steuerung einer Maschine gespeichert und
durch die Netzwerkschnittstelle ausgeliefert). Im
Sinne des Konzepts „I4.0-Komponente“ sind alle
Alternativen als gleichwertig anzusehen.
Ein Gegenstand kann mehrere Verwaltungs-Schalen
für unterschiedliche Zwecke besitzen.
Anforderung: Durch ein geeignetes Referenzmo-
dell muss beschrieben werden, wie ein übergeord-
netes IT-System die Verwaltungs-Schale I4.0-kon-
form zur Verfügung stellen kann (SOA-Ansatz,
Stellvertreterprinzip).
Anforderung: Es muss beschrieben werden, wie
die Verwaltungs-Schale vom Erzeuger (z. B. Kom-
ponentenhersteller, Elektro-Planer) zum überge-
ordneten IT-System „transportiert“ werden kann
(z. B. als Attachment zu einer E-Mail).
Weitere Begriffsabgrenzung
Bild 9 grenzt die Begriffe nochmals voneinander ab:
Eine I4.0-Komponente umfasst aus logischer Sicht ein
oder mehrere Gegenstände und eine Verwaltungs-
Schale, die Daten der Virtuellen Repräsentation und
Funktionen der fachlichen Funktionalität enthält. Das
Manifest als Teil der Virtuellen Repräsentation detail-
liert die notwendigen verwaltungstechnischen Anga-
ben zu der I4.0-Komponente. Der „Resource-Mana-
ger“, wie vom GMA-Fachausschuss 7.21 definiert, ist
ebenfalls Teil der Verwaltungs-Schale. Damit haben
die IT-technischen Dienste Zugriff auf die Daten und
Funktionen der Verwaltungs-Schale und machen sie
nach außen verfügbar.
Die Verwaltungs-Schale und ihre Objekte können
innerhalb eines „embedded systems“ eines der Gegen-
stände „gehostet“ sein (aktive, I4.0-konforme Kom-
munikationsfähigkeit) oder aber in ein oder mehrere
übergeordnete IT-Systeme verteilt werden (Vertei-
lungssicht.
Bild 9. I4.0-Komponente
Anforderung: Je nach Art der übergeordneten
Systeme müssen die Verwaltungsobjekte in mehr
als ein übergeordnetes IT-Systems verteilt werden
können.
Cyberphysisches System
Die I4.0-Komponente stellt eine Spezialisierung eines
cyberphysischen Systems dar.
I4.0-Komponenten aus Verteilungssicht
Der obere Abschnitt stellt dar, dass aus einer logi-
schen Sicht heraus für jede I4.0-Komponente zu je-
dem Gegenstand eine „Verwaltungs-Schale“ gehört.
Er betont aber auch, dass situativ aus Verteilungssicht
die Verwaltungs-Schale in ein übergeordnetes System
ausgelagert werden kann
I4.0-Komponente in Repository abgebildet
Zum besseren Verständnis kann eine zu einem Repo-
sitory der „Digitalen Fabrik“ konforme Darstellung
gezeigt werden, die im Einklang mit den dargelegten
Konzepten ist (Bild 10).
I4.0-Komponente durch Gegenstand abgebildet
Ist einer der Gegenstände der I4.0-Komponente I4.0-
konform kommunikationsfähig (CP34- oder CP44
nach [3], so bietet sich an, die I4.0-Komponente durch
den Gegenstand abzubilden (Bild 11).
www.vdi.de
Referenzarchitekturmodell Industrie 4.0 19
Bild 10. Repository
Bild 11. Lebenszyklus der Fabrik
www.vdi.de
20 Referenzarchitekturmodell Industrie 4.0
Bild 12. Kapselfähigkeit und Vernetzung einer I4.0-Komponente
I4.0-Komponente ist kapselfähig
Die I4.0-Komponente soll bewusst alle möglichen
Querverbindungen innerhalb der I4.0-Fabrik eingehen
bzw. aufbauen können (Bild 12, Nr. 1). Doch diese
Vernetzung darf nicht zur Einschränkung der Kern-
funktionalität führen (Bild 12, Nr. 2). Die Fähigkeit,
diesen Kernbereich störungsfrei zu erhalten, selbst
wenn die „äußere“ Vernetzung Störungen unterliegt,
wird durch SG2 (ZVEI Spiegelgremium Referenz-
architektur) und SG4 (ZVEI Spiegelgremium Securi-
ty) als „kapselfähig“ bezeichnet.
Anforderung: Die I4.0-Komponente, insbesondere
die Verwaltungs-Schale, ihre enthaltene Funktiona-
lität und die damit befassten Protokolle sollen
„kapselfähig“ sein.
Das vorliegende Konzept verwirklicht diese Anforde-
rung dadurch, dass die Verwaltungs-Schale als unab-
hängiges Daten-/Funktionsobjekt ausgeführt wird.
Der Zugriff auf die darin enthaltenen Daten und Funk-
tionen soll nach dem Prinzip von „Separation of Con-
cerns (SoC)“ gestaltet werden, sodass eine Beeinflus-
sung von für die Fertigung kritischen Abläufen nach
dem Stand der Technik ausgeschlossen werden kann.
Aus der Anwendung dieses Prinzips folgt, dass die
I4.0-konforme Kommunikation nach heutigem Stand
in der Fertigung verwendete Ethernet-basierte Feld-
busse nicht vollständig ersetzen muss (Migrations-
szenario).
Allerdings sollen I4.0-konforme Kommunikation und
eine mögliche deterministische oder Echtzeit-Kom-
munikation aufeinander abgestimmt sein und z. B.
nach Möglichkeit die gleichen (physikalischen)
Schnittstellen und Infrastrukturen verwenden. Die
Widerspruchsfreiheit zwischen beiden Kommunikati-
onskanälen muss gewährleistet sein.
Für das in diesem Text beschriebene Referenzmodell
bedeutet diese Argumentation, dass I4.0-konforme
Kommunikation nicht sämtliche Eigenschaften einer
deterministischen oder Echtzeit-Kommunikation
selbst realisieren muss, sondern sie an bestehende
Technologien delegieren kann.
Anspruch der I4.0-Komponente ist, nicht I4.0-kon-
forme Kommunikationsbeziehungen, die in die
Gegenstandsschale führen oder diese verlassen, zu
erfassen und einem durchgängigen Engineering zu
öffnen.
Die heute üblichen Echtzeit-Ethernet-Protokolle las-
sen es möglich erscheinen, beide Kommunikationen
über die gleiche Kommunikationsinfrastruktur (An-
schlüsse, Stecker, Zwischenstationen) abzuwickeln
(Bild 12, Nr. 3). Nach dem Prinzip „Separation of
Concern“ sind aber beide Kommunikationsarten lo-
gisch weiterhin getrennt.
Eine I4.0-Komponente kann mehrere
Gegenstände enthalten
Dieser Abschnitt zeigt an einem Beispiel, dass eine
I4.0-Komponente nicht nur ein, sondern mehrere
Gegenstände enthalten kann.
www.vdi.de
Referenzarchitekturmodell Industrie 4.0 21
Bild 13. I4.0-Komponente, bestehend aus meh-
reren Gegenständen
Die in der Bild 13 gezeigten Gegenstände formen
zusammen ein beispielhaftes elektrisches Achssystem.
Von einem Hersteller gibt es eine Auslegungssoft-
ware, die während der Engineering-Phase dazu ge-
führt hat, dass die einzelnen Teilsysteme zu einem
System kombiniert wurden. Vom Hersteller gibt es
eine Konfigurationssoftware, mit der das System als
Ganzes in Betrieb gesetzt werden kann. Verfahrsätze,
aufgezeichnete Verschleißdaten und das Condition
Monitoring müssen die einzelnen Systembestandteile
miteinander in Bezug setzen (z. B. bezüglich maxima-
ler Verfahrlänge).
Daher ist es aus I4.0-Sicht sinnvoll, diese einzelnen
Gegenstände als ein System zu verwalten und als eine
I4.0-Komponente abzubilden. Eine Zerlegung in ein-
zelne I4.0-Komponenten würde die Abbildung vieler
verschiedener Sinnzusammenhänge durch ein oder
sogar mehrere übergeordnete I4.0-Systeme erfordern
und unnötig verkomplizieren.
Eine I4.0-Komponente kann logisch
schachtelbar sein
Industrie 4.0 fordert die Modularisierung von Produkti-
onssystemen für auftragsgerechte Rekonfiguration und
Wiederverwendung von (Unternehmens-)Assets im
Rahmen von I4.0-Aspekt (2) „Vertikale Integration“.
Daher sieht das Konzept vor, dass eine I4.0-Kompo-
nente andere Komponenten logisch umfassen, als Ein-
heit agieren und für ein übergeordnetes System logisch
abstrahieren kann.
Zudem fordert I4.0-Aspekt (3) „Durchgängigkeit im
Engineering“, dass für möglichst viele Gegenstände
eines Produktionssystems weiterführende Daten und
Engineering-Planungen online verfügbar sind. Die
Verwaltungs-Schale sieht vor, dass Daten, die den
Gegenständen der I4.0-Komponente eindeutig zuge-
ordnet werden können, auch derart verteilt verfügbar
sind. Derart verteilte Daten sind für ein verteiltes
Engineering und für eine schnelle Rekonfiguration
von Vorteil.
Bild 14. Schachtelbarkeit von I4.0-Komponenten
Daher soll das Konzept für eine I4.0-Komponente
vorsehen, dass einer I4.0-Komponente (z. B. einer
ganzen Maschine) andere I4.0-Komponenten logisch
zugeordnet werden, sodass sich eine (temporäre)
Schachtelung ergibt.
Technisch gesehen kann dieses so ausgeführt werden,
dass der übergeordnete Gegenstand (z. B. eine Ma-
schine) zwei I4.0-konforme Kommunikationsschnitt-
stellen ausprägt, sodass sich eine klare logische und
physikalische Trennung von übergeordneten und
untergeordneten I4.0-Komponenten ergibt (Bild 14,
Nr. 1). Eine weitere Möglichkeit besteht darin, dass
die I4.0-konforme Kommunikation „oben“ und „un-
ten“ physisch eins sind, aber logisch voneinander
getrennt werden (Bild 14, Nr. 2).
Um eine solche logische Zuordnung von „untergeord-
neten“ I4.0-Komponenten zu managen, kann die
Verwaltungs-Schale ein geeignetes „Komponenten-
Management“ vorsehen. Dieses kann z. B. die Rekon-
figuration einer Maschine unterstützen oder aber den
Status der Maschine „nach oben“ geeignet abbilden.
Anforderung: Einer I4.0-Komponente (z. B. einer
ganzen Maschine) sollen andere I4.0-Komponenten
logisch zugeordnet werden können, sodass sich
eine (temporäre) Schachtelung ergibt.
Anforderung: Übergeordnete Systeme sollen
zweckgebunden und einschränkbar auf alle I4.0-
Komponenten zugreifen können, auch wenn diese
(temporär) logisch zugeordnet sind.
www.vdi.de
22 Referenzarchitekturmodell Industrie 4.0
Zustandsmodell
Der Zustand einer I4.0-Komponente ist von anderen
Teilnehmern einer I4.0-konformen Kommunikation
immer abrufbar. Er folgt dabei einem definierten
Zustandsmodell.
Da I4.0-Komponenten hierarchisch organisiert sein
können, sollte eine geeignete Abbildung von Unterzu-
ständen in einen Zustand definiert werden („Was
bedeutet es für die Maschine, wenn ein Teil nicht
betriebsbereit ist?“).
Zusätzlich soll das Zustandsmodell auch mit einer
größeren Menge von Zustandsvariablen komplemen-
tiert werden, die eine detaillierte Sicht auf die Zustän-
de der Virtuellen Repräsentation und der fachlichen
Funktionalität erlauben. Dies erlaubt zu einem Zeit-
punkt „t“ eine konsistente Sicht auf den Zustand einer
I4.0-Komponente, etwa zum Zweck der statistisch
korrekten Datenanalyse.
Allgemeine Merkmale der
„I4.0-Komponente“
Der VDI/VDE-GMA FA 7.21 definiert den Begriff
„Komponente“ im Kontext zu Industrie 4.0 wie folgt:
Der Begriff „Komponente“ ist allgemein. Er bezeich-
net einen Gegenstand der physischen Welt oder der
Informationswelt, der in seinem Systemumfeld eine
bestimmte Rolle spielt oder für eine solche vorgese-
hen ist. Eine Komponente kann z. B. ein Rohr, ein
SPS-Funktionsbaustein, eine Lampe, ein Ventil, eine
intelligente Antriebseinheit sein. Wichtig ist die Be-
trachtung als Einheit und der Bezug zu der Rolle
(Funktion), die sie in einem System wahrnehmen soll
oder bereits wahrnimmt. Als I4.0-Komponente be-
zeichnen wir eine spezielle Art von Komponente.
I4.0-Komponenten zeichnen sich dadurch aus, dass
sie bezüglich der oben dargestellten Klassifikations-
merkmale bestimmte Anforderungen erfüllen. Auch in
einem I4.0-System gibt es viele Komponenten, die
diese Anforderungen nicht erfüllen und die damit
keine I4.0-Komponenten sind.
Das hier vorliegende Konzept lässt auch Gegenstände
zu, die passiv oder aktiv, aber nicht I4.0-konform
kommunikationsfähig sind. Daher gilt für die I4.0-
Komponente im Sinne dieses Dokuments:
 Sie ist bezüglich der CP-Klassifikation entweder
eine CP24, CP34 oder eine CP44-Komponente.
 Sie besitzt eine Verwaltungs-Schale, die so kom-
muniziert werden kann, dass sie zu einem vollwer-
tigen Dienstsystemteilnehmer im I4.0-Netzwerk
wird.
Der folgende Abschnitt wurde auf Basis der GMA-
Definition verfeinert und stellt daher eine Detaillie-
rung der Konzepte dar. In voller Übereinstimmung
mit dem VDI-Statusreport „Gegenstände, Entitäten,
Komponenten“ [3] werden als Dienstsystemteilneh-
mer im I4.0-Netzwerk von einer I4.0-Komponente
zunächst folgende Merkmale verlangt (Anforderun-
gen):
Identifizierbarkeit
Sie ist im Netzwerk eindeutig identifizierbar und ihre
physischen Gegenstände werden mittels eines einein-
deutigen Identifiers (ID) identifiziert. Ist sie eine
CP34- oder CP44-Komponente; so ist sie über eine
Kommunikationsadresse (z. B. IP-Adresse) erreich-
bar.
I4.0-konforme Kommunikation
Die I4.0-Komponenten kommunizieren untereinander
mindestens nach dem SOA Prinzip (inklusive ge-
meinsamer I4.0-konformer Semantik).
I4.0-konforme Dienste und Zustände
Sie unterstützt die für ein I4.0-System allgemein stan-
dardisierten (auch nachladbaren) Dienstfunktionen
und Zustände.
Virtuelle Beschreibung
Sie liefert ihre virtuelle Beschreibung einschließlich
ihres dynamischen Verhaltens. Diese Beschreibung
wird durch die Virtuelle Repräsentation und das
Manifest erreicht.
I4.0-konforme Semantik
Sie unterstützt die für ein I4.0-System standardisierte
I4.0-konforme Semantik.
Security und Safety
Sie bietet für ihre Funktionalität und Daten einen der
Aufgabe entsprechenden ausreichenden Schutz
(Security). Zusätzlich können in Anwendungen auch
Maßnahmen zur funktionalen Sicherheit, Maschinen-
sicherheit notwendig sein (Safety).
Quality of Services
Sie besitzt die für ihre Aufgabe erforderlichen Eigen-
schaften als „Quality of Services“ (QoS). Bezüglich
der Anwendung in der Automatisierungstechnik sind
www.vdi.de
Referenzarchitekturmodell Industrie 4.0 23
dies Eigenschaften wie Echtzeitfähigkeit, Ausfallsi-
cherheit, Uhrensynchronisation. Diese Eigenschaften
richten sich möglicherweise nach einem Profil aus.
Zustand
Sie liefert jederzeit ihren Zustand.
Schachtelbarkeit
Jede I4.0-Komponente kann aus weiteren I4.0-Kom-
ponenten bestehen.
I4.0-Komponenten im Kontext dieses Dokuments
stehen für Produktionssysteme, Maschinen, Stationen
und konzeptuell wichtige Teile bzw. Baugruppen von
Maschinen.
Zu Merkmal (1): Identifizierbarkeit
Ziel des I4.0-Ansatzes ist es, auf alle relevanten Daten
in Echtzeit zugreifen zu können. Die I4.0-Komponen-
ten stellen einen wichtigen Teil einer gegenüber heute
erweiterten Infrastruktur dar. Dies gilt während der
gesamten Lebenszeit des Produktionssystems. I4.0-
Komponenten spielen also auch in allen I4.0-Wert-
schöpfungsketten [3] und allen ihren Wertschöpfungs-
prozessen eine zentrale Rolle für den durchgängigen
und einheitlichen Informationsaustausch.
Eine aktive I4.0-Komponente kann I4.0-konforme
Kommunikation selbst abwickeln; für eine passive
I4.0-Komponente erledigt dies die notwendige Infra-
struktur.
Es besteht die Notwendigkeit für eine den industriel-
len Anforderungen gerecht werdende Kommunikati-
on. Da Produktionssysteme immer mehr im Verbund
arbeiten und dabei auch größere Entfernungen über-
brückt werden müssen, wird die Verbindung lokaler
Netze mittels der Weitverkehrstechnik immer wichti-
ger.
Anforderung: Bei der Vernetzung von I4.0-Kom-
ponenten sollte sich die Weitverkehrstechnik so
verhalten, dass lokale Netze weitgehend ohne Ein-
schränkungen über die Weitverkehrsanbindung
miteinander kommunizieren können.
Dies betrifft die Verfügbarkeit solcher Verbindungen,
die Sicherheit (Security), aber auch das zeitgerechte
Verhalten. Wenngleich Streaming-Technologien und
andere Mechanismen eine Basis für passende Lösun-
gen darstellen könnten, sind hierzu noch grundlegen-
de Arbeiten erforderlich.
Eine Ebene höher müssen Verbindungen dafür sor-
gen, dass die Kommunikation zuverlässig und stabil
über einen langen Zeitraum garantiert ist. Hier sind
bestehende Protokolle auf ihre Tauglichkeit in I4.0-
Anwendungen zu prüfen. Zu unterscheiden ist die
Adressierung der I4.0-Komponente und die Adressie-
rung ihrer (Anwendungs-)Objekte. Diese werden
mittels einer weltweiten und herstellerübergreifenden
eineindeutigen ID angesprochen. Zum Umgang mit
IDs sei auf [5] und [6] und andere Standards verwie-
sen.
Anforderung: Zu unterscheiden ist die Adressie-
rung der I4.0-Komponente und die Adressierung
ihrer (Anwendungs-)Objekte.
Zu Merkmal (2): I4.0-konforme Kommunikation
Die Selbstauskunft einer I4.0-Komponente wird auf
Basis einer serviceorientierten Architektur (SOA) mit
Diensten entsprechend einem Dienstemodell realisiert
(Resource-Manager). Ein entsprechendes Profil der
I4.0-Komponente kann regeln, wie diese Dienste
technologisch realisiert werden können (z. B. über
OPC-UA-Basisdienste).
Zu Merkmal (3): I4.0-konforme Dienste und
Zustände
Da im „Shop floor“ und im „Office floor“ unter-
schiedliche Anwendungen bedient werden müssen,
muss die Option bestehen, dass I4.0-Komponenten die
verschiedenen
Anwendungsebenen mit unterschiedlichen Protokol-
len bedienen können.
Anforderung: Protokolle und Anwendungsfunkti-
onen sollen daher optional nachladbar sein.
Zu Merkmal (4): Virtuelle Beschreibung
Die Informationen zur Beschreibung der Eigenschaf-
ten einschließlich des relevanten dynamischen Ver-
haltens einer I4.0-Komponente werden aus dem virtu-
ellen Abbild der realen Komponente in einem I4.0-
Datenformat erzeugt. Dieses Abbild wird als „Virtuel-
le Repräsentation“ bezeichnet; Teil der Virtuellen
Repräsentation ist das Manifest, das mit einer eindeu-
tigen Semantik belegt sein muss. Dabei spielt die
Spezifikation von Merkmalen eine wichtige Rolle.
www.vdi.de
24 Referenzarchitekturmodell Industrie 4.0
Teile des Manifests sind beispielsweise:
 charakteristische Merkmale der realen
Komponente
 Informationen über Beziehungen der Merkmale
untereinander
 Produktions- und Produktionsprozess-relevante
Beziehungen zwischen I4.0-Komponenten
 formale Beschreibung relevanter Funktionen der
Maschine und ihrer Abläufe
Teile der Virtuellen Repräsentation sind beispiels-
weise:
 kaufmännische Daten
 historische Daten, z. B. Servicehistorie
 u. a. m.
Abgrenzung zwischen Manifest im Besonderen und
Verwaltungsobjekten im Allgemeinen ist, dass das
Manifest Informationen enthält, die für die Verwirkli-
chung eines „I4.0-konformen Netzwerks“ entspre-
chend den I4.0-Aspekten nach einer eindeutigen Se-
mantik öffentlich bekannt sein müssen. Verwaltungs-
objekte können auch solche Informationen tragen, bei
denen der Hersteller selbst entscheiden kann, was in
welcher Form er offenlegen möchte.
Zu Merkmal (5): I4.0-konforme Semantik
Der Informationsaustausch zwischen zwei oder meh-
reren I4.0-Komponenten erfordert eine eineindeutige
Semantik. Diese muss mittels der unter Merkmal (4)
aufgeführten Charakteristika I4.0-weit festgelegt
werden. Hilfreich erscheint nach [5] die Klassifikation
der Merkmale nach folgenden Feldern:
 Mechanik
 Funktionalität
 Örtlichkeit
 Leistungsfähigkeit
 geschäftliche Rahmenbedingungen
Zum Umgang mit Merkmalen sei auf [5], [6] und [7]
verwiesen.
Zu Merkmal (6): Security und Safety
Jede I4.0-Komponente weist eine Mindestinfrastruk-
tur zur Sicherstellung der Security-Funktionen auf. Da
Security nur sichergestellt ist, wenn die jeweiligen
Produktionsprozesse in die Security-Betrachtungen
unmittelbar einbezogen sind, stellt die Security-
Infrastruktur einer I4.0-Komponente zwar notwendi-
ge, aber bei Weitem nicht hinreichende Funktionalität
zur Verfügung. Muss die funktionale Sicherheit, Ma-
schinensicherheit (Safety) sichergestellt werden, so
hat dies Einfluss auf die Eigenschaften der einzelnen
I4.0-Komponenten. Zusätzliche Merkmale müssen
hier erfasst, bewertet und an übergeordnete Systeme
weiter gegeben werden
Anforderung: Die Mindestinfrastruktur muss den
Prinzipien von „Security-by-Design“ (SbD) gerecht
werden.
Zu Merkmal (7): Quality of Services
Die Anwendung einer I4.0-Komponente in einer be-
stimmten Umgebung bestimmt deren Anforderungen.
Die in der jeweiligen Umgebung geforderten Eigen-
schaften (QoS) müssen daher schon bei der Auswahl
der Komponenten für eine Maschine oder Anlage
berücksichtigt werden. Speziell für Automatisie-
rungsumgebungen sind das Eigenschaften wie:
 Zeitspanne der Echtzeit für die Produktivkommu-
nikation, z. B. Deterministik mit Echtzeitfähigkeit
von D1ms.
 höchste Ausfallsicherheit bezüglich der umgeben-
den Netzinfrastruktur (Robustheit)
 Uhrensynchronisation
 Interoperabilität
 Diagnose und Engineering auf Basis einheitlicher
Regeln
 Aufbau von Ad-hoc-Verbindungen
Zu Merkmal (8): Zustand
Da jede I4.0-Komponente Teil eines Verbunds mit
bestimmten Aufgaben darstellt und diese Aufgaben in
Prozessen koordiniert erledigt werden, muss der Zu-
stand jeder I4.0-Komponente zu jedem Zeitpunkt von
anderen Teilnehmern eines I4.0-konformen Kommu-
nikationsnetzwerks abrufbar sein. Diese Informatio-
nen dienen der lokalen Verwaltung anderer I4.0-Kom-
ponenten und der globalen Verwaltung zur Koordina-
tion der Abläufe.
www.vdi.de
Referenzarchitekturmodell Industrie 4.0 25
Zu Merkmal (9): Schachtelbarkeit
I4.0-Komponenten können zu einer I4.0-Komponente
zusammengefasst werden. So kann beispielsweise
eine Maschine sich als I4.0-Komponente darstellen.
Sie selbst kann aus eigenständigen I4.0-Komponenten
bestehen, z. B. eine modulare Maschine. Und auch die
einzelnen Maschinenmodule können wieder in einzel-
ne I4.0-Komponenten gegliedert werden.
2.5 Glossar Industrie 4.0
Im Rahmen von Industrie 4.0 wachsen die Sprachen
von Produktion und IKT (Informations- und Kommu-
nikationstechnologie) zusammen. Es existieren jedoch
historisch begründete Unterschiede und Unklarheiten
bei wichtigen Begriffen rund um Industrie 4.0. Die
Arbeitsgruppe „Begriffe“ im Fachausschuss 7.21
„Industrie 4.0“ der VDI/VDE-Gesellschaft Mess- und
Automatisierungstechnik (GMA) unter der Leitung
von Frau Dr.-Ing. Miriam Schleipen vom Fraunhofer
IOSB ist bemüht, eine gemeinsame „Basis“ (Termino-
logie) von Industrie 4.0 im Sinne sprachlicher und
gedanklicher Konstrukte zu erarbeiten. Die Arbeiten
erfolgen zudem in enger Zusammenarbeit mit den
zuständigen Komitees (z. B. DKE/UK 921.1) des
Fachbereichs 9 der DKE (z. B. DKE/UK 921.1). und
werden mit der AG2 „Referenzarchitektur“ der Platt-
form Industrie 4.0 abgestimmt.
Ziel ist ein gemeinsames Verständnis der grundlegen-
den Begriffe! Dabei wird auf bestehenden Normen
und Standards aus den Bereichen IKT und Produktion
aufgesetzt.
Im Umfeld von Industrie 4.0 werden Begrifflichkeiten
und Konzepte aus unterschiedlichen Domänen aufge-
griffen (etwa aus dem IKT-Bereich die Orchestrierung
von Diensten in einer serviceorientierten Umgebung).
Manche Begrifflichkeiten sind aber in den beteiligten
Domänen unterschiedlich besetzt (etwa Service
(Dienst) im IKT-Bereich gegenüber der Produktion).
Andere Begriffe sind sogar innerhalb einer Domäne
mehrdeutig oder unpräzise (etwa Komponente). Diese
sprachlichen und konzeptionellen Unterschiede und
Ungenauigkeiten sowie der Bedarf nach Erklärungen
zu „fachfremden Konzepten“ sind ein Hindernis in
der Entwicklung übergreifender komplexer techni-
scher Lösungen für Industrie 4.0 und in der Normung.
Mit dem Glossar wird also eine gemeinsame Basis für
Begrifflichkeiten im Rahmen von Industrie 4.0 ge-
schaffen werden, die die unterschiedlichen Sichtwei-
sen und Anforderungen berücksichtigt. Dies soll die
Zusammenarbeit über die Grenzen von Unternehmen
und Branchen hinweg erleichtern und ist Vorausset-
zung für die Normung.
Die aktuellen Definitionen sind u. a. auf folgender
Webseite zu finden:
www.iosb.fraunhofer.de/?BegriffeI40
www.vdi.de
26 Referenzarchitekturmodell Industrie 4.0
Autoren
Dr. Peter Adolphs (Pepperl+Fuchs)
Dr. Heinz Bedenbender (VDI)
Dr. Dagmar Dirzus (VDI)
Martin Ehlich (Lenze SE)
Prof. Ulrich Epple (RWTH Aachen)
Martin Hankel (Bosch Rexroth AG)
Roland Heidel (Siemens AG)
Dr. Michael Hoffmeister (Festo AG & Co.KG)
Haimo Huhle (ZVEI)
Bernd Kärcher (Festo AG & Co.KG)
Dr. Heiko Koziolek (ABB)
Reinhold Pichler (DKE)
Stefan Pollmeier (ESR Pollmeier)
Frank Schewe (Phoenix Contact)
Dr. Armin Walter (Lenze)
Bernd Waser (Murrelektronik)
Prof. Dr. Martin Wollschlaeger (TU Dresden)
Schrifttum
[1] VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik: Statusbericht; Industrie 4.0; Wertschöpfungsketten. Düssel-
dorf: VDI e.V., April 2014
[2] VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik: Statusbericht; Industrie 4.0; Auf dem Weg zu einem Refe-
renzmodell. Düsseldorf: VDI e.V., April 2014
[3] VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik: Statusbericht; Industrie 4.0; Gegenstände, Entitäten, Kompo-
nenten. Düsseldorf: VDI e.V., April 2014
[4] Acatech Studie, Umsetzungsempfehlungen für das Zukunftsprojekt Industrie 4.0, Abschlussbericht des Arbeitskreises In-
dustrie 4.0. http://www.bmbf.de/pubRD/Umsetzungsempfehlungen_Industrie4_0.pdf
[5] IEC TR 62794: Industrial-process measurement, control and automation – Reference model for representation of production
facilities (Digital Factory), 2012
[6] IEC CD 62832: Industrial-process measurement, control and automation - Reference model for representation of production
facilities (Digital Factory), 2014
[7] IEC 61987-10: Industrial-process measurement and control - Data structures and elements in process equipment catalogues -
Part 10: Lists of properties (LOPs) for industrial-process measurement and control for electronic data exchange - Funda-
mentals, 2009
www.vdi.de
Referenzarchitekturmodell Industrie 4.0 27
Der VDI
Sprecher, Gestalter, Netzwerker
Ingenieure brauchen eine starke Vereinigung, die sie bei ihrer Arbeit unterstützt, fördert und vertritt. Diese Aufgabe
übernimmt der VDI Verein Deutscher Ingenieure e.V. Seit über 150 Jahren steht er Ingenieurinnen und Ingenieuren
zuverlässig zur Seite. Mehr als 12.000 ehrenamtliche Experten bearbeiten jedes Jahr neueste Erkenntnisse zur
Förderung unseres Technikstandorts. Das überzeugt: Mit rund 154.000 Mitgliedern ist der VDI die größte Ingenieur-
vereinigung Deutschlands.
Über den ZVEI
Der ZVEI – Zentralverband Elektrotechnik- und Elektronikindustrie e.V.
Der ZVEI vertritt die Interessen von 1.600 Unternehmen der Elektroindustrie und zugehöriger Dienstleistungsunter-
nehmen in Deutschland. Jede dritte Neuerung im Verarbeitenden Gewerbe in Deutschland erfährt ihren originären
Anstoß aus der Elektroindustrie. Die Branche beschäftigt 850.000 Arbeitnehmer im Inland und weitere 690.000
weltweit.
www.vdi.de
Verein Deutscher Ingenieure e.V.
VDI/VDE-Gesellschaft Mess- und
Automatisierungstechnik
Dr.-Ing. Dagmar Dirzus
Geschäftsführerin
VDI-Platz 1
40468 Düsseldorf
Tel. +49 211 6214-227
dirzus@vdi.de
www.vdi.de
ZVEI – Zentralverband Elektrotechnik und
Elektronikindustrie e.V.
Fachverband Automation
Dipl.-Ing. Gunther Koschnick
Geschäftsführer
Lyoner Straße 9
60528 Frankfurt am Main
Tel. +49 69-6302-318
koschnick@zvei.org
http://www.zvei.de

Weitere ähnliche Inhalte

Was ist angesagt?

Programmer dans Openrefine avec GREL
Programmer dans Openrefine avec GRELProgrammer dans Openrefine avec GREL
Programmer dans Openrefine avec GRELMathieu Saby
 
Découvrez OpenRefine: un outil gratuit pour nettoyer, préparer et enrichir vo...
Découvrez OpenRefine: un outil gratuit pour nettoyer, préparer et enrichir vo...Découvrez OpenRefine: un outil gratuit pour nettoyer, préparer et enrichir vo...
Découvrez OpenRefine: un outil gratuit pour nettoyer, préparer et enrichir vo...Mathieu Saby
 
A Point of View for PIM in Retail, CPG and Distribution Companies
A Point of View for PIM in Retail, CPG and Distribution CompaniesA Point of View for PIM in Retail, CPG and Distribution Companies
A Point of View for PIM in Retail, CPG and Distribution CompaniesShamanth Shankar
 
JPL’s Institutional Knowledge Graph II: A Foundation for Constructing Enterpr...
JPL’s Institutional Knowledge Graph II: A Foundation for Constructing Enterpr...JPL’s Institutional Knowledge Graph II: A Foundation for Constructing Enterpr...
JPL’s Institutional Knowledge Graph II: A Foundation for Constructing Enterpr...Enterprise Knowledge
 
Slides-for-Benefits-for-Finance-moving-from-ECC-to-S4HANA-Final.pdf
Slides-for-Benefits-for-Finance-moving-from-ECC-to-S4HANA-Final.pdfSlides-for-Benefits-for-Finance-moving-from-ECC-to-S4HANA-Final.pdf
Slides-for-Benefits-for-Finance-moving-from-ECC-to-S4HANA-Final.pdfAlexYuniarto1
 
SAP BusinessObjects Private Cloud Edition (PCE)
SAP BusinessObjects Private Cloud Edition (PCE)SAP BusinessObjects Private Cloud Edition (PCE)
SAP BusinessObjects Private Cloud Edition (PCE)Wiiisdom
 
Introduction to Apache NiFi 1.11.4
Introduction to Apache NiFi 1.11.4Introduction to Apache NiFi 1.11.4
Introduction to Apache NiFi 1.11.4Timothy Spann
 
SAP BW Reports - Copy
SAP BW Reports - CopySAP BW Reports - Copy
SAP BW Reports - CopyAby m
 
HL7 FHIR For Medical Professionals.pdf
HL7 FHIR For Medical Professionals.pdfHL7 FHIR For Medical Professionals.pdf
HL7 FHIR For Medical Professionals.pdfJanaka Peiris
 
Fhir basics session 1 Introduction to Interoperabilty & Principles of FHIR
Fhir basics session 1 Introduction to Interoperabilty & Principles of FHIRFhir basics session 1 Introduction to Interoperabilty & Principles of FHIR
Fhir basics session 1 Introduction to Interoperabilty & Principles of FHIRKumar Satyam
 
CIDOC CRM Tutorial
CIDOC CRM TutorialCIDOC CRM Tutorial
CIDOC CRM TutorialISLCCIFORTH
 
Fifth Elephant Apache Atlas Talk
Fifth Elephant Apache Atlas TalkFifth Elephant Apache Atlas Talk
Fifth Elephant Apache Atlas TalkVimal Sharma
 
How to migrate from Lotus Notes to SharePoint 2013 or SharePoint Online
How to migrate from Lotus Notes to SharePoint 2013 or SharePoint OnlineHow to migrate from Lotus Notes to SharePoint 2013 or SharePoint Online
How to migrate from Lotus Notes to SharePoint 2013 or SharePoint OnlineKnut Relbe-Moe [MVP, MCT]
 
Incrementally streaming rdbms data to your data lake automagically
Incrementally streaming rdbms data to your data lake automagicallyIncrementally streaming rdbms data to your data lake automagically
Incrementally streaming rdbms data to your data lake automagicallyTimothy Spann
 
fhir and loinc
fhir and loincfhir and loinc
fhir and loincDevDays
 

Was ist angesagt? (20)

Programmer dans Openrefine avec GREL
Programmer dans Openrefine avec GRELProgrammer dans Openrefine avec GREL
Programmer dans Openrefine avec GREL
 
Cerner ppt
Cerner pptCerner ppt
Cerner ppt
 
Découvrez OpenRefine: un outil gratuit pour nettoyer, préparer et enrichir vo...
Découvrez OpenRefine: un outil gratuit pour nettoyer, préparer et enrichir vo...Découvrez OpenRefine: un outil gratuit pour nettoyer, préparer et enrichir vo...
Découvrez OpenRefine: un outil gratuit pour nettoyer, préparer et enrichir vo...
 
A Point of View for PIM in Retail, CPG and Distribution Companies
A Point of View for PIM in Retail, CPG and Distribution CompaniesA Point of View for PIM in Retail, CPG and Distribution Companies
A Point of View for PIM in Retail, CPG and Distribution Companies
 
JPL’s Institutional Knowledge Graph II: A Foundation for Constructing Enterpr...
JPL’s Institutional Knowledge Graph II: A Foundation for Constructing Enterpr...JPL’s Institutional Knowledge Graph II: A Foundation for Constructing Enterpr...
JPL’s Institutional Knowledge Graph II: A Foundation for Constructing Enterpr...
 
Slides-for-Benefits-for-Finance-moving-from-ECC-to-S4HANA-Final.pdf
Slides-for-Benefits-for-Finance-moving-from-ECC-to-S4HANA-Final.pdfSlides-for-Benefits-for-Finance-moving-from-ECC-to-S4HANA-Final.pdf
Slides-for-Benefits-for-Finance-moving-from-ECC-to-S4HANA-Final.pdf
 
SAP BusinessObjects Private Cloud Edition (PCE)
SAP BusinessObjects Private Cloud Edition (PCE)SAP BusinessObjects Private Cloud Edition (PCE)
SAP BusinessObjects Private Cloud Edition (PCE)
 
Introduction to Apache NiFi 1.11.4
Introduction to Apache NiFi 1.11.4Introduction to Apache NiFi 1.11.4
Introduction to Apache NiFi 1.11.4
 
SAP BW Reports - Copy
SAP BW Reports - CopySAP BW Reports - Copy
SAP BW Reports - Copy
 
HL7 FHIR For Medical Professionals.pdf
HL7 FHIR For Medical Professionals.pdfHL7 FHIR For Medical Professionals.pdf
HL7 FHIR For Medical Professionals.pdf
 
1 3 introduction to open_ehr
1 3 introduction to open_ehr1 3 introduction to open_ehr
1 3 introduction to open_ehr
 
Fhir basics session 1 Introduction to Interoperabilty & Principles of FHIR
Fhir basics session 1 Introduction to Interoperabilty & Principles of FHIRFhir basics session 1 Introduction to Interoperabilty & Principles of FHIR
Fhir basics session 1 Introduction to Interoperabilty & Principles of FHIR
 
CIDOC CRM Tutorial
CIDOC CRM TutorialCIDOC CRM Tutorial
CIDOC CRM Tutorial
 
Fifth Elephant Apache Atlas Talk
Fifth Elephant Apache Atlas TalkFifth Elephant Apache Atlas Talk
Fifth Elephant Apache Atlas Talk
 
An Introduction to HL7 FHIR
An Introduction to HL7 FHIRAn Introduction to HL7 FHIR
An Introduction to HL7 FHIR
 
How to migrate from Lotus Notes to SharePoint 2013 or SharePoint Online
How to migrate from Lotus Notes to SharePoint 2013 or SharePoint OnlineHow to migrate from Lotus Notes to SharePoint 2013 or SharePoint Online
How to migrate from Lotus Notes to SharePoint 2013 or SharePoint Online
 
Incrementally streaming rdbms data to your data lake automagically
Incrementally streaming rdbms data to your data lake automagicallyIncrementally streaming rdbms data to your data lake automagically
Incrementally streaming rdbms data to your data lake automagically
 
xAPI Application Profile for Serious Games
xAPI Application Profile for Serious GamesxAPI Application Profile for Serious Games
xAPI Application Profile for Serious Games
 
fhir and loinc
fhir and loincfhir and loinc
fhir and loinc
 
[DE] DMS: Ist-Analyse und Auswertung von Analysen | Dr. Ulrich Kampffmeyer | ...
[DE] DMS: Ist-Analyse und Auswertung von Analysen | Dr. Ulrich Kampffmeyer | ...[DE] DMS: Ist-Analyse und Auswertung von Analysen | Dr. Ulrich Kampffmeyer | ...
[DE] DMS: Ist-Analyse und Auswertung von Analysen | Dr. Ulrich Kampffmeyer | ...
 

Andere mochten auch

Industrie 4.0 Referenzmodell 2014
Industrie 4.0 Referenzmodell 2014Industrie 4.0 Referenzmodell 2014
Industrie 4.0 Referenzmodell 2014Martin Gutberlet
 
Io t standardization jan2015 mg strategy
Io t standardization jan2015 mg strategyIo t standardization jan2015 mg strategy
Io t standardization jan2015 mg strategyMartin Gutberlet
 
Reshaping IT - Reshaping Business
Reshaping IT - Reshaping BusinessReshaping IT - Reshaping Business
Reshaping IT - Reshaping BusinessMartin Gutberlet
 
M2M Journal Issue 24 December 2014
M2M Journal Issue 24 December 2014M2M Journal Issue 24 December 2014
M2M Journal Issue 24 December 2014Martin Gutberlet
 

Andere mochten auch (8)

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

Ähnlich wie Referenzmodell Industrie 4.0 - VDI

Industrie 4.0
Industrie 4.0Industrie 4.0
Industrie 4.0GESIS
 
Dipl.-Kfm. Alexander Rehn (T&O Unternehmensberatung)
Dipl.-Kfm. Alexander Rehn (T&O Unternehmensberatung)Dipl.-Kfm. Alexander Rehn (T&O Unternehmensberatung)
Dipl.-Kfm. Alexander Rehn (T&O Unternehmensberatung)Praxistage
 
Mehrwert durch Konnektivität und Interoperabilität - Interview technik report...
Mehrwert durch Konnektivität und Interoperabilität - Interview technik report...Mehrwert durch Konnektivität und Interoperabilität - Interview technik report...
Mehrwert durch Konnektivität und Interoperabilität - Interview technik report...Thomas Schulz
 
Thomas Schulz: Industrie 4.0 – Blaupause der digitalen Transformation In: ope...
Thomas Schulz: Industrie 4.0 – Blaupause der digitalen Transformation In: ope...Thomas Schulz: Industrie 4.0 – Blaupause der digitalen Transformation In: ope...
Thomas Schulz: Industrie 4.0 – Blaupause der digitalen Transformation In: ope...Thomas Schulz
 
EMC Lösungen für das Internet der Dinge und Industrie 4.0 (Handout DE) <<< OU...
EMC Lösungen für das Internet der Dinge und Industrie 4.0 (Handout DE) <<< OU...EMC Lösungen für das Internet der Dinge und Industrie 4.0 (Handout DE) <<< OU...
EMC Lösungen für das Internet der Dinge und Industrie 4.0 (Handout DE) <<< OU...Dell Technologies
 
PLM Open Hours - Was bedeutet Industrie 4.0 für das PLM
PLM Open Hours - Was bedeutet Industrie 4.0 für das PLMPLM Open Hours - Was bedeutet Industrie 4.0 für das PLM
PLM Open Hours - Was bedeutet Industrie 4.0 für das PLMIntelliact AG
 
Umsetzungsempfehlungen industrie 4.0_final_2012-10-02
Umsetzungsempfehlungen industrie 4.0_final_2012-10-02Umsetzungsempfehlungen industrie 4.0_final_2012-10-02
Umsetzungsempfehlungen industrie 4.0_final_2012-10-02FESD GKr
 
Industrie 4.0 vs Industrie 3.0
Industrie 4.0 vs Industrie 3.0Industrie 4.0 vs Industrie 3.0
Industrie 4.0 vs Industrie 3.0JalalHammari
 
Industrie 4.0 und Facility Management - was bedeutet das?
Industrie 4.0 und Facility Management - was bedeutet das?Industrie 4.0 und Facility Management - was bedeutet das?
Industrie 4.0 und Facility Management - was bedeutet das?dankl+partner consulting gmbh
 
PLM Open Hours - Industrie 4.0 – so beginnen sie heute
PLM Open Hours - Industrie 4.0 – so beginnen sie heutePLM Open Hours - Industrie 4.0 – so beginnen sie heute
PLM Open Hours - Industrie 4.0 – so beginnen sie heuteIntelliact AG
 
Das Internet der Dinge – Was bedeutet dies für PLM?
Das Internet der Dinge – Was bedeutet dies für PLM?Das Internet der Dinge – Was bedeutet dies für PLM?
Das Internet der Dinge – Was bedeutet dies für PLM?Intelliact AG
 
Industrie 4.0-gps-whitepaper-2016-3
Industrie 4.0-gps-whitepaper-2016-3Industrie 4.0-gps-whitepaper-2016-3
Industrie 4.0-gps-whitepaper-2016-3Linda Held
 
Iot - IIot - Industrie 4.0 - What it means?
Iot - IIot - Industrie 4.0 - What it means?Iot - IIot - Industrie 4.0 - What it means?
Iot - IIot - Industrie 4.0 - What it means?Reinhard Riepl
 
MES Kompakt - Manufacturing Execution Systems im Zeitalter von Industrie 4.0 ...
MES Kompakt - Manufacturing Execution Systems im Zeitalter von Industrie 4.0 ...MES Kompakt - Manufacturing Execution Systems im Zeitalter von Industrie 4.0 ...
MES Kompakt - Manufacturing Execution Systems im Zeitalter von Industrie 4.0 ...Filipe Felix
 
Industrie 4.0 - Grundlagen, Experteninterviews und Pioniere
Industrie 4.0 - Grundlagen, Experteninterviews und PioniereIndustrie 4.0 - Grundlagen, Experteninterviews und Pioniere
Industrie 4.0 - Grundlagen, Experteninterviews und PioniereFLYACTS GmbH
 

Ähnlich wie Referenzmodell Industrie 4.0 - VDI (20)

Industrie 4.0
Industrie 4.0Industrie 4.0
Industrie 4.0
 
Dipl.-Kfm. Alexander Rehn (T&O Unternehmensberatung)
Dipl.-Kfm. Alexander Rehn (T&O Unternehmensberatung)Dipl.-Kfm. Alexander Rehn (T&O Unternehmensberatung)
Dipl.-Kfm. Alexander Rehn (T&O Unternehmensberatung)
 
Mehrwert durch Konnektivität und Interoperabilität - Interview technik report...
Mehrwert durch Konnektivität und Interoperabilität - Interview technik report...Mehrwert durch Konnektivität und Interoperabilität - Interview technik report...
Mehrwert durch Konnektivität und Interoperabilität - Interview technik report...
 
Thomas Schulz: Industrie 4.0 – Blaupause der digitalen Transformation In: ope...
Thomas Schulz: Industrie 4.0 – Blaupause der digitalen Transformation In: ope...Thomas Schulz: Industrie 4.0 – Blaupause der digitalen Transformation In: ope...
Thomas Schulz: Industrie 4.0 – Blaupause der digitalen Transformation In: ope...
 
EMC Lösungen für das Internet der Dinge und Industrie 4.0 (Handout DE) <<< OU...
EMC Lösungen für das Internet der Dinge und Industrie 4.0 (Handout DE) <<< OU...EMC Lösungen für das Internet der Dinge und Industrie 4.0 (Handout DE) <<< OU...
EMC Lösungen für das Internet der Dinge und Industrie 4.0 (Handout DE) <<< OU...
 
PLM Open Hours - Was bedeutet Industrie 4.0 für das PLM
PLM Open Hours - Was bedeutet Industrie 4.0 für das PLMPLM Open Hours - Was bedeutet Industrie 4.0 für das PLM
PLM Open Hours - Was bedeutet Industrie 4.0 für das PLM
 
Umsetzungsempfehlungen industrie 4.0_final_2012-10-02
Umsetzungsempfehlungen industrie 4.0_final_2012-10-02Umsetzungsempfehlungen industrie 4.0_final_2012-10-02
Umsetzungsempfehlungen industrie 4.0_final_2012-10-02
 
Industrie 4.0 vs Industrie 3.0
Industrie 4.0 vs Industrie 3.0Industrie 4.0 vs Industrie 3.0
Industrie 4.0 vs Industrie 3.0
 
VDC Newsletter 2008-02
VDC Newsletter 2008-02VDC Newsletter 2008-02
VDC Newsletter 2008-02
 
Industrie 4.0 und Facility Management - was bedeutet das?
Industrie 4.0 und Facility Management - was bedeutet das?Industrie 4.0 und Facility Management - was bedeutet das?
Industrie 4.0 und Facility Management - was bedeutet das?
 
PLM Open Hours - Industrie 4.0 – so beginnen sie heute
PLM Open Hours - Industrie 4.0 – so beginnen sie heutePLM Open Hours - Industrie 4.0 – so beginnen sie heute
PLM Open Hours - Industrie 4.0 – so beginnen sie heute
 
Das Internet der Dinge – Was bedeutet dies für PLM?
Das Internet der Dinge – Was bedeutet dies für PLM?Das Internet der Dinge – Was bedeutet dies für PLM?
Das Internet der Dinge – Was bedeutet dies für PLM?
 
VDC Newsletter 2010-05
VDC Newsletter 2010-05VDC Newsletter 2010-05
VDC Newsletter 2010-05
 
Industrie 4.0-gps-whitepaper-2016-3
Industrie 4.0-gps-whitepaper-2016-3Industrie 4.0-gps-whitepaper-2016-3
Industrie 4.0-gps-whitepaper-2016-3
 
Iot - IIot - Industrie 4.0 - What it means?
Iot - IIot - Industrie 4.0 - What it means?Iot - IIot - Industrie 4.0 - What it means?
Iot - IIot - Industrie 4.0 - What it means?
 
VDC Newsletter 2008-10
VDC Newsletter 2008-10VDC Newsletter 2008-10
VDC Newsletter 2008-10
 
MES Kompakt - Manufacturing Execution Systems im Zeitalter von Industrie 4.0 ...
MES Kompakt - Manufacturing Execution Systems im Zeitalter von Industrie 4.0 ...MES Kompakt - Manufacturing Execution Systems im Zeitalter von Industrie 4.0 ...
MES Kompakt - Manufacturing Execution Systems im Zeitalter von Industrie 4.0 ...
 
Industrie 4.0 - Grundlagen, Experteninterviews und Pioniere
Industrie 4.0 - Grundlagen, Experteninterviews und PioniereIndustrie 4.0 - Grundlagen, Experteninterviews und Pioniere
Industrie 4.0 - Grundlagen, Experteninterviews und Pioniere
 
Productronica tageszeitung tag4
Productronica tageszeitung tag4Productronica tageszeitung tag4
Productronica tageszeitung tag4
 
VDC Newsletter 2009-02
VDC Newsletter 2009-02VDC Newsletter 2009-02
VDC Newsletter 2009-02
 

Mehr von Martin Gutberlet

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

Mehr von Martin Gutberlet (10)

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

Referenzmodell Industrie 4.0 - VDI

  • 3. Vorwort Der Einzug von Technologien aus der Welt des Inter- nets in die Fertigungsautomation ist nicht mehr auf- zuhalten. Vielfach mit dem Begriff „4. Industrielle Revolution“ oder „Industrie 4.0“ bezeichnet, hat sich in den Medien ein regelrechter Hype um das Thema ergeben. Aufgabe der Plattform Industrie 4.0, in der sich Vertreter von Automatisierungsindustrie, Ma- schinenbau und der ITK-Branche zusammengetan haben, wird seit einigen Monaten intensiv an der Konkretisierung der Ideen gearbeitet. Ein wesentli- ches Element war dabei die Entwicklung einer Refe- renzarchitektur durch die Arbeitsgruppe 2 (AG2) der Plattform Industrie 4.0. Um eine möglichst breite Basis für diese Überlegungen zu legen, haben die AG2, der Fachausschuss 7.21 „Industrie 4.0“ der VDI/VDE-Gesellschaft Mess- und Automatisierungs- technik (GMA) und die Arbeitsgruppe SG2 des ZVEI eng zusammengearbeitet und ein gemeinsames Papier erstellt, das hier in Auszügen veröffentlicht wird. Die dargestellten Ergebnisse basieren auf einem breiten Konsens in den diversen Industriebranchen, aber auch in der Wissenschaft. Insofern darf davon ausgegangen werden, dass darauf für die nächsten Schritte aufge- baut werden kann. Düsseldorf, im April 2015 Dr.-Ing. Peter Adolphs Sprecher der AG2 in der Plattform Industrie 4.0 Mitglied des Vorstands der VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik (GMA) Mitglied der SG2 im ZVEI Prof. Dr. Ulrich Epple Leiter des Fachausschusses 7.21 „Industrie 4.0“ der VDI/VDE-Gesellschaft Mess- und Automatisierungs- technik (GMA) Vorsitzender des Steuerkreises Industrie 4.0 der DKE Mitglied der SG2 im ZVEI www.vdi.de
  • 5. Referenzarchitekturmodell Industrie 4.0 3 Inhalt Vorwort 1 1 Zusammenfassung 4 2 Referenzarchitektur 5 2.1 Konsens der Verbände 5 2.2 Einleitung 5 2.3 Referenzarchitekturmodell Industrie 4.0 (RAMI4.0) 6 2.4 Referenzmodell für die I4.0-Komponente 11 2.5 Glossar Industrie 4.0 25 Autoren 26 Schrifttum 26 www.vdi.de
  • 6. 4 Referenzarchitekturmodell Industrie 4.0 1 Zusammenfassung Physische und virtuelle Welt wachsen zunehmend zusammen. Immer mehr physische Objekte verfügen über intelligente Sensor- und Aktortechnologie und werden durch die evolutionäre Entwicklung des Inter- nets der Dinge vernetzt. Die Verfügbarkeit aller rele- vanten Informationen in Echtzeit mittels Vernetzung aller an der Wertschöpfung beteiligten Instanzen sowie die Fähigkeit, aus den Daten den zu jedem Zeitpunkt optimalen Wertschöpfungsfluss abzuleiten, löst eine neue weitere industrielle Revolution (als Industrie 4.0 bezeichnet) in den Geschäftsprozessen aus und ermöglicht neue Geschäftsmodelle. Dabei steht die Optimierung der folgenden industriellen Kernprozesse im Fokus: Forschung & Entwicklung, Produktion, Logistik und Service. Um die Zukunftsfähigkeit des Standorts Deutschland und seiner Industrie abzusichern, wurden durch die Plattform Industrie 4.0 in Zusammenarbeit der Ver- bände BITKOM, VDMA, ZVEI und den Unterneh- men der Deutschen Industrie die Umsetzungsstrategie Industrie 4.0 erarbeitet. Das Kapitel 6 der Umset- zungsstrategie Industrie 4.0 wurde von vornherein so konzipiert, dass es extrahiert und als GMA-Statusre- port veröffentlicht werden kann. Das Ergebnis liegt Ihnen hier vor. In diesem VDI-Statusreport wird ein Referenzarchi- tekturmodell für semantische Technologien und deren Nutzen für die Automatisierung und ihr zugeordneten relevanten Technologien vorgestellt (RAMI4.0). Da- rin werden auch der Aufbau und die Arbeitsweise von sogenannten Industrie-4.0-Komponenten (im Folgen- den I4.0-Komponenten genannt) beschrieben. Wo es sinnvoll ist, setzen Teile des Referenzarchitekturmo- dells und der I4.0-Komponenten auf bestehende und relevante Normen auf, um schneller handlungsfähig zu sein. Wo notwendig, wurden in der Umsetzungs- strategie zusätzliche identifizierte Standardisierungs- bedarfe identifiziert und beschrieben. Aufgrund der zunehmenden Vernetzung und Steuer- barkeit von physischen Objekten und der gleichzeitig steigenden Bedrohungslage durch Hacker, Geheim- dienste, Spionage usw. sind besondere Sicherheitsan- forderungen erforderlich. Diese werden im Kapitel 7 der Umsetzungsstrategie Industrie 4.0 umrissen. Der Statusreport wendet sich an Leser aus der Deut- schen Industrie, den relevanten technologieorientier- ten Branchen, der Forschung und der Politik. Im Be- sonderen sind Führungskräfte, Fachkräfte und Berater angesprochen sowie alle Personen, die an einem dem Zukunftsbild der Industrie 4.0 in Deutschland interes- siert sind oder dieses mitgestalten wollen. www.vdi.de
  • 7. Referenzarchitekturmodell Industrie 4.0 5 2 Referenzarchitektur 2.1 Konsens der Verbände Die hier beschriebene Referenzarchitektur für Indus- trie 4.0 ist das Ergebnis der Kooperation mehrerer Institutionen. Insbesondere haben Experten der Fach- ausschüsse 7.21 „Industrie 4.0“ und 7.20 „Cyber- Physical Systems“ der VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik (GMA) zu den Ergeb- nissen beigetragen. Vorarbeiten sind die bislang ver- öffentlichten fünf Statusreports, die ebenso wie dieser und der neue Report zu „IT-Security auf dem Weg zur Industrie 4.0“ unter www.vdi.de/industrie40 kosten- frei zum Download zur Verfügung stehen. Der vorlie- gende Statusreport ist in Kooperation mit dem Spie- gelgremium SG2 des ZVEI entstanden, das inhaltlich das hier beschriebene Modell vorangebracht hat. Auch die DKE (Deutsche Kommission Elektrotech- nik) wurde in alle Arbeiten einbezogen. Damit fiel der AG2 der Plattform Industrie 4.0 primär die Rolle der Koordination der Aktivitäten in den zahlreichen Untergremien und die Sicherstellung einer konsistenten Linie zu. So hat die Plattform ihrer zugedachten Aufgabe, ein konzertiertes Vorgehen unterschiedlichster Organisationen und Verbände sicherzustellen, entsprochen. Die nachfolgend vorge- stellten, breit getragenen Ergebnisse sind damit ein wichtiger Schritt zur Wahrung der Wettbewerbsfähig- keit der deutschen Industrie. 2.2 Einleitung Einer der grundlegenden Gedanken zur Referenzar- chitektur von Industrie 4.0 ist das Zusammenführen unterschiedlichster Aspekte in einem gemeinsamen Modell. Die vertikale Integration innerhalb der Fabrik beschreibt die Vernetzung von Produktionsmitteln z. B. von Automatisierungsgeräten oder Diensten untereinander. Als neuer Aspekt kommt bei Indus- trie 4.0 die Einbeziehung des Produkts bzw. Werk- stücks hinzu. Das zugehörige Modell muss dies reflektieren. Doch Industrie 4.0 geht noch deutlich weiter. Mit durchgängigem Engineering über die ganze Wertschöpfungskette ist gemeint, dass techni- sche, administrative und kommerzielle Daten, die rund um ein Produktionsmittel oder auch das Werk- stück entstehen, über die komplette Wertschöpfungs- kette konsistent gehalten werden und jederzeit über das Netzwerk zugreifbar sind. Ein dritter Aspekt bei Industrie 4.0 ist die horizontale Integration über Wert- schöpfungsnetzwerke, die über den einzelnen Fab- rikstandort hinausgeht und die dynamische Bildung von Wertschöpfungsnetzwerken ermöglicht. Die Aufgabe, diese Aspekte in einem Modell darzu- stellen, war zu lösen. Schließlich sollen Regelkreise mit Abtastungen im Millisekundentakt die dynami- sche Kooperation mehrerer Fabriken untereinander innerhalb eines gemeinsamen Wertschöpfungsnetz- werks mit zusätzlichen kommerziellen Fragestellun- gen in einem Modell darstellbar sein. Hier galt es, die Sichtweisen aus den unterschiedlichen Anwendungs- domänen zu verstehen, das Wesentliche zu erfassen und in einem gemeinsamen Modell zu vereinen. Bevor die eigentlichen Arbeiten zum Referenzarchi- tekturmodell RAMI4.0 begonnen werden konnten, war es daher notwendig, einen Überblick über vor- handene Ansätze und Methoden zu gewinnen. Schnell wurde klar, dass es bereits eine Reihe existierender und nutzbarer Ansätze gibt, die allerdings in der Re- gel nur Teilaspekte der oben beschriebenen ganzheit- lichen Sicht auf Industrie 4.0 adressieren. Im Einzel- nen wurden folgende Ansätze näher betrachtet:  Ansatz für die Realisierung eines Communication Layers ‒ OPC UA: Basis IEC 62541  Ansatz für die Realisierung des Information Layers ‒ IEC Common Data Dictionary (IEC 61360 Series/ISO13584-42) ‒ Merkmale, Klassifikation und Werkzeuge nach eCl@ss ‒ Electronic Device Description (EDD) ‒ Field Device Tool (FDT)  Ansatz für die Realisierung von Functional und Information Layer ‒ Field Device Integration (FDI) als Integrati- onstechnologie  Ansatz für das durchgängige Engineering ‒ AutomationML ‒ ProSTEP iViP ‒ eCl@ss (Merkmale) Im ersten Schritt ging es dabei um die grundsätzliche Prüfung, ob diese Ansätze zum im Kapitel 2.3 vorge- stellten Referenzarchitekturmodell passen. Dies wird grundsätzlich bejaht, allerdings bedürfen die betrach- teten Konzepte und Methoden noch detaillierteren Betrachtungen. www.vdi.de
  • 8. 6 Referenzarchitekturmodell Industrie 4.0 2.3 Referenzarchitekturmodell Industrie 4.0 (RAMI4.0) In der Diskussion über Industrie 4.0 kommen ganz unterschiedliche Interessen zusammen. Branchen von Prozess- bis Fabrikautomation mit unterschiedlichsten Standards, die Technologien der Informations- und Kommunikationstechnik und die Automatisierungs- technik, die Verbände Bitkom, VDMA, ZVEI und VDI sowie die Normungsorganisationen IEC und ISO mit ihren nationalen Spiegelgremien DKE und DIN. Zum Zweck eines gemeinsamen Verständnisses, wel- che Standards, Use Cases, Normen, usw. für Indus- trie 4.0 notwendig sind, entstand die Notwendigkeit, ein einheitliches Architekturmodell als Referenz zu entwickeln, anhand dessen Zusammenhänge und Details diskutiert werden können. Das Ergebnis ist das Referenzarchitekturmodell In- dustrie 4.0 (RAMI4.0), siehe Bild 1. Es beinhaltet die wesentlichen Aspekte aus Industrie 4.0. Es ergänzt die Hierarchiestufen aus IEC 62264 am unteren Ende um die Stufe des Produkts bzw. Werk- stücks („Product“) und am oberen Ende über die ein- zelne Fabrik hinaus um die „Connected World“. Die waagrechte Achse dient der Darstellung des Lebens- zyklus von Anlagen bzw. Produkten, wobei auch der Aspekt der Unterscheidung zwischen Typ und Instanz abgebildet wird. Über die sechs Layer wird schluss- endlich die IT-Repräsentanz einer I4.0-Komponente strukturiert beschrieben. Somit sind die besonderen Charakteristika des Refe- renzarchitekturmodells die Kombination von Lebens- zyklus und Wertschöpfungskette mit einem hierar- chisch strukturierten Ansatz für die Definition von I4.0-Komponenten. Damit ist ein Höchstmaß an Fle- xibilität zur Beschreibung einer I4.0-Umgebung ge- geben. Der Ansatz erlaubt auch die sinnvolle Kapse- lung von Funktionalitäten. Somit sind die Voraussetzungen geschaffen mittels des Referenzarchitekturmodells hoch flexible Kon- zepte zu beschreiben und zu realisieren. Dabei erlaubt das Modell die schrittweise Migration aus der heuti- gen in die I4.0-Welt und die Definition von Anwen- dungsdomänen mit speziellen Vorgaben und Anforde- rungen. Das Referenzarchitekturmodell RAMI4.0 wird als DIN SPEC 91345 der Standardisierung zugeführt. 2.3.1 Anforderungen und Ziele Ziele Industrie 4.0 ist eine Spezialisierung des „Internet of Things and Services“. Es sind ca. 15 Branchen in die Überlegungen einzubeziehen. Mit dem Referenzarchi- tekturmodell können Aufgaben und Abläufe in über- schaubare Teile zerlegt werden. Es soll einen Sach- verhalt so anschaulich machen, dass eine zielgerichte- te Diskussion z. B. bezüglich Standardisierung und Normung möglich wird. Es sollen also auch die infra- ge kommenden vorhandenen Standards und Normen verortet werden können, damit sichtbar wird, wo eventuell noch Erweiterungs-/Modifizierungsbedarf besteht bzw. Normen und Standards fehlen. Über- schneidungen werden dabei ebenfalls sichtbar und können diskutiert werden. Existieren für denselben oder ähnlichen Sachverhalt aus der Modellbetrach- tung heraus mehrere Standards, kann ein Vorzugs- standard im Referenzarchitekturmodell diskutiert werden. Ziel ist, mit möglichst wenigen Standards auszukom- men. Erfüllung von Standards Die ausgewählten Normen und Standards werden daraufhin geprüft, inwieweit deren beschriebene Kon- zepte und Methoden für die Anwendungen im Umfeld von Industrie 4.0 geeignet sind. Für eine erste I4.0- Anwendung kann die Umsetzung einer Teilmenge einer Norm/eines Standards genügen. Dies würde die Umsetzung und Einführung von herstellerübergrei- fenden Lösungen, wie sie für Industrie 4.0 unerläss- lich sind, beschleunigen und auch kleineren Unter- nehmen die Chance eröffnen, die Umsetzung und Anpassung an Industrie 4.0 schneller zu bewältigen. Use Cases Das Referenzarchitekturmodell bietet auch die Mög- lichkeit, I4.0-Use-Cases zu verorten, um z. B. die für den jeweiligen Use Case notwendigen Normen und Standards zu identifizieren. Verortung von Beziehungen Verschiedene Themen können als Unterräume des Referenzarchitekturmodells dargestellt werden. Indus- trie 4.0 lebt wesentlich davon, dass Beziehungen z. B. zwischen diesen Unterräumen elektronisch erfasst und bearbeitet werden können. www.vdi.de
  • 9. Referenzarchitekturmodell Industrie 4.0 7 Definition übergeordneter Regeln Das Referenzarchitekturmodell erlaubt die Ableitung von Regeln für die Umsetzung von I4.0-Implemen- tierungen auf einer übergeordneten Ebene. Die Ziele im Überblick  anschauliches und einfaches Architekturmodell als die Referenz  Verortung von vorhandenen Normen und Standards  Identifikation und Schließen von Lücken in Normen und Standards  Identifikation von Überschneidungen und Festlegung von Vorzugslösungen  Minimierung der Zahl der eingesetzten Normen und Standards  Identifikation von Untermengen einer Norm bzw. eines Standards zur schnellen Umsetzung von Tei- linhalten für Industrie 4.0 („I4.0-ready“)  Verortung von Use-Case-Inhalten  Verortung von Beziehungen  Definition übergeordneter Regeln 2.3.2 Kurzbeschreibung des Referenzarchitekturmodells Ein dreidimensionales Modell kann den I4.0-Raum am besten darstellen. Dabei orientiert sich das Modell in seinen Grundzügen am Smart Grid Architecture Model (SGAM – Anmerkung: CEN/CENELEC/ ETSI SG-CG, Overview of SG-CG Methodologies, Version 3.0, Annex SGAM User Manual, 2014), das von der europäischen Smart Grid Coordination Group (SG-CG) definiert wurde und weltweit akzeptiert ist. Es wurde anhand der I4.0-Erfordernisse angepasst und erweitert. In der senkrechten Achse werden Layer/Schichten für die Darstellung der unterschiedlichen Sichtweisen, wie Datenabbild, funktionale Beschreibung, Kommu- nikationsverhalten, Hardware/Assets oder auch Ge- schäftsprozesse, verwendet. Dies entspricht der Denk- weise der IT bei der Clusterung komplexer Projekte in überschaubare Teileinheiten. Ein weiteres wichtiges Kriterium ist der Produktle- benszyklus mit seinen darin enthaltenen Wertschöp- fungsketten. Dieser Sachverhalt wird auf der waag- rechten Achse dargestellt (Bild 1). Damit können in dem Referenzarchitekturmodell auch Abhängigkeiten gut dargestellt werden, z. B. die durchgängige Daten- erfassung über den gesamten Lebenszyklus. Das dritte wichtige Kriterium, in der dritten Achse dargestellt, ist die Verortung von Funktionalitäten und Verantwortlichkeiten innerhalb der Fabriken/Anlagen. Es geht um eine funktionale Hierarchie und nicht um Geräteklassen oder Hierarchieebenen der klassischen Automatisierungspyramide. Bild 1. Referenzarchitekturmodell Industrie 4.0 (RAMI4.0) www.vdi.de
  • 10. 8 Referenzarchitekturmodell Industrie 4.0 2.3.3 Schichten des Referenzarchitek- turmodells (Layers) Das Smart Grid Modell (SGAM) stellt einen guten ersten Ansatz zur Darstellung der zu beschreibenden Sachlage dar. Es behandelt das Stromnetz von der Erzeugung über die Übertragung und Verteilung bis zum Verbraucher. Bei Industrie 4.0 stehen Produkt- entwicklungs- und Produktionsszenarien im Mittel- punkt. Das heißt, es muss beschrieben werden, wie Entwicklungsprozesse, Produktionslinien, Fertigungs- maschinen, Feldgeräte und die Produkte selbst be- schaffen sind bzw. funktionieren. Für alle Komponenten, ob Maschine oder Produkt, ist nicht nur die informations- und kommunikationstech- nische Funktionalität von Interesse. Für die Simulati- on eines Systems z. B. einer kompletten Maschine werden auch deren Kabel, der Linearantrieb oder auch die mechanische Konstruktion mitbetrachtet. Sie sind Teil der Realität ohne aktiv kommunizieren zu kön- nen. Ihre Informationen müssen als „Virtuelle Reprä- sentation“ vorhanden sein. Dafür werden sie z. B. passiv über einen 2D-Code mit einem Datenbankein- trag verbunden. Um sowohl Maschinen, Komponenten und Fabriken besser beschreiben zu können, wurde gegenüber SGAM dessen Component Layer durch einen Asset Layer ersetzt, als untere Schicht in das Modell einge- fügt und darüber der Integration Layer neu hinzuge- fügt. Dieser ermöglicht die digitale Umsetzung der Assets für die Virtuelle Repräsentation. Der Commu- nication Layer behandelt Protokolle und Übertragung von Daten und Dateien, der Information Layer bein- haltet die relevanten Daten, der Functional Layer alle notwendigen (formal beschriebenen) Funktionen und im Business Layer ist der relevante Geschäftsprozess abgebildet. Hinweis: Innerhalb der Schichten soll eine hohe Kohäsion und zwischen den Schichten eine lose Kopplung herrschen. Der Ereignisaustausch darf nur zwischen zwei benachbarten Schichten und innerhalb einer Schicht erfolgen. Mehrere Systeme werden zu größeren Gesamtsyste- men zusammengefasst. Dabei müssen die Einzelsys- teme und das Gesamtsystem dem Referenzarchitek- turmodell folgen. Die Inhalte der Schichten müssen zueinander kompatibel sein. Nachfolgend werden die einzelnen Schichten und ihre Beziehung untereinander beschrieben. Geschäftssicht (Business Layer)  Sicherstellung der Integrität der Funktionen in der Wertschöpfungskette  Abbildung der Geschäftsmodelle und dem sich daraus ergebenden Gesamtprozess  rechtliche und regulatorische Rahmen- bedingungen  Modellierung der Regeln, denen das System folgen muss  Orchestrierung von Diensten des Functional Layers  Verbindungselement zwischen verschiedenen Geschäftsprozessen  Empfang von Ereignissen für die Weiterschaltung des Geschäftsprozesses Der Business Layer bezieht sich nicht auf konkrete Systeme wie beispielsweise ein ERP. ERP-Funk- tionen, die im Prozesskontext arbeiten, finden sich typischerweise im Functional Layer wieder. Funktionsschicht (Functional Layer)  formale Beschreibung von Funktionen  Plattform für die horizontale Integration der verschiedenen Funktionen  Laufzeit- und Modellierungsumgebung für Dienste, die Geschäftsprozesse unterstützen  Laufzeitumgebung für Anwendungen und fachliche Funktionalität Innerhalb des Functional Layer werden Regeln/ Entscheidungslogiken erzeugt. Diese können auch abhängig vom Anwendungsfall in den unteren Schich- ten (Information Layer oder Integration Layer) ausge- führt werden. Fernzugriffe und horizontale Integration finden nur innerhalb des Functional Layer statt. Damit werden die Integrität der Informationen und Zustände im Prozess und die Integration der technischen Ebene sichergestellt. Zu Wartungszwecken können auch temporäre Zugriffe auf Asset Layer und Integration Layer stattfinden. Solche Zugriffe werden insbesondere verwendet, um auf Informationen und Prozesse, die nur für unterge- ordnete Schichten relevant sind, zuzugreifen. Beispie- le hierfür sind das Flashen von Sensoren/Aktoren oder www.vdi.de
  • 11. Referenzarchitekturmodell Industrie 4.0 9 das Auslesen von Diagnosedaten. Die wartungsbezo- genen temporären Fernzugriffe sind für eine perma- nente funktionale oder horizontale Integration nicht relevant. Informationsschicht (Information Layer)  Laufzeitumgebung für die Ereignis(vor)- verarbeitung  Ausführung von ereignisbezogenen Regeln  formale Beschreibung von Regeln  Kontext: Ereignisvorverarbeitung Dabei werden aus einem oder mehreren Ereignissen über Regeln ein oder mehrere weitere Ereignisse erzeugt, die dann im Functional Layer die Verarbei- tung anstoßen.  Persistieren der Daten, die die Modelle repräsen- tieren  Sicherstellung der Datenintegrität  konsistente Integration verschiedener Daten  Gewinnung von neuen, höherwertigen Daten (Daten, Informationen, Wissen)  Bereitstellung strukturierter Daten über Dienst- schnittstellen  Entgegennahme von Ereignissen und deren Trans- formation passend zu den Daten, die für den Functional Layer verfügbar sind Kommunikationsschicht (Communication Layer)  Vereinheitlichung der Kommunikation, unter Verwendung eines einheitlichen Datenformats, in Richtung des Information Layer  Bereitstellung von Diensten zur Steuerung des Integration Layer Integrationsschicht (Integration Layer)  Bereitstellung der rechnerverarbeitbaren Informa- tionen der Assets Physik/Hardware/Dokumente/ Software usw.  Rechnergestützte Steuerung des technischen Prozesses  Generierung von Ereignissen aus den Assets  enthält die mit der IT verbundenen Elemente, wie RFID Reader, Sensoren, HMI Die Interaktion mit dem Menschen erfolgt ebenfalls in dieser Ebene, z. B. mittels der Mensch-Maschine- Schnittstelle (HMI). Hinweis: Jedes wichtige Ereignis in der Realität weist auf ein Ereignis in der Virtualität, das heißt im Inte- gration Layer. Ändert sich die Realität, wird das Er- eignis mit geeigneten Mechanismen an den Integrati- on Layer gemeldet. Relevante Ereignisse können Ereignisse über den Communication Layer an den Information Layer auslösen Gegenstandsschicht (Asset Layer)  repräsentiert die Realität, z. B. physikalische Ele- mente wie Linearachsen, Blechteile, Dokumente, Schaltpläne, Ideen, Archive  Der Mensch ist ebenfalls Bestandteil des Asset Layers und ist über den Integration Layer an die virtuelle Welt angebunden.  passive Verbindung der Assets mit der Integrati- onsschicht über z. B. QR-Codes 2.3.4 Lebenszyklus und Wertschöp- fungskette (Life Cycle & Value Stream) Lebenszyklus (Life Cycle) Industrie 4.0 bietet über den gesamten Lebenszyklus von Produkten, Maschinen, Fabriken, usw. großes Verbesserungspotenzial. Um Zusammenhänge und Verknüpfungen zu visualisieren und zu standardisie- ren, repräsentiert die zweite Achse des Referenzarchi- tekturmodells den Lebenszyklus und die damit ver- bundenen Wertschöpfungsketten. Für die Betrachtung des Lebenszyklus bietet der Ent- wurf zur IEC 62890 eine gute Orientierung. Dabei ist die grundsätzliche Unterscheidung von Typ und In- stanz ein zentraler Teil für die Betrachtungen. www.vdi.de
  • 12. 10 Referenzarchitekturmodell Industrie 4.0 Typ (Type) Ein Typ entsteht immer mit der ersten Idee, also der Entstehung des Produkts in der Phase „Development“. Damit sind die Beauftragung, die Entwicklung, die Tests bis hin zum ersten Muster und der Prototypenfer- tigung gemeint. In dieser Phase entsteht also der Typ des Produkts, der Maschine, usw. Nach Abschluss aller Tests und Validierung wird der Typ für die Serienpro- duktion frei gegeben. Instanz (Instance) Auf Basis des allgemeinen Typs werden in der Pro- duktion Produkte hergestellt. Jedes gefertigte Produkt stellt dann eine Instanz dieses Typs dar und erhält z. B. eine eindeutige Seriennummer. Die Instanzen gelangen in den Verkauf und werden an Kunden aus- geliefert. Für den Kunden sind die Produkte zunächst wieder nur Typen. Zur Instanz werden sie, wenn sie in eine konkrete Anlage eingebaut werden. Der Wechsel vom Typ zur Instanz kann sich mehrmals wiederho- len. Aus der Verkaufsphase zurückgemeldete Verbesse- rungen können beim Hersteller eines Produkts zur Anpassung der Typunterlagen führen. Mit dem neu entstandenen Typ können wieder neue Instanzen hergestellt werden. Der Typ unterliegt damit einer Nutzung und Pflege genauso wie jede einzelne In- stanz. Beispiel Die Entwicklung eines neuen Hydraulikventils stellt einen neuen Typ dar. Das Ventil wird entwickelt, erste Muster werden aufgebaut und getestet und zum Abschluss wird eine erste Prototypenserie in der Pro- duktion aufgelegt und anschließend validiert. Nach erfolgreichem Abschluss der Validierung erfolgt die Freigabe dieses Hydraulikventiltyps für den Verkauf (Materialnummer und/oder Produktbezeichnung im Verkaufskatalog). Und damit startet auch die Serien- produktion. In der Serienproduktion erhält nun jedes hergestellte Hydraulikventil z. B. seine eineindeutige Kennzeichnung (Seriennummer) und ist eine Instanz zu dem einmal entwickelten Hydraulikventil. Rückmeldungen zu den verkauften Hydraulikventilen (Instanzen) im Feld führen z. B. zu einer kleinen An- passung der mechanischen Konstruktion und Zeich- nungsunterlage sowie zu einer Softwarekorrektur in der Firmware des Ventils. Diese Anpassungen sind Anpassungen am Typ, das heißt, sie fließen in die Typunterlagen ein, werden wieder freigegeben und somit entstehen neue Instanzen des geänderten Typs in der Produktion. Wertschöpfungsketten Die Digitalisierung und Verknüpfung der Wertschöp- fungsketten bietet ein hohes Verbesserungspotenzial durch Industrie 4.0. Dabei ist eine funktional über- greifende Verknüpfung von entscheidender Bedeu- tung. Logistikdaten können in der Montage verwendet werden, die Intralogistik organisiert sich selbst an- hand der Auftragsbestände. Der Einkauf sieht in Echt- zeit Bestände und wo sich Zulieferteile zu einem bestimmten Zeitpunkt befinden. Der Kunde sieht den Fertigstellungsgrad seines bestellten Produkts in der Fertigung usw. Mit der Verknüpfung von Einkauf, Auftragsplanung, Montage, Logistik, Maintenance, Kunde, Zulieferer usw. bestehen große Verbesse- rungspotenziale. Daher muss der Lebenszyklus mit den enthaltenen Wertschöpfungsprozessen zusammen betrachtet werden; und dies nicht isoliert mit Blick auf eine Fabrik, sondern im Verbund aller Fabriken und allen Partnern vom Engineering über Zulieferer bis hin zum Kunden. Zu den Wertschöpfungsketten sei auch auf die Veröf- fentlichung des GMA-Fachausschusses 7.21 zu „Wertschöpfungsketten“ [1] verwiesen. 2.3.5 Hierarchieebenen (Hierarchy Levels) Die dritte Achse des Referenzarchitekturmodells beschreibt die funktionale Einordnung einer Sachlage innerhalb Industrie 4.0. Dabei geht es nicht um eine Implementierung, es geht allein um funktionale Zu- ordnungen. Für die Einordnung innerhalb einer Fabrik orientiert sich das Referenzarchitekturmodell für diese Achse an den Normen IEC 62264 und IEC 61512 (siehe Bild 2). Für eine einheitliche Betrachtung über möglichst viele Branchen von Prozessindustrie bis Fabrikautomation wurden aus den dort aufgeführten Optionen die Be- griffe „Enterprise“, „Work Unit“, „Station“ und „Con- trol Device“ verwendet. Für Industrie 4.0 ist neben dem Control Device (z. B. einer Kopfsteuerung) auch die Betrachtung innerhalb einer Maschine oder Anlage entscheidend. Daher wur- de unterhalb des Control Device das „Field Device“ hinzugefügt. Dies stellt die funktionale Ebene eines intelligenten Feldgeräts z. B. eines intelligenten Sen- sors dar. Außerdem ist neben der Anlage zur Herstellung von Produkten in Industrie 4.0 auch das herzustellende Produkt selbst für die Betrachtungen wichtig. Daher ist es als untere Ebene zusätzlich als „Product“ einge- www.vdi.de
  • 13. Referenzarchitekturmodell Industrie 4.0 11 führt. Damit wird im Referenzarchitekturmodell eine homogene Betrachtung von herzustellendem Produkt und Produktionsanlage mit deren Abhängigkeiten untereinander möglich. Am oberen Ende der Hierarchy Levels wurde eben- falls eine Ergänzung vorgenommen. Die beiden er- wähnten IEC-Normen stellen nämlich nur die Ebenen innerhalb einer Fabrik dar. Industrie 4.0 geht aber einen Schritt weiter und beschreibt auch den Fabrik- verbund, die Zusammenarbeit mit externen Enginee- ring-Büros, Zulieferern und Kunden usw. Daher wur- de für die Betrachtungen über den Enterprise Level hinaus noch zusätzlich die Ebene „Connected World“ eingeführt. 2.4 Referenzmodell für die I4.0-Komponente Die nachfolgend beschriebene Version 1.0 des „Refe- renzmodell I4.0-Komponente“ soll die erste von meh- reren Verfeinerungen sein, die in unterjährigen Zeit- abständen veröffentlich werden sollen. In einem weiteren Schritt sollen daher Kapitel mit genaueren Definitionen folgen, eine Formalisierung mit UML ist vorgesehen. Der Text bemüht sich, genau auszuweisen, wenn Texte/Zitate aus anderen Quellen im I4.0-Umfeld übernommen werden. Im Endstand sollen die Be- griffsverwendungen identisch mit dem abgestimmten und vom GMA-Fachausschuss 7.21 veröffentlichten Glossar (siehe Kapitel 2.5) sein. Beispiele werden ebenfalls explizit gekennzeichnet, um Ausschlüsse, die im Beispiel nicht explizit genannt werden, zu vermeiden. Bild 2. Ableitung der Hierarchieebenen des RAMI4.0 www.vdi.de
  • 14. 12 Referenzarchitekturmodell Industrie 4.0 2.4.1 Einordnung in die Diskussion zu Industrie 4.0 Die Diskussion Industrie 4.0 lässt sich grob als Zu- sammenspiel von vier Aspekten auffassen, wie Bild 3 aus dem Abschlussbericht des Arbeitskreises Indus- trie 4.0 [4] illustriert: Nach Bild 3 sind diese vier Aspekte:  I4.0-Aspekt (1) Horizontale Integration über Wertschöpfungsnetzwerke  I4.0-Aspekt (2) Vertikale Integration, z. B. innerhalb einer Fabrik/Fertigung  I4.0-Aspekt (3) Lebenszyklus-Management, Durchgängigkeit des Engineering  I4.0-Aspekt (4) Der Mensch als Dirigent im Wertschöpfungsnetzwerk Die in diesem Text beschriebene I4.0-Komponente gibt einen flexiblen Rahmen vor, mit dem Daten und Funktionen beschrieben und bereitgestellt werden können, die die oben angeführten I4.0-Aspekte för- dern und möglich machen. Die in diesem Text be- schriebenen Konzepte bedienen zum jetzigen Zeit- punkt vor allem Aspekt (2) und berücksichtigen An- forderungen aus Aspekt (3). 2.4.2 Inhalte aus weiteren relevanten Publikationen Gegenstände, Entitäten, Komponenten Hierzu wird verwiesen auf den VDI-Statusreport „Industrie 4.0: Gegenstände, Entitäten, Komponen- ten“ des GMA-Fachausschusses 7.21 [3]. Definitio- nen hieraus finden sich in den vorausgegangenen Kapiteln des hier vorliegenden Statusreports. Typen und Instanzen Hierzu wird ebenfalls auf den VDI-Statusreport „Industrie 4.0: Gegenstände, Entitäten, Komponen- ten“ des GMA-Fachausschusses 7.21 [3] verwiesen. Es wird auf den Stand der Technik bezüglich der Unterscheidung von Typen und Instanzen in der Industrie 4.0. eingegangen. Lebenszyklen Nach Fraunhofer IPA, Dr. Carmen Constantinescu und Prof. Thomas Bauernhansl, sind für den Betrieb einer Fabrik Lebenszyklen mehrerer Dimensionen von Relevanz für Industrie 4.0.  Produkt: Eine Fabrik produziert mehrere Produk- te. Jedes Produkt hat einen eigenen Lebenszyklus.  Auftrag: Jeder Auftrag, der gefertigt werden soll, durchläuft einen Lebenszyklus und muss seine Spezifitäten während der Auftragsausführung in den Produktionsbetrieb abprägen können.  Fabrik: Auch eine Fabrik hat einen Lebenszyklus: Sie wird finanziert, geplant, aufgebaut und wie- derverwertet. Eine Fabrik integriert Produktions- systeme und Maschinen verschiedener Hersteller.  Maschine: Eine Maschine wird in Auftrag gege- ben, konstruiert, in Betrieb genommen, betrieben, gewartet, umgebaut und verwertet. Bild 3. Vier wichtige Aspekte von Industrie 4.0 (Quellen: Siemens, Festo) www.vdi.de
  • 15. Referenzarchitekturmodell Industrie 4.0 13 Bild 4. Relevante Lebenszyklen für I4.0-Komponenten; Quelle: M. Hankel, Bosch Rexroth. Basiert auf Plattform Industrie 4.0 AG3. Basiert auf Prof. Bauernhansl, Fraunhofer IPA Der Maschinenhersteller bezieht dazu einzelne Zulie- ferteile, die in diesem Text als Gegenstände bezeich- net werden. Der Zulieferer (in der Regel ein Kompo- nentenhersteller) realisiert einen Lebenszyklus auch für diese Zulieferteile:  Komponente: Planung und Entwicklung, Rapid Prototyping, Konstruktion, Produktion, Nutzung bis hin zum Service Bild 4 verdeutlicht die Zuordnung von Typen und Instanzen zum Lebenszyklus. Verbindung von Lebenszyklen Ursächlich für die notwendige Unterscheidung von Typen und Instanzen sind das Zusammenwirken ver- schiedener Geschäftspartner und deren jeweiliger Lebenszyklen mit den Planungsprozessen. Während einer Planung werden verschiedene Hypothesen und Alternativen erwogen. Die Planung geht von potenzi- ellen Gegenständen aus und nennt diese „Typen“:  Der Zulieferer nennt diese „Teiletypen“: Erst die Fertigung und die anschließende Auslieferung an den Kunden (Maschinenhersteller) „erschafft“ eine Instanz, die dieser als Zulieferteil weiterver- wendet.  Der Maschinenhersteller bespricht mit seinen Kunden und plant „Maschinentypen“: Die Kon- struktion einer speziellen Maschine und deren Re- alisierung erschafft eine Instanz, die der Fabrikbe- treiber weiterverwendet.  Der Fabrikbetreiber entwickelt ein Produkt ebenfalls zunächst als Produkttyp. Erst der Auf- trag stößt die Fertigung an und realisiert die Ferti- gung konkreter Produktinstanzen, die ausgeliefert werden. Bemerkenswert ist nun, dass während der Konzeption und Planung eines jeweiligen Typs viele Informatio- nen und Daten generiert werden, die bei der Verwen- dung der jeweiligen Instanz durch den nachfolgenden Geschäftspartner im Wertschöpfungsnetzwerk genutzt werden können. Weitere Informationen kommen während der Produktion einer bestimmten Instanz hinzu (z. B. Tracking-Daten und Qualitätsdaten). Das Referenzmodell für I4.0-Komponenten behandelt daher Typen und Instanzen gleichwertig und gleichar- tig. www.vdi.de
  • 16. 14 Referenzarchitekturmodell Industrie 4.0 Bild 5. Typen und Instanzen im Lebenszyklus Referenzarchitekturmodell Industrie 4.0 (RAMI4.0) Für die Definitionen des „Referenzarchitekturmodell Industrie 4.0 (RAMI4.0)“ sei auf die vorausgegange- nen Kapitel verwiesen. Die in Bild 5 vorgestellte I4.0-Komponente ordnet sich in die Schichten des RAMI4.0 ein. Sie kann verschiedene Positionen des Life-Cycle und Value-Streams genauso wie verschie- dene Hierarchieebenen abbilden; hier bedarf es der konkreten Instantiierung zur eindeutigen Festlegung 2.4.3 I4.0-Komponente In diesem Kapitel wird eine erste allgemein anerkann- te Definition einer I4.0-Komponente hergeleitet. Bild 6. Abgrenzung „Office floor” und „Shop floor” www.vdi.de
  • 17. Referenzarchitekturmodell Industrie 4.0 15 Abgrenzung der I4.0-Komponente zwi- schen „Office floor“ und „Shop floor“ Um eine Abgrenzung der Verantwortlichkeiten vor- nehmen zu können, wird in Unternehmen gewöhnlich zwischen „Office floor“ und „Shop floor“ unterschie- den. In modernen Unternehmen sind allerdings diese Bereiche zunehmend miteinander verzahnt. Wird ein Augenmerk auf die Automatisierungstechnik gelegt, so nimmt die Relevanz des „Office floor“ ab, während immer mehr Anforderungen des „Shop floor“ relevant werden. Gleiches gilt auch in anderer Richtung. Auf- grund der Forderung in Bild 6 nach Konnektivität zu beliebigen Endpunkten und einem gemeinsamen se- mantischen Modell müssen Komponenten bestimmte gemeinsame Eigenschaften unabhängig von den Ebe- nen aufweisen. Sie sind in Form der I4.0-Komponente spezifiziert. Eine I4.0-Komponente kann ein Produktionssystem, eine einzelne Maschine oder Station oder auch eine Baugruppe innerhalb einer Maschine repräsentieren. Damit bewegt sich jede I4.0-Komponente, so ver- schieden sie sein mag, im Spannungsfeld der Rele- vanzen „Office floor“ und „Shop floor“, entlang des Lebenszyklus der Fabrik und in Kontakt mit so zent- ralen und signifikanten Fabriksystemen wie dem PLM (Product Lifecycle Management), ERP (Enterprise Ressource Planning), Industrial Control und Logistik- Systemen. Anforderung: Ein Netzwerk von I4.0-Komponen- ten muss so aufgebaut sein, dass Verbindungen zwischen beliebigen Endpunkten (I4.0-Komponen- ten) möglich sind. Die I4.0-Komponenten und deren Inhalte sollen einem gemeinsamen semanti- schen Modell folgen. Anforderung: Das Konzept einer I4.0-Komponen- te muss so ausdifferenziert werden können, dass es verschiedenen Anforderungsschwerpunkten, also „Office floor“ oder „Shop floor“, gerecht werden kann. Vom Gegenstand zur I4.0-Komponente Im folgenden Abschnitt sollen die einzelnen Festle- gungen der VDI/VDE-Gesellschaft Mess- und Auto- matisierungstechnik (GMA) miteinander in Bezug gesetzt werden, um zu einer Definition einer I4.0-Komponente zu gelangen: Gegenstandsklassen Die GMA benennt vier Gegenstandklassen:  nicht bekannt,  anonym bekannt,  individuell bekannt und  Entitäten. Um Daten und Funktionen an einen Gegenstand bin- den zu können, muss dieser als Entität vorliegen. Software, die im herkömmlichen Sinne auch physisch oder nicht physisch ausgeliefert wird, ist ebenfalls ein Gegenstand. Auch Ideen, Archive und Konzepte sind Gegenstände in diesem Sinne. Bemerkung 1: Da ein Ziel einer I4.0-Komponente ist, Daten und Funktionen in einem Informationssystem bereitzustellen, ergibt sich für individuell bekannte Gegenstände im Sinne der GMA per se ein Übergang zu einer Entität. Bemerkung 2: Im Folgenden wird immer von Gegen- stand gesprochen, wenn ein Gegenstand/Entität be- zeichnet wird. Bild 7. I4.0-Komponente Typ/Instanz Gegenstände können als Typ oder als Instanz bekannt sein. Als Typ ist ein Gegenstand z. B. in der Pla- nungsphase bekannt; sind die Bestellinformationen eines geplanten Gegenstands bekannt, kann dieser als individuell bekannter Typ aufgefasst werden. Als Instanzen sind z. B. alle Gegenstände einer real exis- tierenden Maschine aufzufassen. Scheinbare Instan- zen, die durch mehrfache Instantiierung eines Typs im Sinne einer Abzählbarkeit entstehen (Chargen), sind www.vdi.de
  • 18. 16 Referenzarchitekturmodell Industrie 4.0 zurzeit nicht gesondert berücksichtigt. Hier sollte die Instantiierung konkret ausgeführt werden und ein Rückbezug auf den Typ vorgesehen werden. Kommunikationsfähigkeit Um Eigenschaften einer I4.0-Komponente bereitstel- len zu können, muss mindestens ein Informationssys- tem eine Verbindung zum Gegenstand halten. Daher wird mindestens passive Kommunikationsfähigkeit für den Gegenstand vorausgesetzt, was bedeutet, dass ein Gegenstand nicht unbedingt die Fähigkeit einer I4.0-konformen Kommunikation entsprechend GMA- Fachausschuss 7.21 aufweisen muss. Damit können bereits bestehende Gegenstände zu I4.0-Komponenten „erweitert“ werden. In diesem Fall übernimmt ein übergeordnetes IT-System einen Teil der I4.0-konfor- men Kommunikation im Sinne einer SOA-Architektur und eines Stellvertreterprinzips. Beispielsweise kann so eine identifizierbare Klemm- leiste eine I4.0-Komponente werden oder ein Profi- Net-Gerät (identifizierbar über seine I&M-Daten). Virtuelle Repräsentation Die Virtuelle Repräsentation hält Daten zu dem Ge- genstand. Diese Daten können entweder „auf/in“ der I4.0-Komponente selbst gehalten und durch eine I4.0- konforme Kommunikation der Außenwelt zur Verfü- gung gestellt werden. Oder sie werden auf einem (übergeordneten) IT-System gehalten, das sie durch I4.0-konforme Kommunikation der Außenwelt zur Verfügung stellt. Im Referenzarchitekturmodell RAMI4.0 findet die Virtuelle Repräsentation auf der Informationsschicht statt. Damit kommt der I4.0-konformen Kommunika- tion eine hohe Bedeutung zu. Anforderung: Die I4.0-konforme Kommunikation muss so ausgeführt sein, dass die Daten einer Vir- tuellen Repräsentation einer I4.0-Komponente entweder im Gegenstand selbst oder aber in einem (übergeordneten) IT-System gehalten werden kön- nen Ein wichtiger Teil der Virtuellen Repräsentation ist das „Manifest“ [Gewählt wegen .JAR-Datei, s. Mani- fest bei: http://docs.oracle.com/javase/7/docs/ technotes/guides/jar/jar.html#JAR_Manifest], das als Verzeichnis der einzelnen Dateninhalte der Virtuellen Repräsentation angesehen werden kann. Damit enthält es sogenannte Meta-Informationen. Es enthält außer- dem verpflichtende Angaben zu der I4.0-Komponente, unter anderem zur Verbindung mit dem Gegenstand durch die entsprechende Identifikationsmöglichkeit. Mögliche weitere Daten in der Virtuellen Repräsenta- tion sind Daten, die einzelne Lebenszyklusphasen umfassen, wie CAD-Daten, Anschlussbilder oder Handbücher. Fachliche Funktionalität Neben Daten kann eine I4.0-Komponente auch eine fachliche Funktionalität besitzen. Diese Funktionalität kann beispielsweise umfassen:  Software zur „lokalen Planung“ in Verbindung mit dem Gegenstand. Beispiele: Schweißplanung, Software zum Beschriften der Klemmleisten usw.  Software zur Projektierung, Konfiguration, Bedie- nung, Wartung  Mehrwerte zum Gegenstand  weitere fachliche Funktionalitäten, die für die Ausführung der Geschäftslogik relevant sind Im Referenzarchitekturmodell RAMI4.0 findet die fachliche Funktionalität auf der Funktionsschicht statt. Eine „Verwaltungs-Schale“ macht einen Gegenstand zu einer I4.0-Komponente Wie der obige Abschnitt beschreibt, können verschie- denartige Gegenstände mit verschiedenartigen Kom- munikationsfähigkeiten zu einer I4.0-Komponente ausgeführt werden. Dieser Abschnitt soll diese ver- schiedenen Ausführungsformen anhand von Beispie- len näher beleuchten. Im Sinne des Konzepts „I4.0- Komponente“ sind diese Ausführungsformen gleich- wertig. www.vdi.de
  • 19. Referenzarchitekturmodell Industrie 4.0 17 Bild 8. Ein Gegenstand wird zur I4.0-Komponente Bild 8 zeigt, dass ein Gegenstand, gleich welcher Art, zunächst keine I4.0-Komponente ist. Erst wenn dieser Gegenstand, der eine Entität und mindestens passiv kommunikationsfähig sein muss, mit einer „Verwal- tungs-Schale“ umgeben wird, kann er als I4.0-Kom- ponente bezeichnet werden. Im Sinne des obigen Abschnitts umfasst dabei die Verwaltungs-Schale die Virtuelle Repräsentation und die fachliche Funktionalität des Gegenstands. Für einen möglichen Gegenstand gibt Bild 8 vier Beispiele: 1 Eine ganze Maschine kann vor allem aufgrund ihrer Steuerung als I4.0-Komponente ausgeführt werden. Diese Ausführung der I4.0-Komponente übernimmt dann beispielsweise der Maschinen- hersteller. Auch eine strategisch wichtige Baugruppe von ei- nem Zulieferer kann als eigenständige I4.0-Kom- ponente aufgefasst werden, um sie beispielsweise von Asset-Management- und Wartungssystemen eigenständig zu erfassen. Die Ausführung der I4.0-Komponente übernimmt dann beispielsweise der Komponentenhersteller. 2 Ebenso ist es möglich, einzelne konstruierte Bau- gruppen (um den Begriff Komponente zu vermei- den) der Maschinen als I4.0-Komponente aufzu- fassen. Beispielsweise ist es für einen Klemmen- block wichtig, die Beschaltung mit einzelnen Sig- nalen festzuhalten und über den Lebenszyklus der Maschine aktuell zu halten. Diese Ausführung der I4.0-Komponente übernimmt dann beispielsweise der Elektro-Planer und Elektriker. 3 Letztlich kann eine bereitgestellte Software ein wichtiges Asset eines Produktionssystems und somit eine I4.0-Komponente darstellen. Eine sol- che Standardsoftware könnte z. B. ein eigenstän- diges Planungs- oder Engineering-Werkzeug sein, das heute oder in Zukunft für den Betrieb der Fer- tigung wichtig ist. Auch ist es denkbar, dass ein Zulieferer eine Bibliothek, die erweiterte Funktio- nen zu seinen Produkten bereitstellt, als reine Software verkaufen möchte. Diese Ausführung der I4.0-Komponente übernähme dann beispielsweise der Bereitsteller der Software; eine Verteilung auf einzelne IEC-61131-Steuerungen würde dann von den verschiedenen I4.0-Systemen geleistet. Bild 8 stellt in einer logischen Sicht dar, dass zu einem Gegenstand eine „Verwaltungs-Schale“ gehört. Im Hinblick auf eine Verteilungssicht können Ge- genstand und Verwaltungs-Schale durchaus entkop- pelt existieren. So kann bei passiv kommunikations- fähigen Gegenständen die Verwaltungs-Schale in einem übergeordneten IT-System abgebildet („gehos- tet“) werden. Mithilfe der passiven Kommunikations- www.vdi.de
  • 20. 18 Referenzarchitekturmodell Industrie 4.0 fähigkeit des Gegenstands und einer I4.0-konformen Kommunikation des übergeordneten IT-Systems wird die Verbindung zwischen Gegenstand und Verwal- tungs-Schale gewahrt. Gleiches gilt, wenn der Gegen- stand aktiv, aber nicht I4.0-konform kommunikations- fähig ist. Erst bei einer I4.0-konformen Kommunika- tionsfähigkeit kann die Verwaltungs-Schale „im“ Gegenstand abgebildet werden (sie wird beispielswei- se in der Steuerung einer Maschine gespeichert und durch die Netzwerkschnittstelle ausgeliefert). Im Sinne des Konzepts „I4.0-Komponente“ sind alle Alternativen als gleichwertig anzusehen. Ein Gegenstand kann mehrere Verwaltungs-Schalen für unterschiedliche Zwecke besitzen. Anforderung: Durch ein geeignetes Referenzmo- dell muss beschrieben werden, wie ein übergeord- netes IT-System die Verwaltungs-Schale I4.0-kon- form zur Verfügung stellen kann (SOA-Ansatz, Stellvertreterprinzip). Anforderung: Es muss beschrieben werden, wie die Verwaltungs-Schale vom Erzeuger (z. B. Kom- ponentenhersteller, Elektro-Planer) zum überge- ordneten IT-System „transportiert“ werden kann (z. B. als Attachment zu einer E-Mail). Weitere Begriffsabgrenzung Bild 9 grenzt die Begriffe nochmals voneinander ab: Eine I4.0-Komponente umfasst aus logischer Sicht ein oder mehrere Gegenstände und eine Verwaltungs- Schale, die Daten der Virtuellen Repräsentation und Funktionen der fachlichen Funktionalität enthält. Das Manifest als Teil der Virtuellen Repräsentation detail- liert die notwendigen verwaltungstechnischen Anga- ben zu der I4.0-Komponente. Der „Resource-Mana- ger“, wie vom GMA-Fachausschuss 7.21 definiert, ist ebenfalls Teil der Verwaltungs-Schale. Damit haben die IT-technischen Dienste Zugriff auf die Daten und Funktionen der Verwaltungs-Schale und machen sie nach außen verfügbar. Die Verwaltungs-Schale und ihre Objekte können innerhalb eines „embedded systems“ eines der Gegen- stände „gehostet“ sein (aktive, I4.0-konforme Kom- munikationsfähigkeit) oder aber in ein oder mehrere übergeordnete IT-Systeme verteilt werden (Vertei- lungssicht. Bild 9. I4.0-Komponente Anforderung: Je nach Art der übergeordneten Systeme müssen die Verwaltungsobjekte in mehr als ein übergeordnetes IT-Systems verteilt werden können. Cyberphysisches System Die I4.0-Komponente stellt eine Spezialisierung eines cyberphysischen Systems dar. I4.0-Komponenten aus Verteilungssicht Der obere Abschnitt stellt dar, dass aus einer logi- schen Sicht heraus für jede I4.0-Komponente zu je- dem Gegenstand eine „Verwaltungs-Schale“ gehört. Er betont aber auch, dass situativ aus Verteilungssicht die Verwaltungs-Schale in ein übergeordnetes System ausgelagert werden kann I4.0-Komponente in Repository abgebildet Zum besseren Verständnis kann eine zu einem Repo- sitory der „Digitalen Fabrik“ konforme Darstellung gezeigt werden, die im Einklang mit den dargelegten Konzepten ist (Bild 10). I4.0-Komponente durch Gegenstand abgebildet Ist einer der Gegenstände der I4.0-Komponente I4.0- konform kommunikationsfähig (CP34- oder CP44 nach [3], so bietet sich an, die I4.0-Komponente durch den Gegenstand abzubilden (Bild 11). www.vdi.de
  • 21. Referenzarchitekturmodell Industrie 4.0 19 Bild 10. Repository Bild 11. Lebenszyklus der Fabrik www.vdi.de
  • 22. 20 Referenzarchitekturmodell Industrie 4.0 Bild 12. Kapselfähigkeit und Vernetzung einer I4.0-Komponente I4.0-Komponente ist kapselfähig Die I4.0-Komponente soll bewusst alle möglichen Querverbindungen innerhalb der I4.0-Fabrik eingehen bzw. aufbauen können (Bild 12, Nr. 1). Doch diese Vernetzung darf nicht zur Einschränkung der Kern- funktionalität führen (Bild 12, Nr. 2). Die Fähigkeit, diesen Kernbereich störungsfrei zu erhalten, selbst wenn die „äußere“ Vernetzung Störungen unterliegt, wird durch SG2 (ZVEI Spiegelgremium Referenz- architektur) und SG4 (ZVEI Spiegelgremium Securi- ty) als „kapselfähig“ bezeichnet. Anforderung: Die I4.0-Komponente, insbesondere die Verwaltungs-Schale, ihre enthaltene Funktiona- lität und die damit befassten Protokolle sollen „kapselfähig“ sein. Das vorliegende Konzept verwirklicht diese Anforde- rung dadurch, dass die Verwaltungs-Schale als unab- hängiges Daten-/Funktionsobjekt ausgeführt wird. Der Zugriff auf die darin enthaltenen Daten und Funk- tionen soll nach dem Prinzip von „Separation of Con- cerns (SoC)“ gestaltet werden, sodass eine Beeinflus- sung von für die Fertigung kritischen Abläufen nach dem Stand der Technik ausgeschlossen werden kann. Aus der Anwendung dieses Prinzips folgt, dass die I4.0-konforme Kommunikation nach heutigem Stand in der Fertigung verwendete Ethernet-basierte Feld- busse nicht vollständig ersetzen muss (Migrations- szenario). Allerdings sollen I4.0-konforme Kommunikation und eine mögliche deterministische oder Echtzeit-Kom- munikation aufeinander abgestimmt sein und z. B. nach Möglichkeit die gleichen (physikalischen) Schnittstellen und Infrastrukturen verwenden. Die Widerspruchsfreiheit zwischen beiden Kommunikati- onskanälen muss gewährleistet sein. Für das in diesem Text beschriebene Referenzmodell bedeutet diese Argumentation, dass I4.0-konforme Kommunikation nicht sämtliche Eigenschaften einer deterministischen oder Echtzeit-Kommunikation selbst realisieren muss, sondern sie an bestehende Technologien delegieren kann. Anspruch der I4.0-Komponente ist, nicht I4.0-kon- forme Kommunikationsbeziehungen, die in die Gegenstandsschale führen oder diese verlassen, zu erfassen und einem durchgängigen Engineering zu öffnen. Die heute üblichen Echtzeit-Ethernet-Protokolle las- sen es möglich erscheinen, beide Kommunikationen über die gleiche Kommunikationsinfrastruktur (An- schlüsse, Stecker, Zwischenstationen) abzuwickeln (Bild 12, Nr. 3). Nach dem Prinzip „Separation of Concern“ sind aber beide Kommunikationsarten lo- gisch weiterhin getrennt. Eine I4.0-Komponente kann mehrere Gegenstände enthalten Dieser Abschnitt zeigt an einem Beispiel, dass eine I4.0-Komponente nicht nur ein, sondern mehrere Gegenstände enthalten kann. www.vdi.de
  • 23. Referenzarchitekturmodell Industrie 4.0 21 Bild 13. I4.0-Komponente, bestehend aus meh- reren Gegenständen Die in der Bild 13 gezeigten Gegenstände formen zusammen ein beispielhaftes elektrisches Achssystem. Von einem Hersteller gibt es eine Auslegungssoft- ware, die während der Engineering-Phase dazu ge- führt hat, dass die einzelnen Teilsysteme zu einem System kombiniert wurden. Vom Hersteller gibt es eine Konfigurationssoftware, mit der das System als Ganzes in Betrieb gesetzt werden kann. Verfahrsätze, aufgezeichnete Verschleißdaten und das Condition Monitoring müssen die einzelnen Systembestandteile miteinander in Bezug setzen (z. B. bezüglich maxima- ler Verfahrlänge). Daher ist es aus I4.0-Sicht sinnvoll, diese einzelnen Gegenstände als ein System zu verwalten und als eine I4.0-Komponente abzubilden. Eine Zerlegung in ein- zelne I4.0-Komponenten würde die Abbildung vieler verschiedener Sinnzusammenhänge durch ein oder sogar mehrere übergeordnete I4.0-Systeme erfordern und unnötig verkomplizieren. Eine I4.0-Komponente kann logisch schachtelbar sein Industrie 4.0 fordert die Modularisierung von Produkti- onssystemen für auftragsgerechte Rekonfiguration und Wiederverwendung von (Unternehmens-)Assets im Rahmen von I4.0-Aspekt (2) „Vertikale Integration“. Daher sieht das Konzept vor, dass eine I4.0-Kompo- nente andere Komponenten logisch umfassen, als Ein- heit agieren und für ein übergeordnetes System logisch abstrahieren kann. Zudem fordert I4.0-Aspekt (3) „Durchgängigkeit im Engineering“, dass für möglichst viele Gegenstände eines Produktionssystems weiterführende Daten und Engineering-Planungen online verfügbar sind. Die Verwaltungs-Schale sieht vor, dass Daten, die den Gegenständen der I4.0-Komponente eindeutig zuge- ordnet werden können, auch derart verteilt verfügbar sind. Derart verteilte Daten sind für ein verteiltes Engineering und für eine schnelle Rekonfiguration von Vorteil. Bild 14. Schachtelbarkeit von I4.0-Komponenten Daher soll das Konzept für eine I4.0-Komponente vorsehen, dass einer I4.0-Komponente (z. B. einer ganzen Maschine) andere I4.0-Komponenten logisch zugeordnet werden, sodass sich eine (temporäre) Schachtelung ergibt. Technisch gesehen kann dieses so ausgeführt werden, dass der übergeordnete Gegenstand (z. B. eine Ma- schine) zwei I4.0-konforme Kommunikationsschnitt- stellen ausprägt, sodass sich eine klare logische und physikalische Trennung von übergeordneten und untergeordneten I4.0-Komponenten ergibt (Bild 14, Nr. 1). Eine weitere Möglichkeit besteht darin, dass die I4.0-konforme Kommunikation „oben“ und „un- ten“ physisch eins sind, aber logisch voneinander getrennt werden (Bild 14, Nr. 2). Um eine solche logische Zuordnung von „untergeord- neten“ I4.0-Komponenten zu managen, kann die Verwaltungs-Schale ein geeignetes „Komponenten- Management“ vorsehen. Dieses kann z. B. die Rekon- figuration einer Maschine unterstützen oder aber den Status der Maschine „nach oben“ geeignet abbilden. Anforderung: Einer I4.0-Komponente (z. B. einer ganzen Maschine) sollen andere I4.0-Komponenten logisch zugeordnet werden können, sodass sich eine (temporäre) Schachtelung ergibt. Anforderung: Übergeordnete Systeme sollen zweckgebunden und einschränkbar auf alle I4.0- Komponenten zugreifen können, auch wenn diese (temporär) logisch zugeordnet sind. www.vdi.de
  • 24. 22 Referenzarchitekturmodell Industrie 4.0 Zustandsmodell Der Zustand einer I4.0-Komponente ist von anderen Teilnehmern einer I4.0-konformen Kommunikation immer abrufbar. Er folgt dabei einem definierten Zustandsmodell. Da I4.0-Komponenten hierarchisch organisiert sein können, sollte eine geeignete Abbildung von Unterzu- ständen in einen Zustand definiert werden („Was bedeutet es für die Maschine, wenn ein Teil nicht betriebsbereit ist?“). Zusätzlich soll das Zustandsmodell auch mit einer größeren Menge von Zustandsvariablen komplemen- tiert werden, die eine detaillierte Sicht auf die Zustän- de der Virtuellen Repräsentation und der fachlichen Funktionalität erlauben. Dies erlaubt zu einem Zeit- punkt „t“ eine konsistente Sicht auf den Zustand einer I4.0-Komponente, etwa zum Zweck der statistisch korrekten Datenanalyse. Allgemeine Merkmale der „I4.0-Komponente“ Der VDI/VDE-GMA FA 7.21 definiert den Begriff „Komponente“ im Kontext zu Industrie 4.0 wie folgt: Der Begriff „Komponente“ ist allgemein. Er bezeich- net einen Gegenstand der physischen Welt oder der Informationswelt, der in seinem Systemumfeld eine bestimmte Rolle spielt oder für eine solche vorgese- hen ist. Eine Komponente kann z. B. ein Rohr, ein SPS-Funktionsbaustein, eine Lampe, ein Ventil, eine intelligente Antriebseinheit sein. Wichtig ist die Be- trachtung als Einheit und der Bezug zu der Rolle (Funktion), die sie in einem System wahrnehmen soll oder bereits wahrnimmt. Als I4.0-Komponente be- zeichnen wir eine spezielle Art von Komponente. I4.0-Komponenten zeichnen sich dadurch aus, dass sie bezüglich der oben dargestellten Klassifikations- merkmale bestimmte Anforderungen erfüllen. Auch in einem I4.0-System gibt es viele Komponenten, die diese Anforderungen nicht erfüllen und die damit keine I4.0-Komponenten sind. Das hier vorliegende Konzept lässt auch Gegenstände zu, die passiv oder aktiv, aber nicht I4.0-konform kommunikationsfähig sind. Daher gilt für die I4.0- Komponente im Sinne dieses Dokuments:  Sie ist bezüglich der CP-Klassifikation entweder eine CP24, CP34 oder eine CP44-Komponente.  Sie besitzt eine Verwaltungs-Schale, die so kom- muniziert werden kann, dass sie zu einem vollwer- tigen Dienstsystemteilnehmer im I4.0-Netzwerk wird. Der folgende Abschnitt wurde auf Basis der GMA- Definition verfeinert und stellt daher eine Detaillie- rung der Konzepte dar. In voller Übereinstimmung mit dem VDI-Statusreport „Gegenstände, Entitäten, Komponenten“ [3] werden als Dienstsystemteilneh- mer im I4.0-Netzwerk von einer I4.0-Komponente zunächst folgende Merkmale verlangt (Anforderun- gen): Identifizierbarkeit Sie ist im Netzwerk eindeutig identifizierbar und ihre physischen Gegenstände werden mittels eines einein- deutigen Identifiers (ID) identifiziert. Ist sie eine CP34- oder CP44-Komponente; so ist sie über eine Kommunikationsadresse (z. B. IP-Adresse) erreich- bar. I4.0-konforme Kommunikation Die I4.0-Komponenten kommunizieren untereinander mindestens nach dem SOA Prinzip (inklusive ge- meinsamer I4.0-konformer Semantik). I4.0-konforme Dienste und Zustände Sie unterstützt die für ein I4.0-System allgemein stan- dardisierten (auch nachladbaren) Dienstfunktionen und Zustände. Virtuelle Beschreibung Sie liefert ihre virtuelle Beschreibung einschließlich ihres dynamischen Verhaltens. Diese Beschreibung wird durch die Virtuelle Repräsentation und das Manifest erreicht. I4.0-konforme Semantik Sie unterstützt die für ein I4.0-System standardisierte I4.0-konforme Semantik. Security und Safety Sie bietet für ihre Funktionalität und Daten einen der Aufgabe entsprechenden ausreichenden Schutz (Security). Zusätzlich können in Anwendungen auch Maßnahmen zur funktionalen Sicherheit, Maschinen- sicherheit notwendig sein (Safety). Quality of Services Sie besitzt die für ihre Aufgabe erforderlichen Eigen- schaften als „Quality of Services“ (QoS). Bezüglich der Anwendung in der Automatisierungstechnik sind www.vdi.de
  • 25. Referenzarchitekturmodell Industrie 4.0 23 dies Eigenschaften wie Echtzeitfähigkeit, Ausfallsi- cherheit, Uhrensynchronisation. Diese Eigenschaften richten sich möglicherweise nach einem Profil aus. Zustand Sie liefert jederzeit ihren Zustand. Schachtelbarkeit Jede I4.0-Komponente kann aus weiteren I4.0-Kom- ponenten bestehen. I4.0-Komponenten im Kontext dieses Dokuments stehen für Produktionssysteme, Maschinen, Stationen und konzeptuell wichtige Teile bzw. Baugruppen von Maschinen. Zu Merkmal (1): Identifizierbarkeit Ziel des I4.0-Ansatzes ist es, auf alle relevanten Daten in Echtzeit zugreifen zu können. Die I4.0-Komponen- ten stellen einen wichtigen Teil einer gegenüber heute erweiterten Infrastruktur dar. Dies gilt während der gesamten Lebenszeit des Produktionssystems. I4.0- Komponenten spielen also auch in allen I4.0-Wert- schöpfungsketten [3] und allen ihren Wertschöpfungs- prozessen eine zentrale Rolle für den durchgängigen und einheitlichen Informationsaustausch. Eine aktive I4.0-Komponente kann I4.0-konforme Kommunikation selbst abwickeln; für eine passive I4.0-Komponente erledigt dies die notwendige Infra- struktur. Es besteht die Notwendigkeit für eine den industriel- len Anforderungen gerecht werdende Kommunikati- on. Da Produktionssysteme immer mehr im Verbund arbeiten und dabei auch größere Entfernungen über- brückt werden müssen, wird die Verbindung lokaler Netze mittels der Weitverkehrstechnik immer wichti- ger. Anforderung: Bei der Vernetzung von I4.0-Kom- ponenten sollte sich die Weitverkehrstechnik so verhalten, dass lokale Netze weitgehend ohne Ein- schränkungen über die Weitverkehrsanbindung miteinander kommunizieren können. Dies betrifft die Verfügbarkeit solcher Verbindungen, die Sicherheit (Security), aber auch das zeitgerechte Verhalten. Wenngleich Streaming-Technologien und andere Mechanismen eine Basis für passende Lösun- gen darstellen könnten, sind hierzu noch grundlegen- de Arbeiten erforderlich. Eine Ebene höher müssen Verbindungen dafür sor- gen, dass die Kommunikation zuverlässig und stabil über einen langen Zeitraum garantiert ist. Hier sind bestehende Protokolle auf ihre Tauglichkeit in I4.0- Anwendungen zu prüfen. Zu unterscheiden ist die Adressierung der I4.0-Komponente und die Adressie- rung ihrer (Anwendungs-)Objekte. Diese werden mittels einer weltweiten und herstellerübergreifenden eineindeutigen ID angesprochen. Zum Umgang mit IDs sei auf [5] und [6] und andere Standards verwie- sen. Anforderung: Zu unterscheiden ist die Adressie- rung der I4.0-Komponente und die Adressierung ihrer (Anwendungs-)Objekte. Zu Merkmal (2): I4.0-konforme Kommunikation Die Selbstauskunft einer I4.0-Komponente wird auf Basis einer serviceorientierten Architektur (SOA) mit Diensten entsprechend einem Dienstemodell realisiert (Resource-Manager). Ein entsprechendes Profil der I4.0-Komponente kann regeln, wie diese Dienste technologisch realisiert werden können (z. B. über OPC-UA-Basisdienste). Zu Merkmal (3): I4.0-konforme Dienste und Zustände Da im „Shop floor“ und im „Office floor“ unter- schiedliche Anwendungen bedient werden müssen, muss die Option bestehen, dass I4.0-Komponenten die verschiedenen Anwendungsebenen mit unterschiedlichen Protokol- len bedienen können. Anforderung: Protokolle und Anwendungsfunkti- onen sollen daher optional nachladbar sein. Zu Merkmal (4): Virtuelle Beschreibung Die Informationen zur Beschreibung der Eigenschaf- ten einschließlich des relevanten dynamischen Ver- haltens einer I4.0-Komponente werden aus dem virtu- ellen Abbild der realen Komponente in einem I4.0- Datenformat erzeugt. Dieses Abbild wird als „Virtuel- le Repräsentation“ bezeichnet; Teil der Virtuellen Repräsentation ist das Manifest, das mit einer eindeu- tigen Semantik belegt sein muss. Dabei spielt die Spezifikation von Merkmalen eine wichtige Rolle. www.vdi.de
  • 26. 24 Referenzarchitekturmodell Industrie 4.0 Teile des Manifests sind beispielsweise:  charakteristische Merkmale der realen Komponente  Informationen über Beziehungen der Merkmale untereinander  Produktions- und Produktionsprozess-relevante Beziehungen zwischen I4.0-Komponenten  formale Beschreibung relevanter Funktionen der Maschine und ihrer Abläufe Teile der Virtuellen Repräsentation sind beispiels- weise:  kaufmännische Daten  historische Daten, z. B. Servicehistorie  u. a. m. Abgrenzung zwischen Manifest im Besonderen und Verwaltungsobjekten im Allgemeinen ist, dass das Manifest Informationen enthält, die für die Verwirkli- chung eines „I4.0-konformen Netzwerks“ entspre- chend den I4.0-Aspekten nach einer eindeutigen Se- mantik öffentlich bekannt sein müssen. Verwaltungs- objekte können auch solche Informationen tragen, bei denen der Hersteller selbst entscheiden kann, was in welcher Form er offenlegen möchte. Zu Merkmal (5): I4.0-konforme Semantik Der Informationsaustausch zwischen zwei oder meh- reren I4.0-Komponenten erfordert eine eineindeutige Semantik. Diese muss mittels der unter Merkmal (4) aufgeführten Charakteristika I4.0-weit festgelegt werden. Hilfreich erscheint nach [5] die Klassifikation der Merkmale nach folgenden Feldern:  Mechanik  Funktionalität  Örtlichkeit  Leistungsfähigkeit  geschäftliche Rahmenbedingungen Zum Umgang mit Merkmalen sei auf [5], [6] und [7] verwiesen. Zu Merkmal (6): Security und Safety Jede I4.0-Komponente weist eine Mindestinfrastruk- tur zur Sicherstellung der Security-Funktionen auf. Da Security nur sichergestellt ist, wenn die jeweiligen Produktionsprozesse in die Security-Betrachtungen unmittelbar einbezogen sind, stellt die Security- Infrastruktur einer I4.0-Komponente zwar notwendi- ge, aber bei Weitem nicht hinreichende Funktionalität zur Verfügung. Muss die funktionale Sicherheit, Ma- schinensicherheit (Safety) sichergestellt werden, so hat dies Einfluss auf die Eigenschaften der einzelnen I4.0-Komponenten. Zusätzliche Merkmale müssen hier erfasst, bewertet und an übergeordnete Systeme weiter gegeben werden Anforderung: Die Mindestinfrastruktur muss den Prinzipien von „Security-by-Design“ (SbD) gerecht werden. Zu Merkmal (7): Quality of Services Die Anwendung einer I4.0-Komponente in einer be- stimmten Umgebung bestimmt deren Anforderungen. Die in der jeweiligen Umgebung geforderten Eigen- schaften (QoS) müssen daher schon bei der Auswahl der Komponenten für eine Maschine oder Anlage berücksichtigt werden. Speziell für Automatisie- rungsumgebungen sind das Eigenschaften wie:  Zeitspanne der Echtzeit für die Produktivkommu- nikation, z. B. Deterministik mit Echtzeitfähigkeit von D1ms.  höchste Ausfallsicherheit bezüglich der umgeben- den Netzinfrastruktur (Robustheit)  Uhrensynchronisation  Interoperabilität  Diagnose und Engineering auf Basis einheitlicher Regeln  Aufbau von Ad-hoc-Verbindungen Zu Merkmal (8): Zustand Da jede I4.0-Komponente Teil eines Verbunds mit bestimmten Aufgaben darstellt und diese Aufgaben in Prozessen koordiniert erledigt werden, muss der Zu- stand jeder I4.0-Komponente zu jedem Zeitpunkt von anderen Teilnehmern eines I4.0-konformen Kommu- nikationsnetzwerks abrufbar sein. Diese Informatio- nen dienen der lokalen Verwaltung anderer I4.0-Kom- ponenten und der globalen Verwaltung zur Koordina- tion der Abläufe. www.vdi.de
  • 27. Referenzarchitekturmodell Industrie 4.0 25 Zu Merkmal (9): Schachtelbarkeit I4.0-Komponenten können zu einer I4.0-Komponente zusammengefasst werden. So kann beispielsweise eine Maschine sich als I4.0-Komponente darstellen. Sie selbst kann aus eigenständigen I4.0-Komponenten bestehen, z. B. eine modulare Maschine. Und auch die einzelnen Maschinenmodule können wieder in einzel- ne I4.0-Komponenten gegliedert werden. 2.5 Glossar Industrie 4.0 Im Rahmen von Industrie 4.0 wachsen die Sprachen von Produktion und IKT (Informations- und Kommu- nikationstechnologie) zusammen. Es existieren jedoch historisch begründete Unterschiede und Unklarheiten bei wichtigen Begriffen rund um Industrie 4.0. Die Arbeitsgruppe „Begriffe“ im Fachausschuss 7.21 „Industrie 4.0“ der VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik (GMA) unter der Leitung von Frau Dr.-Ing. Miriam Schleipen vom Fraunhofer IOSB ist bemüht, eine gemeinsame „Basis“ (Termino- logie) von Industrie 4.0 im Sinne sprachlicher und gedanklicher Konstrukte zu erarbeiten. Die Arbeiten erfolgen zudem in enger Zusammenarbeit mit den zuständigen Komitees (z. B. DKE/UK 921.1) des Fachbereichs 9 der DKE (z. B. DKE/UK 921.1). und werden mit der AG2 „Referenzarchitektur“ der Platt- form Industrie 4.0 abgestimmt. Ziel ist ein gemeinsames Verständnis der grundlegen- den Begriffe! Dabei wird auf bestehenden Normen und Standards aus den Bereichen IKT und Produktion aufgesetzt. Im Umfeld von Industrie 4.0 werden Begrifflichkeiten und Konzepte aus unterschiedlichen Domänen aufge- griffen (etwa aus dem IKT-Bereich die Orchestrierung von Diensten in einer serviceorientierten Umgebung). Manche Begrifflichkeiten sind aber in den beteiligten Domänen unterschiedlich besetzt (etwa Service (Dienst) im IKT-Bereich gegenüber der Produktion). Andere Begriffe sind sogar innerhalb einer Domäne mehrdeutig oder unpräzise (etwa Komponente). Diese sprachlichen und konzeptionellen Unterschiede und Ungenauigkeiten sowie der Bedarf nach Erklärungen zu „fachfremden Konzepten“ sind ein Hindernis in der Entwicklung übergreifender komplexer techni- scher Lösungen für Industrie 4.0 und in der Normung. Mit dem Glossar wird also eine gemeinsame Basis für Begrifflichkeiten im Rahmen von Industrie 4.0 ge- schaffen werden, die die unterschiedlichen Sichtwei- sen und Anforderungen berücksichtigt. Dies soll die Zusammenarbeit über die Grenzen von Unternehmen und Branchen hinweg erleichtern und ist Vorausset- zung für die Normung. Die aktuellen Definitionen sind u. a. auf folgender Webseite zu finden: www.iosb.fraunhofer.de/?BegriffeI40 www.vdi.de
  • 28. 26 Referenzarchitekturmodell Industrie 4.0 Autoren Dr. Peter Adolphs (Pepperl+Fuchs) Dr. Heinz Bedenbender (VDI) Dr. Dagmar Dirzus (VDI) Martin Ehlich (Lenze SE) Prof. Ulrich Epple (RWTH Aachen) Martin Hankel (Bosch Rexroth AG) Roland Heidel (Siemens AG) Dr. Michael Hoffmeister (Festo AG & Co.KG) Haimo Huhle (ZVEI) Bernd Kärcher (Festo AG & Co.KG) Dr. Heiko Koziolek (ABB) Reinhold Pichler (DKE) Stefan Pollmeier (ESR Pollmeier) Frank Schewe (Phoenix Contact) Dr. Armin Walter (Lenze) Bernd Waser (Murrelektronik) Prof. Dr. Martin Wollschlaeger (TU Dresden) Schrifttum [1] VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik: Statusbericht; Industrie 4.0; Wertschöpfungsketten. Düssel- dorf: VDI e.V., April 2014 [2] VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik: Statusbericht; Industrie 4.0; Auf dem Weg zu einem Refe- renzmodell. Düsseldorf: VDI e.V., April 2014 [3] VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik: Statusbericht; Industrie 4.0; Gegenstände, Entitäten, Kompo- nenten. Düsseldorf: VDI e.V., April 2014 [4] Acatech Studie, Umsetzungsempfehlungen für das Zukunftsprojekt Industrie 4.0, Abschlussbericht des Arbeitskreises In- dustrie 4.0. http://www.bmbf.de/pubRD/Umsetzungsempfehlungen_Industrie4_0.pdf [5] IEC TR 62794: Industrial-process measurement, control and automation – Reference model for representation of production facilities (Digital Factory), 2012 [6] IEC CD 62832: Industrial-process measurement, control and automation - Reference model for representation of production facilities (Digital Factory), 2014 [7] IEC 61987-10: Industrial-process measurement and control - Data structures and elements in process equipment catalogues - Part 10: Lists of properties (LOPs) for industrial-process measurement and control for electronic data exchange - Funda- mentals, 2009 www.vdi.de
  • 29. Referenzarchitekturmodell Industrie 4.0 27 Der VDI Sprecher, Gestalter, Netzwerker Ingenieure brauchen eine starke Vereinigung, die sie bei ihrer Arbeit unterstützt, fördert und vertritt. Diese Aufgabe übernimmt der VDI Verein Deutscher Ingenieure e.V. Seit über 150 Jahren steht er Ingenieurinnen und Ingenieuren zuverlässig zur Seite. Mehr als 12.000 ehrenamtliche Experten bearbeiten jedes Jahr neueste Erkenntnisse zur Förderung unseres Technikstandorts. Das überzeugt: Mit rund 154.000 Mitgliedern ist der VDI die größte Ingenieur- vereinigung Deutschlands. Über den ZVEI Der ZVEI – Zentralverband Elektrotechnik- und Elektronikindustrie e.V. Der ZVEI vertritt die Interessen von 1.600 Unternehmen der Elektroindustrie und zugehöriger Dienstleistungsunter- nehmen in Deutschland. Jede dritte Neuerung im Verarbeitenden Gewerbe in Deutschland erfährt ihren originären Anstoß aus der Elektroindustrie. Die Branche beschäftigt 850.000 Arbeitnehmer im Inland und weitere 690.000 weltweit. www.vdi.de
  • 30.
  • 31.
  • 32. Verein Deutscher Ingenieure e.V. VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik Dr.-Ing. Dagmar Dirzus Geschäftsführerin VDI-Platz 1 40468 Düsseldorf Tel. +49 211 6214-227 dirzus@vdi.de www.vdi.de ZVEI – Zentralverband Elektrotechnik und Elektronikindustrie e.V. Fachverband Automation Dipl.-Ing. Gunther Koschnick Geschäftsführer Lyoner Straße 9 60528 Frankfurt am Main Tel. +49 69-6302-318 koschnick@zvei.org http://www.zvei.de