對照矩陣、雙軌流程、分工與交付物
車廠往往同時要求 ISO 26262 合規與 ASPICE 評鑑。若不整合，團隊會做「兩套流程、兩份文件、兩次稽核」——重工且容易不一致。
| ASPICE 過程 | ISO 26262 對應 | 共用交付物 |
|---|---|---|
| SYS.1–SYS.2 | Part 3/4（Item、需求） | 需求規格（含 TSR） |
| SYS.3 | Part 4（系統設計） | 系統架構設計 |
| SWE.1 | Part 6（軟體安全需求） | 軟體需求規格（含 ASIL） |
| SWE.2 | Part 6（軟體架構） | 架構設計（含分區） |
| SWE.3 | Part 6（實作） | 詳細設計＋程式碼 |
| SWE.4–6 | Part 6（驗證） | 測試計畫/報告＋覆蓋率 |
| SUP.8–10 | Part 8（CM/變更/問題） | 基線、CR、PR 追蹤 |
| MAN.3 | Part 2（安全計畫） | 專案＋安全計畫 |
里程碑 M4（架構完成）：
安全軌：SWE.2 + 安全架構評審（確認措施 I2）✓
流程軌：SYS.3/SWE.2 證據齊全（進評鑑抽樣）✓
共用：架構圖一份、追溯矩陣一份
稽核話術：用同一份架構文件回答「架構怎麼分層？」
（ASPICE）與「怎麼避免干擾？」（ISO）
動手：做出你專案的對照矩陣（ASPICE 過程 × ISO 活動 × 交付物），找出一份文件能被兩邊共用的項目。
ASPICE 提供過程管理與追溯的骨架，ISO 26262 提供風險導向的安全內容。整合時先建立共同的工作產品邊界，再為安全屬性加上 ASIL、故障反應、獨立性與安全案例欄位。這樣可以避免重複維護兩份需求，也避免把「ASPICE 有文件」誤當成「ISO 已證明安全」。每個共用工作產品都要有唯一版本、責任人與放行準則。
| 共用物 | ASPICE 關注 | ISO 26262 額外關注 |
|---|---|---|
| 需求規格 | 一致、可追溯、可驗證 | ASIL、故障反應、FTTI |
| 架構 | 分配與介面 | 隔離、冗餘、獨立性 |
| 測試報告 | 需求覆蓋與過程證據 | 安全機制、故障注入、確認 |
TSR-01（ASIL D）：雷達逾時 50 ms 後，100 ms 內禁止新煞車請求。 ASPICE：SYS.2/SWE.1 有來源、屬性、驗收準則與雙向追溯。 ISO：需求連到安全目標、診斷機制、FTTI 分析與故障注入。 共同證據：一條需求、一份架構分配、一組測試， 但安全案例另外引用 ASIL 與獨立確認結果。
整合的成功標誌不是文件數量變少，而是重複內容變少、責任更清楚、證據更容易重建，同時不犧牲安全活動的深度與獨立性。
每個里程碑都應同時列出流程完成條件與安全完成條件。例如架構完成不只代表 SYS.3/SWE.2 文件存在，也代表 ASIL 分配、隔離策略、DFA 假設與評審證據已可追溯。這種共同入口能提前發現「ASPICE 文件完成但安全分析落後」或「安全分析完成但測試證據不足」的錯位。
延伸判讀：共同里程碑的放行條件應同時由流程負責人與安全負責人確認，避免單邊完成造成錯誤放行。
專案：ADAS 系統開發，ASPICE CL3 評鑑在即。 ┌─ 風險識別 ──────────────────────────────────────────────┐ │ 風險 R1：評鑑延誤 │ │ 概率：高（30%） │ │ 影響：高（影響合約交付） │ │ 等級：紅色（需立即處理） │ │ │ │ 風險 R2：評鑑結果不及格 │ │ 概率：中（15%） │ │ 影響：高（需重新評鑑） │ │ 等級：橙色（需重點關注） │ │ │ │ 風險 R3：評鑑範圍爭議 │ │ 概率：中（20%） │ │ 影響：中（需額外時間協調） │ │ 等級：黃色（需監控） │ │ │ │ 風險 R4：評鑑師與團隊溝通不良 │ │ 概率：低（10%） │ │ 影響：中（可能誤解要求） │ │ 等級：黃色（需監控） │ ├─ 風險應對策略 ──────────────────────────────────────────┤ │ R1 應對： │ │ • 建立評鑑前準備時間表（倒推 3 個月） │ │ • 每週追蹤準備進度 │ │ • 備援方案：若延誤，先進行 CL2 評鑑 │ │ │ │ R2 應對： │ │ • 聘請有經驗的 ASPICE 顧問進行預評鑑 │ │ • 針對弱勢 Process Area 加強準備 │ │ • 備援方案：若不及格，3 個月內修正並重新評鑑 │ │ │ │ R3 應對： │ │ • 在合約中明確 ASPICE 評鑑範圍 │ │ • 與評鑑師提前對齊範圍 │ │ • 備援方案：若爭議，由第三方仲裁 │ │ │ │ R4 應對： │ │ • 指定專人作為評鑑師的窗口 │ │ • 建立評鑑前的溝通機制 │ │ • 備援方案：若溝通不良，更換窗口人員 │ └────────────────────────────────────────────────────────────┘
ISO 33020 要求評鑑過程本身也必須進行「風險管理」。 評鑑風險包含：評鑑延誤、評鑑不及格、評鑑範圍爭議、評鑑師與團隊溝通不良等。
關鍵概念：「評鑑風險」的量化評估。 使用概率-影響矩陣（Probability-Impact Matrix）量化評鑑風險，並根據風險等級制定 差異化的應對策略：紅色風險需立即處理，橙色風險需重點關注，黃色風險需定期監控。
| 症狀 | 可能原因 | 解決方案 |
|---|---|---|
| 評鑑延誤導致合約違約 | 準備時間不足，關鍵里程碑延後 | 建立倒推式時間表，每週追蹤進度，提前 1 個月緩衝 |
| 評鑑師對 Process Area 範圍有異議 | 合約中的範圍描述模糊 | 在合約中使用 ISO 33020 的 Process Area 編號，避免文字描述歧義 |
| 評鑑後發現大量隱藏問題 | 內部模擬評鑑不夠深入 | 聘請外部顧問進行預評鑑，提前識別隱藏問題 |