Warum Ihre Schwellenwert-Alarme 60 % der Ausfälle übersehen — und was Sie dagegen tun können

Der Anruf um 3 Uhr morgens

Es ist 3:14 Uhr, als Ihr Telefon klingelt. Pumpe 7A im Kühlkreislauf hat sich festgefressen. Produktionslinie 3 steht still. Das Instandhaltungsteam rückt aus. Jemand ruft das Monitoring-Dashboard auf — und sämtliche Alarme standen bis zum katastrophalen Ausfall auf Grün.

Wie ist das möglich? Sie haben monatelang Condition Monitoring aufgebaut. Sie haben Schwingungssensoren, Temperaturfühler, Stromwandler. Sie haben Schwellenwerte nach ISO 10816 eingestellt. Alles sah gut aus.

Nur war es eben nicht gut. Die Pumpe lag seit drei Wochen im Sterben. Ihre Schwellenwerte konnten es nur nicht erkennen.

Das Schwellenwert-Problem: Statische Regeln in einer dynamischen Welt

Das typische Szenario: Sie installieren einen Schwingungssensor am Pumpenlager und setzen einen Alarm bei 4,5 mm/s RMS — basierend auf dem ISO-Standard oder dem OEM-Handbuch. Wenn die Schwingung diesen Wert überschreitet, erhalten Sie eine Warnung.

Das funktioniert — manchmal. Es erkennt plötzliche Ausfälle, bei denen ein Lager innerhalb von Stunden von normal auf katastrophal wechselt. Doch die meisten industriellen Ausfälle verlaufen nicht so.

Betrachten Sie folgendes reales Muster: Ein Pumpenlager startet bei einer Grundschwingung von 1,8 mm/s. Über sechs Wochen steigt der Wert auf 2,1, dann 2,4, dann 2,9 mm/s. Gleichzeitig steigt die Lagertemperatur um 3 Grad Celsius, und der Motorstrom wird beim Anlauf leicht unregelmäßig. Jedes Signal liegt deutlich innerhalb seines individuellen Schwellenwerts. Kein Alarm wird ausgelöst. Dann, an einem Dienstag, ändert sich etwas — die Schwingung springt auf 6,2 mm/s und das Lager fällt innerhalb von Stunden aus.

Der Ausfall war vorhersehbar. Die Schwellenwerte haben ihn übersehen, weil sie das Falsche betrachteten: absolute Werte statt Muster.

Zweites Szenario: Der frequenzumrichtergesteuerte Lüfter

Hier ein weiteres Muster, das Schwellenwerte systematisch übersehen. Ein Frequenzumrichter (VFD) steuert einen Lüfter im Lüftungssystem und variiert die Drehzahl zwischen 600 und 1.800 U/min je nach Prozessanforderung. Das Lüfterlager entwickelt einen Außenringdefekt.

Die Herausforderung: Die Schwingungsamplitude ist direkt proportional zum Quadrat der Drehzahl. Bei 1.800 U/min zeigt das Lager 3,2 mm/s — innerhalb der ISO-10816-Zone „zufriedenstellend". Bei 600 U/min zeigt dasselbe Lager 0,4 mm/s — kaum über dem Grundrauschen. Ein fester Schwellenwert, der auf Volldrehzahl eingestellt ist, löst bei Teildrehzahl nie aus, und ein Schwellenwert für Teildrehzahl führt bei Volldrehzahl ständig zu Fehlalarmen.

Währenddessen schreitet der Defekt fort. Die Schwingung des Lagers bei einer gegebenen Drehzahl steigt um 0,1 mm/s pro Woche. Da sich die Betriebsdrehzahl jedoch alle paar Minuten ändert, ist der Trend in der Rohzeitreihe unsichtbar. Nur ein Modell, das die Schwingung nach Betriebsdrehzahl normalisiert — das lernt, dass „2,1 mm/s bei 900 U/min abnormal ist, obwohl 3,0 mm/s bei 1.800 U/min in Ordnung ist" — kann dies erkennen.

