WIXLIB

Another advantage of the Remote Agent derives from thenominal and failure modeling used by the fault diagnosisengine. For hard-coded fault protection designs, thedomain knowledge is implicit rather than explicit. Thismeans that we rely on the fault protection algorithmdevelopers to understand the system, and abstract from thatunderstanding a design for which symptoms to look for andwhat responses to take when they show up. In contrast, withmodel-based fault diagnosis, the fault protection softwareengineers explicitly model how the system behaves innominal and failure cases. Fault diagnosis then becomes asearch for likely diagnoses given observed symptoms.Since the spacecraft designers understand the details of thesystem behavior, there is an advantage to having themencode their knowledge explicitly at design time.3. AUTONOMY TECHNOLOGY INSERTIONREQUIREMENTSIt is not enough to build a better mousetrap; it won’t catchany mice unless it gets used. There are similar issues forthe insertion of higher levels of autonomy into spacecraftdesigns. The design must be developed with the needs oftwo sets of customers in mind: the spacecraft test engineersand the mission controllers.Spacecraft TestConversations with spacecraft test engineers have raised anumber of concerns that must be addressed in anyautonomous system design process.1. Determinism and non-determinism: Is the system nondeterministic? How do we test the system if we don’tcontrol its initial conditions in flight?For the current Remote Agent design, the system isdeterministic to the extent that the same set of inputs willyield the same outputs each time. The context for thisquestion, however, is that we cannot predict the exact set ofcommands that the Remote Agent will use to achieve a setof goals far in the future since we cannot predict exactlywhat the spacecraft state will be at that time. This situationis common in another context, that of attitude controlsystems. We don’t know exactly when a particular thrusterwill fire, but we do know that the system will fire thrustersas needed to achieve the higher level goal of holding thecommanded attitude.So how do we test such a system? For an attitude controlsystem, we develop multiple scenarios and verify that thepointing error meets requirements in all situations. We alsocheck that the propellant usage is acceptable while therequirements are being met. Continuing the analogy with anattitude control system, we develop multiple scenarios andtest whether the high level goals are met, and analyzewhether the resources required to do so were acceptable.2. Earlier system behavior definition: The flight system ismore complex, so more testing is needed earlier and thedesired behavior needs to be defined long before launch.Some additional techniques are required.described in the testing section of this paper.These areThe concern about early definition may be valid dependingon how much of the spacecraft behavior we choose to buildinto the flight software before launch. With the traditionalsequence development approach, many sequences aredeveloped after launch, so there is no opportunity toobserve full end-to-end behavior in a test environment.With an on-board planner, we now have the opportunity todesign and test the behavior before hand. It should bepointed out that this is an opportunity and not arequirement. For example, the Project may choose to delayfinal design of flyby scenarios until after launch. In thiscase, we should expect to update the on-board planner andmission goals at the time that the scenario is finalized andthis may be after launch.3. Test Plan coverage: How do we develop a test plan thatassures adequate coverage? How should test cases bedevised? What needs to be tested in system test? The coreengines underlying the Remote Agent are unfamiliar tospacecraft test teams and could require large effort to test.First, a distinction should be made between the RemoteAgent infrastructure or engines and the mission-uniquemodels.The Remote Agent infrastructure will beextensively analyzed and tested in pre-integration unit tests.At the system test level, the focus should be on whether thebehavior of the Remote Agent meets the goals andconstraints set for it.As with any complex system, the test plan needs to includenominal cases, failure cases, and cases that test theboundaries of the system so that the operators learn where itwill break. The planner can be challenged by overloadingthe number of tasks to be done in a short time. Theexecutive may be challenged with a large number of tasksrequiring immediate response, and fault protection may bechallenged by examining its response to multiple, closelyspaced failures. Planner unit tests will include examplesusing each constraint. Executive unit tests should exploreeach approach that might be used to achieve a task and faultprotection tests still depend on devious testers to inventchallenging scenarios.A large variety of tests seeking extreme and boundarycondition behavior is indicated when testing any complexsoftware system.A major advantage of the Remote Agent approach is that itdepends on declarative hardware knowledge; in otherapproaches the hardware knowledge is captured Onlyimplicitly. Explicit models come in handy at review timebecause the software engineer can sit with the hardwareexpert and review the declarative model of the hardware.This helps reduce errors in understanding between thehardware and software engineers.

