Amphion/NAV: Deductive Synthesis of State Estimation Software

JonWhittle Jeffrey VanBaalen JohannSchumannQSSInc. U. Wyoming RIACS

PeterRobinson TomPressburger JohnPenixQSSInc. NASA NASA

Phil Oh MikeLowry GuillaumeBratQSSInc. NASA KestrelInst.

NASA AmesResearchCenterMoffett Field,CA 94035

Abstract

This paperdescribestechnology developedfor the Am-phion/NAV synthesissystem.Building on previouswork inAmphion/NAIF, this systemsynthesizesgraduate-level text-book examplesof single-modegeometricstateestimationsoftware. Amphion/NAV includesexplanationtechnologyfor mappingtheinternal representationsof a proof (gener-atedthroughdeductivesynthesis)thata programis correct,to documentationandrequirementstracesthatdemonstratethis correctnessto humanengineers. TheExplainIt! sub-systemextendsthetechnologypreviouslyreportedonfor ex-planationgeneration,andincludesan XML-basedbrowserinterface. A methodology that employsmultiple levels ofreusewasusedin developingAmphion/NAV, including in-corporation of the previousAmphion/NAIF domaintheoryasa part of theAmphion/NAVdomaintheory. Thecombina-tion of general-purposeautomatedreasoningmethodsthatare widelyapplicable, with specializedautomatedreason-ing methodsthataredomainspecific,enabledgenerationofsubstantialprograms. Lessonslearnedare presented,andfuturework is discussed.

1 Introduction

Previous work on domain-specificdeductive programsynthesis[12, 13] describedtheAmphion/NAIF systemforgeneratingFortrancodefromhigh-levelgraphicalspecifica-tionsdescribingproblemsin spacesystemgeometry. Am-phion/NAIF specificationsdescribefunctionsthatcomputegeometricquantaties(e.g.,the distancebetweentwo plan-

etsat somepoint in time) by composingtogetherFortransubroutinesfrom the NAIF subroutinelibrary developedat the Jet PropulsionLaboratory(JPL). In essence,Am-phion/NAIF synthesizescodefor glueingtogethertheNAIFcomponentsin a way suchthat the generatedcodeimple-mentsthespecification.Thecorrectnessof this implemen-tation (with respectto the specification)is guaranteedbytheuseof theSNARK first-orderresolutiontheoremprovertocarryouttherefinementfromspecificationtoafunctional�

-term,andtheuseof a transformationsystemto transformthe

�-terminto Fortrancode.

Amphion/NAIF demonstratedthe successof domain-specificdeductiveprogramsynthesisandis still in usetodaywithin thespacesciencecommunity. However, anumberofquestionsremainedopenthatwe will attemptto answerinthispaper, namely:

� Whatevidencecanbeprovidedto aninterestedpartythat the generatedcodedoesin fact implementthespecification?Note that theuseof a theoremproverin synthesisis notthefinal answersinceaproversuchasSNARK is a complex softwareartifactin itself andmay containbugs. Amphion/NAIF did not addresstheintegrationof aprogramsynthesissysteminto thesoftwareprocess- particularlytheissueof validationandverificationdependentonhumanreview.

� Whataretheissuesinvolvedfor aprojectteamto de-velopaprogramsynthesissystemfor its own particu-lardomain?Amphion/NAIF generatesrelativelysim-ple code, principally sequencesof subroutinecallswith limited use of loops. In developing programsynthesissystemsfor otherdomains(e.g.,for embed-dedsystemsapplications),theserestrictionswill no

longerhold. In addition,Amphion/NAIF wasabletobuild on a well-defined,previouslygivencomponentlibrary. Sucha library is unlikely to beavailableformostapplications,but mustbedevelopedin parallelor collectedfrom elsewhere.

In order to investigatethesetwo limitations, we devel-oped Amphion for a new, much richer domain, namelyGuidance,Navigation & Control (GN&C) algorithms,inparticularsingle-modegeometricstateestimationsoftware.GN&C algorithmsare often complex, involving iterativeloop algorithmsand real-timeconsiderationssuchas ex-trapolatingsensordatasothatdatais integratedat thesamepoint in time. In addition,althoughtherearestandardcom-ponentsavailable for this domain(e.g., matrix manipula-tions, Kalmanfilter algorithms),thereis no easilydefinedsetof componentsthatcover thedomainfully.

Amphion/NAV is an extensionof Amphion/NAIF thatgeneratescode for integrating data from multiple sensorsourcesin a statistically optimal way using Kalman fil-ters [1, 4]. In addition to dealingwith a muchricher do-main,Amphion/NAV significantlyextendstheexplanationcapabilitiesof thepreviousAmphionsystem[13]. Thecodegeneratedby Amphion/NAV is annotatedwith detailedex-planationsdescribingwhere eachexpressionin the codecamefrom. Theseexplanationsare constructedby trac-ing automaticallythroughtheproof thatproducedthecodeandcomposingexplanationsfor eachof theaxiomsusedintheproof. As a result,eachprogramexpressioncanbeex-plainedin termsof the conceptsin the specificationfromwhich they werederived. Theseexplanationsaregiven intheform of hyper-linkedtext andarespecificto theGN&Cdomain.

