火星のプログラマー：Shutdown Dammit until

「ヒューストン、問題があります。」

「いいえ、マーク、それがあなたの問題です。」



火星探査機のプログラマとテスターは、どのようにして4億ドルで眠りますか？ 特に18ソルの場合、デバイスは接触しませんでした。







マーク・アドラーは、宇宙探査の分野で働くアメリカのソフトウェア開発者です。 彼は、データ圧縮の分野での仕事で最もよく知られており、ハッシュ関数Adler-32の著者であり、 zlibおよびgzipデータを圧縮するためのライブラリの共著者でもあります。 彼はInfo-ZIPおよびPortable Network Graphics （PNG）画像フォーマットの開発に携わっていました。 アドラーはまた、 火星探査ローバープログラムの一環として、火星探査機スピリットのミッションを担当しました。



Edison （ 実験用の 保護リレーシステムとアプリケーションの開発を専門とする）と一緒に、ローバーのソフトウェア開発者と、2億2500万キロメートルの距離でソフトウェアエラーを修正しようとしたときに発生したイベントについて説明します。

伝記

フロリダ州マイアミで生まれたアドラーは、デイビッドとベルタ・アドラーの唯一の子供でした。 彼は数学計算の理学士号を取得し、1981年と1985年にそれぞれフロリダ大学で電気工学の修士論文を擁護しました。 1990年、アドラーはカリフォルニア工科大学で物理学の博士号を取得しました。 彼はダイアナ・セント・ジェームスのいるラ・カニャダ（カリフォルニア）に住んでおり、ジョシュアとザカリーという2人の子供がいます。 ダイアナはカリフォルニア工科大学で働いており、舞台公演に参加し、演劇に参加しています。







J. Gailly （gzipの著者）とのコラボレーションで、FLOSSデータ圧縮アルゴリズムの開発への貢献が認められ、2009 USENIX Awardを受賞しました。 [出典-STUGアワード ]

経歴

博士号を擁護した後、アドラーは宇宙通信部門のヒューズエアクラフトで、衛星チャンネルでのX線バーストの影響の分析、 エラー修正コードの開発、盗難防止キーの開発、ビデオおよび画像圧縮の研究など、さまざまなプロジェクトに取り組みました（ ウェーブレットおよびMPEG-2 ）。 [出典-Caltech：Mark Adlerについて ]

火星探査

1992年から1995年まで、AdlerはCassini-Huygensミッションのリードエンジニアでした 。 その後、1996年から1998年まで、 ジェット推進研究所 （JPL）の火星探査プログラムのコーディネーターに任命されました。 したがって、彼は2001年以来、火星探査ミッションの計画を担当しています。



1999年から2000年にかけて、彼は火星からサンプルを配達するプロジェクト（火星サンプルリターン）に取り組みました。その枠組みでは、火星への3つのミッション（2003-2005年）を実施し、2005年に地球にサンプルを持ち込むことが計画されていました。 ただし、火星の極地着陸船のミッションが失敗したため、プロジェクトは拒否されました。

火星探査ローバー

AdlerはMars Exploration Rover火星探査プロジェクト（SpiritおよびOpportunity探査機）を開始し、その実装に積極的に参加しました。



現在、アドラーは低密度超音速減速機プロジェクトの責任者です。これは、火星で2〜3トンの貨物を発射する手段の開発です。



火星と彼の仕事に関するマークの反省 。



現在、マークは低密度超音速減速機またはLDSDのプロジェクトマネージャーです。

「スピリット」 18ソル 異常

マーク・アドラーによるナレーション。 2006年9月22日、惑星コミュニティのアーカイブ資料。



前回の投稿で、私は大統領が国家計画「宇宙探査」を発表した一週間後にスピリットに何が起こったのかを話すと約束した。



そして、貴重な国有財産を管理する方法について、内部から大まかに一目。



2004年1月21日18火星の日（ナイチンゲール）は、スピリットが火星に着陸した瞬間から、火星の表面に着陸プラットフォームを正常に出てから約1週間が経過しました。 すべてが信じられないほどうまくいったので、信じられませんでした。 観測するのは実際には奇妙でした。ローバーはテスト中よりも火星でずっとうまく機能しました。 スピリットはエイリアンの世界の表面で実際の地質調査に関与していました！ 地球上で最も幸せな人のように感じました。



まあ、運はすぐに私たちに背を向けた。