Mission OperationsMission operators or controllers have clearly expressed anumber of requirements or desires with respect to fieldingautonomous systems. These include:1. Low level commanding: Operators should be able to haveaccess to low-level control of spacecraft hardwareunimpeded by the autonomous system.As this requirement became clear, the Remote Agent designwas modified to allow low-level hardware capabilities and safeguards. Unless the Remote Agent isinstructed in the context and goals of these low levelcommands, they need to be used carefully and when thespacecraft is in a low activity quiescent mode.2. Ground override authority: An ability to command thespacecraft to revert to a low-level of autonomy mode if thecontrollers decide that they want to disable the autonomousfeature.This requirement is met on DS1.3. Migration of autonomy capabilities: A sequence thatallows demonstration of autonomous capabilities as groundsystem capabilities prior to fielding them on the spacecraftas on-board capabilities.The Remote Agent experiment is being designed to meetthis requirement by first engaging the executive as justanother basic sequence engine, then allowing Remote Agentto execute a pre-computed plan sent from the ground, andfinally enabling the on board planner, bringing the full DS1Remote Agent level of autonomy to bear.4. Behavior Prediction: The ability to predict (at somelevel) what the behavior of the spacecraft will be when thespacecraft begins to execute the on-board-generated plan.There will be a copy of the on-board planner built into theground system. This copy will be used to generateexperience and rules of thumb as to what sets of goals areeasily achievable and what sets are difficult to achieve forthe on-board system based on these rules of thumb. Theoperators will define the goals for each mission phase andsince the Remote Agent is closing the loop around thesegoals, the best prediction of spacecraft behavior is that thegoals will be achieved on schedule.The Remote Agent has been designed to support multi-levelcommanding and monitoring in order to enable groundcontrollers to adjust the level of autonomy they desireacross different activities or mission phases [1].4. REMOTE AGENT DESIGN APPROACH ANDARCHITECTURE. The New Millennium Autonomy Architecture rapidPrototype (NewMaap) effort [2] identified the keycontributing technologies: on-board planning andreplanning, multi-threaded smart executive, and modelbased failure diagnosis and repair. In NewMaap, welearned how to take advantages of the strengths andweaknesses of these three technologies and merge them intoa powerful system. After successful completion of theprototype, the RA was selected as one of the NMPtechnologies for DS1. It will be uplinked to the spacecraftas a software modification and demonstrated as anexperiment.Fig. 3 shows the communications architecture for theRemote Agent’s interaction with the rest of the spacecraftflight software. Note that all interaction with the hardwareis the responsibility of the real-time software. The RA islayered on top of that software, but also gathers informationfrom all levels to support fault diagnosis.Remote onitorsMode IDandReconfigFlightH/WFigure 3. Remote Agent Communication ArchitectureSeveral spacecraft commanding styles are possible. Goaloriented commanding is the intended operating mode formost of an RA mission; provision has been made forupdating the goals in flight. In a typical planning cycle, theexecutive is executing a plan and gets to an activity that canbe interpreted as "time to plan the next segment." Theexecutive calls the planner with the current and projectedspacecraft state including the health of all devices. Theplanner/scheduler generates a new plan using priorities,heuristics, and domain models including system constraints.The planner sends this plan to an executive that creates anagenda of plan items and executes the agenda. Planexecution robustness is added by making use of the Modelbased Mode Identification and Reconfiguration (MIR)system. The MIR system includes monitors, modeidentification for nominal and failure conditions,communication of state to the executive and proposals ofreconfiguration actions to take in the event of failures.Each of the components of the Remote Agent will bedescribed in more detail in Section 6, but first the RemoteAgent experiment for the Deep Space One mission will bedescribed in more detail.5. THE DEEP SPACE ONE REMOTE AGENTEXPERIMENTThe Remote Agent eXperiment (RAX) for Deep Space Oneis a demonstration of RA capabilities. Since an alternate

