For soft real-time you don't prove zero misses — you bound the statistics: e.g. "99.9% of frames render within 16 ms," or minimise average tardiness max(0,Ri−Di). The design knob is graceful degradation: drop quality, skip frames, or shed load instead of crashing.
Correctness depends on both the logical result and the time it is produced (timeliness is part of correctness).
Hard deadline — consequence of a miss?
Catastrophic / total system failure; a late result is invalid.
Firm deadline — consequence of a miss?
Late result has zero value and is discarded, but no catastrophe.
Soft deadline — consequence of a miss?
Result still has reduced/degrading value; occasional misses tolerated.
What is WCET and why use it (not average)?
Worst-Case Execution Time; deadlines fail in the worst case, so guarantees must be built on the maximum, not the mean.
Utilisation of one periodic task?
Ui=Ci/Ti (CPU fraction it demands).
Total utilisation of n tasks?
U=∑iCi/Ti; if U>1 the CPU is over-subscribed and a miss is unavoidable.
Liu–Layland RM schedulability bound?
U≤n(21/n−1); limit →ln2≈0.693 as n→∞.
EDF utilisation bound on one CPU?
U≤1 (EDF is optimal for periodic single-processor).
Is the RM utilisation test sufficient or necessary?
Sufficient only — failing it does not prove unschedulability; use exact Response-Time Analysis.
Response-Time Analysis equation?
Ri=Ci+∑j∈hp(i)⌈Ri/Tj⌉Cj, iterated to convergence; schedulable iff Ri≤Di.
Why does ⌈Ri/Tj⌉ appear?
It counts how many times higher-priority task j preempts i during Ri.
Hard real-time goal in one word?
Predictability (bounded worst case), not raw speed.
Recall Feynman: explain to a 12-year-old
Imagine catching a school bus. Hard deadline: if you're even one second late the bus leaves and you miss school entirely — disaster. Firm deadline: you can still come, but if you're late your homework "doesn't count" — no points, but nobody's hurt; you just throw it away. Soft deadline: you're allowed to be a little late and still get most of the marks, just fewer the later you are.
To promise you'll never miss the hard bus, you don't say "I'll run fast" — you measure the slowest you could ever walk, add up everyone using the one door, and prove you all fit in time. Fast-on-average isn't a promise; a proof using the worst case is.
Real-time system ka matlab sirf "fast" hona nahi hai — iska matlab hai ki answer sahi time pe aana chahiye. Agar answer correct hai par deadline ke baad aaya, to kuch systems mein wo bekaar (ya khatarnak) ho jaata hai. Isliye correctness mein timeliness bhi include hoti hai. Har task ka ek deadline hota hai: release time se kitne time ke andar finish hona chahiye.
Deadlines teen type ki hoti hain. Hard: miss hui to total disaster — jaise airbag ya flight control. Firm: late answer ki value zero, use throw kar do, par koi catastrophe nahi — jaise video ka late frame. Soft: thoda late chal jaata hai, value dheere-dheere kam hoti hai — jaise streaming buffering ya UI smoothness. Yaad rakhne ka tareeka: HARD = Heart-stop, FIRM = Forget-it, SOFT = Slowly-fades.
Hard deadline ko guarantee karne ke liye testing kaafi nahi — proof chahiye. Pehle har task ka WCET (worst-case execution time, Ci) nikalo. Phir utilisation U=∑Ci/Ti nikalo — yeh CPU ka kitna hissa maang raha hai wo batata hai. Agar U>1 to CPU over-subscribed hai, miss pakka. Rate-Monotonic ke liye safe bound hai U≤n(21/n−1) (jo 0.693 tak gir sakta hai), aur EDF ke liye poora U≤1. Bada point: yeh bound sufficient hai, necessary nahi — fail ho jaaye to Response-Time Analysis se exact check karo.
Sabse important galti: log sochte hain hard real-time matlab "bahut tez". Galat! Iska matlab hai predictable — worst case bounded hona chahiye. Ek slow par deterministic MCU, ek fast par kabhi-kabhi atak jaane waale system se behtar hai. Hamesha average nahi, worst-case time use karo.
