アリアン V88 便

クラスタ

ミッションタイプ	磁気圏
オペレーター	欧州宇宙機関
宇宙船の特性
打ち上げ質量	1,200キログラム（2,600ポンド）
ミッション開始
発売日	1996年6月4日 12:34:06 (UTC) ( 1996-06-04T12:34:06Z )
ロケット	アリアン5G
発射場	クールー ELA-3
ミッション終了
廃棄	打ち上げ失敗
破壊された	1996年6月4日 ( 1996-06-04 )
ESAのクラスター四辺形ミッションの記章 ホライゾン2000

アリアンV88便^{[1]は、1996年6月4日に行われた}アリアンスペースのアリアン5ロケット501号機の失敗した初飛行である。この飛行では、欧州宇宙機関の研究衛星4機からなるクラスター宇宙船が搭載された。

打ち上げはソフトウェア設計の複数のエラーにより失敗に終わった。アリアン4のみを対象としたデッドコードには整数オーバーフローに対する保護が不十分で、例外処理が不適切となり、影響を受けなかった慣性航法システム全体が停止した。これによりロケットは打ち上げから37秒後に飛行経路を外れ、高い空気力で分解し始め、最終的には自動飛行終了システムによって自爆した。この失敗は歴史上最も悪名高く、最も高額なソフトウェアバグの1つとして知られるようになった。^[2]この失敗により3億7千万ドル以上の損失が発生した。^[3]

アリアン5はアリアン4の慣性基準プラットフォームのコードを再利用したが、アリアン5の飛行経路の初期部分はアリアン4と異なり、水平速度の値が高くなっていた。このため、アライメント機能で計算された内部値BH（水平バイアス）が予想外に高くなった。アライメント機能はアリアン4の要件に基づいて約40秒間飛行していたが、アリアン5の打ち上げ後は役に立たなかった。^{[4] BHの値が高かったため、} 64ビット浮動小数点数から16ビット符号付き整数値へのデータ変換でオーバーフローが発生し、ハードウェア例外が発生した。^[5]プログラマーは、搭載慣性基準システムコンピューターの最大作業負荷目標を80%に抑えるために、7つの重要な変数のうち4つだけをオーバーフローから保護し、保護されていない3つの変数の値の可能な範囲に関して、アリアン4の軌道には正しかったがアリアン5には正しかった仮定に依存していました。 ^{[6]この例外により、}冗長化を意図していた慣性基準システムモジュールの両方が停止しました。アクティブなモジュールは、飛行データとして解釈される診断ビットパターンを搭載コンピューターに提示し、特に固体ブースターとヴァルカン主エンジンのノズルが完全に偏向しました。これにより、迎え角が20度を超え、ブースターが主段から分離し、発射台の自爆システムが起動し、飛行が破壊されました。^[4]

墜落に関する公式報告書 (ジャック=ルイ・リオン氏が率いる調査委員会が作成) には、「アリアン 5 の開発における根本的なテーマは、ランダム障害の緩和に向けた偏向である。慣性航法システム(SRI)の供給業者は、例外が検出された場合にはプロセッサを停止するという規定を含む、与えられた仕様だけに従っていた。発生した例外はランダム障害によるものではなく、設計エラーによるものだった。例外は検出されたが、ソフトウェアに欠陥があると証明されるまではソフトウェアは正しいとみなされるべきだという見解がとられていたため、不適切に処理された。[...] 障害は体系的なソフトウェア設計エラーによるものだが、この種の問題を緩和するメカニズムを導入することはできる。たとえば、SRI 内のコンピュータは、必要な姿勢情報の最良の推定値を提供し続けることができたかもしれない。ミッションクリティカルな機器を処理中にプロセッサを停止させるためにソフトウェア例外を許可すべき、あるいは要求すべきであることには懸念すべき理由がある。実際、SRIの両ユニットで同じソフトウェアが動作しているため、適切なソフトウェア機能が失われると危険です。アリアン501の場合、この結果、まだ健全な2つの重要な機器ユニットの電源がオフになりました。」^[4]

報告書で特定されたその他の問題は、検査に焦点を当てている: ^[4]

