組込みOS・RTOSの最適な選び方を徹底解説！おすすめの製品も紹介

選び方に入る前に、組込みOS・RTOSが何を担うソフトウェアなのかを押さえます。ここが曖昧なままだと、必要のない機能に費用を払うことになりかねません。3点に絞って確認しましょう。

組込みOS・RTOSが担う役割

組込みOS・RTOSは、機器に内蔵されたマイコン上で動くソフトウェアの基盤です。タスクの切り替え、割り込みへの応答、メモリの管理を担います。

適用先は産業機器の制御、車載ECU、医療機器、IoTエッジ機器などです。複数の処理を並行して動かしつつ、決められた時間内に確実に終わらせる役目を負います。制御の締切を守れるかどうかが、機器の安全性と品質を直接左右するでしょう。機能安全規格の認証を取得した製品も増えています。

汎用OSとの違い

RTOSは、処理が決められた時間内に終わることを保証する点で汎用OSと違います。汎用OSは平均的な処理量を優先し、応答時間の上限までは約束しません。

RTOSでは割り込み遅延が確定的で、優先度の高いタスクから先に実行されます。カーネルも小さく、限られたメモリのマイコンで動く製品が多くあります。安価なマイコンに載せられる点が、機器への組込みで選ばれる理由です。対応するCPUアーキテクチャの幅は製品ごとに違い、確認が要ります。用語の基礎は組込みOS・RTOSの解説記事で扱っています。

選定でつまずきやすい理由

製品数が多く、カタログ上の機能一覧を並べても差が読み取りにくい分野です。どの軸から評価すればよいかを整理しないまま、比較を始めてしまうケースが見られます。

実際に差が出るのは、応答時間の保証、認証の成果物、量産後の保守責任といった運用面です。いずれもカタログには載りにくい条件といえるでしょう。だからこそ、軸を先に決めてから製品を見る順序が要ります。無料のOSSで始めて認証に詰まる例も、その延長線上で起きています。

編集部コメント：製品を先に見ると、対応機能の多さで判断してしまいがちです。自社の機器が何ミリ秒で応答する必要があり、どの規制の下で売るのかを先に書き出してみてください。それだけで必要な条件が絞り込まれます。

組込みOS・RTOSは、提供形態によって3つに分かれます。この分類を把握しておくと、候補を比較しやすくなります。まず全体像をつかみましょう。

• 商用RTOS
• オープンソースRTOS
• 国産の商用RTOS

商用RTOS

ベンダーが保守と品質保証を担うRTOSです。ライセンス費に加え、量産1台ごとのロイヤリティが発生する形が一般的です。

機能安全認証に対応した版を、別構成で用意する製品が多くあります。安全マニュアルやテスト証跡の提供も受けられます。広範なCPUに対応し、開発環境やミドルウェアも一式でそろう傾向です。高信頼が求められ、ライフサイクルの長い機器に向きます。一方で小型・低価格の機器には費用が重くなりがちでしょう。

オープンソースRTOS

ライセンス費なしで商用製品にも組み込めるRTOSです。MITライセンスやTOPPERSライセンスなど、商用利用を認める条件で公開されています。

導入の障壁が低く、評価を始めるまでの手間がかかりません。対応アーキテクチャが広い製品もあり、試作段階から使いやすい選択肢になります。ただし品質保証や不具合対応は、基本的に利用側の責任です。機能安全認証が要る場合は、成果物を自社または委託で整える負担が残ります。

国産の商用RTOS

日本のベンダーが開発し、日本語のドキュメントと窓口を備えるRTOSです。商用の安心感と、扱いやすさを両立させた位置づけになります。

省メモリ設計の製品が多く、安価なマイコンにも載せやすい構成です。TCP/IPスタックやファイルシステムといったミドルウェアと組み合わせて使えます。価格の目安を公開している製品もあり、見積もりを立てやすい点も利点でしょう。大規模・高機能な用途では機能が限られる場合があります。

同じ組込みOS・RTOSでも、何をしたいかで優先すべき条件が変わります。製造業でよくある3つの目的を取り上げました。自社に近いものから読んでください。

