DE102017100750A1

DE102017100750A1 - Verfahren und vorrichtung für over-the-air-updates

Info

Publication number: DE102017100750A1
Application number: DE102017100750.4A
Authority: DE
Inventors: Sangeetha Sangameswaran; John Naum Vangelov; Daniel Joseph Madrid; Chad Evert Esselink
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2016-02-19
Filing date: 2017-01-16
Publication date: 2017-08-24
Also published as: US11782691B2; US20170242679A1; CN107102869A

Abstract

Ein System umfasst einen Prozessor, der konfiguriert ist, als Reaktion auf eine von einem entfernten Netzwerk empfangene Benachrichtigung, dass ein Update der Fahrzeugsoftware verfügbar ist, eine Liste der installierten Fahrzeugsoftware-Versionen zusammenzustellen. Der Prozessor ist außerdem konfiguriert, die Liste der installierten Versionen zu einem entfernten Update-Server zu übertragen. Der Prozessor ist ferner konfiguriert, eine Liste verfügbarer Updates, die mit den installierten Fahrzeugsoftware-Versionen kompatibel sind, als Reaktion auf die Übertragung zu empfangen. Außerdem der Prozessor ist konfiguriert, mindestens eines der verfügbaren Updates herunterzuladen und die heruntergeladenen Updates zu installieren.

Description

