DE102011079875A1

DE102011079875A1 - Bereitstellung von daten an ein fahrzeug-infotainment-datenverarbeitungssystem

Info

Publication number: DE102011079875A1
Application number: DE102011079875A
Authority: DE
Inventors: Sukhwinder Wadhwa; Michael Raymond Westra; Edward Charles Esker; Saeid Soleimani; Henry Heping Huang; Sandeep Waraich; Timothy Allan Geiger
Original assignee: Ford Motor Co
Current assignee: Ford Motor Co
Priority date: 2010-07-27
Filing date: 2011-07-27
Publication date: 2012-02-02
Also published as: CN102346679A; CN102346679B; RU2572962C2; RU2011131233A; US20120030512A1

Abstract

Verschiedene Ausführungsformen umfassen ein Softwarebereitstellungssystem und -verfahren für einen Fahrzeug-Infotainment-Computer. Softwarebereitstellung für den Fahrzeug-Infotainment-Computer kann während der Fahrzeugmontage stattfinden. Es kann eine Softwarebereitstellungsanforderung zur angepassten Installation von Software in den Fahrzeug-Infotainment-Computer empfangen werden. Die angepasste Installation kann auf einem Anpassungsprogramm basieren, der eine Ortskennung (wie etwa Uniform Resource Identifiers oder Dateipfade) zum Finden der Software umfassen kann. Als Reaktion auf die Anforderung kann die Software auf einem Bereitstellungsserver oder einer tragbaren Speichereinrichtung auf der Basis des Anpassungsprogramms gefunden werden. Die Software kann zu dem Speicher des Fahrzeug-Infotainment-Computers gesendet und angepasst auf dem Fahrzeug-Infotainment-Computer installiert werden.

Description

