SOUP as a "Software Unit"?

ein_stein_sein

Registered
Hello!

I am in the process of trying to really understand how to deal with SOUP according to IEC 62304.
SOUP is theoretically just defined as a "Software Item" that is not developed with the purpose to be in MDSW.

My questions:
  1. Shouldn't SOUP in most cases even be considered as "Software Unit", since we would practically not divide it into smaller sub units?
  2. If it is the case that SOUP is considered a "Software Unit", do we need to "establish acceptance criteria" (5.5.3) for SOUP and do the unit verification (paragraph 5.5.5) ?
SOUP is explicitly only mentioned in a handful of sections in the IEC 62304, but it is considered a "Software Item", possibly even a "Software Unit" so a lot more processes would apply to it.

Cheers,
Max
 

yodon

Leader
Super Moderator
We don't manage SOUP as a unit (or a software item). By definition, you didn't develop it, have no records of its development, and don't control it (other than keeping a snapshot).
 

Tidge

Trusted Information Resource
I've treated SOUP as a unit, but one that I didn't develop. It can appear in the architecture, and if so gets subject to integration testing, as appropriate. This assumes that there are other elements of the software that were developed internally, which integrate with the SOUP.

I can imagine things treated as SOUP that would only be tested in a larger context, such as an off-the-shelf FPGA loaded into a physical device to emulate a component no longer available. The testing would be of the combined device in its application and it would only need to be 'snap-shotted'. A BIOS is similar.
 

ein_stein_sein

Registered
Thank you for your answers!
Can you give me an example of when SOUP appears in the Architecture as a unit and when not?

When you say @Tidge,
such as an off-the-shelf FPGA loaded into a physical device to emulate a component no longer available
would you consider SOUP in this then part of a Software Item, but not a Software Unit?
 

Tidge

Trusted Information Resource
Thank you for your answers!
Can you give me an example of when SOUP appears in the Architecture as a unit and when not?

When you say @Tidge,

would you consider SOUP in this then part of a Software Item, but not a Software Unit?

An example of SOUP that I wouldn't feel obliged to call out in an architecture is a printer driver... there probably is other code that was written to use the printer, but without the printer driver it wouldn't work. The code written to sent things to output devices would be in the architecture (in this example).

The FPGA example is what I would consider a 'software item'. It should be version controlled, but testing (for the exampleI gave) would be very similar to how an engineer would test any discrete component of a PCBA. I wouldn't feel obligated to treat discrete FPGA 'programs' to a full-blown 62304 treatment; I think that would be overkill.

This may be simplistic, but here is how I explain 'units': Units are the lowest level of a design to which someone will ascribe 'blame' and could ask that it be modified. For software: SOUP means that you can't modify it, so you have to find a replacement. In the case of an FPGA, no one is going to blame a single transistor; they are either going to replace the whole FPGA or the code loaded into the FPGA.
 
Top Bottom