TECHNISCHES GEBIET
Die veranschaulichenden Ausführungsformen betreffen im Allgemeinen ein Verfahren und eine Vorrichtung für Over-the-Air-Updates.
BACKGROUND
Viele Fahrzeuge enthalten Telematikeinheiten und Fahrzeugcomputer- und Infotainmentsysteme. Diese Systeme ermöglichen die Integration von Anwendungen aus entfernten Quellen, die Wiedergabe von Medien und Inhalten in einem Fahrzeug, die Kommunikation mit entfernten Quellen und liefern im Allgemeinen ein positiveres Fahrererlebnis. Diese Systeme und andere elektronische Steuereinheiten (ECU) von Fahrzeugen können updatebare Software/Firmware-Komponenten umfassen, um zum Beispiel eine Kompatibilität zwischen Komponenten bereitzustellen. Jedoch kann es erforderlich sein, dass Kunden einen Händler aufsuchen, um Updates zu erhalten und/oder die Systeme untersuchen zu lassen, um festzustellen, ob aktualisierte Software verfügbar ist. Gegenwärtige Strategien können das physikalische Verbinden des Fahrzeugs mit einem Programmierungssystem erfordern, um die Updates durch den Händler installieren zu lassen. Dies ermöglicht es dem Händler sicherzustellen, dass die jüngsten Module und Versionen installiert sind, und ermöglicht es dem Erstausrüster (OEM), eine Momentaufnahme der gegenwärtigen Software- und Firmware-Versionen zu erhalten, die an einem Fahrzeug installiert sind.
ZUSAMMENFASSUNG
In einer ersten veranschaulichenden Ausführungsform umfasst ein System einen Prozessor, der konfiguriert ist, als Reaktion auf eine von einem entfernten Netzwerk empfangene Benachrichtigung, dass ein Update der Fahrzeugsoftware verfügbar ist, eine Liste der installierten Fahrzeugsoftware-Versionen zusammenzustellen. Der Prozessor ist außerdem konfiguriert, die Liste der installierten Versionen zu einem entfernten Update-Server zu übertragen. Der Prozessor ist ferner konfiguriert, eine Liste verfügbarer Updates, die mit den installierten Fahrzeugsoftware-Versionen kompatibel sind, als Reaktion auf die Übertragung zu empfangen. Außerdem ist der Prozessor konfiguriert, mindestens eines der verfügbaren Updates herunterzuladen und die heruntergeladenen Updates zu installieren.
In einer zweiten veranschaulichenden Ausführungsform umfasst ein System einen Prozessor, der konfiguriert ist, eine Liste von Fahrzeug-Identifizierungsnummern (FIN)s zu empfangen, auf die ein verfügbares Softwareupdate zutrifft. Der Prozessor ist außerdem konfiguriert, für jede FIN festzustellen, ob ein Fahrzeughalter Over-the-Air-(OTA)-Updates zugestimmt hat, und eine Benachrichtigung an jedes Fahrzeug zu senden, das durch eine entsprechende FIN identifiziert wird, für das der Halter OTA-Updates zugestimmt hat und ein verfügbares Softwareupdate zutrifft.
In einer dritten veranschaulichenden Ausführungsform umfasst ein System einen oder mehrere Prozessoren, die konfiguriert sind, ein Softwareupdate zu empfangen. Der (die) Prozessor(en) sind außerdem konfiguriert, eine Benachrichtigung an ein Fahrzeug zu liefern, für das ein Datenbankeintrag eine installierte Softwareversion anzeigt, für die das empfangene Update zutrifft, und eine Softwareupdate-Downloadanforderung vom Fahrzeug zu empfangen. Ferner sind der (die) Prozessor(en) konfiguriert, das Softwareupdate als Reaktion auf die Anforderung zu übertragen, ein Update-Protokoll zu empfangen, das den Erfolg oder den Fehlschlag der Installation des Softwareupdates enthält, und den Datenbankeintrag beruhend auf dem Protokoll zu aktualisieren.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 zeigt ein veranschaulichendes Fahrzeugcomputersystem;
2A zeigt einen veranschaulichenden cloudseitigen Prozess zum Bereitstellen eines Fahrzeugsoftware/Firmware-Updates;
2B zeigt einen veranschaulichenden fahrzeugseitigen Prozess zur Update-Behandlung;
3 zeigt einen veranschaulichenden Prozess zur Update-Benachrichtigung;
4 zeigt einen anderen veranschaulichenden Update-Benachrichtigungsprozess; und
5 zeigt einen veranschaulichenden Prozess zur Rückrufbehandlung.
DETAILLIERTE BESCHREIBUNG
Falls erforderlich werden hierin detaillierte Ausführungsformen offenbart; jedoch versteht es sich, dass die offenbarten Ausführungsformen für den beanspruchten Gegenstand lediglich veranschaulichend sind, der in verschiedenen und alternativen Formen ausgeführt werden kann. Die Figuren sind nicht notwendigerweise maßstabsgerecht; einige Merkmale können übertrieben oder minimiert sein, um Einzelheiten von bestimmen Komponenten zu zeigen. Daher sind spezifische hierin offenbarte strukturelle und funktionelle Einzelheiten nicht als einschränkend zu interpretieren, sondern lediglich als eine repräsentative Grundlage, um einen Fachmann zu lehren, den beanspruchten Gegenstand verschiedenartig einzusetzen.
1 stellt eine Beispielblocktopologie für ein fahrzeugbasiertes Computersystem 1 (VCS) für ein Fahrzeug 31 dar. Ein Beispiel eines solchen fahrzeugbasierten Computersystems 1 ist das durch THE FORD MOTOR COMPANY hergestellte SYNC-System. Ein mit einem fahrzeugbasierten Computersystem befähigtes Fahrzeug kann eine visuelle Vorschaltschnittstelle 4 enthalten, die sich im Fahrzeug befindet. Der Benutzer kann imstande sein, mit der Schnittstelle, falls sie vorgesehen ist, zum Beispiel mit einem berührungsempfindlichen Bildschirm zu kommunizieren. In einer anderen veranschaulichenden Ausführungsform findet die Interaktion durch Knopfdrücke und/oder einem Sprachdialogsystem mit automatischer Spracherkennung und Sprachsynthese statt.
In der in 1 gezeigten veranschaulichenden Ausführungsform 1 steuert ein Prozessor 3 mindestens einen Anteil der Operation des fahrzeugbasierten Computersystems. Da er im Fahrzeug vorgesehen ist, ermöglicht der Prozessor eine bordseitige Verarbeitung von Befehlen und Routinen. Ferner ist der Prozessor sowohl mit einem nicht dauerhaften 5 und dauerhaften Speicher 7 verbunden. In dieser veranschaulichenden Ausführungsform ist der nicht dauerhafte Speicher ein Direktzugriffsspeicher (RAM) und der dauerhafte Speicher ist ein Festplattenlaufwerk (HDD) oder ein Flash-Speicher. Im Allgemeinen kann ein dauerhafter (nicht flüchtiger) Speicher alle Speicherformen umfassen, die Daten bewahren, wenn ein Computer oder eine andere Vorrichtung abgeschaltet ist. Diese umfassen, sind jedoch nicht beschränkt auf, HDDs, CDs, DVDs, Magnetbänder, Solid-State-Drives, tragbare USB-Laufwerke und jede andere geeignete Form eines dauerhaften Speichers.
Der Prozessor ist außerdem mit einer Anzahl unterschiedlicher Eingänge versehen, die es dem Benutzer ermöglichen, sich mit dem Prozessor zu verbinden. In dieser veranschaulichenden Ausführungsform sind insgesamt ein Mikrofon 29, ein Zusatzeingang 25 (für den Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24, ein Bildschirm 4, der eine Berührungsbildschirmanzeige sein kann, und ein BLUETOOTH-Eingang 15 vorgesehen. Es ist außerdem ein Eingangswahlschalter 51 vorgesehen, um es einem Benutzer zu ermöglichen, zwischen verschiedenen Eingängen zu wechseln. Eine Eingabe sowohl in das Mikrofon als auch den Zusatzanschluss wird durch einen Wandler 27 von analog in digital umgewandelt, bevor sie zum Prozessor geschickt wird. Obwohl nicht gezeigt, können zahlreiche der Fahrzeugkomponenten und Zusatzkomponenten, die mit dem VCS in Verbindung stehen, ein Fahrzeugnetzwerk verwenden (wie z.B., jedoch nicht beschränkt auf, einen CAN-Bus), um Daten zum und vom VCS (oder deren Komponenten) zu schicken.
Die Ausgänge zum System können umfassen, sind jedoch nicht beschränkt auf, eine Sichtanzeige 4 und einen Lautsprecher 13 oder Stereoanlagenausgang. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal vom Prozessor 3 durch einen Digital-Analog-Wandler 9. Eine Ausgabe kann auch zu einer entfernten BLUETOOTH-Vorrichtung wie einer persönlichen Navigationsvorrichtung 54 oder einer USB-Vorrichtung wie einer Fahrzeugnavigationsvorrichtung 60 längs der bidirektionalen Datenströme erfolgen, die bei 19 bzw. 21 gezeigt werden.
In einer veranschaulichenden Ausführungsform verwendet das System 1 den BLUETOOTH-Transceiver 15, um mit einer nomadischen Vorrichtung 53 eines Benutzers (z.B. z.B. einem Mobiltelefon, einem Smartphone, einem PDA, einem Tablet oder irgendeiner anderen Vorrichtung, die eine drahtlose Konnektivität zu einem entfernten Netzwerk aufweist) zu kommunizieren 17. Die nomadische Vorrichtung kann dann dazu verwendet werden, um mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 durch zum Beispiel eine Kommunikation 55 mit einem Mobilfunkmast 57 zu kommunizieren 59. In einigen Ausführungsformen kann der Mast 57 ein WiFi-Zugangspunkt sein.
Eine repräsentative Kommunikation zwischen der nomadischen Vorrichtung und dem BLUETOOTH-Transceiver wird durch das Signal 14 dargestellt. Die Kopplung einer nomadischen Vorrichtung 53 und des BLUETOOTH-Transceivers 15 kann durch einen Knopf 52 oder eine ähnliche Eingabe befohlen werden. Folglich wird der CPU befohlen, dass der bordseitige BLUETOOTH-Transceiver mit einem BLUETOOTH-Transceiver in einer nomadischen Vorrichtung gekoppelt wird.
Daten können zwischen der CPU 3 und dem Netzwerk 61 mittels zum Beispiel eines Datentarifs, Data-over-Voice oder DTMF-Tönen übertragen werden, die mit der nomadischen Vorrichtung 53 verknüpft sind. Alternativ dazu kann es wünschenswert sein, ein bordseitiges Modem 63 mit einer Antenne 18 zu integrieren, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu übertragen 16. Die nomadische Vorrichtung 53 kann dann dazu verwendet werden, um mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 durch zum Beispiel 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 Netzwerk 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 umfasst, um mit einer 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 einer nomadischen Vorrichtung vorgefundenen) durchzuführen. Bluetooth ist eine Teilmenge der IEEE-802-PAN-Protokolle (PAN = persönliches Netz). IEEE-802-LAN-Protokolle (LAN = lokales Netz) umfassen WiFi und haben eine beträchtliche Kreuzfunktionalität mit IEEE 802 PAN. Beide sind für eine drahtlose Kommunikation innerhalb eines Fahrzeugs geeignet. Es können auch eine optische Freiraumkommunikation (wie IrDA) und nicht standardisierte Kunden-IR-Protokolle verwendet werden.
In einer anderen Ausführungsform umfasst die nomadische Vorrichtung 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 der nomadischen Vorrichtung über die Vorrichtung sprechen kann, während Daten übertragen werden. Zu anderen Zeiten, wenn der Besitzer die Vorrichtung nicht verwendet, kann die Datenübertragung die gesamte Bandbreite (in einem Beispiel 300 Hz bis 3,4 kHz) verwenden. Während Frequenzmultiplexen für analoge Mobilfunkkommunikation zwischen dem Fahrzeug und dem Internet üblich sein mag und immer noch verwendet wird, ist es weitgehend durch Hybride von Codevielfachzugriff (CDMA), Zeitvielfachzugriff (TDMA), Raumvielfachzugriff (SDMA) für digitale Mobilfunkkommunikation ersetzt worden. In noch einer anderen Ausführungsform wird die nomadische Vorrichtung 53 durch eine (nicht gezeigte) Mobilfunkkommunikationsvorrichtung ersetzt, die am Fahrzeug 31 installiert ist. In noch einer anderen Ausführungsform kann die nomadische Vorrichtung 53 eine drahtlose lokale Netzwerk-(LAN)Vorrichtung sein, die zur Kommunikation über zum Beispiel (und ohne Einschränkung) ein 802.11g-Netzwerk (d.h. WiFi) oder ein WiMax-Netzwerk fähig ist.
In einer Ausführungsform können eingehende Daten durch die nomadische Vorrichtung über eine Data-over-Voice-Verbindung oder einen Datentarif, durch den Bord-BLUETOOTH-Transceiver und in den internen Prozessor 3 des Fahrzeugs geleitet werden. Im Fall bestimmter vorrübergehender Daten können die Daten zum Beispiel auf der HDD oder einem anderen Speichermedium 7 bis zu einem Zeitpunkt gespeichert werden, zu dem die Daten nicht mehr benötigt werden.
Zusätzliche Quellen, die mit dem Fahrzeug koppeln können, umfassen eine persönliche Navigationsvorrichtung 54, die zum Beispiel eine USB-Verbindung 56 und/oder einer Antenne 58 aufweist, eine Fahrzeugnavigationsvorrichtung 60, die eine USB-Verbindung 62 oder eine anderen Verbindung aufweist, eine bordseitige GPS-Vorrichtung 24 oder ein (nicht gezeigtes) entferntes Navigationssystem, das eine Konnektivität mit dem Netzwerk 61 aufweist. 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 Rückgrat der seriellen Gerät-zu-Gerät-Standards. Die meisten der Protokolle können für entweder elektrische oder optische Kommunikation implementiert werden.
Ferner könnte die CPU in Verbindung mit einer Vielfalt von anderen Zusatzvorrichtungen 65 stehen. Diese Vorrichtungen können durch eine drahtlose 67 oder eine drahtgebundene Verbindung 69 verbunden sein. Die Zusatzvorrichtung 65 kann persönliche Media-Player, drahtlose Gesundheitsgeräte, tragbare Computer und dergleichen umfassen, ist jedoch nicht darauf beschränkt.
Außerdem oder alternativ könnte die CPU mit einem fahrzeugbasierten drahtlosen Router 73 mittels zum Beispiel eines WiFi-Transceivers (IEEE-803.11-Transceivers) 71 verbunden sein. Dies könnte es der CPU ermöglichen, sich mit entfernten Netzwerken im Bereich des lokalen Routers 73 zu verbinden.
Zusätzlich dazu, dass repräsentative Prozesse durch ein Fahrzeugcomputersystem ausgeführt werden, das sich in einem Fahrzeug befindet, können die repräsentativen Prozesse in bestimmten Ausführungsformen von einem Computersystem in Kommunikation mit einem Fahrzeugcomputersystem ausgeführt werden. Ein solches System kann eine drahtlose Vorrichtung (z.B. und ohne Einschränkung ein Mobiltelefon) oder ein entferntes Computersystem (z.B. und ohne Einschränkung einen Server) umfassen, das durch die drahtlose Vorrichtung verbunden ist, ist jedoch nicht darauf beschränkt. Zusammengefasst können solche Systeme als mit einem Fahrzeug verknüpfte Computersysteme (VACS) bezeichnet werden. In bestimmten Ausführungsformen können bestimmte Komponenten des VACS bestimmte Teile eines Prozesses in Abhängigkeit von der besonderen Implementierung des Systems durchführen. Wenn beispielhaft und nicht einschränkend ein Prozess einen Schritt des Sendens oder Empfangens von Informationen mit einem gekoppelten drahtlosen Vorrichtung aufweist, dann ist es wahrscheinlich, dass die drahtlose Vorrichtung diesen Teil des Prozesses nicht ausführt, da das drahtlose Vorrichtung Informationen nicht an sich selbst bzw. von sich selbst „senden und empfangen“ würde. Ein Durchschnittsfachmann wird verstehen, wann es unangebracht ist, ein bestimmtes Computersystem für eine gegebene Lösung anzuwenden.
In jeder hierin erläuterten veranschaulichenden Ausführungsformen wird ein repräsentatives, nicht einschränkendes Beispiel eines durch ein Computersystem ausführbaren Prozesses gezeigt. Bezüglich jedes Prozesses ist es für das Computersystem möglich, das den Prozess ausführt, für den begrenzten Zweck der Ausführung des Prozesses als ein Spezialprozessor konfiguriert zu werden, um den Prozess auszuführen. Es müssen nicht alle Prozess in ihrer Gesamtheit ausgeführt werden und sind als Beispiele von Arten von Prozessen zu verstehen, die ausgeführt werden können, um Elemente der Erfindung zu erreichen. Es können zu den exemplarischen Prozessen zusätzliche Schritte hinzugefügt oder entfernt werden, falls erwünscht.
Während gegenwärtige Fahrzeugcomputersysteme eine vollständige Aktualisierung von Software und Firmware über eine Händlerschnittstelle ermöglichen, erfordern solche Systeme es auch, dass der Kunde einen Händler oder andere zugelassenen Dienstanbieter aufsucht. Dies kann eine Verzögerung beim Erhalten von Updates hervorrufen, da Kunden häufig warten werden, bis das Fahrzeug eine physikalische Wartung benötigt, für einen Ölwechsel oder Reifenwechsel fällig ist, oder es einfach gänzlich versäumen, die Software aktualisieren zu lassen. Da die Software- und Firmware-Updates häufig die Leistung verbessern, werden Kunden nicht die volle optimale Erfahrung von ihrem Fahrzeug erhalten, wenn sie nicht darauf Wert legen, ihre Software aktuell zu halten, was gemäß dem Händler-Updatemodell häufige Fahrten zu einem Händler oder Wartungsstelle zu Aktualisierung erfordern kann.
Die veranschaulichenden Ausführungsformen stellen repräsentative Systeme und Verfahren zum Erhalten von Over-the-Air (OTA) Updates bereit, die es einem Kunden ermöglichen, die Fahrzeugsoftware zu aktualisieren, ohne einen Händler aufsuchen zu müssen. Die vorgeschlagenen Lösungen und Beispiele stellen ein effizientes und zuverlässiges Mittel zum Aktualisieren der Fahrzeugsoftware und Firmware mit einer minimalen Kundeninteraktion und Beeinflussung bereit. Außerdem kann der OEM verfolgen, welche Updates für welche Fahrzeuge bereitgestellt und/oder angewendet worden sind, so dass es möglich ist, eine gute Wahrnehmung davon zu haben, welche Software- und Firmware-Versionen in den eingesetzten Fahrzeugen stark vorherrschend sind, was bei der Konzentration von Updatebemühungen helfen und eine frühe Erkennung von Problemen und Benachrichtigung der passenden Beteiligten ermöglichen kann, wenn zum Beispiel irgendwelche versionsspezifischen Probleme auftreten.
2A zeigt einen veranschaulichenden cloudseitigen Prozess zum Bereitstellen eines Fahrzeugsoftware/Firmware-Updates. Bezüglich der veranschaulichenden Ausführungsformen, die in dieser Figur beschrieben werden, ist zu beachten, dass vorrübergehend ein Allzweckprozessor zum Zweck der Ausführung einiger oder aller hierin gezeigten exemplarischen Verfahren als ein Spezialprozessor befähigt werden kann. Wenn ein Code ausgeführt wird, der Befehle zur Ausführung einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor vorrübergehend als ein Spezialprozessor umfunktioniert werden, bis zu einem solchen Zeitpunkt, an dem das Verfahren beendet ist. In einem anderen Beispiel kann in einem geeigneten Umfang Firmware, die gemäß einem vorkonfigurierten Prozessor arbeitet, den Prozessor veranlassen, als ein Spezialprozessor zu arbeiten, der für den Zweck der Ausführung des Verfahrens oder einer angemessenen Variation davon vorgesehen ist.
In diesem veranschaulichenden Beispiel kann ein OEM-Ingenieur oder ein anderer Beteiligter, der dazu ausersehen ist, Software- und Firmware-Updates bereitzustellen, die Software zu einem anfänglichen Systemablageort, wie einem fahrzeuginternen Softwaresystem (IVS) hochladen, das dazu ausersehen ist, Updates von einer oder mehrere Beteiligten zu erhalten. Diese Dateien werden dann an ein globales fahrzeuginternes Informationssystem (GIVIS) gesendet, wo die Software zum Download durch Fahrzeugtools gespeichert werden kann. Nachdem das GIVIS-System die Software vom IVS-System 201 empfängt, kann das GIVIS-System die Software in die Cloud 203 schieben, von wo aus die Software an entfernt verbundene Fahrzeug-Telematiksteuereinheiten (TCU)s geliefert werden kann.
Zusätzlich dazu, die Dateien in die Cloud zu schieben (oder auf andere Weise die Dateien drahtlos verfügbar zu machen), kann das GIVIS-System einem Dienstleistungserbringungsnetzwerk (SDN) mitteilen, bestimmte Fahrzeuge zu informieren, dass ein Update für ein installiertes Software- oder Firmware-Paket zum Download und zur Installation verfügbar ist 205.
In den veranschaulichenden Ausführungsformen verfolgen die Backend-OEM-Systeme, welche Module und Versionen auf einer Vielfalt von Fahrzeugen installiert sind, die für OTA-Updates zugelassen sind. Dies sind Informationen, die zum Beispiel von einer Fahrzeug-TCU empfangen werden können und in einer entfernten OEM-Datenbank gespeichert sind. Für Fahrzeuge, deren Konfiguration bekannt ist, kann das SDN (beruhend auf bekannten installierten Software- und Firmware-Versionen) erkennen, welche Fahrzeuge für ein Update geeignet sind, und kann eine Nachricht an diese Fahrzeuge senden, dass ein neues Paket zum Download bereitsteht. Für andere Fahrzeuge, die noch nicht gemeldet worden sind, kann das System zum Beispiel Fahrzeuge zum Aktualisieren beruhend auf den anfänglichen Ausführungen erkennen, und kann diese Systeme ebenfalls benachrichtigen. Da in diesem Beispiel der Prozess die installierte Software überprüfen wird, bevor er das Update liefert, kann jede Inkompatibilität behandelt werden, wenn dem System die tatsächliche Konfiguration mitgeteilt wird.
Wenn erkannte Fahrzeuge online gehen (z.B. ohne Einschränkung, sie über den Schlüssel eingeschaltet werden), können sie sich beim Update-Server zum Beispiel beruhend auf der Benachrichtigung vom SDN anmelden. Das System empfängt die Anmeldung 207 und ein Verzeichnis der am Fahrzeug 209 der installierten Software und Firmware. Dies könnte eine vollständige Liste sein oder könnte in einem anderen Beispiel spezifisch Softwarepakete und Firmwarepakete betreffen, die für ein Update ausersehen sind. Die vollständige Liste wird den OEM mit einer gegenwärtigen Momentaufnahme des Fahrzeugs versehen, jedoch kann die kurze Liste weniger Zeit zur Zusammenzustellung und Übertragung benötigen. Der Bericht kann wie erwünscht beruhend auf der Abwägung zwischen Übertragungszeit, Vollständigkeit, Datenvolumen usw. konfiguriert werden.
Sobald das Verzeichnis vom Fahrzeug 209 empfangen ist, kann der Prozess feststellen, welche Software und Firmware zur Aktualisierung geeignet ist, und eine Liste verfügbarer Updates 211 zusammenzustellen. Dieses Update-Verzeichnis, das die updatebare Software/Firmware und/oder Versionen kennzeichnet, die zum Download verfügbar sind, kann dann an das Fahrzeug 213 gesendet werden. Wie in 2B gezeigt, wird das Fahrzeug geeignete Software herunterladen und zu einem geeigneten Zeitpunkt die Softwareupdates installieren. Sobald die Softwareupdates erfolgreich installiert worden sind, wird der Prozess ein Statusprotokoll empfangen, das den Erfolg oder Fehlschlag verschiedener Updateinstallationen 215 kennzeichnet. Dies kann zu einem späteren Zeitpunkt stattfinden, da zum Beispiel der Download beim Einschalten mit dem Schlüssel stattfinden kann und die Installation beim Ausschalten mit dem Schlüssel stattfinden kann (wenn das Fahrzeug nicht verwendet wird). Das entfernte System kann dann eine aktualisierte Momentaufnahme 217 von einigen oder allen installierten Versionen der Software und der Firmware speichern (abhängig davon, wie viele Daten im anfänglichen Verzeichnis und dem Update-Statusprotokoll bereitgestellt werden).
2B zeigt einen veranschaulichenden fahrzeugseitigen Prozess zur Update-Behandlung. Bezüglich der veranschaulichenden Ausführungsformen, die in dieser Figur beschrieben werden, ist zu beachten, dass vorrübergehend ein Allzweckprozessor für den Zweck der Ausführung einiger oder aller hierin gezeigten repräsentativen Verfahren als ein Spezialprozessor befähigt werden kann. Wenn ein Code ausgeführt wird, der Befehle zur Ausführung einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor vorrübergehend als ein Spezialprozessor umfunktioniert werden, bis zu einem solchen Zeitpunkt, an dem das Verfahren beendet ist. In einem anderen Beispiel kann in einem geeigneten Umfang Firmware, die gemäß einem vorkonfigurierten Prozessor arbeitet, den Prozessor veranlassen, als ein Spezialprozessor zu arbeiten, der für den Zweck der Ausführung des Verfahrens oder einer angemessenen Variation davon vorgesehen ist.
In diesem veranschaulichenden Beispiel ist der Prozess ein fahrzeugseitiger Prozess, der nicht notwendigerweise ohne Pausen bis zum Ende ablaufen wird (d.h. es kann erhebliche zeitliche Lücken zwischen bestimmten Schritten geben). Das Fahrzeug wird typischerweise durch die Fahrzeug-TCU benachrichtigt, dass ein aktualisierte Softwarepaket für diese Fahrzeug 221 verfügbar ist. Diese SDN-Benachrichtigung kann verwendet werden, um das Fahrzeug in einen Zustand zu versetzen, wo das Fahrzeug eine Updateprüfung vornehmen wird, wenn zum Beispiel das Fahrzeug das nächste Mal über den Schlüssel eingeschaltet wird.
Der Prozess wird beim Einschalten mit dem Schlüssel als Reaktion auf die SDN-Benachrichtigung oder zu einem anderen geeigneten Zeitpunkt ein Verzeichnis der vorhandenen Software- und Firmware-Versionen erzeugen, die am Fahrzeug 223 installiert sind. Dies kann eine vollständige Liste der Software und Firmware sein oder kann zum Beispiel auf die Versionen der Software und Firmware beschränkt sein, für die ein Update verfügbar ist. Ein drittes Beispiel einer Liste könnten die Versionen der updatebaren Software und Firmware sowie die Versionen von anderen Modulen sein, die für Kompatibilitätszwecke erforderlich sein könnten (z.B. selbst wenn das Modul Z nicht updatebar ist, könnte es bei der Version 2.0.1 für ein Update des Moduls N sein, um die Kompatibilität zu bewahren, so dass die Versionen sowohl von Z als auch N bereitgestellt werden könnten). Dann wird sich der Prozess erneut beim Einschalten mit dem Schlüssel oder einer anderen dazu ausersehenen Zeit bei der GIVIS-Cloud 225 (oder einem anderen Software/Firmware-Bereitstellungsdienst) anmelden, um die aktualisierte Software zu erhalten.
Der Prozess sendet das Verzeichnis der installierten Versionen an das GIVIS-System 227, was es dem GIVIS-System ermöglicht, eine Überprüfung durchzuführen, um zum Beispiel sicherzustellen, dass der Datenbankeintrag der installierten Software korrekt ist. Wenn das Fahrzeugsystem eine unerwartete aktualisierte Version aufweist (die zum Beispiel der Benutzer manuell installiert haben kann), kann das Update abgebrochen oder zu einem anderen Update gewechselt werden. Sobald die Eignung des Updates verifiziert oder korrigiert worden ist, wird das Fahrzeugsystem ein Update-Verzeichnis empfangen, das eine Liste der updatebaren Software-Module enthält, die zum Download 229 verfügbar sind.
Das Fahrzeugsystem wird dann die geeigneten Updates herunterladen (die alle Updates sein könnten oder eine durch das System oder den Benutzer ausgewählte Teilmenge davon) 231. Zu einem gewissen Zeitpunkt werden die Updates auch installiert 233, obwohl dies wie vorhergehend angemerkt eine andere Zeit sein könnte. Da Updates an Fahrzeugmodulen das Fahrverhalten beeinflussen können, während sie installiert werden, kann es wünschenswert sein zu warten, bis ein Fahrzeug nicht verwendet wird (wie beim Ausschalten mit dem Schlüssel), bevor die Updates installiert werden. In einem anderen Beispiel kann das System für ein Schnellupdate einfach das Fahren für eine begrenzte Zeitspanne verhindern, während ein Update angewendet wird. Dieses letztgenannte Modell könnte zum Beispiel verwendet werden, wenn ein Sicherheitsupdate hoher Priorität zur Installation heruntergeladen wird, oder zu irgendeiner andere geeigneten Zeit. Sobald die Updates installiert worden sind, kann der Prozess ein Nach-Update-Protokoll an das GIVIS-System 235 senden, das den Erfolg oder Fehlschlag von Updates enthalten kann und außerdem falls erwünscht eine andere vollständige Auflistung der gegenwärtig installierten Software- und Firmware-Module enthalten kann, um die Informationen über eine gegenwärtige Fahrzeugkonfiguration zu maximieren.
Obwohl nicht gezeigt, ist es zum Beispiel für den Prozess auch möglich, die Übertragung von bestimmten Softwareversionsupdates an ein Fahrzeug zu protokollieren oder aufzuzeichnen. Dies kann zum Beispiel bei der Erkennung eines Updateproblems helfen, wenn ein Fahrzeug wiederholt aktualisierte Versionen empfängt, jedoch das Update beim Versuch eines Updates nicht anwenden kann.
3 zeigt einen veranschaulichenden Prozess zur Update-Benachrichtigung. Bezüglich der veranschaulichenden Ausführungsformen, die in dieser Figur beschrieben werden, ist zu beachten, dass vorrübergehend ein Allzweckprozessor zum Zweck der Ausführung einiger oder aller hierin gezeigten exemplarischen Verfahren als ein Spezialprozessor befähigt werden kann. Wenn ein Code ausgeführt wird, der Befehle zur Ausführung einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor vorrübergehend als ein Spezialprozessor umfunktioniert werden, bis zu einem solchen Zeitpunkt, an dem das Verfahren beendet ist. In einem anderen Beispiel kann in einem geeigneten Umfang Firmware, die gemäß einem vorkonfigurierten Prozessor arbeitet, den Prozessor veranlassen, als ein Spezialprozessor zu arbeiten, der für den Zweck der Ausführung des Verfahrens oder einer angemessenen Variation davon vorgesehen ist.
In diesem veranschaulichenden Beispiel läuft der Prozess auf einem Dienstleistungserbringungsnetzwerk oder einem anderen Kommunikationssystem, das dazu ausersehen ist, Fahrzeuge von der Verfügbarkeit neuer Updates zu benachrichtigen. In diesem Beispiel empfängt der Prozess (oder ruft ab) die Fahrzeug-Identifizierungsnummern (FIN)s der Fahrzeuge, die durch ein bestimmtes Update 301 betroffen sind.
Die Software- und Firmware-Konfiguration für jedes Fahrzeug ist in einer Datenbank gespeichert, das mittels verschiedener Quellen (aus einer Fahrzeugauswertung, Händlerauswertung, bekannten installierten Versionen bei der Produktion usw.) bestückt und aktualisiert werden kann. Die Datenbank kann zum Beispiel abgefragt werden, um Fahrzeuge zu identifizieren, die eine bestimmte Version der Software N installiert haben, wie Fahrzeuge, die die Version 2.0.3 zum Beispiel aufweisen, für die ein neues Update 2.0.4 angewendet werden soll. In anderen Beispielen könnten alle Fahrzeuge mit Versionen bei oder niedriger als 2.0.3 abhängig zum Beispiel von dem bestimmten Update als Kandidaten zum Aktualisieren auf 2.0.4 erkannt werden.
Die Fahrzeuge können durch die FIN identifiziert werden, die auch dazu verwendet werden kann, um Kommunikationsdaten nachzuschlagen, die es ermöglichen, dass Nachrichten an spezifische FIN-identifizierte Fahrzeuge gesendet werden. Um in diesem Beispiel eine Benachrichtigung von Benutzern zu verhindern, die keine OTA-Updates wollen, führt der der Prozess eine Überprüfung jeder FIN durch, um festzustellen, ob der Benutzer den OTA-Updates 303 zugestimmt hat. FINs, die sich nicht in der Datenbank befinden, können Benutzern entsprechen, die OTA-Updates noch nicht zugestimmt haben oder die aus einer Vielfalt von Gründen (wie ein Flottenmanager, der alle Fahrzeuge auf einem selben Versionsstand haben möchte) keine OTA-Updates wollen. Wenn eine gegebene FIN über eine damit verknüpfte Zustimmung verfügt 305, kann das SDN diese FIN zu einer Liste zur Benachrichtigung 307 hinzufügen. Dieser Prozess kann fortgesetzt werden, solange FINs zur Zustimmungsüberprüfung 309 übrigbleiben. Sobald die FINs, die OTA-Updates zugestimmt haben, alle überprüft worden sind, kann der Prozess Updateanweisungen, Benachrichtigungen usw. 311 an die Fahrzeuge mit den zugehörigen FINs senden.
4 zeigt einen anderen veranschaulichenden Update-Benachrichtigungsprozess. Bezüglich der veranschaulichenden Ausführungsformen, die in dieser Figur beschrieben werden, ist zu beachten, dass vorrübergehend ein Allzweckprozessor zum Zweck der Ausführung einiger oder aller hierin gezeigten exemplarischen Verfahren als ein Spezialprozessor befähigt werden kann. Wenn ein Code ausgeführt wird, der Befehle zur Ausführung einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor vorrübergehend als ein Spezialprozessor umfunktioniert werden, bis zu einem solchen Zeitpunkt, an dem das Verfahren beendet ist. In einem anderen Beispiel kann in einem geeigneten Umfang Firmware, die gemäß einem vorkonfigurierten Prozessor arbeitet, den Prozessor veranlassen, als ein Spezialprozessor zu arbeiten, der für den Zweck der Ausführung des Verfahrens oder einer angemessenen Variation davon vorgesehen ist.
In diesem veranschaulichenden Beispiel empfängt der Prozess, der auf dem GIVIS läuft, zum Beispiel eine aktualisierte Datei von einem OEM-Ingenieur oder einem anderen Beteiligten, der dazu ausersehen ist, Updates 401 bereitzustellen. In diesem Beispiel speichert das GIVIS die Aufzeichnungen (oder greift auf die Datenbank zu, die die Aufzeichnungen speichert) der Fahrzeugkonfigurationen und wird einfach eine Liste anwendbarer FINs an das SDN zur Benachrichtigung liefern (was der repräsentative Prozess ist, der bezüglich 3 beschrieben wird). Hier nutzt der Prozess eine Datenbank, um (durch die FIN in diesem Beispiel) festzustellen, welche Fahrzeuge Software aufweisen, die für das empfangene Update 403 qualifiziert ist. In diesem Beispiel sortiert der Prozess zuerst nach Softwaremodulen 403, um festzustellen, welche Fahrzeuge updatebare Module installiert haben. Dann stellt der Prozess für jedes Fahrzeug fest, ob die Software schon aktualisiert worden ist 405 oder sich auf andere Weise in einem ungeeigneten Zustand zum Aktualisieren befindet. Wenn die Software schon aktualisiert worden ist oder sich auf andere Weise in einem ungeeigneten Zustand zum Aktualisieren befindet 405, wird der Prozess zum nächsten Eintrag 409 weitergehen. Andernfalls wird die FIN für dieses Fahrzeug zu einer Updateliste 407 hinzugefügt, die an das SDN gesendet werden soll. Natürlich kann jedes Verfahren zum Abfragen einer Datenbank und zum Zusammenstellen einer Liste von Aufzeichnungen verwendet werden, das der Prozess gezeigt lediglich veranschaulichend ist. Sobald alle Aufzeichnungen analysiert worden sind, kann der Prozess die Liste der geeigneten FINs an das SDN senden, das die gespeicherte OTA-Zustimmung überprüfen kann, wie in 3 gezeigt. Obwohl der GIVIS-Prozess in 4 und die in 3 gezeigte OTA-Zustimmungsüberprüfung bezüglich getrennter Systeme beschrieben werden, können sie falls erwünscht und geeignet abhängig vom Layout und der Konfiguration des Backend-Netzwerks zusammengefasst werden, das OTA-Softwareupdates bereitstellt.
5 zeigt einen veranschaulichenden Prozess zur Rückrufbehandlung. Bezüglich der veranschaulichenden Ausführungsformen, die in dieser Figur beschrieben werden, ist zu beachten, dass vorrübergehend ein Allzweckprozessor zum Zweck der Ausführung einiger oder aller hierin gezeigten exemplarischen Verfahren als ein Spezialprozessor befähigt werden kann. Wenn ein Code ausgeführt wird, der Befehle zur Ausführung einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor vorrübergehend als ein Spezialprozessor umfunktioniert werden, bis zu einem solchen Zeitpunkt, an dem das Verfahren beendet ist. In einem anderen Beispiel kann in einem geeigneten Umfang Firmware, die gemäß einem vorkonfigurierten Prozessor arbeitet, den Prozessor veranlassen, als ein Spezialprozessor zu arbeiten, der für den Zweck der Ausführung des Verfahrens oder einer angemessenen Variation davon vorgesehen ist.
5 zeigt einen veranschaulichenden Rückrufbenachrichtigungsprozess, der erleichtert wird, indem eine aktuellere Aufzeichnung der gegenwärtig installierten Software- und Firmware-Versionen erhalten wird. Während dies mit jedem Satz von Aufzeichnungen verwendet werden könnte, die Software- und Firmware-Versionen anzeigen, die in Fahrzeugen installiert sind, ist die Lieferung der Rückrufnachrichten umso genauer, je aktueller die Aufzeichnungen sind. Wenn ein OEM überhaupt keine Informationen über gegenwärtige Softwareversionen hat, muss er zum Beispiel eine Rückrufnachricht an alle Fahrzeugmodelle schicken, die eine Version eines bestimmten Software- oder Firmware-Moduls aufweisen, das ein bestimmtes Update benötigt. Wenn andererseits das Update zum Beispiel nur die Version 3.3.1 betrifft, kann ein vollständiger oder vollständigerer Satz von Aufzeichnungen das Ausgeben einer Rückrufnachricht an mindestens einige Fahrzeuge vermeiden, für die die Nachricht ungeeignet ist. Für Fahrzeuge, deren gegenwärtige Konfiguration unbekannt ist oder für die eine lange Zeit seit einem Update vergangen ist, kann der Prozess immer noch wählen, die Nachricht als Vorsichtsmaßnahme senden. Jedoch kann der Prozess das Senden von Nachrichten an Fahrzeuge vermeiden, für die bekannt ist, dass das Update schon angewendet worden ist und/oder die Versionen aufweisen, die nach der Version liegen, die eine Aktualisierung benötigt (3.3.2, zum Beispiel).
Der Prozess empfängt eine Rückrufnachricht, die auf ein bestimmtes Software- oder Firmware-Modul zutrifft, das in bestimmten Fahrzeugen 501 installiert ist. Mittels Datenbankabfragen, wie den vorhergehend beschriebenen, kann der Prozess identifizieren, von welchen Fahrzeugen bekannt, ist, dass sie ein Update benötigen, oder außerdem oder alternativ, welche Fahrzeuge kein Update 503 benötigen. Der Prozess kann dann eine Liste von FINs zusammenzustellen, für die eine Benachrichtigung gesendet werden sollte (oder in einer alternativen Konfiguration, eine Liste von FINs, für die eine Nachricht ist definitiv nicht benötigt wird) 505. Diese Liste kann in jeder Form verwendet werden, um die Liste der Fahrzeuge einzuschränken, an die eine Benachrichtigung gesendet wird, so dass mindestens einige Fahrer nicht überflüssig über einen Rückruf benachrichtigt werden, der für ihr Fahrzeug nicht zutrifft. Die Rückrufnachricht kann dann an die geeigneten Fahrzeuge gesendet werden.
Wie angegeben kann es immer noch beruhend auf unvollständigen Informationen eine gewisse Überlappung und Redundanz bei der Benachrichtigung mittels dieses Prozesses geben, jedoch kann die Rückrufbenachrichtigung umso zielgenauer sein, je besser die Informationen sind, die zum Beispiel von Kundenfahrzeugen und Händlerupdates empfangen werden. Ähnliche Methodologien können auch für eine andere zielgerichtete Fahrzeugbenachrichtigung verwendet, beruhend auf der Kenntnis, welche Module und Versionen auf welchen bestimmten Fahrzeugen installiert sind. Da die OTA-Updates eine häufigere Wartung von Software- und Firmware-Module ermöglichen, ohne dass es erforderlich ist, dass der Kunde einen Fahrt zum Händler unternimmt, kann die erhöhte Häufigkeit eine erhöhte Genauigkeit von Momentaufnahmen liefern, wenn solche Informationen durch den OEM gesammelt werden.
Während oben exemplarische Ausführungsformen beschrieben worden sind, ist es nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die in der Beschreibung verwendeten Worte eher Worte der Beschreibung als der Einschränkung, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne den Geist und Rahmen der Erfindung zu verlassen. Außerdem können die Merkmale der verschiedenen implementierenden 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-Protokolle [0020]
IEEE-802-LAN-Protokolle [0020]
IEEE 802 PAN [0020]
IEEE 1394 [0023]
IEEE 1284 [0023]
IEEE-803.11-Transceivers [0025]