method of control is used for most of the mission, RAX isfocused on demonstrating specific autonomy capabilitiesrather than controlling all aspects of spacecraft behavior.The Remote Agent controls the following spacecrafthardware and software: the camera for use in autonomousnavigation, the Solar Electric Propulsion (SEP) subsystemfor trajectory adjustment, the attitude control system forturns and attitude hold, the navigation system fordetermining how the actual trajectory is deviating from thereference trajectory and what SEP thrusting profile isneeded to stay on the reference trajectory, the PowerAmplification and Switching Module (PASM), for use indemonstrating fault protection capabilities.switch is stuck on. When the new plan is received by theexecutive, execution resumes including navigation and SEPthrusting. Near the end of the three day plan, the planner iscalled to generate the plan for the next three days. Thisplan includes navigation and SEP thrusting as before. Italso includes two simulated faults. First, a failure of ahardware device to communicate is injected (F3); theproper recovery is to reset the device without interruptingthe plan. Next, a thruster stuck closed failure (F4) issimulated by injecting an attitude control error monitorabove threshold. The correct response is to switch controlmodes so that the failure is mitigated.RA Capabilities Demonstrated with DS1 RAXFour failure modes are covered by RAX. These are:F1. Power bus status switch failureF2. Camera power stuck onF3. Hardware device not communicating over bus toflight computerF4. Thruster stuck closedMission ScenarioThe Remote Agent experiment is executed in two phases, a12 hour Phase One followed a couple of weeks later by a 6day Phase Two.In Phase One, we start slowly by first demonstrating theexecutive operating in the manner of a low level sequencerby accepting commands to turn devices on and off. Next, a“scripted” mode is demonstrated with execution of plansuplinked from the ground. The main demonstration herewill be commanding the spacecraft to go to and stay in aknown, safe, standby mode and then take a series of opticalnavigation (OpNav) images. In addition, Failure mode F1will be demonstrated by injecting power bus switch statusreadings indicating that a power bus is unexpectedly off.The fault diagnostic system will examine this informationalong with other information that indicates that devices onthe bus are still communicating normally with the flightcomputer and conclude that the failure is in the switchstatus measurement and not in the bus itself. No action willresult. No planning or SEP thrusting are attempted in PhaseOne.In Phase Two, we also start by demonstrating low levelcommanding, and then initiate on-board planning. Basedon the spacecraft initial state and the uplinked goals, theplanner will generate a three day plan including imaging foroptical navigation, thrusting to stay on the referencetrajectory, and simulated injection of faults to test outfailures F2, F3, and F4. First the camera power stuck onfailure (F2) is injected. When the executive is unable toturn off the camera when the plan so dictates, the executiverealizes that the current plan should be aborted andreplanning is indicated. This might be necessary, forexample, because the initial plan’s assumptions on powerconsumption are incorrect with the camera on when itshould be off. The plan is declared failed, the spacecraft issent to a standby mode while the planner is requested toreplan based on the new information that the camera powerThe above scenario has been designed to demonstrate thatthe DS1 Remote Agent meets the following autonomytechnology goals: Allow low-level command access to hardware Achieve goal oriented commanding Generate plans based on goals and current spacecraftstate expectations Determine the health state of hardware modules Demonstrate model-based failure detection, isolation,and recovery Coordinate hardware states and software modes Replan after failure given new context6. RA COMPONENTSThe major components of the Remote Agent are discussedbelow.Planner/SchedulerThe highest level commanding interface to the RemoteAgent is provided the Planner/Scheduler (PS). PS maintainsa database of goals for the mission, the mission profile, thatspans a very long time horizon, potentially the duration ofthe entire mission. Over the duration of a mission PS isiteratively invoked by the executive to return asynchronized network of high-level activities, the plan, foreach short-term scheduling horizon into which the missionprofile is partitioned. Typically each short-term horizoncovers several days. When PS receives a request fromEXEC, it identifies the next scheduling horizon, retrievesfrom the mission profile the goals relevant to that horizon,merges in the expected initial spacecraft state provided byEXEC into a incomplete, initial plan and generates a fullypopulated plan. PS sends that plan to EXEC for execution.For RAX, Phase Two, the mission profile will cover 6 daysand contain two scheduling horizons of three days each.RAX allows the specification of two kind of goals. Onespecifies the frequency and duration of the “opticalnavigation windows”, the time during which the spacecraftis requested to take a set of asteroid pictures to be used fororbit determination by the on-board Navigator. The secondtype of goal specifies a “mini-sequence”, i.e., a set of lowerlevel commands that EXEC will issue to the real-timesoftware, and requirements to activate the mini-sequence

