CCSDS準拠性試験と相互運用性検証 — 標準があるだけでは繋がらない

この回で学ぶこと

国際相互運用の回では、CCSDSという標準化団体が、各宇宙機関が個別に相互運用協定を結ぶコスト($O(N^2)$)を、共通の標準に準拠するコスト($O(N)$)へと転換してきたことを見ました。物理層(401.0-B)から符号化層(131.0-B)、データ配送層(SLE)に至るまで、階層的に整理されたBlue Bookが整備されていれば、原理的にはどの機関の探査機とどの機関の地上局も相互運用できるはずです。

しかし、ここには前回あえて素通りした重大な落とし穴があります。「標準規格が存在すること」と「2つの独立な実装が実際に相互運用できること」は、まったく別の話だという事実です。ある機関のエンジニアチームがCCSDS 131.0-Bを読み込み、仕様通りにフレーム同期回路を実装したつもりでも、別の機関が同じ131.0-Bを読んで実装したフレーム同期回路と、実際に接続してみたら通信できない——という事態は、決して珍しい話ではありません。原因は規格書の読み違いだけでなく、**規格書そのものに残された「解釈の余地」**にあることも多いのです。

この回では、CCSDS標準が「紙の上の合意」から「実際に動く相互運用」へと橋渡しされるために、各宇宙機関が実務でどのような検証プロセスを踏んでいるのかを扱います。具体的には、実装がどのオプション機能を選んだかを明示的に宣言するPICS(Protocol Implementation Conformance Statement、プロトコル実装適合性宣言)という文書の考え方、実際に異なる機関の実装同士を接続してテストする相互運用性試験(クロステスト)の重要性、そして単体試験からミッション間・機関間の接続試験に至る階層的な検証プロセスを見ていきます。前回が「なぜ標準化という制度が必要か」という設計思想の話だったのに対し、今回は「標準に本当に準拠しているかを、実務としてどう検証するか」という、より現場に近い話です。

直感的導入: 規格書を読んだだけでは繋がらない

なぜ、同じ規格書を読んで実装したはずの2つのシステムが、繋がらないことがあるのでしょうか。理由は大きく3つに整理できます。

理由1: 規格にはオプション機能が多い。 CCSDSの多くの勧告書は、ある機能について「必須(mandatory)」と「オプション(optional)」を明確に区別しています。たとえば空間データリンクプロトコルで扱われる仮想チャンネルの多重化や、誤り訂正符号の種類(畳み込み符号かLDPCか、あるいはその組み合わせか)、フレームのセグメンテーションの有無など、規格は「使ってもよいが、使わなくてもよい」機能の集合を数多く含んでいます。ある機関の探査機がオプション機能Aを実装し、別の機関の地上局がオプション機能Aを実装していなければ、双方とも131.0-Bに完全に準拠していると胸を張って言えたとしても、探査機がAを使ってデータを送った瞬間に、地上局側はそれを解釈できません。

理由2: 規格書の文言には、意図せぬ解釈の幅が残る。 どれほど精密に書かれた規格書であっても、自然言語で書かれた仕様には曖昧さが残ります。「タイムアウトは適切な値に設定すること」「実装は妥当な範囲でエラーを許容すべきである」といった表現は、異なるエンジニアチームがそれぞれ「妥当」だと考える値や挙動を独自に埋めることを許してしまいます。加えて、規格が改訂される過程で旧版との後方互換性のために残された「歴史的な例外規定」なども、解釈の食い違いを生む温床になります。

理由3: 実装のバグは、規格の理解とは独立に存在する。 たとえ2つのチームが規格を寸分違わず同じように解釈していたとしても、実装コードにバグがあれば当然接続は失敗します。むしろ実務上、「規格の解釈違い」と「単なる実装バグ」を切り分けること自体が、相互運用性試験の重要な副産物の一つです。

これら3つの理由に共通するのは、規格書を「読む」だけでは、実際に相互運用できるかどうかを保証できないということです。ここから導かれる実務上の結論はシンプルです。「この実装は本当に相手側と通信できるのか」という問いに答えるには、最終的には実際に接続してみるしかありません。しかし闇雲に総当たりで接続テストをするのはコストが高すぎます。そこで宇宙機関コミュニティは、この検証作業を体系立てて行うための2つの仕組み——PICSと段階的な相互運用性試験——を発展させてきました。

定式化・整理その1: PICS — 実装が「何をサポートしているか」を宣言する文書

まず必要になるのが、ある実装が規格の中のどのオプションを選んで実装したのかを、明示的に、かつ他者が読める形で宣言する仕組みです。これを**PICS(Protocol Implementation Conformance Statement)**と呼びます。

