A Reactive Model-based Programming Language for ... - CSAIL - MIT

A Reactive Model-based Programming Languagefor Robotic Space ExplorersMichel Ingham, Robert Ragno, Brian WilliamsMIT Space Systems Laboratory / Artificial Intelligence LaboratoryCambridge, MA 02139{ingham, rjr, williams}@mit.eduKeywords model-based autonomy, model-basedprogramming, execution, synchronous programming,automated reasoningAbstractModel-based autonomous agents have emerged recentlyas vital technologies in the development ofhighly autonomous reactive systems, particularly inthe aerospace domain. These agents utilize manyautomated reasoning capabilities, but are complicatedto use because of the variety of languages employedfor each capability. To address this problem,we introduce model-based programming, a novel approachto designing embedded software systems. Inparticular, we introduce the Reactive Model-basedProgramming Language (RMPL), which provides aframework for constraint-based modeling, as well asa suite of reactive programming constructs. To conveythe expressiveness of RMPL, we show how it capturesthe main features of synchronous programminglanguages and advanced robotic execution languages.This paper focuses on using the rich behavior modelingof RMPL to provide sequencing and roboticexecution capabilities for spacecraft.1 IntroductionSeveral highly autonomous aerospace systems havebeen recently deployed, and more are currently underdevelopment. Examples include NASA’s DeepSpace One (DS1) spacecraft [1], the next generationof space telescopes [2], and Mars rover prototypes[3]. These systems integrate many of thetools of AI research for automated reasoning: planningand scheduling, task decomposition execution,model-based reasoning and constraint satisfaction.Though these technologies show great promise,there is a likely barrier to the widespread deploymentof this level of autonomy: the numerous softwaretasks running on a spacecraft processor are generallyencoded using a variety of modeling and programminglanguages. These tasks include sequencing,system monitoring, system reconfiguration, planningand low-level control. To illustrate this problem,consider the current state-of-the-art in model-basedautonomy software, Remote Agent (RA). Flightvalidatedon the DS1 spacecraft in 1999, RA iscomposed of three primary components: a Planner/Scheduler,a Smart Executive, and a Mode Identificationand Reconfiguration module known as Livingstone.The complexity of software interfaces was identifiedas a key challenge encountered during the integrationof the RA and the flight software [4]. Furthermore,each of the three component technologiesrequires a distinct knowledge representation, expressedusing different modeling languages. Whilesuch heterogeneous representations have a numberof benefits, including the ability for different softwarecomponents to reason at different levels of abstraction,they also raise several difficulties. Mostsignificant are the possibility for models to diverge,and the need to duplicate knowledge representationefforts. One conclusion from the RA design effortis the desire to head towards a unified representationof the spacecraft, while maintaining the abilityto accommodate the complexities of the spacecraftdomain, and the capacity for knowledge abstraction[5].To address this desire, we introduce the notionof model-based programming, a novel approach todesigning embedded software systems. We also introducea language for encoding model-based programs,the Reactive Model-based Programming Language(RMPL). RMPL combines constraint-basedmodeling with reactive programming constructs, andoffers a simple model of computation in terms of hierarchicalconstraint-based automata. Systems thatmonitor, diagnose and plan using RMPL are discussedin [6] and [7]. The goal of this paper isto show how RMPL leverages the features of bothembedded synchronous programming languages andadvanced robotic execution systems, to provide a

