DE102017120844A1

DE102017120844A1 - Installieren von Fahrzeug-Updates

Info

Publication number: DE102017120844A1
Application number: DE102017120844.5A
Authority: DE
Inventors: Shawn F. Granda; Jeffrey J. Olsen; Ganesh Srinivasan
Original assignee: GM Global Technology Operations LLC; General Motors LLC
Current assignee: GM Global Technology Operations LLC; General Motors LLC
Priority date: 2016-09-14
Filing date: 2017-09-08
Publication date: 2018-03-15
Also published as: CN107835205A; US20180074813A1

Abstract

Es werden ein Kommunikationssystem und ein Verfahren zum Verwenden des Kommunikationssystem zum Installieren eines Fahrzeug-Updates in einem Fahrzeugsystemmodul (VSM) an Bord eines Fahrzeugs bereitgestellt, wobei ermöglicht wird, dass das Fahrzeug während der Installation des Fahrzeug-Updates in einem mobilisierten Zustand verbleibt. Das Verfahren beinhaltet die folgenden Schritte: Empfangen eines Fahrzeug-Updates für ein Ziel-VSM in dem Fahrzeug, während sich das Fahrzeug in dem mobilisierten Zustand befindet; Durchführen eines Übergabe-Betriebsverfahrens zwischen einem Proxy-Gerät und dem Ziel-VSM, sodass dem Proxy-Gerät die Genehmigung erteilt wird, die Fahrzeugbetriebsanweisungen auszuführen, als ob das Proxy-Gerät das Ziel-VSM ist; danach Installieren des Fahrzeug-Updates auf dem Ziel-VSM; und Fortsetzen des Betriebs des Fahrzeugs in dem mobilisierten Zustand unter Verwendung des Proxy-Geräts anstelle des Ziel-VSMs während des Installationsschritts.

Description

