システム・運用#152

Vモデル — 通信サブシステムはどういうプロセスで作られるのか

100を超えるレッスンで学んできた変調・符号化・追跡・プロトコルの技術要素は、実際の探査機開発では要求定義から軌道上実証まで続く一本の川の途中で使われる部品にすぎない。システムズエンジニアリングのVモデルという枠組みで、通信サブシステムの設計・検証プロセス全体を俯瞰し、トレーサビリティという考え方とPDR/CDRといった実務のレビュー体系を整理する。

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

システムズエンジニアリングVモデルトレーサビリティPDRCDR

この回で学ぶこと

ここまで100を超えるレッスンで、PCM/PSK/PMのような変調方式から、畳み込み符号やLDPCといった誤り訂正、パラボラアンテナや低雑音増幅器といったRF回路、CCSDSプロトコルスタック、そして相互運用性の検証まで、通信サブシステムを構成する技術要素をひとつひとつ積み上げてきました。しかしここで一度立ち止まって、素朴な問いを立ててみましょう。これらの技術要素は、実際の探査機開発の現場では、どういう順番で、誰が、何を根拠に決めていくのでしょうか。

変調方式やアンテナ利得は、教科書を読めば「正しい値」が一意に決まるものではありません。ミッションが要求するデータレートや可用性から出発し、無数の設計上の選択肢(どのバンドを使うか、どの符号化方式にするか、アンテナ口径をどこまで大きくするか)の中から、コスト・重量・電力・スケジュールの制約の下でひとつの解を選び取り、それが本当に要求を満たしているかを試験で確認し、不具合が出れば設計に立ち戻って修正する——という反復的なプロセスを経て、初めて「実際に飛ぶハードウェア」になります。この回では、この設計から検証までの一連のプロセスを体系立てて捉えるシステムズエンジニアリングのVモデルという枠組みを導入し、通信サブシステムの文脈に具体化しながら、これまで学んできた個々の技術要素が開発プロセス全体のどこに位置づけられるのかを整理します。あわせて、なぜ「どの設計判断がどの要求から来たのか」を文書として追跡できるようにしておくトレーサビリティが実務上決定的に重要なのか、そして実際の宇宙機開発でどのようなレビュー体系(PDR、CDRなど)がこのプロセスを支えているのかを見ていきます。

直感的導入: なぜ「作って試す」を繰り返すだけでは足りないのか

探査機のように、一度打ち上げてしまえば物理的に修理に行けないハードウェアの開発では、「とりあえず作ってみて、動かなければ直す」という反復的な開発スタイルは通用しません。地上のソフトウェア開発であれば、バグが見つかればパッチを当てて再デプロイすれば済みますが、数億kmの彼方にいる探査機の通信機に半田付けミスが見つかっても、誰も現地に行って直すことはできません。したがって、宇宙機開発では「打ち上げる前に、あらゆる不具合をできる限り地上で発見し尽くす」という発想が開発プロセス全体を貫いています。

そのために有効な考え方が、設計の各段階に、それと対になる検証の段階を明示的に用意することです。たとえば、

「通信サブシステムはデータレート $R_b$ Mbpsを達成できるという設計をした」→ それを実際に測定して確認する試験が必要
「アンテナはこの指向精度で追尾できるという設計をした」→ それを実際に測定して確認する試験が必要
「宇宙放射線環境下でもこの回路は正常動作するという設計をした」→ それを実際に模擬環境で確認する試験が必要

このように、設計の主張ひとつひとつに、それを裏付ける試験を対応させるという発想を、開発プロセス全体の時間軸に沿って図式化したものが、次節で説明するVモデルです。名前の由来は、プロセスを時間軸(左から右)に沿って描いたときに、設計段階が徐々に詳細化しながら下降し、検証段階が徐々に統合されながら上昇する様子が、アルファベットの「V」の字に見えることにあります。

定式化・整理その1: Vモデルの基本構造

Vモデルは、開発プロセスを大きく2つの腕に分けて捉えます。**左側の腕(下降)**は要求から具体的な設計へと詳細化していく段階、**右側の腕(上昇)**はその詳細化された部品から検証を積み重ねて統合していく段階です。両者は同じ高さ(抽象度のレベル)で対応関係を持ちます。