framework for robust spacecraft sequencing. We alsoshow how RMPL forms the basis for a model-basedexecutive providing integrated monitoring, fault protectionand sequencing capabilities.In Section 2, we first introduce the model-basedprogramming paradigm. The RMPL language isthen introduced in Section 3, by describing its principalconstructs and its underlying model of computation.In Section 4, we discuss the compilationand execution of model-based programs, and showhow a model-based executive can be used to enablerobust spacecraft autonomy. To convey the expressivenessof RMPL, in Section 5 we show how it capturesthe main features of synchronous programminglanguages and advanced robotic execution languages.Finally, we conclude by highlighting future work thatwill allow RMPL to be applied to other tasks in automatedreasoning.2 Model-based ProgrammingIn this section we introduce the notion of modelbasedprogramming as an approach to writing softwarefor embedded reactive systems. Figure 1 illustratesthe model-based programming paradigm,as embodied in a model-based executive. The underlyingprinciple is that control programs can bewritten by asserting and checking states which maybe “hidden”, i.e. not directly controllable or observable,rather than by operating on observable andcontrol variables. Such a control program is inputto a sequencing engine, for onboard execution. Anunderlying mode estimation and reactive planninglayer uses a model of the system to deduce the systemstate from the observables, and to figure outhow to achieve a specified goal state. This deductivelayer can reason about states of physical componentsin the system, or abstract states representingsubsystem-level behavior.Model-based programming shares some commonarchitectural themes with the Mission Data System(MDS), under development at the Jet PropulsionLaboratory [8]. In particular, both concepts advocatethat system state and models form the foundationfor monitoring and control. Model-based programmingconcentrates on providing a programminglanguage centered on hidden state, and seamlessly incorporatingpowerful model-based deductive enginesinto the program interpreter.Model-based programming offers the following advantagesover traditional approaches to embeddedsoftware development:Abstraction - By abstracting away the details ofhow a particular state is inferred or achieved, the systemengineer’s knowledge of spacecraft behavior (e.g.as represented in StateCharts [9]) can be convertedControlProgramSystemModelObservationsOnboard SequencerStateestimatesDeductiveMode Estimator &Reactive PlannerFlight System ControlRT Control LayerConfigurationgoalsCommandsFigure 1: Architecture for a Model-based Executiveinto flight code in a more straightforward manner.This is because it is easier to specify a desired statethan the sequence of control actions needed to reachit.Powerful Inference Engines - The model-basedprogramming paradigm leaves the challenging tasksof state estimation and state achievement in thehands of powerful model-based deduction engines,such as those introduced in [10] and [11]. Such enginesoffer more flexibility and robustness than thetraditional rule-based engines commonly deployed inflight software.Modularity - Because of its use of modular systemmodels, flight software written as a model-basedprogram can accommodate component-level modificationslate in the spacecraft design cycle. New componentmodels can be swapped in without having torewrite significant sections of flight code. Furthermore,modularity within the deductive layer allowsfor transparent upgrading of the engines used formode estimation and reactive planning, when morepowerful ones become available.Model Reusability - Another benefit to the use ofmodular system models is that the component-levelmodels can be reused. Over time, a database of modelsfor different subsystems and component designscan be assembled, dramatically reducing the need forsingle-use flight code.Verifiability - As a consequence of being able towrite control code in terms of states, model-basedprogramming results in cleaner code that is easier toverify. Ease of verification is also a feature of thesystem models, which can be built up directly fromsystem engineering specifications of hardware or softwarecomponents.

