Got SOUP? - Part 2 - OS, Drivers, Runtimes
By Mitch on Friday, 24 May 2013, 14:03 - Standards - Permalink
We've seen in the last article, what is a SOUP and what is not a SOUP, according to IEC 62304.
We've also seen that a lot of 3rd party software are SOUPs, to begin with OS, drivers, runtimes, Just-In-Time (JIT) compilers and frameworks.
How to deal with those to be compliant with IEC 62304?
What IEC 62304 expects for SOUP
Requirements about SOUP are spread across IEC 62304 standard. Mainly these requirements are about:
Requirements
The manufacturer shall describe what requirements (functions or non-functional) are necessary to have the SOUP work.
Architecture
The manufacturer shall define the software architecture to have the SOUP work in appropriate conditions.
Maintenance
The manufacturer shall monitor the SOUP lifecycle: patches, new versions...
Risk Analysis
It is mandatory to do a risk analysis related to the SOUP.
Configuration management
SOUPs have to be managed in configuration.
OK, so take the right measures. I won't more discuss this requirement about config management.
That said, it doesn't help to know how to comply with these requirements. Let's see what can be done.
OS is a SOUP
OS's deliver dozens of services, some are basic (file system, IP stack), some are of higher level (multi screen management, default archiving tool…).
Depending on its safety class, integration of your software on the OS should be taken for granted or not. For class C, it may be relevant to list basic services that are used and to unitary test them. For other classes, it is a case-by-case decision based on risk analysis.
Requirements
IEC 62304 requires that the manufacturer describes what requirements are necessary to have the SOUP work.
In the case of OS, we take the problem in the reverse order. It is more relevant to define requirements to have your software work with the services delivered by the OS. Perhaps not all services (yes, you use the file system), but only those that are relevant and/or peculiar to your software.
Architecture
IEC 62304 requires that the manufacturer defines the software architecture to have the SOUP work in appropriate conditions.
Once again, you may take the problem in reverse order, and define your architecture to have it work on the OS. With this architecture, you may end up with hardware requirements, to make OS + software run in appropriate conditions.
Maintenance
IEC 62304 requires that the manufacturer monitors the SOUP lifecycle: patches, new versions…
There are two main possible cases:
- Either the OS version is frozen at design. Eg: your software works on linux debian 6.0.7 with kde desktop.
- Or the OS version is user-dependent. For example, your software works on Windows XP SP3 or higher.
In the frozen case, only updates for cyber security may impose a change of version.
In the open case, the updates of the OS may be analyzed to verify that they don't downgrade software performances nor bring new safety issues.
That may lead to a complete verification of your software when you update the OS. This verification depends on the types of changes in the OS. A complete verification is very probable when you upgrade to a newer version, whereas a few tests may be enough if you apply a security patch.
Risk Analysis
It is mandatory to do a risk analysis related to the SOUP. But how to make a risk analysis related to an OS?
Risk analysis is based on the probability and consequences that the OS doesn't provide its services with expected performances.
As we wrote in introduction, services provided by OS's are taken for granted. It's when your software works in limit conditions that OS failures can happen.
If your software read-writes a 5kb file every minute, we know that it works on a standard PC. But if your software read-write a 5Gb file every minute, it may not work. In this case, some preliminary tests are necessary to verify that the OS can hold the load over time. And the SW/HW architecture may be updated as well.
The safety class of the software is also important in the risk analysis. For class C software, it may be relevant to assess with scrutiny each OS service, whereas for other classes, a macroscopic assessment of HW + OS + SW integration may be enough.
Driver is a SOUP
Drivers are more or less additional services plugged into the OS. Even if the service they provide is peculiar to a dedicated hardware, drivers should be treated in a very similar way, albeit identical, to OS's.
The main difference is the presence of the hardware peripheral, controlled by the driver. That means that you have to verify that the hardware works in appropriate conditions.
Requirements
As for the OS, it is relevant to define requirements to have your software work with the services delivered by the driver.
Architecture
Likewise, it is necessary to define your architecture to have it work with the driver and the underlying hardware. With this architecture, you may end up with hardware requirements, to make OS + drivers + software run in appropriate conditions.
Risks Analysis
Risk analysis is based on the probability and consequences that the driver doesn't provide its services with expected performances.
But there is a new condition. Risk analysis shall also be based on the probability and consequences that the connected hardware doesn't work with expected performances. This hardware risk analysis may have been completed at the system level and may be an input data of software design.
In the next post, we'll continue our journey in the SOUP territory, by paying a visit to runtimes and frameworks.
