Ein LKW fällt mitten in der Nacht aus. Die Ware verdirbt, der Kunde springt ab, die Werkstatt verlangt für die Expresskalkulation das Doppelte. Und dann, Tage später, stellt jemand fest: Die Motortemperatur hatte schon drei Wochen vorher ungewöhnlich geschwankt. Die Daten waren da. Niemand hat sie gelesen.
Genau das ist das Versprechen von Predictive Maintenance: Ausfälle ankündigen, bevor sie passieren. Das Versprechen ist real. Die Ernüchterung setzt ein, sobald man in die eigene Datenbasis schaut – und feststellt, dass nirgendwo sauber dokumentiert ist, wann welche Komponente wie ausgefallen ist.
Viele Projekte scheitern genau hier, bevor sie beginnen. Dieser Artikel zeigt, dass das nicht sein muss. Mit dem Ansatz des weak supervised machine learning (schwach überwachten Lernens) lässt sich ein belastbares Vorhersagesystem aufbauen, auch ohne perfekte Datenbasis. Es ist kein einfacher Weg. Aber er existiert.
Wartung kennt heute im Wesentlichen zwei Spielarten: Man wartet, bis etwas kaputt geht (reaktiv), oder man tauscht Teile nach einem festen Zeitplan aus – etwa alle 10 000 Kilometer (präventiv). Ersteres ist teuer, wenn es schiefgeht. Letzteres ist teuer, weil es immer zu früh ist.
Predictive Maintenance bricht aus diesem Dilemma aus. Die Idee: Sensordaten aus dem laufenden Betrieb – Temperaturen, Drücke, Laufzeiten, Kraftstoffverbrauch – werden kontinuierlich ausgewertet, um vorherzusagen, wann eine Komponente wahrscheinlich ausfallen wird. Der Austausch erfolgt genau dann, wenn er nötig ist.
Damit das funktioniert, muss ein Modell aus historischen Daten lernen, welche Muster einem Ausfall vorausgehen. Fachleute nennen diesen Ansatz supervised machine learning (überwachtes Lernen): Das Modell lernt anhand von Beispielen, bei denen der Ausgang bekannt ist – so wie ein erfahrener Werkstattleiter aus hundert ähnlichen Fällen ein Gespür dafür entwickelt, welche Geräusche harmlos sind und welche nicht.
Das Problem: Supervised machine learning braucht gelabelte Daten – Datensätze, bei denen zu jedem Messzeitraum bekannt ist, ob danach ein Schaden aufgetreten ist oder nicht. Und genau diese Markierungen fehlen. Nicht weil die Daten nicht erhoben wurden, sondern weil niemand sie jemals in dieser Form zusammengeführt hat.
Bevor ein Modell trainiert werden kann, steht eine im Grunde detektivische Frage: Welche Messwerte – in der Fachsprache Features – verraten tatsächlich etwas über den Zustand einer Komponente? Nicht jeder Sensor, der Daten liefert, liefert auch nützliche Daten.
Typische Features im Bereich Fahrzeug- oder Maschinenflotten:
Wichtiger als die einzelnen Messwerte ist oft, wie sie sich über die Zeit verhalten: Steigt die Temperatur? Schwankt der Verbrauch stärker als bei vergleichbaren Fahrzeugen? Solche abgeleiteten Kennzahlen sind diagnostisch trennschärfer als jede Momentaufnahme.
Diese Auswahl ist keine technische Fingerübung. Sie erfordert Menschen, die verstehen, was in einer Maschine tatsächlich passiert und die gelernt haben, zwischen Signal und Rauschen zu unterscheiden.
Ein Modell, das Ausfälle vorhersagen soll, muss aus vergangenen Ausfällen lernen. Das klingt selbstverständlich und ist in der Praxis das größte Hindernis. Denn die Antwort auf die Frage „Wann ist was ausgefallen?“ liegt in den wenigsten Unternehmen tatsächlich vor:
Ein Modell übernimmt die Wahrheit seiner Trainingsdaten, unkritisch und vollständig. Wenn im Datensatz „kein Schaden“ steht, obwohl längst einer vorlag, nur unbemerkt oder undokumentiert, lernt das Modell genau das: Schau weg. Im schlimmsten Fall entsteht so ein System, das mit hoher Konfidenz falsch liegt – und das ist gefährlicher als keines zu haben.
Unzuverlässige Vorhersagen erzeugen falsches Vertrauen. Und falsches Vertrauen in ein Wartungssystem kann teurer werden als der Ausfall, den man vermeiden wollte.
Wenn direkte Schadens-Labels fehlen, helfen Ersatzindikatoren – Ereignisse, die zwar kein Ausfall sind, aber häufig mit einem korrelieren:
Weitere Strategien zur Erzeugung sogenannter schwacher Labels:
Bekannte Grenzwerte aus der Technik werden als Schwellenwerte genutzt. Beispiel: „Wenn die Öltemperatur länger als 15 Minuten über 120 °C liegt, gilt das als kritisches Ereignis.“ Diese Regeln sind keine präzisen Ausfall-Labels – aber sie sind ehrlicher als ein leerer Datensatz.
Manche Komponenten verschleißen nach Beanspruchung, nicht nach Kalenderzeit. Ein Motor mit 100 000 Kilometern unter Volllast ist anders beansprucht als einer mit derselben Laufleistung auf der Autobahn. Aus der Kombination von Nutzungsintensität und typischer Lebensdauer lässt sich ableiten, wie lange eine Komponente voraussichtlich noch hält – Fachleute sprechen vom estimated remaining useful life (eRUL), der geschätzten verbleibenden Nutzungsdauer. Wichtig: Auf diesem Weg erzeugte Labels kodieren Annahmen über typische Verschleißkurven – sie ersetzen keine beobachteten Ausfälle, sondern dienen als grober Ausgangspunkt, der mit jeder Iteration durch echte Daten geschärft wird. In Phase 3 wird der eRUL dann nicht mehr als Label, sondern als eigentliches Vorhersageziel der Modelle verwendet.
Nach einem bekannten Ausfall lassen sich in der Vergangenheit oft systematische Sensormuster erkennen, die ihm vorausgingen. Diese Korrelation kann genutzt werden, um ähnliche Muster in anderen Fahrzeugen mit einem Label zu versehen. Dabei ist Vorsicht geboten: Ein Muster, das in einem Fahrzeug dem Ausfall vorausging, muss nicht zwingend für andere Fahrzeuge verallgemeinerbar sein. Die Labels, die auf diesem Weg entstehen, müssen daher validiert werden – etwa indem geprüft wird, ob das identifizierte Muster tatsächlich auch in anderen Fahrzeugen vor einem Ausfall auftrat, und nicht nur zufällig mit einem einzelnen Schadensfall korreliert.
Keiner dieser Wege ist perfekt. Aber zusammen ergeben sie eine Grundlage, auf der sich arbeiten lässt.
Dabei ist eine strukturelle Einschränkung offen anzusprechen: Historische Daten erfassen nur Ausfälle, die auch bemerkt und dokumentiert wurden. Katastrophale Frühausfälle, stille Verschleißprozesse oder Fahrzeuge, die nach einem schweren Schaden aus dem Betrieb ausgeschieden sind, hinterlassen keine Spuren in der Datenbasis – sie sind schlicht nicht vorhanden. Das Modell lernt aus dem, was sichtbar war, nicht aus dem, was tatsächlich passiert ist. Dieses sogenannte Survivorship-Bias-Problem lässt sich nicht vollständig lösen, aber durch konsequente Einbindung von Domänenexperten abmildern: Sie kennen die blinden Flecken der Dokumentation und können Ausfallmuster benennen, die in keiner Werkstattakte auftauchen.
Da keine vollständigen Schadensdaten vorliegen, wird das Modell nicht auf einen Schlag trainiert. Stattdessen folgt ein dreistufiger Ansatz, der das verfügbare Wissen systematisch aufbaut.
Im ersten Schritt werden die Sensordaten ohne jede Schadensinformation ausgewertet – Fachleute sprechen von unsupervised machine learning, maschinellem Lernen ohne Vorgaben. Das Ziel ist zunächst bescheiden: verstehen, welche Fahrzeuge oder Komponenten sich ähnlich verhalten – und welche auffällig abweichen.
Gleichzeitig wird nach Veränderungspunkten gesucht: Wann hat ein Sensor begonnen, sich anders zu verhalten als zuvor? Ein Kühlsystem, das über Wochen stabile Werte lieferte und dann zu schwanken beginnt, zeigt möglicherweise den Beginn eines Verschleißprozesses an – noch bevor irgendjemand etwas bemerkt.
Diese Phase liefert keine Vorhersagen. Aber sie liefert etwas, das mindestens genauso wertvoll ist: ein ehrliches Bild davon, was die Daten überhaupt hergeben.
In der zweiten Phase werden die in Phase 1 identifizierten Auffälligkeiten mit den schwachen Labels kombiniert. Daraus entsteht ein erstes Vorhersagemodell – noch grob, noch fehleranfällig, aber lernfähig.
Der entscheidende Faktor in dieser Phase sind nicht Algorithmen, sondern Menschen. Domänenexperten werden systematisch einbezogen – und ihre Rolle geht weit über das gelegentliche Absegnen von Ergebnissen hinaus. Erfahrene Techniker und Flottenmanager helfen dabei, die Daten überhaupt erst richtig zu verstehen: Was bedeutet ein bestimmter Sensorwert im konkreten Betriebskontext? Welche Grenzwerte sind technisch sinnvoll – und welche klingen plausibel, halten aber der Realität nicht stand? Welche Modellannahmen sind tragfähig – und welche sind stille Fehler, die sich erst später rächen?
Das Modell wählt gezielt die Datenpunkte aus, bei denen es sich am unsichersten ist, und legt sie den Experten vor: „Schaut euch diese Fahrzeugverläufe an – glaubt ihr, dass dort tatsächlich ein Problem bestand?“ Die Antworten fallen selten so aus, wie das Modell sie erwartet. Experten widersprechen, korrigieren, zweifeln an – und das ist produktiv. Allerdings haben auch Experten systematische blinde Flecken: Elektrische Defekte werden erfahrungsgemäß eher unterschätzt als mechanische, weil sie seltener direkt beobachtet werden. Bestimmte Ausfallmuster, die statistisch auffällig sind, können betrieblich so normalisiert sein, dass niemand sie als Problem benennt. Expertenfeedback ist deshalb ein wertvolles Korrektursignal, aber kein unfehlbares. Es wird als ein Eingangssignal unter mehreren behandelt, nicht als abschließendes Urteil.
In der dritten Phase verschiebt sich die Frage: nicht mehr nur ob ein Ausfall droht, sondern wann, also wie lange eine Komponente voraussichtlich noch funktionieren wird, der estimated remaining useful life (eRUL).
Hierfür kommen spezialisierte Überlebenszeit-Modelle zum Einsatz – Modelle, die mit unvollständig beobachteten Ausfällen umgehen können und nicht voraussetzen, dass jeder Ausfall vollständig dokumentiert ist. Sie lernen, unter welchen Umständen Komponenten länger oder kürzer halten. Faktoren wie Fahrprofil, Streckenbeschaffenheit, Beladung und Belastungshistorie fließen ein. Einfachere Varianten dieser Modelle arbeiten mit statistischen Annahmen über typische Lebensdauern. Flexiblere Varianten erkennen komplexere Zusammenhänge, verlangen aber mehr Daten. Die leistungsfähigsten Varianten lesen den Verlauf der Sensordaten über die Zeit und erkennen, in welchem Stadium sich eine Komponente gerade befindet – nicht anders als ein erfahrener Arzt, der aus Vitalwerten einen Trend abliest, noch bevor ein Symptom spürbar wird.
Ein LKW im Fernverkehr und ein Verteilerfahrzeug im Stadtbetrieb liefern Sensordaten in derselben Struktur – aber sie erzählen völlig verschiedene Geschichten. Beide über dasselbe Modell laufen zu lassen wäre so, als würde man einen Marathonläufer und einen Sprinter mit denselben Leistungsnormen bewerten.
Deshalb werden Fahrzeuge oder Maschinen in homogene Gruppen – Populationen – eingeteilt, bevor ein Modell trainiert wird. Innerhalb einer Population sind die Einheiten vergleichbar genug, dass ihre Muster gemeinsam interpretierbar sind.
Die Wahl der richtigen Populationen ist eine der folgenreichsten Entscheidungen im gesamten Prozess. Zu grobe Einteilungen verwässern die Muster bis zur Bedeutungslosigkeit. Zu feine Einteilungen lassen zu wenig Datenpunkte übrig, um stabile Modelle zu erzeugen. Es gibt keine objektiv richtige Antwort, nur bessere und schlechtere Kompromisse, die mit jeder Iteration neu bewertet werden.
Features erzeugen
Aus Rohdaten werden aussagekräftige Kennzahlen berechnet – Durchschnittswerte, Trends, Ausreißer, Vergleiche mit ähnlichen Fahrzeugen.
Populationen bilden und getrennt trainieren
Für jede Fahrzeuggruppe wird ein eigenes Modell trainiert. Dabei werden die Features innerhalb jeder Population neu bewertet: Ein Feature, das bei einem Großteil der Fahrzeuge dieser Gruppe fehlt oder überall denselben Wert hat, liefert keine nützliche Information und wird entfernt. Was populationsübergreifend relevant ist, muss es innerhalb einer bestimmten Gruppe nicht sein.
Labels erzeugen
Die schwachen Labels aus den beschriebenen Strategien werden für den Trainingsbestand erzeugt – mit dem Wissen, dass sie unvollständig sind, und mit dem Ziel, sie iterativ zu verbessern.
Modell bewerten
Nach dem Training wird geprüft, ob das Modell tatsächlich besser ist als sein Vorgänger. Zwei Perspektiven sind unverzichtbar:
Für die Bewertung sind einfache Trefferquoten ungeeignet: Ein Modell, das nie einen Alarm auslöst, liegt bei seltenen Ausfällen statistisch fast immer „richtig“ – und ist trotzdem wertlos. Entscheidend sind stattdessen zwei Kennzahlen: Precision (wie viele der ausgelösten Alarme waren tatsächlich berechtigt?) und Recall (wie viele der tatsächlichen Ausfälle hat das Modell erkannt?). Da ein ungerechtfertigter Alarm – eine unnötige Werkstattfahrt – teuer, aber verkraftbar ist, während ein übersehener Ausfall katastrophal sein kann, wird als kombinierter Gütegrad der Fβ-Score mit β < 1 verwendet – ein F1-Score, der Precision stärker gewichtet als Recall. Das Modell soll zuverlässig warnen, wenn es warnt – auch wenn es dabei nicht jeden Ausfall erwischt.
Ein Modell, das seine Entscheidungen nicht erklären kann, wird im Betrieb nicht überleben – und sollte es auch nicht. Visualisierungen und Erklärungen werden deshalb direkt an Domänenexperten übergeben. Deren Reaktion ist oft aufschlussreicher als jede Kennzahl: Bestätigen sie einen Befund, wächst das Vertrauen in das Modell. Widersprechen sie – und das passiert regelmäßig –, ist das kein Rückschlag. Es ist die wertvollste Information, die ein Modell bekommen kann.
Ein Predictive-Maintenance-Modell ist kein Produkt, das man einmal baut, abliefert und vergisst. Es ist ein System, das nur so gut wird wie die Rückkopplungsschleifen, die es am Leben halten.
Experten aus Technik und Betrieb prüfen die Ergebnisse anhand von Visualisierungen und verständlichen Erklärungen – und sie widersprechen regelmäßig. Mal stimmt ein Schwellenwert nicht mit der betrieblichen Realität überein. Mal beschreibt ein Feature einen statistischen Zusammenhang, der technisch keinen Sinn ergibt. Solche Einwände werden nicht übergangen, sondern als Korrektursignal eingespeist. Mit jeder Iteration rückt das Modell näher an die Wirklichkeit heran.
Die Kombination zweier Messgrößen kann aussagekräftiger sein als jede einzeln. Ein bisher ignorierter Sensor kann sich als entscheidend herausstellen.
Mit wachsender Betriebserfahrung werden Regeln und Ersatzindikatoren präziser. Was zu Beginn ein grober Näherungswert war, wird zur belastbaren Grundlage.
Eine Gruppe, die sich als zu heterogen herausstellt, wird unterteilt. Zwei Gruppen, die sich ähnlicher sind als gedacht, werden zusammengelegt.
Interne Einstellungen des Modells werden angepasst – ein Prozess, der keine großen Einsichten erfordert, aber ohne den kein Modell sein Potenzial ausschöpft.
Solange das Modell noch verbessert wird, werden alle Schritte regelmäßig erneut durchgeführt – mit einem breiteren und besser gelabelten Datensatz als beim letzten Mal. Jede Iteration gilt nur dann als Fortschritt, wenn die Kennzahlen (Precision, Fβ) sich verbessern oder zumindest nicht verschlechtern.
Auch nach der Entwicklung ist ein einmal trainiertes Modell kein Dauerzustand. Fahrzeugflotten verändern sich, Einsatzprofile verschieben sich, Reparaturpraktiken entwickeln sich weiter. Ein Modell, das vor zwei Jahren auf realen Daten kalibriert wurde, kann heute systematisch falsch liegen – ohne dass irgendjemand es bemerkt. Deshalb müssen dieselben Bewertungsmetriken auch im Regelbetrieb überwacht werden. Sobald Precision oder Fβ unter definierte Schwellenwerte fallen, ist ein erneutes Training fällig.
Wer diesen Prozess als Zeichen von Unreife betrachtet, hat Modellentwicklung missverstanden. Iteration ist nicht der Beweis, dass etwas nicht funktioniert – sie ist der Mechanismus, durch den es funktionieren lernt. Und kontinuierliche Überwachung im Betrieb ist nicht Misstrauen gegenüber dem Modell, sondern Respekt vor der Tatsache, dass sich die Realität weiterentwickelt.
Viele Unternehmen warten auf den richtigen Moment: erst wenn die Schadensdaten vollständig sind, erst wenn die Dokumentation stimmt, erst wenn die Voraussetzungen ideal sind. Dieser Moment kommt nicht.
Weak supervised machine learning ist kein Trick, der schlechte Daten in gute verwandelt. Es ist ein strukturierter Umgang mit einer Realität, die sich nicht wegdiskutieren lässt: Die Daten sind unvollständig. Die Labels sind unscharf. Das Wissen der Experten ist unverzichtbar, aber schwer zu formalisieren.
Genau deshalb ist die Gefahr des falschen Vertrauens – die vielleicht größte Gefahr dieses Ansatzes – kein Argument gegen das System, sondern eine Anforderung an seinen Aufbau. Ein Modell, das seine Entscheidungen nicht erklären kann, hat in diesem Prozess nichts verloren. Domänenexperten, die Befunde bestätigen oder verwerfen, sind keine optionale Ergänzung – sie sind ein unverzichtbarer Bestandteil dieses Schutzmechanismus, gemeinsam mit der Anforderung an Erklärbarkeit und den metrikgestützten Freigabekriterien zwischen Iterationen. Und eine Iteration, die ein Modell nur dann weiterführt, wenn es besser ist als sein Vorgänger, ist keine Schwäche – sie ist die einzige Qualitätssicherung, die bei unvollständiger Datenbasis funktioniert.
Der Einstieg ist machbar. Die Ergebnisse verbessern sich, aber nur, wenn der Prozess konsequent bleibt. Und der Preis des Wartens auf perfekte Bedingungen ist in jedem Nacht-Ausfall auf einer Fernstrecke ablesbar.