TRACKING DATA MESSAGES · CCSDS RECOMMENDATION FOR TRACKING DATA MESSAGES CCSDS 50x.0-W-1 Page ii April 16, 2004 FOREWORD (WHEN THIS RECOMMENDATION IS FINALIZED, IT WILL CONTAIN THE

ConsultativeCommittee for

SpaceData Systems

RECOMMENDATION FOR SPACE DATA SYSTEM STANDARDS

TRACKING DATA

MESSAGES

CCSDS 50x-TDM.0-W-1.2 (DSB Draft #8)

WHITE BOOK

APRIL 2004

CCSDS RECOMMENDATION FOR TRACKING DATA MESSAGES

CCSDS 50x.0-W-1 Page i April 16, 2004

AUTHORITY

Issue: White Book, Issue 1 (Draft 1.1)

Date: April xx, 2004

Location: Pasadena, CA USA

(WHEN THIS RECOMMENDATION IS FINALIZED, IT WILL CONTAIN THE FOLLOWING STATEMENT OF AUTHORITY:)

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, 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 Program Integration Division (Code MT) National Aeronautics and Space Administration Washington, DC 20546, USA


CCSDS 50x.0-W-1 Page ii April 16, 2004

FOREWORD

(WHEN THIS RECOMMENDATION IS FINALIZED, IT WILL CONTAIN THE FOLLOWING FOREWORD:)

This document is a technical Recommendation for tracking data messages and has been prepared by the Consultative Committee for Space Data Systems (CCSDS). The set of tracking data messages described in this Recommendation is the baseline concept for tracking 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 tracking 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.


CCSDS 50x.0-W-1 Page iii April 16, 2004

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. – Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil. – Japan Aerospace Exploration Agency (JAXA)/Japan. – National Aeronautics and Space Administration (NASA)/USA. – Russian Space Agency (RSA)/Russian Federation. 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 50x.0-W-1 Page iv April 16, 2004

PREFACE

This document is a Proposed CCSDS Recommendation. Its ‘White Book” status indicates that the CCSDS believes the document to be technically immature and has not released it for formal review by technical organizations. As such, its technical content is highly unstable and several iterations of it will occur in response to comments received during the proposal development process. Implementers are cautioned not to fabricate any final equipment in accordance with this document’s technical content.

The structure and content of this White Book have been guided by the work of two other authors:

(1) “Navigation Working Group White Paper, Tracking Data Message Content Proposal, Draft 1.0 (September 2003)”, presented by Tomas Martin-Mur at the CCSDS Fall 2003 Meetings of the Navigation Working Group; and

(2) Orbit Data Messages Red Book 502.0-R-3, with principal author Charles H. Acton.

In this first formal draft, there are a number of author’s notes, indicated with the word “NOTE” in all caps, as well as author’s questions, indicated with the word “QUESTION” in all caps. As the issues associated with these notes and questions are resolved through subsequent drafts, these indicators will be removed from the document.

Also note that there is a strong intention to produce the first CCSDS reviewed version of this document with an XML-based TDM, however, there are some XML schema and implementation questions/issues that are still being researched. This version of the document specifies ASCII presentation, for the time being.


CCSDS 50x.0-W-1 Page v April 16, 2004

DOCUMENT CONTROL Document Title and Issue Date Status

CCSDS 50x-TDM.0-W-1 Tracking Data Messages, Draft 1 February 2004 Original Issue

CCSDS 50x-TDM.0-W-1.1 Tracking Data Messages, Draft 1.1 March 2004 With revisions from Tomas Martin-Mur

CCSDS 50x-TDM.0-W-1.2 Tracking Data Messages, Draft 1.2 April 2004 With preliminary comments from JPL Nav and CCSDS Nav WG


CCSDS 50x.0-W-1 Page vi April 16, 2004

CONTENTS

Section Page

1 INTRODUCTION..................................................................................................................1 1.1 PURPOSE..................................................................................................................... 1 1.2 SCOPE AND APPLICABILITY .................................................................................. 1 1.3 CONVENTIONS AND DEFINITIONS....................................................................... 2 1.4 REFERENCES ............................................................................................................. 2 1.5 STRUCTURE OF THIS DOCUMENT........................................................................ 3

2 OVERVIEW...........................................................................................................................4 2.1 THE TRACKING DATA MESSAGE (TDM)............................................................. 4 2.2 EXCHANGE OF MULTIPLE TDM’S......................................................................... 4

3 TRACKING DATA MESSAGE STRUCTURE AND CONTENT...................................5 3.1 TDM FILE HEADER ................................................................................................... 5 3.2 TDM GROUP HEADER.............................................................................................. 6 3.3 TDM TRACKING DATA RECORD SECTION......................................................... 9 3.4 AUTHOR’S DISCUSSION QUESTIONS ON TDM TRACKING DATA RECORDS13 3.5 TDM TRACKING DATA RECORD OPTIONS (FOR NAV WG DISCUSSION).. 13

4 TRACKING DATA MESSAGE SYNTAX .......................................................................14 4.1 TDM LINES ............................................................................................................... 14 4.2 TDM VALUES........................................................................................................... 15 4.3 UNITS IN THE TDM TRACKING DATA RECORD .............................................. 16 4.4 COMMENTS IN THE TDM ...................................................................................... 16

5 TDM EXAMPLE .................................................................................................................17


CCSDS 50x.0-W-1 Page vii April 16, 2004

CONTENTS (continued)

Figures Page

Figure 1 Tracking Data Message Example with Comments (Standard 2-Way) .......................... 17

Tables

Table 3-1 TDM File Layout Specifications ................................................................................... 5

Table 3-2 TDM File Header........................................................................................................... 6

Table 3-3 TDM Group Header........................................................................................................ 9

Table 3-4 Tracking Data Record Generic Format........................................................................ 10

Table 3-5 TDM Tracking Data Record Data Type Keywords ..................................................... 12

Table 5-1: Primary Requirements ............................................................................................... A-2

Table 5-2: Heritage Requirements .............................................................................................. A-3

Table 5-3: Desirable Characteristics ........................................................................................... A-3


CCSDS 50x.0-W-1 Page 1 April 16, 2004

1 INTRODUCTION

1.1 PURPOSE This Tracking Data Message (TDM) Recommendation specifies a standard for use in exchanging spacecraft tracking data between Member Agencies. Such exchanges are used for distributing tracking data output from routine interagency cross-supports in which spacecraft missions managed by one agency are tracked from a ground station managed by a second agency. Additionally, the ability to transfer tracking data between CCSDS Member Agencies facilitates the allocation of tracking sessions to alternate antenna resources and increases the ability of Member Agencies to tolerate availability issues with their primary antenna resources. This Recommendation has been developed via consensus of the Navigation Working Group of the CCSDS Mission Operations and Information Management Services (MOIMS) area.

This Recommendation includes sets of requirements and criteria that the message format has been designed to meet. (QUESTION: Is “includes” the correct word here? The Annex A that contains the requirements specifically states that the Annex is not part of the recommendation, with “not” in bold.) For exchanges where these requirements do not capture the needs of the participating agencies another mechanism may be selected.

The tracking data message in this version of the Recommendation is ASCII text formatted. While binary-based tracking data message formats are computer efficient and minimize overhead during data transfer, there are ground-segment applications for which an ASCII character-based message is more appropriate. For example, ASCII format character-based tracking data representations are 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, emails, documents or printers are possible without preprocessing. The penalty for this convenience is inefficiency. Description of the message formats based on XML will be added to a future issue of this draft Recommendation, as details emerge.

This message is suited to inter-agency exchanges that (1) involve automated interaction and/or (2) human interaction. The intent of the TDM is that it be fully self-contained, with no additional information required. However, for certain applications, it is anticipated that it may be desirable to use the information in a TDM in conjunction with related information contained in Orbit Data Messages (ODM) and/or Attitude Data Messages (ADM). The attributes of a TDM 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, assuming that the data volume is appropriately small; or suitable for use in computer-to-computer communication where the volume of data is large.

1.2 SCOPE AND APPLICABILITY

This Recommendation contains the specification for a tracking data message standard designed for applications involving tracking data interchange in space data systems. The rationale behind the design of the message is described in Annex A and may help the application engineer construct a



suitable message. Definition of the accuracy pertaining to any particular TDM is outside the scope of the Recommendation, and should be specified via Interface Control Document (ICD) between data exchange participants.

This draft Recommendation is applicable only to the message layout. Description of the message formats based on the use of eXtensible Markup Language (XML) is under investigation. It is anticipated that this will be added to this draft Recommendation in a future update. The transmission of the message between agencies is beyond the scope of this document, but could be based on the CCSDS Real-Time Tracking Data Transfer Service Specification currently under development (White Book status).

1.3 CONVENTIONS AND DEFINITIONS

The following conventions apply throughout this Recommendation:

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.

Definitions of time systems and reference frames are provided in Reference 1.

1.4 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/ ]

[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: XVIIth Plenary Assembly. Geneva: CCIR, 1990. Note to DSB: Research more current issue.



[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] Solar System Dynamics group at JPL [http://ssd.jpl.nasa.gov]

[6] Orbit Data Messages. Draft Recommendation for Space Data Systems Standards, CCSDS 502.0-R-3. Red Book. Issue 3. Washington, D.C.: CCSDS, November 2003.

[7] XML Schema Part 2: Datatypes, W3C Recommendation 02 May 2001, http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

[8] XML Schema Part 2: Datatypes Second Edition, W3C Proposed Edited Recommendation 18 March 2004, http://www.w3.org/TR/2004/PER-xmlschema-2-20040318/

[9] IEEE Standard for Binary Floating-Point Arithmetic, IEEE Standard 754-1985, IEEE, http://grouper.ieee.org/groups/754/

1.5 STRUCTURE OF THIS DOCUMENT

Chapter 2 provides a brief overview of the CCSDS-recommended Tracking Data Message (TDM).

Chapter 3 provides details about the structure and content of the TDM.

Chapter 4 provides details about the syntax used in the TDM.

Chapter 5 consists of an example TDM.

Annex A lists a set of requirements that were taken into consideration in the design of the TDM. It should be noted that a large number of these requirements were actually levied for the Orbit Data Message Recommendation (ODM), but seem to have applicability for the TDM as well. The ODM requirements were edited to remove requirements that were clearly inapplicable, and supplemented with a few additional requirements suggested by Tomas Martin-Mur in his concept paper.

Annex B lists a number of items that should be covered in interagency Interface Control Documents (ICD) prior to exchanging TDM’s 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 TDM.

Annex D is a list of Questions and “To-Do” items that will NOT be part of the final document.



2 OVERVIEW

2.1 THE TRACKING DATA MESSAGE (TDM)

Tracking information may be exchanged between Member Agencies by sending tracking data in a Tracking Data Message (TDM). The TDM shall be a text file consisting of tracking data for a single object, or for multiple objects, at multiple epochs contained within a specified time range. Generally, but not necessarily, the time range of a TDM may correspond to a “tracking pass”. The TDM shall be easily readable by both humans and computers. It shall be possible to exchange a TDM either as a real-time stream or as a file.

To aid in precision trajectory modeling, additional ancillary information may be included within the TDM if applicable (e.g., meteorological data, tropospheric data, accelerometer measurements). There are keywords in the TDM that allow the addition of such ancillary information.

The TDM file naming scheme shall be agreed to on a case-by-case basis between the participating agencies, typically using an Interface Control Document (ICD). The method of exchanging TDMs shall be decided on a case-by-case basis by the participating agencies and documented in an ICD.

2.2 EXCHANGE OF MULTIPLE TDM’S

For a given object, multiple tracking data messages may be provided in a message exchange session to achieve the tracking data requirements of the participating agencies. If tracking information for multiple objects is to be exchanged, the data may be included in a single TDM, or multiple TDM files may be used.



3 TRACKING DATA MESSAGE STRUCTURE AND CONTENT

The TDM shall be a digital file comprised of plain text lines. The file constituting a TDM shall be represented as a combination of:

a) a file header (see Section 3.1),

b) metadata group header (data about data) (see Section 3.2),

c) a set of tracking data records (see Section 3.3), and

