Certiable Pr ogram Generation Ewen Denne and Bernd Fischer USRARIA CS ASA Ames Research - PDF document

CertiableProgramGenerationEwenDenneyandBerndFischerUSRA/RIACS,NASAAmesResearchCenter,MoffettField,CA94035,USAfedenney,fischg@email.arc.nasa.govAbstract.Codegeneratorsbasedontemplateexpansiontechniquesareeasiertobuildthanpurelydeductivesystemsbutdonotguaranteethesamelevelofassurance:insteadofproviding“correctness-by-construction”,thecorrectnessofthegeneratedcodedependsonthecorrectnessofthegeneratoritself.Wepresentanalternativeassuranceapproach,inwhichthegeneratorisextendedtoenableHoare-stylesafetyproofsforeachindividualgeneratedprogram.Theproofsen-surethatthegeneratedcodedoesnot“gowrong”,i.e.,doesnotviolatecertainconditionsduringitsexecution.Thecrucialstepinthisapproachistoextendthegeneratorinsuchwaythatitpro-ducesallrequiredannotations(i.e.,pre-/postconditionsandloopinvariants)with-outcompromisingtheassuranceprovidedbythesubsequentvericationphase.Thisisachievedbyembeddingannotationtemplatesintothecodetemplates,whicharetheninstantiatedinparallelbythegenerator.Thisisfeasiblebecausethestructureofthegeneratedcodeandthepossiblesafetypropertiesareknownwhenthegeneratorisdeveloped.Itdoesnotcompromisetheprovidedassurancebecausetheannotationsonlyserveasauxiliarylemmasanderrorsintheannota-tiontemplatesultimatelyleadtounprovablesafetyobligations.WehaveimplementedthisapproachandintegrateditintotheAUTOBAYESandAUTOFILTERprogramgenerators.Wehavethenusedittofullyautomaticallyprovethatcodegeneratedbythetwosystemssatisesbothlanguage-specicpropertiessuchasarray-boundssafetyorpropervariableinitialization-before-useanddomain-specicpropertiessuchasvectornormalization,matrixsymmetry,orcorrectsensorinputusage.1IntroductionProgramgenerationhasasignicantpotentialtoimprovethesoftwaredevelopmentprocessandpromisesmanybenets,includinghigherproductivity,reducedturn-aroundtimes,increasedportability,andeliminationofmanualcodingerrors.However,thekeytorealizingthesebenetsisofcoursegeneratorcorrectness—nothingisgainedfromreplacingmanualcodingerrorswithautomaticcodingerrors.Moreover,followingthemotto“trustbutverify”thereshouldbesomemoreexplicitevidenceforthecorrectnessofthegeneratedcodethanjusttrustinthecorrectnessofthegeneratoritself,orashasbeenargued,“rigorousargumentsmustbeprovidedtodemonstratethecorrectnessofthetranslatorand/orthegeneratedcode”[WH99].Severalapproacheshavebeenexploredtoensureanddemonstratecorrectness.Indeductiveprogramsynthesis[SW+94,Kre98],theprogramisgeneratedasbyproductofanexistenceproofforatheoremderivedfromthespecication;otherapproachesbased onrenement[Smi90,BG+98]ortranslationverication[WB96]canoffersimilar“correct-by-construction”guarantees.However,codegeneratorsbasedontheseideasaredifculttobuildandtoscaleup,andhavenotfoundwidespreadapplication.Codegeneratorsthatarebasedontemplateexpansiontechniquesareeasiertobuildbutcancurrentlynotguaranteethesamelevelofassurance.Traditionally,theyareonlyvali-datedbytesting,whichrequiressignicanteffortthatcanquicklybecomeexcessive,inparticularforapplicationsinhigh-assurancedomainslikeaerospace.Forexample,theaerospacesoftwaredevelopmentstandardDO-178B[RTC92]mandatesthattheimple-mentationofthegeneratoristestedtothesamelevelofcriticalitythegeneratedcoderequires.Wearedevelopingandimplementinganalternativeapproachthatisnotbasedonthevericationorvalidationofthegeneratorbutinsteadfocusesonthesafetyofeachindividualgeneratedprogram.Ourcoreideaistoextendthegeneratoritselfsuchthatitproducesalllogicalannotations(i.e.,pre-/postconditionsandloopinvariants)thatarerequiredforformalsafetyproofsinaHoare-styleframework.Theseproofscertifythatthegeneratedcodedoesnot“gowrong”,i.e.,doesnotviolatecertainconditionsduringitsexecution.Thecrucialaspectoftheapproachistoensurethaterrorsintheoriginalcodegeneratororinthecerticationextensiondonotcompromisetheassurancepro-videdbythesubsequentvericationphase,or,inotherwords,thattheproofsarecorrectandactuallyprovethesafetypropertiesclaimed.WehaveintegratedthisapproachintotheprogramgeneratorsAUTOBAYES[FS03]andAUTOFILTER[WS04].Wehavethenusedittofullyautomaticallyprovethatcodegeneratedbythetwosystemssatisesbothlanguage-specicpropertiessuchasarray-boundssafetyorpropervariableinitialization-before-useanddomain-specicproper-tiessuchasvectornormalization,matrixsymmetry,orcorrectsensorinputusage.Thispapersummarizesourpreviousworkoncertiableprogramgeneration.Moredetailscanbefoundinthecitedreferences.2AUTOBAYESandAUTOFILTERAUTOBAYESandAUTOFILTERaretwodomain-specicprogramgeneratorsthatfol-lowaschema-basedapproachtocodegeneration.Thisextendsthe“plain”templateexpansiontechniquesbyaddingsemanticconstraintstothetemplates.AUTOBAYES[FS03]worksinthescienticdataanalysisdomainandgeneratesparameterlearningprograms,whileAUTOFILTER[WS04]generatesstateestimationcodebasedonvari-antsoftheKalmanlteralgorithm.Bothsystemssharealargecommoncore(e.g.,symbolicsubsystem,certicationsubsystem,andtargetcodegenerators)buthavetheirindividualschemalibraries.TheyareimplementedinSWI-Prologandtogethercom-priseapproximately100kLoC.Bothsystemsworkfullyautomaticallyandcangeneratecodeofconsiderablesizeandcomplexity(approximately1500LoCwithdeeplynestedloops)withinafewseconds.Schemas.Aschemacomprisesaparameterizedcodefragment(i.e.,template)to-getherwithasetofconstraintsthatdeterminewhethertheschemaisapplicableandhowtheparameterscanbeinstantiated.Theconstraintsareformulatedasconditionsonaproblemmodel,whichallowstheproblemstructuretodirectlyguidetheapplication oftheschemasandthusconstrainsthesearchspace.Theparametersareinstantiatedbythecodegenerator,eitherdirectlyonschemaapplicationorbyrecursivecallswithamodiedproblem.Theschemasareorganizedhierarchicallyintoaschemalibrarywhichfurtherconstrainsthesearchspace.Schemasrepresentbothfundamentalbuild-ingblocks(i.e.,algorithms)andsolutionmethods(i.e.,transformations)ofthedomain;theyarethussimilartothelemmasusedinpurelydeductivesystemsbuttheycancon-tainexplicitcallstoameta-programmingkernelinordertoconstructcode.SymbolicComputations.SymboliccomputationsareusedinAUTOBAYESandAUTOFILTERtosupportschemainstantiationandcodeoptimization.Thecoreofthesymbolicsubsystemisasmallrewriteenginewhichsupportsassociative-commutativeoperatorsandexplicitcontexts.Itthusallowsrulesasforexamplex=x!C`x6=01where!C`x6=0means“rewritesto,providedx6=0canbeprovenfromthecurrentcontextC.”Expressionsimplicationandsymbolicdifferentiationareimplementedontopoftherewriteengine.Thebasicrulesarestraightforward;however,vectorsandmatricesrequirecarefulformalizations,andsomerulesalsorequireexplicitmeta-programming,e.g.,whenboundvariablesareinvolved.IntermediateCode.Thecodefragmentsintheschemasareformulatedinanim-perativeintermediatelanguage.Thisisessentiallya“sanitized”variantofC(i.e.,nopointers,nosideeffectsinexpressionsetc.);however,italsocontainsanumberofdomain-specicconstructslikevector/matrixoperations,nitesums,andconvergence-loops.Optimization.Straightforwardschemainstantiationandcompositionproducessub-optimalcode;worse,manyofthesuboptimalitiescannotberemovedcompletelyusingaseparate,after-the-factoptimizationphase.Schemascanthusexplicitlytriggerlarge-scaleoptimizationswhichtakeintoaccountinformationfromthecodegenerationpro-cess.Forexample,allnumericroutinesrestructurethegoalexpressionusingcodemo-tion,commonsub-expressionelimination,andmemoization;sincetheschemasknowthegoalvariables,nodataowanalysisisrequiredtoidentifyinvariantsub-expressions,andcodecanbemovedaroundaggressively,evenacrossprocedureborders.TargetCodeGeneration.Inanalstep,theoptimizedintermediatecodeistrans-latedintocodetailoredforaspecicrun-timeenvironment.WecurrentlyhavetargetcodegeneratorsfortheOctaveandMatlabenvironments,andcanalsoproducestan-daloneAda,C,andModula-2code.Eachtargetcodegeneratoremploysonerewritesystemtoeliminatetheconstructsoftheintermediatelanguagewhicharenotsupportedbythetargetenvironment(“desugaring”)andasecondrewritesystemtocleanupthedesugaredcode;mostrulesaresharedbetweenthedifferentcodegenerators.ProblemSpecications.Schema-basedprogramgenerationdoesnotnecessarilyrequirealogicalconjectureasstartingpointforaproof.TheCodederivationcanthere-forebeginwithaspecicationinamoreapplication-orienteddomain-speciclanguage.Ourspecicationlanguagescombinesometargetlanguageconstructs(e.g.,declara-tions)withestablishedscienticandengineeringnotations(e.g.,differentialequations).Thisallowsaconciseandfullydeclarativeformulationoftheproblemtogetherwithsomedetailsofthedesiredcongurationandarchitectureofthecodetobegener-ated.AUTOBAYESusesaspecicationlanguagethatisveryclosetothegenerative statisticalmodelsusedinBayesianstatistics,whileAUTOFILTERusesamorecontrolengineering-orientednotationtoformulateprocessmodels.3CerticationArchitectureOurcerticationapproachgenerallyfollowssimilarlinesasproofcarryingcode(PCC)[Nec97];inparticular,theroleoftheextendedcodegeneratorasproducerofannotatedtargetcodeisverysimilartothatofacertifyingcompiler[NL98,CL+00]inthePCCapproach.However,therearealsosomekeydifferences.First,sincewetargetcodegen-erationinsteadofcompilation,weworkonthesourcecodelevelinsteadoftheobjectcodelevel.Onthepositiveside,sincesomesafetypropertiescanbeformulatedmorenaturally(e.g.,initialization-before-use)oronly(e.g.,loopvariablerestrictions)onthesourcecodelevel,thisallowsustoformulateandsupportmoresafetypropertiesrel-evanttoapplicationdomains.Inparticular,high-leveldomain-specicpropertiessuchasmatrixsymmetryorframesafety[LPR01]areinherentlydenedonthesourcecodelevel.Onthenegativeside,thesedomain-specicpropertiesmaketheannotationgen-eration(seeSection5)moredifcult.Fortunately,unlikeageneralpurposecompiler,adomain-speciccodegeneratorembodiesenoughdomainknowledgetoprovidetheinformationrequired.Second,theproofsarenottightlyintegratedintothecodeandarecurrentlynotevendistributedtogetherwiththecode;hence,ourapproachprovidescer-tiableratherthancertifyingprogramgeneration.However,thisisnotafundamentaldecitandcouldbechangedrelativelystraightforwardly,ifnecessary.Third,weapplyadifferentprovertechnologyandourarchitectureallowschoosingfromdifferentoff-the-shelffullyautomatedtheoremprovers(ATP)forrst-orderlogicinsteadofrelyingonacustomizedhigher-ordersystem.However,theATPcanessentiallybeconsideredasablackbox.codetheoryVCGsimplifierATPcheckerproofdomainannotated codetrusteduntrustedcertificateproofsVCsaxioms / lemmascertificationextensionproofsrewriterulesspec.problemsafetypolicyVCsgeneratorcodecertifiable code generation systemFig.1.Certiableprogramgeneration:Systemarchitecture Figure1showstheoverallarchitectureofacertiableprogramgenerationsystem.Atitscoreistheoriginalcodegeneratorwhichisextendedforcerticationpurposesandcomplementedbyavericationconditiongenerator(VCG),asimplier,anATP,aproofchecker,andadomaintheory.Thesecomponentsandtheirinteractionsarede-scribedintherestofthispaperandinmoredetailin[WSF02,DF03,DFS05].AsinthePCCapproach,thearchitecturedistinguishesbetweentrustedanduntrustedcompo-nents,showninFigure1inred(darkgrey)andblue(lightgrey),respectively.Trustedcomponentsmustbecorrectbecauseanyerrorsinthemcancompromisetheassuranceprovidedbytheoverallsystem.Untrustedcomponents,ontheotherhand,arenotcru-cialtotheassurancebecausetheirresultsaredouble-checkedbyatleastonetrustedcomponent.Inparticular,theassuranceprovidedbyacertiableprogramgenerationsystemdoesnotdependonthecorrectnessofitstwolargestcomponents:theoriginalcodegenerator(includingthecerticationextensions),andtheATP;instead,weneedonlytrustthesafetypolicy,theVCG,thedomaintheory,andtheproofchecker.4Source-LevelSafetyCerticationThepurposeofsafetycerticationistodemonstratethatthecodedoesnotviolatecer-tainconditionsduringitsexecution.Asafetypropertyisanexactcharacterizationoftheseconditionsbasedontheoperationalsemanticsofthelanguage.Itisformallyde-nedasanentailmentrelationthatformalizeswhentheevaluationofanexpressionandtheexecutionofastatementaresafeinagivenenvironment.Asafetypolicyisasetofproofrulesandauxiliarydenitionswhicharedesignedtoshowthatsafeprogramssatisfythesafetypropertyofinterest.Theintentionisthatasafetypolicyenforcesaparticularsafetypropertyandstrictlyspeakinganoff-lineproofisrequiredtoshowthepolicycorrectwithrespecttotheproperty[DF03].Sincethecalculusissoundandcomplete(modulothecompletenessofthelogicunderlyingtheformulationoftheanno-tations),itdoesinparticularpreventusfromprovingunsafeprogramssafe.TheproofrulescanbeformalizedconciselyusingtheusualHoaretriplesPfcgQ,i.e.,iftheconditionPholdsbeforeandthecommandcterminates,thenQholdsafterwards(see[Mit96]formoreinformationaboutHoare-styleprogramproofs).Foreachnotionofsafetywhichisofinterestasafetypropertyandthecorrespond-ingsafetypolicyneedbeformulated.Theformulationofthesafetypropertyisusu-allystraightforward,andtheproofrulesforanygivensafetypolicycanfortunatelybeconstructedsystematically,byinstantiatingagenericrulesetthatisderivedfromthestandardrulesoftheHoare-calculus[DF03].Thebasicideaistoextendthestandardenvironmentofprogramvariableswitha“safetyenvironment”of“safety”or“shadow”variableswhichrecordsafetyinformationrelatedtothecorrespondingprogramvari-able.Therulesarethenresponsibleformaintainingthisenvironmentandproducingtheappropriatesafetyobligations.Figure2showstherulesinstantiatedfortherelativelysimplecaseofmemorysafety.Herethesafetyenvironmentconsistsofshadowvariablesxhithatareusedtorecordthedimensionofthecorrespondingarraysx.Theonlystatementthataffectsthevalueofashadowvariableisthusthedeclarationofanarray(cf.theadecl-rule).However,allrulesalsoneedtoproducetheappropriatesafetyformulassafemem(e)forallimmediate subexpressionseofthestatements.Sincethesafetypropertydenesthatanexpressionissafeifallaccesstoarrayvariablesarewithintheboundsgivenbythecorrespondingshadowvariables,safemem(x[e])forexamplesimplytranslatesto1exhi.(decl)QfvarxgQ(adecl)Q[n=xhi]fvarx[n]gQ(skip)QfskipgQ(assign)Q[e=x]^safemem(e)fx:=egQ(update)Q[upd(x;e1;e2)=x]^safemem(x[e1])^safemem(e2)fx[e1]:=e2gQ(if)P1fc1gQP2fc2gQ(b)P1)^(:b)P2)^safemem(b)fifbthenc1elsec2gQ(while)PfcgII^b)PI^:b)QI^safemem(b)fwhilebinvIdocgQ(for)PfcgI[i+1=i]I^e1ie2)PI[e2+1=i])QI[e1=i]^safemem(e1)^safemem(e2)ffori:=e1toe2invIdocgQ(comp)Pfc1gRRfc2gQPfc1;c2gQ(assert)P)P0PfcgQ0Q0)QPfpreP0cpostQ0gQ(cons)P)P0P0fcgQ0Q0)QPfcgQFig.2.ProofrulesformemorysafetyWehavedenedvedifferentsafetypropertiesandimplementedthecorrespondingsafetypolicies.Array-boundssafety(array)requireseachaccesstoanarrayelementtobewithinthespeciedupperandlowerboundsofthearray.Variableinitialization-before-use(init)ensuresthateachvariableorindividualarrayelementhasbeenexplic-itlyassignedavaluebeforeitisused.Botharetypicalexamplesoflanguage-specicproperties.Matrixsymmetry(symm)requirescertaintwo-dimensionalarraystobesym-metric.Sensorinputusage(inuse)isavariationofthegeneralinit-propertywhichguar-anteesthateachsensorreadingpassedasaninputtotheKalmanlteralgorithmisactuallyusedduringthecomputationoftheoutputestimate.ThesetwoexamplesarespecictotheKalmanlterdomain.Thenalexample(norm)ensuresthatcertainone- dimensionalarraysrepresentnormalizedvectors,i.e.,thattheircontentsadduptoone;itisspecictothedataanalysisdomain.TheVCGdirectlyimplementsthegenericrulesand,startingwiththeinitialpost-conditiontrue,appliesthemtothestatementsintheusualbackwardsstyle,emittingtheconstructedsafetyobligationsalongtheway.Sinceitispartofthetrustedcompo-nentbase,ithasbeendesignedtobe“correct-by-inspection”,i.e.,deliberatelysimple.Hence,itdoesnotimplementanyoptimizationsorevenapplyanysimplications.Con-sequently,thegeneratedobligationstendtobelargeandmustbesimpliedseparatelybeforetheycanbetackledbytheATP.TheresultingproofscanbesenttoaproofcheckertoensurethattheATPproducedavalidproof.5AnnotationGenerationAsFigure2shows,theproofrulesrequirelogicalannotations,inparticularloopinvari-ants.TheconstructionoftheseannotationsisusuallythelimitingfactorforthepracticalapplicationofHoare-stylevericationtools,e.g.,ESC[FL+02].Fortunately,theanno-tationsareuntrusted.TheyareneverdirectlyusedassafetyobligationsthemselvesbutonlyserveaslemmasforusebythetrustedVCG.Duetothesoundnessofthecalcu-lus,anerrorinanannotationcan,atworst,leadtotheconstructionofaninvalidsafetyobligation.Asanexample,considerthewhile-rule.IftheconstructedinvariantIistoostrong(e.g.,Ifalse),thenitiseasytoshowthatthepostconditionQfollowsbutimpossibletoshowthatthepreconditionPconstructedfromtheloopbodycholds.Iftheinvariantistooweak(e.g.,Itrue),thenitwillgenerallybeimpossibletoshowthateitherthepreconditionorthepostconditionfollows,unlessofcoursetheprogramistriviallysafe.Similarargumentsholdfortheotherrulesaswell.Evencompatible“parallel”errorsinthegenerationofthecodeandtheannotationswillnotcompromisetheassurance.Intheworstcase,thegeneratedcodewillbefunctionallywrongbutiftheproofsucceeds,itwillstillexecutesafely.Thisroleoftheannotationsthusallowsustoextendtheuntrustedcodegeneratortoproducebothcodeandannotations,withoutcompromisingtheassuranceprovidedbythesafetyproofs.Thecentralquestionthoughishowthiscanbeachieved.Obviously,thereisnofreelunch,andultimatelytheannotationshavetobeprovidedbythedeveloper.Thiscanbedoneintheformofannotationtemplatesthatareintegratedintotheschemasandinstantiatedinparallelwiththecodetemplatesbythegenerator.Thebasicprocesstoextendthegeneratorcomprisesthefollowingfoursteps:1.Analyzethegeneratedcodeandidentifythelocationandstructureoftherequiredannotations.2.Foreachlocation,identifytheschemasthatproducedtherespectivecodefragment.3.Foreachaffectedschema,generalizetherespectiveannotationstoappropriatemeta-annotations(e.g.,replaceprogramvariablesbymetavariables).4.Foreachmeta-annotation,formulateanappropriateannotationtemplateormeta-programthatgeneratestheannotationatthetimeofschemaapplication,andinte-grateitintotheschema.Likebuildingthegeneratorintherstplace,thisanexpensivemanualprocess.Ithastoberepeateduntilallschemasarecovered,andstartedagainforeachnewsafety property.Moreover,theannotationsarecross-cuttingconcerns,notonlyonthelevelofthegeneratedprograms,butalsoontheleveloftheprogramgenerator.Thiscanmaketheextensionofthegeneratorquitehardwork.However,itremainsfeasiblebecausetheoverallstructureandthepurposeofthegeneratedcodeaswellasthepossiblesafetypropertiesarealreadyknownwhenthegeneratorisextended.


