通信系デジタルツイン — 実機を作る前に、実機を「動かして」試験する

この回で学ぶこと

相互運用性検証の回では、規格に準拠して実装したはずの2つのシステムが、実際に接続してみて初めて不整合を露呈するという問題を見ました。そこでの結論は「規格書を読み比べるだけでは足りず、最終的には実際に接続してみるしかない」というものでした。そしてVモデルの回では、この「実際に試す」という検証行為が、コンポーネント試験からサブシステム試験、システム試験、そして打ち上げ後の軌道上実証まで、抽象度を上げながら段階的に積み重ねられていくプロセスであることを整理しました。

この2つの回に共通する前提を、あらためて言葉にしてみましょう。検証とは、最終的には「実物を動かしてみて、期待通りに振る舞うか確認する」行為だ、という前提です。試験ベクタを流し込むにせよ、他機関の実装と接続するにせよ、環境試験チャンバーに部品を入れるにせよ、いずれも「本物(あるいは本物に近いもの)を実際に動かす」ことでしか得られない情報を集めています。

しかし、宇宙機開発には常に悩ましい制約がつきまといます。探査機の実機は、開発の初期段階にはまだ存在しない、あるいは存在しても1台しかなく、あらゆる試験シナリオに使い回すには数が足りない、という制約です。リンクバジェットの設計段階で「本当にこの符号化方式で目標BERを達成できるか」を確かめたくても、まだ送信機のフライトモデルは組み上がっていません。運用中に「探査機の様子がいつもと違う」と感じても、地上には比較対象となる正常な探査機がもう1台あるわけではありません。

この回で扱うデジタルツイン(Digital Twin)は、この制約に対する1つの答えです。実機そのものではなく、実機の物理的な挙動を忠実に再現するソフトウェアモデルを構築し、実機を使わずに(あるいは実機と並行して)様々なシナリオでの試験・予測を行おう、という考え方です。これまでこのシリーズで学んできたRF伝搬の数式モデル、プロトコルスタックの階層構造、そしてSDRで見たソフトウェア無線の技術が、この回では「実機を模擬するソフトウェア」という新しい文脈でひとつに統合されます。

直感的導入: なぜ「精密な計算」だけでは足りなくなったのか

リンク設計プロセスの実践ウォークスルーでは、EIRP・自由空間損失・G/T・変調損失といった部品を、dB表記で一枚のリンクバジェット表に積み上げ、マージンを評価する手計算のプロセスを見ました。この手計算は今でも設計の出発点として非常に有効ですが、いくつかの点で本質的な限界を持っています。

限界1: 静的なスナップショットしか扱えない。 リンクバジェット表は「ある1つの距離、ある1つの仰角、ある1つの瞬間」における電力収支を計算するものです。実際のミッションでは、探査機と地球の距離は軌道運動によって刻一刻と変化し、地上局から見た仰角も探査機の姿勢も時々刻々変わります。数時間・数日にわたる通信パス全体を通して、リンクマージンがどう推移するかを知りたければ、無数の瞬間ごとにリンクバジェット表を計算し直す必要があります。

限界2: 部品同士の相互作用を追えない。 手計算のリンクバジェットは、変調損失・符号化利得・大気減衰といった各項を、互いに独立な減衰要因として足し引きします。しかし実際のシステムでは、たとえばPLLのループ帯域幅の設定が、ドップラー変化率への追従性とサイクルスリップ確率の両方に影響し、それが結果的にビット誤り率にも波及する、というように、部品同士が複雑に絡み合っています。この絡み合いを紙の上の代数式だけで正確に追い続けるのは、現実的ではありません。

限界3: 「実機が今どう振る舞うべきか」の基準がない。 運用中に受信信号のSNRがわずかに劣化したとき、それが「想定内のドップラーによる変動」なのか「アンテナ指向のわずかなずれ」なのか「本当の異常(部品の劣化や故障)」なのかを、運用者はどう見分ければよいのでしょうか。手計算のリンクバジェットは1つの設計点の妥当性は教えてくれますが、「今この瞬間、この条件下で、実機は本来どういう信号を返してくるはずか」という、時々刻々更新される比較対象までは提供してくれません。

デジタルツインは、これら3つの限界に対して同じ発想で応えます。紙の上の静的な計算を、時間発展する動的なソフトウェアシミュレーションに置き換え、実機と並走させるという発想です。

定式化・整理その1: デジタルツインとは何か

デジタルツインという言葉は宇宙通信に限らず、製造業や都市計画など幅広い分野で使われる概念ですが、通信系の文脈では次のように定義できます。

