The Fault-Tolerant Insulin Pump Therapy Alfredo Capozucca, Nicolas Guelfi, Patrizio Pelliccione University of Luxembourg Faculty of Sciences, Technologies and Communication Software Engineering Competence Center 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg-Kirchberg LUXEMBOURG

2 Coordinated Atomic Actions Basics facts conceptual framework coordinating complex concurrent activities distributed system achieving fault tolerance by integrating and extending two complementary concepts Conversations cooperative concurrency implement coordinated error recovery Transactions consistency of shared resources in the presence of failures competitive concurrency

3 Coordinated Atomic Actions Why use CAA? CAA, as a design structuring concept, provides support for the following aspects of reliability and safety: Damage confinement Complexity control Fault tolerance Critical condition validation Nesting A. Zorzo, A. Romanovsky, J. Xu, B. Randell, R. Stroud, I. Welch, "Using Coordinated Atomic Actions to Design Complex Safety-Critical Systems: The Production Cell Case Study", Software: Practice & Experience, 29, 7, 1999, 1- 21

4 Case study The Scenario

5 Case study Requirement (1/2) Implementing the technique Continuous Subcutaneous Insulin Injection: Sensors to check the patients status Pumps to administrate insulin Delivering (over 24 hours per day) the right combined amount of two different kinds of insulin Keeping the patients blood glucose

6 Case study Requirement (2/2)

7 Case study Domain knowledge 1.The doctor must set the parameters according to the specific treatment that the patient should receive. 2.This information will be stored in a patients personal record and will be consulted for the application. 3.The emergency room (ER) people are continually monitoring the patients vital signs. 4.Network connection: 1. The dotted arrows represent wireless connection (this allows the patient to move within the access point range). 2. The doctor and the ER have the classic connection. 5.The values of sensors and of the actuator are always transmitted correctly, without any loss or error. 6.All failure on any sensor or actuator is indicated by a specific value, which shows which kind of failure happened. 7.The alarm signal mechanism is free of faults and does not fail.

8 Case study Fault hypothesis (1/3) Sensor stops (E1 or E2): A wearable sensor could not send valid values (special value of the wearable sensor) (1) try again getting the value to continue the cycle (2) delivery stops and the danger alarm will be turned on. Delivery Limit (E3): amount of insulin dropping out of the safe range the delivery is stopped and the danger alarm is turned on. Actuator stops (E4, E6): an actuators sensor has detected a problem before trying to inject the insulin stop the delivery of insulin and start to ring the danger alarm.

9 Case study Fault hypothesis (2/3) Delivery stops (E5, E7): an actuators sensor has detected a problem after the insulin injection try again to deliver the insulin the delivery of insulin will be stopped and the danger alarm will be turned on. Cartridge very low (E4, E5, E6 or E7): the quantity of insulin in a cartridge is less than the low limit set in the cartridge the delivery continues but the warning alarm is turned on. Cartridge empty (E4, E5, E6 or E7): a cartridge of a pump does not have any more insulin stopping the delivery and starting the danger alarm.

10 Case study Fault hypothesis (3/3) Communication lost (E8, E9, E10 or E11): the whole application is distributed by (at least) three different devices => if the communication between some of these devices is dropped (1) the cycle will be completed using the values collected in the previous step of the cycle. (2) the delivery of insulin is stopped and the danger alarm is turned on. Patients record unreachable (E12): impossible to have access to the patients information set by the doctor (1) try one more time to get this information (2) the treatment will be stopped and the danger alarm must be turned on. Logging problem (E13 or E14): the control system is not able to register on the data base the information about the step of the cycle that has been done the information is kept in a local file. When the data base works again, the information saved on the local file is automatically sent to the data base.

11 Case study Architecture

12 Case study Design by CAAs (1/4)

13 Case study Design by CAAs (2/4)

14 Case study Design by CAAs (3/4)

15 Case study Design by CAAs (4/4)

Thank you for your attention! Questions?