DE102017109099A1 - Bereitstellen von modul-updates für ein fahrzeugsystem - Google Patents

Bereitstellen von modul-updates für ein fahrzeugsystem Download PDF

Info

Publication number
DE102017109099A1
DE102017109099A1 DE102017109099.1A DE102017109099A DE102017109099A1 DE 102017109099 A1 DE102017109099 A1 DE 102017109099A1 DE 102017109099 A DE102017109099 A DE 102017109099A DE 102017109099 A1 DE102017109099 A1 DE 102017109099A1
Authority
DE
Germany
Prior art keywords
vehicle
mail
updates
server
cache server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102017109099.1A
Other languages
English (en)
Inventor
Rafael Tiles
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
GM Global Technology Operations LLC
General Motors LLC
Original Assignee
GM Global Technology Operations LLC
General Motors LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by GM Global Technology Operations LLC, General Motors LLC filed Critical GM Global Technology Operations LLC
Publication of DE102017109099A1 publication Critical patent/DE102017109099A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Ein Kommunikationssystem, das ein Backend-System und ein Fahrzeug beinhaltet. Verfahren zur Verwendung des Kommunikationssystems, um ferngesteuerte Modul-Updates eines Systems für das Fahrzeug bereitzustellen. Das Verfahren beinhaltet: das Erzeugen einer elektronischen Nachricht (E-Mail) auf einem Fahrzeug-Backend-System, das ein Update für ein erstes Fahrzeugsystemmodul (VSM) im Fahrzeug beinhaltet; das Speichern der E-Mail auf einem Mail-Cache-Server, wobei der Cache-Server mit dem Backend-System in Verbindung steht; und wenn das Fahrzeug mit einem Backend-Dienste-Vertrag in Verbindung steht, liefert es dann die gespeicherte E-Mail aus dem Cache-Server an das Fahrzeug über eine Mobilfunkverbindung, sodass das Update auf das erste VSM angewendet werden kann.

