Moderne Fahrzeuge entwickeln sich zunehmend hin zu rollenden Computern – immer mehr Features basieren auf Software. Je komplexer solche „Software Defined Vehicles“ (SDV) werden, umso schwieriger wird es, das Timing im Griff zu behalten und übermäßige Latenzen („Totzeiten“) zu vermeiden. Mit der von EDAG und INCHRON entwickelten Toolchain lassen sich bereits in frühen Entwicklungsphasen die erwartbaren Latenzen kalkulieren und potenzielle Problemstellen identifizieren.
In den vergangenen Jahren wurde jedes neue Feature/ im Fahrzeug über ein eigenes, dezentrales Steuergerät (ECU: Electronic Control Unit) realisiert. Doch dieses Konzept stößt inzwischen gleich mehrfach an seine Grenzen. Bei 120 oder noch mehr ECUs pro Fahrzeug erreicht die elektrische und elektronische (E/E-) Architektur eine Komplexität, die kaum noch beherrschbar ist. Ein weiterer Nachteil: Neue Features sind nur mit einem erheblichen Aufwand und zum Modellwechsel möglich.
Der Endkunden erwartet aber eine Flexibilität, wie er sie von seinem Smartphone kennt. Daher braucht es eine Trennung von Hardware und Software. Die Lösung besteht darin, die Vielzahl der ECUs durch einige wenige zentrale High Performance Computern (Zentral-HPC) abzulösen, die alle wichtigen Software-Bestandteile als Apps hosten. Damit ist auch möglich nach dem Kauf das Fahrzeuge über die gesamte Lebenszeit neue Features zu erwerben oder in einem Abomodell zu mieten, das heißt das Fahrzeug bleibt immer „up to date“. Für die Trennung zwischen Hard- und Software sind zonale Mikrokontrollern (Zone-µC) zuständig, die die elektrischen Signale der Sensorik und Aktuatorik in hardwareunabhängige Ethernet-Signale transformieren.
Längere Wege schaffen Timing-Probleme
Der Einsatz zentralisierter Steuerzentralen im SDV hat jedoch auch einen nicht zu unterschätzenden Nachteil. Denn nun werden die Wirkketten, also die Reihe von aufeinanderfolgenden Prozessen, die innerhalb eines Systems auftreten und dazu führen, dass ein bestimmtes Ergebnis erzielt wird, ihrerseits komplexer: sowohl Zahl als auch Länge steigen an.
Besonders kritisch ist es, wenn dadurch die Latenzen sicherheitsrelevanter Funktionen ansteigen, also Verzögerungen, die durch zusätzliche Zeitglieder wie die Zone-µCs und Übertragung zum Zentral-HPC entstehen. Aber auch bei unkritischen und Komfortfunktionen, wie etwa beim Infotainment-System, sind Latenzen nur bis zu einem gewissen Grad für den Kunden akzeptabel. Träge reagierende Fahrzeugfunktionen und Bedienoberflächen sind Gift für die Kundenzufriedenheit
Eine Herausforderung ist es, mögliche Latenzen bereits im Entwicklungsprozess zu kalkulieren und Probleme zu erkennen. Hier kommt ein wichtiger Aspekt zum Tragen: Die Signalerfassung, -übertragung und -verarbeitung erfolgen nur scheinbar kontinuierlich. Tatsächlich erfolgt beispielsweise die Abfrage von Sensoren periodisch, die Datenverarbeitung auf der CPU in festgelegten Takten und auch die Übertragung in Netzwerken in Zyklen. 
Entlang der Wirkketten kann es daher passieren, dass an irgendeiner Stelle ein Signal knapp zu spät ankommt, so dass die Weiterleitung oder -verarbeitung erst in der nächsten Periode stattfindet – unter Umständen tritt dieser Effekt sogar mehrfach innerhalb einer Wirkkette auf, so dass sich die daraus entstehenden Wartezeiten zu einer unakzeptablen Ende-zu-Ende-Latenz (E2E-Latenz) addieren.
Latenzen frühzeitig unter Kontrolle
Um eine Systemauslegung zu erreichen, die definierte Latenzgrenzen einhält, 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 das geforderte Echtzeitverhalten – die E2E-Latenz – schon früh im Entwicklungsprozess entlang der tatsächlichen kausalen Abhängigkeiten erfasst werden kann. Echtzeitanforderungen können stets im Kontext des geforderten Sollverhaltens betrachtet, analysiert und getestet werden. So lässt sich deren Einhaltung über den Verlauf des gesamten Entwicklungsprozesses hinweg garantieren.
Dafür müssen mehrere Schritte ineinandergreifen. Der Architekturentwurf von EDAG definiert ein Fahrzeug anhand von Features und modelliert deren statisches Verhalten mittels logischer und physikalischer Wirkketten. Das EDAG-Modell wird aus PREEvision über ein ARXML-File an das von INCHRON entwickelte Tool chronSuite übergeben. Dort wird das Zeitverhalten simuliert und überprüft, ob die Vorgaben des statischen Modells in Bezug auf die E2E-Latenz eingehalten werden können oder nicht. Dabei werden auch Wechselwirkungen berücksichtigt, so dass es auffällt, wenn die Features für sich betrachtet zwar die Vorgaben erfüllen, sich jedoch gegenseitig behindern und so für Timing-Probleme sorgen.
Harte Timing-Anforderungen für eine E2E-Latenz, wie etwa aufgrund von Gesetzesvorgaben, Standards oder sicherheitskritischen Features, aber auch aufgrund von Kundenakzeptanz, können so bereits vor dem Aufbau des ersten Prototypenfahrzeug analysiert und optimiert werden. Erste Wirkkettenanalysen und zu erwartende Latenzen können bereits sehr früh im Projekt durchgeführt werden.
Praxisbeispiel BBW und ABS
Die so gewonnenen Informationen liefern schließlich die Grundlage für die Architekturauslegung eines SDV. Ein Beispiel liefern die beiden Wirkketten Brake-By-Wire (gelb) und ABS (rot) innerhalb der Systemgrenzen der BBW-ECU (durchgezogene Linien). Die gestrichelten Linien deuten an, dass die Wirkketten außerhalb dieses Systems weitere, in der Regel physikalische Stationen durchlaufen müssen. Hierzu gehört die Erfassung durch den Sensor, die bei zyklischer Abtastung nicht zeitgleich mit dem Eintritt des Startereignisses eintritt, aber auch die eigentliche Umsetzung im Aktuator.
Für die BBW-Funktionalität spielt der Verarbeitungsschritt ABS keine Rolle, umgekehrt aber schon, weil erst hier entschieden werden kann, ob eine Bremsvorgabe durch den Fahrer durchgestellt werden kann, oder ob zunächst ein höher priorisierter Request durch ein blockierendes Rad verarbeitet werden muss. Der Nutzen dieser strikten Trennung zeigt sich bei der Designentscheidung, wo ABS und BBW verortet werden sollen: wegen der schnellen Reaktionszeit von ABS kann nur BBW auf den Zentral-HPC verlagert werden. ABS muss in vier unabhängige Regelschleifen auf je einen Zonen-µC aufgetrennt werden.
Effizienz durch integrierte Toolchain
Das Beispiel zeigt: je früher Latenzrisiken erkannt werden, desto einfacher und kostengünstiger ist die Lösung. Für ein Software Defined Vehicle mit etwa 250 bis 450 Features lassen sich mit Hilfe der von EDAG und nun INCHRON entwickelten Toolchain etwa 700 bis 1400 Wirkketten definieren und mit einer E2E-Latenz als Timing-Anforderung versehen.
Im Rahmen dieser Toolchain ist es möglich, über eine gemeinsam entwickelte Schnittstelle die Wirkketten inklusive Timing-Budgets zwischen PREEvision und chronSUITE bidirektional auszutauschen. Somit können einerseits Scheduling-Analysen durch chronSIM in frühen Phasen durchgeführt werden, andererseits Traces durch chronVIEW in späteren Phasen ausgewertet werden.
Auf diese Weise lassen sich die nötigen Designentscheidungen für SDV bereits früh im Entwicklungsprozess so treffen, dass Latenzanforderungen sicher eingehalten werden – seien es zur Realisierung zentralisierter, hardwareunabhängiger oder sogar cloudbasierter Features. Sprich: sowohl sicherheitsrelevante Aspekte als auch solche der Kundenzufriedenheit werden damit abgedeckt.
Stehen auch Sie vor der Aufgabe, in Ihren Entwicklungsprojekten kritische Latenzen einzuhalten? Dann sprechen Sie mit unseren Experten von EDAG Engineering, Mario Maul, Experte für Architecture & Networks, und INCHRON, Florian Mayer, Timing-Experte für Automotive Embedded Software, wie der gemeinsam entwickelte wirkkettenzentrierte Architekturentwurf und die zugehörige Toolchain sowie das praktische Know-how der beiden Partner Ihre Entwicklungsprozesse im Umfeld von SDV effizienter machen können. Oder laden Sie sich gleich hier unser Whitepaper „So haben SIE die Latenzen im SDV im Griff (und nicht umgekehrt)“ herunter, das weitere Details zur Funktionsweise und den Mehrwerten dieser Lösung verrät. 
