測距・追跡#86

TDM (Tracking Data Message) — 測距・ドップラーの生データを軌道決定に渡す標準フォーマット

測距値やドップラー値は、それ単体の数値では軌道決定に使えない。ターンアラウンド比・測距モード・積分時間といった文脈情報がなければ、同じ数値が全く違う物理量を意味してしまうからだ。CCSDS 503.0-BのTracking Data Message (TDM)がメタデータ部とデータ部の2層構造でこの問題をどう解決し、地上局から軌道決定ソフトウェアへ観測量を届けているかを見る。

前提知識: SLE (Space Link Extension) — 地上局とミッション運用センターをつなぐ標準インターフェース

TDMCCSDS軌道決定メタデータドップラー

この回で学ぶこと

非再生測距と再生測距の回では、PN符号の往復遅延から距離を求める仕組みを、トランスポンダの回ではコヒーレントドップラーからどう探査機の視線速度を求めるかを、DDORの回では電波干渉法から角度情報を得る方法を、それぞれ数式で見てきました。これらはすべて、地上局のRF受信チェーンが生成する「観測量(observable)」です。

しかし、ここでまたSLEの回で扱ったのと同じ種類の疑問が生まれます。この測距値やドップラー値は、地上局からどうやって軌道決定ソフトウェアまで届くのでしょうか。 SLEの回では、地上局が受信した「フレーム」というテレメトリ・コマンドの伝送単位が、RAF・RCFといったサービスを介してミッション運用センター(MOC)まで運ばれる仕組みを見ました。しかし測距値・ドップラー値・信号強度といった観測量は、そもそもフレームの中身(ペイロード)とは別の場所から生まれます。これらは探査機のトランスポンダが折り返した搬送波の位相そのもの、あるいはPN符号の相関ピークの位置から、地上局の受信機がリアルタイムに算出する数値であり、テレメトリフレームのように符号化・復号されて出てくるデータではありません。

この回で扱う TDM (Tracking Data Message) は、CCSDS 503.0-Bに規定される、まさにこの「測距・ドップラー・角度といった生の観測量そのもの」を標準フォーマットで表現し、地上局からミッション運用センターや軌道決定ソフトウェアへ届けるためのメッセージ形式です。SLEが「フレームという伝送単位をどう運ぶか」というトランスポート層の問題を解決したのに対し、TDMは「観測量という物理量をどう表現するか」というデータフォーマット層の問題を解決します。この回では、TDMがなぜメタデータ部とデータ部という2層構造を持つのか、そしてなぜ観測データにこれほど詳細な文脈情報が必要なのかを、これまで学んだ測距・ドップラーの数式を踏まえて理解していきます。

直感的導入: 「測距値 = 12345.678」という数字だけでは何もわからない

具体例から始めましょう。ある地上局が、探査機との測距パスの結果として次のような1行のデータを出力したとします。

\text{RANGE} = 12345.678 \quad (\text{単位不明})

この数字だけを渡されて、あなたは何ができるでしょうか。答えは「何もできない」です。なぜなら、この数値を物理的な距離に変換するには、少なくとも次のような情報がすべて揃っていなければならないからです。

単位は何か: 光時間(秒)なのか、レンジ単位(RU, Range Unit)なのか、キロメートルなのか。
測距モードは何か: 非再生測距(ターンアラウンド)なのか、再生測距なのか。この違いだけで、往復雑音の重畳の有無やトランスポンダ遅延の補正方法が変わることを再生測距の回で見ました。
ターンアラウンド比は何か: トランスポンダの回で見た $G_2/G_1$ (たとえばSバンドの $240/221$ )が分からなければ、アップリンク・ダウンリンクの周波数関係すら定まりません。
測距符号のモジュラス(ambiguity resolution周期)は何か: 再生測距の回で見た「PN符号は周期的に繰り返すため、符号1周期を超える遅延は区別できない」というアンビギュイティの問題を解くには、モジュラス値が必要です。
地上局・探査機側の装置遅延はすでに補正済みか: 補正済みの値なのか、生の往復時間そのものなのかで、後段の軌道決定ソフトウェアが行うべき処理がまったく変わります。

つまり、測距値やドップラー値という数値そのものは、それを生成した「文脈」を伴わなければ物理的に無意味なのです。ドップラー値についても事情は同じで、トランスポンダの回で見たOne-way・Two-way・Three-wayという測定形態のどれであるか、積分時間がどれだけか、送信局と受信局が同一局か別局か(Three-wayの場合はどの局とどの局の組み合わせか)が分からなければ、同じ「ドップラー値」という数値が指す物理量はまるで違うものになります。