Description

  • TECHNISCHES GEBIET
  • Die vorliegende Erfindung betrifft die ferngesteuerte Bereitstellung von Modul-Updates für ein Fahrzeugsystem.
  • HINTERGRUND
  • Nachdem ein neues Fahrzeug an einen Kunden geliefert wurde, ist es mitunter wünschenswert, die darin verwendete Software durch das Elektrofahrzeugmodul zu aktualisieren. In einigen Fällen kann ein Software-Update im Fahrzeug drahtlos über einen ferngesteuerten Computerserver empfangen werden, wenn das Fahrzeug ein Mobilfunkabonnent ist (z. B. in Verbindung mit einem Mobilfunkvertrag). Wenn das Fahrzeug jedoch kein Abonnent ist (oder z. B., wenn der Vertrag abläuft), können Software-Updates verpasst und nicht empfangen werden. Angenommen der Vertrag wird später erneuert, dann können neue Software-Updates für das Fahrzeug drahtlos bereitgestellt werden. Diese neueren Updates können jedoch mit dem Elektrofahrzeugmodul ohne das Installieren von einem ersten oder mehreren Updates, die in der Zwischenzeit verpasst wurden (d. h., während des Zeitraums des Nicht-Abonnements), inkompatibel sein. Daher wird ein Verfahren zum Empfangen und Installieren aller verpassten Zwischenupdates vor dem Installieren der neueren Updates benötigt.
  • KURZDARSTELLUNG
  • Gemäß einer weiteren Ausführungsform der Erfindung wird ein Verfahren zur Bereitstellung von ferngesteuerten Modul-Updates eines Systems für ein Fahrzeug bereitgestellt. Das Verfahren beinhaltet: das Erzeugen einer elektronischen Nachricht (E-Mail) auf einem Fahrzeug-Backend-System, das ein Update für ein erstes Fahrzeugsystemmodul (VSM) im Fahrzeug beinhaltet; das Speichern der E-Mail auf einem Mail-Cache-Server, wobei der Cache-Server mit dem Backend-System in Verbindung steht; und wenn das Fahrzeug mit einem Backend-Dienste-Vertrag in Verbindung steht, liefert es dann die gespeicherte E-Mail aus dem Cache-Server an das Fahrzeug über eine Mobilfunkverbindung, sodass das Update auf das erste VSM angewendet werden kann.
  • Gemäß einer weiteren Ausführungsform der Erfindung, wird ein Verfahren zum Empfangen von Modul-Updates eines Systems für ein Fahrzeug von einem ferngesteuerten Backend-System bereitgestellt. Das Verfahren beinhaltet die Schritte: das Beenden des Empfangens einer E-Mail vom Backend-System, folglich eine Beendigung eines Backend-Dienste-Vertrags zwischen einem Benutzer des Fahrzeugs und dem Backend-System; dann das Empfangen einer E-Mail im Fahrzeug über eine Mobilfunkverbindung vom Cache-Server, der die E-Mail während eines Ablaufzeitraums des Abonnements gespeichert hat; das Extrahieren eines Software-Updates oder eines Firmware-Updates aus der E-Mail; und das Installieren des Software- oder Firmware-Updates auf einem Fahrzeugsystemmodul (VSM) im Fahrzeug.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Eine oder mehrere Ausführungsformen der Erfindung werden nachfolgend in Verbindung mit den beigefügten Zeichnungen beschrieben, worin gleiche Bezeichnungen gleiche Elemente bezeichnen, und worin:
  • 1 ein Blockdiagramm ist, das eine Ausführungsform eines Kommunikationssystems darstellt, das fähig ist, das hierin offenbarte Verfahren zu verwenden;
  • 2 ein schematisches Diagramm eines Fahrzeugs, gezeigt in 1, ist;
  • 3 ein Flussdiagramm ist, das ein Verfahren zur Verwendung des Kommunikationssystems veranschaulicht, um Updates an das Fahrzeug bereitzustellen; und
  • 4 ist ein schematisches Diagramm zur Veranschaulichung von zwischengespeicherten E-Mail-Nachrichten in einem Mail-Cache-Server des Kommunikationssystems.
  • AUSFÜHRLICHE BESCHREIBUNG DER VERANSCHAULICHTEN
  • AUSFÜHRUNGSFORM(EN)
  • Telematikfähige Fahrzeuge können so konfiguriert werden, um Software- und/oder Firmware-Updates, die von einem Fahrzeug-Backend-System empfangen wurden, zu empfangen und zu installieren; z. B. Updates für elektronische Steuergeräte (ECUs) von einem oder mehreren Systemmodulen innerhalb des Fahrzeugs. In vielen Fällen können diese Updates automatisch auftreten oder automatisch eingeleitet werden (z. B. ohne Veranlassung durch einen Benutzer des Fahrzeugs). In mindestens einigen Ausführungsformen werden diese Updates (z. B. Reflash-Updates – z.B., ein Update des BIOS oder des grundlegenden Eingabe-Ausgabe-Systems eines ECUs) über eine Mobilfunkverbindung zwischen einer Fahrzeugtelematikeinheit und dem Backend-System, gemäß eines Abonnementvertrags, empfangen, der das Empfangen von Backend-Diensten des Fahrzeugs über einen Mobilfunk-Service-Provider (WSP) umfasst. Das Backend-System kann beispielsweise dem Fahrzeugbenutzer einen Abonnementvertrag in Verbindung mit einem WSP bereitstellen, der vom Backend-System verwendet wird. Wenn der Benutzer die Backend-Dienste des Fahrzeugs abbricht (z. B. den Vertrag beendet oder der Vertrag verjährt), kann auch der Leistungsumfang des Empfangens von Diensten über die Mobilfunkverbindung enden. In diesen Fällen können neu freigegebene Updates für die ECUs des Fahrzeugs erzeugt werden; diese Updates können jedoch nicht während des Ablaufzeitraums des Abonnements installiert werden. Sie können beispielsweise per E-Mail durch das Backend-System versendet werden; sie erreichen jedoch eventuell niemals das Zielfahrzeug, wenn die Mobilverbindung des Fahrzeugs abgelaufen ist. Wenn der Benutzer den Abonnementvertrag später erneuert und wieder Updates empfängt, sind die späteren Updates eventuell nicht mit den ECUs des Fahrzeugs kompatibel – ohne vorerst die fehlenden Updates und Zwischenupdates (oder Zwischenzeitupdates) zu installieren (z. B. die, die während des Ablaufzeitraum des Abonnements erzeugt werden).
  • Das unten offenbarte Verfahren umfasst das erneuerte Abonnentfahrzeug unter Verwendung eines speziell konfigurierten Cache-Servers, um die fehlenden Updates oder Zwischenupdates für seine ECUs zu empfangen und zu installieren. Wie unten erläutert, empfängt das Fahrzeug nicht nur alle fehlenden Updates, sondern installiert diese auch in der wünschenswertesten Reihenfolge – z.B. um sicherzustellen, dass später empfangene Updates das jeweilige elektronische Steuergerät (oder das VSM) dazu aktivieren, ordnungsgemäß zu funktionieren oder zu arbeiten. Ferner identifiziert das unten beschriebene Verfahren Updates, die in Verbindung mit Fahrzeugsicherheit-VSMs stehen (z. B. ein Fahrzeugbremssystem) und sicherstellt, dass die Updates nur erfolgen, wenn das Fahrzeug stillsteht, usw.
  • Kommunikationssystem –
  • 1 veranschaulicht eine exemplarische Betriebsumgebung eines Kommunikationssystems 10, das ein Fahrzeug 12, ein Drahtlosträgersystem 14, eine Trägersystem-Firewall 16, ein Drahtlosträgersystem (WSP) einer entmilitarisierten Zone (DMZ) 18, eine erste Kontroll-Firewall 20, ein sicheres Netzwerk 22 (z. B. ein örtliches oder Weitverkehrsnetz (z. B. LAN oder WAN)), eine zweite Kontroll-Firewall 24, einen Fest- oder Internetnetz 26, ein elektronischer Backend-Nachrichten(E-Mail)-Server 28, ein E-Mail-Übertragungsserver 30 und eine elektronische Vorrichtung 34 beinhaltet. In mindestens einer Ausführungsform beinhaltet ein Fahrzeug-Backend-System 36 die erste Kontroll-Firewall 20, das sichere Netzwerk 22, die zweite Kontroll-Firewall 24, den Backend-E-Mail-Server 28 und den E-Mail-Übertragungsserver 30. Das dargestellte Kommunikationssystem ist lediglich ein Beispiel; andere Kommunikationssysteme könnten mindestens einige Komponenten verwenden, die das hierin beschriebene Verfahren anders durchführen.
  • Wie auch in 2 gezeigt, ist das Fahrzeug 12 in der veranschaulichten Ausführungsform als ein Personenkraftwagen dargestellt, es sollte jedoch beachtet werden, dass jedes andere Fahrzeug, einschließlich Motorräder, Lastwagen, Geländewagen (SUV), Campingfahrzeuge (RV), Wasserfahrzeuge, Flugzeuge usw., ebenfalls verwendet werden kann. Das Fahrzeug 12 kann ein Fahrzeugkommunikationssystem 40 beinhalten, dass eine Anzahl von miteinander verbundenen Fahrzeugsystemmodulen (VSMs) 42 unter Verwendung von einer oder mehreren Netzwerkverbindungen 44 beinhaltet.
  • VSMs 42 können in Form von elektronischen Hardwarekomponenten auftreten, die sich im ganzen Fahrzeug befinden und in der Regel eine Eingabe von einem oder mehreren Sensoren (nicht dargestellt) empfangen und die erfassten Eingaben verwenden, um Diagnose-, Überwachungs-, Steuerungs-, Berichterstattungs- und/oder andere Funktionen auszuführen. So können nicht einschränkende Beispiele von VSMs ein Motorsteuergerät beinhalten, das verschiedene Aspekte des Motorbetriebs, wie etwa Selbstzündung und Zündzeitpunkt, steuert, ein Antriebsstrangmodul, das den Betrieb von einer oder mehreren Getriebekomponenten des Chassis-Steuermoduls zum Steuern verschiedener elektrischer Komponenten regelt, die sich im ganzen Fahrzeug befinden, und eine Fahrzeugtelematikeinheit 42a für Drahtloskommunikation, Drahtlosnavigation und dergleichen.
  • Jedes der VSMs 42 kann jeweils ein elektronisches Steuergerät (ECU) 46 beinhalten, das Speicher 48 und einen oder mehrere Prozessoren 50 umfasst. Der Speicher 48 kann jedes geeignete nicht-flüchtige computernutzbare oder computerlesbare Medium beinhalten, das eine oder mehrere Speichervorrichtungen oder Gegenstände beinhalten kann. Exemplarische nicht-flüchtige computernutzbare Speichervorrichtungen beinhalten ein herkömmliches Computersystem-RAM (Random Access Memory), ROM (Read Only Memory), EPROM (löschbarer, programmierbarer ROM), EEPROM (elektrisch löschbarer, programmierbarer ROM) und magnetische oder optische Platten oder Bänder.
  • Der/die Prozessor/en 50 kann/können jede Geräteart sein, die fähig ist elektronische Befehle zu verarbeiten, einschließlich Mikroprozessoren, Mikrocontrollern, Hostprozessoren, Steuerungen, Fahrzeugkommunikationsprozessoren und anwendungsspezifische integrierte Schaltungen (ASICs). Er kann ein vorgesehener Prozessor sein, der ausschließlich für das jeweilige VSM 42 verwendet wird oder er kann mit anderen Fahrzeugsystemen gemeinsam genutzt werden. Der Prozessor 50 kann so konfiguriert sein, um verschiedene Arten von digital gespeicherten Anweisungen, wie etwa Software- oder Firmware-Programme, die im Speicher 48 gespeichert sind, ausführen, die es dem VSM 42 ermöglichen, einen oder mehrere zuvor festgelegte Dienste für einen Benutzer eines Fahrzeugs und/oder des Fahrzeug-Backends 36 bereitzustellen. Zum Beispiel kann das ECU 46 unter Verwendung des Prozessors 50 Programme ausführen oder Daten verarbeiten, um mindestens einen Teil des hierin beschriebenen Verfahrens auszuführen. In mindestens einer Ausführungsform kann beispielsweise mindestens eines der ECUs 46 ein Software- oder Firmware-Update als Reaktion auf eine Änderung des Fahrzeugabonnentstatus (z. B. eine Statusänderung vom Nicht-Abonnenten zum Abonnenten) empfangen und ausführen. Wie nachfolgend näher erläutert, können Updates VSM(oder ECU)-Firmware, Software oder dergleichen (z. B. und in mindestens einer Ausführungsform sind die Updates Reflash-Updates) neu konfiguriert werden.
  • Die Telematikeinheit 42a – eine der VSMs 42 – kann eine OEM-installierte (eingebettete) oder eine Sekundärmarktvorrichtung sein, die in dem Fahrzeug 12 installiert ist und drahtlose Sprach- und/oder Datenkommunikation über das Drahtlosträgersystem 14 und über drahtlose Vernetzung ermöglicht. In mindestens einer Ausführungsform umfasst die Telematikeinheit 42a mindestens einen Mobilfunkchipsatz. Dies ermöglicht, dass das Fahrzeug 12 mit dem Backend-System 36, anderen telematikfähigen Fahrzeugen oder einer anderen Entität oder Vorrichtung kommunizieren kann. Die Telematikeinheit 42a verwendet bevorzugt Funkübertragungen, um einen Kommunikationskanal (einen Sprachkanal und/oder einen Datenkanal) mit dem Drahtlosträgersystem 14 herzustellen, sodass Sprach- und/oder Datenübertragungen über den Kanal gesendet und empfangen werden können. Durch das Bereitstellen von sowohl Sprach- als auch Datenkommunikation ermöglicht die Telematikeinheit 42a, dass das Fahrzeug 12 eine Anzahl von unterschiedlichen Diensten anbieten kann, einschließlich denen, die sich auf Navigation, Fernsprechen, Nothilfe, Diagnose, Infotainment usw. beziehen. Daten können beispielsweise entweder über eine Datenverbindung, wie etwa über Paketdatenübertragung über einen Datenkanal oder über einen Sprachkanal unter Verwendung von auf dem Fachgebiet bekannten Techniken gesendet werden. Nicht einschränkende Beispiele der Fähigkeiten der Telematikeinheit beinhalten den Betrieb über eine Mobilfunkverbindung (z. B. GSM-, CDMA-, LTE-, usw. -Standards), eine Kurzbereichs-Drahtloskommunikation(SRWC)-Verbindung (z. B. Wi-Fi-, W-Fi-Direct-, Bluetooth-, usw. -Standards), andere Kommunikationstechniken oder eine beliebige Kombination davon.
  • Die Netzwerkverbindungen 44 können jede geeignete verdrahtete oder drahtlose Kommunikationseinrichtung beinhalten. Beispiele geeigneter nicht einschränkender Netzwerkverbindungen 44 beinhalten diskrete Verbindungen, eine Kommunikations- oder Entertainmentleitung, usw.; z. B. unter Verwendung eines Controller Area Networks (CAN), einer medienorientierten Systemübertragung (MOST), eines lokalen Kopplungsstrukturnetzwerks (LIN), eines lokalen Netzwerks (LAN) und anderen geeigneten Verbindungen, wie etwa Ethernet oder andere, die den bekannten ISO-, SAE- und IEEE-Standards und -Spezifikationen entsprechen.
  • In mindestens einer Ausführungsform ist eines der VSMs 42 die Fahrzeugtelematikeinheit 42a, die ein Software- und/oder Firmware-Update vom Fahrzeug-Backend-System 36 über eine Mobilfunkverbindung empfängt. Danach bestimmt die Telematikeinheit oder andere geeignete VSMs 42, ob das Update ausgeführt werden sollen, und wenn das Update ausgeführt wird, wird die Telematikeinheit 42a oder andere entsprechende VSMs 42 entsprechend aktualisiert. Selbstverständlich könnte das Update auf anderer Weise empfangen werden; z. B. über eine SRWC-Verbindung oder eine verdrahtete Kommunikationsverbindung.
  • Nun zurück zu 1 ist das Drahtlosträgersystem 14 bevorzugt ein Mobiltelefonsystem, das eine Vielzahl von Mobilfunkmasten, einen oder mehrere Mobilfunkknoten (z. B. eNodeBs, Mobilvermittlungsstellen oder dergleichen) sowie andere Netzwerkkomponenten beinhaltet, die erforderlich sind, um das Drahtlosträgersystem 14 mit dem Festnetz 26 und/oder dem Fahrzeug-Backend-System 36 (z. B. über einen oder mehrere Firewalls 16, 20, 24 und andere Komponenten) zu verbinden. Mobilfunkmaste, Mobilfunkknoten und sonstige Infrastruktur – sowie wie das System 14 verbunden und verwendet ist – ist in der Technik bekannt; daher werden hierin weder diese, noch die zum Durchführen verwendeten Prozesse, die über das Drahtlosträgersystem 14 kommunizieren, ferner beschrieben. Nicht einschränkende Beispiele von System 14 beinhalten analoge Technologien, wie etwa AMPS und/oder neuere Digitaltechnologien, wie etwa CDMA, CDMA2000, GSM/GPRS und LTE, um nur einige Beispiele zu nennen.
  • Die Trägersystem-Firewall 16 kann jede geeignete Firewall sein, die über einen Mobilfunk-Service-Provider (WSP) eingesetzt werden kann. Wie hierin verwendet, ist ein WSP eine Entität, die das Drahtlosträgersystem 14 verwendet, um einen Mobilfunkservice an Drahtlosabonnenten bereitzustellen oder zu ermöglichen. Drahtlosabonnent-Fahrzeuge können einen Abonnementvertrag direkt mit dem WSP oder, in mindestens einer Ausführungsform, einen Backend-Dienste-Vertrag mit dem Fahrzeug-Backend-System 36 aufweisen. Und das Fahrzeug- Backend-System 36 weist einen gesonderten Vertrag mit dem WSP auf, sodass der WSP einen Mobilfunkservice zwischen dem Fahrzeug 12 und dem Backend-System 36 bereitstellt oder ermöglicht. Auf diese Weise stellt das Backend-System 36 nicht nur Mobilverbindungen an das Fahrzeug 12 bereit, sondern stellt dem Fahrzeug auch eine breite Bandbreite von Diensten über das Backend selbst bereit – wie etwa das Bereitstellen von Firmware- und/oder Software-Updates an die Fahrzeugsystemmodule, Turn-by-Turn-Richtungen, Straßenrand- und/oder Notfallunterstützung, usw.
  • Somit beinhaltet die Trägersystem-Firewall 16 jede Hardware, Software oder Kombination aus diesen, die durch den WSP eingesetzt werden, um unerwünschte Verbindungen oder Drahtlosverbindungsverkehr zu verhindern oder abzuhalten – z.B. zwischen einer vertrauenswürdigen Quelle (z. B. dem Fahrzeug-Backend-System 36) und einer nicht vertrauenswürdigen Quelle (z. B. einem unbekannten oder nicht identifizierbaren Mobilfunkgerät). In mindestens einer Ausführungsform wird die Firewall 16 als Software verwendet – z.B. auf einem WSP-Computer oder -Server. Firewalls, sowie deren Ausführungsformen, sind auf dem Fachgebiet bekannt und werden hierin nicht erneut beschrieben.
  • Die WSP-DMZ 18 (auch als Umkreisnetzwerk bekannt) beinhaltet jedes geeignete Netz oder Teilnetz, das in einer Hardware, Software oder einer Kombination davon verwendet ist, um ein internes, lokales Netzwerk oder LAN (z. B. in Verbindung mit dem WSP oder Backend-System 36) von nicht vertrauenswürdigen Quellen (z. B. die, die versuchen sich über das Drahtlosträgersystem 14 verbinden) zu trennen. Normalerweise wird es als eine zusätzliche Sicherheitsebene um ein weites oder lokales Netzwerk verwendet, wie etwa Netzwerk 22. Nochmals, die DMZs, sowie deren Ausführungsformen, sind auf dem Fachgebiet bekannt und werden hierin nicht erneut beschrieben.
  • Die erste und zweite Firewall 20, 24 umfassen alle geeigneten Firewalls, die durch das Backend-System 36 verwendet werden. Die Firewalls 20, 24 können so angepasst werden, um das Backend-System 36 von jeweils dem Drahtlosträgersystem 14 und dem Festnetz 26 zu trennen. In mindestens einer Ausführungsform kann die Firewall 20 gleich oder ähnlich Firewall 24 sein (d. h., die Firewalls 20, 24 können so angepasst sein, um das übrige Backend-System 36 von jeweils dem Drahtlosträgersystem 14 und dem Festnetz 26 zu trennen).
  • Ein sicheres Netzwerk 22 kann jedes geeignete Netz hinter den Firewalls 20, 24 und der Träger-Firewall 16 und DMZ 18 sein. Das sichere Netzwerk 22 kann einen oder mehrere Server oder vernetzte Computer beinhalten sowie eine Anzahl der Speichervorrichtungen – die alle durch die DMZ 18 und/oder die Firewalls 16, 20, 24 geschützt sind. Ein sicheres Netzwerk und dessen Ausführungsform und Verwendung sind Fachleuten offensichtlich bekannt und werden damit hierin nicht näher erläutert.
  • Das Festnetz 26 kann ein konventionelles landgebundenes Telekommunikationsnetzwerk sein, das mit einem oder mehreren Festnetztelefonen verbunden ist. So kann beispielsweise das Festnetz 26 ein Fernsprechnetz (PSTN) wie etwa jenes sein, das verwendet wird, um festverdrahtetes Fernsprechen, paketvermittelte Datenkommunikationen und die Internetinfrastruktur bereitzustellen. Ein oder mehrere Segmente des Festnetzes 26 könnten durch Verwenden eines normalen drahtgebundenen Netzwerks, eines Lichtleiter- oder eines anderen optischen Netzwerks, eines Kabelnetzes, von Stromleitungen, anderen drahtlosen Netzwerken, wie etwa drahtlose lokale Netzwerke (WLANs) oder Netzwerke, die drahtlosen Breitbandzugang (BWA) bereitstellen oder jeder Kombination davon implementiert sein. Wie in 1 gezeigt, kann das sichere Netzwerk 22 mit dem Festnetz 26 verbunden und in einigen Fällen kann das Festnetz 26 direkt mit dem Drahtlosträgersystem 14 verbunden werden.
  • Der Backend-E-Mail-Server 28 beinhaltet einen oder mehrere Computer, die so konfiguriert sind, um E-Mail-Nachrichten an telematikfähige Fahrzeuge (wie etwa Fahrzeug 12) zu empfangen und zu senden. Zusätzlich können E-Mail-Nachrichten, die vom Backend-E-Mail-Server 28 bereitgestellt werden, ein oder mehrere Software- und/oder Firmware-Updates (wie etwa ein Reflash-Update) beinhalten. Bei einigen Ausführungsformen wird das gleiche Update vom Backend-System 36 (z. B. gleichzeitig oder etwa auf diese Art und Weise) an mehrere Fahrzeuge übertragen. In einigen Fällen, wie nachfolgend beschrieben, werden die Zielfahrzeuge (oder ECUs von vielen Fahrzeugen) vorerst über das Backend-System 36 identifiziert; dann wird das Update an die spezifischen Zielfahrzeuge übertragen. Das Backend-System 36 kann die Zielfahrzeuge beispielsweise unter Verwendung einer E-Mail-Adresse (z. B. VIN@domain_name.com, wo VIN ist die Identifikation Fahrzeug Anzahl), einer VSM-Kennung, einer ECU-Kennung, einer Software- oder Firmware-Versionskennnung oder dergleichen identifizieren oder adressieren. Wenn das Zielfahrzeug eine Mobilverbindung (z. B. und einen Drahtlosabonnentvertrag) aufweist, kann die E-Mail an das Zielfahrzeug übertragen werden. Wenn jedoch das Zielfahrzeug in mindestens einigen Beispielen keine Mobilverbindung und/oder keinen Mobilfunkabonnentvertrag mit dem Backend-System aufweist, kann die E-Mail-Nachricht an das Zielfahrzeug übertragen werden, erreicht jedoch vielleicht nicht das jeweilige Zielfahrzeug (z. B. kann die E-Mail-Nachricht unzustellbar sein).
  • Der Backend-E-Mail-Server 28 beinhaltet einen Mail-Server 54, die einen konventionellen Mail Transfer Agent (MTA), einen konventionellen Mail Delivery Agent (MDA) oder beide verwenden kann. Der Mail-Server 54 kann Teil des Servers 28 oder eine getrennte Computervorrichtung sein. Weitere Server 28 beinhalten einen Anhang-Server 56, der so angepasst, um zu bestimmen, welche Fahrzeuge 12 veraltet ECU-Firmware oder Software aufweisen. Der Anhang-Server 56 kann so konfiguriert sein, um den Empfangszeitpunkt des Updates (z. B. ausgehende E-Mail) zu steuern sowie um zu bestimmen, ob Updates in den entsprechenden Fahrzeugen 12 (z. B. Empfangsbestätigungsbenachrichtigungen) empfangen und/oder installiert wurden. Zusätzlich kann der Anhang-Server 56 die E-Mail-Nachrichten ver- und/oder entschlüsseln, die dazwischen, gemäß einer geeigneten Technik, kommuniziert wird, wenn E-Mail-Kommunikation zwischen dem Backend-E-Mail-Server 28 und dem Fahrzeug 12, stattfinden. Wie Server 54 kann der Anhang-Server 56 Teil des Servers 28 oder eine getrennte Computervorrichtung sein.
  • Der Backend-E-Mail-Server 28 kann andere Computer und Server beinhalten und/oder angepasst werden, um auch andere Funktionen oder Dienste auszuführen (z. B. kann er einen oder mehrere statische und/oder dynamische Domänennamensserver beinhalten). Jeder der Computer und Server in Verbindung mit dem Backend-E-Mail-Server 28 können nicht-flüchtige Speichermedien oder Speicher 58 und einen oder mehrere Prozessoren oder Verarbeitungseinheiten 60 beinhalten und der/die jeweilige/n Prozessor/en 60 kann/können so angepasst werden, um Anweisungen auszuführen, die in der Hardware, Software oder einer Kombination davon konfiguriert sind. Der Anhang-Server 56 kann beispielsweise Softwareanweisungen zur Bestimmung von Updates für verschiedene Fahrzeuge (z. B. für ECUs, wie etwa ECU 46) und Softwareanweisungen in Verbindung mit E-Mail-Empfang an solche Fahrzeuge beinhalten. Diese Anweisungen können die Verschlüsselung von Updates innerhalb einer E-Mail-Nachricht, die Verschlüsselung der E-Mail selbst oder beides beinhalten.
  • Andere Anweisungen, die durch den Backend-E-Mail-Server 28 verwendet werden, können Anweisungen beinhalten, die mit der Speicherung der empfangenen Update-Inhalte, den Empfangszeiten (z. B. einschließlich geplanten Empfangszeiten), Empfangsbestätigungen (z. B. von den entsprechenden Fahrzeugen 12) usw. in Verbindung stehen. Beispielsweise steht mindestens ein Computer von Server 28 mit einer Dateiverzeichnisstruktur für mehrere Fahrzeuge in Verbindung; z. B. worin die Struktur Update-Inhalte speichert (z. B. in Verbindung mit Updates) und mit unterschiedlichen Fahrzeugherstellern, Modellen, VSMs 42, VSM-ECUs 46, usw. in Verbindung steht. Der Update-Inhalt kann für einen zuvor festgelegten Zeitraum (z. B. 15 Jahre, 20 Jahre, usw.) gespeichert werden. Zusätzlich können andere Backend-E-Mail-Serveranweisungen interaktive Software beinhalten, um die Inhalte des E-Mail-Übertragungsservers 30 zu bestimmen (beispielsweise den Inhalt und die Größe der ausstehenden Nachrichten, die darin gespeichert sind, der Speicherzeitraum der ausstehenden Nachrichten, jeder Status, der mit den ausstehenden Nachrichten in Verbindung steht, usw.).
  • In mindestens einer Ausführungsform umfasst der Backend-E-Mail-Server 28 ferner mindestens einen Computer oder Server zum Durchführen einer Datenanalyse. Dieser Computer oder Server kann beispielsweise so konfiguriert sein, um die von einem oder mehreren Fahrzeugen (wie etwa Fahrzeug 12) empfangenen Daten zu sammeln, zu erstellen, zu interpretieren und zu präsentieren. Die ausgewerteten Daten können dann für verschiedene Zwecke verwendet werden. In einem nicht einschränkenden Beispiel können derartige ausgewertete Daten Diagnosefehlercode(DTC)-Daten beinhalten, die mit Software- und/oder Firmware-Updates an einem oder mehreren Fahrzeugen in Verbindung stehen. Nach der Erstellung, Sammlung, Interpretation, usw., können die ausgewerteten Daten dem Fahrzeugbenutzer, Technikern und Ingenieuren oder beiden präsentiert werden, die in Verbindung mit dem Backend-System 36 stehen. Die ausgewerteten Daten können an das Festnetz 26, das Drahtlosträgersystem 14 oder beide übertragen werden und danach unter Verwendung mindestens einer elektronischen Vorrichtung 34 empfangen werden.
  • Nun zum Inhalt-Empfangsserver 30, gezeigt in 1 (auch Teil eines Backend-Systems 36), der Inhalt-Empfangsserver 30 beinhaltet einen Mail-Cache-Server 62 und arbeitet gemäß eines Network Time Protocols (NTP) und Datenverlustpräventions(DLP)-Techniken. Der Mail-Cache-Server 62 beinhaltet einen oder mehrere Computer, die in Hardware, Software oder dergleichen konfiguriert sind, um E-Mail-Nachrichten, die Software- und/oder Firmware-Updates enthalten, zu empfangen und zu speichern. Der Server 62 kann beispielsweise die Updates vom Backend-E-Mail-Server 28 (z. B. insbesondere vom Mail-Server 54) empfangen. Der Speicherdauer am Cache-Server 62 kann variieren – z.B. abhängig von der Mobilverbindung des Fahrzeugs 12. In einer Ausführungsform können diese E-Mail-Nachrichten beispielsweise gespeichert werden, bis das Fahrzeug 12 wieder mit einem Backend-Dienste-Vertrag in Verbindung steht. In einer anderen Ausführungsform ist die Dauer des E-Mail-Nachrichtenspeichers begrenzt oder eingeschränkt; das heißt, für nicht länger als eine zuvor festgelegte Zeitdauer (z. B. 15 Jahre, 20 Jahre usw.).
  • Es sollte beachtet werden, dass wenn das Fahrzeug 12 mit einem aktiven Backend-Dienste-Vertrag in Verbindung steht, die Software- und/oder Firmware-Updates vom Backend-E-Mail-Server 28 des Fahrzeugs 12 übertragen werden können (z. B. über das sichere Netzwerk 22, die erste Firewall 20, die Träger-Firewall 16 und die DMZ 18 und das Drahtlosträgersystem 14). Und wenn das Fahrzeug 12 nicht mit einem Backend-Dienste-Vertrag in Verbindung steht (d. h., derzeit kein Abonnentfahrzeug oder ein vorheriges Abonnentfahrzeug war, für welches der Abonnementvertrag abgelaufen ist), werden die Software- und/oder Firmware-Updates nicht vom Fahrzeug 12 empfangen, sondern an den Mail-Cache-Server 62 übertragen und dort gespeichert (z. B. vom Mail-Server 54 über das sichere Netzwerk 22, die erste Firewall 20 und die Träger-DMZ 18 zum Mail-Cache-Server 62 übertragen). In einigen Ausführungsformen kann der Mail-Cache-Server 62 selbstverständlich auch E-Mail-Nachrichten kurzzeitig während der Fahrzeugnetztrennung speichern und versuchen nach kurzer Zeit erneut zu senden – z.B., während das Fahrzeug aufgrund eines entfernten Standorts, wie einem unterirdischen Parkhaus, usw., vom Netz getrennt ist.
  • Der Inhalt-Empfangsserver 30 kann konventionelle NTP-Techniken – z. B. kann er Interaktionen zwischen dem Cache-Server 62 und der Telematikeinheit 42a synchronisieren. Ferner kann unter Verwendung von herkömmlichen DLP-Techniken die Plattform 30 Datensicherheitsverstöße identifizieren und minimieren, die mit E-Mail-Nachrichten, die vom Cache-Server 62 übertragen werden, in Verbindung stehen.
  • Der Mail-Cache-Server 62 (sowie alle anderen Computer oder Server in Verbindung mit Server 30) kann alle geeigneten nicht-flüchtigen Speichermedien oder Speicher 64 und einen oder mehrere Prozessoren oder Verarbeitungseinheiten 66 beinhalten und der/die jeweilige/n Prozessor/en 66 kann/können so angepasst werden, um Anweisungen auszuführen, die in der Hardware, Software oder einer Kombination davon konfiguriert sind. Der Mail-Cache-Server 62 kann beispielsweise Softwareanweisungen zum Speichern eines oder mehrerer Zwischen-Updates für verschiedene Fahrzeuge, VSMs 42, ECUs 46, etc., beinhalten – z. B. in einem Dateiverzeichnis oder dergleichen. Wie nachfolgend erläutert wird, wenn Zwischen-Updates (wenn dieses im Cache-Server 62 gespeichert ist) später an das Fahrzeug 12 übertragen werden, kann der Cache-Server 62 so konfiguriert sein, um die Installation des Updates am Zielfahrzeug (z. B. Fahrzeug 12) zu steuern oder zu regulieren. In einer Ausführungsform kann der Cache-Server 62 beispielsweise eine gewünschte Anordnung oder Reihenfolge bestimmen, bei welcher die Updates an das Fahrzeug 12 bereitgestellt werden – und dann stellt er die Updates in dieser Reihenfolge bereit. Der Cache-Server 62 kann die Übertragung der Zwischen-Updates zwischenspeichern, um Zeit für die Installation zu ermöglichen oder der Cache-Server 62 kann vom Fahrzeug 12 eine Bestätigung erhalten, dass ein vorheriges Updates empfangen wurde und vor dem Senden eines anschließenden Updates an das Fahrzeug 12 installiert wurde. In einer anderen Ausführungsform kann der Cache-Server 62 die gewünschte Reihenfolge bestimmen und dann zusätzliche Daten an Fahrzeug 12, zusammen mit den gespeicherten E-Mail-Nachrichten, bereitstellen. Der Cache-Server 62 kann beispielsweise das Fahrzeug 12 zum Installieren der Update-Nachrichten in einer vorbestimmten Reihenfolge beauftragen oder anweisen oder (d. h., zuvor festgelegt durch Cache-Server 62 oder eine andere Backend-System-Komponente). Danach kann das Fahrzeug 12 diese Anweisungen aus dem Cache-Server 62 empfangen und die Updates aufeinanderfolgend installieren – gemäß den Anweisungen/ dem Befehl. In anderen Anwendungen kann eine Kombination dieser Verfahren verwendet werden. Es werden hierin weitere Techniken betrachtet.
  • In mindestens einer Ausführungsform kann der Backend-E-Mail-Server 28 Informationen sammeln und ein Protokoll von Interaktionen zwischen dem Fahrzeug 12 und dem Mail-Cache-Server 62 pflegen. Der Backend-E-Mail-Server 28 kann beispielsweise eine Vielzahl von Information bezüglich des Abonnentstatus des Fahrzeugs 12 speichern und protokollieren; nicht einschränkende Beispiele beinhalten: die Softwareversionen der ECUs 46 im Fahrzeug 12; die Updates, die durch und/oder im Fahrzeug 12 installiert werden; Übertragungs- und Installationsbestätigungen von Fahrzeugs 12, die anzeigen, dass ein bestimmtes Update installiert wurde und darin implementiert ist; jede ausstehenden Software- und/oder Firmware-Updates (z. B. die, die im Mail-Cache-Server 62 gespeichert sind); und dergleichen. Ferner kann dieses Datenprotokoll für das jeweilige Fahrzeug regelmäßig aktualisiert und diese Vorgehensweise für jedes geeignete Fahrzeug durchgeführt werden. In mindestens einer Ausführungsform wird diese Vorgehensweise für alle telematikfähigen Fahrzeuge durchgeführt, die von einem Hersteller für eine zuvor festgelegte Dauer hergestellt und veräußert werden, unabhängig davon, ob alle telematikfähigen Fahrzeuge Abonnentfahrzeuge sind.
  • Es sollte beachtet werden, dass unter Verwendung des Cache-Servers 62 (der sich außerhalb des sicheren Netzwerks 22 befindet) die Backend-Sicherheit verbessert werden kann. Der Cache-Server 62 kann beispielsweise so angepasst werden, um an zahlreichen direkten, bidirektionalen Kommunikationen mit externen Entitäten teilzunehmen, die gegebenenfalls böswillig sind, wobei der Mail-Server 28, der sich innerhalb des sicheren Netzwerks 22 (z. B. und hinter zusätzliche Firewalls 20, 24) befinden, weniger mit derartigen externen Einheiten kommunizieren sollte, wodurch potenziell feindliche oder böswillige Angriffe auf das Backend-System 36 minimiert werden.
  • 1 veranschaulicht auch die elektronische Vorrichtung 34 – die hier als persönlicher Computer gezeigt ist. Diese Vorrichtung 34 kann jede geeignete Vorrichtung sein, die durch einen Fahrzeugbenutzer verwendet wird (z. B. einen Eigentümer, Mieter oder eine andere berechtigte Person, die autorisiert ist, das Fahrzeug 12 zu verwenden). Oder die Vorrichtung 34 kann jede geeignete Vorrichtung (oder Vorrichtungen) sein, die durch Ingenieure, Service-Techniker und dergleichen verwendet wird. In mindestens einer Ausführungsform ist die Vorrichtung 34 zum Empfangen von ausgewerteten Daten aus dem Backend-E-Mail-Server 28 angepasst (z. B. in Verbindung mit installierten und/oder ausstehenden Updates, veralteten Software- und/oder Firmware-Versionen in einem zugehörigen ECU eines Fahrzeugs, usw.). In einer Ausführungsform kann die Vorrichtung 34 beispielsweise von einem autorisierten Benutzer des Fahrzeugs 12 verwendet werden, was dem Benutzer ermöglicht, Informationen bezüglich des Status jeglicher zugeordneter Fahrzeug-Updates zu empfangen.
  • Nicht einschränkende Beispiele für die elektronische Vorrichtung 34 beinhalten ein Mobiltelefon, einen persönlichen digitalen Assistenten (PDA), ein Smartphone, einen persönlichen Laptop-Computer oder Tablet-Computer mit Zwei-Wege-Kommunikationsfähigkeiten, einen Netbook-Computer, ein Notebook oder geeignete Kombinationen davon. In mindestens einer Ausführungsform umfasst die Vorrichtung 34 Anwendungssoftware, die es der Vorrichtung 34 ermöglicht, mit dem Backend-System 36 über das Festnetz 26, Drahtlosträgersystem 14, usw. zu kommunizieren.
  • Verfahren –
  • Nun zu 3, worin ein Verfahren 300 gezeigt ist, in dem ferngesteuerte Modul-Updates für ein Fahrzeugsystem bereitgestellt werden. Das Verfahren beginnt mit Schritt 305, worin ein Abonnementvertrag – z. B. ein Backend-Dienste-Vertrag – zwischen einer Benutzer des Fahrzeugs 12 und dem Backend-System 36 eingerichtet ist (nachfolgend wird das Fahrzeug als Abonnentfahrzeug bezeichnet, wenn der Benutzer eine Vertragspartei ist). In einigen Ausführungsformen kann der Backend-Dienste-Vertrag zum Zeitpunkt des Fahrzeugkaufs oder der Fahrzeugvermietung auftreten – z. B. kann dem Benutzer ein Abonnement für einen ersten Zeitraum oder ein Probezeitabonnement veräußert werden. In anderen Fällen kann der Backend-Dienste-Vertrag jederzeit eingerichtet werden, während der Nutzungsdauer des Fahrzeugs 12. Es sollte beachtet werden, dass dieser Vertrag in einer Ausführungsform nur für Fahrzeug 12 mit einer Telematikeinheit 42a (oder Fahrzeuge wie diesem) angewendet werden kann – z. B., worin Einheit 42a mindestens einen Mobilfunkchipsatz beinhaltet. Auf diese Weise wird der Chipsatz aktiviert und vom WSP verwendet und mit dem Backend-Dienste-Vertrag verbunden. Während das Abonnement aktiv ist, kann das Fahrzeug 12 Software- und/oder Firmware-Updates in E-Mail-Nachrichten vom Backend-E-Mail-Server 28 empfangen, wenn derartige Updates verfügbar sind. Nach Empfang der Nachricht(en) kann das Fahrzeug 12 derartige E-Mail-Nachrichten vom Backend-System 36 herunterladen (z. B. dem E-Mail-Server 28), Updates extrahieren (z. B. welche Entschlüsselung benötigen oder nicht) und dann die Updates installieren. Bereits während eines Abonnementzeitraums kann die Reihenfolge der Installation derartiger Updates geregelt sein je nachdem, wann das Fahrzeug E-Mail-Nachrichten vom Server 28 empfängt.
  • Im folgenden Schritt 310 läuft der Abonnementvertrags ab. Nicht einschränkende Beispiele beinhalten: der Benutzer des Fahrzeugs 12 beendet den Vertrag aktiv, das Backend-System 36 beendet den Vertrag aktiv, der Vertrag wird nicht erneuert, usw. In einigen Fällen erfolgt dies, wenn das Fahrzeug 12 an einen neuen Benutzer übertragen wird; und bei anderen Malen erfolgt dies beim gleichen Benutzer. Während des Abonnementzeitraums – unabhängig vom Grund für das Ablaufen – werden die Backend-Dienste abgebrochen oder begrenzt. Somit ist das Mobilfunkchipsatz in mindestens einer Ausführungsform möglicherweise nicht zum Empfangen von Software- und/oder Firmware-Updates vom Backend-System fähig.
  • Beim Ablauf des Zeitraums kann das Backend-System 36 ein oder mehrere neue Software- und/oder Firmware-Updates für Fahrzeug 12 freigeben – oder insbesondere für ein oder mehrere der ECUs 46 in den VSMs 42. In Schritt 315 kann das Backend-System 36 diese Updates an den Backend-E-Mail-Server 28 bereitstellen (z. B. insbesondere an Mail-Server 54). Für jedes Update, das von Mail-Server 54 empfangen wird, kann Server 54 bestimmen, ob das Update für Fahrzeug 12 angewendet wird. Durch diese Bestimmung kann Server 54 die VSMs 42, ECUs 46, zuletzt installierte Software- und/oder Firmware-Versionen auf VSMs/ ECUs, usw. des Fahrzeugs 12 bestimmen. Wenn Server 54 bestimmt, dass das Update gilt, kann er eine E-Mail-Nachricht generieren, die das Software- und/oder Firmware-Update beinhaltet; und in manchen Fällen kann ein Teil der E-Mail-Nachricht verschlüsselt sein.
  • Im folgenden Schritt 320 kann der Backend-E-Mail-Server 28 (z. B. dem Mail-Server 54) bestimmen, dass kein aktiver Backend-Dienste-Vertrag für das Fahrzeug 12 vorliegt und folglich die E-Mail-Nachricht, die das Update des Inhaltempfangsservers 30 enthält (z. B. insbesondere den Cache-Server 62), übertragen. Somit kann die Übertragung über das sichere Netzwerk 22 durch Firewall 20 und die Träger-DMZ 18 zum Server 30 gesendet werden. In einer anderen Ausführungsform kann der Backend-E-Mail-Server 28 versuchen die Benachrichtigung an Fahrzeug 12 zu senden; die Nachricht wird jedoch als unzustellbar bestimmt (z. B. aufgrund fehlender Konnektivität). Eine Bounce-Nachricht, die den Status unzustellbar anzeigt, kann empfangen werden; danach kann die Nachricht an den Cache-Server 62 bereitgestellt werden.
  • Nach Empfang der E-Mail-Nachricht am Cache-Server 62 kann Server 62 die E-Mail-Nachricht mit den zugehörigen Software- und/oder Firmware-Updates [Schritt 325] speichern. In einer Ausführungsform versucht Cache-Server 62 regelmäßig eine Übertragung an Fahrzeug 12. Und in mindestens einer anderen Ausführungsform speichert Cache-Server 62 die E-Mail-Nachrichten, bis durch den Backend-E-Mail-Server 28 veranlasst werden, um diese an das Fahrzeug 12 zu übertragen.
  • In Schritt 330 wird der Backend-Dienste-Vertrag erneuert oder anderweitig wieder aktiv. Beispielsweise kann der ursprüngliche Benutzer die Dienste erneuern. Oder ein anderer Benutzer (z. B. ein zweiter Eigentümer) richtet seinen/ihren ersten Vertrag mit Backend-System 36 ein. Andere Arten der Einrichtung eines solchen Vertrags mit Fahrzeug 12 sind denkbar.
  • Als Reaktion auf Schritt 330 kann der Inhaltempfangsserver 30 (z. B. insbesondere Cache-Server 62) veranlasst werden, die gespeicherten E-Mail-Nachrichten mit den Updates [Schritt 335] zu übertragen. Diese Veranlassung kann vom Backend-E-Mail-Server 28 oder einem anderen geeigneten Computer oder Server in Verbindung mit Backend-System 36 stammen.
  • In Schritt 340 bestimmt Inhaltempfangsserver 30 eine geeignete Installationsreihenfolge oder Reihenfolgen für die E-Mail-Nachrichten (und/oder ihre jeweiligen Updates). 4 veranschaulicht Cache-Server 62, der mehrere Benachrichtigungen 70 für das Zielfahrzeug 12 speichert. Die Benachrichtigungen 70 können in jeder Anordnung gespeichert werden – chronologisch oder anderweitig. 4 zeigt auch, dass Server 62 in Schritt 340 eine Reihenfolge oder wünschenswerte Anordnung bestimmen kann, um die Updates im Fahrzeug 12 (siehe Benachrichtigungen 70’) zu installieren. In mindestens einer Ausführungsform sind die Benachrichtigungen 70’ chronologisch durch den Cache-Server 62 organisiert. In mindestens einer Ausführungsform kategorisiert Cache-Server 62 die E-Mail-Nachrichten gemäß dem ECU 46, welches eine Aktualisierung benötigt. Es werden beziehungsweise mehrere Reihenfolgen für jedes der VSMs 42 und ihre jeweiligen ECUs 46 ermittelt. Die Benachrichtigungen C31, C32, C33, C34 können das Mittelkonsolenmodul oder das Fahrzeug-Kopfeinheit-VSM 42 betreffen; somit werden die Software- und/oder Firmware-Updates C31 zuerst installiert, dann C32 ... und schließlich C34. Cache-Server 62 kann das Fahrzeug 12 nochmal zum Installieren in dieser Reihenfolge anweisen. Oder Cache-Server 62 kann diese Benachrichtigungen nacheinander übertragen – wobei die darauffolgende Benachrichtigung 70’ nicht installiert wird, bevor die Installation des vorherigen Updates bestimmt ist. Ähnliche Verfahren können für die Benachrichtigungen B04, B05, B06 für ein Bremsanlage-VSM 42 und T22, T23 für das Telematikeinheit-VSM 42a. durchgeführt werden.
  • Es sollte beachtet werden, dass die Installation der Updates am Fahrzeug 12 für getrennte VSMs 42 in einigen Fällen gleichzeitig auftreten kann, wenn gewünscht. C31 könnte beispielsweise gleichzeitig mit T22 installiert werden, wogegen T22 nicht gleichzeitig mit T23 installiert werden kann. Ferner begrüßen Fachleute, dass einige Updates nicht von der zeitlichen Reihenfolge der Installation abhängen, während andere dies tun. Somit kann Cache-Server 62 die Installation aller Updates in einer bestimmten Reihenfolge in einigen Fällen nicht regeln. In einer anderen Ausführungsform könnten Updates nach anderen Prioritäten installiert werden. Eine nicht einschränkendes Beispiel könnte eine Reihe von Updates sein, die die Sicherheit des Fahrzeugs betreffen. Wenn die Updates B04–B06 an das Bremssystem-VSM 42 beispielsweise eine höhere Priorität als die Mittelkonsole-VSM-Nachrichten C31–C34 aufweisen, dann könnten die Updates in Verbindung mit der Bremsanlage zuerst installiert werden.
  • Zurück zu 3, sobald der Cache-Server 62 eine gewünschte Anordnung oder Reihenfolge der Installation bestimmt hat, kann Server 62 in Schritt 350 diese E-Mail-Nachrichten 70’ des Fahrzeugs 12 übertragen. Cache-Server 62 kann die Benachrichtigungen 70’ über die Träger-DMZ 18, die Träger-Firewall 16 und das Drahtlosträgersystem 12 an Fahrzeug 12 senden.
  • In Schritt 355 kann Fahrzeug 12 die E-Mail-Nachrichten herunterladen und empfangen, ein Update(s) aus jeder Nachricht extrahieren und die Updates aufeinanderfolgend nach den Anweisungen des Cache-Server 62 installieren. Wenn der Cache-Server 62 hingegen mindestens einige der Updates einzeln bereitstellt (z. B. jeweils ein oder zwei), kann Fahrzeug 12 diese so installieren, wie es diese empfängt. Es sollte beachtet werden, dass Fahrzeug 12 diese Updates über eine Mobilfunkübertragung und über den Mobilfunkchipsatz innerhalb der Telematikeinheit 42a empfängt. Nach Empfang können die Updates an das entsprechende VSM 42 über Netzwerkverbindung 44 verteilt und dann gemäß Fachleuten bekannten Techniken installiert werden.
  • In mindestens einigen Ausführungsformen ist das Update ein Reflash-Update, das das bestimmte VSM 42 während der Installation unbedienbar oder unbrauchbar werden lassen. Das Fahrzeug 12 kann fahrbar sein, wenn das Mittelkonsole-VSM 42 umprogrammiert wird – obwohl das Modul eventuell keine Musik oder eine andere Form von Entertainment-Audio- oder -Video während der Installation bereitstellt. Jedoch können andere VSMs 42 den Stillstand des Fahrzeugs während der Umprogrammierung erfordern. In einigen Update-Installationen (z. B. ein derartiges Reflash-Update des Bremsanlage-VSMs 42) kann das Fahrzeug unbedienbar sein oder die Übertragung muss sich während der Installation mindestens in der in PARKSTELLUNG befinden. In einer Ausführungsform kann Fahrzeug 12 den Fahrzeugbenutzer am Betrieb des Fahrzeugs 12 während der Installation hindern.
  • Nach Schritt 355 kann das Verfahren 300 enden. In mindestens einer Ausführungsform kann die Installation der Updates am/an den VSM/VSMs 42 über eine oder mehrere elektronische Vorrichtungen 34 (z. B. über das Internet) bereitgestellt werden. Der Server 28 kann beispielsweise gesammelte Fahrzeugdaten bereitstellen, die das/die installierte/n Update/s anzeigen, sowie andere Fahrzeuginformationen, wie etwa ausstehende Updates (Updates, die sich in E-Mails des Cache-Servers 30 befinden), veraltete Software- und/oder Firmware-Versionen in einem zugehörigen Fahrzeug-ECU und dergleichen.
  • Es sind auch andere Ausführungsformen vorhanden. In den obigen Beispielen bestimmt und/oder weist der Inhaltempfangsserver 30 das Fahrzeug 12 zum Installieren der Updates in einer bestimmten Anordnung oder Reihenfolge an. Dieser Anweisung könnte jedoch vom Backend-E-Mail-Server 28 oder stattdessen von einem anderen geeigneten Backend-Server stammen. Wenn das Fahrzeug beispielsweise wieder ein Abonnentfahrzeug ist, könnte der Server 28 ein instruktive E-Mail direkt an Fahrzeug 12 (über das sichere Netzwerk 22, Firewalls, 16, 20, DMZ 18 und das Drahtlosträgersystem 12) senden. Die instruktiven E-Mails beinhalten eine Reihe von Updates, die vom Cache-Server 62 empfangen werden und eine Reihenfolge, wie diese installiert werden sollen. Dementsprechend könnten die VSMs 42 im Fahrzeug 12 diese in dieser Reihenfolge installieren.
  • Somit wurde ein Verfahren zur Bereitstellung von ferngesteuerten Updates an Fahrzeugsystemmodule beschrieben. Ferner wurde ein Verfahren zum Empfangen derartiger Updates und dem Installieren dieser in das Fahrzeug beschrieben. In mindestens einigen Ausführungsformen werden die Updates am Fahrzeug in einer vorbestimmten Reihenfolge installiert – z. B. in gemäß den Anweisungen oder Verfahren eines Backend-E-Mail-Servers, eines Inhaltempfangsservers oder beider.
  • Es ist zu beachten, dass das Vorstehende eine Beschreibung einer oder mehrerer Ausführungsformen der Erfindung ist. Die Erfindung ist nicht auf die besondere(n) hierin offenbarte(n) Ausführungsform(en) beschränkt, sondern ausschließlich durch die folgenden Patentansprüche definiert. Darüber hinaus beziehen sich die in der vorstehenden Beschreibung gemachten Aussagen auf bestimmte Ausführungsformen und sind nicht als Einschränkungen des Umfangs der Erfindung oder der Definition der in den Patentansprüchen verwendeten Begriffe zu verstehen, außer dort, wo ein Begriff oder Ausdruck ausdrücklich vorstehend definiert wurde. Verschiedene andere Ausführungsformen und verschiedene Änderungen und Modifikationen an der/den ausgewiesenen Ausführungsform(en) sind für Fachleute offensichtlich. Alle diese anderen Ausführungsformen, Änderungen und Modifikationen sollten im Geltungsbereich der angehängten Patentansprüche verstanden werden.
  • Wie in dieser Spezifikation und den Patentansprüchen verwendet, sind die Begriffe „z. B.“, „beispielsweise“, „zum Beispiel“, „wie etwa“ und „wie“ und die Verben „umfassend“, „einschließend“ „beinhaltend“ und deren andere Verbformen, wenn sie in Verbindung mit einer Auflistung von einer oder mehreren Komponenten oder anderen Elementen verwendet werden, jeweils als offen auszulegen, was bedeutet, dass die Auflistung andere zusätzliche Komponenten oder Elemente nicht ausschließt. Andere Begriffe sind in deren weitesten vernünftigen Sinn auszulegen, es sei denn, diese werden in einem Kontext verwendet, der eine andere Auslegung erfordert.

