DE102014115943A1

DE102014115943A1 - System und Verfahren zum Vorbereiten eines Fahrzeugs für ein Fern-Reflash-Ereignis

Info

Publication number: DE102014115943A1
Application number: DE201410115943
Authority: DE
Inventors: Russ Eling
Original assignee: GM Global Technology Operations LLC; General Motors LLC
Current assignee: GM Global Technology Operations LLC; General Motors LLC
Priority date: 2013-11-06
Filing date: 2014-11-03
Publication date: 2015-05-07
Also published as: US20150128123A1; CN104639600A; CN104639600B; US9529584B2

Abstract

Realisierungen der vorliegenden Offenbarung ziehen das Verwenden der kommunikativen Verbindungen zwischen einem Telematikdienstanbieter (TSP) und einer Telematikeinheit in einem Fahrzeug in Betracht, um ein Fern-Reflash-Ereignis zu planen, Anweisungen für das Fahrzeug zur Vorbereitung für das Fern-Reflash-Ereignis auszugeben und um das Fern-Reflash-Ereignis zu verwalten. Ein TSP kann ermitteln, dass das Fahrzeug aktuell eine Software ausführt, für die eine Aktualisierung erwünscht ist. Danach kann der TSP Anweisungen an das Fahrzeug übertragen, um Vorbereitungen für das Fern-Reflash-Ereignis zu treffen. Bei einigen Realisierungen können die Anweisungen bewirken, dass das Fahrzeug während seines nächsten Fahrzyklus oder Ladeereignisses in Erwartung des Fern-Reflash-Ereignisses ein höheres Batterieladeniveau erhält.

Description

