For years, the automotive industry has been locked in a circular debate: We want the innovation, the vast ecosystem and the rapid development cycles of Linux, but we are bound by the extremely critical and deterministic world of ISO 26262 functional safety. Historically, the answer was to attempt the impossible, to certify Linux. But as anyone who has tried to do this will tell you, trying to prove that a general-purpose operating system with millions of execution paths is safe, by traditional standards, is a wild-goose chase.
On June 11, we are hosting a webinar to provide the solutions to move past this deadlock and highlight how it is possible to leverage Linux for automotive safety applications. We aren’t here to tell you that we’ve miraculously made the Linux kernel deterministic. We’re here to show you how we have reframed the problem entirely: shifting the focus from the impossible task of certifying the kernel to the highly feasible mission of securing the application through supervision.
The fork in the road: Why retrofitting is a dead end
Linux was created as a general operating system and, simply put, automotive functional safety is not a huge focus for the community behind it. However, that should not stop automotive OEMs and Tier 1 suppliers from harnessing its power – they just need to be backed by the right software partners.
Traditionally, if someone wanted to use Linux, developers would have to fork it and create a specific variant: They take a version of Linux, isolate it from the community and try to retrofit safety into it.
At first glance, this seems logical. You own the code; you control the safety. But reality is a cautionary tale of safety drama and wasted millions. By forking, you decouple yourself from the very thing that makes Linux valuable: The power of the global community. What’s left is a safe version that is permanently stuck in the past, unable to leverage the security updates and innovations of the upstream project.
Reframing the problem: From prevention to detection
When developing EB corbos Linux for Safety Applications we knew we needed to reframe the conversation and ultimately approach.
In our last blog post and webinar, we talked about thinking of Linux as the world’s greatest trapeze artist. They are incredibly talented, versatile and high performing. Instead of trying to engineer the trapeze artist to be infallible, the smart circus director installs a safety net. It is far easier to certify the safety of the net and its anchors than it is to certify the biology of the artist.
With EB corbos Linux for Safety Applications, Linux is the trapeze artist. It runs the complex, high-compute applications. A separate Operating System Monitor acts as the safety net, by detecting any interference by the unsafe Linux kernel with the application’s safe operation. This approach allows automotive OEMs and Tier 1 suppliers to maintain the speed and innovation of open source while keeping the vehicle’s safety-critical functions, firmly under their control.
By externally monitoring and controlling system behavior, we shift the safety argument from prevention – trying to stop Linux from ever making a mistake – to detection and containment, ensuring that if Linux does fail, the system remains safe.
A question we often hear though, once a Linux kernel is placed inside an ASIL-B domain, doesn’t it inevitably become part of the safety-governed reality, regardless of how the supervisor is designed?
We agree, but with a crucial distinction. We don’t claim Linux is irrelevant to the safety story, the burden of proof has shifted:
- On Safety Governance: While an automotive OEM must still manage the Linux baseline, they are no longer required to perform a post-hoc certification of millions of lines of code. They are managing a known baseline against a specific fault model protected by the monitor or safety net.
- On Field Updates: A robust Safety Element out of Context (SEooC) approach addresses one of the most common concerns about Linux in safety-critical systems: field update management. If your monitor is designed to detect and mitigate any class of misbehavior – and the safety argument is scoped to that monitor’s coverage, not Linux’s correctness – then even an incorrect update to that partition affects only reliability or availability, not safety.
- On Architecture: Our approach is built on clear boundaries. Whether using separate partitions or a mixed-criticality same-kernel model, the safety claim rests on the layer that performs the monitoring.
Building an open path forward
When we stop trying to force Linux to be something it isn’t, we can start building systems that are both innovative and demonstrably safe. I’m looking forward to digging into all the possibilities on my webinar on June 11 at 10 a.m. CEST, titled “How Linux can meet functional safety expectations without OS certification.” Register here.
We will cover the above and more, sharing details on:
- Why certifying Linux itself is not a viable strategy
- How supervision shifts the safety argument from prevention to detection
- How a supervised Linux approach fits ISO 26262 and SEooC principles
If you can’t attend live, you can register and we’ll send you a link to the slides and a video of the webinar when it’s finished.
It’s time for architects and safety experts to engage constructively on how we use the world’s most powerful OS in the vehicles of tomorrow. At Elektrobit, we have built the net and we’re here to help automotive OEMs and Tier 1 suppliers stick the landing.
Author
Isaac Trefz
Senior Product Manager, HPC Solutions
