Prädiktive Wartung in der Fertigung mit KI

Prädiktive Wartung in der Fertigung: von Prozesstelemetrie zu priorisierten Maßnahmen

Foto von Ant Rozetsky auf Unsplash.

Jedes Werk betreibt bereits die Sensoren, die ein Programm für prädiktive Wartung braucht. SPS, SCADA-Historiker, Vibrationssonden, Thermosensoren und OPC-UA-Server erzeugen mehr Telemetrie pro Schicht, als ein Zuverlässigkeitsteam manuell lesen könnte. Der Großteil dieser Daten liegt im Historiker und wird nie zu einer Entscheidung.

Sensorabdeckung ist selten das Problem. Das fehlende Puzzleteil liegt zwischen rohen Tags und einer priorisierten Liste, was diese Woche zu reparieren ist: die bereits vorhandene Analyse der Prozesstelemetrie zu lesen und sie in Maßnahmen zu verwandeln, auf die ein Wartungsteam reagieren kann, bevor die Linie stillsteht.

Wo Stillstandszeiten wirklich herkommen

Ungeplante Stillstandszeiten kündigen sich selten selbst an. Ein Lager verschlechtert sich über Wochen, bevor es festfrisst. Die Stromaufnahme eines Motors kriecht über einen Monat nach oben, bevor die Auslösung erfolgt. Bis ein Bediener merkt, dass etwas nicht stimmt, war das Fehlerbild meist schon eine Weile in den Daten sichtbar.

Die direkten Kosten der letztlichen Reparatur sind oft die kleinere Zahl. Produktionsausfall, beschleunigte Ersatzteile, Überstunden und verpasste Lieferfenster summieren sich darum herum. Häufig zitierte Branchenschätzungen setzen die Reduktion durch ein funktionierendes Programm für prädiktive Wartung im Bereich von 30-50% für ungeplante Stillstandszeiten an, wobei die Zahl stark von der Baseline-Wartungsreife abhängt und als Richtwertschätzung gelesen werden sollte, nicht als Garantie für ein bestimmtes Werk.

Die meisten Maschinenwartungsprogramme haben bereits die Sensoren, um diese Ausfälle früher zu erkennen. Was fehlt, ist eine Möglichkeit, jedes Signal kontinuierlich zu überwachen, ohne für jedes einzelne einen Alarm zu erzeugen.

Von SPS, SCADA und OPC UA zu einer Entscheidungsebene

Zuverlässigkeitsteams haben die Telemetrie bereits: SPS-Tags, SCADA-Punkte und zunehmend ein Standard-OPC-UA-Server, der sie alle an einem Ort verfügbar macht. Eine Entscheidungsebene über diese Daten zu legen bedeutet nicht, die Regelschleife zu berühren.

FrostLogic Explore liest Prozesstelemetrie nur lesend, über OPC UA, Modbus oder Herstellerschnittstellen von SPS. Es schreibt niemals einen Sollwert und befindet sich niemals im Regelpfad. Die Engine hinter dieser Fabrikausrüstungsüberwachung, Frostdynamics(tm), nimmt dieselben Tags auf, die der SCADA-Historiker bereits speichert, und korreliert sie über die Physik, die die Ausrüstung tatsächlich steuert, nicht nur über Schwellenwerte pro Tag.

Diese Unterscheidung ist auf einem Fabrikboden wichtiger als fast überall sonst. Die Vibration einer Pumpe, ihr Motorstrom, ihre Lagertemperatur und ihre Durchflussrate sind keine unabhängigen Variablen. Ein Schwellenwert auf eine einzelne davon wird entweder zu oft auslösen oder den Fehler übersehen, der sich als kleine Verschiebung über alle vier gleichzeitig zeigt. Die Tags gemeinsam zu lesen, so wie ein erfahrener Zuverlässigkeitsingenieur es bereits gedanklich tut, ist das, was eine Entscheidungsebene von einem weiteren Dashboard unterscheidet.

Anomalien, die auf einer Linie wichtig sind

Nicht jede Abweichung ist ein Ticket wert. Industrielle Anomalieerkennung, die auf einer Linie tatsächlich nützlich ist, sucht nach einer bestimmten Form: Abweichungen, die sich über die Zeit aufbauen und mehr als ein Signal betreffen.

