Interview with Dr Florian Baumann, STMicroelectronics
“There is no one-size-fits-all model”
Florian Baumann holds a PhD in machine learning from Leibniz University Hannover, specialising in optical sensor-based scene understanding.
Dr Florian Baumann
As E/E architectures consolidate, ECU development must move earlier into virtual environments. STMicroelectronics expert Dr Florian Baumann explains where cloud-based MCU prototyping helps and where physical validation remains essential.
Vehicle computing is moving towards centralised and hierarchical E/E architectures, but development and validation still have to deal with real-time behaviour, safety margins and physical target hardware. Virtual MCUs, virtual eFuses and cloud-based prototyping can move parts of ECU development further to the left, especially for functional software development, integration and early testing.
Dr Florian Baumann, System Technical Expert – SDV at STMicroelectronics, works on software-defined vehicle architectures, platform software, AD/ADAS, machine learning and cloud architectures. At the Automotive Computing Conference Germany in Munich, he will give a keynote titled “From Code to Car: Cloud-Based MCU Prototyping and Virtual eFuses”.
Ahead of the event, we spoke with Baumann about centralised compute, virtual-first development, hardware abstraction and the limits of replacing physical validation.
Which architectural decision being made today will have the longest-lasting impact on automotive computing?
The move to hierarchical, centralised E/E architectures with zonal controllers and vehicle-central compute, built on powerful SoCs and MCUs with hardware/software separation. That transformation will be the baseline for how OEMs scale compute, reuse software, introduce new features and manage updates over the entire SDV lifecycle.
How far can cloud-based virtual MCUs and virtual eFuses move ECU development to the left before correlation with physical target hardware becomes the limiting factor?
Virtual MCUs and eFuses can take us through functional software development, integration, early testing and validation. The limit is reached when we need accurate timing, safety margins, power/electrical behaviour, and real network effects. Those still require correlation with physical MCUs or other peripherals.
As vehicle architectures consolidate functions onto fewer computing nodes, where should OEMs deliberately resist consolidation because latency, safety, availability or deterministic behaviour still favour distributed computing?
OEMs should resist consolidating hard real-time and high-ASIL functions, such as x-by-wire, airbags, fail-operational AD/ADAS, core sensing and actuation, and local power and network management in each zone. These functions rely on having critical compute close to the sensors, actuators or power, ensuring low latency and deterministic behaviour.
Platform software is meant to decouple applications from hardware. At which layer does abstraction begin to hide too much of the underlying semiconductor architecture and leave performance or efficiency on the table?
Abstraction becomes counterproductive once the OS or middleware layer hides critical hardware properties such as memory hierarchy, cache behaviour, I/O or built-in safety mechanisms. For data-intensive, safety-critical or time-critical workloads, applications need controlled visibility of these features to avoid losing performance and efficiency.
For ADAS and AI workloads, what will constrain automotive compute scaling first: raw processing capability, memory bandwidth, data movement, power dissipation or the ability to validate increasingly complex software?
Hardware limits such as memory bandwidth, data movement and power will hit early, but the dominant constraint will be the ability to validate, maintain and assure increasingly complex software stacks. Proving safety and correctness becomes the primary bottleneck.
What prevents automotive from reaching a software-like continuous development model in which virtual platforms provide not only development speed, but credible verification or even certification evidence?
The main blockers are safety-critical regulations, a lack of standardised virtual platform models across OEMs and Tier-1s, limited confidence that virtual timing and fault behaviour fully match reality, and toolchains that do not yet integrate virtual assets into safety and homologation. There is no one-size-fits-all model.
If virtual-first development is to reduce cost structurally, which physical test or hardware milestone should disappear first, and which must never disappear?
The first to disappear should be early, repetitive tests and non-safety-critical integration checks that only reconfirm behaviour. What must never disappear are end-to-end physical validation and robustness tests for safety-critical functions, especially ADAS, AD and x-by-wire, under real environmental, electromagnetic and ageing conditions.
