概要
RTOS(Real-Time Operating System:リアルタイムOS)は、処理の応答時間を厳密に保証するよう設計された組み込みシステム向けのオペレーティングシステムです。一般的なOS(WindowsやLinuxなど)が「平均的なスループット」を重視するのに対し、RTOSは「最悪の場合でも決まった時間内に処理が完了すること」を最優先に設計されています。
組み込み機器では、センサーデータの取得・モーター制御・通信プロトコルの処理など、時間的制約を持つ複数の処理を並行して行う必要があります。こうした要件に応えるのがRTOSの役割です。
ベアメタル(OSなし)と組み込みLinuxの中間的な存在として、RTOSはリソースが限られたマイコンでも動作しながら、複数タスクの時間管理と優先度ベースのスケジューリングを提供します。
歴史・背景
リアルタイムOSの概念は1960〜70年代、工場の制御システムや航空機の組み込み計算機から生まれました。当時はハードウェアとソフトウェアが密接に絡み合い、OSと呼べるほどの抽象化はありませんでしたが、割り込み駆動の処理ループが原型となっています。
1980年代には、iRMX(Intel)やOS-9、pSOSなど商用RTOSが登場し、産業・航空宇宙・軍事分野で採用が進みました。1990年代にはQNX・VxWorks・Nucleus RTOSが台頭し、車載・医療・通信インフラ向けに広がりました。
日本では1990年代にITRON仕様が策定され、国産マイコンとの親和性から家電・産業機器に広く普及しました。2000年代以降はオープンソースのFreeRTOSが普及し、2010年代後半にはZephyrがLinux Foundationのもとで開発されました。2023年時点ではFreeRTOSが圧倒的なシェアを持ちながらも、Zephyrがエッジ・IoT分野で急速に存在感を増しています。
技術仕様
リアルタイム性の分類
RTOSが保証するリアルタイム性には以下の区分があります:
| 分類 | 説明 | 超過時の影響 | 用途例 |
|---|---|---|---|
| ハードリアルタイム | デッドラインの厳守が必須 | システム障害・安全問題 | 航空制御・エンジンECU・産業ロボット |
| ソフトリアルタイム | デッドラインを多少超えても許容 | 品質低下・遅延増加 | 動画再生・音声処理 |
| ファームリアルタイム | 超過は許容されるが超過率を制限 | サービス品質低下 | IoTデータ収集 |
スケジューリングアルゴリズム
RTOSのスケジューラは、どのタスクをいつ実行するかを決定します。主なアルゴリズム:
- 固定優先度プリエンプティブ(Fixed Priority Preemptive): 最も一般的。高優先度タスクが低優先度タスクを横取りして実行。FreeRTOS・Zephyr・ITRONが採用。
- Rate Monotonic Scheduling(RMS): 周期が短いタスクに高優先度を割り当てるアルゴリズム。理論的に最適な固定優先度方式。
- Earliest Deadline First(EDF): デッドラインが最も近いタスクを最優先で実行する動的優先度方式。
- ラウンドロビン(Round-Robin): 同優先度タスクを順番に時分割実行。
コアコンポーネント
RTOS の主要コンポーネント:
┌─────────────────────────────────────┐
│ Application Tasks │
├─────────────────────────────────────┤
│ RTOS API(タスク・同期・通信) │
├──────────┬──────────┬───────────────┤
│Scheduler │IPC/Sync │Memory Manager │
│スケジューラ│セマフォ/ │メモリ管理 │
│ │キュー/ミューテックス│ │
├──────────┴──────────┴───────────────┤
│ Hardware Abstraction Layer │
├─────────────────────────────────────┤
│ Interrupt Controller / Hardware │
└─────────────────────────────────────┘
代表的RTOSの比較
| RTOS | ライセンス | 最小フットプリント | 主な対象 |
|---|---|---|---|
| FreeRTOS | MIT | 約6KB ROM / 4KB RAM | MCU全般 |
| Zephyr | Apache 2.0 | 約8KB ROM / 4KB RAM | IoT・エッジ |
| TOPPERS/ASP3 | TOPPERS | 数十KB | 国内産業・車載 |
| VxWorks | 商用 | 数MB〜 | 航空・軍事・産業 |
| QNX | 商用 | 数MB〜 | 車載・医療 |
| Mbed OS | Apache 2.0 | 〜50KB | ARM Cortex-M |
| RT-Thread | Apache 2.0 | 約2.5KB ROM | 中国発・IoT |
動作原理
タスク管理とコンテキストスイッチ
RTOSはアプリケーションを複数の「タスク(スレッド)」に分割して管理します。各タスクはCPUレジスタ・スタックポインタ・プログラムカウンタなどのコンテキストを持ち、コンテキストスイッチで実行タスクを切り替えます。
/* FreeRTOS タスク生成例 */
void sensorTask(void *pvParameters) {
for (;;) {
// センサーデータ取得
int16_t temp = readTemperature();
// キューへ送信
xQueueSend(dataQueue, &temp, portMAX_DELAY);
// 100ms 周期で実行
vTaskDelay(pdMS_TO_TICKS(100));
}
}
void app_main(void) {
dataQueue = xQueueCreate(10, sizeof(int16_t));
xTaskCreate(sensorTask, "Sensor", 2048, NULL, 2, NULL);
xTaskCreate(commTask, "Comm", 4096, NULL, 1, NULL);
vTaskStartScheduler();
}
割り込みとタスクの協調
割り込み(ISR)はRTOS管理外で実行される最高優先度の処理です。ISR内でキューやセマフォを操作する場合は、専用のISRセーフAPIを使います。
/* ISR からキューへ送信(FreeRTOS例) */
void UART_IRQHandler(void) {
uint8_t data = UART->DR;
BaseType_t xHigherPriorityTaskWoken = pdFALSE;
xQueueSendFromISR(uartQueue, &data, &xHigherPriorityTaskWoken);
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}
スケジューラのティック
RTOSは通常、一定周期のタイマー割り込み(ティック)でスケジューラを動作させます。FreeRTOSのデフォルトは1000Hz(1msティック)ですが、省電力のために100Hzに落とすケースもあります。
用途・ユースケース
産業・製造
工場の PLCやロボットアームでは、制御ループの周期性(例:1ms以内のモーター制御)が保証される必要があり、RTOSが不可欠です。QNXやVxWorksが長年使われており、近年ではZephyrも採用が進んでいます。
車載システム
エンジン制御(ECU)・ABS・エアバッグ制御など、機能安全(ISO 26262)が求められる分野では、AUTOSAR対応RTOSや認定済みVxWorksが使われます。
医療機器
輸液ポンプ・人工呼吸器などでは、IEC 62304(医療機器ソフトウェア規格)への適合が必要です。QNXやVxWorksが採用される一方、FreeRTOSもIEC 62443認定版が提供されています。
IoT・エッジ
消費電力を抑えながら通信・センシングを周期的に行うIoTデバイスでは、FreeRTOSまたはZephyrが使われます。スリープ管理・OTA更新との連携が重要です。
通信インフラ
ルーター・スイッチの制御プレーンでは、パケット処理の厳密な遅延制御のためにRTOSが活用されます。
実装・開発のポイント
タスク設計の原則
- タスクは1つの役割に集中させる: センサータスク・通信タスク・制御タスクに分割
- スタックサイズを適切に設定: 不足するとスタックオーバーフロー。FreeRTOSは
uxTaskGetStackHighWaterMark()で残量確認が可能 - 優先度設計: 時間制約の厳しいタスクほど高優先度。ただし高優先度タスクが長時間実行すると低優先度タスクが飢餓(スタベーション)状態になる
同期・通信メカニズムの選択
タスク間通信の使い分け:
・キュー(Queue) : データを安全に受け渡す。生産者-消費者パターン
・セマフォ(Semaphore): イベント通知・リソースカウント管理
・ミューテックス(Mutex): 共有リソースの排他制御(優先度継承付き)
・イベントグループ : 複数イベントの待ち合わせ
・ストリームバッファ : バイトストリームの効率的な転送(FreeRTOS 10以降)
優先度逆転への対策
優先度逆転は、低優先度タスクが共有リソースを占有して高優先度タスクをブロックする問題です。ミューテックスに優先度継承機能を持つものを使うことで軽減できます。
デッドロックの回避
デッドロックはタスクが互いにリソースを待ち合って永久にブロックする状態です。ロック取得の順序を統一し、タイムアウト付きロック取得を使うことで回避します。
他技術との比較
RTOS vs ベアメタル
ベアメタルはスーパーループ(while(1))で全処理を行います。シンプルで決定論的ですが、処理が増えると管理が困難になります。
| 項目 | RTOS | ベアメタル |
|---|---|---|
| 複数タスク管理 | 優先度スケジューラで自動管理 | 手動ステートマシン |
| 応答性 | 高優先度タスクが即時実行 | ループ全体が回るまで待機 |
| ROM/RAM消費 | 数KB〜数十KB追加で必要 | 最小限 |
| デバッグ難易度 | タスク・キュー状態を把握する必要あり | シンプル |
| 開発効率 | 高い(タスク分割しやすい) | 処理が増えると低下 |
RTOS vs 組み込みLinux
組み込みLinuxは多機能なMMU付きのフルOSで、RTOSよりはるかに多くのリソースを必要とします。RTOSはメモリ数百KB以下のMCU向け、組み込みLinuxは数十MB以上のMPU向けというのが基本的な棲み分けです。
| 項目 | RTOS | 組み込みLinux |
|---|---|---|
| 最小RAM | 4KB〜 | 数十MB〜 |
| 起動時間 | ミリ秒〜 | 数秒〜 |
| リアルタイム性 | 保証あり | PREEMPT_RTでも限定的 |
| ソフトウェア資産 | 限定的 | 豊富(npm, Python等) |
| 対象SoC | MCU中心 | MPU・高性能SoC |