會議上最常聽到的一句話是「這顆 ECU 是 ASIL D 的」。嚴格說，這句話就是誤解的開始——ASIL 從來不是指派給零件的，它是指派給安全目標的。搞清楚這件事，後面的分解、繼承與測試要求才會順。
ASIL 是怎麼算出來的：S × E × C
ISO 26262 的危害分析與風險評估（HARA）對每一個危害事件評三個軸：
| 軸 | 問的問題 | 級距 |
|---|---|---|
| S 嚴重度（Severity） | 事故發生時，人會傷得多重？ | S0（無傷害）～S3（危及生命） |
| E 暴露率（Exposure） | 這個駕駛情境多常出現？ | E0（極罕見）～E4（高機率） |
| C 可控性（Controllability） | 駕駛或其他人來不來得及化解？ | C0（一般可控）～C3（難以控制） |
三軸查表得出 QM、ASIL A、B、C、D 五級。兩個常見的誤讀：
- QM 不是「不用管」——它代表既有的品質管理流程已足夠，不觸發 ISO 26262 的額外要求
- 同一個系統可以同時背著多個等級——不同安全目標各自有各自的 ASIL
等級決定的是「方法的嚴格度」
ASIL 往下傳遞：安全目標 → 功能安全需求 → 技術安全需求 → 軟硬體需求。等級每高一級，標準推薦（或強烈推薦）的方法就更嚴格。以軟體單元測試的結構覆蓋率為例：
- ASIL A／B：敘述覆蓋、分支覆蓋為主
- ASIL C：分支覆蓋是強烈推薦
- ASIL D：MC/DC（修改條件／判定覆蓋）是強烈推薦
這就是為什麼「等級評高了」不只是文件問題——它直接決定測試工作量、工具鏈與證據形式。用人工方式做 MC/DC 幾乎不可行，這也是 VectorCAST 這類工具存在的理由。
ASIL 分解：合法的降級，有代價的降級
ASIL 分解（Decomposition）允許把一個高等級需求拆給兩個獨立的元素共同承擔，例如 ASIL D 拆成 ASIL B(D) ＋ ASIL B(D)。兩個關鍵：
- 括號裡的 (D) 不會消失——它提醒你系統層的驗證仍然是 D 級要求
- 獨立性要能證明——共因失效分析（CCF）要做，兩條路徑共用電源、共用時脈、共用記憶體都可能讓分解不成立
分解是架構手段，不是文件手段。畫兩個框框不等於獨立。
實務上最常見的三個坑
- 把 ASIL 當成零件屬性採購——供應商給的是「按 ASIL D 流程開發的元件」，但它裝進您的系統後承擔哪個安全目標，要重新對
- E 值評得太樂觀——「這情境很少見」需要依據（市場資料、駕駛統計），不是感覺
- 降級之後測試沒跟著補——分解後兩個 B(D) 元素之間的介面與獨立性驗證，常常沒人認領
下一步
從 HARA 到覆蓋率證據，這條鏈的每一環都要接得起稽核的追問。歐特莫夫（Vector Informatik 合作夥伴）以 VectorCAST 建立由安全需求自動生成、可追溯的測試，覆蓋率含 MC/DC。
- 📄 解決方案：符合 ISO 26262 標準的車用軟體自動化測試工具與服務
- 📬 預約一次現況盤點