TECHNISCHES GEBIET
Die vorliegende Offenbarung bezieht sich allgemein auf ein Fahrzeugtelematiksystem und spezieller auf die Verwendung einer Telematikeinheit innerhalb eines Elektrofahrzeugs, um Fahrzeugsysteme hinsichtlich eines bevorstehenden Fern-Reflash-Ereignisses zu benachrichtigen und um Vorbereitungen für das bevorstehende Fern-Reflash-Ereignis zu planen.
HINTERGRUND
In den letzten Jahrzehnten wurden auf dem Gebiet der Kraftfahrzeugelektronik zahlreiche Fortschritte gemacht. Der Grad, zu dem elektronische Steuereinheiten (ECUs) und elektronische Fahrzeugdiagnoseüberwachungssysteme in moderne Fahrzeuge integriert wurden, wächst weiter an. Viele moderne Fahrzeuge enthalten zahlreiche ECUs, die beispielsweise Motorsteuermodule (ECMs), Antriebsstrangsteuermodule (PCMs), Getriebesteuermodule (TCMs), Bremssteuermodule (EBCMs), Aufhängungssteuermodule (SCMs) und Karosseriesteuermodule (BCMs) umfassen.
Telematikeinheiten in mobilen Fahrzeugen, die durch eine ECU, bezeichnet als Telematiksteuereinheit (TCU), gesteuert werden können, stellen Teilnehmern eine Konnektivität hinsichtlich eines Telematikdienstanbieters (TSP) bereit. Der TSP stellt Teilnehmern eine große Anzahl von Diensten bereit, die von einer Notrufhandhabung und einer Wiedererlangung gestohlener Fahrzeuge bis hin zu einer Diagnoseüberwachung, einer durch ein globales Navigationssystem gestützten Positionsidentifikation, Kartendiensten und einer Turn-by-Turn-Navigationsunterstützung reichen. Telematikeinheiten werden oftmals an einem Verkaufsort bereitgestellt und aktiviert, wenn ein Teilnehmer ein Fahrzeug mit Telematikausstattung kauft. Sobald die Telematikeinheiten bereitgestellt und aktiviert wurden, können sie durch einen Teilnehmer verwendet werden, um Telematikdienste, wie beispielsweise jene, die hierin beschrieben sind, von dem TSP zu erhalten.
Ein Dienst, der durch einen TSP bereitgestellt werden kann, ist die Bereitstellung von Aktualisierungen eingebetteter Software aus der Ferne. Ein Fahrzeug kann die jüngsten Versionen der eingebetteten Software für seine zahlreichen ECUs von einem OEM-Hersteller über seine Verbindung mit einem TSP über seine Telematikeinheit erhalten. Die Verbindung mit dem TSP ermöglicht der Telematikeinheit, die jüngsten Versionen von eingebetteter ECU-Software von dem TSP herunterzuladen. TSPs können in einem Fall, der als Fern-Reflash-Ereignis bekannt ist, auch den Aktualisierungsprozess der eingebetteten Software aus der Ferne steuern. Auf diese Weise kann ein OEM-Hersteller über die durch einen TSP bereitgestellten Dienste sicherstellen, dass eine Flotte von Fahrzeugen die jüngste Version von eingebetteter ECU-Software ausführt, ohne dass es erforderlich ist, dass jedes einzelne Fahrzeug in der Flotte einen Händler oder eine andere Werkstatt aufsucht.
ZUSAMMENFASSUNG DER ERFINDUNG
Realisierungen der vorliegenden Offenbarung ziehen das Verwenden der kommunikativen Verbindungen zwischen einem Telematikdienst am Bieter (TSP) und einer Telematikeinheit in einem Fahrzeug in Betracht, um ein Fern-Reflash-Ereignis zu planen, Anweisungen an das Fahrzeug für eine Vorbereitung für das Fern-Reflash-Ereignis auszugeben und um das Fern-Reflash-Ereignis zu verwalten. Ein TSP kann ermitteln, dass das Fahrzeug, das ein Mitglied einer Flotte von Fahrzeugen sein kann, welches durch den TSP identifiziert oder definiert wird, aktuell Software, wie beispielsweise eingebettete Software, die eine oder mehrere ECUs steuert, ausführt, für die eine Aktualisierung erwünscht ist. Die Ermittlung kann in Ansprechen auf die Identifikation von Daten in einer Datenbank erfolgen, die Softwareversionen angeben, die gegenwärtig von einem oder mehreren Fahrzeugen ausgeführt werden. Solch eine Datenbank kann durch den TSP, durch einen OEM-Hersteller oder durch eine andere Entität geführt werden. Die Ermittlung kann auch in Ansprechen auf eine Kommunikation erfolgen, die von dem Fahrzeug empfangen wird. Solch eine von dem Fahrzeug empfangene Kommunikation kann auf eine Anforderung reagieren, die durch den TSP an die Flotte von Fahrzeugen rundgesendet wird.
Beim Ermitteln, dass das Fahrzeug eine Software ausführt, für die eine Aktualisierung erwünscht ist, überträgt der TSP Anweisungen an das Fahrzeug, um Vorbereitungen für das Fern-Reflash-Ereignis zu treffen. Bei einigen Realisierungen können die Anweisungen bewirken, dass das Fahrzeug in Erwartung des Fern-Reflash-Ereignisses während seines nächsten Fahrzyklus oder Ladeereignisses ein höheres Batterieladeniveau erhält. Die durch den TSP übertragenen Anweisungen können das Fahrzeug auch anweisen, andere Vorbereitungen zu treffen. Bei einigen Realisierungen sind die Vorbereitungen entworfen, um sicherzustellen, dass das Fahrzeug aus den Fern-Reflash mit einer ausreichenden Batterieladung, um dem Fahrzeug zu ermöglichen, zu starten, mit einem Batterieladezustand oberhalb eines Schwellenwertniveaus oder mit einer anderen erfüllten Bedingung hervorgehen kann.
Die vorliegende Offenbarung zieht ferner die Verwaltung oder Ausführung des Fern-Reflash-Ereignisses in Betracht. Bei einigen Realisierungen wird eine Bestätigung, die einen gegenwärtigen Batterieladezustand umfassen kann, beim Abschluss des Fern-Reflash-Ereignisses durch das Fahrzeug bereitgestellt. Bei solchen Realisierungen kann der TSP ermitteln, ob der Batterieladezustand niedrig genug ist, sodass kein Ladeereignis erwünscht ist. Bei solchen Realisierungen zieht die vorliegende Offenbarung in Betracht, dass der TSP ein Signal an eine Kommunikationseinrichtung übertragen kann, die einem Benutzerkonto zugehörig ist, das zu dem Fahrzeug gehört.
Eine Realisierung besteht aus einem Verfahren, das an einem durch einen Telematikdienstanbieter (TSP) betriebenen Server realisiert ist, um ein Fahrzeug, das mit einer Telematikeinheit ausgestattet ist, für ein Fern-Reflash-Ereignis vorzubereiten, wobei das Verfahren umfasst, dass ermittelt wird, dass das Fahrzeug ein Kandidat für ein Fern-Reflash-Ereignis ist, ein Fern-Reflash-Ereignis für das Fahrzeug geplant wird und eine Benachrichtigung hinsichtlich des geplanten Fern-Reflash-Ereignisses an die Telematikeinheit übertragen wird, wobei die Benachrichtigung hinsichtlich des geplanten Fern-Reflash-Ereignisses eine Erhöhung des gespeicherten Energieniveaus einer Batterie an dem Fahrzeug während eines Fahrzyklus, der vor dem Fern-Reflash-Ereignis erfolgt, auf ein gespeichertes Energieniveau eines bevorstehenden Reflash ermöglicht.
Eine zusätzliche Realisierung besteht aus einem Verfahren, realisiert an einer Telematikeinheit in einem Fahrzeug, um das Fahrzeug für ein Fern-Reflash-Ereignis vorzubereiten, wobei das Verfahren umfasst, dass eine Benachrichtigung hinsichtlich eines bevorstehenden Fern-Reflash-Ereignisses von einem Server eines Telematikdienstanbieters empfangen wird, wobei die Benachrichtigung hinsichtlich eines bevorstehenden Fern-Reflash-Ereignisses eine Erhöhung des gespeicherten Energieniveaus einer Batterie an dem Fahrzeug während eines Fahrzyklus, der vor dem Fern-Reflash-Ereignis erfolgt, auf ein gespeichertes Energieniveau eines bevorstehenden Reflash ermöglicht.
Eine weitere Realisierung besteht aus einem System, um ein Fahrzeug für ein Fern-Reflash-Ereignis vorzubereiten, wobei das System einen durch einen Telematikdienstanbieter betriebenen Server umfasst, wobei der Server ausgestaltet ist, um zu ermitteln, dass das Fahrzeug ein Kandidat für ein Fern-Reflash-Ereignis ist, um das Fern-Reflash-Ereignis zu planen, um eine Benachrichtigung hinsichtlich des Fern-Reflash-Ereignisses an das Fahrzeug zu übertragen, und um Anweisungen zum Vorbereiten des Fern-Reflash-Ereignisses an das Fahrzeug und das Fahrzeug zu übertragen, wobei das Fahrzeug mit einer Telematikeinheit ausgestattet ist, die ausgestaltet ist, um eine Benachrichtigung hinsichtlich des Fern-Reflash-Ereignisses zu empfangen, um Anweisungen zum Vorbereiten des Fern-Reflash-Ereignisses zu empfangen und um eine Bestätigung, dass das Fern-Reflash-Ereignis abgeschlossen wurde, und ein gespeichertes Energieniveau nach dem Reflash an den Server zu übertragen.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Während die beigefügten Ansprüche die Merkmale der vorliegenden Erfindung genau ausführen, kann die Erfindung, zusammen mit ihren Zielen und Vorteilen, am besten aus der folgenden detaillierten Beschreibung in Verbindung mit den begleitenden Zeichnungen verstanden werden, in denen:
1 ein schematisches Diagramm einer Betriebsumgebung für ein Mobilfahrzeugkommunikationssystem ist, das bei Realisierungen der vorliegenden Offenbarung verwendet werden kann;
2 ein Flussdiagramm ist, das einen beispielhaften Prozess zusammenfasst, der durch einen Telematikdienstanbieter ausgeführt wird, um ein Fern-Reflash-Ereignis zu planen, ein Fahrzeug hinsichtlich des geplanten Fern-Reflash-Ereignisses zu benachrichtigen, das Fahrzeug für das Fern-Reflash-Ereignis vorzubereiten und Fern-Reflash-Abschlussbestätigungen handzuhaben;
3 ein Flussdiagramm ist, das einen beispielhaften Prozess zusammenfasst, der durch eine Telematikeinheit eines Fahrzeugs ausgeführt wird, um es für ein Fern-Reflash-Ereignis vorzubereiten und es diesem zu unterziehen;
DETAILLIERTE BESCHREIBUNG DER ZEICHNUNGEN
Bevor die Details der Erfindung erläutert werden, erfolgt ein kurzer Überblick über ein beispielhaftes Telematiksystem, um den Leser zu führen. 1 zeigt schematisch eine beispielhafte Umgebung zum Ausführen der Erfindung. Es sei angemerkt, dass die beschriebene Umgebung ein Beispiel ist und keine Einschränkung bezüglich der Verwendung anderer Umgebungen zum Ausführen der Erfindung einschließt. Mit Bezug auf 1 ist ein Beispiel eines Kommunikationssystems 100 gezeigt, das bei den vorliegenden Systemen und Verfahren verwendet werden kann und allgemein ein Fahrzeug 102, ein drahtloses Trägersystem 104, ein Bodennetz 106 und ein Call Center 108 umfasst. Es sei angemerkt, dass die Gesamtarchitektur, der Gesamtaufbau und der Gesamtbetrieb sowie die einzelnen Komponenten eines Systems wie des in 1 gezeigten in der Technik allgemein bekannt sind. Somit liefern die folgenden Absätze einen kurzen Überblick über solch ein beispielhaftes Informationssystem 100. Die vorliegenden Systeme und Verfahren könnten jedoch auch in anderen Umgebungen ausgeführt werden.
Das Fahrzeug 102 ist ein mobiles Fahrzeug, wie beispielsweise ein Motorrad, ein Auto, ein Lastwagen, ein Wohnmobil (RV von recreational vehicle), ein Boot, ein Flugzeug etc., und ist mit einer geeigneten Hardware und Software ausgestattet, die ihm ermöglicht, über das System 100 zu kommunizieren. Das Fahrzeug 102 kann durch einen Elektromotor betrieben werden, der ein Laden erfordert, kann durch eine Brennkraftmaschine betrieben werden oder kann durch eine Vielzahl von anderen Leistungsquellen betrieben werden. Die Fahrzeughardware 110, die in 1 allgemein gezeigt ist, umfasst: eine Telematikeinheit 114, ein Mikrofon 116, einen Lautsprecher 118 und Knöpfe und/oder Bedienelemente 120, die mit der Telematikeinheit 114 verbunden sind. Mit der Telematikeinheit 114 ist eine Netzverbindung oder ein Fahrzeugbus 122 wirksam gekoppelt. Beispiele geeigneter Netzverbindungen umfassen ein Controller Area Network (CAN), einen Media Oriented System Transfer (MOST), ein Local Interconnection Network (LIN), ein Ethernet und andere geeignete Verbindungen, wie beispielsweise jene, die bekannten ISO-, SAE- und IEEE-Standards und -Spezifikationen entsprechen, nur um einige zu nennen.
Die Telematikeinheit 114 ist eine bordeigene Einrichtung, die über ihre Kommunikation mit dem Call Center 108 eine Vielzahl von Diensten bereitstellt und allgemein eine elektronische Verarbeitungseinrichtung 128, einen oder mehrere Typen von elektronischem Speicher 130, einen zellularen Chipsatz/eine zellulare Komponente 124, ein Drahtlosmodem 126, eine Dualantenne 129 und eine Navigationseinheit, die einen GPS-Chipsatz/eine GPS-Komponente 132 enthält, umfasst. Der GPS-Chipsatz/die GPS-Komponente kann den Ort des Fahrzeugs mit einem hohen Grad an Genauigkeit ermitteln. Beispielsweise könnte der GPS-Chipsatz/die GPS-Komponente ermitteln, dass sich ein Elektrofahrzeug an einer bestimmten Elektrofahrzeugladestation befindet. Bei einem Beispiel besteht das Drahtlosmodem 126 aus einem Computerprogramm und/oder einem Satz von Softwareroutinen, die in der elektronischen Verarbeitungseinrichtung 128 ausgeführt werden, und wird es in Form hiervon ausgeführt. Der zellulare Chipsatz/die zellulare Komponente 124 und das Drahtlosmodem 126 können Netzzugriffseinrichtung (NAD von network access device) der Telematikeinheit 114 genannt werden. Die NAD 114 umfasst ferner einen Nahbereichsdrahtloseinheit 131, die über eine WLAN- oder WPAN-Verbindung kommunizieren kann. Beispielsweise kann die drahtlose Einheit 131 kommunizieren, indem Datenpakete über das Internet über eine WLAN-Verbindung gesendet werden. Ferner kann die drahtlose Einheit 131 mit der mobilen Einrichtung eines Benutzers, wie beispielsweise einem Mobiltelefon, Tablet-Computer, PDA oder dergleichen, über ein Nahbereichsdrahtlosprotokoll kommunizieren. Beispielsweise umfasst die Nahbereichsdrahtloseinheit 131 bei einer Realisierung eine Bluetooth-Einheit mit einem HF-Transceiver, der mit der mobilen Einrichtung eines Benutzers unter Verwendung eines Bluetooth-Protokolls kommuniziert.
Die Telematikeinheit 114 stellt eine Vielzahl von Diensten für Teilnehmer bereit. Beispiele für solche Dienste umfassen: Turn-by-Turn-Anweisungen und andere navigationsbezogene Dienste, die in Verbindung mit dem GPS-basierten Chipsatz/der GPS-basierten Komponente 132 bereitgestellt werden; eine Airbag-Einsatzbenachrichtigung und andere Notfall- oder Pannenhilfe-Dienste, die in Verbindung mit verschiedenen Crash- und/oder Kollisionssensorschnittstellenmodulen 133 und -sensoren 135 bereitgestellt werden, die an dem Fahrzeug angeordnet sind.
GPS-Navigationsdienste werden auf der Grundlage der Information der geographischen Position des Fahrzeugs, welche durch den GPS-basierten Chipsatz/die GPS-basierte Komponente 132 bereitgestellt wird, realisiert. Ein Benutzer der Telematikeinheit gibt ein Ziel unter Verwendung von Eingaben, die der GPS-Komponente entsprechen, ein, und eine Route zu einem Ziel wird auf der Grundlage der Zieladresse und einer aktuellen Position des Fahrzeugs, die ungefähr zum Zeitpunkt der Routenberechnung ermittelt wird, berechnet. Ferner können Turn-by-Turn-Anweisungen (TBT-Anweisungen) an einem Anzeigebildschirm, der der GPS-Komponente entspricht, und/oder über sprachliche Anweisungen, die über eine Fahrzeugaudiokomponente 137 bereitgestellt werden, bereitgestellt werden. Es sei angemerkt, dass die berechnungsbezogene Verarbeitung an der Telematikeinheit erfolgen kann oder an einem Call Center 108 erfolgen kann.
Durch den TSP werden Infotainment-bezogene Dienste bereitgestellt, bei denen Musik, Webseiten, Filme, Fernsehprogramme, Videospiele und/oder anderer Inhalt auf ein Infotainment-Center 136 heruntergeladen werden, das über einen Fahrzeugbus 122 und einen Audiobus 112 wirksam mit der Telematikeinheit 114 verbunden ist. Bei einem Beispiel wird heruntergeladener Inhalt für eine sofortige oder spätere Wiedergabe gespeichert.
Die vorstehende Liste von Funktionen ist keineswegs eine vollständige Liste aller Fähigkeiten der Telematikeinheit 114, wie es Fachleute erkennen werden, sondern ist lediglich eine Darstellung einiger der Dienste, die die Telematikeinheit 114 anbietet. Die Telematikeinheit 114 kann zusätzlich zu den oben beschriebenen eine Anzahl von Fachleuten bekannten Komponenten umfassen.
Fahrzeugkommunikationen verwenden Funkübertragungen, um einen Kommunikationskanal in dem drahtlosen Trägersystem 104 herzustellen, so dass Sprach- und/oder Datenübertragungen über den Kommunikationskanal erfolgen. Fahrzeugkommunikationen werden über den zellularen Chipsatz/die zellulare Komponente 124 für Sprachkommunikationen und das Drahtlosmodem 126 für eine Datenübertragung ermöglicht. Beispielsweise können Daten bezüglich einer Vorhersage einer Kombination erneuerbarer Energien einer Einrichtung über das Drahtlosmodem 126 an die Telematikeinheit 114 übertragen werden.
Um eine erfolgreiche Datenübertragung über den Kommunikationskanal zu ermöglichen, wendet das Drahtlosmodem 126 eine Form von Codierung oder Modulation an, um die digitalen Daten derart umzuwandeln, dass sie über einen Vocoder oder einen Sprach-Codec übermittelt werden können, der in dem zellularen Chipsatz/der zellularen Komponente 124 umfasst ist. Bei dem vorliegenden Verfahren kann jede geeignete Codierungs- oder Modulationstechnik verwendet werden, die eine akzeptable Datenrate und einen akzeptablen Bitfehler bereitstellt.
Die Dualmodusantenne 129 steht für den GPS-Chipsatz/die GPS-Komponente und den zellularen Chipsatz/die zellulare Komponente bereit.
Das Mikrofon 116 stellt dem Fahrer oder einem anderen Fahrzeuginsassen ein Mittel zum Eingeben von verbalen oder anderen auditiven Befehlen bereit und kann unter Verwendung einer in der Technik bekannten Mensch/Maschine-Schnittstelle-Technologie (HMI-Technologie von human/machine interface technology) mit einer eingebetteten Sprachverarbeitungseinheit ausgestattet sein. Im Gegensatz dazu stellt der Lautsprecher 118 den Fahrzeuginsassen einen verbalen Ausgang bereit und kann er entweder ein unabhängiger Lautsprecher sein, der speziell zur Verwendung mit der Telematikeinheit 114 bestimmt ist, oder kann er ein Teil der Fahrzeugaudiokomponente 137 sein. In jedem Fall ermöglichen das Mikrofon 116 und der Lautsprecher 118 der Fahrzeughardware 110 und dem Call Center 108, über hörbare Sprache mit den Insassen zu kommunizieren.
Die Fahrzeughardware umfasst auch ein(en) oder mehrere Knöpfe oder Bedienelemente 120, der/das oder die ausgestaltet ist/sind, um einem Fahrzeuginsassen zu ermöglichen, eine oder mehrere der Komponenten der Fahrzeughardware 110 zu aktivieren oder einzuschalten. Beispielsweise ist einer der Knöpfe 120 ein elektronischer Druckknopf, der, wenn er niedergedrückt wird, eine Sprachkommunikation mit dem Call Center 108 (sei es nun ein menschlicher Berater 148 oder ein automatisiertes Anrufbeantwortungssystem) initiiert. Bei einem anderen Beispiel initiiert einer der Knöpfe 120, wenn er niedergedrückt wird, Notfalldienste.
Die Audiokomponente 137 ist wirksam mit dem Fahrzeugbus 122 und dem Audiobus 112 verbunden. Die Audiokomponente 137 empfängt analoge Informationen über den Audiobus 112 und gibt sie als Töne aus. Digitale Informationen werden über den Fahrzeugbus 122 empfangen. Die Audiokomponente 137 stellt AM- und FM-Radio, CD, DVD und Multimediafunktionen bereit, die von dem Infotainment-Center 136 unabhängig sind. Die Audiokomponente 137 enthält ein Lautsprechersystem oder verwendet alternativ den Lautsprecher 118 über eine Arbitrierung an dem Fahrzeugbus 122 und/oder dem Audiobus 112.
Die Crash- und/oder Kollisionsdetektionssensorschnittstelle 133 des Fahrzeugs ist mit dem Fahrzeugbus 122 wirksam verbunden. Die Crash-Sensoren 135 liefern der Telematikeinheit 114 über die Crash- und/oder Kollisionsdetektionssensorschnittstelle 133 Informationen bezüglich der Schwere einer Fahrzeugkollision, wie beispielsweise des Aufprallwinkels und des Betrags an erfahrener Kraft.
Die Fahrzeugsensoren 139, die mit verschiedenen Sensorschnittstellenmodulen 134 verbunden sind, sind mit dem Fahrzeugbus 122 wirksam verbunden. Die Fahrzeugsensoren 139 umfassen Sensoren mit Fähigkeiten, die das Ermitteln des Ladezustands einer Batterie (z. B. als Prozentsatz der Gesamtladekapazität), des Ladestatus einer Batterie (d. h. ob die Batterie gegenwärtig geladen wird) und der gegenwärtigen Rate, mit der die Batterie geladen wird (z. B. als Änderungsrate des Prozentsatzes an geladener Kapazität pro Zeiteinheit) umfassen, jedoch nicht darauf beschränkt sind. Die Fahrzeugsensoren 139 können auch Gyroskope, Beschleunigungsmesser, Magnetometer, Emissionsdetektions- und/oder -steuersensoren und dergleichen umfassen, sind jedoch nicht darauf beschränkt. Die Sensorschnittstellenmodule 134 können eine Antriebsstrangsteuerung, eine Klimasteuerung und eine Karosseriesteuerung umfassen, nur um einige zu nennen.
Das drahtlose Trägersystem 104 kann ein Mobiltelefonsystem oder jedes andere geeignete drahtlose System, das Signale zwischen der Fahrzeughardware 110 und dem Bodennetz 106 überträgt, sein. Gemäß einem Beispiel umfasst das drahtlose Trägersystem 104 eine(n) oder mehrere Mobilfunktürme 138, Basisstationen und/oder Mobilfunkvermittlungsstellen (MSCs von mobile switching centers) 140 sowie jegliche andere Netzkomponenten, die erforderlich sind, um das drahtlose System 104 mit dem Bodennetz 106 zu verbinden. Die Mobilfunkvermittlungsstelle kann einen entfernten Datenserver umfassen.
Fachleute werden erkennen, dass verschiedene Mobilfunkturm/Basisstation/MSC-Anordnungen möglich sind und bei dem drahtlosen System 104 (hierin auch als das ”zellulare Netz” bezeichnet) verwendet werden könnten. Beispielsweise könnten eine Basisstation und ein Mobilfunkturm an dem gleichen Ort angeordnet sein oder könnten sie entfernt voneinander angeordnet sein, könnte eine einzelne Basisstation mit verschiedenen Mobilfunktürmen gekoppelt sein und könnten verschiedene Basisstationen mit einer einzelnen MSC gekoppelt sein, nur um einige der möglichen Anordnungen zu nennen. Vorzugsweise ist ein Sprach-Codec oder Vocoder in einer oder mehreren der Basisstationen umfasst, in Abhängigkeit von der bestimmten Architektur des drahtlosen Netzes könnte er jedoch auch in einer Mobilfunkvermittlungsstelle oder einigen anderen Netzkomponenten umfasst sein.
Das Bodennetz 106 ist beispielsweise ein herkömmliches bodenbasiertes Telekommunikationsnetz, das mit einem oder mehreren Festnetztelefonen verbunden ist und das drahtlose Trägernetz 104 mit dem Call Center 108 verbindet. Beispielsweise umfasst das Bodennetz 106 ein Fernsprechnetz (PSTN von public switched telephone network) und/oder ein Internetprotokoll-Netz (IP-Netz von Internet protocol network), wie es Fachleuten bekannt ist. Natürlich können ein oder mehrere Segmente des Bodennetzes 106 in Form eines drahtgebundenen Standardnetzes, eines Glasfaser- oder anderen optischen Netzes, eines Kabelnetzes, von anderen drahtlosen Netzen wie Wireless Local Networks (WLANs) oder Netzen, die einen drahtlosen Breitbandzugriff (BWA von broadband wireless access) bereitstellen, oder jeder Kombination hiervon realisiert sein.
Das Call Center (OCC) 108, das ein Telematikdienstanbieter (TSP von telematics service provider) besitzen oder durch diesen verwaltet oder betrieben werden kann, ist entworfen, um der Fahrzeughardware 110 eine Anzahl von verschiedenen System-Back-End-Funktionen bereitzustellen und umfasst gemäß dem hier gezeigten Beispiel allgemein eine(n) oder mehrere Schalter 142, Server 144, Datenbanken 146, menschliche Berater 148 sowie eine Vielzahl von anderen Telekommunikations- und Computergeräten 150, die Fachleuten bekannt sind. Diese verschiedenen Call Center-Komponenten sind beispielsweise über eine Netzverbindung oder einen Netzbus 152 miteinander gekoppelt, wie beispielsweise den zuvor in Verbindung mit der Fahrzeughardware 110 beschriebenen. Der Schalter 142, der ein Telekommunikationsanlagenschalter (PBX-Schalter von private branch exchange switch) sein kann, leitet eingehende Signale derart weiter, dass Sprachübertragungen für gewöhnlich entweder zu dem menschlichen Berater 148 oder zu einem automatisierten Antwortsystem gesendet werden, und Datenübertragungen für eine Demodulation und eine weitere Signalverarbeitung zu einem Modem oder einem anderen Telekommunikations- und Computergerät 150 weitergeleitet werden.
Das Telekommunikations- und Computergerät 150 umfasst ein Modem, das vorzugsweise einen Codierer wie zuvor erklärt umfasst und mit verschiedenen Einrichtungen, wie beispielsweise Anwendungsservern 144 und Datenbanken 146, verbunden sein kann. Beispielsweise könnten die Datenbanken 146 entworfen sein, um Teilnehmerprofildatensätze, Teilnehmerverhaltensmuster oder beliebige andere entsprechende Teilnehmerinformationen zu speichern. Im Speziellen können die Datenbanken 146 eine Information bezüglich einer oder mehrerer Kommunikationseinrichtungen, die mit den Konten eines oder mehrerer Teilnehmer in Verbindung steht, speichern. Ferner können die Datenbanken 146 bei einigen Realisierungen eine Information bezüglich der Versionen von durch Fahrzeuge ausgeführter Software, die mit den Konten eines oder mehrerer Teilnehmer in Verbindung steht, speichern. Obwohl das dargestellte Beispiel als in Verbindung mit einem mit Personal besetzten Call Center verwendet beschrieben wurde, sei angemerkt, dass das Call Center 108 eine beliebige zentrale oder entfernte Einrichtung, mit oder ohne Personal, mobil oder fest, sein kann, mit der Sprach- und Datenübertragungen ausgetauscht werden sollen.
Mit dem Call Center 108 und der Fahrzeughardware 110 sind kommunikativ Kommunikationseinrichtungen 166 verbunden. Kommunikationseinrichtung 166A ist mit dem Call Center 108 und der Fahrzeughardware 110 über das drahtlose Trägersystem 104 verbunden, während Kommunikationseinrichtung 166B mit dem Call Center 108 und der Fahrzeughardware 110 über das Bodennetz 106 verbunden ist. Die Kommunikationseinrichtungen 166 können ein beliebiges von einem Smartphone, einem Tablet-Computer, einem persönlichen digitalen Assistenten (PDA von personal digital assistant), einem Laptop-Computer, einem Desktop-Computer oder eine beliebige andere Einrichtung sein, die Übertragungen über ein Sprach- oder Datennetz senden und empfangen kann. Die Kommunikationseinrichtungen 166 können eine Information bezüglich Fern-Reflash-Ereignissen empfangen, die eine Bestätigung, dass ein Fern-Reflash-Ereignis erfolgreich abgeschlossen wurde, oder ein Signal, dass ein Fern-Reflash zu einem Batterieladezustand führte, der die potentiellen Bedürfnisse des Benutzers möglicherweise nicht erfüllt, umfassen.
Allgemein und nicht mit der Absicht, die Ansprüche einzuschränken, kann die beispielhafte Umgebung, die durch 1 gezeigt ist, durch Systeme und Verfahren verwendet werden, die die kommunikativen Verbindungen zwischen einem Telematikdienstanbieter (TSP), einer Telematikeinheit eines Fahrzeugs und einer Kommunikationseinrichtung nutzen, um den Abschluss eines Fern-Reflash-Ereignisses zu planen, das Fahrzeug hierfür vorzubereiten, diesen zu verwalten und Bestätigungsbenachrichtigungen diesbezüglich bereitzustellen. Fern-Reflash-Ereignisse aktualisieren die Software in den elektronischen Steuereinheiten (ECUs von electronic control units) eines Fahrzeugs. Solch eine Software kann eine eingebettete Software, die eine einzelne ECU oder einen anderen bordeigenen Computer steuert, umfassen, ist jedoch nicht darauf beschränkt. ECUs, die eine Software ausführen, die bei einem Fern-Reflash-Ereignis aktualisiert werden kann, umfassen ein Motorsteuermodul (ECM von engine control module), ein Getriebesteuermodul (TCM von transmission control module), ein Antriebsstrangsteuermodul (PCM von powertrain control module), ein Modul einer elektronischen Bremssteuerung (EBCM von electronic brake control module), ein Antiblockiersystem (ABS von anti-lock brake system) oder ein Karosseriesteuermodul (BCM von body control module), eine Türsteuereinheit (DCU von door control unit), eine Sitzsteuereinheit (SCU von seat control unit) und zahlreiche andere Steuermodule, die die verschiedenen elektronischen Systeme in dem Fahrzeug verwalten, sind jedoch nicht darauf beschränkt. Beispielsweise kann das ECM eine Software ausführen, die neben anderen Funktionen die Zündkerzenzündung, die Kraftstoffnutzung, die Motorleerlaufdrehzahl, Emissionen und das Leistungsvermögen steuert, und das TCM kann eine Software ausführen, die neben anderen Funktionen den Betrieb von Getriebe und Drehmomentwandler eines Fahrzeugs steuert.
Während eines Fern-Reflash-Ereignisses erlangt die Telematikeinheit 114 des Fahrzeugs 102 aktualisierte Software von dem TSP, z. B. von einem Server, der sich an dem Call Center 108 befindet, und kann sie ferner von einem Computer ausführbare Anweisungen von dem TSP erlangen, um zu bewirken, dass einer oder mehrere der bordeigenen Computer des Fahrzeugs die neu empfangene aktualisierte Software installieren, um vorherige Versionen der Software, die durch die bordeigenen Computersysteme ausgeführt wird, zu ersetzen oder zu aktualisieren. Bei einigen Realisierungen kann das Fahrzeug 102 ein von einem Computer lesbares Medium aufweisen, das mit von einem Computer ausführbaren Anweisungen ausgestaltet ist, um vor dem Fern-Reflash-Ereignis die Installation der neuen Software in die bordeigenen Computersysteme des Fahrzeugs zu ermöglichen, um die vorherigen Versionen zu ersetzen oder zu aktualisieren, die zuvor durch die bordeigenen Computersysteme geladen und ausgeführt wurden.
2 ist ein Flussdiagramm, das einen beispielhaften Prozess zusammenfasst, der durch einen Telematikdienstanbieter ausgeführt wird, um ein Fern-Reflash-Ereignis zu planen, ein Fahrzeug hinsichtlich des geplanten Fern-Reflash-Ereignisses zu benachrichtigen, das Fahrzeug für das Fern-Reflash-Ereignis vorzubereiten und Fern-Reflash-Abschlussbestätigungen handzuhaben. In Schritt 200 empfängt der Prozess einen Trigger für eine Fern-Reflash-Anfrage und ermittelt er die Kriterien für eine Teilnahme an einem Fern-Reflash-Ereignis. Der in Schritt 200 empfangene Trigger kann eine Ankündigung von einem OEM-Hersteller oder einem Drittentwickler, dass eine neue Softwareversion verfügbar ist, eine Ankündigung von einem OEM-Hersteller oder einem Drittsoftwareentwickler, dass eine Aktualisierung für eine bestimmte Softwareversion erwünscht ist, eine Nachricht von einem TSP, dass ein bestimmtes Fahrzeug für eine Softwareaktualisierung eingeplant ist, und eine Nachricht von der Telematikeinheit 114, die eine Softwareaktualisierungsprüfung anfordert, umfassen, ist jedoch nicht darauf beschränkt. Ferner können zahlreiche andere Typen von Kommunikationen zwischen der Telematikeinheit 114, dem TSP und OEM-Herstellern, Drittsoftwareentwicklern und anderen Entitäten eine Fern-Reflash-Ereignisanfrage auslösen. Beispielsweise kann nach einer Wartungsprüfung des Fahrzeugs ein Händler oder ein anderer Fahrzeugwartungsanbieter eine Anforderung an einen TSP übertragen, die ein Fern-Reflash-Ereignis auslöst. Das Ermitteln der Kriterien, die von einem Fahrzeug erfüllt werden müssen, damit das Fahrzeug als Kandidat für das Fern-Reflash-Ereignis betrachtet wird, kann eine Information umfassen, die angibt, dass alle Fahrzeuge einer bestimmten Marke und eines bestimmten Modells, die eine bestimmte Softwareversion ausführen, Kandidaten für ein Fern-Reflash-Ereignis sein können. Ferner kann in Schritt 200 auch eine Information empfangen werden, die bestimmt, ob ein Fern-Reflash-Ereignis für ein bestimmtes Fahrzeug verbindlich, empfohlen, optional oder anderweitig klassifiziert ist. Beispielsweise kann ein Trigger, der in Schritt 200 empfangen wird, ein Hinweis sein, dass eine Softwareversion 2.4 verfügbar ist und kann er von einer Information begleitet sein, die angibt, dass ein Fern-Reflash-Ereignis für Fahrzeuge erwünscht ist, die Softwareversion 2.2 oder eine frühere ausführen, und dass ein Fern-Reflash-Ereignis für Fahrzeuge vorgeschlagen wird, die Softwareversion 2.3 ausführen.
Bei verschiedenen Realisierungen kann das Ermitteln der Kriterien für eine Teilnahme an einem Fern-Reflash-Ereignis in Schritt 200 durch einen TSP, durch einen OEM-Hersteller, durch einen Softwareentwickler, durch das Fahrzeug 102 selbst oder durch irgendeine andere Entität, die eine Information bezüglich verfügbarer Softwareversionen besitzt, oder durch eine Gruppe von Entitäten, die zusammen Zugriff zu einer derartigen Information haben, durchgeführt werden. Bei einigen Realisierungen kann ein OEM-Hersteller eine bestimmte Version oder mehrere Versionen einer Software, die durch eine oder mehrere ECUs oder andere bordeigene Computer ausgeführt wird, für welche eine Aktualisierung bei einem Fern-Reflash-Ereignis erwünscht ist, identifizieren. Bei alternativen Realisierungen kann der TSP oder ein Drittsoftwareentwickler eine bestimmte Version oder mehrere Versionen von Software, die durch eine oder mehrere ECUs oder andere bordeigene Computer ausgeführt wird, für welche eine Aktualisierung erwünscht ist, identifizieren. Bei einigen Realisierungen werden veraltete Versionen der Software als Kandidaten zum Aktualisieren identifiziert, während bei anderen Realisierungen eine neue Softwareversion als Kandidat für eine Installation identifiziert wird. Ähnlich können Installationen und Aktualisierungen gemäß dem Vorteil, den sie bereitstellen können, kategorisiert werden. Beispielsweise können Installationen und Aktualisierungen als empfohlen, vorgeschlagen oder optional bezeichnet werden. Es können andere Begriffe verwendet werden, um Kategorien zu bezeichnen, in denen bestimmte Aktualisierungen oder Installationen angeordnet werden, und zwar gemäß dem Vorteil, den sie bereitstellen können. Bei einigen Realisierungen können der OEM-Hersteller, der TSP oder der Drittsoftwareentwickler ferner spezifizieren, dass die Softwareaktualisierung nur für eine bestimmte Fahrzeugmarke oder ein bestimmtes Fahrzeugmodell oder für alle bestimmten Marken oder Modelle von Fahrzeugen in einer bestimmten Gruppe von Marken und Modellen von Fahrzeugen geeignet ist.
In Schritt 210 wird eine Information bezüglich der eingebetteten Computersysteme des Fahrzeugs 102 und der Software, die gegenwärtig an den eingebetteten Computersystemen des Fahrzeugs 102, wie beispielsweise einer oder mehrerer elektronischer Steuereinheiten, geladen ist, erlangt. Die in Schritt 210 erlangte Information kann eine Versionsidentifikationsinformation für ein oder mehrere Softwareprogramme, eine Information bezüglich des Entwicklers eines oder mehrerer Softwareprogramme, Fehlernachrichten, die durch ein oder mehrere Softwareprogramme erzeugt werden, und eine Installationsinformation eines oder mehrerer Programme, die gegenwärtig an dem Fahrzeug 102 installiert sind, umfassen, ist jedoch nicht darauf beschränkt. Im Allgemeinen kann in Schritt 210 jede Information erlangt werden, die notwendig oder nützlich ist, um zu ermitteln, ob das Fahrzeug 102 ein Kandidat für ein Fern-Reflash-Ereignis ist oder nicht. Die in Schritt 210 erlangte Information kann von der Telematikeinheit 114 des Fahrzeugs 102 empfangen werden. Alternativ kann die in Schritt 210 erlangte Information von einer Datenbank, von einem OEM-Hersteller, der für die Herstellung des Fahrzeugs 102 verantwortlich ist, oder von einer anderen Entität erhalten werden.
In Schritt 220 ermittelt der Prozess, ob das Fahrzeug 102 ein Kandidat für ein Fern-Reflash-Ereignis ist oder nicht. Das Ermitteln, ob das Fahrzeug 102 ein Kandidat für ein Fern-Reflash-Ereignis ist oder nicht, kann umfassen, dass ermittelt wird, ob die in Schritt 210 empfangene Information angibt, dass das Fahrzeug 102 Kriterien für ein Fern-Reflash-Ereignis erfüllt, die in Schritt 200 empfangen werden, oder nicht. Ferner kann eine Information, die in einer Datenbank gespeichert ist, z. B. eine Benutzerkontoinformation oder Benutzerkontodatensätze, hinzugezogen werden, um zu ermitteln, ob das Fahrzeug 102 ein Kandidat für ein Fern-Reflash-Ereignis ist oder nicht. Wenn in Schritt 220 ermittelt wird, dass das Fahrzeug 102 die Kriterien für eine Kandidatur für ein Fern-Reflash-Ereignis nicht erfüllt, fährt der Prozess mit Schritt 280 fort, in dem der Prozess endet. Wenn jedoch ermittelt wird, dass das Fahrzeug 102 die Kriterien erfüllt, um ein Kandidat für ein Fern-Reflash-Ereignis zu sein, fährt der Prozess mit Schritt 230 fort.
Bei einigen Realisierungen kann das Fahrzeug 102 in Schritt 220 ermitteln, ob es ein Kandidat für ein Fern-Reflash-Ereignis ist oder nicht. Bei derartigen Realisierungen werden Daten bezüglich der Marken und/oder Modelle eines Fahrzeugs, die Kandidaten sein können, um einem Fern-Reflash-Ereignis unterzogen zu werden, und bezüglich der bestimmten Version oder den bestimmten Versionen von Software und bestimmten ECUs, die eine derartige Software ausführen und die Kandidaten für eine Aktualisierung während des Fern-Reflash-Ereignisses sein können, direkt an das Fahrzeug 102 übertragen. Beispielsweise kann ein bordeigener Computer an dem Fahrzeug 102 in dem Schritt 220 ermitteln, ob das Fahrzeug 102 ein Kandidat für das Fern-Reflash-Ereignis ist oder nicht, indem ermittelt wird, ob das Fahrzeug 102 eine Marke oder ein Modell umfasst, die oder das durch die an das Fahrzeug 102 übertragenen Daten identifiziert wird, und indem ferner ermittelt wird, ob einer der bordeigenen Computer des Fahrzeugs eine durch die Daten identifizierte Software ausführt. Bei einigen Realisierungen überträgt das Fahrzeug 102, wenn es in Schritt 220 ermittelt, dass es ein Kandidat für ein Fern-Reflash-Ereignis ist, eine Bestätigung seiner Kandidatur an den TSP, während das Fahrzeug 102 bei anderen Realisierungen eine Bestätigung seiner Kandidatur an den OEM-Hersteller oder einen Drittsoftwareentwickler überträgt.
Bei anderen Realisierungen kann der TSP in Schritt 220 ermitteln, ob ein bestimmtes Fahrzeug ein Kandidat für ein Fern-Reflash-Ereignis ist oder nicht. Bei Realisierungen, bei denen die Daten bezüglich der Marken und/oder Modelle eines Fahrzeugs, die Kandidaten sein können, um einem Fern-Reflash-Ereignis unterzogen zu werden, und bezüglich der bestimmten Version oder den bestimmten Versionen von Software und bestimmter ECUs, die eine derartige Software ausführen und die Kandidaten für ein Aktualisieren während des Fern-Reflash-Ereignisses sein können, an den TSP übertragen werden, kann der TSP in Schritt 220 eine Datenbank hinzuziehen, die Daten bezüglich jedes Fahrzeugs, das an den durch den TSP bereitgestellten Diensten teilnimmt, enthält. Die Datenbank kann jene Fahrzeuge durch die Fahrzeugidentifikationsnummer (VIN von vehicle identification number) indizieren, oder die Datenbank kann jene Fahrzeuge über ein anderes Verfahren indizieren. Die Datenbank kann für das Fahrzeug 102 eine Liste von bordeigenen Computern und Softwareversionen, die durch jeden der bordeigenen Computer des Fahrzeugs 102 ausgeführt werden, enthalten. Bei einigen Realisierungen kann der TSP, wenn die Datenbank keinen Eintrag eines vollständigen Eintrags für das Fahrzeug 102 enthält, eine Anforderung an das Fahrzeug 102 übertragen und anfordern, dass das Fahrzeug 102 die fehlenden Daten von der Datenbank an den TSP überträgt. Durch Vergleichen der für das Fahrzeug 102 gespeicherten Daten mit den Daten bezüglich der Marken und/oder Modelle eines Fahrzeugs, die Kandidaten sein können, um einem Fern-Reflash-Ereignis unterzogen zu werden, und bezüglich der bestimmten Version oder den bestimmten Versionen von Software und bestimmter ECUs, die eine derartige Software ausführen und die Kandidaten zum Aktualisieren während des Fern-Reflash-Ereignisses sein können, ermittelt der TSP in Schritt 220, ob das Fahrzeug 102 ein Kandidat für das Fern-Reflash-Ereignis ist.
In Schritt 230 plant der Prozess ein Fern-Reflash-Ereignis. Das Planen eines Fern-Reflash-Ereignisses kann umfassen, dass ein oder mehrere Zeitintervalle ermittelt werden, in denen der TSP ausreichend Ressourcen verfügbar hat, um ein Fern-Reflash-Ereignis zu verwalten. Ferner kann das Planen umfassen, dass ein Benutzer des Fahrzeugs 102 oder ein Benutzer, der ein Benutzerkonto besitzt, das zu dem Fahrzeug 102 gehört, gefragt wird. Solch eine Abfrage kann mehrere verfügbare Zeitschlitze umfassen und kann fordern, dass der Benutzer einen für die Verwaltung des Fern-Reflash-Ereignisses auswählt. Alternativ kann solch eine Abfrage fordern, dass der Benutzer einen Zeitschlitz für die Verwaltung des Fern-Reflash-Ereignisses ohne Beschränkungen der Zeitschlitze, die für eine Benutzerauswahl verfügbar sind, auswählt. Die an den Benutzer gesendete Abfrage kann auch eine Information bezüglich der Software umfassen, die bei dem Fern-Reflash-Ereignis aktualisiert wird, und dem Benutzer ermöglichen, zusätzliche Aktualisierungen zur Durchführung auszuwählen oder bestimmte Aktualisierungen zu löschen. Bei verschiedenen Realisierungen kann die Abfrage dem Benutzer auch eine Möglichkeit bereitstellen, um sich dafür zu entscheiden, nicht zuzulassen, dass das Reflash-Ereignis fortfährt. Solch eine Veto- oder Löschmöglichkeit kann vorgezogen werden, wenn das potentielle Fern-Reflash-Ereignis in Bezug auf das bestimmte Fahrzeug als optional oder vorgeschlagen klassifiziert wird. Bei anderen Realisierungen ist keine Benutzerinteraktion für das Planen eines Reflash-Ereignisses erforderlich. Das Reflash-Ereignis kann auf der Grundlage einer Ressourcenverfügbarkeit oder einer Anzahl von anderen Betrachtungen geplant werden. Bei verschiedenen Realisierungen kann das Fern-Reflash-Ereignis zu einem bestimmten Zeitpunkt, an einem bestimmten Ort oder zu einem bestimmten Zeitpunkt und an einem bestimmten Ort geplant werden. Beispielsweise könnte ein Fern-Reflash-Ereignis für den nächsten Zeitpunkt, an dem die Telematikeinheit 114 des Fahrzeugs 102 eine Verbindung mit einem bestimmten WiFi-Netz herstellt, geplant werden.
In Schritt 240 überträgt der Prozess eine Benachrichtigung des geplanten Fern-Reflash-Ereignisses und Anweisungen zum Vorbereiten des Fern-Reflash-Ereignisses an die Telematikeinheit 114 des Fahrzeugs 102. Die Anweisungen zum Vorbereiten für das Fern-Reflash-Ereignis können Anweisungen für ein Batterieladesystem des Fahrzeugs 102 zum Laden der Batterie des Fahrzeugs auf ein höheres gespeichertes Energieniveau während jedes Fahrzyklus, bis das Fern-Reflash-Ereignis verwaltet ist, umfassen. Alternativ können die Anweisungen das Ladesystem des Fahrzeugs 102 anweisen, die Batterie jedes Mal auf das gespeicherte Energieniveau eines bevorstehenden Reflash zu laden, wenn die Batterie während eines bestimmten Zeitfensters geladen wird. Solch ein Zeitfenster kann zu dem Zeitpunkt, zu dem das Reflash-Ereignis geplant ist, oder beim Empfangen einer Bestätigung, dass das Reflash-Ereignis stattgefunden hat, enden. Beispielsweise kann ein gespeichertes Energieniveau eines bevorstehenden Reflash durch den TSP ermittelt werden und können die Anweisungen das Batterieladesystem anweisen, das Fahrzeug auf ein höheres gespeichertes Energieniveau zu laden.
Bei verschiedenen Realisierungen kann das gespeicherte Energieniveau eines bevorstehenden Reflash durch den TSP, durch die Telematikeinheit 114 des Fahrzeugs 102, durch das Ladesystem des Fahrzeugs 102, durch den OEM-Hersteller, der das Fahrzeug 102 hergestellt hat, oder durch eine andere Entität ermittelt werden.
Das gespeicherte Energieniveau eines bevorstehenden Reflash kann für alle Reflash-Ereignisse über eine bestimmte Marke und ein bestimmtes Modell eines Fahrzeugs konstant sein, oder das gespeicherte Energieniveau eines bevorstehenden Reflash kann für alle Marken und Modelle eines Fahrzeugs konstant sein. Bei einigen Realisierungen kann ein Schätzwert der Menge an Daten, die während des Fern-Reflash-Ereignisses an das Fahrzeug übertragen werden, verwendet werden, um das Niveau eines bevorstehenden Reflash zu ermitteln. Bei solchen Realisierungen kann das gespeicherte Energieniveau eines bevorstehenden Reflash über jedes einzelne Reflash-Ereignis dynamisch angepasst werden. Bei ähnlichen Realisierungen kann das gespeicherte Energieniveau eines bevorstehenden Reflash gemäß einer zusätzlichen Information ermittelt werden, die Eigenschaften der Softwareprogramme, die während des Reflash-Ereignisses aktualisiert werden sollen, den Ort des geplanten Reflash-Ereignisses, Eigenschaften der Verbindung, die während der Verwaltung des Reflash-Ereignisses verwendet wird, Benutzerkontoeinstellungen, die an einem Benutzerkonto festgelegt sind, das zu dem Fahrzeug gehört, und eine Verlaufsdiagnoseinformation bezüglich des Fahrzeugs 102 umfasst, jedoch nicht darauf beschränkt ist. Das gespeicherte Energieniveau eines bevorstehenden Reflash kann als Prozentsatz des maximalen gespeicherten Energieniveaus der Batterie festgelegt werden, kann für alle Reflash-Ereignisse einheitlich festgelegt werden oder kann gemäß den Eigenschaften des bestimmten Reflash-Ereignisses festgelegt werden.
Reflash-Vorbereitungsanweisungen, die in Schritt 240 an das Fahrzeug 102 übertragen werden, können auch Anweisungen für die Telematikeinheit 114 des Fahrzeugs 102 umfassen, um eine Erinnerung für einen Benutzer des Fahrzeugs 102 bereitzustellen. Solche Erinnerungen können Anweisungen umfassen, die den Benutzer anweisen, zu einem bestimmten Ort zu fahren, an dem das Reflash-Ereignis geplant wurde. Ferner können Reflash-Vorbereitungsanweisungen spezifizieren, dass das Fahrzeug 102 den Ladezustand vor dem Beginn des Reflash-Ereignisses, zu dem Zeitpunkt, zu dem geplant ist, dass das Reflash-Ereignis beginnt, oder bei Beginn des Reflash-Ereignisses verifizieren sollte. Wenn das gespeicherte Energieniveau des Fahrzeugs unter einem Schwellenwertniveau liegt, das in den Reflash-Vorbereitungsanweisungen spezifiziert sein kann und nicht gleich dem gespeicherten Energieniveau eines bevorstehenden Reflash sein muss, kann die Telematikeinheit 114 das Reflash-Ereignis löschen.
Bei alternativen Realisierungen werden in Schritt 240 keine Anweisungen zum Vorbereiten des Fern-Reflash-Ereignisses an die Telematikeinheit übertragen. Stattdessen löst die in Schritt 240 an die Telematikeinheit übertragene Benachrichtigung die Vorbereitung des Fahrzeugs für das bevorstehende Reflash-Ereignis aus. Bei solchen Realisierungen löst der Empfang der Benachrichtigung in Schritt 240 einen Prozess, für dessen Ausführung die Telematikeinheit 114 des Fahrzeugs 102 programmiert ist, aus bzw. setzt er diesen in Bewegung [engl.: ”triggers sets into motion”]. Der Prozess kann das Ausgeben von Anweisungen an ein Batterieladesystem des Fahrzeugs, um die Fahrzeugbatterie während jedes Fahrzyklus auf ein höheres gespeichertes Energieniveau zu laden, bis das Fern-Reflash-Ereignis verwaltet ist, oder die die Vorbereitung des Fahrzeugs für ein bevorstehendes Reflash-Ereignis auf andere Weise ermöglichen, umfassen.
In Schritt 250 wird das Fern-Reflash-Ereignis verwaltet. Sobald das Fern-Reflash-Ereignis geplant wurde und Anweisungen zum Vorbereiten des Fern-Reflash-Ereignisses an das Fahrzeug gesendet wurden, verwaltet der TSP das Fern-Reflash-Ereignis in Schritt 250. Die Verwaltung des Fern-Reflash-Ereignisses umfasst Datenübertragungen zwischen dem TSP und der Telematikeinheit 114 des Fahrzeugs 102. Ferner können die Fern-Reflash-Ereignisse Datenübertragungen zwischen einem OEM-Hersteller und dem Fahrzeug 102 oder zwischen einem Drittsoftwareentwickler und dem Fahrzeug 102 umfassen. Beispielsweise kann die Verwaltung des Fern-Reflash-Ereignisses in Schritt 250 den Empfang von Anweisungen durch die Telematikeinheit 114 zum Erlangen von Daten, die Software darstellen, die an bordeigenen Computersystemen des Fahrzeugs installiert werden soll, von einem Server, der von einem OEM-Hersteller, einem Drittsoftwareentwickler oder einer anderen Entität geführt wird, umfassen. Die Datenübertragungen können über das drahtlose Trägersystem 104 oder über eine Nahbereichskommunikationsverbindung ausgeführt werden, die über die drahtlose Einheit 131 hergestellt wird. Beispielsweise kann sich die Telematikeinheit 114 mit dem Internet über eine WLAN-Verbindung verbinden, die über die drahtlose Einheit 131 hergestellt wird. Die Verwaltung des Fern-Reflash-Ereignisses kann auch die Installation von Software, welche aktualisierte Versionen von eingebetteter Software, die durch eine oder mehrere ECUS an dem Fahrzeug 102 ausgeführt wird, umfasst, durch bordeigene Computer, die sich an dem Fahrzeug 102 befinden, umfassen.
Nachfolgend empfängt der TSP in Schritt 260 eine Bestätigung von der Telematikeinheit 114 des Fahrzeugs 102, dass das Fern-Reflash-Ereignis verwaltet wurde. Ferner überträgt die Telematikeinheit 114 in Schritt 260 auch Daten bezüglich des gespeicherten Energieniveaus nach dem Reflash des Fahrzeugs 102. Die Daten bezüglich des gespeicherten Energieniveaus nach dem Reflash des Fahrzeugs 102 können ein Unvermögen des Fahrzeugs zu starten oder das Unvermögen des Fahrzeugs, die erwartete Fahrt abzuschließen, angeben.
In Schritt 270 ermittelt der TSP, ob das gespeicherte Energieniveau nach dem Reflash möglicherweise unerwünscht ist oder nicht. Das Ermitteln, ob das gespeicherte Energieniveau nach dem Reflash möglicherweise unerwünscht ist, kann umfassen, dass die erwartete Fahrt des Fahrzeugs ermittelt wird und ermittelt wird, ob das Fahrzeug solch eine Fahrt vor einem nachfolgenden Ladeereignis durchführen kann. Das Ermitteln, ob das gespeicherte Energieniveau nach dem Reflash unerwünscht ist oder nicht, kann auch umfassen, dass ermittelt wird, ob das gespeicherte Energieniveau angibt, dass die Batterie nicht auf ein ausreichendes Niveau geladen ist, um dem Fahrzeug 102 zu ermöglichen, seinen Motor zu starten.
Wenn das gespeicherte Energieniveau nach dem Reflash nicht potentiell unerwünscht ist, fährt der Prozess mit Schritt 280 fort, in dem der Prozess endet. Wenn jedoch das gespeicherte Energieniveau nach dem Reflash potentiell unerwünscht ist, fährt der Prozess mit Schritt 275 fort, in dem ein Signal übertragen wird. Das Signal kann an einen Benutzer des Fahrzeugs, an eine Kommunikationseinrichtung, die zu einem Benutzerkonto gehört, zu dem das Fahrzeug gehört, wie beispielsweise eine der Kommunikationseinrichtungen 166, oder an ein Notfallpersonal für das Fahrzeug übertragen werden. Beispielsweise kann das Signal an eine Entsendungseinrichtung übertragen werden, die Personal entsenden kann, das die Fahrzeugbatterie aufladen kann. Nachdem das Signal in Schritt 275 übertragen wurde, fährt der Prozess mit Schritt 280 fort, in dem der Prozess endet.
3 ist ein Flussdiagramm, das einen beispielhaften Prozess zusammenfasst, der durch eine Telematikeinheit eines Fahrzeugs ausgeführt wird, um sich auf ein Fern-Reflash-Ereignis vorzubereiten und sich diesem zu unterziehen. In Schritt 300 empfängt die Telematikeinheit eine Benachrichtigung hinsichtlich eines bevorstehenden Reflash-Ereignisses und Anweisungen zur Vorbereitung für das bevorstehende Reflash-Ereignis. Die Benachrichtigung des bevorstehenden Reflash-Ereignisses kann eine Information bezüglich des Zeitpunkts, zu dem das Reflash-Ereignis geplant ist, oder des Orts, an dem das Reflash-Ereignis geplant ist, umfassen. Ferner kann die Benachrichtigung eine Information bezüglich Aktionen umfassen, die während des Reflash-Ereignisses ausgeführt werden. Beispielsweise kann die Benachrichtigung Identitäten einer oder mehrerer Softwareversionen, die aktualisiert werden, oder einer oder mehrerer ECUs, die Software ausführen, die aktualisiert wird, angeben. Die in Schritt 300 empfangenen Anweisungen weisen das Fahrzeug 102 an, Maßnahmen zu treffen, um sich für das Fern-Reflash-Ereignis vorzubereiten, so dass der Reflash erfolgreich abgeschlossen werden kann, während das Fahrzeug in einem vollständig betriebsfähigen Zustand verbleibt. Beispielsweise können die Anweisungen ein Lademodul des Fahrzeugs anweisen, eine Fahrzeugbatterie auf ein gespeichertes Energieniveau zu laden, das höher als das voreingestellte gespeicherte Energieniveau ist, um dem Fahrzeug zu ermöglichen, sich einem Fern-Reflash-Ereignis zu unterziehen, und um ausreichend Batterieladung aufrechtzuerhalten, um einen zufriedenstellenden Fahrzeugbetrieb zu erreichen. Beispielsweise können die Anweisungen das Lademodul des Fahrzeugs 102 anweisen, die Batterie auf ein Niveau zu laden, das gleich neunzig Prozent der maximalen Ladekapazität ist, wenn ein Fern-Reflash-Ereignis bevorsteht, während das voreingestellte gespeicherte Energieniveau achtzig Prozent der maximalen Ladekapazität beträgt.
In Schritt 310 führt das Fahrzeug 102 die in Schritt 300 empfangenen Anweisungen aus. Die Ausführung der in Schritt 300 empfangenen Anweisungen kann ein Prozess sein, der von dem Zeitpunkt, zu dem die Anweisungen empfangen werden, bis zu dem Zeitpunkt, zu dem das Fahrzeug dem Fern-Reflash-Ereignis unterzogen wird, dauert. Ferner kann das Ausführen der in Schritt 300 empfangenen Anweisungen Wiederholungen umfassen. Beispielsweise kann das Fahrzeug mehreren Fahrzyklen unterliegen, d. h. Zyklen, während denen eine Batterie an dem Fahrzeug 102 verwendet wird, um den Fahrzeugmotor zu starten, oder um dem Fahrzeug Leistung bereitzustellen, um die Fahrt zu ermöglichen, und während denen nachfolgend die Batterie wieder aufgeladen wird. Daher können Anweisungen zum Laden der Fahrzeugbatterie auf ein Niveau über dem voreingestellten gespeicherten Energieniveau in jedem Fahrzyklus vor dem Fern-Reflash-Ereignis wiederholt werden.
In Schritt 320 wird das Fahrzeug dem Fern-Reflash-Ereignis unterzogen. Das Unterziehen bezüglich des Fern-Reflash-Ereignisses umfasst, dass Kommunikationen von einem TSP empfangen werden und aktualisierte Softwareversionen an einem oder mehreren eingebetteten Computersystemen des Fahrzeugs installiert werden. Zusätzlich zu dem Empfangen von Kommunikationen von dem TSP kann das Fahrzeug 102 auch Kommunikationen von einem OEM-Hersteller oder von einem Softwareentwickler während des Fern-Reflash-Ereignisses empfangen. In Schritt 330 überträgt das Fahrzeug eine Bestätigung, die einen Abschluss des Fern-Reflash-Ereignisses angibt, und überträgt es ferner eine Information, die das gespeicherte Energieniveau der Batterie nach dem Reflash angibt.
Fachleute werden erkennen, dass die Ausführung der verschiedenen maschinenrealisierten Prozesse und Schritte, die hierin beschrieben sind, über die computergestützte Ausführung von von einem Computer ausführbaren Empfehlungen erfolgen kann, die an einem konkreten von einem Computer lesbaren Medium, z. B. RAM, ROM, PROM, flüchtig, nichtflüchtig, oder einem anderen elektronischen Speichermechanismus gespeichert sind. Somit können die durch die Telematikeinheit durchgeführten Operationen beispielsweise gemäß gespeicherten Empfehlungen oder Anwendungen, die an der Telematikeinheit installiert sind, ausgeführt werden, und der Betrieb, der an dem Call Center durchgeführt wird, kann gemäß gespeicherten Empfehlungen oder Anwendungen, die an dem Call Center installiert sind, ausgeführt werden.
Es wird somit in Betracht gezogen, dass sich andere Realisierungen der Erfindung im Detail von den vorstehenden Beispielen unterscheiden können. Somit sollen alle Bezugnahmen auf die Erfindung auf das bestimmte Beispiel der Erfindung verweisen, das an dieser Stelle in der Beschreibung erläutert wird, und sollen dem Schutzumfang der Erfindung allgemeiner keinerlei Beschränkungen auferlegt werden. Jegliche sprachliche Unterscheidung und Schmälerung in Bezug auf bestimmte Merkmale soll auf eine geringere Bevorzugung jener Merkmale hinweisen, sollte jedoch nicht vollständig vom Schutzumfang der Erfindung ausschließen, wenn es nicht anderweitig angegeben ist.
Die Verwendung der Begriffe ”ein” und ”eine” und ”der/die/das” und ähnliche Referenzen im Kontext des Beschreibens der Erfindung (insbesondere im Kontext der folgenden Ansprüche) soll als sowohl Singular als auch Plural abdeckend betrachtet werden, wenn es hierin nicht anders erläutert ist oder durch den Kontext deutlich anderweitig vorgegeben wird. Die Begriffe ”umfassen”, ”aufweisen”, ”einschließen” und ”enthalten” sollen als Begriffe mit offenem Ende betrachtet werden (d. h. mit der Bedeutung ”umfassen, jedoch nicht begrenzt sein auf”), wenn es nicht anderweitig erläutert ist. Angaben von Bereichen von Werten dienen hierin lediglich als eine Abkürzung der einzelnen Bezugnahme auf jeden einzelnen Wert, der in den Bereich fällt, wenn es hierin nicht anderweitig erläutert ist, und jeder einzelne Wert ist in der Beschreibung umfasst, als wäre er hierin einzeln genannt. Alle hierin beschriebenen Verfahren können in jeder geeigneten Reihenfolge ausgeführt werden, wenn es hierin nicht anderweitig erläutert ist oder durch den Kontext anderweitig klar vorgegeben wird. Die Verwendung jeglicher und aller Beispiele oder die Verwendung von beispielhafter Sprache (z. B. ”wie beispielsweise”), die hierin bereitgestellt ist, soll die Erfindung lediglich besser erklären und soll dem Schutzumfang der Erfindung keine Beschränkung auferlegen, wenn es nicht anderweitig beansprucht wird. Keine Begrifflichkeit in der Beschreibung sollte derart ausgelegt werden, dass sie angibt, dass irgendein nicht beanspruchtes Element für die Praxis der Erfindung wesentlich ist.
Demgemäß umfasst diese Erfindung alle durch das jeweilige anwendbare Gesetz zulässigen Abwandlungen und Äquivalente des Gegenstands, der in den hier beigefügten Ansprüchen aufgeführt ist. Ferner ist jede Kombination der oben beschriebenen Elemente in allen möglichen Variationen dieser durch die Erfindung eingeschlossen, wenn es hierin nicht anderweitig erläutert ist oder durch den Kontext anderweitig klar vorgegeben wird.

