Demo 2: Predictive Maintenance mit RapidMiner

Dieser Demonstrator zeigt, wie eine Ausfall-Prognose im Rahmen eines Predictive Maintenance-Szenarios mit Hilfe des Entscheidungsbaum-Verfahrens in einem RapidMiner-Prozess durchgeführt wird. Wir verwenden einen Automobildatensatz, der in allen weiteren Demos des Predictive Maintenance-Zyklus verwendet wird: eine csv-Datei mit 140 Beobachtungen zu Merkmalen von Motoren. Die mit dieser Demo zu beantwortende Fragestellung aus dem Predictive Maintenance-Prozess lautet: "Bei welcher Kombination von Merkmalen tritt ein Ausfall ein?".

Für die Datenanalyse verwenden wir RapidMiner, da das Tool durch sein Bausteinkonzept und ausführliche Dokumentation einen leichten Einstieg bietet. Die Abbildung des Prozesses in RapidMiner und die Verwendung der entsprechenden Bausteine wird detailliert erläutert und durch ein 5-Minuten-Video veranschaulicht.

1 Der Automotive-Datensatz

Der Automotive-Datensatz ist eine Excel- bzw. csv-Datei und besteht aus insgesamt 140 Beobachtungen von Motoren. Als Trennzeichen für die Spalten wird in der csv-Datei das Semikolon verwendet.

Jede Beobachtung enthält den Vorhersagewert Ausfall, mit angenommenen Werten ja/nein, die Messungsnummer und Sensorwerte zu insgesamt 22 Merkmalen. Die erhobenen Merkmalswerte stammen aus Temperatur- und Druckmessungen sowie Mengenangaben zum Kraftstoff und zu Abgasdämpfen, die an verschiedenen Stellen im Motor erfasst wurden. Weiterhin enthält der Datensatz acht Merkmale zu den Lambdasonden (LS), die an jeweils einem Zylinder im Motor Messwerte liefern und in 2 Bänke unterteilt sind (d.h. das Merkmal LS32 gibt den Sensorwert vom dritten Zylinder innerhalb der zweiten Bank an). Bis auf die Katalysatortemperatur (Merkmalsname: KatTemp, Werte: normal/hoch) liegen für alle Merkmale numerische Messungen vor.

2 Die Fragestellung

Uns interessiert, welche Merkmalskombinationen, d.h. welches Zusammenspiel der Sensorwerte, zu einem Ausfall des Motors führen. Die Frage, die der Entscheidungsbaum beantworten soll, lautet also: Welche Kombination von Merkmalen wird zu einem Ausfall führen? Werden alle Merkmale einen Einfluss auf den Ausfall haben und falls nein, mit welchem Gewicht werden welche Merkmale einen Ausfall bewirken?

3 Ablauf der Datenanalyse

Die Datenanalyse für die Predictive Maintenance läuft in fünf Schritten ab:

• Schritt 1. Datenvorbereitung: Der Datensatz wird in Trainings- und Testdaten zerlegt, die Zielvariable wird festgelegt und die Daten werden bereinigt, d.h. je nach Datenlage normiert und transformiert, bei fehlenden Werte interpoliert und durch Algorithmen werden Ausreißer erkannt und behandelt.
  
• Schritt 2. Modell definieren: Gemäß den Daten wird ein passendes Modell gewählt, dies kann ein Entscheidungsbaum-Modell für Klassifikation oder Regression sein, oder eine Nächste Nachbarn-Klassifikation, dies hängt von der Fragestellung ab.
  
• Schritt 3. Modell trainieren: Mit den Trainingsdaten wird das Modell erstellt, d.h die Parameter des Modells geschätzt, z.B. die Verzweigungen und Blätter eines Entscheidungsbaums oder die Parameter als Kleinste-Quadrate-Schätzer in einem Regressionsmodell.
• Schritt 4. Modell validieren: Das Modell wird auf die Testdaten angewandt um eine Vorhersage zu erhalten, der Vergleich der Vorhersagen mit den bekannten Werten der Zielvariablen liefert die Performance­-Kennzahlen, die den Testfehler beschreiben, und angeben wie gut ein Modell ist.
  
