Dealing with SOUP in an IEC 62304 design
One of the challenges that has been raised by our customers in recent months is the need to deal with ‘SOUP’ in safety-related projects, particularly in medical products developed in compliance with IEC 62304.
IEC 62304 (‘Medical device software: Software life-cycle processes’) defines a software item that has already been developed, is generally available and that was not developed for the purpose of being incorporated into a medical device as ‘SOUP’ (Software Of Unknown Provenance).
In this short article, we consider ways of dealing with SOUP. Our focus will be on an IEC 62304 design, but the solution we present can be applied in a wide range of different sectors.
The solution we consider in this article is based on a ‘Time Triggered‘ (TT) software architecture.
We begin by looking briefly at some of the links between TT systems and IEC 62304.
[This page was last updated: 2018-02-02]
Developing software in compliance with IEC 62304 (2006) / Amendment 1 (2015)
IEC 62304 is concerned with the development of software for use in medical devices.
The standard notes that software is often an integral part of medical-device technology. It further notes that the effectiveness of a medical device that contains software requires: [i] knowledge of what the software is intended to do, and [ii] demonstration that the software will fulfill such intentions without causing unacceptable risks.
IEC 62304 requires that the manufacturer of the device assigns a safety class (Class A, Class B or Class C) to each software system.
The classes are assigned based on the impact that (failure of) the system may have:
- Class A: No injury or damage to health is possible
- Class B: Non-serious injury is possible
- Class C: Death or serious injury is possible
IEC 62304 and TT architectures
IEC 62304 is intended to be used together with other appropriate standards when developing a medical device. [IEC 62304 (2006), Section C.1]
In particular, readers of IEC 62304 are encouraged to use IEC 61508 as a source for good software methods, techniques and tools. [IEC 62304 (2006), Section C.7]
At a design level, IEC 62304 has a focus on the use of appropriate risk-control measures.
In our experience, the ‘TT Platforms’ presented in ‘ERES2‘ provide an effective way of implementing such measures.
We can an example of our approach in the example below.
Wrapping up ‘SOUP’
The use of SOUP is considered extensively throughout IEC 62304.
One reason for this is that some medical systems rely in part on the use of COTS operating systems (e.g. Linux® or Windows®), and it would not be practical to re-work this software completely. Instead, it is probably fair to summarise the approach in IEC 62304 as one of segregation and containment.
For example (to summarise and paraphrase again) the user of SOUP in compliance with IEC 62304 must do the following:
- specify the functional and performance requirements of SOUP item (Clause 5.3.3);
- specify the hardware and software requirements of the SOUP item (Clause 5.3.4);
- identify the level of segregation necessary for controlling risk (Clause 5.3.5); and,
- verify the software architecture to ensure (for example) the correct operation of any SOUP items (Clause 5.3.6).
In our experience, use of a ‘TT Wrapper’ and a suite of run-time tests can provide a very effective way of dealing with SOUP, even in complex systems.
To be clear. Use of a TT Wrapper need not require large-scale code changes to the system that employs SOUP (and is compatible – for example – with the use of libraries of ‘unqualified’ code in many cases).
You may also like to read our short article that discusses ways of improving confidence in the safety of autonomous systems using a TT Wrapper.
Please contact us for further information about this example, or to discuss ways in which we may be able to help you to employ a TT Wrapper in your own designs.