ネットワーク・プロトコル#64

CCSDS時刻コード — CUC/CDSフォーマットで探査機と地上局の時刻をそろえる

測距もドップラーもフレーム同期も、根底には共通の時刻表現がなければ成り立たない。CCSDS 301.0-Bが定めるCUC/CDS時刻コードのビット構造、探査機がUTCでなく連続時刻系で運用される理由、そしてタイムスタンプ精度がDDORや重力科学の精度要求にどう波及するかを数式で追う。

CCSDS時刻コードCUCCDSTAI/UTC

この回で学ぶこと

ここまでの回では、「時刻」という概念を暗黙のうちに何度も使ってきました。レンジングでは信号の往復に要した時間から距離を求め、ドップラー計測ではある積分時間の始点と終点における周波数の差から速度を求め、フレーム同期ではテレメトリフレームに時刻情報を刻んで地上でデータを時系列に並べ直し、DDORでは2つの地上局が受信した信号の到達時刻の差から角度を求めました。これらすべての処理は、「ある瞬間」を数値として一意に特定できることを大前提としています。

しかし考えてみると、これは決して自明なことではありません。探査機の搭載コンピュータは自分の内部クロックが刻む数値をそのままテレメトリパケットに書き込みますが、地上局のソフトウェアがその数値を「何年何月何日何時何分何秒」として正しく解釈できるためには、探査機と地上がまったく同じ規約——基準となるエポック(原点の日時)はいつか、整数部と小数部の境目はどこか、1ビットが何秒に相当するか——を共有していなければなりません。この規約が1ビットでもずれれば、レンジングの往復時間もドップラーの積分窓も、根本から意味をなさなくなります。

この回では、探査機と地上局がこの「共通の時刻表現」をどう実現しているかを扱います。CCSDS(宇宙データシステム諮問委員会)は CCSDS 301.0-B, Time Code Formats という勧告書で、深宇宙・地球周回を問わず宇宙機関が共通して使える時刻コードのフォーマットを標準化しています。中でも最も広く使われる2つの形式、CUC (CCSDS Unsegmented Time Code) と CDS (CCSDS Day Segmented Time Code) のビット構造を数式で追い、さらになぜ探査機の時計はうるう秒を含むUTCではなく連続的な時刻系で運用されるのか、そして原子時計とUSOの回で学んだアラン分散の議論が、このタイムスタンプの精度要求にどうつながるのかを見ていきます。

直感的な全体像

時刻をビット列で表現する方法を、まっさらな状態から考えてみましょう。素朴なアイデアは2つあります。

アイデア1: ひたすら経過秒数を数える。 ある基準の瞬間(エポック)を決め、そこから何秒経過したかを、固定長の整数(および端数を表す固定長の小数部)として表現する方法です。これは実はハードウェア的にもっとも作りやすい方式です。探査機の搭載クロックは、水晶発振器やUSOが刻む一定周期のパルスを、単純なバイナリカウンタで数え続けているだけの装置に近いからです。カウンタの値をそのままビット列として出力すれば、それがそのまま「エポックからの経過秒数」になります。これが CUC の発想です。

アイデア2: 日数とその日の中の時刻を分けて数える。 カレンダーの感覚に近いやり方で、「エポックから何日目か」というカウンタと、「その日の中で真夜中から何ミリ秒経過したか」というカウンタを別々に持つ方法です。日数と日内時刻を分離しておくと、地上でのデータ処理時に人間可読なカレンダー日時(年月日時分秒)への変換が扱いやすくなり、また日をまたぐ大きなタイムスタンプでも日内側のフィールド幅を圧迫しません。これが CDS の発想です。

どちらも「エポックからの経過時間」を表現しているという本質は同じですが、CUCは「搭載クロックが素朴に吐き出す生のカウンタ値」に近く、CDSは「地上のデータ処理や人間の理解にとって扱いやすい形」に近いという性格の違いがあります。実際のミッションでは、探査機からのテレメトリパケットのタイムスタンプにはCUCが、ミッションデータプロダクトや一部のミッションの運用データにはCDSが好んで使われる、という使い分けが見られます。

CUCフォーマット: 経過秒数を数える固定長カウンタ

CUCは、基準エポック $t_{\text{epoch}}$ からの経過時間を、固定ビット幅の整数部(coarse time, 整数秒)と固定ビット幅の小数部(fine time, 1秒未満の端数)に分けて表現します。時刻コード全体は、P-field(プリアンブルフィールド) と T-field(タイムフィールド) という2つの部分から構成されます。

P-fieldは通常1オクテット(拡張ビットが立っていれば複数オクテットに拡張可能)で、その中に次の情報が符号化されています。

