Seite 2: Zentralrechner, Kommunikation

Inhaltsverzeichnis

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.

Mehr Infos

Auf heise Developer:

• AUTOSAR: Chance der Softwareentwicklung im Automotive-Bereich

Aktuell werden in den meisten Steuergeräten statisch konfigurierte Betriebssysteme eingesetzt, die nach dem AUTOSAR- oder OSEK-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 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) 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"-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.