組込みRTOSの選び方

まず、RTOS を入れない選択肢を検討してください。処理が周期タスク数本で完結し、割込みハンドラとスーパーループで表現できるなら、RTOS を入れないほうが解析もテストも容易です。RTOS が効いてくるのは、優先度の異なる処理が同居し、それぞれに応答期限がある場合です。

判断の目安は、「処理間の優先関係を、自前のステートマシンで表現し続けられるか」です。ここが破綻し始めたらスケジューラを導入する時期です。逆に、RTOS を入れるとコンテキストスイッチ・スタック多重化・同期プリミティブの分だけ RAM と解析対象が増えます。

適用する規格と水準（IEC 61508 の SIL、ISO 26262 の ASIL、IEC 62304 のソフトウェア安全クラス、EN 50128 の SIL）は、アーキテクチャを決める前に確定させてください。認証済みカーネルの価値は、コードの品質そのものより付属する成果物にあります。

認証で工数を消費するのは、要求仕様・設計文書・検証記録・トレーサビリティの整備です。事前認証済みカーネルは、この部分を Design Assurance Pack などの形で提供します。自前で同等のものを作る工数と、その提供価格を比較するのが正しい検討順序です。

認証済みカーネルには必ず使用条件（Safety Manual）が付きます。使ってよい API、割込み優先度の扱い、禁止される構成、アプリ側で実施すべき検証が列挙されており、これを外れると認証の前提が崩れます。評価の初期段階で入手して、自社の設計方針と矛盾しないか確認してください。

安全機能と非安全機能を同一プロセッサに同居させるなら、Freedom from Interference（干渉排除）の論証が必要になります。論証すべき方向は、メモリ・実行時間・情報交換の3つです。

メモリは MPU/MMU によるパーティション分離で示します。実行時間は、低優先度の処理が高優先度の期限を侵さないことを、スケジューリング解析または実測トレースで示します。情報交換は、定義された経路以外でデータが流れないことを設計で保証します。

この3点をどう論証するかは、カーネル選定と同時に決めてください。後から「トレースが取れないので余裕度を示せない」となると、基板のトレースポートまで遡ることになります。

同じ機能でも、ライセンス形態で総額が桁違いになります。主に次の軸で整理してください。

ソース提供かバイナリか（認証・監査が絡むならソースと設計文書が必要になる）、ランタイムライセンスの有無（量産数量が増えたときの総額を左右する）、ライセンス単位（開発者単位／製品単位／サイト単位）、サポート期間と更新条件（10年保守する製品では供給継続性そのものが要件）。

オープンソースのカーネルを使う場合も、ライセンス条項の遵守と、「誰が長期サポートするのか」を決めておく必要があります。商用ライセンス版を選ぶ理由の多くは、機能差ではなくこの2点です。

対応コアの一覧に載っていても、そのコンパイラ・その割込みコントローラ構成でのポートが存在するとは限りません。コア・コンパイラ・BSP の3点セットで確認してください。

また、カーネル単体が動いても、TCP/IP・ファイルシステム・USB・GUI を別ベンダーで揃えると、統合と検証で工数が膨らみます。同一ベンダーで揃えるか、OS 非依存のものを選ぶか、混在させるなら検証工数を見積もっておくか、いずれかを最初に決めてください。