Request-Driven Scheduling for NASA’s Deep Space Network

Mark D. Johnston, Daniel Tran, Belinda Arroyo, and Chris PageJet Propulsion Laboratory/California Institute of Technology

4800 Oak Grove DrivePasadena, California 91109

Abstract

This paper describes recent work undertaken to increase thelevel of automated scheduling support available to users ofNASA’s Deep Space Network (DSN). We have adopted arequest-driven approach to DSN scheduling, in contrast to theactivity-oriented approach used up to now. We describe someof the key constraints and preferences of the DSN schedul-ing domain and how we have modeled these as schedulingrequests. Algorithms to expand requests into valid resourceallocations, and to resolve schedule conflicts and unsatisfiedrequests, have been developed and incorporated into a dis-tributed system of servers called the DSN Scheduling Engine(DSE). To explore the usability aspects of our approach wehave developed a pathfinder graphical user interface that uti-lizes the DSE. This GUI incorporates several key features tomake it easier to work with complex scheduling requests, in-cluding progressive revelation of detail, immediate propaga-tion and feedback of implications, and a “meeting calendar”metaphor for repeated patterns of requests. This pathfindersystem has been deployed and adopted by one of the JPLDSN scheduling teams, representing an initial validation ofour overall approach. The DSE is planned to be a centralelement of the Service Scheduling Software (S3) web-basedscheduling system now under development for deployment toall DSN users.

IntroductionNASA’s Deep Space Network (DSN) provides communi-cations services for planetary exploration missions as wellas other missions beyond geostationary, supporting bothNASA and international users. It also constitutes a scien-tific observatory in its own right, conducting radar investi-gations of the moon and planets, in addition to radio sci-ence and radio astronomy. The DSN comprises three an-tenna complexes in Goldstone, California; Madrid, Spain;and Canberra, Australia. Each complex contains one 70mantenna and several 34m antennas, providing S-, X-, andK-band up and downlink services. The distribution in longi-tude enables full sky coverage and generally provides someoverlap in spacecraft visibility between the complexes. Amore detailed discussion of the DSN and its capabilities canbe found in (Imbriale 2003).

Copyright c! 2009, California Institute of Technology. Govern-ment sponsorship acknowledged.

Figure 1: The 70m antenna at the Goldstone DSN complexin California

The process of scheduling the DSN is complex and time-consuming. There is significantly more demand for commu-nications services than can be handled by the available as-sets. There are numerous constraints on the assets and on thetiming of communications supports, due to spacecraft andground operations rules and preferences. Most DSN usersrequire a firm schedule around which to build spacecraftcommand sequences, weeks to months in advance. Cur-rently there are several distributed teams who work withmissions and other users of the DSN to determine their com-munications needs, provide these as input to an initial draftschedule, then iterate among themselves and work with theusers to resolve conflicts and come up with an integratedschedule. This effort has a goal of a conflict-free scheduleby eight weeks ahead of the present, which is rarely met inpractice. In addition to asset contention, many other factorssuch as upcoming launches (and their slips) contribute to thedifficulty of building up an extended conflict-free schedule.

There have been a variety of efforts over the years toincrease the level of automation in the DSN to supportscheduling. Currently, the DSN scheduling process iscentered around the Service Preparation Subsystem (SPS)which provides a central database for schedules and for theauxiliary data needed by the DSN to actually operate the an-tennas and communications equipment (e.g. viewperiods,sequence of event files). The TIGRAS program (Borden,Wang, & Fox 1997) is used for schedule viewing and edit-ing, along with a number of other tools for generating spe-cialized reports and graphics. The current effort to improvescheduling automation is designated the Service SchedulingSubsystem, or S3, which will be integrated with SPS. Thereare three primary features of S3 that are expected to improvethe scheduling process:• unifying the scheduling software and databases into a sin-

gle integrated suite covering realtime out through as muchas several years into the future

• adopting a request-driven approach to scheduling (ascontrasted with the current activity-oriented scheduling)

• development of a peer-to-peer collaboration environmentfor DSN users to view, edit, and negotiate schedulechanges and conflict resolutions

