Safety Frontier: A Retrospective on ELISA

ELISA (Enabling Linux In Safety Applications) is an open project that brings together functional safety practitioners, software engineers, and open source software contributors, to learn from each other and collaborate on a singularly challenging mission: working out how we can safely use Linux — an open source software project that powers most of the web and the majority of smart phones — in systems that have an even more important role: protecting us from harm.

These safety-critical systems include applications such as the advanced driver assistance features that you might have in your car, or control systems for medical equipment, trains, agricultural vehicles, or even aircraft. Historically, the software in such systems has been purpose-made: developed using dedicated tools or methodologies, and following rigorous quality control processes.

As the technology involved in safety-critical systems has grown in scope and complexity, however, the desire to take advantage of general-purpose and open source software as part of products has grown steadily. While this is permitted by the applicable regulations and standards, the use of pre-existing software in this way must be backed by safety arguments (reasoned explanations of how a system or component contributes to a safety design) and safety cases (detailed documentation with supporting evidence to show that appropriate engineering and quality management processes were applied).

Accomplishing this is especially challenging when the software in question is as complex and extensive as Linux, which has a code base of nearly 30 million lines. The ELISA project was created to consider how best to approach this, and how existing tools, methodologies, tests, documentation and other evidence from the open source world can help.

"Its five year mission..."

I have been contributing to the project for five years, starting with the first workshop in June 2019. This has meant participating in weekly meetings for various working groups, and regular in-person and online workshops, including the most recent one at the start of this month.

Although I was a newcomer to safety when I joined ELISA, I had worked with Linux in various contexts, including automotive, and was a contributor to the Trustable Software project, exploring related topics. However, I had limited experience with open source communities, and wanted to understand more about Linux, how it is developed and the implications of this in a safety context.

Open source software projects such as Linux underpin the development of many systems and components at the forefront of advanced system development, including safety-critical systems; key examples are the technologies enabling the use of connectivity, graphical processing and machine learning to extend the capabilities of automated systems. Linux is already relied upon to power business-critical systems running on servers, network devices, tablets, mobile phones or personal computers, but it is considered unproven from a safety-critical perspective.

This means that, where Linux is already used in such contexts, its role is carefully circumscribed, either by delegating the ultimate responsibility for ensuring safety to other systems or components, or by conducting costly 'hardening' and verification work focussing on its use in a given application. The latter is typically restricted to a specific (often older) version of the software, which makes it difficult for products to benefit from ongoing bug fixes and feature development by the originating ('upstream') open source projects. More frustratingly, the documentation and verification materials that are created as part of such efforts are rarely shared with the open source community.

The challenge for ELISA, therefore, is to find a way to use Linux in safety applications that does not simply delegate all safety-related responsibilities to other components, or make use of a single 'blessed' version of Linux. Ideally, the approaches we devise should also enable other Linux users to build upon the tools, documentation and improvements created by our efforts, in the same spirit of mutually beneficial cooperation with which Linux is provided to the world.

The most recent ELISA workshop was in Lund, a delightful city in southern Sweden, just a short train journey across the bridge from the Danish city of Copenhagen. The two day event was graciously hosted by Volvo Cars, and was attended by a mixture of regular ELISA contributors and newcomers, the latter hoping to find out more about the project, functional safety, or the challenges of using Linux in safety-related contexts.

Amongst the topics we discussed were two initiatives introduced at the last workshop, both of which aim to address the same underlying problem: how can we at ELISA create meaningful materials, which others can use in their work with Linux, when (a) the scale of the analysis required seems so vast, and (b) meaningful safety analysis must be conducted in the context of a specific system?

The first of these is initiatives to explore how we might define a core set of parts or aspects of Linux, which we can treat as our first priority. Our intended approach here is to define this core set in terms of functional design elements: specific features or necessary properties of Linux that are required to support safety-critical applications at the most fundamental level, as opposed to entire subsystems or particular sections of source code.

The second is an initiative that we have been pursuing in OSEP, which is a kind of negative counterpoint to the first: compiling a list of of known problems, limitations or risks associated with Linux, which any system incorporating it must necessarily consider and address, even if only to establish why a given problem does not apply for that system.

It was particularly good to have active participation from some of our host's functional safety experts, who gave us an insight into the role that advanced software systems play in modern cars, and the challenges they face in managing the safe integration of these systems. There were also new participants from the Linux and other open source communities, and from other parts of the automotive industry, as well as some with functional safety experience with other operating systems, or software engineering experience in other domains.

