Temporal Logic

1. Temporal Logic Shmuel Katz The Technion Formal Specifications CS236368 Spring 2004

2. Liveness • Need to specify that the system actually progresses, without using real time • Methods so far say what is a legal transition, but not that they must be taken • Will use “temporal logic” to express which states must appear in an execution sequence (trace) of states • Widely used in spec. and verification

3. A Logic Over Sequences • For an individual state, use first order predicate calculus over the variables and other parts of the state • Temporal modalities = special symbols used to quantify over the states in a sequence. • (r, i ) |= P “P is true in the suffix of sequence r that starts in the i-th state” • If P has no modalities, it holds in that state

4. Defining |= • (r, i) |= P , no modalities in P, iff P(ri) is true • (r, i) |= ~P iff (r, i) |=/= P • (r, i) |= P v Q iff (r, i) |= P or (r, i) |= Q • (r, i) |= []P iff forall j. i £ j £ |r| .(r, j) |= P • “box P”, “from now on P”, “forever P”

5. More on Box • []P by itself is interpreted as (r, 0) |= []P • P holds from every state in r • If P has no modalities, []P means P is an invariant of the computation r • [] (x > 0 ) • [] ( ~ ( in( crit1 ) /\ in( crit2 ) ) ) mutual exclusion-- a safety property

6. Diamond • (r, i) |= <> P iff $ j. i £ j £ |r|. (r, j) |= P • “eventually”, “some time” • (r, 0) |= <> P holds in the initial state, if there is a later state where P holds • <> (x > 0 ) • <> ( at(halt1) /\ at(halt2) ) • liveness properties

7. Connections • Box and Diamond are dual <> P == ~ [] ~ P [] P == ~ <> ~ P ~ <> P == [] ~ P • Sometimes see G for [] F for <>

8. The future fragment • So far, the original future fragment of T.L., introduced to CS by Amir Pnueli • <> [] P eventually, always P starts being true • [] <> P always, eventually P is true (What does this mean?) • [] ( P => <> Q ) “always, P leads to Q”

