Workshop

Olivier Charrier of Wind River led a discussion on AI-based tooling in safety-related development, comparing regulatory approaches across automotive, industrial, and aerospace markets. The session explored emerging standards, the influence of the EU AI Act, and proposed limitations on the safety assurance credit available for different types of AI tools in avionics. Olivier emphasized the importance of understanding the regulatory requirements of the intended market, engaging with auditors early, and following standards discussions to guide tool selection and development processes.

Workshop attendees also discussed the value of understanding the rationale behind standards and sharing insights across industries to make approaches more reusable. The session concluded with a proposal to bring standards expertise and practical experimentation together through the ELISA Tools Working Group, using a small number of pilot projects and open source proofs of concept to explore AI adoption in safety-related development. Slides here.

From Best Practices to Evidence: How SWH and SWHID Support Trustworthy Open Source – Wendi Urribarri, Woven by Toyota

Wendi Urribarri of Woven by Toyota explained how Software Heritage and Software Hash Identifiers (SWHIDs) can support trustworthy open source by connecting best practices, assessment evidence, and exact software artifacts. She distinguished SWHIDs, which identify artifacts by their content and can be used independently, from Software Heritage, which preserves source code and its history. The session emphasized the need to identify what was assessed, reviewed, or reused and to retrieve that same code years later, even if repositories move or disappear.

Examples showed how SWHIDs can complement package URLs and SBOM metadata, and support traceability from requirements and tests to specific source files or lines. Urribarri connected this approach to assessment initiatives including Lighthouse OSS, OpenSSF Best Practices, and Trustable. Participants also discussed linking source code, build configurations, toolchains, and binaries to support reproducibility, as well as retrieving exact historical code for targeted fixes and reassessment. Slides here.

Improving kernel test coverage with stress-ng – Colin King, stress-ng maintainer

Colin King, maintainer of stress-ng, presented ongoing work to improve Linux kernel test coverage by exercising system calls and kernel interfaces. He described new stressors for scheduling, filesystems, memory, and networking, including tests targeting race conditions, read-only filesystems, and invalid file descriptor operations. Using gcov and lcov, Colin showed how coverage analysis reveals missing test cases and untested error paths. He also explained how fault injection can trigger memory allocation failures to exercise error handling, and shared examples of bugs uncovered through stress testing.

Colin highlighted that although stress-ng’s coverage is increasing, the kernel is growing faster than his testing can keep up, with major gaps in driver coverage. He outlined plans to target common driver code and develop generic tests, inviting the ELISA community to identify priority drivers and provide access to relevant hardware. The discussion also raised opportunities to document the interfaces exercised by each stressor and collaborate on tool classification and qualification for safety-related use. Slides here.

These sessions explored regulatory considerations for AI-based tooling, the preservation and identification of software artifacts supporting assessment evidence, and improvements to Linux kernel test coverage. Together, they emphasized understanding the requirements of the intended market, keeping assessed software identifiable and retrievable over time, and using coverage analysis to identify untested code paths.

The discussions also raised proposals for further collaboration, including combining standards expertise with AI pilot projects through the ELISA Tools Working Group, identifying priority drivers and providing hardware for stress-ng testing, and working together on tool classification and qualification for safety-related use.

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 included discussions on the opportunities and challenges of using AI-based tools in safety-related development. Topics included requirements and test development, static code analysis for the Linux kernel, tool classification and qualification, risk analysis, explainability, false results, and human oversight.

In this blog from our post-event series, we highlight three sessions focused on AI-based tooling. The first introduced possible uses of AI throughout the development lifecycle and considered how different markets were addressing qualification and regulatory challenges. The second presented a work-in-progress approach for using AI to classify and prioritize large numbers of static code analysis violations in the Linux kernel. The third described NVIDIA’s methodology for introducing AI into safety-critical product development, beginning with AI-assisted reviewers and working toward controlled generation workflows.

Introduction: AI based tooling used during a project development lifecycle and different market views – Olivier Charrier, Wind River

