DE102011014557B4

DE102011014557B4 - Verfahren zum Diagnostizieren von Ursachen von Fehlern in Fahrzeugsystemen

Info

Publication number: DE102011014557B4
Application number: DE102011014557.5A
Authority: DE
Inventors: Satnam Singh; Rahul Chougule; Pulak Bandyopadhyay
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2010-03-24
Filing date: 2011-03-21
Publication date: 2019-03-14
Anticipated expiration: 2031-03-22
Also published as: CN102200487B; US20110238258A1; US8301333B2; CN102200487A; DE102011014557A1

Abstract

Verfahren zum Diagnostizieren von Ursachen von Fehlern in Fahrzeugsystemen, wobei das Verfahren umfasst:
Definieren von mehreren Diagnosefehlercodes, die auf verschiedene Fehlerbedingungen in Systemen eines Fahrzeugs (12) anwendbar sind, von Kriterien zum Auslösen jedes Diagnosefehlercodes und einer Liste von Parameteridentifikationsdaten, die für jeden Diagnosefehlercode erfasst werden sollten;
Vorsehen eines Controllers (16) an Bord eines Fahrzeugs (12), der mit den Diagnosefehlercodes und den Kriterien zum Auslösen jedes Diagnosefehlercodes programmiert ist und der auch mit der Liste von Parameteridentifikationsdaten programmiert ist, die für jeden Diagnosefehlercode erfasst werden sollten;
Vorsehen von Sensoren (18) an Bord des Fahrzeugs (12), wie erforderlich, um die Parameteridentifikationsdaten zu erfassen;
Erfassen des Diagnosefehlercodes und der Parameteridentifikationsdaten durch den Controller (16), wenn eine Fehlerbedingung in einem Fahrzeugsystem auftritt, wobei jedes Auftreten einer Fehlerbedingung als Fehlerereignis bekannt ist;
Herunterladen des Diagnosefehlercodes und der Parameteridentifikationsdaten vom Controller (16) im Fahrzeug (12) auf einen zentralen Computer;
Speichern des Diagnosefehlercodes und der Parameteridentifikationsdaten für Fehlerereignisse von mehreren Fahrzeugen auf dem zentralen Computer, wobei jedes Fehlerereignis einen tatsächlichen Ausfallmodus aufweist, der ihm zugeschrieben ist;
Analysieren des Diagnosefehlercodes und der Parameteridentifikationsdaten von den auf dem zentralen Computer gespeicherten Fehlerereignissen unter Verwendung von mathematischen Modellen, die lernen können, Merkmale in den Daten mit dem tatsächlichen Ausfallmodus für jedes Fehlerereignis zu korrelieren; und
Verwenden der mathematischen Modelle, um einen Ausfallmodus für zusätzliche Fehlerereignisse zu diagnostizieren,
wobei das Analysieren des Diagnosefehlercodes und der Parameteridentifikationsdaten eine Trainingsphase und eine Testphase umfasst,
wobei die Trainingsphase umfasst:
Vorsehen von Eingangsdaten mit einer Matrix von Daten für jeden von mehreren Ausfallmodi, wobei jede Matrix von Daten den Ausfallmodus identifiziert, den sie betrifft, und einen Diagnosefehlercode und Parameteridentifikationsdaten für Fehlerereignisse von mehreren Fahrzeugen umfasst;
Verwenden eines Vorverarbeitungsmoduls (64), um die Abweichung in den Eingangsdaten zu normieren und zu verringern;
Verwenden eines Merkmalsgewinnungsmoduls (66), um charakteristische Merkmale der Eingangsdaten zu gewinnen;
Verwenden eines Klassifikatormoduls (68), um Muster in den Merkmalen der Eingangsdaten zu identifizieren und die Muster dem tatsächlichen Ausfallmodus zuzuordnen; und
Speichern von Techniken und Einstellungen, die in dem Merkmalsgewinnungsmodul (66) und dem Klassifikatormodul (68) verwendet werden und die Eingangsdaten am effektivsten mit den tatsächlichen Ausfallmodi korrelieren; und
wobei die Testphase umfasst:
Vorsehen einer Testdatenmatrix (82), die einen Diagnosefehlercode und Parameteridentifikationsdaten für Fehlerereignisse von mehreren Fahrzeugen umfasst, wobei jedes Fehlerereignis den tatsächlichen Ausfallmodus aufweist, der ihm zugeschrieben ist;
Verwenden des Vorverarbeitungsmoduls (64), des Merkmalsgewinnungsmoduls (66), des Klassifikatormoduls (68) und der gespeicherten Techniken und Einstellungen von der Trainingsphase, um einen diagnostizierten Ausfallmodus für jedes Fehlerereignis zu erzeugen; und
Verifizieren, dass die gespeicherten Techniken und Einstellungen von der Trainingsphase effektiv sind, mit der Testdatenmatrix (82), durch Vergleichen des diagnostizierten Ausfallmodus mit dem tatsächlichen Ausfallmodus für jedes Fehlerereignis,
wobei von einer Gesamtmenge von Daten, die in den Matrizes von Daten für jeden von mehreren Ausfallmodi zur Verfügung stehen, zwei Drittel für die Trainingsphase verwendet werden und das restliche eine Drittel für die Testphase verwendet wird.

Description

