1. 1 Jet Propulsion Laboratory California Institute of Technology Oct 23 2008 Save the Bits! Scheduling NASA’s Deep Space Network Mark D. Johnston Jet Propulsion Laboratory — California Institute of Technology 4800 Oak Grove Dr., Pasadena CA 91109 mark.d.johnston@jpl.nasa.gov

2. 2 Jet Propulsion Laboratory California Institute of Technology Oct 23 2008 Overview The Deep Space Network – Overview –Users –Assets –Scheduling Drivers –Process Automated scheduling software: SSAS = Service Scheduling Application Software Conclusions

3. 3 Jet Propulsion Laboratory California Institute of Technology Oct 23 2008 The Current Deep Space Network Current DSN comprises –3 sites roughly equally spaced in longitude –26m, 34m, 70m antennas, 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. 4 Jet Propulsion Laboratory California Institute of Technology Oct 23 2008 Goldstone

5. 5 Jet Propulsion Laboratory California Institute of Technology Oct 23 2008 DSN Scheduling Process

6. 6 Jet Propulsion Laboratory California Institute of Technology Oct 23 2008 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 critical events s/c emergencies –other user categories include radio science radio astronomy

7. 7 Jet Propulsion Laboratory California Institute of Technology Oct 23 2008 Tracks, Viewperiods & Activities A track is an allocation of an antenna to a mission over some time interval A viewperiod is the time interval when a spacecraft is visible to an antenna An activity is a track plus setup and teardown time

8. 8 Jet Propulsion Laboratory California Institute of Technology Oct 23 2008 Constraints No two spacecraft can use antenna at same time –except MSPA where antenna points to both (2 at most) and uplinks to at most one Spacecraft must be in view of antenna –generally, centered is better At Goldstone, no track/activity may be scheduled where two other tracks/activities start within 15 minutes –except the four Cluster s/c At other complexes, no two may start within 5 minutes of each other U/L D/L U/L D/L MEX MRO viewperiod track

9. 9 Jet Propulsion Laboratory California Institute of Technology Oct 23 2008 SSAS: Service Scheduling Application S/W

10. Requirements-Driven vs. Activity-Oriented Scheduling users create edit scheduled activities conflicts reports displays ACTIVITY-ORIENTED SCHEDULING

11. Requirements-Driven vs. Activity-Oriented Scheduling users create edit scheduled activities conflicts reports displays ACTIVITY-ORIENTED SCHEDULING Why consider requirements-driven scheduling? efficiency: one requirement can generate many activities  major labor savings enables automated support for conflict resolution

12. Requirements-Driven vs. Activity-Oriented Scheduling scheduling requirements & constraints users create edit scheduled activities conflicts reports displays create edit check/validate expand resolve conflicts improve quality override reqts violations find opportunities REQUIREMENTS-DRIVEN SCHEDULING

13. Requirements-Driven vs. Activity-Oriented Scheduling scheduling requirements & constraints users scheduled activities conflicts reports displays create edit check/validate expand resolve conflicts improve quality override reqts violations find opportunities REQUIREMENTS-DRIVEN SCHEDULING role of scheduling engine create edit

14. Requirements-Driven vs. Activity-Oriented Scheduling scheduling requirements & constraints users create edit scheduled activities in multiple private workspaces conflicts reports displays create edit check/validate expand resolve conflicts improve quality override reqts violations find opportunities REQUIREMENTS-DRIVEN SCHEDULING role of scheduling engine

15. Scheduling Engine Functionality Categories CategoryDescription Conflict CheckCheck schedule for conflicts per DSN standards (down to equipment instances) Requirement – error checkCheck requirement for consistency, completeness, correctness, feasibility Requirement – satisfaction checkCheck requirement vs tracks to see if satisfied (also identify unexpanded requirements) Requirement – expand (single)Expand one requirement into tracks on a schedule, try to avoid conflicts, respect locked tracks, respect mission priorities Requirement – expand (multiple)Expand >1 requirement into tracks on a schedule (same conditions as above) Schedule inquiryAnswer query about (a) the state of the schedule or, (b) additionally, about potential ways to satisfy a specified requirement Resolve conflicts — automaticGiven a schedule with conflicts and filters (time/mission/assets, etc.), use requirement flexibility to find a way to remove conflict(s) Resolve conflicts — generate optionssame input, but generate multiple different suggestions and return them to the user Improve schedule qualitysame, but focused on improving schedule quality, not conflicts: reduce gaps, adjust tracks to preferred timing & assets, etc.

16. 16 Jet Propulsion Laboratory California Institute of Technology Oct 23 2008 Collaborative Conflict Resolution with Private Workspaces

