[解決済み】高放射能環境下で使用するアプリケーションのコンパイルについて

質問

が飛び交う環境で、シールドされたデバイスに展開される組み込みC++アプリケーションをコンパイルしています。 電離放射線 . GCCを使用し、ARM用にクロスコンパイルしています。デプロイすると、私たちのアプリケーションは、いくつかの誤ったデータを生成し、私たちが望むよりも頻繁にクラッシュします。ハードウェアはこの環境用に設計されており、私たちのアプリケーションはこのプラットフォームで数年間動作しています。

を識別/修正するために、コードに加えることができる変更、またはコンパイル時の改善はありますか？ ソフトエラー やメモリ破壊による シングルイベントアップセット ? 他の開発者で、長時間稼働するアプリケーションでソフトエラーの有害な影響を減らすことに成功した人はいるのでしょうか？

解決方法は？

約4～5年間、ソフトウェアやファームウェアの開発、環境テストに携わってきました。 小型人工衛星 *ここでは、その経験をお話ししたいと思います。

*( 小型衛星は、電子部品が比較的小さく、サイズが限られているため、大型衛星に比べてシングルイベントのアップセットが起こりやすい。 )

非常に簡潔かつ直接的な言い方をすれば、「回復する仕組みがない」ということです。 検出可能な誤り 状況 ソフトウェア/ファームウェア自身による なく 少なくとも、1つの コピー の 最低限動作するバージョン ソフトウェア/ファームウェアの どこか のために リカバリー という目的、そして リカバリーをサポートするハードウェア (機能的)です。

さて、このような状況は、通常、ハードウェアとソフトウェアの両レベルで処理されます。ここでは、ご要望にお応えして、ソフトウェアレベルでできることをお伝えします。

1. ...回復の目的... . 実環境でのソフトウェア/ファームウェアのアップデート/リコンパイル/リフラッシュの機能を提供する。これは ほぼマストアイテム 高電離環境下でのソフトウェア/ファームウェアのための機能です。これがないと 可能性 冗長化されたソフトウェアやハードウェアはいくらでもありますが、ある時点ですべて吹き飛んでしまうのです。だから、この機能を用意しましょう

2. ...最低限動作するバージョン... ソフトウェア/ファームウェアの最小バージョンを、レスポンス良く、複数コピーして、コードに組み込んでください。これは、Windowsのセーフモードのようなものです。完全に機能するバージョンを1つだけ持つのではなく、ソフトウェア/ファームウェアの最小バージョンのコピーを複数持つようにします。最小バージョンのコピーは、通常、完全なコピーよりもはるかに小さいサイズになり、ほとんど常に のみ 以下の2～3の機能です。

   1. 外部システムからのコマンドを待ち受けることができる。
   2. 現在のソフトウェア/ファームウェアを更新することができる。
   3. 基本動作のハウスキーピングデータを監視できること。

3. ...コピー...どこかに...。 どこかに冗長なソフトウェア/ファームウェアがある。

   1. を使えば、可能です。 または ハードウェアを冗長化せずに、ARM uCのソフトウェア/ファームウェアを冗長化することを試みます。これは通常、2つ以上の同じソフトウェア/ファームウェアを持つことによって行われます。 別々のアドレスで しかし、一度にアクティブになるのは1つだけです。しかし、一度にアクティブになるのは1つだけです。1つ以上のソフトウェア/ファームウェアが応答しないことが判明した場合、もう1つのソフトウェア/ファームウェアに切り替えます。この方法の利点は、エラー発生後すぐに機能交換ができることです。エラーの検出と修復を担当する外部システム／関係者（サテライトの場合、通常はミッションコントロールセンター（MCC））に一切連絡することなく、機能交換ができます。

      厳密に言うと、冗長化されたハードウェアがない場合、この方法の欠点は、実際には できない 排除 すべて シングルポイントエラー 少なくとも 一つ 単一障害点、である スイッチ本体 (またはコードの先頭であることが多い）。とはいえ、高電離環境でサイズに制限のあるデバイス（ピコ／フェムト衛星など）の場合、単一障害点を1点に減らすことで なく ハードウェアを追加することは、やはり検討に値するでしょう。さらに、スイッチングのためのコード片は、プログラム全体のコードよりはるかに少ないことは確かで、シングルイベントのリスクを大幅に減らすことができます。

   2. しかし、もしこれをしないのであれば、デバイスと接触してソフトウェア/ファームウェアを更新できる外部システム（衛星の場合、それは再びミッションコントロールセンターです）に少なくとも1つのコピーを持つべきです。

   3. また、実行中のシステムのソフトウェア/ファームウェアを復元するためにトリガーすることができるコピーを、デバイスの永久メモリストレージに保存することもできます。

4. ...検出可能な誤りの状況... エラーは、必ず 検出可能 通常、ハードウェアによって エラー訂正・検出回路 またはエラー訂正/検出のための小さなコードによって。そのようなコードは小さく、複数個置くのがベストです。 独立した メインソフトウェア/ファームウェアから その主なタスクは のみ チェック・補正のため。もし、ハードウェア回路/ファームウェアが 信頼できる (レストよりも放射線耐性が高いとか、複数の回路・ロジックを持つとか）、それでエラー訂正をすることも考えられるでしょう。しかし、そうでない場合は、エラー検出とした方がよいでしょう。補正は、外部システム／デバイスで行うことができます。誤り訂正には、Hamming/Golay23のような基本的な誤り訂正アルゴリズムが、回路/ソフトウェアともに実装しやすいので、それを利用することも検討できます。しかし、最終的にはチームの能力に依存します。エラー検出には、通常CRCが使用されます。

5. ...リカバリーをサポートするハードウェア さて、この問題で最も難しい局面を迎えます。最終的には、リカバリーを担当するハードウェアが 少なくとも 機能します。ハードウェアが永久に壊れている場合（通常、その後に起こる 全電離量 あるレベルに達すると、（悲しいかな）ソフトウエアは復旧の手助けをすることができません。このように、高い放射線レベルにさらされる機器（人工衛星など）にとって、ハードウェアは最も重要な懸念事項なのです。

上記のシングルイベントアップセットによるファームウェアのエラーを想定した提案に加え、こんな提案もあります。

1. サブシステム間通信プロトコルのエラー検出および/またはエラー訂正アルゴリズム。これは、他のシステムから受信した不完全な/誤った信号を回避するために、もう1つのほぼ必須のものです。

2. ADCの読み取りにフィルターをかける。行う ない ADCの読み取り値を直接使用する。中央値フィルタ、平均値フィルタ、その他のフィルタでフィルタリングしてください。 決して 単一の読み取り値を信頼する。サンプルは多く、少なくない - 合理的に。