TDMは、この「数値」と「その数値を解釈するために必要な文脈情報」を、1つの標準化されたメッセージの中にメタデータ部とデータ部として明示的に分離・同梱することで、この問題を解決します。

定式化・整理その1: TDMのメッセージ構造 — ヘッダ・セグメント・メタデータ・データ

TDMメッセージは、階層的に次のように構成されます。

\text{TDM} = \big(\text{Header},\ \{\text{Segment}_1, \text{Segment}_2, \dots, \text{Segment}_k\}\big)

Header(ヘッダ): メッセージ全体に対する情報。TDMのバージョン番号(CCSDS_TDM_VERS)、作成日時(CREATION_DATE)、作成組織(ORIGINATOR)などを含みます。
Segment(セグメント): 1つの連続した観測区間(典型的には1回のアンテナパス、あるいはその一部)に対応する単位。各セグメントはさらにメタデータブロックとデータブロックの2つに分かれます。

\text{Segment}_i = \big(\text{Metadata}_i,\ \text{Data}_i\big)

メタデータブロック — 「この観測データはどういう文脈で得られたか」

メタデータブロックは、そのセグメント内のすべての観測値に共通して適用される識別情報・条件情報の集合です。代表的なキーワードには次のようなものがあります(CCSDS 503.0-Bで規定されるキーワード名の一部)。

キーワード	意味
`TRACK_ID`	この観測パスを一意に識別するID
`PARTICIPANT_1`〜`PARTICIPANT_5`	観測に関与した局・探査機の識別子(送信局、探査機、受信局など、最大5者)
`MODE`	観測の幾何(`SEQUENTIAL`: 単一の送受信経路、`SINGLE_DIFF`: 差分観測など)
`PATH`	信号がどの参加者を経由したかを表す経路(例: `1,2,1` は局1→探査機2→局1のTwo-way)
`TRANSMIT_BAND` / `RECEIVE_BAND`	アップリンク・ダウンリンクの周波数帯(S/X/Kaバンドなど)
`TURNAROUND_NUMERATOR` / `TURNAROUND_DENOMINATOR`	トランスポンダの回で見たターンアラウンド比 $G_2/G_1$ の分子・分母
`RANGE_MODE`	測距方式(`COHERENT`: コヒーレント折り返し、`ONE_WAY`: 片道測距、`CONSTANT`: 固定変換など)
`RANGE_MODULUS`	測距符号のアンビギュイティ周期(モジュラス値)
`RANGE_UNITS`	測距値の単位(`km`, `s`, `RU` など)
`TIMETAG_REF`	データ部のタイムスタンプが送信時刻基準か受信時刻基準か
`INTEGRATION_INTERVAL`	ドップラー値の積分時間
`DATA_QUALITY`	データの品質フラグ(`RAW`, `VALIDATED`, `DEGRADED` など)
`CORRECTIONS_APPLIED`	対流圏・電離層遅延などの補正がすでに適用済みか(`YES`/`NO`)
`START_TIME` / `STOP_TIME`	このセグメントが対象とする観測時間範囲

データブロック — タイムスタンプ付き観測値の系列

メタデータブロックに続くデータブロックは、時刻・種別・数値の3つ組の系列として表現されます。

\text{Data}_i = \big\{\, (t_j,\ k_j,\ v_j) \;\big|\; j = 1, \dots, n_i \,\big\}

ここで $t_j$ はタイムスタンプ、 $k_j$ は観測種別を表すキーワード、 $v_j$ はその数値です。代表的なキーワード $k_j$ には次のようなものがあります。

RANGE: 測距値
DOPPLER_INSTANTANEOUS / DOPPLER_INTEGRATED: 瞬時ドップラー・積分ドップラー(周波数カウント値)
CARRIER_POWER, PC_N0, PR_N0: 搬送波電力・搬送波対雑音密度比・測距信号対雑音密度比
TRANSMIT_FREQ / RECEIVE_FREQ: 送信・受信周波数
ANGLE_1 / ANGLE_2: アンテナの指向角(方位角・仰角など)
STEC: 電離層の全電子数(電離層遅延補正に用いる)
VLBI_DELAY: DDORで得られる干渉遅延観測量

