Embed Size (px)
Citation preview
On-board Timeline Validation and Repair: A Feasibility StudyM. Fox and D. Long
Department of Computer and Information SciencesUniversity of Strathclyde, Glasgow, UK
L. Baldwin and G. Wilson and M. WoodsSciSys Ltd, Clothier Road, Bristol, UK
D. JameuxEuropean Space Agency (ESA)
European Space Research and Technology CentreNoordwijk, The Netherlands
R. AylettHerriot-Watt University, Edinburgh, UK
Abstract
We report on the progress and outcome of a recent ESA-funded project (MMOPS) designed to explore the feasibilityof on-board reasoning about payload timelines. The projectsought to examine the role of on-board timeline reasoning andthe operational context into which it would fit. We frameda specification for an on-board service that fits with exist-ing practices and represents a plausible advance within sen-sible constraints on the progress of operations planning. Wehave implemented a prototype to demonstrate the feasibilityof such a system and have used it to show how science gath-ering operations might be improved by its deployment.
IntroductionCommunication to distant landers is restricted, both byavailability of a communication window and by the time ittakes for a signal to pass from transmitter to receiver. Thismakes it essential to construct plans for the activities of adistant spacecraft, often spanning several hours or days ofotherwise unsupervised activity. As has frequently been ob-served, plans rarely survive contact with reality unscathed.Plans must be constructed using predictions about the out-come of activities of the spacecraft and also predictions ofthe behaviours and reactions of the surrounding environ-ment. These predictions can diverge from the actual be-haviours when a plan is executed. In typical currently de-ployed systems, plan failure will (depending on the severityof the failure) lead to the spacecraft entering a safe mode andawaiting further instructions, having aborted execution ofthe remainder of the plan. This response shares an importantcharacteristic with the models on which the plans are basedfrom the outset: they are conservative. That is, both the pre-dictions about the activities of a spacecraft and the responseto failures in those predictions act to limit and constrain thescience gathering operations of the spacecraft. To illustratethis conservatism, consider that it is now estimated that So-journer spent at least 50% of its time idle, awaiting furtherinstructions, either because it had completed its planned ac-tivities and had nothing left to execute, or because it hadentered safe mode following a failure in some activity. Eventhe immensely successful Mars Exploratory Rovers (MER)mission has been extremely cautious: the original plannedmission lifetime for the rovers was only 90 sols, yet theyhave now been active for more than 850 sols. Even so, they
have travelled no more than 7 kilometers in the nearly threeyears of mission activity. Despite great improvements in thesupport technology for the planning of MER operations (Ai-Changeet al. 2003), plans remain conservative and plan ex-ecution failures have caused many days of lost science gath-ering over the lifetime of the mission.
In this paper we describe the Mars Mission On-boardPlanning and Scheduling (MMOPS) project, in which weexplored the construction of a prototype system that wouldhelp to address the loss of science caused by conservativemission planning and plan failure. Our prototype has beenconstructed to work with the Beagle 2 (Blakeet al. 2004)hardware (see Figure 1), since the on-board software (OBS)and simulator were already available to the team. As part ofthe project, we have also considered the use of our approachfor a mobile lander, such as the planned ExoMars rover.
Our approach has been to design a system that could bedeployed on-board a remote spacecraft, granting the craftsome measure of autonomy. Other space missions have alsoexplored this possibility, with some success (Chienet al.2004; Jonssonet al. 2000). In our work we have not at-tempted to construct a system in which planning is devolvedto the on-board system. Instead, it remains under the controland supervision of the ground operations personnel. Theon-board system is designed to manipulate plans (timelines)constructed on the ground, handling three problems that weconsider to be central to execution issues on spacecraft:
• Plan failure isolation. When a plan contains an activitythat fails, or that it is predicted will fail, the first concernis to isolate the consequences of that failure and to protectexecution of the remainder of the plan.
• Over-subscription. When a plan contains more activitiesthan it is predicted that there are resources available tosupport, activities must be removed from the timeline inorder to bring it back within safe bounds. This situationincludes both consumable resources such as power andfixed resources such as instruments.
• Under-subscription. Either as a consequence of failureisolation, or conservative estimates for plan execution, ifit is predicted that more resource will be available thanwas expected before plan execution began, additional ac-tivities may be performed. We call these activitiesoppor-tunitiesand they are described in more detail below.
Figure 1: Beagle 2
The system we have developed performs Timeline Val-idation, Control and Repair (TVCR). These three servicesprovide the foundation of the management of the problemsidentified above. The design of the system allows these ser-vices to be invoked incrementally, so that additional func-tionality is called on as ground personnel gain confidence inthe behaviour of TVCR.
BackgroundOn December 25th, 2003, a small lander, travelling with theMars Express orbiter, was expected to land on Mars sur-face. Unfortunately, mirroring the fate of many other at-tempts to land on Mars, Beagle 2 was unsuccessful. Vari-ous explanations of its failure have been proposed, includ-ing the possibility that the density of the Martian atmo-sphere is not as high as had been thought and, as a result,the parachute-brake failed to slow the lander sufficiently be-fore impact. Considerable expertise was built up around theBeagle 2 systems, including a partial domain model for hu-man planning operations, and this formed the core of an ini-tial project to exploit planning technology to support mixed-initiative and partially automated planning for the lander op-erations (Woodset al. 2003) and, from that, the project de-scribed in this paper. Beagle 2 was a static lander, equippedwith a jointed arm carrying an array of scientific instrumentsin a “paw” at its end. Included in the paw was a mole capa-ble of drilling into soil around the lander to a distance ofmore than 2 meters, to retrieve soil samples for gas analy-sis on board. Beagle 2 was, essentially, a geological surveysystem, capable of performing an array of geological and en-vironmental measurements in its immediate surroundings.
All lander operations are constrained by power availabil-ity, provided by solar energy with a battery for storage, andby temperatures. Planning lander operations involves man-aging constraints on continuously changing quantities (thegenerated power levels and temperatures), scheduling theuse of resources, planning the movement sequences of thearm and use of the instruments. Human operations plan-ners were to have carried out the planning for Beagle 2in a complex process involving scientists, providing mis-sion goals and the operations to achieve them, and landeroperations personnel, concerned with lander security and,
therefore, the power resources and internal lander monitor-ing systems. When we became involved in the project wediscovered that the existing partial domain description wasin a form that closely resembledPDDL2.1 durative actiondescriptions (Fox & Long 2003). It was possible to translatethe description intoPDDL automatically using a simple au-tomatic translator. The domain encoding began with over 50actions and this has increased to nearly 70 actions followingfurther domain analysis.
Power is the most important continuous factor in the op-erations of the lander. The lander operates close to marginsand the model of the solar generation and the battery charg-ing profiles are vital in determining when operations can beplanned. The management of battery and solar power is suf-ficiently close to the margins of operational envelopes thatplans must interact with the continuous changes involved inthe physical system rather than with abstractions into coarse-grained simple step-function changes. Of course, with suf-ficiently small time-steps a step-function model can approx-imate the continuous change adequately, but it is infeasibleto attempt to model this level of granularity explicitly in theplanning domain description. Therefore, this problem de-mands that the planner (human or otherwise) has access toa sufficiently detailed model of the continuous changes thataffect the power systems.
Ground-based Planning, On-board RepairOur preliminary investigations (Woodset al. 2003) con-vinced us that, while on-board planning technology has animportant role to play, there are important reasons why, inthe short-term, fully automated plan construction is not themost important objective. The first reason is that on-boardresources are extremely constrained, so both CPU and mem-ory availability is likely to prevent realistic planning technol-ogy from being deployed on deep space probes in the nearfuture (notwithstanding the important success in the RemoteAgent Experiment (Jonssonet al. 2000)). The second rea-son is that neither scientists not operations personnel (thosecurrently responsible for planning of spacecraft operations)are willing to relinquish their tight control over operationsuntil significantly more experience and trust in automatedtechnologies has been built up. Therefore, our goal has beento provide an on-board “planning assistant”, providing sup-port to the operations personnel responsible for constructingplans on the ground. The role of the assistant is to adjustand repair plans on-board when circumstances make it im-possible execute the plans constructed on the ground. Anessential constraint on this behaviour is that the plans thatare manipulated on-board are all built on the ground by op-erations personnel.
Domain Models and Plan FragmentsIn order to perform any on-board manipulation of plans itis necessary to provide a foundation for reasoning about thestructure of those plans. Our starting point is the action-centred models of AI planning, describing the actions thatform the building blocks of plans in terms of their precon-ditions and effects. Preconditions and effects are evaluated
with respect to a model of the state of a system and its envi-ronment. The state is represented by a collection of propo-sitions asserting both logical status and also numeric valuesof metric properties. In our work we have used PDDL (Fox& Long 2003) as our modelling language, since it offers usaccess to a range of research tools already constructed forthe construction and analysis of plans and domains.
Although PDDL offers an expressive language for mod-elling the behaviour of individual actions and their interac-tions with other actions, it does not currently offer a way toexpress several other important constraints on the structureof plans. For example, Beagle 2 was equipped with a rockgrinder and various imaging tools: it is standard scientificmethodology to perform experiments so that the least inva-sive investigations are performed first, following them withthose that might change the target of investigation physi-cally or, finally, chemically. Thus, the grinder would notbe deployed until after images of a target had been captured.This constraint is not a logical constraint on the performanceof these actions — clearly, it is perfectly possible to grinda rock before taking any images of it. Instead, this is amethodological constraint on the actions in a plan. Althoughthere are techniques that would allow such constraints tobe modelled in PDDL, the fact that these constraints gov-ern not the way in which actions can be performed but thecircumstances under which it would be appropriate to per-form them is very significant. In particular, methodolog-ical constraints may be relaxed under exceptional circum-stances, while logical constraints cannot be. Recent devel-opments in PDDL support the inclusion of soft constraints(indeed, this project was a source of significant inspirationto that work) (Gerevini & Long 2006). Methodological con-straints are distinguished as one particular kind of soft con-straints only because their source is scientists who wish tosee them imposed to maximise the value of the scientific re-turn. Other soft constraints might reflect the preferences ofoperations personnel who might wish, for example, to seethe craft maximise its stored energy levels or minimise wearon sensitive components.
AI planning research has been primarily focussed on theconstruction of plans for goals that specify the conditionsthat should be achieved in the final state. In the context ofspace probe plans we found that this was not always themost convenient way to express the purpose of plans. Of-ten, a plan is intended to perform a series of experimentsand the simplest way to express their goals is to say whichactions they are designed to perform rather than to expressthe goals in terms of the states that these actions achieve.One reason for this is that the effects of a science gatheringactivity seen from the perspective of the on-board state aretypically to add data to some internal data buffer. The on-board state is not really any different if the data is acquiredfrom a spectrometer or from a camera, but to support theexpression of goals in terms of state conditions would re-quire that a distinction be made between the various sourcesof data, including not only the instrument but also the tar-get. This complicates the model and is counter intuitive foroperations personnel when describing plans.
To address these problems we introduced a separate way
to capture information about the structure of a plan and itspurpose. Our objective was to provide a tool that wouldallow operations personnel to record information about thestructure of a plan — information that was already knownto them but has previously not been formally captured orrecorded. Essentially, we wanted to capture the informationthat might be exchanged informally between (human) plan-ners during the initial construction of a plan. This informa-tion includes:
• Plan structure. In order to identify the organisation ofa plan into coherent blocks of activity we allowed plansto be divided intoplan fragments. A plan fragment is agroup of actions that are together in a plan to coordinateand achieve a single objective. The group forms a co-herent unit of related activities, such as preparing equip-ment, deploying it and gathering data from it before stow-ing it again. The point in identifying these structures isthat these actions are in a plan because of their mutualintegrity. If, for example, an instrument is known to benon-operational then there is no benefit in deploying itand stowing it, even if those actions are logically inde-pendent of the status of the instrument. These compo-nents are very similar to hierarchical task network struc-tures (HTNs), but they are generated on anad hocbasisfor each part of the mission, rather than once for the do-main as a whole.
• Ordering constraints. When it is important that one ac-tivity should precede or succeed another, but this condi-tion is not a logical constraint on the interactions of theseactivities then we record it as a plan constraint. Suchconstraints might hold between individual activities or be-tween entire fragments. We distinguish betweenorderingdependencies, where the two constrained elements shouldeither both appear in a valid execution of a plan, or elseneither appear, andconditional orderings, where the twoconstrained elements must appear in a particular order ifthey are both executed.
• Timing constraints. Activities or fragments can be iden-tified as requiring to be executed during darkness or dur-ing daylight. They can also be marked asfixed, meaningthat the time at which they are to be executed cannot bechanged. This is typical for communication activities thatmust synchronise with communication windows sharedby orbiters or ground-based transmitters.
• Mutual exclusion constraints. These constraints preventtwo activities, or fragments, from coexisting in the sametimeline. This constraint can be useful in triggering theuse of diagnostic activities where they are inappropriatewhen the corresponding instrument is functioning, butthey should be included in the plan exactly when the activ-ities using the instrument have failed (and therefore havenot been executed in the current timeline).
Figure 2 shows the interface to our prototype tool,CON-TOOL, developed for this project. It presents a simple viewof the timeline and allows selection of elements to be splitinto fragments. The entry of constraints is managed in thesmaller window showing the small coloured and number-
Figure 2: The plan fragment and constraint editing tool.
coded blocks representing activities and fragments. An im-portant aspect of the use ofCONTOOL is the identificationof plan fragments. The fragments that form the main time-line are the building blocks that form the primary scientificexperiments for that period. However, additional fragmentscan be created and included in the data sent to the lander,identifying optional additional experiments that might beperformed. These are calledopportunities(an example isshown in the upper right window of the screenshot). Eachopportunityis a self-contained scientific experiment, form-ing a coherent planned structure of activities that could beexecuted by the lander. The identification of opportunitiesallows ground staff to propose useful additional activitiesthat scientists would like to see executed but which havenot been selected for the primary timeline for that period.These opportunities are used to reduce the problem of under-subscription: when the lander completes the primary time-line with a significant margin of unused resource — a situ-ation that can often occur because of conservative assump-tions made during planning — the excess can be deployedto achieve bonus experiments in the form of opportunities.Similarly, if failure of parts of the primary timeline leavesthe lander with freed resource, opportunities can be used toachieve some scientific return from the resource that wouldotherwise be wasted.
System Architecture
Our system architecture is illustrated in figure 3. The lowerpart of this diagram shows the ground-based operationsplanning tools. These include standard timeline planningtools used in earlier ESA missions. The interface betweenthese tools and the lander is achieved via the generatedtelecommands. The lander is represented using the originalBeagle 2 on-board software (OBS), running in an ERC32emulator on a Sun Solaris machine. Hardware elements of
the lander are simulated in software. The Beagle 2 OBSwas modified to allow communication with the additionalmodule, TVCR. This module was constructed using severalexisting software components and was not, therefore, builtwith a view to on-board deployment. As a consequence,the most efficient connection with the OBS was determinedto be through a page of external memory which could bewritten-to and read-from by the emulated ERC32. TVCRran as an external library on the Solaris machine, invokedwhen the external memory page was written-to by the OBS.
TVCR: An on-board planning assistant
TVCR is built around our plan validation system,VAL (Howey, Long, & Fox 2004a; 2004b; Fox, Howey,& Long 2005), coupled with a plan-execution architecture,originally developed for robot control (Coddingtonet al.2005). The execution architecture is not critical to the be-haviour of TVCR, but was a convenient framework in whichto work. TVCR receives three types of requests from theOBS: validate, control and repair. Thevalidate request isissued when a new timeline has been transmitted to the lan-der. The OBS issues the request before the timeline beginsexecution. The timeline is then validated using the on-boardstate and model. The model is a PDDL (McDermott & theAIPS’98 Planning Competition Committee 1998) descrip-tion of the domain, using continuous functions that veryclosely approximate the solar generation and battery usecurves. We discuss the model below. Thecontrol request isissued periodically by the OBS, during execution of a time-line, in order to monitor the continuing evolution of the tra-jectory. In our prototype the control request frequency wasset at 0.1 Hz, but this could be dynamically adjusted to suitthe demands on CPU and memory, as well as the granular-ity of current activities. In response to this request, TVCRcan revalidate the plan, but this depends on how close to the
SUN Solaris
PC/Laptop/Linux
SCOS 2000
SchedulerCONTOOL
TM DisplaysManual Stack
Structure
TCTM
Platform and Payload
Simulation (PPS)
TEST with TVCR TEST without TVCR
i.e. Nominal Beagle 2 System
Addition of ConstraintsAnd opportunity science fragments
Creation of Initial Timeline
(TSIM)IO Module
ECCS
MMIMMUROCO- II
ARE
Control Manager
SUN Solaris
PC/Laptop/Linux
SCOS 2000
SchedulerCONTOOL
TM DisplaysManual Stack
DAFDAFDAF
DAFDAFDAF
DAF
Structure
DAFDAF
StructureStructure
StructureStructure
TCTC TMTM
TCTM
Platform and Payload
Simulation (PPS)
Beagle 2 Lander Software (OBS)
TSIMERC32
Beagle 2 Lander Software (OBS)
TSIMERC32
TVCRTVCR
TEST with TVCR TEST without TVCR
i.e. Nominal Beagle 2 System
Addition of Constraints Creation of Initial Timeline
(TSIM)IO Module
ECCS
MMIMMUROCO- II
ARE
Control Manager
Figure 3: The system architecture, showing both ground and lander segments.
next critical transition in the activities of the system TVCRjudges the system to be. In particular, TVCR validates thetimeline following initiation of a new activity and approach-ing the end of an activity. It will also validate the timelinein between activities if there is sufficient gap before the nextactivity will begin. Essentially, once this gap is small, it isnot possible for TVCR to respond to an anticipated activ-ity failure before the failure would be triggered anyway onattempted dispatch to the lander executive.
The final request,repair, is only issued by the OBS af-ter TVCR has signalled that an earlier request (eithervali-dateor control) has identified a potential failure in the time-line. In fact, when TVCR identifies such a potential flaw itdoes not immediately signal the fact to the OBS (althoughit is logged). Instead, the problem is signalled when TVCRjudges that there is a window during which it would be ap-propriate to respond. One reason for this is that anticipatedfailures far into the future might be countered by activities inthe nearer term completing well within the (usually conser-vative) estimated resource requirements. Reacting too earlyto anticipated plan failure can be as damaging as failure toact. TVCR continues to monitor the timeline execution andthe anticipated failure point, based on the type of failure thatis expected, until the point it considers appropriate to alertthe OBS. Once OBS issues arepair request, TVCR is sanc-tioned to act to repair the timeline.
TVCR Acting to Repair the TimelineTVCR is intended to operate within tightly constrained re-source limits: processor cycles and memory availability areboth severely restricted. For this reason, we have adopteda strategy that is based on a hierarchy of responses, startingwith a simplest response which is to repair a damaged time-
line by removing the activities from the current timeline thatare affected by the observed failures. This process involvesfirst removing the fragments in which the affected activitieslie, using the structure identified by the operations personnelthroughCONTOOL. The impact of these removals is prop-agated through the constraints which were also entered byoperations personnel. The resulting structure is revalidatedand, if there remains a violation of resource demands, fur-ther components are removed, using the priority levels seton the ground to determine the order in which fragmentsare taken out of the timeline. Where there are dependenciesbetween fragments, each fragment is assigned a temporarypriority based on the highest priority fragment that wouldbe affected by its removal. The objective, in this first stage,is to arrive, as quickly as possible, at a baseline core time-line that is executable and represents a maximal executableset of fragments from the original timeline. The only avail-able choices in this process are in situations in which morethan one fragment has been assigned the same priority. Inthis case, TVCR uses an estimated resource requirement foreach fragment and eliminates the one that demands greatestresource. The priority value is assumed to represent an es-timated scientific utility and, if two fragments are of equalutility, the one that returns its rewards at lowest resource costis considered the better choice. There is no backtrackingacross these choices, since the alternative can never improvethe opportunity to find an executable timeline. The processwill always terminate, although it is possible that it mightconverge on an empty timeline. In the situation where thetimeline is empty and the validator still assesses the timelineto be invalid (because resource thresholds are not reached atcritical times), the lander is in a precarious state and the bestchance for survival is to enter a safe mode in a state of alarm.
Once a valid base timeline has been identified, TVCR at-tempts to enhance the timeline. TVCR always maintains thecurrent best timeline, so that if the OBS issues a commandfor an immediate response, or TVCR itself identifies thatthere is no more time to wait before releasing a timeline (inorder to ensure that the next activity is released on time), thiscurrent best will be the one that is used. This creates a vari-ant “anytime” behaviour, in that the repair process attemptsto use whatever time is afforded to it to improve the existingversion of the timeline until it is either interrupted or reachesthe end of the process.
The enhancements of the timeline are performed by iden-tifying a subset of possible opportunity fragments that mightbe added to the timeline. This set is pruned to include onlythose for which dependencies are satisfied (or mutual ex-clusions violated) and for which there is sufficient avail-able resource (within the limits of the original primary time-line). The opportunities are then ranked in priority order.In general, there are relatively few opportunities to consider,but there can be choice between alternatives. In particular,when multiple opportunities are awarded the same priority,the choice between them must consider alternative resourcedemands and the interactions between the alternatives andother outstanding opportunities. In order to maintain a tightbound on memory and CPU demands the search is resolvedheuristically, using a greedy selection. This could obviouslybe improved if resources were to be less constrained, butour experience suggests that greedy choice works well. Itis worth recalling that the repair strategy is only applied insituations where resources would otherwise go unused, soeven a sub-optimal enhancement of the timeline offers ben-efits over the timeline without intervention.
The hierarchy of extensions to the timeline begins by con-sidering the addition of opportunity fragments to the time-line. It should be noted that when a timeline is modified,either by the removal or by the addition of fragments, thenit is generally the case that some additional linking activitiesare required between the ends of the newly adjacent partsof the timeline. TVCR has a special-purpose planner de-signed for this job, which only considers a very small subsetof activities (those relevant to this linking behaviour). Thisproblem is very highly constrained and involves no search,but the linking activities must be known in order to deter-mine the costs of execution of new fragments. Following thesimple addition of fragments, the next possibility that is con-sidered is the rescheduling of activities in order to open upwider windows of opportunity for execution of longer activ-ities. This is particularly useful when small overlaps preventan opportunity from fitting into a gap between other activ-ities in the timeline. The rescheduling considers only thepossibility of sliding activities along the timeline and this isrestricted by any constraints stipulated on activities by op-erations personnel, including activities that are locked (suchas communications activities) or that must occur in certainlighting conditions.
In principle, the addition of opportunities can open upnew opportunities, through satisfaction of dependencies, sothe set of opportunities can be modified after each enhance-ment of the timeline. The process of generation of further
enhancements is restricted by the time, CPU and memoryresources available to the repair process, but TVCR willcontinue to explore the hierarchy of extended timelines untilnotified that there is no further resource, or until no furtherimprovement can be found. In our test cases there were rela-tively few opportunities to consider and reasoning resourceswere never a limiting factor.
The Domain Model and Timeline ValidationWhen we began work on the construction of a PDDL do-main model, we started with a pre-existing model built bythe scientists working on the Beagle 2 project. We foundthat this model was so similar in form to PDDL that a simplescript provided us with an initial translation into PDDL. Weconcluded that the level of abstraction we require to supportplan validation using our PDDL model is an appropriate andnatural one for operations personnel and that it correspondswell to the level at which timeline activities are planned inactual missions. The model is based on a pre- and post-condition description of activities, most of which are dura-tive actions. A few actions, such as turning on the torchattached to the PAW, are not best captured as durative ac-tions. The model also required an appropriate power modeland temperature model. In these cases we found that theextensions forming PDDL+ (Fox & Long 2006), compris-ing the addition ofprocessesandeventswere an appropriatebasis for modelling the domain behaviours. Torch activi-ties are modelled as instantaneous actions (turning on andturning off the torch), with a process consuming power be-tween the two. The power model is constructed using con-tinuous processes that capture an approximate, but realis-tic, model of solar power generation and of battery state ofcharge. Our model of temperature is not continuous: wewere supplied with a discretised model of the temperatureof various nodes on the lander structure at hourly intervals.This is used to construct a series of timed assertions in theinitial state of each planning problem instance. We chose toadopt the discretised model in this case in order to demon-strate that our approach can handle both a continuous anda discretised model. In both cases the model is an approxi-mation, although with different levels of discrepancies, andone of the key issues in managing the plan validation is toensure that the activity models are conservative with respectto these approximations.
Validation of a timeline involves projection of the statethrough a series of models of activities representing thetimeline. This process involves confirming that the in-teractions between processes (power generation and con-sumption) are correctly monitored across intervals of ac-tivity. Since the functions describing these processes arenon-linear, monitoring them involves checking whether non-linear functions have roots within certain intervals. We usea mixture of analytic techniques and numerical techniquesto achieve this. Since we do not expect our systems to runtoo close to operational envelopes, the accuracy of numer-ical techniques is not an issue in these tests. Indeed, theaccuracy of numerical techniques for solving these func-tions is far greater than the accuracy of the predictive mod-els themselves. The environment introduces uncertainty in
the form of degradation of solar panels through accumula-tion of dust, through atmospheric effects and through tem-perature effects. As a consequence, the prediction of thestate of charge will always be subject to a degree of inac-curacy during actual execution. The objective is to achievea sufficiently accurate model to enable robust prediction ofthe outcome of planned activity — if no such model can beconstructed because of excessive uncertainty, then the wholepurpose of planning is called into question.
EvaluationEvaluation of TVCR is complicated by the fact that its role ismost important when the execution trajectory has performedunexpectedly. We were further constrained by the hardwaresimulation we were using: this did not simulate the detailedfunction of some instruments, making it very difficult tomodel failures in those subsystems. In order to understandthe impact of an operational failure during timeline execu-tion, consider the schematics in figures 4, 5 and 6. Figure 4shows the typical progression of operations, in which time-lines are planned during the day (sol) preceding their ex-pected execution (assuming an operational cycle of roughlyone sol). At the end of each day the data generated by thatday’s operations is downlinked for analysis and a new time-line is uplinked for execution in the following day. If thereis an operational failure in this cycle (shown figure 5 imme-diately following activity 21) the ground staff will not be-come aware of it until the end of that day’s activities. Theplanned timeline for the next day will be downlinked be-fore the ground staff become aware of the problem in thecurrent day’s activities. In the worst case, this timeline willno longer be executable, probably because the lander willhave entered safe mode in response to the failure. Assum-ing that the ground staff now wish to execute diagnostics,they will have a first opportunity to perform new activitiesby the second day following the failure. It is likely thatother activities might be included at this time, dependingon the severity of the failure. Instrument repairs will thentake place on the third day following the failure and normalactivity will be resumed only on the fourth day after the fail-ure. With TVCR (figure 6) the failure will (assuming thefailure is not too severe) lead to the insertion of opportuni-ties into the timeline on the first day. These can include adiagnostic activity which would be constrained to be addedto the plan only if the instrument operation had not been per-formed (that is, the diagnostics would be mutually exclusivewith a successful operation of the instrument for which theywere relevant). The planned timeline for the following daywould almost certainly not execute directly following thedisrupted cycle of operations, but parts of it might executesuccessfully and TVCR could insert additional opportunitiesto absorb the otherwise undersubscribed resources availableon that day. Meanwhile, the ground staff, armed with thediagnostics, would be in a position to plan instrument re-pairs and continuation of the remaining science mission, sothat by the second day following failure a full sequence ofactivities could be completed. Normal operations would re-sume fully on the third day, but the intervening period wouldhave included a fully populated timeline, so that the mission
would have continued to gather scientific data and completediagnosis and repair of instrument failures.
Of course, this schematic view is both simplified and, tosome extent, optimistic. In practice, it is quite plausible thatTVCR could not completely populate the timeline. In thecase of severe system failures, TVCR would be unlikely tobe able to anything. However, mission logs demonstratethat minor failures occur regularly and with frustrating fre-quency, leading to periods of significant science blackout asmissions personnel put the lander back into an operationalstate and resynchronise their view of its status with reality.It is in these cases where TVCR can help to recover whatwould otherwise be lost time and resources.
To explore the performance we generated a collectionof scenarios, based around a common timeline, featuringtwo rock geology experiments. The primary timeline con-tained two Mossbauer spectrometer experiments, supportedby imaging and rock grinding activities (see figure 7). Wethen considered a variety of possible failures. These in-cluded:
• A scenario in which the Mossbauer was assumed to havefailed prior to the timeline being uplinked. This mighthappen if the instrument had failed in an activity in thetimeline immediately preceding this one, so that the fail-ure would be unknown to the ground staff at the time ofconstruction of the new timeline.
• A scenario in which the Mossbauer failed during the firstactivity in which it was used.
• A scenario in which there was insufficient battery chargeat the start of the plan to allow it to complete execution.
In each case, TVCR performed as expected and repairedthe timeline. Where a suitable opportunity was available,TVCR inserted it into the timeline, together with the neces-sary linking activities to create a complete, coherent time-line, which was then successfully simulated to conclusion.As can be seen in figure 8, the timeline executed whenTVCR performed repair was significantly enhanced com-pared with the one executed without TVCR. In the uppercase almost all of the timeline is abandoned without TVCRsupport. In both cases the timeline is repaired by removalof the damaged activity or activities and an opportunity isinserted into the timeline in the place of the first. This is anenvironmental sensing activity and relies on the PAW beingplaced into an appropriate attitude. This is achieved by theaddition of some simple “glue” activities that reposition thePAW prior to execution of the fragment and then rejoin theexecution of the original timeline at its conclusion.
A further dimension for evaluation is that of performance.In our tests, the validation of a timeline of approximatelytwo sols of activity could be performed in less than 3 sec-onds using an estimated ERC32 processor speed, with repairin less than 6 seconds. Our prototype was not optimised foreither memory or processor performance, but we considerthis figure to be representative of the performance we canexpect from TVCR.
Execute plan iReturndata i
Generateplan j
Check Landerstate
Time
FCT
Plan
Evaluate
Exploit
Support
Teams
Sendplan j
Execute
Sol i Sol j Sol l
Check plan hexecution
Generatescience
products h
Analysescienceresults h
MPT MET GOT
Execute plan jReturndata j
Generateplan k
Check Landerstate
FCT
Sendplan k
Check plan iexecution
Generatescience
products i
Analysescienceresults i
MPT MET GOT
Sol k
Execute plan kReturndata k
Generateplan l
Check Landerstate
FCT
Sendplan l
Check plan jexecution
Generatescience
products j
Analysescienceresults j
MPT MET GOT
Execute plan lReturndata l
Generateplan m
Check Landerstate
FCT
Sendplan m
Check plan kexecution
Generatescience
products k
Analysescienceresults k
MPT MET GOT
21 22 23 24 25 26 27 28 29 30 31 33
99 => Experiment 99
Figure 4: Normal operations sequence.
Executeplan i Return
data i
Generateplan j
Time
FCT
Plan
Evaluate
Exploit
Support
Teams
Sendplan j
Execute
Sol i Sol j Sol l
Generatescience
products h
Analysescienceresults h
MPT MET GOT
Returndata j
Generatediagnostic
plan k
FCT
Sendplan k
Generatescience
products i
Analysescienceresults i
MPT MET GOT
Sol k
Execute diagnosticplan k Return
data k
FCT
Send noplan
MPT MET GOT
Returndata l
Generaterepair plan
m
FCT
Sendplan m
MPT MET GOT
Bang!
Analysefailure
Identifydiagnostics
Analysediagnostic
data
IdentifyrepairsAnalyse failure
Check Landerstate
Check plan hexecution
Check Landerstate
Check plan iexecution
Check Landerstate
Check Landerstate
Check plan kexecution
Generatereduced
plan l
Execute reducedplan l
Generatescience
products i
Analysescienceresults i
21 24 26 27S
99 => Experiment 99 Z => Diagnostic Z
Figure 5: Operations sequence with failed activity.
Executediagnostics &opportunities
Executeplan i Return
data i
Generate plan j
Time
FCT
Plan
Evaluate
Exploit
Support
Teams
Sendplan j
Execute
Sol i Sol j Sol l
Generatescience
products h
Analysescienceresults h
MPT MET GOT
Generate repair plank
FCT
Generatescience
products i
Analysescienceresults i
MPT MET GOT
Sol k
FCT MPT MET GOT
Generate plan m
FCT MPT MET GOT
Bang!
Analysescienceresults j
Analysescienceresults k
Generatescience
products j
Generatescience
products k
Execute viable parts ofplan j & opportunities Return
data j
Sendplan k Execute repair plan k
Returndata k
Sendplan l
Generate plan l
Execute plan lReturndata l
Sendplan m
Generate diagnostics& opportunities
Check Landerstate
Check plan hexecution
Check Landerstate
Check plan iexecution
Check Landerstate
Check plan jexecution
Check Landerstate
Check plan kexecution
Analysediagnostic
data
Identifyrepairs
Generate diagnostics& opportunities
Generate diagnostics& opportunities
Generate diagnostics& opportunities
21 24 22 23 25 26 27S Q K M
99 => Experiment 99 Z => Diagnostic or Opportunity Z
Figure 6: Operations sequence with on-board plan repair.
MI
RCG
Moss
XRS
Mole
MI
RCG
Moss
XRS
Mole
Comms Session
Figure 7: Base timeline showing instruments it commands.
ConclusionWe have successfully constructed a prototype system thatacts as an on-board plan validation and repair system. Wehave used the prototype to demonstrate that on-board rea-soning about plans is a practical objective which is less am-bitious than full-scale planning, but that can grant huge ben-efits in terms of science return. Several features contributeto this. Firstly, an on-board system is best placed to monitorexecution of a plan and react to failures in a timely and effec-tive way. Secondly, the very fact that plans can be brittle inexecution means that operations staff tend to be conservativein their construction of plans, leading to under-subscriptionof lander resources. The combination of these factors canlead to significant periods of downtime during deep spacemissions. An on-board planning assistant could exploit theslack during execution of a plan and adapt to plan failures inorder to improve the scientific return.
ReferencesAi-Change, M.; Bresina, J.; Charest, L.; Hsu, J.; Jonsson, A.;Kanefsy, R.; Maldegue, P.; Morris, P.; Rajan, K.; and Yglesias, J.2003. MAPGEN: Mixed intitive activity planning for the MarsExploratory Rover mission. InProceedings of DemonstrationSystems Track, ICAPS’03.
Blake, O.; Bridges, J.; Chester, E.; Clemmet, J.; Hall, S.; Han-nington, M.; Hurst, S.; Johnson, G.; Lewis, S.; Malin, M.; Mori-son, I.; Northey, D.; Pullan, D.; Rennie, G.; Richter, L.; Roth-ery, D.; Shaughnessy, B.; Sims, M.; Smith, A.; Townend, M.;and Waugh, L. 2004.Beagle2 Mars: Mission Report. LanderOperations Control Centre, National Space Centre, University ofLeicester.
Chien, S.; Sherwood, R.; Tran, D.; Cichy, B.; Rabideau, G.; Cas-tano, R.; Davies, A.; Lee, R.; Mandl, D.; Frye, S.; Trout, B.;Hengemihle, H.; D’Agostino, J.; Shulman, S.; Ungar, S.; Brakke,T.; Boyer, D.; Gaasbeck, J. V.; Greeley, R.; Doggett, T.; Baker,V.; Dohm, J.; and Ip, F. 2004. The EO-1 autonomous scienceagent. InProceedings of AAMAS-04.
Coddington, A.; Fox, M.; Gough, J.; Long, D.; and Serina, I.2005. MADbot: A motivated and goal directed robot. InPro-ceedings of AAAI’05 (Intelligent Systems Demo).
Fox, M., and Long, D. 2003. PDDL2.1: An Extension to PDDLfor Expressing Temporal Planning Domains.Journal of AI Re-search20:61–124.
Fox, M., and Long, D. 2006. Modelling mixed discrete-continuous domains for planning.Journal of AI Researchforth-coming.
Fox, M.; Howey, R.; and Long, D. 2005. Validating plans in thecontext of processes and exogenous events. InProceedings of The20th National Conference on Artificial Intelligence (AAAI-05).
Gerevini, A., and Long, D. 2006. Plan constraints and prefer-ences on PDDL. InICAPS Workshop on Soft Constraints andPreferences in Planning.
Howey, R.; Long, D.; and Fox, M. 2004a. Plan validation andmixed-initiative planning in space operations. InProceedings ofthe Workshop on ‘Planning and Scheduling: Bridging Theory toPractice’ (ECAI’04).
Howey, R.; Long, D.; and Fox, M. 2004b. VAL: Automatic planvalidation, continuous effects and mixed initiative planning usingPDDL. In Proceedings of 16th IEEE International Conference onTools with Artificial Intelligence.
Jonsson, A.; Morris, P.; Muscettola, N.; and Rajan, K. 2000. Plan-ning in Interplanetary Space: Theory and Practice. InProceed-ings of International Conference on Artificial Intelligent Planningand Scheduling (AIPS).
McDermott, D., and the AIPS’98 Planning Competition Commit-tee. 1998. PDDL–the planning domain definition language. Tech-nical report, Available at:www.cs.yale.edu/homes/dvm .
Woods, M.; Aylett, R.; Long, D.; Fox, M.; and Ward, R. 2003.Assessing planning and scheduling technologies for deep spaceexploration. InProceedings of 4th British Conference on (Mobile)Robotics: Towards Intelligent Mobile Robots.
Figure 8: Timeline execution paths. The top screen shot shows the original timeline (top third) and the timeline actuallyexecuted with (middle) and without (bottom) TVCR, for the case in which the timeline is recognised at the outset as damaged.Actions shown in the pale colour below the executed timeline are activities that were removed from the timeline during therepair, while dark activities slightly offset above the timeline are new activities added into the timeline by TVCR. The lowerscreenshot shows the timeline repaired when the Mossbauer fails after its first operation in the timeline.
