1. Modeling and Analysis of Complex Computational Systems
Nancy Lynch, Dilsun Kaynar, Sayan Mitra
MIT
UIUC, MIT, Stanford MURI: 2-Year Review
June 11, 2004
Sponsored by DDR&E and DARPA/AFOSR
Program managers Lt Col Sharon Heise and Dr Belinda King

2. Research Areas Lynch Liberzon Lynch Mitchell Viswanathan Control &
Formal techniques for stability analysis of complex systems
Control &
Information
Theory
Computing &
Verification
Formal frameworks for modeling and analysis
Languages and tools
for specification, simulation, and proofs
Robotic
Vehicles
Lynch
Mitchell
Viswanathan
Communications

3. Project Goals
Develop formal frameworks for modeling and reasoning about complex behavior in distributed systems
Timing-dependent behavior
Hybrid continuous/discrete behavior
Probabilistic behavior
Combinations of these kinds of behavior
Build language and tool support for our formal models
Extensions of the IOA language
Extensions of simulation and verification tools in the IOA toolkit

4. I/O Automata Mathematical, infinite-state, automaton models
Describe states, transitions
Describe system modularity:
Parallel composition of interacting components
Levels of abstraction
Example: Generic distributed system
Diagram represents interfaces
IOA models also describe behavior
Abstract models for system components
Channel: Implemented by TCP, modeled as reliable FIFO queue
Node: Implemented by C++ program, modeled as algorithm automaton

5. Flavors of I/O Automaton Models
Basic IOAs deal with:
What happens, in what order (not when)
Discrete events (not continuous behavior)
Timing: TIOA
For describing timeout-based algorithms
Local clocks, clock synchronization
Timing/performance analysis
Hybrid (continuous/discrete): HIOA
Systems with real world + computer components
Vehicle control (ground, air, space), embedded systems
Probabilistic: PIOA, PTIOA, PHIOA
Randomized distributed algorithms
Security protocols
Safety-critical systems

6. Talk Outline Introduction TIOA HIOA PIOA Conclusions
New composition results (Segala, Vaandrager)
Language and tool design (Archer, Shvartsman)
HIOA
Stability analysis (Liberzon)
PIOA
New composition results (Cheung, Segala,Vaandrager)
Applications to security protocols (Mitchell)
Conclusions

7. New composition results and language and tool design
2. Timed I/O Automata
New composition results and language and tool design

8. Timed I/O Automata X: internal variables
Q: states, a set of valuations of X
: start states
A = I  O  H: input, output, internal actions
D  Q  A  Q: discrete transitions
T: trajectories for X, in which the valuations of X are in Q. Closed under prefix, suffix, and countable concatenation.

9. Executions and Traces Execution fragment: Execution: Trace:
Hybrid sequence 0 a1 1 a2 2 …, where:
Each i is a trajectory of the automaton, and
Each (i.lstate, ai , i+1.fstate) is a discrete step
Execution:
Execution fragment beginning in a start state.
Trace:
Restrict to external actions and empty set of variables
A implements B if they have the same set of external actions and traces(A)  traces(B).

10. Composition
Assume A1 and A2 are compatible (internal actions are private). Then, A = A1 || A2 is the following automaton:
X = X1  X2
States Q: Projections in Q1, Q2
I = (I1  I2) – (O1  O2) , O= (O1  O2)
Start states, discrete steps, trajectories: Projections
Projection/pasting theorem:
If A = A1 || A2 then traces(A) is the set of hybrid sequences (of the right type) whose restrictions to A1 and A2 are traces of A1 and A2, resp.
Substitutivity theorems:
Basic: No assumptions about the environment or context of components
More complex: Assume-guarantee style results

11. Substitutivity Theorem I [KLSV1-04][FTRTFT-04]A2 A2 B
then If A1 A1 B
A1 implements A2 in all environments..nice and simple
Has a nice corollary that allows decomposing proofs into more manageable pieces

12. But it is not always possible or easy to do this without
In order to prove A1 B1 A2 B2
It suffices to prove
it is not easy to show that A1 implements A2 in all environments, or B1 implements B2 in all environments. Therefore we have to impose some conditions on the envoronments we are looking at: assume guarantee type results. A1 B1
But it is not always possible or easy to do this without
using assumptions about how the environment behaves

13. Substitutivity Theorem IIA2 A2 B2 B2 If A1 A2 B2 B1 A2 B2
then, A1 B1

14. A new theorem that allows decomposition of proofs:B3 B3 A3 If A2 B3 B1 B2 A3 A1 B3 A3 A2 A1 B2 B1
then,