PICSの考え方は、ISO/IECのOSIプロトコル適合性試験の枠組み(ISO/IEC 9646)に由来するもので、CCSDSに限らずネットワークプロトコル全般で広く使われている概念です。基本的な構造は、規格書中のすべての要求事項(requirement)を一覧化した表に対して、実装者が各項目について

• サポートしている(Supported)か、していない(Not Supported)か
• 必須項目・オプション項目・条件付き必須項目のいずれに分類されるか
• サポートしている場合、規格が許す範囲(パラメータの取りうる値の範囲など)のうち、実際にどこまでを実装したか

を1行ずつ埋めていく、というものです。ある実装のPICSを、規格中のすべての要求項目の集合 $\mathcal{R} = \{r_1, r_2, \ldots, r_n\}$ に対する部分集合として捉えると、

$$\text{PICS}(\text{実装}\ X) = \{ r_i \in \mathcal{R} \mid \text{実装}\ X\ \text{が}\ r_i\ \text{をサポートする} \}$$

と定式化できます。国際相互運用の回で見た「探査機側のパラメータ集合が地上局側のパラメータ集合に包含されていること($\Sigma_{\text{探査機}} \subseteq \Sigma_{\text{地上局}}$)」というクロスサポート成立の必要条件を思い出すと、PICSはまさにこの $\Sigma$ を、機関間で共有可能な文書として明文化したものだと理解できます。2つの実装 $X$(探査機側)と $Y$(地上局側)のPICSを突き合わせたとき、

$$\text{PICS}(X) \subseteq \text{PICS}(Y)$$

——つまり探査機が実際に使う機能の集合が、地上局が受信・処理できる機能の集合にすべて含まれていること——が、少なくとも紙の上での相互運用可能性の必要条件になります。

ここで重要なのは、PICSは「相互運用できることの証明」ではなく、あくまで「実装者による自己申告」だという点です。ある機関のエンジニアが「うちの実装はオプション機能Bをサポートしています」とPICSに記載したとしても、それは規格の要求通りに正しく動くことまでは保証しません。PICSの役割はむしろ、2つの実装を接続する前段階で、「この組み合わせで接続テストをする価値があるか」「テストすべきはどの機能の組み合わせか」を効率的に絞り込むためのスクリーニングツールです。総当たりで全機能を試験するのではなく、双方のPICSを比較して重なり合う機能領域にテストの焦点を当てることで、限られた試験時間・予算を有効に使うことができます。

定式化・整理その2: 検証の3階層 — 単体・統合・機関間接続

PICSによる机上の突き合わせだけでは、実際の相互運用性は保証できません。そこで実務では、検証作業を粒度の異なる複数の階層に分けて段階的に進めます。典型的には次の3階層で整理されます。

階層1: ユニット試験(Unit-level Conformance Testing)。 個々の実装を単独で、規格そのものに対して照合する試験です。たとえばフレーム同期を実装したモジュールに対して、規格が定める同期マーカー(ASM)のビットパターンを含む既知のテストベクタ(あらかじめ正解が分かっている入力データ列)を流し込み、期待通りにフレームの先頭を検出できるかを確認します。この段階では、通信相手となる別実装は不要で、規格書と、規格に基づいて用意された参照テストベクタ・参照実装だけを相手に、自分の実装が仕様通りに振る舞うかを検証します。CCSDSはしばしば各勧告書に付随する形で、こうした標準テストベクタや、参照ソフトウェア実装を公開しており、各機関はこれを使って自前の実装を独立に検証できます。

階層2: サブシステムレベルの統合試験(Integration Testing)。 単体では規格に適合していたモジュールを、実際に自機関のシステム全体(たとえば地上局のフロントエンド一式、あるいは探査機の通信サブシステム一式)に組み込み、内部の他コンポーネントとの整合性を確認する段階です。ここではまだ他機関の実装とは接続しませんが、たとえば探査機側では搭載コンピュータ(C&DH)から渡されたデータが宇宙データリンクプロトコルに従って正しくフレーム化され、変調器に渡るまでのパイプライン全体が、規格通りのタイミング・フォーマットで動作するかを確認します。単体では正しく動いていた個々のモジュールが、実際に統合されると想定外のタイミングやバッファリングの不整合で問題を起こすことは珍しくなく、この段階での検証は不可欠です。

