Warum liefert ein Modell zur Wartungsvorhersage am Anfang schlechtere Ergebnisse, als die vorhandene Sensorik eigentlich zulässt? Fast immer, weil die Daten dafür zwar vorhanden sind, aber nie in der Form gesammelt wurden, die ein Modell zum Lernen braucht. Die Sensoren selbst sind fast nie der Engpass. Der Engpass ist, was mit ihren Daten bisher passiert ist.
In vielen Betrieben, die über Maschinen mit moderner Sensorik verfügen, wird diese Sensorik ausschließlich zur Störungsmeldung genutzt: Ein Wert überschreitet eine Schwelle, eine Warnung geht raus, jemand schaut nach. Das ist eine reaktive Nutzung derselben Daten, aus denen sich auch eine vorausschauende Wartung ableiten ließe, nur wird dafür die Historie gebraucht, nicht nur der aktuelle Wert.
Das eigentliche Problem liegt vor dem Modell, nicht im Modell
Ein Vorhersagemodell braucht Beispiele dafür, wie Messwerte aussahen, kurz bevor eine Maschine tatsächlich ausgefallen ist. Genau diese Verknüpfung, Störung plus die Messreihe davor, existiert in den seltensten Betrieben als fertiger Datensatz. Störungen stehen in einem Wartungsprotokoll, Messwerte in einer Anlagensteuerung, und niemand hat beide bisher zusammengeführt, weil dafür bis zum Projektbeginn kein Anlass bestand.
Dieses Zusammenführen ist der Teil der Arbeit, der in Angeboten am leichtesten unterschätzt wird, weil er nach Fleißarbeit aussieht und nicht nach künstlicher Intelligenz. Er entscheidet aber, ob ein Modell überhaupt etwas lernen kann, bevor die erste Zeile Modellcode geschrieben ist.
Erstens: Bestandsaufnahme der Sensorik, nicht Vertrauen in die Spezifikation
Was auf dem Datenblatt einer Maschine steht, sagt wenig darüber, was tatsächlich im Betrieb gemessen und aufbewahrt wird. Auflösung, Messintervall und Aufbewahrungsdauer unterscheiden sich häufig erheblich von Anlage zu Anlage, selbst wenn sie technisch baugleich sind, weil die Konfiguration über Jahre gewachsen ist.
Deshalb beginnt ein solides Projekt mit einer Bestandsaufnahme der vorhandenen Sensorik: Was wird gemessen, in welcher Auflösung, und wie lange bleiben die Werte überhaupt gespeichert, bevor sie überschrieben werden. Werden Rohdaten nach wenigen Wochen gelöscht, fehlt am Ende genau die Historie, die ein Modell für vergangene Ausfälle bräuchte, und das fällt erst auf, wenn es zu spät ist, die Lücke noch zu schließen.
Zweitens: Historische Störungen und Messreihen tatsächlich zusammenführen
Erst wenn Störungsmeldungen und die zugehörigen Sensordaten über einen gemeinsamen Zeitstempel verknüpft sind, entsteht ein Trainingsdatensatz. In einem anonymisierten Projekt aus unserer Arbeit, einem mittelständischen Maschinenbauer mit rund 45 Millionen Euro Umsatz aus NRW, war genau dieser Schritt der zeitintensivste Teil der Umsetzung, deutlich vor dem eigentlichen Training der Modelle.
Der Aufwand lohnt sich trotzdem, weil er nicht nur dem ersten Modell dient. Ein einmal aufgebauter, gepflegter Zusammenhang zwischen Störung und Messverlauf bleibt als Datengrundlage bestehen und trägt auch künftige Verbesserungen, ohne dass die Verknüpfung ein zweites Mal von Hand gemacht werden muss.
Drittens: Ein Modell je Maschinentyp, kein Universalmodell
Verschiedene Maschinentypen fallen auf unterschiedliche Art aus, mit unterschiedlichen Vorboten in den Messwerten. Ein einziges Modell für den gesamten Maschinenpark zu bauen, klingt effizient, verwässert aber genau die Muster, die ein Modell je Typ zuverlässig erkennen könnte.
In dem genannten Projekt wurden deshalb separate Modelle je Maschinentyp aufgesetzt, auch wenn das mehr Pflegeaufwand bedeutet als ein einziges Modell. Die Schwellenwerte, ab denen gewarnt wird, kamen anschließend nicht aus einer Formel am Schreibtisch, sondern aus Gesprächen mit der Instandhaltung, die am besten einschätzen kann, welcher Vorlauf für eine geplante Wartung praktisch nötig ist.
Was daraus wurde, und was sich davon nicht übertragen lässt
In diesem einzelnen, anonymisierten Projekt ist die ungeplante Stillstandszeit um 60 Prozent gesunken, die Wartungskosten um 40 Prozent, bei einer Anlagenverfügbarkeit von stabil 98 Prozent. Diese Zahlen beschreiben einen konkreten Fall mit seiner eigenen Sensorhistorie und Maschinenlandschaft; sie sind kein Versprechen für jeden Maschinenpark, weil die Ausgangslage bei der Datenqualität von Betrieb zu Betrieb stark variiert.
Was sich verallgemeinern lässt, ist die Reihenfolge: Pilot an einigen wenigen Maschinen, erst danach das Ausrollen auf die ganze Linie, nicht umgekehrt. Ein Modell, das an drei Maschinen über Wochen seine Vorhersagen beweist, ist eine andere Ausgangslage für den Rollout als eines, das direkt für den ganzen Park gebaut wird, ohne je an echten Ausfällen gemessen worden zu sein.
Was Sie an Ihrer eigenen Anlagendatenlage prüfen können
Bevor Sie über ein Vorhersagemodell sprechen, klären Sie drei Punkte für Ihre wichtigsten Maschinen. Wie lange werden die Sensordaten tatsächlich gespeichert, nicht laut Datenblatt, sondern in der Praxis? Lassen sich vergangene Störungen heute schon mit einem Zeitstempel den passenden Messwerten davor zuordnen, oder liegen beide getrennt in verschiedenen Systemen? Und gibt es für die relevanten Maschinentypen überhaupt genug vergangene Ausfälle, aus denen sich etwas lernen lässt?
Fehlt eine dieser Voraussetzungen, heißt das nicht, dass sich Predictive Maintenance nicht lohnt. Es heißt, dass der erste Projektschritt bei KIsult eher in der Dateninfrastruktur liegt als im Modell, und dass dieser Schritt von Anfang an eingeplant gehört. Wie wir solche Integrationsprojekte technisch aufsetzen, beschreiben wir unter KI-Software & individuelle Lösungen. Wie die Vorprüfung aussieht, ob sich ein Fall wie dieser überhaupt rechnet, steht unter KI-Beratung & Strategie.