Smart Cars: Wie beeinflussen Wirkketten das Fahrerlebnis?

ChatGPT beschreibt eine technische Wirkkette als „Reihe von aufeinanderfolgenden Prozessen, die innerhalb eines Systems auftreten und dazu führen, dass ein bestimmtes Ergebnis erzielt wird“. Heutige Fahrzeuge weisen eine Vielzahl von Wirkketten auf, um die immer größer werdende Zahl von Features umzusetzen. Mit dem Software Defined Vehicle (SDV) werden sowohl die Zahl als auch die Komplexität der Wirkketten steigen. Mit einher gehen Latenzen entlang der Wirkketten, die trotz vielfacher Rechenleistung zu bisher nicht gekannten Reaktionszeiten führen können. Deren frühe Betrachtung während der Entwicklung ist essenziell, damit das Fahrerlebnis nicht zur Enttäuschung wird.

Aber Latenzen werden den Siegeszug des SDV nicht aufhalten; zu stark sind die Vorteile nachladbarer Dienste über die gesamte Fahrzeuglaufzeit sowohl auf Hersteller- als auch auf Kundenseite. Gerne wird das SDV daher als Smartphone auf Rädern bezeichnet. Im Gegensatz zum Smartphone besteht das Fahrzeug aber auch aus sicherheitsrelevanten Systemen. Themen wie funktionale Sicherheit, Redundanzen und Latenzen sind für die Sicherheit von Passagieren und anderen Verkehrsteilnehmern eminent wichtig. Für deren Systemauslegung bedarf es einer konsistenten und geschlossenen Kette vom Anforderungsmanagement bis hin zur Freigabe. Inchron und EDAG haben dafür einen wirkkettenzentrierten Architekturentwurf entwickelt, mit dem sich das geforderte Echtzeitverhalten, die Ende-zu-Ende-Latenz oder kurz E2E-Latenz, schon früh im Entwicklungsprozess entlang der tatsächlichen kausalen Abhängigkeiten erfassen lässt. Echtzeitanforderungen können stets im Kontext des geforderten Sollverhaltens betrachtet, analysiert und getestet und deren Einhaltung über den Verlauf des gesamten Entwicklungsprozesses garantiert werden.

Zentralisierung und zonale Architekturen erhöhen die Latenz

Nachladbare Dienste sind mit herkömmlichen Architekturen nicht realisierbar, da Software dezentral auf dedizierten Electronic Control Units (ECU) verteilt ist. Zudem ist die Software sehr eng mit der Hardware der angeschlossenen Sensorik und Aktorik verzahnt.

Das Konzept des softwaredefinierten Fahrzeuges basiert darauf, nachladbare Dienste in einigen wenigen zentralen High Performance Computern (Zentral-HPC) zu vereinen. Um einen Dienst getrennt von der Hardware entwickeln zu können, bedarf es einer Middleware auf dem Zentral-HPC und zusätzlicher zonaler Mikrokontroller (Zone-µC), um elektrische Signale der Sensorik und Aktorik in hardwareunabhängige Ethernet-Signale zu transformieren.

Wirkketten wie im SDV lassen sich gut anhand ihrer Analogie zu einer Befehlskette auf einem Großsegler verstehen (Bild 1): jedes Manöver muss vor der Umsetzung erst eine komplexe Befehlskette durchlaufen. Die Entscheidungshoheit liegt zentral beim Kapitän. Die Luftschnittstelle, über die die Zurufe der Befehle auf dem Großsegler erfolgt, ist analog zur Kommunikation über Ethernet zu sehen: es folgen Latenzen und Arbitrierungseffekte. Nicht selten sind sogar unterschiedliche Manöveranforderungen gegeneinander abzuwägen.

Der Umstieg auf SDV-Architekturen bricht Wirkketten auf, die im klassischen Ansatz noch wegen der hohen Integration mit der Hardware und dem damit verbundenen geringeren Kommunikationsaufkommen funktioniert haben. Die Wege und Latenzzeiten verlängern sich, aber die Überwachung der Echtzeitanforderungen kann nicht mehr isoliert in der jeweiligen Domäne geschehen, sondern muss sich ganzheitlich über alle Features hinweg erstrecken.

