👨🏼‍🌾 🤫 🏭 スペースエラー：整数オーバーフローで$ 370,000,000 🔌 📈 🏅

起動します。
37秒間の飛行...ブロード！
10年と70億ドルが開発に費やされました。
1996年6月4日に、クラスター科学プログラム（太陽放射と地球の磁場との相互作用を研究する）の4つの1.5トンの衛星とアリアン5キャリアロケットが「お菓子」に変わりました。
そして、その責任はプログラマーのせいでした。

前のモデルであるアリアン4ロケットは、100回以上の打ち上げに成功しました。何が悪かったのですか？

天国を襲うには、地獄の言語をよく知る必要があります。

関係書類

Ariane 5（ "Arian-5"）は、Arianeファミリーの一部であるヨーロッパの使い捨て打ち上げロケットです（最初の打ち上げは1979年に行われました）。中型または重型の宇宙船を軌道に乗せるために使用され、2つまたは3つの衛星を同時に打ち上げ、同時に最大8つのマイクロサテライトを発射できます。

プロジェクトの歴史
1984年から1995年に作成されました。欧州宇宙機関（ESA; ESA）、主な開発者はフランス国立宇宙研究センター（CNES）です。プログラムの参加者はヨーロッパ10か国で、プロジェクトの費用は70億米ドルです（46.2％はフランスの貢献です）。

約1000の産業企業がロケットの作成に参加しました。主な請負業者は、欧州企業のエアバスディフェンスアンドスペース（エアバスディフェンスアンドスペース、エアバスグループ、エアバスグループ、パリ）です。 Ariane 5は、フランスの会社Arianespace（Arianspace; Evry）によって宇宙サービス市場で販売されており、ESAは1997年11月25日に契約を締結しました。

特徴
アリアン5は、2段式の大型打上げ機です。長さ-52-53 m、最大直径-5.4 m、開始重量-775-780トン（構成による）。

最初のステージには、Vulcain 2液体ロケットエンジン（Vulkan-2、最初の3つのロケットバージョンでVulcainが使用されました）、2番目はHM7B（Ariane 5 ECAバージョン用）またはAestus（Aestus; Ariane 5 ES用）が装備されています。 Vulcain 2とHM7Bは、フランスの会社Snecma（Snecma;パリのSafranのSafranグループの一部）によって製造された水素と酸素の混合物で動作します。

Aestusは、長寿命の燃料である四酸化窒素とモノメチルヒドラジンを使用しています。このエンジンは、ドイツのダイムラークライスラーエアロスペースAG（DASA、DASA、ミュンヘン）によって開発されました。

さらに、2つの固体燃料ブースター（メーカー-Europropulsion、Europhlzhn、Suren、フランス、Safranグループとイタリアの企業Avio、Avioの合弁会社）が第1ステージに取り付けられ、打ち上げの開始時に90％以上の推力を提供します。 Ariane 5 ESバリアントでは、ペイロードが低基準軌道に運ばれたときに第2ステージが存在しない場合があります。

オンボードコンピューター
www.ruag.com/space/products/digital-electronics-for-satellites-launchers/on-board-computers

調査

災害の翌日、欧州宇宙機関（ESA）の局長とフランス宇宙研究センター（CNES）の委員長は、この緊急事態の状況と原因を調査する独立委員会の設立を命じました。ヨーロッパ諸国。

1996年6月13日に委員会は作業を開始し、すでに7月19日に包括的なレポート（ PDF ）が発行され、すぐにWebで利用できるようになりました。

委員会は、飛行の光学観測を記録するだけでなく、テレメトリデータ、軌道データも持っていました。
爆発は約4 kmの高度で発生し、破片は約12平方メートルの面積に散らばっていました。 km サバンナと沼地で。多数の専門家の証言が聞かれ、生産と運用の文書が研究されました。

事故の技術的詳細

宇宙空間での打ち上げロケットの位置と向きは、慣性基準システム（IRS）によって測定されました。その不可欠な部分は、レーザージャイロスコープと加速度計を備えた搭載慣性プラットフォームからの情報に基づいて角度と速度を計算する統合コンピューターです。 IRSからのデータは、特別なバスを介してオンボードコンピューター（OBC）に送信され、飛行プログラムの実行に必要な情報と、油圧およびサーボドライブを介して制御された固体燃料加速器およびVulkainタイプの極低温エンジンを直接提供しました。