Vibrationsdrift ist das klarste Beispiel. Die Vibrationssignatur eines Lagers springt nicht; sie steigt, oft über Wochen, deutlich bevor sie einen festen Alarmschwellenwert überschreitet. Thermisches Kriechen an einem Motor oder Getriebe verhält sich genauso: ein langsamer Anstieg, den eine schichtbasierte Sichtprüfung völlig übersehen wird.

Kreuzsignal-Inkohärenz erfasst Ausfälle, die ein Einzelkanal-Schwellenwert strukturell nicht erfassen kann. Wenn Durchfluss, Druck und Leistungsaufnahme aufhören, sich so zu bewegen, wie es die Prozessphysik vorgibt, hat sich stromaufwärts etwas verändert, selbst wenn kein einzelner Tag seine Grenze überschritten hat. Energie-pro-Einheit-Drift ist dasselbe Muster, angewendet auf Kosten: Eine Linie, die pro produzierter Einheit mehr Energie verbraucht als ihre eigene historische Baseline, ohne entsprechende Produktionsänderung, verschlechtert sich irgendwo, auch wenn noch nichts Alarm geschlagen hat.

Jedes davon ist mit den bereits installierten Sensoren erkennbar. Was sie erfordern, ist die kontinuierliche Überwachung der Beziehung zwischen Signalen, nicht das einmalige Abscannen eines einzelnen Tags gegen eine feste Grenze pro Schicht.

Kausale Filterung auf dem Fabrikboden

Eine stromaufwärts liegende Kreuzsignal-Anomalie löst tendenziell ein Dutzend nachgeschalteter Tags aus. Der Durchfluss sinkt, der Druck steigt in der nächsten Stufe sprunghaft an, ein Temperaturalarm wird in der Stufe danach ausgelöst, und ein Zuverlässigkeitsingenieur öffnet ein Schichtprotokoll voller Warnungen, die eigentlich ein einziges Ereignis sind.

Kausale Filterung verfolgt diese Kette bis zur Grundursache zurück und fasst sie zu einem einzigen Ticket zusammen: das Pumpenlager, nicht die elf Symptome seines Ausfalls. Das ist der Unterschied zwischen einer priorisierten, erklärten Ursache und einem Alarmsturm, den das Team lernt zu ignorieren.

Um es explizit zu sagen: Explore priorisiert und erklärt die Ursache. Es erstellt oder verfolgt keine Arbeitsaufträge und ist kein CMMS.

Das Ergebnis ist ein priorisiertes, kausal verfolgtes Ticket, das einem Zuverlässigkeitsingenieur sagt, was tatsächlich falsch ist und wie sicher sich das System darüber ist. Was danach passiert, ob das Ticket in einem bestehenden CMMS, einem Papierprotokoll oder einem Slack-Kanal landet, ist der Prozess des Werks. Die Aufgabe von Explore endet bei der Diagnose, früh geliefert und bereits gefiltert.

Gleiche Engine, anderes Signal

Der physikbewusste Ansatz, der einen Lagerausfall auf einer Produktionslinie erfasst, ist dieselbe Engine, die eine HVAC-Drift in einem Gewerbegebäude erfasst. Beide sind Fälle, in denen mehrere korrelierte Signale auf ein Muster überwacht werden, das ein Einzeltag-Schwellenwert übersehen würde, und beide müssen das nachgeschaltete Rauschen unterdrücken, das eine echte Grundursache erzeugt.

Was sich zwischen einem Fabrikboden und einem Gebäude ändert, ist der Signalsatz, nicht die zugrunde liegende Logik. Die Lüftungsanlage eines Gebäudes erzeugt eine andere Telemetrieform als der Servomotor einer Stanzlinie, aber die Frage, die die Plattform beantwortet, welche dieser Abweichungen ein echter Vorbote eines Ausfalls ist und was ihn tatsächlich verursacht, ist identisch. Unser begleitender Beitrag über prädiktive Wartung in Gewerbegebäuden behandelt dieselbe Engine, angewendet auf HVAC, Kältemaschinen und Gebäudetechnik.

