Amphion/NAV: Deductive Synthesis of State Estimation Software Jon Whittle Jeffrey Van Baalen Johann Schumann Peter Robinson Tom Pressburger John Penix Phil Oh Michael Lowry Guillaume Brat ASE Group: NASA, QSS, RIACS, Kestrel Tech., U. Wyoming NASA Ames Research Center, Moffett Field, CA 94035 1 Introduction Previous work on domain-specific deductive program synthesis [8, 9] described the Amphion/NAIF system for generating Fortran code from high-level graphical specifica- tions describing problems in space system geometry. Am- phion/NAIF specifications describe input-output functions that compute geometric quantities (e.g., the distance be- tween two planets at a point in time, or the time when a radio communication path between a spacecraft and earth is occluded) by composing together Fortran subroutines from the NAIF subroutine library developed at the Jet Propul- sion Laboratory. In essence, Amphion/NAIF synthesizes code for glueing together the NAIF components in a way such that the generated code implements the specification, with a concurrently generated proof that this implementa- tion is correct. Amphion/NAIF demonstrated the success of domain-specific deductive program synthesis and is still in use today within the space science community. However, a number of questions remained open that we will attempt to answer in this short paper, namely: Can the deductive synthesis strategy be extended from the generation of input-output functions to itera- tive, imperative programs without incurring the com- putational complexity penalties entailed by most the- oretical treatments of the formal derivation of imper- ative systems? Can the methodology for developing an Amphion- like program synthesis system be used in other do- mains, particularly where a well-defined component library does not already exist? Can the development of Amphion-like domain- specific program synthesis systems be modularized, with substantial reuse at the intersection of domains? How can the mechanized proof of implementation correctness be used in the software process by end- users unfamiliar with formal methods? In order to investigate these questions, we developed Amphion for a new, much richer domain, namely Guid- ance, Navigation & Control (GN&C) algorithms, in par- ticular single-mode geometric state estimation software for aerospace vehicles. AMPHION/NAV generates code for in- tegrating a model of the vehicle dynamics with a temporal stream of data from multiple sensor sources in a statistically optimal way using one or more Kalman filters [1, 3]. GN&C algorithms are often complex, involving iterative loop algo- rithms and real-time considerations such as extrapolating sensor data so that data is integrated at the same point in time. Although there are standard components available for this domain (e.g., matrix manipulations, Kalman filter al- gorithms), there is no easily defined set of components that cover the domain fully. AMPHION/NAV incorporates the Amphion/NAIF do- main theory as one component in a much larger domain theory, demonstrating a form of theory reuse. In particular, the Amphion/NAIF domain theory provides the formulation of the geometric concepts. AMPHION/NAV is also an up- graded version of the same architecture as Amphion/NAIF, and thus demonstrates reusability across a number of com- ponents including the specification interface and the de- duction engine. AMPHION/NAV incorporates an enhanced back-end code generator suitable for iterative programs, and significantly extends the explanation capabilities of the pre- vious Amphion system [9]. The code generated by AM- PHION/NAV is annotated with detailed explanations de- scribing where each expression in the code came from. These explanations are constructed by tracing automatically through the proof that produced the code and composing explanations for each of the axioms used in the proof. As a result, each program expression can be explained in terms of the concepts in the specification from which they were derived. These explanations are given in the form of hyper- linked text in a standard notation of the GN&C domain. Because GN&C algorithms are often used in safety- critical systems, detailed explanations are crucial to provide
Transcript
Amphion/NAV: Deductive Synthesis of State Estimation Software
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.
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.
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
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
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.
