1. On Building PVS Interfaces for Abstraction Proofs Extending TAME for Refinements Sayan Mitra mitras@theory.lcs.mit.edu Myla Archer archer@itd.nrl.navy.mil

2. 1. Motivation Why a theorem prover interface ? –Simpler to use Strict rules for specification Fewer proof steps –Provides a more tamed environment, for special purposes. –Less effort Strategies exploit common proof patterns –Generate human readable proofs How does it work ? –Example: TAME Template for specifying Timed I/O Automata Specialized Strategies for Inductive Invariant Proofs. We want to extend this idea to other kinds of proofs –Abstractions –Termination –Liveness

3. Talk Outline 1.Motivation 2.Background A quick tour of TAME PVS strategies Interface for Abstraction proofs Abstraction relations Design using PVS theory interpretations The Examples Strategy for proving Refinement Results Conclusions ToDo’s & Future work

4. 2. Timed Automaton Modeling Environment Provides a template for specifying timed automata States Actions : Visibility, Preconditions, and Transitions Start states –Reachable states of the automaton –Equivalence of states Strategies for proving Invariants –AUTO_INDUCT –DIRECT_PROOF –TRY_SIMP –APPLY_GENERAL_PRECOND –APPLY_SPECIFIC_PRECOND –APPLY_IND_HYP –APPLY_INV_LEMMA

5. 2.1 TAME: Theory Tree TESLA_decls statesmachinetime TESLA_unique_auxTESLA_rewrite_1_auxTESLA_rewrite_2_aux TESLA_invariants state actions preconditions transitions start state

