The world of safety critical embedded software presents a fundamental blocking issue to the adoption of Linux, in the shape of the traceability demands with which such systems are required to comply. No one person can know exactly how every module is built, nor how the code interacts between the modules.

The Siren call of embedded Linux

Imagine a start-up with a great idea for a safety critical application. The chances are that work will initially concentrate on the Proof of Concept (PoC). Whatever the sector, there will be a world of pain later – for example, bringing a medical device to market means seeking FDA approval in the USA, while the EU’s MDR/IVDR compliance rules demand adherence to best practice. But why worry about that when you’re not even sure that the application will work?

It’s likely that the budget will be tight in such a situation, and the selection of Linux is a no-brainer. It’s free, you can download it in a few minutes, and there’s an internet full of advice, support and guidance. What could possibly go wrong?

What are the problems?

Functional safety standards lay down a development life cycle that demands rigorous quality assurance, change management and verification/validation.

Quality Management: At the heart of any critical system is a robust quality management process, usually to ISO 9001 as a minimum. Quality management within an open-source software environment tends to be less rigid.

Change Management: The downside of the fact that that anyone can fix bugs as they are found in open source developments is that it bypasses formal change control processes.

Verification and Validation: A key problem area for mission-critical software is in the verification and validation activities.  The safety case requires evidence to support the argument that the software is fit for purpose; that is, it meets the documented requirements.

In common with many functional safety standards, ISO 26262 describes a V-model for automotive developments (Figure 1).

Figure 1: Traditional sequence for the application of an automated tool chain to the ISO 26262 process guidelines

This requires traceability of requirements through the full lifecycle, verification and validation of the design, and verification and validation of the implementation. Functional safety standards also recommend the adoption of language subsets (coding standards) such as the guidelines described by MISRA. There is no evidence to suggest that any of these functional safety related objectives are typically fulfilled by Linux.

Even if you develop exemplary compliant application software, if you can’t provide evidence that your operating system also achieves that level quality then your system cannot be compliant.

A pragmatic solution for today

If all proof of concept developments had to be completed on certifiable operating systems, then many would never even start. The use of Linux in some form or another is almost inevitable.

Portability is one of the major advantages of any POSIX compliant development. While many Linux implementations are not fully POSIX compliant, it is entirely possible to limit the use of their functionality to those features that are, and still have a more than adequate toolkit to build a practical system.

Even when application development moves from a sandbox “hack it and see” approach to a formally documented, compliant development lifecycle it is entirely practical for even an extended development team to continue to leverage Linux in this way, performing all the verification and validation activity demanded by the functional safety standard of choice, including requirements tracing, the applications of coding standards, unit test (Figure 2), structural coverage analysis etc.

Figure 2: Performing unit test with the LDRA tool suite

Eventually the product has to be readied for market. It may be possible for the Linux foundation’s ELISA to be deployed by then, or a POSIX conformant, commercially available RTOS such as those from QNX and Lynx that are certified for use. In principle, it is then a simple task to recompile your application with a single licence for your certifiable RTOS of choice, re-run the dynamic analysis tests in the new environment, and hit the market!

There are two key considerations to making that a practical proposition, both of which need to be considered early in the project.

POSIX compliance and conformance: Figure 3 highlights the possible degrees of subtle mismatch, capturing in a nutshell the blurring of boundaries between what is defined by the POSIX specification and what is implemented in practice.

That raises questions about portability. For example, if you’ve developed a system deploying an RTOS that includes non-conformant features, any change of RTOS is likely to involve at least a partial rewrite.

Conversely, if the development leveraged a fully POSIX conformant RTOS and the selected replacement is not fully conformant, there will be no guarantee that the new OS implements all of the features leveraged in the code base.

Figure 3: The Open Group’s illustration of architecture compliance and conformance

Fully automated test and requirements traceability: “Re-run the dynamic analysis tests in the new environment” is easy to say, but if all of those tests have been performed by manual means there could be considerable overhead implied.

Ensuring a fully integrated, automated approach to test and requirements traceability can minimise that impact, making the identification of necessary retests easy and their execution a simple matter of re-running them.

Figure 4: Impact analysis of changing requirements with the LDRA tool suite.

Conclusions

Right now, the use of Linux as an operating system of choice for the most safety critical applications is not an option. But that doesn’t mean to say that it can’t be used during the development of such an application. The portability inherent in POSIX offers an option for the transition from proof of concept into a certifiable project.

In practice, that requires careful use of POSIX features, and a seamless mechanism for retest when the time comes to port the application from Linux to a standards compliant alternative.