In this paper we focus on the second of these major capa-bilities — request-driven scheduling, and its implications interms of a scheduling request specification or “language”,and on the scheduling algorithms themselves. We first pro-vide some background on the DSN scheduling problem andthe existing scheduling tool suite, and on the rationale forthe approach taken by S3. We then describe the schedul-ing request specification, which is how DSN users will de-scribe their service requests to the system. These requestsare processed by the DSN Scheduling Engine (DSE), whichexpands schedule requests into tracking passes, integratingthem into an overall schedule, seeking to minimize conflictsand request violations. A pathfinder graphical user inter-face has been developed for creating and editing schedulerequests, and integrating them into schedules and minimiz-ing conflicts. This pathfinder version has been deployed ina test configuration for several months, and we describe ourexperiences to date and lessons learned from this prelimi-nary deployment. We conclude with an overall status sum-mary, and a description of plans for ongoing development.

BackgroundThe driving factors towards increased automation of theDSN come from several directions. The expected increase inthe number of missions from NASA and international part-ners will put more and more pressure on the available DSNresources, a trend which is expected to accelerate in the fu-ture. More missions are expected to have higher data vol-umes and greater link complexities. At the same time, thereis a strong desire to reduce operations costs, while increasingreliability and continuing to provide 24h service coverage.

Increased automation support for DSN scheduling has along history. LR-26 was a customizable heuristic schedul-ing system for the 26-meter antennas using Lagrangian re-laxation and constraint satisfaction search techniques(Bell

1992). Operation Mission Planner (OMP-26) used heuristicsearch to allocate 26-meter antennas to missions, and linearprogramming to adjust track durations(Kan, Rosas, & Vu1996). The Demand Access Network Scheduler (DANS)included all antennas and used a heuristic iterative repair ap-proach (Chien et al. 1997). Other investigations into aredescribed in (Fisher et al. 1998; Clement & Johnston 2005;Johnston & Clement 2005; Guillaume et al. 2007).

The current DSN scheduling software project S3 is de-rived from a 2004 resource allocation process working groupthat analyzed the DSN scheduling process and identified akey set of goals for implementation, listed in the Introduc-tion. One of these goals centers on the basic entities thatdrive the schedule. In the past, and currently, these are thescheduled communications passes (tracks) or other individ-ual activities that are placed on the schedule. All of the soft-ware to create, manage, and report the DSN schedule arebuilt around a representation of the schedule as a collectionof activities. The shift to a request-driven (sometimes calledrequirements-driven) approach is a fundamental shift in rep-resentation, adding a layer above tracks, such that the pre-dominant control mechanism of users over the schedule isvia scheduling requests, rather than the individual scheduledactivities. Note that it is not anticipated that individual ac-tivities can be bypassed; indeed, all the basic capabilities ofactivity-oriented scheduling are still required: users need tobe able to edit individual activities, for reasons that may notbe expressible in the form of scheduling requests. However,the net benefits of a request-driven approach outweigh thoseof activity-oriented scheduling in several important ways:• leveraged effort: one scheduling request can generate and

be used to manage many scheduled activities, and onechange to a request can propagate to all activities derivedfrom it; this can significantly reduce the ongoing effortneeded to generate the schedule and manage its changes

• automated continuous schedule validation: based on therequest specification, the schedule can be continuouslymonitored against constraints and preferences; this canhelp minimize the effort to ensure that schedule changes,as they invariably occur, will not introduce undetected in-consistencies between requests and activities

• traceability: all activities trace to scheduling requests thatdescribe the purpose and intent of the generated activities

The main disadvantage of a request-driven approach is thatthe request specification language is complex(Clement et al.2008). There are many options and subtleties involved indescribing the constraints and preferences on DSN activities,and a sufficiently rich representation of these is necessarilylarge and complicated. Some of the problems that ensue are:

1) what appears at a high level to be a simple request isoften much more involved when practical details are consid-ered, yet all of these details may be needed (even if rarely)to fully describe how and when a particular activity can bescheduled. Users do not want to be bombarded with requestsfor detail when using the system, but neither will they acceptthat they cannot make use of all available options.

2) many interdependent options can make it difficult to tellwhether a request is feasible: the interactions of time win-

dows with other request parameters can all too easily leadto inconsistencies, which may not show up until late in thescheduling process.

3) failure to accurately represent the correct applicableflexibilities forces schedulers to use workarounds that arti-ficially limit flexibility, thus inhibiting user acceptance ofthe system. For example, if it is not possible to representthat any one of several choices is acceptable, then the hu-man scheduler must pick one, and the advantages of havingthe flexibility are lost.

