月ミッション "Bereshit"-事故の予備的原因が発表されました

Bereshit装置が月面に落下した6日後、SpaceILチームは2019年4月11日に月面事故の興味深いバージョンを公式に発表しました。 そして、何が起こったのかについてさらに質問があります。

2019年4月18日に事故に関する情報を更新しました。

この出版の続きで。



BereshitデバイスからのSpaceILからの最新の公式写真（月面まで15 km）：







この写真の場所の参照は次のとおりです。







事故調査の予備結果： 着陸の過程で、コマンドがコンピューター上で有効になり、その実行がミッションの致命的な結果につながった







Beresheetの着陸作戦の予備調査の結果は次のとおりです。着陸プロセス中にコマンドが入力され、連鎖反応が発生したため、メインエンジンがオフになり、再起動が妨げられたようです。



「 着陸プロセス中にコマンドが導入されたようです。これにより、デバイスのメインエンジンが停止し、それ以上の作業を再開できなかった連鎖反応が発生しました。」

2019年4月18日からの更新：

それでも、着陸中にオペレーターから受け取ったコマンドによる事故は神経であり、状況を分析する時間はありません、メインユニットIMU1（慣性測定ユニット）は異常モードにあり、オペレーターはスペアIMU2ユニットを作動させるコマンドを送信します。オンボードコンピューター（フリーズ、再起動）およびエンジン障害。



「スペースシートが実施した予備調査によると、ベレシート宇宙船の慣性測定ユニットの1つでの誤動作を修正するコマンドにより、着陸中にメインエンジンが停止する一連のイベントが発生しました。」

したがって、これはBereshit装置の着陸手順におけるプログラム/ヒューマンエラー（MCCのオペレーターまたはエンジニアによってコマンドが入力された）であった可能性があります。



Bereshitデバイスのコマンドと動作モードのリストは承認され、SpaceIL MCCからのみ送信されました。 SpaceILのエンジニアは、デバイスのオンボードコンピューター用のパッチを作成し、操作性と機能を確認し、着陸手順のコマンドを準備しました。



理論的には、デバイスの制御を奪い、追加のコード/コマンドをオンボードコンピューターに導入することは興味深いことです。



実際、着陸時間が数秒経つと、オペレーターがデバイスを外国のチームに受け入れさせる状況を逃す可能性があります。 ただし、現時点では、オペレーターは手動モードでも負傷し、デバイスを操作しようとしました。 ここでも、入力されたコマンドに同時に矛盾があったのかもしれません。



しかし、おそらく「致命的な」コードにエラーがあり（再起動のたびにオンボードコンピューターに送信された多くのパッチの1つにあった）、致命的なコマンドが含まれていました。







このコマンドは意図的または偶然に導入されたため、事故につながりました。この事実は、近い将来、SpaceILからの最終結果を待っていますが、公開することを約束しています。



Bereshitデバイスのハードウェアおよびソフトウェアコンポーネントについて知られていること：



-オンボードコンピューターは1つであり、複製されていません（月への飛行中にコンピューターが複数回再起動しました）。



-プログラムコード、コマンドを制御し、オンボードコンピューターで動作する-C言語。



-コンピューターが1台しかないため、再起動時にすべての更新プログラム（パッチ）が消去され、システムに再度ダウンロードする必要があります。



-データ転送速度が遅い：1つの高解像度写真（8 Mpxカメラから）が40分読み込まれます。



-DLR（ドイツ航空宇宙センター）は、Bereshitビークルの着陸メカニズムをテストしました。



-SpaceIL MCCのチーム：大半は宇宙エンジニアと物理学者、衛星制御システムを研究している若い科学者とエンジニアです。



この致命的なコマンドを含むコードはいつ実装できますか？ おそらく、着陸手順の準備をするとき。



しかし、搭載コンピューターでのみ制御される自動着陸プロセスが開始されたときに、搭載コンピューターのコマンドは、装置が「戻りのないポイント」を通過した後に機能しました。



SpaceIL MCCは、着陸中のデバイスの状況に影響を与えるための手動制御モードの試みでしたが。



着陸地点から800 kmの距離で、植え付け手順が開始されます。







Bereshitデバイスは、MCCから一連のコマンドを受け取ります。







着陸センサー（プライマリおよびバックアップ）がアクティブになります。







Bereshitデバイスの位置（向き）を変更する手順が開始されます。