Frequenzumrichtergesteuerte Anlagen machen einen wachsenden Anteil der industriellen Assets aus (geschätzt 30–40 % der Motoren in modernen Anlagen), und jede einzelne davon hat dasselbe drehzahlabhängige Baseline-Problem, das statische Schwellenwerte nicht lösen können.

Erkennungsmethoden im Vergleich

Nicht alle Erkennungsansätze sind bei allen Fehlertypen gleich wirksam. So schneiden gängige Methoden ab:

| Erkennungsmethode | Plötzlicher Ausfall | Schleichender Lagerverschleiß | Drehzahlabhängige Degradation | Sensorübergreifendes Muster | Typische Vorlaufzeit | |---|---|---|---|---|---| | Statischer Schwellenwert | 70 % Erkennung | 20–30 % Erkennung | < 10 % Erkennung | Nicht anwendbar | Stunden | | Hüllkurvenanalyse | 50 % Erkennung | 60–70 % Erkennung | 40 % Erkennung | Nicht anwendbar | Tage bis Wochen | | LSTM Autoencoder | 85 % Erkennung | 85–90 % Erkennung | 80–85 % Erkennung | 90 %+ Erkennung | 2–4 Wochen | | TranAD (Transformer) | 90 % Erkennung | 90–95 % Erkennung | 90 % Erkennung | 95 %+ Erkennung | 2–6 Wochen |

Die zentrale Erkenntnis: Schwellenwertbasierte Methoden haben eine Obergrenze, die durch ihre Einzelsensor- und Festbaseline-Architektur vorgegeben ist. ML-Methoden verbessern sich mit dem Datenvolumen und erfassen die sensorübergreifenden, drehzahlabhängigen Muster, die den Großteil der realen Ausfälle ausmachen.

Warum Maschinen nicht nach Regeln ausfallen

Industrieanlagen sind komplex. Drei Faktoren machen statische Schwellenwerte grundsätzlich ungeeignet, um die meisten Ausfälle zu erkennen:

Schleichender Verschleiß ist für feste Grenzwerte unsichtbar. Ein Lager springt nicht von „in Ordnung" auf „defekt". Es degradiert über Wochen oder Monate. Die frühen Anzeichen sind minimal — ein Anstieg der Schwingung um 0,3 mm/s, eine Temperaturverschiebung um ein halbes Grad, eine subtile Veränderung der spektralen Oberwellen. Jedes Einzelsignal ist Rauschen. Zusammen ergeben sie ein klares Signal.

Ausfallmuster erstrecken sich über mehrere Sensoren. Eine Pumpe fällt nicht eindimensional aus. Ein Außenringdefekt zeigt sich in Schwingung, Temperatur, Stromaufnahme und manchmal Durchflussrate — gleichzeitig, aber subtil. Kein einzelner Schwellenwert erfasst ein mehrdimensionales Muster. Sie müssten Hunderte von sensorübergreifenden Regeln schreiben, und Sie würden trotzdem die übersehen, an die Sie nicht gedacht haben.

„Normal" ändert sich mit den Betriebsbedingungen. Ein Motor, der an einem kühlen Montagmorgen mit 1.800 U/min läuft, hat ein anderes „Normal" als derselbe Motor bei 3.600 U/min an einem heißen Freitagnachmittag unter Volllast. Jahreszeitliche Temperaturschwankungen, Produktwechsel und Lastvariationen verschieben die Baseline. Ein fester Schwellenwert löst entweder ständig Fehlalarme aus oder ist so hoch eingestellt, dass er echte Probleme übersieht.

