ASIL Operating Systems - Which is your new pick?

4 years ago, we researched on the landscape of ASIL qualified RTOSs available in the market. You can find the article here. While we were already familiar with several well-known and widely adopted solutions, we were surprised that the ecosystem was far broader and diverse than we had anticipated, with many more RTOS options addressing automotive functional safety needs.

Fast forward to the start of 2026, how has this market changed? What new operating systems have entered the market, and how has their role changed in response to the industry’s rapid transformation? That’s what this article is about.

With the steady rise of semi-autonomous and fully autonomous vehicles, and the transition towards a software-on-wheels paradigm, it is not surprising that the notion of an “Operating system” has significantly shifted. Traditionally, an operating system is “a software that manages computer hardware and software resources and provides common services for computer programs.” It sandwiches between the hardware and the Application and supports the running of the Application by providing the required resources and services. Today, the term operating system is increasingly used in a much broader sense. In many modern automotive platforms, it represents a “software development kit” that bundles together not only the core OS, but also a wide range of libraries, middleware, communication stacks, diagnostics, health management services, and development tooling. The Operating system is just one component within the larger SDK. Several SDKs like Drive OS, Apex OS, BMW Operating System 9 (OS 9) etc are labelled as Operating Systems but are rather SDKs built for SDVs and Autonomous vehicles.

Let’s separate the kernel from the packaging. In this article, we have deliberately taken out of scope, SDKs that are labelled as operating systems and focused on true operating systems. Let’s dive deeper into the recently announced Operating Systems (i.e., in the last 4 years) and examine what they offer. 

Disclaimer: The information presented here is based solely on publicly available documentation; it may not represent a complete or exhaustive description of each offering.

The OSs we will cover in this article are:

1. Pike OS
2. Cesium RTOS (Cs/OS2 and Cs/OS3 kernels)
3. EB corbos Linux for Safety Applications
4. Segger embOS-Safe
5. Red Hat In-vehicle OS

The below graphics for each OS highlights its highest ASIL level, Safety certifications and key technical safety features (limited to whatever is shared by the OS vendor).

 

Conclusion

From the early days of OSEK-VDX to Classic AUTOSAR, automotive operating systems have evolved significantly over the past two decades. Modern platforms such as PikeOS go a step further by enabling the coexistence of Classic AUTOSAR OS and POSIX-based operating systems as guest OSs, allowing the reuse of legacy software within a software-defined vehicle (SDV) ECU context.

Today’s automotive operating systems are architected with software-defined vehicles in mind. They provide the necessary technical capabilities and embed safety-related design principles that allow safety-critical and non-safety applications to coexist and execute reliably on shared hardware.

However, as vehicles continue to evolve, the true value of an ASIL-qualified OS extends beyond its ASIL rating or feature set. It lies in how effectively the OS supports continuous safety assurance across frequent software updates, along with proactive management of vulnerabilities. This continuous proactive approach will ensure that weaknesses introduced over time do not propagate into damage scenarios/hazards.