搭乗前の準備手順の完了後、Bereshit搭載コンピューターとMCCはシステムの状態と搭乗の準備状況を評価する機会があります。何かが正常に機能しない場合、すべてが正常であれば搭乗プロセスはキャンセルされ、次の段階の後着陸はキャンセルされなくなります：







すべてが正常に動作している場合、Bereshit装置は軌道速度を低下させ始め、メインおよび補助エンジンを使用して月面までの距離を短縮します。この手順には15分かかります。







着陸ビデオ：







着陸ビデオによると、デバイスで何が起こったのか（ビデオから時間を示します）：



23:03テレメトリーインジケーターが緑色になりました。 モード：方向。

25:04モード：ブレーキング。

25:20「戻りのないポイント」を通過。

25:26戻りのないポイントのインジケータが黒になりました。

25:52垂直速度インジケーターは緑色です。

28:16テレメトリーインジケーターが緑色でなくなった。

28:20テレメトリインジケータがしばらく緑色になり、その後緑色でなくなった。

29.37距離：210 km。

29:50距離が385 kmに変わります。

30:03距離が370 kmに変わります。

30:40テレメトリーインジケーターが緑色になりました。

30:51距離が314 kmに変わります。

31:33月に写っている自分撮り写真。 高度は約22 kmですか？ テレメトリーインジケーターが緑色になりました。

31:50テレメトリーインジケーターが緑色でなくなった。

31:55〜32:29「[聞こえない]彼を殺す（プロセス？）」 「[聞こえない場合でも]忙しい」

（ここでは、エンジニアはすでに緊急事態に対処しようとして手動制御されています）

32:48テレメトリー画面が表示されます。 遠隔測定インジケータは黄色です。 高さ14095 m。水平速度955.5 m / s。 垂直速度24.8 m / s メインエンジンがオンになっています。 水平速度セルは黄色です。 その他のパラメーターは、テレメトリーインジケーターを除き、緑色で表示されます。

32:49すべてのエンジンがオンになっています。

32:51すべてのエンジンがオフです。

32:55メインエンジンがオンです。

32:57すべてのエンジンがオンになっています。

32:59メインエンジンがオンになっています。 距離：183.8 km

33:01-33:03「IMUセンサーが故障しています」

33:02すべてのエンジンがオンになっています。

33:05メインエンジンがオンになっています。

33:07すべてのエンジンがオンになっています。

33:09メインエンジンがオンになっています。

33:11すべてのエンジンがオンになっています。

33:13メインエンジンがオンになっています。

33:16すべてのエンジンがオンになっています。

33:20テレメトリーインジケーターが緑色になりました。 すべてのエンジンがオフになっています。 すべての画像がフリーズしました（測定値に変化はありません）。

33:32テレメトリーインジケーターが緑色でなくなりました。 すべてのエンジンがオフになっています。 すべての画像がフリーズしました（測定値に変化はありません）。

34:24テレメトリーインジケーターが緑色になりました。 すべてのエンジンがオフになっています。

36:25-36:33「メインエンジンの問題。 オンボードコンピューターを再起動してエンジンをオンにします。」



着陸プロセス中にアナウンサーとエンジニアの言葉を書き起こそうとする試み（タイミングは異なりますが、本質と秒は同じです）：



7:37:37-IMU2は正常ではない

7:37:50-[不明]は有効にしようとします。

7:37:57-「「それ」が何であるかわからない」ことで、2番目の[何か]

7:38:10-JPLからの接続が失われました

7:38:34-1つのIMUが失われ、JPLへの接続が失われました。2つは関連してはなりません。

[バックグラウンドで、誰かがIMUの再起動について何か言います]

7:38:39-IMU2を有効にしないでください

7:38:52-画面に表示される内容が正しくありません。現在、テレメトリはありません

7:39:06-[英語]テレメトリを失いましたが、テレメトリが戻ってきました。

7:39:23-標高10kmを通過しました

7:39:29-900 m / s未満の速度

7:39:34-速度0に到達する必要があることを思い出させる

7:39:47-エンジンの運転中、圧力が[不明]から5 bar [？]に増加し、「興味深い」

7:39:52-2番目の画像がダウンロードされました。

7:40:06-[アナウンサーがレーザー着陸センサーについて何か言い始めています]。 [背景-不明だが、彼はエンジンが動いていないと言ったようだ]

7:40:13-メインエンジンに問題がある可能性があります。

7:40:17-リセットを行います[彼らは放送の前に、着陸プロセス中に宇宙船にコマンドを送信できると述べていました]

