zurück zum Artikel

Die Anforderungen an den Systementwurf und die Softwareentwicklung im Automobil wachsen durch die drei wichtigsten Zukunftsthemen der Automobilbranche: autonomes Fahren, Software-Updates "over the air" und die Elektrifizierung des Antriebs.

Die aktuelle E/E-Architektur (elektrisch/elektronisch) im Fahrzeug integriert eine oder einige wenige Fahrzeugfunktionen pro Steuergerät. Dadurch steigt die Zahl der Steuergeräte und der verteilten Softwarefunktionen ebenso wie die Komplexität der Vernetzung. Diese Architektur muss dabei zunehmend mehr Fahrerassistenzfunktionen übernehmen. Schätzungen zur Softwarekomplexität gehen von über 100 Millionen Programmzeilen aus, die in einem Premiumfahrzeug heute auf mehr als 100 Steuergeräte verteilt sind.

Derzeit werden noch einzelne oder eng verwandte Funktionen jeweils auf einem Steuergerät realisiert. Durch die Verfügbarkeit leistungsfähigerer Automotive-geeigneter Systems on a Chip (SOC, z. B. Renesas R-CAR H3, NXP BlueBox oder Nvidia Drive PX) und die Notwendigkeit, Gewicht zu sparen, beispielsweise durch die Reduktion von Steuergeräten oder Verkabelung, besteht der Wunsch zur Integration mehrerer Funktionen auf einem Domain-Controller (zuständig beispielsweise für Body, Chassis oder Engine) oder gar weniger Zentralrechner.

Dieser Paradigmenwechsel ändert die E/E-Architektur der Fahrzeuge erheblich. So halten serviceorientierte Kommunikation und dynamische Betriebssysteme Einzug, die wiederum die Anforderungen an Echtzeit, funktionale Sicherheit und Security erfüllen müssen. Der Einsatz dynamischer Steuergeräte ermöglicht zudem das Nachrüsten von Funktionen, die zum Zeitpunkt der Fahrzeugvorstellung noch nicht vorhanden sind.

Der folgende Artikel geht auf die verschiedenen Techniken für zukünftige E/E-Architekturen ein und stellt Änderungen sowie Risiken und neue Möglichkeiten dar.

Die E/E-Architektur in der Zukunft

Die Abbildung 1 zeigt die wahrscheinliche zukünftige E/E-Architektur. Herzstück sind ein oder wenige Zentralrechner, die über ein fahrzeuginternes Ethernet-Backbone kommunizieren. Zentrales Element des Fahrzeugs wird das Gateway, das die User-Interface-Domain (Infotainment-System/Anbindung Smartphone) von der Drive-Domain (Antrieb, Bremse, Batteriemanagement) trennt und das Fahrzeug über die sogenannte Smart Antenna mit dem Backend-System des OEM verbindet. Kernaufgabe der Smart Antenna und des Gateways ist es, verschiedene Security-Ebenen wie Firewall und Intrusion Detection zu realisieren. Zudem werden Mechanismen für die sichere On-Board-Kommunikation zwischen den Steuergeräten zum Einsatz kommen.

Die Verbindung zum Backend-System ermöglicht viele neue Funktionen. Beispielsweise lässt sich das Fahrzeug mit Umgebungsdaten wie Straßenzustand, freien Parkplätze oder aktuellen Angeboten des Fahrzeugherstellers versorgen. Diese Online-Dienste und die Möglichkeit der Funktionsfreischaltung (z. B. Fahrerassistenzsysteme) geben den Fahrzeugherstellern die Gelegenheit, über den Verkaufszeitpunkt des Automobils hinaus auch während des Betriebs Umsatz zu generieren.

Die ständige Online-Verbindung zum Fahrzeug erlaubt es dem OEM, Nutzerdaten zu sammeln und somit mehr Informationen über Zuverlässigkeit und Verschleiß der verwendeten Komponenten zu bekommen. Fehlerquellen in Hard- und Software sowie dazugehörige Umgebungsdaten können über die Diagnoseschnittstelle erkannt, die Software beim Hersteller verbessert und zeitnah ein Update ins Auto geladen werden, ähnlich zu den Updates der Smartphone-Apps, an die sich Nutzer seit Jahren gewöhnt haben.

