ネットワーク・プロトコル#56
SpaceWire — 探査機の筐体内部をつなぐ高速シリアルデータバス
SpacePacketが「何のデータをどう詰めるか」という論理層の約束事だったのに対し、今回はそのSpacePacketを探査機の筐体内部で観測機器⇔データ処理ユニット⇔通信系の間で実際に運ぶケーブル規格SpaceWire(ECSS-E-ST-50-12C)を、物理層のDS符号化からFCTによるクレジット制フロー制御、ワームホールルーティングまで数式で追う。
前提知識: space-packet
この回で学ぶこと
前回、CCSDS SpacePacketが「観測データやコマンドをどんなヘッダ構造に詰めて、どのアプリケーションプロセス宛てに届けるか」という論理層の約束事であることを学びました。しかし、SpacePacketそれ自体は単なるビット列のフォーマットにすぎず、それをどんな物理的な配線で、どんな信号の乗せ方で、どの機器からどの機器へ実際に運ぶかについては何も規定していません。
探査機の内部には、観測機器(カメラ、分光器、粒子検出器など)、データ処理ユニット(CPU、大容量メモリ、圧縮回路)、姿勢制御系、通信系(トランスポンダ)といった多数の機器(ユニット)が搭載されており、これらは互いにケーブルで接続されて絶えずデータをやり取りしています。この筐体内部の配線とプロトコルの標準規格が SpaceWire(ECSS-E-ST-50-12C)です。SpaceWireは、SpacePacketという「中身」を実際に機器間で運ぶ「輸送路」にあたります。今回は、この輸送路が物理的にどう信号を伝え、機器同士がどうやって「送りすぎ」を防ぎ、複数の機器をどうネットワーク的に相互接続するのかを、規格の数式的な骨格に沿って理解します。
直感的な導入
SpaceWireは、地上のコンピュータ同士をつなぐEthernetやUSBの「探査機版」だとイメージすると分かりやすいです。1990年代、欧州の複数のミッションでそれぞれ独自仕様のデータバスが乱立していた反省から、ESAの支援のもとダンディー大学(University of Dundee)のSTAR-Dundeeグループが中心となって標準化を進め、IEEE 1355という民生の高速シリアル規格をベースに宇宙用途向けに拡張したのがSpaceWireです。
Ethernetとの決定的な違いは、SpaceWireがポイント・ツー・ポイントの全二重リンクを基本単位とすることです。1本のSpaceWireケーブルは必ず2つの機器(ノード)だけを1対1で結び、複数機器が1本のバスを共有する(バス衝突が起きうる)ような構成にはなりません。3つ以上の機器を相互接続したい場合は、後述するルーティングスイッチを介して星型・網目状のネットワークを構成します。この「常に1対1、混雑した箇所はスイッチが捌く」という設計思想が、後述のフロー制御やワームホールルーティングの土台になっています。
物理層: LVDSと信号の伝え方
SpaceWireの物理層は、LVDS(Low Voltage Differential Signaling、低電圧差動信号)を使います。1本の論理信号を、電位が互いに逆相に振れる2本の導線(差動ペア)で伝送する方式で、
を受信側の差動レシーバが検出し、 か かの符号だけで論理値を判定します。振幅はわずか数百mV程度ですが、2本の線が空間的に近接してツイストされているため、外部からのコモンモード雑音(電磁干渉や筐体接地電位の揺らぎ)がほぼ同じ量だけ と の両方に乗り、差分を取る際に打ち消し合います。探査機内部は多数の電子機器や電源ラインが密集する電磁的にノイジーな環境であり、このコモンモード除去能力がLVDSを採用する理由です。
SpaceWireの物理コネクタには9極のマイクロミニチュアD型コネクタが規定されており、1本のリンクには次の4対の差動ペア(往路・復路それぞれデータとストローブ)が収容されます。
- Data In+/−、Strobe In+/−(受信方向)
- Data Out+/−、Strobe Out+/−(送信方向)
ケーブルは特性インピーダンス100Ωのツイストペア、全体をシールドした構造が規定されており、規格上の最大信号速度は400 Mbit/sです(ただし現実の衛星ハーネスでは、ケーブル長やコネクタ品質、EMC要求との兼ね合いから、多くのミッションで実運用速度は数十〜200 Mbit/s程度に抑えられます)。
DS符号化 — クロックを別線で送らない工夫
高速シリアル通信では、送信側のビットレートに受信側が正確に同期する「クロック再生」が必須です。ここでSpaceWireは DS符号化 (Data-Strobe encoding) という巧妙な方式を使い、専用のクロック線を1本追加することなく、データ線とストローブ線の2本だけから確実にクロックを再生できるようにしています。
考え方はこうです。ビット周期ごとのデータビットを 、それに対応するストローブビットを とし、送信側は次の規則で を生成します。
言葉で言うと、「データが前ビットから変化しなかったときはストローブを反転させ、データが変化したときはストローブをそのまま保持する」というルールです。この規則の帰結として、受信側で
を計算すると、 は必ず毎ビット周期ごとに反転します。証明は単純で、 が変化した回はデータ自身の遷移がクロックの役割を果たし、 が変化しなかった回はストローブの反転がその代わりを果たす、というように、データとストローブが「遷移の責任」を分担し合う構造になっているからです。受信側はこの の遷移エッジをサンプリングクロックとして使い、その時点の を読み取れば、PLLによる周波数逓倍やクロック再生回路を用意しなくても、送信側と完全に同期したビット列を復元できます。これはハーネスの本数と受信機の回路規模の両方を抑える、宇宙機の限られた質量・電力予算の中で理にかなった設計です。
キャラクタレベルのプロトコル: データ文字と制御文字
SpaceWireの符号化されたビット列は、送信側で**キャラクタ(文字)**という単位に区切られて解釈されます。キャラクタには2種類あります。
- データ文字 (N-Char): パリティビット1 + データ/制御フラグ1(0) + データ8ビット、合計10ビット。ペイロードの実データ(SpacePacketの中身)を運びます。
- 制御文字 (Control Char): パリティビット1 + データ/制御フラグ1(1) + 制御コード2ビット、合計わずか4ビット。以下の4種類があります。
- FCT (Flow Control Token): 後述するクレジット制フロー制御の「送信許可トークン」。
- EOP (End of Packet): パケットの正常終端を示す。
- EEP (Error End of Packet): パケットがエラー終端したこと(送信側が異常を検出して打ち切った、あるいは経路上でエラーが発生した)を示す。
- ESC (Escape): 後続の2文字と組み合わせてタイムコードなど拡張機能を表す特殊シーケンスの導入符号。
ここで工学的に重要なのは、制御文字がデータ文字の合間に、パケットの途中であっても自由に挿入できるという設計です。これは決して些細な実装上の都合ではありません。もし「制御情報はパケットとパケットの切れ目でしかやり取りできない」という設計だったなら、受信バッファが逼迫していることをFCTで送信側に伝えたくても、相手が長いパケットを送信中であれば、そのパケットが終わるまで通知できず、バッファオーバーフローのリスクが高まります。制御文字をわずか4ビットという軽量な単位にして、データ文字の隙間にいつでも割り込ませられるようにしたことで、キャラクタ単位の粒度でフロー制御とパケット境界の通知を行える、つまり待ち時間をキャラクタ1つ分程度に抑えられる、というのがこの設計の狙いです。次節のFCTによるフロー制御は、まさにこの仕組みの上に成り立っています。
フロー制御: FCTによるクレジットベースのバッファ管理
SpaceWireのリンクレベルフロー制御は、クレジット(信用枠)方式を採用しています。考え方は「受信側が確保できたバッファの分だけ、送信側に送信許可を切符(トークン)として渡す」というものです。
受信側ノードは、自分の受信バッファに新たに8文字分の空きを確保するたびに、1個のFCTを対向ノードへ送信します。送信側ノードは、送信可能な残りクレジット数 を内部カウンタとして保持し、次の規則で更新します。
そして送信側は、常に次の制約を守らなければなりません。
つまり「受信側からFCTで明示的に通知された分のクレジットを使い果たしたら、追加のFCTが届くまで一切データを送れない」という、非常に単純だが厳密な信用枠制御です。これにより、受信側はバッファオーバーフローを起こす可能性のあるデータを物理的に一切受け取らずに済みます。
さらに規格は、リンク初期化直後のバッファ要求を有界にするため、**送信側が保持できるクレジットの上限は56(= FCT 7個分)**と定めています。
これは受信ノードが最低でも56文字(56バイト)分のバッファを用意しておけば、送信側がどれだけ積極的にFCTのクレジットを使い切ろうとしても、あふれることが理論上起きない、という設計上の安全マージンです。探査機搭載機器のメモリ資源が限られている中で、「バッファは最大でもこれだけあれば十分」という上限を数式レベルで保証できることは、システム設計上の大きな利点です。
ルーティングスイッチとネットワークトポロジ
前述の通り、SpaceWireリンクは常に1対1の接続です。3個以上のノードを相互接続するには、複数のポートを持つ**ルーティングスイッチ(ルータ)**を介して、星型・階層型・冗長経路を持つ網目状など、ミッションの要求に応じたトポロジを構築します。探査機1機あたり数十のSpaceWireノードと複数のスイッチが搭載されることも珍しくありません。
スイッチが受信したパケットをどのポートへ転送すべきかを決める方式には、大きく2種類あります。
- 論理アドレシング: パケット先頭に置かれた1バイトの宛先アドレス(8ビット、値の範囲は概ね32〜255)を、スイッチ内部のルーティングテーブルで引いて出力ポートを決める方式。テーブルの書き換えにより経路変更や冗長系への切り替えが柔軟に行えます。
- パスアドレシング: パケット先頭に、経由すべきポート番号の列をそのまま並べておく方式。各スイッチは先頭の1バイト(自スイッチ宛てのポート番号)を読んで転送し、その1バイトをパケットから取り除いて次のスイッチに渡します。ルーティングテーブルを持たない単純なスイッチでも動作しますが、経路がパケット自体にハードコードされる分、経路変更の柔軟性は下がります。
ワームホールルーティング
ここでSpaceWireのネットワーク的な特徴として重要なのが ワームホールルーティング (wormhole routing) です。従来型のパケット交換ネットワーク(ストア・アンド・フォワード方式)では、スイッチは1つのパケットを送信元から完全に受信し、パケット全体をバッファに蓄積してから、次のホップへの送信を開始します。1ホップあたりの遅延は、伝搬遅延に加えてパケット全体の受信時間がかかるため、ホップ数を 、1ホップの伝搬遅延を 、パケット長を ビット、リンクレートを とすると、総遅延はおおよそ
となり、ホップ数に比例してパケット送信時間 が積み重なります。
これに対しSpaceWireのワームホールルーティングでは、スイッチはパケット全体を待たずに、宛先アドレスを示す先頭1バイトを受信した瞬間に、その出力ポートへの転送を開始します。以降のデータ文字は、届き次第すぐに次のホップへ中継されていく(パケットが「芋虫(ワーム)」のように複数のスイッチをまたいで細長く伸びた状態で流れていく)ため、各スイッチが必要とするバッファはパケット全体ではなく、わずか数文字分の一時保持で足ります。この場合の総遅延は近似的に
となり、パケット送信時間 が(ホップ数倍ではなく)1回分しか乗ってきません。探査機内部のようにケーブル長が高々数m、伝搬遅延 がナノ秒オーダーで無視できるほど短い環境では、 はほぼパケット送信時間そのものにまで縮まり、ストア・アンド・フォワード方式に対して大きな低遅延・低バッファのメリットを持ちます。
ただし副作用もあります。ワームホールルーティングでは、パケットの先頭が出力リンクの混雑(前述のフロー制御でクレジット切れ)で止まると、そのパケットの残りの部分を保持している上流のスイッチやリンクも連鎖的に送信を止めざるを得ません。これはヘッドオブラインブロッキングと呼ばれる現象で、1本のリンクの輻輳が、そのリンクを経由しない別の通信経路にまで間接的に影響を及ぼしうる、という設計上のトレードオフとして知られています。ミッションのネットワーク設計では、トラフィックの優先度分離や冗長経路の確保によってこの影響を緩和します。
実務での使われ方
SpaceWireはESAの主導のもとECSS-E-ST-50-12Cとして標準化され、欧州・日本の多くの深宇宙探査機・科学衛星で採用されてきました。ESAのRosetta、BepiColombo、JUICE(木星氷衛星探査機)、Gaia(位置天文衛星)、JAXAの「はやぶさ2」や磁気圏観測衛星「あらせ(ERG)」などが代表例です。搭載機器メーカー各社(STAR-DundeeのSpaceWire IPコアやルータASICなど)からSpaceWire対応の標準部品が供給されており、ミッションごとに独自のバス規格を一から設計する必要がなくなったことで、開発コストと検証工数の削減に大きく貢献しています。
ここで前回学んだSpacePacketとの関係を整理しておきます。SpacePacketは論理層のフォーマットであり、SpaceWireは物理層・データリンク層・(スイッチを介した)ネットワーク層を担います。実際の探査機内部では、観測機器がCCSDS SpacePacketとして観測データを組み立て、それをSpaceWireパケットのペイロード(カーゴ)としてそのままカプセル化して送出します。SpaceWireパケットの構造は、
という形を取り、宛先アドレスとEOPで挟まれた「カーゴ」部分に丸ごとSpacePacketが収まります。どのプロトコルがカプセル化されているかを識別するために、ECSS-E-ST-50-51Cで Protocol ID フィールドが規定されており(例えばCCSDS SpacePacketにはProtocol ID = 2が割り当てられています)、受信側はこのIDを見てカーゴをどのプロトコルスタックに渡すべきかを判断します。つまり「SpacePacketで何を送るかを決め、SpaceWireでそれをどう物理的に運ぶかを決める」という、2つのレッスンがちょうど論理層と物理・リンク層として積み重なる関係になっています。
なお、SpaceWireの上にはもう1つ、機器のレジスタやメモリを遠隔から読み書きするための軽量プロトコル RMAP (Remote Memory Access Protocol、ECSS-E-ST-50-52C) もよく重ねられます。RMAPはFPGA・ASICのレジスタ設定やメモリのアップロード/ダウンロードといった、リアルタイム性より確実性が重視される機器制御用途で広く使われています。
演習問題
- リンクレート Mbit/s のSpaceWireリンクで、4096バイトのSpacePacketを1つのSpaceWireパケットとして送信する場合、DS符号化のオーバーヘッド(データ文字1バイトあたり10ビット送信される)を考慮した送信時間を求めてください。
- あるノードの送信クレジット が初期値0で、以下の順にイベントが発生したとする。「FCT受信(+8)」「N-Char送信×5」「N-Char送信×3」「FCT受信(+8)」「N-Char送信×9」。それぞれのイベント後の を追跡し、途中で送信不能(のときに送信を試みる状態)が発生するかどうか判定してください。
- 5ホップのSpaceWireネットワークで、1ホップあたりの伝搬遅延 ns、パケット長 kbit、リンクレート Mbit/s とする。ストア・アンド・フォワード方式とワームホールルーティング方式それぞれの総遅延を計算し、両者の差がどこから生じるか説明してください。
- なぜSpaceWireの制御文字(FCT, EOP, EEP, ESC)は、データ文字よりも短い4ビットで符号化され、しかもデータ文字列の途中に自由に挿入できる設計になっているのか。この回で学んだフロー制御とワームホールルーティングの仕組みを踏まえて、その設計上の理由を自分の言葉で説明してください。
まとめと次回予告
SpaceWireは、LVDS差動信号とDS符号化によって専用クロック線なしに最大400 Mbit/sの高速シリアル伝送を実現する物理層、FCTによるクレジット制フロー制御でバッファオーバーフローを起こさせないリンク層、そしてワームホールルーティングで低遅延・低バッファなスイッチングを実現するネットワーク層を、1つの規格として統合したものです。前回のSpacePacketが探査機の「何を送るか」を決める論理層だったのに対し、SpaceWireはそれを筐体内部で機器から機器へ確実に運ぶ「輸送路」を担っており、両者は探査機内部データシステムの縦に積み重なる2つのレイヤーとして機能しています。
ここまでは、探査機の内部(SpaceWire)、近距離の機器間(Proximity-1)、そして地上局との数億km彼方のリンクという、それぞれ異なる距離スケールでの通信を個別に見てきました。次回以降扱う DTN (Delay/Disruption Tolerant Networking、遅延耐性ネットワーク) では、これらの区間をまたいで「常時接続を前提としないインターネット」をどう設計するかという、より大きなネットワークアーキテクチャの問題に踏み込んでいきます。
参考文献
- ECSS-E-ST-50-12C, SpaceWire — Links, nodes, routers and networks
- ECSS-E-ST-50-51C, SpaceWire protocol identification
- ECSS-E-ST-50-52C, SpaceWire — Remote memory access protocol
- S. Parkes, SpaceWire User’s Guide, STAR-Dundee
- IEEE Std 1355-1995, Standard for Heterogeneous InterConnect (HIC)