OTA beherrschen: Die Domänen Automotive und IT konvergieren

Mit dem Einzug von High Performance Computing Plattformen (HPCs) ins Fahrzeug wandeln sich auch die eingesetzten E/E-Architekturen. Aktuell sind mehrere Domänen-Controller über ein zentrales Gateway miteinander verbunden (Bild 1a). Die Funktionen werden bereits zum Produktionszeitpunkt konkreten Steuergeräten (Mikrocontrollern) zugeordnet. Dort eingesetzte Software ist überwiegend in embedded-C-Code geschrieben, der auf minimalen Ressourcenverbrauch hin optimiert ist. Das Programmierparadigma erlaubt keine dynamische Speicherverwaltung. Ein Vertreter dieser Architektur ist die Autosar-Classic-Plattform (Bild 1).

Bild 1: Aktuell sind mehrere Domänen-Controller über ein zentrales Gateway verbunden (a), während zukünftig komplexe Funktionen zentral auf HPCs implementiert sind (b). Vector Informatik

In zukünftigen Fahrzeuggenerationen sind komplexere Funktionen zentral auf HPCs (Mikroprozessoren) implementiert. Diese Funktionscluster kommunizieren über eine entsprechende Middleware miteinander. Für die Sensorik und Aktorik kommen weiterhin klassische Steuergeräte zum Einsatz (Bild 1b). Ziel ist eine serviceorientierte Architektur, die eine bessere Wartbarkeit und Erweiterbarkeit des Gesamtsystems – insbesondere auch nach Start of Production (SOP) – ermöglicht. Auf diesen HPCs kommen vielfach Posix-kompatible Betriebssysteme zum Einsatz. Für diese Plattformen können Techniken und Werkzeuge Verwendung finden, welche aus der klassischen IT-Welt stammen. Die Verwendung objektorientierter Hochsprachen wie C++ wird möglich und ein neues Programmierparadigma erlaubt eine dynamische Speicherverwaltung. Ein Beispiel für eine solche Architektur ist die Autosar-Adaptive-Plattform.

Software-Update

In der Telekommunikation sind Software-Updates „Over the Air“ seit vielen Jahren üblich. Ein Smartphone erhält derzeit fast täglich ein Update für eine oder mehrere Applikationen. Im Automotive-Bereich sind diese Mechanismen noch nicht durchgängig verbreitet. In der Regel wird die Steuergerätesoftware immer noch in der Werkstatt aktualisiert. Ein Grund hierfür ist auch die deutlich höhere Komplexität eines Steuergeräte-Updates in einem Fahrzeugnetzwerk, verglichen mit dem Update einer App auf dem Smartphone: Aktuelle Fahrzeuge können über 100 Steuergeräte enthalten, welche auf unterschiedlichen Plattformen basieren und über verschiedene Updatemechanismen verfügen. Sie kommunizieren in einem heterogenen Netzwerk über mehrere Bussysteme in einer vielschichtigen Topologie miteinander.

Außerdem muss sich das Fahrzeug für ein Software-Update in einem sicheren Zustand beziehungsweise einer gesicherten Umgebung befinden, da während des Updates sicherheitsrelevante Funktionen unter Umständen nicht verfügbar sind. Beispielsweise muss das Fahrzeug während des Updates stillstehen und der Motor darf nicht laufen. Diese Vorbedingungen sind in einer Werkstatt sehr einfach herstell- und überprüfbar, indem zum Beispiel ein externer Werkstatttester an das Fahrzeug angeschlossen wird.

Bild 2: Live-Diagnose-Abläufe kommen der Komplexität klassischer Applikationssoftware immer näher. Entwickler benötigen entsprechende Werkzeuge, die Effizienz und Qualität steigern. Ein Beispiel dafür ist die Vector-Diagnostic-Scripting-Bibliothek (VDS). Vector Informatik

Im OTA-Szenario sind solche Vorbedingungen automatisiert und unbeaufsichtigt zu prüfen und sicherzustellen. Dies erfordert Applikationen, welche im Fahrzeug die Rolle des Werkstatt-Testers und des Service-Technikers übernehmen können. Der eigentliche Flashablauf unterscheidet sich dabei prinzipiell nicht von dem im Offboard-Szenario mit dem Werkstatt-Tester durchgeführten Ablauf. Für das Software-Update über OTA wird in neueren Steuergeräten ein Softwaredownload im Applikationskontext unterstützt. Diese Steuergeräte halten hierzu intern den doppelten Speicher vor. Während auf der aktiven Partition die Applikation ausgeführt wird, lässt sich die neue Softwareversion im Betrieb auf die inaktive Partition herunterladen. Durch anschließendes Umschalten der Partitionen ist die neue Software ohne nennenswerte Downtime aktivierbar. Über diesen Mechanismus ist auch ein verlässliches Rollback auf die Vorversion unkompliziert möglich. Ein zuverlässiges Rollback ist zwingend notwendig, um ein Fahrzeug nach einem fehlgeschlagenen Update betriebsfähig halten zu können.