Olivier Charrier of Wind River introduced the potential value of AI-based tools in safety-related development. He discussed how AI could help process large amounts of data, derive and review requirements from existing source code, and generate tests against requirements. The session also examined the challenges of qualifying AI tools, including their probabilistic behavior, training data, false positives and negatives, and the ability to explain their results. Charrier noted that while AI could support preliminary analysis and help identify issues in code or tests, human involvement remained necessary to complete the formal work required by current safety regulations. The session concluded by opening a discussion about how different markets were addressing these challenges. Slides here.

Taming the Violation Tsunami: Using AI to Tailor Static Code Analysis for Safe Linux – Eli Gurvitz, NVIDIA

Eli Gurvitz of NVIDIA presented a work-in-progress approach for using AI to analyze the large number of static code analysis violations found in the Linux kernel. The proposed process classified each violation as deviated, unknown, or a potential issue. Potential issues could then be prioritized and tested to determine whether they represented real bugs. The session also covered creating deviation records, using permits for recurring violations, grading coding rules, and addressing potential issues through safety analysis, assumptions of use, manual inspection, additional verification, or code fixes. Examples showed how a violation might be harmless in one Linux version but require reevaluation when the code changes, as well as how AI-assisted analysis identified a real vulnerability. The session concluded by raising the unresolved question of how AI results could be trusted in safety-critical development. Slides here.

Applying AI to safety-critical product development – Nicola Di Miscio, NVIDIA; Francesco Saracino, NVIDIA

Nicola Di Miscio presented NVIDIA’s approach to adopting AI in safety-critical product development, based on work carried out with Francesco Saracino. Rather than attempting to make AI deterministic, the methodology used established safety and cybersecurity processes, workflows, roles, and review gates to contain its probabilistic behavior. NVIDIA began at the requirements level, using AI as a reviewer rather than allowing it to generate or autonomously modify approved artifacts. The session covered standardizing input data, reviewing requirements for quality and consistency, reducing false negatives, maintaining human oversight, and recording review decisions. It also examined tool classification and qualification management, risk and impact analysis, and controls applied within both the tool and the wider development process. This reviewer-first approach was presented as a foundation for introducing controlled AI-generated content in the future, with humans continuing to approve the final artifacts. Slides here.

These sessions showed how AI-based tools could support requirements analysis, test development, and the review of large numbers of static code analysis violations. They also presented approaches for identifying potential bugs, prioritizing findings, and improving the efficiency of safety-related development activities.

The discussions highlighted that using AI in safety-critical development still raises important questions about probabilistic results, training, explainability, false positives and negatives, tool qualification, and trust. The sessions emphasized the continued need for human review, established development processes, risk analysis, and appropriate controls when applying AI to safety-related work.

The next blog in this series will highlight more sessions from the ELISA Workshop London 2026. Stay tuned!

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!

This recap includes observations and insights from ELISA Project leaders who participated in the workshop.

In June, the ELISA Project and Canonical co-hosted a three-day workshop in London bringing together the safety-critical Linux community – kernel developers, standards experts, hypervisor and RTOS engineers, and representatives from automotive, aerospace, and rail. Over three days the conversation ranged from certification strategy and real-time monitoring to the (very live) debate over how much AI tooling the functional-safety world is ready to trust.

This workshop landed at a turning point for the project. ELISA has spent years building the case that Linux can be used responsibly in safety-critical systems; London was where that case started converting into concrete deliverables. Several working groups left with clear mandates rather than open questions: the Tools WG is being revived to also tackle AI-assisted static analysis classification, the newly founded Railways SIG has its first concrete ask (a public proof-of-concept built purely on open source), and the Lighthouse OSS SIG checklist work has moved from a spreadsheet exercise toward something that could plausibly become a referenceable standard for assessors. At the same time, the group was refreshingly honest about where the hard problems still are – AI tooling in particular came up again and again, not as a solved problem but as something the community needs to get ahead of before it gets ahead of them.

Below is a walk-through of the main sessions, day by day, followed by a closing look at what these three days mean for ELISA’s roadmap.

Day 1: Certification Foundations and Functional Safety Building Blocks

