Post on 14-Jan-2016
description
Reusable PVS Proof Strategies for Proving Abstraction Properties of I/O
Automata
Myla ArcherCode 5546
Naval Research Laboratoryarcher@itd.nrl.navy.mil
Sayan MitraMIT
Computer Sc. and AI Labmitras@csail.mit.edu
Outline
1. Backgroundi. I/O Automataii. TAME
2. Design i. Class ‘automaton’ii. Property theoriesiii. Template for abstraction properties
3. Strategy for weak refinement4. Experimental results5. Conclusions
Background: I/O Automata • Basic I/O automaton model (IOA)
– Discrete events (no timing or probability)
– Parallel composition
– Levels of abstractions
• Automaton [MMT ’91]– X: set of state variables
• now є X: a special ‘real time’ variable
– Q: states, a set of valuations of X
Q: start states
– A = I O H: input, output, invisible actions• nu є A: a special time passage action
– D Q A Q: discrete transitions
visible actions
I/O Automaton Executions and Invariants
• Execution – Alternating sequence s0 a1 s1 a2 s2 …, where:
– Each (si, ai , si+1) is a discrete step
– Beginning in a start state, s0 є • Trace (external behavior): execution restricted to external actions
• Invariant properties (true in all reachable states):– base case:
– induction step:
TAME
SUPPOSE p Splits proof goal into cases based on predicate p.
APPLY_SPECIFIC_PRECOND Appeal to precondition of an action
AUTO_INDUCT Split into base case and induction step and do action based case analysis for induction step.
APPLY_INVARIANT_LEMMA m, i Introduce invariant lemma m, instantiating the universally quantified variables as i in proof goal.
TRY_SIMP Apply propositional, equational, datatype simplifications.
• TAME [Archer ’02] provides a set of strategies that exploit the above proof structure to partially automate invariant proofs.
• Templates – Specifying IOA as PVS theories
– Invariant properties as theorems
• Generic strategies for proving invariants– Reusable : independent of particular IOA
– Relies on IOA template, and structure of invariant theorems.
I/O Automata Traces and Implementation relations
• Some properties cannot be formalized as invariants• A implements B if they have the same set of external
actions and traces(A) traces(B).• Abstraction properties
– Homomorphism– Refinement, weak refinement– Forward and backward simulation
Case Study : TIP
• Tree Identification Phase of IEEE 1394: leader election algorithm.
• Algorithm starts after a reset which clears all topology information except local information– Leaf nodes send parent request (PR) message to neighbors
– When a node receives PR from all but one of its neighbors then it sends a PR to the remaining neighbor. PRs are ACKed
– Tree grows from leaf to root
– Node receiving an ACK terminates as a non-root.
– Node receiving PR from all its neighbors is root --- leader.
– Root contentions are broken by back-off and random retransmit.
• Correctness– # leaders always <= 1
– Eventually, # leaders = 1
actions: DATATYPE nu(t) add_child(edge) children_known(vertices) ack(edges)
resolve_contention(edges) root(vertices)
noop:noop?
visible(a):bool = root?(a) or nu?(a)
states: TYPE = [# init: [Vertices -> Bool], contention: [Vertices -> Bool], root:[Vertices->Bool], child: [Edges -> Bool], mq:[Edges -> BoolStar] #]
enabled_general (a, s):Bool = true
enabled_specific (a, s):Bool = nu(t):t > zero, add_child(e): init(target(e),s) & not(mq(e,s)=null),…
root(v): not(init(v,s)) & not(contention(v,s)) & not(root(v,s)) & (forall (e:tov(v)):child(e,s)), noop:true
enabled (a, s):Bool= enabled_general(a,s) & enabled_specific(a,s)
trans (a, s):states = nu(t): s WITH [now := now(s) + t],
add_child(e):……root(v): s WITH [basic:= basic(s) with [root:= root(basic(s)) with [(v):= true]]],noop: s
start (s):Bool = s = (# basic := basic(s) with ….
SPECactions: DATATYPE
root(vertices)
nu(t)
noop
states: TYPE = [# done:bool #]
enabled_general (a, s):bool = true;
enabled_specific (a, s):bool = nu(t): t > zero,root(v): not(done(s)),noop: true
enabled (a, s):bool = enabled_general(a,s) & enabled_specific(a,s)
trans (a, s):states =nu(t): s WITH [now := now(s) + t],root(v): s WITH [basic:= basic(s) with [done := true]],noop : s
start: [states -> bool] = LAMBDA(s):s = (# basic := basic(s) with [done:= false], now := zero,
first := (LAMBDA (a:spec_actions): zero), last := (LAMBDA (a:spec_actions): infinity) #);
2. Design Issues
• How to define abstraction properties (say, refinement) without referring to particular automata?
• Cannot define a type "automaton" in PVS
• How quantify over two automata?
• Adapt the notion of an automaton object
• A PVS theory with special structure
• A automaton declaration written with TAME template is interpreted as an automaton object
• The object can carry extra information: visible, reachable, etc. for property definitions
• Introduce a template for importing automata definitions and defining a refinement relation between them
• Essentially user has to rewrite the definition of refinement for every pair of automata
• User has to be familiar with PVS naming conventions
• Introduce a generic refinement theory which is imported in the context of the two automata to state the refinement relation
• User has to write a new theory that matches the elements of the automata theories to elements of the generic theory
Design Issues (contd.)
Instead, parameterize generic refinement theory on automaton objects Pass automata theories interpreted as automaton objects as parameters to a
generic refinement theory Automatic matching by name of theory elements to elements of automaton object
This matching is made possible by recent PVS enhancements, making it easier to pass theory parameters.
How to distinguish between analogous objects (e.g. A.states vs B.states) from two automata when communicating with the prover? Formal theory-parameter names can be used as prefixes on objects from the actual
theories
Interpretation
Interpretation
3. Pieces in PVS Specification of an Abstraction property
Automaton ClassTemplate for Abstraction properties
i
Abstraction Property
iiiA
Bim
port
MA
MB
Theorem: MA implements MB
ii
Rest of the Talk
1. Background
2. Previous barriers
3. Pieces in PVS specificationi. Class ‘automaton’
ii. Property theories
iii. Template for abstraction properties
4. Strategy for weak refinement
5. Experimental results
6. Conclusions
i. Class automaton
automaton : THEORY
BEGIN
actions : TYPE+
states : TYPE+
visible (a: actions) : bool
start (s: states) : bool
enabled (a: actions, s: states) : bool
trans (a: actions, s: states): states
reachable (s: states): bool
converts (s1 , s2 : states) : bool
END automaton
ii. Property Theories : Forward Simulation
fwd_sim_base: FORALL sA, If A.start(sA) then EXISTS sB, B.start(sB) and r(sA,sB);
fwd_sim_step
FORALL sA, sA’, sB, aA, r(sA,sB) & A.enabled(aA,sA) & sA’ = A.trans(aA,sA) implies
If A.visible(aA)
then EXISTS sB1, sB
2, sB3,
converts(sB,sB1) & converts(sB
2,sB2) &
r(sA’, sB3) &
B.enabled(actmap(aA), sB1) & B.trans(actmap(aA),sB
1) = sB2)
else EXISTS sB3, converts(sB, sB
3) & r(sA’, sB
3)
sA sA’aA sA sA’
aA
sBsB
1 sB2 sB
3
r r
actm
ap
sB sB3
r r
Visible Invisible
ii. Property Theories : Weak Refinement
weak_refinement_base
FORALL sA:A.states, if A.start(sA) then B.start(r(sA))
weak_refinement_step
FORALL sA, aA, A.reachable(sA) & A.enabled(aA,sA) implies
if A.visible(aA) then B.enabled(actmap(aA),r(sA)) and
r(A.trans(aA,sA)) = B.trans(actmap(aA),r(sA))
else r(sA) = r(A.trans(aA,sA)) or r(A.trans(aA,sA)) = B.trans(actmap(aA),r(sA))
weak_refinement THEOREM
weak_refinement_base and weak_refinement_step
iii. Template for Abstraction Properties
Initial theory imports for TIP and SPEC
MA : THEORY = automaton :-> tip_decls
MB : THEORY = automaton :-> spec_decls
amap(aA: MA.actions): MB.actions =
CASES aA OF
nu(t): nu(t), add_child(e):noop, children_known(c): noop, ack(a): noop, resolve_contention(r):noop, root(v): root(v), noop:noop
ENDCASES
ref(sC: MC.states): MA.states =
(# basic := (# done := EXISTS (v:Vertices): root(v,s_C) #), now := now(s_C) #)
IMPORTING weak_refinement[MA,MC, amap, ref]
weak_refinement_theorem: THEOREM refinement
PROVE_REFINEMENTPROVE_REFINEMENT
SETUP_REF_BASE SETUP_REF_INDUCT_CASES
START_REF_INDUCTION_BRANCH START_REF_INDUCTION_BRANCH
START_ENABLEMENT_PROOF DO_TRANS DO_TRANS
APPLY_GENERAL_PRECOND APPLY_SPECIFIC_PRECOND
PROVE_REFINEMENT Strategy
PROVE_REFINEMENT
SETUP_REF_BASE SETUP_REF_INDUCT_CASES
START_REF_INDUCTION_BRANCH START_REF_INDUCTION_BRANCH
START_ENABLEMENT_PROOF DO_TRANS DO_TRANS
APPLY_GENERAL_PRECOND APPLY_SPECIFIC_PRECOND
weak_refinement : weak_refinement_base & weak_refinement_step
weak_refinement_base : FORALL sc:A.states, if A.start(sc) then B.start(r(sc))
weak_refinement_step : FORALL sc, ac, A.reachable(sC) & A.enabled(aC,sC) implies
if A.visible(aC) then B.enabled(actmap(aC),r(sC)) and
r(A.trans(aC,sC)) = B.trans(actmap(aC),r(sC))
else r(sC) = r(A.trans(aC,sC)) or r(A.trans(aC,sC)) = B.trans(actmap(aC),r(sC))
SETUP_REF_BASE
(defstep setup_ref_base (concsimpstrat abssimpstrat) (then (expand "refinement_base") (skolem 1 "sC_1") (flatten) (expand "start") (expand "ref") concsimpstrat abssimpstrat)"" "")
PROVE_REFINEMENT
SETUP_REF_BASE SETUP_REF_INDUCT_CASES
START_REF_INDUCTION_BRANCH START_REF_INDUCTION_BRANCH
START_ENABLEMENT_PROOF DO_TRANS DO_TRANS
APPLY_GENERAL_PRECOND APPLY_SPECIFIC_PRECOND
START_ENABLEMENT_PROOF(defstep start_enablement_proof (comment-string)
(let ((gencomcmd (setq *gencomcmd* `(comment ,(format nil "~a~a" comment-string "general enablement")))) (speccomcmd (setq *speccomcmd* `(comment ,(format nil "~a~a" comment-string "specific enablement"))))) (then (expand "enabled" "enabled C.action" :assert? NONE) (with-labels (flatten) (("C.general-precondition" "C.specific-precondition"))) (expand "enabled" "enabled A.action" :assert? NONE) (branch (with-labels (split) (("A.general-precondition" "A.specific-precondition"))) ((then (apply_general_precond)
gencomcmd
(time_simp)
(postpone)) (then (apply_specific_precond)
speccomcmd
(postpone)))))) "" "")
PROVE_REFINEMENT
SETUP_REF_BASE SETUP_REF_INDUCT_CASES
START_REF_INDUCTION_BRANCH START_REF_INDUCTION_BRANCH
START_ENABLEMENT_PROOF DO_TRANS DO_TRANS
APPLY_GENERAL_PRECOND APPLY_SPECIFIC_PRECOND
TIP Walkthrough: Proof Stages
weak_refinement : |------- {1} refinement
Rule?
(PROVE_REFINEMENT)
{-1,(base-case)} s_C!1 = (# basic := basic(s_C!1) WITH [init := LAMBDA (v: Vertices): TRUE, contention := LAMBDA (v: Vertices): FALSE, root := LAMBDA (v: Vertices): FALSE, child := LAMBDA (e: Edges): FALSE, mq := LAMBDA (e: Edges): null], now := zero, first := (LAMBDA (a: actions): zero), last := (LAMBDA (a: actions): infinity) #) |------- {1,(base-case)} NOT (EXISTS (v: Vertices): root(v, s_C!1)) AND now(s_C!1) = zero
Rule?
(SETUP_REF_BASE)
TIP Walkthrough: Proof Stages
;;; Case nu(timeof_C_action) enablement
[-1,(reachable C.prestate)]
reachable(s_C_theorem)
[-2,(enabled C.action)]
enabled(nu(timeof_C_action), s_C_theorem)
|-------
[1,(enabled A.action)]
tip_spec_decls.enabled (nu(timeof_C_action),
(# basic := (# done := EXISTS (v: Vertices): root(v, s_C_theorem) #),
now := now(s_C_theorem),
first := (LAMBDA (a: MA.actions): zero),
last := (LAMBDA (a: MA.actions): infinity) #))
TIP Walkthrough: Proof Stages ;;; Transitions correspond for nu {-1,(enabled A.action)}
tip_spec_decls.enabled(nu(timeof_C_action), (# basic := (# done := EXISTS (v: Vertices): root(v, s_C_theorem) #),
now := now(s_C_theorem), first := (LAMBDA (a: MA.actions): zero), last := (LAMBDA (a: MA.actions): infinity) #))
[-2,(reachable C.prestate)] reachable(s_C_theorem)
[-3,(enabled C.action)] enabled(nu(timeof_C_action), s_C_theorem)
|------- {1,(congruence)}
((# basic := (# done := EXISTS (v: Vertices): root(v, trans(nu(timeof_C_action), s_C_theorem)) #), now := now(trans(nu(timeof_C_action), s_C_theorem)), first := (LAMBDA (a: MA.actions): zero), last := (LAMBDA (a: MA.actions): infinity) #) = tip_spec_decls.trans(nu(timeof_C_action),
(# basic := (# done := EXISTS (v: Vertices): root(v, s_C_theorem) #), now := now(s_C_theorem), first := (LAMBDA (a: MA.actions): zero), last := (LAMBDA (a: MA.actions): infinity) #)))
Tip Proof("" (prove_refinement)
(("1" ;; Case root(rootV_C_action) specific enablement case (skolem_in "A.specific-precondition" "v_1") (apply_inv_lemma "15" "s_C_theorem") ;; Applying the lemma ;; (EXISTS (v: Vertices): FORALL (e: tov(v)): child(e, s_C_theorem)) => ;; ((EXISTS (v: Vertices): FORALL (e: tov(v)): child(e, s_C_theorem)) & ;; (FORALL (v, w: Vertices): ;; (((FORALL (e: tov(v)): child(e, s_C_theorem)) & ;; (FORALL (e: tov(w)): child(e, s_C_theorem))) => v = w))) (inst_in "lemma_15" "rootV_C_action") (inst_in "lemma_15" "v_1" "rootV_C_action") (inst_in "lemma_15" "v_1" "rootV_C_action") (skolem_in "lemma_15" "e_1") (apply_inv_lemma "13" "s_C_theorem" "e_1"))
;; Applying the lemma
;; FORALL (e: Edges): root(target(e), s_C_theorem) +> child(e, s_C_theorem)
(try_simp) (“2" ;; Case root(rootV_C_action) congruence (inst "congruence" "rootV_C_action") (try_simp))))
5. Other Case Studies
• Specification and implementation of failure prone memory component[ Romijn 1996] – REL_MEM: concrete automaton
– MEM: Abstract automaton, same as MEM without fail action
• The refinement relation ref is a bijection
• The action map amap is an injection
• Trace inclusion proved by weak refinement– Proved completely automatically using (prove_refinement)
Forward Simulation
• Concrete automaton: composition of P C T [Kaynar, et. al. 2004 ]– Send process P sends a message every u1 time until fail action occurs
– Channel C delivers message with a max delay b
– Timeout process T times out if it does not receive a message for more than u2
time, and suspects P to be failed
• Property to check:– If u2 > u1 + b then suspects failed
• Abstract automaton:– A fail action is followed by timeout in u2 + b time
• Trace inclusion proved by forward simulation in PVS
• Developing strategy PROVE_FWD_SIM– Initial proof steps are similar to PROVE_REFINEMENT
– Needs addition TAME sub strategies
Conclusions
• Specification of abstraction properties in PVS/ TAME– Automaton object / theory
– Library of abstraction property theories
– Template for stating abstraction properties as theorems
• Reusable strategy for proving weak refinement in TAME– User friendly interactive proving
– Template for developing strategies for proving other abstraction relations
• Add other abstraction relations to library
• Develop PROVE_FWD_SIM and others
• Integrate with TIOA tools