• Schritt 5. Modell verwenden: Liegt ein gutes Modell vor, dann werden durch Anwendung des Modells auf neue Beobachtungen, deren Werte der Zielvariablen unbekannt sind, Vorhersagen getätigt.

4 Die Definition des Modells

Gemäß des Schrittes 2 des Zyklus der Datenanalyse in der Predictive Maintenance wählen wir ein den Daten entsprechendes Modell, die Formatierung der Daten und die Festlegung der Zielvariablen hängt von der Fragestellung ab. In dieser Demo wurde gemäß der Fragestellung das Merkmal AUSFALL als Zielvariable festgelegt, d.h. das Modell soll eine Klassifikation der Daten in AUSFALL Ja oder Nein durchführen.

Der Entscheidungsbaum ist ein intuitiv nutzbares Klassifikationsmodell, das für den Einstieg besonders geeignet ist, da es eine Visualisierung der Klassifikation bzw. der hierarchisch aufeinanderfolgenden Entscheidungen ermöglicht. Ein Entscheidungsbaum besteht aus einer Wurzel, Kindknoten und Blättern, wobei jeder Knoten eine Entscheidungsregel und jedes Blatt eine Antwort auf die Fragestellung darstellt. Um eine Klassifikation eines einzelnen Datenobjektes abzulesen, geht man vom Wurzelknoten entlang des Baumes abwärts. Bei jedem Knoten wird ein Merkmal abgefragt und eine Entscheidung über die Auswahl des folgenden Knoten getroffen. Dies wird so lange fortgesetzt, bis man ein Blatt erreicht. Das Blatt entspricht der Klassifikation.

Mehr Details und ein Mini-Beispiel zum Entscheidungsbaum-Modell sind unter Predictive Maintenance: Die Datenanalyse zu finden.

5 Die RapidMiner-Entwicklungsumgebung

RapidMiner ist eine Entwicklungsumgebung für die Datenanalyse, die als Open Source-Software an der Uni Dortmund entstanden ist und heute zu den Marktführern gehört. Sie bietet spezialisierte Oberflächen für Endanwender ohne Programmierkenntnisse, die die Verfahren des maschinellen Lernens einsetzen wollen.

Ein RapidMiner-Prozess kann aus Operatoren/Bausteinen zusammengeklickt und konfiguriert werden, diese Bausteine bilden alle gängigen Aufgaben der Datenanalyse ab und sind über verschiedene Ports miteinander verknüpfbar. Das ist einfach und benutzerfreundlich und bietet einen einfachen Einstieg in die Datenanalyse, auch für Anfänger ohne Programmierkenntnisse.

Perspektiven und Views

Beim Start der Entwicklungsumgebung RapidMiner Studio öffent sich die Welcome-Perspektive, d.h. eine Willkommens-Ansicht. Eine Perspektive besteht aus einer frei konfigurierbaren Auswahl von einzelnen Elementen der Oberfläche, den sogenannten Views. Diese können in der Ansicht beliebig angeordnet werden. In der Welcome-Perspektive gibt es zumindest voreingestellt nur einen einzigen View, den Willkommensschirm, der aus den unten gezeigten Tabs besteht.

Neben der Welcome-Perspektive gibt es noch die Design-Perspektive, diese ist die zentrale Ansicht von RapidMiner Studio in der alle Analyseprozesse erstellt und verwaltet werden, und die Result-Perspektive, die die Ergebnisse eines Analysesprozesses in Form von Daten, Modellen, Vorhersagen u.s.w. liefert. Der Wechsel von der Design- in die Result-Perspektive erfolgt automatisch nach Ausführung eines Prozesses.

Die Design-Perspektive der Entwicklungsumgebung RapidMiner Studio besteht standardmäßig aus den folgenden Elementen/Views, diese kann aber über den Menüpunkt View -> Show Panel durch weitere Elemente ergänzt werden, wie dem Data Editor, dem Log-Tab, dem Problems-Tab usw.

