Repository navigation
Users and Roles
spod is intended for teams that need precise, repeatable, and auditable orbit-determination workflows as part of spacecraft operations or mission data processing.
Different users interact with the product in different ways. Some care primarily about orbit quality, others about integration, automation, repeatability, or fleet-scale operation.
The personas below describe the main users spod is designed to support.
A satellite operator needs reliable orbit products as part of routine spacecraft operations.
Typical concerns include:
- whether the latest orbit solution is available;
- whether its quality is acceptable;
- whether required observations and supporting data were complete;
- whether the processing run succeeded;
- whether any warnings require operational attention;
- whether the result can be reproduced later.
The operator should not need to understand the internal numerical implementation of the POD system.
From their perspective, spod should behave like an operational processing system:
tracking data
|
v
processing
|
v
orbit product
+
quality status
+
provenance
Relevant use cases:
A flight-dynamics or POD engineer is responsible for the scientific and operational quality of orbit solutions.
This user cares about more detail than the general operator.
Typical concerns include:
- which observations were used;
- which supporting products were selected;
- which force and measurement models apply;
- estimation convergence;
- residual behavior;
- covariance and uncertainty;
- rejected observations;
- orbit comparisons;
- quality thresholds;
- reproducibility across processing changes.
The engineer needs enough information to understand why a solution has a particular quality result.
spod should allow this user to move between:
operational result
|
v
quality assessment
|
v
diagnostics
|
v
processing provenance
without requiring them to reconstruct the run manually.
Relevant use cases:
A ground-segment integrator needs to incorporate POD into a larger mission-processing architecture.
This user is less interested in the internal scientific implementation and more interested in predictable system behavior.
Typical concerns include:
- stable interfaces;
- automation;
- machine-readable configuration;
- deterministic outputs;
- clear failure semantics;
- product discovery;
- integration with storage and downstream processing;
- deployment;
- monitoring.
For this user, spod should behave as a well-defined processing component:
ground segment
|
v
spod
|
+-- status
+-- orbit products
+-- quality results
+-- provenance
|
v
downstream mission systems
The same conceptual workflow should be usable regardless of whether spod is invoked manually, through an API, or from a larger automation system.
Relevant use cases:
During launch and early operations, teams need to determine whether the complete tracking and orbit-processing chain is working correctly.
The commissioning team may include:
- mission operators;
- flight-dynamics engineers;
- GNSS specialists;
- spacecraft engineers;
- ground-segment engineers.
Typical questions include:
- Are GNSS observations being received consistently?
- Are time tags correct?
- Is the receiver behaving as expected?
- Are antenna and spacecraft metadata correct?
- Does the POD solution converge?
- Are residuals reasonable?
- Does the orbit agree with independent information?
- Is the system ready for routine operations?
For these users, spod is not only producing an orbit.
It is helping answer:
Is the tracking and POD chain healthy enough to enter operations?
Relevant use case:
A constellation operator faces the same fundamental POD problem as a single-spacecraft operator, but at a much larger operational scale.
Typical concerns include:
- applying consistent processing across spacecraft;
- managing different mission configurations;
- isolating failures;
- retrying individual spacecraft;
- monitoring fleet-wide processing;
- identifying quality degradation across the fleet;
- rolling out new processing baselines safely.
The product must preserve the identity and reproducibility of every individual spacecraft run while also providing fleet-level visibility.
Conceptually:
fleet processing request
|
v
spod
|
+-- spacecraft A -> POD run
+-- spacecraft B -> POD run
+-- spacecraft C -> POD run
+-- ...
|
v
individual products
+
fleet processing status
+
aggregate quality view
Relevant use case:
Scientific missions and long-lived operational missions often need to regenerate historical orbit products.
Reasons may include:
- improved force models;
- updated calibration;
- better supporting products;
- corrected metadata;
- new processing standards;
- algorithm improvements;
- consistent regeneration of a mission archive.
This user needs to know that a historical processing campaign is controlled and reproducible.
Typical concerns include:
- which processing baseline was used;
- which historical inputs were selected;
- whether the campaign can resume after interruption;
- which arcs failed;
- how new results compare with previous products;
- whether processing is consistent across long periods.
Relevant use case:
An organization may already have a primary orbit solution but need an independent assessment of its quality.
This may occur during:
- mission acceptance;
- supplier validation;
- processing upgrades;
- anomaly investigation;
- software regression testing;
- comparison between processing centers.
The independent validator cares primarily about objective evidence.
Typical questions include:
- How closely does the candidate orbit agree with a reference?
- Are differences systematic or time-dependent?
- Are there coverage gaps?
- Are radial, along-track, or cross-track errors acceptable?
- Does independent tracking confirm the solution?
- Did quality change after a processing update?
In this context, spod acts as a validation system rather than as the primary POD engine.
Relevant use case:
A platform or operations engineer is responsible for keeping the processing system running reliably.
This user may have little interest in the detailed mathematics of POD.
Typical concerns include:
- whether jobs are progressing;
- where failures occur;
- resource usage;
- processing duration;
- whether required data is available;
- whether failed work can be retried safely;
- whether the system can be deployed consistently;
- whether operational problems can be diagnosed.
For this persona, scientific quality and system health are related but distinct:
service health
processing health
scientific quality
spod should make those dimensions observable without requiring the operator to infer them from low-level logs.
Relevant use cases:
These personas often participate in the same workflow from different perspectives.
For example:
Flight Dynamics Engineer
|
| defines processing intent
v
Ground Segment Integrator
|
| integrates workflow
v
spod
|
| produces orbit + quality
v
Satellite Operator
At the same time:
Platform Engineer
|
+--> keeps processing operational
Independent Validator
|
+--> assesses resulting orbit quality
A good spod workflow should therefore produce results that are:
- scientifically meaningful;
- operationally understandable;
- machine-readable;
- reproducible;
- useful to both humans and external systems.
The initial product focus is operational POD for satellite missions, especially where tracking data and supporting products need to be converted into controlled orbit products repeatedly.
The primary audience is therefore:
Satellite operators, flight-dynamics/POD teams, and ground-segment integrators that need operational orbit determination without building the entire processing infrastructure themselves.
Other personas become increasingly important as the same workflows are applied to commissioning, validation, historical processing, and constellation-scale operations.