(thrust = zero) AND(power_in = zero)(thrust = zero) AND(power_in = nominal)(thrust = full) AND(power_in = nominal)Engine ModelOffStandbyFiringoff -cmdstandby -cmdstandby -cmd0.01fire -cmd0.01FailedOrbitInsert ()::(do -watching ((EngineA = Firing) OR ( EngineB = Firing))(parallel(EngineA = Standby)(EngineB = Standby)(Camera = Off)(do -watching (EngineA = Failed)(when -donext ( (EngineA = Standby) AND(Camera = Off) )(EngineA = Firing) ))(when -donext ( (EngineA = Failed) AND(EngineB = Standby) AND(Camera = Off) )(EngineB = Firing) )))Figure 2: State transition model for an engineModel-based Programming ExampleTo demonstrate the applicability of model-based programmingto the field of spacecraft execution, weconsider the representative mission scenario of performingan orbital insertion maneuver. As shown inFigure 1, a model-based program specifies two inputs,a control program and a system model. Thesystem model is composed of component-level models.In our example, we consider a simplified spacecraftmodel, consisting of two identical redundant engines(EngineA and EngineB) and a science Camera.The state transition model for an engine is shown inFigure 2. Nominally, an engine can be in one ofthree modes: off, standby, or firing. Each of thesemodes is described by a set of constraints on thethrust and power in variables. The engine also hasa failed mode, capturing any off-nominal behavior.Transitions between nominal modes are triggered oncommands, as shown in the figure. Transitions intothe failed mode are considered to be probabilistic,with a 1% chance of failure from both the standbyand firing modes. The Camera can be in one of twomodes, on or off, with corresponding “turn-on” and“turn-off” transitions. This type of transition systemmodel is similar to the one used in Livingstone[10].The control program in Figure 3 specifies statetrajectories for the orbital insertion maneuver. Thespecific RMPL constructs used in the program areintroduced in Section 3. In order to execute the orbitalinsertion, both engines must be set to standbymode and one of the two engines must be fired. Priorto firing an engine, the camera must be turned off,for fear of plume contamination of its sensitive optics.Should the first engine fail to fire correctly, thebackup engine should be commanded to fire instead.To express this, our control program must be able torepresent the following types of behavior:1. conditional branching - The control codemust check for two conditions, prior to firing itsFigure 3: RMPL Control Program for the OrbitalInsertion Scenarioengine: that the engine to be fired is in standbymode, and that the camera is turned off.2. iteration - Should the above two conditionstake some time to be achieved, the control programshould wait for both to become true, requiringan iteration on the condition check.Also, while the primary engine is firing, theremust be a continuous check for engine failure.3. preemption - If the primary engine fails, theact of firing it should be preempted, in favor offiring the backup engine.4. concurrency - The following tasks should beperformed in parallel: setting each engine tostandby mode, turning off the science camera,checking for completion of these actions prior tofiring the primary engine, and checking for primaryengine failure.These types of behaviors are common to embeddedprogramming. The key distinction in our modelbasedcontrol programs is that we refer directly tohidden variables in the plant. Furthermore, we wouldlike to express the spacecraft state transition modelsdescribed above using a language common to boththe system models and the control program. Such alanguage would need to be able to specify deterministicand probabilistic transitions, as well as qualitativeconstraints describing the behavior in each mode. Inthe next section, we introduce a language expressiveenough to encode all these types of behavior.3 The RMPL LanguageRMPL is an object-oriented language that allows adomain to be structured in a variety of ways – forexample, through a component or process hierarchy.RMPL enables modeling of complex elements of adomain through an object hierarchy that includessubclassing and multiple inheritance.RMPL programs may be viewed as specificationsof deterministic state transition systems, which act

on the plant by asserting and checking constraintsexpressed in a propositional state logic. The propositionsare assignments of state variables to valueswithin their domains. Reactive combinators allowflexibility in expression of complex system behaviorand dynamic relations.3.1 RMPL ConstructsThe constructs of RMPL are similar to those developedin TCC, a language for timed concurrentconstraint programming [12]. RMPL constructs arestated as operator-prefixed, parenthesis-enclosed expressions.These expressions may be arbitrarily composedwith each other. An RMPL program is a singleexpression built up from simpler expressions. Theconstructs rely on the system state knowledge, consistingof a set of value assignments to all state variables.A constraint is entailed if it is implied bythe current state knowledge, and not entailed otherwise.Entailment is denoted by simply stating theconstraint, non-entailment is denoted by using anoverbar. Note that non-entailment of c (c) is notequivalent to entailment of the negation of c (NOTc) – the current state knowledge may not imply c tobe true or false. The following are the key constructsin the language:constraintConstraint is expressed as a well-formed-formula instate logic. The simplest constraint expression is anassertion of the state of a variable, such as (thrust =full). More complex constraints can be created usingthe logical connectives NOT, AND, and OR. Theconstants true and false are also valid constraints.Note that the same form is used for both checkingconstraints and asserting constraints.(PARALLEL exp 1 exp 2 . . . )Concurrency. Execution of each expression exp i isinitiated concurrently.(SEQUENCE exp 1 exp 2 . . . )Sequence. Starting with i = 0, executes expressionexp i until completion, and then initiates expressionexp i+1 in the next time step. Terminates when thelast expression terminates.(ALWAYS exp)Iteration. Expression exp is initiated at every timestep.(IF-THENNEXT-ELSENEXT c exp then exp else )Branch. If constraint c is entailed, then executesexpression exp then in the next time step. Otherwise(if c is not entailed), executes expression exp else inthe next time step.(UNLESS-THENNEXT constraint exp)Guarded transition. Unless constraint is entailed,expression exp is executed in the next time step.(WHEN-DONEXT constraint exp)Temporally-extended guarded transition. Wait untilconstraint is entailed, then execute expression expin the next time step.(WHENEVER-DONEXT constraint exp)Iterated guarded transition. Wait until constraintis entailed, then execute expression exp in the nexttime step. This trigger can repeat indefinitely.(DO-WATCHING constraint exp)Preemption. Executes expression exp until completionor until constraint is entailed. If and whenconstraint is entailed, the execution of expressionexp is halted at the beginning of the step in whichconstraint is entailed.Constructs also exist to represent probabilistic andreward-producing transitions [6]. Other higher-levelconstructs can be constructed from the above.3.2 Hierarchical Constraint AutomataTo support efficient execution or reasoning, RMPLcode is compiled into hierarchical constraint automata(HCA). Figure 4 shows the HCA structuresrepresented by various RMPL constructs. HCA consistof nodes (called locations) that may assert constraints,and directed edges (called transitions) thatmay have associated guard conditions. Groups oflocations may also have associated maintenance constraints.The transition guards and maintenanceconstraints may either indicate entailment or nonentailment.HCA are hierarchical in that a transitionmay connect a location to either another location oran HCA. A subset of the locations in an HCA aredesignated as start locations. These start locationsserve as ”entry points” into the automaton duringtheir execution. The HCA execution process is describedin the following section.4 Compilation and Executionof Model-based ProgramsIn this section, we show how a control programwritten in RMPL is compiled to HCA, and discusshow an HCA is executed. To illustrate this processclearly, we return to our motivating examplefrom Section 2. Figure 3 shows how the orbital insertioncontrol code looks when encoded in RMPL.The RMPL compiler takes this code as an input, andoutputs the corresponding HCA system (see Figure5). It should be noted that the compilation processtakes place offline. Only the resulting HCA model isloaded onto the onboard flight processor for eventualexecution.The current execution threads in the HCA systemare represented by a set of “marked” locations. Executionof an HCA consists of stepping through the

