Software in Medical Devices, by MD101 Consulting

Reminder - What IEC 62304 expects for SOUP

Requirements about SOUP are spread across IEC 62304 standard. Mainly these requirements are about:

• 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.

Runtime is a SOUP

Runtime is a SOUP, but there is always a software development framework behind a runtime. Even the smallest runtime has its framework, like gcc to make C-runtime library linked to an executable.

The Framework behind the runtime

Frameworks provide services for the developer and the architect (make things easier to design and code) or provide services of higher level than those provided by OS's. Most of times, frameworks impose the software architecture. It may be necessary to assess the consequences of the architectural constraints of the framework on the architecture.
Contrary to OS's, services are very framework-dependent. Thus, the types of software failures and the risk analysis are very framework-dependent.
This can be analyzed only on a case-by-case basis.

Runtimes

Runtimes are the libraries and executables provided by a framework. From the C-runtime of the very limited C standard lib framework, to the Java Runtime Environment of the plethoric Java Development Kit framework.
Therefore the requirements of IEC 62304 about runtimes are mostly covered by the analysis of the framework. The risk analysis about frameworks may be completed with the analysis of problems that can be specific to a runtime (memory consumption, number of threads intanciated, deployment methods...).

JIT compilers

JIT compilers are a very peculiar case of framework runtimes. Therefore the requirements of IEC 62304 about JIT compilers are mostly covered by the analysis of the framework and its runtime. The risk analysis about JIT compilers may be limited to the analysis of specific problems that can arise when they are activated (delayed response time, behavior on different target platforms...).

That said, we can rephrase what's above to present it in the same order as we did in the previous post about OS's.

Requirements about frameworks and runtimes

IEC 62304 requires to define what software requirements (functions or non-functional) are necessary to have the SOUP work properly.
For frameworks, we can take it in the reverse order, like for OS's. The job is to design the software to run inside the framework, and to define the hardware + software environment to have the framework runtimes work.
We can then have two types of requirements:

• Those about services used by the software, eg. web services, databases, planned tasks, security...
• Those about hardware + software environment, eg. OS version, HW requirements...

Architecture of frameworks and runtimes

IEC 62304 requires to define the software architecture to have the SOUP work properly.
Once again, we can take the problem in reverse order. We have to make the software run inside its framework. This has consequences on the architecture of the software.
To make a link with software requirements, the real way to do things is:

1. Choosing the framework,
2. Defining the software functional requirements,
3. Defining the software architecture to have software run within its functional perimeter,
4. Defining the software requirements (as such listed above about services and so on) to have the right architecture,

Perhaps, you may find a bit early to place choosing the framework in first position. This is actually what happens in most of cases, except for brand new devices.

Risk Analysis of frameworks and runtimes

As we said above, the risk analysis of framework is always peculiar to each framework and the software implementation.
Having defined a list of framework services (or libraries or else) used by the software, it is possible to guide the risk analysis about the framework with a list of what if questions.
What if this service provided by the framework fails?
What if this framework runtime component fails?...
These questions are definitely not enough to do a risk analysis. They only consider what happens if something internal to software fails. But they are a good start to think about framework risks.

Maintenance of frameworks and runtimes

Frameworks versions are usually frozen at the beginning of design. Unless you know that a new version of the framework will be released during your development project. Or unless you are agile enough to change of framework version on the fly (but this is not today's discussion)!
Changing of framework version poses the same problems as those for OS's. Depending on what's new in the version, migrating to a new version may impose a full verification and validation of a software.

In the next post, we'll see how to deal with open-source librairies.