ISO 22644:2006

INTERNATIONAL ISO
STANDARD 22644
First edition
2006-05-01
Space data and information transfer
systems — Orbit data messages
Systèmes de transfert des informations et données spatiales —
Messages pour données d'orbites

Reference number
©
ISO 2006
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2006
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2006 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 22644 was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as
CCSDS 502.0-B-1, September 2004) and was adopted (without modifications except those stated in Clause 2
of this International Standard) by Technical Committee ISO/TC 20, Aircraft and space vehicles, Subcommittee
SC 13, Space data and information transfer systems.

INTERNATIONAL STANDARD ISO 22644:2006(E)

Space data and information transfer systems — Orbit data
messages
1 Scope
This International Standard specifies two standard message formats for use in transferring spacecraft orbit
information between space Agencies: the Orbit Parameter Message (OPM) and the Orbit Ephemeris Message
(OEM). Such exchanges are used for
⎯ pre-flight planning for tracking or navigation support;
⎯ scheduling tracking support;
⎯ carrying out tracking operations (sometimes called metric predicts);
⎯ performing orbit comparisons;
⎯ carrying out navigation operations such as orbit propagation.
This International 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 another mechanism may be selected.
The scope and field of application are furthermore detailed in subclauses 1.1 and 1.2 of the enclosed CCSDS
publication.
2 Requirements
Requirements are the technical recommendations made in the following publication (reproduced on the
following pages), which is adopted as an International Standard:
CCSDS 502.0-B-1, September 2004, Orbit data messages.
For the purposes of international standardization, the modifications outlined below shall apply to the specific
clauses and paragraphs of publication CCSDS 502.0-B-1.
Pages i to v
This part is information which is relevant to the CCSDS publication only.
Page 1-2
Add the following information to the reference indicated:
[1] CCSDS Green Books are now available at http://public.ccsds.org/publications/GreenBooks.aspx
3 Revision of publication CCSDS 502.0-B-1
It has been agreed with the Consultative Committee for Space Data Systems that Subcommittee
ISO/TC 20/SC 13 will be consulted in the event of any revision or amendment of publication CCSDS 502.0-B-1.
To this end, NASA will act as a liaison body between CCSDS and ISO.

2 © ISO 2006 – All rights reserved

Consultative
Committeefor
SpaceDataSystems
RECOMMENDATION FOR SPACE
DATA SYSTEM STANDARDS
ORBIT DATA
MESSAGES
CCSDS 502.0-B-1
BLUE BOOK
September 2004
(Blank page)
4 © ISO 2006 – All rights reserved

CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES
AUTHORITY
Issue: Blue Book, Issue 1
Date: September 2004
Location: Electronic Ballot
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 Recommendations is detailed in the Procedures Manual
for the Consultative Committee for Space Data Systems (reference [5]), and the record of
Agency participation in the authorization of this document can be obtained from the CCSDS
Secretariat at the address below.
This Recommendation is published and maintained by:
CCSDS Secretariat
Office of Space Communication (Code M-3)
National Aeronautics and Space Administration
Washington, DC 20546, USA
CCSDS 502.0-B-1 Page i September 2004
CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES
STATEMENT OF INTENT
The Consultative Committee for Space Data Systems (CCSDS) is an organization officially
established by the management of member space Agencies. 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
Recommendations and are not considered binding on any Agency.
This Recommendation is issued by, and represents the consensus of, the CCSDS Plenary
body. Agency endorsement of this Recommendation is entirely voluntary. Endorsement,
however, indicates the following understandings:
– Whenever an Agency establishes a CCSDS-related standard, this standard will be in
accord with the relevant Recommendation. Establishing such a standard does not
preclude other provisions which an Agency may develop.
– Whenever an Agency establishes a CCSDS-related standard, the Agency will provide
other CCSDS member Agencies with the following information:
• The standard itself.
• The anticipated date of initial operational capability.
• The anticipated duration of operational service.
– Specific service arrangements are made via memoranda of agreement. Neither this
Recommendation nor any ensuing standard is a substitute for a memorandum of
agreement.
No later than five years from its date of issuance, this Recommendation 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 Recommendation is issued, existing CCSDS-
related Agency standards and implementations are not negated or deemed to be non-CCSDS
compatible. It is the responsibility of each Agency to determine when such standards or
implementations are to be modified. Each Agency is, however, strongly encouraged to direct
planning for its new standards and implementations towards the later version of the
Recommendation.
CCSDS 502.0-B-1 Page ii September 2004
6 © ISO 2006 – All rights reserved

CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES
FOREWORD
This document is a technical Recommendation 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 Recommendation is the baseline concept for trajectory
representation in data interchange applications that are cross-supported between Agencies of
the CCSDS.
This Recommendation 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 Recommendation and may incorporate
features not addressed by this Recommendation.
Through the process of normal evolution, it is expected that expansion, deletion or
modification to this document may occur. This Recommendation is therefore subject to
CCSDS document management and change control procedures, as 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 502.0-B-1 Page iii September 2004
CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES
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.
– Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)/Germany.
– European Space Agency (ESA)/Europe.
– Federal Space Agency (FSA)/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.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– Centro Tecnico Aeroespacial (CTA)/Brazil.
– Chinese Academy of Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– Communications Research Laboratory (CRL)/Japan.
– Danish Space Research Institute (DSRI)/Denmark.
– European Organization for the Exploitation of Meteorological Satellites
(EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Europe.
– Federal Science Policy Office (FSPO)/Belgium.
– 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.
– MIKOMTEK: CSIR (CSIR)/Republic of South Africa.
– Ministry of Communications (MOC)/Israel.
– National Oceanic & Atmospheric Administration (NOAA)/USA.
– National Space Program Office (NSPO)/Taipei.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
– United States Geological Survey (USGS)/USA.
CCSDS 502.0-B-1 Page iv September 2004
8 © ISO 2006 – All rights reserved

CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES
DOCUMENT CONTROL
Document Title and Issue Date Status
CCSDS Orbit Data Messages, September Current Issue
502.0-B-1 Issue 1 2004
CCSDS 502.0-B-1 Page v September 2004
CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES
CONTENTS
Section Page
1 INTRODUCTION.1-1
1.1 PURPOSE. 1-1
1.2 SCOPE AND APPLICABILITY.1-1
1.3 CONVENTIONS AND DEFINITIONS.1-1
1.4 STRUCTURE OF THIS DOCUMENT.1-2
1.5 REFERENCES . 1-2
2 OVERVIEW.2-1
2.1 ORBIT DATA MESSAGE TYPES. 2-1
2.2 ORBIT PARAMETER MESSAGE (OPM) . 2-1
2.3 ORBIT EPHEMERIS MESSAGE (OEM) . 2-1
2.4 EXCHANGE OF MULTIPLE MESSAGES. 2-2
2.5 DEFINITIONS. 2-2
3 ORBIT PARAMETER MESSAGE (OPM) . 3-1
3.1 OVERVIEW . 3-1
3.2 OPM CONTENT . 3-1
3.3 OPM SYNTAX. 3-7
3.4 OPM EXAMPLES. 3-11
4 ORBIT EPHEMERIS MESSAGE (OEM).4-1
4.1 OVERVIEW . 4-1
4.2 OEM CONTENT . 4-1
4.3 OEM SYNTAX . 4-6
4.4 OEM EXAMPLE. 4-11

ANNEX A RATIONALE FOR ORBIT DATA MESSAGES. A-1
ANNEX B ITEMS FOR AN INTERFACE CONTROL DOCUMENT . B-5
ANNEX C ABBREVIATIONS AND ACRONYMS. C-6

CCSDS 502.0-B-1 Page vi September 2004
10 © ISO 2006 – All rights reserved

CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES
CONTENTS (continued)
Figure Page
3-1 OPM File Example Using Comments to Denote Updates .3-11
3-2 OPM File Example with Optional Keplerian Elements and Two Maneuvers .3-12
4-1 OEM Example .4-11

Table Page
3-1 OPM Header.3-2
3-2 OPM Metadata. 3-3
3-3 OPM Data.3-5
4-1 OEM File Layout Specifications . 4-2
4-2 OEM Header.4-3
4-3 OEM Metadata .4-4
A-1 Primary Requirements . A-2
A-2 Heritage Requirements . A-3
A-3 Desirable Characteristics . A-3
A-4 Applicability of the Criteria to Orbit Data Codes. A-4
A-5 Services Available with Orbit Data Codes. A-4

CCSDS 502.0-B-1 Page vii September 2004
(Blank page)
12 © ISO 2006 – All rights reserved

CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES
1 INTRODUCTION
1.1 PURPOSE
This Orbit Data Message (ODM) Recommendation specifies two standard message formats
for use in transferring spacecraft orbit information between space Agencies: the Orbit
Parameter Message (OPM) 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; and
e) carrying out navigation operations such as orbit propagation.
This Recommendation 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 another mechanism may be selected.
1.2 SCOPE AND APPLICABILITY
This document contains two orbit data messages designed for applications involving data
interchange in space data systems. The rationale behind the design of each message is
described in Annex A 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 Recommendation and should be specified via Interface Control Document (ICD)
between data exchange participants. Applicability information specific to each orbit data
message format appears in sections 3 and 4, as well as in subsection A3.
This Recommendation is applicable only to the message format and content, but not to its
transmission. The transmission of the message between Agencies is outside the scope of this
document and should be specified in the ICD.
Description of the message formats based on the use of eXtensible Markup Language (XML)
is under investigation. It is anticipated that an XML schema will be defined by a future
Recommendation on the XML implementation of Navigation data messages.
1.3 CONVENTIONS AND DEFINITIONS
The following conventions apply throughout this Recommendation:
a) the words ‘shall’ and ‘must’ imply a binding and verifiable specification;
CCSDS 502.0-B-1 Page 1-1 September 2004
CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES
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.4 STRUCTURE OF THIS DOCUMENT
Chapter 2 provides a brief overview of the CCSDS-recommended Orbit Data Message types,
the Orbit Parameter Message (OPM) and Orbit Ephemeris Message (OEM).
Chapter 3 provides details about the structure and content of the OPM.
Chapter 4 provides details about the structure and content of the OEM.
Annex A lists a set of requirements that were taken into consideration in the design of the
OPM and OEM, along with tables and discussion regarding the applicability of the two
message types to various navigation tasks/functions.
Annex B lists a number of items that should be covered in interagency Interface Control
Documents (ICD) 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.
Annex C is a list of abbreviations and acronyms applicable to the ODM.
1.5 REFERENCES
The following documents contain provisions which, through reference in this text, constitute
provisions of this Recommendation. At the time of publication, the editions indicated were
valid. All documents are subject to revision, and users of this Recommendation 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 Recommendations.
[1] Navigation Data—Definitions and Conventions. Report Concerning Space Data
System Standards, CCSDS 500.0-G-1. Green Book. Issue 1. Washington, D.C.:
CCSDS, June 2001. [http://www.ccsds.org/green_books.html]
[2] Spacewarn Bulletin. Greenbelt, MD, USA: World Data Center for Satellite
Information: WDC-SI. [ http://nssdc.gsfc.nasa.gov/spacewarn ]
[3] Standard Frequencies and Time Signals. Volume 7 of Recommendations and Reports
of the CCIR: XVth Plenary Assembly. Geneva: CCIR,1990.
CCSDS 502.0-B-1 Page 1-2 September 2004
14 © ISO 2006 – All rights reserved

CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES
[4] 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. [ http://www.iso.ch ]
[5] Procedures Manual for the Consultative Committee for Space Data Systems. CCSDS
A00.0-Y-9. Yellow Book. Issue 9. Washington, D.C.: CCSDS, November 2003.
[6] NASA/JPL Solar System Dynamics Group [ http://ssd.jpl.nasa.gov ].
[7] XML Schema Part 2: Datatypes, W3C Recommendation 02 May 2001,
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/
[8] IEEE Standard for Binary Floating-Point Arithmetic, IEEE Standard 754-1985, IEEE,
http://grouper.ieee.org/groups/754/
CCSDS 502.0-B-1 Page 1-3 September 2004
(Blank page)
16 © ISO 2006 – All rights reserved

CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES
2 OVERVIEW
2.1 ORBIT DATA MESSAGE TYPES
Two CCSDS-recommended Orbit Data Messages (ODMs) are described in this
Recommendation: the Orbit Parameter Message (OPM) and the Orbit Ephemeris Message
(OEM).
The recommended orbit data messages are ASCII text format. While binary-based orbit data
message formats are computer efficient and minimize overhead on uplinked/downlinked data
streams, there are ground-segment applications for which an ASCII character-based message
is more appropriate. For example, when files or data objects are created using text editors or
word processors, ASCII character-based orbit data format representations are necessary.
They are also useful in transferring text files between heterogeneous computing systems,
because the ASCII character set is nearly universally used and is interpretable by all popular
systems. In addition, direct human-readable dumps of text files or objects to displays or
printers are possible without preprocessing. The penalty for this convenience is inefficiency.
NOTE As currently specified, an OPM or OEM file is to represent orbit data for a
single vehicle. It is possible that the architecture may support multiple vehicles 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. This
message is suited to inter-agency 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. The OPM is fully self-contained; no additional
information is required.
The code 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 attributes
of this code also make it suitable for applications such as exchanges by FAX or voice, or
applications where the message is to be frequently interpreted by humans.
2.3 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 inter-agency exchanges that (1) involve
automated interaction (e.g., computer-to-computer communication where frequent, fast
CCSDS 502.0-B-1 Page 2-1 September 2004
CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES
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 is fully self-
contained; no additional information is required.
2.4 EXCHANGE OF MULTIPLE MESSAGES
For a given object, multiple OPM 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 or OEM files must be used.
2.5 DEFINITIONS
Definitions of time systems, reference frames and planetary models are provided in reference
[1].
CCSDS 502.0-B-1 Page 2-2 September 2004
18 © ISO 2006 – All rights reserved

CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES
3 ORBIT PARAMETER MESSAGE (OPM)
3.1 OVERVIEW
a) Orbit information may be exchanged between two participants by sending a state
vector (see reference [1]) 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) shall be
included with the message.
b) The use of the OPM shall be applicable under the following conditions:
1) an orbit propagator must be run at the receiver’s site;
2) the receiver’s modeling of gravitational forces, solar radiation pressure,
atmospheric drag and thrust phases (see reference [1]) must fulfill accuracy
requirements established between the agencies.
c) The OPM shall be a text file consisting of orbit data for a single object. It shall be
easily readable by both humans and computers.
d) The OPM file naming scheme shall be agreed to on a case-by-case basis between
the participating Agencies, and should be documented in an Interface Control
Document (ICD). The method of exchanging OPMs shall be decided on a case-
by-case basis by the participating Agencies and documented in an ICD.
3.2 OPM CONTENT
The OPM shall be represented as a combination of the following:
a) a header;
b) metadata (data about data);
c) optional comments (explanatory information); and
d) data.
3.2.1 OPM HEADER
Table 3-1 specifies for each header item:
a) the keyword to be used;
b) a short description of the item;
CCSDS 502.0-B-1 Page 3-1 September 2004

CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES
c) examples of allowed values; and
d) whether the item is obligatory or optional.
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 1.0
Format version in the form of ‘x.y’, where ‘y’ is Yes
incremented for corrections and minor changes,
and ‘x’ is incremented for major changes.
CREATION_DATE
File creation date/time in one of following formats: Yes
2001-11-06T11:17:33
YYYY-MM-DDThh:mm:ss[.tttttt] or
2002-204T15:56:23
YYYY-DDDThh:mm:ss[.tttttt]
where “YYYY” is the year, “MM” is the 2 digit
month, “DD” is the 2 digit day, “DDD” is the 3
digit day of year, “T” is constant,
“hh:mm:ss[.tttttt]” is the UTC time in hours,
minutes, seconds, and optional fractional seconds.
All fields require leading zeros.
ORIGINATOR CNES, ESOC, GSFC, GSOC, JPL,
Yes
Creating agency (value should be specified in an
JAXA, etc.
ICD).
COMMENT n/a
Comments (allowed everywhere in the OPM No
Header after the OPM version number). Each
comment line shall begin with this keyword.
3.2.2 OPM METADATA
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.
Only those keywords shown in Table 3-2 shall be used in OPM metadata. For some
keywords (OBJECT_NAME, OBJECT_ID, CENTER_NAME, REF_FRAME) there are no
definitive lists of authorized values maintained by a control authority; the references listed in
subsection 1.5 are the best known sources for authorized values to date.
CCSDS 502.0-B-1 Page 3-2 September 2004