ジェニファー・トロスパーと私は交互にスピリットミッションの戦術的指揮の義務を果たしました。 ジェニファーは18ソルで勤務していたので、休みがありました。 確かに、私はまだ正午頃にLRDに来て、ドキュメンタリーのインタビューをしました。 その結果、MER（Mars Exploration Rovers）プログラムのスーパーバイザーであるSteve Squaersに出会いました。 彼は面接に来たところです。 私を見て、スティーブは言った：「あなたはすでにスピリットを知っていますか？」スティーブの質問と深刻な口調はすぐに私を眠気状態から引き離しました。 「どういう意味ですか？」私は彼を見つめて尋ねた。 スティーブは、指定された時間にスピリットから信号を受信しなかったと言いました。地球に直接届く高利得のアンテナを通して、またはオービターの火星オデッセイのリピーターを通して。



なんてこった



最初のケースで通信がなかった場合、これは悪天候、長距離宇宙通信ネットワークの問題、多くのものに簡単に起因する可能性があります。 数億キロメートルにわたる通信は単純な問題ではなく、多くの場合問題を抱えています。 しかし、当時の私たちの経験から判断すると、わずか数百キロメートルの距離で軌道上にあり完全に機能したオデッセイを介した通信は失敗するべきではありませんでした。



すべてが問題がローバーにあることを示し、すべてが非常に深刻でした。



宇宙ミッションは危険です。 私たちはそれに慣れています。 最も危険な瞬間を慎重に検討します。 MERプログラムの最大のリスクは、配達、降下、着陸、または、私たちが呼んだように、地球からの非常に危険な打ち上げ、およびプラットフォームを出てローバーを展開する着陸後の操作に加えて、6分間の恐怖でした。ケーブルを取り外します。



開始、着陸、終了。 これのいずれかはあなたが灰色になります。 スピリットで、これを突破しました。 危険なものはすべて取り残された、と私たちは考えました。 そして、当然ながら、十分な注意と注意を払うことで、主要な危険はもはや予見されませんでした。 簡単で測定された前方への水泳。



これはすべて不安に追加されただけです。 一体何が起こったの？



私はすぐに手術エリアに行きました。そこで、私と他の多くの人々は休みなく次の3日間を過ごしました。 そのような状況では休みはありません。 次の3つのソロでは、ジェニファーがタスクのスケジューリングを担当し、私はその実装を担当しました。 火星の夜に計画し、日中にローバーが起きているときに戦術を実行します。 そのため、ジェニファーと彼女のチームは何をすべきかを判断しようとしましたが、私と私のチームはそれを行いました。 または少なくとも試してみました。



19日ソルで、私たちは単にスピリットに連絡して彼からフィードバックを得ようとしました。 始める前に、伝統に従って、私はその日の出来事に捧げられたミッションコントロールセンターで歌を歌いました。 19回目のソロでは、Abbaの「SOS」を選びました。 一般的に、これはその日スピリットが関わったほぼすべてのものです。 通信の試みは失敗し、ローバーの送信機信号のみが受信されました。 送信する情報がない場合は、とにかくオンになり、まだそこにあるという重要な信号の証拠を提供します。 彼は完全に失われたわけではありません。 これ以外に、他の情報は受信されませんでしたが、私たちはそれを良い日と考えました。 その日の状況に関するレポートを楽観的なメモで終えました。「長期的には、デバイスの状態を復元し、何が起きたかを診断して修正し、通常の勤務スケジュールに戻す予定です。」 20ソルと21ソルのレポートを同じ言葉で仕上げました。



20日ソルで、私たちはローバーから情報を引き出すためにさらに熱心な試みをしました。 結局、それなしでは、私たちは何をすべきか、何をすべきか、作業能力をどのように回復するのか分からなかった。 何度も試行した結果、無線送信機から現在の情報を取得することができました。 そのほとんどは謎めいた繰り返しでしたが、それ自体は謎でしたが、それでもこのデータパケットはSpiritの状況を理解するのに十分でした。 はい、素晴らしいニュースですが、状況自体は喜びを引き起こしませんでした。



ローバーの内部温度は通常よりもはるかに高く、バッテリーの充電は予想よりもはるかに低いことがわかりました。 これらの2つの要因は、ローバーがスリープモードに移行しようとしていないことを明確に示しています。 通常、彼のコンピューターは1日5〜6時間稼働しています。 これにより、バッテリーに保存されている貴重な太陽エネルギーを節約し、デバイスの過熱を防ぎます。 まあ、霊は長い間眠っておらず、眠らないかもしれません。



