Bisher wurden Automatisierungslösungen überwiegend als in sich geschlossene Systeme realisiert: Die SPS ist mit zahlreichen Sensoren und Aktoren verbunden, um eine bestimmte Maschine oder Anlage zu steuern. Externe Datenschnittstellen für andere Anwendungen gibt es bei älteren Lösungen meist überhaupt nicht. Neue Steuerungskonzepte besitzen häufig schon ein OPC-UA-Interface. Die zur Verfügung stehenden Datenpunkte sind aber in erster Linie für Konfigurationsaufgaben und einfache Zustandsvisualisierungen vorgesehen. Einer Edge-basierten Predictive-Maintenance-Software oder einem Wartungs- und Instandhaltungsassistenten, der bei einem ungeplanten Maschinenstillstand mit Hilfe von KI-Algorithmen dem Maschinenbediener bei der Fehlersuche, -analyse und -behebung unterstützt, reicht diese Datenqualität in der Regel nicht, um werthaltige Ergebnisse zu liefern.
Datenintegrationsschicht erforderlich
Die Maschinenlandschaft eines produzierenden Unternehmens mit Serienfertigung ist in der Regel über einen längeren Zeitraum entstanden und daher außerordentlich vielfältig. Maschinen und Subsysteme unterschiedlicher Hersteller, die teilweise noch nicht einmal einen gemeinsamen Kommunikationsstandard unterstützen, wurden zu Anlagen zusammengefügt. Zu jeder einzelnen Maschine gehört umfangreiches Expertenwissen, um im Alltagsbetrieb bestmögliche Ergebnisse zu erzielen. Die meisten Anlagebestandteile besitzen eine individuelle Automatisierungstechnik, häufig mit eigenständigen Bedieneinheiten oder anderem Spezialzubehör. Teilweise existieren Fernwartungszugänge, um bei Problemen externe Hilfe durch einen Maschinenbauer oder ein Serviceunternehmen in Anspruch zu nehmen. Vereinzelt gibt es auch Cloud-Anbindungen, z.B. für ein Frequenzumrichter-Monitoring – in der Summe also eine sehr heterogene Landschaft.
Bevor sich in einem solchen Umfeld erfolgreiche Edge-Computing-Anwendungen realisieren lassen, ist zunächst einmal eine horizontale Datenintegrationsebene erforderlich. Diese sollte dem Stand der Technik in der IT-Welt entsprechen und per Ethernet-LAN mit MQTT, HTTP(S)-basiertem Rest-API und gegebenenfalls noch OPC UA möglichst nur drei Protokolle unterstützen. Alle Subsysteme, die Ethernet und zumindest eines der drei Protokolle nicht direkt unterstützen, werden mit Hilfe eines Gateway-Adapters angebunden (der Markt bietet hier inzwischen eine sehr große Auswahl).
Die zum Einsatz kommende Edge-Gateway-Hardware selbst muss auf offenen IT-Standards basieren und keine Vendor-Lock-ins beinhalten. Die gesamte Anwendungssoftware sollte aus einer modularen serviceorientierten Architektur mit wiederverwendbaren Komponenten bestehen und an keine bestimmte Hardwareplattform gebunden sein. DevOps mit regelmäßigen Updates und IT-Security by Design sind als Standardfunktionen erforderlich – nicht als Optionen, um die sich der Betreiber dann selbst kümmern muss.
Vor der Datenintegration der einzelnen Maschinen sollte zunächst einmal die anwendungsbezogene Fragestellung geklärt werden: „Welche Maschinen haben wir überhaupt und welche Daten bzw. Informationen werden jeweils benötigt?“ Für das datentechnische Gesamtbild sind eine Bestandsanalyse direkt vor Ort und der Austausch zwischen erfahrenen IT-Anwendungsentwicklern, Maschinenbedienern und Automatisierungstechnikern erforderlich. Das Ziel ist in jedem Fall ein sogenannter Echtzeit-Merkmalsvektor mit Querschnittsdaten, der zu der jeweiligen Aufgabenstellung passt. Aus den einzelnen Datenelementen dieses Merkmalsvektors lässt sich ableiten, welche zusätzliche Sensorik benötigt wird.
Docker-basierte Edge-Anwendungen
Eine hardwareunabhängige, serviceorientierte und modulare Anwendungssoftware, die über DevOps gewartet und weiterentwickelt wird, basiert in der IT-Welt auf Docker-Technologie. Mit einem Docker-Container lassen sich Softwareanwendungen nahezu plattformunabhängig weitergeben, um sie auf Rechnern mit 32- bzw. 64Bit-AMD/Intel-, Arm- oder RISC-V-Prozessoren sowie Linux-, Microsoft-Windows-, macOS- und anderen Unix-ähnlichen Betriebssystemen zu betreiben. Die Bereitstellung und Installation einer Docker-basierten Anwendung erfolgt nahezu unabhängig vom Zielsystem über Registry-Server und Repositories. Die zu installierende Applikation wird dabei als Docker-Container-Image wahlweise auf einem Internet-Server (z.B. Docker Hub) oder einer lokalen Serveranwendung zur Verfügung gestellt.
Eine Anwendung in einem Docker-Container, der auf einem Edge-Gateway als Docker-Host ausgeführt wird, stellt keine besonderen Anforderungen an spezielle Betriebssystemversionen oder im Host-Dateisystem vorinstallierte Laufzeitumgebungen (z.B. eine spezielle Version einer Programmiersprache) oder andere Bibliotheken (z.B. ein OpenSSL mit der TLS-Version 1.3). Alles, was von der Containeranwendung benötigt wird, ist auch im Container selbst mit dem jeweils erforderlichen Versionsstand vorhanden. Da Container-Images sehr kompakt sind, sollte jede einzelne Anwendung ein separates Docker-Container-Image bilden. Die Container auf einem Host können über die Docker-Laufzeitumgebung ein Netzwerk mit IP-Adressen usw. erzeugen, um miteinander zu kommunizieren. Für die IP-Kommunikation zwischen den Docker-Containern lassen sich die gleichen Funktionen und Protokolle nutzen, die auch bei der Rechnervernetzung in einem LAN zum Einsatz kommen. Dadurch können auch Container auf unterschiedlichen Edge-Baugruppen ohne weitere Änderungen miteinander kommunizieren. Darüber hinaus unterstützen Docker den Microservice-Gedanken: eine komplexe Anwendungssoftware lässt sich aus einzelnen Prozessen zusammensetzen, die in separaten Containern laufen und über Standard-Netzwerkschnittstellen miteinander kommunizieren.
Aufgabenspezifische Sensorik
Der wichtigste Funktionsbaustein für die erforderliche Datenqualität ist die Sensorik. Jede einzelne Funktionseinheit der eingesetzten Sensoren sollte auf die jeweilige Aufgabenstellung abgestimmt werden. Einen besonderen Stellenwert hat in diesem Zusammenhang die Signalauswertung. Hier lassen sich Algorithmen aus dem Bereich des Supervised Machine Learning, einem Teilgebiet der künstlichen Intelligenz, verwenden. Zu jedem Sensor gehören daher umfangreiche Softwarefunktionen als Docker-Container, die sich direkt an der Edge, On-Premise, also irgendwo in der IT vor Ort, oder in der Cloud einsetzen lassen. Die Funktionen basieren in erster Linie auf künstlichen neuronalen Netzen, um Sensordaten für Klassifizierungs- oder Regressionsaufgaben zu nutzen. Ein Beispiel hierfür wäre die automatische Antwort auf die Frage „In welchem Zustand befindet sich meine Werkzeugmaschine gerade?“
Zu guter Letzt benötigt der Sensor natürlich noch eine passende Kommunikationsschnittstelle. Dessen Hauptaufgabe ist es, Sensordaten oder die daraus gewonnenen Informationen an andere Systeme weiterzuleiten. Darüber hinaus wird das Interface sowohl für Konfigurationen, Software-Updates als auch zur Realisierung einer vertrauenswürdigen digitalen Identität, also einem Root of Trust für Sensorikanwendungen, genutzt. Durch den Edge-Docker-Einsatz besteht ein Sensorik-Interface aus zwei Teilen: Die Verbindung des Sensors zum Docker und die Sensorschnittstelle des Dockers zur Datenintegrationsebene. Die erste Teilaufgabe lässt sich z. B. in Form einer Funkschnittstelle oder eines einfaches Bussystems (RS485, CAN, Single Pair Ethernet) realisieren. Der zweite Teil wäre das passende Protokoll, also MQTT, ein Rest-API per HTTP(S) oder OPC UA.