通信系デジタルツインとは、探査機(および地上局)の通信サブシステムの物理的な入出力関係を、実機と同じ精度で予測できるソフトウェアモデルの集合であり、実際の運用データ(あるいは仮想的なシナリオの入力)を与えることで、実機を用いずに(あるいは実機と並行して)その挙動を再現・予測できるものを指す。

ここで重要なのは、デジタルツインは単なる「数式のコレクション」ではないという点です。従来のリンクバジェット計算が「与えられた1組のパラメータから、1つの出力値(マージン)を計算する」静的な写像だったのに対し、デジタルツインは

$$\mathbf{y}(t) = F\big(\mathbf{x}(t), \mathbf{s}(t)\big)$$

という形の、時間発展する動的システムとして組まれます。ここで $\mathbf{x}(t)$ は時刻 $t$ における状態変数のベクトル(探査機の位置・姿勢、送信電力、変調パラメータなど)、$\mathbf{s}(t)$ は外部から与えられるシナリオ入力(たとえば太陽コロナの電子密度、降雨強度)、$\mathbf{y}(t)$ はシミュレーションが出力する予測値(受信SNR、BER、フレーム同期率など)です。$F$ は、これまでこのシリーズで個別に学んできた物理モデル・プロトコルモデルを組み合わせた合成関数であり、$\mathbf{x}(t)$ 自体も軌道力学・姿勢力学の微分方程式に従って時間発展します。

デジタルツインを、これまで見てきた「単発の計算」や「試験ベクタによる単体試験」と区別する特徴を整理すると、次の3点にまとめられます。

• 忠実度(fidelity): モデルが実機の挙動をどれだけ精密に再現するか。粗いモデルでは見落とされる非線形性(たとえば送信機のアンプの飽和特性)まで含めるかどうかで、忠実度のレベルは何段階にも分かれます。
• 時間発展性: 単一の設計点ではなく、軌道運動・姿勢変化・環境変動に伴って、状態が連続的に更新され続けること。
• 実機との並走可能性: 運用中の実機から得られるテレメトリと、同じ時刻・同じ条件でシミュレーションが出力する予測値を、常に突き合わせられる状態にあること。

3点目が、次節以降で見る「異常診断」の土台になります。

定式化・整理その2: 通信系デジタルツインの構成要素

通信系デジタルツインは、単一の巨大なプログラムというよりも、これまでこのシリーズで学んできた複数のモデル群を、時間軸に沿って結合したパイプラインとして組まれます。主要な構成要素を整理すると、次の3層に分けられます。

層1: RF伝搬モデル層

変調損失の回で導入したリンクバジェット方程式

$$\frac{P_R}{N_0} = EIRP - L_{path} + \frac{G}{T} - k$$

を構成する各項——自由空間損失 $L_{path}$、降雨減衰、太陽コロナによる位相シンチレーション、アンテナ指向誤差による利得損失——は、これまで個別のレッスンで手計算の対象として扱ってきました。デジタルツインでは、これらの数式モデルをそれぞれ独立したソフトウェア関数として実装し、時刻 $t$ ごとの状態変数(距離、仰角、大気の状態、太陽との離角)を入力すれば、その瞬間の $P_R/N_0$ を自動的に出力するパイプラインとして統合します。

$$L_{path}(t) = \left(\frac{4\pi d(t)}{\lambda}\right)^2, \qquad d(t) = \| \mathbf{r}_{sc}(t) - \mathbf{r}_{gs}(t) \|$$

のように、探査機位置 $\mathbf{r}_{sc}(t)$ と地上局位置 $\mathbf{r}_{gs}(t)$ が時間の関数として与えられれば、$L_{path}(t)$ も自動的に時間の関数になります。手計算では「ある1つの距離における損失」しか評価しませんでしたが、デジタルツインでは可視パス全体(地上局が探査機を追跡できる時間帯全体)にわたって $L_{path}(t)$ が連続的に計算され続けます。同様に、太陽合の回で見た位相シンチレーションの標準偏差 $\sigma_\phi$ も、太陽・地球・探査機の離角が変化するにつれて時々刻々更新される量として組み込まれます。

層2: プロトコルスタックのソフトウェアシミュレーション層

RF伝搬モデル層が「どれだけの電力・SNRが受信機に届くか」を計算する一方、その受信信号を実際に復調・復号し、フレーム同期を取り、プロトコルスタックの各層(物理層・データリンク層・CFDPなどの上位層)を通過させたときにどう振る舞うかをシミュレートするのが、この層の役割です。