病気の火星探査車が1台手にありました。 スピリットには不眠症、発熱があり、常に衰弱し、首尾一貫せずにつぶやいており、長い間命令に従わなかった。



残念だ。 私たちの火星では、1人のローバーが死にかけ、2日後にもう1人のオポチュニティが配達、降下、着陸を経なければなりませんでした。 1週間以内に、ローバーなしで簡単に終了することができました。



20日ソルの主なタスクは、ローバーをスリープ状態にすることでした。 切断コマンドが通信セッションの一部としてデバイスに到達することを期待しました。 したがって、デバイスコマンドの受信を確認するセッションの時期尚早の終了を確認できました。 そのため、特定の時間までデバイスをオフにするコマンドを送信しました。SHUTDWN_DMT_TILは、現時点でデバイスが実行するアクションよりも優先されます（コマンド名は控えめにユーモアで装飾されています）。



私たちはそれがうまくいくと確信していました。 ええと...私たちは霊を眠らせました。 確認するために、彼らはデバイスにリクエストを送信しました。 スリープモードのローバーは、信号を受信も応答もできません。



そして...応答信号を受け取りました。



なに...？ スピリットは眠りにつくことになっていた！ しかし、ありません。 彼は仕事に遅れることにした。



地球の位置は、次の日まで試みを延期せざるを得ませんでした。 このとき、ローバーは充電を続け、電子機器は過熱しました。 私たちの時間はすぐに尽きました。



21ソル 計画があります。 現在の問題の基本バージョンは、少なくとも私たちに操作の余地を残していましたが、当時は次のようなものでした。ローバーのコンピューターが「リセットループ」に陥っていました。 解決できない問題に対するソフトウェアの応答は、再起動です。 コンピューターがフリーズしたときと同じこと。 しかし、リセットボタンを押すことができる人がいなかったため、ローバーはこれを自動的に行いました。 ただし、再起動中にソフトウェアでエラーが発生した場合、永久に再起動する運命にあります。



開発者はリブート間の遅延を慎重にプログラムしました。その間、ローバーと話すことができます。 これは、コマンドの断続的な実行を説明できます。肯定的な結果は、デバイスがブート間間隔で信号を受信した場合のみです。



再起動のアイデアは簡単です。前のセッションで問題を引き起こしたものはすべて、新しいセッションでは消えます。 しかし、この場合、問題は残りました。 そのため、「スピリット」は再起動の間に何かを思い出し、それが失敗の原因でした。 これは、フラッシュカメラ（デジタルカメラなど）、EEPROMメモリの小さなブロック、またはハードウェア障害を示しています。 フラッシュメモリはローバーでコンピュータのハードドライブとして使用されます。ファイルシステムはそこに保存されます。



繰り返しますが、天才開発者は私たちのために裏口を作りました。 フラッシュ上のファイルシステムを見ずにローバーを再起動する方法がありました。 地球から信号を受信する無線機器は、それ自体でいくつかのコマンドをデコードできます。いわゆる ハードウェアコマンド。 認識と実行には、コンピューターはまったく必要ありません。 これらのコマンドの1つは、ブート時にファイルシステムを使用しないようにコンピューターに指示することです。 別の同様のコマンドにより、コンピューターが再起動する可能性があります。



したがって、これは21ソルで行ったものです。 何度か試みた後、やっとスピリットを多かれ少なかれ健全なモードでダウンロードすることに成功しました。彼はコマンドに応答し、ナンセンスをつぶやきませんでした。 それはなんと安reliefしたことでしょう！ 私たちは過去数日間のエネルギー消費の履歴を要求し、オービタルリピーターとの通信のために次の予定されたセッションを延期し、そして最終的にスピリットに長くふさわしいと切望されていた夢を持たせました。 今回はすべてがうまくいきました。



今、私たちにはスピリットを働かせる秘密の手段がありました。 ローバーはまだブートサイクルモードで毎朝起動する必要がありましたが、ファイルシステムをバイパスして、ブートに必要なコマンドをすばやく送信できました。 次の数日間でした。 私たちは時間との戦いに勝ちました、そして今、私たちは何が起こったのかを正確かつ系統的に見つけ、それを修正し、ミッションを継続することができます。