The workshop opened with a welcome from ELISA leadership and co-host Canonical, followed by an Ask Me Anything session where Philipp Ahmann, Technical Steering Committee Chair, framed the state of play: existing safety standards (with a focus on automotive), the industry trends driving Linux adoption in functional safety (FuSa), and the challenges of bringing open source software into that world. Two questions from the floor set the tone for the rest of the event – whether AI can help manage growing system complexity (yes, in principle, but trust and verification remain open questions), and whether there’s any bridge between open source and the PLC-based world of railway signaling (not much overlap today, since ELISA’s focus is Linux rather than the simpler, more deterministic RTOS environments PLCs typically run).

Certifying Linux for safety-critical systems. Mikel Azkarate-askatsua walked through Canonical’s certification roadmap: having achieved security certifications against ISO 21434 and IEC 62443-4-1, Canonical is now working with TÜV SÜD toward quality and safety certification. A recurring question from the audience was how a “process certificate” can realistically cover the roughly 30,000 packages in Ubuntu’s Universe repository – the answer being that the certificate covers whichever subset of the supported packages a given customer actually uses.

Long-term latency monitoring with PREEMPT_RT. Jan Altenberg described OSADL’s approach to real-time validation, built around a QA farm (osadl.org/qa) that continuously runs boards in primary/shadow pairs and polls health data every five minutes. The core argument: modern CPUs are complex enough (caches, thermal throttling, parallel execution) that determinism can no longer be established through static analysis alone – it has to be verified empirically, over long uptimes, correlating system events with real-time performance data.

SafetyGuard – a watchdog for AGL. Sathishkumar Duraisamy and Philipp Ahmann introduced SafetyGuard, a safety-monitoring component based onthe Automotive Grade Linux (AGL) stack. It’s designed around zero-copy IPC, deterministic timing, fault detection, and restart/recovery, using single-producer/single-consumer message queues to monitor each application independently. The team laid out a phased roadmap, starting with single-monitor heartbeat and memory monitoring and building toward logging, metrics, and a full developer toolchain.

AGL SoDeV status update. Yuichi Kusakabe placed this work in a broader industry context: the shift from distributed, hardware-defined vehicle functions toward centralized, software-defined vehicles (SDV), and from closed supply chains toward collaborative, standards-based ones (citing JASPAR as an example). AGL’s goal is a single, shared platform that reduces fragmentation – with Xen pursuing ASIL D / SIL 3 certification and Zephyr targeting SIL 3.

Functional safety with Xen, Zephyr, and Linux. Matthew Weber and Ayan Kumar Halder discussed a domain-based architecture where Zephyr handles the control domain (small footprint, clearer certification path) while Linux serves as the driver domain (broad hardware support). Much of the Q&A focused on verification limits: how much can realistically be tested via QEMU versus real hardware, and how “Safety Element out of Context” (SEooC) claims interact with assumptions of use (AoUs) when the underlying hardware varies across vendors.

Day 2: AI Tooling, Traceability, and Standards Alignment

Day two opened with a clear framing from Olivier Charrier: AI can genuinely add value in safety-critical development – improving requirements, generating tests – but tool qualification depends on determinism, which AI doesn’t offer. The working assumption for now: use AI, but keep a human in the loop, and don’t claim credit for AI output until qualification standards catch up.

That framing carried through the rest of the morning:

• Taming the “violation tsunami” (Eli Gurvitz) – with millions of MISRA findings across the kernel, NVIDIA has been experimenting with AI to classify violations and triage which ones represent real risk. The session included a candid caution from the presenter that a cost-comparison figure generated via an AI search tool during slide prep turned out to be fabricated and should be disregarded – a useful cautionary tale in its own right. The group proposed reviving ELISA’s Tools Working Group to collaborate on static analysis classification.
• Applying AI to product development (Nicola Di Miscio) – argued for layered mitigation of AI-introduced errors (impact analysis, mandatory human checkpoints, standard guidance), and for tuning AI reviewers to minimize false negatives even at the cost of more false positives: “better an annoying alert than an invisible defect.”
• Facilitated discussion – surfaced the regulatory reality that standards bodies (ISO WG-14, ISO PAS 8800, ISO 22440) are still working out how AI-assisted tooling fits into existing frameworks, and that different regions and domains (automotive vs. avionics vs. medical) are moving at different speeds.

