DE102018220976A1

DE102018220976A1 - Konfigurieren eines fahrzeugsoftware-updates

Info

Publication number: DE102018220976A1
Application number: DE102018220976.6A
Authority: DE
Inventors: Orla Murphy
Original assignee: Jaguar Land Rover Ltd
Current assignee: Jaguar Land Rover Ltd
Priority date: 2017-12-05
Filing date: 2018-12-04
Publication date: 2019-06-06
Also published as: GB2569112A; GB2569112B; GB201720200D0

Abstract

Fahrzeugsoftware-Update-System, wobei das System Folgendes umfasst:
Mittel zur Bestimmung (302), dass ein OTA-Software-Update eines Fahrzeugs (12) erforderlich ist;
Mittel zur Bestimmung (304) eines ersten Parameters;
Mittel zum Vergleich (312) des ersten Parameters mit einer ersten Anforderung;
Mittel zur Bestimmung (314), in Abhängigkeit von dem Vergleich, einer ersten Einschränkung; und
Mittel zur Konfigurierung (316), in Abhängigkeit von der ersten Einschränkung, eines Downloads des OTA-Software-Updates.

Description

TECHNISCHES GEBIET
Die vorliegende Offenbarung bezieht sich auf das Konfigurieren eines Fahrzeugsoftware-Updates. Insbesondere, aber nicht ausschließlich, bezieht sie sich auf das Konfigurieren eines OTA (over-the-air)-Fahrzeugsoftware-Updates.
Aspekte der Erfindung betreffen ein Fahrzeug, ein System, einen Client, einen Server, Verfahren und Computerprogramme.
STAND DER TECHNIK
Ein OTA-Software-Update (OTA) wird auch als Software-OTA-Update (SOTA) bezeichnet. SOTA ist ein Begriff, der das Herunterladen und Installieren von Softwarekomponenten für ein System ohne Verwendung einer Kabelverbindung umfasst. Softwarekomponenten für SOTA-Updates können ausführbaren Code, Konfigurationsdaten, Grafiken, Karten, Audiokalibrierung, Multimedien sowie Firmware umfassen.
Ein SOTA-fähiges System stellt die Flexibilität für zukünftige Software-Implementierungen des Original Equipment Manufacturer (OEM) eines Fahrzeugs sicher, um beispielsweise neue Softwarefunktionen zu integrieren.
Wenn sich ein Fahrzeug in einer Situation befindet, in der die OTA-Verbindung schlecht ist, schlägt der Download möglicherweise fehl oder dauert inakzeptabel lange Zeit. Bei einem fehlgeschlagenen Download fallen Energie- und Finanzkosten an, wenn der Download erneut versucht werden muss oder das Fahrzeug für ein manuelles Software-Update zu einem Händler gebracht werden muss.
Die vorliegende Erfindung zielt darauf ab, die Nachteile des Stands der Technik zu beheben.
KURZDARSTELLUNG DER ERFINDUNG
Erfindungsgemäße Aspekte und Ausführungsformen stellen ein System, ein Fahrzeug, einen Client, einen Server, Verfahren und Computersoftware bereit, wie in den beigefügten Ansprüchen beansprucht.
Gemäß einem Aspekt der Erfindung wird ein Fahrzeugsoftware-Updatesystem bereitgestellt, wobei das System Folgendes umfasst: Mittel zum Bestimmen, dass ein OTA-Software-Update eines Fahrzeugs erforderlich ist; Mittel zur Bestimmung eines ersten Parameters; Mittel zum Vergleich des ersten Parameters mit einer ersten Anforderung; Mittel zur Bestimmung, in Abhängigkeit zum Vergleich, einer ersten Einschränkung; und Mittel zur Konfigurierung, in Abhängigkeit zu der ersten Einschränkung, eines Downloads über das OTA-Software-Update.
Dies bietet den Vorteil eines effizienteren Systems. Dies ist darauf zurückzuführen, dass die Anzahl der fehlgeschlagenen Download-Versuche reduziert wird, da der Download wahrscheinlich beim ersten Mal funktioniert. In einigen Beispielen besteht der Vorteil darin, dass die Entscheidung zum Senden von Software eine fundierte Entscheidung zum Senden von Software ist, basierend auf den Parametern und Bedingungen des Fahrzeugs.
Gemäß einem weiteren Aspekt der Erfindung wird ein Fahrzeugsoftware-Update-System wie oben beschrieben bereitgestellt, wobei das System einen Fahrzeugsoftware-Update-Client und einen Fahrzeugsoftware-Update-Server umfasst, wobei jeder aus Fahrzeugsoftware-Update-Client und Fahrzeugsoftware-Update-Server mindestens einen elektronischen Prozessor umfasst; und wobei mindestens eine elektronische Speichervorrichtung elektrisch mit dem elektronischen Prozessor gekoppelt ist und Anweisungen darauf gespeichert hat, wobei die jeweiligen elektronischen Speichervorrichtungen und die Anweisungen konfiguriert sind, um mit den jeweiligen elektronischen Prozessoren das Fahrzeugsoftware-Update-System zu Folgendem zu konfigurieren:

bei dem Fahrzeugsoftware-Update-Client, dem Fahrzeugsoftware-Update-Server, oder einer Kombination davon, Bestimmen, dass ein OTA-Software-Update eines Fahrzeugs erforderlich ist;
bei dem Fahrzeugsoftware-Update-Client, Bestimmen eines ersten Parameters;
bei dem Fahrzeugsoftware-Update-Server, Vergleichen des ersten Parameters mit einer ersten Anforderung;
bei dem Fahrzeugsoftware-Update-Server, in Abhängigkeit von dem Vergleich, Bestimmen einer ersten Einschränkung; und
bei dem Fahrzeugsoftware-Update-Server, in Abhängigkeit von der ersten Einschränkung, Konfigurieren eines Downloads des OTA-Software-Updates.

