メッセージパッシングをCPUの冗長性と負荷分散構造に使用できますか

複数のプロセッサを備えたベアメタルまたは最小限のRTOSタイプの組み込みシステムで、メッセージパッシングインターフェース（MPI）を使用して同一のプログラムを各プロセッサで実行し、ロードバランシングとプロセッサ障害時の冗長性を提供することは可能ですか？渡されたメッセージに基づいて他のCPUが実行するアクションを変更するステートマシンなど。たとえば、ロードバランシングまたは定期的なアライブメッセージの送信のためにシステムループの一部を引き継ぐように別のプロセッサに要求し、各CPUが何を担当しているかを記憶するCPUの冗長性。

この例の図では、「オープン」である完全なシステムループの実際の部分は、異なるシステムである可能性があります。ある種の非常に原始的な非対称マルチプロセッシングで、各CPUで実行されている完全なシステムループの一部を開いたり閉じたりする機能だけでは、協力がありません。別のCPUへの「プロセスの移行」は、別のCPUがシステムループのその部分を開くように要求することによってトリガーされます。その後、要求側のCPUがその部分を閉じるか、クエリが実行されたときに別のCPUからの応答がないため、一定時間存続する。

組み込みOSを移植してカスタムボードで対称または非対称のマルチプロセッシングを実際に実行することはできず、理論的には可能であるように思えますが、設計が非常に悪いため、これは潜在的なプロセッサ障害の解決策およびロードバランシングの解決策として提案されています考え。また、この方法でメッセージパッシングを使用するための設計パターンやアルゴリズムを見つけることができませんでした。

ソフトウェアエンジニアリングの決定に重要な背景：学生のCubeSatプロジェクト（採点またはクラス用ではありません）。オペレーティングシステムの設計に関する知識がほとんどまたはまったくない、ほとんどが中学生の小規模なソフトウェア開発チームがあります。さまざまな理由により、私が読んだ多くの現実的な解決策のいずれも実行できません。これは、チームが対処するのに複雑すぎるほど導入される可能性があるように聞こえるかもしれませんが、それが可能であっても、CubeSatを軌道に乗る岩石に変えるいくつかの問題につながる恐ろしい設計を引き起こす可能性があるようです。

スペースフェアリングに十分な信頼性のある方法でメッセージパッシングを実装できるかどうかさえわかりません。小さなOSまたはベアのバスでメッセージを渡すために使用できるプロダクション対応の通信プロトコルを見つけることもできませんでした。私たちが必要とするような金属。しかし、私は、プロセスの移行、CPUの冗長性、およびロードバランシングのためのこの提案されたソリューションが、安全性が重要なシステムでも実行可能かどうかを知りたいと思っています。検出が困難なスリープ状態から復帰すると、2つのCPUが同じ「プロセス」またはプログラムループの一部を実行している状態になる可能性があります。

私が実際にこれを90年代半ばに取り戻したので、すばらしい質問です。宇宙船は高価であり、軌道上で一度ソフトウェアを変更することは困難です。宇宙船のソフトウェアリソースが変化するミッション要件に基づいてどのように再割り当てできるかを考えるとき、この問題の変形について考えました。ラボ（VxWorks）で行った限り：

1. 要件ごとに各プロセッサに不可欠なタスクの負荷を見積もります。
2. サブミッションタスクセットのタスク負荷を推定します。これは、最も重要なミッション要件を満たすために必要なプロセッサごとの必要なタスクの提供に基づいて望まれる新しい構成です。基本的にはなくてはならないもの。
3. 現在、各プロセッサーについて、可能な限り迅速に切り替えなければならない可能性がある他の処理状態に基づいて、主要なミッションタスクモデルとそのバリアントがあります。これは単純に計画された適応です。特別なことは何もありません。いくつかの刺激を出し入れするタスクモデルの異なるセットだけです。私の実験での負荷分散は基本的に事前に計画されていました。この操作には、基本的なRMAスケジューリングを使用しました。基本的に、これはシステム全体のタスクモデルレベルでの大きなコンテキストスイッチです。

RTOSでのステーションプログラムの更新。 基本的に、新しいタスクセットを接続し、キューネットワークを接続して、データフローを再開します。
したがって、この単純な実装では、一部のタスクを一時停止または削除し、他のタスクを実行できるようにしました。「心臓移植」技術と呼ばれるもので、もう少し詳しく説明しました。これは、ステーションソフトウェアのアップデート用でした。タスクモデル内でキューネットワークを切断して再ルーティングできます。基本的にタスクを切断し、必要に応じて削除します。キューを強制終了し、新しいタスク（心臓）と動脈（キューネットワーク）を再接続します。私たちは1995/96年にこのちょっとした遊び時間をしました。メモリは非常に限られたリソースであるため、機能を追加する機能だけでなく、不要な機能を削除する必要もありました。MPIについてよく知らないので、使用しませんでした。それは確定的ですか？情報理論を使用すると、キープアライブ信号を送信するために多くを必要としません。最小限のビットを使用します。「キープアライブ」などの最も一般的な情報は1ビットしかかかりませんが、正しいか間違っているか。より低い確率で発生するイベントは、表現するためにより多くのビットを必要とします。可能なソフトウェアのオーバーヘッドを排除します。KISSの原則に従ってください（Keep It Simple..Stupid！）。

ある種の放射線防護。学生プロジェクトとは、おそらくCMOSを飛ばすことです。少なくともCRCチェックをメモリに置き、ウォッチドッグを実行して、ハングアップ放射線が電子機器に奇妙なことをするようなエラーをキャッチします。シングルイベントの混乱の影響は、メモリのCRCを使用して軽減できます。ラッチアップにはパワーアップリセットが必要です。

FreeRTOSのようなものを試してみて、あなたの意志に曲げることができる機能を確認することをお勧めします。宇宙は非常に挑戦的な環境です。楽しんで。