8/3/011 Formal methods for CARA development Insup Lee (Univ. of Pennsylvania) Rance Cleaveland (SUNY at Stony Brook) Elsa Gunter (NJIT)

SDRL & RTG University of Pennsylvania 8/3/01 2 CARA Case Study Thanks –… for giving us the opportunity to study CARA –… for sharing documents and providing domain expertise Our goals: –Study applicability of state-of-the-art formal techniques for development of safety critical embedded systems –Phase I: system modeling from requirements –Phase II: formulation and checking of properties on models General properties Specific safety properties (from requirements) –Phase III: implementation validation from models What we are not trying to do: –Develop a working system –Replace other existing efforts

SDRL & RTG University of Pennsylvania 8/3/01 3 Properties of high-confidence 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 8/3/01 4 Hoped-for outcome of CARA study Enriched methodologies for the development of reliable and robust CARA-like systems that incorporate formal modeling and analysis Requirement capture and analyzer, model checker, equivalence checker, test generator, etc. Evaluate the effectiveness of existing tools Development of domain specific framework and methodology

SDRL & RTG University of Pennsylvania 8/3/01 5 Development Process Requirements capture and analysis –Informal to formal –Consistency and completeness –Assumptions and interfaces between system components –Application-specific properties Design specifications and analysis –Formal modeling notations –Abstractions –Analysis techniques (simulation, model checking, equivalence checking, testing, etc.) Implementation –Manual/automatic code generation –Validation (testing, model extraction, etc.) Requirements Design specification Implementation

SDRL & RTG University of Pennsylvania 8/3/01 6 Ideal Requirement Capture Process Informal requirements Formal requirements Analysis results Requirement Analyzer Restricted NL Translator

SDRL & RTG University of Pennsylvania 8/3/01 7 Phases of Requirements Development Identify concepts and interfaces User Requirements System Specification World Knowledge Programming Platform Capture first using English, then formal languages such as (finite) state machines, process algebra, temporal logic, higher order logic

SDRL & RTG University of Pennsylvania 8/3/01 8 Top Level View of System CARA resuscitation unit Saline

SDRL & RTG University of Pennsylvania 8/3/01 9 Identify Interface Visibility – System, Environment Control – System, Environment Examples: –Infusate contents (saline/glucose/water): Environment controlled, System hidden –Infusate impedance: Environment controlled, System visible –Alarm for infusate impedance out of range: System controlled, Environment visible EnvironmentSystem

SDRL & RTG University of Pennsylvania 8/3/01 10 User Requirements Expressed only in terms of concepts visible to Environment Meaningful to end user, not programmer Example: –If a bag of pure water is attached to pump, within 10 seconds the pump will stop and an alarm will be sounded (for user) –Checking impedance (for programmer)

SDRL & RTG University of Pennsylvania 8/3/01 11 System specification Expressed only in terms of concepts visible to both Environment and System Meaningful to programmer, not to end user Implies User Requirements, when supplemented by World Knowledge Example: –If infusate impedance goes out of range, then within 10 seconds an alarm will be rung.

SDRL & RTG University of Pennsylvania 8/3/01 12 World (or Domain) Knowledge Expressed only in terms of concepts visible to Environment Bridges gap between User Requirements and System Specification Can be viewed as a specification of suitable environment for system Example: –Water has an impedance outside range for acceptable infusates (saline/glucose)

SDRL & RTG University of Pennsylvania 8/3/01 13 CARA Resuscitation Unit - Components Pump CARA Propaq

SDRL & RTG University of Pennsylvania 8/3/01 14 Programming Platform, or Machine Description of components used to construct the System Expressed only in terms of concepts visible to System Individual components may be viewed as systems themselves; other components are in there environment Examples: –Blood pressure monitor – Propaq, pump, display unit, resuscitation file (?), hardware for running algorithm

SDRL & RTG University of Pennsylvania 8/3/01 15 How to generate design specifications? By (informal) refinement of requirements specification Constructing from scratch based on requirements By extracting models from implementation

SDRL & RTG University of Pennsylvania 8/3/01 16 Formalism Design Specification and Analysis abstraction System specificatio n Requirement s formalization Formal model Properties Analysis abstraction 1 TCCS formalization 1 CTL* Model checking Formalism 1 abstraction 2 formalization 2 Timed automata CTL Model checking UPPAAL ACSR Monitors State-space exploration PARAGON abstraction 3 formalization 3

SDRL & RTG University of Pennsylvania 8/3/01 17 Implementation Validation Requirements Test generator Specifications Test suite Implementation Test results Test executor

SDRL & RTG University of Pennsylvania 8/3/01 18 Other issues Maintenance Documentation Traceability Dealing non-functional aspects such as resource constraints Code generation …