With the emergence of the first safety-certified Linux distributions, the role of open-source software (OSS) in safety-critical systems is experiencing a fundamental shift in mindset. What was once categorically dismissed is now increasingly seen as a long-awaited opportunity. OSS, previously confined to experimental or non-critical domains, is gaining credibility as a solid foundation for dependable systems. This shift is not about following trends, it is driven by the recognition among major industry players that collaborative development in open source can reduce costs and accelerate time-to-market, even in mission-critical domains. The movement toward incorporating OSS into safety-critical systems is not only a technical transformation, it is also a cultural one, gradually challenging and reshaping long-held assumptions in industries where safety remains the highest priority.

Eclipse iceoryx, initiated in 2019, was the first project hosted by the Eclipse Foundation with the goal of delivering certifiable code for embedded systems as open source. Its ambition is to develop high-performance, safety-ready communication middleware while embracing the openness and transparency that define successful open-source ecosystems. The journey of this project has been anything but smooth. It continues to encounter unknowns, obstacles, and hard-won lessons that resonate with anyone operating at the intersection of OSS and safety.

Eclipse iceoryx in a Nutshell

Today’s data-intensive systems, such as those in automotive and robotics, require communication middleware that can handle gigabytes per second between applications running on a single host while keeping latency and CPU overhead low. Traditional inter-process communication (IPC) mechanisms provided by operating systems, such as Linux, typically involve multiple memory copies when messages are transmitted between sender and receiver. This results in performance bottlenecks and limits scalability.

iceoryx is a communication middleware that relies on shared memory, enabling true zero-copy communication between POSIX processes. Messages can be exchanged without a single memory copy, allowing sub-microsecond latencies regardless of message size. These capabilities make iceoryx a key enabler for software architectures that demand both high throughput and real-time responsiveness. In real-world applications, iceoryx serves as a foundational layer in many commercial and open-source frameworks. It is used in automotive, medical, robotics, marine, defense, artificial intelligence, and even high-frequency trading environments.

Challenges and Insights from the iceoryx Journey

The technical challenges for iceoryx lie in the design and implementation of a middleware that must be high-performance while addressing the highest safety and security demands. But these are by far not the only challenges we encountered while developing certifiable software in an open-source setting.

Acceptance of Open Source in the Safety Community

A few years ago, the idea of using OSS in safety-critical systems was unthinkable in many organizations. Internal policies often explicitly prohibited it. This strict rejection was frequently based on two common 1misconceptions: first, that using OSS would automatically introduce license complications due to copyleft obligations from licenses like the GPL, and second, that OSS is written by developers unfamiliar with safety requirements who follow informal, "happy-hacking" practices rather than disciplined software engineering as required by standards such as ISO 26262. These reservations still persist, and many engineers and decision-makers continue to associate OSS with informal or low-quality "hobbyist" projects. Overcoming these biases requires ongoing education, real-world success stories, and new approaches to trust-building.

The safety culture, shaped by risk management and liability concerns, typically leaves little room for adopting open-source solutions or engaging in collaborative, community-driven development. In the case of iceoryx, this led to a situation where, even after several vendors of frameworks like AUTOSAR Adaptive recognized the need for shared memory communication, they chose to build their own solutions instead of collaborating with the iceoryx maintainers or seeking commercial support to integrate it into their products. As a result, many teams had to learn the hard and costly lessons of building a robust shared memory middleware stack from scratch. Fortunately, the situation is improving. A recent example is Eclipse SCORE, a full runtime software stack for software-defined vehicles that is being developed as open source by many large industry players with the explicit goal of achieving safety certification.

Workflow and Tooling Gaps

Developing safety-certifiable software involves a set of best practices like requirements management, architecture definition, design and code reviews, static and dynamic code analysis, rigorous testing, and traceability between all these artifacts. A whole industry of its own has evolved to provide commercial tools that support these processes and ensure everything is done according to industry-specific standards. These include tools such as static code analyzers that must be kept up to date with evolving programming languages like C++, and coding rules defined by organizations such as MISRA. Replicating this structure within an open-source workflow, and consequently with an open-source toolchain, is a significant challenge.

When maintaining an open-source project like iceoryx, you want certain checks to happen automatically with every pull request. In our case, this includes running a static code analysis and performing a build targeting a safety-certified operating system commonly used in the industry. These tools are not available on the GitHub platform, and it is difficult to convince vendors to provide either the tools or the analysis results free of charge in an open-source context. Additionally, coupling a public build on the GitHub CI/CD pipeline with an internal CI/CD system is not a technical integration most projects are eager to solve. It is frustrating when a pull request from a motivated external contributor must be rejected because a tool reports a failure they have no way of reproducing locally. The hope is that, as more and larger players engage in the development of certifiable OSS, their resources and influence will make it possible to establish an open-source toolchain that meets all safety requirements.

Business Models and Ecosystem Tensions

While larger companies may fully sponsor OSS projects as a way to strengthen their ecosystem, smaller entities often rely on sustainable business models such as open-core strategies, paid feature development, or service-based offerings. Safety-critical use cases add further complexity by requiring the creation and maintenance of detailed artifacts such as safety manuals, risk analyses, and compliance documentation. Producing these materials demands significant effort, and many in the field acknowledge that writing the actual code is often one of the smaller parts of the overall effort. This reality stands in tension with the widely desired principle of "everything is open and certified," which would offer a powerful argument in favor of trusting OSS projects.

2iceoryx is a key technology addressing one well-defined challenge within larger software stacks, such as those used in software-defined vehicles. It is developed by a small team, and fully open-sourcing every safety artifact would significantly impact the business viability of the company behind it. We believe that safe OSS must also accommodate models that allow smaller, innovative players to participate meaningfully. The ecosystem as a whole will only thrive if it includes and sustains contributions from both large industry players and smaller companies or research institutes.

Key Takeaways for the Audience

• OSS continues to face skepticism in safety-critical domains. Changing this perception requires ongoing education and a growing portfolio of successful, high-quality projects.
• A genuinely open-source safety-critical development process must support all compliance-related activities, including a comprehensive and open-source toolchain.
• Safe OSS development is not cost-free. It requires long-term commitment and viable business models. Without proper funding and structural support, open innovation in safety-critical fields will remain rare.
• This talk encourages all participants, developers, safety engineers, business leaders, and toolchain providers, to reflect on what it will take to complete this journey and make safe open-source software a practical reality.

Short Bio:

Michael Pöhnl is Chief Technology Officer at ekxide IO GmbH. Before joining ekxide, he worked for Apex.AI and Bosch. At Apex.AI, he served as Principal Engineer, where he led the technical strategy and coordinated the product architecture of Apex.Grace and Apex.Ida. At Bosch, he held various engineering and research roles, focusing on engine control systems, video-based driver assistance, corporate research, and automated driving.

Over the past 15+ years, his work has centered on zero-copy data communication. A microcontroller-based middleware he developed is deployed in radar, front video, and surround-view systems across millions of production vehicles from multiple manufacturers. The POSIX version, developed by his teams, was open-sourced in 2019 as Eclipse iceoryx and is now used across a range of industries worldwide. Today, ekxide is the main company behind the Eclipse iceoryx project, continuing its development and stewardship. 

Friday, September 26, 10.30 AM