Ariane 5のFlight 501の歴史的な影響は何でしたか？

Ariane 5ロケットの処女航海（Flight 501）での打ち上げから37秒後の分解は、歴史上、最も高価なソフトウェアバグの 1つと呼ばれています¹：

欧州宇宙機関が10年間と70億ドルを費やして、3トンの衛星のペアを打ち上げるたびに軌道に打ち込むことができる巨大なロケットであるアリアン5を生産しました。

昨年6月にロケットがその初飛行に1分もかからず爆発し、フランス領ギアナのマングローブの沼地に燃えるような瓦礫を散布したのは、64ビットの数値を16ビットの空間に詰め込もうとする小さなコンピュータプログラムだけでした。

1つのバグ、1つのクラッシュ。コンピュータサイエンスの記録に記録されているすべての不注意なコード行の中で、これは最も壊滅的に効率が良いものであると言えます。ロケット工学の専門家へのインタビューと宇宙機関のために準備された分析から、算術エラーから完全な破壊への明確な道が現れます。

Flightの501の失敗とその後の調査は、安全上重要なシステムとソフトウェアテストの研究に影響を与えた大きな変化は何ですか？

私はバグ自体の説明を探しているのではなく、失敗の調査に触発された、または直接関連した調査という点での、バグの歴史的な影響の説明を探しています。たとえば、このペーパーでは次のように結論しています。

静的分析を使用して、次のことを行いました。

• 変数の初期化を確認し、
• シェア変数の潜在的なデータアクセス競合の完全なリストを提供します。
• Adaセマンティクスから潜在的な実行時エラーを徹底的にリストします。

私たちの知る限り、これはブールベースおよび非ブールベースの静的解析手法を使用して産業用プログラムを検証するのは初めてです。

同様に、この論文^（pdf）は次のように述べています

Ariane 5ランチャーとARDの組み込みADAソフトウェアの静的分析には、抽象解釈ベースの静的プログラム分析が使用されています。静的プログラムアナライザーは、スカラーや浮動小数点のオーバーフロー、配列のインデックスエラー、ゼロによる除算や関連する算術例外、初期化されていない変数、データ競合などのランタイムエラーの確定性、可能性、不可能性またはアクセス不能性の自動検出を目的としていますアナライザーは、Ariane 501フライトエラーを自動的に検出できました。組み込みの安全性クリティカルソフトウェア（航空電子工学ソフトウェアなど）の静的分析は非常に有望です。

この単一のイベントがソフトウェアテストのアプローチとツールに与えた影響を徹底的に説明したいと思います。

_{¹ 70億ドルという数字は、おそらくAriane 5プロジェクトの総コストを参照していると、ウィキペディアは、失敗により3億7000万ドル以上の損失が発生したと報告しています。それでもかなり高価な失敗ですが、70億ドルという数字にはほど遠いものです。}

技術的に言えば、それは「ソフトウェアの腐敗」の場合でした。飛行制御ソフトウェアは、初期のAriane 4ロケットからリサイクルされました。ソフトウェアを開発するのにどれほどの費用がかかるかを考えると、特に、ほとんどの商用ソフトウェアが必要とするよりもはるかに厳しい基準でテストおよび検証する必要があるミッションクリティカルなソフトウェアの場合、賢明な動きです。

残念ながら、動作環境の変化がもたらす影響をテストしたり、テストを十分に徹底した基準でテストしたりしなかった人は誰もいませんでした。

ソフトウェアは、特定のパラメーターが特定の値（推力、加速、燃料消費率、振動レベルなど）を超えないことを期待して作成されました。Ariane 4での通常の飛行では、これらのパラメーターは何かがすでに見事に間違っていなければ無効な値に到達することはないため、問題ではありませんでした。ただし、Ariane 5の方がはるかに強力で、4では馬鹿げていると思われる範囲が5で非常に簡単に発生する可能性があります。