TECHNISCHES GEBIET
Die vorliegende Erfindung betrifft das Installieren von Fahrzeug-Updates und insbesondere das Installieren von Fahrzeug-Updates, wenn sich das Fahrzeug in einem mobilisierten Zustand befindet.
HINTERGRUND
Ein Fahrzeugbenutzer kann sein/ihr Fahrzeug zu einem Fahrzeughersteller oder zu einer Service-Stelle bringen, um Software- und/oder Firmware-Updates auf einer oder mehreren elektronischen Steuereinheiten oder anderen elektronischen Geräten in dem Fahrzeug zu installieren. Während solcher Installationen befindet sich das Fahrzeug im Stillstand oder in einem immobilisierten Zustand. So kann beispielsweise es notwendig sein, dass die Zündung ,aus' ist und sich das Fahrzeuggetriebe in der PARKSTELLUNG usw. befindet. Im immobilisierten Zustand ist der normale oder typische Fahrzeugbetrieb vorübergehend ausgesetzt – um beispielsweise den Fahrzeugbetrieb in einem undefinierten oder unbeabsichtigten Zustand zu verhindern. Daher immobilisiert der Hersteller oder Servicetechniker während der Software-/Firmware-Updates das Fahrzeug, sodass es nicht gefahren, nicht aus der PARKSTELLUNG gebracht oder ähnliches gemacht werden kann. So kann der Benutzer das Fahrzeug während dieser Updates nicht bedienen oder fahren.
Daher wäre es zur Verbesserung der Nutzerfreundlichkeit wünschenswert, eine Möglichkeit zur Aktualisierung von durch die Fahrzeugelektronik ausgeführten Anweisungen bereitzustellen, während sich das Fahrzeug in einem mobilisierten Betriebszustand befindet.
ZUSAMMENFASSUNG
Gemäß einer Ausführungsform der Erfindung wird ein Verfahren zum Verwenden des Kommunikationssystems zum Installieren eines Fahrzeug-Updates in einem Fahrzeugsystemmodul (Vehicle System Module – VSM) an Bord eins Fahrzeugs bereitgestellt, während ermöglicht wird, dass das Fahrzeug während der Installation des Fahrzeug-Updates in einem mobilisierten Zustand verbleibt. Das Verfahren beinhaltet die folgenden Schritte: Empfangen eines Fahrzeug-Updates für ein Ziel-VSM in dem Fahrzeug, während sich das Fahrzeug in dem mobilisierten Zustand befindet; Durchführen eines Übergabe-Betriebsverfahrens zwischen einem Proxy-Gerät und dem Ziel-VSM, sodass dem Proxy-Gerät die Genehmigung erteilt wird, Fahrzeugbetriebsanweisungen auszuführen, als ob das Proxy-Gerät das Ziel-VSM ist; danach Installieren des Fahrzeug-Updates auf dem Ziel-VSM; und Fortsetzen des Betriebs des Fahrzeugs in dem mobilisierten Zustand unter Verwendung des Proxy-Geräts anstelle des Ziel-VSMs während des Installationsschritts.
Gemäß einer weiteren Ausführungsform der Erfindung wird ein Computerprogrammprodukt bereitgestellt, das ein nicht-flüchtiges computerlesbares Medium für eine mobile Vorrichtung umfasst, die Computerprogrammanweisungen beinhaltet, die der mobilen Vorrichtung das zeitweise Ausführen eines aktualisierten Satzes von Betriebsanweisungen für ein Fahrzeugsystemmodul (VSM) in einem Fahrzeug ermöglichen, während der aktualisierte Satz von Betriebsanweisungen darin installiert wird, wodurch ermöglicht wird, dass das Fahrzeug während der Installation in einem mobilisierten Zustand verbleibt. Das Computerprogrammprodukt beinhaltet: Anweisungen zum Empfangen des aktualisierten Satzes von Betriebsanweisungen auf der mobilen Vorrichtung von einem Remote-Server; Anweisungen zum Kommunizieren mit dem Fahrzeug über ein Gateway-Modul darin in Reaktion auf den Empfangsschritt; und Anweisungen zum Durchführen eines Übergabe-Betriebsverfahrens in Reaktion auf das Empfangen einer Bereitschaftsnachricht von dem Gateway-Modul, wobei die mobile Vorrichtung während des Übergabe-Betriebsverfahrens den aktualisierten Satz von Betriebsanweisungen für das Fahrzeug über das Gateway-Modul ausführt, sodass das Fahrzeug den Betrieb fortsetzen kann, während das Gateway-Modul den aktualisierten Satz von Betriebsanweisungen in dem VSM installiert.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Eine oder mehrere Ausführungsformen der Erfindung werden im Folgenden in Verbindung mit den beigefügten Zeichnungen beschrieben, worin gleiche Bezeichnungen gleiche Elemente bezeichnen, und worin:
1 eine schematische Darstellung einer Ausführungsform eines Kommunikationssystems ist, das fähig ist, das hierin offenbarte Verfahren zu verwenden; und
2 ein Flussdiagramm eines Verfahrens zum Installieren eines Fahrzeug-Updates in einem Fahrzeugsystemmodul an Bord eines Fahrzeugs ist.
AUSFÜHRLICHE BESCHREIBUNG DER VERANSCHAULICHTEN AUSFÜHRUNGSFORM(EN)
Nachfolgend wird ein Kommunikationssystem beschrieben, das fähig ist, Fahrzeug-Updates (oder Fahrzeugsystem-Updates) in verschiedenen Fahrzeugsystemmodulen (VSMs) im Fahrzeug zu installieren, während sich das Fahrzeug in einem mobilisierten Zustand befindet – d. h. in einem Zustand, in dem das Fahrzeug normal gefahren und betrieben werden kann. Üblicherweise ist das Fahrzeug während dieses Prozesses vorübergehend immobilisiert (deaktiviert) oder zumindest teilweise deaktiviert. Zum Beispiel erfordert die Immobilisierung normalerweise, dass das Fahrzeuggetriebe während der Installation eines Fahrzeug-Updates in die PARKSTELLUNG gebracht wird – und so das Fahrzeug nicht (z. B. im VORWÄRTSGANG, RÜCKWÄRTSGANG usw.) gefahren werden kann. Somit kann der immobilisierte Zustand das elektronische und/oder mechanische Sperren oder Einschränken des Betriebs einiger Fahrzeugsubsysteme beinhalten – z. B. kann das Motorsteuergerät (ECM), eine Kraftstoffpumpe oder ein Kraftstoffsystem oder dergleichen zumindest teilweise außer Betrieb sein. Im vorliegenden System muss das Fahrzeug nicht geparkt werden, sondern kann während der Installation des Fahrzeug-Updates normal gefahren sowie im Rückwärtsgang und dergleichen betrieben werden. Des Weiteren werden während der Installation des Updates kein Kraftstoff geregelt und keine elektrischen oder mechanischen Fahrzeugfunktionen betätigt, um den Betrieb aufgrund der laufenden Installation des Fahrzeug-Updates einzuschränken oder zu unterbrechen. Um dies zu erreichen, kommuniziert eines der VSM, ein Gateway- oder Gateway-Kommunikationsmodul, mit einem Proxy-Gerät, um den normalen Betrieb des jeweiligen VSMs, das aktualisiert wird, auszuführen. Ein Beispiel eines Proxy-Geräts ist ein Smartphone mit einer speziellen, darauf installierten Fahrzeuganwendungssoftware. Somit kann beispielsweise das Gateway-Modul ein Übergabe-Betriebsverfahren koordinieren, wobei das Smartphone die Funktionen und Operationen eines Ziel-VSMs (z. B. eines VSMs, das ein Software- oder Firmware-Update empfängt) übernimmt. Während sich das Smartphone vorübergehend als das Ziel-VSM verhält, wird das Fahrzeug-Update auf dem Ziel-VSM installiert. Während dieser Zeitspanne kann das Fahrzeug normal betrieben werden. So kann beispielsweise das Smartphone, auch wenn das Ziel-VSM das Motorsteuergerät ist, die Anweisungen eines Motorsteuergeräts ausführen, sodass es nicht erforderlich ist, das Fahrzeug zu immobilisieren. Sobald das Ziel-VSM aktualisiert ist, kann ein umgekehrtes Übergabe-Betriebsverfahren erfolgen, wobei das Ziel-VSM die Steuerung der Funktionen und Operationen wieder übernimmt (und das Smartphone zu diesem Zeitpunkt natürlich mit der Ausführung solcher aufhört).
Mit Bezug auf 1 ist eine Betriebsumgebung dargestellt, die ein mobiles Fahrzeugkommunikationssystem 10 umfasst, das verwendet werden kann, um das hierin offenbarte Verfahren zu implementieren. Das Kommunikationssystem 10 beinhaltet im Allgemeinen: ein oder mehrere Mobilfunksysteme 12; ein Festnetz 14; ein Backend-System 16, das mindestens eines von einem Remote-Server 18 oder einem Call-Center 20 umfasst; eine mobile Vorrichtung 22 und ein Fahrzeug 24. Es versteht sich, dass das offenbarte Verfahren mit einer beliebigen Anzahl von unterschiedlichen Systemen verwendet werden kann und nicht speziell auf die hierin gezeigte Betriebsumgebung einschränkt ist. Auch die Architektur, Konstruktion, Konfiguration und der Betrieb des Systems 10 und seiner einzelnen Komponenten sind in der Technik allgemein bekannt. Somit stellen die folgenden Absätze lediglich einen kurzen Überblick über ein solches Kommunikationssystem 10 bereit; aber auch andere, hierin nicht dargestellte Systeme könnten die offenbarten Verfahren einsetzen.
Das Mobilfunksystem 12 ist bevorzugt ein Mobiltelefonsystem, das in einigen Implementierungen eine Vielzahl von Mobilfunktürmen (nur einer gezeigt), eine oder mehrere mobile Vermittlungszentralen (MSC) (nicht gezeigt) sowie beliebige andere Netzwerkkomponenten beinhaltet, die erforderlich sind, um das Mobilfunksystem 12 mit dem Festnetz 14 zu verbinden. Jeder Mobilfunkturm beinhaltet Sende- und Empfangsantennen und eine Basisstation, wobei die Basisstationen verschiedener Mobilfunktürme mit den MSC verbunden sind, entweder direkt oder über Zwischenvorrichtungen, wie beispielsweise eine Basisstationssteuerung. Das Mobilfunksystem 12 kann jede geeignete Kommunikationstechnologie implementieren, einschließlich beispielsweise analoger Technologien, wie AMPS, oder der neueren digitalen Technologien, wie beispielsweise GSM/GPRS, CDMA (beispielsweise CDMA2000) oder LTE. Wie einem Fachmann auf dem Gebiet bekannt, sind verschiedene Mobilfunkturm-/Basisstations-/MSC-Anordnungen möglich und könnten mit dem Mobilfunksystem 12 verwendet werden. Zum Beispiel könnten sich die Basisstation und Mobilfunktürme an derselben Stelle oder entfernt voneinander befinden, jede Basisstation könnte für einen einzelnen Mobilfunkturm zuständig sein oder eine einzelne Basisstation könnte verschiedene Mobilfunktürme bedienen und verschiedene Basisstationen könnten mit einer einzigen MSC gekoppelt werden, um nur einige der möglichen Anordnungen zu nennen.
Das Festnetz 14 kann ein konventionelles Festnetz-Telekommunikationsnetzwerk sein, das mit einem oder mehreren Festnetztelefonen verbunden ist und das Mobilfunksystem 12 mit dem Backend-System 16 verbindet. So kann zum Beispiel das Festnetz 14 ein öffentliches Telefonnetz (PSTN) beinhalten, wie es verwendet wird, um Festnetztelefonie, paketvermittelte Datenkommunikation und die Internetinfrastruktur bereitzustellen. Ein oder mehrere Segmente des Festnetzes 14 könnten durch die Verwendung eines Standardverdrahteten Netzwerks, eines Glasfasernetzwerks oder eines anderen LWL-Netzwerks, eines Kabelnetzwerks, von Stromleitungen, anderer drahtloser Netzwerke, wie beispielsweise drahtloser lokaler Netze (WLAN) oder von Netzwerken, die Broadband Wireless Access (BWA) oder eine beliebige Kombination davon bereitstellen, implementiert werden. Des Weiteren muss das Datenservice-Center 20 nicht über das Festnetz 14 verbunden sein, sondern könnte Funktelefonieausrüstung beinhalten, sodass es direkt mit einem drahtlosen Netzwerk, wie dem drahtlosen Trägersystem 12, kommunizieren kann.
Der Remote-Server 18 des Systems 16 kann Fahrzeugen eine Reihe von verschiedenen System-Backend-Funktionen bereitstellen und kann einer von mehreren Computern sein, die über ein privates oder öffentliches Netzwerk, wie dem Internet, zugänglich sind. Jeder dieser Server 18 kann für einen oder mehrere Zwecke verwendet werden, wie beispielsweise als Web-Server, der über das Festnetz 14 und/oder den drahtlosen Träger 12 erreichbar ist. Andere derartige zugängliche Server 18 können beispielsweise sein: ein Computer im Kundendienstzentrum, wobei Diagnoseinformationen und andere Fahrzeugdaten vom Fahrzeug 24 hochgeladen werden können; ein Clientcomputer, der von dem Fahrzeugbesitzer oder einem anderen Teilnehmer für solche Zwecke, wie das Zugreifen auf oder Empfangen von Fahrzeugdaten oder zum Einstellen oder Konfigurieren von Teilnehmerpräferenzen oder Steuern von Fahrzeugfunktionen, verwendet wird; oder ein Drittparteispeicherstandort, zu dem oder von dem Fahrzeugdaten oder andere Informationen bereitgestellt werden, entweder durch Kommunizieren mit dem Fahrzeug 24 oder dem Datenservice-Center 20 oder beiden. Ein Remote-Server 18 kann auch für das Bereitstellen von Internetkonnektivität, wie DNS-Diensten, oder als ein Netzwerkadressenserver verwendet werden, der DHCP oder ein anderes geeignetes Protokoll verwendet, um dem Fahrzeug 24 eine IP-Adresse zuzuweisen. In einer Ausführungsform ist der Remote-Server 18 Teil eines oder mit dem Datenservice-Center 20 verbunden; dies ist jedoch nicht erforderlich.
Das Datenservice-Center 20 von System 16 ist auch konzipiert, um Fahrzeugen eine Anzahl von unterschiedlichen System-Backend-Funktionen bereitzustellen, und beinhaltet im Allgemeinen einen oder mehrere Switches, Server, Datenbanken, Live-Berater sowie ein automatisiertes Sprachausgabesystem (VRS), die Fachleuten auf dem Gebiet bekannt sind. Diese verschiedenen Komponenten des Datenservice-Centers sind bevorzugt miteinander über ein verdrahtetes oder drahtloses lokales Netzwerk gekoppelt. Der Switch, der ein Nebenstellenanlagen(PBX)-Switch sein kann, leitet eingehende Signale weiter, sodass Sprachübertragungen gewöhnlich entweder zum Live-Berater über das reguläre Telefon oder automatisiert zum Sprachausgabesystem unter Verwendung von VoIP gesendet werden. Das Telefon des Live-Beraters kann zudem VoIP verwenden; VoIP und andere Datenkommunikationen über den Switch werden über ein Modem implementiert, das zwischen dem Switch und dem Netzwerk implementiert ist. Datenübertragungen werden über das Modem zum Server und/oder der Datenbank weitergegeben. Die Datenbank kann Kontoinformationen, wie beispielsweise Teilnehmerauthentisierungsinformationen, Fahrzeugbezeichner, Profilaufzeichnungen, Verhaltensmuster und andere entsprechende Teilnehmerinformationen, speichern. Datenübertragungen können zudem durch drahtlose Systeme, wie z. B. 802.11x, GPRS und dergleichen, erfolgen. Obwohl eine Ausführungsform beschrieben wurde, als ob sie in Verbindung mit einem bemannten Datenservice-Center 20 verwendet würde, das den Live-Berater einsetzt, ist es offensichtlich, dass das Datenservice-Center stattdessen VRS als einen automatisierten Berater verwenden kann oder eine Kombination von VRS und dem Live-Berater verwendet werden kann.
In mindestens einer Ausführungsform können der Server 18, das Datenservice-Center 20 oder beide Fahrzeug-Updates oder Fahrzeugsystemmodul(VSM)-Updates speichern und/oder an eine Anzahl von Fahrzeugen, wie Fahrzeug 24, über das Festnetz 14, über das Mobilfunknetz 12, über andere geeignete Kommunikationsinfrastrukturen (z. B. wie ein drahtloses lokales Netzwerk oder WLAN) oder über jede Kombination davon übertragen. Diese Fahrzeug-Updates können vorhandene Fahrzeughardware-Modulanweisungen (z. B. ein Hardware-Modul-Betriebssystem (OS), Software-Anweisungen, Firmware-Anweisungen oder dergleichen) ersetzen, modifizieren oder überschreiben. So kann beispielsweise das Backend-System 16 ein entsprechendes Fahrzeug-Update durch Speichern einer Fahrzeugkennung für alle Fahrzeuge, die es bedient (z. B. eine Fahrgestellnummer (Vehicle Identification Number – VIN) oder der VIN@Onstar.com), sowie Identifikatoren für verschiedene Hardware- und Softwarekomponenten in jedem Fahrzeug, bestimmen. Somit kann das Backend-System 16 beispielsweise mehrere Hardware-Modul-Kennungen (z. B. Modell und Seriennummern) und Software-Versions-Kennungen (z. B. der zuletzt installierten oder zuletzt aktualisierten Software-Version, die mit jedem der Hardware-Module assoziiert ist) für das Fahrzeug 24 speichern. Wie nachfolgend näher erläutert, kann die Installation der Fahrzeug-Updates ausgeführt werden, während sich das Fahrzeug in einem Betriebs- oder mobilisierten Zustand befindet – d. h. wie hierin verwendet, umfasst ein mobilisierter Zustand einen Zustand, in dem das Fahrzeug 24 in den VORWÄRTSGANG oder RÜCKWÄRTSGANG versetzt und normal gefahren werden kann. Folglich erfordert der mobilisierte Zustand nicht, dass sich das Fahrzeug 24 tatsächlich in dem VORWÄRTSGANGMODUS befindet bzw. fährt (z. B. sich bewegt); es ist lediglich erforderlich, dass das Fahrzeug 24 vorwärts, rückwärts usw. gefahren werden kann. Somit ist das Fahrzeug 24 durch das Unterbrechen/Einschränken bzw. das teilweise Unterbrechen/Einschränken der Funktionalität oder Betriebsfähigkeit nicht immobilisiert, wie es bei herkömmlichen Lösungen für Fahrzeug-Updates (wie vorstehend beschrieben) der Fall wäre.
Im Folgenden wird auf die mobile Vorrichtung 22 (1) Bezug genommen und, wie nachfolgend näher beschrieben, kann die mobile Vorrichtung 22 als eine Proxy- oder ErsatzComputer-Hardware zur Durchführung zumindest einiger Fahrzeugfunktionen während der Installation eines Fahrzeug-Updates in einem der Fahrzeug-Hardware-Module dienen. Die mobile Vorrichtung 22 kann jede geeignete tragbare elektronische Vorrichtung sein. Die Vorrichtung 22 kann zu mobilen Sprach- und/oder Datenanrufen über ein großes geografisches Gebiet fähig sein, in dem Übertragungen durch das Mobilfunksystem 12 erleichtert werden. Die mobile Vorrichtung 22 kann beispielsweise so konfiguriert sein, dass Mobilfunkdienste gemäß einer Teilnahmevereinbarung mit einer Drittanbietereinrichtung, wie einem Wireless-Service-Provider (WSP), bereitgestellt werden. In einigen Ausführungsformen kann die mobile Vorrichtung 22 mit dem Fahrzeug 24 verdrahtet sein oder sie kann drahtlos mit dem Fahrzeug 24 über ein Nahbereichs-Drahtloskommunikationssystem(SRWC)-Protokoll (z. B. Wi-Fi Direct, Bluetooth, Bluetooth Low Energy (BLE), Nahbereichskommunikation (NFC) usw. oder dergleichen) oder mittels beidem verbunden sein.
Die mobile Vorrichtung 22 kann eine Benutzeroberfläche (z. B. für die Eingabe/Ausgabe-(I/O)) umfassen, die mit einem Prozessor 30 gekoppelt ist, der konfiguriert ist, um ein Betriebssystem (OS) auszuführen, das in einem Gerätespeicher 32 (z. B. auf einem nichtflüchtigen computerlesbaren Medium der Vorrichtung) gespeichert ist. Der Prozessor 30 kann ferner auch ein oder mehrere in dem Gerätespeicher 32 gespeicherte Computerprogrammprodukte ausführen – das/die Computerprogrammprodukt/e kann/können beispielsweise jeder geeignete Programmcode, jede geeignete Sammlung von Anweisungen usw. sein und kann/können als ausführbare Anwendungssoftware 34 enthalten sein, die eine Benutzerinteraktion (I/O) erfordert oder nicht. Unter Verwendung dieser Anwendung/en 34 kann ein Fahrzeugbenutzer mit dem Fahrzeug 24, dem Backend-System 16 oder beiden kommunizieren (z. B. über Mobilfunkkommunikation, SRWC, das Festnetz 14 oder eine Kombination davon). In einer Ausführungsform kann mindestens eine Software-Anwendung 34 den Benutzer zum Betrieb des Fahrzeugs 24 in einem mobilisierten Zustand befähigen, während das Fahrzeug 24 ein Fahrzeug-Update installiert, das von dem Backend-System 16 an einem Fahrzeug-Hardware-Modul empfangen wurde. Zum Beispiel kann sich, wie unten näher beschrieben, die mobile Vorrichtung 22 während der Installation des Fahrzeug-Updates in dem Hardware-Modul unter Verwendung der Anwendung 34 als Proxy verhalten, indem sie Funktionen und Operationen des besagten Hardware-Modules ausführt – beispielsweise so, dass das Fahrzeug 24, wenn gewünscht, gefahren oder anderweitig betrieben werden kann. So können beispielsweise von dem Fahrzeug 24 und der mobilen Vorrichtung 22 ausgeführte Operationen einem Benutzer als normal erscheinen – und deshalb kann es sein, dass der Benutzer in einer Ausführungsform nichts von dem laufenden Fahrzeug-Update-Vorgang bemerkt. Somit kann die Anwendung 34 gemäß einer Ausführungsform zumindest einige der hierin beschriebenen Verfahrensschritte ausführen – und kann diese Schritte automatisch ausführen.
Nicht einschränkende Beispiele für die mobile Vorrichtung 22 beinhalten ein Smartphone, ein Mobiltelefon, einen persönlichen digitalen Assistenten (PDA), einen Laptop-Computer oder Tablet-Computer mit Zwei-Wege-Kommunikationsfähigkeiten, einen Netbook-Computer, ein Notebook oder geeignete Kombinationen davon. Die Vorrichtung 22 kann innerhalb oder außerhalb des Fahrzeugs 24 durch einen Fahrzeugbenutzer verwendet werden, der ein Fahrzeugführer oder Fahrgast sein kann. Es sollte klar sein, dass der Benutzer nicht Inhaber der mobilen Vorrichtung 22 oder des Fahrzeugs 24 sein muss (der Fahrzeugbenutzer kann beispielsweise ein Eigentümer oder ein Lizenznehmer der mobilen Vorrichtung, des Fahrzeugs oder beides sein).
Unter Bezugnahme auf das Fahrzeug 24 (1) ist das Fahrzeug in der veranschaulichten Ausführungsform als ein Pkw dargestellt, aber es sollte klar sein, dass jedes andere Fahrzeug, einschließlich Motorräder, LKWs, Sport Utility Vehicles (SUV), Campingfahrzeuge (RV), Schiffe, Flugzeuge usw., ebenfalls verwendet werden kann. Das Fahrzeug 24 kann eine Vielzahl elektrischer Bauteile, einschließlich, jedoch nicht einschränkt auf ein oder mehrere Fahrzeugsysteme oder Hardware-Module (VSM) 40, beinhalten. Eines der VSM 40 kann ein Gateway-Modul oder Gateway-Kommunikationsmodul 42 sein, und in mindestens einer Ausführungsform können die VSM 40 und das Gateway-Modul 42 mit einer oder mehreren Netzwerkverbindungen 44 (z. B. einem Bus, wie im Folgenden noch beschrieben) gekoppelt sein.
Die Fahrzeugsystemmodule (VSM) 40 können jede modulare Hardwarevorrichtung sein, die dazu ausgelegt ist, kategorische Fahrzeugfunktionen oder Aufgaben oder Funktionen oder Aufgaben in einer bestimmten Zone oder einem Bereich des Fahrzeugs 12 auszuführen (z. B. einem vorderen Bereich, einem hinteren Bereich, einem Seitenbereich, etc.). Jedes VSM 40 kann mit verschiedenen lokalen Hardwarekomponenten verbunden sein, kann eine geeignete Steuerelektronik aufweisen (z. B. einen lokalen Prozessor 50, einen lokalen Speicher 52, Anweisungen oder einen Code 58, der auf dem lokalen Speicher 52 gespeichert ist, der durch den lokalen Prozessor 50 ausführbar ist, usw.). Ferner können die VSM 40 jede geeignete elektrische Schnittstelle zum Kommunizieren über eine oder mehrere Netzwerkverbindungen 44 aufweisen.
Nicht beschränkende Beispiele von VSM 40 beinhalten ein GPS-Modul, ein Motorsteuergerät (ECM), ein Chassis-Steuermodul (BCM), ein Antriebsstrangsteuermodul (PCM) und dergleichen, die Fachleuten auf dem Gebiet bekannt sind. In einigen Implementierungen kann ein GPS-Modul eine Fahrzeugposition bestimmen, die für die Bereitstellung von Navigations- und anderen positionsbezogenen Diensten verwendet wird; weiterhin können derartige Informationen den Benutzern des Fahrzeugs 24 zur Verfügung gestellt werden. Das ECM kann automatisch verschiedene Aspekte des Motorbetriebs, wie beispielsweise Brennstoffzündung und Zündzeitpunkt, steuern. Darüber hinaus könnte das ECM mit integrierten Diagnosemerkmalen ausgestattet sein, die unzählige Echtzeitdaten bereitstellen, wie jene, die von verschiedenen Sensoren einschließlich Fahrzeugemissionssensoren empfangen werden, und kann eine standardisierte Reihe von Diagnosefehlercodes (DTC) bereitstellen, die einem Techniker ermöglichen, Fehlfunktionen innerhalb des Fahrzeugs 24 schnell zu identifizieren und zu beheben. In einigen Implementierungen kann das BCM verschiedene elektrische Komponenten regeln, die sich im gesamten Fahrzeug 24 befinden, wie die elektrische Türverriegelung und Scheinwerfer, die automatisiert, durch den Benutzer betätigbar oder eine Kombination davon sein können. Und das PCM könnte so konfiguriert werden, dass es den Betrieb einer oder mehrerer Komponenten des Fahrzeugantriebsstranges steuert. Natürlich sind dies lediglich Beispiele von Fahrzeugsystemmodulen 40; andere Ausführungsformen existieren.
Das Gateway-Modul 42 kann ein elektronisches Modul sein, das angepasst ist, um eine Zwischen- oder Portal-Vorrichtung zwischen den VSM 40 und Extra- oder Nicht-Fahrzeugvorrichtungen, wie der mobilen Vorrichtung 22, zu sein. Gemäß mindestens einer Ausführungsform kann das Gateway-Modul 42 konfiguriert sein, um über drahtlose Nahbereichskommunikation (SRWC) zu kommunizieren, und kann einen Prozessor 60, Speicher 62 und eine Kommunikationsschaltung 64 mit einem oder mehreren SRWC-Chipsätzen 66 beinhalten.
Der Prozessor 60 kann jede Art von Vorrichtung sein, die fähig ist, elektronische Anweisungen zu verarbeiten; nicht einschränkende Beispiele beinhalten einen Mikroprozessor, Mikrocontroller, Host-Prozessor, Steuerungen, Fahrzeugkommunikationsprozessoren und anwendungsspezifische integrierte Schaltkreise (ASICs). Es kann sich um einen dedizierten Prozessor handeln, der nur für das Gateway-Modul 42 verwendet wird, oder er kann mit anderen Fahrzeugsystemen gemeinsam genutzt werden. Der Prozessor 60 führt digital gespeicherte Anweisungen 68 aus, die in dem Speicher 62 gespeichert werden können und das Gateway-Modul 42 befähigen, eine oder mehrere Fahrzeugkommunikationsfunktionen durchzuführen – z. B. einschließlich das gleichzeitige zeitweise Kommunizieren mit der mobilen Vorrichtung 22, einem oder mehreren VSM 40 und, in einigen Implementierungen, mit dem Backend-System 16.
Der Speicher 62 kann jedes geeignete nichtflüchtige computerlesbare oder -nutzbare Medium beinhalten, das eine oder mehrere Speichervorrichtungen oder Gegenstände beinhaltet. Exemplarische nichtflü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. Wie oben diskutiert, kann der Speicher 62 ein oder mehrere Computerprogrammprodukte speichern, die als Software und/oder Firmware ausgeführt sein können. So kann beispielsweise der Speicher 62 Anweisungen 68 speichern, die es dem Gateway-Modul 42 ermöglichen, zumindest einen Teil des hierin beschriebenen Verfahrens zu erleichtern.
In einigen Implementierungen kann das Gateway-Modul 42 Teil einer Fahrzeugkopfeinheit (z. B. Infotainment-Einheit) sein und kann eine Benutzeroberfläche aufweisen (z. B. mit Steuerknöpfen, Tasten, Anzeige usw.) – z. B. Teil des zentralen Stack-Moduls; dies ist jedoch nicht erforderlich. Ferner ist das Gateway-Modul 40 in mindestens einer Ausführungsform so konfiguriert, dass es Telematikfunktionen auszuführt – z. B. u. a. das Kommunizieren mit anderen Mobilfunkvorrichtungen über einen Sprachanruf, einen Datenanruf oder beides. Somit beinhaltet die vorstehend beschriebene Kommunikationsschaltung 64 in mindestens einer Ausführungsform einen oder mehrere zellulare Chipsätze 70, sodass das Gateway-Modul 42 zellulare Konnektivität entsprechend einem oder mehreren zellularen Protokollen – z. B. einschließlich, aber nicht beschränkt auf GSM/GPRS, CDMA (z. B. CDMA2000) und LTE, beinhaltet. Gemäß einer Ausführungsform baut das Gateway-Modul 42, wie in dem Verfahren nachstehend beschrieben, eine Verbindung mit dem Backend-System 16 auf, empfängt ein oder mehrere Fahrzeug-Updates und stellt die Fahrzeug-Updates dem(den) entsprechenden Fahrzeugsystemmodul(en) 40 zur Verfügung, während die Kommunikation mit der mobilen Vorrichtung 22 über eine verdrahtete oder drahtlose Verbindung aufrechterhalten wird.
Die Netzwerkverbindungen 44 beinhalten ein beliebiges verdrahtetes fahrzeugeigenes Kommunikationssystem, um das Gateway-Modul 42 und andere VSM 40 miteinander zu verbinden oder zu koppeln sowie um Modul 42 und die VSM 40 mit anderen elektronischen Vorrichtungen zu verbinden. Gemäß einer Ausführungsform beinhaltet die Netzwerkverbindung 44 einen Datenbus (z. B. einen Bus, Entertainmentbus usw.). Beispiele von geeigneten Netzwerkverbindungen beinhalten ein Controller Area Network (CAN), einen medienorientierten Systemtransfer (MOST), ein lokales Kopplungsstrukturnetzwerk (LIN), ein lokales Netzwerk (LAN) und andere geeignete Verbindungen wie Ethernet, Audio-Visual Bridging (AVB) oder andere, die bekannten ISO-, SAE- und IEEE-Standards und -Spezifikationen, entsprechen, um nur einige zu nennen.
Wenn ein Benutzer/Kunde das Fahrzeug 24 erwirbt, sind im Allgemeinen Anweisungen 58 auf den VSM 40 gespeichert und darauf installiert – die beispielsweise dem jeweiligen VSM den Befehl erteilen, entsprechend den gewünschten Funktionen davon zu fungieren. So erteilen beispielsweise die Anweisungen des ECM dem ECM den Befehl, Motorfunktionen zu steuern; Anweisungen des PCM erteilen dem PCM den Befehl, Antriebsstrangfunktionen zu steuern; usw. Nach der anfänglichen Konfiguration der VSMs 40 des Fahrzeugs 24 kann der Fahrzeughersteller Fahrzeug-Updates entwickeln, d. h. Verbesserungen oder Änderungen an den bestehenden Anweisungen, was neue Anweisungen, neue Funktionalitäten, usw. beinhalten kann. Üblicherweise werden diese Fahrzeug-Update(s) in den VSMs 40 durch einen Servicetechniker in einer autorisierten Fahrzeugservice-Stelle oder manchmal durch den Benutzer durchgeführt (wenn beispielsweise das Fahrzeug am Wohnhaus des Benutzers abgestellt ist oder dergleichen). Unabhängig davon erfordert die herkömmliche Installation, dass sich das Fahrzeug 24 in einem immobilisierten Zustand befindet; z. B. für Bedienbarkeit oder aus Sicherheitsgründen. Tatsächlich ist der Servicetechniker oder Benutzer häufig angehalten, bejahend auf eine Aufforderung zu antworten, die anzeigt, dass das Fahrzeug während eines Fahrzeug-Update-Installationsvorgangs immobilisiert wird – wobei eine solche Immobilisierung ein Sicherheitsfeature darstellt. Betrachten Sie beispielsweise das Installieren eines Fahrzeug-Updates auf dem ECM, das eine Anzahl von Motorfunktionen steuert. Bei der Installation können die aktualisierten Anweisungen oder der aktualisierte Code, die/der spezifischen Fahrzeugfunktionen entsprechen/entspricht, geändert, ersetzt oder sogar überschrieben werden; somit stehen diese Funktionen nicht zur Ausführung und folglich nicht für den Fahrzeugbetrieb zur Verfügung. Deshalb würde das Fahrzeug 24 während des Aktualisierungsvorgangs normalerweise immobilisiert werden. Dies ist nur ein Beispiel; es gibt viele andere VSM-Beispiele, die Fachleuten auf dem Gebiet der Technik bekannt sind.
Das nachfolgend beschriebene Verfahren umgeht die unerwünschten Aspekte des konventionellen Fahrzeug-Update-Installationsverfahrens. Das beschriebene Verfahren ermöglicht es dem Fahrzeugbenutzer, das Fahrzeug in einem mobilisierten Zustand während des Installationsvorgangs zu betreiben, indem eine Proxy-Vorrichtung, wie eine mobile Vorrichtung 22, die Funktionen oder Aufgaben eines Ziel-VSMs 40 ausführt, d. h. eines VSMs, das das Fahrzeug-Update installiert.
In 2 wird ein Flussdiagramm dargestellt, das ein Verfahren zum Installieren eines Fahrzeug-Updates in einem VSM 40 an Bord des Fahrzeugs 24 zeigt. Das Verfahren beginnt mit Schritt 201, in dem das Fahrzeug 24 in einem mobilisierten Zustand dargestellt wird. So kann beispielsweise Schritt 201 beinhalten, dass sich ein Getriebe von Fahrzeug 24 im VORWÄRTSGANG befindet und das Fahrzeug im VORWÄRTSGANG betrieben werden kann – oder zumindest fähig ist, in den VORWÄRTSGANG zu wechseln und gefahren zu werden. Es ist offensichtlich, dass Schritt 201 gleichzeitig mit allen anderen Schritten 202–232 erfolgen kann. Somit zeigt Schritt 201, dass die Installation des Fahrzeug-Updates ohne Unterbrechung des normalen Fahrzeugbetriebs erfolgen kann; des Weiteren kann die Installation für den Fahrzeugbenutzer im Allgemeinen transparent sein. Während es beispielsweise in einigen Ausführungsformen wünschenswert sein kann, dass der Benutzer benachrichtigt wird oder der Benutzer auf eine Aufforderung auf der mobilen Vorrichtung 22 reagiert, um den Installationsvorgang zu initiieren, können das nachfolgende Übergabe-Betriebsverfahren und das umgekehrte Übergabe-Betriebsverfahren, die nachstehend beschrieben werden, automatisiert sein, d. h. es ist kein Eingreifen des Benutzers erforderlich.
Schritt 202 erfolgt gleichzeitig mit Schritt 201 (oder in einigen Ausführungsformen vor oder nach Schritt 201). In diesem Schritt kann die Anwendungssoftware 34 in dem Speicher 32 der mobilen Vorrichtung 22 installiert werden. Unter anderem kann die Anwendungssoftware 34 angepasst sein zum: Empfangen eines Fahrzeug-Updates von dem Backend-System 16; unter Verwendung des empfangenen Updates, Installieren des Updates in dem Speicher 32; unter Verwendung des Prozessors 30, Kommunizieren mit dem Gateway-Modul 42, während gleichzeitig Anweisungen ausgeführt werden, die mit dem Fahrzeug-Update assoziiert sind, um Fahrzeugfunktionen, -aufgaben, -operationen oder dergleichen, die mit einem der VSM 40, d. h. einem Ziel-VSM assoziiert sind, auszuführen. Somit fungiert die mobile Vorrichtung 22, die die Software 34 verwendet, als ein Spezialcomputer, der angepasst ist, um bestimmte Funktionen auszuführen, die das Durchführen eines Übergabe-Betriebsverfahrens und eines umgekehrten Übergabe-Betriebsverfahrens, wie im Folgenden ausführlicher beschrieben, umfassen.
Während das Fahrzeug 24 normal gefahren bzw. betrieben werden kann (Schritt 201), führt der Prozessor 50 des Ziel-VSMs 40 einen ersten, in dem Speicher 52 gespeicherten Satz von Anweisungen 58 vor jeder Installation eines Fahrzeug-Updates aus (Schritt 204). Somit kann der erste Satz von Anweisungen 58 jedwede zuvor in dem Speicher 52 gespeicherten Anweisungen (z. B. ursprüngliche von dem Fahrzeughersteller installierte Anweisungen oder jedwede gemäß einem vorherigen Fahrzeug-Update-Vorgang zuvor installierten aktualisierten Anweisungen) umfassen. Selbstverständlich wird die Art des ersten Satzes von Anweisungen je nach Funktion und Betrieb des bestimmten VSMs 40 variieren, d. h. Anweisungen, die ein BCM betreiben, unterscheiden sich von denen eines ECMs usw.
In Schritt 206 kann eine drahtlose Nahbereichskommunikations- (SRWC) Verbindung zwischen dem Gateway-Modul 42 und der mobilen Vorrichtung 22 aufgebaut werden. Die SRWC-Verbindung kann jedem geeigneten Protokoll entsprechen; nichteinschränkende Beispiele beinhalten Bluetooth, BLE, Wi-Fi Direct und dergleichen. SRWC-Verbindungen und Kommunikation/Konnektivität, die derartige Verbindungen verwenden, sind allgemein bekannt und werden hier nicht näher beschrieben.
In Schritt 208 empfängt die mobile Vorrichtung einen zweiten Satz von Anweisungen von dem Backend-System 16 (z. B. von dem Remote-Server 18 oder dem Datenservice-Center 20) – d. h. der zweite Satz von Anweisungen kann ein Update des ersten Satzes von Anweisungen 58 sein, der gegenwärtig von dem Ziel-VSM 40 verwendet wird. Die mobile Vorrichtung 22 kann diese Anweisungen in Reaktion auf das Durchführen von Schritt 202 (Installieren von Softwareanwendung 34) und einer bekannten Beziehung zwischen dem Benutzer des Fahrzeugs 24 und dem Benutzer der mobilen Vorrichtung 22 empfangen (d. h., die mobile Vorrichtung 22 gehört oder ist anderweitig mit einem berechtigten Benutzer des Fahrzeugs 24 und der mobilen Vorrichtung 22 assoziiert, und der Benutzer hat zuvor die Genehmigung zum Ausführen von Verfahren 200 erteilt oder tut dies beispielsweise während des Verfahrens). So können beispielsweise Anweisungen infolge der vorherigen Berechtigung der mobilen Vorrichtung zur Teilnahme an Verfahren, wie dem Übergabe-Betriebsverfahren und dem umgekehrten Übergabe-Betriebsverfahren, die im Folgenden beschrieben werden, in Schritt 208 zu der mobilen Vorrichtung 22 gesendet werden.
Schritt 208 kann zudem das Senden oder anderweitige Bereitstellen des empfangenen zweiten Satzes von Anweisungen von der mobilen Vorrichtung 22 zu dem Gateway-Modul 42 umfassen. Dies kann über die SRWC-Verbindung oder eine andere geeignete Verbindung (z. B. verdrahtet, zellular usw.) erfolgen. Andere Implementierungen dieses Aspekts von Schritt 208 sind ebenfalls möglich – z. B. könnte das Gateway-Modul 42 stattdessen den zweiten Satz von Anweisungen direkt von dem Remote-Backend 16 oder über eine weitere zwischengeschaltete Vorrichtung (z. B. eine andere als die mobile Vorrichtung 22) empfangen. Es sollte beachtet werden, dass der zweite Satz von Anweisungen schließlich von dem Backend-System 16 zu einer Vielzahl von Fahrzeugen mit dem gleichen Ziel-VSM 40, das unter Verwendung des gleichen ersten Satzes von Anweisungen 58 (wie beispielsweise Fahrzeug 24) arbeitet, kommuniziert werden kann.
Nach Schritt 208 kann die mobile Vorrichtung 22 den zweiten Satz von Anweisungen installieren – oder beispielsweise die Anwendungssoftware 34 aktualisieren, um den zweiten Satz von Anweisungen (Schritt 210) einzuschließen. Dies kann die Interaktion des Benutzers erfordern oder nicht. Nach Schritt 210 kann die mobile Vorrichtung 22 ausgestattet sein, um als ein Proxy-Gerät für die Zielvorrichtung während des unten beschriebenen Übergabe-Betriebsverfahrens zu fungieren (z. B. Ausführen des zweiten Satzes von Anweisungen). Selbstverständlich könnte die mobile Vorrichtung 22 in anderen Ausführungsformen stattdessen als das Proxy-Gerät dienen, das den ersten Satz von Anweisungen verwendet (d. h. während der zweite Satz von Anweisungen auf dem Ziel-VSM 40 installiert wird). (So kann beispielsweise die mobile Vorrichtung 22 zuvor stattdessen den ersten Satz von Anweisungen empfangen haben.) In mindestens einer Ausführungsform ist es bevorzugt, dass Schritt 210 die Installation des zweiten Satzes von Anweisungen auf der mobilen Vorrichtung 22 umfasst – somit erwirbt das Fahrzeug 24 während des unten beschriebenen Übergabe-Betriebsverfahrens beispielsweise die Fähigkeit, die aktualisierten oder neueren Anweisungen (vom Proxy) früher zu nutzen, als es das würde, wenn die mobile Vorrichtung 22 stattdessen nur den ersten Satz von Anweisungen während des Installationsschritts 210 installiert hätte.
In Schritt 212 kann das Gateway-Modul 42 eine Bereitschaftsnachricht zu dem Ziel-VSM 40 (z. B. über den Bus 44) senden. Die Bereitschaftsnachricht informiert das Ziel-VSM 40, dass das Gateway-Modul 42 ein Fahrzeug-Update für das Ziel-VSM empfangen hat; ferner kann die Bereitschaftsnachricht fordern, dass sich das Ziel-VSM 40 auf die Ausführung von Übergabe-Betriebsverfahren mit dem Proxy-Gerät (z. B. der mobilen Vorrichtung 22) vorbereitet. Und wenn das Ziel-VSM 40 entsprechend bereit ist, kann es in Schritt 214 seine Bereitschaft bestätigen.
Schritt 216 zeigt, dass das Gateway-Modul 42 eine ähnliche Bereitschaftsnachricht an die mobile Vorrichtung 22 (z. B. über die SRWC-Verbindung) senden kann. Diese Bereitschaftsnachricht informiert die mobile Vorrichtung, dass das Gateway-Modul 42 und das Ziel-VSM 40 bereit sind, die Übergabe-Betriebsverfahren auszuführen. In Reaktion darauf kann die mobile Vorrichtung 22 in einigen Ausführungsformen den Benutzer darüber informieren und/oder dazu auffordern, zu bestätigen, dass die mobile Vorrichtung zur Durchführung der Verfahren verwendet werden kann. Dies ist jedoch optional. Wenn die mobile Vorrichtung 22 angemessen bereit ist (und/oder wenn ein Benutzer die Verfahren über die mobile Vorrichtung 22 autorisiert hat), kann die mobile Vorrichtung 22 ihre Bereitschaft (z. B. über die SRWC-Verbindung) in Schritt 218 bestätigen.
In Schritt 220 wird ein Übergabe-Betriebsverfahren initiiert. Gemäß einer Ausführungsform wird diese Initiierung durch das Gateway-Modul 42 durchgeführt- beispielsweise, weil das Gateway-Modul in einer einzigartigen Lage ist, Kenntnis über die Bereitschaft von sowohl dem Ziel-VSM 40 und der mobilen Vorrichtung 22 zu haben, die ansonsten möglicherweise nicht miteinander kommunizieren würden. Das Initiieren beinhaltet das Koordinieren der Übernahme des Ausführens von Betriebsanweisungen, die normalerweise durch das Ziel-VSM 40 ausgeführt werden, durch die mobile Vorrichtung, wenn das Ziel-VSM mit dem Ausführen solcher Betriebsanweisungen aufhört. Wenn das Ziel-VSM 40 zum Beispiel mit dem Ausführen des ersten Satzes von Anweisungen aufhört, dann kann die mobile Vorrichtung 22 mit dem Ausführen des ersten oder zweiten Satzes von Anweisungen beginnen (Schritt 224). Zum Initiieren des Übergabe-Betriebsverfahrens kann das Gateway-Modul 42 ein synchronisiertes Triggersignal zu den beiden Vorrichtungen 22, 40 senden, sodass die Übergabe nahtlos ist. In einigen Implementierungen können bis dahin in dem Ziel-VSM 40 anstehende Aufgaben oder Funktionen an die mobile Vorrichtung 22 (über die Gateway Modul 42) übertragen werden – sodass beispielsweise die mobile Vorrichtung 22 die Ausführung dieser durchführen kann.
Nach dem Initiieren führt die mobile Vorrichtung 22 in Schritt 224 alle geeigneten Funktionen, Aufgaben, Operationen usw. gemäß den Anweisungen in der Anwendungssoftware 34 (z. B. den zweiten Satz von Anweisungen) durch. Während dieses Zeitraums fungiert das Gateway-Modul 42 als eine bidirektionale Leitungs- oder Durchgangsvorrichtung, die die Konnektivität der mobilen Vorrichtung mit der Netzwerkverbindung 44 ermöglicht (z. B. dem Bus), sodass das mobile Vorrichtung 22 Daten senden und empfangen kann – z. B. Nachrichten über den Bus senden und empfangen kann.
Sobald Schritt 224 erfolgt, kann sich das Gateway-Modul 42 an der Installation des Fahrzeug-Updates auf dem Ziel-VSM 40 (Schritt 226) beteiligen – d. h. die Schritte 224 und 226 erfolgen zumindest teilweise gleichzeitig. In mindestens einer Ausführungsform installiert das Gateway-Modul 42 den zweiten Satz von Anweisungen (das Fahrzeug-Update) auf dem Speicher 52 des Ziel-VSMs 40 – beispielsweise unter Verwendung der Netzwerkverbindung 44. Dieser zweite Satz von Anweisungen kann den ersten Satz von Anweisungen 58 verändern, ersetzen oder überschreiben und wird allgemein hin als Flash (oder Reflash) des Ziel-VSMs 40 bezeichnet – d. h., das jeweilige Betriebssystem wird dadurch aktualisiert. In einigen Ausführungsformen führt das Gateway-Modul 42 den Reflash des Ziel-VSMs 40 durch. Und in anderen Ausführungsformen kann das Ziel-VSM 40 das Fahrzeug-Update von dem Gateway-Modul 42 erhalten und das Ziel-VSM 40 kann den Reflash selbst durchführen (d. h., das Gateway-Modul 42 nimmt nicht an dem Reflash teil). Schritt 226 setzt sich fort, bis die Installation, das Neubooten oder Neustarten (falls erforderlich) usw. abgeschlossen sind.
In Schritt 228 kann das Gateway Modul 42 eine Bereitschaftsnachricht an die mobile Vorrichtung 22 senden – die z. B. anzeigt, dass das Fahrzeug-Update auf dem Ziel-VSM installiert wurde (d. h., dass die Installation abgeschlossen ist). Des Weiteren kann diese Bereitschaftsnachricht fordern, dass sich die mobile Vorrichtung 22 darauf vorbereitet, ein umgekehrtes Übergabe-Betriebsverfahren mit dem Ziel-VSM 40 auszuführen (über das Gateway-Modul 42). In Reaktion darauf kann die mobile Vorrichtung 22 in einigen Ausführungsformen den Benutzer darüber benachrichtigen und/oder informieren, dass die mobile Vorrichtung das Durchführen der vorgenannten Verfahren beendet. Dies ist jedoch auch optional. Umgekehrte Übergabe-Betriebsverfahren beinhalten das Koordinieren der Übernahme des Ausführens von Betriebsanweisungen (z. B. des zweiten Satzes von Anweisungen) durch das Ziel-VSM von dem Proxy-Gerät 22, wenn das Proxy-Gerät aufhört, diese Anweisungen in dessen Namen auszuführen. Wenn die mobile Vorrichtung 22 entsprechend bereit ist, kann sie in Schritt 230 ihre Bereitschaft bestätigen.
Schritt 232 zeigt, dass das Gateway-Modul 42 eine ähnliche Bereitschaftsnachricht zu dem Ziel-VSM 40 senden kann. Diese Bereitschaftsnachricht kann das Ziel-VSM informieren, dass das Gateway-Modul 42 und die mobile Vorrichtung 22 bereit sind, die umgekehrten Übergabe-Betriebsverfahren auszuführen. Wenn das Ziel-VSM 40 entsprechend bereit ist, kann das Ziel-VSM 40 in Schritt 234 seine Bereitschaft bestätigen.
In Schritt 236 wird das umgekehrte Übergabe-Betriebsverfahren ausgeführt. Wie bei dem vorstehend diskutierten Übergabe-Betriebsverfahren wird dies in mindestens einer Ausführungsform durch das Gateway-Modul 42 durchgeführt – beispielsweise, weil das Gateway-Modul in einer einzigartigen Lage ist, Kenntnis über die Bereitschaft von sowohl dem Ziel-VSM 40 und der mobilen Vorrichtung 22 zu haben, die ansonsten möglicherweise nicht miteinander kommunizieren würden. Die Übergabe-Betriebsverfahren in umgekehrter Richtung können den vorstehend erörterten (in Schritt 220) ähnlich sein, mit der Ausnahme, dass die mobile Vorrichtung 22 mit der Ausführung der VSM-Betriebsanweisungen aufhört und das Ziel-VSM 40 die Ausführung der Betriebsanweisungen wieder aufnimmt (Schritt 238) – außer dass das Ziel-VSM 40 infolge des Fahrzeug-Updates jetzt geänderte, ersetzte oder überschriebene Anweisungen – d. h, den zweiten Satz von Anweisungen, ausführt.
Wie bereits erläutert, kann das Fahrzeug 24 während der Schritte 202–238 in den VORWÄRTSGANG, RUCKWÄRTSGANG usw. versetzt und normal gefahren oder anderweitig betrieben werden. In mindestens einer Ausführungsform erfolgen die Schritte 204–238 automatisch an dem Fahrzeug 24 ohne Benachrichtigung des Benutzers und ohne Benutzerinteraktion (z. B. kann die Verbindung in Schritt 206 basierend auf einer vorherigen Identifikation, einem vorherigen Verbinden oder Bonden oder dergleichen automatisiert sein). Somit kann der Fahrzeugbenutzer fahren bzw. unterwegs zu einem Zielort sein und die Verfahrensschritte 204–238 können ausgeführt werden, ohne dass der Benutzer weiß, dass diese stattgefunden haben.
Zudem kann Verfahren 200 mit einem oder mehreren unterschiedlichen VSM 40 wiederholt werden. Oder beispielsweise kann das gleiche Ziel-VSM zu einem späteren Zeitpunkt wieder neu programmiert werden (z. B. mit einem dritten Satz von Anweisungen usw.). Für jede Neuprogrammierung kann das Backend-System 16 Kennungen, die mit dem installierten Code oder der Software-Version assoziiert sind, aufzeichnen/speichern, sodass das Backend-System entsprechend neue Fahrzeug-Updates bereitstellen kann, wie sie verfügbar werden.
In mindestens einer Ausführungsform umfasst das Ziel-VSM 40 elektronische Hardware, die für die Fahrzeugmobilität erforderlich ist, d. h., ohne Betrieb des Ziel-VSMs (oder Proxy-Betrieb in dessen Auftrag) kann das Fahrzeug nicht gefahren oder betrieben werden. So könnte beispielsweise das Ziel-VSM 40 ein Motorsteuergerät (ECM), ein Antriebsstrangsteuermodul (PCM) oder ein Bordnetzsteuergerät (BCM) sein. Andere Ziel-VSM 40 könnten ein Erfassungs- und Diagnosemodul (SDM), eine elektronische Klimasteuerungs-(ECC)Vorrichtung, ein Instrumententafel-Cluster (IPC), eine adaptive Fahrgeschwindigkeitsregelungs-(ACC)Vorrichtung, ein Fahrerassistenzsystem oder ADAS-Kartenmodul (AMM), ein externes Objektkameramodul (EOCM) zum Abbilden von Objekten außerhalb des Fahrzeugs (z. B. kann das EOCM mit einem oder mehreren anderen Modulen oder Vorrichtungen verwendet werden), ein Getriebesteuermodul (TCM), eine Passive-Entry/Passive-Start-Vorrichtung (PEPS), ein universelles Einparkhilfesystem (UPA) usw. beinhalten.
Es sind auch andere Ausführungsformen vorhanden. So fungierte beispielsweise die mobile Vorrichtung 22 in Verfahren 200 als Proxy-Gerät; dies ist jedoch nicht obligatorisch. Das Proxy-Gerät könnte jede andere geeignete elektronische Vorrichtung sein, die in der Lage ist, sich mit der Netzwerkverbindung 44 zu verbinden, wobei die Kommunikationsgeschwindigkeit ausreichend schnell ist, um unerwünschte Latenzen zu vermeiden. So kann beispielsweise gemäß einer Ausführungsform VSM 40' (1) anstelle der mobilen Vorrichtung 22 als das Proxy-Gerät fungieren. In dieser Ausführungsform könnte das Gateway-Modul 42 das Fahrzeug-Update von der mobilen Vorrichtung 22, direkt von dem Backend-System 16 usw. empfangen und dann können die Übergabe-(und umgekehrten Übergabe-)Betriebsverfahren mit VSM 40' ausgeführt werden. In mindestens einem Aspekt wird die Verwendung der mobilen Vorrichtung 22 anstelle der Verwendung des VSMs 40' als das Proxy-Gerät bevorzugt, da eine derartige Implementierung des VSMs 40' die Größe, das Gewicht und die Kosten des VSMs 40' erhöhen kann. So kann beispielsweise das VSM 40' zusätzliche oder schnellere Prozessoren, zusätzlichen Speicher, usw. erfordern, um diese Ausführungsform auszuführen.
In einer anderen Ausführungsform kann das Gateway-Modul 42 als das Proxy-Gerät in einer ähnlichen Weise wie das VSM 40' agieren. Und noch weitere Ausführungsformen sind ebenfalls möglich.
Somit wurde ein Kommunikationssystem beschrieben, das angepasst ist, um das Aktualisieren von Betriebsanweisungen für die Fahrzeugelektronik mittels eines Proxy-Geräts zu erleichtern, und insbesondere ein Verfahren zum Installieren eines Fahrzeug-Updates in einem Zielfahrzeugsystemmodul (VSM) an Bord eines Fahrzeugs, während es dem Fahrzeug ermöglicht wird, während der Installation des Fahrzeug-Updates in einem mobilisierten Zustand zu verbleiben. Das Proxy-Gerät kann Betriebsanweisungen für das Ziel-VSM empfangen, speichern und ausführen, die es dem Ziel-VSM ermöglichen, das Fahrzeug-Update zu installieren. Sobald das Fahrzeug-Update installiert ist, erfolgt eine Umkehrung der Steuerung, wobei das Ziel-VSM die Ausführung der Betriebsanweisungen wieder übernimmt und das Proxy-Gerät mit einer solchen Ausführung in dessen Namen aufhört, jedoch führt das Ziel-VSM beispielsweise nun aktualisierte (z. B. ersetzte, geänderte, überschriebene usw.) Betriebsanweisungen infolge der Installation aus. Während der Durchführung des Verfahrens verblieb das Fahrzeug in einem mobilisierten Zustand, z. B. kann das Fahrzeug normal gefahren oder anderweitig betrieben werden, und es ist beispielsweise kein zeitweises Immobilisieren des Fahrzeugs erforderlich, wofür Zeit benötigt wird und das den Benutzer frustrieren kann.
Es versteht sich, 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 Beschreibung und den Ansprüchen verwendet, sind die Begriffe „zum Beispiel”, „beispielsweise”, „wie zum Beispiel”, „wie” und „gleich”, sowie die Verben „umfassen”, „aufweisen”, „enthalten” und ihre anderen Verbformen, wenn sie in Verbindung mit einer Auflistung einer oder mehrerer Komponente(n) oder anderen Gegenständen verwendet werden, jeweils als offen auszulegen, d. h. die Auflistung ist nicht so zu sehen, dass andere, zusätzliche Komponenten oder Elemente ausgeschlossen sind. 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

