系統整合策略、資格測試計畫、結果報告
| 過程 | 目的 | 測試的是 |
|---|---|---|
| SYS.4 系統整合 | 把子系統組合成完整系統 | 介面、資料流、元件間互動 |
| SYS.5 系統資格測試 | 證明系統符合系統需求 | 系統級行為、驗收準則 |
系統資格測試計畫（AEB） 測試環境：HIL（含煞車致動器模擬）+ 場景庫 + 部分實車驗證 測試項目（抽樣）： QT-SYS-01 行人穿越（日間/夜間） → 期望：煞車啟動 TTC<1.2s QT-SYS-02 靜止物體 30m → 期望：0.6g 減速啟動 QT-SYS-03 雷達離線（故障注入） → 期望：200ms 內安全狀態 QT-SYS-04 誤觸發檢查（高架橋/路樹）→ 期望：誤觸發率 ≤ 0.1% 通過門檻：所有測試無 CRITICAL 失敗；誤觸發率達標
第1天 接好 CAN 拓樸，驗證雷達→ECU 通訊（frame 數與 CRC） 第2天 串通 ECU→致動器指令，驗證 20ms 延遲 第3天 加入 TTC 決策邏輯（stub 場景） 第4天 用 20 個基本場景跑通 AEB 啟動/停止 第5天 跑完整 80 場景回歸 + 故障注入（雷達離線） 第6天 整理結果：3 個失敗 → 開問題單（見單元 16 SUP.9）
動手：為你專案規劃一個「整合一週」，列出每天的驗證目標與測試。
SYS.4 的核心不是「把所有東西接起來」，而是以可控順序建立子系統，逐步確認介面契約、資料單位、時序與錯誤傳播。SYS.5 則以系統需求為測試基準，從外部可觀測行為判斷是否符合。好的測試案例同時定義刺激、觀測點、時間窗、環境配置與失敗處置，避免只記錄最後的 PASS/FAIL 而無法重現。
| 測試元素 | 應記錄 | 缺少時的問題 |
|---|---|---|
| 刺激 | 訊號、場景、故障注入 | 無法重現 |
| 觀測 | 輸出、DTC、狀態、時間戳 | 只知道失敗，不知原因 |
| 環境 | 軟體版本、硬體、工具設定 | 結果不可比較 |
QT-SYS-03 FAIL：雷達離線後 200 ms 仍有 BRAKE_REQUEST。 觀測：心跳最後時間戳 10.000 s；安全狀態訊號 10.245 s。 初判：逾時門檻 50 ms + 任務排程 200 ms 的預算不一致。 處置：開 SUP.9 問題單，追溯到 TSR-02 與排程設計， 修正後重跑正常、邊界與重啟場景，而不是只重跑原案例。
一份合格的系統資格報告要能讓未參與測試的人重建結論：他應知道測了哪個版本、在什麼環境、用什麼刺激、看到什麼輸出，以及為何判定通過。只有摘要數字而沒有原始證據，無法支撐安全案例或稽核。
若一條需求只描述正常道路情境，請補一個邊界情境與一個故障情境，並說明它們是否屬於同一測試目的。這個練習能避免把「功能通過」誤認為「失效時也安全」。
放行不是看測試案例數量，而是確認需求覆蓋、環境配置、未關閉問題與安全影響都已被判定。任何高嚴重度失敗、無法重現的結果或版本不一致，都應阻擋放行並建立問題單。低嚴重度例外也要有明確接受者、補救期限與回歸計畫。
情境：EPB 已通過 ASPICE CL3 評鑑，進入量產階段。 量產安全管理重點： ┌─ 生產階段（Part 4 §8）───────────────────────────────────┐ │ 1. 生產過程的安全驗證： │ │ • 每批 ECU 出廠前執行功能測試（EPB 驗證） │ │ • 測試項目：夾緊力、回應時間、功耗 │ │ • 測試設備年度校準（±2% 精度要求） │ │ │ │ 2. 生產缺陷率監控： │ │ • 目標：DPPM < 10（每百萬件 < 10 個缺陷） │ │ • 監控：SPC 統計製程控制，Cpk ≥ 1.67 │ │ • 異常：觸發 8D 報告流程 │ ├─ 運維階段（Part 4 §8.4）────────────────────────────────┤ │ 1. 客戶回饋分析： │ │ • 收集保修資料（Warranty Data），分析安全相關故障 │ │ • 安全相關故障分類：安全相關 / 非安全相關 │ │ • 安全相關故障 → 啟動「安全相關事件分析」 │ │ │ │ 2. OTA 更新的安全管理： │ │ • OTA 前：驗證更新包完整性（E2E + 數位簽章） │ │ • OTA 中：確保更新過程中安全功能不受影響 │ │ • OTA 後：執行安全驗證測試 │ ├─ 退役階段（Part 4 §8.5）────────────────────────────────┤ │ 1. 安全相關資料保留：至少 15 年 │ │ 2. 安全相關故障統計：終身追蹤 │ └────────────────────────────────────────────────────────────┘
ISO 26262 Part 4 §8 明確定義了「生產、運營與退役」階段的安全活動。 這部分常被忽略——多數團隊將注意力集中在開發階段，忽略了量產後的安全監控。
關鍵概念：「安全相關事件」（Safety-Related Events）。ISO 26262 要求 建立回饋機制（Feedback Loop），收集量產後的安全相關故障資料，並評估是否需要修改設計。 這與 ASPICE SWE.1 的「維護計畫」形成互補——ASPICE 關注軟體維護，ISO 26262 關注安全維護。
| 症狀 | 可能原因 | 解決方案 |
|---|---|---|
| 量產缺陷率超標 | 製程能力不足（Cpk < 1.33） | 執行製程能力分析，調整製程參數或增加檢測站點 |
| OTA 更新後安全功能異常 | 更新包簽章驗證失敗或版本不相容 | 增加回滾機制（A/B 分區），確保更新失敗時恢復原版本 |
| 客戶回饋的安全故障分析延遲 | 保修資料格式不統一，分類困難 | 建立統一的安全故障分類碼（Safety Fault Code），與保修系統整合 |