We are often asked, is the classic software approach enough for the software-defined vehicle (SDV)? The SDV demands a new level of compute and complexity that the tools of the last 20 years were never designed to handle. For the past two decades, the industry has relied on a familiar set of approaches – microcontrollers, AUTOSAR and proprietary real-time operating systems – and they have worked well. Brake systems work. Airbags deploy. But these tools were designed for a different job, one that looked nothing like what the complexity of today’s world demands, not to mention what tomorrow’s society will expect.
The functional complexity alone has increased significantly and the volume of data that modern vehicles must process from sensors, cameras, maps and networks demand a level of compute power that obsolete methods cannot keep up with. At the heart of this challenge is one of the industry’s most critical priorities: dependability – the ability to perform as and when required, and the concept that underpins functional safety standards like ISO 26262 and EN 61508.
Old school: Proprietary systems and outdated AUTOSAR approaches
For many years, the automotive industry managed the dependability of complex systems through physical separation. But this model came with trade-offs. Classic AUTOSAR provided a standardized software framework that was deterministic and well-understood but lacked the flexibility needed for automotive OEMs to add new features into their vehicles. Proprietary systems mean vendor lock-in, limited developer ecosystems slower iteration and no community-driven evolution result in dependency on a single supplier’s roadmap. Further, the growing requirements for the co-existence of safety and non-safety related functions running on the same piece of hardware, added new industry challenges.
We are no longer living in a world where microprocessors, redundant architectures and round robin schedulers are all that it takes. Proprietary systems and outdated approaches are not equipped to handle the complexities and manifold constraints on timing, bandwidth and throughput, while also addressing exponential growth of data processing, that next-generation vehicle systems require. Outdated approaches stalled innovation, and it was time for a new software era to be defined.
An industry in need of a new approach: Is Linux the new black?
Linux was and is an obvious candidate. It’s open source, supports a broad range of hardware platforms, is backed by a massive global developer community, it’s continuously updated and is field proven across some of the most demanding computing environments. For an industry facing exponentially growing software complexity, it ticked nearly every box. However, until very recently, Linux was being leveraged largely only in one place: Non-safety critical applications where the stakes are much lower, such as infotainment. Linux works beautifully here. But it is capable of far more.
The challenge with using Linux for safety-critical applications is dependability. Linux is a general-purpose operating system and positively assessing it against standards like ISO 26262 or EN 61508 is impossible. Linux is too vast, too dynamic, with an almost infinite number of internal states and hence too far outside the ability of any single organization’s control to build a credible dependability argument for all the required supporting evidence through traditional means.
A shift in strategy
Instead of wasting years trying to prove Linux is dependable and will never fail, we’re tackling the problem in a different way. Detecting when and how Linux will misbehave is a far more achievable goal. Further, this strategy makes the assessment a much more manageable task.
The aim is not to ask an assessor, “Is this piece of software SIL-compliant?” Instead, we’re shifting the question to the system and asking, “Is a system built on X Linux solution able to perform SIL2 safety functions or fulfill ASIL B safety goals?”.
The dependability of the system does not rely on Linux itself, but on the overall arrangement.
This change in thinking and strategy translates into two software components. A hypervisor provides Linux with virtualized memory and computation resources, giving it full control over what Linux can and cannot access. And “supervisor” software that analyzes any attempt by Linux to access those resources and detects when such an attempt could adversely affect the dependability of the system as defined by EN 61508.
EB corbos Linux for Safety Applications
This is exactly what EB corbos Linux for Safety Applications delivers. For the first time, safety and non-safety-related applications can run simultaneously on a single Linux instance, on the same hardware, without one compromising the other. The separation between the two is managed entirely in software with no constraints or demands on the hardware.
The practical implications are significant. Even in the worst case, an incorrect update to Linux, would only affect the reliability – not the safety of the system. The open-source advantages that make Linux so compelling remain intact. And because the dependability argument rests on the supervision layer rather than Linux itself, extending the solution to new variants and use cases requires a fraction of the effort of starting from scratch.
Our solution has been positively assessed by TÜV Nord, confirming dependable execution up to SIL2 / EN 61508 and ASIL-B / ISO 26262, with architecture capable of supporting even higher integrity levels.
New webinar: Linux safety strategies compared – partitioning, wrappers, certification and supervision
So, if you are developing your next-generation vehicle and have needs including:
- Using a modern operating system for HPC
- Meeting high bandwidth performance requirements
- Robust security conditions
- Eliminating vendor lock in
- Harnessing the benefits of the Linux ecosystem, ranging from supported hardware to tooling landscape and availability of experienced developers
- All backed by a solution for creating dependable systems which reduces efforts drastically
Then join our webinar. On 21 July 2026, we’ll discuss this and more. I’ll highlight how automotive OEMs and Tier 1s are actively evaluating different approaches to using Linux in safety critical automotive systems. Partitioning Linux from safety software, building custom safety wrappers, certifying limited Linux subsets or adopting supervision-based approaches will all be examined.
Register here where you’ll learn:
- The real tradeoffs of common Linux safety strategies
- Why some approaches scale poorly as system complexity grows
- How to evaluate safety strategies beyond short term feasibility
Author
Ulrich Kirchmaier
Senior System Architect, HPC OS, Elektrobit
