Page 160 - Safety Risk Management for Medical Devices

Software Risk Management 139

Table 15.6 Harm severity versus software safety class
Harm severity class Software safety class

Catastrophic C
Critical C
Serious C
Minor B
Negligible A

Example: Consider Table 11.1. Imagine a hypothetical System in which a single
hardware failure could cause both Harm.3 and Harm.4. In this System, there is a
software Risk Control for that hardware failure. We want to know the safety class of
the software Risk Control. The highest likelihood Harm for Harm.3 is the Minor
class. The highest likelihood Harm for Harm.4 is the Serious class. Per Step 1 of the
algorithm above, we select Serious class. Consulting Table 15.6, we see that Serious
class correlates to Software Safety Class: C.
By this point, we have determined whether software has a contribution to safety,
and have assigned a software safety class to it. If the software System performs many
tasks, only some of which warrant a safety class of C or B, a manufacturer may desire
to focus their engineering resources on the parts that are responsible for the safety
critical functions. To do this requires the knowledge of the software architecture.
Only after the software architecture is completed, the full set of software items, and their
contributions to safety can be known. Given the top-down System analysis that was done
earlier, we can deduce which software items contribute to which Hazardous Situations.
If the software architecture and design strategy allows segregation and discrimination
among the software Items, then a separate safety classification can be assigned to each
software Item within the software System. If this strategy is chosen, segregation must be
shown to be effective. That is, a mechanism that adversely affects one software item must
not be able to adversely affect another, segregated software item. Examples of segregation
strategies include use of separate microprocessors and partitioned memory. The ade-
quacy/strength of the segregation strategy should be based on the level of risk involved.
The manufacturer may find that the cost and complexity of the segregation
strategy is too high and instead opt to treat all of the software as the highest software
safety class of the Software System.
Fig. 15.3, which is an adaptation of Figure 3 of IEC 62304 [9], provides a
decision process for the determination of the safety risk class of the Software
System. In the beginning, all software is assumed to be Class C by default.
Following the process in Fig. 15.3, if software is initially determined to be class B
or C, an external Risk Control measure is considered. This external Risk Control
may be software or hardware. If the software option is chosen, doing a SFMEA