Bundy, Alan

Grov, Gudmund

Ireland, Andrew

Jones, Cliff B.

English

Edinburgh Research Explorer

     Edinburgh Research Explorer                                      The AI4FM approach for proof automation within formal methodsCitation for published version:Grov, G, Bundy, A, Jones, CB & Ireland, A 2010, 'The AI4FM approach for proof automation within formalmethods'. in UKCRC Grand Challenges in Computing Research (GCCR‘10).Link:Link to publication record in Edinburgh Research ExplorerDocument Version:Preprint (usually an early version)Published In:UKCRC Grand Challenges in Computing Research (GCCR‘10)General 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 AI4FM approach for proof automation within formalmethodsA Grand Challenge 6 “Dependable Systems Evolution" projectGudmund GrovSchool of InformaticsUniversity of Edinburghggrov@staffmail.ed.ac.ukAlan BundySchool of InformaticsUniversity of Edinburghbundy@staffmail.ed.ac.ukCliff B. JonesSchool of ComputingUniversity of Newcastlecliff.jones@ncl.ac.ukAndrew IrelandSchool of Mathematical &Computer SciencesHeriot-Watt UniversityA.Ireland@hw.ac.uk1. INTRODUCTIONWe are about to embark on a project (AI4FM) that willuse Artificial Intelligence (AI) to tackle a core issue for GC6(Dependable Systems Evolution).Achieving verified software has been a dream since the birthof computer science and the importance of this objective hasbecome ever greater with the increasing size and complex-ity of software.1 Grand Challenge 6 (GC6), “DependableSystems Evolution”, addresses this by advocating the use offormal methods for software development.2 The use of for-mal methods has been successful in safety-critical domains,like railway and aviation and is becoming increasingly pop-ular in other sectors (e.g. Microsoft use formal methods toverify device drivers). A recent paper by Woodcock et al.[7] analyses a large number of recent industrial applicationsof formal methods.Formal methods are applied post facto (bottom-up) or incorrectness by construction (top-down). Top-down methodstend to be “posit and prove” where a designer posits a stepof development and then seeks to justify it. Such justifica-tions generate proof obligations (POs) — putative lemmasthat need proof. Typically, a large proportion of POs canbe discharged by automatic theorem provers, but there arestill some that require user interaction. Discharging thesePOs can become a bottleneck in the use of formal methodsin practical applications. There are two approaches to deal-ing with the POs that require user interaction:3 (1) Follow amodelling strategy : change the model/abstraction to a strat-egy that simplifies the proofs, thus increasing the proportionof POs that are discharged automatically. (2) Follow a proof1We use the term software although the discussion here isvalid for any application of formal methods, i.e. to genericsystem modelling as well as software and hardware.2‘Formal methods’ use mathematics to specify, develop andreason about software and systems.3Note that the modelling and proof strategies are not mutu-ally exclusive. For example, the numbers quoted below mostlikely apply after several iterations of the original model.A proof strategy could still be applied after the modellingstrategy has reduced the numbers of undischarged POs.strategy : accept the challenging POs and define a strategyfor discharging them.It is the proof approach that we will take in our AI4FMproject. Our aim is to increase the repertoire of techniquesfor the proof-strategy approach by learning from proof at-tempts made by humans.The POs arising from formal methods tend to have differ-ent properties from “pure” mathematics. (1) There are of-ten large numbers of detailed POs. To illustrate, the ParisMetro Line 14 and the Roissy Airport shuttle system wereboth developed using formal methods; the former generated27, 800 POs (around 2, 250 interactive) while the latter gen-erated 43, 610 POs (around 1, 150 interactive) [1]. (2) POstend to be less deep, thus less proof effort is required fromthe user. (3) They are often “similar”, in the sense that theycan be grouped into “families” — and the same (high-level)proof approach can be successfully applied to all membersof the family.2. THE AI4FM APPROACHIn many cases where a (correct) PO is not discharged auto-matically, an expert can easily see how to complete a proof.By exploring the nature of the POs within formal meth-ods we believe that a higher degree of automation can beachieved by relying on expert intervention to do one proof,if this would enable a prover to discharge the others in thesame family. Specifically, we hope to build a tool that willlearn enough from one proof attempt to improve the chancesof proving “similar” results automatically. By “proof at-tempt” we include things like the steps explored by the user(not just the chain of steps in the final proof). Thus it iscentral to our goal that we find high-level strategies capableof cutting down the search space in proofs. Our hypothesisis:we believe that it is possible (to devise a high-level strategy language for proofs and) to extractstrategies from successful hand proofs that will fa-cilitate automatic proofs of related POs.To achieve our goal we plan to use many dimensions toanalyse the exemplar proof and the POs, e.g. by separatinginformation about data structures and approaches to dif-ferent patterns of POs. A proof (attempt) might be seento use “generalise induction hypothesis” (e.g. adding an ar-gument to accumulate values) in a specific proof about, say,sequences; a future use of the same PO might involve a morecomplicated tree data structure — but if it has an inductionrule, the same strategy might work. We would also expectto discover other dimensions, such as the domain of the PO(e.g. does it relate to trains or to railway tracks?).Designing a strategy language capable of capturing suchproperties (in an abstract form) is key to the success ofAI4FM. Evidence for the possibility of such strategy lan-guage is rippling [2] – its generality can be illustrated bythe domains to which it has been applied, e.g. verificationof functional, logical and imperative programs; synthesis oftheorems, programs and witnesses; correction of faulty spec-ifications and hardware verification. We believe that severalitems from rippling will play a major part in the design ofour strategy language:• Some “standard” proof plans and known devia-tions from and patches to them. [2] uses ripplingto describe a“standard”proof plan for inductive proofsand shows how each different pattern of failure in rip-pling suggests a different way of patching a failed proofattempt. We hypothesise that expert-provided proofsof undischarged POs will typically exhibit either a newproof plan or a new patch to an existing plan.• Choices of unusual induction rules and vari-ables, choices of loop invariants. Choosing analternative non-standard induction rule is one of thepatches to the standard induction proof plan which isdescribed in [2]; patching a failed loop invariant is thepatch described in [6].• Choices of intermediate lemmas. Designing, con-structing and proving a key intermediate lemma is an-other of the patches to the standard induction proofplan described in [2].• Generalisation of the PO. [2] also describes waysof generalising the PO or the current goal to patch afailed proof.3. CONCLUSIONAI4FM addresses proof automation for formal methods whichis a bottleneck for their (industrial) application. The targetof the project is to increase the overall proof automationwithin formal methods, thus increasing their applicability.Hence, it relates to any grand challenge where formal meth-ods are, or can be,4 applied. Thus, it is within the scopeof the existing computing Grand Challenge 6: “DependableSystems Evolution”.4Although formal methods have mainly been applied tosafety-critical domains, it has been argued that they are infact cheaper than conventional software development tech-niques. The argument is that bugs are detected earlier, thusreducing (much of) the need for testing and reworking.Of the proposed societal grand challenges, reliable softwareis at least crucial for security. Moreover, the formality andmathematical rigour of formal methods could have a roleto play when modelling and developing systems to supportassisted living and health.5Finally, note that the motivation for AI4FM has come fromactual industrial needs (in particular from industrial part-ners of the EU-funded Deploy project6). Our longer termhope is that it can help to stimulate other AI ideas for formalmethods. An example of this is [5], where AI is used to sug-gest changes to formal models from proof failures. For moredetails about the AI4FM project, please see www.ai4fm.organd [3, 4].AcknowledgementsThe initial work has been supported by the EPSRC PlatformGrants EP/E005713/1 The Integration and Interaction ofMultiple Mathematical Reasoning Processes and EP/E035329/1Trustworthy Ambient Systems (TrAmS). From April 2010,it will be supported by the EPSRC (EP/H024050/1,EP/H023852/1, EP/H024204/1) AI4FM: using AI to aidautomation of proof search in Formal Methods grant.4. REFERENCES[1] J.-R. Abrial. Formal methods: Theory becomingpractice. Journal of Universal Computer Science,13(5):619–628, 2007.[2] A. Bundy, D. Basin, D. Hutter, and A. Ireland.Rippling: Meta-level Guidance for MathematicalReasoning, volume 56 of Cambridge Tracts inTheoretical Computer Science. Cambridge UniversityPress, 2005.[3] A. Bundy, G. Grov, and C. B. Jones. Learning fromexperts to aid the automation of proof search. InL. O’Reilly and M. Roggenbach, editors, AVoCS’09 –PreProceedings of the Ninth International Workshop onAutomated Verification of Critical Systems, TechnicalReport of Computer Science CSR-2-2009, pages229–232. Swansea University, Wales, UK, 2009.[4] A. Bundy, G. Grov, and C. B. Jones. An outline of aproposed system that learns from experts how todischarge proof obligations automatically. InProceedings of Dagstuhl Seminar 09381: RefinementBased Methods for the Construction of DependableSystems, 2009.[5] A. Ireland, G. Grov, and M. Butler. ReasonedModelling Critics: Turning Failed Proofs intoModelling Guidance. In Proceedings of ABZ’10, number5977 in LNCS. Springer-Verlag, 2010.[6] J. Stark and A. Ireland. Invariant discovery via failedproof attempts. In P. Flener, editor, Logic-basedProgram Synthesis and Transformation, number 1559 inLNCS, pages 271–288. Springer-Verlag, 1998.[7] J. Woodcock, P. G. Larsen, J. Bicarregui, andJ. Fitzgerald. Formal Methods: Practice andExperience. ACM Computing Surveys, 41(4), Oct 2009.5If software is to be used to help people in their daily life,it should not make them do something that is potentiallydangerous.6See www.deploy-project.eu/

The AI4FM approach for proof automation within formal methods

Abstract

Similar works

Full text

Available Versions

Edinburgh Research Explorer