Over-The-Air Software-Updates erfolgreich mit AUTOSAR Classic umsetzen

Kennen Sie die unterschiedlichen OTA-Ansätze im Fahrzeug?

Vergleich von OTA-Update-Strategien

Software-Updates „Over-The-Air“ (OTA) sind heute fester Bestandteil vieler Produkte der Unterhaltungselektronik. Apps auf Smartphones und Tablets werden praktisch täglich mit Updates versorgt. Applikationen als auch die Firmware der Geräte lassen sich so fortlaufend und einfach direkt beim Endverbraucher aktualisieren.

Im Automotive-Bereich sind Software-Updates „Over-The-Air“ derzeit zwar vereinzelt schon umgesetzt, allerdings ist die Funktionalität dann meist auf bestimmte Steuergeräte bzw. Anteile der Fahrzeugsoftware eingeschränkt. Durch die steigende Komplexität der Fahrzeugsoftware und deren Bedeutung für die Funktionalität wächst der Bedarf an Software-Updates – selbst für sicherheitsrelevante Anwendungen/Funktionen.

Da heutige Fahrzeuge mehr als 100 Steuergeräte enthalten können, ist eine optimale Implementierung eine echte Herausforderung. Die auf mehrere Steuergeräte verteilten Fahrzeugfunktionen müssen über sogenannte Update-Kampagnen, bestehend aus Update-Paketen für alle betroffenen Steuergeräte, aktualisiert werden. Dies kann zu teilweise komplexen Update-Szenarien im Fahrzeug führen. Dabei ist es unabdingbar, dass die Aktualisierungsprozesse automatisch, unbeaufsichtigt und vollkommen verlässlich ablaufen. Im Falle eines Fehlers muss jederzeit sichergestellt sein, dass das Fahrzeug zurück in einen betriebsbereiten Zustand gebracht werden kann, notfalls durch ein vollständiges Wiederherstellen der vorherigen Software-Version.

Fokus auf AUTOSAR Classic Steuergeräten

Flash Bootloader als optimale Ergänzung

Damit rücken auch klassische Steuergeräte in den Fokus, die auf der Basissoftware AUTOSAR Classic basieren, wie beispielsweise Türsteuergeräte aus der Body-Domäne. Üblicherweise verfügen diese Steuergeräte über einen sogenannten Flash Bootloader, über den die Applikationssoftware inklusive der AUTOSAR Basissoftware per Diagnose auf dem Steuergerät aktualisiert wird.

Flash Bootloader sind seit vielen Jahren im Einsatz, um eine Steuergerätesoftware zu programmieren oder später im Lebenszyklus zu aktualisieren. Es sind vergleichsweise kleine und dabei hochoptimierte Programme, die per Diagnose angesprochen werden und den Flash-Speicher löschen und neu beschreiben. Updates über den Flash Bootloader erfolgen während der Entwicklung, der Produktion und in der Werkstatt. Zum Zeitpunkt des Updates lässt sich die volle Bandbreite des entsprechenden Bussystems nutzen. Die Programmierung findet in jedem Fall in einem sicheren Zustand des Fahrzeugs statt.

Für den Anwendungsfall von Software-Updates „Over-The-Air“ ist ein Flash Bootloader ebenfalls eine optimale Ergänzung (Abbildung 1).

Abbildung 1: Software-Update über den Flash Bootloader

Die neue Software wird drahtlos in das Fahrzeug übertragen und auf einem zentralen Steuergerät, hier „Connectivity-Steuergerät“ genannt, mit ausreichend großem Speicher zwischengespeichert. Sobald die Software auf das Zielsteuergerät im sicheren Zustand aufgespielt werden soll, startet das Connectivity-Steuergerät den Update-Prozess und lädt per Diagnosesequenz das Software-Update auf das Zielsteuergerät – genau so, wie es der Werkstatt-Diagnosetester machen würde.

 

Zwei limitierende Faktoren bei OTA

1. Während des Update-Prozesses verbleibt das Fahrzeug im sicheren Zustand und kann nicht genutzt werden. Diese „Down-Time“ des Fahrzeugs wird vom OEM im Sinne des Kundenkomforts üblicherweise streng limitiert – dies hat erheblichen Einfluss auf den Umfang bzw. die Größe der Updates.

2. Die am Update-Prozess beteiligten Steuergeräte müssen mit Strom versorgt werden. Die Restkapazität der Batterie gibt somit eine strikte Grenze für die Dauer des Updates vor.

 

Houston, wir haben KEIN Problem!

Der Weg zur effizienten Update-Kampagne

Wie bereits erwähnt ist die Möglichkeit zur Wiederherstellung eines vorherigen Softwarestandes im Falle eines fehlerhaften Updates alternativlos. Daher ist im Extremfall ein vollständiges Reprogrammieren und Zurückrollen von allen an der Update-Kampagne beteiligten Steuergeräten erforderlich. Durch die oben genannten limitierenden Faktoren Down-Time und Batteriekapazität sind die Möglichkeiten eines Flash Bootloaders im OTA-Szenario eingeschränkt.

