Recommendation for Space Data System Standards 

BLUE BOOK 

ORBIT DATA 

MESSAGES

RECOMMENDED STANDARD

CCSDS 502.0-B-2 

November 2009 

Note:

This current

issue includes

all updates through

Technical Corrigendum 1,

dated May 2012.
Recommendation for Space Data System Standards 

ORBIT DATA 

MESSAGES 

RECOMMENDED STANDARD 

CCSDS 502.0-B-2 

BLUE BOOK 

November 2009 

Note:

This current

issue includes

all updates through

Technical Corrigendum 1,

dated May 2012.
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page i November 2009 

AUTHORITY 

 

 Issue: Recommended Standard, Issue 2 

 Date: November 2009 

 Location: Washington, DC, USA 

 

This document has been approved for publication by the Management Council of the 

Consultative Committee for Space Data Systems (CCSDS) and represents the consensus 

technical agreement of the participating CCSDS Member Agencies. The procedure for 

review and authorization of CCSDS documents is detailed in the Procedures Manual for the 

Consultative Committee for Space Data Systems, and the record of Agency participation in 

the authorization of this document can be obtained from the CCSDS Secretariat at the 

address below. 

This document is published and maintained by: 

CCSDS Secretariat 

Space Communications and Navigation Office, 7L70 

Space Operations Mission Directorate 

NASA Headquarters 

Washington, DC 20546-0001, USA 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page ii November 2009 

STATEMENT OF INTENT 

The Consultative Committee for Space Data Systems (CCSDS) is an organization officially 

established by the management of its members. The Committee meets periodically to address 

data systems problems that are common to all participants, and to formulate sound technical 

solutions to these problems. Inasmuch as participation in the CCSDS is completely 

voluntary, the results of Committee actions are termed Recommended Standards and are 

not considered binding on any Agency. 

This Recommended Standard is issued by, and represents the consensus of, the CCSDS 

members. Endorsement of this Recommendation is entirely voluntary. Endorsement, 

however, indicates the following understandings: 

o Whenever a member establishes a CCSDS-related standard, this standard will be in 

accord with the relevant Recommended Standard. Establishing such a standard 

does not preclude other provisions which a member may develop. 

o Whenever a member establishes a CCSDS-related standard, that member will 

provide other CCSDS members with the following information: 

 -- The standard itself. 

 -- The anticipated date of initial operational capability. 

 -- The anticipated duration of operational service. 

o Specific service arrangements shall be made via memoranda of agreement. Neither 

this Recommended Standard nor any ensuing standard is a substitute for a 

memorandum of agreement. 

No later than five years from its date of issuance, this Recommended Standard will be 

reviewed by the CCSDS to determine whether it should: (1) remain in effect without change; 

(2) be changed to reflect the impact of new technologies, new requirements, or new 

directions; or (3) be retired or canceled. 

In those instances when a new version of a Recommended Standard is issued, existing 

CCSDS-related member standards and implementations are not negated or deemed to be 

non-CCSDS compatible. It is the responsibility of each member to determine when such 

standards or implementations are to be modified. Each member is, however, strongly 

encouraged to direct planning for its new standards and implementations towards the later 

version of the Recommended Standard. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page iii November 2009 

FOREWORD 

This document is a Recommended Standard for Orbit Data Messages (ODMs) and has been 

prepared by the Consultative Committee for Space Data Systems (CCSDS). The set of orbit 

data messages described in this Recommended Standard is the baseline concept for trajectory 

representation in data interchange applications that are cross-supported between Agencies of 

the CCSDS. 

This Recommended Standard establishes a common framework and provides a common 

basis for the interchange of orbit data. It allows implementing organizations within each 

Agency to proceed coherently with the development of compatible derived standards for the 

flight and ground systems that are within their cognizance. Derived Agency standards may 

implement only a subset of the optional features allowed by the Recommended Standard and 

may incorporate features not addressed by this Recommended Standard. 

Through the process of normal evolution, it is expected that expansion, deletion, or 

modification of this document may occur. This Recommended Standard is therefore subject 

to CCSDS document management and change control procedures, which are defined in the 

Procedures Manual for the Consultative Committee for Space Data Systems. Current 

versions of CCSDS documents are maintained at the CCSDS Web site: 

http://www.ccsds.org/ 

Questions relating to the contents or status of this document should be addressed to the 

CCSDS Secretariat at the address indicated on page i. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page iv November 2009 

At time of publication, the active Member and Observer Agencies of the CCSDS were: 

Member Agencies

– Agenzia Spaziale Italiana (ASI)/Italy. 

– British National Space Centre (BNSC)/United Kingdom. 

– Canadian Space Agency (CSA)/Canada. 

– Centre National d’Etudes Spatiales (CNES)/France. 

– China National Space Administration (CNSA)/People’s Republic of China. 

– Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)/Germany. 

– European Space Agency (ESA)/Europe. 

– Russian Federal Space Agency (RFSA)/Russian Federation. 

– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil. 

– Japan Aerospace Exploration Agency (JAXA)/Japan. 

– National Aeronautics and Space Administration (NASA)/USA. 

Observer Agencies

– Austrian Space Agency (ASA)/Austria. 

– Belgian Federal Science Policy Office (BFSPO)/Belgium. 

– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation. 

– Centro Tecnico Aeroespacial (CTA)/Brazil. 

– Chinese Academy of Sciences (CAS)/China. 

– Chinese Academy of Space Technology (CAST)/China. 

– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia. 

– CSIR Satellite Applications Centre (CSIR)/Republic of South Africa. 

– Danish National Space Center (DNSC)/Denmark. 

– European Organization for the Exploitation of Meteorological Satellites 

(EUMETSAT)/Europe. 

– European Telecommunications Satellite Organization (EUTELSAT)/Europe. 

– Geo-Informatics and Space Technology Development Agency (GISTDA)/Thailand. 

– Hellenic National Space Committee (HNSC)/Greece. 

– Indian Space Research Organization (ISRO)/India. 

– Institute of Space Research (IKI)/Russian Federation. 

– KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary. 

– Korea Aerospace Research Institute (KARI)/Korea. 

– Ministry of Communications (MOC)/Israel. 

– National Institute of Information and Communications Technology (NICT)/Japan. 

– National Oceanic and Atmospheric Administration (NOAA)/USA. 

– National Space Organization (NSPO)/Chinese Taipei. 

– Naval Center for Space Technology (NCST)/USA. 

– Scientific and Technological Research Council of Turkey (TUBITAK)/Turkey. 

– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan. 

– Swedish Space Corporation (SSC)/Sweden. 

– United States Geological Survey (USGS)/USA. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page v November 2009 

DOCUMENT CONTROL 

Document Title Date Status 

CCSDS 

502.0-B-1 

Orbit Data Messages, 

Issue 1 

September 

2004 

Original issue, 

superseded 

CCSDS 

502.0-B-2 

Orbit Data Messages, Recommended 

Standard, Issue 2 

November 

2009 

Current issue: 

– changes from the 

original issue are 

documented in 

annex E 

EC 1 Editorial Change 1 April 2012 Corrects erroneous cross 

references and table of 

contents entries; corrects 

typographical anomaly in 

annex B; updates 

informative references 

[G1] and [G2] to current 

issues in annex G. 

CCSDS 

502.0-B-2 

Cor. 1 

Technical Corrigendum 1 May 2012 Corrects/clarifies text; 

updates references [1] and 

[4] to current issues in 1.7.

CCSDS 502.0-B-2 Cor. 1 May 2012
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page vi November 2009 

CONTENTS 

Section Page

1 INTRODUCTION .......................................................................................................... 1-1

1.1 PURPOSE AND SCOPE ........................................................................................ 1-1

1.2 APPLICABILITY ................................................................................................... 1-1

1.3 RATIONALE .......................................................................................................... 1-2

1.4 DOCUMENT STRUCTURE ................................................................................. 1-2

1.5 DEFINITIONS ........................................................................................................ 1-3

1.6 NOMENCLATURE ............................................................................................... 1-3

1.7 REFERENCES ....................................................................................................... 1-3

2 OVERVIEW ................................................................................................................... 2-1

2.1 ORBIT DATA MESSAGE TYPES ....................................................................... 2-1

2.2 ORBIT PARAMETER MESSAGE (OPM) ........................................................... 2-1

2.3 ORBIT MEAN-ELEMENTS MESSAGE (OMM) ................................................ 2-1

2.4 ORBIT EPHEMERIS MESSAGE (OEM) ............................................................. 2-2

2.5 EXCHANGE OF MULTIPLE MESSAGES .......................................................... 2-2

2.6 DEFINITIONS ........................................................................................................ 2-2

3 ORBIT PARAMETER MESSAGE (OPM) ................................................................ 3-1

3.1 GENERAL .............................................................................................................. 3-1

3.2 OPM CONTENT/STRUCTURE ............................................................................ 3-1

3.3 OPM EXAMPLES .................................................................................................. 3-7

4 ORBIT MEAN-ELEMENTS MESSAGE (OMM) ..................................................... 4-1

4.1 GENERAL .............................................................................................................. 4-1

4.2 OMM CONTENT/STRUCTURE .......................................................................... 4-2

4.3 OMM EXAMPLES ................................................................................................ 4-8

5 ORBIT EPHEMERIS MESSAGE (OEM) .................................................................. 5-1

5.1 GENERAL .............................................................................................................. 5-1

5.2 OEM CONTENT/STRUCTURE ........................................................................... 5-1

5.3 OEM EXAMPLES ................................................................................................. 5-7

6 ORBIT DATA MESSAGE SYNTAX .......................................................................... 6-1

6.1 OVERVIEW ........................................................................................................... 6-1

6.2 GENERAL .............................................................................................................. 6-1

6.3 ODM LINES ........................................................................................................... 6-1
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page vii November 2009 

CONTENTS (continued) 

Section Page

6.4 KEYWORD = VALUE NOTATION AND ORDER OF ASSIGNMENT 

STATEMENTS ...................................................................................................... 6-1

6.5 VALUES ................................................................................................................. 6-2

6.6 UNITS IN THE ORBIT DATA MESSAGES ........................................................ 6-4

6.7 COMMENTS IN THE ORBIT DATA MESSAGES ............................................. 6-5

6.8 ORBIT DATA MESSAGE KEYWORDS ............................................................. 6-6

7 SECURITY ..................................................................................................................... 7-1

7.1 OVERVIEW ........................................................................................................... 7-1

7.2 SECURITY CONCERNS RELATED TO THIS 

RECOMMENDED STANDARD .......................................................................... 7-1

7.3 POTENTIAL THREATS AND ATTACK SCENARIOS ..................................... 7-2

7.4 CONSEQUENCES OF NOT APPLYING SECURITY TO 

THE TECHNOLOGY ............................................................................................ 7-2

7.5 DATA SECURITY IMPLEMENTATION SPECIFICS ........................................ 7-2

ANNEX A VALUES FOR TIME_SYSTEM AND FRAME RELATED 

KEYWORDS (NORMATIVE) .................................................................... A-1

ANNEX B ABBREVIATIONS AND ACRONYMS (INFORMATIVE) .....................B-1

ANNEX C RATIONALE FOR ORBIT DATA MESSAGES (INFORMATIVE) ..... C-1

ANNEX D ITEMS FOR AN INTERFACE CONTROL DOCUMENT 

(INFORMATIVE) ......................................................................................... D-1

ANNEX E CHANGES IN ODM VERSION 2 (INFORMATIVE) ..............................E-1

ANNEX F CREATING A VERSION 1.0 COMPLIANT OPM/OEM 

(INFORMATIVE) .......................................................................................... F-1

ANNEX G INFORMATIVE REFERENCES (INFORMATIVE) .............................. G-1

Figure

3-1 Simple OPM File Example ........................................................................................... 3-7

3-2 OPM File Example with Optional Keplerian Elements and Two Maneuvers .............. 3-8

3-3 OPM File Example with Covariance Matrix ................................................................ 3-9

3-4 OPM File Example with Optional Keplerian Elements, 

Covariance Matrix, and a User Defined Parameter .................................................... 3-10

4-1 Example Two Line Element Set (TLE) ........................................................................ 4-8

4-2 OMM File Example without Covariance Matrix .......................................................... 4-8

Cor. 1

CCSDS 502.0-B-2 Cor. 1 May 2012
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page viii November 2009 

CONTENTS (continued) 

Figure Page

4-3 OMM File Example with Covariance Matrix ............................................................... 4-9

4-4 OMM with Units and a User Defined Parameter ....................................................... 4-10

5-1 Version 1 OEM Compatible Example (No Acceleration, No Covariance) .................. 5-8

5-2 Version 2 OEM Example with Optional Accelerations ............................................... 5-9

5-3 Version 2 OEM Example with Optional Covariance Matrices .................................. 5-10

Table

3-1 OPM Header ................................................................................................................. 3-2

3-2 OPM Metadata .............................................................................................................. 3-3

3-3 OPM Data ..................................................................................................................... 3-4

4-1 OMM Header ................................................................................................................ 4-2

4-2 OMM Metadata ............................................................................................................ 4-4

4-3 OMM Data .................................................................................................................... 4-5

5-1 OEM File Layout Specifications .................................................................................. 5-2

5-2 OEM Header ................................................................................................................. 5-3

5-3 OEM Metadata .............................................................................................................. 5-4

C-1 Primary Requirements ..................................................................................................C-2

C-2 Heritage Requirements .................................................................................................C-3

C-3 Desirable Characteristics ..............................................................................................C-3

C-4 Applicability of the Criteria to Orbit Data Messages ...................................................C-4

C-5 Services Available with Orbit Data Messages..............................................................C-5
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 1-1 November 2009 

1 INTRODUCTION 

1.1 PURPOSE AND SCOPE 

This Orbit Data Message (ODM) Recommended Standard specifies three standard message 

formats for use in transferring spacecraft orbit information between space agencies and 

commercial or governmental spacecraft operators: the Orbit Parameter Message (OPM), the 

Orbit Mean-Elements Message (OMM), and the Orbit Ephemeris Message (OEM). Such 

exchanges are used for: 

a) pre-flight planning for tracking or navigation support; 

b) scheduling tracking support; 

c) carrying out tracking operations (sometimes called metric predicts); 

d) performing orbit comparisons; 

e) carrying out navigation operations such as orbit propagation and orbit reconstruction; 

f) assessing mutual physical and electromagnetic interference among satellites orbiting 

the same celestial body (currently primarily Earth, Moon, and Mars); 

g) performing orbit conjunction (collision avoidance) studies; and 

h) developing and executing collaborative maneuvers to mitigate interference or 

enhance mutual operations. 

This Recommended Standard includes sets of requirements and criteria that the message 

formats have been designed to meet. For exchanges where these requirements do not capture 

the needs of the participating agencies and satellite operators, another mechanism may be 

selected. 

1.2 APPLICABILITY 

The rationale behind the design of each orbit data message is described in annex C and may 

help the application engineer to select a suitable message. Definition of the orbit accuracy 

underlying a particular orbit message is outside of the scope of this Recommended Standard 

and should be specified via Interface Control Document (ICD) between data exchange 

participants (or specified via COMMENT sections in the message itself). Applicability 

information specific to each orbit data message format appears in sections 3, 4, and 5, as well 

as in C3. 

This Recommended Standard is applicable only to the message format and content, but not to 

its transmission. The transmission of the message between agencies and operators is outside 

the scope of this document and should be specified in the ICD. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 1-2 November 2009 

Description of the message formats based on the use of Extensible Markup Language (XML) 

is detailed in an integrated XML schema document for all Navigation Data Message 

Recommended Standards. (See reference [4].)

1.3 RATIONALE 

This update to version 1 of the Orbit Data Messages adds a third message type based on 

collaboration of the CCSDS Navigation Working Group and the ISO Technical Committee 

20, Subcommittee 14, Working Group 3 (ISO TC20/SC14/WG3). Additionally, added to the 

messages in the previous version are data structures that provide information regarding the 

uncertainty of the orbital states represented in the messages. Such information will increase 

the number of applications for which the messages are useful. A full list of the changes in 

this document is located in annex E. 

1.4 DOCUMENT STRUCTURE 

Section 2 provides a brief overview of the CCSDS-recommended Orbit Data Message types, 

the Orbit Parameter Message (OPM), Orbit Mean-Elements Message (OMM), and Orbit 

Ephemeris Message (OEM). 

Section 3 provides details about the structure and content of the OPM. 

Section 4 provides details about the structure and content of the OMM. 

Section 5 provides details about the structure and content of the OEM. 

Section 6 discusses the syntax considerations of the set of Orbit Data Messages (OPM, 

OMM, OEM). 

Section 7 discusses security requirements for the Orbit Data Messages. 

Annex A lists acceptable values for selected ODM keywords. 

Annex B is a list of abbreviations and acronyms applicable to the ODM. 

Annex C lists a set of requirements that were taken into consideration in the design of the 

OPM, OMM, and OEM, along with tables and discussion regarding the applicability of the 

three message types to various navigation tasks/functions. 

Annex D lists a number of items that should be covered in ICDs prior to exchanging ODMs 

on a regular basis. There are several statements throughout the document that refer to the 

desirability or necessity of such a document; this annex lists all the suggested ICD items in a 

single place in the document. Also provided is a set of generic comment statements that may 

be added to one of the Orbit Data Messages to convey supplementary information for 

scenarios in which there is no ICD in place. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 1-3 November 2009 

Annex E provides a summary of the changes introduced in this version 2 of the ODM and 

documents the differences between ODM version 1 and ODM version 2. 

Annex F provides instructions for how to produce a version 2 OPM/OEM that is backwards 

