The portable insulin pump Developing a dependability specification for the insulin pump
Dependability attributes 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 (this repair time dominates everything else) 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
Transient failures System 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.
Physical hazards System hazard analysis 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 allergic reaction to the materials or insulin used in the machine (biol).
Risk analysis example Identified Hazard Hazard Estimated Acceptability hazard probability severity risk Insulin overdose Medium High High Intolerable Insulin Medium Low Low Acceptable underdose Power failure High Low Low Acceptable Machine High High High Intolerable incorrectly fitted Machine breaks Low High Medium ALARP in patient Machine causes Medium Medium Medium ALARP infection Electrical Low High Medium ALARP interference Allergic reaction Low Low Low Acceptable
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
Arithmetic error Software problems 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.