Software Defined Vehicles
Interview with Peter Gliwa, GLIWA
“Wouldn’t it be good if someone designed a dedicated embedded processor?”
Precise timing is becoming the make-or-break factor for embedded software. Peter Gliwa, CEO of GLIWA, explains why developers must close the gap between virtual and real-world behavior – and why future ECUs need processors truly built for determinism.
Peter Gliwa has spent more than two decades working at the forefront of embedded timing — from developing the timing suite T1 to guiding global projects on real-time performance and RTOS design. Before founding GLIWA in 2003, he worked at ETAS as a developer and later as product manager for the ERCOSEK operating system, and also lectured in microcomputer technology.
As a speaker at the upcoming Automotive Computing Conference in Munich, Gliwa discusses why precise timing is essential for reliability in software-defined vehicles — and why the industry urgently needs processors purpose-built for deterministic performance.
ADT: Timing has become one of the critical bottlenecks in embedded software. From your perspective, what are the most underestimated challenges developers face when scaling software complexity in modern ECUs?
Gliwa: The biggest problem in this context is the lack of awareness. People are often not aware of what their timing, their scheduling, their communication, and their synchronization really look like. Simulations, static analyses, and virtual ECUs all have their valid use cases, but they describe a model-based, a virtual world. In the end, however, we are building real cars. Neglecting the real world and what the timing looks like there will cause task forces and result in less safe, less reliable embedded systems. The gap between the virtual world and the real world is bigger than expected!
At the ACC 2025, you’ll address the differences between real-time and non-real-time operating systems. How do processor architectures influence timing behavior – and what strategies help ensure deterministic performance in increasingly heterogeneous systems?
This is a tricky question because most people will dislike my answer. When building safety-relevant embedded systems, you should always think “worst case” with respect to timing. The timing constraints must be met under all realistic conditions. However, the processor architectures and operating systems designed for high-performance computing, desktop PCs, phones, etc., are barely a good fit for hard real-time constraints. These architectures and operating systems are designed for maximum throughput. This means their execution and response times are low on average. In the worst case, they might perform very badly. Nevertheless, the embedded world seems to take whatever the high-performance computing world comes up with. Wouldn’t it be good if someone designed a dedicated embedded processor? Apitronix is a company going in this direction.
GLIWA is known for its deep expertise in timing analysis and optimization. How do you see the role of precise timing management evolving as the industry moves toward software-defined and AI-assisted vehicle platforms?
I see three kinds of platforms: a) the classical embedded ECU, b) the POSIX-based high-performance control unit with or without AI, and c) a centralized approach using RCP. All come with their individual timing requirements, which should be addressed already in the design phase. Here, scheduling simulation can help to get a clear picture and shape the design. As soon as a first version of the system is up and running, measuring, tracing, and supervising the timing on “the real thing” is essential – for all three kinds of platforms.