Verfahren zum Installieren eines Fahrzeug-Updates in einem Fahrzeugsystemmodul (VSM) an Bord eines Fahrzeugs, was ermöglicht, dass das Fahrzeug während der Installation des Fahrzeug-Updates in einem mobilisierten Zustand verbleibt, das Verfahren die folgenden Schritte umfassend: das Empfangen eines Fahrzeug-Updates für das Ziel-VSM in dem Fahrzeug, während sich das Fahrzeug in dem mobilisierten Zustand befindet; das Durchführen eines Übergabe-Betriebsverfahrens zwischen einem Proxy-Gerät und dem Ziel-VSM, sodass das Proxy-Gerät die Genehmigung zum Ausführen von Fahrzeugbetriebsanweisungen erhält, als ob das Proxy-Gerät das Ziel-VSM ist; danach das Installieren des Fahrzeug-Updates in dem Ziel-VSM; und das Fortsetzen des Betriebs des Fahrzeugs in dem mobilisierten Zustand mit dem Proxy-Gerät anstelle des Ziel-VSMs während des Installationsschritts.
Verfahren nach Anspruch 1, worin ein Gateway-Modul in dem Fahrzeug das Fahrzeug-Update von dem Proxy-Gerät empfängt, wobei das Gateway-Modul das Fahrzeug-Update in dem Ziel-VSM installiert.
Verfahren nach Anspruch 1, worin das Gateway-Modul mit dem Ziel-VSM über einen Fahrzeugbus verbunden ist, wobei das Gateway-Modul mit dem Proxy-Gerät über eine drahtlose Nahbereichskommunikations-(SRWC)Verbindung verbunden ist.
Verfahren nach Anspruch 1, worin das Proxy-Gerät eine mobile Vorrichtung mit darauf installierter Anwendungssoftware ist, die angepasst ist, die Fahrzeugbetriebsanweisungen des Ziel-VSMs auszuführen.
Verfahren nach Anspruch 1, worin das Proxy-Gerät ein Gateway-Modul in dem Fahrzeug oder ein weiteres VSM in dem Fahrzeug ist.
Verfahren nach Anspruch 1, des Weiteren umfassend: das Empfangen des Fahrzeug-Updates an einer mobilen Vorrichtung; vor dem Empfangen des Fahrzeug-Updates für das Ziel-VSM, das Installieren des Fahrzeug-Updates auf der mobilen Vorrichtung, sodass die mobile Vorrichtung die Fahrzeugbetriebsfunktionen ausführen kann, die mit dem laufenden Fahrzeugbetrieb assoziiert sind; und das Bereitstellen des Fahrzeugs-Updates von der mobilen Vorrichtung an ein Gateway-Modul mit einer Kommunikationsverbindung zu dem Ziel-VSM.
Verfahren nach Anspruch 1, des Weiteren umfassend: in Reaktion auf den Installationsschritt, das Durchführen eines umgekehrten Übergabe-Betriebsverfahrens zwischen dem Proxy-Gerät und dem Ziel-VSM, sodass dem Ziel-VSM die Genehmigung erteilt wird, wieder mit dem Ausführen der Fahrzeugbetriebsanweisungen in dem Fahrzeug zu beginnen, wobei das Ziel-VSM einen anderen Satz von Betriebsanweisungen ausführt, als es vor der Installation getan hat.
Verfahren nach Anspruch 7, worin der andere Satz von Betriebsanweisungen identisch mit den Betriebsanweisungen ist, die durch das Proxy-Gerät ausgeführt werden, während das Fahrzeug-Update in dem Ziel-VSM installiert wurde.
Verfahren nach Anspruch 1, wobei das Ziel-VSM eines von einem Motorsteuergerät (ECM), einem Antrieb sstrangsteuermodul (PCM) oder einem Bordnetzsteuergerät (BCM) ist.
Computerprogrammprodukt, umfassend ein nicht-flüchtiges computerlesbares Medium für eine mobile Vorrichtung, die Computerprogrammanweisungen umfasst, die der mobilen Vorrichtung das zeitweise Ausführen eines aktualisierten Satzes von Betriebsanweisungen im Auftrag eines Fahrzeugsystemmoduls (VSM) in einem Fahrzeug ermöglichen, während der aktualisierte Satz von Betriebsanweisungen darin installiert wird, wodurch ermöglicht wird, dass das Fahrzeug während der Installation in einem mobilisierten Zustand verbleibt, das Computerprogrammprodukt umfassend: Anweisungen zum Empfangen des aktualisierten Satzes von Betriebsanweisungen an der mobilen Vorrichtung von einem Remote-Server; Anweisungen zum Kommunizieren mit dem Fahrzeug über ein Gateway-Modul darin in Reaktion auf den Empfangsschritt; und Anweisungen zum Durchführen eines Übergabe-Betriebsverfahrens in Reaktion auf das Empfangen einer Bereitschaftsnachricht von dem Gateway-Modul, wobei, während des Übergabe-Betriebsverfahrens, die mobile Vorrichtung den aktualisierten Satz von Betriebsanweisungen für das Fahrzeug über das Gateway-Modul ausführt, sodass das Fahrzeug den Betrieb fortsetzen kann, während das Gateway-Modul den aktualisierten Satz von Betriebsanweisungen in dem VSM installiert.