Safety-related Software, Linux, and Certification

Contributed by Jason R. Smith, Principal Engineer, UL LLC and ELISA Ambassador

In my nearly 16 years as a certification engineer focusing on safety-related software and functional safety, on many occasions I have found myself working with a client with safety-related software who is not only going through the certification process for the first time, but is also incorporating third-party software such as Linux into their application. Even before I have to answer questions like “How long will this take?”, I’ll often have to answer an even more fundamental question: “Is it even possible to certify this application?”

Jason Smith,
*Certification engineer, expressing doubt*

My typical response usually starts with the dubious phrase, “Yes, but…”

After first explaining that functional safety standards require the software to be developed in accordance with a software development life cycle like the V-Model, my attention then focuses on the third-party software: it wasn’t developed by the client, it wasn’t tested by the client, it doesn’t have its own certification, and the client doesn’t know much about its inner workings. It is what some of us certification engineers call SOUP, i.e. Software of Unknown Provenance.

Soup

Also SOUP

So, what is required of SOUP? Much of it depends on the application. Standards intended to be applied to high complexity systems such as IEC 61508 and ISO 26262 require either proof of certification or submittal of evidence that more or less demonstrates an equivalent level of confidence as certification. However, some standards used in the appliance or medical sectors such as UL 1998 or IEC 62304, generally systems of lower complexity, allow a different approach that effectively treats SOUP “as is”.

The SOUP Approach

The SOUP approach employed in standards such as UL 1998 or IEC 62304 focuses on a few topics:

Information about the SOUP such as a detailed description of its purpose, its function, its available interfaces, and its version are available and understood by the client;
The client has conducted a fault analysis that treats the SOUP as a component of the system, has analyzed how failures of the SOUP could impact the safety of the system, and has measures in place to address those failures;
The client has sought out information pertaining to any known issues or bugs related to the SOUP, has analyzed that information, and has shown that those known issues or bugs do not impact the safety of the system; and
The client has conducted and can show evidence of appropriate verification and testing activities, proving that the SOUP and any measures that have been implemented to address failures of the SOUP work correctly in the context of the application.

The ELISA project is currently working on a white paper that explains this approach in further detail and what resources are available to further facilitate this approach for applications that employ LINUX. If you are interested in reading more or contributing to this white paper, it is located on GitHub here.