1 W.Hell (ESA) March 2015 Validated TDM Delivery Considerations Validated TDM Delivery Considerations March 2015

2 W.Hell (ESA) March 2015 Who uses the data to be exchanged? In existing cross-support arrangements, data related to navigation such as radiometric observables and trajectory predicts are exchanged between the navigation / flight dynamic teams on the cross support provider and the cross support user side The reason is that in general these teams need to perform the conversion of such data to other formats and products before they can be used for the actual space flight operation support It therefore makes sense to ‘bundle’ the exchange of navigation data in one interface

3 W.Hell (ESA) March 2015 Who uses the data to be exchanged? If Service Management offers the appropriate mechanism for the transfer of predicts, it should also accommodate the handling of observables If there are compelling reasons to come up with a different mechanism for the observables, then we should ‘re-host’ the predicts as well

4 W.Hell (ESA) March 2015 Why do today’s (bilateral) navigation ICDs have that many pages NOTE: The focus in the following is on the exchange of radiometric observables, but is likely to be also applicable to other types of navigation data Legend: Provider / Originator characteristic Fixed in Offline TDM Controlled via Service Management prior to the data collection

5 W.Hell (ESA) March 2015 Why do today’s (bilateral) navigation ICDs have that many pages Definition of accuracy requirements pertaining to any particular TDM Method of exchanging TDMs (e.g., post-processed SFTP, real-time stream,etc.) Whether the KVN or XML format of the TDM will be exchanged (could be made a user choice in case a pull interface is used) Frequency of exchange, special types of exchange, and conditions under which multiple TDMs will be exchanged (e.g., launch supports with periodic TDMs, critical maneuvers, orbit insertions, etc.) TDM file naming conventions (may require some registries)

6 W.Hell (ESA) March 2015 Why do today’s (bilateral) navigation ICDs have that many pages List of valid values that may be used for ‘ORIGINATOR’ keyword in the TDM Header (but the TDM format may be a problem) Specific TDM version number(s) that will be exchanged (bilateral variants should be avoided) Antenna geometry, if not accommodated by built-in values of ‘ANGLE_TYPE’ keyword The list of eligible names that is used for PARTICIPANT keywords (but the TDM format may be a problem) Definitions of ‘RAW’, ‘VALIDATED’, and ‘DEGRADED’ as they apply to data quality for a particular exchange (DATA_QUALITY keyword) – if anything but ‘VALIDATED’ shall be supported at all

7 W.Hell (ESA) March 2015 Why do today’s (bilateral) navigation ICDs have that many pages The range of frequencies associated with each value of the ‘TRANSMIT_BAND’ and ‘RECEIVE_BAND’ metadata keywords If more than five participants are necessary, special arrangements are necessary. When all the data in a TDM Segment is media related or weather related, the observable may be relative to a reference location within the tracking complex; the methods used to extrapolate the measurements to other antennas should be specified in the ICD Complete description of the station locations and characteristics

8 W.Hell (ESA) March 2015 Why do today’s (bilateral) navigation ICDs have that many pages Whether TRANSMIT_DELAY and RECEIVE_DELAY are processed by the producer or the consumer of the tracking data Special sort orders that may be required by the producer or recipient – can be avoided by placing one observable type only in any TDM Spin correction arrangements (who will do the correction, the agency providing the tracking or the agency that operates the spacecraft) – should only be done by the spacecraft operating agency Correction algorithms that are more complex than a simple scalar value

9 W.Hell (ESA) March 2015 Why do today’s (bilateral) navigation ICDs have that many pages Standard corrections that will (or will not) be applied to the data (e.g., tropospheric, meteorological, media, transponder, etc.), miscellaneous corrections Definition of the range unit, if it is not kilometers or seconds Equation for calculation of four-way Doppler shift, if applicable Transponder turnaround ratios necessary to calculate predicted downlink frequency and the Doppler measurement; also includes cases such as dual uplink where a ‘beacon’ or ‘pilot’ frequency is used (e.g., TDRS, DRTS, COMETS) – could be resolved by an appropriate ‘PARTICIPANT’ registry

10 W.Hell (ESA) March 2015 Why do today’s (bilateral) navigation ICDs have that many pages Whether or not it is necessary to distinguish the separate Slant Total Electron Count contributions between ionospheric and interplanetary STEC Elevation mapping function for the tropospheric data Recommended polynomial interpolations for tropospheric data If non-standard floating-point numbers in extended-single or extended-double precision are to be used, then discussion of implementation- specific attributes is required. Information which must appear in comments for any given TDM exchange

11 W.Hell (ESA) March 2015 Why do today’s (bilateral) navigation ICDs have that many pages Description of any ancillary data not already included in the Tracking Data Record definition Interagency Information Technology (IT) security requirements in TDMs – presumably implemented by the underlying GFT Time systems not shown in annex A – there should not be any and perhaps only a subset of those listed in annex A Reference frames not shown in annex A – there should not be any and perhaps only a subset of those listed in annex A Whether the mean range rate for 2W and/or 3W Doppler is based on the one-way light time or two- way light time

12 W.Hell (ESA) March 2015 Why do today’s (bilateral) navigation ICDs have that many pages Whether the RANGE observable for 2W and/or 3W range is based on the round trip light time, or half the round trip light time

13 W.Hell (ESA) March 2015 Prerequisites for the file transfer For the logon to the peer entitie’s file server, at least the following information must be known:  user name  password  IP address of the server It needs to be known if and which file compression method is used and the associated file extension must be agreed The directory structure needs to be known where a distinction between mission-specific files and general files (e.g. media calibration) should be made A file naming convention needs to be agreed

14 W.Hell (ESA) March 2015 Prerequisites for the file transfer Example of a file naming convention:  yyyydddhhmmSCssssDSSnnn[DSSnnn_DDOR].tdm.txt where:  The time in the file name is UTC (yyyy is the four-digit year, ddd is the three-digit day-of-year (001 thru 366), hhmm represents the time of the earliest tracking sample, hh is the two-digit hour into the day (00 thru 23), and mm is minutes into the hour (00 thru 59)  SC is fixed, and denotes that the spacecraft ID is to follow and ssss is the spacecraft ID (with leading zeros omitted)  DSS is fixed and denotes that the DSS ID is to follow. If delta-DOR data is present, this DSS ID is for a first DSS, nnn is the DSS ID (with leading zeros omitted) .tdm is a fixed suffix and identifies the file as being in TDM format; .txt identifies the file as being an ASCII text file.