Remote Agent Experiment ] http ://rax. arc. nasa. go v Doug Bernard ([email protected]) JPL (818) 354-2597 Gregory A. Dorais ([email protected]) NASA ARC (650) 604-485 ! Ed Gamble (Edward.B.Gamble-Jr@]pl.nasa.gov) JPL (818) 354-5387 Bob Kanefsky ([email protected]) NASA ARC (650) 604-3514 James Kurien (kurien @ptolemy.arc, nasa. gov) NASA ARC (650) 604-4745 William Millar (millar @ptolemv.arc.nasa.gov) NASA ARC (650) 604-0263 Nicola Muscettola (mus @ptolemy.arc, nasa. gov) NASA ARC (650) 604-4744 Pandu Nayak ([email protected]) NASA ARC Nicolas Rouquette (Nicolas.F.Rouquette @jpl.nasa.gov) JPL (818) 354-9600 Kanna Rajan (karma @ptolemy.arc, nasa. gov) NASA ARC (650) 604-0573 Ben Smith (smith @aig.jpl.nasa.gov) JPL (818) 393-5371 Will Taylor (taylor @ptolemy.arc.nasa.gov) NASA ARC (650) 604-3364 Yu- Wen Tung (yu- wen. tung @jpl. nasa. gov) JPL (818) 354-2673 Deep Space 1 TECHNOLOGY VALIDATION SYMPOSIUM February 8-9, 2000(cid:0)Pasadena, CA Table of Contents Extended Abstract ........................................................................................................................................... 1 Remote Agent Experiment Fact Sheet ............................................................................................................ 3 The Remote Agent .......................................................................................................................................... 4 Technology Overview ................................................................................................................................. 4 Detailed Validation Objectives ................................................................................................................... 6 Performance Envelope ................................................................................................................................ 6 Technology Details ..................................................................................................................................... 7 Subsystem Interdependencies .................................................................................................................... 12 Preparing Lisp for Flight ........................................................................................................................... 13 The Remote Agent Experiment ..................................................................................................................... 13 Historical Perspective ................................................................................................................................ 14 Domain models ......................................................................................................................................... 15 Experiment Scenarios ................................................................................................................................ 18 RAX development ..................................................................................................................................... 18 Ground Tests ............................................................................................................................................. 19 Ground Tools ........................................... :................................................................................................ 2I Flight Test ................................................................................................................................................. 23 Effectiveness of the development and test process ................................................................................... 24 Costing ...................................................................................................................................................... 27 Lessons Learned ........................................................................................................................................ 27 Answers to a Project Manager's questions ................................................................................................ 29 Future Applications ....................................................................................................................................... 3! Acknowledgements ....................................................................................................................................... 31 References ..................................................................................................................................................... 32 Appendix A: Telemetry Channels ................................................................................................................. 33 Appendix B: DSI Technology Validation Power On Times ......................................................................... 33 Appendix C: Acronym Definitions ............................................................................................................... 33 o°° 111 Remote Agent Experiment Validation EXTENDED ABSTRACT system (EXEC), and the Mode Identification and Recovery (MIR) system for model-based fault diagnosis and recovery. Remote Agent (RA) is a model-based, reusable artificial These component technologies are described briefly below. intelligence (AI) software system that enables goal-based PS--PS generates the plans that RA uses to control the spacecraft commanding and robust fault recovery. RA was spacecraft. Given the initial spacecraft state and a set of flight validated during an experiment on board of DSI goals, PS generates a set of synchronized high-level tasks between May 17thand May 21th, 1999. that, once executed, will achieve the goals. PS consists of a heuristic chronological-backtracking search engine Technology Overview operating over a constraint-based temporal database. PS begins with an incomplete plan and expands it into a RA can operate at different levels of autonomy, allowing complete plan by posting additional constraints in the ground operators to interact with the spacecraft with database. These constraints originate either from Ground, immediate commands to the flight software, if needed. which imposes them directly on the goals, or from However, one of the most unique characteristics of RA, and constraint templates (e.g. the camera must be pointed at an a main difference with traditional spacecraft commanding, asteroid to take a picture of it) stored in a model of the is that ground operators can communicate with RA using spacecraft. PS queries domain-specific planning experts goals (e.g. "During the next week take pictures of the (specialized software modules such as Deep Space One's following asteroids and thrust 90% of the time") rather than navigation system) to access information that is not in its with detailed sequences of timed commands. RA determines model. a plan of action that achieves those goals and carries out that plan by issuing commands to the spacecraft. Actions are EXEC--EXEC is a reactive, goal-achieving, control system represented with tasks that are decomposed on the fly into that is responsible for: more detailed tasks and, eventually, into commands to the • Requesting and executing plans from the planner. underlying flight software. When discrepancies are detected between the desired state and the actual state, RA detects, • Requesting/Executing failure recoveries from MIR • Executing goals and commands from human interprets and responds to the anomaly in real time. More serious anomalies can be addressed with longer response operators. times, by generating a new plan of action while the • Managing system resources. spacecraft is kept idle in a safe configuration. When the new • Configuring system devices. plan is generated, the spacecraft is taken out of the safe • System-level fault protection. configuration and execution resumes normally. • Achieving and maintaining safe-modes as necessary. RA differentiates itself from traditional flight software EXEC is goal-oriented rather than command-oriented. We because it is model-based. In traditional software programs define a goal as a state of the system being controlled that and expert systems, the programmer decides what the result must be maintained for a specified length of time. As a of a program should be and writes down instructions or simple example, consider the goal: keep device A on from rules that attempt to achieve those results. The computer time x to time y. If EXEC were to detect that device A is off simply executes the instructions or fires the rules with no during that period, it would perform all the commands knowledge of what the intended result was or how it is necessary to turn it back on." EXEC controls multiple achieving it. Each component of RA instead operates on processes in order to coordinate the simultaneous execution models, general descriptions of the behavior and structure of of multiple goals that are often inter-dependent. In order to the spacecraft it is controlling. Each RA component solves execute each goal, EXEC uses a model-based approach to problems by accepting goals and using appropriate create a complex command procedure designed to robustly reasoning algorithms on its models to assemble a solution achieve the goal. that achieves the goals. The reasoning algorithms are MIR--The MIR inference engine provides mode general-purpose and remain unchanged across different identification (diagnosis) and mode reconfiguration deployments of RA. For different applications, the parts that (recovery) functionality. To track the state of each change are the models and, possibly, the problem-solving component (called a mode) in the spacecraft MIR control knowledge needed by some RA modules to tune eavesdrops on commands that are sent to the spacecraft performance. hardware by EXEC. As each command is executed, MIR Remote Agent Component Technologies receives observations from spacecraft's sensors, abstracted by monitors in the spacecraft's control software. MIR combines these commands and observations with Remote Agent integrates three separate technologies: an on- declarative models of the spacecraft components to board planner-scheduler (PS), a robust plan execution determine the current state of the system and report it to \ EXEC. If failures occur, MIR uses the same model to find a preparing a plan on the ground and uplinking it to the repair or workaround that allows the plan to continue spacecraft for execution; and providing closed-loop execution. planning and execution on-board the spacecraft. The final validation objective was the first formulation of a The key idea underlying model-based diagnosis is that a development and testing plan for an autonomous flight combination of component modes is a possible description software system. of the current overall state of the spacecraft only if the set of models associated with these modes is consistent with the observed sensor values. This method does not require that Test Program and Results all aspects of the spacecraft state be directly observable, providing an elegant solution to the problem of limited The Remote Agent Experiment (RAX) consisted of using observability. the RA technology to operate the DSI spacecraft for several days. We developed a series of operations scenario based on DSI actfve cruise mode. In these scenarios RAX Risks commanded a subset of the spacecraft subsystems: Ion Propulsion System (IPS), Miniature Integrated Camera RA is flight software and as such poses the same kind of and Spectrometer (MICAS), Autonomous Navigation risks posed by conventional flight software. (NAV), Attitude Control System (ACS) and a series of The autonomous behavior implemented by RA is not power switches. The goals in the main scenario were to qualitatively different from that displayed by conventional execute an IPS thrust arc, acquire optical navigation fault protection or attitude control. In all cases, the images as requested by the autonomous navigator, and spacecraft is commanded on the basis of current state respond to several simulated faults. The faults included information rather than by direct operator commands. The minor ones that could be responded to without disrupting behavior of RA can be predicted, within an envelope, just as the current plan, and more serious faults that required the behavior of fault protection or attitude control can be generating a new plan to achieve the remaining goals. We predicted within certain bounds. Confidence in the RA's adopted a continuous integration approach in which new responses can be obtained through testing, just as features or bug fixes were integrated in new releases only confidence in fault protection or attitude control is obtained after the integrated system could successfully run the reference scenarios on all available testbeds. We also now. conducted an extensive formal testing program, separate A risk addressed by the experiment concerns the integration from the software development process. Testing was and testing of the technology. RA in a novel integration of distributed on several different platforms of different three technologies and their application to spacecraft is also speeds, level of fidelity and availability to the RA team. new. For this reason there was no prior experience on Test cases were targeted to the most available testbed that development and validation methodologies for such a could validate them with the reasonable expectation that system. Another risk had to do with the integration of the AI the test result would hold on higher fidelity testbeds. technologies of RA, based on general-purpose search algorithms, together with real-time control software on a In spite of a couple of bugs that occurred during the flight flight processor. experiment, RA successfully demonstrated 100% of its flight validation objectives. Validation Objectives Applicability to future NASA missions The first validation objective was to demonstrate RA's ability to autonomously operate a spacecraft with The Remote Agent technology is applicable to any future communication from ground limited to few high-level goals. NASA mission that desires or requires autonomous This translated into specific objectives for PS, EXEC and operations. The RA reasoning engines can be used as-is on MIR. The second validation objective was to show that RAt • future missions. New domain models would be required for could be commanded with different levels of autonomy. each mission. This meant supporting all of the possible operation modes: using EXEC to run a traditional sequence of commands; 2 Remote Agent Experiment Fact Sheet Point of Contact Retnote Agent Douglas E. Bernard Estimated Spacecraft Avionic Systems Engineering State and Jet Propulsion Laboratory I-818-354-2597 Plan Database douglas.e, bernard @jpl.nasa. gov Observations and Command Responses [ Models of Remote Agent Spacecraft, Reasoning Engines Flight rules Planner/ Spacecraft Schedule= Flight Software Smart Executive and Hardware State Estimator/ Systems Recovery Expert (Livingstone) Low-level Commands Goals, high or low-level commands Ground Control Validation Objectives Capabilities •Robust Goal-based commanding _ .Initiate and generate flexible plans on-board •Reject low-priority, unachievable goals -Planner expands high-level goals into flexible plans -Executive decomposes plans into low-level _ .Execute plans generated both on-board and from Ground spacecraft commands and monitors that the states •Confirm execution of commands commanded to are achieved and maintained •Fail-operational model-based fault recovery _ .Demonstrate model-based failure detection and recovery •Maintain required spacecraft states in the face of failures -Livingstone identifies faults and suggests recoveries that the Executive uses to continue plan execution _ .Re-plan following a failure •Generate back-to-hack plans -If necessary, Executive requests the Planner to generate anew plan in light of failure _/ .Modify mission goals from Ground Applicabilit_ to future missions _ .Execute low-level commands from Ground •Update estimated spacecraft state database from Ground Remote Agent technologies are generally applicable to mission that benefit from highly autonomous operation and are currently being applied to prototypes of future NASA missions including aspace-based interferometer and an in-situ propellant production plant. \ THE REMOTE AGENT also allowed a clear methodology for testing and validating the RA software on the ground. Remote Agent is a model-based, reusable artificial We now describe the main functionalities provided by RA intelligence (Ai) software system that enables goal-based and how each individual RA component participates in the spacecraft commanding and robust fault recovery. This overall picture. We will do so by giving concrete examples report describes the Remote Agent technology, its of commanding and operations relative to DSI. development and test history and the DSI flight experiment in which Remote Agent was validated. Whenever feasible, As we will discuss later. RA can operate at different levels this report attempts to give guidance on how Remote Agent of autonomy, allowing ground operators to interact with the can be fruitfully employed in future science missions. We spacecraft with immediate commands to FSW, if needed. also highlight further technology developments and However, one of the most unique characteristics of RA, and a main difference with traditional spacecraft commanding, operational applications of the technologies that we are currently pursuing. is that ground operators can communicate with RA at the goal level rather than having to formulate detailed sequences of timed commands. Goals are stored in MM in a Technology Overview mission profile covering an extended period of time. In principle, a mission profile could contain all goals for a The Remote Agent (RA) integrates three separate Artificial mission, requiring no further uplink from ground. More Intelligence technologies: automated planning and realistically, mission operations will want to change goals scheduling, robust multi-threaded execution, and model- (e.g., the schedule of communications with DSN can be based fault diagnosis and recovery. modified on a week by week basis). This can be easily accomplished by uplinking commands to edit the mission profile. Goals typically contain very little detail of how they should be achieved. For example, for the DSI Remote Agent Experiment the only goals in the mission profile were "Perform AutoNAV orbit determination (OD) activities for I hour every day" and "Thrust the IPS engine for at most 12 hours". To translate high,level goals into a stream of commands to flight software, RA follows a two-step process. In the first step, MM selects goals for the next commanding horizon (typically covering several days) and sends them to PS. PS uses its model of the spacecraft to determine which detailed tasks should be selected and scheduled to achieve the goals. For example, in order to perform an OD PS determines from Figure l:Remote Agent architecture the model that pictures of beacon asteroids need to be taken. In order to select these asteroids, the model instructs PS to interrogate the AutoNAV software as a planning expert. In general, PS will rely on several specialized services Remote Agent Architecture--The RA architecture and its provided by software modules external to RA. In DSI both relation to flight software are shown in Figure 1.Viewed as a black-box, RA issues commands to real-time execution AutoNAV and ACS provided information to PS that was incorporated into plans. Going back to our example, flight software (FSW) to modify spacecraft state, and receives data from the spacecraft through a set of monitors observing an asteroid translates, according to the PS model, that filter and discretize sensor values. The RA itself is into taking a series of images of it with the Miniature Integrated Camera And Spectrometer (MICAS). Therefore comprised of three main components: a Planner/Scheduler PS schedules a "MICAS take OPNAV images" task. (PS), a Smart Executive (EXEC), and Livingstone, a Mode Moreover, the model instructs PS that while images of an Identification and Reconfiguration module also known as asteroid are taken, the attitude of the spacecraft must be MIR. An additional component, strictly related with PS, is compatible with the MICAS camera pointing at it. If this is the Mission Manager (MM). In addition, the RA team not the case, the PS model instructs PS to schedule an provided a clean interface to the rest of FSW via the RAX appropriate turn changing the attitude from the previous one Manager (RAXM), which mediated all communication to the desired one. between RA and FSW and was included from the outset in the FSW design. RAXM provided a messaging conduit The brief example above points out another fundamental between RA and the rest of FSW including interfaces to the characteristic of all RA components: their fundamental Planning Experts, the Monitors and to the Real Time reliance on explicit, declarative models of the spacecraft. Sequencer. Using such a mechanism allowed RA to be Although their level of detail varies between the different cleanly bundled on top of FSW much later in flight and yet components, RA models tend to be fairly abstract and tend to focus on system level interactions rather than on the 4 detailoperatioonf individuaslubsystemorscomponents. uses its model to hypothesize the most likely cause of the ThishastwoadvantageFsir.stly,it provideasmethodto unexpected observations in terms of failures of the capturesystem level knowledge in a form that is directly spacecraft's components. The infi_rmation about the new usable to command a spacecraft, without having to go state of the spacecraft hardware is sent to EXEC, which through the costly and error prone translation of system now asks MIR for an action to correct the problem. MIR requirements into flight software. In the traditional now activates MR, which, using the same model, approach, system requirements are at best translated into determines the least-cost system state that satisfies flight rules that can be used to check the validity of EXEC's request and one that is reachable from the fault command sequences but not to generate them in the first mode. MIR then gives EXEC the first action in a possible place. Secondly, more abstract models are less susceptible sequence that will take the system to that state. Such a to changes when a detailed understanding of the behavior of recovery might involve resetting a device, attempting a each subsystem is gained during spacecraft development. command again, or a complex reconfiguration of the Although they need to be adjusted to the new finding, the spacecraft to enable a functionally redundant system. abstract models usually remain structurally unchanged, and EXEC executes the recovery action, under the watchful so remain the synthesis procedures that RA component use eye of MIR, and receives further actions from MIR if to generate command loads. needed by the recovery process. When the recovery is complete, EXEC continues executing the PS task in a Once PS has generated a plan for the next commanding nominal fashion. Note that during this entire process the horizon, EXEC receives it and incorporates it into the original PS task is still active and in a "nominal" state. queues of tasks that it is currently executing. Tasks This depends on the time allocated to the task including generated by PS tend to be fairly abstract. EXEC's enough slack to tolerate variations during execution that responsibility is to synchronize the parallel execution of the can be handled by low-level fault protection. plan tasks according to the specifications contained in the plan, and to further decompose each task, one at a time, into • High-level fault protection loop: this involves EXEC and more detailed steps. This task decomposition eventually PS. Assume that all recovery actions suggested by MR results into individual commands being sent, one at a time, fail and no more recovery actions are available. MIR to FSW. For example, the abstract task "MICAS take therefore infers that MICAS is unusable and OPNAV images" is decomposed into commanding MICAS communicates this to EXEC. This means that there is no to take a number of snapshots while checking that MICAS way to execute a command necessary for the success of is kept "ON" during the entire process. the "MICAS take OPNAV images" task. Moreover, the assumed conditions for other tasks that may be present in Besides its goal-directed commanding and model-centered the plan in the future may now be invalidated. Therefore approaches, RA puts particular emphasis on robustness of EXEC terminates task execution with a failure, discards execution and flexibility of response to faults. The mode the rest of the plan and immediately commands the identification (MI) component of MIR observes EXEC spacecraft to enter an appropriate "RA standby" mode. t It issuing commands, receives sensor observations from then activates PS by communicating to it the current state monitors, and uses model-based inference to deduce the of the spacecraft and asks for a new plan. After receiving state of the spacecraft and provide feedback to EXEC. The the initial state from EXEC and the goals from MM, PS other component of MIR, mode reconfiguration (MR), generates a new plan that achieve the goals as best as serves as a recovery expert, taking as input a set of EXEC possible within the new, degraded configuration of the constraints to be established or maintained, and spacecraft. When the plan is ready, PS sends it to EXEC. recommends a recovery action to EXEC that will achieve EXEC now exits the "RA standby" state and resumes those constraints. MIR provides both the MI and MR normal operations by starting the execution of the new functions using a single core algorithm and a single plan. declarative model. With the above capabilities, RA allows implementation of Fault protection in RA happens at two different levels. fail-operational behaviors under a much broader range than • Low-level fault protection loop: This involves EXEC and is possible in traditional spacecraft commanding. MIR in the context of executing a single PS-generated Traditionally only critical sequences (e.g., Saturn Orbit task. Suppose that EXEC is commanding MICAS power Insertion for Cassini) are designed to tolerate a large number on in order to ensure that MICAS is on during the of faults without requiring "sating" of the spacecraft. This "MICAS take OPNAV images" PS task. It does so by depends on the cost of analysis and implementation of these sending an appropriate command to the power driver. MI sequences. Therefore, in less critical mission phases, a fault observes the command and, on the basis of its previous event usually requires the intervention of the ground state estimate and its models, predicts the likely next state operations team to correct it. With RA the cost of in which the system will be. This prediction provides a qualitative description of the sensor readings MIR should i Note that this is astandby situation only from the perspective of observe from the spacecraft (e.g. the switch sensor and RA. From the point of view of FSW, "RA standby" mode is not a current sensor should be consistent with MICAS being fault mode and does not require the intervention of FSW fault on). If the expected observations are not received, MI protection. implementing these scenarios is significantly reduced, Level Ground System On-Board PS On-Board EXEC making possible an increase of mission productivity and a I Prepare real-time None None (executed reduction of cost of operations. commands w/o EXEC involvement) Detailed Validation Objectives Prepare sequence None Execute .,u_quence Validation of a technology with the complexity and the Prepare plan. upload to None Execute plan: EXEC as script "Scripted mode" pervasive systemic impact of RA required attention to several different aspects and dimensions. Prepare plan. upload to Confirm and pass Execute plan; planner as goals thin the planner "'Planner Mode" The first and most obvious objective was to validate the fact that RA could autonomously command a system as complex Prepare plan including Complete the Execute plan some unexpanded goals plan as a spacecraft for an extended period of time. This translated into the following list of objectives for each RA Definegoals Prepare plan Execute plan component. PS/MM Table 1: Autonomy levels of RA • generate plans on-board the spacecraft Even within the scope of the autonomy demonstration, it • reject low-priority unachievable goals was important to show that adopting RA was not an "all or nothing" proposition and that RA could be commanded with • replan following a simulated failure different levels of autonomous operations. Table 1 shows • enable modification of mission goals from ground. the possible RA autonomy levels, all the way from having EXEC issuing low-level commands from a low-level script EXEC analogous to a traditional command (autonomy level 2), to preparing a plan on the ground and uplinking it to the • provide a low-level commanding interface spacecraft for execution (autonomy level 3) and finally to providing closed-loop planning and execution on the • initiate on-board planning spacecraft (autonomy level 6). The DS! autonomy • execute plans generated both on-board and on the ground experiment was designed from the outset to start with level 3 as a confidence building measure and then to migrate to • recognize and respond to plan failure level 6. • maintain required properties in the face of failures. The final set of validation objectives involved the MIR development process for autonomy software. This covered a number of separate items: • confirm executive command execution • integration of RA with the DSI FSW, a large and • demonstrate model-based failure detection, isolation, and complex system in itself written in a language (C) recovery; different from RA (Lisp); • demonstrate ability to update MIR state via ground • adaptation of RA models and scenarios to reflect commands. operational constraints imposed by the flight team even late in the development process; Other validation objectives addressed the impact of the introduction of RA into a "traditional" spacecraft software • achievement of high-level of confidence by the DSI architecture. From the outset RA was designed to work in spacecraft team by going through a rigorous test regimen conjunction with existing FSW modules and not to replace dictated by the team on high fidelity testbeds. them. As a result the fidelity of control provided by RA We will discuss the level of achievement of these validation depends on the scope and detail of the models of the objectives in the section on the Remote Agent Experiment. spacecraft it has. The challenge was to demonstrate that such cooperative arrangement with FSW could indeed be carried out. This consisted in modeling within RA only a Performance Envelope specific set of spacecraft subsystems and allowing conventional techniques of FSW control to deal with the Note that these performance and resource figures refer to remaining control modes of the craft. While there are no RA as flown on Deep Space ! in 1999 in Lisp. Each of the software or architectural limitations which would disallow RA engines has been or is being re-architected and ported to RA to command all subsystems for an extended period of C or C++. These new systems may exhibit significantly time, the fielding of RA on DS 1was also meant to provide a different performance characteristics. credible demonstration of the fact that autonomy concepts could be applied within a well defined scope. 6 • Memory: 32 Mbytes memory peak, 20 avg. under control. This is asignificant difference with respect to • CPU: classical approaches both in Artificial Intelligence and - RAX ran at priority level just below that of DSI Operations Research where action planning and resource sequencer (very low). scheduling are typically addressed in two sequential - 20% of CPU when planner is idle (only EXEC and problem-solving stages, often by distinct software systems (see [181). MIR are running). - 45% of CPU while planner is running (PS, EXEC, Another important distinction between PS and other and MIR all running). classical approaches to planning is that besides activities, • Time to generate plans depends on plan complexity. the planner also "'schedules" the occurrence of states and RAX plans took 50 to 90 minutes to generate. conditions. Such states and conditions may need to be • Telemetry: 10bits per second, average. monitored to ensure that, for example, the spacecraft is This includes notification as each activity in the plan is vibrationally quiet when high stability pointing is required. executed, current diagnosis for each device monitored These states can also consume resources and have finite by MIR, and summary of the planner's plan generation durations and, therefore, have very similar characteristics to progress. Similar telemetry would be needed for future other activities in the plan. PS explicitly acknowledges this science missions. similarity by using a unifying conceptual primitive, the • File space: 140 KB for support files, plus token, to represent both actions and states that occur over approximately 100 KB per stored plan, depending on time intervals of finite extension. More details with plan complexity (proportional to number of activities in examples of the semantics of a token are given further along the plan). Compressed binary executable was 4MB. At in this section. most one plan needs to be stored, though all plans were PS consists of a heuristic search engine that deals with stored during RAX for validation purposes. RAX also incomplete or partial plans. Since the plans explicitly generated a IMB log. represent time in a metric fashion, the planner makes use of a temporal database. As with most causal planners, PS Technology Details begins with an incomplete plan and attempts to expand it into a complete plan by posting additional constraints in the RA consists of general-purpose reasoning engines, and database. mission-specific domain models. The engines make decisions and command the spacecraft based on the These constraints originate from the goals and from knowledge in the models. This section describes the details constraint templates stored in a domain model of the of the reasoning engines and how they interact. The DS1 spacecraft. The temporal database and the facilities for domain models developed for the flight experiment will be defining and accessing model information during search are discussed in the flight experiment section. provided by the Heuristic Scheduling Testbed System (HSTS). The planning engine searches the space of possible Planner/Scheduler--PS provides the core of the high-level plans for one that satisfies the constraints and achieves the commanding capability of RAX. Given an initial, goals. The action definitions determine the space of plans. incomplete plan containing the initial spacecraft state and The constraints determine which of these plans are legal, goals, PS generates a set of synchronized high-level and heavily prune the search space. The heuristics guide the activities that, once executed, will achieve the goals. In the search in order to increase the number of plans that can be spacecraft domain planning and scheduling aspects of the found within the time allocated for planning. Figure 2 problem need to be tightly integrated. The planner needs to describes the PS architecture. Additional details on the recursively select and schedule appropriate activities to planner algorithm and its correctness can be found in [lI]. achieve mission goals and any other subgoals generated by The model describes the set of actions, how goals these activities. It also needs to synchronize activities and allocate global resources over time (e.g., power and data decompose into actions, the constraints among actions, and resource utilization by the actions. For instance, the model storage capacity). Subgoals may also be generated due to limited availability of resources over time. For example, it will encode constraints such as "do not take MICAS images may be preferable to keep scientific instruments on as long while thrusting" or "ensure that the spacecraft does not slew when within a DSN communication window". These as possible (to maximize the amount of science gathered). However limited power availability may force a temporary constraints are encoded in a stylized and declarative form instrument shutdown when other more mission-critical called the Domain Description Language (DDL). subsystems need to be functioning. In this case the allocation of power to critical subsystems (the main result of a scheduling step) generates the subgoal "instrument must be off" (which requires the application of a planning step). PS is able to tune the order in which decisions are made to the characteristics of the domain by considering the consequences of action planning and resource scheduling simultaneously. This helps keep the search complexity \ would be impacted also). In addition, the richness of the representation and the declarative form of DDL ensures that mission/systems engineers can have a substantially easier job of understanding and verifying the implementation of the flight rules in RA than would have been possible in conventional FSW. These are some of the advantages that RA brings to a mission. F_n Figure 2: Planner/Scheduler Architecture. (Define_Compatibility ;; compats on SEP_Thrusting (SEP_Thrusting ?heading ?level ?duration) :compatibility_spec (AND (equal (DELTA MULTIPLE (Power) (+ 2416 Used))) (contained_by (Constant_Pointing ?heading)) (met_by (SEP_Standby)) (meets (SEP_Standby))) Figure 4: A Plan fragment formed by a DDL model ) (Define_Compatibility Each subsystem in the model is represented in the PS ;; Transitional Pointing database as a set of dynamic state variables whose value is (Transitional_Pointing ?from ?to ?legal) tracked over time. Timelines are treated as instantiations of :parameter_functions (?_duration <- APE_Slew_Duration (?from state variables and are used interchangeably with state ?to ?_start_time_)) variables in this report. Each dynamic state variable can (?_legal <- APE Slew_Legality (?from ?to ?_start_time_)) assume one or more values. A token is associated with a :compatibility_spec value of a state variable occurring over a finite time interval. (AND Each value has one or more associated compatibilities, i.e., (met_by (ConstantPointing ?from)) (meets (Constant_Pointing ?to)))) patterns of constraints between tokens. A legal plan will contain a token of a given value only if all temporal (Define_Compatibility constraints in its compatibilities are satisfied by other tokens ;; Constant Pointing (Constant_Pointing ?target) in the plan. Figure 3 shows an example of a set of :compatibility_spec compatibilities with temporal constraints. (AND (met_by (Transitional Pointing * ?target LEGAL)) The first compatibility indicates that the master token (meets (Constant_Pointing ?target * (which is at the head of the compatibility), is LEGAL))) SEP_Thrusting (when the Solar Electric Propulsion engine is producing thrust), 2 must be immediately preceded and followed by a SEP_Standby token (when the SEP engine is in a standby mode but has not been completely shut off), and it must be temporally contained by a constant pointing Figure 3: Temporal Constraints in DDL token, and the complete thrusting activity requires 2416 Watts of power. The Constant_Pointing token implies that the spacecraft is in a steady state aiming its camera towards a fixed target in space. Transitional_Pointing tokens In conventional modes of writing flight software, the describe an activity when the spacecraft slews. Figure 4 constraints in the domain are mixed with the control gives a visual rendering of these compatibilities. information. In the model-based approach of RA, the domain model is a distinct entity which encodes the mission The timeline approach to modeling is also driven by strong specific flight rules. This means that (in the case of PS) not software engineering principles. In a complex domain with only are the core engines (the HSTS Temporal Database different individuals and organizations with varying (TDB) and the Search Engine) reusable across missions, but expertise, timelines provide disparate views of the same that the model can be manipulated independently of any domain model across organizational boundaries. For other piece of the flight code (note that since the heuristics search control information is model dependant, this module 2Solar Electric Propulsion (SEP) issynonymous with IPS.