EN
DE
Wenn Infrastrukturcode und Anwendungslogik in einer monolithischen Software zu stark miteinander verwoben sind, wird es ab einem bestimmten Punkt immer schwieriger, neue Funktionen zu implementieren. Für die Entwicklung einer intelligenten Fabrik ist es jedoch entscheidend, dass keine infrastrukturellen Skalierungsprobleme auftreten. Zudem müssen in einer Smart Factory mehrere hundert KI-Modelle trainiert, organisiert, ausgerollt und vernetzt werden, ohne dass bereits produktive Softwarekomponenten überarbeitet werden müssen. Zudem muss die Aktualisierbarkeit von sicherheitsrelevanten Patches für alle Geräte jederzeit gewährleistet sein.
Darüber hinaus gibt es zwei weitere Herausforderungen bei der Anwendung von KI in der Fertigung: Die Anbindung von Sensoren lässt sich nicht ohne weiteres virtualisieren und die Forderung nach geringer Latenz bzw. die 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 den Edge und die Cloud vernetzt werden können.
Eine solche Architektur ist heute Stand der Technik 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 bedeutet einen erheblichen Mehraufwand in der Softwareentwicklung. Zudem bedeutet die Isolation und Verschlüsselung der Softwarekomponenten eine spürbar geringere systembedingte Gesamtleistung, da z.B. Sensordaten immer über ein Netzwerkprotokoll zwischen den Diensten kopiert werden müssen und nicht wie bei einem monolithischen Ansatz einfach im Speicher weitergegeben werden können. Diese Nachteile fallen aber nicht ins Gewicht, wenn man sonst bei der Skalierung der Software mit einem monolithischen Ansatz an harte Grenzen stoßen würde. Der Leistungsverlust kann relativ leicht durch zusätzliche Rechenleistung kompensiert werden.
Das folgende Diagramm zeigt das Blockdiagramm für eine typische KI-Anwendung in der Produktion, die ein Multikamerasystem zur Überwachung von Produkten auf einem Förderband verwendet.
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.
Die aufgenommenen Bilder werden dann an einen Objekterkennungsalgorithmus gesendet, der auf einem tiefen Faltungsnetzwerk basiert. Dieser Dienst markiert die einzelnen Objekte. Zu diesem Zweck verwendet der Algorithmus eine Dual-Coral-TPU als KI-Co-Beschleuniger in einem Mini-PCI-e-Steckplatz des Edge-Geräts, sofern verfügbar, da diese Funktion eine hohe Leistung erfordert.
Bei einem auf dem Kalman-Filter basierenden Verfolgungsalgorithmus 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 gehen nun parallel zu drei Auswertungsdiensten, von denen jeder nur den für ihn notwendigen Teil der Informationen aufnimmt
- ein Algorithmus zur Erkennung von Anomalien auf der Grundlage eines Autoencoders und eines auf SOM-Clustering basierenden Algorithmus zur Schätzung der Dichte
- einen Algorithmus für 3D-Oberflächendefekte, der auf einer photometrischen Stereomethode basiert,
- 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 strömen die Ergebnisse der Dienste über einen OPC-Server zu einer zentralen Prozessleitstelle in der Produktion.
Neben dem rein funktionalen Schema gibt es mindestens die gleiche Anzahl von Support- und Vorschaudiensten zur Steuerung und Wartung des Edge-Geräts, wie z.B. eine Web-App zur Anzeige der KI-Funktionalität, die wiederum mit einer zentralen Nutzerverifizierung 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 im Prinzip 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. Während des Betriebs 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 Netzwerkanschluss verbunden. Ohne eine Änderung 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 durch vorkonfigurierte Hardwaremodule überall dort unterstützt werden, wo Echtzeitfähigkeit erforderlich ist. Die Einfachheit und Entkopplung von Datenstrom und KI-Logik erlaubt es den Kunden, sehr einfach eigene Algorithmen außerhalb der DRIFT-Bibliothek zu implementieren, und zwar in der Programmiersprache ihrer Wahl mit den Frameworks ihrer Wahl.
Dazu werden die entsprechenden Daten beim Broker abonniert und die Auswertung ebenso einfach wieder bereitgestellt. Der Rest organisiert sich von selbst. Der Datenwissenschaftler und ML-Experte kann sich auf das Wesentliche konzentrieren.
Im produktiven Betrieb können neue KI-Algorithmen auf diese Weise getestet werden, ohne die Produktivität der laufenden Software zu gefährden. Das Sammeln von Daten für das Training von Algorithmen und die Anwendung 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 möglichst schnell und einfach eingesetzt werden können, unabhängig davon, ob es sich um eingebaute KI-Services von PANDA oder um selbst entwickelte Methoden handelt.
