OSS + ELC EU 2026

Over the last decade, Zephyr has grown from a focused open source RTOS into one of the most widely adopted platforms for connected, secure, and portable embedded systems. That success brings new challenges: more architectures, more boards, more vendors, more contributors, more downstream users, and higher expectations around quality, security, safety, documentation, testing, and long-term maintenance.

This talk looks at Zephyr’s evolution through the lens of project sustainability. It will highlight where the current model is working, where scaling pressure is becoming visible, and what the community needs to address to keep Zephyr healthy for the next 10 years. Topics include maintainer bandwidth, review latency, infrastructure load, test and sample growth, vendor enablement, downstream compatibility, long-term support, security updates, dependency management, and the tension between a unified upstream and the need for product- and platform-specific innovation.

A decade after its launch, Zephyr has grown from a small RTOS into a capable, MMU-aware, userspace-supporting system running on application-class cores. So people keep asking: can it replace Linux? A better question is how the two can work together - and Zephyr already has what it needs to do that.

This talk shows how Linux and Zephyr run side by side on the same SoC, using parts Zephyr ships today: the IPC service layer, OpenAMP and RPMsg for messaging between the two cores, mailbox and shared-memory backends, and the mechanisms that let Linux start and stop Zephyr firmware. Based on real work on NXP i.MX and i.MX RT platforms, I'll show how these pieces fit, and where the hard parts are - memory layout, buffer sizes, address translation, and shutdown order.

The takeaway: after ten years, the interesting frontier isn't replacement. It's connecting the two so each kernel does what it's best at on the same chip.

Infineon's AURIX family of automotive microcontrollers is based on the TriCore architecture and is widely used across automotive systems, from powertrain and chassis control to safety-critical ECUs. This talk presents the upstream effort to add TriCore architecture support and enable Infineon AURIX TC3x and TC4x devices in Zephyr (https://github.com/zephyrproject-rtos/zephyr/pull/107516).

Starting from CPU reset, we will walk through the key architecture bring-up steps required to reach the first Zephyr thread, including trap and interrupt handling, Context Save Area (CSA)-based context switching, and system timer integration. We will also cover the work required beyond the architecture layer, including SoC support, board enablement, and QEMU-based development and testing.

Finally, we will discuss the challenges of upstreaming a new architecture into Zephyr, from toolchain and CI integration to HAL dependencies and ecosystem support, along with the remaining work needed for automotive and safety-critical systems.

As part of the ongoing effort to achieve IEC 61508 certification, Zephyr's requirements capture process is underway. Yet there is still no clear picture of how these requirements trace to the tests that verify them or the code that implements them. Safety evidence is largely documented evidence, so the primary concern is generating auditable documents: requirement and test specifications, test reports, and traceability matrices.
The challenge is collecting this evidence in a community-compatible way — low-friction processes and tooling that developers and maintainers will accept.

This talk proposes a pipeline built on Zephyr's existing documentation tools (Doxygen/Sphinx) to extract the needed information from annotated source and tests, then trace it back against requirements into an end-to-end chain.
Two demos are shown: a minimal working example against Zephyr itself, and a self-contained pipeline for a Zephyr module the authors maintain. Required process adaptations and guidelines are explained. The work is an open proposal for discussion; once agreed, it gives the community a scalable foundation to advance safety efforts, with concrete tasks contributors can pick up.

Zephyr’s security response is run by a small, mostly volunteer team handling a large and growing workload. Every vulnerability report must be triaged against a million-line codebase, confirmed in source, scored, mapped to a CWE, written up as a CVE record, documented for disclosure, and tracked across multiple release branches — often under embargo deadlines that don’t move. It’s repetitive, high-stakes work, and it’s exactly the kind of burden that burns maintainers out.

This talk is a candid look at how we started using AI to help: grounding analysis in the source tree with file:line citations, drafting CVE records against a strict schema to prevent fabricated fields, and reducing release vulnerability accounting from hours to minutes. It covers what worked, what failed, and the guardrails we built to keep a human in the loop. You’ll leave with a practical blueprint and checklist for using AI in security response — and an honest view of where it helps and where it’s still a liability.

SBOMs for embedded firmware are harder than simple dependency lists. A Zephyr-based product typically combines upstream Zephyr code, vendor HALs, out-of-tree modules, binary blobs, generated files, Kconfig and devicetree configuration, and of course user/application code. Some of these pieces end up in the final firmware image, some do not, and yet it is important to have a clear picture of what was used, what was changed, and what actually shipped. This is what helps teams avoid chasing false positives, while still knowing when a new CVE might really affect them.

In this talk, we will look at Zephyr’s SPDX-based SBOM generation, including its recently added support for SPDX 3.0. We will show why it is useful to describe not only _which_ components are present, but also _why_ they were pulled into the build and how they relate to each other.

We will also discuss how build-aware SBOMs can directly support vulnerability management and help prepare for regulations such as the Cyber Resilience Act.

Using Zephyr in space is not only a question of choosing an RTOS. A space computer is a system architecture: boot firmware, supervisor logic, watchdogs, safe mode, recovery paths, update policy, hardware monitoring, FPGA or SoC configuration, and the boundary between platform software and mission-specific applications all matter.

This talk looks at Zephyr from that system-architecture point of view. Based on Space Cubics’ OBC development experience and recent Space Grade Linux discussions, it explores where Zephyr can fit in future space systems: mission RTOS, payload-controller OS, supervisor/control-plane OS, or companion to Linux. Space already has credible RTOS options, but Zephyr can bring value if the ecosystem develops a clear architectural story around boot, recovery, observability, hardware control, and responsibility boundaries.

Attendees will leave with a practical checklist for evaluating Zephyr’s role in a space computer: what Zephyr should control, what should remain outside it, what must be recoverable after launch, and how to structure boot, update, monitoring, isolation, and fault-handling responsibilities.