HINTERGRUND DER ERFINDUNG
Gebiet der Erfindung
Diese Erfindung bezieht sich allgemein auf ein System und ein Verfahren zum Diagnostizieren von Fehlerbedingungen in einem Fahrzeug und insbesondere auf ein System und ein Verfahren zum Erfassen von Betriebsparameterdaten, sobald ein Diagnosefehlercode (DTC) in einem Fahrzeug ausgelöst wird, und Anwenden von mathematischen Modellen sowohl auf die Parameterdaten als auch auf die DTC-Daten, um den Grund für die Fehlerbedingung zu diagnostizieren.
Erörterung der verwandten Technik
Moderne Fahrzeuge sind komplexe elektrische und mechanische Systeme, die viele Komponenten, Vorrichtungen, Module, Untersysteme usw. verwenden, die Betriebsinformationen zwischen und untereinander unter Verwendung von anspruchsvollen Algorithmen und Datenbussen übergeben. Wie überall sind diese Typen von Vorrichtungen und Algorithmen anfällig für Fehler, Ausfälle und Störungen, die sich auf den Betrieb des Fahrzeugs auswirken. Wenn solche Fehler und Störungen auftreten, gibt häufig die betroffene Vorrichtung oder Komponente einen Fehlercode wie z. B. einen Diagnosefehlercode (DTC) aus, der von einem oder mehreren Systemcontrollern empfangen wird, der den Fehler oder irgendeinen Zusatzfehler bei einer integrierten Komponente identifiziert. Diese DTCs können durch Kundendiensttechniker und -ingenieure analysiert werden, um Probleme zu identifizieren und/oder Systemkorrekturen und -aufrüstungen durchzuführen. In Anbetracht der Komplexität von Fahrzeugsystemen könnten jedoch viele DTCs und andere Signale aus vielen verschiedenen Gründen ausgelöst werden, was die Fehlersuche besonders schwierig machen könnte.
Wie vorstehend erwähnt, weisen moderne Fahrzeuge eine Anzahl von mechanischen und elektrischen Teilen auf, die durch verschiedene Controller in elektrischer Kommunikation stehen. Wenn ein bestimmter Aktuator, ein bestimmter Sensor oder ein bestimmtes Untersystem nicht korrekt arbeitet, liefert die Komponente oder das Untersystem oder sein Controller typischerweise einen DTC, der von einem Systemcontroller empfangen wird, so dass der DTC entweder unter Verwendung von Telematikdiensten wie z. B. OnStar™ oder Diagnosevorrichtungen während des Betriebs des Fahrzeugs heruntergeladen werden kann. Ein DTC kann jedoch aus einer Vielfalt von Gründen und auf der Basis von vielen verschiedenen Kombinationen von gemessenen Parametern ausgelöst werden. Dies macht es häufig schwierig, die wahre Grundursache eines Problems auf der Basis eines DTC-Werts allein zu diagnostizieren. Dies kann zur Unfähigkeit, ein Problem zu finden oder zu wiederholen, wenn das Fahrzeug gewartet wird, führen, was zu Kundenunzufriedenheit, erhöhten zukünftigen Garantiekosten und verpassten Gelegenheiten zum Verbessern der Systemkonstruktionen auf der Basis von realen Ausfallmodi führt.
In Anbetracht der unannehmbar hohen Rate von verpassten Diagnosen von Fahrzeugfehlern unter Verwendung von derzeitigen Techniken besteht ein Bedarf, die Fehlerdiagnose von Fahrzeugsystemen durch Erfassen von mehr Betriebsparameterdaten, wenn ein DTC ausgelöst wird, und Anwenden von fortschrittlichen mathematischen Techniken auf die Daten, um die wahre Grundursache irgendeiner Fehlerbedingung zu finden, zu verbessern.
DE 103 19 493 A1 offenbart ein Diagnosesystem zur Überwachung eines Fahrzeugs, wobei ein Datenerfassungsspeicher in dem Fahrzeug Abtastwerte von elektrischen Signalen von Betriebskomponenten des Fahrzeugs speichert und ein Analysator in dem Fahrzeug Abweichungen der Signale von einem Sollbetriebszustand erkennt. Bei einer auftretenden Abweichung werden basierend auf einem auslösenden Ereignis mehrere Abtastwerte an ein entferntes Rechenzentrum übertragen, welches diese klassifiziert. Weiterer Stand der Technik ist aus DE 690 28 872 T2 und DE 102 35 525 B4 bekannt.
ZUSAMMENFASSUNG DER ERFINDUNG
Aufgabe der Erfindung ist es, ein verbessertes Verfahren zum Diagnostizieren von Ursachen von Fehlern in Fahrzeugsystemen bereitzustellen.
Zur Lösung der Aufgabe ist ein Verfahren mit den Merkmalen des Anspruchs 1 vorgesehen. Vorteilhafte Ausbildungen der Erfindung sind den Unteransprüchen, der Beschreibung und den Zeichnungen zu entnehmen.
Figurenliste

1 ist ein Diagramm eines Fahrzeugs mit Sensoren und einem Controller zum Erfassen von fehlerbezogenen Daten, die in einem Fehlerdiagnosegerüst verwendet werden sollen;
2 ist ein Diagramm einer Matrix von ereignisgesteuerten Daten, die zum Organisieren von fehlerbezogenen Daten, die zur Fehlerdiagnose verwendet werden, verwendet wird;
3 ist ein Ablaufplandiagramm eines Prozesses, der für die Erfassung von Fahrzeugfehlerereignisdaten und zum Herunterladen derselben auf einen zentralen Computer verwendet wird;
4 ist ein Blockdiagramm eines Systems, das für eine Trainingsphase des Fehlerdiagnosegerüsts verwendet wird; und
5 ist ein Blockdiagramm eines Systems, das für eine Testphase des Fehlerdiagnosegerüsts verwendet wird.