compatible to version 1 implementations. 

Annex G provides a listing of informative references. 

1.5 DEFINITIONS 

For the purposes of this document, the following definitions apply: 

a) the word ‘agencies’ may also be construed as meaning ‘satellite operators’ or 

‘satellite service providers’; 

b) the word ‘participant’ denotes an entity that has the ability to acquire or broadcast 

navigation messages and/or radio frequencies, for example, a spacecraft, a tracking 

station, a tracking instrument, or an agency/operator; 

c) the notation ‘n/a’ signifies ‘not applicable’; 

d) depending on context, the term ‘ODM’ may be used to refer to this document, or may 

be used to refer collectively to the OPM, OMM and OEM messages. 

1.6 NOMENCLATURE 

 The following conventions apply throughout this Recommended Standard: 

a) the words ‘shall’ and ‘must’ imply a binding and verifiable specification; 

b) the word ‘should’ implies an optional, but desirable, specification; 

c) the word ‘may’ implies an optional specification; 

d) the words ‘is’, ‘are’, and ‘will’ imply statements of fact. 

1.7 REFERENCES 

The following documents contain provisions which, through reference in this text, constitute 

provisions of this Recommended Standard. At the time of publication, the editions indicated 

were valid. All documents are subject to revision, and users of this Recommended Standard 

are encouraged to investigate the possibility of applying the most recent editions of the 

documents indicated below. The CCSDS Secretariat maintains a register of currently valid 

CCSDS Recommended Standards. 

[1] Time Code Formats. Recommendation for Space Data System Standards, CCSDS 

Cor. 1 

301.0-B-4. Blue Book. Issue 4. Washington, D.C.: CCSDS, November 2010. 

CCSDS 502.0-B-2 Cor. 1 May 2012
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 1-4 November 2009 

[2] Spacewarn Bulletin. Greenbelt, MD, USA: World Data Center for Satellite 

Information: WDC-SI. <http://nssdc.gsfc.nasa.gov/spacewarn> 

[3] Information Technology—8-Bit Single-Byte Coded Graphic Character Sets—Part 1: 

Latin Alphabet No. 1. International Standard, ISO/IEC 8859-1:1998. Geneva: ISO, 

1998. 

[4] XML Specification for Navigation Data Messages. Recommendation for Space Data 

System Standards, CCSDS 505.0-B-1. Blue Book. Issue 1. Washington, D.C.: 

CCSDS, December 2010. 

[5] “JPL Solar System Dynamics.” Solar System Dynamics Group. 

<http://ssd.jpl.nasa.gov/> 

[6] Paul V. Biron and Ashok Malhotra, eds. XML Schema Part 2: Datatypes. 2nd Edition. 

W3C Recommendation. N.p.: W3C, October 2004. 

<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/> 

[7] IEEE Standard for Binary Floating-Point Arithmetic. IEEE Std 754-1985. New York: 

IEEE, 1985. 

Cor. 1

CCSDS 502.0-B-2 Cor. 1 May 2012
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 2-1 November 2009 

2 OVERVIEW 

2.1 ORBIT DATA MESSAGE TYPES 

Three CCSDS-recommended Orbit Data Messages (ODMs) are described in this 

Recommended Standard: the Orbit Parameter Message (OPM), the Orbit Mean-Elements 

Message (OMM), and the Orbit Ephemeris Message (OEM). 

The recommended orbit data messages are ASCII text format (reference [3]). This ODM 

document describes ‘keyword = value notation’ formatted messages, while reference [4] 

describes XML formatted messages (the ICD should specify which of these formats will be 

exchanged). 

NOTE – As currently specified, an OPM, OMM, or OEM file is to represent orbit data for 

a single spacecraft. It is possible that the architecture may support multiple 

spacecraft per file; this could be considered in the future. 

2.2 ORBIT PARAMETER MESSAGE (OPM) 

An OPM specifies the position and velocity of a single object at a specified epoch. 

Optionally, osculating Keplerian elements may be provided. This message is suited to 

exchanges that (1) involve automated interaction and/or human interaction, and (2) do not 

require high-fidelity dynamic modeling. 

The OPM requires the use of a propagation technique to determine the position and velocity 

at times different from the specified epoch, leading to a higher level of effort for software 

implementation than for the OEM. A 6x6 position/velocity covariance matrix that may be 

used in the propagation process is optional. 

The OPM allows for modeling of any number of maneuvers (as both finite and instantaneous 

events) and simple modeling of solar radiation pressure and atmospheric drag. 

The OPM also contains an optional covariance matrix which reflects the uncertainty of the 

orbit state. 

Though primarily intended for use by computers, the attributes of the OPM also make it 

suitable for applications such as exchanges by email, FAX or voice, or applications where 

the message is to be frequently interpreted by humans. 

2.3 ORBIT MEAN-ELEMENTS MESSAGE (OMM) 

An OMM specifies the orbital characteristics of a single object at a specified epoch, 

expressed in mean Keplerian elements. This message is suited to exchanges that (1) involve 

automated interaction and/or human interaction, and (2) do not require high-fidelity dynamic 

modeling. Such exchanges may be inter-agency exchanges, or ad hoc exchanges among 

satellite operators when interface control documents have not been negotiated. Ad hoc 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 2-2 November 2009 

interactions usually involve more than one satellite, each satellite controlled and operated by 

a different operating authority. 

The OMM includes keywords and values that can be used to generate canonical NORAD Two 

Line Element Sets (TLEs) to accommodate the needs of heritage users (see reference [G4]). 

The OMM also contains an optional covariance matrix which reflects the uncertainty of the 

mean Keplerian elements. This information may be used to determine contact parameters 

that encompass uncertainties in predicted future states of orbiting objects of interest. 

This message is suited for directing antennas and planning contacts with satellites. It is not 

recommended for assessing mutual physical or electromagnetic interference among Earthorbiting spacecraft, developing collaborative maneuvers, or propagating precisely the orbits 

of active satellites, inactive man made objects, and near-Earth debris fragments. It is not 

suitable for numerical integration of the governing equations. 

Though primarily intended for use by computers, the attributes of the OMM also make it 

suitable for applications such as exchanges by email, FAX or voice, or applications where 

the message is to be frequently interpreted by humans. 

2.4 ORBIT EPHEMERIS MESSAGE (OEM) 

An OEM specifies the position and velocity of a single object at multiple epochs contained 

within a specified time range. The OEM is suited to exchanges that (1) involve automated 

interaction (e.g., computer-to-computer communication where frequent, fast automated time 

interpretation and processing is required), and (2) require higher fidelity or higher precision 

dynamic modeling than is possible with the OPM. 

The OEM allows for dynamic modeling of any number of gravitational and non-gravitational 

accelerations. The OEM requires the use of an interpolation technique to interpret the 

position and velocity at times different from the tabular epochs. 

The OEM also contains an optional covariance matrix which reflects the uncertainty of the 

orbit solution used to generate states in the ephemeris. 

2.5 EXCHANGE OF MULTIPLE MESSAGES 

For a given object, multiple OPM, OMM, or OEM messages may be provided in a message 

exchange session to achieve ephemeris fidelity requirements. If ephemeris information for 

multiple objects is to be exchanged, then multiple OPM, OMM, or OEM files must be used. 

2.6 DEFINITIONS 

Definitions of time systems, reference frames, planetary models, maneuvers and other 

fundamental topics related to the interpretation and processing of state vectors and spacecraft 

ephemerides are provided in reference [G1]. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 3-1 November 2009 

3 ORBIT PARAMETER MESSAGE (OPM) 

3.1 GENERAL 

3.1.1 Orbit information may be exchanged between two participants by sending a state 

vector (see reference [G1]) for a specified epoch using an Orbit Parameter Message (OPM). 

The message recipient must have an orbit propagator available that is able to propagate the 

OPM state vector to compute the orbit at other desired epochs. For this propagation, 

additional ancillary information (spacecraft properties such as mass, area, and maneuver 

planning data, if applicable) may be included with the message. 

3.1.2 Osculating Keplerian elements and Gravitational Coefficient may be included in the 

OPM in addition to the Cartesian state to aid the message recipient in performing consistency 

checks. If any Keplerian element is included, the entire set of elements must be provided. 

3.1.3 If participants wish to exchange mean element information, then the Orbit MeanElements Message (OMM) should be the selected message type. (See section 4.) 

3.1.4 The use of the OPM is best applicable under the following conditions: 

a) an orbit propagator consistent with the models used to develop the orbit data should 

be available at the receiver’s site; 

b) the receiver’s modeling of gravitational forces, solar radiation pressure, atmospheric 

drag, and thrust phases (see reference [G1]) should fulfill accuracy requirements 

established between the exchange partners. 

3.1.5 The OPM shall be a plain text file consisting of orbit data for a single object. It shall 

be easily readable by both humans and computers. 

3.1.6 The OPM file-naming scheme should be agreed to on a case-by-case basis between the 

exchange partners, and should be documented in an ICD. The method of exchanging OPMs 

should be decided on a case-by-case basis by the exchange partners and documented in an ICD. 

NOTE – Detailed syntax rules for the OPM are specified in section 6. 

3.2 OPM CONTENT/STRUCTURE 

3.2.1 GENERAL 

The OPM shall be represented as a combination of the following: 

a) a header; 

b) metadata (data about data); 

c) data; and 

d) optional comments (explanatory information). 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 3-2 November 2009 

3.2.2 OPM HEADER 

3.2.2.1 Table 3-1 specifies for each header item: 

a) the keyword to be used; 

b) a short description of the item; 

c) examples of allowed values; and 

d) whether the item is obligatory or optional. 

3.2.2.2 Only those keywords shown in table 3-1 shall be used in an OPM header. 

Table 3-1: OPM Header 

Keyword Description Examples of Values Obligatory

CCSDS_OPM_VERS Format version in the form of ‘x.y’, where ‘y’ is 

incremented for corrections and minor changes, 

and ‘x’ is incremented for major changes. 

2.0 Yes 

COMMENT Comments (allowed in the OPM Header only 

immediately after the OPM version number). (See 

6.7 for formatting rules.) 

COMMENT This is a comment No 

CREATION_DATE File creation date/time in UTC. (For format 

specification, see 6.5.9.) 

2001-11-06T11:17:33 

2002-204T15:56:23Z

Yes 

ORIGINATOR Creating agency or operator (value should be 

specified in an ICD). The country of origin should 

also be provided where the originator is not a 

national space agency. 

CNES, ESOC, GSFC, GSOC, JPL, 

JAXA, INTELSAT/USA, USAF, 

INMARSAT/UK 

Yes 

3.2.3 OPM METADATA 

3.2.3.1 Table 3-2 specifies for each metadata item: 

a) the keyword to be used; 

b) a short description of the item; 

c) examples of allowed values; and 

d) whether the item is obligatory or optional. 

3.2.3.2 Only those keywords shown in table 3-2 shall be used in OPM metadata. 

NOTE – For some keywords (OBJECT_NAME, OBJECT_ID, CENTER_NAME) there 

are no definitive lists of authorized values maintained by a control authority; the 

references listed in 1.7 are the best known sources for authorized values to date. 

For the TIME_SYSTEM and REF_FRAME keywords, the approved values are 

listed in annex A. 

Cor. 1

CCSDS 502.0-B-2 Cor. 1 May 2012
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 3-3 November 2009 

Table 3-2: OPM Metadata 

Keyword Description Examples of Values Obligatory 

COMMENT Comments (allowed at the beginning of the OPM 

Metadata). (See 6.7 for formatting rules.) 

COMMENT This is a comment No 

OBJECT_NAME Spacecraft name for which the orbit state is 

provided. There is no CCSDS-based restriction on 

the value for this keyword, but it is recommended 

to use names from the SPACEWARN Bulletin 

(reference [2]), which include Object name and 

international designator of the participant. 

EUTELSAT W1 

MARS PATHFINDER 

STS 106 

NEAR

Yes 

OBJECT_ID Object identifier of the object for which the orbit 

state is provided. There is no CCSDS-based 

restriction on the value for this keyword, but it is 

recommended that values be the international 

spacecraft designator as published in the 

SPACEWARN Bulletin (reference [2]). 

Recommended values have the format YYYYNNNP{PP}, where: 

YYYY = Year of launch. 

NNN = Three digit serial number of launch in 

year YYYY (with leading zeros). 

P{PP} = At least one capital letter for the 

identification of the part brought into 

space by the launch. 

In cases where the asset is not listed in the bulletin, 

or the SPACEWARN format is not used, the value 

should be provided in an ICD. 

2000-052A 

1996-068A 

2000-053A 

1996-008A 

Yes 

CENTER_NAME Origin of reference frame, which may be a natural 

solar system body (planets, asteroids, comets, and 

natural satellites), including any planet barycenter 

or the solar system barycenter, or another 

spacecraft (in this case the value for 

‘CENTER_NAME’ is subject to the same rules as 

for ‘OBJECT_NAME’). There is no CCSDS-based 

restriction on the value for this keyword, but for 

natural bodies it is recommended to use names 

from the NASA/JPL Solar System Dynamics 

Group at http://ssd.jpl.nasa.gov (reference [5]). 

EARTH 

EARTH BARYCENTER 

MOON 

SOLAR SYSTEM BARYCENTER 

SUN 

JUPITER BARYCENTER 

STS 106 

EROS

Yes 

REF_FRAME Name of the reference frame in which the state 

vector and optional Keplerian element data are 

given. Use of values other than those in annex A 

must be documented in an ICD. The reference 

frame must be the same for all data elements, with 

the exception of the maneuvers and covariance 

matrix, for which applicable different reference 

frames may be specified.

ICRF 

ITRF-93 

ITRF-97 

ITRF2000 

ITRFxxxx (Template for a future version)

TOD (True Equator/Equinox of Date)

EME2000 (Earth Mean Equator and 

Equinox of J2000) 

TDR (true of date rotating) 

GRC (Greenwich rotating coordinate 

frame) 

Yes 

REF_FRAME_EPOCH Epoch of reference frame, if not intrinsic to the 

definition of the reference frame. (See 6.5.9 for 

formatting rules.) 

2001-11-06T11:17:33 

2002-204T15:56:23Z 

No 

TIME_SYSTEM Time system used for state vector, maneuver, and 

covariance data (also see table 3-3). Use of values 

other than those in annex A must be documented in 

an ICD. 

UTC, TAI, TT, GPS, TDB, TCB Yes 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 3-4 November 2009 

3.2.4 OPM DATA 

3.2.4.1 Table 3-3 provides an overview of the six logical blocks in the OPM Data section 

(State Vector, Osculating Keplerian Elements, Spacecraft Parameters, Position/Velocity 

Covariance Matrix, Maneuver Parameters, and User Defined Parameters), and specifies for 

each data item: 

a) the keyword to be used; 

b) a short description of the item; 

c) the units to be used; 

d) whether the item is obligatory or optional. 

3.2.4.2 Only those keywords shown in table 3-3 shall be used in OPM data. 

NOTE – Requirements relating to the keywords in table 3-3 appear after the table. 

Table 3-3: OPM Data 

Keyword Description Units Obligatory

State Vector Components in the Specified Coordinate System 

COMMENT (See 6.7 for formatting rules.) n/a No 

EPOCH Epoch of state vector & optional Keplerian elements. (See 

6.5.9 for formatting rules.) 

n/a Yes 

X Position vector X-component km Yes 

Y Position vector Y-component km Yes 

Z Position vector Z-component km Yes 

X_DOT Velocity vector X-component km/s Yes 

Y_DOT Velocity vector Y-component km/s Yes 

Z_DOT Velocity vector Z-component km/s Yes 

Osculating Keplerian Elements in the Specified Reference Frame (none or all parameters of this block must be given.) 

COMMENT (See 6.7 for formatting rules.) n/a No 

SEMI_MAJOR_AXIS Semi-major axis km No 

ECCENTRICITY Eccentricity n/a No 

INCLINATION Inclination deg No 

RA_OF_ASC_NODE Right ascension of ascending node deg No 

ARG_OF_PERICENTER Argument of pericenter deg No 

TRUE_ANOMALY or

MEAN_ANOMALY 

True anomaly or mean anomaly deg No 

GM Gravitational Coefficient (Gravitational Constant x Central 

Mass) 

km**3/s**2 No 

Spacecraft Parameters 

COMMENT (See 6.7 for formatting rules.) n/a No 

MASS S/C Mass kg No 

SOLAR_RAD_AREA Solar Radiation Pressure Area (AR) m**2 No 

SOLAR_RAD_COEFF Solar Radiation Pressure Coefficient (CR) n/a No 

DRAG_AREA Drag Area (AD) m**2 No 

DRAG_COEFF Drag Coefficient (CD) n/a No 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 3-5 November 2009 

Keyword Description Units Obligatory

Position/Velocity Covariance Matrix (6x6 Lower Triangular Form. None or all parameters of the matrix must be given. 

COV_REF_FRAME may be omitted if it is the same as the metadata REF_FRAME.) 

COMMENT (See 6.7 for formatting rules.) n/a No 

COV_REF_FRAME Coordinate system for covariance matrix (value must be 

selected from annex A) 

n/a No 

CX_X Covariance matrix [1,1] km**2 No 

CY_X Covariance matrix [2,1] km**2 No 

CY_Y Covariance matrix [2,2] km**2 No 

CZ_X Covariance matrix [3,1] km**2 No 

CZ_Y Covariance matrix [3,2] km**2 No 

CZ_Z Covariance matrix [3,3] km**2 No 

CX_DOT_X Covariance matrix [4,1] km**2/s No 