Detailedexplanationsprovide a meansfor a certifica-tion body suchas the FAA to examinethe codein detailand to know preciselywhereeachcodeexpressioncamefrom. GN&C algorithmsare often usedin safety-criticalsystems. Hencethe very detailedexplanationsprovidedby Amphion/NAV providenecessarydocumentationfor thecertificationprocess.The explanationsarealsocrucial toprogrammerswhoneedto modify thegeneratedcodeor in-tegrateit into a 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.

In summary, AMPHION/NAV is a working prototypethat makesthe following contributionsto the field of pro-gramsynthesis:

� generationof complex softwareartifactsinvolving it-erative loopsandreal-timeaspects;

� generationof detailedexplanationsthatprovidedoc-umentationnecessaryfor thecertificationprocessofsafetycritical systems;

� the use of a theoremprover to guaranteedomain-specific propertiesin the generatedcode (as a by-productof synthesis)— e.g., all parametersare inthe sameframe/coordinatesystem,matrix multipli-cationsarewell-defined;

� rapiddesignspaceexplorationof competingarchitec-tures/configurations.

2 Background on State Estimation

Thedomainof interestfor Amphion/NAV is thatof geo-metricstateestimation,i.e., estimatingtheactualvaluesofcertainstatevariables(suchasposition,velocity, attitude)basedonnoisydatafrom multiplesensorsources.Thestan-dardtechniquefor integratingmultiplesensordatais to usea Kalman filter. A Kalman filter estimatesthe stateof alinear dynamicsystemperturbedby Gaussianwhite noiseusingmeasurementslinearlyrelatedto thestatebutalsocor-ruptedby Gaussianwhitenoise.A Kalmanfilter providesastatisticallyoptimalestimate,in thesensethatit minimizesthe expectedrisk associatedwith any quadraticlossfunc-tion of theestimationerror. TheKalmanfilter algorithmisessentiallya recursive versionof linear leastsquareswithincrementalupdates.

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,attitudeetc.), �!��� is a vector of measurements(the statevariablesarenotnecessarilymeasureddirectly), ���� , �����areGaussianwhitenoiseperturbanceson themeasurementand processmodel respectively and and � are possibly

2

nonlinearcontinuousfunctionsthatmustbediscretizedforimplementationpurposes.

A Kalmanfilter is an iterative algorithmthat returnsatimesequenceof estimatesof thestatevector, "#�$�%& , by fus-ing themeasurementswith estimatesof thestatevariablesbasedon theprocessmodelin anoptimal fashion.Thees-timatesminimize themean-squareestimationerror. In thecasewhereeither ' or ( is nonlinear, a Kalmanfilter canstill be usedby first linearizing arounda “nominal” esti-mate.After linearizationanddiscretization,' and ( canberepresentedby matrices) (thestatetransitionmatrix) and*

(themeasurementmatrix) respectively.Thestandardimplementationof aKalmanfilter requires

seven inputs: the ) and*

matrices,the covariancestruc-tureof theprocessandmeasurementnoise( + $�%& and , $�%& ),aninitial stateestimate#�$�%.-/& , anerrorcovariancematrixoftheinitial estimateand,of course,thesequenceof measure-ments.During eachiterationof thefilter, thestateestimateis updatedbasedonnew measurementsandtheestimateer-ror covarianceis updatedfor thenext iteration.

To illustrate,consideran aircraft that is equippedwithaninertial navigationsystem(INS) andradioequipmenttodeterminethe distanceof theaircraft from two fixed radiotowers(distancemeasuringequipment(DME) sensors).Aninertial navigation system(for detail seee.g., [10]) is anelectromechanicaldevicewhichconsistsof threegyrosandaccelerometersorientedwith respectto the 0 , 1 , and 2 axisof a rectangularcoordinatesystem.Eachmovementof theINS (andtheaircraft)generatesadeviationsignalin thegy-roswhich, togetherwith readingsfrom theaccelerometers,provideanestimateof thecurrentposition,velocityandat-titudeof theaircraft.However, dueto inherenterrorsof theINS (principally, gyro drift), the accuracy of the estimatedecreasesconsiderablyover time. Therefore,additional(oraiding) measurementsareneededto contributeinformationandthusboundtheerror. In ourexample,two DME sensorsprovideaidingmeasurementsin the 0�31 plane.

Figure1 givesthe AMPHION/NAV graphicalspecifica-tion for integratingmeasurementsfrom anINS sensorwiththosefrom two DME sensorsusinga Kalmanfilter 4 . Fig-ure2A shows resultsfrom a simulationusingcodesynthe-sizedautomaticallyfrom this specification.Thesimulationmodelstheaircraftasflying in thenorth-southdirection,butunderturbulenceso it is not flying in a straightline, but ina “random-walk” like fashion.The locationof the two ra-dio towersaremarkedby “+”. The dashedline shows theestimated$ 0�31 & positionof theaircraft,basedupontheINSsystemaidedby thetwo DME readings.

