Download presentation

Presentation is loading. Please wait.

Published byRandolph Marshall Modified over 4 years ago

1
CIS 540 Principles of Embedded Computation Spring 2015 http://www.seas.upenn.edu/~cis540/ Instructor: Rajeev Alur alur@cis.upenn.edu

2
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

3
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

4
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

5
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

6
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

7
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

8
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

9
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

10
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

11
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

12
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

13
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

14
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

15
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

16
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

17
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

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

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

Similar presentations

© 2020 SlidePlayer.com Inc.

All rights reserved.

To make this website work, we log user data and share it with processors. To use this website, you must agree to our Privacy Policy, including cookie policy.

Ads by Google