Understanding Temporal Logic for Modeling Dynamic Systems

1. Temporal logic

2. Temporal logic • So far we used logic to model and reason about static situations. • Examples: • Are there truth values that can be assigned to x,ysimultaneously that satisfy x Ç:y ? • Is the following valid: 8n 2N.9p 2N. ((n >1 Æ isprime(p)) ! n < p < 2n) • To reason about programs, we need dynamics!

3. Need dynamics • State = an assignment • Formula = a set of states • i.e., the set of assignments that satisfy it. • What we need is a sequence of states. • possibly an infinite sequence for reactive systems. • Each such sequence is called a behavior, or a computation.

4. Need dynamics • Once we model our system M, we need to specify it. • Need temporal logic to specify required behavior over time. Let  be such a formula. • We will ask whether the following holds: M ² i.e., do all behaviors of M satisfy the property .

5. History of Temporal Logic • Designed by philosophers to study the way that time is used in natural language arguments • Brought to Computer Science by Amir Pnueli in 1977. • Has proved to be useful for specification of concurrent reactive systems

6. Linear Temporal Logic (LTL) • In LTL time is • implicit, • discrete, • has an initial moment with no predecessors, and • infinite in the future • The model of LTL formula is infinite sequence of states : s0, s1, s2, …

7. LTL: Syntax • Elements: • Atomic propositions • Boolean operators¬ • Temporal operatorsG F X U R  := () |¬| Æ Ç UR|GF|X| p

8. LTL: Syntax  := () | ¬ |  Æ ÇUWG F |X  | p G Always( = “Henceforth ”) FEventually(= “ in the future”) X“next-time” U“ until” R“Release”

9. Semantic Intuition f f f f f f f r r r f f f f f f r r r r r r r,f r • G f - always f • F f –eventually f • X f –next state • f U r– until • f R r– releases

10. Semantic • Semantic is given with respect to paths • = s0 s1 s2… • Suffix of trace starting at si • i = si si+1 si+2… • A system satisfies an LTL formulaif each path through the system satisfies .

11. Semantic (cont’d) • k²a iff a sk • k² iff not k² • k²   iff k² and k² • k²   iff k² or k² • k²X  iffk+1² • k²F iff exists i  ki² • k²G ifffor all i  ki² • k² U  iff exists i  ki² and for all k  j < i. j² • k² R  iff for all j  k, if for every k· i < j noti² then j²

12. LTL Identities • Write G with F: G = F • Write F with U: F = (trueU ) • Write R with U:  R  = ( U ) • Every LTL formula can be rewritten using only operators   X U

13. Combinations • GF p • “p will happen infinitely often” • FG p • “p will happen from some point forever”. • (GF p) ! (GF q) • “If p happens infinitely often, then q also happens infinitely often”. (Now: Examples of specifying with LTL )

14. Limitations of LTL • Is there a temporal behavior that we cannot express with LTL ? • Property: “p holds in every even state” • Unexpressible in LTL. • There are extensions to LTL that solve these type of problems. We will not learn them.

15. Two classes of properties • Safety properties: nothing ‘bad’ will happen. • A counterexample is a finite loop-free sequence of states. • Example: G(p → X q) Initial state Bad state p p,q

16. Two classes of properties • Liveness properties: something ‘good’ will happen. • A counterexample is an infinite trace, showing that this good thing NEVER happens. • In a finite state model, this is represented as a finite sequence of states ending with a loop. • Example: F p Initial state :p :p :p :p :p :p

17. A Spring Example release s1 s2 s3 pull release S3 S2 0 = s1 s2 s1 s2 s1 s2 s1 … 1 = s1 s2 s3 s3 s3 s3 s3 … 2 = s1 s2 s1 s2 s3 s3 s3 … …

