# Hard vs. Soft Real-Time Systems ###### tags: `RTS` ## Jobs and Processors * Jobs * 是被系統排程 (scheduled) 和執行 (executed) 的最小單位 * RTS 中的功能常常是透過一連串 jobs 的排程與執行而成 * Task * 一連串的 jobs 組合而成 * eg : 讓飛機飛行在空中並維持固定高度 ## Times ![](https://i.imgur.com/LaalKqI.png) * `Release Time` : 一個 job 準備好可以被開始執行的時間點，也就是說 job 可以被排程在 release time 中的任何時間點執行。通常 release time 不會是一個確切的時間點而是落在一個範圍時間內。 * `Response Time` : 從 job 的 release time 到 job 執行完的時間差 :::info 但 response time 和 execution time 並不相同 response time = execution time + 其他的時間 ::: ![](https://i.imgur.com/pqnMwdR.png) * `Deadlines` : job 在該時間點前一定要被被執行完畢，又稱為 **absolute deadline** * `Completion time` : job 執行完的時間點 * `Relative deadline` : 表示 job 最大可容許的 `response time` * `Absolute deadline` : 相當於 `release time + relative time` ## Timing constraints * hard timing constraint 當系統沒有達成這個時間限制或 job 沒在 deadline 前被完成時，會有致命的錯誤產生(fatal fault) * soft timing constraint 當系統沒有達成這個時間限制或 job 沒在 deadline 前被完成時，使會讓結果產生的沒預期的好 :::info 因此會以此立場對目標結果的重要性決定其為 hard or soft ::: * Usefulness of result 使用 tardiness of job 來評估資料的可用性和時間的關係 ![](https://i.imgur.com/xWgiZAg.png) 可以看出 * A 若未在 deadline 前完成，其有效性為 0 => ==hard timing constraint== * B 與 C 則是隨時間遞減 =? ==soft timing constraint== * 不同型態的 timing constraints * Deterministic constraint * 具體的給了 deadline 的時間，如: 10(ms) 內要完成 * HRTS 通常用這個 * Probabolity constraint * 將 timing constraint 用機率分佈來表示，如: response time 超過 10 (ms) 的機率要小於 0.2 * Usefulness function * 如: 每個 control law 的 usefulness 都必須高於 0.8 ## Hard Real-Time Systems 在系統中的 timing constraint 都為 hard timing constraint 時，稱其為 hard real-time system。 許多嵌入式系統都是 HRTS。在嵌入式系統中，job 的 deadline 指的是 senor. actuator. control by it 的時間 * 汽車煞車系統 然而有些非嵌入式系統也是 HRTS * 股市交易系統 不過提早完成這些 HRTS 的 deadline 並沒有帶來任何好處，他的 response time 並不能代表什麼指標，因此僅須在 deadline 前完成即可。事實上比較重要的指標反而是要讓 response time 的 ==jitters== 最小越好，也就是說希望週期性的 job 每次被執行完的時間是固定的 :::info **jitters** - 是指每次 response time 的跳動也就是變動的幅度 ::: ## Soft Real-Time Systems 在系統中的 timing constraint 都為 soft timing constraint 時，稱其為 soft real-time system。 * eg: 線上交易系統. 電話交換機系統. 遊戲 當系統對時間的驗證度越不嚴謹，就代表著有越寬鬆的 timing constraint，這也讓系統開發者有較大的空間去考量其他非時間上的效能，因此滿足 deadline 就不會是主要的考量了 * eg: 電話 -> 希望電話快點有回應 -> 有機率的容忍空間. 多媒體的影格交換率