私たちは、シールドされたデバイスに展開された組み込みC++アプリケーションをコンパイルしています。電離放射線私たちは GCC を使用して ARM 用にクロスコンパイルしています。デプロイすると、アプリケーションが誤ったデータを生成し、予想以上に頻繁にクラッシュします。ハードウェアはこの環境向けに設計されており、私たちのアプリケーションはこのプラットフォームで数年間実行されています。
コードに変更を加えたり、コンパイル時に改善を加えたりして、問題を特定/修正することはできますか？ソフトエラーおよびメモリ破損によって引き起こされるシングルイベントの番狂わせ? 長期実行アプリケーションにおけるソフトエラーの有害な影響を軽減することに成功した開発者は他にいますか?
ベストアンサー1
ソフトウェア/ファームウェアの開発と環境テストに約4〜5年間携わりました。小型衛星*、ここで私の経験を共有したいと思います。
*(小型衛星は、電子部品のサイズが比較的小さく限られているため、大型衛星よりもシングルイベントアップセットが発生しやすくなります)
非常に簡潔かつ直接的に言えば、回復目的でソフトウェア/ファームウェアの最小動作バージョンのコピーが少なくとも1 つどこかに存在せず、回復をサポートするハードウェア(機能的) がなければ、ソフトウェア/ファームウェア自体によって検出可能なエラー状況から回復するメカニズムは存在しません。
さて、この状況は通常、ハードウェア レベルとソフトウェア レベルの両方で処理されます。ここでは、ご要望に応じて、ソフトウェア レベルで何ができるかをお伝えします。
...回復目的...実際の環境でソフトウェア/ファームウェアを更新/再コンパイル/再フラッシュする機能を提供します。これは、高度にイオン化された環境のソフトウェア/ファームウェアにとってほぼ必須の機能です。これがなければ、冗長ソフトウェア/ハードウェアを好きなだけ持つことができますが、ある時点ですべてが爆発してしまいます。そのため、この機能を準備してください。
... 最小動作バージョン...コード内に、応答性の高い、ソフトウェア/ファームウェアの最小バージョンの複数のコピーを用意します。これは、Windows のセーフ モードのようなものです。ソフトウェアの完全機能バージョンを 1 つだけ用意するのではなく、ソフトウェア/ファームウェアの最小バージョンの複数のコピーを用意します。最小コピーは通常、完全コピーよりもサイズがはるかに小さく、ほとんどの場合、次の 2 つまたは 3 つの機能のみを備えています。
- 外部システムからのコマンドを聴くことができる、
- 現在のソフトウェア/ファームウェアを更新できる
- 基本操作のハウスキーピングデータを監視できます。
...どこかにコピーします...どこかに冗長ソフトウェア/ファームウェアを用意します。
冗長ハードウェアの有無にかかわらず、ARM uC に冗長ソフトウェア/ファームウェアを導入することができます。これは通常、 2 つ以上の同一のソフトウェア/ファームウェアを別々のアドレスに置き、相互にハートビートを送信することで実現されますが、一度にアクティブになるのは 1 つだけです。1 つ以上のソフトウェア/ファームウェアが応答しないことがわかっている場合は、他のソフトウェア/ファームウェアに切り替えます。この方法を使用する利点は、エラーが発生した直後に機能的な交換が行えることです。エラーを検出して修復する責任がある外部システム/関係者 (衛星の場合は通常、ミッション コントロール センター (MCC)) と連絡を取る必要はありません。
厳密に言えば、冗長ハードウェアがない場合、これを行うデメリットは、実際にはすべての単一障害点を排除できないことです。少なくとも、スイッチ自体(または多くの場合、コードの先頭)である単一障害点が1 つ残ります。ただし、高度にイオン化された環境 (ピコ/フェムト衛星など) でサイズが制限されているデバイスの場合、追加ハードウェアなしで単一障害点を 1 点に減らすことは、依然として検討する価値があります。さらに、スイッチング用のコードは、プログラム全体のコードよりもはるかに小さくなるため、Single Event が発生するリスクが大幅に軽減されます。
ただし、これを行わない場合は、デバイスと通信してソフトウェア/ファームウェアを更新できる外部システムに少なくとも 1 つのコピーを用意する必要があります (衛星の場合は、ミッション コントロール センターになります)。
- デバイスの永久メモリストレージにコピーを保存しておき、実行中のシステムのソフトウェア/ファームウェアを復元することもできます。
...検出可能なエラー状況...エラーは、通常、ハードウェアエラー訂正/検出回路、またはエラー訂正/検出用の小さなコードによって検出可能でなければなりません。 このようなコードは、小さく、複数で、メインのソフトウェア/ファームウェアから独立したものにするのが最適です。 その主なタスクは、チェック/修正のみです。 ハードウェア回路/ファームウェアが信頼できる場合(他のものよりも放射線耐性が高い、または複数の回路/ロジックがあるなど)、それを使用してエラー訂正を行うことを検討できます。 しかし、そうでない場合は、エラー検出として行う方がよいでしょう。 修正は外部システム/デバイスによって行うことができます。 エラー訂正には、Hamming/Golay23 などの基本的なエラー訂正アルゴリズムの使用を検討できます。これらは、回路とソフトウェアの両方でより簡単に実装できるためです。 しかし、最終的にはチームの能力に依存します。 エラー検出には、通常 CRC が使用されます。
...回復をサポートするハードウェアさて、この問題の最も難しい側面に至ります。 結局のところ、回復には、回復を担当するハードウェアが少なくとも機能している必要があります。 ハードウェアが永久に壊れている場合 (通常、総電離線量が特定のレベルに達した後に発生します)、ソフトウェアが回復を支援する方法は (残念ながら) ありません。 したがって、高レベルの放射線にさらされるデバイス (衛星など) にとって、ハードウェアは当然最も重要な懸念事項です。
シングル イベント アップセットによるファームウェア エラーを予測するための上記の提案に加えて、次のことも提案します。
サブシステム間通信プロトコルにおけるエラー検出および/またはエラー訂正アルゴリズム。これは、他のシステムから不完全/誤った信号を受信することを避けるためにほぼ必須のものです。
ADC 読み取り値をフィルタリングします。ADC読み取り値をそのまま使用しないでください。中央値フィルター、平均値フィルター、またはその他のフィルターでフィルタリングします。単一の読み取り値を決して信用しないでください。適度に、少なくではなく多くサンプリングします。