cc(parallel A B )AB(if-thennext-elsenext c A B )_c AcB(always A)A_ (when-donext c A)cc A(whenever-donext c A)c AEAS1,2EBS1,2CO1(EAS AND CO)MAINTAIN (EAR OR EBR)LEGEND:EAS (EngineA = Standby)EAF (EngineA = Failed)EAR (EngineA = Firing)EBS (EngineB = Standby)EBF (EngineB = Failed)EBR (EngineB = Firing)CO (Camera = Off)MAINTAIN (EAF)EAREAS AND CO1,2 3,4(unless-thennext c A)c _A(do-watching c A)_MAINTAIN( c )A(EAF AND EBS AND CO)1,2,3,4EAF AND EBSAND COEBRFigure 4:forms.HCA representations of various RMPLFigure 5: HCA model for the Orbital Insertion Scenario(markings for nominal execution are labeled inred)HCA, beginning from the start locations, and takingall enabled transitions from each currently markedlocation. Steps are performed synchronously, withall possible transitions assumed to be simultaneous.If a location transitions to an HCA, that HCA isinitialized (by marking its start locations). This allowsthe initiation of components of the hierarchicalstructure.The algorithm for executing an HCA model canbe described as follows:1. Initialize HCA system by marking all start locations.2. Assert states from the currently marked locations(as well as any active maintenanceconditions specified by an encapsulating “dowatching”).The reactive planner deduces a sequenceof actions to eventually achieve each ofthe asserted system states, and issues the firstset of commands in the sequence.3. Obtain from the mode estimation module an updateof the system states.4. Take enabled transitions. A location’s transitionsare enabled if (1) the location’s state assignmenthas been achieved, and (2) the transitionconditions and maintenance conditions currentlyhold true.5. Mark new set of locations, delete previous set ofexpired markings, and return to step 2.HCA Execution ExampleTo illustrate the process of executing HCA, we considera nominal (i.e. failure-free) execution trace fromour example scenario. In Figure 5, markings are representedby small numbered labels adjacent to eachlocation. The numbers correspond to the order ofexecution steps, e.g. the location which asserts thestate (EngineA = Standby) is marked in both thefirst and second steps.Initially, all start locations are marked. The startlocations are those labeled with “1”. The followingstate assignments are asserted by the start locations:EngineA=Standby, EngineB=Standby andCamera=Off. The maintenance condition to bechecked throughout the process of achieving thesestates is the non-entailment of (EngineA=FiringOR EngineB=Firing). These state assignments andmaintenance conditions are sent to the reactive planner,which generates the sequence that achieves thegoal state, and issues the first set of commands inthe sequence.The enabled transitions of the currently markedlocations are then taken. In our example, we assumethat turning a camera off is a one-step operation,whereas putting an engine into standby moderequires two steps (the intermediate step might beto turn on a valve driver, for instance). Consequently,the locations asserting (EngineA=Standby)and (EngineB=Standby) remain marked in the nextexecution step (labeled “2” in Figure 5). Since Camera=Offhas been achieved within a single step (asconfirmed by the mode estimator), and there areno specified transitions from the location that assertedthis state, this thread of execution terminates.The last two markings from execution step “1”, correspondingto “when-donext” condition checks, remainmarked at step “2”, as the only currently enabledtransitions from these locations are the self-

