Scheduling Best Practices

⚠️

Proceed with caution!

Any changes to the Facts and Best Practices described in this document will not be considered breaking API changes. The information here can and will change as Umbra seeks to improve aspects of our feasibility and scheduling services. Please be defensive when developing integrations using the information in this document.

If you see system behavior that appears to contradict any of the information presented here, please reach out to us at [email protected]

This document describes a series of Umbra "Best Practices" for submitting Task and Feasibility requests that give our users the best chance to have their requests accepted by the scheduling system. The document is split into two sections:

1. Facts: Descriptions of behaviors of the Umbra Scheduler
2. Best Practices: Suggestions based on experience for how to optimize results based on the Facts of the Umbra Scheduler

Facts

The Umbra Scheduler will begin attempting to schedule submitted Tasks once they are within 96 hours of collection time. Until then, submitted Tasks will remain in ACCEPTED.

The Umbra Scheduler attempts to schedule Tasks in batches every 10 minutes, scheduling new Tasks within the 96 hour collection window first. Each batch is limited to 50 Tasks. Any extra Tasks will be pushed to the next batch.

There is no scheduling prioritization of specific Tasks within any given batch. The Scheduler will bias towards attempting to schedule the earliest feasible Tasks. For example, if two Tasks are on the same pass but one becomes feasible 10 seconds prior to the other one, the Scheduler will first schedule the earlier one.

The Scheduler biases to collecting a given Task at the soonest possible time within a given tasking window. Practically speaking this tends to result in squinted Collects since the earliest possible time within a given time window tends to be when the satellite is squinting forward along its velocity vector.

The Scheduler will sometimes make small (a few seconds) adjustments to Collect start and end times if the parent Task window allows. These occurrences are relatively rare. If the Collect is moved to a different Satellite that is able to satisfy the constraints of the requested Task, the existing Collect will be marked SUPERSEDED and a new Collect will replace it.

There is imprecision in the ability of the Umbra Scheduler to accurately predict the location of the spacecraft across the entire 7 day schedule. As Umbra updates its TLE across the 7 day schedule, Tasks that were previously ACCEPTED or SCHEDULED will sometimes later be REJECTED. Often times, these tasks are still feasible for that same pass and can be re-tasked with a slightly different (within a few minutes) time window (i.e. time is adjusted from 7:01 - 7:03 to 7:03 - 7:05). The Umbra Scheduler is not flexible enough to accommodate these small adjustments in time, but the tasks can often be manually re-tasked in Canopy. It is a high priority of Umbra’s to provide a solution with more precision and flexibility for this process.

Best Practices

Generally speaking, attempt to submit Tasks closer to the desired collection time as much as your workflow allows. It is generally safe to submit Tasks up to three hours before the desired collection time. If Tasks are submitted many days in the future, ACCEPTED and SCHEDULED Tasks may transition to REJECTED due to imprecision in the schedule making them no longer feasible.

If trying to submit a group of tasks that are densely spaced:

• If you DO care about which particular Tasks are scheduled:
  • Submit the one that occurs earliest (aka, the target that will be first to enter the axe blade on a given pass), wait for it to proceed to “SCHEDULED”, and then proceed to the next one to enter the axe blade. Continue until all tasks are SCHEDULED or until feasibility will not allow you to schedule any additional tasks.
• If you do NOT care about which particular tasks are scheduled:
  • Submit them all in a batch so that the Scheduler considers them all together. The Scheduler will maximize for total number of tasks.

Where possible, aim to only submit targets on one side of the ground track for a given pass. The Scheduler will optimize for the soonest possible collection. In situations where you have targets on either side of the ground track, this can cause sub-optimal total throughput if the soonest possible collection is on the opposite side of the ground track from the majority of your targets.