In einigen Beispielen wird der erste Parameter automatisch ermittelt.
Dies bietet den Vorteil einer minimalen Benutzerstörung, insbesondere für Push-Updates, die nicht von einem Fahrzeugbenutzer angefordert werden.
In einigen Beispielen wird der erste Parameter am Fahrzeug bestimmt.
Dies bietet den Vorteil des Ausgleichs einer mangelnden Verfügbarkeit nützlicher Informationen (z. B. Netzwerkverkehr, Funkstörungen), die ein Netzwerkbesitzer wie zum Beispiel ein Mobilfunknetzbetreiber besitzt. Einige dem Fahrzeug bekannte Informationen können gut mit der Erfolgswahrscheinlichkeit des Downloads korrelieren.
In einigen Beispielen gibt der erste Parameter Umgebungsinformationen an. In einigen Beispielen weisen die Umgebungsinformationen auf Klimainformationen hin. In einigen Beispielen geben die Umgebungsinformationen Standortinformationen an. In einigen Beispielen gibt der erste Parameter Informationen zur Fahrzeugnutzung an.
Dies bietet den Vorteil, dass einige Informationen, die dem Fahrzeug bereits für andere Zwecke bekannt sind, wie etwa Infotainment, mit Funkrauschen korrelieren, das die Erfolgswahrscheinlichkeit des Downloads beeinflusst. Zum Beispiel wird das Funkrauschen durch Umwelteinflüsse (Atmosphäre) wie Niederschlag, Gewitter, Lufttemperatur oder Druck erhöht.
In einigen Beispielen gibt der erste Parameter die am Fahrzeug und/oder am Netzwerk gemessene Signalstärke an.
In einigen Beispielen gibt der erste Parameter Informationen über die Verfügbarkeit von Downloadressourcen an, die die Verfügbarkeit von Ressourcen am Fahrzeug für den Download anzeigen. In einigen Beispielen geben die Informationen zur Verfügbarkeit der Downloadressourcen eine der folgenden Informationen an: Verarbeitungsverfügbarkeit, Speicherverfügbarkeit; Verfügbarkeit der Bandweite. In einigen Beispielen gibt der erste Parameter eine Abonnementeinschränkung an.
Dies bietet den Vorteil, dass Informationen, die die Erfolgswahrscheinlichkeit des Herunterladens aus anderen Gründen als Funkstörungen beeinflussen, berücksichtigt werden.
In einigen Beispielen ist die erste Anforderung ein Schwellenwert.
Dies bietet den Vorteil, dass kontinuierliche Größen wie die Temperatur bewertet werden können.
In einigen Beispielen beeinflusst die erste Einschränkung die Zeit des Beginns des Downloads, das Unterteilen des Downloads in separate kleinere Downloads oder den Ort des Beginns des Downloads.
Dies bietet den Vorteil, dass der Download so konfiguriert werden kann, dass er zu Zeiten (z. B. außerhalb der Spitzenzeiten) und/oder an Orten (z. B. Zellen mit hoher Bandbreite und/oder geringem Datenverkehr) beginnt, wenn zu erwarten ist, dass der Download wahrscheinlich erfolgreich verläuft.
In einigen Beispielen wird das OTA-Software-Update vom Server gepusht oder vom Fahrzeug abgerufen.
In einigen Beispielen ist das OTA-Software-Update, das heruntergeladen werden soll, in einem komprimierten Delta-Format konfiguriert.
Dies bietet den Vorteil, dass die Dateigröße reduziert und die Sicherheit stark erhöht wird, da es sich bei der übertragenen Delta-Komponente nicht um einen eigenständigen Abschnitt der Software handelt, sondern um einen Überblick über Änderungen an der vorhandenen Software.
Bei einigen Beispielen umfasst das System Mittel zur Übertragung eines Signals an eine Ausgabevorrichtung, damit die Ausgabevorrichtung eine Ausgabe in Abhängigkeit von einem oder mehreren Fehlern beim Abschluss des Downloads zur Verfügung stellt.
Dies bietet den Vorteil, dass der Fahrzeugbenutzer (Ausgabevorrichtung im Fahrzeug) oder der OEM-Mitarbeiter (Ausgabevorrichtung beim OEM) alarmiert wird und einen Händlerbesuch planen kann, um das Softwareupdate ohne OTA-Download zu laden.
In einigen Beispielen umfasst das System Mittel zum Bestimmen eines Installationsparameters und Mittel zum Konfigurieren einer Installation des OTA-Software-Updates in Abhängigkeit von dem Installationsparameter. In einigen Beispielen gibt der Installationsparameter an, ob sich das Fahrzeug in einem Schlüssel-Aus-Zustand befindet und/oder wie lange es sich in diesem befindet. In einigen Beispielen gibt der Installationsparameter Informationen zur Verfügbarkeit der Installationsressourcen an, die die Ressourcenverfügbarkeit im Fahrzeug für die Installation anzeigen. In einigen Beispielen geben die Informationen zur Verfügbarkeit der Installationsressourcen eine der folgenden Informationen an: Verarbeitungsverfügbarkeit; Speicherverfügbarkeit; Verfügbarkeit der elektrischen Energie am Fahrzeug.
Dies bietet den Vorteil der Minimierung einer Störung für einen Fahrzeugbenutzer, beispielsweise wenn das Fahrzeug während des Installationsvorgangs nicht gefahren werden kann oder die Installation eine Fahrzeugbatterie erschöpfen kann.
In einigen Beispielen umfasst das System einen Fahrzeugsoftware-Update-Server und einen Fahrzeugsoftware-Update-Client eines Fahrzeugs, wobei der Download vom Fahrzeugsoftware-Update-Server zum Fahrzeugsoftware-Update-Client erfolgt.
Dies bietet den Vorteil einer erhöhten Sicherheit, da das Fahrzeug als Client und nicht als Server konfiguriert ist.
In einigen Beispielen ist das Mittel zum Bestimmen, dass ein OTA-Software-Update eines Fahrzeugs erforderlich ist, in dem Fahrzeugsoftware-Update-Server und/oder dem Fahrzeugsoftware-Update-Client enthalten, wobei das Mittel zum Bestimmen eines ersten Parameters in dem Fahrzeugsoftware-Update-Client enthalten ist, wobei das Mittel zum Vergleichen des ersten Parameters mit einer ersten Anforderung in dem Fahrzeugsoftware-Update-Server enthalten ist, wobei das Mittel in Abhängigkeit von dem Vergleich bestimmt, dass eine erste Einschränkung im Fahrzeugsoftware-Update-Server enthalten ist, und das Mittel zum Konfigurieren des Herunterladens des OTA-Software-Updates in Abhängigkeit von der ersten Bedingung in dem Fahrzeugsoftware-Update-Server enthalten ist.
In einigen Beispielen umfasst der erste Parameter Fahrtinformationen, die erste Anforderung umfasst eine Anforderung, dass sich das Fahrzeug in einem vordefinierten Gebiet befindet, das von einer Route gemäß den Fahrtinformationen durchschnitten wird, und die erste Einschränkung erfordert, dass der Download beginnt, wenn das Fahrzeug in den vorbestimmten Bereich einfährt.
Dies bietet den Vorteil, dass der vordefinierte Bereich mit einer hohen Erfolgswahrscheinlichkeit verbunden ist (z. B. gutem Signalempfang) und daher eine Ausfallwahrscheinlichkeit niedriger ist.
Gemäß einem weiteren Aspekt der Erfindung wird ein Fahrzeugsoftware-Update-Verfahren bereitgestellt, wobei das Verfahren Folgendes umfasst: Bestimmen, dass ein OTA-Software-Update eines Fahrzeugs erforderlich ist; Bestimmen eines ersten Parameters; Vergleichen des ersten Parameters mit einer ersten Anforderung; Bestimmen einer ersten Bedingung in Abhängigkeit von dem Vergleich; und Konfigurieren, in Abhängigkeit von der ersten Einschränkung, eines Downloads des OTA-Software-Updates.
Gemäß einem weiteren Aspekt der Erfindung wird ein Computerprogramm bereitgestellt, das, wenn es auf mindestens einem elektronischen Prozessor ausgeführt wird, Folgendes bewirkt: Bestimmen, dass ein OTA-Software-Update eines Fahrzeugs erforderlich ist; Bestimmen eines ersten Parameters; Vergleichen des ersten Parameters mit einer ersten Anforderung; Bestimmen einer ersten Bedingung in Abhängigkeit von dem Vergleich; und Konfigurieren, in Abhängigkeit von der ersten Einschränkung, eines Downloads des OTA-Software-Updates. Das Computerprogramm kann eine nicht-transiente materielle physische Entität sein, die ein Computerprogramm mit Computerprogrammanweisungen enthält.
Gemäß einem weiteren Aspekt der Erfindung wird ein Fahrzeugsoftware-Update-Client bereitgestellt, der Folgendes umfasst: Mittel zum Bestimmen, dass ein OTA-Software-Update eines Fahrzeugs erforderlich ist; Mittel zur Bestimmung eines ersten Parameters; und Mittel zum Übertragen des ersten Parameters an einen Fahrzeugsoftware-Update-Server, um einen Vergleich des ersten Parameters mit einer ersten Anforderung, eine Bestimmung einer ersten Einschränkung in Abhängigkeit von dem Vergleich, und eine Konfiguration eines Downloads des OTA-Software-Updates, das in Abhängigkeit von der ersten Einschränkung konfiguriert wurde, zu beeinflussen.
Gemäß einem weiteren erfindungsgemäßen Aspekt wird ein Fahrzeugsoftware-Update-Client wie obenstehend beschrieben bereit gestellt, wobei
der Fahrzeugsoftware-Update-Client einen elektronischen Prozessor mit einem oder mehreren elektrischen Eingängen zum Bestimmen des ersten Parameters; und eine elektronische Speichervorrichtung, die elektrisch mit dem elektronischen Prozessor gekoppelt ist und darin Computerprogrammanweisungen gespeichert hat, umfasst,
wobei das Mittel zum Bestimmen, dass ein OTA-Software-Update eines Fahrzeugs notwendig ist, das Mittel zum Bestimmen eines ersten Parameters und das Mittel zum Übertragen des ersten Parameters an einen Fahrzeugsoftware-Update-Server, um einen Vergleich des ersten Parameters mit einer ersten Anforderung, eine Bestimmung einer ersten Einschränkung in Abhängigkeit von dem Vergleich und eine Konfiguration eines Herunterladens des OTA-Software-Updates, das in Abhängigkeit von der ersten Bedingung konfiguriert ist, zu beeinflussen, umfasst, dass der Prozessor derart konfiguriert ist, dass er auf die Speichervorrichtung zugreift und die darin gespeicherten Anweisungen ausführt, so dass der Fahrzeugsoftware-Update-Client bestimmt, dass ein OTA-Software-Update eines Fahrzeugs erforderlich ist, den ersten Parameter bestimmt und den ersten Parameter an den Fahrzeugsoftware-Update-Server übermittelt, um den Vergleich, die Bestimmung der ersten Einschränkung, und die Konfiguration zu beeinflussen.
Gemäß einem weiteren erfindungsgemäßen Aspekt wird eine Telematikeinheit bereitgestellt, welche den Fahrzeugsoftware-Update-Client umfasst.
Gemäß einem weiteren erfindungsgemäßen Aspekt wird ein Fahrzeug bereitgestellt, welches den Fahrzeugsoftware-Update-Client oder die Telematikeinheit umfasst.
Gemäß einem weiteren Aspekt der Erfindung wird ein Software-Update-Verfahren für ein Client-Endfahrzeug bereitgestellt, umfassend: Bestimmen, dass ein drahtloses Software-Update eines Fahrzeugs erforderlich ist; Bestimmen eines ersten Parameters; und Übertragen des ersten Parameters an einen Fahrzeugsoftware-Update-Server, um einen Vergleich des ersten Parameters mit einer ersten Anforderung, eine Bestimmung einer ersten Einschränkung in Abhängigkeit von dem Vergleich, und eine Konfiguration eines Downloads des OTA-Software-Updates in Abhängigkeit von der ersten Bedingung zu beeinflussen.
Gemäß einem weiteren Aspekt der Erfindung wird ein Client-Endcomputer-Programm bereitgestellt, das, wenn es auf wenigstens einem elektronischen Prozessor ausgeführt wird, Folgendes bewirkt: Bestimmen, dass ein OTA-Software-Update eines Fahrzeugs erforderlich ist; Bestimmen eines ersten Parameters; und Übertragen des ersten Parameters an einen Fahrzeugsoftware-Update-Server, um einen Vergleich des ersten Parameters mit einer ersten Anforderung, eine Bestimmung einer ersten Einschränkung in Abhängigkeit von dem Vergleich, und eine Konfiguration eines Downloads des OTA-Software-Updates in Abhängigkeit von der ersten Einschränkung zu beeinflussen.
Gemäß einem weiteren Aspekt der Erfindung wird ein Fahrzeugsoftware-Update-Server bereitgestellt, der Folgendes umfasst: Mittel zum Bestimmen, dass ein OTA-Software-Update eines Fahrzeugs erforderlich ist; Mittel zum Empfangen eines ersten Parameters von einem Fahrzeugsoftware-Aktualisierungsclient; Mittel, den ersten Parameter mit einer ersten Anforderung zu vergleichen; Mittel, um in Abhängigkeit von dem Vergleich eine erste Einschränkung zu bestimmen; und Mittel, um in Abhängigkeit von der ersten Einschränkung einen Download des OTA-Software-Updates zu konfigurieren.
Gemäß einem weiteren erfindungsgemäßen Aspekt wird ein Fahrzeugsoftware-Update-Server wie obenstehend beschrieben bereit gestellt, wobei
der Fahrzeugsoftware-Update-Server einen elektronischen Prozessor mit einem oder mehreren elektrischen Eingängen zum Empfangen des ersten Parameters; und eine elektronische Speichervorrichtung, die elektrisch mit dem elektronischen Prozessor gekoppelt ist und darin Computerprogrammanweisungen gespeichert hat, umfasst,
wobei das Mittel zum Bestimmen, dass ein OTA-Software-Update eines Fahrzeugs erforderlich ist, das Mittel zum Empfangen eines ersten Parameters von einem Fahrzeugsoftware-Update-Client, das Mittel zum Vergleichen des ersten Parameters mit einer ersten Anforderung, das Mittel um, in Abhängigkeit von dem Vergleich, eine erste Einschränkung zu bestimmen, und das Mittel um, in Abhängigkeit von der ersten Einschränkung, einen Download des OTA-Software-Updates zu konfigurieren, umfasst, dass der Prozessor derart konfiguriert ist, dass er auf die Speichervorrichtung zugreift und die darin gespeicherten Anweisungen ausführt, so dass der Fahrzeugsoftware-Update-Server bestimmt, dass eine OTA-Softwareaktualisierung eines Fahrzeugs erforderlich ist, den ersten Parameter empfängt und den Vergleich, die Bestimmung der ersten Einschränkung und die Konfiguration vornimmt.
Gemäß einem weiteren Aspekt der Erfindung wird ein Server-End-Fahrzeug-Software-Update-Verfahren bereitgestellt, das Folgendes umfasst: Bestimmen, dass ein OTA-Software-Update eines Fahrzeugs erforderlich ist; Empfangen eines ersten Parameters von einem Fahrzeugsoftware-Update-Client; Vergleichen des ersten Parameters mit einer ersten Anforderung; Bestimmen einer ersten Einschränkung in Abhängigkeit von dem Vergleich; und Konfigurieren, in Abhängigkeit von der ersten Einschränkung, eines Downloads des OTA-Software-Updates.
Gemäß einem weiteren Aspekt der Erfindung wird ein Server-End-Computerprogramm bereitgestellt, das, wenn es auf mindestens einem elektronischen Prozessor ausgeführt wird, Folgendes bewirkt: Feststellen, dass ein OTA-Software-Update eines Fahrzeugs erforderlich ist; Empfangen eines ersten Parameters von einem Fahrzeugsoftware-Update-Client; Vergleichen des ersten Parameters mit einer ersten Anforderung; Bestimmen einer ersten Einschränkung in Abhängigkeit von dem Vergleich; und Konfigurieren, in Abhängigkeit von der ersten Einschränkung, eines Downloads des OTA-Software-Updates. Das Computerprogramm kann eine nicht-transientes materielle physische Entität sein, die ein Computerprogramm mit Computerprogrammanweisungen enthält.
Gemäß einem weiteren Aspekt der Erfindung wird ein System bereitgestellt, das dazu eingerichtet ist, einen Download des OTA-Software-Updates in Abhängigkeit von einem ersten Parameter zu konfigurieren. Der erste Parameter kann an einem Fahrzeug bestimmt werden.
Innerhalb des Umfangs dieser Anmeldung wird ausdrücklich beabsichtigt, dass die verschiedenen Aspekte, Ausführungsformen, Beispiele und Alternativen, die in den vorhergehenden Absätzen, in den Ansprüchen und/oder in der folgenden Beschreibung und den Zeichnungen dargestellt werden, und insbesondere deren individuellen Merkmale, unabhängig voneinander oder in einer beliebigen Kombination berücksichtigt werden können. Dies bedeutet, dass alle Ausführungsformen und/oder Merkmale einer beliebigen Ausführungsform auf beliebige Art und/oder beliebige Kombination kombiniert werden können, sofern diese Merkmale nicht inkompatibel sind. Der Anmelder behält sich das Recht vor, jeden beliebigen ursprünglich eingereichten Patentanspruch zu ändern oder einen beliebigen neuen Patentanspruch entsprechend einzureichen, einschließlich des Rechts, jeden beliebigen ursprünglich eingereichten Patentanspruch zu verändern, um von einem beliebigen Merkmal eines beliebigen anderen Patentanspruchs abzuhängen und/oder dieses zu integrieren, obwohl es auf diese Art und Weise zuvor nicht beansprucht wurde.
Figurenliste
Eine oder mehrere erfindungsgemäße Ausführungsformen werden nun ausschließlich beispielhaft unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben; wobei:

1 ein Netzwerkdiagramm darstellt, das ein beispielhaftes Fahrzeugsoftware-Update-System enthält;
2A eine beispielhafte Steuervorrichtung darstellt
2B ein beispielhaftes computerlesbares Speichermedium darstellt;
3 ein Beispiel eines Fahrzeugsoftware-Update-Verfahrens darstellt;
4 ein Beispiel eines fehlerhaften Verfahrens darstellt; und
5 eine beispielhafte Installationsmethode darstellt.

DETAILLIERTE BESCHREIBUNG
1 ist ein Computernetzdiagramm.
Das Computernetzdiagramm zeigt zunächst ein Fahrzeug 12. In einigen, jedoch nicht zwingend in allen Beispielen ist das Fahrzeug 12 ein Personenkraftwagen, das auch als PKW oder Automobil bezeichnet wird. Pkw haben in der Regel ein Leergewicht von weniger als 5000 kg. In anderen Beispielen können Ausführungsformen der Erfindung für andere Anwendungen, wie z.B. für Industriefahrzeuge, Luft- oder Wasserfahrzeuge, eingesetzt werden.
In 1, jedoch nicht notwendigerweise in allen Beispielen, umfasst das Fahrzeug 12 eine Ausgabevorrichtung 18. Beispielsweise kann die Ausgabevorrichtung 18 eine Ausgabevorrichtung eines Infotainment-Untersystems sein.
Das Fahrzeug 12 umfasst ein Telematik-Untersystem 10. Das Telematik-Untersystem 10 umfasst eine Steuerung 16. Die Steuerung kann eine Telematiksteuereinheit (TCU) sein. Die Steuerung 16 ist so konfiguriert, dass sie als Fahrzeugsoftware-Update-Client fungiert (so dass die Steuerung austauschbar als „Client“ im Zusammenhang mit Downloads bezeichnet wird). Das Telematik-Untersystem umfasst eine clientseitige Antennenanordnung 14. Die clientseitige Antennenanordnung 14 kann als Empfänger, Sender oder als Transceiver ausgebildet sein.
In anderen Beispielen kann das die Steuerung 16 umfassende Untersystem ein anderes Untersystem als ein Telematik-Untersystem 10 sein.
Das Computernetzdiagramm zeigt einen Fahrzeugsoftware-Update-Server 20 (abgekürzt als „Server“ bezeichnet). Der Server 20 kann von einem OEM oder einer dritten Partei gesteuert werden.
Der Client 16 und der Server 20 können zusammen als ein Fahrzeugsoftware-Update-System 1 (abgekürzt „System“) angesehen werden.
Das Computernetzdiagramm veranschaulicht, dass der Client 16 über ein Netzwerk 30 mit dem Server 20 kommunizieren kann. Das Netzwerk 30 ist ein Kommunikationsnetzwerk.
Das Netzwerk 30 umfasst eine netzseitige Antennenanordnung 40 zur drahtlosen OTA-Kommunikation mit der clientseitigen Antennenanordnung 14.
Das Netzwerk 30 kann ein Mobilfunknetz umfassen. Die netzseitige Antennenanordnung 40 kann in einer Basistransceiverstation (BTS) implementiert sein. Das Netzwerk 30 ist ein Mobilfunknetz, weil die Kommunikationsverbindung zwischen dem Endbenutzer (Client 16) und dem Netzwerk 30 eine drahtlose OTA-Verbindung ist. In diesem Beispiel umfasst das Fahrzeug 12 die notwendigen Systeme (nicht gezeigt) für die Zellularnetzkompatibilität, einschließlich, aber nicht beschränkt auf ein Teilnehmeridentitätsmodul (subscriber identity module, SIM) oder ähnliches, das einer internationalen Mobilfunkteilnehmeridentität (international mobile subscriber identity, IMSI) oder ähnlichem zugewiesen ist. Das Mobilfunknetz gehört einem Mobilfunknetzbetreiber (mobile network operator, MNO) und/oder wird von diesem verwaltet.
In einigen, aber nicht notwendigerweise allen Beispielen, implementiert das zellulare Netzwerk mindestens eines von: 3G; 4G; vorgeschlagenes 5G oder eine andere gleichwertige Alternative.
In anderen Beispielen ist das Netzwerk 30 eine andere Form eines Netzwerks, wie etwa ein drahtloses lokales Netzgebiet oder ein drahtloses persönliches Netzwerk, wobei Verweise auf eine BTS Verweise auf den äquivalenten Endknoten sind, wie beispielsweise einen Router/Zugangspunkt.
Details der Kommunikationsverbindung in 1 sind vereinfacht. Zum Beispiel wird die vollständige Topologie des zellularen Netzwerks und jedes andere dazwischenliegende Kommunikationsnetzwerk(e) zwischen der netzseitigen Antennenanordnung und dem Server 20 der Übersichtlichkeit halber weggelassen und durch die Cloud 32 dargestellt.
Die gesamte, hier beschriebene Client-Server-Kommunikation erfolgt über das Netzwerk 30, sofern nicht anders angegeben.
2A zeigt eine beispielhafte Implementierung einer Steuervorrichtung 16. Die Steuerung 16 umfasst mindestens einen elektronischen Prozessor 202 und mindestens eine elektronische Speichervorrichtung 204, in der Computerprogrammanweisungen 206 (abgekürzt als „Computerprogramm“) gespeichert sind. Mindestens eine Steuerung 16 mit der in 2A gezeigten Architektur ist in dem Fahrzeug 12 enthalten und fungiert als Client 16. Mindestens eine Steuerung 20 mit der in 2A gezeigten Architektur fungiert als Server 20.
2B veranschaulicht ein Beispiel eines computerlesbaren Speichermediums 208, in dem das Computerprogramm gespeichert ist. Es können separate Computerprogramme und/oder computerlesbare Speichermedien bereitgestellt werden, um clientseitige und serverseitige Funktionalität zu implementieren.
Die Funktionalität des Systems 1 wird nun unter Bezugnahme auf ein Fahrzeugsoftware-Update-Verfahren 300 beschrieben, wie in 3 dargestellt. Aspekte des Verfahrens 300 werden von der Steuerung (Client) 16 ausgeführt. In einigen Beispielen werden einige Aspekte des Verfahrens 300 vom Server 20 ausgeführt.
Das Verfahren beginnt bei Block 302. Bei Block 302 wird bestimmt, dass ein SOTA-Update des Fahrzeugs 12 erforderlich ist. Dies kann eine Server-Push-Anforderung („Push“) sein, bei der das Unternehmen entscheidet, aktualisierte Software zu pushen. Oder es könnte eine Client-Pull-Anforderung („Pull“) sein, bei der der Fahrer des Fahrzeugs neue Software oder eine neue Funktion anfordert.
Wenn das SOTA-Update ein Push ist, kann der Block 302 in Abhängigkeit von der Eingabe des Administrators zuerst am Server 20 bestimmt werden. Der Server 20 überträgt dann Informationen an den Client 16, damit der Block 302 auch am Client 16 bestimmt werden kann.
Wenn die SOTA-Aktualisierung ein Pull ist, kann der Block 302 zuerst in Abhängigkeit von einer automatischen Bestimmung oder einer Benutzereingabe in eine Eingabevorrichtung (nicht gezeigt), die dem Fahrzeug 12 zugeordnet ist, am Client 16 bestimmt werden. Der Client 16 überträgt dann Informationen an den Server 20, damit der Block 302 auch am Server 20 bestimmt werden kann.
Das Verfahren fährt mit Block 304 fort. Bei Block 304 wird ein erster Parameter bestimmt. In einigen, aber nicht unbedingt allen Beispielen, wird Block 304 am Client 16 ausgeführt.
Die folgende Beschreibung bezieht sich auf ein Beispiel, in dem der Block 304 das Bestimmen einer Vielzahl von Parametern umfasst, die den ersten Parameter umfassen. In anderen Beispielen kann der Block 304 jedoch nur das Bestimmen des ersten Parameters umfassen.
In einigen, aber nicht notwendigerweise allen Beispielen, werden die Parameter bestimmt, indem die Parameter auf der Kundenseite, insbesondere auf dem Fahrzeug 12, erhalten werden. Die Parameter wurden zuerst am Fahrzeug 12 gemessen, erfasst und/oder gespeichert und sind dem Fahrzeug 12 kontextbezogen zugeordnet.
In anderen Beispielen können einer oder mehrere der Parameter durch das Netzwerk 30 erhalten werden und sind mit der Netzwerkseite in Zusammenhang gebracht. Ein oder mehrere Parameter können von dem Server 20 erhalten werden und sind dem Server 20 kontextmäßig zugeordnet.
Block 304 kann automatisch durchgeführt werden, so dass die Parameter automatisch bestimmt werden. Die Parameter können automatisch als Antwort auf Block 302 erhalten werden. Alternativ können die Parameter kurz vor Block 302 erhalten worden sein.
In anderen Beispielen können einige oder alle Parameter nur manuell bestimmt werden. Zum Beispiel können die Parameter durch eine Benutzereingabe definiert werden, die die Parameter spezifiziert.
Block 304 (und/oder Block 306) kann/können aus Datenschutzgründen vorbehaltlich einer Benutzerautorisierung durchgeführt werden. Die Benutzerberechtigung kann einer vordefinierten Benutzereinstellung und/oder einer Eingabeaufforderung des Benutzers nach dem Block 302 entsprechen.
In einigen, aber nicht unbedingt allen Beispielen, gibt jeder Parameter Informationen an, die dem Fahrzeug 12 bereits bekannt wären, so dass keine neue Hardware am Fahrzeug 12 benötigt wird. Jeder Parameter kann beispielsweise Informationen angeben, die von mindestens einem anderen Fahrzeuguntersystem zum Beeinflussen einer Fahrzeugfunktion verwendet werden, die unabhängig von einem Aspekt der Aktualisierung der Fahrzeugsoftware ist.
Zum Beispiel können die Parameter einem Navigationssystem wie einem globalen Positionierungssystem (GPS); einem Wetterinformationsmodul zum Bereitstellen eines Wetterinformationssystems; einem Verkehrsinformationsmodul zum Bereitstellen von Verkehrsinformationen; dem Telematik-Untersystem 10 für „Black-Box“ -Funktionen, das Daten wie Geschwindigkeiten aufzeichnet, bereits bekannt sein.
Jeder Parameter oder jede Kombination von Parametern wird mit einer bestimmten Wahrscheinlichkeit korreliert, damit ein Download erfolgreich ist („Erfolgswahrscheinlichkeit“), falls der Download sofort startet. In einigen Beispielen ist die Erfolgswahrscheinlichkeit die Wahrscheinlichkeit, dass der Download abgeschlossen wird. In einigen Beispielen ist die Erfolgswahrscheinlichkeit eine Wahrscheinlichkeit, dass der Download abgeschlossen wird und ein anderes Kriterium erfüllt wird, beispielsweise eine maximal akzeptable Zeit, in der der Download abgeschlossen wird.
Einige Beispielparameter liefern Informationen über einen bestimmten Kanal zwischen der netzseitigen Antennenanordnung 40 und der clientseitigen Antennenanordnung 16. Solche Parameter können direkt auf einen Aspekt der Servicequalität (quality of service, QoS) hinweisen. Zu diesen Parametern gehören beispielsweise:

