Zeitweise sah es ja so aus, als wäre in Zukunft jedes ‚Thing‘ im IoT mit einer Internet-basierten Private/Public/Hybrid-Cloud verbunden. Inzwischen wird deutlich, dass dieses Konzept aus unterschiedlichen Gründen in vielen Anwendungsbereichen so nicht funktionieren wird. Im Industrial Internet of Things (IIoT), aber auch im Industrie- 4.0-Umfeld erkennt man schon den veränderten Lösungsansatz: Zwischen Feldebene und Cloud entsteht unter dem Oberbegriff Fog- beziehungsweise Edge-Computing eine serviceorientierte Zwischenschicht. Sie könnte sogar die gesamte Feldebene einer Smart Factory vollständig absorbieren. Das Ziel dabei ist, einzelne Systeme am Rand zur Cloud (at the edge), also im unmittelbaren Umfeld (Nebel = Fog), intelligenter zu machen, mit speziellen Fähigkeiten auszustatten und Sonderaufgaben ausführen zu lassen. Dadurch können die ‚Things im Nebel‘ direkt oder über ein Edge-Gateway untereinander kommunizieren.

Die Kommunikationsbeziehungen einer IIoT- beziehungsweise Industrie-4.0-basierten Smart Factory: Die einzelnen Systeme sind zukünftig in unterschiedlichen Kommunikations-Domains zusammengefasst.

© SSV Software Systems

Automobilhersteller testen zusammen mit Mobilfunknetzbetreibern bereits Cloudlet-Konzepte (Mobil Edge Computing) für autonome Fahrzeuge. Dabei kommunizieren Fahrzeuge und Verkehrsschilder über die Funkzellen-Hardware als Edge-Gateway direkt miteinander, ohne dass die einzelnen Datenpakete über eine Cloud ins Internet geleitet werden. Mit IBM hat sogar ein erster führender IoT-Cloud-Anbieter einen Strategiewechsel vollzogen: Seit einigen Wochen werden die Watson-Analytics-Funktionen nicht mehr nur in der Wolke sondern auch im Cisco-Edge-Router angeboten.

In den USA wurde mit dem ‚OpenFog Consortium‘ inzwischen bereits ein Verband gegründet, der sich diesem speziellen Thema widmet. Die Gründungsmitglieder ARM, Cisco, Dell, Intel, Microsoft und die Princeton University wollen ‚Fog-Technologie‘ zusammen weiterentwickeln und im Markt verbreiten. Dabei werden sie inzwischen auch von GE und Schneider Electric und zahlreichen weiteren Unternehmen und Organisationen unterstützt.

Vielfalt statt hierarchischer Kommunikation

Die gegenwärtigen Kommunikationsstrukturen im industriellen Umfeld lassen sich im Allgemeinen durch eine hierarchische Pyramidenstruktur beschreiben. Ganz unten die Feldebene, darüber eine Steuerungsebene und als Krönung des Ganzen in der Regel mehrere Leitebenen mit unterschiedlichen Aufgaben. Da hätte es funktional sehr gut ins Bild gepasst, oben auf die Pyramide einfach noch eine Cloud-Anbindung draufzusetzen und in der ‚Wolke‘ zum Beispiel Predictive Analytics-Entscheidungen zu fällen oder Intralogistik-Prozesse zu steuern.

Industrie-4.0-basierte Automatisierungslösungen werden mittelfristig aber dafür sorgen, dass die hierarchische Kommunikationspyramide komplett verschwinden wird. Das dreidimensionale RAMI-4.0-Modell lässt sich definitiv nicht mit der vorhandenen Pyramidenstruktur umsetzen. Einfach alle Pyramiden per Cloud miteinander zu verbinden, hilft allerdings auch nicht weiter. Es werden vielmehr Anwendungsarchitekturen mit einzelnen Kommunikations-Domains entstehen, in denen außerdem weitreichende autonome Entscheidungen getroffen werden.

Kommunikations-Domains ersetzen Pyramiden

Das Bild illustriert ein Beispiel mit den zukünftigen Kommunikationsbeziehungen. Die gesamte Automatisierungstechnik (Sensoren, Aktoren, Steuerungen) ist in einer OT-Domain (OT = Operational Technology) zusammengefasst. In dieser Ebene gibt es verschiedene kommunikative Querverbindungen (D2D = Device-to-Device), zum Beispiel OPC UA Pub/Sub per MQTT oder IEEE TSN beziehungsweise RFC 1006 bei älteren Steuerungen. Die zu einer Smart Factory gehörende MES- und ERP-Software ist in der IT-Domain (IT = Information Technology) zu finden.

