Ariane 5：型変換オーバーフローで自爆したロケット

何が起きたか

横にスクロール

1996年6月4日、欧州宇宙機関（ESA）の新型大型ロケットAriane 5が初めて空へ向かった。Ariane 5は、それまで主力だったAriane 4を置き換えるべく、長い年月と巨額の費用を投じて開発された欧州の威信をかけた機体だった。ところが、その晴れ舞台はわずか40秒足らずで終わる。

離陸後、ロケットは正常に上昇を始めたように見えた。しかし数十秒後、機体は突如として大きく姿勢を崩し、想定外の方向へ傾き始める。エンジンのノズルが限界まで振れ、機体には設計の許容を超える空気力がかかった。構造は分解を始め、飛行の異常を検知した自動破壊システムが作動して、Ariane 5は搭載物もろとも空中で失われた。

原因は、エンジンの故障でも燃料タンクの破裂でもなかった。機体そのものは物理的に健全であり、事故を引き起こしたのはたった一箇所のソフトの欠陥だった。飛行の姿勢を計算する心臓部で、あるはずのないエラーが起き、それが処理されないまま制御系を丸ごと沈黙させたのである。数億ドル規模の損失を生んだこの事故は、ソフトウェア工学の歴史に残る代表的な失敗として、いまも語り継がれている。

技術的な根本原因

問題の中心にあったのは、慣性基準系（SRI: Inertial Reference System）と呼ばれる装置のソフトだ。SRIは、ロケットがいまどの向きにどれだけの速度で進んでいるかを計測し、その姿勢データを飛行制御コンピュータへ送る、いわば機体の「平衡感覚」を担う部品である。

事故の引き金は、この中の一行にあった。水平方向の速度を表す値は、内部では64ビットの浮動小数点数として保持されていた。それを別の用途に渡すため、16ビットの符号付き整数へ変換する処理が置かれていたのだ。16ビットの符号付き整数が表せる範囲は限られている。

16ビット符号付き整数の範囲: -32768 〜 32767

水平方向速度（64ビット浮動小数点）を16ビット整数へ変換
  Ariane 4 の飛行プロファイル: 値は範囲に収まる → 正常
  Ariane 5 の飛行プロファイル: 値が上限を超過   → Operand Error

このコードは、もともと先代のAriane 4のために書かれたものを、そのまま再利用したものだった。Ariane 4では、水平方向の速度がこの範囲を超えることはなく、変換は常に安全に行えた。ところがAriane 5は、より強力で、離陸直後からはるかに大きな水平加速度を持つ。その結果、速度の値はあっという間に16ビット整数の上限を突き破り、変換はオーバーフローを起こした。

この変換の失敗は「Operand Error」という例外として検出された。だが、そのコードには例外を受け止めて安全に処理する仕組みが用意されていなかった。処理されない例外はそのままSRIを停止させ、装置はエラーコードを含む診断データを出力して沈黙した。飛行制御コンピュータは、姿勢データの代わりに意味をなさない診断ビット列を受け取り、機体を誤った方向へ操舵してしまった。

さらに事態を悪くしたのが、冗長系の設計だ。SRIは故障に備えて二重に搭載されていたが、予備系もまったく同一のソフトを積んでいた。同じ入力に対して同じコードは同じ結果を出す。予備系も、能動系とほぼ同時に、まったく同じオーバーフローで停止した。二重化は、片方が壊れても他方が生き残ることを前提とするが、両者が同じ原因で同時に倒れるなら、その前提は成り立たない。

もう一つ皮肉なのは、このオーバーフローを起こした計算が、離陸してしまえば本来は不要だった点である。当該の処理は打ち上げ前の位置合わせのためのもので、飛行中に動かし続ける必要はなかった。にもかかわらず、Ariane 4の運用上の都合で離陸後も一定時間動作を続ける仕様が残されており、その惰性で動いていた処理が、まさに機体を失わせた。型変換や例外の詳しい仕組みはプログラミングの基礎も参照するとよい。

教訓

この事故が残した教訓は、宇宙開発に限らず、あらゆるソフトウェア開発に通じる。

第一に、コードの再利用には、動作する前提条件の再検証が欠かせない。Ariane 4で完璧に動いていたコードは、決して「バグ」ではなかった。ただ、Ariane 5という新しい文脈では前提が崩れていた。他所から持ち込んだコードは、その動作範囲や暗黙の仮定ごと引き継がれる。新しい環境の入力が、元の想定範囲に本当に収まるのかを問い直さないまま流用することが、いかに危ういかを示している。

第二に、例外・エラー処理は設計の一部として明示的に扱わねばならない。この値がこの範囲を超えることはない、という判断で例外処理を省くと、その判断が外れた瞬間に系全体が沈黙する。起こり得ないと信じた事象が起きたときに、どう振る舞うかを決めておくことこそが、堅牢なソフトの条件である。停止して診断データを流すという振る舞いは地上試験では妥当でも、飛行中には最悪の選択だった。

第三に、冗長化は万能ではない。同じ設計・同じコードの多重化は、ハードの偶発故障には強いが、設計に起因する共通原因故障の前では無力だ。二つのSRIは、独立した二つの安全網ではなく、同じ弱点を共有した一つの仕組みにすぎなかった。真の冗長性を求めるなら、実装そのものを別系統にするといった多様性が要る。

第四に、実機に近い条件でのテストの重要性だ。もしAriane 5の実際の飛行プロファイル、すなわち大きな水平加速度を含む軌道を入力としてSRIのソフトを検証していれば、このオーバーフローは打ち上げ前に発見できたはずだった。想定の範囲だけを試すテストは、想定の外にある欠陥を決して照らし出さない。同種の、単位や数値の扱いをめぐる失敗としては、探査機を失った火星気候探査機の事故も対をなす事例である。

まとめ

Ariane 5 Flight 501は、物理的にはどこも壊れていない機体を、たった一箇所の型変換オーバーフローが葬った事故だ。64ビット浮動小数点から16ビット整数への変換、処理されなかった例外、そして同一コードゆえに共倒れした冗長系という三つの要素が重なり、離陸から40秒足らずで数億ドルが失われた。

学ぶべきは、コードの再利用では前提条件を疑い、例外処理を設計に組み込み、冗長化の独立性を確かめ、実機に近い条件でテストせよ、という基本の徹底である。派手な技術よりも、この地道な基本こそが大惨事を防ぐ。ほかの現実の障害事例はインシデント事例集から辿れる。