ここでSDRの回で学んだ考え方が自然な形で活きてきます。SDRは「アナログ回路が担ってきたミキシング・フィルタリング・位相追尾を、デジタル演算として書き直す」という発想でした。デジタルツインのプロトコルスタック層は、まさにこのSDR的なソフトウェア実装をそのままシミュレーションエンジンとして転用します。つまり、実際の受信信号の代わりに、層1で計算されたSNRをもとに生成した模擬受信信号(あるいはSNRの統計的性質だけを反映した簡略化されたビット誤りモデル)を、実機と同じ復調アルゴリズム・同じ誤り訂正復号アルゴリズムに通し、実際にフレーム同期が成功するか、CRCやFECによる誤り検出・訂正がどの程度機能するかを、ビット単位・フレーム単位で再現します。

この層が持つ意味は大きく2つあります。第一に、相互運用性検証の回で見た単体試験の「参照テストベクタを流し込む」という発想を、静的なテストベクタではなく時間発展するシナリオ全体に拡張できることです。第二に、COP-1の再送制御や、CCSDSのフレーム構造がもつ仮想チャンネル多重化のような、プロトコルの状態遷移を伴う複雑な挙動まで、実際にコードを走らせることで確認できることです。数式だけでは「平均的にどの程度のフレーム損失率になるか」は近似できても、「再送制御プロトコルが特定のバースト誤りパターンに遭遇したときに、実際にデッドロックに近い挙動を起こさないか」といった、コードを実際に走らせないと発見しにくい種類の不具合は、このシミュレーション層があって初めて洗い出せます。

層3: 軌道・姿勢モデル統合層

層1・層2がそれぞれ「与えられた時刻 $t$ における状態」を前提に計算する一方、その状態そのもの——探査機の位置・速度・姿勢——を時間発展させるのがこの層です。カルマンフィルタによる軌道決定やスタートラッカーによる姿勢決定で学んだ推定アルゴリズムの「順方向」、つまり軌道力学の運動方程式や姿勢の運動学モデルを積分して、任意の未来時刻における探査機の状態を予測する軌道伝播モデル・姿勢伝播モデルがここに入ります。

$$\dot{\mathbf{r}}_{sc} = \mathbf{v}_{sc}, \qquad \dot{\mathbf{v}}_{sc} = -\frac{\mu}{\|\mathbf{r}_{sc}\|^3}\mathbf{r}_{sc} + \mathbf{a}_{pert}(t)$$

のような運動方程式($\mu$ は中心天体の重力定数、$\mathbf{a}_{pert}$ は軌道擾乱による摂動加速度)を数値積分することで、$\mathbf{r}_{sc}(t)$ が任意の時刻について得られます。これが層1のRF伝搬モデルに供給されることで、初めて「未来のある期間、地上局から見た探査機の可視パス全体でリンクマージンがどう推移するか」という、時間軸を持った予測が可能になります。姿勢モデルについても同様で、探査機のアンテナ指向が姿勢の関数として決まる以上、姿勢の時間発展がなければアンテナ利得の時間変化(指向誤差による損失)を正しくシミュレートできません。

この3層が結合されることで、デジタルツインは「ある瞬間の静的なスナップショット」ではなく、「探査機が実際に飛行する軌道に沿って、通信リンクがどう振る舞うか」を、時間軸に沿って連続的に予測できるシステムになります。

定式化・整理その3: デジタルツインの2つの使い道 — 予測的シミュレーションと乖離検出

デジタルツインの使われ方は、大きく2つの異なる問いに答える形で整理できます。

問い1(設計段階): 「もしこの設計・このシナリオだったら、リンクはどう振る舞うか」。 実機がまだ存在しない設計段階で、デジタルツインに仮想的な設計パラメータ(送信電力、符号化方式、アンテナ口径)や仮想的なシナリオ(将来の軌道、想定される太陽合の時期、降雨の統計モデル)を与え、シミュレーションを走らせて予測値 $\hat{\mathbf{y}}(t)$ を得ます。これはリンク設計プロセスの実践ウォークスルーで見た手計算によるリンクバジェットの、より精緻で時間軸を持ったバージョンだと理解できます。手計算では捉えきれなかった、可視パス全体を通したマージンの推移や、太陽合前後のシンチレーションによる劣化期間の長さといった時間的な情報が、この予測的シミュレーションによって初めて定量的に評価できます。