These factors pose a major challenge to a request-drivenapproach, in that the effort of creating and managing re-quests, and their consequent benefits in continuous valida-tion of schedule, must be shown to be overall more benefi-cial than an activity-oriented approach in order to gain useracceptance. In the following section we describe how wehave approached the problem of representing DSN schedul-ing requests, and a later section, how we have addressed theway that users can specify complex options.

DSN Scheduling RequestsDSN scheduling requests specify the services required andtheir associated constraints and preferences.

ServicesServices include use of any of the available capabilities ofthe DSN, including uplink and downlink services, Dopplerand ranging (for spacecraft navigation), as well as more spe-cialized capabilities. The details of a spacecraft’s servicespecification depend on the onboard hardware and software(the frequency band, encoding, etc.). Along with other fac-tors such as radiated power levels and distance from theEarth, these all determine a set of antennas and associatedequipment (transmitters, receivers, etc.) that must be sched-uled to satisfy the request. However, these assets are notall equally desirable, and so there are preferred choices forantennas and equipment that also need to be considered.

In addition to single antenna/single spacecraft communi-cations, there are a variety of other DSN service types. Somemissions need the added sensitivity of more than one an-tenna at once, and so make use of arrayed downlinks usingtwo or more ground antennas. For navigation data, thereare special scenarios (DDOR) involving alternating the re-ceived signal between the spacecraft and a nearby quasar,over a baseline that extends over multiple complexes. ForMars missions, there is a capability to communicate withseveral spacecraft at once (called Multiple Spacecraft PerAperture, or MSPA): while more than one may be sendingdown data at once, only one at a time may be uplinking.Another feature of the Mars mission complement is the ca-pability to relay data from surface missions such as the MarsExploration Rover (MER) rovers, via the Mars orbiting mis-sions such as Mars Odyssey and the Mars ReconnaissanceObserver (MRO).

ConstraintsConstraints on DSN scheduling requests fall into severalbroad categories. The most important is timing: users need

a certain amount of communications contact time in orderto download data and upload new command loads, and forobtaining navigation data. How this time is to be allocated issubject to many options, including whether it must be all inone interval or can be spread over several, and whether andhow it is related to external events and to spacecraft visibil-ity. Table 1 lists a number of these factors.

A second category of constraint is that of relationshipsamong contacts. In some cases, contacts need to be suffi-ciently separated so that onboard data collection has time toaccumulate data but not overfill onboard storage. In othercases, there are command loss timers that are triggered ifthe time interval between contacts is too long, placing thespacecraft into safemode. During critical periods, it maybe required to have continuous communications from morethan one antenna at once, so some passes are scheduled asbackups for others.

A third category of constraint can be called “distribution”requirements. These cover some extended time span andspecify constraints on certain aspects of overall set of activi-ties during that time. Examples include: a certain proportionof 70m contacts; ensuring that navigation passes are spreadout roughly evenly between the northern and southern hemi-sphere complexes; ensure that not all contacts in a week areon the same antenna.

PreferencesIn addition to constraints, there are numerous preferencesthat scheduling users have as to how their activities are tobe scheduled. Many would prefer additional time if it isavailable, while at the same time are able to reduce somecontact durations in order to resolve a contentious period onan antenna. There are preferences on gap durations, whethertracks are split or continuous, for tracks to occur during dayshift at a particular operations center, and so on. While someof these preferences are implicit, some must be explicit and,if they apply, need to be specified as part of the schedulingrequest.

PriorityPriority plays a significant role in DSN scheduling, but notthe dominating role that it plays in some other systems (e.g.(Calzolari et al. 2008)). Critical events (launches, surfacelandings, planetary orbit insertions) preempt other more rou-tine activities. Other than critical activities, missions havehigher priorities during their prime (initial phases) than dur-ing their later extended missions. However, higher prioritydoes not automatically mean that resource allocations areassured. Depending on their degree of flexibility, missionstrade off and compromise in order to meet their own require-ments, while attempting to accommodate the requirementsof other users. As noted above, one of the key goals of S3 isto facilitate this process of collaborative scheduling.

Patterns of RequestsOne characteristic of DSN scheduling is that, for most users,it is common to have repeated patterns of requests over ex-tended time intervals. Frequently these intervals correspond

Constraint Description