AUSFÜHRLICHE BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
Die folgende Erörterung der Ausführungsformen der Erfindung, die sich auf ein ereignisgesteuertes Fehlerdiagnosegerüst für Kraftfahrzeugsysteme richtet, ist dem Wesen nach lediglich beispielhaft und soll keineswegs die Erfindung oder ihre Anwendungen oder Verwendungen begrenzen. Die vorliegende Erfindung hat beispielsweise spezielle Anwendung für eine Fahrzeugfehlerdiagnose. Das Verfahren der Erfindung hat jedoch andere Anwendungen für andere Industrien, wie z. B. Fehlerdiagnose in der Luft- und Raumfahrt, bei Schwermaschinen und in anderen Transportindustrien.
1 ist ein Diagramm eines Fahrzeugs 12 mit einer Bordanlage, die zum Erfassen von fehlerbezogenen Daten erforderlich ist. Das Fahrzeug 12 umfasst einen Motor 14 und zahlreiche andere Systeme und Untersysteme wie z. B. Aufhängungs-, Lenk-, Getriebe- und Endantriebs-, Wärraemanagement-, Unterhaltungs- und Sicherheitssysteme. Jedes dieser Systeme besteht typischerweise aus vielen Untersystemen und Komponenten, die sich in einem guten Arbeitszustand befinden müssen, damit das Muttersystem korrekt funktioniert. Irgendein modernes Fahrzeug 12 umfasst einen oder mehrere Controller 16 zum Überwachen und Steuern der verschiedenen Fahrzeugsysteme und -untersysteme. Das Fahrzeug 12 umfasst auch viele Bordsensoren 18 zum Messen eines breiten Bereichs von System- und Komponentenparametern, einschließlich Temperaturen, Drücken, Spannungen, Kräften, Fluidströmungsraten, Fluidpegeln und anderer. Die Sensoren 18 übergeben ihre Parameterdaten an den Controller 16 über elektronische Netze, die verdrahtet oder drahtlos sein können. Der Controller 16 umfasst einen Speicher zum Speichern von Parameterdaten und einen Prozessor, der mit Algorithmen zum Steuern der verschiedenen Fahrzeugsysteme und -untersysteme konfiguriert ist.
Im Fahrzeug 12 werden Parameterdaten von den Sensoren 18 kontinuierlich überwacht. Der Controller 16 ist programmiert, um die Werte von vielen verschiedenen Parametern und Kombinationen von Parametern zu prüfen, um festzustellen, ob die Werte innerhalb normaler Bereiche liegen. Wenn ein Parameter oder eine Kombination von Parametern als außerhalb seines normalen Bereichs detektiert wird, werden ein oder mehrere Fehlercodes oder Diagnosefehlercodes (DTC) ausgelöst und im Controller 16 gespeichert. Eine Kraftstofftank-Drucksensorschaltung, die außerhalb ihres Bereichs liest, kann beispielsweise einen DTC auf Schaltungsebene auslösen. Dieses Problem würde wahrscheinlich ziemlich leicht als entweder ein schlechter Kraftstofftank-Drucksensor oder eine fehlerhafte Verdrahtungsverbindung vom Kraftstofftank-Drucksensor mit dem Controller 16 diagnostiziert werden. Andererseits kann eine Motorfehlzündung einen oder mehrere DTCs auf Untersystemebene auslösen. Die Fehlzündungsbedingung kann sehr schwierig zu diagnostizieren und zu korrigieren sein, da sie durch ein Problem bei dem Kraftstoff- oder dem Kraftstoffeinspritzsystem, ein Zündsystemproblem, ein Verdrahtungsproblem, ein mechanisches Problem irgendwo im Motor 14 oder irgendein anderes Problem verursacht werden könnte. Das Ziel der vorliegenden Erfindung besteht darin, so viel relevante Daten wie möglich zu erfassen, sobald ein DTC ausgelöst wird, und diese Daten sowohl für den Zweck des Lösens jedes individuellen Fahrzeugproblems als auch für den Zweck der Identifikation und Korrektur von Systemkonstruktionsproblemen zu analysieren.
Um das gewünschte Ziel zu erreichen, wird eine dreidimensionale Datenmatrix vorgeschlagen. 2 ist ein Diagramm einer Datenmatrix 30, die zum Sammeln und Organisieren von ereignisgesteuerten Fehlerdaten verwendet wird. Die Datenmatrix 30 umfasst Fahrzeuge als erste Dimension 32, DTCs als zweite Dimension 34 und Parameteridentifikationsdaten (PID) als dritte Dimension 36. Fahrzeuge können durch ihre Fahrzeugidentifikationsnummer (VIN) oder irgendeinen anderen geeigneten Identifizierer identifiziert werden. DTCs müssen einen eindeutigen Identifizierer oder ein Nummerierungsschema aufweisen. Es können Hunderte von verschiedenen DTCs vorhanden sein, die irgendeiner speziellen Fahrzeugplattform zugeordnet sind. PIDs müssen auch einen eindeutigen Identifizierer oder ein Nummerierungsschema aufweisen. Es sind typischerweise Tausende von Parametern oder PIDs vorhanden, die an irgendeiner Motor- oder Fahrzeugfamilie erfasst werden können. Üblicherweise verwendete PIDs umfassen beispielsweise die Motordrehzahl, die Fahrzeuggeschwindigkeit, die Motorkühlmitteltemperatur, den Einlasskrümmerdruck, den Kraftstoffdruck und die Batteriespannung. In der ganzen folgenden Erörterung wird der Begriff PID allgemein verwendet, um auf sowohl einzelne Parameterwerte wie z. B. die Motordrehzahl als auch Felder oder „Pakete“ von zugehörigen Parametern, die manchmal als Datenpaketidentifizierer (DPIDs) bekannt sind, Bezug zu nehmen.
Um die Datenmatrix 30 zu konstruieren, ist es erforderlich zu definieren, welche PIDs für jeden DTC erfasst werden sollten. Viele DTCs erfordern, dass Dutzende oder sogar Hunderte von spezifischen PIDs erfasst werden. Diese Beziehung wird typischerweise durch einen Ingenieur definiert, der für das System verantwortlich ist, auf das sich der DTC bezieht. Folglich wird die Matrix 30 konstruiert, indem für eine gegebene Fahrzeugplattform definiert wird, welche DTCs anwendbar sind, und für jeden DTC, welche PIDs erfasst werden sollten. Die Datenmatrix 30 kann dann mit Ereignisdaten von individuellen Fahrzeugen im Betrieb belegt werden, wenn ein DTC ausgelöst wird.
3 ist ein Ablaufplandiagramm 40 eines Prozesses zum Erfassen von DTC- und PID-Daten und Belegen von Datenmatrizes. Der Prozess beginnt im Kasten 42, in dem der Controller 16 irgendeines speziellen Fahrzeugs mit Kriterien zum Auslösen von DTCs und mit einer Liste von PIDs, die erfasst werden sollten, wenn irgendein gegebener DTC ausgelöst wird, programmiert wird. Ein spezieller DTC kann beispielsweise zum Auslösen definiert sein, wenn bestimmte Kombinationen von Bedingungen existieren, wie z. B. dass der Motoröldruck unter einem bestimmten Wert liegt, während die Motordrehzahl gleichzeitig innerhalb eines bestimmten Bereichs liegt. Wie vorher erwähnt, sind Hunderte von DTCs und ihre Kriterien auf die meisten Fahrzeuge anwendbar. Für jeden DTC wird auch ein Satz von PIDs definiert, so dass alle der vorgeschriebenen PID-Daten in einer „Standbild“-Weise erfasst werden, wenn irgendein spezieller DTC ausgelöst wird. Der Prozess fährt im Kasten 44 fort, wenn ein Fahrzeug 12 ein Fehlerereignis oder ein Problem, das einen oder mehrere DTC auslöst, erfährt. Im Kasten 46 wird (werden) der (die) DTC(s) und die zugehörigen PID-Daten im Controller 16 für das Ereignis erfasst. Im Kasten 48 werden die individuellen Ereignisdaten auf einen zentralen Computer heruntergeladen, der eine Stammkopie der Datenmatrix enthält. Der Datendownload kann stattfinden, wenn das Fahrzeug 12 zum Kundendienst zu einem Händler gebracht wird, oder der Datendownload kann zu irgendeiner Zeit über eine drahtlose Kommunikation oder ein Telematiksystem bearbeitet werden. Die Aktivitäten der Kästen 44, 46 und 48 fahren auf einer andauernden Basis fort, wenn mehr individuelle Fahrzeuge Fehlerereignisse erfahren, erfassen DTC- und PID-Daten und laden diese Daten auf den Computer herunter, der die Stammkopie der Datenmatrix beherbergt. Im Kasten 50 wird die Stammdatenmatrix mit DTC- und PID-Daten von verschiedenen Fahrzeugereignissen belegt. Die PID-Daten können auch mit anderen relevanten Informationen über den Fehler ergänzt werden, wie z. B. Daten, die durch Diagnosewerkzeuge an einem Kundendienstzentrum aufgenommen werden, und Kundenrückmeldung hinsichtlich des Ereignisses.
In dieser Stufe enthält die Matrix Daten von Ereignissen, die viele verschiedene Fahrzeugsystem-Ausfallmodi darstellen. Dann ist es erforderlich, tatsächliche Einsatzdiagnosedaten zu verwenden, um die ereignisspezifischen DTC- und PID-Daten nach dem Ausfallmodus zu trennen. Im Kasten 52 werden Einsatzkundendienstberichte, Kundenbeobachtungen und andere Daten verwendet, um den tatsächlichen Ausfallmodus, wenn möglich, für jeden individuellen Ereignisdatensatz zu identifizieren. Dann ist es möglich, Matrizes von ereignisgesteuerten Daten für spezifische Ausfallmodi im Kasten 54 zu konstruieren, wobei jede Matrix von für den Ausfallmodus spezifischen Daten das Fahrzeug, den DTC und PID-Daten für Ereignisse enthält, von denen bekannt ist, dass sie einen spezifischen Ausfallmodus aufweisen. Die Matrizes von für den Ausfallmodus spezifischen Daten können für so viele verschiedene Ausfallmodi konstruiert werden wie Daten zur Unterstützung verfügbar sind. Beispielsweise kann eine Matrix von für den Ausfallmodus spezifischen Daten mit DTC- und PID-Daten für Ereignisse belegt werden, die als durch einen Kraftstofftankdruck- (FTP) Sensor-Niederspannungsausfall verursacht diagnostiziert werden, eine andere Matrix kann für Ereignisse erzeugt werden, bei denen der Ausfallmodus als FTP-Sensor-Hochspannungsausfall diagnostiziert wird, und so weiter. Nachdem Matrizes von ereignisgesteuerten Daten mit ausreichend Daten für mehrere spezifische Ausfallmodi belegt sind, kann ein Analyseprozess unternommen werden.
Der Analyseprozess der vorliegenden Erfindung findet in zwei Phasen statt - einer Trainingsphase und einer Testphase. In der Trainingsphase werden verschiedene mathematische und statistische Werkzeuge verwendet, um die Daten in den Matrizes von für den Ausfallmodus spezifischen Daten zu analysieren, charakteristische Merkmale der Daten zu identifizieren und die Datenmerkmale nach dem Ausfallmodus zu klassifizieren. Die Trainingsphase umfasst eine Maschinenlerntechnik, die als trainierte Klassifikatoren bekannt ist, um für den Ausfallmodus spezifische Muster in den Daten zu identifizieren. In der Testphase werden individuelle Fahrzeugfehlerereignisdaten analysiert und Diagnosen werden unter Verwendung der trainierten Klassifikatoren von der Trainingsphase ausgegeben. Die Testphase validiert mit zusätzlichen Daten, dass die trainierten Klassifikatoren wie erwartet arbeiten.
4 ist ein Blockdiagramm eines Systems 60, das für die Trainingsphase verwendet wird. Das Trainingssystem 60 umfasst die mathematischen und statistischen Werkzeuge und Techniken, die für die Vorverarbeitung der Daten, zum Gewinnen von charakteristischen Merkmalen der Daten und zum Training der Klassifikatoren, um die Datenmerkmale durch den Ausfallmodus zu erkennen, verwendet werden können. Es wird als Trainingsphase beschrieben, da die mathematischen Modelle tatsächlich lernen, welche Parametereinstellungen verwendet werden sollen, um die relevantesten Merkmale der Daten zu gewinnen und die Datenmerkmale nach dem tatsächlichen Ausfallmodus korrekt zu klassifizieren. Das Trainingssystem 60 beginnt mit Matrizes 62 von für den Ausfallmodus spezifischen Daten. Wie vorstehend beschrieben, enthält jede der Matrizes 62 Daten nur für Ereignisse, von denen festgestellt wird, dass sie einem spezifischen Ausfallmodus zugeschrieben sind, wobei die Daten Fahrzeug-, DTC- und PID-Daten umfassen. Die Datenmatrizes 62 werden zu einem Datenvorverarbeitungsmodul 64 geliefert, das Normierung, Varianzverringerung und möglicherweise andere Techniken verwendet, um die Datenmatrizes 62 für die Merkmalsgewinnung vorzubereiten. Der Zweck des Vorverarbeitungsmoduls 64 besteht darin, Anomalien in den Daten zu minimieren oder zu beseitigen, wie z. B. Fehler, die während des Datendownloads von einem Fahrzeug auf den zentralen Computer auftreten könnten, die die Datenanalyse, die gleich unternommen wird, verzerren oder behindern könnten.
Ein Merkmalsgewinnungsmodul 66 verwendet mehrere Datenreduktions-, Datentransformations- und Datenanalysetechniken, um Merkmale der Daten aus den Datenmatrizes 62 zu identifizieren. Merkmale sind Eigenschaften der Daten, die für die spätere Klassifikation der Daten nützlich sein können. Beispiele von Techniken, die im Merkmalsgewinnungsmodul 66 verwendet werden, umfassen Schlüsselstatistik und Dimensionsverringerungstechniken, wie z. B. Hauptkomponentenanalyse (PCA) und partiell kleinste Quadrate (PLS). Diese Techniken sind alle dem Fachmann auf dem Gebiet der Datenanalyse und Digitalsignalverarbeitung bekannt. Durch automatisches Anwenden von mehreren Analysetechniken auf die Daten kann das Merkmalsgewinnungsmodul 66 Merkmale identifizieren, die ansonsten übersehen werden könnten, wenn nur manuelle oder weniger umfangreiche Datenanalysetechniken verwendet werden würden.
Ein Datenklassifikatorniodul 68 empfängt die Merkmale vom Merkmalsgewinnungsmodul 66 und führt eine Klassifikation durch. Die Klassifikation ist eine Maschinenlerntechnik, die verwendet wird, um die Gruppenmitgliedschaft für Dateninstanzen vorherzusagen. Grob gesagt besteht das Ziel des Maschinenlernens darin, dass ein Computer automatisch lernt, komplexe Muster zu erkennen und auf der Basis der Daten intelligente Entscheidungen zu treffen. Wie hier angewendet, wird die Klassifikation verwendet, um Muster in den Datenmerkmalen spezifischen Fahrzeugsystem-Ausfallmodi zuzuordnen. Das Datenklassifikatorniodul 68 verwendet viele Typen von Klassifikatoren, einschließlich einer Stützvektormaschine (SVM), probabilistischer Neuronennetze (PNN), k-nächster Nachbar (KNN); Entscheidungsbäumen (DT), einer linearen Diskriminanzanalyse (LDA) und einer quadratischen Diskriminanzanalyse (QDA). Diese Techniken oder Kombinationen von ihnen, die als Fusionen bekannt sind, sind auch dem Fachmann auf dem Gebiet bekannt und von ihnen wurde gezeigt, dass sie Muster in den Datenmerkmalen identifizieren können, die den Ausfallmodus angeben. Die Ausgabe des Klassifikatormoduls 68 ist das kumulative Lernen des ganzen Trainingssystems 60. Dies umfasst die Parameter und Einstellungen, die im Datenvorverarbeitungsmodul 64 verwendet werden; die Techniken und Parameter, die im Merkmalsgewinnungsmodul 66 verwendet werden, und die Merkmale, die sich daraus ergeben; und die Klassifikatoren, die im Klassifikatormodul 68 verwendet werden, die Parameter, die darin gelernt werden, und die Klassifikationsmuster, die darin detektiert werden.
Die Testphase wird verwendet, um die Klassifikatoren, die in der Trainingsphase in einer Maschinenlernhinsicht trainiert wurden, zu validieren. Das heißt, die Testphase verifiziert, dass die trainierten Klassifikatoren beim Identifizieren von für den Ausfallmodus spezifischen Mustern in den Daten und zum Erreichen einer korrekten Diagnose für zusätzliche Daten auf Ereignisbasis effektiv sind. Erfindungsgemäß werden von der Gesamtmenge von Ereignisdaten, die in den Matrizes 62 von für den Ausfallmodus spezifischen Daten zur Verfügung stehen, zwei Drittel für die Trainingsphase verwendet und wird das restliche eine Drittel für die Testphase verwendet.
5 ist ein Blockdiagramm eines Systems 80, das für die Testphase verwendet wird. Das Testsystem 80 beginnt mit einer Testdatenmatrix 82. Die Testdatenmatrix 82 kann Ereignisdaten für mehrere verschiedene bekannte Ausfallmodusereignisse umfassen oder sie kann nur Daten für Ereignisse enthalten, von denen bekannt ist, dass sie durch einen einzelnen spezifischen Ausfallmodus verursacht werden. In beiden Fällen wird die Testphase verwendet, um zu verifizieren, dass die trainierten Klassifikatoren die korrekte Diagnose für jedes Ereignis in der Testdatenmatrix 82 erreichen. Ein Datenvorverarbeitungs- und Merkmalsgewinnungsmodul 84 arbeitet in derselben Weise wie die Module 64 und 66 vom Trainingssystem 60 unter Verwendung derselben Techniken und Einstellungen, die für die Merkmalsgewinnung im Trainingssystem 60 verwendet werden. Dies stellt sicher, dass die aus der Testdatenmatrix 82 gewonnenen Merkmale zu den Merkmalen, die aus den Matrizes 62 von für den Ausfallmodus spezifischen Daten gewonnen werden, die in der Trainingsphase verwendet wurden, vergleichbar sind. Merkmale, die aus dem Modul 84 gewonnen werden, werden zum Modul 86 von trainierten Klassifikatoren übergeben, das mit Parametern konfiguriert ist, die während der Trainingsphase gelernt wurden. Das heißt, das Ergebnis der Trainingsphase besteht darin, dass spezifische Klassifikatoren in einer Maschinenlernhinsicht trainiert wurden, um Muster in den Merkmalsdaten zu erkennen, die spezifischen Ausfallmodi zugeordnet sind. In der Testphase werden die trainierten Klassifikatoren im Modul 86 verwendet, um Ausfallmodi für jedes spezifische Ereignis in der Testdatenmatrix 82 zu diagnostizieren.
Sobald die trainierten Klassifikatoren im Modul 86 getestet sind und gezeigt wurde, dass sie Ausfallmodi für spezifische DTC-Ereignisse zuverlässig diagnostizieren, können die Merkmalsgewinnungs- und Klassifikatormodule an Bord von Fahrzeugen oder anderweitig für die Fehlerisolation eingesetzt werden. Der unmittelbarste Vorteil kann unter Verwendung der Klassifikatoren zum Diagnostizieren der Grundursachen von individuellen Fahrzeugfehlerereignissen, wenn sie auftreten, erlangt werden. Die Klassifikatoren können auf die Fehlerdiagnose in zwei Weisen angewendet werden. Erstens können die Diagnosemuster auf Computer 88 in Fahrzeugkundendienstzentren heruntergeladen werden, so dass, wenn ein Fahrzeug 12, das ein Fehlerereignis erfahren hat, zur Reparatur zum Kundendienstzentrum gebracht wird, die DTC- und PID-Daten vom Fahrzeug 12 auf den Kundendienstzentrum-Computer 88 heruntergeladen werden, das Diagnosemuster durch den Kundendienstzentrum-Computer 88 erkannt wird und die Diagnose zum Kundendiensttechniker geliefert wird. Eine andere Weise, in der die Datenklassifikation für die Fehlerdiagnose verwendet werden kann, besteht im Herunterladen der Diagnosemuster direkt auf Computer 90 an Bord von individuellen Fahrzeugen 12. Der Computer 90 könnte dieselbe Vorrichtung wie der Controller 16 sein oder er könnte eine andere Vorrichtung sein. Wenn der Bordcomputer 90 mit den trainierten Klassifikatoren programmiert ist, die zum Erkennen von Diagnosedatenmustern erforderlich sind, dann ist es, wenn ein Fehlerereignis auftritt und DTC- und PID-Daten erfasst werden, möglich, dass der Bordcomputer 90 unmittelbar die wahre Grundursache des Fehlers diagnostiziert. Dies würde wiederum ermöglichen, dass eine weitere Handlung unternommen wird, wie z. B. Umkonfigurieren oder Deaktivieren von von Fehlern betroffenen Systemen oder Benachrichtigen des Fahrers, dass das Fahrzeug 12 bald zum Kundendienst zu einem Händler gebracht werden sollte. Eine drahtlose Kommunikation oder Telematiksysteme könnten auch verwendet werden, um eine Bordfahrzeugdiagnose zusammen mit den zugehörigen DTC- und PID-Daten zu einem Fahrzeugkundendienstzentrum weiterzuleiten. Das Kundendienstzentrum könnte dann den Eigentümer des Fahrzeugs kontaktieren, dem Eigentümer die Situation erklären und möglicherweise einen Termin für einen Kundendienst vereinbaren.
Die Ergebnisse der Fehlerdatenanalyse und -klassifikation können auch auf zukünftige Produktkonstruktionen angewendet werden. Die Datenanalyse mit den vorstehend beschriebenen Verfahren kann beispielsweise ein wiederkehrendes Problem bei der Zuverlässigkeit oder Haltbarkeit einer Hardwarekomponente oder beim Betrieb einer Softwarekomponente aufdecken, was zu einer Schlussfolgerung führt, dass die fehlerhafte Komponente für ein zukünftiges Fahrzeugprogramm umgestaltet werden sollte. Die Anwendung von Kundendienstdaten von einer existierenden Flotte von Fahrzeugen auf zukünftige Fahrzeugkonstruktionen ist nichts neues, aber die Verfahren der vorliegenden Erfindung ermöglichen eine verbesserte Diagnose der Grundursache von Fehlern, während das Vorkommen einer Fehldiagnose verringert wird, wobei somit besser ersichtlich gemacht wird, welche Fehler an welchen Fahrzeugen unter welchen Umständen auftreten. Mit existierenden Fehlerdatenanalyseverfahren können einige Typen von Fehlern niemals mit ausreichend Genauigkeit und Häufigkeit diagnostiziert werden, um eine zukünftige Konstruktionsverbesserung zu ermöglichen. Die vorstehend erwähnte fehlerhafte Komponente kann beispielsweise niemals vorher als problematisch identifiziert worden sein, da Systemfehler in vielen Fällen nicht korrekt diagnostiziert worden sein können. Die Verfahren der vorliegenden Erfindung führen zu weitaus deutlicheren Informationen, die in der Ausfallauswirkungsanalyse (FMEA) verwendet und auf zukünftige Fahrzeugkonstruktionen angewendet werden können.
Die Datenmatrix 30 kann auch auf eine vierte Dimension erweitert werden, wobei die vierte Dimension die Zeit ist. Zeitdaten können in einem beliebigen geeigneten Zeitmaßstab gemessen werden, vorzugsweise einem absoluten Zeitmaßstab, der ein Jahr, eine Tagnummer innerhalb des Jahrs, eine Stunde, eine Minute und eine Sekunde umfasst. Ein Zeitstempel würde für jeden DTC-Ereignis-Eintrag in der Datenmatrix 30 aufgezeichnet werden. Wenn ein DTC-Ereignis ein zweites Mal an einem individuellen Fahrzeug auftreten würde, könnten dann Parameterdaten ausgewertet werden, um festzustellen, ob sich irgendetwas über die Zeit signifikant geändert hat. Beispielsweise soll ein intermittierendes DTC-Ereignis eines Kraftstofftankdrucksensors (FTP-Sensors) betrachtet werden, das dreimal mit einem Monat von vergangener Zeit zwischen den drei Ereignissen aufgetreten ist. In diesem Beispiel wurde das DTC-Ereignis ausgelöst, als das Motorsteuermodul eine abrupte FTP-PID-Änderung detektierte. Wenn die FTP-Spannungs-PID einen zunehmenden oder abnehmenden Trend während dieser drei Ereignisse aufweisen, könnte dies darauf hindeuten, dass entweder der FTP-Sensor-Referenzkanal blockiert wird oder dass ein FTP-Sensorschaltungs-Niederspannungs- oder -Hochspannungsproblem in der nahen Zukunft an diesem Fahrzeug auftritt. Dieses Beispiel stellt sehr einfach dar, wie die Zeitdaten verwendet werden können, um die Typen von Analyse und Diagnose zu verbessern, die von der Datenmatrix 30 möglich sind. Viel anspruchsvollere Analysen sind möglich, einschließlich der Verwendung der Zeitdaten, um eine Prognose der Systemgesundheit und der restlichen Nutzlebensdauer zu schaffen. Die Restnutzlebensdauerdaten können dann durch ein Fahrzeugkundendienstzentrum verwendet werden, um eine Empfehlung an einen Fahrzeugeigentümer zum Reparieren oder Austauschen des Systems oder der Komponente, das/die sich verschlechtert, zu geben.
Die vorstehend beschriebenen Systeme und Verfahren schaffen ein verbessertes Diagnosegerüst für Fahrzeugsystemfehler, während sie nicht erfordern, dass irgendeine zusätzliche Hardware in Fahrzeuge aufgenommen wird. Die verbesserten Fehlerdiagnoseinformationen können einen unmittelbaren Vorteil für den Eigentümer eines Fahrzeugs durch schnelle Diagnose und Korrektur irgendeines Problems schaffen und können ermöglichen, dass ein Fahrzeughersteller die Kundenzufriedenheit verbessert, Garantiekosten verringert und zukünftige Produktkonstruktionen verbessert.
Die vorangehende Erörterung offenbart und beschreibt lediglich beispielhafte Ausführungsformen der vorliegenden Erfindung. Ein Fachmann auf dem Gebiet erkennt leicht aus einer solchen Erörterung und aus den begleitenden Zeichnungen und Ansprüchen, dass verschiedene Änderungen, Modifikationen und Variationen darin durchgeführt werden können, ohne vom Gedanken und Schutzbereich der Erfindung, wie in den folgenden Ansprüchen definiert, abzuweichen.

