von Steven Miller, Alec Jenab und Robert Clendenning, übersetzt durch Dirk Stahlecker

Dieser Blogbeitrag beschreibt wie sich das Long Short Term Memory (LSTM) Machine Learning Modell verwenden lässt, um Ausfälle und Rückrufe von Automobilteilen vorherzusagen. Im Besonderen zeigen wir, wie durch die Vorhersagen eines LSTM-Modells Frühindikatoren entwickelt werden können, die im Allgemeinen zu besseren Ergebnissen führen als die der existierenden manuellen Prozesse. Ingenieure und Analysten unserer Kunden adressieren dadurch Probleme schneller und Kosten für Produktreparatur, Lager etc. werden reduziert. Die vorgestellte Methode lässt sich auch auf andere Industriebranchen mit vergleichbaren Anwendungsfällen übertragen.

Ausgangslage

Im Jahr 2021 gaben Autohersteller 45,9 Milliarden US-Dollar für Gewährleistungs- und Garantieansprüche[1] aus. Ein besonderer schwerwiegender Fall eines Gewährleistungsanspruchs ist der Rückruf. Er wird ausgelöst, sobald ein Hersteller oder das deutsche Kraftfahrtbundesamt bzw. in den USA die National Highway Traffic Safety Administration feststellt, dass „ein Fahrzeugdefekt ein unangemessenes Sicherheitsrisiko darstellt oder die Mindestsicherheitsstandards nicht erfüllt“. Erfolgt ein Rückruf, dann muss ein Autohersteller die Ursachen des Defekts für den Verbraucher kostenlos beheben. Aus diesem Grund bilden Hersteller in den Bilanzen grosse Rückstellungen. Dieser Blogbeitrag erklärt, wie Autohersteller und Zulieferer maschinelles Lernen (ML) nutzen können, um Rückrufe bzw. größere Mängel vorherzusagen, Abhilfemaßnahmen schneller umzusetzen und um somit die finanziellen Auswirkungen zu reduzieren. Wir beschreiben, wie man das trainierte ML-Modell mit historischen Daten testet (engl. «backtest»), um die Zeit- und Kostenvorteile im Vergleich zum bestehenden Qualitätsprozess zu bestimmen.

Sobald ein Rückruf erfolgt oder ein schwerwiegender Defekt auftritt führen Autohersteller und Zulieferer eine Fehler-Ursachen Analyse (engl. «Root-Cause-Analysis») durch, um die Grundursachen zu identifizieren. Um mögliche Muster zu erkennen und zu analysieren werden u.a. Heuristiken und Statistiken verwendet. Sobald die Ursachen bekannt sind, werden die notwendigen Verbesserungen auf der Technik-, Design- oder Fertigungsebene implementiert. Die bisher verwendeten Methoden sind größtenteils manuell und zeitaufwändig. Mit Hilfe fortschrittlicher ML-Methoden können Kunden der Automobilindustrie vorhandene historische Daten verwenden, um damit ein ML-Modell zu trainieren. Dadurch werden für Menschen unsichtbare Muster sichtbar, die zu schwerwiegenden Produktfehlern oder Rückrufen geführt haben. Das trainierte ML-Modell wird dann benutzt, um vor Eintritt eines Defekts, Teile in der Flotte vorherzusagen, bei denen die Wahrscheinlichkeit schwerwiegender Produktfehler oder Rückrufe hoch ist. Obwohl der mit ML vorausgesagte Zeitraum des Schadenseintritts zwischen Tagen und Monaten liegen kann, können unsere Kunden schon durch eine einwöchige frühere Ankündigung erhebliche Einsparungen erzielen. Das liegt vor allem daran, dass Autohersteller und Zulieferer Teile in sehr hohen Stückzahlen produzieren und sie weltweit bereitstellen müssen.