reducible whether and by how much the requested time can be reduced to fit in an available opportunity

extensible whether and by how much the requested time can be increased to take advantage of available resources

splittable whether the requested time must be provided in one unbroken track, or can be split into two or more

split duration if splittable, the minimum, maximum, and preferred durations of the split segments; the maximum number ofsplit segments

split segmentoverlap

if the split segments must overlap each other, the minimum, maximum, and preferred duration of the overlaps

split segment gaps if the split segments must be separated, the minimum, maximum, and preferred duration of the gaps

viewperiods periods of visibility of a spacecraft from a ground station, possibly constrained to special limits (rise/set, otherelevation limits)

events general time intervals that constrain when tracks may be allocated; examples include:

• day of week, time of day (for accommodating shift schedules, daylight, ...)• orbit/trajectory event intervals (occultations, maneuvers, surface object direct view to Earth, ...)

Different event intervals may be combined and applied to one request. The included events may have apreference ordering.

Table 1: A sample list of possible timing constraints and preferences that can apply within a DSN scheduling request

to explicit phases of the mission (cruise, approach, fly-by,orbital operations). These patterns can be quite involved,since they interleave communication and navigation require-ments. The presence of repeated patterns can be exploited inrepresenting scheduling requests that vary minimally or notat all over some time frame, as will be discussed further be-low.

DSN Scheduling EngineThe DSN Scheduling Engine (DSE) is that component of S3

responsible for:• expanding scheduling requests into individual communi-

cations passes by allocating time and resources to each• identifying conflicts in the schedule, both for resources

and for any other violations of DSN scheduling rules, andattempting to find conflict-free allocations

• checking scheduling requests for satisfaction, and at-tempting to find satisfying solutions

Schedule conflicts are based on the schedule alone, not onany correspondence to schedule requests, and indicate eithera resource overload (e.g. too many activities scheduled onthe available resources) or some other violation of a schedulefeasibility rule (see Table 2a for a representative list). Incontrast, violations (Table 2b) are associated with schedulerequests and with their tracks, and indicate that the requestis not being satisfied in some version of the schedule.

ArchitectureThe DSE is based on ASPEN, the planning and schedulingframework developed at JPL and previously applied to nu-merous problem domains (Chien et al. 2000). In the contextof S3, there may be many simultaneous users, each working

SMA

JMS messagebus

Schedule Manager

Application

AMA

ASPEN

ASPEN Manager

Application

DSE (DSN Scheduling Engine)

Figure 2: DSE architecture

with a different time segment or different private subset ofthe overall schedule. This has led us to develop an envelop-ing distributed architecture (Figure 2) with multiple runninginstances of ASPEN, each available to serve a single userat a time. We use a Java Messaging System (JMS) middle-ware tier to link the ASPEN instances to their clients, via anASPEN Manager Application (AMA) associated with eachrunning ASPEN process. A Scheduling Manager Applica-tion (SMA) acts as a central registry of available instancesand allocates incoming work to free servers. This architec-ture provides for flexibility and scalability: additional sched-uler instances can be brought online simply by starting themand having them register with the SMA.

The DSE communicates with clients using an XML-based messaging protocol, similar to HTTP sessions butwith responses to time-consuming operations returned asyn-chronously. Each active user has a session (possibly morethan one) which has loaded all the data related to a sched-ule that user is working on. This speeds the client-server

(a)

Conflict Type Description

Spacecraft Multiple tracks of the same mission share the same temporal extent

Beginning of Track– BOT*

Multiple tracks start with in 15 minutes of Goldstone and 30 minutes for Canberra and Madrid.

Start of Activity –SOA*

Multiple tracks start with in 15 minutes of Goldstone and 30 minutes for Canberra and Madrid.

Antenna (Facility) Multiple non-MSPA tracks use the same antenna at one time

Equipment* Multiple tracks share the same equipment during the same temporal extent

Viewperiod The spacecraft/user is out of view of the track antenna

Teardown The post-track teardown time does not match the expected teardown time

Setup The pre-track setup time does not match the expected setup time*Not enabled in initial DSE release

(b)

Violation Type Description

Track Quantization The track start or end time violates the request quantization constraint. For example, requests can specify thattracks start or end only at 5 minute intervals.

Track Separation If the request is splittable, the separation time between two tracks violates the split segment overlap or splitsegment gap constraint.

