在實時嵌入式系統中，哪怕一次時限未滿足，都可能損害安全性與可靠性。從汽車、航空電子到工業自動化、國防領域，開發人員必須證明：系統對最壞情況執行時間（WCET）有充分理解并能持續界定其范圍，確保運行中任何任務都不會超出這個可靠上限。

估算 WCET 絕非易事，尤其在現代多核系統中。因此，即便是經驗最豐富的開發團隊，也常常低估 WCET，且往往實現得很差。關鍵任務的最壞情況執行時間會隨其他運行任務、共享資源狀態以及處理器負載行為的變化而波動。

隨著系統日益復雜，以及人工智能與機器學習（AI/ML）負載帶來更大的內存與數據流量壓力，開發人員必須直面 WCET 問題。忽略它是不可接受的。即便平均執行時間看起來合理，低估 WCET 仍會危及安全性、可靠性與認證合規性（圖 1）。

圖 1：實測執行時間（橙色）只是所有可能執行時間（紫色）中的一部分。為確保能滿足最壞情況執行時間（WCET），開發人員利用實測執行時間來估算 WCET。為實現安全可靠的運行，開發人員可設定一個時序上限，保證實際 WCET 一定在此范圍內。

即使是平均滿足時序要求的任務，在真實負載下仍可能出現超時。認證標準強制要求開發人員證明：

• 每個安全關鍵任務在所有運行條件下都滿足時限。

• 即使存在干擾，WCET 仍在系統約束范圍內。

• 即使其他核心并發執行，時序依然保持確定性。

實測執行時間只能捕捉到測試中觀察到的部分情況。在真實多核硬件上，每次運行的干擾模式都會因緩存狀態、內存流量與其他共享資源競爭而改變。測試中測到的最壞情況，極少是真正的 WCET，它僅僅是測試期間觀察到的上限。而這個差距，正是可能引發災難性故障的地方。

在實時關鍵任務系統中，WCET 不可忽視的其他原因包括：

• 隱藏的并發影響：即使任務不共享代碼或數據，也可能通過共享緩存、內存總線或外設產生干擾，引發不可預測的延遲突增。

• 稀有事件脆弱性：時序違規常發生在不常見但關鍵的場景下，例如傳感器數據突發、AI/ML 負載峰值、多重中斷同時發生 —— 而這些時刻恰恰是可靠性最關鍵的時候。

• 安全與認證影響：ISO 26262、DO?178C、IEC 61508 等標準要求提供時序保證的證據。忽略 WCET 可能危及認證或帶來責任風險。

• 系統動態行為：內存競爭、緩存替換、任務重疊都會隨時間變化。依賴平均執行時間可能掩蓋最壞情況。

• 關鍵任務影響：在強實時系統（如飛控、汽車安全、醫療設備）中，哪怕一次超時都可能是災難性的。

簡單來說：WCET 是決定實時系統能否在所有條件下安全可靠運行的最重要因素。忽略它會帶來僅靠測試平均值無法發現的失效風險。

為什么 WCET 分析如此困難？

多核時序耦合

即使任務不共享數據、不共享函數，且運行在不同核心上，仍會因共享的底層硬件（L2/L3 緩存、內存總線與互聯、共享外設、RAM 訪問模式）而相互干擾。這些隱藏的干擾通道會產生時序突增，僅靠代碼審查無法預測。

并發執行具有非確定性

任務之間的執行重疊每次運行都不同。某個任務在一次測試中與另一任務重疊數毫秒，在下一次中可能幾乎不重疊。這種可變性直接影響 WCET，使分析成為一個迭代、以測量為主導的過程。

數據大小改變緩存行為

當任務的工作集超出 L1 緩存容量時，就會依賴共享 L2 或 RAM 訪問。多個任務同時超過這一閾值會導致緩存競爭激增，時序不可預測地拉長，在真實系統中有時增幅可達 40% 甚至更高。

人工合成干擾不真實

人為生成的干擾模式無法復現真實硬件競爭。WCET 必須在目標硬件、真實負載、實際緩存與內存配置下評估。

分三個互補階段分析多核 WCET

根據行業指導文件與標準，開發人員可采用多種方法在復雜的多核處理器系統中測量執行時序。三種成熟方法可在整個開發周期提供有價值的時序數據：

1. 開發早期：哈爾斯特德度量與靜態分析

哈爾斯特德復雜度度量可作為開發人員的早期預警系統。該方法可揭示特定代碼段的復雜度與資源需求。通過靜態分析，開發人員可將哈爾斯特德數據與目標系統的實時測量結果結合，幫助更高效地降低 WCET。

這類指標能反映代碼的時序相關特性，包括模塊大小、控制流結構、數據流。通過識別規模更大、復雜度更高、數據流更復雜的代碼段，開發人員可優先優化對處理時間要求最高的代碼。在開發生命周期早期優化這些資源密集型區域，可有效降低時序違規風險，并簡化后續分析。

2. 開發中期：執行時間的實測動態分析

