背景：
C ++で自動化フレームワークを作成したいのですが、一方では「センサー」と「アクター」、もう一方では「ロジックエンジン」を「コア」に接続できます。
「センサー」と「アクター」は「コア」を実行しているマシンに接続されている場合がありますが、フィールドバスまたは通常のコンピューターネットワークを介してアクセスできる場合もあります。継続的または定期的に動作するものもあれば（たとえば、100ミリ秒ごとに新しい値）、イベント駆動型で動作するものもあります（たとえば、スイッチが[非]アクティブ化された場合にのみ、メッセージに新しい状態が表示されます）。
「ロジックエンジン」は、コアにプラグインできるようなものであり、たとえば、埋め込まれたよく知られたスクリプト言語（Perl、Python、Luaなど）で構成されます。
「コア」は、センサー/アクター情報をサブスクライブされたスクリプトにルーティングし、それらを呼び出します。イベントが発生した直後のものもあれば、スケジューラーで定義されているように定期的にのものもあります。
追加要件：
- この自動化アプリケーションを実行するシステム（「サーバー」）も非常に小さい（500MHzx86および256MB RAM）か、可能であれば電力消費が問題であるため（OpenWRTベースのルーター）小さい場合があります
=>効率が重要です
=>マルチコアサポートはありません今のところ、それはすぐに重要になると確信しています-したがって、デザインはそれをサポートする必要があります - ある種のフェイルセーフモードが可能である必要があります。たとえば、2つのシステムが相互に監視している
- アプリケーション/フレームワークはGPLになります=>使用されるすべてのライブラリは互換性がなければなりません
- サーバーはLinuxを実行しますが、クロスプラットフォームがいいでしょう
大きな質問：
そのような種類のアプリケーション/フレームワークに最適なアーキテクチャは何ですか？
私の推論：
車輪の再発明をしないために、すべてのイベント処理を行うためにMPIを使用することを考えていました。
これにより、特に2つ以上の「サーバー」が連携して動作する場合（それぞれがいくつかのセンサーとアクターを接続している場合）、メッセージ処理ではなく、関連するものに集中できます。各センサーとアクターハンドラー、およびロジックエンジン自体は、事前定義されたMPIベースのインターフェイスを実装するためにのみ必要となるため、クラッシュを回避できます。コアが応答しなくなったときに、コアがそれぞれ再起動する可能性があります。
追加の質問：
- それはMPIでも可能でしょうか？（コンテキストから少し外れて使用されます...）
- MPIのオーバーヘッドは大きすぎますか？ソケットとスレッドを使用して自分で作成する必要がありますか？
- この場合により適した他のライブラリはありますか？