Track Duration If the request is splittable, the track duration violates the request split duration constraint.

ServiceSpecification

The track violates the request service specification, i.e. the antenna or equipment allocated does not match therequested service.

Total TrackDuration

The total track duration does not meet the requested duration

Number of Tracks The number of tracks for the requests violates the maximum. For a non-splittable track, this limit is 1; for asplittable track, the limit may be specified.

Track TemporalExtent

The track start or end time falls outside the scheduling request’s time interval.

Event Reference The track time interval violates the intersection of the event time intervals referenced by the schedulingrequest.

Request Reference The track time interval violates the scheduling request’s temporal constraint link to other requests.

Table 2: Representative schedule conflicts (a) and violations (b)

interaction, especially when editing scheduling requests andactivities, when there can be numerous incremental schedulechanges.

There are a few basic design principles around which theDSE has been developed, derived from its role as providerof intelligent decision support to DSN schedulers:

• no unexpected schedule changes:

– all changes to schedule must be requested, explicitly orimplicitly

– the same sequence of operations on the same data willalways generate the same schedule

• even for infeasible scheduling requests, attempt to returnsomething “reasonable” in response, possibly by relax-ing aspects of the request; along with a diagnosis of thesources of infeasibility, this provides a starting point forusers to handle the problem

AlgorithmsWith these design principles in mind, several automatedscheduling algorithms were developed to generate activitiesfrom scheduling requests. Users may lock requests and ac-tivities to ensure that they are not modified, and the execu-tion of these algorithms is under the explicit control of theuser (see GUI description). Also, there are no stochastic ele-ments to these algorithms, thus ensuring that repeated opera-tions with the same data always generate the same schedule.

Initial generation of tracks The initial layout algorithm(Algorithm 1) is executed to initially generate tracks to sat-isfy the specifications of the request. The algorithm con-sists of a series of systematic search stages over the legaltrack intervals, successively relaxing constraints each stageif no solution is found. The systematic search algorithm is adepth-first search algorithm over the space of available an-tenna start times and durations for each scheduling request.The set of legal antennas for scheduling is defined in therequest service specification, while the available start timesand durations search space is defined by the request quanti-zation value.

We are employing four relaxation strategies. These strate-gies are outlined below, with each relaxation strategy build-ing upon the previous.

• temporal linkage — the explicit temporal relationshipsbetween tracks in the same or different requests

• track separation — between two track segments from asplittable request

• event intervals — the time intervals (exclusive of viewpe-riods) that constrain the timing of the track

• spacecraft, antenna, and equipment — removing theseconflicts from consideration (Table 2) leaves only theviewperiod constraint

These relaxation strategies allow for tracks to be generatedeven though the scheduling request may be infeasible (inisolation or within the context of the current schedule), andprovides the user a starting point to make any corrective

Algorithm 1 Initial LayoutFor each request in the schedule

Remove existing request tracksSystematically search legal intervals to satisfy the requestIf success

Continue to next requestEnd if

Remove all lower priority tracks in request intervalSystematically search legal intervals to satisfy the requestIf success

Add all tracks removedContinue to next request

End if

Remove all equal priority tracks in request intervalSystematically search legal intervals to satisfy the requestIf success

Add all tracks removedContinue to next request

End if

Remove all remaining tracks in request intervalSystematically search legal intervals to satisfy the requestIf success

Add all tracks removedContinue to next request

End if

For each relaxation strategySystematically search legal intervals to satisfy requestIf success

Add all tracks removedContinue to next request

End ifEnd for

End for

Algorithm 2 Repair Conflicts/ViolationsUntil timeout or schedule is conflict/violation free

Choose a conflict or violationIdentify the contributing requestsFor each request

Checkpoint current stateSystematically search the legal intervals to satisfy

the requestIf success or timeout

Continue to next conflict/violationElse

Recover to checkpoint stateEnd if

End forEnd until

Algorithm 3 Extend Track To Preferred DurationFor each conflict-free track in the schedule

Checkpoint current stateExtend duration of track to min(legal interval duration,

preferred duration requested)If violations created

Recover to checkpoint stateEnd if

End for

changes as needed. These changes may range from modify-ing the scheduling request to introduce more tracking flex-ibility, to contacting other mission schedulers to negotiatedifferent request time opportunities.

