Im zweiten Teil des AEEmobility-Interviews 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.
AEEmobility: Können wir angesichts der schwierigen wirtschaftlichen Lage vieler Unternehmen in der Automobilindustrie mit spürbaren Rückenwind bei den Standardisierungsbemühungen und einer hohen Innovationsgeschwindigkeit rechnen?
Jim Tung: Aus unserer Sicht gibt es mehrere Möglichkeiten, wie wir als Unternehmen und als Branche Kostensenkungen und Innovationsgeschwindigkeit in Einklang bringen können.
Was die Geschwindigkeit angeht, hat MathWorks stets den Ansatz verfolgt, unseren Anwendern die Flexibilität zu geben, die von uns definierten Produktfunktionen auf innovative Weise zu kombinieren, die für sie hilfreich ist. Wir geben ihnen diese Möglichkeit und stellen die erforderliche Dokumentation zur Verfügung.
Dieser Weg der Modifizierung und Erweiterung auf Anwenderseite kann auch von anderen Anbietern wie NXP und Infineon sowie anderen Allianzen beschritten werden, um unsere Tools mit oder ohne unsere Beteiligung in ihre eigenen Toolketten zu integrieren. Dies ist wichtig, da wir aus Kosten- und Ressourcengründen natürlich nicht jede Allianz und Initiative vollständig unterstützen können.
Wenn sich beispielsweise eine Allianz an uns wendet, die mit uns zusammenarbeiten und unsere Unterstützung in Anspruch nehmen möchte, können wir oft sagen: „Das können wir machen, aber Sie können es auch selbst umsetzen.“ Das hängt natürlich von der Art der erforderlichen Integration ab. Diese Flexibilität senkt jedoch die Hürde für eine Investition.
Zu Ihrem Punkt bezüglich der Kosten: Die Automatisierung ist hier entscheidend. Wir könnten an dieser Stelle über Cloud-Kosten sprechen, aber das ist eine andere Frage. Unabhängig davon, ob Anwender die Cloud, On-Premise-Lösungen oder einen anderen Computing-Ansatz nutzen, können sie durch Automatisierung Effizienzsteigerungen erzielen. Und das gilt für jedes Unternehmen innerhalb und außerhalb der Automobilindustrie.
Jim Tung, Fellow
bei MathWorks. © The MathWorks, Inc.
Es wird viel über SDVs gesprochen. Ich habe aber den Eindruck, dass insbesondere viele europäische OEMs den großen Schritt hin zu einer durchgängig zentralisierten Architektur vermeiden und stattdessen bestehende Architekturen evolutionär weiterentwickeln. Aus Kosten- und Zeitgründen verwenden sie weiterhin alte Hardware und Software. Verlangsamt dieser eher evolutionäre Ansatz das Innovationstempo?
Tung: Jeder OEM muss die Risiken und Chancen einer drastischen und schnellen Umstellung der Architektur abwägen, da er auch während der Umstellung weiterhin zuverlässige Fahrzeuge entwickeln und produzieren muss. Es gibt jedoch bedeutende Fortschritte. Wir haben einen Punkt erreicht, an dem die OEMs die E/E-Architektur für ihre neueste Plattformgeneration in Bezug auf dedizierte Steuergeräte, Zonen- und Domänencontroller sowie Fahrzeugcomputer definiert haben.
Sie haben auch herausgefunden, wie sie CAN und Ethernet für diese Generation kombinieren können, die noch viele Jahre lang im Einsatz sein wird.
Der Grund für den Umstieg auf leistungsstärkere Zonen- und Fahrzeugcomputer liegt darin, dass diese die für die Aktualisierung der Software erforderlichen Ressourcen und Rechenleistung bereitstellen.
Derzeit haben wir es mit Fahrzeugcomputern zu tun, die eine Vielzahl unterschiedlicher Prozessorkerne verwenden. Dies wirft die Frage auf, welche Art von Middleware-Architektur erforderlich ist, um all diese Domänen-Gateways, Zonen-Controller und zentralen Fahrzeugcomputer effektiv zu verbinden und zu verwalten.
Wird es sich um eine Variante oder Erweiterung von AUTOSAR Adaptive handeln? Wird sie von Google kommen oder wird es etwas völlig anderes sein, vielleicht ein neuer Standard oder etwas, das von den OEMs entwickelt wurde? Diese Entscheidung müssen die Unternehmen treffen – und manchmal immer wieder neu treffen.
Wie verändert dies die Anforderungen an Entwicklungswerkzeuge?
Tung: Unsere Werkzeuge müssen robust und flexibel gegenüber Veränderungen sein. Sie müssen flexibel genug sein, damit Entwickler ihre Algorithmen und Implementierungen an unterschiedliche Middleware und unterschiedliche Zielprozessoren anpassen können, ohne jedes Mal, wenn sie etwas ändern, alles über den Haufen werfen und von vorne beginnen zu müssen.
Genau darin liegt der Wert modellbasierter Ansätze, wie wir sie bei MathWorks verfolgen. Modellbasiertes Design ermöglicht es den Ingenieuren, die Implementierungsentscheidung auf eine spätere Phase des Entwicklungsprozesses zu verschieben, indem sie die Algorithmen in einer wiederverwendbaren Form modellieren. Denn wenn Sie über das Modell des Algorithmus verfügen und es mit der automatischen Codegenerierung kombinieren, kann der Code automatisch für die Zielhardware mit Zieloptimierungen generiert werden. Dabei spielt es keine Rolle, ob es sich um einen Mikrocontroller, eine GPU oder einen FPGA handelt.
Model-based-Desing ermöglicht eine Zielhardware-unabhängige Entwicklung und unterstützt damit eine frühere Anwendungsprogrammierung (Shift-Left) © The MathWorks, Inc.
Modellbasierte Tools bieten schon seit langem die Möglichkeit, Anpassungen vorzunehmen, wenn Sie Ihre Meinung ändern. Und nun gilt dies auch für verschiedene Middleware-Produkte. Genau das ist einer der großen Vorteile des modellbasierten Designansatzes.
Es gibt mehr Flexibilität, da unsere Tools die Sprachen C und C++ in Verbindung mit serviceorientierten und signalbasierten Architekturen unterstützen.
In den Teams unserer Kunden wird viel darüber diskutiert, welcher Ansatz gewählt werden soll. Ich denke, dass die Engineering-Teams dazulernen und sich verbessern und möglicherweise ihre Meinung darüber ändern, welche Art von Architektur für welche Aufgabe am besten geeignet ist. Unsere Tools sind darauf ausgerichtet, sie zu schützen und ihre Produktivität während dieses Lernprozesses zu ermöglichen.
Aber glauben Sie, dass insbesondere die großen, etablierten OEMs die Zeit haben, all diese ORs auszuprobieren? Oder anders gefragt: Was können diese OEMs tun, um voranzukommen und die richtige OR-Entscheidung mit der viel zitierten „China-Geschwindigkeit” zu treffen?
Tung: Wir arbeiten auch mit chinesischen OEMs zusammen, die im Allgemeinen mit vielen der gleichen Fragen und Entscheidungen konfrontiert sind. Neulinge haben es in manchen Fällen leichter, da sie sich nicht mit so vielen Altlasten auseinandersetzen müssen.
Ich würde mich hier jedoch eher auf Flexibilität als auf Handlungsorientierung konzentrieren. Es geht also darum, als OEM die Möglichkeit zu haben, etwas zu realisieren und dann zu ändern oder zu modifizieren.
Etablierte Unternehmen haben jedoch nach wie vor die Mentalität, eine Entwicklung erst zu perfektionieren, bevor sie den Startschuss geben.
„Etablierte Unternehmen haben nach wie vor die Mentalität, eine Entwicklung erst zu perfektionieren, bevor sie den Startschuss geben.“ © The MathWorks, Inc.
Ist das Verhalten etablierter Unternehmen nicht verständlich? Schließlich haben sie viel mehr zu verlieren?
Tung: Das Risiko ist für etablierte Unternehmen höher. Und vor allem das wahrgenommene Risiko ist höher. Das liegt daran, dass diese Unternehmen mit langer Geschichte bereits viele Fälle erlebt haben, in denen eine Veränderung dazu geführt hat, dass vieles verworfen und von vorne begonnen werden musste, wofür wiederum kulturell unterschiedliche Teams neu motiviert werden mussten.
Unser Ziel als Tool-Anbieter ist es, diese Flexibilität zu ermöglichen, damit Anwender Dinge wiederverwenden, ihre Produktivität steigern und ihre Entwicklungsprozesse optimieren können.
Und ist Virtualisierung oder Simulation der Schlüssel zur Steigerung der Produktivität und zur Rationalisierung von Entwicklungsprozessen?
Tung: Simulation, Automatisierung, die Art und Weise, wie Benutzer Code generieren, Late-Binding-APIs – all das sind Aspekte davon. Wir haben im ersten Teil des Interviews über die unterschiedlichen Perspektiven und Denkweisen der Silos gesprochen.
Programmierer sind es gewohnt, Code mit einem bestimmten Ziel oder einer bestimmten Funktionalität im Hinterkopf zu erstellen, und agile Ansätze ermöglichen es ihnen, dies schneller zu tun. Ein Aspekt des DevOps-Ansatzes besteht darin, die zukünftige Betriebsumgebung, in der die Software ausgeführt wird, so weit wie möglich zu berücksichtigen und sie so früh wie möglich während der Entwicklungsschritte darzustellen. Dazu gehören in der Regel benachbarte Datenströme, Datenbanken und Ähnliches. Die IT-Perspektive der übrigen Softwareumgebung wird daher im Voraus berücksichtigt und ist Teil der Testkriterien.
Wenn jedoch die Middleware oder die physischen Schnittstellen zum System geändert werden, ist dies etwas, womit Softwareentwickler normalerweise nicht konfrontiert sind. Und in einem Auto umfasst dies auch die physischen Teile des Fahrzeugs, da die Software- und Hardwarekomponenten viel weniger isoliert sind als beispielsweise in einem PC oder einem Mobiltelefon. Ein Auto ist kein Mobiltelefon und kein Browser auf Rädern. Daher muss eine stärkere Brücke zwischen Hardware- und Systemdesignern und Programmierern geschlagen werden. In vielen Fällen hat die Qualität heute gelitten, weil diese Brücke fehlt.
Ich bin mir sicher, dass die OEMs und Zulieferer, die die Grauzone zwischen System-Engineering und Software-Engineering klären, aufeinander abstimmen und wirklich gut beherrschen, am Ende gewinnen werden.
„Ich bin mir sicher, dass die OEMs und Zulieferer, die die Grauzone zwischen System-Engineering und Software-Engineering klären, aufeinander abstimmen und wirklich gut beherrschen, am Ende gewinnen werden.“ © The MathWorks, Inc.
Erleichtern Standards diese Abstimmung zwischen System- und Software-Engineering?
Tung: Standards können einen wesentlichen Beitrag zur Erreichung von Reife leisten. Ob es sich dabei um einen formalen Standard, einen De-facto-Standard oder etwas Vergleichbares handelt, ist zweitrangig.
Das Beispiel der Cloud zeigt jedoch, dass ein System auch mit wenigen formalen Standards sehr leistungsfähig, modular und effizient sein kann, solange es starke De-facto-Standards gibt und sich die beteiligten Parteien auf einen Ansatz einigen können.
Mein Problem mit Standards ist einfach, dass ein Standard im Wesentlichen ein Produkt ist, das entworfen, entwickelt, validiert, implementiert und dann überarbeitet werden muss. Und das muss geschehen, während ein Konsens zwischen den Beteiligten mit unterschiedlichen Perspektiven und Agenden hergestellt wird.
Wir haben bereits einige der noch nicht bewältigten Herausforderungen angesprochen. Gibt es OEMs, die weiter fortgeschritten sind als der Rest der Branche?
Tung: Wir arbeiten mit vielen, wenn nicht sogar allen OEMs zusammen. Aber es gibt keinen bestimmten OEM, den ich hier einzeln nennen würde. Das sage ich sowohl aus Höflichkeit gegenüber unseren Kunden als auch weil ich es für die Wahrheit halte. Jedes Unternehmen hat bestimmte Dinge in verschiedenen Bereichen besonders gut im Griff, aber es hat auch Schwächen, an denen es arbeitet. Unterm Strich hat jeder OEM Stärken und Schwächen, und jeder entwickelt sich weiter.
Das Rennen ist also noch nicht vorbei?
Tung: Nein, ganz und gar nicht. Kurzfristig könnte man sich für jemanden entscheiden, der gerade in Führung liegt.
Das Rennen geht jedoch über eine lange Distanz, und am Ende werden sich einige durchsetzen. Andere werden aufgrund fehlerhafter technischer Umsetzung und anderer Gründe ins Straucheln geraten.
Natürlich spielen auch politische und wirtschaftliche Faktoren wie Zölle eine Rolle. Die Regeln können sich während des Rennens ändern.
In der Vergangenheit sind vermeintliche oder tatsächliche Spitzenreiter gescheitert, und das wird noch häufiger der Fall sein.
Wird die Dynamik durch den Übergang zu SDV zunehmen?
Tung: Ich beobachte, dass die oben beschriebene Dynamik im IT-Sektor stärker ausgeprägt ist als in der Fertigungsindustrie.
Die Automobilindustrie ähnelt aufgrund des Übergangs zu SDV immer mehr der IT-Branche. Ich denke daher, dass das Risiko eines Scheiterns für Spitzenreiter gestiegen ist, während gleichzeitig die Chancen für Nachzügler, aufzuholen, größer geworden sind.
MATLAB Copilot unterstützt Programmierer beim Erstellen, Verfeinern und Debuggen von Code. © The MathWorks © The MathWorks, Inc.
Welche Rolle kann KI im Wettlauf um den Anschluss spielen?
Tung: Ich denke, generative KI ist definitiv ein wichtiger Disruptor. Es handelt sich um eine Reihe von Fähigkeiten, die im Laufe der Zeit zu mehr Effizienz und Produktivität beitragen werden. Eine Stärke der KI liegt sicherlich im Bereich der Programmierung, wie Angebote wie GitHub Copilot zeigen.
MathWorks hat im April 2025 sein erstes KI-basiertes Produkt, MATLAB Copilot, auf den Markt gebracht. Da MATLAB eine Programmiersprache ist, passt es perfekt in das Paradigma der generativen KI-Copiloten.
Es wird auch einen Simulink-Copiloten geben, der sich jedoch noch in der Entwicklung befindet. Ein Copilot für die Polyspace-Tools, unsere Tools zur Codeüberprüfung und -validierung, ist ebenfalls geplant.(jr)
Das Interview führte Franz Roßmann, Herausgeber und Co-Chefredakteur AEEmobility.
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.
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.