Eine andere Möglichkeit ist die Übertragung der Daten an die jeweiligen Zielsteuergeräte bereits während des Normalbetriebs, also während der Fahrt, mit der Speicherung in einem von der Fahrapplikation getrennten Speicherbereich (Abbildung 2). Die Daten sind dabei nicht notwendigerweise im Connectivity-Steuergerät zwischengespeichert. Vielmehr werden die empfangenen Daten direkt an die Zielsteuergeräte weitergereicht.

Dieser Ansatz hat folgende Vorteile:

  • Die Übertragungszeit des Updates zum Zielsteuergerät im sicheren Fahrzeugzustand wird eingespart.
  • Ein Wiederherstellen der vorherigen Software ist ohne weitere Datenübertragung möglich.
Abbildung 2: Software-Download während der Fahrt

Mit Konzepten, die auf eine entsprechende Hardwareunterstützung zur Umschaltung der Software-Versionen bauen, lassen sich Aktivierungszeiten auf ein Minimum reduzieren. Das Fahrzeug bleibt also trotz Software-Update jederzeit betriebsbereit.

AUTOSAR Classic hat mit dem Release 19-11 Requirements an eine Firmware Over-The-Air (FOTA) Lösung, die eine Datenübertragung bereits während der Fahrt ermöglicht, veröffentlicht. Noch wurden jedoch kein entsprechendes Basissoftwaremodule im Standard eingeführt.

Vector hat mit MICROSAR Classic bereits frühzeitig auf FOTA gesetzt und bietet bereits seit 2018 eine Erweiterung der MICROSAR Basissoftware für den Software-Download an, die insbesondere die AUTOSAR Anforderungen erfüllt.

Teil 2

Speicherpartitionierung und Versionsumschaltung

Eine Grundvoraussetzung für ein erfolgreiches OTA-Update ist die Speicherpartitionierung im Zielsteuergerät: Der Speicher muss eine Möglichkeit bieten, das Softwareupdate während der normalen Ausführung zwischenzuspeichern, potenziell über mehrere Fahrzyklen hinweg.

Strategien zur Speicheroptimierung

Dieser Teil der Artikelserie konzentriert sich daher auf mögliche Strategien zur Speicheroptimierung. Die verschiedenen Wege unterscheiden sich hauptsächlich anhand der erforderlichen Hardware-Eigenschaften als auch der Performance des Umschaltens, d.h. der Zeit, die maßgeblich für den Fahrzeug-Stillstand beim Softwareupdates verantwortlich ist.

Um während der normalen Ausführung der Steuergeräteapplikation eine neue Softwareversion zu empfangen und im Steuergerät zwischenspeichern zu können, ist ein zusätzlicher Speicher notwendig, der unabhängig von der laufenden Software gelesen und beschrieben werden kann. Im Folgenden gehen wir von typischen Mikrocontrollern aus, die die Applikation direkt vom Flash-Speicher ausführen. Für den Einsatz erforderlich ist daher ein Flash-Speicher, der mindestens eine zusätzliche Partition mit Read-While-Write (RWW) Eigenschaft unterstützt, die nicht für die Ausführung der Applikation genutzt wird. Eine solche RWW-Partitionierung ermöglicht die Ausführung von Code aus der einen Partition, während in eine andere Partition geschrieben werden kann. Die gelesene Partition enthält dabei die aktuelle Software. Die geschriebene Partition ist diejenige, in die die neue Software geschrieben wird.

Dieser Ansatz stellt eine Lösung für die Speicherung des Softwareupdates dar. Allerdings muss die neue Software auch zur Ausführung gebracht werden, also aktiviert werden. Insgesamt lassen sich folgende drei typischen Ansätze betrachten:

Hardware-assisted A/B-Swap

Ein A/B Swap-fähiger Controller unterteilt seinen internen Speicher in zwei Partitionen. Diese beiden Partitionen können im Wechsel eine einheitliche Ausführungsadresse zugewiesen bekommen. Es ist somit möglich, dass ein einmalig gelinktes Image an zwei unterschiedlichen physikalischen Positionen ausgeführt werden kann. Welche die aktive Partition (A oder B) gerade ist, wird typischerweise entweder in einem Hardware-Register dauerhaft abgelegt oder bei jedem Neustart per Software gesetzt. Für die Umschaltung reicht also ein Neustart des Steuergeräts aus. Es gibt praktisch keine Downtime des Steuergeräts während der Aktivierungsphase.

Abbildung 3 zeigt beispielhaft die Umschaltung in einem System mit A/B-Bänken. Der physikalische Adressbereich 0xA00000 - 0xC00000 ist nach der Umschaltung über den Bereich 0x00000 – 0x20000 lese- und ausführbar.

Abbildung 3: Umschaltung in einem System mit A/B-Bänken

Dual-Binary-Ansatz und Position-Independent Code

Auch ohne Hardwareunterstützung der Adressbereiche von Bank A und B lässt sich eine schnelle Umschaltung erreichen. Was aber sind die Bedingungen und Einschränkungen dazu?

