NASAがArtemis IIの耐故障性コンピュータを構築した方法

 (cacm.acm.org)
7 ポイント 投稿者 GN⁺ 19 일 전 | 1件のコメント | WhatsAppで共有
  • 月周回有人宇宙船 Orion の飛行コンピュータは、Apollo時代のシステムよりも回復力と自動制御能力が大幅に向上した構造で、生命維持・電力・通信などの中核機能をすべて管理する
  • 月軌道の25万マイル先でも中断なく動作するよう、物理的・論理的な冗長構成と複数の飛行コンピュータによって、ハードウェア障害や放射線の影響に耐えるよう設計されている
  • 各 Flight Control Module(FCM) は自己検証プロセッサのペアで構成され、合計8個のCPUが並列実行される。fail-silent設計と優先順位ベースの出力選択アルゴリズムで障害を隔離する
  • システムは time-triggered Ethernet と決定論的アーキテクチャ により完全同期状態を維持し、三重化されたネットワークとメモリで単一ビット誤りまで自動修正する
  • 主系統がすべて失敗した場合に備え、独立したハードウェアとOSベースの Backup Flight Software が制御権を引き継ぐ。この構造は今後の自律システムにおける常時稼働型レジリエンスモデルとして評価されている

NASAのArtemis II耐故障性コンピュータ設計

  • Artemis II の飛行コンピュータは、Apollo時代の航法コンピュータよりも回復力と自動制御能力が大幅に向上した構造
    • Apolloのコンピュータは1MHzプロセッサと約4KBのメモリを使用し、主要制御は手動スイッチやリレーが中心だった
    • Artemis IIの Orionカプセル では、生命維持、電力、通信などすべての中核機能をコンピュータが直接管理する
  • 月軌道の25万マイル先で任務が失敗すると回復は不可能なため、システムは宇宙放射線、ビット反転、ハードウェア障害があっても中断なく動作しなければならない
    • NASAは物理的な冗長配線、論理的に冗長化されたネットワークプレーン、複数の飛行コンピュータによってハードウェア障害に備えている

  • The Power of Eight

    • Orionは従来の 三重冗長(triple redundancy) を超える構成を採用
      • 2台のVehicle Management Computer(VMC)それぞれに2つのFlight Control Module(FCM)を搭載し、合計4つのFCMで構成
      • 各FCMは 自己検証(self-checking) プロセッサのペアで構成され、合計8個のCPUが並列で飛行ソフトウェアを実行する
    • システムは fail-silent設計 を基盤としており、障害が発生したCPUは誤った出力を出さず、即座にサイレント状態へ移行する
    • 多数決投票ではなく、優先順位ベースのソース選択アルゴリズムを使って正常チャネルの出力を選択する
    • NASAはVan Allen帯通過中の一時的な障害を想定しており、最大22秒間で3つのFCMを失っても、最後の1つのFCMで任務を継続できる
    • サイレント状態になったFCMはリセット後に他のモジュールと同期し、飛行中に再参加できる

  • 決定論的動作の維持

    • 複数の独立コンピュータを完全同期(lockstep)状態に保つため、決定論的アーキテクチャ(deterministic architecture) を適用
    • Orionは time-triggered Ethernet ネットワークを使用してシステム全体に時刻を配布する
      • 飛行ソフトウェアはARINC653スケジューラが管理する メジャーフレーム(major frame) と マイナーフレーム(minor frame) 内で実行される
      • 時間・空間分割により、入力と出力がネットワークスケジュールと完全に整合するよう保証する
    • 各FCMは同一の入力を受け取り、同一のコードを実行し、同一の出力を生成する
    • 毎秒FCMのクロックドリフトを測定し、ネットワーク基準時刻へ再補正する
    • デッドラインを守れなかったアプリケーションは自動的にサイレント状態へ移行し、その後再同期される
    • ハードウェアは 三重モジュール冗長メモリ(TMR) を使って単一ビット誤りを自動修正し、ネットワークインターフェースカードも 二重トラフィック経路 を比較して障害発生時にfail-silent処理を行う
    • ネットワークは3つの独立プレーンで三重化されており、すべてのスイッチは自己検証機能を持つ

  • 最終バックアップシステム

    • NASAは、すべての主要チャネルに同時に影響し得る 共通モード故障(common mode failure) に備えている
    • そのため Backup Flight Software(BFS) システムを別途搭載
      • BFSは異なるハードウェア、異なるOS、独立して開発された簡素化飛行ソフトウェアで構成される
      • 主系統が失敗すると、自動的にBFSが制御権を引き継ぎ、任務の動的フェーズを完了できる
      • その後、乗組員が主FCMの復旧を試みることができる
    • fail-silentロジック は不可欠だが、障害が検出されないまま残らないよう、ウォッチドッグタイマーと多層監視も併用しなければならない
    • 電源の完全喪失（“dead bus”）時でも生存可能なよう設計されている
      • 電源復旧時には自動的に セーフモード(safe mode) に入る
      • 太陽電池パネルを太陽方向へ向けて電力を回復した後、熱安定化のため機体を太陽に尾を向けた姿勢にする
      • その後、地球との通信再確立を試み、必要に応じて乗組員が手動で生命維持装置を調整できる

  • 信頼性の未来

    • ApolloからArtemisへの変化は、ソフトウェア複雑性の飛躍的な増大を意味する
      • Apolloには機械的バックアップが存在したが、Artemisではソフトウェアがすべての制御を担う
    • NASAは全環境シミュレーション、モンテカルロストレステスト、大規模な故障注入(fault injection) を含む現代的な検証ワークフローを使用
      • スーパーコンピュータを活用して飛行タイムライン全体を模擬し、ハードウェア障害時でもソフトウェアがfail-silentで復旧可能かを検証する
    • Orionの ゼロトレランスアーキテクチャ は、今後 自動運転車、産業制御ネットワーク などにも適用可能な 常時稼働(always-on)レジリエンス のモデルとして評価されている