15. Example A1 and A2 Signature: input b, output a
Takes any number of consecutive inputs
Produces a single output in response to a sequence of inputs
A1: the newest input determines time of next output.
A2: the oldest input determines when the next output will occur
Sample trace A1: (a, t) (b, t1) (b, t2) (a, t2+1) (b,t3)…
Sample trace A2: (a, t) (b, t1) (b, t2) (a, t1+1) (b,t3)…
B1 and B2 behave similarly to, resp., A1 and A2, except that
Signature: input a, output b
A1 || B1 and A2 || B2 alternate a and b actions.
Sample trace: (a, t) (b, t+1) (a, t+2) (b, t+3) (a,t+4)…

16. Example
We cannot prove that A1 implements A2 and B1 implements B2 without any assumptions about their environment.
However, A1 implements A2 if the automata are put in an environment that imposes strict alternation. Similarly for B1 and B2.
Use an auxiliary automaton A3, which captures what is essential for the implementation relation.
A3: timing-independent, imposes strict alternation.
Use an auxiliary automaton B3, which captures what is essential for the implementation relation.
B3: timing-independent, imposes strict alternation.
We can prove that A1 || B3 implements A2 || B3 and A3 || B1 implements
A3 || B2.

17. TIOA Modeling Language
Provides notation for describing timed I/O automata precisely
Extends IOA syntax
Continuous variables
Trajectory definitions describe state evolution
Differential and algebraic equations
Invariants
Stopping conditions
Semantics for syntax extensions
UPPAAL trans implemented FME experimentw

18. TIOA Tools Interactive theorem proving Simulation (planned)
TIOA to UPPAAL translator [Robson, MEng Thesis’04]
UPPAAL is a modeling tool for real-time systems with a fully automatic verifier
Facilitates automatic verification of a subset of TIOA
Experiments: timing based mutual exclusion, etc.
Interactive theorem proving
Abstraction proofs of TIOA in PVS [Mitra, Archer’04]
Translation TIOA PVS (planned)
Simulation (planned)

19. Stability Analysis: Formal Verification Approach
3. Hybrid I/O Automata
Stability Analysis: Formal Verification Approach
Collaboration with Daniel Liberzon, UIUC

20. HIOA: A Platform Bridging the Gap
Control Theory: Dynamical system with boolean variables
Stability
Controllability
Controller design
Computer Science: State transition systems with continuous dynamics
Safety verification
model checking
theorem proving
HIOA: math model specification
Expressive: few constraints on continuous and discrete behavior
Compositional: analyze complex systems by looking at parts
Structured: inductive verification
Compatible: application of CT results e.g. stability, synthesis
there has been quite a bit of work in the hybrid systems area over the last few years. the CT community looks at HS as ….
the CS community, with its experience and success in hardware verification based on state transition systems …
Our claim is that HIOA framework is indeed such a platform…HIOA it is a state transition based model but its expressive enough to allow the modelling of complex continuous behavior..in fact only a minimal set of constrains are imposed on what kind of continous behavior is allowed. And these constrained are necessary to get the other nice properties of the model like compositionality…i.e. …
inductive verification
and as we shall see momentarily with a concrete example, it allows us to use CT results.

21. Hybrid I/O Automata V= U  Y  X: input, output, internal variables
Q: states, a set of valuations of V
: start states
A = I  O  H: input, output, internal actions
D  Q  A  Q: discrete transitions
T: trajectories for V, in which the valuations of V are in Q. Closed under prefix, suffix, and countable concatenation.
Execution 0 a1 1 a2 2 …, beginning in a start state.
Trace: Restrict to external variables and actions
Invariant I(s) proved by base case :
induction discrete:
continuous:

22. HIOA Model for Switched Systems
Switched system abstracts away the discrete behavior and studies the properties of the continuous state: stability etc.
is a family of systems
is a switching signal
Switched system modeled as HIOA:
Each mode is modeled by a trajectory definition;
Mode switches are brought about by actions
Usual notions of stability apply
Stability theorems involving Common and Multiple Lyapunov functions carry over.
Our first step to wards using CT results in the HIOA framework was to find a map the different notions of stability in the HIOA domain, and also

23. Stability Under Slow Switchings
Lyapunov functions for each mode
Slow switching:
# of switches on
average dwell time (τa)
Background slide
Average dwell time vs. dwell time – allows to react to unpredictable circumstances
Mention Joao
Assuming Lyapunov functions for the individual modes exist, global asymptotic stability can be proved by showing that the τa is large enough. [HM1999]

