Post on 19-Dec-2015
© Katz, 2007CS236368 Formal Specifications Lecture - Temporal logic 1
Temporal Logic
Formal SpecificationsCS236368
Shmuel Katz
The Technion
© Katz, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - Temporal logic 7
Connections
• Box and Diamond are dual
<> P == ~ [] ~ P
[] P == ~ <> ~ P
~ <> P == [] ~ P
• Sometimes see G for [] F for <>
© Katz, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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 iffk. 0k i .( (r, k)|= Q /\j.k < j i . (r, j)|
= P)
© Katz, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - Temporal logic 16
The Past Helps Expressiveness
• [] ( Q => <-> P ) Q is preceded by P
• How does this relate to [] ( P => <> Q ) ?
© Katz, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - Temporal logic 21
Hierarchy
Reactivity []<>P v <>[]Q *
Recurrence Persistence []<>P <>[]P
Obligation []P v <>Q *
Safety Guarantee []P <>P
© Katz, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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 => <> solutionis of this form
© Katz, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - Temporal logic 34
Branching Examples
• AGp is like []p of linear (why?)
• EGp
• EFp versus AFp
• EFAGp versus EFGp
• AGEF interrupted (= potential events)
© Katz, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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, 2007CS236368 Formal Specifications Lecture - 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!