amphion/nav: deductive synthesis of state estimation software · 2008-06-05 · amphion/nav:...

Amphion/NAV: Deductive Synthesis of State Estimation Software

JonWhittle Jeffrey VanBaalen JohannSchumannPeterRobinson TomPressburger JohnPenixPhil Oh MichaelLowry GuillaumeBrat

ASEGroup:NASA, QSS,RIACS,KestrelTech.,U. WyomingNASA AmesResearchCenter, Moffett Field,CA 94035

1 Introduction

Previous work on domain-specificdeductive programsynthesis[8, 9] describedthe Amphion/NAIF systemforgeneratingFortrancodefromhigh-levelgraphicalspecifica-tionsdescribingproblemsin spacesystemgeometry. Am-phion/NAIF specificationsdescribeinput-outputfunctionsthat computegeometricquantities(e.g., the distancebe-tweentwo planetsat a point in time, or the time whenaradiocommunicationpathbetweenaspacecraftandearthisoccluded)by composingtogetherFortransubroutinesfromthe NAIF subroutinelibrary developedat the Jet Propul-sion Laboratory. In essence,Amphion/NAIF synthesizescodefor glueingtogetherthe NAIF componentsin a waysuchthat the generatedcodeimplementsthe specification,with a concurrentlygeneratedproof that this implementa-tion is correct.Amphion/NAIF demonstratedthesuccessofdomain-specificdeductive programsynthesisandis still inusetodaywithin thespacesciencecommunity. However, anumberof questionsremainedopenthatwe will attempttoanswerin thisshortpaper, namely:

� Can the deductive synthesisstrategy be extendedfrom thegenerationof input-outputfunctionsto itera-tive, imperativeprogramswithout incurringthecom-putationalcomplexity penaltiesentailedby mostthe-oreticaltreatmentsof theformalderivationof imper-ativesystems?

� Can the methodologyfor developing an Amphion-like programsynthesissystembe usedin other do-mains,particularlywherea well-definedcomponentlibrary doesnotalreadyexist?

� Can the development of Amphion-like domain-specificprogramsynthesissystemsbe modularized,with substantialreuseat theintersectionof domains?

� How can the mechanizedproof of implementationcorrectnessbe usedin the softwareprocessby end-usersunfamiliarwith formalmethods?

In order to investigatethesequestions,we developedAmphion for a new, much richer domain,namelyGuid-ance,Navigation & Control (GN&C) algorithms,in par-ticular single-modegeometricstateestimationsoftwareforaerospacevehicles.AMPHION/NAV generatescodefor in-tegratinga modelof thevehicledynamicswith a temporalstreamof datafrom multiplesensorsourcesin astatisticallyoptimalwayusingoneormoreKalmanfilters[1, 3]. GN&Calgorithmsareoftencomplex, involving iterativeloopalgo-rithms and real-timeconsiderationssuchas extrapolatingsensordataso that datais integratedat the samepoint intime. Althoughtherearestandardcomponentsavailableforthis domain(e.g.,matrix manipulations,Kalmanfilter al-gorithms),thereis no easilydefinedsetof componentsthatcover thedomainfully.

AMPHION/NAV incorporatesthe Amphion/NAIF do-main theory as one componentin a much larger domaintheory, demonstratinga form of theoryreuse.In particular,theAmphion/NAIF domaintheoryprovidestheformulationof thegeometricconcepts.AMPHION/NAV is alsoanup-gradedversionof thesamearchitectureasAmphion/NAIF,andthusdemonstratesreusabilityacrossa numberof com-ponentsincluding the specificationinterface and the de-ductionengine.AMPHION/NAV incorporatesanenhancedback-endcodegeneratorsuitablefor iterativeprograms,andsignificantlyextendstheexplanationcapabilitiesof thepre-vious Amphion system[9]. The codegeneratedby AM-PHION/NAV is annotatedwith detailedexplanationsde-scribing where eachexpressionin the code camefrom.Theseexplanationsareconstructedby tracingautomaticallythroughthe proof that producedthe codeand composingexplanationsfor eachof theaxiomsusedin theproof. As aresult,eachprogramexpressioncanbeexplainedin termsof the conceptsin the specificationfrom which they werederived.Theseexplanationsaregivenin theform of hyper-linkedtext in astandardnotationof theGN&C domain.

