an automated insulin pump
Post on 05-Jan-2016
32 Views
Preview:
DESCRIPTION
TRANSCRIPT
©Ian Sommerville 2004 Software Engineering, 7th edition. Insulin Pump Slide 1
An automated insulin pump
©Ian Sommerville 2004 Software Engineering, 7th edition. Insulin Pump Slide 2
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
©Ian Sommerville 2004 Software Engineering, 7th edition. Insulin Pump Slide 3
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.
©Ian Sommerville 2004 Software Engineering, 7th edition. Insulin Pump Slide 4
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.
©Ian Sommerville 2004 Software Engineering, 7th edition. Insulin Pump Slide 5
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.
©Ian Sommerville 2004 Software Engineering, 7th edition. Insulin Pump Slide 6
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.
©Ian Sommerville 2004 Software Engineering, 7th edition. Insulin Pump Slide 7
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
©Ian Sommerville 2004 Software Engineering, 7th edition. Insulin Pump Slide 8
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
©Ian Sommerville 2004 Software Engineering, 7th edition. Insulin Pump Slide 9
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.
©Ian Sommerville 2004 Software Engineering, 7th edition. Insulin Pump Slide 10
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
The formal specification of the insulin pump is covered in the following lecture
©Ian Sommerville 2004 Software Engineering, 7th edition. Insulin Pump Slide 11
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
©Ian Sommerville 2004 Software Engineering, 7th edition. Insulin Pump Slide 12
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 13
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 14
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 15
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 16
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
©Ian Sommerville 2004 Software Engineering, 7th edition. Insulin Pump Slide 17
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).
Insulin system hazards
©Ian Sommerville 2004 Software Engineering, 7th edition. Insulin Pump Slide 18
Risk analysis example
Identifiedhazard
Hazardprobability
Hazardseverity
Estimatedrisk
Acceptability
Insulin overdose Medium High High IntolerableInsulinunderdose
Medium Low Low Acceptable
Power failure High Low Low AcceptableMachineincorrectly fitted
High High High Intolerable
Machine breaksin patient
Low High Medium ALARP
Machine causesinfection
Medium Medium Medium ALARP
Electricalinterference
Low High Medium ALARP
Allergic reaction Low Low Low Acceptable
©Ian Sommerville 2004 Software Engineering, 7th edition. Insulin Pump Slide 19
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 20
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 21
Insulin pump fault tree
Incorrectsugar levelmeasuredIncorrectinsulin doseadministeredorCorrect dosedelivered atwrong time
SensorfailureorSugarcomputationerrorTimerfailure PumpsignalsincorrectorInsulincomputationincorrectDeliverysystemfailure
ArithmeticerrororAlgorithmerrorArithmeticerrororAlgorithmerror
©Ian Sommerville 2004 Software Engineering, 7th edition. Insulin Pump Slide 22
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.
top related