リアルタイム制約とWCET

「速い」と「間に合う」は別物

一般のソフトウェアでは平均が速いほど良いとされます。しかし組込み制御では評価軸が違います。エアバッグ展開やモーター制御は、平均何ミリ秒かではなく 「どんなに悪くても指定時刻までに必ず終わるか」 が問われます。平均1msでも、稀に50msかかる瞬間があれば制御は破綻します。リアルタイムシステムとは高速なシステムではなく、時間的な正しさ（時刻という結果の正しさ）が保証されたシステム です。

この保証を組み立てる部品が3つあります。締切（デッドライン）に対する厳しさの分類、1タスクの最悪実行時間（WCET）の見積り、そして複数タスクが同居しても全員が締切を守れるかの判定（スケジュール可能性）です。順に見ていきます。

ハードリアルタイムとソフトリアルタイム

締切を1回でも破ったときの「損害の質」で分類します。速度の大小ではない点に注意が必要です。

区別が決定的なのは、要求される「証明の強さ」が変わる からです。ソフトリアルタイムは「99パーセンタイルで20ms以内」のような統計的目標で足り、平均性能の最適化と相性が良い。対してハードリアルタイムは統計では不十分で、最悪ケースでも締切内 という決定論的な保証を、解析によって事前に示す必要があります。この「最悪ケース」を扱う中心概念がWCETです。

WCET：なぜ「実測の最大値」では足りないか

WCET（Worst-Case Execution Time）は、あるタスクを単独で走らせたときにかかりうる実行時間の上界です。ここで最大の落とし穴は、「何回も測って一番遅かった値」がWCETの上界にはならない という点です。理由は現代プロセッサの実行時間が経路と履歴に強く依存するからです。

同じ関数でも実行時間が変わる主因（速い⇔遅いの幅を生む要素）
  命令キャッシュ  : ヒットなら数サイクル、ミスなら主メモリ往復で数十〜数百サイクル
  データキャッシュ: 同上。アクセスパターン次第でミス率が激変
  分岐予測        : 的中なら遅延ゼロ、外すとパイプラインフラッシュ
  パイプライン    : 直前命令との依存でストール（追い越し不可の待ち）
  DRAMリフレッシュ / バス競合 : 他マスタ（DMA等）と衝突すると待たされる

これらの状態は入力データや直前に何が動いていたかで変わるため、テストで最悪の組合せを踏む保証がありません。実測の最大値は下界（少なくともこれ以上はかかる）にはなっても、上界の証明にはならないのです。そこで実務では次の3系統を使い分けます。

いずれの結果にも 安全余裕（マージン） を上乗せして設計WCETとするのが通例です。静的解析器は分岐の到達可能性やループ回数の上限（ループバウンド）を必要とするため、開発者が上限を注釈で与えることも多くあります。

デッドラインとスケジュール可能性

各タスクのWCETが求まったら、次は複数タスクを同じCPUに載せて 全員が締切を守れるか を判定します。周期タスクを次の記号で表します（すべてインラインコードで表記）。実行時間 C（WCET）、周期 T、相対締切 D。CPU利用率は各タスクで U = C / T、システム全体では総和 Utotal = Σ(Ci / Ti) です。

代表的な固定優先度方式が レート単調（RM） です。周期が短いタスクほど高い優先度を与えます。RM には有名な十分条件があり、n 個のタスクで全締切が D = T のとき、Utotal が n * (2^(1/n) - 1) 以下ならスケジュール可能です。n が大きくなるとこの上界は約 0.693（ln 2）に収束します。つまり 利用率が約69%以下なら、RMで必ず間に合う という強力な指針が得られます。

RM 利用率上界（Liu & Layland 境界）
  n=1 : 100.0 %
  n=2 :  82.8 %
  n=3 :  78.0 %
  n→∞ :  69.3 %  ( = ln 2 )
  → この値“以下”なら十分条件を満たす（必要条件ではない）

動的優先度方式の EDF（最早締切優先） はさらに強力で、締切が最も近いタスクを常に優先します。締切と周期が等しい前提なら、Utotal が 100% 以下 でスケジュール可能という必要十分条件が成り立ちます。理論上はCPUを1%も無駄にせず使い切れるわけです。RMと比べた性質を整理します。

RMの利用率境界はあくまで 十分条件 です。境界を超えても実際には間に合う場合があり、より精密に判定するのが 応答時間解析（RTA） です。各タスクの最悪応答時間 R（起動から完了までの最大時間）を、自身の C に、より高優先度タスクから受ける割込み（干渉）を足し込んで反復計算し、最終的に R が D 以下なら合格とします。境界法より甘くない、正確な合否判定を与えます。

ジッタ：締切を守っても揺れは残る

締切を守れても、まだ品質を損なう要素があります。ジッタ（jitter） ——本来一定であるべきタイミングのばらつきです。周期タスクの起動が理想時刻から前後にずれる リリースジッタ、開始が高優先度タスクの割込みで遅れる 開始ジッタ、そして完了時刻が揺れる 完了ジッタ に分けられます。

これが問題になるのは、周期の一定性そのものが結果の質を決める 制御だからです。モーター制御やセンサーサンプリングでは、各回の実行が「均等な時間間隔」で行われる前提で制御則が設計されます。実行間隔が揺れると、微分・積分項の計算が狂い、制御が不安定化したりノイズが乗ったりします。締切内には収まっていても、間隔がばらつくだけで悪化するのです。

まとめ：時間を「保証」する設計へ

リアルタイム設計の核心は、平均を速くすることではなく 最悪ケースの時間的振る舞いを事前に証明する ことにあります。締切超過の質でハード／ソフトを分類し、経路とハードウェア状態に依存するWCETを実測ではなく上界として見積もり、RMの利用率境界やEDFの100%基準、応答時間解析でスケジュール可能性を判定し、最後にジッタを抑えて周期の一定性を守る——この一連の流れが揃って初めて「間に合う」を保証できます。土台にあるのはCPUのキャッシュやパイプラインといった/hardware-components/や/semiconductor/の挙動、そしてタスクをどう切り替えるかという/os/のスケジューリング機構であり、それらの理解の上に時間保証は成り立っています。