section 1 - iriffrancoisl/divers/mpri1920c1.pdf · tls are a good formalism for specifying...

Foundations of real time and hybrid systems - 2.8.2

François Laroussinie IRIF, Univ. Paris Diderot

Part 1: Advanced technics in verification

Plan

1. Temporal logics for the specification and verification

2. Timed temporal logics

3. Model-checking for discrete-time systems

4. Model-checking for timed automata

Section 1

Temporal logics for the specification and verification

Introduction: why Temporal Logic is a good specification language ?

Classical temporal logics: LTL, CTL, CTL* → definitions, expressivity, decision procedures (based on automata techniques).

Classical extensions of TLs.

Section 1 — Plan

Kripke structures to model systems.

Model-checkingModel checking

System

? ϕ

Properties

Formalizing step

Automata, Kripke structures, Petri nets, process algebra, games,…

Automata, Logics,…

Reactive systems

Reactive systems maintain an ongoing interaction with their environment.

Their correctness properties deal with the events along the executions.

Ex: “If a problem occurs, an alarm will start”.

or: along an execution, if a problem occurs at some point, then an alarm will be turned on afterwards.

Real-time systems or Timed systems

(Reactive) systems with quantitative timing constraints. → quantitative time.

Not only « before/after », but « after 5 time units »

Ex: “If a problem occurs, an alarm will start before 10 ms”.

temporal ≠ timed

Specifying reactive systems

Safety properties: “bad things do not happen”. Ex: There is at most one process in the Critical Section.

Liveness properties: “good things do happen (eventually)”. Ex: Every request for the CS is eventually granted.

Fairness properties: → Verification of fair executions. Ex: Every process should be executed infinitely often.

Temporal logics

TLs are a good formalism for specifying properties of reactive systems.

[Pnueli 1977]

Allow to state properties about the order of events along an execution.

‣natural semantics, ‣good expressive power, ‣succinctness, ‣efficient decision procedures (and tools !), ‣many extensions (for timed systems, probabilistic systems, games, data,…).

Temporal logics

Temporal logics = propositional logic +

temporal modalities

+ a model of time !

… (linear time)

… (branching time)

+ many other variants !!

…

presentpast future

…

pastpresent

future

Models of timewith past

…

…

Models of time

t=0 t=1.2 t=3 t=5.1 t=6 t=7.4

t=0t=1.2

t=3

t=3

t=6

t=6

t=7.4

t=7.4

t=7.4

with (discrete) real-time

…

Models of time

t=0 t=1.2 t=3 t=5.1 t=6 t=7.4

…t=0

t=1.2

t=3

t=3

t=6

t=6

t=7.4

t=7.4

t=7.4

with (dense) real-time

…t=0

t=1.2

t=3

t=3

t=6

t=6

t=7.4

t=7.4

Verification problems

Model-checking:input: a model 𝐒 and a formula φ output: yes iff 𝐒 ⊨ φ.

Satisfiability:input: a formula φ output: yes iff there exists a model satisfying φ. (+ a model if the answer is yes…)

Controller synthesis:input: a model 𝐒 and a formula φ output: a controller 𝑪 s.t. 𝐒x𝑪 ⊨ φ.




Section 1 — Plan


Kripke structures

Definition:A Kripke structure 𝐒 is a 4-tuple ⟨Q,q0,R,𝓁 ⟩ : - Q is a finite set of states - q0 ∈ Q is the initial state - R ⊆ Q x Q is the accessibility relation (often required to be

total) - 𝓁 : Q → 2AP : gives the valuation of atomic propositions in

each state.

q0

q1

q2

q3

Executions/paths from q0: q0(q1q3)ω, q0q1q3(q2)ω, …

AP: the set of atomic propositions.

Modelling a cash dispenser

attente carte

code ?

code ?

code ?

erreur

erreur

erreur

carte bloquée

codeok

montant ?

20€ 40€ 60€

distrib argent

éjectioncarte

annulation

A Kripke structureSpécifier un système

Un distributeur de billets.exemple

attente carte

code ?

code ?

code ?

erreur

erreur

erreur

carte bloquée

codeok

montant ?

20€ 40€ 60€

distrib argent

éjectioncarte

annulation

𝐒 = (Q,Act,→,q0,AP,L)

q0

q1

q2

q3

q4

q5q7

q8

q9

q10

q11 q12 q13

q14

q15q16

AP={att. carte, code?, c. bloquée, code ok, …}

Spécifier un distributeur de billets

‣Si le bon code est donné, on peut choisir une somme et on obtiendra de l’argent.

‣Après avoir fait trois erreurs de code, la carte est bloquée. ‣Après avoir obtenu l’argent, la carte est éjectée. ‣A tout moment, si on appuie sur annulation, la carte est éjectée sans donner d’argent sauf si l’utilisateur a fait trois erreurs avant.

algorithme d’exclusion mutuelleExe

mple

boolean D1:= False boolean D2 := False

Processus P1: loop forever: p1: Section NC p2: D1 := True p3: await (not D2) p4: section critique p5: D1 := False

Processus P2: loop forever: p1: Section NC p2: D2 := True p3: await (not D1) p4: section critique p5: D2 := False

+ hypothèse d’atomicité

algorithme d’exclusion mutuelle

Exemple

→ une KS avec AP={D1,D2,SC1,SC2}

‣ D1 étiquette les états où la variable D1 est vraie, ‣ D2 étiquette les états où la variable D2 est vraie, ‣ SC1 étiquette les états où le processus 1 est en section critique, ‣ SC2 étiquette les états où processus 2 est en section critique.

Act = { a1, a2 } (étiquette les transitions)


Exemple

(SC1,SC2,D1,D2)

(F,F,F,F)

(F,F,T,F)

(T,F,T,T)

(F,F,F,T)

(F,F,T,T)

(F,T,T,T)

(T,F,T,F) (F,T,F,T)

a1 a2

{SC1,D1}


‣Exclusion mutuelle: Jamais les deux processus ne peuvent se trouver en SC au même moment.

‣Il n’y a jamais pas de blocage.

‣Absence de famine: Si un processus demande l’accès à la SC, il y arrivera un jour.

‣Attente bornée: Si un processus demande l’accès à la SC, l’autre processus ne peut pas passer avant lui plus d’une fois.

propriétés attendues

En général, on vérifie ces propriétés sous hypothèses d’équité entre processus et en supposant que chaque section critique se termine.


(F,F,F,F)

(F,F,T,F)

(T,F,T,T)

(F,F,F,T)

(F,F,T,T)

(F,T,T,T)

(T,F,T,F) (F,T,F,T)

Equité = infinité de transitions bleues et de rouges.SC termine = infinité de transitions bleues et de rouges pleines (pas en pointillés !).


(F,F,F,F)

(F,F,T,F)

(T,F,T,T)

(F,F,F,T)

(F,F,T,T)

(F,T,T,T)

(T,F,T,F) (F,T,F,T) +équité + SC finies

→ un ensemble d’exécutions possibles du système modélisé.Vérifient-elles les propriétés attendues ?







✔

✘

(→ l’algorithme n’est pas bon !)

✘

✘

Comment énoncer précisément ce genre de propriétés ?








Section 1 — Plan


LTL

(Path) formulas: φ,𝜓 ::= P | ¬ φ | φ∨𝜓 | X φ | φ U 𝜓

‣ LTL = Linear-Time Temporal Logic

+Abbrev.: ⊤, ⊥, ∧, Fφ = ⊤ U φ : “eventually“ , G φ = ¬ F ¬φ : “always “ φW 𝜓 = φU 𝜓 ∨ G φ : “weak until”

P ∈ AP

LTL formulas are interpreted over (infinite) paths of Kripke structures.

𝐒 =⟨Q,qinit,R,𝓁 ⟩ q ∈ Q, ρ = q0 q1 q2 q3 q4 … a path in 𝐒.

ρ ⊨ P iff P ∈ 𝓁(q0)

ρ ⊨ φ∨𝜓 iff ( ρ ⊨ φ or ρ ⊨ 𝜓) ρ ⊨ ¬φ iff ( ρ ⊭ φ )

ρ ⊨ X φ iff ρ1 ⊨ φ (with ρ1= q1 q2 q3 …)

ρ ⊨ φ U 𝜓 iff ∃ i ≥ 0 ( ρi ⊨ 𝜓 and (∀ 0 ≤j<i: ρj ⊨ φ ) )

LTL - semantics

CTL

(State) formulas: φ,𝜓 ::= P | ¬φ | φ∨𝜓 | EX φ | AX φ | Eφ U𝜓 | Aφ U𝜓

‣ CTL = Computation Tree Logic

+Abbrev.: ⊤, ⊥, ∧, EFφ = E ⊤ U φ : “eventually“ , AG φ = ¬ EF ¬φ : “always “ AFφ = A ⊤ U φ , EG φ = ¬ AF ¬φ

P ∈ AP

CTL formulas are interpreted over states of Kripke structures.

𝐒 =⟨Q,qinit,R,𝓁 ⟩ q ∈ Q, ρ = q0 q1 q2 q3 q4 … a path in 𝐒.

q ⊨ P iff P ∈ 𝓁(q)

q ⊨ EX φ iff ∃ π ∈ Path(q) s.t. π(1) ⊨ φ

q ⊨ AX φ iff ∀ π ∈ Path(q), π(1) ⊨ φ

q ⊨ E φ U 𝜓 iff ∃ π ∈ Path(q) s.t. ∃ i ≥ 0 ( π(i) ⊨ 𝜓 and (∀ 0 ≤j<i: π(j) ⊨ φ ) )

q ⊨ A φ U 𝜓 iff ∀ π ∈ Path(q), ∃ i ≥ 0 ( π(i) ⊨ 𝜓 and (∀ 0 ≤j<i: π(j) ⊨ φ ) )

CTL - semantics

CTL - semantics

… …

… …

q ⊨ E red U green

q

…or:q

… …

… …

q ⊨ A red U green

q

…ou:q

CTL - semantics

… …

… …

q ⊨ EF green

q

…ou:q

CTL - semantics

… …

… …

q ⊨ AF green

q

…ou:q

CTL - semantics

… …

… …

q ⊨ EG red

q

…

CTL - semantics

… …

… …

q ⊨ AG red

q

Every reachable states is red !

CTL - semantics

CTL*State formulas: φ,𝜓 ::= P | ¬φ | φ∨𝜓 | E φp | A φp

Path formulas: φp,𝜓p ::= φ | ¬ φp | φp ∨ 𝜓p | X φp | φp U 𝜓p

‣ LTL = only path formulas [no path quantifier]

‣ CTL = path formulas are restricted to: φp ::= X φ | φ U 𝜓

+Abbrev.: ⊤, ⊥, ∧, Fφ = ⊤ U φ : “eventually“ , G φ = ¬ F ¬φ : “always “ φW 𝜓 = φU 𝜓 ∨ G φ : “weak until”

P ∈ AP 𝐒 =⟨Q,qinit,R,𝓁 ⟩ q ∈ Q, ρ = q0 q1 q2 q3 q4 … a path in 𝐒.

q ⊨ P iff P ∈ 𝓁(q)

q ⊨ E φp iff ∃ π ∈ Path(q) s.t. π ⊨ φp

q ⊨ A φp iff ∀ π ∈ Path(q), π ⊨ φp

ρ ⊨ X φp iff ρ1 ⊨ φp (with ρ1= q1 q2 q3 …)

ρ ⊨ φp U 𝜓p iff ∃ i ≥ 0 ( ρi ⊨ 𝜓p and (∀ 0 ≤j<i: ρj ⊨ φp ) )

CTL* - semantics

Fragments of CTL*φ,𝜓 ::= P | ¬φ | φ∨𝜓 | E φp | A φp φp,𝜓p ::= ¬ φp | φp ∨ 𝜓p | X φ | φ U 𝜓

CTL+

ECTL

with: F φ = GF φ ∞

φ,𝜓 ::= P | ¬φ | φ∨𝜓 | E φp | A φp φp,𝜓p ::= X φ | φ U 𝜓 | F φ ∞

∞φ,𝜓 ::= P | ¬φ | φ∨𝜓 | E φp | A φp φp,𝜓p ::= ¬ φp | φp ∨ 𝜓p | X φ | φ U 𝜓 | F φ

ECTL+

Examples

G (problem ⇒ F alarm)

AG (problem ⇒ AF alarm)

G F (a)

A ( (GF a) ⇒ (GF b) )

LTL

CTL

CTL*

LTL

= A ( F a ⇒ F b ) ∞ ∞

∞ ∞A ( G a ⇒ F b) CTL+

A ( F a ⇒ F b) ECTL+

Other specification languages

- propositional µ-calculus - MSO - …

Example of properties







¬ F (SC1 ∧ SC2) G (¬ SC1 ∨ ¬ SC2)

G (X ⊤ ) (NB: toujours vrai si → est totale)

G (D1 ⇒ F SC1) ∧ G (D2 ⇒ F SC2)

G (D1 ⇒ ( (¬SC2) U ( SC1 ∨ SC2 U ( ¬ SC2 U SC1 )))

Specification of a lift

H. Barringer (“Up and down, the temporal way”, 1985)

floor 1

floor 2

floor 3123

button light

……


Hypothesis:

‣ A floor door is open or closed. ‣ A button is pressed or depressed. ‣ An indicator light is on or off. ‣ The cabin is present at floor i, or it is absent.


P1. Safe doors: A floor door is never opened if the cabin is not present at the given floor.

P2. Indicator lights: The indicator lights correctly reflect the current requests.

P3. Services: All requests are eventually satisfied.

P4. Smart service: The cabin only services the requested floors and does not move when there is no request.


P5. Diligent service: The cabin does not pass by a floor for which it has a request without servicing it.

P6. Direct movements: The cabin always moves directly from previous to next serviced floor.

P7. Priorities: The cabin services in priority requests that do not imply a change of direction (upward or downward).

Specification of a lift: the atomic prop.

floor 0

floor 1

floor 2C2 CL2

…

…

floor k

C1

C0

CL1

CL0

Ck CLkS2

Sk

S1S0

SLk

SL2SL1SL0

Di = ⊤ iff the doors at floor i are opened And: ati = ⊤ iff the cabin is at floor i

Ci (resp. Si) = ⊤ iff the button is pressedCLi (resp. SLi) = ⊤ iff the light is on

Dk

D2

D1

D0

cabin


G ( Di ⇒ ati)

P1. Safe doors: A floor door is never opened if the cabin is not present at the given floor.

Specification of a liftP2. Indicator lights: The indicator lights correctly reflect the current requests.

(and the same for Si and SLi)

G ( Ci ⇒ (CLi ∨ servicingi ))with: servicingi = ati ∧ Di

: turned on when necessary∧i

G ( CLi ⇒ ( CLi W servicingi ) ) : stay lit when necessary∧i

G ( servicingi ⇒ (¬ CLi ∧ ¬ SLi)) : turned off when necessary∧i

G ( (¬ CLi ) ⇒ ( (¬CLi) W Ci) ) :only turned on when necessary∧i

G ( CLi ⇒ ( CLi S Ci) )∧ior

Specification of a liftP2. Indicator lights: The indicator lights correctly reflect the current requests.

(and the same for Si and SLi)

G ( LCi ⟺ ( (¬servicingi ) S (Ci ∧ ¬ servicingi)) )∧i

An alternative is:

Specification of a liftP3. Services: All requests are eventually satisfied.

G ( requesti ⇒ F servicingi ))

with: requesti = Ci ∨ Si

∧i

P4. Smart service: The cabin only services the requested floors and does not move when there is no request.

G ( servicingi ⇒ [ servicingi S (CLi ∨ SLi) ] )∧i

G ( ati ⇒ ( ati W ( ∨ (CLj ∨ SLj ) ) ) ) ∧i j≠i


G ([( LCi ∨ LSi) ∧ ati ]⇒ (ati U servicingi ))∧i

P5. Diligent service: The cabin does not pass by a floor for which it has a request without servicing it.


G ( From_i_to_j ⇒ (ati ∨ betw_floors) U (ati+1 ∧ (ati+1∨ betw_floors) U (ati+2 …(atj-1 ∧ (atj-1∨ betw_floors) U atj))))

∧i<j

P6. Direct movements: The cabin always moves directly from previous to next serviced floor.

servicingi ∧ [ (servicingi ∨ ¬ service) U servicingj ]

¬at0∧ … ∧¬atn

service = servicing0 ∨ servicing1 ∨ … ∨ servicingk


P7. Priorities: The cabin services in priority requests that do not imply a change of direction (upward or downward).

Up = ∨ [ (ati ∨ betw_floors ) S ati-1 ∧ (ati ∨ betw_floors) U ati ]i=1..k

Down = ∨ [ (ati ∨ betw_floors ) S ati+1 ∧ (ati ∨ betw_floors) U ati ]i=0..k-1

G ∧[(servicingi ∧ Down ∧ ∨ (CLj∨SLj) ) ⇒ ∨ From_i_to_n] i=0..k-1 j<i n<i

G ∧[(servicingi ∧ Up ∧ ∨ (CLj∨SLj) ) ⇒ ∨ From_i_to_n] i=1..k j>i n>i

Which is the best one ? CTL* ? LTL ? CTL ? …

Which logic should we choose ?

There are several criteria: - the expressiveness - the complexity of decision procedures - the existence of tools - …

Expressiveness

Expressiveness

3 different notions:

- Distinguishing power‣ 𝓛 is at least as distinguishing as 𝓛’ (𝓛 ≥ 𝓛’) iff for any

𝐒 and 𝐒’, 𝐒 ≡𝓛 𝐒’ ⇒ 𝐒 ≡𝓛’ 𝐒’

‣ with: 𝐒 ≡𝓛 𝐒’ iff (∀ φ ∈ 𝓛, 𝐒 ⊨ φ ⟺ 𝐒’⊨ φ )

- Expressive power‣ 𝓛 is at least as expressive as 𝓛’ (𝓛 ≽ 𝓛’) iff for ∀ φ’ ∈ 𝓛’, ∃ φ ∈ 𝓛 s.t. φ ≡ φ’

- Succinctness when 2 logics 𝓛 and 𝓛’ are equally expressive, one can be more succinct (w.r.t. the size of the formula)…

Distinguishing powerCTL and CTL* formulas are interpreted over state of KS, or equivalently over the nodes of its execution tree.

LTL formulas are interpreted over paths. With LTL, a system is viewed as a set of executions.

Convention: for a KS 𝐒 and φ ∈ LTL, we write 𝐒 ⊨ φ when q0 ⊨ A φ

→ Two Kripke structures satisfy the same LTL formulas iff they have the same set of executions (ie they are trace-equivalent).

={ };

≡LTL

Distinguishing power

≡CTLX

⊨ EX (EX P ∧ EX P)

≡CTL

(strong) bisimulation

Let 𝐒1= ⟨Q1,q01,R1,𝓁1 ⟩ and 𝐒2= ⟨Q2,q02,R2,𝓁2 ⟩ A relation 𝓡 ⊆ Q1 x Q2 is a bisimulation iff ∀ (q1,q2) ∈ 𝓡 we have: - 𝓁1(q1) = 𝓁2(q2)

- ∀ q1→R1 q1’ , ∃ q2→R2 q2’ such that (q1’,q2’) ∈ 𝓡

- ∀ q2→R2 q2’ , ∃ q1→R1 q1’ such that (q1’,q2’) ∈ 𝓡

𝐒1 and 𝐒2 are bisimilar (𝐒1 ≈ 𝐒2) iff there exists a bisimulation 𝓡 such that (q01,q02)∈ 𝓡.

Behavioral equivalences (Van Glabbeek, 1990)

2-nested simulation

ready simulation

bisimulation

ready trace

equivalence

failure trace

equivalence

readiness

equivalence

failure

equivalence

completed trace

equivalence

trace equivalence

possible-futures

equivalence

simulation

[LTL]

Behavioral equivalences (Van Glabbeek, 1990)

[CTL, CTL*]

CTL distinguishes more than LTL…

Theorem: Two (finitely branching) Kripke structures satisfy the same CTL (or CTL*) formulas iff they are bisimilar.

(Hennessy, 1980)

Distinguishing power

section 1 - iriffrancoisl/divers/mpri1920c1.pdf · tls are a good formalism for specifying...

Documents