• Dem Verzeichnis (Repository), das Tutorials, vordefinierte Datensätze, sowie Datensätze aus der Community enthält, auch das eigene lokale Verzeichnis mit den Unterordnern data und processes wird angezeigt.
• Die Übersicht aller Operatoren in der Komponente Operators mit einer Suchleiste und deren Sortierung in Unterordner, wie Data Access oder Modeling.
• Der Auswahl der Perspektiven­/Ansichten, hier auch Views genannt, wie "Design" für die Anzeige des Prozesses oder "Results" für die Anzeige der Ergebnisse.
• Die Prozess-Komponente, die den Aufbau des Prozesses aus Bausteinen/Operatoren enthält, hier: das Einlesen einer Excel-Datei und deren Speicherung.
• Die Parametereinstellung zu den Operatoren, die je nach Baustein verschieden aussieht.
• Der Hilfe zu allen Operatoren und Themenbereichen wie Import, Read, Data usw.
• Dem RUN-Button zum Starten bzw. Durchlaufen des Prozesses.

Projekte in RapidMiner

Im Menü der Repository kann unter dem Punkt "Connect to a Project" das aktuelle Verzeichnis in einem Projekt geteilt werden, d.h. andere Benutzer mit einem Account haben über eine URL Zugriff auf das Verzeichnis. Die Versionskontrolle des Verzeichnisses und deren Projekte erfolgt mit Git, siehe auch die RapidMiner-Dokumentation zu Thema Projekt.

Templates in RapidMiner

Im Learn-Tab der Welcome-Perspektive können beim Start von RapidMiner Templates zu verschiedenen Themengebieten ausgewählt werden. In der Design-Perspektive ist diese Auswahl durch Anklicken des Ordners "Templates" im aktuellen Verzeichnis auch möglich:

Ein Template ist eine Analyse-Prozess-Vorlage zu einem bestimmten Themengebiet, z.B. der Predictive Maintenance, inkl. Erläuterungen zum Aufbau des Prozesses. Wir verwenden das Template zur Predictive Maintenance um unsere Vorhersage mittels des Entscheidungsbaum-Modells mit der des im Template verwendeten k-Nearest Neighbor-Modells zu vergleichen, siehe den Abschnitt 6-4 Vorhersage.

6 Der Datenanalyse-Prozess in RapidMiner

Die Schritte 2 bis 5 der Datenanalyse werden nun am Beispiel des Automobildatensatzes mit RapidMiner durchgeführt.

Der Prozessverlauf ist in der Abbildung zu sehen und beinhaltet verschiedene Schritte: Einlesen und Speichern der Daten (lila-markiert), Bearbeitung der Daten (rosa-markiert), die Analyse der Trainingsdaten und die Vorhersage mit Hilfe des erstellten Entscheidungsbaum-Modells (grün-markiert). Dieser Prozess wird unter dem Namen "demo2_predmaint_1" unter dem lokalen Verzeichhnis im processes-Ordner abgespeichert.

Der Datenanalyse-Prozess wird mit Hilfe der Operatoren "Read Excel" (Daten aus Excel einlesen), "Set Role" (Rolle festlegen), "Decision Tree" (Klassifikationsmodell erstellen), "Apply Model" (Modell anwenden) zusammengebaut.

6-1 Datenvorbereitung

Schritt 1 im Zyklus der Datenanalyse ist die Datenvorbereitung. Hier werden die Daten aus Excel eingelesen und die Rollen der einzelnen Datenspalten werden festgelegt.

Der Datensatz wird eingelesen (Operator "Read Excel") und im lokalen Verzeichnis unter dem Ordner data gespeichert (Operator "Store"). Die Variable Ausfall wird als Zielvariable festgelegt (Operator "Set Role") und die zu verwendenden Merkmale werden festgelegt (Operator "Select Attributes").

