Predictive Maintenance aus Sensor- und Logdaten erproben

Die Anlagen des Maschinen­bauers laufen bei seinen Kunden im Dauerbetrieb, und jeder Stillstand kostet dort unmittelbar Produktion. Ziel ist deshalb die Vermeidung von Ausfallzeiten: Was der Maschinenbau Predictive Maintenance nennt, soll an den eigenen Anlagendaten geprüft werden. Drei Datenquellen kommen dafür in Frage, mit sehr unterschiedlichen Eigenschaften: Ersatzteilbestellungen, hochstandardisiert, aber ohne zwingenden Zusammenhang zum Defekt; Fehlerlogs der Steuerung; und Sensordaten aus der laufenden Anlage, aktuell und unverfälscht, aber gemischt strukturiert und in hoher Frequenz. Zur Prüfung werden Datensätze bereitgestellt — bewusst ohne erklärende Zusatz­informationen.

Drei Datenquellen, drei verschiedene Wahrheiten. Bevor ein Verfahren gewählt wird, muss klar sein, was die Daten hergeben. Ersatzteilbestellungen sind hochstandardisiert und leicht verfügbar, sagen aber nur mittelbar etwas über einen Defekt und liefern eine geringe Schätzgenauigkeit. Fehlerlogs sind stabil strukturiert und deckend, doch der Maschinen­zustand muss aus ihnen erst genähert werden. Sensordaten sind aktuell und unverfälscht, verlangen aber automatisierte Vorverarbeitung, die Übertragung großer Mengen und teils Rechen­leistung am Gerät. Wir haben die drei Quellen gegeneinander bewertet und die Analyse auf die beiden gelegt, die den Zustand am direktesten zeigen.

Aus hundert Dateien eine Faktentabelle. Für die Sensoranalyse kamen einhundert Flat Files mit über hunderttausend Zeilen gemischter Zahlen- und Freitext­informationen einer Druckanlage — ohne Erläuterung, was welche Spalte bedeutet. In einem mehrstufigen Verfahren haben wir die Dateien harmonisiert, in eine Faktentabelle überführt und in R weiterverarbeitet. Die automatisierte Aufbereitung erkannte 6.183 Maschinen­durchläufe mit 172 zusammenfassenden Größen. Über eine Hauptkomponenten­analyse und das Calinski-Verfahren blieb davon ein Bruchteil an erklärenden Größen übrig, und es zeigten sich sieben unterscheidbare Maschinen­zustände.

5,77 Millionen Logzeilen, mit Standard­werkzeug beherrschbar. Die zweite Untersuchung nahm die Fehlerlogs: neun Dateien, 1,6 Gigabyte, 5.770.209 Zeilen in 62 Spalten. Aufgebaut haben wir eine Analysestrecke unter zwei Vorgaben, kostenneutral und standardisierbar: die Logs in eine Datenbank, darüber Elasticsearch mit Kibana für die visuelle Analyse und R für die Statistik, alles auf einem Server. Die Unregelmäßigkeiten der Exporte haben wir dokumentiert, statt sie stillschweigend zu reparieren — eine falsch geteilte Spaltenüberschrift, Leerzeichen und Klammern in Feldnamen. Wer so etwas in den Dauerbetrieb überführt, behebt es an der Quelle und nicht im Analyseskript.

Was zusammenhängt, muss nicht doppelt überwacht werden. Über eine geclusterte Korrelations­matrix der Tages­häufigkeiten ließen sich die Fehlerereignisse in drei Gruppen ordnen: fünf Typen, die stark miteinander auftreten, zwei, die nur untereinander zusammenhängen, und einer, der weitgehend für sich steht. Für ein Frühwarn­system heißt das Entkomplizierung, denn es genügt, je Gruppe die Leitgröße zu beobachten. Ergänzend zeigten zwei Klassifizierungs­verfahren mindestens zwei beziehungs­weise mindestens vier Betriebs­zustände und einen Zustandswechsel mitten im Beobachtungs­zeitraum. Ein ARIMA-Modell prognostizierte die Tages­häufigkeit des häufigsten Fehlers etwa zehn Tage weit brauchbar, danach nicht mehr. Auch das ist ein Ergebnis: Die verfügbare Datenhistorie begrenzt den Horizont, nicht das Verfahren.