拡張フラグ: このP-fieldの後にさらにP-fieldオクテットが続くかどうか
エポック識別子: CCSDSが定める既定のエポック(1958年1月1日0時、国際原子時TAI基準)を使うか、あるいは各宇宙機関・ミッションが独自に定義したエポック(打上げ時刻など)を使うか
整数秒部(coarse time)のオクテット数: 基本形では1〜4オクテット程度、拡張フィールドを使えばさらに広い範囲まで指定可能
小数部(fine time)のオクテット数: 基本形では0〜3オクテット程度

T-fieldは、P-fieldが指定したビット幅にしたがって、整数秒部 $N_{\text{coarse}}$ (符号なし整数)と小数部 $F_{\text{fine}}$ (1秒を1として正規化された二進小数)を格納します。時刻の値は次のように再構成されます。

t = t_{\text{epoch}} + N_{\text{coarse}} + \frac{F_{\text{fine}}}{2^{n}}

ここで $n$ は小数部フィールドのビット幅です。たとえば整数秒部に4オクテット(32ビット)、小数部に2オクテット(16ビット)を割り当てる構成は、多くのミッションで実際に採用されている代表的な組み合わせです。この場合、

\text{ダイナミックレンジ} = 2^{32}\ \text{s} \approx 136\ \text{年}, \qquad \text{分解能} = \frac{1}{2^{16}}\ \text{s} \approx 15.3\ \mu\text{s}

となり、数十年規模のミッション寿命をオーバーフローなく表現しつつ、マイクロ秒オーダーの分解能を確保できます。整数部・小数部のオクテット数は自由に選べるため、短期ミッションで分解能を優先したい場合は整数部を削って小数部を増やす、逆に超長期ミッションではダイナミックレンジを優先する、といった調整が可能です。この柔軟性こそがCUCの設計思想であり、「固定小数点の二進カウンタ」という単純な構造が、そのまま搭載クロックのハードウェア実装と直結しているという利点があります。

実務上とりわけ重要なのは、CCSDSの**宇宙パケットプロトコル(Space Packet Protocol, CCSDS 133.0-B)**のセカンダリヘッダに置かれるタイムスタンプフィールドが、まさにこのCUC形式で規定されている点です。つまり、これまでの回で「フレームやパケットにタイムスタンプが付与されている」と述べてきた部分の実体は、多くの場合このCUCのビット列そのものなのです。

CDSフォーマット: 日数とミリ秒で刻む

CDSもCUCと同様にP-fieldとT-fieldから構成されますが、T-fieldの分割の仕方が異なります。P-fieldは次の情報を符号化します。

拡張フラグ・時刻コード識別子: CUCと区別するための識別ビット
エポック識別子: CCSDS既定のエポック(1958年1月1日0時)を使うか、機関固有のエポックを使うか
日数フィールドの長さ: 16ビット(day countの範囲は0〜65535日、約179年分)か、24ビット(day countの範囲がさらに広く、事実上ミッション期間中のオーバーフローを心配しなくてよい)かを選択
サブミリ秒フィールドの有無と分解能: フィールドなし(ミリ秒分解能で打ち切り)、2オクテット(マイクロ秒分解能)、あるいは4オクテット(ピコ秒分解能)から選択

T-fieldは、日数カウンタ $D$ (P-fieldが指定した長さ、エポックからの経過日数)、その日の中の時刻を表すミリ秒カウンタ $M$ (4オクテット、 $0 \le M < 86{,}400{,}000$ )、そして必要であればさらに細かい端数を表すサブミリ秒カウンタ $S$ から構成されます。時刻の値は次のように再構成されます。

t = t_{\text{epoch}} + D \times 86400\ \text{s} + \frac{M}{1000}\ \text{s} + \frac{S}{10^{6}\ \text{または}\ 10^{12}}\ \text{s}

CDSは「日」という単位を明示的に切り出しているため、地上のデータ処理ソフトウェアがカレンダー日時(年月日)に変換する際、うるう年の処理さえ気をつければ単純な除算・剰余演算で年月日を再構成できるという実務上のメリットがあります。一方でCUCは「エポックからの単なる経過秒数」であるため、カレンダー変換には(エポックが固定であっても)グレゴリオ暦のうるう年規則を踏まえた変換処理が必要になり、この点でCDSに一日の長があります。

