1 / 16

The Fault-Tolerant Insulin Pump Therapy

The Fault-Tolerant Insulin Pump Therapy. Alfredo Capozucca, Nicolas Guelfi, Patrizio Pelliccione. alfredo.capozucca@uni.lu nicolas.guelfi@uni.lu patrizio.pelliccione@uni.lu. University of Luxembourg Faculty of Sciences, Technologies and Communication

nelly
Download Presentation

The Fault-Tolerant Insulin Pump Therapy

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Fault-Tolerant Insulin Pump Therapy Alfredo Capozucca, Nicolas Guelfi, Patrizio Pelliccione alfredo.capozucca@uni.lu nicolas.guelfi@uni.lu patrizio.pelliccione@uni.lu 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 ActionsBasics 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 • http://homepages.cs.ncl.ac.uk/alexander.romanovsky/home.formal/caa.html

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

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

  6. Case studyRequirement (2/2)

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

  8. Case studyFault 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 actuator’s sensor has detected a problembefore trying to inject the insulin • stop the delivery of insulin and start to ring the danger alarm.

  9. Case studyFault hypothesis (2/3) • Delivery stops (E5, E7): an actuator’s 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 studyFault 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. • Patient’s record unreachable (E12): impossible to have access to the patient’s 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 studyArchitecture

  12. Case studyDesign by CAAs (1/4)

  13. Case studyDesign by CAAs (2/4)

  14. Case studyDesign by CAAs (3/4)

  15. Case studyDesign by CAAs (4/4)

  16. Thank you for your attention! Questions?

More Related