変更要約: 初版
3.5割込みとリアルタイム性
ISR（割込みサービスルーチン）とタスクを分離し、時間のかかる処理を遅延処理（deferred processing）へ委譲する設計、ハードリアルタイムとソフトリアルタイムの違い、割込み遅延（interrupt latency）とジッタの発生要因、そして応答時間解析によって最悪応答時間を見積もる考え方を学びます。
割込みは「発生したらすぐに反応できる」という利点がある一方、ISRの中で時間のかかる処理をしてしまうと、他の割込みやタスク全体の応答性を悪化させるという副作用があります。組込み設計者には、「ISRでは何をして、何をタスクに委ねるべきか」という設計判断と、システム全体のリアルタイム性（締め切りを守れる保証の強さ）をどう見積もるかという分析力の両方が求められます。
3.5.1ISRとタスクの分離・遅延処理
- ISR（割込みサービスルーチン）は割込みが発生したことを即座に認識し、最小限の処理（フラグの記録、レジスタの読み出し、タスクの起床要求など）だけを行い、速やかに割込みを終えるべきというのが鉄則。ISRの実行中は同レベル以下の割込みが受け付けられない（あるいは全割込みが禁止される）ことが多く、ISRが長引くほど他の割込みの検出・応答が遅れる。
- 時間のかかる本処理（データの整形・複雑な計算・通信処理など）は、ISRからセマフォやイベントフラグでタスクを起床させ、通常のタスクコンテキストで実行する遅延処理（deferred processing）に委ねる。これにより割込み禁止区間を最小化し、優先度に基づくスケジューリングの恩恵（他の高優先度処理を妨げない）も受けられる。
3.5.2ハードリアルタイムとソフトリアルタイム
- ハードリアルタイム＝締め切りを1回でも外すとシステムの安全性・機能そのものが失われる（致命的な結果を招く）制約。例：エアバッグの展開制御、エンジン点火タイミング。設計は必ず最悪ケースで間に合うことを保証する方向で行う。
- ソフトリアルタイム＝締め切りを外しても品質の低下（体感の悪化）にとどまり致命的ではない制約。例：動画再生のコマ落ち、音声のわずかな遅延。統計的に「多くの場合間に合えばよい」という設計が許容される。
3.5.3割込み遅延・ジッタと応答時間解析
- 割込み遅延（interrupt latency）＝割込み信号がハードウェア的に発生してから、対応するISRの最初の命令が実行されるまでの時間。割込み禁止区間の長さ（他の割込みハンドラやクリティカルセクションで割込みを禁止している期間）が最大の支配要因。
- ジッタ＝周期的に発生すべき処理の実際の開始時刻・完了時刻が、理想の周期からばらつく度合い。割込み遅延の変動・スケジューリングの優先度競合・キャッシュミスやDMAとのバス競合などが原因となる。制御系（PID制御等）ではジッタが大きいと制御精度が悪化するため、周期の揺らぎの上限を設計要件として明示する。
- 応答時間解析（RTA）＝あるタスクの最悪応答時間（自身の実行時間＋自身より高優先度の全タスクによる割込み・プリエンプションの累積干渉時間）を数式的に見積もる手法。締め切りと比較し「最悪でも間に合うか」を精密に判定する、レートモノトニックの利用率上限より厳密な判定手段。
「ISRは最小限の処理に留め本処理は遅延処理（タスク）へ委譲する」「ハードリアルタイムは1回のデッドライン違反も致命的、ソフトリアルタイムは品質低下にとどまる」「割込み遅延は割込み禁止区間の長さが支配要因、ジッタは周期のばらつき」が最頻出です。RTAが利用率上限より精密な判定手段である位置付けも問われます。
あるファームウェア開発者が、モータ制御タスクH（周期T=5msのPID制御・ハードリアルタイム、締め切り厳守が安全上必須）を含むシステムで、「まれにHの応答が遅れ制御が乱れる」という不具合の原因を調査しているとします。まず疑うべきは割込み遅延です。調査の結果、通信インタフェース用の別の割込みハンドラ（ISR）が、受信データの解析処理までISRの中で行っており、最大0.8msもの間、割込みを禁止していることが判明しました。これがHへの割込み通知を最大0.8ms遅らせる割込み遅延の主因です。対策として、このISRを「受信データをバッファへコピーしフラグを立てるだけ」の最小限処理に縮小し、実際の解析処理は優先度の低いタスクへ遅延処理として委譲することで、ISRの実行時間を0.8msから数マイクロ秒へ大幅に短縮できます。次に、Hの最悪応答時間を見積もるため応答時間解析（RTA）を行います。Hより高優先度の割込み処理（縮小後で数マイクロ秒）と、Hと同等以上の優先度を持つ他のタスクによる干渉時間を積み上げ、Hの最悪応答時間 = Hの実行時間 + 高優先度タスク/割込みによる累積干渉時間という式で計算し、この値がT=5msという締め切りを下回ることを確認します。もしこの見積もりが締め切りを超えるようであれば、ハードリアルタイム制約であるHにとっては致命的な設計不備であり、割込み優先度の見直しやISRのさらなる簡略化、あるいは干渉するタスクの周期・実行時間そのものの見直しが必要になります。一方、同じシステムの音声ストリーミング処理（ソフトリアルタイム）であれば、まれにTを超えても「わずかな音切れ」で済むため、Hほどの厳密なRTAは不要で、統計的な遅延分布の監視で足りるという判断ができます。「致命的か品質低下で済むか」でハード/ソフトを区別し、ハードリアルタイムのタスクにはRTAで最悪ケースを保証するのが、この節が求める設計判断です。
| 観点 | ハードリアルタイム | ソフトリアルタイム |
|---|---|---|
| 締め切り違反の結果 | 致命的（安全性・機能喪失） | 品質低下にとどまる（体感の悪化） |
| 設計方針 | 最悪ケースでも必ず間に合う保証（RTA等） | 統計的に多くの場合間に合えばよい |
| 代表例 | エアバッグ展開・エンジン点火・モータ制御 | 動画/音声ストリーミング |
ひっかけ： 「ISRの中で本処理まで全て終わらせるのが最も応答性が良い設計である」は誤りです——ISR内で時間のかかる処理をすると割込み禁止区間が延び他の割込みの割込み遅延を悪化させるため、本処理は遅延処理（タスク）へ委譲するのが正しい設計です。また「ソフトリアルタイムであれば締め切りは全く気にしなくてよい」も誤り＝ソフトリアルタイムでも締め切り違反が続けば品質が著しく低下するため、統計的な監視・改善は必要です。
3.5.4この節のまとめ
- ISRは最小限の処理に留め、時間のかかる本処理は遅延処理としてタスクへ委譲する
- ハードリアルタイムは1回の締め切り違反も致命的、ソフトリアルタイムは品質低下にとどまる
- 割込み遅延は割込み禁止区間の長さが支配要因、応答時間解析（RTA）で最悪応答時間を締め切りと比較し精密に保証する
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. ハードリアルタイム制約のモータ制御タスクの応答がまれに遅延する不具合を調査したところ、別の通信用ISRが受信データの解析まで割込みハンドラ内で実行し、最大0.8msの間割込みを禁止していた。最も適切な対策はどれか。
Q2. 音声ストリーミング処理（ソフトリアルタイム）とエアバッグ展開制御（ハードリアルタイム）の設計方針の違いとして最も適切なものはどれか。
Q3. レートモノトニックの利用率上限による判定では「スケジュール可能」と断言できなかったタスク集合について、より精密な判定を行いたい。最も適切な手法はどれか。