Properties of Matter Physical Properties, Phases of Matter, Chemical Properties.
Section 1 - IRIFfrancoisl/DIVERS/mpri1920c1.pdf · TLs are a good formalism for specifying...
Transcript of 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𝑪 ⊨ φ.
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.
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)
algorithme d’exclusion mutuelle
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}
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 !).
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
‣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
✔
✘
(→ l’algorithme n’est pas bon !)
✘
✘
Comment énoncer précisément ce genre de propriétés ?
‣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.
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.
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
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
¬ 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
……
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.
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 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
Specification of a lift
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
Specification of a lift
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.
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 ]
¬at0∧ … ∧¬atn
service = servicing0 ∨ servicing1 ∨ … ∨ servicingk
Specification of a lift
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