BecauseGN&C algorithmsare often used in safety-critical systems,detailedexplanationsarecrucialto provide

a meansfor a certificationbodysuchastheFAA to exam-inethecodein detailandtoknow preciselywhereeachcodeexpressioncamefrom. Explanationsarealsocrucialwhenthegeneratedcodeneedsto bemodifiedor integratedit intoa largersystem.

The domainof stateestimationturnsout to be a goodchallengedomainfor deductivesynthesis.Developingstateestimationsoftware tends to be a black art. In princi-ple,theengineershoulddevelopamathematicalmodelthatcloselyresemblesthereal-world characteristicsof theprob-lem. The outputof simulationrunson this modelshouldthenbe usedto refinethe modeluntil a thresholdlevel ofaccuracy is reached.In practice,however, engineersstartoff with a mathematicalmodelbut the time andcostcon-straintsassociatedwith the projectmeanthat they merely“tweak” parametersin theircoderatherthanreassessingthefidelity of the model. Programsynthesisencouragesanal-ysis to take placeat the modelinglevel andenablesrapiddesignspaceexploration.

2 Background on State Estimation

Thedomainof interestfor AMPHION/NAV is thatof ge-ometricstateestimation,i.e.,estimatingtheactualvaluesofcertainstate variables (suchasposition,velocity, attitude)basedonnoisydatafrom multiplesensorsources.Thestan-dardtechniquefor integratingmultiplesensordatais to usea Kalman filter. A Kalman filter estimatesthe stateof alinear dynamicsystemperturbedby Gaussianwhite noiseusing measurementslinearly relatedto the statebut alsocorruptedby Gaussianwhitenoise.TheKalmanfilter algo-rithmis essentiallyarecursiveversionof linearleastsquareswith incrementalupdates.

Thestateestimationproblemcanbe representedby thefollowing equations,givenin vectorform:

���������� ������������������������� (1)���������������������������������� (2)

The first equationis the processmodel, a vector dif-ferential equationmodeling how the state vector, ������� ,changesover time. The secondequationis the measure-ment model, relating the measuredvariablesto the statevariables.Specifically, ������� is thestatevector(with

�������� thetimederivative)of quantitiesto beestimated(e.g.,position,attitude,etc.), ������� is a vectorof measurements(the statevariablesarenotnecessarilymeasureddirectly), ������ , �������areGaussianwhitenoiseperturbanceson themeasurementandprocessmodel respectively and � and � are possiblynonlinearcontinuousfunctionsthatmustbediscretizedforimplementationpurposes.

A Kalmanfilter is an iterative algorithmthat returnsatimesequenceof estimatesof thestatevector, �������� , by fus-ing themeasurementswith estimatesof thestatevariables

basedon theprocessmodelin anoptimal fashion,i.e., theestimatesminimize the mean-squareestimationerror. Inthe casewhereeither � or � is nonlinear, a Kalmanfiltercanstill beusedby first linearizingarounda “nominal” es-timate. After linearizationanddiscretization,� and � canbe representedby matrices � (the statetransitionmatrix)and � (themeasurementmatrix) respectively.

Thestandardimplementationof aKalmanfilter requiresseven inputs: the � and � matrices,the covariancestruc-tureof theprocessandmeasurementnoise( ������� and ������ ),aninitial stateestimate����� �!� , anerrorcovariancematrixoftheinitial estimateand,of course,thesequenceof measure-ments.Duringeachiterationof thefilter, thestateestimateis updatedbasedonnew measurementsandtheestimateer-ror covarianceis updatedfor thenext iteration.