Therelative errorof theKalmanfilter estimateis shown5We assumethat all sensorreadings,measurements,andpositiones-

timatesarein the samecoordinatesystemandframeandthe sameunits.AMPHION/NAV, however, canautomaticallygeneratecodefor theappro-priateconversionroutines.

Figure 1. Graphical input specification for asimple INS configuration with two aiding DMEsensor s.

in Figure2B. Theerrorin theverticaldirection(theverticalscaleis logarithmic)grows in an unboundedfashion(dot-dot-dash),becausetheaidingsensorsareonly contributingto the horizontal 0 and 1 directions. After a short time,all estimatesin the(vertical) 2 directionbecomepracticallyuseless.

A typical way to avoid this problemis to adda sensorwhichprovidesinformationaboutthealtitudeof theaircraft(e.g.,a baro-altimeter).With traditionalsoftwaredevelop-ment of the state-estimationsoftware, addinga sensorinthis way leadsto a lengthyre-implementationof muchofthe code. Within AMPHION/NAV, a sensorcanbe addedeasily(within about5 minutes).AMPHION/NAV thensyn-thesizescodefor thenew sensorconfiguration.Figure2Cshows therelativeerrorsfor thenew configuration.Theer-rorsin the 0 and 1 directionremainthesame(thealtimeterdoesnot contribute to that); however, the vertical error isreducedsubstantially.

3 AMPHION/NAV System Architecture

Figure3 presentsthearchitectureof theAMPHION/NAVsystem.Thedomaintheory(Section4) specifiesthe typesandoperationsignaturesin thedomain,andaxiomsdescrib-ing the implementationof the abstract operations(whichareusedin theproblemspecification)in termsof concreteoperations(which are usedin the implementation). Thedomaintheoryalsocontainsexplanationtemplatesassoci-

3

A

B

C

Figure 2. Simulation results for synthesiz edcode: actual and estimated aircraft positionon the 6�7�8 plane (A), relative errors in the con-figuration INS with two DME sensor s (B), andwith an additional baro-altimeter (C).

atedwith eachaxiom. The templatesprovide documenta-tion aboutthemeaningof theaxioms.

A GUI (not shown), guidedby the typesandoperationsignaturesspecifiedin the domaintheory, aidsthe userinproducinga formal,type-correctgraphicalproblemspecifi-cation(Figure1 for anexample).Thespecificationis equiv-alentto a first-orderlogic formulaof theform

9�:inputs;=< : outputs;>< : intermediates;:

Conjunct?�@BACADAC@ ConjunctEF;�AThe conjunctsdescribethe desiredinput/outputrelation-ship.Theconjunctsareall expressedin termsof theabstractlanguage,exceptfor thoseexpressingtherelationshipsbe-tweenconcreteinput or output variablesand the abstractvariablesthey represent.

The processof deductivesynthesis[6, 9] submitsthespecificationand the axiomsof the domaintheory to thesynthesisengine,whichis theSNARK [11] refutation-based

Specification

G H I J K L M N O PAxioms

ExplanationExplanationtemplatesdo

mai

n th

eory QRS

TUProof

