Ein Produktionsleiter, mit dem wir letztes Jahr gesprochen haben, stellte eine einfache Frage: „Wie viele Monate dauert es, bis Ihr KI-System den ersten Motor vor einem Ausfall rettet?" Die Antwort war unangenehm, aber ehrlich: Das hängt davon ab, wie lange Sie vorher Daten gesammelt haben. Wenn weniger als sechs Monate — reicht wahrscheinlich auch ein Jahr nicht.
Vorausschauende Instandhaltung (PdM) gehört zu den Bereichen, in denen KI/ML nachweisbare Ergebnisse liefert. Eine Reduzierung ungeplanter Ausfälle um 30 – 50 % ist eine Zahl, die sich branchenübergreifend in Projekten wiederholt. Gleichzeitig ist es ein Bereich, in dem Marketing-Hype und reale Produktionsergebnisse stärker auseinanderklaffen als anderswo. Ziel dieses Artikels ist es aufzuzeigen, wo ein ML-Modell wirklich Mehrwert schafft, welche Datenvoraussetzungen Sie erfüllen müssen und wann es sinnvoller ist, mit regelbasierter Logik zu beginnen.
Was vorausschauende Instandhaltung konkret löst
Traditionelle Instandhaltung funktioniert in zwei Modi: reaktiv (Reparatur nach dem Ausfall) und präventiv (Austausch nach Zeitplan, unabhängig vom tatsächlichen Zustand). Beide haben offensichtliche Schwächen — reaktive Instandhaltung erzeugt ungeplante Ausfälle, präventive führt zum vorzeitigen Austausch von Teilen, die noch Jahre hätten laufen können.
Vorausschauende Instandhaltung fügt einen dritten Modus hinzu: Sie greifen ein, wenn die Anlage tatsächlich anfängt zu degradieren — nicht davor und nicht danach. In der Praxis bedeutet das:
- Kontinuierliche Datenerfassung von Sensoren (Schwingungen, Temperatur, Schallemission, Stromspektrum)
- Anomalieerkennung oder direkte Schätzung der Restnutzungsdauer (RUL — Remaining Useful Life)
- Warnung der Bediener typischerweise 3 – 14 Tage vor dem vorhergesagten Ausfall
Gut funktioniert es bei Anlagen mit einem gut charakterisierten Degradationsprozess — Lager, Elektromotoren, Kompressoren, Pumpen, Getriebe. Gerade bei diesen Anlagentypen sind Frequenzspektren der Schwingungen ein zuverlässiger Informationsträger für den Verschleißzustand.
Wo ein ML-Modell wirklich Mehrwert schafft
Anomalieerkennung ohne Labels
Der universellste Einstiegspunkt ist das Training eines Modells ausschließlich auf Normalzustände der Anlage. Das Modell lernt die Verteilung des „gesunden" Signals — jede Abweichung, auch eine, die noch niemand zuvor gesehen hat, löst einen Alert aus. Technisch handelt es sich um Autoencoder oder Methoden wie Isolation Forest, oder Vision Transformer, die auf Schwingungsspektrogrammen trainiert werden.
Vorteil: Sie benötigen keine historischen Ausfallaufzeichnungen. Nachteil: höhere False-Positive-Rate in den ersten Betriebsmonaten, bis die Schwellenwerte für die konkrete Anlage kalibriert sind.
Fehlerklassifikation und RUL-Schätzung
Wenn Sie genügend Datenhistorie haben — und das ist der entscheidende Punkt — kann das Modell den konkreten Fehlertyp klassifizieren und die Restnutzungsdauer schätzen. Dabei werden Werte von 88 – 97 % Prognosegenauigkeit bei gut ausgerüsteten Anlagen nach 6 – 12 Monaten Datenerfassung erreicht. Diese Zahlen stammen jedoch aus Benchmark-Datensätzen, nicht zwingend aus dem ersten Produktionsjahr Ihrer konkreten Anlage.
Multimodale Signalfusion
Die Kombination von Schwingungen, Temperatur, Schallemission und Stromspektrum in einem Modell liefert deutlich bessere Genauigkeit als Ansätze mit nur einem Sensor. In der Praxis bedeutet das mehr Sensoren und eine robustere Datenpipeline — bei kritischen Anlagen ist die Investition jedoch gerechtfertigt.
Generative synthetische Daten für seltene Ausfälle
Eines der größten Probleme bei PdM: katastrophische Ausfälle sind selten. Das Modell bekommt nicht genug Beispiele. Ein bewährter aktueller Ansatz ist die Generierung synthetischer Failure-Events mittels GAN oder Diffusionsmodellen — so lässt sich der Trainingsdatensatz dort künstlich erweitern, wo reale Daten schlicht nicht vorhanden sind.
Datenvoraussetzungen — was Ihnen der Anbieter nicht sagt
Vor jeder Entscheidung über den Einsatz einer ML-Lösung müssen diese Fragen beantwortet werden:
- 1.Wie lange erfassen wir bereits Sensordaten? — Weniger als sechs Monate bedeutet ein Cold-Start-Problem. Das Modell weiß nicht, was „abnormal" ist, weil es weder genug Normalzustände noch deren saisonale Schwankungen gesehen hat.
- 2.Haben wir Failure-Events erfasst? — Datum und Art der Störungen müssen im System vorliegen. Ohne diese Daten ist weder ein Fehlerklassifikationsmodell noch ein RUL-Modell trainierbar.
- 3.Sind die Daten synchronisiert? — Sensoren, SCADA, ERP und Wartungsprotokolle müssen konsistente Zeitstempel haben. Eine Stunde Versatz zwischen Quellen kann das gesamte Modell durcheinanderbringen.
- 4.Wie hoch ist die Abtastfrequenz? — Schwingungsanalysen erfordern typischerweise Hunderte von Hz. Temperatur reicht einmal pro Minute. Ein unterabgetastetes Signal deckt das Problem nicht auf.
- 5.Sind die Daten sauber? — Tote Sensoren, feststeckende Werte, Kommunikationsunterbrechungen. Datenqualität ist in der Praxis ein größeres Problem als die Wahl des Modells.
Wir haben Projekte gesehen, bei denen ein Unternehmen für eine ML-Plattform bezahlt hat, bevor die Datenerfassungspipeline in Ordnung war. Das Ergebnis: Das Modell wurde auf Rauschen trainiert, und die ersten Alarme waren False Positives. Das entmutigt Kunden schnell — was schlimmer ist als gar kein PdM.
Wann eine einfachere Regel ausreicht
Ein ML-Modell ist nicht immer die richtige Wahl. Es gibt Szenarien, in denen ein regelbasiertes System oder statistische Prozesskontrolle (SPC) das gleiche oder ein besseres Ergebnis zu einem Bruchteil der Kosten liefert:
- Anlagen mit eindeutigen Schwellenwerten — wenn ein Motor auf 95 °C aufheizt, ist das ein Alarm. Dafür brauchen Sie kein neuronales Netz.
- Neue Anlage ohne Datenhistorie — das Modell hat nichts zum Trainieren, Regeln funktionieren ab dem ersten Tag.
- Wenige Anlagen desselben Typs — ML-Modelle zeigen bei kleiner Stichprobe keine Stärke.
- Regulierte Prozesse mit Auditierbarkeit — eine Regel „Alarm bei Überschreitung von X" lässt sich einem Regulierer leicht erklären. Ein Black-Box-Modell weitaus weniger.
Der vernünftige Weg: Beginnen Sie mit Regeln und SPC, sammeln Sie Daten, und wenn Sie 12+ Monate Geschichte mit ausreichend Failure-Events haben — dann lohnt es sich, ML in Betracht zu ziehen.
ROI-Realität: was rechnen und was nicht
Marketingmaterialien nennen eine Reduzierung ungeplanter Ausfälle um 30 – 50 %. Diese Zahlen sind realistisch — aber es dauert, sie zu erreichen. Eine realistische ROI-Kalkulation muss rechnen:
Auf der Nutzenseite: - Reduzierte Kosten eines ungeplanten Ausfalls (Stundensatz der Linie × durchschnittliche Ausfallzeit × Häufigkeit) - Verlängerung der Lebensdauer von Teilen — weniger vorzeitige Austausche - Reduzierung der Sicherheitsbestände an Ersatzteilen
Auf der Kostenseite: - Sensorinfrastruktur (Nachrüstung alter Anlagen ist teuer) - Datenpipeline und Integration mit SCADA/ERP - Lizenzen oder interne Entwicklung der ML-Plattform - Zeit für die Modellkalibrierung — die ersten 3 Monate mit False Positives sind unproduktiv - Laufende Modellpflege (Drift, neue Anlagen, Firmware-Updates)
Aus Dutzenden von Einsätzen sehen wir, dass der Break-even typischerweise im Jahr 2 – 3 eintritt, nicht im Jahr 1 — sofern von null begonnen wird. Wenn Sie ein bestehendes OPC-UA- oder SCADA-System mit sauberen historischen Daten haben, können Sie schneller sein.
Damit verbunden ist auch die Frage des Hardware-Budgets — mehr dazu im Artikel KI-Copilot für Bediener, in dem wir die Wirtschaftlichkeit von Edge-KI-Geräten behandeln.
Integration mit bestehenden Systemen
Vorausschauende Instandhaltung ist kein isoliertes Modul — sie muss an Ihre bestehenden Systeme angebunden sein:
- CMMS/EAM (Computerized Maintenance Management System) — ein PdM-Alert muss automatisch einen Work Order generieren, nicht nur eine Meldung im Dashboard. Wenn der Bediener den Alarm manuell ins CMMS übertragen muss, wird das System sehr schnell nicht mehr genutzt.
- SCADA / OPC-UA — Standardprotokolle für Industriedaten; die meisten modernen PdM-Plattformen unterstützen sie nativ.
- ERP — die Anbindung an Ersatzteilbestellungen ist für eine geschlossene Regelschleife entscheidend.
Eine Architektur, bei der PdM als Silo mit eigenem Dashboard ohne Anbindung an operative Prozesse steht, ist einer der häufigsten Gründe, warum Projekte den erwarteten ROI nicht liefern. Über die Integration von BMS-Systemen mit der SCADA-Ebene lesen Sie mehr im Artikel über BMS, KNX und Loxone.
Digitaler Zwilling und Multi-Agent-Ansätze
In der aktuellen Generation von PdM-Lösungen zeichnet sich eine neue Architektur ab: digitale Zwillinge von Anlagen in Kombination mit KI-Agenten. Anstatt eines einzelnen Klassifikationsmodells haben Sie ein Netzwerk von Agenten — einer sammelt und bereinigt Daten, ein zweiter klassifiziert den Degradationstyp, ein dritter simuliert die Restnutzungsdauer auf einem physikbasierten Modell der Anlage, ein vierter generiert Empfehlungen für das Wartungspersonal.
Dieser Ansatz ist leistungsfähiger als ein zweckgebundenes ML-Modell, aber auch teurer in Implementierung und Betrieb. Er lohnt sich dort, wo die Anlage einen ausreichend hohen Wert hat (CNC-Zentrum, Turbine, Kompressorstation) und wo eine Fehlprognose wirklich hohe Kosten verursacht. Für gewöhnliche Pumpen im Sekundärkreislauf ist es überdimensioniert.
Über Architekturen von Multi-Agent-Systemen schreiben wir ausführlicher in KI in der Praxis: Multi-Agent-Systeme.
Vorausschauende Instandhaltung vs. KI-Sichtprüfung — wo liegt die Grenze
Vorausschauende Instandhaltung und visuelle Inspektion sind zwei verschiedene Domänen, auch wenn beide zur „KI in der Industrie" gehören. PdM arbeitet mit Zeitreihen aus Sensordaten und beantwortet die Frage wann eine Anlage ausfällt. Visuelle Inspektion arbeitet mit Bildern und beantwortet die Frage ob ein konkretes Teil einen Defekt hat oder nicht. Mehr zur visuellen Qualitätskontrolle finden Sie im Artikel KI-Sichtprüfung Qualitätskontrolle.
Interessant ist, dass sich diese Domänen zu überschneiden beginnen — Schwingungsspektrogramme werden mit visuellen Modellen (CNN) verarbeitet, Kamerasysteme überwachen gleichzeitig Temperaturprofile. Multimodale Fusion ist die Richtung, in die sich der gesamte Bereich entwickelt.
Häufige Fragen
Wie lange dauert es, bis ein PdM-System zuverlässig funktioniert?
In der Praxis sollten Sie mit 6 – 12 Monaten vom Start der Datenerfassung bis zu den ersten zuverlässigen Prognosen rechnen. Die ersten 3 Monate sind durch eine höhere False-Positive-Rate (ca. 10 – 15 %) gekennzeichnet, bis das Modell auf die konkrete Anlage und ihre Betriebszyklen kalibriert ist. Diese Zeit lässt sich verkürzen, wenn Sie archivierte historische Daten aus dem SCADA-System haben — aber sie müssen sauber und mit Wartungsprotokollen synchronisiert sein.
Reicht es für PdM, handelsübliche industrielle IoT-Sensoren zu installieren?
Sensoren sind nur der erste Schritt. Genauso wichtig ist es, eine konsistente Zeitsynchronisation, eine zuverlässige Datenübertragung ohne Ausfälle und eine korrekte Speicherung mit einer Retention von mindestens 2 Jahren sicherzustellen. Die meisten Misserfolge bei PdM-Projekten hängen nicht mit der Modellwahl zusammen, sondern mit einer mangelhaften Datenpipeline — tote Sensoren, feststeckende Werte, Zeitversatz zwischen Quellen.
Wann ergibt es Sinn, ML statt Regeln einzusetzen?
Ein ML-Modell lohnt sich, wenn Sie mindestens 12 Monate saubere Sensordaten mit ausreichend erfassten Failure-Events haben, Anlagen desselben Typs in ausreichender Anzahl und einen Degradationsprozess, der sich nicht trivial mit einem einfachen Schwellenwert erfassen lässt. Für Anlagen mit eindeutigem Grenzwert (Temperatur, Druck, Strom) sind Regeln einfacher, auditierbar und gleich wirksam.
Wie hoch ist die reale Prognosegenauigkeit?
Unter idealen Bedingungen — gut ausgerüstete Anlage, 6 – 12 Monate Daten, wiederkehrende Fehlertypen — werden Werte von 88 – 97 % Genauigkeit genannt. Diese Zahlen stammen überwiegend aus Benchmark-Datensätzen und kontrollierten Studien. Im ersten Jahr realer Produktion bei neuen Anlagen sollten Sie mit niedrigerer Genauigkeit rechnen, bis das Modell saisonale Schwankungen und verschiedene Betriebsmodi absorbiert hat.
Muss ich mein gesamtes CMMS-System ersetzen, um PdM einzusetzen?
Nein. Die meisten modernen PdM-Plattformen lassen sich über API oder Standardkonnektoren in bestehende CMMS- und ERP-Systeme integrieren. Entscheidend ist, dass ein PdM-Alert automatisch einen Work Order generiert — manuelles Übertragen ist langfristig nicht tragbar. Wenn Ihr CMMS keine API hat, gibt es in der Regel Middleware-Lösungen, die diese Brücke schlagen, ohne das System austauschen zu müssen.
*Wenn Sie entscheiden, ob und wie Sie vorausschauende Instandhaltung in Ihrem Betrieb einführen sollen, beurteilen wir gerne den Zustand Ihrer Sensorinfrastruktur und Ihrer Daten — und sagen Ihnen direkt, ob der Einstieg mit ML sinnvoll ist oder ob ein anderer Schritt zuerst zielführender wäre. Kontaktieren Sie uns für eine unverbindliche Beratung.*