-
HINTERGRUND DER ERFINDUNG
-
1. Gebiet der Erfindung
-
Diese Erfindung bezieht sich auf ein Verfahren zum Überprüfen, Bestätigen und Verbessern von Fahrzeugfehlermodellen, das das Ausführen einer Was-wäre-wenn-Analyse unter Verwendung von Experten zum Identifizieren erheblicher Fehlermodi und -symptome unter Verwendung von Feldfehlerdaten, das Lernen von Simulationsparametern aus den Feldfehlerdaten, das Simulieren von Fehlern unter Verwendung der gelernten Parameter, das Erzeugen von Simulationen unter Verwendung der Was-wäre-wenn-Analyse und des Fehlermodells zusammen mit einem Diagnoselogikprogramm [engl.: diagnostic reasoner] zum Bereitstellen geschätzter Fehler und das Vergleichen der geschätzten Fehler mit den simulierten Fehlern für eine Nutzenanalyse enthält.
-
2. Diskussion des verwandten Gebiets
-
Moderne Fahrzeuge sind komplexe elektrische und mechanische Systeme, die viele Komponenten, Vorrichtungen, Module, Teilsysteme usw. nutzen, die unter Verwendung anspruchsvoller Algorithmen und Datenbusse elektrische Informationen zwischen und untereinander übergeben. Wie bei allem sind diese Typen von Vorrichtungen und Algorithmen anfällig für Defekte, Störungen und Fehler, die den Betrieb des Fahrzeugs beeinflussen. Wenn solche Defekte und Fehler auftreten, gibt die betroffene Vorrichtung oder Komponente häufig einen Fehlercode wie etwa einen Diagnosefehlercode (DTC) aus, der von einem oder von mehreren Systemcontrollern empfangen wird, der/die den Fehler oder einen zusätzlichen Fehler bei einer integrierten Komponente identifiziert/identifizieren. Diese DTCs können durch Servicetechniker und -ingenieure analysiert werden, um Probleme zu identifizieren und/oder Systemkorrekturen und -aktualisierungen vorzunehmen. Ausgehend von der Komplexität von Fahrzeugsystemen könnten allerdings viele DTCs und andere Signale aus vielen verschiedenen Gründen ausgegeben werden, was die Fehlerbehebung besonders schwierig machen könnte.
-
Fahrzeugfehlermodelle, die die Fehler, die in einem Fahrzeug auftreten könnten, und die für diese Fehler verfügbaren Abhilfemaßnahmen definieren, werden in der Industrie zunehmend verbreitet. Eine der einfachsten Darstellungen eines Fehlermodells ist eine zweidimensionale Matrix, bei der die Zeilen der Matrix die Fehlermodi, die in dem Fahrzeug auftreten könnten, erfassen, und die Spalten der Matrix die Symptome identifizieren, die das Fahrzeug für die Fehlermodi erfahren kann. Das Fehlermodell erfasst die kausalen Abhängigkeiten zwischen den Fehlermodi und -symptomen. Die verschiedenen Symptome könnten Informationen, die während des Betriebs des Fahrzeugs aufgezeichnet werden, oder Informationen, die auftreten, während das Fahrzeug gewartet wird, sein. Somit kann Kundendienstpersonal durch Anbringen eines Indikators bei dem Schnitt zwischen einem bestimmten Fehlermodus und den Symptomen, die das Fahrzeug für diese Fehlermodi in dem Fehlermodell erfahren würde, auf der Grundlage der Symptome, die auftreten, identifizieren, welcher Wartungsbetrieb ausgeführt werden muss, um einen bestimmten Fehler zu beheben.
-
In Anhängigkeit von dem Umfang des Fehlermodells kann die Matrix sehr groß sein und aktualisiert und verfeinert werden, sodass sie schließlich für jedes mögliche Symptom spezifische Reparaturbetriebe identifizieren kann. Ferner können für verschiedene Ebenen des Fahrzeugs verschiedene Fehlermodelle bereitgestellt werden, wobei solche Fehlermodelle für spezifische Fahrzeugteilsysteme bereitgestellt werden können, Fehlermodelle für spezifische Fahrzeugmarken, spezifische Fahrzeughersteller, ein spezifisches Fahrzeugmodell usw. bereitgestellt werden können.
-
Es ist erwünscht, Fehlermodelle genau zu besetzen, sodass sie keine redundanten Informationen nutzen, die Fehler genau identifizieren und die Symptome in Bezug auf diese Fehler genau identifizieren. Mit anderen Worten, es ist erwünscht, eine Methodik zum Überprüfen und Bestätigen integrierter Fahrzeugfunktionsmanagement-Fehlermodelle (IVHM-Fehlermodelle von integrated vehicle health management fault models) durch eine systematische Methodik, die mit Feldfehlerdaten verknüpft ist, die von vielen Fahrzeugen erhoben werden, zu haben.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
In Übereinstimmung mit den Lehren der vorliegenden Erfindung wird ein Verfahren zum Überprüfen, Bestätigen und Verbessern eines Fahrzeugfehlermodells offenbart. Das Verfahren enthält das Bereitstellen eines Anfangsfehlermodells, das kausale Abhängigkeiten zwischen in einem Fahrzeug auftretenden Symptomen und Fehlermodi in dem Fahrzeug für diese Symptome identifiziert und Feldfehlerdaten bereitstellt, die Fahrzeugsymptome und Fehler für viele Fahrzeuge enthalten. Das Verfahren führt unter Verwendung der Feldfehlerdaten eine Was-wäre-wenn-Analyse aus, die das Verwenden von Gegenstandsexpertenkenntnis (SME-Kenntnis) zum Bestimmen der wichtigsten Fehlermodi und der wichtigsten Symptome enthält. Außerdem enthält das Verfahren das Lernen von Simulationsparametern aus den Feldfehlerdaten und das Simulieren von Fehlern unter Verwendung der gelernten Simulationsparameter. Ferner enthält das Verfahren das Bestätigen des Fehlermodells auf der Grundlage der wichtigsten Fehlermodi und der wichtigsten Symptome aus der Was-wäre-wenn-Analyse und aus den durch die Simulation identifizierten Fehlern. Ferner nutzt das Verfahren ein Diagnoselogikprogramm zum Erzeugen geschätzter Fehler unter Verwendung des Fehlermodells und der in den Was-wäre-wenn-Szenarien und in den Simulationen vorhandenen Symptome. Daraufhin vergleicht das Verfahren die geschätzten Fehler mit den simulierten Fehlern, um die Wahr-Detektierungs- und Fehleralarmraten [fault alarm rates] zu bestimmen, und führt daraufhin durch in Beziehung setzen der Wahr-Detektierungs- und Fehlalarmraten mit den Reparaturkosten wie etwa Arbeitskosten, anderen Arbeitszeitkosten, Gesamtkosten usw. eine Nutzenanalyse aus.
-
Zusätzliche Merkmale der vorliegenden Erfindung gehen aus der folgenden Beschreibung und aus den angefügten Ansprüchen in Verbindung mit den beigefügten Zeichnungen hervor.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
1 ist ein Blockschaltplan eines Systems zum Überprüfen, Bestätigen und Verbessern eines Fahrzeugfehlermodells;
-
2 ist ein Ablaufplan, der ein Verfahren zum Überprüfen, Bestätigen und Verbessern eines Fahrzeugfehlermodells zeigt;
-
3 ist eine Darstellung von Feldfehlerdaten, die von vielen Fahrzeugen für den in 1 gezeigten Prozess erhoben wurden; und
-
4 ist ein Ablaufplan, der einen Prozess zum Analysieren von Szenarien unter Verwendung eines Fehlermodells und eines Diagnoselogikprogramms in dem in 1 gezeigten Verfahren zeigt.
-
AUSFÜHRLICHE BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
-
Die folgende Diskussion der Ausführungsformen der Erfindung, die auf ein Verfahren zum Überprüfen, Bestätigen und Verbessern eines Fehlermodells gerichtet ist, ist dem Wesen nach lediglich beispielhaft und soll die Erfindung oder ihre Anwendungen oder Verwendungen in keiner Weise einschränken. Zum Beispiel besitzt die vorliegende Erfindung besondere Anwendung für Fahrzeugfehlermodelle. Allerdings besitzt das Verfahren der Erfindung andere Anwendungen für andere Branchen wie etwa für die Fehlermodellbestätigung in der Luft- und Raumfahrtindustrie.
-
1 ist ein Blockschaltplan eines Systems 40, das die notwendige Hardware für ein vorgeschlagenes Verfahren zum Überprüfen, Bestätigen und Verbessern eines Fahrzeugfehlermodells für ein bestimmtes Fahrzeug und/oder Fahrzeugsystem bereitstellt, wobei das vorgeschlagene Verfahren zum Überprüfen, Bestätigen und Verbessern eines Fehlermodells fahrzeugextern ausgeführt wird. Das System 40 enthält einen Computer 42, der irgendeinen geeigneten Prozessor darstellen soll, der Informationen verarbeitet, die von verschiedenen Quellen 44, die Feldfehlerdaten bereitstellen, empfangen werden. Die Quellen 44 können irgendeine für die hier beschriebenen Zwecke geeignete Quelle wie etwa Garantieberichte, Kundendienstwerkstattdaten, Telemetriedaten usw. sein. Die von dem Computer 42 empfangenen Informationen und Daten werden in dem Computer 42 in einem Speicher 46 gespeichert, auf den durch SMEs zugegriffen werden kann. Der Computer 42 kann in Übereinstimmung mit der vorliegenden Diskussion aus den Feldfehlerdaten Simulationen ausführen und Simulationsparameter lernen. Der Speicher 46 speichert die Fehlermodelle, Was-wäre-wenn-Szenarien, Monte-Carlo-Simulationen und Feldfehlerdaten in Übereinstimmung mit der vorliegenden Diskussion. Außerdem enthält der Computer 42 einen Prozessor 50, der einen Komparator 52, ein Parameterlernprogramm [engl.: Learner] 34 und ein Diagnoselogikprogramm 56 für Zwecke, die auf der Grundlage der folgenden Diskussion leicht festzustellen sind, enthält. Der Computer 42 stellt ein Hilfsmittel bereit, das ermöglicht, dass der SME die Daten und Informationen in einem geeigneten Format wie etwa Berichte und Fehlermodelle, die auf einer Anzeigevorrichtung 48 angezeigt werden können, analysiert.
-
2 ist ein Ablaufplan 10, der ein vorgeschlagenes Verfahren zum Überprüfen, Bestätigen und Verbessern eines Fehlermodells zeigt. Zu Beginn des Prozesses ist für ein bestimmtes Fahrzeug oder System ein Fehlermodell erzeugt worden, wobei dieses Fehlermodell analysiert wird, um bestätigt und verbessert zu werden. Hierfür werden aus Informationen, die im Feld und auf anderer Weise erhoben wurden, Historiendaten für verschiedene Symptome und ihre Reparaturen verwendet. Somit werden die verschiedenen Feldfehlerdaten, die im Zeitverlauf für viele Fahrzeuge erhoben werden, dazu verwendet, das gegenwärtige Fehlermodell zu beurteilen und Änderungen daran bereitzustellen, die geeigneter sind. Zum Beispiel kann durch Betrachtung verschiedener identifizierter Probleme oder Systeme und Untersuchung, welche Lösungen an diesem System vorgeschlagen wurden, bestimmt werden, welche Lösung die meiste Wirkung hatte und die zuverlässigere war, um zu verhindern, dass das Symptom erneut auftritt.
-
Ein erster Schritt des Verfahrens im Kasten 12 wird als eine ”Was-wäre-wenn-Analyse” bezeichnet, die SME-Kenntnis und Daten aus verschiedenen Datenbanken, Programmen, Berichten usw. verwendet, um die wichtigsten Fehlermodi in Ansprechen auf SME, Kosten, Häufigkeit des Auftretens, des Totalausfalls beim Betreiber [engl.: Operator walk-home] usw. zu identifizieren und die wichtigsten Symptome, d. h. Symptome, die während dieser Fehlermodi unter Beachtung des Auftretens und der Schwere dieser Symptome aufgetreten sind, zu bestimmen. Diese Analyse kann irgendeine Anzahl oberster Fehlermodi wie etwa fünfzig und irgendeine Anzahl der obersten Symptome bestimmen, wobei die Was-wäre-wenn-Analyse eine deterministische und Software-Herangehensweise zum Erzeugen der Szenarien nutzt. Wie in 3 gezeigt ist, können die Informationen und Daten in dieser Ausführungsform von Feldfehlerdaten 14 kommen, die Garantieanspruchsdaten, DTCs, Betriebsparameteridentifiziererdaten (PID-Daten) aus vielen verschiedenen Quellen wie etwa Kundendienstwerkstätten, Telematikdiensten usw. enthalten. Die PIDs identifizieren irgendeinen geeigneten Fahrzeugparameter wie etwa Spannungen, Drücke, Temperaturen, Ströme usw. Die Daten können enthalten, welche Maßnahmen für bestimmte Symptome ergriffen wurden, und die DTCs für Garantieansprüche und andere Kundendienstauftritte und ob diese Systeme wirksam waren.
-
Wenn die Feldfehlerdaten 14 und andere Informationen in dem Kasten 12 wie oben diskutiert bewertet worden sind, können im Kasten 16 Fehlersimulationen ausgeführt werden. Die Betriebe, die in dem Kasten 16 ausgeführt werden, enthalten zwei Schritte, d. h. Lernen von Parametern aus den Feldfehlerdaten 14 und Simulieren von Fehlern. Insbesondere können die Feldfehlerdaten 14 in einer probabilistischen und Software-Herangehensweise zum Lernen von Parametern für die Simulation verwendet werden, d. h. die Feldfehlerdaten 14 können z. B. verwendet werden, um eine zweidimensionale Fehlerverteilung von Hauptfehlern, die Verteilung von Hauptfehlerreparaturen in Bezug sowohl auf Meilenzahl als auch auf Dienstzeit, die durchschnittlichen Arbeitskosten, andere Arbeitszeitkosten, Teilkosten, Gesamtkosten der Komponentenreparatur usw.; Wiederholungsbesuche für dasselbe System und Mehrfachanspruchsraten; bedingte Wahrscheinlichkeiten zwischen den Fehlermodi wie etwa Arbeitscodes und Symptomen wie etwa DTCs; Fehlererscheinen- und Fehlerverschwinden-Wahrscheinlichkeiten zum Simulieren intermittierender Fehler zu lernen; und Auftrittszählwert und Schwere jedes Symptoms zu lernen.
-
Daraufhin werden die gelernten Parameter in dem zweiten Schritt verwendet, um Fehler zu simulieren. In einer nicht einschränkenden Ausführungsform werden die Fehler unter Verwendung einer Monte-Carlo-Simulation simuliert, die dem Fachmann auf dem Gebiet gut bekannt ist. Die Simulation führt in Übereinstimmung mit einer Wahrscheinlichkeitsverteilung, die aus den Feldfehlerdaten 14 gelernt wird, zufällig eine große Anzahl von Fehlern und Symptomen ein. Die Simulation kann Dauerfehler simulieren, die zweidimensionale Fehlerverteilungen nutzen, um Fehler mit realistischen Szenarien zu simulieren, und kann intermittierende Fehler simulieren, die Fehlererscheinen- und Fehlerverschwinden-Wahrscheinlichkeitsverteilungen nutzen, um Fehler auf realistische Weise während des tatsächlichen Vorfalls und später im Wartungsbereich zu simulieren. Es werden Symptomergebnisse erzeugt, die Fehlermodelle, bedingte Wahrscheinlichkeiten zwischen Fehlermodi und Symptomen nutzen, um Sätze bestandener Systemergebnisse und nicht bestandener Systemergebnisse zu erhalten.
-
Wenn die Simulationen in dem Kasten 16 ausgeführt worden sind, kann geeignetes Personal unter Verwendung des Fehlermodells und einer Diagnose, die im Kasten 18 gefolgert wird, den Was-wäre-wenn-Analysator und die Simulationsszenarien analysieren. Ein Diagnoselogikprogramm ist ein Algorithmus, der die verschiedenen Fehlermodi und -systeme betrachtet und bestimmen kann, welche Fehlermodi für die in dem Fahrzeug vorhandenen Systeme verantwortlich sind.
-
4 ist ein Ablaufplan 20, der einen Analysealgorithmus 24 enthält, der ein Fehlermodell 26 und ein Diagnoselogikprogramm 28 aufweist. Das Fehlermodell 26 ist das Fehlermodell, das durch das Verfahren entwickelt wird, um überprüft, bestätigt und verbessert zu werden, während im Zeitverlauf mehr Feldfehlerdaten und andere Informationen verfügbar werden, sodass das Fehlermodell 26 schließlich ein umfassendes Hilfsmittel zum Identifizieren von Fehlermodi auf der Grundlage ihrer Symptome bereitstellt. Das Fehlermodell 26 zeigt Symptome entlang der oberen Achse, die als S1-S6 dargestellt sind, und Fehlermodi auf der vertikalen Achse, die als F1-F10 dargestellt sind. Ein schwarzer Punkt (boolescher oder gebrochener Wert zwischen 0 und 1) in einem Fehlermodell entspricht der Angabe, welcher Fehlermodus durch welches Fehlersymptom identifiziert werden konnte. Das Diagnoselogikprogramm 28 analysiert die vorhandenen Symptome, um eine Rangordnungsliste der geschätzten Fehlermodi in Übereinstimmung mit ihren Wahrscheinlichkeitswerten bereitzustellen. Die hier diskutierte Methodik kann einen quantitativen Vergleich von Diagnoselogikprogrammen ausführen. Der Kasten 22 zeigt verschiedene Szenarien unter Verwendung der Was-wäre-wenn-Analyse in dem Kasten 12 und unter Verwendung der Simulationen in dem Kasten 16, die zum Erzeugen des Fehlermodells 26 in der oben diskutierten Weise verwendet werden. Der Kasten 30 repräsentiert simulierte Fehler, die durch die Simulationen in dem Kasten 16 bereitgestellt werden. Die simulierten Fehler 30 werden über das Fehlermodell 26 und die Diagnoselogikprogramme 28 analysiert, um geschätzte Fehler zu erzeugen, die durch einen Komparator 32 mit den simulierten Fehlern aus dem Algorithmus 30 verglichen werden, um als die Analyse in dem Kasten 18 die Wahr-Detektierungs- und Fehlalarmraten zu identifizieren. Somit kann durch Ausführen der Was-wäre-wenn-Analyse und Simulieren der Fehler das Fehlermodell 26 so bestätigt und geändert werden, dass die Symptome besser mit Fehlermodi verknüpft werden können.
-
Dieses Verfahren schafft eine systematische und quantitative Weise zum Bewerten mehrerer Diagnoselogikprogramme durch Erzeugen von Simulationen und durch ihr Analysieren über die Diagnoselogikprogramme. Da jedem Logikprogramm dasselbe Szenarium zugeführt wird, könnte die Ausgabe des Diagnoselogikprogramms und des Komparators, d. h. die Wahr-Detektierungs-/Fehlalarmrate, verglichen und bewertet werden.
-
Wenn durch den Komparator 32 der Vergleich zwischen den geschätzten Fehlern und den simulierten Fehlern vorgenommen wird, kann geeignetes Personal im Kasten 34 eine IVHM-Nutzenanalyse ausführen, um die Kosten zu senken.
-
Die IVHM-Nutzenanalyse setzt die Detektierungsrate und die Fehlalarmrate der Diagnoselogikprogramme 28 mit den Reparaturkosten wie etwa Arbeitskosten, anderen Arbeitszeitkosten, Gesamtkosten usw. in Beziehung. Ferner berechnet die IVHM-Nutzenanalyse unter Verwendung der Ergebnisse der Diagnosefolgerung die Abnahme der Fehldiagnoseraten, Wiederholungsbesuchs- und Mehrfachanspruchsraten. Außerdem berechnet die Analyse Einsparungen wegen der IVHM-Fehlermodelle und Diagnosefolgerung.
-
Die vorstehende Diskussion offenbart und beschreibt lediglich beispielhafte Ausführungsformen der vorliegenden Erfindung. Der Fachmann auf dem Gebiet erkennt aus dieser Diskussion und aus den beigefügten Zeichnungen und Ansprüchen leicht, dass daran verschiedene Änderungen, Abwandlungen und Veränderungen vorgenommen werden können, ohne von dem Erfindungsgedanken und Schutzumfang der Erfindung wie in den folgenden Ansprüchen definiert abzuweichen.