vara[n];varb[m]


/*A:*/fori:=1toninv8j
1ji)1a[j]mdoa[i]:=f(i);post8i
1in)1a[i]m


/*B:*/fori:=1toninv1a[i]mdob[a[i]]:=g(i);


Fig.3.CodefragmentwithannotationsThecodefragmentshowninFigure3,whichistakeninsimpliedformfromcodegeneratedbyAUTOBAYES,illustrateshowtheprocessworks.ItusestheloopatAtoinitializethearrayawithanunspeciedexpressionf(i),andthenusesainthesecondloopatBtowritethealsounspeciedexpressiong(i)indirectlyintob.Inordertoprovethesearrayaccessessafe,theinvariantneedstorestrictthecontentsofthea-elementstothevalidindexrangeofb,i.e.,a[i]hastobebetween1andm.Thequestionisnowhowandwheretoconstructthisinvariant.However,whenwewritetheschemathatgeneratestherstloop,wealsoalreadyknowthatthea-elementswillbeusedtoindexintob.Thisispartofthedomainknowledgethatisrequiredtobuildtheoriginalcodegenerator.Inarststep,wethusextendthisschemabyanannotationtemplateormeta-programthatconstructsthe(local)invariantandpostconditiongivenatA.Theannotationtemplatecanfocusonthelocallyrelevantinformation,withoutneedingtodescribealltheglobalinformationthatmaylaterbenecessaryfortheproofsbecausetheschemasarenotcombinedarbitrarilybutonlyalongthehierarchygivenintheschemalibrary.Unfortunately,theselocalannotationsareingeneralstillinsufcienttoprovethepostconditionattheendoflargercodefragments.Inourexample,westillneedtogettheinformationaboutthevaluesinaintotheloopinvariantatB.Sincethislimitedinformationtransportisarecurrentproblem,wedonotpassaroundtheconstructedannotationsduringgeneration,butrelyonaseparateannotationpropagationphaseaf-terthecodehasbeenconstructed.Thepropagationalgorithmcanbeseenasaverycrudeapproximationofastrongestpostconditionpredicatetransformer.Itpushesthegeneratedlocalannotationsforwardalongtheedgesofthesyntaxtreeaslongasthe informationcanbeguaranteedtoremainunchanged.Becausethegeneratorproducescodewithrestrictedaliasingonly,thetestforwhichstatementsinuencewhichanno-tationscaneasilybeaccomplishedwithoutafullstaticanalysisbymaintainingasetofmodiedvariablesduringpropagation.Thepropagationphasealsoaddsafewdefaultannotationsasittraversesthecode,forexampleboundsontheloopvariables.ThesecouldinprinciplealsobereconstructedbytheVCG,butthatwouldcomplicatedtheimplementationofthetrustedVCG.ThefullyannotatedandpropagatedcodeisthenusedbytheVCG.6ExperimentalResultsWehaveusedtheapproachdescribedheretocertifydifferentsafetypropertiesforcodegeneratedbyAUTOBAYESandAUTOFILTER.Table1summarizestherelevantnum-bersforfourrepresentativeexamples.ThersttwoexamplesareAUTOFILTERspec-ications.ds1istakenfromtheattitudecontrolsystemofNASA'sDeepSpaceOnemission[WS04].issspeciesacomponentinasimulationenvironmentfortheSpaceShuttledockingprocedureattheInternationalSpaceStation.Inbothcases,thegen-eratedcodeisbasedonKalmanlteralgorithms,whichmakeextensiveuseofmatrixoperations.TheothertwoexamplesareAUTOBAYESspecicationswhicharepartofamorecomprehensiveanalysis[FH+03]ofplanetarynebulaimagestakenbytheHubbleSpaceTelescope.segmdescribesanimagesegmentationproblemforwhichaniterativenumericalclusteringalgorithmissynthesized.Finally,gausstsanimageagainstatwo-dimensionalGaussiancurve.Thisrequiresamultivariateoptimizationwhichisim-plementedbytheNelder-Meadsimplexmethod.Thecodegeneratedforthesetwoex-ampleshasasubstantiallydifferentstructurefromthestateestimationexamples.First,itcontainsmanydeeplynestedloops,andsomeofthemdonothaveaxed(i.e.,knownatgenerationtime)numberofiterationsbutareexecuteduntiladynamicallycalculatederrorvaluebecomessmallenough.Incontrast,intheKalmanltercode,allloopsareexecutedaxednumberoftimes.Second,allarrayaccessesareelementbyelementandtherearenooperationsonentirematrices(e.g.,matrixmultiplication).Foreachoftheexamples,Table1liststhesizejSjofthespecication,thesizejPjofthegeneratedprogram(includingcommentsbutwithoutannotations),theapplicablesafetypolicies,thesizesjAjandjAjofthegeneratedandpropagatedannotations,andnallythenumbersNandNfailofgeneratedandinvalidsafetyobligationsaswellasthegenerationandprooftimesTgenandTproof.Alltimesarewall-clocktimesroundedtothenextsecondandwereobtainedona2.4GHzstandardLinuxPCwith4GBmemory.Thegenerationtimesalsoincludegeneration,simplication,andleoutputofthesafetyobligations;codegenerationaloneaccountsforapproximately90%ofthetimeslistedunderthearraysafetypolicy.TheprooftimesarebasedonusingtheE-Setheo[MI+97]proverwhichwasabletodischargeallvalidobligations;theydonotincludethetimespentontheinvalidobligations.AmoredetailedanalysisoftheresultsachievedwithdifferentATPsisavailablein[DFS05].Thetableshowsthatthegeneratedannotationscanamounttoasignicantfrac-tionofthegeneratedcodeand,afterpropagation,canevendominateit.Italsoshowssubstantialdifferencesinthesizeoftheannotationsrequiredforthedifferentsafety ExamplejSjjPjPolicyjAjjAjNNfailTgenTproofds148431array0191-61init8744474-1184inuse614132118202symm75261865-71794iss97755array0194-253init8845871-4088inuse603611132-symm87274480-66510segm17517array0531-31init1711090121-8109norm19524714-412gauss181039array2050520-2116init1181615316-54259Table1.Resultsofsafetycerticationproperties;inparticular,italsoshowsthatarray-boundssafety(whichisthecoreprop-ertyguaranteedbyPCC)requiresalmostnolocalannotationsandcanoftenbecertiedwithonlythedefaultannotationsaddedbythepropagator.Thenumberofgeneratedsafetyobligationsalsovariessubstantiallyforthedifferentsafetyproperties.However,theproofeffortremainstractable,andinmostofthecasestheATPwasabletosuccess-fullydischargeallobligationsinlessthan15minuteswallclocktime.Ingeneral,ofcourse,anobligationcanfailtobeprovenforanumberofreasons.First,theremayofcoursebeanactualsafetyviolationinthecode.Thisisthecaseforthetwoinvalidobligationsthatareproducedforthesensorinputusageproperty.Thedeeperreasonforthis,however,isnotaawinthecodegeneratorbutasloppyspecicationthatdeclaresavectorthatisnotcompletelyused.Second,the(generated)annotationsmaybeinsufcientorwrong.Annotationerrorscancomefromanypartoftheschema,orfromthepropagationphase:anannotationmightnotbepropagatedfarenough,oritmightbepropagatedoutofscope.Third,thetheoremprovermaytime-out,eitherduetothesizeandcomplexityoftheobligation,orduetoanincompletedomaintheory.Forcerticationpurposes,however,itisimportanttodistinguishbetweenunsafeprogramsandanyotherreasonsforfailure,andinthecaseofgenuinesafetyviolations,tolocatetheunsafepartsoftheprogram.7ConclusionsWehavedescribedanextensiontotheAUTOBAYESandAUTOFILTERprogramgener-atorswhichcanautomaticallyensureimportantsafetypropertiesforthegeneratedcode.Thecoreideaofourapproachistoextendthegeneratoritselfinsuchwaythatitpro-ducesalllogicalannotations(i.e.,pre-/postconditionsandloopinvariants)requiredforHoare-stylesafetyproofswithoutcompromisingtheassuranceprovidedbytheproofs.Inprinciple,theprovercanfailtoprovesomevalidproofobligationsandthusraisefalse alarmsbutinpracticewewereabletodesignthesystemsuchthatallvalidobligationscouldbedischargedfullyautomatically.Ourapproachcanbeseenas“PCCforcodegenerators”becauseitenablessafetyproofsforthegeneratedcode.Webelievethatitcandirectlybeappliedtocodegener-atorsbasedontemplateexpansiontechniquesingeneral,notonlytoourownsystems.However,webelievealsothatourtechniquescouldaswellbeusedinaresponsetotherecentlyannouncedGrandChallengeofdevelopingaverifyingcompiler.Wefurtherbelievethatinprincipleanyvericationtechniquethatcanbeguidedbyanappropri-ateformofannotationscanbecombinedsuccessfullywithacertiablecodegenerator,notjusttheHoare-stylecerticationusingtheVCG/ATPcombinationdescribedhere.Anotherinterestingresearchdirectionwouldthusbetocombineannotationgenerationwithothertechniques,forexamplestaticanalysis.Forfuturework,weplantoextendthesystemintwomainareas,inadditiontocontinuallyincreasingthesystems'generativepowerwithmorealgorithmicschemas,morespecicationfeatures,andmorecontroloverthederivation.First,wearedevelopingamoredeclarativeandexplicitmodelingstyle.Muchofthedomainknowledgeusedbythesysteminderivingcodeiscurrentlyimplicit;bymakingitexplicitthiscanbeusedto(amongotherthings)facilitatetraceabilitybetweenthecodeanditderivationinthegenerateddocumentation.Second,wecontinuetoextendthecerticationpowerofthesystemwithmorepoli-cies,moreautomation,andanintegratedapproachtodocumentationgeneration.Inpar-ticular,wearenowdevelopingan“annotationinference”techniquewhichaddressesmanyofthedifcultiesofannotationgeneration.Thiswillalsoenableustoeasilyap-plyourcerticationtechniquestocodegeneratorsotherthanourown.Acknowledgements.MikeWhalenandJohannSchumanncontributedsubstantiallytothedevel-opmentandimplementationofthecertiableprogramgenerationapproach.References[BG+98]L.Blaine,L.-M.Gilham,J.Liu,D.R.Smith,andS.Westfold.“Planware–Domain-SpecicSynthesisofHigh-PerformanceSchedulers”.InD.F.RedmilesandB.Nuseibeh,(eds.),Proc.13thIntl.Conf.AutomatedSoftwareEngineering,pp.270–280.IEEEComp.Soc.Press,1998.[CL+00]C.Colby,P.Lee,G.C.Necula,F.Blau,M.Plesko,andK.Cline.“AcertifyingcompilerforJava”.InProc.ACMConf.ProgrammingLanguageDesignandImplementation2000,pp.95–107.ACMPress,2000.PublishedasSIGPLANNotices35(5).[DF03]E.DenneyandB.Fischer.“CorrectnessofSource-LevelSafetyPolicies”.InK.Araki,S.Gnesi,andD.Mandrioli,(eds.),Proc.FM2003:FormalMethods,Lect.NotesComp.Sci.2805,pp.894–913.Springer,2003.[DFS05]E.Denney,B.Fischer,andJ.Schumann.“AnEmpiricalEvaluationofAutomatedTheoremProversinSoftwareCertication”.InternationalJournalofAITools,2005.Toappear.[FH+03]B.Fischer,A.Hajian,K.Knuth,andJ.Schumann.“AutomaticDerivationofStatisticalDataAnalysisAlgorithms:PlanetaryNebulaeandBeyond”.InG.EricksonandY.Zhai,(eds.),Proc.23rdIntl.WorkshoponBayesianInferenceandMaximumEntropyMethodsinScienceandEngineering,pp.276–291.AmericanInstituteofPhysics,2003. [FL+02]C.Flanagan,K.R.M.Leino,M.Lillibridge,G.Nelson,J.B.Saxe,andR.Stata.“ExtendedstaticcheckingforJava”.InL.J.Hendren,(ed.),Proc.ACMConf.ProgrammingLanguageDesignandImplementation2002,pp.234–245.ACMPress,2002.PublishedasSIGPLANNotices37(5).[FS03]B.FischerandJ.Schumann.“AutoBayes:ASystemforGeneratingDataAnalysisPro-gramsfromStatisticalModels”.J.FunctionalProgramming,13(3):483–508,2003.[Kre98]C.Kreitz.“ProgramSynthesis”.InW.BibelandP.H.Schmitt,(eds.),AutomatedDeduction—ABasisforApplications,pp.105–134.Kluwer,1998.[LPR01]M.Lowry,T.Pressburger,andG.Rosu.“CertifyingDomain-SpecicPolicies”.InM.S.FeatherandM.Goedicke,(eds.),Proc.16thIntl.Conf.AutomatedSoftwareEngineering,pp.118–125.IEEEComp.Soc.Press,2001.[MI+97]M.Moser,O.Ibens,R.Letz,J.Steinbach,C.Goller,J.Schumann,andK.Mayr.“TheModelEliminationProversSETHEOandE-SETHEO”.J.AutomatedReasoning,18:237–246,1997.[Mit96]J.C.Mitchell.FoundationsforProgrammingLanguages.MITPress,1996.[Nec97]G.C.Necula.“Proof-CarryingCode”.InProc.24thACMSymp.PrinciplesofPro-grammingLanguages,pp.106–19.ACMPress,1997.[NL98]G.C.NeculaandP.Lee.“TheDesignandImplementationofaCertifyingCompiler”.InK.D.Cooper,(ed.),Proc.ACMConf.ProgrammingLanguageDesignandImplementation1998,pp.333–344.ACMPress,1998.PublishedasSIGPLANNotices33(5).[RTC92]RTCASpecialCommittee167.SoftwareConsiderationsinAirborneSystemsandEquipmentCertication.Technicalreport,RTCA,Inc.,December1992.[Smi90]D.R.Smith.“KIDS:ASemi-AutomaticProgramDevelopmentSystem”.IEEETrans.SoftwareEngineering,16(9):1024–1043,1990.[SW+94]M.Stickel,R.Waldinger,M.Lowry,T.Pressburger,andI.Underwood.“DeductiveCompositionofAstronomicalSoftwarefromSubroutineLibraries”.InA.Bundy,(ed.),Proc.12thIntl.Conf.AutomatedDeduction,Lect.NotesArticialIntelligence814,pp.341–355.Springer,1994.[WB96]V.L.WinterandJ.M.Boyle.“ProvingRenementTransformationsforDerivingHigh-AssuranceSoftware”.InProc.High-AssuranceSystemsEngineeringWorkshop,pp.68–77.IEEEComp.Soc.Press,1996.[WH99]M.WhalenandM.Heimdahl.“OntheRequirementsofHigh-IntegrityCodeGenera-tion”.InProc.4thIntl.Symp.High-AssuranceSystemsEngineering,pp.216–226.IEEEComp.Soc.Press,1999.[WS04]J.WhittleandJ.Schumann.“AutomatingtheImplementationofKalmanFilterAlgo-rithms”.ACMTransactionsonMathematicalSoftware,30(4):434–453,2004.[WSF02]M.Whalen,J.Schumann,andB.Fischer.“SynthesizingCertiedCode”.InL.-H.ErikssonandP.A.Lindsay,(eds.),Proc.Intl.Symp.FormalMethodsEurope2002:FormalMethods—GettingITRight,Lect.NotesComp.Sci.2391,pp.431–450.Springer,2002.