DE102017116186A1

DE102017116186A1 - Fahrzeugbereichsspezifische Softwareupdateverteilung

Info

Publication number: DE102017116186A1
Application number: DE102017116186.4A
Authority: DE
Inventors: Brunilda Bleta Caushi; John Naum Vangelov
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2016-07-19
Filing date: 2017-07-18
Publication date: 2018-01-25
Also published as: US20180024826A1; CN107632839A

Abstract

Ein Server empfängt von einem Fahrzeug eine Nachricht, die einen geografischen Bereich angibt, in dem sich das Fahrzeug befindet, als Reaktion auf die Anwesenheit des Fahrzeugs in dem Bereich über einen vordefinierten Zeitraum, aktualisiert als Reaktion auf die Nachricht einen Datenspeicher, um das Fahrzeug mit dem Bereich zu verknüpfen, und gibt, als Reaktion auf eine Fahrzeuganforderung nach Softwareupdates, auf Grundlage der Verknüpfung Softwareupdates an, die von einem regionalen Softwarebereitstellungsnetzwerk des Bereichs bereitgestellt werden. Als Reaktion auf ein Bestimmen, auf Grundlage von Positionsinformationen, die von einem Positionsbestimmungssystem empfangen werden, dass sich das Fahrzeug für eine vordefinierte Vielzahl von Bereichsüberprüfungen in einem geografischen Bereich befindet, sendet eine Fahrzeugsteuerung eine Angabe des Bereichs an einen Server. Als Reaktion auf das Empfangen von von einem regionalen Softwarebereitstellungsnetzwerk gehosteten Adressen von Softwareupdates, die für Fahrzeuge innerhalb des Bereichs bestimmt sind, von dem Server, richtet die Steuerung eine Verbindung mit dem Netzwerk ein und installiert die Softwareupdates im Fahrzeug.

Description

