DE102017101480A1

DE102017101480A1 - Anpassen von diagnosetests basierend auf gesammelten fahrzeugdaten

Info

Publication number: DE102017101480A1
Application number: DE102017101480.2A
Authority: DE
Inventors: Fling Finn Tseng; Imad Hassan Makki; Pankaj Kumar; Aed M. Dudar; Robert Roy Jentz
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2016-02-05
Filing date: 2017-01-26
Publication date: 2017-08-10
Anticipated expiration: 2037-01-27
Also published as: US20170228946A1; GB2549169A; DE102017101480B4; US9824512B2; RU2017103440A; CN107045739B; CN107045739A; MX2017001583A; GB201701739D0

Abstract

Ein System, das einen Prozessor umfasst, der dafür programmiert ist, von mehreren Fahrzeugen Diagnosetestdatensätze in Bezug auf einen durchgeführten Diagnosetest zu empfangen. Jeder Diagnosetestdatensatz umfasst einen Testausgabewert und einen oder mehrere entsprechende Testbedingungswerte. Der Prozessor ist ferner dafür programmiert, einige der Testausgabewerte basierend auf dem Auswählen einer Funktion für das Verknüpfen des Testausgabewerts mit Testausgabewerten von verschiedenen Diagnosedatensätzen auszuwählen. Der Prozessor ist ferner dafür programmiert, den Testausgabewert und die entsprechenden Testbedingungswerte als Eingabe für die ausgewählte Funktion für das Erhalten von mehreren skalierten Testausgabewerten bereitzustellen und eine Anpassung des Diagnosetests basierend wenigstens teilweise auf den skalierten Testausgabewerten zu erzeugen.

Description

