# Presentation: 305874

## SSAS Scheduling Engine (SE) Requirements OverviewB. Clement & M. Johnston

## Design Overview

- Outline:
- SE Components
- Messaging API
- Request / requirement language
- ASPEN
- Search

## 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

## Messages

| Request | Response |
| --- | --- |
| initiateSessionRequest | initiateSessionResponse |
| statusRequest | statusResponse |
| terminateProcessingRequest |  |
| generateScheduleRequest | generateScheduleResponse |
| applyScheduleChangesRequest | applyScheduleChangesResponse |
| identifyConflictsRequest | identifyConflictsResponse |
| resolveConflictsRequest | resolveConflictsResponse |
| terminateSessionRequest |  |
| undoToStepRequest | undoToStepResponse |

## 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?

## 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**

**individualTrackDuration**

**absoluteTime.min**

## Single Activity Requirement Model

## Periodic Requirement

**Periodic Requirement**

- < all parameters of Single Activity >
- period
- tracksPerPeriod
- trackWindow
- No tracks created for a period where the trackWindow is not fully contained.

**period**

**trackWindow**

**absoluteTime.min**

**absoluteTime.max**

## Periodic Requirement Model

## Continuous Requirement

- < all parameters of Single Activity >
- totalTrackDuration
- trackOverlap

**trackOverlap**

**dur1**

**dur2**

**dur3**

- totalTrackDuration = dur1 + dur2 + dur3

**totalTrackDuration**

**setup**

**teardown**

**trackOverlap**

**absoluteTime**

## Continuous Requirement Model

## Segmented Requirement

- < all parameters of Single Activity >
- totalTrackDuration (min, max, preferred)
- trackGap (min, max, preferred)
- gapToTrackRatio (min, max, preferred)
- dataRate (min, max, preferred)
- dataSize (min, max, preferred)

- not exposed

**min gap**

**max gap**

- a

- b

- c

**absoluteTime**

**max gap**

**setup**

**teardown**

## Segmented Requirement Model

## 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”

## 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*

## 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)

## 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

- CLU1

- CLU2

- STEREOA	 B

## 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

## 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

## 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

## ASPEN

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

## 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

## ASPEN Modeling

- Aspen is customized to different projects by selecting different mixes of built-in heuristics and the light addition of C++ code
- ASPEN’s 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

## 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,

## Search to Satisfy Dynamic Events

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

## 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