transitions.At step “2”, the reactive planner issues the secondset of actions in the sequence for achieving(EngineA=Standby) and (EngineB=Standby). Assumingthese actions are successfully performed, themode estimation module indicates that the (EngineA=Standby)and (EngineB=Standby) conditionsare achieved. This results in termination of thetwo execution threads corresponding to these stateachievement requests, and enabling of the transitionlabeled with the condition (EngineA=StandbyAND Camera=Off). Note that the maintenanceconditions associated with this transition, correspondingto non-entailment of (EngineA=Failed),and non-entailment of (EngineA=Firing OR EngineB=Firing),still hold true.After taking the enabled transitions, only two locationsare marked at step “3”. One of these markedlocations asserts (EngineA=Firing). This state assignmentis sent to the reactive planner, which generatesthe two-step sequence that achieves this state,and issues the first set of commands in the sequence.Finally, at step “4” the reactive planner issues thesecond set of commands required to achieve (EngineA=Firing),and the mode estimation module infersthat the engine is indeed firing. Since this violatesthe high-level maintenance condition beingwatched for, the entire block of Figure 5 is exited.Note that since no engine failure occurred duringthis process, the thread of execution waiting for (EngineA=Failed)did not advance from its start location.5 Expressiveness of RMPLTo serve as the foundation for the development of amodel-based execution framework, RMPL must providecertain key features of other languages usedfor embedded robotic systems. Expressiveness isachieved through the combination of constraintbasedmodeling and recent advances in two differentdomains: synchronous programming, used in manyindustrial embedded reactive systems, and roboticexecution languages, used to provide robust sequencingcapabilities for ground-based robots and autonomousspacecraft.In this section, we highlight the relevant aspectsof each of these two domains to the design of RMPL,and provide a rough mapping of these features toconstructs in RMPL.5.1 Synchronous ProgrammingLanguagesThe field of synchronous programming offers a classof languages developed for writing control programsfor embedded reactive systems. Esterel, Lustreand Signal are synchronous programming languagesthat have been deployed for industrial applications[13, 14]. The widely used StateCharts graphicalspecification formalism [9] shares key aspects of thesynchronous programming model. In the design ofRMPL, certain key ideas from the synchronous programmingdomain have been leveraged. In this section,we highlight the similarities and fundamentaldifferences between RMPL, and one widely-used synchronouslanguage, Esterel.First we consider similarities between the two languages.Both include standard constructs for expressingreactive system behavior, such as conditionalbranching, iteration, parallel composition, sequentialordering and preemption. Figure 6 providesa mapping between constructs in Esterel and the correspondingRMPL forms. Both languages compileto underlying automaton models with clean mathematicalsemantics. They both emphasize modularityin software design: Esterel uses the ‘module’as its programming unit, while RMPL uses the notionof ‘class’ objects. Finally, like Esterel, RMPL isfully orthogonal, meaning that the constructs can benested and combined arbitrarily.Despite the similarities between the two languages,there exist some fundamental differences in their correspondingphilosophy:• Esterel is very much a “signal-based” language,whereas RMPL is a “state-based” language.Rather than thinking in terms of signals, asis the case for Esterel, we consider the notionof hidden system states to be the fundamentalbasis for execution with RMPL. This differentpoint of view is attributable to the differentapplication domains targeted by the two languages.For Esterel, which is designed to providecoordination and synchronization between computationalprocesses, signals and events are themost appropriate basic mechanisms. RMPL’stask, which is to provide a framework for monitoringand control of complex dynamic plants,lends itself to thinking more naturally in termsof state evolution.• The availability of instantaneous broadcastingand control transmission in Esterel makes it possibleto write syntactically correct but semantically“non-sensical” programs [13]. RMPL’smore strict use of execution steps avoids thesecausality problems.• The intent of Esterel is to provide the functionalityof a full programming language, includingexternal function and procedure calls,and external task execution. RMPL’s scope isfocused towards providing the functionality requiredto evolve the state of a complex system.