どのパラメーターが範囲外になったのかはわかりませんが（加速であった可能性があるため、確認する必要があります）、そうした場合、ソフトウェアは対応できず、算術オーバーフローが発生しました不十分なエラーチェックと回復コードが実装されました。ガイダンスコンピューターは、エンジンノズルジンバルにゴミを送り始めました。エンジンジンバルは、かなりランダムにエンジンノズルを向け始めました。ロケットが転倒して崩壊し始め、自動自己破壊システムがロケットが危険な回復不可能な姿勢になったことを検出し、作業を終了しました。

正直なところ、このような問題はおそらく新しい教訓をもたらさなかったでしょう。これは、あらゆる種類のシステムで以前にこの種の問題が発見されており、エラーの発見と修正に対処するための戦略がすでに整っているためです。インシデントが行ったのは、これらの戦略を怠ることが莫大な結果をもたらす可能性があるという点に突き当たったことです。

お金を節約するためにとられた近道がお金と評判の両方の点で莫大な費用を費やしてしまったので、この特定のケースは特に明白でした。ソフトウェアが最初にAriane 4用に開発されたときと同じようにAriane 5のシミュレーション環境で堅牢にテストされていた場合、ソフトウェアが起動ハードウェアにインストールされてコマンドが実行されるずっと前にエラーが明らかになっていました。実際のフライト。さらに、ソフトウェア開発者が意図的にソフトウェアに意味のない入力を投入した場合、エラーはAriane 4時代にさえ捕らえられていた可能性があります。それは、適切なエラー回復が不十分であったという事実を浮き彫りにするためです。

要するに、それは実際には新しい教訓を教えることはできなかったが、それは古いものを覚えていないという危険に突き当たった。また、ソフトウェアシステムが動作する環境は、ソフトウェア自体と同じくらい重要であることも示しています。ソフトウェアが環境Xで検証可能に正しいからといって、Xが同様の明確な環境Yで目的に適合していることを意味するわけではありません。最後に、ミッションクリティカルなソフトウェアが、起こりました。

フライト501とアポロ11のコントラストおよびそのコンピューターの問題。LGCソフトウェアは、着陸時に深刻な不具合が発生しましたが、非常に堅牢であるように設計されており、ソフトウェアアラームがトリガーされても、宇宙飛行士を危険にさらすことなく、運用状態を維持できました。その使命を完了します。

それはほとんど再利用の問題と管理の問題であり、コーディングの問題ではありませんでした。レポートの思い出（私はおそらくいくつかのことを間違っている）。

• 1つのサブシステムは、Ariane IV用に設計されました。Ariane IVの軌道はオーバーフローを引き起こすことができず、発生した場合はハードウェアの問題であり、サブシステムをシャットダウンしてスペアに移動することが正しいことであると意図的に決定されました。

• Ariane Vの場合、そのサブシステムを再利用し、仮定とコードを確認するのではなく、テストに依存することが決定されました。

• さらに、完全なテストを中止することが決定されました。

アリアンVのさまざまな飛行パラメータにより、オーバーフローが発生しました。プライマリをシャットダウンします。スペアをシャットダウンします。自動破壊。

私が覚えている追加の事柄：

• オーバーフロー時のサブシステムはもはや役に立ちませんでした。その失敗は自動破壊を引き起こすべきではなかったと主張することができます。（一方で、追加された複雑さ自体が問題の原因になる可能性があります）。

• バスに送信すべきでないときにデバッグデータが送信されました。具体的なことは覚えていません。

他の人が述べたように、それによって業界は一般に再利用の概念を再検討し、それをより大きな基準の枠内に置き、それによってコンポーネントは個別にではなくシステム全体のコンテキストで評価されます。これにより、コンポーネントを変更せずに再利用できる場合でも、新しい前提条件で分析する必要があるため、再利用の魅力が大幅に低下します。もう1つの当然の結果として、ほとんどの最新のハードウェアは最新のソフトウェアよりも桁違いに信頼性が高いため、同じソフトウェアを実行するバックアップハードウェアはそれほど魅力的ではありません。一部の防衛契約では、適切な実装を検証するために、同じ仕様で動作する異なるテクノロジーを使用して異なるチームによって開発された2つの個別のソフトウェアシステムが必要であると聞いています。