d) optional comments (see Section 4.4).

TDM files shall have a set of minimum required sections; some sections may be repeated, as shown in Table 3-1. Note that each Group Header must be accompanied by a corresponding set of Tracking Data Records.

Required Sections File Header Group Header (Metadata) Tracking Data Records (Appropriate comments should be included, although not required.)

Allowable Repetitions of Required Sections

Group Header (Metadata) Tracking Data Records Group Header (Metadata) Tracking Data Records Group Header (Metadata) Tracking Data Records …etc. (Appropriate comments should also be included)

Table 3-1 TDM File Layout Specifications

3.1 TDM FILE HEADER

The TDM shall include a File Header that consists of information in KVN format that identifies the basic parameters of the message. The first File Header line must be the first non-blank line in the file.

A description of TDM File Header items and values is provided in Table 3-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 not obligatory.

Only those items shown in Table 3-2 shall be used in a TDM File Header.

Keyword Description Examples Obligatory CCSDS_TDM_VERS Format version in the form of ‘x.y’, where ‘y’

shall be incremented for corrections and minor changes, and ‘x’ shall be incremented for major changes.

1.0 Yes

CREATION_DATE File creation date/time in one of following formats: YYYY-MM-DDThh:mm:ss[.tttt] or YYYY-DDDThh:mm:ss[.tttt] 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[.tttt]” is the UTC time in hours, minutes, seconds, and optional fractional seconds. All fields require leading zeros.

