DE102022126225A1

DE102022126225A1 - System und verfahren zum validieren der durch bordinterne diagnosesysteme von fahrzeugen erzeugten diagnosefehlercodes

Info

Publication number: DE102022126225A1
Application number: DE102022126225.1A
Authority: DE
Inventors: Shiming Duan; Yingjie Cai; Paul R. Hozak; Fernando Ferreira Pio; Gregory Sapick; Xiaomeng Peng
Original assignee: NORTHEASTERN, University of; GM Global Technology Operations LLC
Current assignee: NORTHEASTERN, University of; GM Global Technology Operations LLC
Priority date: 2022-03-04
Filing date: 2022-10-10
Publication date: 2023-09-07
Also published as: CN116736825A; US20230282033A1

Abstract

Ein System zum Validieren von Diagnosefehlercodes (DTCs) in Fahrzeugen enthält einen Prozessor und einen Speicher, der Anweisungen speichert, die, wenn sie durch den Prozessor ausgeführt werden, den Prozessor konfigurieren, DTC-Daten von den Fahrzeugen zu empfangen, die DTC-Daten unter Verwendung vorgegebener Regeln zu filtern, eine oder mehrere Metriken basierend auf den gefilterten DTC-Daten zu erzeugen und basierend auf den Metriken zu bestimmen, ob die DTCs die Spezifikationen für die DTCs erfüllen.

Description

EINLEITUNG
Die in diesem Abschnitt bereitgestellten Informationen dienen dem Zweck der allgemeinen Darstellung des Kontexts der Offenbarung. Sowohl die Arbeit der gegenwärtig genannten Erfinder in dem Ausmaß, in dem sie in diesem Abschnitt beschrieben ist, als auch die Aspekte der Beschreibung, die sich zum Zeitpunkt des Einreichens nicht anderweitig als Stand der Technik qualifizieren können, werden weder ausdrücklich noch implizit als Stand der Technik gegenüber der vorliegenden Offenbarung anerkannt.
Die vorliegende Offenbarung bezieht sich im Allgemeinen auf bordinterne Diagnosesysteme von Fahrzeugen und insbesondere auf ein System und ein Verfahren zum Validieren von Diagnosefehlercodes, die durch die bordinternen Diagnosesysteme von Fahrzeugen erzeugt werden.
Eine bordinterne Diagnose (OBD) wird in verschiedenen in Fahrzeugen verwendeten Teilsystemen ausgeführt, um sicherzustellen, dass die Teilsysteme normal arbeiten, und um zu detektieren, ob in den Teilsystemen irgendwelche Störungen auftreten oder im Begriff sind, aufzutreten. Wenn eine Störung in einem Teilsystem auftritt oder im Begriff ist, aufzutreten, erzeugt die OBD für das Teilsystem einen Diagnosefehlercode (DTC). Der DTC wird typischerweise auf der Instrumententafel des Fahrzeugs angezeigt oder in Form einer Warnung dem Fahrer des Fahrzeugs in irgendeiner anderen geeigneten Weise (z. B. über eine audiovisuelle Angabe) bereitgestellt. Im Ergebnis kann der Fahrer basierend auf dem DTC eine geeignete Maßnahme ergreifen (z. B. eine Wartung planen). Der DTC kann das Wartungspersonal bei der Fehlersuche und beim Beheben der Störung unterstützen.
ZUSAMMENFASSUNG
Ein System zum Validieren von Diagnosefehlercodes (DTCs) in Fahrzeugen umfasst einen Prozessor und einen Speicher, der Anweisungen speichert, die, wenn sie durch den Prozessor ausgeführt werden, den Prozessor konfigurieren, DTC-Daten von den Fahrzeugen zu empfangen, die DTC-Daten unter Verwendung vorgegebener Regeln zu filtern, basierend auf den gefilterten DTC-Daten eine oder mehrere Metriken zu erzeugen und basierend auf den Metriken zu bestimmen, ob die DTCs den Spezifikationen für die DTCs entsprechen.
Gemäß weiteren Merkmalen ist der Prozessor konfiguriert, Probleme mit den DTCs basierend auf den Metriken und den vorgegebenen Regeln zu detektieren, die Probleme mit Software- und Kalibrierungsversionen, die verwendet werden, um die DTCs zu erzeugen, Fahrzeugidentifikationsnummern (VINs) der Fahrzeuge und Umgebungsvariable zu korrelieren und eine Grundursache für die Probleme mit den DTCs zu identifizieren.
Gemäß einem weiteren Merkmal ist der Prozessor konfiguriert, basierend auf der Korrelation mit den Software- und Kalibrierungsversionen eine Angabe hinsichtlich des Aktualisierens der Software- oder Kalibrierungsversionen bereitzustellen.
Gemäß einem weiteren Merkmal ist der Prozessor konfiguriert, basierend auf der Korrelation mit den VINs eine Angabe hinsichtlich der Wartung eines oder mehrerer der Fahrzeuge bereitzustellen.
Gemäß einem weiteren Merkmal ist der Prozessor konfiguriert, basierend auf der Korrelation mit den VINs eine Angabe hinsichtlich des Modifizierens von wenigstens einer der Software- oder Kalibrierungsversionen bereitzustellen.
Gemäß weiteren Merkmalen ist der Prozessor konfiguriert, die DTC-Daten basierend auf einem oder mehreren dessen zu filtern, ob die DTC-Daten von einem Testfahrzeug stammen, die Bedingungen, um die DTCs zu erzeugen, für jeden Fahrzyklus erfüllt sind, die DTCs zurückgesetzt wurden, nachdem die entsprechende Störung beseitigt wurde, die DTCs erzeugt werden, nachdem die Fahrzeuge während eines Zeitraums gefahren worden sind, und ob sich die Variable, die verwendet werden, um die Metriken zu erzeugen, innerhalb der jeweiligen Bereiche der Standardwerte befinden.
Gemäß weiteren Merkmalen ist eine der Metriken ein Verhältnis der Überwachungsleistung in Verwendung (IUMPR). Der Prozessor ist konfiguriert, darauf basierend, ob sich das IUMPR für den einen der DTCs innerhalb eines vorgegebenen Bereichs befindet, zu bestimmen, ob einer der DTCs einer entsprechenden Spezifikation entspricht.
Gemäß weiteren Merkmalen ist eine der Metriken ein Verhältnistyp, wobei der Prozessor konfiguriert ist, darauf basierend, ob sich ein Verhältnis einer Variable für den einen der DTCs zu einem entsprechenden Schwellenwert innerhalb einer vorgegebenen Grenze befindet, zu bestimmen, ob einer der DTCs einer entsprechenden Spezifikation entspricht.
Gemäß weiteren Merkmalen ist eine der Metriken ein statistischer Typ, wobei der Prozessor konfiguriert ist, darauf basierend, ob ein Mittelwert einer Variable für den einen der DTCs eine vorgegebene Anzahl von Standardabweichungen von einem entsprechenden Schwellenwert entfernt ist, zu bestimmen, ob einer der DTCs einer entsprechenden Spezifikation entspricht.
Gemäß weiteren Merkmalen ist der Prozessor so konfiguriert, Ausreißer in den Daten zu detektieren, die einer Variable entsprechen, die als Gütezahlvariable für einen der DTCs ausgewählt worden ist, die Ausreißer mit den Software- und Kalibrierungsversionen, die verwendet worden sind, um die DTCs zu erzeugen, den Fahrzeugidentifikationsnummern (VINs) der Fahrzeuge und den Umgebungsvariable zu korrelieren und eine Grundursache für die Probleme mit dem einen der DTCs zu identifizieren.
Gemäß noch anderen Merkmalen umfasst ein Verfahren zum Validieren von Diagnosestörungscodes (DTCs) in Fahrzeugen Empfangen von DTC-Daten von den Fahrzeugen, Filtern der DTC-Daten unter Verwendung vorgegebener Regeln, Erzeugen einer oder mehrerer Metriken basierend auf den gefilterten DTC-Daten und Bestimmen basierend auf den Metriken, ob die DTCs den Spezifikationen für die DTCs entsprechen.
Gemäß weiteren Merkmalen umfasst das Verfahren Detektieren von Problemen mit den DTCs basierend auf den Metriken und den vorgegebenen Regeln; Korrelieren der Probleme mit den Software- und Kalibrierungsversionen, die verwendet werden, um die DTCs zu erzeugen, den Fahrzeugidentifikationsnummern (VINs) der Fahrzeuge und den Umgebungsvariable; und Identifizieren einer Grundursache für die Probleme mit den DTCs.
Gemäß einem weiteren Merkmal umfasst das Verfahren ferner Bereitstellen einer Angabe hinsichtlich des Aktualisierens der Software- oder Kalibrierungsversionen basierend auf der Korrelation mit den Software- und Kalibrierungsversionen.
Gemäß einem weiteren Merkmal umfasst das Verfahren ferner Bereitstellen einer Angabe hinsichtlich der Wartung eines oder mehrerer der Fahrzeuge basierend auf der Korrelation mit den VINs.
Gemäß einem weiteren Merkmal umfasst das Verfahren ferner Bereitstellen einer Angabe hinsichtlich des Modifizierens von wenigstens einer der Software- oder Kalibrierungsversionen basierend auf der Korrelation mit den VINs.
Gemäß weiteren Merkmalen umfasst das Verfahren ferner Filtern der DTC-Daten basierend auf einem oder mehreren dessen, ob die DTC-Daten von einem Testfahrzeug stammen, die Bedingungen, um die DTCs zu erzeugen, für jeden Fahrzyklus erfüllt sind, die DTCs zurückgesetzt wurden, nachdem die entsprechende Störung beseitigt wurde, die DTCs erzeugt werden, nachdem die Fahrzeuge während eines Zeitraums gefahren worden sind, und ob sich die Variable, die verwendet werden, um die Metriken zu erzeugen, innerhalb der jeweiligen Bereiche der Standardwerte befinden.
Gemäß weiteren Merkmalen ist eine der Metriken ein Verhältnis der Überwachungsleistung in Verwendung (IUMPR). Das Verfahren umfasst ferner Bestimmen darauf basierend, ob sich das IUMPR für den einen der DTCs innerhalb eines vorgegebenen Bereichs befindet, ob einer der DTCs einer entsprechenden Spezifikation entspricht.
Gemäß weiteren Merkmalen ist eine der Metriken ein Verhältnistyp und umfasst das Verfahren ferner Bestimmen darauf basierend, ob sich ein Verhältnis einer Variable für den einen der DTCs zu einem entsprechenden Schwellenwert innerhalb einer vorgegebenen Grenze befindet, ob einer der DTCs einer entsprechenden Spezifikation entspricht.
Gemäß weiteren Merkmalen ist eine der Metriken ein statistischer Typ, wobei das Verfahren ferner Bestimmen darauf basierend, ob ein Mittelwert einer Variable für den einen der DTCs eine vorgegebene Anzahl von Standardabweichungen von einem entsprechenden Schwellenwert entfernt ist, ob einer der DTCs einer entsprechenden Spezifikation entspricht.
Gemäß weiteren Merkmalen umfasst das Verfahren ferner Detektieren von Ausreißern in den Daten, die einer Variable entsprechen, die als eine Gütezahlvariable für einen der DTCs ausgewählt worden ist; Korrelieren der Ausreißer mit den Software- und Kalibrierungsversionen, die verwendet worden sind, um die DTCs zu erzeugen, den Fahrzeugidentifikationsnummern (VINs) der Fahrzeuge und den Umgebungsvariable; und Identifizieren einer Grundursache für die Probleme mit dem einen der DTCs.
Weitere Anwendungsbereiche der vorliegenden Offenbarung werden aus der ausführlichen Beschreibung, den Ansprüchen und den Zeichnungen offensichtlich. Die ausführliche Beschreibung und die spezifischen Beispiele dienen nur der Veranschaulichung und sind nicht vorgesehen, den Schutzumfang der Offenbarung einzuschränken.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Offenbarung wird aus der ausführlichen Beschreibung und den beigefügten Zeichnungen vollständiger verstanden; es zeigen:

