vergleich-klassisches-vs-federated-learning-ki-machine-learning

Im Gegensatz zum klassischen, zentralen Machine Learning (links) werden beim dezentrale Machine Learning-Ansatz (Federated Learning) die Modelle direkt in der Produktion beim Anwender trainiert und nur diese übertragen. Dabei verbleiben alle sensiblen Daten sicher bei den Anwendern. (Bild: Katulu)

Frank Wieben ist Unternehmer, Lohnfertiger im Spritzguss und hat zwei große Probleme: Spritzgießen erfordert viel Wissen um die Prozesse, die Maschinen und das Material. Allerdings fehlen dem Lohnfertiger immer öfter Fachkräfte und gleichzeitig steigen die Anforderungen an sein Unternehmen. Zugleich muss die Branche nachhaltiger werden und verstärkt Recyclate nutzen. Deshalb gibt es in jeder Materialcharge Schwankungen, die die Prozessstabilität in der Produktion gefährden. Die Folge: Maschinen müssen immer wieder neu ausgelegt werden. „Das kostet Zeit, Geld und vor allem braucht es Wissen um den Prozess“, erklärt Wieben. Mit diesen Problemen wollen Maschinenbauer ihre Kunde nicht allein lassen und versuchen, auf ihre Anforderungen zu reagieren. Dabei ist Künstliche Intelligenz (KI) bzw. maschinelles Lernen ein möglicher Ansatz, der Abhilfe schaffen könnte. Das Problem: Spritzgießer lassen sich nur ungern in die Karten schauen. Für den Maschinebauer bedeutet das, dass die Anwender Daten über den Produktionsprozessen nur widerwillig, bis gar nicht teilen möchten. Doch ohne ausreichende Daten gibt es kein Training. Kein Training bedeutet keine Modelle und damit am Ende kein maschinelles Lernen. Expertinnen und Experten sprechen vom Distributed Data Dilemma. In anderen Worten: der Anwender kommt nicht an die Daten, die er braucht, um sein Problem zu lösen – obwohl es sie gibt.

Spritzguß
Beim Spritzgießen lässt sich die Prozessstabilität mit Federated Learning über Unternehmensgrenzen hinweg optimieren – ohne Datenweitergabe aus der Produktion. (Bild: Alpla)

Was können Maschinenbauern beim Lösen des Distributed Data Dilemmas von Apple und Google lernen?

Die Lösung trägt jeder Mitarbeitende von Wieben in seinem Blaumann – das Smartphone. Sie kennen das: Sobald der Werker in seiner Frühstückspause eine Nachricht an seine Familie schickt, schlägt ihm das System oberhalb der Tastatureinblendung Worte vor. Drückt er den Buchstaben A erscheinen die Wörter „aber oder also“, passen diese nicht, tippt er weiter. Drückt er A und L schlägt das System das Wort „alles“ vor. Er wählt es aus und schreibt weiter „Alles in“ und den Begriff „Ordnung“ gibt die Anwendung sofort vor. Und das leistet nicht nur sein Smartphone, sondern alle Google- oder Apple-Geräte weltweit! Sie wurden von den Anwendern unwissentlich lokal trainiert. Wählt er nun ein vorgeschlagenes Wort aus, trainiert er das Modell auf dem Smartphone weiter. Am Abend, wenn der Mitarbeitende sein Handy an der Steckdose steckt, trainiert das Gerät die lokalen Modelle und macht sie versandbereit. Sobald das Smartphone wieder online ist, sendet es das trainierte Modell an die Google- oder Apple-Entwickler. Wichtig ist, dass der der Nutzer dabei keine Daten sendet, sondern verschlüsselte, trainierte Modelle. Alle Informationen, die auf dem Smartphone eingeben werden, verlassen das Smartphone nicht. Die Entwickler nutzen diese für ihre Modelle und schicken sie dann neu trainiert wieder zurück. So entsteht ein kontinuierlicher Verbesserungskreislauf – ohne dass Daten geteilt werden. Federated Learning oder auch dezentrale KI nennen das die Experteninnen und Experten. An dieser Stelle kommen die Spritzgießer um Wieben wieder ins Spiel, denn sie könnten von der Technologie profitieren.

Katulu_FL_Suite
Mit Federated Analytics können Probleme gelöst werden, bei denen kein Zugriff auf die Daten besteht. (Bild: Katulu)

Federated Learning bedeutet: teilt Modelle, nicht Daten