重要なのは、このデータブロックの数値は、単独では意味を持たず、必ず同じセグメントのメタデータブロックとセットで解釈されなければならないという点です。つまりTDMの1つのセグメントは、数学的には「観測値の系列 $\text{Data}_i$ 」を、「その解釈を定める文脈のパラメータ集合 $\text{Metadata}_i$ 」でパラメトライズした構造だと捉えられます。

\text{物理量} = \phi\big(v_j\;;\ \text{Metadata}_i\big)

ここで $\phi$ は、メタデータで指定された測距モード・ターンアラウンド比・モジュラス・単位などに基づいて、生の数値 $v_j$ を実際の距離・速度・角度に変換する関数です。TDMが標準化する価値は、この $\phi$ を計算するために必要な引数を、データそのものと一緒に、誰が見ても曖昧さなく取り出せる形で運ぶという点にあります。

定式化・整理その2: なぜこれほど詳細なメタデータが必要なのか

なぜCCSDSは、単に「距離」「速度」という2つの数値を送るのではなく、これほど多くのメタデータ項目を規定したのでしょうか。理由は、これまでの回で見てきた測距・ドップラーの多様性そのものにあります。

測距モードによる解釈の違い

非再生測距と再生測距の回で見たように、地上局が観測する往復遅延には、探査機トランスポンダの処理遅延(ターンアラウンド遅延、あるいは復調・再構成にかかる遅延)が含まれています。この遅延が装置較正によってすでに差し引かれているかどうかで、同じ「RANGE値」でも意味が変わります。TDMのCORRECTIONS_APPLIEDとRANGE_MODEは、この違いを明示的に伝える役割を担います。もし受信側の軌道決定ソフトウェアが、RANGE_MODE = COHERENT(折り返し測距)のデータをONE_WAY(片道測距)のものと誤解して処理すれば、往復分の光行時間を片道分と取り違えるという致命的な誤差が生じます。

ターンアラウンド比によるドップラー解釈の違い

トランスポンダの回で見たように、ダウンリンク周波数はアップリンク周波数にターンアラウンド比 $G_2/G_1$ を掛けた名目値を基準にドップラーシフトしています。同じ生の周波数カウント値でも、使われたターンアラウンド比が(たとえばSバンドの $240/221$ なのかXバンドの別の比なのか)分からなければ、視線速度に変換するどころか、そもそも名目搬送波周波数すら特定できません。TDMのTURNAROUND_NUMERATOR/TURNAROUND_DENOMINATORとTRANSMIT_BAND/RECEIVE_BANDは、この変換に不可欠な情報です。

観測幾何(何者から何者への経路か)による違い

PARTICIPANT_1〜5とPATH、MODEの組み合わせは、トランスポンダの回で扱ったOne-way・Two-way・Three-wayドップラーのどれに該当するかを特定します。特にThree-wayドップラー(送信局と受信局が異なる局であるケース)では、2局それぞれの周波数基準(USOやDSNの原子時計)の安定度が精度に効いてくるため、どの局のペアで観測されたかという情報がなければ、精度評価どころか観測量の物理的な定義すら定まりません。

積分時間によるドップラー値の意味の違い

ドップラー値は、瞬時の周波数偏移そのものではなく、多くの場合INTEGRATION_INTERVALで指定された時間窓の中でカウントされたサイクル数(積分ドップラー、Doppler count)として記録されます。積分時間が1秒のデータと60秒のデータでは、同じ「ドップラー値」というキーワードでも数値のスケールも、含まれる雑音特性も異なります。カルマンフィルタによる軌道決定の回で見たように、観測モデルは観測ノイズの統計的性質を正しく仮定する必要があり、積分時間という文脈情報を欠いたドップラーデータは、軌道推定の重み付け(観測共分散の設定)を誤らせる原因になります。

このように、TDMが持つメタデータの各項目は、「同じキーワードの生数値が、文脈によって全く異なる物理的解釈を持ちうる」というこの分野に特有の事情に対応するために、1つずつ必然性を持って規定されています。

定式化・整理その3: SLEとTDMの役割分担 — 「伝送単位」と「観測量」

SLEの回で学んだSLEと、この回のTDMは、しばしば同じ地上局・同じアンテナパスから生まれるデータを扱いますが、その役割はまったく異なります。

SLE: 探査機からのRF信号を復調・復号して得られるフレームという伝送単位のデータを、地上局からMOCへ届ける。RAF・RCFといったサービスが扱うのは、あくまで「ビット列としてのフレーム」であり、その中身がテレメトリなのか科学データなのかはSLEにとって関心の対象外です。
TDM: 探査機との間のRF伝搬(搬送波の位相・PN符号の相関・信号強度)そのものから直接導かれる観測量を、地上局から軌道決定ソフトウェアへ届ける。フレームの中身とは独立に、PLLが追尾する搬送波の位相そのものや、再生測距の相関器出力から、地上局の受信機がリアルタイムに算出する数値です。

