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) and NIS2. 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 the EU Cyber Resilience Act, 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 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.

The Yocto Project provides several building blocks for supply-chain security, including pinned sources, checksums, source mirroring, SBOM support, and reproducible builds. These mechanisms are invaluable, but only as strong as the code behind them.

In this talk, I will describe a project in which I used LLMs to assist security research on selected Yocto Project components. I will explain how candidate findings were identified, manually triaged, reproduced, and filtered before being reported upstream.

The talk will cover how I separated real issues from false positives, assessed whether suspicious code patterns were exploitable, prepared reports that maintainers could act on, and upstreamed patches where appropriate.

Modeling underlies the grid we all rely on. Every decision to build a new power plant or transmission line starts with a model run, yet planning models are often opaque, expensive, and difficult to replicate. That lack of transparency, along with uneven access to high-fidelity tools and data, breeds distrust and delay in the planning processes essential to decarbonizing the grid and expanding energy access worldwide. Open-source planning tools are growing in number and capability, but real barriers to adoption remain. OpenGrid aims to build a shared infrastructure foundation for open-source modeling, so open tools and data can become a credible industry standard. This session introduces the OpenGrid initiative, announced as a project under Linux Foundation fiscal sponsorship, covering both the thinking behind it, the plans to build it out and how you can get involved.

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.

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.

Over several decades, TLA+ has been immensely useful for finding safety and liveness issues in concurrent and distributed systems. As developers of Apalache, the symbolic model checker for TLA+, our work with engineers has changed how we think specification tooling should look. Three obstacles to adoption arise repeatedly: (1) the steep learning curve, (2) the gap between formal specs and the code, and (3) scalability issues.

This talk reflects on our 10 year journey with TLA+ into the age of AI. We first show how we addressed (1) through a less mathematical syntax and modern developer experience. For (2) and (3), model-based testing and proofs have long been promising, but traditionally required too much expert labor. Frontier AI tooling changes this balance: it lowers onboarding costs, helps generate test drivers, and can automate proof work to a useful degree.

At the same time, formal tooling allows us to gate AI-generated code, catching plausible but incorrect implementations. We argue that AI and formal tooling complement each other, making both more practical.