階層3: 機関間相互接続試験(Cross-Agency Interoperability Testing)。 ここでようやく、異なる機関が独立に開発した実装同士を、実際に接続してテストします。これがこの回の主題である**相互運用性試験(クロステスト)**です。次節で詳しく見ますが、ここでは単体試験・統合試験では決して発見できない種類の不整合——「双方とも規格に忠実なつもりで実装したのに、解釈が食い違っていた」という問題——が初めて表面化します。

この3階層はちょうどハードウェアの環境試験などで見られる「コンポーネント試験 → サブシステム試験 → システム試験」という段階的検証の考え方と同型の構造を持っています。違いは、対象がハードウェアではなく通信プロトコルの実装であり、最終段階(階層3)で試験されるのが自分のシステム単体ではなく、自分のシステムと他機関のシステムとの組であるという点です。

定式化・整理その3: なぜ「解釈の突き合わせ」だけでは不十分で、実接続が要るのか

階層3の相互運用性試験がなぜ不可欠なのかを、もう少し掘り下げてみましょう。PICSの突き合わせは、あくまで「双方が同じ機能名にチェックを入れているかどうか」を照合する行為です。しかし、たとえ双方が「オプション機能Bをサポートしている」とPICSに記載していても、次のような食い違いが実接続で初めて発覚することがあります。

• 同じ機能名の解釈が違う。 たとえば「タイムアウト後の再送」という項目について、機関Aは3回の再送を試みてから接続を切断する実装をし、機関Bは無限に再送を試み続ける実装をしていた、というように、規格が数値まで厳密に規定していない挙動については、双方の実装が異なる前提を持ってしまうことがあります。
• 境界値・異常系の扱いが違う。 規格が正常系のフォーマットは厳密に定めていても、フィールドが規定範囲外の値を取った場合や、パケットが破損して届いた場合の挙動については記述が薄いことがあり、双方が異なる防御的実装をしていることがあります。
• タイミング・同期の暗黙の前提が違う。 特にPLLの捕捉時間や、フレーム同期の再同期にかかる時間など、規格が「妥当な時間内に」としか書いていない性能要求については、実装ごとに具体的な数値が異なり、片方の実装が想定するタイムアウト値が、もう片方の実装の応答時間より短い、という組み合わせ次第の不整合が起こり得ます。

これらはいずれも、規格書を読み比べるだけでは発見しにくく、実際に2つの実装を繋いで、実データ(あるいは模擬データ)を流してみて初めて表面化する類の問題です。相互運用性試験の本質的な価値は、「規格の文言レベルでの一致」と「実装の挙動レベルでの一致」の間に存在するギャップを、実接続という経験的な手段で埋めることにあります。

実務での使われ方

CCSDSにおける相互運用性デモンストレーション

CCSDS自身も、この「規格を作るだけでは足りない」という問題を強く認識しており、勧告書の制定・改訂プロセスの中に、複数機関が持ち寄った実装同士を実際に接続して検証する活動を組み込んでいます。これは業界で「プラグフェスト(plugfest)」と呼ばれる、複数ベンダー・複数機関の実装を一堂に会させて相互接続性を確認する活動と同種の発想です。CCSDSの各作業部会(Working Group)は、新しい勧告書を正式なBlue Book(義務的な標準規格)として承認する前段階で、複数機関がそれぞれ独立に実装したプロトタイプを持ち寄り、実際に接続してデータをやり取りできるかを確認する相互運用性デモンストレーションを行うことがあります。ここで発見された不整合は、正式勧告化される前の規格文書そのものにフィードバックされ、曖昧な文言の明確化や、オプション機能の整理に反映されます。つまり相互運用性試験は、標準が確定した後の検証作業であるだけでなく、標準そのものの品質を高めるフィードバックループの一部としても機能しています。

国際共同ミッション立ち上げ前の技術検証

国際相互運用の回で見た火星探査における多機関中継協力や、DSNとESTRACKの相互支援は、日常的な運用としてクロスサポートが機能している例でしたが、こうした運用が「初めて」成立する前には、必ず入念な事前検証が行われています。たとえば、ある機関の探査機が別機関の地上局に初めて追跡してもらう場合、打ち上げの何ヶ月も前から、双方の運用チームがPICSを交換して机上でパラメータの整合性を確認し、可能であれば地上での試験設備(探査機側の通信機の技術試験モデルと、地上局側の受信システムを模擬した試験局)を使って実際にRF信号(あるいはそれを模擬した基底帯域信号)を送受信する接続試験を実施します。ESAのMars ExpressやTGOがNASAのローバーを中継する運用が確立する過程でも、Proximity-1 Space Link Protocolに基づく実装同士の相互接続試験が、実際のミッション運用に先立って行われました。この事前検証によって、打ち上げ後・着陸後の一発勝負のクリティカルフェーズで初めて「実は繋がらなかった」という事態を防いでいます。

