SSAS Scheduling Engine (SE) Requirements Overview B. Clement

1
SSAS Scheduling Engine (SE) Requirements
OverviewB. Clement M. Johnston
2
Design Overview

• Outline
• SE Components
• Messaging API
• Request / requirement language
• ASPEN
• Search

3
Messaging API

• SE is designed around a messaging API
• JMS standard, vendor neutral
• asynchronous
• XML messages, schema for validation
• conforms to DSMS messaging guidelines
• Session-oriented service model
• user initiates one or more sessions for all
  interactions
• resources freed when session terminates

4
Messages
Request Response
initiateSessionRequest initiateSessionResponse
statusRequest statusResponse
terminateProcessingRequest
generateScheduleRequest generateScheduleResponse
applyScheduleChangesRequest applyScheduleChangesResponse
identifyConflictsRequest identifyConflictsResponse
resolveConflictsRequest resolveConflictsResponse
terminateSessionRequest
undoToStepRequest undoToStepResponse
5
Requirements Language

• Borrowed heavily from a MADB requirement web form
• Repeated tracks
• Gap constraints
• Continuous / segmented
• Arraying / VLBI / delta DOR
• Added some others
• MSPA
• Override / block-out
• Total time, data volume,datarate, gap-to-track
  ratio
• event constraints event-relative requirements
• Scoping of scheduling requests to specific
• time periods
• assets
• missions
• constraints
• SQL and ASPEN as backup language extensions for
• changing administrative controlled inter-mission
  constraints
• telecom configuration constraints (automating
  service requests)
• User interface rules?

6
Single Activity Requirement

• individualTrackDuration (min, max, preferred)
• absoluteTime (min, max, preferred)
• assets (e.g. 34BWG, 70m and 70m, DSS-14 or DSS-63
  or DSS-65)
• missionID
• setup
• teardown
• MSPA allow or not
• services
• configurationCode
• workCategory
• activityDescription
• quantization

absoluteTime.max
absoluteTime.min
individualTrackDuration
7
Single Activity Requirement Model
8
Periodic Requirement

• lt all parameters of Single Activity gt
• period
• tracksPerPeriod
• trackWindow

absoluteTime.max
period
absoluteTime.min
trackWindow
9
Periodic Requirement Model
10
Continuous Requirement

• lt all parameters of Single Activity gt
• totalTrackDuration
• trackOverlap

totalTrackDuration
trackOverlap
dur1
trackOverlap
dur2
setup
dur3
teardown
absoluteTime
totalTrackDuration dur1 dur2 dur3
11
Continuous Requirement Model
12
Segmented Requirement

• lt all parameters of Single Activity gt
• totalTrackDuration (min, max, preferred)
• trackGap (min, max, preferred)
• gapToTrackRatio (min, max, preferred)
• dataRate (min, max, preferred)
• dataSize (min, max, preferred)

not exposed
max gap
max gap
min gap
a
b
c
setup
teardown
absoluteTime
13
Segmented Requirement Model
14
User-specified events

• DSE API
• allows events, intervals, and sets of intervals
  to be specified
• embedded in the message (like viewperiods)
• will need to query from the SSAS DB (like
  viewperiods)
• Comments
• sets of intervals are needed for repeated
  intervals that the engine must avoid or schedule
  within
• an additional interface element permits
  references to intervals from within requirements
  (see below)
• compatible with SSAS requirement for handling
  user events

15
References to viewperiods and events

• Issue some missions have timing requirements
  that need to combine viewperiod and event info
• API implementation
• allow timing requirement to refer to multiple
  event specs viewperiod
• the event intervals can be specified as to avoid
  or to schedule within or to center

16
continued .. MEX example

• MEX has to avoid NNO visibility, so would
  specify
• a user-defined interval list of NNO rise-to-set
  times with the required 5min pad
• timing requirements to avoid the NNO rise-to-set
  intervals (while scheduling within the MEX
  viewperiods on DSN antennas)

17
Requirements and tracks as events

• Provided capability for an unforeseen need to
  schedule DSN requirements involving timing
  constraints among activities of multiple
  spacecraft
• e.g., Cluster 1 and 2 must have simultaneous
  tracks
• e.g., STEREO A and B must be back-to-back
• Now able to refer to a requirement or tracks of a
  requirement similar to events.
• MSPA U/L and D/L specified in separate
  requirements

STEREOA B
CLU1
CLU2
18
Alternative timing requirements

• Users wish to specify alternative requirements
  like either 4h track on 70m or 8h track on
  34HEF and the like
• API implementation
• allow requirements to be grouped as choices,
  meaning exactly one of the group is required
• maybe used to implement alternative
  equipment/config codes

19
Track freezing

• allow tracks to be frozen in the API
• implementation
• this is not a scheduling requirement issue, but
  rather with the schedule itself
• API allows additional fields on tracks in the
  schedule (SSAS GUI to support these)
• 1) lock down engine should not move this track
• 2) why locked (drop down for common choices, and
  additional user custom reason)
• 3) flag to tell engine to ignore requirement
  conflicts (only) that involve this track all
  other conflicts will be treated normally
• note the engine will use these flags, but never
  change them they come from the SSAS database

20
Algorithm Design

• Local search in Aspen
• scales to large problems
• short memory of what it has tried before
• captures all DSN and requirement constraints
• Systematic search
• effective on smaller subproblems
• exhaustively searches options
• captures all DSN constraints but few requirement
  constraints
• extending to requirement constraints could prove
  very effective

21
ASPEN

• Aspen is a local search, heuristic iterative
  repair planner/scheduler

22
ASPEN (cont.)

• For the SE, our approach incorporates a hybrid
  approach of heuristic repair along with
  systematic search
• over limited problems, systematic search can be
  both fast and complete
• experiments have confirmed this expectation

23
ASPEN Modeling

• Aspen is customized to different projects by
  selecting different mixes of built-in heuristics
  and the light addition of C code
• ASPENs modeling language is use to capture
  common request parameters and constraints
• antennas choices and availability
• viewperiods, temporal relationships, gaps,
  periodicities
• resources (consumable and non-consumable)
• timeline states
• For maximum flexibility, constraints can also be
  specified as SQL queries against the ASPEN data
  model
• query only needs to identify that a constraint is
  violated, and which activities participate
• customized heuristics could additionally be added
  to help guide repair

24
Search

• possible rescheduling are scored by common
  criteria
• whether all of the other constraint rules (those
  of the DSN, not defined by the requirement) are
  met,
• how well they can satisfy dynamic event
  constraints (which we will explain later), and
• the closeness of values of the state to their
  corresponding preferred values.
• and by type-specific criteria
• whether all of the other constraint rules (those
  of the DSN, not defined by the requirement) are
  met,

25
Search to Satisfy Dynamic Events

• Dynamic event - event referring to a tracks
  that DSE may move
• For static event constraints, intervals are just
  intersected with computed valid intervals for
  track (based on free assets, etc.)
• Cant do with dynamic events because constraining
  track (A) needs to consider possible places the
  constrained track (B) could move to satisfy its
  constraint.

26
Strategy Element

• strategy XML element for user guidance of
  scheduling engine
• sub-elements
• random schedule generated tracks randomly
  within requirement and viewperiod constraints
  (default is a more careful generation)
• extendDurations increase durations of all
  unlocked tracks as much as possible without
  creating conflicts
• globallyLock/Unlock
• convenience for freezing entire schedule
• currently used to accurately evaluate conflicts
  by keeping tracks from being rescheduled