6/22/011 Case Study: Computer Assisted Resuscitation Algorithm (CARA) System Insup Lee Department of Computer and Information Science University of Pennsylvania 6/22/01

SDRL & RTG University of Pennsylvania 6/22/01 2 People Alwyn Goodloe (Penn) Dr. Jitka Stribna (Penn) Jiaxiang Zhou (Penn) Prof. Insup Lee (Penn) Dr. Oleg Sokolsky (Penn) Prof. Elsa Gunter (NJIT)

SDRL & RTG University of Pennsylvania 6/22/01 3 Goals of CARA case study Facilitate the development of reliable and robust (current and future) CARA systems Use the state-of-the-art formal methods and techniques –Requirement capture and analyzer, model checker, equivalance checker, test generator, etc) –Evaluate the effectiveness of tools –Development of domain specific framework and methodology

SDRL & RTG University of Pennsylvania 6/22/01 4 Embedded Systems Difficulties –Increasing complexity –Decentralized –Safety critical –Resource constrained Non-functional: power, size, etc. Development of reliable and robust embedded software Increased development cost implies greater emphasis on reuse …

SDRL & RTG University of Pennsylvania 6/22/01 5 Properties of embedded systems Adherence to safety-critical properties Meeting timing constraints Satisfaction of resource constraints Confinement of resource accesses Supporting fault tolerance Domain specific requirements

SDRL & RTG University of Pennsylvania 6/22/01 6 Progress to date Translated parts of informal requirements to EFSM (Extended Finite State Machines) Our analysis of the requirements ( 3/19/01 ) and Questions/Answers ( 1/24/01 ) generated 29 questions of the following types: –Identifying Inconsistencies (4) –Identifying Incompleteness (10) –Clarification of specific terms (15)

SDRL & RTG University of Pennsylvania 6/22/01 7 Sample Questions Clarifications of specific term –What is an infusate ( Req16 ) Infusate is the ‘stuff’ usually a saline solution that is being pumped into the person Identifying Incompleteness –Is hardware setting on pump active in Auto-Control mode? What happens if the user meddles with the hardware flow knob in Auto-Control mode? The computer can take control of the pumping rate and thus lock out the hardware flow knob. The pump can still be shut off though.

SDRL & RTG University of Pennsylvania 6/22/01 8 Sample Questions (Cntd.) Identifying Inconsistencies –There were several exchanges requesting clarification on the fact that the requirements indicate that a beat-to-beat source is lost after 3 minutes ( Req42 and 43 ), but the Q/A document says it should be 2 minutes ( Q120 ).

SDRL & RTG University of Pennsylvania 6/22/01 9 Overall System Pump –The hardware Cara system –The software Environment –The user Patient –The object

SDRL & RTG University of Pennsylvania 6/22/01 10 Overall System Structure Back

SDRL & RTG University of Pennsylvania 6/22/01 11 The Cara System Component –Pump Monitor –Blood Pressure Detector –Control Algorithm –Display/Alarm

SDRL & RTG University of Pennsylvania 6/22/01 12 Back

SDRL & RTG University of Pennsylvania 6/22/01 13 Pump Monitor Signal from Pump hardware –Plugged-in Whether the pump is plugged in is the pre-condition of the Cara system. Whenever the monitor finds the pump is not plugged in, it will trigger the alarm system and the Cara will revert back to “Manual mode” –back EMF Monitors the voltage of the pump –Air Ok line Monitors the infused liquid for presence of air bubbles –Occlusion line Monitors whether an occlusion fault is found –Wire-continuity Checks continuity of all lines connecting the pump

SDRL & RTG University of Pennsylvania 6/22/01 14 Pump Monitor

SDRL & RTG University of Pennsylvania 6/22/01 15 State Flow to Check Plugged-in Back

SDRL & RTG University of Pennsylvania 6/22/01 16 BP Detector Read BP –Read & Check Cuff Pressure –Read & Check Beat-to-Beat BP Select BP Source –Several sources: cuff pressure, arterial line,pulse wave transmission, etc) –Select control BP Corroborate BP –Corroboration Algorithm –Re-Corroboration Monitor BP Level –Check with BP Set Point –Check BP falls

SDRL & RTG University of Pennsylvania 6/22/01 17

SDRL & RTG University of Pennsylvania 6/22/01 18 BP Source Selection Back

SDRL & RTG University of Pennsylvania 6/22/01 19 Control Algorithm Pump-control Algorithm –Computes drive voltage for the pump –Consists of some modes Polling-control Algorithm –Checks the pumping rate by polling the back EMF line –Computes flow rate, cumulative volume & impedance value and send them to display –Checks impedance of the infused liquid

SDRL & RTG University of Pennsylvania 6/22/01 20 Pump-Control Algorithm

SDRL & RTG University of Pennsylvania 6/22/01 21 Polling-Control Algorithm Back

SDRL & RTG University of Pennsylvania 6/22/01 22 Display/Alarm Message Display –Pump status Pump mode Unexpected status –Pumping data Flow rate Cumulative volume –Override windows Alarm –Alarm messages Alarm type Directions to fix alarm –Audible alarms

SDRL & RTG University of Pennsylvania 6/22/01 23

SDRL & RTG University of Pennsylvania 6/22/01 24 Alarm State Machine Back

SDRL & RTG University of Pennsylvania 6/22/01 25 Preliminary Plan Understand informal requirements (tech report): Aug ‘01 –Translate informal requirements to EFSM –Identify assumptions on four subsystems: environment, patient, pump hardware, CARA systems –Failure modes: detection and handling Check consistency of EFSM (paper): Nov ’01 –Completeness (of events and conditions) –Complete treatment of failures Identify and verify safety properties: Jan ’02 –Extract safety properties from hazard analysis document –Talk to designer Other possibilities –Timing modeling and analysis –Reliability modeling and analysis –Generate tests –Code generation API, hardware spec., what control algorithms Simulator/emulator (?)

SDRL & RTG University of Pennsylvania 6/22/01 26 Announcements 14 th IEEE Symposium on computer-based medical systems (CBMS), NIH, Bethesda, July Web page – (two part: public and password)