Kommunikation der Zukunft


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.


  • Maintenance verzeichnet Besucherzuwachs

    Mit einem Besucherzuwachs von 25 Prozent ziehen die Veranstalter der Messen Maintenance und Pumps & Valves ein positives Fazit und wollen die…


  • Koenig & Bauer setzt Wachstumskurs fort

    Koenig & Bauer hat im zurückliegenden Geschäftsjahr 2023 seinen Wachstumskurs aus dem Vorjahr fortgesetzt. Demnach stieg der Umsatz des Konzerns um 12%…


  • Verbindungstechnik neu gedacht

    Edelstahl ist der Materialstandard für Installationen im Reinraum, für Abfüll-, Verpackungs- und Förderanlagen in der Lebensmittelindustrie und für alle korrosionsgefährdeten Bereiche. Leider…


  • NEONEX, Fabasoft Approve & KSB: „Win-win-win-Situation“ durch starke Partnerschaft

    Im Zuge einer Smart-Factory-Potenzialanalyse für ihren Kunden KSB identifizierte die Managementberatung NEONEX Opti mierungschancen bei der Beschaffung der Lieferantendokumentation sowie der Erstellung…