Interview with Peter Gliwa, GLIWA
“Wouldn’t it be good if someone designed a dedicated embedded processor?”
Before founding GLIWA, Peter Gliwa worked as a developer and as a lecturer in microcomputer technology.
GLIWA
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.
