The embedded control software for a personal insulin

pump

Case study: Insulin pump overview

Medical systems
More and more medical instruments now include embedded
control software.
These software systems are often critical systems as a
patients life (or at least their health) may depend on the
correct and timely functioning of these systems
The systems themselves are often relatively small and are
therefore understandable unlike, for example, industrial
control systems

Case study: Insulin pump overview

Diabetes
People with diabetes cannot make their own insulin, a
hormone that is normally secreted by the pancreas. Insulin is
essential to metabolise sugar and hence generate energy
Currently most diabetics inject insulin 2 or more times per
day, with the dose injected based on readings of their blood
sugar level
However, this results in artificial blood sugar fluctuations as it
does not reflect the on-demand insulin production of the
pancreas

Case study: Insulin pump overview

A personal insulin pump

A personal insulin pump is an external device that mimics the

function of the pancreas
It uses an embedded sensor to measure the blood sugar level
at periodic intervals and then injects insulin to maintain the
blood sugar at a normal level.
I will draw on this example at various points in the course to
illustrate aspects of critical systems engineering

Case study: Insulin pump overview

Insulin pump hardware schematic

Case study: Insulin pump overview

Activity model of the personal insulin pump

Case study: Insulin pump overview

Concept of operation
Using readings from an embedded sensor, the system
automatically measures the level of glucose in the sufferers
body
Consecutive readings are compared and, if they indicate that
the level of glucose is rising (see next slide) then insulin is
injected to counteract this rise
The ideal situation is a consistent level of sugar that is within
some safe band

Case study: Insulin pump overview

Sugar levels
Unsafe
A very low level of sugar (arbitrarily, we will call this 3 units) is
dangerous and can result in hypoglaecemia which can result in a
diabetic coma and ultimately death.

Safe
Between 3 units and about 7 units, the levels of sugar are safe and
are comparable to those in people without diabetes. This is the ideal
band.

Undesirable
Above 7 units of insulin is undesirable but high levels are not
dangerous in the short-term. Continuous high-levels however can
result in long-term side-effects.

Case study: Insulin pump overview

Insulin injection
The decision when to apply insulin does NOT depend on the
absolute level of glucose that is measured in the sufferers
blood.
The reason for this is that insulin does not act instantaneously
and the change in sugar level does not simply depend on a
single injection but also on previous injections.
A more complex decision based on previous levels and rate of
change of sugar level is used.

Case study: Insulin pump overview

Injection scenarios
Level of sugar is in the unsafe band
Do not inject insulin;
Initiate warning for the sufferer.

Level of sugar is falling

Do not inject insulin if in safe band. Inject insulin if rate of change of level is
decreasing.

Level of sugar is stable

Do not inject insulin if level is in the safe band;
Inject insulin if level is in the undesirable band to bring down glucose level;
Amount injected should be proportionate to the degree of undesirability ie inject
more if level is 20 rather than 10.

Case study: Insulin pump overview

10

Injection scenarios
Level of sugar is increasing
Reading in unsafe band
No injection.

Reading in safe band

Inject only if the rate of increase is constant or increasing. If constant, inject
standard amount; if increasing, compute amount based on increase.

Reading in unsafe band

Inject constant amount if rate of increase is constant or decreasing.
Inject computed amount if rate of increase is increasing.

Case study: Insulin pump overview

11

Glucose measurements

Sugarlevel

Inject

Undesirable area
Inject

Donotinject
Donotinject

Safe area

Donotinject

Unsafe area
t1

t2

t3

Case study: Insulin pump overview

Time
12

System specification
Functional specification
How to carry out the computation to determine if insulin should be
administered

Dependability specification
Requirements to ensure safe operation of the pump

Case study: Insulin pump overview

13

Functional requirements
Ifthereadingisbelowthesafeminimum,noinsulinshallbe
delivered.
Ifthereadingiswithinthesafezone,theninsulinisonlydelivered
ifthelevelofsugarisrisingandtherateofincreaseofsugarlevelis
increasing.
Ifthereadingisabovetherecommendedlevel,insulinisdelivered
unlessthelevelofbloodsugarisfallingandtherateofdecreaseof
thebloodsugarlevelisincreasing.

Case study: Insulin pump overview

14

Formal specification
Because of the complexity of the functional specification,
there is considerable scope for misinterpretation
This system is an example where formal specification can be
used to define the insulin to be delivered in each case

Case study: Insulin pump overview

15

