OSS + ELC EU 2026

There is an increasing demand for functional safety and certifying Zephyr RTOS from SoC vendors and companies wishing to make medical and automotive products. In the meantime, there is a lot of pushback from developers who believe that open source software is not compatible with the rigors and the processes required by functional safety.
Alexandre Bailon is an active Zephyr developer who had no knowledge about functional safety. After attending numerous talks, he found himself facing more questions than answers.
Alexandre Bailon will give the talk he would have expected as an open source developer. He will first explain what functional safety is and why this is a must-have for Zephyr RTOS.
Then, he will try to address developers' concerns and tackle some common misconceptions they have. In addition, he will talk about the safety working group and how it aims to minimize the burden on contributors and maintainers while meeting certification requirements.
To finish, he will discuss the current initiatives and opportunities for community involvement in advancing functional safety support in Zephyr.

In automotive systems, interest is growing in OSS adoption, Software-Defined Vehicles (SDV), and mixed-criticality architectures. In initiatives such as AGL and SoDeV, configurations combining Linux, RTOSes, and hypervisors are becoming a key focus. In this context, Zephyr may be used as a small RTOS domain with a limited, well-defined role.

This session views Zephyr and Xen as complementary components. Xen can provide domain isolation and resource partitioning, Linux can host high-level services and integration layers, and Zephyr can handle focused RTOS functions. It outlines role division in OSS-based automotive software.

Functional safety is also important. The Zephyr Safety WG is advancing related activities, treating safety readiness not as certification itself but as a technical foundation—requirements, tests, and documentation—that the community can build together. This session discusses how automotive stakeholders can participate and contribute upstream.

Based on Linux/AGL mixed-OS integration experience, this case study discusses what should be addressed when applying Zephyr and Xen to automotive systems and how these efforts can advance with the community.

The IEC 60730 Class B standard defines safety requirements for automatic electrical controls in household appliances, mandating diagnostic mechanisms that ensure safe operation under fault conditions.
Despite its widespread adoption, IEC 60730 implementations remain fragmented and vendor-specific, typically delivered as proprietary libraries tightly coupled to individual MCUs. This approach limits portability, duplicates engineering effort, and prevents meaningful integration with modern open-source ecosystems.
This talk presents an open, reusable IEC 60730 Class B diagnostic framework built on Zephyr RTOS, demonstrating how functional safety mechanisms can be implemented in a portable and extensible way. The framework includes key diagnostics such as power-on self-tests, periodic runtime checks, watchdog supervision, and safe-state handling.
This work establishes a foundation for standardizing safety mechanisms in Zephyr and aims to catalyze community collaboration around common APIs and reference implementations for safety-critical embedded systems.
The session is targeted at embedded developers working on consumer appliances and industrial control systems.

Zephyr RTOS is increasingly relevant for safety-related and
mixed-criticality systems, where qualification and certification must
address standards such as IEC 61508 and ISO 26262. A key question is
how to provide evidence that software components are independent, that
freedom from interference is preserved, and that future changes can be
assessed without redoing unnecessary qualification work.

This session presents ongoing work on reverse engineering Zephyr's
effective software architectural constraints using static
analysis. Starting from concrete Zephyr configurations, we model
components, observe calls and data accesses, identify dependencies,
and compare the result with the project's intended layered
architecture.

The talk will show how this analysis supports safety arguments by
making software-level independence explicit and checkable. It will
also show how the same model enables Change Impact Analysis: when a
qualified Zephyr version or configuration evolves, the model helps
determine which components, assumptions, tests, and safety evidence
are affected. This is essential to make Zephyr's safety effort
sustainable over time and viable for safety-related development.

Zephyr makes it easy to build the same code for multiple board targets. native_sim lets you run (parts of) your zephyr application and associated tests as a regular Linux process, allowing reproducible runs, easy debugging and CI integration.

In this talk, I will share what we learned structuring, testing, and debugging several real-world Zephyr applications:

* The native_sim execution model: How time is handled
* How to emulate hardware: Fake drivers, virtual bluetooth controllers, networking, PTY UART, emulators
* Examples of what can be built using these primitives:
* Connecting to the Android Emulator over BLE
* Writing Zephyr tests using the Cucumber framework
* ...
* Tooling around native_sim: twister, sanitizers, GDB, code coverage
* Integrating external binaries into twister through the pytest harness
* Designing for testability: Separating business logic from hardware-dependent software units
* When native_sim is not enough: Running tests in qemu or on real hardware

The goal of this talk is to provide a broad overview about what is possible thanks to native_sim, hopefully inspiring new ideas on how to test code without ever touching hardware.

In Zephyr, subsystems, middleware, and application components typically depend on one or more lower-level device driver APIs. For testing these upper-level subsystems in isolation, the lower-level driver dependencies must still be satisfied. A popular software design pattern for this is to use test doubles. However, how can this be achieved in Zephyr without introducing test-specific changes to the upper-level subsystem?

The solution is to use fake drivers. This presentation will explore various use cases for employing fake device drivers as test doubles, examine the structure of a fake driver implementation, and demonstrate how fake drivers can be used to not only satisfy test dependencies, but also facilitate test case isolation, driver API call inspection and instrumentation.

Embedded test automation is often limited by something simple: wires. External loopback, testing another peripheral instance, validating a power domain, or connecting to external equipment can each require a different setup. As coverage grows, teams end up with custom fixtures, manual steps, fragile lab instructions, and CI systems that cannot reproduce a developer’s bench setup.

This talk presents an open source framework that uses a low-cost, off-the-shelf FPGA board as a programmable routing fabric. It sits between the device under test and the rest of the setup, routing pins to loopbacks, other peripherals, boards, or tools.

The framework is software-agnostic: it works with Zephyr, Linux, bare metal, or vendor SDK testing. Tests declare the needed connections, metadata describes the FPGA-to-device wiring, and the framework generates per-test Verilog, runs open source FPGA tools, and programs the FPGA.

The talk will cover lessons from real tests, common peripheral limits, demo and how to reproduce this setup at a desk, in a lab, or in CI.

Key benefits:
*Low-cost off-the-shelf hardware
*Open source software
*Easier developer desk testing
*More CI/CD regression coverage

Zephyr is a comprehensive ecosystem, but sometimes you want a better view of your system and end up reaching for shell, UART, printk, RTT, or tracing, all of which work, but all of which cost on-target code, pins, or configuration overhead, or even extra hardware.
ZView is a live, non-intrusive, low-integration-cost runtime observability tool that provides an overview of how your application behaves (threads, heaps, allocation and fragmentation, CPU usage, and more) all in a TUI, using only your debug probe via SWD.
It uses the debug access port to read kernel memory passively while the target keeps running. No instrumentation, no halt, no extra pins. ZView interprets what it reads, recognizing threads, heaps, and other kernel objects, turning raw memory into actionable runtime insights.
This talk covers what ZView is, how it works, its limits, and where it can go next. The goal is to make ZView a standard part of the Zephyr debugging toolkit, with the community's help.