機能安全認証を取得したい

認証に対応した版を持つ商用RTOSから検討すると進めやすいでしょう。IEC 61508やISO 26262などの規格への適合が前提になるためです。医療機器ならIEC 62304、航空ならDO-178Cが代表的な規格になります。

見るべきは、OS自体の認証実績と、安全マニュアルやテスト証跡の提供範囲です。認証版は通常版と別ライセンス・別構成になる点も確認しましょう。認証は機器全体で取得するもので、OSは構成要素のひとつにすぎません。自社側の開発プロセス整備の工数も、あわせて見込んでおきます。

厳密な応答時間を保証したい

ハードリアルタイム性を保証できるRTOSに絞ります。締切を1回でも超えると重大な結果を招く制御では、応答時間の上限が確定している必要があるためです。

モーター制御、ブレーキ、医療機器の動作などがこれにあたります。割り込みの応答が確定的でないOSでは、まれな遅延が事故につながります。割り込み遅延が確定的か、障害をプロセス単位で隔離できる構造かが確認のポイントです。表示更新やデータ収集のように数十ミリ秒の遅れを許せる用途なら、ここまでの水準は要りません。

ネット接続機器を低コストで開発したい

まずは、ライセンス費のかからないOSSから検討するとよいでしょう。ソフトリアルタイムで足りる用途では、商用RTOSの保証が過剰になりやすいためです。

対応アーキテクチャの広さと、クラウド連携の仕組みがそろっているかを見ます。クラウド側の機能でセキュリティを補える構成なら、自前実装を減らせます。あわせて設計すべきなのが、出荷後のセキュリティ運用です。脆弱性が公表されたときに誰がパッチを当て、出荷済み機器をどう更新するかを決めておきましょう。後から体制を作るのは難しくなります。

OSに求める条件は、使う部門によっても異なります。組込みOS・RTOSに関わる3つの部門で整理しました。複数部門で共有する場合は、条件の厳しいほうに合わせます。

組込みソフト開発部門

日々コードを書き、実機で動かす部門です。開発環境とミドルウェアの充実度が、そのまま工数に響いてきます。

IDEとデバッガの使い勝手、TCP/IPスタックやファイルシステムの標準提供範囲も確認しましょう。採用予定マイコンへの対応も、この部門が見る条件です。将来の派生機種で使うマイコンまで含めて洗い出すと、機種ごとにOSを変える手間を避けられます。評価ボードで実際に動かし、デバッグのしやすさを確かめてください。

品質保証部門

認証と試験の証跡を扱う部門です。OSがどこまで成果物を提供するかで、自部門の作業量が大きく変わります。

安全マニュアル、テスト結果、変更履歴の提供範囲を選定段階で確認しておくと安心です。OSSを使う場合は、これらを自社で整えるか委託するかの判断が要ります。あわせて、応答時間の実測データをどの段階で誰が取るのかも決めておきましょう。後工程での差し戻しを防げます。認証は機器全体で取得するもので、OSは構成要素のひとつです。

保守・サービス部門

出荷後の機器を数年にわたり支える部門です。脆弱性と不具合への対応窓口が、判断の中心になります。

ベンダーのサポート期間と、脆弱性情報の告知の仕組みを確認してください。ファームウェア更新の手段が用意されているかも重要な条件です。OSSを採用するなら、パッチを適用する担当と更新の配信方法を設計に織り込みます。窓口が不在のまま量産に入ると、対応が滞りかねません。長期間ネットにつなぐ機器ほど、更新の仕組みが保守の負担に影響します。

企業規模そのものより、規模から来る制約が判断を分けます。専任担当の有無、量産台数、稟議の通し方の3点です。自社の体制に近いところを見てください。

中小企業

OSの保守を担う専任者がいない前提で選びます。不具合や脆弱性への対応を、開発担当者自身が抱えることになるためです。

日本語の窓口が近い製品が向いています。導入時の移植支援や技術サポートを受けられるかも、あわせて確認したい条件です。量産台数が少ないうちは、ロイヤリティより初期費用と保守費が総額を左右します。価格の目安が公開されている製品なら、予算の承認も得やすくなるでしょう。省メモリ設計の製品なら、安価なマイコンでも構成を組めます。