Zentralrechner, Kommunikation

Ein Rechner im Zentrum

Autonomes oder hochautomatisiertes Fahren erfordert, dass das Fahrzeug sich ein "Bild" von der Umgebung machen kann. Das Umgebungsmodell wird durch die sogenannte Sensorfusion erstellt, bei der Kamera-, Radar-, LiDAR- (Light Detection and Ranging) und Ultraschall-Daten zu einem Modell zusammengefasst werden. Verschiedene Sensortechniken sind notwendig, da einzelne Systeme Schwächen haben, die sich durch andere Techniken kompensieren lassen. Beispielsweise können Kamerasysteme unter Umständen helle Objekte nicht erkennen, wenn die Sonne blendet.

Diese aufwendigen Berechnungen übernimmt in Zukunft der Zentralrechner im Fahrzeug. Die verwendeten Prozessoren werden heterogene Multicore-Prozessoren sein mit vermutlich mehreren Rechenkernen, GPUs und mehreren GBit-Ethernet-Kanälen. Für sicherheitskritische Funktionen wie Plausibilisierung, Monitoring und Ergebnisvalidierung werden zusätzliche Safety-Kerne auf dem Chip integriert oder ein zweiter Prozessor auf der Platine integriert. Das ist keine Zukunftsmusik. Mit ARM Cortex A50/A57, Renesas R-Car H3, Cortex R7 und Infenion Aurix existieren bereits solche Systeme.

Im Gegensatz zu diesen komplexen Mehrkernsystemen waren viele Steuergeräte vor zehn Jahren noch 16-Bit-Single-Core-Systeme. Dieser Technologiesprung erfordert bei den Zulieferern einen anspruchsvollen Kompetenzaufbau im Bereich Software. War sie früher nur ein Kostenfaktor, der zu einer Bremse inklusive Steuergerät gehörte, wird in Zukunft die Softwarefunktion den eigentlichen Wert darstellen. Das wird die existierende Zuliefererkette aufbrechen und neue Geschäftsmodelle ermöglichen. Gewinnen werden wohl Hersteller, die rechtzeitig durchgehende Tool-Ketten vom Systemdesign, Zeitmodellierung, Codegenerierung und Verifikation sowie Validierung einsetzen, um die steigende Softwarekomplexität und damit die Kosten in den Griff zu bekommen.

Aktuell werden in den meisten Steuergeräten statisch konfigurierte Betriebssysteme eingesetzt, die nach dem AUTOSAR [2]- oder OSEK [3]-Standard implementiert sind. Zur Konfigurationszeit legen diese Systeme das Scheduling und die Ressourcennutzung fest, die sich zur Laufzeit nur bedingt ändern lassen. Vorteil der statischen Konfiguration ist die einfachere Verifizierbarkeit, dass eine Funktion in einer bestimmten Zeitspanne ausgeführt wird. Im Fall des Seitenairbags ist zum Beispiel in nur wenigen Millisekunden zu entscheiden und der Airbag auszulösen.

Für weniger zeitkritische Systeme zusammen mit komplexeren Mehrkernprozessoren und verschiedenen externen Interaktoren (Software-Update, User-Eingaben) haben dynamische Betriebssysteme ihre Stärken. Die wichtigsten Anwendungsszenarien sind:

• Unterstützung von Rekonfiguration zur Laufzeit
• serviceorientierte Dienste und Kommunikation
• Partial Software Updates
• Vereinfachung der Softwareentwicklung durch den Einsatz von POSIX-Schnittstellen statt statisch generierter, XML-basierter Schnittstellenbeschreibungen