2001-11-06T11:17:33

2002-204T15:56:23

Yes

CREATOR Creating agency CNES, ESOC, GSFC, GSOC, JPL, JAXA, etc.

Yes? No?

TIME_SYSTEM Time system used for timetags in the associated Tracking Data Records. Should be UTC for Earth-based data. Allowed values are same as in ODM, but also could include a local spacecraft clock, as applicable.

UTC, TAI, TT, GPS, TDB, TCB

Yes

Table 3-2 TDM File Header

The TDM File Header shall provide a CCSDS Tracking Data Message version number that identifies the format version; this is included to anticipate future changes. The version keyword is CCSDS_TDM_VERS and the value shall have the form of x.y where y is incremented for corrections and minor changes, and x is incremented for major changes. The initial version accepted by the CCSDS as an official Recommended Standard (“Blue Book”) shall be 1.0.

The TDM File Header shall include the CREATION_DATE keyword with the value set to the Coordinated Universal Time (UTC) the file was created, using the ISO standard.

The TIME_SYSTEM value must remain fixed within a TDM.

3.2 TDM GROUP HEADER

The TDM shall include a Group Header that contains configuration details (metadata) applicable to a group of tracking data records.

A single TDM Group Header shall precede each block of Tracking Data Records. Multiple occurrences of a TDM Group Header followed by a block of Tracking Data Records may be