TECHNISCHES GEBIET
Die vorliegende Offenbarung betrifft Systeme und Verfahren zum Bereitstellen von Softwareupdates über eine Luftschnittstelle (OTA – over-the-air) für ein Fahrzeug auf Grundlage eines mit dem Fahrzeug verknüpften Bereichs.
HINTERGRUND
Es kann sein, dass eine oder mehrere Software- und/oder Hardwarekomponenten eines Fahrzeugs periodische oder gelegentliche elektronische Updates benötigen. In einem Beispiel können die Softwareupdates Änderungen an der Software oder den Einstellungen des Fahrzeugs beinhalten, um ein Problem hinsichtlich der aktuellen Software oder Einstellungen anzugehen oder der aktuellen Software eine bessere Funktionalität zu bieten. In einem weiteren Beispiel können die Softwareupdates aktualisierte Konfigurationseinstellungen für ein oder mehrere Fahrzeugsteuerungen und/oder aktualisierte Software- oder Firmwareversionen beinhalten, welche auf ein oder mehrere Fahrzeugsteuerungen einzuspielen sind.
Das Fahrzeug kann konfiguriert sein, um elektronische Updates über eine drahtgebundene oder eine drahtlose Verbindung zu empfangen. In einem Beispiel kann ein Techniker bei einem Autohändler oder einer Werkstatt die Updates unter Verwendung einer drahtgebundenen LAN-Verbindung (Land Access Network) auf das Fahrzeug herunterladen. In einem weiteren Beispiel kann das Fahrzeug konfiguriert sein, um Softwareupdates über eine Luftschnittstelle (OTA) zu empfangen, wie Softwareupdates, die über eine drahtlose Verbindung zu einem Server empfangen werden.
KURZDARSTELLUNG
Ein System beinhaltet einen Server, der konfiguriert ist, um: von einem Fahrzeug eine Nachricht zu empfangen, die einen geografischen Bereich angibt, in dem sich das Fahrzeug befindet, als Reaktion auf die Anwesenheit des Fahrzeugs in dem Bereich über einen vordefinierten Zeitraum, um als Reaktion auf die Nachricht einen Datenspeicher zu aktualisieren, um das Fahrzeug mit dem Bereich zu verknüpfen, und um als Reaktion auf eine Fahrzeuganforderung nach Softwareupdates auf Grundlage der Verknüpfung Softwareupdates anzugeben, die von einem regionalen Softwarebereitstellungsnetzwerk des Bereichs bereitgestellt werden.
Ein System beinhaltet einen Server, der konfiguriert ist, um: als Reaktion auf eine Anforderung von einem Fahrzeug, Softwareupdates bereitzustellen, einen mit dem Fahrzeug verknüpften geografischen Bereich und ein regionales Softwarebereitstellungsnetzwerk zu identifizieren, das Softwareupdates für Fahrzeuge innerhalb des Bereichs bereitstellt, und um von dem regionalen Softwarebereitstellungsnetzwerk gehostete Adressen von Softwareupdates, die für Fahrzeuge innerhalb des Bereichs bestimmt sind, an das Fahrzeug zu senden.
Ein System für ein Fahrzeug beinhaltet einen Server, der konfiguriert ist, um: als Reaktion auf ein Bestimmen auf Grundlage von Positionsinformationen, die von einem Positionsbestimmungssystem empfangen werden, dass sich das Fahrzeug für eine vordefinierte Vielzahl von Bereichsüberprüfungen in einem geografischen Bereich befindet, eine Angabe des Bereichs an einen Server zu senden, und um als Reaktion auf das Empfangen von von einem regionalen Softwarebereitstellungsnetzwerk gehosteten Adressen von Softwareupdates, die für Fahrzeuge innerhalb des Bereichs bestimmt sind, von dem Server, eine Verbindung mit dem Netzwerk einzurichten und die Softwareupdates im Fahrzeug zu installieren.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Blockschaubild, das eine fahrzeugbasierte Rechnerplattform veranschaulicht;
2 ist ein Blockschaubild, das einen im Fahrzeug integrierten Softwareupdateserver und mehrere regionale Softwarebereitstellungsnetzwerke, die mit einem Fahrzeug kommunizieren, veranschaulicht;
3 ist ein Datenflussdiagramm, das die Bereitstellung einer aktualisierten Bereichskennung, die mit dem Fahrzeug zu verknüpfen ist, veranschaulicht;
4 ist ein Datenflussdiagramm, das die Bereitstellung von Softwareupdates unter Verwendung der regionalen Softwarebereitstellungsnetzwerke veranschaulicht;
5 ist ein Ablaufdiagramm, das einen Algorithmus zum Aktualisieren des mit dem Fahrzeug verknüpften Bereichs veranschaulicht; und
6 ist ein Ablaufdiagramm, das einen Algorithmus zum Bereitstellen von Softwareupdates für das Fahrzeug auf Grundlage des aktualisierten Bereichs veranschaulicht.
DETAILLIERTE BESCHREIBUNG
Ausführungsformen der vorliegenden Offenbarung werden hier beschrieben. Es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich Beispiele darstellen und andere Ausführungsformen verschiedene und alternative Formen annehmen können. Die Figuren sind nicht zwingend maßstabsgetreu; einige Merkmale können vergrößert oder verkleinert dargestellt sein, um Einzelheiten von bestimmten Komponenten zu zeigen. Dementsprechend sind hierin offenbarte konkrete bauliche und funktionelle Einzelheiten nicht als einschränkend auszulegen, sondern lediglich als repräsentative Basis, um einen Fachmann eine vielfältige Verwendung der vorliegenden Erfindung zu lehren. Wie der Fachmann verstehen wird, können verschiedene Merkmale, die dargestellt und unter Bezugnahme auf beliebige der Figuren beschrieben werden, mit Merkmalen kombiniert werden, die in einer oder mehreren anderen Figuren dargestellt sind, um Ausführungsformen zu erzeugen, 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 Modifikationen der Merkmale, welche mit den Lehren dieser Offenbarung übereinstimmen, können jedoch für bestimmte Anwendungen oder Umsetzungen erwünscht sein.
1 veranschaulicht ein beispielhaftes Diagramm eines Systems 100, das verwendet werden kann, um einem Fahrzeug 102 Telematikdienste zur Verfügung zu stellen. Bei dem Fahrzeug 102 kann es sich um unterschiedliche Arten von Personenkraftwagen handeln, wie beispielsweise Softroader (Crossover Utility Vehicle – CUV), Geländewagen (Sport Utility Vehicle – SUV), LKW, Wohnmobile (RV), Boote, Flugzeuge oder andere mobile Maschinen zum Befördern von Personen oder Transportieren von Gütern. Telematikdienste können unter anderem Navigation, Wegbeschreibungen, Fahrzeugdiagnosen, lokale Unternehmenssuche, Unfallmeldungen und Freisprecheinrichtungen umfassen. In einem Beispiel kann das System 100 das SYNC-System enthalten, hergestellt durch The Ford Motor Company in Dearborn, Michigan. Es ist anzumerken, dass das veranschaulichte System 100 lediglich ein Beispiel darstellt und mehr, weniger und/oder anders angeordnete Elemente verwendet werden können.
Die Rechnerplattform 104 kann einen oder mehrere Prozessoren 106 umfassen, welche sowohl mit einem Speicher 108 als auch einem computerlesbaren Speichermedium 112 verbunden und konfiguriert sind, um Anweisungen, Befehle und andere Routinen durchzuführen, um die hierin beschriebenen Verfahren zu unterstützen. Beispielsweise kann die Rechnerplattform 104 konfiguriert sein, um Anweisungen von Fahrzeuganwendungen 110 zum Bereitstellen von Funktionen, wie beispielsweise Navigation, Unfallmeldung, Satellitenradioentschlüsselung und Freisprecheinrichtung, auszuführen. Solche Anweisungen und andere Daten können nicht flüchtig unter Verwendung einer Vielzahl von Arten von computerlesbaren Speichermedien 112 vorgehalten werden. Das computerlesbare Speichermedium 112 (auch als prozessorlesbares Medium oder prozessorlesbarer Speicher bezeichnet) umfasst ein nicht flüchtiges (z. B. materielles) Medium, welches an der Bereitstellung von Anweisungen oder anderen Daten beteiligt ist, welche durch den Prozessor 106 der Rechnerplattform 104 gelesen werden können. Durch den Computer ausführbare Anweisungen können von Computerprogrammen zusammengestellt oder interpretiert werden, welche unter Verwendung einer Vielzahl von Programmiersprachen und/oder -technologien hergestellt wurden, einschließlich unter anderem und entweder allein oder in Kombination Java, C, C++, C#, Objective C, Fortran, Pascal, Java Script, Python, Perl und PL/SQL.
Die Rechnerplattform 104 kann mit verschiedenen Funktionen ausgestattet sein, durch welche die Fahrzeuginsassen eine Verbindung mit der Rechnerplattform 104 herstellen können. Beispielsweise kann die Rechnerplattform 104 einen Audioeingang 114, der konfiguriert ist, um Sprachbefehle von Fahrzeuginsassen über ein verbundenes Mikrofon 116 zu empfangen, und einen zusätzlichen Audioeingang 118, der konfiguriert ist, um Audiosignale von verbundenen Geräten zu empfangen, beinhalten. Bei dem zusätzlichen Audioeingang 118 kann es sich um eine drahtgebundene Buchse, wie beispielsweise einen Stereoeingang, oder einen drahtlosen Eingang handeln, wie beispielsweise eine Bluetooth^®-Audioverbindung. In einigen Beispielen kann der Audioeingang 114 so konfiguriert sein, dass er Audioverarbeitungsfähigkeiten besitzt, wie beispielsweise das Vorverstärken von niedrigen Signalen und das Umwandeln von analogen Eingängen in digitale Daten zum Verarbeiten durch den Prozessor 106.
Die Rechnerplattform 104 kann ferner einen oder mehrere Audioausgänge 120 zu einem Eingang der Audiowiedergabefunktion der Audiosteuerung 122 bereitstellen. In anderen Beispielen kann die Rechnerplattform 104 Audioausgang durch die Verwendung eines oder mehrerer fest zugeordneter Lautsprecher (nicht abgebildet) an die Insassen bereitstellen. Die Audiosteuerung 122 kann eine Eingangswähleinheit 124 umfassen, die konfiguriert ist, um einem Audioverstärker 128 zum Wiedergeben über die Fahrzeuglautsprecher 130 Audioinhalte von einer ausgewählten Audioquelle 126 bereitzustellen. Die Audioquellen 126 können beispielsweise decodierte amplitudenmodulierte (AM) oder frequenzmodulierte (FM) Radiosignale und Audiowiedergaben von Compact Disks (CDs) oder Digital Versatile Disks (DVDs) umfassen. Die Audioquellen 126 können ferner Audiodaten umfassen, welche von der Rechnerplattform 104 empfangen wurden, wie beispielsweise durch die Rechnerplattform 104 erstellte Audioinhalte, von Flash-Speichersticks dekodierte Audioinhalte, welche mit einem USB-Untersystem 132 (Universal Serial Bus) der Rechnerplattform 104 verbunden sind, und vom zusätzlichen Audioeingang 118 durch die Rechnerplattform 104 geleitete Audioinhalte.
Die Rechnerplattform 104 kann eine Sprachschnittstelle 134 verwenden, um eine Freisprecheinrichtung für die Rechnerplattform 104 bereitzustellen. Die Sprachschnittstelle 134 kann eine Spracherkennung von über das Mikrofon 116 empfangenen Audiodaten entsprechend einer Grammatik von verfügbaren Befehlen und das Erstellen von Sprachaufforderungen zur Ausgabe über die Audiosteuerung 122 unterstützen. In einigen Fällen kann das System so konfiguriert sein, dass es die durch die Eingangswähleinheit 124 vorgegebene Audioquelle stumm schaltet, leiser macht oder anderweitig überspielt, wenn eine Audioaufforderung durch die Rechnerplattform 104 ausgegeben werden kann und eine andere Audioquelle 126 zur Wiedergabe ausgewählt ist.
Die Rechnerplattform 104 kann ferner Eingaben von Bedienelementen einer Mensch-Maschine-Schnittstelle (Human Machine Interface – HMI) 136 empfangen, die konfiguriert ist, um eine Interaktion zwischen Insassen und dem Fahrzeug 102 zu ermöglichen. Beispielsweise kann die Rechnerplattform 104 mit einer oder mehreren Schaltflächen oder anderen HMI-Bedienelementen eine Verbindung herstellen, die konfiguriert sind, um Funktionen der Rechnerplattform 104 aufzurufen (z. B. Audiotasten am Lenkrad, Sprechtasten, Bedienelemente auf der Armaturentafel usw.). Die Rechnerplattform 104 kann ferner eine oder mehrere Anzeigen 138 steuern oder anderweitig damit kommunizieren, die konfiguriert sind, um über ein Videosteuergerät 140 eine visuelle Ausgabe für die Fahrzeuginsassen bereitzustellen. In einigen Fällen kann es sich bei der Anzeige 138 um einen Touchscreen handeln, der ferner konfiguriert ist, um berührungsbasierte Eingaben vom Nutzer über das Videosteuergerät 140 zu empfangen, wohingegen in anderen Fällen die Anzeige 138 lediglich eine Anzeige sein kann, ohne die Möglichkeit zur Eingabe durch Berührungen.
Die Rechnerplattform 104 kann ferner so konfiguriert sein, dass sie über ein oder mehrere fahrzeuginterne Netzwerke 142 mit anderen Komponenten des Fahrzeugs 102 kommuniziert. Die fahrzeuginternen Netzwerke 142 können eines oder mehrere der folgenden umfassen: ein lokales Netzwerk des Fahrzeugsteuergerätes (Controller Area Network – CAN), ein Ethernet-Netzwerk oder eine mediengebundene Systemübertragung (Media-Oriented System Transfer – MOST), als einige Beispiele. Durch die fahrzeuginternen Netzwerke 142 kann die Rechnerplattform 104 mit anderen Systemen im Fahrzeug 102 kommunizieren, wie beispielsweise ein Fahrzeugmodem 144 (bei einigen Konfigurationen unter Umständen nicht vorhanden), eine globale Positionsbestimmungssystemsteuerung (GPS) 146, die konfiguriert ist, um die aktuelle Position und die Fahrtrichtung des Fahrzeugs 102 bereitzustellen, und verschiedene Fahrzeugsteuerungen 148, die konfiguriert sind, um andere Informationsarten hinsichtlich der Systeme des Fahrzeugs 102 bereitzustellen. Als nicht einschränkende Möglichkeiten können die Fahrzeugsteuerungen 148 beispielsweise eine Antriebsstrangsteuerung, die so konfiguriert ist, dass sie die Betriebskomponenten des Motors steuert (z. B. Leerlaufregler, Komponenten der Kraftstoffzufuhr, Komponenten der Emissionssteuerung usw.) und die Betriebskomponenten des Motors überwacht (z. B. Status von Diagnosecodes des Motors); eine Karosseriesteuerung, die so konfiguriert ist, dass sie unterschiedliche Funktionen zur Leistungssteuerung verwaltet, wie beispielsweise Außenbeleuchtung, Innenraumbeleuchtung, schlüsselloser Zugang, Fernstart, und den Status von Zugangspunkten überprüft (z. B. Schließstatus der Motorhaube, der Türen und/oder des Kofferraums des Fahrzeugs 102); ein Funksprechgerät, das so konfiguriert ist, dass es mit Schlüsselanhängern oder anderen lokalen Geräten des Fahrzeugs 102 kommuniziert; und eine Klimaanlagensteuerung, die so konfiguriert ist, dass sie die Komponenten der Klimaanlage steuert und überwacht (z. B. Steuerung von Kompressorkupplung und Gebläselüfter, Temperatursensorinformationen usw.) beinhalten.
Wie gezeigt, können die Audiosteuerung 122 und die HMI-Bedienelemente 136 über ein erstes fahrzeuginternes Netzwerk 142A mit der Rechnerplattform 104 kommunizieren, und das Fahrzeugmodem 144, die GPS-Steuerung 146 und die Fahrzeugsteuerungen 148 können über ein zweites fahrzeuginternes Netzwerk 142B mit der Rechnerplattform 104 kommunizieren. In anderen Beispielen kann die Rechnerplattform 104 mit mehr oder weniger fahrzeuginternen Netzwerken 142 verbunden sein. Zusätzlich oder alternativ können ein oder mehrere HMI-Bedienelemente 136 oder andere Komponenten über andere als die gezeigten fahrzeuginternen Netzwerke 142 oder direkt ohne Verbindung zu einem fahrzeuginternen Netzwerk 142 mit der Rechnerplattform 104 verbunden sein.
Die Rechnerplattform 104 kann ferner konfiguriert sein, um mit mobilen Geräten 152 der Fahrzeuginsassen zu kommunizieren. Bei den mobilen Geräten 152 kann es sich um beliebige Arten von tragbaren Computergeräten handeln, wie beispielsweise Mobiltelefone, Tablet-Computer, Smart Watches, Laptops, tragbare Musikwiedergabegeräte oder andere Geräte, welche eine Verbindung mit der Rechnerplattform 104 herstellen können. In vielen Beispielen kann die Rechnerplattform 104 ein drahtloses Sende-Empfangsgerät 150 (z. B. eine Bluetooth^®-Steuerung, ein ZigBee^®-Sende-Empfangsgerät, ein Wi-Fi-Sende-Empfangsgerät usw.) umfassen, das konfiguriert ist, um mit einem kompatiblen drahtlosen Sende-Empfangsgerät 154 des mobilen Gerätes 152 zu kommunizieren. Zusätzlich oder alternativ kann die Rechnerplattform 104 über eine drahtgebundene Verbindung mit dem mobilen Gerät 152 kommunizieren, wie beispielsweise über eine USB-Verbindung zwischen dem Mobilgerät 152 und dem USB-Untersystem 132.
Das Weitverkehrsnetzwerk 156 kann Geräten, welche mit dem Weitverkehrsnetzwerk 156 verbunden sind, Verbindungsdienste bereitstellen, wie beispielsweise paketvermittelte Netzwerkdienste (z. B. Internetzugang, VoIP-Kommunikationsdienste). Ein Beispiel für ein Weitverkehrsnetzwerk 156 kann ein Mobilfunknetz beinhalten. Mobilgeräte 152 können eine Netzwerkkonnektivität zum Weitverkehrsnetzwerk 156 über ein Gerätemodem 158 des Mobilgerätes 152 bereitstellen. Um die Kommunikation über das Weitverkehrsnetzwerk 156 zu vereinfachen, können Mobilgeräte 152 mit einzigartigen Gerätekennungen assoziiert sein (z. B. MAC-Adressen (Media Access Control), Mobilgerätenummern (MDN), Internetprotokoll(IP)-Adressen, netzspezifische internationale Rufnummern innerhalb eines digitalen Mobilfunknetzes (Mobile Station International Subscriber Directory Number – MSISDN), die internationale Teilnehmeridentität (International Mobile Subscriber Identity – IMSI) usw.), um die Kommunikation der Mobilgeräte 152 über das Weitverkehrsnetzwerk 156 zu identifizieren. In einigen Fällen können Insassen des Fahrzeugs 102 oder Geräte mit der Freigabe zum Verbinden mit der Rechnerplattform 104 durch die Rechnerplattform 104 gemäß gepaarten Gerätedaten 160 identifiziert werden, welche im Speichermedium 112 gepflegt werden. Die gepaarten Gerätedaten 160 können beispielsweise auf die einzigartigen Gerätekennungen von Mobilgeräten 152, welche im Vorfeld mit der Rechnerplattform 104 des Fahrzeugs 102 gepaart wurden, geheime Informationen, welche zwischen dem gepaarten Mobilgerät 152 und der Rechnerplattform 104 geteilt wurden, wie beispielsweise Verbindungsschlüssel, und/oder persönliche Identifikationsnummern (PIN), und die zuletzt verwendeten oder Geräteprioritätsinformationen hindeuten, so dass die Rechnerplattform 104 ohne ein Eingreifen des Nutzers automatisch erneut eine Verbindung mit den Mobilgeräten 152 herstellen kann, welche den Daten in den gepaarten Gerätedaten 160 entsprechen. In einigen Fällen können die gepaarten Gerätedaten 160 ferner auf zusätzliche Informationen oder Optionen im Zusammenhang mit den Freigaben oder der Funktionalität der Rechnerplattform 104 hindeuten, auf welche das gepaarte Mobilgerät 152 nach dem Herstellen einer Verbindung zugreifen darf.
Wird ein gepaartes Mobilgerät 152, welches Netzwerkkonnektivität unterstützt, automatisch oder manuell mit der Rechnerplattform 104 verbunden, kann das Mobilgerät 152 der Rechnerplattform 104 die Nutzung der Netzwerkkonnektivität des Gerätemodems 158 erlauben, um über das Weitverkehrsnetzwerk 156 zu kommunizieren. In einem Beispiel kann die Rechnerplattform 104 eine Daten-über-Sprache-Verbindung über einen Sprachanruf oder eine Datenverbindung des Mobilgerätes 152 nutzen, um Informationen zwischen der Rechnerplattform 104 und dem Weitverkehrsnetzwerk 156 zu kommunizieren. Zusätzlich oder alternativ kann die Rechnerplattform 104 das Fahrzeugmodem 144 verwenden, um Informationen zwischen der Rechnerplattform 104 und dem Weitverkehrsnetzwerk 156 zu kommunizieren, ohne dabei Verbindungseinrichtungen des Mobilgerätes 152 zu verwenden.
Ähnlich der Rechnerplattform 104 kann das Mobilgerät 152 einen oder mehrere Prozessoren 162 umfassen, die konfiguriert sind, um Anweisungen von mobilen Anwendungen 168 auszuführen, welche von einem Speichermedium 166 des Mobilgerätes 152 in einen Speicher 164 des Mobilgerätes 152 geladen werden. In einigen Beispielen können die mobilen Anwendungen 168 konfiguriert sein, um mit der Rechnerplattform 104 oder anderen lokal vernetzten Geräten und mit dem Weitverkehrsnetzwerk 156 zu kommunizieren.
Die Rechnerplattform 104 kann ferner eine Geräteverknüpfungsschnittstelle 170 beinhalten, um die Einbindung von Funktionen der mobilen Anwendungen 168 in die Grammatik von über die Sprachschnittstelle 134 verfügbaren Befehlen zu ermöglichen. Die Geräteverknüpfungsschnittstelle 170 kann den mobilen Anwendungen 168 ferner Zugriff auf Fahrzeugfunktionen, wie beispielsweise der Rechnerplattform 104 über fahrzeuginterne Netzwerke 142 zur Verfügung stehende Informationen, oder Zugriff auf die Anzeige 138 bereitstellen. Ein Beispiel für eine Geräteverknüpfungsschnittstelle 170 kann die SYNC APPLINK-Komponente des SYNC-Systems darstellen, angeboten durch The Ford Motor Company in Dearborn, Michigan.
In 2 ist ein beispielhaftes Diagramm 200 eines fahrzeuginternen Softwareupdateservers (nachfolgend IVSU) 202 und mehrerer regionaler Softwarebereitstellungsnetzwerke 204 in Kommunikation über das Netzwerk 156 mit dem Fahrzeug 102 dargestellt. Das Fahrzeug 102 kann in drahtloser Verbindung mit dem Netzwerk 156 über die Rechnerplattform 104 des Fahrzeugs 102 stehen. Wenn das Fahrzeug 102 montiert wird, kann das Fahrzeug 102 unterschiedliche Hardware- und Softwarekomponenten beinhalten. Bei oder nach der Montage kann die Rechnerplattform 104 des Fahrzeugs 102 konfiguriert sein, um die Anwesenheit und Versionsinformationen von mindestens einem Teil dieser Hardware- und Softwarekomponenten des Fahrzeugs 102 abzufragen. Die Rechnerplattform 104 kann beispielsweise eine optimierte Datenkennungslisten-Datei (ODL-Datei) 214 referenzieren, die konkret abzufragende Informationen und die möglichen Speicherorte solcher Informationen definiert. In einigen Fällen kann die ODL-Datei 214 als Teil einer Softwareinstallation auf der Rechnerplattform 104 installiert sein.
Die Rechnerplattform 104 kann die abgefragten Daten verwenden, um ein Abfrageprotokoll 212 zu erzeugen. Bei dem Abfrageprotokoll 212 kann es sich um eine Datei oder eine andere Datenstruktur handeln, die vom Fahrzeug 102 gesammelte Informationen für eine Verwendung beim Identifizieren der aktuellen Softwareversion des Fahrzeugs 102 beinhaltet. Das Abfrageprotokoll 212 kann Informationen beinhalten, die das konkrete Fahrzeug 102 sowie eine oder mehrere der Fahrzeugsteuerungen 148 identifizieren, wobei Parameter und Werte wie u. a. Bezeichnung der Steuerung, Seriennummer der Steuerung, Fahrgestellnummer, Hardwareteilenummer, MAC-Adresse, Teilenummern von Softwareanwendungen, Sprachen und Service-Packs, welche in der Steuerung installiert sind, verfügbarer Speicherplatz in der Steuerung und Statusinformationen hinsichtlich der Installation vorhergehender Updates verwendet werden.
Die Rechnerplattform 104 kann ferner konfiguriert sein, um eine gespeicherte Bereichskennung 228 abzufragen. Die gespeicherte Bereichskennung 228 kann eine alphanumerische Kennung eines Bereichs 210, in dem das Fahrzeug 102 hergestellt, montiert oder getestet wurde, oder stattdessen eines Bereich 210, in dem der Vertrieb des Fahrzeugs 102 an den Kunden geplant ist, sein. Der Bereich 210 kann somit ein geografischer Bereich sein, der mit dem Fahrzeug 102 verknüpft ist und kann, muss aber nicht, politischen Grenzen, internationalen, nationalen oder lokalen Grenzen entsprechen, die Hoheitsgebiete, Provinzen, Fürstentümer oder andere Besiedlungen kennzeichnen. Wie nachfolgend beschrieben kann die gespeicherte Bereichskennung 228, sobald das Fahrzeug 102 die Bereiche 210 wechselt, überschrieben werden, um mit einer Bereichskennung des Bereichs 210, in dem sich das Fahrzeug 102 aktuell befindet, übereinzustimmen.
Unter Verwendung von Informationen, die das konkrete Fahrzeug 102 identifizieren, wie u. a. die über den Bus des Fahrzeugnetzwerkes (Car Area Network – CAN) veröffentlichte Fahrgestellnummer (VIN), Teilnehmeridentitätsmodul-Informationen (SIM-Informationen) des Fahrzeugmodems 144, wie beispielsweise die eindeutige Seriennummer (International Mobile Station Equipment Identity – IMEI) usw.), kann die Rechnerplattform 104 über das Netzwerk 156 kommunizieren, um ein Konto beim IVSU 202 einzurichten. In einem Beispiel kann die Rechnerplattform 104 dem IVSU 202 das Abfrageprotokoll 212 senden, das Informationen, die das konkrete Fahrzeug 102 identifizieren, und Informationen bezüglich einer aktuellen Softwareversion der Steuerungen des Fahrzeugs 102 beinhaltet. Der IVSU 202 kann diese Kommunikationen von den Fahrzeugen 102 empfangen und kann einen Datenspeicher der Hardwarekonfigurationen und Softwareversionen (z. B. Firmware usw.), der mit den Kennungen der Fahrzeuge 102 verbunden ist, z. B. mit der VIN des Fahrzeugs 102 verbunden ist, pflegen. Der IVSU 202 kann ferner einen Datenspeicher der gespeicherten Bereichskennung 228 pflegen, die den mit dem Fahrzeug 102 verknüpften, vorher bestimmten Bereich 210 definiert.
Die regionalen Softwarebereitstellungsnetzwerke 204 können sich in verschiedenen Bereichen 210 befinden, so dass jeder der Bereiche 210 sein eigenes entsprechendes regionales Softwarebereitstellungsnetzwerk 204 aufweist. Jedes regionale Softwarebereitstellungsnetzwerk 204 kann einen oder mehrere Webserver 218 zum Hosten der Softwareupdates 220 zum Herunterladen durch die Fahrzeuge 102 bereitstellen. Die Webserver 218 können ein oder mehrere Geräte umfassen, die konfiguriert sind, um den Fahrzeugen 102 die Softwareupdates 220 bereitzustellen, die durch das regionale Softwarebereitstellungsnetzwerk 204 gespeichert sind. Beispielsweise können die Webserver 218 konfiguriert sein, um Aktualisierungsanfragen nach verfügbaren Softwareupdates 220 von Fahrzeugen 102 zu empfangen. In einem Beispiel können die regionalen Softwarebereitstellungsnetzwerke 204 dazu gedacht sein, die Softwareupdates 220 den Fahrzeugen 102 bereitzustellen, die sich im selben Bereich 210 wie das regionale Softwarebereitstellungsnetzwerk 204 befinden.
Die Softwareupdates 220 können Änderungen an der Software oder den Einstellungen des Fahrzeugs 102 beinhalten, um ein Problem hinsichtlich der aktuellen Software oder Einstellungen anzugehen oder der aktuellen Software eine bessere Funktionalität zu bieten. Die Softwareupdates 220 können beispielsweise aktualisierte Konfigurationseinstellungen für eine oder mehrere Fahrzeugsteuerungen 148 und/oder aktualisierte Software- oder Firmwareversionen beinhalten, die auf eine oder mehrere Fahrzeugsteuerungen 148 zu installieren sind. In einigen Fällen können Softwareupdates 220 einen einzelnen Abschnitt umfassen, wohingegen Softwareupdates 220 in anderen Fällen in mehreren Teilabschnitten, Partitionen oder Blöcken angeordnet sein können, wobei alle Teilabschnitte heruntergeladen werden können, um das zu installierende Softwareupdate 220 insgesamt abzuschließen. In einigen Beispielen können die Softwareupdates 220 von einem Lieferanten (z. B. der Fahrzeugsteuerungen 148) oder vom Fahrzeughersteller stammen. In einigen Fällen kann zumindest ein Teil der Softwareupdates 220 verschlüsselt sein, während die Softwareupdates 220 in anderen Fällen unverschlüsselt sein können.
Der Bereichsprüfer 206 des Fahrzeugs 102 kann konfiguriert sein, um zu bestimmen, in welchem Bereich 210 sich das Fahrzeug 102 aktuell befindet. In einem Beispiel kann der Bereichsprüfer 206 konfiguriert sein, um Informationen, die auf die aktuelle Position des Fahrzeugs 102 hinweisen, von der GPS-Steuerung 146 und/oder von einer oder mehreren der Fahrzeugsteuerungen 148 abzurufen. Zum Beispiel kann der Bereichsprüfer 206 konfiguriert sein, um die aktuelle Position des Fahrzeugs 102 periodisch oder als Reaktion auf ein vordefiniertes Signal, z. B. bei jedem Zündungszyklus/Startereignis und/oder bei jeder vordefinierten Anzahl von Zündungszyklen/Startereignissen, abzurufen. Der Bereichsprüfer 206 kann ferner konfiguriert sein, um zu bestimmen, welchem der Bereiche 210 die aktuelle Position des Fahrzeugs 102 entspricht. Der Bereichsprüfer 206 kann zum Beispiel eine Auflistung von Bereichskennungen referenzieren, die in dem Speicher 108 gespeichert ist und mit einer Vielzahl von geografischen Koordinaten, die die Grenzen der Bereiche 210 identifizieren, beispielsweise mittels Geofence-GPS-Koordinaten, verbunden ist.
Als Reaktion auf die Bestimmung des aktuellen Bereichs 210 des Fahrzeugs 102 kann der Bereichsprüfer 206 konfiguriert sein, um die aktuelle Bereichskennung 230, die dem identifizierten aktuellen Bereich 210 des Fahrzeugs 102 entspricht, mit einer gespeicherten Bereichskennung 228 zu vergleichen, die einen vorher bestimmten Bereich 210, in dem sich das Fahrzeug 102 befand, angibt. In einem Beispiel kann die gespeicherte Bereichskennung 228 von dem Bereichsprüfer 206 in einem Datenspeicher der Rechnerplattform 104 gepflegt werden. Als Reaktion darauf, dass der Bereichsprüfer 206 bestimmt, dass sich die aktuelle Bereichskennung 230 von der gespeicherten Bereichskennung 228 unterscheidet, kann der Bereichsprüfer 206 konfiguriert sein, um die aktuelle Bereichskennung 230 an den IVSU 202 zu übertragen. In einem Beispiel kann der Bereichsprüfer 206 konfiguriert sein, um die aktuelle Bereichskennung 230 als Reaktion auf Bestimmungen, dass sich die aktuelle Bereichskennung 230 über einen vordefinierten Zeitraum oder eine vordefinierte Anzahl von Zündungszyklen/Startereignissen weiterhin von der gespeicherten Bereichskennung 228 unterscheidet, zu senden. In diesem Fall kann der Bereichsprüfer 206 konfiguriert sein, um die gespeicherte Bereichskennung 228 in dem Datenspeicher mit einer Kennung der aktuellen Bereichskennung 230 vor, während oder als Reaktion auf eine Übertragung der aktuellen Bereichskennung 230 an den IVSU 202 zu aktualisieren.
Ein Bereichsempfänger 222 des IVSU 202 kann konfiguriert sein, um eine Nachricht von dem Fahrzeug 102 zu empfangen, die das Fahrzeug 102 (z. B. durch die VIN) identifiziert und die aktuelle Bereichskennung 230 des Fahrzeugs 102 angibt. Dies kann dementsprechend ermöglichen, dass der IVSU 202 über den Bereich 210, in dem sich das Fahrzeug 102 nun befindet, informiert ist. Der Bereichsempfänger 222 kann konfiguriert sein, um die empfangene aktuelle Bereichskennung 230 mit Informationen zu verknüpfen, die das konkrete Fahrzeug 102 identifizieren, z. B. die VIN, zur Verwendung beim Verarbeiten von Updateanfragen vom Fahrzeug 102. Zum Beispiel kann der Bereichsempfänger 222 als Reaktion auf eine Updateanfrage konfiguriert sein, die aktuelle Bereichskennung 230, die der VIN des Fahrzeugs 102, das die Anfrage sendet, entspricht, zu identifizieren, wie etwa die vom gleichen Fahrzeug 102 während eines vorherigen Datenaustauschs empfangene aktuelle Bereichskennung 230.
Der Bereichsempfänger 222 kann Daten 226 des regionalen Softwarebereitstellungsnetzwerkes (RSDN) verwenden, um zu bestimmen, welches der regionalen Softwarebereitstellungsnetzwerke 204 von dem Fahrzeug 102, das die Softwareupdates 220 anfordert, verwendet werden soll. In einem Beispiel kann der Bereichsempfänger 222 die im Datenspeicher gepflegten Informationen verwenden, um zu identifizieren, welches regionale Softwarebereitstellungsnetzwerk 204 die Softwareupdates 220 für ein Fahrzeug 102, das sich in der aktuellen Bereichskennung 230 befindet, bereitstellen soll. Die RSDN-Daten 226 können Informationen beinhalten, die angeben, welche regionalen Softwarebereitstellungsnetzwerke 204 zur Verwendung in welchen Bereichen 210 zugewiesen sind. In einem Beispiel können die RSDN-Daten 226 eine Abbildung von Netzwerkkennungen oder anderen Adressen der regionalen Softwarebereitstellungsnetzwerke 204 auf Kennungen der Bereiche 210 beinhalten, welche durch die jeweiligen regionalen Softwarebereitstellungsnetzwerke 204 versorgt werden.
Ein Anweisungsersteller 224 kann konfiguriert sein, um eine Anweisungsdatei (nachfolgend Anweisungen) 216 unter Verwendung des Abfrageprotokolls 212 zu erzeugen. Um die Softwareupdates 220 zu identifizieren, kann der Anweisungsersteller 224 konfiguriert sein, um die aktuellen Softwareversionen von Steuerungen, die im vom Fahrzeug 102 empfangenen Abfrageprotokoll 212 angegeben sind, mit der neuesten Version der Software zu vergleichen, die mit der Rechnerplattform 104 kompatibel ist. Der Anweisungsersteller 224 kann ferner konfiguriert sein, um für alle Komponenten, die aktualisiert werden sollen, alle zusätzlichen unter Umständen durch diese aktualisierten Versionen geforderten Abhängigkeiten zu erkennen. Diese zusätzlichen Abhängigkeiten können ferner den Anweisungen 216, die zum Fahrzeug 102 gesandt werden, hinzugefügt werden. Auf Grundlage des regionalen Softwarebereitstellungsnetzwerks 204, das die durch die Bereichskennung 222 identifizierten Softwareupdates 220 bereitstellen soll, kann der Anweisungsersteller 224 die Downloadadressen in den Anweisungen 216 mit Netzwerkadressen bestücken, die durch Webserver 218 eines der regionalen Softwarebereitstellungsnetzwerke 204 in dem mit dem Fahrzeug 102 verknüpften Bereich versorgt werden.
Bei den Anweisungen 216 kann es sich um eine Datei oder eine andere Datenstruktur handeln, die konfiguriert ist, um Binärdateien oder andere Softwareupdates 220 zu identifizieren, die im Fahrzeug 102 installiert werden sollen. Die Anweisungen 216 können Netzwerkadressen vorgeben, an welchen jedes der vorgegebenen Softwareupdates 220 abgerufen werden kann. Als ein Beispiel können die Anweisungen 216 die Netzwerkadressen als Internetadresse (Universal Resource Locator – URL) vorgeben, welche durch Webserver 218 eines der regionalen Softwarebereitstellungsnetzwerke 204 in dem mit dem Fahrzeug 102 verknüpften Bereich 210 versorgt werden.
Die in den Anweisungen 216 definierten Netzwerkadressen können auf Grundlage des Bereichs 210, mit dem sie verknüpft sind, voneinander abweichen. In einem Beispiel können sich die Netzwerkadressen, die ein Update für eines der regionalen Softwarebereitstellungsnetzwerke 204 kennzeichnen, von Netzwerkadressen für das gleiche Update in einem anderen der regionalen Softwarebereitstellungsnetzwerke 204 unterscheiden. Zusätzlich können die Inhalte der Softwareupdatedateien, die von den regionalen Softwarebereitstellungsnetzwerken 204 bereitgestellt werden, auf Grundlage des Bereichs 210 variieren. In einem Beispiel können die Anweisungen 216 die Netzwerkadressen für bereichsspezifische Updatedateien beinhalten, die von Webservern 218 des einen der regionalen Softwarebereitstellungsnetzwerke 204 den mit dem Bereich 210 verknüpften Fahrzeugen 102 bereitgestellt werden.
Die bereichsspezifischen Updatedateien können u. a. Dateien beinhalten, die Anforderungen, Einschränkungen, Spezifikationen, Regulierungen und andere Eigenschaften, die für einen oder mehrere Bereiche 210 einzigartig sind, definieren. In einem Beispiel können die bereichsspezifischen Updatedateien Spezifikationen bezüglich eines oder mehrerer Aspekte von Betrieb, Besitz und/oder Aufbewahrung des Fahrzeugs 102 beinhalten, wie etwa u. a. Emissionen, Beleuchtung, Klimaanlage und Kraftstoffeffizienz. Als ein Beispiel kann es in bestimmten Bereichen 210 vorgeschrieben sein, dass die Innenbeleuchtung des Armaturenbretts auf ein Maximum gesetzt ist, während in anderen Bereichen 210 die Software eine Konfiguration der Lichtintensität durch den Benutzer anbieten kann. Als weiteres Beispiel kann es in bestimmten Bereichen 210 vorgeschrieben sein, dass die Fahrzeugscheinwerfer während des Betriebs der Scheibenwischer angeschaltet werden, während in anderen Bereichen 210 eine solche Anforderung nicht bestehen kann. Als noch weiteres Beispiel kann ein begrenzter Navigationsanzeigebetrieb bei geringen Geschwindigkeiten in bestimmten Bereichen 210 erlaubt sein, während in anderen Bereichen 210 vorgeschrieben sein kann, dass die Anzeige automatisch ausgeschaltet wird, wenn das Fahrzeug 102 aus dem PARK-Gang geschaltet wird.
3 veranschaulicht ein beispielhaftes Datenflussdiagramm 300, das die Aktualisierung einer mit dem Fahrzeug 102 verknüpften Bereichskennung auf Grundlage des Bereichs 210, in dem sich das Fahrzeug 102 befindet, veranschaulicht. In einem Beispiel kann der Datenfluss unter Verwendung eines Systems erfolgen, wie es beispielsweise in 2 veranschaulicht ist.
Bei Zeitindex (A) ruft die Rechnerplattform 104 Informationen bezüglich einer aktuellen Position des Fahrzeugs 102 ab. Der Bereichsprüfer 206 kann zum Beispiel geografische Koordinaten aus der GPS-Steuerung 146 abrufen, die eine Position des Fahrzeugs 102 bei jedem Zündungszyklus/Startereignis angeben. Bei Zeitindex (B) identifiziert die Rechnerplattform 104, welcher Bereich 210 der aktuellen Position des Fahrzeugs 102 entspricht. In einem Beispiel kann die Rechnerplattform 104 eine Auflistung von Bereichskennungen referenzieren, die in dem Speicher 108 gespeichert ist und mit einer Vielzahl von geografischen Koordinaten, die die Grenzen der Bereiche 210 identifizieren, beispielsweise mittels Geofence-GPS-Koordinaten, verbunden ist.
Bei Zeitindex (C) vergleicht die Rechnerplattform 104 die aktuelle Bereichskennung 230 mit der gespeicherten Bereichskennung 228, die im Datenspeicher gepflegt wird. Bei Zeitindex (D) sendet die Rechnerplattform 104 als Reaktion auf ein Bestimmen, bei Zeitindex (C), dass sich die aktuelle Bereichskennung 230 von der gespeicherten Bereichskennung 228 unterscheidet, eine Nachricht an den IVSU 202. In einem Beispiel kann der Bereichsprüfer 206 eine Nachricht, die die aktuelle Bereichskennung 230 beinhaltet, an den IVSU 202 senden, als Reaktion auf ein Bestimmen, bei Zeitindex (D), dass sich die aktuelle Bereichskennung 230 über einen vordefinierten Zeitraum oder eine vordefinierte Anzahl von Zündungszyklen/Startereignissen anhaltend von der gespeicherten Bereichskennung 228 unterscheidet. Bei Zeitindex (E) verknüpft der IVSU 202 die aktuelle Bereichskennung 230, die in der empfangenen Nachricht angegeben wird, mit dem Fahrzeug 102 im Datenspeicher.
Unter Bezugnahme auf 4 ist ein beispielhafter Datenfluss 400 gezeigt, der die Durchführung eines bereichsspezifischen Updates auf Grundlage einer mit dem Fahrzeug 102 verknüpften Bereichskennung veranschaulicht. Bei Zeitindex (A) sammelt die Rechnerplattform 104 Informationen bezüglich der Steuerungen des Fahrzeugs 102. Der Prozess der Datenerfassung kann als Abfrage und die erfassten Daten können als das Abfrageprotokoll 212 bezeichnet werden. In einem Beispiel kann ein Nutzer des Fahrzeugs 102 ein Herunterladen der Softwareupdates 220 über eine Eingabeaufforderung unmittelbar vor dem Herunterladen des Updates auswählen oder kann automatische Hardware- und Softwareupdates im Vorfeld autorisiert haben. Sobald sie autorisiert wurde (z. B. durch Empfang von Knopfdrücken oder Spracheingaben durch den Nutzer), kann die Rechnerplattform 104 konfiguriert sein, um Softwareupdates 220 für die Fahrzeugsteuerungen 148 abzufragen. Dieses Abfragen kann im Hintergrund erfolgen, ohne dass Benutzereingaben erforderlich sind.
Die Rechnerplattform 104 kann über die ODL-Datei 214 festlegen, welche Informationen erfasst werden sollen. Vor allem können die zu erfassenden Informationen Datenelemente von den Fahrzeugsteuerungen 148 oder anderen Steuerungen des Fahrzeugs 102 beinhalten und können über das Steuergerätenetzwerk (Controller Area Network – CAN) oder eine andere Kommunikationsarchitektur des Fahrzeugs 102, welche die Datenübertragung zwischen Steuerungen unterstützt, abgerufen werden. Die Informationen können ferner Diagnosecodes und andere Informationen zum Fahrzeugzustand beinhalten, welche während der Wartung des Fahrzeugs 102 durch einen Händler erfasst werden können. Die Informationen können ferner Analysedaten beinhalten, einschließlich Nutzungs- und Protokolldaten, welche Aufschluss über die Verwendung unterschiedlicher Fahrzeugfunktionen geben. In einigen Fällen kann die ODL-Datei 214 als Teil einer Softwareinstallation auf der Rechnerplattform 104 installiert sein, während die ODL-Datei 214 in anderen Fällen entsprechend früherer Updates im Vorfeld empfangen worden sein kann.
Bei Zeitindex (B) sendet die Rechnerplattform 104 eine Updateanforderung, z. B. sendet sie das Abfrageprotokoll 212 an den IVSU 202. In einem Beispiel kann die Rechnerplattform 104 das Abfrageprotokoll 212 über HTTPS an den IVSU 202 senden (z. B. durch Verbinden der Rechnerplattform 104 mit einer vordefinierten Internetadresse des IVSU 202, welche der Rechnerplattform 104 bekannt ist). Der IVSU 202 kann dementsprechend das Abfrageprotokoll 212 vom Netz empfangen.
Bei Zeitindex (C) bestimmt der IVSU 202 den mit dem Fahrzeug 102 verknüpften Bereich 210 auf Grundlage der aktuellen Bereichskennung 230, die im Datenspeicher in Verbindung mit einer Kennung des Fahrzeugs 102 gepflegt wird. Unter Verwendung der aktuellen Bereichskennung 230 und der RSDN-Daten 226 kann der Bereichsempfänger 222 des IVSU 202 bestimmen, welches regionale Softwarebereitstellungsnetzwerk 204 dem Fahrzeug 102 die Softwareupdates 220 zur Verfügung stellen soll.
Als Reaktion auf das Identifizieren des regionalen Softwarebereitstellungsnetzwerks 204 bestimmt der IVSU 202 die Softwareupdates 220 und erzeugt die Anweisungen 216 bei Zeitindex (D). Beim Erzeugen der Anweisungen 216 kann der Anweisungsersteller 224 des IVSU 202 die Downloadadressen in den Anweisungen 216 mit den bereichsspezifischen Netzwerkadressen für das regionale Softwarebereitstellungsnetzwerk 204, das den Bereich 210 versorgen soll, bestücken. In einem weiteren Beispiel kann der Anweisungsersteller 224 die Anweisungen 216 erzeugen, einschließlich der Netzwerkadressen für bereichsspezifische Updatedateien, die von den Webservern 218 des regionalen Softwarebereitstellungsnetzwerks 204 den Fahrzeugen 102 bereitgestellt werden, die mit der aktuellen Bereichskennung 230 verknüpft sind, welche den Bereich 210 definieren, in dem sich das Fahrzeug 102 nun befindet.
Durch Erzeugen der Anweisungen 216 kann der IVSU 202 ferner die aktuelle Steuerungskonfiguration und die aktuelle Version auf der Rechnerplattform 104 überprüfen und Binärdateien eines Softwareupdates 220 identifizieren, die zum Durchführen der identifizierten Updates auf dem Fahrzeug 102 installiert werden sollen. Diese Binärdateien können in den Anweisungen 216 identifiziert werden. Die Anweisungen 216 können ferner Netzwerkadressen vorgeben, an welchen jede der vorgegebenen Binärdateien des Updates abgerufen werden kann. Als ein Beispiel können die Anweisungen 216 die Netzwerkadressen als URL vorgeben, die durch einen Webserver 218 des IVSU 202 versorgt werden. In einigen Fällen können die Binärdateien neue Versionen von zu installierenden Dateien beinhalten, während die Binärdateien in anderen Fällen inkrementelle Updates beinhalten können, welche auf aktuell installierte Binärdateien angewendet werden können, um die aktuell installierten Binärdateien von einer Version auf die nächste Version zu aktualisieren.
Der IVSU 202 sendet die Anweisungen 216 bei Zeitindex (E) an das Fahrzeug 102. In einem Beispiel kann der IVSU 202 die Anweisungen 216 über HTTPS an das Fahrzeug 102 senden (z. B. über die HTTPS-Verbindung, an welche die Rechnerplattform 104 das Abfrageprotokoll 212 an die Rechnerplattform 104 gesendet hat, über eine andere Verbindung an dieselbe oder eine andere vordefinierte Internetadresse des IVSU 202, welche der Rechnerplattform 104 bekannt ist usw.). Nach dem Empfang kann die Rechnerplattform 104 konfiguriert sein, um die Softwareupdates 220, die von den Anweisungen 216 angegeben werden, zu installieren.
Auf Grundlage der Anweisungen 216 fordert die Rechnerplattform 104 bei Zeitindex (F) die Softwareupdates 220 (z. B. Konfigurationsdateien, Binärdateien usw.) von den Links an, welche durch die Anweisungen 216 vorgegeben sind. In einem Beispiel kann die Rechnerplattform 104 die Updates von bereichsspezifischen Netzwerkadressen für das regionale Softwarebereitstellungsnetzwerk 204, das den Bereich 210 versorgen soll, anfordern. In einem weiteren Beispiel kann die Rechnerplattform 104 die bereichsspezifischen Updatedateien von den durch die Anweisungen 216 vorgegebenen Links anfordern.
Die Rechnerplattform 104 kann dementsprechend die Softwareupdates 220 entsprechend der Darstellung bei Zeitindex (G) herunterladen. Als ein Beispiel können die Anweisungen 216 die Netzwerkadressen als URL vorgeben, die durch einen Webserver 218 des IVSU 202 versorgt werden, und kann die Rechnerplattform 104 das Softwareupdate 220 von den URL herunterladen, die durch die Anweisungen 216 vorgegeben sind. Da die Softwareupdates 220 durch den Webserver 218 über HTTPS bereitgestellt werden können, kann die Rechnerplattform 104 in der Lage sein, die Softwareupdates 220 unter Verwendung einer Fortsetzungsfunktion herunterzuladen, welche für Downloads von Webservern 218 verfügbar ist.
Bei Zeitindex (H) installiert die Rechnerplattform 104 die heruntergeladenen Softwareupdates 220. In einigen Beispielen kann die Rechnerplattform 104, um eine Unterbrechung der aktuell auf der Rechnerplattform 104 installierten Softwareversion zu vermeiden, konfiguriert sein, um die Installation auf einer zweiten Installation der Rechnerplattform 104 durchzuführen, bei der es sich nicht um die aktuell aktive Installation handelt, von der aus die Rechnerplattform 104 gestartet wurde. Das Installieren der Updates auf der zweiten Installation kann im Hintergrund erfolgen, ohne dass Benutzereingaben nötig sind.
Nach Abschluss der Installation der durch die Anweisungen 216 vorgegebenen Softwareupdates kann die Rechnerplattform 104 konfiguriert werden, um eine zusätzliche Abfrage der Steuerungen des Fahrzeugs 102 durchzuführen, um ein neues Abfrageprotokoll 212 zu erzeugen. Die Rechnerplattform 104 kann nachfolgend das Abfrageprotokoll 212 z. B. unter Verwendung der empfangenen ODL 214 erzeugen, wodurch eine aktualisierte Definition dahingehend bereitgestellt wird, welche Informationen für die aktuell durchgeführten Softwareupdates 220 abzufragen sind. Die Rechnerplattform 104 kann konfiguriert sein, um das Abfrageprotokoll 212 an den IVSU 202 zu senden, z. B. über HTTPS. Dementsprechend kann der IVSU 202 automatisch mit dem Installationsstatus des Fahrzeugs 102 aktualisiert werden, ohne das eine Interaktion des Nutzers mit der HMI erforderlich ist.
5 veranschaulicht ein beispielhaftes Verfahren 500 zum Aktualisieren von Software der Rechnerplattform 104 unter Verwendung eines regionalen Softwarebereitstellungsnetzwerkes 204. Das Verfahren 500 kann beispielsweise durch die Rechnerplattform 104 des Fahrzeugs 102 in Verbindung mit dem IVSU 202 und dem regionalen Softwarebereitstellungsnetzwerk 204 über das Netzwerk 156 erfolgen.
Bei Vorgang 502 ruft die Rechnerplattform 104 eine aktuelle Position des Fahrzeugs 102 ab. In einem Beispiel kann die Rechnerplattform 104 die aktuelle Position des Fahrzeugs 102 aus der GPS-Steuerung 146 und/oder einer oder mehreren der Fahrzeugsteuerungen 148 abrufen. In einem weiteren Beispiel kann die Rechnerplattform 104 die Position des Fahrzeugs 102 periodisch oder als Reaktion auf ein vordefiniertes Signal, z. B. bei jedem Zündungszyklus/Startereignis und/oder bei jeder vordefinierten Anzahl von Zündungszyklen/Startereignissen, abrufen. Die Rechnerplattform 104 bestimmt bei Vorgang 504, welchem der Bereiche 210 die Position des Fahrzeugs 102 entspricht. Die Rechnerplattform 104 kann die aktuelle Bereichskennung 230 auch durch Referenzieren einer Auflistung von Bereichskennungen, die in dem Speicher 108 gespeichert ist und mit einer Vielzahl von geografischen Koordinaten, die die Grenzen der Bereiche 210 identifizieren, beispielsweise mittels Geofence-GPS-Koordinaten, verbunden ist, bestimmen.
Bei Vorgang 506 bestimmt die Rechnerplattform 104, ob sich die aktuelle Bereichskennung 230, die dem Bereich 210, in dem sich das Fahrzeug 102 aktuell befindet, entspricht, von der gespeicherten Bereichskennung 228, die dem vorher bestimmten Bereich 210 entspricht, unterscheidet. Die Steuerung geht weiter zu Vorgang 502, bei dem die Rechnerplattform 104 eine Position des Fahrzeugs 102 abruft, als Reaktion auf das Bestimmen bei Vorgang 506, dass die aktuelle Bereichskennung 230, die dem Bereich 210 entspricht, die gleiche wie die gespeicherte Bereichskennung 228, die mit dem Fahrzeug 102 verknüpft ist, ist.
Die Rechnerplattform 104 sendet bei Vorgang 508 die aktuelle Bereichskennung 230 als Reaktion auf das Bestimmen bei Vorgang 506, dass sich die aktuelle Bereichskennung 230 von der gespeicherten Bereichskennung 228 unterscheidet, an den IVSU 202. In einem Beispiel kann die Rechnerplattform 104 die aktuelle Bereichskennung 230 als Reaktion darauf, dass sich die aktuelle Bereichskennung 230 andauernd von der gespeicherten Bereichskennung 228 über einen vordefinierten Zeitraum oder eine vordefinierte Anzahl von Zündungszyklen unterscheidet, senden. Nach Vorgang 508 geht die Steuerung zu Vorgang 502.
Unter Bezugnahme auf 6 ist ein beispielhaftes Verfahren 600 zum Aktualisieren einer mit dem Fahrzeug 102 verknüpften Bereichskennung in einem Datenspeicher des IVSU 202 veranschaulicht. Das Verfahren 600 kann beispielsweise durch den IVSU 202 in Verbindung mit dem Fahrzeug 102 und dem regionalen Softwarebereitstellungsnetzwerk 204 über das Netzwerk 156 erfolgen.
Bei Vorgang 602 empfängt der IVSU 202 eine Nachricht vom Fahrzeug 102, die die aktuelle Bereichskennung 230 angibt, die den Bereich 210, in dem sich das Fahrzeug 102 befindet, definiert. Bei Vorgang 604 verknüpft der IVSU 202 die empfangene Bereichskennung 230 mit dem Fahrzeug 102 zur Verwendung mit Updateanforderungen vom Fahrzeug102.
Bei Vorgang 606 bestimmt der IVSU 202, ob eine Anforderung nach Softwareupdates 220 von dem Fahrzeug 102 empfangen wurde. In einem Beispiel kann die Rechnerplattform 104 als Reaktion auf ein Bestimmen, dass ein Auslöser aufgetreten ist, um Softwareupdates 220 anzufordern, eine Anforderung nach den Softwareupdates 220 an den IVSU 202 senden. Beispielsweise kann die Rechnerplattform 104 nach dem Bestimmen, dass eine vorbestimmte Anzahl an Startzyklen durch das Fahrzeug 102 erreicht ist und/oder ein vorbestimmter Zeitraum abgelaufen ist, und ferner, dass eine Netzwerkverbindung zum Kommunizieren mit dem IVSU 202 verfügbar ist (z. B. über ein angeschlossenes Mobilgerät 152), bestimmen, dass das Fahrzeug 102 eine Prüfung auf Softwareupdates durchführen soll.
Wie vorher unter Bezugnahme auf zumindest 2 und 4 beschrieben, kann das Fahrzeug 102 das Abfrageprotokoll 212 in die Anforderung an den IVSU 202 nach den Softwareupdates 220 aufnehmen. Das Abfrageprotokoll 212 kann Versionsinformationen zumindest einer im Fahrzeug 102 installierten Softwaresteuerung beinhalten, sowie u. a. Bezeichnung der Steuerung, Seriennummer der Steuerung, Fahrgestellnummer, Hardwareteilenummer, MAC-Adresse, Teilenummern von Softwareanwendungen, Sprachen und Service-Packs, welche in der Steuerung installiert sind, verfügbarer Speicherplatz in der Steuerung und Statusinformationen hinsichtlich der Installation vorhergehender Updates. In manchen Fällen kann die Rechnerplattform 104 das Abfrageprotokoll 212 entsprechend einer ODL 214 erzeugen, die definiert, welche Informationen abzufragen sind und wo sich solche Informationen befinden können. Die Steuerung geht als Reaktion auf das Bestimmen durch den IVSU 202 bei Vorgang 606, dass keine Anforderung nach Softwareupdates 220 von dem Fahrzeug 102 empfangen wurden, weiter zu Vorgang 602.
Bei Vorgang 608 identifiziert der IVSU 202 eine mit dem Fahrzeug 102, das die Softwareupdates 220 angefordert hat, verknüpfte Bereichskennung. In einem Beispiel kann die IVSU 202 im Abfrageprotokoll 212 enthaltene Fahrzeuginformationen verwenden, wie zum Beispiel die VIN, um das Fahrzeug 102 in dem Datenspeicher zu lokalisieren. Der IVSU 202 kann ferner den Datenspeicher referenzieren, um eine mit dem Fahrzeug 102, das die Softwareupdates 220 angefordert hat, verknüpfte Bereichskennung zu identifizieren.
Der IVSU 202 stellt dem Fahrzeug 102 bei Vorgang 610 die Anweisungen 216 bereit. Die Anweisungen 216 können Informationen beinhalten, die auf Grundlage einer Bereichskennung des Bereichs 210, der mit dem Fahrzeug 102 verknüpft ist, identifizieren, welches der regionalen Softwarebereitstellungsnetzwerke 204 einem Fahrzeug 102 die Softwareupdates 220 zur Verfügung stellen soll. Die Anweisungen 216 können ferner ein oder mehrere durch das Fahrzeug 102 herunterzuladende und zu installierende Binärdateien angeben, sowie andere Informationen, die beim Durchführen des Updates zu verwenden sind, wie beispielsweise aktualisierte ODL 214 und/oder Schlüssel zum Entschlüsseln der herunterzuladenden und zu installierenden Binärdateien.
Die in den Anweisungen 216 definierten Netzwerkadressen können auf Grundlage des Bereichs 210, mit dem sie verknüpft sind, voneinander abweichen. In einem Beispiel können sich die Netzwerkadressen, die ein Update für eines der regionalen Softwarebereitstellungsnetzwerke 204 kennzeichnen, von Netzwerkadressen für das gleiche Update in einem anderen der regionalen Softwarebereitstellungsnetzwerke 204 unterscheiden. Zusätzlich können die Inhalte der Softwareupdatedateien, die von den regionalen Softwarebereitstellungsnetzwerken 204 bereitgestellt werden, auf Grundlage des Bereichs 210 variieren. In einem Beispiel können die Anweisungen 216 die Netzwerkadressen für bereichsspezifische Updatedateien beinhalten, die von Webservern 218 des einen der regionalen Softwarebereitstellungsnetzwerke 204 den mit dem Bereich 210 verknüpften Fahrzeugen 102 bereitgestellt werden. Nach Vorgang 610 geht die Steuerung zu Vorgang 602.
Als Reaktion auf den Empfang der Anweisungen 216 kann das Fahrzeug 102 die von den Anweisungen 216 festgelegten Softwareupdates 220 herunterladen, wie etwa durch Herunterladen der Softwareupdates 220 von dem Webserver 218 der durch die Anweisungen 216 festgelegten Netzwerkadressen des regionalen Softwarebereitstellungsnetzwerks 204. Nach Beenden des Herunterladens kann die Rechnerplattform 104 die Softwareupdates 220 installieren, etwa durch Ausführen oder anderweitigem Anwenden des Firmwareupdates an der installierten Firmwareversion, um die Firmwareversion zu aktualisieren. In einigen Fällen kann die Rechnerplattform 104 eine Nachricht an den IVSU 202 senden, um den IVSU 202 darauf hinzuweisen, dass die Installation der Softwareupdates 220 erfolgreich war oder fehlgeschlagen ist. Nach dem Empfang einer Nachricht, die ein erfolgreiches Softwareupdate angibt, kann der IVSU 202 seine Aufzeichnungen des installierten Konfigurationsstatus des Fahrzeugs 102 aktualisieren.
Die hier offenbarten Prozesse, Verfahren oder Algorithmen können an eine Verarbeitungsvorrichtung, Steuereinrichtung oder einen Computer, der eine beliebige vorhandene programmierbare elektronische Steuereinheit oder dedizierte elektronische Steuereinheit einschließen kann, bereitstellbar oder von diesen implementierbar sein. Ebenso können die Prozesse, Verfahren oder Algorithmen als Daten und Anweisungen, die von einer Steuereinrichtung oder einem Computer ausführbar sind, in vielen Formen gespeichert sein, darunter, ohne darauf beschränkt zu sein, Informationen, die dauerhaft auf nicht beschreibbaren Speichermedien wie etwa ROM-Vorrichtungen gespeichert sind, und Informationen, die in veränderbarer Weise auf beschreibbaren Medien wie etwa Disketten, Magnetbändern, CDs, RAM-Vorrichtungen und anderen magnetischen und optischen Medien gespeichert sind. Die Prozesse, Verfahren oder Algorithmen können auch in einem durch Software ausführbaren Objekt implementiert sein. Alternativ können die Prozesse, Verfahren oder Algorithmen ganz oder in Teilen mittels geeigneter Hardwarekomponenten verkörpert sein, etwa anwendungsspezifischer integrierter Schaltungen (ASICs), feldprogrammierbarer Gate-Arrays (FPGAs), Zustandsmaschinen, Steuereinrichtungen oder anderer Hardwarekomponenten oder Vorrichtungen oder einer Kombination aus Hardware-, Software- und Firmwarekomponenten.
Die in der Beschreibung verwendeten Ausdrücke sind vielmehr beschreibende Ausdrücke als einschränkende Ausdrücke, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Geist und Umfang der Offenbarung abzuweichen. Wie zuvor beschrieben, können die Merkmale verschiedener Ausführungsformen miteinander kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden, die unter Umständen nicht ausdrücklich beschrieben oder veranschaulicht sind. Obwohl verschiedene Ausführungsformen so beschrieben sein können, dass sie Vorteile bereitstellen oder gegenüber anderen Ausführungsformen oder Umsetzungen auf dem Stand der Technik in Bezug auf eine oder mehrere erwünschte Eigenschaften bevorzugt sind, wird ein durchschnittlicher Fachmann erkennen, dass ein oder mehrere Merkmale oder eine oder mehrere Eigenschaften in Frage gestellt werden können, um die gewünschten Gesamtattribute des Systems zu erreichen, welche von der konkreten Anwendung und Umsetzung abhängig sind. Zu diesen Attributen können gehören, ohne darauf beschränkt zu sein, Kosten, Festigkeit, Haltbarkeit, Kosten über die Lebensdauer hinweg, Marktgängigkeit, Erscheinungsbild, Verpackung, Größe, Wartbarkeit, Gewicht, Herstellbarkeit, Einfachheit der Montage usw. Ausführungsformen, die in Bezug auf eine oder mehrere Eigenschaften als weniger wünschenswert als andere Ausführungsformen oder Implementierungen des Stands der Technik beschrieben werden, liegen somit nicht außerhalb des Schutzumfangs der Offenbarung und können für bestimmte Anwendungen wünschenswert sein.

