SDRL & RTG University of Pennsylvania 8/3/2001 Formalization of CARA system requirements Oleg Sokolsky Department of Computer and Information Science University of Pennsylvania

SDRL & RTG University of Pennsylvania 8/3/ People Dave Arney (Penn) Alwyn Goodloe (Penn) Prof. Elsa Gunter (NJIT) Prof. Insup Lee (Penn) Dr. Oleg Sokolsky (Penn) Dr. Jitka Stribrna (Penn) Jiaxiang Zhou (Penn)

SDRL & RTG University of Pennsylvania 8/3/ Roadmap Pass 1: –Understanding of requirements, clarifications –Informal requirements  extended finite state machines (EFSM) Pass 2: –EFSM  SCR* SCR* analysis of consistency and completeness –Identification of assumptions and interfaces between components Pass 3: –Use design specification Use PARAGON and Hermes for behavioral analysis Test generation Pass 4: …

SDRL & RTG University of Pennsylvania 8/3/ Progress to date Pass 1 is completed –Obtained a better understanding of the system –Asked a lot of questions –Formed a basis for a more precise specification Pass 2 is under way –Most EFSMs are translated

SDRL & RTG University of Pennsylvania 8/3/ Pass 1: Getting organized Translated parts of informal requirements to EFSMs –Obtain an unbiased generic description that can serve as a reference model Our analysis of the requirements and the Questions/Answers document generated 30 questions of the following types: –Identifying Inconsistencies (5) –Identifying Incompleteness (10) –Clarification of specific terms (15)

SDRL & RTG University of Pennsylvania 8/3/ Sample Questions Clarifications of specific terms –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 8/3/ More Sample Questions 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 8/3/ Overall System Pump –The hardware Cara system –The software Environment –The user Patient –The object

SDRL & RTG University of Pennsylvania 8/3/ Overall System Structure Environment Pump Hardware CARA System h/w flow setting Air alarm Occ alarm dialog box buttons control voltage #2 (SysGRD) #6 (Ext_Speed_control) AirOK OccOK Back EMF Pump Wires infused fluidBP signals Pump status Current mode BP value BP source Flow rate Infused volume Messages Dialog boxes

SDRL & RTG University of Pennsylvania 8/3/ The Cara System Components: –Pump Monitor –Blood Pressure Detector –Control Algorithm –Display/Alarm

SDRL & RTG University of Pennsylvania 8/3/ The CARA System Display/Alarm Algorithm Pump Monitor Blood Pressure Monitor Manual BPSource BPValue Start A/C Terminate A/C Set BP Reset alarms Mode Infused Volume Flow rate Pumping Polling Failure Exit A/C BPSource BPValue BPAlarms* PluggedIn Air OK Occ OK Impedance Continuity Back EMF

SDRL & RTG University of Pennsylvania 8/3/ Blood Pressure Monitor 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 8/3/ Example: ReadCuffData Wait to do a cuff reading Read cuff data into var. Cuffdat Set frequency Check data End of check First check failed source != cuff source == cuff source != cuff  SampleCuff:=0 CRTimer:=0 InvalidCuffData  CuffNotValid2:=1 CuffLostSource:=1 ValidCuffData SampleCuff==0 && source==cuff && CRTimer!=CuffFreq

SDRL & RTG University of Pennsylvania 8/3/ Pass 2: Detailed formalization Translate EFSMs into tabular notation using SCR* toolset

SDRL & RTG University of Pennsylvania 8/3/ Example: ReadCuffData Translation of EFSMs is mostly mechanical Mode transition graphs correspond to EFSMs Additional details are needed to provide complete specifications

SDRL & RTG University of Pennsylvania 8/3/ SCR* analysis SCR provides a number of consistency and completeness checks In this example, same event is used to trigger two transitions in ReadCuffData

SDRL & RTG University of Pennsylvania 8/3/ SCR* analysis Using SCR* has forced us to disambiguate many details that were not explicitly defined in the EFSMs Several inconsistencies were identified, mostly in EFSMs, but also in the requirements: If corroboration fails, two additional readings should be made. Req specifies what to do if both of these readings are within 10% of the cuff reading, or both are not. –It does not seem to be specified what to do if one is within 10% and the other is not.

SDRL & RTG University of Pennsylvania 8/3/ Conclusions Pass 1: –Obtained a working knowledge of CARA requirements –Constructed a more precise and structured requirements specification Pass 2: –Construct a formal requirements specification –Perform consistency analysis We are preparing a list of additional questions to the CARA team based on the SCR* modeling effort

SDRL & RTG University of Pennsylvania 8/3/ Discussion What we provide: –EFSMs as a reference model to facilitate coordination between groups –SCR* models and analysis results What we need: –Identify the properties –Better understanding of the fault model