DE102020104555A1

DE102020104555A1 - Planung und ausführung einer bordeigenen diagnostischen überwachung

Info

Publication number: DE102020104555A1
Application number: DE102020104555.7A
Authority: DE
Inventors: Aed M. Dudar; Fling Tseng
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2019-02-25
Filing date: 2020-02-20
Publication date: 2020-08-27
Also published as: US11210870B2; CN111612937A; US20200273262A1

Abstract

Die Offenbarung stellt die Planung und Ausführung einer bordeigenen diagnostischen Überwachung bereit. Eine erste Steuerung empfängt eine diagnostische Empfehlung von einem Cloud-Server. Eine zweite Steuerung, die mit der ersten Steuerung über einen Fahrzeugbus in Kommunikation steht, setzt als Reaktion auf ein Auftreten einer Fahrzeugbedingung, welche eine Ausführung einer bordeigenen diagnostischen (OBD) Überwachung auslöst, die Ausführung der OBD-Überwachung aus, während sich das Fahrzeug innerhalb einer Region befindet, die durch die diagnostische Empfehlung spezifiziert ist. Standorte in diagnostischen Ergebnisdaten werden korreliert, um Gruppen von Standorten zu identifizieren, die eine vorbestimmte Anzahl von Ausführungen einer bordeigenen diagnostischen (OBD) Überwachung beinhalten. Als Reaktion darauf, dass eine vorhergesagte Erfolgswahrscheinlichkeit für die Ausführung der OBD-Überwachung für einen der Gruppen von Standorten, die anhand der diagnostischen Ergebnisdaten berechnet wurde, unter einem Aktivierungsschwellenwert liegt, wird eine Nachricht an ein Fahrzeug gesendet, durch die weitere Ausführungen der OBD-Überwachung an dem Standort ausgesetzt werden.

Description

TECHNISCHES GEBIET
Aspekte der Offenbarung betreffen im Allgemeinen die Planung und Ausführung von bordeigenen diagnostischen Überwachungen.
ALLGEMEINER STAND DER TECHNIK
Bordeigene Diagnose (on-board diagnostics - OBD) bezieht sich auf die Selbstdiagnose- und Meldefähigkeiten eines Fahrzeugs. OBD-Systeme gewähren dem Fahrzeugbesitzer oder dem Reparaturtechniker Zugriff auf den Status der verschiedenen Fahrzeugteilsysteme. OBD-II stellt Zugriff auf Daten von der Motorsteuereinheit (engine control unit - ECU) bereit und bietet eine wertvolle Informationsquelle bei der Problembehebung in einem Fahrzeug. Ein Fahrzeug kann einen OBD-Anschluss enthalten, der Zugriff auf die OBD-Diagnoseinformationen bereitstellt. OBD-Scannervorrichtungen können an den OBD-Anschluss angeschlossen sein und werden zum Empfangen und Analysieren der Diagnoseinformationen verwendet.
KURZDARSTELLUNG
In einem oder mehreren veranschaulichenden Beispielen beinhaltet ein Fahrzeug eine erste Steuerung, die so konfiguriert ist, dass sie eine diagnostische Empfehlung von einem Cloud-Server empfängt. Das Fahrzeug beinhaltet ebenfalls eine zweite Steuerung, die mit der ersten Steuerung über einen Fahrzeugbus in Kommunikation steht und so konfiguriert ist, dass sie als Reaktion auf ein Auftreten einer Fahrzeugbedingung, welche eine Ausführung einer bordeigenen diagnostischen (OBD) Überwachung auslöst, die Ausführung der OBD-Überwachung aussetzt, während sich das Fahrzeug innerhalb einer Region befindet, die durch die diagnostische Empfehlung spezifiziert ist.
In einem oder mehreren veranschaulichenden Beispielen beinhaltet ein System einen Speicher, der diagnostische Ergebnisdaten von einer Vielzahl von Fahrzeug speichert, wobei jeder Eintrag der diagnostischen Ergebnisdaten Daten enthält, die angeben, ob die Ausführung einer OBD-Überwachung durch ein Fahrzeug erfolgreich abgeschlossen wurde, und einen Standort des Fahrzeugs während der Ausführung der OBD-Überwachung. Das System beinhaltet ebenfalls einen Prozessor, der so programmiert ist, dass er als Reaktion darauf, dass eine vorhergesagte Erfolgswahrscheinlichkeit für die Ausführung der OBD-Überwachung für einen Standort, die anhand der diagnostischen Ergebnisdaten berechnet wurde, unter einem Aktivierungsschwellenwert liegt, eine Nachricht an die Fahrzeuge sendet, durch die weitere Ausführungen der OBD-Überwachung an dem Standort ausgesetzt werden.
In einem oder mehreren veranschaulichenden Beispielen beinhaltet ein Verfahren Korrelieren von Standorten in diagnostischen Ergebnisdaten, die Gruppen von Standorten identifizieren und mindestens eine vorbestimmte Anzahl von Ausführungen einer bordeigenen diagnostischen (OBD) Überwachung beinhalten; und als Reaktion darauf, dass eine vorhergesagte Erfolgswahrscheinlichkeit für die Ausführung der OBD-Überwachung für einen der Gruppen von Standorten, die anhand der diagnostischen Ergebnisdaten berechnet wurde, unter einem Aktivierungsschwellenwert liegt, Senden einer Nachricht an ein Fahrzeug, durch die weitere Ausführungen der OBD-Überwachung an dem Standort ausgesetzt werden.
Figurenliste

1 veranschaulicht ein beispielhaftes System für die intelligente Durchführung von OBD-Überwachungen;
2 veranschaulicht ein Beispiel für eine Karte, die durch Crowdsourcing erhaltene diagnostische Ergebnisdaten entlang einer Fahrtroute zeigt;
3 veranschaulicht einen beispielhaften Prozess zum Senden von diagnostischen Empfehlungen für OBD-Überwachungen auf der Grundlage von diagnostischen Ergebnisdaten; und
4 veranschaulicht einen beispielhaften Prozess für die intelligente Durchführung von OBD-Überwachungen, wie durch die diagnostischen Empfehlungen angeregt.

