DE102015208750A1

DE102015208750A1 - Over-the-air-fahrzeugproblembehebung

Info

Publication number: DE102015208750A1
Application number: DE102015208750.6A
Authority: DE
Inventors: Peter Eric Petersen; Cathleen TISTLE
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2014-05-15
Filing date: 2015-05-12
Publication date: 2015-11-19
Also published as: US20150331686A1; CN105094882A

Abstract

Eine Symptomdatenbank kann Fahrzeugparameter, die Fahrzeugprobleme anzeigen, mit Software-Updates, die die Probleme beheben, assoziieren. Ein Diagnoseserver kann als Reaktion auf eine Erzeugung eines Diagnosecodes durch ein Fahrzeug Fahrzeugparameter von dem Fahrzeug empfangen, die Symptomdatenbank dazu nutzen, ein Software-Update zu identifizieren, das einem Problem entspricht, das von den Fahrzeugparametern angezeigt wird, und eine Antwort bereitstellen, die das Software-Update zur automatischen Installation durch das Fahrzeug, um das Problem zu beheben, identifiziert. Ein Prozessor eines Fahrzeugs kann als Reaktion auf eine Erzeugung eines Diagnosecodes durch das Fahrzeug Fahrzeugparameter, die den Diagnosecode und eine Kennung des Fahrzeugs enthalten, an einen Diagnoseserver senden, eine Antwort, die ein Software-Update identifiziert, das einem Problem entspricht, das von den Fahrzeugparametern angezeigt wird, von dem Diagnoseserver empfangen, das Software-Update als Reaktion auf die Antwort, die das Software-Update identifiziert, empfangen und das Software-Update automatisch installieren.

Description