問い2(運用段階): 「実機は今、予測通りに振る舞っているか」。 実機が実際に運用に入った後は、デジタルツインは実機と同じ時刻・同じ軌道条件・同じ既知の環境パラメータを入力として受け取り、その瞬間に実機が返してくるはずの予測値 $\hat{\mathbf{y}}(t)$ を計算し続けます。これを、実際に地上局が受信したテレメトリの実測値 $\mathbf{y}_{obs}(t)$ と突き合わせ、その乖離

$$\boldsymbol{\varepsilon}(t) = \mathbf{y}_{obs}(t) - \hat{\mathbf{y}}(t)$$

を継続的に監視します。$\boldsymbol{\varepsilon}(t)$ が、モデルの不確かさから見込まれる範囲(たとえば予測の標準偏差の数倍)を超えて大きくなったとき、それは「デジタルツインがモデル化していない何かが実機に起きている」というシグナルであり、これが**異常診断(anomaly diagnosis)**の出発点になります。重要なのは、この乖離検出が「過去の平均値との比較」ではなく「その瞬間の軌道・環境条件のもとで理論上期待される値との比較」である点です。探査機がちょうど地平線近くの低仰角にいて大気減衰が大きい時間帯なのか、太陽合に近くシンチレーションが強い時期なのか、といった「本来劣化していて当然の条件」をデジタルツインが正しく差し引いてくれるからこそ、その上でなお残る乖離を、本当の異常の候補として絞り込むことができます。

$$\text{異常の候補} \iff |\boldsymbol{\varepsilon}(t)| > k \cdot \sigma_{model}(t)$$

のような閾値判定($\sigma_{model}(t)$ はその時刻の条件下でのモデル予測の不確かさ、$k$ は運用上設定する感度パラメータ)が、実務での異常検知アルゴリズムの基本形になります。$k$ を小さくすれば偽陽性(実際には問題ないのに警報が出る)が増え、大きくすれば偽陰性(本当の異常を見逃す)が増えるという、リンク可用性の統計的設計でも見た種類のトレードオフがここにも現れます。

さらに、この問い1と問い2は独立ではなく、太陽合の回で見た「将来シナリオの事前評価」という第3の使い道にもつながります。数ヶ月先に太陽合を控えているミッションであれば、デジタルツインにその時期の太陽・地球・探査機の幾何学的配置を予測入力として与え、シンチレーションによる位相雑音がPLLのループSNRをどこまで悪化させ、いつからいつまで合ブラックアウト運用に切り替える必要があるかを、事前に定量的にシミュレートしておくことができます。これは問い1(予測的シミュレーション)の枠組みをそのまま将来時刻に適用したものであり、実際に合の時期が来たときには、問い2(乖離検出)の枠組みで「予測通りに劣化が進んでいるか」を継続的に確認する、という形で2つの使い道がつながります。

実務での使われ方

地上局側でのデジタルツイン活用

NASAのDSN(Deep Space Network)やESAのESTRACKでは、受信した実際の信号のテレメトリ(受信電力、SNR、ロック状態)と、軌道決定データ・既知の大気モデル・太陽活動指数から予測されるリンク性能とを突き合わせるモニタリングの仕組みが運用に組み込まれています。JPLは深宇宙リンクの性能を事前予測・事後検証するための解析ツール群(リンク性能予測とテレメトリ照合を行うソフトウェア)を長年運用しており、これは前節で見た「問い2」の考え方——実測値とモデル予測値の乖離を継続的に監視する——を具体的なオペレーションに落とし込んだものです。予測と実測が一致しない場合、運用者はまず地上局側の機器(受信機の較正状態、アンテナの指向精度)を疑い、それでも説明がつかなければ探査機側の異常を疑う、という切り分けの手順に、デジタルツインによる予測値が判断材料として使われます。

探査機開発におけるハードウェア・イン・ザ・ループ(HIL)試験

デジタルツインの考え方は、Vモデルで見たサブシステム試験の実務とも密接に結びついています。特に重要なのが**ハードウェア・イン・ザ・ループ試験(HIL試験, Hardware-in-the-Loop Testing)**です。これは、通信サブシステムの一部の実機ハードウェア(たとえばフライトモデルの送信機やトランスポンダ)を試験台に接続し、それ以外の要素——伝搬経路、相手側の地上局受信機、探査機の姿勢や軌道の変化——はすべてデジタルツインのソフトウェアシミュレーションで模擬する、というハイブリッドな試験手法です。

