Page 169 - Safety Risk Management for Medical Devices

148 Safety Risk Management for Medical Devices

15.11 Tips for developing safety-critical software
In this section, general tips and advice are provided to aid in the successful develop-
ment of safety-critical medical software.
• Do not postpone software risk analysis until late in the product development
process. Retrospective software risk analysis cannot effectively reduce risk.
• When adding new software features, analyze for introduction of new Hazards,
or compromising existing software Risk Controls.
• Consider platform evolution, e.g., operating system upgrades in your risk man-
agement process.
• Ensure that good software configuration management and safety impact analysis
due to software changes are a part of your Quality Management System. This
would help detect changes with unexpected consequences.
• If possible, separate the safety-critical software items and keep them as simple
and small as possible.
• IEC TR 80002-1 [26] table C.1 offers advice on avoiding pitfalls in the devel-
opment of software for medical devices.

NASA JPL lead scientist, Gerard J. Holzmann has produced a set of 10 rules to
help guide the development of safety-critical software. Below, the 10 rules are summa-
rized. For further details, see Ref. [28]. These rules are directed at C programming
language, but you can benefit from them in other programming environments as well.

1. Rule: Restrict all code to very simple control flow constructs do not use
goto statements, setjmp or longjmp constructs, and direct or indirect recursion.
2. Rule: All loops must have a fixed upper-bound. It must be trivially possible
for a checking tool to prove statically that a preset upper-bound on the num-
ber of iterations of a loop cannot be exceeded. If the loop-bound cannot be
proven statically, the rule is considered violated.
3. Rule: Do not use dynamic memory allocation after initialization.
4. Rule: No function should be longer than what can be printed on a single
sheet of paper in a standard reference format with one line per statement and
one line per declaration. Typically, this means no more than about 60 lines of
code per function.
5. Rule: The assertion density of the code should average to a minimum of two
assertions per function. Assertions are used to check for anomalous conditions
that should never happen in real-life executions. Assertions must always be
side-effect free and should be defined as Boolean tests. When an assertion
fails, an explicit recovery action must be taken, e.g., by returning an error
condition to the caller of the function that executes the failing assertion. Any