Dr. Peter Adolphs verstarb am 24.10.2016. Wir führten dieses Interview mit Ihm einige Monate vor seinem Tod.

Sie waren maßgeblich daran beteiligt, die neue Referenzarchitektur für Industrie 4.0 – kurz RAMI 4.0 - zu entwickeln. Herr Dr. Adolphs, wie unterscheidet sich die darin enthaltene Industrie-4.0-Komponente eigentlich von einer regulären Komponente in einer Anlage?

Dr. Peter Adolphs: Eine Industrie-4.0-Komponente – wir nennen sie der Einfachheit halber I4.0-Komponente – ist ein abstraktes Modell für die Beteiligten einer I4.0 kompatiblen Kommunikation und Vernetzung. Das muss man zunächst verstehen. Dahinter kann sich genauso ein Sensor verbergen wie eine komplette Maschine. I4.0-Komponenten sind zum einen die Bestandteile einer Produktionsanlage, die es auch bisher schon gibt und die auch bisher schon miteinander kommunizieren. Neu hinzu kommt, dass auch ein Werkstück selbst als I4.0-Komponente modelliert wird. So kann es mit der Maschine oder mit Anlagenteilen kommunizieren und zum Beispiel mitteilen, wie es bearbeitet werden soll. Außerdem endet das Automatisierungsmodell nicht wie bisher am Fabriktor. Im Sinne der Connected World kann auch eine komplette Fabrik eine I4.0-Komponente sein und via Internet automatisiert mit anderen Fabriken Geschäfte machen. So könnte eine Fabrik zum Beispiel mit einer anderen Fabrik aushandeln, dass sie ein bestimmtes Bauteil benötigt, wenn beide als I4.0-Komponenten agieren.

Dazu müssen I4.0-Komponenten miteinander sprechen. Wie funktioniert das?

Für jede I4.0-Komponente gibt es eine Art digitalen Zwilling, wir nennen das Verwaltungsschale. In dieser Schale sind alle Daten zur jeweiligen I4.0-Komponente gespeichert. Dabei finden sich in der Verwaltungsschale nicht nur aktuelle Zustandsdaten sondern auch die komplette Datensammlung über den Lebenszyklus der Komponente. Auch das ist ein neuer Aspekt bei I4.0. Sie kann entweder in das Asset eingebettet sein oder sich separat in der Cloud befinden. Will nun eine I4.0-Komponente etwas von einer anderen I4.0-Komponente wissen, fragt sie nicht die Komponente selbst, sondern ihren digitalen Zwilling.

Klingt ein wenig wie die Treiber in der IT-Welt. Lässt sich das vergleichen?

Der Begriff Treiber stammt noch aus einer alten Denkweise, deshalb sollte man vorsichtig mit einem Vergleich sein. Es geht schon in die Richtung, aber Treiber sind eher passive Elemente. Die Verwaltungsschale hingegen kann auch selbst aktiv werden.

Die IT-Welt dient aber grundsätzlich als Vorbild für RAMI 4.0?

Selbstverständlich. Das ist ja der Ansatz von I4.0, dass die Möglichkeiten des Internets und der IT-Welt auf die Fabrik übertragen werden. Im Gegensatz zur Automatisierungspyramide sind zum Beispiel die Hierarchien im RAMI-Modell aufgelöst. Alle I4.0-Komponenten sind über ihre Verwaltungsschale mit demselben Netzwerk verbunden und können direkt untereinander kommunizieren. Dabei kann das I4.0 Netz rein firmenintern begrenzt sein oder aber auch über das Internet über das Werkstor hinaus reichen. Wie das im Einzelnen realisiert wird, ist dabei auch eine Frage der Security-Policy des Betreibers. Theoretisch könnte z.B. ein Sensor über das Internet von außen abgefragt werden. Das macht in vielen Fällen sicherlich keinen Sinn, es sind aber Fälle denkbar wo das durchaus sinnvoll ist. Denkbar sind z.B. Geschäftsmodelle, wo nicht mehr der Sensor als Asset verkauft wird, sondern eine sensorisch ermittelte Information wird. Dies ist alles im RAMI Referenzmodell schon vorgesehen. Das klingt vielleicht utopisch, aber I-Phone Benutzer nutzen einen solchen Service schon heute, wenn Sie um die Temperatur vor der Haustür zu erfahren nicht selbst ein Thermometer raushängen, sondern auf den entsprechenden lokalen Wetterdienst zugreifen.

