はじめに
ロケットのGNCシステムは、実際に飛行する前に地上で徹底的に検証される必要がある。しかし、ロケットの飛行試験は莫大なコストと高いリスクを伴うため、地上でのシミュレーションベースの検証が不可欠だ。
SIL（Software-in-the-Loop）とHIL（Hardware-in-the-Loop）は、GNCシステムを段階的に検証するためのシミュレーション・テスト手法であり、ロケット開発における品質保証の中核を成す。本記事では、SIL/HILテストの原理、構成、ロケットGNCへの適用を解説する。
V字モデルと検証プロセス
開発の V字プロセス
ロケットのGNC開発はV字モデルに基づいて進められることが多い。
要件定義 ──────────────────────────── システム検証（HIL/飛行試験）
│ ↑
↓ │
システム設計 ──────────────────── 統合テスト（HIL）
│ ↑
↓ │
サブシステム設計 ────────── サブシステムテスト（SIL/HIL）
│ ↑
↓ │
詳細設計・実装 ──── 単体テスト
V字の左側で設計が進み、右側で対応する検証が行われる。SIL/HILはV字の右側上部に位置し、統合レベルの検証を担う。
検証レベルの階層
| レベル | 手法 | 対象 | 忠実度 |
|---|---|---|---|
| 1 | MIL（Model-in-the-Loop） | アルゴリズムの数学モデル | 低 |
| 2 | SIL（Software-in-the-Loop） | フライトソフトウェア（ホストPC上） | 中 |
| 3 | PIL（Processor-in-the-Loop） | フライトソフトウェア（ターゲットCPU上） | 中〜高 |
| 4 | HIL（Hardware-in-the-Loop） | フライトハードウェア + ソフトウェア | 高 |
| 5 | 飛行試験 | 実機飛行 | 最高 |
SIL（Software-in-the-Loop）
概要
SILテストでは、フライトソフトウェアをホストPC上で実行し、環境モデル（6DoFシミュレータ等）と接続してGNC機能を検証する。
┌──────────────────────────────────────┐
│ ホストPC │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ フライト │ │ 環境シミュ │ │
│ │ ソフトウェア │←→│ レーション │ │
│ │ （GNC） │ │ （6DoF） │ │
│ └──────────────┘ └──────────────┘ │
│ │
└──────────────────────────────────────┘
SILの利点
- 高速実行：リアルタイムよりも高速に実行可能（非リアルタイム）
- デバッグ容易：標準の開発ツール（GDB、IDE等）が利用可能
- 自動化：CI/CDパイプラインに統合可能
- 大量テスト：Monte Carloシミュレーション（数千〜数万ケース）に適する
- 低コスト：特殊なハードウェア不要
SILの制限
- タイミングの忠実度：ホストPCのスケジューリングはフライトコンピュータと異なる
- ハードウェア固有の挙動：浮動小数点演算の精度差、メモリレイアウトの差異
- I/Oの忠実度：実際のセンサ・アクチュエータのインタフェースが欠如
- リアルタイム制約：デッドライン違反の検出が困難
フライトソフトウェアのクロスコンパイル
SILテストでフライトソフトウェアを正確に検証するには、フライトコードの移植性が重要だ。
- HAL（Hardware Abstraction Layer）：ハードウェア依存部分を抽象化層で隔離
- クロスコンパイル対応：フライトコードをホストPC（x86等）とターゲット（ARM, PowerPC等）の両方でビルド可能にする
- 条件コンパイル：SIL環境とフライト環境で異なるI/Oドライバを切り替え
PIL（Processor-in-the-Loop）
概要
PILテストでは、フライトソフトウェアをターゲットプロセッサ上で実行し、環境モデルはホストPCで動作させる。
┌────────────────┐ ┌──────────────┐
│ ターゲットCPU │ 通信 │ ホストPC │
│ ┌────────────┐ │←─────→│ ┌──────────┐ │
│ │フライトSW │ │ JTAG │ │6DoFシミュ│ │
│ │（GNC） │ │ UART │ │レーション│ │
│ └────────────┘ │ Ether │ └──────────┘ │
└────────────────┘ └──────────────┘
PILの目的： – ターゲットCPUでの実行タイミングの検証 – 浮動小数点演算の精度確認（固定小数点CPUの場合特に重要） – メモリ使用量の実測 – コード最適化の効果確認
HIL（Hardware-in-the-Loop）
概要
HILテストでは、実際のフライトハードウェア（フライトコンピュータ、IMU、GPS受信機、アクチュエータ等）を使用し、環境モデルがリアルタイムシミュレータから電気信号として提供される。
┌──────────────────────┐ ┌──────────────────┐
│ フライトハードウェア │ 実信号 │ リアルタイム │
│ │←──────→│ シミュレータ │
│ ・フライトコンピュータ│ │ │
│ ・IMU │ アナログ│ ・環境モデル │
│ ・GPS受信機 │ デジタル│ ・センサ信号生成 │
│ ・アクチュエータ │ PWM │ ・アクチュエータ │
│ ・データリンク │ 1553 │ 負荷シミュレーション│
│ │ Ether │ │
└──────────────────────┘ └──────────────────┘
HILシミュレータの構成
リアルタイムコンピュータ
HILシミュレータのコアは、決定論的なリアルタイムOSで動作する高性能計算機だ。
| プラットフォーム | メーカー | RTOS |
|---|---|---|
| PXI | National Instruments | LabVIEW RT |
| dSPACE | dSPACE | SCALEXIO |
| Speedgoat | Speedgoat | Simulink Real-Time |
| カスタム | 各社 | VxWorks, QNX, PREEMPT-RT |
信号条件付け（Signal Conditioning）
リアルタイムシミュレータとフライトハードウェアの間には、信号条件付け回路が必要だ。
| 信号タイプ | 用途 | 仕様例 |
|---|---|---|
| アナログ出力 | IMU出力模擬 | ±10V, 16bit DAC |
| アナログ入力 | アクチュエータ指令取得 | ±10V, 16bit ADC |
| デジタルI/O | 離散信号（火工品指令等） | 3.3V/5V TTL |
| シリアル通信 | データバス | 1553B, RS-422, Ethernet |
| RF信号 | GPS模擬 | GPS信号シミュレータ |
GPSシミュレータ
HILテストでGPS受信機を検証するには、GPS信号シミュレータ（RF signal generator）が使用される。シミュレーションされた軌道に基づいてGPS衛星信号をRFで生成し、GPS受信機のアンテナ入力に注入する。
| メーカー | 製品例 |
|---|---|
| Spirent | GSS9000 |
| Rohde & Schwarz | SMBV100B |
| Safran | Skydel |
IMUシミュレーション
IMU（加速度計・ジャイロ）の出力信号を模擬する方法：
方法1：電気信号注入 – シミュレーションされた加速度・角速度をアナログ/デジタル信号としてIMUの出力端に注入 – 実際のIMUセンサ部をバイパス
方法2：モーションテーブル – 3軸または5軸のモーションテーブル上にIMUを搭載 – 物理的にIMUを動かしてセンサ出力を生成 – 帯域の制限（大きな加速度の再現が困難）
方法3：仮想IMU – IMUのデジタル出力を直接シミュレータから注入 – デジタルインタフェース（SPI、シリアル等）で接続 – 最も柔軟だが、センサ固有の挙動（ノイズ特性等）の再現に注意
アクチュエータのシミュレーション
TVC用アクチュエータのHILテストでは：
負荷シミュレータ – アクチュエータに接続された負荷モータが空力荷重を模擬 – シミュレーションされたヒンジモーメントを負荷として印加 – アクチュエータの実応答をシミュレーションにフィードバック
エレクトリカルインタフェースのみ – アクチュエータの電気的インタフェースのみを接続 – 物理的なアクチュエータ動作は行わず、指令信号の検証のみ
リアルタイムシミュレーションの課題
タイムステップと計算負荷
HILシミュレーションはハードリアルタイムで動作しなければならない。各タイムステップの計算が確実にデッドライン内に完了する必要がある。
| モデル | 典型的なステップ | 計算負荷 |
|---|---|---|
| 剛体ダイナミクス | 1ms | 低 |
| 柔軟体モデル | 0.1ms | 中〜高 |
| スロッシングモデル | 0.5〜1ms | 中 |
| エンジンモデル | 0.1〜1ms | 中 |
| 空力モデル | 1ms | 低〜中 |
| 環境モデル（大気・重力） | 10ms | 低 |
モデルの忠実度と計算負荷のトレードオフがあり、HIL用のリアルタイムモデルは非リアルタイム用の高忠実度モデルよりも簡素化される場合がある。
レイテンシ
シミュレータとフライトハードウェア間の通信レイテンシは制御ループの安定性に影響する。典型的にはレイテンシを1タイムステップ以下に抑える必要がある。
テストシナリオ
公称飛行シナリオ
正常な飛行プロファイルの全フェーズを通じたエンドツーエンドテスト。打上げから軌道投入（および着陸）までの全フェーズをリアルタイムで実行する。
異常シナリオ（FDIR検証）
Fault Detection, Isolation, and Recovery（FDIR）の検証は HILテストの重要な目的だ。
| 異常シナリオ | テスト内容 |
|---|---|
| エンジン停止 | 1基のエンジン停止時の制御応答 |
| センサ故障 | IMUバイアス異常、GPS喪失 |
| アクチュエータ故障 | TVC固着（ジャム）、ハードオーバー |
| 通信故障 | テレメトリ喪失、コマンドリンク断 |
| 電源異常 | 電圧低下、電源系切替 |
| 環境異常 | 極端な風、大気密度異常 |
AFTS検証
AFTS（自律型飛行中断システム）のHILテストでは、安全境界近傍での判定ロジックの正確性を検証する。誤判定（不必要な中断）と見逃し（必要な中断の失敗）の両方について評価する。
自動化とCI/CD
テスト自動化
SIL/HILテストの自動化は、ロケットGNC開発の効率と品質を大幅に向上させる。
- テストスクリプト：Python等でテストシナリオを記述
- 自動判定：パス/フェイル基準を定義して自動評価
- レグレッションテスト：ソフトウェア変更時の自動回帰テスト
- CI/CDパイプライン統合：コードコミットごとにSILテストを自動実行
SpaceXのアプローチ
SpaceXは「テスト・テスト・テスト」の文化で知られ、SIL/HILテストを大規模に自動化している。フライトソフトウェアの変更は自動化されたSILテストスイートを通過してから統合される。
発展的手法
PHIL（Power Hardware-in-the-Loop）
電力系統（バッテリー、電力変換器）を含むHILテスト。電力アクチュエータ（EMA等）の実電力特性を含めた検証を行う。
CHIL（Controller Hardware-in-the-Loop）
フライトコンピュータ（コントローラ）のみを実ハードウェアとし、センサ・アクチュエータはすべてシミュレーションで模擬する。HILよりも簡素で、フライトソフトウェアの検証に焦点を当てる。
デジタルツイン
実機のデジタルツイン（高忠実度の仮想モデル）を構築し、飛行データでモデルを逐次更新する。飛行後の解析と次回飛行の予測に活用される。再使用ロケットでは飛行データの蓄積がデジタルツインの精度向上に貢献する。
まとめ
SIL/HILテストは、ロケットGNCの検証において飛行試験に次ぐ最高レベルの忠実度を提供する。SILによる大量の自動テストとHILによる実ハードウェア検証の組み合わせにより、フライトソフトウェアの品質と信頼性が保証される。
テスト自動化とCI/CD統合の進展は、ロケット開発のイテレーション速度を加速させている。SpaceXの高頻度打上げを支えているのは、こうした地上検証インフラの充実にほかならない。