要求定義 ─────────────────────────────── 運用・実証
   │                                          ▲
   ▼                                          │
システム設計 ───────────────────────── システム試験
   │                                          ▲
   ▼                                          │
サブシステム設計 ───────────────────── サブシステム試験
   │                                          ▲
   ▼                                          │
コンポーネント設計 ───────────────────  コンポーネント試験
   └──────────────── 製造・実装 ─────────────┘

左の腕を上から順に見ていきます。

要求定義(Requirements Definition): ミッションが何を達成すべきかを、測定可能な言葉で書き下す段階。「探査機は地球からこう遠く離れても通信できること」といった曖昧な表現ではなく、「軌道長半径◯AUにおいて、ビット誤り率 $10^{-5}$ 以下でデータレート $R_b$ bpsの伝送を実現すること」のように、後で検証可能な数値として定義します。
システム設計(System Design): ミッション全体を俯瞰し、通信サブシステムに何が要求されるか、他のサブシステム(電源・姿勢制御・熱制御など)とどう資源(電力・質量・体積)を分け合うかを決める段階。
サブシステム設計(Subsystem Design): 通信サブシステムの内部を、送信機・受信機・アンテナ・変復調器・符号化器といった機能ブロックに分割し、それぞれに満たすべき性能値を割り当てる段階。
コンポーネント設計(Component Design): 個々の回路・部品レベルの詳細設計。増幅器の利得配分、フィルタの遮断特性、アンテナの反射鏡形状など。

右の腕は、左の腕で分割した粒度をそのまま逆順にたどり、部品レベルから統合していきます。

コンポーネント試験(Component-level Test): 個々の部品・回路単体が、割り当てられた性能値を満たすかを確認する試験。
サブシステム試験(Subsystem-level Test): 個々のコンポーネントを統合した通信サブシステム全体が、サブシステムに割り当てられた要求を満たすかを確認する試験。
システム試験(System-level Test): 通信サブシステムを他のサブシステムと統合した探査機システム全体で、ミッション要求を満たすかを確認する試験。
運用・実証(Operations and Validation): 打ち上げ後、実際の宇宙空間・実際のリンク条件下で、要求が本当に満たされていることを確認する段階。

Vの底(製造・実装)は、設計と検証の間をつなぐ物理的な製造工程です。図の左右で同じ高さにある段階は対になっているという点がVモデルの核心です。「コンポーネント設計」で決めたことは「コンポーネント試験」で検証され、「サブシステム設計」で決めたことは「サブシステム試験」で検証される、というように、抽象度のレベルごとに設計と検証が1対1で対応します。これにより、「どの段階まで検証が済んでいて、どの段階がまだ残っているか」を常に見通せる状態を保つことができます。

定式化・整理その2: 通信サブシステムの文脈でのVモデル

前節の抽象的な構造を、これまでこのシリーズで学んできた具体的な技術要素に当てはめてみましょう。

左の腕(設計の下降)

ミッション要求: 「探査機は臨界期間中、常に最低限のテレメトリ可用性◯%を確保すること」「巡航期間中、データレート◯kbps以上で科学データを送出できること」といった、データレートと可用性に関する数値要求。これらはミッション全体の科学目標(取得したいデータ量)や運用制約(地上局の視野・スケジュール)から導かれます。
リンクバジェット設計: ミッション要求を満たすために、送信電力、アンテナ利得(G/T、受信系の性能を1つの数値に凝縮した指標)、変調損失、大気減衰、リンク可用性の統計といった要素を積み上げ、実際にリンク設計プロセスを通しで計算した回で見たようにマージンを評価しながら反復して、実現可能な組み合わせを探る段階。ここで初めて「Xバンド、送信電力◯W、パラボラアンテナ口径◯m、符号化利得◯dB」という具体的な数値のセットが決まります。
回路・アンテナ設計: リンクバジェットで割り当てられた各要素(送信機の出力電力、アンテナの利得、受信機の雑音指数)を、実際の回路トポロジやアンテナ形状に落とし込む段階。進行波管増幅器か固体電力増幅器か、パラボラの焦点形式をどうするか、といった詳細設計がここに入ります。
コンポーネント設計: 個々の増幅器・フィルタ・発振器・変復調ICといった部品レベルの回路図・実装設計。

