Open Source Summit Europe 2024

The Zephyr sensor driver API is a popular area for new contributors to submit code upstream; a sensor driver is well-contained, it doesn't touch more intimidating or complex subsystems, and most importantly, it enables your Zephyr application to interact with the physical world in a new way. Naturally, you want to share it with the open source community, but how do you do it? This talk will share best practices and common pitfalls encountered by new contributors submitting their first sensor driver, and provide insight into why maintainers request certain changes.

The Zephyr build system had been reaching its limits in its ability to build multiple images for modern SoCs in its previous hardware model.
The original build system began with the concept of a simple board containing a single core SoC for which you would build a single image. In today's world however, developers want to build multiple images for boards which may have multiple SoCs and / or SoCs with multiple CPU cores. This evolution towards complexity led us to the development and introduction of sysbuild and a new hardware model in Zephyr.

The purpose of this talk is to dive into the new hardware model, and what it provides seen from a developer's point of view, and from there continue into sysbuild, where the new hardware model is leveraged in order to build multiple images for a single device. The talk will go over how you as a developer can make the best use of the new hardware model and sysbuild to effectively build a complete project.

MCUboot enables secure booting of Zephyr RTOS using asymmetric cryptographic signature verification with a public key. The hash of the public key is embedded or compiled with the MCUboot binary by default, which is used for checking the integrity of the public key. To tamper-proof, as an alternate secure boot option, the hash of the public key can be stored securely and retrieved when hardware keys are enabled. Security of embedded SoC's (e.g., i.MX RT) offers more capabilities, such as High Assurance Boot (HAB), Data Co-Processor (DCP), or Trusted Firmware-M (TF-M) implementing the Trustzone for SoC's (e.g., nRF91) to enable secure storage with hardware crypto acceleration or external security modules (e.g., TPM, EdegeLock) to store keys in hardware vaults.

This talk will detail MCUboot secure booting with hardware keys. NXP i.MX RT as an example using HAB for booting singed and encrypted bootloader MCUboot, enabling hardware root of trust, and booting Zephyr RTOS using keys from OTP for verification. We will also see about using the TF-M backend and OTP for secure booting Trustzone-enabled SoCs.

Network connectivity is important part of Zephyr. This talk will give information of current status of the network stack.

RISC-V's instruction set architecture (ISA) has enabled seasoned embedded software engineers to experiment with FPGAs since numerous open-source RISC-V cores can be flashed onto an FPGA.

The Zephyr Project is rapidly emerging as a leading real-time operating system (RTOS). Zephyr integrates open-source and security best practices to ensure a vendor-neutral, secure, and reliable platform.

One of the exciting features of the RISCV ISA is the Custom Function Unit (CFU), which enables a framework to support custom operations in hardware, which is accessible from software. In this talk, Mohammed will demonstrate how to add a CFU into a RISCV core on an FPGA, and how to make the appropriate calls from Zephyr.

Code portability is one of the compelling benefits of adopting Zephyr. In this session we will discuss a single AI-based face detection application that scales from a high performance, Arm Cortex-M7 based MCU to a low power Cortex-M33 based MCU with a neural processing accelerator. In addition to different main processor cores, these two platforms have quite different camera and display interfaces, and one has a limited frame buffer capability, leading to required improvements in the display driver which NXP has contributed back to the project. This session will also explore the specifics of how devicetree and Kconfig were leveraged to switch between platforms.

Share how Ampere Computing uses Zephyr to re-imagine the cloud in a more sustainable way. Covering some of the challenges encountered aligning product goals with Zephyr, adding new code coverage beyond the upstream support, and getting a test environments up and running.

In order for highly distributed communication to function well, there must be a reliable time source and a way to synchronize time between devices. In applications such as automotive and industrial control, the requirements here can be strict and subject to regulatory constraints. Precision Time Protocol (PTP) is a response to these hard time synchronization requirements by achieving clock accuracy in the sub-microsecond range.

As Zephyr becomes more broadly used in these environments, it needs support for precision timekeeping. This talk will cover a brief overview of PTP, discussion of various implementation choices for Zephyr, challenges along the way and upstreaming plans.

Monitoring wildlife and environmental changes often requires deploying remote camera traps that can capture imagery and activity over long periods of time. These camera systems need to be low-power, portable, and easily adapted to different hardware configurations based on project requirements.

This talk will cover how we utilised Zephyr to develop flexible time lapse camera solutions for conservation applications. We’ll explore our time lapse camera deployment in Bermuda and how we’re using Zephyr to monitor and understand the impact of seagrass decay on the local marine life. Zephyr allowed us to rapidly target different hardware platforms by abstracting away complex hardware interactions. We'll discuss how Zephyr's hardware and driver APIs simplify peripheral access to cameras, RTCs, and power management features across multiple vendor SoCs.

Additionally, we'll explore challenges associated with this kind of cross-platform support, such as lack of core features for certain vendor SoCs. We'll also share insights into optimising for size, performance, and battery life on constrained embedded devices.

In the automotive industry more than 100 embedded control units (ECUs) are present in a typical car. They are equipped with microcontrollers responsible for various peripherals within the vehicle. Although it may be challenging to adapt automotive-specific interfaces to an IoT-driven RTOS like Zephyr, the use of standard peripherals such as GPIOs, I2C, and UART can lead to significant synergies with other products.