當模塊無法滿足時序要求時，開發人員可測量、分析、跟蹤單個任務的執行時間，以識別并緩解時序問題（實測分析）。必須消除開發環境與生產環境在配置上的差異（如編譯選項、鏈接選項、硬件特性）。因此，分析必須在應用實際運行的環境中進行。這意味著實測分析要等到測試系統搭建完成后才能全面開展。

為反映多次運行之間環境與應用的變化，必須重復執行足夠多的測試以確保結果準確、可靠、一致（實測動態分析）。要在合理時間內完成足夠測試，自動化必不可少。自動化還能減輕開發人員負擔，并消除手動過程中可能出現的人為錯誤。

3. 開發后期：應用控制與數據耦合分析

評估競爭需要從控制與數據兩個角度識別應用內的任務依賴關系。通過控制耦合與數據耦合分析，開發人員可研究任務間的執行與數據依賴如何相互影響。標準強制要求此類分析，不僅是為了確保所有耦合關系都被覆蓋，也因為它們能揭示潛在問題。

端到端方案如何改善 WCET 分析

由于 WCET 同時取決于軟件與硬件行為，開發人員需要具備以下能力的工具：

• 在目標硬件上插裝代碼、捕獲時序、實時交換數據

• 揭示數據耦合、控制耦合與時序耦合

• 支持可復現、符合標準的驗證

準確的 WCET 分析依賴于對代碼在目標硬件上運行行為的理解。這些工具共同為開發人員提供完整的執行行為視圖，實現更準確、更具說服力的 WCET 分析：

• 編譯器通過控制機器碼的確定性影響 WCET。可預測的優化與穩定的代碼生成有助于保持執行時序一致。

• 調試器讓開發人員實時觀察負載下的系統執行。支持追蹤的工具可揭示指令流、任務重疊、內存訪問模式以及多核干擾導致的時序突增。

• 軟件質量與驗證工具通過代碼插裝收集詳細的運行時測量數據，幫助開發人員識別數據、功能與時序耦合；驗證執行路徑；并將結果與系統需求關聯。這為支持安全與認證目標提供可追蹤的證據。

對于 WCET 而言，硬件分析同樣至關重要。它包括：識別目標特定硬件配置中所有潛在的干擾通道；設計測試或配置系統，以觸發應測量 WCET 的最壞情況條件。

緩解時序耦合，控制 WCET

時序耦合是指任務之間即使不共享代碼或數據，也會相互影響執行時間。在多核系統中，隱藏依賴通過共享緩存、內存總線、外設等硬件資源產生。這些交互會造成意外延遲，拉高 WCET，導致關鍵任務超時（圖 2）。

圖 2：時序耦合干擾會顯著影響最壞情況執行時間。

識別干擾源后，開發人員可采用以下緩解技術：

• 最小化數據集以適配 L1 緩存：減少緩存競爭，避免任務相互淘汰工作數據。

• 調整多核配置：設置核心親和性、緩存模式、任務優先級，幫助關鍵任務隔離干擾。

• 使用 L2 緩存分區或 RTOS 級分區：為每個任務或核心保留資源，防止任務間競爭拉高 WCET。

• 在確定性優先于 raw 性能時關閉 L2：在某些系統中，可預測時序比吞吐量更重要。

• 在滿負載下重新運行 WCET 分析：驗證緩解措施在真實系統條件下有效。

其他管理時序耦合的方法包括：任務調度與優先級設置；限制共享外設的并發訪問，以減少多核心同時訪問同一設備時的不可預測阻塞時間；分析控制與數據依賴，識別任務間可能傳播延遲的間接交互。

通過追蹤與運行時插裝，開發人員不僅能驗證任務執行時間，還能分析時序變化的原因、定位干擾源，并確認緩解策略有效。這種可見性對于確保 WCET 上限可靠、關鍵任務在所有運行條件下都滿足時限至關重要。

LDRA 近期與美國陸軍聯合開展的一項研究表明：潛在時序問題可能導致安全關鍵 / 時序關鍵應用中超過 40% 的性能問題。干擾帶來如此大的時序增幅是不可接受的。

未來之路

現代指導文件（如 A (M) C 20?193）強化了對航空電子開發人員的要求：必須提供證據，證明多核干擾可被理解、WCET 可被界定、且確定性行為可被保證，而不是僅僅假設。

在汽車與工業領域，功能安全（FuSa）標準雖沒有 A (M) C 20?193 那樣詳細的指導，但多核設備已被大量使用，不滿足 WCET 要求同樣可能引發安全危險。

隨著實時系統納入更大數據集（尤其用于 AI/ML 推理），內存訪問模式、緩存壓力與多核干擾只會變得更加顯著。僅依賴平均執行時間或孤立任務測量的開發人員，將面臨遺漏關鍵時序缺陷的風險。

借助具備確定性的編譯器、支持追蹤的調試器、運行時驗證工具，再結合靜態、動態與耦合分析，開發人員可獲得系統級可見性，識別隱藏的時序耦合、在真實硬件上準確測量 WCET、驗證確定性行為，并構建安全、可靠、可認證、滿足實時時限的系統。

忽略 WCET 已不再可行。但借助合適的工具、測量方法與方案，開發人員最終能夠掌控最壞情況執行時間，確保實時系統在所有條件下都保持安全、可靠與可認證。