CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur

LTL Recap  Syntax: Formulas built from  Base formulas: Boolean-valued expressions over typed variables  Logical connectives: AND, OR, NOT, IMPLIES …  Temporal Operators: Always, Eventually, Next, Until  LTL formula is evaluated w.r.t. a trace  (infinite seq of valuations)  Semantics defined by rules for the satisfaction relation  A system satisfies LTL spec  if every infinite execution satisfies   Derived operators  Repeatedly (Always Eventually); Persistently (Eventually Always)  Sample requirement: Every req is eventually granted Always [ req=1  Eventually ( grant=1) ] CIS 540 Spring 2015; Lecture March 18

Temporal Implications and Equivalences  Understanding subtle differences among different variants of LTL formulas can be tricky  Formula  is stronger than the formula  : whenever a trace satisfies , it is guaranteed to satisfy   Every trace satisfies the implication     Formula  is equivalent to the formula  : a trace satisfies  if and only if it satisfies   Two formulas express exactly the same requirement  Knowing some standard equivalences can be useful for simplifying formulas CIS 540 Spring 2015; Lecture March 18

Temporal Implications and Equivalences  Always  is stronger than   Repeatedly  is equivalent to ~ Persistently ~   Persistently  is stronger than Repeatedly   Always  is equivalent to [  & Next Always  ]  What’s the relationship between  Always Eventually   Next Always Eventually   Eventually Always Eventually  CIS 540 Spring 2015; Lecture March 18

Logical Connectives and Temporal Operators  Are these equivalent? Eventually (  |  ) and Eventually  | Eventually  [Proof in one direction]. Suppose a trace  satisfies Eventually (  |  )  There exists a position j such that ( , j) |=  |   Either ( , j) |=  or ( , j) |=   Suppose ( , j) |=  (the other case is similar)  Then  satisfies Eventually   Hence also satisfies Eventually  | Eventually  [Proof of converse]. Suppose trace  satisfies Eventually  | Eventually   Suppose it satisfies Eventually  (the other case is similar)  There exists a position j such that ( , j) |=   Then, it also is the case that ( , j) |=  |   It follows that  satisfies Eventually (  |  ) CIS 540 Spring 2015; Lecture March 18

Logical Connectives and Temporal Operators  Are these equivalent? Eventually (  &  ) and Eventually  & Eventually  [Proof in one direction]. The first is stronger than the second  Suppose a trace  satisfies Eventually (  &  )  There exists a position j such that ( , j) |=  &   It follows that both ( , j) |=  and ( , j) |=   Since ( , j) |=  it also satisfies Eventually   Similarly it also satisfies Eventually   It follows that the trace satisfies Eventually  & Eventually  [Disprove the converse]. But the two are not equivalent!  Consider trace 0,1,0,1,0,1,… over a boolean variable x  It satisfies Eventually(x=0) & Eventually(x=1)  But does not satisfy Eventually (x=0 & x=1) CIS 540 Spring 2015; Lecture March 18

Logical Connectives and Temporal Operators  Distributivity rules for logical connectives and temporal operators  Are these equivalent?  Always (  &  ) and Always  & Always   Always (  |  ) and Always  | Always    Repeatedly (  &  ) and Repeatedly  & Repeatedly    Repeatedly (  |  ) and Repeatedly  | Repeatedly  CIS 540 Spring 2015; Lecture March 18

Back to Fairness  What fairness assumptions are needed so that P satisfies the spec  Eventually ( x >= 10) : weak-fairness for A  Eventually ( y = 1) : strong-fairness for B  Fairness can be encoded directly in LTL  Instead of checking whether the system satisfies an LTL-formula , check if the system satisfies the formula FairnessAssumption    FairnessAssumption is an LTL formula that encodes the meaning of what it means for an infinite execution to be weak/strong fair with respect to different tasks nat x:=0; bool y:=0 A: x := x+1 B: even(x)  y := 1-y Process P CIS 540 Spring 2015; Lecture March 18

Encoding Weak Fairness in LTL  To encode fairness assumption, let us add a variable called taken whose values are task names, and whenever a task executes, taken is assigned the name of the task  Weak-fairness for a task  Persistently enabled  Repeatedly taken  Alternatively: Always [ enabled  eventually ( taken | ~ enabled) ]  An infinite execution is weakly-fair to task A if it satisfies wf(A): Repeatedly(taken=A)  An infinite execution is weakly-fair to task B if it satisfies wf(B): Persistently(even(x))  Repeatedly (taken =B) nat x:=0; bool y:=0; A: x := x+1; B: even(x)  y := 1-y; Process P {A,B} taken taken := A taken := B CIS 540 Spring 2015; Lecture March 18

