リアルタイムオペレーティングシステム(RTOS)

1. 概要

A. 定義

リアルタイムOS(RTOS) とは、定められた時間(デッドライン)内に必ず応答するという時間制約(timing constraint)を守るよう設計されたオペレーティングシステムである。核心的価値は「どれだけ速いか(throughput)」ではなく「いつ終わるか予測できるか(determinism)」にある。

RTOSが登場した背景は組込み制御の本質にある。エアバッグ展開、モータ制御、航空機の飛行制御、産業用PLCのように物理世界とかみ合って動作するシステムでは、「平均的に速い応答」ではなく「最悪の場合でも定められた期限内に終わる応答」が安全に直結する。エアバッグが衝突後に平均10msで作動しても、まれに50msかかれば搭乗者は死亡しうる。汎用オペレーティングシステム(GPOS, General-Purpose OS)は全体のスループットと公平性を高めるよう設計され、応答時間の上限を保証できないため、こうした要求を満たすには決定性を第一目標とするRTOSが必要になった。

したがってRTOSを理解する出発点は「速さ」と「予測可能性」を区別することである。GPOSが統計的性能(平均遅延、スループット)を追求するのに対し、RTOSは遅延の上限(bounded latency) と最悪実行時間(WCET, Worst-Case Execution Time) を基準に設計・検証される。いくら平均性能が優れていても上限を保証できなければ、リアルタイムシステムとしては失敗である。

B. リアルタイム性の分類と特徴

RTOSが保証すべき「リアルタイム性」は、デッドラインを破ったときの結果によって三種類に分かれる。この区分は単なる分類ではなく、どの水準の検証・余裕(margin)に投資するかを決める設計基準となる。

区分	デッドライン違反時の結果	事例
ハード(Hard)	システム障害・人命被害	エアバッグ、航空飛行制御、原子炉制御
ファーム(Firm)	結果の価値喪失(危険ではない)	産業ビジョン検査、リアルタイム取引約定
ソフト(Soft)	品質低下(許容可能)	動画ストリーミング、VoIP

ハードリアルタイムはデッドライン違反がそのまま破局であるため100%のデッドライン遵守を数学的に証明(スケジューリング可能性分析)しなければならず、ソフトリアルタイムは間欠的な違反を品質低下として受け入れる。このためハードシステムほどWCET算定、キャッシュ・パイプラインの不確定性の除去、割込み遅延の上限保証に多くのコストをかける。遅延の揺らぎであるジッタ(jitter) をどれだけ抑えるかが、RTOS品質のもう一つの尺度である。

ここで注意すべきは、リアルタイム性が「絶対的に速くなければならない」を意味しないということである。デッドラインが1秒のシステムなら応答が0.9秒でも「リアルタイム」であり、デッドラインが1msなのに平均0.5msでも最悪が1.2msなら「非リアルタイム」である。つまりリアルタイムの基準は速度の絶対値ではなく、宣言されたデッドラインに対する相対的な保証の有無である。この視点の転換がRTOS設計・分析の出発点であり、試験答案でも「速いOS」と記述すれば核心を外したものとみなされる。

2. RTOSの核心概念と全体構造

RTOSの決定性はいくつかのメカニズムがかみ合って実現される。最も重要なのはプリエンプティブ優先度スケジューリング(preemptive priority scheduling) である。レディ(ready)状態のタスクのうち常に優先度が最も高いものを直ちに実行し、より高い優先度のタスクが起きると実行中のタスクを直ちにプリエンプトする。この規則が守られるかぎり、どのタスクがいつCPUを得るかを解析的に計算できる。

二つ目は高速で上限が保証された文脈切替(context switch)と割込み応答である。GPOSはスループットのために割込みを長く無効化することもあるが、RTOSは割込み無効区間を最小化しその上限を明示して、外部イベントに数マイクロ秒単位で反応する。三つ目は優先度逆転の防止である。共有資源を保護するミューテックスに優先度継承(Priority Inheritance)・上限(Priority Ceiling)プロトコルを適用し、低優先度タスクが高優先度タスクを無限に阻む現象を有界化する([[priority-inversion]]参照)。

graph TD
  subgraph APP["アプリケーション層"]
    T1["タスクA(高)"]
    T2["タスクB(中)"]
    T3["タスクC(低)"]
  end
  subgraph KERNEL["RTOSカーネル"]
    SCH["スケジューラ(プリエンプティブ優先度)"]
    IPC["IPC(セマフォ·キュー·ミューテックス)"]
    MEM["メモリ管理(固定ブロック)"]
    TMR["タイマ·ティックサービス"]
  end
  subgraph HW["ハードウェア"]
    CPU["CPU/MPU"]
    INT["割込みコントローラ"]
  end
  T1 --> SCH
  T2 --> SCH
  T3 --> SCH
  SCH --> CPU
  INT -->|ISR| SCH
  IPC --- SCH
  TMR --> SCH
  MEM --- CPU

