OSS + ELC EU 2026

Critical infrastructure operators face growing pressure to modernize their systems while maintaining the highest levels of security, reliability, and regulatory compliance in an era shaped by regulations such as the EU Cyber Resilience Act (CRA). In this session, Hitachi shares two real-world modernization journeys with open source from the energy and railway sectors.

The first half focuses on Hitachi Energy’s adoption of Embedded Linux and Yocto for next-generation grid automation products. Hitachi Energy actively contributes to the modernization of energy systems, making electricity more accessible worldwide. In product development, adopting Embedded Linux and Yocto enhances flexibility and maintainability, with strong legal compliance, license management, and open-source collaboration. Hitachi Energy is rolling out Linux-based energy grid automation products and this talk covers their transition to embedded Linux via Yocto, addressing industry protocol support, impacts of CRA, OSS license challenges, and navigating these within a slow-evolving sector.

The second half presents Hitachi Rail’s modernization of mission-critical railway management systems using Keycloak, an open source identity and access management platform. As railway systems become increasingly interconnected, cybersecurity and identity management have become fundamental architectural concerns. We show how secure-by-design principles were applied to modernizing legacy environments, with Keycloak. We also demonstrate how Keycloak helps address several IEC 62443-4-2 requirements and provides a strong foundation for meeting emerging regulatory expectations such as CRA.

Safety-critical systems in avionics, automotive, and industrial domains increasingly rely on mixed-criticality architectures where workloads of different safety levels share hardware. This talk presents ongoing work to bring functional safety to the upstream Xen hypervisor, composed with Zephyr RTOS and Linux, to meet standards including DO-178C (avionics), ISO 26262 (automotive), and IEC 61508 (industrial).
We walk through concrete upstreamed and published contributions: MISRA C fixes, MPU support in Xen, requirements and architecture specifications, and test specifications. We describe how Xen is validated as a Safety Element out of Context using domain-based tests, fault injection, gdb-based interface testing, fuzzing, platform emulation, Ceedling unit testing, and coverage analysis (line, branch, function, MC/DC).
We also cover efforts to shrink the safety-certifiable codebase through fine-grained hardware configuration, and how Xen enforces freedom from interference between VMs via isolation. We close with opportunities to collaborate with the ELISA and Xen FuSa communities toward an open safety case for open-source systems.

SPDX 3.1's Functional Safety profile recently grew to model a safety case end to end: requirements and their refinement, verification, pass/fail evaluations, evidence, and assumptions of use. It standardizes how a safety case is exchanged, but not how one is produced, nor what a consumer does with one received. We demonstrate SEGkit, a prototype, open-source, project-agnostic engine that extracts a design and evidence graph from content repositories to recompute a verdict over the graph—a judgment recomputed from content, not merely recorded—and detects which evidence goes stale as code evolves; in this talk we also show how we plan to use it within Zephyr to automate safety evidence creation. This makes SEGkit interesting to projects maintaining their safety BOM as well as downstream users who want to work with one. For the latter case we argue a received BOM is best consumed as a contract—its requirements and evidence being guarantees and its assumptions the conditions the consumer must discharge against its own case. Lastly, we talk about what the profile might add for machine-checkable discharge: assumptions as checkable conditions, linked to the guarantees they constrain.

A hazard assessment is “a process that allows the identification and evaluation of potential hazards related to [...] system function regardless of the details of its implementation” (SAE ARP4761A, section C.1). The outcome of a hazard assessment has far-reaching consequences for overall project design and the degree of engineering rigor required during development. In this session, Chuck will take the audience through a hazard assessment exercise based on a simplified model and describe the effects of the assessment on the design and development process. In addition to exposing the audience to a relatively simple but rigorous method for thinking about failure conditions during design, Chuck will also touch on gaps in non-safety-critical software engineering that can benefit from best practices developed by the safety engineering community.

Linux was not developed around fault-containment properties expected of safety-certifiable software.

The linear map lets kernel code access memory across userspace ownership boundaries, so corruption can affect another process or container. Shared slab/page allocators and per-CPU caches compound this risk: corrupted state may remain latent and later affect unrelated subsystems. MMIO can cause external interference when a faulty driver accesses the wrong register or device because of corrupted state or an incorrect Device Tree or ACPI-derived base address.

Building on ELISA Linux Features WG (LFSCS) work, we use ks-nav call-tree artifacts to show that even narrow services depend on shared infrastructure across subsystems.

Reducing the configuration lowers function count but also usability; restoring functionality introduces transitive dependencies, so assessment cannot be limited to newly enabled code.

These findings challenge treating Linux as safe by default or relying on proven-in-use arguments alone. In a monolithic, shared-address-space kernel, fault containment and qualification scope must be demonstrated, not assumed.

Autonomous train operation requires a new generation of computing platforms capable of running AI-based perception, sensor fusion, and safety-critical control functions. Traditionally, railway systems have been delivered as tightly integrated proprietary hardware-software stacks, limiting software reuse, innovation, and vendor independence.
This talk presents the results of the Automated Train research project and explores whether a Linux-based platform can become the foundation for safety-critical rail applications. We examine the technical feasibility of using Linux to support mixed-criticality workloads while meeting stringent railway safety requirements.
Beyond technology, we discuss a fundamental challenge for open source in regulated industries: how can continuously evolving software be certified in environments governed by legally binding functional safety standards?
Finally, we explore the governance and business implications of a shared open-source platform for the railway sector. The lessons learned extend far beyond railways and provide a blueprint for applying Linux and open-source collaboration to other safety-critical and sovereign digital infrastructure domains.

Interest in safety critical open source software is high, yet opportunities to connect and openly discuss challenges remain limited. This BoF creates a focused forum for practitioners and newcomers to exchange experiences, ask questions, and gain visibility into existing projects and initiatives.

It also highlights the role of initiatives such as the Linux Foundation ELISA project as a central interface within the ecosystem, helping to connect efforts across communities, share practices, and make ongoing work more discoverable. The project brings together horizontal working groups covering features, processes, architecture, and tooling, while also addressing vertical domains such as automotive, aerospace, space, railways, and medical. This reflects the growing relevance of Linux and open source in safety critical systems.

By enabling direct interaction and cross project exchange, the session supports alignment, reduces duplication, and fosters collaboration in an evolving safety critical OSS landscape.

Participants at all levels of experience are encouraged to join, contribute their perspective, and engage with the community.