DE102015116703A1

DE102015116703A1 - Verfahren und Systeme zur Aktualisierung eines Fahrzeugdatenverarbeitungssystems

Info

Publication number: DE102015116703A1
Application number: DE102015116703.4A
Authority: DE
Inventors: Douglas Raymond Martin; Mark Anthony ROCKWELL
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2014-10-07
Filing date: 2015-10-01
Publication date: 2016-04-07
Also published as: CN105487883B; US20160098266A1; CN105487883A; US10282194B2

Abstract

Ein Fahrzeugdatenverarbeitungssystem für ein Fahrzeug beinhaltet ein erstes und ein zweites Speichergerät (z. B. einen löschbaren programmierbaren Festwertspeicher (EEPROM)). Das System beinhaltet weiterhin einen Schaltkreis, der selektiv zwischen dem ersten und dem zweiten Speichergerät umschaltet. Das System beinhaltet weiterhin ein erstes Fahrzeugsteuermodul, das dazu konfiguriert ist, eine Benachrichtigung zu empfangen, dass eine Softwareaktualisierung an dem zweiten Speichergerät verfügbar ist. Das erste Fahrzeugsteuermodul steuert den Schaltkreis dahingehend, bei einem Initialisierungsereignis von dem ersten Speichergerät zu dem zweiten Speichergerät umzuschalten. Das erste Fahrzeugsteuermodul führt die Softwareaktualisierung auf der Basis einer Kommunikation mit dem zweiten Speichergerät aus.

Description

