Docstoc

The embedded control software for a personal insulin pump

Document Sample
The embedded control software for a personal insulin pump Powered By Docstoc
					The embedded control software for a personal insulin
pump




                    Case study: Insulin pump overview   1
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




                         Case study: Insulin pump overview      2
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            3
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         4
Insulin pump hardware schematic




                    Case study: Insulin pump overview   5
Activity model of the personal insulin pump




                       Case study: Insulin pump overview   6
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




                          Case study: Insulin pump overview           7
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               8
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.




                         Case study: Insulin pump overview       9
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


     Sugar level


                                    Inject                     Undesirable area
                                                Inject



                                              Do not inject


                                              Do not inject
                                                               Safe area
                                             Do not inject


                                                               Unsafe area

                   t1   t2              t3                    Time
                         Case study: Insulin pump overview                        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


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




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




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




                        Case study: Insulin pump overview   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




                        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




                    Case study: Insulin pump overview   36

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:1
posted:10/31/2013
language:English
pages:36