3.1RTOSの役割とタスク状態遷移

汎用OSが「平均的なスループット」を最適化するのに対し、RTOS（Real-Time OS）は「最悪実行時間でも締め切りを守れるか」を最優先に設計されています。組込み設計者にとって重要なのは、RTOSが速いかどうかではなく、予測可能（deterministic）にタスクを切り替えられるかという一点です。この節ではRTOSの中核であるカーネルの役割と、タスクがどのような状態を遷移するかを、実際の採否判断とあわせて学びます。

3.1.1カーネルの役割

• カーネル＝RTOSの中核部分で、タスク管理（生成/削除/状態遷移）・スケジューリング（次にCPUを渡すタスクの決定）・割込み処理・タスク間の同期・通信（セマフォ/メッセージキュー等）・時間管理（タイマ/遅延）を提供する。
• RTOSカーネルが汎用OSカーネルと最も異なるのは、割込みからタスク起床までの時間（割込みレイテンシ）や、タスク切り替えにかかる時間（コンテキストスイッチ時間）が既知の上限値として保証される点。これにより「最悪でも何マイクロ秒以内に応答する」という設計が可能になる。

3.1.2タスクの状態遷移

• 実行（running）＝現在CPUを占有し命令を実行中の状態。シングルコアでは同時に1タスクのみがこの状態を取る。
• 実行可能（ready）＝CPUが割り当てられればすぐに実行できる状態にあるが、より優先度の高い（または同優先度で順番待ちの）タスクにCPUを占有されているため待機している状態。
• 待ち（waiting／blocked、休止(dormant)を含む広義の待機状態）＝セマフォ取得待ち・メッセージ受信待ち・タイマ満了待ちなど、何らかのイベントの発生を待って自らCPUを手放している状態。休止は生成前/終了後でスケジューリング対象外の状態を指す。
• 遷移の要点：実行中タスクが待ちに入るのは自発的（イベント待ち）、実行中タスクが実行可能に落ちるのはプリエンプション（より優先度の高いタスクの出現）による強制的な追い出し。待ちからイベント成立で実行可能へ戻り、スケジューラが選ぶまで実行には移らない。

3.1.3RTOS採否の判断

あるファームウェア開発者が、産業用センサ端末の設計を任されたとします。要件は「
①温度センサから100ms周期でデータを取得」「
②取得データをBLEで500ms周期で送信」「
③ボタン押下を即座に検知しLEDを点滯」の3つが並行して動く必要がある、というものです。ここでベアメタル（1本のメインループ+割込み）で実装しようとすると、
①のセンサ読み取りが数十ms掛かる処理だった場合、その間
②のBLE送信タイミングがずれたり、
③のボタン応答が遅れたりする恐れがあります。ポーリングループの中に全処理を詰め込むと、どれか1つの処理時間が伸びるだけで他の処理全体のタイミングが崩れるという結合が生まれるためです。ここでRTOSを導入すれば、
①
②
③をそれぞれ独立したタスクとして分離し、
③のボタン検知タスクに最高優先度を与えることで、他のタスクの実行状況に関わらずボタン応答性を保証できます。
①と
②はそれぞれの周期でイベント待ち（待ち状態）に入り、周期が来ればスケジューラが実行可能へ戻し、優先度に応じて実行へ昇格させます。一方、要件が「LEDを1秒間隔で点滅させるだけ」のような単純な機器であれば、RTOSの導入はメモリと開発コストの追加投資に見合わず、単純なポーリングループ（ベアメタル）で十分と判断すべきです。「独立した複数の周期処理が絡み合い、それぞれに異なる締め切り制約がある」ことがRTOS導入を正当化する典型的な条件です。

3.1.4この節のまとめ

• RTOSが優先するのは平均性能ではなく最悪ケースでの予測可能性（締め切り保証）
• タスクは実行/実行可能/待ちの3状態を遷移し、実行→待ちは自発的、実行→実行可能はプリエンプションによる強制
• 複数の独立した周期処理が絡み合い異なる締め切り制約を持つ場合はRTOS採用が有利、単純な単機能処理はベアメタルで十分