Wie da funktionieren könnte, das weiß Michael Kühne-Schlinkert von Katulu aus Hamburg. Der Pumpenbauer KSB vertraut beispielsweise auf die Anwendungen der Norddeutschen. Kühne-Schlinkert und sein Team beschäftigen sich seit einigen Jahren auch in Zusammenarbeit mit dem SKZ (Das Kunststoff-Zentrum) und Fraunhofer-Instituten mit Federated Learning im Spritzguss. „Wir entwickeln zwar auch die Modelle für die Maschinenbauer oder deren Kunden, primär sorgen wir aber für die Infrastruktur damit Federated Learning funktioniert und schaffen echte Datensouveränität für die Maschinenbaukunden“, erklärt der Gründer. Der Firmenname geht auf das krakenartiges Comic-Wesen Cthulhu aus den 1920er Jahren von H.P. Lovecraft zurück. „Ganz bewusst, denn die Krakenarme verfügen alle einzeln auch über Intelligenz. Das passt gut zu unserer Technologie. Wir müssen die Arme, also die Maschinen im Feld, mit den Modellen beim Maschinenbauer koordinieren“, lacht Kühne-Schlinkert. Die Herausforderungen beim Federated Learning sind im ersten Schritt nicht die KI-Modelle, sondern die Infrastruktur und die Entwicklungswerkzeuge, die es ermöglichen mit Daten zu arbeiten, zu denen kein direkter Zugriff besteht. „Verteilte Netze mit Edge-Devices, Cloudanbindungen und dann noch an verschiedenen geografischen Positionen mit eingeschränkter Konnektivität sind unser Alltag“, erklärt der Hamburger. Dazu kommt, die Norddeutschen müssen erstmal alle Assets, die notwendig für ein Lernen sind, in der Produktion finden und sinnvoll gruppieren, ohne direkt etwas über die Assets zu erfahren. „Federated Learning scheint für manche im Markt gerade der Zauberstab für das Distributed Data Dilemma zu sein“, berichtet Kühne-Schlinkert.

Zitat

Wir schaffen echte Datensouveränität für die Industrie.

Michael Kühne-Schlinkert, CEO von Katulu

Wie sieht das Basismodell beim Federated Learning aus?

Der nächste Schritt ist ein initiales Modell. Dafür erfassen Mitarbeitende des Maschinenbauers im Technikum oder Labor erste Datensätze der Spritzgießmaschinen. „Hierbei konzentrieren wir uns am Anfang auf die Daten, die direkt an der Steuerung oder dem MES abgegriffen werden können, etwa den Einspritzdruck oder die Werkzeugtemperatur“, so Kühne-Schlinkert. Entscheidend bei der Datenerfassung ist das Labeling der Daten durch Fachexperten, also das Kennzeichnen der Datensätze nach Fehlerfällen und Qualitätsgüten. Hierzu werden Experimente mit verschiedenen Maschinenparametern und Zykluszeiten durchgeführt und die Versuchsergebnisse ausgewertet, um Merkmale wie Oberflächenglanz, Gratbildung oder Verzug mit den Steuerungsdaten in Zusammenhang zu setzen. „Historische Daten, die einem bestimmten Fehlerfall zugeordnet werden können, sind ebenfalls eine wertvolle Datenquelle“, erklärt der Informatiker. In der Regel geschieht das durch den Maschinenbauer. Ausnahmen sind Zusammenschlüsse von Anwendern oder wenn es über mehrere Werke des Anwenders geht. Dann übernehmen Anwender die Auswertung.

Mit diesen gesammelten Daten wird ein erstes KI-Modell zur Identifikation der zentralen Einflussfaktoren auf den Prozess trainiert, mit dem Ziel Vorhersagen zur Qualität im laufenden Prozess zu ermöglichen. Katulus Teams liefert nicht wie viele in der KI-Szene am Ende ein Stück Software, sondern sie machen die Maschinen fit für das Modell. „Wir nutzen die Edge an der Maschine für das lokale Training und geben dieses in eine Cloud des Maschinenbauers“, erklärt er. Katulu hat seine eigene AI Edge, die Daten mittels MQTT oder OPC UA sammelt – ein lokaler Data Lake, also eine Datensammlung, entsteht. „Die Herausforderung besteht dann darin, diesen zu managen und beispielsweise festzulegen, welche Daten auch wieder gelöscht werden können und welche gar versioniert werden müssen. Das initiale Modell kommt meistens vom Maschinenbauer. Das spielen wir auf die Edge und dort wird dann weiter trainiert.“

Katulu setzt auf Open Source