• アリアン 5 計画のすべての主要パートナーが参加するレビュー プロセスの目的は、設計上の決定を検証し、飛行資格を取得することです。このプロセスでは、調整ソフトウェアの制限が十分に分析されておらず、飛行中にソフトウェアが機能し続けることを許可した場合の影響が認識されていませんでした。
• 慣性基準システムの仕様と機器レベルで実施されたテストには、アリアン 5 の軌道データが具体的に含まれていなかったため、アリアン 5 の飛行状況をシミュレートした状態で再調整機能がテストされず、設計エラーは発見されませんでした。
• 実行されたシステム全体のシミュレーションに慣性基準システムのほぼ全体を含めることは技術的に可能だったでしょう。いくつかの理由から、実際のシステムやその詳細なシミュレーションではなく、慣性基準システムのシミュレーション出力を使用することが決定されました。システムが含まれていれば、障害を検出できた可能性があります。飛行後のシミュレーションは、慣性基準システムのソフトウェアと、アリアン 501 飛行の実際の軌道データを含むシミュレーション環境を使用してコンピューターで実行されました。これらのシミュレーションは、慣性基準システムの障害につながる一連のイベントを忠実に再現しました。

システム工学に基づく失敗のもう一つの観点は、要件に焦点を当てている: ^[7]

• 水平速度やそこから計算される量 BH などの変数の範囲は、明示的に定量化される必要がありました。代わりに、16 ビットの範囲が想定されました。
• アライメント タスクは適切な時点で停止されるはずでした。しかし、アライメント タスクは打ち上げ後に実行されていました。
• 慣性基準プラットフォームの障害モデルは、最大で 1 つのモジュールが故障すると想定するのではなく、飛行中サービスが継続的に提供されるように分析されるべきでした。しかし、両方のモジュールが故障し、飛行を正常に終了させるのではなく、出力された診断メッセージが飛行データとして解釈されました。

クラスターは、224ワットの太陽電池で駆​​動する、 1,200キログラム（2,600ポンド）の円筒形のスピン安定化宇宙船4機で構成されていた。宇宙船は四面体編隊で飛行し、地球の磁気圏の調査を行うことになっていた。衛星は、赤道に対して90度傾斜した、17,200 x 120,600キロメートル（10,700 x 74,900マイル）の高度に楕円形の軌道に配置される予定だった。 ^[8]

この失敗の後、代替のCluster II衛星が 4 機製造され、 2000 年に ソユーズ U /フレガートロケットで 2 機ずつ打ち上げられました。

打ち上げ失敗により、複雑なコンピューティングシステムに伴う高いリスクが一般大衆、政治家、企業幹部の注目を集め、安全性が重要なシステムの信頼性を確保するための研究への支援が拡大した。その後のアリアンコード（ Adaで記述）の自動解析は、抽象解釈による大規模な静的コード解析の最初の例となった。^[9]

この失敗は、アリアン4型の高い成功率によって達成された欧州宇宙機関のロケットファミリーの優れた成功記録にも悪影響を及ぼした。アリアン5の打ち上げが前身のモデルと同じくらい信頼できると認められたのは2007年になってからだった。^[10]

• 以前の火星探査機から改造された火星探査機のソフトウェアは、打ち上げ前に十分にテストされていなかった。
• アポロ誘導コンピュータ - PGNCS トラブル、サブシステムが不適切に稼働したままになったために宇宙船誘導コンピュータが被害を受けた別の事例
• ソフトウェアのバグ一覧

• Thomas, LD (2007). 「選択されたシステムエンジニアリングプロセスの欠陥とその結果」. Acta Astronautica . 61 (1–6): 406–415. Bibcode :2007AcAau..61..406T. doi :10.1016/j.actaastro.2007.01.005. hdl : 2060/20070002067 . ISSN  0094-5765 – NTRS経由.

• ジャック＝ルイ・ライオンズ他、アリアン501調査委員会報告書（）
• Spaceflight Now – Cluster II – Ariane 501 が爆発、Wayback Machine (2015 年 3 月 25 日アーカイブ)、ビデオ ファイルへの直接リンク — ロケット飛行の最後の数秒間の映像。
• Wired – 史上最悪のソフトウェア バグ — ソフトウェア バグのトップ 10 に関する記事。アリアン 5 フライト 501 のソフトウェア グリッチがこれらのバグの 1 つとして言及されています。
• (ドイツ語) Ariane 5 – 501 (1–3) — 問題の実際のコードが記載されている優れた記事 (ドイツ語)。