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 schedule submitted Tasks in batches every 10 minutes. Until then, submitted Tasks will remain in ACCEPTED.

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. This generally occurs once a day on each satellite when state vectors are updated (see below). 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.

Feasibility Availability and State Vectors

The duration for which feasibilities are available varies for each spacecraft in the constellation due to how state vectors are updated. Here's how it works for each spacecraft:

After each communication pass, telemetry data is collected and used to create new state vectors, predicting the spacecraft's position up to 8 days (192 hours) in the future.

At 12:00 UTC daily, the updated state vectors are loaded into the scheduling system, providing the most accurate information.

The availability of state vector information varies based on the timing of the last communication pass. For instance, if a pass occurred just before 12:00 UTC, the system has data for close to 8 days (192 hours) in the future. This availability decreases as time passes since the last pass; after 2 hours, it drops to 190 hours.

The least state vector information is available just before 12:00 UTC, with at most 7 days (168 hours) of data, decreasing according to the last communication pass.

Because state vector updates are specific to each spacecraft, the end times for scheduling may differ between spacecrafts. For example, one spacecraft may allow scheduling 190 hours into the future, while another may only support scheduling up to 188 hours ahead.

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.