-
TECHNISCHES GEBIET
-
Die veranschaulichten Ausführungsformen betreffen im Allgemeinen ein Verfahren und eine Vorrichtung zur Handhabung der Übereinstimmung von mehrzyklischen Fahrzeugsoftwareaktualisierungen.
-
ALLGEMEINER STAND DER TECHNIK
-
Fahrzeughersteller haben angefangen, eine Vielzahl von Computermikroprozessoren in modernen Fahrzeugmodellen einzuschließen. Von umfangreichen Betriebssystemen, die das Infotainment und die Telematik im Fahrzeug steuern, zu kleinen Systemsteuerungen, wie etwa Fenstern oder digitalen Wegmessern, befindet sich ein breites Spektrum von Software auf Speichern, die diesen Mikroprozessoren zugeordnet sind. Da die Fahrzeugrechensysteme verbunden sind und die Systeme sowohl miteinander interagieren als auch sich eine Datenleitung teilen, die Fahrzeugbus genannt wird, gibt es die ständige Sorge, ob die Software auf einem System mit Software auf anderen Modulen funktioniert.
-
Der Fahrzeugbus ist eine geteilte Datenleitung, die der Beeinflussung durch jedes verbundene Modul unterliegt. Da alle Module in einem Controller-Area-Network-(CAN)System, die einen Fahrzeugbus verwenden, Daten mehrfach auf den Bus übertragen, gibt es eine Möglichkeit, dass fehlerhafte oder ungeeignete Software die Datenübertragung durch andere Module über den Bus negativ beeinflussen kann. Gleichzeitig gibt es einen erhöhten Bedarf von Kunden, dass ihre Fahrzeuge die aktualisierteste und am vollständigsten eingebundene Software aufweisen, die verfügbar ist. Diese Kombination führt dazu, dass Druck auf Originalgerätehersteller (original equipment manufacturers - OEMs) entsteht, um sowohl stabile als auch kontinuierlich Softwareaktualisierungen bereitzustellen.
-
Dieses Paradigma wäre möglicherweise überschaubarer, wenn die gesamte Software einen Hauptprozessor und ein einheitliches Betriebssystem verwenden würde, da es aber Dutzende oder sogar Hunderte von elektronischen Steuereinheiten (electronic control units - ECUs) gibt, die alle ihre eigene Software ausführen, und die jeweils mögliche Abhängigkeiten von anderen ECUs aufweisen, kann das Aktualisieren der Software von lediglich einer einzelnen ECU erhebliche Probleme in einem Fahrzeugnetzwerk verursachen, wenn es nicht mit Sorgfalt und Überlegung durchgeführt wird.
-
Aktualisierungen über Luftschnittstellen (over the air - OTA) sind zunehmend als ein Verfahren zum Aktualisieren von Fahrzeugsoftware beliebt geworden. Ein Fahrzeug lädt eine Aktualisierung herunter, wenn eine Internet- oder andere Fernverbindung verfügbar ist, und dann, wenn sich dem Fahrzeug eine angemessene Gelegenheit bietet, verarbeitet das Fahrzeug die Aktualisierung. Ursprünglich wurden die meisten OTA-Aktualisierungen durchgeführt, während sich ein Fahrzeug in einem geparkten Zustand befand, aber neue Modelle stellen bessere Verfahren zum Durchführen von OTA-Aktualisierungen bereit, während ein Fahrzeug gefahren wird. In beiden Fällen kann das Fahrzeug mehrere Zyklen benötigen, um die Aktualisierung abzuschließen, die typischerweise vor dem Verwenden aufgrund von möglichem Einfluss auf eine Fahrsituation vollständig abgeschlossen und verifiziert sein muss.
-
Das ältere Verfahren zum Aktualisieren von Software beinhaltete, dass ein Fahrzeug zu einem Händler gebracht wurde und die neuesten Versionen beliebiger benötigter Aktualisierungen vom Händler installiert wurden. Während dieses Modell noch immer häufig verwendet wird, weisen OTA-Aktualisierungen den naheliegenden Vorteil auf, dass sie ohne jegliche ausdrückliche Maßnahme durch den Kunden im Hintergrund auftreten. Es kann jedoch ein Problem auftreten, wenn der Kunde das Fahrzeug zu einem Händler fährt und Teile oder Softwareaktualisierungen austauschen oder modifizieren lässt. In diesem Fall können sich Kompatibilitätsprobleme ergeben, wenn eine vorherige Aktualisierung noch immer verarbeitet wird, und der Händler versucht, aktualisierte Software auf demselben oder einem zusammenhängenden Modul zu installieren.
-
KURZDARSTELLUNG
-
In einer ersten veranschaulichenden Ausführungsform beinhaltet ein System einen Prozessor, der dazu konfiguriert ist, eines oder mehrere elektronische Fahrzeugsteuereinheits(ECU-)module abzufragen, um aktuelle Softwareversionen, die auf den ECU-Modulen installiert sind, als Reaktion auf das Fortsetzen eines mehrzyklischen Aktualisierungsprozesses zu bestimmen. Der Prozessor ist außerdem dazu konfiguriert, den Aktualisierungsprozess als Reaktion auf die Abfrage zu pausieren, die eine Änderung von mindestens einer Softwareversion in eine andere Version ab dem Zeitpunkt identifiziert, an dem der Aktualisierungsprozess erstmals gestartet wurde. Der Prozessor ist zusätzlich konfiguriert, die Änderung an eine entfernten Quelle zu berichten.
-
In einer zweiten veranschaulichenden Ausführungsform beinhaltet ein System einen Prozessor, welcher dazu konfiguriert ist, eine Vielzahl von Softwareversionsbezeichnungen für elektronische Steuereinheits(ECU-)module von einem Fahrzeug zu empfangen. Der Prozessor ist außerdem dazu konfiguriert, auf Grundlage der Bezeichnungen zu bestimmen, dass eine neue Softwareversion für mindestens ein ECU-Modul verfügbar ist. Der Prozessor ist ferner dazu konfiguriert, die Kompatibilität der neuen Softwareversion mit den empfangen ECU-Modul-Softwareversionen zu bestimmen, die durch die Bezeichnungen identifiziert wurden, und das Fahrzeug anzuweisen, das mindestens eine ECU-Modul, als Reaktion auf das Bestimmen, dass die neue Softwareversion kompatibel ist, auf die neue Softwareversion zu aktualisieren.
-
In einer dritten veranschaulichenden Ausführungsform beinhaltet ein durch einen Computer umgesetztes Verfahren als Reaktion auf eine Bestimmung, dass versucht wird, eine mehrzyklische Softwareaktualisierung fortzusetzen, das Abfragen, um elektronische Steuereinheits(ECU-)modulsoftwareversionen zu erhalten. Das Verfahren beinhaltet außerdem das Senden einer Liste von geänderten ECU-Modulsoftwareversionen an eine entfernte Quelle und das Verhindern des Fortsetzens einer mehrzyklischen Softwareaktualisierung als Reaktion auf eine Bestimmung aus einer Abfrage, dass sich eine ECU-Modulsoftwareversion geändert hat. Das Verfahren beinhaltet ferner als Reaktion auf das Empfangen von Anweisungen von der entfernten Quelle, die Aktualisierung fortzusetzen, das Fortsetzen der mehrzyklischen Aktualisierung, wobei jegliche Änderungen integriert werden, die von der entfernten Quelle empfangen wurden.
-
Figurenliste
-
- 1 veranschaulicht ein repräsentatives Fahrzeugrechensystem;
- 2 veranschaulicht einen Aktualisierungsprozess;
- 3 veranschaulicht einen Verifikationsprozess für das Verarbeiten einer OTA-Aktualisierung;
- 4 veranschaulicht einen zweiten Prozess zur Aktualisierungsverarbeitung und Kompatibilitätsprüfung; und
- 5 veranschaulicht einen Prozess zur Modulkompatibilitätsprüfung.
-
DETAILLIERTE BESCHREIBUNG
-
Detaillierte Ausführungsformen sind in der vorliegenden Schrift nach Bedarf offenbart; dennoch versteht es sich, dass die offenbarten Ausführungsformen lediglich veranschaulichend sind und in verschiedenen und alternativen Formen ausgeführt sein können. Die Figuren sind nicht unbedingt maßstabsgetreu; einige Merkmale können vergrößert oder verkleinert dargestellt sein, um Details bestimmter Komponenten zu zeigen. Dementsprechend sind hierin offenbarte konkrete strukturelle und funktionelle Einzelheiten nicht als einschränkend auszulegen, sondern lediglich als eine repräsentative Grundlage, um einen Fachmann eine vielfältige Ausführung des beanspruchten Gegenstands zu lehren.
-
1 veranschaulicht eine beispielhafte Blockstruktur für ein fahrzeugbasiertes Rechensystem 1 (vehicle based computing system - VCS) für ein Fahrzeug 31. Ein Beispiel für ein derartiges fahrzeugbasiertes Rechensystem 1 ist das SYNC-System, hergestellt durch THE FORD MOTOR COMPANY. Ein mit einem fahrzeugbasierten Rechensystem ausgestattetes Fahrzeug kann eine visuelle Front-End-Schnittstelle 4 enthalten, welche sich im Fahrzeug befindet. Der Benutzer kann zudem in der Lage sein, mit der Schnittstelle zu interagieren, wenn diese zum Beispiel mit einem berührungsempfindlichen Bildschirm bereitgestellt ist. In einer anderen veranschaulichenden Ausführungsform erfolgt die Interaktion durch das Betätigen von Tasten, ein Sprachdialogsystem mit automatischer Spracherkennung und Sprachsynthese. Während SYNC ein Beispiel eines fahrzeugbasierten Rechensystems bereitstellt, kann es hilfreicher sein, das Fahrzeugrechensystem als ein oder mehrere elektronische Steuereinheiten anzusehen, von denen jeder eine verschiedene Aufgabe zugewiesen werden kann. Dies kann zum Beispiel eine Telematiksteuereinheit (telematics control unit - TCU), Verbindungsmodule, Gatewaymodule und verschiedenste andere beauftragte und wiederbeauftragbare Mikroprozessoreinheiten beinhalten, die im Fahrzeug installiert sind.
-
In der in 1 gezeigten veranschaulichenden Ausführungsform 1 steuert ein Prozessor 3 mindestens einen Teil des Betriebs des fahrzeugbasierten Rechensystems. Der in dem Fahrzeug bereitgestellte Prozessor ermöglicht die fahrzeuginterne Verarbeitung von Befehlen und Routinen. Ferner ist der Prozessor sowohl mit nicht dauerhaften 5 als auch dauerhaften Speichern 7 verbunden. In dieser veranschaulichenden Ausführungsform handelt es sich bei dem nicht dauerhaften Speicher um einen Direktzugriffsspeicher (random access memory - RAM) und bei dem dauerhaften Speicher um einen Festplattenspeicher (hard disk drive - HDD) oder Flash-Speicher. Im Allgemeinen kann der dauerhafte (nichtflüchtige) Speicher alle Speicherformen beinhalten, die Daten behalten, wenn ein Computer oder eine andere Vorrichtung abgeschaltet wird. Diese beinhalten unter anderem HDDs, CDs, DVDs, Magnetbänder, Festkörperlaufwerke, tragbare USB-Laufwerke und jede andere geeignete Form von dauerhaftem Speicher.
-
Der Prozessor ist zudem mit einer Reihe unterschiedlicher Eingänge ausgestattet, die dem Benutzer ermöglichen, eine Schnittstelle mit dem Prozessor zu bilden. In dieser veranschaulichenden Ausführungsform sind ein Mikrofon 29, ein Hilfseingang 25 (zur Eingabe 33), ein USB-Eingang 23, ein GPS-Eingang 24, Bildschirm 4, der eine Touchscreen-Anzeige sein kann, und ein BLUETOOTH-Eingang 15 alle bereitgestellt. Eine Eingangswähleinheit 51 ist ebenfalls bereitgestellt, damit ein Benutzer zwischen verschiedenen Eingängen wechseln kann. Eingaben sowohl an das Mikrofon als auch den Hilfsanschluss werden durch einen Wandler 27 von analog zu digital umgewandelt, bevor sie zum Prozessor weitergeleitet werden. Wenngleich nicht gezeigt, können zahlreiche Fahrzeugkomponenten und Hilfskomponenten, die mit dem VCS in Kommunikation stehen, ein Fahrzeugnetzwerk (wie etwa unter anderem ein CAN-Bus) verwenden, um Daten an das und von dem VCS (oder Komponenten davon) weiterzuleiten.
-
Ausgänge des Systems können unter anderem eine visuelle Anzeige 4 und einen Lautsprecher 13 oder eine Stereosystemausgang beinhalten. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt dessen Signal durch einen Digital-Analog-Wandler 9 von dem Prozessor 3. Eine Ausgabe kann zudem an eine entfernte BLUETOOTH-Vorrichtung, wie etwa PND 54, oder eine USB-Vorrichtung, wie etwa die Fahrzeugnavigationsvorrichtung 60, entlang der bidirektionalen Datenströme, die bei 19 bzw. 21 gezeigt sind, erfolgen.
-
In einer veranschaulichenden Ausführungsform verwendet das System 1 den BLUETOOTH-Sendeempfänger 15, um mit der Mobilvorrichtung 53 eines Benutzers zu kommunizieren 17 (z. B. Mobiltelefon, Smartphone, PDA oder jede andere WLAN-fähige Vorrichtung). Die Mobilvorrichtung kann anschließend verwendet werden, um beispielsweise durch Kommunikation 55 mit einem Mobilfunkmast 57 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59. In einigen Ausführungsformen kann es sich bei dem Mast 57 um einen WLAN-Zugangspunkt handeln.
-
Eine beispielhafte Kommunikation zwischen der Mobilvorrichtung und dem BLUETOOTH-Sendeempfänger wird durch das Signal 14 dargestellt.
-
Das Koppeln einer Mobilvorrichtung 53 mit dem BLUETOOTH-Sendeempfänger 15 kann durch eine Taste 52 oder eine ähnliche Eingabe angewiesen werden. Dementsprechend wird die CPU angewiesen, dass der fahrzeuginterne BLUETOOTH-Sendeempfänger mit einem BLUETOOTH-Sendeempfänger in einer Mobilvorrichtung gekoppelt wird.
-
Zwischen der CPU 3 und dem Netzwerk 61 können Daten beispielsweise unter Verwendung eines Datentarifs, Daten über Sprache oder DTMF-Töne kommuniziert werden, welche der Mobilvorrichtung 53 zugeordnet sind. Alternativ kann es wünschenswert sein, ein fahrzeuginternes Modem 63 zu beinhalten, das eine Antenne 18 aufweist, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu kommunizieren 16. Die Mobilvorrichtung 53 kann anschließend verwendet werden, um beispielsweise durch Kommunikation 55 mit einem Mobilfunkmast 57 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59. In einigen Ausführungsformen kann das Modem 63 eine Kommunikation 20 mit dem Mast 57 herstellen, um mit dem Netzwerk 61 zu kommunizieren. Als nicht einschränkendes Beispiel kann es sich beim Modem 63 um ein USB-Mobilfunkmodem und bei der Kommunikation 20 um eine Mobilfunkkommunikation handeln.
-
In einer veranschaulichenden Ausführungsform ist der Prozessor mit einem Betriebssystem bereitgestellt, das eine API zum Kommunizieren mit einer Modemanwendungssoftware beinhaltet. Die Modemanwendungssoftware kann auf ein eingebettetes Modul oder eine Firmware auf dem BLUETOOTH-Sendeempfänger zugreifen, um die drahtlose Kommunikation mit einem entfernten BLUETOOTH-Sendeempfänger (wie etwa dem in einer Mobilvorrichtung) abzuschließen. Bei Bluetooth handelt es sich um eine Teilmenge der IEEE-802-PAN-(Personal Area Network)Protokolle. IEEE-802-LAN-(Local Area Network)Protokolle beinhalten WLAN und weisen eine beträchtliche Kreuzfunktionalität mit IEEE 802 PAN auf. Beide eignen sich für die drahtlose Kommunikation in einem Fahrzeug. Ein weiteres Kommunikationsmittel, welches in diesem Bereich eingesetzt werden kann, sind die optische Freiraumkommunikation (wie beispielsweise IrDA) und nicht standardisierte Verbraucher-IR-Protokolle.
-
In einer anderen Ausführungsform beinhaltet die Mobilvorrichtung 53 ein Modem zur Sprachband- oder Breitbanddatenkommunikation. Bei der Daten-über-Sprache-Ausführungsform kann eine Technik umgesetzt werden, welche als Frequenzmultiplexverfahren bekannt ist, wenn der Besitzer der Mobilvorrichtung bei gleichzeitiger Datenübertragung über die Vorrichtung sprechen kann. Zu anderen Zeitpunkten, wenn der Besitzer der Vorrichtung nicht verwendet, kann für die Datenübertragung die ganze Bandbreite (300 Hz bis 3,4 kHz in einem Beispiel) verwendet werden. Während das Frequenzmultiplexverfahren bei der analogen Mobilfunkkommunikation zwischen dem Fahrzeug und dem Internet geläufig sein kann und nach wie vor verwendet wird, wurde es weitgehend durch Hybriden mit Codemultiplexverfahren (CDMA), Zeitmultiplexverfahren (TDMA), Raummultiplexverfahren (SDMA) für eine digitale Mobilfunkkommunikation ersetzt. Ist das Mobilgerät des Benutzers einem Datentarif zugeordnet, besteht die Möglichkeit, dass der Datentarif eine Breitbandübertragung ermöglicht und das System eine wesentlich größere Bandbreite nutzen könnte (wodurch sich die Datenübertragungsgeschwindigkeit erhöht). In noch einer anderen Ausführungsform wird die Mobilvorrichtung 53 durch eine Mobilfunkkommunikationsvorrichtung (nicht gezeigt) ersetzt, welche in dem Fahrzeug 31 verbaut ist. In noch einer weiteren Ausführungsform kann es sich bei der ND 53 eine Vorrichtung eines drahtlosen lokalen Netzwerks (LAN) handeln, die zum Beispiel (und ohne Beschränkung) über ein 802.11g-Netzwerk (d.h. WLAN) oder ein WiMax-Netzwerk kommunizieren kann.
-
In einer Ausführungsform können ankommende Daten durch die Mobilvorrichtung über Daten-über-Sprache oder einen Datentarif durch den fahrzeuginternen BLUETOOTH-Sendeempfänger und in den internen Prozessor 3 des Fahrzeugs weitergeleitet werden. Im Falle bestimmter temporärer Daten können die Daten zum Beispiel auf dem HDD oder einem anderen Speichermedium 7 gespeichert werden, bis die Daten nicht mehr benötigt werden.
-
Zusätzliche Quellen, welche eine Schnittstelle mit dem Fahrzeug herstellen können, beinhalten ein persönliches Navigationsgerät 54, die zum Beispiel einen USB-Anschluss 56 und/oder eine Antenne 58 aufweisen, ein bordseitiges Navigationsgerät 60 das einen USB- 62 oder einen anderen Anschluss aufweist, ein bordseitiges GPS-Gerät 24 oder ein separates Navigationssystem (nicht gezeigt), die Konnektivität zum Netzwerk 61 aufweisen. Bei USB handelt es sich um eines einer Klasse serieller Netzwerkprotokolle. Die seriellen Protokolle IEEE 1394 (FireWire™ (Apple), i.LINK™ (Sony) und Lynx™ (Texas Instruments)), EIA (Electronics Industry Association), IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Rückgrat der seriellen Einrichtung-zu-Einrichtung-Standards. Die Mehrheit der Protokolle kann entweder für die elektrische oder die optische Kommunikation umgesetzt werden.
-
Ferner könnte die CPU mit einer Vielfalt von anderen Hilfsvorrichtungen 65 in Kommunikation stehen. Diese Vorrichtungen können über eine drahtlose 67 oder drahtgebundene 69 Verbindung verbunden sein. Die Hilfsvorrichtungen 65 können unter anderem persönliche Medienwiedergabegeräte, drahtlose Gesundheitsvorrichtungen, tragbare Computer und dergleichen beinhalten.
-
Zudem oder alternativ dazu könnte die CPU mit einem fahrzeugbasierten drahtlosen Router 73 verbunden sein, zum Beispiel unter Verwendung eines WLAN-Sendeempfängers 71 (IEEE 803.11). Dies könnte der CPU ermöglichen, sich mit Fernnetzwerken in Reichweite des lokalen Routers 73 zu verbinden.
-
Neben der Ausführung beispielhafter Prozesse durch ein sich in einem Fahrzeug befindliches Fahrzeugrechensystem können die beispielhaften Prozesse in bestimmten Ausführungsformen durch ein Rechensystem ausgeführt werden, welches mit einem Fahrzeugrechensystem in Kommunikation steht. Ein derartiges System kann unter anderem eine drahtlose Vorrichtung (z. B. unter anderem ein Mobiltelefon) oder ein entferntes Rechensystem (z. B. unter anderem einen Server) beinhalten, welches über die drahtlose Vorrichtung verbunden ist. Zusammen können derartige Systeme als dem Fahrzeug zugeordnete Rechensysteme (vehicle associated computing systems - VACS) bezeichnet werden. In bestimmten Ausführungsformen können bestimmte Komponenten des VACS bestimmte Teile eines Prozesses ausführen, wobei dies von der konkreten Umsetzung des Systems abhängt. Wenn ein Prozess beispielsweise und nicht einschränkend einen Schritt des Sendens oder Empfangens von Informationen mit einer gekoppelten drahtlosen Vorrichtung aufweist, ist es wahrscheinlich, dass die drahtlose Vorrichtung den Teil des Prozesses nicht durchführt, da die drahtlose Vorrichtung Informationen nicht sich selbst bzw. von sich selbst „senden und empfangen“ würde. Ein Durchschnittsfachmann wird verstehen, wann es unangemessen ist, ein bestimmtes Rechensystem auf eine bestimmte Lösung anzuwenden.
-
Bei jeder hierin erörterten veranschaulichenden Ausführungsform wird ein beispielhaftes nicht einschränkendes Beispiel eines Prozesses gezeigt, der von einem Rechensystem durchführbar ist. Bezüglich jedes Prozesses kann das Rechensystem den Prozess ausführen, um, für den beschränkten Zweck der Ausführung des Prozesses, als ein Spezialprozessor konfiguriert zu werden, um den Prozess durchzuführen. Alle Prozesse müssen nicht in ihrer Gesamtheit durchgeführt werden und werden als Beispiele von Arten von Prozessen verstanden, die durchgeführt werden können, um Elemente der Erfindung zu erreichen. Zusätzliche Schritte können nach Bedarf zu den beispielhaften Prozessen hinzugefügt oder daraus entfernt werden.
-
In Bezug auf die veranschaulichenden Ausführungsformen, die in den Figuren beschrieben sind, die veranschaulichende Prozessabläufe zeigen, ist anzumerken, dass ein Universalprozessor temporär als ein Spezialprozessor zum Zwecke des Ausführens einiger oder aller der beispielhaften Verfahren, welche durch diese Figuren gezeigt werden, aktiviert werden kann. Wenn Code ausgeführt wird, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor temporär erneut als ein Spezialprozessor eingesetzt werden, und zwar solange, bis das Verfahren abgeschlossen ist. In einem anderen Beispiel kann, bis zu einem angemessenen Grad, Firmware, die in Übereinstimmung mit einem vorkonfigurierten Prozessor agiert, veranlassen, dass der Prozessor als ein Spezialprozessor agiert, der zum Zwecke des Durchführens des Verfahrens oder einer angemessenen Variation davon bereitgestellt ist.
-
Während die gezeigten veranschaulichenden Beispiele im Hinblick auf eine Mehrfahrtzyklenaktualisierung erörtert werden, kann dasselbe Konzept für jede mehrzyklische (z. B. mehrfache außerzyklische usw.) Aktualisierung auftreten, bei der eine vorherige Aktualisierung noch immer lediglich teilweise zu einem Zeitpunkt verarbeitet ist, wenn eine weitere Quelle (z. B. Benutzer, Händler usw.) eine Aktualisierung des laufenden Moduls oder eines zusammenhängenden Moduls versucht.
-
Die veranschaulichenden Ausführungsformen schlagen einen Prozess vor, der es der Telematiksteuereinheit (TCU), die in diesen Beispielen die OTA-Aktualisierungen handhabt, ermöglicht, bei einem Ereignis „Zündung an“ alle Module abzufragen, die aktualisiert werden. Andere Auslösezeitpunkte (außer „Zündung an“) wären angemessen, wenn andere Aktualisierungsparadigmen verwendet würden (z. B. unter Verwendung des Ereignisses „Zündung aus“ zur Abfrageauslösung, wenn die Zyklen „Zündung aus“ für Aktualisierungen verwendet würden). Wenn sich Parameter auf den abgefragten Modulen geändert haben, wenn zum Beispiel ein weiterer Prozess, wie etwa ein Händler, ein Modul aktualisiert hat, kann die TCU alle Aktualisierungen unterbrechen und die Änderungen an die Cloud berichten. Die Cloud kann dann verifizieren, dass es keine Konflikte beim Fortsetzen der Aktualisierung geben wird. Wenn Konflikte bestehen, kann das TCU die Aktualisierung einfach einstellen und/oder ein neues Aktualisierungsmodul empfangen, das mit der aktuellen Konfiguration kompatibel ist, die durch die Abfrage bestimmt wurde.
-
Es ist erwähnenswert, dass die TCU-Abfrage Module einschließen kann, die mit Modulen zusammenhängen, die aktualisiert werden, selbst wenn diese zusammenhängenden Module im Augenblick nicht aktualisiert werden, da die Module, die aktualisiert werden, eine gewisse Abhängigkeit von den zusammenhängenden Modulen oder eine gewisse notwendige Kompatibilität mit diesen aufweisen.
-
Die TCU ist außerdem in einigen Fällen in der Lage zu bestimmen, wie fortgefahren werden soll, ohne die Cloud zu kontaktieren. Zum Beispiel könnte die TCU mit einer aktualisierbaren Kompatibilitätsliste bereitgestellt sein, so dass, zum Beispiel, wenn ein Händler ein Modul aktualisiert hat, die TCU-Liste mit den Kompatibilitätsversionen für andere Module aktualisiert würde, die möglicherweise vom Modul abhängen, das vom Händler aktualisiert wurde. In anderen Fällen kann die TCU beschließen, wenn Änderungen erfasst werden, die keine Module betreffen, die mit laufenden Aktualisierungen zusammenhängen, fortzufahren, da die Kompatibilität nicht betroffen sein sollte.
-
2 veranschaulicht einen Aktualisierungsprozess. In diesem veranschaulichenden Beispiel empfängt die TCU einen OTA-Aktualisierungsbefehl von der Cloud 201, der anzeigt, dass die TCU eine OTA-Aktualisierung verarbeiten sollte. Als Reaktion auf den Befehl beginnt die TCU die Aktualisierung 203 während eines Zyklus „Zündung an“ (das für dieses Beispiel verwendete Modell).
-
Wenn die Aktualisierung während des Zyklus „Zündung an“ abgeschlossen wird, kann der Prozess einfach abgebrochen werden, da Kompatibilitätsprobleme, die während des Zyklus „Zündung an“ auftraten, unwahrscheinlich sind (da die Kompatibilität vermutlich vom Server in der Cloud verifiziert wurde, bevor die Aktualisierung gesendet wurde). Wenn der Prozess nicht abgeschlossen wird 205, wird der Prozess letztendlich einen Zustand „Zündung aus“ 207 erfassen, der das Verarbeiten der Aktualisierung beendet. Solange der Prozess keinen Zustand „Zündung aus“ erfasst, fährt die Aktualisierung fort 215.
-
Wenn der Zustand „Zündung aus“ erfasst wird, speichern 209 die aktualisierenden ECU und die TCU jegliche Statusdaten, die benötigt werden, um die Aktualisierung beim nächsten Zyklus „Zündung an“ 211 fortzufahren. Sobald der Zustand „Zündung an“ erfasst wird 211, ruft der Prozess jegliche gespeicherten Zustandsdaten 213 ab und die Aktualisierung fährt fort 215. Dieser veranschaulichende Prozess zeigt das Aktualisierungsmodell, wie es aktuell besteht, ohne die Verifizierung von Moduländerungen während des Zustands „Zündung aus“. Dieses Aktualisierungsmodell unterliegt den möglichen hierin beschriebenen Problemen, nämlich, dass ein Modul, von dem ein Aktualisierungsmodul abhängt, während des Zustands „Zündung aus“ geändert wird, und das Aktualisierungsmodul die Aktualisierung abschließt, und der TCU dann zwei möglicherweise inkompatible Module geboten werden, obwohl beide gerade aktualisiert wurden.
-
3 veranschaulicht einen Verifikationsprozess für das Verarbeiten einer OTA Aktualisierung. In diesem veranschaulichenden Beispiel empfängt der Prozess ein OTA-Aktualisierungsereignis von einer entfernten Quelle 301. Wieder verzögert der Prozess die OTA-Aktualisierung, bis der Prozess einen Zustand „Zündung an“ 303 erfasst.
-
Sobald der Prozess einen Zustand „Zündung an“ 303 erfasst, fragt der Prozess ein Aktualisierungsmodul 305 an (ein Modul, das aktualisiert wird), um zu sehen, ob es Änderungen am Aktualisierungsmodul 307 gibt, die während des Zustand „Zündung aus“ erfolgten. Zum Beispiel könnte ein Händler die auf dem Aktualisierungsmodul installierte Software vollständig überschrieben haben, wodurch die laufende Aktualisierung unnötig würde. Aber selbst in diesem Fall kann der Händler das Modul mit einer falschen Version (bezüglich der Kompatibilität) oder einer älteren Softwareversion als der aktuell bestehenden aktualisiert haben. Dementsprechend unterbricht der Prozess die laufende Aktualisierung 309.
-
Der Prozess berichtet dann die erfasste Änderung zurück an die Cloud 311 und empfängt eine Antwort 313 von der Cloud, die den Prozess anweist, wie er fortfahren soll. Das Unterbrechen und Berichten wird in diesem Beispiel auf aufeinanderfolgende Weise gezeigt, es ist aber vertretbar, dass alle Daten gesammelt werden können/werden, bevor das Berichten und das Antworten erfolgt.
-
Zusätzlich zum Bestimmen, ob sich die Parameter des Aktualisierungsmoduls geändert haben, kann der Prozess außerdem bestimmen, ob es andere Module gibt, die auf Softwareänderungen 319 überprüft werden müssen. Dies kann eine Bestimmung im Hinblick auf alle Module am Fahrzeug sein oder lediglich im Hinblick auf Module, die eine bekannte bestehende Beziehung zu einem Aktualisierungsmodul aufweisen. Wenn Module zum Abfragen verbleiben, wird der Prozess zu einem nächsten Modul 321 übergehen und den Abfrageprozess für jedes relevante Modul wiederholen.
-
Sobald keine Module zum Aktualisieren verbleiben und der Prozess eine Anweisung zum Fortfahren 315 von der Cloud empfangen hat, insoweit, dass der Prozess jegliche geänderten Module erfasst und berichtet hat, kann der Prozess mit der Aktualisierung für den aktuellen Zyklus „Zündung an“ 323 fortfahren.
-
Wenn die Cloud den Prozess angewiesen hat, nicht fortzufahren 315, kann der Prozess das Aktualisieren der identifizierten Module 317 einstellen. Wenn der Prozess keine Änderungen an relevanten Modulen erfasst hat, kann der Prozess ohne ausdrückliche Anweisung von der Cloud bestimmen, dass das Fortfahren zulässig ist.
-
Das folgende veranschaulichende Szenario zeigt ein Beispiel von zwei Modulen, ECU1 und ECU2, die beide unterschiedliche mögliche Softwarekonfigurationen aufweisen. In diesem Beispiel ist ECU1 über OTA aktualisierbar und ECU2 ist nicht über OTA aktualisierbar. Das bedeutet, dass eine direkte Schnittstelle notwendig ist, um ECU2 durch einen Besitzer, einen Händler usw. zu aktualisieren. In diesem Beispiel führt ECU1 die Softwareversion C aus und ECU2 führt die Softwareversion 3 aus und ein Kunde würde es bevorzugen, dass die neuesten und kompatiblen Versionen auf jedem Modul installiert würden. ECU1 und ECU2 weisen derartig gewisse Kreuzkompatibilitätsanforderungen auf, dass die ECU2-Versionen 1-3 mit den ECU1-Versionen A-F kompatibel sind, aber die ECU2-Versionen 4-9 lediglich mit den ECU1-Versionen A-D und G-H kompatibel sind (E und F ausnehmend und G und H hinzufügend). Das bedeutet, dass die ECU2-Version 4 und die ECU1-Version E ein Inkompatibilitätsproblem darstellen würden.
-
Dieses Beispiel wird im Hinblick auf 4 beschrieben, die einen zweiten Prozess zur Aktualisierungsverarbeitung und Kompatibilitätsprüfung veranschaulicht. In diesem Beispiel erhält die TCU zuerst die aktuelle Konfiguration 401 der Module ECU1 und ECU2 (C bzw. 3). Die TCU sendet eine Liste der Softwareversionen der unterschiedlichen Module an die Cloud 403 und empfängt als Reaktion darauf OTA-Aktualisierungsanweisungen 405. In diesem Beispiel sendet die Cloud Anweisungen, um ECU1 auf die neueste Version zu aktualisieren, die ebenfalls mit der ECU2-Version 3 kompatibel ist, da lediglich ECU1 über OTA aktualisierbar ist. In diesem Fall besagen diese Anweisungen, dass die TCU ECU1 auf Version F aktualisieren soll.
-
In diesem Beispiel wird das Fahrzeug ebenfalls betrieben, so dass die Aktualisierung unmittelbar beginnen kann, sofern die Zündung nicht ausgeschaltet wurde 407. Die Aktualisierung wird verarbeitet 415 und sobald ECU1 das Verarbeiten abgeschlossen hat, wird ECU1 auf die neu installierte Version F wechseln. Wenn das System bereit ist, auf die neue Software 417 zu wechseln, kann eine letzte Kompatibilitätsprüfung vorgenommen werden 419. Wenn das Wechseln nicht bereit ist 417, dann wird die Aktualisierung noch immer verarbeitet und wird damit fortfahren, bis der Prozess einen Zustand „Zündung aus“ erfasst oder die Aktualisierung abgeschlossen wird.
-
Die letzte Kompatibilitätsprüfung stellt sicher, dass die derzeitig installierte Software noch immer mit allen anderen Modulen gemäß der definierten Kompatibilität kompatibel ist. Wenn die installierte Software noch immer kompatibel ist 421, wird der Prozess auf ECU1 auf die neue Version der Software wechseln und diese Software (Version F) für ECU1 verwenden. Wenn es eine Änderung in letzter Minute gab, wenn zum Beispiel ECU2 auf Version 9 geschaltet wurde, und Version F nicht länger kompatibel ist, dann kann der Prozess ein neues Versionsverzeichnis an die Cloud schicken, so dass die Cloud bestimmen kann, welche Software tatsächlich auf ECU1 installiert werden soll (in diesem Fall Version H, was die neueste Software ist und auch mit der jetzigen Version 4 auf ECU2 kompatibel ist).
-
Während des Aktualisierungsprozesses wird der Prozess die Aktualisierung unterbrechen, bis der Prozess einen Zustand „Zündung an“ 409 erfasst, wenn ein „Zündung aus“ auftritt. Sobald ein Zustand „Zündung an“ während eines unterbrochenen Aktualisierungsprozesses erfasst wird, prüft der Prozess das vorliegende Modul (das in diesem Beispiel noch immer aktualisiert wird) und alle zugeordneten Module, wie etwa ECU2.
-
In diesem Beispiel fuhr der Kunde zu einem Händler und „Zündung aus“ trat beim Händler auf. Beim Versuch, den Bedarf des Kunden zu erfüllen, installierte der Händler ECU2-Version 9, was die neueste ECU2-Version ist und ebenfalls mit Version C auf ECU1 kompatibel ist, da ECU1 noch immer Version C ausführte (da es die Aktualisierung auf Version D noch nicht abgeschlossen hatte). Also wurden aus Sicht des Händlers alle Kompatibilitätsprüfungen erfüllt und der Kunde weist nun Version C auf ECU1 und Version 9 auf ECU2 auf.
-
Beim nächsten Zustand „Zündung an“ 409 erfasst der Prozess, dass das Modul ECU2 auf Version 9 geändert wurde 413. Da dies ein Kompatibilitätsproblem darstellen könnte (und es in diesem Fall auch so ist), unterbricht der Prozess die Aktualisierung und berichtet die Änderung zurück an die Cloud 403. Die Cloud kann dann bestimmen, dass die Aktualisierung auf Version D auf ECU1 eingestellt wird, da D und 9 inkompatibel sind, und kann stattdessen eine Aktualisierung auf Version H anweisen, was sowohl die neueste Version für ECU1 ist als auch mit Version 9 kompatibel ist.
-
Die Cloud hätte in diesem Beispiel das Aktualisieren auf Version H nicht unmittelbar zu Beginn anweisen können, da H und Version 3 (auf ECU2) inkompatibel sind. Das Beste, was die Cloud hätte unternehmen können, wäre das Anweisen einer Aktualisierung auf Version F. Das Aktualisieren auf Version F hätte allerdings zum selben Problem geführt, sobald ECU2 auf eine der Versionen 4-9 aktualisiert worden wäre, da keine dieser Versionen mit der Version F kompatibel ist.
-
Dieses Beispiel verdeutlicht die Komplexität des erfolgreichen Aktualisierens eines Systems mit einer Reihe von unabhängigen und voneinander abhängenden ECUs. Da bestimmte ECUs aktualisiert werden können, während eine andere ECU-Aktualisierung unterbrochen ist, sind Probleme vorprogrammiert. Durch die dargestellten veranschaulichenden Beispiele helfen Kompatibilitätsprüfungen sicherzustellen, dass die Systemintegrität aufrechterhalten bleibt, wenn Aktualisierungen von sowohl OTA als auch anderen Quellen laufen.
-
5 veranschaulicht einen Prozess zur Modulkompatibilitätsprüfung, der zum Beispiel in der Cloud oder an jedem Ort auftreten kann, an dem das Aktualisierungsverzeichnis zusammengeführt wird. In diesem veranschaulichenden Beispiel empfängt der Prozess ECU-Software-/Firmwareversionen für alle relevanten Module (unter anderem alle Module beinhaltend, die sowohl über OTA als auch nicht über OTA aktualisierbar sind). Das Empfangen der Modulversionsdaten für nicht über OTA aktualisierbare Module kann noch immer wichtig sein, da die Kompatibilität neuer OTA-Aktualisierungsversionen zum Teil von nicht über OTA aktualisierbaren Modulen abhängen kann.
-
In diesem Beispiel bestimmt der Prozess für jede empfangene über OTA aktualisierbare ECU-Modulversion, ob eine aktualisierte Version der Software für dieses konkrete Modul verfügbar ist 503. Wenn es eine aktualisierte Version gibt 503, dann führt der Prozess eine Kompatibilitätsprüfung durch.
-
Der Prozess kann eine neueste Version auswählen (und rückwärts arbeiten bis die Kompatibilität gefunden wurde) oder er kann eine neueste Version auswählen, von der bekannt ist, dass sie mit mindestens einem anderen Modul kompatibel ist 507. In der anfänglichen Auswahl kann eine schnelle Datenbanksortierung unter Verwendung der empfangenen Modulversionen die Kompatibilität 505 der anfänglichen Auswahl sicherstellen.
-
Der Prozess führt ein Verzeichnis, das Anweisungen und/oder Daten zum Verarbeiten der Aktualisierung beinhaltet, zusammen und sendet 511 es an die TCU. Die TCU verarbeitet die Aktualisierung über möglicherweise mehrere Zündungszyklen und berichtet zurück an die Cloud, wenn Änderungen der anfänglichen ECU-Konfiguration durch die TCU erfasst werden.
-
Wenn die TCU die Aktualisierung nicht als abgeschlossen berichtet 513 und stattdessen einen neuen Satz von ECU-Versionen gesendet hat 517, was eine Änderung einer oder mehrerer ECU-Softwareversionen anzeigt, prüft der Prozess nochmals, um zu sehen, ob die aktuell angewiesene (und unterbrochene) Aktualisierung mit den neuen Versionen kompatibel ist 505.
-
Wenn die Aktualisierung kompatibel ist, kann der Prozess das anfängliche Verzeichnis erneut senden oder einfach eine Anweisung senden, dass die TCU mit dem Aktualisierungsverarbeiten fortfahren soll. Wenn die vorher angewiesene Aktualisierung nun inkompatibel ist (wie es in dem vorhergehenden Beispiel der Fall war), kann der Prozess eine andere kompatible Version auswählen, die mit der bestehenden Konfiguration kompatibel ist 507.
-
Wenn es keine neue Version gibt, das heißt, wenn die neueste kompatible Version bereits auf der ECU installiert ist, die aktualisiert wird, kann der Prozess abbrechen (und möglicherweise eine Anweisung zum Einstellen der Aktualisierung senden). Wenn es eine neuere (neuer als die aktuell installierte) Version gibt 509, die auch kompatibel ist, kann der Prozess ein neues Verzeichnis senden, das die TCU anweist, die Aktualisierung auf die neueste kompatible Version zu ändern, die durch den Prozess identifiziert wurde.
-
Die veranschaulichenden Ausführungsformen stellen eine Kompatibilitätsprüfung dar, die zum mehrfachen Ändern von Aktualisierungsanweisungen für ein einzelnes Modul führen kann, bevor eine Aktualisierung für das Modul abgeschlossen ist. Trotzdem helfen die Kompatibilitätsprüfungen dabei, Kundenprobleme zu vermeiden, und stellen die Systemintegrität sicher, während gleichzeitig dem Kunden ermöglicht wird, ständig Nutzen aus den neuesten kompatiblen verfügbaren Softwareversionen für mindestens die über OTA aktualisierbaren Module am Fahrzeug zu ziehen.
-
Während vorstehend beispielhafte Ausführungsformen beschrieben sind, sollen diese Ausführungsformen nicht alle möglichen Formen der Erfindung beschreiben. Die in der Beschreibung verwendeten Ausdrücke sind vielmehr beschreibende Ausdrücke als einschränkende Ausdrücke, und es versteht sich, dass unterschiedliche Änderungen vorgenommen werden können, ohne vom Geist und Schutzumfang der Erfindung abzuweichen. Zusätzlich können die Merkmale verschiedener implementierender Ausführungsformen auf logische Weise kombiniert werden, um situationsgerechte Variationen von hier beschriebenen Ausführungsformen zu bilden.
