insulin pump depend spec

8/3/2019 Insulin Pump Depend Spec

http://slidepdf.com/reader/full/insulin-pump-depend-spec 1/13

©Ian Sommerville 2004 Software Engineering, 7th edition. Insulin Pump Slide 1

The portable insulin pump

Developing a dependabilityspecification 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. Afail-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 beconsidered 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 withoutcompromising the usefulness of the system

Hardware failures can only be repaired by return to themanufacturer. This means, in practice, a loss of availability of atleast 3 days




Availability

A general specification of availability suggeststhat the machine should not have to be returnedto the manufacturer more than once every year

years (this repair time dominates everythingelse) so System availability = 727/730 *100 = 0.99

It is much harder to specify the software

availability as the demands are intermittent. Inthis 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. Thismeans 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. Roughlyonce 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 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




Risk analysis example

Identifiedhazard

Hazardprobability

Hazardseverity

Estimatedrisk

Acceptability

Insulin overdose Medium High High Intolerable

Insulin

underdose

Medium Low Low Acceptable

Power failure High Low Low Acceptable

Machineincorrectly fitted

High High High Intolerable

Machine breaksin patient

Low High Medium ALARP

Machine causes

infection

Medium Medium Medium ALARP

Electricalinterference

Low High Medium ALARP

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 hardwareand 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 detectedand 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 inTable 4 should be displayed.

insulin pump depend spec

Documents