• Signalstärke
- ◯ Empfangssignalstärkeanzeige (RSSI);
- ◯ Empfangskanal-Leistungsanzeige (RCPI);
- ◯ Signal-Rausch-Verhältnis (SNR);
- ◯ Signal-Interferenz-Verhältnis (SIR);
- ◯ Rauschabstand plus Störungsverhältnis (SNIR);
• Latenz;
• Fehlerrate; oder
• Bitrate.

Zumindest einige der obigen Parameter, die einzelnen Kanälen zugeordnet sind, können dem Client bekannt sein. In anderen Beispielen ist dies möglicherweise nicht der Fall, und der Client ist möglicherweise nicht in der Lage, aufgrund eines Mangels an geeigneter Hardware/Schaltung am Fahrzeug 12 die obigen Parameter zu bestimmen. In solchen Fällen können die QoS-Metriken beispielsweise an der BTS ermittelt und nicht mit dem Client geteilt werden.
Einige Parameter liefern Informationen zu einem bestimmten Kanal und geben die QoS an, sind jedoch indirekter als die obigen Parameter, die einem bestimmten Kanal zugeordnet sind (schwächere Korrelation mit der Erfolgswahrscheinlichkeit). Sie können jedoch dem Kunden bekannt sein (am Fahrzeug 12). Solche Parameter können beispielsweise mit der QoS korrelieren, weil sie Informationen über einen Ausbreitungspfad und/oder ein Ausbreitungsmedium (hauptsächlich Luft) bereitstellen, das dem Kanal zugeordnet ist. Zu diesen „indirekten“ Parametern gehören beispielsweise:

• Ortsinformationen (gibt die Entfernung von der BTS an; Sichtlinie von der BTS), wie Breitengrad, Längengrad, Reiseinformationen (umfassend Ortsinformationen), die eine vom Fahrzeug 12 zu befahrende Route angeben, usw. (können den aktuellen Standort des Fahrzeugs darstellen);
• andere Navigationsinformationen als Ortsinformationen (gibt die Antennenorientierung relativ zur BTS, Entfernung/Sichtlinie von BTS usw. an), wie beispielsweise die Richtung des Fahrzeugs 12;
• Fahrzeugnutzungsinformationen (gibt die Entfernung von der BTS an; Sichtlinie; Fahren hin zu einem guten Abdeckungsbereich hin oder von diesem weg), z. B. ob das Fahrzeug 12 keyon ist, Fahrzeuggeschwindigkeit, usw.;
• eine Fahrzeugmodellkennung (gibt clientseitige Antennenanordnungsfähigkeiten an) wie zum Beispiel eine Fahrzeugidentifikationsnummer (VIN);
• Klimainformationen wie Temperatur, Niederschlag, Luftfeuchtigkeit, Druck, elektromagnetische Aktivität wie Gewitter (deutet auf Streuung, Beugung, Absorption, thermisches Rauschen usw.) hin.

Einige Parameter beziehen sich möglicherweise nicht auf den spezifischen Kanal, der verwendet werden soll, sondern könnten sich auf eine Gruppe von Kanälen beziehen, beispielsweise eine Gruppe von Kanälen, die zumindest teilweise eine der BTS zugeordnete Zelle bilden. Solche Parameter können direkt einen Aspekt des Netzwerkverkehrsstatus angeben, wie z. B. die Qualität der Dienstleistung (grade of service, GoS). Zu diesen Parametern gehören beispielsweise:

• Mit GoS verknüpfte Messungen (zeigen an, ob der Netzwerkverkehr hoch ist), beispielsweise eine Rate blockierter Kommunikationen, eine Rate von Paketverlusten, Verzögerungen oder dergleichen.
• Ein Indikator für eine bekannte genutzte/verbleibende Kapazität (Anzahl der Kanäle oder Benutzer) eines BTS.

Zumindest einige der obigen Parameter, die zu Kanalgruppen gehören, können dem Client bekannt sein. In anderen Beispielen kann es sein, dass diese aufgrund eines Mangels an geeigneter Hardware/der Schaltungsanordnung am Fahrzeug 12 nicht bekannt sind.
Einige Parameter liefern Informationen, die eine Gruppe von Kanälen anzeigen, sind jedoch indirekter als die obigen, mit Gruppen von Kanälen verbundenen Parameter (schwächere Korrelation mit der Erfolgswahrscheinlichkeit). Sie können jedoch dem Kunden bekannt sein (am Fahrzeug 12). Solche Parameter können zum Beispiel mit GoS korrelieren, weil sie Informationen über den Netzwerkverkehr bereitstellen, der der netzseitigen Antennenanordnung 40 und/oder anderen Aspekten des Netzwerks 30 zugeordnet ist. Zu diesen „indirekten“ Parametern gehören beispielsweise:

• Dienstzellen-/BTS-Identität (der Server 20 kann in der Lage sein zu bestimmen, ob die BTS eine gute oder schlechte Wahl ist, z. B. wenn die BTS mit Roaming verbunden ist, eine geringe Kapazität aufweist oder in früheren Downloads mit einer schlechten Leistung usw. in Verbindung gebracht wurde) die entweder dem Fahrzeug 12 bekannt oder aus Ortsinformationen bestimmbar ist;
• Tageszeit (zeigt Spitzen- und Nebenverkehr im Netzwerk)
• Fahrzeugverkehrsinformationen (zeigt Staus und damit möglicherweise hohen Netzwerkverkehr an), beispielsweise die Art der Verkehrsinformationen, die von Navigationssystemen verwendet werden.

Ein Vorteil der indirekten Parameter ist, dass, wenn ein direkter Parameter nicht bekannt ist, die indirekten Parameter einzeln oder in Kombination einen guten Hinweis auf die Erfolgswahrscheinlichkeit liefern.
In einigen, aber nicht notwendigerweise allen Beispielen werden die oben aufgelisteten Beispielparameter als Übergangsparameter betrachtet, da sie vorübergehende oder sich regelmäßig ändernde Bedingungen und daher eine dynamische Erfolgswahrscheinlichkeit darstellen, die sich in Abhängigkeit von Faktoren wie der Fahreraktion, atmosphärischen Veränderungen, usw. konstant verändert. Insbesondere Parameter, die sich regelmäßig verändern (z. B. täglich oder wöchentlich) sind besonders vorteilhaft, da der Download nicht zu lange verschoben werden muss.
Einige der Parameter können Steuerparameter enthalten. Steuerparameter beziehen sich nicht notwendigerweise auf einen bestimmten Kanal oder eine Gruppe von Kanälen, sondern darauf, wie das SOTA-Update selbst behandelt und/oder verarbeitet wird. Beispiele für Steuerparameter sind:

• Übertragungsmechanismus wie Netzwerktyp (z. B. Mobilfunk, WLAN) und/oder Netzwerkerzeugung (z. B. 2G, 3G, 4G, 5G), wie ein zu verwendendes Multiplexschema;
• Netzwerkpriorisierung (z. B. QoS-Klassenkennung (QCI)), insbesondere wenn die SOTA-Aktualisierung einer bestimmten Klasse zugeordnet ist;
• Paketgröße; und
• Größe der Download-Datei.

Einige Parameter können Abonnementeinschränkungen enthalten. Abonnementeinschränkungen beziehen sich nicht notwendigerweise auf einen bestimmten Kanal, eine Gruppe von Kanälen oder darauf, wie die SOTA-Aktualisierung selbst zu behandeln und zu verarbeiten ist. Abonnementeinschränkungen können beeinflussen, ob die SOTA-Aktualisierung überhaupt zulässig ist (oder sein sollte). Beispiele für Abonnementeinschränkungen sind:

• Verbleibende Datenerlaubnis des Kunden;
• Roaming-Einschränkungen (z. B. keine Downloads während des Roamings zulässig), z. B. von Daten eines besuchten Netzwerks zu einem Heimnetzwerk;
• Abonnementebene für die Netzwerkgenerierung (z. B. 2G / 3G / 4G);

