Roboterarchitekturen im Fahrzeug

Jedes der heute üblichen Assistenzsysteme lässt sich zwar gleichzeitig mit anderen Fahrerassistenzfunktionen ausführen, doch eine beabsichtigte Kooperation findet nicht statt. Die Lösung hierfür ist keine einfache Aufgabe, denn unter anderem fehlt eine passende, skalierbare Systemarchitektur, die alle Fahrerassistenzfunktionen im Fahrzeug abdeckt und einfach zu einem vollautomatischen System integriert.

Heutige Fahrerassistenzsysteme

Die heutigen Systeme sind – bestimmt durch Faktoren wie Kosten, Skalierbarkeit und Einbausituation – meist auf möglichst wenige Pakete im Fahrzeug verteilt und führen ausschließlich die ihnen zugedachte Aufgabe aus. Durch diese Anordnung lässt sich, unter anderem aufgrund der Nähe zu den relevanten Sensoren, viel Platz sparen. Gleichzeitig sind die einzelnen Funktionen voneinander unabhängig, was den separaten Verkauf an Endkunden ebenso vereinfacht wie den Einsatz verschiedener Zulieferer. Das bedeutet große Kostenvorteile für den Automobilhersteller. Auch das Testen der einzelnen Funktionen kann unabhängig voneinander erfolgen, was diesen Prozess erheblich vereinfacht und wenig Aufwand für die Integration der Funktionen untereinander verursacht. In der Landau-Notation für die Komplexität von Algorithmen in der Informatik beträgt die Komplexität für die Integration von n Funktionen bei dieser Vorgehensweise daher O(n).

Dieses Prinzip funktioniert sehr gut, solange die einzelnen Systeme weitgehend unabhängig voneinander agieren können und dem Fahrer lediglich assistieren. Sobald es jedoch darum geht, das Fahrzeug automatisch fahren zu lassen, ist eine Vernetzung der Systeme notwendig. Am vereinfachten Beispiel der zwei Funktionen Abstandsregeltempomat und Notbremsassistent lässt sich erkennen, wie schnell die Komplexität ansteigt, wenn viele verschiedene Funktionen untereinander kommunizieren müssen.

Schon die Koordination zwischen Brems- und Motorsteuergerät verdeutlicht die Komplexität in der Kommunikation beider Systeme. Elektrobit

In diesem Fall benötigen die Steuergeräte ein Koordinator-Modul, das verhindert, dass sich die Funktionen gegenseitig behindern. Sollen bei diesem Systemaufbau die Funktionen in verschiedenen Kombinationen verfügbar sein, so wächst der Aufwand für das Testen und die Zertifizierung aller möglichen Kombinationen exponentiell – die Komplexität für k Systeme wird dabei ausgedrückt durch O(2k-1). Auch der Einsatz von Modulen verschiedener Zulieferer, wie es meistens der Fall ist, erschwert den Prozess oft noch.

Aktuelle Trends

Um diese Komplexität zu beherrschen, geht der aktuelle Trend in der Automobilindustrie dahin, zentrale Steuergeräte für jeweils ein Aufgabengebiet wie zum Beispiel Fahrerassistenz zu entwickeln. Zur Fusion verarbeitet ein Steuergerät die Sensordaten zunächst zentralisiert und stellt sie dann, je nach Bedarf, mehreren Funktionen zur Verfügung. Der Vorteil dabei ist, dass der Automobilhersteller eine Trennung von Hardware und Software erreicht, interessanterweise unter Beibehaltung einer Verantwortungsteilung nach Steuergeräten. Damit wachsen zwar die Möglichkeiten zur Optimierung der Zuliefererwahl, doch die Skalierbarkeit sinkt, da das zentrale Steuergerät in jedem Fall verbaut werden muss, unabhängig von der ausgewählten Funktionskonfiguration durch den Endkunden. Die Komplexität hingegen steigt, denn zusätzlich zu der Integration der Funktionen untereinander muss die Integration in das zentrale Steuergerät erfolgen. Daher können zentrale Steuergeräte nur eine Übergangslösung auf dem Weg zum automatisierten Fahren sein.