20 © ISO 2006 – All rights reserved

CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES
Table 3-2: OPM Metadata
Keyword Description Examples of Values Obligatory
EUTELSAT W1
OBJECT_NAME Yes
There is no CCSDS-based restriction on the value
MARS PATHFINDER
for this keyword, but it is recommended to use
STS 106
names from the SPACEWARN Bulletin
NEAR
(reference [2]), which include Object name and
international designator of the participant.
2000-052A
OBJECT_ID Yes
International spacecraft designator (as published in
1996-068A
the SPACEWARN Bulletin (reference [2])). Valid
2000-053A
values have the format YYYY-NNNP{PP}, where:
1996-008A
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
the value should be provided in an ICD.
CENTER_NAME EARTH
Origin of reference frame, which may be a natural Yes
EARTH BARYCENTER
solar system body (planets, asteroids, comets, and
MOON
natural satellites), including any planet barycenter
SOLAR SYSTEM BARYCENTER
or the solar system barycenter, or another
SUN
spacecraft (in this case the value for
JUPITER BARYCENTER
‘CENTER_NAME’ is subject to the same rules as
STS 106
for ‘OBJECT_NAME’). There is no CCSDS-based
EROS
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 [6])).
ICRF
REF_FRAME Yes
Name of the reference frame in which the state
ITRF-93
vector and optional Keplerian element data are
ITRF-97
given. It is recommended to use reference frames
ITRF2000
from Navigation Definitions and Conventions
ITRFxxxx (Template for a future version)
(reference [1]).
TOD   (True Equator/Equinox of Date)
EME2000 (Earth Mean Equator and
Equinox of J2000)
TDR       (true of date rotating)
GRC      (Greenwich rotating coordinate
frame)
TIME_SYSTEM UTC, TAI, TT, GPS, TDB, TCB
Time system used for state vector and maneuver data Yes
(also see Table 3-3). It is recommended to use names
from Navigation Definitions and Conventions
(reference [1]). Times may be given in 1)
ISO/CCSDS ASCII format or 2) Julian Date strings.
COMMENT n/a
Comments (allowed everywhere in the OPM No
Metadata). Each comment line shall begin with this
keyword.
CCSDS 502.0-B-1 Page 3-3 September 2004

CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES
3.2.3 OPM DATA
Table 3-3 provides an overview of the four logical blocks in the OPM Data section (State
Vector, Keplerian Elements, Spacecraft Parameters, and Maneuver 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.
Only those keywords shown in Table 3-3 shall be used in OPM data. (Some important notes
about the keywords in Table 3-3 appear immediately after the table.)
CCSDS 502.0-B-1 Page 3-4 September 2004

22 © ISO 2006 – All rights reserved

CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES

Table 3-3: OPM Data
Keyword Description Units Obligatory
State Vector Components in the Specified Coordinate System
EPOCH Epoch of state vector & optional Keplerian elements 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
Keplerian Elements in the Specified Reference Frame (none or all parameters of this block must be given.)
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 True anomaly or mean anomaly DEG No
MEAN_ANOMALY
GM Gravitational Coefficient KM**3 / S**2 No
Spacecraft Parameters
MASS S/C Mass at Epoch KG Yes
SOLAR_RAD_AREA Solar Radiation Pressure Area (A). M**2 Yes
R
SOLAR_RAD_COEFF Solar Radiation Pressure Coefficient (C). n/a Yes
R
DRAG_AREA Drag Area (A). M**2 Yes
D
DRAG_COEFF Drag Coefficient (C). n/a Yes
D
Maneuver Parameters (Repeat for each maneuver. None or all parameters of this block must be given.)
MAN_EPOCH_IGNITION Epoch of ignition 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 n/a No
st
MAN_DV_1 1 component of the velocity increment KM/S No
nd
MAN_DV_2 2 component of the velocity increment KM/S No
rd
MAN_DV_3 3 component of the velocity increment KM/S No
Comments (shall appear only at the beginning or end of the logical blocks, but not between components of the
logical blocks.)
COMMENT Each comment line shall begin with this keyword. n/a No

CCSDS 502.0-B-1 Page 3-5 September 2004

CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES
NOTES
1 See ‘CREATION_DATE’ in Table 3-1 for examples of how to format the EPOCH.
2 Table 3-3 is broken into four logical blocks, each of which has a descriptive heading.
Those descriptive headings shall not be included in an OPM, unless they appear in a
properly formatted COMMENT statement.
3 The gravitational coefficient, GM (Gravitational Coefficient = Gravitational Constant
x Central Mass), used by the originator of the message for the conversion of state
vector to Keplerian elements (or vice versa) must be included if the optional set of
3 2
Keplerian elements is provided. The required units for GM are km /s .
4 If the solar radiation coefficient, C , is set to zero, no solar radiation pressure shall be
R
taken into account.
5 If the atmospheric drag coefficient, C , is set to zero, no atmospheric drag shall be
D
taken into account.
6 Parameters for thrust phases may be optionally given for the computation of the
trajectory during or after maneuver execution (see reference [1] 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 allowed for the keyword REF_FRAME
in Table 3-1 and the Radial, Transverse (along-track) and Normal (RTN) reference
frame (see reference [1]).
3.2.4 COMMENTS IN AN OPM
a) 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.
b) 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 OPM producer should put
certain information into comments and use the ICD to provide further
specifications.
c) Comments may appear anywhere within the OPM Header and OPM Metadata
sections. In the OPM Data section, comments shall only appear at the beginning
or end of a logical block. Comments must not appear between the components of
CCSDS 502.0-B-1 Page 3-6 September 2004

