Embedded-KI projektieren
Wie KI in Produkte kommt
Wer eine lokale Embedded-KI in ein Produkt integrieren und vermarkten will, muss vor der Wahl externer Systemkomponenten eine Reihe von Vorarbeiten leisten: So müssen Produktmanagement und Entwicklung genau wissen, wie der Prozess mit KI abläuft und wie die lernenden Algorithmen langfristig auf Produktzyklen wirken.
Bild: AITAD GmbHWann lokal, wann 'on edge'?
Die Definitionsabgrenzung zwischen einer lokalen Embedded-KI-Lösung und dem weitläufiger verwendeten Edge-KI-Begriff ist bei den hier dargestellten Systemkomponenten in den meisten Fällen unauflöslich verschwommen. Schließlich gibt beispielsweise ein Predictive Maintenance Node mit entsprechendem Sensor und einer kleinen, dezentralen Recheneinheit immer eine mehr oder minder ausführliche Statusinformation an das Zentralsystem weiter. Es gibt ebenso die Möglichkeit, Trigger- oder Preprocessing-Parameter zu ändern oder gar ganze Modelle zu beeinflussen respektive upzudaten. Die Trennlinie der Begriffe liegt also im Dateninhalt beider Kommunikationsrichtungen. Grundsätzlich werden vereinfacht dargestellt Systeme, die ein Klassifizierungsergebnis am Node liefern, eher als Embedded-KI und solche mit ausschließlicher Datenvorverarbeitung und größerem Processing außerhalb des Nodes - also auf der Steuerung oder der Cloud - als Edge-KI bezeichnet. Beides ist mit IoT- und IIoT-Konzepten vereinbar. In diesem Artikel wird stets von Embedded-KI gesprochen, auch wenn viele der Aussagen auf beides applizierbar sind.
Hürden bei Projekten
Häufig reichen vorhandene Produkt- oder Prozessdaten nicht aus. Dies betrifft Qualität, Erfassung und Speicherung. Ein weiterer, früher Trugschluss ist oft, dass die bereits in der aktuellen Produktgeneration vorhandenen Sensoren mit ihrer Auflösung, Empfindlichkeit und Messrate ausreichen. Die Lösung eines solchen Problems liegt entweder in Umstellung oder Veränderung der Messweise über einen komplementierenden Sensor für die vermuteten oder geforderten physikalischen Größen oder einem Neudesign mit einem für alle Zwecke passenden, gegebenenfalls etwas teureren Sensor. Eine Hürde, die auch die IIoT- und Automatisierungswelt gut kennt, ist die Interface- und Protokoll-Thematik. Um das Zusammenspiel der Komponenten im System und darüber hinaus abzusichern, müssen die Komponenten entsprechende Industrie-Interfaces wie One-Pair-Ethernet, Ethercat, USB, CAN, LIN aufweisen bzw. das jeweilige proprietäre Protokoll beherrschen. Eingeschlossen ist auch das Gesamtkonzept mit den üblicherweise übergeordneten Shopfloor- bzw. Field-Service-Systemen, die die Lebensdaten oder Prozessüberwachung letztendlich statistisch erfassen und den Service- oder Produktionsprozess steuern. Die Aufgabenteilung und Datenabstraktion müssen von Anfang an klar sein.
Bild: AITAD GmbHProjektablauf
Am Anfang eines Produktzyklus muss in der Konzeptphase der KI-Einsatz mit der Kosten- und Nutzenfunktion erwogen werden. Dies setzt gesamtheitliches Denken voraus, denn gerade bei neuen HMI- oder Predictive-/Preventive-Maintenance-Systemen kommt man mit einzelnen Überwachungskomponenten beim Produkt entweder wirtschaftlich (z.B. Verfügbarkeitsgarantie beim Geschäftsmodell) oder als Verkaufsargument nicht weiter. Meistens ist bei einer HMI ein neu aufgestelltes Konzept notwendig, während bei Wartungsthemen eine wirtschaftliche Berechnung sinnvoll sind, bei der Kosten in Form von Hardware, Service und Ausfallskomponenten mit den Ausfallswerten aus der Vergangenheit abgewogen werden. In den meisten Fällen kommt man aufgrund der Natur des Machine Learnings sehr früh nicht um einen praxisbezogenen Proof-of-Concept herum. Der diesbezügliche Bedarf zeigt sich bereits am Anfang im Produktentwicklungsprozess, die damit einhergehenden Einstiegskosten mit Datensammlung, Verarbeitung und Data Science sind aber gerade bei erstmaligen Entwicklungsprozessen nicht zu unterschätzen.
Tipps für die Praxis
Verantwortliche sollten nie das Gesamtbild und das im Unternehmen und insbesondere beim Entwicklungsteam vorhandene Wissen und entsprechende Lösungsvorschläge aus den Augen verlieren. Ein wichtiger Hinweis oder eine Idee vom Produktdesigner oder dem mechanischen Konstrukteur kann früher verworfenes oder unrealisierbar erscheinendes wieder in den bereich des Möglichen rücken, was zu neuen Ansätzen führt. Beteiligte sollten folglich die Konzeption mit Embedded-AI als ein interdisziplinäres Feld betrachten mit fester Zielsetzung, internen Ideen und Daten als Grundlage. Dabei sollten sich die Projektteilnehmer die Stärken von Machine Learning (ML) zunutze machen, nämlich unbekannte Muster zwecks Klassifizierung zu verwenden. Lässt sich ein ein Prozess nicht direkt überwachen, etwa weil die Sensorik zu teuer wäre, könnten es sekundäre Messmethoden und ML gegebenenfalls trotzdem möglich machen. Indirekte Messweisen können beispielsweise Spektrografie bei Medien oder VOC-Stauberkennung bei Abluft sein. Um die Ecke zu denken ist also in diesem Zusammenhang alles andere als verkehrt.
Produkt langfristig denken
Nachhaltige Entwicklungsprinzipien in Form von Zugänglichkeit, übersichtlicher (Code-)Struktur sowie der Ressourcen- und Kompetenzeneffizienz sollten stets berücksichtigt werden. Denn gerade bei Wartungserkennung können die Algorithmen bei einem leicht veränderten Produktdesign oder gar einer geringfügigen Zulieferteiländerung unpräziser werden. Mittelfristig werden Modell-Iterationen und Updates nötig sein. Diese dürften aufgrund der bereits erwähnten Adaptionsthemen recht einfach ausfallen. Doch muss die Produktpflege im Produktionszeitraum besonders betrachtet werden, was einen kontinuierlichen Support- und Entwicklungsprozess einschließt.
Neues Toolset
Embedded-KI ist ein spezifisches, sich schnell fortentwickelndes und noch unterschätztes Produktfeld. Mit genauer Projektplanung, Ressourcenzuordnung und den notwendigen Skills dürfte der Ansatz allmählich zum gewöhnlichen Toolset der Produktentwickler werden - angefangen vom Management über den mechanischen Background bis hin zur Prozessplanung. Viele Prozesse und Messgrößen können im neuen Licht betrachtet werden. Wichtig ist, das mit Proof-of-Concepts validierte Konzept sattelfest aufzustellen. Der Konzeptgedanke sollte sich nicht nur auf das System beschränken, sondern sich auch über die Produktlebensdauer, Optimierungen, Updates und technologische Fortschritte erstrecken. Dann steht dem innovativen Produkt nichts im Wege.
Wer eine lokale Embedded-KI in ein Produkt integrieren und vermarkten will, muss vor der Wahl externer Systemkomponenten eine Reihe von Vorarbeiten leisten: So müssen Produktmanagement und Entwicklung genau wissen, wie der Prozess mit KI abläuft und wie die lernenden Algorithmen langfristig auf Produktzyklen wirken.
Bild: AITAD GmbHWann lokal, wann 'on edge'?
Die Definitionsabgrenzung zwischen einer lokalen Embedded-KI-Lösung und dem weitläufiger verwendeten Edge-KI-Begriff ist bei den hier dargestellten Systemkomponenten in den meisten Fällen unauflöslich verschwommen. Schließlich gibt beispielsweise ein Predictive Maintenance Node mit entsprechendem Sensor und einer kleinen, dezentralen Recheneinheit immer eine mehr oder minder ausführliche Statusinformation an das Zentralsystem weiter. Es gibt ebenso die Möglichkeit, Trigger- oder Preprocessing-Parameter zu ändern oder gar ganze Modelle zu beeinflussen respektive upzudaten. Die Trennlinie der Begriffe liegt also im Dateninhalt beider Kommunikationsrichtungen. Grundsätzlich werden vereinfacht dargestellt Systeme, die ein Klassifizierungsergebnis am Node liefern, eher als Embedded-KI und solche mit ausschließlicher Datenvorverarbeitung und größerem Processing außerhalb des Nodes - also auf der Steuerung oder der Cloud - als Edge-KI bezeichnet. Beides ist mit IoT- und IIoT-Konzepten vereinbar. In diesem Artikel wird stets von Embedded-KI gesprochen, auch wenn viele der Aussagen auf beides applizierbar sind.
AITAD GmbH
Dieser Artikel erschien in IT&Production 2 (März) 2023 - 09.03.23.Für weitere Artikel besuchen Sie www.it-production.com
