Bundy, Alan

Grov, Gudmund

Lin, Yuhui

English

Proof automation is a common bottleneck for industrial adoption of formal methods. In Event-B, a significant proportion of proof obligations which require human interaction fall into a family called invariant preservation . In this paper we show that a rewriting technique called rippling can increase the automation of proofs in this family, and extend this technique by combining two existing approaches

Edinburgh Research Explorer

     Edinburgh Research Explorer                                      The Use of Rippling to Automate Event-B Invariant PreservationProofsCitation for published version:Lin, Y, Bundy, A & Grov, G 2012, 'The Use of Rippling to Automate Event-B Invariant Preservation Proofs'.in A Goodloe & S Person (eds), NASA Formal Methods: 4th International Symposium, NFM 2012, Norfolk,VA, USA, April 3-5, 2012. Proceedings. Lecture Notes in Computer Science, vol. 7226, Springer-VerlagGmbH, pp. 231-236., 10.1007/978-3-642-28891-3_23Digital Object Identifier (DOI):10.1007/978-3-642-28891-3_23Link:Link to publication record in Edinburgh Research ExplorerDocument Version:Preprint (usually an early version)Published In:NASA Formal MethodsGeneral rightsCopyright for the publications made accessible via the Edinburgh Research Explorer is retained by the author(s)and / or other copyright owners and it is a condition of accessing these publications that users recognise andabide by the legal requirements associated with these rights.Take down policyThe University of Edinburgh has made every reasonable effort to ensure that Edinburgh Research Explorercontent complies with UK legislation. If you believe that the public display of this file breaches copyright pleasecontact openaccess@ed.ac.uk providing details, and we will remove access to the work immediately andinvestigate your claim.Download date: 20. Feb. 2015The Use of Rippling to Automate Event-BInvariant Preservation ProofsYuhui Lin, Alan Bundy, and Gudmund GrovSchool of Informatics, University of Edinburgh, UKAbstract. Proof automation is a common bottleneck for industrial adop-tion of formal methods. In Event-B, a significant proportion of proofobligations which require human interaction fall into a family called in-variant preservation. In this paper we show that a rewriting techniquecalled rippling can increase the automation of proofs in this family, andextend this technique by combining two existing approaches.Keywords: Event-B, automated reasoning, rippling, lemma conjecture1 IntroductionEvent-B [2] is a “top-down” formal modelling method, which captures require-ments into an abstract formal specification and then stepwise refines the specifi-cation into the final product. In each step of development, designers justify thecorrectness of the specification by proving proof obligations (POs). The gener-ation of the POs is automated by the Rodin platform [3] which also containssupport for both automatic and interactive theorem proving. Most of these POscan be discharged automatically, yet still 3% to 10% of them require human in-teraction [8]. In an industrial sized project, this proportion of interactive proofscan be thousands. For example, 43,610 POs with 3.3% interactive proof in theRoissy Airport Shuttle project, and 27, 800 POs with 8.1% interactive proof inthe Paris Metro line 14 project [1]. Moreover, specifications often change fre-quently, which require users to reprove previous proven POs.Invariant preservation (INV) POs is a family of Event-B POs which can ac-count for a significant part of all of the POs that require human interaction.To illustrate, 188 out of 317 (59%) undischarged POs in the BepiColombo casestudy1 belong to the INV family.Here we argue that part of the problem is a lack of meta-level reasoningsince Rodin provers only work on the object level logic. In [5] it is argued that,to achieve a better understanding of reasoning, both logic and a meta-level un-derstanding should be put into consideration. In this paper we propose to usea meta-level reasoning technique, called rippling [6] for Event-B POs. It is arewriting technique which can be applied when the goal embeds in one of thehypothesis, and details are given in Sect. 2.2. Our hypothesis is1 The case study can be found in http://deploy-eprints.ecs.soton.ac.uk/136/By utilising rippling we can increase the automation of Event-B in-variant preservation proof obligations and make proofs more robust tochanges.The contributions of this paper are two-fold: (1) In Sect. 2 we illustratethe use of rippling for INV POs; (2) The key advantage of rippling is that,due to meta-level reasoning, we can often patch a broken proof, thus makingproofs more robust to changes. In Sect. 3 we describe a novel combination of twoexisting techniques, lemma speculation and scheme-based theory exploration, toconjecture lemmas when proofs are blocked by the absence of lemmas. Finally,we describe further work and conclude in Sect. 4 and Sect. 5, respectively.2 INV POs and Rippling2.1 INV POsanyswheres ∈ Subs ∧ s /∈ dom callthencall := call ∪ {(s 7→ (seize 7→ ∅))}endNotation Definitionx 7→ y denotes the pair (x, y)dom(r) {x|∃y.x 7→ y ∈ r}s⊳− r {x 7→ y|x 7→ y ∈ r ∧ x /∈ s}r ⊲ s {x 7→ y|x 7→ y ∈ r ∧ y ∈ s}r ⊳− s s ∪ (dom(s)⊳− r)r ; s {x 7→ y|∃z.x 7→ z ∈ r ∧ z 7→ y ∈ s}Fig. 1. An example of events & mathematical notionsMachines are key components of Event-B specifications. A machine containsvariables, invariant and events. Variables represent the states of the machine, andinvariants describe constraints on the states. INV POs are generated to guaran-tee that the invariants are still preserved under changes made by the events.To illustrate, let us consider the invariant (1)Callers = dom((call ; st)⊲ Connected) (1)in which Callers, call, st and Connected are variables. Figure 1 defines an eventin which s is an argument followed by a guard and an action, describing how thestate changes.An INV PO (2) is generated to ensure (1) holds under changes made in theevent.s ∈ Subs ∧ s /∈ dom call ∧ Callers = dom((call ; st)⊲ Connected)⊢Callers = dom((call ∪ {(s 7→ (seize 7→ ∅)))} ; st)⊲ Connected)(2)2.2 RipplingRippling2 is a rewriting technique which was developed originally for inductiveproofs. Although it was designed to guide the step cases of inductive proofs, itis applicable in any scenario where one of the assumptions can be embedded inthe goal. In the case of INV POs, the invariant is embedded in the goal, thusmaking rippling applicable. The embedding in the goal is called the skeleton,while the differences are the wave-front.To illustrate, let us recall the INV PO in Sect. 2.1. The annotated version ofthe goal (2) with the embedding (1), becomes:Callers = dom(( call ∪ {(s 7→ (seize 7→ ∅)))} ; st)⊲ Connected)in which the wave-fronts are shaded by a box. When applying a rewrite rule,the skeleton (i.e. the non-shaded part) in a goal should be preserved, and aripple measure must decrease, e.g. skeletons which are separated by wave-frontare moving together. Therefore, by applying(f ∪ g) ; S = (f ; S) ∪ (g ; S)we haveCallers = dom( ((call ; st) ∪ ({(s 7→ (seize 7→ ∅)))} ; st)) ⊲ Connected)With the following two rules(f ∪ g)⊲ S = (f ⊲ S) ∪ (g ⊲ S)dom(f ∪ g) = dom f ∪ dom gwe haveCallers = dom( (call ; st ⊲ Connected) ∪ ({(s 7→ (seize 7→ ∅)))} ; st)⊲ Connected )and finally get the INV PO toCallers = dom((call ; st) ⊲ Connected) ∪ dom(({(s 7→ (seize, ∅))} ; st) ⊲ Connected)Then the hypothesis (1) can be applied to simplify the proof by substitutingdom((call ; st)⊲ Connected) with Callers, which results inCallers = Callers ∪ dom(({(s 7→ (seize, ∅))} ; st)⊲ Connected)2 Rippling has been implemented in IsaPlanner which we use to start our experiments.For more details about IsaPlanner, please refer tohttp://dream.inf.ed.ac.uk/projects/isaplanner/This step of using the hypothesis is called fertilisation. Now as st projects thesecond first argument (e.g. (x 7→ (y 7→ z)) into (x 7→ y)) and Connected ={ringing, speech, suspended}, dom(({(s 7→ (seize, ∅))} ; st) ⊲ Connected) canbe trivially simplified into ∅ by using the assumptions in (2). This completesthe proof.The advantage of rippling is the meta-level guidance which can be used toguide the application of rewrite rules. Due to its lack of meta-level guidance,many rules3 can only be applied manually in Rodin. Let us consider the followingdistribution rule:(p ∪ q)⊳− r = (p⊳− r) ∪ (q ⊳− r)We can generate two rewrite rules from the left hand side (lhs) to the right handside (rhs) and the other way round. Rodin does not add both of them into itsrewriting system, because the rewriting may not terminate. However, due to themeta-level guidance of rippling, both directions can be added in rippling whilstguaranteeing termination. For example:From lhs to rhs : (p ∪ q) ⊳− r⇒ (p⊳− r ) ∪ (q ⊳− r)From rhs to lhs : (p ⊳− r) ∪ (q ⊳− r) ⇒ (p ∪ q )⊳− r3 IsaScheme and lemma conjectureThe key advantage of rippling is that the strong expectation of how the proofshould succeed can help us to build a proof patching mechanism when a proof isblocked, e.g. due to a missing lemma. It can contribute to proof automation andmakes proofs more robust to change. This mechanism is known as proof critics[7]. One useful critic in our case is lemma speculation [7]. It’s applicable whenproofs are blocked due to a missing lemma. Meta-level annotations are used toguide and construct the lemma being conjectured. Consider the following blockedrippling proof:Callers = dom( (call ⊳− x) ; st⊲ Connected)we construct the left hand side of the missing lemma with one of our wave-frontsand parts of skeletons, which is (call ⊳− x) ;st. With the skeleton preservationrule, we can construct the right hand side of the lemma by introducing a meta-variable ?F1 to represent the unknown part. Then we have(call ⊳− x) ; st = ?F1 call ; st x st3 For more rules, please refer tohttp://wiki.event-b.org/index.php/All_Rewrite_RulesThis meta-variable is stepwise instantiated by unification during the proof. Thisapproach is called middle-out reasoning [9]. However, higher-order unificationbrings a challenge for this approach.Therefore, instead of using middle-out reasoning, we propose a new approachby using IsaScheme[10] which is a scheme-based approach to instantiate thesemeta-variables, to generate the missing lemmas. Given a scheme and candidateterms and operations, IsaScheme can instantiate the meta-variables and returnlemmas that pass a counter-example checker. The scheme will help constrain thelemmas generated, and we can further filter out those that will not provide validripple steps. The following algorithm shows more details about how to constructa scheme and get the potential lemmas with the example showed in the begin-ning of this section.Precondition: When no rewriting rules are applicable and fertilisation can notbe applied, the following process can be triggered.1. Construct the lhs of the scheme with a wave-front and part of skeletons, i.e.(call ⊳− x) ; st = ...2. Since the skeleton has to be preserved and a ripple measure must decrease,we can partially predict how the term evolves on the rhs.i.e. evolve from (call ⊳− x) ; st to call ; st ⊳− ...Also we need to construct a term with meta-variables to specify the newshape of combination of the constants and variables in the wave-fronts, i.e.x, and those next to the wave-fronts in the skeleton, i.e. st. In our examplethis term would be (?F2 x st). Now we introduce meta-variables to combinethese terms to compose the rhs of the missing lemma, i.e.... = ?F1 (call ; st)(?F2 x st) .3. Now we have a scheme to instantiate. i.e.Myscheme ?F1 ?F2 ≡ (call ⊳− r) ; st = ?F1 (call ; st) (?F2 r st)in which Myscheme is the name of our scheme; ?F1 and ?F2 are meta-variables to be instantiated from a set of given terms. Then we try thisscheme in IsaScheme with relevant proof context, including assumptions.4. IsaScheme returns potential lemmas which we can apply to unblock thecurrent proof. In our example, we get the following lemma which can helpto proceed the proof4(call ⊳− r) ; st = (call ; st)⊳− (r ; st)4 Further workThese schemes are currently deduced manually, and next we plan to automatethis process. Moreover, we observe that many POs contain quantifiers and are4 This lemma relies on some properties of the specificationconditional. Rippling is not particularly suited for such POs, and to handle this,we are currently exploring integrating a technique called piecewise fertilisation[4] with rippling. Longer term we will develop a rippling plug-in for Rodin, whichwill be based on the existing Rodin to Isabelle translator by Schmalz5.5 ConclusionWe have showed that the use of rippling can improve the automation of proofsin Event-B INV POs and make it more robust to changes. We have combinedlemma speculation and scheme-based theory exploration to discovery the miss-ing lemma when proofs are blocked. This has to be done manually in Rodin.Moreover, with meta-level reasoning and its patching mechanism, the robust-ness of proofs can be improved, as the proof strategy remains the same even ifthe POs are required to be re-proven when specifications change.Acknowledgement: This work is supported by EPSRC grant EP/H024204/1(AI4FM). Thanks to Omar Montano Rivas, Andrew Ireland, Moa Johanssonand the AI4FM partners for the useful discussions.References1. Abrial, J.R.: Formal methods in industry: achievements, problems, future. In: Pro-ceedings of the 28th international conference on Software engineering. pp. 761–768.ACM (2006)2. Abrial, J.R.: Modeling in Event-B - System and Software Engineering. CambridgeUniversity Press (2010)3. Abrial, J.R., Butler, M.J., Hallerstede, S., Hoang, T.S., Mehta, F., Voisin, L.:Rodin: an open toolset for modelling and reasoning in event-B. STTT 12(6), 447–466 (2010)4. Armando, A., Smaill, A., Green, I.: Automatic synthesis of recursive programs:The proof-planning paradigm. Autom. Softw. Eng 6(4), 329–356 (1999)5. Bundy, A.: A science of reasoning. In: 10th International Conference on AutomatedDeduction. pp. 633–640. Springer (1990)6. Bundy, A.: Rippling: meta-level guidance for mathematical reasoning, vol. 56. Cam-bridge Univ Pr (2005)7. Ireland, A.: Productive use of failure in inductive proof. Journal of AutomatedReasoning 16(1–2), 79–111 (Mar 1996)8. Jones, C.B., Grov, G., Bundy, A.: Ideas for a high-level proof strategy language.Tech. Rep. CS-TR-1210, School of Computing Science, Newcastle University (2010)9. Kraan, I., Basin, D., Bundy, A.: Middle-out reasoning for synthesis and induction.Journal of Automated Reasoning 16(1), 113–145 (1996)10. Montano-Rivas, O., McCasland, R.L., Dixon, L., Bundy, A.: Scheme-based syn-thesis of inductive theories. In MICAI, LNCS vol. 6437, pp. 348–361. Springer(2010)5 See http://wiki.event-b.org/index.php/Export_to_Isabelle for details.

The Use of Rippling to Automate Event-B Invariant Preservation Proofs

Abstract

Similar works

Full text

Available Versions

Edinburgh Research Explorer