Insulin pump overview

The embedded control software for a personal insulin

pump

1Case 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 patient’s 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


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


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


Insulin pump hardware schematic


Activity model of the personal insulin pump


Concept of operation

Using readings from an embedded sensor, the system

automatically measures the level of glucose in the sufferer’s

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


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.


Insulin injection

The decision when to apply insulin does NOT depend on the

absolute level of glucose that is measured in the sufferer’s

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.


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.


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.


Glucose measurements

Time

Sugar level

Unsafe area

Safe area

Undesirable area

t1 t2 t3

Inject

Inject

Do not inject

Do not inject

Do not inject


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


Functional requirements

If the reading is below the safe minimum, no insulin shall be

delivered.

If the reading is within the safe zone, then insulin is only delivered if

the level of sugar is rising and the rate of increase of sugar level is

increasing.

If the reading is above the recommended level, insulin is delivered

unless the level of blood sugar is falling and the rate of decrease of

the blood sugar level is increasing.


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


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


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


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


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


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.


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


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).


Risk analysis example


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


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


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.


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


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


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)

Arithmetic 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

Algorithmic errors


Insulin delivery code


Informal safety argument


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


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.


Safety assertions


Insulin pump overview

Technology

software systems

embedded control software

demand insulin production

industrial control systems

diabetes control

blood sugar levelhowever

level of glucose sugar

systemsthe systems