平均一ミリ秒では、間に合ったことにならない

架空事例：青葉機材が機材の状態を監視する組込み制御装置を企画する。周期、処理時間、電力、コストの数値は単純化した設計例であり、実機測定値や安全要件ではない。

千回のうち一回だけ、間に合わなかった

機材の姿勢を監視する制御装置がある。センサの値を読み、危険な姿勢になったときには所定の時間内に制御信号を出す。試作機の平均処理時間は一ミリ秒だった。

開発者は十分速いと考えた。しかし千回に一回、別の処理が割り込むと制御が遅れた。その遅延が、許容された期限を越えていた。

平均の速さと、期限を守ることは違う。

組込み・リアルタイムシステムでは、処理時間だけでなく、どの時点までに結果が必要かを決める。最悪実行時間、割込みの応答、周期、他のタスクの干渉によって結果が変わる。原教材第26章が扱う制約は、単に処理能力の低さではなく、時間的な保証の必要性である。1

リアルタイムとは、いつでも瞬時という意味ではない

一秒後に動けばよい装置と、一ミリ秒以内に動く必要がある装置では要求が異なる。ただし、後者の方が必ず「よりリアルタイム」であると機械的には言えない。決められた期限へ間に合うことが要件だからだ。

ハードリアルタイムでは、期限を越えると許容できない障害や危険につながる場合がある。ソフトリアルタイムでは、多少の期限超過を品質低下として扱える場面がある。名称だけで安全性を判断せず、期限違反がどの業務・物理動作にどんな影響を及ぼすかを明確にする。

青葉機材は、危険検出時の停止命令と、運用者への状態表示を別に考える。運用画面の更新が多少遅くなることと、危険な動作を止める指示が遅れることでは許容できる影響が違う。すべての処理を同じ優先度へ置く必要はない。

CPU利用率の合計だけで、期限は保証できない

説明用に、単一CPUで動く二つの周期タスクを考える。タスクAは10ミリ秒ごとに最大2ミリ秒、Bは20ミリ秒ごとに最大3ミリ秒のCPU時間を必要とする。利用率の合計は 2÷10＋3÷20＝0.35、すなわち35%となる。

計算したのはCPU時間の比率であり、期限を守る証明そのものではない。もしタスクの期限が極端に短かったり、優先度が不適切だったり、割込みや資源の待ちが大きかったりすれば、利用率が低くても期限を越える可能性がある。

例えば独立した周期タスクで相対期限が周期に等しい、単一CPUでのプリエンプションが可能、無視できない追加のオーバーヘッドがない、といった理想化を置くと、EDF（Earliest Deadline First）で利用率を用いたスケジューリング可能性の議論ができる。しかし、その条件を外した実装へ「35%なので必ず安全」と転用してはいけない。

LinuxカーネルのSCHED_DEADLINE資料は、runtime、deadline、periodという三つの時間パラメータとEDF/CBSに関係する実装を説明する。2 その説明はLinuxの当該スケジューラの文脈であり、すべてのRTOSへ同じ設定値を要求するものではない。

優先順位を上げたら、止まってしまった

危険検出のタスクの優先順位を高くした。これでいつでも先に動くように見える。しかし、低い優先順位の処理が共有資源のロックを保持し、高い優先順位の処理がその解放を待つ状況もある。

優先順位が高いという情報だけでは、何が起きるかを決められない。共有資源の排他制御、割込みを止める時間、処理の実行可能性を合わせて確認する必要がある。

このような事象を考えると、アルゴリズムの平均処理時間を短くするより、待ちの上限を明確にする方が重要な場合がある。待つ必要のない設計へ変える、共有するデータを減らす、適切な同期手法を選ぶなどの選択肢を比較する。

ただし、高優先度タスクを無制限に増やせばよいわけではない。通常のデータ記録や通信処理が飢餓状態になれば、監視装置の一部機能が成立しなくなる。制御と記録の仕事を、必要な期限に応じて配置する。

メモリを減らせば、必ず良いわけではない

組込み装置は、メモリ容量、消費電力、発熱、起動時間、部品の供給期間、製造単価に制約を受ける。サーバ用ソフトウェアをそのまま載せられるとは限らない。

青葉機材がデータを保存するため、独立したDBサーバへ通信する案と、装置内のアプリケーションから直接利用できるDBエンジンを組み込む案を比較する。後者は構成を簡素にできる場合がある。SQLiteは別のサーバプロセスを要求せず、呼び出すアプリケーションがDBファイルへアクセスする方式の代表例である。3

しかし、同時アクセスや故障の分離、遠隔バックアップの条件は別に設計しなければならない。インプロセスDBを使ったからネットワーク上の複数機器から自動的に安全に共同更新できるわけではない。

同様に、メモリ使用量を少なくしても、一時的に処理時間が伸びる圧縮処理を導入すれば期限に影響することがある。単一の制約を最小化すれば全体が最適になるとは限らない。

専用回路とプログラムの境界

危険検出の一部を専用回路へ実装する案がある。応答を短くしやすい場面もある一方、回路を変更するための費用や開発時間が必要になる。ソフトウェアへ置けば変更しやすいが、CPU負荷や割込み処理へ依存する場合がある。

ハードウェア／ソフトウェア協調設計では、機能をどちらに置くかを、時間、電力、単価、変更頻度、検証方法などから決める。ハードウェアであるというだけで正しく、ソフトウェアであるというだけで柔軟という単純な序列はない。

センサの配線や電源の故障をソフトウェアの条件分岐だけで防げるとは限らない。一方、専用回路があるから運用の誤設定まで防げるわけでもない。機能を割り当てる先と、そこで保証される性質を分ける。

正しく動くことと、安全に動くこと

コーディング規約の遵守は重要だ。原教材のMISRA Cの説明は、危険な記述を減らす考え方を示している。1 しかし規約を満たしたプログラムでも、停止すべき条件が仕様に欠けていれば装置は危険な動作をし得る。

テストでも、平均値だけでは最悪条件を確かめられない。センサの値が境界を越える瞬間、通信が遅れる場合、電源投入直後の未初期化状態などを検討する。

最終的に、どの期限が安全上重要か、何を独立に検出し、どう停止させるかを明らかにする。装置が平均して速いことより、必要な時点で必要な性質が成立することを優先する。

知識を答案へ戻す

午前Ⅱ。 ハード・ソフトリアルタイム、WCET、割込み、ハード／ソフト協調設計、インプロセスDB、MISRA Cの目的を区別する。

午後Ⅰ。 期限と制約を本文から特定し、平均時間・最悪時間、優先度・待ちの違いを読む。モデルが置いた仮定を明らかにする。

午後Ⅱ。 安全上の期限、機能配分、検証方法、残る制約について具体的な設計判断として説明する。

立ち止まって考える：CPU使用率が35%なので、すべての制御タスクが期限を守れると言えるか

言えない。相対期限、優先順位、排他待ち、割込み、実行時間の上限などが関係する。特定の理想モデルの条件を満たすか確認する必要がある。

出典と照合範囲

[1] コンプリートテキスト第5・12・13・14・26章、IPA SAシラバスVer.5.2：制約条件と方式設計、組込みシステムの基本を参照。周期と利用率の数値は独自に設定。公式シラバス

[2] Linux Kernel, Deadline Task Scheduling：SCHED_DEADLINEのruntime、period、deadlineの概念を参照した。Linux特有の実装条件は他OSへそのまま適用しない。公式文書

[3] SQLite公式文書「SQLite Is Serverless」：組込みDBと独立DBサーバの違いを参照した。公式文書