ConstructDescription Esterel RMPL1-step delay pause truehalting halt (ALWAYS true)sequencing body1 ; body2 (SEQUENCE body1 body2 )conditionalif exp then body1else body2end(IF-THENNEXT-ELSENEXT expbody1 body2 )concurrency body1 || body2 (PARALLEL body1 body2 )await await S(DO-WATCHING S(ALWAYS true))await-dotrap definitionweak abortabort withhandlerguarded loopawait S dobodyendtrap id inbodyendweak abortbodywhen Sabortbody1when S dobody2endevery S dobodyend(WHEN-DONEXT Sbody )(DO-WATCHING (exit=true)body )(DO-WATCHING (exit=true)(PARALLELbody(WHEN-DONEXT S(exit=true) )))(PARALLEL(DO-WATCHING S body1 )(WHEN-DONEXT S body2 ))(WHENEVER-DONEXT S(DO-WATCHING Sbody ))Figure 6: Corresponding constructs in Esterel andRMPLIt currently relies less heavily on code writtenin an external “host” language. Future deploymentof RMPL to various applications will revealwhether the additional capability providedby such external links warrants extension of thelanguage.5.2 Robotic Execution LanguagesState-of-the-art spacecraft sequencers, like the SmartExecutive flown as part of the Remote Agent Experimenton Deep Space One [15], are used to coordinatethe run-time activity among the different softwaremodules within a control system. They must be ableto respond quickly to events while bringing potentiallylarge amounts of information (both knowledgeand run-time data) to bear on their decisions [16].Robust executives are becoming even more essentialas autonomous agents of increasing capability are developed.The robotic execution languages used to encodeadvanced sequencing engines (e.g. RAPs [17],TDL [18]) provide constructs for managing interactingparallel goal- and event-driven processes.We consider the example of the Remote AgentExecutive. It is written in a rich procedural language,Execution Support Language (ESL), whichis an extension to multi-threaded Common Lisp.ESL provides the following features, allowing the encodingof execution knowledge into embedded autonomousagents [16]: contingency handling, timekeeping,task management, goal achievement, logicaldatabase querying, and resource management.Through its rich set of reactive constructs, RMPLprovides most of these features. By combining itspreemption constructs (e.g. “do-watching”) with thehidden state diagnosis capability provided by the underlyingdeductive layer, mechanisms for identifyingand recovering from failure contingencies and specifyingcleanup procedures can be built.Task management capabilities, such as spawningnew concurrent tasks, aborting tasks, setting up tasknetworks and defining guardian tasks (for task monitoring)are provided by RMPL’s parallel compositionand preemption constructs. Task synchronizationfeatures, including signaling and waiting for particularevents, take on a different meaning in a modelbasedprogramming language like RMPL: as long asthe “events” can be represented as changes to systemstates, they are straightforwardly accommodated.The mechanisms for specifying and commandinggoal achievement methods are provided by the underlyingreactive planning layer, in the model-basedprogramming framework. The capacity for a modelbasedexecutive to perform sequencing at the levelof system state specifications, and to abstract awaythe details of how states are achieved, is considereda significant benefit, as discussed in Section 2.Similarly, the need to explicitly maintain, queryand reason about a distinct logical database is madeobsolete by the presence of a transparent underlyingmode estimation layer, which maintains the latestsystem state knowledge, and provides the sequencerwith all the state information it requires.The dominant features that the current incarnationof RMPL cannot adequately provide are timerelatedutilities (such as event scheduling, timeoutdefinitions or warping), and advanced property lockingmechanisms (resource interactions between concurrenttasks). It should be noted that RMPL doesprovide the ability to perform basic resource management,using the preemptive constructs to triggerwhen a certain property, expressed in terms ofstate assignments, is no longer entailed. Incorporationof timing-related constructs and more advancedresource management features is a focus of currentwork.6 ConclusionWe have discussed the design of a model-based executive,consisting of a sequencing layer coded in RMPLand compiled down to HCA, and an underlying deductivelayer providing mode estimation and reactiveplanning capabilities, based on models of thesystem expressed in RMPL. In the current design of

