はじめに
フライトコンピュータはロケットの「頭脳」であり、GNC（誘導・航法・制御）のアルゴリズムを実行し、センサデータの処理、エンジン指令の生成、テレメトリの管理を行う中枢システムだ。宇宙空間の過酷な環境下で確実に動作しなければならず、地上のコンピュータとは根本的に異なる設計思想が求められる。
本記事では、ロケットのフライトコンピュータの設計原則、アーキテクチャの進化、冗長設計の手法、そして現代のロケットにおける実装事例を解説する。
設計要件
ロケット環境の過酷さ
フライトコンピュータは以下の極限環境で動作しなければならない。
| 環境要因 | 条件 |
|---|---|
| 振動 | 打上げ時 20〜2000Hz のランダム振動 |
| 衝撃 | 段分離・火工品動作時のパイロショック（数千G） |
| 温度 | -40°C〜+85°C（真空中の熱管理含む） |
| 放射線 | 宇宙線・太陽粒子イベント（SEU/SET/SEL） |
| EMI/EMC | エンジン点火・火工品の電磁パルス |
| 真空 | アウトガス・熱伝導の制約 |
リアルタイム性の要求
ロケットのGNCループは典型的に50〜200Hzで動作する。フライトコンピュータは各制御サイクルのデッドラインを確実に守るハードリアルタイム性が必要だ。
| システム | 制御レート | デッドライン |
|---|---|---|
| 姿勢制御 | 50〜100Hz | 10〜20ms |
| エンジン制御 | 100〜200Hz | 5〜10ms |
| 航法更新 | 50〜100Hz | 10〜20ms |
| テレメトリ | 1〜10Hz | 100ms〜1s |
信頼性要件
有人ロケットでは、フライトコンピュータの信頼性に厳しい要件が課される。
- LOC（Loss of Crew）確率：1/500以下（NASA基準）
- LOM（Loss of Mission）確率：1/200以下
- フライトコンピュータ単体の故障がLOCに直結しないよう、冗長設計が必須
プロセッサの選定
宇宙用プロセッサの伝統
宇宙用プロセッサは、地上用と比較して数世代遅れた技術を使用するのが一般的だった。放射線耐性（Rad-Hard）の認定に時間がかかるためだ。
| プロセッサ | アーキテクチャ | 放射線耐性 | 用途 |
|---|---|---|---|
| RAD750 | PowerPC | >100 krad | Mars Rovers, 多数の衛星 |
| LEON3/4 | SPARC V8 | >300 krad | ESA衛星 |
| GR740 | SPARC V8（4コア） | >100 krad | ESA次世代 |
| Vorago VA10820 | ARM Cortex-M0 | >300 krad | 小型衛星向け |
SpaceXのアプローチ：COTS + 冗長
SpaceXは宇宙用グレードの専用プロセッサを使わず、COTS（Commercial Off-The-Shelf）プロセッサを冗長構成で使用する革新的なアプローチを採用した。
Dragon宇宙船の事例 – デュアルコアx86プロセッサ（地上用グレード） – トリプル冗長 + 多数決（Triple Modular Redundancy: TMR） – 3つの独立したフライトコンピュータが同一計算を実行し、多数決で結果を採用 – SEU（Single Event Upset）による一時的なビットフリップを多数決で検出・修正
このアプローチの利点： – 最新のプロセッサ性能を利用可能 – 低コスト（宇宙用グレードの1/100以下） – 短い調達リードタイム – ソフトウェア開発ツールチェーンが充実
Linux in Space
SpaceXはフライトコンピュータのOSにLinuxを採用したことでも知られる。
従来のロケットでは専用のリアルタイムOS（VxWorks、RTEMS等）が使用されてきたが、SpaceXはLinux上でリアルタイムスケジューリングを設定し、制御ループを動作させている。Falcon 9のフライトソフトウェアはC++で記述されている。
Linuxの利点： – 豊富なドライバサポート – 開発ツールの充実（GDB、Valgrind等） – ネットワークスタック（テレメトリ伝送） – 開発者の確保が容易
冗長アーキテクチャ
冗長の種類
フライトコンピュータの冗長設計にはいくつかのアプローチがある。
1. TMR（Triple Modular Redundancy）
Computer A ──┐
Computer B ──┼── Voter ── 出力
Computer C ──┘
3台が同一計算を行い、多数決（Voting）で出力を決定する。1台の故障を許容できる。SpaceX Dragon、SLSのフライトコンピュータで採用。
2. Dual Redundancy（ホットスタンバイ）
Primary ──── Switch ── 出力
Backup ──┘
主系統と予備系統が同時に稼働し、主系統の異常を検知したら予備系統に切り替える。多くの使い捨てロケットで採用される。
3. Quad Redundancy（2 Fail-Operational）
Computer A ──┐
Computer B ──┤
Computer C ──┼── Voter ── 出力
Computer D ──┘
4台構成で2台の故障を許容。スペースシャトルのGPC（General Purpose Computer）は5台構成（4台のPASS + 1台のBFS）を採用していた。
ビザンチン耐障害性
単純な故障（沈黙故障）だけでなく、ビザンチン故障（誤った結果を出力する故障）への対策も重要だ。プロセッサが異なるメーカーの異なるアーキテクチャであれば、共通原因故障（Common Cause Failure）のリスクを低減できる。
スペースシャトルでは、主系統4台（IBM AP-101）とは異なるソフトウェアで動作するバックアップ1台（BFS: Backup Flight Software）を搭載し、異種冗長性を確保していた。
フライトソフトウェア
ソフトウェア・アーキテクチャ
典型的なロケットのフライトソフトウェアは以下の層で構成される。
┌─────────────────────────────────┐
│ ミッションアプリケーション層 │ 誘導・航法・制御
├─────────────────────────────────┤
│ ミドルウェア層 │ タスク管理・通信・データ管理
├─────────────────────────────────┤
│ BSP / HAL層 │ ボード・ハードウェア抽象化
├─────────────────────────────────┤
│ RTOS / OS層 │ VxWorks, RTEMS, Linux
├─────────────────────────────────┤
│ ハードウェア │ CPU, I/O, メモリ
└─────────────────────────────────┘
タスクスケジューリング
GNCタスクはレート・モノトニック・スケジューリング（Rate Monotonic Scheduling: RMS）やEDF（Earliest Deadline First）に基づいてスケジュールされる。
典型的なタスク優先度：
| 優先度 | タスク | 周期 |
|---|---|---|
| 最高 | 安全監視・AFTS判定 | 100Hz |
| 高 | エンジン制御 | 100Hz |
| 高 | 姿勢制御 | 50Hz |
| 中 | 航法更新 | 50Hz |
| 中 | 誘導計算 | 10〜20Hz |
| 低 | テレメトリ送信 | 1〜10Hz |
| 最低 | ハウスキーピング | 1Hz |
ソフトウェアの検証
フライトソフトウェアの検証は多層的に行われる。
- 単体テスト（Unit Test）：個々の関数の検証
- 統合テスト（Integration Test）：モジュール間の結合検証
- SIL（Software-in-the-Loop）：ソフトウェアを仮想環境で実行
- HIL（Hardware-in-the-Loop）：実機ハードウェアでソフトウェアを実行
- FDIR検証：故障注入テストによる異常対応の検証
- Monte Carlo シミュレーション：統計的な性能・信頼性検証
通信バスとインタフェース
データバス規格
フライトコンピュータと各サブシステムの通信にはさまざまなバス規格が使用される。
| バス規格 | 速度 | 用途 | 採用例 |
|---|---|---|---|
| MIL-STD-1553B | 1 Mbps | コマンド・データ | SLS, 多数の軍用ロケット |
| SpaceWire | 200 Mbps | 高速データ | ESA衛星 |
| Ethernet | 100M〜1Gbps | 汎用 | SpaceX Falcon 9 |
| CAN | 1 Mbps | センサ・アクチュエータ | 小型ロケット |
| TTE（Time-Triggered Ethernet） | 1 Gbps | 決定論的通信 | Orion |
SpaceXがMIL-STD-1553BではなくEthernetを採用したことは、COTSアプローチの延長線上にある。高速で柔軟、低コストなネットワーク基盤を構築できる。
放射線対策
SEE（Single Event Effects）
宇宙放射線による半導体への影響は以下に分類される。
| 効果 | 略称 | 影響 | 対策 |
|---|---|---|---|
| Single Event Upset | SEU | ビットフリップ | ECC、TMR |
| Single Event Transient | SET | 一過性パルス | フィルタリング、TMR |
| Single Event Latchup | SEL | 電流ラッチ | 電流監視・電源遮断 |
| Total Ionizing Dose | TID | 累積劣化 | 耐放射線プロセス・シールド |
ソフトウェア対策
放射線耐性をソフトウェアで確保する手法：
- EDAC（Error Detection And Correction）：メモリのECC保護
- ソフトウェアTMR：重要な演算を3回実行して多数決
- チェックポイント・リスタート：定期的な状態保存と異常時の復帰
- ウォッチドッグタイマー：ハングアップ検出とリセット
- メモリスクラビング：定期的にメモリを読み書きしてエラー修正
事例研究
SLS（Space Launch System）
NASAのSLSは伝統的な宇宙グレード・アプローチを採用。
- フライトコンピュータ：BAE Systems RAD750ベース
- 冗長：TMR構成
- バス：MIL-STD-1553B
- ソフトウェア：VxWorksベース
Falcon 9
SpaceXのFalcon 9はCOTSアプローチの代表。
- プロセッサ：x86系COTS
- 冗長：TMR（3台の独立コンピュータ）
- バス：Ethernet
- OS：Linux
- 言語：C++
- 特徴：飛行中のソフトウェア更新能力
Electron
Rocket LabのElectronも現代的なアプローチ。
- 小型・軽量なフライトコンピュータ
- 電動ポンプ制御との統合
- COTSコンポーネントの活用
設計トレンド
マルチコア・プロセッサの活用
最新のフライトコンピュータでは、マルチコアプロセッサの活用が進んでいる。しかし、マルチコアでのリアルタイム認証は単一コアよりも複雑であり、WCET（Worst Case Execution Time）の解析が困難になる。
FPGA / SoC ベースの設計
FPGA（Field-Programmable Gate Array）をフライトコンピュータに組み込む設計が増えている。Xilinx Zynq UltraScale+等のSoC FPGAは、プロセッサコアとプログラマブルロジックを1チップに統合し、カスタムI/O処理と計算処理を柔軟に実装できる。
AI / ML の統合
将来のフライトコンピュータでは、GNCアルゴリズムにニューラルネットワーク推論を組み込むことが検討されている。これにはGPU/NPUの搭載や、確定的な推論実行時間の保証等の課題がある。
まとめ
ロケットのフライトコンピュータは、極限環境での信頼性とリアルタイム性を両立させる精密なシステムだ。伝統的なRad-Hardプロセッサ + VxWorksの組み合わせから、SpaceXが開拓したCOTS + Linux + TMRのアプローチへとパラダイムが移行しつつある。
COTS部品の活用は、最新のプロセッサ性能を宇宙に持ち込むことを可能にし、開発コストと期間を劇的に削減した。この革新は再使用ロケットの経済性を支える重要な要素であり、今後も宇宙アビオニクスの設計思想に大きな影響を与え続けるだろう。