Interview mit Dr. Florian Baumann, System Technical Expert – SDV bei STMicroelectronics

„Physische End-to-End-Validierung darf niemals entfallen“

Zentralisierte E/E-Architekturen verändern auch die ECU-Entwicklung. Dr. Florian Baumann von STMicroelectronics erklärt, welche Aufgaben virtuelle MCUs bereits übernehmen können und wo reale Hardware unverzichtbar bleibt.

2 min
Mann im grauen Anzug mit Krawatte vor hellem Hintergrund.
Florian Baumann promovierte an der Leibniz Universität Hannover im Bereich Machine Learning. Sein Schwerpunkt lag auf szenischem Umgebungsverständnis mithilfe optischer Sensoren.

Vehicle Computing entwickelt sich in Richtung zentralisierter und hierarchischer E/E-Architekturen, das stellt die Branche vor Herausforderungen: Entwicklung und Validierung müssen weiterhin Echtzeitverhalten, Sicherheitsmargen und die physische Zielhardware berücksichtigen. Virtuelle MCUs, virtuelle eFuses und cloudbasiertes Prototyping können Teile der ECU-Entwicklung weiter nach vorne verlagern – insbesondere die funktionale Softwareentwicklung, Integration und frühe Tests.

Dr. Florian Baumann, System Technical Expert – SDV bei STMicroelectronics, fokussiert in dieser Funktion SDV-Architekturen, Plattformsoftware, AD/ADAS, Machine Learning und Cloud-Architekturen. Auf der Automotive Computing Conference Germany hält er die Keynote „From Code to Car: Cloud-Based MCU Prototyping and Virtual eFuses“.

Im Vorfeld der Veranstaltung sprachen wir mit Baumann über zentralisierte Rechenarchitekturen, Virtual-First-Entwicklung, Hardwareabstraktion und die Grenzen beim Ersatz physischer Validierung.

Herr Dr. Baumann, welche heute getroffene Architekturentscheidung wird die langfristigsten Auswirkungen auf das Automotive Computing haben?

Der Übergang zu hierarchischen, zentralisierten E/E-Architekturen mit Zonen-Controllern und zentraler Fahrzeugrechenleistung, die auf leistungsfähigen SoCs und MCUs mit Trennung von Hardware und Software basieren. Diese Transformation wird die Grundlage dafür bilden, wie OEMs Rechenleistung skalieren, Software wiederverwenden, neue Funktionen einführen und Updates über den gesamten Lebenszyklus eines Software-defined Vehicle hinweg verwalten.

Alles zur Automotive Computing Conference

Werbegrafik mit blauem Auto, Netzwerk-Linien und Text zur Automotive Computing Conference 2026 in München.

Die Automotive Computing Conference geht den technischen Grundlagen moderner Fahrzeugrechner auf den Grund. Im Fokus stehen High-Performance-Computing im Fahrzeug, moderne E/E-Architekturen, Chiplets, Sicherheitskonzepte, funktionale Sicherheit, Cloud-Anbindung und die wachsende Komplexität softwaredefinierter Fahrzeuge.

Am 18. und 19. November 2026 diskutieren internationale Expertinnen und Experten in München, wie sich klassische Fahrzeugarchitekturen zu leistungsfähigen Computing-Plattformen weiterentwickeln lassen. Keynotes, Panels und Q&A-Sessions zeigen, welche Hardware- und Softwaretrends das Automotive Computing prägen, wie OEMs und Zulieferer mit steigenden Anforderungen umgehen und welche Rolle moderne Halbleiterarchitekturen für künftige SDVs spielen.

Weitere Infos zur Automotive Computing Conference gibt es hier oder auf dem LinkedIn-Kanal.

Wie weit können cloudbasierte virtuelle MCUs und virtuelle eFuses die ECU-Entwicklung nach vorne verlagern, bevor die Korrelation mit der physischen Zielhardware zum limitierenden Faktor wird?

Virtuelle MCUs und eFuses können uns durch die funktionale Softwareentwicklung, Integration sowie frühe Tests und Validierung führen. Die Grenze ist erreicht, sobald wir präzises Timing, Sicherheitsmargen, Leistungs- und elektrisches Verhalten sowie reale Netzwerkeffekte berücksichtigen müssen. Dafür ist weiterhin eine Korrelation mit physischen MCUs oder anderen Peripheriekomponenten erforderlich.

