配置管理、問題解決、變更請求管理
SYS/SWE 是「蓋樓」，SUP.8/SUP.9/SUP.10 是「鋼筋混凝土」——沒有它們，版本亂、問題沉、變更失控，一切證據作廢。
基線：AEB_2026.08.16_SWE6_RC1
內容：原始碼 v1.2.3（git tag）、需求庫快照、
資格測試報告 v2、編譯工具鏈 v4.1
狀態：已簽署（release sign-off）、凍結
PR-2026-034｜嚴重度：高 標題：AEB 在 vrel=0 時 TTC 除以零 → 系統重啟 影響：可能導致 AEB 失效（對應 SWR-AEB-011） 原因：未檢查 vrel<1.0 邊界 修正：補輸入驗證（見單元 10） 驗證：UT-015 邊界測試 + 資格測試回歸 → PASS 狀態：已關閉 2026-08-16
早上：資格測試發現 UT-RQ-02 失敗（CAN 亂 CRC 未丟棄） → 開 PR-2026-035（SUP.9） 中午：工程師分析原因 → 提出變更 CR-2026-012（SUP.10） 影響評估：改 CRC 檢查模組；安全影響：無（純改善）；批准 下午：實施 + 單元測試 + 整合回歸 → 更新基線 快照：AEB_2026.08.16_SWE6_RC2（SUP.8） 驗證 PASS → PR 與 CR 關閉
動手：你團隊現在用什麼管版本/問題/變更？畫出現行流程並找出缺口。
SUP.8、SUP.9、SUP.10 常被拆成三個工具畫面，但它們共同回答「現在交付的是什麼、發生了什麼、為什麼要改」。沒有基線，問題無法重現；沒有問題單，修正沒有責任與影響；沒有變更評估，修正可能破壞原有安全論證。安全相關變更要沿著 SG、需求、架構、分析與測試逐項評估，並由批准者決定是否需要重新確認措施。
| 事件 | 必須保留 | 關閉條件 |
|---|---|---|
| 基線 | 版本、工具、文件快照 | 批准與可重建 |
| 問題 | 現象、重現、原因、影響 | 修正與回歸證據 |
| 變更 | 理由、影響、批准、追溯 | 新基線與驗證完成 |
CR-021：將雷達逾時由 50 ms 放寬為 100 ms。 影響：TSR-02、SWR-013、排程、FTTI、故障注入與安全案例。 決策：不得只改一個常數；先由安全工程師確認風險， 更新需求與測試門檻，重跑正常/邊界/故障場景， 再以新基線封存批准、測試與安全案例版本。
不要用 Git commit 訊息或聊天紀錄取代正式變更證據；它們可以作為線索，但不能單獨說明安全影響、批准與驗證責任。
發生問題時，先固定重現版本與工具，再找出最後一個已知良好基線。將問題與需求、程式、測試、配置及變更單關聯，能把「整個系統不可信」縮小成可處理的變更範圍。修正完成後，不只重跑失敗案例，也要依影響分析選擇安全回歸與追溯檢查。
情境：使用 Polyspace 執行靜態分析（MISRA C:2012），需確認工具鑑定等級。 ┌─ 工具鑑定等級（TI/TO/TD）決策 ──────────────────────────┐ │ ISO 26262 Part 8 §11 工具影響分析： │ │ │ │ 工具：Polyspace Bug Finder + Code Prover │ │ 用途：MISRA C:2012 合規檢查 + 程式碼驗證 │ │ │ │ TI（Tool Impact）分析： │ │ 若 Polyspace 產生錯誤結果，是否影響安全？ │ │ → 是（TI1）：Polyspace 的結果直接用於安全驗證 │ │ │ │ TD（Tool Error Detection）分析： │ │ 開發過程能否偵測 Polyspace 的錯誤？ │ │ → 低（TD2）：人工審查難以發現靜態分析工具的誤判 │ │ │ │ 工具鑑定等級 = TI1 × TD2 → TCL2 │ │ │ │ TCL2 要求： │ │ • 工具驗證報告（Validation Report） │ │ • 工具使用規範（Usage Guidelines） │ │ • 誤差率可接受性分析 │ ├─ 工具鑑定執行 ──────────────────────────────────────────┤ │ 1. 取得 Polyspace 的工具驗證報告（Synopsys 提供） │ │ 2. 建立 Polyspace 使用規範： │ │ • 版本鎖定：Polyspace R2023b │ │ • 配置檔鎖定：MISRA C:2012_config.xml │ │ • 分析流程：全量分析 → 手動審查 → 修正 → 再分析 │ │ 3. 誤差率分析： │ │ • 虛假陽性率（False Positive）：≤ 5% │ │ • 虛假陰性率（False Negative）：0% │ │ • 人工審查可過濾所有虛假陽性 │ └────────────────────────────────────────────────────────────┘
ISO 26262 Part 8 §11 要求對用於安全相關開發的工具進行「工具鑑定」。 工具鑑定等級取決於兩個維度：① 工具對開發過程的影響（TI）、② 開發過程能偵測工具錯誤的程度（TD）。
關鍵概念：「工具鑑定」vs「工具驗證」。 工具驗證（Tool Validation）是確認工具按規格運作；工具鑑定（Tool Qualification）是確認工具 在特定使用場景下的可靠性。即使工具通過驗證，若使用場景超出驗證範圍，仍需額外鑑定。
| 症狀 | 可能原因 | 解決方案 |
|---|---|---|
| 工具鑑定等級判斷錯誤 | TI/TD 分析不準確 | 與評鑑師對齊 TI/TD 分析方法，並記錄分析過程 |
| 工具版本升級後鑑定失效 | 新版本的工具行為可能不同 | 版本升級時重新驗證工具鑑定，確保結果一致性 |
| 工具使用規範未被遵守 | 規範太嚴格，團隊不願遵守 | 簡化規範，僅保留關鍵約束，並建立自動化檢查機制 |