contained in a single TDM. The beginning of each TDM Group Header shall be indicated by the string "META_START" on a separate line. After each metadata group (and before the associated tracking data block) the string "META_STOP” shall appear on a separate line. The “META_START” and “META_STOP” keywords are used to facilitate file parsing. NOTE: The “META_START” and “META_STOP” keywords will not be necessary in the planned XML implementation.

Table 3-3 specifies for each group header item:


(b) a short description of the item,

(c) examples of allowed values, and

(d) whether the item is obligatory or not obligatory.

Only those keywords shown in Table 3-3 shall be used in a TDM Group Header. Obligatory items shall appear in every TDM Group Header. Items that are not obligatory may or may not appear in any given TDM Group Header, at the discretion of the file creator.



Keyword Description Examples Obligatory META_START This keyword delineates the start of the TDM

Group Header (metadata block) within the message. It must appear on a line by itself.

N/A Yes

TRANSMITTER_n Transmitting party. If more than one transmitter can be used, this keyword shall specify the transmitter that was used. This keyword applies to the ground system uplink for 2-way data or the spacecraft for 1-way data. For spacecraft identifiers, there is no CCSDS-based restriction on the value for this keyword, but names should be drawn from the SPACEWARN Bulletin (reference [2]), which include Object name and international designator of the participant.

DSS-63 S400K ROSETTA Quasar catalog name

Yes

TRANSPONDER_n Transponding party. If more than one transponder can be used, it shall specify the transponder that was used. There is no CCSDS-based restriction on the value for this keyword, but names should be drawn from the SPACEWARN Bulletin (reference [2]), which include Object name and international designator of the participant. NOTE: transponder is not applicable for 1-way data.

EUTELSAT W1 MARS PATHFINDER STS 106 NEAR

Yes

RECEIVER_n Receiving party. If more than one receiver can be used, it shall specify the receiver that was used.

DSS-15 Yes

MODULUS Modulus for ambiguous data. It should be expressed in the same units as those of the corresponding data type.

2**24 No

COMPRESSION_TIME Compression time for Doppler data or for the creation of normal points.

60 No

ACCEL_FRAME Name of the reference frame in which the acceleration data are given. Values for this keyword should be restricted to reference frames described in Navigation Definitions and Conventions (reference [1]).

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 coord frame)

ACCEL_ORIGIN Origin of accelerometer 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 a spacecraft. There is no CCSDS-based restriction on the value for this keyword, but for natural bodies names should be drawn from the NASA/JPL Solar System Dynamics Group (Ref [5]).

EARTH EARTH BARYCENTER MOON SOLAR SYSTEM BARYCENTER SUN JUPITER BARYCENTER STS 106 EROS

START_TIME Start time of total time span covered by tracking data immediately following this metadata block, in one of the two following formats: YYYY-MM-DDThh:mm:ss[.tttt] YYYY-DDDThh:mm:ss[.tttt] where “YYYY” is the year, “MM” is the 2 digit

1996-12-18T14:28:15.1172 1996-277T07:22:54

Yes



Keyword Description Examples Obligatory month, “DD” is the 2 digit day, “DDD” is the 3 digit day of year, “T” is constant, “hh:mm:ss[.tttt]” is the UTC time in hours, minutes, seconds, and optional fractional seconds. All fields require leading zeros.

STOP_TIME Stop time of total time span covered by tracking data immediately following this metadata block, in one of the two following formats: YYYY-MM-DDThh:mm:ss[.tttt] YYYY-DDDThh:mm:ss[.tttt] 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[.tttt]” is the UTC time in hours, minutes, seconds, and optional fractional seconds. All fields require leading zeros.

1996-12-18T14:28:15.1172 1996-277T07:22:54

Yes

META_STOP This keyword delineates the end of the TDM Group Header (metadata block) within the message. It must appear on a line by itself.

N/A Yes

Table 3-3 TDM Group Header

3.3 TDM TRACKING DATA RECORD SECTION

The TDM Tracking Data Record Section shall consist of one or more Tracking Data Records. Each Tracking Data Record shall have the following generic format:

keyword = timetag observable_1 [observable_2 ... observable_n]

Each tracking data record shall contain one or more observables that depend upon the data type keyword used. A list of the applicable keywords and their associated observable values is in Table 3-5 later in this section. In any particular TDM, all keywords shall be optional because they depend upon the characteristics of the tracking pass, however, the keyword associated with at least one tracking data type must be present. If one of the observables is not present for a keyword for which multiple observables applies, then the string “N/A” must be entered into the data at that position. “N/A” values shall not be used in any computations.

