1. Recognizing Safety and Liveness
By Bowen Alpern, Fred B. Schneider
Presented by Choi, Chang-Beom

2. Content Introduction Notation Recognizing Safety Recognizing Liveness
Categorizing Systems
Linear-time Temporal Logic
Safety & Liveness
Model Checking
Notation
Recognizing Safety
Recognizing Liveness
Partitioning into Safety and Liveness
Conclusion
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST, Chang-Beom Choi

3. Introduction What is people’s interest?
Consider two objects
S – Specification : What of a system description
I – Implementation : How of a system description
Establish that I conforms with S
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST, Chang-Beom Choi

4. Introduction Categories of Systems
System can be divided into two categories
Transformational programs
Reactive systems (Interactive) x y
Data Intensive
System
Env
Control Intensive
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST, Chang-Beom Choi

5. Introduction Two Type of Transformational program
Finite word
Input : finite word
Output : finite word
Model of System : Finite State Automata with finite word
Infinite word
Input : infinite word
Output : infinite word
Model of System : Finite State Automata with infinite word
Büchi Automata
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST, Chang-Beom Choi

6. Introduction How About the Specification of Systems?
People wanted to have an accurate way of giving specification
Linear-time Temporal Logic
(LTL)
The ability to express all sorts of specifications
Expressiveness
Reasonable complexity to evaluate the specified rules
Complexity
Easy to learn
Pragmatics
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST, Chang-Beom Choi

7. Introduction Example: Mutual Exclusion by Semaphores
Consider Two coordinating access to their critical sections by Semaphores
y : integer where y = 1 N1 N2 T1 T2
Release y
Release y
Request y
Request y C1 C2
Request y : <await y > 0; y = y -1>
Release y : y = y+1
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST, Chang-Beom Choi

8. Introduction Example: Specification of MUTEX by a Property List
Safety : bad thing will not happen
The two processes can never visit their respective critical section at the same time
□ ┐(C1 ∧ C2)
Liveness : good thing will happen
Every visit of a process to its trying section is followed by a visit to the critical section of the same process
T1⇒◊ C1 T2 ⇒◊ C2
□ : always
◊ : eventually
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

9. Introduction Example: Specification by an Abstract Model
N1, N2
N1, T2
T1, N2
N1, C2
T1, T2
C1, N2
T1, C2
C1, T2
The absence of the state <C1, C2> implies mutual exclusion
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

10. Introduction Example: Adding Liveness
N1, N2
N1, T2
T1, N2
N1, C2
T1, T2
C1, N2
T1, C2
C1, T2
Escape Region 2
Escape Region 1
Liveness imposed by the specification of escape regions and requiring that no computation remains contained forever in any escape region
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

11. Introduction Model Checking
For a system T and a specification formula φ we say that :
T ⊨ φ if Lω(T) ⊆ models(φ)
models(φ) = {σ ∈ (2Prop)ω |σ⊨φ}
Translate both the system T and the formula φ to a representation that would allow us to verify such a containment
Containment of Büchi Automata
Lω(A1) ⊆ Lω(A2) ⇔ Lω(A1) ∩ Lω(Ac2) =∅ ⇔ Lω(A1 ∩ Ac2) = ∅
Complementation of Nondeterministic Büchi Automata creates automaton of size nO(n)
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

12. Content Introduction Notation Recognizing Safety Recognizing Liveness
Categorizing Systems
Linear-time Temporal Logic
Safety & Liveness
Model Checking
Notation
Recognizing Safety
Recognizing Liveness
Partitioning into Safety and Liveness
Conclusion
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST, Chang-Beom Choi

13. Notation History A program π is assumed to be specified in terms of
Its set of atomic actions Aπ
A predicate Initπ that describes its possible initial states
History
Execution of π can be viewed as an infinite sequence of program states
σ= s0s1 …
s0 satisfies Initπ and each following state results from executing a single enabled atomic action Aπ from in the preceding state
Terminating execution : repeating the finial state
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

14. Notation Property Property Set of infinite sequences of program states
σ ⊨ P (infinite sequence σ is in property P)
A program satisfies a property P if for each of its histories h, h ⊨ P
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

15. Notation Büchi Automata
Büchi Automata m accepts the sequences of program states that are in L(m), the property it specifies.
Definition
A = (Σ, S, S0, ρ, F) Σ: alphabet (set of program states) S : set of automaton states
S0 : set of initial state ρ : a transition function (S xΣx S) F : a set of accepting states
The input of A is infinite w : a0, a1, … (∈ Σω)
A run is a sequence of states r: s0,s1, … (∈ Sω)
Initiation: s0 ∈ S0
Consecution : si+1∈ρ(si, ai)
Inf(r) : {s: s= si for infinitely many i-s} Acceptance : Inf(r) ∩ F = ∅
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