Q VWXY Z[\ [] W^\ WZ _ ` a bc b M b d K O ` d TraceApplicative

TermCode

Figure 3. Architecture of AMPHION/NAV withExplainIt!

theoremprover. Thetheoremproverprovesthatthespecifi-cationis a consequenceof thedomaintheory, andreturnsaproofandavectorof witnesstermsfor theoutputvariables,in our caseanapplicative termcomprisingthesynthesizedprogram.

Thecodegeneratoris giventheapplicativetermandpro-ducescodein the target programminglanguagevia appli-cationof several phasesof programtransformations.Thetargetlanguagein AMPHION/NAV is C++ andOCTAVE e .AMPHION/NAIF generatedFORTRAN code,but only thelast phaseof the codegeneratorneededto be changedforAMPHION/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

Designingdomain theoriesfor programsynthesisis adifficult task.Domainknowledgeis oftenill-definedor dis-tributedamongmultiplesourcesof knowledge,e.g.domainexperts.In addition,thescopeof thedomainfor a particu-lar applicationis usuallyvery fuzzy (cf., for example,[2]).Thisproblemis furthercomplicatedfor supportingprogramsynthesisbecausedomainknowledgerepresentsboth theoperationsandalgorithmsin thedomainandhow thosedo-main elementsareproperly applied. As a result, domainengineeringfor programsynthesisis a significantlymoredifficult taskthanprogramming.

For the initial versionof AMPHION/NAV describedinfA Matlabclone:http://www.octave.org

4

thispaper, thescopeis thatof graduate-level textbook(e.g.,[1]) stateestimationexamples.Themethodologyfollowedwasto work from concreteexamplesgivenin thetextbooks,and, from theseexamples,to identify the conceptsof thedomainandthe relationshipsbetweenthoseconcepts.In-put from domainexpertswassolicitedto validatetheseef-forts. Thedomaintheoryis a collectionof modularsubthe-orieseachcontaininga setof axiomsdescribingthe prim-itivesin thesubtheoryandtherelationsbetweenthem,ex-pressedin first order logic. Abstract primitivesencapsu-late specification-level conceptsin the domain(e.g., fusedatafrom two sensors)whereasconcreteprimitivesdefinewrappersaroundimplementedsoftwarecomponents(e.g.,aKalmanfilter component).

Figure 4 shows the structureof the subtheoriesin thecurrentdomaintheory. Thearrowsshow whichsubtheoriesimportothersubtheories(e.g.,theaxiomsfor frameconver-sionsimport theNAIF axioms).In thesynthesisproofs,theNAIF axiomsandframe/coordinateaxiomsareappliedus-ing resolution,paramodulationanddemodulation.All otheraxiomsareappliedusing demodulationonly. This was arestrictionmadeto control the proof process.The arrowsin Figure 4 also manifestthemselves in the axioms: therules refineprimitives from onesubtheoryinto primitivesfrom a subtheoryconnectedby anarrow. Notethattheleafnodesof Figure4 aresubtheorieswhoseprimitivesappearin thefinal applicative term. In essence,high-level abstractprimitivesspecifyingKalmanfilter architecturesand sen-sor configurationsarerefinedinto primitivesof Euclideangeometryandmatrix/vectoroperations.Refinementsalsotake placewithin thetheoriesthatrefineprimitivesof thosetheoriesinto primitivesthatarewrappersaroundcodecom-ponents.

Referringto Figure1, thespecificationfor a typical ex-ampledescribesthe sensorconfigurationand the Kalmanfilter architecture. Sensorsare specifiedby giving thedatatypesof their outputs— e.g.,a DME sensoroutputsadistancein aparticularframeandcoordinatesystem,andits(noisy)outputsaredistributedwith a givenmeanandvari-ance.TheKalmanFilter subtheorydescribeshow to derivethenecessarymatrix inputs(e.g.,the g and h matrices)toa Kalmanfilter codecomponent(seeFigure5). Figure6givesanaxiomfrom theKalmanfilter subtheoryfor fusingdatafrom multiplesensorsusinga linearizedKalmanfilter.Eachof the derive operationsis refinedby domainthe-ory axiomsinto a matrix that is input to the Kalmanfilterroutine.

In general,the synthesisengineappliesproof searchtoapplytheaxiomsin awaythatsuit thecurrentcontext. Thismay involve makingpre-definedassumptionsasto thena-tureof thecurrentproblem(e.g.,that thenominalestimateis closeenoughto the true valueto enablea Taylor seriesexpansionto beaccurate)but theseassumptionsappearex-

KalmanFilteraxioms

Frame/CoordinateConversions

Differentiation

NAIFdomain(Euclideangeometry)

Sensorspecificaxioms

VectorOperations

MatrixOperations

Linearization

Figure 4. AMPHION/NAV Domain Theor y Orga-nization.

plicitly in thefinal explanationspresentedto theuser.To give a flavor of thereasoninginvolvedin thesynthe-

sissystem,considerhow the h matrix is formed.Eachrowin the h matrix correspondsto a measurementand eachcolumnto a statevariable(so, in the runningexample, hhas2 rows, onefor eachDME sensor, and9 columns,forposition,velocity, attitudein 3 directions). Eachentry inh is a linearizationof therelationshipbetweena measure-mentanda statevariable. In general,the relationshipthatholdsbetweenmeasurementsandvariablesmaynot belin-ear. The domaintheorycontainsa linearizationsubtheoryfor applyingTaylor seriesexpansionanddiscardinghigherordertermsunderappropriateassumptions.

In fact, thepreviousAmphion/NAIF domaintheoryforgeometrycan be reusedin the linearizationprocess. Forexample,a DME measurement,ikj , is a distancefrom thecurrentcoordinatesto the DME tower, which is expressedverynaturallyusingNAIF’sgeometricconstructs:

i jmlon.prq/stqvuxw>nyCzrq/{|u}yCn}~�w=�����������/��q/qv�/��y�����q/qv�/��yv� (3)

Axioms in the domain theory describehow to linearizethis equation(it is an abstractrepresentationof the usualPythagoreandistance)aroundthenominalcoordinates.Theeaseof reuseof theexisting NAIF domaintheoryprovidesstrongevidencethat it is possibleto developdomaintheo-riesin apiece-wisefashionandbringthemtogetherin sucha way that interactionsbetweentheoriesdo not adverselyaffect thecodegenerationprocess.

A fully declarativedomaintheoryis idealfor expressingthe conceptsin a new domainandfor communicatingand

5