The rest of the day shifted toward traceability and process:

• SPDX modeling for a safety case (Nicole Pappler, Kate Stewart) – SPDX 3.1 introduces new profiles (Safety, Service, Hardware, Supply Chain, Operations)aimed at building complete SBOMs for safety-critical supply chains. Auto-SBOM generation already exists for Yocto and Zephyr; Xen support is hoped for.
• Software Heritage & SWHID (Wendi Urribarri) – made a compelling case for long-term artifact traceability, with sobering real-world examples of repositories that simply disappeared (Google Code in 2015, among others) leaving no way to verify what compiled a safety-qualified binary years later.
• Improving kernel test coverage with stress-ng (Colin King) – a look at how stress-ng stresses kernel syscalls and APIs across configurable stressor classes, and the scale challenge it’s up against: roughly 25 million of the kernel’s ~30 million lines are driver code, spread across thousands of drivers, most of them tied to specific hardware.
• Lightning talks covered BASIL (Red Hat’s traceability tool linking requirements to code, tests, and results, with a new Jumpstarter test-execution integration), the newly formed Railways SIG (founded this past April after over a year of preliminary discussion), and a deep-dive PoC framework for evaluating Linux virtual memory allocator (VMA) criticalities in safety-critical contexts.
• Panel: Enabling Linux in safety applications (Paul Albertella, Igor Stoppa, Pete Brink) – a candid discussion of the limits of “proven in use” claims for Linux, and what ELISA can realistically contribute: documenting challenges and limitations, cataloging reusable configurations, and writing down the tribal knowledge that rarely makes it into formal specs.
• What do we expect from a Safety Manual? (Nicole Pappler) – raised a sharp point about AI-generated safety manuals: it’s now easy to produce a plausible-looking 20–30 page document quickly, but plausibility isn’t the same as covering the right assumptions in both directions. The room converged on reframing “safety manual” as more of an integration guide – an index into the information integrators actually need.
• Defining Linux Kernel Requirements (Gabriele Paoloni, Kate Stewart, Chuck Wolber) – an update on ELISA’s multi-year effort (started 2024) to define kernel requirements upstream, including the friction of getting requirements accepted for /drivers/char/mem.c after discussion with the maintainer, and the pivot to maintaining requirements in a separate repository with explicit traceability relationships.

Day 3: Qualification Approaches, Checklists, and Next Steps

NVIDIA ASIL B Qualified Linux. Igor Stoppa presented an approach to isolating safety-relevant kernel data from interference, given that the Linux kernel is monolithic and any thread can, in principle, touch any memory. The design assigns context privilege levels (ASIL vs. QM) to threads and even to specific functions, using a compiler plugin to inject context-switch code, backed by a hardware watchdog as the ultimate root of safety. The goal isn’t to qualify the entire memory manager – a very complex state machine – but to build qualified, verifiable “safe havens” around it.

ELISA Lighthouse OSS SIG checklist comparison. Wendi Urribarri shared progress on a project comparing existing open-source quality frameworks (OpenSSF Best Practices Badge, Apache Project Maturity Model, Eclipse Trustable Software Framework) against each other, scoring them for gaps, overlaps, and equivalence – essentially exploring what an ISO 9001-style quality framework adapted for open source could look like, without adding undue burden on projects.

Eclipse S-CORE and Assumptions of Use. Philipp Ahmann gave an update on S-CORE, the open-source SDV stack spanning hypervisor to application middleware, with Red Hat and Elektrobit as Linux providers and Exida providing ongoing audit support. Discussion touched on how far S-CORE’s current focus on ADAS (versus full autonomous vehicles) should extend, and whether portions could run on Zephyr under the Xen hypervisor.

The workshop closed with a wrap-up and next-steps session, setting the stage for continued work across the Tools, Safety Architecture, and newly formed Railways working groups.

Looking Ahead: What This Means for ELISA

Across three days, a few threads kept resurfacing: the tension between AI’s genuine usefulness and the determinism that safety qualification still demands; the growing importance of SBOM and traceability tooling (SPDX, SWHID, BASIL) for making safety cases defensible over the long haul; and a community increasingly comfortable saying out loud that Linux “proven in use” isn’t a real safety claim – and getting to work on what would actually make one.