Alle aus der Smart Factory-Sicht externen Komponenten und Systeme sind Bestandteile einer CT-Domain (CT = Cloud Technology). Hier findet man die Partner-ERP-Systeme einer bestimmten Wertschöpfungskette, Smartphone-Apps, aber auch in der Smart Factory hergestellte Produkte (siehe ‚Connected Product‘ in der CT-Domain), die von Anwendern irgendwo auf der Welt genutzt werden. Sie liefern nun per Internet laufend Betriebs- und Zustandsdaten an das ERP-System des Smart-Factory-Betreibers. Mit Hilfe dieser Daten lassen sich den Produktnutzern zusätzliche Services, wie zum Beispiel Opex-basierte Angebote und Wartungsverträge für eine vorausschauende Instandhaltung, anbieten sowie das be­treffende Produkt auf Basis echter Nutzerdaten weiterentwickeln. Dazu müssen die Daten an ­Produktmarketing und Entwicklung weitergeleitet werden.

Zwischen den einzelnen Domains existieren zahlreiche Verbindungen. So sind einzelne Devices per D2B (Device-to-Business) beziehungsweise D2C (Device-to-Cloud) direkt mit MES-, ERP- und Cloud-Anwendungen oder untereinander verbunden. Die ERP-Systeme zweier Unternehmen etwa, die als Wertschöpfungskettenpartner zusammenarbeiten, sind in Zukunft per B2B-Datenverbindung (B2B = Business-to-Business) miteinander gekoppelt.

Edge-Gateways als Bindeglied

Aus Sicht des bereits angesprochenen ‚OpenFog Consortium‘ bildet die gesamte OT-Domain einer Smart Factory den ‚Fog‘, also den Low-Level-Datennebel. Eine wichtige Rolle in diesem neuen Leitbild spielt die Baugruppe an der Grenze zwischen OT- und IT- beziehungsweise CT-Domain. Diesem als Edge-Gateway oder auch Edge-Router bezeichneten System kommen bisher nicht vorhandene Sonderaufgaben zu. Dazu einige Beispiele:

Sensordatenintegration: In einer OT-Domain wird es sehr viele Sensoren geben. Einige davon sind direkt an Steuerungen angebunden, um Ist-Werte an eine SPS-Software zu liefern. Andere dienen ausschließlich zur Maschinen- und Prozessüberwachung, beziehungsweise um ein möglichst vollständiges Prozessdatenabbild zu schaffen. Ein Edge-Gateway bildet das Bindeglied zwischen den Sensordaten und den Datennutzern. Zum Speichern der Sensordaten benötigt ein Edge-Gateway eine geeignete Datenbank für unstrukturierte Daten (in der Regel eine sogenannte NoSQL-Datenbank, zum Beispiel MongoDB) mit entsprechenden Schnittstellen, um anderen Systemen den Zugriff auf diese Daten zu ermöglichen.

Vor-Ort-Analytics: Die in der Feldebene gewonnen Daten können mit Hilfe mathematischer Vorhersagemodelle direkt einer Datenanalyse unterzogen werden, um zum Beispiel automatisch Wartungstermine für einzelne mechatronische Baugruppen, Maschinen und Anlagen zu bestimmen. Der Zugriff auf diese Daten durch ERP und MES ist zum Beispiel per OPC UA möglich. Auch das Eintragen der Instandhaltungstermine und Ersatzteilbestellungen können vom Edge-Gateway aus mit Hilfe entsprechender SOA-Schnittstellen erfolgen.

Vertikale Integration: Maschinen sind in der zukünftigen Smart Factory nahezu direkt mit einer ERP-Software verbunden. Die dazwischengeschaltete Leitrechner- und MES-Software-Ebene entfällt dann. Eine SPS sendet Produktionsrückmeldungen direkt ans ERP oder erhält etwa von diesem Stücklisten, Rezepturen und Arbeitspläne.

Cloud-Verbindung: Die Kommunikation zwischen OT- und CT-Domain sollte im Idealfall ausschließlich über das Edge-Gateway erfolgen. Dadurch kann nicht nur ein preiswerter Funksensor im OT-Umfeld (zum Beispiel ein Wireless-MBus-Zähler) anspruchsvolle Cloud-Schnittstellen (beispielsweise ein HTTPS-basiertes REST-Interface mit XML-Datenstrukturen) in der CT-Welt bedienen. Es lassen sich über die vielfältigen Möglichkeiten  eines Edge-Gateways auch IT-Security-Anforderungen wirkungsvoll umsetzen.

In Zusammenhang mit der vertikalen Integration kann ein Edge-Gateway zum Beispiel daneben die Aufgaben einer SOA-PLC übernehmen. Die durch Industrie 4.0 zu erwartenden konzeptionellen Veränderungen werden mit der gegenwärtigen Technik zu einigen größeren Herausforderungen führen. Besonderer Handlungsbedarf besteht bei den Steuerungen und die Art und Weise, wie einzelne SPS-Systeme einer Anlage beziehungsweise Fertigungszelle programmiert und in die Lage versetzt werden, untereinander und mit einer übergeordneten Leittechnik zu kommunizieren (SPS-Orchestrierung in einer Fertigungszelle). Die dabei gegenwärtig zum Einsatz kommende Methodik ist veraltet und für die dargestellten Kommunikationsbeziehungen eigentlich nicht mehr geeignet.

Autor: Klaus-Dieter Walter ist Mitglied der ­Geschäftsführung bei SSV Software Systems.