Es sei angemerkt, dass zumindest einige der Steuerparameter und Abonnementsbeschränkungen vorübergehend sein können, wie etwa verbleibende Datenerlaubnis, die monatlich zurückgesetzt werden kann, oder Roamingbeschränkungen, die aufhören können, wenn das Fahrzeug 12 zu einem Heimnetzwerk zurückkehrt usw. Es ist nützlicher, einen Download auf der Grundlage eines Übergangsparameters zu verzögern als auf der Grundlage eines statischen Parameters.
In einigen, aber nicht unbedingt allen Beispielen können die Parameter Informationen zur Verfügbarkeit von Downloadressourcen umfassen. Informationen zur Verfügbarkeit von Downloadressourcen weisen auf eine oder mehrere der folgenden Informationen hin: Verarbeitungsverfügbarkeit, Speicherverfügbarkeit; Bandbreitenverfügbarkeit auf der Clientseite.
Diese Informationen können einen Engpass oder einen Prioritätenkonflikt des Fahrzeugs 12 anzeigen.
Sobald der/die erforderliche(n) eine oder die mehreren des/der oben genannten Parameter(s) bestimmt worden ist/sind, geht das Verfahren zu Block 306 über, in dem die Parameter beispielsweise unter Verwendung des in 1 gezeigten Netzwerks 30 vom Client 16 an den Server 20 übertragen werden. Block 306 kann weggelassen werden, wenn die nachfolgenden Verfahrensblöcke auf der Clientseite ausgeführt werden.
Bei Block 310 empfängt der Server 20 die Parameter, die bei Block 306 übertragen wurden, vom Client 16. Der Block 310 kann weggelassen werden, wenn die nachfolgenden Verfahrensblöcke auf der Clientseite ausgeführt werden.
Als Nächstes umfasst das Verfahren in Block 312 das Vergleichen eines oder mehrerer der Parameter mit einer Anforderung (z. B. „erste Anforderung“). In einigen Beispielen wird jeder der Vielzahl von Parametern mit einer jeweiligen Anforderung verglichen.
Eine Anforderung kann ein Schwellenwert sein, bei dem der zugehörige Parameter eine kontinuierliche Variable ist. Eine Anforderung kann binär sein, wenn der oder die zugehörigen Parameter einen binären Zustand angeben. In einigen Beispielen kann die Anforderung einen booleschen Operator umfassen.
In einigen, aber nicht unbedingt allen Beispielen kann die Leichtigkeit, mit der die Anforderung erfüllt wird, automatisch in Abhängigkeit von einem oder mehreren Faktoren wie einer SOTA-Updatedateigröße, einer dem SOTA-Update zugewiesenen Wichtigkeitsmetrik, einer Anzahl aufeinanderfolgender fehlgeschlagener Downloads usw. variiert werden. Die Anforderung könnte beispielsweise schwieriger zu erfüllen sein, wenn die Dateigröße des SOTA-Updates groß ist, da bei einem fehlgeschlagenen Download mit einer großen Dateigröße die verschwendete Energie höher ist. Die Anforderung könnte inkrementell angepasst werden, damit sie in Abhängigkeit von inkrementell zunehmenden Verzögerungen, Unterbrechungen oder Fehlern beim Download schwieriger zu befriedigen ist.
In einigen, aber nicht unbedingt allen Beispielen, kann der Vergleich bei Block 312 in einer Vorhersagefunktion verkörpert sein, die die Erfolgswahrscheinlichkeit vorhersagt und eine Bestimmung trifft.
Wenn die oder jede Anforderung erfüllt ist, ist der Download wahrscheinlich erfolgreich, wenn er sofort gestartet wird, so dass das Verfahren zu Block 320 übergeht, in dem der Download sofort beginnt. Das SOTA-Update wird vom Client 16 vom Server 20 über das Netzwerk 30, beispielsweise das in 1 gezeigte, heruntergeladen.
Wenn die oder jede Anforderung nicht erfüllt ist, ist der Download wahrscheinlich nicht erfolgreich, wenn er sofort gestartet wird, so dass er konfiguriert werden muss. Daher fährt das Verfahren mit Block 314 fort.
Verschiedene Beispiele für Vorhersagefunktionen, die dem Block 312 zugeordnet sind, werden hier beschrieben.
Bei einer beispielhaften Implementierung einer Vorhersagefunktion unter Verwendung eines einzelnen Parameters wird der Vergleich auf der Grundlage eines Parameters durchgeführt. Der Parameter gibt RSSI an. Die erste Voraussetzung ist, dass der RSSI über einem Schwellenwert liegt. Wenn die erste Anforderung erfüllt ist, schließt die Vorhersagefunktion, dass die Signalstärke hoch ist, sodass der Download sofort ausgeführt werden kann. Wenn die erste Anforderung nicht erfüllt ist, schließt die Vorhersagefunktion, dass die Signalstärke niedrig ist, so dass das Verfahren zu Block 314 übergeht. Die Höhe des Schwellenwerts wird durch Fahrzeugtests und statistische Analysen früherer Übertragungsversuche (sowohl erfolgreicher als auch nicht erfolgreicher) bestimmt.
In einer anderen beispielhaften Implementierung einer Vorhersagefunktion unter Verwendung mehrerer Parameter empfängt der Server 20 Parameter, die den Scheibenwischerstatus und die Umgebungstemperatur angeben. Eine bedingte Wahrscheinlichkeitstabelle für den Wischer-Status gibt an, dass ein Wischer-Status „On“ eine 70 %-ige Erfolgswahrscheinlichkeit und ein „Off“ -Status eine 80 %-ige Erfolgswahrscheinlichkeit bietet. Eine bedingte Wahrscheinlichkeitstabelle für die Umgebungstemperatur zeigt an, dass eine Temperatur unter null Grad Celsius eine Erfolgswahrscheinlichkeit von 75 % und eine Temperatur über null Grad Celsius eine Erfolgswahrscheinlichkeit von 85 % bietet. Die erste Anforderung kann ein Schwellenwert der kombinierten Erfolgswahrscheinlichkeit sein. In diesem Beispiel werden die Schwelle oder Anforderungen nur durch keinen Regen und Temperaturen über null Grad Celsius erfüllt. Zusätzliche, von den Parametern getrennte Informationen könnten ebenfalls berücksichtigt werden, beispielsweise die Größe der zu übertragenden Datei.
Obwohl obenstehend ein Ansatz für eine bedingte Wahrscheinlichkeitstabelle beschrieben wurde, ist klar, dass andere Techniken innerhalb des Bereichs der Vorhersagefunktionen von vorbestimmten Algorithmen angewendet werden könnten.
In einigen Beispielen kann die Vorhersagefunktion maschinelles Lernen implementieren, um unter Verwendung einer Rückmeldung dahingehend, ob ein Download erfolgreich war, kontinuierlich zu trainieren. Das Training könnte die Anforderung(en) ändern und den Algorithmus mit der Zeit verbessern.
In einigen Beispielen hat der Vergleich von Block 312 möglicherweise nicht nur binäre Pass/Fail-Ergebnisse. Beispielsweise könnte der Vergleich stattdessen eine Variable ergeben, die viele Konfigurationsebenen des Downloads ermöglicht.
Bei Block 314 umfasst das Verfahren das Bestimmen einer ersten Bedingung in Abhängigkeit von dem Vergleich. In einigen Beispielen werden mehrere Einschränkungen in Abhängigkeit vom Vergleich bestimmt.
In einigen, aber nicht unbedingt allen Beispielen stellt bzw. stellen die Einschränkung(en) dar, wann der Download beginnen kann und/oder wann der Download nicht beginnen kann, sodass der Download dann nicht sofort beginnen kann.
Die Einschränkung(en) können beispielsweise den Download auf den Start zu einem späteren Zeitpunkt einschränken, der möglicherweise später eintritt (z. B. mitten in der Nacht, wenn das Auto höchstwahrscheinlich mit bekannt guter Signalstärke am Haus des Benutzers geparkt ist).
In anderen Beispielen kann die erste Bedingung den Download zu einem bestimmten späteren Zeitpunkt unabhängig von der Erfolgswahrscheinlichkeit zu dem bestimmten späteren Zeitpunkt starten. Dies kann insbesondere bei wichtigen SOTA-Updates der Fall sein.
In einigen, aber nicht notwendigerweise allen Beispielen kann die Einschränkung bzw. können die Einschränkungen eine Bedingung zum Starten des Herunterladens einführen, sobald die erste Anforderung als nächstes erfüllt ist. Vor dem Start zu einem späteren Zeitpunkt kann das Verfahren optional zum Block 310 zurückkehren, um die aktuelle Erfolgswahrscheinlichkeit zu überprüfen, und kann den Download erneut verschieben, wenn die erste Anforderung zu dem späteren Zeitpunkt nicht erfüllt ist.
In einigen, aber nicht notwendigerweise allen Beispielen kann/können die Einschränkung(en) einen Ortsauslöser zum Starten des Herunterladens einführen, beispielsweise wenn das Fahrzeug 12 in einen Bereich mit guter Netzabdeckung einfährt. Eine beispielhafte Einschränkung könnte sein, den Download „“nächstes Mal, wenn das Fahrzeug 12 zu Hause ist“ durchzuführen. Ein „Heimatort“ kann aus Benutzereinstellungen bekannt sein, die in Navigationsinformationen gespeichert sind.
In einer beispielhaften ortsbasierten Implementierung des Verfahrens 300 umfasst der im Block 304 bestimmte erste Parameter Reiseinformationen, die die von dem Fahrzeug 12 zu befahrende Route angeben. Die erste Anforderung für Block 312 umfasst eine Anforderung, dass sich das Fahrzeug 12 in einem vordefinierten Bereich befindet, der von der Route gemäß den Reiseinformationen geschnitten wird. Die erste Einschränkung umfasst einen Ortsauslöser, der das Starten des Downloads erfordert, wenn das Fahrzeug in den vordefinierten Bereich einfährt. Die Erfüllung des Ortsauslösers könnte lokal am Fahrzeug 12 überwacht werden, wobei bei Erfüllung des Ortsauslösers eine Nachricht an den Server 20 gesendet wird. Alternativ könnte das Fahrzeug 12 Standortdaten kontinuierlich an den Server 20 senden, wodurch der Server 20 die Erfüllung des Standortauslösers überwachen kann.
Dies bietet die Vorteile, dass der vordefinierte Bereich mit einer hohen Erfolgswahrscheinlichkeit (z. B. gutem Signalempfang) verbunden sein kann und daher eine Ausfallwahrscheinlichkeit niedriger ist.
In einigen, aber nicht unbedingt allen Beispielen bestimmt/bestimmen die Einschränkung(en) ein Unterteilen des Downloads. Beispielsweise ist es wahrscheinlich, dass zwei 50-Megabyte(MB)-Downloads erfolgreicher sind als ein einzelner Download von 100 MB. Durch das Aufteilen des Downloads in separate Downloads mit geringerer Dateigröße wird sichergestellt, dass das SOTA-Update während des Downloadvorgangs regelmäßig von einem flüchtigen Speicher in einen nichtflüchtigen Speicher übertragen wird. Wenn der Download nicht abgeschlossen wird, kann es daher möglich sein, von einem zuletzt erfolgreich übertragenen Datenblock aus fortzufahren.
Das Verfahren geht dann weiter zu Block 316, in dem der Download in Abhängigkeit von der Einschränkung (den Einschränkungen) konfiguriert wird. Das Konfigurieren des Downloads bedeutet das Anwenden der relevanten Einschränkung(en) auf den Download, sodass ein Aspekt des Downloads, z. B. die Startzeit, auf eine Weise gesteuert wird, die die Einschränkung(en) erfüllt.
Das Verfahren geht dann weiter zu Block 318, in dem der Download beginnt, wenn die Bedingungen erfüllt sind. Das SOTA-Update wird vom Client 16 vom Server 20 über das Netzwerk 30, wie zum Beispiel über das in 1 gezeigte, heruntergeladen.
Das SOTA-Update kann während des Herunterladens Delta-komprimiert sein.
4 zeigt ein Ausfallverfahren 400. Das Ausfallverfahren 400 kann von der Steuerung (Client) 16 oder vom Server 20 oder von beiden ausgeführt werden.
Das Fehlerverfahren 400 beginnt bei Block 402 (Download starten). Block 402 ist eine direkte Referenz zu Block 318 und Block 320.
Der nächste Block 404 des Ausfallverfahrens 400 bestimmt, dass der Download fehlgeschlagen ist. Beispielsweise fällt eine Datenübertragungsrate für eine vorbestimmte Zeitdauer (Timeout) auf null oder unter einen Schwellenwert. Der Fehler könnte einen vollständigen Verlust der bereits heruntergeladenen Daten darstellen, so dass der Download erneut beginnen muss, oder könnte in anderen Beispielen einen Unterbrechungspunkt darstellen, wobei der Download ab dem Unterbrechungspunkt wieder aufgenommen werden kann.
Ein Zähler kann für jedes aufeinanderfolgende Versagen des Downloads für ein bestimmtes Fahrzeug 12 ansteigen.
Der nächste Block 406 des Ausfallverfahrens 400 bestimmt, ob eine Ausfallschwelle erreicht wurde, z. B. 5 maliges Versagen. Die Schwelle liegt bei mehr als einem Versagen. In einem Beispiel wird bestimmt, dass der Wert des Zählers einen Schwellenwert erreicht/überschritten hat.
Der nächste Block 408 des Ausfallverfahrens 400 sendet ein Signal. In einigen Beispielen kann das Signal eine Nachricht wie ein Bericht oder eine E-Mail sein. Der Bericht oder die E-Mail könnte an einen Administrator am Serverende und/oder an einen Benutzer des Clientendes übermittelt werden. In anderen Beispielen könnte das Signal zu einer Ausgabevorrichtung übertragen werden, um zu bewirken, dass die Ausgabevorrichtung eine Ausgabe bereitstellt. Das Signal könnte zu einem Ausgabegerät am Serverende und/oder zu einem Ausgabegerät 18 beim Clientende übertragen werden. Der Bericht, die E-Mail oder die Ausgabe könnten den Benutzer dazu auffordern, einen Händler zu aufzusuchen, um die Software zu aktualisieren, oder dem Benutzer mitteilen, dass er sich nicht an einem guten Ort befindet, oder es später erneut zu versuchen oder könnten warnen dahingehend, wie lange der Download aufgrund der gegebenen Fahrzeugparameter usw. vermutlich dauern wird.
5 zeigt ein Installationsverfahren 500. Das Installationsverfahren 500 wird am Fahrzeug 12 durchgeführt, beispielsweise durch das Telematik-Untersystem 10 und/oder eine Steuerung 16, für die die SOTA-Aktualisierung bestimmt ist.
Das Installationsverfahren 500 umfasst in Block 502 das Bestimmen, dass der Download abgeschlossen ist und zur Installation bereit ist. Block 502 kann von Block 320 aus folgen und kann von Block 318 folgen, wenn der Download erfolgreich war.
Bei Block 503 umfasst das Installationsverfahren 500 dann das Bestimmen eines oder mehrerer Installationsparameter(s). Die Installationsparameter korrelieren mit einer Erfolgswahrscheinlichkeit der Installation, ähnlich wie die Downloadparameter mit einer Erfolgswahrscheinlichkeit des Downloads korrelieren. Zum Beispiel kann die Installation erfordern, dass der Schlüssel des Fahrzeugs 12 für eine gewisse Zeit nicht betätigt wird, und es muss sichergestellt werden, dass die Installation abgeschlossen ist, bevor das Fahrzeug das nächste Mal verwendet wird.
In einem Beispiel werden die Installationsparameter mit einer Erfolgswahrscheinlichkeit der Installation korreliert, ohne die Anforderung eines Benutzers zur Verwendung des Fahrzeugs 12 außer Kraft zu setzen.
Installationsparameter umfassen beispielsweise Fahrzeugbenutzungsparameter, wie sie oben beschrieben sind. Fahrzeugnutzungsparameter können zum Beispiel anzeigen, ob das Fahrzeug 12 gezündet wurde (key on, in Betrieb) oder nicht gezündet wurde (key off, außer Betrieb) und/oder wie lange erwartet wird, dass das Fahrzeug 12 außer Betrieb bleibt.
Ein weiterer, potentiell nützlicher Fahrzeugbenutzungsparameter zur Verwendung als Installationsparameter ist ein Zeitgeber, der mit einer nächsten Verwendung oder einer Änderung des Leistungsmodus (z. B. Aufwecken) in Richtung Schlüsselbetätigung verbunden ist. Zum Beispiel kann geplant sein, dass das Fahrzeug 12 am nächsten Morgen um 7 Uhr verwendet wird.
Zu den nützlichen Installationsparametern gehören auch Informationen zur Verfügbarkeit der Installationsressourcen, die Folgendes angeben: Verarbeitungsverfügbarkeit; Speicherverfügbarkeit; Verfügbarkeit der elektrischen Energie am Fahrzeug 12. Überlegungen zur Verarbeitung und zum Speicher können einen Engpass und/oder einen Konflikt mit anderen Prozessen betreffen. Die Verfügbarkeit elektrischer Energie kann einen Zustand eines Batteriemoduls anzeigen, beispielsweise einen Ladezustand. Wenn dies nicht bekannt ist, wäre ein nützlicher Parameter für die Verfügbarkeit der elektrischen Energie die Temperatur, die mit der Batterieleistung korreliert.
Dann umfasst das Installationsverfahren 500 bei Block 504 das Vergleichen der Installationsparameter mit einer oder entsprechenden Installationsanforderungen.
Die Installationsanforderungen können Schwellenwerte oder ähnliche Bedingungen darstellen, ähnlich wie in Bezug auf Block 312 beschrieben.
Wenn in einem Beispiel die Installationsanforderung(en) erfüllt sind, und der Vergleich beispielsweise zeigt, dass die Verfügbarkeit elektrischer Energie gut ist (beispielsweise über dem Schwellenwert für SoC) und/oder das Fahrzeug 12 außer Betrieb ist und/oder geplant ist, dass das Fahrzeug 12 für zumindest eine definierte Installationszeit außer Betrieb ist, dann kann die Installation sofort durchgeführt werden. Das Verfahren geht zu Block 512 zur sofortigen Installation über.
Wenn die Installationsanforderungen nicht erfüllt sind, geht das Verfahren zu Block 506 über, in dem eine Installationsbedingung in Abhängigkeit vom Vergleich von Block 504 bestimmt wird.
Wie bei der Einschränkung für den Download bestimmt die Installationseinschränkung, wann die Installation durchgeführt werden kann und/oder nicht ausgeführt werden kann, sofern die Installation nicht sofort ausgeführt werden kann.
Bei Block 508 wird die Installation dann durch Anwenden der relevanten Installationseinschränkung(en) konfiguriert. Die Installationseinschränkungen können ähnliche Bedingungen/Anforderungen einführen, wie sie für die Downloadeinschränkungen beschrieben wurden. Wenn im Block 510 die Installationseinschränkungen erfüllt sind, beginnt die Installation (wie konfiguriert). In einem Fahrzeug 12 kann die Installation zum Beispiel eine Kopie der vorhandenen Software auf einer dedizierten elektronischen Speichervorrichtung sichern, bis das SOTA-Update erfolgreich war.
Zum Zweck der vorliegenden Offenbarung versteht es sich, dass die hier beschriebene(n) Steuerung(en) jeweils eine Steuereinheit oder Rechenvorrichtung umfassen können, die einen oder mehrere elektronische Prozessoren aufweist/aufweisen. Ein Fahrzeug 12 und/oder ein System von diesem kann eine einzige Steuereinheit oder ein elektronisches Steuergerät umfassen, oder alternativ können unterschiedliche Funktionen der Steuervorrichtung/der Steuervorrichtungen in verschiedenen Steuereinheiten oder Steuerungen ausgeführt oder untergebracht sein. Es kann ein Satz von Anweisungen bereitgestellt werden, die bei ihrer Ausführung die Steuerung(en) oder die Steuereinheit(en) veranlassen, die in dieser Schrift beschriebenen Steuertechniken (einschließlich der beschriebenen Methode(n)) umzusetzen. Der Satz aus Anweisungen kann in einem oder mehreren elektronischen Prozessoren eingebunden sein; alternativ dazu kann der Satz aus Anweisungen als Software bereitgestellt sein, die von einem oder mehreren elektronischen Prozessoren ausgeführt wird. So kann zum Beispiel ein erstes Steuergerät in Software implementiert sein, die auf einem oder mehreren elektronischen Prozessoren ausgeführt wird, und ein oder mehrere weitere Steuergeräte können auch auf einer auf einem oder mehreren Prozessoren, optional demselben einen oder denselben mehreren elektronischen Prozessoren wie das erste Steuergerät, ausgeführten Software implementiert sein. Es wird allerdings darauf hingewiesen, dass andere Anordnungen ebenfalls brauchbar sind und demnach die vorliegende Offenbarung nicht beabsichtigt, auf eine bestimmte Anordnung beschränkt zu sein. In jedem Fall kann der oben beschriebene Satz von Anweisungen in ein computerlesbares Speichermedium (z. B. ein nicht-transientes computerlesbares Speichermedium) eingebettet sein, das einen beliebigen Mechanismus zur Speicherung von Daten in einer für eine Maschine oder einen elektronischen Prozessor/Rechner lesbaren Form umfassen kann, wie unter anderem: ein magnetisches Speichermedium (z. B. Floppydisk), optisches Speichermedium (z. B. CD-ROM), magnetisch-optisches Speichermedium, Nur-LeseSpeicher (ROM), Arbeitsspeicher (RAM), löschbarer programmierbarer Speicher (z. B. EPROM und EEPROM), Flash-Speicher oder elektrische oder andere Datenträger zum Speichern solcher Daten/Anweisungen.
Die in den 3, 4 und 5 dargestellten Blöcke können Schritte in einem Verfahren und/oder Abschnitte des Codes in dem Computerprogramm 206 darstellen. Die Darstellung einer besonderen Reihenfolge für die Blöcke impliziert nicht notwendigerweise, dass es eine erforderliche oder bevorzugte Reihenfolge für die Blöcke gibt, und die Reihenfolge und Anordnung des Blocks kann variiert werden. Darüber hinaus kann es möglich sein, dass einige Schritte ausgelassen werden.
Der Begriff „Update“, wie er hier verwendet wird, ist ausdrücklich nicht auf eine Anforderung beschränkt, dass die Software, die überschrieben oder modifiziert werden soll, bereits in einem Fahrzeug vorhanden ist. Der Begriff „Update“ umfasst auch die Installation neuer Software, für die es keinen Vorgänger gibt.
Obwohl Ausführungsformen der vorliegenden Erfindung in den vorhergehenden Abschnitten unter Bezugnahme auf verschiedene Beispiele beschrieben wurden, ist anzumerken, dass Modifikationen an den gegebenen Beispielen vorgenommen werden können, ohne von dem Umfang der beanspruchten Erfindung abzuweichen. Beispielsweise könnte eine Benutzereingabe, die eine Installationsstartzeit angibt, für die Konfiguration der Installation erforderlich und ausreichend sein, ohne dass Installationsparameter zur Bestimmung der Erfolgswahrscheinlichkeit einer Installation ermittelt werden müssen.
In der vorhergehenden Beschreibung beschriebene Merkmale können in Kombinationen verwendet werden, die sich von den ausdrücklich beschriebenen Kombinationen unterscheiden.
Wenngleich Funktionen unter Bezugnahme auf bestimmte Merkmale beschrieben worden sind, sind diese Funktionen durch andere Merkmale ausführbar, unabhängig davon, ob sie beschrieben worden sind oder nicht.
Wenngleich Merkmale mit Bezug auf bestimmte Ausführungsformen beschrieben worden sind, können diese Merkmale auch in anderen Ausführungsformen vorliegen, gleich ob beschrieben oder nicht.
Während versucht wurde, in der vorstehenden Spezifikation die Aufmerksamkeit auf jene Merkmale der Erfindung zu lenken, die für besonders wichtig gehalten wurden, sollte es sich verstehen, dass der Anmelder in Bezug auf jedes patentierbare Merkmal oder jede patentierbare Kombination von Merkmalen Schutz beansprucht, auf die im Vorstehenden Bezug genommen wird und/oder die in den Zeichnungen dargestellt werden, unabhängig davon, ob dem eine besondere Bedeutung beigemessen worden ist oder nicht.