Claims (10)

  1. Verfahren zum ferngesteuerten Bereitstellen von Modul-Updates eines Systems für ein Fahrzeug, umfassend die Schritte: Erzeugen einer elektronischen Nachricht (E-Mail) auf einem Fahrzeug-Backend-System, das ein Update für ein erstes Fahrzeugsystemmodul (VSM) im Fahrzeug beinhaltet; Speichern der E-Mail auf einem Mail-Cache-Server, wobei der Cache-Server mit dem Backend-System in Verbindung steht; und wenn das Fahrzeug mit einem Backend-Dienste-Vertrag in Verbindung steht, liefert es dann die gespeicherte E-Mail aus dem Cache-Server an das Fahrzeug über eine Mobilfunkverbindung, sodass das Update am ersten VSM angewendet werden kann.
  2. Verfahren nach Anspruch 1, worin die E-Mail auf einem Mail-Server in Verbindung mit einem sicheren Netzwerk erzeugt wird, worin sich der Cache-Server außerhalb des sicheren Netzwerkes befindet.
  3. Verfahren nach Anspruch 2, worin die E-Mail an das Fahrzeug unter Verwendung einer Fahrzeugkennung, einer VSM-Kennung oder einer elektronischen Steuergerät(ECU)-Kennung adressiert ist.
  4. Verfahren nach Anspruch 3, worin die E-Mail unter Verwendung eines Domänennamens und einer Kennung adressiert ist, die eine Fahrzeug-Identifizierungsnummer (VIN) ist.
  5. Verfahren nach Anspruch 1, ferner umfassend den Versuch des Übertragens der E-Mail an das Fahrzeug, wobei eine Anzeige, empfangen wird, dass die E-Mail nicht an das Fahrzeug gesendet und danach auf dem Cache-Server gespeichert wurde.
  6. Verfahren nach Anspruch 1, ferner umfassend das Speichern mehrerer ähnlich erzeugter Emails auf dem Cache-Server, worin einige der E-Mails mit dem Fahrzeug und andere E-Mails mit anderen Fahrzeugen in Verbindung stehen.
  7. Verfahren nach Anspruch 1, ferner umfassend: das Speichern mehrerer ähnlich erzeugter Emails auf dem Cache-Server für das Fahrzeug, worin mindestens einige der E-Mails unterschiedliche Updates für das erste VSM oder ein zweites VSM umfassen; das Bestimmen einer Installationsreihenfolge von mindestens einigen der Updates, die mit den E-Mails in Verbindung stehen; und das Übertragen der E-Mails an das Fahrzeug mit einer Anweisung zum Installieren mindestens einiger der Updates in einer vordefinierten Reihenfolge oder das Übertragen der E-Mails in einer bestimmten Reihenfolge, worin eine nächste sequentielle E-Mail nicht an das Fahrzeug übertragen wird, bis eine vorherige sequentielle E-Mail empfangen ist und dessen entsprechende Updates in einem der ersten oder zweiten VSMs installiert ist.
  8. Verfahren nach Anspruch 7, worin die Installation jedes Updates auf dem Backend-System protokolliert ist.
  9. Verfahren nach Anspruch 1, ferner umfassend das Bereitstellen eines Zugriffs auf die Fahrzeugdaten über eine Internetverbindung, die mit dem Update in Verbindung stehen.
  10. Verfahren zum Empfangen von Modul-Updates eines Systems für ein Fahrzeug von einem ferngesteuerten Backend-System, umfassend die Schritte: Beenden des Empfangens einer E-Mail vom Backend-System folglich eine Beendigung eines Backend-Dienste-Vertrags zwischen einem Benutzer des Fahrzeugs und dem Backend-System; dann, Empfangen einer E-Mail im Fahrzeug über eine Mobilfunkverbindung vom Cache-Server, der die E-Mail während eines Ablaufzeitraums des Abonnements gespeichert hat; Extrahieren eines Software-Updates oder eines Firmware-Updates aus der E-Mail; und Installieren des Software- oder Firmware-Updates auf einem Fahrzeugsystemmodul (VSM) im Fahrzeug.
DE102017109099.1A 2016-05-04 2017-04-27 Bereitstellen von modul-updates für ein fahrzeugsystem Pending DE102017109099A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/146,290 2016-05-04
US15/146,290 US10318269B2 (en) 2016-05-04 2016-05-04 Providing vehicle system module updates

Publications (1)

Publication Number Publication Date
DE102017109099A1 true DE102017109099A1 (de) 2017-11-09

Family

ID=60119536

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102017109099.1A Pending DE102017109099A1 (de) 2016-05-04 2017-04-27 Bereitstellen von modul-updates für ein fahrzeugsystem

Country Status (3)

Country Link
US (1) US10318269B2 (de)
CN (1) CN107346254B (de)
DE (1) DE102017109099A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3730340A1 (de) * 2019-04-25 2020-10-28 Gogoro Inc. Systeme und verfahren zur informationsverwaltung in fahrzeugen

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108292211A (zh) * 2015-12-10 2018-07-17 三菱电机株式会社 信息处理装置、信息处理方法和信息处理程序
US10656281B2 (en) * 2016-11-10 2020-05-19 Cable Television Laboratories, Inc. Systems and methods for interference detection in shared spectrum channels
US11686852B2 (en) * 2016-11-10 2023-06-27 Cable Television Laboratories, Inc. Systems and methods for interference detection in shared spectrum channels
US10922424B2 (en) * 2017-08-17 2021-02-16 M2MD Technologies, Inc. Method and system for securely providing vehicle services data to a vehicle
US10803681B2 (en) * 2017-11-15 2020-10-13 Honda Motor Co., Ltd. Server side security preventing spoofing of vin provisioning service
US10678530B2 (en) * 2018-01-09 2020-06-09 Ford Global Technologies, Llc Vehicle update systems and methods
US11245583B2 (en) * 2018-05-03 2022-02-08 Micron Technology, Inc. Determining whether a vehicle should be configured for a different region
US11204751B2 (en) * 2018-09-07 2021-12-21 International Business Machines Corporation Mitigating incompatibilities due to code updates in a system containing multiple networked electronic control units
CN110071835B (zh) * 2019-04-25 2022-03-18 成都信息工程大学 一种智能网联车安全预警分发方法及系统
JP7069084B2 (ja) * 2019-05-22 2022-05-17 本田技研工業株式会社 ソフトウェア更新装置およびソフトウェア更新方法
US11271971B1 (en) * 2021-03-19 2022-03-08 King Saud University Device for facilitating managing cyber security health of a connected and autonomous vehicle (CAV)
KR20230015200A (ko) * 2021-07-22 2023-01-31 현대자동차주식회사 차량 업데이트 제어 장치 및 그 방법
US11886860B2 (en) * 2021-09-27 2024-01-30 Red Hat, Inc. Distribution of digital content to vehicles

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7502672B1 (en) * 2000-04-24 2009-03-10 Usa Technologies, Inc. Wireless vehicle diagnostics with service and part determination capabilities
US7092803B2 (en) * 2000-08-18 2006-08-15 Idsc Holdings, Llc Remote monitoring, configuring, programming and diagnostic system and method for vehicles and vehicle components
US20020098853A1 (en) * 2001-01-22 2002-07-25 General Motors Corporation Method and system for providing vehicle-directed services
US20040249934A1 (en) * 2003-06-06 2004-12-09 Anderson Jeff M. Updating print server software based on update emails
US7366589B2 (en) * 2004-05-13 2008-04-29 General Motors Corporation Method and system for remote reflash
US7676804B2 (en) * 2004-05-20 2010-03-09 Caterpillar Inc. Systems and method for remotely modifying software on a work machine
DE112006003591B4 (de) * 2005-12-31 2019-06-27 General Motors Llc ( N. D. Ges. D. Staates Delaware ) Verfahren zum Bereitstellen einer Fahrzeuginformation durch eine Fahrzeug - Email - Benachrichtigung unter Verwendung von Vorlagen
FR2914080A1 (fr) * 2007-03-23 2008-09-26 Renault Sas Systeme et procede de gestion de donnees en provenance et a destination d'un vehicule automobile.
US8730033B2 (en) * 2010-02-17 2014-05-20 Hti Ip, L.L.C. Method and system for sending information from a user device to a car
US8775448B2 (en) * 2012-04-24 2014-07-08 Responsys, Inc. High-throughput message generation
JP2014013148A (ja) * 2012-07-03 2014-01-23 Panasonic Corp 端末装置、車載装置、ナビゲーションプログラム
US8813061B2 (en) * 2012-10-17 2014-08-19 Movimento Group Module updating device
WO2014164893A2 (en) * 2013-03-13 2014-10-09 Arynga Inc. Remote transfer of electronic images to a vehicle
US20140380296A1 (en) * 2013-06-20 2014-12-25 General Motors Llc Re-programming vehicle modules
US9940762B2 (en) * 2013-09-25 2018-04-10 Ford Global Technologies, Llc Systems and methods for identification of a compromised module
CN103634232B (zh) * 2013-11-06 2016-08-31 南京邮电大学 基于延迟容忍网络技术的车辆消息路由方法
US9766874B2 (en) * 2014-01-09 2017-09-19 Ford Global Technologies, Llc Autonomous global software update
US10140109B2 (en) * 2014-02-25 2018-11-27 Ford Global Technologies, Llc Silent in-vehicle software updates
CN105519232B (zh) * 2014-08-01 2019-03-01 华为技术有限公司 一种无线网络中传输数据的装置及方法
US10146521B2 (en) * 2014-09-09 2018-12-04 Airpro Diagnostics, Llc Device, system and method for updating the software modules of a vehicle

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3730340A1 (de) * 2019-04-25 2020-10-28 Gogoro Inc. Systeme und verfahren zur informationsverwaltung in fahrzeugen

