Repository navigation
Processing Classes
Processing Classes describe different operational goals for orbit determination when timeliness, data availability, and product quality cannot all be maximized at the same time.
The objective is to make these trade-offs explicit.
This use case answers the question:
How should
spodbehave when an orbit is needed quickly, routinely, or only after the best supporting data becomes available?
Typical users include:
- satellite operators;
- flight-dynamics and POD teams;
- ground-segment integrators;
- constellation operators;
- downstream systems that depend on orbit products at different stages of the mission timeline.
These users may need different orbit products for different purposes.
For example:
- a rapidly available orbit for near-term operations;
- a routine orbit for standard processing;
- a final orbit produced later from higher-quality supporting data.
Precise orbit determination depends on supporting information that may become available at different times.
Examples may include:
- GNSS orbit and clock products;
- Earth-orientation information;
- atmospheric or environmental data;
- calibration updates;
- external reference products.
The best possible supporting data may not exist immediately.
If every workflow always waits for the highest-quality input, the result may arrive too late for operational use.
If every workflow always uses the first available data, final product quality may be unnecessarily limited.
spod should therefore make the intended processing objective explicit.
A processing class represents a set of operational expectations.
Conceptually, classes may include:
rapid
routine
final
These names are illustrative.
The important idea is not the exact terminology, but that a run explicitly states what kind of processing is intended.
Different missions may define different classes.
A processing class may balance:
availability
^
|
rapid |
|
routine |
|
final +------------> supporting-data quality
A rapid product prioritizes timeliness.
A final product can wait for better supporting information.
Neither is inherently "better" without knowing the intended use.
Rapid processing is intended for cases where availability matters strongly.
Typical objectives may include:
- support near-term spacecraft operations;
- provide an early orbit estimate;
- detect major processing or tracking problems quickly;
- make a usable product available before final supporting data exists.
A rapid class may allow:
- earlier supporting products;
- explicitly permitted fallback data;
- shorter waiting periods;
- different operational quality expectations.
The resulting orbit must still be accompanied by an explicit quality assessment.
"Rapid" should never mean "quality is unknown."
Routine processing represents the standard operational workflow for a mission.
It may balance:
- product availability;
- supporting-data quality;
- computational effort;
- repeatability;
- expected orbit quality.
For many missions, this may be the default product consumed by normal downstream operations.
The exact balance is mission-specific.
Final processing prioritizes the best supported orbit solution over immediate availability.
It may wait for:
- improved reference products;
- more complete supporting data;
- finalized mission information;
- higher-quality external products.
Final processing is particularly relevant to:
- science archives;
- long-term mission products;
- historical reprocessing;
- reference datasets;
- high-accuracy analysis.
A final product should clearly identify the processing definition and supporting data from which it was generated.
The user should be able to express the intended processing objective without manually encoding all data-selection and waiting rules.
Conceptually:
observations
+
mission
+
processing class
|
v
spod
|
+-- determine acceptable inputs
+-- apply class-specific policy
+-- execute POD
+-- evaluate quality
|
v
orbit product
+
processing-class identity
+
quality result
+
provenance
The resulting product should make clear which processing class produced it.
A processing class may influence which supporting products are acceptable.
For example:
preferred product available?
|
yes
|
v
use it
no
|
v
class permits fallback?
/ \
yes no
| |
v v
use fallback wait / fail
The exact policy is mission-specific.
The important product principle is:
Fallback behavior should be explicit rather than hidden.
A user should be able to determine whether a product was generated using preferred or fallback inputs.
Some processing objectives may allow waiting for better supporting data.
Others may require a result before a particular operational deadline.
A processing class may therefore describe concepts such as:
- whether waiting is allowed;
- what information the system is waiting for;
- when fallback becomes acceptable;
- when the request should fail rather than degrade.
This should make states such as:
WAITING_FOR_INPUT
distinguishable from:
PROCESSING
or:
FAILED
The user should not have to infer those conditions indirectly.
Different processing classes may have different operational quality expectations.
For example, a rapid orbit may be acceptable for one operational activity while insufficient as a final science product.
Conceptually:
same scientific metric
|
+--> rapid acceptance policy
|
+--> final acceptance policy
The underlying scientific evidence may be the same.
The interpretation depends on the intended product.
A spacecraft arc may produce more than one orbit over time.
For example:
observations
|
+--> rapid orbit
|
+--> routine orbit
|
+--> final orbit
These products are related, but they should remain distinguishable.
The final product should not silently overwrite the history of earlier operational products without preserving their identity and provenance.
This allows users to understand:
- which orbit was available at a particular time;
- what information was available when it was produced;
- how quality improved as better supporting data became available.
The processing class forms part of the meaning of the resulting orbit.
Relevant provenance should make it possible to identify:
- requested processing class;
- actual supporting inputs selected;
- whether fallback products were used;
- when the product was generated;
- which processing definition applied;
- resulting quality assessment.
See Provenance.
Different operational outcomes should remain explicit.
Examples include:
The desired supporting product does not yet exist.
The processing policy allows waiting for that product.
A lower-priority but acceptable product is used according to policy.
No available supporting data satisfies the processing class.
Suitable inputs were available, but the resulting orbit cannot be accepted.
These cases have very different operational meanings.
Historical reprocessing will often use processing policies that differ from real-time operations.
For example, a historical campaign may intentionally use only final-quality supporting products.
Conceptually:
operational processing -> rapid / routine
archive reprocessing -> final
Different requests within a fleet may have different urgency.
For example:
- normal routine processing for most spacecraft;
- rapid processing for a spacecraft under investigation;
- final reprocessing for historical intervals.
The fleet workflow should preserve the processing intent of each run.
See Fleet and Constellation POD.
This use case is successful when spod makes the following interaction natural:
State the operational objective for the orbit product, and let the processing workflow apply the corresponding data-availability, waiting, fallback, and quality policy explicitly and reproducibly.