Hier setzt die Notwendigkeit der Vorgabe eines Referenzmodells an. Die direkte Ankopplung der Komponenten einer Fabrik an die Cloud beschreibt lediglich die hardwareseitigen Vorgaben für die Kommunikation. Darüber hinaus braucht es ein Ordnungsschema, wie die Kommunikation in diesem riesigen IoT-Netzwerk organisiert wird. Diesem Thema hat sich die Arbeitsgruppe 1 aus der Plattform I4.0 in den letzten Monaten gewidmet und dabei das RAMI-Referenzmodell und die Definition der I4.0-Komponente erarbeitet. Nachfolgend werden die Überlegungen, die dazu geführt haben, schrittweise vorgestellt.
Wer kommuniziert?
Um diese Frage zu beantworten muss man sich vor Augen halten, dass es nicht um den Ersatz eines Feldbusses geht, der im Wesentlichen der Übermittlung von aktuellen Mess- und Steuerdaten dient. Unter I4.0 versteht man die abstrakte Vernetzung von Anlagen, Anlagenteilen, ganzen Fabriken, Werkstücken, aber auch CAD-Systemen für das Design von Produkten und Anlagen. Nachfolgend wird hierfür als Sammelbegriff für die Netzwerkteilnehmer der Begriff Assets verwendet. Aus der Auflistung wird klar, dass der gegenseitige Zugriff auch schon vor Fertigstellung der Produktionsanlage möglich ist, in dem z.B. das CAD System, mit dem die Anlage geplant wird, auf bestimmte Spezifikationsdaten der später eingesetzten Komponenten zugreift. Nur wenn man dieses einfache Beispiel vollständig verstanden hat, wird einem der Unterschied zwischen Feldbus und I4.0 richtig klar.
Was wird kommuniziert?
Das Netzwerk dient der Bereitstellung von Daten jedes der Assets aus einer beliebigen Phase seines Lebenszyklus. Man kann also genauso auf die Datenblattangaben wie auf den aktuellen Messwert eines Sensors zugreifen. Dabei muss man unterscheiden in Typ-Daten, die für alle Assets eines Typs gleich sind (z.B. Datenblattangaben) und Instanz-Daten, die einem individuellen Einzelstück zugeordnet werden (z.B. Kalibrierdaten). Bild 2 zeigt dies am Beispiel eines Sensors. Selbstverständlich stehen nicht alle Daten zu jedem Zeitpunkt zur Verfügung. So kann man mit dem CAD-System bei der Planung der Anlage lediglich auf die Typ-Daten des vorgesehenen Sensors zugreifen. Ein Zugriff auf die Instanz-Daten ist erst nach dem Einbau des Sensors in die Anlage möglich. Damit der Datenaustausch effektiv erfolgt, ist es notwendig, die Kommunikation zwischen den Assets zu organisieren. Dazu wurde der Ansatz der Service Oriented Architecture (SOA) gewählt. Jeder Teilnehmer veröffentlicht dazu in einem Verzeichnis seine angebotenen Services. Ein Servicenutzer sucht sich aus dem Verzeichnis den passenden Service aus und baut eine direkte Verbindung auf.
Wie wird kommuniziert?
Ganz wichtig ist es im dritten Schritt noch festzulegen, wie die Services strukturiert werden sollen. Dazu hat man im RAMI-Modell die sogenannten Layer definiert. Bild 3 zeigt das RAMI-Modell. Der Asset-Layer beschreibt die Hardware des Assets selber. Der Integration-Layer umfasst die Einbindung des Assets in die I4.0-IT-Welt. Diese Schnittstelle ist meist herstellerspezifisch und nicht von außen per Service-Zugriff ansprechbar. Darüber liegt der Communication-Layer, der die Funktionalität zum Aufbau von Verbindungen und dem Transfer von Nachrichten enthält. Dies ist der Layer, bei dem sich z.B. OPC UA wiederfinden könnte. Die Ebenen Information- und Functional-Layer sind die eigentlichen Schnittstellen-Layer. Über standardisierte Merkmalsleisten und domänenspezifische Funktionsschnittstellen ist der SOA-Zugriff auf jedes Asset über diese Layer möglich. Der oberste Layer (Business-Layer) ist ein abstrakter IT-Layer, der die Abbildung von ganzen Business-Chains erlaubt. Im RAMI-Modell werden diese drei Aspekte (Wer? Wie? Was?) auf den drei Achsen abgebildet. Insofern ist das Bild eine grafische Darstellung des beschriebenen Kommunikationsmodells für I4.0. Damit ist ein inzwischen allseitig akzeptiertes Modell entstanden, welches hilft, eine einheitliche Sprache zu sprechen. So ist es damit möglich bestimmte existierende Standards (z.B. eCl@ss oder OPC UA) in dieser Grafik zu verorten und damit zu erklären, für welche Teile des I4.0 Modells diese gelten.
I4.0-Komponente
Neben dem Referenzmodell ist aber eine andere Definition von größter Wichtigkeit, nämlich die der I4.0-Komponente. Dazu muss man sich in Erinnerung rufen, dass wir ein Modell suchen, das generisch genug ist, sowohl eine einfache Komponente als auch eine komplette Fabrik zu beschreiben. Um dieser Anforderung Genüge zu tun, wurde die sogenannte Verwaltungsschale definiert. Es handelt sich dabei um ein Stück IT, welches das Interface zwischen dem eigentlichen Asset und dem I4.0-Netzwerk herstellt. Sie ist nicht nur Interface, sondern auch Speicherplatz für die Daten entlang des Lebenszyklus des Assets. Nach außen hat die Verwaltungsschale die standardisierte Schnittstelle und repräsentiert die beschriebenen Daten-, Funktions- und Business-Layer der Komponente. Was die Realisierung der Verwaltungsschale angeht, gibt es ein hohes Maß an Freiheit. Denkbar ist die Realisierung innerhalb der Rechner- und Speicherstruktur des Assets selber als auch eine Realisierung über einen separaten Server. Die zweitgenannte Realisierung dürfte insbesondere für einfache Assets ohne eigene CPU das Mittel der Wahl sein. Für den Zugriff auf die Verwaltungsschale durch andere Assets sind die Ansätze nicht zu unterscheiden. Festzuhalten bleibt, dass ein Asset erst dann zu einer I4.0-Komponente wird, wenn es über eine Verwaltungsschale verfügt, die einen SOA-Zugriff zulässt. Das Modell der I4.0-Komponente bietet vielfältige Möglichkeiten. So ist z.B. die sogenannte Schachtelbarkeit vorgesehen, d.h. mehrere I4.0-Komponenten können zusammengefasst sein und eine gemeinsame Verwaltungsschale haben. Das wäre z.B. der Fall, wenn eine komplette Maschine nach außen lediglich die Funktionalität der Gesamtmaschine per Verwaltungsschale zur Verfügung stellt. Dadurch kann dann z.B. der Zugriff auf einzelne Komponenten innerhalb der Maschine bewusst blockiert sein (z.B. der Einzelzugriff auf einzelne Motoren). Damit wäre eine saubere funktionale Blockbildung erreicht. Parallel dazu könnte man aber z.B. lediglich Diagnosedaten der Sensoren über ihre eigene Verwaltungsschale nach außen zugänglich machen. Diese Daten könnten dann für das Condition Monitoring genutzt werden, ohne die funktionale Integrität zu stören. Man hätte also quasi zwei Sichten auf die Maschine geschaffen, einmal eine funktionale und zum zweiten eine aus Condition Monitoring Sicht. Dieses Modell lässt sich beliebig weiterdenken. Damit werden neue Geschäftsmodelle möglich, die ohne Eingriff in die eigentliche Funktionalität machbar sind. Das ist die eigentliche Chance von I4.0 auf mittlere Sicht.
Verwaltungsschale in der Praxis
Wie könnte die praktische Realisierung der Verwaltungsschale am Beispiel der Sensorik aussehen: Es ist davon auszugehen, dass für einfachste Schalter ohne CPU und Digitalschnittstelle die Verwaltungsschale als separate IT angeboten wird. Eine Integration der Funktionalität in den Schalter wird vermutlich in den nächsten Jahren noch zu kostspielig sein. Diese Geräte werden auch keine Instanz-Daten bieten können, da sie über keinerlei internes Interface zur Verwaltungsschale verfügen. Anders ist das bei Sensoren mit IO-Link-Interface. Zwar ist auch hier eine Verwaltungsschalen-Realisierung auf dem Asset derzeit noch nicht abbildbar, über den IO-Link-Kanal verfügen sie aber über eine digitale Schnittstelle, die Instanz-Daten in die Verwaltungsschale liefern kann. Die dritte Kategorie von Sensoren ist diejenige mit vollwertiger IP-Schnittstelle und CPU. Hier wird sich die Realisierung der Verwaltungsschale auf dem Asset relativ schnell durchsetzen.
Ausblick
Das RAMI-Referenzmodell und die Definition der I4.0-Komponente sind ein wichtiger Zwischenschritt hin zu einer strukturierten und interoperablen Vernetzung von Assets im Automationsumfeld. Diese Sicht wird zwischenzeitlich von vielen Experten geteilt. Die Arbeit der Plattform Industrie 4.0 richtet sich jetzt – basierend auf diesen Vorarbeiten – auf die Erarbeitung von Grundlagen für die Semantik der SOA-Kommunikation. Dabei wird es notwendig sein, diese Grundlagen in die verschiedenen Anwendungsdomänen zu übertragen und zu optimieren. Alle Interessierten sind herzlich eingeladen, sich an diesem Prozess durch aktive Mitarbeit zu beteiligen.
