Open Source Summit North America 2026 and Embedded Linux Conference brought together the open source community in Minneapolis from May 18-20, 2026.
As part of the Zephyr track, Saravanan Sekar from Linumiz presented “Turning the Ignition on Safety: Zephyr RTOS in Automotive Compliance.”
The session covered three main areas: Zephyr’s technical readiness for automotive systems, automotive functional-safety standards, and Linumiz’s work on automotive-focused Zephyr support.
Automotive real-time operating systems are expected to provide low latency, deterministic performance, memory isolation, bounded scheduling latency and reliable multitasking.
Saravanan explained that Zephyr already includes several capabilities that align with these needs. Applications can interact directly with interrupt service routines, which can help reduce latency for time-critical events such as an airbag signal. Zephyr’s tickless-kernel support can also improve deterministic behaviour and power management by allowing the CPU to remain idle without unnecessary kernel ticks.
Zephyr supports memory protection through MPU- and MMU-based isolation, helping separate memory regions and prevent one part of the system from interfering with another. Its preemptive scheduling and bounded latency are also relevant for safety-critical workloads.
The talk also highlighted Zephyr’s in-tree benchmarking support. Since Zephyr 4.1, developers can measure areas such as interrupt latency, thread-switching latency, timers, mutexes and other kernel services on supported SoCs. These benchmarks can help teams evaluate whether a platform meets their timing requirements.
However, technical capability alone does not make an RTOS suitable for an automotive safety product.
Automotive functional safety is governed by ISO 26262 and its Automotive Safety Integrity Levels, or ASILs. The level is determined through hazard analysis and risk assessment, based on factors such as severity, exposure and controllability.
The talk used examples ranging from lower-risk functions to more critical functions such as airbags, braking and steering. Higher ASIL levels require more rigorous development and testing, including stronger code-coverage requirements.
Saravanan stressed that the purpose of functional safety is not to create software that can never fail. The goal is to detect faults, report them and allow the application to respond in a way that reduces risk.
ISO 26262 therefore requires a structured process covering safety requirements, architecture, module design, implementation, testing and traceability between each stage.
Zephyr’s Safety Working Group is currently working toward certification based on IEC 61508. The scope focuses on a defined subset of the kernel, including areas such as scheduling, inter-process communication and memory management.
This work follows a Safety Element out of Context approach. The goal is to provide a reusable kernel component that can later be integrated into different products.
The certification scope does not automatically include product-specific hazard analysis, SoC drivers, hardware abstraction layers, toolchains or application software. These areas remain the responsibility of the integrator.
Saravanan explained that this certified kernel subset could cover a large part of the functional-safety foundation, while the remaining product- and hardware-specific work must be completed by the SoC vendor, software supplier or vehicle manufacturer.
Linumiz is working with Infineon on TriCore architecture support, board support packages and automotive-focused drivers for Zephyr. The company’s role is to help bridge the gap between the kernel-level safety work and the needs of automotive SoCs and vehicle integrators.
The team is developing drivers and related software artifacts using functional-safety processes, with the intention of later integrating relevant work upstream.
To demonstrate this process, the talk used a tire-pressure monitoring system example.
The system monitors tire pressure and sends a CAN message to the instrument cluster when the pressure reaches a critical level. For the example, this was treated as an ASIL B use case.
Possible failures included the CAN message not being transmitted, the CAN bit rate changing while a transmission was in progress, or the CAN bus being unavailable without the application receiving an error.
These safety goals were broken down into technical safety requirements and software safety requirements. Driver-level protections, such as restricting concurrent access with a mutex and returning clear error information, could then be linked to the original safety goals.
Zephyr’s Ztest framework was used for unit testing. The tests were built through CI and executed on real hardware in the lab.
When moving between Zephyr versions, the results could be reviewed to determine whether a failure came from a software regression or from a missing safety requirement.
The presentation ended with a demonstration of a traceability dashboard created for the talk. It showed how safety goals could be linked to technical requirements, software requirements, implementation code and test cases.
This type of backward and forward traceability is a core requirement of functional-safety development because it demonstrates how each safety goal has been implemented and verified.
The session concluded that Zephyr already provides several technical features needed by automotive systems, but certification requires much more than technical performance.
Kernel certification, product-specific safety analysis, driver development, testing and traceability all need to work together before Zephyr can be used in a safety-certified automotive product.
Watch the session here. Check out the OSS NA 2026 playlist here.