右の腕(検証の上昇)

コンポーネント試験: 個々の回路基板や部品単体に対して、電磁両立性(EMC)試験、宇宙放射線環境を模擬した全電離線量(TID)試験、振動・熱真空試験などの環境試験を行い、部品レベルの仕様を満たすことを確認する段階。これらは前回学んだ相互運用性の検証プロセスにおける「ユニット試験」の考え方とも共通しており、通信プロトコルの実装検証とハードウェアの環境試験は、扱う対象こそ違えど「単体をまず規格・仕様に照らして確認する」という同型の発想に基づいています。
サブシステム統合試験: コンポーネントを統合した通信サブシステム全体(送信機・受信機・アンテナ・変復調器一式)を、実際の信号を流して動作させ、リンクバジェット設計段階で割り当てられた性能(データレート、BER、電力消費)を満たすかを確認する段階。ここで初めて、個々には仕様を満たしていた部品同士の組み合わせで生じる想定外の干渉や損失が発見されることがあります。
衛星システム試験: 通信サブシステムを探査機全体(電源・姿勢制御・熱制御・推進系など他の全サブシステム)と統合し、ミッション要求そのものを満たすかを確認する段階。電磁干渉(他のサブシステムのスイッチングノイズが通信機の受信感度を劣化させないか)や、熱設計(通信機の発熱が他の搭載機器に影響しないか)など、システム全体としての整合性がここで試験されます。
打ち上げ後の軌道上実証: 実際に打ち上げられた探査機が、実際の深宇宙リンク条件下(本物の距離、本物のドップラーシフト、本物の太陽雑音)で要求性能を発揮できることを確認する段階。地上での試験環境がどれほど精巧でも、実際の宇宙空間を完全に模擬することはできないため、この最終段階の実証は省略できません。打ち上げ初期段階でしばしば行われる「コミッショニング」運用は、まさにこの軌道上実証にあたります。

このように整理すると、これまでこのシリーズで個別に学んできたトピック——リンクバジェットの各要素、回路・アンテナの物理設計、環境試験、相互運用性検証——が、実はすべてVモデルという1本のプロセスの異なる高さに位置する部品だったことが見えてきます。

定式化・整理その3: トレーサビリティという考え方

Vモデルの左右の対応関係を、実際の開発プロジェクトで機能させるために不可欠なのが**トレーサビリティ(traceability、追跡可能性)**という考え方です。

トレーサビリティとは、ある設計判断や試験結果について、「これはどの要求から来たのか」「この要求はどの試験結果によって満たされたことが確認されているのか」という由来と裏付けの連鎖を、文書として明示的に追跡できる状態を指します。形式的には、要求の集合を $\mathcal{R} = \{r_1, r_2, \ldots, r_n\}$ 、設計判断の集合を $\mathcal{D} = \{d_1, d_2, \ldots, d_m\}$ 、試験結果の集合を $\mathcal{T} = \{t_1, t_2, \ldots, t_k\}$ としたとき、トレーサビリティが確立された状態とは、それぞれの設計判断 $d_j$ について、それを動機づけた要求への写像

\text{origin}(d_j) \subseteq \mathcal{R}

が明示され、かつそれぞれの要求 $r_i$ について、それが満たされたことを裏付ける試験結果への写像

\text{verified\_by}(r_i) \subseteq \mathcal{T}

が明示されている状態だと言えます。実務では、これを**要求トレーサビリティマトリクス(RTM: Requirements Traceability Matrix)**と呼ばれる一覧表として管理することが一般的です。各行が1つの要求 $r_i$ に対応し、その要求がどの設計文書のどの節で対応されているか、どの試験手順書のどの項目で検証されるか、そしてその試験が実際に合格したかどうかが、1行にまとめて記録されます。

なぜこれが重要なのでしょうか。理由は大きく2つあります。