17. R1 R2 R3 expanded requirements unexpanded requirements scheduletracks reference to parent schedule Schedule – master or workspace schedule a workspace schedule has a time bound and a parent schedule from which it originated Track or activity– associated with a single schedule, but possibly multiple requirements Requirement – associated with multiple tracks, and possibly multiple schedules can be in expanded or unexpanded states

18. Scenario: Conflict exists in master schedule two users: U0, U1 x conflict ? requirements violation T1 T0 U1 – R1 U0 – R0 master schedule x x

19. child (private workspace) schedule U0 creates a private workspace to work the conflict activities are copied but (in this case) requirements are not) x conflict ? requirements violation U1 – R1 U0 – R0 master schedule T1 T0 x x T1’ T0’ x x

20. child (private workspace) schedule U0 makes changes to resolve the conflicts, here moving both conflicting tracks x conflict ? requirements violation U1 – R1 U0 – R0 master schedule T1 T0 x x T1’ T0’

21. child (private workspace) schedule U0 invites U1 to review and approve the changes U0 can give U1 write access to the schedule, to make a counter proposal U0 and U1 can view the workspace simultaneously while on audio/video chat to discuss resolution: changes made by one are visible to the other U1 could create their own workspace schedule to explore additional alternatives, and invite U0 to participate U0 or U1’s changes could introduce requirement violations, which either could resolve or choose to ignore x conflict ? requirements violation U1 – R1 U0 – R0 master schedule T1 T0 x x T1’ T0’ Proposal: here is a suggestion for the DOY 145 conflict… Concur:  U0 ☐ U1 Proposal: here is a suggestion for the DOY 145 conflict… Concur:  U0 ☐ U1

22. child (private workspace) schedule Once concurrence is reached, the private schedule can be merged back into the parent to resolve the conflict by either U0 or U1 since both have concurred If a change to a U1-owned track is made after U1 concurrence but before merging, SSAS knows to clear the concurrence flag and re-request x conflict ? requirements violation U1 – R1 U0 – R0 master schedule T1 T0 T1’ T0’ Proposal: here is a suggestion for the DOY 145 conflict… Concur:  U0  U1 Proposal: here is a suggestion for the DOY 145 conflict… Concur:  U0  U1 merge

23. 23 Jet Propulsion Laboratory California Institute of Technology Oct 23 2008 Scheduling Requirements and Constraints

24. 24 Jet Propulsion Laboratory California Institute of Technology Oct 23 2008 Requirements and Constraint Language Instead of “atomic” detailed requirements, define a “request” as a pattern of items or “requirements” Adopt familiar “recurrent appointment” metaphor for specifying repetitions while allowing individual exceptions Identify ways to hide detail unless needed, yet still support complexity when truly required Utilize service configurations/aliases to specify antenna equipment choices/preferences

26. 26 Jet Propulsion Laboratory California Institute of Technology Oct 23 2008

27. 27 Jet Propulsion Laboratory California Institute of Technology Oct 23 2008 Repeated requests and events Repeated requirement support, e.g. repeat 4 more times every other week Complex event support: –arbitrary interval intersection, optionally inverted –expand or contract windows, then used to constrain where tracks may be allocated –convert viewperiods into constraining event windows

28. 28 Jet Propulsion Laboratory California Institute of Technology Oct 23 2008 Resolving Conflicts/Violations The engine considers as distinct conflicts (on tracks) vs. violations (of requirements) –there are basic strategies for focusing on each of these and trying to re-layout requirements to resolve conflicts, fix unsatisfied requirements –these strategies exploit flexibilities in the requirements (start time duration, antennas, splitting, gaps, overlaps...) to find good allocations –although a good starting point, there remains work to do on more sophisticated conflict/violation resolution techniques

29. 29 Jet Propulsion Laboratory California Institute of Technology Oct 23 2008 Expanding Requirements The engine expands requirements to tracks as follows: –try to find conflict- & violation-free allocations –if can’t find any, try a series of “fallbacks”: temporarily ignore lower priority tracks, equal priority tracks, all other tracks relax requirement parameters: timing relationships, gap/overlap parameters, event windows,... ultimately considering only viewperiods Goal: always try to return something “reasonable” rather than nothing at all (sometimes this can be very hard!)

30. 30 Jet Propulsion Laboratory California Institute of Technology Oct 23 2008 Performance Conducted scaling performance test on 6-month schedules with excellent results: roughly linear time and memory usage –~10s/week for schedule generation, ~15Mb week memory consumption –scaling for a full DSN schedule size appears reasonable –no performance optimization has been conducted to date

31. 31 Jet Propulsion Laboratory California Institute of Technology Oct 23 2008