Temporal Logic
Shmuel Katz
The Technion
Formal Specifications
CS236368
Spring 2004
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 1
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
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 2
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
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 3
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”
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 4
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
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 5
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
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 6
Connections
• Box and Diamond are dual
<> P
== ~ [] ~ P
[] P
==
~ <> P
~ <> ~ P
==
• Sometimes see
CS236368 Formal Specifications
[] ~ P
G for []
F for <>
© Katz, 2004
Lecture - Temporal logic 7
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 )
CS236368 Formal Specifications
“always, P leads to Q”
© Katz, 2004
Lecture - Temporal logic 8
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” )
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 9
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
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 10
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
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 11
Is the Future Enough?
• Lamport: Yes
Pnueli: maybe not
• Past operators:
>
>
>
<->
[-]
s
‘once’
‘until now’,
‘so far’
‘since’ (reflection of ‘until’)
(r, i) |= P s Q iff
$k. 0k  i .( (r, k)|= Q /\"j.k < j  i . (r, j)|= P)
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 12
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!
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 13
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?)
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 14
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 ]
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 15
The Past Helps Expressiveness
• [] ( Q => <-> P )
Q is preceded by P
• How does this relate to [] ( P => <> Q ) ?
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 16
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
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 17
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....
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 18
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)
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 19
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).
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 20
Hierarchy
Reactivity
[]<>P v <>[]Q *
Recurrence
[]<>P
Persistence
<>[]P
Obligation
[]P v <>Q *
Safety
[]P
CS236368 Formal Specifications
Guarantee
<>P
© Katz, 2004
Lecture - Temporal logic 21
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
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 22
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 )
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 23
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
CS236368 Formal Specifications
<>“a past formula” )
© Katz, 2004
Lecture - Temporal logic 24
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
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 25
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
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 26
Persistence
• Equivalent to <> [] P
• Is [] ( P => <> [] Q ) also of this form?
•
<> [] ( P => [] Q )
eventual latching
== <> [] Q v <> [] ~P
This is also a persistence property.
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 27
Reactivity
• Conjunctions of [] <> P v <> [] Q
• Includes everything else.
• Often written [] <> r => [] <> p
• Infinitely often enabled => infinitely often
executed
• Strong fairness
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 28
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.
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 29
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
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 30
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....
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 31
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
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 32
Branching Examples
• AGp
is like []p of linear (why?)
• EGp
• EFp
versus
• EFAGp
versus EFGp
• AGEF interrupted
CS236368 Formal Specifications
AFp
(= potential events)
© Katz, 2004
Lecture - Temporal logic 33
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 logictype proofs.
• Widely used for hardware designs, some
use for protocols and key software.
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 34
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 )
)
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 35
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.
CS236368 Formal Specifications
© Katz, 2004
Lecture - Temporal logic 36