なお、CCSDS 301.0-Bにはこの2つに加えて、年月日時分秒をそのままビットフィールドとして格納するCCS (CCSDS Calendar Segmented Time Code) という第3の形式も定義されています。人間が直接読み書きするミッション運用ログやコマンドファイルには便利ですが、ビット効率が悪く可変長になりやすいため、宇宙リンク上を流れるテレメトリのタイムスタンプとしてはほとんど使われません。以下では、実運用上の主役であるCUCとCDSの使い分けに焦点を絞ります。

CUCとCDSの使い分けをまとめると、CUCは搭載クロックのハードウェアカウンタと直結した「生のクロック値」として、テレメトリ・コマンドパケットのタイムスタンプに使われることが多く、CDSは地上でのデータプロダクト管理や、人間が扱いやすいカレンダー変換を重視する場面で好まれる傾向があります。ただしこれは絶対的な規則ではなく、実際にどちらを採用するかはミッションごとにフライトソフトウェア・地上系ソフトウェアの設計として決定されます。

なぜ探査機はUTCではなく連続時刻系で運用するのか

ここまで見てきたCUC・CDSはいずれも、エポックから単調に増加し続ける値として時刻を表現しています。しかし私たちが日常的に使うUTC(協定世界時)は、実は単調に増加し続ける時刻系ではありません。地球の自転速度がわずかに変動し続けるため、UTCと(自転を基準にした)天文時UT1のずれが0.9秒を超えないよう、IERS(国際地球回転・基準系事業)が不定期にうるう秒を挿入し、UTCの特定の1分間だけ61秒(理論上は59秒の削除もあり得ます)にするという操作を行っています。

このうるう秒の挿入は、UTCの立場からは「時刻が正しく保たれるための補正」ですが、単調カウンタとして時刻を刻んでいる搭載クロックの立場からは不連続な段差にほかなりません。もし探査機の搭載クロックがUTCをそのまま刻んでいたとすると、うるう秒挿入の瞬間だけ「23時59分60秒」という通常存在しない値を扱うか、あるいは同じ「23時59分59秒」を2回カウントするかという特別処理が必要になります。これは次のような理由から、深宇宙ミッションの運用にとって非常に都合が悪いものです。

通信途絶中に補正情報が届かない可能性がある。 深宇宙探査機は数週間から数ヶ月にわたって地上との通信機会が限られることがあり、うるう秒の挿入予定(IERS Bulletin Cとして事前に公示される)をタイムリーに搭載ソフトウェアへ反映できるとは限りません。
時間差分の計算にことごとく特殊処理が必要になる。 レンジングの往復時間、ドップラー積分窓の長さ、フレーム間隔など、これまでの回で扱ってきたあらゆる時間差の計算が、うるう秒境界をまたぐたびに「+1秒」の補正判定を挟まなければならなくなり、バグの温床になります。
単調性が壊れると軌道決定・信号処理のアルゴリズムが前提を崩す。 カルマンフィルタによる軌道決定など、時刻を連続的な実数値として扱う数値解析アルゴリズムの多くは、時刻が単調かつ一定の刻み幅で増加することを暗黙に仮定しています。

そこで探査機の搭載クロックは、実質的にTAI(国際原子時)と同じ、うるう秒を挿入しない連続的な時刻系、あるいはミッション独自に定義されたエポックからの単純な経過時間(しばしばSCLK, Spacecraft Clockと呼ばれます)として運用されます。TAIとUTCの関係は、うるう秒による段差を $\Delta AT(t)$ として、

\text{TAI} = \text{UTC} + \Delta AT(t)

と表され、 $\Delta AT(t)$ は各うるう秒挿入のたびに1ずつ増える階段関数です(2016年末の挿入以降、 $\Delta AT = 37$ 秒で据え置かれています)。搭載クロックはこの段差を一切経験しない連続量として時を刻み続け、UTCとの対応関係(すなわち $\Delta AT$ の現在値、および搭載クロックのドリフト補正係数)は地上側で管理・更新されます。

この対応関係を確立する地上の処理が、**SCLK-SCET相関(Spacecraft Clock to Spacecraft Event Time Correlation)です。地上局が受信したテレメトリの受信時刻(地上の原子時計基準で測った正確なUTC/TAI時刻、水素メーザーで管理)と、そのテレメトリに搭載クロックが刻んだSCLK値とを、複数の時点にわたって対応づけ、両者を結ぶ較正係数(オフセットとドリフト率)を最小二乗などで推定します。この較正は、搭載クロックの水晶発振器が温度変化や経年劣化で周波数ドリフトを起こすため、一度きりではなく運用期間を通じて定期的に更新され続けます。NASA/JPLでは、この相関情報をSPICE(NAIFが開発・保守する軌道・姿勢・時刻データの標準的な取り扱いソフトウェア群)**の「SCLKカーネル」というデータファイルとして管理し、ミッション解析ソフトウェアがSCLK値とUTC/TDB(太陽系力学時)を相互変換できるようにしています。