Wiederverwendung von Flash-Containern

Der Flashablauf für ein Steuergerät ist durch den Bootloader fest vorgegeben. Zunächst wird die Kommunikation zum Zielsteuergerät über CAN oder DoIP aufgebaut. Anschließend wird das Steuergerät entriegelt, beziehungsweise der Tester führt eine Authentifizierung durch. Im Anschluss daran erfolgt die Ausführung von Diagnosesequenzen. In diesen Skripten werden beispielsweise zunächst Werte aus dem Steuergerät ausgelesen und in Abhängigkeit der ermittelten Daten dann unterschiedliche Zweige durchlaufen.

Bild 3: Für Signale, welche auf dem CAN- hinter einem DoIP-CAN-Gateway anliegen, existiert seit Autosar 4.4 eine Bus-Mirror-Komponente. Vector Informatik

Welche Sprache zur Implementierung dieser Abläufe verwendet wird, ist hierbei zweitrangig. Relevant sind die flash- und diagnosespezifischen Bibliotheksfunktionen, die der Anwendung zur Verfügung stehen. Die Software-Update-Applikation der Automotive-OTA-Lösung vConnect von Vector verwendet Flash-Container, welche mit dem Werkzeug vFlash erstellt wurden. Die Wiederverwendung dieser Flash-Container im OTA-Kontext ist möglich, da diese neben den Flash-Sequenzen auch alle Daten, Kommunikationsparameter und Adressinformationen enthalten, die für eine Re-Programmierung erforderlich sind. Insbesondere basieren die Flash-Skripte auf einer Diagnose- beziehungsweise Flash-Bibliothek, welche beiden Anwendungen gemeinsam ist. Die Flash-Container lassen sich so mit Standardwerkzeugen lokal entwickeln und validieren.

Live-Diagnose

Um über die Diagnose Daten auslesen oder Routinen ausführen zu können, ist es oft notwendig, mehrere Diagnoseservices in bestimmten Sequenzen auszuführen. Beispiele sind das Auslesen des Fehlerspeichers oder die Ausführung von Tests über die Diagnose. Für die Beschreibung dieser Sequenzen kommt in der Live-Diagnose-Applikation von vConnect dieselbe Diagnose-Bibliothek zum Einsatz, welche auch im Diagnosewerkzeug Indigo und im Software-Update-Fall Anwendung findet. Diese Bibliothek wird durchgängig für die Anwendungsfälle Diagnose und Flashen sowohl Offboard als auch Onboard eingesetzt.

Die Komplexität dieser Abläufe kommt der von klassischer Applikationssoftware immer näher. Es liegt also nahe, dem Entwickler solcher Abläufe die entsprechenden Werkzeuge zur Verfügung zu stellen. Hierzu zählt insbesondere eine professionelle IDE und ein Test-Framework. Dies steigert die Effizienz und erhöht die Qualität der erstellten Abläufe. Für die Ablaufumgebung im Fahrzeug sind auf der anderen Seite Aspekte wie Ressourceneffizienz und Sicherheit entscheidend (Bild 2).

Bild 4: Sicherheit und Datenschutz sind eine fundamentale Anforderung an eine OTA-Lösung. Eine Ende-zu-Ende Absicherung der Kommunikation ist unerlässlich. Hier ist es sinnvoll, die notwendigen Kommunikations- und Sicherheitskomponenten für alle OTA Applikationen gemeinsam in einem Framework bereitzustellen. Vector Informatik

Beispiel für einen solchen Ansatz ist die Vector-Diagnostic-Scripting-Bibliothek (VDS). Diese ist in einer portablen Version mit unterschiedlichen Language-Bindings verfügbar. Mittels einer Extension für die professionelle integrierte Entwicklungsumgebung (IDE) Microsoft Visual Studio lassen sich Flash- und Diagnoseabläufe komfortabel auf dem PC in der Sprache C# entwickeln und testen. Die Extension unterstützt den Entwickler durch Features, wie Intellisense auf Qualifier-Ebene, Syntax-Highlighting, Debugging und einem Test-Framework. Dadurch ist es möglich, die erstellten Abläufe bereits zum Entwicklungszeitpunkt gegen die zugrundeliegenden Datenbasen zu validieren.  Für den Einsatz im Fahrzeug werden diese Abläufe automatisch in die Skriptsprache LUA konvertiert. Warum LUA? Der LUA-Interpreter ist aufgrund seines geringen Ressourcenbedarfs, der Integrierbarkeit in C++-Applikationen und den Möglichkeiten zur Abkapselung von Skripten sehr gut für den Einsatz im Fahrzeug geeignet.

