V-model、風險×流程雙主軸、兩套規範的關係
手機 App 出 bug 會閃退，車上的 bug 可能造成人身傷害。汽車電子（引擎控制、煞車、轉向、ADAS）一旦失效，後果不是「重新開機」而是「事故」。這讓車用軟體有了兩層要求：
| 層次 | 回答的問題 | 對應規範 |
|---|---|---|
| 功能安全 | 系統失效時是否安全？風險多高、要做到多安全？ | ISO 26262 |
| 過程能力 | 團隊是否「有能力」把軟體做好？每個階段有沒有做對？ | ASPICE |
V-model 的左邊是逐步向下分解（需求 → 設計 → 實作），右邊是逐層向上驗證（單元測試 → 整合 → 系統驗證）。每一層都有對應的規格與驗證活動：
| V 的位置 | ISO 26262 | ASPICE |
|---|---|---|
| 概念/需求 | Part 3（概念）、Part 4（系統需求） | SYS.1–SYS.2、SWE.1 |
| 設計 | Part 4/5/6（系統/硬體/軟體設計） | SYS.3、SWE.2–SWE.3 |
| 實作 | Part 6（軟體實作） | SWE.3 |
| 驗證 | Part 4/6（整合與驗證） | SWE.4–SWE.6、SYS.4–SYS.5 |
| 管理 | Part 2/8（安全與支持流程） | SUP、MAN |
專案：煞車輔助系統（Brake Assist）
├── 安全軌（ISO 26262）
│ └── 目標：ASIL C，需完成 HARA → 安全目標 → TSR
├── 流程軌（ASPICE）
│ └── 目標：CL2，需完成 SYS.1→SWE.6 全過程交付物
└── 兩者共用
└── V-model 時間軸、同一份需求庫、同一套測試結果
動手：找一個你手邊的車用/安全相關專案，把它拆成「安全軌」與「流程軌」兩欄，各寫出要交付的第一個文件。
安全工程不是在專案末端加一層審查，而是把「風險」轉成可管理的工程約束。HARA 決定風險嚴重度與 ASIL；ASIL 再決定需求、架構、驗證與獨立性需要多強。ASPICE 則把這些活動放進可重複的流程，要求有輸入、活動、輸出與追溯。兩者交會處就是同一份證據：例如一條 ASIL D TSR 既是 ISO 的安全需求，也是 SYS.2 的工作產品，最後由 SWE/SYS 測試報告閉環。
| 若缺少 | 表面現象 | 真正風險 |
|---|---|---|
| HARA | 需求看似完整 | 未定義的危害沒有安全目標 |
| 追溯 | 文件很多 | 無法證明測試真的覆蓋安全需求 |
| 獨立檢查 | 團隊自評通過 | 同一個錯誤可能一路被複製 |
危害：AEB 未在行人前煞車（HARA-01，ASIL D） SG-01 → FSR-01 → TSR-01 → SWR-01 → SYS.2/SWE.1 需求評審 → SWE.4 單元測試 + SWE.6 目標環境測試 → SUP.8 基線與測試證據 閉環檢查：每一層都能向上找到來源、向下找到實現與驗證。
專案背景：OEM 要求開發 EPS，目標 ASIL D + ASPICE CL3。 ┌─ 安全軌 ──────────────────────────────────────────────────┐ │ Item 定義：EPS 馬達驅動、扭矩感測、車速信號、ECU 控制。 │ │ HARA（Part 3）： │ │ H-01 輸出異常扭矩（非駕駛意圖轉向） │ │ 情境：高速公路 120 km/h，駕駛無法及時糾正 │ │ S3 × E4 × C3 → ASIL D │ │ 安全目標 SG-01：EPS 不得輸出超過 ±5Nm 的非預期扭矩。 │ │ 安全機制 SM-01：扭矩輸出與感測交叉驗證，差異 > 2Nm │ │ 持續 3 個週期 → 關閉輔助並進入安全模式。 │ ├─ 流程軌 ──────────────────────────────────────────────────┤ │ ASPICE CL3 要求： │ │ MAN.3 專案計畫需納入安全里程碑（HARA 完成、安全概念凍結）│ │ SWE.1 需求追溯矩陣：功能需求 → 安全需求 → 測試案例 │ │ SYS.2 系統需求規格須含安全需求分配表 │ │ 雙軌交匯點： │ │ 安全需求 = 系統需求的子集，追溯矩陣同時滿足 ASPICE 與 │ │ ISO 26262 Part 4 §7 的雙重要求。 │ └────────────────────────────────────────────────────────────┘
ISO 26262 與 ASPICE 的核心交集在於「需求管理」與「追溯性」。 ISO 26262 Part 2 §6 要求建立安全計畫（Safety Plan），ASPICE MAN.3 要求專案計畫， 兩者合併後形成「整合專案計畫」（Integrated Project Plan），其中安全里程碑嵌入開發流程。
關鍵概念：ASIL decomposition（Part 9）允許將高 ASIL 需求拆分為 多個較低 ASIL 的冗餘需求，分別分配到不同硬體/軟體元件，降低單一元件的開發成本。 但 decomposition 必須滿足 Independence（獨立性）要求——故障偵測、容錯時間間隔（FTTI） 與安全機制覆蓋率需同時驗證。
| 症狀 | 可能原因 | 解決方案 |
|---|---|---|
| 安全需求無法追溯到功能需求 | HARA 遺漏情境或需求編號衝突 | 重建追溯矩陣，使用雙向編號規則（SA-001 → FR-001） |
| ASPICE 評鑑時追溯性不足 | 需求變更未同步更新追溯表 | 導入需求管理工具（如 Jama、DOORS），設定變更觸發同步機制 |