the model-based executive, the sequencing layer andthe deductive layer are distinct. One of the eventualgoals of this research task is the integration of bothcapabilities into a unified system, which will allowus to perform monitoring, diagnosis and reconfigurationon the same HCA models that are executed,eliminating the need for separately maintaining thecontrol program and the system models.The ultimate goal of this research effort is to arriveat a fully integrated autonomous system, whichuses a unified system representation to provide highlevelplanning and scheduling capabilities, in additionto robust sequencing and configuration management.To this end, a temporal planning capabilitybased on an extension of RMPL (including thenotions of metric time, temporally bounded activityspecifications and non-deterministic choice) is currentlyunder development [7]. In addition, to addressthe problem of monitoring and controlling systemswhich must be described using continuous dynamics,a hybrid version of RMPL is under development[19]. This Hybrid Model-based Programming Languageincorporates the notion of continuous variableswith RMPL’s reactive programming and constraintbasedmodeling features.7 AcknowledgmentsThis research was supported in part by the DARPAMOBIES program under contract F33615-00-C-1702, and by NASA’s Cross Enterprise TechnologyDevelopment program under contract NAG2-1466.References[1] Muscettola, N. et al., “Remote Agent: ToBoldly Go Where No AI System Has GoneBefore”, Artificial Intelligence, 103(1-2):5-48,1998.[2] Ingham, M. et al., “Autonomous Sequencingand Model-based Fault Protection for Space Interferometry”,Proc. of iSAIRAS-2001, 2001.[3] Washington, R. et al., “Autonomous Roversfor Mars Exploration”, Proc. of the IEEEAerospace Conference, 1999.[4] Nayak, P.P. et al., “Validating the DS1 RemoteAgent Experiment”, Proc. of iSAIRAS-1999, 1999.[5] Bernard, D.E. et al., “Design of the RemoteAgent Experiment for Spacecraft Autonomy”,Proc. of the IEEE Aerospace Conference, 1999.[6] Williams, B.C., Chung, S., and Gupta, V.,“Mode Estimation of Model-based Programs:Monitoring Systems with Complex Behavior”,To appear in Proc. of IJCAI-2001, 2001.[7] Kim, P., Williams, B.C., and Abramson, M.,“Executing Reactive, Model-based Programsthrough Graph-based Temporal Planning”, Toappear in Proc. of IJCAI-2001, 2001.[8] Dvorak, D. et al., “Software ArchitectureThemes in JPL’s Mission Data System”, Proc.of the AIAA Guidance, Navigation, and ControlConference and Exhibit, Portland, OR, 1999.[9] Harel, D., “Statecharts: A Visual Approach toComplex Systems”, Science of Computer Programming8:231-274, 1987.[10] Williams, B.C. and Nayak, P.P., “A ModelbasedApproach to Reactive Self-ConfiguringSystems”, Proc. of AAAI-96, pp.971-978, 1996.[11] Williams, B.C. and Nayak, P.P., “A ReactivePlanner for a Model-Based Executive”, Proc. ofIJCAI-97, 1997.[12] Saraswat, V., Jagadeesan, R., and Gupta,V., “Foundations of Timed Concurrent ConstraintProgramming”, Proc. of the Ninth AnnualIEEE Symposium on Logic in ComputerScience, 1994.[13] Berry, G., The Esterel v5 Language Primer, version5.21 release 2.0, Centre de MathematiquesAppliquees, Ecole des Mines and INRIA, April6, 1999.[14] Halbwachs, N., Synchronous Programming ofReactive Systems, Kluwer Academic Publishers,1993.[15] Pell, B. et al., ”The Remote Agent Executive:Capabilities to Support Integrated RoboticAgents”, Proc. of the AAAI Spring Symposiumon Integrated Robotic Architectures, 1998.[16] Gat, E., “ESL: A Language for Supporting RobustPlan Execution in Embedded AutonomousAgents”, Proc. of the AAAI Fall Symposium onPlan Execution, 1996.[17] Firby, R.J., Adaptive Execution in Dynamic Domains,Ph.D. Thesis, Yale University Departmentof Computer Science, 1989.[18] Simmons, R. and Apfelbaum, D., “A task DescriptionLanguage for Robot Control”, Proc. ofthe Conference on Intelligent Robotics and Systems,Vancouver, Canada, October 1998.[19] Williams, B., Hofbaur, M., and Jones, T.,Mode Estimation of Probabilistic Hybrid Systems,MIT Space Systems Laboratory Report#6-01, Massachusetts Institute of Technology,May 2001.