Download Safety and Liveness

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
Safety and Liveness
Introduction
A safety property asserts that a system does not exhibit bad behavior,
e.g. it is not possible to reach an error state.
A liveness property asserts that a system eventually will do something
good, e.g. produce output.
A fairness property is a liveness property in which we require that a
system gives fair turns to its components.
Questions
• How do we define these notions formally?
• How can we specify safety/liveness properties in practice?
Specifying Liveness: Switch Example
-
s
on on
off s0 “Good”
s
s on s0 off s
s on s0 off s on s0 off s · · ·
“Bad”
s on s0
“Good” or “Bad”? Depends on application!
s on s0 on s0 on s0 · · ·
Specifying Liveness (cnt)
off 0
on-0
6
on 0
?
on off
off 0
on off
on
6
on 0
?
on , on 0
“Good” or “Bad”?
on on 0 off 0 on on 0 off 0 on on 0 off 0 · · ·
⇒ Specification of liveness can be tricky!
What is a liveness property, really?
Formal Definitions (Alpern & Schneider 1985)
Safety (“no bad thing ever happens”):
A set S ⊆ execs (B) is a safety property if
∀σ ∈ execs (B) : σ ∈ S
⇔
[∀ρ ∈ fexecs (B) : ρ ≤ σ ⇒ ρ ∈ S]
Liveness (“something good eventually happens”):
A set L ⊆ execs (B) is a liveness property if
∀σ ∈ fexecs (B) : ∃ρ ∈ fragm (B) : σ · ρ ∈ L
Examples
Safety properties:
• The set of all executions of an automaton that only contain states
that satisfy some state property ϕ (invariance).
• The set of all executions of the switch automaton that contain
at most 3 off actions.
• The set of all executions of the candy bar automaton in which
—at any point— the number of occurrences of the Twix and
Bounty actions differ by at most one.
• The set of all executions of a channel system in which the sequence of messages that are output is a prefix of the sequence of
messages that are input.
Examples
Liveness properties:
• The set of all executions of an automaton that are either infinite
or end in a quiescent state (a state in which no locally controlled
action is enabled).
• The set of all executions of the switch automaton in which the
system does not stay in state s0 from some point onwards.
• The set of all finite executions of the candy bar automaton in
which the number of occurrences of Twix actions equals the number of occurrences of Bounty actions.
• The set of all executions of the channel system satisfying that if
an output action is enabled from some point onwards then it is
eventually taken.
Fact. Safety properties are prefix closed. Formally, if S is a safety
property then
σ ∈S∧ρ≤σ
⇒
ρ∈S
Fact. Safety properties are limit closed. Formally, if S is a safety
property then
σ1 , σ 2 , σ 3 , . . . ∈ S ∧ σ1 ≤ σ2 ≤ σ3 · · ·
⇒
( lim σi) ∈ S
i→∞
Fact. If X is both a safety and a liveness property then X equals the
set of all executions.
Theorem. Each set X of executions of a SIOA can be written as
the intersection of a safety and a liveness property.
Proof sketch: Suppose B is a SIOA. Let
• S = limit closure of prefix closure of X
• L = execs (B) − (S − X)
Then X = S ∩ L.
A Naive Definition
A live I/O automaton is a pair (B, L) where B is a safe I/O automaton
and L is a liveness property for B.
Problem: Consider the switch automaton
on
-
s
on
-
off
s0
L is set of executions with at least five occurrences of on
Specifation constrains environment!!
Receptiveness/Environment Freedom (Dill 1988)
System should behave properly independently of inputs provided by
the environment. It should not constrain its environment.
Game between ‘system’ and ‘environment’:
• automaton is the board
• system player performs locally controlled actions
• environment player performs input actions
• goal system player is to obtain run in given liveness property L
• goal environment player is to prevent this
Strategies
A strategy for a safe I/O automaton B fully specifies the moves for
the system player. Formally, it is a pair of functions (g, f ) where
g : fexecs (B) × in (B ) → states (B )
f : fexecs (B) → (local (B ) × states (B )) ∪ {⊥}
such that
g(σ, a) = s
⇒ σ a s ∈ fexecs (B)
f (σ) = (a, s) ⇒ σ a s ∈ fexecs (B)
An environment sequence for B is an infinite sequence of symbols
from in (B ) ∪ {λ}, with infinitely many occurrences of λ.
Outcome of Game
Suppose
• ρ = (g, f ) is a strategy,
• I = a1a2a3 · · · is an environment sequence,
• σ is a finite execution.
Then the outcome of the game with ρ, I and σ, denoted by Oρ(σ, I)
is the execution limi→∞ σi, where σi’s are defined inductively by
• σ0 = σ
• If i > 0 then
ai = λ ∧ f (σi−1) = (a, s) ⇒ σi = σi−1 a s
ai = λ ∧ f (σi−1) =⊥ ⇒ σi = σi−1
ai ∈ in (B ) ⇒ σi = σi −1 ai g (σi −1 , ai )
Live I/O Automata
A live I/O automaton is a pair (B, L) with B a SIOA and L ⊆ execs (B)
such that there exists a strategy ρ with for any finite execution σ and
any environment sequence I, Oρ(σ, I) ∈ L.
Fact. If (B, L) is a live IOA then L is a liveness property of B.
Proof: Follows immediately from the fact that σ ≤ Oρ(σ, I).
Fairness
A fair I/O automaton A consists of
• a SIOA safe (A)
• sets WF (A) and SF (A) of subsets of local (safe (A)), called the weak
fairness and strong fairness sets, respectively.
Note
An I/O automaton is a fair I/O automaton A with SF (A) = ∅ and
WF (A) a partition of local (safe (A)). In the IOA language, WF (A) is
referred to as the task partition.
Definition
A set of actions X is enabled in a state s iff some action a ∈ X is
enabled in s.
Execution σ is weakly fair iff for W ∈ WF (A)
• If σ is finite then W is not enabled in the last state of σ.
• If σ is infinite then σ contains either infinitely many occurrences of
actions from W , or infinitely many occurrences of states in which
W is not enabled.
Execution σ is strongly fair iff for S ∈ SF (A)
• If σ is finite then S is not enabled in the last state of σ.
• If σ is infinite then σ contains either infinitely many occurrences
of actions from S, or only finitely many occurrences of states in
which S is enabled.
∆
σ fair = σ both weakly and strongly fair
∆
fairexecs (A) = fair executions of A
Theorem (Romijn & Vaandrager 1995)
Suppose that A is a fair IOA with
• each reachable state of A enables at most countably many sets
in WF (A) ∪ SF (A)
• for all S ∈ SF (A), a ∈ in (A), and reachable states s, s0: if s enables
a
S and s → s0, then s0 enables S
Then (safe (A), fairexecs (A)) is a live IOA.
Example of Fair IOA that is Not Live
i
-
-
s
o
i
Input: i
Output: o
Weak fairness: ∅
Strong fairness: {{o}}
s0
Specifying Safety and Liveness in Practice
In IOA, safety properties can be expressed using invariants. History
dependent safety properties can be expressed by using additional history variables.
The only liveness properties that can be specified in IOA are weak
fairness properties, which can be specified using the task partition.
Temporal logic is a convenient language for defining both safety and
liveness properties.