CX_DOT_Y Covariance matrix [4,2] km**2/s No 

CX_DOT_Z Covariance matrix [4,3] km**2/s No 

CX_DOT_X_DOT Covariance matrix [4,4] km**2/s**2 No 

CY_DOT_X Covariance matrix [5,1] km**2/s No 

CY_DOT_Y Covariance matrix [5,2] km**2/s No 

CY_DOT_Z Covariance matrix [5,3] km**2/s No 

CY_DOT_X_DOT Covariance matrix [5,4] km**2/s**2 No 

CY_DOT_Y_DOT Covariance matrix [5,5] km**2/s**2 No 

CZ_DOT_X Covariance matrix [6,1] km**2/s No 

CZ_DOT_Y Covariance matrix [6,2] km**2/s No 

CZ_DOT_Z Covariance matrix [6,3] km**2/s No 

CZ_DOT_X_DOT Covariance matrix [6,4] km**2/s**2 No 

CZ_DOT_Y_DOT Covariance matrix [6,5] km**2/s**2 No 

CZ_DOT_Z_DOT Covariance matrix [6,6] km**2/s**2 No 

Maneuver Parameters (Repeat for each maneuver. None or all parameters of this block must be given.) 

COMMENT (See 6.7 for formatting rules.) n/a No 

MAN_EPOCH_IGNITION Epoch of ignition. (See 6.5.9 for formatting rules.) n/a No 

MAN_DURATION Maneuver duration (If = 0, impulsive maneuver) s No 

MAN_DELTA_MASS Mass change during maneuver (value is < 0) kg No 

MAN_REF_FRAME Coordinate system for velocity increment vector (value 

must be selected from annex A) 

n/a No 

MAN_DV_1 1st component of the velocity increment km/s No 

MAN_DV_2 2nd component of the velocity increment km/s No 

MAN_DV_3 3rd component of the velocity increment km/s No 

User Defined Parameters (all parameters in this section must be described in an ICD). 

USER_DEFINED_x User defined parameter, where ‘x’ is replaced by a variable 

length user specified character string. Any number of user 

defined parameters may be included, if necessary to 

provide essential information that cannot be conveyed in 

COMMENT statements. Example: 

USER_DEFINED_EARTH_MODEL = WGS-84 

n/a No 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 3-6 November 2009 

3.2.4.3 All values except Maneuver Parameters in the OPM data are ‘at epoch’, i.e., the 

value of the parameter at the time specified in the EPOCH keyword. 

3.2.4.4 Table 3-3 is broken into six logical blocks, each of which has a descriptive heading. 

These descriptive headings shall not be included in an OPM, unless they appear in a properly 

formatted COMMENT statement. 

3.2.4.5 If the solar radiation coefficient, CR, is set to zero, no solar radiation pressure shall 

be taken into account. 

3.2.4.6 If the atmospheric drag coefficient, CD, is set to zero, no atmospheric drag shall be 

taken into account. 

3.2.4.7 Parameters for thrust phases may be optionally given for the computation of the 

trajectory during or after maneuver execution (see reference [G1] for the simplified modeling 

of such maneuvers). For impulsive maneuvers, MAN_DURATION must be set to zero. 

MAN_DELTA_MASS may be used for both finite and impulsive maneuvers; the value must 

be a negative number. Permissible reference frames for the velocity increment vector shall 

be those specified in annex A. 

3.2.4.8 Multiple sets of maneuver parameters may appear. For each maneuver, all the 

maneuver parameters shall be repeated in the order shown in table 3-3. 

3.2.4.9 If the OPM contains a maneuver definition, the Spacecraft Parameters section must 

be included. 

3.2.4.10 Values in the covariance matrix shall be expressed in the applicable reference frame 

(COV_REF_FRAME keyword if used, or REF_FRAME keyword if not), and shall be 

presented sequentially from upper left [1,1] to lower right [6,6], lower triangular form, row 

by row left to right. Variance and covariance values shall be expressed in standard double 

precision as related in 6.5. This logical block of the OPM may be useful for risk assessment 

and establishing maneuver and mission margins. The intent is to provide causal connections 

between output orbit data and both physical hypotheses and measurement uncertainties. 

These causal relationships guide operators’ corrective actions and mitigations. 

3.2.4.11 A section of User Defined Parameters is allowed. In principle, this provides 

flexibility, but also introduces complexity, non-standardization, potential ambiguity, and 

potential processing errors. Accordingly, if used, the keywords and their meanings must be 

described in an ICD. User Defined Parameters, if included in an OPM, should be used as 

sparingly as possible; their use is not encouraged. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 3-7 November 2009 

3.3 OPM EXAMPLES 

Figure 3-1 through figure 3-4 are examples of Orbit Parameter Messages. The first has only 

a state; the second has state, Keplerian elements, and maneuvers; the third and fourth include 

the position/velocity covariance matrix. 

Figure 3-1 and figure 3-2 are compatible with the ODM version 1.0 processing because they 

do not contain any of the unique features of the ODM version 2.0. Thus for these examples a 

value of 1.0 could be specified for the ‘CCSDS_OPM_VERS’ keyword. (See annex F.) 

Figure 3-3 and figure 3-4 include unique features of ODM version 2.0, and thus 

‘CCSDS_OPM_VERS = 2.0’ must be specified. 

CCSDS_OPM_VERS = 2.0 

CREATION_DATE = 1998-11-06T09:23:57 

ORIGINATOR = JAXA 

COMMENT GEOCENTRIC, CARTESIAN, EARTH FIXED 

OBJECT_NAME = GODZILLA 5 

OBJECT_ID = 1998-057A 

CENTER_NAME = EARTH 

REF_FRAME = ITRF-97 

TIME_SYSTEM = UTC 

EPOCH = 1998-12-18T14:28:15.1172 

X = 6503.514000 

Y = 1239.647000 

Z = -717.490000 

X_DOT = -0.873160 

Y_DOT = 8.740420 

Z_DOT = -4.191076 

MASS = 3000.000000 

SOLAR_RAD_AREA = 18.770000 

SOLAR_RAD_COEFF = 1.000000 

DRAG_AREA = 18.770000 

DRAG_COEFF = 2.500000 

Figure 3-1: Simple OPM File Example 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 3-8 November 2009 

CCSDS_OPM_VERS = 2.0 

COMMENT Generated by GSOC, R. Kiehling 

COMMENT Current intermediate orbit IO2 and maneuver planning data 

CREATION_DATE = 2000-06-03T05:33:00.000 

ORIGINATOR = GSOC 

OBJECT_NAME = EUTELSAT W4 

OBJECT_ID = 2000-028A 

CENTER_NAME = EARTH 

REF_FRAME = TOD 

TIME_SYSTEM = UTC 

COMMENT State Vector 

EPOCH = 2006-06-03T00:00:00.000 

X = 6655.9942 [km] 

Y = -40218.5751 [km] 

Z = -82.9177 [km] 

X_DOT = 3.11548208 [km/s] 

Y_DOT = 0.47042605 [km/s] 

Z_DOT = -0.00101495 [km/s] 

COMMENT Keplerian elements 

SEMI_MAJOR_AXIS = 41399.5123 [km] 

ECCENTRICITY = 0.020842611 

INCLINATION = 0.117746 [deg] 

RA_OF_ASC_NODE = 17.604721 [deg] 

ARG_OF_PERICENTER = 218.242943 [deg] 

TRUE_ANOMALY = 41.922339 [deg] 

GM = 398600.4415 [km**3/s**2] 

COMMENT Spacecraft parameters 

MASS = 1913.000 [kg] 

SOLAR_RAD_AREA = 10.000 [m**2] 

SOLAR_RAD_COEFF = 1.300 

DRAG_AREA = 10.000 [m**2] 

DRAG_COEFF = 2.300 

COMMENT 2 planned maneuvers 

COMMENT First maneuver: AMF-3 

COMMENT Non-impulsive, thrust direction fixed in inertial frame 

MAN_EPOCH_IGNITION = 2000-06-03T09:00:34.1 

MAN_DURATION = 132.60 [s] 

MAN_DELTA_MASS = -18.418 [kg] 

MAN_REF_FRAME = EME2000 

MAN_DV_1 = -0.02325700 [km/s] 

MAN_DV_2 = 0.01683160 [km/s] 

MAN_DV_3 = -0.00893444 [km/s] 

COMMENT Second maneuver: first station acquisition maneuver 

COMMENT impulsive, thrust direction fixed in RTN frame 

MAN_EPOCH_IGNITION = 2000-06-05T18:59:21.0 

MAN_DURATION = 0.00 [s] 

MAN_DELTA_MASS = -1.469 [kg] 

MAN_REF_FRAME = RTN 

MAN_DV_1 = 0.00101500 [km/s] 

MAN_DV_2 = -0.00187300 [km/s] 

MAN_DV_3 = 0.00000000 [km/s]

Figure 3-2: OPM File Example with Optional Keplerian Elements and Two Maneuvers 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 3-9 November 2009 

CCSDS_OPM_VERS = 2.0 

CREATION_DATE = 1998-11-06T09:23:57 

ORIGINATOR = JAXA 

COMMENT GEOCENTRIC, CARTESIAN, EARTH FIXED 

OBJECT_NAME = GODZILLA 5 

OBJECT_ID = 1998-057A 

CENTER_NAME = EARTH 

REF_FRAME = ITRF-97 

TIME_SYSTEM = UTC 

EPOCH = 1998-12-18T14:28:15.1172 

X = 6503.514000 

Y = 1239.647000 

Z = -717.490000 

X_DOT = -0.873160 

Y_DOT = 8.740420 

Z_DOT = -4.191076 

MASS = 3000.000000 

SOLAR_RAD_AREA = 18.770000 

SOLAR_RAD_COEFF = 1.000000 

DRAG_AREA = 18.770000 

DRAG_COEFF = 2.500000 

CX_X = 3.331349476038534e-04 

CY_X = 4.618927349220216e-04 

CY_Y = 6.782421679971363e-04 

CZ_X = -3.070007847730449e-04 

CZ_Y = -4.221234189514228e-04 

CZ_Z = 3.231931992380369e-04 

CX_DOT_X = -3.349365033922630e-07 

CX_DOT_Y = -4.686084221046758e-07 

CX_DOT_Z = 2.484949578400095e-07 

CX_DOT_X_DOT = 4.296022805587290e-10 

CY_DOT_X = -2.211832501084875e-07 

CY_DOT_Y = -2.864186892102733e-07 

CY_DOT_Z = 1.798098699846038e-07 

CY_DOT_X_DOT = 2.608899201686016e-10 

CY_DOT_Y_DOT = 1.767514756338532e-10 

CZ_DOT_X = -3.041346050686871e-07 

CZ_DOT_Y = -4.989496988610662e-07 

CZ_DOT_Z = 3.540310904497689e-07 

CZ_DOT_X_DOT = 1.869263192954590e-10 

CZ_DOT_Y_DOT = 1.008862586240695e-10 

CZ_DOT_Z_DOT = 6.224444338635500e-10 

Figure 3-3: OPM File Example with Covariance Matrix 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 3-10 November 2009 

CCSDS_OPM_VERS = 2.0 

COMMENT Generated by GSOC, R. Kiehling 

COMMENT Current intermediate orbit IO2 and maneuver planning data 

CREATION_DATE = 2000-06-03T05:33:00.000 

ORIGINATOR = GSOC 

OBJECT_NAME = EUTELSAT W4 

OBJECT_ID = 2000-028A 

CENTER_NAME = EARTH 

REF_FRAME = TOD 

TIME_SYSTEM = UTC 

COMMENT State Vector 

EPOCH = 2006-06-03T00:00:00.000 

X = 6655.9942 [km] 

Y = -40218.5751 [km] 

Z = -82.9177 [km] 

X_DOT = 3.11548208 [km/s] 

Y_DOT = 0.47042605 [km/s] 

Z_DOT = -0.00101495 [km/s] 

COMMENT Keplerian elements 

SEMI_MAJOR_AXIS = 41399.5123 [km] 

ECCENTRICITY = 0.020842611 

INCLINATION = 0.117746 [deg] 

RA_OF_ASC_NODE = 17.604721 [deg] 

ARG_OF_PERICENTER = 218.242943 [deg] 

TRUE_ANOMALY = 41.922339 [deg] 

GM = 398600.4415 [km**3/s**2] 

COMMENT Spacecraft parameters 

MASS = 1913.000 [kg] 

SOLAR_RAD_AREA = 10.000 [m**2] 

SOLAR_RAD_COEFF = 1.300 

DRAG_AREA = 10.000 [m**2] 

DRAG_COEFF = 2.300 

COV_REF_FRAME = RTN 

CX_X = 3.331349476038534e-04 

CY_X = 4.618927349220216e-04 

CY_Y = 6.782421679971363e-04 

CZ_X = -3.070007847730449e-04 

CZ_Y = -4.221234189514228e-04 

CZ_Z = 3.231931992380369e-04 

CX_DOT_X = -3.349365033922630e-07 

CX_DOT_Y = -4.686084221046758e-07 

CX_DOT_Z = 2.484949578400095e-07 

CX_DOT_X_DOT = 4.296022805587290e-10 

CY_DOT_X = -2.211832501084875e-07 

CY_DOT_Y = -2.864186892102733e-07 

CY_DOT_Z = 1.798098699846038e-07 

CY_DOT_X_DOT = 2.608899201686016e-10 

CY_DOT_Y_DOT = 1.767514756338532e-10 

CZ_DOT_X = -3.041346050686871e-07 

CZ_DOT_Y = -4.989496988610662e-07 

CZ_DOT_Z = 3.540310904497689e-07 

CZ_DOT_X_DOT = 1.869263192954590e-10 

CZ_DOT_Y_DOT = 1.008862586240695e-10 

CZ_DOT_Z_DOT = 6.224444338635500e-10 

USER_DEFINED_EARTH_MODEL = WGS-84 

Figure 3-4: OPM File Example with Optional Keplerian Elements, Covariance 

Matrix, and a User Defined Parameter 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 4-1 November 2009 

4 ORBIT MEAN-ELEMENTS MESSAGE (OMM) 

4.1 GENERAL 

4.1.1 Orbit information may be exchanged between two participants by sending an orbital 

state based on mean Keplerian elements (see reference [G1]) for a specified epoch using an 

Orbit Mean-Elements Message (OMM). The message recipient must use appropriate orbit 

propagator algorithms in order to correctly propagate the OMM state to compute the orbit at 

other desired epochs. 

4.1.2 The OMM is intended to allow replication of the data content of an existing TLE in a 

CCSDS standard format, but the message can also accommodate other implementations of 

mean elements. All essential fields of the ‘de facto standard’ TLE are included in the OMM 

in a style that is consistent with that of the other ODMs (i.e., the OPM and OEM). From the 

fields in the OMM, it is possible to generate a TLE (see reference [G3]). Programs that 

convert OMMs to TLEs must be aware of the structural requirements of the TLE, including 

the checksum algorithm and the formatting requirements for the values in the TLE. The 

checksum and formatting requirements of the TLE do not apply to the values in an OMM. 

4.1.3 If participants wish to exchange osculating element information, then the Orbit 

Parameter Message (OPM) should be the selected message type. (See section 3.) 

4.1.4 The use of the OMM is best applicable under the following conditions: 

a) an orbit propagator consistent with the models used to develop the orbit data should 

be run at the receiver’s site; 

b) the receiver’s modeling of gravitational forces, solar radiation pressure, atmospheric 

drag, etc. (see reference [G1]), should fulfill accuracy requirements established 

between the exchange partners. 

4.1.5 The OMM shall be a plain text file consisting of orbit data for a single object. It shall 

be easily readable by both humans and computers. 

4.1.6 The OMM file-naming scheme should be agreed to on a case-by-case basis between 

the exchange partners, and should be documented in an ICD. The method of exchanging 

OMMs should be decided on a case-by-case basis by the exchange partners and documented 

in an ICD. 

NOTE – Detailed syntax rules for the OMM are specified in section 6. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 4-2 November 2009 

4.2 OMM CONTENT/STRUCTURE 

4.2.1 GENERAL 

The OMM shall be represented as a combination of the following: 

a) a header; 

b) metadata (data about data); 

c) data; and 

d) optional comments (explanatory information). 

4.2.2 OMM HEADER 

4.2.2.1 Table 4-1 specifies for each header item: 

a) the keyword to be used; 

b) a short description of the item; 

c) examples of allowed values; and 

d) whether the item is obligatory or optional. 

4.2.2.2 Only those keywords shown in table 4-1 shall be used in an OMM header. 

Table 4-1: OMM Header 

Keyword Description Examples of Values Obligatory

CCSDS_OMM_VERS Format version in the form of ‘x.y’, where ‘y’ is 

incremented for corrections and minor changes, 

and ‘x’ is incremented for major changes. 

2.0 Yes 

COMMENT Comments (allowed in the OMM Header only 

immediately after the OMM version number). 

(See 6.7 for formatting rules.) 

COMMENT This is a comment No 

CREATION_DATE File creation date/time in UTC. ( For format 

specification, see 6.5.9.) 

2001-11-06T11:17:33 

2002-204T15:56:23Z

Yes 

ORIGINATOR Creating agency or operator (value should be 

specified in an ICD). The country of origin should 

also be provided where the originator is not a 

national space agency. 

CNES, ESOC, GSFC, GSOC, JPL, 

JAXA, INTELSAT/USA, USAF, 

INMARSAT/UK 

Yes 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 4-3 November 2009 

4.2.3 OMM METADATA 

4.2.3.1 Table 4-2 specifies for each metadata item: 

a) the keyword to be used; 

b) a short description of the item; 

