computer science//real-time computing//real-time scheduling//response-time analysis

Response-time analysis is the exact schedulability test for fixed-priority tasks: it computes, for each task, the longest time from its release to its completion, counting its own execution and everything more urgent tasks steal meanwhile, and compares it with the deadline. It is what an engineer runs when a task set fails the quick rate-monotonic utilization bound, or when deadlines are shorter than periods, and it is the analysis certification bodies expect for priority-scheduled flight and automotive code.


Response-time analysis is the exact schedulability test for fixed-priority tasks: it computes, for each task, the longest time from its release to its completion, counting its own execution and everything more urgent tasks steal meanwhile, and compares it with the deadline. It is what an engineer runs when a task set fails the quick rate-monotonic utilization bound, or when deadlines are shorter than periods, and it is the analysis certification bodies expect for priority-scheduled flight and automotive code.

The worst response RiR_iRi​ of task iii satisfies

Ri=Ci+∑j∈hp(i)⌈RiTj⌉Cj,R_i=C_i+\sum_{j\in hp(i)}\left\lceil\frac{R_i}{T_j}\right\rceil C_j,Ri​=Ci​+j∈hp(i)∑​⌈Tj​Ri​​⌉Cj​,

where CiC_iCi​ is its own worst-case execution time, hp(i)hp(i)hp(i) the tasks with higher priority, and the ceiling counts how many times each of them is released while task iii is waiting or running. The unknown appears on both sides, so it is solved by fixed-point iteration: start with Ri=CiR_i=C_iRi​=Ci​, recompute the right-hand side, and repeat until the value stops changing. The task meets its deadline if Ri≤DiR_i\le D_iRi​≤Di​; if RiR_iRi​ grows past the deadline the iteration stops and the task fails.

In the autopilot budget worked out under rate-monotonic scheduling, the logger, last in priority with C=1.00C=1.00C=1.00 ms and a 20 ms deadline, starts at 1.00 ms, grows to 2.22 ms and settles at R=2.54R=2.54R=2.54 ms: before it finishes it is preempted by three IMU releases, two attitude releases, one EKF release and one position release. It meets its deadline with more than 17 ms to spare.

The result inherits every assumption. It is exact only if the worst-case execution times are true bounds, if interrupt service time is added as one more high-priority task, and if blocking on shared resources is bounded and added as a term (with priority inheritance, at most one critical section of a lower task; without it, unbounded, the priority inversion case).

It answers a different question from a utilization bound: the bound says the whole set fits, response-time analysis says by how much each task is early, which is the margin an engineer adds features against (real-time scheduling).