Der Vorschlag des AUTOSAR-Konsortiums hierfür ist Adaptive AUTOSAR (s. Abb. 2). Grundlage ist ein POSIX-OS, basierend auf dem Linux-Kern, das entweder direkt auf einem Mehrkernprozessor läuft oder in einer Hypervisor-Umgebung, falls mehrere Betriebssysteme parallel integriert werden sollen. Die Adaptive-AUTOSAR-Arbeitsgruppen verschiedener OEMs und Zulieferer definieren die speziellen Services für den Einsatz im Automobil, zum Beispiel Diagnostic Services, Security Service und SOME/IP. Die Services und Softwarekomponenten (die Funktionen) kommunizieren über einen gemeinsamen Service-Broker. Das verwendete Middleware-Protokoll nennt sich ARA und ist von der Common API [4] inspiriert.

Ethernet und TSN als Mittler

Die Kommunikation zwischen den meisten Steuergeräten, Sensoren und Aktuatoren wird über Ethernet realisiert. Um sicherheitskritische und zuverlässige Kommunikation zu realisieren, wird das Time Sensitive Networking (TSN [5]) benutzt, eine Erweiterung des Audio Video Bridging Protocol (AVB). Der TSN-Standard entstand für sicherheits- und echtzeitkritische Systeme wie ADAS (Advanced Driver Assistance Systems) und autonomes Fahren. Zusätzlich kommt Ethernet zum Einsatz, um Infotainment-Systeme mit dem Internet und Backend-System des Fahrzeugherstellers zu verbinden.

Verlierer des Technologiewechsels ist FlexRay. Das Feldbussystem setzen nur noch wenige OEMs ein und dürfte bald abgelöst werden. CAN und CAN FD (CAN mit flexibler Datenrate) werden weiterhin Verwendung finden, um Sensoren und Aktuatoren oder kleinere IO-Steuergeräte zu verbinden.

Die Kommunikation zwischen IO-Geräten und den Zentralrechnern erfolgt über eine serviceorientierte Schnittstelle, die die BMW Group 2011 spezifiziert hat: "Scalable Service-Oriented Middleware over IP", kurz SOME/IP. Sie setzt auf Ethernet und auf die TCP/IP-Protokollfamilie auf. Wesentlich hierbei ist, dass SOME/IP eine definierte Anwendungsschnittstelle automatisch auf Pakete abbildet. Der Vorteil von SOME/IP ist, dass es sich selbst auf kleinen Geräten integrieren lässt und ein schnelles Starten des Gesamtsystems ermöglicht.

Funktionale Architektur

Neben den bisher vorgestellten Infrastrukturthemen, die größtenteils das AUTOSAR-Konsortium spezifiziert hat, zeigt sich zunehmend der Bedarf nach einer funktionalen Architektur, in der die Schnittstellen zwischen Funktionsblöcken definiert sind. Der Vorteil gemeinsamer standardisierter Schnittstellen liegt in der Austauschbarkeit bestimmter Blöcke und der Möglichkeit, diese als Produkt einzukaufen oder anzubieten.

Abbildung 3 zeigt einen Architekturvorschlag aus dem "Open Robinos [6]"-Projekt des Automotive-Softwareherstellers Elektrobit. Auf der linken Seite befinden sich die Komponenten für die Fahrzeugpositionierung und Object Fusion, die Objekte, die durch unterschiedliche Sensoren erkannt werden, zu einem Gesamtbild zusammenfügt. Basierend auf der aktuellen Fahrsituation werden dann die Trajektorien-Planung sowie Beschleunigung und Lenkwinkel bestimmt.

Das Projekt hat das Ziel, eine offene Referenzarchitektur zu erarbeiten, die Softwarekomponenten, Schnittstellen und Kontrollmechanismen definiert. Die Spezifikation ist frei verfügbar und das Projekt ist offen für die Mitarbeit weiterer OEMs, Zulieferer und Partner.

Dieser Ansatz ist neu auf dem Markt, hat aber das Ziel, auf verschiedenen ADAS-Plattformen (Advanced Driver Assistance) integriert zu werden. In diesem Kontext ordnet sich die Plattform ein in unterschiedliche Hardware mit verschiedenen Betriebssystemen wie Adaptive AUTOSAR, QNX oder unixoiden OS, die vielfach auf dem Markt angeboten werden.