Diese Offenbarung bezieht sich allgemein auf die Over-the-Air-Fahrzeugproblembehebung unter Verwendung von vom Fahrzeug bereitgestellten Parameterinformationen.
Fahrzeuge können eine Funktionalität zum Bereitstellen von Selbstdiagnoseinformationen in der Form von Diagnosecodes beinhalten. Diagnosecodes können aus dem Fahrzeug gelesen werden und dazu verwendet werden, einer Person zu ermöglichen, den Betriebsstatus verschiedener Komponenten oder Systeme in dem Fahrzeug zu identifizieren. Beispielsweise kann ein Fahrer eines Fahrzeugs mit einer beleuchteten „Motor überprüfen“-Lampe das Fahrzeug zu einer Reparaturwerkstätte fahren, wo ein Automechaniker spezielle Hardware dazu nutzen kann, die Diagnosecodes zu lesen und zu decodieren, um ein etwaiges Fahrzeugproblem zu identifizieren und zu beheben.
In einer ersten veranschaulichenden Ausführungsform beinhaltet ein System eine Symptomdatenbank, die Fahrzeugparameter, die Fahrzeugprobleme anzeigen, mit Software-Updates, die die Probleme beheben, assoziiert; und einen Diagnoseserver, der dazu konfiguriert ist, Fahrzeugparameter von einem Fahrzeug als Reaktion auf eine Erzeugung eines Diagnosecodes durch das Fahrzeug zu empfangen, die Symptomdatenbank dazu zu nutzen, ein Software-Update zu identifizieren, das einem Problem entspricht, das von den Fahrzeugparametern angezeigt wird, und eine Antwort bereitzustellen, die das Software-Update zur automatischen Installation durch das Fahrzeug, um das Problem zu beheben, identifiziert.
In einer zweiten veranschaulichenden Ausführungsform beinhaltet ein System einen Prozessor eines Fahrzeugs, der dazu konfiguriert ist, als Reaktion auf eine Erzeugung eines Diagnosecodes durch das Fahrzeug Fahrzeugparameter, die den Diagnosecode und eine Kennung des Fahrzeugs enthalten, an einen Diagnoseserver zu senden, eine Antwort, die ein Software-Update identifiziert, das einem Problem entspricht, das von den Fahrzeugparametern angezeigt wird, von dem Diagnoseserver zu empfangen, das Software-Update als Reaktion auf die Antwort, die das Software-Update identifiziert, zu empfangen und das Software-Update automatisch zu installieren.
In einer dritten veranschaulichenden Ausführungsform beinhaltet ein computerimplementiertes Verfahren als Reaktion auf eine Erzeugung eines Diagnosecodes durch das Fahrzeug das Empfangen von Fahrzeugparametern, die den Diagnosecode und eine Kennung des Fahrzeugs enthalten; das Nutzen einer Symptomdatenbank, die Fahrzeugparameter, die Fahrzeugprobleme anzeigen, mit Software-Updates, die die Probleme beheben, assoziiert, um ein Software-Update zu identifizieren, das einem Problem entspricht, das von den Fahrzeugparametern angezeigt wird; und das Bereitstellen einer Antwort, die die durch das Fahrzeug automatisch zu installierenden Software-Updates, um das Problem zu beheben, identifiziert.
1 ist eine beispielhafte Blocktopologie eines Fahrzeug-Infotainmentsystems, das ein benutzerinteraktives fahrzeugbasiertes Datenverarbeitungssystem implementiert;
2 stellt ein beispielhaftes System zur automatischen Identifizierung von Updates für ein Fahrzeug gemäß Fahrzeugparametern dar;
3 stellt einen beispielhaften Datenfluss zur automatischen Identifizierung von Software-Updates für ein Fahrzeug gemäß Fahrzeugparametern dar;
4 stellt einen beispielhaften Vorgang zum automatischen Empfangen von Software-Updates durch ein Fahrzeug dar und
5 stellt einen beispielhaften Vorgang zum automatischen Identifizieren von Software-Updates zum Bewältigen von Fahrzeugproblemen gemäß von einem Fahrzeug bereitgestellten Fahrzeugparametern dar.
Detaillierte Ausführungsformen der vorliegenden Erfindung sind erforderlichenfalls hierin offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen verkörpert werden kann. Die Figuren sind nicht unbedingt maßstabgetreu; einige Merkmale können übertrieben oder minimiert sein, um Einzelheiten bestimmter Komponenten zu zeigen. Folglich sollten hierin offenbarte spezifische strukturelle und funktionelle Einzelheiten nicht als einschränkend betrachtet werden, sondern lediglich als eine repräsentative Grundlage, um einem Fachmann das verschiedenartige Einsetzen der vorliegenden Erfindung zu lehren.
Ein Fahrzeug kann dazu konfiguriert sein, während eines normalen Betriebs eines Fahrzeugs Parameter, wie Diagnosecodes (DTC), an einen Diagnoseserver zu senden. Diese Parameter können beispielsweise beim Einstecken des Schlüssels, während das Fahrzeug sich in einem Bewegungsmodus befindet, beim Abziehen des Schlüssels oder, wenn das Fahrzeug derart konfiguriert ist, beim Anschließen („Plug-in“) zum Aufladen gesendet werden. Die Parameter können außerdem ein oder mehrere Zusatzinformationselemente enthalten, wie eine eindeutige Kennung des Fahrzeugs (z. B. eine auf dem Controller-Area-Network-Bus (CAN-Bus) veröffentlichte Fahrzeugidentifizierungsnummer-Information (FIN-Information), eine SIM-Information (SIM = subscriber identity module, Teilnehmerkennungsmodul) eines eingebetteten Fahrzeugmodems, wie eine IMEI-Kennzahl (IMEI = international mobile station equipment identity)), eine Anzeige des Modells des Fahrzeugs und/oder eine Information, die die aktuelle Konfiguration und eine Versionsinformation zu dem Fahrzeug anzeigt.
Ein Fahrzeug kann verschiedene Komponentenmodule beinhalten, die dazu konfiguriert sind, verschiedene Aufgaben oder Unteraufgaben für das Fahrzeug durchzuführen. Als einige nicht einschränkende Beispiele können die Fahrzeugmodule ein Antriebsstrangsteuermodul (ASM), ein Bremssystemsteuermodul (brake system control module, BSCM) und ein übergeordnetes Steuergerät (body control module, BCM) beinhalten. Während des Betriebs des Fahrzeugs kann ein Fahrzeugmodul eine Sequenz von einem oder mehreren Diagnosecodes vorbringen. Diese Sequenz von Codes kann von dem Fahrzeug als Parameter dem Diagnoseserver bereitgestellt werden. In einigen Fällen kann der Fahrzeugführer auch auf diese Codes aufmerksam gemacht werden, wie mittels einer „Motor-überprüfen“-Lampe im Innenraum des Fahrzeugs.
Der Diagnoseserver kann weiterhin dazu konfiguriert sein, eine Symptomdatenbank zu pflegen, die Assoziationen von Parametern, die Fahrzeugprobleme anzeigen, mit Software-Updates, die dazu konfiguriert sind, die entsprechenden Probleme zu bewältigen, enthält. Die Symptomdatenbank kann beispielsweise einen Datensatz aufweisen, der eine Anzeige einer Sequenz von einem oder mehreren Diagnosecodes und eine Assoziation mit einem verfügbaren Software-Fix, der in dem Fahrzeug installiert werden kann, um das Problem, das die Diagnosecodes verursacht, zu beheben, enthält. Wenn neue Fahrzeugprobleme identifiziert werden, können Symptome und Anzeigen verfügbarer Software-Updates in die Symptomdatenbank hochgeladen werden. In einigen Fällen kann das Software-Update aktualisierte Konfigurationseinstellungen für ein oder mehrere Fahrzeugmodule beinhalten, während das Software-Update in anderen Fällen eine neue Version einer Software oder Firmware, die in einem oder mehreren Fahrzeugmodulen installiert werden soll, beinhalten kann. In einigen Fällen kann die Symptomdatenbank anstelle des Pflegens der Updates in der Symptomdatenbank Kennungen enthalten, die den Software-Updates entsprechen, die an einem anderen Ort gespeichert sind, wie in einem Software-Update-Datenspeicher.
Wie überall in dieser Offenbarung verwendet, können Software und Software-Updates Daten beinhalten, die Anweisungen darstellen, die von einem Mikroprozessor, Controller oder Computer des fahrzeugbasierten Datenverarbeitungssystems ausgeführt werden können. Alternativ dazu oder in Kombination damit können Software-Updates Daten beinhalten, die Kalibrier-, Konfigurations- oder andere Daten oder Parameter darstellen, die dazu verwendet werden, den Fahrzeugbetrieb zu steuern, was den Betrieb verschiedener Fahrzeugmodule, -komponenten oder -systeme beinhalten kann, wie ein Fahrzeug-Infotainment-System, ein Borddiagnosesystem (OBD-System, OBD = on-board diagnostics) und ähnliche Systeme.
Auf der Basis der Symptomdatenbank kann der Diagnoseserver dazu konfiguriert sein, die empfangenen Fahrzeugparameter zu analysieren, um potentielle Probleme mit dem Fahrzeug zu identifizieren. Wenn das Fahrzeug beispielsweise seine Fahrzeugparameter an den Diagnoseserver sendet, können die hochgeladenen Parameter durch den Diagnoseserver mit einer Symptomdatenbank verglichen werden. Wenn der Diagnoseserver auf der Basis der Fahrzeugparameter identifiziert, dass ein verfügbares Software-Update das Problem beheben würde, kann der Diagnoseserver das Fahrzeug informieren, die entsprechenden Software-Updates von dem Software-Update-Datenspeicher herunterzuladen und zu installieren. Das Fahrzeug kann dazu konfiguriert sein, als Reaktion auf die Anforderung die neue Software herunterzuladen und zu installieren (z. B. beim Abziehen des Schlüssels, bei einem Anschlusszustand („Plugged-in“), dem ein Hybrid-Elektrofahrzeug unterzogen wird, wenn die Update-Information empfangen wird usw.), ohne dass ein Eingreifen des Kunden erforderlich ist.
Folglich können Fahrzeugprobleme unter Verwendung des Systems automatisch diagnostiziert und bewältigt werden, ohne dass ein Kunde zu einer Reparaturwerkstätte fahren muss und Diagnosecodes abgerufen werden müssen, um zu bestimmen, welches Modul mit einem bestimmten Problem assoziiert war.
1 stellt eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Datenverarbeitungssystem (vehicle-based computing system, VCS) 1 für ein Fahrzeug 31 dar. Ein Beispiel eines derartigen fahrzeugbasierten Datenverarbeitungssystems 1 ist das von THE FORD MOTOR COMPANY hergestellte SYNC-System. Ein Fahrzeug, das mit einem fahrzeugbasierten Datenverarbeitungssystem ausgestattet ist, kann eine visuelle Front-End-Oberfläche 4 enthalten, die sich in dem Fahrzeug befindet. Der Benutzer kann auch dazu in der Lage sein, mit der Oberfläche zu interagieren, wenn sie beispielsweise mit einem Berührungsbildschirm versehen ist. In einer anderen veranschaulichenden Ausführungsform erfolgt die Interaktion durch Tastendrücke, ein natürlichsprachliches Dialogsystem mit automatischer Spracherkennung und Sprachsynthese.
In der in 1 gezeigten veranschaulichenden Ausführungsform 1 steuert ein Prozessor 3 zumindest einen Teil des Betriebs des fahrzeugbasierten Datenverarbeitungssystems. Der in dem Fahrzeug vorgesehene Prozessor ermöglicht die Bordverarbeitung von Befehlen und Routinen. Des Weiteren ist der Prozessor mit sowohl einem nichtpermanenten Speicher 5 als auch einem permanenten Speicher 7 verbunden. In dieser veranschaulichenden Ausführungsform ist der nichtpermanente Speicher ein Direktzugriffsspeicher (random access memory, RAM) und der permanente Speicher ist ein Festplattenlaufwerk (hard disk drive, HDD) oder Flash-Speicher. Im Allgemeinen kann ein permanenter (nicht vergänglicher) Speicher alle Speicherformen beinhalten, die Daten pflegen, wenn ein Computer oder anderes Gerät abgeschaltet wird. Diese beinhalten HDD, CD, DVD, Magnetbänder, Halbleiterlaufwerke, tragbare USB-Laufwerke und eine beliebige andere geeignete Form eines permanenten Speichers, sind jedoch nicht darauf beschränkt.
Der Prozessor ist außerdem mit einer Reihe unterschiedlicher Eingänge versehen, die dem Benutzer ermöglichen, eine Verbindung mit dem Prozessor herzustellen. In dieser veranschaulichenden Ausführungsform sind ein Mikrofon 29, ein Hilfseingang 25 (für Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24, ein Bildschirm 4, bei dem es sich um eine Touchscreen-Anzeige handeln kann, und ein BLUETOOTH-Eingang 15 alle vorgesehen. Ein Eingangswähler 51 ist ebenfalls vorgesehen, um einem Benutzer zu ermöglichen, zwischen verschiedenen Eingängen zu wechseln. Eine Eingabe in sowohl das Mikrofon als auch den Hilfsanschluss wird durch einen Wandler 27 von analog in digital umgewandelt, bevor sie an den Prozessor geleitet wird. Obwohl nicht gezeigt, können zahlreiche der Fahrzeugkomponenten und Hilfskomponenten in Kommunikation mit dem VCS ein Fahrzeugnetz (wie einen CAN-Bus, jedoch nicht darauf beschränkt) dazu verwenden, Daten an das und von dem VCS (oder Komponenten davon) zu leiten.
Ausgänge zu dem System können eine optische Anzeige 4 und einen Lautsprecher 13 oder einen Stereosystemausgang beinhalten, sind jedoch nicht darauf beschränkt. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal von dem Prozessor 3 durch einen Digital-Analog-Wandler 9. Eine Ausgabe kann auch zu einem entfernten BLUETOOTH-Gerät, wie einem PND 54, oder einem USB-Gerät, wie einem Fahrzeugnavigationsgerät 60, entlang der bidirektionalen Datenströme, die bei 19 bzw. 21 gezeigt sind, erfolgen.
In einer veranschaulichenden Ausführungsform verwendet das System 1 den BLUETOOTH-Transceiver 15, um mit einem nomadischen Gerät 53 des Benutzers (z. B. einem Mobiltelefon, Smartphone, PDA oder beliebigen anderen Gerät mit drahtloser Remote-Netzkonnektivität) zu kommunizieren 17. Das nomadische Gerät kann dann dazu verwendet werden, mit einem Netz 61 außerhalb des Fahrzeugs 31 durch beispielsweise eine Kommunikation 55 mit einem Mobilfunkmast 57 zu kommunizieren 59. In einigen Ausführungsformen kann der Mast 57 ein WiFi-Zugangspunkt sein.
Eine beispielhafte Kommunikation zwischen dem nomadischen Gerät und dem BLUETOOTH-Transceiver ist durch ein Signal 14 dargestellt.
Das Verbinden (Paaren) eines nomadischen Geräts 53 und des BLUETOOTH-Transceivers 15 kann durch eine Taste 52 oder eine ähnliche Eingabe angewiesen werden. Dementsprechend wird der CPU angewiesen, dass der Bord-BLUETOOTH-Transceiver mit einem BLUETOOTH-Transceiver in einem nomadischen Gerät verbunden wird.
Daten können zwischen dem CPU 3 und dem Netz 61 unter Nutzung von beispielsweise einem Datenplan, Data-over-Voice oder DTMF-Tönen, die mit dem nomadischen Gerät 53 assoziiert sind, übermittelt werden. Alternativ dazu kann es wünschenswert sein, ein Bordmodem 63 mit einer Antenne 18 zu integrieren, um Daten zwischen dem CPU 3 und dem Netz 61 über das Sprachband zu übermitteln 16. Das nomadische Gerät 53 kann dann dazu verwendet werden, mit einem Netz 61 außerhalb des Fahrzeugs 31 durch beispielsweise eine Kommunikation 55 mit einem Mobilfunkmast 57 zu kommunizieren 59. In einigen Ausführungsformen kann das Modem 63 eine Kommunikation 20 mit dem Mast 57 zum Kommunizieren mit dem Netz 61 herstellen. Als ein nicht einschränkendes Beispiel kann das Modem 63 ein USB-Mobilfunkmodem sein und die Kommunikation 20 kann eine Mobilfunkkommunikation sein.
In einer veranschaulichenden Ausführungsform ist der Prozessor mit einem Betriebssystem versehen, das eine API beinhaltet, um mit Modemanwendungssoftware zu kommunizieren. Die Modemanwendungssoftware kann auf ein eingebettetes Modul oder Firmware auf dem BLUETOOTH-Transceiver zugreifen, um eine drahtlose Kommunikation mit einem entfernten BLUETOOTH-Transceiver (wie dem in einem nomadischen Gerät vorgefundenen) abzuschließen. Bluetooth ist eine Untermenge der IEEE-802-PAN-Protokolle (PAN = personal area network, persönliches Netz). IEEE-802-LAN-Protokolle (LAN = local area network, lokales Netz) beinhalten WiFi und haben eine beträchtliche Kreuzfunktionalität mit IEEE 802 PAN. Beide sind für eine drahtlose Kommunikation innerhalb eines Fahrzeugs geeignet. Ein anderes Kommunikationsmittel, das in diesem Gebiet verwendet werden kann, sind eine optische Freiraumkommunikation (wie IrDA) und nicht standardisierte Verbraucher-IR-Protokolle.
In einer anderen Ausführungsform beinhaltet das nomadische Gerät 53 ein Modem für Sprachband- oder Breitbanddatenkommunikation. In der Data-over-Voice-Ausführungsform kann eine Technik, die als Frequenzmultiplexen bekannt ist, implementiert werden, wobei der Besitzer des nomadischen Geräts über das Gerät sprechen kann, während Daten übertragen werden. Zu anderen Zeitpunkten, wenn der Besitzer das Gerät nicht verwendet, kann der Datentransfer die gesamte Bandbreite (in einem Beispiel 300 Hz bis 3,4 kHz) verwenden. Obgleich Frequenzmultiplexen für analoge Mobilfunkkommunikation zwischen dem Fahrzeug und dem Internet üblich sein mag und immer noch verwendet wird, wurde es weitgehend durch Hybride von Mehrfachzugriff im Codebereich (Code Domain Multiple Access, CDMA), Mehrfachzugriff im Zeitbereich (Time Domain Multiple Access, TDMA), Mehrfachzugriff im Raumbereich (Space Domain Multiple Access, SDMA) für digitale Mobilfunkkommunikation ersetzt. Dies sind alles ITU-IMT-2000-konforme (3G-konforme) Standards, die Datenübertragungsgeschwindigkeiten von bis zu 2 Mbs für stationäre oder gehende Benutzer und 385 Kbs für Benutzer in einem sich bewegenden Fahrzeug bieten. 3G-Standards werden jetzt durch IMT-Advanced (4G) ersetzt, das 100 Mbs für Benutzer in einem Fahrzeug und 1 Gbs für stationäre Benutzer bietet. Wenn der Benutzer einen Datenplan hat, der mit dem nomadischen Gerät assoziiert ist, ist es möglich, dass der Datenplan eine Breitbandübertragung zulässt, und das System könnte eine viel weitere Bandbreite verwenden (wodurch die Datenübertragung beschleunigt wird). In noch einer anderen Ausführungsform wird das nomadische Gerät 53 durch ein Mobilfunkkommunikationsgerät (nicht gezeigt) ersetzt, das an dem Fahrzeug 31 installiert ist. In noch einer anderen Ausführungsform kann das NG 53 ein drahtloses LAN-Gerät sein (LAN = local area network, lokales Netz), das zur Kommunikation über beispielsweise (und ohne Einschränkung) ein 802.11g-Netz (d. h. WiFi) oder ein WiMax-Netz fähig ist.
In einer Ausführungsform können eingehende Daten durch das nomadische Gerät über eine Data-over-Voice-Verbindung oder einen Datenplan, durch den Bord-BLUETOOTH-Transceiver und in den internen Prozessor 3 des Fahrzeugs geleitet werden. Im Fall bestimmter temporärer Daten beispielsweise können die Daten auf dem HDD oder einem anderen Speichermedium 7 gespeichert werden, bis zu einem Zeitpunkt, zu dem die Daten nicht mehr benötigt werden.
Zu zusätzlichen Quellen, die eine Verbindung mit dem Fahrzeug herstellen können, zählen ein persönliches Navigationsgerät 54 mit beispielsweise einer USB-Verbindung 56 und/oder einer Antenne 58, ein Fahrzeugnavigationsgerät 60 mit einer USB-Verbindung 62 oder einer anderen Verbindung, ein Bord-GPS-Gerät 24 oder ein entferntes Navigationssystem (nicht gezeigt) mit Konnektivität zu dem Netz 61. USB ist eines einer Klasse von seriellen Vernetzungsprotokollen. IEEE 1394 (FireWire^TM (Apple), i.LINK^TM (Sony) und Lynx^TM (Texas Instruments)), serielle Protokolle der EIA (Electronics Industry Association), IEEE 1284 (Centronics-Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Gerüst der seriellen Gerät-zu-Gerät-Standards. Die meisten der Protokolle können für entweder elektrische oder optische Kommunikation implementiert werden.
Des Weiteren könnte der CPU in Kommunikation mit einer Vielfalt von anderen Hilfsgeräten 65 stehen. Diese Geräte können durch eine drahtlose Verbindung 67 oder eine drahtgebundene Verbindung 69 verbunden werden. Das Hilfsgerät 65 kann persönliche Media-Player, drahtlose Gesundheitsgeräte, tragbare Computer und dergleichen beinhalten, ist jedoch nicht darauf beschränkt.
Zudem oder alternativ dazu könnte der CPU mit einem fahrzeugbasierten drahtlosen Router 73 unter Verwendung beispielsweise eines WiFi-Transceivers (IEEE-803.11-Transceivers) 71 verbunden sein. Dies könnte dem CPU ermöglichen, sich mit Remote-Netzen im Bereich des lokalen Routers 73 zu verbinden.
Zusätzlich zu beispielhaften Vorgängen, die von einem Fahrzeugdatenverarbeitungssystem ausgeführt werden, das sich in einem Fahrzeug befindet, können die beispielhaften Vorgänge in bestimmten Ausführungsformen von einem Datenverarbeitungssystem in Kommunikation mit einem Fahrzeugdatenverarbeitungssystem ausgeführt werden. Ein derartiges System kann ein drahtloses Gerät (z. B. und ohne Einschränkung ein Mobiltelefon) oder ein entferntes Datenverarbeitungssystem (z. B. und ohne Einschränkung ein Server), das durch das drahtlose Gerät verbunden ist, beinhalten, ist jedoch nicht darauf beschränkt. Zusammengefasst können derartige Systeme als mit einem Fahrzeug assoziierte Datenverarbeitungssysteme (vehicle-associated computing systems, VACS) bezeichnet werden. In bestimmten Ausführungsformen können bestimmte Komponenten des VACS bestimmte Teile eines Vorgangs in Abhängigkeit von der bestimmten Implementierung des Systems durchführen. Beispielhaft und nicht einschränkend, wenn ein Vorgang einen Schritt des Sendens oder Empfangens von Informationen mit einem verbundenen (gepaarten) drahtlosen Gerät aufweist, ist es wahrscheinlich, dass das drahtlose Gerät nicht den Vorgang durchführt, da das drahtlose Gerät Informationen nicht sich selbst bzw. von sich selbst „senden und empfangen“ würde. Ein Durchschnittsfachmann wird verstehen, wann es unangebracht ist, ein bestimmtes VACS für eine gegebene Lösung anzuwenden. In allen Lösungen wird in Erwägung gezogen, dass zumindest das Fahrzeugdatenverarbeitungssystem (vehicle computing system, VCS), das sich in dem Fahrzeug selbst befindet, die beispielhaften Vorgänge durchführen kann.
2 stellt ein beispielhaftes System 200 zur automatischen Identifizierung von Software-Updates 206 für ein Fahrzeug 31 gemäß Fahrzeugparametern 202 dar. Das System 200 beinhaltet mehrere Fahrzeuge 31, die dazu konfiguriert sind, Fahrzeugparameter 202 über das Kommunikationsnetz 61 bereitzustellen. Das System 200 kann weiterhin einen Diagnoseserver 214 beinhalten, der dazu konfiguriert ist, eine Symptomdatenbank 212 zu pflegen und die Symptomdatenbank 212 dazu zu verwenden, eine Upgrade-Information 216 gemäß den empfangenen Fahrzeugparametern 202 zu identifizieren und den Fahrzeugen 31 mitzuteilen. Das System 200 kann auch einen Software-Update-Server 208 beinhalten, der dazu konfiguriert ist, einen Update-Datenspeicher 204 zu pflegen und den Update-Datenspeicher 204 dazu zu verwenden, als Reaktion auf eine Update-Anforderung 210 des Fahrzeugs 31 dem Fahrzeug 31 Software-Updates 206 bereitzustellen. Das System 200 kann viele verschiedene Formen annehmen und mehrere und/oder alternative Komponenten und Einrichtungen beinhalten. Obgleich in 2 ein beispielhaftes System 200 gezeigt ist, sollen die in der Figur dargestellten beispielhaften Komponenten nicht einschränkend sein. In der Tat kann das System 200 mehr oder weniger Komponenten aufweisen und zusätzliche oder alternative Komponenten und/oder Umsetzungen können verwendet werden. Als ein Beispiel: Obwohl die Symptomdatenbank 212 und der Update-Datenspeicher 204 in dem System 200 als separate Datenspeicher gezeigt sind, können die Symptomdatenbank 212 und der Update-Datenspeicher 204 in anderen Beispielen zu einer einzigen Datenbank kombiniert sein. Als ein anderes Beispiel: Obwohl der Diagnoseserver 214 und der Software-Update-Server 208 in dem System 200 als separate Server gezeigt sind, können sie zu einem einzigen Server kombiniert sein oder in anderen Fällen unter mehreren Servern aufgeteilt sein, um eine Belastungsverteilung, eine Kollokation oder andere Datenspeichertechniken zu erzielen.
Die Fahrzeugparameter 202 können Informationen enthalten, die während des Betriebs des Fahrzeugs 31 gesammelt wurden. Die Informationen können Parameter, wie Diagnosecodes (manchmal als DTC bezeichnet), beinhalten, die von dem Fahrzeug 31 beim Eintreten verschiedener Zustände erzeugt werden. Die Parameter können außerdem ein oder mehrere Zusatzinformationselemente enthalten, wie eine eindeutige Kennung des Fahrzeugs 31 (z. B. eine FIN des Fahrzeugs 31, mit einem Modem 63 des Fahrzeugs 31 assoziierte eindeutige Kennungen usw.), eine Anzeige des Modells des Fahrzeugs und/oder eine Information, die die aktuelle Konfiguration und eine Versionsinformation zu den Modulen des Fahrzeugs anzeigt. In einigen Fällen können die Fahrzeugparameter 202 eine Sequenz von Parametern enthalten, die ein Problem anzeigen, das ein Modul, eine Komponente oder ein System des Fahrzeugs 31 erfährt.
Der Update-Datenspeicher 204 kann dazu konfiguriert sein, Software-Updates 206 zu speichern, die dem Fahrzeug 31 bereitgestellt werden können. Die Software-Updates 206 können beispielsweise aktualisierte Konfigurationseinstellungen für ein bzw. eine oder mehrere Module, Komponenten oder Systeme des Fahrzeugs 31 und/oder eine aktualisierte Version einer Software oder Firmware, die auf einem bzw. einer oder mehreren Modulen, Komponenten oder Systemen des Fahrzeugs 31 installiert werden soll, enthalten. In einigen Fällen kann ein Software-Update 206 weiterhin eine Information enthalten, die die Kompatibilität der Software-Updates 206 mit dem Modell oder der Konfiguration des Fahrzeugs 31 anzeigt. Ein Eintrag für das Software-Update 206 kann beispielsweise anzeigen, dass das Software-Update 206 mit einer bestimmten Marke und einem bestimmten Modell des Fahrzeugs 31 kompatibel ist oder dass sie eine Abhängigkeit von einer Version eines anderen Moduls, einer anderen Komponente oder eines anderen Systems des Fahrzeugs 31, bei der es sich um eine bestimmte Version oder bestimmte Versionen handelt, aufweist.
Der Software-Update-Server 208 kann dazu konfiguriert sein, den Update-Datenspeicher 204 zu pflegen. Der Software-Update-Server 208 kann beispielsweise dazu konfiguriert sein, Hinzufügungen zu oder Änderungen den gepflegten Software-Updates zu empfangen, wie jenen, die von Support-Personal oder Entwicklungsgruppen erzeugt wurden, um ein Problem zu beheben, auf das von Fahrzeugen 31 unterwegs gestoßen wird. Der Software-Update-Server 208 kann weiterhin dazu konfiguriert sein, Update-Anforderungen 210 von den Fahrzeugen 31 zu empfangen, den Update-Datenspeicher 204 als Reaktion auf den Empfang der Update-Anforderungen 210 auf Updates abzufragen und auf die Update-Anforderungen 210 mit den angeforderten Software-Updates 206 zu antworten.
Die Symptomdatenbank 212 kann dazu konfiguriert sein, eine Assoziation von Fahrzeugparametern 202 mit Anzeigen von Software-Updates 206 zu speichern, die dazu konfiguriert ist, Probleme zu bewältigen, die von den Fahrzeugparametern 202 angezeigt werden. Die Assoziation kann beispielsweise eine Anzeige einer Sequenz von einem oder mehreren Diagnosecodes in Assoziation mit einem Software-Update 206, das ein Problem bewältigt, das die Sequenz von Diagnosecodes verursacht, beinhalten. Die Assoziation kann weiterhin Zusatzinformationen beinhalten, wie Anzeigen, welche Fahrzeuge 31 mit dem Software-Update 206 kompatibel sein können (z. B. Marke der Fahrzeuge 31, Modell der Fahrzeuge 31, unterstützte Modul-, Komponenten- oder Systemversionen der Fahrzeuge 31 usw.).
Der Diagnoseserver 214 kann dazu konfiguriert sein, die Symptomdatenbank 212 zu pflegen. Der Software-Update-Server 208 kann beispielsweise dazu konfiguriert sein, Hinzufügungen zu oder Änderungen der gepflegten Assoziationen von Fahrzeugparametern 202 zu empfangen, wie zusätzliche Fahrzeugparameter 202, die der Symptomdatenbank 212 hinzugefügt wurden und ein Problem anzeigen, das von einem neuen Software-Update 206 bewältigt wird, das dem Update-Datenspeicher 204 hinzugefügt wurde. Der Diagnoseserver 214 kann weiterhin dazu konfiguriert sein, Informationen zu den aktuellen Konfigurationen der Fahrzeuge 31, wie Modul-, Komponenten- oder Systemversionen, Marke und Modell der Fahrzeuge 31, assoziierte Region oder assoziierter Markt der Fahrzeuge 31, oder andere Informationen, die in Bezug auf das Diagnostizieren von Problemen mit den Fahrzeugen 31 von Nutzen sein können, zu pflegen.
Der Diagnoseserver 214 kann weiterhin dazu konfiguriert sein, die Fahrzeugparameter 202 von den Fahrzeugen 31 des Systems 200 zu empfangen. Das Fahrzeug 31 kann dazu konfiguriert sein, die Fahrzeugparameter 202 während eines oder mehrerer Betriebsmodi, beispielsweise beim Einstecken des Schlüssels, während das Fahrzeug sich in einem Bewegungsmodus befindet, beim Abziehen des Schlüssels oder, wenn das Fahrzeug 31 derart konfiguriert ist, beim Anschließen („Plug-in“) zum Aufladen, an den Diagnoseserver 214 zu senden. Der Diagnoseserver 214 kann weiterhin dazu konfiguriert sein, die Symptomdatenbank 212 auf Anzeigen von Updates abzufragen, die mittels des Software-Update-Servers 208 verfügbar sind, um etwaige Probleme zu bewältigen, die von den empfangenen Fahrzeugparametern 202 angezeigt werden, und eine Update-Information 216 den Fahrzeugen 31 bereitzustellen, die ein oder mehrere Software-Updates 206 anzeigen, die das Fahrzeug 31 installieren sollte, um das identifizierte Problem zu bewältigen. Das Fahrzeug 31 kann dementsprechend die Update-Information 216 empfangen und Update-Anforderungen 210 dem Software-Update-Server 208 bereitstellen, um die angezeigten Updates abzurufen.
3 stellt einen beispielhaften Datenfluss 300 zur automatischen Identifizierung von Software-Updates 206 für ein Fahrzeug 31 gemäß Fahrzeugparametern 202 dar. In dem beispielhaften Datenfluss 300 kann das Fahrzeug 31 Software-Updates 206 empfangen und installieren, um ein Problem zu beheben, das von dem Diagnoseserver 214 auf der Basis der Fahrzeugparameter 202 identifiziert wurde.
Ganz besonders sendet das VCS 1 des Fahrzeugs 31 zum Zeitindex (A) Fahrzeugparameter 202 über das Netz 61 an den Diagnoseserver 214. In einigen Fällen kann das VCS 1 die Fahrzeugparameter 202 durch Nutzen eines Bordmodems 63 des Fahrzeugs 31 bereitstellen, während das VCS 1 in anderen Fällen die Fahrzeugparameter 202 unter Verwendung des Datenplans des verbundenen (gepaarten) nomadischen Geräts 53 mittels des Bord-BLUETOOTH-Transceivers 15 bereitstellen kann. Die Fahrzeugparameter 202 können Informationen, die während des Betriebs des Fahrzeugs 31 gesammelt wurden, wie Diagnosecodes, die möglicherweise gespeichert wurden, sowie das Fahrzeug identifizierende Informationen enthalten. Das VCS 1 kann dazu konfiguriert sein, die Fahrzeugparameter 202 periodisch oder bei Erkennen eines Ereignisses, wie das Vorbringen eines Diagnosecodes, oder weiterhin als Reaktion auf ein anderes Ereignis des Fahrzeugs 31, das nach der Auslösungserkennung aufgetreten ist, wie das Einstecken des Schlüssels, das Abziehen des Schlüssels oder das Anschließen („Plug-in“), bereitzustellen.
Zum Zeitindex (B) erfasst der Diagnoseserver 214 Informationen des Fahrzeugs 31. Der Diagnoseserver 214 kann beispielsweise auf der Basis von das Fahrzeug identifizierenden Informationen, die in den empfangenen Fahrzeugparametern 202 enthalten sind, aktuelle Konfigurationsinformationen zu dem Fahrzeug 31, wie aktuelle Modul-, Komponenten- oder Systemversionen, Marke und Modell und Region oder Markt, abrufen, die von dem Diagnoseserver 214 gepflegt werden oder anderweitig für diesen zugänglich sind. Zum Zeitindex (C) fragt der Diagnoseserver 214 die Symptomdatenbank 212 ab. Der Diagnoseserver 214 kann die Fahrzeugparameter 202 und andere aktuelle Fahrzeugkonfigurationsinformationen nutzen zu bestimmen, ob es etwaige verfügbare Software-Updates 206 gibt, die dazu konfiguriert sind, Probleme zu bewältigen, die von den Fahrzeugparametern 202 angezeigt werden.
Zum Zeitindex (D) stellt der Diagnoseserver 214 eine Upgrade-Information 216 dem VCS 1 des Fahrzeugs 31 bereit. Wenn der Diagnoseserver 214 beispielsweise auf der Basis der Symptomdatenbank 212 bestimmt, dass Software-Updates 206 verfügbar sind, um ein Problem zu bewältigen, das das Fahrzeug 31 erfährt, kann der Diagnoseserver 214 eine Upgrade-Information 216 an das Fahrzeug 31 senden, die die zu installierenden Software-Updates 206 anzeigt. In einigen Fällen kann das Software-Update 206, wenn ein Softwaremodul ein Update erfordert, Abhängigkeiten zu bestimmten anderen Modulen anzeigen, von denen erfordert wird, dass sie ebenfalls eine aktualisierte Version haben. Folglich kann die Upgrade-Information 216 weiterhin Anzeigen anderer Software-Updates 206 enthalten, die möglicherweise ebenfalls durchgeführt werden müssen, um das Software-Update 206 zu unterstützen, das das identifizierte Problem bewältigt.
Zum Zeitindex (E) sendet das VCS 1 eine Update-Anforderung 210 an den Update-Server 208. Das VCS 1 kann beispielsweise das eine oder die mehreren Software-Updates 206 von dem Update-Server 208 anfordern. Zum Zeitpunkt (F) ruft der Update-Server 208 die angeforderten Software-Updates 206 von dem Update-Datenspeicher 204 ab. Folglich kann der Update-Server 208 dementsprechend die angeforderten Software-Updates 206 dem VCS 1 zurück bereitstellen. Zum Zeitpunkt (G) empfängt das VCS 1 die Software-Updates 206 von dem Update-Server 208.
Zum Zeitindex (H) wendet das VCS 1 die Software-Updates 206 auf die aktuelle Softwareinstallation des Fahrzeugs 31 an. Das VCS 1 kann beispielsweise aus dem Software-Update 206 ein beabsichtigtes Modul des Fahrzeugs 31 bestimmen, auf das das Software-Update 206 angewendet werden soll. Als eine Möglichkeit kann das Software-Update 206 eine Moduladresse oder andere Modulkennung enthalten, die dazu konfiguriert ist, dem VCS 1 das Identifizieren zu ermöglichen, welches Modul des Fahrzeugs 31 das Software-Update 206 erhalten sollte, so dass das VCS 1 das Software-Update 206 zu dem korrekten Modul routen kann. Um das Update anzuwenden, kann das VCS 1 weiterhin dazu konfiguriert sein, eine Sitzung mit dem Zielmodul zu öffnen, das Software-Update 206 dem Modul zur Installation bereitzustellen, eine Anzeige der Anwendung des Updates auf das Modul zu empfangen und die Sitzung mit dem Zielmodul zu schließen. In einem Beispiel kann das VCS 1 dazu konfiguriert sein, das Software-Update 206 zu dem passenden Modul mittels des Controller-Area-Network-Busses (CAN-Busses) des Fahrzeugs 31 zu routen (z. B. unter Verwendung der Moduladresse oder der anderen Modulkennung als beabsichtigtem Ziel des Software-Updates 206). Folglich kann das VCS 1 die aktualisierten Konfigurationseinstellungen und/oder aktualisierten Softwareversionen anwenden, um das identifizierte Problem zu bewältigen. In einigen Fällen können die Software-Updates beim nächsten Abziehen des Schlüssels installiert werden, nachdem die Software-Updates 206 empfangen wurden.
Zum Zeitindex (I) aktualisiert das VCS 1 den Diagnoseserver 214 mit der aktualisierten Konfigurationsinformation des Fahrzeugs 31. Bei erfolgreicher Installation der Software-Updates 206 kann das VCS 1 beispielsweise aktualisierte Fahrzeuginformationen dem Diagnoseserver 214 bereitstellen, um dem Diagnoseserver 214 zu ermöglichen, auf weitere Software-Updates 206 für das Fahrzeug 31 unter Verwendung der aktuellen Konfiguration des Fahrzeugs 31 zu prüfen. In einigen Fällen können die aktualisierten Konfigurationsinformationen des Fahrzeugs 31 als weitere Fahrzeugparameter 202 dem Diagnoseserver 214 bereitgestellt werden.
4 stellt einen beispielhaften Vorgang 400 zum automatischen Empfangen von Software-Updates 206 durch ein Fahrzeug 31 dar. Der Vorgang 400 kann beispielsweise von dem VCS 1 in Kommunikation mit dem Diagnoseserver 214 und dem Update-Server 208 über das Netz 61 durchgeführt werden.
In Arbeitsschritt 402 sendet das VCS 1 Fahrzeugparameter 202 an den Diagnoseserver 214. Die Fahrzeugparameter 202 können Informationen, die während des Betriebs des Fahrzeugs 31 gesammelt wurden, wie zuvor gespeicherte oder derzeit ausgelöste Diagnosecodes, sowie das Fahrzeug identifizierende Informationen enthalten. In Arbeitsschritt 404 empfängt das VCS 1 eine Upgrade-Information 216 von dem Diagnoseserver 214. Das VCS 1 kann beispielsweise eine Upgrade-Information 216 von dem Diagnoseserver 214 empfangen, die Software-Updates 206 anzeigt, die installiert werden sollen, um ein Problem zu bewältigen, das das Fahrzeug 31 erfährt, wie von den Fahrzeugparametern 202 identifiziert.
In Arbeitsschritt 406 sendet das VCS 1 eine Update-Anforderung 210 an den Update-Server 208. Das VCS 1 kann beispielsweise das eine oder die mehreren Software-Update 206 von dem Update-Server 208 anfordern. In Arbeitsschritt 408 empfängt das VCS 1 die angeforderten Software-Updates 206 von dem Update-Server 208 und in Arbeitsschritt 410 wendet das VCS 1 die angeforderten Software-Updates 206 an. Folglich kann das VCS 1 als Reaktion auf das Empfangen der Upgrade-Information 216 von dem Diagnoseserver 214 die aktualisierten Konfigurationseinstellungen und/oder aktualisierten Softwareversionen anwenden, um das identifizierte Problem zu bewältigen. In einigen Fällen können die Software-Updates beim nächsten Abziehen des Schlüssels installiert werden, nachdem die Software-Updates 206 empfangen wurden.
In Arbeitsschritt 412 sendet das VCS 1 einen Fahrzeug-Update-Status an den Diagnoseserver 214. Bei erfolgreicher Installation der Software-Updates 206 kann das VCS 1 beispielsweise aktualisierte Fahrzeuginformationen dem Diagnoseserver 214 als Fahrzeugparameter 202 bereitstellen, um dem Diagnoseserver 214 zu ermöglichen, auf weitere Software-Updates 206 für das Fahrzeug 31 unter Verwendung der aktuellen Konfiguration des Fahrzeugs 31 zu prüfen. Nach Arbeitsschritt 412 endet der Vorgang 400.
5 stellt einen beispielhaften Vorgang 500 zum automatischen Identifizieren von Software-Updates 206 zum Bewältigen von Problemen eines Fahrzeugs 31 gemäß von dem Fahrzeug bereitgestellten Fahrzeugparametern 202 dar. Der Vorgang 500 kann beispielsweise von dem Diagnoseserver 214 und dem Update-Server 208 in Kommunikation mit dem VCS 1 über das Netz 61 durchgeführt werden.
In Arbeitsschritt 502 empfängt der Diagnoseserver 214 Fahrzeugparameter 202 von dem Fahrzeug 31. Der Diagnoseserver 214 kann beispielsweise Fahrzeugparameter 202 empfangen, die von dem VCS 1 periodisch oder bei Erkennen eines Ereignisses, wie das Vorbringen eines Diagnosecodes, oder bei Auftreten eines anderen Ereignisses des Fahrzeugs 31, wie das Einstecken des Schlüssels, das Abziehen des Schlüssels oder das Anschließen („Plug-in“) des Fahrzeugs 31 zum Aufladen (z. Be. wie durch einen Anzeiger eines Ladeanschlusses des Fahrzeugs 31, bei Erkennen von eingehendem Leistungsfluss durch das Ladesystem des Fahrzeugs 31 usw. bestimmt), gesendet werden. In Arbeitsschritt 504 erfasst der Diagnoseserver 214 Fahrzeuginformationen. Der Diagnoseserver 214 kann beispielsweise auf der Basis von das Fahrzeug identifizierenden Informationen, die in den empfangenen Fahrzeugparametern 202 enthalten sind, aktuelle Konfigurationsinformationen zu dem Fahrzeug 31, wie aktuelle Modulversionen, Marke und Modell und Region oder Markt, abrufen, die von dem Diagnoseserver 214 gepflegt werden oder anderweitig für diesen zugänglich sind.
In Arbeitsschritt 506 identifiziert der Diagnoseserver 214 Software-Updates 206 für das Fahrzeug 31. Der Diagnoseserver 214 kann beispielsweise die Fahrzeugparameter 202 und andere aktuelle Konfigurationsinformationen des Fahrzeugs 31 dazu nutzen, die Symptomdatenbank 212 auf Anzeigen von Software-Updates 206 für das Fahrzeug 31 abzufragen. In Arbeitsschritt 508 sendet der Diagnoseserver 214 eine Upgrade-Information 216 an das Fahrzeug 31. Die Upgrade-Information 216 kann beispielsweise Anzeigen der Software-Updates 206 enthalten, die in dem Fahrzeug 31 installiert werden sollen, um ein Problem zu bewältigen, das das Fahrzeug 31 erfährt, wie von den Fahrzeugparametern 202 identifiziert.
In Arbeitsschritt 510 stellt der Update-Server 208 die Software-Updates 206 dem Fahrzeug 31 bereit. Der Update-Server 208 kann beispielsweise eine Update-Anforderung 210 von dem VCS 1 empfangen, die die Software-Updates 206 anfordert, die dem VCS 1 durch den Diagnoseserver 214 angezeigt wurden. Der Update-Server 208 kann dementsprechend die angeforderten Software-Updates 206 von dem Update-Datenspeicher 204 abrufen und die angeforderten Software-Updates 206 zurück an das VCS 1 senden.
In Arbeitsschritt 512 aktualisiert der Diagnoseserver 214 die Fahrzeuginformationen zu dem Fahrzeug 31. Der Diagnoseserver 214 kann beispielsweise aktualisierte Fahrzeuginformationen von dem VCS 1 empfangen, die die aktualisierte Konfiguration des Fahrzeugs 31 anzeigen. In einigen Fällen können die aktualisierten Konfigurationsinformationen des Fahrzeugs 31 dem Diagnoseserver 214 als weitere Fahrzeugparameter 202 bereitgestellt werden. Nach Arbeitsschritt 512 endet der Vorgang 500.
Folglich kann der Diagnoseserver 214 die Symptomdatenbank 212 und die empfangenen Fahrzeugparameter 202 dazu nutzen, Probleme des Fahrzeugs 31 zu identifizieren, die bereits von einem verfügbaren Software-Update 206 behoben werden, und das Fahrzeug 31 anzuweisen, das Software-Update 206 zu installieren, um das Problem zu beheben, alles ohne dass erforderlich ist, dass der Kunde zu einer Reparaturwerkstätte fährt und Codes abgerufen werden, um zu bestimmen, welches Modul für die Erzeugung des Diagnosecodes oder der Codesequenz verantwortlich war.
Als ein Beispiel: Ein Techniker kann bestimmen, dass ein Grenzwert, der für eine bestimmte Komponententemperatur eingestellt ist, auf einen Punkt eingestellt ist, der verursacht, dass Fahrzeuge 31 Temperaturdiagnosecodes melden, die nicht wirklich einen abweichenden Betriebszustand des Fahrzeugs 31 anzeigen. Der Techniker kann dementsprechend ein Software-Update 206 erzeugen, das aktualisierte Konfigurationseinstellungen enthält, die den Grenzwert modifizieren. Dieses Software-Update 206 kann dem Update-Datenspeicher 204 hinzugefügt werden. Um Fahrzeugen 31 zu ermöglichen, das Update automatisch anzunehmen, kann die Symptomdatenbank 212 aktualisiert werden, um eine Assoziation von Fahrzeugparametern 202, die die Temperaturdiagnosecodes enthalten, mit einer Anzeige des Software-Updates 206, das den Grenzwert modifiziert, zu enthalten. Wenn ein Fahrzeug 31 die Temperaturdiagnosecodes dem Diagnoseserver 214 meldet, kann der Diagnoseserver 214 folglich die Symptomdatenbank 212 dazu nutzen, das Fahrzeug 31 anzuweisen, das Software-Update 206 mit den aktualisierten Konfigurationseinstellungen, das das Problem behebt, herunterzuladen und zu installieren.
Als ein anderes Beispiel: Ein Mechaniker kann bestimmen, dass ein Batterieladealgorithmus für ein Plug-in-Hybridfahrzeug 31 bestimmte Diagnosecodes aufgrund von Fahrzeugparametern 202 infolge eines Problems in dem Ladealgorithmus hervorbringt. Der Mechaniker kann dementsprechend ein Software-Update 206 entwickeln, das eine neue Ladefunktion enthält, die das Problem bewältigt. Dieses Software-Update 206 kann dem Update-Datenspeicher 204 hinzugefügt werden. Um Fahrzeugen 31 zu ermöglichen, das Update automatisch anzunehmen, kann die Symptomdatenbank 212 aktualisiert werden, um eine Assoziation von Fahrzeugparametern 202, die charakteristisch für das Ladeproblem sind, mit einer Anzeige des Software-Updates 206, das die neue Ladefunktion enthält, zu enthalten. Wenn ein Fahrzeug 31 Fahrzeugparameter 202, die charakteristisch für das Ladeproblem sind, meldet und vom entsprechenden Hybrid-Fahrzeugtyp ist, kann der Diagnoseserver 214 folglich die Symptomdatenbank 212 dazu nutzen, das Fahrzeug 31 anzuweisen, das Software-Update 206 mit der aktualisierten Ladefunktion herunterzuladen und zu installieren.
Obwohl beispielhafte Ausführungsformen oben beschrieben sind, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die in der Spezifikation verwendeten Wörter beschreibende und nicht einschränkende Wörter und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Sinn und Schutzumfang der Erfindung abzuweichen. Darüber hinaus können die Merkmale verschiedener Umsetzungsausführungsformen kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

IEEE-802-PAN-Protokolle [0026]
IEEE 802 PAN [0026]
IEEE 1394 [0029]
IEEE 1284 [0029]
IEEE-803.11-Transceivers [0031]

Claims

System, das Folgendes umfasst: eine Symptomdatenbank, die Fahrzeugparameter, die Fahrzeugprobleme anzeigen, mit Software-Updates, die die Probleme beheben, assoziiert; und einen Diagnoseserver, der zu Folgendem konfiguriert ist: Empfangen von Fahrzeugparametern von einem Fahrzeug als Reaktion auf eine Erzeugung eines Diagnosecodes durch das Fahrzeug, Nutzen der Symptomdatenbank, um ein Software-Update zu identifizieren, das einem Problem entspricht, das von den Fahrzeugparametern angezeigt wird, und Bereitstellen einer Antwort, die das Software-Update zur automatischen Installation durch das Fahrzeug, um das Problem zu beheben, identifiziert.
System nach Anspruch 1, wobei das Software-Update eine aktualisierte Konfigurationseinstellung, die auf ein Fahrzeugmodul angewendet werden soll, und/oder eine aktualisierte Version einer Software, die auf das Fahrzeugmodul angewendet werden soll, enthält.
System nach Anspruch 1, wobei der Diagnoseserver weiterhin dazu konfiguriert ist, das Software-Update gemäß Fahrzeugparametern, die die Fahrzeugmarke, das Fahrzeugmodell und/oder die Fahrzeughardwarekonfiguration enthalten, zu identifizieren.
System nach Anspruch 1, wobei der Diagnoseserver weiterhin dazu konfiguriert ist, das Software-Update gemäß Fahrzeugparametern, die eine Softwareversion enthalten, die aktuell auf einem Fahrzeugmodul installiert ist, zu identifizieren.
System nach Anspruch 1, wobei der Diagnoseserver weiterhin zu Folgendem konfiguriert ist: Empfangen einer Anzeige eines Status der Installation des Software-Updates in dem Fahrzeug von dem Fahrzeug und als Reaktion auf die Anzeige Aktualisieren von Daten, die eine Softwareversion anzeigen, die aktuell auf einem Fahrzeugmodul installiert ist.
System nach Anspruch 1, wobei die Fahrzeugparameter weiterhin eine eindeutige Kennung des Fahrzeugs und/oder eine eindeutige Kennung eines Netzgeräts, das Zugriff auf ein Netz bereitstellt, über das die Fahrzeugparameter gesendet werden, enthalten.
System nach Anspruch 1, das weiterhin einen Update-Server umfasst, der zu Folgendem konfiguriert ist: Empfangen einer Upgrade-Anforderung von dem Fahrzeug, die die Software-Updates anfordert; und Bereitstellen der Software-Updates dem Fahrzeug als Reaktion auf die Anforderung.
System, das Folgendes umfasst: einen Prozessor eines Fahrzeugs, der zu Folgendem konfiguriert ist: als Reaktion auf eine Erzeugung eines Diagnosecodes durch das Fahrzeug Senden von Fahrzeugparametern, die den Diagnosecode und eine Kennung des Fahrzeugs enthalten, an einen Diagnoseserver, Empfangen einer Antwort von dem Diagnoseserver, die ein Software-Update identifiziert, das einem Problem entspricht, das von den Fahrzeugparametern angezeigt wird, Empfangen des Software-Updates als Reaktion auf die Antwort, die das Software-Update identifiziert, und automatisches Installieren des Software-Updates.
System nach Anspruch 8, wobei das Software-Update eine aktualisierte Konfigurationseinstellung, die auf ein Fahrzeugmodul angewendet werden soll, und/oder eine aktualisierte Version einer Software, die auf das Fahrzeugmodul angewendet werden soll, enthält.
System nach Anspruch 8, wobei der Prozessor des Fahrzeugs weiterhin dazu konfiguriert ist, eine Anzeige eines Status der Installation der Software-Updates in dem Fahrzeug bereitzustellen, wobei die Anzeige eine Softwareversion anzeigt, die aktuell auf einem Fahrzeugmodul installiert ist.
System nach Anspruch 10, wobei der Prozessor des Fahrzeugs weiterhin dazu konfiguriert ist, die Anzeige des Status der Installation als zusätzliche Fahrzeugparameter bereitzustellen.
System nach Anspruch 8, wobei der Prozessor des Fahrzeugs weiterhin dazu konfiguriert ist, das Software-Update bei einem Abziehen des Schlüssels des Fahrzeugs, einem Einstecken des Schlüssels des Fahrzeugs oder einem Anschließen („Plug-in“) des Fahrzeugs zum Aufladen zu installieren.
System nach Anspruch 8, wobei die Fahrzeugparameter weiterhin eine eindeutige Kennung des Fahrzeugs und/oder eine eindeutige Kennung eines Netzgeräts, das Zugriff auf ein Netz bereitstellt, über das die Fahrzeugparameter gesendet werden, enthalten.
Computerimplementiertes Verfahren, das Folgendes umfasst: als Reaktion auf eine Erzeugung eines Diagnosecodes durch das Fahrzeug Empfangen von Fahrzeugparametern, die den Diagnosecode und eine Kennung des Fahrzeugs enthalten, Nutzen einer Symptomdatenbank, die Fahrzeugparameter, die Fahrzeugprobleme anzeigen, mit Software-Updates, die die Probleme beheben, assoziiert, um ein Software-Update zu identifizieren, das einem Problem entspricht, das von den Fahrzeugparametern angezeigt wird; und Bereitstellen der Software-Updates, die automatisch durch das Fahrzeug installiert werden sollen, um das Problem zu beheben.
Verfahren nach Anspruch 14, wobei das Software-Update eine aktualisierte Konfigurationseinstellung, die auf ein Fahrzeugmodul angewendet werden soll, und/oder eine aktualisierte Version einer Software, die auf das Fahrzeugmodul angewendet werden soll, enthält.
Verfahren nach Anspruch 14, das weiterhin das Identifizieren des Software-Updates gemäß der Fahrzeugmarke, dem Fahrzeugmodell und/oder der Fahrzeughardwarekonfiguration umfasst.
Verfahren nach Anspruch 14, das weiterhin das Identifizieren des Software-Updates gemäß einer Softwareversion, die aktuell auf einem Fahrzeugmodul installiert ist, umfasst.
Verfahren nach Anspruch 14, das weiterhin Folgendes umfasst: Empfangen einer Anzeige eines Status der Installation der Software-Updates in dem Fahrzeug von dem Fahrzeug und als Reaktion auf die Anzeige Aktualisieren von Daten, die eine Softwareversion anzeigen, die aktuell auf einem Fahrzeugmodul installiert ist.
Verfahren nach Anspruch 14, wobei die Fahrzeugparameter weiterhin eine eindeutige Kennung des Fahrzeugs und/oder eine eindeutige Kennung eines Netzgeräts, das Zugriff auf ein Netz bereitstellt, über das die Fahrzeugparameter gesendet werden, enthalten.
Verfahren nach Anspruch 14, das weiterhin Folgendes umfasst: Empfangen einer Upgrade-Anforderung von dem Fahrzeug, die die Software-Updates anfordert; und Bereitstellen der Software-Updates dem Fahrzeug als Reaktion auf die Anforderung.