関連記事

1件のコメント

 
GN⁺ 19 일 전
Hacker Newsのコメント

  • 1989年から95年までStratusでVOSとデータベース性能に関わる仕事をしていた
    Stratusはハードウェアベースのフォールトトレラントシステム企業で、競合のTandemはソフトウェアベースのアプローチを取っていた
    Stratusのアーキテクチャは「pair and spare」で、すべてのボードが二重化され、各ピン出力を毎ティックごとに比較していた
    Motorola 68KからIntelへ移行する際、一部命令の未使用ピンが浮いてしまう問題で、ハードウェアチームはかなり苦労していた

  • CMUの研究者が言った「AgileとDevOpsがアーキテクチャ上の規律を弱めた」という表現が印象的だった
    最近は決定論的システムの作り方を忘れてしまったように思える
    Time-triggered Ethernetの厳格なフレームスケジューリングは、今のソフトウェア開発のやり方とはまったく別世界のように感じられる

    • 今でもリアルタイム保証が必要な組み込みシステムを扱っている人たちはいる
      最新の開発プラクティスの一部（単体テスト、CIなど）は、こうした環境でも良い影響を与えている
    • アポロ時代には国防総省主導の研究資金のおかげで、**WCET（最悪実行時間）**ベースの決定論的コンピューティングが主流だった
      今は商用市場中心に変わって投資は減ったが、それでも興味深いアルゴリズムは多い
      Frank MuellerやJohann Bliebergerの研究は参考になる
    • Time-triggered Ethernetは航空機認証向けデータバスの一部で、INRIAとAirbusが関連研究を行っていた
      航空機のように入出力が限られた環境では、決定論的設計が完璧に当てはまる
      実際にはEthernetというより専用ハードウェアバスに近い
    • Tesla Cybertruckもこの方式をEthernetで使っていると聞いた
    • おそらく彼が言っていたのはSpaceWireのことだと思う

  • Code Golfの「radiation hardening」チャレンジを見て、
    こうしたアプローチが実際に役に立つのだろうかと気になった
    現実にはあまりに多くのレイヤーの問題が絡んでいて難しいだろうが、それでも面白い発想だと思う

  • 記事で説明されていた**「fail-silent」設計**は興味深かった
    ただ、2つのCPUが同時に誤った計算をして、その結果が一致した場合にどう検出するのかは気になった

    • 放射線による同一ビット誤りが同時に2つのCPUで起きる確率は極めて低い
    • こうしたCPUはロックステップ構成で同じ演算を同時に実行し、結果を比較する
      2つのCPUが同時に同じ誤りを出す確率は、単一CPUのFITよりはるかに低い
    • 2つのCPUで同時に同じビットが反転する確率は、むしろ小惑星衝突が起きる確率より低い
      それでも宇宙ではMurphyの法則が通用するので、断言はできない
    • 実際、3重多数決構成でも2つのCPUが同じ誤りを出せば同じ問題が起こる
    • システム1と2が同時に誤動作し、残り6つが正常だったとしても、
      「25%多数決」で誤った結果が選ばれる可能性はある

  • このシステムのCPU、RAM、OS、言語などの具体的な情報が知りたい
    FCMがどれくらいの頻度で「fail-silent」になったのかも気になる

    • NASA cFSはCで書かれており、GitHubで公開されている
      通常はFreeRTOSやRTEMS上で動作する
      個人的にはプロジェクト構造が複雑すぎて扱いづらかった
    • BFSはcFSを使っており、YouTube動画でも見られる
      NASAの中核コードの大半は非公開だが、cFSは古典的な飛行ソフトウェア設計を学ぶには良い資料だ

  • 記事では実際のRTOSとアーキテクチャに関する詳細が抜けている
    Orionの主飛行制御はGreen Hills INTEGRITY RTOSとBAE RAD750プロセッサに基づく4重冗長構成だ
    BFSはまったく異なるLEON3 + VxWorksハードウェア上で動作し、NASAのcFSフレームワークを使っている
    これはJames Webb望遠鏡やMars Roverでも使われたモジュール型再利用アーキテクチャだ
    この構成は単なる「主系＋バックアップ」ではなく、**異種冗長化（dissimilar redundancy）**の考え方だ
    詳しくはNASA技術文書 1、文書 2を参照

    • ただ、完全に別チームであっても、同じ教科書やアルゴリズムの出典を使っていれば同じ不具合が生じる可能性はある

  • 実際の製造はLockheed Martinと下請け企業が担当していた
    メディアがNASAが直接作ったかのように表現するのは誤解を招く

    • LockheedがNASAの要請なしに、あの高価な4重冗長PowerPCシステムを作ったとは思えない
    • BFSは主にNASA内部で開発された（直接関わった友人の証言）
    • 実際にはNASAとLockheedの間で緊密な協業があったはずだ
    • 「メガコープを想像してみろ」という冗談も出ていた

  • 25年前にWeb開発者として働いていた頃、NASA出身の友人に「バグはどう処理していたのか」と聞いたところ、
    彼は笑って「バグなんてなかった」と答えた
    今の開発者たちは、失敗しても人命が懸からない環境に慣れてしまっている

    • 業界ごとに「十分によい」の基準は違う
      Webサービスなら売上損失程度だが、宇宙船では人命が懸かっている

  • 以前耐放射線コンピュータを開発したことがあるが、
    単純な冗長化に加えて非冗長なエラー検出手法も使っていた
    今回のシステムではそうしたアプローチが見えないのが少し残念だ

    • スペースシャトル時代には5台のコンピュータを互いに異なる位置と向きに設置して、
      放射線衝突断面積を分散させる物理的ハードニングも行っていた

  • さまざまな冗長構成は素晴らしいが、手動操縦（Manual Override）機能が今でも可能なのか気になる
    アポロ11号や13号のように、必要なときに直接制御できるのか知りたい
    今でも    テストパイロット出身の宇宙飛行士    が操縦しているのだから、可能なのではないかと思う