Bevor wir auf das spezifische ML-Modell eingehen, ist in Abb. 1 die vereinfachte allgemeine Lieferkette von Automobilteilen zwischen OEMs (engl. «Original Equipment Manufacturer») und Zulieferern dargestellt. Die einzelnen Fahrzeugkomponenten werden von einem oder mehreren Zulieferern hergestellt, ggf. zu Systemen zusammengebaut (z. B. Airbags, Sicherheitsgurte, Getriebe, etc.) und an den OEM geliefert. Der OEM montiert das komplette Fahrzeug, führt die Qualitätskontrollen durch und liefert es über das Händlernetzwerke an den Verbraucher aus. Die meisten modernen Fahrzeuge bestehen typischerweise aus mehr als 10.000 Einzelkomponenten, die von global tätigen Lieferanten hergestellt werden.

Abb. 1: Vereinfachte Lieferkette von Automobilteilen

Wenn ein Verbraucher einen Neuwagen kauft, muss der Hersteller für einen bestimmten Zeitraum mindestens die gesetzliche Gewährleistung erfüllen. In der Europäischen Union gilt für Kraftfahrzeuge ein Gewährleistungszeitraum von zwei Jahren. Bei einem Defekt, bringt der Besitzer das Fahrzeug zu einem Händler und die Reparatur erfolgt im Rahmen der gesetzlichen Gewährleistung oder der zusätzlichen freiwilligen Herstellergarantie kostenlos. Beim Vertragshändler ermittelt ein Service-Techniker das Problem, führt die Reparatur durch und erstellt einem Gewährleistungsantrag bzw. Schadensbericht. Im Antrag werden das identifizierte Problem, die Ursachenanalyse und die durchgeführten Reparaturmassnahmen inkl. Reparaturkosten und Arbeitsaufwand beschrieben. Zusätzlich enthält dieses Dokument Informationen über das Fahrzeug, wie Typ, Modelljahr und Produktionsstätte.

Nach Abschluss der Reparatur reicht der Vertragshändler den Antrag zur Kostenrückerstattung beim Hersteller ein. Der Hersteller, prüft den Fall und die Daten werden für spätere Analysezwecke in einer Garantie-Datenbank gespeichert. Typischerweise haben Autohersteller Millionen von historischen Garantieansprüchen gesammelt, die bis in die frühen 2000er Jahre zurückreichen.

Die Gewährleistungs- oder Garantieansprüche werden beim Hersteller durch Analysten manuell geprüft, wobei statistische Ansätze, Visualisierungen und andere Methoden eingesetzt werden, um Behauptungen zu überprüfen und Trends zu identifizieren. Grundsätzlich wird die Auswertung durch Probleme mit der Datenqualität (z.B. Datenrauschen) erschwert. Eines der Hauptziele dieses manuellen Überprüfungsprozesses ist die Identifizierung neu entstehender Teiledefekte in der Flotte, die auf ein generisches Herstellungs- oder Konstruktionsproblem zurückzuführen sein könnten.

Die meisten Ansprüche lassen sich auf akzeptable Fertigungsschwankungen zurückführen. Zeichnen sich allerdings Trends ab, weil z.B. vermehrt Gewährleistungsansprüche für ein bestimmtes Teil eingereicht werden (s. Abb. 4), wird ab einem bestimmten Schwellwert eine eingehendere Untersuchung eingeleitet. Sobald die Grundursachen durch Zusammenarbeit zwischen Analysten und Ingenieuren des Autoherstellers und des Zulieferers identifiziert sind, werden Änderungen im Design bzw. im Herstellungsprozess vorgenommen, um weitere Defekte und Gewährleistungsansprüche zu vermeiden.

Abb. 2: Bestehender Gewährleistungs- bzw. Garantieprozess

Der verbesserte und ML unterstützte Gewährleistungsprozess

Wir schlagen Autoherstellern und Zulieferern vor, die bestehenden Gewährleistungs- und Garantieprozesse (s. Abb. 2) durch maschinelles Lernen (ML) zu ergänzen. Wie in Abb. 3 dargestellt werden dazu aggregierte und anonymisierte historische Daten aus der Garantiedatenbank benutzt, um ein ML-Modell zu trainieren. Das trainierte Modell, wird dann verwendet um Warnungen auszulösen, falls für Teile in der Fahrzeugflotte eine hohe Ausfallwahrscheinlichkeit bzw. ein Rückruf vorhergesagt wird. Maschinelles Lernen erlaubt Autoherstellern und Zulieferern einen vorausschauenden Indikator zu entwickeln, der es ermöglicht potentielle Teileprobleme frühzeitig zu erkennen und Gegenmassnahmen zu priorisieren und einzuleiten.