Branchendaten bestätigen dies: Studien von McKinsey und verschiedene Reliability-Engineering-Umfragen legen nahe, dass traditionelles schwellenwertbasiertes Monitoring weniger als die Hälfte der vermeidbaren Ausfälle erkennt — viele Schätzungen liegen bei etwa 40 %. Der Rest tritt entweder als Überraschung auf oder wird von einem Mitarbeiter erkannt, der zufällig bemerkt hat, dass sich etwas nicht richtig anfühlte.

Was KI-basierte Erkennung tatsächlich erkennt

Die Alternative sind nicht mehr Regeln. Es ist ein System, das lernt, wie „normal" für jede Maschine unter ihren spezifischen Betriebsbedingungen aussieht, und meldet, wenn die Realität von dieser gelernten Baseline abzuweichen beginnt.

Genau das leisten LSTM Autoencoder. Ein LSTM-Netzwerk (Long Short-Term Memory) ist ein KI-Modell, das besonders gut darin ist, Muster in Zeitreihendaten zu erlernen — genau die Art von Daten, die Ihre Sensoren erzeugen. Ein Autoencoder wird darauf trainiert, normales Verhalten zu rekonstruieren. Wenn die Maschine gesund ist, stimmt die Rekonstruktion des Modells eng mit der Realität überein. Wenn etwas schief zu gehen beginnt, steigt der Rekonstruktionsfehler an — auch wenn jeder einzelne Sensor noch innerhalb seines Schwellenwerts liegt.

Stellen Sie es sich so vor: Sie kennen das Geräusch Ihres Automotors. Sie können das exakte Frequenzspektrum, das „normal" definiert, nicht aufschreiben, aber Sie bemerken sofort, wenn etwas anders klingt. Ein LSTM Autoencoder macht dasselbe mit Sensordaten — aber über 10 oder 20 Sensoren gleichzeitig, rund um die Uhr, ohne müde zu werden.

Das Modell lernt pro Maschine. Das „Normal" von Pumpe 7A unterscheidet sich vom „Normal" von Pumpe 7B, selbst wenn es sich um dasselbe Modell handelt. Es passt sich an Last, Drehzahl und Umgebungsbedingungen an. Und es erkennt die Art von langsamer, sensorübergreifender Degradation, die Schwellenwerte schlicht nicht erfassen können.

Die Erklärbarkeitslücke

Hier scheitern die meisten KI-Lösungen. Das Modell erkennt eine Anomalie und löst einen Alarm aus: „Pumpe 7A — Anomalie erkannt, Konfidenz 94 %."

Gut. Und nun?

Ihr Reliability Engineer erhält diesen Alarm und stellt die naheliegende Frage: Warum? Welcher Sensor? Was hat sich verändert? Ist es ein Lagerproblem oder ein Dichtungsproblem? Sollte ich eine Abstellung planen oder einfach beobachten?

Wenn die Antwort „Das Modell hat es so gesagt" lautet, landet dieser Alarm im Papierkorb. Und das zu Recht — kein erfahrener Ingenieur wird eine produktionskritische Pumpe auf Basis einer Zahl aus einer Blackbox abstellen.

Hier kommt SHAP (SHapley Additive exPlanations) ins Spiel. SHAP stammt aus der Spieltheorie und berechnet exakt, wie viel jedes Eingabemerkmal (jeder Sensorwert, jede berechnete Kennzahl) zur Entscheidung des Modells beigetragen hat. Nicht ungefähr. Exakt.

14 Tage Vorwarnung — mit Beleg

Hier ein konkretes Beispiel aus der Erkennung eines Außenringdefekts. Das KI-basierte System meldet eine Anomalie an einer Kreiselpumpe 14 Tage bevor das Lager ausgefallen wäre. Der Alarm sagt nicht nur „Anomalie" — er enthält die SHAP-Attribution:

• vibration_x_rms: +0,34 — der dominierende Beitrag, erhöhte Schwingung in radialer Richtung
• temperature_delta: +0,21 — Lagertemperatur steigt schneller als die Gehäusetemperatur
• current_kurtosis: +0,12 — subtile Spitzen im Motorstrom, die auf intermittierenden mechanischen Widerstand hindeuten

