ミッションクリティカルな組み込みアプリケーションのメモリをどのように管理する必要がありますか？
グーグルでいくつかの記事を見つけましたが、本当に役立つ実用的なガイドを特定することができませんでした。
動的メモリ割り当てはDO-178b禁止されていますが、メモリをどのように管理しますか？事前にすべてを事前に割り当て、割り当てが必要な各関数へのポインタを送信しますか？スタックに割り当てますか？グローバル静的アロケータを使用しますか（ただし、動的割り当てと非常によく似ています）？
回答は、通常の回答、リソースへの参照、または優れたオープンソース組み込みシステムへの参照などの形式にすることができます。
明確化：ここでの問題は、組み込みシステムでメモリ管理が利用できるかどうかではありません。しかし、信頼性を最大化するための組み込みシステムの優れた設計は何ですか。
バッファプールを静的に事前割り当てし、動的に取得および削除することが、メモリを動的に割り当てることと異なる理由がわかりません。
組み込みシステムを扱ったことがある人として、これまでのところそれほど厳密ではありませんが（DO-178Bを読んだことがあります）：
しかし、実際には、 http：//www.do178site.com/に参加することであなたの答えが見つかるかもしれないと思います
私はDO-178B環境（飛行機用のシステム）で働いてきました。私が理解したのは、動的割り当てを許可しない主な理由は主に認証であるということです。認証は、テスト（ユニタリ、カバレッジ、統合など）を通じて行われます。これらのテストでは、プログラムの動作が100％予測可能であり、プロセスのメモリフットプリントが実行ごとに同じになることを証明する必要があります。動的割り当てはヒープ上で行われるため（失敗する可能性もあります）、それを簡単に証明することはできません（ハードウェアから記述されたコードまで、すべてのツールをマスターすれば可能になると思いますが...）。静的割り当てではこの問題は発生しません。そのため、このような環境では現時点ではC++が使用されていませんでした。（それは約15年前でした、それは変わったかもしれません...）
実際には、決定論的なものがあることを保証する多くの構造体プールと割り当て関数を作成する必要があります。あなたは多くの解決策を想像することができます。重要なのは、（大量のテストを使用して）高レベルの決定論的動作を証明する必要があるということです。手作りの開発が決定論的に機能することを証明する方が、linux+gccがメモリの割り当てにおいて決定論的であることを証明する方が簡単です。
ちょうど私の2セント。かなり前のことですが、状況は変わったかもしれませんが、DO-178Bのような認証に関しては、どのような状況でもいつでもアプリが同じように機能することを証明することが重要です。
免責事項：私はDO-178bを特に使用したことはありませんが、認定システム用のソフトウェアを作成しました。
私が開発者である認定システムでは、...
これにより、次のオプションが残りました...
私たちの会社は、構造物のプールを見つけて、プールから取得/解放/プールに戻すことが最も有用であることがわかりました。モデルを維持し、最小限の問題で物事を決定論的に保つことができました。
お役に立てば幸いです。
リアルタイムで長時間実行されるミッションクリティカルなシステムは、メモリを動的に割り当ててヒープから解放するべきではありません。必要であり、それを中心に設計できない場合は、独自の割り当てられた固定プール管理スキームを作成します。はい、可能な限り事前に固定で割り当てられます。他の何かが最終的なトラブルを求めています。
スタックからすべてを割り当てることは、通常、組み込みシステムまたは割り当てが失敗する可能性が許容できない他の場所で行われます。DO-178bが何であるかはわかりませんが、mallocがプラットフォームで使用できないことが問題である場合は、それを自分で実装することもできます（独自のヒープを実装する）が、実行時に割り当てが失敗する可能性がありますもちろん、スペースが足りません。
100％確実にする方法はありません。
FreeRTOSのメモリアロケータの例をご覧ください。私が間違っていなければ、それらは静的プールを使用します。