Building Open Safety Standards with the Eclipse Trustable Software Project

Standards development for safety-critical software is, unsurprisingly, very conservative. The reason is obvious. When safety-critical software systems fail, people’s lives are at risk. This is true whether the software is in a person’s car, a commercial vehicle like a truck, a heavy vehicle used in mining or heavy industry, or even in medical devices to monitor patients or send alerts to medical professionals. 

But as open standards and collaborative development become ever more common, the process of developing and evaluating safety standards feels increasingly antiquated and opaque. Most engineers are not privy to the actual requirements of the standards themselves. In some cases, it is possible to write software that technically complies with the standards but does not necessarily achieve its actual goal of ensuring people’s safety. And the methods used to develop the software often rely on inefficient and outdated development techniques, like the V-Model. 

Open source has much to offer, and many of the methods used for open source development are already fundamental to how safety standards are developed and evaluated. But taking it a step further by developing an open source framework for evaluating and proving the safety of software in an open way will improve the quality of the standards themselves, the ability of industry to trust in them, and simplify innovation. 

This is what the Eclipse Trustable Software Framework project is working to achieve. 

Safety Standards Need to Keep Pace With Modern Development

This effort began as a research project. A client who worked with major OEMs found that the traditional safety methods were becoming more and more difficult to apply. It was extremely challenging to cope with the increasing complexity of the systems and the scale of the software involved. 

His hope was that there would be ideas, techniques, and software in the open source world that could be useful. Open source had already demonstrated its ability to handle complex projects at scale. But the research project quickly ran into a wall. In discussions with many of my client’s colleagues in the industry, I found a tremendous resistance to using open source for safety-critical applications and concerns around its ability to comply with standards — even though many were using lots of open source projects in their continuous integration infrastructure.

This led to us starting the Trustable Software initiative in 2016. The goal was to create a public discussion group and figure out what would be required for safety-critical industries to start adopting open source methodologies. Now, having finished its community review process, the Trustable Software Framework project is moving into the Eclipse Foundation under the banner of the Software Defined Vehicle Working Group.

Defining a Trustable, Non-Prescriptive Framework

Two important elements emerged from our initial research project, as well as our subsequent engagement with the open source community. 

The first is around trust. The crucial element of safety-critical systems is that you must be able to trust that they do what they say they do. This was the reason for the initial objection to the use of open source that spurred the development of the framework’s six trustable tenets. 

These tenets are meant to prove: 

• The provenance of the software
• How the software is built
• How to change the software without breaking it
• What the software does and does not do
• That it does what it should and doesn’t do what it shouldn’t
• That the previous propositions are true

The second element, the framework, emerged from contact with the open source community. This framework is comparatively new to open source. But many projects have a long history, with well-established processes and methodologies delivering extremely high-quality software. It wouldn’t make practical sense to come in and demand that they align to a new framework. They simply wouldn’t do it. 

This is why the framework is built to provide a map to demonstrate trust, rather than setting out a proscriptive set of processes. Every project has its own processes that are meant to guarantee the quality of its products, demonstrate how it is built, explain how to make changes to it, and so on. The framework is meant to be flexible enough to capture the evidence while still being rigorous enough for safety-critical industries to trust. 

From Standards Alignment to an Open Standard

Another important point about the framework is that it is not a shortcut. It does not, and is not intended to, provide a means for open source to bypass the stringent requirements of safety-critical software development. Rather, it is structured to provide the ability for open source to demonstrate where and how it meets or even exceeds those requirements. 

Part of this involves mapping specific standard certification paths to the framework. We’ve done some work behind the scenes with IEC 61508 to show how our argumentation complies with the standard. After all, safety-critical industries would not have much confidence in our framework if it didn’t match the standards that currently exist. 

But the hope is that in the future, building on these efforts, this framework can lead to the development of truly open, emergent standards. 

Building a New, Open Framework for Safety-Critical Software

Safety isn’t something we want to be private knowledge. Safety standards are a public good, not least because they are produced by volunteers offering their time. But as it is, current standards don’t benefit from the critique they could receive from ongoing expert review in public, as is normal in open source. 

Further enhancing the transparency of our framework is its use of directed acrylic graphs (DAG) to automate evaluation to the degree to which the evidence presented by a project actually proves its claims around safety. In other words, it’s a confidence interval: How sure can you be that this project meets the six tenets that prove it is trustable? Using a DAG provides a way to mathematically demonstrate how confident you can be.

And while the framework is not only usable but already in use, there is always more to be done. One of our key goals is to improve the adoptability of the project, such as by enhancing the documentation, improving, extending, and optimising the tooling, and more. 

Get involved by joining the SDV mailing list and Slack channel.