Bereit für die Fahrzeuge der Zukunft

Seit rund 15 Jahren ist AUTOSAR der Software-Entwicklungsstandard im Automobilbereich. Nun wird neben der bewährten AUTOSAR Classic-Plattform (CP) die AUTOSAR Adaptive-Plattform (AP) als eine Umgebung für Systeme mit hoher Rechenleistung und flexibler Software-Konfiguration eingeführt. IAV als AUTOSAR Premium Member arbeitet intensiv an der Entwicklung von Adaptive AUTOSAR mit, um die neue Technologie bald in Serie bringen zu können.

Künftige Fahrzeuge werden deutlich komplexer sein und über viele neue Funktionen verfügen – etwa für hochautomatisiertes Fahren, Car-2-X-Anwendungen, die Vernetzung mit Consumer-Elektronik oder Remote Update. Ein Ergebnis daraus ist der breite Einzug von Ethernet ins Auto. Es ermöglicht nicht nur deutlich höhere Datenraten, sondern hat auch eine völlig andere Architektur als die derzeit vorherrschenden CAN- oder FlexRay-Busse. Zudem lässt sich Ethernet bei Bedarf flexibel erweitern.

Die bewährte AUTOSAR Classic-Plattform ist den neuen Anforderungen nicht mehr gewachsen, weil sie kaum erweiterbar und wenig flexibel ist. Darum arbeitet die AUTOSAR-Entwicklungspartnerschaft seit über zwei Jahren an einer neuen Technologie, die die Anforderungen an Flexibilität und steigende Komplexität zukünftiger Funktionen abdecken kann. Adaptive AUTOSAR bildet die Basis für die neuen Funktionen in den vernetzten und digitalisierten Fahrzeugen der nächsten Generation.

Ein zentraler Unterschied zwischen CP und AP: Statt mit einer signalbasierten Kommunikation haben es die Software-Entwickler mit einer serviceorientierten Architektur (SOA) zu tun. Wie in der IT-Welt gibt es bei AP einzelne Anbieter und Konsumenten von Diensten. „Konsumenten können sich bei Anbietern anmelden und deren Dienste nutzen, wobei es auch mehrere Anbieter für den gleichen Dienst geben kann“, erklärt Tobias Lorenz, Fachreferent für AUTOSAR bei IAV. „Die Dienste können entweder lokal auf dem Steuergerät oder steuergeräteübergreifend genutzt werden, wobei AP für die Kommunikation zwischen ihnen verantwortlich ist.“

Dieses Konzept ist deutlich flexibler als die bisherige Lösung: So lassen sich neue Anbieter und Konsumenten von Diensten beispielsweise einfach nachträglich in das System integrieren – etwa wenn das Fahrzeug über ein Remote Update mit einer neuen oder aktualisierten Funktion ausgestattet wird. Dienste können dem Nutzer vom OEM sowie zukünftig auch von Drittanbietern zur Verfügung gestellt werden. Hier eröffnen sich dem OEM zuvor im Fahrzeug nicht nutzbare Märkte. Durch das Zur-Verfügung-Stellen von standardisierten Nutzerschnittstellen durch den OEM können Drittanbieter, ähnlich wie beim Smartphone, Mehrwertdienste für den Fahrzeugnutzer über einen App-Store zum Download zur Verfügung stellen.

Für Software-Entwickler ist der Umstieg auf AP mit größeren Änderungen verbunden. „Bei der Arbeit ist neues Denken gefordert: Klassische, echtzeitfähige AUTOSAR-Tasks werden nach einem festen Zeitplan abgearbeitet und sind innerhalb gewisser Grenzen prädizierbar. Zudem nutzen alle Applikationen den gleichen Speicherraum, für dessen statische Aufteilung der Software-Entwickler verantwortlich ist.“, so Lorenz. „Bei AP hat man es mit einem POSIX-Betriebssystem (PSE51) zu tun, das Multithreading ermöglicht und bei dem jede Applikation einen eigenen virtuellen, dynamisch adressierten Speicherbereich hat. Die Applikationen müssen mit Schwankungen bei der Ausführungszeit von Diensten zurechtkommen können, etwa wenn ein neuer Algorithmus für eine bestimmte Funktion geladen wurde.“

Außerdem treten durch das erforderliche Laden aller Applikationen ins RAM beim Hochfahren des Steuergerätes neue Herausforderungen in Form von längeren Startzeiten auf. Bei den Tool-Landschaften sind ebenfalls Änderungen eingetreten: Sie sind komplexer, wie erste prototypische Umgebungen einiger Anbieter zeigen.

Die Einführung von AP bedeutet aber nicht das Aus für CP. Stattdessen werden beide in Zukunft im Fahrzeug zusammenarbeiten und dabei ihre jeweiligen Stärken einbringen: CP bleibt weiterhin zuständig für hardwarenahe, echtzeitfähige und sicherheitskritische Funktionen, während AP immer dann zum Einsatz kommt, wenn eine besonders hohe Rechenleistung und Flexibilität gefragt sind.

Im Oktober 2018 soll die erste serienfähige Version des neuen Standards veröffentlicht werden, danach kann dieser als Grundlage für die ersten AP-Seriensteuergeräte angesehen werden. IAV beschäftigt sich in laufenden Kundenprojekten bereits intensiv mit der Entwicklung von Diensten nach dem aktuell verfügbaren AP-Standard. Bei diesen Arbeiten werden die aktuell verfügbaren Entwicklungsumgebungen der verschiedenen Anbieter verwendet.

Alle derzeit verfügbaren Umgebungen basieren auf einer für AP angepassten Yocto-Build- Umgebung (www.yoctoproject.org). Mit Yocto können Linux-basierte Systeme unabhängig von der Hardware konfiguriert, generiert und mithilfe von QEMU simuliert werden. QEMU ist ein Open-Source-Maschinenemulator und ermöglicht somit die Virtualisierung von Software-Tests.

Darüber hinaus untersucht IAV die durch AP verursachten Auswirkungen auf die Kommunikationsarchitektur bei der Verwendung von Mischsystemen aus CP und AP. Dabei entstehen Kommunikationspfade, die bisher im Fahrzeug nicht existierten: CAN (signalbasiert) zu Ethernet (serviceorientiert). Hierzu wurden intensive Laufzeit- und Performanzmessungen unter der Verwendung der derzeit in diesem Umfeld etablierten serviceorientierten Protokolle, wie zum Beispiel SOME/IP- und REST-basiert, durchgeführt.

Im Rahmen von Kunden und eigenen Projekten wird sich IAV weiter intensiv mit der Serienreife von Mischsystemen auseinandersetzen; natürlich ist AP auch Teil des Qualifizierungsprogramms bei IAV.

• Programmierung in C++
• Serviceorientierte Architektur
• POSIX-basierte API
• Applikation wird vor Ausführung ins RAM geladen
• Jede Applikation verfügt über einen eigenen virtuellen, dynamisch adressierten Speicher
• Threadbasiertes Scheduling bei der Ressourcenvergabe