The Tracking Data Record Section in the TDM shall be delineated by the “DATA_START” and “DATA_STOP” keywords. These keywords are intended to facilitate file parsing, and will also serve to advise the recipient that they have received all the data associated with the immediately preceding TDM Group Header (rationale for including this is that data volumes can be very large, so knowing when the data ends is desirable). The TDM recipient may process the “DATA_STOP” keyword as a “local” end-of-file marker.

Each tracking data record including the timetag must be provided on a single line. The order in which observables are listed in the Tracking Data Record shall be fixed because it is dependent on the data type keyword used for the given line.



At least one blank character must be used to delimit the observables in each Tracking Data Record.

Tracking Data Records must be ordered by increasing time, and each keyword/timetag combination must be unique within a given TDM (i.e., because of the chronological order, no keyword/timetag combination may be repeated). The time duration between timetags may be constant, or may vary, within any given TDM. In general, all acquired data should be transferred from the service provider agency to the customer agency in a cross-support activity, not just an edited data set. Data sampling to reduce data volume may be performed for high volume data if a previous agreement is documented in an ICD. (NOTE: This paragraph is extracted in large part from the old 501.0 Blue Book.) The tracking data observables shall be corrected with the best estimate of all known instrument calibrations, such as path delay calibrations between the reference point and the tracking equipment. Every tracking instrument shall have a defined reference location that could be defined in the OEM format, possibly extended to define spacecraft body-fixed axis. This reference location shall not depend on the observing geometry. The timetag of the tracking data shall always be the best estimate of the reception time at the instrument reference point. The observable shall be converted to an equipment-independent quantity, e.g. frequencies and phase counts shall be reported at the sky level. Other corrections applied to the data, like media corrections or transponder delays, shall be agreed by the service provider and the customer Agencies. The message should include a comment section that lists which corrections have been applied. These measures should reduce the requirement for consumers of tracking data to have detailed knowledge of the underlying structure of the hardware/software system which performed the measurements. The generic format of a Tracking Data Record is shown in the following table: Keyword Description Examples Obligatory DATA_START Delineates start of block of Tracking Data

Records. N/A Yes

<keyword> Data type keyword from a list specified in the TDM recommendation.

See Table 3-5 Yes (at least one)

<timetag> Timetag of the tracking observable. Timetags shall be corrected to the receiving instrument reference point. Timetags shall be in chronological sequence for a given keyword. Tracking data shall be tagged in the applicable TIME_SYSTEM. Format shall be the same as for START_TIME and STOP_TIME keywords.

2003-205T18:00:01.275 Yes

<observable(s)> Observable(s) in units defined in the TDM recommendation. Some data types may have more than one observable.

See Table 3-5 Yes (at least one)

DATA_STOP Delineates end of block of tracking data N/A Yes

Table 3-4 Tracking Data Record Generic Format



The TDM Tracking Data Record keyword assignments are shown in Table 3-5, which specify for each keyword:


(b) the data type to which it applies,

(c) applicable units for the associated observables, and

(d) comments.

All data type keywords in the tracking data section of the TDM must be from Table 3-5. For some keywords there are no definitive lists of authorized values maintained by a control authority; the recommended references are the best known candidates for authorized values to date. The standard tracking data types are extended to also cover some of the ancillary data that may be required for precise trajectory determination work. Table 3-5 identifies the most frequently used data and ancillary types. Where multiple observables with different units are specified for the same keyword, the observables in the Tracking Data Record must appear in the specified order.



Keyword Data type Units Comments A_RANGE Ambiguous range Range Units

dB-Hz The definition of the range unit should be specified in an ICD written by the service provider and customer agency. It may have the Pr/N0 as second component.

OPTICAL Optical Line/Pixel Body fixed frame of the camera ????? Charged particle delay

(Total Electron Count) TECU Along the line of sight

ACCELERATION Accelerometer m/s**2 The frame must be properly identified (see ACCEL_FRAME and ACCEL_ORIGIN in the Group Header)

ANGLES Angles Degrees Degrees

This data may have two components. There may be a number of different data types:

- Azimuth / elevation - Hour angle / declination - X/Y where +X is East - X/Y where +X is South - Defined with respect to body fixed axes.

CLOCK_BIAS Clock bias Sec Timetags should be corrected, but when that is not possible (e.g. for delta types), then this data type may be used.

CLOCK_DRIFT Clock drift s/s Clock drift for spacecraft-spacecraft exchanges DELTA_DELAY Delta delay Seconds Two receivers and/or two transmitters/transponders. DELTA_PHASE_CT Delta phase count Cycles Two receivers and/or two transmitters/transponders. DELTA_RCVFREQ Delta received

frequency Hz Two receivers and/or two transmitters/transponders.

METEO Meteorological K

mbar %

Temperature, pressure, relative humidity

RANGE Range Seconds “Start”|“End”

Satellite Laser Ranging (SLR), skin radar, proximity radar. Range data should be provided as round trip light time in seconds and decimal fractions (one way light time when it is the case). The timetag (start or end of the round trip) should be specified with the range observables.

RCVFREQ_n Received frequency Hz dB-Hz

