硬體安全需求、FMEDA、隨機硬體失效
ISO 26262 Part 5 硬體層開發：把 TSR 中分配給硬體的部分變成硬體安全需求、硬體設計、硬體驗證，並用量化分析證明隨機硬體失效風險可接受。
| 類型 | 成因 | 處理方式 |
|---|---|---|
| 系統性失效 | 設計/製程/規格錯誤 | 流程（ISO 26262 Part 6/8）+ 測試 |
| 隨機硬體失效 | 物理劣化、輻射等隨機事件 | 量化分析（FMEDA）+ 安全機制 |
| 指標 | 含義 | ASIL D 參考 |
|---|---|---|
| PMHF | 平均每小時失效機率 | < 10⁻⁸ /h |
| SPFM | 單點失效度量 | > 99% |
| LFM | 潛在失效度量 | > 90% |
這些指標用 FMEDA（失效模式、影響與診斷分析）估算：對每個元件列出失效模式、影響、是否被安全機制診斷、殘餘風險。
元件：微控制器 RAM（ASIL D） 失效模式 → 影響 → 安全機制 → 診斷率 單一 bit 翻轉 → 資料錯誤 → ECC 校正 → 99% 雙 bit 翻轉 → 不可校正錯誤 → 錯誤中斷→安全狀態 → 98% 位址解碼失效 → 錯誤寫入 → 記憶體保護檢查 → 95% 合計：PMHF 達標（<10⁻⁸/h）＋ SPFM/LFM 達標
情境：AEB ECU 的 RAM 發生 ECC 不可校正錯誤（UE）
硬體：產生不可遮罩中斷（NMI）→ 觸發安全狀態請求
軟體：NMI handler 在 50ms 內執行：
1. 凍結輸出（煞車請求維持安全值）
2. 記錄錯誤碼與上下文
3. 進入有限安全模式（警示駕駛）
驗證：故障注入測試（強制 UE）證明 NMI→安全狀態 ≤50ms
動手：列舉你系統中「軟體必須應對的 3 個硬體故障」，各配一個偵測與反應。
FMEDA 的價值不是產出一個漂亮的百分比，而是把元件失效模式、系統影響、診斷機制與殘餘風險逐項對上。軟體工程師要確認：診斷訊號是否真的可讀、反應時間是否在 FTTI 內、錯誤旗標是否可能被清除，以及安全狀態是否定義清楚。SPFM/LFM/PMHF 是不同角度的證據，不能用單一指標代替完整失效分析。
| 失效分類 | 意義 | 工程反應 |
|---|---|---|
| 單點失效 | 無診斷即可破壞安全目標 | 增加監視、冗餘或修改架構 |
| 殘餘失效 | 安全機制也失效後仍有風險 | 分析組合故障與 FTTI |
| 潛在失效 | 未被發現且可能削弱備援 | 週期診斷與維修檢查 |
硬體失效：RAM uncorrectable error 置位 UE_INT。 TSR：UE_INT 必須在 10 ms 內被安全軟體確認， 50 ms 內停止使用受影響資料、記錄 DTC 並進入安全狀態。 驗證：故障注入 UE，量測中斷到輸出凍結的時間， 再測重複中斷、啟動期間錯誤與清除旗標失敗。
量化分析與實際測試要互相校正：FMEDA 假設某診斷可在 50 ms 內反應，就必須在軟體與硬體整合測試中量測這個時間，而不能只引用分析表。
FMEDA 的數字必須和元件版本、失效率資料來源、診斷覆蓋假設與使用環境一起閱讀。當硬體料號、時脈、電源或診斷韌體改變，不能只沿用舊的 PMHF 結論。審查時要挑一個代表性失效，從失效模式追到診斷訊號、軟體反應與故障注入結果，確認量化分析不是孤立報告。
系統：電動車電池管理系統（BMS） 需求數量：500+ 條功能需求，其中 120 條為安全關鍵需求（ASIL B/C/D） ┌─ 追溯矩陣架構 ──────────────────────────────────────────┐ │ Level 1：客戶需求 → 系統需求 │ │ CR-001 → SR-001, SR-002, SR-003 │ │ │ │ Level 2：系統需求 → 硬體需求 │ │ SR-001 → HW-001 (電壓感測精度 ±5mV) │ │ │ │ Level 3：系統需求 → 軟體需求 │ │ SR-001 → SW-001 (電壓濾波演算法) │ │ │ │ Level 4：軟體需求 → 軟體單元 │ │ SW-001 → UC-001 (voltage_filter.c) │ │ │ │ Level 5：軟體單元 → 測試案例 │ │ UC-001 → TC-001, TC-002, TC-003 │ │ │ │ Level 6：安全需求 → 安全驗證 │ │ SA-001 → SV-001 (故障注入測試) │ ├─ 安全關鍵需求的特殊要求 ──────────────────────────────────┤ │ 1. 雙向追溯：每個安全需求必須同時有前向和後向追溯 │ │ 2. 覆蓋率檢查：每個安全需求至少被 1 個測試案例覆蓋 │ │ 3. 變更影響分析：安全需求變更時，自動識別影響範圍 │ │ 4. 版本控制：安全需求變更需保留完整歷史紀錄 │ │ │ │ 工具：Jama Connect + 自動化腳本 │ │ • 每週自動檢查追溯完整性 │ │ • 變更時自動通知相關人員 │ │ • 覆蓋率儀表板（Dashboard）即時顯示 │ └────────────────────────────────────────────────────────────┘
ISO 26262 Part 8 §6 要求「需求管理」必須建立雙向追溯性。 ASPICE SWE.1 / SYS.2 也有類似要求，但 ISO 26262 的追溯性要求更嚴格—— 必須覆蓋從客戶需求到安全驗證的完整鏈路。
關鍵概念：「追溯性矩陣」的自動化。手動維護追溯矩陣在 500+ 條需求的規模下 幾乎不可能——每週變更 5-10 條需求，手動更新追溯矩陣會成為瓶頸。自動化工具（如 Jama Connect） 可以：① 自動檢查追溯完整性、② 變更時自動識別影響範圍、③ 即時顯示覆蓋率。
| 症狀 | 可能原因 | 解決方案 |
|---|---|---|
| 追溯矩陣缺口（Gap） | 需求變更時未同步更新追溯 | 建立變更觸發機制：需求變更 → 自動檢查追溯 → 通知相關人員 |
| 追溯矩陣過於龐大無法維護 | 需求粒度過細，追溯關係過多 | 按 ASIL 等級分層管理：安全關鍵需求單獨管理，非安全需求簡化追溯 |
| 工具導入後追溯完整性反而下降 | 團隊未正確使用工具 | 提供充分培訓，並建立「工具使用規範」文件 |