Der Architekturentwurf von EDAG definiert ein Fahrzeug anhand von Features aus einer internen Datenbank und modelliert deren statisches Verhalten mithilfe von Wirkketten. In Kombination mit der Wirkkettenmethodik von Inchron lässt sich nun für jedes Feature ein von der Zielhardware unabhängiges logisches Verhaltensmodell aufbauen, im Folgenden logische Wirkkette genannt. Diese spezifiziert die kausalen Wirkzusammenhänge des Sollverhaltens. Harte Timinganforderungen für eine E2E-Latenz etwa aufgrund von Gesetzesvorgaben, Standards oder sicherheitskritischen Features, aber auch aufgrund der Kundenakzeptanz für bestimmte Wirkketten sind bereits in diesen logischen Wirkketten enthalten. Erste Wirkkettenanalysen und zu erwartende Latenzen können bereits sehr früh im Projekt erfolgen. Die so gewonnenen Informationen liefern die Grundlage für die Architektur.

In heutigen domänenbasierenden Fahrzeugarchitekturen spielen Latenzen eine eher untergeordnete Rolle und werden in der Regel nur bei Fehlverhalten von Prototypen oder Feldfahrzeugen näher betrachtet. Warum das so ist, zeigt Bild 2 anhand des Features Brake-By-Wire (BBW).

Durch den direkten Zugriff auf die elektrischen Eingabe- und Ausgabesignale lässt sich der Regler linear nach dem Eingabe-Verarbeitung-Ausgabe-Prinzip (hier: sense, think, act) meist in einem einzigen Task unterbringen. Die Samplingzeitpunkte aller vier Räder sind über die gemeinsame Clock des Mikrocontrollers perfekt synchronisiert.

Bild 3 zeigt nicht nur einen beispielhaften zeitlichen Verlauf eines solchen Reglers mit seinen Runnables, sondern veranschaulicht auch einen zentralen Aspekt der logischen Wirkkettenarchitektur: Jede logische Wirkkette beschreibt die kausalen Abhängigkeiten von Verarbeitungsschritten, die ausgehend von einem Startereignis für eine bestimmte Systemantwort in dieser Folge im System stattfinden müssen. In der Abbildung sind zwei Wirkketten dargestellt. Die rote Wirkkette zeigt den Brake-By-Wire-Fall. Dabei muss ausgehend von einer geänderten Bremspedalstellung bei t_start,BWW innerhalb der E2E-Anforderung t_E2E,BBW >20 ms eine entsprechende Änderung bis zum Aktuator erfolgt sein, was hier mit dem Ablauf der ersten Periode bei t_i=1 erreicht ist. Die Berechnung des Soll-Wertes für den Aktuator erfolgt in dem Runnable "BBW".

Allerdings kann dieser Wert noch nicht übernommen werden, weil das ABS-System ein eventuell blockierendes Rad freigeben können muss. Die zweite Wirkkette beschreibt deshalb die für das ABS relevante Abfolge von den Raddrehsensoren (wheel speed) bis zur Bremse. Die BBW-Wirkkette muss ebenfalls durch den ABS-Schritt geleitet werden, aber nicht umgekehrt. Für die Stabilität des Reglers ist die Software in eine zyklische Hardwaresynchronisation (IO-Trigger bei t_i=0 und t_i=1) eingefasst.

Ein völlig anderes Bild ergibt sich bei einer SDV-Architektur: An die Stelle der dedizierten ECU treten jetzt Zonen-µCs und ein Zentral-HPC. Die aus dem klassischen Ansatz bekannte Wirkkette bricht nun auf: „sense“ und „act“ werden auf die Zonen-µCs je Rad verteilt (Bild 4). Wegen der schnellen Reaktionszeit von ABS lässt sich nur BBW auf den Zentral-HPC verlagern. ABS muss in vier unabhängige Regelschleifen auf je einem Zonen-µC aufgetrennt werden.