Replaces the classical Doppler data type. A compression time value must be used. The SNR/Pc/N0 may appear as the second component

STATE State m m m m/s m/s m/s

e.g. from a GPS receiver, three or six components, different types for different frames [Ref 6].

TOTAL_PHASE_CT Total count phase Cycles dB-Hz

Current count (not delta count). It may require a cycle slip indicator. It may have the SNR/Pc/N0 as the second component

TROPO Troposphere Meters Meters

Dry and wet zenith delay, agreed upon elevation mapping

XMTFREQ Transmitted frequency Hz Hz/s seconds

It may have three components, starting frequency, rate and duration of applicability.

Table 3-5 TDM Tracking Data Record Data Type Keywords



3.4 AUTHOR’S DISCUSSION QUESTIONS ON TDM TRACKING DATA RECORDS

a) For the “ANGLES” keyword, there would seem to be a requirement for a companion keyword to indicate which type of angle measurement the data represents, or perhaps qualifications on the units (e.g., degrees-AZEL, degrees-HRDEC, degrees-+XEY, degrees-+XSY, etc.)

b) For the “DELTA_xxx” keywords, how are the applicable pairs of transmitters/transponders associated? Is this material for COMMENTs? ICD? keywords that explain the mapping?

c) For the “RANGE” keyword, how are the station delay, station location and Z-height information conveyed? Note that old 501.0 Blue Book relegates these to an ICD. Perhaps these corrections are to be applied to the range data prior to being written to the TDM? The station location could be provided via the STATE keyword.

d) For non-standard 1-way, 2-way, 3-way tracking sessions, how is the sequence of parties indicated (e.g., “4-way” relays, spacecraft-to-spacecraft, etc.).

e) Is a tracking data record sequence counter desirable for accountability purposes?

3.5 TDM TRACKING DATA RECORD OPTIONS (FOR NAV WG DISCUSSION)

There are many possible ways of listing tracking data in a file. The proposal that is shown in the foregoing sections is that the Tracking Data Message will start with a File Header that will identify it as a TDM and will show the version number. After that it will have data groups, each of them with a Group Header and one or more Tracking Data Records. There are other possibilities, such as:

a) Having all the TDM Group Header information in every Tracking Data Record, and eliminating the TDM Group Header as a distinct section in the TDM (this is an “SFDU-like” option).

b) Having the Group Header information assigned to an identifier, index, or associative token, that then appears in each Tracking Data Record.

c) Having the TIME_SYSTEM keyword in the Group Header instead of the File Header.

d) Expanding the number of Tracking Data Record keywords so that each line of the TDM only contains a single value assignment.

e) ????



4 TRACKING DATA MESSAGE SYNTAX

The TDM shall observe the syntax described in Sections 4.1 through 4.4.

4.1 TDM LINES

The TDM file shall consist of a set of TDM Lines. The TDM line must contain only printable ASCII characters and blanks. ASCII control characters (such as TAB, etc.) must not be used, except as indicated below for the termination of the TDM Line. A TDM Line must not exceed 254 ASCII characters and spaces (excluding line termination character[s]). (NOTE: line size is 254 for OEM... probably need long lines for TDM.).

Each TDM Line shall be one of the following:

a) File Header line

b) Group Header line

c) Tracking Data Record line

d) Comment line

e) blank line

All File Header, Group Header, and Tracking Data Record lines shall use “keyword = value” syntax, abbreviated as KVN. The following distinctions in KVN syntax shall apply for TDM lines:

a) TDM Lines in the File Header and Group Header sections shall consist of a keyword, followed by an equals sign “=”, followed by a single value assignment.

b) TDM Lines in the Tracking Data Record sections shall consist of a keyword, followed by an equals sign “=”, followed by two or more values (timetag plus at least one observable). The number of values present on a Tracking Data Record line varies depending on the keyword on that line; several keywords are defined to have more than one applicable observable value. Each value in the Tracking Data Record line must be separated by white space.

Keywords must be uppercase and must not contain blanks.

Any white space immediately preceding or following the keyword is not significant.

Any white space immediately preceding or following the equals sign “=” is not significant.

Any white space immediately preceding the end of line is not significant.

Blank lines may be used at any position within the TDM.



TDM 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.

4.2 TDM VALUES

A non-null value field must be specified for each obligatory keyword provided. If an actual observable value is not available, then “N/A” must be the value specified for an obligatory keyword. 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: -9223372036854775808 <= x <= +9223372036854775807 .

Non-integer numeric values may be expressed in either fixed or floating-point notation. Both representations may be used within a TDM. 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 maximum number of digits allowed must be greater than or equal to 18 to satisfy the requirements for minimally conforming XML processors. 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 period “.” 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 0 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 “+” is 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 “long integer”, “decimal” and “double” respectively. The



specifications for floating point values conform to the IEEE double precision type. Floating point numbers in extended-single or extended-double precision may be represented, but do require an ICD between participating agencies due to their implementation specific attributes.