理由1: 変更管理(change management)のため。 開発の途中で、ある要求が変更されたとします(たとえばミッションの科学目標が見直され、必要なデータレートが引き上げられたとします)。トレーサビリティが確立されていれば、「この要求 $r_i$ に紐づく設計判断は $d_3, d_7, d_{12}$ であり、それらを検証していた試験は $t_5, t_9$ である」ということが即座に分かり、変更の影響範囲(どの設計をやり直す必要があり、どの試験をやり直す必要があるか)を過不足なく洗い出すことができます。トレーサビリティがなければ、変更の影響範囲を洗い出すために、設計文書全体を人手で読み返す羽目になり、見落としのリスクが増大します。

理由2: 不具合対応(anomaly resolution)のため。 試験や運用中に不具合が見つかったとき、「この不具合はどの設計判断に起因するのか」「その設計判断はそもそもどの要求を満たすためのものだったのか」を遡れることが、根本原因の特定を大きく助けます。逆に言えば、なぜその設計にしたのかという理由(トレーサビリティの情報そのもの)が失われていると、開発チームが入れ替わった後などに「なぜこの部品はこの仕様になっているのか誰も分からない」という状態に陥り、不具合対応のたびに一から設計意図を推測し直す非効率が生じます。

通信サブシステムの文脈で具体的に言えば、「なぜこのリンクは変調指数 $\Delta = 1.1$ rad を採用しているのか」という設計判断が、「打ち上げ直後のクリティカルフェーズでも安定して搬送波トラッキングできること」という要求に由来することが文書化されていれば、後から誰かが電力効率を優先して $\Delta$ を変更しようとしたときに、「それをすると、この要求を満たせなくなる可能性がある」と即座に気づくことができます。これがトレーサビリティの実務的な価値です。

実務での使われ方

設計審査(レビュー)体系

実際の宇宙機開発では、Vモデルの左の腕(設計の下降)が進むにつれて、節目ごとに**設計審査(デザインレビュー)**という公式な審査イベントが設けられます。代表的なものに、以下のようなものがあります(名称や区分けは機関によって多少異なりますが、NASAやJAXA、ESAの開発プロセスで広く共通する構造です)。

概念設計審査(MDR/SRR, Mission Definition Review / System Requirements Review): ミッション要求そのものが妥当か、実現可能かを審査する段階。Vモデルでいえば「要求定義」段階の出口にあたります。
予備設計審査(PDR: Preliminary Design Review): システム設計・サブシステム設計が要求を満たす見込みがあるかを審査する段階。通信サブシステムでいえば、リンクバジェットの概算や、採用する変調・符号化方式の選定根拠がここで審査されます。まだ詳細な回路図までは固まっていない段階です。
詳細設計審査(CDR: Critical Design Review): コンポーネントレベルまで含めた詳細設計が完了し、製造に進んでよいかを審査する段階。回路図、部品リスト、環境試験計画などが、この段階までに固まっていることが求められます。
試験準備審査、飛行準備審査(TRR: Test Readiness Review, FRR: Flight Readiness Review): それぞれ試験の開始前、打ち上げの直前に、これまでの検証結果が要求を満たしていることを最終確認する審査。

これらの審査は、いずれも「この段階までに、対応する要求が本当に満たされる見込みがあるか」を、複数の専門家(レビューア)がチェックする場であり、Vモデルの各段階を無事に通過できているかを外部の目でも確認する仕組みだと理解できます。PDRとCDRの間でしばしば設計の手戻りが発生するのは、PDR時点では概算だったリンクバジェットが、詳細設計を進める過程で「実は電力が足りない」「実はアンテナ指向精度が足りない」といった問題が判明し、要求か設計のどちらかを見直す必要が生じるためです。

相互運用性検証のVモデル上の位置づけ

前回学んだ相互運用性検証(PICSによる机上照合とクロステスト)は、Vモデルのどこに位置づけられるでしょうか。厳密には、単体でのプロトコル準拠性試験は右の腕の「コンポーネント試験」に近く、他機関の実装との接続試験(クロステスト)は「サブシステム試験」から「システム試験」にまたがる位置づけになります。特に国際共同ミッションでは、探査機側の通信サブシステムと、地上局側のシステムという、本来別々の開発プロジェクトで作られた2つの「システム」を接続することになるため、通常のVモデルが1つの開発チーム内で完結するのに対し、機関間相互接続試験は複数のVモデルが右上で合流する特殊な検証段階だと捉えることができます。この合流点で発見される不整合(前回学んだ、規格の解釈の食い違いなど)は、しばしば個々の機関のVモデル内では検出できず、この合流を明示的に検証プロセスに組み込んでおかない限り、打ち上げ後まで発見されないリスクがあります。

