たった1行のコードが10億ドルのロケットを墜落させた

今日ソフトウェアについて語るとき、その重要性はさまざまな技術のスペクトルの末端にあることを認識すべきです。たとえば、航空宇宙の世界では、その重要性は信じられないほど高く、 ソフトウェアの不具合は悲惨な結果につながる可能性がある。

この号では、エラーが許されないこのような重大な環境において、ソフトウェア障害が重大な影響を及ぼした注目すべき事例をいくつか取り上げます。

それでは、詳しく見ていきましょう。

1996年6月4日、欧州宇宙機関（ESA）は アリアン5ロケット これは宇宙探査の歴史において重要な瞬間を刻む初めての出来事でした。しかし、このミッションは困難なものでした。たった 1 行のコードが原因で壊滅的な障害が発生し、およそ 5 億ユーロ相当の積荷がすべて失われたのです。

2つの通信衛星はアリアン5号によって静止トランスファー軌道に運ばれる予定だった。打ち上げは順調に進み、 ロケットは軌道から外れ、飛行開始から37秒後に爆発した。ロケットの進路を制御する誘導システムのソフトウェアの欠陥が事故の原因であることが判明した。アリアン5号の打ち上げは、 史上最も高額なソフトウェア障害科学衛星の破壊により、地球の磁気圏の働きに関する科学的研究はほぼ4年間遅れました。

何だった 原因? ほぼ10年前に始まった最後のアリアン4ミッションのコードの一部に、単純で修正可能なプログラミングエラーが含まれていました。ロケットは水平バイアスと呼ばれる方法を使用していました。 BH値、上を向いているか下を向いているかを識別するために、64 ビットの浮動小数点変数を使用して表されました。誘導システムはこれを 16 個の 16 ビット符号付き整数に変換するために使用しました。64 ビット変数は数十億の値を表せますが、16 ビットは 65,535 個の値しか表せません。

整数は符号を格納する最初のビットで表され、16ビット整数は-32,768から32,767の範囲になります。しかし、浮動小数点数は-1.8e+308から-2.2e-308までの同じビット数を使用して、より広い範囲の数値を追跡するように作られています。16ビット整数に格納しようとすると、 符号付き整数の範囲外それで、何が起こったかはよく知られている 整数オーバーフロー。

災害のもう一つの要因は ユーザー要件 アリアン5号は以前のものよりもはるかに急な軌道を採用し、驚異的な垂直速度を実現しています。

この災害から得られた教訓は何でしょうか?

• 理解せずにコピー＆ペーストしたコード（カーゴカルト）は重大な問題です。

• もう一つは、適切な 例外処理。

• 変化したユーザー要件を無視する そして

• 適切なテストの欠如。

公式推奨事項 理事会によって だった：

✅ R1 – 必要のないプログラムやシステムの使用を避ける飛行中は、必要な場合を除きソフトウェアは動作しません。

✅ R2、R10、R11 – テストは必須ですできるだけ多くの実際の機器を備えたテスト施設を確立し、本物の入力データを追加し、徹底した閉ループ システム テストを実施します。すべてのミッションは、完全に実現されたシミュレーションに先行する必要があり、高いテスト範囲が必要です。

✅ R4 – コードレビューを行うすべてのコード詳細は、どのプログラミング言語でも重要です。

✅ R6、R8、R13 – タスク内の例外を処理し、問題が発生したときにスムーズな操作を保証するバックアップ システムを作成することで信頼性を向上します。重要なコンポーネントを定義する際には、ソフトウェアにも障害が発生する可能性があることを認識し、ソフトウェアの障害を考慮することが重要です。厳格なソフトウェアテストルールを作成するチームを設立し、高品質の基準を確保します。

参考文献:

最近報告された事件では、 ロイター連邦航空局（FAA）は、調査の結果、契約社員が「不正行為」を行っていたことが判明したと説明した。 1月11日に全国的に地上停止が発生し、11,000便以上の飛行が中断された。その人はプライマリ データベースとバックアップ データベース間の同期に取り組んでいたそうです。