18. LTL satisfaction by a single sequence release s1 s2 s3 pull release 2 = s1 s2 s1 s2 s3 s3 s3 … 2²S2 ?? 2² X S2 ?? 2² XX S2 ?? 2²FS2 ?? 2²GS2 ?? 2²FGS2 ?? 2²FGS3 ?? 2²¬FGS2 ?? 2² (¬S2) U S3 ?? 2²G(¬S2! X S2) ??

19. LTL satisfaction by a system release s1 s2 s3 pull release A: A ²FGS2 ?? A ²FGS3 ?? A ² ¬FGS2 ?? A ² (¬S2) U S3 ?? A ²G(¬S2! X S2) ?? A ²S2 ?? A ² X S2 ?? A ² XX S2 ?? A ²FS2 ?? A ²GS2 ??

20. The problem of vacuity • Consider the following property : G(request  F ack) ... and a system M that never sends requests. • The property is satisfied: M ² • Is it ok ? • This can indicate a bug in M or in the property.

21. The problem of vacuity • Consider the following property : G(p U (p Ç q)) ... and a system M which satisfies Gq. • The property is satisfied: M ² • Is this what the user intended ? • A bug in the property? • Equivalent to G (p Ç q) • Otherwise change the property.

22. The problem of vacuity • When a formula passes not due to the ‘right’ reasons we might be fooling ourselves that everything is ok. • Is there a way to check for such errors ?

23. The problem of vacuity • Let  be an LTL formula in negation normal form. •  is said to be vacuous in M if there exists an occurrence of an atom a2 AP() such that M ²[aà false] • (or M ²[aà true] if a appears negatively). • We check vacuity only after we know that M ²

24. The problem of vacuity • Example 1: : G(request  F ack) • Check 1: G(true  F ack) • Suppose that M ²1 • Either: • This contradicts the user’s understanding of M. There is a bug in M. • This was the intention. So change  to the stronger formula GF ack.

25. The problem of vacuity • Example 1: : G(request  F ack) • Check 2: G(request  F false) • Suppose that M ²2 • Either: • This contradicts the user’s understanding of M. There is a bug in M. • This was the intention. So change  to the stronger formula G :request.

26. The problem of vacuity • Example 2: : G(p U (p Ç q)) • Check 1: G(false U (p Ç q)) • For all M, if M ² then M ²2. • Hopefully the user will realize that it should be G(p Ç q).

27. The problem of vacuity • Example 2: : G(p U (p Ç q)) • Check 2: G(p U (false Ç q)) • If M ²2 then there is no path satisfying G(p Æ:q) • Error in the model ? • Should we change the property to 2?

28. The problem of vacuity • Example 2: : G(p U (p Ç q)) • Check 3: G(p U (p Ç false)) • If M ²3 then M ²Gp • Error in the model ? • Should we change the property to 3?

29. Mutual vacuity ab ac • Consider  = G(a Ç b Ç c) • .. and M: • M ² G(b Ç c) // nothing else to remove • M ² G(a Ç b) // can still remove b M ² G(a) • Conclusion: order of vacuity-checks matters!

30. Mutual vacuity • The mutual vacuity problem: what is the largest number of literal ocurrences that can be replaced with false simultanuously without falsifying M in  ? • Formally: find largest S µ lit-occur() such that M ²[a à false | a 2 S]

31. Vacuity checks in the industry • Most commercial model-checkers check for vacuity automatically • Typically only a few ‘important checks’, not all possible. • Too expansive in practice to check for mutual vacuity.

32. Representing Concurrent Systems • The ‘spring’ system is an example of a ‘Kripke structure’ • Kripke structure: a tuple M = (S, S0, R, L), where • S– set of all states of the system • S0– set of initial states • R– transition relation between states • L– a function that associates each state with set of propositions true in that state

33. Kripke Model • Set of states S • {q1,q2,q3} • Set of initial states S0 • {q1} • Set of atomic propositions AP • {a,b} q1 a a,b b q2 q3

34. What’s next ? • A Kripke structure is a special variant of an automaton. • Next, we will learn about automata.