在安全關鍵實時系統的領域中，精確性不僅是一種偏好，更是生存的必要條件。無論是設計汽車控制單元、醫療設備或航空電子系統，系統行為的可預測性決定了安全完整性等級。UML 時序圖在該生態系統中扮演關鍵角色，用於視覺化事件、訊號與物件生命線之間的時序關係。然而，一張在視覺上看似正確的圖表，可能無法捕捉認證所需的嚴格約束。
本指南提供一套完整的框架，用於在安全關鍵情境下驗證 UML 時序圖。我們專注於結構完整性、時序準確性與可追溯性，且不依賴任何特定商業工具。其目標是確保模型能準確反映硬體與軟體執行環境的實際物理狀況。
📋 為何驗證在安全關鍵環境中至關重要
安全標準如汽車用的 ISO 26262 與工業系統用的 IEC 61508，均要求嚴格的驗證程序。時序圖常用於定義最壞情況執行時間（WCET）、中斷延遲與通訊截止期限。若時序圖存在缺陷，後續的程式碼產生或模擬將不正確，可能導致系統失效，進而危害使用者或環境。
驗證（Validation）與確認（Verification）有所不同。確認問的是：「我們是否正確地建構產品？」（與設計進行比對）。驗證問的是：「我們是否建構了正確的產品？」（與使用者需求及安全需求進行比對）。在時序圖的脈絡中，驗證確保所建模的時序約束確實與處理器的物理能力及通訊匯流排的實際效能相符。
🔍 第一階段：驗證前準備
在檢視圖表本身之前，必須先建立基礎情境。時序圖無法孤立存在；它依賴於狀態機中定義的行為，以及系統架構中定義的時序預算。
- 需求對齊：確保圖表上的每個約束都對應到一項具體的安全需求。不應存在無法追溯的時序約束。
- 情境定義：定義圖表的範圍。它是單一功能、子系統還是整個系統？清晰界定可防止範圍蔓延與歧義。
- 時間參考框架：確認時間是絕對時間（牆鐘時間）還是相對時間（自觸發起算）。若未明確標記而混用兩者，將導致計算錯誤。
- 執行環境：記錄假定的處理器速度、時鐘週期與中斷優先級。圖表必須反映特定的硬體配置。
🏗️ 第二階段：結構驗證
UML 時序圖的結構決定了物件如何隨時間互動。結構錯誤常導致邏輯死鎖或競態條件，這些問題在測試階段難以發現。
2.1 物件生命線與實例名稱
- 唯一性：每條生命線必須擁有唯一識別碼。重複的名稱可能導致可追溯性工具產生混淆。
- 一致性：確保名稱與系統架構文件完全一致。若架構文件將其命名為「Sensor_Module」，則圖表不得使用「Sensor」。
- 活化條：驗證活化條（生命線上的矩形）是否正確代表控制期間。它們應在操作被呼叫時開始，並在操作返回或訊號發送時結束。
- 銷毀事件：若物件被銷毀，請確保「X」標記放置正確。過早銷毀可能導致產生的程式碼出現空指標例外。
2.2 區域與並行
實時系統常需同時處理多個任務。UML 透過組合片段（特別是並行區域）來支援此功能。
- 並行區域：驗證平行區域（標記為「par」）是否準確反映硬體並行性。確保並行性與實際可用的 CPU 核心數量或中斷上下文數量相符。
- 干擾：檢查平行區域之間是否存在共用資源。若兩個平行處理程序在未同步的情況下存取相同的記憶體位址，則該圖表不安全。
- 保護條件：若區域內使用了保護條件，請確保其邏輯正確。若保護條件恆為真或恆為假，則會喪失條件流程的意義。
⏱️ 第三階段：時序驗證
這是時序圖驗證的核心。時序錯誤是安全關鍵系統中非確定性最常見的來源。
3.1 時序約束與數值
- 計量單位：明確標示時間單位（毫秒、微秒、週期）。此處的模糊性常是導致嚴重錯誤的原因。
- 區間與點：安全關鍵系統通常需要區間（最小值/最大值）。請確保圖表支援區間表示法，而非在可能發生變化的情況下使用固定點。
- WCET 分析：所示的每個執行路徑都必須有文件記錄的最壞情況執行時間。若未對某路徑進行分析，則無法在認證圖表中表示該路徑。
- 抖動：考慮通訊中的抖動。若預期信號每 10 毫秒出現一次，則應允許容差。圖表應反映最大允許偏差。
3.2 截止期限合規性
| 約束類型 | 驗證檢查 | 安全影響 |
|---|---|---|
| 硬截止期限 | 驗證信號在時間 T 之前到達。 | 系統故障 / 功能喪失 |
| 軟截止期限 | 驗證信號到達時性能下降最小。 | 性能下降 |
| 週期性 | 驗證重複間隔是否恆定。 | 時序漂移 / 振盪 |
| 延遲 | 驗證從觸發到執行的回應時間。 | 不穩定的控制迴路 |
3.3 時間表達式
- 複雜表達式：避免在時序約束中使用過於複雜的數學表達式。保持其足夠簡單，以便進行數學驗證。
- 相依性：如果時序約束依賴於另一個事件（例如：「時間 = T1 + T2」），請驗證相依鏈是否完整且已定義。
- 溢位：確保時間值不超過底層資料類型的容量（例如：32 位元整數）。這可能導致迴繞錯誤。
📡 第四階段：訊息序列與互動驗證
資料流程決定狀態的變化。錯誤的訊息順序可能導致系統狀態不一致。
4.1 同步與非同步訊號
- 箭頭類型：清楚區分實線箭頭（同步呼叫）與虛線箭頭（非同步訊號）。錯誤混用會暗示不存在的阻塞行為。
- 傳回值：對於同步呼叫，請確保已處理傳回訊號。缺少傳回值可能導致呼叫端無限掛起。
- 發射即忘：對於非同步訊號，請確認發送端不會等待回應。這對於非阻塞的即時任務至關重要。
4.2 遺失或重複的訊號
- 通訊媒介：建立通訊媒介（匯流排、網路、中斷）的模型。該圖是否已考慮訊息遺失的情況？
- 超時：如果訊號可能無法到達，是否已建立超時機制？缺少超時是安全系統中常見的失效模式。
- 重傳：對於重要訊息，若通訊協定要求，請驗證圖中是否顯示重傳邏輯。
⚠️ 第五階段：例外處理與錯誤狀態
正常運作僅是故事的一部分。安全關鍵系統必須能優雅地處理失敗。
- 例外路徑：每個操作都應有相關的例外路徑。如果函式失敗，時序會發生什麼變化？
- 復原時間：模擬從錯誤中恢復所需的時間。這會增加整體延遲預算。
- 失效安全狀態：確保圖表顯示若發生時序違規，系統會進入安全狀態（例如停止馬達）。
- 看門狗計時器：確認圖表已描繪與看門狗計時器的互動。若圖表的執行時間超過看門狗限制，系統必須重設。
🔗 第 6 階段：可追溯性與文件記錄
若無法將已驗證的圖表追溯至需求或向前映射至實現，則該圖表無用。
- 需求連結：每個時序限制都應連結至需求 ID。這讓審計人員得以驗證覆蓋範圍。
- 實現映射：確保圖表映射至實際的原始碼函式。圖表中的函式名稱應與程式碼簽名相符。
- 版本控制：時序圖會演變。請確保版本管理妥善，以避免在生產程式碼中使用過時的模型。
- 變更記錄：記錄時序限制變更的原因。是出於硬體變更還是需求更新？
🛠️ 應避免的常見陷阱
即使是經驗豐富的工程師在模擬時間時也會落入陷阱。請對這些常見問題保持警覺。
- 忽略中斷延遲：假設 CPU 隨時可用。實際上，中斷可能會將任務執行延遲數微秒。請模擬中斷開銷。
- 過度樂觀的時序：使用最佳情況而非最壞情況。安全邊界必須基於最壞可能條件進行計算。
- 忽略資料相依性：兩個任務可能並行，但若其中一個依賴另一個的資料，則它們實際上為串列。請正確建模相依性。
- 靜態 vs. 動態：請勿將靜態時序分析與動態模擬假設混用。它們服務於不同的驗證目的。
- 手動輸入的人為錯誤：若手動輸入數值，請實施同行審查。時間數值中的一個單一字元錯誤即可使安全論證失效。
🔄 持續驗證策略
驗證並非一次性事件。隨著系統演變，時序圖也必須隨之演變。
- 回歸測試：當需求變更時，請在更新後的圖表上重新執行驗證檢查清單。
- 硬體在環測試：將圖表的預測結果與實際硬體效能進行比較。必須解決任何差異。
- 定期審查：安排定期審查時序圖，以確保其仍反映當前的系統架構。
- 自動化檢查：如果建模環境支援，請使用腳本自動驗證語法與基本約束。
📊 驗證檢查清單摘要
為確保安全關鍵設計的穩健性，請在審查過程中使用以下摘要作為快速參考。
- ✅ 情境：是否已定義範圍與時間單位？
- ✅ 結構：生命線與活化條是否準確？
- ✅ 並行性：平行區域是否符合硬體實際情況？
- ✅ 時序：是否已考量最壞情況執行時間（WCET）與抖動？
- ✅ 截止期限：是否已區分硬截止期限與軟截止期限？
- ✅ 訊號：同步與非同步訊號是否明確？
- ✅ 例外情況：是否已建模失效路徑與超時情況？
- ✅ 可追溯性：需求是否與約束條件相連結？
- ✅ 審查：該圖表是否已通過同行審查？
遵循此全面檢查清單可確保您的 UML 時序圖不僅是圖形表示，更是安全、確定性實時系統的可靠藍圖。透過嚴格驗證每個元素，您將降低執行時失敗的風險，並使您的設計符合最高安全標準。
請記住，圖表是設計與實現之間的契約。若契約有缺陷，執行亦將有缺陷。請投入必要的時間與資源於此驗證階段，因為它是系統可靠性的基礎。