6. 2.2 PVS Strategies PVS prover commands are either rules or strategies –A rule executes as a single step, e.g. skolem, flatten, etc. –A strategy is created using PVS strategy building commands (strategicals), e.g., then, branch, try, let, if, etc. Rule applications Other strategies Examples of simple strategies –(TRY (THEN (LIFT-IF) (PROP) (ASSERT)) (FAIL) (SKIP)) –(APPLY (THEN (LIFT-IF) (PROP (ASSERT)) let, if strategicals allow the use of Lisp code in strategies Lisp is used to probe the current proof state and create prover commands.

7. 2.3 Probing the Proof State in PVS The following slots have :instance allocation: label "weak_refinement_thm.1" current-goal {-1} "rel_mem_visible(rel_nu(rel_nu1_var!1))" {-2} "rel_mem_reachable(s1)“ {3} "rel_mem_enabled(rel_nu(rel_nu1_var!1), s1)" |------- {1} "mem_enabled_general(amap(rel_nu(rel_nu1_var!1)),r(s1))" current-xrule… (lisp (describe *ps* ))

8. 2.3 Probing the Proof State in PVS The following slots have :instance allocation: s-forms (mem_enabled_general(amap(rel_nu(rel_nu1_var!1)), r(s1)) NOT rel_mem_visible(rel_nu(rel_nu1_var!1)) NOT rel_mem_reachable(s1) NOT rel_mem_enabled(rel_nu(rel_nu1_var!1), s1)) p-sforms (mem_enabled_general(amap(rel_nu(rel_nu1_var!1)), r(s1))) n-sforms (NOT rel_mem_visible(rel_nu(rel_nu1_var!1)) NOT rel_mem_reachable(s1) NOT rel_mem_enabled(rel_nu(rel_nu1_var!1), s1)) (lisp (describe (current-goal *ps* )))

9. 2.3 Probing the Proof State in PVS (mem_enabled_general(amap(rel_nu(rel_nu1_var!1)), r(s1)) NOT rel_mem_visible(rel_nu(rel_nu1_var!1)) NOT rel_mem_reachable(s1) NOT rel_mem_enabled(rel_nu(rel_nu1_var!1), s1)) is a cons. (lisp (describe (s-forms (current-goal *ps* )))) (lisp (describe (car (s-forms (current-goal *ps* ))))) newline-comment nil parens 0 type bool free-variables nil free-parameters unbound from-macro nil operator mem_enabled_general argument (amap(rel_nu(rel_nu1_var!1)), r(s1)) nil

10. A Typical defstep in a Strategy (defstep ref_induct_steps () (let ((sforms (s-forms (current-coal *ps*))) (refStepName (string (id (formula (car sforms))))) (cmd `(then (expand, refStepName) (skolem 1 “s1”))) cmd) “Expands induction step and skolemizes top level” “Expand” )

11. 3 Abstraction Relations: Refinements A refinement from A to B is a function r from states of A to states of B, such that: –s є start(A) implies r(s) є start(B), and –s  a A s’ implies r(s)  a B r(s’). A weak refinement from A to B is a function r from states of A to states of B, such that: –s є start(A) implies r(s) є start(B), and –for every reachable state s, and transition s  a A s’, if a is a visible action then r(s)  a B r(s’), otherwise r(s) = r(s’). Thm: (Weak) Refinement is sound. A ≤ r B implies A ≤ T B Thm: Invariance: If A ≤ r B, I A is invariant for A, and I B = r(I A )= {r(s) | s є I A }, then is I B an invariant for B ?

12. 3.1 More on Refinements No, I B as defined above is not an invariant for B. –start(B) not contained in I B. Suppose I B is an invariant for B We define I A = {s | r(s) є I B } Then I A is an invariant for A.

13. 3.1 Abstraction Relations: Simulations A forward simulation from A to B is a function f from states of A to states of B, such that: –s є start(A) implies f(s) ∩ start(B) ≠ Ø, and –if s is a reachable state of A, s  a A s’, and u є f(s), then there exists u’ є f(s’), such that u  a B u’. Thm: refinement implies forward simulation. Thm: Soundness A ≤ f B implies A ≤ T B

14. 3.2 Interface for Abstraction Proofs: The Plan PVS 3 is supposed to support theory interpretations We define a generic automaton theory An abstraction theory defines the relation between two automata automaton:THEORY BEGIN actions: TYPE+; visible:[actions->bool]; states: TYPE+ enabled:[actions,states -> bool]; trans:[actions, states ->states]; equivalent:[states, states ->bool]; reachable:[states->bool]; start:[states -> bool] END automaton refinement[ A, B : THEORY automaton, r:[A.states -> B.states], amap: [A.actions -> B.actions]] : THEORY A common theory imports the specification of both the abstract and concrete automata and imports the abstraction theory IMPORTING abstractions_lib@refinement[tip_decls, spec_decls, r, amap]

15. 3.3 Problems The previous scheme requires –PVS theory interpretations, and –Passing theories as parameters by name We have collapsed all the theories into a single theory –Abstract and concrete automata specifications –The invariants –The abstraction relation and the corresponding theorem To distinguish the components of each automaton –Cannot rely on standard naming not implemented presently does not work!!

16. We are here 1.Motivation 2.A quick tour of TAME PVS strategies 3.Interface for Abstraction proofs Abstraction relations Design using PVS theory Problems The Examples Strategy for proving Refinement Results Conclusions ToDo’s & Future work

17. 4 Example 1: Tip VERTICES: TYPE+; Link: TYPE=[Vertices, Vertices]; Edges: TYPE = {l:Link | not(proj_1(l)=proj_2(l))}; % source, target functions and definition of connectness tip_actions: DATATYPE nu(timeof:(fintime?)): nu? add_child(addE: Edges): add_child? children_known(childV: Vertices): children_known? ack(ackE: Edges): ack? resolve_contention(resE: Edges): resolve_contention? root(rootV: Vertices): root? noop:noop? tip_visible(a:tip_actions):bool tip_MMTstates: TYPE = [# init: [Vertices -> Bool], contention: [Vertices -> Bool], root: [Vertices -> Bool], child: [Edges -> Bool], mq:[Edges -> BoolStar] #] IMPORTING states[tip_actions,tip_MMTstates,time,fintime?] % this should not be necessary if % tip_states:TYPE = states tip_enabled_general (a:tip_actions, s:tip_states):bool = now(s) >= first(s)(a) & now(s) zero, add_child(e): children_known(v): ack(e): resolve_contention(e): root(v): not(init(v,s)) & not(contention(v,s)) & not(root(v,s)) & (forall (e:tov(v)): child(e,s)), noop:true tip_enabled (a:tip_actions, s:tip_states):bool = tip_enabled_general(a,s) & tip_enabled_specific(a,s) IMPORTING machine[tip_states, tip_actions, tip_enabled, tip_trans, tip_start, tip_visible]

18. 4.1 Tip continued (Transitions) tip_trans (a:tip_actions, s:tip_states):tip_states = nu(delta_t): s WITH [now := now(s) + delta_t], add_child(e): if not(mq(e,s)=null) then s WITH [basic:= basic(s) with [child := child(basic(s)) with [(e):=true], mq := mq(basic(s)) with [(e):= cdr(mq(e,s))]]] else s endif, children_known(v): …. ack(e):… resolve_contention(e):… root(v): s WITH [basic:= basic(s) with [root:= root(basic(s)) with [(v):= true]]], noop: s tip_start (s:tip_states):bool = s = (# basic := basic(s) with ….

19. 4.2 The Spec spec_actions: DATATYPE spec_root(rootV: Vertices): spec_root? spec_nu(timeof:(fintime?)): spec_nu? spec_noop: spec_noop? spec_MMTstates: TYPE = [# done:bool #] IMPORTING states[spec_actions,spec_MMTstates,time,fintime?] spec_enabled_general (a:spec_actions, s:spec_states):bool = now(s) >= first(s)(a) & now(s) <= last(s)(a); spec_enabled_specific (a:spec_actions, s:spec_states):bool = spec_nu(delta_t): delta_t > zero, spec_root(v): not(done(s)), spec_noop: true spec_trans (a:spec_actions, s:spec_states):spec_states = spec_nu(delta_t): s WITH [now := now(s) + delta_t], spec_root(v): s WITH [basic:= basic(s) with [done := true]], spec_noop : s spec_enabled (a:spec_actions, s:spec_states):bool = spec_enabled_general(a,s) & spec_enabled_specific(a,s) spec_start: [spec_states -> bool] = LAMBDA(s:spec_states):s = (# basic := basic(s) with [done:= false], now := zero, first := (LAMBDA (a:spec_actions): zero), last := (LAMBDA (a:spec_actions): infinity) #); IMPORTING machine[spec_states, spec_actions, spec_enabled, spec_trans, spec_start, spec_visible]

20. 4.3 Action and State maps for Tip amap(a A : tip_actions): spec_actions = nu(t): spec_nu(t), add_child(e): spec_noop, children_known(c): spec_noop, ack(a): spec_noop, resolve_contention(r):spec_noop, root(v): spec_root(v), noop: spec_noop r(s A : tip_states): spec_states = (# basic := (# done := EXISTS (v:Vertices): root(v,s A ) #), now := now(s A ), first := (LAMBDA(a:spec_actions): zero), last := (LAMBDA(a:spec_actions): infinity) #)

21. 4.4 Tip Invariants and Refinement Theorem Thm_200: THEOREM (FORALL (s:tip_states): tip_reachable(s) => spec_reachable(r(s))); refinement_base: bool = (FORALL (s A :tip_states): tip_start(s A ) => spec_start(r(s A ))); weak_alt_refinement_step: bool = (FORALL (s A :tip_states, a A :tip_actions): tip_reachable(s A ) & tip_enabled(a A,s A ) => IF tip_visible(a A ) THEN (spec_enabled(amap(a A ),r(s A )) & r(tip_trans(a A,s A ))= spec_trans(amap(a A ),r(s A ))) ELSE (r(s A ) = r(tip_trans(a A,s A ))) ENDIF) weak_refinement_step : bool = (FORALL (s A :tip_states): FORALL (a A :tip_actions): tip_reachable(s A ) & tip_enabled(a A,s A ) => (tip_visible(a A )  (spec_enabled(amap(a A ),r(s A )) & r(tip_trans(a A,s A ))= spec_trans(amap(a A ),r(s A )))) & (NOT tip_visible(a A )  ((r(s A ) = r(tip_trans(a A,s A ))) OR (r(tip_trans(a A,s A ))= spec_trans(amap(a A ),r(s A )))))) weak_refinement : bool = refinement_base & weak_refinement_step weak_refinement_thm : THEOREM weak_refinement correspondence equality

22. 4.5 Example 2: Memory : The Spec find:[Locs, Memory -> MemVals] change:[Locs, Vals, Memory -> Memory] find_Ax: AXIOM FORALL(l,m): IF memloc(l) THEN find(l,m) = m(l) ELSE find(l,m) = InitVal ENDIF change_Ax: AXIOM FORALL(l,v,m): IF memloc(l) AND memval(v) THEN change(l,v,m) = m WITH [(l) := v] ELSE change(l,v,m) = m ENDIF mem_actions: DATATYPE nu(timeof:(fintime?)): nu? read(proc:Process, loc:Locs):read? write(proc:Process, loc:Locs, val: Vals):write? return(proc:Process, ack:Ack):return? bad_arg(proc:Process):bad_arg? mem_failure(proc:Process):mem_failure? get(proc:Process):get? put(proc:Process):put? noop:noop? mem_MMTstates: TYPE = [# pc:[Process->Mpc], loc:[Process->Locs], val:[Process->Vals], memory:Memory, performed:[Process->bool], legal:[Process->bool] #] mem_enabled_specific (a:mem_actions, s:mem_states):bool = nu(delta_t): delta_t > zero, read(p,l):true, write(p,l,v):true, return(p,ack): bad_arg(p): ( Read?(pc(s,p)) OR Write?(pc(s,p)) ) AND NOT legal(s,p), mem_failure(p):( Read?(pc(s,p)) OR Write?(pc(s,p)) ), get(p): Read?(pc(s,p)) AND legal(s,p) AND (NOT performed(s,p)), put(p): Write?(pc(s,p)) AND legal(s,p), noop:true

23. 4.6 Reliable Memory Identical to mem specs, except, does not have the mem_failure action. r and amap are identity functions. amap(a A : rel_mem_actions): mem_actions = rel_nu(t): nu(t), rel_read(p,l): read(p,l), rel_write(p, l, v):write(p,l,v), rel_return(p, ack):return(p,ack), rel_bad_arg(p):bad_arg(p), rel_get(p):get(p), rel_put(p):put(p), rel_noop: noop r(s A : rel_mem_states): mem_states = (# basic := (# pc := pc(s A ), loc := loc(s A ), val := val(s A ), performed := performed(s A ), memory := memory(s A ), legal := legal(s A ) #), now := now(s A ), first := (LAMBDA(a:mem_actions): zero), last := (LAMBDA(a:mem_actions): infinity) #)

24. 5 Strategy for Refinement Proofs Structure of refinement proofs : (refinement_strat) Expands and splits theorem into base case and induction step –Base case proved by skolemizing and expanding r and expanding tip_start and spec_start. –Induction step: Induct on the action name, this generates as many subgoals as there are actions For each visible action 2 new subgoals are generated –Corresponding visible action is enabled –Correspondence for the resulting post state For each invisible action prove either of the following –Equality –Correspondence If this does not complete the proof for a particular action then invariants are required, and the user will be prompted to choose the appropriate invariant

25. 5.1 Results RPC-MEM –Proof completes without any user assistance –Run time = 4.25 secs Real time 38.74 secs Can improve using rewrite instead of grind. Tip –Used invariant 15 and invariant 13 manually for the branch which required maximum work in the full manual proof.

26. 5.2 Summary Strategy for proving refinements. Two examples. –Rewrites instead of grind –Add comments –Careful back-tracking to handover the proof to the user in the best possible proof state –Another example Template theory for proving other abstractions using PVS theory interpretations and passing theories by name. Automatic generation of auxiliary theories. Learnt quite a bit about writing PVS strategies.

27. Future Work Strategies other structured proofs –Abstraction Proofs Simulation Proofs –Termination Proofs –Liveness (?) Porting the system to new and enhanced PVS Interface for HIOA

28. Thank you all very much. It has been a fun summer.. so far