Der abgebildetet Teilprozess liefert beim Durchlaufen die folgende Ausgabe (Result-Ansicht, View), dabei ist die Rolle von "Ausfall" auf den Vorhersage-/Zielwert gesetzt worden (Set Role-Operator) und erscheint grün hinterlegt in der Anzeige. Weiterhin speichert der Store-Operator den Datensatz unter dem lokalen Verzeichhnis im data-Ordner mit Namen "Automobildaten_Training":

Die Parameter des Read Excel-Operators enthalten die Pfad-Auswahl und die Auswahl des Excel-Blattes, das unter der im Pfad hinterlegten Datei eingelesen werden soll:

Die Einlese-Hilfe (Import Configuration Wizard) liefert in mehreren Schritten eine Anleitung um die Excel-Daten einzulesen inkl. einer Formatierung der Variablen-Typen und einer Vor-Anzeige des Datensatzes:

Einlese-Hilfe: Select Cell	Einlese-Hilfe: Formatierung

6-2 Modell erstellen

Der Beispieldatensatz ("exa"-Ausgangs-Port des Operators), der über den Operator "Select Attributes" erstellt wurde, wird nun als Trainingsdatensatz dem Decision Tree-Operator übergeben ("tra"-Eingangs-Port des Operators). Der Decision Tree-Operator erstellt den Entscheidungsbaum mittels des Trainingsdatensatzes und anhand festgelegter Parameter (siehe unten), dieser wird letztlich dem Ergebnis-Port des Prozesses ("res"-Port) übergeben, sowie auch die verwendeten Trainingsdaten über den Example ("exa")-Ausgangs-Port.

Der abgebildetet Teilprozess liefert beim Durchlaufen die folgende Ausgabe (Result-Ansicht, View), also den anhand der Trainingsdaten erstellten Entscheidungsbaum:

Die Parameter des Decision Tree-Operators enthalten die Modellparameter anhand derer der Entscheidungsbaum erstellt wird, z.B.:

• das Kriterium zur Erstellung des Baums, hier: das Entropie-Kriterium (information-gain),
• die maximale Tiefe des Baums, maximal depth-Parameter, hier: -1, d.h. es liegt keine maximale Grenze vor
• die minimale Anzahl an Beobachtungen in einem Blatt: minimal leaf size-Parameter oder
• die minimale Anzahl an Beobachtungen, die in einem Knoten mindestens vorliegen müssen, um einen weitere Aufteilung zu erlauben: minimal size for split-Parameter

Wann kommt es nun zu einem Ausfall?

Wenn im letzten rechteckigen Block "Ja" steht, dann führt der Pfad/die Merkmalskombination zu einem Ausfall andernfalls, d.h. bei "Nein", kommt es bei durchlaufener Merkmalskombination zu keinem Ausfall.

Je höher des Merkmal im Baum steht, d.h. je weiter oben dessen Position ist, desto mehr Einfluss hat es auf die Vorhersage eines Ausfalls. In unserem Baum hat die Einlasslufttemperatur den höchsten Einfluss. An der Höhe der rot/blauen Balken in den Blättern erkennt man, wie viele Beobachtungen des Trainingsdatensatzes diesem Blatt zugeordnet werden. Eine genaue Angabe der Anzahl der zugeordneten Beobachtungen erfolgt in RapidMiner durch Klicken auf das jeweilige Blatt.

Eine alternative Darstellung des Entscheidungsbaum-Modells ist als Textform gegeben, einige Werkzeuge zur Predictive Maintenance wie die Programmiersprachen R geben diese Darstellung standardmäßig aus. Dort sind auch direkt die oben erwähnten Anzahlen der zugeordneten Beobachtungen im jeweiligen Ast angegeben.

Durch die Auflistung als erstes Merkmal erkennt man auch hier sofort den hohen Einfluss des Merkmals Einlasslufttemperatur.

6-3 Modell validieren