言い換えると、探査機からの1本のダウンリンク信号は、地上局の受信チェーンの中で2つの異なる系列のデータを生み出しています。1つはPCM/PSK/PMや符号化・復号を経て得られるフレームの列(SLEが運ぶ)、もう1つは搬送波・サブキャリア・PN符号そのものの物理的な振る舞いから得られる観測量の列(TDMが運ぶ)です。両者は同じRF信号から派生していながら、下流の消費者(前者はミッション運用ソフトウェアやテレメトリ処理系、後者は軌道決定ソフトウェア)が全く異なるため、CCSDSはこの2つに対してそれぞれ独立したデータフォーマット・配送の標準を用意しているのです。

\underbrace{\text{RF受信チェーン}}_{\text{1つの物理系}} \;\longrightarrow\; \begin{cases} \text{フレーム列} \;\xrightarrow{\text{SLE (RAF/RCF)}}\; \text{MOC・テレメトリ処理系} \\[4pt] \text{観測量列} \;\xrightarrow{\text{TDM}}\; \text{軌道決定ソフトウェア} \end{cases}

なお、TDMのファイル自体はCCSDSの**軌道関連データメッセージ(Navigation Data Messages)**というファミリーの一員です。同じファミリーには、探査機の軌道状態そのものを表すOPM(Orbit Parameter Message)・OEM(Orbit Ephemeris Message)や、衝突確率評価に使うCDM(Conjunction Data Message)などがありますが、これらが「軌道要素・軌道の結果」を表すのに対し、TDMだけは「軌道を求めるための生の観測量」を表すという点で性格が異なります。

実務での使われ方

複数機関間のトラッキングデータ交換

国際相互運用の回やSLEの回で見たように、ESAのESTRACK局がNASAの探査機を支援する、あるいはJAXAの臼田局・美笹局がESAやNASAのミッションを支援するといったクロスサポートが日常的に行われています。このとき、支援側の地上局は測距・ドップラーの観測結果をTDMファイルとして生成し、被支援側のミッションが使う軌道決定ソフトウェアへ引き渡します。TDMのメタデータブロックにはPARTICIPANTとして観測に関与した局・探査機のIDが、RANGE_MODEやTURNAROUND_NUMERATOR/DENOMINATORにはその局・探査機ペアで実際に使われた測距方式・ターンアラウンド比が、明示的に記録されます。これにより、観測データを生成した機関のトランスポンダの内部実装やソフトウェアの詳細を、受け取る側が一切知らなくても、TDMのメタデータだけを頼りに正しく解釈できます。これはSLEの回で見た「標準化によって相互運用協定のコストを機関数の2乗のオーダーから線形のオーダーに縮小する」という議論の、観測データ版の実装だといえます。

軌道決定ソフトウェアへの入力

NASA/JPLの軌道決定ソフトウェアODP (Orbit Determination Program)・MONTE (Mission-analysis, Operations, and Navigation Toolkit Environment) や、ESA/ESOCで運用される軌道決定システムは、DSNやESTRACKの地上局から届くTDMファイル(あるいはそれに準ずる内部フォーマット)を入力として、最小二乗法やカルマンフィルタによる軌道推定処理にかけます。1回のアンテナパスの間に生成される数千〜数万点の測距・ドップラーの時系列データが、1つあるいは複数のTDMセグメントとしてまとめられ、軌道決定ソフトウェアは各セグメントのメタデータを読み取ってから初めて、そのセグメント内のデータ点を観測モデル(幾何学的距離・視線速度の理論式)と比較する処理に進みます。

KVN形式とXML形式

TDMは、人間にも読みやすいASCIIのキーワード=値形式であるKVN (Keyword Value Notation)と、機械処理に適したXML形式の2種類のシリアライズ方式のいずれかで表現できると規定されています。同一の観測データが、運用上の都合に応じてどちらの形式でも交換可能であることも、TDMが単なる「社内フォーマット」ではなく相互運用を意図した標準であることの表れです。以下はKVN形式によるTDMメタデータ・データブロックの簡略化した例です。