24. Average Dwell Time
Average dwell time is a property of the executions of the automaton
Two approaches:
Transform the automaton A A’ so that the a.d.t property of A becomes an invariant property of A’.
Then use theorem proving or model checking tools to prove the invariant(s)
Use MILP to find an execution fragment that violates a.d.t.

25. Transformation for Uniform Stability Verification
Simple stability preserving transformation adds
counter Q, for number of extra mode switches,
Qmin for the smallest value of Q,and
a timer t. A A’
Theorem: A has average dwell time τa iff Q- Qmin ≤ N0 in all reachable states of A’. [ML’04]
invariant property

26. Average Dwell Time: MILP Approach
Congruence relation  partitions state space
Sufficient condition for violating a.d.t. τa:
Exists an execution fragment α = τ0a1…τn with
τ0.fstate  τn.lstate
N(α) > α.length / τa
This is also necessary condition for
Initialized HIOA
Linear non-initialized HIOA (In progress)

27. MILP α* Maximize: N(α) – α.length / τa
subject to: α = τ0a1…τn is an execution fragment of A
τ0.fstate  τn.lstate
If N(α*) ≤ α*.length / τa then A has a.d.t τa otherwise it does not.
Example: Leaking gas-burner automaton
gas burner HIOA
region automaton α*

28. 4. Probabilistic I/O Automata
New composition results and applications to security protocols

29. Probabilistic I/O Automata
Differ from basic I/O automata:
Transitions: (s, a, P), where P is a probability distribution on states.
Include both nondeterministic and probabilistic choices.
Challenge: Define external behavior and composition for PIOAs, so that the implementation relation is preserved by composition:
If A1 implements A2, then A1 || B implements A2 || B .
Previous work [Segala 95]
Scheduler: Resolves all nondeterministic choices.
External behavior represented by a set of trace distributions, one per scheduler.
Possible implementation relation: A1 D A2
Every trace distribution of A1 is a trace distribution of A2.
But this is not preserved by composition.
So, defined implementation relation DC to be the coarsest relation included in D that preserves composition

30. Characterization of the relation DC [Lynch, Segala, Vaandrager 03, 04]
For nondeterministic automata:
A1 DC A2 i f and only if there exists an ordinary simulation relation from A1 to A2.
For probabilistic automata:
A1  DC A2 if and only if there exists a probabilistic simulation relation from A1 to A2.
Relates states of A1 to distributions over states of A2.
Transitions preserve probabilities.
First completeness results for simulation relations.
Probabilistic contexts can observe all distinctions expressed by simulation relations.
Exposes all internal choices, both nondeterministic and probabilistic.
Scheduler has too much information:
Can base decisions on internal choices of composed automata.
Idea: Restrict schedulers so that:
They use less information: External information only.
So, they generate fewer trace distributions.
The resulting trace distribution ordering is preserved by composition.

31. PIOA with Restricted Schedulers [Ling, Lynch, Segala, Vaandrager, in progress]
Scheduler consists of pieces:
An I/O scheduler for each component.
Resolves nondeterministic choices within that component.
An arbiter.
Resolves which component gets the next turn.
Obtain pasting, projection, substitutivity results.

32. Applications to Security Protocols [In progress]
Formalize security protocols using PIOAs.
Formulate security properties as sets of trace distributions.
Ignore “negligible probability events”:
E.g., guessing a key.
Include “interesting probability events”:
E.g., Oblivious Transfer:
Probability ½ of transferring a value.
Probability ½ of guessing correctly whether value has been successfully transferred.
Prove that a protocol satisfies its properties:
Use abstract service specification PIOA.
Invariants.
Probabilistic simulations.

33. Conclusions and Future Work
Timed systems
Composition results that decompose abstraction proofs into smaller pieces.
Language design for TIOA
Translator to UPPAAL
Abstraction proofs in PVS
Automatic translation of TIOA to PVS
TIOA Language implementation and Simulator
Hybrid systems
Stability analysis of HIOA under slow switching
Invariant approach using formal verification techniques
MILP approach for constant rate HIOA
Application of analysis techniques in mobile systems
Tools for automatic verification of average dwell time property
Probabilistic systems
New composition results
Applications to security protocols (Mitchell)

34. Future Work HIOA Incorporate other control theory methods
Invariant sets, robust control.
Implement proposed extensions to IOA
Test proof tools on more examples
TIOA
Language implementation, and simulation and verification tools
PIOA
Restrict the set of schedulers so that fewer distinctions are observable by probabilistic contexts
Obtain a characterization of the resulting new notions of trace distribution precongruence
Applications
Aero/astro applications, sensor networks etc.
Security protocols