Temporal Logic

© Katz, 2004CS236368 Formal Specifications Lecture - Temporal logic 1

Temporal Logic

Formal SpecificationsCS236368

Spring 2004

Shmuel Katz

The Technion


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


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


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”


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


Connections

• Box and Diamond are dual

<> P == ~ [] ~ P

[] P == ~ <> ~ P

~ <> P == [] ~ P

• Sometimes see G for [] F for <>


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”


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


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


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)


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!


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?)


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 ]


The Past Helps Expressiveness

• [] ( Q => <-> P ) Q is preceded by P

• How does this relate to [] ( P => <> Q ) ?


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


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....


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)


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).


Hierarchy

Reactivity []<>P v <>[]Q *

Recurrence Persistence []<>P <>[]P

Obligation []P v <>Q *

Safety Guarantee []P <>P


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


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 )


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” )


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


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


Persistence

• Equivalent to <> [] P

• Is [] ( P => <> [] Q ) also of this form?

• <> [] ( P => [] Q ) eventual latching

== <> [] Q v <> [] ~P

This is also a persistence property.


Reactivity

• Conjunctions of [] <> P v <> [] Q

• Includes everything else.

• Often written [] <> r => [] <> p

• Infinitely often enabled => infinitely often executed

• Strong fairness


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.


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


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....


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


Branching Examples

• AGp is like []p of linear (why?)

• EGp

• EFp versus AFp

• EFAGp versus EFGp

• AGEF interrupted (= potential events)


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.


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 ) )


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.

Temporal Logic

Documents

Transcript of Temporal Logic