16. Notation Example of Büchi Automata
run : q0, q1, q1, q1, …
S = {q0, q1}
S0 = {q0}
ρ = {(q0,true, q0), (q0, P, q1), (q1,true, q1)
F = {q1}
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

17. Notation Reduced Büchi Automata
Büchi automaton is reduced if from every state there is a path to an accepting state
Given an arbitrary Büchi automaton, an equivalent reduced Büchi automaton can always be obtained by deleting every state from which no accepting state is reachable
If the next symbol read by Büchi automaton satisfies no transition predicate, the input is rejected; in this case we say the transition is undefined
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

18. Notation Additional Definitions
σ[i] = si
σ[…i] = s0s1…si
σ[i…] = sisi+1…
|σ| = the length of σ(if ω is σ infinite)
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

19. Content Introduction Notation Recognizing Safety Recognizing Liveness
Categorizing Systems
Linear-time Temporal Logic
Safety & Liveness
Model Checking
Notation
Recognizing Safety
Recognizing Liveness
Partitioning into Safety and Liveness
Conclusion
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST, Chang-Beom Choi

20. Recognizing Safety Properties Formal Definition
Safety property : “bad thing” does not happen
What is “bad thing”?
Attempting an undefined transition
If “bad thing” happens in every run while reading an input, the Büchi automaton will not accept that input
If “bad thing” happens in an infinite sequence σ, then it must do so after some finite prefix and must be irremediable.
Safety : (∀σ: σ∈ Σω : σ ⊨ P ⇔ (∀ i: 0 ≤i : (∀ β: β ∈ Σω : σ[…i]β⊨ P )))
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

21. Recognizing Safety Properties RBA and Safety Properties
Closure cl(m)
For a reduced Büchi automaton m, cl(m) to be the corresponding Büchi automaton in which every stae has been made into an accepting state.
The closure of m accepts a safety property
It never rejects an input by failing to enter accepting sates(lack of “good thing”)
It rejects only by attempting an undefined transition
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

22. Recognizing Safety Properties Theorem 1
A reduced Büchi automaton m specifies a safety property iff L(m) = L(cl(m))
Proof
⇒ Assume m specifies safety property
L(m) ⊆ L(cl(m)) : trivial
L(cl(m)) ⊆ L(m)
Let α ∈ L(cl(m)), then α[…i] puts m in state qi Since m is reduced, qi precedes an accepting states
β= β0β1β2 …
Therefore, α[…i]β causes m to be in accepting states infinitely often, α ∈ L(m)
(∀ i: 0 ≤i : (∀ β: β ∈ Σω : α[…i]β ∈ L(m) ))
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

23. Recognizing Safety Properties Proving Theorem 1⇐
σ ∈ L(m) ⇒ (∀ i: 0 ≤i : (∀β: β ∈ Σω : σ[…i]β ∈ L(m) ))
Since we can choose β= σ[i+1…] σ ∉L(m) ⇒ ┓(∀ i: 0 ≤i : (∀β: β ∈ Σω : σ[…i]β ∉ L(m) ))
Since L(m) =L(cl(m)), σ ∉L(cl(m)) ⇒ ∃ i: 0 ≤i : (∃β: β ∈ Σω : σ[…i]β ∉ L(cl(m) ))
σ ∉L(cl(m)) then cl(m) reject σ. Let undefined transition occur upon reading σ[k]
(∃β: β ∈ Σω : σ[…k]β ∉ L(cl(m) ))
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

24. Content Introduction Notation Recognizing Safety Recognizing Liveness
Categorizing Systems
Linear-time Temporal Logic
Safety & Liveness
Model Checking
Notation
Recognizing Safety
Recognizing Liveness
Partitioning into Safety and Liveness
Conclusion
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST, Chang-Beom Choi

25. Recognizing Liveness Formal Definition
Liveness : “good thing” eventually happens
What is “good thing”?
Entering an accepting state infinitely often
Require “good thing” to happen for an input to be accepted
No partial execution is irremediable since if some partial execution were irremediable, then it would be a “bad thing”
Liveness (∀α:α∈ Σ*: (∃β:β∈ Σω: αβ ⊨ P))
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

26. Recognizing Liveness Theorm 2
A reduced Büchi auomaton m specifies a liveness property iff L(cl(m)) =Σω
Proof
⇒ Assume m specifies liveness property
(∀α:α∈ Σω: (∀ i: 0 ≤i : (∃β:β∈ Σω: α[…i]β ∈ L(m) )))
m does not attempt an undefined transition when reading an input α, cl(m) does accepts α , therefore
(∀α:α∈ Σω: α∈ L(cl(m)) )
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

27. Recognizing Liveness Proving Theorem 2⇐
Similar to Proof of Theorem 1
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

28. Recognizing Liveness Example : Büchi automaton that specifies liveness property
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

29. Content Introduction Notation Recognizing Safety Recognizing Liveness
Categorizing Systems
Linear-time Temporal Logic
Safety & Liveness
Model Checking
Notation
Recognizing Safety
Recognizing Liveness
Partitioning into Safety and Liveness
Conclusion
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST, Chang-Beom Choi

30. Partitioning into Safety and Liveness Construct Büchi Automaton Specifying Properties
Büchi automaton is equivalent to the conjunction of a safety property and a liveness property
Safe(m)
Büchi Automaton which specifies a safety property
It uses cl(m)
Live(m)
Büchi Automaton which specifies a liveness property
Construct Büchi automaton s.t.
L( Live(m)) = L(m) ∪ (Σω - L(cl(m)))
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

31. Partitioning into Safety and Liveness Construct Live(m)
Trap state qtrap
A trap state is one that has a transition to itself for all inputs
m is deterministic
m augmented by an accepting trap state qtrap
Transition function ρLive every undefined transition of m to put Live(m) in qtrap
m is nondeterministic
Use m x env(m) and take accepting states of m or env(m)
env(m) = Σω - L(cl(m)) env(m) include a trap state qtrap and the sets of automaton states of m qtrap is the only accepting state of env(m).
Transition function ρenv
ρenv(qi,s) = qtrap if ρm(qi,s) = ∅, otherwise ρm(qi,s)
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

32. Partitioning into Safety and Liveness Lemma
L( Live(m)) = L(m) ∪ (Σω - L(cl(m)))
m is deterministic
Assume α∈ L( Live(m))
Live(m) enters accepting states infinitely ofen when reading α
Accepting states are also states of m and α∈ L( m)
Otherwise, one of the accepting state is qtrap, therefore
α ∉ L(cl(m))
∴α∈ (Σω - L(cl(m)))
(Omission)
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

33. Partitioning into Safety and Liveness Example of Lemma
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

34. Partitioning into Safety and Liveness Theorem 3 and Theorem 4
Theorem 3 Safe(m) specifies a safety property
Theorem 4 Live(m) specifies a Liveness property
Deterministic case
By construction, Live(m) has no undefined transitions. Therefore L(cl(Live(m))) = Σω
Nondeterministic case
(Omission)
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

35. Partitioning into Safety and Liveness Theorem 5
Given a reduced Büchi automaton m, L(m) = L(Safe(m)) ∩ L(Live(m))
Proof
L(Safe(m)) ∩ L(Live(m))
= L(m) ∪ (Σω - L(cl(m))) ∩ L(cl(m))
= (L(m) ∩ L(cl(m)))∪ ((Σω - L(cl(m))) ∩ L(cl(m)))
= (L(m) ∩ L(cl(m)))∪ ∅
= L(m)
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

36. Content Introduction Notation Recognizing Safety Recognizing Liveness
Categorizing Systems
Linear-time Temporal Logic
Safety & Liveness
Model Checking
Notation
Recognizing Safety
Recognizing Liveness
Partitioning into Safety and Liveness
Conclusion
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST, Chang-Beom Choi

37. Conclusion There are lots of things to study
DBA vs NBA
Expressive power of Deterministic Büchi Automaton is less then Nondeterministic Büchi Automaton
Generalized Büchi Automata?
Simplified Live(m) ?
Connection between Safety and Liveness properties and Partial and Total Correctness
Proving Deterministic Safety and Liveness Properties
Saftey properties specified by deterministic Büchi automata can be proved using only invariance arguments
A variant function of well-foundedness argument is therefore required in proving a liveness property.
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

38. Conclusion Next Presentation ?
Translate LTL into Automaton
M. Vardi, M. Daniele and F.Giunchiglia, Improved Automata Generation for Linear Temporal Logic, CAV’99
Other Topics?
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi

39. Reference
Verification Engineering: A Future Profession. By Amir Pnueli, (A. M. Turing Award Lecture) Sixteenth Annual ACM Symposium on Principles of Distributed Computing (PODC 1990), San Diego, August, 1997
Recognizing Safety and Liveness By Bowen Alpern, Fred B. Schneider, Distributed Computing, vol. 2, num. 3, 1987
Automata-Theoretic Approach to Automated Verification By Amir Pnueli and M. Vardi Lecture Note from
Recognizing Safety and Liveness, Provable Software Lab, CS, KAIST Chang-Beom Choi