with certain synchronization constraints with respect toother planned activities. A new plan will be requested ofMM/PS in two situations: nominal operations: in this case EXEC reaches theactivity Planner Plan Next Horizon towardthe end of the current scheduling horizon. EXEC willissue a request for a new plan. This request will definethe new initial state as the expected final state from theplan currently in execution. This will allow seamlesspatching of the old and new schedule without anyinterruption of execution. fault response: if the fault protection system detects ananomaly that will impact the executability of futuretasks in the plan, the EXEC will request a new plan toresume normal operations after having put thespacecraft in a safe standby mode. In this case theinitial state describes the standby tasks or holdingstates for each subsystem modeled in the plan andhealth information describing possibly degraded modesfor failed subsystems.Notice that from the point of view of PS both the nominaland fault response case are handled exactly in the sameway.Ground controllers can add, modify, or delete goals fromthe mission profile by explicitly issuing a command to themission profile. For example, in a mission in which thespacecraft communicated to Earth through the Deep SpaceNetwork, the final communication schedule allocated to themission may become available only a few weeks ahead oftime and it is possible that a schedule may change with ashort notice (e.g., within a week). Ground controllers willneed to communicate both of these situation to thespacecraft by issuing appropriate edit commands to modifythe mission profile.PS provides the core of the high-level commandingcapability of RAX. Given an initial, incomplete plancontaining the initial spacecraft state and goals, PSgenerates a set of synchronized high-level activities that,once executed, will achieve the goals. PS presents severalfeatures that distinguish it from other Artificial Intelligenceand Operations Research approaches to the problem. Forexample, in the spacecraft domain planning and schedulingaspects of the problem need to be tightly integrated. Theplanner needs to recursively select and schedule appropriateactivities to achieve mission goals and any other subgoalsgenerated by these activities. It also needs to synchronizeactivities and allocate global resources over time (e.g.,power and data storage capacity). Subgoals may also begenerated due to limited availability of resources over time.For example, it may be preferable to keep scientificinstruments on as long as possible (to maximize the amountof science gathered). However limited power availabilitymay force a temporary instrument shut-down when othermore mission-critical subsystems need to be functioning. Inthis case the allocation of power to critical subsystems (themain result of a scheduling step) generates the subgoal“instrument must be off” (which requires the application ofa planning step). The PS is able to tune the order in whichdecisions are made to the characteristics of the domain byconsidering the consequences of action planning andresource scheduling simultaneously. This helps keep thesearch complexity under control.This is a significant difference with respect to classicalapproaches both in Artificial Intelligence and OperationsResearch where action planning and resource schedulingare typically addressed in two sequential problem solvingstages, often by distinct software systems. Anotherimportant distinction between the Remote Agent PS andother classical approaches to planning is that besidesactivities, the planner also “schedules” the occurrence ofstates and conditions. Such states and conditions may needto be monitored to ensure that, for example, the spacecraftis vibrationally quiet when high stability pointing isrequired. These states can also consume resources and havefinite durations and, therefore, have very similarcharacteristics to other activities in the plan. PS explicitlyacknowledges this similarity by using a unifying conceptualprimitive, the token, to represent both actions and statesthat occur over time intervals of finite extension.PS consists of a heuristic search engine, the IncrementalRefinement Scheduler (IRS) that operates in the space ofincomplete or partial plan [6]. Since the plans explicitlyrepresent time in a numeric (or metric) fashion, the plannermakes use of a temporal database. As with most causalplanners, PS begins with an incomplete plan and attempts toexpand it into a complete plan by posting additionalconstraints in the database. These constraints originatefrom the goals and from constraint templates stored in amodel of the spacecraft. The temporal database and thefacilities for defining and accessing model informationduring search are provided by the HSTS system. For moredetails on PS and the HSTS system see [3] and [4]. Figure 4describes the PS architecture.NAVExpertEngineDomain KnowledgeHeuristicsIRS SearchengineModel(DDL)ACSExpertMission ProfileHSTSTDBPlanInitial stateFigure 4. Planner/Scheduler ArchitectureThe coverage of the RAX model is described in Table 1.Appendix B gives a detailed description of the timelines andtokens needed by PS to handle the propulsion and thrustsubsystems of the spacecraft.

Table 1 Summary of Planner Models for RA ExperimentSubsystemStateVariablesMICASExecutable: 2ValueTypesCompatibilities714Models the health, mode and activity of the MICAS imaging camera.RAX demonstrates fault injection and recovery for this device as partof the 6 day scenario.56To schedule Orbit determination (OD) based on picture takingactivity.912Based on thrust schedule generated by the NAV m

the Remote Agent. Section 7 describes how the Remote Agent software is integrated into the separately-developed Deep Space One flight software. Section 8 describes how the Remote Agent experiment is tested prior to flight. Section 9 summarizes the paper and describes plans for future Remote Agent development. 2. NEED FOR AUTONOMY ON SPACECRAFT