Text value fields may be constructed using mixed case: case is not significant.

Blanks shall be prohibited within numeric values and time values.

Individual blanks between values shall be retained (shall be significant) but multiple blanks are equivalent to a single blank. In value fields that are text, an underscore shall be considered part of the value. (NOTE: This is different from ODM, which considers the underscore as equivalent to blank, but seems to be necessary for the TDM due to the fact that multiple values may occur after a single keyword).

4.3 UNITS IN THE TDM TRACKING DATA RECORD

For documentation purposes and clarity, units may be included as ASCII text after a value. If units are displayed, they must match the units specified in Table 3-5. If units are displayed,

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]”), and

c) exponents of units shall be denoted with a double asterisk (i.e. “**”).

The units documentation may be constructed using mixed case; case is not significant.

4.4 COMMENTS IN THE TDM

Comments may be used to provide any pertinent information associated with the data that is not covered via one of the keywords. This additional information may aid in consistency checks and elaboration where needed. Comments shall not be required for successful processing of a file. Comment lines shall be optional and may occur at any position in the File Header or Group Header. Comments shall not occur between Tracking Data Records.

All comment lines shall begin with the “COMMENT” keyword followed by a single space. The “COMMENT” keyword must appear on every comment line, not just the first comment line, and it must begin in column one. After the keyword, the remainder of the line shall be the comment value. White space shall be retained (is significant) in comment values.

The following comments are recommended:

Corrections applied to data: (e.g., ranging station delay calibration, Z-height correction, etc.):

COMMENT Range calibration 155853.19 ns applied COMMENT Z-height correction –240.515 ns applied



5 TDM EXAMPLE

The TDM could be formatted in many different ways, bit packed, byte packed, PVL, XML... Figure x-y is an example of how an ASCII formatted KVN implementation of a Tracking Data Message fragment similar to that of the Orbit Ephemeris Message (OEM) (Ref [6]) could appear.

CCSDS_TDM_VERS = 1.0 CREATION_DATE = 2003-268T20:15:00 CREATOR = NASA/JPL TIME_SYSTEM = UTC COMMENT TDM example created by Tomas Martin-Mur (NASA/JPL) META_START TRANSMITTER_1 = DSS-15 TRANSPONDER_1 = SIRTF RECEIVER_1 = DSS-15 COMPRESSION_TIME = 60 META_STOP DATA_START METEO = 2003-268T13:10:00 288.0 1023.4 45.3 XMTFREQ = 2003-268T13:12:10 7123456789.000000 0.0 RCVFREQ = 2003-268T13:12:30 8369351234.567890 23.45 RCVFREQ = 2003-268T13:13:30 8369351245.567890 23.35 RCVFREQ = 2003-268T13:14:30 8369351256.567890 23.25 RCVFREQ = 2003-268T13:15:30 8369351267.567890 23.15 DATA_STOP

Figure 1 Tracking Data Message Example with Comments (Standard 2-Way)

{ TC \f G "5-1 OEM Example "}


CCSDS 50x.0-W-1 Page A-1 April 16, 2004

ANNEX A

RATIONALE FOR TRACKING DATA MESSAGES

(This annex is not part of the Recommendation)

A1 GENERAL

This annex presents the rationale behind the design of the Tracking Data Message. It may help the application engineer construct 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. 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:

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 or its Member Agencies.

Heritage Requirements - These are additional requirements that derive from pre-existing Member Agency requirements, conditions or needs. Ultimately these carry the same weight as the Primary Requirements. This Recommendation reflects heritage requirements pertaining to some of the panels' home institutions collected during the preparation of the Recommendation; it does not speculate on heritage requirements that could arise from other Member Agencies. Corrections and/or additions to these requirements are expected during future updates.

Desirable Characteristics - These are not requirements, but they are felt to be important or useful features of the Recommendation.



A2 PRIMARY REQUIREMENTS ACCEPTED FOR TRACKING DATA MESSAGES

Table 5-1: Primary Requirements{ TC \f T "A-1 Primary Requirements"}

Requirement Trace Data must be provided in digital form (computer file).

2.1

The object being tracked and all primary resources used in the tracking session must be clearly identified and unambiguous. 3.2

The object being tracked must be clearly identified and unambiguous. 3.2

Time measurements (time stamps, or epochs) must be provided in a commonly used, clearly specified system. 3.2

The time bounds of the tracking data must be unambiguously specified. 3.2

The standard must provide for clear specification of units of measure. 4.3

Files must be readily portable between and useable within ‘all’ computational environments in use by Member Agencies. 3

Files must have means of being uniquely identified and clearly annotated. The file name alone is considered insufficient for this purpose. 3.1

File name syntax and length must not violate computer constraints for those computing environments in use by Member Agencies. Annex B

Acclerometer information must be provided in a reference frame that is clearly identified and unambiguous. 3.3

The Tracking Data Message format shall be independent of the equipment that was used to perform the tracking. 3, 4.1