META_START
    TRACK_ID           = PASS_2026_196_A
    PARTICIPANT_1       = DSS-25
    PARTICIPANT_2       = PROBE-X
    MODE                = SEQUENTIAL
    PATH                = 1,2,1
    TRANSMIT_BAND       = X_BAND
    RECEIVE_BAND        = X_BAND
    TURNAROUND_NUMERATOR   = 880
    TURNAROUND_DENOMINATOR = 749
    RANGE_MODE          = COHERENT
    RANGE_UNITS         = km
    INTEGRATION_INTERVAL = 60.0
    CORRECTIONS_APPLIED = NO
    START_TIME          = 2026-07-15T02:00:00
    STOP_TIME            = 2026-07-15T06:00:00
META_STOP

DATA_START
    RANGE               = 2026-07-15T02:00:00.000  248009123.456
    DOPPLER_INTEGRATED  = 2026-07-15T02:01:00.000  -1345678.9
    RANGE               = 2026-07-15T02:02:00.000  248009087.221
    DOPPLER_INTEGRATED  = 2026-07-15T02:02:00.000  -1345601.2
DATA_STOP

演習問題

あるTDMファイルのメタデータブロックにRANGE_MODE = ONE_WAYと記載されているセグメントと、別のセグメントにRANGE_MODE = COHERENTと記載されているセグメントがあり、両方のRANGE値がたまたま近い数値だったとします。この2つのセグメントのRANGE値を同じ意味の観測量として軌道決定ソフトウェアに渡してしまうと、どのような問題が起きるか、非再生測距・再生測距の回で学んだ内容を踏まえて説明してください。
あるTDMセグメントのメタデータにTRANSMIT_BAND = S_BAND、TURNAROUND_NUMERATOR = 240、TURNAROUND_DENOMINATOR = 221と記載されていました。トランスポンダの回の演習で扱った計算方法を使って、アップリンク周波数 $f_{up} = 2115$ MHzのときの名目ダウンリンク周波数を求め、このメタデータがなぜドップラー値の解釈に不可欠かを説明してください。
次に挙げるデータのうち、SLEで運ばれるべきものとTDMで運ばれるべきものをそれぞれ分類し、その判断理由を説明してください。(a) 探査機の科学観測機器が取得した画像データを含むテレメトリフレーム、(b) 地上局の受信機が算出した積分ドップラー値、(c) 地上局からMOCへ送るコマンドパケット、(d) DDOR観測から得られる干渉遅延(VLBI_DELAY)。
ESAのESTRACK局が、NASAの探査機を一時的に支援してTwo-way測距・ドップラー観測を行い、そのデータをJPLのMONTEに引き渡す場面を考えます。TDMのメタデータブロックのどの項目が、ESTRACK局とNASA探査機のトランスポンダの組み合わせに固有の情報を伝える上で特に重要になるか、本文中のキーワード一覧から2つ以上選び、その理由とともに説明してください。

まとめと次回予告

この回では、これまで学んできた測距・ドップラー・角度といった観測量が、地上局から軌道決定ソフトウェアへどのような標準フォーマットで受け渡されるかを、CCSDS 503.0-BのTDM (Tracking Data Message) を通じて見ました。TDMは、観測値そのものを保持するデータブロックと、その観測値をどう物理的に解釈すべきかを規定するメタデータブロックを1つのセグメントとして同梱することで、「同じ数値でも測距モード・ターンアラウンド比・観測幾何・積分時間によって意味が変わる」という測距・ドップラー観測に特有の問題を解決していました。また、フレームという伝送単位を運ぶSLEと、観測量そのものを運ぶTDMは、同じRF受信チェーンから派生する2つの異なるデータの流れに対応する、補完的な標準であることも整理しました。

次回は視点を再び地上局とリンクの物理的な側面に戻し、LEO(低軌道)や地上移動体とのリンクで生じるマルチパス・フェージングという、深宇宙リンクとは異なる種類の伝搬課題に軽く触れていきます。

参考文献

CCSDS, Tracking Data Message, CCSDS 503.0-B-2
CCSDS, Radiometric and Doppler Tracking Data Message Format, CCSDS 503.0-G (Green Book)
CCSDS, Navigation Data Messages Overview, CCSDS 500.0-G
DSN Telecommunications Link Design Handbook, DSN No. 810-005(Turnaround Ratios and Tracking Data に関するモジュール)
J. H. Yuen (ed.), Deep Space Telecommunications Systems Engineering, JPL Publication 82-76
T. D. Moyer, Formulation for Observed and Computed Values of Deep Space Network Data Types for Navigation, JPL Publication 00-7