The ELISA Project community gathered at Canonical’s London office from June 9-11, 2026, for three days of technical presentations, discussions, and collaboration focused on advancing Linux for safety-critical applications.
The workshop brought together ELISA members, contributors, and industry experts to exchange knowledge across topics including safety-oriented Linux supervision, software-defined vehicle platforms, system partitioning, safety requirements, verification and validation, and maintaining safety evidence for open source software.
In this blog from our post-event blog series, we highlight three sessions. The first introduced SafetyGuard, a work-in-progress Linux supervision middleware focused on monitoring, fault detection, watchdog responses, and application recovery. The second presented the development status of AGL SoDeV and explored how AGL, Xen, Zephyr, and VirtIO can support software-defined vehicle architectures. The third discussed how Xen, Zephyr, and Linux could work together in functional safety architectures, covering partitioning, assumptions of use, testing, and ongoing efforts to maintain certifiable open source software.
SafetyGuard – Watchdog Software – Sathishkumar Duraisamy, SDuraiEngineer & Philipp Ahmann, ETAS GmbH
Sathishkumar Duraisamy and Philipp Ahmann introduced SafetyGuard, a work-in-progress, safety-oriented Linux supervision middleware being developed within the ELISA Systems Working Group. SafetyGuard is intended to operate as a software watchdog for selected Linux applications while also managing a hardware watchdog. Its planned capabilities include monitoring application health and memory usage, detecting faults through heartbeat signals, and initiating configurable responses such as restarting or recovering an application or system.
The session presented SafetyGuard’s proposed architecture, which is organized into control, data, signal, and safety planes. The design explores the use of shared memory, eventfd, and epoll to support low-overhead, zero-copy communication and work toward more deterministic behavior. SafetyGuard is being developed in Rust, with plans to provide interfaces that allow applications written in C, C++, and other languages to use the middleware.
The speakers also outlined the project roadmap, including application registration, resource monitoring, logging and metrics, container support, debugging and configuration tools, redundancy, and cross-monitoring between virtual machines. They highlighted areas that still require further investigation and development, such as requirements, testing, safety evidence, kernel interference, security, and dependencies on complex components such as systemd.
As SafetyGuard remains at an early stage, the session invited the ELISA community to review its architecture, propose requirements and additional features, improve the documentation, and contribute to its continued development. Slides here.
Development status of AGL SoDeV – Yuichi Kusakabe, Chief Architect, Honda Motor R&D Co., Ltd.
Yuichi Kusakabe, Chief Architect at Honda Motor R&D Co., Ltd., presented the development status of SoDeV, the Automotive Grade Linux Software-Defined Vehicle reference platform. He began by describing three major shifts affecting automotive software development: the move toward software-defined vehicles, the growing use of open standards and open consortiums, and changes to the traditional automotive supply chain.
Software-defined vehicles are increasing the demand for frequent software updates and new features. At the same time, automotive architectures are moving toward powerful central electronic control units that run different types of applications on a single system-on-chip. This requires support for application processing, real-time workloads, and other functions with different requirements. The supply chain is also changing as automakers work more directly with semiconductor vendors and multiple software companies, making collaboration across the automotive software ecosystem increasingly important.
Yuichi explained how open source projects can support this transition. AGL aims to provide a shared software platform that gives automakers and suppliers a common starting point for product development. Xen provides a Type-1 hypervisor for running and isolating different software environments, while Zephyr offers a lightweight operating system that can help address automotive requirements such as fast start-up and real-time communication. He also highlighted Zephyr’s safety-related activities. VirtIO provides standardized virtual device interfaces that can help the same applications and software binaries work across different hardware configurations. The presentation also referred to open source compliance and security assurance as important considerations when managing the many open source components used in automotive software.
The SoDeV reference architecture brings these technologies together. It uses Xen as the Type-1 hypervisor and includes control and monitoring functions, hardware-dependent driver domains, and guest domains that can run AGL and other operating systems or applications. Driver domains can be selected according to the system-on-chip vendor and board support package. The architecture also uses VirtIO interfaces and includes Unified HMI technology to manage content across multiple displays. An instrument-cluster application was presented as one of the platform’s use cases, including the isolation of different software components through virtualization.
Yuichi then shared the current development work on the Renesas R-Car V4H-based Sparrow Hawk board and Raspberry Pi 5. He discussed efforts to support Xen, guest domains, graphics, GPU access, and multiple displays on these platforms. On Raspberry Pi 5, the development progressed from basic boot and display output to GPU-enabled graphics and support for two displays. The next steps include running an AGL instrument-cluster application alongside Android and publishing the related source code through the AGL repositories.
The session showed how AGL SoDeV is using open source technologies to explore a common reference platform for software-defined vehicle development. It also emphasized the value of collaboration among automotive companies, hardware vendors, software developers, and open source communities as vehicle software architectures continue to evolve. Slides here.
Functional safety with Xen, Zephyr and Linux for avionics, automotive and industrial Matthew Weber, The Boeing Company; Ayan Kumar Halder, AMD
Matthew Weber of The Boeing Company and Ayan Kumar Halder of AMD presented ongoing work within AMD and the Xen open source community to support the functional safety certification of Xen and define safety use cases involving Xen, Zephyr, and Linux for avionics, automotive, and industrial systems.
Ayan explained how Xen can provide memory, time, and space partitioning between operating systems running on the same hardware. The architecture presented uses Zephyr as a possible control domain because it is lightweight and undergoing safety-certification activities. Linux can serve as the hardware domain because of its broad support for platform hardware and drivers. Other domains can run separate workloads, with Xen controlling their interactions and protecting selected domains from interference.
The session emphasized the importance of defining requirements and assumptions of use for the hardware, firmware, bootloader, compiler, tools, and guest operating systems. The Xen community has adopted around 120 MISRA C rules and directives, with documented deviations where needed, and integrated MISRA checking into the upstream development process. More detailed configuration options are also being developed to limit safety-focused Xen builds to the code required for a specific platform.
Verification and validation work includes domain-based testing, freedom-from-interference testing, runtime testing, internal-interface testing, and fault injection. GDB-based testing can trigger internal conditions such as memory-allocation failures, while QEMU can introduce hardware faults at specific points. Runtime testing examines memory use, resource exhaustion, and virtualization-related latency. The presenters noted that some areas also require testing on real hardware, code inspection, and platform-specific verification.
Matthew explained how the Xen functional safety work could be extended for avionics under DO-178C, together with the related system and hardware considerations covered by ARP4754A and DO-254. This requires low-level requirements, white-box testing, traceability, and structural code coverage. A Ceedling-based approach was presented for testing individual Xen functions with mocked or stubbed interfaces without starting a complete Xen system.
The speakers also discussed maintaining requirements, architecture specifications, tests, traceability, and coverage evidence alongside changes to the upstream Xen codebase. The session showed how Xen, Zephyr, and Linux could support partitioned, mixed-criticality architectures while recognizing that the complete safety case and final verification must be developed for a specific system, hardware platform, and use context. Slide here.
These sessions showed how SafetyGuard, AGL SoDeV, Xen, Zephyr, and Linux are being explored for safety-oriented systems. They covered application monitoring and recovery, software-defined vehicle architectures, system partitioning, safety requirements, and testing.
The discussions also showed that this work is still developing and requires continued collaboration across open source communities, industry, and safety experts.
The next blog in this series will highlight more sessions from the ELISA Workshop London 2026. Stay tuned!