Efficient Safety Critical Systems Development - Is FLOSS the only answer?

Michaël Friess and Cyrille Comar, AdaCore

FLOSS is just about software license

In a few years' time, Free/Libre Open Source Software (FLOSS) has gained recognition in the industry and is now widely accepted. However, this global acceptance has not reached a few domains, like the one of safety critical systems where some people are still questioning the appropriateness of FLOSS for this type of development. While others, in the same domain, have already successfully used and certified FLOSS several years ago.

To evaluate the role of FLOSS for safety critical systems, one has to understand what FLOSS actually is. A significant term in FLOSS is “License”. FLOSS is about a Free/Libre license that is granted to the user of the software, to be compared with Closed/Restrictive Licenses that are currently associated with most software.

For a developer, using FLOSS is like using Closed/Restrictive License software. But with FLOSS he or she has additional degrees of freedom.

So, is FLOSS appropriate for safety critical systems developments? It is at worse neutral and most probably an advantage for such development.

The full paper will develop the topics above and will give concrete examples on the use of FLOSS in safety critical systems.

Where do you get your FLOSS from?

This is actually the important question to ask.

If you are purchasing your FLOSS as a COTS (Commercial Of the Shelf) product, it will require the same attention as purchasing COTS with a Closed/Restrictive license. In particular, attention should be paid on the ability of the software vendor to provide new software versions, bug fixes and long term maintenance. It is worth noting that, by giving access to software sources and build, FLOSS gives you a way to better deal with a potential software vendor failure to accomplish his due diligence.

If you are acquiring your FLOSS software on internet without establishing a commercial relationship with the developers or owners of the software, you are taking a risk since you have little guarantee on the fitness for purpose, both legally and technically, of the component you plan to use. This risk is typical of uncontrolled internet downloads and is made worse if the freely downloadable software does not come with an open license.

FLOSS gives more freedom to the user. This freedom has to be properly exercised and the actual choice made for each project should be the result of a cost vs. risk analysis.

Safety critical software is not just software

The points developed above show that the questions related to the use of FLOSS are actually not specific to the development of safety critical systems. That being said, the FLOSS approach is of clear interest for the development of safety critical software as we will see later.

Let’s first see what safety critical software is and what makes it different from non safety-critical software.

Often, the development of safety critical software has to comply with certain safety critical standards. Widely used standards like IEC61508 or DO-178 require software development to follow stringent development processes in order to meet all the objectives described in those standards. It is also necessary to produce certification evidence showing how these objectives have been met.

We can call “safety critical software” the combination of software plus all its certification artifacts. The body of artifacts can be an order of magnitude more voluminous than the software product itself. So development of safety critical software requires much more than the development of software sources. Focusing on software only in such a context actually means that we are missing most of what makes software safety critical: software certification artifacts.

Trying to transform a posteriori, existing non-safety critical software into a safety critical one, may be a dangerous and costly proposal: not only, as seen before, a lot of work needs to be done in order to produce the required certification evidence but more importantly, safety properties are usually carried, at least in part, by the software architecture and design. So if the latter have been done without any attention to safety considerations, it may be impractical to retrofit them afterwards. The problem here is inappropriate software reuse and is independent from the license of the software itself.

Handling efficiently certification evidence

Safety standards tend to be more and more stringent and software certification is currently often considered as a heavy, costly and rigid process. There is a clear need from the industry for improvements in order to achieve software certification more efficiently.

This is the driving motivation of the Open-DO initiative (www.open-do.org) that aims at a cooperative and open framework for the development of certifiable software. What makes its approach unique is the following:

• For an effective way to share costs, it takes FLOSS as the basis for its development organization
• For a complete answer to the needs of the development of certifiable software, it considers not only the software, but also the certification artifacts
• For a better answer to the needs of today’s software development, to ease software evolution and allow easy regeneration of certification artifacts, it puts agile methods at the heart of its development process.

Projects developed under the Open-DO auspices provide the basis for software components and tools that can be used in a safety-critical context. This paper will present how a project can benefit from this approach and can integrate components from the Open-DO initiative in its software development.