Abb. 3: ML unterstützter und verbesserter Garantieprozess

Im Folgenden wird die verwendete ML-Methode und die Integration in den bestehenden Prozess beschrieben.

Verwendung der Garantiedatenbank als Startpunkt

Um relevante Daten für das Training des ML-Modells zu gewinnen, schlagen wir vor die bestehenden strukturierten Datenbanken zu verwenden, in denen die Autohersteller und Zulieferer Informationen über die Gewährleistungs- und Garantieansprüche verwalten. Diese Datenbanken haben eine seit Jahren stabile Datenstruktur und enthalten Millionen von individuellen Fällen.

In diesen Datenbanken werden hauptsächlich drei Arten von Informationen verwaltet: Teileinformationen, Fahrzeuginformationen und freier Text.  Zu den Teileinformationen gehören Informationen über die Art des defekten Teils, die Kosten für den Austausch, die Teilenummer und Version und andere Metadaten die im Zusammenhang zum defekten Teil stehen. Die Fahrzeuginformationen geben Auskunft über die Kilometerleistung zum Zeitpunkt des Defekts und wann und wo das Fahrzeug hergestellt wurde. Schließlich beinhaltet die freie Textbeschreibung Informationen über die durchgeführte Reparatur der Servicewerkstatt.

Um durch ein trainiertes ML-Modell gute Vorhersagen zu erhalten, ist neben der Wahl der passenden ML-Architektur, die Qualität der Trainingsdaten wichtig. Die Trainingsdaten müssen folgende drei Bedingungen erfüllen:  Als erstes müssen die historischen Daten den zeitlichen Versagensverlauf (die «Sequenz») des spezifischen Teils abbilden. Meistens kündigt sich ein Teileversagen Schritt für Schritt an. Zweitens müssen die historischen Daten Informationen liefern, um die Sequenz mit einem «Label» als «defekt» oder «nicht defekt» zu klassifizieren. Und drittens benötigen wir voneinander unabhängige Variablen oder Merkmale (engl. «Features»), die mit der Zielvariablen (Defekt / nicht Defekt) korrelieren. Im nächsten Abschnitt werden diese drei grundsätzlichen Anforderungen detailliert besprochen.

Vorbereitung der ML-Trainingsdaten aus Garantiedaten

Wie werden nun die Trainingsdatensätze aus den vorhandenen Daten aufgebaut, sodass der sequentielle Charakter bzw. der zeitliche Ablauf eines schwerwiegenden Produktfehlers oder Rückrufs in der Fahrzeugflotte abgebildet wird? Datensätze eines einzelnen Garantiefalls reichen dazu nicht aus. Um dies zu erreichen werden die Daten verschiedener Schadensfälle mit gleicher Teilenummer und Version zu einer zeitlichen Ereignissequenz aufgebaut. Als Ergebnis entsteht ein Datensatz, der die gewünschte zeitliche Sequenz von Ereignissen eines bestimmten generischen Teils über verschiedene Schadensereignisse hinweg enthält.

 Abb. 4: Entwicklung der wöchentlich eingereichten Garantieanträge

Um sicherzustellen, dass alle Datenelemente im Trainingsdatensatz auf die gleiche Weise aufgebaut werden, sollten Kunden die unabhängigen Variablen ebenfalls nach Teilenummer und Version aggregieren. Nutzen lassen sich z.B. der Durchschnitt der Arbeitskosten, Teilekosten, gefahrene Kilometer oder Garantieantragsvolumen pro Woche, jeweils in Abhängigkeit von Teilenummer und Version. Damit haben wir teilindexierte Zeitreihendatensätze für das spätere ML-Training aufgebaut.