DETAILLIERTE BESCHREIBUNG
Nach Bedarf werden in der vorliegenden Schrift detaillierte Ausführungsformen der vorliegenden Erfindung offenbart; dabei versteht es sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen ausgeführt sein kann. Die Figuren sind nicht zwingend maßstabsgetreu; einige Merkmale können vergrößert oder verkleinert dargestellt sein, um Details bestimmter Komponenten zu zeigen. Deshalb sind in dieser Schrift offenbarte konkrete strukturelle und funktionelle Details nicht als einschränkend zu interpretieren, sondern lediglich als repräsentative Grundlage, um den Fachmann die vielfältige Verwendung der vorliegenden Erfindung zu lehren.
OBD-Überwachungen sind Selbstprüfungsroutinen, die von der Fahrzeugelektronik ausgeführt werden, um Einblicke in den Betrieb des Fahrzeugs bereitzustellen. Einige Beispiele für OBD-Überwachungen sind Routinen zur Überwachung von EVAP-, AGR-, Ch-Sensoren (zu denen Sensoren an der Vorderseite und/oder am Heck des Fahrzeugs gehören können), Fehlzündungsdetektion und Katalysatoren. Einige OBD-Überwachungen sind kontinuierlich und protokollieren unabhängig von den Umständen. Andere sind ratenbasiert, d. h., sie werden während oder nach einer Fahrt aktiviert. Als einige beispielhafte Bedingungen für das Ausführen einer ratenbasierten Überwachung kann das Überwachen als Reaktion auf eins oder mehrere von Erreichen der Motorkühlmitteltemperatur einer vordefinierten Temperatur, einer Kraftstoffsteuerung mit geschlossenem Regelkreis oder gleichbleibenden Fahrzeugfahrbedingungen ausgelöst werden.
Jede ratenbasierte Überwachung darf höchstens einmal pro Fahrt ausgeführt werden und nur als Reaktion darauf, dass die Auslösekriterien für die Einleitung der Überwachung erfüllt sind. Folglich kann jede ratenbasierte Überwachung eine eindeutige Nummer der Überwachungsleistung bei der Verwendung (in-use monitoring performance - IUMP) aufweisen. Die IUMP kann Vorschriften (z. B. Emissionsvorschriften) unterliegen, sodass eine Überwachung bei der Detektion eines Fehlers wirksam sein muss und auch mit einer ausreichenden Rate, wie durch die Vorschriften definiert, vollständig ausgeführt werden muss. Zum Beispiel kann es erforderlich sein, dass in Nordamerika verkaufte Fahrzeuge eine EVAP-Leckdetektion als Teil der OBD-II-Anforderungen durchführen. Umweltbewusste Staaten verlangen, dass Fahrzeuge im Rahmen des Clean Air Act (CAA) Section 177 auf 0,02" große Lecks überwacht werden. Ab dem Modellj ahr 2017 verfügte jeder Bundesstaat der Vereinigten Staaten über eine Anforderung für die Durchführung des 0,02"-Lecktests. Der 0,02"-Lecktest weist auch eine Anforderung bezüglich der Abschlusshäufigkeit auf, die als Überwachungsleistung bei der Verwendung (IUMP) von 26 % bezeichnet wird. Die Bruttoleckprüfung muss eine IUMP-Rate von 62 % aufweisen.
Unter einigen Umständen können Fahrzeuge nicht in der Lage sein, OBD-Überwachungen oft genug auszuführen, um die geforderte Rate zu erreichen. Einige Ursachen hierfür können die Gewohnheiten des Fahrers (z. B. eine Nichtübereinstimmung der im Fahrzeug durchgeführten Fahrten mit den Auslösebedingungen, die für die Einbindung der Überwachung erforderlich sind) oder Straßen- und Umgebungsbedingungen sein, welche die Auslösung einer Überwachung ermöglichten, wobei nachfolgende Ereignisse verhindern, dass die Überwachung erfolgreich abgeschlossen wird (wie zum Beispiel holprige/kurvenreiche/hügelige Straßen, Überschwappen von Kraftstoff, starker Wind/Regen und nasse Straßenbeläge, nach dem Fahren Wärme abführen). Eine Fehlzündungsüberwachung kann beispielsweise durch unebene Straßen beeinflusst werden, da die Beschleunigungsanomalie des Kurbelrads während einer unebenen Straße eine Fehlzündung nachahmt. Als ein weiteres Beispiel können unebene, windige oder hügelige Straßen das Überschwappen von Kraftstoff und erhöhte Dampfentwicklung verursachen, welche die Ergebnisse der EVAP-Leckdetektion verfälschen und entweder falsch positive oder falsch negative Ergebnisse liefern.
Wenn ein Fahrzyklus endet, ohne dass die Diagnose abgeschlossen ist, kann sie dem Fahrzeug möglicherweise nicht angerechnet werden, was zu niedrigen IUMP-Zahlen führt. Die offenbarten Ansätze nutzen Fahrzeugkonnektivität, um die Wahrscheinlichkeit zu erhöhen, dass eine OBD-Diagnoseüberwachung erfolgreich abgeschlossen wird. Da die Diagnosen unvollkommen sind und bei einer bestimmten Häufung von Rauschfaktoren einen falschen Code auslösen können, ist es von größter Wichtigkeit, entweder zu versuchen, die Diagnose abzubrechen, oder sie gar nicht auszuführen. Die Diagnosen sind ebenfalls intrusiv und zu viele Abbrüche können die ideale Funktion des Steuersystems, das mit der Diagnose assoziiert ist, verwässern. Wenn das EVAP-System beispielsweise eine Diagnose durch Schließen des CVV-Ventils durchführt, kann der Kanister nicht gespült werden. Da die Motorlaufzeit in zukünftigen Motoren begrenzt ist, kann dies bei zu vielen Ausführungen/Abbrüchen zu einem Anstieg der Verdunstungsemissionen führen.
Als Reaktion auf den Abschluss einer OBD-Überwachung durch ein Fahrzeug kann das Fahrzeug so konfiguriert sein, dass das Ergebnis der Diagnose an einen Cloud-Server gemeldet wird. Dieses Ergebnis kann einen Erfolgsstatus der OBD-Überwachung hinweisen, wie zum Beispiel eins von abgebrochen, bestanden oder nicht bestanden. Das Ergebnis kann in die diagnostischen Ergebnisdaten aufgenommen werden, die auch andere Informationen enthalten können, wie z. B. die Standortkoordinaten des Fahrzeugs, als die Überwachung eingeleitet wurde und als die Überwachung abgeschlossen wurde. Wenn sich ein Fahrzeug bewegt und die Eintrittsbedingungen für die OBD-Überwachung erfüllt sind, kann der Ansatz vor der Investition in eine Diagnosesitzung eine einfache Berechnung der Wahrscheinlichkeit durchführen, dass die Diagnose ohne Fehlmeldungen erfolgreich abgeschlossen wird.
1 veranschaulicht ein beispielhaftes System 100 für die intelligente Durchführung von OBD-Überwachungen 120. Wie dargestellt, enthält das Fahrzeug 102 eine Vielzahl von elektronischen Steuereinheiten (electronic control units - ECUs) des Fahrzeugs oder Fahrzeugsteuerungen 104, die über einen oder mehrere Fahrzeugbusse 106 kommunizieren. Eine oder mehrere OBD-Überwachungen 120 können an den Steuerungen 104 installiert sein und von den Steuerungen 104 zur Durchführung verschiedener Diagnosen ausgeführt werden. Das System 100 beinhaltet auch einen Cloud-Server 118, der so konfiguriert ist, dass er die diagnostischen Ergebnisdaten 122 beibehält. Der Cloud-Server 118 kann einen OBD-Überwachungsdienst 126 nutzen, um optimale Zeiten dafür zu bestimmen, wann das Fahrzeug 102 die OBD-Überwachungen 120 durchführen soll. Das Fahrzeug 102 enthält ferner eine Telematiksteuereinheit (telematics control unit - TCU) 108, die so konfiguriert ist, dass sie diagnostische Ergebnisdaten 122 an den Cloud-Server 118 sendet und vom OTA-Cloud-Server 118 diagnostische Ergebnisdaten 122 empfängt, die vorgeschlagene Zeiten zum Vermeiden der Durchführung der OBD-Überwachungen 120 angeben. Die TCU 108 kann einen Überwachungsergebnisdienst 124 nutzen, um die diagnostischen Ergebnisdaten 122 zu empfangen und die diagnostischen Ergebnisdaten 122 für den Cloud-Server 118 bereitzustellen. Es ist anzumerken, dass das System 100 lediglich ein Beispiel darstellt und dass andere Anordnungen oder Kombinationen von Elementen verwendet werden können. Beispielsweise können die OBD-Überwachungen 120 an mehreren oder unterschiedlichen Steuerungen 104 der Fahrzeuge 102 installiert sein.
Bei dem Fahrzeug 102 kann es sich um verschiedene Arten von Automobilen, Softroadern (crossover utility vehicle - CUV), Geländelimousinen (sport utility vehicle - SUV), Trucks, Wohnmobilen (recreational vehicle - RV), Booten, Flugzeugen oder anderen mobilen Maschinen zum Befördern von Personen oder Gütern handeln. In vielen Fällen kann das Fahrzeug 102 durch eine Brennkraftmaschine angetrieben werden. Als eine weitere Möglichkeit kann es sich bei dem Fahrzeug 102 um ein Hybrid-Elektrofahrzeug (hybrid electric vehicle - HEV) handeln, das sowohl durch eine Brennkraftmaschine als auch durch einen oder mehrere Elektromotoren angetrieben wird, wie etwa ein Serienhybrid-Elektrofahrzeug (series hybrid electric vehicle - SHEV), ein Parallelhybrid-Elektrofahrzeug (parallel hybrid electrical vehicle - PHEV) oder ein Parallel/Serienhybrid-Elektrofahrzeug (parallel/series hybrid electric vehicle - PSHEV). Da die Art und Konfiguration des Fahrzeugs 102 variieren können, können auch die Fähigkeiten des Fahrzeugs 102 entsprechend variieren. Um einige weitere Möglichkeiten zu nennen, können die Fahrzeuge 102 unterschiedliche Eigenschaften in Bezug auf die Fahrgastkapazität, die Abschleppfähigkeit und -kapazität und den Stauraum aufweisen. Für Titel, Bestand und andere Zwecke können die Fahrzeuge 102 mit einmaligen Kennungen assoziiert sein, wie zum Beispiel VINs.
Das Fahrzeug 102 kann eine Vielzahl von Steuerungen 104 beinhalten, die dazu konfiguriert sind, verschiedene Funktionen des Fahrzeugs 102, die von der Batterie und/oder dem Antriebsstrang des Fahrzeugs mit Leistung versorgt werden, durchzuführen und zu verwalten. Wie gezeigt, sind die beispielhaften Fahrzeugsteuerungen 104 als diskrete Steuerungen 104-A bis 104-G dargestellt. Die Fahrzeugsteuerungen 104 können jedoch physische Hardware, Firmware und/oder Software gemein haben, sodass die Funktionen mehrerer Steuerungen 104 in eine einzelne Steuerung 104 integriert sein können und die Funktionen verschiedener dieser Steuerungen 104 über eine Vielzahl von Steuerungen 104 verteilt sein können.
Einige nicht einschränkende Beispiele für Fahrzeugsteuerungen 104 sind: eine Antriebsstrangsteuerung 104-A kann dazu konfiguriert sein, eine Steuerung von Motorbetriebskomponenten (z. B. Leerlaufsteuerkomponenten, Kraftstoffabgabekomponenten, Emissionssteuerkomponenten usw.) und das Überwachen des Status solcher Motorbetriebskomponenten (z. B. Status von Motorcodes) bereitzustellen; eine Karosseriesteuerung 104-B kann dazu konfiguriert sein, verschiedene Leistungssteuerfunktionen, wie etwa Außenbeleuchtung, Innenbeleuchtung, schlüssellosen Zugang, Fernstart und Statusverifizierung von Zugriffspunkten (z. B. Schließstatus der Motorhaube, der Türen oder des Kofferraums des Fahrzeugs 102), zu verwalten; eine DSRC-Sendeempfängersteuerung 104-C kann dazu konfiguriert sein, mit Schlüsselanhängern, mobilen Vorrichtungen oder anderen lokalen Vorrichtungen des Fahrzeugs 102 zu kommunizieren; eine Unterhaltungssteuerung 104-D kann dazu konfiguriert sein, Sprachbefehle und BLUETOOTH-Schnittstellen mit dem Fahrer und Fahrermobilvorrichtungen zu unterstützen; eine Klimasteuerverwaltungssteuerung 104-E kann dazu konfiguriert sein, eine Steuerung von Komponenten des Heiz- und Kühlsystems (z. B. Verdichterkupplung, Gebläselüfter, Temperatursensoren usw.) bereitzustellen; eine Steuerung des globalen Navigationssatellitensystems (global navigation satellite system - GNSS) 104-F kann dazu konfiguriert sein, Fahrzeugstandortinformationen bereitzustellen; und eine Steuerung für eine Mensch-Maschine-Schnittstelle (human-machine interface - HMI) 104-G kann dazu konfiguriert sein, Benutzereingaben über verschiedene Schaltflächen oder andere Steuerungen zu empfangen sowie Fahrzeugstatusinformationen, wie etwa Füllstandinformationen, Motorbetriebstemperaturinformationen und den aktuellen Standort des Fahrzeugs 102, an einen Fahrer bereitzustellen.
Der Fahrzeugbus 106 kann verschiedene Kommunikationsverfahren beinhalten, die zwischen den elektronischen Steuereinheiten (ECUs) des Fahrzeugs 104 sowie zwischen der TCU 108 und den Fahrzeug-ECUs 104 verfügbar sind. Um einige nicht einschränkende Beispiele zu nennen, kann der Fahrzeugbus 106 ein oder mehrere von einem Fahrzeug-Controller-Area-Network (CAN), einem Ethernet-Netzwerk und einem Media-Oriented-System-Transfer-Netzwerk (MOST-Netzwerk) beinhalten. Weitere Aspekte des Layouts und der Anzahl von Fahrzeugbussen 106 werden nachstehend ausführlicher erörtert.
Die TCU 108 kann Netzwerkhardware beinhalten, die dazu konfiguriert ist, die Kommunikation zwischen den Fahrzeug-ECUs 104 und anderen Vorrichtungen des Systems 100 zu ermöglichen. Die TCU 108 kann zum Beispiel ein Mobilfunkmodem 110, das dazu konfiguriert ist, Kommunikation mit einem Weitverkehrsnetzwerk 112 zu ermöglichen, beinhalten oder anderweitig auf ein solches zugreifen. Das Weitverkehrsnetzwerk 112 kann ein oder mehrere miteinander verbundene Kommunikationsnetzwerke, wie etwa, als einige nicht einschränkende Beispiele, das Internet, ein Kabelfernsehverteilungsnetzwerk, ein Satellitenverbindungsnetzwerk, ein lokales Netzwerk und ein Telefonnetzwerk, beinhalten. Als ein weiteres Beispiel kann die TCU 108 eines oder mehrere von Vernetzung über ein BLUETOOTH-, Wi-Fi- oder drahtgebundenen USB-Netzwerk nutzen, um Kommunikation mit dem Weitverkehrsnetzwerk 112 über die mobile Vorrichtung des Benutzers zu ermöglichen.
Die TCU 108 kann ferner verschiedene Arten von Rechenvorrichtungen zur Unterstützung der Durchführung der Funktionen der in dieser Schrift beschriebenen TCU 108 beinhalten. In einem Beispiel kann die TCU 108 einen oder mehrere Prozessoren 114, die zum Ausführen von Computeranweisungen konfiguriert sind, und ein Speichermedium 116, in dem die computerausführbaren Anweisungen und/oder Daten hinterlegt werden können, beinhalten. Ein computerlesbares Speichermedium (auch als prozessorlesbares Medium oder prozessorlesbarer Speicher 116 bezeichnet) beinhaltet ein beliebiges nichttransitorisches (z. B. greifbares) Medium, das an der Bereitstellung von Daten (z. B. Anweisungen) beteiligt ist, die von einem Computer (z. B. von dem/den Prozessor(en)) ausgelesen werden können. Im Allgemeinen empfängt der Prozessor 114 Anweisungen und/oder Daten, z.B. vom Speicher 116 usw., in einem Arbeitsspeicher und führt die Anweisungen unter Verwendung der Daten aus, wodurch ein oder mehrere Prozesse, einschließlich eines oder mehrerer der hierin beschriebenen Prozesse, durchgeführt werden. Computerausführbare Anweisungen können von Computerprogrammen zusammengestellt oder ausgewertet werden, die unter Verwendung einer Reihe von Programmiersprachen und/oder -technologien erzeugt wurden, einschließlich unter anderem und entweder für sich oder in Kombination JAVA, C, C++, C#, FORTRAN, PASCAL, VISUAL BASIC, PYTHON, JAVA SCRIPT, PERL, PL/SQL usw.
Die TCU 108 kann dazu konfiguriert sein, eine oder mehrere Schnittstellen zu beinhalten, von denen Fahrzeuginformationen gesendet und empfangen werden können. In einem Beispiel kann die TCU 108 dazu konfiguriert sein, die Sammlung von Daten zu Diagnosefehlercodes (diagnostic trouble code - DTC) und/oder anderen Fahrzeuginformationen von den Fahrzeugsteuerungen 104 zu ermöglichen, die mit einem oder mehreren Fahrzeugbussen 106 verbunden sind. Wenngleich nur ein einzelner Bus 106 veranschaulicht ist, sollte angemerkt werden, dass in vielen Beispielen mehrere Fahrzeugbusse 106 enthalten sind, wobei eine Teilmenge der Steuerungen 104 mit jedem Bus 106 verbunden ist. Um auf eine bestimmte Steuerung 104 zuzugreifen, kann die TCU 108 dementsprechend dazu konfiguriert sein, eine Zuordnung dafür zu hinterlegen, welche Busse 106 mit welchen Steuerungen 104 verbunden sind, und auf den entsprechenden Bus 106 für eine Steuerung 104 zuzugreifen, wenn eine Kommunikation mit der konkreten Steuerung 104 gewünscht wird.
Der Cloud-Server 118 kann verschiedene Arten von Recheneinrichtungen, wie etwa einen Computerarbeitsplatz, einen Server, einen Desktop-Computer, eine virtuelle Serverinstanz, die durch einen Großrechner-Server ausgeführt wird, oder ein anderes Rechensystem und/oder eine andere Rechenvorrichtung, beinhalten. Ähnlich der TCU 108 schließt der Cloud-Server 118 im Allgemeinen einen Speicher ein, in dem computerausführbare Anweisungen hinterlegt werden können, wobei die Anweisungen von einem oder mehreren Prozessoren (aus Gründen der Eindeutigkeit nicht gezeigt) ausführbar sein können. Derartige Anweisungen und andere Daten können unter Verwendung einer Vielfalt an computerlesbaren Medien gespeichert werden. In einem nicht einschränkenden Beispiel kann der Cloud-Server 118 so konfiguriert sein, dass die diagnostischen Ergebnisdaten 122 und der OBD-Überwachungsdienst 126 beibehalten werden.
Die OBD-Überwachungen 120 können Selbstprüfungsroutinen enthalten, die von den Fahrzeugsteuerungen 104 ausgeführt werden, um Einblicke in den Betrieb des Fahrzeugs 102 bereitzustellen. Einige Beispiele für OBD-Überwachungen 120 beinhalten Routinen zum Überwachen von EVAP-, AGR-, O₂-Sensoren, Fehlzündungsdetektion und Katalysatoren. Die OBD-Überwachungen 120 können Dienste sein, die in der Steuerung 104 enthalten sind, um die gegebene Diagnose durchzuführen.
Die diagnostischen Ergebnisdaten 122 können Daten enthalten, die sich auf die Ausführung der OBD-Überwachung 120 beziehen. Diese Daten können einen Erfolgsstatus enthalten, der angibt, ob die OBD-Überwachung 120 erfolgreich abgeschlossen wurde oder nicht. Beispiele für Erfolgsstatuscodes können zum Beispiel eines von abgebrochen, bestanden oder nicht bestanden sein. Die diagnostischen Ergebnisdaten 122 können auch andere Informationen enthalten, wie z. B. die Standortkoordinaten des Fahrzeugs 102, als die OBD-Überwachung 120 initiiert wurde und als die OBD-Überwachung 120 abgeschlossen wurde.
Der Überwachungsausführungsdienst 124 kann eine Anwendung sein, die im Speicher 116 der TCU 108 enthalten ist. Der Überwachungsausführungsdienst 124 kann Anweisungen enthalten, die bei Ausführung durch den Prozessor 114 der TCU 108 die TCU 108 dazu veranlassen, Funktionen in Bezug auf das Planen von OBD-Überwachungen 120, Aktualisieren von Fahrzeugeinstellungen in Erwartung der Ausführung von OBD-Überwachungen 120 und Melden von diagnostischen Ergebnisdaten 122 bezüglich der OBD-Überwachungen 120 an den Cloud-Server 118 durchzuführen.
Der OBD-Überwachungsdienst 126 kann eine Anwendung sein, die im Speicher des Cloud-Servers 118 enthalten ist. Der OBD-Überwachungsdienst 126 kann Anweisungen enthalten, die bei Ausführung durch einen oder mehrere Prozessoren des Cloud-Servers 118 den Cloud-Server 118 dazu veranlassen, die diagnostischen Ergebnisdaten 122 von den Fahrzeugen 102 zu empfangen und Empfehlungen für die Fahrzeuge 102 in Bezug darauf auszusprechen, wann die OBD-Überwachungen 120 ausgeführt werden sollten. Der OBD-Überwachungsdienst 126 kann auch so programmiert sein, dass er Begründungs- und Sensitivitätsanalysen an zusätzlichem Inhalt durchführt, der nicht vom Fahrzeug 102 aus verfügbar ist, um Hauptursachen für Abbruchereignisse von OBD-Überwachungen 120 zu identifizieren. Zu dieser Begründung kann die Vorschau auf potenzielle Unterbrechungen, die durch den bordexternen Inhalt angegeben werden, sowie die Vorschau auf Stoppmuster gehören, die mit einer bestimmten OBD-Überwachung 120 assoziiert sind (z. B. eine vorhergesagte Stoppdauer für EVAP EONV).
Der OBD-Überwachungsdienst 126 kann auch so programmiert sein, dass er diagnostische Empfehlungen 128 bereitstellt, um die erfolgreiche Ausführung der OBD-Überwachungen 120 zu fördern. In einem Beispiel können die diagnostischen Empfehlungen 128 eine oder mehrere Handlungen beinhalten, die vom Fahrzeug 102 durchzuführen sind, um die Erfolgswahrscheinlichkeit für eine OBD-Überwachung 120 zu erhöhen. Als Beispiel kann eine Handlung das Anpassen einer aktiven Federungssteuerung beinhalten, um vorübergehend in den Komfortmodus zu wechseln, um die Ausbreitung des Straßeninhalts zu reduzieren. Als weiteres Beispiel kann eine Handlung das Verwenden einer intelligenten Geschwindigkeitssteuerung (ACC) beinhalten, um kleinere Geschwindigkeitsregelungen vorzunehmen, um die Zeit unter günstigen Bedingungen zu verlängern und unter ungünstigen Bedingungen zu verkürzen. Als wieder anderes Beispiel kann eine Handlung das Anfordern eine Parkhilfe beinhalten, um Parken auf einem überdachten Bereich zu empfehlen, wenn eine OBD-Überwachung 120 für EVAP EONV der Planung nach ausgeführt wird und ungünstige Umgebungsbedingungen erwartet werden. Die diagnostischen Empfehlungen 128 enthalten auch zusätzliche Informationen, wie z. B. eine Auflistung der geographischen Standorte (z. B. GNSS-Standortkoordinaten), an denen die Ausführung von OBD-Überwachungen 120 vermieden werden sollte.
2 veranschaulicht ein Beispiel 200 für eine Karte 202, die durch Crowdsourcing erhaltene diagnostische Ergebnisdaten 122 entlang einer Fahrtroute zeigt. Die Karte 202 veranschaulicht ein geografisches Gebiet, während jeder der markierten Standorte 204 eine Position eines Fahrzeugs 102 angibt, an der ein DTC gemäß den diagnostischen Ergebnisdaten 122 ausgegeben wurde. Wie in der Darstellung zu sehen ist, sind in bestimmten Gebieten Gruppen von markierten Standorten 204 vorhanden, wodurch angegeben wird, dass OBD-Überwachungen 120 an diesen Standorten nicht bestanden wurden. Da die Fahrzeugdynamik und die Straßenbeläge eine bedeutende Rolle für die Robustheit der Leistung der OBD-Überwachungen 120 spielen, kann der Ausführungserfolg der OBD-Überwachung 120 verbessert werden, indem eine Erfolgswahrscheinlichkeit der erfolgreichen Ausführung der OBD-Überwachung 120 berechnet wird, wie aus den durch Crowdsourcing erhaltenen Daten der Fahrzeuge 102 bestimmt. Dementsprechend können die diagnostischen Ergebnisdaten 122 vom OBD-Überwachungsdienst 126 des Cloud-Servers 118 analysiert werden, wie nachstehend detaillierter erörtert.
Eine Erfolgswahrscheinlichkeit für die Ausführung einer OBD-Überwachung 120 kann gemäß den durch Crowdsourcing erhaltenen diagnostischen Ergebnisdaten 122 bestimmt werden. Wenn z. B. hundert Fahrzeuge 102 eine interessierende Route zurücklegen und versucht haben, eine bestimmte OBD-Überwachung 120 auszuführen, und die Ausführung der OBD-Überwachung 120 bei fünfzig der Fahrzeuge 102 zu einem Abbruch geführt hat (z. B. aufgrund von Straßenunebenheiten, Kraftstoffüberschwappen usw.), dann kann eine Abbruchwahrscheinlichkeit von 50 % für die Durchführung der OBD-Überwachung 120 entlang der gegebenen Route wie folgt identifiziert werden: $P (A) = 50 / 100 = 50 %$
Eine Chance von 50 % für das Fehlschlagen kann als zu hoch angesehen werden, um in eine Diagnose zu investieren. Dementsprechend kann eine OBD-Überwachung 120, die der Planung nach auf der gegebenen Route durchgeführt werden soll, verschoben werden. Insbesondere kann dieser Ansatz eine Anforderung bezüglich nach einer Mindestpopulationsgröße für jede OBD-Überwachung 120 auferlegen. In einem Beispiel kann eine vernünftige Populationsgröße von mindestens dreißig Punkten für jede OBD-Überwachung 120 erforderlich sein.
Wenn das Abschlussverhältnis für die Durchführung der OBD-Überwachung 120 ausreicht und wenn die diagnostischen Ergebnisdaten 122 Erfolgsdaten enthalten, kann eine weitere Wahrscheinlichkeitsanalyse durchgeführt werden, um eine Wahrscheinlichkeit dafür zu berechnen, dass die OBD-Überwachung 120 sowohl abgeschlossen (Wahrscheinlichkeit A) als auch bestanden (Wahrscheinlichkeit B) wird. Wenn also die Abschlussrate für die Diagnose 90 % beträgt und die Bestehensrate 98 % beträgt, ist die Wahrscheinlichkeit dafür, dass die Diagnose zu einem Ergebnis führt und auch bestanden wird, gegeben durch: $P (A und B) = P (A) \times P (B) = 0,9 \times 0,98 = 0,882$
Ein Aktivierungsschwellenwert kann verwendet werden, um zu bestimmen, ob eine Diagnose bei bestimmten geografischen Koordinaten durchgeführt werden soll. Wenn das durch Gleichung (2) erhaltene Produkt ausreichend ist (z. B. ein vordefiniertes Schwellenwertminimum, wie z. B. 95 %, erfüllt), kann erlaubt werden, dass die Diagnose durch das Fahrzeug 102 durchgeführt wird. Wenn der Wert das vordefinierte Schwellenwertminimum andererseits nicht überschreitet, dann kann die OBD-Ausführung für die OBD-Überwachung 120 verschoben werden. Es ist anzumerken, dass in dieser Offenbarung in vielen Beispielen einfache Wahrscheinlichkeiten verwendet werden. Es können jedoch auch andere Wahrscheinlichkeitstechniken zur Vorhersage von Ergebnissen verwendet werden, wie z. B. die Kosinuskorrelation.
Da es sich bei den meisten OBD-DTCs um Zwei-Fahrten-Fehlfunktionswarnleuchten (malfunction indicator lamps - MILs) handelt, d. h., es werden zwei verschiedene Fahrten benötigt, um die MIL-Leuchten zu aktivieren, ist das erste Fehlschlagen ein vorbehaltlicher Code und ist das zweite konsekutive Fehlschlagen ein bestätigter Code. Wenn ein Bestehen nach dem ersten vorbehaltlichen DTC stattfindet, dann befragt der beschriebene Ansatz die Fahrzeuge 102, die den DTC am verdächtigen GPS-Tag gesetzt haben, um zu sehen, ob ein weiterer konsekutiver DTC auf einer späteren Route/GPS-Koordinate gesetzt wurde oder ob der vorbehaltliche DTC durch eine erfolgreiche Diagnoseausführung und ein Bestehen geheilt wurde. Wenn die Mehrheit der Population von Fahrzeugen 102, die beim ersten GPS-Tag einen DTC gesetzt haben, den Code später durch das Bestehen der Diagnose auf einer anderen Route und Fahrt heilte, dann ist das ursprüngliche GPS-Geotag anfällig für Fehlschlagen und kann als OBD-Diagnose-ungeeignet gesperrt werden.
Hinsichtlich der Günstigkeit gegenüber dem Schweregrad kann die Gesamtgünstigkeit wie in Gleichung (3) gezeigt definiert sein, während der Gesamtschweregrad wie in Gleichung (4) gezeigt definiert sein kann: $F = f (i) * d (i) * p_{f} (i)$
$S = s (i) * d (i) * p_{s} (i)$
wobei:

s: ein kontinuierlicher, quantifizierbarer Indikator für ungünstige Bedingungen ist;
f: ein kontinuierlicher, quantifizierbarer Indikator für günstige Bedingungen ist;
d: ein Segmententfernung ist; und
p: die Wahrscheinlichkeit für das Auftreten von günstigen/ungünstigen Bedingungen

Im Laufe der Zeit kann F für variable Längen von Segmenten mit Wahrscheinlichkeiten für erfolgreiche Ausführungen einer OBD-Überwachung 120 assoziiert sein. Wenn z. B. C als Gesamtzahl vorbehaltlicher Fehlschläge an einem gegebenen Standort definiert ist und D als Gesamtzahl für bestätigte Fehlschläge an einem zweiten gegebenen Standort definiert ist, dann wird eine Wahrscheinlichkeit von MIIL-Status-DTC-Fehlschlägen an diesen Standorten wie folgt berechnet: $P (C UND D) = P (C) \times P (D)$
Wenn P(C) hoch und P(D) niedrig ist und das Verhältnis sehr niedrig ist, dann ist der DTC wahrscheinlich eine falsche Entscheidung. Wenn das Verhältnis hoch ist, dann ist der DTC eher auf einen echten Fehlschlag zurückzuführen. Die Route mit Standort C kann dann für die Ausführung der OBD-Diagnose blockiert werden, da eine solche Diagnose zu einer hohen Fehlerrate führt, die später an Standort D geheilt wird. Daher kann eine auf einer Menge basierende Filterung durchgeführt werden, um die Ausführung der OBD-Diagnose für Standorte der Straßensegmente aufgrund der hohen Wahrscheinlichkeit für Fehlschläge zu blockieren. Wenn ein DTC zu MIL wird, indem an Standorten auf zwei verschiedenen Routen und auf zwei verschiedenen Fahrten fehlschlägt, dann ist die Wahrscheinlichkeit dafür, dass das Fahrzeug einen wirklichen Fehler aufweist, hoch. Da Standortkoordinaten (wie zum Beispiel GNSS-Koordinaten) absolut sind und einen Fehler aufweisen, wird bei der Analyse ein Meilenbereich um die Koordinaten herum festgelegt (z. B. +/- X Meilen für die gegebenen GNSS-Koordinaten).
Fahrroutensegmente, die zu einer mangelhaften OBD-Ausführung oder zu schlechten OBD-Ausführungsergebnissen führen, werden als OBD-ungeeignet gekennzeichnet. Dementsprechend kann der Cloud Server 118 andere Fahrzeuge 102 über das hohe Risiko in den diagnostischen Empfehlungen 128 informieren, die an die Fahrzeuge 102 gesendet werden. Peer-Fahrzeuge können die OBD-Ausführung in diesem Routensegment aussetzen, um die diagnostische OBD-Robustheit und hohe IUMP-Verhältnisse aufrechtzuerhalten. Auf diese Weise kann das System 100 eine reduzierte Anzahl von OBD-Diagnoseabbrüchen und eine verbesserte diagnostische Robustheit basierend auf den durch Crowdsourcing erhaltenen aggregierten Daten von bewährten und erfolgreichen OBD-Diagnosedurchläufen an markierten GNSS-Standorten erreichen.
3 veranschaulicht einen beispielhaften Prozess 300 zum Senden von diagnostischen Empfehlungen 128 für OBD-Überwachungen 120 auf der Grundlage von diagnostischen Ergebnisdaten 122. In einem Beispiel kann der Prozess 300 durch den OBD-Überwachungsdienst 126 durchgeführt werden, der vom Cloud-Server 118 in Kommunikation mit den Fahrzeugen 102 über das Weitverkehrsnetz 112 ausgeführt wird.
Bei Vorgang 302 empfängt der Cloud-Server 118 diagnostische Ergebnisdaten 122. In einem Beispiel kann der Cloud-Server 118 die diagnostischen Ergebnisdaten 122 von Fahrzeugen 102 als Reaktion darauf empfangen, dass die Fahrzeuge 102 OBD-Überwachungen 120 abschließen. In einem anderen Beispiel kann der Cloud-Server 118 die diagnostischen Ergebnisdaten 122 periodisch von den Fahrzeugen 102 empfangen. In noch einem weiteren Beispiel kann der Cloud-Server 118 die Fahrzeuge 102 nach den diagnostischen Ergebnisdaten 122 fragen.
Bei 304 korreliert der Cloud-Server 118 die diagnostischen Ergebnisdaten 122 gemäß dem Standort. In einem Beispiel kann der Cloud-Server 118 GNSS-Koordinaten oder andere Standortinformationen in den diagnostischen Ergebnisdaten 122 identifizieren, welche die Standorte der Initiierung und Beendigung der OBD-Überwachungen 120 angeben. Mit Hilfe der Koordinaten kann der Cloud-Server 118 Gruppenbildungs- oder andere Datenanalysen an den Standorten durchführen, um die diagnostischen Ergebnisdaten 122 gemäß dem Standort zu korrelieren.
Bei Vorgang 306 bestimmt der Cloud-Server 118, ob ausreichend diagnostische Ergebnisdaten 122 für die Standorte vorhanden sind, um eine Abschlussvorhersage durchzuführen. In einem Beispiel kann der Cloud-Server 118 die Datenmenge von Instanzen von diagnostischen Ergebnisdaten 122 an den Standorten mit Gruppen mit einem Schwellenwert für die Mindestpopulationsgröße (z. B. dreißig Proben) für eine gegebene OBD-Überwachung 120 (oder für alle OBD-Überwachungen 120 in einem anderen Beispiel) vergleichen, um zu bestimmen, ob Wahrscheinlichkeiten für diese OBD-Überwachung 120 (oder für alle OBD-Überwachungen 120 zusammen) berechnet werden können. Wenn für bestimmte Standorte nicht ausreichend diagnostische Ergebnisdaten 122 vorhanden sind, geht die Steuerung für diese Standorte zu Vorgang 308 über. Wenn Wahrscheinlichkeiten berechnet werden können, geht die Steuerung zu Vorgang 310 über.
Der Cloud-Server 118 erlaubt OBD-Überwachungen 120 für die vorhergesagten Standorte bei 308. In einem Beispiel führt der Cloud-Server 118 möglicherweise keinen Vorgang durch, falls Fahrzeuge 102 die Durchführung von OBD-Überwachungen 120 standardmäßig zulassen. In anderen Beispielen oder in Fällen, in denen der Cloud-Server 118 zuvor die OBD-Überwachung 120 ausgesetzt hat, sendet der Cloud-Server 118 diagnostische Empfehlungen 128 an die Fahrzeuge 102, sodass die OBD-Überwachungen 120 an dem/den angegebenen Standort(en) durchgeführt werden dürfen. Nach Vorgang 308 endet Prozess 300.
Bei 310 sagt der Cloud-Server 118 die Erfolgswahrscheinlichkeit für den Abschluss der OBD-Überwachungen 120 an den Standorten mit ausreichend diagnostischen Ergebnisdaten 122 voraus. Beispiele für die Vorhersage des Erfolgs des Abschlusses sind in Bezug auf 2 detailliert erörtert. Bei Vorgang 312 bestimmt der Cloud-Server 118, ob eine ausreichende Wahrscheinlichkeit für die Vorhersage des Abschlusses der OBD-Überwachungen 120 vorhergesagt wurde. In einem Beispiel vergleicht der Cloud-Server 118 die Wahrscheinlichkeit für den Abschluss mit einem vordefinierten Abschlussverhältnis (z. B. 80 %, 95 % usw.), um sicherzustellen, dass das Abschlussverhältnis für die Durchführung der OBD-Überwachung 120 ausreicht. Wenn die Wahrscheinlichkeit nicht ausreicht, geht die Steuerung zu Vorgang 314 über. Anderenfalls geht die Steuerung zu Vorgang 316 über.
Der Cloud-Server 118 setzt OBD-Überwachungen 120 für die vorhergesagten Standorte bei 314 aus. In einem Beispiel sendet der Cloud-Server 118 diagnostische Empfehlungen 128 an die Fahrzeuge 102, sodass die OBD-Überwachungen 120 an dem/den angegebenen Standort(en) ausgesetzt werden. Nach Vorgang 314 endet der Prozess 300.
Bei Vorgang 316 sagt der Cloud-Server 118 eine Erfolgswahrscheinlichkeit der Ausführung der OBD-Überwachungen 120 voraus. Beispiele für die Vorhersage des Erfolgs der Ausführung sind in Bezug auf 2 detailliert erörtert. Bei 318 bestimmt der Cloud-Server 118, ob die Erfolgswahrscheinlichkeit der Ausführung der OBD-Überwachungen 120 den Aktivierungsschwellenwert überschreitet. Wenn dies der Fall ist, geht die Steuerung zu Vorgang 308 über. Andernfalls geht die Steuerung zu Vorgang 314 über.
4 veranschaulicht einen beispielhaften Prozess 400 für die intelligente Durchführung von OBD-Überwachungen 120, wie durch die diagnostischen Empfehlungen 128 angeregt. In einem Beispiel kann der Prozess 400 von Komponenten des Fahrzeugs 102 im Kontext des Systems 100 durchgeführt werden, wie z. B. der TCU 108, die den Überwachungsausführungsdienst 124 in Kommunikation über den Fahrzeugbus 106 mit den Steuerungen 104 ausführt, die für die Ausführung der OBD-Überwachungen 120 konfiguriert sind.
Bei Vorgang 402 sendet das Fahrzeug 102 diagnostische Ergebnisdaten 122 an den Cloud-Server 118. In einem Beispiel kann das Senden durch die TCU 108 des Fahrzeugs 102 durchgeführt werden, wie vorstehend in Bezug auf den Vorgang 302 des Prozesses 300 beschrieben. Das Fahrzeug 102 empfing diagnostische Empfehlungen 128 vom Cloud-Server 118 bei 404. In einem Beispiel kann das Empfangen durch die TCU 108 des Fahrzeugs 102 durchgeführt werden, wie vorstehend in Bezug auf den Vorgänge 308 und 314 des Prozesses 300 beschrieben.
Bei 406 bestimmt das Fahrzeug 102, ob eine OBD-Überwachung 120 ausgelöst wird. In einem Beispiel kann die OBD-Überwachung 120 als Reaktion auf das Eintreten verschiedener Bedingungen des Fahrzeugs 102 ausgelöst werden, einige Beispiele dafür können eins oder mehrere von Erreichen der Motorkühlmitteltemperatur einer vordefinierten Temperatur, einer Kraftstoffsteuerung mit geschlossenem Regelkreis oder gleichbleibenden Fahrzeugfahrbedingungen sein. Die Bestimmung, ob die Auslösebedingungen erfüllt sind, kann durch die Steuerung 104 durchgeführt werden, welche die OBD-Überwachung 120 beherbergt. Es ist anzumerken, dass die Auslösekriterien pro OBD-Überwachung 120 variieren können. Wenn eine OBD-Überwachung 120 ausgelöst wird, geht die Steuerung zu Vorgang 408 über. Falls nicht, endet der Prozess 400.
Das Fahrzeug 102 bestimmt, ob die diagnostischen Empfehlungen 128 die Durchführung der OBD-Überwachung 120 zulassen. In einem Beispiel kann die Steuerung 104, welche die ausgelöste OBD-Überwachung 120 beherbergt, die TCU 108 abfragen, um sicherzustellen, dass die Diagnose ausgeführt werden kann. In einem anderen Beispiel könnte die TCU 108 die diagnostischen Empfehlungen 128 bezüglich der OBD-Überwachung 120 an die Steuerung 104 weitergeleitet haben, welche die OBD-Überwachung 120 beherbergt, und kann die Steuerung 104 bestimmen, ob die Durchführung der OBD-Überwachung 120 zulässig ist. Wenn die Diagnose ausgeführt werden darf, geht die Steuerung zu Vorgang 410 über, um die OBD-Überwachung 120 durchzuführen. Nach Vorgang 410 endet der Prozess 400. Wenn die OBD-Überwachung 120 jedoch nicht zulässig ist, geht die Steuerung zu Vorgang 412 über, um den Vorgang der OBD-Überwachung 120 auszusetzen. Beispielsweise kann die OBD-Überwachung 120 abgebrochen oder so lange verzögert werden, bis das Fahrzeug 102 eine Region verlässt, die in den diagnostischen Empfehlungen 128 als Standorte spezifiziert ist, an denen die OBD-Überwachung 120 nicht ausgeführt werden sollte. Nach Vorgang 412 endet der Prozess 400.
Zusammenfassend lässt sich sagen, dass die OBD-Diagnostik anfällig für Alpha-Fehler ist, und dass die Konnektivität die einzigartige Möglichkeit bietet, Alpha-Fehler durch einen Massenvergleich und die Geotagging von GNSS-Standorten beim Setzen eines DTC herauszufiltern. Bestimmte Straßen oder Gelände können für die OBD-Diagnostik ungeeignet sein, da das Fahrzeug 102 in diesem Gelände zum Beispiel federt, vibriert oder sich anderweitig so bewegt, dass es bei Fehlzündungen, EVAP oder anderen OBD-Überwachungen 120 zu falsch positiven oder negativen Ergebnissen kommen kann. Die durch Crowdsourcing erhalten Daten können diese Routen dementsprechend als ungeeignet kennzeichnen und Peers informieren. Dementsprechend kann das System 100, bevor ein Fahrzeug 102 in eine OBD-Diagnose investiert, die historische Erfolgsrate überprüfen, um sicherzustellen, dass das Fahrzeug 102 in der Lage ist, die OBD-Überwachung 120 ohne Abbruch und mit einer geringen Wahrscheinlichkeit für einen Alpha-Fehler auszuführen.
Die im vorliegenden Zusammenhang beschriebenen Rechenvorrichtungen, wie etwa die Steuerungen 104, die TCU 108 und der Cloud-Server 118, beinhalten im Allgemeinen computerausführbare Anweisungen, wobei die Anweisungen von einer oder mehreren Rechenvorrichtungen, wie etwa den vorstehend aufgelisteten, ausführbar sein können. Computerausführbare Anweisungen, wie etwa die des Überwachungsausführungsdienstes 124 oder des OBD-Überwachungsdienstes 126, können von Computerprogrammen zusammengestellt oder ausgewertet werden, die unter Verwendung einer Vielfalt an Programmiersprachen und/oder -techniken erstellt worden sind, einschließlich unter anderem und entweder einzeln oder in Kombination JAVA™, C, C++, C#, VISUAL BASIC, JAVASCRIPT, PYTHON, JAVASCRIPT, PERL, PL/SQL usw. 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, wodurch er einen oder mehrere Prozesse durchführt, einschließlich eines oder mehrerer der in dieser Schrift beschriebenen Prozesse. Derartige Anweisungen und andere Daten können unter Verwendung einer Vielfalt an computerlesbaren Medien gespeichert und übertragen werden.
Hinsichtlich der in dieser Schrift beschriebenen Prozesse, Systeme, Verfahren, Heuristiken usw. versteht es sich, dass die Schritte derartiger Prozesse usw. zwar als gemäß einer bestimmten Reihenfolge erfolgend beschrieben worden sind, derartige Prozesse jedoch mit den beschriebenen Schritten in einer Reihenfolge durchgeführt werden können, die von der in dieser Schrift beschriebenen Reihenfolge abweicht. Es versteht sich ferner, dass bestimmte Schritte gleichzeitig durchgeführt, andere Schritte hinzugefügt oder bestimmte in dieser Schrift beschriebene Schritte weggelassen werden könnten. Anders ausgedrückt dienen die Beschreibungen von Prozessen in dieser Schrift dem Zwecke der Veranschaulichung bestimmter Ausführungsformen und sollten keinesfalls dahingehend ausgelegt werden, dass sie die Patentansprüche einschränken.
Dementsprechend versteht es sich, dass die vorstehende Beschreibung veranschaulichend und nicht einschränkend sein soll. Viele Ausführungsformen und Anwendungen, bei denen es sich nicht um die bereitgestellten Beispiele handelt, erschließen sich beim Lesen der vorstehenden Beschreibung. Der Schutzumfang der Erfindung sollte nicht unter Bezugnahme auf die vorstehende Beschreibung festgelegt werden, sondern stattdessen unter Bezugnahme auf die beigefügten Patentansprüche unter Hinzunahme des vollständigen Schutzumfangs von Äquivalenten, zu denen solche Patentansprüche berechtigen. Es wird erwartet und ist beabsichtigt, dass es hinsichtlich der in dieser Schrift erörterten Technologien künftige Entwicklungen geben wird und dass die offenbarten Systeme und Verfahren in derartige künftige Ausführungsformen aufgenommen werden. Insgesamt versteht es sich, dass die Anmeldung modifiziert und variiert werden kann.
Allen in den Patentansprüchen verwendeten Ausdrücken sollen deren umfassendste nachvollziehbare Konstruktionen und deren allgemeine Bedeutungen zugeordnet sein, wie sie mit den in dieser Schrift beschriebenen Technologien vertrauten Fachleuten bekannt sind, sofern in dieser Schrift kein ausdrücklicher Hinweis auf das Gegenteil erfolgt. Insbesondere ist die Verwendung der Singularartikel, wie etwa „ein“, „einer“, „eine“, „der“, „die“, „das“ usw., dahingehend auszulegen, dass eines oder mehrere der aufgeführten Elemente genannt werden, es sei denn, ein Anspruch enthält eine ausdrücklich gegenteilige Einschränkung.
Die Zusammenfassung der Offenbarung wird bereitgestellt, um dem Leser einen schnellen Überblick über den Charakter der technischen Offenbarung zu ermöglichen. Sie wird in der Auffassung eingereicht, dass sie nicht dazu verwendet wird, den Schutzumfang oder die Bedeutung der Patentansprüche auszulegen oder einzuschränken. Darüber hinaus geht aus der vorstehenden detaillierten Beschreibung hervor, dass verschiedene Merkmale zum Zwecke der Vereinfachung der Offenbarung in verschiedenen Ausführungsformen zusammengefasst sind. Dieses Offenbarungsverfahren soll nicht dahingehend interpretiert werden, dass es eine Absicht widerspiegelt, dass die beanspruchten Ausführungsformen mehr Merkmale als ausdrücklich in jedem Patentanspruch genannt erforderlich machen. Vielmehr liegt der Gegenstand der Erfindung in weniger als allen Merkmalen einer einzelnen offenbarten Ausführungsform, wie die folgenden Patentansprüche widerspiegeln. Somit werden die folgenden Patentansprüche hiermit in die detaillierte Beschreibung aufgenommen, wobei jeder Patentanspruch für sich als separat beanspruchter Gegenstand steht.
Wenngleich vorstehend beispielhafte Ausführungsformen beschrieben sind, sollen diese Ausführungsformen nicht alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die in der Beschreibung verwendeten Ausdrücke beschreibende und keine einschränkenden Ausdrücke, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Wesen und Umfang der Erfindung abzuweichen. Darüber hinaus können die Merkmale verschiedener umsetzender Ausführungsformen miteinander kombiniert werden, um weitere erfindungsgemäße Ausführungsformen zu bilden.
Gemäß der vorliegenden Erfindung wird ein Fahrzeug bereitgestellt, aufweisend eine erste Steuerung, die so konfiguriert ist, dass sie eine diagnostische Empfehlung von einem Cloud-Server empfängt; und eine zweite Steuerung, die mit der ersten Steuerung über einen Fahrzeugbus in Kommunikation steht und so konfiguriert ist, dass sie als Reaktion auf ein Auftreten einer Fahrzeugbedingung, welche eine Ausführung einer bordeigenen diagnostischen (OBD) Überwachung auslöst, die Ausführung der OBD-Überwachung aussetzt, während sich das Fahrzeug innerhalb einer Region befindet, die durch die diagnostische Empfehlung spezifiziert ist.
Gemäß einer Ausführungsform ist die zweite Steuerung ferner so programmiert, dass sie als Reaktion auf das Auftreten der Fahrzeugbedingung, welche eine Ausführung einer bordeigenen diagnostischen (OBD) Überwachung auslöst, die Ausführung der OBD-Überwachung initiiert, während sich das Fahrzeug nicht innerhalb einer Region befindet, die durch die diagnostische Empfehlung spezifiziert ist.
Gemäß einer Ausführungsform ist die erste Steuerung ferner so konfiguriert ist, dass sie diagnostische Ergebnisdaten an den Cloud-Server sendet, wobei die diagnostischen Ergebnisdaten angeben, ob die Ausführung der OBD-Überwachung erfolgreich abgeschlossen wurde, und einen Standort des Fahrzeugs bei der Initiierung der OBD-Überwachung.
Gemäß einer Ausführungsform geben die diagnostischen Ergebnisdaten ferner einen Standort des Fahrzeugs bei Beendigung der OBD-Überwachung an.
Gemäß einer Ausführungsform beinhaltet die OBD-Überwachung eine Routine zum Überwachen von einem oder mehreren von EVAP-, AGR-, O₂-Sensoren, Fehlzündungsdetektion oder Katalysatormessung.
Gemäß einer Ausführungsform beinhaltet die durch die diagnostische Empfehlung spezifizierte Region eine radiale Entfernung, welche die in der diagnostischen Empfehlung enthaltenen Standortkoordinaten umgibt.
Gemäß der vorliegenden Erfindung ist ein System bereitgestellt, aufweisend einen Speicher, der diagnostische Ergebnisdaten von einer Vielzahl von Fahrzeug speichert, wobei jeder Eintrag der diagnostischen Ergebnisdaten Daten enthält, die angeben, ob die Ausführung einer bordeigenen diagnostischen (OBD) Überwachung durch ein Fahrzeug erfolgreich abgeschlossen wurde, und einen Standort des Fahrzeugs während der Ausführung der OBD-Überwachung; und einen Prozessor, der so programmiert ist, dass er als Reaktion darauf, dass eine vorhergesagte Erfolgswahrscheinlichkeit für die Ausführung der OBD-Überwachung für einen Standort, die anhand der diagnostischen Ergebnisdaten berechnet wurde, unter einem Aktivierungsschwellenwert liegt, eine Nachricht an die Fahrzeuge sendet, durch die weitere Ausführungen der OBD-Überwachung an dem Standort ausgesetzt werden.
Gemäß einer Ausführungsform ist der Prozessor ferner so programmiert, dass er als Reaktion auf die diagnostischen Ergebnisdaten für einen Standort, die mindestens eine vorbestimmte Anzahl von Ausführungen einer OBD-Überwachung enthalten, eine Erfolgswahrscheinlichkeit für den Abschluss der OBD-Überwachung an dem Standort auf der Grundlage von Daten vorhersagt, die angeben, ob die Ausführung der OBD-Überwachung an dem Standort erfolgreich abgeschlossen wurde.
Gemäß einer Ausführungsform ist der Prozessor ferner so programmiert, dass er Standorte in den diagnostischen Ergebnisdaten gruppiert, um Standorte zu identifizieren, die mindestens die vorbestimmte Anzahl von Ausführungen einer OBD-Überwachung enthalten.
Gemäß einer Ausführungsform wird die Erfolgswahrscheinlichkeit für den Abschluss als ein Verhältnis von erfolgreichen Ausführungen an dem Standort zu allen Ausführungen an dem Standort berechnet.
Gemäß einer Ausführungsform ist der Prozessor ferner so programmiert, dass er als Reaktion auf diagnostische Ergebnisdaten für einen Standort, welchem mindestens eine vorbestimmte Anzahl von Ausführungen einer OBD-Überwachung fehlt, eine Nachricht an die Fahrzeuge sendet, die weitere Ausführungen der OBD-Überwachung an dem Standort erlaubt.
Gemäß einer Ausführungsform ist der Prozessor ferner so programmiert, dass er die diagnostischen Ergebnisdaten von der Vielzahl von Fahrzeugen empfängt.
Gemäß einer Ausführungsform beinhaltet die Nachricht an die Fahrzeuge, durch die weitere Ausführungen der OBD-Überwachung an dem Standort ausgesetzt werden, Koordinaten des Standorts.
Gemäß der vorliegenden Erfindung beinhaltet ein Verfahren Korrelieren von Standorten in diagnostischen Ergebnisdaten, die Gruppen von Standorten identifizieren und mindestens eine vorbestimmte Anzahl von Ausführungen einer bordeigenen diagnostischen (OBD) Überwachung beinhalten; und als Reaktion darauf, dass eine vorhergesagte Erfolgswahrscheinlichkeit für die Ausführung der OBD-Überwachung für einen der Gruppen von Standorten, die anhand der diagnostischen Ergebnisdaten berechnet wurde, unter einem Aktivierungsschwellenwert liegt, Senden einer Nachricht an ein Fahrzeug, durch die weitere Ausführungen der OBD-Überwachung an dem Standort ausgesetzt werden.
Gemäß einer Ausführungsform ist die vorstehende Erfindung ferner gekennzeichnet durch Vorhersagen einer Erfolgswahrscheinlichkeit für den Abschluss der OBD-Überwachung an dem einen der Gruppe von Standorten auf der Grundlage von Daten, die in den diagnostischen Ergebnisdaten enthalten sind, die angeben, ob die Ausführung der OBD-Überwachung an dem Standort erfolgreich abgeschlossen wurde.
Gemäß einer Ausführungsform ist die vorstehende Erfindung ferner gekennzeichnet durch Berechnen der Erfolgswahrscheinlichkeit für den Abschluss als ein Verhältnis von erfolgreichen Ausführungen an dem Standort zu allen Ausführungen an dem Standort.
Gemäß einer Ausführungsform ist die vorstehende Erfindung ferner gekennzeichnet durch, als Reaktion auf diagnostische Ergebnisdaten für einen Standort, welchem mindestens eine vorbestimmte Anzahl von Ausführungen einer OBD-Überwachung fehlt, Senden einer Nachricht an das Fahrzeug, die weitere Ausführungen der OBD-Überwachung an dem Standort erlaubt.
Gemäß einer Ausführungsform ist die vorstehende Erfindung ferner gekennzeichnet durch Empfangen der diagnostischen Ergebnisdaten von einer Vielzahl von Fahrzeugen.
Gemäß einer Ausführungsform ist die vorstehende Erfindung ferner gekennzeichnet durch Aufnehmen von Koordinaten des Standorts in die Nachricht.