More concretely, the workshop leaves ELISA with a set of active threads to carry forward:

• Tools WG revival. Prompted directly by the AI-tooling sessions on Day 2, the group agreed to bring the Tools Working Group back to active status, with an initial focus on classifying static-analysis findings (MISRA, Coverity, and similar) and figuring out where AI can responsibly assist without becoming an unqualified black box in the safety argument.
• Requirements repository. The Linux Kernel Requirements effort is moving to a standalone repository with explicit traceability relationships (hasSpecification, hasEvidence), a direct response to the friction encountered getting requirements accepted upstream. Expect continued engagement with kernel maintainers as this matures.
• SPDX and Software Heritage convergence. Nicole Pappler and Wendi Urribarri agreed to follow up on connecting SPDX’s safety profile with SWHID, so a safety case can eventually point to both what a component is and a durable way to retrieve it years later – directly addressing the “the repo disappeared and we still had to prove what we shipped” stories from Day 2.
• Lighthouse OSS SIG checklist. The best-practices comparison work (OpenSSF Badge, Apache Maturity Model, Eclipse TSF) is moving from an internal spreadsheet toward a document intended for actual use by assessors. Kate Stewart volunteered to produce a Zephyr best-practices summary against the current checklist as a next concrete test case.
• Railways SIG growth. Having just formed in April, the SIG’s near-term goal is a public proof-of-concept built on open source components – and an explicit invitation for participants outside Europe, since the current group skews heavily regional.
• VMA criticality framework. NVIDIA’s PoC framework for evaluating memory-allocator risks is still pre-quantitative (no risk numbers yet), but the team signaled they’re close to being able to attach real figures to the risks they’ve identified – worth watching for an update at the next gathering.
• Safety manuals as integration guides. Expect this reframing – from “compliance document” to “integration index” – to show up in how ELISA talks about Linux adoption going forward, especially as a counterweight to how easy it now is to generate a plausible-but-hollow manual with AI.

Taken together, these point to a project shifting from making the case for Linux in safety-critical systems toward building the scaffolding – requirements, SBOMs, checklists, and tooling – that lets others make that case for their own products. The next milestone worth watching is whether the revived Tools WG and the requirements repository produce something concrete enough to bring back to the community before the next in-person gathering.

The session videos will be available on the ELISA Project YouTube channel in the London Workshop playlist, which will be updated weekly as new recordings are published.  

ELISA Resources

Stay connected and get involved with our growing community through the following channels:

• Join the real-time conversation with contributors, members and working groups on the ELISA Project Discord.
• Follow the ELISA Project LinkedIn Page for technical updates, event announcements, and networking.
• Sign up for project updates and technical discussions via the ELISA Mailing Lists to get the latest news delivered straight to your inbox.

The ELISA Workshop Munich 2025 took place November 18-20 at the Red Hat office in Grasbrunn, Germany, bringing together project members, contributors, and industry partners for three days of focused collaboration.

Welcome & Introductions Gabriele Paoloni, Red Hat; Kate Stewart, Linux Foundation; Philipp Ahmann, ETAS GmbH

The ELISA Workshop opened with a welcome note from organizers who introduced logistics, guidelines, and expectations for collaboration, including the code of conduct and Chatham House Rule options. Participants from industry, academia, and open source communities briefly introduced themselves, reflecting a diverse range of expertise in safety-critical systems, Linux engineering, certification, and research.

Ask Me Anything – New Contributor Onboarding Gabriele Paoloni, Red Hat; Philipp Ahmann, ETAS GmbH

The “Ask Me Anything about ELISA or the Use of OSS in Safety-Critical Applications” session, led by Gabriele Paoloni and Philipp Ahmann, offered participants an open space to address foundational questions about applying Linux and open source software in safety-critical systems. The conversation clarified why live Q&A remains valuable beyond static FAQs, explored the challenges of using Linux in complex safety contexts, and outlined how ELISA approaches requirements, standards, tooling, and system understanding. 