Beim Dual-Binary Ansatz wird ein Softwarestand für die Applikation sowohl spezifisch für die Adressen für Bank A und für Bank B gebaut. Ein Softwareupdate besteht also immer aus zwei verschiedenen Binärdaten. Es werden nur die Daten heruntergeladen, die für die gerade inaktive Bank geeignet sind. Vor der Einspielung eines Updates erfolgt also anhand der aktiven Partition die Auswahl der richtigen Daten. Diese Lösung hat jedoch massiven Einfluss auf die Software-Logistik des Fahrzeugherstellers. Denn für jede Softwareversion müsste er zwei Stände pflegen und verwalten.  Abbildung 4 zeigt beispielhaft das Szenario im Dual-Binary-Ansatz.

Abbildung 4: Szenario im Dual-Binary-Ansatz

Eine andere Möglichkeit ist, die Software unabhängig von der konkreten Ausführungsadresse zu programmieren. Dieser Ansatz wird Position-Independent-Code genannt. Er wird von einigen Compilern unterstützt. In der Praxis hat sich jedoch gezeigt, dass die Unterstützung von Position-Independent-Code mit sehr hohen Anforderungen an die Struktur des Codes einhergeht. Daraus ergeben sich unter anderem Nachteile hinsichtlich der Ausführungsperformanz.

Last but not Least: Der Caching-Ansatz mit Backup

Sollten weder die Hardware-unterstützte Umschaltung von Adressbereichen noch die beiden oben genannten Alternativansätze in Frage kommen, ist dies kein Grund zu verzweifeln. Denn es gibt noch einen generischen Ansatz. Beim Caching-Ansatz mit Backup ist lediglich ein von der aktiven Partition unabhängiger Zwischenspeicher erforderlich. Dieser muss natürlich groß genug sein, um den Softwarestand zwei Mal abzuspeichern. Die Idee hinter diesem Ansatz ist es, dass der Bereich der aktiven (also aktuell ausgeführten) Software konstant bleibt. Während der Umschaltung wird der Bereich gelöscht und mit der neuen Software überschrieben. Um die Anforderung an eine Rollback-Möglichkeit zu erfüllen, muss die aktuelle Software als Backup gespeichert werden. Der Zwischenspeicher muss daher sowohl die neue (inaktive) Software als auch das Backup abspeichern können.

Diese Voraussetzung ist erfüllt bei

  • internem Flash mit mindestens zwei RWW-Partitionen, wobei Partitionen, die nicht zur Ausführung genutzt werden, zwei Softwarestände speichern können

         oder

  • Verfügbarkeit von zusätzlichem externem Speicher, der zwei Softwarestände speichern kann.

Abbildung 5 zeigt beispielhaft den Caching-Ansatz mit Backup. Die Erstellung des Backups kann, wie der Download der neuen Software, im Hintergrund ausgeführt werden. Für die Umschaltung muss lediglich der aktive Bereich gelöscht und mit der Software aus der inaktiven Partition geschrieben werden.

Abbildung 5: Caching-Ansatz mit Backup

Der Caching-Ansatz hat allerdings gegenüber den anderen Ansätzen mit internem Flash einen klaren Nachteil: Nämlich den der längeren Aktivierungsdauer. Vorteilhaft hingegen ist, dass er bei der Hardwareauswahl mehr Freiheiten bietet. Außerdem erfordert der Caching-Ansatz im Gegensatz zum Dual-Binary-Ansatz keine Verwaltung von unterschiedlichen Binärdaten für unterschiedliche Ausführungsadressen.

Die Nutzung von externem Speicher dürfte seine Vorteile also insbesondere bei existierenden Steuergeräteprojekte ausspielen, die um die Möglichkeit des Software-Downloads erweitert werden sollen. Ein wirklicher Rettungsanker also, wenn die Voraussetzungen der anderen Ansätze an den internen Flashspeicher nicht zu erfüllen sind.

Fortsetzung folgt

Der noch folgende Teil dieser Artikelreihe befasst sich mit folgendem Thema:

  • Software-Download in Classic MICROSAR

Verpassen Sie nicht die Fortsetzung dieser Serie! Folgen Sie uns auf den Social-Media-Kanälen und gehören Sie zu den ersten Lesern!

Empfohlene Seiten

MICROSAR Classic

Die intelligente Implementierung des AUTOSAR-Standards.

Mehr Informationen
Flash Bootloader

Kompakte Lösung zur schnellen, effizienten und sicheren Re-Programmierung von Steuergeräten.

Mehr Informationen
AUTOSAR Classic

Alles zum serienerprobten Standard für komplexe Fahrzeugsteuergeräte.

Zur Seite gehen
Automotive OTA

Automotive Over-The-Air verändert die Branche. Anwendungen wie Software-Updates, Live-Diagnose und...

Mehr erfahren
vConnect | Vector Automotive Over-The-Air Solution

Mit Fahrzeugflotten in Kontakt bleiben: Die neue Vector Automotive-OTA-Lösung entdecken.

Zur Seite gehen