Formal methods for CARA development

1
Formal methods for CARA development

• Insup Lee (Univ. of Pennsylvania)
• Rance Cleaveland (SUNY at Stony Brook)
• Elsa Gunter (NJIT)

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

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

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

5
Development Process
Requirements

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

Design specification
Implementation
6
Ideal Requirement Capture Process
Informal requirements
Restricted NL Translator
Formal requirements
Requirement Analyzer
Analysis results
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

8
Top Level View of System
CARA resuscitation unit
Saline
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

Environment
System
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)

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.

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)

13
CARA Resuscitation Unit - Components
Pump
Propaq
CARA
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

15
How to generate design specifications?

• By (informal) refinement of requirements
  specification
• Constructing from scratch based on requirements
• By extracting models from implementation

16
Design Specification and Analysis
System specification
abstraction
Analysis
Formal model
Properties
formalization
Requirements
17
Implementation Validation
Requirements
Test generator
Specifications
Test suite
Implementation
Test executor
Test results
18
Other issues

• Maintenance
• Documentation
• Traceability
• Dealing non-functional aspects such as resource
  constraints
• Code generation