The AMPHION/NAV systemtakesasinput a specifica-tion of theprocessmodel(a typical modelis a descriptionof thedrift of an INS systemover time), a specificationofsensorcharacteristics,anda specificationof the geometricconstraintsbetweenanaerospacevehicleandany physicallocationsassociatedwith thesensors- suchasthepositionof radio navigationaids. The input specificationalsopro-videsarchitecturalconstraints,suchaswhetherthereis oneintegratedKalmanfilter or a federationof separateKalmanfilters. AMPHION/NAV producesas output codethat in-stantiatesoneor moreKalmanfilters. Theusercanrun orsimulatethecode,determinethatit is lacking(e.g.,thatthesimulatedestimatefor altitudeis not sufficiently accurate),reiteratethedesign(e.g.,by addingaradioaltimetersensorto thespecification),andthenreruntheexperiment.

3 Amphion/NAV System Architecture

Specification

" # $ % & ' ( ) * +Axioms

ExplanationExplanationtemplatesdo

mai

n th

eory ,-.

/0Proof

, 1234 567 68 297 25 : ; < => = ( = ? & * ; ? TraceApplicative

TermCode

Figure 1. Architecture of Amphion/NA V withExplainIt!

Figure1 presentsthearchitectureof theAMPHION/NAVsystem.Thedomaintheory(Section4) specifiesthe typesandoperationsignaturesin the domain,andcontainsaxi-omsdescribingthe implementationof the abstract opera-tions(whichareusedin theproblemspecification)in terms

2

of concrete operations(which areusedin the implementa-tion). The domaintheory also containsexplanationtem-platesassociatedwith eachaxiom (Section5) providingdocumentationabouttheirmeaning.

The processof deductive synthesis [4, 7] submitsthespecificationand the axiomsof the domaintheory to thesynthesisengine, which is the SNARK @ refutation-basedtheoremprover. Thetheoremproverprovesthatthespecifi-cationis a consequenceof thedomaintheory, andreturnsaproofandwitnesstermsfor theoutputvariables,in ourcasean applicative term comprisingthe synthesizedprogram.The codegeneratoris given the applicative term andpro-ducescodein thetargetprogramminglanguageby applyingseveralprogramtransformationphases.Thetargetlanguagein AMPHION/NAV is C++ andOCTAVE. A Amphion/NAIFgeneratedFortrancode,but only the lastphaseof thecodegeneratorneededto bechangedfor AMPHION/NAV.

Thecodegeneratorrecordsa traceof theapplicationofthetransformations.TheExplainIt! component(Section5)acceptstheaxiomexplanationtemplates,theproof, theap-plicative term, andthe codegeneratortrace,andproducesan explanationstructurefor the final code. This structurelinks portionsof the target codeto explanations.The ex-planationof a portionof targetcodeis generatedfrom theexplanationtemplatesassociatedwith theaxiomsthatwereusedin thecreationof thatportionof thecode.

4 Engineering a Domain Theory for State Es-timation

The stateestimationdomaintheoryrepresentsboth theoperationsandalgorithmsin thedomainandhow thosedo-mainelementsareproperlyapplied.For the initial versionof AMPHION/NAV describedin thispaper, thescopeis thatof advancedgraduate-level textbooks(e.g., [1]) stateesti-mation examples. In all, six textbookswere usedin de-velopingthe domaintheory, rangingfrom generalappliedKalmanfiltersto specializedtextsonINS andGPSsystems.Theexamplesusedrangedfrom simplestateestimationsys-temswith radiobeaconsto complex INS/GPSsystemswithadditionalaiding sensors.The methodologyfollowedwastowork fromconcreteexamplesgivenin thetextbooks,and,from theseexamples,to identify theconceptsof thedomainandthe relationshipsbetweenthoseconcepts.Input fromdomainexpertswassolicitedto validatetheseefforts. Thedomaintheoryis a collectionof modularsubtheorieseachcontaininga setof axiomsdescribingtheprimitivesin thesubtheoryandtherelationsbetweenthem.

Figure 2 shows the structureof the subtheoriesin thecurrentdomaintheory. Thearrowsshow whichsubtheories

BURL: http://www.ai.sri.com/ stickel/snark.htmlCA Matlabclone:http://www.octave.org

importothersubtheories(e.g.,theaxiomsfor frameconver-sionsimport theNAIF axioms).In thesynthesisproofs,theNAIF axiomsandframe/coordinateaxiomsareappliedus-ing resolution,paramodulationanddemodulation.All otheraxiomsareappliedusingdemodulationonly. Thiswasare-strictionmadeto control the proof process.Thearrows inFigure2 alsomanifestthemselvesin theaxioms: therulesrefineprimitives from one subtheoryinto primitives froma subtheoryconnectedby an arrow. Note that the leaf no-desof Figure2 aresubtheorieswhoseprimitivesappearinthe final applicative term. In essence,high-level abstractprimitivesspecifyingKalmanfilter architecturesand sen-sor configurationsarerefinedinto primitivesof Euclideangeometryandmatrix/vectoroperations.Refinementsalsotake placewithin thetheoriesthatrefineprimitivesof thosetheoriesinto primitivesthatarewrappersaroundcodecom-ponents.

KalmanFilteraxioms

Frame/CoordinateConversions

Differentiation

NAIFdomain(Euclideangeometry)

Sensorspecificaxioms

VectorOperations

MatrixOperations

Linearization

Figure 2. Amphion/NA V Domain Theor y Orga-nization

In general,the synthesisengineappliesproof searchtoapply the axiomsin a way that suits the currentcontext.Thismayinvolvemakingpre-definedassumptionsasto thenatureof the currentproblem(e.g., that the nominalesti-mateis closeenoughto thetruevalueto enableaTaylorse-riesexpansionto beaccurate)but theseassumptionsappearexplicitly in thefinal explanationspresentedto theuser.

A fully declarativedomaintheoryis idealfor expressingthe conceptsin a new domainandfor communicatingandvalidatingtheir relationships.On theotherhand,codegen-eration(regardlessof whichsynthesisengineis used)needsmoreguidanceto be successful.As partof our methodol-ogy, webeganwith a highly declarativedomaintheoryand

3

thenextendedthis theorywith operationalelementsto en-ablesuccessfulrefinement.

Anotherway to limit thesearchspaceis to make useofdecision procedures in the theoremproving process.Theidea is to solve appropriatesubtasks(over groundterms)thatcomeupin theproofby callsto externalroutinesratherthanrelyingontheproofengine.Amphion/NAIF containeddecisionproceduresfor instantiatingvariableswith theap-propriatecoordinateframe.AMPHION/NAV usesSNARK’sproceduralattachmentmechanismto incorporatedecisionproceduresfrom the KIF libraryD (list manipulations,nu-mericmanipulations,etc.)andproceduresfor low-levelma-trix manipulations.

5 The ExplainIt! Documentation Generator

The code generatedby AMPHION/NAV is annotatedwith detailedexplanationsdescribingwhereeachstatementandexpressionin thecodecamefrom. Intuitively, anexpla-nationof a statementin thegeneratedprogramis a collec-tion of explainedconnectionsbetweenthevariables,func-tions and subroutinesin that statementand objects,rela-tions,andfunctionsin theproblemspecificationor domaintheoryrespectively.

Ourexplanationtechniqueworksontheproofderivationof the generatedprogramwhich is a tableau,a treewhosenodesaresetsof formulastogetherwith substitutionsof theexistentiallyquantifiedvariables,andwhosearcsarestepsin theproof (i.e., they encodethe“derivedfrom” relation).Thus,anabstractsyntaxtree(AST) of thesynthesizedpro-gramandtheemptyclauseis therootof thisderivationtree.Its leavesaredomaintheoryaxiomsandtheproblemspeci-fication. SincetheAST andall formulasarerepresentedastree-structuresterms,thederivationtreeis essentiallya treeof trees.

Theexplanationgenerationproceduretracesbacka po-sition in theabstractsyntaxtreethroughthederivationtreeextracting explanation equalities along the way. Theseequalitiesrecord the links betweenpositionsof differentterms in the derivation. By reasoningwith theseequal-ities, goal explanation equalities arederived which relateelementsof thegeneratedprogramwith termsin thespeci-ficationandformulasin thedomaintheory.

With theseexplanationequalititescalculated,theappro-priateexplanationtemplatesof the domaintheoryaxiomsare instantiatedand composed. Finally, an XML docu-mentis assembled,containinganexplanationfor everyexe-cutablestatementin a synthesizedprogramin a vocabularythat the domainexpertunderstands.Theexplanationindi-cateswhy thatstatementis in theprogramandhow thesta-tementrelatesto theproblemspecificationandthedomain

EURL: http://logic.stanford.edu/kif/kif.html

theory. Thesestepswhichareanextensionof work reportedin [9] will bedescribedin thefollowing.Explanation Equalities. All piecesof a formulaareiden-tified using a position notation,describedby a path fromtheroot of theformulato thatposition. A pathdescriptionis a sequenceof argumentpositionselectors,e.g.,thepathFHG �JI!K specifiesthe position of L in the term � �HM���NO� L �QPR��� ,i.e., LJS FHG �JI!K . Explanation equalities capturingthe linksbetweenpiecesof a formula are assertionsof the form� @ SUT @ � A SUT A betweenterms� @ � � A atpositionsT @ andT A in theterm,respectively. Explanationequalitiesarealsoextractedfor variablesubstitutionsgeneratedduring eachderivationstep.Templates. Theaxiomsof thedomaintheoryareannotatedwith explanationtemplateswhich consistof text fragmentsandvariables. All variablesoccurringin a templatemustalsooccurin the axiom to which the templateis attached.Eachaxiom canhave multiple templateseachof which isassociatedwith a differentpositionin thataxiom.Template Instantiation and Composition. The explana-tion for a position in the generatedprogramis composedfrom the templatesassociatedwith theexplanationequali-ties. This is accomplishedby constructingan equivalenceclassVXW w.r.t. theexplanationequalitiesof thederivation.Thenthedesiredgoalexplanationequalitieslinking a sub-term to the specificationanddomaintheoryarecontainedin the correspondingequivalenceclass;the templatescanbefoundin thesetof templatesattachedto theformulapo-sitionsin V W . To constructtheentireexplanation,thetem-platesin this setareinstantiatedandconcatenatedtogetheraccordingto theorderin whichthey occurin thederivation.Document Assembly. The final outputof ExplainIt! is adocumentwhichexplainseachpartof thesynthesizedcodein a formatsuitablefor thedomainengineer. Thestructureof the explanationis reflectedin the computationalstruc-ture of the applicative term. Thus, explanationsare con-structedfor eachpositionin theapplicativeterm.As a flex-ible intermediateformat,XML is used,becauseit facilitatesthegenerationof variousdocumentformats. Furthermore,hyper-linksallow theuserto transparentlytracebetweenthefinal codeand the explanationdocument. This is neces-sarybecausethestructureof theimperativeC++ codedoesnotnecessarilycoincidewith thestructureof theapplicativeprogram.

XSLT [6] is usedto producethefinal structuredHTMLversionof theexplanation.In orderto enhancereadability,all termscontainingmatricesareshown asHTML tables(inAMPHION/NAV they arerepresentedashard-to-readlistsof lists). Fig. 3 shows theupperleft cornerof the2x9 mea-surementmatrix � . TheXSLT parsercaneasilybemodi-fied to handlevarioussyntactictransformationsthusfacili-tatingadaptationto otherdomains.ExplainIt! is thuscon-figurablein a similar way like Hallgren’s ProofEditor [5],

4

Figure 3. Screen dump of a par t of the expla-nation document

or theILF system[2].

6 Experiments and Results

WehaveusedAMPHION/NAV to synthesize5 groupsofexamplesof single-modegeometricstateestimationsoft-ware. The examplesuseeitheran inertial navigation sys-tem (INS), or a GPSsystemas its basis. As aiding sen-sors,we have usedmodelsfor distancemeasuringequip-ment(DME), VOR (measuringthe anglebetweenthe air-craft anda fixed station),anda barometricaltimeter. Thefollowing tablegivesan indicationof the performanceofthesystemfor all examples.Thesizeof thespecificationisgivenasthenumberof conjunctsin thetextual (logic) rep-resentationof thespecification.Thedomaintheoryconsistsof 622 axioms,344 of which have beenreusedfrom theNAIF domain. Y[Z]\�^J_�` depictsthe run-timeto find a proof(includingloadingof theprover’sLisp code)in secondsona SunUltra 60. Finally, thenumberof linesof synthesizedC++ is given. This numberincludescommentsandratherlengthyinterfacecode(300-350linesperexample).

measure min mean maxsizeof spec 67 83 114Y[Z]\�^R_�`ba cJd 44 390 1311C++ lines 712 950 1208

7 Conclusions

We have presentedAMPHION/NAV, a deductive syn-thesissystemfor the automaticgenerationof highly doc-

umentedstateestimationsoftwarewith Kalmanfilters. Al-thoughtherehave beenmany improvementsover the oldsynthesissystemwith respectto domaincomplexity, usabil-ity, andgenerationof explanations,thereis still a numberof importantissuesto be addressed.During developmentof AMPHION/NAV it turnedout that thegraphicalspecifi-cation language,originally developedfor spacetrajectoryspecifications,needsextensionsfor thestateestimationdo-main. Theoriginal specificationswererelationalin nature,whereasafunctionalspecificationmaybemoreappropriatefor thenew domain.

As describedin the paper, the developmentof the do-maintheoryturnedout to bea centralissuefor our synthe-sis system. Although the old NAIF domaintheorycouldbereusedin anas-ismanner, thestructureanddevelopmentprocessfor the domaintheoryneedsto be improved sub-stantially. We areinvestigatingin how far techniquesfromobject-orientedsoftwaredesigncanbeof helpto developadomaintheoryin a muchmorestructuredandfundamentalway.

In developing AMPHION/NAV, mucheffort was spenton the explanationsystem. Automaticgenerationof doc-umentationis only a first step. Future work will inves-tigate how far deductive synthesiscan supportcomputer-supportedcertificationof safety-criticalcodeby automaticgenerationof verificationproof obligations,invariants,andotherannotationsfor thesynthesizedcodewhich thencanbecheckedby asmallandtrustedproofchecker.

References

[1] R.G.Brown andP. Hwang.Introduction to Random Signalsand Applied Kalman Filtering. Wiley, 3rded.,1997.

[2] B. I. DahnandA. Wolf. Natural Language Presentation andCombination of Automatically Generated Proofs, volume3of Applied Logic Series, pp.175–192.Kluwer, 1996.

[3] A. Gelb(ed).Applied Optimal Estimation. MIT Press,1974.[4] C. C. Green. Application of theoremproving to problem

solving. In Proc. IJCAI, pages219–240,1969.[5] T. HallgrenandA. Ranta. An extensibleproof text editor.

In Proc. LPAR’2000, volume1955of LNAI, pages70–84.Springer, 2000.

[6] M. Kay. XSLT Programmer’s Reference. Wrox Press,2000.[7] Z. MannaandR.Waldinger. Fundamentalsof deductivepro-

gramsynthesis.IEEE Transactions on Software Engineer-ing, 18(8):674–704,1994.

[8] M. Stickel, R. Waldinger, M. Lowry, T. Pressburger, andI. Underwood. Deductivecompositionof astronomicalsoft-ware from subroutinelibraries. In Proc. CADE 12, pages341–355,Springer, 1994.

[9] J. van Baalen,P. Robinson,M. Lowry, andT. Pressburger.Explainingsynthesizedsoftware. In Proc. ASE’98, pages240–248.IEEE,1998.

5