Repairing the schedule Once an initial schedule has beengenerated, conflicts and/or violations may exist in the sched-ule due to the relaxation of constraints. The DSE provides abasic repair algorithm to reduce conflicts or violations, de-scribed as Algorithm 2. Note that conflicts and violations areindependent, so there are separate versions provided throughthe user interface for users to invoke.

Optimizing existing tracks in the schedule We also pro-vide the user a method for optimizing existing tracks in theschedule. For requests that are reducible in duration, theabove scheduling algorithms may return tracks that, whilestrictly satisfying the request specifications, have durationsthat are less than the preferred value, e.g. in order to fit intoan available opportunity window. We thus provide an ad-ditional algorithm (3) that attempts to achieve the preferredtrack duration values.

PerformanceWe have conducted initial performance testing of the DSE,based on schedules of varying duration from 1 week through6 months. For these tests we used the same 14 mission sam-ple, and repeated their requests uniformly over the entireschedule period. The results are shown in Figure 3: bothruntime and memory usage are very well behaved, showingroughly linear growth over the time range of interest.

User InterfaceTo investigate the capability of the request specificationlanguage outlined above, we have developed a pathfindergraphical user interface and web application. The user inter-face incorporates all of the major basic features of schedul-ing requests, including viewperiod and event management,and scheduling request creation and editing with all of thefeatures noted in Table 1. This UI acted as a DSE clientfor expanding schedule requests to tracks, identifying andresolving conflicts, and identifying and resolving request vi-olations. The main simplification was to limit the DSE/UI tosingle-mission, single antenna scenarios, a restriction whichis being lifted as further development takes place.

The overall architecture of the DSE+UI is illustrated inFigure 4. Multiple users can work with the system at once,each on their own workstation. Each user has installed alocally running copy of the GUI client, which stores a lo-cal copy of all the data needed for scheduling includingviewperiod files, event definitions, scheduling requests, andschedules. All changes to these data items are mirrored ona REST-based web application, which also ensures that as-signed identifiers are globally unique. Users can then sharedata items via a command to the web application that trans-fers over all data associated with a given schedule, includ-ing the scheduling requests and any data needed to properlyinterpret them. This enables users to work on different mis-sions completely independently, yet integrate their requests

(a)

!

!

!

!

0 5 10 15 20 250

50

100

150

200

250

Schedule Duration !weeks", 14 missionsEngineInitialLayoutTime!sec

"

(b)

! !

!

!

0 5 10 15 20 250

100

200

300

400

500

Schedule Duration !weeks", 14 missionsEngineMemoryUsage!Mb"

Figure 3: DSE performance scalability for schedules from 1-week to 6-months in duration: (a) run time for initial layout(~10 sec/week) and (b) memory usage (~15Mb/week)

into a single schedule at the appropriate time. Note that thisarchitecture differs from that of S3, which is based on a cen-tral database and web browser-based client.

The pathfinder GUI was intended to explore and assessseveral aspects of user interaction with the scheduler:

1. Progressive revelation of detail: as noted above, schedul-ing requests can potentially contain many adjustable pa-rameters, often with interrelationships among them. TheGUI uses an animation technique to fade in or out rele-vant parameter choices, as soon as a dependent choice ismade. For example, if a request is for tracking time thatis not splittable, then none of the parameters that controlsplitting are visible on the screen (split minimum dura-tion, maximum number of segments, whether split seg-ments must overlap or be separated, etc.) However, assoon as the user selects the splittable option, a subset ofthese parameters will fade in. This is chained several lev-els deep, e.g. overlap parameters settings are not shownunless the user specifies that the split segments must over-lap (Figure 5).

2. Immediate display of implications: another aspect of thepotential complexity of scheduling requests is that it isnot difficult to overspecify a request, thus making it im-possible to satisfy. For example, the duration of schedul-

User1

UserNSMA

AMA

ASPEN

JMS

REST

webappUser2

UserN

User1

...

DSE

HTTP

Figure 4: The architecture of the DSE/UI pathfinder userinterface

ing request may not fit within any schedulable time inter-val allowed by the intersection of viewperiods and timingevent intervals. Rather than wait for later schedule gen-eration, the pathfinder GUI application adopts a strategyof 1) propagating all known information as far as pos-sible, with the goal of early diagnosis of any problems,and 2) visually displaying as much of this propagatedinformation as possible. For example, as the user editsa scheduling request, the system dynamically calculatesthe intersections of viewperiods and all timing event win-dows, displays the result for all allowable antennas thatcould potentially satisfy a request, and then checks to seewhether the total requested time is available, as well aswhether the time requested for any segment is consistentwith the request’s timing parameters. The results are dis-played as a “preview” Gantt view along side the requestparameters.