上の構造図でアプリケーションタスクはカーネルのスケジューラを通じてのみCPUを割り当てられる。外部イベントは割込みコントローラを経てISR(Interrupt Service Routine)へ伝えられ、ISRは最小限の処理だけを行ったのちセマフォ·キューを通じて関連タスクを起こす遅延処理(deferred processing) の構造をとる。ISRの中ですべてを処理すると割込み無効区間が長くなり他のイベント応答が遅れるため、「短いISR+タスクへの委譲」がRTOS設計の定石である。

メモリ管理もGPOSとは異なる。汎用OSの可変サイズ動的割当(malloc)は断片化により割当時間がばらつき決定性を損なう。そこでRTOSは固定サイズのブロックプール(fixed-size memory pool) 方式で定数時間の割当を保証するか、そもそも動的割当を禁止(MISRA Cなどの安全コーディング規則)して静的割当のみを用いることもある。

結局、RTOSの決定性は「ある一つの秘訣」ではなく、複数の非決定性要因を一つずつ除去·有界化した結果である。スケジューリングの非決定性はプリエンプティブ優先度で、割込みの非決定性は無効区間の最小化で、メモリの非決定性は固定ブロックで、資源競合の非決定性は優先度継承でそれぞれ制御する。このうち一つでも崩れると全体の応答時間の上限が破れるため、RTOS設計は「最悪の場合」を最後まで追跡する保守的思考を要求する。

3. RTOSアーキテクチャと構成要素

RTOSカーネルはおおむねマイクロカーネル(microkernel) 指向である。スケジューリング·IPC·タイマなど最小機能だけをカーネルモードに置き、ファイルシステム·ネットワークスタックなどはユーザ空間のサーバやミドルウェアへ分離する。こうするとカーネルが小さく検証範囲が狭まり、安全認証(航空のDO-178C、自動車のISO 26262)を得るのに有利である。以下はタスクの状態遷移とカーネルサービスの関係を示す詳細図である。

stateDiagram-v2
  [*] --> Ready: 生成 create
  Ready --> Running: ディスパッチ 最高優先度
  Running --> Ready: プリエンプト preempt
  Running --> Blocked: 資源待ち P操作·遅延
  Blocked --> Ready: 資源返却 V操作·タイムアウト
  Running --> Suspended: 明示的中断
  Suspended --> Ready: 再開 resume
  Running --> [*]: 終了 delete

A. タスクとスケジューラ

タスク(またはスレッド)はRTOSの実行単位で、それぞれ優先度·スタック·文脈(レジスタ集合)をもつ。スケジューラは各スケジューリング時点(ティック割込み、ブロッキング呼出し、割込み復帰)ごとにレディキューから最高優先度のタスクを選びディスパッチする。同一優先度のタスクが複数あればラウンドロビン(time slicing)で公平に分けることもある。この状態遷移をO(1)の定数時間で行うため、ビットマップベースの優先度テーブルを用いるのがFreeRTOS·μC/OSなどの共通手法である。

B. タスク間通信·同期(IPC)

複数のタスクが協調するには、データをやり取りし実行順序を合わせる必要がある。RTOSはセマフォ(同期·資源カウント)、メッセージキュー(データ伝達)、ミューテックス(相互排除)、イベントフラグ(多条件待ち) を提供する。特にミューテックスは優先度継承を内蔵して優先度逆転を防ぐ。たとえばFreeRTOSのミューテックスは、取得した低優先度タスクが待機中の高優先度タスクの優先度を一時的に継承し、クリティカルセクションを速く抜けるようにする。

ここでセマフォとミューテックスを区別することが実務の落とし穴である。どちらも相互排除に使えるが、所有権(ownership) の概念が異なる。ミューテックスはロックしたタスクだけが解放できるため所有者を特定でき優先度継承が可能だが、二値セマフォはどのタスクでも返却でき所有者が分からないため継承をかけられない。そこで「資源保護にはミューテックス、イベント信号(ISR→タスク通知)にはセマフォ」という原則が立ち、これを混同してセマフォで資源を保護すると優先度逆転が再び開く欠陥を生む。

C. 時間管理と割込み

RTOSはシステムティック(system tick) タイマで時間を数える。ティックごとに遅延(delay)が満了したタスクを起こし、タイムスライスを更新する。ただしティック周波数が高すぎるとオーバヘッドが増え、低すぎると時間分解能が落ちるため、近年はティックが不要なときにタイマを止めるティックレス(tickless) モードで低消費電力と精度を両立する。割込み遅延(interrupt latency)とスケジューリング遅延の和であるタスク応答時間の上限を保証することが、カーネル設計の核心的目標である。