However, as starting point, the talk will delve into the automotive specific requirements and technology stacks necessary for integrating Zephyr into automotive development. Additionally, it will highlight areas where Zephyr may not yet be a perfect fit for automotive applications. Key touchpoints for discussion will include the compatibility of Zephyr with established automotive standards like Autosar, COVESA VSS, and CAN stack. Furthermore, the talk will address the challenges related to process compliance and adherence to safety integrity standards in the automotive industry.

This talk aims to initiate a discussion on the potential wider adoption of Zephyr in automotive products and to foster an engaging discussion among industry professionals.

Complex, real-life embedded system deployments often consist of multiple SoCs/MCUs running a mix of OSes, ranging from user-facing high-end nodes based on Linux/Android to MCUs dedicated to controlling specific low-level functions of the device, using an RTOS like Zephyr. Over-the-air updates for such systems poses a challenge, as the firmware needs to be updated in a safe & coordinated way.

Remote Device Fleet Manager is a permissively licensed, fully open source and self-hostable framework for modular, configurable OTA updates, fleet management and ML data management that supports Linux, Android, and, since recently, also Zephyr-based platforms.

This talk will delve into how RDFM was extended to support Zephyr-based systems, the motivations and considerations of the development and some interesting use cases it enables. RDFM allows for fully redundant updates, incl. rollback to the previous version, grouped device updates and mixed OS deployments.

To enable tight interoperability with Zephyr's ecosystem, the integration is based on the MCUmgr library, communicating with Zephyr devices via the SMP protocol. The MCUboot bootloader is used for managing the firmware on the device.

Firmware Over The Air (FOTA) updates are a well-established method for updating devices, but this approach shows its limitations in the embedded world. Indeed, in embedded systems we have 2 main constraints (among others) when discussing firmware updates : memory and bandwidth. Regarding memory, developing a low-memory-footprint API was our priority when creating this solution. To explain how we built this API, we will discuss compression algorithms and justify our choice of implementing in Zephyr the open-source library "Heatshrink" which is ideally suited for DFOTA's needs and for embedded systems in general (we can demonstrate the memory footprint differences compared to the already implemented compression algorithm "LZ4"). Next, we will see how deltas (or patches) between two firmware versions are generated (we could present a benchmark to illustrate the data savings achieved by sending patches instead of the full firmware, as it is done during FOTA update). Further, we will explore the implementation of the DFOTA API to explain how it works and how it can be implemented into your project.

In this lightning talk I'll show you how to create a working PoC of an asset tracker with very little effort by using Zephyr. It's based on an off-the-shelf cellular SoC that sends GPS data over CoAP to the open source Thingsboard IoT cloud platform.

Using Zephyr OS, we successfully developed three firmware versions in under two years, establishing a scalable wireless sensor network for enhanced railway infrastructure monitoring.

This talk will detail the rationale behind our technology selections, including Zephyr OS, BLE, LTE-M, and AWS Iot Core.

We will discuss specific features of Zephyr that facilitated rapid development and the aspects that presented a learning curve. Our session will explore critical design decisions, architectural frameworks using Zephyr, and effective strategies for MCU communication and optimizing battery life. It will show how projects are setup, dependency are managed using west, how firmware is tested, and which features of zephyr we use where. We'll also share common pitfalls and practical lessons learned.

Concluding with recent Zephyr updates and our reflective insights, this presentation will end with what we would have done differently this time.

Zephyr, as also other open source projects, is heading towards functional safety, to achieve a safety certification as a Safety Element out of Context (SEooC) the question of what this really means comes up quite often.

There are usually three stakeholders in a project like project community, the assessor and the user, who actually wants to use the certified software

As all these parties have different expectations of what this certification will require, there are a lot of different rumours and opinions out there regarding functional safety certification. This talk will give an introduction to what qualification evidence is usually prepared and assessed for a SEooC certification, what this means for the project and how it can actually be integrated into a safety relevant software system.

This talk will also give an update of the current status of the safety working group, how to participate and what to expect there.

Developing embedded software for regulated environments like medical devices presents unique challenges. Crucially, we need to document how the software design fulfills stated product requirements. While functional testing remains dominant for verifying functional suitability, deriving and maintaining effective test suites can quickly become cumbersome.

This talk explores a novel approach to this longstanding problem. We leverage NASA's FRETish method for formally capturing requirements. We will talk about how the formal nature of FRETish requirements allows for automatic test case generation leveraging the Robot Framework. The latter was specifically chosen as it is partially supported by Zephyr's test harness today and allows to utilize twister for automated test execution of these test suites on real hardware. This method has the potential to streamline testing, offering benefits such as reduced time and maintenance efforts as well as accurate coverage metrics from very early on in the project's lifecycle.

We'll discuss our progress in implementing this approach, the challenges we encountered, and potential solutions for deeper integration with the Zephyr project.

Developers are spoiled for choice when it comes to Low-Power Wide-Area-Network technologies, which can make it difficult to choose where to focus your time when starting a project.

In this session we will run through the advantages and tradeoffs of the various LPWAN solutions that Zephyr supports out of the box, with respect to power consumption, range, reachability and more.
Technologies to discuss include Bluetooth, WiFi, LTE CAT-M1, LTE NB-IoT, LoRa/LoRaWAN and Thread.