c) examples of allowed values; and 

d) whether the item is obligatory or optional. 

4.2.3.2 Only those keywords shown in table 4-2 shall be used in OMM metadata. 

NOTE – For some keywords (OBJECT_NAME, OBJECT_ID, CENTER_NAME) there 

are no definitive lists of authorized values maintained by a control authority; the 

references listed in 1.7 are the best known sources for authorized values to date. 

For the TIME_SYSTEM and REF_FRAME keywords, the approved values are 

shown in annex A. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 4-4 November 2009 

Table 4-2: OMM Metadata 

Keyword Description Examples of Values Obligatory

COMMENT Comments (allowed at the beginning of the 

OMM Metadata). (See 6.7 for formatting rules.)

COMMENT This is a comment No 

OBJECT_NAME Spacecraft name for which the orbit state is 

provided. There is no CCSDS-based restriction 

on the value for this keyword, but it is 

recommended to use names from the 

SPACEWARN Bulletin (reference [2]), which 

include Object name and international 

designator of the participant. 

TELCOM 2 

SPACEWAY 2 

INMARSAT 4-F2 

Yes 

OBJECT_ID Object identifier of the object for which the orbit 

state is provided. There is no CCSDS-based 

restriction on the value for this keyword, but it is 

recommended that values be the international 

spacecraft designator as published in the 

SPACEWARN Bulletin (reference [2]). 

Recommended values have the format YYYYNNNP{PP}, where: 

YYYY = Year of launch. 

NNN = Three digit serial number of launch 

in year YYYY (with leading zeros). 

P{PP} = At least one capital letter for the 

identification of the part brought 

into space by the launch. 

In cases where the asset is not listed in the 

bulletin, or the SPACEWARN format is not 

used, the value should be provided in an ICD. 

2005-046B 

2005-046A 

2003-022A 

2005-044A 

Yes 

CENTER_NAME Origin of reference frame. There is no CCSDSbased restriction on the value for this keyword, 

but for natural bodies it is recommended to use 

names from the NASA/JPL Solar System 

Dynamics Group at http://ssd.jpl.nasa.gov

(reference [5]). 

EARTH 

MARS 

MOON

Yes 

REF_FRAME Name of the reference frame in which the 

Keplerian element data are given. Use of values 

other than those in annex A must be documented 

in an ICD. The reference frame must be the 

same for all data elements, with the exception of 

the covariance matrix, for which an applicable 

different reference frame may be specified. 

TEME 

EME2000

Yes 

REF_FRAME_EPOCH Epoch of reference frame, if not intrinsic to the 

definition of the reference frame. (See 6.5.9 for 

formatting rules.) 

2001-11-06T11:17:33 

2002-204T15:56:23Z 

No 

TIME_SYSTEM Time system used for the orbit state and 

covariance matrix. Use of values other than those 

in annex A must be documented in an ICD. 

UTC Yes 

MEAN_ELEMENT_THEORY Description of the Mean Element Theory. 

Indicates the proper method to employ to 

propagate the state. 

SGP4 

DSST 

USM 

Yes 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 4-5 November 2009 

4.2.4 OMM DATA 

4.2.4.1 Table 4-3 provides an overview of the five logical blocks in the OMM Data section 

(Mean Keplerian Elements, Spacecraft Parameters, TLE Related Parameters, 

Position/Velocity Covariance Matrix, and User Defined Parameters), and specifies for each 

data item: 

a) the keyword to be used; 

b) a short description of the item; 

c) the units to be used; 

d) whether the item is obligatory or optional. 

4.2.4.2 Only those keywords shown in table 4-3 shall be used in OMM data. 

NOTE – Requirements relating to the keywords in table 4-3 appear after the table. 

Table 4-3: OMM Data 

Keyword Description Units Obligatory

Mean Keplerian Elements in the Specified Reference Frame 

COMMENT (See 6.7 for formatting rules.) n/a No 

EPOCH Epoch of Mean Keplerian elements. (See 6.5.9 for 

formatting rules.) 

n/a Yes 

SEMI_MAJOR_AXIS or 

MEAN_MOTION 

Semi-major axis in kilometers (preferred), or, if 

MEAN_ELEMENT_THEORY = SGP/SGP4, the 

Keplerian Mean motion in revolutions per day 

km 

rev/day 

Yes 

ECCENTRICITY Eccentricity n/a Yes 

INCLINATION Inclination deg Yes 

RA_OF_ASC_NODE Right ascension of ascending node deg Yes 

ARG_OF_PERICENTER Argument of pericenter deg Yes 

MEAN_ANOMALY Mean anomaly deg Yes 

GM Gravitational Coefficient (Gravitational Constant x Central 

Mass) 

km**3/s**2 No 

Spacecraft Parameters 

COMMENT (See 6.7 for formatting rules.) n/a No 

MASS S/C Mass kg No 

SOLAR_RAD_AREA Solar Radiation Pressure Area (AR) m**2 No 

SOLAR_RAD_COEFF Solar Radiation Pressure Coefficient (CR) n/a No 

DRAG_AREA Drag Area (AD) m**2 No 

DRAG_COEFF Drag Coefficient (CD) n/a No 

TLE Related Parameters (This section is only required if MEAN_ELEMENT_THEORY=SGP/SGP4) 

COMMENT (See 6.7 for formatting rules.) n/a No 

EPHEMERIS_TYPE Default value = 0. (See 4.2.4.7.) n/a No 

CLASSIFICATION_TYPE Default value = U. (See 4.2.4.7.) n/a No 

Cor. 1 Cor. 1

CCSDS 502.0-B-2 Cor. 1 May 2012
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 4-6 November 2009 

Keyword Description Units Obligatory

NORAD_CAT_ID NORAD Catalog Number (‘Satellite Number’) an integer 

of up to nine digits. This keyword is only required if 

MEAN_ELEMENT_THEORY=SGP/SGP4. 

n/a No 

ELEMENT_SET_NO Element set number for this satellite. Normally 

incremented sequentially, but may be out of sync if it is 

generated from a backup source. Used to distinguish 

different TLEs, and therefore only meaningful if TLEbased data is being exchanged (i.e., 

MEAN_ELEMENT_THEORY = SGP/SGP4). 

n/a No 

REV_AT_EPOCH Revolution Number n/a No 

BSTAR SGP/SGP4 drag-like coefficient (in units 1/[Earth radii]). 

Only required if MEAN_ELEMENT_THEORY=SGP/SGP4

1/ER No 

MEAN_MOTION_DOT First Time Derivative of the Mean Motion (only required if 

MEAN_ELEMENT_THEORY = SGP) 

rev/day**2 No 

MEAN_MOTION_DDOT Second Time Derivative of Mean Motion (only required if 

MEAN_ELEMENT_THEORY = SGP) 

rev/day**3 No 

Position/Velocity Covariance Matrix (6x6 Lower Triangular Form. None or all parameters of the matrix must be given. 

COV_REF_FRAME may be omitted if it is the same as the metadata REF_FRAME.) 

COMMENT (See 6.7 for formatting rules.) n/a No 

COV_REF_FRAME Reference frame for the covariance matrix. The value 

must be selected from annex A. 

n/a No 

CX_X Covariance matrix [1,1] km**2 No 

CY_X Covariance matrix [2,1] km**2 No 

CY_Y Covariance matrix [2,2] km**2 No 

CZ_X Covariance matrix [3,1] km**2 No 

CZ_Y Covariance matrix [3,2] km**2 No 

CZ_Z Covariance matrix [3,3] km**2 No 

CX_DOT_X Covariance matrix [4,1] km**2/s No 

CX_DOT_Y Covariance matrix [4,2] km**2/s No 

CX_DOT_Z Covariance matrix [4,3] km**2/s No 

CX_DOT_X_DOT Covariance matrix [4,4] km**2/s**2 No 

CY_DOT_X Covariance matrix [5,1] km**2/s No 

CY_DOT_Y Covariance matrix [5,2] km**2/s No 

CY_DOT_Z Covariance matrix [5,3] km**2/s No 

CY_DOT_X_DOT Covariance matrix [5,4] km**2/s**2 No 

CY_DOT_Y_DOT Covariance matrix [5,5] km**2/s**2 No 

CZ_DOT_X Covariance matrix [6,1] km**2/s No 

CZ_DOT_Y Covariance matrix [6,2] km**2/s No 

CZ_DOT_Z Covariance matrix [6,3] km**2/s No 

CZ_DOT_X_DOT Covariance matrix [6,4] km**2/s**2 No 

CZ_DOT_Y_DOT Covariance matrix [6,5] km**2/s**2 No 

CZ_DOT_Z_DOT Covariance matrix [6,6] km**2/s**2 No 

User Defined Parameters (all parameters in this section must be described in an ICD). 

USER_DEFINED_x User defined parameter, where ‘x’ is replaced by a variable 

length user specified character string. Any number of user 

defined parameters may be included, if necessary to 

provide essential information that cannot be conveyed in 

COMMENT statements. Example: 

USER_DEFINED_EARTH_MODEL = WGS-84 

n/a No 

Cor. 1 Cor. 1 Cor. 1

CCSDS 502.0-B-2 Cor. 1 May 2012
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 4-7 November 2009 

4.2.4.3 All values in the OMM are ‘at epoch’, i.e., the value of the parameter at the time 

specified in the EPOCH keyword. 

4.2.4.4 Table 4-3 is broken into five logical blocks, each of which has a descriptive 

heading. These descriptive headings shall not be included in an OMM, unless they appear in 

a properly formatted COMMENT statement. 

4.2.4.5 Values in the covariance matrix shall be expressed in the applicable reference frame 

(COV_REF_FRAME keyword if used, or REF_FRAME keyword if not), and shall be 

presented sequentially from upper left [1,1] to lower right [6,6], lower triangular form, row 

by row left to right. Variance and covariance values shall be expressed in standard double 

precision as related in 6.4. This logical block of the OMM may be useful for risk assessment 

and establishing maneuver and mission margins. 

4.2.4.6 For operations in Earth orbit with a TLE-based OMM, some special conventions 

must be observed, as follows: 

– The value associated with the CENTER_NAME keyword shall be ‘EARTH’. 

– The value associated with the REF_FRAME keyword shall be ‘TEME’ (see annex A). 

– The value associated with the TIME_SYSTEM keyword shall be ‘UTC’. 

– The format of the OBJECT_NAME and OBJECT_ID keywords shall be that of the 

SPACEWARN bulletin (reference [2]). 

– The MEAN_MOTION keyword must be used instead of SEMI_MAJOR_AXIS. 

4.2.4.7 For those who wish to use the OMM to represent a TLE, there are a number of 

considerations that apply with respect to precision of angle representation, use of certain 

fields by the propagator, reference frame, etc. Some sources suggest the coding for the 

EPHEMERIS_TYPE keyword: 1=SGP, 2=SGP4, 3=SDP4, 4=SGP8, 5=SDP8. Some 

sources suggest the following coding for the CLASSIFICATION_TYPE keyword: 

U=unclassified, S=secret. (For further information see references [G3] and [G4].) 

4.2.4.8 Maneuvers are not accommodated in the OMM. Users of the OMM who wish to 

model maneuvers may use several OMM files to describe the orbit at applicable epochs. 

4.2.4.9 A section of User Defined Parameters is allowed. In principle, this provides 

flexibility, but also introduces complexity, non-standardization, potential ambiguity, and 

potential processing errors. Accordingly, if used, the keywords and their meanings must be 

described in an ICD. User Defined Parameters, if included in an OMM, should be used as 

sparingly as possible; their use is not encouraged. 

Cor. 1

CCSDS 502.0-B-2 Cor. 1 May 2012
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 4-8 November 2009 

4.3 OMM EXAMPLES 

Figure 4-2 and figure 4-3 are examples of OMMs based on the TLE shown in figure 4-1. 

GOES 9 [P] 

1 23581U 95025A 07064.44075725 -.00000113 00000-0 10000-3 0 9250 

2 23581 3.0539 81.7939 0005013 249.2363 150.1602 1.00273272 43169 

Figure 4-1: Example Two Line Element Set (TLE) 

CCSDS_OMM_VERS = 2.0 

CREATION_DATE = 2007-065T16:00:00 

ORIGINATOR = NOAA/USA 

OBJECT_NAME = GOES 9 

OBJECT_ID = 1995-025A 

CENTER_NAME = EARTH 

REF_FRAME = TEME 

TIME_SYSTEM = UTC 

MEAN_ELEMENT_THEORY = SGP/SGP4 

EPOCH = 2007-064T10:34:41.4264 

MEAN_MOTION = 1.00273272 

ECCENTRICITY = 0.0005013 

INCLINATION = 3.0539 

RA_OF_ASC_NODE = 81.7939 

ARG_OF_PERICENTER = 249.2363 

MEAN_ANOMALY = 150.1602 

GM = 398600.8 

EPHEMERIS_TYPE = 0 

CLASSIFICATION_TYPE = U 

NORAD_CAT_ID = 23581 

ELEMENT_SET_NO = 0925 

REV_AT_EPOCH = 4316 

BSTAR = 0.0001 

MEAN_MOTION_DOT = -0.00000113 

MEAN_MOTION_DDOT = 0.0 

Figure 4-2: OMM File Example without Covariance Matrix 

Cor. 1

CCSDS 502.0-B-2 Cor. 1 May 2012
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 4-9 November 2009 

CCSDS_OMM_VERS = 2.0 

CREATION_DATE = 2007-065T16:00:00 

ORIGINATOR = NOAA/USA 

OBJECT_NAME = GOES 9 

OBJECT_ID = 1995-025A 

CENTER_NAME = EARTH 

REF_FRAME = TEME 

TIME_SYSTEM = UTC 

MEAN_ELEMENT_THEORY = SGP/SGP4 

EPOCH = 2007-064T10:34:41.4264 

MEAN_MOTION = 1.00273272 

ECCENTRICITY = 0.0005013 

INCLINATION = 3.0539 

RA_OF_ASC_NODE = 81.7939 

ARG_OF_PERICENTER = 249.2363 

MEAN_ANOMALY = 150.1602 

GM = 398600.8 

EPHEMERIS_TYPE = 0 

CLASSIFICATION_TYPE = U 

NORAD_CAT_ID = 23581 

ELEMENT_SET_NO = 0925 

REV_AT_EPOCH = 4316 

BSTAR = 0.0001 

MEAN_MOTION_DOT = -0.00000113 

MEAN_MOTION_DDOT = 0.0 

COV_REF_FRAME = TEME 

CX_X = 3.331349476038534e-04 

CY_X = 4.618927349220216e-04 

CY_Y = 6.782421679971363e-04 

CZ_X = -3.070007847730449e-04 

CZ_Y = -4.221234189514228e-04 

CZ_Z = 3.231931992380369e-04 

CX_DOT_X = -3.349365033922630e-07 

CX_DOT_Y = -4.686084221046758e-07 

CX_DOT_Z = 2.484949578400095e-07 

CX_DOT_X_DOT = 4.296022805587290e-10 

CY_DOT_X = -2.211832501084875e-07 

CY_DOT_Y = -2.864186892102733e-07 

CY_DOT_Z = 1.798098699846038e-07 

CY_DOT_X_DOT = 2.608899201686016e-10 

CY_DOT_Y_DOT = 1.767514756338532e-10 

CZ_DOT_X = -3.041346050686871e-07 

CZ_DOT_Y = -4.989496988610662e-07 

CZ_DOT_Z = 3.540310904497689e-07 

CZ_DOT_X_DOT = 1.869263192954590e-10 

CZ_DOT_Y_DOT = 1.008862586240695e-10 

CZ_DOT_Z_DOT = 6.224444338635500e-10 

Figure 4-3: OMM File Example with Covariance Matrix 

CCSDS 502.0-B-2 Cor. 1 May 2012

Cor. 1 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 4-10 November 2009 

CCSDS_OMM_VERS = 2.0 

CREATION_DATE = 2007-065T16:00:00 

ORIGINATOR = NOAA/USA 

OBJECT_NAME = GOES 9 

OBJECT_ID = 1995-025A 

CENTER_NAME = EARTH 

REF_FRAME = TEME 

TIME_SYSTEM = UTC 

MEAN_ELEMENT_THEORY = SGP/SGP4 

EPOCH = 2007-064T10:34:41.4264 

MEAN_MOTION = 1.00273272 [rev/day] 

ECCENTRICITY = 0.0005013 

INCLINATION = 3.0539 [deg] 

RA_OF_ASC_NODE = 81.7939 [deg] 

ARG_OF_PERICENTER = 249.2363 [deg] 

MEAN_ANOMALY = 150.1602 [deg] 

GM = 398600.8 [km**3/s**2] 

EPHEMERIS_TYPE = 0 

CLASSIFICATION_TYPE = U 

NORAD_CAT_ID = 23581 

ELEMENT_SET_NO = 0925 

REV_AT_EPOCH = 4316 

BSTAR = 0.0001 [1/ER] 

MEAN_MOTION_DOT = -0.00000113 [rev/day**2] 

MEAN_MOTION_DDOT = 0.0 [rev/day**3] 

USER_DEFINED_EARTH_MODEL = WGS-84 

Figure 4-4: OMM with Units and a User Defined Parameter 

CCSDS 502.0-B-2 Cor. 1 May 2012

Cor. 1 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 5-1 November 2009 

5 ORBIT EPHEMERIS MESSAGE (OEM) 

5.1 GENERAL 

5.1.1 Orbit information may be exchanged between two participants by sending an 

ephemeris in the form of a series of state vectors (Cartesian vectors providing position and 

velocity, and optionally accelerations) using an Orbit Ephemeris Message (OEM). The 