Infrastruktur, Entwicklungsprozess

Infrastruktur als Herausforderung

Eine große technische Herausforderung für das (teil-)autonome Fahren ist die Infrastruktur, in der sich das Fahrzeug bewegt. Derzeit werden die Fahrzeuge mit möglichst vielen Sensoren ausgestattet, um sich selbstständig einen Weg durch den Verkehrsdschungel zu bahnen. Das Vorgehen ist teuer und kompliziert. Der Vergleich zu Zügen und Flugzeugen zeigt, dass sich diese in einem geschützten Raum bewegen, der von außen kontrolliert wird. Zum Beispiel werden die Flughöhe und -route durch die Flugverkehrskontrolle geleitet und Züge automatisch gebremst, wenn sie in einen nicht freigegeben Bereich einfahren.

Nun lassen sich nicht alle Straßen einzäunen und Radfahrer aussperren. Doch Infrastrukturanpassungen, die dem Auto etwa an den Auf-/Abfahrten mitteilen, dass es sich auf der Autobahn befindet statt auf der fünf Meter entfernten parallelen Landstraße, würden das Problem der Positionserkennung vereinfachen. Ein anderes Beispiel ist das Parkhaus, das die Fernsteuerung übernimmt und das Fahrzeug zu einem freien Platz leitet. Dieses Konzept ist einfacher als Fahrzeuge, die selbstständig autonom durch das Parkhaus auf der Suche nach einem freien Platz irren.

Voraussetzung für diese Anwendungsfälle sind ein schneller und flächendeckender Ausbau des mobilen Datennetzes (5G) zum Datenaustausch mit Backend und Infrastruktur sowie die Möglichkeit, die Straßeninfrastruktur zeitnah an das autonome Fahren anzupassen.

Welcher Entwicklungsprozess kristallisiert sich heraus?

Wie lassen sich in diesen hochkomplexen Gesamtsystemen sowohl die Anforderungen der funktionalen Sicherheit und – besonders im Hinblick auf die zunehmende Vernetzung der Fahrzeuge – der Informationssicherheit erfüllen? Um hohe Qualitätsansprüche an die Softwareentwicklung im Automobil zu erfüllen, hat sich das Prozessmodell Automotive SPICE [8] flächendeckend etabliert und bilden die Basis für Safety und Security.

Der Sicherheitsstandard ISO 26262 definiert, wie sich die Aspekte der funktionalen Sicherheit in der Systementwicklung sowohl auf der Prozessebene als auch auf der Methodenebene umsetzen lassen. Für Softwarearchitekturen ist die funktionale Sicherheit ein entscheidender Einflussfaktor. Grundlegende Integritätsmechanismen wie Überwachung der Systemintegrität, Partitionierung, Zeit- und Ablaufüberwachung oder abgesicherte Kommunikation sind verfügbar und werden bereits in Serienprojekten eingesetzt.

Informationssicherheit ist seit längerem in der Automobilentwicklung relevant. So gehören Systeme wie eine Wegfahrsperre, sichere elektronische Schlüssel oder das abgesicherte Speichern des Kilometerstandes schon oft zur Grundausstattung. Doch die zunehmende Vernetzung der Fahrzeuge stellt die Industrie vor neue Herausforderungen. Gemäß der Grundregel der IT, "Was verbunden ist, das wird von Hackern angegriffen", rücken die Systemaspekte Informationssicherheit ("Security") und Datenschutz ("Privacy") auch in der Automobilindustrie stärker in den Vordergrund.

Die ersten erfolgreichen Angriffe auf Systeme über Remote-Zugriff oder das Internet sind mittlerweile bekannt und haben eine breite Reaktion hervorgerufen. Als Antwort darauf wurde Anfang dieses Jahres von SAE International ein Handbuch für die Entwicklung informationssicherer Systeme veröffentlicht (SAE J3061 [9], "Cybersecurity Guidebook for Cyber-Physical Systems"). Es beschreibt sowohl Prozesse als auch Methoden und orientiert sich beim Lebenszyklus an der ISO 26262. Zwar handelt es sich dabei um keinen Standard, das Dokument fasst aber wesentliche Bemühungen wie Forschungsprogramme oder bisherige Standards und Publikationen zusammen. Insofern ist es ein wertvoller Beitrag und kann als ein Einstiegspunkt für die Einführung von Prozessen und Methoden dienen.