Every tracking instrument shall have a defined reference location that could be defined in the OEM format, possibly extended to define spacecraft body-fixed axis. This reference location should not depend on the observing geometry.

3.3

The timetag of the tracking data shall always be the best estimate of the reception time at the instrument reference point. 3.3

The observable shall be corrected with the best estimate of all known tracking instrument calibrations, such as path delay calibrations between the reference point and the tracking equipment.

3.3

The observable shall be converted to an equipment-independent quantity, e.g. frequencies and phase counts shall be reported at the sky level. 3.3

Other corrections applied to the data, such as media corrections or transponder delays, shall be agreed by the service providing and the customer Agencies. 4.4



Table 5-2: Heritage Requirements{ TC \f T "A-2 Heritage Requirements"}

Requirement Trace

The standard shall be, or must include, an ASCII format. 4.1

The standard shall not require software supplied by other agencies. 3, 4.1

Table 5-3: Desirable Characteristics{ TC \f T "A-3 Desirable Characteristics"}

Requirement Trace

The standard should apply to non-traditional objects, such as landers, rovers, balloons, spacecraft-spacecraft tracking data exchange, etc.

N/A

The standard should be extensible with no disruption to existing users/uses. 3.1

Keywords in the TDM should be the same as those in the ODM and ADM, where applicable. 3.1, 3.2, 3.3, 4.4


CCSDS 50x.0-W-1 Page B-4 April 16, 2004

ANNEX B

ITEMS FOR AN INTERFACE CONTROL DOCUMENT

(This annex is not part of the Recommendation)

In several places in this document there are references to items which should be specified in an Interface Control Document (ICD) between agencies participating in an exchange of tracking data. The ICD should be jointly produced by both Agencies participating in a cross-support involving the collection, analysis and transfer of tracking data. This section compiles those recommendations into a single section. NOTE: Some of the items listed here were extracted from the old 501.0 Blue Book, and may no longer be necessary in an ICD given the TDM.

EDITOR’S COMMENT: The greater the amount of material specified via ICD, the lesser the utility/benefit of the TDM (custom programming will be required to tailor software for each ICD).

1. TDM file naming conventions 2. Method of physically exchanging TDM’s 3. Definition of accuracy requirements pertaining to any particular TDM

4. Information which must appear in comments for any given TDM exchange 5. Description of any ancillary data not already included in the Tracking Data Record definition 6. Complete description of the station location, including the earth-centered coordinates with

their defining system, and the relative geometry of the tracking point and cross axis of the antenna mount

7. Source of polar motion values (e.g., BIH or Naval Observatory) and their use 8. Definition of the range unit 9. Data sampling conditions, if any 10. Standard corrections that will (or will not) be applied to the data (e.g., tropospheric,

meteorological, etc.) 11. Turnaround ratios (?) 12. 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 participating agencies.


CCSDS 50x.0-W-1 Page C-5 April 16, 2004

ANNEX C

ABBREVIATIONS AND ACRONYMS ADM Attitude Data Message ASCII American Standard Code for Information Interchange CCIR International Coordinating Committee for Radio Frequencies CCSDS Consultative Committee on Space Data Systems EME2000 Earth Mean Equator and Equinox of J2000 (Julian Date 2000) GPS Global Positioning System ICD Interface Control Document ICRF International Celestial Reference Frame IEC International Electrotechnical Commission ISO International Standards Organization ITRF International Terrestrial Reference Frame KVN Keyword = Value notation MOIMS Mission Operations and Information Management Services ODM Orbit Data Message OEM Orbit Ephemeris Message OPM Orbit Parameter Message PVL Parameter Value Language TDM Tracking Data Message TOD True Equator and Equinox of Date UTC Coordinated Universal Time XML eXtensible Markup Language


CCSDS 50x.0-W-1 Page D-6 April 16, 2004

ANNEX D TO DO / QUESTIONS

1. Fix page numbering 2. Fix Table, Figure captions (extra garbage when printing) 3. Compare to TRK-2-34 4. Fix Table numbering in Annexes 5. How important is it to support 4-Way tracking or spacecraft-spacecraft exchanges in this

version of the standard? How is the sequence of participants to be specified? 6. Is it necessary to have a way to convey transponder delays (e.g., for spacecraft-spacecraft

ranging)? Note: This info is not contained in TRK-2-18. 7. Research XDR & SAN formats as way to provide efficient XML implementation 8. Research concept of integrated ODM/ADM/TDM XML schema 9. How to handle issues of remote electronics? 10. Understand how SLE Tracking Service will impact this (if at all). 11. Apply applicable ODM RID’s to the TDM. 12. Is it desirable to minimize the necessity for inference? 13. Is specification of frequency band required? or should this be inferred by examining

frequency? 14. Is specification of a numeric data type (as in TRK-2-18) more desirable than a KVN

notation? Note this could reduce volume of data transferred. 15. Is it desirable to include flags to indicate data that may be degraded (question: how is this

determined in a real-time exchange)? 16. Need more TDM samples.