The portable insulin pump
• Developing a dependability
specification for the insulin
pump
©Ian Sommerville 2004
Software Engineering, 7th edition. Insulin Pump
Slide 1
Dependability attributes

Availability
•

Reliability
•

Intermittent demands for service are made on the system
Safety
•

The pump should have a high level of availability but the nature
of diabetes is such that continuous availability is unnecessary
The key safety requirements are that the operation of the
system should never result in a very low level of blood sugar. A
fail-safe position is for no insulin to be delivered
Security
•
Not really applicable in this case
©Ian Sommerville 2004
Software Engineering, 7th edition. Insulin Pump
Slide 2
System availability

In specifying the availability, issues that must be
considered are:
•
•
•
•
The machine does not have to be continuously available as
failure to deliver insulin on a single occasion (say) is not a
problem
However, no insulin delivery over a few hours would have an
effect on the patient’s health
The machine software can be reset by switching it on and off
hence recovery from software errors is possible without
compromising the usefulness of the system
Hardware failures can only be repaired by return to the
manufacturer. This means, in practice, a loss of availability of at
least 3 days
©Ian Sommerville 2004
Software Engineering, 7th edition. Insulin Pump
Slide 3
Availability

A general specification of availability suggests
that the machine should not have to be returned
to the manufacturer more than once every year
years (this repair time dominates everything
else) so
•

System availability = 727/730 *100 = 0.99
It is much harder to specify the software
availability as the demands are intermittent. In
this case, you would subsume availability under
reliability
©Ian Sommerville 2004
Software Engineering, 7th edition. Insulin Pump
Slide 4
Reliability metric



Demands on the system are intermittent (several
times per hour) and the system must be able to
respond to these demands
In this case, the most appropriate metric is
therefore Probability of Failure on Demand
Other metrics
•
•
Short transactions so MTTF not appropriate
Insufficient number of demands for ROCOF to be
appropriate
©Ian Sommerville 2004
Software Engineering, 7th edition. Insulin Pump
Slide 5
System failures

Transient failures
•

can be repaired by user actions such as resetting or
recalibrating the machine. For these types of failure, a relatively
low value of POFOD (say 0.002) may be acceptable. This
means that one failure may occur in every 500 demands made
on the machine. This is approximately once every 3.5 days.
Permanent failures
•
require the machine to be repaired by the manufacturer. The
probability of this type of failure should be much lower. Roughly
once a year is the minimum figure so POFOD should be no
more than 0.00002.
©Ian Sommerville 2004
Software Engineering, 7th edition. Insulin Pump
Slide 6
System hazard analysis

Physical hazards
•

Electrical hazards
•

Hazards that result from some physical failure of the
system
Hazards that result from some electrical failure of the
system
Biological hazards
•
Hazards that result from some system failure that
interferes with biological processes
©Ian Sommerville 2004
Software Engineering, 7th edition. Insulin Pump
Slide 7
Insulin system hazards






insulin overdose or underdose (biological)
power failure (electrical)
machine interferes electrically with other medical
equipment such as a heart pacemaker (electrical)
parts of machine break off in patient’s body(physical)
infection caused by introduction of machine (biol.)
allergic reaction to the materials or insulin used in the
machine (biol).
©Ian Sommerville 2004
Software Engineering, 7th edition. Insulin Pump
Slide 8
Risk analysis example
Identified
hazard
Ins ulin overdos e
Ins ulin
underdose
Power failure
Machine
incorrectly fitted
Machine breaks
in patient
Machine causes
infection
Electrical
interference
Allergic reaction
©Ian Sommerville 2004
Hazard
probability
Medium
Medium
Hazard
severity
High
Low
Es timated
ris k
High
Low
Acceptability
Intolerable
Acceptable
High
High
Low
High
Low
High
Acceptable
Intolerable
Low
High
Medium
ALARP
Medium
Medium
Medium
ALARP
Low
High
Medium
ALARP
Low
Low
Low
Acceptable
Software Engineering, 7th edition. Insulin Pump
Slide 9
Software-related hazards



Only insulin overdose and insulin underdose are
software related hazards
The other hazards are related to the hardware
and physical design of the machine
Insulin underdose and insulin overdose can be
the result of errors made by the software in
computing the dose required
©Ian Sommerville 2004
Software Engineering, 7th edition. Insulin Pump
Slide 10
Software problems

Arithmetic error
•
•

Some arithmetic computation causes a representation failure
(overflow or underflow)
Specification may state that arithmetic error must be detected
and an exception handler included for each arithmetic error.
The action to be taken for these errors should be defined
Algorithmic error
•
•
Difficult to detect anomalous situation
May use ‘realism’ checks on the computed dose of insulin
©Ian Sommerville 2004
Software Engineering, 7th edition. Insulin Pump
Slide 11
Insulin pump fault tree
In co rrect
in sulin dose
admi nist er ed
or
In co rrect
sugar le vel
m easur ed
Co rrect dose
deli vered a t
wro ng t im e
Delivery
sy st em
failure
or
Senso r
failure
or
Sugar
com p ut a t io n
erro r
Tim er
failure
In sul in
com p ut a t io n
in correct
or
or
Algo rit hm
erro r
©Ian Sommerville 2004
Pum p
sign al s
in correct
Arit h m et i c
erro r
Algo rit hm
erro r
Arit h m et i c
erro r
Software Engineering, 7th edition. Insulin Pump
Slide 12
General dependability requirements
•
•
•
•
•
SR1: The system shall not deliver a single dose of insulin that is
greater than a specified maximum dose for a system user.
SR2: The system shall not deliver a daily cumulative dose of insulin
that is greater than a specified maximum for a system user.
SR3: The system shall include a hardware diagnostic facility that
should be executed at least 4 times per hour.
SR4: The system shall include an exception handler for all of the
exceptions that are identified in Table 3.
SR5: The audible alarm shall be sounded when any hardware
anomaly is discovered and a diagnostic message as defined in
Table 4 should be displayed.
©Ian Sommerville 2004
Software Engineering, 7th edition. Insulin Pump
Slide 13