In der Softwareentwicklung sind verschiedene Mechanismen für den Umgang mit hochkomplexen Architekturen bekannt, wobei Abstraktion, Polymorphie und Standardisierung besonders vielversprechend für den Einsatz im Automotive-Umfeld sind.

Abstraktion

Wenn eine Softwarekomponente mit zu vielen Partnern kooperieren muss, ist es hilfreich, ein Modul zwischenzuschalten, das sich lediglich um diese Koordination kümmert. Im Fahrzeug könnte das beispielsweise ein Bewegungsmanager sein, der den Zugang zur Motorsteuerung und zum Bremssteuergerät abstrahiert. Dieses Modul nimmt Beschleunigungs- oder Verzögerungsbefehle von den Fahrerassistenzsystemen an, entscheidet aber nach einer eigenen internen Logik, welcher Befehl auszuführen ist und auf welche Weise dies erfolgen soll, beispielsweise eine Geschwindigkeitsreduzierung durch die Radbremse oder durch Einsatz der Motorbremse.

Ein Bewegungsmanager abstrahiert den Zugriff auf die Aktoren. Elektrobit

Dieses neue Modul verringert die Komplexität enorm, denn die Koordinator-Module für Motor und Bremse sind nicht mehr notwendig, nachdem ihre Aufgaben ebenfalls der Bewegungsmanager übernimmt. Vor allem aber müssen die Funktionen und die Aktoren jeweils nur noch einen Kommunikationskanal bedienen, nämlich den zum Bewegungsmanager. Damit verhält sich die Komplexität abhängig von der Zahl der Funktionen nicht mehr exponentiell, das heißt O(2k-1), sondern linear, also O(k). So kann auch eine große Anzahl von Systemen, wie sie für das automatisierte Fahren erforderlich ist, relativ einfach zusammenarbeiten.

Polymorphie

Aus der objektorientierten Systementwicklung stammt das Konzept der Polymorphie. Softwarekomponenten, die ähnliche Aufgaben übernehmen, auch wenn ihre internen Strukturen erheblich voneinander abweichen, sollen über die gleiche Schnittstelle mit der Außenwelt kommunizieren. Diese sogenannten Polymorphismen können auch in der Fahrzeugarchitektur von Nutzen sein, denn die Kommunikationswege bieten ein großes Potenzial zur Komplexitätsreduktion. Der Entwickler einer Softwarekomponente, die mit verschiedenen Partnern mit ähnlichen Befehlen kommunizieren muss, müsste dann nicht für jede Art von Befehl neuen Code schreiben, da sich eine standardisierte Schnittstelle für die Kommunikation mit verschiedenen anderen Komponenten nutzen lässt. Dadurch verringert sich die Komplexität von O(k) zu O(1).

Standardisierung

Noch einen Schritt weiter in der Komplexitätsreduktion geht die Standardisierung. Der Automobilhersteller kann bei seinen Ausschreibungen auf Standards referenzieren, sodass sich Funktionen und Module verschiedener Hersteller einfach gegeneinander austauschen lassen. Damit reduzieren sich die Entwicklungskosten und das Risiko, aber auch die Zulieferer und Komponentenentwickler profitieren. Mit einer standardisierten Schnittstelle lässt sich ein einmal entwickeltes Softwaremodul an mehrere Automobilhersteller verkaufen. Test- und Toolanbieter können sich bei der Wertschöpfung auf den Inhalt und weniger auf individuelle Schnittstellenanpassungen konzentrieren. Im Bereich der Automobilsoftware gehören Autosar und ADASIS zu den wichtigsten Standards, ebenso wie der zukünftige Sensoris-Standard für Cloud-basierte Mapping-Architekturen, dessen Entwicklung gerade beginnt.

Beispiel Autobahnfahrt