7:40:24-何が欲しい？

7:40:28-状況は良くないようで、メインエンジンもありません。

7:40:33-2番目の画像を受信しました。

7:40:40-高度の低下

7:41:07-[英語]メインエンジンに問題があるようです。エンジンを有効にしようと宇宙船をリセットしています

7:41:10-[不明]を送信する承認はありますか？

7:41:15-[圧力測定]に基づいて、メインエンジンが現在実行中です

7:41:19-メインエンジンが再びオンになりました。 [そして再び英語で]

7:41:27-多くの高度を失い、状況は不明。

7:41:32-JPLとの接続が失われました

7:41:45-現在、nasaではなくssc [??]を介してのみ接続していますが、宇宙船とは接続しています。

7:41:49-テレメトリの喪失

7:41:52-テレメトリーなし

7:41:57-[英語]メインエンジンはオンですが、通信が失われました

7:42:10-[不明瞭]から[評価]を待つ

7:42:17-まだ評価していない[不明]

7:42:56-私たちはテレメトリがなく、宇宙船を失った疑いがあります。

7:43:16-すべての兆候は、残念ながら私たちは月に着陸する4番目の国ではないということです。

7:43:33-私たちは月にいますが、私たちが望んでいた通りではありません。



MCCのデータによると、デバイスの寿命の最後の4秒（678から149メートル減少）：



















19:23にテレメトリデータが完全に到着しなくなりました。



SpaceILのエンジニアは、オンボードコンピューターを再起動するたびにBereshitデバイスに送信したすべてのデータ、コマンドリスト、パッチを入手できるようになりました。また、このすべての情報をより徹底的に調べ、デバイスでの事故前の着陸手順を分析することもできます。



悲劇につながった外部センサーからの誤ったデータだけでなく、このデータを処理したり、偶発的にデバイスを緊急事態に導いたプログラムコードも、送信前にコードを作成する段階でさえ、経験を積んでのみ解決できます宇宙船へ。



SpaceILのMorris Kahn議長は次のように述べました。「 私はSpaceILエンジニアリングチームの優れた仕事と献身に誇りを持っています。残念ながら、事故はしばしば複雑で革新的なプロジェクトの不可欠な部分です。 できる限り多くの教訓を学び、間違いを研究し、大胆に前進し続けることが重要です 。」



ちなみに、月の軌道上および着陸時のBereshit装置は、搭載された磁力計を使用し、月の磁場に関する科学データの一部をSpaceIL MCCに送信しました。



したがって、彼はそれにもかかわらず彼の科学的な小さなプログラムの一部を完了しました！



事故の場合に誤ってデータを更新しました ：



調査の完了した第一段階は、事実と一連の出来事の調査に至りました。 飛行中、通信が中断されましたが、Bereshit装置は指定されたモードで機能し続けました。 それは、デバイスが月面に着陸し始める瞬間まででした。



調査中に、飛行管制センターから送信されたコマンドの1つが実行されなかったことがわかりました。これにより、その後の一連の障害が発生しました。エンジンが動作を停止し、デバイスが表面に落下しました。



UMI（加速に責任がある）と呼ばれる加速度計センサーの動作で誤動作が検出されました。 失敗が続いた理由はまだ正確には確立されておらず、システムのその後の否定的な反応につながった。



加速度センサーをアクティブにするコマンドは、SpaceIL MCCから送信されました。



障害が発生した後、別の方法でエンジンを再起動しようとしましたが、失敗しました。



すべては、最も厳しい一時的な時間的プレッシャーの下で発生しました。ミッションの最後の数秒で障害が発生し、最終的に完了できませんでした。



Bereshit装置のオンボードコンピューターも、エンジンを自律的に再起動しようとしました-5〜6回試行されました。 しかし、それらはすべて失敗しました。



おそらく、スペアモジュール（IMU2）をオンにするデバイスのエンジニア間でコマンドの互換性のない実行が発生し、さらに新しい問題や事故につながりました。



宇宙船はIMU 1を使用していましたが、最初はIMU 2の障害の影響を受けませんでした。



1人のエンジニアがIMU 2を有効にしようとするかどうかを尋ね、別のエンジニアがそれを要求すると、システムがそれに切り替わります（おそらく「それ」はIMU 2を意味します）。



おそらく、2人目のエンジニアからの警告の言葉にもかかわらず、誰かがIMU 2を再起動しようとするコマンドを送信しました。