Many of the topics that we covered were recurrent themes: explaining the role of ELISA to newcomers, and why we cannot simply create a 'safe Linux' for them to use as a 'drop-in' operating system in their safety-critical applications; grappling with the concepts and terminology of international safety standards like ISO 26262, and debating how these may be applied to the development of Linux, or products involving it; discussing how best to coordinate activities between the various ELISA working groups, and make their work accessible to a wider audience.

"These are the voyages..."

One thing that appealed to me about ELISA from the very start was the sense that we were going on a voyage of discovery together. This wasn't a territory that had already been mapped, and many outsiders (and even a few early participants) believed that the enterprise was - and always would be - doomed to failure.

When I first joined, my understanding of functional safety was limited, and I spent more time listening and learning than I contributed. There were a lot of unfamiliar terms and concepts to grasp in both domains, some passionate opinions were frequently expressed and many of those involved knew each other from past projects. However, I still felt able to speak up when I did have something to contribute, such as explaining how to do a basic STPA at the first workshop, and almost everyone involved seemed more than happy to share their knowledge.

These are important factors. In common with other open projects, ELISA is more a community than a project, at least in the sense that the latter word is typically used. We participate on a volunteer basis, even if our employers are members of ELISA, and unlike other organisations, we do not have a committed 'bank' of engineering effort to apply to the technical and organisational problems that we find. This is just one of the reasons why we can't tell you when a 'safe Linux' will be available for you to use in your products!

What ELISA can provide, however, is a community of peers with which to discuss your questions about safety or Linux, or share the particular challenges that you may be facing on your own voyages of discovery in this arena, or the solutions that you have found to these!

In ELISA today, it is not always easy for newcomers to working groups to get past that first sense of bewilderment or not-belonging, especially if we are in the middle of debating something. In the OSEP working group that I chair, and in the other groups that I've attended over the years, we encourage new people to introduce themselves, to share the reasons they have come to ELISA and what they hope to gain from their participation.

One thing that might help newcomers with this would be a series of 'primers' on the topics that ELISA has discussed in the past, explaining the conclusions that we came to (and why), and how these have informed the approaches that we are following today.

"Its continuing mission..."

Something that has become more and more apparent to me over the years is the necessarily open-ended nature of this project. Just as the Linux project is an ongoing endeavour, always introducing new features and simultaneously finding and resolving problems in existing features, so any consideration of how it can be used for safety applications must always have one eye on the future.

When using Linux in a commercial product, whether that product has a safety dimension or not, we must consider how to maintain the version that we use, for the lifetime of the product - which in the case of a car, for example, may be decades. This maintenance has two distinct, but related aspects: the need to review bug fixes or security patches provided by the 'upstream' Linux community and apply these where they have a bearing on our product; and the ability to benefit from improved or extended functionality or properties that have been implemented.

For a safety-related use case, the bug-fixing aspect of this is likely to be most important, but if an improvement could make a system more safe, or improve some other function of the product without compromising its safety, then there might be an equally powerful motivation to apply it. For this reason, our approaches in ELISA must always be informed by the need to remain open to the benefits (and responsibilities) of using open source software in a product.

The other 'continuing' aspect of this mission, however, is the 'safety culture' that needs to be cultivated in any organisation working with systems that can cause harm. Safety is not something that is simply attained; ensuring that products continue to satisfy their safety requirements is an ongoing responsibility for manufacturers. Most importantly, this includes investigating cases where a product has caused or failed to prevent harm, determining the causes of these failings and identifying a remedy.

This means that the approaches ELISA adopts or recommends must necessarily consider the long run for the use of Linux in products, and how the resources made available by the Linux project and related projects like ELISA can help to inform the processes that manufacturers or their suppliers use to investigate and correct safety-related issues.

"To boldly go..."

One aspect that keeps me coming back to ELISA, however, is the sense that we are breaking new ground. While the enormity of the challenges can sometimes feel overwhelming, and the pace at which we are able to progress our work can be frustrating, there is always much to be gained when we dare to keep going against the odds.

My work at Codethink focuses on much the same territory, as I have explained previously, and I have been happy to share my experiences, ideas and frustrations with the ELISA community over the years. Even where our approaches are different, the opportunity to discuss ideas and problems with others who are wrestling with similar challenges, and learn from their experiences, is always valuable.

I don 't know what the next five years of ELISA will hold, but I hope that it will continue to provide a welcoming and stimulating space for people to work together on this challenging but rewarding project.