Claims

Fahrzeug, umfassend: eine erste Steuerung, die so konfiguriert ist, dass sie eine diagnostische Empfehlung von einem Cloud-Server empfängt; und eine zweite Steuerung, die mit der ersten Steuerung über einen Fahrzeugbus in Kommunikation steht und so konfiguriert ist, dass sie als Reaktion auf ein Auftreten einer Fahrzeugbedingung, welche eine Ausführung einer bordeigenen diagnostischen (OBD) Überwachung auslöst, die Ausführung der OBD-Überwachung aussetzt, während sich das Fahrzeug innerhalb einer Region befindet, die durch die diagnostische Empfehlung spezifiziert ist.
Fahrzeug nach Anspruch 1, wobei die zweite Steuerung ferner so programmiert ist, dass sie als Reaktion auf das Auftreten der Fahrzeugbedingung, welche eine Ausführung einer bordeigenen diagnostischen (OBD) Überwachung auslöst, die Ausführung der OBD-Überwachung initiiert, während sich das Fahrzeug nicht innerhalb einer Region befindet, die durch die diagnostische Empfehlung spezifiziert ist.
Fahrzeug nach Anspruch 1, wobei die erste Steuerung ferner so konfiguriert ist, dass sie diagnostische Ergebnisdaten an den Cloud-Server sendet, wobei die diagnostischen Ergebnisdaten angeben, ob die Ausführung der OBD-Überwachung erfolgreich abgeschlossen wurde, und einen Standort des Fahrzeugs bei der Initiierung der OBD-Überwachung.
Fahrzeug nach Anspruch 3, wobei die diagnostischen Ergebnisdaten ferner einen Standort des Fahrzeugs bei Beendigung der OBD-Überwachung angeben.
Fahrzeug nach Anspruch 1, wobei die OBD-Überwachung eine Routine zum Überwachen von einem oder mehreren von EVAP-, AGR-, O₂-Sensoren, Fehlzündungsdetektion oder Katalysatormessung beinhaltet.
Fahrzeug nach Anspruch 1, wobei die durch die diagnostische Empfehlung spezifizierte Region eine radiale Entfernung beinhaltet, welche die in der diagnostischen Empfehlung enthaltenen Standortkoordinaten umgibt.
Verfahren, umfassend: Korrelieren von Standorten in diagnostischen Ergebnisdaten, die Gruppen von Standorten identifizieren und mindestens eine vorbestimmte Anzahl von Ausführungen einer bordeigenen diagnostischen (OBD) Überwachung beinhalten; und als Reaktion darauf, dass eine vorhergesagte Erfolgswahrscheinlichkeit für die Ausführung der OBD-Überwachung für einen der Gruppen von Standorten, die anhand der diagnostischen Ergebnisdaten berechnet wurde, unter einem Aktivierungsschwellenwert liegt, Senden einer Nachricht an ein Fahrzeug, durch die weitere Ausführungen der OBD-Überwachung an dem Standort ausgesetzt werden.
Verfahren nach Anspruch 7, ferner umfassend Vorhersagen einer Erfolgswahrscheinlichkeit für den Abschluss der OBD-Überwachung an dem einen der Gruppe von Standorten auf der Grundlage von Daten, die in den diagnostischen Ergebnisdaten enthalten sind, die angeben, ob die Ausführung der OBD-Überwachung an dem Standort erfolgreich abgeschlossen wurde.
Verfahren nach Anspruch 8, ferner umfassend Berechnen der Erfolgswahrscheinlichkeit für den Abschluss als ein Verhältnis von erfolgreichen Ausführungen an dem Standort zu allen Ausführungen an dem Standort.
Verfahren nach Anspruch 8, ferner umfassend, als Reaktion auf diagnostische Ergebnisdaten für einen Standort, welchem mindestens eine vorbestimmte Anzahl von Ausführungen einer OBD-Überwachung fehlt, Senden einer Nachricht an das Fahrzeug, die weitere Ausführungen der OBD-Überwachung an dem Standort erlaubt.
Verfahren nach Anspruch 8, ferner umfassend Empfangen der diagnostischen Ergebnisdaten von einer Vielzahl von Fahrzeugen.
Verfahren nach Anspruch 8, ferner umfassend Aufnehmen von Koordinaten des Standorts in die Nachricht.