3. The “meeting calendar” metaphor for repeated patternsof requests: as noted above, many users formulate their re-quests as a repeated pattern, with variations. We adoptedthe metaphor of a meeting calendar program, with whichmost users are familiar, e.g. in which a meeting or ap-pointment is created and then designated as “recurrent”.For DSN scheduling, the repetition intervals are some-times along typical calendar lines (e.g. daily, weekly),but often are based on trajectory or celestial events (e.g.every visibility interval, or opportunity for a Mars roverto reach earth with its antenna). Additional requirementsinclude the option to place time linkages between succes-sive repetitions, e.g. to prevent two neighboring passesfrom being too close together (Figure 6).

Once scheduling requests have been created, they may becombined to generate a schedule by invoking the DSE to ex-pand the requirements into explicit tracks. The DSE gener-ates and returns the scheduled activities, identifies conflicts,and checks that all requests are satisfied. The user may in-voke a conflict repair strategy, or requirement violation re-pair strategy, based on the heuristics described above. TheGUI allows the user to view the schedule, identify conflicts(shown as red in the Gantt chart view), and see any unsatis-fied requests (indicated by a red “!” in the request list on theleft). Individual schedule items can be edited, and requests

(a)

(b)

Figure 5: Example of progressive display of detail for re-quest parameters: the parameters for “splittable” do not ap-pear (a) unless the option is selected, in which case they fadeinto view (b).

Figure 6: Example of configuring a recurrent request, herea simple weekly repetition for 8 weeks total. The previewGantt view at the bottom shows the original pattern timespan, along with that of each repeated instance. Tracks ineach repeated copy are constrained by a time linkage of 3 to6 days end-to-start in this example.

Figure 7: The schedule view showing expanded requests (the list of the left) into tracks (visible in the Gantt view)

may be locked (fixed in place) and will not be subsequentlychanged by the DSE. An example of the schedule view isshown in Figure 7.

Pathfinder DeploymentIn December 2008 we began a trial deployment to assesshow well the concepts described above would work whenexercised in a realistic scheduling context. The JPL Multi-mission Resource Scheduling Services (MRSS) team is re-sponsible for DSN scheduling for 20 different missions (outof about 35 currently being actively scheduled to use DSNresources). One team member started out using the soft-ware, and based on positive feedback, the team deployed itin February 2009 to each member. In its current usage mode,each team member develops a set of scheduling requests fortheir responsible subset of the overall set of MRSS missions.These requests are then integrated by one team member, whoprepares an integrated schedule containing all missions forwhich MRSS is responsible, for delivery to another organi-zation to add additional missions.

The MRSS team’s experience with the DSE andpathfinder GUI has been very positive — the most com-pelling endorsement is that the team does not want to con-sider falling back to the mode of operations before the soft-ware was available. A comparison of the before and afterprocess is provided in Table 3. Among the positive featuresare:

• repeated requests, and the ability to rapidly “clone” exist-ing requests and edit them to create variations

• the immediate preview capability, providing instant feed-back even for complex interval timings

• the ability to quickly create day-of-week based event in-tervals to constrain scheduling

Before(manual scheduledevelopment)

After(using request-drivenDSE)

integrated schedulecontained only the Marsmissions, Cassini, andSpitzer Space Telescope

all 20 MRSS missions areintegrated into theschedule

only DSN maintenanceand downtime and criticalactivities were consideredwhen building theintegrated schedule

same, with the addition ofany other missions forwhich requirements areavailable

schedule was developedmanually, entered viaExcel macro

schedule requests arecreated and stored, andrepeated and re-used fromweek to week

Table 3: Comparison of before and after process based onMRSS use of the DSE software

As of mid-March, the MRSS team has built and deliv-ered 14 weeks of DSN schedule using the DSE test client.The main shortcomings that have been identified center onthe simplifications noted above — there is not yet supportfor multi-user, multi-antennas scheduling scenarios, whichstill require significant manual intervention. Since the DSEpathfinder GUI does not have extensive scheduling editingcapabilities, the DSE schedule is imported into TIGRAS fora final set of interactive updates before delivery.