飛行制御システムの信頼性を確保するために、 機器の複製が使用されました 。そのため、同一のハードウェアとソフトウェアを備えた2つのIRSシステム（1つがアクティブ、もう1つがホットスタンバイ）が並行して機能しました。オンボードコンピューターOBCは、「アクティブな」IRSが通常モードから外れたことを検出するとすぐに、別のモードに切り替わります。オンボードコンピューターも2台ありました。

プロセス開発の重要な段階

予定されている打ち上げの7分前に、「可視性基準」の違反が記録されました。したがって、開始は1時間延期されました。

H0 = 9時間 33分 59秒現地時間では、「起動ウィンドウ」が再び「キャッチ」され、最終的に起動自体が実行されました。これは通常、H0 + 37秒の瞬間まで発生しました。

次の数秒で、ロケットが特定の軌道から急激に逸脱し、爆発に終わりました。

H0 + 39秒の時点で、空力負荷が高いため、「迎え角」が臨界値を20度超えているため、ロケット打ち上げ加速器はメインステージから分離され、ロケットの自動ブラストシステムを組み込むための基礎となりました。

迎え角の変化は、固体燃料ブースターのノズルの異常な回転が原因で発生しました。このような加速器のノズルがH0 + 37秒の瞬間に正しい方向からずれると、アクティブナビゲーションシステム（IRS 2）からの情報に基づいてオンボードコンピューターによってコマンドが発行されます。

この情報の一部は基本的に間違っていました。フライトデータとして解釈されたのは、実際にはIRS 2組み込みコンピューターからの診断情報でした。

IRS 2組み込みコンピューターは、ソフトウェアモジュールのいずれかによってスローされた例外をキャッチすることにより異常な状況を診断したため、誤ったデータを送信しました。

同時に、オンボードコンピューターは、IRS 2と同じ理由で、以前のサイクル（72ミリ秒かかりました）で既に機能を停止していたため、バックアップIRS 1システムに切り替えることができませんでした。

IRSプログラムの1つによってスローされた例外は、データを64ビット浮動小数点形式から16ビット符号付き整数に変換した結果であり、オペランドエラーが発生しました。

慣性プラットフォームの「調整」を実行するためだけに設計されたソフトウェアコンポーネントでエラーが発生しました。さらに、このソフトウェアモジュールは、H0 +ロケットが発射台から7秒離れた瞬間までのみ、重要な結果を生成します。ロケットが離陸した後、このモジュールの機能は飛行に影響を与えることはできませんでした。

「調整機能」は、（設定された要件に従って）ナビゲーションシステムのバスで「フライトモード」を開始してからさらに50秒間（H0-3秒）動作する必要がありました。

プラットフォームに配置されたセンサーによって測定された「水平速度」に基づいて内部関数によって計算された、予期せずに大きいBH（水平バイアス-水平勾配）により、「オペランドエラー」エラーが発生しました。

BHの値は、プラットフォームの位置決めの精度の指標として機能しました。初期のアリアン5飛行経路は、このプログラムモジュールが以前に使用されていたアリアン4飛行経路とは大幅に異なっていたため、BH値が予想よりはるかに高くなり、「水平速度」が大幅に向上しました。

致命的な結果をもたらした最後のアクションは、プロセッサの停止でした。したがって、ナビゲーションシステム全体が機能しなくなりました。彼女の行動を再開することは技術的に不可能でした。

この一連のイベントはコンピューターシミュレーションを使用して完全に再現され、他の研究や実験の資料と合わせて、災害の原因と状況が完全に特定されたと結論付けることができました。

事故の原因と起源

ロケットを離陸した後、調整作業を継続するための最初の要件は、アリアンシリーズの初期のモデルが設計されていた運命的なイベントの10年以上前に設定されました。
いくつかのありそうもないイベントでは、離陸は開始のほんの数秒前にキャンセルできます。たとえば、IRSで「フライトモード」が起動されたときのH0-9秒と、ロケット機器でいくつかの操作を実行するコマンドが発行されたときのH0-5秒です。

離陸が予期せずキャンセルされた場合は、すぐに「カウントダウン」モードに戻る必要がありました-同時に、慣性プラットフォームを初期位置に戻すことを含む、すべての設置操作を最初に繰り返さないことが必要でした「起動ウィンドウ」を失う可能性があります。