Für Fertigungs- und Schwerindustriebetreiber im Besonderen bedeutet das, dass ein Werk keinen maßgeschneiderten Analyseaufbau braucht, um das zu bekommen. Dieselbe Plattform, die das BMS eines Gebäudes liest, liest den OPC-UA-Server eines Werks und priorisiert das Ergebnis auf die gleiche Weise: danach, wie stark es die Betriebszeit gefährdet, nicht danach, wie laut der Alarm klingt. Mehr dazu, wie das speziell zu einem Fertigungsstandort passt, finden Sie auf unserer Seite zur Fertigungsindustrie.

Häufige Fragen

Was ist prädiktive Wartung in der Fertigung? Es bedeutet, Sensor- und Prozessdaten, Vibration, Temperatur, Stromaufnahme, Durchfluss und ähnliche Signale zu nutzen, um Ausrüstungsverschlechterung zu erkennen, bevor sie einen ungeplanten Stopp verursacht, anstatt Teile nach einem festen Zeitplan zu ersetzen oder auf einen Ausfall zu warten.

Wie viel Stillstandszeit reduziert prädiktive Wartung tatsächlich? Schätzungen variieren je nach Werk und Baseline-Reife, aber eine Reduktion im Bereich von 30-50% für ungeplante Stillstandszeiten wird in Branchenstudien häufig zitiert. Betrachten Sie es als Richtwertschätzung und nicht als Zahl, auf die man ohne eigene Baseline-Daten einen Business Case aufbaut.

Erfordert das Hinzufügen einer prädiktiven Wartungsebene neue Sensoren? Normalerweise nicht. Die meisten Werke haben bereits die benötigten SPS-Tags, SCADA-Punkte und OPC-UA-Tags. Die Lücke liegt typischerweise in der kontinuierlichen Korrelation vorhandener Signale, nicht in der Sensorabdeckung.

Was ist OPC UA und warum ist das hier wichtig? OPC UA ist ein herstellerneutraler industrieller Kommunikationsstandard, der Prozessdaten von SPS und SCADA-Systemen einheitlich verfügbar macht. Das ermöglicht es einer Entscheidungsebene wie Explore, Telemetrie von Ausrüstung verschiedener Hersteller ohne eine kundenspezifische Integration pro Maschine zu lesen. Details auf Protokollebene finden Sie in unserem Glossareintrag.

Ist das dasselbe wie ein CMMS? Nein. Ein CMMS verwaltet Arbeitsaufträge und Wartungspläne. Explore priorisiert und erklärt Anomalien in Ihren Prozessdaten. Es erstellt oder verfolgt keine Arbeitsaufträge. Die beiden sind ergänzend, keine konkurrierenden Kategorien.

Steuert Explore irgendwelche Ausrüstung oder schreibt es an die SPS? Nein. Explore liest Prozesstelemetrie nur lesend, über OPC UA, Modbus oder die API eines SPS-Herstellers. Es schreibt niemals einen Sollwert und befindet sich niemals innerhalb der Regelschleife.

Welche Arten von Ausfällen werden am frühesten erkannt? Fehlermodi, die sich allmählich über korrelierte Signale aufbauen, Lagerverschleiß, thermisches Kriechen an Motoren und Getrieben und Kreuzsignal-Inkohärenz, zeigen sich tendenziell Wochen in den Daten, bevor ein fester Schwellenwert ausgelöst hätte. Plötzliche mechanische Ausfälle ohne allmähliche Signatur sind allein aus der Telemetrie schwerer vorherzusagen.

Wie unterscheidet sich das von einem Standard-Vibrationsüberwachungsprogramm? Vibrationsüberwachung allein beobachtet eine Signalklasse. Explore korreliert Vibration zusammen mit Stromaufnahme, Temperatur, Durchfluss und anderen Prozess-Tags, was Fehlermodi erfasst, die ein reines Vibrationsprogramm übersieht, und den nachgeschalteten Alarmsturm unterdrückt, den eine einzige Grundursache sonst erzeugt.

Bereit, es an Ihren eigenen Daten zu sehen?

Sehen Sie es an einer Stichprobe Ihrer Prozessdaten. Bringen Sie einen Export Ihrer OPC-UA- oder SCADA-Tags mit, und wir gehen durch, wie eine priorisierte, kausal verfolgte Warteschlange gegen Ihre tatsächliche Ausrüstung aussieht. 30 bis 60 Minuten, keine Verpflichtung in beide Richtungen. Darüber sprechen.