φ = )( ) (Η=

...linearization

geometric conversion coordinate systems...coord_to_pt(polar),DME1,...

abs(coord_to_pt(polar),V) =

coord_conv(polar,rect,V)) abs(coord_to_pt(rect),

...coord_to_pt(rect)...DME1...

BARO DME1

Code: x = pol2rect(x1)

Figure 5. Synthesis in AMPHION/NAV

sensor_integration_with_linearize(state nominal aiding) =

extended_kalman_filter(derive-initial-estimate(state)derive-state-transition-matrix(state)derive-measurement-matrix(state nominal aiding)derive-process-covariance-matrix(state)derive-measurement-covariance-matrix(aiding)derive-observation-vector(aiding)derive-initial-covariance-matrix(state))

Figure 6. A lineariz ed Kalman filter axiom.

validatingtheir relationships.On theotherhand,codegen-eration(regardlessof whichsynthesisengineis used)needsmoreguidanceto besuccessful.As partof our methodol-ogy, webeganwith a highly declarativedomaintheoryandthenextendedthis theorywith operationalelementsto en-ablesuccessfulrefinement.Theresultis thatthesubtheoriesmake useof resolution,paramodulationanddemodulation,but in arestrictedfashion.Inferencerulessuchasresolutionandparamodulationprovide a greatdealof expressivenessbut easilyleadto exponentialblow-up in proof search.De-modulation(rewriting), on the otherhand,is tractablebutrequiresthedomainengineerto imposea left to right order-ing on the axioms. In orderto leveragethe advantagesofbothof thesetechniques,weuseresolution/paramodulationin specific,well-definedcircumstances,suchasconvertingbetweendifferent framesand coordinatesystems. Mostof the domain theory, however, consistsof rewrite rules.Paramodulationallows axiomsto be appliedin a way thatintroducesa freshvariableinto theproof goal. This cannotbe doneusing rewriting becausethe RHS variablesmustbe a subsetof the LHS variables. Paramodulationis veryusefulwhenconvertingtwo domainobjectsinto a commonframe.It allows thedecisionasto which commonframeto

useto be delayeduntil a point in the proof wherethe in-stantiationof thefreshvariablecanbedeterminedfrom thecurrentproofcontext. Overuseof paramodulation,however,leadsto asearchspaceblow-upandsoits usewasrestrictedto themostusefulapplications.

Anotherway to limit thesearchspaceis to make useofdecisionprocedures in the theoremproving process.Theidea is to solve appropriatesubtasks(over groundterms)thatcomeupin theproofby callsto externalroutinesratherthanrelyingontheproofengine.Amphion/NAIF containeddecisionproceduresfor instantiatingvariablesrepresentingframeswith the appropriateframe. AMPHION/NAV usesSNARK’s proceduralattachmentmechanismto incorporatedecisionproceduresfrom theKIF library [5] (list manipula-tions,numericmanipulationsetc.) andproceduresfor low-level matrix manipulations.By combiningtheoremprov-ing techniquessuchasdemodulationwith specialized(andpotentiallydomain-specific)decisionprocedures,deductiveprogramsynthesiscanbescaledup to realisticexamples.

5 The ExplainIt! Documentation Generator

In [13], we reportedon a techniquefor explaining de-ductively synthesizedsoftwarefrom tracesof thesynthesisproofs. Intuitively, anexplanationof a statementin a gen-eratedprogramis a collectionof explainedconnectionsbe-tweenthevariables,functionsandsubroutinesin thatstate-mentand objects,relations,and functionsin the problemspecificationor domaintheory.

Theexplanationtechniqueworkswith theproof deriva-tion of thegeneratedprogramwhich is a treewhosenodesaresetsof formulastogetherwith substitutionsof theexis-tentiallyquantifiedvariables,andwhosearcsarestepsin theproof (i.e., they encodethe“derivedfrom” relation).Thus,an abstractsyntaxtree(AST) of the synthesizedprogramandtheemptyclauseis the root of this derivationtree. Itsleavesaredomaintheoryaxiomsandthe problemspecifi-cation. Sincethe AST andall formulasarerepresentedastree-structuresterms,thederivationtreeis essentiallya treeof trees.

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

In this paper, we report on our subsequentdevelop-mentof the techniquefor generatingexplanationsto pro-vide completetraceability. By this, we meana systemthatgeneratesanexplanationfor everyexecutablestatementin asynthesizedprogramin vocabularythatadomainexpertun-

6

derstands.Theexplanationindicateswhy thatstatementisin theprogramandhow thestatementrelatesto theproblemspecificationandthe domaintheory. In the following, wedescribeexplanationequalities,explanationtemplatesandtheir instantiation,andthe mannerin which the documentis assembled.

5.1 Explanation Equalities

From each step in a derivation, a set of explana-tion equalitiesis extracteddescribingthe “links” between“pieces”of aformulaandits parentformulaswith respecttotheproof step.Thus,eachexplanationequalityis a logicalconsequenceof thesemanticsof the inferencerule appliedin thestepandtheparentformulas.

The piecesof a formula are identifiedusinga positionnotation.A positionin a formulais specifiedby a pathde-scriptionfrom the root of the formula to that position. Apathdescriptionis a sequenceof argumentpositionselec-tors, e.g., the path [2,1] specifiesthe position of � in theterm ������������v���D��� . Thesubtermat a positionselectedby avalid pathdescription� in the term � is written ����� . Thispositionaldescriptionis importantbecauselexically identi-cal termscanappearin multipleplacesin aformula,but arederivedthroughdifferentpaths.

When extracting explanation equalities, it is impor-tant that we keep track of where the different occur-rencesof terms originated. To this end, each node inthe derivation tree is assigneda unique number. Then,each variable � in node � is annotatedby �!  . Non-variable terms (constants,functors) are annotatedwithnode number and position. For example, the formula¡ �¢�����������������£������� in node� of thederivationis annotatedas¡  �¤¦¥ §�¨ ���  �¤¦¥ ©ª¤ §�¨ ���   �����  �¤¦¥ «�¤ §�¨ ���  �¤¦¥ «D¤ ©ª¤ §�¨ ��£   ��   ��Explanation equalities capturing the links between

piecesof a formula are assertionsof the form ¬m©D����©�­¬®«¯���!« betweenannotatedterms ¬m©v��¬®« . Explanationsarealsoextractedfor substitutionsgeneratedin eachderivationstepin theform of equalityassertions�   ­±°³² , where �  is thevariable� appearingin formula � and °³² is the(anno-tated)subtermto which � wasboundin theinferencestep,expressedasa positionin a formula.

5.2 Templates

Domain theory axiomsare annotatedwith explanationtemplates. Templatesare stringsof words and variables.All variablesoccurringin a templatemustalsooccurin theaxiom to which the templateis attached.Eachaxiom canhave multiple templateseachof which is associatedwith adifferentpositionin thataxiom. By templ��´������ we denotethe templatebelongingto axiom ´ at position � . Figure7shows theexplanationtemplatesfor theaxiomof Figure6.

templ(extended_kalman_filter,[2]) =(Integrate measurements from multiple sensors using an

Extended Kalman Filter EKF. All measurements areassumed to be in the same frame and coordinatesystem. The measurements are linearized around anominal trajectory. Data from aiding sensors is usedto provide a state estimate based on an underlyingprocess/state-vector model. The EKF takes sevenmatrices as input.)

templ(extended_kalman_filter,[2,1]) =(an initial state estimate)

templ(extended_kalman_filter,[2,2]) =(the state transition matrix Phi)

templ(extended_kalman_filter,[2,3]) =(the measurement matrix H)...

templ(extended_kalman_filter,[2,7]) =(an initial covariance matrix P_0)

Figure 7. Explanation Templates associatedwith the Kalman Filter Axiom of Figure 6

In thatcase,wehaveatemplatedescribingtheentireaxiom.This templateis attachedat theright-handsideof theequa-tion in Figure6. Thus,its positionis 2. Furthermore,eachof the 7 argumentsof the extendedKalmanfilter containtheirown explanationtemplates.

5.3 Template Composition and Instantiation

Thecompositionof anexplanationfor a positionin thegeneratedprogram(or, for thatmatter, any positionin anyformula in a derivation) is constructedfrom the templatesassociatedwith the explanationequalitiesdescribedaboveby constructionof an equivalenceclass. Let ¬�§k����§ bea term in a formula of the derivation. Then, we defineµ®¶ ��¬ § ��� § ��­¸·/¬®¹�����¹»º�¼½­¿¾F�CÀDÀDÀÂÁ asthe equivalenceclassof ¬ § ��� § containingall terms ¬®¹�����¹ inducedby theexplanationequalitiesof thederivation.

Then the desired goal explanation equalities linking¬ § ��� § to thespecificationanddomaintheoryarecontainedinµ ¶ ��¬�§v���!§¯� . Theexplanationtemplatesfor ¬�§v����§ can

be found in the set ÃÄ­ ·C�}ůÆÇ��È�x¬ ¹ ��� ¹ �ɺ�¬ ¹ ��� ¹Ëʵ ¶ ��¬�§k����§C��Á of templatesattachedto theformulapositionsinµ ¶