Claims

Verfahren zum Diagnostizieren von Ursachen von Fehlern in Fahrzeugsystemen, wobei das Verfahren umfasst: Definieren von mehreren Diagnosefehlercodes, die auf verschiedene Fehlerbedingungen in Systemen eines Fahrzeugs (12) anwendbar sind, von Kriterien zum Auslösen jedes Diagnosefehlercodes und einer Liste von Parameteridentifikationsdaten, die für jeden Diagnosefehlercode erfasst werden sollten; Vorsehen eines Controllers (16) an Bord eines Fahrzeugs (12), der mit den Diagnosefehlercodes und den Kriterien zum Auslösen jedes Diagnosefehlercodes programmiert ist und der auch mit der Liste von Parameteridentifikationsdaten programmiert ist, die für jeden Diagnosefehlercode erfasst werden sollten; Vorsehen von Sensoren (18) an Bord des Fahrzeugs (12), wie erforderlich, um die Parameteridentifikationsdaten zu erfassen; Erfassen des Diagnosefehlercodes und der Parameteridentifikationsdaten durch den Controller (16), wenn eine Fehlerbedingung in einem Fahrzeugsystem auftritt, wobei jedes Auftreten einer Fehlerbedingung als Fehlerereignis bekannt ist; Herunterladen des Diagnosefehlercodes und der Parameteridentifikationsdaten vom Controller (16) im Fahrzeug (12) auf einen zentralen Computer; Speichern des Diagnosefehlercodes und der Parameteridentifikationsdaten für Fehlerereignisse von mehreren Fahrzeugen auf dem zentralen Computer, wobei jedes Fehlerereignis einen tatsächlichen Ausfallmodus aufweist, der ihm zugeschrieben ist; Analysieren des Diagnosefehlercodes und der Parameteridentifikationsdaten von den auf dem zentralen Computer gespeicherten Fehlerereignissen unter Verwendung von mathematischen Modellen, die lernen können, Merkmale in den Daten mit dem tatsächlichen Ausfallmodus für jedes Fehlerereignis zu korrelieren; und Verwenden der mathematischen Modelle, um einen Ausfallmodus für zusätzliche Fehlerereignisse zu diagnostizieren, wobei das Analysieren des Diagnosefehlercodes und der Parameteridentifikationsdaten eine Trainingsphase und eine Testphase umfasst, wobei die Trainingsphase umfasst: Vorsehen von Eingangsdaten mit einer Matrix von Daten für jeden von mehreren Ausfallmodi, wobei jede Matrix von Daten den Ausfallmodus identifiziert, den sie betrifft, und einen Diagnosefehlercode und Parameteridentifikationsdaten für Fehlerereignisse von mehreren Fahrzeugen umfasst; Verwenden eines Vorverarbeitungsmoduls (64), um die Abweichung in den Eingangsdaten zu normieren und zu verringern; Verwenden eines Merkmalsgewinnungsmoduls (66), um charakteristische Merkmale der Eingangsdaten zu gewinnen; Verwenden eines Klassifikatormoduls (68), um Muster in den Merkmalen der Eingangsdaten zu identifizieren und die Muster dem tatsächlichen Ausfallmodus zuzuordnen; und Speichern von Techniken und Einstellungen, die in dem Merkmalsgewinnungsmodul (66) und dem Klassifikatormodul (68) verwendet werden und die Eingangsdaten am effektivsten mit den tatsächlichen Ausfallmodi korrelieren; und wobei die Testphase umfasst: Vorsehen einer Testdatenmatrix (82), die einen Diagnosefehlercode und Parameteridentifikationsdaten für Fehlerereignisse von mehreren Fahrzeugen umfasst, wobei jedes Fehlerereignis den tatsächlichen Ausfallmodus aufweist, der ihm zugeschrieben ist; Verwenden des Vorverarbeitungsmoduls (64), des Merkmalsgewinnungsmoduls (66), des Klassifikatormoduls (68) und der gespeicherten Techniken und Einstellungen von der Trainingsphase, um einen diagnostizierten Ausfallmodus für jedes Fehlerereignis zu erzeugen; und Verifizieren, dass die gespeicherten Techniken und Einstellungen von der Trainingsphase effektiv sind, mit der Testdatenmatrix (82), durch Vergleichen des diagnostizierten Ausfallmodus mit dem tatsächlichen Ausfallmodus für jedes Fehlerereignis, wobei von einer Gesamtmenge von Daten, die in den Matrizes von Daten für jeden von mehreren Ausfallmodi zur Verfügung stehen, zwei Drittel für die Trainingsphase verwendet werden und das restliche eine Drittel für die Testphase verwendet wird.
Verfahren nach Anspruch 1, wobei das Merkmalsgewinnungsmodul (66) mindestens eine der Techniken umfasst, die Schlüsselstatistik, Hauptkomponentenanalyse und partiell kleinste Quadrate umfassen.
Verfahren nach Anspruch 1, wobei das Klassifikatormodul (68) mindestens eine der Techniken umfasst, die eine Stützvektormaschine, probabilistische Neuronennetze, k-nächster Nachbar, Entscheidungsbäume, lineare Diskriminanzanalyse und quadratische Diskriminanzanalyse umfassen.
Verfahren nach Anspruch 1, das ferner das Herunterladen der mathematischen Modelle nach der Trainings- und Testphase auf einen Computer (88) in einem Fahrzeugreparatur-Kundendienstzentrum und das Verwenden der mathematischen Modelle, um einen Ausfallmodus für Fehlerereignisse an Fahrzeugen, die zur Diagnose zum Fahrzeugreparatur-Kundendienstzentrum gebracht werden, zu diagnostizieren, umfasst.
Verfahren nach Anspruch 1, das ferner das Herunterladen der mathematischen Modelle nach der Trainings- und Testphase auf einen Computer an Bord eines Fahrzeugs (12) und das Verwenden der mathematischen Modelle zum Diagnostizieren eines Ausfallmodus für Fehlerereignisse an dem Fahrzeug (12) umfasst.
Verfahren nach Anspruch 1, wobei der Diagnosefehlercode und die Parameteridentifikationsdaten auch einen Zeitstempel für jedes Fehlerereignis umfassen.
Verfahren nach Anspruch 6, das ferner die Verwendung des Diagnosefehlercodes und der Parameteridentifikationsdaten und des Zeitstempels für jedes Fehlerereignis umfasst, um eine Prognose der Systemgesundheit und der restlichen Nutzlebensdauer für irgendein am Fehlerereignis beteiligtes System durchzuführen.