Got SOUP? - Part 5 - Standalone software
By Mitch on Friday, 14 June 2013, 13:43 - Standards - Permalink
After having discussed about open-source software in the last post, we continue today this series about SOUP with the case of standalone software.
The standalone software SOUP category stands for off-the-shelf software executables. They can be:
- Software with GUI used by humans:
- mail client,
- web browser,
- document viewer,
- software delivered by a supplier to manage a hardware or software component,
- Services or daemons running on a server:
- mail service,
- print spooler,
- service delivered by a supplier to manage a hardware or software component.
Unlike frameworks and runtimes, they are not used to host your own software, or have it work. Unlike libraries, they are not linked to your own software. They are standalone from an architectural point of view. They are standalone from a functional point of view.
So, what do we have to do, according to IEC 62304, with standalone software SOUP?
Reminder - What IEC 62304 expects for SOUP
Skip this if you've already read previous posts.
IEC 62304 requirements about SOUP are:
- Software 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.
Standalone software is a SOUP
Let's see what we have to do with standalone software.
Requirements
This is probably where there is the biggest job to do with standalone software.
Off-the-shelf standalone software provide off-the-shelf functionalities. You don't have to develop them, they're already there in the standalone software.
Thus, it is important to list what functions are used, to write them in terms of software requirements, and to finally verify these requirements (i.e. to verify that the listed functions work in your case).
Architecture
Even if the software is standalone, there is probably an interface between that software and yours. Thus, describe how both software work together.
More usual, if the standalone requires some peculiar environment, then design the software and hardware architecture the right way and document it.
Maintenance
No big difference here with other software. You have to monitor the obsolescence and the bug fixes like any other software.
Risk-Analysis
Once again, no big difference here. It may be simplified, compared to other software, like libraries. If the software is really standalone, them there is little risk that it crashes your own software. But, well, it depends on the interface between both.
There is a risk, however, that the standalone software goes into an infinite loop and takes all hardware resources (100% CPU, out of memory...).
The classical solution is to create a supervisor that watches the behavior of the standalone software.
Standalone software are useful because they provide functions or services to the end-user, that we don't need to recreate. We don't have to reinvent the wheel! They have their specific impact on requirements, architecture, and risks. But IMHO, they are usually easier to manage than libraries, frameworks and other SOUP already reviewed.
Next time, we'll see FDA guidances about SOUPs.
EDIT: further reading on web browsers in a new article about validating apps running on web browsers.
