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-03-06]
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).
Learn more about TT software architectures
The Second Edition of ‘The Engineering of Reliable Embedded Systems’ (ERES2), documents an industry-proven approach to the development of software for reliable, real-time embedded systems, based on the use of ‘Time Triggered’ (TT) architectures.
What distinguishes TT approaches is that it is possible to model the expected system behaviour precisely. This means that: [i] during the development process, we can demonstrate that all of the requirements have been met; and [ii] at run time, we can detect problems very quickly.
The end result is that we can have a high level of confidence that a TT system will either: [i] operate precisely as required; or [ii] move into an appropriate state if a problem occurs.
The above characteristics mean that appropriately-implemented TT systems provide a particularly effective means of meeting the requirements of various international safety standards.
In order to illustrate how the TT techniques presented in ERES2 can be employed in practical designs, five detailed case studies are included. These studies describe the development of embedded control and monitoring systems for the following products:
- an industrial alarm sounder unit (IEC 61508, SIL 2);
- a domestic washing machine (IEC 60730, Class B);
- a hospital radiotherapy machine (IEC 62304, Class C);
- a steering-column lock for a passenger car (ISO 26262, ASIL D);
- an aircraft jet engine (DO-178C, Level A).
Complete your cost-effective IEC 62304 design successfully using a SafeTTy Solutions™ package
Our SafeTTy Solutions™ packages are designed to help your development team produce a safety-related embedded system quickly and cost-effectively, in compliance with one or more international safety standards (ISO 26262, IEC 61508, DO-178C, IEC 62304, IEC 60730 …).
SafeTTy Solutions packages are based on TT designs and include carefully-selected combinations of our various products and services.
SafeTTy Solutions packages include an appropriate ReliabiliTTy® Technology Licence.
Learn more about SafeTTy Solutions packages …