HINTERGRUND
Viele Fahrzeuge umfassen Computer, die zur Durchführung von On-Board-Diagnosen programmiert sind, um Systeme zu identifizieren, die möglicherweise nicht innerhalb vorgegebener Grenzen arbeiten. Diese Diagnosetests werden üblicherweise unter realen Bedingungen durchgeführt, zum Beispiel im Fahrzeugbetrieb oder direkt nach dem Fahrzeugbetrieb. Entsprechend können die Testergebnisse von unkontrollierten Umweltfaktoren und Betriebsbedingungen des Fahrzeugs wie dem geografischen Ort des Fahrzeugs, Wetterbedingungen während der Fahrzeit und/oder während der Testzeit oder Nutzungsmustern des Fahrzeugs abhängen. Verschiedene unkontrollierte (oder unkontrollierbare) Faktoren werden jedoch bei aktuellen Testspezifikationen nicht berücksichtigt, und diese stellen deshalb möglicherweise unzuverlässige oder ungenaue Diagnosetestergebnisse oder wenigstens Diagnosetestergebnisse, die weniger genau als gewünscht sind, bereit.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Diagramm eines beispielhaften Systems für das Anpassen von On-Board-Diagnose-Tests in Fahrzeugen.
2 ist ein Blockdiagramm eines beispielhaften Fahrzeugs für das System von 1.
3A ist ein beispielhaftes Diagramm eines Diagnosetests, der unter einer ersten Testbedingung durchgeführt wurde.
3B ist ein beispielhaftes Diagramm eines Diagnosetests, der unter einer zweiten Testbedingung durchgeführt wurde.
4 ist ein Diagramm eines beispielhaften Prozesses für das Sammeln von Daten, der für das Anpassen eines Diagnosetests verwendet wird.
5 ist ein Diagramm eines beispielhaften Prozesses für das Erzeugen einer Anpassung des Diagnosetests basierend auf Daten von mehreren Fahrzeugen.
6 ist ein Diagramm eines beispielhaften Prozesses für das Anpassen des Diagnosetests.
BESCHREIBUNG
EINFÜHRUNG
Ein System 10, wie in 1 gezeigt, umfasst einen Server 16, der dafür programmiert ist, Daten in Bezug auf mehrere Fahrzeuge 12 zu sammeln. Die Daten von jedem Fahrzeug 12 umfassen Fahrzeugidentifikationsdaten, Daten in Bezug auf Betriebsbedingungen und gemessene Parameterwerte für einen oder mehrere Diagnosetests, die das Fahrzeug 12 betreffen und/oder von diesem durchgeführt wurden. Identifikationsdaten umfassen Daten wie Fahrzeugmodell, Fahrzeugbaujahr, Fahrzeugmerkmale, Fahrzeugleistungsspezifikationen usw. Betriebsbedingungen umfassen Daten wie den Ort des Fahrzeugs 12, Wetterbedingungen während des Betriebs (z. B. Umgebungsbedingungen wie Außentemperatur, Luftfeuchtigkeit usw.), Nutzungsmuster des Fahrzeugs 12, Positionen von Aktuatoren (z. B. in Steuerungen) in dem Fahrzeug 12, das Anliegen von elektrischem Strom an einer Kraftmaschine in dem Fahrzeug 12 usw. Gemessene Testparameterwerte umfassen Ergebnisse von Diagnosetests, die von dem Fahrzeug 12 durchgeführt wurden, wie ein Dampfdruckniveau oder ein Fluiddruckniveau. Die Daten können von dem Server 16 von den Fahrzeugen 12 oder von anderen Datenquellen 18 wie globalen Positionsbestimmungssystemen (GPS), Wettermeldesystemen, usw. gesammelt werden. Die Daten können z. B. über ein Netzwerk 14 gesammelt werden.
Der Server 16 ist dafür programmiert, einen Datensatz in Bezug auf einen bestimmten Diagnosetest, der von den jeweiligen Fahrzeugen 12 durchgeführt wurde, zu sammeln. Der Datensatz kann die Identifikationsdaten in Bezug auf das Fahrzeug 12, die Betriebsbedingungen in Bezug auf das Fahrzeug 12 zu einer Zeit des Diagnosetests und die Testparameterwerte, die von dem Fahrzeug 12 während des Diagnosetests gemessen wurden, umfassen.
Der Server 16 kann aus den gesammelten Datensätzen Datensätze auswählen, um eine Anpassung für einen bestimmten Diagnosetest zu bestimmen. Das Auswählen der zu verwendenden Datensätze kann umfassen, basierend auf den Fahrzeugidentifikationsdaten, Betriebsdaten und Testparameterwerten zu ermitteln, dass eine Funktion für das Erzeugen skalierter Testparameterwerte, die auf einer gemeinsamen Skala bewertet werden können, identifiziert werden kann. Die gemeinsame Skala kann eine vorher festgelegte Skala für den bestimmten Diagnosetest sein, die z. B. auf einem Referenzfahrzeug, das unter Referenzbetriebsbedingungen betrieben wird, basiert. Eine Funktion für das Erzeugen skalierter Testparameterwerte, die auf einer gemeinsamen Skala bewertet werden können, wird hierin als eine normalisierende Funktion bezeichnet.
Die ausgewählten Datensätze können Datensätze von den Fahrzeugen 12 sein, die von einem ähnlichen Modelltyp sind, ein ähnliches Baujahr, einen ähnlichen Antriebsstrang, ein ähnliches Klimaregelsystem haben und/oder auf einer ähnlichen Fahrtroute, bei einer ähnlichen Umgebungslufttemperatur, bei einem ähnlichen barometrischen Druck, nach einem ähnlichen Nutzungsmuster usw. betrieben wurden.
Der Server 16 kann Datensätze in Bezug auf einen Diagnosetest von den jeweiligen Fahrzeugen 12 sammeln. Der Server 16 kann dann aus den gesammelten Datensätzen Datensätze auswählen, auf die eine normalisierende Funktion angewendet werden kann. Der Server 16 kann dann die normalisierende Funktion auf die ausgewählten Datensätze anwenden und skalierte Testparameterwerte erzeugen. Basierend auf den skalierten Testparameterwerten kann der Server 16 eine Anpassung eines Diagnosetests erzeugen und die Anpassung für ein oder mehrere Fahrzeuge 12 bereitstellen. Die Fahrzeuge 12 werden jeweils mit den Datensätzen, die zum Erzeugen der Anpassung ausgewählt wurden, verbunden. In einigen Fällen kann eine Anpassung basierend auf den ausgewählten Datensätzen auch auf andere Fahrzeuge 12, die nicht mit den ausgewählten Datensätzen verbunden wurden, anwendbar sein. Die Fahrzeuge 12 können die Anpassung von dem Server 16 empfangen und dann On-Board-Diagnose-Tests basierend auf den Anpassungen durchführen.
SYSTEMELEMENTE
Ein beispielhaftes System 10 für das Sammeln von Daten in Bezug auf die Fahrzeuge 12 ist in 1 gezeigt. Das System 10 umfasst ein oder mehrere Fahrzeuge 12, ein Netzwerk 14 und einen Server 16, und es kann ferner eine oder mehrere Datenquellen 18 umfassen.
Das Fahrzeug 12 ist allgemein ein Landfahrzeug 12 mit drei oder mehr Rädern, z. B. ein Personenkraftwagen oder Kleinlastkraftwagen. Wie nachfolgend genauer beschrieben und wie in 2 gezeigt, umfasst das erste Fahrzeug 12 einen Computer 20. Der Computer 20 kann dafür programmiert sein, On-Board-Diagnose-Tests auf einem oder mehreren Fahrzeugsystemen durchzuführen und/oder diesbezügliche Daten zu sammeln, wie nachfolgend genauer beschrieben ist. Außerdem kann das Fahrzeug 12 Daten in Bezug auf die On-Board-Diagnose-Tests zu dem Server 16 senden. Die Daten können Identifikationsdaten, Daten von Sensoren, Daten von Steuerungen oder von Datenquellen wie globalen Positionsbestimmungssystemen (GPS), Wetterbeobachtungssystemen, Verkehrsbeobachtungssystemen usw. empfangene Daten umfassen.
Zum Beispiel kann der Computer 20 des Fahrzeugs 12 einen Diagnosetest durchführen, um Undichtigkeiten in einer Kraftstoffverdunstungsanlage (EVAP) zu erkennen. Der erste Computer des Fahrzeugs 12 kann eine oder mehrere Fahrzeugkomponenten unter der Kontrolle des Computers 20 betätigen. Das Betätigen einer Fahrzeugkomponente unter der Steuerung des Computers 20, wie hier verwendet, kann umfassen, dass ein Computer 20 des Fahrzeugs z. B. über einen Kommunikationsbus des Fahrzeugs 12 Anweisungen an eine elektronische Steuereinheit (ECU – Electronic Control Unit oder „Steuerung“) 24 des Fahrzeugs sendet und die Steuerung 24 des Fahrzeugs basierend auf den Anweisungen eine Komponente in dem ersten Fahrzeug 12 betätigt. Zum Beispiel kann der Computer 20 des Fahrzeugs 12 zum Durchführen des Diagnosetests ein Ventil betätigen, um einen Kraftstoffdampfhohlraum in dem Fahrzeug 12 zu öffnen oder zu schließen. Der Computer 20 des Fahrzeugs 12 kann eine Anweisung an eine Ventilsteuerung 24 senden. Die Ventilsteuerung 24 kann einen Elektromotor steuern, um das Ventil zu öffnen oder zu schließen. Die Ventilsteuerung 24 kann ferner eine Rückmeldung zu dem Computer 20 senden, in der angegeben wird, dass sich das Ventil in der geöffneten oder in der geschlossenen Stellung befindet.
Der Computer 20 des Fahrzeugs 12 kann ferner Daten von einem oder mehreren Sensoren empfangen. Die Sensoren können zum Beispiel einen Druck in dem Hohlraum angeben.
Das Netzwerk 14 stellt einen oder mehrere Mechanismen dar, durch die die Fahrzeuge 12, der Server 16 und eine oder mehrere Datenquellen 18 miteinander kommunizieren können, und es kann eines oder mehrere von verschiedenen verdrahteten oder drahtlosen Kommunikationsmechanismen, unter anderem jede gewünschte Kombination von verdrahteten (z. B. Kabel und Glasfaser) und/oder drahtlosen (z. B. Mobilfunk, drahtlos, Satellit, Mikrowellen und Hochfrequenz) Kommunikationsmechanismen sein und jede gewünschte Netzwerktopologie (oder Topologien, wenn mehrere Kommunikationsmechanismen verwendet werden) haben. Beispielhafte Kommunikationsnetzwerke umfassen drahtlose Kommunikationsnetzwerke, lokale Netzwerke (LAN – Local Area Networks) und/oder großflächige Netzwerke (WAN – Wide Area Networks), einschließlich des Internets, die Datenkommunikationsdienste bereitstellen.
Die Datenquellen 18 können Systeme wie globale Positionsbestimmungssysteme (GPS), Verkehrsbeobachtungssysteme, Wetterbeobachtungssysteme usw. sein, und sie können Daten in Bezug auf eine Betriebsbedingung des Fahrzeugs 12 bereitstellen. Die Datenquelle 18 kann zum Beispiel dafür programmiert sein, Kartendaten, Wetterdaten, geografische Koordinaten (z. B. Breitengrad, Längengrad), Verkehrsdaten usw. wie bekannt zu erzeugen und den Fahrzeugen 12 oder dem Server 16 bereitzustellen.
Das Fahrzeug 12 umfasst ferner einen oder mehrere Sensoren 22, die bereitgestellt werden, um Daten in Bezug auf das erste Fahrzeug 12 und die Umgebung, in der das erste Fahrzeug 12 betrieben wird, zu sammeln. Beispielhaft und nicht einschränkend können die Sensoren 22 z. B. Thermometer, Barometer, Feuchtigkeitssensoren, Höhenmesser, Kameras, LiDAR, Radar, Ultraschallsensoren, Infrarotsensoren, Drucksensoren, Beschleunigungsmesser, Gyroskope, Temperatursensoren, Hall-Sensoren, optische Sensoren, Spannungssensoren, Stromsensoren, mechanische Sensoren wie Schalter usw. umfassen. Die Sensoren 22 können verwendet werden, um die Umgebung zu erfassen, in der das Fahrzeug 12 betrieben wird, wie Wetterbedingungen, das Gefälle einer Straße, den Ort einer Straße, in der Nähe befindliche Fahrzeuge 12 usw. Die Sensoren 22 können ferner verwendet werden, um dynamische Daten des Fahrzeugs 12 in Bezug auf den Betrieb des Fahrzeugs 12 zu sammeln, wie Geschwindigkeit, Gierrate, Lenkwinkel, Kraftmaschinendrehzahl, Bremsdruck, Öldruck, das auf Steuerungen in dem Fahrzeug angewendete Leistungsniveau oder Verbindbarkeit zwischen Komponenten. Die Sensoren 22 können außerdem ferner verwendet werden, um Parameter zu messen und Parameterwerte in Bezug auf einen oder mehrere Diagnosetests zu erzeugen, wie Kraftstoffstand oder Kraftstoffverdunstungsdruck.
Die Kommunikationsschaltung 26 kann Hardware, Software, Firmware usw. wie bekannt umfassen, und sie kann für eine oder mehrere Arten von drahtlosen Kommunikationen angeordnet sein. Die Hardware kann z. B. einen oder mehrere Sender-Empfänger, einen oder mehrere Empfänger, einen oder mehrere Sender, einen oder mehrere Antennen, einen oder mehrere Mikrocontroller, einen oder mehrere Speicher, eine oder mehrere elektronische Komponenten usw. umfassen. Die Software kann in einem Speicher gespeichert sein, und sie kann z. B. einen oder mehrere Encoder oder einen oder mehrere Decoder für das Konvertieren von Nachrichten von einem Protokoll in ein anderes Protokoll umfassen. Einige Funktionen, z. B. Codierfunktionen, können über Firmware umgesetzt werden.
Die Arten von drahtlosen Kommunikationen können WLAN-Kommunikationen, dedizierte Nahbereichskommunikationen (DSRC – Dedicated Short Range Communications), Zwei-Wege-Satellitenkommunikationen (z. B. Notdienste), Ein-Weg-Satellitenkommunikationen (z. B. das Empfangen von digitalen Audio-/Rundfunkübertragungen), MW-/UKW-Rundfunk usw. umfassen. Außerdem kann die Kommunikationsschaltung 26 z. B. über ein verdrahtetes Netzwerk wie einen CAN(Controller Area Network)-Bus oder einen LIN(Local Interconnect Network)-Bus wie bekannt kommunikativ an den Computer 20 gekoppelt sein.
Die Steuerungen 24 für das Fahrzeug 12 können bekannte elektronische Steuereinheiten (ECUs – Electronic Control Units) oder dergleichen umfassen, unter anderem als nicht einschränkende Beispiele eine Kraftmaschinensteuerung, eine Ventilsteuerung, eine Sitzsteuerung, eine Servolenkungssteuerung, eine Türschlosssteuerung, eine Türverriegelungssteuerung, eine Klimaregelung, eine Spiegeleinstellungssteuerung, eine Sitzgurtsteuerung, eine Bremssteuerung usw. Alle Steuerungen 24 können jeweilige Prozessoren und Speicher, einen oder mehrere Aktuatoren, umfassen, und sie können Anweisungen zu einem oder mehreren Sensoren 22 senden und/oder Daten von diesen empfangen, wie bekannt ist. Die Steuerungen 24 können programmiert und mit einem Kommunikationsbus des Fahrzeugs 12 verbunden sein, um Anweisungen von dem Computer 20 zu empfangen und einen Aktuator basierend auf diesen Anweisungen zu steuern. Zum Beispiel kann eine Ventilsteuerung eine Anweisung zum Öffnen oder Schließen eines Ventils empfangen und bewirken, dass ein Aktuator einen Ventilzylinder bewegt. Der Aktuator kann z. B. eine Kraftmaschine oder eine Magnetspule sein. Ein oder mehrere Sensoren 22 können z. B. die Aktion des Aktuators erkennen. Zum Beispiel kann ein Sensor 22 in der Ventilsteuerung erkennen, dass der Ventilzylinder bewegt wurde. Die Steuerung 24 kann Daten in Bezug auf den Status des Ventilzylinders für den Computer 20 bereitstellen.
Der Computer 20 umfasst einen Prozessor und einen Speicher. Der Speicher umfasst eine oder mehrere Arten von computerlesbaren Medien und vom Prozessor ausführbare Speicheranweisungen für das Durchführen verschiedener Betriebsvorgänge, unter anderem wie hierin offenbart. Ferner kann der Computer 20 einen oder mehrere andere Computer umfassen und/oder kommunikativ an diese gekoppelt sein, unter anderem z. B. Fahrzeugkomponenten wie die Sensoren 22 und Steuerungen 24, die gleichermaßen wie bekannt jeweilige Prozessoren und Speicher umfassen können. Kommunikationen können z. B. über einen Controller Area Network(CAN)-Bus oder Local Interconnect Network LIN)-Bus durchgeführt werden, wie bekannt ist.
Der Computer 20 kann wie bekannt dafür programmiert sein, Diagnosetests durchzuführen und die Betriebsfähigkeit von On-Board-Systemen wie On-Board-Sensoren 22, On-Board-Steuerungen 24 und der On-Board-Kommunikationsschaltung 26 zu ermitteln.
PROZESSE
Durchführen von On-Board-Diagnose-Tests
Der Computer 20 eines Fahrzeugs 12 kann allgemein dafür programmiert sein, einen oder mehrere OBD(On-Board-Diagnose)-Tests durchzuführen. Der Computer 20 kann z. B. den ordnungsgemäßen Betrieb einer bestimmten Komponente oder einer Gruppe von Komponenten in dem Fahrzeug 12 testen. Der Computer 20 kann zu einem bestimmten Zeitpunkt zum Beispiel basierend auf einem Auslöseereignis wie nachfolgend erläutert einen Diagnosetest initiieren, indem er Anweisungen an eine oder mehrere Steuerungen 24 sendet. Die Steuerungen 24 können das Fahrzeug 12 in einen Zustand für das Durchführen des Diagnosetests bringen, d. h., sie können eine oder mehrere Komponenten des Fahrzeugs 12 auf eine vorher festgelegte Weise und/oder derart, dass sich diese in einer vorher festgelegten Position für den Test befinden, betätigen und/oder steuern. Der Zustand kann zum Beispiel umfassen, ein oder mehrere Ventile in bestimmte Positionen zu bringen oder eine bestimmte Kraft durch eine Kraftmaschine aufzubringen. Nachdem das Fahrzeug 12 in den Zustand für das Durchführen des Diagnosetests gebracht wurde, kann der Computer 20 Daten von einem oder mehreren Sensoren 22 empfangen. Basierend auf den Daten von den Sensoren 22 kann der Computer 20 bestätigen, ob ein Wert eines gemessen Testparameters innerhalb eines vorher festgelegten Bereichs liegt. Ein innerhalb des vorher festgelegten Bereichs liegender Parameterwert kann darauf hindeuten, dass die vom Computer 20 getestete Komponente innerhalb der Spezifikation arbeitet. Ein außerhalb des vorher festgelegten Bereichs liegender Parameterwert kann darauf hindeuten, dass die vom Computer getestete Komponente nicht innerhalb der Spezifikation arbeitet.
Zum Beispiel kann der Computer 20 eine Anweisung an eine Steuerung 24 senden, um einen Hauptzylinder um einen vorgegebenen Wert zu bewegen, um einen Druck auf eine Bremsflüssigkeitsleitung auszuüben. Der Computer 20 kann von der Steuerung 24 eine Bestätigung empfangen, dass der Hauptzylinder um den vorgegebenen Wert bewegt wurde. Basierend auf der Bewegung des Hauptzylinders kann der Computer 20 einen erwarteten Bremsflüssigkeitsdruck bestimmen. Der Computer 20 kann von einem in der Bremsflüssigkeitsleitung angeordneten Drucksensor 22 den Wert des Bremsflüssigkeitsdrucks in der Bremsflüssigkeitsleitung empfangen. Der Computer 20 kann die Daten von dem Sensor 22 vergleichen und ermitteln, dass der Bremsflüssigkeitsdruck innerhalb des erwarteten Bereichs liegt. Der vorher festgelegte Bereich kann z. B. oberhalb eines vorher festgelegten Schwellwerts wie 40 bar liegen.
Der erwartete Bereich eines Testparameterwerts kann eine Funktion von einem oder mehreren anderen Werten sein. Zum Beispiel kann ein Schwellwert für den Kraftstoffverdunstungsdruck teilweise basierend auf einem Kraftstoffstand des Fahrzeugs 12 ermittelt werden.
Gemeinhin verwendete On-Board-Diagnose-Tests umfassen die Diagnose der Krümmerdruckmessung, die Diagnose der Kühlflüssigkeitstemperaturmessung, die Diagnose des Kraftstoffeinspritzsystems, die Diagnose des Klopfsensors, die Diagnose der Abgasrückführungsfunktion, die Diagnose der Katalysatorsystemeffizienz, die Funktionsdiagnose usw.
Auslöseereignisse für das Sammeln von Daten in Bezug auf On-Board-Diagnose-Tests
Der Computer 20 kann dafür programmiert sein, viele verschiedene Arten von Auslöseereignissen für das Sammeln von Daten in Bezug auf einen On-Board-Diagnose-Test zu erkennen. Als nicht einschränkende Beispiele kann das Sammeln von Daten periodisch (z. B. einmal pro Stunde, wenn das Fahrzeug in Betrieb ist), zu einem Zeitpunkt, wenn das Fahrzeug 12 mit einer Geschwindigkeit oberhalb eines bestimmten Werts (z. B. 60 Meilen/Stunde) für eine Dauer von mehr als fünf Minuten in Betrieb war, wenn das Fahrzeug 12 in Betrieb ist und die Umgebungstemperatur innerhalb eines vorher festgelegten Bereichs (z. B. zwischen 0 und 25 Grad Celsius) liegt, am Ende einer Fahrt, wenn das Fahrzeug 12 im Ruhezustand ist, die Kraftmaschine vom Betrieb aber noch warm ist (z. B. Kühlmitteltemperatur oberhalb 50 Grad Celsius), am Ende einer Fahrt mit einem bestimmten Nutzungsmuster (z. B. Beibehalten einer Geschwindigkeit von mehr als 30 Meilen/Stunde für wenigstens 30 Minuten), am Ende einer Fahrt, wenn das Fahrzeug 12 in einer bestimmten geografischen Region unterwegs war oder eine bestimmte Strecke eines Autobahnabschnitts zurückgelegt hat, wenn das Fahrzeug 12 gestartet wird, nachdem es sich auf Umgebungstemperatur abgekühlt hat, wenn das Fahrzeug 12 eine bestimmte Anzahl von Meilen wie 1000 Meilen zurückgelegt hat, seit die letzten Daten in Bezug auf den Diagnosetest gesammelt wurden, usw. ausgelöst werden. Außerdem können Auslöseereignisse zum Beispiel eine Anforderung von Daten für einen bestimmten Test von dem Server 16 oder eine Anforderung von einem Techniker, zum Beispiel über einen CAN-Bus, zum Sammeln von Daten in Bezug auf einen bestimmten Diagnosetest, usw. umfassen.
Basierend auf dem Erkennen eines Auslöseereignisses für das Sammeln von Daten in Bezug auf den Diagnosetest kann der Computer 20 die Daten sammeln. Der Computer 20 kann Anweisungen senden, um einen oder mehrere Aktuatoren in eine Position für das Sammeln der Daten zu bringen. Nachdem die Aktuatoren in Position gebracht wurden, kann der Computer 20 Daten von einem oder mehreren Sensoren 22 empfangen. Die Daten können gemessene Werte von Testparametern in Bezug auf den Diagnosetest umfassen.
Arten von Testparametern, die für Diagnosetests verwendet werden
Der Computer 20 kann dafür programmiert sein, Daten für verschiedene Arten von Testparametern für einen bestimmten Diagnosetest zu sammeln und zu analysieren. Die Daten können Werte für einen oder mehrere Testparameter umfassen. In einigen Fällen kann der Diagnosetest absolute Werte sammeln. Zum Beispiel kann ein Testparameterwert die Temperatur des Kühlmittels sein, wenn das Fahrzeug 12 ausgeschaltet wird. In anderen Fällen kann der Testparameter eine Wertänderung sein. Zum Beispiel kann der Computer 20 eine Änderung des Bremsflüssigkeitsdrucks messen, wenn ein Hauptzylinder von einer ersten Position in eine zweite Position bewegt wird. In anderen Fällen kann der Testparameter der Unterschied zwischen einem ersten Wert eines Parameters, wenn das Fahrzeug 12 im Ruhezustand ist, und einem zweiten Wert des Parameters, wenn das Fahrzeug 12 für einen bestimmten Zeitraum in Betrieb war oder bei einer bestimmten Kraftmaschinentemperatur in Betrieb ist usw., sein.
Sammeln und Speichern von Daten, Bereitstellen von Daten für den Server
Wie weiter oben beschrieben, kann der Computer 20 dafür programmiert sein, das Sammeln von Daten in Bezug auf einen Diagnosetest basierend auf dem Erkennen eines Auslöseereignisses zu initiieren. Der Computer 20 kann die Daten sammeln und die Ergebnisse in einem mit dem Computer 20 verknüpften Speicher speichern. Der Speicher kann zum Beispiel in dem Fahrzeug 12 enthalten sein. Die Daten können als Datensätze organisiert sein, z. B. als ein Datensatz in Bezug auf einen bestimmten Diagnosetest, der von einem bestimmten Fahrzeug 12 durchgeführt wurde.
In einigen Fällen kann der Computer 20 die Daten nach Abschluss des Tests für den Server 16 bereitstellen. In anderen Fällen kann der Computer 20 die Daten speichern und zu einem späteren Zeitpunkt, zum Beispiel nach dem Empfang einer entsprechenden Anforderung von dem Server 16, für den Server 16 bereitstellen.
Wie weiter oben beschrieben, kann der Computer 20 ferner Daten in Bezug auf einen Diagnosetest basierend auf einer Anforderung von dem Server 16 sammeln. Nach dem Sammeln der Daten kann der Computer 20 die Daten für den Server 16 bereitstellen.
Wie weiter oben erläutert, können die für den Server 16 bereitgestellten Daten von den Sensoren 22 in dem Fahrzeug 12 gemessene Parameterwerte umfassen. Für den Server 16 bereitgestellte Daten können ferner Fahrzeugidentifikationsdaten wie Fahrzeugtyp, Fahrzeugmodelljahr, Fahrzeugkomponenten, Fahrzeuglaufleistung usw. umfassen. Die Daten können ferner Betriebsbedingungen des Fahrzeugs wie einen geografischen Ort des Fahrzeugs 12, z. B. geografische Koordinaten von einem globalen Positionsbestimmungssystem (GPS) oder einem ähnlichen Navigationssystem, z. B. Daten zu Breitengrad und Längengrad, und/oder andere geografische Identifikationsinformationen (z. B. geografische Regionen oder Einheiten wie Bundesstaat Michigan, Wayne County, Ostküste usw.), eine Fahrtroute des Fahrzeugs 12 (von Detroit nach Chicago, auf einem Abschnitt der Interstate 95, innerhalb eines Orts, durch eine Gebirgsgegend usw.), Wetterbedingungen zum Zeitpunkt der Fahrt und/oder zum Zeitpunkt des Tests (Lufttemperatur, relative Luftfeuchtigkeit, heiter oder bewölkt usw.), Nutzungsmuster des Fahrzeugs 12 (Autobahnfahrt, stockender Verkehr, ein Geschwindigkeitsprofil entlang eines Fahrwegs usw.) und Straßenbedingungen (trocken, nass, schneebedeckt usw.) umfassen. Die Daten können außerdem ferner den Zeitpunkt, zu dem ein Diagnosetest durchgeführt wurde, oder den Zeitpunkt, zu dem eine Fahrt stattgefunden hat, umfassen, um die Daten mit Daten von anderen Quellen wie den Datenquellen 18 zu synchronisieren.
Auswählen von Datensätzen für das Bestimmen von Anpassungen für einen Diagnosetest
Der Server 16 kann von den Fahrzeugen 12 und den Datenquellen 18 empfangene Datensätze derart auswählen, dass die Datensätze für das Bestimmen einer Anpassung für eine bestimmte Art von Diagnosetest verwendet werden können. Das Auswählen von Datensätzen kann umfassen, für jeden der Datensätze zu ermitteln, ob eine normalisierende Funktion für das Erzeugen skalierter Testparameterwerte, die auf einer gemeinsamen Skala zusammen mit allen anderen ausgewählten Datensätzen bewertet werden können, identifiziert werden kann. Die gemeinsame Skala kann eine vorher festgelegte Skala für den bestimmten Diagnosetest sein, die z. B. auf einem Referenzfahrzeug, das unter Referenzbetriebsbedingungen betrieben wird, basiert.
Um die Identifikation einer normalisierenden Funktion für Datensätze in Bezug auf einen Diagnosetest zu vereinfachen oder sogar überhaupt möglich zu machen, kann der Server 16 Datensätze von den Fahrzeugen 12 auswählen, die z. B. denselben Diagnosetest durchgeführt haben und z. B. von einem ähnlichen Fahrzeugtyp sind, ähnliche Eigenschaften haben und/oder unter ähnlichen Betriebsbedingungen betrieben wurden.
Fahrzeuge eines ähnlichen Typs können z. B. die Fahrzeuge 12 umfassen, die dieselbe Art von Diagnosetest durchführen und ähnliche Eigenschaften haben und für die möglicherweise eine normalisierende Funktion identifizierbar ist, um Testparameterwerte in Bezug auf Unterschiede zwischen den jeweiligen Fahrzeugen anzupassen. Zum Beispiel können zwei Fahrzeuge 12 vom selben Modelltyp sein und dieselben Antriebsstrangmerkmale (Kraftmaschinenart, Getriebetyp usw.) haben. Ein erstes der Fahrzeuge 12 wurde möglicherweise 110.000 Meilen gefahren, und ein zweites der Fahrzeuge wurde möglicherweise 30.000 Meilen gefahren. Es kann eine Funktion bekannt sein, die die Werte von Testparameterwerten von jedem dieser Fahrzeuge an ein Referenzfahrzeug 12 anpasst. Das Referenzfahrzeug 12 kann zum Beispiel ein Fahrzeug 12 sein, das direkt der Produktion entnommen und unter Laborbedingungen getestet wurde. In ähnlicher Weise können normalisierende Funktionen z. B. für verschiedene Fahrzeugmerkmale (Kraftmaschinenart, Getriebetyp, Baujahr usw.) identifizierbar sein.
Ähnliche Betriebsbedingungen können Betriebsbedingungen umfassen, für die möglicherweise eine normalisierende Funktion identifizierbar ist, um Testparameterwerte in Bezug auf Unterschiede zwischen den Betriebsbedingungen anzupassen. Um zum Beispiel eine bestimmte Anpassung für einen Diagnosetest zu ermitteln, kann der Server 16 Datensätze von den Fahrzeugen 12 auswählen, die unter ähnlichen Wetterbedingungen betrieben wurden. Ähnliche Wetterbedingungen können als innerhalb eines Bereichs von Wetterbedingungen liegend definiert werden, wobei die Testergebnisse gemäß einer Funktion variieren und normalisiert werden können, um Unterschiede bei den Wetterbedingungen zu berücksichtigen. Ähnliche Wetterbedingungen können zum Beispiel umfassen, innerhalb eines Umgebungstemperaturbereichs von –20 bis 30 Grad Celsius und innerhalb eines Bereichs der relativen Luftfeuchtigkeit von 30 % bis 70 % zu liegen.
Der Server 16 kann ferner z. B. Datensätze von den jeweiligen Fahrzeugen 12 und Datenquellen 18 in Bezug auf die Fahrzeuge 12, die auf einem ähnlichen Fahrweg gefahren wurden, auswählen. Ähnliche Fahrwege können als Fahrwege definiert werden, für die eine Funktion verwendet werden kann, um Testergebnisse zwischen den jeweiligen verschiedenen Wegen zu normalisieren. Ähnliche Fahrwege können zum Beispiel Wege umfassen, bei denen die Fahrzeuge 12 bei den 100 Meilen vor dem Durchführen des Diagnosetests z. B. zu 90 % auf denselben Straßen oder auf derselben Autobahnstrecke fahren.
Außerdem kann der Server 16 ferner Datensätze von den jeweiligen Fahrzeugen 12 auswählen, die nach einem ähnlichen Nutzungsmuster gefahren wurden. Ein ähnliches Nutzungsmuster kann zum Beispiel als ein Nutzungsmuster definiert werden, bei dem die Testergebnisse gemäß einer Funktion variieren und normalisiert werden können, um Unterschiede bei den Nutzungsmustern zu berücksichtigen. Zum Beispiel kann ein Nutzungsmuster einen Prozentsatz der Zeit berücksichtigen, in der ein Fahrzeug innerhalb eines Bereichs von vorher festgelegten Geschwindigkeiten wie zwischen 30 und 60 Meilen/Stunde betrieben wurde. Die ersten und zweiten Fahrzeuge 12 können ähnliche Nutzungsmuster haben, wenn der Prozentsatz der Zeit, in der ein erstes Fahrzeug innerhalb eines bestimmten Geschwindigkeitsbereichs (z. B. zu 90 % der Zeit zwischen 30 und 60 Meilen/Stunde) betrieben wurde, bei den 100 Meilen vor dem Durchführen des Diagnosetests innerhalb eines Bereichs von +/–10 % des Prozentsatzes der Zeit liegt, in der das zweite Fahrzeug innerhalb des bestimmten Geschwindigkeitsbereichs betrieben wurde.
Es sei darauf hingewiesen, dass es in einigen Fällen möglich sein kann, Datensätze derart auszuwählen, dass für einen bestimmten Faktor keine Normalisierung erforderlich ist, d. h., dass die Normalisierungsfunktion oder -funktionen eins sind. Zum Beispiel erfordern Daten von zwei Fahrzeugen desselben Modells und Baujahrs und mit denselben Merkmalen möglicherweise keine Normalisierung in Bezug auf den Fahrzeugtyp. Daten von zwei Fahrzeugen 12, die zu einer ähnlichen Tageszeit (zum Beispiel innerhalb eines zeitlichen Abstands von 10 Minuten) auf demselben Autobahnabschnitt unterwegs waren, erfordern möglicherweise keine Normalisierung in Bezug auf den Fahrweg oder die Wetterbedingungen.
Der Server 16 kann Datensätze in Bezug auf Fahrzeuge 12 derart auswählen, dass alle Faktoren außer einem Faktor ähnlich sind und der eine Faktor von den anderen auf eine bestimmte Weise verschieden ist. Auf diese Weise kann der Server 16 dazu in der Lage sein, den Einfluss des einen Faktors, der verschieden ist, auf Diagnosetestergebnisse zu identifizieren.
Zum Beispiel kann der Server 16 Datensätze auswählen, bei denen der Typ jedes Fahrzeugs im Wesentlichen ähnlich ist, die Wetterbedingungen während der Fahrt und während des Tests im Wesentlichen ähnlich waren, die Nutzungsmuster im Wesentlichen ähnlich waren, wobei jedoch ein erster Teil der Fahrzeuge 12 auf einer ersten Strecke und ein zweiter Teil der Fahrzeuge auf einer zweiten Strecke unterwegs war. Basierend auf einem Vergleich der Testergebnisse des ersten Teils der Fahrzeuge 12 mit den Testergebnissen des zweiten Teils der Fahrzeuge 12 kann der Server 16 dazu in der Lage sein, eine Anpassung für Variationen bei den Fahrtrouten zu identifizieren.
Ferner kann der Computer 20 in einigen Fällen Datensätze auswählen, bei denen Normalisierungsfunktionen für mehrere Testparameter nicht bekannt sind. Zum Beispiel kann der Computer 20 Daten in Bezug auf einen bestimmten Typ von Diagnosetest von jedem Fahrzeug 12, das diesen Testtyp durchgeführt hat, umfassen. Durch das Analysieren der Daten kann der Computer 20 Beziehungen zum Beispiel zwischen einem bestimmten Testparameter und einer bestimmten Betriebsbedingung identifizieren, die zuvor nicht bekannt waren.
Normalisieren von Testergebnissen
Wie weiter oben erläutert, kann der Server 16 dafür programmiert sein, Datensätze von den Fahrzeugen 12 derart auszuwählen, dass Daten von jedem Fahrzeug 12 mit Daten von jedem anderen Fahrzeug 12 mit jedem der anderen Datensätze normalisiert werden können. Daten können normalisiert (durch eine Normalisierungsfunktion angepasst) werden, um Unterschiede zum Beispiel zwischen Typen der Fahrzeuge 12 oder Betriebsbedingungen der Fahrzeuge 12 zu kompensieren.
Dies kann zum Beispiel durch das Anpassen jedes der Datensätze an einen Referenzdatensatz erfolgen. Zum Beispiel kann ein Kraftstoffdampfdruck in jedem Fahrzeug 12 je nach einer Dampftemperatur um eine bekannte Funktion variieren. Der Server 16 kann den für jedes Fahrzeug 12 gemessenen Druckwert zusammen mit der Dampftemperatur für das jeweilige Fahrzeug 12 zum Testzeitpunkt aufzeichnen. Der Server 16 kann dann jeden der gemessenen Druckwerte in einen äquivalenten Druck bei einer ausgewählten Referenztemperatur, zum Beispiel 20 Grad Celsius, umwandeln. Auf diese Weise können Druckwerte, die bei verschiedenen Temperaturen gemessen wurden, zur Verwendung in einer Analyse kombiniert werden.
In ähnlicher Weise können Unterschiede zwischen Fahrzeugtypen kompensiert werden, wenn eine Funktion ermittelt werden kann, um die Unterschiede bei gemessenen Werten zwischen den verschiedenen Fahrzeugtypen zum Beispiel auf ein Referenzfahrzeug 12 zu normalisieren. Durch das Normalisieren von Werten auf diese Weise kann der Server 16 die Menge an Daten erhöhen, die beim Ermitteln von Anpassungsfaktoren für bestimmte Diagnosetests verwendet werden können.
Erzeugen von Anpassungen für Diagnosetests
Der Server 16 kann ferner dafür programmiert sein, die Daten von den ausgewählten Datensätzen zu analysieren und eine Anpassung für einen Fahrzeugdiagnosetest basierend auf den Datensätzen zu ermitteln. Zum Beispiel kann der Server 16 dafür programmiert sein, eine Abhängigkeit eines Kraftstoffverdunstungstests von einem Fahrweg zu ermitteln, bevor der Test durchgeführt wird. Der Server 16 kann Daten von mehreren ersten Fahrzeugen 12, die vor dem Durchführen des Kraftstoffverdunstungstests auf einem ersten Weg unterwegs waren, und von mehreren zweiten Fahrzeugen 12, die vor dem Durchführen des Kraftstoffverdunstungstests auf einem zweiten Weg unterwegs waren, sammeln. Der Server 16 kann die Daten von jedem der ersten Fahrzeuge nach Fahrzeugtyp, Betriebsbedingungen wie dem Wetter usw. normalisieren und typische erste Testwertdaten für die mehreren ersten Fahrzeuge identifizieren. Der Server 16 kann ferner die Daten von jedem der zweiten Fahrzeuge nach Fahrzeugtyp, Betriebsbedingungen wie dem Wetter usw. normalisieren und typische zweite Testwertdaten für die mehreren zweiten Fahrzeuge identifizieren. Basierend auf den typischen ersten Testwertdaten und den typischen zweiten Testwertdaten kann der Server 16 Unterschiede bei Testwerten in Bezug auf den Fahrweg identifizieren.
Der Server 16 kann ferner dafür programmiert sein, Anpassungsfaktoren für die mit den ausgewählten Datensätzen verbundenen Fahrzeuge 12 basierend auf der Analyse bereitzustellen. Zum Beispiel kann der Server 16 ermitteln, dass die zweiten Fahrzeuge einen Wert eines bestimmten Testparameters hatten, der gegenüber dem Wert des Testparameters für die ersten Fahrzeuge 12 um durchschnittlich 3 % höher war. Basierend auf dieser Ermittlung kann der Server 16 vorschlagen, einen Schwellwert für den Testwert für die Fahrzeuge 12, die auf dem zweiten Weg unterwegs waren, gegenüber dem Schwellwert für Fahrzeuge, die auf dem ersten Weg unterwegs waren, um 3 % zu erhöhen.
Der Prozess kann zum Beispiel für mehrere Fahrwege wiederholt werden. Auf diese Weise kann ein Diagnosetest für den bestimmten Testparameter an eine Vielzahl von Fahrwegen angepasst werden. Das Anpassen der Testparameter an die Vielzahl von Fahrwegen kann die Zuverlässigkeit (z. B. weniger falsche positive Ergebnisse, weniger falsche negative Ergebnisse usw.) der auf diesen Fahrwegen durchgeführten Diagnosetests erhöhen, und es kann ferner die Anzahl von Fahrwegen erhöhen, die für das Durchführen des Diagnosetests berücksichtigt werden können.
BEISPIELHAFTE TESTDATEN, DIE AUF EINE SCHWELLWERTANPASSUNG HINDEUTEN
Beispielhafte Testdaten, die auf eine Schwellwertanpassung hindeuten, sind in 3A gezeigt. 3A ist ein Diagramm, das eine Verteilung von beispielhaften Sensordaten als eine Funktion eines Betriebsparameterwerts zeigt. Mit „o“ gekennzeichnete Datenpunkte stellen Daten von einer Fahrzeugkomponente oder einem Teilsystem dar, die bzw. das außerhalb einer Spezifikation arbeitet. Mit „*“ gekennzeichnete Datenpunkte stellen Daten von einer Fahrzeugkomponente oder einem Teilsystem dar, die bzw. das innerhalb einer Spezifikation arbeitet.
Ein beispielhafter erster Schwellwert 30, der von dem Betriebsparameter unabhängig ist (d. h., eine horizontale Linie ist) und als ein Schwellwert für Bestanden/Nicht bestanden für den Diagnosetest verwendet werden kann, ist in dem Diagramm angezeigt. Für Datenpunkte oberhalb des ersten Schwellwerts 30 kann zum Beispiel ermittelt werden, dass der Diagnosetest bestanden wurde, und für Datenpunkte unterhalb des ersten Schwellwerts 30 kann ermittelt werden, dass der Diagnosetest nicht bestanden wurde.
Wie in 3A zu sehen ist, befindet sich eine Anzahl von Symbolen „o“, die Fahrzeugkomponenten oder Teilsysteme darstellen, die außerhalb der Spezifikation arbeiten, oberhalb des ersten Schwellwerts 30, und für diese wurde ermittelt, dass der Diagnosetest bestanden wurde. Das heißt, dass der Diagnosetest falsche positive Ergebnisse erzeugen würde. In ähnlicher Weise befindet sich eine Anzahl von Symbolen „*“, die Fahrzeugkomponenten oder Fahrzeugteilsysteme darstellen, die innerhalb der Spezifikation arbeiten, unterhalb des ersten Schwellwerts 30, und für diese wurde ermittelt, dass der Diagnosetest nicht bestanden wurde, was zu falschen negativen Ergebnissen führen würde.
Ein Ansatz für das Reduzieren von falschen positiven und falschen negativen Diagnosetestergebnissen besteht in der Einführung einer ersten Pufferzone 32. Der Computer 20, der den Diagnosetest einführt, könnte zum Beispiel keine Fahrzeugkomponenten oder Teilsysteme bewerten, bei denen Datenpunkte innerhalb der ersten Pufferzone 32 liegen. Dies kann jedoch zu einer niedrigen Entscheidungsrate für den Diagnosetest führen.
Alternativ dazu kann jedoch der Server 16 oder eine andere Datenverarbeitungsvorrichtung, wie in 3A ferner gezeigt, basierend auf einer Analyse von Daten von mehreren Fahrzeugen 12 eine Beziehung zwischen den Sensordaten und dem Betriebsparameter identifizieren. Ein neuer Schwellwert 34 für den Diagnosetest kann erzeugt werden, um die Beziehung zwischen den Sensordaten und dem Betriebsparameter zu berücksichtigen.
Im Fall von 3A ist ersichtlich, dass die Untergrenze der Sensordaten „*“ bei einer Erhöhung des Betriebsparameters erhöht wird. In ähnlicher Weise wird die Obergrenze von „o“ bei einer Erhöhung des Betriebsparameters erhöht. Basierend auf den Daten kann ein zweiter Schwellwert 34 für das Durchführen des Diagnosetests ermittelt werden, der die Beziehung zwischen Sensordatenwerten und dem Betriebsparameter berücksichtigt. Der zweite Schwellwert 34 führt zu einer wesentlichen Reduzierung von falschen positiven („o“ oberhalb des Schwellwerts) und falschen negativen („*“ unterhalb des Schwellwerts) Diagnosetestergebnissen.
Nachdem eine Beziehung zwischen den Sensordaten und dem Betriebsparameter identifiziert wurde, können Daten alternativ oder zusätzlich zu dem Anpassen eines Schwellwerts für einen Diagnosetest umgewandelt werden, um die Beziehung zu berücksichtigen. 3B ist ein Diagramm, das die Verteilung von beispielhaften Sensordaten für einen selben Test als eine Funktion desselben Betriebsparameterwerts anzeigt, wobei die Sensordaten durch eine Funktion umgewandelt wurden, um umgewandelte Sensordaten zu erzeugen. Die Funktion berücksichtigt die identifizierte Beziehung zwischen den Sensordaten und dem Betriebsparameter. Durch das Verwenden der umgewandelten Daten kann der Diagnosetest mit einem Schwellwert durchgeführt werden, der von dem Betriebsparameter unabhängig ist (eine horizontale Linie ist). Zum Beispiel können die Daten nach der Umwandlung der Daten zur Berücksichtigung der Beziehung zwischen den Sensordaten und dem Betriebsparameter wie in 3B gezeigt verteilt sein. Ein dritter Schwellwert 36, der von dem Betriebsparameter unabhängig ist (horizontal), kann ermittelt werden, um zwischen (umgewandelten) Sensordaten zu unterscheiden, die den Test bestanden/nicht bestanden haben. Aufgrund der Umwandlung der Sensordaten wird eine wesentlich niedrigere Anzahl von falschen positiven und falschen negativen Ergebnissen beobachtet.
Wie bei der vorherigen 3A könnte auch eine zweite Pufferzone 38 angewendet werden. In diesem Fall könnten die falschen positiven und die falschen negativen Ergebnisse beseitigt werden. Es würde sich jedoch eine wesentlich kleinere Anzahl von Ergebnissen ohne Entscheidung ergeben.
Zum Beispiel könnten die 3A und 3B Diagramme eines Kraftstoffverdunstungstests sein. Die Überwachung auf Undichtigkeiten in einer Kraftstoffverdunstungsanlage (EVAP) kann z. B. nach dem EONV-Verfahren (natürlicher Unterdruck bei abgeschalteter Kraftmaschine) durchgeführt werden. Die Y-Achse jedes Diagramms zeigt eine Skala für normalisierte Werte für eine Druckänderung nach einem Ausschaltereignis an. Die X-Achse jedes Diagramms zeigt eine Dampftemperatur an. Wie in 3A gezeigt, können die Sensordaten eine Abhängigkeit von der Dampftemperatur derart zeigen, dass die Untergrenze von Sensordaten von Fahrzeugkomponenten oder Teilsystemen, die innerhalb der Spezifikation arbeiten, bei einer Erhöhung der Dampftemperatur erhöht wird und die Obergrenze von Sensordaten von Fahrzeugkomponenten oder Teilsystemen, die außerhalb der Spezifikation arbeiten, ebenfalls erhöht wird. Dies kann zu einer großen Anzahl von falschen positiven („o“ oberhalb des Schwellwerts) und falschen negativen („*“ unterhalb des Schwellwerts) Diagnosetestergebnissen führen.
Der Server 16 kann jedoch basierend auf der beobachteten Abhängigkeit der Sensordatenwerte von der Dampftemperatur den zweiten Schwellwert 34 von 3A erzeugen. Das Durchführen des Diagnosetests nach dem zweiten Schwellwert 34 kann zu einer reduzierten Anzahl von falschen positiven und falschen negativen Diagnosetestergebnissen führen.
3B kann dieselben Daten wie in 3A gezeigt darstellen, wobei die Daten zum Beispiel von dem Server 16 umgewandelt wurden, um die Beziehung zwischen Druckänderungen und der Dampftemperatur zu berücksichtigen. Wie weiter oben erläutert, kann dann ein Diagnosetest basierend auf dem dritten Schwellwert 36, der von der Dampftemperatur unabhängig ist, auf die umgewandelten Daten angewendet werden.
BEISPIELHAFTE PROZESSABLÄUFE
4 ist ein Diagramm eines beispielhaften Prozesses 400 für das Sammeln von Daten, der für das Erzeugen einer Anpassung für einen On-Board-Diagnose-Test verwendet wird. Der Prozess startet in einem Block 405.
In dem Block 405 ermittelt der Computer 20 des Fahrzeugs 12, ob ein Auslöseereignis für das Sammeln von Daten in Bezug auf einen Diagnosetest vorliegt, wie weiter oben beschrieben (und wobei Auslöseereignisse für OBD-Tests und dergleichen bekannt sind). In dem Fall, dass kein Auslöseereignis erkannt wird, fährt der Prozess in dem Block 405 fort. In dem Fall, dass ein Auslöseereignis erkannt wird, fährt der Prozess in einem Block 410 fort.
In dem Block 410 sammelt der Computer 20 Daten in Bezug auf den Diagnosetest, wie weiter oben beschrieben. Der Computer 20 kann eine oder mehrere Steuerungen betätigen, zum Beispiel eine Ventilsteuerung, um ein Ventil zu öffnen oder zu schließen, oder einen Zylinder, um ein Druckniveau in einem Hohlraum zu ändern. Der Computer 20 kann ferner Daten von einem oder mehreren Sensoren 22 empfangen. Der Computer 20 kann die Daten zusammen mit anderen Daten in Bezug auf den Diagnosetest wie einem Zeitpunkt des Tests, Umgebungsbedingungen (durchschnittliche Umgebungstemperatur, relative Luftfeuchtigkeit, durchschnittlicher barometrischer Druck, durchschnittliche Dampftemperatur, durchschnittlicher Dampfdruck usw.) während einer oder mehreren Ausführungsphasen des Tests, einem Ort (zum Beispiel über ein globales Positionsbestimmungssystem (GPS) erfasst), Fahrzeugbetriebsbedingungen (eingeschaltet, ausgeschaltet, Fahrzeuggeschwindigkeit, Kraftmaschinendrehzahl usw.), Rückmeldungen von Steuerungen (Ventilpositionen, Anliegen von elektrischem Strom an einer Kraftmaschine) usw. speichern. Nach dem Speichern der Sensordaten und anderen Daten in Bezug auf den Diagnosetest fährt der Prozess 400 in einem Block 415 fort.
In dem Block 415 ermittelt der Computer 20, ob der Server 16 für den Empfang von Daten verfügbar ist. Zum Beispiel kann der Computer 20 eine Nachricht an den Server 16 senden, in der angegeben wird, dass Daten in Bezug auf eine bestimmte Art von Diagnosetest verfügbar sind, und er kann eine Bestätigung dafür anfordern, dass der Server 16 für das Hochladen der Daten verfügbar ist. In dem Fall, dass der Server 16 zum Beispiel innerhalb eines vorher festgelegten Zeitraums wie 1 Minute antwortet, dass der Server 16 für das Hochladen der Daten verfügbar ist, fährt der Prozess 400 in einem Block 420 fort. In dem Fall, dass der Server 16 nicht antwortet oder angibt, dass der Server 16 nicht für das Hochladen der Daten verfügbar ist, endet der Prozess 400.
In dem Block 420 lädt das Fahrzeug 12 die Daten wie bekannt auf den Server 16 hoch. Der Prozess 400 fährt dann in einem Block 425 fort.
In dem Block 425 speichert der Server 16 die Daten. Die Testparameterdaten können zusammen mit der Identifikation des Fahrzeugs 12, das die Daten gemessen/bereitgestellt hat, Betriebsbedingungen des Fahrzeugs 12 zu einem Zeitpunkt des Messens der Daten und/oder vor dem Messen der Daten und Daten von Datenquellen 18 wie Wetterbedingungen, Verkehrsbedingungen usw. zu einem Zeitpunkt des Messens der Testparameter gespeichert werden.
On-Board- und Off-Board-Daten können querverglichen werden, um zu ermitteln, ob wesentliche Unterschiede bestehen. Wesentliche Unterschiede können zum Beispiel Unterschiede, die größer als +/–10 % sind, ein Unterschied gegenüber einem Mittelwert von mehr als 3 Standardabweichungen usw. sein. In dem Fall, dass ein bestimmtes Fahrzeug 12 eine konsistente Inkonsistenz bei einem oder mehreren seiner Sensoren zeigt, die für das Bewerten der Effektivität oder Vertrauenswürdigkeit einer Überwachungsausführung von entscheidender Bedeutung ist, sind die Informationen bei einem Vergleich mit den Fahrzeugen 12, bei denen diese Probleme nicht bestehen, zu ignorieren. Wenn der Server 16 die Daten gespeichert hat, endet der Prozess 400.
5 ist ein Diagramm eines beispielhaften Prozesses 500 für das Erzeugen einer Anpassung eines Schwellwerts für einen On-Board-Diagnose-Test basierend auf Daten von mehreren Fahrzeugen 12. Der Prozess 500 startet in einem Block 505.
In dem Block 505 kann der Server 16 ermitteln, ob ein Auslöseereignis für das Analysieren von Daten in Bezug auf einen Diagnosetest eingetreten ist. Der Server 16 kann zum Beispiel dafür programmiert sein, Daten in Bezug auf den Diagnosetest periodisch, zum Beispiel einmal pro Tag, zu analysieren. Alternativ dazu kann der Server 16 dafür programmiert sein, Daten zu analysieren, wenn der Server 16 Daten von einer zusätzlichen vorher festgelegten Anzahl von Fahrzeugen 12, zum Beispiel von 100 zusätzlichen Fahrzeugen 12, empfangen hat. Als noch ein weiteres Beispiel kann der Server 16 eine Eingabe von einem Bediener empfangen, in der angegeben wird, dass der Server 16 Daten in Bezug auf den Diagnosetest analysieren soll. In dem Fall, dass der Server 16 ermittelt, dass ein Auslöseereignis eingetreten ist, fährt der Prozess 500 in einem Block 510 fort. In dem Fall, dass der Server 16 nicht ermittelt, dass ein Auslöseereignis eingetreten ist, fährt der Prozess 500 in dem Block 505 fort.
In dem Block 510 ermittelt der Server 16, ob der Server 16 zusätzliche Daten sammeln muss, um die Analyse durchzuführen. Um zum Beispiel eine sinnvolle Analyse von Daten in Bezug auf einen bestimmen Diagnosetest durchzuführen, kann der Server 16 Daten von 100 Fahrzeugen 12 oder 100 Fahrzeugen 12, die von einem ähnlichen Typ sind und/oder unter ähnlichen Betriebsbedingungen getestet wurden, erfordern. In dem Fall, dass der Server 16 ermittelt, dass der Server 16 zusätzliche Daten sammeln muss, fährt der Prozess 500 in einem Block 515 fort. In dem Fall, dass der Server 16 ermittelt, dass der Server 16 über ausreichende Daten verfügt, fährt der Prozess 500 in einem Block 520 fort.
In dem Block 515 sammelt der Server 16 Daten von einem oder mehreren zusätzlichen Fahrzeugen 12. Der Server 16 kann ein oder mehrere Fahrzeuge 12 identifizieren, die möglicherweise den Diagnosetest durchgeführt haben, und er kann anfordern, dass die Fahrzeuge 12 dem Server 16 Daten in Bezug auf den Test bereitstellen. Der Server 16 kann die Daten von den Fahrzeugen 12 empfangen.
Der Server 16 kann die Sensordaten zusammen mit den Fahrzeugidentifikationsdaten, den Betriebsbedingungsdaten usw. derart speichern, dass alle für eine Analyse eines bestimmten Testparameters erforderlichen Daten aus dem Datenspeicher abgerufen werden können. Der Server 16 kann ferner Daten von Datenquellen 18 in Bezug auf die Diagnosetestdaten sammeln. Zum Beispiel kann der Server 16 basierend auf dem Zeitpunkt, zu dem ein Test durchgeführt wurde, Wetterdaten, Verkehrsdaten, GPS-Daten usw. in Bezug auf das Fahrzeug 12 oder die Umgebung des Fahrzeugs 12 während der Durchführung des Diagnosetests herunterladen. Nach dem Empfangen der Daten von dem Computer 20 und den Datenquellen 18 und dem Speichern der Daten fährt der Prozess 500 in einem Block 520 fort.
In dem Block 520 wählt der Server 16 Datensätze aus, die verwendet werden, um eine Anpassung des Diagnosetests zu erzeugen, wie weiter oben beschrieben. Der Prozess 500 fährt in einem Block 525 fort.
In dem Block 525 erzeugt der Server 16 basierend auf den ausgewählten Datensätzen in Bezug auf den Diagnosetest eine Anpassung des Diagnosetests, wie in dem Abschnitt weiter oben beschrieben. Der Prozess 500 fährt in einem Block 530 fort.
In dem Block 530 kann der Server 16 die Anpassung des Diagnosetests für ein oder mehrere Fahrzeuge 12 bereitstellen. Zusätzlich oder alternativ dazu kann der Server 16 die erzeugte Anpassung speichern, bis die Anpassung von einem Fahrzeug 12 angefordert wird. Nach dem Bereitstellen der Anpassung des Diagnosetests für das eine oder die mehreren Fahrzeuge und/oder dem Speichern des Anpassungsfaktors endet der Prozess 500.
6 ist ein Diagramm eines beispielhaften Prozesses 600 für das Anpassen eines On-Board-Diagnose-Test-Schwellwerts basierend auf einer Anpassung. Der Prozess 600 startet in einem Block 605.
In dem Block 605 ermittelt der Computer 20 des Fahrzeugs 12, ob ein Auslöseereignis für das Aktualisieren eines Diagnosetests für ein oder mehrere Fahrzeuge 12 vorliegt.
Zum Beispiel kann der Computer 20 dafür programmiert sein, einen Diagnosetest periodisch, z. B. einmal pro Tag oder einmal alle drei Monate, zu aktualisieren. Als ein anderes Beispiel kann der Computer 20 ermitteln, dass das Fahrzeug 12 dafür programmiert sein kann, den Diagnosetest zu aktualisieren, wenn sich das Fahrzeug 12 von einem ersten geografischen Ort zu einem zweiten geografischen Ort bewegt hat (z. B., wenn es sich um mehr als 100 Meilen bewegt hat). Verschiedene geografische Bereiche können dazu führen, dass die Umgebungsbedingung, z. B. Temperaturschwankungen, barometrischer Druck, relative Luftfeuchtigkeit, usw., wesentlich variiert. Eine Schwellwerteinstellung eines Diagnosetests für den ersten geografischen Bereich kann von der entsprechenden Schwellwerteinstellung eines Diagnosetests für den zweiten geografischen Bereich verschieden sein. Als ein anderes Beispiel kann der Computer 20 dafür programmiert sein, den Diagnosetest zu aktualisieren, wenn eine Fahrzeugkomponente den Diagnosetest nicht bestanden hat, um sicherzustellen, dass der Diagnosetest mit den aktuellsten Testparametern durchgeführt wird. In dem Fall, dass der Computer 20 einen Testauslöser identifiziert, fährt der Prozess in einem Block 610 fort. Ansonsten fährt der Prozess in dem Block 605 fort.
In dem Block 610 fordert der Computer 20 die Anpassung von dem Server 16 an und empfängt diese. Der Prozess 600 fährt in einem Block 615 fort.
In dem Block 615 passt der Computer 20 den Diagnosetest an. Der Computer 20 kann z. B. einen gespeicherten Parameter oder eine gespeicherte Funktion, der bzw. die einen Schwellwert in dem Diagnosetest angibt, ändern. Der Prozess 600 endet.
SCHLUSSFOLGERUNG
Datenverarbeitungsvorrichtungen, wie die hier beschriebenen, umfassen im Allgemeinen jeweils Anweisungen, die von einer oder mehreren Datenverarbeitungsvorrichtungen, wie den oben genannten, ausführbar sind, und zum Durchführen von Blöcken oder Schritten der Prozesse, wie oben beschrieben. Beispielsweise können oben beschriebene Prozessblöcke als computerausführbare Anweisungen enthalten sein.
Computerausführbare Anweisungen können von Computerprogrammen kompiliert oder interpretiert werden, die unter Verwendung einer Vielzahl von Programmiersprachen und/oder - technologien, einschließlich unter anderem Java^TM, C, C++, Visual Basic, Java Script, Perl, HTML usw., erstellt wurden, wobei diese entweder allein oder in Kombination verwendet werden können. Im Allgemeinen empfängt ein Prozessor (z. B. ein Mikroprozessor) Anweisungen, z. B. von einem Speicher, einem computerlesbaren Medium usw., und führt diese Anweisungen aus, wobei er einen oder mehrere Prozesse, einschließlich eines oder mehrerer der hier beschriebenen Prozesse, ausführt. Solche Anweisungen und andere Daten können in Dateien gespeichert und unter Verwendung vielfältiger computerlesbarer Medien übertragen werden. Eine Datei in einer Datenverarbeitungsvorrichtung ist allgemein eine Sammlung von auf einem computerlesbaren Medium, wie einem Speichermedium, einem Direktzugriffsspeicher usw., gespeicherten Daten.
Ein computerlesbares Medium umfasst jedes Medium, das beim Bereitstellen von Daten (z. B. Anweisungen) partizipiert, die von einem Computer gelesen werden kann. Ein solches Medium kann viele Formen annehmen, einschließlich u.a. nicht-flüchtige Medien, flüchtige Medien usw. Nicht-flüchtige Medien umfassen beispielsweise optische oder magnetische Platten und andere persistente Speicher. Flüchtige Medien umfassen einen dynamischen Direktzugriffsspeicher (DRAM, Dynamic Random Access Memory), welcher normalerweise einen Hauptspeicher darstellt. Herkömmliche Formen computerlesbarer Medien umfassen beispielsweise eine Diskette, eine Floppy Disk, eine Festplatte, ein Magnetband, irgendein anderes magnetisches Medium, eine CD-ROM, eine DVD, irgendein anderes optisches Medium, Lochkarten, Lochband, irgendein anderes physisches Medium mit Lochmustern, einen RAM, einen PROM, einen EPROM, einen Flash-EEPROM, irgendeinen anderen Speicherchip oder irgendeine andere Speicherkarte oder irgendein anderes Medium, das ein Computer lesen kann.
Alle in den Ansprüchen verwendeten Begriffe sollen in ihrer einfachen und üblichen Bedeutung verstanden werden, wie sie auch von einem Fachmann verstanden werden, sofern hier nicht explizit eine gegenteilige Angabe gemacht wird. Insbesondere ist die Verwendung von Artikeln im Singular, wie beispielsweise „ein/e/er“, „der, die, das“, „jene/r/s“ usw., so zu verstehen, dass eines oder mehrere der aufgezeigten Elemente gemeint sein könnten, sofern nicht in einem Anspruch eine explizite gegenteilige Einschränkung angeführt wird.
Der Begriff „beispielhaft“ wird hier im Sinne des Kennzeichnens eines Beispiels verwendet, z. B. sollte ein Verweis auf eine „beispielhafte Vorrichtung“ einfach als ein Verweisen auf ein Beispiel einer Vorrichtung verstanden werden.
Das Adverb „ungefähr“, das einen Wert oder ein Ergebnis modifiziert, bedeutet, dass eine Gestalt, eine Struktur, ein Maß, ein Wert, eine Bestimmung, eine Berechnung usw. von einer exakt beschriebenen Geometrie, Entfernung, Messung, einem Wert, einer Bestimmung, einer Berechnung usw. abweichen kann, wegen Unzulänglichkeiten bei Materialien, beim Bearbeiten, Herstellen, bei Sensormessungen, Berechnungen, Verarbeitungszeit, Kommunikationszeit usw.
In den Zeichnungen bezeichnen die gleichen Referenznummern die gleichen Elemente. Ferner könnten einige dieser oder alle diese Elemente geändert werden. Im Hinblick auf die hier beschriebenen Medien, Prozesse, Systeme, Verfahren usw. versteht es sich, dass, obwohl die Schritte solcher Prozesse usw. als in einer bestimmten geordneten Reihenfolge stattfindend beschrieben wurden, solche Prozesse mit den beschriebenen Schritten auch in einer von der hier beschriebenen Reihenfolge abweichenden Reihenfolge durchgeführt werden könnten. Des Weiteren versteht es sich, dass bestimmte Schritte gleichzeitig durchgeführt werden können, dass weitere Schritte hinzugefügt werden können, oder dass bestimmte hier beschriebene Schritte ausgelassen werden können. Mit anderen Worten dienen die hier bereitgestellten Beschreibungen von Prozessen dem Zweck der Veranschaulichung bestimmter Ausführungsformen und sollten keinesfalls als Beschränkung der beanspruchten Erfindung ausgelegt werden.