4. スケジューリング手法の比較

リアルタイムスケジューリングは優先度を「固定」するか「動的」に変えるかで分かれる。二つの代表アルゴリズムの違いは単なる実装の違いではなく、スケジューリング可能性(schedulability)の上限に由来する。

手法	優先度の付与	スケジューリング可能限界(単一CPU)	特徴
RMS(Rate Monotonic)	周期が短いほど高い(固定)	約69.3%(n→∞, `n(2^(1/n)-1)`)	静的·単純·予測しやすい
EDF(Earliest Deadline First)	デッドラインが迫るほど高い(動的)	100%	最適だがオーバラン時に連鎖崩壊

RMSは周期が短い(頻繁に実行される)タスクに高い優先度を固定付与する。実装が単純で分析が容易なため産業で広く使われるが、CPU利用率が理論上限(タスク数が多いほど約69.3%)を超えるとデッドラインを保証できない。すなわちCPUの約30%を「余裕」として空けておかねば安全でないという意味で、これはコストだが予測可能性という価値を買う代償である。

EDFはその瞬間にデッドラインが最も迫ったタスクへ最高優先度を動的に与える。単一プロセッサで利用率100%まですべてのデッドラインを守れる最適アルゴリズムだが、過負荷(overrun)が生じるとどのタスクが先にデッドラインを破るか予測しにくく、連鎖的デッドライン失敗(domino effect) の危険がある。そこで安全が重要なハードシステムは分析が明快なRMSを、利用率を絞り出すべきシステムはEDFを選ぶというようにトレードオフが分かれる。実際、自動車AUTOSARのOSは固定優先度プリエンプティブ方式を基本とし、RMS系の分析可能性を重視する。

A. RMSスケジューリング可能性 — 数値例

具体的に三つのタスクがあるとしよう。タスク1は周期50msに実行時間10ms、タスク2は周期100msに20ms、タスク3は周期200msに40msである。各タスクのCPU利用率は10/50=0.2、20/100=0.2、40/200=0.2で合計0.6である。RMSの利用率上限はタスク数3のとき3(2^(1/3)-1)≈0.78であるから、総利用率0.6は上限0.78より小さく、三つのタスクすべてがデッドラインを守れることが保証される。もしタスク3の実行時間を60msに増やして総利用率が0.7になっても依然として上限の下で安全だが、90ms(0.85)に増やすとLiu-Layland上限を超え、この簡単な判定だけでは保証できなくなり、精密な応答時間分析(RTA, Response-Time Analysis)が必要になる。このようにRMSは「計算で安全を証明」できる点が産業で好まれる理由である。

5. GPOSとの比較、そして適用事例

RTOSとGPOSの違いは「何を最適化するか」という設計目標の違いに由来する。以下の比較は単なる機能の羅列ではなく、なぜ一つのOSで二つの要求をともに満たしにくいかを示す。

観点	RTOS	GPOS(Linux·Windows)
第一目標	決定性(応答上限)	スループット·公平性
スケジューリング	プリエンプティブ優先度、上限保証	CFSなど公平性中心
カーネル遅延	数μs、上限明示	数ms、非決定的
メモリ	固定ブロック·静的割当	仮想メモリ·ページング
規模	数KB~数百KB	数十MB以上

一つのOSで二つの要求をともに満たしにくい根本理由は、最適化対象が相反するからである。スループットと公平性を高めるにはスケジューラはキャッシュヒットを狙って実行順序を並べ替え、割込みをまとめて処理し、遅延書込み(write-back)でI/Oを集めるが、これらの手法はすべて「平均」を良くする代わりに「最悪」を予測不能にする。逆にRTOSは最悪を有界化するために平均性能を一部犠牲にする。そこで伝統的には役割を分けて別々のOSを使い、近年になってマルチコアとハイパーバイザで一つのチップに両者を共存させる手法が現実化している。

実際の事例を見ると設計目標の違いが明確になる。第一に、自動車の電子制御装置(ECU) はエンジン·制動制御にOSEK/VDXベースのAUTOSAR Classic OSを使う。エンジン噴射タイミングはクランク角に応じて数百μs単位で制御されねばならないため、平均性能がいくら良くても上限が保証されないGPOSでは不可能である。第二に、火星探査ローバはWind RiverのVxWorksを搭載してきたが、1997年のマーズ·パスファインダの再起動障害が優先度逆転によるもので、優先度継承を遠隔パッチして解決した逸話はRTOS設計の教科書的事例として残っている。第三に、小型IoT·ウェアラブルは数KBのRAMで動くFreeRTOS(2017年にAWSが買収)やZephyrを使い、ミリワット単位の電力でセンササンプリングと無線通信のタイミングを合わせる。

