Skip to main content
For the complete documentation index, see llms.txt.
The Orbit Comprehensive Message (OCM) is the most feature-rich standardized format for exchanging spacecraft orbital information. Unlike OPM (single-epoch state) and OEM (ephemeris time series), OCM combines multiple data types into a single comprehensive message, supporting trajectory state history, spacecraft physical properties, covariance time history, multiple maneuvers, perturbation parameters, and user-defined data.

Why OCM is “Comprehensive”

OCM aggregates and extends the capabilities of OPM, OMM, and OEM into one unified format:
  • Multiple Trajectory States: Time series of state vectors or Keplerian elements (like OEM)
  • Single-Epoch States: State snapshots at specific times (like OPM)
  • Multiple Maneuvers: Comprehensive maneuver planning with impulsive and continuous thrust
  • Physical Properties: Spacecraft mass, area, drag/SRP coefficients, attitude information
  • Covariance Time History: Uncertainty evolution over time
  • Perturbation Parameters: Force model configuration for propagation
  • User-Defined Data: Custom parameters for mission-specific needs
  • Parent-Child Scenarios: Support for deployment and separation events
OCM is the recommended format when you need to exchange comprehensive mission planning data, including orbital states, maneuver plans, spacecraft properties, and uncertainties in a single file.

Key Components

An OCM file contains several distinct sections (all optional except Header and Metadata):
  • Header: File-level metadata (format version, creation date, originator)
  • Metadata: Mission context (object identification, time system, reference frame)
  • Trajectory State Time History: Cartesian state vectors or Keplerian elements over time
  • Physical Descriptor: Spacecraft physical properties (mass, area, drag coefficient, etc.)
  • Covariance Time History: Position/velocity uncertainty matrices over time
  • Maneuver Parameters: Multiple maneuver definitions (impulsive or continuous thrust)
  • Perturbation Parameters: Force model specification for propagation
  • Orbit Determination Parameters: OD configuration and results
  • User-Defined Parameters: Custom mission-specific data

Structure Overview

OCM Hierarchy

Metadata Fields

Required Metadata

Object Identification

Trajectory Configuration

EPOCH_TZERO serves as the time origin for all relative time references in the OCM. Absolute times can also be used where appropriate.

Trajectory State Time History

OCM supports time series of orbital states in multiple representations:

Cartesian State Vectors

Keplerian Elements

Time values can be:
  • Absolute: Full ISO 8601 timestamp
  • Relative: Offset in seconds from EPOCH_TZERO (indicated by + or - prefix)

Physical Descriptor Block

Spacecraft physical properties for accurate propagation:

Key Physical Parameters

Covariance Time History

OCM supports time-varying covariance matrices to represent uncertainty evolution:
The covariance matrix is stored in lower-triangular form, representing the 6×6 position-velocity uncertainty.

Maneuver Parameters

OCM’s most powerful feature is comprehensive maneuver specification supporting both impulsive and continuous thrust maneuvers.

Impulsive Maneuver

A single instantaneous velocity change:

Continuous Thrust Maneuver

Extended burn with time-varying thrust profile:

Maneuver Metadata Fields

MAN_COMPOSITION — Customizable Data Columns

The MAN_COMPOSITION field defines which data columns appear in the maneuver data rows. This allows flexible maneuver specification tailored to the mission needs. Common composition fields:
The order of fields in MAN_COMPOSITION must exactly match the order of data columns in subsequent maneuver data rows. Units must be specified in MAN_UNITS in the same order.

Maneuver Chaining

OCM supports maneuver sequences through MAN_PREV_ID and MAN_NEXT_ID, enabling:
  • Maneuver dependency tracking
  • Sequence validation
  • Mission timeline reconstruction

Perturbation Parameters

Define the force model configuration for orbit propagation:

Perturbation Parameters

Perturbation parameters ensure the receiving system can accurately propagate the orbit using the same force model configuration as the originating system.

User-Defined Parameters

OCM allows custom parameters for mission-specific data:
User-defined parameters should be used sparingly and documented in Interface Control Documents (ICDs). Their meaning must be clearly communicated to all parties exchanging the OCM file.

Common Use Cases

  • Comprehensive Mission Planning: Complete mission state including trajectory, maneuvers, and spacecraft properties
  • Maneuver Sequencing: Planning and tracking multiple burn sequences
  • Conjunction Data Submission: Providing detailed orbital information to conjunction assessment services
  • Formation Flying: Parent-child deployment scenarios and relative state information
  • Mission Handover: Comprehensive state transfer between control centers
  • Long-Duration Missions: Time-varying properties (mass, drag coefficient) over mission lifetime
  • High-Fidelity Propagation: Providing complete force model and spacecraft parameters
Complete definition of the OCM standard in CCSDS 502.0-B-3 specification.

Complete OCM Example

Here is a comprehensive OCM file demonstrating multiple features:

VALAR Import Requirements