タイムスタンプ精度の伝搬 — アラン分散から測距・DDOR精度へ

原子時計とUSOの回では、水素メーザー( $\sigma_y \sim 10^{-15}$ )とUSO( $\sigma_y \sim 10^{-13}$ )の周波数安定度の違いが、ドップラー速度計測の精度にそのまま反映されることを見ました。CUC・CDSの小数部(fine time)のビット幅、つまりタイムスタンプの分解能は、この精度の議論と無関係ではありません。テレメトリに刻まれるタイムスタンプの粒度が粗すぎれば、どれだけ発振器そのものが安定していても、時刻の割り当て誤差がボトルネックになってしまうからです。

ドップラー計測への影響。 ドップラー観測量は、ある積分時間 $T_c$ の始点と終点における位相(あるいはサイクルカウント)の差から周波数を求めます。この積分窓の境界時刻に $\delta t$ の不確かさがあると、実効的な積分時間には $T_c \pm \delta t$ の揺らぎが生じ、周波数(したがって速度)の推定にはおおよそ

\frac{\delta f}{f} \sim \frac{\delta t}{T_c}

程度の相対誤差が乗ります。たとえば $T_c = 60$ s の積分窓に対して $\delta t = 1\ \mu\text{s}$ のタイムスタンプ誤差があると、 $\delta t / T_c \approx 1.7\times10^{-8}$ となり、これはUSOのアラン偏差( $\sigma_y \sim 10^{-13}$ 、 $\tau=100$ s)よりも5桁近く粗い誤差です。つまり、もしCUCの小数部が粗すぎて時刻付けの不確かさがマイクロ秒オーダーに留まっているなら、発振器の安定度をどれだけ追求しても、タイムスタンプの粒度がボトルネックとなって精度が頭打ちになってしまいます。実際のシステムでは、fine timeフィールドの分解能はマイクロ秒からサブマイクロ秒オーダーに設計され、発振器由来の誤差(前回学んだアラン偏差)がタイムスタンプ由来の誤差を上回るよう——つまりタイムスタンプが律速要因にならないよう——バランスが取られています。

測距・DDORへの影響。 測距の観測量は信号の往復時間そのものであり、時刻の誤差 $\delta t$ は光速倍されてそのまま距離誤差になります。

\delta R = c \cdot \delta t

$c \approx 3\times10^8$ m/s なので、 $\delta t = 1$ ナノ秒の時刻付け誤差は $\delta R \approx 30$ cmの距離誤差に直結します。DDORの回で見た通り、ナノラジアンオーダーの角度精度を実現するには群遅延測定精度がピコ秒オーダーに達している必要があり、これは2つの地上局の時刻系(それぞれの局の水素メーザーに準拠したタイムスケール)が、局間で数十ピコ秒以下の精度で相互に較正されていなければ意味を持たないことを意味します。この局間の時刻同期は、GPS共通ビュー方式(GPS Common View)や双方向衛星時刻周波数伝送(TWSTFT, Two-Way Satellite Time and Frequency Transfer)といった専用の時刻比較技術によって実現されており、CCSDS時刻コードのフォーマット(たとえばCDSのサブミリ秒フィールドをピコ秒分解能に設定する選択肢)は、こうした高精度な時刻管理システムの出力を、無駄なく、かつ曖昧さなくデータプロダクトに刻み込むための「入れ物」を提供している、と位置づけることができます。

実務での使われ方

CCSDS時刻コードの規定と運用は、以下のような形で実際のミッションインフラに組み込まれています。