Das amerikanische Modell des Internet of Things sieht genau diese wilde Kommunikation von Einzelkomponenten vor. Warum wollen Sie das einschränken?
Genau in diesem Punkt unterscheiden wir uns sehr stark von der amerikanischen IoT-Definition. Wenn in einer Anlage jeder mit jedem kommuniziert, erzeugt das erst mal unnötig Traffic. Unser RAMI-Modell grenzt das ein, indem das Anlagenengineering sinnvolle Hierarchien vorgibt und I4.0-Komponenten dadurch in ihrer Kommunikationsfähigkeit kapselt. So wird sichergestellt, dass man von außen nur auf ein bestimmtes Maschinenteil zugreifen kann, nicht aber auf jeden einzelnen Sensor. Man muss sich das analog zum Internet vorstellen. Da gibt es viele Seiten, die jeder lesen kann. Und dann gibt es Homepages, auf die man nur mit dem entsprechenden Abo zugreifen kann.
Die Neuerung dabei ist, dass die Hierarchie-Levels zwischen den I4.0-Komponenten nicht mehr durch Verdrahtung vorgegeben sind, sondern durch Software – sprich durch Programmierung. Das macht die Anlage sehr flexibel. Bisher war ein bestimmter Sensor zum Beispiel mit einem festen Eingang – sagen wir Input 27 – an der SPS verdrahtet und konnte nur mit diesem IO-Gerät Daten austauschen. Im Sinne von RAMI lassen sich die Hierarchielevel nun dynamisch zuordnen. Schließlich hängt jeder Sensor, jede Klemme, jeder Antrieb am I4.0-Netz und kann theoretisch mit jeder anderen I4.0-Komponente sprechen. Über Software wird aber definiert, wer mit wem kommunizieren darf. Der Maschinen- oder Anlagenbauer entscheidet also, welche Daten des Sensors er quasi in die freie Wildbahn wirft und welche Daten er privat hält. Zudem ist das eine zusätzliche Möglichkeit die Security einer Anlage durch individuelles Engineering zu erhöhen.

Welches Kommunikationsnetz nutzen I4.0-Komponenten eigentlich?

Grundsätzlich läuft die Kommunikation im I4.0 Netz auf IP-Basis. D.h. hier kann die normale Verkabelung, die von den Ethernet basierten Feldbussen vorgegeben ist, mit benutzt werden. Wir gehen aber davon aus, dass der Echtzeit-Datenverkehr zwischen Sensor und Steuerung noch eine ganze Zeit lang nicht über den I4.0-Kanal der Verwaltungsschale -abgedeckt wird, sondern weiterhin direkt abläuft. Nur so sind derzeit die harten Echtzeitanforderungen realisierbar. Auf mittlere Sicht werden die beiden Kanäle jedoch zusammenwachsen.
Auch die Netzwerkgeschwindigkeit für Verbindungen außerhalb der Fabrik wird weiter steigen, so arbeitet die Telekom momentan am 5G-Kommunikationsstandard, der auch schon wichtige, notwendige Security-Funktionen enthält. Damit wird eine I4.0-Kommunikation voraussichtlich auch über eine Internetverbindung funktionieren. Dann wäre auch der Feldbus-Krieg beendet (lacht).

I4.0-Komponenten sollen also in Zukunft über den I4.0-Kanal kommunizieren, der das Telekommunikationsnetz verwendet. Was ist dazu neben einer Echtzeitfähigen Geschwindigkeit außerdem notwendig?

Wir müssen zügig entscheiden, welches Kommunikationsinterface in dieser serviceorientierten Architektur – kurz SOA-Architektur - genutzt wird. OPC UA wäre da als Basis geeignet. Aber auch hier fehlt die Semantik, also die Erklärung, wie ein bestimmter Befehl zu verstehen ist. Für Sensoren und Aktoren lässt sich zum Beispiel die Semantik im Rahmen von Prolist eclass beschreiben. Man könnte also für alle I4.0-Komponenten, die zu den Sensoren zählen, die Datensätze in Prolist-Form in einem OPC-UA-Telegramm übertragen, das wiederum über den I4.0-Kanal kommuniziert. Auch EDDL, die Electronic Device Description Language, könnte als Semantik für bestimmte Feldgeräte dienen.
Zu den I4.0-Komponenten zählen aber nicht nur Sensoren oder Feldgeräte, sondern auch komplexere Produkte wie eine ganze Maschine. Was ändert das in Bezug auf die I4.0-Kommunikation?
Im Grunde muss für jede mögliche I4.0-Komponente die passende Semantik definiert werden, denn eine Maschine verwendet ganz andere Befehle als ein Sensor. Meiner Meinung nach müssen die verschiedenen Stakeholdergruppen wie zum Beispiel die Werkzeugmaschinenhersteller oder auch alle anderen Gruppen von Maschinenherstellern eine gemeinsame Semantik für ihre Maschinen definieren. Wir als Plattform ‚Industrie 4.0‘ werden basierend auf dem RAMI Modell die Grundlagen für eine I4.0-Semantik erarbeiten, die Details für einzelne Maschinen und Maschinenteile können jedoch nur die entsprechenden Hersteller selbst definieren.

Pepperl+Fuchs bietet viele verschiedene Feldgeräte an. Wie wollen Sie diese Komponenten I4.0-fähig machen?

Indem wir die I4.0-Kommunikation in unsere Feldgeräte implementieren. Dazu muss man letztlich die Funktionalitäten des RAMI-Modells über eine SOA-Schnittstelle in einer Verwaltungsschale anbieten. Im Vorfeld muss aber genormt werden, ob OPC UA oder ein anderes Interface als SOA-Schnittstelle genutzt wird. Das ist die nächste Hürde, die wir überspringen müssen, dass wir uns auf einen Standard einigen und erste Referenzimplementierungen testen.