IOAGが定めるクロスサポートの検証プロセス

前回紹介したIOAG(Interagency Operations Advisory Group)も、単に「どの標準を使うか」を決めるだけでなく、機関間でクロスサポートを開始する際の技術検証プロセスについてもガイダンスを発行しています。新しいミッションが他機関の地上局によるサポートを要請する際には、両機関の技術者チームが**インターフェース制御文書(ICD, Interface Control Document)**を取り交わし、その内容に基づいて段階的な検証(まず地上系での接続試験、次に実機を使ったコンパチビリティテスト)を経てから、実運用でのサポートに移行するというプロセスが一般的です。このプロセスは、この回で見た「PICSによる机上照合 → 実接続試験」という2段階の考え方と対応しています。

演習問題

1. ある規格の要求事項の集合を $\mathcal{R} = \{r_1, \ldots, r_{10}\}$ とし、探査機側実装 $X$ が $\text{PICS}(X) = \{r_1, r_2, r_3, r_5, r_8\}$、地上局側実装 $Y$ が $\text{PICS}(Y) = \{r_1, r_2, r_3, r_4, r_5, r_6, r_8, r_9\}$ をそれぞれサポートしていると宣言している。$\text{PICS}(X) \subseteq \text{PICS}(Y)$ は成立するか判定し、成立する・しない場合それぞれについて、この結果から「実際に相互運用できる」と結論してよいかどうかを、この回の内容を踏まえて論じてください。

2. 単体試験(ユニットレベル)・統合試験(サブシステムレベル)・機関間相互接続試験(クロステスト)という3階層の検証プロセスにおいて、それぞれの階層で「発見できる不整合の種類」と「発見できない不整合の種類」を整理し、なぜ3階層すべてが必要であり、どれか1つを省略できないのかを説明してください。

3. 本文で挙げた「タイムアウト後の再送回数」の例のように、規格書が数値まで厳密に規定していない項目について、あなたがCCSDSの新しい勧告書の作成に関わるとしたら、こうした曖昧さを減らすためにどのような記述方針を提案しますか。具体例を1つ挙げて説明してください。

4. CCSDSにおける相互運用性デモンストレーション(プラグフェスト的な活動)が、正式なBlue Book勧告化の「前」に行われることには、単に「実装のバグを見つける」以外にどのような意義があるか、規格そのものの品質という観点から考察してください。

まとめと次回予告

CCSDS標準の存在は、相互運用性の必要条件を用意するに過ぎず、十分条件ではありません。規格書にはオプション機能や解釈の幅が残るため、2つの独立な実装が「両方とも規格に準拠している」と主張していても、実際に接続してみるまで本当に通信できるかは分かりません。この回では、実装がどの機能をサポートしているかを明示的に宣言するPICSという文書によって机上での突き合わせを効率化しつつ、最終的には単体試験・統合試験・**機関間相互接続試験(クロステスト)**という段階的な検証プロセスを経ることで、規格の文言レベルの一致を、実装の挙動レベルの一致へと確認していく実務を見ました。CCSDSの相互運用性デモンストレーションや、国際共同ミッション立ち上げ前の入念な事前検証は、いずれもこの考え方の具体的な現れです。

次回は、これまで地上局・通信リンクの話に集中してきた視点を探査機の内部に転じ、受信したコマンドの処理やテレメトリの生成を担うC&DH(Command and Data Handling)サブシステムのアーキテクチャに軽く触れます。地上との通信規格がどれほど整備されていても、その先で探査機の頭脳であるC&DHが正しくコマンドを解釈し、データを準備できなければ、相互運用性は絵に描いた餅で終わってしまうからです。

参考文献

• CCSDS, Cross Support Reference Model—Part 1: Space Link Extension (SLE) Services, CCSDS 910.4-B-2
• CCSDS, Cross Support Concept—Part 1: Space Link Extension Services, CCSDS 910.3-G (Green Book)
• ISO/IEC 9646, Information technology — Open Systems Interconnection — Conformance testing methodology and framework
• IOAG, IOAG Service Catalog (最新版)
• IOAG, Interoperability Guidelines and Interface Control Document Templates
• J. H. Yuen (ed.), Deep Space Telecommunications Systems Engineering, JPL Publication 82-76
• NASA/JPL および ESA公式資料, 国際共同ミッション立ち上げ前の技術検証・相互接続試験記録