最壞情況執行時間（worst-case execution time, WCET）
/ DUB-yoo-set /
若你必須保證能準時開車穿越市區赴約，你不會以最幸運、全程綠燈的那次來規劃——你會以最壞但合理的車流來規劃。對一段必須達成期限的程式碼，對應的問題是：在「所有」可能的輸入與條件下，這個函式執行可能花的「最長」時間是多少？那個上界就是最壞情況執行時間（WCET）。
WCET 是一個任務或程式碼區塊在特定處理器上、跨越每個可達的輸入、路徑與硬體狀態，執行可能花的最長時間。它是即時排程分析（速率單調、EDF、回應時間分析）賴以運作的關鍵原料——那些方法需要每個任務的 Ci，也就是它的最壞情況時間，才能證明期限達成。估計 WCET 真的很難，因為有兩件事讓可能性倍增。第一是「軟體」：不同輸入走不同路徑、迴圈可能依資料迭代不定次數（所以你需要每個迴圈的已知上界）、遞迴必須在某個界限內終止。第二是「硬體」：現代處理器透過快取（一次快取未命中遠慢於命中）、分支預測、管線與亂序執行讓時序依資料而變，所以「同一道」指令可能依歷史花費天差地別的時間。有兩大途徑：以量測為本（跑很多次並觀察最大值，這可能「漏掉」真正的最壞情況）與靜態分析（分析程式碼與處理器模型以導出有保證的上界，傾向安全但悲觀）。安全的 WCET 上界必須是高估、絕不可低估，否則保證就一文不值。
它之所以重要，是因為沒有可信的 WCET，你就無法誠實宣稱一個硬即時系統會達成期限——整套可排程性分析都建立在它之上。誠實且重要的提醒：純以量測為本的 WCET「不」是保證，因為你可能在測試中根本沒擊中最壞情況的路徑或快取狀態；「我們測試中從沒發生記憶體區段錯誤」那種推理正是這個陷阱。讓平均情況程式碼變「快」的快取與推測硬體，也讓 WCET 更難設上界、更悲觀，這正是深度攸關安全的系統有時關閉快取或選用更簡單、更可預測處理器的原因。而 WCET 是「依處理器」而定：同樣的程式碼在不同晶片或時脈下有不同的 WCET。
// WCET 取決於輸入「與」硬體歷史： int search(const int *a, int n, int key) { for (int i = 0; i < n; i++) // 迴圈界限 n 必須「已知」 if (a[i] == key) return i; // 最佳情況：i=0 就命中 return -1; // 最壞情況：掃完全部 n 個元素 } // WCET ~ n 次迭代，「每次」都可能快取未命中 -> 上界是 // （n * 最壞情況單次迭代時間），而非量測到的快速平均。
WCET 假設最長路徑與最壞快取行為，而非量測到的平均執行——每個迴圈都需要已知的迭代界限。
以量測為本的 WCET 不是保證：測試可能從未擊中真正的最壞情況路徑或快取狀態。安全的上界必須高估，而加速平均情況的快取／推測會讓最壞情況更難設上界。