1 jet propulsion laboratory california institute of technology oct 23 2008 save the bits! scheduling...

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 [email protected]

2


Oct 23 2008

Overview

• The Deep Space Network – Overview

– Users

– Assets

– Scheduling Drivers

– Process

• Automated scheduling software:

SSAS = Service Scheduling Application Software

• Conclusions

3


Oct 23 2008

The Current Deep Space Network

• Current DSN comprises

– 3 sites roughly equally spacedin 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


Oct 23 2008

Goldstone

5


Oct 23 2008

DSN Scheduling Process

SU (science users oly) write agree-ments with SP

(DSA)

SU generate detailed require-ments & perform unilateral conflict

resolution

SU negotiate multi-laterally for

tracking resources, with SP for support level, and to develop contingencies

SP generates predicts

(just in time)

Escalate conflict

Conflict-freeschedule?

Setup

Teardown

Track

SP define & update operations & capabilities rules

SU define and input mission requirements

SU Generate Events and

Ephemerides Files

SPS and/or SU generate

viewperiods

Yes

No

SU, SP, & SSL negotiate down-time and produce

loading/impact assessments

7

3

4

56

2

1

9

10

12 13

14

- Step is repeated often later in the process

@ -4 weeks, SP generates staffing

plans11

DMR - DSN Mission RequirementsDSA - DSN Service AgreementSC - Service coordinator(s)SP - Service provider(s)SPS - Service Preparation SubsystemSSL - Special Studies LeadSU - Service user(s)

Acronyms

6


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


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


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/LD/L

D/L U/L

D/LMEXMRO

viewperiod

track

9


Oct 23 2008

SSAS: Service Scheduling Application S/W

Requirements-Driven vs. Activity-Oriented Scheduling

users

• create• edit

scheduled activities

• conflicts• reports• displays

ACTIVITY-ORIENTED SCHEDULING


users

• create• edit



ACTIVITY-ORIENTED SCHEDULING

Why consider requirements-driven scheduling?•efficiency: one requirement can generate many activities

major labor savings •enables automated support for conflict resolution


scheduling requirements &

constraints


constraints

users

• create• edit



• create• edit

• check/validate

• expand

• resolve conflicts• improve quality

• override

• reqts violations• find opportunities

REQUIREMENTS-DRIVEN SCHEDULING



constraints


constraints

users



• create• edit

• check/validate

• expand


• override



role of scheduling engine

• create• edit



constraints


constraints

users

• create• edit

scheduled activities in multiple private workspaces


• create• edit

• check/validate

• expand


• override



role of scheduling engine

Scheduling Engine Functionality CategoriesCategory Description

Conflict Check Check schedule for conflicts per DSN standards (down to equipment instances)

Requirement – error check Check requirement for consistency, completeness, correctness, feasibility

Requirement – satisfaction check Check 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 inquiry Answer query about (a) the state of the schedule or, (b) additionally, about potential ways to satisfy a specified requirement

Resolve conflicts — automatic Given a schedule with conflicts and filters (time/mission/assets, etc.), use requirement flexibility to find a way to remove conflict(s)

Resolve conflicts — generate options same input, but generate multiple different suggestions and return them to the user

Improve schedule quality same, but focused on improving schedule quality, not conflicts: reduce gaps, adjust tracks to preferred timing & assets, etc.

16


Oct 23 2008

Collaborative Conflict Resolution with Private Workspaces

R1R1

R2R2

R3R3

expanded requirements

unexpanded requirements

scheduletracksreference to parentschedule

• 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

Scenario:• Conflict exists in master

schedule• two users: U0, U1 x conflict

? requirements violation

T1T1

T0T0

U1 – R1U1 – R1

U0 – R0U0 – R0

master schedule

x

x

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


U1 – R1U1 – R1

U0 – R0U0 – R0

master schedule

T1T1

T0T0x

x

T1’T1’

T0’T0’x

x

child (private

workspace) schedule

• U0 makes changes to resolve the conflicts, here moving both conflicting tracks x conflict


U1 – R1U1 – R1

U0 – R0U0 – R0

master schedule

T1T1

T0T0x

x

T1’T1’T0’T0’

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


U1 – R1U1 – R1

U0 – R0U0 – R0

master schedule

T1T1

T0T0x

x

T1’T1’T0’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

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


U1 – R1U1 – R1

U0 – R0U0 – R0

master schedule

T1T1T0T0

T1’T1’T0’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


Oct 23 2008

Scheduling Requirements and Constraints

24


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


Oct 23 2008

27


Oct 23 2008

Repeated requests and events

• Repeated requirementsupport, e.g. repeat4 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


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 startingpoint, there remains work to do on more sophisticated conflict/violation resolution techniques

29


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


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


Oct 23 2008

1 jet propulsion laboratory california institute of technology oct 23 2008 save the bits! scheduling...

Documents