1 mehrere Teilsysteme eines Fahrzeugs, die unter Verwendung eines gesteuerten Bereichsnetzbusses (CAN-Busses) im Fahrzeug miteinander verbunden sind;
2 ein Beispiel eines verteilten Netzsystems, das mehrere Server und mehrere der in 1 gezeigten Fahrzeuge umfasst;
3 ein Beispiel eines Servers, der in dem verteilten Netzsystem nach 2 verwendet wird;
4 ein Verfahren zum Validieren von durch bordinterne Diagnosesysteme (ODS) in Fahrzeugen erzeugten Diagnosefehlercodes (DTCs) unter Verwendung des verteilten Netzsystems nach 2;
5 ein Verfahren zum Definieren von Regeln, die zum Validieren der DTCs verwendet werden;
6 ein Verfahren zum Filtern von DTC-Daten, die beim Validieren der DTCs verwendet werden;
7A und 7B Verfahren zum Erzeugen von Metriken, die beim Validieren der DTCs verwendet werden;
8A und 8B Verfahren zum Detektieren von Problemen mit den DTCs unter Verwendung der Metriken;
9A-9C Verfahren zum Korrelieren der detektierten Probleme mit der Software und/oder der Kalibrierung, die verwendet werden, um die DTCs zu erzeugen, den Fahrzeugidentifikationsnummern (VINs) und den Umgebungsvariable;
10 ein Verfahren zum Bestimmen der Grundursachen für die detektierten Probleme mit den DTCs; und
11 ein Verfahren zum Kategorisieren der detektierten Probleme mit den DTCs und zum Bereitstellen von Vorschlägen, um die detektierten Probleme mit den DTCs anzugehen.