それで家に帰って、すぐに眠りに落ちました。 私の目覚まし時計は5時間後に鳴りました。 なんで？ LRDに戻り、今夜の機会を逃さないように。 私たちがスピリットのコントロールを取り戻した数時間後、チャンスは時速1万2,000マイルの速さで悲鳴を上げて火星の大気圏に突入しました。 着陸は成功し、私たちは再び自信を持ちました。火星に安全な全地形対応車が2台あります。 うわー、まあ、冒険。



21ソルの終わりに、回復操作の転換点に達しました。 確かに、診断の完了、問題の解決（デバイスのハードディスク（フラッシュメモリ）のフォーマットが必要）、Spiritの完全な機能の再開にはさらに2週間かかりました。



クラッシュの前に蓄積された情報を回復したので、Rock Abrasion Tool（RAT）でアメリカ国旗のこの美しいカラー写真を取り出しました。 この旗は、世界貿易センターのツインタワーの遺跡から作られた保護ケーシングにありました。 RATは、タワーがあった場所から数ブロック離れたマンハッタンで設計および建設されました。 この写真をコントロールセンターの大型モニターに星とストライプで配置し、国歌を失いました。 誰もが彼の心に手で立っていました。 それは良い瞬間でした。



それ以来、スピリットは正常に機能し、モーターの騒音の増加などの年齢の兆候を考慮していません。 私がこれを書いている間、スピリットは967マークのマークを克服しました。 九百六十七？！ ちょっと待って、ある種の間違いがあります。 確認しましょう... N-no、それだけです。 すごい。



18ソルでの失敗の主な理由は何だろうと思われます。 最終的に、ローバーソフトウェアのバグであり、テスト段階では検出されなかったことがわかりました。 情報を収集するにつれて、占有メモリの量はますます増加しました。 18日ソルで、メモリブロックがいっぱいになり、ファイルシステムを読み取ることができないため、再起動プロセスが停止しました。 実際、多くのソロを過ごした後に起こりうる問題について考えました。 これらの疑念を払拭するために、着陸前に10塩のテストを実施しました。 しかし、18塩のテストは実施しませんでした。 スピリットが火星で私たちのためにそれを保持するまで、はい。



確かに、他の宇宙船で深刻なソフトウェアエラーが発生することは何度もあります。 しかし、私はそのような間違いがもはや私たちを驚かせないことを保証します。



翻訳にご協力いただきありがとうございます。セルゲイダンシンに感謝します。





火星の夕日。 スピリットローバーのスナップショット

エラー処理

詳細と詳細が必要な人にとっては、イベントのシーケンスを詳細に説明し、主要な理由を特定し、学んだ教訓を登録し、発見された欠点に関連してどのような変更が導入されたかというレポートが役立ちます。



The Mars Rover Spirit FLASH Anomaly （Glenn Reeves、Tracy Neilson、ジェット推進研究所）







NASA開発者がバグに取り組む方法の別の例。 推奨事項あり-MER Spirit Flash Memory Anomaly（2004）

興味深い事実

• スピリットは2日間で60回リロードしました。
  
  
  
  
• ローバーのコンピューターには、PowerPCチップの放射線対策バージョン（一部のポピーで使用されていた）である32ビットRad 6000マイクロプロセッサーが搭載されていました。 速度-1秒あたり2000万回の操作。
  
  
  
  
• 合計で、このコンピューターには3種類のメモリがあります：電源がオフになると消去される128 MBのRAM、データを保存するための256 MBの不揮発性フラッシュメモリ、最後にソフトウェアの参照コピーを保存する電気的にプログラム可能なROM。
  
  
  
  
• フライトソフトウェアは、 vxWorksで実行されるCで完全に記述されています 。 地上ベースのソフトウェアは、C、C ++、Fortran、Perl、およびJava（およびおそらくそれ以上）の混合物です。
  
  
  
  
• ほとんどのステレオビジョンおよびローバーナビゲーションソフトウェアコード（約70,000行）はC ++で記述されています。 最適化のために、さらにいくつかのコードがCおよびアセンブラーで記述されています。
  
  
  
  

[ソース-c2.com/cgi/wiki?MarsSpiritSoftwareProblem ]

---

エジソンの方法は、電力網監視およびイベント視覚化システムまたはX線トモグラフ用のソフトウェアをテストするプロセスです。ビデオを参照してください。