Dependability specification
Availability
The pump should have a high level of availability but the nature of
diabetes is such that continuous availability is unnecessary

Reliability
Intermittent demands for service are made on the system

Safety
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

Case study: Insulin pump overview

16

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 patients 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

Case study: Insulin pump overview

17

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

Case study: Insulin pump overview

18

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

Case study: Insulin pump overview

19

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.

Case study: Insulin pump overview

20

System hazard analysis

Physical hazards
Hazards that result from some physical failure of the system

Electrical hazards
Hazards that result from some electrical failure of the system

Biological hazards
Hazards that result from some system failure that interferes with
biological processes

Case study: Insulin pump overview

21

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 patients body(physical)
infection caused by introduction of machine (biol.)
allergic reaction to the materials or insulin used in the
machine (biol).

Case study: Insulin pump overview

22

Risk analysis example

Identified
hazard
Insulinoverdose
Insulin
underdose
Powerfailure
Machine
incorrectlyfitted
Machine breaks
inpatient
Machinecauses
infection
Electrical
interference
Allergicreaction

Hazard
probability
Medium
Medium

Hazard
severity
High
Low

Estimated
risk
High
Low

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

Case study: Insulin pump overview

Acceptability

23

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

Case study: Insulin pump overview

24

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

Case study: Insulin pump overview

25

Insulin pump fault tree

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.

Case study: Insulin pump overview

27

Safety proofs
Safety proofs are intended to show that the system cannot
reach in unsafe state
Weaker than correctness proofs which must show that the
system code conforms to its specification
Generally based on proof by contradiction
Assume that an unsafe state can be reached
Show that this is contradicted by the program code

Case study: Insulin pump overview

28

Insulin delivery system

Safe state is a shutdown state where no insulin is delivered

If hazard arises,shutting down the system will prevent an accident

Software may be included to detect and prevent hazards such

as power failure
Consider only hazards arising from software failure
Arithmetic error The insulin dose is computed incorrectly because of
some failure of the computer arithmetic
Algorithmic error The dose computation algorithm is incorrect

Case study: Insulin pump overview

29

Arithmetic errors
Use language exception handling mechanisms to trap errors
as they arise
Use explicit error checks for all errors which are identified
Avoid error-prone arithmetic operations (multiply and divide).
Replace with add and subtract
Never use floating-point numbers
Shut down system if exception detected (safe state)

Case study: Insulin pump overview

30

Algorithmic errors
Harder to detect than arithmetic errors. System should always
err on the side of safety
Use reasonableness checks for the dose delivered based on
previous dose and rate of dose change
Set maximum delivery level in any specified time period
If computed dose is very high, medical intervention may be
necessary anyway because the patient may be ill

Case study: Insulin pump overview

31

Insulin delivery code

currentDose = computeInsulin () ;
// Safety check - adjust currentDose if necessary; if statement 1
if (previousDose == 0)
{
if (currentDose > 16)
currentDose = 16 ;
}
else
if (currentDose > (previousDose * 2) )
currentDose = previousDose * 2 ;
// if statement 2
if ( currentDose < minimumDose )
currentDose = 0 ;
else if ( currentDose > maxDose )
currentDose = maxDose ;
administerInsulin (currentDose) ;

Case study: Insulin pump overview

32

Informal safety argument

Case study: Insulin pump overview

33

System testing
System testing of the software has to rely on simulators for
the sensor and the insulin delivery components.
Test for normal operation using an operational profile. Can be
constructed using data gathered from existing diabetics
Testing has to include situations where rate of change of
glucose is very fast and very slow
Test for exceptions using the simulator

Case study: Insulin pump overview

34

Safety assertions
Predicates included in the program indicating conditions
which should hold at that point.
May be based on pre-computed limits e.g. number of insulin
pump increments in maximum dose.
Used in formal program inspections or may be pre-processed
into safety checks that are executed when the system is in
operation.

Case study: Insulin pump overview

35

Safety assertions

static void administerInsulin ( ) throws SafetyException {

int maxIncrements = InsulinPump.maxDose / 8 ;
int increments = InsulinPump.currentDose / 8 ;
// assert currentDose <= InsulinPump.maxDose
if (InsulinPump.currentDose > InsulinPump.maxDose)
throw new SafetyException (Pump.doseHigh);
else
for (int i=1; i<= increments; i++)
{
generateSignal () ;
if (i > maxIncrements)
throw new SafetyException ( Pump.incorrectIncrements);
} // for loop
} //administerInsulin
Case study: Insulin pump overview

36