Abstract Systems created to support, or whose human life depend upon are critical systems.
Their failure could threaten human life, or the existence of the system environment that operates the system. More and more medical instruments now include embedded control software. The systems are often understandable since they are smaller compared to industrial control systems. These software systems are often critical systems as a patients life may depend on them. In this course work project I will be looking at insulin pump as an example to represent safety –critical systems. Insulin Pump The insulin pump system is a portable, automated insulin pump which is used to administer insulin by diabetics.
People with diabetes usually cannot make their own insulin (a hormone that is normally secreted by the pancreas) and is essential in sugar metabolism to generate energy. 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. The insulin pump hardware components The insulin pump hardware components consists of Controller, Clock, Simulator, Display, Insulin Pump, Insulin Reservoir, Needle Assembly, Sensor, alarm and Power Supply. The diagram below show the relationships between the hardware components and how they work.
Software The overall approach used to produce the insulin pump software was to emulate the hardware organisation by producing separate software objects, for each distinguishable hardware object. Of all of these software objects the controller object is where the bulk of the computation within the system is carried. It is within the controller that the dose of insulin to be delivered is computed and where the self tests are performed. Working in together with the controller object there is a clock object which runs in a thread, constantly determining how much time has lapsed since the software was started or the timer was reset (which happens every 24 hours). Then periodically, at every interval specified the clock triggers certain events required to be performed by the system. A software called display is used to create a graphical user interface to present information to the user.
The data is then presented to the user via text boxes positioned on the graphical user interface. The other software objects model the peripheral hardware units. They record the current state of the hardware units and provide the functionality to change that state. All the mentioned objects combine together to produce the working insulin pump system. In addition, one other object (the simulator software object) is also provided. This object runs in a thread parallel to the insulin pump software and provides the user with the functionality to perform a simulation of the real world events that would affect the pump software in differing manners.
It facilitates the testing process, making it possible to perform the necessary testing required to determine whether the insulin pump system is adequately safe. The make up of the objects within the system is detailed below by the object classes. The objects are represented by three sections: The name of the object class The class attributes The operations associated with object class the following sequence diagrams Illustrates the sequence of object interactions that occur in the insulin pump software. The diagram assumes that a reading has already been given to the Sensor object before the clock begins the sequence of interactions. The final two sequences show how information that is intent to be output to the user is initially passed to the clock object where it is stored in a buffer.
The contents of this buffer are then continually displayed to the user one after another for a period of five seconds each. Sequence of object interactions involved in the manual delivery of insulin If the user decides to operate the insulin pump manually, then he can do so. But the user must determine how much insulin he/she would wish to administer in his/her blood system. This diagram shows that the user must input how much insulin they wish to administer after he/she has switched the insulin pump system to the manual mode, this is done so by pressing the AdministerInsulinBut button as many times as is required in a five second period.
Concept of operation The embedden sensor gives the readings after automatically measuring the level of glucose in the patient’s body. Consecutive readings r0, r1 and r2 are compared and, if they indicate that the level of glucose is rising then insulin is injected to counteract this rise. R2 is the variable for the current reading, while r1 is the last reading and r0 being the previous reading. The ideal situation is a level of sugar that is consistent within some ‘safe’ band.
Sugar levels Unsafe A very low level of sugar is dangerous and can result in hypoglaecemia which can result in a diabetic coma and ultimately death. An arbitrary figure of 3 units can be considered the minimum unit the body needs. 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 When the level of sugar rises above the limit of safe level, it is said to be undesirable.
Levels above 7 units of insulin are undesirable but high levels are not dangerous in the short-term. Continuous high-levels however can result in long-term side-effects such as kidney damage, eye damage etc. 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.
Injection scenarios When the Level of sugar is in the unsafe band The system should not inject insulin; The system should initiate warning for the sufferer. When the level of sugar is falling The system should not inject insulin if in safe band. It should inject insulin if rate of change of level is decreasing. When the level of sugar is stable The system should not inject insulin if level is in the safe band; It should inject insulin if level is in the undesirable band to bring down glucose level; The amount injected should be proportionate to the degree of undesirability i.e. inject more if level is 20 rather than 10.
Injection scenarios When the level of sugar is increasing and the Reading is in unsafe band There should be no injection. If the reading is in safe band There should be an injection only if the rate of increase is constant or increasing. If constant, the injection should be standard amount; if increasing, compute amount based on increase. Reading in unsafe band Inject constant amount if rate of increase is constant or decreasing.
Otherwise inject computed amount if rate of increase is increasing. Attributes of critical systems Critical systems need to be available since lives or businesses depend on them. Lack of availability would cause many hazards or dangers. The Insulin Pump software is a critical software system; it therefore must have the dependability attributes of a critical system. The insulin pump must have high levels of availability, reliability, safety and security. Since the service requirement of the insulin pump is intermittent, we cannot talk about its being available always.
In addition to that, delivery failure of insulin on a single occasion is not a problem although failure for a few hours would have an effect on the patient’s health. Since the machine software can be reset by switching on and off, the recovery of software errors is possible without compromising the usefulness and availability of the system due to its software breakdown. Otherwise it would take along time away from the user for repair. Incase of hardware failure, the machine would be returned to the manufacturer. It would imply loss of availability of at least 3 days.
Reliability The demands of this system are intermittent and it must be able to respond to these demands. We therefore talk about the probability of failure to respond to the demands. In this case we talk about two types of system failure, transient failure and permanent failure. Transient failures can be repaired by user actions such as resetting or recalibrating the pump. In this case a relatively low value of POFOD may be acceptable.
About one failure in every four days. For permanent failures, the POFOD value should be very small. About once in every year. Hazard analysis Some hazards result from the failure of some physical failure of the system. These type of hazards are said to physical hazards. For example parts of the machine break off in the patient’s body.
Hazards caused by electrical failure are referred to as electrical hazards e.g. power failure; machine interferes with electrically with other medical equipments such as heart pacemaker. Biological hazards result from some system failure that interfere with biological processes for example insulin overdose or under dose, infection caused by introduction of machine or allergic reaction to the materials or insulin used in the machine. Insulin overdose or insulin under dose can be the result of errors made by the software in computing the dose required. They are software related hazards. All other hazards are related to the hardware and physical design of the machine.
Risk analysis example Software problems (errors) There are two types of software errors namely Arithmetic error and algorithmic error. Some arithmetic computations cause representation failure. Specification may state that arithmetic error must be detected and an exception handler included for each arithmetic error and the action taken for these errors should be defined. Algorithmic errors are difficult to detect. Realism checks could be used on computed dose of insulin General dependability requirements The system shall not deliver a daily cumulative dose of insulin that is greater than a specified maximum for a system user.
The system shall not deliver a single dose of insulin that is greater than a specified maximum dose for a system user. The system shall include a hardware diagnostic facility that should be executed at least 4 times per hour. The system shall include an exception handler for all of the Exceptions identified The audible alarm shall be sounded when any hardware anomaly is discovered and a diagnostic message a Analysis of the insulin pump algorithm and the safety argument. Algorithm to compute insulin dose The following is the given algorithm for an automated insulin pump which I want to examine, analyze and produce safety argument in order to determine if it is adequately safe.
When the insulin pump is in automatic mode, the software periodically determines (using the blood sugar level readings) the dose of insulin that should be administered to the user. This is the functionality provided by the insulin pump software that ensures the system is considered to be a safety critical system. Before the blood sugar level is read in, a safety check is performed to determine that the system status is correct and that the mode is set to Auto: if (manDeliveryButPressed = = false) { if (status != ERROR && remainingInsulin >= maxSingleDose && cumulativeDose < maxDailyDose) { If these requirements are met then the blood sugar level can be read in: reading2 = Sensor.getReading(); Once the blood sugar level has been read in, the system must determine whether this level represents that the sugar level is too low, at a safe level or is too high. In order to do this the current reading is checked against the safe minimum and safe maximum blood levels defined. Check if sugar level is low: if (reading2 < safeMin) if sugar level is safe: else if (reading2 >= safeMin && reading2 <= safeMax) or if sugar level is too high: else if (reading2 > safeMax) Depending on the outcome of these tests, one of three execution paths is taken, they are: Execution path if sugar level is low compDose = 0; alarm_ON = true; status = WARNING; pumpTimer.displayOutput(“Sugar Low”); If the blood sugar level is less than the safe minimum then the dose computed to be delivered is 0, the alarm is set to be activated, the status of the system is set to warning and the user is displayed a warning message reading “Sugar Low”.
Execution path if sugar level is safe If the sugar level is deemed to be safe then the current reading is compared against the previous reading in order to determine whether, since the previous reading the blood sugar level is stable or falling, if it is then the dose computed to be administered is set to 0: if (reading2 <= reading1) { compDose = 0; } If this is not the case then the sugar level must be rising and a relative dose of insulin must be calculated to attempt to prevent any further increase in the sugar level: // If rate of increase is falling if ((reading2 – reading1) < (reading1 – reading0)) { compDose = 0; } // If rate of increase is increasing else if ((reading2 – reading1) >= (reading1 – reading0)) { // If dose is rounded to zero, deliver the min dose if ((reading2 – reading1) / 4 == 0) { //set the amount to deliver to the min dose compDose = minDose; } else if ((reading2 – reading1) / 4 > 0) { //Set the amount to deliver compDose = (reading2 – reading1) / 4; } } Once it has been determined that an increase has occurred, the first test the software performs is to check whether the rate of increase is falling overall. If it is then the dose computed to be administered is set to 0. Otherwise, the software then proceeds to ensure that the rate is therefore increasing, if it is then a dose to be administered is computed depending on the severity of the increase. If the rate of increase is not severe enough to be rounded to higher number than 0 then the minimum dose is administered. Execution path if sugar level is too high If the sugar level is otherwise deemed to be too high the following code is executed: // If Sugar level increasing if (reading2 > reading1) { // If dose is rounded to zero, deliver the min dose if ((reading2 – reading1) / 4 == 0) { compDose = minDose; } else if ((reading2 – reading1) / 4 > 0) { //Set the amount to deliver compDose = (reading2 – reading1) / 4; } } // If the Sugar level is stable else if (reading2 == reading1) { compDose = minDose; } // If the Sugar level is falling else if (reading2 < reading1) { // If rate of decrease increasing if ((reading2 – reading1) <= (reading1 – reading0)) { compDose = 0; } // If rate of decrease decreasing else { compDose = minDose; } } Again, the software determines whether the sugar level overall is increasing, decreasing or whether the level has remained stable.
The dose is calculated in the same manner as it would be had the sugar level been safe, except when the sugar level high the software not only checks whether the sugar level is falling but also checks the rate at which it’s falling. If the rate of decrease is increasing then the computed dose is set to 0 whereas if the rate of decrease is decreasing, the minimum dose of insulin is computed to be administered. Also if the sugar level is too high, the software computes that the minimum dose should be delivered if the level has remained stable. Safety of the algorithm It is very necessary for the system to determine whether the computed dose is safe after the dose has been computed by the system. This is essential due to the critical nature of the software. We can use the safety argument method of validation to try and prove to a satisfactory level that the insulin pump software is safe; so that we can make certain that the insulin pump system cannot deliver an unsafe quantity of insulin.
Therefore the section of code we must produce a safety argument for is the following: //IF STATEMENT: 1 //If max daily dose will be exceeded by the dose calculated if ((compDose + cumulativeDose) > maxDailyDose) { //Alert the user and set status to Warning alarm_ON = true; status = WARNING; dose = maxDailyDose – cumulativeDose; InsulinPump.deliverInsulin(dose); pumpTimer.displayOutput(“Close to Max Daily Dose”); } //Normal situation else if ((compDose + cumulativeDose) < maxDailyDose) { //IF STATEMENT: 2 if (compDose <= maxSingleDose) { dose = compDose; InsulinPump.deliverInsulin(dose); } //If the single dose computed is too high else { dose = maxSingleDose; InsulinPump.deliverInsulin(dose); } } There are two pre-conditions that would make the system unsafe; a) If the dose calculated to be delivered is greater than the maximum single dose value b) If the maximum daily dose was exceeded. Using the safety argument we must prove that the all the if-statement post conditions contradict the unsafe pre-condition: Safety Argument Using the fault tree analysis shown below will help see the faults or errors that can be found in the system Results The safety argument shows that the potentially unsafe state could be reached and there is a great possibility that a user could be administered the maximum daily amount of insulin in one go. This would happen if this sequence of events were to occur: cumulativeDose = 0 compDose computed to be a very high number If statement: 1 then branch executed dose = maxDailyDose – 0 InsulinPump.deliverInsulin(dose) Conclusion From this safety argument I can conclude that the insulin pump software (if implemented according to the Z specification provided) is unsafe since the potentially unsafe state could be reached. The user could be administered the maximum daily amount of insulin in one go.
The Z specification specifies that the dose should be administered as a post condition of If-statement: 1 (the requirement to administer the insulin at this point is modeled in the Z specification as dose!). In order to eliminate this safety error the point at which insulin is administered (dose!) would have to be moved in the specification. References Architecting dependable systems III: V. 3 by Rogério de Lemos, Cristina Gacek, Alexander Romanovsky – Computers – 2005 Component-Based Software Engineering: 10th International Symposium, CBSE Page 156 by Heinz-W. Schmidt, Ivica Crnkovic, George T. Heineman, Judith A.
Stafford – Computers – 2007 – 283 pages Concurrency in Dependable Computing – Page 61 by Paul Ezhilchelvan, Alexander Romanovsky – Computers – 2002 chapter 4 Software for Dependable Systems: Sufficient Evidence? – Page 124 by Daniel Jackson, National Research Council (U.S.), National Academies Press, Martyn Thomas, Lynette I. Millett – Computers – 2007 Software Engineering Handbook – Page 361 Chapter 39 by Jessica Keyes – Computers – 2003 Software Engineering by Ian Sommerville – Computers – 2006 Part 4 and chapter 18 Structure for Dependability: Computer-Based Systems by Denis Besnard, Cristina Gacek, Cliff Jones – Computers – 2005 Introduction to Fuzzy Reliability – Page 6 by Kai-Yuan Cai, Sushil Jajodia – Computers – 1996 SDI: technology, survivability, and software – Page 259 Software Engineering and Fault Tolerant Systems – Page 25 by P. Pelliccione, H. Muccini, N. Guelfi – Computers – 2007 – 281 pages B.
Nuseibeh and S. Easterbrook, Requirements Engineering
