1 / 18

Formalization of CARA system requirements

This article discusses the formalization process of CARA system requirements, including understanding requirements, translating them into SCR*, and analyzing consistency and completeness. The progress to date is also presented.

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

More Related