Zephyr is the RTOS that Automotive Grade Linux placed beside Linux and Xen in its SoDeV reference platform, and it does not yet hold a functional-safety certificate. The Zephyr safety programme targets IEC 61508 SIL 3 for the kernel as a Safety Element out of Context, with a separate ISO 26262 ASIL D objective. The Zephyr Safety FAQ says full certification may not come before 2027. Even when a kernel certificate exists, it will cover a defined software element, not the automotive function built on it, so the integrator’s safety argument across the Linux and RTOS domains remains to be built either way.
An engineer drawing the partition plan for a software-defined vehicle controller now has an open-source candidate for every layer. Automotive Grade Linux announced its SoDeV reference platform on 5 December 2025, combining the AGL Unified Code Base, Linux containers, VirtIO, the Xen hypervisor, the Yocto Project and the Zephyr RTOS in one pre-integrated package. Linux takes the cockpit and the applications. The open question is what runs the functions that carry a safety requirement, and how far Zephyr safety work has progressed towards carrying them. This post reads what the project has published about the Zephyr safety position, sets it beside a certified commercial RTOS, and explains what the answer means for the Linux side of the same platform.
Where Zephyr sits beside Linux on an automotive platform
A consolidated automotive platform usually has more than one processing domain, and each has a different job.
| Component | Typical responsibility | Engineering consideration |
|---|---|---|
| Linux on application cores | Cockpit, cluster graphics, connectivity, media, middleware, applications, updates | Large ecosystem and driver coverage; a large and fast-moving code base |
| Zephyr or another RTOS | Real-time control, monitoring and selected safety functions | Scheduling, memory protection, bounded execution on small cores |
| Hypervisor | Separating operating-system domains that share application cores | Spatial and temporal isolation between guests |
| Safety island or separate microcontroller | Executing allocated safety functions | Lockstep cores, hardware fault detection, memory protection unit |
| Inter-domain link | Mailbox, shared memory, CAN or Ethernet between domains | Validation, fault containment, timing and availability |
Two arrangements appear in practice. In the first, Zephyr runs as a guest beside Linux on shared application cores, and the hypervisor supplies the separation. In the second, Zephyr runs on a physically separate safety island or microcontroller, and the two domains meet only at a communication link. In the second arrangement the hypervisor is not in the path between Linux and the safety function at all. The SoDeV announcement lists the components but does not state which arrangement a given deployment should use, and the two produce different safety arguments.
Application cores Safety island / MCU
+-------------------------+ +-------------------------+
| Linux: HMI, connectivity| mailbox | Zephyr or certified RTOS|
| containers, updates |<--------->| control and monitoring |
+-------------------------+ or CAN +-------------------------+
| Hypervisor (if shared) | | Lockstep cores, MPU |
+-------------------------+ +-------------------------+The figure is conceptual. Hypervisor placement, hardware partitioning and the certification boundary depend on the target SoC.
What a certificate covers, and what it does not
A certificate applies to a defined software element in a defined configuration, under the assumptions its safety manual states. It does not make the application or the ECU safe. The integrator still has to show that the assumptions hold on the target, and that the complete function meets the requirements allocated to it. The value of a certified RTOS is that reusable evidence already exists for one part of that argument.
Five terms are worth keeping apart, because the documents discussed below use all of them.
| Term | Meaning |
|---|---|
| Certification objective | The standard and integrity level being targeted |
| Concept approval | An assessor’s approval of the approach, not of a finished product |
| Safety evidence | Requirements, verification results and analyses supporting an argument |
| Assessed baseline | A specific version and configuration evaluated against defined requirements |
| Certification | A completed assessment, recorded in a certificate with a defined scope |
IEC 61508 SIL 3 and ISO 26262 ASIL D also need to be kept apart. They belong to different standards. Evidence produced for IEC 61508 can be reused in an automotive assessment, but a SIL 3 certificate does not by itself establish ISO 26262 ASIL D compliance. Automotive-specific development, verification, tool qualification and integration requirements may need additional work. The Zephyr Safety FAQ itself records one such gap, discussed below.
The case for a certified RTOS on the safety island
The reasons a safety engineer puts a critical function on an RTOS, and specifically on one with a certificate, are technical and should be stated before any Linux-side response.
The first is the silicon. Safety islands and automotive microcontrollers are typically built around lockstep cores with a memory protection unit rather than a full memory management unit. A general-purpose Linux kernel is built around an MMU and is not the natural occupant of those cores. An RTOS is designed for them.
The second is a manageable assurance scope. The Zephyr project’s safety architect described the intended Zephyr safety scope at Embedded World on 11 March 2026 as approximately 15,000 lines of code, covering kernel services, system initialisation and APIs. Size is not evidence of safety: control-flow complexity, concurrency, interrupt behaviour, hardware dependencies and configuration variability all drive assurance effort. But a small scope keeps that effort within reach of a defined team.
The third is evidence that already exists. QNX OS for Safety is listed on the vendor’s certifications page at IEC 61508 SIL 3, ISO 26262 ASIL D and IEC 62304 Class C, linking to TÜV Rheinland register entry 968/FSP 2999.02/26. As read on 12 September 2026, that entry also placed the supplied tool chain inside the assessed scope at TCL3 and T3. An integrator choosing that product starts from an assessed baseline and a safety manual, though the item-level work described above still remains.
The fourth is accountability. A commercial certificate has one holder, who issues corrective actions and maintains the revision list with the certification body.
The fifth is timing. A small RTOS has fewer kernel mechanisms between an interrupt and the task that handles it, which simplifies the analysis of response and scheduling latency. Worst-case timing still has to be established for the specific hardware, configuration and workload.
Together these give a certified RTOS a stronger existing evidence position for ASIL C and D functions. Overall programme risk also depends on hardware support, integration complexity, licensing and supplier support, so the evidence position is not the whole decision. It is the part that is hardest to create late.
What the Zephyr safety work has produced so far
The Zephyr Safety FAQ, last edited on 30 March 2026, states that the initial scope of Zephyr RTOS certification is IEC 61508 SIL 3, and that the scope includes all kernel components, with further components and configuration matrices still being refined. Specific target hardware, devices and compilers are out of scope. The integrator must qualify their own compiler and any third-party libraries outside the certification scope. Any modification to the Zephyr baseline requires an impact evaluation and possibly a repeat of safety lifecycle activities. The Zephyr safety evidence and safety manual are available only to specific tiered members of the project.
On automotive, the Zephyr Safety FAQ states that a contract exists with the project’s assessor for ISO 26262 with an objective of ASIL D. It records a gap: the team does not plan modified condition/decision coverage, which the FAQ notes ASIL D prescribes. That is an example of the SIL 3 and ASIL D difference described above. The FAQ does not name the assessor. Its near-term goal is an end-to-end example during 2026, and it says full certification may not happen before 2027 or later.
A paper presented at the first Zephyr in Science and Education conference in September 2025, published on 13 March 2026, reports that the project received written concept approval towards IEC 61508 certification of the kernel in 2024. It describes the kernel as being qualified as a Safety Element out of Context through the IEC 61508 Route 3S pathway, and notes that requirement identifiers have not yet been added to the main Zephyr repository, so end-to-end traceability remains a proof of concept.
A project blog of 13 August 2026, summarising a talk at Open Source Summit North America, describes the boundary from the automotive side. The safety scope is a kernel subset covering scheduling, inter-process communication and memory management. Product hazard analysis, SoC drivers, hardware abstraction layers, toolchains and applications are excluded and fall to the integrator.
Read together, these give a consistent Zephyr safety position. As of the March 2026 FAQ, Zephyr has a stated objective, a defined kernel scope, a reported concept approval and an assessor under contract. It does not offer a completed certificate for that scope or a public certificate reference. Whether member-held evidence is enough to support a particular programme before certification is a question to settle with the project.
What changed between 2019 and 2026
The first public statement of the Zephyr safety programme is dated 14 February 2019. It announced that Zephyr would target IEC 61508 SIL 3, that the submission would cover the core OS of the long-term support release due in mid-2019, that an ISO 26262 ASIL D submission was planned, and that the project was working with a certification authority. No assessor and no completion date were given.
The 2026 Zephyr safety documents differ in three ways. The scope is narrower and stated: the kernel, with hardware, drivers and compilers explicitly excluded. The target is described as a process rather than a release: the FAQ names no Zephyr version, and the project describes its long-term goal as continuous certifiability, with documentation kept in step with the main branch. The January 2026 project blog lists the steps taken so far: MISRA-style coding rules, static analysis in the workflow, traceable requirements and documentation generated with StrictDoc. And the dates have moved: a submission planned around a 2019 release has become a concept approval reported for 2024, an end-to-end example targeted for 2026 and full certification that may not arrive before 2027.
The Zephyr safety roadmap has therefore moved from a release-oriented submission towards repeatable safety processes on a living code base. That brings real engineering problems: change control on an open contribution model, traceability from requirements to code and tests, and a defined baseline that an assessor can sign. The public documents do not state that this change alone explains the timeline, and this post does not claim it.
Freedom from interference between the Linux and RTOS domains
Placing Linux and a safety RTOS in separate domains is the start of the argument, not the end. The integrator has to show that faults and resource consumption on the Linux side cannot invalidate the requirements allocated to the RTOS side. A certified RTOS does not supply that assurance for the whole platform; it has to be built for the actual hardware and software.
| Interference type | Example |
|---|---|
| Spatial | A Linux driver or DMA-capable device writes into the RTOS domain’s memory |
| Temporal | Contention on shared caches, memory controllers or interconnect delays a safety task past its deadline |
| Communication | Malformed, stale or excessive messages from Linux reach the safety function |
| Resource | Linux workloads consume shared bandwidth, power or thermal headroom |
| Fault propagation | A Linux failure triggers an unintended reaction in the safety domain |
The arrangement decides which rows dominate. When Zephyr shares application cores under a hypervisor, the Zephyr safety evidence says nothing about the hypervisor, and the spatial and temporal rows depend on the hypervisor and the SoC’s memory system. When Zephyr runs on a separate safety island, spatial isolation comes largely from the hardware, and the communication and fault-propagation rows dominate. In both cases the safety domain has to treat everything that arrives from Linux as untrusted input.
Where Linux sits in this comparison
For safety functions on dedicated lockstep microcontrollers with limited memory and strict timing constraints, a small RTOS is the more natural choice than Linux, for the silicon, scope and timing reasons above. Linux remains relevant for safety-related functions on application processors where an assessed platform and isolation mechanisms exist. Red Hat announced on 20 May 2025 that Red Hat In-Vehicle Operating System is certified as a Safety Element out of Context against ISO 26262 at ASIL-B, with exida as assessor. The decision is therefore not Linux against an RTOS. It depends on the function, the processing domain, the hardware and the evidence available for the chosen configuration.
On the functions Linux usually carries, such as graphics, connectivity, media, camera pipelines, containers and the update path, the comparison runs the other way, because an RTOS is not built to carry that driver coverage and ecosystem. If you want the timing side of the comparison, we covered how PREEMPT_RT and an RTOS differ in real-time Linux versus an RTOS.
The Linux team also owns a concrete work product in the safety argument: the specification of the interface towards the safety domain. It states what Linux sends, at what rate, with what validity checks, and what the safety domain should assume when messages stop. That document is needed whichever RTOS is chosen.
How to evaluate an RTOS for a given function
ASIL level and schedule alone do not settle the choice. A function entering production in 2028 at ASIL B may still need an already assessed baseline if the programme cannot absorb certification uncertainty, while a team with strong safety experience may justify a different route. These questions make the evaluation repeatable.
| Criterion | Question to ask |
|---|---|
| Safety classification | What ASIL is allocated to this software function? |
| Hardware architecture | Does it run on application cores, a real-time core or an independent microcontroller? |
| Timing | What are the maximum response times, and how will they be measured on the target? |
| Certification evidence | Is there an assessed baseline covering the intended use, and which version and configuration does it name? |
| Hardware support | Are the processor, drivers and required hardware safety mechanisms supported, and what does the evidence assume about the silicon? |
| Toolchain | What tool qualification or confidence activities are required? |
| Integration responsibility | Who supplies the safety manual, the verification evidence and the missing work products? |
| Lifecycle | How will security updates and software changes affect the safety case? |
| Schedule | When must the evidence be available for programme milestones? |
The Zephyr safety blog’s own automotive example shows why the kernel is only part of the answer. Its August 2026 blog describes a tyre-pressure monitoring function treated as ASIL B, sending a CAN message to the instrument cluster. Even with reusable kernel evidence, that function still needs assessment of the sensor inputs, the CAN driver, message transmission, fault detection, response timing and the vehicle-level reaction to missing or wrong pressure information. The Zephyr safety evidence would cover the scheduler and memory management beneath it. The rest belongs to the integrated function.
What a Zephyr safety certificate would change
The question for an open RTOS is no longer whether it can schedule deterministically or protect memory. It is whether the project can produce and maintain the evidence a safety product needs, release after release. Commercial certified RTOS products keep a clear advantage where established evidence and a predictable schedule are essential. Zephyr offers a different option: an openly developed kernel with a safety process being built around it, which could in time give integrators an alternative to proprietary software in selected domains. For the Linux engineer, the useful outcome is the same in both cases: a safety domain whose evidence is defined, and an interface to it that the Linux side can specify and test.
Key takeaways
- Zephyr does not yet hold a functional-safety certificate. Its FAQ of 30 March 2026 targets IEC 61508 SIL 3 for the kernel, records an ISO 26262 contract with an ASIL D objective, and says full certification may not come before 2027.
- A SIL 3 certificate would not by itself establish ASIL D; the FAQ already records a coverage gap between the two.
- Any RTOS certificate covers a defined element and configuration. It does not certify the application, the ECU or the freedom from interference between Linux and the RTOS.
- The Zephyr safety scope is the kernel, about 15,000 lines by the project’s own figure; drivers, hardware abstraction, toolchains and applications stay with the integrator, and the evidence is available to members only.
- QNX OS for Safety holds an assessed ASIL D position with its tool chain in scope, which gives it a stronger existing evidence position for the hardest functions.
- On lockstep safety microcontrollers an RTOS is the natural choice; Linux remains relevant for lower-ASIL functions on application processors, and its team owns the interface specification towards the safety domain.
Frequently asked questions
Does Zephyr hold a safety certificate?
Not yet. The project targets IEC 61508 SIL 3 for its kernel and reports a concept approval in 2024, but its FAQ says full certification may not happen before 2027 or later.
Would a SIL 3 certificate make Zephyr ASIL D?
No. IEC 61508 and ISO 26262 are different standards, and the Zephyr Safety FAQ itself notes that the team does not plan the MC/DC coverage it says ASIL D prescribes.
Does the Zephyr safety scope cover drivers and the compiler?
No. Specific hardware, devices and compilers are out of scope, and the integrator must qualify their own compiler and any third-party libraries outside the certification scope.
Does a certified RTOS make my ECU safe?
No. The certificate covers a defined software element under stated assumptions. The integrator still has to show that the assumptions hold and that the complete function, including freedom from interference with Linux, meets its requirements.
Further reading
- Zephyr Project Safety FAQ (project wiki, last edited 30 March 2026)
- Zephyr Project, 14 February 2019 — first functional-safety certification submission
- Zephyr Project, 8 January 2026 — a decade of Zephyr
- Zephyr Project, 13 August 2026 — how Zephyr aligns with automotive functional safety requirements
- Bagnara et al., “Zephyr: An Ideal Platform for Introducing the Software Development Processes of Safety-Critical Embedded Systems”, ZiSE 2025
- Embedded World 2026 talk summary, Zephyr’s roadmap to a pre-certified kernel (summary by the speaker’s employer)
- QNX certifications and compliance page (vendor page, read 19 October 2026) and TÜV Rheinland register entry 968/FSP 2999.02/26
- Automotive Grade Linux, 5 December 2025 — SoDeV announcement
- Red Hat, 20 May 2025 — In-Vehicle Operating System SEooC at ASIL-B
