Designtime and Runtime Assurance

1
Design-time and Run-time Assurance

• Insup Lee
• Department of Computer and Information Science
• University of Pennsylvania
• Philadelphia, PA

2
People

• Dr. Funda Ergun (Bell Labs)
• Prof. Sampath Kannan
• Moonjoo Kim
• Hee Hwan Kwak
• Prof. Insup Lee
• Dr. Anna Philippou (University of Cyprus)
• Insik Shin
• Dr. Oleg Sokolsky
• Mahesh Viswanathan

3
Run-time Monitoring and Checking(MaC)
4
Motivation and Objective

• Specification and verification
• complete analysis, all behaviors are correct
• gap between specification and implementation
• Testing
• tested behaviors are correct
• not complete
• Monitoring and checking (MaC)
• ensure the current behavior is correct
• consistency between abstract model and
  implementation
• provide a framework for automatic generation of
  monitors and checkers

5
Fundamental Issues

• How does a monitor gather information from a
  running system?
• How does the monitor relate to requirements?
• How do we integrate dynamic monitoring with
  static analysis?
• Can monitor be used to steer a system?
• What mathematical guarantees do monitors provide?

6
MaC Architecture
System Spec
Requirement Spec
Formal verification
Design
7
Design issues

• Filter
• what, how and when to instrument
• distributed monitoring
• overheads
• Event recognizer
• mapping between concrete state and abstract event
• Checker
• safety properties, security properties, timing,
  resource use, QoS
• local versus global checking
• computation
• Corrector
• how to provide feedback
• steering to safe states

8
MaC Prototype
Requirement Specification
Program (Java source code)
Requirements (MEDL)
Monitoring Script (PEDL)
Program (Java byte code)
MEDL Compiler
PEDL Compiler
Instrumentation Information
Filter Generator (JTREK)
Instrumented
Code
Event Recognizer
Run-time Checker
9
Primitive Event Definition Language

• The language maps the low-level state information
  of the system to high-level events used in
  describing the requirements.
• Information about the system comes in two
  different forms
• Conditions, which are true or false for a finite
  duration of time (e.g., is variable x gt5?), and
• Events, which are either present or absent at
  some instant of time (e.g., is the control right
  now at the end of method f?).

10
PEDL Features

• Provides primitives to refer to values of
  variables and to certain points in the execution
  of the program.
• condition in_crossing (train_position lt 10)
• event inCS start_m(critical_method)
• Enables one to write expressions comparing the
  return value of a method invocation with its call
  arguments.
• event correct (value(io_m(mult),1)
• (value(io_m(mult),2)value(io_m(m
  ult),3)))
• Allows the user to invoke methods of the system
  in the event recognizer for the purposes of
  program checking.
• condition check (mult(A, Brand_vect)
  A(Brand_vect))

11
Meta-Event Definition Language

• Language used express the requirements of the
  system, in terms of the events and conditions
  recognized by the event recognizer.
• Has similar notions of events and conditions, but
  is more expressive than PEDL.
• Unlike PEDL, it has constructs that help reason
  about the whole execution seen so far.

12
MEDL Features

• Describes the safety requirements of the system,
  in terms of conditions that must always be true,
  and alarms (events) that must never be raised.
• safeprop even (x2 0)
• alarm accident (enter_crossing) (gate_up)
• Has primitives to manipulate auxiliary variables
  that may be used to record some aspects of the
  execution seen thus far.
• request_info -gt num_hits

13
Demo Railroad crossing
System Violation
RRC
Filter
Event Recognizer
Checker
14
Integration within the MaC framework

• Proxy server developed at Stanford University
• mobile code, java applets
• Suite of checkers developed at Cornell University
• computations such as matrix multiplication,
  longest common substring, depth first search,
  FFT, etc.

15
The Specification and Analysis of Real-Time
Systems
16
Motivation

• Correctness and reliability of real-time systems
  depends on
• Functional correctness
• Temporal correctness
• Failures
• Factors that affect temporal behavior
• Synchronization and communication
• Resource requirements
• Availability of resources and scheduling
• An integrated framework to bridge the gap between
  concurrency theory and real-time scheduling

17
Objectives

• Development of Design Formalism for Distributed
  Real-time Systems
• Process-Algebra-Based Formalisms
• Executable Specifications
• Logics for Specifying Properties
• Design of Analysis Techniques
• Automated Verification Techniques
• Parameterized End-to-end Schedulability Analysis
• Tool Implementation
• Graphical Textual User Interface

18
Specification and analysis

• ACSR (Algebra of Communicating Shared Resource)
• A real-time process algebra which features
  discrete time, resources and priorities
• Timeouts, interrupts and exception handling
• Graphical ACSR
• PACSR (Probabilistic ACSR)
• ACSR-VP (Value Passing)
• Hierarchical specification and analysis
• Tools PARAGON, VERSA
• Analysis techniques - state space exploration,
  (symbolic) bisimulation, abstract interpretation,
  model checking
• Applications safety, timing constraints,
  schedulability analysis, end-to-end design
  support, etc.

19
Probabilistic ACSR (PACSR)

• It has two types of actions
• instantaneous events
• timed actions
• PACSR supports probabilistic failure of resource
• Probabilistic information is defined separately
  to the specification and is only used during
  analysis
• Reachability analysis, model checking

20
Examples
A Scheduler
A Faulty Channel
where pr(channel) 0.99.
21
Æ
(FCh, Æ)
p
p
p
in
p
Æ
(P, Æ)
0.99
0.01
Æ
p
22
A telecommunication example

• Two versions of the system
• S1 possibility of 1 alarm per time unit, buffer
  size of 3, capability of
• processing 2 alarms per time unit
• S2 possibility of 2 alarms per time unit,
  buffer size of 6, capability of
• processing 4 alarms per time unit

23
Analysis results -
24
ACSR-VP

• ACSR with data variables and value passing
• Provide the general frame for the analysis of
  real-time scheduling problems with
• variable release and execution times
• relative timing constraints
• dynamic priorities
• multiprocessor etc.
• Based on ACSR-VP and symbolic bisimulation
  algorithm.

25
Overall Approach
System Described with ACSR-VP
Symbolic Weak Bisimulation
Predicate Equations with Free Variables
Linear/Integer Programming
Constraint Logic Programming
Theorem Prover
Solution Space (Ranges of Free Variables)
26
Real-time System Design Problems

• Schedulability Analysis
• verify that a system is schedulable, given a
  certain priority assignment method and execution
  synchronization method
• Priority Assignment
• assign priorities to jobs so that the system
  schedulability is maximized
• Execution Synchronization
• decide when to release jobs so that the
  precedence constraints are satisfied

27
Example of execution synchronization
? 25
? 14
? 10
? 12
5,7
3,4
Job1
Job2
s1
s1e1
s2
s2e2
28
Predicate Equations
By symbolic weak bisimulation with infinite idle
process, the following set of predicate equations
is generated.
29
Solution Space
? The solutions for predicate equations can be
obtained in various ways, linear/integer
programming techniques or constraint logic
programming techniques or theorem prover. ?
Following table shows the solution for previous
example.
30
Current and future work

• Tool support for ACSR-VP
• How to construct an ACSR-VP specification for a
  given scheduling problem?
• Develop a general methodology of automated
  construction of the ACSR-VP specification of
  scheduling problems.
• Develop and maintain a library of reusable
  template specifications for common scheduling
  algorithms and system configurations.
  General-purpose and domain-specific templates can
  be used.