formalization of cara system requirements n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Formalization of CARA system requirements PowerPoint Presentation
Download Presentation
Formalization of CARA system requirements

Loading in 2 Seconds...

play fullscreen
1 / 18
jovan

Formalization of CARA system requirements - PowerPoint PPT Presentation

0 Views
Download Presentation
Formalization of CARA system requirements
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. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Formalization of CARA system requirements Oleg Sokolsky Department of Computer and Information Science University of Pennsylvania

  2. 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)

  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: …

  4. 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

  5. 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)

  6. 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.

  7. 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).

  8. Overall System • Pump • The hardware • Cara system • The software • Environment • The user • Patient • The object

  9. Overall System Structure Environment • Pump status • Current mode • BP value • BP source • Flow rate • Infused volume • Messages • Dialog boxes • h/w flow setting • Air alarm • Occ alarm • dialog box buttons • AirOK • OccOK • Back EMF • Pump Wires Pump Hardware CARA System • control voltage • #2 (SysGRD) • #6 (Ext_Speed_control) infused fluid BP signals

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

  11. 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

  12. Example: ReadCuffData SampleCuff==0 && source==cuff && CRTimer!=CuffFreq Wait to do a cuff reading source != cuff  SampleCuff:=0 CRTimer:=0 Read cuff data into var. Cuffdat Check data ValidCuffData First check failed ValidCuffData InvalidCuffData  CuffNotValid2:=1 CuffLostSource:=1 source != cuff End of check source == cuff Set frequency

  13. Pass 2: Detailed formalization • Translate EFSMs into tabular notation using SCR* toolset

  14. Example: ReadCuffData • Translation of EFSMs is mostly mechanical • Mode transition graphs correspond to EFSMs • Additional details are needed to provide complete specifications

  15. SCR* analysis • SCR provides a number of consistency and completeness checks • In this example, same event is used to trigger two transitions in ReadCuffData

  16. 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. 20.3 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.

  17. 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

  18. 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