Checking Requirements under Weak Fairness in LTL  Does P satisfy Eventually (x >= 10) ?  Does P satisfy wf(A)  Eventually (x >= 10) ?  Does P satisfy wf(B)  Eventually (y=1) ?  Does P satisfy (wf(A) & wf(B) )  Eventually(y=1) ?  What have we achieved?  The problem of checking whether a LTL-spec is satisfied under fairness assumptions is reduced to checking a modified LTL-spec, so verification procedure does not have to worry about handling fairness) nat x:=0; bool y:=0; A: x := x+1; B: even(x)  y := 1-y; Process P {A,B} taken taken := A taken := B CIS 540 Spring 2015; Lecture March 18

Encoding Strong Fairness in LTL  Strong-fairness for a task  Repeatedly enabled  Repeatedly taken  An infinite execution is weakly-fair to task B if it satisfies sf(B): Repeatedly (even(x))  Repeatedly(taken=B)  Observe that the formula sf(B) is stronger than wf(B): if a spec is satisfied assuming weak-fairness, it also holds under strong-fairness  Does P satisfy sf(B)  Eventually (y=1) ?  Does P satisfy sf(B)  Repeatedly (y=1) ?  Does P satisfy sf(B)  Persistently (y=1) ? nat x:=0; bool y:=0; A: x := x+1; B: even(x)  y := 1-y; Process P {A,B} taken taken := A taken := B CIS 540 Spring 2015; Lecture March 18

Model Checking System Model LTL Requirement yes no/bug Model Checker  Performed using enumerative or symbolic search through the state- space of the program  Success story for transitioning academic research to industrial practice  2007 Turing Award to Ed Clarke, Alan Emerson, and Joseph Sifakis  Used to debug multicore protocols, pipelined processors, device driver code, distributed algorithms in Intel, Microsoft, IBM … CIS 540 Spring 2015; Lecture March 18

Buchi Automata  A safety monitor classifies finite executions into good and bad  Verification of safety requirements is done by analyzing reachable states of the system composed with the monitor  Bug: An execution that drives the monitor into an error state  How can a monitor (also called an automaton) classify “infinite” executions into good and bad?  Theoretical model of Buchi automata proposed by Richard Buchi (1960)  Model checking application (1990s) using Buchi automata  Automatically translate LTL formula  to a Buchi monitor M  Consider the composition of system C and monitor M  Reachable cycles in this composite correspond to counter-examples (if no such cycle is found, system satisfies spec)  Implemented in many model checkers including SPIN CIS 540 Spring 2015; Lecture March 18

Buchi Automaton: Example 1 a ~e e  Inputs: boolean variable e  Of two states a and b, a is initial and b is accepting  Given a trace  over e (i.e. infinite sequence of 0/1 values to e), there is a corresponding execution of M  The trace  is accepted if accepting state appears repeatedly  Language of M = Set of traces in which e is satisfied repeatedly  M accepts  iff  |= Repeatedly e ~e e b CIS 540 Spring 2015; Lecture March 18

Buchi Automaton: Example 2 a  Automaton is nondeterministic: as long as it is in state a, at each step it can either stay in state a, or switch to state b  On a given input trace, many possible executions  An execution is accepting if it visits accepting state repeatedly  M accepts an input trace if there exists some accepting execution on that input  M accepts  iff  |= Persistently e e b CIS 540 Spring 2015; Lecture March 18

Buchi Automaton: Example 3  Design a Buchi automaton such that M accepts  iff  |= Always [ e  Eventually f ]  Inputs: Boolean conditions e and f  In an accepting execution, every e must be followed by f b ~ e | f e & ~f f a ~ f CIS 540 Spring 2015; Lecture March 18

Buchi Automaton: Example 4 a e c b f Which traces does this accept? Express it in LTL M accepts  iff  |= Repeatedly e & Repeatedly f CIS 540 Spring 2015; Lecture March 18

Buchi Automaton M Definition  V: set of Boolean input variables  Finite set Q of states  Set Init of initial states  Set F of accepting states  Set of edges/transitions, where each edge is of the form q –Guard  q’ where Guard is a Boolean-valued condition over input vars V  Given an input trace  = v 1, v 2, v 3, … over V, an accepting run/execution of M over  is an infinite sequence of states q 0, q 1, q 2, … such that 1.State q 0 is initial 2.For each i, there exists an edge q i -Guard  q i+1 such that input v i satisfies Guard 3.There are infinitely many positions i such that state q i is in F  The automaton M accepts the input trace  if there exists an accepting run of M over  CIS 540 Spring 2015; Lecture March 18

Buchi Automata: More Examples e Eventually e ~ e e Eventually e CIS 540 Spring 2015; Lecture March 18