Interview with Paula Herzog, Qorix
“Production readiness is achieved through systematic hardening”
Paula Herzog, Head of Product Program Management at Qorix, holds an MSc in Mechatronics and Robotics from Fachhochschule Technikum Vienna.
Qorix GmbH
As SDV stacks grow more complex, open software must prove it can scale under series, safety and lifecycle constraints. Paula Herzog of Qorix explains how Eclipse S-CORE can be hardened for real-time, automotive-grade deployment.
As software-defined vehicle
programs become more complex, the industry is under growing pressure to turn
flexible software architectures into robust production platforms. Open-source
building blocks are gaining importance in that effort, but series programs
still demand stability, traceability, safety alignment and long-term
maintainability.
Paula Herzog, Head of Product Program Management at Qorix,
addresses exactly this tension in her presentation at the Automotive Software Strategies Conference 2026 in
Munich. Drawing on experience from Bosch, ZF and now Qorix, she discusses what
it takes to make Eclipse S-CORE production-ready for
safety-critical and real-time embedded systems.
Ahead of the event, we spoke with her about the
industrialization challenge behind open automotive software platforms.
ADT: Looking ahead three to five years, what will
be the biggest challenge in bringing open software platforms into series
automotive programs?
Herzog: The hardest part won’t be building open
software platforms. It will be industrializing them – turning promising
technology into something a series automotive program can actually base its
schedule and safety case on. Open-source innovation moves fast. Automotive
programs need stability, predictability, and compliance with functional safety
standards such as ISO 26262. In practice, we’re seeing a widening gap between
what the upstream community ships and what OEM programs can actually deploy. Closing
that gap is not primarily a technology problem. It’s a question of ownership,
governance, and lifecycle discipline. The industry has spent the last few years
exploring what open source can do. The next phase is about making it work at
scale – repeatedly, reliably, and under real program conditions.
Which platform decision today will most strongly shape
how open middleware scales across SDV programs?
The most consequential decision is deceptively simple: is
middleware treated as a shared, non-differentiating foundation, or does every
program rebuild and reintegrate it from scratch? OEMs that standardize this
layer early gain a compounding advantage. A stable middleware foundation scales
across domains, platforms, and vehicle generations. Those who don’t will keep
paying the same integration tax, program after program. What we consistently
see is that success comes down to a clean separation of concerns – hardware,
operating system, middleware, applications – and ensuring that the middleware
layer is robust enough to carry not just one program, but many. Get that
architecture right once, and it pays dividends for years.
Your presentation focuses on distributing Eclipse S-CORE
for safety-critical systems. What does it take to make an open project
production-ready?
Production readiness is about everything that doesn’t show
up in the code. Functional safety alignment, traceability, test coverage,
release management, and long-term maintenance – none of that is visible in a
repository, but all of it is what an automotive program actually depends on.
Add to that the integration work across SoCs, operating systems, and real-time
environments, and you start to see why “open source” and “production-ready” are
very different claims. At Qorix, we address this by pairing open-source
collaboration with a production-grade distribution model. The open project
provides the shared baseline. Production readiness is achieved through
systematic hardening, validation, and the kind of support structures that OEM
programs can build a program plan around. We demonstrated this concretely at
CES – four end-to-end demonstrators across different partners, platforms, and
use cases, all running on a consistent middleware foundation. What became clear
is that production readiness is not about individual features. It’s about
making complex, mixed-criticality systems behave reliably across real
automotive environments.
What role does a distributor play when scaling open
middleware across multiple OEM programs?
The distributor is where open-source innovation meets
program accountability. Open-source communities are exceptional at
collaboration and feature development. But they are not structured to carry the
full responsibility for an automotive program – and they shouldn’t have to. The
distributor closes that gap by owning integration, validation, compliance, and
lifecycle support across the full vehicle lifecycle. That role becomes critical
at scale. When you’re running middleware across multiple OEM programs simultaneously,
consistency and predictability aren’t optional. You need a single point of
accountability – someone who can align with program timelines, absorb the
complexity, and ensure that what ships in one program can be maintained and
updated in the next. In that sense, the distributor doesn’t just enable
technology adoption. It’s what makes adoption sustainable.
Where do real-time and safety requirements create the
biggest challenges when turning open software into automotive platforms?
Real-time and functional safety requirements change the
rules fundamentally. It’s no longer enough for software to be correct – it has
to be deterministically correct under all conditions, with strict guarantees on
timing, isolation, and data consistency. That’s a different engineering problem
from what most open-source development is optimized for, and it’s frequently
underestimated in early-stage projects. The hardest part is runtime
orchestration in mixed-criticality environments – where safety-relevant and
non-safety functions share the same hardware platform. That’s where the gap
between “open code that works” and “automotive-grade middleware” becomes most
visible. And it’s exactly where dedicated architectural investment pays off.
How can OEMs ensure long-term maintainability when
integrating open components into complex SDV stacks?
Long-term maintainability is less a feature question and
more a governance question – one that gets harder the longer it’s deferred. The
technical foundations are well understood: modular architectures, stable
interfaces, strict versioning. But the real challenge is managing change over a
vehicle lifecycle that stretches 10 to 15 years. Updates, compliance
requirements, security patches, evolving safety standards – none of that stops
after SOP. What OEMs actually need is clear ownership of lifecycle management:
who is responsible for integration stability, who owns the update strategy, and
who ensures ongoing alignment with functional safety and cybersecurity
requirements. Without that structure, open components that looked like assets
at the start of a program can quietly become liabilities by the end of it. The
good news is that well-architected stacks – with clean interfaces and active
upstream communities – give OEMs real optionality. Switching costs exist, but
they are manageable. The risk isn’t open source. The risk is choosing a partner
who doesn’t know how to play the long game in an open world.
Finally, what do you personally hope to take away from
the Automotive Software Strategies Conference in Munich?
Honestly? Fewer hypotheticals and more commitments. There is strong alignment across the industry around the idea
of shared, open software foundations like Eclipse S-CORE. What I’m
hoping to drive at this conference is the next conversation – not “should we do
this?” but “how do we actually operationalize it across programs, across
partners, at scale?” I’m particularly interested in concrete discussions with
OEMs and Tier-1 companies on closing the gap between strategic intent and
production execution. That’s the conversation that moves the industry forward –
and Munich is exactly the right place to have it.
