-
Die vorliegende Erfindung betrifft ein Verfahren zum robusten Aktualisieren von Firmware eines Fahrzeuges über eine Luftschnittstelle. Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium.
-
Stand der Technik
-
In der Funktechnik wird die Übertragung von Daten mittels elektromagnetischer Wellen, also scheinbar durch das Medium Luft (over the air, OTA), mitunter als Luftschnittstelle bezeichnet. Eine solche Luftschnittstelle ist insbesondere dadurch gekennzeichnet, dass kein festkörperliches Übertragungsmedium wie Kupfer- oder Glasfaserkabel verwendet wird, was für die Zwecke der nachfolgenden Ausführungen die Übertragung im Vakuum nicht ausschließt. Telekommunikationstechnische Ansätze, die sich einer solchen Übertragung bedienen, sind etwa als Over-the-Air-Programmierung (OTA), Over-the-Air Service Provisioning (OTASP), Over-the-Air Provisioning (OTAP) oder Over-the-Air Parameter Administration (OTAPA) bekannt.
-
Von besonderer Bedeutung sind die genannten Technologien für die Aktualisierung sogenannter Firmware, also solcher Software, die in elektronische Geräte eingebettet ist. Auf Firmware angepasste Abwandlungen der oben genannten OTA-Technologien werden in der Telekommunikation unter dem Oberbegriff der Firmware-Over-the-Air-Programmierung (FOTA) zusammengefasst.
-
DE 10105454 A1 schlägt ein Verfahren zur automatischen Ergänzung von Software über eine Luftschnittstelle vor, das dazu dient, Software, die auf einem System läuft, durch neue Softwaremodule zu ergänzen, wobei diese Softwaremodule zunächst getestet werden und von diesen Softwaremodulen dann Applikationsmodule abgeleitet werden.
-
Offenbarung der Erfindung
-
Die Erfindung stellt ein Verfahren zum robusten Aktualisieren von Firmware eines Fahrzeuges über eine Luftschnittstelle, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium gemäß den unabhängigen Ansprüchen bereit.
-
Ein Vorzug dieser Lösung liegt in der Erhöhung der Robustheit eines Over-The-Air-Updates von Software (SW) und insbesondere Firmware (FW), sodass Probleme im praktischen Einsatz für den Erstausrüster (original equipment manufacturer, OEM) und Endkunden vermieden werden. Hierbei ist es wichtig zu verstehen, dass ein OTA-Szenario ohne Unterstützung einer Werkstatt mit hoher Robustheit sicher funktionieren sollte. Das i. d. R. an sich intakte Fahrzeug erhält hierbei ein FW- oder anderweitiges SW-Update, um den Funktionsumfang zu erweitern oder Fehler zu beseitigen und darf somit nach einem OTA-Update nicht defekt – d. h. fahruntüchtig – werden. Dies unterscheidet das OTA-Szenario grundlegend vom konventionellen Werkstatt-Szenario. Robuste Lösungen gemäß einer Ausführungsform der Erfindung werden entsprechend hohen Kundenerwartungen gerecht.
-
Robustheit beschreibt gemäß IEEE, ISO/IEC den Grad eines Systems oder einer Komponente, Funktionalitäten korrekt zu gewährleisten, selbst wenn das System und die Systemumgebung vor allem an den Systemgrenzen auslastenden Einflüssen und Bedingungen unterliegt oder unbekannte Inputwerte auftreten.
-
Die hier vorgeschlagene Lösung betrifft nicht lediglich einzelne SW- oder Hardwarekomponenten, sondern setzt sich aus einer Reihe von Funktionen und vor allem deren sinnvollem Zusammenspiel und den betreffenden Architekturelementen zusammen.
-
Die nachfolgenden Ausführungen beschreiben, wie analog zum klassischen SW- und insbesondere FW-Update in einer Werkstatt bspw. Aktivitäten einer Werkstattperson, die bei der Durchführung des Updates in der Werkstatt die Robustheit gewährleisten, automatisiert im Fahrzeug erfolgen. Optionen zur weiteren Erhöhung der Robustheit sind ebenfalls ausgezeichnet.
-
Ein Aspekt der Erfindung betrifft den robusten FOTA-Update für die Teilaktivitäten in der folgender Gesamtkette: Interaktion zwischen Fahrzeug-Client und Backend, Download ins Fahrzeug, Speicherung und Verwaltung, Verteilung und Update sowie Umgang mit Unfällen (disaster handling). Die Integration von Fahrzeug-Update-Daten, Backend-Aufbereitung sowie Rollback und Wiederherstellung (recovery) als weitere Prozessschritte sind dem Fachmann hinlänglich bekannt und nicht Gegenstand der nachfolgenden Ausführungen.
-
Ein weiterer Aspekt der Erfindung ist ein technisches System, welches aus einem oder mehreren Backend-Systemen und einem Fahrzeug-Teilsystem besteht.
-
Der Kern des Systems besteht daher aus einem Fahrzeug-Teilsystem für das OTA-SW- und insbesondere FW-Update in einem einzelnen Fahrzeug, einem Backend-Teilsystem für das Update einer Flotte oder Gruppe von Fahrzeugen und der Interaktion dieser Komponenten.
-
Kurze Beschreibung der Zeichnungen
-
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
-
1 die einer Ausführungsform der Erfindung zugrunde liegende Architektur.
-
2 die Zuordnung der Funktionskomponenten in autonome Bereiche mit Interaktionsabhängigkeiten und Verantwortlichkeiten.
-
3 exemplarische Bedingungen, die bei Berücksichtigung die Robustheit erhöhen.
-
4 eine erfindungsgemäße Koordinierungsschicht und den transparenten Umgang mit den Installationsausführungsfunktionen.
-
Ausführungsformen der Erfindung
-
Das System setzt auf der in 1 illustrierten technischen Architektur auf, die nicht nur Modularität, Erweiterbarkeit und Anpassbarkeit erhöht, sondern auch die Robustheit. Der Daten-Download ist hierzu in einer Komponente separiert, welche sowohl als Download-Server 21 im Backend 20 als auch als Download-Clients 11 im Fahrzeug 10 implementiert wird. Das Device-Management ist in einer Komponente separiert, welche sowohl als Gerätemanagement-Server 26 im Backend 20 als auch als Gerätemanagement-Client 16 im Fahrzeug 10 implementiert wird. Ein fahrzeugseitiger Proxy wird genutzt, um verteilte Implementierungen des Gerätemanagements – zum Beispiel in mehreren Domänen – zu einer einzigen Implementierung zu bündeln.
-
Das Software-Update und -Management ist in einer Komponente separiert, welche sowohl als SCOS-Server 22 und FCOS-Server 23 im Backend 20 als auch als Anwendungssoftware-Update-Client 12 und Firmware-Update-Client 13 im Fahrzeug 10 implementiert wird. SCOMO/FUMO bezeichnet hier die Funktionalität entsprechend OMA-DM als einer beispielhaften Umsetzung.
-
Ein Fahrzeugmanagement 25 dient der Konkretisierung eines „Devices“ zu dem Fahrzeug 10 inklusive seiner relevanten Topologie, also Steuergeräte (electronic control units, ECUs) und Sub-Systeme.
-
Das fachliche Datenhandling seitens des Backends 20 ist in einem Fahrzeug-Content-Management 28 separiert, welche die unterschiedlichen Versionen und Varianten von Datenständen an das Fahrzeug 10 bindet. Separiert ist auch die Update-Logik einschließlich der Kampagnensteuerung, welche sowohl als Fahrzeugupdate-Server 24 im Backend 20 als auch als Fahrzeugupdate-Client 14 im Fahrzeug 10 implementiert wird.
-
Als Content-Management 18 ist das Daten-Management im Fahrzeug 10 separiert. Entsprechendes gilt für die für die ECU-Aktualisierung im Fahrzeug 10 separierte Firmware-Update-Komponente, welche in mehreren Varianten und Instanzen – etwa jener eines Anwendungssoftware-Update-Clients 12 oder eines Firmware-Update-Clients 13 – vorliegen kann und in der Lage ist, die unterschiedlichen Systeme und Technologien zu aktualisieren.
-
Die Inhalte und Funktionen der aufgeführten Komponenten seien nunmehr im Einzelnen erläutert.
-
Das Fahrzeugmanagement 25 ist für die Kenntnis der Fahrzeuge 10 – im Sinne eines Satzes oder einer Gruppe von Fahrzeugen 10 –, des Fahrzeuges 10 selbst und seiner Fahrzeugtopologie für alle Zwecke verantwortlich und in der Lage, ein Gerät auf das vom Gerätemanagement 15, 16, 26 gelieferte Fahrzeug 10 abzubilden. Das Gerätemanagement 15, 16, 26 identifiziert und kommuniziert hierzu mit einem Gerät, nicht notwendigerweise einem Fahrzeug 10 oder einem bekannten Fahrzeug 10. Mehrere Geräte können dabei zu einem Fahrzeug 10 zusammengefasst sein. Gleichwohl kann das Gerätemanagement 15, 16, 26 einen anderen Gerätetyp, beispielsweise einen Rasenmäher, identifizieren. Das Gerätemanagement 15, 16, 26 identifiziert somit den Gerätetyp, um die Weiterleitung an dessen Verwaltungsfunktion zu erlauben. Im vorliegenden Beispiel handelt es sich dabei um das Fahrzeugmanagement 25.
-
Der Gerätemanagement-Server 26 ist in der Lage, alle Verwaltungsaktionen mit dem zugehörigen Gerät durchzuführen. Hierzu ist ein Protokoll vonnöten, um solcherlei Verwaltungsobjekte zum und vom Gerät zu befördern.
-
Das Gerätemanagement 15, 16, 26 ist in der Lage, mehrere Geräte unterschiedlichen Typs zu handhaben. Bekannte Geräte werden mithilfe des Datenmanagements 27 identifiziert und typisiert, um ein „bekanntes Gerät“ zu werden. Ein bekanntes Gerät wird der zugehörigen Verwaltungsfunktion – vorliegend dem Fahrzeugmanagement 25 – zugeleitet. Für die Zwecke der folgenden Ausführungen sei angenommen, dass alle Geräte als „Straßenfahrzeuge“ typisiert und durch das Fahrzeugmanagement 25 verarbeitet werden. Nichtsdestotrotz ist das Gerätemanagement vorzugsweise in der Lage, auch andere Typen und Anwendungsfälle zu unterstützen.
-
Der Gerätemanagement-Client 16 ermöglicht es, Softwarekomponentenmanagement in der zugehörigen Laufzeitumgebung von einem Gerätemanagement-Server 26 aus einzuleiten. Der Gerätemanagement-Treiber unterstützt Geräteerkennung und Parameterkonfiguration durch den Gerätemanagement-Client 16. Der Gerätemanagement-Client 16 wiederum interagiert mit einem oder mehreren Gerätemanagement-Agenten 15 in der Umgebung, die über einen optionalen Gerätemanagement-Proxy für die Durchführung der Verwaltungsaktivitäten mittels eines gelieferten Softwarekomponentenmanagementobjektes zuständig sind. Der Gerätemanagement-Client 16 setzt den allgemeinen Warnmechanismus ein, um die den Status der Verwaltungsaktivität umfassende endgültige Benachrichtigung mitzuteilen.
-
Wenn mehrere Instanzen des Gerätemanagement-Clients 16 existieren, dann wird diese Aktivität als bestmögliche Alternative durch eine einzige Instanz des Gerätemanagement-Clients 16 und zusätzlichen Gerätemanagement-Agents 15 ausgeführt. Um bei einem einzigen Gerät pro Fahrzeug 10 gleichwohl mehrere Gerätemanagement-Clients 16 unterstützen zu können, wird ein Gerätemanagement-Proxy verwendet. Auf jedem IP-fähigen System 46 läuft somit eine Instanz des Gerätemanagement-Agenten 15 und nutzt den zentralen Proxy des Gerätemanagement-Client 16.
-
Die Gerätemanagement-Proxy-Komponente ermöglicht es, mehrere Instanzen des Gerätemanagement-Clients 16 zu vermeiden. Hierzu leitet und aggregiert jeder Gerätemanagement-Agent das Gerätemanagement-Verwaltungsobjekt an den Gerätemanagement-Client 16. Die Gerätemanagement-Agent können in unterschiedlichen Laufzeitumgebungen laufen. Der Proxy ist zuständig und stellt die eindeutige Zuordnung zwischen Fahrzeug 10 und Gerät sicher.
-
Das Fahrzeug-Content-Management 28 ist seitens des Backends 20 dafür zuständig, den Inhalt abzubilden, für die Übertragung gegebenenfalls zu komprimieren und für die Verwendung bzgl. Software Updates zu paketieren. Es empfängt die Daten und Inhalt vom Datenmanagement 27, dieses speichert die Daten und Inhalt auf einheitliche Art. So wird die OEM-Varianz hinsichtlich Daten und Inhalt innerhalb des Fahrzeuges 10 vom Datenmanagement 27 vollständig abgedeckt. Dies bringt auch die eindeutige semantische und syntaktische Beziehung zwischen der Ausgabe des Datenmanagements 27 und dem zugehörigen Content-Management 18 seitens des Fahrzeuges 10 mit sich.
-
Der SCOS-Server 22 ist für das Aufbauen und Übertragen der Management-Objekte für Applikationssoftware Updates verantwortlich. Im Falle einer Verwendung von OMA-DM kann dies durch Nutzung des SCOMO-Protokolls und Management-Objekte realisiert werden. Der SW-Update-Client 12 ist für die Ausführung von SCOS-Anweisungen zuständig. Er verbraucht die an das Gerät gelieferte Softwarekomponente und garantiert, dass ein Erfolgs- oder Fehlerergebnis übermittelnde Warnungen zurück an den SCOS-Server 22 geleitet werden. Um bei einem einzigen Gerät pro Fahrzeug 10 gleichwohl mehrere SW-Update-Clients unterstützen zu können, werden mehrere Varianten und Instanzen verwendet. Alle SW-Update-Client-Instanzen 12 werden hierbei vom Fahrzeugupdate-Server 14 orchestriert. So kann auf jedem IP-fähigen System eine Instanz des SW-Update-Clients 12 laufen.
-
Der Download-Server 21 ist für die Bereitstellung der später zu übertragenden Update-Pakete verantwortlich. Der Download-Server 21 bezieht seinen Inhalt vom Fahrzeug-Datenmanagement 27, koordiniert durch den Fahrzeugupdate-Server 24. Dies stellt sicher, dass nur jene Update-Pakete durch den Download-Server 21 verfügbar sind, die tatsächlich durch das Fahrzeug 10 gebraucht und benötigt werden.
-
Die Wertschöpfungskette „Fahrzeugupdateanforderung, Content-Zusammenstellung, Content-Bereitstellung“ durch den Download-Server 21 wird somit nur für aktive Fahrzeuge 10 innerhalb einer definierten Kampagne durchgeführt.
-
Der Download-Client 11 ist für das Herunterladen von Softwarekomponenten, Firmware oder anderem Inhalt in das Fahrzeug 10 zuständig. Der Download-Client 11 kann DLOTA oder irgendeine andere, beispielsweise auf HTTP, HTTPS oder FTP basierende Luftschnittstelle 29 unterstützen. Der Download-Client 11 verfügt vorzugsweise über eine Schnittstelle zu einem Content-Speicher 17 via Content-Management 18.
-
Der Fahrzeugupdate-Server 24 ist für die Koordinierungsschicht des Fahrzeugupdate-Prozesses zuständig. Mit anderen Worten: Er führt die definierte Update-Kampagne oder die definierten Update-Kampagnen aus. Die ursprünglich durch das OEM-Daten- und -Servicemanagement geschriebene Spezifikation der Kampagne für ein bestimmtes Fahrzeug 10 lässt sich vom Datenmanagement 27 beziehen. Diese Spezifikation verbindet die erforderlichen Dienste und Abläufe zu einem resultierenden Update-Prozess. Wenn das Fahrzeug 10 durch das Fahrzeugmanagement 25 erkannt und vermerkt wird, werden sein Zustand und Status dauerhaft durch das Datenmanagement 27 überwacht.
-
Der Fahrzeugupdate-Client 14 ist für die Ausführung der Anforderungen des Fahrzeugupdate-Servers 24 zuständig. Der Fahrzeugupdate-Client 14 koordiniert somit den Fahrzeugupdate-Prozess oder einen beliebigen Teil davon – Anwendungssoftware-Updates eingeschlossen – für das Fahrzeug 10. Um Flexibilität und einfache Anbindung an bestehende Technologien zu ermöglichen, implementiert der Fahrzeugupdate-Client 14 auch eine Management-Schnittstelle zum Gerätemanagement. Des Weiteren übernimmt der Fahrzeugupdate-Client 14 die Verantwortung für den heruntergeladenen Inhalt, empfängt den auf das Fahrzeug 10 bezogenen Teil – etwa die Update-Prozessdaten und andere Hilfsinformationen – und delegiert Update und Inhalt an die Client 12 bzgl. 13.
-
Wird beispielsweise OMA-DM verwendet, so können FUMO und/oder SCOMO Objekte verwendet werden.
-
Das Datenmanagement 27 ist seitens des Backends 20 dafür zuständig, konsistente Daten und Inhalt an die Dienste zu liefern.
-
Das Content-Management 18 ist dafür zuständig, jedwede Art von Inhalt innerhalb des Fahrzeuges 10 persistent abzulegen. Es dient gleichsam als netzgebundener Speicher (network-attached storage, NAS) des Fahrzeuges 10 einschließlich der Fähigkeit, die Daten aus einer Web-Quelle zu laden. Mehrere Instanzen eines Content-Speichers 17 können innerhalb des Fahrzeuges 10 existieren und werden durch das Content-Management 18 verwaltet. Das Content-Management 18 kümmert sich um Speicherung, Depaketierung und Zusammenfügen von Daten und kann für jede Art von Anwendung innerhalb des Fahrzeuges 10 genutzt werden.
-
Der Content-Speicher 17 ist dafür zuständig, jedwede Art von Inhalt innerhalb des Steuergerätes (electronic control unit, ECU) persistent abzulegen. Es wird gleichsam wie eine zeichenorientierte Gerätedatei (raw device) verwendet. Mehrere Instanzen des Content-Speichers 17 können innerhalb des Fahrzeuges 10 existieren und werden durch das Content-Management 18 verwaltet. Der Content-Speicher 17 kümmert sich um die Speicherung und kann für jede Art von Anwendung innerhalb des Fahrzeuges 10 genutzt werden.
-
Der Steuergerät-Update-Client 12 resp. 13 ist für die Ausführung des Anwendungssoftware- oder Firmware-Updates für ein bestimmtes Steuergerät oder einen bestimmten Teilbereich zuständig. Der Steuergerät-Update-Client 12 resp. 13 fungiert als Client und ist mit dem Fahrzeugupdate-Client 14 verbunden. Er verwaltet den Anwendungssoftware- oder Firmware-Update-Prozess einschließlich des Rollbacks für ein bestimmtes Steuergerät oder einen bestimmten Teilbereich. Er ist darüber hinaus dafür zuständig, dass der Zustand des Steuergerätes oder Teilbereiches jederzeit bekannt ist.
-
Durch die Aufteilung der Gesamtfunktionalität (des Fahrzeug-Teilsystems) in abgeschlossene und entkoppelte Komponenten können Einflussfaktoren, die zu einem geänderten Verhalten der Gesamtfunktionalität führen würden, auf die Teilfunktionalitäten reduziert werden. Dazu werden als solche bekannte Architektur- und Entwurfsmuster (design patterns) verwendet wie bspw. Redundanzfreiheit (kohärente Systeme mit definierten und getrennten Aufgabenbereichen reduzieren Redundanz) sowie lose Kopplung, die insgesamt den Einfluss von unbekannten Inputwerten oder auslastenden Einflüssen und Bedingungen auf die betreffenden Schnittstellen eingrenzen, reduzieren oder dort erkennbar machen.
-
Das technische System basierend auf dem hier vorgestellten Design und der hier vorgestellten Architektur ermöglicht vor allem den Umgang mit invaliden oder unbekannten Inputwerten oder auslastenden Einflussfaktoren und Bedingungen in einer Weise, dass sich solche Einflussfaktoren nur auf das Verhalten der betreffenden Komponenten auswirken (Lokalität) sowie sich dieses veränderte Verhalten an den Schnittstellen zu übergeordneten, überwachenden und kontrollierenden Komponenten erkennbar zeigt (Transparenz). Dies ermöglicht eine abgestufte und ganzheitliche Reaktion des Systems.
-
Das Zusammenspiel der Funktionen in diesem Lösungssystem betrifft die Interaktion, wenn SW- oder Hardwarekomponenten oder Funktionen ausfallen oder sich nicht innerhalb festgelegter Sequenzen mit Ergebnissen an übergeordnete Komponenten zurückmelden etc. Umgekehrt bewirkt bspw. der Ausfall übergeordneter Instanzen keine oder eine geringe Auswirkung auf konkrete und spezialisierte Komponenten bezüglich eines SW- und insbesondere FW-Updates.
-
Die entkoppelte Robustheit ist in den nachfolgenden Punkten im Detail beschrieben:
Die Robustheit des Systems wird in einem ersten Schritt dadurch erhöht, dass die Robustheit des Gesamtverhaltens des Systems während des OTA-SW- und insbesondere FW-Updates durch auslastende und ggf. abnormale Systemumgebungsbedingungen nicht beeinflusst wird, sondern Auswirkungen eines Teilverhaltens bereits durch die entkoppelten Komponenten erkannt und abgefangen werden.
-
Die Entkopplung der Gesamtfunktionalität und der Zugriff auf die Teilfunktionalitäten, die von den Komponenten über die lose Kopplung anderen Komponenten und Funktionen bereitgestellt werden, bringt in einem zweiten Schritt eine über die lose Kopplung benötigte Abhängigkeits- und Verantwortlichkeitsbeziehung mit sich. D. h. die OTA-SW- und insbesondere FW-Update-Gesamtfunktionalität ist entkoppelt und bewirkt, dass Teilfunktionalitäten von übergeordneten Komponenten an untergeordnete entkoppelte Komponenten zur Ausführung delegiert werden und von den untergeordneten Komponenten an die übergeordneten Komponenten bereitgestellt werden müssen.
-
In einem dritten Detaillierungsschritt des hier vorgeschlagenen Systems erfolgen die Fortschrittsberichterstattung (via lose Kopplung festgelegt) sowie die Einholung eines Einverständnisses der übergeordneten Komponente und Funktion. Dies ist dann von Vorteil, wenn besondere Bedingungen eintreten. Man betrachte folgendes Beispiel: Eine delegierte Aktion muss wiederholt ausgeführt werden, weil bei der Ausführung Fehler aufgetreten sind.
-
Jede der folgenden Komponenten führt basierend auf ihrer Spezialisierung (bspw. robuster Download oder fehlerfreies Ablegen und Abspeichern der Daten) die zugeordneten Aktionen ununterbrochen durch, solange diese nicht von übergeordneten Komponenten und Funktionen anders gesteuert (unterbrochen, pausiert, fortgeführt) werden, wie in 2 dargestellt: ein über die Luftschnittstelle 29 mit einem Backend 20 wechselwirkendes Verbindungsmodul 31, ein mit dem Verbindungsmodul 31 wechselwirkendes robustes Datenhaltungsmodul 32 innerhalb des Fahrzeuges 10, eine mit dem Verbindungsmodul 31 und dem Datenhaltungsmodul 32 wechselwirkende Koordinierungsschicht 33, eine mit dem Verbindungsmodul 31 und der Koordinierungsschicht 33 wechselwirkende Benutzerinteraktion 34 und eine mit dem Datenhaltungsmodul 32 und der Koordinierungsschicht 33 wechselwirkende Installation 35.
-
Das Verbindungsmodul 31 umfasst dabei eine autonome Interaktion mit dem Backend 20 und eine Kenntnisnahme und Auswertung letzter bekannter Fahrzeugzustände sowie eine autonome Durchführung eines aufgetragenen Downloads oder Uploads und eine robuste Handhabung einer Verbindung über die Luftschnittstelle 29. Das Datenhaltungsmodul 32 umfasst eine autonome Speicherung und Einräumung von Zugang sowie eine von der Koordinierungsschicht 33 abhängige Reservierung und Freigabe von Speicherplatz. Die Installation 35 erfolgt mit einer durch die Koordinierungsschicht 33 erteilten Erlaubnis sowie einer auf ein Zielobjekt begrenzten Steuerungsgewalt und umfasst eine Steuerung, Kontrolle, Entscheidung, Ausführung und Überwachung der Installation 36.
-
Die Richtung, in der eine Reporting-Übergabe (handover) erfolgt, ist zum einen vom Fahrzeugupdate-Client 14 gesteuert, wenn sie weitere untergeordnete Komponenten betrifft – bspw. Softwareupdate-Clients 12, 13 –, und zum anderen auch von den Komponenten selbst, bspw. dem Verbindungsmodul 31 mittels Download-Client 11 oder Gerätemanagement-Client 16 oder der Benutzerinteraktion 34. Denn wenn auf Grund einer kritischen Schwachstelle (single point of failure) der Fahrzeugupdate-Client 14 ausfällt und beteiligte Komponenten wie die Benutzerinteraktion 34 oder das Verbindungsmodul 31 eine Interaktion mit dem Fahrzeugupdate-Client 14 versuchen, diesen aber auf Grund des Ausfalls nicht erreichen, dann sind diese mindestens selbstständig in der Lage, ihre eigene Komponentenfunktionalität zu nutzen und das Reporting und Interaktion durchzuführen und den letzten bekannten Schritt für weitere Aktionen zu verwenden. Im Beispiel des Verbindungsmanagements 31 würde ein Gerätemanagement-Client 16 bei dem Backend 20 über bspw. den Ausfall eines Fahrzeugupdate-Clients 14 unter Hinzunahme der letzten bekannten Schritte und Informationen berichten. Im Falle der Benutzerinteraktion 34 würde der Benutzer informiert werden, dass es interne Fehler gibt und der Fahrzeugupdate-Client 14 nicht erreichbar ist (Autonomie).
-
Nachfolgend wird die auch in 2 dargestellte und bereits erläuterte Robustheit des FOTA-Gesamtsystems basierend auf der entkoppelten Robustheit, Lokalität, Transparenz und Autonomie dargestellt, indem für jede der Funktionskomponenten das Zusammenspiel mit anderen entkoppelten Funktionskomponenten beschrieben wird.
-
Die robuste Koordinierungsschicht 33 mittels des Fahrzeugupdate-Clients 14 behandelt Probleme auf ECU-Ebene bis hin zur Fahrzeugebene sowie als weitere Option der Unfall-Ebene (zu lösen im Backend 20).
-
Die Orchestrierungskomponente ist in der Lage, zu jedem separat durchzuführenden Update alle korrespondierenden Daten und Aktionen unverwechselbar eindeutig zu identifizieren, zu administrieren und den Zugriff darauf zu ermöglichen, indem sie die Existenz zu den Daten oder Aktionen verwaltet und administriert und die Referenz (oder die Daten selbst) dem Datenhaltungsmodul 32, Verbindungsmodul 31 oder Updateclientkomponenten zur Verfügung stellt – ähnlich wie es eine Werkstattperson manuell tun würde.
-
Die Orchestrierungseinheit nutzt die Funktionalitäten des Datenhaltungsmanagements 32 und des Verbindungsmanagements 31, indem es die notwendigen Informationen bereitstellt, damit der Download von Updatedaten entkoppelt von der Koordinierungsschicht 33 durchgeführt und die heruntergeladenen Daten an einem zugesicherten Speicherort abgespeichert werden können und für den betreffenden und anstehenden Download genügend Speicherplatz vorhanden ist, sodass diese im Fahrzeug 10 abgespeicherten Daten zu jedem späteren Zeitpunkt, solange die Orchestrierungseinheit die Existenz der Daten ermöglicht und verwaltet, von anderen berechtigten Komponenten verwendet werden können.
-
Die Koordinierungsschicht 33 stellt alle notwendigen Eingangsgrößen sicher, die es der Koordinierungsschicht 33 erlauben, jederzeit ein Update überhaupt zu beginnen, fortzusetzen oder, wenn für den Update definierte Eingangsgrößen und Sollwerte, die der Koordinierungsschicht 33 zur Verfügung stehen, nicht mit den realen Zuständen von ECUs, Clients, des Fahrzeuges 10 oder der Benutzerinteraktion 34 übereinstimmen, auch stoppen zu lassen oder gar, wenn die Koordinierungsschicht 33 parallel zu einer laufenden Updateinstallation Rückmeldung vom Backend 20 über das Verbindungsmodul 31 erhält, das bereits zugeordnete Update bspw. nicht durchzuführen und zu verwerfen (3). Das Sicherstellen aller notwendigen Eingangsgrößen beinhaltet auch, wenn die notwendigen Fahrzeugumgebungsbedingungen existieren und es der Koordinierungsschicht 33 erlauben, aktiv eine Fahrzeugfunktion zu aktivieren oder deaktivieren und so bspw. eine elektronische Handbremse zu betätigen, wenn dies als ein Sollwert definiert wurde, der existieren muss, damit ein Update durchgeführt werden kann. Die Koordinierungsschicht 33 ist zudem in der Lage, alle durchgeführten aktiven Aktionen zur Erreichung eines bestimmten „für den Updatevorgang günstigen“ Fahrzeugzustandes in den ursprünglichen Zustand zurückzuversetzen und so bspw. die elektronische Handbremse wieder zu deaktivieren, wenn das Update durchgeführt wurde.
-
Beispielsweise kann die Koordinierungsschicht 33 bezugnehmend auf 3 von mindestens einem der folgenden Umstände abhängen: die Fahrzeugzustände 50 können abgefragt werden (37) und entsprechen vorgegebenen Sollwerten (38); ein Fahrzeughalter oder Fahrer des Fahrzeuges 10 stimmt der Installation 36 zu (39); die Zustände 51 der Steuergeräte können abgefragt werden (40) und entsprechen vorgegebenen Sollwerten (41); eine für die Installation 36 benötigte Zeit ist insgesamt und für die betreffenden Steuergeräte bekannt (42); eine für das Rollback 36 benötigte Zeit ist insgesamt und für die betreffenden Steuergeräte bekannt (43); ein Fortschritt der Softwareupdate-Clients 12, 13 kann abgefragt werden (44) und entspricht vorgegebenen Sollwerten (45); eine Funktionalität der Softwareupdate-Clients 12, 13 und Steuergeräte kann genutzt werden (46); eine Ablauflogik oder Konfiguration gibt an, wie lange auf eine nicht zugreifbare Information zu warten ist (47); ein Zugriff auf Update- und Rollbackdaten von allen betreffenden Komponenten ist möglich (48); oder Update- und Rollbackdaten sind lokal vorhanden (49).
-
Alle Softwareupdate-Clients 12, 13 sind in der Lage, das eigentliche Update (die Installation 36) einer ECU spezifisch für diese durchzuführen. Softwareupdate-Clients 12, 13 sind wie die anderen dem Fahrzeugupdate-Clients 14 untergeordneten Clients – bspw. der Download-Client 11 – in der Lage, spezifisch, in sich abgeschlossen und spezialisiert Funktionen auszuführen (4). Softwareupdate-Clients 12, 13 sind außerdem in der Lage, in ihrer Funktion Fehler festzustellen und Gegenmaßnahmen einzuleiten. Daher interagieren sie mit dem Fahrzeugupdate-Client 14 – bspw. um Berechtigungen zu erhalten, wenn ein Rollback 36 ausgeführt werden muss und es Auswirkung auf Funktionalität auf der Fahrzeugebene hat oder Reporting-Information an das Backend 20 oder über eine Benutzerinteraktion 34 zu übermitteln –, damit der Fahrzeugupdate-Client 14, der den Fahrzeugzustand 50 kennt und diesen steuern kann, letztendlich das Gesamtupdate steuern kann, einen definierten Zustand 51 des Fahrzeuges 10 unter Berücksichtigung der Verfügbarkeit der Fahrtüchtigkeit des Fahrzeuges 10 gewährleisten kann oder im Falle von nicht einhaltbaren Bedingungen bezüglich des Gesamtsystems oder gar im Falle von unlösbaren Problemen (bspw. eine ECU reagiert nach dem Update gar nicht mehr und der Fahrzeugupdate-Client 14 erkennt das, damit eine Fahrzeugfahrfunktion beeinträchtig ist) die Übergabe an einen Benutzer durchführen kann. Im Falle, dass ein Softwareupdate-Client 12, 13 nicht reagiert, ist der Fahrzeugupdate-Client 14 in der Lage, Gegenmaßnahmen einzuleiten.
-
Der Fahrzeugupdate-Client 14 sendet zu jedem relevanten Updateschritt Reporting-Informationen an das Backend 20, indem er die Informationen von untergeordneten Komponenten und Funktionen sammelt und diese dem Verbindungsmodul 31 übergibt, welches dazu ausgelegt ist, solche Daten über einen vorhandenen Kommunikationsweg eigenständig an das Backend 20 zu verschicken.
-
Der Fahrzeugupdate-Client 14 entscheidet situationsabhängig, wann und über welchen Interaktionsweg – etwa die Benutzerinteraktion 34 über eine Mensch-Maschine-Schnittstelle (human-machine interace, HMI) oder anderweitige Verbindung – eine Übergabe an einen Endbenutzer erfolgt.
-
Das robuste Datenhaltungsmodul 32 (Content Management 18) wird von der Koordinierungsschicht 33 gesteuert und erhält Informationen über den zur Verfügung zu stellenden Speicherplatz für einen anstehenden Download oder bspw. für einen Backup von Daten. Da die Koordinierungsschicht 33 die übergeordnete Komponente und Funktion ist, ist sichergestellt, dass ein bspw. für einen anstehenden Download zu reservierender Speicherplatz solange sichergestellt ist, bis die Orchestrierungsfunktion diesen wieder freigibt – beispielsweise nach der erfolgreichen Updateinstallation, nach einem Rollback 36 oder nachdem ein Update vollständig verworfen wurde.
-
Das Datenhaltungsmodul 32 meldet der Koordinierungsschicht 33 (sowie anderen Komponenten wie dem Verbindungsmodul 31) fortlaufend Reporting – bspw. bei Fehlern oder wenn ein Download einer geplanten Größe vollständig vorliegt und vom Datenhaltungsmodul 32 vollständig abgespeichert wurde, sodass die Koordinierungsschicht 33 weitere Update- und Installationsschritte durchführen und Bedingungen überprüfen kann (siehe 3). Alternativ kann auch das Verbindungsmodul 31 anstelle des Datenhaltungsmanagements 32 der Koordinierungsschicht 33 direkt über Fehler bezüglich eines Downloads fortlaufend berichten.
-
Das robuste Verbindungsmodul 31 mittels des Download-Clients 11 und Gerätemanagement-Clients 16 lädt eindeutig identifizierbare Daten vom Backend 20 über bekannte Schnittstellen und Kommunikationsmöglichkeiten ins Fahrzeug 10. Es ist in der Lage, indem es den tatsächlich im Fahrzeug 10 bereits heruntergeladenen und sicher abgespeicherten Datensatz durch Interaktion über eine lose Kopplung mit dem Datenhaltungsmodul 32 überprüfen und den exakten fehlenden Datensatz vom Backend 20 anfordern kann und ab dem Byte den Download fortsetzen kann, bei dem es einst aufgehört hat und der zuletzt tatsächlich im Fahrzeug 10 sicher abgelegt wurde, und so Luftschnittstellenverbindungsabbrüche und andere Rückmeldungen des Backends 20 an den Komponentensystemgrenzen derart fehlerfrei und robust behandelt werden, über einen robusten Weg Daten ins Fahrzeug 10 vollständig und fehlerfrei abzulegen.
-
Das Ablegen von heruntergeladenen Daten ermöglicht das Datenhaltungsmodul 32, welches die Funktionalität anbietet, Daten so, wie sie übergeben wurden, über eine eindeutige Referenz vollständig und fälschungssicher abzuspeichern.
-
Das Verbindungsmodul 31 reagiert auf unterschiedliche Inputs – bspw. wenn eine Verbindung zu einem Backend 20 plötzlich unterbrochen wird – oder auf spezifischere Antwortinformationen des Backends 20. Es reagiert auch bspw. darauf und steuert den Download- und Wiederaufnahmevorgang (resume) abhängig von Inputs des Datenhaltungsmanagements 32, wenn bspw. das Ablegen und Abspeichern von herunterladenden Daten Fehler verursacht.
-
Das Verbindungsmodul 31 ist in der Lage, vom Backend 20 empfangenen Input an seine verantwortlichen Komponenten weiterzuleiten. In diesem Fall ist der Fahrzeugupdate-Client 14 die übergeordnete Instanz, die alle das Fahrzeug 10 betreffenden Funktionalitäten bezüglich eines Updates steuert und auch auf Funktionalitäten untergeordneter Komponenten zurückgreift.
-
Das Backend 20 stellt dem Verbindungsmodul 31 von jedem Fahrzeug 10 spezifische Updatedaten zur Verfügung und stellt die Informationen bereit, die von einem Verbindungsmodul 31 und einem Fahrzeugupdate-Client 14 genutzt werden können, um den nötigen Speicherplatz für ein anstehendes Update rechtzeitig im Fahrzeug 10 bereitzustellen und einen robusten Download der betreffenden für das Fahrzeug 10 eindeutigen und unverwechselbaren Updatedaten über die Luftschnittstelle 29 ins Fahrzeug 10 zu laden, sodass ein robuster, ressourcenschonender und reibungsloser Update vonstattengehen kann.
-
Das Backend-Teilsystem erhält durch das Verbindungsmodul 31 eines Fahrzeuges 10 über jeden definierten Updateschritt des Fahrzeugs zu einer betreffenden Kampagne zusätzlich Reporting-Informationen neben Informationen über aufgerufene Backendschnittstellen. Basierend auf den dem Backend 20 zur Verfügung stehenden Informationen über Schnittstellenaufrufe sowie Reporting-Informationen von Fahrzeugen 10 bezüglich einer Kampagne führt das Backend 20 Ist-Soll-Vergleiche dieser zur Verfügung stehenden Reporting-Werte mit den in der betreffenden Kampagne festgelegten Schwellwerten durch und erwirkt ggf. Steuerungs-Aktionen (Kampagne pausieren, stoppen, fortlaufen lassen) seitens der restlichen Fahrzeuge 10, bei denen das betreffende Update noch ansteht oder gerade durchgeführt wird. Durch das Zusammenspiel der Backend- und Fahrzeugteilsysteme wird die Robustheit erhöht, indem auf Resultate eines jeden Updateschritts einer vorgegebenen Anzahl von Fahrzeugen 10 auf eine robuste und korrekte Ausführung eines Updates geschlossen wird und fehlerhafte oder falsche Updates an zukünftigen Fahrzeugen 10 vermieden werden.
-
Basierend auf der Analyse von Reporting-Informationen können Kampagnen- und Updateverantwortliche sogar eine Updatekampagne verbessern und wieder ausrollen.
-
Das vorgestellte Zusammenspiel der Funktionen – auf Teilsystemebene (wie Backend- und Fahrzeug-Teilsysteme zusammenspielen) sowie auf Fahrzeugebene (wie Komponenten und Funktionen zusammenspielen) – stellt dar, wie die traditionellen Schritte einer Werkstattperson automatisiert im OTA-Szenario vom Fahrzeug 10 automatisiert durchgeführt werden. Die Koordinierungsschicht 33 entspricht hauptsächlich der Werkstattperson, die den Fahrzeugzustand 50 für ein robustes und korrektes Update sicherstellt, bspw. dass genügend Stromversorgung vorhanden ist, indem eine externe Reservebatterie am Fahrzeug 10 angeschlossen wird (Fahrzeugupdate-Client 14, welcher Ist- und Soll-Zustände der Fahrzeugsystemumgebung passiv und aktiv betrachtet und bspw. vor dem Update überprüft, ob der Batteriezustand der Dauer eines anstehenden Updates entspricht und diesen fortlaufend während des Updates überprüft) oder indem für jedes betreffende Steuergerät das Überschreiben des Flash-Speichers (flashing) einzeln oder von einem zentralen Werkstattdiagnosetester ausgeführt wird, diesem aber die richtigen Daten zur Verfügung gestellt werden (Fahrzeugupdate-Client 14, der die eigentliche Update-Installation 36 an betreffende Softwareupdate-Clients 12, 13 delegiert und interagiert) und nach jedem Flash- oder Installationsschritt an einer einzelnen ECU überprüft wird, ob das Überschreiben und die Installation 36 fehlerfrei erfolgt sind (Fahrzeugupdate-Client 14, der die Ist-Soll-Zustände 51 der am Update betreffenden ECUs und Softwareupdate-Clients 12, 13 vor, während und nach dem Update und nach jeder Installation 36 kennt und aktiv beeinflusst).
-
Diese gesamte Koordinierungsschicht 33 eines Fahrzeugupdates ist in erweiterter Form Aufgabe der Koordinierungsschicht 33 bzw. des Fahrzeugupdate-Clients 14, welcher all die Orchestrierungs- und Managementarbeit während des Fahrbetriebs des Fahrzeugs 10 durchführen muss und kann und entscheiden muss, wann das Fahrzeug 10 für welche Teilaktionen in einem bestimmten Fahrzeugzustand 50 sein muss (und sich bspw. nicht bewegen darf), indem er die Sollwerte des betreffenden Steuergerätes vergleicht und auf diese aktiv reagiert.
-
Die nachfolgenden Anwendungsfälle (use cases) stellen beispielhaft Abläufe dar. Die Anwendungsfälle enthalten Kernaktionen und Kernschritte, die ausgeführt werden sollten. Die Kernschritte entsprechen den bereits vorgestellten Funktionskomponenten (Verbindungsmodul 31, Datenhaltungsmodul 32, Koordinierungsschicht 33) oder sind zum Teil in diesen enthalten und abgeschlossen von den anderen Funktionskomponenten beschrieben.
-
Das Verbindungsmodul 31 erhält Daten von einem authentifizierten Backend 20. In den Daten sind FOTA-Informationen enthalten, welche vom Verbindungsmodul 31 an die Koordinierungsschicht 33 als der FOTA-Daten zugeordneten Einheit weitergeleitet und bereitgestellt werden. Parallel hat das Verbindungsmodul 31 Reporting-Daten über den Erhalt und über eine erfolgreiche Weiterverteilung der FOTA-Daten an die verantwortliche Komponente zwischengespeichert und (je nachdem, wie das Verbindungsmodul 31 konfiguriert ist, mit dem Backend 20 zu kommunizieren) ggf. dem Backend 20 sofort mitgeteilt.
-
FOTA-Updateverfügbarkeitsinformationen erreichen somit nicht nur das Fahrzeug 10 (bspw. weil vorher eine Updateverfügbarkeitsüberprüfung über einen Endbenutzer oder das Backend 20 ausgelöst wurde), sondern auch die verantwortliche Zielfunktionskomponente (Koordinierungsschicht 33 bzw. Fahrzeugupdate-Client 14) im Fahrzeug 10. Diese verantwortliche Komponente interpretiert die FOTA-Daten und erkennt ein zur Verfügung stehendes Update, welcher Speicherplatz für den Download der eigentlichen Update- und Rollbackdaten benötigt wird und inwiefern und ob eine Benutzerinteraktion 34 erfolgen muss – bspw., dass zuvor eine Lizenzvereinbarung (license agreement) vom Benutzer eingeholt werden muss, dass im Allgemeinen selbst der Download vom Benutzer über eine Interaktion bestätigt werden muss oder dass es sich um ein „Silent-Update“ zur Ausführung im Hintergrund handelt, ohne dass der Benutzer für das Update miteinbezogen werden muss, oder weil eine Lizenzvereinbarung überhaupt nicht erforderlich ist.
-
Parallel zu jedem beschriebenen Schritt werden für das Backend 20 bestimmte Reporting-Informationen an das Verbindungsmodul 31 übergeben. Das Verbindungsmodul 31 zwischenspeichert diese, um sie zu einem bestimmten geeigneten Zeitpunkt an das Backend 20 zu verschicken, oder verschickt diese ggf. sofort nach der Überreichung an das Backend 20. Das Backend 20 ist in der Lage, diese Reporting-Informationen über die Ausführung des Updates in einem Fahrzeug 10 zu interpretieren und diese Art der Reporting-Informationen aggregiert über viele weitere Fahrzeuge 10 zu nutzen, um die Updatekampagne zu steuern und bspw. zu pausieren, wenn die Reporting-Informationen über bestimmte Updateschritte fehlerhafte Ausführungen erkennen lassen.
-
Die Koordinierungsschicht 33 nutzt die FOTA-Updateinformationen und lässt beim Datenhaltungsmodul 32 den benötigten Speicherplatz auf Verfügbarkeit überprüfen und – falls vorhanden – eindeutig identifizierbar reservieren (eindeutig daher, dass sie nach Abschluss oder in beliebigen Situationen den Speicherplatz wieder freigeben muss, so wie er reserviert wurde, da die Koordinierungsschicht 33 den Fahrzeugzustand 50 überprüft und steuert und für den Ablauf des gesamten Updates zuständig ist).
-
Hat die Koordinierungsschicht 33 erst einmal alle erforderlichen Informationen eingeholt, die es benötigt (Bestätigung des Benutzers durch Interaktion, wenn es erforderlich war, oder die Zusicherung des Datenhaltungsmanagements 32 über den zur Verfügung stehenden Speichers usw.), dann überreicht es parallel wieder Reporting-Informationen an das Verbindungsmodul 31, führt aber auch weiterhin parallel weitere Update-Ablaufschritte aus, wenn diese in den FOTA-Informationen enthalten sind, und delegiert als nächsten Schritt den Download der eigentlichen Updatedaten an das Verbindungsmodul 31, indem es den Downloaddeskriptor – einen einheitlichen Ressourcenanzeiger (uniform resource locator, URL), Zugangsinformationen (credentials) etc. – aus den FOTA-Informationen verwendet und zusätzlich dem Verbindungsmodul 31 die Informationen mitgibt, wo und wie die zu herunterladenden Daten abgespeichert werden sollen (und zwar in dem reservierten Speicherbereich).
-
Das Verbindungsmodul 31 führt die delegierte Aufgabe aus und berücksichtigt während des Downloads ggf. größere Megabyte- oder Gigabytedaten sowie unterschiedliche Einflüsse, die über die OTA-Luftschnittstelle 29 auftreten können. Es agiert autonom und selbstständig und sorgt für den robusten Downloadvorgang und reagiert unmittelbar auf Anfragen bzgl. des Downloadvorgangs mit Reporting-Informationen an seine übergeordneten oder beteiligten Instanzen und Funktionskomponenten (Koordinierungsschicht 33, Datenhaltungsmodul 32). Auch hier werden parallel nach der Delegation der Downloadaufgabe an das Verbindungsmodul 31 Reporting-Informationen zur Weiterleitung an das Backend 20 an das Verbindungsmodul 31 übergeben. Das Verbindungsmodul 31 teilt der Koordinierungsschicht 33 und Benutzerinteraktion 34 den Status des Downloads mit, falls ggf. über Benutzerinteraktion 34 der Status an den Benutzer weitergegeben werden muss und diese Art der Interaktion mit dem Benutzer in den FOTA-Informationen definiert und von der Koordinierungsschicht 33 interpretiert wurden und daher so ausgeführt werden müssen.
-
Der Koordinierungsschicht 33 wird es vom Verbindungsmodul 31 und ggf. auch vom Datenhaltungsmodul 32 mitgeteilt, sobald der Download abgeschlossen wurde und die heruntergeladenen Daten vollständig und sicher zugreifbar bereitstehen.
-
Die Koordinierungsschicht 33 interpretiert Datenteile – die sogenannte Update-Ablauflogik (flow) und zugehörige Bedingungen für die konkrete Updateinstallationen – aus dem heruntergeladenen Fahrzeug 10-Updatepaket, die angeben, inwiefern weiterhin eine Benutzerinteraktion 34 erfolgen muss und ob eine Zustimmung eingeholt werden muss, bspw. das Update zu einem von der Koordinierungsschicht 33 vorgeschlagenen Zeitpunkt auszuführen sowie zusätzlich basierend auf den nachfolgenden FOTA-Ablauflogikdaten, wenn bspw. vorher auch eine weitere Lizenzbestätigung vom Endbenutzer (Fahrer) erfolgen muss, bevor überhaupt die eigentliche Updateinstallation anfangen kann, oder weil das Fahrzeug 10 bspw. in einen bestimmten Zustand 51 gebracht werden muss und eine Bestätigungseinholung des Benutzers notwendig ist. Diese Informationen sind als Ablauflogik Bestandteil des über das Verbindungsmodul 31 heruntergeladenen Fahrzeug-Updatedatenpakets. Darin kann außerdem enthalten sein, wie lange bspw. das Gesamtupdate andauert, welche Installationsausführungen (Softwareupdate-Clients 12, 13) betroffen sind, welche Steuergeräte oder Fahrzeugdomänen – etwa Infotainment oder Karosseriesteuerung (body control) – betroffen sind und in welchem Zustand 51 sich das Fahrzeug 10 befinden muss, d. h. einige der von der anstehenden Updateinstallation betroffenen Steuergeräte und Softwareupdate-Clients 12, 13 dürfen nur ausgeführt werden, wenn bspw. der Batteriestand des Fahrzeuges 10 einen bestimmten Ladezustand (level) hat, da die Updatezeit an einem Steuergerät dies erfordern würde.
-
Die Koordinierungsschicht 33 überprüft die in der Update-Ablauflogik enthaltenen Sollwerte und vergleicht diese mit Istwerten des Fahrzeuges 10, indem es die notwendigen Fahrzeug-Interfaces verwendet und so bspw. den Batteriezustand des Fahrzeuges 10 und ggf. den momentanen Grad der Batterieentladung erhält und im Soll-Istwert-Vergleich entscheidet, ob eine Installation 36 überhaupt gestartet werden kann. Falls eine Installation 36 bereits gestartet wurde und der Fahrzeugupdate-Client 14 parallel auf Grund des einzuhaltenden Sollwertes fortlaufend und parallel zur Ausführung der einzelnen Installation 36 bspw. plötzlich feststellt, dass ein Istwert wie bspw. der Batteriestand im Vergleich mit dem definierten Sollwert zu einem definierten Zeitpunkt unterschritten ist, dann wird diejenige Updateinstallation bspw. pausiert, unterbrochen oder neu ausgeführt – abhängig davon, was letztendlich in der Update-Ablauflogik definiert ist und wie mit einem solchen Fall umzugehen ist, wenn die Batterie einen Soll-Schwellwert unterscheitet. Falls eine solche Unterschreitung des Soll-Schwellenwerts des Batteriestands Auswirkungen auf den Fahrzeugzustand 50 und ggf. auf die Fahrzeug-Fahrfunktionalität hat und die vollständige Ausführung als Bestandteil der Updateinstallation in der Update-Ablauflogik definiert ist, kann die Updateinstallation vollständig beendet oder eine sofortige Unterbrechung initiiert werden und bspw. ein Rollback 36 zur Ausführung an den Softwareupdate-Client 12, 13 delegiert werden – je nachdem, wie schnell bspw. der Rollback 36 durchgeführt werden kann und ob dies in der Update-Ablauflogik definiert ist und welche zusätzlichen Bedingungen vorhanden sein müssen. Im Falle eines Pausierens – je nachdem, was in der Update-Ablauflogik für einen solchen Sonderfall als weitere Aktion definiert wurde – steuert der Fahrzeugupdate-Client 14 den korrespondierenden Softwareupdate-Client 12, 13 mit Unterbrechungsbefehlen an. Der Fahrzeugupdate-Client 14 würde entsprechend seiner spezifischen Funktionalität seine aktuellen laufenden Aktionen ggf. zu Ende ausführen und die ECU in einem vom Fahrzeugupdate-Client 14 definierten (wenn auch nicht voll funktionsfähigen) Zustand 51 hinterlassen oder ggf. alle laufenden Aktionen unterbrechen und mit Statuszuständen an den Fahrzeugupdate-Client 14 berichten, sodass der Fahrzeugupdate-Client 14 über den Zustand 51 der Softwareupdate-Clients 12, 13 und des Steuergeräts in Kenntnis ist und nach seinen Update-Ablauflogik-Regeln (den Fahrzeugzustand 50 berücksichtigend) weiter verfahren kann. Pausieren eines Softwareupdate-Clients 12, 13 bedeutet, diesen in einen definierten Zustand 51 versetzen zu lassen, indem der Softwareupdate-Client 12, 13 einen definierten Zustand 51 bezüglich eines Installationsschrittes hinterlässt und bspw. alle notwendigen Informationen zur Sitzung (session) speichert, damit er in der Lage ist, nach Ende einer Pause weiterzumachen, wo er aufgehört hat, bspw. wenn wieder ein gültiger Batterielevel vorhanden ist, ohne somit von Neuem mit der initial vom Fahrzeugupdate-Client 14 delegierten Ausführung zu starten. Eine Unterbrechung eines Softwareupdate-Clients 12, 13 bedeutet, eine einst delegierte Ausführungsaktion vollständig zu unterbrechen und von neuem ggf. mit neuen Inputwerten zu beginnen.
-
Die Koordinierungsschicht 33 überprüft zu Beginn, welche der betroffenen Softwareupdate-Clients 12, 13 für spezifische und vereinzelnde Updateinstallation überhaupt auf ein bestimmtes Zielsteuergerät oder auf eine Zieldomäne spezialisiert sind und welche dieser Softwareupdate-Clients 12, 13 den Fahrzeugzustand 50 und Fahrzeugfahrfunktionalität betreffen und welche einzelnen und spezifischen Updateinstallationen abhängig von anderen Updateinstallationen in der Reihenfolgeausführung sind, um so die unabhängigen und den Fahrzeugzustand 50 nicht betreffenden einzelnen Updateinstallationen (parallel zur weiteren Abarbeitung und Bestimmung der Updateinstallationsstarts der anderen Updateinstallationen) bereits auszuführen, nachdem bspw. eine Startbestätigung des Endbenutzers eingeholt wurde. Die verbleibenden und bspw. den Fahrzeugzustand 50 betreffenden einzelnen Updateinstallationen können ggf. mehr Zeit in Anspruch nehmen, bis der optimale Zeitpunkt für die eigentliche Updateinstallation eintreten kann, da bspw. umfangreichere Zustände 51 im Fahrzeug 10 verlangt werden und mehrere Soll-Istwert-Vergleiche und Zustände 51 im Fahrzeug 10 erfüllt sein müssen (weil es sich bspw. um ein Motorsteuergerät handelt), bspw. wenn ein bestimmter Batteriezustand vorhanden sein muss oder das betreffende Steuergerät nur im stillgelegten Fahrzeugzustand 50 aktualisiert werden darf und somit bspw. eine bestimmte verlangte Datenrate über den betreffenden Bus-Kommunikationskanal zur Verfügung steht, damit auch die in der Update-Ablauflogik geplante Updateinstallationszeit eingehalten werden kann. Die Bestimmung des optimalen Zeitpunktes einer Updateinstallation bei Auswirkung auf Fahrzeugfahrfunktionalität kann bspw. auch dadurch verzögert werden, dass der Endbenutzer auf den Ausfall der Fahrzeugfunktionalität für eine bestimmte Zeit informiert werden und er zustimmen muss und selbst dann noch die Situation eintreten muss, dass das Fahrzeug 10 tatsächlich stillsteht und erst dann die Updateinstallation an einem Steuergerät mit Auswirkung auf Fahrzeugfahrfunktionalität vom korrespondierenden Softwareupdate-Client 12, 13 initiiert durch den Fahrzeugupdate-Client 14 durchgeführt werden kann. Ein möglicher Sonderfall ist der folgende: Ein Fahrer fährt eine lange Strecke und parkt auf der Autobahn. Der Fahrzeugupdate-Client 14 stellt fest, dass alle Bedingungen erfüllt sind und das Fahrzeug 10 bspw. auch stillsteht und führt die Updateinstallation am Motorsteuergerät aus. Ein Endbenutzer steigt ins Fahrzeug 10 ein und möchte losfahren, muss aber bspw. mehrere Minuten abwarten, da der vom Fahrzeugupdate-Client 14 künstlich herbeigeführte Fahrzeugzustand 50 (Fahrzeug 10 darf während der Updateinstallation nicht starten bzw. fahrbereit sein) eine Weiterfahrt nicht erlaubt. Ein erweiterter Sonderfall wäre wie soeben beschrieben mit dem Unterschied, dass die Updateinstallation fehlschlägt und bspw. das Motorsteuergerät auch nach einem Rollback 36 nicht mehr funktioniert und das Fahrzeug 10 den Unfall behandelt und der Fahrer auf seiner langen Reise nicht mehr weiterfahren kann. Hieraus wird ersichtlich, dass eine Bestätigung des Endbenutzers und Bestimmung des optimalen Zeitpunktes sehr wichtig sind.
-
Der Fahrzeugupdate-Client 14 delegiert also insgesamt Ausführungsaktionen wie bspw. Speicherplatzreservierungen, Downloadvorgänge oder Updateinstallationsschritte an Softwareupdate-Clients 12, 13, die zuständig sind für Updateinstallationen in betroffenen Domänen oder an betroffenen Steuergeräten und stellt selbst die notwendigen Fahrzeugzustände 50 und ECU-Zustände 51 sicher, indem es beispielsweise nicht nur Ausführungsaktionen delegiert, sondern auch die Erreichbarkeit von bspw. Softwareupdate-Clients 12, 13 und ECUs vorher überprüfen lässt, den Batteriezustand und den Fahrzeugmodus (steht es still oder fährt es) überprüft, die Benutzerinteraktion 34 und Benutzerrückmeldung miteinbezieht und die einzelnen Rückgabewerte mit in seine Soll-Istwert-Vergleiche einschließt. Diese Orchestrierungsarbeit kann von der Koordinierungsschicht 33 bzw. von dem Fahrzeugupdate-Client 14 selbst dann durchgeführt werden, während einzelne bereits delegierte Ausführungen fortlaufen, und parallel Soll-Istwert-Vergleiche durchgeführt werden, indem es von den Funktionskomponenten Status-, Fortschritts- und Erreichbarkeitsinformationen verlangt und diese auch bereitstellt (3, 4).
-
Durch seine transparente Verantwortung, Reporting-Informationen zu jedem relevanten Schritt an seine Beobachter (observer) (Verbindungsmodul 31, Benutzerinteraktion 34) bereitzustellen, ist sichergestellt, dass selbst bei Ausfall der Koordinierungsschicht 33 die entkoppelten und autonomen Funktionskomponenten den letzten bekannten Zustand 51 und bspw. einen Ausfall weitergeben können – bspw. an das Backend 20 oder direkt über Benutzerinteraktion 34 an den Benutzer.
-
Die Update-Ablauflogik-Definition ist entweder datenorientiert und es existiert eine Implementierungsgegenstelle im Fahrzeug 10 (hier: Koordinierungsschicht 33 bzw. Fahrzeugupdate-Client 14), die die Daten interpretieren und bspw. alle vorkommenden Attribute, Parameter und Werte verstehen und umsetzen kann, oder die Updatedaten-Ablauflogik-Definition enthält für das Fahrzeug 10 und dessen spezifisches durchgehendes (end-to-end, E/E) Fahrzeugmodell und E/E-Fahrzeugtopologie spezifisch parallel ausführbare Regeln oder Update-Ablauflogik im Sinne eines Skriptes, welches mittels eines Interpreters ebenfalls von der Koordinierungsschicht 33 ausgeführt wird.
-
Hat der Fahrzeugupdate-Client 14 durch Soll-Istwert-Vergleiche innerhalb des Fahrzeuges 10 nach dem Update – bspw. Überprüfung der aktuellen SW- und insbesondere FW-Versionen anhand von Ziel-SW- und insbesondere FW-Versionen – festgestellt, dass das Fahrzeugupdate erfolgreich verlaufen ist, ist es – je nachdem, wie es in der Update-Ablauflogik definiert wurde, wann der Schritt unter welchen Bedingungen nach einem erfolgreichen Update auszuführen ist, bspw. wenn der Soll-Istwert-Vergleich von SW- und insbesondere FW-Versionen erfolgreich war – in der Lage, den reservierten Speicherplatz wieder freizugeben und die alten Updatedaten zu löschen, indem es mit dem Datenhaltungsmodul 32 interagiert.
-
Der robuste Umgang mit Sonderfällen beinhaltet bspw. auch Folgendes:
Ein Updateverfügbarkeitsabbruchtrigger durch das Backend 20, während ein Update bereits im Fahrzeug 10 ausgeführt wird erlaubt, dass der Fahrzeugupdate-Client 14 laufende oder bereits durchgeführte Updates unterbrechen und rückgängig machen kann, indem er Rollbackaktionen von den Softwareupdate-Clients 12, 13 durchführen lässt.
-
Bspw. wenn Speicherplatzverfügbarkeit (aus unterschiedlichsten Gründen) nicht mehr gegeben ist, erhält der Fahrzeugupdate-Client 14 entsprechende Statusinformationen und kann basierend seiner Update-Ablauflogik das Update am Fahrzeug 10 steuern.
-
Wenn bspw. der Zustand 51 der betreffenden Softwareupdate-Clients 12, 13 oder ECUs nicht mehr verfügbar ist oder der Zustand 51 der betroffenen ECUs und Softwareupdate-Clients 12, 13 durch den Fahrzeugupdate-Client 14 nicht mehr angefragt werden kann, stellt der Fahrzeugupdate-Client 14 einen bestimmten Fahrzeugzustand 50 sicher und berichtet an seine Beobachter.
-
Optionen, die als zusätzliche Elemente zur Robustheit beitragen, umfassen eine duale Architektur, in welcher die FOTA-Komponenten und Funktionen verteilt sind.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
