分析方法選擇、ASIL 導向、分析表格
| 工具 | 方向 | 問的問題 |
|---|---|---|
| FMEA | 自下而上 | 某元件失效會造成什麼影響？ |
| FTA | 自上而下 | 這個頂端失效是由哪些原因組合而成？ |
| DFA | 跨元件 | 元件是否獨立？有無共因/串聯失效？ |
項目 失效模式 影響 S O D RPN 煞車致動器 不回應指令 無法減速→撞擊 9 3 2 54 雷達模組 離線（無輸出） 無法偵測→撞擊 9 4 3 108 ← 高 CAN frame CRC 錯誤漏檢 錯誤訊號 8 2 5 80 改善：雷達離線加 Watchdog（D→1）→ RPN 36
頂端：AEB 未執行煞車
├─OR─ 雷達未偵測到目標
│ ├─ 雷達失效（隨機） ← 硬體
│ └─ 雷達訊號被遮蔽（系統性） ← 部署
└─OR─ 煞車命令未執行
├─ ECU 未發出指令（軟體缺陷）
└─ 致動器失效（隨機硬體）
解讀：軟體缺陷是 OR 分支之一 → 需要測試/防禦式設計
隨機硬體 → 需診斷與安全機制
FMEA、FTA、DFA 不是互斥的報告格式。FMEA 從元件失效往上追影響，適合檢查安全機制是否能偵測；FTA 從安全目標往下拆原因，適合檢查是否遺漏軟體、硬體、介面或環境因素；DFA 檢查冗餘路徑是否真的獨立，特別關注共因失效、共享電源、共享時脈、共享資料與共同流程缺陷。三者的結果要回寫需求、架構、測試與 FMEDA。
| 分析結果 | 應回饋到 | 完成判準 |
|---|---|---|
| FMEA 發現未偵測失效 | 安全機制、TSR、測試 | 有 owner 與故障注入證據 |
| FTA 出現單一 OR 分支 | 架構、冗餘、FMEDA | 風險降低或正式接受 |
| DFA 發現共同依賴 | 分區、介面、ASIL 分解 | 獨立性論證完成 |
頂端事件：AEB 未煞車。 FTA 顯示主路徑與監視路徑都依賴同一個 5V 電源與同一個時脈。 即使兩個軟體元件不同，電源掉壓會同時讓兩者失效， 因此「冗餘」不能直接宣稱獨立。DFA 行動：加入獨立電源監視、 檢查時脈共因，並把結果回寫到架構與 ASIL 分解論證。
分析表不應在設計完成後被當成靜態附件；當架構、ASIL 分解或安全機制改變時，應重新確認分析假設與殘餘風險。
如果 FMEA、FTA、DFA 只產生風險顏色，卻沒有導致需求、架構、診斷或測試改變，分析活動就沒有完成目的。每個高風險結果都應有處置選項：降低失效可能性、增加偵測、限制影響、加入獨立路徑，或由授權角色接受殘餘風險。處置完成後要重新分析，而不是把原表格標成已完成。
延伸判讀：若分析結果沒有改變任何需求、架構或測試，請回到分析邊界與失效假設重新檢查。
專案背景：Tier-1 開發 ADAS 系統，需要同時滿足 ASPICE 與 ISO 26262。 ┌─ 過程範圍選擇決策 ──────────────────────────────────────┐ │ 決策因素： │ │ 1. 客戶要求（OEM 合約中的 ASPICE 等級要求） │ │ 2. 安全等級（ASIL 等級影響 Process Area 選擇） │ │ 3. 組織成熟度（避免選擇超出能力的 Process Area） │ │ │ │ OEM 合約要求： │ │ • SWE.1 ~ SWE.5：CL2 │ │ • SYS.1 ~ SYS.5：CL2 │ │ • MAN.3：CL2 │ │ • SUP.1：CL2 │ │ │ │ ISO 26262 隱含要求： │ │ • SWE.1（軟體需求分析）：ASIL D 要求 CL3 │ │ • SWE.2（軟體架構設計）：ASIL D 要求 CL3 │ │ • SWE.4（軟體單元驗證）：ASIL D 要求 CL3 │ │ │ │ 決策： │ │ 基礎範圍：OEM 要求的 Process Area（CL2） │ │ 增強範圍：ISO 26262 隱含的 Process Area（CL3） │ │ 總計：12 個 Process Area，其中 3 個需達 CL3 │ ├─ 風險評估 ──────────────────────────────────────────────┤ │ 風險 1：範圍過大導致評鑑延誤 │ │ → 分階段評鑑：第一階段先評 CL2，第二階段升級 CL3 │ │ │ │ 風險 2：ISO 26262 隱含要求模糊 │ │ → 與評鑑師對齊：明確哪些 Process Area 因 ASIL D 需要 │ │ 提升到 CL3 │ │ │ │ 風險 3：組織資源不足 │ │ → 建立內部培訓計畫，提升團隊能力 │ └────────────────────────────────────────────────────────────┘
ASPICE 評鑑範圍的選擇不是「越多越好」——必須根據客戶要求、 安全等級、組織成熟度三個因素綜合考量。
關鍵概念：「過程範圍」（Process Scope）的策略性選擇。 過多的 Process Area 會導致評鑑成本急劇上升（每個 Process Area 需要 1-2 個月的準備）； 過少的 Process Area 則無法滿足客戶和安全要求。最佳策略是「先聚焦、再擴展」—— 選擇最關鍵的 5-8 個 Process Area 先達到目標等級，再逐步擴展。
| 症狀 | 可能原因 | 解決方案 |
|---|---|---|
| 評鑑範圍選擇不當 | 未充分了解客戶要求或安全要求 | 在合約談判階段明確 ASPICE 範圍，並與 ISO 26262 要求交叉檢查 |
| 評鑑成本超標 | Process Area 過多，準備工作量大 | 分階段評鑑：第一階段先評核心 Process Area，第二階段再擴展 |
| 評鑑後無法維持 | Process Area 過多，日常執行負擔重 | 將 Process Area 納入日常流程，避免「為評鑑而評鑑」 |