.To constructthe explanation,the templatesin this set

are instantiatedand concatenatedtogether. Eachindivid-ual templateis instantiatedby replacingeachvariable �!Ìwith the non-variableterm in

µ ¶ ����Ì�� that occursin theproblem specification. Compositionof the templatesisaccomplishedby imposingan orderingon the subformu-las: for ¬®¹}�ª¬�Í Ê µ�¶ ��¬ § ��� § � suchthat ¬®¹ occursear-lier in the derivation than ¬�Í then templ��¬®¹����!¹�� precedestempl��¬�Í��¢�ÎÍC� in theexplanation.

As anexample,theDME examplefrom Section2 con-tains the following subtermin the applicative term gener-

7

<function name=f><reason axiom=...> Explanation returned for entire term</reason>

<argument type =...>XML explanation returned for the term Ï¢Ð

</argument>. . .<argument type =...>

XML explanation returned for the term Ï�Ñ</argument>

</function>

Figure 8. XML representation of the explana-tions for a term Ò�Ó�Ô�ÕvÖC×Â×Ø×ØÖÔ}ÙFÚ .

ated:mk-mx(2,9, list (list (x-coord (vhat (vsub (

Coordinate3-1 ,Coordinate-Dme1-Posn ). . . )))

This subtermcomputesthe measurementmatrix, Û .x-coord(...) is one entry of the 2 Ü 9 matrix thatcomputesthelinearizedrelationshipbetweenthestatevari-ablerepresentingpositionin the Ý direction,andthemea-surementvariablerepresentingthe measurementfrom thefirst DME sensor. Figure9 givesthe explanationfor thissubterm.Eachbullet comesfrom anexplanationtemplate.Thefirst four bulletsdescribein a genericway thecontentsof the elementat position Ó}Þ�ÖCÞ¯Ú in the matrix. The cur-rent output text is somewhat rough but tells the userthatthe entry representsßCà Ð߯á Ð evaluatedusing the nominalval-uesfor â . The next threebullets describethe applicationof axiomsthat rewrite this partial derivative in termsof adirection cosine. The remainingbullets explain that thedirectioncosineis equivalent to the function compositionvhat(vsub(...)) .

5.4 Document Assembly

The final outputof ExplainIt! is a documentwhich ex-plainseachpartof thesynthesizedcodein aformatsuitablefor the domainengineer. The structureof the explanationis reflectedin thecomputationalstructureof theapplicativeterm. Thus,explanationsareconstructedfor eachpositionin the applicative term. As a flexible intermediateformat,XML is beingused,becauseit facilities the generationofvariousdocumentformatsand the useof hyper-links al-low to the usertransparentlytracebetweenthe final codeandthe explanationdocument.This is necessary, becausethestructureof thecodedoesnot necessarilycoincidewiththestructureof theapplicative program.For eachsubtermÒ�Ó�Ô Õ ÖC×Â×Ø×ØÖÔ Ù Ú astructuredXML datastructureis generatedasshown in Figure8.

XSLT [8] is usedto producethefinal versionof theex-planationfrom this XML document.XSLT transformsthe

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

function-argumenttagstructurein theXML documentintoHTML with a pargraphcontainingthe explanationof thefunction followed by a bulletedlist of the explanationsofthe arguments. It further processestermswhoseheadismk-mx into tables. The resultingdocumentfor the termmk-mx(2,9, . . . ) in theapplicativetermfrom theprevioussectionis shown in Figure9.

ThisXSLT parsercaneasilybeadaptedtohandlevarioussyntactictransformations.Thus,thebasicstructureof Ex-plainIt! canbeadaptedto otherdomains.ExplainIt! is thusconfigurablein a similar way like Hallgren’s Proof Editor[7], or theILF system[3].

6 Related Work

Over recentyears,automaticcode generationhas be-come a hot topic in various industries, including theaerospaceindustry. A numberof commercialtools arenow availablethat carry out domain-specificcodegenera-tion. MatrixX ã andSimulinkä providegraphicallanguagesfor modeling dynamic systemsfrom which code can begenerated.In essence,however, thesecodegeneratorsarelittle more than domain-specificcompilers. The domain-knowledge embeddedin thesesystemscomesfrom thefactthateachgraphicalconstructcorrespondsto a domain-specificprimitive andcanbe compiledin a 1-to-1 fashioninto code. The mappingin AMPHION/NAV is not 1-to-1.The codegenerationprocessmay involve reasoningoveråfrom Wind River Systemsæfrom MathWorks

8

deepdomainknowledgeandmaymake assumptionsaboutthe currentproblemcontext that will affect the codepro-duced.It is alsonotoriouslydifficult to integratecodegen-eratedusingMatrixX or Simulink with hand-writtencodeasthereis no traceabilitybetweenmodelandcode. AM-PHION/NAV overcomesthis problemthroughits explana-tion mechanism.As furtherwork, we intendto investigatetheproblemof optimizingthegeneratedcode.Thedomaintheory in AMPHION/NAV shouldenabledomain-specificoptimizationsthatcouldnot beachievedusingMatrixX orSimulink.

7 Conclusions

WehavepresentedAMPHION/NAV, adeductivesynthe-sissystemfor the automaticgenerationof stateestimationsoftwarewith Kalmanfilters. We have usedthis systemtosynthesizeroughly a dozengraduate-level textbookexam-plesof single-modegeometricstateestimationsoftwareandvariantsthereof.Theexamplesuseeitheraninertialnaviga-tionsystem(INS,seeourexamplein thetext), or aGPSsys-temasits basis.We haveusedmodelsfor distancemeasur-ing equipment(DME), VOR(measuringtheanglebetweenthe aircraft and a fixed station),GPS,and baro-altimeter.In theseexamples,SNARK couldfind a proof within a fewminutes.

Althoughtherehave beenmany improvementsover theold synthesissystemwith respectto domaincomplexity, us-ability, andgenerationof explanations,thereis still a num-ber of importantissuesto be addressed.During develop-ment of AMPHION/NAV it turnedout that the graphicalspecificationlanguage(which is translatedinto first-orderformulas)is notwell suitedfor thestateestimationdomain.Many examplesrequireaverylargegraphicalspecification,resultingin a low leveragefactorbetweensizeof specifi-cation and size of the synthesizedcode. Furthermore,aconcisesemanticsfor thespecificationlanguageis required.For practicalusability, we will work togetherwith domainexpertson thedevelopmentof apractical,yetconcisespec-ification language.

As describedin the paper, the developmentof the do-maintheoryturnedout to bea centralissuefor our synthe-sissystem.Althoughtheold NAIF domaintheorycouldbereusedin anas-ismanner, a factwhichnicelydemonstratescompositionalityof domaintheories,structureanddevelop-mentprocessfor the domaintheoryneedsto be improvedsubstantially. In particular, for safety-criticaldomains,acareful developmentprocessfor the domaintheory is es-sential,becauseproving correctnessfor an entiredomaintheoryis practicallyimpossible.Currentwork aimsto de-velopa domaintheoryin a muchmorestructuredandfun-damentalway. We areinvestigatingin how far techniquesfrom object-orientedsoftwaredesigncanbeof helpfor our

task. Sucha principleddevelopment,which is embeddedin a highly iterative designprocessalso addressesissuesof interactionbetweenthe domaintheory and the deduc-tive machinery. To avoid unnecessarysearchspaces,whichis an importantprerequisitefor scalability, partsof thedo-main theorywhich copewith calculationsor assemblyofdatastructures(e.g.,matrices)shouldemploy decisionpro-ceduresor proceduralattachmentto thetheoremprover. Ahighly structureddomaintheoryallows us to clearly iden-tify suchparts.

Within theparadigmof deductiveprogramsynthesis,allinformationrequiredto constructtheprogramis containedin the proof. Our experiencewith practicalprogramsyn-thesis,however, showed that synthesizingcodealone,i.e.,without detaileddocumentationis not enough. Hence,indevelopingAMPHION/NAV, mucheffort wasspenton theexplanationsystem. Automaticgenerationof documenta-tion is only afirst step.Futurework will investigatehow fardeductive synthesiscansupportcomputer-supportedcerti-fication of safety-criticalcodeby automaticgenerationofverificationproof obligations,invariants,andotherannota-tions for the synthesizedcodewhich thencanbe checkedby asmallandtrustedproofchecker.

References

[1] R. G. Brown andP. Hwang. Introductionto RandomSig-nalsandAppliedKalmanFiltering. JohnWiley & Sons,3rdedition,1997.

[2] K. CzarneckiandU. Eisenecker. GenerativeProgramming:Methods,ToolsandApplications. AddisonWesley, 2000.

[3] B. I. DahnandA. Wolf. Natural LanguagePresentationandCombinationof AutomaticallyGeneratedProofs, volume3of AppliedLogic Series, pages175–192.Kluwer AcademicPublishers,1996.

[4] A. Gelb, editor. AppliedOptimal Estimation. MIT Press,1974.

[5] M. Genesereth.Knowledgeinterchangeformat,1998.URL:http://logic.stanford.edu/kif/kif.htm l .

[6] C. C. Green. Application of theoremproving to problemsolving. In ProceedingsIntl. Joint Conf. on Artificial Intel-ligence, pages219–240,1969.

[7] T. Hallgren and A. Ranta. An extensibleproof text edi-tor. In Logic for Programmingand AutomatedReasoning(LPAR’2000), volume1955of LNAI, pages70–84.Springer-Verlag,2000.

[8] M. Kay. XSLT Programmer’sReference. Wrox Press,2000.[9] Z. MannaandR.Waldinger. Fundamentalsof deductivepro-

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

[10] G. M. Siouris.AerospaceAvionicsSystems:A modernSyn-thesis. AcademicPress,Inc., 1993.

[11] M. Stickel. The snark theorem prover, 2001. URL:http://www.ai.sri.com/˜stickel/snark. html .

9

[12] M. Stickel, R. Waldinger, M. Lowry, T. Pressburger, andI. Underwood. Deductivecompositionof astronomicalsoft-warefrom subroutinelibraries. In A. Bundy, editor, Proc.12th Conferenceon AutomatedDeduction, Nancy, France,June1994.SpringerVerlagLNCS814.

[13] J. van Baalen, P. Robinson, M. Lowry, and T. Press-burger. Explainingsynthesizedsoftware. In ThirteenthIn-ternational Conferenceon AutomatedSoftware Engineer-ing, pages240–248.IEEEComputerSocietyPress,1998.

10