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

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

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

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

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

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

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

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.

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

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

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

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

Substitutivity Theorem II A2 A2 B2 B2 If A1 A2 B2 B1 A2 B2 then, A1 B1

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,

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)…

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.

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

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)

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

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.

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:

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

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]

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.

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

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)

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 α*

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

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

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.

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.

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.

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)

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