message recipient must have a means of interpolating across these state vectors to obtain the 

state at an arbitrary time contained within the span of the ephemeris. 

5.1.2 The OEM may be used for assessing mutual physical or electromagnetic interference 

among Earth-orbiting spacecraft, developing collaborative maneuvers, and representing the 

orbits of active satellites, inactive man made objects, near-Earth debris fragments, etc. The 

OEM reflects the dynamic modeling of any users’ approach to conservative and nonconservative phenomena. 

5.1.3 The OEM shall be a plain text file consisting of orbit data for a single object. It shall 

be easily readable by both humans and computers. 

5.1.4 The OEM file-naming scheme should be agreed to on a case-by-case basis between 

the participants, typically using an ICD. The method of exchanging OEMs should be 

decided on a case-by-case basis by the participants and documented in an ICD. 

NOTE – Detailed syntax rules for the OEM are specified in section 6. 

5.2 OEM CONTENT/STRUCTURE 

5.2.1 GENERAL 

5.2.1.1 The OEM shall be represented as a combination of the following: 

a) a header; 

b) metadata (data about data); 

c) ephemeris data; 

d) optional covariance matrix data; and 

e) optional comments (explanatory information). 

5.2.1.2 OEM files must have a set of minimum required sections; some may be repeated. 

Table 5-1 outlines the contents of an OEM. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 5-2 November 2009 

Table 5-1: OEM File Layout Specifications 

Required 

Sections 

Header 

Metadata 

Ephemeris Data 

(Appropriate comments should also be included, although they are 

not required.) 

Allowable 

Repetitions of 

Sections 

Covariance Matrix (optional) 

Metadata 

Ephemeris Data 

Covariance Matrix (optional) 

Metadata 

Ephemeris Data 

Covariance Matrix (optional) 

Metadata 

Ephemeris Data 

Covariance Matrix (optional) 

...etc. 

(Appropriate comments should also be included.) 

5.2.2 OEM HEADER 

5.2.2.1 The OEM header assignments are shown in table 5-2, which specifies for each 

item: 

a) the keyword to be used; 

b) a short description of the item; 

c) examples of allowed values; and 

d) whether the item is obligatory or optional. 

5.2.2.2 Only those keywords shown in table 5-2 shall be used in an OEM header. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 5-3 November 2009 

Table 5-2: OEM Header 

Keyword Description Examples of Values Obligatory

CCSDS_OEM_VERS Format version in the form of ‘x.y’, where ‘y’ is 

incremented for corrections and minor changes, and ‘x’ 

is incremented for major changes. 

2.0 Yes 

COMMENT Comments (allowed in the OEM Header only 

immediately after the OEM version number). (See 6.7 

for formatting rules.) 

COMMENT See 6.7 No 

CREATION_DATE File creation date and time in UTC. (For format 

specification, see 6.5.9.) 2001-11-06T11:17:33 

2002-204T15:56:23

Yes 

ORIGINATOR Creating agency or operator (value should be specified 

in an ICD). The country of origin should also be 

provided where the originator is not a national space 

agency. 

CNES, ESOC, GSFC, GSOC, 

JPL, JAXA, INTELSAT/USA, 

USAF, INMARSAT/UK

Yes 

5.2.3 OEM METADATA 

5.2.3.1 The OEM metadata assignments are shown in table 5-3, which specifies for each 

item: 

a) the keyword to be used; 

b) a short description of the item; 

c) examples of allowed values; and 

d) whether the item is obligatory or optional. 

5.2.3.2 Only those keywords shown in table 5-3 shall be used in OEM metadata. 

NOTE – For some keywords (OBJECT_NAME, OBJECT_ID, CENTER_NAME) there 

are no definitive lists of authorized values maintained by a control authority; the 

references listed in 1.7 are the best known sources for authorized values to date. 

For the TIME_SYSTEM and REF_FRAME keywords, the approved values are 

listed in annex A. 

5.2.3.3 A single metadata group shall precede each ephemeris data block. Multiple 

occurrences of a metadata group followed by an ephemeris data block may be used. Before 

each metadata group the string ‘META_START’ shall appear on a separate line and after 

each metadata group (and before the associated ephemeris data block) the string 

‘META_STOP’ shall appear on a separate line. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 5-4 November 2009 

Table 5-3: OEM Metadata 

Keyword Description Examples of Values Obligatory

META_START The OEM message contains metadata, 

ephemeris data, and covariance data; this 

keyword is used to delineate the start of a 

metadata block within the message (metadata 

are provided in a block, surrounded by 

‘META_START’ and ‘META_STOP’ markers to 

facilitate file parsing). This keyword must 

appear on a line by itself. 

n/a Yes 

COMMENT Comments allowed only immediately after the 

META_START keyword. (See 6.7 for 

formatting rules.) 

COMMENT This is a comment. No 

OBJECT_NAME The name of the object for which the ephemeris 

is provided. There is no CCSDS-based 

restriction on the value for this keyword, but it 

is recommended to use names from the 

SPACEWARN Bulletin (reference [2]), which 

include Object name and international 

designator of the participant. 

EUTELSAT W1 

MARS PATHFINDER 

STS 106 

NEAR 

Yes 

OBJECT_ID Object identifier of the object for which the 

ephemeris is provided. There is no CCSDSbased restriction on the value for this keyword, 

but it is recommended that values be the 

international spacecraft designator as published 

in the SPACEWARN Bulletin (reference [2]). 

Recommended values have the format YYYYNNNP{PP}, where: 

YYYY = Year of launch. 

NNN = Three-digit serial number of launch 

in year YYYY (with leading zeros). 

P{PP} = At least one capital letter for the 

identification of the part brought 

into space by the launch. 

In cases where the asset is not listed in 

reference [2], or the SPACEWARN format is 

not used, the value should be provided in an 

ICD. 

2000-052A 

1996-068A 

2000-053A 

1996-008A 

Yes 

CENTER_NAME Origin of reference frame, which may be a 

natural solar system body (planets, asteroids, 

comets, and natural satellites), including any 

planet barycenter or the solar system 

barycenter, or another spacecraft (in this case 

the value for ‘CENTER_NAME’ is subject to the 

same rules as for ‘OBJECT_NAME’). There is 

no CCSDS-based restriction on the value for 

this keyword, but for natural bodies it is 

recommended to use names from the 

NASA/JPL Solar System Dynamics Group at 

http://ssd.jpl.nasa.gov (reference [5]). 

EARTH 

EARTH BARYCENTER 

MOON 

SOLAR SYSTEM BARYCENTER 

SUN 

JUPITER BARYCENTER 

STS 106 

EROS

Yes 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 5-5 November 2009 

Keyword Description Examples of Values Obligatory

REF_FRAME Name of the reference frame in which the 

ephemeris data are given. Use of values other 

than those in annex A must be documented in an 

ICD. The reference frame must be the same for 

all data elements, with the exception of the 

covariance matrix, for which an applicable 

different reference frame may be specified.

ICRF 

ITRF-93 

ITRF-97 

ITRF2000 

ITRFxxxx (template for future 

versions)

TOD (True Equator and 

Equinox of Date)

EME2000 (Earth Mean Equator 

and Equinox of J2000) 

TDR (true of date rotating) 

GRC (Greenwich rotating 

coordinate frame, 

another name for TDR) 

Yes 

REF_FRAME_EPOCH Epoch of reference frame, if not intrinsic to the 

definition of the reference frame. (See 6.5.9 for 

formatting rules.) 

2001-11-06T11:17:33 

2002-204T15:56:23Z 

No

TIME_SYSTEM Time system used for metadata, ephemeris data, 

and covariance data. Use of values other than 

those in annex A must be documented in an ICD.

UTC, TAI, TT, GPS, TDB, 

TCB 

Yes 

START_TIME Start of TOTAL time span covered by 

ephemeris data and covariance data 

immediately following this metadata block. 

(For format specification, see 6.5.9.) 

1996-12-18T14:28:15.1172 

1996-277T07:22:54

Yes 

USEABLE_START_TIME 

USEABLE_STOP_TIME 

Optional start and end of USEABLE time span 

covered by ephemeris data immediately 

following this metadata block. To allow for 

proper interpolation near the ends of the 

ephemeris data block it may be necessary, 

depending upon the interpolation method to be 

used, to utilize these keywords with values 

within the time span covered by the ephemeris 

data records as denoted by the 

START/STOP_TIME time tags. (For format 

specification, see 6.5.9.) These keywords are 

optional items, and thus may not be necessary, 

depending on the recommended interpolation 

method. However, it is recommended to use 

the USEABLE_START_TIME and 

USEABLE_STOP_TIME capability in all 

cases. The USEABLE_START_TIME time tag 

at a new block of ephemeris data must be 

greater than or equal to the 

USEABLE_STOP_TIME time tag of the 

previous block. 

1996-12-18T14:28:15.1172 

1996-277T07:22:54

No 

STOP_TIME End of TOTAL time span covered by 

ephemeris data and covariance data 

immediately following this metadata block. 

(For format specification, see 6.5.9.) 

1996-12-18T14:28:15.1172 

1996-277T07:22:54

Yes 

INTERPOLATION This keyword may be used to specify the 

recommended interpolation method for 

ephemeris data in the immediately following 

set of ephemeris lines. 

Hermite 

Linear 

Lagrange 

No 

Cor. 1 Cor. 1 Cor. 1

CCSDS 502.0-B-2 Cor. 1 May 2012
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 5-6 November 2009 

Keyword Description Examples of Values Obligatory

INTERPOLATION_DEGREE Recommended interpolation degree for 

ephemeris data in the immediately following 

set of ephemeris lines. Must be an integer 

value. This keyword must be used if the 

‘INTERPOLATION’ keyword is used. 

5 

1 

No 

META_STOP The OEM message contains metadata, 

ephemeris data, and covariance data; this 

keyword is used to delineate the end of a 

metadata block within the message (metadata 

are provided in a block, surrounded by 

‘META_START’ and ‘META_STOP’ markers to 

facilitate file parsing). This keyword must 

appear on a line by itself. 

n/a Yes 

5.2.4 OEM DATA: EPHEMERIS DATA LINES 

5.2.4.1 Each set of ephemeris data, including the time tag, must be provided on a single 

line. The order in which data items are given shall be fixed: Epoch, X, Y, Z, X_DOT, 

Y_DOT, Z_DOT, X_DDOT, Y_DDOT, Z_DDOT. 

5.2.4.2 The position and velocity terms shall be obligatory; acceleration terms may be 

provided. 

5.2.4.3 At least one space character must be used to separate the items in each ephemeris 

data line. 

5.2.4.4 Repeated time tags may occur in consecutive ephemeris data blocks if the 

STOP_TIME of the first ephemeris data block is greater than the START_TIME of the 

second ephemeris data block. Although the USEABLE_STOP_TIME and 

USEABLE_START_TIME of the consecutive ephemeris data blocks must not overlap 

(except for a possibly shared endpoint), the STOP_TIME of the first ephemeris data block 

may be greater than the START_TIME of the second ephemeris data block if the extra data 

is required for interpolation purposes. 

5.2.4.5 The TIME_SYSTEM value must remain fixed within an OEM. 

5.2.4.6 The occurrence of a second (or greater) metadata block after some ephemeris data 

indicates that interpolation using succeeding ephemeris data with ephemeris data occurring 

prior to that metadata block shall not be done. This method may be used for proper modeling 

of propulsive maneuvers or any other source of a discontinuity such as eclipse entry or exit. 

5.2.4.7 Details about interpolation method should be specified using the 

INTERPOLATION and INTERPOLATION_DEGREE keywords within the OEM. All data 

blocks must contain a sufficient number of ephemeris data records to allow the recommended 

interpolation method to be carried out consistently throughout the OEM. 

Cor. 1

CCSDS 502.0-B-2 Cor. 1 May 2012
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 5-7 November 2009 

5.2.5 OEM DATA: COVARIANCE MATRIX LINES 

5.2.5.1 A single covariance matrix data section may optionally follow each ephemeris data 

block. 

5.2.5.2 If present, the covariance matrix data lines in the OEM are separated from the 

ephemeris data by means of two new keywords: COVARIANCE_START and 

COVARIANCE_STOP. The ‘COVARIANCE_START’ keyword must appear before the 

first line of the covariance matrix data. The ‘COVARIANCE_STOP’ keyword must appear 

after the last line of covariance data. Each of these keywords shall appear on a line by itself 

with no time tags or values. 

5.2.5.3 The epoch of the navigation solution related to the covariance matrix must be 

provided via the ‘EPOCH’ keyword. The reference frame of the covariance matrix, if 

different from that of the states in the ephemeris, must be provided via the 

‘COV_REF_FRAME’ keyword. 

5.2.5.4 Each row of the 6x6 lower triangular covariance matrix must be provided on a 

single line. The order in which data items are given shall be fixed. The elements in each 

row of covariates shall be defined by the order in the ephemeris data line (i.e., X, Y, Z, 

X_DOT, Y_DOT, Z_DOT). The six rows of the covariance matrix contain from one to six 

numbers depending on what row of the matrix is being represented (first row has one 

element, second row has two, continuing in this fashion until the sixth row has six elements). 

5.2.5.5 At least one space character must be used to separate the items in each covariance 

matrix data line. 

5.2.5.6 Multiple covariance matrices may appear in the covariance matrix section; they 

may appear with any desired frequency (one for each navigation solution that makes up the 

overall ephemeris is recommended). The OEM may also contain propagated covariances, 

not just individual covariances associated with navigation solutions. 

5.2.5.7 If there are multiple covariance matrices in the data section, they must be ordered 

by increasing time tag. 

5.3 OEM EXAMPLES 

Figure 5-1, figure 5-2, and figure 5-3 are example OEMs. Some ephemeris data lines have 

been omitted to save space. 

Figure 5-1 is compatible with ODM version 1, and thus could use either 

‘CCSDS_OEM_VERS = 1.0’ (since it does not contain any of the unique features of the 

ODM version 2), or ‘CCSDS_OEM_VERS = 2.0’ (as shown). Figure 5-2 and figure 5-3 

contain features unique to the ODM version 2, and thus ‘CCSDS_OEM_VERS = 2.0’ must 

be specified. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 5-8 November 2009 

CCSDS_OEM_VERS = 2.0 

CREATION_DATE = 1996-11-04T17:22:31 

ORIGINATOR = NASA/JPL 

META_START 

OBJECT_NAME = MARS GLOBAL SURVEYOR 

OBJECT_ID = 1996-062A 

CENTER_NAME = MARS BARYCENTER 

REF_FRAME = EME2000 

TIME_SYSTEM = UTC 

START_TIME = 1996-12-18T12:00:00.331 

USEABLE_START_TIME = 1996-12-18T12:10:00.331 

USEABLE_STOP_TIME = 1996-12-28T21:23:00.331 

STOP_TIME = 1996-12-28T21:28:00.331 

INTERPOLATION = HERMITE 

INTERPOLATION_DEGREE = 7 

META_STOP 

COMMENT This file was produced by M.R. Somebody, MSOO NAV/JPL, 1996NOV 04. It is 

COMMENT to be used for DSN scheduling purposes only. 

1996-12-18T12:00:00.331 2789.619 -280.045 -1746.755 4.73372 -2.49586 -1.04195 

1996-12-18T12:01:00.331 2783.419 -308.143 -1877.071 5.18604 -2.42124 -1.99608 

1996-12-18T12:02:00.331 2776.033 -336.859 -2008.682 5.63678 -2.33951 -1.94687 

 < intervening data records omitted here > 

1996-12-28T21:28:00.331 -3881.024 563.959 -682.773 -3.28827 -3.66735 1.63861 

META_START 

OBJECT_NAME = MARS GLOBAL SURVEYOR 

OBJECT_ID = 1996-062A 

CENTER_NAME = MARS BARYCENTER 

REF_FRAME = EME2000 

TIME_SYSTEM = UTC 

START_TIME = 1996-12-28T21:29:07.267 

USEABLE_START_TIME = 1996-12-28T22:08:02.5 

USEABLE_STOP_TIME = 1996-12-30T01:18:02.5 

STOP_TIME = 1996-12-30T01:28:02.267 

INTERPOLATION = HERMITE 

INTERPOLATION_DEGREE = 7 

META_STOP 

COMMENT This block begins after trajectory correction maneuver TCM-3. 

1996-12-28T21:29:07.267 -2432.166 -063.042 1742.754 7.33702 -3.495867 -1.041945 

1996-12-28T21:59:02.267 -2445.234 -878.141 1873.073 1.86043 -3.421256 -0.996366 

1996-12-28T22:00:02.267 -2458.079 -683.858 2007.684 6.36786 -3.339563 -0.946654 

 < intervening data records omitted here > 

1996-12-30T01:28:02.267 2164.375 1115.811 -688.131 -3.53328 -2.88452 0.88535 

Figure 5-1: Version 1 OEM Compatible Example (No Acceleration, No Covariance) 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 5-9 November 2009 

CCSDS_OEM_VERS = 2.0 

COMMENT OEM WITH OPTIONAL ACCELERATIONS MUST BE OEM VERSION 2.0 

CREATION_DATE = 1996-11-04T17:22:31 

ORIGINATOR = NASA/JPL 

META_START 

OBJECT_NAME = MARS GLOBAL SURVEYOR 

OBJECT_ID = 1996-062A 

CENTER_NAME = MARS BARYCENTER 

REF_FRAME = EME2000 

TIME_SYSTEM = UTC 

START_TIME = 1996-12-18T12:00:00.331 

USEABLE_START_TIME = 1996-12-18T12:10:00.331 