Fazit

Die Anforderungen an die Architekturen für das autonome Fahren sind deutlich komplizierter geworden. Durch die Kombination von Aspekten wie Standardarchitekturen, funktionale Sicherheit, Informationssicherheit, Mehrkernsysteme und Verfügbarkeit ist es aber möglich, zuverlässige Systeme ("dependable systems") zu entwerfen und die einzelnen Systemaspekte je nach Anwendungsfall ideal zu gewichten und zu kombinieren.

Eine Kernkompetenz, die bei allen Beteiligten in der automobilen Zulieferkette aufzubauen ist, ist das Systems Engineering und damit das fachübergreifende Verständnis von der Physik über die Elektronik bis zur Software.

Für (Software-)Entwickler heißt dies, dass er in Zukunft mehr Systemverständnis mitbringen muss, um das Systemverhalten in entsprechenden Tools mit verknüpften Codegeneratoren zu modellieren. Die klassische Softwareentwicklung fokussiert sich auf die Entwicklung für Tooling und Codegeneratoren sowie Standardfunktionen, die als wiederverwendbare Produkte eingekauft werden. Für die Integration der Software werden weiterhin Spezialisten benötigt, die Fehler auf allen Ebenen von deeply-embedded bis serviceorientiertes Verhalten verstehen, analysieren und beheben können.

Neue Fahrzeughersteller und Zulieferer werden in den nächsten Jahren auf dem Automobilmarkt auftauchen. Insbesondere IT-Firmen setzen diese Technologien seit Jahren in anderen Bereichen ein und folgen der Vision, das Auto als Smartphone auf Rädern zu betreiben. Denn durch das autonome Fahren haben die Fahrzeuginsassen wesentlich mehr Zeit zur Verfügung, die sie beispielsweise zum Telefonieren, Lesen oder auch online Einkaufen nutzen können. Durch die Umwandlung von Fahrzeit in Internetnutzungszeit entstehen ganz neue Geschäftsmodelle.

Auch die Business Cases der OEMs werden zunehmend nicht nur durch den Verkauf, sondern durch den Betrieb des Fahrzeugs bestimmt. In der Diskussion sind beispielsweise neuartige Miet- und Leasingkonzepte, die nicht mehr das Auto als Produkt, sondern die Dienstleistung "Mobilität" zum Gegenstand haben. In Zukunft könnte es also sein, dass der Mietpreis der autonomen Transportkapsel, die einen zur Arbeit bringt, zu verschiedenen Tageszeiten unterschiedlich ausfällt.

Rudolf Grave
studierte Elektrotechnik an der TU Hamburg-Harburg. Seit 2005 arbeitet er bei Elektrobit und betreut AUTOSAR-Projekte. Der Schwerpunkt liegt dabei auf den Themengebieten Multicore und funktionale Sicherheit. (ane [10])

URL dieses Artikels:
https://www.heise.de/-3568991

Links in diesem Artikel:
[1] https://www.heise.de/hintergrund/AUTOSAR-Chance-der-Softwareentwicklung-im-Automotive-Bereich-861055.html
[2] http://www.autosar.org/
[3] https://de.wikipedia.org/wiki/OSEK-OS
[4] http://docs.projects.genivi.org/ipc.common-api-tools/2.1.4/Tutorial.html
[5] http://www.ieee802.org/1/pages/tsn.html
[6] https://www.elektrobit.com/products/eb-robinos/eb-robinos-specification/
[7] https://www.heise.de/hintergrund/Qualitaetssicherung-fuer-die-Software-im-Auto-mit-Automotive-SPICE-R-3-0-3029717.html
[8] http://www.automotivespice.com/
[9] http://standards.sae.org/wip/j3061/
[10] mailto:ane@heise.de

Copyright © 2016 Heise Medien