Uns interessiert, wie sicher das Vorhersagemodell den Ausfall eines Motors vorhersagt. Anhand der Kennzahlen zum Testfehler lässt sich dies beantworten:
Liegen die Kennzahlen in einem vorher festgelegten, akzeptablen Bereich? Wenn ja, dann ist das Modell gut, d.h. wir können uns auf die Aussagen und Vorhersagen durch das Modell verlassen.

Der Validierungs-Prozess - Der erweiterte Datenanalyse-Prozess in RapidMiner

Der zur Erstellung des Entscheidungsbaums verwendete RapidMiner-Prozess wird nun erweitert, um zusätzlich die zur Bewertung der Güte des Vorhersagemodells benötigten Kennzahlen zum Testfehler zu bestimmen.

Die Schritte "Einlesen und Speichern der Daten" (lila-markiert) und "Bearbeitung der Daten" (rosa-markiert) ändern sich nicht, einzig der Operator "Decision Tree" des Datenanalyse-Prozesses wird auf oberster Ebene des Prozesses durch den "Cross Validation"-Operator (gelb-markiert) ersetzt.

Der Decision Tree-Operator wird in den Unterprozess des Cross Validation-Operators, genauer gesagt in dessen Trainingsphase, verlagert. Das so erstellte Modell, der Entscheidungsbaum des entsprechenden Durchlaufs der Kreuzvalidierung, wird in der folgenden Testphase des Cross Validation-Operators im Apply Model-Operator zur Vorhersage verwendet und danach werden mit dem Performance-Operator die Kennzahlen zum Testfehler des entsprechenden Durchlaufs der Kreuzvalidierung ermittelt. Nach 10 Durchläufen werden die durchschnittlichen Kennzahlwerte des Testfehlers bestimmt.

Die Parameter des Cross Validation-Operators enthalten die Modellparameter anhand derer die Kreuzvalidierung durchführt, z.B.:

• die Anzahl der Teildatensätze, die verwendet werden, d.h. die Anzahl der Durchläufe: number of folds, hier: 10, oder
• die Auswahl, ob eine leave-one-out-Methode angewandt werden soll, d.h. ob im Trainingsdatensatz immer eine Beobachtung, zur späteren Validierung dieser Beobachtung anhand ihres vorhergesagten Wertes, ausgenommen werden soll. Dann entspricht die Anzahl der Teildatensätze bzw. der Durchläufe der Kreuzvalidierung der Anzahl aller Beobachtungen im Trainingsdatensatz, hier: 140.

Beurteilung des Vorhersagemodells anhand der Kennzahlen

Der abgebildetet Teilprozess liefert beim Durchlaufen die folgende Ausgabe (Result-Ansicht, View), also die Kennzahlen zur Validierung des Modells:

Wie gut der Entscheidungsbaum zur Vorhersage eines Ausfalls geeignet ist, können wir nun anhand der vier ermittelten Kennzahlen zum Testfehler beurteilen:

• Accuracy = 65.71%
• Recall (True Positive Rate) TPR = 69.17%
• Precision = 73.83%
• AUC = 69.6%

Wie in Schritt 4: Datenanalyse des Predictive Maintenance Prozesses beschrieben, kann ein Modell als "gut" bewertet werden, wenn die Kennzahlen nahe an 100% liegen. Was genau "nahe" heißt, hängt von der Einschätzung des Experten ab, d.h. welche Abweichungen er noch als in Ordnung gelten lässt. Unsere Kennzahlen liegen je nach Auswahl in einem moderaten bis guten (Precision) Bereich und können mit Vorbehalt zur Vorhersage eines Ausfalls verwendet werden.

Des Weiteren können die hier ermittelten Kennzahlen auch zur Auswahl eines Vorhersagemodells aus mehreren zur Verfügung stehenden Modellen herangezogen werden. Dabei sollte neben den Kennzahlen auch die Verständlichkeit und intuitive Interpretierbarkeit sowie die praktische Anwendbarkeit des Modells eine Rolle bei der Auswahl des Vorhersagemodells spielen.

6-4 Modell verwenden

