Ariane 5のFlight 501の歴史的な影響は何でしたか？
アリアン5ロケットの崩壊、彼女の処女航海での発射37秒後（ Flight 501 ）は、一般的に 最も高価なソフトウェアバグの1つと呼ばれています歴史の中で1：
欧州宇宙機関が10年間と70億ドルを費やして、打ち上げごとに3トンの衛星のペアを軌道に打ち込むことができる巨大なロケットであるアリアン5を生産しました。
昨年6月にロケットがその初飛行に1分もかからず爆発し、フランス領ギアナのマングローブの沼地に燃える瓦礫を散布したのは、64ビットの数値を16ビットの空間に詰め込もうとする小さなコンピュータプログラムだけでした。
1つのバグ、1つのクラッシュ。コンピュータサイエンスの記録に記録されているすべての不注意なコード行の中で、これは最も壊滅的に効率のよいコードである可能性があります。ロケット工学の専門家へのインタビューと宇宙機関のために準備された分析から、算術エラーから完全な破壊への明確な道が現れます。
Flightの501故障とその後の調査は、安全上重要なシステムとソフトウェアテストの研究に影響を与えた主な変更は何ですか？
私はバグ自体の説明を探しているのではなく、失敗の調査に触発された、または直接関連した調査という点での、バグの歴史的な影響の説明を探しています。たとえば、この paper は次のように結論付けます。
静的分析を使用して、次のことを行いました。
- 変数の初期化を確認し、
- シェア変数の潜在的なデータアクセス競合の完全なリストを提供します。
- adaセマンティクスから潜在的な実行時エラーを徹底的にリストします。
私たちの知る限りでは、ブールベースおよび非ブールベースの静的分析手法を使用して産業用プログラムを検証するのはこれが初めてです。
同様に、 この論文（pdf） ノート：
Ariane 5ランチャーとARDの組み込みADAソフトウェアの静的分析には、抽象解釈ベースの静的プログラム分析が使用されています。静的プログラムアナライザーは、スカラーや浮動小数点のオーバーフロー、配列のインデックスエラー、ゼロによる除算や関連する算術例外、初期化されていない変数、データ競合などのランタイムエラーの有限性、可能性、不可能性またはアクセス不能性の自動検出を目的としていますアナライザーは、Ariane 501フライトエラーを自動的に検出できました。 組み込みの安全性クリティカルソフトウェア（航空電子工学ソフトウェアなど）の静的分析は非常に有望です。
この単一のイベントがソフトウェアテストのアプローチとツールに与えた影響を徹底的に説明したいと思います。
1 70億ドルという数字は、おそらくAriane 5プロジェクトの総コストを参照していると、ウィキペディアは、失敗により3億7000万ドル以上の損失が発生したと報告しています。それでもかなり高価な失敗ですが、70億ドルという数字にはほど遠いものです。
技術的には、 " software rot "の場合が多くなりました。飛行制御ソフトウェアは、初期の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つの個別のソフトウェアシステムが必要であると聞いています。