The session also highlighted common misconceptions such as the idea of producing a “safe Linux”and reinforced the importance of context, collaboration, and evolving industry practices when integrating OSS into safety-relevant applications.

Research questions and publication directions of Aerospace WG Martin Halle, Hamburg University of Technology – Institute of Aircraft Systems Engineering, Matthew Weber, Boeing

This session outlined key research questions for the Aerospace Working Group, focusing on where Linux is currently used in aerospace and space systems, how regulations affect its adoption, and which topics should lead to future white papers. The speakers also introduced shared use cases and tools supporting this work and invited contributors with domain expertise to help advance upcoming publications.

Towards Practical Program Verification for the Linux Kernel Keisuke NISHIMURA, Inria

The session “Towards Practical Program Verification for the Linux Kernel,” presented by Keisuke Nishimura, Jean-Pierre Lozi, and Julia Lawall, introduced foundational concepts of deductive program verification and demonstrated their application through a case study on the kernel function. The speakers highlighted challenges in specifying correct behavior, automating loop invariants, and preparing verification-ready code, and outlined research efforts aimed at making large-scale kernel verification more practical.

Towards a More Sustainable and Secure Software Tooling in Free/Libre Open Source Software Environments Stefan Tatschner, Fraunhofer AISEC

The session “Towards a More Sustainable and Secure Software Tooling in Free/Libre Open Source Software Environments”, presented by Dr. Stefan Tatschner (Fraunhofer AISEC), explored how software sustainability and security intersect in FLOSS ecosystems. Building on his PhD work, Dr. Tatschner discussed how vague or overly complex specifications and fragmented development practices can lead to inconsistent, insecure implementations, illustrated through studies of QUIC stacks and X.509 libraries. He showed how dependency analysis and graph-based metrics can help identify critical projects whose health has a disproportionate impact on the ecosystem.

Introducing SW Requirements in the Linux kernel development process: status and next steps Gabriele Paoloni, Red Hat; Kate Stewart, Linux Foundation; Chuck Wolber, Boeing

The session “Introducing SW Requirements in the Linux Kernel Development Process: Status and Next Steps”, presented by Gabriele Paoloni (Red Hat), Kate Stewart (Linux Foundation), and Chuck Wolber (Boeing), explored how to bring structured software requirements into the Linux kernel’s distributed, maintainer-driven development model. The speakers highlighted gaps in existing documentation and explained how missing explicit intent increases technical debt and complicates safety and certification work. They proposed testable, SPDX-based requirement annotations that live alongside the code to improve clarity, traceability, and review. The talk also summarized feedback from kernel maintainers and outlined ongoing experiments and next steps to refine the approach and drive broader adoption.

Exploring possibilities for integrating StrictDoc with ELISA’s requirements template approach for the Linux kernel Tobias Deiminger, Linutronix; Stanislav Pankevich, Reflex Aerospace

The session “Exploring Possibilities for Integrating StrictDoc with ELISA’s Requirements Template Approach for the Linux Kernel”, presented by Tobias Deiminger (Linutronix GmbH) and Stanislav Pankevich (Reflex Aerospace GmbH), demonstrated how the StrictDoc tool can support structured, traceable requirements workflows for kernel development. The speakers introduced StrictDoc’s capabilities, showed how it is already used at Linutronix for certification-driven projects, and walked through a live prototype integrating SPDX-based requirements directly from kernel source files. They highlighted how StrictDoc can link requirements, code, and tests while enabling validation and drift detection. The session emphasized that such tooling could strengthen documentation quality, improve traceability, and complement ELISA’s efforts to introduce maintainable requirements practices into the kernel ecosystem.

Architectures for Linux in Railway Safety Applications Florian Wühr, Red Hat; Daniel Weingaertner, Red Hat

The session “Architectures for Linux in Railway Safety Applications”, presented by Florian Wühr and Dr. Daniel Weingärtner (Senior Software Engineers, Red Hat EMEA Field CTO Office), explored how Linux-based platforms can be used in modern railway safety systems. They outlined Red Hat’s involvement in the “AutomatedTrain” research project and discussed applying high-performance, Linux-based platforms for autonomous and safety-related rail use cases. The talk covered relevant safety standards and SIL levels, key certification and interoperability challenges in Europe, and compared architectural options (containers, hypervisors, redundancy/diversity) for mixed-criticality railway applications.

