1 / 20

Multi-Objective Scheduling for NASA’s Future Deep Space Network Array

Multi-Objective Scheduling for NASA’s Future Deep Space Network Array. Mark D. Johnston Jet Propulsion Laboratory — California Institute of Technology 4800 Oak Grove Dr., Pasadena CA 91109 mark.d.johnston@jpl.nasa.gov. Overview. The evolution of the NASA Deep Space Network

bobby
Download Presentation

Multi-Objective Scheduling for NASA’s Future Deep Space Network Array

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Multi-Objective Scheduling for NASA’s Future Deep Space Network Array Mark D. Johnston Jet Propulsion Laboratory — California Institute of Technology4800 Oak Grove Dr., Pasadena CA 91109mark.d.johnston@jpl.nasa.gov

  2. Overview • The evolution of the NASA Deep Space Network • The scheduling problem • how scheduling the array differs from scheduling individual antennas • perspectives, objectives, and constraints • Multi-objective optimization • A multi-objective optimization formulation of the array scheduling problem • Results • competing missions example • a representative 2015 mission set • scalability • Conclusions

  3. The Current Deep Space Network • Current DSN comprises • 3 sites roughly equally spacedin longitude • 26m, 34m, 70m antennas,same at each site • DSN supports all planetary missions + some earth orbiters • Drivers on evolution include: • more missions (3x by 2030) • data rates and volumes increasing by 100x by 2030 • manned missions place stringent availability and reliability requirements • more cluster (multi-spacecraft) missions • reduce costs (operations and maintenance) • maintain high level of 24x7 support

  4. Deep Space Array-Based Network • An array-based network links together large numbers of less expensive antennas • possibly at 3 balanced sites like today’s DSN, but possibly unbalanced • some designs call for ~400 antennas/site • Array-based network offers advantages • allocation of antennas can be more granular • subsets of the array can be allocated to simultaneous communications with different spacecraft • antenna allocation can be time-phased within a single pass • unused antennas could be allocated on-the-fly in case of equipment failure or spacecraft emergency An array-based network will be much more flexible, but will require an approach to planning and scheduling that can take advantage of this flexibility

  5. Challenges An array-based network presents some challenges not present in today’s DSN: • Shift to higher frequency (especially Ka band) makes communications sensitive to the weather • signal is attenuated in bad weather much more than for X and S bands • There are some array-specific constraints • a sufficient number of signal combiners must be available to support the scheduled simultaneous users • there may be limitations on which subsets can be used for a contact based on physical layout of the array • The array will not suddenly replace the current DSN, but will likely be an evolutionary development over many years and multiple sites

  6. Scheduling Context DSN array scheduler • From multiple users: • mission status, capabilities & requirements • new service requests • changed service requests • site schedules • site status (availability, maintenance, performance) • weather • execution feedback

  7. User Requirements • User requirements drive the scheduling of the DSN • missions place a variety of constraints and preferences into their requirements for communications support • data downlinks • command uplinks • navigation and control • critical events • s/c emergencies • other user categories include • radio science • radio astronomy

  8. Objectives from a Mission Perspective • Mission objectives can be categorized based on how they relate to the schedule: • pass-based objectives are defined in terms of specific allocations of antennas to missions over some time interval, called a “pass” • e.g. 25 antennas at Goldstone dedicated to Mars Phoenix for 6 hours would be a single pass • objectives may be defined with respect to attributes of the pass, including duration, timing relative to absolute time or to other passes, etc. • service-based objectives are defined at a higher level and refer to missions needs in terms of how well a service requirement is satisfied • e.g. a mission may specify that it needs an 8h downlink at a certain data rate every 3 days over some mission phase • model-based objectives are even higher level and require the scheduler to model some aspects of mission behavior to asses • e.g. need to download data often enough to keep onboard storage from capacity limit

  9. Objective Description contact duration min and max limits on duration, where a contact is the union of the coverage intervals of overlapping passes contact gap duration min and max limits on the sizes of any gaps between contacts pass duration min and max limits on individual pass duration gap duration min and max limits on the sizes of any gaps between individual passes coverage fraction fraction of some specified time interval with scheduled contact coverage (e.g. “1” means continuous coverage) coverage level number of distinct passes simultaneously providing coverage (e.g. “2” would mean simultaneous coverage at two different sites) total gap duration total gap in coverage over a specified interval pass time shift how much a pass has shifted in time from some baseline requested time objective out of limit extent to which an objective value exceeds a specified limit Objectives • A sample of mission service-based objectives:

  10. Objectives from a System Perspective • To some approximation, we can collect the non-mission objectives into a single “system” user, representing the overall operations of the DSAN: • satisfy the users of the system • captured in users own objectives • minimize operational costs • this is largely a function of the system configuration, operations, and maintenance policies, and not likely to be affected much by schedule variations • maximize system availability • this is a core system objective — maximize the number of users serviced by a given investment in assets and infrastructure • counterintuitively, maximize the number of unallocated antennas

  11. Constraints • Constraints are factors that must be satisfied in order for the schedule to be feasible • Examples: • visibility constraints • resource limitations (total number of antennas over time) • mission-originated constraints (e.g. must have contact around course correction maneuver) • Some constraints may be formulated as quantitative measures on a schedule that represent degree of violation, and thus be treated like objectives • this is particularly useful when no feasible schedule exists, and constraint relaxation must be considered • in this context, the ability to exchange constraints and objectives is a useful feature to incorporate

  12. Multi-Objective Optimization • Approach: multiobjective optimization • keep objectives separate and combine only when necessary • do not lose information that separate objectives contain • allows an explicit view into the tradeoffs when building and changing the schedule • define a very general approach to specifying objectives and constraints • penalty function f() applied to schedule as viewed from the user’s perspective • can switch constraints  objectives to investigate overconstrained situations • use multiobjective optimization techniques based on evolutionary algorithms • maintain a population of candidate schedules that evolves to optimize M>1 objectives • population provides an estimate of the Pareto frontier (tradeoff surface) • population provides a starting point for schedule changes • easy to distribute for processing in parallel • enables user visibility into schedule tradeoffs, thus supporting collaborative schedule development, repair, and negotiation

  13. Evolutionary Algorithms • Formulated as a minimization problem for M objectives subject to K constraints • Population of N solution candidates • With each step (generation), generate a new population following rules for crossover (combining parents to make offspring) and mutation (introducing random variations into offspring) • Considered two algorithm families: • NSGA II (Deb et al. 2002) elitist method, pioneered • non-dominated sorting • crowding distance • GDE3 (Kukkonen and Lampinen 2005) extended NSGA II by using differential evolution (DE) to generate offspring

  14. GDE3 GDE3 is based on differential evolution for single-objective optimization (Price, Storn and Lampinen 2005) 1. For each parent, select three distinct population members, all different and different from parent 2. Calculate a trial vector as: where F is a scaling factor 3. Modify the trial vector by binary crossover with parent with probability CR Compare offspring with parent as follows • both infeasible: choose less violated in constraint violation space • one feasible, other infeasible: choose feasible • both feasible: choose dominating if present, else choose both Then, if necessary, reduce population back to size N via non-dominated sorting and crowding distance (to improve diversity along Pareto frontier)

  15. max min # ant.req. # ant.req. time time (x1, x2, x3) DSAN Schedule Model • Time is quantized to arbitrary buckets • Boundary conditions allow for contacts outside scheduling interval • needed to compute objectives/constraints that depend on contacts external to schedule • Background of fixed contacts is supported • could be higher priority allocations • could be a frozen part of the schedule when rescheduling • Decision variables based on user/viewperiod:

  16. constraint viol. dominated non-dominated (Pareto frontier) Simple Example • Two (identical) users, 4 day schedule, 10 antenna “array”, but only 5 available on 2nd day (“maintenance”) • Each user requires 5 antennas per contact, prefers 12hr contacts and gaps <18hr, requires at least 3hr contacts; there is one 12hr viewperiod/day • Initial population randomized (diversity helps search, especially in more complex situations) user 1 user 2 200 generations2 sec runtime(10K schedules/sec) user 2 penalty  user 2 penalty  user 1 penalty  user 1 penalty 

  17. Simple Example — movie

  18. 2015 Mission Set • More extensive experiments were conducted on a model representative of a 2015 mission set: • 17 missions requiring from 1 to 94 antennas for each pass • periodic pass requirements over a range of time intervals (every 8 hours to once/week), with pass durations ranging up to 12 hours • 3 sites, each with 100 antennas, equally spaced in longitude • one week scheduling interval (760 decision variables) • Model was used to explore: • algorithm convergence and performance • scalability with population size • scalability with schedule time resolution

  19. 2015 Mission Set – cont. • Results are very encouraging: • Initial experiments comparing NSGA and GDE3 showed the latter to be superior • GDE3 does a good job of finding a feasible population then optimizing and filling out the Pareto surface • scalability with population size N is proportional to N log N • scalability with time resolution is linear

  20. Conclusions and Future Work • Strengths of multi-objective formulation: • explicit and separate representation of each mission’s objectives, making it easy to consider tradeoffs • a population of solutions approximating the Pareto frontier, useful in scheduling selection and as a starting point when revising the schedule • Results to date are encouraging in terms of convergence to Pareto frontier, scalability, and diversity of coverage • Plans for future work include: • modifying an existing schedule quickly and effectively e.g. to respond to changed scheduling requirements or s/c emergencies • incorporating risk mitigation into the schedule, e.g. to optimally allocate unused antennas as a hedge against bad weather • parallelizing the implementation to take advantage of grid or other distributed computing resources

More Related