Claims

Fahrzeug-Update-System (16, 20), wobei das System Folgendes umfasst: Mittel zur Bestimmung (302), dass ein OTA-Software-Update eines Fahrzeugs (12) erforderlich ist; Mittel zur Bestimmung (304) eines ersten Parameters; Mittel zum Vergleich (312) des ersten Parameters mit der ersten Anforderung; Mittel zur Bestimmung (314), in Abhängigkeit von dem Vergleich, einer ersten Einschränkung; und Mittel zur Konfigurierung (316), in Abhängigkeit von der ersten Einschränkung, eines Downloads des OTA-Software-Updates.
System nach Anspruch 1, wobei der erste Parameter eine aus Umgebungsinformationen, Klimainformationen, Ortsinformationen, Informationen über die Verfügbarkeit von Downloadressourcen, die auf die Ressourcenverfügbarkeit im Fahrzeug für den Download hinweisen, Anzeige der am Fahrzeug und/oder im Netzwerk (30) gemessenen Signalstärke oder Abonnementeinschränkung angibt; und optional der erste Parameter automatisch am Fahrzeug ermittelt wird; optional die erste Einschränkung den Zeitpunkt des Beginns des Downloads, das Unterteilen des Downloads in separate kleinere Downloads oder den Ort des Beginns des Downloads beeinflusst; optional die Verfügbarkeitsinformation der Downloadressource eine der folgenden Informationen anzeigt: Verarbeitungsverfügbarkeit; Speicherverfügbarkeit; Verfügbarkeit der Bandbreite.
System nach Anspruch 2, wobei die Ortsinformationen Fahrtinformationen umfassen, die erste Anforderung eine Anforderung umfasst, dass sich das Fahrzeug in einem vordefinierten Bereich befindet, der von einer Route gemäß den Fahrtinformationen durchschnitten wird, und die erste Einschränkung erfordert, dass der Download beginnt, wenn das Fahrzeug in den vordefinierten Bereich einfährt.
System nach einem der vorhergehenden Ansprüchen, umfassend Mittel zur Übertragung eines Signals an eine Ausgabevorrichtung, um die Ausgabevorrichtung dazu zu veranlassen, eine Ausgabe in Abhängigkeit von einem oder mehrerem Versagen zur Verfügung zu stellen, um den Download zu beenden.
System nach einem der vorhergehenden Ansprüche, umfassend Mittel zum Bestimmen (50) eines Installationsparameters und Mittel zum Konfigurieren (508), in Abhängigkeit vom Installationsparameter, einer Installation des OTA-Software-Updates; optional gibt der Installationsparameter an, ob sich das Fahrzeug und/oder wie lange sich das Fahrzeug in einem Schlüssel-Aus-Zustand befindet, oder gibt Informationen zur Verfügbarkeit der Installationsressourcen an, die auf die Ressourcenverfügbarkeit im Fahrzeug für die Installation hinweisen.
System nach Anspruch 5, wobei die Informationen zur Verfügbarkeit der Installationsressourcen eines aus Folgenden anzeigen: Verarbeitungsverfügbarkeit; Speicherverfügbarkeit; Verfügbarkeit der elektrischen Energie am Fahrzeug.
System nach einem der vorhergehenden Ansprüchen, das einen Fahrzeug-Software-Update-Server (20) und einen Fahrzeugsoftware-Update-Client (16) eines Fahrzeugs (12) umfasst, wobei der Download von dem Fahrzeugsoftware-Update-Server an den Fahrzeugsoftware-Update-Client erfolgt.
Fahrzeugsoftware-Update-Verfahren (300), wobei das Verfahren Folgendes umfasst: Bestimmen (302), dass ein OTA-Software-Update eines Fahrzeugs erforderlich ist; Bestimmen (304) eines ersten Parameters; Vergleichen (312) des ersten Parameters mit einer ersten Anforderung; Bestimmen (314), in Abhängigkeit von dem Vergleich, einer ersten Einschränkung; und Konfigurieren (316), in Abhängigkeit von der ersten Einschränkung, eines Downloads des OTA-Software-Updates.
Computerprogramm, das bei Ausführung auf mindestens einem elektronischen Prozessor (202) Folgendes bewirkt: Bestimmen (302), dass ein OTA-Software-Update eines Fahrzeugs erforderlich ist; Bestimmen (304) eines ersten Parameters; Vergleichen (312) des ersten Parameters mit einer ersten Anforderung; Bestimmen (314), in Abhängigkeit von dem Vergleich, einer ersten Einschränkung; und Konfigurieren (316), in Abhängigkeit von der ersten Einschränkung, eines Downloads des OTA-Software-Updates.
Fahrzeug (16), das Folgendes umfasst: das System nach einem der Ansprüche 1 bis 7.