The open projects rethinking safety culture

In 2016, Codethink started out on a journey to discover how open source software can be safely used to build safety-critical systems — that is, in products where people might be harmed if the software fails to do its job correctly.

Free / libre open source software (FLOSS) projects like Linux have clearly demonstrated the value of collaboration in public when creating software that is — amongst many other things — trusted as the backbone of the web and millions of smart phones. FLOSS projects have also established the essential role of transparency and rapid software updates in dealing with cybersecurity threats. When it comes to safety, however, the difficulties of making a case for using FLOSS in a solution have long been a frustrating obstacle for product developers.

Immediately following Codethink’s announcement about our latest milestone in this journey, I took part in two workshops focussing on safety and open source. This gave me the opportunity to talk about the Trustable Software Framework (TSF) and how we are using it in our development of CTRL OS. I also learnt more from other open source projects about their approaches to creating software where trustability is as important.

The workshops were hosted by Volvo Cars in the Swedish city of Lund, and our hosts also provided several enthusiastic participants. The events were organised by two open source projects that have common goals and challenges, but approach these from different perspectives and with different focuses. The Eclipse SDV project aims to build an automotive software stack to provide “an open technology platform for the software-defined vehicle of the future”. In contrast, the ELISA project is concerned with the use of Linux-based operating systems for safety applications in a range of different domains.

→ Read: 'Codethink Limited Announces World’s First Baseline Safety Assessment for a Linux-Based OS to SIL 3 / ASIL D'

Day 1

Markus Bechter from BMW started the Eclipse SDV workshop by describing the approach to safety being developed for the Eclipse S-CORE or Safe Open Vehicle Core project. The intent is to establish a common set of development processes for components of this project, making the software amenable to safety certification using the ISO 26262 Automotive Safety Standard.

The Trustable Software Framework project was recently accepted into the Eclipse Foundation, so I gave the next presentation. TSF approaches the challenge of using FLOSS in safety more broadly: how can we make a case for using software that has not been developed following a process that conforms to an applicable safety standard? Since this describes the vast majority of existing FLOSS, including many of the tools and dependencies that S-CORE plans to use, an answer to this question is sorely needed, and TSF provides a methodology for making such a case.

After lunch, it was time to welcome a new set of participants and start the ELISA workshop. This began with an introduction to the project for newcomers (see my retrospective from last year’s workshop if you are also new to the project), followed by an Ask Me Anything discussion. Then we had a fascinating talk from David Cuartielles, a founder of the Arduino project who was recently honoured in the European Open Source Awards. After telling us about the latest Arduino (the Portenta x8) and the features of the boards that are relevant for trust, he went on to talk about a topic that he is passionate about: the DESIRE4EU project, which is exploring how to make printed circuit boards that are recyclable, in support of the European sustainable electronics goal.

The rest of the day focussed on the efforts of the ELISA Systems working group to describe and build systems involving Linux in combination with two other FLOSS components: the Zephyr RTOS and the Xen Hypervisor. This led naturally into a discussion of ELISA’s interactions with other adjacent open source communities.

Day 2

Philipp Ahmann and I started the second day with a discussion exploring some common misapprehensions about Linux and safety. We talked about some of the ‘routes’ to certification in the safety standards for pre-existing software, and why these are difficult to apply to open source software. We also explained why the notion of creating a ‘safe’ Linux is misleading, because safety can only really be understood in terms of a system, as opposed to an intrinsic property of a component. This led into discussions of various system models involving Linux, the use of complete redundant systems as part of a larger system design, and the role of hardware components in this, which was a perfect segue to the next session.

Olivier Charrier talked about the role of hardware integration in safety, describing how the responsibilities for achieving specific safety objectives as part of a system design are typically assigned to hardware and software components, and then refined or re-defined in a series of iterations to address the identified gaps. Alessandro Carminati then shared the results of a Linux Features working group investigation to build and analyse a minimal Linux configuration and identify a core set of features that must be considered for any Linux-based system.

After lunch we had a series of ‘special topic’ talks, beginning with interesting talks on PX4SPace — a flight control solution for drones that is being used to build robotic space vehicle solutions — and the SPDX Safety Profile, which extends the SPDX 3.0 ‘knowledge graph’ to include metadata relating to development processes for safety.

Håkan Sivencrona from Volvo then talked about Safe Continuous Deployment, emphasising the importance of building development processes that deliver an ongoing stream of ‘safe’ software deliveries using DevOps principles, not just one ‘blessed’ release that is never expected to change. Igor Stoppa’s talk on “Resilient Safety Analysis and Qualification” sparked a lively discussion, as he argued that any safety analysis of Linux must be based on a detailed understanding of the code, and that this might be a reason not to rely on more complex features or extensions of the kernel.

We then had a talk by Gustavo Padovan of the Kernel CI project, which recently became an associate member of ELISA. He explained that a key goal of the project is to enable projects and organisations testing the kernel to share their results with the wider kernel community by providing a common framework for reporting results. Recent developments include kci.dev, a command line tool enabling developers and maintainers to interact with Kernel CI, and a YAML config file format to enable Linux subsystems to share tailored test case executions for maintainers and the wider community.

The rest of the day focussed on requirements management and traceability, looking first at ELISA’s BASIL tool, and then at an initiative with the Linux Tracing subsystem to develop a low-level requirements specification approach. The latter involved documenting detailed requirements for each function in the kernel, which would be intended to support complete reimplementation of the functionality without reference to the code. One participant noted that this approach might enable the kernel to be re-written in Rust!

Day 3

I kicked off the last day by reprising my presentation about the TSF from the Eclipse workshop for the ELISA attendees. Once again, the enthusiastic engagement and insightful questions from the participants were very gratifying, and Daniel Krippner helped to illustrate how the framework may be applied in practice by talking through his use of it as part of the Eclipse uProtocol project. Daniel and I followed this with a quick discussion of how Rust is becoming increasingly relevant in the safety sphere, and how this may be relevant for ELISA.

The workshop wrapped up with a discussion on the Open Source Best Practices Standard, an initiative that was launched earlier this year. It included a live survey collecting input from the audience about their awareness of existing standards and suggestions for projects to be considered for examples of best practices.

Key Takeaways

I’ve attended numerous ELISA workshops since the first one in 2019, and it was wonderful to note how many passionate and enthusiastic newcomers we had attending this time. We also had participants from a variety of different backgrounds, including academics from the local university and engineers from the rail, medical and aeronautics industries, as well as the always-prevalent automotive specialists.

ELISA’s increasing engagement with other open source communities, including those from the Eclipse Foundation and Linux Foundation projects, is also good to see. The growing interest in safety-related topics in these communities, building on the already well-established awareness of cybersecurity topics, is also encouraging. After the enthusiastic reception that my talks had last week, I am hopeful that the Trustable Software Framework can help to continue this trend, giving all open source projects a way to start engaging with these topics and to share their thinking and strategies for building trust with other projects and communities.

→ Read: 'Codethink Limited Announces World’s First Baseline Safety Assessment for a Linux-Based OS to SIL 3 / ASIL D'