USEABLE_STOP_TIME = 1996-12-28T21:23:00.331 

STOP_TIME = 1996-12-28T21:28:00.331 

INTERPOLATION = HERMITE 

INTERPOLATION_DEGREE = 7 

META_STOP 

COMMENT This file was produced by M.R. Somebody, MSOO NAV/JPL, 2000 NOV 04. It is 

COMMENT to be used for DSN scheduling purposes only. 

1996-12-18T12:00:00.331 2789.6 -280.0 -1746.8 4.73 -2.50 -1.04 0.008 0.001 -0.159 

1996-12-18T12:01:00.331 2783.4 -308.1 -1877.1 5.19 -2.42 -2.00 0.008 0.001 0.001 

1996-12-18T12:02:00.331 2776.0 -336.9 -2008.7 5.64 -2.34 -1.95 0.008 0.001 0.159 

 < intervening data records omitted here > 

1996-12-28T21:28:00.331 -3881.0 564.0 -682.8 -3.29 -3.67 1.64 -0.003 0.000 0.000 

Figure 5-2: Version 2 OEM Example with Optional Accelerations 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 5-10 November 2009 

CCSDS_OEM_VERS = 2.0 

CREATION_DATE = 1996-11-04T17:22:31 

ORIGINATOR = NASA/JPL 

META_START 

OBJECT_NAME = MARS GLOBAL SURVEYOR 

OBJECT_ID = 1996-062A 

CENTER_NAME = MARS BARYCENTER 

REF_FRAME = EME2000 

TIME_SYSTEM = UTC 

START_TIME = 1996-12-28T21:29:07.267 

USEABLE_START_TIME = 1996-12-28T22:08:02.5 

USEABLE_STOP_TIME = 1996-12-30T01:18:02.5 

STOP_TIME = 1996-12-30T01:28:02.267 

INTERPOLATION = HERMITE 

INTERPOLATION_DEGREE = 7 

META_STOP 

COMMENT This block begins after trajectory correction maneuver TCM-3. 

1996-12-28T21:29:07.267 -2432.166 -063.042 1742.754 7.33702 -3.495867 -1.041945 

1996-12-28T21:59:02.267 -2445.234 -878.141 1873.073 1.86043 -3.421256 -0.996366 

1996-12-28T22:00:02.267 -2458.079 -683.858 2007.684 6.36786 -3.339563 -0.946654 

 < intervening data records omitted here > 

1996-12-30T01:28:02.267 2164.375 1115.811 -688.131 -3.53328 -2.88452 0.88535 

COVARIANCE_START 

EPOCH = 1996-12-28T21:29:07.267 

COV_REF_FRAME = EME2000 

 3.3313494e-04 

 4.6189273e-04 6.7824216e-04 

-3.0700078e-04 -4.2212341e-04 3.2319319e-04 

-3.3493650e-07 -4.6860842e-07 2.4849495e-07 4.2960228e-10 

-2.2118325e-07 -2.8641868e-07 1.7980986e-07 2.6088992e-10 1.7675147e-10 

-3.0413460e-07 -4.9894969e-07 3.5403109e-07 1.8692631e-10 1.0088625e-10 6.2244443e-10 

EPOCH = 1996-12-29T21:00:00 

COV_REF_FRAME = EME2000 

 3.4424505e-04 

 4.5078162e-04 6.8935327e-04 

-3.0600067e-04 -4.1101230e-04 3.3420420e-04 

-3.2382549e-07 -4.5750731e-07 2.3738384e-07 4.3071339e-10 

-2.1007214e-07 -2.7530757e-07 1.6870875e-07 2.5077881e-10 1.8786258e-10 

-3.0302350e-07 -4.8783858e-07 3.4302008e-07 1.7581520e-10 1.0077514e-10 6.2244443e-10 

COVARIANCE_STOP 

Figure 5-3: Version 2 OEM Example with Optional Covariance Matrices 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 6-1 November 2009 

6 ORBIT DATA MESSAGE SYNTAX 

6.1 OVERVIEW 

This section details the syntax requirements for each of the Orbit Data Messages. 

6.2 GENERAL 

The Orbit Data Messages (OPM, OMM, OEM) shall observe the syntax described in 6.2 

through 6.7. 

6.3 ODM LINES 

6.3.1 Each ODM file shall consist of a set of OPM, OMM, or OEM lines. Each ODM line 

shall be one of the following: 

– Header line; 

– Metadata line; 

– Data line; or 

– Blank line. 

6.3.2 Each OEM, OPM, or OMM line must not exceed 254 ASCII characters and spaces 

(excluding line termination character[s]). 

6.3.3 Only printable ASCII characters and blanks shall be used. Control characters (such 

as TAB, etc.) shall not be used, with the exception of the line termination characters 

specified below. 

6.3.4 Blank lines may be used at any position within the file. Blank lines shall have no 

assignable meaning, and may be ignored. 

6.3.5 The first header line must be the first non-blank line in the file. 

6.3.6 All lines shall be terminated by a single Carriage Return or a single Line Feed, or a 

Carriage Return/Line Feed pair or a Line Feed/Carriage Return pair. 

6.4 KEYWORD = VALUE NOTATION AND ORDER OF ASSIGNMENT 

STATEMENTS 

6.4.1 For the OPM and OMM, all header, metadata, and data lines shall use ‘keyword = 

value’ notation, abbreviated as KVN. 

6.4.1.1 For the OEM, all header and metadata elements shall use KVN notation. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 6-2 November 2009 

6.4.1.2 OEM ephemeris data lines shall not use KVN format; rather, the OEM ephemeris 

data line has a fixed structure containing seven required fields (epoch time, three position 

components, three velocity components), and three optional acceleration components. 

(See 5.2.4.) 

6.4.1.3 OEM covariance matrix epoch and covariance reference frame (if used) shall use 

KVN format. The OEM covariance data lines shall not use KVN format; rather, the OEM 

covariance data line has a fixed structure containing from one to six required fields (a row 

from the 6x6 lower triangular form covariance matrix). (See 5.2.5.) 

6.4.2 The keywords ‘COMMENT’, ‘META_START’, ‘META_STOP’, 

‘COVARIANCE_START’, and ‘COVARIANCE_STOP’ are exceptions to the KVN syntax 

assignment. 

6.4.3 Only a single ‘keyword = value’ assignment shall be made on a line. 

6.4.4 Keywords must be uppercase and must not contain blanks. 

6.4.5 Any white space immediately preceding or following the keyword shall not be 

significant. 

6.4.6 Any white space immediately preceding or following the ‘equals’ sign shall not be 

significant. 

6.4.7 Any white space immediately preceding the end of line shall not be significant. 

6.4.8 The order of occurrence of obligatory and optional KVN assignments shall be fixed 

as shown in the tables in sections 3, 4, and 5 that describe the OPM, OMM, and OEM 

keywords. 

6.5 VALUES 

6.5.1 A non-empty value field must be specified for each obligatory keyword. 

6.5.2 Integer values shall consist of a sequence of decimal digits with an optional leading 

sign (‘+’ or ‘-’). If the sign is omitted, ‘+’ shall be assumed. Leading zeroes may be used. 

The range of values that may be expressed as an integer is: 

-2,147,483,648 <= x <= +2,147,483,647 (i.e., -231 <= x <= 231-1). 

6.5.3 Non-integer numeric values may be expressed in either fixed-point or floating-point 

notation. Both representations may be used within an OPM, OMM, or OEM. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 6-3 November 2009 

6.5.4 Non-integer numeric values expressed in fixed-point notation shall consist of a 

sequence of decimal digits separated by a period as a decimal point indicator, with an 

optional leading sign (‘+’ or ‘-’). If the sign is omitted, ‘+’ shall be assumed. Leading and 

trailing zeroes may be used. At least one digit shall appear before and after a decimal point. 

The number of digits shall be 16 or fewer. 

6.5.5 Non-integer numeric values expressed in floating point notation shall consist of a 

sign, a mantissa, an alphabetic character indicating the division between the mantissa and 

exponent, and an exponent, constructed according to the following rules: 

a) The sign may be ‘+’ or ‘-’. If the sign is omitted, ‘+’ shall be assumed. 

b) The mantissa must be a string of no more than 16 decimal digits with a decimal point 

(‘.’) in the second position of the ASCII string, separating the integer portion of the 

mantissa from the fractional part of the mantissa. 

c) The character used to denote exponentiation shall be ‘E’ or ‘e’. If the character 

indicating the exponent and the following exponent are omitted, an exponent value of 

zero shall be assumed (essentially yielding a fixed point value). 

d) The exponent must be an integer, and may have either a ‘+’ or ‘-’ sign (if the sign is 

omitted, then ‘+’ shall be assumed). 

e) The maximum positive floating point value is approximately 1.798E+308, with 16 

significant decimal digits precision. The minimum positive floating point value is 

approximately 4.94E-324, with 16 significant decimal digits precision. 

NOTE – These specifications for integer, fixed point and floating point values 

conform to the XML specifications for the data types four-byte integer 

‘xsd:int’, ‘decimal’, and ‘double’, respectively (reference [6]). The 

specifications for floating point values conform to the IEEE double precision 

type (references [6] and [7]). Floating point numbers in IEEE extendedsingle or IEEE extended-double precision may be represented, but do require 

an ICD between exchange partners because of their implementation-specific 

attributes (reference [7]). The special values ‘NaN’, ‘-Inf’, ‘+Inf’, and ‘-0’ 

are not supported in the ODM. 

6.5.6 Text value fields must be constructed using only all uppercase or all lowercase. 

6.5.7 Blanks shall not be permitted within numeric values and time strings. 

6.5.8 In value fields that are text, an underscore shall be equivalent to a single blank. 

Individual blanks shall be retained (shall be significant), but multiple contiguous blanks shall 

be equivalent to a single blank. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 6-4 November 2009 

6.5.9 In value fields that represent a time tag or epoch, times shall be given in one of the 

following two formats: 

YYYY-MM-DDThh:mm:ss[.d→d][Z] 

or 

YYYY-DDDThh:mm:ss[.d→d][Z] 

where ‘YYYY’ is the year, ‘MM’ is the two-digit month, ‘DD’ is the two-digit day, ‘DDD’ 

is the three-digit day of year, ‘T’ is constant, ‘hh:mm:ss[.d→d]’ is the time in hours, minutes 

seconds, and optional fractional seconds; ‘Z’ is an optional time code terminator (the only 

permitted value is ‘Z’ for Zulu, i.e., UTC). As many ‘d’ characters to the right of the period 

as required may be used to obtain the required precision, up to the maximum allowed for a 

fixed point number. All fields shall have leading zeros. (See reference [1], ASCII Time 

Code A or B.) 

6.5.10 There are eight types of ODM values that represent a time tag or epoch, as shown in 

the applicable tables. The time system for the CREATION_DATE shall be UTC; the time 

system for the EPOCH, REF_FRAME_EPOCH, MAN_EPOCH_IGNITION, 

START_TIME, USEABLE_START_TIME, USEABLE_STOP_TIME, STOP_TIME, and 

the covariance matrix epoch time shall be as determined by the TIME_SYSTEM metadata 

keyword. 

6.6 UNITS IN THE ORBIT DATA MESSAGES 

6.6.1 OPM/OMM UNITS 

6.6.1.1 For documentation purposes and clarity, units may be included as ASCII text after a 

value in the OPM and OMM. If units are displayed, they must exactly match the units 

specified in table 3-3 and table 4-3 (including case). If units are displayed, then: 

a) there must be at least one blank character between the value and the units text; 

b) the units must be enclosed within square brackets (e.g., ‘[km]’); 

c) exponents of units shall be denoted with a double asterisk (i.e., ‘**’, for example, 

m/s2

=m/s**2). 

6.6.1.2 Some of the items in the applicable tables are dimensionless. The table shows a 

unit value of ‘n/a’, which in this case means that there is no applicable units designator for 

these items (e.g., for ECCENTRICITY). The notation ‘[n/a]’ should not appear in an OPM 

or OMM. 

Cor. 1

CCSDS 502.0-B-2 Cor. 1 May 2012
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 6-5 November 2009 

6.6.2 OEM UNITS 

6.6.2.1 In an OEM ephemeris data line, units shall be km, km/s, and km/s**2 for position, 

velocity, and acceleration components, respectively, but the units shall not be displayed. 

6.6.2.2 In an OEM covariance matrix line, units shall be km**2, km**2/s, or km**2/s**2 

depending on whether the element is computed from two position components, one position 

component and one velocity component, or two velocity components. The units shall not be 

displayed. 

6.7 COMMENTS IN THE ORBIT DATA MESSAGES 

6.7.1 There are certain pieces of information that provide clarity and remove ambiguity 

about the interpretation of the information in a file, yet are not standardized so as to fit 

cleanly into the ‘keyword = value’ paradigm. Rather than force the information to fit into a 

space limited to one line, the ODM producer should put certain information into comments 

and use the ICD to provide further specifications. 

6.7.2 Comments may be used to provide provenance information or to help describe 

dynamical events or other pertinent information associated with the data. This additional 

information is intended to aid in consistency checks and elaboration where needed, but shall 

not be required for successful processing of a file. 

6.7.3 For the OPM, OMM, and OEM, comment lines shall be optional. 

6.7.4 All comment lines shall begin with the ‘COMMENT’ keyword followed by at least one 

space. This keyword must appear on every comment line, not just the first such line. The 

remainder of the line shall be the comment value. White space shall be retained (shall be 

significant) in comment values. 

6.7.5 Placement of comments shall be as specified in the tables in sections 3, 4, and 5 that 

describe the OPM, OMM and OEM keywords. 

6.7.6 Comments in the OPM may appear in the OPM Header immediately after the 

‘CCSDS_OPM_VERS’ keyword, at the very beginning of the OPM Metadata section, and at 

the beginning of a logical block in the OPM Data section. Comments must not appear 

between the components of any logical block in the OPM Data section. 

NOTE – The logical blocks in the OPM Data section are indicated in table 3-3. 

6.7.7 Comments in the OMM may appear in the OMM Header immediately after the 

‘CCSDS_OMM_VERS’ keyword, at the very beginning of the OMM Metadata section, and 

at the beginning of a logical block in the OMM Data section. Comments must not appear 

between the components of any logical block in the OMM Data section. 

NOTE – The logical blocks in the OMM Data section are indicated in table 4-3. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 6-6 November 2009 

6.7.8 Comments in the OEM may appear in the OEM Header immediately after the 

‘CCSDS_OEM_VERS’ keyword, at the very beginning of the OEM Metadata section (after 

the ‘META_START’ keyword), at the beginning of the OEM Ephemeris Data Section, and 

at the beginning of the OEM Covariance Data section (after the ‘COVARIANCE_START’ 

keyword). Comment lines must not appear within any block of ephemeris lines or 

covariance matrix lines. 

6.7.9 Extensive comments in an ODM are recommended in cases where there is 

insufficient time to negotiate an ICD. (For an example ‘Checklist ICD’, see annex D.) 

6.7.10 The following comments should be provided: 

a) Information regarding the genesis, history, interpretation, intended use, etc., of the 

state vector, spacecraft, maneuver, or ephemeris that may be of use to the receiver of 

the OPM, OMM, or OEM: 

COMMENT Source: File created by JPL Multi-Mission Navigation Team as part 

COMMENT of Launch Operations Readiness Test held on 20 April 2001. 

b) Natural body ephemeris information: When the Earth is not the center of motion, the 

ephemerides of the planets, satellites, asteroids, and/or comets (including associated 

constants) consistent with the ODM should be identified so that the recipient can, in a 

consistent manner, make computations involving other centers: 

COMMENT Based on latest orbit solution which includes observations 

COMMENT through 2000-May-15 relative to planetary ephemeris DE-0405. 

c) OEM accuracy vs. efficiency: If the covariance data section of the OEM is not 

utilized, the producer of an OEM should report in comment lines what the expected 

accuracy of the ephemeris is, so the user can smooth or otherwise compress the data 

without affecting the accuracy of the trajectory. The OEM producer also should 

strive to achieve not only the best accuracy possible, taking into account prediction 

errors, but also consider the efficiency of the trajectory representation (e.g., step sizes 

of fractional seconds between ephemeris lines may be necessary for precision 

scientific reconstruction of an orbit, but are excessive from the standpoint of antenna 

pointing predicts generation). 

6.8 ORBIT DATA MESSAGE KEYWORDS 

6.8.1 VERSION KEYWORDS 

The Header of the OPM, OMM, and OEM shall provide a CCSDS Orbit Data Message 

version number that identifies the format version; this is included to anticipate future 

changes. The version keywords for the OPM, OMM, and OEM shall be 

CCSDS_OPM_VERS, CCSDS_OMM_VERS, and CCSDS_OEM_VERS, respectively. The 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 6-7 November 2009 

value shall have the form of ‘x.y’, where ‘y’ shall be incremented for corrections and minor 

changes, and ‘x’ shall be incremented for major changes. Version x.0 shall be reserved for 

versions accepted by the CCSDS as an official Recommended Standard (‘Blue Book’). 

Testing shall be conducted using OPM, OMM, and OEM version numbers less than 1.0 (e.g., 

0.x). Exchange participants should specify in the ICD the specific OPM, OMM, and OEM 

version numbers they will support. The following version numbers are supported: 

Version Keyword Version Number Applicable 

Recommendation 

CCSDS_OPM_VERS 1.0 Silver Book 1.0, 

09/2004 

CCSDS_OPM_VERS 2.0 Blue Book 2.0 (this 

document) 

CCSDS_OMM_VERS 2.0 Blue Book 2.0 (this 

document) 