Datensammeln

Beim Sammeln von Daten über eine gesamte Fahrzeugflotte ist eine effiziente Übermittlung der Daten an das Backend eminent wichtig, um Bandbreite und somit Kosten zu sparen. Technisch lässt sich hier eine optimale Kodierung der Inhalte anstreben und die Daten im Fahrzeug vorverarbeiten sowie aggregieren. Diese Vorverarbeitung erzeugt aber immer zusätzliche Last auf den Steuergeräten, welche im Extremfall den laufenden Betrieb einschränken kann. Dies gilt es unter allen Umständen zu vermeiden. Datensammelaufträge müssen daher strikt daraufhin ausgelegt sein, möglichst wenige, dafür aber die „richtigen“ Daten zu erfassen.

Dies ist nur mit dem entsprechenden Domänenwissen möglich und erfordert in der Regel ein Nachschärfen der Abfrage nach Auswertung der ersten Ergebnisse. Dazu ist es notwendig, Datensammelanfragen dynamisch erstellen und modifizieren zu können. Das Know-how, welches in eine Datensammelanfrage einfließt, ist wertvoll. Diese Konfigurationen sind daher auch einem Versionsmanagement zu unterwerfen. Dies gilt gleichermaßen für Logger-Konfigurationen, die mit klassischen Werkzeugen erstellt und validiert wurden.

Over-the-Air-Anwendungen versprechen Einsparpotenziale für OEMs. Vector Informatik

Die auf den Fahrzeugbussen übertragenen Signale liefern bereits einen tiefen Einblick in das Fahrzeugverhalten. Diese Signale sind außerdem mit minimalen Seiteneffekten erfassbar. Annahme ist hierbei, dass das HPC-System, auf dem die Applikation zum Sammeln der Daten läuft, über Ethernet angebunden ist. Es gibt allgemein verfügbare Bibliotheken, mit denen sich Ethernet-Kommunikation komfortabel mitschneiden lässt. Dies erzeugt auf dem Bus praktisch keine zusätzliche Last. Für Signale, welche auf dem CAN- hinter einem DoIP-CAN-Gateway anliegen, existiert seit Autosar 4.4 eine standardisierte Bus-Mirror-Komponente. Diese verfügt über eine API, mit der zur Laufzeit eine Instrumentierung möglich ist. Damit lassen sich ausgewählte CAN-Frames in DoIP-Pakete verpacken und die enthaltenen Signale über Ethernet verfügbar machen (Bild 3).

Die Daten können dann zentral in der Datensammel-Applikation auf dem HPC vor der Übermittlung an das Backend gefiltert und aggregiert, oder über Trigger in Beziehung gesetzt werden. Im Backend wird aus den empfangenen Datenreihen beispielsweise das standardisierte Datenformat MDF erzeugt. Dieses Format wird von vielen im Markt erhältlichen Mess- und Analysewerkzeugen unterstützt.

Framework

Sicherheit und Datenschutz sind eine fundamentale Anforderung an eine OTA-Lösung. Eine Ende-zu-Ende-Absicherung der Kommunikation ist unerlässlich. Hier ist es sinnvoll, die notwendigen Kommunikations- und Sicherheitskomponenten für alle OTA-Applikationen gemeinsam in einem Framework bereitzustellen. Die Automotive-OTA-Lösung vConnect bietet in ihrem Framework eine solche Security- und Kommunikations-API an. Über diese API stehen komplexe Kommunikations-Muster, wie der Aufbau einer verschlüsselten Sitzung oder Request/Response-Kommunikation komfortabel anwendbar zur Verfügung.

Verschiedene Sicherheitsmechanismen sind in dieser API ebenfalls bereits integriert. Beispielsweise ein Replay-Schutz, welcher es erlaubt, aufgezeichnete und nochmals verschickte Nachrichten auf Empfängerseite zu erkennen und zu verwerfen. Sowohl auf Backend- als auch auf Fahrzeugseite stellt das Framework Standardmechanismen, wie die sichere Ablage von Zertifikaten und Schlüsseln oder die Validierung von Signaturen, zur Verfügung. Die APIs des Frameworks sind öffentlich. Es lässt sich daher auch zur Umsetzung neuer kundenspezifischer OTA-Anwendungen einsetzen (Bild 4).

Das Framework ermöglicht aufgrund der Container-basierten Backend-Architektur vielfältige Optionen für ein Deployment. Auf Fahrzeugseite sorgen mehrere Abstraktionsschichten unter anderem für Kommunikation, Datenablage und Mensch-Maschine-Schnittstelle für eine einfache Adaptierung auf verschiedene Posix-Derivate und Hardwareumgebungen.

(na)