An automated insulin pump - PowerPoint PPT Presentation

1 / 22
About This Presentation
Title:

An automated insulin pump

Description:

A more complex decision based on previous levels and rate of change of sugar ... more than once every year years (this repair time dominates everything else) so ... – PowerPoint PPT presentation

Number of Views:354
Avg rating:3.0/5.0
Slides: 23
Provided by: IanSomm8
Category:

less

Transcript and Presenter's Notes

Title: An automated insulin pump


1
An automated insulin pump
2
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

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.

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

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.

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.

7
Glucose measurements
Sugar level
Undesirable area
Inject
Inject
Do not inject
Do not inject
Safe area
Do not inject
Unsafe area
t1
t2
t3
Time
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

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.

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

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

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

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

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

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.

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

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

18
Risk analysis example
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

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

21
Insulin pump fault tree
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.
Write a Comment
User Comments (0)
About PowerShow.com