CCSDS_OEM_VERS 1.0 Silver Book 1.0, 

09/2004 

CCSDS_OEM_VERS 2.0 Blue Book 2.0 (this 

document) 

6.8.2 GENERAL KEYWORDS 

6.8.2.1 Only those keywords shown in table 3-1, table 3-2, and table 3-3 shall be used in an 

OPM. Some keywords represent obligatory items and some are optional. KVN assignments 

representing optional items may be omitted. 

6.8.2.2 Only those keywords shown in table 4-1, table 4-2, and table 4-3 shall be used in an 

OMM. Some keywords represent obligatory items and some are optional. KVN assignments 

representing optional items may be omitted. 

6.8.2.3 Only those keywords shown in table 5-2 and table 5-3 shall be used in an OEM. 

Some keywords represent obligatory items and some are optional. KVN assignments 

representing optional items may be omitted. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 7-1 November 2009 

7 SECURITY 

7.1 OVERVIEW 

This section presents the results of an analysis of security considerations applied to the 

technologies specified in this Recommended Standard. 

7.2 SECURITY CONCERNS RELATED TO THIS RECOMMENDED STANDARD 

7.2.1 DATA PRIVACY 

Privacy of data formatted in compliance with the specifications of this Recommended 

Standard should be assured by the systems and networks on which this Recommended 

Standard is implemented. 

7.2.2 DATA INTEGRITY 

Integrity of data formatted in compliance with the specifications of this Recommended 

Standard should be assured by the systems and networks on which this Recommended 

Standard is implemented. 

7.2.3 AUTHENTICATION OF COMMUNICATING ENTITIES 

Authentication of communicating entities involved in the transport of data which complies 

with the specifications of this Recommended Standard should be provided by the systems 

and networks on which this Recommended Standard is implemented. 

7.2.4 DATA TRANSFER BETWEEN COMMUNICATING ENTITIES 

The transfer of data formatted in compliance with this Recommended Standard between 

communicating entities should be accomplished via secure mechanisms approved by the IT 

Security functionaries of exchange participants. 

7.2.5 CONTROL OF ACCESS TO RESOURCES 

This Recommended Standard assumes that control of access to resources will be managed by 

the systems upon which provider formatting and recipient processing are performed. 

7.2.6 AUDITING OF RESOURCE USAGE 

This Recommended Standard assumes that auditing of resource usage will be handled by the 

management of systems and networks on which this Recommended Standard is 

implemented. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page 7-2 November 2009 

7.3 POTENTIAL THREATS AND ATTACK SCENARIOS 

Potential threats or attack scenarios include, but are not limited to, (a) unauthorized access to 

the programs/processes that generate and interpret the messages, and (b) unauthorized access 

to the messages during transmission between exchange partners. Unauthorized access to the 

programs/processes that generate and interpret the messages should be prohibited. Protection 

from unauthorized access during transmission is especially important if the mission utilizes 

open ground networks such as the Internet to provide ground station connectivity for the 

exchange of data formatted in compliance with this Recommended Standard. It is strongly 

recommended that potential threats or attack scenarios applicable to the systems and 

networks on which this Recommended Standard is implemented be addressed by the 

management of those systems and networks. 

7.4 CONSEQUENCES OF NOT APPLYING SECURITY TO THE TECHNOLOGY 

The consequences of not applying security to the systems and networks on which this 

Recommended Standard is implemented could include potential loss, corruption, and theft of 

data. Because these messages are used in preparing pointing and frequency predicts used 

during spacecraft commanding, and may also be used in collision avoidance studies, the 

consequences of not applying security to the systems and networks on which this 

Recommended Standard is implemented could include compromise or loss of the mission if 

malicious tampering of a particularly severe nature occurs. 

7.5 DATA SECURITY IMPLEMENTATION SPECIFICS 

Specific information-security interoperability provisions that may apply between agencies 

and other independent users involved in an exchange of data formatted in compliance with 

this Recommended Standard should be specified in an ICD. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page A-1 November 2009 

ANNEX A

VALUES FOR TIME_SYSTEM AND FRAME RELATED KEYWORDS 

(NORMATIVE) 

The values in this annex represent the set of acceptable values for the TIME_SYSTEM, 

REF_FRAME, MAN_REF_FRAME, and COV_REF_FRAME keywords in the OPM, 

OMM, and OEM. (For details and description of these time systems, see reference [G1].) If 

exchange partners wish to use different settings, the settings should be documented in the 

ICD. 

A1 TIME_SYSTEM METADATA KEYWORD 

Time System Value Meaning 

GMST Greenwich Mean Sidereal Time 

GPS Global Positioning System 

MET Mission Elapsed Time (note) 

MRT Mission Relative Time (note)

SCLK Spacecraft Clock (receiver) (requires rules for interpretation in ICD)

TAI International Atomic Time 

TCB Barycentric Coordinate Time 

TDB Barycentric Dynamical Time 

TCG Geocentric Coordinate Time 

TT Terrestrial Time 

UT1 Universal Time 

UTC Coordinated Universal Time 

If MET or MRT is chosen as the TIME_SYSTEM, then the epoch of either the start of the 

mission for MRT, or of the event for MET, should either be given in a comment in the 

message or provided in an ICD. The time system for the start of the mission or the event 

should also be provided in the comment or the ICD. If these values are used for the 

TIME_SYSTEM, then the times given in the file denote a duration from the mission start or 

event. However, for clarity, an ICD should be used to fully specify the interpretation of the 

times if these values are to be used. The time format should only utilize three digit days from 

the MET or MRT epoch, not months and days of the months. 

Cor. 1 

CCSDS 502.0-B-2 Cor. 1 May 2012

Cor. 1 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page A-2 November 2009 

A2 REF_FRAME KEYWORD 

Reference Frame 

Value 

Meaning 

EME2000 Earth Mean Equator and Equinox of J2000 

GCRF Geocentric Celestial Reference Frame 

GRC Greenwich Rotating Coordinates 

ICRF International Celestial Reference Frame 

ITRF2000 International Terrestrial Reference Frame 2000 

ITRF-93 International Terrestrial Reference Frame 1993 

ITRF-97 International Terrestrial Reference Frame 1997 

MCI Mars Centered Inertial 

TDR True of Date, Rotating 

TEME True Equator Mean Equinox (see below) 

TOD True of Date 

NORAD Two Line Element Sets are implicitly in a True Equator Mean Equinox (TEME) 

reference frame, which is ill defined in international standard or convention. TEME may be 

used only for OMMs based on NORAD Two Line Element sets, and in no other 

circumstances. There are subtle differences between TEME of Epoch and TEME of Date 

(see reference [G3] or [G4]). The effect is very small relative to TLE accuracy, and there is 

uncertainty regarding which of these is used by NORAD. The preferred option is TEME of 

Date. Users should specify in the ICD if their assumption is TEME of Epoch. 

A3 MAN_REF_FRAME AND COV_REF_FRAME KEYWORDS 

Reference Frame 

Value 

Meaning 

RSW Another name for ‘Radial, Transverse, Normal’ 

RTN Radial, Transverse, Normal 

TNW A local orbital coordinate frame that has the x-axis along the 

velocity vector, W along the orbital angular momentum vector, and 

N completes the right handed system. 

1

CCSDS 502.0-B-2 Cor. 1 May 2012

Cor. 1 Cor. 1
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page B-1 November 2009 

ANNEX B

ABBREVIATIONS AND ACRONYMS 

(INFORMATIVE) 

ASCII American Standard Code for Information Interchange 

CCSDS Consultative Committee for Space Data Systems 

DSST Draper Semi-Analytic Satellite Theory 

ECI Earth Centered Inertial 

EGM Earth Gravitational Model, Earth Geopotential Model 

EME2000 Earth Mean Equator and Equinox of J2000 (Julian Date 2000) 

EOP Earth Orientation Parameters 

GCRF Geocentric Celestial Reference Frame 

GPS Global Positioning System 

IAU International Astronomical Union 

ICD Interface Control Document 

ICRF International Celestial Reference Frame 

IEC International Electrotechnical Commission 

IERS International Earth Rotation and Reference Systems Service 

IIRV Improved Inter-Range Vector 

ISO International Standards Organization 

ITRF International Terrestrial Reference Frame 

ITRS International Terrestrial Reference System 

GRC Greenwich Rotating Coordinate Frame 

KVN Keyword = Value Notation 

NORAD North American Aerospace Defense Command 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page B-2 November 2009 

OD Orbit Determination 

ODM Orbit Data Message 

OEM Orbit Ephemeris Message 

OMM Orbit Mean-Elements Message 

OPM Orbit Parameter Message 

RTN Radial, Transverse (along-track) and Normal 

SGP4 US Air Force Simplified General Perturbations No. 4 

SPK Satellite, Planetary Kernel 

TAI International Atomic Time 

TCB Barycentric Coordinate Time 

TCG Geocentric Coordinate Time 

TDB Barycentric Dynamical Time 

TDR True of Date Rotating 

TDT Terrestrial Dynamical Time (see also ‘TT’) 

TEME True Equator Mean Equinox 

TLE Two Line Element 

TOD True Equator and Equinox of Date 

TT Terrestrial Dynamical Time (see also ‘TDT’) 

USM Universal Semianalytical Method 

UTC Coordinated Universal Time 

W3C World Wide Web Consortium 

WGS World Geodetic System 

XML Extensible Markup Language 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page C-1 November 2009 

ANNEX C

RATIONALE FOR ORBIT DATA MESSAGES 

(INFORMATIVE) 

C1 OVERVIEW 

This annex presents the rationale behind the design of each message. It may help the 

application engineer to select a suitable message. 

A specification of requirements agreed to by all parties is essential to focus design and to 

ensure the product meets the needs of the Member Agencies and satellite operators. There 

are many ways of organizing requirements, but the categorization of requirements is not as 

important as the agreement to a sufficiently comprehensive set. In this section the 

requirements are organized into three categories: 

a) Primary Requirements: These are the most elementary and necessary requirements. 

They would exist no matter the context in which the CCSDS is operating, i.e., 

regardless of pre-existing conditions within the CCSDS, its Member Agencies, or 

other independent users. 

b) Heritage Requirements: These are additional requirements that derive from preexisting Member Agency or other independent user requirements, conditions or 

needs. Ultimately these carry the same weight as the Primary Requirements. This 

Recommended Standard reflects heritage requirements pertaining to some of the 

CCSDS Areas’ home institutions collected during the preparation of the document; it 

does not speculate on heritage requirements that could arise from other sources. 

Corrections and/or additions to these requirements are expected during future 

updates. 

c) Desirable Characteristics: These are not requirements, but they are felt to be 

important or useful features of the Recommended Standard. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page C-2 November 2009 

C2 PRIMARY REQUIREMENTS ACCEPTED BY THE ORBIT DATA 

MESSAGES 

Table C-1: Primary Requirements 

Requirement Accepted 

for OPM? 

Accepted 

for 

OMM? 

Accepted 

for OEM?

Data must be provided in digital form (computer file). Y Y Y 

The file specification must not require of the receiving exchange 

partner the separate application of, or modeling of, spacecraft 

dynamics or gravitational force models, or integration or 

propagation. 

N N Y 

The interface must facilitate the receiver of the message to 

generate a six-component Cartesian state vector (position and 

velocity) at any required epoch. 

Y Y Y 

State vector information must be provided in a reference frame 

that is clearly identified and unambiguous. 

Y Y Y 

Identification of the object and the center(s) of motion must be 

clearly identified and unambiguous. 

Y Y Y 

Time measurements (time stamps, or epochs) must be provided in 

a commonly used, clearly specified system. 

Y Y Y 

The time bounds of the ephemeris must be unambiguously 

specified. 

N/A N/A Y 

The Recommended Standard must provide for clear specification 

of units of measure. 

Y Y Y 

Files must be readily ported between, and useable within, ‘all’ 

computational environments in use by Member Agencies. 

Y Y Y 

Files must have means of being uniquely identified and clearly 

annotated. The file name alone is considered insufficient for this 

purpose. 

Y Y Y 

File name syntax and length must not violate computer 

constraints for those computing environments in use by Member 

Agencies. 

Y Y Y 

A means to convey information about the uncertainty of the state 

shall be provided. 

Y Y Y 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page C-3 November 2009 

Table C-2: Heritage Requirements 

Requirement Accepted 

for OPM? 

Accepted 

for OMM? 

Accepted 

for OEM?

Ephemeris data is reliably convertible into the SPICE SPK 

(NASA) format (reference [G6]) and IIRV (NASA) format 

(reference [G7]) using a standard, multi-mission, unsupervised 

pipeline process. A complete ephemeris, not subject to 

integration or propagation by the customer, must be provided. 

N N Y 

Ephemeris data provided for Deep Space Network (DSN), Ground 

Network (GN), and Space Network (SN) scheduling or operations 

(metric predicts) is to be certified by the providing Agency as 

correct and complete for the intended purpose. The receiving 

Agency cannot provide evaluation, trajectory propagation or other 

usability services. 

N N Y 

The Recommended Standard is, or includes, an ASCII format. Y Y Y 

The Recommended Standard does not require software supplied 

by other Agencies. 

Y N Y 

Table C-3: Desirable Characteristics 

Requirement Accepted 

for OPM? 

Accepted 

for 

OMM? 

Accepted 

for OEM?

The Recommended Standard applies to non-traditional objects, 

such as landers, rovers, balloons, and natural bodies (asteroids, 

comets). 

Y N Y 

The Recommended Standard allows state vectors to be provided 

in other than the traditional EME2000 inertial reference frame; 

one example is the International Astronomical Union (IAU) Mars 

body-fixed frame. (In such a case, provision or ready availability 

of supplemental information needed to transform data into a 

standard frame must be arranged.) 

Y Y Y 

The Recommended Standard is extensible with no disruption to 

existing users/uses. 

Y Y Y 

The Recommended Standard is consistent with, and ideally a part 

of, ephemeris products and processes used for other space science 

purposes. 

N Y N 

The Recommended Standard is as consistent as reasonable with 

any related CCSDS ephemeris Recommended Standards used for 

earth-to-spacecraft or spacecraft-to-spacecraft applications. 

Y Y Y 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page C-4 November 2009 

C3 APPLICABILITY OF CRITERIA TO MESSAGE OPTIONS 

The selection of one particular message will depend on the optimization criteria in the given 

application. Table C-4 compares the three recommended messages in terms of the relevant 

selection criteria identified by the CCSDS: 

Table C-4: Applicability of the Criteria to Orbit Data Messages 

Criteria Definition Applicable 

to OPM? 

Applicable 

to OMM? 

Applicable 

to OEM? 

Modeling Fidelity Permits modeling of any dynamic 

perturbation to the trajectory. 

N N Y 

Human Readability Provides easily readable message 

corresponding to widely used orbit 

representation. 

Y Y Y 

Remote Body 

Extensibility 

Permits use for assets on remote solar 

system bodies. 

Y N Y 

Lander/Rover 

Compatibility

Permits exchange of non-orbit 

trajectories. 

N N Y 

C4 INCREASING ORBIT PROPAGATION FIDELITY OF AN OPM OR OMM 

Some OPM and/or OMM users may desire/require a higher fidelity propagation of the state 

vector or Keplerian elements. A higher fidelity technique may be desired/required in order 

to minimize inconsistencies in predictions generated by diverse, often operator-unique 

propagation schemes. Nominally the OPM and OMM are engineered only for a relatively 

lower fidelity orbit propagation. However, with the inclusion of additional context 

information, it is possible for users to provide data that could be used to provide a relatively 

higher fidelity orbit propagation. For this relatively higher fidelity orbit propagation, a much 

greater amount of ancillary information regarding spacecraft properties and dynamical 

models should be provided. Higher fidelity orbit propagations may be useful in special 

studies such as orbit conjunction studies. 

Spacecraft orbit determination and propagation are stochastic estimation problems. 

Observations are inherently uncertain, and not all of the phenomena that influence satellite 

motion are clearly discernible. State vectors and Keplerian elements with their respective 

covariances are best propagated with models that include the same forces and phenomena 

that were used for determining the orbit. Including this information in an OPM/OMM allows 

exchange partners to compare the results of their respective orbit propagations. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page C-5 November 2009 

With additional context information, the OPM/OMM may be used for assessing mutual 

physical or electromagnetic interference among Earth-orbiting spacecraft, developing 

collaborative maneuvers, and propagating the orbits of active satellites, inactive man made 

objects, and near-Earth debris fragments. The additional information facilitates dynamic 

modeling of any user’s approach to conservative and non-conservative phenomena. 

The primary vehicle for the provision of additional optional ancillary information to be used 

when propagating an OPM/OMM is the COMMENT mechanism. A number of potential 

COMMENT statements are included in annex D. Alternatively, the ‘USER_DEFINED_’ 

keyword prefix may be used, though this usage is not encouraged. 

C5 SERVICES RELATED TO THE DIFFERENT ORBIT DATA MESSAGE 

FORMATS 

The different orbit data messages have been distinguished by the self-interpretability of the 

messages. The different services that can be achieved without special arrangements between 

users of the CCSDS orbit data messages are listed in table C-5. 

Table C-5: Services Available with Orbit Data Messages 

Service Definition Applicable 

to OPM? 

Applicable 

to OMM? 

Applicable 

to OEM? 

Absolute Orbit 

Interpretation 

State availability at specific times for use in 

additional computations (geometry, event 

detection, etc.). 

Y Y Y 

Relative Orbit 

Interpretation 

Trajectory comparison and differencing for events 

based on the same time source. 

Only at time 

specified at 

Epoch 

