Im Interview mit AEEmobility erklärt Thomas Kleinhenz, Director of Automotive System and Software Architecture bei Elektrobit, warum ein Framework basierend auf MATLAB und Simulink für Kunden ein unverzichtbares Werkzeug darstellt, um schnell und kosteneffizient zu einer serienreifen ECU für SDV zu gelangen.
Mit der Trennung von Hardware und Software in automobilen Architekturen wird der Lebenszyklus neuer Hardware-Architekturen länger, während Software in deutlich kürzeren Zyklen veröffentlicht wird und parallel mit vielen Generationen von Hardware umgehen kann. Ein wichtiger Aspekt bei der Systemdefinition ist die Bewertung, ob eine neue Software-Funktion auf einem bestehenden oder neuen System-on-Chip (SoC) bereitgestellt und ausgeführt werden kann. Aus diesem Grund bietet Elektrobit seinen Kunden ein Framework basierend auf MATLAB und Simulink, das dies ermöglicht.
AEEmobility: Herr Kleinhenz, was steckt hinter dem Konzept dieses Frameworks? Welchen Nutzen haben die Anwender?
Thomas Kleinhenz: Dieses Framework ergänzt die End-to-End Closed-Loop-Umgebung von Elektrobit in Software und Hardware für die modellbasierte Anwendungsentwicklung. Wir optimieren die Entwicklung softwaredefinierter Fahrzeuge, indem wir MATLAB und Simulink für die Erforschung innovativer Ideen und die Entwicklung von Softwarefunktionen, Integration und Verifikation von der Cloud bis zum SoC nutzen. Das Ziel des Frameworks, auch als „Target Picture“ bekannt, besteht darin, das Konzept eines softwaredefinierten Fahrzeugs effizient umzusetzen. Angenommen, Sie haben eine neue Idee für eine Fahrfunktion oder einen Algorithmus für automatisiertes Fahren. Die Herausforderung liegt darin, diese Idee direkt in das Fahrzeug zu integrieren, ohne unnötige Zwischenschritte wie das Erstellen neuer Spezifikationen oder das Durchlaufen mehrerer Prozesse.
In der Automobilindustrie wird zunehmend Virtualisierung und der Einsatz virtueller Steuergeräte (vECUs) genutzt, um tiefere Systemschichten oder das Betriebssystem zu modellieren. Die Frage ist jedoch, wie man diesen Ansatz so ergänzt, dass die Idee schließlich auf einem realen Steuergerät umgesetzt werden kann. Dies war der Ausgangspunkt unserer Überlegungen. Jede Firma wird dies unterschiedlich umsetzen, je nach ihren spezifischen Systemen und Methoden. Das übergeordnete Ziel bleibt jedoch dasselbe: Wie kann man eine Idee möglichst schnell, effizient und mit maximaler Wiederverwendbarkeit entwickeln, bis sie auf dem endgültigen System einsatzbereit ist? Für uns bildet Matlab/Simulink den Kern des Frameworks, das jedoch in einen umfassenderen Kontext eingebettet ist.
Thomas Kleinhenz ist Director of Automotive System and Software Architecture bei Elektrobit.
Wie kann das Framework Entwicklern dabei helfen, zu bewerten, ob eine neue Software-Funktion auf einer bestimmten Hardware ausgeführt werden kann?
Das hängt von der Situation ab. Bei einem Autohersteller, der bereits Fahrzeuge auf dem Markt hat, muss bei der Integration einer neuen Funktion auf die vorhandenen Ressourcen wie Speichergröße, Prozessorleistung und andere Abhängigkeiten Rücksicht genommen werden. Diese Parameter können modelliert und beschrieben werden. Gleichzeitig können algorithmische Funktionen gut charakterisiert werden, auch wenn die genaue Implementierung noch nicht vorliegt. Man weiß zum Beispiel, dass die Funktion bestimmte Datenblöcke verarbeitet oder komplexe Algorithmen ausführt. Solche Anforderungen können gut abgeschätzt werden, da bekannt ist, wie viele MIPS (Millionen Instruktionen pro Sekunde) und wie viel Speicher für bestimmte Operationen benötigt werden. Es reicht aus, zunächst grob zu verstehen, was die Funktion erfordert und welche Kosten damit verbunden sind. Wenn man die Anforderungen der Funktion und die zur Verfügung stehenden Hardware-Ressourcen kennt, kann man diese miteinander abgleichen. Falls die bestehenden Hardware-Ressourcen nicht ausreichen, muss die Funktion gegebenenfalls vereinfacht werden.
Ein interessanteres Szenario tritt auf, wenn eine neue Plattform oder ECU entwickelt wird. In diesem Fall möchte man möglichst viele Funktionen darauf abbilden und gleichzeitig sicherstellen, dass auch zukünftige Funktionen implementiert werden können. Hier kann es zu einem Spannungsfeld zwischen Technik und Einkauf kommen. Es ist hilfreich, wenn Entwickler klar darlegen können, welche Prozessoren, Speicher und andere Ressourcen benötigt werden. Beim Software-defined Vehicle (SDV) ist dazu ein umfassendes Systemverständnis erforderlich, da, trotz der Bezeichnung „software-defined“, die Software letztlich auf Hardware laufen muss. Dieser Aspekt muss besonders berücksichtigt werden.
Ein drittes Szenario betrifft Autohersteller, die darüber nachdenken, eigene System-on-Chip (SoC) zu entwickeln. Hierfür sind präzise Kenntnisse der Anforderungen notwendig.
Die verschiedenen Levels der Virtualisierung.
Welche Vorteile bieten virtuelle ECUs?
Virtuelle ECUs ermöglichen es, die Abhängigkeit von physischer Hardware zu reduzieren. Bereits frühzeitig kann die Software-Entwicklung auf einer simulierten Hardware-Plattform beginnen, etwa einem Modell eines Prozessors wie einem ARM-Core, der erst in zwei oder drei Jahren verfügbar sein wird. Dadurch kann die Software bereits vor der Markteinführung der eigentlichen Hardware umfassend getestet und validiert werden. Dies bietet den Vorteil, dass beim Marktstart die neueste Hardware-Generation im Fahrzeug integriert ist, was wiederum die Möglichkeit schafft, das Fahrzeug langfristig mit neuen Funktionen und Updates zu versorgen.
„Die Grundlage von Software-Defined Vehicles (SDV) wird durch die Integration des Elektrobit-Frameworks mit MATLAB/Simulink ermöglicht. Dieses Framework ermöglicht eine durchgängige und schnelle Umsetzung – von der Erforschung innovativer Konzepte über die Entwicklung und Integration von Softwarefunktionen bis hin zur Verifizierung. Dabei gewährleistet es nahtlose Abläufe, sowohl in der Cloud als auch direkt auf dem System-on-Chip (SoC), in virtuellen sowie realen Umgebungen.„
Wie überbrückt das Framework die Lücke zwischen Simulation, virtueller Validierung und realen Tests?
Es ist entscheidend, dass der Übergang zwischen den verschiedenen Phasen – von der Simulation über die virtuelle Validierung bis hin zu den realen Tests – nahtlos verläuft. Es darf keinen Medienbruch geben. Ich muss in der Lage sein, flexibel zwischen den Welten zu wechseln. Sobald meine Applikation entwickelt und die Zielplattform festgelegt ist, sollte ich entscheiden können, ob ich die Validierung auf virtueller Hardware durchführe oder auf die tatsächliche Hardware wechsle. Dieser Prozess muss reibungslos funktionieren.
Welche Herausforderungen ergeben sich bei der Nutzung von virtuellen ECUs, insbesondere in Bezug auf die detaillierte Nachbildung von Hardware-Charakteristika?
Es gibt Grenzen dessen, was virtualisiert werden kann. Besonders bei der Nachbildung von thermischen Eigenschaften wird es anspruchsvoll, da bei immer komplexeren Operationen die Verlustleistung stärker ins Gewicht fällt und detailliert betrachtet werden muss.
Virtuelle ECUs ermöglichen es, die Abhängigkeit von physischer Hardware zu reduzieren. Bereits frühzeitig kann die Software-Entwicklung auf einer simulierten Hardware-Plattform beginnen, etwa einem Modell eines Prozessors wie einem ARM-Core, der erst in zwei oder drei Jahren verfügbar sein wird.
Welche Rolle spielt der OEM künftig bei der Systembeschreibung?
Das Ziel ist, einen „Shift Left“ zu erreichen. Häufig entwickeln die verschiedenen Zulieferer parallel ihre Komponenten, ohne dass frühzeitig aufeinander abgestimmt wird. Erst später, wenn alle zusammenkommen, zeigt sich, ob die Komponenten wirklich miteinander funktionieren. Stellt man dann fest, dass das Zusammenspiel nicht klappt, entsteht ein massives Integrationsproblem, das unter großem Zeitdruck behoben werden muss. Diese ineffiziente und energieaufwendige Vorgehensweise kann dazu führen, dass ein Fahrzeug zu spät auf den Markt kommt.
Um das zu vermeiden, muss der OEM bereits frühzeitig das Gesamtsystem durchdenken: Wie ist es aufgebaut? Welche Schnittstellen und Komponenten sind erforderlich? In einer simulativen Umgebung wie Matlab/Simulink lässt sich dies verifizieren, sodass ein solides Grundgerüst für das System entsteht. Dabei müssen noch nicht alle Details der Komponenten feststehen, aber die grundlegenden funktionalen und nicht-funktionalen Anforderungen auf Systemebene – wie MIPS, Stromverbrauch, Speicher und Performance – sollten definiert sein. Sobald diese Grundlagen stehen, kann der OEM die Entwicklung an verschiedene Zulieferer delegieren, wobei die Interfaces, nicht-funktionalen Anforderungen und die Test- und Simulationsumgebung klar beschrieben sind. Dies ermöglicht einen schnellen und effizienten Entwicklungsprozess, bei dem das System bereits in einer frühen Phase quasi vorentwickelt ist.
Wieviel davon ist schon Wirklichkeit?
In der Industrie sind wir noch weit davon entfernt, da eine völlig andere Form der Zusammenarbeit zwischen OEMs und Zulieferern erforderlich ist. Es geht hier vielmehr um ein partnerschaftliches Modell. OEMs und Zulieferer müssen eng zusammenarbeiten, um solche Entwicklungsziele zu erreichen. Der traditionelle Top-Down-Ansatz, bei dem der OEM die Vorgaben macht und der Zulieferer leicht austauschbar ist, wenn er beispielsweise nicht günstig genug ist oder aus Compliance-Gründen ersetzt werden muss, funktioniert beim SDV nicht mehr. Ich denke, das ist ein wesentlicher Punkt.
Man muss sich auch fragen, warum gerade neue OEMs, die auf den Markt kommen, so schnell handeln können. Natürlich spielen die bestehenden Strukturen eine Rolle, aber es gibt sicherlich auch andere Ansätze, von denen wir lernen können, und auf die wir als europäische Industrie eine Antwort finden müssen. Ich glaube, die Lösung liegt in echten Partnerschaften, die gesamte Lieferkette betreffend. Nehmen wir zum Beispiel Unternehmen wie Elektrobit, Vector oder auch andere: Sie müssen sich stärker abstimmen. Es geht darum, ein funktionierendes Ökosystem zu schaffen, in dem konkrete Probleme gelöst werden können. Es gibt bereits Ansätze, wie beispielsweise Initiativen von Branchenführern, um mehr Kooperation zu fördern. Aber meines Wissens ist bisher noch nicht genug passiert. Hier muss deutlich mehr geschehen, auch um der Konkurrenzsituation aus China besser begegnen zu können.
Es ist entscheidend, einen hohen Wiederverwendungsgrad von Software und Testfällen zu erreichen. Mit einem Kooperationsmodell, wie bereits erwähnt, lässt sich sicherstellen, dass die Komponenten umfassend getestet sind, die Schnittstellen präzise funktionieren und Regressionstests zuverlässig durchgeführt werden. Ein OEM, der seine Lastenhefte an die Zulieferer verteilt, kann die schrittweise gelieferten Komponenten integrieren und mithilfe der entsprechenden Testfälle die Regressionstests durchführen. So entwickelt sich das System allmählich weiter, anstatt in einem großen, risikobehafteten Schritt.
Wie realitätsnah sind die virtuellen ECUs im Vergleich zur tatsächlichen Hardware?
Virtuelle ECUs kommen zwar sehr nah an die tatsächliche Hardware heran, aber es gibt immer noch Aspekte, die nur auf realer Hardware sichtbar werden. Es gibt Nebenläufigkeiten und Effekte, die sich in Simulationen nicht vollständig abbilden lassen. Daher wird es immer Testfälle geben, die direkt am Fahrzeug durchgeführt werden müssen. Dennoch können viele funktionale Tests im Vorfeld virtuell durchgeführt werden, sodass im Fahrzeug nur noch die funktionale Regression getestet wird. Dies ist besonders wichtig, wenn es um komplexe Funktionen geht. Bei ADAS und KI beispielsweise sind die Szenarien so komplex, dass sie durch reale Tests allein nicht mehr vollständig abgedeckt werden können.
Welche Herausforderungen gibt es bei der Wartung solcher virtueller ECUs über die gesamte Lebensdauer eines Fahrzeugs?
Das ist eine zentrale Frage. Dabei geht es nicht nur um die Pflege einzelner Softwarekomponenten, sondern auch um die gesamte Tool-Landschaft, die diese langfristige Wartung überhaupt ermöglichen muss. Wenn Software über Jahre hinweg gewartet werden muss, wie es beispielsweise von der UNECE-Cybersecurity-Regelung gefordert wird, bedeutet das, dass ich über einen langen Zeitraum sicherstellen muss, dass ich Sicherheitsupdates oder Bugfixes zuverlässig einspielen kann.
Was bedeutet das für die Werkzeugketten? Muss ich diese einfrieren, um sicherzustellen, dass ich sie in vielleicht acht Jahren wieder verwenden kann, um einen Fehler zu beheben? Das sind entscheidende Fragestellungen, für die es zwar Lösungsansätze gibt, aber eine umfassende Antwort bleibt bisher aus. Sicher ist, dieses Thema ist äußerst komplex und wird erheblichen Aufwand erfordern, insbesondere aufgrund der strengen gesetzlichen Vorgaben. Wenn diese Anforderungen nicht erfüllt werden, könnten Hersteller gezwungen sein, ihre Fahrzeuge vom Markt zu nehmen, wie es bereits in einigen Fällen geschehen ist. Ein konsistentes Konzept, das sicherstellt, dass Software und die zugehörigen Werkzeuge über einen langen Zeitraum hinweg verteilt und aktualisiert werden können, könnte hier Abhilfe schaffen. So lassen sich gezielt Probleme beheben, ohne das gesamte Fahrzeug überarbeiten zu müssen.
Es ist auch entscheidend, unser Verständnis der Systeme weiter zu vertiefen. Auf der Mathworks-Konferenz wurden bereits zentrale Lösungsansätze präsentiert, die dabei hilfreich sein könnten. Besonders durch die Einführung kollaborativer Frameworks zwischen Herstellern und Zulieferern könnten wir die Entwicklung, Integration und Testung von Funktionen deutlich beschleunigen.
In anderen Branchen sind Virtualisierung und Systemsimulation bereits fest etabliert und haben ihre Vorteile deutlich bewiesen. Dort werden systematische Simulationen und Modellierungen weit intensiver genutzt, und ich bin überzeugt, dass wir von diesen Erfahrungen profitieren können, um Prozesse in der Automobilindustrie effizienter und kostengünstiger zu gestalten. Möglicherweise benötigen wir eine ähnliche Brancheninitiative wie einst AUTOSAR, um gemeinsame Methodiken und Partnerschaftsmodelle voranzutreiben. Es gibt bereits zahlreiche vielversprechende Ideen und Lösungsansätze, die wir jedoch konsequent umsetzen müssen. Beim SDV brauchen wir ein tief gehendes Verständnis vom System.
Was sind Ihrer Meinung nach die wesentlichen Punkte für eine erfolgreiche SDV-Entwicklung?
Bei der Entwicklung von Software-defined Vehicles ist die präzise Analyse der Machbarkeit für die Ausführung eines Anwendungsfalls auf abstrahierter Hardware unerlässlich. Der Weg zum Erfolg führt über eine umfassende Simulation, die sowohl funktionale als auch nicht-funktionale Anforderungen detailliert ableitet. Ebenso unverzichtbar ist die präzise Schätzung und Charakterisierung von Systemparametern wie der optimierten Abtastrate von Funktionen, den benötigten MIPS, dem Speicherbedarf und dem Stromverbrauch. Darüber hinaus müssen die Schnittstellen klar definiert werden – dies umfasst sowohl die Bandbreitenanforderungen als auch die Integration von Drittanbieter-Software. Eine frühzeitige Integration dieser Schnittstellen und Bausteine ist letztlich entscheidend, um reibungslose Abläufe zu gewährleisten. Und schließlich muss ein robustes Testgerüst etabliert werden, das die Produktionssoftware umfassend verifiziert, um die Qualität und Funktionalität sicherzustellen. (oe)
Herr Kleinhenz, ich danke Ihnen für das Gespräch!
Das Interview führte Klaus Oertel, Chefredakteur der AEEmobility.
Zum Vortrag von Thomas Kleinhenz auf der Mathworks-Konferenz
