スペースの強化に対処しましたか？

スペースの強化に関しては、ベストプラクティスを研究したいと強く思っています。たとえば、私は（もう記事を見つけることはできませんが）火星探査機の中核部分は動的メモリ割り当てを使用していないことを読んでおり、実際には禁止されていました。私はまた、昔ながらのコアメモリが宇宙で好ましいかもしれないことを読みました。

Google Lunar Challengeに関連するいくつかのプロジェクトを見て、月に、または宇宙にさえコードを入れるのはどんな感じだろうと思っていました。スペースが強化されたボードは、このような過酷な環境である程度の健全性を提供することを知っていますが、（Cプログラマーとして）宇宙で実行する何かを書いている場合、どのように思考とコードを調整する必要があるのでしょうか？

私は今後数年間でプライベートスペース企業の成長がさらに見込めると思うので、少なくともベストプラクティスについてある程度知識を持ちたいと思っています。

断熱材に損傷を与えたボードに放射線、寒さ、または熱が衝突すると、プログラムはどうなりますか？目標は、宇宙船内に人間を置き（物の修理や交換に関する限り）、物事を修理するミッションを避けることだと思います。

さらに、ボードが重要なシステムを維持している場合、早期の警告が最優先されるようです。

テストと試行錯誤を通して、この経験をどのように得ることができますか（あなた自身の個人的な衛星の打ち上げがなければ）？

宇宙ソフトウェアは不可解な魔法ではありません。まだ1と3ではなく0と1を使用しています。したがって、ソフトウェアの開発に何が関係するかを説明することに関与するすごい要因はおそらくないでしょう。

現時点で思い浮かぶいくつかのわずかな違いは次のとおりです。

• 非常にプロセス指向。
• スペースソフトウェアには、常にソフトウェアとハ​​ードウェアの両方のウォッチドッグタイマーがあります。
• 私が取り組んだ宇宙システムはすべて、ハードリアルタイムシステムでした。
• システムのすべての外部アクターを（非常に正確に）シミュレートします。これには通常、テスト専用のカスタムハードウェアの構築（非常に高価な場合もあります）が含まれます。
• 正式なテストには膨大な労力と費用がかかります。
• 顧客（通常はJPL）はテストプロセスに非常に関与しています。
• 一般的に、新しいものではなく、古い既知のコンパイラーと開発環境を使用しています。
• コードレビュー、コードレビュー、コードレビュー。
• ハードウェアとソフトウェアの世界を非常に快適に切り替えることができます。ハードウェアの設計方法を知っている必要はありませんが、その仕組みを知っている必要があります。
• オシロスコープ、ロジックアナライザー、シンセサイザー、スペクトルアナライザーなどのテスト機器の広範な使用。
• アプリケーションプログラムを保存するための少なくとも3つの場所。デフォルトはROMに書き込まれます。これは決して変わりません。他の2つは、現在のバージョンと次/最後のバージョン用です。
• 故障解析（MTBF）は本当に重要です。
• 重要なコンポーネントの冗長システムとフェイルオーバー計画。

私はあなたの興味深い質問につまずいた。

私はアポロの間に計装研究所にいましたが、後に再び「冷戦」の間にドレーパー研究所と呼ばれました。

Apolloガイダンスコンピューターでは、RAMにコアが使用され、ROMに特別な編組コアが使用されました。マシン自体は完全にNORゲートで構成されており、信頼性のために非常に低速で動作していました。

ミニッツマンミサイルに直接取り組んでいませんでしたが、いくつかの問題を認識していました。いくつかの電子機器の近くで核弾頭が発動した場合、基本的にはショートします。誘導コンピューターには、Vcを即座に遮断する放射線センサーが搭載されていたため、燃え尽きることはありませんでした。その後、レジスターを消去してコンピューターを再起動します。

これを処理するために、コンピューターは定期的にレジスタをコアにスナップショットし、再起動するとそのチェックポイントから起動します。これを機能させるには、ソフトウェア（すべてASM内）を分析して、間違った答えを得ることなく、そのようなヒットを任意の頻度で取得できることを確認する必要がありました。それは「再起動保護」と呼ばれていました。非常に興味深い問題です。（ありがとう）使用する必要はなかったということです。

