Wenn Infrastrukturcode und Anwendungslogik zu stark in einer monolithischen Software verwoben sind, wird es ab einem bestimmten Punkt immer schwieriger, neue Funktionen zu implementieren. Für die Entwicklung einer Smart Factory ist es jedoch wesentlich, dass keine infrastrukturellen Skalierungsprobleme auftreten. Darüber hinaus müssen in einer Smart Factory mehrere hundert KI-Modelle trainiert, organisiert, ausgerollt und vernetzt werden, ohne bereits produktive Softwarekomponenten überarbeiten zu müssen. Darüber hinaus muss die Aktualisierungsfähigkeit sicherheitsrelevanter Patches für alle Geräte jederzeit gewährleistet sein.
Darüber hinaus gibt es zwei weitere Herausforderungen beim Einsatz von KI in der Fertigung: Die Anbindung von Sensoren ist nicht ohne weiteres möglich virtualisiert und die Anforderung einer geringen Latenz bzw. der Integration von KI in die Echtzeitumgebung der Automatisierung muss gewährleistet sein.
Mit diesen Herausforderungen im Hinterkopf haben wir unsere DRIFT-Plattform entwickelt. DRIFT ist von Anfang an als plattformübergreifende Microservice-Architektur konzipiert, sodass einzelne KI-Softwarekomponenten frei ausgerollt und über die Edge und die Cloud hinweg vernetzt werden können.
Eine solche Architektur ist mittlerweile State of the Art in der Softwareentwicklung für komplexe Cloud-Projekte.
Der Aufbau einer Microservice-Infrastruktur und die saubere Definition von APIs und Protokollen zwischen den einzelnen Diensten ist mit einem erheblichen Mehraufwand in der Softwareentwicklung verbunden. Darüber hinaus bedeutet die Isolation und Verschlüsselung der Softwarekomponenten systembedingt eine spürbar geringere Gesamtleistung, da beispielsweise Sensordaten immer über ein Netzwerkprotokoll zwischen Diensten kopiert werden müssen und nicht wie bei einem monolithischen Ansatz einfach weitergegeben werden können in Erinnerung. Diese Nachteile fallen jedoch nicht ins Gewicht, wenn man sonst bei der Skalierung der Software mit einem monolithischen Ansatz an harte Grenzen stoßen würde. Der Leistungsverlust lässt sich relativ einfach durch zusätzliche Rechenleistung kompensieren.
Die folgende Abbildung zeigt das Blockschaltbild für eine typische KI-Anwendung in der Produktion, die ein Multikamerasystem zur Überwachung von Produkten auf einem Förderband nutzt.
Die Auslösung der Bilder erfolgt durch einen Hardware-Triggerdienst, der in diesem Fall einfach feste Zeitintervalle verwendet, um einen kontinuierlichen Videostrom für die anschließende Verarbeitung bereitzustellen. Basierend auf dem Software-Trigger generiert ein DRIFT-Hardware-Controller eine exakte Echtzeit-Sequenz zum Triggern der verschiedenen LEDs und der Kameras, so dass jedes Foto exakt getaktet fünfmal mit unterschiedlichen Beleuchtungs-Setups der LEDs aufgenommen wird. Dieses präzise Timing wäre mit einer reinen Softwarelösung in einem Microservice und der Ansteuerung der Kamera über USB allein nicht möglich.
Die aufgenommenen Bilder werden zunächst direkt im Kameradienst optisch und perspektivisch entzerrt.
Anschließend werden die aufgenommenen Bilder an einen Objekterkennungsalgorithmus auf Basis eines tiefen Faltungsnetzwerks gesendet. Dieser Dienst markiert die einzelnen Objekte. Dazu nutzt der Algorithmus eine Dual-Coral-TPU als KI-Co-Beschleuniger in einem Mini-PCI-e-Slot des Edge-Devices, sofern vorhanden, da diese Funktion eine hohe Leistung erfordert.
In einem Kalman-Filter-basierten Tracking-Algorithmus wird den erkannten Objekten eine virtuelle Seriennummer zugewiesen. Jedes Objekt wird optimal aus dem Videostrom herausgeschnitten und die Position wird Pixel für Pixel mit der gemittelten Geschwindigkeit des Kalman-Filters korrigiert. Der Stapel aus fünf Einzelbildern wird dann mit einem Wavelet- und Entropie-Encoder komprimiert und normalisiert, wobei das Rauschen reduziert und die für die Auswertung wesentlichen Merkmale verarbeitet werden.
Diese Bildstapel durchlaufen nun parallel drei Auswertungsdienste, von denen jeder nur seinen notwendigen Informationsteil übernimmt
- ein Algorithmus zur Erkennung von Anomalien, der auf einem Autoencoder und einem auf SOM-Clustering basierenden Algorithmus zur Dichteschätzung beruht
- ein Algorithmus zur Erkennung von 3D-Oberflächendefekten auf der Grundlage einer photometrischen Stereomethode,
- ein 2D-Vermessungsalgorithmus, der auf einem Gradienten-Vektorfluss-Algorithmus basiert, der einen Spline um die Objekte herum anpasst.
Zusammen mit der virtuellen ID aus der Verfolgung fließen die Ergebnisse der Dienste über einen OPC-Server zu einem zentralen Prozessleitstand in der Produktion.
Neben dem rein funktionalen Schema gibt es mindestens die gleiche Anzahl an Support- und Vorschaudiensten zur Steuerung und Wartung des Edge-Devices, wie z.B. eine Web-App zur Darstellung der KI-Funktionalität, die wiederum mit einer zentralen Benutzerkontrolle verbunden ist.
Insgesamt laufen neun Microservices auf dem Gerät.
Die Flexibilität dieses Ansatzes ist die Basis für einen adaptiven und unkomplizierten Einsatz von KI in der Produktion.
Alle neun Softwarekomponenten laufen einzeln und prinzipiell unabhängig voneinander. Auf einem Gerät würde dies prinzipiell auch in einem monolithischen Ansatz funktionieren, der sich aber nicht ohne weiteres erweitern ließe. Die Dienste sind über einen MQTT-Broker miteinander verbunden. Im Betrieb kann jeder Dienst einzeln eingebunden, abgekoppelt und aktualisiert werden.
Zusätzliche Dienste können nach Belieben hinzugefügt werden. Reicht die Rechenleistung des 8-Kerns nicht aus, wird ein weiteres Edge-Device hinzugefügt und über einen Netzwerkstecker angeschlossen. Ohne Umstellung laufen nun zusätzliche Dienste auf dem hinzugefügten Edge-Device. Im Prinzip können die Geräte eine zentrale Rechenleistung im Rechenzentrum ersetzen. Lediglich der Kameradienst ist an den Standort der Kamera gebunden.
Ein weiterer großer Vorteil der Kapselung der einzelnen Softwarekomponenten in Microservices ist deren Wiederverwendbarkeit. Einzelne Dienste werden für andere Zwecke ausgetauscht. Die Dienste sind bewusst einfach gehalten. Für den Kameradienst zum Beispiel gibt es viele verschiedene Varianten, die die gleichen externen Schnittstellen haben. DRIFT ist eine Bibliothek von Diensten, die von vorkonfigurierten Hardwaremodulen überall dort unterstützt werden, wo Echtzeitfähigkeit erforderlich ist. Die Einfachheit und Entkopplung von Datenstrom und KI-Logik erlaubt es dem Kunden, sehr einfach eigene Algorithmen außerhalb der DRIFT-Bibliothek zu implementieren, und zwar in der Programmiersprache seiner Wahl mit den Frameworks seiner Wahl.
Dazu werden die relevanten Daten beim Broker abonniert und die Auswertung ebenso einfach wieder bereitgestellt. Der Rest regelt sich von selbst. Der Datenwissenschaftler und ML-Experte kann sich auf das Wesentliche konzentrieren.
Im produktiven Betrieb können auf diese Weise neue KI-Algorithmen getestet werden, ohne die Produktivität der laufenden Software zu gefährden. Das Sammeln von Daten für das Training von Algorithmen und das Anwenden von Algorithmen erfolgt über denselben Datenfluss, was damit verbundene Fehlerquellen eliminiert und den Aufwand für die Datenkonvertierung vermeidet. Es ist bekannt, dass 80 % der Zeit in der Datenwissenschaft für das Kopieren, Bereinigen und Konvertieren von Daten aufgewendet wird.
Kurz gesagt, unsere Edge AI Platform DRIFT ist in Form von Microservices organisiert, die sich insbesondere um das Datenstreaming von hochauflösenden Sensordaten kümmern, so dass Algorithmen so schnell und einfach wie möglich eingesetzt werden können, unabhängig davon, ob es sich um eingebaute KI-Services von PANDA oder um selbst entwickelte Methoden handelt.