Claims

System, umfassend: einen Server, der konfiguriert ist, um: von einem Fahrzeug eine Nachricht zu empfangen, die einen geografischen Bereich angibt, in dem sich das Fahrzeug befindet, als Reaktion auf die Anwesenheit des Fahrzeugs in dem Bereich über einen vordefinierten Zeitraum; als Reaktion auf die Nachricht einen Datenspeicher zu aktualisieren, um das Fahrzeug mit dem Bereich zu verknüpfen, und als Reaktion auf eine Fahrzeuganforderung nach Softwareupdates auf Grundlage der Verknüpfung Softwareupdates anzugeben, die von einem regionalen Softwarebereitstellungsnetzwerk des Bereichs bereitgestellt werden.
System nach Anspruch 1, wobei der Server ferner konfiguriert ist, um den Datenspeicher zu aktualisieren, um das mit dem Bereich zu verknüpfende Fahrzeug auf Grundlage einer Fahrgestellnummer (VIN) des in der Nachricht enthaltenen Fahrzeugs zu identifizieren.
System nach Anspruch 1, wobei der Prozessor ferner konfiguriert ist, um: von einem Fahrzeug eine zweite Nachricht zu empfangen, die einen zweiten geografischen Bereich angibt, in dem sich das Fahrzeug befindet, als Reaktion auf die Anwesenheit des Fahrzeugs in dem zweiten Bereich über einen vordefinierten Zeitraum, wobei sich der zweite geografische Bereich von dem Bereich unterscheidet; und als Reaktion auf die zweite Nachricht den Datenspeicher zu aktualisieren, um das Fahrzeug mit dem zweiten geografischen Bereich anstatt dem Bereich zu verknüpfen.
System nach Anspruch 3, wobei der Server ferner konfiguriert ist, um als Reaktion auf eine zweite Fahrzeuganforderung nach Softwareupdates auf Grundlage der Verknüpfung Softwareupdates anzugeben, die von einem zweiten regionalen Softwarebereitstellungsnetzwerk des zweiten geografischen Bereichs bereitgestellt werden.
System nach Anspruch 1, wobei der Bereich einer politischen Begrenzung entspricht.
System, umfassend: einen Server, der konfiguriert ist, um: als Reaktion auf eine Anforderung von einem Fahrzeug, Softwareupdates bereitzustellen, einen mit dem Fahrzeug verknüpften geografischen Bereich und ein regionales Softwarebereitstellungsnetzwerk zu identifizieren, das Softwareupdates für Fahrzeuge innerhalb des Bereichs bereitstellt, und von dem regionalen Softwarebereitstellungsnetzwerk gehostete Adressen von Softwareupdates, die für Fahrzeuge innerhalb des Bereichs bestimmt sind, an das Fahrzeug zu senden.
System nach Anspruch 6, wobei der Server ferner konfiguriert ist, um als Reaktion auf das Empfangen einer Angabe eines neuen Bereichs, in dem sich das Fahrzeug befindet, den neuen Bereich mit dem Fahrzeug zu verknüpfen, und um als Reaktion auf die Fahrzeuganforderung nach Softwareupdates die von dem regionalen Softwarebereitstellungsnetzwerk, das mit dem neuen Bereich verknüpft ist, bereitgestellten Softwareupdates anzugeben.
System nach Anspruch 7, wobei die Angabe des neuen Bereichs als Reaktion darauf, dass sich das Fahrzeug über einen vordefinierten Zeitraum in dem neuen Bereich befindet, ausgegeben wird.
System für ein Fahrzeug, umfassend: eine Fahrzeugsteuerung, die konfiguriert ist, um: als Reaktion auf ein Bestimmen, auf Grundlage von Positionsinformationen, die von einem Positionsbestimmungssystem empfangen werden, dass sich das Fahrzeug für eine vordefinierte Vielzahl von Bereichsüberprüfungen in einem geografischen Bereich befindet, eine Angabe des Bereichs an einen Server zu senden, und als Reaktion auf das Empfangen von von einem regionalen Softwarebereitstellungsnetzwerk gehosteten Adressen von Softwareupdates, die für Fahrzeuge innerhalb des Bereichs bestimmt sind, von dem Server, eine Verbindung mit dem Netzwerk einzurichten und die Softwareupdates im Fahrzeug zu installieren.
System nach Anspruch 9, wobei die für die Fahrzeuge bestimmten Softwareupdates Updates für ein Beleuchtungssystem oder ein Telematiksystem beinhalten.
System nach Anspruch 9, wobei die Fahrzeugsteuerung ferner konfiguriert ist, um vor dem Senden der Angabe des Bereichs an den Server zu bestimmen, dass sich der Bereich von einem vorher bestimmten Bereich unterscheidet.
System nach Anspruch 11, wobei die Fahrzeugsteuerung ferner konfiguriert ist, um den vorher bestimmten Bereich mit der Angabe des Bereichs zu überschreiben.
System nach Anspruch 9, wobei die vordefinierte Vielzahl von Bereichsüberprüfungen eine vordefinierte Anzahl von Zündungszyklen beinhaltet.
System nach Anspruch 9, wobei die vordefinierte Vielzahl von Bereichsüberprüfungen eine vordefinierte Anzahl von periodischen Positionsüberprüfungen beinhaltet.
System nach Anspruch 9, wobei die Fahrzeugsteuerung ferner konfiguriert ist, um die Angabe des Bereichs, in dem sich das Fahrzeug befindet, als Reaktion auf ein Fahrzeugstartereignis zu senden.