JPLやESAにおける実際の運用

NASA/JPLの深宇宙ミッションでは、NPR(NASA Procedural Requirements)7123.1にシステムズエンジニアリングプロセスの標準が規定されており、Vモデルに準じた設計審査の体系が明文化されています。ESAでも同様に、ECSS(European Cooperation for Space Standardization)規格群、特にECSS-E-ST-10Cがシステムズエンジニアリング全体のプロセスを規定しており、要求トレーサビリティマトリクスの整備が正式なプロジェクト成果物として要求されます。JAXAの宇宙機開発標準でも同様の審査体系(基本設計審査、詳細設計審査など)が整備されています。これらはいずれも、この回で見たVモデルの考え方——設計の各段階に対応する検証段階を用意し、要求から試験結果までのトレーサビリティを維持する——を、組織として制度化したものです。

演習問題

Vモデルにおいて、「サブシステム設計」段階での設計判断に対応する検証段階はどれか答え、なぜその2つの段階が対になるのかを、この回で学んだ「抽象度のレベル」という考え方を使って説明してください。
ある通信サブシステムの開発で、ミッション後半にデータレート要求が1.5倍に引き上げられたとします。要求トレーサビリティマトリクス(RTM)が整備されていた場合と、整備されていなかった場合とで、この変更にどう対応することになるか、それぞれのシナリオを具体的に描写して比較してください。
コンポーネント試験では合格していた送信機と受信機が、サブシステム統合試験で初めて不具合(たとえば予期しない相互干渉によるBER劣化)を起こすことがあります。なぜこのような不具合は、コンポーネント試験の段階では発見できないのか、Vモデルの各段階が検証している対象の違いに基づいて説明してください。
PDR(予備設計審査)とCDR(詳細設計審査)は、どちらもVモデルの左の腕(設計の下降)の途中に置かれる審査ですが、それぞれが確認しようとしている内容には違いがあります。両者の違いを、審査時点で固まっている設計の詳細度という観点から説明してください。

まとめと次回予告

Vモデルは、要求定義からコンポーネント設計へと詳細化していく左の腕と、コンポーネント試験から運用・実証へと統合していく右の腕を、同じ抽象度のレベルで対応させることで、「設計の主張には必ず対になる検証がある」という規律を開発プロセス全体に持ち込む枠組みです。通信サブシステムの文脈では、ミッション要求からリンクバジェット設計、回路・アンテナ設計へと降りていく流れと、コンポーネント試験からサブシステム統合試験、衛星システム試験、そして打ち上げ後の軌道上実証へと昇っていく流れが対応します。この流れを実際に機能させるために不可欠なのが、要求から設計、設計から試験結果までを追跡できるトレーサビリティであり、それを組織的に運用する仕組みが、PDR・CDRといった設計審査の体系です。これまで100を超えるレッスンで個別に学んできた技術要素は、この一本のVという流れの中のどこかに位置する部品だった、という見方を持てるようになったはずです。

次回は、これまで探査機側の通信サブシステムに寄っていた視点を地上側に転じ、地上局のアンテナ・受信系だけでなく、運用管制システムやデータ配送網まで含めた地上セグメント全体のアーキテクチャ設計を概観します。探査機側のVモデルがどれほど精緻に組まれていても、それを受け止める地上セグメントの設計が伴っていなければ、ミッション全体としては成立しないからです。

参考文献

NASA, NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev2
NASA, NASA Procedural Requirements: NASA Systems Engineering Processes and Requirements, NPR 7123.1
ECSS, Space Engineering: System Engineering General Requirements, ECSS-E-ST-10C
INCOSE, Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities
J. R. Wertz, D. F. Everett, J. J. Puschell (eds.), Space Mission Engineering: The New SMAD
J. H. Yuen (ed.), Deep Space Telecommunications Systems Engineering, JPL Publication 82-76