In Teil 1 des großen AEEMobility-Interviews spricht Jim Tung, Fellow bei MathWorks, über die tiefgreifenden Veränderungen in der Fahrzeugentwicklung, die durch die Entkopplung von Hardware- und Softwarearchitekturen erforderlich werden. Er zeigt auf, wie die Fragmentierung zwischen System- und Softwareentwicklung aufgelöst werden kann und erläutert, warum der Einsatz von Simulation und Virtualisierung sowie offenen Schnittstellen und Standards Interoperabilität und konsistente Entwicklungsprozesse in der gesamten Organisation sicherstellt.
AEEmobility: Die alten Regeln des Automobilmarktes gelten nicht mehr. Die neuen Marktteilnehmer scheinen vorzugeben, wie Fahrzeuge definiert und entwickelt werden. Wie reagieren die etablierten OEMs darauf?
Jim Tung: Die etablierten Akteure sind gezwungen, sich an die neuen Spielregeln anzupassen.
Dies begann mit einer Veränderung der konventionellen Fahrzeugarchitektur, die sich über Jahrzehnte hinweg entwickelt und verbreitet hatte. Infolgedessen enthielten die konventionellen Fahrzeugarchitekturen der etablierten Automobilhersteller Hunderte von Steuergeräten mit dedizierten Mikrocontrollern. Das musste sich ändern.
Bislang sind die Hardware und Software dieser Steuergeräte so eng miteinander gekoppelt, dass es fast unmöglich ist, Funktionen regelmäßig zu aktualisieren. Auch das musste sich ändern.
Daher haben die OEMs an den E/E- und Softwarearchitekturen gearbeitet und auch daran, wie die Hardware auf technischer Ebene von der Software entkoppelt werden kann. Sie brauchen dies, um über die Software weitere Funktionen hinzufügen und diese drahtlos und auf flexiblere, modulare Weise aktualisieren zu können, ohne die erforderliche Zuverlässigkeit und Determiniertheit zu verlieren.
Jim Tung, Fellow
bei MathWorks. © The MathWorks, Inc.
Wie weit sind die etablierten OEMs mit dieser HW/SW-Entkopplung bereits vorangekommen?
Tung: Stand heute ist es den etablierten Akteuren bereits gelungen, Aspekte der E/E-Architektur und der Software voneinander zu entkoppeln, aber sie haben auch die Entwicklungsansätze voneinander entkoppelt, in gewisser Weise sogar zu sehr. Ich denke dabei an den Einsatz modellbasierter Entwicklungsmethoden in der ECU-Entwicklung. Diese etablierten Methoden haben es ermöglicht, Funktionen zu modellieren und den Code für die ausgewählte Zielhardware später im Entwicklungsprozess automatisch zu generieren.
Das Ergebnis lässt sich sowohl auf Code- als auch auf Modellebene leicht überprüfen. Dies hat sich positiv auf die Kosten, die Markteinführungszeit, die Reduzierung von Rückrufaktionen und andere KPIs ausgewirkt.
Die Entkopplung von Hardware und Software hat jedoch auch zu einer Verfestigung der Silos in den Automobilunternehmen geführt, mit unterschiedlichen Perspektiven und Ansätzen zur funktionalen Entwicklung.
Wo zeigt sich der Unterschied in der Denk- und Herangehensweise von Software- und Hardwareentwicklern?
Tung: Es lässt sich immer wieder beobachten, dass Software- und Systemdesigner unterschiedliche Ansichten, Arbeitsmethoden und Denkweisen haben oder Dinge sehr unterschiedlich interpretieren und bewerten.
Beispielsweise versteht ein Softwareentwickler unter „Shift-Left“, dass er seine Software früher entwickeln sollte, da die Softwareentwicklung ein relativ geradliniger Prozess ist.
Der Systemdesignprozess hingegen wird häufig anhand des V-Diagramms beschrieben. Ein Systemdesigner versteht das V-Diagramm als Darstellung von Verantwortungsbereichen, sodass beispielsweise Dinge, die zuvor auf der rechten Seite des V-Diagramms standen, auf die linke Seite verschoben werden können. Die Diskrepanz zur Softwareentwicklung ergibt sich aus der Tatsache, dass das V-Diagramm weniger eine chronologische Abfolge mit einer von links nach rechts verlaufenden Zeitachse darstellt, sondern vielmehr die Entwicklungsaufgaben strukturiert und Verantwortlichkeiten definiert.
Systemdesigner und Programmierer haben oft unterschiedliche Ansichten, Arbeitsmethoden und Denkweisen. Sie interpretieren daher das V-Diagramm und DevOps unterschiedlich. © The MathWorks, Inc.
Wie interpretiert ein typischer Softwareentwickler das V-Modell?
Tung: Ein Softwareentwickler setzt das V-Modell in der Regel mit dem Wasserfallmodell gleich, da er davon ausgeht, dass es eine Zeitachse von links nach rechts gibt – und manchmal zeigen ihre Systemengineering-Teams das V tatsächlich mit dieser Achse, was nicht gerade hilfreich ist. Da Softwareentwickler das Wasserfallmodell längst durch agile oder DevOps-Prozesse ersetzt haben, interpretieren sie das V-Modell fälschlicherweise als Rückschritt.
Die Systemexperten betrachten ihrerseits die von Softwareentwicklern bevorzugten Agile- und DevOps-Ansätze und verstehen nicht, wie sie die Hardwareentwicklung in Entwicklungsansätze integrieren können, die scheinbar softwarespezifisch sind.
Dieses Beispiel zeigt, dass die Kluft sehr groß ist und dass es zwei Silos gibt, die sehr unterschiedliche Denkweisen, Perspektiven, Prozessansätze, Werkzeuge und vieles mehr voneinander trennen.
Wir befinden uns daher in einer Situation, in der wir glauben, dass wir uns für das eine oder das andere Silo entscheiden müssen – wir leben also in einer binären Welt der „Entweder-oder“-Entscheidungen.
Die Frage lautet also: Wie können wir die beiden Silos wieder so zusammenführen, dass wir, um bei der Metapher zu bleiben, wieder in einer UND-Situation landen?
Tung: Ein Teil der Antwort ist die Simulation, die als Bindeglied dienen kann.
In beiden Silos wird Simulation oder Virtualisierung – im Grunde sind dies nur unterschiedliche Begriffe für dieselbe Funktion – als sehr nützlich angesehen und intensiv genutzt. Das Beste daran ist, dass dieselben Modelle und Simulationen, die von Systemingenieuren zum Entwerfen und Optimieren des Systemverhaltens verwendet werden, von Softwareteams als Testumgebung zum Überprüfen und Validieren der Software genutzt werden können.
Der Unterschied besteht darin, dass die Systemingenieure mit der Simulation interagieren, sie optimieren und feinabstimmen. Es handelt sich um einen Prozess, bei dem Menschen Teil einer kontinuierlichen Iterationsschleife sind und das Ziel darin besteht, das System zu entwerfen.
Auf der anderen Seite nutzt der Softwareentwickler diese Funktion auf andere Weise. Für ihn läuft die Simulation automatisch im Hintergrund als Teil der Testumgebung, wenn er seine Softwareänderung einreicht. Sein Ziel ist es, seine Software zu validieren, und er nutzt die automatisierte Ausführung des virtualisierten Systemverhaltens, um umfassende Tests seiner Software durchzuführen. Mit der Umstellung auf SDV müssen die verschiedenen Teams einen gemeinsamen Ansatz entwickeln, auch wenn sie teilweise unterschiedliche Begriffe verwenden, wobei sie sich darüber im Klaren sind, dass die Simulation des Systemingenieurs die Virtualisierung des Softwareingenieurs ist.
„Das Beste daran ist, dass dieselben Modelle und Simulationen, die von Systemingenieuren zum Entwerfen und Optimieren des Systemverhaltens verwendet werden, von Softwareteams als Testumgebung zum Überprüfen und Validieren der Software genutzt werden können.“ © The MathWorks, Inc.
Auch wenn sich die Erkenntnis an vielen Stellen durchgesetzt hat, dass Kooperation zielführend ist, klappt das in der Praxis bisher nicht so gut. Woran liegt das?
Tung: Ich stimme zu, dass oft die Erkenntnis vorhanden ist. Und es ist nicht die Verfügbarkeit von Technologie, die die Umsetzung verhindert. Es kann jedoch eine Herausforderung sein, von dieser Erkenntnis zu einem abgestimmten Ansatz zu gelangen, der die vorherrschenden Meinungen, Vorbehalte, Eigentumsrechte und Verantwortlichkeiten von Gruppen überbrückt, die sich im Laufe der Jahre in den einzelnen Domänenbereichen entwickelt haben. Manchmal gibt es auch Wissenslücken, die geschlossen werden müssen. Beispielsweise sind die Plattform-Engineering- oder DevOps-Teams, die CI-Pipelines und andere Infrastrukturen für die Softwareentwicklung einrichten, manchmal nicht damit vertraut, wie modellbasierte Tools effizient in ihre Pipelines integriert werden können. Wir arbeiten mit unseren Kunden zusammen, um dieses Know-how aufzubauen.
In vielen Fällen haben sich Systemteams in ihren isolierten Gruppen seit Jahren in Richtung agiler Arbeitsmethoden wie DevOps oder CI-Pipelines entwickelt. Veränderungen finden innerhalb einer Organisation auf verschiedenen Ebenen und auf unterschiedliche Weise statt. Es werden Fortschritte erzielt, die jedoch auf der Ebene der einzelnen Bereiche fragmentiert sind.
Dies führt manchmal zu widersprüchlichen Ansätzen und unnützen Aufwand, da verschiedene Gruppen versuchen, dasselbe auf unterschiedliche Weise zu erreichen.
Dieser Ansatz steht im Gegensatz zu den höheren Ebenen des Organisationsmanagements, die oft das Ziel verfolgen, eine Plattform aufzubauen, die von allen gemeinsam für die Entwicklung genutzt werden soll. Das Ziel ist es, durch groß angelegte Automatisierung und den Einsatz von Cloud- und HPC-Diensten Kosteneinsparungen zu erzielen und Prozesse zu systematisieren. Es ist also notwendig, diesen organisatorischen Auftrag mit den Ansätzen der Domänengruppen in Einklang zu bringen.
Es gibt daher organisatorische Herausforderungen hinsichtlich der Frage, wer für was verantwortlich ist. Es gibt auch Voreingenommenheiten, beispielsweise wenn eine Domänengruppe ein CI-System wählt und die zentrale Organisation ein anderes.
Wenn ich Sie richtig verstehe, bedeutet dies, dass wir auf vielen Ebenen eine Standardisierung benötigen, schon allein, um die verschiedenen dafür erforderlichen Tools integrieren zu können?
Tung: Hier gibt es verschiedene Konzepte, von denen sich einige überschneiden. Das eine ist Interoperabilität und Kompatibilität, das andere sind Standards. Bei MathWorks haben wir uns schon immer für Interoperabilität eingesetzt. Im Laufe der Jahrzehnte hat sich jedoch auch gezeigt, dass es verschiedene Wege gibt, um dauerhafte Interoperabilität zu erreichen.
In unseren Produkten setzen wir auf APIs, um Interoperabilität zu gewährleisten. Andere Tool-Anbieter implementieren ebenfalls APIs, bieten dann aber exklusiven Zugriff oder erstellen spezielle Anpassungen mit bestimmten Partnern. Das bedeutet, dass Dritte kaum darauf zugreifen können.
Dies birgt auch das Risiko, dass sich diese APIs plötzlich ändern können, da nur eine vergleichsweise kleine Anzahl von Parteien sie nutzt und von einer solchen Änderung betroffen wäre. Unser Ansatz hingegen war schon immer, dass die APIs Funktionen der Produkte sind, gut dokumentiert sind und kontrolliert weiterentwickelt werden. Das bedeutet auch, dass wir wie bei jeder anderen Produktfunktion auf die Abwärtskompatibilität unserer APIs achten und die Nutzer rechtzeitig über Änderungen informieren.
APIs sind daher für uns ein wichtiges Element zur Schaffung von Interoperabilität.
„APIs sind für uns ein wichtiges Element zur Schaffung von Interoperabilität.“ © The MathWorks, Inc.
Und wie beurteilen Sie die Bedeutung von Standards im Hinblick auf Interoperabilität?
Tung: Einige Standards sind für die Interoperabilität sehr effektiv, andere hingegen nicht. Ein Beispiel für einen effektiven Standard ist OpenScenario von ASAM. Dieser Standard ermöglicht es Anwendern, Fahrszenarien zu erstellen, beispielsweise mit unseren RoadRunner-Tools, und diese in verschiedenen Simulatoren anderer Anbieter auszuführen. Wie unsere APIs entwickelt sich auch dieser Standard weiter.
Teile von OpenScenario lassen Interpretationsspielraum, und auch dieser Standard entwickelt sich weiter. Beispielsweise gibt es Flexibilität hinsichtlich der Frage, ob eine Kurve als eine Reihe von Liniensegmenten oder als vollständige Geometrie definiert wird.
Deshalb arbeiten wir mit anderen Anbietern zusammen, um sicherzustellen, dass unsere Interpretationen konsistent sind und unsere Implementierungen miteinander kompatibel sind. Auch wenn OpenScenario für den beschriebenen Zweck ein großartiger Standard ist, zeigt dieses Beispiel, dass Standards ohne die Zusammenarbeit der Beteiligten in der Anwendung nicht effektiv sein können. In einem solchen Fall ist die Bereitschaft zur Zusammenarbeit zwischen den Anbietern bei einer gemeinsamen Interpretation des Standards unerlässlich, da dies für die Interoperabilität von entscheidender Bedeutung ist.
Standards sind also nicht immer hilfreich, wenn es um Interoperabilität geht?
Tung: Es gibt einige Standards, die sich als weniger effektiv erwiesen haben, wenn man den Erfolg an der Interoperabilität misst.
Ein Beispiel, das mir dazu einfällt, ist SysML Version 1.0 vom OMG-Konsortium, das vom International Council on Systems Engineering (INCOSE) und vielen anderen Organisationen und Unternehmen unterstützt wird. Dieser Standard ist dateibasiert und verfügt über einige APIs, was für statische beschreibende Modelle in Ordnung ist, aber laut unseren Anwendern für die Anforderungen des Marktes ziemlich unzureichend ist.
Meiner Meinung nach hat sich insbesondere das XMI-Austauschformat als unzureichend erwiesen, was das Ziel der Interoperabilität und die Vermeidung von Herstellerabhängigkeit angeht.
Aus prozessuaer Sicht hat diese mangelnde Interoperabilität eine Chance vertan. Wir sehen zwar kleine Gruppen in vielen Organisationen, die nach hohen Einstiegskosten SysML-Tools einsetzen. Diese Modelle werden jedoch nur in relativ kleinen Bereichen ihrer Entwicklungsaktivitäten verwendet, was bedeutet, dass der Standard nicht wirklich positive Auswirkungen auf den gesamten Prozess haben kann.
Diese Beispiele zeigen, dass selbst Standards nicht automatisch Interoperabilität gewährleisten.
Während SysML v1 wenig Verbreitung gefunden hat, wird die Version 2 das modellbasierte Engineering verändern. © The MathWorks, Inc.
Noch eine Anmerkung zu SysML: Die kürzlich ratifizierte Version 2 von SysML ist vielversprechender als die Vorgängerversion, da die Ziele der neuen Version von Anfang an Interoperabilität und Offenheit umfassen. Sie verfolgt einen repositorybasierten Ansatz anstelle eines dateibasierten. In Kombination mit ihrer stärkeren Semantik bietet uns dies eine spannende Möglichkeit, die Interoperabilität in diesem wichtigen Bereich zu verbessern.
Wir müssen jedoch abwarten, wie sich dies tatsächlich entwickelt. Wie bei anderen Standards auch müssen neben dem Standard selbst die Tool-Anbieter bereit sein, zusammenzuarbeiten, um die erklärten Ziele der Offenheit und Interoperabilität in der Praxis zu erreichen. Wir bei MathWorks unterstützen dies aktiv mit unserem Produkt System Composer. Dennoch wird es interessant sein zu sehen, wie die Community die Einhaltung dieser Standards sicherstellen wird. (jr)
Das Interview führte Franz Roßmann, Herausgeber und Co-Chefredakteur AEEmobility.
Im zweiten Teil des Interviews, der am Montag, den 13. Oktober 2025 auf AEEmobility online geht, spricht Jim Tung, Fellow bei MathWorks, über die Balance zwischen Kostendruck und Innovationsgeschwindigkeit in der Automobilindustrie. Er diskutiert zudem, wie Automatisierung, modellbasiertes Design und flexible Entwicklungswerkzeuge den Übergang zum SDV unterstützen und warum das Rennen noch nicht entschieden ist.
Wenn Sie mehr über die Überwindung der Engineering-Hürden bei SDV-Projekten erfahren möchten, können Sie das am 17. und 18. Oktober mit den Experten von MathWorks auf der ELIV 2025 in Bonn diskutieren oder die MATLAB EXPO Konferenz am 21. Oktober in München besuchen.