Claims

Verfahren, das an einem durch einen Telematikdienstanbieter (TSP) betriebenen Server realisiert ist, zum Vorbereiten eines Fahrzeugs, das mit einer Telematikeinheit ausgestattet ist, für ein Fern-Reflash-Ereignis, wobei das Verfahren umfasst, dass: ermittelt wird, dass das Fahrzeug ein Kandidat für ein Fern-Reflash-Ereignis ist; ein Fern-Reflash-Ereignis für das Fahrzeug geplant wird; und eine Benachrichtigung hinsichtlich des geplanten Fern-Reflash-Ereignisses an die Telematikeinheit übertragen wird; wobei die Benachrichtigung hinsichtlich des geplanten Fern-Reflash-Ereignisses eine Erhöhung des gespeicherten Energieniveaus einer Batterie an dem Fahrzeug während eines Fahrzyklus, der vor dem Fern-Reflash-Ereignis stattfindet, auf ein gespeichertes Energieniveau eines bevorstehenden Reflash ermöglicht.
Verfahren nach Anspruch 1, wobei das Verfahren ferner umfasst, dass: an dem Server eine Information empfangen wird, die Kriterien für einen Kandidaten für ein Fern-Reflash-Ereignis spezifiziert; und an dem Server eine Information empfangen wird, die Eigenschaften eingebetteter Software, die an dem Fahrzeug installiert ist, angibt; wobei das Ermitteln, dass das Fahrzeug ein Kandidat für ein Fern-Reflash-Ereignis ist, umfasst, das durch den Server auf der Grundlage der Information, die Kriterien für einen Kandidaten für ein Fern-Reflash-Ereignis spezifiziert, und der Information, die Eigenschaften eingebetteter Software, die an dem Fahrzeug installiert ist, angibt, ermittelt wird, dass das Fahrzeug ein Kandidat für ein Fern-Reflash-Ereignis ist.
Verfahren nach Anspruch 2, wobei die Information, die Kriterien für einen Kandidaten für ein Fern-Reflash-Ereignis spezifiziert, eine Information umfasst, die aus einer von der Gruppe ausgewählt wird, die besteht aus: einer Information, die eine Version einer eingebetteten Software identifiziert, die ausgestaltet ist, um durch eine elektronische Steuereinheit (ECU) ausgeführt zu werden, einer Information, die eine Fahrzeugmarke identifiziert, und einer Information, die ein Fahrzeugmodell identifiziert.
Verfahren nach Anspruch 3, wobei die Information, die die Version der eingebetteten Software identifiziert, die zur Ausführung durch die ECU ausgestaltet ist, durch eine Information begleitet wird, die eine Klassifikation der Version angibt; und wobei die Klassifikation der Version angibt, dass ein OEM-Hersteller die Installation der Version als eines aus der Gruppe betrachtet, die besteht aus: verbindlich, empfohlen oder optional.
Verfahren nach Anspruch 1, wobei das Verfahren ferner umfasst, dass: Eigenschaften des Fern-Reflash-Ereignisses ermittelt werden; und auf der Grundlage der Eigenschaften des Fern-Reflash-Ereignisses das gespeicherte Energieniveau eines bevorstehenden Reflash berechnet wird.
Verfahren nach Anspruch 5, wobei die Eigenschaften des Fern-Reflash-Ereignisses eines aus der Gruppe umfassen, die besteht aus: der Menge an Daten, die während des Fern-Reflash-Ereignisses an die Telematikeinheit zu übermitteln sind, der Größe einer Datei einer eingebetteten Software, die während des Fern-Reflash-Ereignisses an die Telematikeinheit zu übermitteln ist, und dem Umfang an elektrischer Leistung, der von dem Fahrzeug benötigt wird, um das Fern-Reflash-Ereignis auszuführen.
Verfahren nach Anspruch 1, wobei das Planen des Fern-Reflash-Ereignisses umfasst, dass an einer Fern-Reflash-Station dem Fern-Reflash-Ereignis eine WiFi-Bandbreite zugeteilt wird.
Verfahren nach Anspruch 1, wobei die Benachrichtigung hinsichtlich des Fern-Reflash-Ereignisses das Auffordern eines Benutzers, das Fern-Reflash-Ereignis zu bestätigen, und eine Übertragung einer von dem Benutzer empfangenen Bestätigung an den Server ermöglicht.
Verfahren nach Anspruch 1, wobei das Planen des Fern-Reflash-Ereignisses umfasst, dass: an die Telematikeinheit Anweisungen übertragen werden, um einen Benutzer des Fahrzeugs aufzufordern, ein Zeitintervall anzugeben, während dessen das Fern-Reflash-Ereignis verwaltet werden kann; und von der Telematikeinheit eine Information empfangen wird, die ein durch den Benutzer ausgewähltes Zeitintervall angibt.
System zum Vorbereiten eines Fahrzeugs für ein Fern-Reflash-Ereignis, wobei das System umfasst: einen durch einen Telematikdienstanbieter betriebenen Server, wobei der Server ausgestaltet ist, um zu ermitteln, dass das Fahrzeug ein Kandidat für ein Fern-Reflash-Ereignis ist, um das Fern-Reflash-Ereignis zu planen, um eine Benachrichtigung hinsichtlich des Fern-Reflash-Ereignisses an das Fahrzeug zu übertragen, und um Anweisungen für eine Vorbereitung für das Fern-Reflash-Ereignis an das Fahrzeug zu übertragen; und das Fahrzeug, wobei das Fahrzeug mit einer Telematikeinheit ausgestattet ist, die ausgestaltet ist, um eine Benachrichtigung hinsichtlich des Fern-Reflash-Ereignisses zu empfangen, um Anweisungen für eine Vorbereitung für das Fern-Reflash-Ereignis zu empfangen und um eine Bestätigung, dass das Fern-Reflash-Ereignis abgeschlossen wurde, und ein gespeichertes Energieniveau nach dem Reflash an den Server zu übertragen.