Hypervisors are scary, so why use them for enabling Linux for Safety Applications Aqib Javaid, Elektrobit

The session explained why hypervisors, though often viewed as complex or risky, are valuable for enabling Linux in safety-critical systems. Aqib Javaid clarified common misconceptions such as hypervisors being slow or unusable for safety and showed how modern hardware support and open-source options like Xen and L4 make them practical and certifiable. He demonstrated how hypervisors provide strong isolation and allow a small safety monitor to supervise Linux, adding protection without modifying the kernel.

Open Functional Safety: Safety-Qualified Lifecycle with Sphinx Christopher Zimmer, innotec GmbH

The session “Open Functional Safety: Safety-Qualified Lifecycle with Sphinx” was presented by Christopher Zimmer (innotec GmbH). He showed how an open-source toolchain centered on Sphinx can support a full, safety-qualified development lifecycle for smaller companies and open source projects that can’t afford heavy commercial tooling. The talk also outlined how to classify and qualify such tools so they can be used in standards-compliant functional safety workflows.

AGL SDV SoDeV Insights Naoto Yamaguchi, AISIN; Harunobu Kurokawa, Renesas

The session “AGL SDV SoDeV Insights,” presented by Naoto Yamaguchi (AISIN) and Harunobu Kurokawa (Renesas), shared progress on Automotive Grade Linux’s Software-Defined Vehicle initiative. The speakers outlined SoDeV’s goal of decoupling hardware and software using open-source technologies like hypervisors, VirtIO, and unified HMI frameworks to enable reusable, scalable in-vehicle software. They also discussed early prototypes, planned architecture, and open challenges particularly around safety and integrating monitoring in virtualized systems.

Best Practices in Open Source and Standards – Evaluation of Example Projects Simone Weiss, Linutronix

The session presented work from ELISA’s WG Lighthouse OSS on identifying open-source “best practices” and mapping them to quality/safety standards. Simone showed how a common evaluation template was applied to Xen and Yocto, revealing both strong governance/CI practices and recurring issues like fragmented documentation, and outlined plans for a maturity model to rate project process quality.

Beyond the OS: What else is required for safe automotive applications? Isaac Trefz, Elektrobit

The session “Beyond the OS: What Else Is Required for Safe Automotive Applications?” highlighted that making Linux safe is only one part of building a safety-compliant automotive system. Isaac Trefz (Elektrobit) explained that safe applications also require qualified compilers and libraries, safe IPC, reliable rendering paths, hypervisors, hardware support, and proper monitoring/watchdog mechanisms. Using examples like telltales and ADAS functions, he showed how these system-level elements must work together.

BASIL Luigi Pellecchia, Red Hat

The session “BASIL,” presented by Luigi Pellecchia (Red Hat), introduced BASIL as a tool for managing traceability across requirements, code, and tests in safety-critical projects. Luigi highlighted recent updates improved SPDX SBOM export, graphical traceability views, expanded test-framework support, and a new AI-assisted requirement generator. He also outlined a proposal for a configurable traceability scanner that pulls structured data from multiple repositories, aiming to simplify and standardize traceability workflows in open-source safety development.

Continuous Compliance in Safety-Critical Open Source Projects Rinat Shagisultanov, InfoMagnus

The session “Continuous Compliance in Safety-Critical Open Source Projects,” presented by Rinat Shagisultanov (InfoMagnus), showed how safety-annotated SBOMs—using SPDX 3 and its emerging safety profile can automate functional-safety traceability. Rinat explained how tools like BASIL generate these SBOMs and how the OpenCC platform performs semantic diffs, impact analysis, and audit logging inside CI/CD pipelines.

Industry Safety Level(s) vs. Aerospace Use Cases Matthew Weber, Boeing