Claims

System, das aufweist: einen Prozessor, der konfiguriert ist: als Reaktion auf eine von einem entfernten Netzwerk empfangene Benachrichtigung, dass ein Update der Fahrzeugsoftware verfügbar ist, eine Liste der installierten Fahrzeugsoftware-Versionen zusammenzustellen; die Liste der installierten Versionen zu einem entfernten Update-Server zu übertragen; als Reaktion auf die Übertragung eine Liste verfügbarer Updates zu empfangen, die mit den installierten Fahrzeugsoftware-Versionen kompatibel sind; mindestens eines der verfügbaren Updates herunterzuladen; und die heruntergeladenen Updates zu installieren.
System nach Anspruch 1, wobei die Liste der installierten Fahrzeugsoftware-Versionen Firmware-Versionen umfasst.
System nach Anspruch 1, wobei Versionen in der Liste verfügbarer Updates nur Software- und Firmware-Versionen umfassen, auf die das Update zutrifft.
System nach Anspruch 3, wobei die Software- und Firmware-Versionen, auf die das Update zutrifft, Versionen von Software oder Firmware umfassen, die nicht aktualisiert werden sollen, sich jedoch auf oder über einer bestimmten Version befinden müssen, um eine Kompatibilität mit dem Update sicherzustellen.
System nach Anspruch 1, wobei die Liste der installierten Fahrzeugkomponenten-Versionen alle installierten Software- und Firmware-Versionen umfasst.
System nach Anspruch 1, wobei der Download das Herunterladen von allen Updates umfasst.
System nach Anspruch 1, wobei der Prozessor ferner konfiguriert ist, eine vom Benutzer ausgewählte Teilmenge der verfügbaren Updates herunterzuladen, die kleiner als jedes verfügbare Update ist.
System nach Anspruch 1, wobei der Prozessor ferner konfiguriert ist, den Erfolg oder Fehlschlag jeder Update-Installation festzustellen.
System nach Anspruch 8, wobei der Prozessor konfiguriert ist, an einen entfernten Server ein Protokoll zu melden, das den Erfolg oder Fehlschlag für jede Update-Installation enthält.
System, das aufweist: einen Prozessor, der konfiguriert ist: eine Liste von Fahrzeug-Identifizierungsnummern (FIN)s zu empfangen, auf die ein verfügbares Softwareupdate zutrifft; für jede FIN festzustellen, ob ein Fahrzeughalter Over-the-Air-(OTA)-Updates zugestimmt hat; und eine Benachrichtigung an jedes Fahrzeug zu senden, das durch eine entsprechende FIN identifiziert wird, für das der Halter OTA-Updates zugestimmt hat und ein verfügbares Softwareupdate zutrifft.
System nach Anspruch 10, wobei die Liste der FINs von einem sekundären entfernten Server empfangen wird, durch den das verfügbare Softwareupdate an die Fahrzeuge geliefert wird.
System nach Anspruch 10, wobei die Liste als Reaktion auf eine Datenbankabfrage von einer Datenbank empfangen wird, die gegenwärtig installierte Softwareversionen für jedes Fahrzeug enthält, das durch die FIN identifiziert wird.
System, das aufweist: einen oder mehrere Prozessoren, die konfiguriert sind: ein Softwareupdate zu empfangen; eine Benachrichtigung an ein Fahrzeug zu liefern, für das ein Datenbankeintrag eine installierte Softwareversion anzeigt, für die das empfangene Update zutrifft; eine Softwareupdate-Downloadanforderung vom Fahrzeug zu empfangen; das Softwareupdate als Reaktion auf die Anforderung zu übertragen; ein Update-Protokoll zu empfangen, das den Erfolg oder den Fehlschlag der Installation des Softwareupdates enthält; und den Datenbankeintrag beruhend auf dem Protokoll zu aktualisieren.
System nach Anspruch 13, wobei mindestens einer der Prozessoren ferner konfiguriert ist, als Reaktion auf die Benachrichtigung eine Kommunikation von dem Fahrzeug zu empfangen, die eine Liste der gegenwärtig installierten Softwareversionen des Fahrzeugs enthält.
System nach Anspruch 14, wobei der mindestens eine der Prozessoren ferner konfiguriert ist, den Datenbankeintrag beruhend auf der empfangenen Kommunikation zu aktualisieren.
System nach Anspruch 14, wobei der mindestens eine der Prozessoren ferner konfiguriert ist, die Anwendbarkeit des Updates einer gegenwärtig installierten Softwareversion festzustellen, die in der Kommunikation identifiziert wird; und eine Bestätigung der Anwendbarkeit des Updates als Reaktion auf die Anwendbarkeitsfeststellung zu übertragen.
System nach Anspruch 16, wobei der mindestens eine der Prozessoren ferner konfiguriert ist, die Anwendbarkeit des Updates durch Bestätigen festzustellen, dass die gegenwärtig installierte Softwareversion auf oder über einer bestimmten Version befindet.
System nach Anspruch 14, wobei die Liste alle Software- und Firmware-Versionen umfasst, die gegenwärtig am Fahrzeug installiert sind.
System nach Anspruch 14, wobei die Liste nur Software- und Firmware-Versionen umfasst, auf die das Update zutrifft.
System nach Anspruch 19, wobei die Software- und Firmware-Versionen, auf die das Update zutrifft, Versionen von Software oder Firmware umfassen, die nicht aktualisiert werden sollen, sich jedoch auf oder über einer bestimmten Version befinden müssen, um eine Kompatibilität mit dem Update sicherzustellen.