In den Zeichnungen können Bezugszeichen mehrfach verwendet werden, um ähnliche und/oder völlig gleiche Elemente zu identifizieren.
AUSFÜHRLICHE BESCHREIBUNG
Die Leistung der Diagnosefehlercodes (DTCs) oder die Genauigkeit, mit der die DTCs die Status verschiedener Teilsysteme von Fahrzeugen angeben, kann sich auf die Emissionen, die Sicherheit und die Garantiekosten des Fahrzeugs auswirken. Jeder DTC wird durch ein bordinternes Diagnosesystem (OBD) unter Verwendung eines spezifischen Verfahrens erzeugt. Ein Verfahren zum Erzeugen eines DTC kann z. B. Überwachen einer oder mehrerer Variable eines Teilsystems, Ausführen einer oder mehrerer Berechnungen unter Verwendung der überwachten Variable, Vergleichen der Ergebnisse der Berechnungen mit jeweiligen Schwellenwerten und Erzeugen des DTC basierend auf den Vergleichen beinhalten. Die Schwellenwerte werden für einen speziellen Satz von Fahrzeugen während der Herstellung der Fahrzeuge empirisch kalibriert. Die Kalibrierungen berücksichtigen die meisten Bedingungen, denen die Fahrzeuge auf den Straßen begegnen können. Einige Bedingungen können jedoch einen DTC auslösen, wenn der DTC nicht ausgelöst werden sollte (falsch positiv). Umgekehrt können einige Bedingungen keinen DTC auslösen, wenn der DTC ausgelöst werden sollte (falsch negativ). Derartige Inkonsistenzen können nicht nur Anwender aufgrund von falsch positiven belästigen (z. B. durch das Erfordern einer unnötigen Wartung), sondern können außerdem die Fahrzeugemissionen, die Sicherheit und die OBD-Konformität aufgrund von falsch negativen beeinflussen (z. B. indem eine Störung, die eine Wartung erfordert, nicht detektiert wird).
Die vorliegende Offenbarung schafft ein System und ein Verfahren zum Sammeln von DTC-Daten von Fahrzeugen, zum Validieren der DTC-Daten und zum Bereitstellen verschiedener Angaben für die Fahrer, das Wartungspersonal und die Entwurfsingenieure, um die DTCs robust zu machen, so dass die falsch positiven und falsch negativen minimiert oder eliminiert werden können. Um die DTCs zu validieren und die DTCs robust zu machen, stellen das System und das Verfahren der vorliegenden Offenbarung den Ingenieuren DTC-Gütezahlen (DTC-FOMs) und Analysen des Verhältnisses der Überwachungsleistung in Verwendung (IUMPR-Analysen) bereit, um die OBD-Systeme zu kalibrieren. Das System und das Verfahren der vorliegenden Offenbarung werden im Folgenden gemeinsam als DTC-Validierungssystem bezeichnet.
Das DTC-Validierungssystem nimmt DTC-Daten auf, die manuell unter Verwendung eines OBD-Wartungswerkzeugs und automatisch unter Verwendung eines Fahrzeugdatenrekorders (VDR) an Bord eines Fahrzeugs gesammelt werden. Das DTC-Validierungssystem nimmt DTC-Daten von in Betrieb befindlichen Fahrzeugen und von Entwicklungsfahrzeugen auf. Das DTC-Validierungssystem filtert schlechte Abtastwerte (z. B. Ausreißer) aus den aufgenommenen Daten und detektiert und identifiziert DTC-Leistungsprobleme für eine Fahrzeugflotte durch Berechnen von DTC-Metriken und Vergleichen dieser mit den Entwurfszielen. Das DTC-Validierungssystem schlägt Korrekturmaßnahmen vor, die durch die Fahrer, das Wartungspersonal und die Entwurfsingenieuren ergriffen werden können.
Aktuelle Systeme filtern die von den Fahrzeugen gesammelten Daten manuell und berechnen die DTC-Metriken unter Verwendung von Approximationen, was diese Systeme langsam und fehleranfällig macht. Die Geschwindigkeit dieser Systeme wird weiter verringert, weil in diesen Systemen Datenkorrelationen manuell ausgeführt werden und einzelne Rohdatendateien manuell untersucht werden, um Anomalien zu detektieren. Im Gegensatz filtert das DTC-Validierungssystem der vorliegenden Offenbarung automatisch schlechte Abtastwerte (z. B. Ausreißer), wobei es die DTC-Probleme unter Verwendung von auf Physik und maschinellem Lernen basierenden Modellen schnell detektiert, wie im Folgenden ausführlich erklärt wird.
Das DTC-Validierungssystem filtert z. B. automatisch Datenabtastwerte mit Verzerrungen und Rauschen, was das DTC-System robust macht und eine genaue Detektion und Identifikation von DTC-Problemen ermöglicht. Das DTC-Validierungssystem führt außerdem eine umfassende Korrelationsanalyse der detektierten DTC-Probleme mit Umgebungsvariable aus. Das DTC-Validierungssystem stellt den Fahrern, dem Wartungspersonal und Ingenieuren Handlungsanweisungen hinsichtlich zu ergreifender Maßnahmen und/oder Reparaturen elektronisch bereit, die anzuwenden sind, um die detektierten DTC-Probleme zu lösen.
Folglich verbessert das DTC-Validierungssystem der vorliegenden Offenbarung das technische Gebiet der OBD-Systeme in der Automobilindustrie. Ferner sind die Lehren des DTC-Validierungssystems auf andere Typen von Fahrzeugen anwendbar, einschließlich, aber nicht eingeschränkt auf Luftfahrzeuge, Wohnmobile, Erdbaumaschinen und irgendwelche anderen Geräte, wie z. B. Geräte, die sich auf OBD und DTCs stützen.
Die vorliegende Offenbarung ist wie folgt organisiert. Anfangs ist ein System, das mehrere Teilsysteme eines Fahrzeugs enthält, bezüglich 1 gezeigt und beschrieben, um eine OBD und DTCs einzuführen. Ein verteiltes Netzsystem, das mehrere Fahrzeuge und einen oder mehrere Server umfasst, die konfiguriert sind, das DTC-Validierungssystem der vorliegenden Offenbarung zu implementieren, ist in den 2 und 3 gezeigt und wird bezüglich der 2 und 3 beschrieben. Die verschiedenen Verfahren, die durch das DTC-Validierungssystem der vorliegenden Offenbarung zum Validieren der DTCs ausgeführt werden, sind in den 4-11 gezeigt und werden bezüglich der 4-11 beschrieben. Eine Validierung eines DTC, wie sie hier verwendet wird, bedeutet das Bestätigen, dass der DTC den spezifizierten Anforderungen entspricht.
In Fahrzeugen sind Steuersysteme, die verwendet werden, um verschiedene Teilsysteme zu steuern, typischerweise als elektronische Steuereinheiten (ECUs) implementiert. Die ECUs sind über einen Controller-Bereichsnetz-Bus (CAN-Bus) miteinander verbunden. Jede ECU steuert ein spezifisches Teilsystem (z. B. Kraftmaschine, Getriebe, Abgasanlage, Bremsen, Heizung und Kühlung, Infotainment, Navigation usw.) des Fahrzeugs. Jede ECU enthält einen Mikrocontroller, einen CAN Controller und einen Sender/Empfänger. In jeder ECU enthält der Mikrocontroller einen Prozessor, einen Speicher und andere Schaltungen, um das spezifische Teilsystem zu steuern. Jede ECU kann mit anderen ECUs über den CAN-Bus durch den CAN-Controller und den Sender/Empfänger kommunizieren.
1 zeigt ein Beispiel eines Fahrzeugs 10, das mehrere ECUs umfasst, die über einen CAN-Bus miteinander verbunden sind. Die mehreren ECUs enthalten die ECU-1 12-1, ..., und die ECU-N 12-N (gemeinsam die ECUs 12), wobei N eine ganze Zahl größer als eins ist. Im Folgenden bezieht sich die ECU 12 auf irgendeine der mehreren ECUs 12. Während 1 einen ausführlichen Funktionsblockschaltplan nur der ECU-N 12-N zeigt, weisen andere ECUs 12 eine zu der ECU-N 12-N ähnliche Struktur auf. Jede ECU 12 oder irgendein Abschnitt davon kann als ein oder mehrere Module implementiert sein.
Jede ECU 12 steuert ein jeweiliges Teilsystem des Fahrzeugs 10. Die ECU-1 12-1 steuert z. B. ein Teilsystem 14-1, die ECU-1 12-2 steuert ein Teilsystem 14-2, ..., und die ECU-N 12-N steuert ein Teilsystem 14-N. Die Teilsysteme 14-1, 14-2, ..., und 14-N werden gemeinsam als die Teilsysteme 14 bezeichnet. Nicht einschränkende Beispiele der Teilsysteme 14 enthalten ein Kraftmaschinen-Teilsystem, ein Getriebe-Teilsystem, ein Abgas-Teilsystem, ein Brems-Teilsystem, ein Traktions-Teilsystem, ein Aufhängungs-Teilsystem, ein Sicherheits-Teilsystem, ein Infotainment-Teilsystem, ein Navigations-Teilsystem, ein Kommunikations-Teilsystem, ein Erfassungs-Teilsystem physiologischer Daten, ein Klimatisierungs-Teilsystem usw.
Jedes Teilsystem 14 kann einen oder mehrere Sensoren enthalten, um Daten von einer oder mehreren Komponenten des Teilsystems 14 abzutasten. Ferner kann jedes Teilsystem 14 einen oder mehrere Aktuatoren enthalten, um eine oder mehrere Komponenten des Teilsystems 14 zu betätigen. Eine ECU 12 kann Daten von einem oder mehreren Sensoren eines entsprechenden Teilsystems 14 empfangen. Abhängig vom Typ des Teilsystems 14 kann die ECU 12 außerdem eine oder mehrere Eingaben von einem Insassen des Fahrzeugs 10 empfangen. Die ECU 12 kann einen oder mehrere Aktuatoren des entsprechenden Teilsystems 14 basierend auf den von dem einen oder den mehreren Sensoren empfangenen Daten und/oder der einen oder den mehreren Eingaben von einem Insassen des Fahrzeugs 10 steuern.
Die ECUs 12 sind mit einem CAN-Bus 16 verbunden. Die ECUs 12 können über den CAN-Bus 16 miteinander kommunizieren. Die ECUs 12 können mit anderen Vorrichtungen, die mit dem CAN-Bus 16 verbunden sind, (z. B. einem Testgerät, einem Kommunikations-Gateway usw.) kommunizieren. Jede ECU 12 enthält einen Mikrocontroller 20 und einen CAN-Sender/Empfänger 22. Der Mikrocontroller 20 kommuniziert mit dem durch die ECU 12 gesteuerten Teilsystem 14. Der CAN-Sender/Empfänger 22 kommuniziert mit dem CAN-Bus 16 und sendet und empfängt Daten auf dem CAN-Bus 16.
Der Mikrocontroller 20 enthält einen Prozessor 30, einen Speicher 32, einen CAN-Controller 34 und eine Leistungsversorgung 36. Der Speicher 32 enthält flüchtigen Speicher (RAM) und kann zusätzlich nichtflüchtigen Speicher (z. B. Flash-Speicher) und/oder einen anderen Typ von Datenspeichervorrichtung(en) enthalten. Der Prozessor 30 und der Speicher 32 kommunizieren über einen Bus 38 miteinander. Der Prozessor 30 führt im Speicher 32 gespeicherten Code aus, um das Teilsystem 14 zu steuern. Der Code kann z. B. eine bordinterne Diagnose (OBD) enthalten, um das Teilsystem 14 zu diagnostizieren. Die Leistungsversorgung 36 führt allen Komponenten des Mikrocontrollers 20 und der ECU 12 Leistung zu. Der CAN-Controller 34 kommuniziert mit dem CAN-Sender/Empfänger 22.
Der Prozessor 30 kann die OBD am Teilsystem 14 ausführen und kann einen oder mehrere Diagnosefehlercodes (DTCs) erzeugen, die den Betriebsstatus des Teilsystems 14 angeben. Die OBD und irgendwelche Sensoren des Teilsystems 14 werden kalibriert, wenn das Fahrzeug 10 hergestellt wird. Die Teilsysteme 14 können ein Kommunikations-Teilsystem (z. B. das Teilsystem 14-1) enthalten. Das Kommunikations-Teilsystem 14-1 kann einen oder mehrere Sender/Empfänger für die drahtlose (z. B. Zellen-, WiFi- usw.) Kommunikation, ein GPS-System für die Navigation usw. enthalten, um mit einem verteilten Kommunikationssystem 110 zu kommunizieren. Das Kommunikations-Teilsystem 14-1 kann DTC-Daten über das verteilte Kommunikationssystem 110 zu dem DTC-Validierungssystem übertragen, das in einem oder mehreren (in 2 gezeigten) Servern in einer Cloud implementiert ist. Das Kommunikations-Teilsystem 14-1 kann Software-Aktualisierungen (z. B. für die OBD) vom DTC-Validierungssystem über das verteilte Kommunikationssystem 110 empfangen.
Die Teilsysteme 14 können außerdem ein Infotainment-Teilsystem (z. B. das Teilsystem 14-N) enthalten. Das Infotainment-Teilsystem 14-N kann einen Funkempfänger, einen Satellitenempfänger und eine oder mehrere Anzeigen einschließlich einer Anzeigekonsole auf der Instrumententafel des Fahrzeugs 10 und mehrerer Anzeigen einschließlich Berührungsschirmen für die Insassen des Fahrzeugs 10 enthalten, während dies nicht gezeigt ist. Das Infotainment-Teilsystem 14-N kann audiovisuelle Multimedia-Teilsysteme und eine Mensch-Maschine-Schnittstelle (HMI) enthalten, die es den Insassen des Fahrzeugs 10 ermöglicht, mit einem oder mehreren der Teilsysteme 14 zu interagieren. Das Infotainment-Teilsystem 14-N kann den Insassen des Fahrzeugs 10 audiovisuelle Angaben zu den DTCs bereitstellen. Außerdem kann das Infotainment-Teilsystem 14-N den Insassen des Fahrzeugs 10 über die HMI Warnungen und/oder Meldungen bereitstellen, die von dem DTC-Validierungssystem empfangen worden sind.
2 zeigt ein vereinfachtes Beispiel eines verteilten Netzsystems 100. Das verteilte Netzsystem 100 enthält das verteilte Kommunikationssystem 110. Das verteilte Netzsystem 100 enthält einen oder mehrere Server 130-1, 130-2, ..., und 130-N (gemeinsam die Server 130); und ein oder mehrere Fahrzeuge 140-1, 140-2, ..., und 140-P (gemeinsam die Fahrzeuge 140), wobei N und P positive ganze Zahlen sind. Die Server 130 können sich z. B. in einer Cloud befinden. Das verteilte Kommunikationssystem 110 kann ein Zellennetz, ein satellitengestütztes Kommunikationsnetz, ein Wi-Fi-Netz, das Internet oder einen anderen Typ von Netz enthalten. Die Server 130 können mit dem verteilten Kommunikationssystem 110 unter Verwendung von drahtlosen und/oder drahtgebundenen Verbindungen verbunden sein.
Die Server 130 implementieren das DTC-Validierungssystem der vorliegenden Offenbarung, das im Folgenden bezüglich der 4-11 ausführlich beschrieben wird. Jedes Fahrzeug 140 ist zu dem oben beschriebenen Fahrzeug 10 ähnlich und umfasst die ECUs 12 und die in 1 gezeigten Teilsysteme 14. Überall in der vorliegenden Offenbarung sind die Kommunikationen mit und durch die Fahrzeuge 140 als Kommunikationen mit den ECUs 12 und den Teilsystemen 14 in den Fahrzeugen 140 zu verstehen. In jedem Fahrzeug 140 kann z. B. das Kommunikations-Teilsystem (z. B. das Teilsystem 14-1) über das verteilte Kommunikationssystem 110 mit dem in den Servern 130 implementierten DTC-Validierungssystem kommunizieren.
3 zeigt ein vereinfachtes Beispiel der Server 130 (z. B. den Server 130-1). Der Server 130-1 enthält typischerweise eine oder mehrere CPUs oder Prozessoren 170, eine oder mehrere Eingabevorrichtungen 172 (z. B. eine Kleintastatur, ein Tastfeld, eine Maus usw.), ein Anzeige-Teilsystem 174, das eine Anzeige 172 enthält, eine Netzschnittstelle 178, einen Speicher 180 und einen Massenspeicher 182. Die Netzschnittstelle 178 verbindet den Server 130-1 über das Netz 110 mit dem verteilten Netzsystem 100. Die Netzschnittstelle 178 kann z. B. eine drahtgebundene Schnittstelle (z. B. eine Ethernet-Schnittstelle) und/oder eine drahtlose Schnittstelle (z. B. eine Wi-Fi-, Bluetooth-, Nahfeldkommunikations- (NFC-), Zellen- oder eine andere drahtlose Schnittstelle) enthalten. Der Speicher 180 kann flüchtigen oder nichtflüchtigen Speicher, einen Cache oder einen anderen Typ von Speicher enthalten. Der Massenspeicher 182 kann einen Flash-Speicher, ein oder mehrere Festplattenlaufwerke (HDDs) oder eine andere Massenspeichervorrichtung enthalten.
Der Prozessor 170 des Servers 130-1 kann ein Betriebssystem (OS) 184 und eine oder mehrere Server-Anwendungen 186 ausführen. Die Server-Anwendungen 186 können eine Anwendung enthalten, die die im Folgenden beschriebenen Verfahren zum Ausführen der DTC-Validierung gemäß der vorliegenden Offenbarung implementiert. Der Massenspeicher 182 kann eine oder mehrere Datenbanken 188 speichern, die Datenstrukturen speichern, die durch die Server-Anwendungen 186 verwendet werden, um die jeweiligen Funktionen auszuführen. Der (die) Server 130 und die Server-Anwendungen 186, die eine oder mehrere Anwendungen enthalten, die die im Folgenden bezüglich der 4-11 gezeigten und beschriebenen Verfahren zum Ausführen der DTC-Validierung implementieren, bilden das DTC-Validierungssystem gemäß der vorliegenden Offenbarung.
Überall in der vorliegenden Offenbarung sind Verweise auf Begriffe, wie z. B. Server, Anwendungen usw., nur für Veranschaulichungszwecke. Der Begriff Server ist umfassend als eine Rechenvorrichtung repräsentierend zu verstehen, die einen oder mehrere Prozessoren und einen Speicher umfasst, der konfiguriert ist, maschinenlesbare Anweisungen auszuführen. Die Begriffe Anwendungen und Computerprogramme sind umfassend als maschinenlesbare Anweisungen repräsentierend zu verstehen, die durch die Rechenvorrichtungen ausführbar sind.
4 zeigt ein Verfahren 200 zum Ausführen einer DTC-Validierung gemäß der vorliegenden Offenbarung. Bei 202 definiert das Verfahren 200 Regeln, um die Leistung von DTCs zu bewerten, die durch eine Fahrzeugflotte erzeugt werden können. Ein Verfahren zum Definieren der Regeln unter Verwendung der Variable, die in den Regeln verwendet werden, und anderer Parameter, einschließlich Schwellenwerten, Filter, Grenzen usw., aber nicht darauf eingeschränkt, die bei der DTC-Validierung verwendet werden, ist in 5 gezeigt und wird bezüglich 5 ausführlich beschrieben.
Bei 203 importiert das Verfahren 200 variable Informationen für die DTCs. Bei 204 nimmt das Verfahren 200 die DTC-Daten von den Fahrzeugen auf. Bei 206 filtert das Verfahren 200 vorzeitige DTC-Abtastwerte aus den aufgenommenen DTC-Daten unter Verwendung der Regeln. Der Filterungsprozess ist in 6 gezeigt und wird bezüglich 6 ausführlich beschrieben.
Bei 208 erzeugt das Verfahren 200 Metriken für einen DTC unter Verwendung der Regeln. Die Metrikerzeugung ist in den 7A und 7B gezeigt und wird bezüglich der 7A und 7B ausführlich beschrieben. Bei 210 detektiert das Verfahren 200 Probleme mit dem DTC unter Verwendung der Regeln. Die Problemdetektion ist in den 8A und 8B gezeigt und wird bezüglich der 8A und 8B ausführlich beschrieben.
Bei 212 bestimmt das Verfahren 200, ob ein Problem mit dem DTC detektiert wird. Falls kein Problem mit dem DTC detektiert wird, bestimmt das Verfahren 200 bei 214, dass der DTC die Anforderungen erfüllt (d. h., das Verfahren genehmigt oder validiert den DTC als den Anforderungen entsprechend), wobei das Verfahren 200 endet. Ein DTC entspricht den Anforderungen, wenn der DTC ein Problem richtig angibt, für das der DTC entworfen ist, um es anzuzeigen. Dementsprechend gibt das Entsprechen der Anforderungen an, dass der DTC richtig erzeugt wird (d. h., dass Prozeduren, wie z. B. Kalibrierung, Abtasten von Daten, Verarbeiten von Daten, Schwellenwertvergleiche usw., die verwendet werden, um den DTC zu erzeugen, gemäß der Spezifikation arbeiten, ohne falsch positive und falsch negative zu erzeugen).
Falls jedoch ein Problem mit dem DTC detektiert wird, korreliert das Verfahren 200 bei 216 das detektierte Problem oder die detektierten Probleme mit der Software-Version und/oder der Kalibrierung, die verwendet werden, um den DTC zu erzeugen, einer Fahrzeugkennung (z. B. einer Fahrzeugidentifikationsnummer oder VIN) und den Umgebungsvariable (z. B. der Umgebungstemperatur, den Wetterbedingungen, den Straßenbedingungen usw.). Die Korrelationsverfahren sind in den 9A-10 gezeigt und werden bezüglich der 9A-10 ausführlich beschrieben.
Bei 218 kategorisiert das Verfahren 200 den Typ des Problems mit dem DTC, so dass eine geeignete Korrekturmaßnahme ergriffen werden kann (z. B. Aktualisieren der Software und/oder der Kalibrierung, die verwendet werden, um den DTC zu erzeugen, Kompensieren der Umgebungsvariable, Planen der Hardware-Wartung usw.). Das Verfahren zum Kategorisieren des Typs des Problems und zum Vorschlagen von Korrekturmaßnahmen, um das Problem anzugehen, ist in 11 gezeigt und wird bezüglich 11 ausführlich beschrieben.
5 zeigt den Schritt 202 des Verfahrens 200 (d. h., ein Verfahren zum Definieren der Regeln einschließlich der in den Regeln verwendeten Variable und anderer Parameter, wie z. B. Schwellenwerte, Filter, Grenzen usw., die bei der DTC-Validierung verwendet werden) ausführlicher. Bei 230 spezifiziert das Verfahren 200 die Variable, die (z. B. in Gleichungen) verwendet werden, um jeden DTC für eine Fahrzeugflotte zu berechnen. Zusätzlich spezifiziert das Verfahren 200 andere Parameter, einschließlich Schwellenwerten, Filter, Grenzen usw., aber nicht darauf eingeschränkt, die bei der weiteren Verarbeitung der DTC-Daten verwendet werden, wie bezüglich der 6-11 für jeden DTC beschrieben wird. Bei 232 spezifiziert das Verfahren 200 Filterkriterien zum Filtern der aufgenommenen DTC-Daten für jeden DTC. Der unter Verwendung der Filterkriterien ausgeführte Filterungsprozess ist in 6 gezeigt und wird bezüglich 6 ausführlich beschrieben.
Bei 234 spezifiziert das Verfahren 200 Schwellenwerte zum Berechnen einer Gütezahl (FOM) für jeden DTC. Die Verfahren zum Berechnen der FOMs sind in den 7A und 7B gezeigt und werden bezüglich der 7A und 7B ausführlich beschrieben. Bei 236 spezifiziert das Verfahren 200 die Grenzen zum Detektieren von Problemen für jeden DTC. Die Verfahren zum Detektieren von Problemen mit den DTCs sind in den 8A und 8B gezeigt und werden bezüglich der 8A und 8B ausführlich beschrieben. Bei 238 spezifiziert das Verfahren ein abgestuftes Meldeschema zum Melden detektierter Probleme mit den DTCs. Ein Meldeverfahren ist in 11 gezeigt und wird bezüglich 11 ausführlich beschrieben.
6 zeigt den Schritt 206 des Verfahrens 200 (d. h., ein Verfahren zum Filtern vorzeitiger DTC-Abtastwerte) ausführlicher. Bei 252 bestimmt das Verfahren 200, ob die aufgenommenen Daten von einer Testfahrt eines Fahrzeugs (z. B. einer durch das Fahrzeug mit Fehlereinfügung zu Diagnosebewertungszwecken ausgeführten Fahrt) stammen. Falls ja, verwirft das Verfahren 200 bei 262 die aufgenommenen Daten, weil das Analysieren derartiger Daten das tatsächliche Verhalten eines DTC nicht widerspiegelt und deshalb nicht zum Validieren des DTC verwendet werden kann. Falls nein, geht das Verfahren 200 zu 252 weiter.
Bei 252 bestimmt das Verfahren 200, ob die Bedingungen zum Freigeben der Erzeugung eines DTC für jede durch das Fahrzeug ausgeführte Fahrt erfüllt sind, (d. h., ob ein DTC bei jeder durch das Fahrzeug ausgeführten Fahrt konsistent erzeugt wird). Falls nein, verwirft das Verfahren 200 bei 262 die aufgenommenen Daten. Falls ja, geht das Verfahren 200 zu 254 weiter.
Bei 254 bestimmt das Verfahren 200, ob der DTC zurückgesetzt wurde, nachdem eine hardware-bezogene Störung oder eine injizierte Störung beseitigt wurde, (d. h., ob ein DTC, der aufgrund einer früheren Bedingung gesetzt wurde, nicht weiter besteht). Falls nein, verwirft das Verfahren 200 bei 262 die aufgenommenen Daten. Falls ja, geht das Verfahren 200 zu 256 weiter.
Bei 256 bestimmt das Verfahren 200, ob das Fahrzeug während einer ausreichenden Zeit gefahren worden ist, um zu ermöglichen, dass die Daten sich entwickeln. Ein Abgassystem eines Fahrzeugs kann z. B. Zeit benötigen, um nach einem Kaltstart warmzulaufen, bevor ein basierend auf den Daten von dem Abgassystem erzeugter DTC gültig sein kann. Falls nein, verwirft das Verfahren 200 bei 262 die aufgenommenen Daten. Falls ja, geht das Verfahren 200 zu 258 weiter.
Bei 258 bestimmt das Verfahren 200, ob sich die FOM-Variable für den DTC nicht innerhalb eines vorgegebenen Bereichs von Standardwerten befinden. Falls nein, verwirft das Verfahren 200 bei 262 die aufgenommenen Daten. Falls ja, geht das Verfahren 200 zu 260 weiter. Bei 260 behält das Verfahren 200 nach dem Filtern der aufgenommenen Daten, wie in den Schritten 250 bis 258 beschrieben worden ist, die gefilterten Daten für die weitere Verarbeitung, wie in 7A weiter gezeigt ist.
Die 7A und 7B zeigen den Schritt 208 des Verfahrens 200 (d. h., die Verfahren der Metrikerzeugung unter Verwendung der gefilterten Daten aus dem in 6 gezeigten Schritt 260) ausführlicher. 7A zeigt die Berechnung einer Metrik, die als ein Verhältnis der Überwachungsleistung in Verwendung (IUMPR) bezeichnet wird, als einen Schritt 208-1, der Teil des Schritts 208 ist. 7B zeigt Berechnungen der Metriken, die FOM-Verhältnis und FOM-Sigma genannt werden, als einen Schritt 208-2, der außerdem Teil des Schritts 208 ist.
In 7A wählt das Verfahren 200 bei 280 einen DTC und die zugehörigen gefilterten Daten aus, die aus der in 6 ausgeführten Filterung erhalten werden. Bei 282 bestimmt das Verfahren 200 unter Verwendung eines Satzes vorgegebener Filter (die z. B. definiert sind, wie bezüglich 5 beschrieben worden ist), ob Daten aus den Fahrten in der Metrikberechnung enthalten sein sollten.
Bei 284 bestimmt das Verfahren 200 für jeden DTC einen Zähler, der die Anzahl ist, wie oft ein Fahrzeug betrieben worden ist, so dass auf alle Überwachungsbedingungen getroffen worden ist, die erforderlich sind, dass eine spezifische Überwachungsvorrichtung eine Fehlfunktion detektiert. Bei 286 berechnet das Verfahren 200 ein Verhältnis des Zählers zu einem Nenner, wobei der Nenner ein Zähler ist, der bei einem speziellen Fahrzyklus inkrementiert wird, falls definierte Bedingungen für einen Standardfahrzyklus erfüllt worden sind.
Bei 288 vergleicht das Verfahren 200 das Verhältnis mit einem vorgegebenen Schwellenwert und bestimmt, ob das IUMPR ausreichend ist, (d. h., ob der DTC der IUMPR-Anforderung entspricht). Ein Verhältniswert von kleiner als 1 (z. B. 0,336) wird z. B. als ausreichend betrachtet. Die Angemessenheit des IUMPR-Wertes basiert auf der vorgeschriebenen Anzahl, in der eine Diagnose gemäß den Vorschriften ausgeführt werden soll, und der tatsächlichen Anzahl, in der die Diagnose ausgeführt wird. Dementsprechend ist ein sehr niedriger Wert (z. B. kleiner als 0,336) des Verhältnisses nicht ausreichend, um der IUMPR-Anforderung zu entsprechen.
In 7B bestimmt das Verfahren 200 bei 300 unter Verwendung eines Satzes vorgegebener Filter (die z. B. definiert sind, wie bezüglich 5 beschrieben worden ist), ob Daten aus den Fahrten in der Metrikberechnung enthalten sein sollen. Bei 302 wählt das Verfahren 200 eine FOM-Variable und einen Schwellenwert für einen DTC aus der Regel für den DTC aus (die z. B. definiert ist, wie bezüglich 5 beschrieben worden ist).
Bei 304 bestimmt das Verfahren 200 aus den Regeln, die definiert sind, wie bezüglich 5 beschrieben worden ist, ob der FOM-Typ für den DTC als ein Verhältnis oder als ein statistischer Parameter Sigma definiert ist. Das Verfahren 200 geht zu 306 weiter, falls der FOM-Typ für den DTC als ein Verhältnis definiert ist. Das Verfahren 200 geht zu 308 weiter, wenn der FOM-Typ für den DTC als ein statistischer Parameter Sigma definiert ist.
Bei 306 verwendet das Verfahren 200 den Wert der FOM-Variable aus den gefilterten Daten und berechnet ein Verhältnis der FOM-Variable zu dem entsprechenden Schwellenwert. Das Verfahren 200 verarbeitet das Verhältnis, wie im Folgenden bezüglich 8A beschrieben wird. Bei 308 verwendet das Verfahren 200 die Werte der FOM-Variable aus den gefilterten Daten und berechnet einen Mittelwert der FOM-Variable. Das Verfahren 200 bestimmt eine Anzahl von Sigmas (Standardabweichungen), um die der Mittelwert vom Schwellenwert entfernt ist. Das Verfahren 200 verarbeitet den Mittelwert, wie im Folgenden bezüglich 8B beschrieben wird.
Die 8A und 8B zeigen den Schritt 210 des Verfahrens 200, (d. h., der Verfahren zur Problemdetektion basierend auf den berechneten Metriken, wie bezüglich der 7A und 7B beschrieben worden ist) ausführlicher. 8A zeigt die Problemdetektion basierend auf dem in 7A gezeigten berechneten Verhältnis als einen Schritt 210-1, der Teil des Schritts 210 ist. 8B zeigt die Problemdetektion basierend auf der in 7B gezeigten Sigma-Berechnung als einen Schritt 210-2, der außerdem Teil des Schritts 210 ist.
In 8A bestimmt das Verfahren 200 bei 320, ob das Verhältnis, das berechnet wird, wie bezüglich 7A beschrieben worden ist, kleiner als oder gleich einem vorgegebenen Schwellenwert ist, (der z. B. in den Regeln definiert ist, wie sie bezüglich 5 beschrieben worden sind). Das Verhältnis kann z. B. ein Typ-1-Verhältnis für einen falsch positiven DTC und ein Typ-2-Verhältnis für einen falsch negativen DTC sein. In jedem Fall kann das Verhältnis auf einen Wert zwischen 0 und 1 normiert werden. Ein niedriger Wert des Verhältnisses (z. B. näher bei 0 als bei 1) gibt an, dass die DTC-Daten zuverlässig sind.
Falls das Verhältnis kleiner als oder gleich dem vorgegebenen Schwellenwert ist, bestimmt das Verfahren 200 bei 322, dass sich die FOM-Daten für den DTC innerhalb einer Grenze befinden, (die z. B. in den Regeln definiert ist, wie sie bezüglich 5 beschrieben worden sind). Bei 324 bestimmt das Verfahren 200, dass die OBD für den DTC die Anforderungen erfüllt.
Falls jedoch das Verhältnis nicht kleiner oder gleich dem vorgegebenen Schwellenwert ist, bestimmt das Verfahren 200 bei 326, dass sich die FOM-Daten für den DTC nicht innerhalb der Grenze befinden, (d. h., sich außerhalb der Grenze befinden). Bei 328 bestimmt das Verfahren 200, dass die OBD für den DTC die Anforderungen nicht erfüllt.
In 8B bestimmt das Verfahren 200 bei 340, ob die Anzahl der Sigmas, die bestimmt werden, wie bezüglich 8B beschrieben worden ist, einem Zielwert (der z. B. in den Regeln, die bezüglich 5 beschrieben worden sind, definiert ist), entspricht. Die Anzahl der Sigmas kann z. B. größer als oder gleich 4 Sigmas für den Typ 1 (falsch positiver DTC) und größer als oder gleich 2 Sigmas für Typ 2 (falsch negativer DTC) sein. In jedem Fall kann das Verhältnis auf einen Wert zwischen 0 und 1 normiert werden.
Falls die bestimmte Anzahl der Sigmas dem Zielwert entspricht, bestimmt das Verfahren 200 bei 342, dass sich die FOM-Daten für den DTC innerhalb einer Grenze (die z. B. in den Regeln definiert ist, wie sie bezüglich 5 beschrieben worden sind), befinden. Bei 344 bestimmt das Verfahren 200, dass die OBD für den DTC die Anforderungen erfüllt.
Falls jedoch die bestimmte Anzahl der Sigmas nicht dem Zielwert entspricht, bestimmt das Verfahren 200 bei 326, dass sich die FOM-Daten für den DTC nicht innerhalb der Grenze befinden, (d. h. sich außerhalb der Grenze befinden). Bei 348 bestimmt das Verfahren 200, dass die OBD für den DTC die Anforderungen nicht erfüllt.
Die 9A-9C und 10 zeigen den Schritt 216 des Verfahrens 200 (d. h., Verfahren zum Korrelieren des detektierten Problems oder der detektierten Probleme mit der Software-Version und/oder der Kalibrierung, der VIN und den Umgebungsvariable) ausführlicher. 9A zeigt die Korrelation mit der Software-Version als einen Schritt 216-1, der Teil des Schritts 216 ist. 9B zeigt die Korrelation mit der VIN als einen Schritt 216-2, der Teil des Schritts 216 ist. 9C zeigt die Korrelation mit Umgebungsvariable als einen Schritt 216-2, der Teil des Schritts 216 ist. 10 zeigt die Korrelation von Ausreißerdaten mit diesen Faktoren als einen Schritt 216-4, der außerdem Teil des Schritts 216 ist.
In 9A bestimmt das Verfahren 200 bei 360, ob sich die FOM-Daten für den DTC außerhalb der Grenze, (wie sie im Schritt 326 in 8A oder im Schritt 346 in 8B bestimmt worden ist), befinden. Falls sich die FOM-Daten für den DTC außerhalb der Grenze befinden, filtert das Verfahren 200 bei 362 die FOM-Daten basierend auf der Software-Version oder der Kalibrierungsversion, die verwendet wird, um den DTC zu erzeugen. Bei 364 identifiziert das Verfahren 200 die Software-Version oder die Kalibrierungsversion, die die Probleme mit dem DTC verursacht.
In 9B bestimmt das Verfahren 200 bei 380, ob sich die FOM-Daten für den DTC außerhalb der Grenze (wie sie im Schritt 326 nach 8A oder im Schritt 346 nach 8B bestimmt wird) befinden. Falls sich die FOM-Daten für den DTC außerhalb der Grenze befinden, filtert das Verfahren 200 bei 382 die FOM-Daten basierend auf der VIN. Bei 364 identifiziert das Verfahren 200 das Fahrzeug oder die Fahrzeuge, die Probleme mit dem DTC aufweisen.
In 9C bestimmt das Verfahren 200 bei 400, ob sich die FOM-Daten für den DTC außerhalb der Grenze (wie sie im Schritt 326 nach 8A oder im Schritt 346 nach 8B bestimmt worden ist) befinden. Falls sich die FOM-Daten für den DTC außerhalb der Grenze befinden, bestimmt das Verfahren 200 bei 402, ob die Probleme mit dem DTC auf die Software- oder Kalibrierungsversionen (die bestimmt werden, wie bezüglich 9A beschrieben worden ist) oder die VIN (die bestimmt wird, wie bezüglich 9B beschrieben worden ist) zurückzuführen sind. Falls die Probleme mit dem DTC weder auf die Software- oder Kalibrierungsversionen noch auf die VIN zurückzuführen sind, korreliert das Verfahren 200 bei 404 die FOM-Daten des DTC mit einer oder mehreren Umgebungsvariable (z. B. der Umgebungstemperatur, einer Straßenunebenheit usw.). Bei 406 identifiziert das Verfahren 200 die Umgebungsvariable mit der höchsten Korrelation als die Probleme mit dem DTC verursachend.
In 10 gibt das Verfahren 200 bei 420 die FOM-Daten für einen DTC in einen auf maschinellem Lernen basierende Ausreißerdetektor ein. Bei 422 bestimmt das Verfahren 200, ob irgendwelche Ausreißer in den FOM-Daten für den DTC detektiert werden. Falls irgendwelche Ausreißer detektiert werden, korreliert das Verfahren 200 bei 424 die Ausreißer mit den Software- oder Kalibrierungsversionen, den VINs und den Umgebungsvariable. Bei 426 bestimmt das Verfahren 200, ob eine starke Korrelation zwischen den Ausreißern und irgendeinem der Faktoren besteht, die die Software- oder Kalibrierungsversion, die VIN und die Umgebungsvariable enthalten. Falls ja, bestimmt oder identifiziert das Verfahren 300 bei 430 die Grundursache oder die Grundursachen für die Ausreißer basierend auf den Faktoren, mit denen die Ausreißer die stärkste (höchste) Korrelation aufweisen.
11 zeigt den Schritt 218 des Verfahrens 200 (d. h., ein Verfahren zum Kategorisieren des Typs des DTC-Problems und zum Vorschlagen von Korrekturmaßnahmen) ausführlicher. Bei 440 stellt das Verfahren 200 sicher, dass die in 5 definierten Regeln und zugehörigen Parameter (z. B. Schwellenwerte, Filter, Grenzen usw.) (z. B. aus der Entwurfs- und Technikperspektive) richtig sind. Bei 442 bestimmt das Verfahren 200 (basierend auf der bezüglich der 9A-10 beschriebenen Korrelation), ob das Problem mit dem DTC auf eine spezielle Software-Version oder Kalibrierungsversion zurückzuführen ist. Falls ja, aktualisiert das Verfahren 200 bei 444 die dem DTC zugeordnete Software. Falls nein, geht das Verfahren 200 zu 446 weiter.
Bei 446 bestimmt das Verfahren 200, ob das Problem mit dem DTC mit einer speziellen VIN oder VINs korreliert ist. Falls ja, stellt das Verfahren 200 bei 448 eine Angabe bereit, die Fahrzeug-Hardware (z. B. ein durch den DTC angegebenes fehlerhaftes Teilsystem) zu warten. Falls nein, geht das Verfahren 200 zu 450 weiter. Bei 450 aktualisiert das Verfahren die Software oder die Kalibrierung für den DTC.
Die vorhergehende Beschreibung ist lediglich veranschaulichender Art und ist nicht vorgesehen, die Offenbarung, ihre Anwendung oder Verwendungen einzuschränken. Die umfassenden Lehren der Offenbarung können in verschiedenen Formen implementiert sein. Während diese Offenbarung spezielle Beispiele enthält, sollte deshalb der wahre Schutzumfang der Offenbarung nicht so eingeschränkt werden, weil andere Modifikationen bei einem Studium der Zeichnungen, der Beschreibung und der folgenden Ansprüche offensichtlich werden.
Es sollte erkannt werden, dass ein oder mehrere Schritte innerhalb eines Verfahrens in unterschiedlicher Reihenfolge (oder gleichzeitig) ausgeführt werden können, ohne die Prinzipien der vorliegenden Offenbarung zu ändern. Obwohl jede der Ausführungsformen oben mit bestimmten Merkmalen beschrieben worden ist, können ferner ein oder mehrere dieser Merkmale, die bezüglich irgendeiner Ausführungsform der Offenbarung beschrieben worden sind, in irgendeiner der anderen Ausführungsform implementiert und/oder mit den Merkmalen irgendeiner der anderen Ausführungsform kombiniert sein, selbst wenn diese Kombination nicht explizit beschrieben ist. Mit anderen Worten, die beschriebenen Ausführungsformen schließen einander nicht aus, wobei Permutationen einer oder mehrerer Ausführungsformen miteinander innerhalb des Schutzumfangs dieser Offenbarung verbleiben.
Räumliche und funktionale Beziehungen zwischen Elementen (z. B. zwischen Modulen, Schaltungselementen, Halbleiterschichten usw.) werden unter Verwendung verschiedener Begriffe, z. B. „verbunden“, „im Eingriff‟, „gekoppelt“, „benachbart“, „neben“, „oben auf‟, „über“, „unter“ und „angeordnet“, beschrieben. Wenn eine Beziehung zwischen einem ersten und einem zweiten Element in der obigen Offenbarung beschrieben ist, kann diese Beziehung eine direkte Beziehung sein, bei der keine anderen dazwischenliegenden Elemente zwischen dem ersten und dem zweiten Element vorhanden sind, sie kann aber außerdem eine indirekte Beziehung sein, bei der ein oder mehrere dazwischenliegende Elemente (entweder räumlich oder funktional) zwischen dem ersten und dem zweiten Element vorhanden sind, wenn sie nicht ausdrücklich als „direkt“ beschrieben ist. Wie der Ausdruck wenigstens eines von A, B und C hier verwendet wird, sollte er ausgelegt werden, dass er ein logisches (A ODER B ODER C) unter Verwendung eines nicht ausschließlichen logischen ODER bedeutet, und nicht ausgelegt werden, dass er „wenigstens eines von A, wenigstens eines von B und wenigstens eines von C“ bedeutet.
In den Figuren demonstriert die Richtung eines Pfeils, wie durch die Pfeilspitze angegeben ist, im Allgemeinen den Informationsfluss (wie z. B. von Daten oder Anweisungen), der für die Veranschaulichung von Interesse ist. Wenn z. B. das Element A und das Element B verschiedene Informationen austauschen, aber die vom Element A zum Element B übertragenen Informationen für die Veranschaulichung relevant sind, kann der Pfeil vom Element A zum Element B zeigen. Dieser unidirektionale Pfeil impliziert nicht, dass keine anderen Informationen vom Element B zum Element A übertragen werden. Ferner kann das Element B für die vom Element A zum Element B gesendeten Informationen Anforderungen für die oder Empfangsquittungen der Informationen an das Element A senden.
In dieser Anmeldung einschließlich der Definitionen im Folgenden können die Begriffe „Modul“, „Controller“ oder „Teilsystem“ durch den Begriff „Schaltung“ ersetzt werden. Die Begriffe „Modul“, „Controller“ und „Teilsystem“ können sich beziehen auf, Teil sein von, oder enthalten: eine anwendungsspezifische integrierte Schaltung (ASIC); eine digitale, analoge oder gemischt analog/digitale diskrete Schaltung; eine digitale, analoge oder gemischt analog/digitale integrierte Schaltung; eine kombinatorische Logikschaltung; eine feldprogrammierbare Gatteranordnung (FPGA); eine Prozessorschaltung (gemeinsam benutzt, dediziert oder Gruppe), die Code ausführt; eine Speicherschaltung (gemeinsam benutzt, dediziert oder Gruppe), die den durch die Prozessorschaltung ausgeführten Code speichert; andere geeignete Hardware-Komponenten, die die beschriebene Funktionalität bereitstellen; oder eine Kombination aus einigen oder allen der Obigen, wie z. B. in einem System auf einem Chip. Ferner kann der Begriff „Teilsystem“ ein Modul und/oder einen Controller umfassen und kann zusätzlich einen oder mehrere Sensoren und Aktuatoren umfassen, um die beschriebene Funktionalität bereitzustellen.
Das Modul, der Controller und das Teilsystem können eine oder mehrere Schnittstellenschaltungen enthalten. Gemäß einigen Beispielen können die Schnittstellenschaltungen drahtgebundene oder drahtlose Schnittstellen enthalten, die mit einem lokalen Netz (LAN), dem Internet, einem Weitbereichsnetz (WAN) oder Kombinationen davon verbunden sind. Die Funktionalität irgendeines gegebenen Moduls, Controllers und Teilsystems der vorliegenden Offenbarung kann zwischen mehreren Modulen, Controllern und Teilsystemen verteilt sein, die über Schnittstellenschaltungen verbunden sind. Mehrere Module können z. B. einen Lastausgleich ermöglichen. In einem weiteren Beispiel kann ein Server-Modul (das außerdem als ein entferntes oder Cloud-Modul bekannt ist) einige Funktionalität im Auftrag eines Client-Moduls ausführen.
Der Begriff Code, wie er oben verwendet wird, kann Software, Firmware und/oder Mikrocode enthalten und kann sich auf Programme, Routinen, Funktionen, Klassen, Datenstrukturen und/oder Objekte beziehen. Der Begriff gemeinsam benutzte Prozessorschaltung umfasst eine einzelne Prozessorschaltung, die etwas oder alles des Codes von mehreren Modulen, Controllern und Teilsystemen ausführt. Der Begriff Gruppenprozessorschaltung umfasst eine Prozessorschaltung, die in Kombination mit zusätzlichen Prozessorschaltungen einiges oder alles des Codes von einem oder mehreren Modulen, Controllern und Teilsystemen ausführt. Die Bezugnahmen auf mehrere Prozessorschaltungen umfassen mehrere Prozessorschaltungen auf diskreten Dies, mehrere Prozessorschaltungen auf einem einzigen Die, mehrere Kerne einer einzelnen Prozessorschaltung, mehrere Threads einer einzelnen Prozessorschaltung oder eine Kombination aus dem Obigen. Der Begriff gemeinsam benutzte Speicherschaltung umfasst eine einzelne Speicherschaltung, die etwas oder alles des Codes von mehreren Modulen, Controllern und Teilsystemen speichert. Der Begriff Gruppenspeicherschaltung umfasst eine Speicherschaltung, die in Kombination mit zusätzlichen Speichern etwas oder alles des Codes von einem oder mehreren Modulen, Controllern und Teilsystemen speichert.
Der Begriff Speicherschaltung ist eine Teilmenge des Begriffs computerlesbares Medium. Der Begriff computerlesbares Medium, wie er hier verwendet wird, umfasst keine transitorischen elektrischen oder elektromagnetischen Signale, die sich durch ein Medium (wie z. B. auf einer Trägerwelle) ausbreiten; der Begriff computerlesbares Medium kann deshalb als greifbar und nicht transitorisch betrachtet werden. Nicht einschränkende Beispiele eines nicht transitorischen, greifbaren computerlesbaren Mediums sind nichtflüchtige Speicherschaltungen (wie z. B. eine Flash-Speicherschaltung, eine löschbare programmierbare Festwertspeicherschaltung oder eine Maskenfestwertspeicherschaltung), flüchtige Speicherschaltungen (z. B. eine statische Schreib-Lese-Speicher-Schaltung oder eine dynamische Schreib-Lese-Speicher-Schaltung), magnetische Speichermedien (wie z. B. ein analoges oder digitales Magnetband oder ein Festplattenlaufwerk) und optische Speichermedien (wie z. B. eine CD, eine DVD oder eine Blu-ray-Disc).
Die in dieser Anmeldung beschriebenen Vorrichtungen und Verfahren können teilweise oder vollständig durch einen Spezialcomputer implementiert sein, der durch das Konfigurieren eines Universalcomputers erzeugt wird, um eine oder mehrere spezielle in Computerprogrammen verkörperte Funktionen auszuführen. Die oben beschriebenen Funktionsblöcke, Ablaufplankomponenten und anderen Elemente dienen als Software-Spezifikationen, die durch die Routinearbeit eines ausgebildeten Technikers oder Programmierers in die Computerprogramme übersetzt werden können.
Die Computerprogramme enthalten prozessorausführbare Anweisungen, die in wenigstens einem nicht transitorischen, greifbaren computerlesbaren Medium gespeichert sind. Die Computerprogramme können außerdem gespeicherte Daten enthalten oder sich auf gespeicherte Daten stützen. Die Computerprogramme können ein grundlegendes Eingabe-/Ausgabesystem (BIOS), das mit der Hardware des Spezialcomputers wechselwirkt, Vorrichtungstreiber, die mit speziellen Vorrichtungen des Spezialcomputers wechselwirken, ein oder mehrere Betriebssysteme, Anwenderanwendungen, Hintergrunddienste, Hintergrundanwendungen usw. umfassen.
Die Computerprogramme können enthalten: (i) beschreibenden Text, der zu parsen ist, wie z. B. HTML (Hypertext-Auszeichnungssprache), XML (erweiterbare Auszeichnungssprache) oder JSON (JavaScript-Objektbezeichnung), (ii) Assemblercode, (iii) Objektcode, der durch einen Compiler aus Quellcode erzeugt wird, (iv) Quellcode zur Ausführung durch einen Interpreter, (v) Quellcode zur Kompilierung und Ausführung durch einen Just-in-Time-Compiler usw. Lediglich als Beispiele kann der Quellcode unter Verwendung der Syntax von Sprachen einschließlich C, C++, C#, Objective-C, Swift, Haskell, Go, SQL, R, Lisp, Java®, Fortran, Perl, Pascal, Curl, OCaml, Javascript®, HTML5 (Hypertext-Auszeichnungssprache, 5. Überarbeitung), Ada, ASP (Aktive Server-Seiten), PHP (PHP: Hypertext-Vorprozessor), Scala, Eiffel, Smalltalk, Erlang, Ruby, Flash®, Visual Basic®, Lua, MATLAB, SIMULINK und Python® geschrieben sein.