Die drei Konzepte Abstraktion, Polymorphie und Standardisierung wendet man in der Softwareentwicklung in den unterschiedlichsten Bereichen bereits seit langem an. Doch wie sieht das im Automobil aus? Letztendlich ist ein automatisiertes Fahrzeug nichts anderes als ein autonomer, mobiler Roboter. Das Fahrzeug muss Folgen komplexer Handlungen ausführen, um sich im Straßenverkehr zu bewegen. Für die Fahrt auf der Autobahn muss eine solche Folge zum Beispiel sicherstellen, dass das Fahrzeug einem vorausfahrenden Auto folgt und dabei die Spur hält. Ein Überholvorgang soll dann erfolgen, wenn das vorausfahrende Auto zu langsam wird und die linke Spur frei ist. Nach dem Überholen soll das Fahrzeug wieder auf die ursprüngliche Spur zurückkehren, und wenn die Spur blockiert ist und keine andere Spur frei ist, eine Notbremsung durchführen.

Dafür benötigt das Fahrzeug erstens ein präzises Abbild seiner Umgebung mit Hindernissen, Spurmarkierungen und anderen Verkehrsteilnehmern, und zweitens muss es dazu in der Lage sein, seine Längs- und Querführung auf eine für die Insassen möglichst komfortable Weise auszuführen. Dazu ist die Koordination vieler verschiedener Sensoren und Fahrzeugfunktionen notwendig, was eine höchst komplexe Aufgabe darstellt. Mit diesen Abstraktionen auf Steuergeräteebene lässt sich durch den Bewegungsmanager und die Sensordatenfusion die Komplexität stark verringern. Übrig bleibt ein Funktionsumfang, den man sinnvollerweise in kleinere, besser beherrschbare Teile aufteilen möchte.

Zwischen der Abstraktion von Sensordaten und Bewegungsmanager liegt ein Funktionsumfang, den es in kleine Teile aufzuteilen gilt. Elektrobit

Roboterarchitekturen im Fahrzeug

Ein aktueller Ansatz hierfür ist eine Softwarearchitektur in der verhaltensbasierten Robotik, die gleichzeitig Funktionen aktiviert, die verschiedene Teile des Roboters bewegen, und dann die Ausgaben an die Aktuatoren zusammenfasst. Einfachere und komplexe Verhaltensfunktionen sind in dieser Architektur hierarchisch geordnet. Besonders wichtig ist, dass die Funktionen über standardisierte Schnittstellen verfügen, nämlich eine Eingangsschnittstelle für die Aktivierung oder Inhibition der Funktion, einen Ausgang für das Aktivitätslevel und einen Ausgang für das Rating. Dieser Rating-Ausgang macht eine Aussage über die Wahrscheinlichkeit, dass der Befehl der richtige für die aktuelle Situation ist. Mit diesem einfachen Systemaufbau ist es möglich, sehr komplexe Verhaltenssysteme zu modellieren, zu verwalten und zu überwachen.

Mit Roboter-Architekturen lassen sich sehr komplexe Verhaltenssysteme modellieren und überwachen. Albiez et al., A Behaviour Network Concept for Controlling Walking Machines, In: Adaptive Motion of Animals and Machines. Springer Tokyo, 2006. S. 237-246.

Eine solche verhaltensbasierte Roboterarchitektur ließe sich im Fahrzeug umsetzen, indem man den verbliebenen Funktionsumfang im Beispiel der Autobahnfahrt in eine Reihe von einfachem Verhalten aufteilt. Dazu kommt die Funktion „Safe State Handling“, die das Fahrzeug im Falle eines Systemausfalls verlangsamt und auf dem Seitenstreifen zum Stillstand bringt. Diese einzelnen Verhaltensfunktionen sind bereits als Spurhalteassistent, Abstandsregeltempomat und Notbremsassistent in aktuellen Fahrzeugen etabliert. Sie werden in einer verhaltensbasierten Architektur genauso funktionieren, nur ihre Schnittstellen ändern sich.

Aus Gründen der Sicherheit sind situationsabhängige Verhaltensfunktionen in ein Arbitrierungs-Framework eingebettet. Elektrobit