Future WorkThe initial experience with the DSE has been positive, con-firming most of the expectations that a combination ofan intelligent user interface, combined with user-focusedscheduling algorithms and processing, can make a request-driven approach feasible. The next steps in DSE develop-ment are to add multi-user and multi-antenna scheduling.We plan to continue to use the pathfinder GUI to exploreways to provide more efficiencies to users of the system, in-cluding additional preview functionality. Some of the futurecapabilities to incorporate include:

• “distribution” requirements, where it is important to applysome global criteria to the track expansion, for exampleto meet conditions like “during any given month, no morethan 75% of a particular mission’s tracks should be in onehemisphere”

• ways to define and manage more complex flexibilityoptions, e.g. when there are dependencies among thechoices and it is not sufficient to simply provide sets ofparameters with value ranges

• support for exploring non-local tradeoffs, e.g. when it isacceptable to reduce a track in one week, but only if itcan be restored to requested duration in a preceding orfollowing week

• providing end users with full control over what exactlyis relaxed, and in what order, when the DSE schedulingalgorithms are invoked

The DSE is a central element of the Service Scheduling Soft-ware (S3) system that is currently in development. Whencomplete, S3 will provide collaboration and reporting toolsas well as scheduling tools, via a web-base architecture thatwill make it available to all DSN users. The close collabora-tion between end users and developers has been a key factorin the progress made to date, and we expect this to continueto be critically important as the system development pro-gresses.

AcknowledgmentsThe research described in this paper was carried out at the JetPropulsion Laboratory, California Institute of Technology,under a contract with the National Aeronautics and SpaceAdministration.

ReferencesBell, C. 1992. Scheduling deep space network data trans-missions: A lagrangian relaxation approach. Technical re-port, Jet Propulsion Laboratory.Borden, C.; Wang, Y.-F.; and Fox, G. 1997. Planning andscheduling user services for NASA’s deep space network.In 1997 Int. Conf. on Planning and Scheduling for SpaceExpl.Calzolari, G.; Beck, T.; Doat, Y.; Unal, M.; Dreihahn, H.;and Niezette, M. 2008. From the EMS concept to opera-tions: First usage of automated planning and scheduling atESOC. In SpaceOps 2008.Chien, S.; Hill, R.W., J.; Govindjee, A.; Wang, X.; Estlin,T.; Griesel, M.; Lam, R.; and Fayyad, K. 1997. A hierar-chical architecture for resource allocation, plan execution,and revision for operation of a network of communicationsantennas. In Proceedings IEEE International Conferenceon Robotics and Automation.Chien, S.; Rabideau, G.; Knight, R.; Sherwood, R.; En-gelhardt, B.; Mutz, D.; Estlin, T.; Smith, B.; Fisher, F.;Barrett, T.; Stebbins, G.; and Tran, D. 2000. ASPEN - au-tomating space mission operations using automated plan-ning and scheduling. In SpaceOps 2000.Clement, B. J., and Johnston, M. D. 2005. The deep spacenetwork scheduling problem. In Innovative Applications ofArtificial Intelligence (IAAI). Pittsburgh, PA: AAAI Press.Clement, B. J.; Johnston, M. D.; Tran, D.; and Schaffer,S. R. 2008. Experience with a constraint and prefer-ence language for DSN communications scheduling. InISAIRAS-08.Fisher, F.; Chien, S.; Paal, L.; Law, E.; Golshan, N.; andStockett, M. 1998. An automated deep space communica-tions station. In Proceedings IEEE Aerospace Conference.Guillaume, A.; Lee, S.; Wang, Y.; Zheng, H.; Hovden, R.;Chau, S.; Tung, Y.; and Terrile, R. 2007. Deep space net-work scheduling using evolutionary computational meth-ods. In 2007 IEEE Aerospace Conference, 1–6.Imbriale, W. A. 2003. Large Antennas of the Deep SpaceNetwork. Wiley.Johnston, M. D., and Clement, B. J. 2005. Automatingdeep space network scheduling and conflict resolution. InISAIRAS-05.Kan, E.; Rosas, J.; and Vu, Q. 1996. Operations missionplanner - 26m user guide modified 1.0. Technical report,Jet Propulsion Laboratory.