Claims

System zum Validieren von Diagnosefehlercodes (DTCs) in Fahrzeugen, wobei das System umfasst: einen Prozessor; und einen Speicher, der Anweisungen speichert, die, wenn sie durch den Prozessor ausgeführt werden, den Prozessor konfigurieren: DTC-Daten von den Fahrzeugen zu empfangen; die DTC-Daten unter Verwendung vorgegebener Regeln zu filtern; basierend auf den gefilterten DTC-Daten eine oder mehrere Metriken zu erzeugen; und basierend auf den Metriken zu bestimmen, ob die DTCs den Spezifikationen für die DTCs entsprechen.
System nach Anspruch 1, wobei der Prozessor konfiguriert ist: Probleme mit den DTCs basierend auf den Metriken und den vorgegebenen Regeln zu detektieren; die Probleme mit Software- und Kalibrierungsversionen, die verwendet werden, um die DTCs zu erzeugen, Fahrzeugidentifikationsnummern (VINs) der Fahrzeuge und Umgebungsvariable zu korrelieren; und eine Grundursache für die Probleme mit den DTCs zu identifizieren.
System nach Anspruch 2, wobei der Prozessor konfiguriert ist, basierend auf der Korrelation mit den Software- und Kalibrierungsversionen eine Angabe hinsichtlich des Aktualisierens der Software- oder Kalibrierungsversionen bereitzustellen.
System nach Anspruch 2, wobei der Prozessor konfiguriert ist, basierend auf der Korrelation mit den VINs eine Angabe hinsichtlich der Wartung eines oder mehrerer der Fahrzeuge bereitzustellen.
System nach Anspruch 2, wobei der Prozessor konfiguriert ist, basierend auf der Korrelation mit den VINs eine Angabe hinsichtlich des Modifizierens von wenigstens einer der Software- oder Kalibrierungsversionen bereitzustellen.
System nach Anspruch 1, wobei der Prozessor konfiguriert ist, die DTC-Daten basierend auf einem oder mehreren dessen zu filtern: ob die DTC-Daten von einem Testfahrzeug stammen; die Bedingungen, um die DTCs zu erzeugen, für jeden Fahrzyklus erfüllt sind; die DTCs zurückgesetzt wurden, nachdem die entsprechende Störung beseitigt wurde; die DTCs erzeugt werden, nachdem die Fahrzeuge während eines Zeitraums gefahren worden sind; und ob sich die Variable, die verwendet werden, um die Metriken zu erzeugen, innerhalb der jeweiligen Bereiche der Standardwerte befinden.
System nach Anspruch 1, wobei eine der Metriken ein Verhältnis der Überwachungsleistung in Verwendung (IUMPR) ist und wobei der Prozessor konfiguriert ist, darauf basierend, ob sich das IUMPR für den einen der DTCs innerhalb eines vorgegebenen Bereichs befindet, zu bestimmen, ob einer der DTCs einer entsprechenden Spezifikation entspricht.
System nach Anspruch 1, wobei eine der Metriken ein Verhältnistyp ist und wobei der Prozessor konfiguriert ist, darauf basierend, ob sich ein Verhältnis einer Variable für den einen der DTCs zu einem entsprechenden Schwellenwert innerhalb einer vorgegebenen Grenze befindet, zu bestimmen, ob einer der DTCs einer entsprechenden Spezifikation entspricht.
System nach Anspruch 1, wobei eine der Metriken ein statistischer Typ ist und wobei der Prozessor konfiguriert ist, darauf basierend, ob ein Mittelwert einer Variable für den einen der DTCs eine vorgegebene Anzahl von Standardabweichungen von einem entsprechenden Schwellenwert entfernt ist, zu bestimmen, ob einer der DTCs einer entsprechenden Spezifikation entspricht.
System nach Anspruch 1, wobei der Prozessor konfiguriert ist: Ausreißer in den Daten zu detektieren, die einer Variable entsprechen, die als Gütezahlvariable für einen der DTCs ausgewählt worden ist; die Ausreißer mit den Software- und Kalibrierungsversionen, die verwendet worden sind, um die DTCs zu erzeugen, den Fahrzeugidentifikationsnummern (VINs) der Fahrzeuge und den Umgebungsvariable zu korrelieren; und eine Grundursache für die Probleme mit dem einen der DTCs zu identifizieren.