HIL試験がなぜ必要かというと、純粋なソフトウェアシミュレーション(層2のプロトコルスタックシミュレーションだけ)では、実機の増幅器の非線形歪みや、実際の発振器が持つ位相雑音の細かい特性といった、モデル化しきれない実機固有の癖を見落とすリスクがあるからです。かといって、探査機全体を組み上げてから実際の軌道条件を再現した試験を行うことは、コスト的にも時間的にも現実的ではありません。HIL試験は、この2つの極——「全部ソフトウェア」と「全部実機」——の中間に位置し、最も検証したい実機部分だけを本物にして、それ以外はデジタルツインが代わりに演じることで、限られた実機資源を効率よく使いながら、実機特有の非線形性まで含めた現実的な試験を可能にします。具体的には、送信機の実機出力を、ソフトウェアで実装された自由空間損失・降雨減衰・受信機雑音のモデルに通し、その結果として得られる劣化した信号を、今度はソフトウェアの復調器(あるいは受信機の実機)に入力する、という構成が典型的です。これは相互運用性検証の回で見たユニット試験とサブシステム試験の中間に位置する試験形態だと理解することもでき、「実機同士を本当に接続する前に、片方だけを実機、もう片方をデジタルツインで代替して、できる限り現実に近い条件で確認しておく」という、コストと忠実度のバランスを取った実務上の折衷案です。

演習問題

1. リンクバジェットの手計算(1つの設計点についてEIRP・自由空間損失・G/T・変調損失を足し引きする)と、通信系デジタルツインによるシミュレーションを比較したとき、後者だけが提供できる情報を2つ挙げ、それぞれがなぜ手計算だけでは得られないのかを説明してください。

2. 本文中の異常検知の閾値判定式 $|\boldsymbol{\varepsilon}(t)| > k \cdot \sigma_{model}(t)$ について、$k$ を小さく設定した運用と大きく設定した運用のそれぞれで、どのような実務上のリスク・コストが生じるかを、リンク可用性の統計的設計で学んだ考え方も踏まえて説明してください。

3. ハードウェア・イン・ザ・ループ(HIL)試験が、「全部ソフトウェアシミュレーション」でも「全部実機を組み上げての試験」でもなく、その中間に位置することの利点を、コストと試験の忠実度(実機固有の非線形性を捉えられるか)という2つの観点から説明してください。

4. 太陽合の回で学んだ合ブラックアウト運用の準備において、デジタルツインが「問い1(予測的シミュレーション)」と「問い2(乖離検出)」の両方の枠組みでどう役立つかを、太陽合の前後という時間軸に沿って具体的に説明してください。

まとめと次回予告

デジタルツインは、実機の物理的な挙動を忠実に再現するソフトウェアモデルを構築し、実機を用いずに(あるいは実機と並行して)様々なシナリオでの試験・予測を行うという考え方です。この回では、これまでこのシリーズで個別に学んできたRF伝搬モデル(自由空間損失・降雨減衰・太陽コロナのシンチレーション)、SDR的なプロトコルスタックのソフトウェアシミュレーション、そして軌道・姿勢モデルという3つの構成要素が、時間発展する1つのシミュレーションパイプラインとして統合されることを見ました。デジタルツインは設計段階での性能予測(問い1)と、運用中の実測値との乖離に基づく異常診断(問い2)という2つの使い道を持ち、地上局側でのモニタリングや、探査機開発におけるハードウェア・イン・ザ・ループ試験という形で、すでに実務に組み込まれています。Vモデルの言葉で言えば、デジタルツインは検証の各段階を「より安く、より繰り返し可能に」する道具であり、実機という有限で貴重な資源を補う存在だと位置づけられます。

次回は視点を少し変え、打ち上げ後の探査機のソフトウェアそのものをどう更新するかという問題、すなわちOTA(Over-The-Air)更新プロトコルに軽く触れます。デジタルツインが「実機を動かす前に予測する」道具だとすれば、OTA更新は「打ち上げ後に発見された不具合や改善点を、実機のソフトウェアに実際に反映する」道具であり、この2つは「地上と実機のギャップをどう埋めるか」という同じ問題意識の、異なる側面だと言えます。

参考文献

• J. H. Yuen (ed.), Deep Space Telecommunications Systems Engineering, JPL Publication 82-76
• NASA, NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev2
• CCSDS, Radio Frequency and Modulation Systems, Part 1: Earth Stations and Spacecraft, CCSDS 401.0-B
• M. Grieves, J. Vickers, “Digital Twin: Mitigating Unpredictable, Undesirable Emergent Behavior in Complex Systems,” in Transdisciplinary Perspectives on Complex Systems, Springer, 2017
• J. R. Wertz, D. F. Everett, J. J. Puschell (eds.), Space Mission Engineering: The New SMAD
• DSN Telecommunications Link Design Handbook, DSN No. 810-005