打ち上げキャンセルイベントが発生した場合、H0-9後50秒で十分であり、地上機器が情報を失うことなく慣性プラットフォームのフルコントロールを取り戻すことができると正当化されました-この間、プラットフォームは開始された動きを停止し、対応するソフトウェアモジュールはその状態に関する情報が記録されます。これは、ロケットを元の位置にすばやく戻すのに役立ちます（これは、ロケットが引き続き打ち上げ場所にある場合です）。かつて、1989年に、アリアン4ロケットの33番から開始したときに、この機能が正常に使用されました。

ただし、Ariane 5は、以前のモデルとは異なり、プリフライトアクションを実行するための根本的に異なる規律をすでに持っていたため、開始時刻以降のロックソフトウェアモジュールの動作がまったく意味をなさないように異なっていました。ただし、モジュールは変更なしで再利用されました。

ADA言語

調査の結果、このプログラムモジュールには、型変換操作に関係する7つの変数が含まれていることがわかりました。開発者は、脆弱性の例外を潜在的にスローする可能性があるすべての操作を分析したことが判明しました。

4つの変数に適切な保護を追加し、BHを含む3つを保護しないままにすることは、彼らの非常に意識的な決定でした。この決定の基礎はこれらの3つの変数のために原則としてオーバーフロー状況の発生が不可能であるという信念でした。

この信頼性は、前述の変数の値が決定される物理飛行パラメーターの予想範囲が、望ましくない状況に至らないようなものであることを示す計算によって強化されました。そして、それは本当でした-しかし、アリアン4モデルのために計算された軌道について。

そして、新世代のアリアン5ロケットは、まったく異なる軌道で打ち上げられましたが、推定は行われませんでした。一方、（初期加速度が高いと）「水平速度」が計算値（アリアン4の場合）を5回以上超えました。

IRSコンピューターに対して最大80％のワークロードが宣言されたため、7つすべて（BHを含む）変数の保護は提供されませんでした。開発者は、不必要な計算コストを削減する方法を探す必要があり、理論的に望ましくない状況が発生しなかった場合の保護を弱めました。それが発生すると、そのような例外処理メカニズムが有効になり、完全に不適切であることが判明しました。

このメカニズムには、次の3つの主要なアクションが含まれていました。

緊急事態の発生に関する情報は、バスを介してオンボードコンピューターOBCに送信する必要があります。
並行して、コンテキスト全体とともに、EEPROMの再プログラム可能なメモリに書き込まれました（調査中に、その内容を回復して読み取ることができました）。
IRSプロセッサがクラッシュするはずです。

最後のアクションは致命的であることが判明しました-（保護されていないオーバーフローのためにソフトウェア例外が生成されたにもかかわらず）実際に正常な状況で発生し、災害につながりました。

結論

Ariane 5の欠陥は、1つの原因が原因ではありません。開発およびテストプロセス全体を通じて、この欠陥を特定できる多くの段階がありました。

ソフトウェアモジュールは、動作条件がソフトウェアモジュールの要件とは異なる新しい環境で再利用されました。これらの要件は改訂されていません。
システムはエラーを検出して認識しました。残念ながら、エラー処理メカニズムの仕様は一貫性がなく、最終的な破壊を引き起こしました。
エラーが発生したモジュールは、ハードウェアレベルでもシステム統合レベルでも、新しい環境では適切にテストされていません。その結果、開発と実装の誤りは検出されませんでした。

コミッションレポートから：

Ariane 5の開発の主な目的は、偶発的な事故を減らすことです。発生した例外は、事故によるものではなく、設計エラーによるものです。例外が検出されましたが、プログラムは正しいと見なされるべきであることが反対のものが示されるまで受け入れられるため、誤って処理されました。委員会は、現在認められているベストプラクティスの使用がその正当性を実証するまで、ソフトウェアは誤りであると見なされるべきであるという反対の見解を持っています。

ハッピーエンド

失敗にもかかわらず、さらに4つのクラスターII衛星が建設され、2000年にソユーズ / フリゲートロケットの軌道に投入されました。

起動時の事故は、複雑なコンピューティングシステムの使用に関連する高いリスクに公衆、政治家、および組織の責任者の注意を引き、特別なセキュリティ要件を備えたシステムの信頼性の向上を目的とした研究への投資の増加に貢献しました。その後のArianeコードの自動分析（Adaで記述）は、抽象解釈手法を使用して大規模プロジェクトで静的分析を適用した最初のケースでした。

スペースエラー：整数オーバーフローで$ 370,000,000