Als Nächstes werden «Labels» aus den Rohdaten extrahiert um die vorbereiteten Datensätze als «nicht defekt» oder z.B. durch Fehlercodes als «defekt» zu markieren. Möglicherweise ist in der Garantiedatenbank des Kunden bereits ein Attribut mit Fehlercodes (engl. «Diagnostic Trouble Codes – DTCs») vorhanden. Ist dies nicht der Fall, dann müssen die Codes aus den freien Textbeschreibungen durch simple Suchtechniken extrahiert werden und durch Verknüpfungspunkte wie z.B. über die Fahrzeugidentifizierungsnummer in das Trainingsdatenset integriert werden.

Anschliessend werden die Trainingsdatensätze normalisiert und bereinigt. Offensichtlich fehlerhafte Daten (z. B. unsinniger Fahrzeugkilometerstand) und Daten bei denen es Probleme mit der Datenerfassung gab werden entfernt. Zum Training verwenden Kunden normalerweise die Garantiedaten von 52 Wochen eines Teils. Dazu werden die Datensätze ggf. auf 52 Wochen gekürzt (engl. «slicing») und Datensätze die weniger als 52 Wochen abdecken werden aufgefüllt (engl. «pre-padding»). Zusätzlich müssen vor dem Modelltraining Klassenungleichgewichte in den Trainingsdaten behoben werden, da Teile mit schwerwiegenden Produktdefekten und Rückrufaktionen selten vorkommen. Dazu werden einerseits Daten von häufigen Klassen (z.B. in der Klasse «nicht defekt») entfernt und andererseits werden Daten der seltenen Defektklassen durch «synthetisches Oversampling» hinzugefügt. Eine solche Methode ist die Duplizierung von zufällig ausgesuchte Datensätzen der seltenen Klassen.

Merkmale ausschliessen, die nicht mit Defekten und Rückrufen korrelieren

Als letzten Schritt vor dem Modelltraining, müssen Kunden Merkmale aus den Trainingsdaten entfernen, die nicht mit Defekten und Rückrufen (= Signal) korrelieren. Durch diese Massnahme wird das Ziel verfolgt, ein angemessenes Signal / Rausch Verhältnis in den Daten herzustellen und dabei nur Informationen zu verwenden, die zu einem gut «generalisierten» ML-Modell führen. In der Regel sind dazu enge Abstimmungen zwischen Datenwissenschaftlern und Fachexperten notwendig, um die passenden Merkmale zu berücksichtigen, die sowohl mit schwerwiegenden Defekten bzw. Rückrufen korrelieren und die praktikabel sind.

Beispielsweise ist die Fahrzeugfarbe leicht verfügbar, allerdings korreliert das «Feature» Farbe in der Regel nicht mit schwerwiegenden Defekten oder Rückrufen und sollte deshalb aus dem Datensatz ausgeschlossen werden. Umgekehrt ist der Kilometerstand der Fahrzeuge ein viel besserer Indikator. Fahrzeuge mit niedriger Laufleistung haben in der Regel weniger Probleme als Fahrzeuge mit höherer Laufleistung. Wenn also beim Eintritt eines Defekts die durchschnittliche Laufleistung für eine bestimmte Teilenummer und Version niedrig ist, ist die Wahrscheinlichkeit größer, dass ein generisches Problem vorliegt (s. Abb. 5). Im Allgemeinen möchten Kunden, dass die Variablen, die zum Trainieren des Modells verwendet werden, von Fachexperten sorgfältig ausgewählt werden. Dadurch wird sichergestellt, dass das Modell relevante Variablen (z. B. Kilometerstand) berücksichtigt, die sich auf die Vorhersage von Defekten auswirken, und irrelevante Variablen (z. B. Farbe) ausschließt. Konzeptionell gesehen korrelieren Merkmale wie z.B. Diagnosezeitaufwand, Ersatzteilkosten, Kilometerstand des Fahrzeugs und Anzahl der Reklamationen im Laufe der Zeit (s. Abb. 4) gut mit schwerwiegenden Defekten oder Rückrufen.

Abb. 5 Struktur der Trainingsdaten

Wahl des Long Short Term Memory Machine (LSTM) Machine Learning Modells

