Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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.