より良いテスト:BoeingStarlinerのクラッシュ報告は終了しました

NASAとボーイングは12月にボーイングスターライナーの飛行の分析を完了しました。新しい宇宙船の最初の無人テスト打ち上げでは、飛行プログラムは部分的にしか完了せず、ISSとのドッキングが失敗し、ミッション期間を2日間に短縮する必要があり、宇宙船はほぼ完全に2回失われたことを思い出してください。レポートは完全には公開されていませんが、80の推奨事項が、厳密で品質の高いテストの重要性を再び強調していることが知られています。





ボーイングスターライナーの飛行後サービス、写真NASA /ビルインガルス



ほぼ2回失われました



NASAの用語では、ミッションは「幅広いメディア報道でほとんど失われた」(「視認性の高いクローズコール」)と宣言されました。次の用語は船の喪失であり、おそらく人命の喪失です。この状況は非常にまれであり、2013年に宇宙飛行士のルカ・パルミターノが水冷システムのフィルターの目詰まりのために宇宙遊泳中に宇宙服で溺死しそうになった状況が最後に指定されました。



最初のバグは、開始から31分後に現れました。宇宙船は、元の軌道からISSへの飛行経路に切り替えるための予想される操作を実行しませんでした。 MCCは状況を是正しようとしましたが、悪として、これらの試みは通信の問題と重なっており、その結果、スターライナーはISSとのランデブーや空の燃料タンクとのランデブーには不適切な軌道上にありました。コードのエラーにより、宇宙船は、カウントダウンの開始時ではなく、発射の11時間前に、飛行時間タイマーを発射車両と同期させました。その結果、搭載されたコンピューターは、船が実際とは異なる飛行段階にあると信じていました。





ボーイングビデオからのフレームであるスタライナーのコンパートメントの分離



2番目のバグはそれ自体を証明する時間がありませんでした。最初の問題のために、NASAとBoeingの専門家は、コードを分析して、他に何か見落としがないかどうかを確認し始めました。そして、結局のところ、無駄ではありませんでした。着陸中、ブレーキ操作を実行した後、宇宙船は降下車両とサービスモジュールに分割する必要がありました(上の図に示すように、ほとんどすべての宇宙船は同様の手順を実行します。たとえば、ソユズは3つのコンパートメントに分割され、クルードラロンは前にサービスモジュールをドロップします制動)。分離後、サービスモジュールは船から離れるために操作を実行する必要がありましたが、コードのエラーのために、手順がプロセスを制御するコントローラーに誤って送信されました。その結果、サービスモジュールが降下車両にぶつかってトラブルを引き起こす可能性があります。



3番目の問題はそれほど重大ではありませんでしたが、私は地上職員の血をたくさん飲みました。ミッション中、船は地上との通信に問題があり、MCCからの制御が困難であり、有人飛行の場合、宇宙飛行士との交渉が困難になりました。



MCCの介入がなければ、それぞれが船の損失につながる2つの重大な問題が、設計および開発段階で発生し、テスト段階で多数のチェックを通過することができました。両方の問題はテストを通じて検出可能であり、ボーイングのプロセスはそれらを発見して修正することができたはずでした。



何をすべきか?



完全なレポートには専有情報と企業秘密情報が含まれているため、NASAは一般的な概要のみ公開していますが、それでも非常に興味深いものです。



21の推奨事項は、テストに直接関連しています。まず、ハードウェアレベルとソフトウェアレベルの両方で統合テストを改善する必要があります。私自身、統合テストの段階で検出されなかったエラーが、宇宙事故の原因の大部分を占めていることに気づきました。さらに、各フライトの前に、フライト機器を最大限に関与させて「ドレスリハーサル」を実施し、その動作と制限を分析し、シミュレーションで検出されたギャップに対してアクションを実行する必要があります。



10の推奨事項は要件に起因していましたが、実際にはテストにも関連しています。複数の条件を含む要件をより適切に分析し、意思決定の範囲を拡大する必要があります。つまり、コード内の条件のテスト範囲です。 100%の意思決定カバレッジは100%のステートメントカバレッジを意味しますが、その逆ではないことを思い出してください。



35の推奨事項はプロセスを改善するはずです。そして、改善が提案されていることに応じて、発見された問題を再構築することが可能です。コードレビューとテストデータを強化することで、コードの記述プロセス(コードレビュー用)またはテストプロセス(テストデータが明らかに不十分)のいずれでもコードのエラーに気付かなかったという事実の問題を修正する必要があります。安全性が重要な分野への専門家のより大きな関与は、能力のギャップをなくすはずです。また、意思決定委員会の文書の変更に関する提案は、開発とテストの欠陥に気づかなかった場合、または排除するには優先度が低すぎる場合の状況を修正する必要があります。



7つの推奨事項は、飛行時間とサービスモジュールを分離する手順を考慮してバグを修正し、アンテナ選択アルゴリズムの信頼性を高めるコード修正です。



そして最後の7つの推奨事項は、組織構造とハードウェアに関連しています。安全メッセージの組織構造に変更が加えられるのを待っています(明らかに、「ここに重要な問題があります」というメッセージをより適切に渡すために)、外部監査を改善する必要があり、帯域外干渉から保護するために追加のフィルターが船の設計に導入されます。



親愛なるレッスン



緊急飛行の話には楽しいことは何もないという事実にもかかわらず、それは宇宙技術と飛行の安全性を生み出すプロセスを改善するのに役立ちます。もちろん、フライトのずっと前のテスト中に発見された可能性があり、発見されるべきだったプロダクションバグを見逃すことは非常に厄介です。さて、最初のテストフライトでは、気付かれない問題を検出するのではなく、行われた決定の正確さを確認する必要があります。テスト飛行は非常に有益でしたが、非常に高価でもありました。ボーイングは、船が安全で飛行可能であることを確認するために、自費で別のテスト打ち上げを実施する必要があります。正確な日付はまだ不明ですが、2020年11月が予定されています。



All Articles