Only at time 

specified at 

Epoch 

Y 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page D-1 November 2009 

ANNEX D

ITEMS FOR AN INTERFACE CONTROL DOCUMENT 

(INFORMATIVE) 

D1 STANDARD ICD ITEMS 

In several places in this document there are references to items which should be specified in 

an Interface Control Document (ICD) between participants that supplements an exchange of 

ephemeris data. The ICD should be jointly produced by both participants in a cross-support 

involving the transfer of ephemeris data. This annex compiles those recommendations into a 

single section. Although the Orbit Data Messages described in this document may at times 

be used in situations in which participants have not negotiated interface control documents 

(ICD), ICDs based on the content specified in this Recommended Standard should be 

developed and negotiated whenever possible.1

Item Section 

1) Definition of orbit accuracy requirements pertaining to any particular 

ODM. 

1.2 

2) Method of physically exchanging ODMs (transmission). 1.2, 3.1, 4.1, 5.1 

3) Whether the ASCII format of the ODM will be KVN or XML. 2.1 

4) OPM, OMM and/or OEM file-naming conventions. 3.1, 4.1, 5.1 

5) Format on values used for the ‘ORIGINATOR’ keyword. 3.2.2, 4.2.2, 

5.2.2 

6) Situations where the OBJECT_ID is not published in the 

SPACEWARN Bulletin (reference [2]). 

3.2.3, 4.2.3, 

5.2.3 

7) Detailed description of any user defined parameters used. 3.2.4, 4.2.4 

8) Type of TEME reference frame, if applicable (TEME of Epoch or 

TEME of Date). 

4.2.3 

9) If floating point numbers in extended-single or extended-double 

precision are to be used, then discussion of implementation specific 

attributes is required in an ICD between exchange partners. 

6.5 

10) Information which must appear in comments for any given ODM 

exchange. 

6.7 

 

1 EDITOR’S COMMENT: The greater the amount of material which must be specified via ICD, the lesser the 

utility/benefit of the ODM (custom programming may be required to tailor software for each ICD). 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page D-2 November 2009 

Item Section 

11) Specific OPM, OMM and/or OEM version numbers that will be 

exchanged. 

6.8.1 

12) Specific information security interoperability provisions that apply 

between agencies. 

7 

13) Exceptions for the REF_FRAME and/or TIME_SYSTEM metadata 

keywords that are not drawn from annex A. 

annex A 

14) Interpretation of TIME_SYSTEM specified as MET, MRT or SCLK, 

if to be exchanged, and how to transform them to a standardized time 

system. The ICD should specify that elapsed days are to be used for 

epochs, with year starting at zero. 

annex A 

D2 THE ‘CHECKLIST ICD’ 

The following checklist is provided in order to allow for the exchange of essential 

information when there is insufficient time to generate an official, documented Interface 

Control Document. None of the items in this checklist are required, but may be used to 

convey as much information as possible in an exchange. This checklist may also be used as 

a guideline for the development of a formal ICD, if so desired. The basic idea of the 

‘Checklist ICD’ is to provide a vehicle that may be used by exchange partners to document 

sufficient data and metadata to allow comparison of their independent estimates of future 

states of satellites of interest. 

Information about atmospheric models and other elements of analysis that cannot be 

described precisely enough to allow consumers to reproduce the provider’s processes may be 

included via this vehicle, i.e., in optional comment fields and not in normative requirements. 

The rationale for making these non-normative includes: (a) investigators often tune or 

modify ‘standard’ models and there may be many uncontrolled versions, and (b) simply 

stating the name of a model such as a ‘Jacchia atmosphere’ may not be a sufficient 

specification, yet there may be no more precise description available. 

USAGE NOTE: This checklist should be filled in by an engineer or technician and used as a 

supplement to one (or more) of the normative messages in this document (OPM, OMM, or 

OEM). For each attribute, a space is allocated in which the applicable values or text may be 

provided. The far right column provides usage information. Also, to facilitate use within 

one of the normative messages, the far left column of the ‘Checklist ICD’ is set up with the 

‘COMMENT’ keyword. This allows the user to fill in the checklist and then copy it into one 

of the ODM files as a comment section. Individual COMMENT statements that are not 

applicable to any given exchange may be deleted. A blank Microsoft Word copy of this 

‘Checklist ICD’ is available on the CCSDS web site at: 

http://public.ccsds.org/publications/archive/ODM-checklist-icd.doc
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page D-3 November 2009 

Because this checklist is non-normative, it may be extended, reduced, or otherwise tailored to 

meet the needs of individual exchange partners. This online version is suitable for 

downloading, editing, and inserting directly into an OPM. This set of COMMENT 

statements is also suitable for use in situations where an ICD between exchange partners is 

neither required, desired, nor feasible. An alternative to the use of this set of COMMENT 

statements is the User Defined Parameters capability; however, User Defined Parameters 

should only be used sparingly. For a list this extensive the User Defined Parameters feature 

should not be used. 

CHECKLIST INTERFACE CONTROL DOCUMENT

COMMENT Attribute Value Usage 

COMMENT DATE = Date/time the checklist was filled 

out 

COMMENT OBJECT ID = If this list is used as a standalone 

ICD, this satellite international 

designator number links the 

checklist to the applicable 

normative message. It is not 

necessary if the checklist is pasted 

into one of the normative messages. 

COMMENT OBJECT NAME = If this list is used as a standalone 

ICD, this item links the checklist to 

the applicable normative message. 

It is not necessary if the checklist is 

pasted into one of the normative 

messages. 

COMMENT GEOPOTENTIAL MODEL = Gravitational model (e.g., EGM-96, 

WGS-84/EGM-96, WGS-84, GGM01, TEG-4) 

COMMENT GEOPOTENTIAL MODEL DEGREE AND ORDER = ____ x ____ 

COMMENT EARTH RADIUS USED = 

COMMENT EARTH ANGULAR ROTATION USED = deg/sec 

COMMENT ATMOSPHERIC DRAG MODEL = Atmospheric models (e.g., 

MSISE90, NRLMSIS00, J70, J71, 

JRob, DTM) 

COMMENT 

COMMENT 

COMMENT 

COMMENT 

COMMENT 

COMMENT 

COMMENT 

COMMENT 

COMMENT 

COMMENT 

THIRD BODY PERTURBATIONS = 

THIRD BODY PERTURBATIONS = 

THIRD BODY PERTURBATIONS = 

THIRD BODY PERTURBATIONS = 

THIRD BODY PERTURBATIONS = 

THIRD BODY PERTURBATIONS = 

THIRD BODY PERTURBATIONS = 

THIRD BODY PERTURBATIONS = 

THIRD BODY PERTURBATIONS = 

THIRD BODY PERTURBATIONS = 

Sun 

Moon 

Mercury 

Venus 

Mars 

Jupiter 

Saturn 

Uranus 

Neptune 

Pluto 

If this list is printed, circle or 

otherwise indicate the included 

accelerations. 

If this annex is used as a file, or is 

cut/pasted into an ODM, then the 

lines for 3rd body perturbations that 

were not included in the analysis 

may be removed from the file. 

COMMENT SOLAR PRESSURE MODEL = 

COMMENT SOLID TIDES MODEL = 

COMMENT OCEAN TIDES MODEL = 

COMMENT EARTH ALBEDO = 

COMMENT EARTH ALBEDO GRID SIZE = 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page D-4 November 2009 

COMMENT ATTITUDE = NOTE – Attitude state is best 

supplied by a CCSDS 

Attitude Data Message 

(see reference [G5]). 

Could supply the 

applicable APM or AEM 

file name as the value for 

this parameter. 

COMMENT EOP EPOCH = 

COMMENT EOP SOURCE = e.g., IERS, USNO, NGA 

COMMENT POLAR MOTION X = in arcseconds 

COMMENT POLAR MOTION Y = in arcseconds 

COMMENT POLAR ANGLE EPSILON = in degrees 

COMMENT POLAR ANGLE PSI = in degrees 

COMMENT UT1 CORRECTION = in seconds 

COMMENT SOLAR F10.7 = units = 104 Jansky 

COMMENT AVERAGE F10.7 = units = 104 Jansky. Time frame 

should be specified. 

COMMENT INTERPOLATION METHOD = Used for EOP and Solar Weather 

data 

COMMENT SHADOW MODEL = Shadow modeling for Solar 

Radiation Pressure (e.g., NONE, 

CYLINDRICAL, DUAL CONE); 

dual cone uses both 

umbra/penumbra regions 

COMMENT PRECESSION/NUTATION UPDATE INTERVAL = Update interval for precession 

nutation values 

COMMENT ORBIT DETERMINATION SCHEME = e.g., PODS, DSST, RTOD, ODTK, 

or other widely used orbit 

estimation technique or tool 

COMMENT INTEGRATION SCHEME = (e.g., RKF78, GAUSSJACK, 

ADAMSB, other) 

COMMENT INTEGRATION STEP MODE = Type of integration (e.g., FIXED, 

RELATIVE ERROR, REGTIME) 

COMMENT INTEGRATOR STEP SIZES = Step sizes—not used if relative 

error is selected 

COMMENT INTEGRATOR ERROR CONTROL = Error control if needed by the 

integrator (e.g., 1.0 e-15, other) 

COMMENT COVARIANCE SOLVE-FOR = Repeat this line as many times as is 

necessary to list the factors included 

in the orbit determination solution 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page E-1 November 2009 

ANNEX E

CHANGES IN ODM VERSION 2 

(INFORMATIVE) 

This annex lists the differences between ODM 1.0 and ODM 2.0. The differences are 

divided into those which affect the content of one or more of the orbit data messages, and 

those which only affect the document. 

E1 CHANGES IN THE MESSAGES 

1. The Orbit Mean-Elements Message (OMM) was added to provide better support for ISO 

Technical Committee 20, Subcommittee 14 objectives (see section 4). 

2. The 6x6 covariance matrix (lower triangular form) included in the initial version of the 

OMM was added to the OPM and OEM to allow producers of these files to provide the 

uncertainties associated with the state(s). 

3. The option to use the Julian Date in formatting of epochs and other time fields is 

withdrawn, as this format is described in neither the CCSDS Time Code Formats 

(reference [1]) nor the ISO 8601 standard ‘Data elements and interchange formats — 

Information interchange — Representation of dates and times’. 

4. Optional accelerations were added to the state vectors provided in the OEM format (see 

section 5). 

5. Some restrictions were imposed on the placement of COMMENT statements in order to 

allow easy conversion of ODMs from KVN format to XML format or vice versa. 

6. The requirement to put the OBJECT_ID parameter in SPACEWARN format was 

changed from a requirement (‘shall’) to a recommendation (‘should’) based on current 

operational uses of the OEM. 

7. Maximum line width for all messages changed to 254 to be consistent with the Tracking 

Data Message (TDM) and Attitude Data Messages (ADM) Recommended Standards. 

8. The rules for text value fields were constrained to only all uppercase or all lowercase. 

9. The fields in the ‘Spacecraft Parameters’ block of the OPM were changed from 

obligatory to optional parameters. 

10. The block of optional User Defined Parameters included in the initial version of the 

OMM is added to the OPM. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page E-2 November 2009 

11. The REF_FRAME_EPOCH is added to accommodate cases when the reference frame 

epoch is not intrinsic to the definition of the reference frame. 

12. The relationship between successive blocks of ephemeris data was clarified such that the 

repetition of time tags is relative to the USEABLE_STOP_TIME and 

USEABLE_START_TIME instead of the STOP_TIME and START_TIME. 

E2 CHANGES IN THE DOCUMENT 

1. A normative annex for primary TIME_SYSTEM and reference frame related keywords 

was added, replacing non-normative references to the Navigation Green Book (reference 

[G1]). The CCSDS documents are not allowed to make normative references to nonnormative documents. 

2. Annexes were rearranged to conform to CCSDS Guidelines that were inadvertently not 

followed in the first version of the ODM (specifically, normative annexes are supposed to 

appear first, prior to the informative annexes). 

3. The formats of units allowed in the OPM were changed to make them compliant with the 

International System (SI) of Units. In the Blue Book version 1, the SI conventions were 

not observed. In all cases, this was merely a change in case conventions from upper case 

to lower case. 

4. A few changes were made to harmonize the ODM with the other Navigation Data 

Messages (Attitude Data Messages [ADM] and Tracking Data Message [TDM]). Most 

of these changes were generated from the CCSDS Agency Review processes of the ADM 

and TDM. 

5. In the original ODM Blue Book, several aspects of the CCSDS ‘Style Guide’ were not 

followed when the ODM was originally published. This version corrects these styling 

errors. 

6. The annex that describes information to be included in an ICD was significantly revised 

to suggest additional information that would be worthwhile to exchange. Also, a 

checklist was added that will allow exchange partners to exchange ODMs when there is 

no time to negotiate a formal ICD by inserting COMMENT statements into an ODM. 

7. The syntax rules for the OPM, OMM, and OEM were consolidated into a common syntax 

section (see section 6). 

8. The rules for processing COMMENT keywords were consolidated into a single section 

of the document (see section 6). 

9. Improved discussion of information security considerations was provided, per Secretariat 

request (see section 7). 

Cor. 1 Cor. 1

CCSDS 502.0-B-2 Cor. 1 May 2012
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page F-1 November 2009 

ANNEX F

CREATING A VERSION 1.0 COMPLIANT OPM/OEM 

(INFORMATIVE) 

This annex describes the actions that the user should perform in order to create an OPM or 

OEM that is compatible with implementations of the ODM version 1.0 Blue Book. Note: 

there is no version 1.0 compatible OMM; that message type first appears in the ODM version 

2.0. Examples of version 1.0 compatible OPM and OEM messages are shown in the body of 

the document. 

F1 ODM VERSION 1.0 COMPATIBLE OPM 

For various reasons, the user may wish to create an OPM that is compatible with the ODM 

Version 1. In this case, the user must observe the following requirements: 

– If the software implementation of the exchange partner will not accept a version 2.0 

OPM, the value associated with the CCSDS_OPM_VERS keyword must be ‘1.0’. 

– If the software implementation of the exchange partner will accept either version 1.0 

or 2.0 OPMs, the value associated with the CCSDS_OPM_VERS keyword may be 

either ‘1.0’ or ‘2.0’. 

– The OPM line length must not exceed 80 characters (including end of line markers). 

– The user must not code the REF_FRAME_EPOCH metadata keyword. 

– The user must code the Spacecraft Parameters logical block. 

– The user must not code the Covariance Matrix logical block. 

– The user must not code the User Defined Parameters logical block. 

– If units are desired in the version 1.0 compatible OPM, it may be that an exchange 

partner’s software requires units in upper case characters as they were shown in the 

Version 1.0 OPM. While it seems unlikely that the case of the units in an OPM 

would be checked, the user should be aware of this potential issue. 

NOTE – OPM Version 2.0 commenting rules are backward compatible to OPM Version 1.0. 

F2 ODM VERSION 1.0 COMPATIBLE OEM 

For various reasons, the user may wish to create an OEM that is compatible with the ODM 

Version 1. In this case, the user must observe the following requirements: 

– If the software implementation of the exchange partner will not accept a version 2.0 

OEM, the value associated with the CCSDS_OEM_VERS keyword must be ‘1.0’. 
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page F-2 November 2009 

– If the software implementation of the exchange partner will accept either version 1.0 

or 2.0 OEMs, the value associated with the CCSDS_OEM_VERS keyword may be 

either ‘1.0’ or ‘2.0’. 

– The user must not code the REF_FRAME_EPOCH metadata keyword. 

– The user must not code the acceleration components in the OEM Data Lines. 

– The user must not code the Covariance Matrix logical block. 

– The user must ensure that ephemeris data time tags do not overlap except at the 

STOP_TIME/START_TIME boundary. 

NOTE – OEM Version 2.0 commenting rules are backward compatible to OEM Version 1.0. 

Cor. 1

CCSDS 502.0-B-2 Cor. 1 May 2012
CCSDS RECOMMENDED STANDARD FOR ORBIT DATA MESSAGES 

CCSDS 502.0-B-2 Page G-1 November 2009 

ANNEX G

INFORMATIVE REFERENCES 

(INFORMATIVE) 

[G1] Navigation Data—Definitions and Conventions. Report Concerning Space Data 

System Standards, CCSDS 500.0-G-3. Green Book. Issue 3. Washington, D.C.: 

CCSDS, May 2010. 

[G2] Organization and Processes for the Consultative Committee for Space Data Systems. 

CCSDS A02.1-Y-3. Yellow Book. Issue 3. Washington, D.C.: CCSDS, July 2011.

[G3] “CelesTrak.” Center for Space Standards & Innovation (CSSI). 

<http://celestrak.com/> 

[G4] David A. Vallado, et al. “Revisiting Spacetrack Report #3.” In Proceedings of the 

AIAA/AAS Astrodynamics Specialist Conference and Exhibit (21–24 August 2006, 

Keystone, Colorado). AIAA 2006-6753. Reston, Virginia: AIAA, 2006. 

<http://www.centerforspace.com/downloads/files/pubs/AIAA-2006-6753.pdf>

[G5] Attitude Data Messages. Recommendation for Space Data System Standards, CCSDS 

504.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, May 2008. 

[G6] “Documentation.” SPICE: NASA’s Solar System Exploration Ancillary Information 

System. Navigation and Ancillary Information Facility (NAIF). 

<http://naif.jpl.nasa.gov/naif/documentation.html> 

[G7] Ground Network Tracking and Acquisition Data Handbook. 453-HNDK-GN. 

Greenbelt, Maryland: Goddard Space Flight Center, May 2007.