Claims

System, das eine Datenverarbeitungsvorrichtung mit einem Prozessor und einem Speicher umfasst, wobei der Speicher von dem Prozessor ausführbare Anweisungen derart speichert, dass der Prozessor für Folgendes programmiert ist: Empfangen von jedem von mehreren Fahrzeugen von jeweiligen Diagnosetestdatensätzen in Bezug auf einen durchgeführten Diagnosetest, wobei jeder Diagnosetestdatensatz einen Testausgabewert und einen oder mehrere entsprechende Testbedingungswerte umfasst; Auswählen von wenigstens einigen der Testausgabewerte basierend wenigstens teilweise auf dem Auswählen einer Funktion für das Verknüpfen eines jeweiligen ausgewählten Testausgabewerts mit Testausgabewerten von verschiedenen Diagnosedatensätzen; Bereitstellen von allen Testausgabewerten und den entsprechenden Testbedingungswerten als Eingabe für die ausgewählte Funktion für das Erhalten von mehreren skalierten Testausgabewerten; und Erzeugen einer Anpassung des Diagnosetests basierend wenigstens teilweise auf den skalierten Testausgabewerten.
System nach Anspruch 1, wobei der Prozessor ferner für Folgendes programmiert ist: Bereitstellen der Anpassung für ein Fahrzeug, das einen der ausgewählten Testausgabewerte bereitgestellt hat.
System nach Anspruch 1, wobei die Anpassung eine Anpassung eines Schwellwerts für das Bewerten des Testausgabewerts ist.
System nach Anspruch 1, wobei die skalierten Ausgabewerte auf einer für den Diagnosetest vorher festgelegten Skala vergleichbar sind.
System nach Anspruch 4, wobei die für den Diagnosetest vorher festgelegte Skala wenigstens teilweise auf einem Referenzfahrzeug basiert.
System nach Anspruch 4, wobei die für den Diagnosetest vorher festgelegte Skala wenigstens teilweise auf Referenztestbedingungen basiert.
System nach Anspruch 1, wobei die ausgewählte Funktion für das Annehmen von wenigstens einigen der Testausgabewerte eins ist.
System nach Anspruch 1, wobei das Auswählen von wenigstens einigen der Ausgabewerte teilweise auf der Fahrtroute und/oder dem Umgebungslufttemperaturwert und/oder dem barometrischen Druck und/oder der relativen Luftfeuchtigkeit und/oder dem Nutzungsmuster basiert.
System nach Anspruch 1, wobei der Testdatenausgabewert einen natürlichen Unterdruck bei abgeschalteter Kraftmaschine umfasst.
System nach Anspruch 1, wobei die Testbedingungswerte einen Kraftstoffstand umfassen.
System nach Anspruch 1, wobei der Testdatenausgabewert eine Luftmassensummierung vom Einschalten bis zum Ausschalten umfasst.
System nach Anspruch 1, das ferner eine zweite Datenverarbeitungsvorrichtung umfasst, die einen zweiten Prozessor und einen zweiten Speicher umfasst, wobei der zweite Speicher von dem zweiten Prozessor ausführbare Anweisungen derart speichert, dass der zweite Prozessor für Folgendes programmiert ist: Empfangen des Testausgabewerts von einem Sensor in einem Fahrzeug, und Senden des Testausgabewerts zusammen mit einer Fahrzeugidentifikation und den entsprechenden Testbedingungen an den Prozessor.
System nach Anspruch 12, wobei der zweite Prozessor ferner für Folgendes programmiert ist: Empfangen der Anpassung des Diagnosetests von dem Prozessor; und Durchführen des Diagnosetests basierend auf der Anpassung.
Verfahren, das Folgendes umfasst: Empfangen, von einem Prozessor, von jedem von mehreren Fahrzeugen von jeweiligen Diagnosetestdatensätzen in Bezug auf einen durchgeführten Diagnosetest, wobei jeder Diagnosetestdatensatz einen Testausgabewert und einen oder mehrere entsprechende Testbedingungswerte umfasst; Auswählen von wenigstens einigen der Testausgabewerte basierend wenigstens teilweise auf dem Auswählen einer Funktion für das Verknüpfen eines jeweiligen ausgewählten Testausgabewerts mit Testausgabewerten von verschiedenen Diagnosedatensätzen; Bereitstellen von allen Testausgabewerten und den entsprechenden Testbedingungswerten als Eingabe für die ausgewählte Funktion, um mehrere skalierte Testausgabewerte zu erhalten; und Erzeugen einer Anpassung des Diagnosetests basierend wenigstens teilweise auf den skalierten Testausgabewerten.
Verfahren nach Anspruch 14, das ferner Folgendes umfasst: Bereitstellen der Anpassung für ein Fahrzeug, das einen der ausgewählten Testausgabewerte bereitgestellt hat.
Verfahren nach Anspruch 14, wobei die skalierten Ausgabewerte auf einer für den Diagnosetest vorher festgelegten Skala vergleichbar sind.
Verfahren nach Anspruch 16, wobei die für den Diagnosetest vorher festgelegte Skala wenigstens teilweise auf einem Referenzfahrzeug basiert.
Verfahren nach Anspruch 17, wobei die für den Diagnosetest vorher festgelegte Skala wenigstens teilweise auf Referenztestbedingungen basiert.
Verfahren nach Anspruch 14, das ferner Folgendes umfasst: Empfangen, von einem zweiten Prozessor, des Testausgabewerts von einem Sensor in einem Fahrzeug; und Senden, von dem zweiten Prozessor, des Testausgabewerts zusammen mit einer Fahrzeugidentifikation und den entsprechenden Testbedingungen an den Prozessor.
Verfahren nach Anspruch 19, das ferner Folgendes umfasst: Empfangen, von dem zweiten Prozessor, der Anpassung des Diagnosetests von dem Prozessor; und Durchführen, von dem zweiten Prozessor, des Diagnosetests basierend auf der Anpassung.