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 system-level approaches to Linux safety, assessing open source software quality, and defining operating system requirements for safety-related automotive platforms. The main topics included spatial and temporal interference, memory isolation, selective safety qualification, monitoring mechanisms, open source quality assessment frameworks, and assumptions of use for operating systems and hardware.
In this blog from our post-event series, we highlight three sessions covering these topics. The first presented NVIDIA’s system-level approach to Linux safety, focusing on protecting safety-relevant components through memory isolation and monitoring while reducing the need to qualify the entire kernel. The second compared the ELISA Lighthouse OSS SIG Checklist with existing open source best-practice frameworks, examining how development practices and observable evidence can support software quality assessment. The third introduced Eclipse S-CORE’s assumptions of use for underlying operating systems and explored opportunities to refine these requirements through concrete use cases, traceability, and collaboration with the ELISA community.
NVIDIA Linux for Safety: A System Level View – Igor Stoppa, NVIDIA
Igor Stoppa of NVIDIA presented a system-level approach to using Linux in safety-related applications, focusing on managing spatial and temporal interference while preserving the benefits of upstream Linux development. He discussed the challenges of qualifying the entire Linux kernel, particularly given its rapid evolution, and outlined an approach that limits qualification efforts to safety-relevant functions and protection mechanisms rather than the entire kernel.
The session explored spatial interference and the use of multiple memory contexts to protect safety-relevant data from unintended modifications. Igor explained how different memory mappings can restrict write access based on the executing thread or function, allowing safety-qualified and non-qualified components to coexist. He described the use of context-specific memory pools, changes to the scheduler, and compiler-injected context switching to manage access permissions without requiring extensive modifications to existing kernel source code. He also discussed end-to-end verification of memory allocations, reducing the need to qualify complex kernel memory allocators, and extending memory protection to user-space processes.
Igor then addressed temporal interference and the importance of monitoring mechanisms in detecting failures. He described how spatial protection provides a foundation for reliable monitoring by protecting safety-relevant data and internal states from unintended interference. The proposed approach uses a chain of monitoring mechanisms, from application-specific checks to hardware watchdogs, to detect failures across different system levels. He emphasized that the objective is not to guarantee system availability but to ensure that failures can be observed and detected.
The discussion also covered implementation considerations, including memory allocation, hardware dependencies, integration with upstream Linux, and the ability to configure protected memory pools for specific safety applications. The session highlighted how selective qualification, memory isolation, and monitoring mechanisms can support the development of Linux-based safety-related systems while reducing dependencies on rapidly evolving kernel components. Slides here.
Comparing ELISA Lighthouse OSS SIG Checklist with Existing OSS Best-Practice Frameworks – Wendi Urribarri, Woven by Toyota
Wendi Urribarri of Woven by Toyota and Philipp Ahmann of ETAS GmbH presented an initial comparison of the ELISA Lighthouse OSS SIG Checklist with existing open source best-practice frameworks. The session focused on understanding how different frameworks support open source software quality assessment and where the Lighthouse checklist could complement existing approaches rather than replace them. They discussed the challenges of demonstrating quality management in open source projects using traditional development models such as Automotive SPICE and CMMI, which may not reflect modern open source development practices.
The presentation outlined the ongoing development of the Lighthouse checklist, which covers governance and community health, development practices, security and supply chain management, quality assurance, documentation, and long-term sustainability. Wendi and Philipp explained the checklist’s evolving maturity model, which assesses both process robustness and the availability of evidence, recognizing that open source projects may demonstrate established practices through observable results without formally documented processes. They compared the checklist with three frameworks: the OpenSSF Best Practices Badge, which provides project-level criteria with an emphasis on security; the Apache Project Maturity Model, which focuses on governance, community maturity, and sustainability; and the Eclipse Trustable Software Framework, which emphasizes structured evidence and assessment.
The discussion explored the relationship between software quality, governance, community health, and long-term sustainability, including whether these factors directly contribute to quality or support its continued development. Participants also considered how quality assessment could provide evidence for safety-related applications without suggesting that meeting the checklist makes a project safety-certified. The speakers emphasized the importance of identifying existing open source practices rather than imposing additional processes on maintainers.
The session concluded with discussions on refining the checklist, identifying overlaps and gaps with other frameworks, and exploring opportunities for collaboration and potential alignment with existing standards. Participants also considered how assessment results could help adopters understand the quality practices of open source projects, identify areas requiring improvement, and manage risks within their specific applications. The Lighthouse checklist remains an evolving effort, with further comparisons, practical evaluations, and community feedback expected to inform its development. Slides here.
Lightning Talk: Eclipse S-CORE and AoUs to the Operating System – Philipp Ahmann, ETAS GmbH
Philipp Ahmann of ETAS GmbH introduced Eclipse S-CORE, an open source automotive middleware platform, and examined its Assumptions of Use (AoUs) for the underlying operating system. He outlined the platform’s components, including communication, diagnostics, logging, and other automotive middleware services, as well as its approach to development aligned with ISO 26262 and ISO/SAE 21434. The session also covered Eclipse S-CORE’s use of safety-related development artifacts, requirements traceability, and reference integrations with Linux-based platforms, including AutoSD and Elektrobit’s EB corbos Linux.
The presentation focused on the existing AoUs for operating systems and hardware platforms, particularly when Eclipse S-CORE is used in systems with safety goals. Philipp reviewed assumptions covering operating system startup, process management, file systems, inter-process communication, standard libraries, process and memory isolation, DMA protection, and hardware safety mechanisms. He explained that Eclipse S-CORE aims to remain operating system and hardware agnostic, leaving specific responsibilities to the underlying platform and system integrators. However, many of the current AoUs are broadly defined and require further clarification to identify the specific operating system capabilities needed for safety-related applications.
The discussion explored how the ELISA community could contribute to reviewing and refining these assumptions. Participants suggested using concrete use cases or reference demonstrations to identify relevant subsets of operating system functionality rather than assessing entire libraries or Linux subsystems. They also discussed improving traceability between Eclipse S-CORE features, module-level safety analyses, and their dependencies on the operating system and hardware. Memory partitioning was proposed as a potential starting point for examining these responsibilities across system layers.
The session concluded with a proposal to continue the discussion within the ELISA community, potentially through the Systems Working Group. Possible next steps include reviewing the existing AoUs, breaking down broad assumptions into more specific requirements, examining module-level safety analyses, and providing feedback or contributions to Eclipse S-CORE. The discussion also briefly considered the possibility of running selected Eclipse S-CORE components on Zephyr, although this is not currently part of the project’s roadmap. Slides here.
These sessions highlighted different approaches to supporting the use of Linux and open source software in safety-related systems. NVIDIA’s work focused on protecting safety-relevant components and establishing monitoring mechanisms while limiting kernel qualification efforts. The Lighthouse OSS SIG discussion identified opportunities to refine its quality assessment checklist, compare it with existing frameworks, and gather further evidence through practical evaluations. The Eclipse S-CORE session highlighted the need to clarify operating system assumptions of use, improve traceability to specific middleware features, and explore concrete use cases. Further technical development, community feedback, and collaboration across these efforts could help strengthen quality assessment, safety mechanisms, and system-level integration approaches for Linux-based safety-related applications.