Also Published As

Publication number Publication date
CN107346254B (zh) 2020-10-30
CN107346254A (zh) 2017-11-14
US10318269B2 (en) 2019-06-11
US20170322791A1 (en) 2017-11-09

Similar Documents

Publication Publication Date Title
DE102017109099A1 (de) Bereitstellen von modul-updates für ein fahrzeugsystem
DE102018130216A1 (de) Fahrzeugkommunikation unter Verwendung eines Publish-Subscribe-Messaging-Protokolls
DE102017111501A1 (de) Aktualisierung von fahrzeugsystemmodulen
DE102017116186A1 (de) Fahrzeugbereichsspezifische Softwareupdateverteilung
DE102016103725A1 (de) Aufrechterhalten einer Spiegelsitzung zwischen einem Fahrzeug und einer mobilen Einrichtung
DE102018129843A1 (de) Einrichten einer sicheren drahtlosen Nahbereichs-Kommunikationsverbindung an einem Fahrzeug
DE102017121510A1 (de) Priorisierung von Aktualisierungen zur Verbreitung über eine Luftschnittstelle
DE102016101327A1 (de) Reagieren auf elektronisches Eindringen im Fahrzeug
DE102015103974A1 (de) Fahrzeugtelematik-Datenaustausch
DE102018100153A1 (de) Verfahren und system zur fernbetätigten änderung von informationen für eine geräteaktivierungsübertragung
DE102012205358A1 (de) OTA-Einleitungsverfahren für ein Telematiksystem in einem 2G-GSM / 3G-WCDMA-Netz
DE102008030974A1 (de) Verfahren zum Bereitstellen von datenbezogenen Diensten für ein Fahrzeug mit Telematikausstattung
DE102011108672B4 (de) Verfahren zum Identifizieren von Telematikanrufen
DE102017120844A1 (de) Installieren von Fahrzeug-Updates
DE102019111576A1 (de) System und verfahren zur übertragung von in der warteschlange befindlichen over-the-air-software-updates
DE102013203357A1 (de) Verfahren zum herstellen einer kommunikation zwischen einrichtungen in einem fahrzeug
DE102008058442A1 (de) Verbindungsverwaltung für eine Fahrzeugtelematikeinheit
DE102019105287A1 (de) Verfahren und vorrichtung für fahrzeugkommunikation
DE102017109091A1 (de) Dynamische statusaktualisierungsaufforderung
DE102014118306A1 (de) Verarbeitung sicherer SMS-Nachrichten
DE102017117039A1 (de) Betrieb eines drahtlosen fahrzeugzugangspunkts zum selektiven verbinden mit drahtlosen fahrzeugvorrichtungen
DE102017206478A1 (de) Vereinfachen der installation von mobilgeräte-anwendungen unter verwendung eines fahrzeugs
DE102017200020A1 (de) Steuern der auswahl der wlan-subskription eines aicc mit multiplen mobilgeräteprofilen
DE102017122082A1 (de) Ultraschallbasierte audioübertragung von drahtlos-lan-informationen
DE102017122083A1 (de) Dynamische fahrzeuganforderungsstrategien

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R082 Change of representative

Representative=s name: MANITZ FINSTERWALD PATENT- UND RECHTSANWALTSPA, DE

Representative=s name: MANITZ FINSTERWALD PATENTANWAELTE PARTMBB, DE

R016 Response to examination communication