6. 深化 — 最新動向と混合クリティカリティ

近年のRTOS領域における最大の変化は、汎用OSとリアルタイム性の境界が崩れつつあるという点である。LinuxのリアルタイムパッチであるPREEMPT_RTが長い外部パッチ期間を経て、2024年のLinux 6.12カーネルにかなりの部分がメインラインへ統合され、Linuxでも限定的なハードリアルタイムに近い応答が得られるようになった。これは一つのSoCでリッチなアプリケーション(Linux)とリアルタイム制御をともに動かそうとする産業·ロボットの需要を反映する。

ただしPREEMPT_RTがすべてのハードリアルタイムを置き換えるわけではない。Linuxは依然としてカーネル規模が大きく、仮想メモリ·キャッシュの非決定性を完全には除去しにくいため、マイクロ秒単位の厳格なデッドラインがかかる制御ループには専用RTOSや別コアが併用される。つまり「LinuxがRTOSを置き換える」のではなく、緩いリアルタイムはLinuxが吸収し厳格なリアルタイムはRTOSが担う役割分担の再編として理解するのが正確である。

これとかみ合って混合クリティカリティ(Mixed-Criticality)システムが台頭する。一つのマルチコアチップで安全等級の異なる機能(例:自動運転の安全制御とインフォテインメント)をともに動かしつつ、ハイパーバイザ(例:Xen、PikeOS、QNX Hypervisor)でコア·メモリ·周辺装置を隔離し、低等級機能の誤作動が高等級機能のタイミングを侵さないようにする。このときキャッシュ·メモリ帯域のような共有資源の干渉(interference)をどう有界化するかが分析の難題として残る。

標準·エコシステムの面では、Linux FoundationのZephyr Projectが数百のボードを支援しオープンソースRTOSの事実上の標準へ成長しており、産業ネットワークの決定性を保証するTSN(Time-Sensitive Networking) とRTOSが結合し「チップからネットワークまで」端から端までのリアルタイム性を追求する方向が鮮明である。予想される出題方向としては、①ハード/ソフトの区分とスケジューリング可能性分析(RMS利用率限界の計算)、②優先度逆転と継承·上限プロトコル、③混合クリティカリティ·ハイパーバイザ隔離、④RTOS対GPOS(PREEMPT_RTを含む)比較が結合して出ることが多い。

7. 考慮事項および示唆点

技術士の観点でRTOSの導入·設計時には次を総合的に考慮せねばならない。

適用戦略(要求等級の整合):すべての機能をハードとして設計すると過度な余裕とコストがかかる。機能ごとにハード/ファーム/ソフトを区分し、ハード経路にのみWCET分析と余裕CPUを集中投入するクリティカリティに基づく資源配分がコスト対効果に優れる。
トレードオフ(利用率対予測性):RMSはCPUの約30%を空ける代わりに分析が明快で、EDFは利用率を100%まで使うが過負荷時に崩壊の危険を負う。システムの安全等級と負荷特性に合わせて選び、過負荷処理(デッドライン未遵守時の性能低下モード)をともに設計せねばならない。
検証·認証の観点:ハードシステムではWCET算定の信頼性が全体の安全の土台である。キャッシュ·分岐予測·マルチコア干渉はWCET算定を困難にするため、安全認証(DO-178C、ISO 26262)では決定性を損なうハードウェア機能を無効化するか、その影響を保守的に上限処理する設計が要求される。
展望·連携技術:PREEMPT_RTのメインライン化とマルチコアハイパーバイザにより「RTOSとGPOSの統合」が加速している。TSN·エッジAI·機能安全(ISO 26262)·[[priority-inversion]]·[[race-condition]]などと連携し、端から端までの決定性を保証するアーキテクチャ設計の力がますます重要になる。

参考資料

FreeRTOS Documentation, https://www.freertos.org/features.html
Zephyr Project (Linux Foundation), https://www.zephyrproject.org/
Linux 6.12 release notes (PREEMPT_RT), https://kernelnewbies.org/Linux_6.12
Liu & Layland, "Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment", https://dl.acm.org/doi/10.1145/321738.321743

一言まとめ: RTOSはスループットではなくデッドライン内の応答を保証する決定性を第一目標とし、プリエンプティブ優先度スケジューリング·上限保証割込み·優先度継承/上限·固定ブロックメモリで予測可能性を実現し、RMS(分析容易·利用率69.3%)とEDF(最適·100%)のトレードオフの上でハード/ソフト要求に合わせて設計し、PREEMPT_RT·混合クリティカリティ·TSNによってGPOSとの境界が崩れる方向へ進化している。