特にCで厳しい環境の信頼性を得るために、ここで私が見た本当に具体的なことをいくつか示します。

MISRA-C：自動車用Cサブセット。Ravenscar ADA / Javaに少し似ています。

ウォッチドッグ：プログラムがロックしないようにする

eccメモリ（時々）

チェックサム：反転ビットを探します。これら3つすべてを1つのシステムで見ました。

1）プログラムを継続的にチェックサムします（EPROMにありましたが、まだビットが反転しています）。

2）特定のデータ構造を定期的にチェックサムします。

3）CPUの健全性チェックは定期的に行われます。

4）IOレジスタにあるべきものをチェックします。

4b）出力を独立した入力に読み戻し、検証します。

プログラミング言語よりもはるかに重要なのは、基盤となるシステム（OSおよびハードウェア）の要件です。基本的に、システム全体の決定論的で予測可能な動作を保証（および証明）する必要があります。関連する多くの研究がリアルタイムコミュニティで行われています。このテーマを本当に勉強したい場合は、Jane LiuのReal-Time SystemsとHermann Kopetzの同名の本を読むことを強くお勧めします。前者は非常に理論的な方法でスケジューリングをカバーし、後者は地面に戻って、フォールトトレランスなどの（リアルタイム）システム設計に関連するすべての側面をほぼカバーします。

さらに、次の2つの事件は、ソフトウェアエンジニアが宇宙に何かを送るときに直面しなければならない問題の質をうまく示しています。

• アリアン5（さまざまな制約の下での実績のあるソフトウェアの再利用）
• Mars Rover Pathfinder Reboot（優先度反転）

私はのために（2009年頃）、この文書を発見したJPL制度は、Cプログラミング言語標準コーディング上のジェット推進研究所ので信頼性の高いソフトウェア（ラース）のために研究室サイト。

文書化されたルールの概要は次のとおりです。

1. 言語コンプライアンス

   • 言語定義の外に迷わないでください。
   • すべての警告を有効にしてコンパイルします。静的ソースコードアナライザーを使用します。

2. 予測可能な実行

   • 終了することを意図したすべてのループに検証可能なループ境界を使用します。
   • 直接再帰または間接再帰を使用しないでください。
   • タスクの初期化後に動的メモリ割り当てを使用しないでください。
   • *タスク通信にIPCメッセージを使用します。
   • タスクの同期にタスク遅延を使用しないでください。
   • *共有データオブジェクトの書き込み許可（所有権）を明示的に転送します。
   • セマフォとロックの使用に制限を設けます。
   • メモリ保護、安全マージン、バリアパターンを使用します。
   • goto、setjmp、longjmpは使用しないでください。
   • 列挙リストの要素に選択的な値の割り当てを使用しないでください。

3. 防御コーディング

   • 可能な限り最小レベルのスコープでデータオブジェクトを宣言します。
   • 非void関数の戻り値を確認するか、明示的に（void）にキャストしてください。
   • 関数に渡された値の妥当性を確認してください。
   • 健全性チェックとして静的および動的アサーションを使用します。
   • * int、shortなどの定義済みCデータ型の代わりに、U32、I16などを使用します。
   • 複合式の評価の順序を明示的にします。
   • 副作用のある式を使用しないでください。

4. コードの明瞭さ

   • Cプリプロセッサの使用はごく限られたものにします。
   • 関数またはブロック内でマクロを定義しないでください。
   • マクロを未定義または再定義しないでください。
   • ＃else、＃elif、および#endifを、一致する#ifまたは#ifdefと同じファイルに配置します。
   • *テキストの行ごとに複数のステートメントまたは宣言を配置しないでください。
   • *限られた数のパラメーターで短い関数を使用します。
   • *宣言ごとに2レベル以下の間接参照を使用します。
   • *オブジェクト参照ごとに2レベル以下の間接参照を使用します。
   • *マクロまたはtypedef内で間接参照操作を非表示にしないでください。
   • *非定数関数ポインターを使用しないでください。
   • 関数ポインタを他の型にキャストしないでください。
   • #includeディレクティブの前にコードや宣言を置かないでください。