VALAR uses OCM as its file format for importing and exporting maneuver data. When importing an OCM file, VALAR validates several requirements beyond the base CCSDS standard. This section is the canonical reference for all import validation rules.
VALAR uses OCM exclusively for maneuver data. Other OCM sections (trajectory state history, covariance, perturbation parameters, orbit determination, user-defined parameters) are parsed but not imported.

File Requirements

Required Maneuver Fields

Every maneuver block (MAN_START to MAN_STOP) must include the following fields:
Specific impulse values outside the 50–10,000 second range will be rejected. This range covers all common propulsion technologies, from cold-gas thrusters (~50 s) to advanced ion engines (~10,000 s).

Physical Properties

Your OCM file must include a physical properties block (PHYS_START to PHYS_STOP) with the WET_MASS field:

Supported Reference Frames

The MAN_REF_FRAME field must use one of the following frames. Inertial Frames: Local Orbital Frames:
If your OCM file uses J2000, VNC, or RIC as the reference frame, VALAR automatically maps them to their canonical equivalents (EME2000, QSW, and RTN respectively).

Spacecraft Matching

VALAR identifies the target spacecraft from the OCM metadata fields, checked in this order:
  1. OBJECT_NAME — spacecraft name
  2. INTERNATIONAL_DESIGNATOR — COSPAR ID (e.g., 2024-001A)
  3. OBJECT_DESIGNATOR — NORAD catalog number
The first matching identifier is used to resolve the spacecraft. If none of the identifiers match a spacecraft in your organization, the import will fail. After resolving the spacecraft, each non-null identifier present in the file is cross-validated against your spacecraft record. The comparison is case-insensitive. If any provided identifier does not match, the import is rejected.
Before importing, verify that the OBJECT_NAME, INTERNATIONAL_DESIGNATOR, or OBJECT_DESIGNATOR in your OCM file matches what is configured on the spacecraft details page in VALAR.

Consistency Rules

  • Uniform basis: All maneuvers in a single file must share the same MAN_BASIS. For planned maneuver imports, all must be PLANNED. For telemetry reports, all must be TELEMETRY (or DETERMINED_TLM).
  • No temporal overlaps: Maneuver time ranges within the file must not overlap. Two maneuvers may share a boundary (one ends exactly when the next begins), but their active periods cannot overlap.

Merge Behavior

When importing maneuvers, two merge strategies are available: Update mode:
  • Maneuvers with a MAN_ID that already exists in VALAR will replace the existing record. For planned imports, the existing maneuver must be in PLANNED status. For telemetry reports, the existing maneuver must be either PLANNED or TELEMETRY.
  • Maneuvers with new IDs must not overlap in time with any existing maneuvers for the same spacecraft.
Replace mode:
  • All existing maneuvers within the imported time range are removed and replaced by the file contents.
Replace mode permanently removes existing maneuvers in the imported time range. This action cannot be undone.

Exporting Maneuvers

  • OCM Export: Export individual maneuvers or maneuver plans from VALAR as OCM files
  • Multi-Maneuver Support: Multiple maneuvers are included in a single OCM file
  • Standard Compliance: Exported OCM files follow CCSDS 502.0-B-3 specification
  • Interoperability: OCM format enables maneuver plan exchange with external systems and agencies

Best Practices

Data Organization

  1. Use EPOCH_TZERO effectively: Set to mission start or a significant epoch for cleaner relative times
  2. Include physical properties: Always provide mass, area, and coefficient data for accurate propagation
  3. Document maneuver sequences: Use MAN_PREV_ID and MAN_NEXT_ID to chain related maneuvers

Maneuver Specification

  1. Choose appropriate DC_TYPE: IMPULSIVE for chemical burns, CONTINUOUS for ion/low-thrust
  2. Specify reference frames clearly: Document whether RTN, LVLH, or other LOF is used
  3. Include all composition fields: Don’t omit important fields like DELTA_MASS or THR_ISP

File Quality

  1. Add comments liberally: Explain mission phases, maneuver purposes, assumptions
  2. Validate before sharing: Ensure all referenced IDs exist and data is self-consistent
  3. Use appropriate units: Follow CCSDS conventions and specify units explicitly in MAN_UNITS

Interoperability

  1. Minimize user-defined parameters: Use standard fields whenever possible
  2. Document extensions: If using USER blocks, provide clear documentation in ICDs
  3. Test round-trip: Verify OCM can be imported and re-exported without data loss

Comparison with Other Formats

When to Use OCM

Use OCM when you need:
  • Multiple maneuvers in a single file
  • Time-varying spacecraft properties (mass, drag coefficient)
  • Complete force model specification for propagation
  • Maneuver sequencing and dependencies
  • Parent-child deployment scenarios
  • Comprehensive mission state exchange
Use OPM instead when:
  • Sharing a simple single-epoch state vector
  • Only one maneuver needs to be specified
  • Simplicity and minimal file size are priorities
Use OEM instead when:
  • Providing pre-computed ephemeris for interpolation
  • No maneuvers or physical properties needed
  • Standard trajectory exchange format expected