Verschiedene Ausführungsformen betreffen Verfahren und Systeme zum Bereitstellen von Datenmengen für ein Fahrzeug-Infotainment-Datenverarbeitungssystem. Bei bestimmten Ausführungsformen können die Datenmengen Softwareanwendungen umfassen.
Das Laden von Software in ein Fahrzeug wird gewöhnlich über ein Fahrzeugnetzwerk (wie etwa einen CAN-Bus) durchgeführt. Beispiele für verschiedene Installationsverfahren sind im Stand der Technik bekannt.
Das US-Patent Nr. 6,978,198 offenbart ein System und ein Verfahren zum Laden von Fahrzeugbetriebssoftware und Kalibrationsdaten in einer allgemeinen Montage- und Serviceumgebung. Das System offenbart ein Datenaustauschsystem zur Verwendung bei der Fahrzeugmontage mit einem Datenaustauschmechanismus, der Fahrzeugsoftware- und/oder Diagnostikinformationen zwischen Fahrzeugprozessoren und einem externen Prozessor austauscht. Der Datenaustauschmechanimus ist eine tragbare Speichereinrichtung, wie etwa eine USB-Flash-Disk, die abwechselnd mit USB-Ports des externen Prozessors und dem Fahrzeug verbunden wird. Fahrzeugsoftware wird durch einen mit einer CAN-Steuerung verbundenen Schnittstellenprozessor automatisch auf Fahrzeugprozessoren geladen, und die Prozessoren schreiben ähnlich Diagnostikinformationen zurück. In einem anderen Aspekt ist der Datenaustauschmechanismus ein drahtloser Mechanismus, wie etwa ein iCHIP, der den externen Prozessor und Fahrzeugprozessoren durch ein Kommunikationsnetzwerk und eine CAN-Steuerung verbindet. Fahrzeugprozessoren fordern individuell drahtlos entsprechende Fahrzeugsoftware an und/oder stellen Diagnostikinformationen bereit. Der Datenaustauschmechanimus kann permanent in das Fahrzeug integriert sein oder vorübergehend durch einen alternativen Verbindungsmechanismus wie etwa ALDL mit dem Fahrzeug verbunden werden.
Die US-Publikation Nr. 2006/0130033 offenbart ein Verfahren zum Bereitstellen eines Softwaremoduls für eine Automobil-Fahrzeugsteuereinheit und ein Computerprogramm zum Ausführen des Verfahrens. Das Verfahren umfasst die folgenden Schritte a) Herstellen einer Verbindung zwischen einem programmierbaren Speicher der Fahrzeugsteuereinheit und einer Programmiereinrichtung, b) Erzeugen einer Anforderungsnachricht, wobei die Anforderungsnachricht eine Softwaremodulkennung zum Identifizieren des Softwaremoduls umfasst, c) Senden der Anforderungsnachricht über ein Kommunikationsmittel zu einem Server, d) Empfangen einer Zugriffsnachricht von dem Server, die die Programmiereinrichtung dafür freigibt, auf ein Softwaremodul zuzugreifen, und e) Laden des Softwaremoduls in den programmierbaren Speicher durch die Programmiereinrichtung.
Ein Aspekt umfasst ein Softwarebereitstellungssystem für einen Fahrzeug-Infotainment-Computer. Es kann ein Anpassungsprogramm zum Installieren von Software in den Fahrzeug-Infotainment-Computer gespeichert werden. Der Anpassungsprogramm kann eine Ortskennung (wie etwa einen URL oder einen Dateipfad) mit der Software assoziieren, um die Software zur angepassten Installation zu finden. Als Reaktion auf eine Anforderung, angepasst Software in den Fahrzeug-Infotainment-Computer zu installieren, kann die Software auf der Basis des Anpassungsprogramms gefunden werden und in den Speicher des Fahrzeug-Infotainment-Computers übertragen werden. Die Software kann angepasst in den Fahrzeug-Infotainment-Computer installiert werden.
Das System kann auch dafür konfiguriert werden, den Fahrzeug-Infotainment-Computer durch Empfangen einer Fahrzeugidentifikationsnummer (VIN) von einem Fahrzeugnetzwerk (wie etwa einem CAN-Bus) zu identifizieren.
Ein anderer Aspekt kann ein Softwarebereitstellungssystem für einen Fahrzeug-Infotainment-Computer umfassen, das einen Fahrzeug-Infotainment-Computer umfassen kann. Es kann eine verdrahtete oder drahtlose Verbindung mit Speicher (wie etwa einer tragbaren Speichereinrichtung oder einem Bereitstellungsserver) hergestellt werden, der einen Anpassungsprogramm speichert, der Software zur angepassten Installation auf dem Fahrzeug-Infotainment-Computer bereitstellt. Der Anpassungsprogramm kann einen Uniform Resource Identifier (URI) mit der Software assoziieren. Der Speicher kann auch Software für angepasste Installation auf dem Fahrzeug-Infotainment-Computer umfassen.
Der Fahrzeugcomputer kann ferner dafür ausgelegt sein, den Anpassungsprogramm zu empfangen, aus dem ein oder mehrere URI zum Empfangen der Software erhalten werden können. Die Software kann auf der Basis eines oder mehrerer zum Speicher übertragener URI aus Speicher empfangen werden. Bei einer Ausführungsform können die URI als eine oder mehrere Anforderungen des Hypertext Transfer Protocol (HTTP) übertragen werden. Die Software kann angepasst in den Fahrzeug-Infotainment-Computer installiert werden, nachdem mindestens ein Teil der Software empfangen wird.
Das System kann außerdem ein Softwarebereitstellungs-Verifikationssystem zur Fehlerverifikation bei der angepassten Installation umfassen. Die Fehler können Diagnostik-Problemkodes aus einem Fahrzeugnetzwerk sein.
Ein anderer Aspekt umfasst ein Verfahren, bei dem Eingaben zum Aktivieren der Softwarebereitstellung von einem Fahrzeug empfangen werden. Es wird eine Verbindung mit einem Bereitstellungsmedium hergestellt, das einen SoftwareAnpassungsprogramm und Software zur Installation auf dem Fahrzeugcomputer speichert. Software kann auf dem Fahrzeugcomputer auf der Basis des Anpassungsprogramms empfangen und angepasst auf dem Fahrzeugcomputer installiert werden.
Bei bestimmten Ausführungsformen kann die Bereitstellung für den Fahrzeugcomputer gleichzeitig mit einer Konfiguration eines oder mehrerer Fahrzeugsteuermodule durchgeführt werden. Zusätzlich kann der Bereitstellungsprozess während der Fahrzeugmontage auftreten.
Das Verfahren kann auch einen Unterbrechungs-Umgangsprozess zum Umgang mit der Bereitstellung von Unterbrechungen umfassen. Bei einer Ausführungsform kann eine Unterbrechung empfangen werden, die den Fahrzeugcomputer triggert, neu zu booten. Der Punkt der Unterbrechung während der angepassten Installation kann bestimmt werden. Nach dem Identifizieren des Softwarebereitstellungsmediums kann die angepasste Installation neu gestartet werden. Als Alternative kann die angepasste Installation an dem Punkt der Unterbrechung abgeschlossen werden.
Bei bestimmten Ausführungsformen kann bestimmt werden, ob sich das Softwarebereitstellungsmedium geändert hat. Wenn dem so ist, kann die angepasste Installation neu gestartet werden.
Diese und andere Aspekte werden im Hinblick auf die beigefügten Zeichnungen und die folgende ausführliche Beschreibung der Erfindung besser verständlich.
Die nachfolgend identifizierten Figuren veranschaulichen bestimmte Ausführungsformen der Erfindung. Die Figuren sind nicht als Beschränkung der Erfindung gedacht, die in den angefügten Ansprüchen angeführt ist. Die Ausführungsformen werden sowohl in Bezug auf ihre Organisation als auch auf ihre Betriebsweise zusammen mit weiteren Aufgaben und Vorteilen dieser am besten mit Bezug auf die folgende Beschreibung in Verbindung mit den beigefügten Zeichnungen verständlich. Es zeigen:
1 eine Blocktopologie eines Fahrzeug-Infotainment-Systems;
2 einen Softwarebereitstellungsprozess in Kontext des Fahrzeug-Infotainment-System-Produktionsprozesses;
3 ein Blockdiagramm eines Softwarebereitstellungssystems und des Betriebs des Softwarebereitstellungssystems für ein Fahrzeug-Infotainment-System;
4 einen Softwarebereitstellungsprozess gemäß einer Ausführungsform;
5 einen Softwarebereitstellungsprozess gemäß einer anderen Ausführungsform; und
6 einen Prozess zum Umgang mit Softwarebereitstellungsunterbrechungen gemäß einer Ausführungsform.
Es werden hier ausführliche Ausführungsformen der Erfindung offenbart. Es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für eine Erfindung sind, die in verschiedenen und alternativen Formen realisiert werden kann. Deshalb sind hier offenbarte spezifische Funktionsdetails nicht als beschränkend zu interpretieren, sondern lediglich als repräsentative Grundlage für die Ansprüche und/oder als repräsentative Grundlage, um es Fachleuten zu lehren, die vorliegende Erfindung verschiedenartig einzusetzen.
Fahrzeugbusnetzwerke (wie etwa CAN) können im Allgemeinen nicht mit großen Volumen von Daten umgehen. Zum Beispiel kann es bei 500 kbps (der Geschwindigkeit eines Hochgeschwindigkeits-CAN) mindestens 30 Minuten dauern, um eine Daten-Datei von 120 MB über einen HSCAN-Bus zu schieben. Dementsprechend können große Volumen von Daten (wie etwa Softwareanwendungen) nicht in ein Fahrzeug-Infotainment-System, wie etwa das von der FORD MOTOR COMPANY hergestellte SYNC-System, geladen werden, ohne Effizienz beim Installationsprozess aufzuopfern.
1 zeigt eine beispielhafte Blocktopologie für ein fahrzeuggestütztes Infotainment-Datenverarbeitunssystem 1 (VCS) für ein Fahrzeug 31. Es versteht sich, dass die Offenbarung und Anordnung von 1 so modifiziert oder umgeordnet werden kann, wie es am besten auf eine bestimmte Implementierung der verschiedenen Ausführungsformen der Erfindung passt. Ein mit einem fahrzeuggestützten Datenverarbeitungssystem befähigtes Fahrzeug kann eine visuelle Frontend-Schnittstelle 4 enthalten, die sich in dem Fahrzeug befindet. Der Benutzer kann auch in der Lage sein, mit der Schnittstelle in Dialog zu treten, wenn sie zum Beispiel mit einem berührungsempfindlichen Bildschirm ausgestattet ist. Bei einer anderen beispielhaften Ausführungsform erfolgt der Dialog durch Tastenbetätigung, hörbare Sprache und Sprachsynthese.
Bei der in 1 gezeigten beispielhaften Ausführungsform 1 steuert ein Prozessor 3 mindestens einen Teil des Betriebs des fahrzeuggestützten Datenverarbeitungssystems. Der Prozessor ist in dem Fahrzeug vorgesehen und erlaubt Onboard-Verarbeitung von Befehlen und Routinen. Ferner ist der Prozessor sowohl mit nichtpersistentem 5 als auch persistentem Speicher 7 verbunden. Bei dieser beispielhaften Ausführungsform ist der nichtpersistente Speicher Direktzugriffsspeicher (RAM) und der persistente Speicher ist ein Festplattenlaufwerk (HDD) oder Flashspeicher.
Der Prozessor ist außerdem mit einer Anzahl von verschiedenen Eingängen ausgestattet, die es dem Benutzer erlauben, eine Schnittstelle mit dem Prozessor zu bilden. Bei dieser beispielhaften Ausführungsform sind ein Mikrofon 29, ein Hilfseingang 25 (für den Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24 und ein BLUETOOTH-Eingang 15 vorgesehen. Außerdem ist ein Eingangsselektor 51 vorgesehen, um es einem Benutzer zu erlauben, zwischen verschiedenen Eingängen zu wechseln. Eingaben sowohl in den Mikrofon- als auch in den Hilfsverbinder werden durch einen Umsetzer 27 von analog in digital umgesetzt, bevor sie zu dem Prozessor geleitet werden.
Ausgänge des Systems können, aber ohne Beschränkung darauf, ein visuelles Display 4 und einen Lautsprecher 13 oder einen Stereoanlagenausgang umfassen. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal durch einen Digital-Analog-Umsetzer 9 von dem Prozessor 3. Ausgaben können auch an eine entfernte BLUETOOTH-Einrichtung, wie etwa die PND 54, oder eine USB-Einrichtung, wie etwa die Fahrzeugnavigationseinrichtung 60, entlang der bei 19 bzw. 21 gezeigten bidirektionalen Datenströme erfolgen.
Bei einer beispielhaften Ausführungsform verwendet das System 1 den BLUETOOTH-Sender/-Empfänger 15 zum Kommunizieren 17 mit der tragbaren Einrichtung 53 (z. B. Mobiltelefon, Smart Phone, PDA usw.) eines Benutzers. Die tragbare Einrichtung kann dann verwendet werden, um zum Beispiel durch Kommunikation 55 mit einem Zellularmast 57 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59. Bei bestimmten Ausführungsformen kann der Mast 57 ein WiFi-Zugangspunkt sein.
Die beispielhafte Kommunikation zwischen der tragbaren Einrichtung und dem BLUETOOTH-Sender/-Empfänger ist durch das Signal 14 dargestellt.
Durch eine Taste 52 oder ähnliche Eingabe kann Paarung einer tragbaren Einrichtung 53 und des BLUETOOTH-Senders/-Empfängers 15 angewiesen werden. Dementsprechend wird die CPU angewiesen, dass der Onboard-BLUETOOTH-Sender/-Empfänger mit einem BLUETOOTH-Sender/-Empfänger in der tragbaren Einrichtung gepaart wird.
Zwischen der CPU 3 und dem Netzwerk 61 können zum Beispiel mit einem Datenplan, Data Over Voice oder DTMF-Tönen, die mit der tragbaren Einrichtung 53 assoziiert sind, Daten übermittelt werden. Als Alternative kann es wünschenswert sein, ein Onboard-Modem 63 vorzusehen, das eine Antenne 18 aufweist, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu übermitteln 16. Die tragbare Einrichtung 53 kann dann verwendet werden, um zum Beispiel durch Kommunikation 55 mit einem Zellularmast 57 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59. Bei bestimmten Ausführungsformen kann das Modem 63 zur Kommunikation mit dem Netzwerk 61 Kommunikation 20 mit dem Mast 57 herstellen. Als nichteinschränkendes Beispiel kann das Modem 63 ein USB-Zellularmodem sein, und die Kommunikation 20 kann zellulare Kommunikation sein.
Bei einer beispielhaften Ausführungsform ist der Prozessor mit einem Betriebssystem ausgestattet, das eine API zur Kommunikation mit Modem-Anwendungssoftware umfasst. Die Modem-Anwendungssoftware kann auf ein eingebettetes Modul oder Firmware in dem BLUETOOTH-Sender/-Empfänger zugreifen, um drahtlose Kommunikation mit einem entfernten BLUETOOTH-Sender/-Empfänger (wie etwa dem in einer tragbaren Einrichtung angetroffenen) abzuschließen.
Bei einer anderen Ausführungsform umfasst die tragbare Einrichtung 53 ein Modem zur Sprachband- oder Breitband-Datenkommunikation. Bei der Data-Over-Voice-Ausführungsform kann eine als Frequenzmultiplexen bekannte Technik implementiert werden, wenn der Eigentümer der tragbaren Einrichtung über die Einrichtung sprechen kann, während Daten transferiert werden. Zu anderen Zeiten kann der Datentransfer, wenn der Eigentümer die Einrichtung nicht verwendet, die gesamte Bandbreite (300 Hz bis 3,4 kHz in einem Beispiel) verwenden.
Wenn der Benutzer einen mit der tragbaren Einrichtung assoziierten Datenplan besitzt, ist es möglich, dass der Datenplan Breitbandübertragung erlaubt und das System eine wesentlich größere Bandbreite verwenden könnte (wodurch der Datentransfer beschleunigt wird). Bei einer weiteren Ausführungsform wird die tragbare Einrichtung 53 mit einem zellularen Kommunikationsgerät (nicht gezeigt) ersetzt, das in dem Fahrzeug 31 installiert wird. Bei einer weiteren Ausführungsform kann die ND 53 eine drahtlose LAN-Einrichtung (LAN = lokales Netzwerk) sein, die zum Beispiel (und ohne Beschränkung) über ein 802.11g-Netzwerk (d. h. WiFi) oder ein WiMax-Netzwerk kommunizieren kann.
Bei einer Ausführungsform können ankommende Daten über einen Data-Over-Voice- oder Datenplan durch die tragbare Einrichtung, durch den Onboard-BLUETOOTH-Sender/-Empfänger und in den internen Prozessor 3 des Fahrzeugs geleitet werden. Im Fall bestimmter temporärer Daten können die Daten zum Beispiel auf der HDD oder einem anderen Speichermedium 7 gespeichert werden, bis die Daten nicht mehr benötigt werden.
Zusätzliche Quellen, die an das Fahrzeug angeschaltet werden können, wären ein persönliches Navigationsgerät 54, das zum Beispiel eine USB-Verbindung 56 und/oder eine Antenne 58 aufweist; oder ein Fahrzeugnavigationsgerät 60 mit einem USB 62 oder einer anderen Verbindung, ein Onboard-GPS-Gerät 24 oder Fernnavigationssystem (nicht gezeigt) mit Konnektivität zu dem Netzwerk 61.
Ferner könnte sich die CPU in Kommunikation mit vielfältigen anderen Hilfseinrichtungen 65 befinden. Diese Einrichtungen können durch eine drahtlose 67 oder verdrahtete 69 Verbindung verbunden werden. Außerdem oder als Alternative könnte die CPU zum Beispiel unter Verwendung eines WiFi-Senders/-Empfängers 71 mit einem fahrzeuggestützten drahtlosen Router 73 verbunden werden. Dadurch könnte sich die CPU mit entfernten Netzwerken in der Reichweite des lokalen Routers 73 verbinden.
2 zeigt einen Softwarebereitstellungsprozess für das VCS 1 während der VCS-Produktion. Es versteht sich, dass Softwarebereitstellung für das VCS 1 in der Fabrik, beim Händler und/oder nach dem Verkauf des Fahrzeugs stattfinden kann. Ferner kann Softwarebereitstellung auf der Fertigungslinie, von einem Händler und/oder von dem Fahrzeugeigentümer durchgeführt werden. Dementsprechend kann 2 so modifiziert oder umgeordnet werden, wie es am besten auf eine bestimmte Implementierung der verschiedenen Ausführungsformen der Erfindung passt.
Der Softwarebereitstellungsprozess für das VCS 1 kann in Bezug auf Effizienz optimiert werden, so dass Volumen von Daten, groß oder klein, installiert werden können. Bei einem nichteinschränkenden Beispiel kann das Bereitstellungssystem bzw. der Bereitstellungsprozess dafür ausgelegt werden, innerhalb von etwa 5 Minuten 180 MB–270 MB Daten zu schieben, das umgesetzt einem Bereich von zwischen 1–1,2 MB pro Sekunde entspricht. Es versteht sich, dass dieses Beispiel lediglich zur Veranschaulichung angegeben wird und deshalb nicht einschränkend ist. Dementsprechend können Dateigrößen und Datentransferraten auf der Basis der spezifischen Implementierung des Systems und von mit dem Datentransfer assoziierten Umgebungsfaktoren unterschiedlich sein.
Das Bereitstellungssystem bzw. der Bereitstellungsprozess kann auch skalierbar sein. Dementsprechend kann ein Bereitstellungssystem für mehrere VCS verwendet werden, die auf der Montagelinie konfiguriert werden können.
Nunmehr mit Bezug auf 2 wird der VCS-Montage- und -Bereitstellungsprozess dargestellt und beschrieben. Natürlich können andere Fahrzeug- und VCS-Montageprozesse implementiert werden. 2 kann die „Montagelinien”-Produktion des VCS 1 repräsentieren. In diesem Beispiel kann das VCS 1 in der Fabrik 100 montiert (Block 102) und programmiert (z. B. „Image-Flashing”) werden (Block 104). Wenn das Ende der Linie 106 erreicht ist, kann das Display-Modul 4 an das VCS 1 angeschlossen werden (Block 108), und dann kann Montagebandendeprüfung und Funktionsprüfung durchgeführt werden (Block 112).
Während des Prozesses der Instrumententafel-Teilmontage 114 kann die Baugruppe des VCS 1 an der Instrumententafel des Fahrzeugs montiert werden (Block 116). Während des Prozesses der Fahrzeugoperationen 118 kann die montierte Instrumententafel dann in dem Fahrzeug montiert werden (Block 120). Während dieser Phase kann das VCS 1 Markenpersonalität erhalten. Zum Beispiel kann ein Splash Screen programmiert werden, für ein Ford-Fahrzeug Ford-Namen und -Logo anzuzeigen. Ferner kann das VCS 1 mit markenspezifischen Grafiken, Sprachenpaketen, Marktdaten und anderen Softwareanwendungen (wie etwa Navigation) ausgestattet werden (Block 122).
Das Fahrzeug kann von der Fabrik an den Händler 124 ausgeliefert werden. Der Kunde kann das Fahrzeug von dem Händler kaufen und erhalten (Block 126). Ferner kann Softwarebereitstellung anderer Anwendungen, wie etwa einer Kartendatenbank und andere Software des VCS 1, stattfinden (Block 128).
3 ist ein Blockdiagramm der Systemarchitektur und des Betriebs eines Softwarebereitstellungssystems für das VCS 1. Es versteht sich, dass die Offenbarung und Anordnung von 3 so modifiziert oder umgeordnet werden kann, wie es am besten auf eine bestimmte Implementierung der verschiedenen Ausführungsformen der Erfindung passt.
Über ein Fahrzeugnetzwerk, wie etwa ein CAN-Netzwerk 201, können ein oder mehrere Fahrzeugmodule 202 konfiguriert werden. In diesem Kontext beziehen sich Fahrzeugmodule auf Fahrzeugsteuermodule, darunter, aber ohne Beschränkung, das Kraftübertragungs-Steuermodul (PCM), die Motorsteuereinheit (ECU), das Airbag-Steuermodul (ACM) und andere ähnliche Fahrzeugsteuermodule. Die Konfiguration der Fahrzeugmodule kann durch ein Fahrzeugmodul-Konfigurationssystem 200 in der Fahrzeugproduktionslinie durchgeführt werden. Der Konfigurationsprozess der Fahrzeugmodule kann vor der Softwarebereitstellung für das VCS 1 auftreten. Es versteht sich jedoch, dass der Konfigurationsprozess oder mindestens ein Teil davon später stattfinden kann, ohne von dem Schutzumfang der verschiedenen Ausführungsformen abzuweichen. Bei einer Ausführungsform können Fahrzeugmodulkonfiguration und die Softwarebereitstellung gleichzeitig durchgeführt werden.
Das VCS 1 kann eine Fahrzeugidentifikationsnummer (VIN) für seine Softwarebereitstellung benutzen. Die VIN kann durch das VCS 1 über ein CAN-Netzwerk 201 empfangen werden, um das Fahrzeug und das VCS, für das bereitgestellt wird, zu identifizieren.
Mit der VIN und einer Konstantstromversorgung des VCS 1 kann der Softwarebereitstellungsprozess mit Hilfe eines Softwarebereitstellungsservers 204 erzielt werden. Der Server 204 kann die Informationen zur Bereitstellung für das VCS 1, die im Speicher des Servers 204 und/oder einer Bereitstellungsdatenbank (nicht gezeigt) gespeichert sein können, bereitstellen. Die Informationen können, aber ohne Beschränkung darauf, Softwareanwendungen zur Installation in das VCS 1 und Anweisungen umfassen, die den Softwaresatz zur Installation auf dem VCS definieren. Der Satz kann eine oder mehrere Softwareanwendungen oder Datensätze umfassen. Bei einer Ausführungsform kann es sich bei diesen Anweisungen um eine Software-Materialaufstellung (BOM) handeln (diese Anweisungen werden im Allgemeinen hier als „BOM” bezeichnet). Bei einer Ausführungsform kann die BOM auf dem Server als Textdatei gespeichert und durch eine VIN identifiziert werden. Diese Textdatei kann auch als die „Bereitstellungsquelle” für das VCS 1 bezeichnet werden. Als ein Beispiel kann die BOM in einer Datei auf dem Server mit der Bezeichnung <VIN>.lst vorliegen, wobei sich „VIN” auf die VIN des Fahrzeugs bezieht. In bestimmten Fällen ist eine VIN möglicherweise während der Bereitstellung nicht über das Fahrzeugnetzwerk verfügbar. In diesem Fall kann eine Vorgabe-VIN oder eine andere Vorgabe-Identifikationsnummer verwendet werden.
Es kann individuell für ein VCS 1 in jedem Fahrzeug bereitgestellt werden. Dementsprechend kann das VCS 1 während des Bereitstellungsprozesses angepasste Pakete oder Anpassungspläne empfangen. Der Anpassungsprogramm kann in der Bereitstellungsquelle enthalten sein. Bei einer Ausführungsform kann der Anpassungsprogramm die Software-Materialaufstellung sein. Die Anpassungspläne können auf einem Build-Plan für das Fahrzeug basieren. Der Build-Plan kann, aber ohne Beschränkung darauf, Folgendes umfassen: Land/Region des Ziels (d. h. Sprachenpakete), Marke des Fahrzeugs, Trimmniveau (z. B. und ohne Beschränkung Größe von Innen-Displays), Anwesenheit bestimmter Merkmale (z. B. und ohne Beschränkung Notfallansprechverhalten, Fahrzeugintegritätsmeldungen usw.) und Anwendungslizenzierung. Der Anpassungsprogramm kann ferner auf Präferenzen und/oder Anforderungen eines Kunden, OEM, Händlers und dergleichen basieren.
Das VCS 1 kann durch einen oder mehrere drahtlose Zugangspunkte 206 mit dem Server 204 kommunizieren. Wenn mehrere Zugangspunkte 206 vorliegen, kann das VCS 1 willkürlich einen Zugangspunkt 206 wählen, mit dem es kommuniziert. Bei bestimmten Ausführungsformen kann die Entscheidung auf Leistungsfähigkeitsgesichtspunkten der Zugangspunkte 206 (wie etwa Lastausgleich) basieren. Die drahtlose Kommunikation zwischen dem VCS 1 und dem Server 204 kann, aber ohne Beschränkung darauf, WiFi (oder andere drahtlose Kommunikation auf der Basis des 802.11-Standards), BLUETOOTH und andere ähnliche drahtlose Technologien umfassen.
Natürlich können VCSI und VCS-Bereitstellungsserver 204 auch über fest verdrahtete Datenverbindung verbunden sein, wie etwa Ethernet, RS-232, USB oder dergleichen. Die Durchführung des Bereitstellungsprozesses kann auch durch die Geschwindigkeit der Montagelinie, Geschwindigkeit des Herunterladens von Software, Position der Zugangspunkte und Leistungspegel beeinflusst werden. Dementsprechend kann das VCS 1 auch Roaming zwischen Zugangspunkten während des Herunterladens von Software unterstützen.
Bei einer Ausführungsform kann der Zugangspunkt bzw. können die Zugangspunkte der Softwarebereitstellung gewidmet sein. Zum Beispiel und ohne Beschränkung können die Zugangspunkte mit dem Namen „SYNCPROV0” oder „SYNCPROV1” identifiziert werden, die sich auf „Sync-Bereitstellung” beziehen. Es versteht sich, dass der Zugangspunktname von der Groß-/Kleinschreibung abhängig sein kann oder auch nicht. Ferner kann der Service Set Identifier (SSID) des Zugangspunkts klein oder groß oder gemischt klein und groß geschrieben sein. Als Beispiel für die Abhängigkeit des Zugangspunkts von Groß-/Kleinschreibung kann ein SSID mit Großbuchstaben VCS-Bereitstellung gestatten, während ein gemischt- oder kleingeschriebener SSID es nicht gestatten kann.
Der Zugangspunkt bzw. die Zugangspunkte 206 können eine Zeitgrenze umfassen. Wenn eine Verbindung nicht innerhalb der Zeitgrenze hergestellt wurde, kann dementsprechend eine Verbindung neu versucht werden. Wenn mehrere Zugangspunkte 206 vorliegen, kann eine Verbindung mit einem neuen Zugangspunkt 206 versucht werden. Bei bestimmten Ausführungsformen kann die Zeitgrenze 20 Sekunden betragen.
Das VCS 1 kann unter Verwendung von Anforderungen 207a und Antworten 207b des HTTP Daten mit dem Server 204 austauschen. Es können andere Protokolle benutzt werden, aber zur Veranschaulichung wird hier HTTP verwendet. Die anderen Protokolle können, aber ohne Beschränkung darauf, die Folgenden umfassen: TFTP, FTP, POP, RSYNC, SCP und SSH. Ferner kann SSL in Kombination mit beliebigen dieser Protokolle zur sicheren Übertragung verwendet werden.
Diese HTTP-Anforderungen 207a können (einzeln oder in Kombination) einen URI (Uniform Resource Identifier) der Bereitstellungsquelle, die VIN oder eine elektronische Seriennummer (ESN) des VCS 1 umfassen. Der URI kann verwendet werden, um Anweisungen zu empfangen, die den Softwaresatz zur Installation (der eine Materialaufstellung sein kann) auf dem VCS 1 definieren. Die VIN kann verwendet werden, um das Fahrzeug zu identifizieren. Die ESN kann verwendet werden, um das VCS 1 zu identifizieren.
Die durch die HTTP-Anforderung 207a von dem Server 204 angeforderten Daten können, aber ohne Beschränkung darauf, die Anweisungen umfassen, die den Softwaresatz zur Installation (identifiziert durch VIN) und Anwendung(en) definieren. Dementsprechend kann die Softwarebereitstellung für das VCS 1 über Anwendungsinstallation durchgeführt werden. Anwendungen können, aber ohne Beschränkung darauf, Folgendes umfassen: Markenzeichen-Anwendungen (die die Marke des Fahrzeugs definieren), Region-/Sprachenanwendungen (wodurch das VCS 1 an die bestimmte geografische Region angepasst wird), Display-Anwendungen, Grafikanwendungen, Datenmanageranwendungen, Anwendungslizenz(en) und Lizenzierungsschlüssel und Service-Pakete.
Bei bestimmten Ausführungsformen können bestimmte Anwendungen (z. B. und ohne Beschränkung Anwendungslizenzen) über transiente Anwendungen installiert werden. Diese transienten Anwendungen können einmal laufen und dann von dem VCS 1 gelöscht werden.
Die Antworten 207b von dem Server 204 können die Bereitstellungsquelle (d. h. die Datei <VIN>.lst) und die von dem Server 204 angeforderte(n) Anwendung(en) umfassen. Die Softwareanwendung(en) können mit einer Teil-Kennung assoziiert sein, die einen Teil der Adresse des URI zum Abrufen der Software umfassen kann. Die Teil-Kennung kann durch einen OEM vordefiniert werden.
Verifikationssysteme 208 können verwendet werden, um zu verifizieren, dass in das Fahrzeug 31 installierte Software erfolgreich installiert wurde. Verifikation kann das Untersuchen der Ergebnisse der Bereitstellung für das VCS 1 auf Fehler und/oder Verifizieren der Installation von Software umfassen. Bei bestimmten Ausführungsformen kann die Verifikationsprüfung auch das Verifizieren 213a, b der Ergebnisse der Konfiguration der Fahrzeugsteuermodule 202 umfassen. Die Verifikationssysteme 208 können Endgeräte (z. B. tragbare und nichttragbare Einrichtungen), Datenbanken und/oder Software zum Durchführen der Verifikationsprüfung umfassen. Ferner kann das Verifikationssystem 208 auf dem VCS 1 installiert sein oder auch nicht. Bei einer Ausführungsform kann die Verifikationsprüfung am Ende der Produktionslinie erfolgen.
Während des Softwarebereitstellungsprozesses kann das VCS 1 Fehler, die während des Bereitstellungsprozesses aufgetreten sind, sammeln und verzeichnen. Bei einer Ausführungsform können diese Fehler Diagnostik-Problemkodes (DTC) sein. Zu einem vorbestimmten Zeitpunkt und/oder in bestimmten Zeitintervallen können die Fehler zur Diagnose zu dem Verifikationssystem 208 übertragen 209a werden. Eine Diagnose kann das Empfangen des Fehlers bzw. der Fehler und das Bestimmen des mit dem Fehler assoziierten Softwarebereitstellungsfehlers umfassen.
Die Fehler können von dem VCS 1 als Kette von Zeichen empfangen werden. Wenn das Verifikationssystem 208 den bzw. die Fehler empfängt, kann es den Fehler auf der Basis eines Nachschlagens in einer Tabelle definieren, die die Softwarebereitstellungsfehler aufweist. Die Fehler können in benutzerverständlicher Form vorliegen. Als ein Beispiel kann das VCS 1 „DTC XXXXX” zu dem Verifikationssystem 208 senden 209a, wobei die Xe Zahlen und/oder Buchstaben repräsentieren. Das Verifikationssystem 208 kann diesen Fehler auf der Basis eines Nachschlagens in der Fehlertabelle definieren und die Definition dieses Fehlers bestimmen.
Das Verifikationssystem 208 kann den definierten Fehler zum dem VCS 1 senden 209b, das die Definition an den Benutzer ausgeben kann. Eine Ausgabe kann hörbar und/oder visuell sein. Zum Beispiel kann die Diagnose als Sprache, eine Reihe von Pieptönen oder Tönen, Text auf dem Display 4 und/oder grafische Bilder auf dem Display 4 ausgegeben werden.
Nichteinschränkende Beispiele für Fehler umfassen, aber ohne Beschränkung darauf, die Folgenden: fehlende/nicht verfügbare BOM, fehlende/nicht verfügbare Anwendung(en), noch nicht für VCS bereitgestellt, Installieren von Softwareanwendung(en), die bereits auf dem VCS 1 existiert, Anwendung(en) können nicht installiert werden und/oder unzureichender Speicher zum Installieren der Anwendung(en). Auf der Basis des Fehlers bzw. der Fehler kann neu für das VCS 1 bereitgestellt werden, um den bzw. die Fehler aus dem VCS 1 zu löschen.
Das Verifikationssystem 208 kann zusätzlich oder als Alternative die Installation der Anwendung(en) verifizieren. Eine installierte Anwendung kann einen oder mehrere Installationskennungen umfassen, die verwendet werden können, um die installierte Anwendung bzw. die installierten Anwendungen zu verifizieren. Bei einer Ausführungsform können die Installationskennungen mit einer Gruppe von installierten Anwendungen assoziiert sein (z. B. kann eine Kennung mit einer Gruppe von einer oder mehreren installierten Anwendungen assoziiert sein). Ein Empfang der Installationskennung wird folglich dem Verifikationssystem 208 die Gruppe von Anwendungen anzeigen, die installiert wurde. Bei einer Ausführungsform können die Installationskennungen über das Fahrzeugnetzwerk zu dem Verifikationssystem 208 gesendet werden.
Der Verifikationsprozess kann in bestimmten Zeitintervallen während des Bereitstellungsprozesses oder zu einem einzelnen vorbestimmten Zeitpunkt (z. B. und ohne Beschränkung nachdem die Bereitstellung abgeschlossen ist) auftreten. Während der Verifikation kann das Verifikationssystem 208 die Installationskennung(en) von dem VCS 1 und die in dem Verifikationssystem 208 aufgezeichneten Informationen empfangen 211a. Bei einer Ausführungsform können diese Informationen verfolgt werden, um den Zustand des VCS 1 zu bestimmen. Es kann eine Bestätigung der installierten Anwendungen zu dem VCS 1 zurückgesendet werden 211b oder nicht.
Der Bereitstellungsprozess kann zusätzlich oder als Alternative mit einer tragbaren Speichereinrichtung 210 durchgeführt werden. Eine tragbare Speichereinrichtung 210 kann, aber ohne Beschränkung darauf, einen USB-Stick, eine SD-Karte (Secured Digital), eine CF-Karte (Compact Flash) und ein externes Festplattenlaufwerk umfassen. Ferner kann die tragbare Speichereinrichtung verdrahtet oder drahtlos sein. Das VCS 1 kann einen Port zur Aufnahme von Speicherkarten wie SD- und CF-Karten umfassen.
Wenn die tragbare Speichereinrichtung durch das VCS 1 aufgenommen wird, kann die Bereitstellungsquelle durch das VCS 1 von der tragbaren Speichereinrichtung 210 angefordert 215a und empfangen 215b werden. Die Bereitstellungsquelle kann als Textdatei in dem Wurzelverzeichnis der tragbaren Speichereinrichtung 210 gespeichert werden. Zum Beispiel und ohne Beschränkung kann die Bereitstellungsquelle <VIN>.lst genannt werden.
Die in der BOM für Softwareanwendungszugriff definierten URI können Dateipfade auf der tragbaren Speichereinrichtung 210 definieren. Wie bei der oben beschriebenen drahtlosen Bereitstellung können die Softwareanwendungen gemäß der BOM empfangen und auf dem VCS 1 installiert werden. Etwaige Bereitstellungsfehler, die gesammelt und verzeichnet werden, können definiert und/oder mit dem Verifikationssystem 208 verifiziert werden.
Bei einer Ausführungsform können die drahtlosen Bereitstellungssysteme oder die tragbare Speichereinrichtung 210 zur Softwarebereitstellung verwendet werden, wenn irgendein Teil der Bereitstellung fehlgeschlagen ist. In diesem Fall können Reparatursysteme 216 beim Reparieren des fehlgeschlagenen Teils bzw. der fehlgeschlagenen Teile benutzt werden. Das Reparatursystem 216 kann zusätzlich oder als Alternative verwendet werden, wenn ein VCS 1 mit einem VCS, für das noch nicht bereitgestellt wurde, ersetzt wird.
Das Reparatursystem 216 kann Systeme zur Bereitstellung für das VCS 1 umfassen. Bei einer Ausführungsform kann Software unter Verwendung des Reparatursystems 216 manuell durch einen Benutzer installiert werden. Wenn der Bereitstellungsprozess fehlgeschlagen ist, kann auf der Basis des Empfangs eines Fehlers während des verdrahteten oder drahtlosen Bereitstellungsprozesses eine Reparatur eingeleitet werden.
4 zeigt einen Softwarebereitstellungsprozess gemäß einer der verschiedenen Ausführungsformen. Es versteht sich, dass die Offenbarung und Anordnung von 4 so modifiziert oder umgeordnet werden kann, wie es am besten auf eine bestimmte Implementierung der verschiedenen Ausführungsformen der Erfindung passt.
Der Bereitstellungsprozess kann mit einer Aktivierungseingabe (Block 300) aktiviert werden, die einen Softwarebereitstellungsmodus des VCS 1 aktiviert. Die Aktivierungseingabe kann automatisch und/oder manuell sein. Eine automatische Aktivierungseingabe kann ein Signal von dem Fahrzeugnetzwerk sein. In diesem Fall kann das VCS 1 eine Bereitstellungsroutine umfassen (die eine in das VCS 1 programmierte Diagnostikroutine sein kann oder auch nicht), die, wenn sie ausgeführt wird, automatisch Softwarebereitstellung aktiviert. Eine manuelle Aktivierungseingabe kann eine hörbare (z. B. ein Sprachbefehl) und/oder eine taktile (z. B. Berührungsschirmeingabe) Eingabe in dem Fahrzeug sein. Zusätzlich kann der Prozess als Reaktion auf das Einfügen einer tragbaren Speichereinrichtung aktiviert werden.
Das VCS 1 kann auf der Basis einer in den nichtflüchtigen Speicher des VCS 1 gespeicherten Bereitstellungskennung identifizieren, wann erfolgreich für es bereitgestellt wurde oder nicht. Zum Beispiel kann eine „0” anzeigen, dass noch nicht für das VCS 1 bereitgestellt wurde, und eine „1” kann anzeigen, dass für das VCS 1 bereitgestellt wurde. Bei einer Ausführungsform kann ein Sicherheitsmerkmal eingerichtet sein, das verhindert, dass die Bereitstellungskennung geändert wird, nachdem für das VCS 1 bereitgestellt wurde. Dieses Sicherheitsmerkmal kann eine Umprogrammierung (oder ein Neu-Flash) des VCS 1 überleben (Block 104, 2). Es versteht sich, dass die Kennung numerisch, alphabetisch oder alphanumerisch sein kann.
Die Bereitstellungsquelle (z. B. eine Datei <VIN>.lst) kann durch das VCS 1 empfangen werden (Block 302). Der Softwareinstallationsplan aus der in der Bereitstellungsquelle enthaltenen BOM kann extrahiert und gelesen werden, um zu bestimmen, welche Software auf das VCS 1 zu installieren ist (Block 304).
Die Bereitstellung kann während der Fahrzeugproduktion stattfinden. Ein VCS 1, für das am Ende der Produktionslinie nicht einmal teilweise bereitgestellt wurde, führt deshalb dazu, dass dieser Fehler detektiert wird. Wenn teilweise oder noch gar nicht für das VCS 1 bereitgestellt wurde, kann dementsprechend bestimmt werden, ob das Ende der Produktionslinie erreicht wurde (Block 306). Wenn nicht, kann die Software gemäß dem Build-Plan in der BOM empfangen/heruntergeladen werden (Block 308).
Wenn die Software empfangen wurde, kann bestimmt werden, ob ein Softwarefehlschlag besteht (Block 310). Ein Softwarefehlschlag kann auf einen während der Softwarebereitstellung empfangenen Fehler zurückzuführen sein. Nichteinschränkende Beispiele für Fehler werden oben beschrieben. Wenn das Ende der Linie erreicht wurde, kann auch bestimmt werden, ob ein Softwarefehlschlag existiert (Block 310).
Wenn ein Fehlschlag gefunden wird, kann eine Warnung von dem VCS 1 gesendet werden (Block 312). Die Warnung kann hörbar und/oder visuell (d. h. textlich und/oder grafisch) sein. Der Softwarefehlschlag kann dann aus der Fehlerwarnung bestimmt werden (Block 314). Als Reaktion auf die Fehlerwarnung kann Software empfangen werden, um den Fehler zu reparieren (Block 316).
Die Software, die durch das VCS 1 empfangen wird, kann installiert werden (Block 318). Software-Herunterladen und Software-Installation können gleichzeitig sein oder auch nicht. Ferner können mehrere Installationen verschiedener Software gleichzeitig stattfinden oder auch nicht.
Bei einer Ausführungsform können, wenn der Softwareinstallationsprozess (auf der Basis eines Fehlers oder nicht) abgeschlossen ist (Block 318), Daten auf dem VCS 1, die bei dem Bereitstellungsprozess benutzt werden, aus dem Speicher gelöscht werden. Dazu können Verbindungsdaten zu der drahtlosen oder verdrahteten Einrichtung (z. B. Server 204 oder USB-Stick) gehören (Block 320). Zum Beispiel und ohne Beschränkung können im Fall drahtloser Bereitstellung Daten in Bezug auf etwaige drahtlose (z. B. WiFi-)Verbindungen und drahtlose Schlüssel gelöscht werden. Damit kann man eine spätere Neubereitstellung für das VCS 1 verhindern.
Nachdem der Bereitstellungsprozess mit Installation (Block 318) abgeschlossen wird, kann der Softwarebereitstellungsmodus des VCS 1 verlassen und beendet werden (Block 322). Nachdem die Softwarebereitstellung abgeschlossen ist, kann auf diesen Modus wieder zugegriffen werden oder auch nicht.
Die Softwarebereitstellung kann zusätzlich oder als Alternative mit einer verdrahteten Einrichtung, wie etwa einer tragbaren Speichereinrichtung, durchgeführt werden. Bei bestimmten Ausführungsformen kann eine verdrahtete Einrichtung zur manuellen Softwarebereitstellung verwendet werden. 5 ist ein Bereitstellungsprozess bei Verwendung einer verdrahteten Einrichtung. Es versteht sich, dass die Offenbarung und Anordnung von 5 so modifiziert oder umgeordnet werden kann, wie es am besten auf eine bestimmte Implementierung der verschiedenen Ausführungsformen der Erfindung passt.
Die tragbare Speichereinrichtung kann als Eingabe an einem Port des VCS 1 empfangen werden (Block 400). Als nichteinschränkendes Beispiel kann ein USB-Speicherstick in den USB-Port des VCS 1 eingeführt werden. Nach der Aufnahme kann eine Verbindung zwischen der tragbaren Speichereinrichtung und dem VCS 1 hergestellt werden (Block 402).
Die VIN kann von dem Fahrzeugnetzwerk empfangen werden (Block 404), womit man nach der Bereitstellungsquelle auf der tragbaren Speichereinrichtung suchen kann. Wie oben beschrieben, kann die Bereitstellungsquelle als Textdatei in dem Wurzelverzeichnis auf der tragbaren Speichereinrichtung abgespeichert werden.
Wenn die Bereitstellungsquelle gefunden wird (Block 406), wird die Bereitstellungsquelle durch das VCS 1 empfangen (Block 408) und die Installation der Software kann wie oben beschrieben erreicht werden. Wenn die Bereitstellungsquelle nicht anwesend ist, kann eine Warnung auf dem VCS 1 gesendet werden, die diesen Fehler anzeigt (Block 410). Der Fehlerwarnprozess ist wie oben mit Bezug auf 4 beschrieben.
Während des Bereitstellungsprozesses kann dem Benutzer der Status der Bereitstellung präsentiert werden. Der Status kann hörbar (z. B. auf Sprache basierend) und/oder visuell (z. B. grafisch und/oder textlich) sein. Der Status kann automatisch (z. B. in vorbestimmten Zeitintervallen) und/oder als Reaktion auf eine manuelle Eingabe (z. B. als Ergebnis eines Sprachbefehls oder einer taktilen Eingabe in dem Fahrzeug) präsentiert werden. Der Status kann, aber ohne Beschränkung darauf, Folgendes umfassen: den Fortschritt jedes installierten Softwarepakets, einen Gesamtstatus (z. B. Bereitstellung ist abgeschlossen oder nicht abgeschlossen), vergangene Bereitstellungszeit, verbleibende Zeit für Abschluss, Stärke des drahtlosen Signals, IP-Adresse, SSID des Zugangspunkts und angetroffene(n) Fehler.
6 zeigt einen Neuboot-Abwicklungsprozess des Softwarebereitstellungsprozesses. Die (oben beschriebene) Bereitstellungsroutine kann als Teil des Neuboot-Prozesses verwendet werden. Dementsprechend kann die Bereitstellungsroutine auf dem VCS 1 empfangen und abgespeichert werden (Block 500). Bei einer Ausführungsform kann diese Routine empfangen werden, wenn die Bereitstellung beginnt.
Ein Neubooten kann aufgrund der Installation eines Service-Pakets stattfinden. Zusätzlich oder als Alternative kann ein Neubooten aufgrund einer Unterbrechung in dem Bereitstellungsprozess auftreten (eine Unterbrechung kann zum Beispiel auf einen Stromversorgungsverlust zurückzuführen sein). Diese können als „Neuboot-Ereignis” bezeichnet werden. Während des Bereitstellungsprozesses kann ein Neuboot-Ereignis durch das VCS 1 empfangen werden (Block 502).
Wenn das Neuboot-Ereignis empfangen wird, kann das VCS 1 neu gebootet und der Bereitstellungsprozess neu gestartet werden (Block 504). Das Neubooten kann sofort oder nach einer vorbestimmten Zeit stattfinden. Eine vorbestimmte Zeit kann eine bestimmte Zeitspanne und/oder die Installation bestimmter oder aller Softwareanwendungen sein. Wenn das Neubooten auf eine Unterbrechung zurückzuführen ist, kann das VCS 1 während der vorbestimmten Zeit versuchen, eine Verbindung wieder herzustellen. Bei einer Ausführungsform kann das Neubooten nur eine vorbestimmte Anzahl von Malen stattfinden, woraufhin ein Fehler gemeldet und der Bereitstellungsprozess abgebrochen werden kann.
Der Bereitstellungsprozess kann von Anfang an neu gestartet werden. Als Alternative kann der Bereitstellungsprozess von dem Punkt an neu gestartet werden, an dem die Unterbrechung aufgetreten ist. Dies kann so geschehen, damit die Teile des Prozesses, die abgeschlossen sind, nicht wiederholt werden, und/oder die Installation abgeschlossen werden kann (z. B. wenn ein Service-Paket installiert wird).
Das Bereitstellungssystem kann in der Lage sein, während der Bereitstellung mit einer Änderung des Bereitstellungsmediums umzugehen (z. B. drahtlose Bereitstellung zu verdrahteter Bereitstellung oder Verwendung zweier verschiedener tragbarer Speichereinrichtungen). Wenn zum Beispiel eine Unterbrechung auftritt, kann der Benutzer die Bereitstellung nach der Unterbrechung von einem anderen Bereitstellungsmedium als dem, mit dem die Bereitstellung gestartet wurde, aus fortsetzen. Das VCS 1 kann dann bestimmen, ob dasselbe Medium verwendet wird, wenn das Neubooten stattfindet oder wenn der Bereitstellungsprozess neu gestartet wird (Block 506). Die Bestimmung kann auf der Basis des Bereitstellungsmediums erfolgen, woraus die Bereitstellungsquelle ursprünglich empfangen wurde.
Wenn ein neues Medium verwendet wird, kann die BOM aus dem vorherigen Bereitstellungsmedium gelöscht werden (Block 508), und die BOM aus dem neuen Bereitstellungsmedium kann empfangen werden (Block 510). Der Bereitstellungsprozess kann mit der BOM aus dem neuen Bereitstellungsmedium fortfahren (Block 514).
Wenn dasselbe Medium verwendet wird, kann der Punkt des Neubootens bestimmt werden (Block 512), so dass die Bereitstellung von dem Punkt an neu starten kann, wenn die Bereitstellung nicht abgeschlossen ist. Wenn weitere Bereitstellung verbleibt, kann die Bereitstellung dann von dem Punkt des Neubootens an fortgesetzt werden (Block 514).
Es versteht sich, dass die verschiedenen Ausführungsformen der Verfahren und Systeme im Kontext der Bereitstellung von Softwareanwendungen für das VCS 1 beschrieben werden. Das Bereitstellungssystem und -verfahren können jedoch in anderen Kontexten, wie etwa Programmierung oder Umprogrammierung (d. h. Flashing oder Neu-Flashing) des VCS 1 verwendet werden. In allen Fällen können die verschiedenen Ausführungsformen das Erzeugen verschiedener Permutationen des VCS 1 ermöglichen, ohne physisch verschiedene Kombinationen von Modulen und Software zu erzeugen. Dementsprechend kann für mehrere Module des VCS 1 unterschiedlich bereitgestellt werden, während die Anzahl der bei dem Bereitstellungsprozess benutzten Werkzeuge verringert wird. Dies kann nützlich sein, wenn, als ein Beispiel, einem OEM drei verschiedene Fahrzeugmarken (X, Y und Z) gehören und jede Marke für 20 verschiedene Regionen bestimmt sein kann.
Ferner können bestimmte dieser Marken Navigationssysteme umfassen. Deshalb müssen nicht verschiedene Kombinationen von Modulen erzeugt werden, um diesen Anforderungen für jedes Fahrzeug jeder Marke zu genügen.
Obwohl oben beispielhafte Ausführungsformen dargestellt und beschrieben wurden, ist nicht beabsichtigt, dass diese Ausführungsformen alle Möglichkeiten darstellen und beschreiben. Stattdessen sind die in der Beschreibung verwendeten Wörter nicht Wörter der Beschränkung, sondern der Beschreibung, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne von dem Gedanken und Schutzumfang der Erfindung abzuweichen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 6978198 [0003]
US 2006/0130033 [0004]

Claims

Softwarebereitstellungssystem für einen Fahrzeug-Infotainment-Computer, wobei das System Folgendes umfasst: einen Fahrzeug-Infotainment-Computer, der für Folgendes ausgelegt ist: Herstellen einer Verbindung mit einem Speicher, auf dem ein Anpassungsprogramm und Software zur angepassten Installation auf dem Fahrzeug-Infotainment-Computer gespeichert ist, wobei das Anpassungsprogramm die Software zur angepassten Installation auf dem Fahrzeug-Infotainment-Computer umfasst und das Anpassungsprogramm einen Uniform Resource Identifier (URI) mit jeder Software verbindet; Empfangen des Anpassungsprogramms aus dem Speicher; Erhalten eines oder mehrerer URI zum Empfangen der Software aus dem Anpassungsprogramm; Senden des einen oder der mehreren URI zum Speicher; Empfangen der Software aus dem Speicher auf der Basis des einen oder der mehreren URI; und angepasstes Installieren der Software im Fahrzeug-Infotainment-Computer, nachdem mindestens ein Teil der Software empfangen ist.
System nach Anspruch 1, wobei der Speicher eine tragbare Speichereinrichtung ist.
System nach Anspruch 1, wobei der Speicher ein Softwarebereitstellungsserver ist.
System nach einem der vorherigen Ansprüche, wobei das System ferner ein Softwarebereitstellungs-Verifikationssystem umfasst, das für Folgendes ausgelegt ist: Empfangen von Diagnostik-Problemkodes, die einen Fehler bei der angepassten Installation definieren; und Darstellen des Fehlers an dem Fahrzeug-Infotainment-Computer.
System nach Anspruch 4, wobei der Fahrzeug-Infotainment-Computer ferner für Folgendes ausgelegt ist: Empfangen der Diagnostik-Problemkodes von einem Fahrzeugnetzwerk; und Senden der Diagnostik-Problemkodes zu dem Softwarebereitstellungs-Verifikationssystem.
System nach einem der vorherigen Ansprüche, wobei der Anpassungsprogramm auf mindestens einer der folgenden Alternativen basiert: einer geografischen Region, Benutzerpräferenzen, Lizenzierung, OEM-Präferenzen oder Fahrzeugtyp.
System nach einem der vorherigen Ansprüche, wobei die Verbindung eine drahtlose oder eine verdrahtete Verbindung ist.
System nach einem der vorherigen Ansprüche, wobei der Fahrzeug-Infotainment-Computer ferner dafür ausgelegt ist, den einen oder die mehreren URI als eine oder mehrere Anforderungen des Hypertext Transfer Protocol (HTTP) zu senden.
Softwarebereitstellungssystem nach einem der vorherigen Ansprüche, wobei der URI ein Uniform Resource Locator (URL) ist.