これは、「それをリリースする” という Michael Nygard 著の本を参考にしました。航空会社は、サービス指向アーキテクチャに従ったコア システムを提供するデータベース クラスターのフェイルオーバーを計画しました。段階的なロールアウトは機能別に計画され、推進されました。そのシステムは、さまざまな入力 (日付、時刻、都市) に対するフライトの詳細リストを返す検索を処理しました。

航空会社は、冗長化されたハードウェアロードバランサーを備えた冗長化されたOracleデータベースを備えたJ2EEアプリケーションサーバーのクラスター上で動作していました。 非常に一般的な高可用性アーキテクチャある日、エンジニアがデータベース 1 からデータベース 2 (バックアップ 1) への手動データベース フェイルオーバーを実行しました。エンジニアはこれを何度も実行しており、すべてが計画どおりに進みました。その後、2 時間後、システムはキオスクに表示されるリクエストの処理を停止しました。エンジニアは分析を行った後、アプリケーションを再起動することにしました。これが功を奏し、約 3 時間にわたって航空機の運航が停止しました。

ログファイルの事後分析後、スレッドダンプ、構成ファイルを調べて、エラーが報告されたシステムではなく、コアシステムに問題があることを突き止めました。多くのスレッドがブロックされ、決して発生しない応答を待っていました（都市による検索を行ったメソッド）。最終ブロックで実行されたSQL終了ステートメントもエラーをスローする可能性があることを発見しました。 SQL例外 ドライバーが DB にリソースを解放するように指示しようとしたが、それが処理されず、リソース プールが枯渇しました。

このような状況で、彼らは何をもっと改善できるでしょうか？すべてのエラーを防ぐことは不可能であり、いくつかのバグは発生します。私たちにできることは あるシステムのバグが他のシステムに影響を及ぼさないようにする。

2018年10月と2019年3月に、 ボーイング737MAX機2機が5ヶ月以内に墜落し、346人が死亡した。この問題は、飛行の安全性を高めるために設計されたソフトウェア システムに一部起因しています。

MCAS – 操縦特性向上システム（ソフトウェア） — ボーイング737 MAX危機の核心です。必要性から生まれたこのソフトウェアは、ボーイングの根本的な設計上の課題（ハードウェアの問題に対するソフトウェアの修正）に対する解決策でした。 [1]737 MAXは、より大型で燃費効率に優れたエンジンを搭載し、以前の機種とは異なる空力特性を持っていました。MCASは、MAXを以前の737モデルと同じように操縦できるようにし、パイロットにとってシームレスな移行を保証することを目的としていました。

理論上、MCASは素晴らしいものでした。水平安定板を自動的に調整して、急旋回時や低速時に航空機が失速するのを防ぐのです。しかし実際には、 これは、単一障害点がどのようにして災害に連鎖するかを示す教科書的な例となった。。

重大な欠陥？ MCASは、飛行機の2つの迎え角（AOA）センサーのうち1つからの入力のみに依存していた。 [1][2]もしそのセンサー 1 つが誤ったデータを提供すると、MCAS が不必要に作動し、機首を下げるべきでないときにも機首を下げることになります。さらに問題なのは、システムが繰り返し再起動するため、システムの存在や動作について十分な情報を得ていないパイロットが圧倒される可能性があることです。

しかし、MCASの物語は、墜落事故の後に明らかになった事実に触れずには完結しない。ボーイングは737MAXのソフトウェア開発の大部分を、時給わずか9ドルのエンジニアに外注していたと報じられた。 [4]ボーイング社の元ソフトウェアエンジニアによると、同社は海外のソフトウェア開発センターで雇用された臨時労働者、特に大学を卒業したばかりの労働者にますます依存するようになった。この決定は、おそらく コスト削減と開発スピードアップの圧力により、737 MAXの物語に新たな複雑さが加わった。。

ソフトウェアエンジニアとしてこの話から学べること:

1. 単一障害点を排除するMCAS の事件は、重要なシステムにおいて冗長性がなぜ重要かということをはっきりと思い出させてくれます。単一のデータ ソース (この場合は 1 つの AOA センサー) に依存していたため、脆弱性が生じ、壊滅的な結果をもたらしました。私たちの仕事では、常に「このコンポーネントに障害が発生したらどうなるか」を自問する必要があります。

2. ソフトウェアとシステムをシンプルに保ちつつ、シンプルになりすぎないようにする (KISS)MCAS システムは、ハードウェアの問題に対する解決策を過剰に設計した典型的な例です。ボーイングは、737 MAX の設計の根本的な不安定性に対処するのではなく、新しい脆弱性をもたらすソフトウェアの「修正」を選択しました。

3. ドメイン専門知識の欠如アウトソーシング会社から雇用されたエンジニアの多くは、航空宇宙工学や安全性が重要なシステムに関する深い経験を持っていません。そのため、コミュニケーションの問題やミスが発生し、何度も修正が必要になりました。

4. 不適切なテスト方法徹底的なテストにもかかわらず、MCAS の致命的な欠陥は航空機の就航前に発見されませんでした。これは、特に現実世界の状況を完全に再現することが難しいシステムの場合、現在のテストとシミュレーションの実践が適切であるかどうかという重要な疑問を提起します。

これらの問題を改善するために、ソフトウェア エンジニアとして日々何ができるでしょうか? いくつか例を挙げます。

✅ 適切なエラー処理を実装するコンポーネントが故障することを前提にシステムを設計します。冗長性、クロスチェック、およびフェイルセーフ メカニズムを実装します。

✅ ユーザーに焦点を当てるシステムがユーザーと明確にコミュニケーションをとれるようにします。特に現在の状態と自動化されたアクションについてです。十分な情報に基づいた決定を下すために必要な情報とコントロールをユーザーに提供し、必要に応じて自動化されたシステムを上書きします。

✅ 統合テストを優先するユニット テストは重要ですが、それだけでは十分ではありません。包括的なシステム全体の統合テストに時間とリソースを投資してください。エッジ ケースと障害モードをテストします。

✅ オープンなコミュニケーションの文化を育みます。 懸念を恐れることなく表明でき、ニアミスが隠蔽されるべき恥ずかしい出来事ではなく、貴重な学習機会として捉えられるような環境を作りましょう。

✅ 適切なリソース割り当てを推進します。 ソフトウェアエンジニアとして、私たちは仕事を適切に行うためのリソースを主張します。これには、非現実的な期限、不十分なテスト時間、安全性を損なう可能性のあるコスト削減策への反対が含まれます。 [5]。

参考文献:

[1] 「ボーイング737 Maxの事故はソフトウェア開発者にとってどう映るだろうか」、グレゴリー・トラヴィス、IEEE Spectrum、2019年。

[2] 「キラーソフトウェア：致命的な737 MAX墜落事故から学ぶ4つの教訓」、マット・ハンブレン。

[3] 「専門家によると、ボーイング737MAXの墜落事故では8行のコードで346人の命が救われた可能性があるマット・ハンブレン

[4] 「ボーイングの737 Maxソフトウェアは時給9ドルのエンジニアにアウトソーシングされる「ブルームバーグ、2019年。」

[5] 「ボーイング737 MAX：エンジニア倫理への教訓」、ハーケット J. 他、 科学工学倫理。 2020年。

また、チェックしてください NASA のコーディング改善のためのトップ 10 ルール。

1. 33,000人以上の購読者に自分を宣伝しましょう このニュースレターをスポンサーすることで、あなたは、技術上の決定や購入に影響を与える多くのエンジニアリング リーダーや上級エンジニアを前にすることができます。

2. 1:1コーチング: 私とのセッションを予約する個人および組織/チームの成長に関するトピックについて、1:1 のコーチングをご利用いただけます。私はあなたが優れたリーダーになるお手伝いをします 🚀。