Artemis IIの耐障害性（フォールトトレランス）の仕組みを徹底解剖

Artemis IIにおける耐障害性の実装や設計アプローチについて解説します。ミッションの成功を左右する冗長性や異常系処理のアーキテクチャはどうなっているのでしょうか？詳細な技術的議論を深めていきましょう。

Airbusの場合、CPU自体にもバグがあるからという理由で、異なるCPUを使っていたよね…

Orionは2台のVehicle Management Computerを活用していて、それぞれに2つのFlight Control Module（FCM）が搭載されているから、合計4つのFCMがある。でも冗長性はさらに深くて、各FCMは自己診断機能を持つプロセッサペアで構成されている。

一体誰が8個が正解だと決めたんだろう？なんで4個じゃないの？それとも2個？あるいは16個か32個じゃないのはなぜ？

面白いね。安全性に関わるコンポーネントで、うちはLockstep Microcontrollerを使っているけど、もっと小規模で似たようなことをやっているよ。

https://en.wikipedia.org/wiki/Lockstep_(computing) (https://en.wikipedia.org/wiki/Lockstep_(computing))

例: https://www.st.com/resource/en/datasheet/spc574k72e5.pdf (https://www.st.com/resource/en/datasheet/spc574k72e5.pdf)

見てみたいのは障害データだね。それと、同期しているFCMの数の推移を示すグラフと、それが予測とどのくらい一致していたか。要するに、どれだけ過剰設計になっているのかが気になる。

システムソフトウェアを作る上で、異種冗長性（Dissimilar Redundancies）って概念がすごく好きだよ（今日までその用語は知らなかったけど）。

いろんなLinuxディストリビューションやいくつかのBSD向けにビルドしてみるといい。奇妙なコンパイルエラーやエッジケースに必ず遭遇するから。単一のプラットフォーム向けに作っていたら気づかないような未定義の挙動や、間違った思い込みを浮き彫りにしてくれることがよくあるんだ。

宇宙飛行士に必要なトレーニング量って相当なものだろうな。

自己診断ペアによって、放射線イベントが原因でCPUが誤った計算をした場合に、そのエラーを即座に検知してシステムが応答する。

ペアのうち、どちらが正しく計算したのか、どうやって判断しているんだろう？

正直なところ、ある程度の冗長性が必要なのは理解できるけど、これだけの冗長性がシステム全体にどれだけの複雑さを付け加えているのか、そしてその複雑さによるリスクの方が、高い冗長性による恩恵を上回ってしまっていないかが気になる。NASAのことだからトレードオフは計算済みだろうけど、その背後にある考え方を見てみたいね。

ここ数年の航空機事故について知ると似たようなことを感じるよ。システムの冗長性と、それによって加わる複雑さが、事故を防ぐどころか間接的な原因になっているように思える時があるから。まあ、冗長性によって防げた事故の数を定量化して直接比較するのは、現実的に難しいんだろうけど。