中堅企業

複数の製品ラインで同じOSを使えるかが課題になります。機種ごとにOSが分かれると、ノウハウも保守体制も分散するためです。

対応アーキテクチャの広さは、比較の早い段階で確かめておきましょう。現行機種だけでなく、将来の派生機種で使うマイコンまで含めて確認します。量産台数が増えるほどロイヤリティの影響が大きくなるため、台数を前提にした総額の試算が欠かせません。社内の開発標準を定めるのも、この規模からになります。派生カーネルや構成の選択肢が多い製品ほど、機種間の差を吸収できます。

大企業

認証と長期サポートの確実性が判断を左右します。参入する市場が広く、規制の要求も機種ごとに異なるためです。

比較では、認証対応版の有無とサポート期間の長さが主な軸になるでしょう。稟議では単価より、量産台数を踏まえた総額と移行コストが問われます。既存機種の資産や社内ツールとの連携範囲も確認が要ります。全社一斉ではなく、製品ライン単位で段階的に切り替える進め方が現実的でしょう。認証版は通常版と別ライセンスになるため、調達の手続きも早めに始めます。

目的・部門・規模で方向が見えたら、具体的な条件に落とし込みます。ここからは順番が大切です。上から順に確認すると、手戻りが減ります。

• 制御周期と許容ジッタを数値で書き出す
• 採用予定マイコンへの対応を確かめる
• 必要なミドルウェアと開発環境を洗い出す
• セキュリティと出荷後の更新方法を決める
• ライセンス形態と量産までの総額を出す

制御周期と許容ジッタを数値で書き出す

最初に決めるのは、リアルタイム性の水準です。感覚で決めず、制御周期と許容できる遅延を数値で書き出してください。

要求応答時間がマイクロ秒から数ミリ秒で、締切超過が許されないならハードリアルタイムです。数十ミリ秒以上の遅れを許せるならソフトリアルタイムと線を引きます。ここを厳しい側に倒しすぎると、費用が跳ね返ります。逆に甘く見積もると、量産直前で系統ごと乗り換える事態になりかねません。この数値は設計レビューや稟議の資料にもそのまま使えます。

採用予定マイコンへの対応を確かめる

次に、採用予定マイコンのアーキテクチャとメモリ容量への対応を確認します。カーネルはCPUアーキテクチャに強く依存し、未対応なら移植に大きな工数がかかるためです。

広く使われるアーキテクチャなら、ほとんどのRTOSが対応します。独自アーキや特殊なDSPでは、候補が限られます。メモリ制約が厳しい小規模マイコンでは、省メモリ設計の製品が現実解になるでしょう。将来の派生機種で使うマイコンまで含めて洗い出しておくと安心です。

必要なミドルウェアと開発環境を洗い出す

カーネル単体が動いても、製品にはなりません。IDE、デバッガ、TCP/IPスタック、ファイルシステム、USBスタックなどの周辺ソフトが要ります。

必要な周辺機能のうち、何が標準提供で何を自前実装または追加調達するかを一覧にしておきましょう。カーネルが無料でも、通信やセキュア機能を自前で整備する工数を積めば話が変わります。一式で提供される商用製品のほうが、総工数で安く収まる場合もあるでしょう。デバッガで解析しやすいかどうかも、開発期間を左右します。

セキュリティと出荷後の更新方法を決める

ネットワークに接続する機器では、セキュリティを選定段階で見ます。出荷後の数年間に脆弱性へどう対応し続けるかまでが判断の範囲です。

確認するのは、セキュア通信、安全なファームウェア更新の手段、脆弱性対応の窓口の3点です。障害や侵害を局所化できる構造かどうかも判断材料になります。OSSを選ぶ場合は、パッチの適用者と出荷済み機器の更新方法を自社で設計しなければなりません。更新の手段がない機器は、脆弱性が出ても手を打てなくなります。

ライセンス形態と量産までの総額を出す

最後に、単価ではなく総額で比べます。初期のライセンス費、量産1台ごとのロイヤリティ、年間の保守費、認証版の追加費用を積み上げてください。