24 © ISO 2006 – All rights reserved

CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES
any logical block in the OPM Data section. The logical blocks in the OPM Data
section are indicated in Table 3-3.
d) The following comments should be provided:
1) Information regarding the genesis, history, interpretation, intended use, etc.
of the state vector, spacecraft, and maneuver that may be of use to the
receiver of the OPM:
COMMENT Source: File created by JPL Multi-Mission Navigation Team as part
COMMENT of Launch Operations Readiness Test held on 20 April 2001.
2) Natural body ephemeris information:

COMMENT Based on latest orbit solution which includes observations
COMMENT through 2000-May-15 relative to planetary ephemeris DE-0405.
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.
3.3 OPM SYNTAX
The OPM shall be a plain text file, using the syntax described in subsections 3.3.1 through
3.3.6.
3.3.1 LINES
a) Each OPM line must not exceed 78 ASCII characters and spaces (excluding line
termination character[s]).
b) Only printable ASCII characters and blanks shall be used. Control characters
(such as TAB, etc.) shall not be used.
c) Blank lines may be used at any position within the file.
d) Comment lines shall be optional. See Section 3.2.4 for details regarding the
placement of comment lines.
e) OPM 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.
CCSDS 502.0-B-1 Page 3-7 September 2004

CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES
3.3.2 KEYWORD = VALUE NOTATION AND ORDER OF ASSIGNMENT
STATEMENTS
a) All header, metadata, and data lines shall use ‘keyword = value’ notation,
abbreviated as KVN.
b) Only a single ‘keyword = value’ assignment shall be made on a line.
c) Keywords must be uppercase and must not contain blanks.
d) Any white space immediately preceding or following the keyword shall not be
significant.
e) Any white space immediately preceding or following the ‘equals’ sign shall not
be significant.
f) Any white space immediately preceding the end of line shall not be significant.
g) The order of occurrence of obligatory and optional KVN assignments shall be
fixed as shown in Table 3-1, Table 3-2, and Table 3-3.
3.3.3 VALUES
a) 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 blanks shall
be equivalent to a single blank.
b) Blanks must not appear within numeric values and time strings.
c) 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 .
d) Non-integer numeric values may be expressed in either fixed or floating-point
notation. Both representations may be used within an OPM.
e) 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. If the fractional part is zero,
the period and following zero(es) may be omitted. There must be a leading zero
if -1.0 < x < 1.0 .  The number of digits shall be 18 or less.
f) Non-integer numeric values expressed in floating point notation shall consist of a
sign, a mantissa, an alphabetic character indicating the division between the
CCSDS 502.0-B-1 Page 3-8 September 2004

26 © ISO 2006 – All rights reserved

CCSDS RECOMMENDATION FOR ORBIT DATA MESSAGES
mantissa and exponent, and an exponent, constructed according to the following
rules:
1) The sign may be “+” or “-”. If the sign is omitted, “+” shall be assumed.
2) 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.
3) The character used to denote exponentiation shall be “E” or “e”. If the
character indicating the exponent and the following exponent are o
...