Es gibt verschiedene nutzbare ML-Methoden bzw. Algorithmen, um das beschriebene Problem zu adressieren. Beispielsweise: «Random Alerting», auf Human in the Loop (HITL) -Regeln basierende Methoden, Single Perception und XGBoost. Wir empfehlen unseren Kunden, das Long Short-Term Memory (LSTM) ML-Modell zu verwenden. LSTM-Modelle sind so ausgelegt, dass sie bei komplexen zeitlichen Sequenzen gute Vorhersagen liefern. Sie eignen sich ebenfalls gut für die Klassifizierung von Maschinenausfällen anhand von Sensorprotokollen und für Sprachübersetzungsaufgaben mit Eingabesätzen variabler Länge. Eine detaillierte Beschreibung des LSTM-Modells finden Sie in folgendem Blogbeitrag.

Wichtig ist, dass das LSTM zur Inferenzzeit sowohl die Klassenvorhersage nicht defekt oder defekt (bzw. Fehlercode) und die zugehörige Wahrscheinlichkeit bestimmt. Die berechnete Wahrscheinlichkeit sollte in Gesprächen mit den internen Stakeholdern diskutiert werden, um Erfahrung und Vertrauen in die Prognose aufzubauen. Das Data-Science-Team und die internen Business Stakeholder der Kunden müssen auch festlegen, welche Massnahmen bei welchen Wahrscheinlichkeitsschwellwerten in Kombination mit der Anzahl der Garantieschäden oder Reparaturkosten pro Zeitperiode ergriffen werden.

Leistungsbewertung des LSTM Models in der Praxis

Um die Güte des trainierten ML-Modells quantitativ zu bewerten und um zu zeigen, wie das Modell in der Vergangenheit abgeschnitten hätte, werden Test mit historischen Daten (engl. «Backtests») durchgeführt. Dazu sollten die Daten von historischen Garantieansprüchen einen Zeitraum von 5 Jahren abdecken. Wichtig ist, dass die Testdatensätze (engl. «hold-out sets») nur zur Inferenz aber nicht zum Training verwendet werden dürfen. Im Testdatensatz teilen wir die Daten in wochenweise Abschnitte auf. Um die Güte der Ergebnisse im Vergleich zum klassischen Prozess zu bestimmen, berechnen wir die Zeitdifferenz zwischen dem Zeitpunkt, an dem unser ML-Modell eine Warnung ausgelöst hat, und dem Zeitpunkt, an dem das Analystenteam durch herkömmliche heuristische Garantiemethoden auf das Teileproblem aufmerksam wurde.

Aufbau der Lösung mit AWS-Technologie und einer AWS-Referenzarchitektur

Im folgendem beschreiben wir, wie Kunden diese ML-Lösung mithilfe von AWS-Technologie und einer AWS-Referenzarchitektur implementieren können.

Abb. 6: AWS-Referenzarchitektur

Die in Abb. 6 vorgestellte AWS-Referenzarchitektur besteht aus sechs Hauptkomponenten:

1. Datenextraktion, Transformation und Ladeprozess ( «ETL»): Regelmäßiges Erfassen von KFZ-Garantieansprüchen (Rohdaten) aus Automobilportalen bzw. deren Datenbanken durch Skripte, die auf Amazon EC2 Instanzen ausgeführt werden. Es folgt ein mit AWS Glue implementierter und skalierbarer ETL-Prozess zum Extrahieren, Transformieren und Laden bzw. speichern der Daten in Amazon S3.
2. Data Warehouse: Das zentrale Data Warehouse basiert auf Amazon Redshift. Es enthält aufbereitete Daten sowie Tabellen für spezifische Dashboards, die sich einfach auf ein ganzes Unternehmen oder eine Organisationseinheit übertragen bzw. skalieren lassen.
3. Data Science: Amazon SageMaker Studio ist die AWS ML-Entwicklungsumgebung (IDE) und bietet Datenwissenschaftlern und Analysten umfassende Werkzeuge für integrierte MLOps-Prozesse von der Datenvorbereitung bis hin zum Erstellen, Trainieren und Bereitstellen Ihrer ML-Modelle in den Betrieb.
4. Datennutzung: Analysten und Geschäftsbenutzer erhalten spezifische und umsetzbare Empfehlungen durch Amazon QuickSight
5. Betrieb: Der periodische Dateneinlesevorgang (engl. «Ingestion») und die Durchführung der ML-Inferenz und nachgelagerten Auswerteprozesse werden durch Amazon EventBridge, ausgelöst. Der Anwendungscode wird in AWS CodeCommit gespeichert und Amazon CloudWatch wird für die Protokollierung und Überwachung verwendet.
6. Anwender: Datenwissenschaftler und Automotive Analysten entwickeln iterativ ML-Modelle mit Amazon SageMaker Studio und überprüfen Ergebnisse die in Amazon QuickSight Dashboards dargestellt werden.