9. P Until Q • Can we express “ P is true until Q holds” ? • (r, i ) |= P u Q iff $ k. i £ k £ |r|.( (r, k)|= Q /\" j.i £ j < k. (r, j)|= P) • Also have Weak version uw defined as P uw Q iff []P v ( P u Q) • [] ( “one-active” u “answer-received” )

10. Next • There is also a Next operator: (r, i) |= O P iff (r, i+1) |= P • Also written as XP • Adds to expressive power, but can make a specification less abstract and general. • Without “next” repeating states can’t be distinguished...called “eliminating stuttering” by Lamport

11. The Anchored Version • If we just write a temporal logic assertion, when does it have to be true of a sequence? • Anchored: in the initial state • Drifting: in any state (like regular logic) • Anchored seems preferred for specs. : [] anchored == drifting

12. Is the Future Enough? • Lamport: Yes Pnueli: maybe not • Past operators: • <-> ‘once’ • [-] ‘until now’, ‘so far’ • s ‘since’ (reflection of ‘until’) (r, i) |= P s Q iff $ k. 0£ k £ i .( (r, k)|= Q /\" j.k < j £ i . (r, j)|= P)

13. Connections • Have equalities similar to the future: ~ <-> ~ P == [-] P • The past and the future are connected: ( [] P v [] Q ) == [] ( [-] P v [-] Q ) ( <> P /\ <> Q ) == <> ( <-> P /\ <-> Q ) These are just changes in the point of view!

14. Previous • As before, can have a ‘previous’ modality similar to ‘next’ • (r, i ) |= O P iff (r, i - 1 ) |= P • Problem: the past differs from the future in having an initial state. • What is (r, 0 ) |= O P ? Usual assumption: it is always false. • This allows expressing ‘start’ state. (How?)

15. Do we need the past? • Claim: for an entire sequence, we can always ‘translate’ an assertion with past modalities to an equivalent claim without them (if we have enough future modalities) • Systematically change the point of view... <> [ ( T /\ P s Q ) /\ <-> R ]

16. The Past Helps Expressiveness • [] ( Q => <-> P ) Q is preceded by P • How does this relate to [] ( P => <> Q ) ?

17. Proof Modularity • How can we prove mutual exclusion? • spec.: [] ( ~ ( in(Crit0) /\ in( Crit1) )) • Usual way: it follows from an invariant P0:: repeat{so: a() ; Crit0 ; e0: b() } P1:: repeat{s1: a() ; e1: b() ; Crit1 } a() and b() are joint actions, only when P0 and P1 are both ready to do them

18. Proving mutual exclusion (cont.) • An invariant of the system: ( at(s0) = (at(s1) v in(Crit1) ) ) /\ ( at(e1) = (in(Crit0) v at(e0) ) ) • Can be shown by induction on the computation • Also have at(s0) => ~in(Crit0) • Together: in(Crit1) => at (s0) => ~in(Crit0) • Problem: Global view of system....

19. A Modular proof • Predicate “A” means an a() has just occurred locally, similarly for “B” and b() • In P0: [](in(Crit0) => ( ~B s (A /\ ~B))) • In P1: [](in(Crit1) => ( ~A s (B /\ ~A) ) ) • Both of these follow from local reasoning • Claim: if in(Crit0) /\ in(Crit1) were true in any state, the above force a contradiction! (Both RHS’s can’t be true together)

20. Classes of Properties • Past modalities allow identifying syntactic classes of properties • Each class has its own proof techniques and gives ‘similar’ properties • In all classes, are based on any predicate P that only has PAST modalities (or none) • A Safety property can be written as []P (for P any past formula).

21. Hierarchy Reactivity []<>P v <>[]Q * Recurrence Persistence []<>P <>[]P Obligation []P v <>Q * Safety Guarantee []P <>P

22. Safety • Any formula equivalent to one of the form [] P where P is any PAST formula • Invariants are safety properties • []( Q => <-> P ) “Q is preceded by P” is a safety property • Claim: so is P => [] ( at(halt) => Q ) • Can be shown by induction on the traces

23. Finite Refutation • All safety properties have a “Finite Refutation”: For a sequence that does NOT satisfy a safety property P, there is a finite prefix where P is violated, and it is also violated in all continuations from that point. • For other classes of properties, this may not be so (example: reaching halt )

24. Guarantee Properties • Equivalent to <>P • A state will be reached (once) • termination: <> at(halt) • claim: total correctness is a guarantee prop. first /\ P => <> ( at ( halt ) /\ Q ) (rewrite as <>“a past formula” )

25. Obligation • Conjunction of formulas of the form []P v <> Q (again: P and Q are any PAST formulas) • Includes all Safety and Guarantee, plus... • Claim: <> problem => <> solution is of this form

26. Recurrence (or Response) • Equivalent to [] <> P (infinitely often P) • Claim: [] ( P => <> Q) is recurrence. • [] <> ( ~enabled (act) v did ( act ) ) weak fairness • [] <> ~ in (prob-area) no livelock

27. Persistence • Equivalent to <> [] P • Is [] ( P => <> [] Q ) also of this form? • <> [] ( P => [] Q ) eventual latching == <> [] Q v <> [] ~P This is also a persistence property.

28. Reactivity • Conjunctions of [] <> P v <> [] Q • Includes everything else. • Often written [] <> r => [] <> p • Infinitely often enabled => infinitely often executed • Strong fairness

29. Branching Time • Is it enough to relate to “the sequence that will occur” as is done in Linear TL ? • Sometimes we may want to relate to there being a computation with a certain property, or to relate to the relations among the computations. • Relate to “possible worlds” that can be, depending on which action occurs.

30. Example for Branching Time • How can we specify a random-number generator? • Each time it is activated, some value from the given range will be returned. • Is this enough? • Is “return 53” a correct implementation? • Want: there is a possibility of getting any i

31. Semantics of Branching Time • View the computations as organized into a tree: all with a common prefix will be along a path from the root, until they split at some state. • Can also be seen as an “unwinding” of a state machine. Sometimes viewed as a directed acyclic graph of computations (the same state can be reached in more than one way). • Assertions are about these trees, which are NOT ever constructed....

32. CTL* • Computation Tree Logic by Ed Clarke • Use F for <> , G for [] • Add: A for “all computations starting in this state” E for “there is a computation starting in this state” • A and E relate to the subtree starting from that state, while F and G relate to a path

33. Branching Examples • AGp is like []p of linear (why?) • EGp • EFp versus AFp • EFAGp versus EFGp • AGEF interrupted (= potential events)

34. Model Checking • Verify temporal logic properties of an explicit state machine model (with a finite number of states) by checking all possibilities --efficiently. • Formal verification, without using invariants-- an alternative to Hoare logic-type proofs. • Widely used for hardware designs, some use for protocols and key software.

35. CTL* versus CTL • Restrictions on expressibility in CTL: Only pairs of AG, AF, EG, EF, (AX, EX) • Allows efficient model checking • Cannot express in CTL that all FAIR computations have a desired eventuality property: (in CTL* : A(GFp => Fq ) )

36. SMV • Express the system as a collection of transitions (also for gate-level spec. of hardware). • Express the property to be shown as a CTL assertion. • Express the fairness as GF `CTL assert.’ • Builds a compact version of the model, and checks on the compact version. • Can still have problems of state explosion.