組込みLinux と RTOS の使い分け

「速さ」ではなく「間に合うか」で選ぶ

組込みでLinuxとRTOSのどちらを選ぶかは、性能の優劣ではなく何を保証したいかの問題です。モーターの電流制御ループを 20kHz（50μs 周期）で回すとき、平均が速くても 1 周期でも取りこぼせば波形が崩れます。逆にタッチパネルの描画や TLS 通信では、数十ミリ秒の揺らぎは誰も気づきません。前者が要求するのは決定性（determinism）——最悪ケースの応答時間が有界であること——であり、後者が要求するのは開発生産性と機能性です。この 2 つの軸で切り分けると、選定は自然に定まります。

決定性の核心は WCET（Worst-Case Execution Time、最悪実行時間）と割込み応答遅延（interrupt latency）です。RTOS はこれらを小さく有界に保つよう設計され、汎用 OS である Linux は平均スループットと公平性を優先します。この設計思想の差が、以下すべての違いを生みます。

RTOS：割込み応答を有界化する薄い層

RTOS（Real-Time Operating System）は、優先度ベースの完全プリエンプティブなスケジューラを核に持つ、数 KB〜数十 KB 規模のカーネルです。FreeRTOS・Zephyr・µC/OS・VxWorks などが代表です。決定性を生む仕組みは 3 点に集約されます。

• 固定優先度プリエンプション：常に「実行可能な最高優先度タスク」を走らせます。高優先度タスクが起きた瞬間、実行中の低優先度タスクを即座に退避します（詳細な原理は /os/ のリアルタイムスケジューリングに通じます）。
• 有界な割込み応答：割込み禁止区間（critical section）を極小に抑え、ISR から高優先度タスクへの復帰までのパスを最短化します。ハンドラで重い処理をせず、遅延処理はタスクへ委譲する「トップ半分／ボトム半分」の徹底です。
• 決定的なカーネルサービス：ミューテックス・セマフォ・キューの操作を定数時間 O(1) で実装し、優先度継承で優先度逆転を有界化します。動的メモリ確保を避け静的割当を推奨するのも、確保時間のばらつきを排すためです。

MMU（メモリ管理ユニット）を前提としないため、Cortex-M のようなフラッシュ実行・SRAM 数十 KB のマイコンでも動きます。多くの RTOS はカーネルとアプリを単一アドレス空間・特権モードでリンクするため、システムコールの境界越えがなく関数呼び出し同然に軽い一方、1 つのタスクの暴走がシステム全体を壊し得るという裏返しの弱さも持ちます。

組込みLinux：分離と機能性を持つ重い基盤

組込み Linux は、MMU による仮想メモリとプロセス分離、プリエンプティブなマルチタスク、そして膨大なデバイスドライバ・ファイルシステム・TCP/IP スタック・言語ランタイムを持つ汎用カーネルです。ARM Cortex-A や x86 のように MMU を備えた SoC が前提で、必要リソースは桁が変わります。

Linux が既定で締め切りを保証できない理由は構造的です。カーネル内に長い割込み禁止区間やプリエンプト不可区間が点在し、デマンドページングによるページフォルトやページキャッシュの writeback、周期タイマの粒度などが、いつ実行が中断されるか予測不能にします。PREEMPT_RT パッチ（現在は主流カーネルへ統合が進む）はスピンロックを睡眠可能ミューテックスへ置換し割込みハンドラをスレッド化して、この非決定性を大幅に削ります。それでも最悪応答は RTOS より一桁大きい数十〜数百μs 級にとどまるのが実情で、SCHED_FIFO / SCHED_DEADLINE を使っても物理限界は残ります。

使い分けの判断軸

選定は次の順で問うと明快です。第一に締め切りの硬さ。1 回でも逃すと機能が破綻する（ハードリアルタイム：モーター制御、パワエレのゲート駆動、エアバッグ、ABS）なら RTOS か専用ロジックへ。時々の遅延を許容できる（ソフトリアルタイム：動画再生、計装 UI）なら Linux が候補です。第二にリソースと BOM。SRAM 数十 KB・電池駆動・低コスト MCU なら RTOS 一択、外部 DRAM を積める SoC なら Linux が現実的です。第三に機能要件。Wi-Fi/Ethernet・TLS・Web UI・OTA 更新・複数言語ランタイムが要るなら Linux の既製資産が圧倒的に有利です。

両取りする：AMP とコプロセッサ分離

現実の製品は「決定性」と「機能性」の両方を要求します。そこで定石となるのが、両者を物理的・論理的に分離して同居させる構成です。代表が **AMP（Asymmetric Multi-Processing、非対称マルチプロセッシング）**で、1 つの SoC 内の異種コアに別々の OS を載せます。

[ SoC ]
  Cortex-A コア群 ──▶ 組込み Linux
    └ UI / ネットワーク / OTA 更新 / ログ / クラウド連携
  Cortex-M コア     ──▶ RTOS（またはベアメタル）
    └ 20kHz 制御ループ / センサ取得 / ゲート駆動 / セーフティ
        ▲
        │ 共有メモリ + メールボックス（例: OpenAMP / RPMsg）

STMicro STM32MP1 や NXP i.MX8 のような「Cortex-A ＋ Cortex-M」ヘテロジニアス SoC がこの形を狙った製品です。締め切り厳守のタスクは Cortex-M 上の RTOS（あるいはベアメタル）へ隔離し、リッチな機能は Cortex-A 上の Linux へ寄せ、両者を共有メモリと割込みベースのメッセージング（OpenAMP / RPMsg など）で疎結合に繋ぎます。Linux が再起動・更新中でも制御コアは走り続けられるのが安全上の利点です。

同じ発想は、Linux ホストに独立した MCU（コプロセッサ）を SPI/UART で外付けする「コプロセッサ分離」でも実現できます。モータードライバやセンサ前処理（/dsp-control/ のフィルタや PID を含む）を MCU 側で閉じ、Linux はコマンドとデータの受け渡しに徹します。分離の境界は結局、「締め切りを守らねばならない範囲」をどこまで小さく囲えるかで決まります。

まとめると、RTOS と組込み Linux は競合ではなく役割分担です。μs 級の締め切りと極小フットプリントには RTOS、豊富な機能と開発生産性には Linux、そして両方が要るなら AMP やコプロセッサ分離で決定性の領域を隔離する——この三択で、組込みシステムの多くの要求は原理的にカバーできます。