Diese vorgestellte AWS-Lösung hilft Kunde aus der Automobilindustrie eine eigene spezifisch angepasste Lösung mit AWS-Technologie aufzubauen und zu betreiben. Sie ermöglicht, Produktfehler und Rückrufe in der Flotte früh zu erkennen und die damit verbundenen Kosten zu senken. Der schlanke ETL-Prozess erfasst fortlaufend und konsistent Garantiedaten und bereitet sie für die Nutzung und Auswertung durch maschinelles Lernen vor. In der zentralen Amazon SageMaker Studio Entwicklungsumgebung, trainieren Datenwissenschaftler und Analysten gemeinsam LSTM-Modelle, transferieren sie in die Produktion, überwachen die durchgeführten Inferenzen und erstellen Ad-hoc-Berichte und Analysen. Und schließlich bietet Amazon Redshift eine skalierbare OLAP-Datenbank (engl. «Online Analytical Processing») für benutzerorientierte Dashboards und Berichte.

Fazit

Die in diesem Blog vorgestellte AWS-Lösung erlaubt es Autoherstellern und Zulieferern zügig eine spezifisch eigene ML basierte Lösung zu entwickeln, um Kosten zu reduzieren, die durch Produktfehler und Rückrufe verursacht werden. Speziell lassen sich durch die ML basierten Prognosen Abhilfemaßnahmen im Zusammenhang mit schwerwiegenden Produktfehlern und Rückrufen vorausschauender und schneller implementieren als durch die bestehenden Prozesse. Dadurch werden die Arbeits- und Reparaturkosten und fehlerhafte Lagerbestände reduziert und mögliche Marken- und Reputationsschäden werden vermieden.

Bitte kontaktieren Sie uns durch dieses Formular, falls Sie oder Ihr Team den beschriebenen Geschäftsfall, die vorgestellte AWS-Anleitung und die technische Architektur ausführlicher besprechen möchten. Weitere AWS Lösungen und Architekturen für die Automobilindustrie finden sie hier: AWS-Lösungsportfolio.

[1] Obwohl juristisch nicht korrekt, wird der Begriff Gewährleistung und Garantie in diesem Blogbeitrag synonym verwendet.

Über die Autoren

	Steven Miller Steve ist Principal Consultant bei AWS Professional Services. Er ist leidenschaftlicher Data-Science Ingenieur in der Automobil- und Motorsportbranche und arbeitet Seite an Seite mit Kunden, um neue wegweisende Lösungen zu entwickeln.
	Alec Jenab Alec ist Ingenieur für maschinelles Lernen (ML) bei AWS Professional Services. Er entwickelt ML-Lösungen für Unternehmenskunden und bringt sie in grossem Massstab in die Produktion. Alec ist begeistert davon, innovative Lösungen auf den Markt zu bringen.  Dies gilt insbesondere für Bereiche, in denen maschinelles Lernen das Endnutzererlebnis erheblich verbessern kann. Außerhalb der Arbeit spielt er gerne Basketball, fährt Snowboard und entdeckt versteckte Juwelen in San Francisco.
	Robert Clendenning Rob ist Senior Practice Manager in der AWS Industries Global Automotive Practice. Seit über 20 Jahren arbeitet er mit Unternehmen zusammen, um innovative Lösungen in den Bereichen Produktplanung, -entwicklung und Produktion, Anreizanalyse, autonomes Fahren und Assistenz, IoT, sowie Garantieanalyse zu entwickeln.