Page 154 - Safety Risk Management for Medical Devices

Software Risk Management 133

function?” One way to do this is to list the requirements of the software item and con-
sider how not meeting each requirement affects the software item’s intended function.
Software Failure Modes can have direct and/or indirect Causes. Direct Causes are
local to the software item at hand, and do not necessarily affect other software items.
Examples: incorrectly implemented algorithms, errors in input processing, and errors in
output processing of the software item. Indirect Causes include: stack overflow, unini-
tialized pointers, and race conditions. Indirect Causes are more unpredictable than
direct Causes. Other indirect Causes of software failures are: bit flips, low-power condi-
tion, or software sources such as operating systems, libraries, and SOUP.
Unlike DFMEA, SFMEA entries in the column “Causes/Mechanisms of Failure”
would not be things like aging, fatigue, or wear out. Items that go in the column
“Causes/Mechanisms of Failure” are external factors or systemic Causes. Since the
object of the analysis is a software item, the question would be: “what factors could
cause this software item not to perform its function?” For example, consider a software
item that is supposed to pressurize a tank to 10 psi and a pressure sensor provides the
tank pressure as input to the software item. If the pressure sensor input to the software
item is incorrect for any reason, the software item would fail to meet its function.
The entries in the “End Effect” columns would be the consequences of the
software item’s Failure Mode at the boundary of analysis. Boundary of analysis is
chosen by the analyst, and could be, e.g., a software subsystem, the entire software
system, or the medical device. If the scope of analysis is the software system (as a
component of the medical device), then the question is: “How would the Failure
Mode of the software item in question affect the behavior of the software system?” If
on the other hand the scope of analysis is the medical device, then the question would
be: “How would the Failure Mode of the software item in question affect the
behavior of the medical device?” Local Effects are not visible from outside the bound-
ary of analysis but are noteworthy because they may cascade into other End Effects. It
is possible that there would not be any Local Effect.
Determination of whether the software Failure Mode has a Safety Impact can only
be made at the System (medical device) level. In the hierarchical multilevel FMEAs
this can be known only after the integration of the FMEAs into the System DFMEA.
But it may be possible to make some estimations of the Safety Impact in advance. For
example, if it is certain that the Failure Mode would lead to one of the Hazards in the
Clinical Hazards List, it would be a good guess that the Safety Impact will end up
being Y. Another way to estimate the Safety Impact of a Failure Mode is if it would
violate a System requirement which is tagged as Safety.
If the Safety Impact of the Failure Mode cannot be determined in advance, you
can set the Safety Impact to N as a generic setting and use the “No-Safety Impact”
column in the Ratings tab of the template to determine the Severity rating. As the
SFMEA is a living process and goes through an iterative process, when the FMEAs
are rolled up to the System DFMEA, it will become apparent whether a given Failure