OSSはライセンス費がかかりませんが、認証対応と脆弱性保守の人件費を別に見込む必要があります。量産台数とライフサイクルが長い製品では、商用製品のほうが総額で下回る場合もあるでしょう。想定台数を前提に試算してから、稟議の数字を組み立てます。サポート契約の期間と更新条件も、総額に含めて比べてください。

製品データとして数値化できる4項目を、製造業適合性スコアで横並びにしました。工程管理・品質管理・生産管理・中小適合の4つを5段階で評価しています。並びは中小適合の高い順です。下へ向かうほど、想定する企業規模と導入の重さが上がります。

スコアが「－」の製品は、機能がないという意味ではありません。評価の登録がない項目です。Nucleus RTOSは2023年11月に新規販売が終了しました。既存のサポート契約のみが継続しています。新規採用の候補からは外れるため、参考として掲載しました。製品ごとの詳しい比較は組込みソフトウェアの比較記事で扱っています。カテゴリー全体の製品一覧は組み込みソフトウェア（組込みOS・RTOS）から確認できます。

導入でつまずく開発現場には共通したパターンがあります。事前に知っておけば、設計レビューや稟議の段階で対策を示せるはずです。よくある4つを回避策とあわせて挙げます。

リアルタイム性を過小に見積もる

ソフトリアルタイムで足りると考え、軽量なOSを選んでしまうケースが見られます。実際にはハードリアルタイムが必要だった、という取り違えです。締切を守れず、量産直前で系統ごと乗り換える事態になります。

回避策：制御周期と許容ジッタを数値化してください。評価ボードに最も厳しい制御ロジックを実装し、応答時間と割り込み遅延の最悪値を実機で測ります。数字で確かめてから系統を確定すれば、後戻りを避けられます。

認証を後から付けようとする

認証は不要と判断し、無償のOSで開発を始める例があります。市場の要件で後から機能安全認証が必要になると、成果物が足りず再選定に追い込まれます。

回避策：製品が将来参入する市場の規制を、選定段階で確認してください。可能性があるなら、認証支援を受けられる製品を初めから候補に入れます。認証版は別構成になるため、切り替えの条件も先に聞いておきましょう。参入市場が後から広がる製品ほど、この見落としが重くなります。

総額の見落としで採算が崩れる

よくあるのが、ライセンス無料に着目してOSSを選び、周辺の費用がかさむ失敗です。認証対応、脆弱性保守、ミドルウェア整備の人件費が積み上がり、結果的に高くつきます。

回避策：ライセンス費だけでなく、保守・認証・ロイヤリティを含めた総額で比べてください。量産台数とライフサイクルを前提に試算します。数字を並べてから判断すれば、無料という額面に引きずられずに済みます。量産台数が増えるほど、ロイヤリティと人件費の差は開くでしょう。

サポート体制を軽く見る

保守の責任者を決めないまま量産に入ると、不具合や脆弱性が出た際に対応が滞ります。出荷済み機器の更新も進まず、市場での信用を損ないます。

回避策：商用製品ならサポート契約の範囲と窓口を、契約の段階で明確にしてください。OSSなら自社の保守体制と更新の仕組みを設計に織り込みます。誰がいつ対応するかを、量産前に文書で残しておきましょう。サポート期間が製品の寿命より短くないかも確かめてください。窓口の有無は、機器のライフサイクル全体の安心感を左右します。

組込みOS・RTOSの選定は、制御の締切と機能安全認証の要否から始まります。この2点で、商用とOSSのどちらが向くかを判断しやすいためです。種類は商用RTOS・オープンソースRTOS・国産の商用RTOSの3つに分かれます。

方向が定まったら、5つの条件を順に確認します。前半は制御周期の数値化、採用予定マイコンへの対応、開発環境とミドルウェアの3点です。後半でセキュリティと更新方法、量産までの総額を詰めます。失敗の型は、リアルタイム性の過小評価と認証の後付けが代表例です。

製品ごとの比較は組込みソフトウェアの比較記事で扱っています。費用は組込みOS・RTOSの費用の解説記事にまとめました。