Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO 26900:2024 – Orbit Data Messages for Space Systems
Standardized formats for OPM, OMM, OEM, and OCM in space data and information transfer systems
1. Overview of ISO 26900:2024 Orbit Data Messages
ISO 26900:2024 defines the standard format for four types of orbit data messages used in space data and information transfer systems. Developed by the Consultative Committee for Space Data Systems (CCSDS) and adopted under the ISO fast-track procedure, this second edition supersedes ISO 26900:2012 with significant technical enhancements. The standard addresses the critical need for interoperability among international space agencies, satellite operators, and ground segment systems by providing standardized XML-based message formats for exchanging orbital information.
For engineers integrating multi-agency satellite operations, adopting ISO 26900 message formats eliminates the costly and error-prone process of developing custom interface control documents for each inter-agency data exchange.
The standard specifies four distinct message types: the Orbit Parameter Message (OPM), Orbit Mean-Elements Message (OMM), Orbit Ephemeris Message (OEM), and the newly introduced Orbit Comprehensive Message (OCM). Each message type serves a specific use case, ranging from simple Keplerian element exchanges to high-fidelity ephemeris data with full covariance information. All message types can be aggregated into a single Navigation Data Message (NDM) XML file, enabling efficient batch processing and exchange of multiple orbit records.
2. Message Types and Technical Specifications
2.1 Orbit Parameter Message (OPM)
The OPM specifies the position and velocity of a single object at a specified epoch, with optional osculating Keplerian elements. It includes a 6×6 position/velocity covariance matrix for uncertainty estimation and supports modeling of maneuvers (both finite and instantaneous events), solar radiation pressure, and atmospheric drag. The OPM is suited for automated and human-interactive exchanges where high-fidelity dynamic modeling is not required.
2.2 Orbit Mean-Elements Message (OMM)
The OMM contains orbital characteristics expressed in mean Keplerian elements: mean motion, eccentricity, inclination, right ascension of ascending node, argument of perigee, and mean anomaly. It includes parameters for modeling non-conservative forces and supports multiple propagators including SGP, SGP4, and the new SGP4-XP. The second edition added BSTAR/BTERM and MEAN_MOTION_DDOT/AGOM parameter pairs to support these propagators.
2.3 Orbit Ephemeris Message (OEM)
The OEM specifies position and velocity of a single object at multiple epochs within a specified time range. It supports dynamic modeling of any number of gravitational and non-gravitational accelerations and requires interpolation techniques for determining states between tabular epochs. The OEM is ideal for high-precision applications requiring frequent automated time interpretation and processing.
2.4 Orbit Comprehensive Message (OCM)
The OCM is new to the 2024 edition and aggregates/extends OPM, OEM, and OMM content into a single comprehensive hybrid message. It supports en masse parent/child deployment scenarios and includes additional capabilities for multi-object mission planning and execution monitoring.
| Message Type | Primary Use Case | Covariance Support | Propagation Required | New in 2024 |
|---|---|---|---|---|
| OPM | Single-epoch state vector exchange | 6×6 optional | Yes (propagator needed) | MESSAGE_ID field |
| OMM | Mean Keplerian element exchange | No | Yes (SGP/SGP4/SGP4-XP) | BSTAR/BTERM, SGP4-XP support |
| OEM | Multi-epoch ephemeris data | Optional covariance matrix | Interpolation only | MESSAGE_ID field |
| OCM | Comprehensive hybrid messaging | Full support | Configurable | Entirely new message type |
3. Engineering Design Insights and Implementation Guidance
When implementing ISO 26900 in ground segment or spacecraft operations systems, engineers should consider several key design decisions. The choice between OPM and OEM depends primarily on the required propagation accuracy and computational resources available. OPM requires onboard or ground-based propagation to determine states at non-epoch times, which demands more sophisticated software but offers greater flexibility. OEM, by contrast, provides pre-computed states at defined intervals, reducing computational load at the cost of larger data volumes.
The MESSAGE_ID field, added in the 2024 edition, provides a powerful mechanism for message tracking, auditing, and correlation across distributed systems. Implementing unique MESSAGE_ID generation early in system design greatly simplifies downstream troubleshooting and data lineage analysis.
The introduction of the OCM represents a significant architectural advancement. For complex missions involving multiple spacecraft deployments or constellation management, the OCM enables a single standardized file to encapsulate the complete orbital picture, reducing the risk of data inconsistency across multiple message files. Engineers should evaluate the OCM for new mission designs, particularly those involving parent-child deployment scenarios or inter-agency collaboration.
The SGP4-XP propagator support in the OMM requires careful validation against legacy SGP4 implementations. Organizations transitioning from traditional two-line element (TLE) formats should implement parallel testing of both propagators during the transition period to ensure orbital predictions remain within acceptable error bounds.
The XML-based NDM aggregation format (Section 8.12, Annex G) provides robust extensibility. Designers should implement schema validation against the CCSDS navigation message schemas to catch formatting errors early in the data exchange pipeline. Additionally, the covariance matrix fields in OPM and OEM enable rigorous uncertainty propagation, which is essential for conjunction assessment and collision avoidance analysis in increasingly congested orbital environments.
The standard explicitly warns that the OPM covariance matrix is valid only at the reference epoch and degrades with propagation time. Engineers performing conjunction assessments must account for this degradation and should not rely on propagated covariances beyond the recommended validity period without appropriate uncertainty inflation factors.
4. Frequently Asked Questions
Q1: What is the difference between ISO 26900 and traditional TLE formats?
A: Traditional TLE (Two-Line Element) sets are a specific format primarily used with the SGP4 propagator, whereas ISO 26900 provides a standardized XML framework supporting multiple message types (OPM, OMM, OEM, OCM) and propagators (SGP4, SGP4-XP, numerical integration). ISO 26900 offers richer metadata, covariance information, and formal schema validation.
A: Traditional TLE (Two-Line Element) sets are a specific format primarily used with the SGP4 propagator, whereas ISO 26900 provides a standardized XML framework supporting multiple message types (OPM, OMM, OEM, OCM) and propagators (SGP4, SGP4-XP, numerical integration). ISO 26900 offers richer metadata, covariance information, and formal schema validation.
Q2: Can ISO 26900 messages be used for real-time operations?
A: Yes, the OEM is specifically designed for automated computer-to-computer exchanges requiring frequent, fast time interpretation. The OPM is also suitable for near-real-time exchanges. However, real-time latency requirements should be evaluated against the XML parsing overhead.
A: Yes, the OEM is specifically designed for automated computer-to-computer exchanges requiring frequent, fast time interpretation. The OPM is also suitable for near-real-time exchanges. However, real-time latency requirements should be evaluated against the XML parsing overhead.
Q3: How does the OCM differ from simply bundling OPM, OMM, and OEM files?
A: The OCM provides a unified message structure with cross-referencing capabilities between the different orbital representations. It supports parent-child deployment scenarios and includes overarching metadata that would be duplicated or inconsistent if using separate files.
A: The OCM provides a unified message structure with cross-referencing capabilities between the different orbital representations. It supports parent-child deployment scenarios and includes overarching metadata that would be duplicated or inconsistent if using separate files.
Q4: Is backward compatibility maintained with the 2012 edition?
A: The 2024 edition introduces new fields (MESSAGE_ID, BSTAR/BTERM, AGOM) and the OCM, but existing OPM, OMM, and OEM structures from the 2012 edition remain valid. Implementers should update XML schemas and validation rules to accept both legacy and new field combinations during transition.
A: The 2024 edition introduces new fields (MESSAGE_ID, BSTAR/BTERM, AGOM) and the OCM, but existing OPM, OMM, and OEM structures from the 2012 edition remain valid. Implementers should update XML schemas and validation rules to accept both legacy and new field combinations during transition.