CCSDS 301.0-B, Time Code Formats が、CUC・CDS・CCSの正式なビット構造を規定する基本文書です。各宇宙機関はこの勧告書を参照しつつ、P-fieldのどの組み合わせ(整数秒部・小数部のオクテット数、エポック選択)を自ミッションで採用するかをプロジェクト固有の文書(たとえばNASAの各ミッションにおけるTelemetry/Command Handbook)で定めます。
CCSDS 133.0-B, Space Packet Protocol のセカンダリヘッダで、パケットの時刻タグとしてCUC形式が広く採用されています。地上のパケット処理ソフトウェアは、このタイムスタンプを読み取り、SCLK-SCET相関係数を適用してUTC/TDBに変換することで、テレメトリを時系列順に正しく並べ、他の観測データ(ドップラー、レンジング、DDOR)と時刻軸上で突き合わせます。
JPL NAIFのSPICEツールキットは、SCLKカーネル(搭載クロックとUTC/TDBの相関係数の時系列データ)、LSKカーネル(うるう秒の履歴、Leapseconds Kernel)などを標準フォーマットで提供し、ミッション解析者がCUC生値から任意の時刻系への変換を、車輪の再発明なしに行えるようにしています。IERSが発行するBulletin C(うるう秒挿入の公式通知)は、このLSKカーネルの更新の一次情報源です。
DSN(Deep Space Network)の周波数・時刻基準系(FTS) は、水素メーザーを基準とする局内時刻系を維持し、GPS共通ビューなどの手法で各局・各国の地上局(ESAのESTRACKなど)との時刻整合性を管理しています。この局側の絶対時刻精度こそが、CCSDS時刻コードに刻まれるタイムスタンプの「意味」を担保する物理的基盤です。
打上げ前のミッション設計段階では、フライトソフトウェアチームと地上系ソフトウェアチームが、CUC/CDSのフィールド幅・エポック・分解能をあらかじめ合意し、双方のソフトウェアに矛盾なく実装することが、ミッション全期間にわたるデータの整合性を左右する重要な設計判断になります。

演習問題

あるミッションのCUCが、整数秒部5オクテット、小数部3オクテットで構成されているとする。(a) 表現可能な最大経過時間(ダイナミックレンジ)を年単位で見積もれ。(b) 時刻分解能を秒単位で求めよ。
あるCDSタイムスタンプが、16ビットの日数フィールドで $D = 5000$ 、4オクテットのミリ秒フィールドで $M = 43{,}200{,}000$ を示しているとする。エポックを2000年1月1日0時(UTC、うるう秒を無視した単純なグレゴリオ暦換算でよい)とするとき、このタイムスタンプが指す日付とその日の中の時刻(時:分:秒)をおおよそ求めよ(1年=365.25日として概算してよい)。
あるドップラー観測の積分時間が $T_c = 30$ s で、タイムスタンプの不確かさが $\delta t = 200$ ns であったとする。本文の近似式 $\delta f/f \sim \delta t/T_c$ を使って、このタイムスタンプ誤差が周波数測定に与える相対誤差を求め、USOのアラン偏差( $\sigma_y(\tau=100\,\text{s}) \sim 10^{-13}$ 程度)由来の誤差と比べてどちらが支配的かを議論せよ。
探査機の搭載クロックがUTCをそのまま刻む設計だったと仮定する。うるう秒が挿入される瞬間に、搭載ソフトウェアと地上処理ソフトウェアがそれぞれどのような不具合を起こしうるか、本文で触れた「単調性」の観点から具体的に2つ挙げて説明せよ。

まとめと次回予告

CCSDS時刻コードは、探査機と地上局が「同じ瞬間」を同じ数値として共有するための、地味だが不可欠な基盤です。CUCはエポックからの経過秒数を整数部・小数部に分けて刻む、搭載クロックのハードウェアと直結した固定小数点表現であり、CDSは日数とミリ秒を分離することで地上でのカレンダー変換を扱いやすくした表現です。探査機の搭載クロックがUTCではなく連続的な時刻系(TAI的なSCLK)で運用されるのは、うるう秒による不連続な段差が、通信途絶に強く単調性を要求される宇宙機システムと本質的に相性が悪いからであり、UTCとの対応づけはSCLK-SCET相関という地上側の較正プロセスに委ねられています。そしてアラン分散で見た発振器の周波数安定度とタイムスタンプの分解能は独立な誤差要因ではなく、片方が粗ければもう片方の精度もまるごと無駄になってしまう、という意味で互いに釣り合っていなければならない関係にあります。

次回は、こうして時刻付けされ、パケット化されたデータそのものを、深宇宙特有の長い伝搬遅延や間欠的な通信機会という制約のもとでどう確実に届けるかという、宇宙用トランスポート層プロトコル SCPS (Space Communications Protocol Specifications) の考え方に軽く触れます。地上のインターネットで当たり前に使われているTCP/IPが、なぜそのままでは深宇宙リンクに使えないのか、という問いから話を始めます。

参考文献

CCSDS 301.0-B-4, Time Code Formats
CCSDS 133.0-B-2, Space Packet Protocol
IERS, Bulletin C (うるう秒に関する公式通知)
DSN Telecommunications Link Design Handbook, DSN No. 810-005(Frequency and Timing Subsystem に関するモジュール)
C. Acton et al., “A Look Toward the Future in the Handling of Space Science Mission Geometry,” Planetary and Space Science(NAIF SPICEシステムに関する解説)
J. H. Yuen (ed.), Deep Space Telecommunications Systems Engineering, JPL Publication 82-76