-
Die Ausführungsbeispiele betreffen im Allgemeinen ein Verfahren und eine Vorrichtung für die Umprogrammierung mehrerer Fahrzeugsoftwaremodule.
-
Heutzutage weisen viele Fahrzeuge komplexe Rechensysteme als Teil ihrer allgemeinen Gestaltung auf. Angefangen bei Infotainment-Systemen bis hin zur Antriebsstrangsteuerung bilden Computersoftware und -hardware einen Bestandteil der Fahrzeuginfrastruktur.
-
Wie viele andere Computerkomponenten (Hardware und Software) können diese Systeme oftmals aus Aktualisierungen Nutzen ziehen. In vielen Fällen erfordert dies einen Flash des Speichers, der eine Überschreibung von Kernsoftware auf einem nichtflüchtigen Speicher ist, der typischerweise nicht anderweitig geändert werden kann. Da die Software oftmals kritisch ist, müssen diese Aktualisierungen ad hoc durchgeführt werden, wobei oft relativ komplizierte Prozesse (im Vergleich zu einfachen Softwareinstallationsverfahren) an der Umprogrammierung eines Speichers beteiligt sind.
-
In vielen Fällen erfordert die Umprogrammierung bestimmter Komponenten eine Fahrt zum Händler, um sicherzustellen, dass die Aktualisierung ordnungsgemäß durchgeführt wird. In anderen Fällen können dem Benutzer eine Reihe von Anweisungen und Schritten zur Verfügung gestellt werden, um die Umprogrammierung ordnungsgemäß durchzuführen. Da jedoch Softwareaktualisierungen häufig sein können, kann es für einen Benutzer recht mühselig sein, sein System vollkommen aktualisiert zu halten. Dies gilt insbesondere dann, wenn ein Fuhrpark betroffen ist.
-
Die US-Anmeldung mit Veröffentlichungsnummer 2005/0216902 betrifft im Allgemeinen ein System und ein Verfahren zur Verwaltung einer Softwarekonfigurationsaktualisierung eines Fahrzeugs. Ein erstes Softwaremodul wird identifiziert und Fahrzeugkonfigurationsdaten, die für eine erste Fahrzeugsoftwarekonfiguration stehen, werden abgerufen. An einem Callcenter wird bestimmt, ob das erste Softwaremodul mit der ersten Fahrzeugsoftwarekonfiguration kompatibel ist. Eine zweite Fahrzeugsoftwarekonfiguration wird von dem Callcenter über ein Funknetz basierend auf der Bestimmung an eine telematische Einheit gesendet. Ein computernutzbares Medium mit geeignetem Computerprogrammcode wird zur Verwaltung der Softwarekonfigurationsaktualisierung des Fahrzeugs verwendet,
-
Die US-Anmeldung mit Veröffentlichungsnummer 2013/0031540, eingereicht am 26. Juli 2011, betrifft im Allgemeinen ein computerimplementiertes Verfahren, welches des Bestimmen, dass eine Verbindung zu einem Aktualisierungsserver hergestellt werden soll, beinhaltet. Das Verfahren beinhaltet auch das Herstellen einer drahtlosen Verbindung mit dem Aktualisierungsserver. Das Verfahren beinhaltet ferner das Senden mindestens einer VIN-Nummer an den Aktualisierungsserver und das Herunterladen einer oder mehrerer Modulaktualisierungen in Übereinstimmung mit der gesendeten VIN-Nummer. Ferner beinhaltet das Verfahren das Überprüfen einer oder mehrerer heruntergeladener Aktualisierungen. Das Verfahren beinhaltet ferner das Programmieren eines oder mehrerer Module, denen die eine oder mehreren Aktualisierungen entsprechen. Außerdem beinhaltet das Verfahren das Überprüfen der Funktionalität jedes Moduls, das geflasht wurde.
-
Die US-Anmeldung mit Einreichungsnummer 13/206,615, eingereicht am 7. August 2011, betrifft im Allgemeinen ein computerimplementiertes Verfahren, welches das Empfangen eines Wiederherstellungsbefehls zum Wiederherstellen des Systemzustandes eines Fahrzeugrechensystems (VCS) beinhaltet. Das Verfahren beinhaltet ferner das Wiederherstellen eines Systembasiszustandes in einen bekannten Funktionszustand und das Erhalten einer Liste von Anwendungen, die vorher auf dem VCS installiert wurden. Das Verfahren beinhaltet auch für jede vorher auf dem VCS installierte Anwendung das Finden einer Version der Anwendung, die mit dem wiederhergestellten Systembasiszustand kompatibel ist. Ferner beinhaltet das Verfahren das Installieren der Version jeder Anwendung, die mit dem wiederhergestellten Systembasiszustand kompatibel ist.
-
In einem ersten Ausführungsbeispiel weist ein System einen Prozessor auf, der zum drahtlosen Empfangen von Aktualisierungsanforderungen von mehreren Fahrzeugen konfiguriert ist. Der Prozessor ist auch konfiguriert, für jede Anforderung zu bestimmen, ob Fahrzeugmodule aktualisiert werden müssen. Ferner ist der Prozessor auch zum Abrufen einer aktualisierten Version und Senden der aktualisierten Version an ein Fahrzeug zum Umprogrammieren für jedes Modul, das aktualisiert werden muss, konfiguriert. Der Prozessor ist außerdem zum Empfangen einer Bestätigung für jedes Modul, das umprogrammiert wurde, und Aktualisieren einer Fahrzeugkonfiguration mit einer Versionskennung konfiguriert, welcher der aktualisierten Version für jedes umprogrammierte Modul entspricht.
-
In einem anderen Ausführungsbeispiel beinhaltet ein computerimplementiertes Verfahren das drahtlose Empfangen von Aktualisierungsanforderungen von mehreren Fahrzeugen. Das beispielhafte Verfahren beinhaltet auch, für jede Anforderung, das Bestimmen, ob Fahrzeugmodule aktualisiert werden müssen. Das Verfahren beinhaltet außerdem das Abrufen einer aktualisierten Version und Senden der aktualisierten Version an ein Fahrzeug zum Umprogrammieren für jedes Modul, das aktualisiert werden muss. Das Verfahren beinhaltet ferner das Empfangen einer Bestätigung für jedes Modul, das umprogrammiert wurde, und Aktualisieren einer Fahrzeugkonfiguration mit einer Versionskennung, welcher der aktualisierten Version für jedes umprogrammierte Modul entspricht.
-
In einem dritten Ausführungsbeispiel speichert ein nichtflüchtiges computerlesbares Speichermedium Anweisungen, die, wenn sie von einem Prozessor ausgeführt werden, bewirken, dass der Prozessor ein Verfahren ausführt, welches das drahtlose Empfangen von Aktualisierungsanforderungen von mehreren Fahrzeugen beinhaltet. Das beispielhafte Verfahren beinhaltet auch für jede Anforderung, das Bestimmen, ob Fahrzeugmodule aktualisiert werden müssen. Das Verfahren beinhaltet außerdem das Abrufen einer aktualisierten Version und Senden der aktualisierten Version an ein Fahrzeug zum Umprogrammieren, für jedes Modul, das aktualisiert werden muss. Das Verfahren beinhaltet ferner das Empfangen einer Bestätigung für jedes Modul, das umprogrammiert wurde, und Aktualisieren einer Fahrzeugkonfiguration mit einer Versionskennung, welcher der aktualisierten Version für jedes umprogrammierte Modul entspricht.
-
Es zeigen: 1 ein beispielhaftes Fahrzeugrechensystem;
-
2 einen beispielhaften Prozess zum Aktualisieren mehrere Module eines einzigen Fahrzeugs; und
-
3 einen beispielhaften Prozess zum gleichzeitigen Aktualisieren mehrere Module.
-
Ausführliche Ausführungsformen der vorliegenden Offenbarung sind hierin vorschriftsmäßig offenbart; jedoch muss man verstehen, dass die offenbarten Ausführungsformen die Erfindung rein beispielhaft darstellen und in verschiedenen und alternativen Formen ausgeführt werden können. Die Figuren sind nicht unbedingt maßstabsgetreu, wobei einige Merkmale übertrieben oder minimiert dargestellt sein können, um Details bestimmter Komponenten aufzuzeigen. Daher sind spezifische hierin offenbarte strukturelle und funktionelle Details nicht als einschränkend auszulegen, sondern nur als repräsentative Grundlage, um einen Fachmann verschiedene Anwendungen der vorliegenden Erfindung zu lehren.
-
1 stellt eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Rechensystem 1 (VCS) für ein Fahrzeug 31 dar. Ein Beispiel eines solchen fahrzeugbasierten Rechensystems 1 ist das SYNC-System, das von der THE FORD MOTOR COMPANY hergestellt wird. Ein Fahrzeug, das mit einem fahrzeugbasierten Rechensystem bereitgestellt ist, kann eine visuelle Frontend-Oberfläche 4 enthalten, die sich in dem Fahrzeug befindet. Der Benutzer kann auch mit der Oberfläche interagieren, wenn diese zum Beispiel mit einem berührungsempfindlichen Bildschirm versehen ist. In einem anderen Ausführungsbeispiel erfolgt die Interaktion durch Drücken von Tasten, hörbare Sprache und Sprachsynthese.
-
In Ausführungsbeispiel 1, das in 1 dargestellt ist, steuert ein Prozessor 3 mindestens einen Teil des Betriebs des fahrzeugbasierten Rechensystems. Der in dem Fahrzeug bereitgestellte Prozessor ermöglicht die bordseitige Verarbeitung von Befehlen und Routinen. Ferner ist der Prozessor sowohl mit einem nichtflüchtigen 5 als auch einem flüchtigen Speicher 7 verbunden. In diesem Ausführungsbeispiel ist der nichtflüchtige Speicher ein wahlfreier Zugriffspeicher (RAM) und der flüchtige Speicher ein Festplattenlaufwerk (HDD) oder ein Flash-Speicher.
-
Der Prozessor ist auch mit einer Anzahl unterschiedlicher Eingabeelemente bereitgestellt, mit denen sich der Benutzer mit dem Prozessor verbinden kann. In diesem Ausführungsbeispiel sind ein Mikrofon 29, ein Hilfseingang 25 (für den Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24 und ein BLUETOOTH-Eingang 15 bereitgestellt. Ein Eingabewahlschalter 51 ist ebenfalls bereitgestellt, damit ein Benutzer zwischen verschiedenen Eingabeelementen wechseln kann. Die Eingabe sowohl in das Mikrofon als auch den Hilfsstecker wird von einem Wandler 27 von analog in digital umgewandelt, bevor sie an den Prozessor geleitet wird. Wenngleich nicht dargestellt, können zahlreiche der Fahrzeugkomponenten und Hilfskomponenten, die mit dem VCS verbunden sind, ein Fahrzeugnetzwerk (wie beispielsweise, jedoch ohne Beschränkung auf einen CAN-Bus) verwenden, um Daten an das und von dem VCS (oder Komponenten davon) zu leiten.
-
Ausgabeelemente des Systems können eine visuelle Anzeige 4 und einen Lautsprecher 13 oder eine Stereosystemausgabe einschließen, sind jedoch nicht darauf beschränkt. Der Lautsprecher ist mit einem Verstärker 1 verbunden und empfängt sein Signal von dem Prozessor 3 durch einen Digital-Analog-Wandler 9. Die Ausgabe kann auch an eine rechnerferne BLUETOOH-Vorrichtung wie PND 54 oder eine USB-Vorrichtung wie eine Fahrzeugnavigationsvorrichtung 60 entlang der bidirektionalen Datenströme erfolgen, die bei 19 bzw. 21 dargestellt sind.
-
In einem Ausführungsbeispiel verwendet das System 1 einen BLUETOOTH-Sendeempfänger 15, um mit einem Mobilgerät 53 eines Benutzers (z. B. einem Mobiltelefon, Smartphone, PDA oder anderen Vorrichtung mit einer drahtlosen rechnerfernen Netzwerkkonnektivität) zu kommunizieren 17. Das Mobilgerät kann dann verwendet werden, um mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zum Beispiel durch die Verbindung 55 mit einem Mobilfunkturm 57 zu kommunizieren 59. In einigen Ausführungsformen kann der Turm ein WLAN-Zugriffspunkt sein.
-
Eine beispielhafte Verbindung zwischen dem Mobilgerät und dem BLUETOOTH-Sendeempfänger ist durch das Signal 14 dargestellt.
-
Die Kopplung eines Mobilgeräts 53 und des BLUETOOTH-Sendeempfängers kann durch eine Taste 52 oder ein ähnliches Eingabeelement befohlen werden. Dementsprechend wird der CPU befohlen, dass der bordseitige BLUETOOTH-Sendeempfänger mit einem BLUETOOTH-Sendeempfänger in einem Mobilgerät gekoppelt wird.
-
Die Daten können zwischen der CPU 3 und dem Netzwerk 61 unter Verwendung beispielweise eines Datenplans, Date Over Voice oder DTMF-Töne, die mit einem Mobilgerät 53 assoziiert sind, mitgeteilt werden. Als Alternative kann es wünschenswert sein, ein bordseitiges Modem 63 mit Antenne 18 aufzunehmen, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu übertragen 16. Das Mobilgerät 53 kann dann zum Kommunizieren 59 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 durch zum Beispiel die Verbindung 55 mit einem Mobilfunkturm 57 verwendet werden. In einigen Ausführungsformen kann das Modem 63 eine Verbindung 20 mit dem Turm 57 herstellen, um mit dem Netzwerk 61 zu kommunizieren. Als nicht einschränkendes Beispiel kann das Modem 63 ein USB-Mobilfunkmodem sein und die Verbindung 20 kann eine Mobilfunkverbindung sein.
-
In einem Ausführungsbeispiel ist der Prozessor mit einem Betriebssystem bereitgestellt, das eine API aufweist, um mit der Modemanwendungssoftware zu kommunizieren. Die Modemanwendungssoftware kann auf ein eingebettetes Modul oder Firmware an dem BLUETOOTH-Sendeempfänger zugreifen, um eine drahtlose Verbindung mit einem rechnerfernen BLUETOOTH-Sendeempfänger (wie dem in einem Mobilgerät) herzustellen. Bluetooth ist Teil der Protokolle IEEE 802 PAN (Personal Area Network). Die IEEE 802 LAN (Local Area Network)-Protokolle schließen WiFi ein und haben eine bedeutende übergreifende Funktionalität mit IEEE 802 PAN. Beide sind für die drahtlose Kommunikation in einem Fahrzeug geeignet. Ein anderes Kommunikationsmittel, das in diesem Kontext verwendet werden kann, ist die optische Freiraumkommunikation (wie IrDA) und nicht genormte Verbraucher-IR-Protokolle.
-
In einer anderen Ausführungsform weist das Mobilgerät 53 ein Modem für die Sprachbrand- oder Breitbanddatenkommunikation auf. In der Ausführungsform mit Data-Over-Voice kann eine als Frequenzmultiplexverfahren bekannte Technik implementiert werden, wenn der Eigentümer des Mobilgeräts über das Gerät sprechen kann, während Daten übertragen werden. Zu anderen Zeitpunkten, wenn der Eigentümer das Gerät nicht benutzt, kann bei der Datenübertragung die gesamte Bandbreite (300 Hz bis 3,4 kHz in einem Beispiel) verwendet werden. Wenngleich das Frequenzmultiplexverfahren für die analoge Mobilkommunikation zwischen dem Fahrzeug und dem Internet üblich sein mag und noch immer angewendet wird, wurde es größtenteils durch Hybridformen mit Code Domain Multiple Access (CDMA), Time Domain Multiple Access (TDMA), Space-Domain Multiple Access (SDMA) für die digitale Mobilkommunikation ersetzt. Hierbei handelt es sich um Normen, die mit ITU IMT-2000 (3G) konform sind und Datenraten von bis zu 2 mbs für ortsfeste oder gehende Benutzer und 385 kbs für Benutzer in einem sich bewegenden Fahrzeug bieten. 3G-Standards werden derzeit durch IMT-Advanced (4G) ersetzt, die 100 mbs für Benutzer in einem Fahrzeug und 1 gbs für ortsfeste Benutzer bieten. Wenn der Benutzer einen Datenplan hat, der mit dem Mobilgerät assoziiert ist, kann der Datenplan eine Breitbandübertragung ermöglichen und das System könnte eine viel breitere Bandbreite nutzen (und somit die Datenübertragung beschleunigen). In noch einer anderen Ausführungsform ist das Mobilgerät 53 durch eine Mobilkommunikationsvorrichtung (nicht dargestellt) ersetzt, die in dem Fahrzeug 31 installiert ist. In noch einer anderen Ausführungsform kann das ND 53 ein Gerät mit Wireless Local Area Netzwork (WLAN) sein, das zum Beispiel (und ohne Einschränkung) über ein 802.11g-Netzwerk (d. h. WiFi) oder ein WiMax-Netzwerk kommunizieren kann.
-
In einer Ausführungsform können ankommende Daten durch das Mobilgerät über Data-Over-Voice oder einen Datenplan durch den bordseitigen BLUETOOTH-Sendeempfänger und in den internen Prozessor 3 des Fahrzeugs geleitet werden. Im Falle bestimmter temporärer Daten können die Daten beispielsweise auf dem HDD oder einem anderen Speichermedium 7 gespeichert werden, bis die Daten nicht mehr benötigt werden.
-
Zusätzliche Quellen, die mit dem Fahrzeug sein können, schließen eine persönliche Navigationsvorrichtung 54 ein, die zum Beispiel einen USB-Anschluss 56 und/oder eine Antenne 58 aufweist, eine Fahrzeugnavigationsvorrichtung 60, die eine USB 62 oder anderen Anschluss aufweist, eine bordseitige GPS-Vorrichtung 24 oder ein rechnerfernes Navigationssystem (nicht dargestellt) mit Konnektivität zu dem Netzwerk 61 ein. USB ist ein Typ eines seriellen Netzwerkprotokolls. Die seriellen Protokolle laut IEEE 1394 (Firewire), EIA (Electronics Industry Association), IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Grundgerüst der seriellen Standards von Gerät zu Gerät. Die meisten Protokolle können entweder für die elektrische oder die optische Kommunikation implementiert sein.
-
Ferner kann die CPU mit verschiedenen anderen Hilfsvorrichtungen 65 verbunden sein. Diese Vorrichtungen können durch eine drahtlose 67 oder eine verdrahtete 69 Verbindung verbunden sein. Die Hilfsvorrichtung 65 kann persönliche Mediaplayer, drahtlose Gesundheitsvorrichtungen, tragbare Computer und dergleichen einschließen, ohne jedoch darauf beschränkt zu sein.
-
Außerdem oder alternativ könnte die CPU mit einem fahrzeugbasierten drahtlosen Router 73 verbunden sein, der zum Beispiel einen Sendeempfänger für WiFi 71 verwendet. Dadurch könnte die CPU mit rechnerfernen Netzwerken innerhalb der Reichweite des lokalen Routers 73 verbunden werden.
-
Neben beispielhaften Prozessen, die von einem Fahrzeugrechensystem ausgeführt werden, das sich in einem Fahrzeug befindet, können die beispielhaften Prozesse von einem Rechensystem ausgeführt werden, das mit einem Fahrzeugrechensystem verbunden ist. Ein solches System kann eine drahtlose Vorrichtung (z. B. und ohne Einschränkung ein Mobiltelefon) oder ein rechnerfernes Rechensystem (z. B. und ohne Einschränkung einen Server), der durch die drahtlose Vorrichtung verbunden ist, einschließen, ist jedoch nicht darauf beschränkt. Kollektiv können solche Systeme als fahrzeugassoziierte Rechensysteme (VACS) bezeichnet werden. In bestimmten Ausführungsformen können bestimmte Komponenten des VACS in Abhängigkeit der jeweiligen Implementierung des Systems bestimmte Teile eines Prozesses ausführen. Wenn ein Prozess zum Beispiel und ohne Einschränkung einen Schritt des Sendens oder Empfangens von Informationen mit einer gekoppelten drahtlosen Vorrichtung aufweist, dann führt die drahtlose Vorrichtung den Prozess wahrscheinlich nicht aus, da die drahtlose Vorrichtung selbst keine Informationen „sendet und empfängt“. Der Durchschnittsfachmann wird verstehen, wann die Anwendung eines bestimmten VACS für eine bestimmte Lösung unangemessen ist. In allen Lösungen wird in Betracht gezogen, dass mindestens das Fahrzeugrechensystem (VCS), das sich in dem Fahrzeug selbst befindet, die beispielhaften Prozesse ausführen kann.
-
Die US-Anmeldung mit Veröffentlichungsnr. 2013/0031540, eingereicht am 26. Juli 2001, und die US-Anmeldung mit Veröffentlichungsnr. 2013/0042231, eingereicht am 7. August 2011, sind gemeinsam besessene Anmeldungen, deren Inhalte hiermit durch Bezugnahme aufgenommen werden.
-
Die Software von Fahrzeugmodulen wie PCM oder TCM muss oft aktualisiert oder überarbeitet werden. Fahrzeugprüfprogramme und Maßnahmen seitens des Händlers oder Außendienstmitarbeiters sind sehr zeitaufwendig und führen zu Mehrkosten, wenn mehrere Fahrzeuge oder Entwicklungsplattformen manuell umprogrammiert werden. Derzeit muss jedes Prüffahrzeug/jede Plattform oft lokalisiert, manuell im Hinblick auf den Softwarestand und die Hardwareteilenummer inventarisiert und mittels eines Service- oder Diagnosewerkzeugs manuell umprogrammiert werden.
-
Die Ausführungsbeispiele stellen Prozesse dar, die für eine Flotte von Fahrzeugen, die sich im Hinblick auf ihre Modulhardware und/oder Softwarekonfigurationen individuell unterscheiden können, gleichzeitig ausgeführt werden können. Ein beliebiges individuelles Umprogrammierungsereignis kann je nachdem, welche Fahrzeuge mit dem Server verbunden sind, gleichzeitig mit dem Rest der Flotte stattfinden.
-
Ein sicherer OEM-Server speichert Software für die Erzeugung der Fahrzeugmodulprogrammierung/-umprogrammierung und kann auch in einer Version bereitgestellt sein, die nur Fahrzeugsmodulentwicklungssoftware hostet.
-
Die hierin beschriebenen Ausführungsbeispiele ermöglichen die Umprogrammierung mehrerer Flottenfahrzeuge mit mehreren Modulen an jedem Flottenfahrzeug. Sie stellen eine automatische Dokumentation ganzer Flash-Ereignisse für ein Fahrzeug und das sofortige Hochladen auf die Fahrzeugkonfigurationsdatenbank bereit. Ferner ermöglichen sie die automatische Erkennung von Fahrzeughardwarekonfigurationen, die Übermittelung dieser Konfiguration an einen sicheren Server und die Anordnung der Verpackung und sicheren Übertragung an ein Fahrzeug, sodass sichergestellt werden kann, dass jedes Fahrzeug gemäß seiner spezifischen Konfiguration geflasht wird. Da das Fahrzeug zur Verwirklichung der Ausführungsformen die Kommunikation mit dem rechnerfernen Server initiiert, wird zusätzliche Sicherheit bereitgestellt, da Fahrzeuge nicht angezapft werden können, um ihre individuellen IP-Adressen herauszufinden (was sie gegenüber Hackern angreifbar macht).
-
2 stellt einen beispielhaften Prozess zum Aktualisieren mehrerer Module eines einzigen Fahrzeugs dar. In einem Flottenbeispiel kann eine Anzahl von Fahrzeugen gleichzeitig mit einem bestimmten Server verbunden werden und gleichzeitige Aktualisierungen anfordern. In den Ausführungsbeispielen kontaktieren die Fahrzeuge den Server für Aktualisierungszwecke. Immer wenn also ein Fahrzeug verbunden wird, können die Modulinformationen dem Server bereitgestellt werden, und der Server kann diese Informationen mit vorhandenen Informationen (im Hinblick auf ihre Einheitlichkeit) vergleichen und Module für das Fahrzeug aktualisieren, das die spezifische Konfiguration aufweist, die mit diesem Fahrzeug in Beziehung steht.
-
In diesem Ausführungsbeispiel empfängt der Server eine Verbindungsanforderung von einem Fahrzeug 201. Verschiedene Validierungsprozesse können implementiert werden, um zu gewährleisten, dass die Anforderung durchführbar ist, wobei der Server nach Vollendung dieser (falls gewünscht) Fahrzeugdaten 203 erfassen kann. Fahrzeugdaten können einschließen, sind jedoch nicht beschränkt auf Modulsoftwareversionen, verschiedene Komponenteninstallationen usw. Diese können Kennungen für Sekundärmarktkomponenten sowie eine Bestätigung aufweisen, dass verschiedene OEM-installierte Komponenten noch immer installiert sind.
-
Wenngleich der rechnerferne Server über die Konfiguration eines bestimmten Fahrzeugs Buch führen kann, kann es dennoch nützlich sein, diese Konfiguration zu überprüfen, bevor eine Modulaktualisierung vorgenommen wird. Nachdem eine Softwareversion empfangen (und gegebenenfalls mit gespeicherten Daten abgeglichen) wurde, kann die Modulversion mit einer Datenbank verglichen werden, die das bzw. die aktuellsten Modul(e) für ein Fahrzeug einer bestimmten Konfiguration 205 enthält.
-
Wenn das Modul aktuell 207 ist und keine weiteren Module verbleiben 209, kann der Prozess beendet werden. Wenn weitere Module zur Aktualisierung bei einem bestimmten Fahrzeug verbleiben, kann sich der Prozess zu einem nächsten Modul 213 bewegen und die Überprüfung wiederholen und den Prozess für alle verbleibenden Module wiederholen.
-
Wenn ein bestimmtes Softwaremodul nicht aktuell ist, kann der Prozess Aktualisierungsdaten an das Fahrzeug 211 senden und einen rechnerfernen Umprogrammierungsprozess beginnen. Ein Beispiel dieses Prozesses ist in dem hierin aufgenommenen Verweis 2013/0031540 beschrieben. Für jedes Modul, das aktualisiert werden muss, kann dieser Prozess wiederholt werden, um das Fahrzeug nach der Verbindung (beispielsweise innerhalb der zeitlichen Beschränkungen) vollständig zu aktualisieren.
-
Da ein rechnerferner Server eine Anzahl dieser Anforderungen handhaben kann, können Fuhrparkbetreiber sowie Verbraucher im Allgemeinen sicher sein, dass ihre Software angemessen aktualisiert ist, immer wenn eine Verbindung zu dem rechnerfernen Server hergestellt wird. Dies kann zur Vermeidung von Schwierigkeiten dabei beitragen, ob eine neue Softwareversion installiert wurde oder nicht.
-
3 stellt ein beispielhaftes Verfahren zum gleichzeitigen Aktualisieren mehrere Module dar. Dieses erläuternde Beispiel ist dem aus 2 ähnlich, ermöglicht jedoch eine schnellere Aktualisierung, da unterschiedliche Module an unterschiedlichen Bussen gleichzeitig aktualisiert werden können.
-
In diesem erläuternden Beispiel (das von der Fahrzeugseite dargestellt ist), sammelt der Prozess Daten in Bezug auf installierte Komponenten und Softwaremodulversionen 301. Wenn danach ausreichend Daten vorhanden sind und wenn eine Verbindung vorhanden ist, verbindet sich der Prozess mit einem rechnerfernen Server 303, sodass die fahrzeugbezogenen Daten gesendet 305 werden können.
-
Nachdem der rechnerferne Server alle einschlägigen Fahrzeugdaten empfangen hat, kann ein Prozess wie der in 2 dargestellte eintreten. In diesem Fall sammelt und sendet der Prozess die Aktualisierungen (und sendet und verarbeitet sie eben nicht alle gleichzeitig), sodass ein Fahrzeug mit mehreren Modulen an mehreren Bussen diese Module gleichzeitig umprogrammieren kann.
-
Die kompilierten Aktualisierungsdaten werden von dem Fahrzeug 307 empfangen und das Fahrzeug bestimmt, ob mehrere Aktualisierungen benötigt werden oder ob nur ein einziges Modul umprogrammiert 309 werden muss. Falls nur ein einziges Modul geflasht werden muss, flasht der Prozess die einzige Aktualisierung 311. Das umprogrammierte Modul empfängt dann einen Rücksetzungsbefehl 337, um den Neuprogrammierungszustand zu verlassen. Erfolglose Flash-Vorgänge werden ebenfalls in ihren ursprünglichen Zustand 339 wiederhergestellt, um den Betrieb von Fahrzeugsystemen nicht zu behindern. Danach aktualisiert der Prozess den rechnerfernen Server im Hinblick auf die Erfolge und Misserfolge 341.
-
Wenn mehrere Aktualisierungen vorhanden sind, prüft der Prozess, ob Module an mehreren Bussen vorhanden sind, von denen jedes aktualisiert 317 werden muss. Falls nicht, dann flasht der Prozess eine einzige Aktualisierung für das Modul an einem ersten Bus 321, wonach der Prozess unter der Annahme, dass noch Module 343 verbleiben, zu einer nächsten Aktualisierung 345 geht und den Vorgang wiederholt.
-
Falls mehrere Module an mehreren Bussen vorhanden sind, flasht der Prozess diese Module gleichzeitig 335. Wenn nach Vollendung noch Aktualisierungen 315 verbleiben, wird der Prozess mit der bzw. den nächsten Aktualisierung(en) 313 fortgesetzt. Auf diese Weise wird ein bestimmtes Fahrzeug effizient umprogrammiert, wobei die meisten oder alle Module auf neue Versionen aktualisiert werden. Wenn fehlgeschlagene Versionen berichtet werden, kann der Prozess versuchen, diese Version erneut zu aktualisieren, oder abwarten und dies zu einem späteren Zeitpunkt versuchen.
-
Wenngleich vorstehend Ausführungsbeispiele beschrieben wurden, sollen diese Ausführungsformen nicht alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die Begriffe, die in der Spezifikation verwendet werden, beschreibende und nicht einschränkende Begriffe, wobei es sich versteht, dass verschiedene Änderungen vorgenommen werden können, ohne von dem Geist und Schutzbereich der Erfindung abzuweichen. Außerdem können die Merkmale verschiedener implementierender Ausfü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 [0023]
- IEEE 802 LAN [0023]
- IEEE 802 PAN [0023]
- IEEE 1394 [0026]
- IEEE 1284 [0026]