TECHNISCHES GEBIET
Die vorliegende Offenbarung betrifft ein System und ein Verfahren zum Flashen eines Steuermoduls und ganz besonders zum Aktualisieren einer Fahrzeugdatenverarbeitungssystemanordnung und -methodologie.
HINTERGRUND
Um eine Softwareversion einer Komponente eines Fahrzeugs zu aktualisieren, kann das Fahrzeug zu einem Autohaus gefahren und von einem Techniker in Stand gesetzt werden. Der Techniker kann ein System nutzen, das die einzelnen Softwareebenen von Komponenten in dem Fahrzeug sowie verfügbare Softwareaktualisierungen verfolgt. Der Techniker kann die Softwareaktualisierungen, die von dem System angezeigt werden, manuell anwenden und etwaige Änderungen zurück in das System aufzeichnen. Die Softwareaktualisierung kann vorgenommen werden, während das Fahrzeug funktionsunfähig ist.
KURZDARSTELLUNG
In einer Ausführungsform beinhaltet ein Fahrzeugdatenverarbeitungssystem für ein Fahrzeug ein erstes Speichergerät in Kommunikation mit einem ersten Prozessor zum Ausführen eines oder mehrerer Fahrzeugarbeitsvorgänge. Das System beinhaltet weiterhin ein zweites Speichergerät in Kommunikation mit einem zweiten Prozessor zum Empfangen von Softwareaktualisierungen. Das System beinhaltet einen ersten Schalterschaltkreis, der selektiv zwischen dem ersten Prozessor und dem ersten und dem zweiten Speichergerät umschaltet, und einen zweiten Schalterschaltkreis, der selektiv zwischen dem zweiten Prozessor und dem ersten und dem zweiten Speichergerät umschaltet. Der erste Prozessor kann dazu konfiguriert sein, eine Benachrichtigung zu empfangen, dass eine Softwareaktualisierung an dem zweiten Speichergerät verfügbar ist. Der erste Prozessor kann den ersten Schalterschaltkreis dahingehend steuern, die Kommunikation von dem ersten Speichergerät zu dem zweiten Speichergerät zu schalten. Der erste Prozessor kann die Softwareaktualisierung von dem zweiten Speichergerät ausführen.
In einer Ausführungsform umfasst ein Schaltkreis einen ersten Prozessor, der für den Fahrzeugbetrieb konfiguriert ist, und einen zweiten Prozessor, der für Softwareaktualisierungen konfiguriert ist. Der Schaltkreis kann weiterhin ein erstes und ein zweites Speichergerät umfassen, die dazu konfiguriert sind, mit dem ersten und dem zweiten Prozessor zu kommunizieren. Der Schaltkreis kann weiterhin einen ersten Schalter, der dazu konfiguriert ist, selektiv zwischen dem ersten Prozessor und dem ersten und dem zweiten Speichergerät umzuschalten, und einen zweiten Schalter, der dazu konfiguriert ist, selektiv zwischen dem zweiten Prozessor und dem ersten und dem zweiten Speichergerät umzuschalten, umfassen. Als Reaktion auf eine Softwareaktualisierung an dem zweiten Speichergerät mittels des zweiten Prozessors schaltet der Schalter, um die Kommunikation zwischen dem ersten Prozessor von dem ersten Speichergerät zu dem zweiten Speichergerät zu wechseln.
In einer Ausführungsform kann ein Fahrzeug-Softwareaktualisierungsverfahren eine Softwareaktualisierung an einem ersten Speichergerät während des Fahrzeugbetriebs empfangen. Das Verfahren kann eine Benachrichtigung an einem ersten Controller empfangen, dass die Softwareaktualisierung an dem ersten Speichergerät verfügbar ist. Das Verfahren kann einen Schaltkreis dahingehend steuern, die Kommunikation zwischen dem ersten Controller mit einem zweiten Speichergerät zu dem ersten Speichergerät umzuschalten. Das Verfahren kann die Softwareaktualisierung von dem ersten Speichergerät an dem ersten Controller ausführen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 stellt eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Datenverarbeitungssystem für ein Fahrzeug dar;
2 stellt ein beispielhaftes Fahrzeugsystem dar, das ein Softwareaktualisierungsverwaltungsmodul beinhaltet;
3A stellt ein Beispiel eines programmierbaren Speicherkreises für das fahrzeugbasierte Datenverarbeitungssystem dar;
3B stellt ein Beispiel des programmierbaren Speicherkreises für ein Fahrzeugmodul in Kommunikation mit dem fahrzeugbasierten Datenverarbeitungssystem dar und
4 ist ein Ablaufdiagramm, das ein beispielhaftes Verfahren zum Verwalten von Softwareaktualisierungen unter Verwendung des programmierbaren Speicherkreises darstellt.
AUSFÜHRLICHE BESCHREIBUNG
Ausführungsformen der vorliegenden Offenbarung sind hierin beschrieben. Es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich Beispiele sind und andere Ausführungsformen verschiedene und alternative Formen annehmen können. Die Figuren sind nicht unbedingt maßstabgetreu; einige Merkmale könnten ü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 Ausführungsformen zu lehren. Wie Durchschnittsfachmänner verstehen werden, können verschiedene Merkmale, die unter Bezugnahme auf eine beliebige der Figuren dargestellt und beschrieben sind, mit Merkmalen kombiniert werden, die in einer oder mehreren anderen Figuren dargestellt sind, um Ausführungsformen zu ergeben, die nicht ausdrücklich dargestellt oder beschrieben sind. Die Kombinationen von dargestellten Merkmalen stellen repräsentative Ausführungsformen für typische Anwendungen bereit. Verschiedene Kombinationen und Modifizierungen der Merkmale, die mit den Lehren dieser Offenbarung vereinbar sind, könnten jedoch für bestimmte Anwendungen oder Umsetzungen erwünscht sein.
Die Ausführungsformen der vorliegenden Offenbarung sehen im Allgemeinen mehrere Schaltkreise oder andere elektrische Geräte vor. Alle Verweise auf die Schaltkreise und andere elektrische Geräte und die Funktionalität, die von diesen jeweils bereitgestellt wird, sollen nicht darauf beschränkt sein, nur das zu umfassen, was hierin dargestellt und beschrieben ist. Während den offenbarten verschiedenen Schaltkreisen oder anderen elektrischen Geräten besondere Kennzeichnungen zugeteilt sein können, sollen derartige Kennzeichnungen den Umfang des Betriebs für die Schaltkreise und die anderen elektrischen Geräte nicht einschränken. Derartige Schaltkreise und andere elektrische Geräte können auf der Basis des bestimmten Typs der elektrischen Umsetzung, die gewünscht wird, miteinander kombiniert und/oder auf beliebige Weise getrennt werden. Es wird anerkannt, dass ein beliebiger Schaltkreis oder ein beliebiges elektrisches Gerät, der bzw. das hierin offenbart ist, eine beliebige Anzahl von Mikroprozessoren, integrierten Schaltkreisen, Speichergeräten (z. B. FLASH, Direktzugriffsspeicher (random access memory, RAM), Festwertspeicher (read only memory, ROM), elektrisch programmierbarer Festwertspeicher (electrically programmable read only memory, EPROM), elektrisch löschbarer programmierbarer Festwertspeicher (electrically erasable programmable read only memory, EEPROM) oder andere geeignete Varianten davon) und Software, die mit einer anderen zusammenwirken kann, um einen bzw. mehrere hierin offenbarte Arbeitsvorgänge durchzuführen, beinhalten kann. Darüber hinaus können ein beliebiges oder mehrere beliebige der elektrischen Geräte dazu konfiguriert sein, ein Computerprogramm auszuführen, das in einem nichtflüchtigen computerlesbaren Medium verkörpert ist, das dazu programmiert ist, eine beliebige Anzahl der wie offenbarten Funktionen durchzuführen.
Diese Erfindungsoffenbarung bezieht sich auf ein System und ein Verfahren zum Verbessern des Aktualisierens und Flashens neuer Software an einem Fahrzeugdatenverarbeitungssystem. Wenn beispielsweise ein Software-Upgrade für ein Fahrzeug durch einen Speicherstick, der dem Kunden gesendet wurde, oder bei dem Händler empfangen wird, kann es erforderlich sein, dass das Fahrzeug während des Softwareaktualisierungs-/-Flash-Vorgangs deaktiviert ist (bei eingeschalteter Elektronik). Dies bereitet dem Kunden Unannehmlichkeiten, während er für einen längeren Zeitraum wartet, um das Abschließen der Aktualisierung zu ermöglichen. Während des Aktualisierungs-/Flashvorgangs eines Steuermoduls ist der Bediener möglicherweise nicht dazu in der Lage, das Fahrzeug unbeaufsichtigt zu lassen, und das Fahrzeug kann funktionsunfähig sein.
Diese Offenbarung kann das Fahrzeugdatenverarbeitungssystem einsetzen, das ein Adressbusdesign umfasst, das ermöglicht, dass zwei oder mehr Speichergeräte (z. B. elektrisch löschbarer programmierbarer Festwertspeicher (EEPROM)) existieren. Ein erstes Speichergerät (z. B. der erste EEPROM) ist verdrahtet, um das Fahrzeugsystem zu betreiben, während das zweite Speichergerät (z. B. der zweite EEPROM) verdrahtet ist, um einen Softwareaktualisierungs-Flash anzunehmen. Wenn die Softwareaktualisierung an dem zweiten EEPROM abgeschlossen ist, werden die zwei Sätze von Adresszeilen gewechselt (vertauscht), wenn der Fahrzeugzündschalter abgeschaltet wird. Ab diesem Zeitpunkt bis zum nächsten Flash-Ereignis kann der zweite EEPROM, der den Flash annahm, das System betreiben, während der erste EEPROM mit der veralteten Software bereit ist und darauf wartet, den nächsten Flash anzunehmen.
Die Offenbarung betrifft ein System und ein Verfahren zum Aktualisieren von Software an einem oder mehreren Steuermodulen des Fahrzeugdatenverarbeitungssystems während des Fahrzeugbetriebs. Das offenbarte System und das offenbarte Verfahren können Software aktualisieren, ohne eine Unterbrechung des Betriebs des Fahrzeugs zu bewirken. Die aktualisierte Software kann an dem Fahrzeug unter Verwendung eines zusätzlichen Speichergeräteschaltkreises gespeichert werden, der für Softwareaktualisierungen entworfen ist, bis das Fahrzeugdatenverarbeitungssystem eine Anforderung bereitstellt, die aktualisierte Software umzusetzen. Der zusätzliche Speichergeräteschaltkreis kann einen Schalter, um das selektive Umschalten zwischen einem oder mehreren Speichergeräten zu ermöglichen, ein oder mehrere Speichergeräte und einen Controller, der dazu bestimmt ist, Softwareaktualisierungen zu empfangen, um das ausgewählte Speichergerät zu flashen, beinhalten, ist jedoch nicht darauf beschränkt.
1 stellt eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Datenverarbeitungssystem 1 (vehicle-based computing system, VCS) 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 steuert ein Prozessor 3 zumindest einen Teil des Betriebs des fahrzeugbasierten Datenverarbeitungssystems. Ein zusätzlicher Prozessor (nicht gezeigt) kann mindestens einen Teil einer Softwareaktualisierung für das fahrzeugbasierte Datenverarbeitungssystem steuern. 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 (nichtflüchtiger) 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. Das System kann ein oder mehrere zusätzliche Speichergeräte (nicht gezeigt) umfassen. Das zusätzliche Speichergerät kann mit einem Schalter (nicht gezeigt) konfiguriert sein, um dem Zusatzprozessor zu ermöglichen, Softwareaktualisierungen an das zusätzliche Speichergerät ohne Unterbrechung des fahrzeugbasierten Datenverarbeitungssystems 1 zu übertragen.
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 einer nomadischen Vorrichtung 53 des Benutzers (z. B. Mobiltelefon, Smartphone, PDA oder eine beliebige andere Vorrichtung 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. Andere Kommunikationsmittel, die in diesem Gebiet verwendet werden können, 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 und sie bieten Datenübertragungsgeschwindigkeiten von bis zu 2 MB/s für stationäre oder gehende Benutzer und 385 KB/s für Benutzer in einem sich bewegenden Fahrzeug. 3G-Standards werden jetzt durch IMT-Advanced (4G) ersetzt, das 100 MB/s für Benutzer in einem Fahrzeug und 1 GB/s 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.
Das VCS kann mit zwei oder mehr Speichergeräten (z. B. EEPROM 202) konfiguriert sein, wie in 2 gezeigt. Die zwei oder mehr EEPROM 202 können derart konfiguriert sein, dass das System 200 ein EEPROM 202 zuteilen kann, um mit dem CPU 3 mittels eines Schalterschaltkreises zu kommunizieren, während der andere EEPROM 202 mit einem zweiten CPU (nicht gezeigt) kommuniziert, um eine Softwareaktualisierung zu empfangen. Der zweite CPU kann die Softwareaktualisierung während des Fahrzeugbetriebs empfangen. Der zweite CPU kann in Kommunikation mit einem oder mehreren Modulen 208 sein, um eine Softwareaktualisierung zu empfangen. Das eine oder die mehreren Module 208 können ein eingebettetes Modem, ein eingebettetes Mobiltelefon, ein drahtloses Modul mit kurzer Reichweite, das dazu verwendet wird, dem entfernten nomadischen Gerät 53 zu ermöglichen, mit dem VCS 1 zu kommunizieren, ein USB-Modul 23 und/oder eine Kombination davon beinhalten, sind jedoch nicht darauf beschränkt.
Das VCS 1 kann beispielsweise dazu konfiguriert sein, den Softwarestatus des einen oder der mehreren EEPROM 202 zu überwachen. Wenn der EEPROM 202, der sich nicht in aktueller Kommunikation mit dem CPU 1 befindet, eine Softwareaktualisierung mittels des zweiten CPU empfangen hat, kann das VCS 1 ermöglichen, dass die Softwareaktualisierung von dem VCS 1 ausgeführt wird, sobald ein Initialisierungsereignis stattgefunden hat. In einer Ausführungsform ist das Initialisierungsereignis ein Zündschlüssel-Ein-Ereignis, ein Zündschlüssel-Aus-Ereignis und/oder eine von einem Benutzer initiierte Anforderung, die Initialisierung des Systems zu ermöglichen. Als Reaktion auf das Initialisierungsereignis kann das VCS 1 den CPU 3 umschalten, um die Software an dem EEPROM 202 zu empfangen, der die aktualisierte Software hat. Der CPU 3 kann die aktualisierte Software ausführen, die von dem EEPROM 202 empfangen wurde.
2 stellt ein beispielhaftes System 200 eines Fahrzeugs 31 zum Bereitstellen von Softwareaktualisierungen an das Fahrzeug 31 dar. Das System 200 beinhaltet das VCS 1 in Kommunikation mit einem Aktualisierungsserver 218 über das Netz 61. Der Aktualisierungsserver 218 kann mit einem Softwaredatenspeicher 220 kommunizieren, der Fahrzeugkonfigurationen 222 und Softwareaktualisierungen 224 speichert. Das System 200 beinhaltet weiterhin ein Softwareaktualisierungsverwaltungsmodul 214 in Kommunikation mit dem VCS 1 und verschiedenen Modulen 208 des Fahrzeugs 31, das dazu konfiguriert ist, Softwareaktualisierungen 224 zu installieren. Das VCS 1 kann weiterhin eine Softwareaktualisierungsanwendung (nicht gezeigt) beinhalten, die dazu konfiguriert ist, dem Benutzer zu ermöglichen, die Anwendung von Softwareaktualisierungen 224 zu steuern, die mittels des Softwareaktualisierungsverwaltungsmoduls 214 durchgeführt wurden. 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 mehrere Fahrzeugmodule 208 dargestellt sind, können die Systeme 200 mehr oder weniger Module 208 beinhalten. Als ein anderes Beispiel: Obwohl das Softwareaktualisierungsverwaltungsmodul 214 als eine separate Komponente dargestellt ist, kann es in anderen Beispielen mit anderen Komponenten kombiniert werden, z. B. als eine Möglichkeit mit dem VCS 1 integriert werden.
Die Fahrzeugmodule 208 können verschiedene Komponenten des Fahrzeugs 31 beinhalten, die dazu konfiguriert sind, Aktualisierungen von assoziierter Software, Firmware oder Konfigurationseinstellungen zu empfangen. Die Fahrzeugmodule 208 können beispielsweise dazu konfiguriert sein, eine Aktualisierungsschnittstelle von Fahrzeugbusbefehlen umzusetzen, die einen Befehl, um einen Softwareaktualisierungsmodus für das Fahrzeugmodul 208 aufzurufen, einen Befehl, um eine aktualisierte Konfiguration oder aktualisierte Softwaredaten, die auf das Fahrzeugmodul 208 angewendet werden sollen, zu empfangen, und einen Befehl, um das Fahrzeugmodul 208 zurückzusetzen und die Konfiguration und die Softwaredaten mittels eines EEPROM 202 im Bereitschaftsmodus neu zu laden, beinhalten. Als einige nicht einschränkende Beispiele können die Fahrzeugmodule 208 ein Antriebsstrangsteuermodul (ASM), ein Telematiksteuermodul (telematics control module, TCM), ein Bremssystemsteuermodul (brake system control module, BCSM) und ein übergeordnetes Steuermodul (body control module, BCM) beinhalten.
Das Softwareaktualisierungsverwaltungsmodul 214 kann dazu konfiguriert sein, auf ein Fahrzeugbordnetz zuzugreifen, um mit den Fahrzeugmodulen 208 zu kommunizieren. In einem Beispiel kann das Fahrzeugbordnetz ein Fahrzeug-Controller-Area-Network (Fahrzeug-CAN) sein. Wenn ein Fahrzeug 31 zusammengebaut wird, kann das Fahrzeug 31 verschiedene Hardware- und Softwarekomponenten beinhalten. Das Softwareaktualisierungsverwaltungsmodul 214 kann dazu konfiguriert sein, bei oder nach dem Zusammenbauen die Existenz und Versionsinformationen für mindestens einen Teil dieser Hardware- und Softwarekomponenten der Fahrzeugmodule 208 des Fahrzeugs 31 abzufragen.
Das Softwareaktualisierungsverwaltungsmodul 214 kann weiterhin dazu konfiguriert sein, auf das VCS 1 zuzugreifen, um mit dem Aktualisierungsserver 218 über das Netz 61 zu kommunizieren. Unter Verwendung der abgefragten Informationen und von zusätzlichen Informationen, die das spezifische Fahrzeug 31 identifizieren (z. B. FIN-Informationen, die auf dem CAN-Bus veröffentlicht sind, SIM-Informationen (SIM = subscriber identity module, Teilnehmerkennungsmodul) des Modems 63, wie eine IMEI-Kennzahl (IMEI = international mobile station equipment identity), usw.), kann das Softwareaktualisierungsverwaltungsmodul 214 mittels des Netzes 61 kommunizieren, um ein Konto mit dem Aktualisierungsserver 218 einzurichten. Der Aktualisierungsserver 218 kann diese Kommunikationen von den Fahrzeugen 31 empfangen und kann einen Softwaredatenspeicher 220 von Informationen zur Fahrzeugkonfiguration 222 in Bezug auf die empfangenen Hardwarekonfiguration und Softwareversionen (z. B. Firmware usw.), die mit Kennungen der Fahrzeuge 31 verknüpft sind, pflegen.
Der Softwaredatenspeicher 220 kann weiterhin dazu konfiguriert sein, Softwareaktualisierungen 224 zu speichern, die dem Fahrzeug 31 bereitgestellt werden können. Die Softwareaktualisierungen 224 können beispielsweise aktualisierte Konfigurationseinstellungen für ein oder mehrere Module des Fahrzeugs 31 und/oder aktualisierte Versionen von Software oder Firmware, die auf einem oder mehreren Modulen des Fahrzeugs 31 installiert werden soll, beinhalten. Die Softwareaktualisierungen 224 können auch beispielsweise zusätzliche Anwendungen beinhalten, die zum Herunterladen in das Fahrzeug 31 verfügbar sein können.
Der Softwaredatenspeicher 220 kann weiterhin dazu konfiguriert sein, zusätzliche Informationen zu den Softwareaktualisierungen 224 zu speichern. Der Softwaredatenspeicher 220 kann beispielsweise dazu konfiguriert sein, ein fakultatives/erforderliches Flag in Bezug auf die Softwareaktualisierungen 224 zu pflegen, das den Fahrzeugen 31 ermöglicht zu bestimmen, welche Softwareaktualisierungen 224 erforderlich sind und welche fakultativ sind (z. B. ein fakultatives Flag). Als ein anderes Beispiel: Der Softwaredatenspeicher 220 kann dazu konfiguriert sein, Hinweise darauf zu pflegen, welches bzw. welche Fahrzeugmodule 208 mit welchen Softwareaktualisierungen 224 assoziiert sind. Der Softwareaktualisierungsspeicher 220 kann weiterhin Informationen speichern, die auf die Kompatibilität der Softwareaktualisierungen 224 mit dem Modell oder der Konfiguration des Fahrzeugs hinweisen. Ein Speichereintrag für eine Softwareaktualisierung 224 kann beispielsweise darauf hinweisen, dass die Softwareaktualisierung 224 mit einer bestimmten Marke und einem bestimmten Modell des Fahrzeugs 31 kompatibel ist oder dass sie von einer Version eines anderen Fahrzeugmoduls 208, bei der es sich um eine bestimmte Version oder bestimmte Versionen handelt, abhängig ist.
Die Softwareaktualisierungsanwendung kann dazu konfiguriert sein, einen Hinweis darauf zu empfangen, das Bereitstellen von Softwareaktualisierungen 224 zu initiieren. Als eine Möglichkeit kann die Softwareaktualisierungsanwendung des VCS 1 eine Befehlsanforderung von einem Benutzer empfangen, die anfordert, auf Softwareaktualisierungen 224 zu prüfen. Als eine andere Möglichkeit kann das Softwareaktualisierungsverwaltungsmodul 214 eine periodische Prüfung auf neue Softwareaktualisierungen 224 auslösen und kann einen Hinweis auf die ausgelöste Anforderung an die Softwareaktualisierungsanwendung bereitstellen. Die Softwareaktualisierungsanwendung kann dazu konfiguriert sein, bei Anforderung durch den Benutzer oder durch das Softwareaktualisierungsverwaltungsmodul 214 eine Anforderung an den Aktualisierungsserver 218 zu senden, um zu fragen, ob Softwareaktualisierungen 224 für das Fahrzeug 31 verfügbar sind. Die Softwareaktualisierungsanwendung kann beispielsweise den Aktualisierungsserver 218 unter Verwendung einer Kennung des Fahrzeugs 31 (z. B. FIN des Fahrzeugs 31, SIM-Informationen des Fahrzeugs 31 usw.) abfragen und kann eine Antwort von dem Aktualisierungsserver 218 empfangen, die darauf hinweist, ob neue Softwareaktualisierungen 224 für das Fahrzeug 31 verfügbar sind (z. B. als Links oder andere Kennungen von Softwareaktualisierungen 224 für das Fahrzeug 31 zum Herunterladen).
Die Softwareaktualisierungsanwendung kann weiterhin dazu konfiguriert sein, eine Benutzeroberfläche für das Softwareaktualisierungsverwaltungsmodul 214 dem Benutzer mittels des VCS 1 bereitzustellen. Die Softwareaktualisierungsanwendung kann beispielsweise dazu konfiguriert sein, eine Aufforderung an den Benutzer bereitzustellen (z. B. mittels der Anzeige 4 oder dem Lautsprecher 13 des VCS 1), die den Benutzer informiert, dass Softwareaktualisierungen 224 verfügbar sind und, und eine Genehmigung anfordert, mit der Installation des Softwareaktualisierungen 224 zu beginnen. Als eine andere Möglichkeit kann die Softwareaktualisierungsanwendung dazu konfiguriert sein, einen Hinweis auf verfügbare Aktualisierungen in der Tankuhrgruppe des Fahrzeugs 31 bereitzustellen, wenn Softwareaktualisierungen 224 verfügbar (z. B. heruntergeladen) sind.
Sobald der Benutzer bestätigt, dass die Softwareaktualisierungen 224 installiert werden sollten, kann das Softwareaktualisierungsverwaltungsmodul 214 dazu konfiguriert sein, verschiedene Funktionen zu unterstützen, die bei der Unterstützung des Aktualisierens der Software der Fahrzeugmodule 208 von Nutzen sind. Das Softwareaktualisierungsverwaltungsmodul 214 kann beispielsweise dazu konfiguriert sein, einen Softwareaktualisierungsmodus für die Fahrzeugmodule 208, die von den Softwareaktualisierungen 224 als Empfänger der Softwareaktualisierungen 224 identifiziert wurden, aufzurufen, indem eine Nachricht von dem Softwareaktualisierungsverwaltungsmodul 214 an die Empfängerfahrzeugmodule 208 über den Fahrzeugbus bereitgestellt wird. Das Softwareaktualisierungsverwaltungsmodul 214 kann eine Nachricht an das VCS 1 übertragen, um zu bestimmen, ob die Softwareaktualisierung auf einen verfügbaren EEPROM 202 hochgeladen werden kann, der nicht von dem einen oder den mehreren Modulen 208 verwendet wird. Das Fahrzeugsystem 200 kann zwei oder mehr EEPROM 202 umfassen. Das Fahrzeugsystem 200 kann zwischen den zwei oder mehr EEPROM 202 hin und her wechseln, so dass eine aktuelle Version der Software an einem EEPROM 202A gespeichert und von dem VCS 1 ausgeführt werden kann, während der andere EEPROM 202B verfügbar sein kann, um eine Softwareaktualisierung zu empfangen.
In einem Beispiel kann die Softwareaktualisierungsanwendung dazu konfiguriert sein, Softwareaktualisierungen automatisch zu akzeptieren, die für das eine oder die mehreren Module 208 in Kommunikation mit dem VCS 1 verfügbar sind. Das VCS 1 kann einen Schalterschaltkreis 206 dahingehend steuern, mit einem EEPROM 202A zu kommunizieren. Der Schalterschaltkreis 206 ermöglicht dem EEPROM 202A, Software an das eine oder die mehreren Module zur Ausführung zu übertragen. Der Schalterschaltkreis 206 kann dem EEPROM 202B ermöglichen, für Softwareaktualisierungen verfügbar zu sein, ohne das VCS 1 zu stören. Das Softwareaktualisierungsverwaltungsmodul 214 kann die Softwareaktualisierung empfangen und es an das EEPROM 202B übertragen, das derzeit nicht von dem einen oder den mehreren Modulen 208 und/oder dem VCS 1 verwendet wird. Bei einem Initialisierungsereignis kann das VCS 1 den Schalterschaltkreis 206 derart steuern, dass der EEPROM 202B, der die aktualisierte Software empfing, nun in Kommunikation mit dem einen oder den mehreren Modulen 208 ist, wodurch nun der andere EEPROM 202A für eine Softwareaktualisierung verfügbar bleibt.
Das Softwareaktualisierungsverwaltungsmodul 214 kann weiterhin dazu konfiguriert sein, die Softwareaktualisierungen 212 an den verfügbaren EEPROM 202, der derzeit nicht von den Fahrzeugmodulen 208 verwendet wird, mittels des Fahrzeugbusses zu übertragen. Das Fahrzeugsystem kann ermöglichen, dass die Softwareaktualisierung mittels des EEPROM 202 von den Empfängerfahrzeugmodulen 208 bei einem Initialisierungsereignis verwendet wird. Das Initialisierungsereignis ermöglicht dem VCS zu bestimmen, ob eine Softwareaktualisierung abgeschlossen wurde, und bewirkt folglich, dass der Schalterschaltkreis den EEPROM 202 mit der Softwareaktualisierung mit den Fahrzeugmodulen 208 verbindet, um die aktualisierte Software neu zu laden und zu nutzen. Das Softwareaktualisierungsverwaltungsmodul 214 kann auch dazu konfiguriert sein, Diagnosefunktionen in Bezug auf den Erfolg des Aktualisierungsablaufs durch Lesen von Diagnosecodes mittels des Fahrzeugbusses durchzuführen.
In einem früheren System kann die Softwareaktualisierung erfordern, dass das Fahrzeug funktionsunfähig ist, da ein zugeteilter EEPROM mit der Softwareaktualisierung neu geflasht werden muss. Die Verwendung von zwei oder mehr EEPROM 202 ermöglicht dem Fahrzeugsystem 200, eine Softwareaktualisierung durchzuführen, während dem Modul 208 ermöglicht wird, mit dem Kommunizieren mit dem EEPROM 202 mit der ausgeführten aktuellen Software fortzufahren, während der verfügbare EEPROM mit der aktualisierten Software geflasht wird. Weitere Gesichtspunkte des Betriebs des Softwareaktualisierungsverwaltungsmoduls 214 und der Softwareaktualisierungsanwendung unter Verwendung von zwei oder mehr EEPROM werden in Bezug auf 3A, 3B und 4 im Folgenden erörtert.
3A stellt ein Beispiel eines programmierbaren Speicherkreises 300 für das VCS 1 dar. Das VCS 1 kann einen aktiven EEPROM 202A, der Software an einen CPU 3 überträgt, der für den Fahrzeugbetrieb konfiguriert ist, und einen anderen CPU 302, der zum neuen Flashen eines EEPROM 202B im Bereitschaftsmodus mit einer Softwareaktualisierung konfiguriert ist, umfassen. Das VCS 1 kann einen Schalter 206 steuern, um dem CPU 3 einen EEPROM 202 zuzuteilen. Der Schaltkreis des Schalters 206 besteht aus zwei Teilen, die sich jeweils aus zwei Gruppen von Feldeffekttransistoren (FET) zusammensetzen. Die zwei Teile der Schaltschaltkreise arbeiten identisch, mit Ausnahme davon, dass einer mit dem EEPROM 202A und der andere mit dem EEPROM 202B verdrahtet ist. In dem Teil, der mit dem EEPROM 202A verdrahtet ist, ist eine erste Gruppe von FET (FET1) angeordnet, um eine Verbindung zwischen den Adresszeilen des CPU 3 zur Fahrzeugsteuerung und dem EEPROM 202A herzustellen. Wenn die FET aktiviert werden, wird die Verbindung zwischen den Adresszeilen der zwei Chips hergestellt. Wenn die FET abgeschaltet sind, ist die Verbindung geöffnet. Die zweite Gruppe von FET (FET2) sind angeordnet, um eine Verbindung zwischen den Adresszeilen des CPU 302 zum Flashen und den Speicherchips des EEPROM 202A herzustellen. Wenn die FET aktiviert werden, wird die Verbindung zwischen den zwei Chips hergestellt. Wenn der FET abgeschaltet ist, ist die Verbindung geöffnet. Durch Aktivieren der ersten Gruppe von FET, während die zweite Gruppe von FET deaktiviert ist, wird der Speicher ausschließlich mit dem CPU 3 zur Fahrzeugsteuerung verbunden. Umgekehrt wird bei Deaktivieren der ersten Gruppe von FET, während die zweite Gruppe von FET aktiviert ist, der Speicher ausschließlich mit dem CPU 302 zum Flashen verbunden. Auf ähnliche Weise steuern eine dritte und eine vierte Gruppe von FET die Verbindungen von EEPROM 202B.
FET1 oben mit FET2 unten verbindet beispielsweise EEPROM 202A mit dem CPU 3 zur Fahrzeugsteuerung und FET3 unten mit FET4 oben verbindet EEPROM 202B mit dem CPU 302 zum Flashen. Als solches ist die Detailfunktion des Schaltkreises gegeben. Es kann beobachtet werden, dass FET2 und FET2 immer entgegengesetzt zueinander sind und dass FET3 und FET4 immer entgegengesetzt zueinander sind und folglich nicht einzeln angegeben werden müssen. Darüber hinaus sind FET3 und FET1 immer Gegenteile. Somit kann der Betrieb des Schaltkreises 300 einfacher beschrieben werden, als wenn FET1 oben ist, verbindet EEPROM 202A sich mit dem CPU 303 zur Fahrzeugsteuerung und EEPROM 202B verbindet sich mit dem CPU 302 zum Flashen. Wenn FET1 unten ist, verbindet sich EEPROM 202A mit dem CPU 302 zum Flashen und EEPROM 202B verbindet sich mit dem CPU 3 zur Fahrzeugsteuerung.
In einem anderen Beispiel kann das VCS 1 dem aktiven EEPROM 202A ermöglichen, mit dem CPU 3 für den Fahrzeugbetrieb zu kommunizieren. Das VCS 1 kann benachrichtigt werden, dass der EEPROM 202B im Bereitschaftsmodus einen aktualisierten Software-Flash mittels des CPU 302 in Kommunikation mit dem Aktualisierungsserver 218 empfangen hat.
Das VCS 1 kann beispielsweise den Schalter 206 während eines Schlüssel-Ein-Ereignisses steuern, so dass das CPU 3, der das Fahrzeugsystem betreibt, in Kommunikation mit dem EEPROM 202A ist, der Software umfasst, die zur Ausführung verfügbar ist. Das VCS 1 kann den Schalter 206 derart steuern, dass der CPU 302, der für das Empfangen der aktualisierten Software vorgesehen ist, in Kommunikation mit dem EEPROM 202B ist, der nicht während des Fahrzeugbetriebs verwendet wird. Der EEPROM 202B im Bereitschaftsmodus kann eine Softwareaktualisierung von dem Aktualisierungsserver 218 empfangen. Die Softwareaktualisierung kann von dem EEPROM 202B im Bereitschaftsmodus ohne jegliche Unterbrechung des Betriebs des Fahrzeugs empfangen werden. Das VCS 1 kann eine Nachricht empfangen, sobald das Hochladen der Softwareaktualisierung an dem EEPROM 202B im Bereitschaftsmodus abgeschlossen ist. Das VCS 1 kann eine Nachricht erzeugen, die einen Fahrzeugbenutzer benachrichtigt, dass eine Softwareaktualisierung verfügbar ist. Das VCS 1 kann die Nachricht auf der Anzeige 4 ausgeben. Der Fahrzeugbenutzer kann die Option haben, die Softwareaktualisierung zu akzeptieren, so dass das VCS 1 die Softwareaktualisierung beim nächsten Fahrzeugschlüssel-Ein-Ereignis empfängt. In einer anderen Ausführungsform kann der Fahrzeugbenutzer die Option haben, die Softwareaktualisierung zu akzeptieren, so dass das VCS ein Reinitialisierungsereignis durchführt. Als Reaktion auf das Akzeptieren der Softwareaktualisierung durch den Fahrzeugbenutzer und beim nächsten Schlüssel-Ein-Ereignis kann das VCS 1 den Schalter derart steuern, dass der EEPROM 202B im Bereitschaftsmodus nun in Kommunikation mit dem CPU 3 ist, der das Fahrzeug betreibt. Der einst aktive EEPROM 202A ist nun in Kommunikation mit dem CPU 302, der zum Empfangen aktualisierter Software vorgesehen ist.
In einem anderen Beispiel kann der CPU 3, der für den Fahrzeugbetrieb konfiguriert ist, eine Softwareaktualisierungsnachricht empfangen. Die Softwareaktualisierungsnachricht kann dem CPU 3 Informationen bereitstellen, dass der zweite EEPROM 202B eine Softwareaktualisierung empfangen hat. Als Reaktion auf ein Initialisierungsereignis kann die CPU 3 den Schalterschaltkreis 206 auf der Basis der Softwareaktualisierungsnachricht steuern. Der CPU 3 kann ein Signal an den Schalterschaltkreis 206 übertragen, um eine Kommunikation mit dem zweiten EEPROM 202B herzustellen, der die aktualisierte Software enthält. In anderen Ausführungsformen kann der CPU 302, der dazu konfiguriert ist, den verfügbaren EEPROM zu flashen, und/oder ein zusätzlicher Prozessor (nicht gezeigt) dem Schaltkreis zum Steuern des Schalters 206 hinzugefügt werden.
3B stellt ein Beispiel des programmierbaren Speicherkreises 350 für ein Fahrzeugmodul 208 in Kommunikation mit dem VCS 1 dar. Das Fahrzeugmodul 208 kann den EEPROM 202B, der Software an den CPU 304 überträgt, der für den Fahrzeugbetrieb konfiguriert ist, und einen anderen CPU 306, der zum neuen Flashen eines EEPROM 202A im Bereitschaftsmodus konfiguriert ist, umfassen.
Das VCS 1 kann beispielsweise eine Softwareaktualisierung von mindestens einem eines entfernten Servers (z. B. dem Aktualisierungsserver 218), eines USB-Laufwerks mittels des USB-Ports 23 und/oder einer Kombination davon empfangen. Das VCS 1 kann mit dem Aktualisierungsserver 218 unter Verwendung eines oder mehrerer drahtloser Kommunikationsgeräte kommunizieren, die ein eingebettetes Mobiltelefon, ein eingebettetes Modem, ein verbundenes nomadisches Gerät 53 in Kommunikation mit dem Aktualisierungsserver 218 und/oder eine Kombination davon beinhalten.
In einem Beispiel kann das VCS 1 die Softwareaktualisierung von einem USB-Laufwerk mittels des USB-Ports 23 empfangen. Das VCS 1 kann die Daten verwalten, die von dem USB-Port 23 empfangen wurden, und kann die Softwareaktualisierung an das jeweilige Fahrzeugmodul 208 übertragen. Das Fahrzeugmodul 208 kann die Softwareaktualisierung mittels des CPU 306 empfangen, der zum neuen Flashen eines EEPROM 202A im Bereitschaftsmodus konfiguriert ist. Das Fahrzeugmodul kann damit fortfahren, ein oder mehrere Fahrzeugsysteme ohne Unterbrechung des Empfangens der Softwareaktualisierung an dem EEPROM 202A zu betreiben. Das Fahrzeugmodul 208 kann damit fortfahren, eine oder mehrere Funktionen auf der Basis des CPU 304, der für den Fahrzeugbetrieb konfiguriert ist, durchzuführen, indem Software ausgeführt wird, die von dem aktiven EEPROM 202B empfangen wurde.
Das Fahrzeugsystem kann eine Softwareaktualisierungsbenachrichtigung von dem Fahrzeugmodul 208 empfangen. Als Reaktion auf die Softwareaktualisierungsbenachrichtigung kann das Fahrzeugmodul 208 dem Schalter ermöglichen, eine Anforderung zu übertragen, so dass der CPU 304, der für den Fahrzeugbetrieb konfiguriert ist, nun in Kommunikation mit dem EEPROM 202A sein kann, der die aktualisierte Software empfangen hat. Das Fahrzeugmodul 208 kann dem Schalter 206 ermöglichen, bei einem Initialisierungsereignis zu dem EEPROM 202A zu schalten, der die Softwareaktualisierung umfasst. Das Initialisierungsereignis kann ein Schlüssel-Ein-, Schlüssel-Aus- und/oder ein Systemreinitialisierungsereignis beinhalten, ist jedoch nicht darauf beschränkt.
4 ist ein Ablaufdiagramm, das ein beispielhaftes Verfahren 400 zum Verwalten von Softwareaktualisierungen unter Verwendung des programmierbaren Speicherkreises darstellt. Das Softwareaktualisierungsverfahren kann eine oder mehrere Softwareanwendungen umfassen, die auf Hardware in dem Fahrzeugsystem ausgeführt werden. Die eine oder die mehreren Anwendungen können Anweisungen beinhalten, um mit einer oder mehreren Komponenten des Fahrzeugs zu kommunizieren und Softwareaktualisierungen zu einem verfügbaren EEPROM zu verwalten, ohne den Fahrzeugbetrieb zu stören. Das Verfahren 400 kann unter Verwendung von Softwarecode umgesetzt werden, der in dem VCS 1 enthalten ist. In anderen Ausführungsformen kann das Verfahren 400 in anderen Fahrzeug-Controllern, an einem entfernten Server in Kommunikation mit dem VCS 1, verteilt unter mehreren Fahrzeug-Controllern oder einer Kombination davon umgesetzt werden.
Erneut unter Bezugnahme auf die 4 wird überall in der Erörterung des Verfahrens 400 auf das Fahrzeug und seine Komponenten, die in 1, 2, 3A und 3B dargestellt sind, verwiesen, um ein Verständnis verschiedener Gesichtspunkte der vorliegenden Offenbarung zu erleichtern. Das Verfahren 400 des Aktualisierens von Software, während das Fahrzeug betrieben wird, kann durch einen Computeralgorithmus, einen rechnerausführbaren Code oder Softwareanweisungen, die in eine oder mehrere geeignete programmierbare Logikanordnungen des Fahrzeugs programmiert sind, wie das Fahrzeugsteuermodul, ein Steuermodul an dem entfernten Server ein anderer Controller in Kommunikation mit dem Fahrzeugdatenverarbeitungssystem oder eine Kombination davon, umgesetzt werden. Obwohl die in dem Ablaufdiagramm 400 gezeigten verschiedenen Arbeitsvorgänge in einer chronologischen Abfolge erfolgen zu scheinen, können mindestens einige der Arbeitsvorgänge in einer anderen Reihenfolge erfolgen und einige Arbeitsvorgänge können gleichzeitig oder überhaupt nicht durchgeführt werden.
Im Arbeitsschritt 402 kann das Fahrzeugsystem ein Initialisierungsereignis umfassen, das eine oder mehrere Datenvariablen beinhalten kann, die für ein Fahrzeugbetriebsstartereignis konfiguriert werden sollen. Als Reaktion auf die Systeminitialisierung kann das Fahrzeugsystem bestimmen, ob neue Software zur Ausführung in Arbeitsschritt 404 verfügbar ist. Das System kann eine existierende Schalterstellung beibehalten, so dass der aktive EEPROM damit fortfährt, Software an den CPU zu übertragen, der für den Fahrzeugbetrieb konfiguriert ist, wenn keine neue Software in Arbeitsschritt 406 verfügbar ist.
Wenn neue Software verfügbar ist, kann das Fahrzeugsystem in Arbeitsschritt 408 bestimmen, ob die neue Software an dem EEPROM im Bereitschaftsmodus gespeichert ist. Wenn die neue Software an dem EEPROM im Bereitschaftsmodus gespeichert ist, kann das System in Arbeitsschritt 418 die Schalterstellung derart ändern, dass der EEPROM mit der aktualisierten Software in Kommunikation mit dem CPU ist, der dazu konfiguriert ist, das Fahrzeug zu betreiben.
Wenn die neue Software nicht an dem EEPROM im Bereitschaftsmodus ist, kann das System in Arbeitsschritt 410 eine Kommunikation mit dem entfernten Server herstellen, um die aktualisierte Software zu empfangen. Der Server kann die aktualisierte Software drahtlos an das System übertragen. Das System kann die Software von dem Server empfangen. Das System kann in Arbeitsschritt 412 den EEPROM im Bereitschaftsmodus mittels eines CPU flashen, der zum neuen Flashen des EEPROM im Bereitschaftsmodus konfiguriert ist, der nicht derzeit von dem Fahrzeugsystem verwendet wird.
In Arbeitsschritt 414 kann das System bestimmen, wann der Flash des EEPROM im Bereitschaftsmodus abgeschlossen ist. Als Reaktion auf das Flashen eines EEPROM mit aktualisierter Software kann das System in Arbeitsschritt 416 fortfahren zu überwachen, ob ein Initialisierungsereignis stattgefunden hat. Wenn kein Initialisierungsereignis erkannt wird, kann das System die Schalterstellung in Arbeitsschritt 406 beibehalten.
Wenn ein Initialisierungsereignis erkannt wird, kann das System in Arbeitsschritt 418 die Schalterstellung derart ändern, dass der EEPROM mit der aktualisierten Software in Kommunikation mit dem CPU ist, der für den Fahrzeugbetrieb konfiguriert ist. Der CPU, der für den Fahrzeugbetrieb konfiguriert ist, kann die aktualisierte Software in Arbeitsschritt 420 ausführen.
In Arbeitsschritt 422 kann das Fahrzeugsystem auf ein Schlüssel-Aus-Ereignis überwachen. Wenn kein Schlüssel-Aus-Ereignis erkannt wird, kann das System damit fortfahren, Softwareaktualisierungen zu dem EEPROM im Bereitschaftsmodus zu verwalten. Wenn ein Schlüssel-Aus-Ereignis erkannt wird, kann das System damit beginnen, ein oder mehrere Module herunterzufahren, die ein oder mehrere Variablen in einem nichtflüchtigen Speicher speichern, während das System darauf vorbereitet wird, die aktualisierte Software an dem EEPROM im Bereitschaftsmodus auszuführen. Sobald der EEPROM im Bereitschaftsmodus zu dem aktiven EEPROM wird, kann das System den vorherigen aktiven EEPROM darauf vorbereiten, mit dem CPU zu kommunizieren, der zum neuen Flashen eines EEPROM im Bereitschaftsmodus konfiguriert ist.
Obwohl beispielhafte Ausführungsformen oben beschrieben sind, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen beschreiben, die von den Ansprüchen umfasst werden. Die in der Spezifikation verwendeten Wörter sind Wörter zur Beschreibung anstelle zur Einschränkung und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Sinn und Schutzumfang der Offenbarung abzuweichen. Wie zuvor beschrieben, können die Merkmale verschiedener Ausführungsformen kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden, die nicht ausdrücklich beschrieben oder dargestellt sind. Während verschiedene Ausführungsformen möglicherweise als Vorteile bereitstellend oder gegenüber anderen Ausführungsformen oder Umsetzungen nach dem Stand der Technik in Bezug auf ein oder mehrere gewünschte Charakteristika bevorzugt beschrieben wurden, erkennen Durchschnittsfachmänner, dass bei einem oder mehreren Merkmalen oder Charakteristika ein Kompromiss geschlossen werden kann, um gewünschte Gesamtsystemattribute zu erzielen, die von der spezifischen Anwendung und Umsetzung abhängen. Diese Attribute können Kosten, Festigkeit, Dauerhaftigkeit, Lebenszykluskosten, Marktfähigkeit, Aussehen, Verpackung, Größe, Bedienbarkeit, Gewicht, Herstellbarkeit, Einbaufreundlichkeit usw. beinhalten, sind jedoch nicht darauf beschränkt. Dabei liegen Ausführungsformen, die als weniger wünschenswert als andere Ausführungsformen oder Umsetzungen nach dem Stand der Technik in Bezug auf ein oder mehrere Charakteristika beschrieben wurden, nicht außerhalb des Schutzumfangs der Offenbarung und können für bestimmte Anwendungen wünschenswert sein.
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 [0024]
IEEE-802-LAN-Protokolle [0024]
IEEE 1394 [0027]
IEEE 1284 [0027]
IEEE-803.11-Transceivers [0029]

Claims

Fahrzeugdatenverarbeitungssystem, das Folgendes umfasst: ein erstes Speichergerät in Kommunikation mit einem ersten Prozessor zum Ausführen einer oder mehrerer Fahrzeugarbeitsvorgänge; ein zweites Speichergerät in Kommunikation mit einem zweiten Prozessor zum Empfangen von Softwareaktualisierungen; einen ersten Schalterschaltkreis, der selektiv zwischen dem ersten Prozessor und dem ersten und dem zweiten Speichergerät umschaltet; und einen zweiten Schalterschaltkreis, der selektiv zwischen dem zweiten Prozessor und dem ersten und dem zweiten Speichergerät umschaltet, wobei der erste oder der zweite Prozessor dazu konfiguriert ist, eine Benachrichtigung zu empfangen, dass eine Softwareaktualisierung an dem zweiten Speichergerät verfügbar ist, den ersten Schalterschaltkreis zu steuern, um die Kommunikation mit dem ersten Prozessor von dem ersten Speichergerät zu dem zweiten Speichergerät zur Ausführung der Softwareaktualisierung durch den ersten Prozessor von dem zweiten Speichergerät zu schalten.
Fahrzeugdatenverarbeitungssystem nach Anspruch 1, wobei das erste und das zweite Speichergerät aus einem elektrisch löschbaren programmierbaren Festwertspeicher (EEPROM), einem FLASH, einem Direktzugriffsspeicher und/oder einem Festwertspeicher bestehen.
Fahrzeugdatenverarbeitungssystem nach Anspruch 1, das weiterhin als Reaktion darauf, dass der erste Schalterschaltkreis schaltet, um eine Kommunikation mit dem ersten Prozessor zu ermöglichen, um mit dem zweiten Speichergerät zu kommunizieren, umfasst, dass der zweite Prozessor mit dem ersten Speichergerät mittels des zweiten Schalterschaltkreises kommuniziert.
Fahrzeugdatenverarbeitungssystem nach Anspruch 3, wobei der zweite Prozessor dazu konfiguriert ist, ein Softwareaktualisierungs-Flash-Ereignis des ersten Speichergeräts während des Fahrzeugbetriebs zu ermöglichen.
Fahrzeugdatenverarbeitungssystem nach Anspruch 3, das weiterhin ein Kommunikationsmodul umfasst, das dazu konfiguriert ist, eine Fernkommunikation mit einem oder mehreren Geräten herzustellen, so dass das Kommunikationsmodul eine Softwareaktualisierung an das erste Speichergerät mittels des zweiten Prozessors überträgt.
Fahrzeugdatenverarbeitungssystem nach Anspruch 5, wobei das Kommunikationsmodul ein eingebettetes Mobiltelefon, ein Bluetooth-Modul und/oder ein eingebettetes Modem ist.
Fahrzeugdatenverarbeitungssystem nach Anspruch 5, wobei das eine oder die mehreren Geräte ein entfernter Server und/oder ein nomadisches Gerät in Kommunikation mit einem entfernten Server sind.
Fahrzeugdatenverarbeitungssystem nach Anspruch 5, wobei das Kommunikationsmodul dazu konfiguriert ist, als Reaktion auf ein Schlüssel-Aus-Ereignis damit fortzufahren, die Softwareaktualisierung zu empfangen, bis der zweite Prozessor eine Softwareaktualisierungserfolgsnachricht empfängt, bevor das Schlüssel-Aus-Ereignis abgeschlossen wird, und die Softwareaktualisierung an dem ersten Speichergerät mittels des zweiten Prozessors zu speichern.
Fahrzeugdatenverarbeitungssystem nach Anspruch 1, wobei der erste oder der zweite Prozessor weiterhin dazu konfiguriert ist, als Reaktion auf ein Initialisierungsereignis eine Anforderung zu übertragen, um zu bestimmen, ob das erste oder das zweite Speichergerät die aktualisierte Software umfasst.
Fahrzeugdatenverarbeitungssystem nach Anspruch 9, wobei das Initialisierungsereignis ein Zündschlüssel-Ein-, Zündschlüssel-Aus- und/oder ein manuell initiiertes Ereignis ist.
Fahrzeugdatenverarbeitungssystem nach Anspruch 1, wobei der erste und der zweite Schalterschaltkreis mindestens zwei Feldeffekttransistoren sind.
Schaltkreis, der Folgendes umfasst: einen ersten Prozessor, der für den Fahrzeugbetrieb konfiguriert ist; einen zweiten Prozessor, der für Softwareaktualisierungen konfiguriert ist; ein erstes und ein zweites Speichergerät, die dazu konfiguriert sind, mit dem ersten und dem zweiten Prozessor zu kommunizieren; einen ersten Schalter, der dazu konfiguriert ist, selektiv zwischen dem ersten Prozessor und dem ersten und dem zweiten Speichergerät umzuschalten; einen zweiten Schalter, der dazu konfiguriert ist, selektiv zwischen dem zweiten Prozessor und dem ersten und dem zweiten Speichergerät umzuschalten; und als Reaktion auf eine Softwareaktualisierung an dem zweiten Speichergerät mittels des zweiten Prozessors schaltet der erste Schalter, um die Kommunikation zwischen dem ersten Prozessor von dem ersten Speichergerät zu dem zweiten Speichergerät zu wechseln.
Schaltkreis nach Anspruch 12, wobei der erste und der zweite Schalter Feldeffekttransistoren (FET), Metalloxid-Halbleiter-Feldeffekttransistoren (MOSFET), Dioden, Relais und/oder Register umfassen.
Schaltkreis nach Anspruch 12, wobei das erste oder das zweite Speichergerät die Softwareaktualisierung während des Fahrzeugbetriebs mittels des zweiten Prozessors empfangen kann.
Schaltkreis nach Anspruch 14, wobei der zweite Prozessor dazu konfiguriert ist, ein Flash-Ereignis zu ermöglichen, um die Softwareaktualisierung an dem ersten und dem zweiten Speichergerät mittels des zweiten Schalters zu speichern.
Schaltkreis nach Anspruch 15, der weiterhin umfasst, dass der zweite Schalter dazu konfiguriert ist, als Reaktion auf die Softwareaktualisierung die Kommunikation mit dem zweiten Prozessor von dem zweiten Speichergerät zu dem ersten Speichergerät bei einem Initialisierungsereignis zu wechseln.
Schaltkreis nach Anspruch 12, der weiterhin ein Kommunikationsmodul umfasst, das dazu konfiguriert ist, Softwareaktualisierungen an das erste und das zweite Speichergerät mittels des zweiten Prozessors zu übertragen.
Fahrzeugsoftwareaktualisierungsverfahren, das Folgendes umfasst: Empfangen einer Softwareaktualisierung an einem ersten Speichergerät während des Fahrzeugbetriebs; Empfangen einer Benachrichtigung an einem ersten Controller, dass die Softwareaktualisierung an dem ersten Speichergerät verfügbar ist; Steuern eines Schaltkreises dahingehend, die Kommunikation zwischen dem ersten Controller mit einem zweiten Speichergerät zu dem ersten Speichergerät umzuschalten, und Ausführen der Softwareaktualisierung von dem ersten Speichergerät an dem ersten Controller.
Verfahren nach Anspruch 18, das weiterhin das Steuern des Schaltkreises, als Reaktion auf ein Initialisierungsereignis, die Kommunikation mit dem ersten Controller von dem zweiten Speichergerät zu dem ersten Speichergerät umzuschalten, umfasst, wobei das Initialisierungsereignis ein Zündschlüssel-Ein-, Zündschlüssel-Aus-Ereignis und/oder eine manuelle Benutzeranforderung ist.
Verfahren nach Anspruch 19, das weiterhin das Herstellen einer Kommunikation mittels des Schaltkreises zwischen dem zweiten Speichergerät und einem zweiten Controller als Reaktion auf das Initialisierungsereignis umfasst, wobei der zweite Controller zum Flashen von Softwareaktualisierungen zu dem zweiten Speichergerät konfiguriert ist.