Beim Übergang zum Software Defined Vehicle (SDV) sind viele Hürden zu nehmen. Eine davon ist das ‚Verheiraten‘ unterschiedlicher Sensordaten. Bei aktuellen Timing-Konzepten ist nicht sichergestellt, dass immer die aktuellsten Daten bei der Sensor-Fusion verwendet werden. Rudolf Dienstbeck, System Engineer bei Lauterbach, sieht dringenden Handlungsbedarf und plädiert für einen Paradigmenwechsel. Nur so könne eine deterministische Abarbeitung der Steuerungssoftware auch in komplexen Automobilarchitekturen sichergestellt werden.
Warum ist das Timing für Entwickler in der Praxis zum Problem geworden?
Rudolf Dienstbeck: Etablierte Verfahren zur Gewährleistung des richtigen Timing-Verhaltens können mit den Auswirkungen des Trends zur Konsolidierung und der damit einhergehenden hohen Komplexität der Software sowie den verwendeten Softwaremethoden schlicht nicht mehr mithalten. Sie wurden, wie der Debug- und Timing-Standard OSEK RunTime Interface (ORTI), zum Teil in den 90er-Jahren eingeführt, als es noch um die Entwicklung von einzelnen ECUs für die Steuerung der Motoren oder Bremsen mit überschaubaren Funktionsumfang und Softwareinhalten ging. Die Abtastung und Verarbeitung der Parameter wie z.B. des Kolbenhubs erfolgte in einem Millisekundenzeitraster, in dem die ganze Funktionalität – im Wording des AUTOSAR-Standards die Runnables – untergebracht werden mussten. Entsprechend verfolgten Entwickler die Strategie, die Verarbeitung und Datenweiterleitung so schnell wie möglich zu machen. In der Praxis führte das aber dazu, dass immer mehr hin- und hergeschoben werden musste, damit das Ganze überhaupt irgendwie funktioniert hat.
Wie haben die Ingenieure bei OEMs und den Zulieferfirmen die Timing-Probleme bislang adressiert?
Über viele Jahre wurden vergleichsweise einfachen Strategien angewendet. Die Ingenieure haben das Timing der ECU mathematisch fast ausnahmslos schlicht durchgerechnet. Ausgangspunkt war dabei im Datenblatt angegebene Worst Case Execution Time (WCET) des eingesetzten Controllers. Mit einem Debug- & Tracing-Tool wurde dann nur noch geschaut, ob die Rechnung auch richtig war.
Dieses Vorgehen ist auch heute noch verbreitet.
Was spricht gegen dieses verbreitete Vorgehen?
Ein Problem der mathematischen Timing-Berechnung ist, dass bei unerwünschtem Verhalten kaum die Wirkungskette ermittelt werden kann. Alleine schon deshalb, weil in der Regel keine Trace-Aufzeichnung aufgesetzt wird.
Zudem ist ein Berechnen des Timings aufgrund der steigenden Komplexität der Chips und der Software sowie der Nutzung von Verfahren, wie DMA-, Cache- und Flash-Zugriffe oder Out-of-Order Execution, die alle nicht mehr deterministisch sind, praktisch nicht mehr möglich.
Rudolf Dienstbeck ist Mitglied der AUTOSAR Working Group Resources, die u.a. für Timing-Aspekte bei Automotive Embedded Systems im AUTOSAR Consortium zuständig ist. Er hat zuvor schon am ORTI-Standard mitgearbeitet und später ARTI mitinitiiert. ©(jr)
Wie versuchen das die Ingenieure zu lösen?
Häufig wird bei Timing-Problemen einfach auf einen schnelleren Chip gesetzt. Mit dem Trend zum SDV und dem Wunsch, möglichst viel auf einem Chip zu integrieren, stößt diese Strategie aber an ihre Grenzen. Die Software wird dabei einfach so komplex, dass es zu ‚Ausrutschern‘ kommen kann, deren Auslöser nicht mehr zu identifizieren sind.
Aber noch problematischer an den bisher verbreiteten Methoden zur Ausgestaltung des Timings ist, dass nicht ausgeschlossen ist, dass in Entscheidungen, die auf möglichst aktuellen Daten getroffen werden sollten, veraltete Daten Eingang finden können. Was bei Komfortfunktionen vielleicht noch hinnehmbar ist, ist bei sicherheitskritischen Systemen nicht mehr tolerabel.
Können Sie das etwas konkreter erklären, warum z.B. bei einer Sensorfusion die Gefahr besteht, dass veraltete Daten einfließen?
Wie erwähnt, ist es bislang üblich, Daten nach deren Verarbeitung in einem Knoten möglichst schnell an den nächsten Knoten weiterzugeben. Aufgrund von unterschiedlichen Verarbeitungs- bzw. Laufzeiten, die zudem variieren können, ist es möglich, dass Sensordaten mit einem älteren Zeitstempel, diejenigen mit einem jüngeren ‚überholen‘. Bei den angestrebten heterogenen Systemarchitekturen mit z.B. unterschiedlichen Domain-Controllern und der wachsenden Zahl der Datenquellen wird die Wahrscheinlichkeit für derartige Timing-Probleme noch größer.
Wie können Ingenieure die Timing-Herausforderungen bei diesen modernen Architekturen bewältigen?
Das geht nicht mehr ohne einen Paradigmenwechsel: Weg von einer Timing-Planung auf Basis der Worst Case Execution Time, also von Codelaufzeiten, hin zur Logical Execution Time (LET), also zu Datenlaufzeiten. Anders gesagt: Es werden Zeitscheiben für Daten definiert. Dabei werden die Daten von einem Knoten im Netzwerk nicht mehr weitergeschickt, sobald die Verarbeitung abgeschlossen ist, sondern erst mit dem Ablauf der zuvor definierten Logical Execution Time bzw. mit dem Beginn der nächsten Zeitscheibe. Es ist also unerheblich, wann die Daten innerhalb dieser Zeitscheibe abgearbeitet werden. Wichtig ist nur, dass dies innerhalb der Zeitscheibe erfolgt und dass die Daten erst am Ende der LET weitergereicht werden. Damit ist klar, dass die LET immer länger sein muss als die WCET.
Unsere Beobachtung ist, dass wir immer häufiger Feuerwehr spielen müssen, weil Ingenieure mit den Zeitbudgets nicht mehr zurechtkommen und sie Effekte beobachten, die sie nicht erklären können. ©(jr)
Das heißt aber auch, dass ich mich als Entwickler auch bei Rückgriff auf das LET-Konzept um das physikalische Timing kümmern muss, oder?
Auch LET erfordert hier ein sorgfältiges Design. Ich muss mir als Entwickler Gedanken über meine Datenpakete machen und in welcher Zeit sie verarbeitet werden müssen sowie wann ich sie zeitlich übergebe – unabhängig von der Implementierung. Es geht also darum, dass die Software eine Form der LET-Implementierung enthält.
Welche LET-Implementierungen werden wir in der Praxis sehen?
Da gibt es mehrere Möglichkeiten. Eine ganz einfache Variante ist die Verwendung einer globalen Variable, die erst am Ende einer LET-Zeitscheibe beschrieben und am Anfang der nächsten gelesen wird.
Eine praxisnahe Variante wird sein, dass es einen LET-Treiber gibt – einen eigenen Task, der nur für die Datenübergabe bzw. Datenverteilung zuständig ist, also die Daten am Ende der LET entsprechend weitergibt. Die einzelnen Tasks sind mithin nicht mehr selbst dafür zuständig, die Message an den nächsten Task weiterschicken, sondern ein Task sagt, meine Daten sind fertig, und schickt die Daten an den LET-Task und dieser leitet die Daten dann zum Ende der LET an den nächsten Task. Der Treiber muss auch ein Fehlerhandling beinhalten. Die Datenintegrität steht bei diesem Konzept an vorderster Stelle. Selbstverständlich hat auch LET physikalische Laufzeiten der Tasks. Da der LET-Task aber ‚nur‘ Datenkonsistenz und -weitergabe behandelt, ist die Laufzeit im Idealfall – bei entsprechender LET-Implementierung – vernachlässigbar.
Info-Kasten: Jitter und Interferenzen als Grund für fehlenden Determinismus
Bild 1: Jitter und eine Interferenz bewirken, dass der 3. Job in der dritten Hyperperiode noch keine aktuellen Daten der Task 1 erhält. ©Kai Gemlau
Ohne LET liest ein periodischer Task seine Eingabe zu Beginn und schreibt die Ausgabe am Ende seiner Ausführung. Dies war das vorherrschende Modell für Echtzeitaufgaben. Infolgedessen kann sich ein Jitter in der Ausführungszeit auf den Datenfluss zwischen den Tasks auswirken, wie in der Abbildung dargestellt. Die Farben Grün, Blau und Rot illustrieren den Datenfluss zwischen dem 20ms-Task und dem 5ms-Task. Während der dritte Job des 5ms-Tasks (jeweils orange markiert) in den ersten beiden Hyperperioden frische Daten (aus derselben Hyperperiode) liest, liest er in der letzten Hyperperiode ältere Daten (das blaue Muster). Dieser nicht-deterministische Datenfluss wird durch die Aktualisierung eines fremden Tasks verursacht, die das Laufzeitverhalten des 20ms-Tasks beeinflusst. Während dies bereits bei einer Einzelimplementierung problematisch ist, wird es bei dynamischen Architekturen noch dringlicher.
Eine Aktualisierung oder Änderung in einer völlig anderen Funktion kann aufgrund der gemeinsamen Plattform zeitliche Interferenzen verursachen und sich auf den Jitter der Ausführungszeit des Tasks auswirken.
Quelle: Kai-Björn Gemlau; Hermann v. Hasseln; Rolf Ernst: “Industry-track: System-Level Logical Execution Time for Automotive Software Development”; Proceedings of the 2022 International Conference on Embedded Software (EMSOFT)
Gibt es schon OEMs, die LET in ihren Softwarearchitekturen nutzen?
Mercedes arbeitet schon seit über zehn Jahren zusammen mit der TU Braunschweig an der Entwicklung entsprechender Softwarelösungen. Das Ergebnis dieser Arbeit ist nicht nur in das Mercedes-Flagship EQS eingeflossen, sondern bis auf Ausnahme des EQC in die Baureihen mit EVA1.5 und EVA2-Architekturen. In den restlichen Modellen der EQ-Baureihe und in allen zukünftigen Baureihen inkl. AMG, wird LET im zentralen Domänen-Controller des Powertrains eingesetzt.
BMW hat sich auch schon frühzeitig mit dem Timing beschäftigt und den TIMEX-Standard innerhalb von AUTOSAR vorangetrieben.
Zur Erinnerung: TIMEX gibt es seit vielen Jahren. Dieser Standard wurde eingeführt, um Timing Requirements im Rahmen des AUTOSAR-Standards erstellen zu können. Bei der Mehrheit der Zulieferunternehmen ist das Thema Timing aber noch nicht wirklich im Fokus – es wird oft nur darauf geschaut, dass die Steuerungssoftware irgendwie läuft.
Apropos AUTOSAR. Was sagt der Standard zu LET und zum Tracen?
Für AUTOSAR gibt es erst seit 2019 das Autosar Runtime Interface – kurz ARTI, der das Aufzeichnen, Debuggen und Tracen standardisiert. Bis zu dessen Einführung mussten Entwickler auf ORTI zurückgreifen. Selbst dieser Standard wird heute immer noch benutzt, auch wenn er inzwischen völlig veraltet ist. System-level LET, wo im Gegensatz zu LET mit »Zero Time Communication« – die Zeit für die Datenübergabe wird vernachlässigt – die Datenübergabe explizit mit modelliert wird, ist mit Release 22-11 von AUTOSAR in den TIMEX-Standard eingeflossen. Bei AUTOSAR AP soll LET konkret erst mit Release 24-11 implementiert werden. Allerdings dauert es in der Regel mindestens fünf weitere Jahre, bis das dann in die Entwicklungen einfließt.
Info-Kasten: LET und System Level LET (SL-LET)
Bild 2a: Beispiel einer verteilten Architektur, die den Wechsel von LET zu System Level LET erfordert. ©Kai Gemlau
LET ist mit einigen grundlegenden Einschränkungen verbunden. Erstens ist die Länge des LET-Intervalls konzeptionell durch seine Periode begrenzt. Ein LET-Intervall, das größer als die Periode ist, würde bedeuten, dass mehrere Jobs dieses Tasks parallel ausgeführt werden können.
Die korrespondierenden Clock-Zonen Z1, Z2, Z3 der Beispielschaltung aus Bild 2a lassen sich nicht perfekt synchronisieren. ©Kai Gemlau
Zweitens erlaubt LET keine verteilten Uhren. Für eine verteilte Plattform (ein Beispiel zeigt Bild 2a) ist eine perfekte Uhrensynchronisation nicht implementierbar, aber die verschiedenen Uhren (Bild 2b zeigt die korrespondierenden Clock-Zonen Z1, Z2, Z3 der Beispielschaltung aus Bild 2a) können bis auf einen begrenzten Fehler synchronisiert werden. Aufgrund dieser Einschränkungen ist LET auf den Bereich der ECU beschränkt.
SL-LET ist die Weiterentwicklung der LET-Idee für die Systemebene, um diese Beschränkungen zu überwinden.
Bild 2c: Die drei Hauptelemente des SL-LET-Konzepts. ©Kai Gemlau
Das Konzept umfasst drei Hauptelemente (siehe Bild 2c und 2v):
(A) Die Permitted Pipelining Property (PPP) erlaubt es, Systeme zu erfassen, bei denen das SL-LET-Intervall größer als seine Periode ist. Dies ist zum Beispiel relevant für lange Kommunikationslatenzen oder die Pipeline-basierte Verarbeitung von Daten in HPC Architekturen.
(B) LET-Zonen unterstützen die Bedeutung von SL-LET-Ereignissen in einem verteilten System, indem sie ein gemeinsames Verständnis von Zeit bzw. Uhren und deren Synchronisationsgenauigkeit bieten.
(C) Auf der Grundlage dieses gemeinsamen Zeitverständnisses werden SL- LET-Intervalle durch zwei SL-LET-Ereignisse abgegrenzt, die jeweils mit einer LET-Zone und damit einer bestimmten Zeitbasis verbunden sind.
Quelle: Kai-Björn Gemlau; Hermann v. Hasseln; Rolf Ernst: “Industry-track: System-Level Logical Execution Time for Automotive Software Development”; Proceedings of the 2022 International Conference on Embedded Software (EMSOFT)
Gibt es in den AUTOSAR-Standards auch verbindliche Vorschriften zur Implementierung?
LET ist wie das meiste im AUTOSAR-Standard nicht verpflichtend. Auch zur Implementierung selbst sagt AUTOSAR CP im Moment noch nichts. Es war schwierig genug, den Status quo zu erreichen. Es wird allerdings APIs geben, mit denen dann festgelegt wird, wie LETs und Messages in der Software anzugeben sind. Aber wie LET zu implementieren ist, wird wohl dem Anwender überlassen bleiben.
Das Ganze klingt für mich danach, dass eigentlich ein TOP-Down-Ansatz bei der Entscheidung für LET und dessen Implementierung zu verfolgen ist und letztendlich der OEM entsprechende Vorgaben machen muss!
Ja, das wäre die Aufgabe des Integrators. Es ist so gedacht, dass der Integrator das komplette LET-System implementiert. Die einzelnen Funktionen rufen nur die APIs auf. Und erst wenn dann die einzelnen Funktionen verheiratet werden, wird die LET implementiert. Ist die gewählte LET zu kurz, muss der Integrator allerdings gegebenenfalls Einfluss auf die Subsysteme nehmen können, um sie zu verlängern. Letztendlich geht es dabei auch darum, ob es die CPU schafft, die gewählte LET einzuhalten! Ohne einen Timing-Architekten wird es beim Integrator daher nicht gehen.
Wenn ich Ihre hier getroffenen Aussagen richtig interpretiere, sind es im Moment eher die Entwickler, die sich wegen zunehmender Timing-Probleme für das Thema LET interessieren?
Unsere Beobachtung ist, dass wir immer häufiger Feuerwehr spielen müssen, weil Ingenieure mit den Zeitbudgets nicht mehr zurechtkommen und sie Effekte beobachten, die sie nicht erklären können. Funktionen, die vormals auf separaten ECUs liefen, sollen heute auf wenigen Domainrechnern konsolidiert werden. Integratoren stehen im Feuer, wenn sie feststellen, dass die Steuerungssoftware in der Kombination nicht mehr funktioniert.
Beispiel: Ein größerer Automobilzulieferer hat sich an einem Freitag an uns mit der Bitte gewandt, einen Trace aufzusetzen, weil er festgestellt hat, dass sein System nicht mehr geht und er das Problem bis Montag beheben muss. Bis zu diesem Zeitpunkt wurde dort kein Timing aufgezeichnet, keinerlei Messung gemacht. Auch wenn das ein krasses Beispiel ist, bekommen wir fast täglich mit, dass es da an allen Ecken und Enden fehlt, weil das Ganze erstens nicht mehr durchrechenbar ist und die Manager zweitens sagen, dass eine CPU-Auslastung von 75 % aus Kostengründen ok ist. Mir sind Fälle bekannt, in denen eine Reserve von 10 % als ausreichender Sicherheitsabstand angesehen wurde. Nur nebenbei: Aus unserer Sicht sollte eher eine 50 % Auslastung angestrebt werden.
Was möchten Sie den Entwicklern in Bezug auf die Timing-Herausforderungen mit auf den Weg geben?
Ich kann nur empfehlen, von Anfang an eine Timing-Analyse einzuplanen. Da kommen wir zurück auf ARTI und TIMEX. Dort ist definiert, wie ich Trace-Punkte setze und wie die mit den TIMEX-Requirements zusammenhängen. D.h. ich definiere meine Timing-Requirements und die entsprechenden Trace-Punkte werden dann im Idealfall automatisch in den Code gesetzt.
Dann können die Entwickler mit unseren hardwarebasierten Tools den Code in Echtzeit mit einer Minimalinstrumentierung tracen. Wir bieten Lösungen für jeden Chip, der im Automotive-Bereich zum Einsatz kommt. Diese Werkzeuge erlauben aber auch eine erste Analyse z.B. der Laufzeiten oder der CPU-Last. Analysen und Statistiken liefern Informationen darüber, welches Runnable bzw. welcher Task die meiste Zeit gebraucht hat. Der Clou dabei: Wir können das auch unter Berücksichtigung der Auswirkungen, die das OS und darunterliegende Hypervisoren haben. Für viele Anwender genügt das bereits.
Für weitergehende Analysen, wenn z.B. das Timing gegen Requirements geprüft oder Event-Chain-Analysen durchgeführt werden sollen, arbeiten wir mit Partnern wie Vector zusammen. Wir exportieren unseren Trace in einem speziellen Format gemäß des ASAM-Standards. Tools der TA Tool Suite bzw. TA.Inspection können das einlesen und weiternutzen. LET bietet hier die Chance, das Timing von Automotive-Anwendungen von Anfang an in den Design-Prozess von komplexen Systemen mit einzuplanen. Entsprechende Standards und Tools stehen bereits zur Verfügung. Allerdings erfordert es auch ein Umdenken in der traditionellen Entwicklungsarbeit. (jr)