Wo zentralisierte E/E-Architekturen an ihre Grenzen stoßen

Wenn Fahrzeugarchitekturen immer mehr Funktionen auf wenige Rechenknoten bündeln: Wo sollten OEMs bewusst an verteiltem Computing festhalten, weil Latenz, Sicherheit, Verfügbarkeit oder deterministisches Verhalten dafür sprechen?

OEMs sollten darauf verzichten, harte Echtzeitfunktionen und Funktionen mit hohen ASIL-Anforderungen zu konsolidieren, etwa x-by-wire, Airbags, fail-operationale AD-/ADAS-Funktionen, zentrale Sensorik und Aktuatorik sowie lokales Energie- und Netzwerkmanagement in den einzelnen Zonen. Diese Funktionen sind darauf angewiesen, dass sich kritische Rechenleistung nahe an Sensoren, Aktuatoren oder der Energieversorgung befindet, um niedrige Latenzen und deterministisches Verhalten sicherzustellen.

Plattformsoftware soll Anwendungen von der Hardware entkoppeln. Ab welcher Ebene beginnt Abstraktion zu viele Eigenschaften der zugrunde liegenden Halbleiterarchitektur zu verbergen und dadurch Performance oder Effizienz zu verschenken?

Abstraktion wird kontraproduktiv, sobald die Betriebssystem- oder Middleware-Ebene kritische Hardwareeigenschaften wie Speicherhierarchie, Cache-Verhalten, I/O oder integrierte Sicherheitsmechanismen verbirgt. Bei datenintensiven, sicherheitskritischen oder zeitkritischen Workloads benötigen Anwendungen einen kontrollierten Zugriff auf diese Eigenschaften, um keine Performance und Effizienz zu verlieren.

Was wird bei ADAS- und KI-Workloads die Skalierung der Rechenleistung im Fahrzeug zuerst begrenzen: reine Rechenleistung, Speicherbandbreite, Datenbewegung, Verlustleistung oder die Fähigkeit, zunehmend komplexe Software zu validieren?

Hardwaregrenzen wie Speicherbandbreite, Datenbewegung und Leistungsaufnahme werden früh erreicht werden. Die dominierende Einschränkung wird jedoch die Fähigkeit sein, zunehmend komplexe Software-Stacks zu validieren, zu warten und deren Sicherheit nachzuweisen. Der Nachweis von Sicherheit und Korrektheit wird zum zentralen Engpass.

Wie weit Virtual-First-Entwicklung Tests ersetzen kann

Was hindert die Automobilindustrie daran, ein softwareähnliches Continuous-Development-Modell zu erreichen, bei dem virtuelle Plattformen neben einer schnelleren Entwicklung auch belastbare Nachweise für Verifikation oder sogar Zertifizierung liefern?

Die größten Hürden sind sicherheitskritische regulatorische Anforderungen, fehlende standardisierte Modelle virtueller Plattformen über OEMs und Tier-1-Zulieferer hinweg, begrenztes Vertrauen darin, dass virtuelles Timing und virtuelles Fehlerverhalten die Realität vollständig abbilden, sowie Toolchains, die virtuelle Assets noch nicht in Sicherheitsnachweise und Homologation integrieren. Es gibt kein universelles Modell, das für alle Anwendungsfälle passt.

Wenn Virtual-First-Entwicklung die Kosten strukturell senken soll: Welcher physische Test oder Hardware-Meilenstein sollte zuerst entfallen und welcher darf niemals entfallen?

Als Erstes sollten frühe, repetitive Tests und nicht sicherheitskritische Integrationsprüfungen entfallen, die lediglich bereits bekanntes Verhalten erneut bestätigen. Niemals entfallen dürfen physische End-to-End-Validierungen und Robustheitstests für sicherheitskritische Funktionen, insbesondere ADAS, automatisiertes Fahren und x-by-wire, unter realen Umwelt-, elektromagnetischen und Alterungsbedingungen.