Die Katulu FL Suite integriert das beliebte Federated Learning Framework Flower mit Kubelfow, dessen Code öffentlich zugänglich ist. So können Anwender ihre vertrauten Data Science Tools nutzen und Probleme lösen, bei denen sie keinen Zugriff auf die Daten haben. Darüber hinaus können die Maschinenbauer die Vorteile des leistungsstarken Katulu SDKs nutzen und dezentralisierte Modelle aus ihren Jupyter-Notebooks orchestrieren. Durch die hohe Skalierbarkeit (>5 Mio. Geräte) sowie das Shopfloor-erprobte Edge Management schafft Katulu die Voraussetzung für den erfolgreichen Einsatz von KI unter realen Industriebedingungen.

Wie bleibt der Anwender beim Federated Learning anonym?

Ein wichtiger Punkt bei dieser Methode: Die Modelle des Kunden werden zusätzlich noch verschlüsselt, um keine Rückschlüsse auf die Daten zu ermöglichen. Katulu nutzt dabei das Prinzip der Differential Privacy. Nicolas Sartor von Aircloak aus Kaiserslautern erklärt das Prinzip anschaulich: Die Eltern eines Kindes wissen eine Menge über das Kind, wie zum Beispiel, welches Gemüse ihm nicht schmeckt. Das Kind möchte aber bestimmt nicht, dass jeder das weiß. Um solche Arten von Geheimnissen bewahren zu können, braucht man Privatsphäre. Aber der Mann, der dem Kind ein Mittagessen im Kindergarten macht, möchte vielleicht wissen, dass es in der Gruppe Kinder gibt, die keine Tomaten mögen. Dafür muss er allerdings nicht wissen, welche Kinder das sind. Meistens reicht es aus, wenn er weiß, dass es vielleicht 4 oder 5 Kinder gibt, die keine Tomaten mögen. Diese Art der Privatsphäre wird eben als Differential Privacy bezeichnet. „Hierbei ist die richtige Verteilung der Störgeräusche entscheidend, so dass wir nicht mehr nachvollziehen können, wer keine Tomaten mag. Wir können Informationen hinzufügen, um das Modell zu anonymisieren. Diese Verteilung ist aber nicht trivial, weshalb unser Privacy Proxy unseren Kunden diese Aufgabe vollautomatisch abnimmt“, mahnt der Informatiker Kühne-Schlinkert.

Katulu stellt Federated Learning auf dem Flower Summit 2022 vor (engl.)

Wer trainiert beim Federated Learning mit?

In der Cloud des Maschinenbauers kommen die Modelle an und das System des Maschinenbauers hat im Vorfeld entschieden, welche Modelle von den Kunden zum Trainieren genutzt werden. „Das kommt auf den Use-Case an, den ich verbessern will. Manche wollen die OEE optimieren, andere Wartungsprozesse und wieder andere die Materialverarbeitung an der Maschine“, berichtet der Unternehmer. Daraufhin melden sich die Edges und nehmen teil. „Der Kunde kann immer auch selbst entscheiden, ob er Teil des anstehenden Trainingslaufs sein will und das große Basismodell mit seinen kleinen Modellen verbessert werden soll.“

Fünf Maschinen im Feld für einen spezifischen Anwendungsfall reichen den Hamburger bereits, um ein Training erfolgreich zu absolvieren. Wichtig sei nur, dass die Maschinen konnektiert sind. Wenn das Trainierte vom Maschinenbauer zurück zum Kunden kommt, kann dieser entscheiden, ob er dies eine Verbesserung für ihn darstellt und er es nutzen möchte – vollautomatisiert natürlich. „Wir lassen die Modelle auf der Edge parallel gegeneinander laufen und testen, ob und wie sich die Verbesserungen spürbar auswirken“, ergänzt der Federated Learning-Spezialist.

Katulus Edge spricht mit den MES- und SCADA-Systemen oder der Steuerung des Kunden. Das Edge Device direkt an der Maschine ermöglicht Inferenzen auf Basis von Live-Daten in harter Echtzeit, um das Ergebnis für die Feinabstimmung des Prozesses zu verwenden. Momentan kommen vor allem die Maschinenbauer auf ihn zu, die mit ihm gemeinsam Modelle für die Kunden im Feld weitertrainieren wollen. Mit seinem Unternehmen arbeitet er aber auch am unternehmensübergreifenden Einsatz von KI entlang von Liefer- und Wertschöpfungsketten. Das überzeugt Frank Wieben. Er will Federated Learning auch für sich nutzen. Auf die Maschinenbauer will er nicht warten.

Sie möchten gerne weiterlesen?