KI-Fehlerdiagnose in der Produktion: Ausfallzeiten halbieren

Die drei Phasen eines Maschinenausfalls und wo ein Assistent spart

Phase 1 – Erkennung: 5 Minuten. Die Anlage meldet einen Fehlercode oder stoppt. Ein Bediener meldet das an die Instandhaltung. Zeit: praktisch null bis fünf Minuten.

Phase 2 – Eingrenzung: 45 bis 60 Minuten (mit Assistent: 5 bis 10 Minuten). Ein Techniker wird informiert, fährt zur Anlage, liest den Fehlercode. Jetzt muss er verstehen, was der Code bedeutet. Ist es ein echtes Problem oder ein Sensor-Fehler? Ist es schon vorgekommen? Was half damals? Sind Ersatzteile zu besorgen? Ein erfahrener Techniker kennt die Antworten aus dem Kopf, aber nur wenn er diese Anlage regelmäßig wartet. Ein neuer muss alle Informationen zusammensuchen: Dokumentation, Fehlerkatalog, Wartungshistorie. Das kostet 30 bis 50 Minuten. Ein KI-Assistent antwortet auf alle diese Fragen in fünf bis zehn Minuten.

Phase 3 – Reparatur: 30 bis 120 Minuten (stark variabel). Der Techniker weiß jetzt, was zu tun ist, und macht es. Ein Fehler, der nur ein Sensor-Reset erfordert, dauert Minuten. Ein Fehler, der einen Zylinder-Tausch braucht, dauert Stunden. Der Assistent verkürzt diese Phase nicht direkt, hilft aber indirekt, weil der Techniker die Ersatzteile schon vorbestellt hat.

Warum schnellere Diagnose mehr kostet als nur Zeitersparnis

Ein Techniker, der schneller weiß, was er tun muss, spart nicht nur Zeit. Er spart auch Fehlerquoten. Ein Techniker, der einen Fehlercode missversteht und das falsche Teil tauscht, macht den Fehler später wieder schlimmer. Das passiert nicht oft, aber wenn, kostet es mehr als die ursprüngliche Reparatur. Auch spart schnellere Diagnose Kosten für eilige Ersatzteile. Ein Techniker, der weiß, dass eine bestimmte Membran auswechseln wird, kann sie schon bestellen, bevor er die Anlage sperrt. Ein Techniker, der erst nach Öffnen merkt, dass die Membran nicht da ist, muss mit einer Notfallbestellung zahlen, die 30 bis 50 Prozent Aufschlag kostet.

Die drei Datenquellen, die ein Assistent braucht

1. Fehlercodes und ihre Bedeutung. Aus dem Hersteller-Handbuch oder der Maschinen-Dokumentation. Diese Daten sind fast immer verfügbar, eventuell müssen sie nur aus PDFs extrahiert werden.

2. Wartungshistorie und bekannte Lösungen. Aus den Protokollen der Instandhaltung. Jedes Mal, wenn ein bestimmter Fehler repariert wurde, sollte notiert sein: Fehlercode, Ursache, Lösung, Dauer, Ersatzteile. Diese Daten sind oft unvollständig, aber der Assistent funktioniert schon mit 60 bis 70 Prozent Abdeckung.

3. Messwerte und Systemzustände. Aus der Prozessüberwachung. Die Temperatur, der Druck, die Vibration, die Stromaufnahme zum Zeitpunkt des Fehlers sind wichtige Hinweise. Ein Fehlercode könnte ein echter Fehler sein, oder nur ein Artefakt, weil die Umgebungstemperatur gestern Nacht 35 Grad war. Betriebe, die diese Daten nicht haben, müssen erst digitalisieren, was sich aber für andere Zwecke auch lohnt.

Vier Architektur-Entscheidungen vor der Einführung

1. Lokal oder über API? Ein lokaler Assistent läuft auf einer GPU im Rechenzentrum, liest die Fehlerdaten aus dem lokalen System und antwortet auf dem Monitor. Ein API-Assistent sendet Daten an einen Provider und bekommt die Antwort zurück. Beide funktionieren. Lokal ist schneller und sicherer, braucht aber Hardware. API ist flexibler und braucht weniger Betriebsaufwand, kostet aber je Anfrage. Faustregel: bei mehr als 20 Anfragen je Tag lohnt sich eine lokale Lösung.

2. Echtzeit oder Batch? Ein Echtzeit-Assistent antwortet, wenn der Fehler kommt, sofort im Ticketsystem. Ein Batch-System liest nächtlich alle Fehler des Tages und antwortet verzögert. Echtzeit ist besser für kritische Maschinen, Batch ist ausreichend für unkritische.

3. Assistenz oder Automatisierung? Ein Assistenz-Modell zeigt dem Techniker eine Diagnose, und der Techniker entscheidet. Ein Automatisierungs-Modell würde handeln. Im produktiven Betrieb braucht es immer Menschen, die sehen und entscheiden, deshalb assistieren wir nur.

4. Welches Modell? Ein großes Modell (70 Mrd. Parameter) versteht nuancierte Fehler, braucht aber viel Hardware. Ein kleines (7 Mrd. Parameter) ist schnell und ressourcenschonend, versteht aber keine komplexen Zusammenhänge. Die beste Wahl ist ein mittleres Modell (32 bis 35 Mrd. Parameter) im 4-Bit Format, das auf 16 GB RAM läuft und unter einer Sekunde antwortet.

Die häufigsten Fehler bei der Implementierung

1. Assistent antwortet, ohne Quelle anzugeben. Der Techniker muss wissen, ob die Diagnose aus einem Handbuch kommt oder aus einem trainierten Modell, das auch falsch sein kann. Immer eine Quelle mit angeben (Dokumentseite, ähnliches Protokoll, Fehlercode-Datenbank).

2. Keine Feedback-Schleife für den Assistenten. Jedes Mal, wenn ein Techniker die Diagnose korrigiert, sollte das Feedback in das System gehen. Das macht den Assistenten besser.

3. Trainiert auf alte Daten, nicht auf aktuelle. Ein Assistent, der nur mit Wartungsprotokollen aus 2023 trainiert ist, funktioniert schlecht. Die Trainingsdaten müssen kontinuierlich aktualisiert werden, mindestens vierteljährlich.

Was ein solcher Assistent nicht tut

Ein Assistent diagnostiziert keine physischen Schäden, die nicht in den Fehlercode reflektiert werden. Ein Getriebeschaden, der sich mechanisch anfühlt, aber keinen Fehlercode erzeugt, wird der Assistent nicht vorhersagen. Auch ersetzt ein Assistent keinen guten Techniker. Ein Team, in dem niemand Maschinenbau versteht und alle blindlings dem Assistenten folgen, wird auf lange Sicht scheitern.

Was Sie diese Woche tun können

• Ziehen Sie aus den Logs des Piloten zwei Zahlen: gleichzeitige Anfragen zur Spitzenzeit und Kontextlänge im Median. Ohne diese beiden Zahlen ist jede Dimensionierung geraten.
• Rechnen Sie die Gewichte aus: Parameterzahl mal Byte je Parameter im geplanten Zahlenformat.
• Addieren Sie den Kontextspeicher für die gemessene Spitzenlast und schlagen Sie 20 Prozent Overhead auf.
• Lassen Sie sich vom Anbieter bestätigen, dass die genannte Karte das genannte Modell bei dieser Nutzerzahl trägt.