Da Anforderungen an die funktionale Sicherheit besonders im Automobilbereich eine große Rolle spielen, erhalten die Verhaltensfunktionen keinen direkten Zugang zum Bewegungsmanager, sondern sind in einen Arbitrierungs-Block eingebettet, der ihre Interaktionen steuert, überwacht und absichert. Dieser Block übernimmt noch eine andere Aufgabe: Er entscheidet anhand eines festgelegten Regelsatzes, wann welche Funktion zum Einsatz kommen darf. Diese Regeln sind situationsabhängig, so kann es beispielsweise unterschiedliche Verhaltensmuster geben für Situationen, in denen ein Fahrer selbst fährt, und für Fahrsituationen, die das Fahrzeug automatisch bewältigt.

In dieser Struktur gibt es für jede Verhaltensfunktion nur vier Kommunikationswege: zum Umfeldmodell, zum Bewegungsmanager, zum HMI und zum Arbitrierungs-Framework. Dank der standardisierten Schnittstellen in dieser Architektur ändert sich das nicht, unabhängig von der Anzahl der Verhaltensfunktionen, wodurch die Komplexität bei O(1) konstant bleibt.

Software-Verteilung und Autosar

Die hier beschriebene Architektur fokussiert sich auf das Thema Software, doch auch im Hardwarebereich bietet eine verhaltensbasierte Roboterarchitektur Optimierungsmöglichkeiten. Mittlerweile nutzen fast alle Steuergeräte im Fahrzeug eine Version von Autosar, die vor allem die Trennung von Hardware und Software ermöglichen sollte, was jedoch nicht in jeder Hinsicht passiert ist. Steuergeräte laufen zumeist mit Autosar-Basissoftware, auf der dann allerdings proprietäre Applikationssoftware aufsetzt. Einer der Gründe dafür könnte sein, dass für die Applikationssoftware nie so allgemeingültige Standards beschrieben wurden, dass man eine Softwarekomponente zwischen Steuergeräten austauschen konnte. Im Fahrerassistenzbereich haben Roboterarchitekturen das Potenzial, dies zu ändern. Sie spezifizieren nicht nur eine klare, funktionale Softwarearchitektur, sondern auch die Schnittstellen zwischen den Softwarekomponenten. Die Autosar-Spezifikationssprache ARXML ist dafür sehr gut geeignet, denn sie ermöglicht eine klare Beschreibung, Erweiterbarkeit und Portabilität der Komponenten, über Projektgrenzen hinweg und selbst zwischen Zulieferern und Herstellern. Hardwareseitig ermöglicht eine Autosar-konforme Basissoftware die Verteilung spezifischer Softwarekomponenten auf ein Netzwerk aus Steuergeräten und verbindet damit Software-und Hardwarearchitektur. Sie optimiert das System unter Berücksichtigung von Prozessor- und Speicherkapazitäten der ECUs, der Bandbreite und der Anforderungen der funktionalen Sicherheit.

Der Einsatz von standardisierten (Roboter-)Architekturen für das automatisierte Fahren löst viele Probleme. Eine verhaltensbasierte Roboterarchitektur kann die bereits vorhandene Hardware im Fahrzeug nutzen und durch das Autosar-basierte Mapping wird die Nutzung aller verfügbaren Kapazitäten sichergestellt. Die Architektur macht das System außerdem vollständig skalierbar, und durch die Verteilung von Funktionen auf einzelne Steuergeräte wird auch die Hardware skalierbar. Die Standardisierung der Komponenten und vor allem der Schnittstellen macht es schließlich einfach, zwischen verschiedenen Zulieferern zu wählen und so die Funktionalität und die Kosten zu optimieren.

Die Komplexität der Systeme ist eine der größten technischen Hürden auf dem Weg zum automatisierten Fahren. Der Einsatz von Roboterarchitekturen in Kombination mit Autosarist für die Lösung dieses Problems ein vielversprechender Ansatz. Standardisierte Systemarchitekturen und Softwaremodule gehen das Problem auf Industrieebene an und reduzieren die Komplexität bei der Entwicklung von automatisierten Fahrzeugen erheblich.

(pet)