BBW verliert durch die zusätzlich notwendige Kommunikation zwei Zyklen, kann aber noch die E2E-Latenz erreichen (Bild 5). Der aus Bild 3 bekannte Ablauf wird in den Zonen-µCs um die für das Senden und Empfangen notwendigen Middlewareanteile (hier: Rx und Tx) ergänzt. Für die ABS-Wirkkette ist das die einzige Änderung. Die BBW-Wirkkette allerdings vergrößert sich durch den Kommunikationsaufwand von einem auf drei benötigte Zyklen: zunächst muss die Bremspedalstellung erfasst und per Ethernet an den Zentral-HPC weitergegeben werden (hier: sig2 via Eth0). Dann erhält jeder Zonen-µC per separater Ethernetverbindung den neuen Sollwert für die Bremse, der schließlich in jeder Zone mit ABS abgeglichen werden muss.

Es ist schnell ersichtlich, dass eine naive Implementierung ohne Synchronisation zur Instabilität im Fahrzeug führen würde. Durch die Wirkkettenmethodik sind solche Anforderungen allerdings bereits in der logischen Architektur erfasst und können bei Designentscheidungen berücksichtigt werden.

Neben der reinen Verarbeitungszeit spielt aber auch das Datenalter diskreter Signale eine wichtige Rolle. So können aufgrund ungünstiger Abtastraten oder auch driftender Clocks eventuell „veraltete“ Signale verarbeitet werden und erst im nächsten Zyklus wird das korrekte Signal verarbeitet (Bild 6).

Das Beispiel zeigt, dass für das SDV die Betrachtung solcher Wirkketten bereits in frühen Entwicklungsphasen essenziell ist: je früher Latenzrisiken erkannt sind, desto einfacher und kostengünstiger ist die Lösung.

Ein Fahrzeug hat heute etwa 250 bis 450 Features, deren Modellierung Basis für die Ausleitung der Leitungssatzzeichnung und Kommunikationsmatrizen ist. Auf diesen Modellen werden nun etwa 700 bis 1400 Wirkketten definiert und mit einer E2E-Latenz als Timing-Anforderung versehen. Innerhalb der Wirkketten lassen sich nun für jedes Glied Timing-Budgets unterhalb der E2E-Latenz vergeben. Damit haben die technischen Wirkketten eine zusätzliche dynamische Prägung erhalten und sind konsistent zum restlichen Fahrzeugmodell.

Über eine gemeinsam entwickelte Schnittstelle lassen sich die Wirkketten inklusive Timing-Budgets zwischen PREEvision und dem Scheduling Simulator chronSIM bidirektional austauschen.

Da sich die Timinganforderungen aus logischen Wirkketten auf eindeutige, formal spezifizierte und somit im Zielsystem konkret beobachtbare Ereignisse beziehen, ist eine durchgängige Überprüfung begonnen mit der ersten Simulation bis hin zum Einsatz auf der Straße möglich. Umgekehrt können auch aus realen Testläufen gewonnene Daten in das Simulationsmodell zurückgespielt werden, um die Simulation weiter zu präzisieren. So spiegelt das Simulationsmodell stets den aktuellen Wissensstand über den kompletten Lebenszyklus wider und ermöglicht kontinuierliche Analysen.

Der wirkkettenzentrierte Architekturentwurf führt also zumindest für Latenzen zum garantierten Kundenerlebnis. Gleichzeitig sind Latenzen auch Gradmesser für die Umsetzung zentralisierter, hardwareunabhängiger oder sogar cloudbasierender Features. Der wirkkettenzentrierte Architekturentwurf ermöglicht es, Designentscheidungen hinsichtlich der Einhaltung von Echtzeitanforderungen zu bewerten und Fehlerquellen früh zu identifizieren. Für alle Features, die die geforderte E2E-Latenz einhalten, steht dem dynamischen Nachladen aus Latenzsicht somit nichts im Wege.

Danksagung: Diese Arbeit wurde teilweise vom BMBF im Projekt Mannheim-AutoDevSafeOps gefördert.