Page 334 -

12.2 Safety specification 317

incorrect computation of insulin into an insulin overdose and an insulin underdose.
An insulin overdose is potentially more serious than an insulin underdose in the
short term. Insulin overdose can result in cognitive dysfunction, coma, and ulti-
mately death. Insulin underdoses lead to high levels of blood sugar. In the short term,
these cause tiredness but are not very serious; in the longer term, however, they can
lead to serious heart, kidney, and eye problems.
Hazards 4–9 in Figure 12.3 are not software related, but software nevertheless has
a role to play in hazard detection. The hardware monitoring software should monitor
the system state and warn of potential problems. The warning will often allow the
hazard to be detected before it causes an accident. Examples of hazards that might be
detected are power failure, which is detected by monitoring the battery, and incorrect
placement of machine, which may be detected by monitoring signals from the blood
sugar sensor.
The monitoring software in the system is, of course, safety related. Failure to
detect a hazard could result in an accident. If the monitoring system fails but the
hardware is working correctly then this is not a serious failure. However, if the mon-
itoring system fails and hardware failure cannot then be detected, then this could
have more serious consequences.

12.2.3 Hazard analysis

Hazard analysis is the process of discovering the root causes of hazards in a safety-
critical system. Your aim is to find out what events or combination of events could
cause a system failure that results in a hazard. To do this, you can use either a top-
down or a bottom-up approach. Deductive, top-down techniques, which tend to be
easier to use, start with the hazard and work up from that to the possible system failure.
Inductive, bottom-up techniques start with a proposed system failure and identify
what hazards might result from that failure.
Various techniques have been proposed as possible approaches to hazard decom-
position or analysis. These are summarized by Storey (1996). They include reviews
and checklists, formal techniques such as Petri net analysis (Peterson, 1981), formal
logic (Jahanian and Mok, 1986), and fault tree analysis (Leveson and Stolzy, 1987;
Storey, 1996). As I don’t have space to cover all of these techniques here, I focus on
a widely used approach to hazard analysis based on fault trees. This technique is
fairly easy to understand without specialist domain knowledge.
To do a fault tree analysis, you start with the hazards that have been identified.
For each hazard, you then work backwards to discover the possible causes of that
hazard. You put the hazard at the root of the tree and identify the system states that
can lead to that hazard. For each of these states, you then identify further system
states that can lead to them. You continue this decomposition until you reach the root
cause(s) of the risk. Hazards that can only arise from a combination of root causes
are usually less likely to lead to an accident than hazards with a single root cause.
Figure 12.4 is a fault tree for the software-related hazards in the insulin delivery sys-
tem that could lead to an incorrect dose of insulin being delivered. In this case, I have