© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 1 Temporal Logic Formal Specifications CS Shmuel Katz The Technion

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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”

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 7 Connections Box and Diamond are dual <> P == ~ [] ~ P [] P == ~ <> ~ P ~ <> P == [] ~ P Sometimes see G for [] F for <>

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 8 The future fragment So far, the simple future fragment of Linear 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”

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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” )

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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)

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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!

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

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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 ]

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 16 The Past Helps Expressiveness [] ( Q => P ) Q is preceded by P How does this relate to [] ( P => <> Q ) ?

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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....

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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)

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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).

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 21 Hierarchy Reactivity []<>P v <>[]Q * Recurrence Persistence []<>P <>[]P Obligation []P v <>Q * Safety Guarantee []P <>P

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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 )

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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” )

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 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.

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 28 Reactivity Conjunctions of [] <> P v <> [] Q Includes everything else. Often written [] <> r => [] <> p Infinitely often enabled => infinitely often executed Strong fairness

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 29 On Fairness Often used to restrict a system—as part of an ASSUMPTION about the system. Only fair computations are interesting and must be checked—the unfair ones can be ignored: they will not happen in practice Note: can’t express all fair computations in a tree without also sometimes having unfair ones In other situations, the system is intended to guarantee fair scheduling---so an assertion of fairness is one of the REQUIREMENTS and must be checked

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 30 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.

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 31 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

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 32 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....

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 33 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

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 34 Branching Examples AGp is like []p of linear (why?) EGp EFp versus AFp EFAGp versus EFGp AGEF interrupted (= potential events)

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 35 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.

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 36 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 ) )

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 37 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.

© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 38 Using Temporal Logic Usually just important properties—not a full specification Often used to analyze a more detailed state machine Sometimes used to add liveness or global invariants to a state machine Note that there is no “time” in temporal logic!