ESS — Emergency Steering Support: Zwei Jahre ADAS-Entwicklung
Knapp zwei Jahre, ein Ziel: Ausweichen in Notsituationen sicherer machen. Ein System, das Leben retten soll. Ein Thema das mich auf vielen Ebenen gefordert hat. Was sich dahinter verbirgt und was ich dabei gelernt habe.
Was ist ein Ausweichassistent?
Man stelle sich vor man ist auf dem Heimweg aus dem Büro, die letzte Nacht war kurz, der Arbeitstag lang ... die Erschöpfung ist einem ins Gesicht geschrieben. Auch wenn jeder weiß dass es nicht die beste Idee ist sich in so einer Verfassung ans Steuer zu setzen, ist es gesellschaftlicher Alltag auch dann den Heimweg im eigenen Auto anzutreten. Gerade an diesem Tag kann es passieren. Das Vorderfahrzeug bremst, ein Radfahrer kreuzt die Straße oder ein Fußgänger tritt ungeachtet auf vor das Auto. Alles passiert zu schnell, für eine Bremsung ist es vielleicht zu spät. In Sekundenbruchteilen muss ein Fahrer die Situation blitzschnell erkennen, einen freien Manöverraum identifizieren, ein entsprechendes Lenkverhalten umsetzen und dabei das Fahrzeug durchgehend in einem stabilen Zustand halten. In solchen Schockmomenten kommen auch geübte Fahrer an ihre Grenzen. Oft wird einfach irgendwie am Lenkrad herumgerissen und die Kontrolle über den Untersatz ist schnell verloren.
Die Idee hinter einem Ausweichassistenten ist, genau hier zu unterstützen: Ein geregelter Eingriff zur Verhinderung einer frontalen Kollision und das herannahende Hindernis sicher seitlich umfahren. Der Ansatz dahinter ist nicht, den Fahrer zu ersetzen, sondern seinen Reflex zu veredeln: Er hat bereits das Richtige getan — nämlich den Lenkimpuls gegeben - der Ausweichassistent sorgt dafür, dass es auch sicher ausgeht. (Hinweis: Da ein Fahrerassistenzsystem nicht selbstständig eine Längsregelung in diesem Ausmaß selbstständig durchführen darf, ist es notwendig, dass der Fahrer den Lenkimpuls gibt und somit das System aktiviert.)
Als Dienstleister waren wir in der Entwicklung dieses Systems von Anfang bis Ende vollständig eingebunden, von der Konzeptionsverfeinerung über die Implementierung bis zur kompletten Absicherung — in der Simulation (SiL), auf der Hardware (HiL) und direkt im Fahrzeug.
Softwaredesign und -architektur: Patterns, die ich diesmal wirklich genutzt habe
Ein System dieser Kritikalität zu entwickeln ist kein kleines Unterfangen. Sicherheitsanforderungen, komplexe Abhängigkeiten zwischen Komponenten und ein hoher Anspruch an Testbarkeit machen Struktur nicht optional — sie machen sie zwingend. Genau das macht solche Projekte aus Software-Engineering-Sicht so reizvoll: Der Anspruch ist hoch, und das Lernpotential entsprechend groß.
Die Codebasis die Stück für Stück aufgebaut wurde, stellte sich rückblickend als ein geeignetes Konstrukt heraus. Einer der Gründe dafür: der konsequente Einsatz bewährter Design Patterns. Einige davon waren mir bereits vertraut, andere habe ich persönlich zum ersten Mal wirklich aktiv in einem Produktionsprojekt eingesetzt.
Vertiefen konnte ich vor allem:
- Strikte Interface-Verwendung — konsequent durch alle Codeebenen
- Template-Methoden und -Klassen — für generische, wiederverwendbare Strukturen
- Factory-Pattern, oft in Kombination mit dem Builder-Pattern
- Decorators und Composites
Erstmals in Produktion genutzt habe ich:
- Visitor Pattern — zunächst abstrakt, am Ende ein echtes Werkzeug
- Facade Pattern — Komplexität kapseln und einfache Zugriffe schaffen
- Proxy Pattern — transparente Stellvertreter
Neben dem Einsatz dieser Patterns konnte ich mein Wissen in einer ganzen Reihe weiterer Bereiche ausbauen: Autosar als Automotive-OS, Franca als Modellierungssprache, Bazel als Build-System, Proto-definierte Strukturen, Codegenerierung, sauberes Testen mit Google Test (Mocks, Unit- und Komponententests), MCAP für Trace-Aufzeichnungen — und einiges mehr.
Eine echte Herausforderung: Degradation
Viel Zeit und Energie habe ich in das Degradationskonzept für den Ausweichassistenten gesteckt. Die Herausforderung war dabei nicht nur, ein einheitlich umsetzbares Konzept zu entwickeln und in alle Komponenten zu integrieren. Zuerst muss mit allen Input-Providern geklärt werden, welche Daten und Qualifier noch akzeptabel sind — und ab wann nicht mehr.
Nur mit diesem Wissen lässt sich zuverlässig bewerten, wann dem Fahrer eine sichere Ausweichunterstützung angeboten werden kann — und ab wann nur noch Rückfallebenen wie eine Notbremsung ohne Ausweichen greifen. Ein feiner, aber sicherheitskritischer Unterschied.
Weitere Themen, die das Projekt geprägt haben: die Integration von Parametern via Parameter-Server, Einhaltung und Tracking von SW-Qualitätsmetriken (Coverity, Coverage), und der Einsatz von Fuzzing für einzelne Teilkomponenten. Auf Tooling-Seite war das Spektrum ebenfalls breit: Docker, CANape, Carmen, Foxglove, Grafana, SonarQube.
Fazit
Am Ende steht ein System, das zu Teilen ASIL B und ASIL QM Anforderungen erfüllt — und das Ausweichen in Notsituationen messbar sicherer macht. Für mich persönlich steht aber vor allem eines: Es ist etwas anderes, Features für eine Applikation zu bauen, als an einem System zu arbeiten, das irgendwann in echten Fahrzeugen auf echten Straßen läuft — und im Ernstfall eingreift, bevor etwas Schlimmeres passiert. Das gibt dieser Arbeit ein Gewicht, das ich nicht missen möchte.