Der Beispieldatensatz ("exa"-Ausgangs-Port des Operators), der über den Operator "Select Attributes" erstellt wurde, wird nun als Testdatensatz dem Apply Model-Operator als ungelabelter Datensatz, d.h. für die Zielvariable "Ausfall" liegt keine Beobachtung vor, übergeben ("unl"-Eingangs-Port des Operators). Der Decision Tree-Operator liefert den Entscheidungsbaum als Modell für die Vorhersage über den "mod"-Eingans-Port. Die gelabelten Daten, d.h. die Daten inkl. Vorhersagewert für die Variable "Ausfall" und der verwendetete Entscheidungsbaum als Modell werden an Ausgangs-Ports des Prozesses übergeben.

Der abgebildetet Teilprozess liefert beim Durchlaufen die folgende Ausgabe (Result-Ansicht, View), also die anhand der Testdaten und des Modells erstellte Vorhersage für den Ausfall (grün hinterlegt) und Konfidenzintervall zur Eintrittswahrscheinlichkeit der Vorhersagewerte Ja und Nein (gelb hinterlegt), diese Werte geben die Aufteilung des rot/blauen Balkens eines Blattes in Ausfall ja und nein im Baum wieder.:

Für die erste und dritte Merkmalskombination (Beobachtung im Testdatensatz) wird kein Ausfall vorhergesagt, für die anderen beiden aber doch. Die Eintrittswahrscheinlichkeit für keinen Ausfall liegt in den beiden Blättern, zu der die erste und dritte Merkmalskombination geführt haben, bei 96,8%. Im Blatt mit der Vorhersage Ja für den Ausfall, zu der die zweite Kombination geführt hat, liegt die Eintrittswahrscheinlichkeit für einen Ausfall bei 100%.

Vergleich mit der Vorhersage des k-Nearest Neighbor-Modells

Im RapidMiner-Template zur Predictive Maintenance wird das k-Nearest­-Neighbor-Modell (k-Nächste­-Nachbar-Modell) zur Klassifikation , d.h. zur Vorhersage eines Ausfalls, herangezogen. Dabei ist zu beachten, dass nur numerische und keine kategorisierten Variablen im Algorithmus zugelassen sind. Dies liegt an der Verwendung von Abstandmaßen als Distanz, die nur numerische Werte erlauben. D.h. die Katalysatortemperatur wird nicht bei der Modellbildung und Klassifikation berücksichtigt.

Bei Anwendung des Templates auf den Automotive-Datensatz erhalten wir folgende Gewichte für die Merkmale, je höher das Gewicht (Importance), desto mehr Einfluss hat das Merkmal auf den Ausfall:

Wie auch im Entscheidungsbaum hat die Einlasslufttemperatur den höchsten Einfluss gefolgt von der Drosselklappenstellung und bestimmten Lambdasonden.

Die Klassifikation mit dem k-Nearest­-Neighbor-Modell ergibt eine Zuordnung der neuen Beobachtungen in Ausfall Ja/Nein:

In diesem Modell tritt bei der ersten und letzten neuen Merkmals­kombination eine Ausfall ein, bei Merkmalskombination Nummer Zwei und Drei jedoch nicht.

Hinweis: Um die Katalysatortemperatur als mögliches Merkmal im Modell zu erlauben, kann diese auch numerisch gemessen werden.

YouTube-Video und weitere Predictive Maintenance-Demos

Die Erstellung und Verwendung des RapidMiner-Prozesses zur Durchführung von Schritt 4: Datenanalyse des Predictive Maintenance-Prozesses wird durch ein 5-Minuten-Video (Screencast mit zusätzlichen Erläuterungen) veranschaulicht.

Der Predictive Maintenance-Zyklus besteht neben dieser ersten Demo noch aus den folgenden elab2go-Demos:

• Demo 3: Predictive Maintenace mit R
• Demo 4: Interaktive PredMaintApp
• Demo-MAT4: Predictive Maintenance mit MATLAB
• Demo-PY4: Predictive Maintenance mit scikit-learn

Autoren, Tools und Quellen