*）すべてのルールがある条アスタリスクでマークされたものを除き、ルール。

スペースプルーフコンピューティングシステムは、すべて信頼性に関するものです。この分野の詳細な説明は、AlgirdasAvižienis、Jean-Claude Laprie、およびBrian Randellによる信頼性の基本概念にあります。

リアルタイムは、スペースコンピューティングの重要な概念でもあります。Pankratとして、Hermann KopetzのReal-Time Systemsをお勧めします。

宇宙コンピューティングの課題について実用的な感覚を与えるには、次のことを考えてください。

• 宇宙での極端な条件：太陽に向いたときは非常に暑く、反対側は非常に寒く、メモリ内のビットを反転させる可能性のある多くの宇宙線、大声で叫ぶときの巨大な加速と振動、...軍事用。

• 国際宇宙ステーションまたはハッブル宇宙望遠鏡を除き、障害が発生した場合、障害のあるシステムを交換する人はいません。最大限の可観測性と指揮能力、そして切り替え先の予備システムを通じて、すべてを地上から固定する必要があります。これは地球の衛星にとって簡単です。これは、通信遅延が1時間の場合がある宇宙探査機ではさらに困難です。実際、そもそもすべてが可能な限り信頼できるものでなければなりません。

インターンとして携わった1つのプロジェクトから学んだこと：

ハードウェアの仕様は変更されますが、通常はもっと悪いことです！

たとえば、設計で使用されていたCPUのスペースを確保したCPUは約束されていましたが、 約束したことが20 MHzで動作することを、心、あなたを。

最終結果は12 MHzで実行されました。プロジェクトのシニアプログラマーは、制御システムの厳しいリアルタイム要件を満たすためにアルゴリズムの再設計に多くの時間を費やし、テレメトリソフトウェアの多くは、プライマリCPUで実行する代わりに2番目のシステムにオフロードされました。

そのため、元のデザインで使用可能なリソースをいくつか残し、使用可能なすべてのCPUとメモリを使用しないようにしてください。

ソフトウェアの観点からは、コード内のビットを時々ランダムに反転する特権タスクを作成し、それがどのように処理されるかを確認してください。それがあなたのシミュレータです。

ハードウェアに関しては、スペース定格のものを入手するには時間がかかるため、部品は古くなっています。また、新しい部品は絶えずサイズが縮小されており、フィーチャーが小さいほど（ICのメモリセルを考えると）、放射イベントによる破損の影響を受けやすくなります。

私は安全性が重要なデバイスに取り組んでおり、いくつかの同様のフープを経験しなければなりませんでした。

安全に重要な変数がありました。変数の逆のコピーがありました。各ループの後、変数はその逆に対してチェックされました。

すべてのレジスタのウォーキングおよびゼロテストを実施しました。それにはプログラムカウンターが含まれていました！

マイクロ命令セットのすべてのオペコードをテストしました。2つのレジスタを追加した場合、レジスタが追加されたことを確認する必要がありました。

これのいくつかは、おそらく宇宙のプログラムとは関係ありませんが、可能なチェックの大きさの感覚を与えてくれます。

環境が悪いほどエラー訂正コードが使用され、ECCメモリが増えると思う使用され、ある程度使用できるます。

エラーのレベルを推定できる場合、導入されたエラーを処理できるエラー修正コードを作成できます。

• はい、コアメモリは研究委員会にあります。
• 動的メモリは組み込みシステムには適していません。信頼性の問題。

データのソフトウェアECCと、情報理論とカスタムローダーを使用してシステム全体にデータを拡散し、メモリ障害を管理することから始めると思います。しかし、私はrad-hardソフトウェアを研究していないので、私はそれをよく知らない、それは単なる推測です。