Der Ingenieur liest dies und hat sofort eine Hypothese: erhöhte Radialschwingung plus Temperaturanstieg plus Stromspitzen — das ist ein klassisches Außenringdefekt-Muster. Er plant eine Inspektion beim nächsten geplanten Stillstand, bestätigt den Defekt per Ultraschall und tauscht das Lager in einem 2-Stunden-Fenster — anstatt mit einem katastrophalen Ausfall und 18 Stunden ungeplanter Ausfallzeit umgehen zu müssen.

Das Schwellenwert-System? Immer noch grün. Es wäre noch weitere 12 Tage grün geblieben.

Von reaktiv zu prädiktiv

Der Wechsel von Schwellenwert-Alarmen zu KI-basierter Anomalieerkennung bedeutet nicht, Ihre Monitoring-Infrastruktur zu ersetzen. Ihre Sensoren, Historian-Systeme und SCADA-Anlagen bleiben genau dort, wo sie sind. Der Unterschied liegt in dem, was darauf aufsetzt: Statt statischer Regeln haben Sie ein System, das lernt, sich anpasst und erklärt.

Der Übergang geschieht nicht über Nacht, und er muss es auch nicht. Die meisten Werke beginnen damit, ML-basierte Erkennung auf ihre 10–20 kritischsten Assets aufzusetzen — diejenigen, bei denen ungeplante Ausfallzeit am meisten kostet. Die bestehenden Schwellenwert-Alarme bleiben als Sicherheitsnetz erhalten. Innerhalb von 2–4 Wochen erlernt das ML-Modell die normalen Betriebsmuster jeder Maschine. Innerhalb von 2–3 Monaten haben Sie genügend Daten, um die Erkennungsraten zu vergleichen: Wie viele Anomalien hat das ML-Modell erkannt, die Schwellenwerte übersehen haben? Nach unserer Erfahrung lautet die Antwort konstant 3–5-mal mehr Erkennungen bei 60–80 % weniger Fehlalarmen.

Die Wirtschaftlichkeit ist eindeutig. Ein einziger verhinderter ungeplanter Stillstand an einer kritischen Produktionslinie — 2 Wochen früher erkannt statt um 3 Uhr morgens — bezahlt typischerweise ein Jahr vorausschauende Überwachung der gesamten Anlage. Die Frage ist nicht, ob KI-basierte Erkennung besser funktioniert als Schwellenwerte. Die Frage ist, wie viele Ausfälle Sie bereit sind zu akzeptieren, während Sie sich entscheiden.

Für Werksleiter übersetzt sich dies direkt in Zahlen: weniger ungeplante Stillstände, geringere Ersatzteillagerbestände (weil Sie wissen, was ausfällt, bevor es ausfällt) und bessere Wartungsplanung. Für Reliability Engineers bedeutet es, weniger Zeit mit der Verfolgung von Fehlalarmen zu verbringen und mehr Zeit für die Ausfälle aufzuwenden, die wirklich zählen — mit den Daten, um jede Entscheidung zu belegen.

Testen Sie es mit Ihren eigenen Daten

Prevly bringt KI-basierte Anomalieerkennung mit integrierter SHAP-Erklärbarkeit für industrielle Anlagen — ohne ein Data-Science-Team zu benötigen. Verbinden Sie Ihre Sensordaten, und innerhalb weniger Tage sehen Sie, was Schwellenwert-Alarme übersehen.

Starten Sie Ihre kostenlose Testphase auf prevly.org und erfahren Sie, was Ihre Maschinen Ihnen schon lange mitteilen wollten.

Weiterführende Artikel: Wie SHAP eine Vorhersage erklärt · Restlebensdauer-Vorhersage erklärt · Vom Sensor zur Vorhersage