THE LINUX FOUNDATION PROJECTS

Recap: ELISA Project London Workshop

By August 10, 2026Blog, Workshop
Recap ELISA Project London Workshop 2026

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: