Section 1

(1)

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.

(2)

Model-checking

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

(3)

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

… present

past future

…

past present future

Models of time

with past

…

… 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=6

t=6 t=7.4

t=7.4

t=7.4 with (discrete) real-time

(4)

… 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=6

t=6 t=7.4

t=7.4

with (dense) real-time

…

t=0 t=1.2

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𝑪 ⊨ φ.

decision procedures (based on automata techniques).

Classical extensions of TLs.

Section 1 — Plan

Kripke structures

Definition:

A Kripke structure 𝐒 is a 4-tuple ⟨Q,q0,R,𝓁 ⟩ :

-

Q is a finite set of states

-

^q⁰ ∈ Q is the initial state

-

R ⊆ Q x Q is the accessibility relation (often required to be total)

-

^𝓁^{: Q → 2}^AP: 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.

(5)

Modelling a cash dispenser

attente carte code ?

code ?

code ? erreur

erreur

erreur carte bloquée

code ok

montant ?

20€ 40€ 60€

distrib argent

éjection carte annulation

A Kripke structure

Spécifier un système

Un distributeur de billets.

exemple

attente carte code ?

code ?

code ? erreur

erreur erreur

carte

bloquée code

ok

montant ?

20€ 40€ 60€

distrib argent

éjection carte annulation

𝐒 = (Q,Act,→,q

0

,AP,L)

q

0

q

1

q

2

q

3

q

4

q

5

q

7

q

8

q

9

q

10

q11 q12 q13

q

14

q

15

q

16

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 mutuelle Exe mp le

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é

(6)

algorithme d’exclusion mutuelle Exe mp le

→ une KS avec AP={D

1

,D

2

,SC

1

,SC

2

}

‣ 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 = { a

1

, a

2

}

(étiquette les transitions)

algorithme d’exclusion mutuelle Exe mp le

(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

{SC

1

,D

1

}

algorithme d’exclusion mutuelle

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

algorithme d’exclusion mutuelle

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

(7)

algorithme d’exclusion mutuelle

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

algorithme d’exclusion mutuelle

propriétés attendues

✔

✘

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

✘

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

decision procedures (based on automata techniques).

Classical extensions of TLs.

Section 1 — Plan

(8)

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,q

init

,R, 𝓁 ⟩

q ∈ Q,

ρ = q0

q

1

q

2

q

3

q

4

… a path in

𝐒

.

ρ ⊨ P iff P ∈ 𝓁

(q

0

)

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

ρ ⊨ X φ iff ρ¹

⊨ φ (with ρ

¹=

q

1

q

2

q

3

…)

ρ ⊨ φ U 𝜓

iff ∃ i ≥ 0 ( ρ

ⁱ

⊨

𝜓

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, ρ = q0q1 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

(9)

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 ⊨ A

F green

q

ou: … q

CTL - semantics

(10)

… …

q ⊨

EG red

q

…

CTL - semantics

… …

q ⊨ AG

red

q

Every reachable states is red !

CTL - semantics

State formulas:

CTL*

φ, 𝜓 ::= 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,q

init

,R, 𝓁 ⟩

q ∈ Q,

ρ = q0

q

1

q

2

q

3

q

4

… 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 ρ

¹

⊨ φ

p

(with ρ

¹=

q

1

q

2

q

3

…)

ρ ⊨ φp U 𝜓^p

iff ∃ i ≥ 0 ( ρ

ⁱ

⊨

𝜓^p

and (∀ 0 ≤j<i: ρ

^j

⊨ φ

p

) )

CTL* - semantics

(11)

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

(12)

algorithme d’exclusion mutuelle

propriétés attendues

¬ 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 3 123

button light

… …

Specification of a lift

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.

Specification of a lift

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.

(13)

Specification of a lift

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 2 C2 CL2

…

floor k

C1

C0

CL1

CL0

Ck CLk

S2

Sk

S1

S0

SLk

SL2

SL1

SL0

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 pressed CLi (resp. SLi) = ⊤ iff the light is on Dk

D2

D1

D0

cabin

Specification of a lift

G ( D

i

at

i

)

P1. Safe doors:

A floor door is never opened if the cabin is not present at the given floor.

Specification of a lift

(and the same for Si and SLi) G ( Ci

(CL

i

∨ servicing

i

))

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

∧

ⁱ

or

(14)

Specification of a lift

(and the same for Si and SLi)

G

( LC

i⟺

( (¬servicing

i

) S (C

i

∧ ¬ servicing

i

)) )

∧

i

An alternative is:

Specification of a lift

P3. Services:

All requests are eventually satisfied.

G ( requesti

F servicing

i

))

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

[ servicing

i S (CLi

∨ SL

i

) ] )

∧

i

G ( ati

( at

i

W ( ∨ ^(CL

^j

^{∨ SL}

^j

) ) ) )

∧

ⁱ _j≠i

Specification of a lift

G

([ ^{( LC}

ⁱ^{∨ LS}ⁱ

^{) ∧ at}

ⁱ

] ^(at

ⁱ

U servicing

i

) )

∧

i

P5. Diligent service:

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

Specification of a lift

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 ]

¬at

0

∧ … ∧¬at

n

service = servicing0 ∨ servicing1 ∨ … ∨ servicingk

(15)

Specification of a lift

P7. Priorities:

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

Up = ∨ ^[

^(atⁱ^∨ betw_floors ) S ati-1 ∧ (ati ∨ betw_floors) U ati

]

i=1..k

Down = ∨ ^[

^(atⁱ^∨ betw_floors ) S ati+1 ∧ (ati ∨ betw_floors) U ati

]

i=0..k-1

G ∧ ^[

^(servicingⁱ^{∧ Down ∧}

∨

^(CL^j^∨SL^j^{) )}

∨

From_i_to_n

]

i=0..k-1 j<i n<i

G ∧ ^[

^(servicingⁱ^{∧ Up ∧}

∨

^(CL^j^∨SL^j^{) )}

∨

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

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

(16)

Distinguishing power

CTL 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

≡ X CTL

⊨ EX (EX P ∧ EX P)

≡ CTL

(strong) bisimulation

Let 𝐒¹= ⟨Q1,q01,R1,𝓁¹ ⟩ and 𝐒²= ⟨Q2,q02,R2,𝓁² ⟩

A relation 𝓡 ⊆ Q1 x Q2 is a bisimulation iff ∀ (q1,q2) ∈ 𝓡 we have:

-

^𝓁¹^(q¹^{) =}^𝓁²^(q²⁾

-

^{∀ q}¹^→^R1^q¹^{’ , ∃}^q²^→^R2^q²’ such that (q1’,q2’) ∈ 𝓡

-

^{∀ q}²^→^R2^q²^{’ , ∃}^q¹^→^R1^q¹’ such that (q1’,q2’) ∈ 𝓡

𝐒¹and 𝐒² are bisimilar (𝐒¹ ≈ 𝐒²) 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…

(17)

Theorem:

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

(Hennessy, 1980)

Distinguishing power

Section 1

Foundations of real time and hybrid systems - 2.8.2

François Laroussinie

Part 1: Advanced technics in verification

Plan

Section 1

Temporal logics for the specification and verification

Section 1 — Plan

Model-checking

System

ϕ

Properties

Reactive systems

Real-time systems or Timed systems

temporal ≠ timed

Specifying reactive systems

Temporal logics

Temporal logics

Verification problems

Section 1 — Plan

Kripke structures

-

-

-

-

Modelling a cash dispenser

A Kripke structure

Spécifier un système

𝐒 = (Q,Act,→,q

,AP,L)

q

q

q

q

q

q

q

q

q

q

q

q

q

Spécifier un distributeur de billets

algorithme d’exclusion mutuelle Exe mp le

+ hypothèse d’atomicité

algorithme d’exclusion mutuelle Exe mp le

→ une KS avec AP={D

,D

,SC

,SC

}

Act = { a

, a

}

algorithme d’exclusion mutuelle Exe mp le

{SC

,D

}

algorithme d’exclusion mutuelle

propriétés attendues

algorithme d’exclusion mutuelle

algorithme d’exclusion mutuelle

+ équité

+ SC finies

→ un ensemble d’exécutions possibles du système modélisé.

Vérifient-elles les propriétés attendues ?

algorithme d’exclusion mutuelle

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

φ, 𝜓 ::= P | ¬ φ | φ ∨ 𝜓 | X φ | φ U 𝜓

𝐒 =⟨Q,q

,R, 𝓁 ⟩

q ∈ Q,

q

q

+ ^équité

+ ^{SC finies}

φ, 𝜓 ::= P | ¬ φ | φ ∨ 𝜓 ^{| E φ}

^{| A φ}