The session “Industry Safety Level(s) vs. Aerospace Use Cases,” presented by Matthew Weber (Boeing), explained how civil aerospace develops and certifies aircraft software using DO-178C safety levels (DAL A–E), and how these compare conceptually to ASIL/SIL levels in other industries. He walked through the aircraft lifecycle, showed how safety levels drive required artifacts and rigor, and illustrated everything with example use cases and early Linux-based demos (like a safety-aware “cabin light” and NASA CFS-based scenarios).

Linux Virtual Address Space Safety Alessandro Carminati, Red Hat

The session “Linux Virtual Address Space Safety,” presented by Alessandro Carminati (Red Hat), explored how Linux’s virtual memory design especially Virtual Memory Areas (VMAs) and the global linear mapping creates subtle safety risks in mixed-criticality systems. He walked through the VMA lifecycle, showed how the linear map lets kernel and user pages sit side-by-side (enabling accidental cross-domain corruption), and reviewed current defenses and why they’re aimed at security/debugging rather than deterministic functional safety.

Behind the Scenes: Elisa Yocto meta-layer and the ELISA CI infrastructure Sudip Mukherjee, Codethink

The session “Behind the Scenes: ELISA Yocto Meta-Layer and the ELISA CI Infrastructure,” presented by Sudip Mukherjee (Codethink), gave a concise behind-the-scenes look at how ELISA’s Yocto meta-layer and CI system are built and maintained. Sudip explained how the team created a standardized Docker-based build environment, added nightly CI builds, shared sstate caching, and automated testing with QEMU and OpenQA. He also highlighted ongoing work to keep the AGL-based demo app building reliably and invited other working groups to adopt the shared CI to ensure reproducible, stable builds.

The SPDX Safety Profile Release Candidate – towards standardised safety supply chain documentation Nicole Pappler, AlektoMetis

The session “The SPDX Safety Profile Release Candidate – Towards Standardised Safety Supply Chain Documentation” by Nicole Pappler (AlektoMetis) presented the new SPDX 3.1 safety profile, which extends the core SPDX model with safety-specific concepts like requirements, verifications, and evidence links. Nicole explained how this enables standardized, machine-readable safety documentation across the software supply chain, improving traceability, impact analysis, and compliance for safety-critical industries using open source.

Drawing an open source safety-critical landscape Philipp Ahmann, ETAS GmbH

The session “Drawing an Open Source Safety-Critical Landscape” by Philipp Ahmann (ETAS) outlined the need for a clear map of the growing ecosystem of safety-critical open source projects. Philipp proposed building a structured landscape covering OSs, hypervisors, tools, frameworks, simulators, and industry domains to show how projects relate, where they fit, and where gaps or collaboration opportunities exist. The goal is to give the community a central, easy-to-navigate view of safety-critical open source efforts.

In short:

The Munich workshop highlighted the rapid progress and growing cohesion of the safety-critical open source ecosystem. Over three days, contributors shared tools, research, architectures, requirements approaches, and CI practices all reinforcing that using Linux in regulated environments requires aligned methods, clear documentation, traceability, and strong cross-community collaboration.

With active participation from industry, academia, and open-source projects, the workshop wrapped up with renewed momentum and a shared commitment to push ELISA’s technical work forward.

Note: Presentation Slides can be accessed here

Would like to see the photos from the meetup? Check here.

Check the workshop playlist in the ELISA YouTube.

Interested to host the next ELISA workshop?

The ELISA Project hosts workshops on a regular basis to gather the project community to accelerate technical collaboration and output, and plan for future goals. It is intended as a technical community collaboration forum to advance the mission of the ELISA Project. More specifically, the Workshop series provide the avenue to: 

• Explore ideas about approaches, processes, tooling, and testing that can be incorporated into building safety-critical applications and systems  
• Exchange perspectives and feedback from the Linux kernel, safety, and other adjacent open source project communities
• Provide updates about the various Working Groups’ current activities and priorities and future roadmaps
• Enable real-time collaboration to make more accelerated progress on current work streams 
• Define and articulate near-term technical goals and priorities
• Educate and onboard new community members
• Activate and increase engagement and contributions from a broader range of contributors
• The workshops are generally held in person to facilitate more open discussions and real-time collaboration. Virtual access can be provided if there is sufficient interest.

Contact us to discuss hosting a workshop.