安全計畫、確認措施、安全案例、獨立性
Part 2 定義安全活動的管理面：安全計畫、確認措施、安全案例、獨立性。它像是「安全的專案管理」。對應 ASPICE 的 MAN 與 SUP 但更聚焦安全。
安全計畫（AEB）摘要 Wk2 HARA + 安全目標 （安全工程師） Wk4 TSR 定義 （系統工程師） Wk6 SWE.1-2 完成 + 架構評審 （聯合） Wk10 SWE.4 單元驗證完成 Wk12 資格測試 + 確認措施 （獨立檢查員） Wk14 安全案例完成 + 簽署
對安全關鍵活動做獨立檢視，分三種獨立性等級：
| 措施 | 內容 | 獨立性 |
|---|---|---|
| 安全計畫評審 | 審查安全計畫完整性 | I1/I2（依 ASIL） |
| HARA 評審 | 審查危害分析品質 | I2/I3 |
| 安全案例分析 | 審查安全案例論證 | I2/I3 |
安全案例是論證 + 證據：主張「Item 在安全目標下是功能安全的」，並用證據支持。結構常用 GSN（目標結構記號）：
目標 G1：AEB 對「行人碰撞」是功能安全的（ASIL D）
策略：分成「分析證明」＋「測試證明」
├─ G1.1 HARA 完整且 ASIL 正確 → 證據：HARA 報告 + 評審紀錄
├─ G1.2 安全需求已實現並可追溯 → 證據：追溯矩陣 + 需求庫
└─ G1.3 失效風險已量化達標 → 證據：FMEDA 報告
└─ G1.3.1 軟體符合需求 → 證據：SWE.4-6 測試報告
└─ 確認措施完成 → 證據：獨立檢查員簽署
獨立檢查員發現： 論證「雷達離線 200ms 進安全狀態」缺證據——測試只做了 模擬環境，未在目標 ECU 驗證。 行動： 1. 補一條資格測試（目標環境故障注入） 2. 更新安全案例引用新報告 3. 檢查員簽署 → 關閉
動手：為你的安全目標畫一張 2-3 層的安全案例論證圖。
安全案例不是把所有報告堆在一起，而是把主張、推理策略、子主張與證據連成可檢查的論證。每個證據都要有適用範圍、版本與限制；若證據只在模擬環境成立，就不能直接支持目標 ECU 的主張。獨立確認措施的角色，是挑戰假設、找出論證跳躍與證據不足，而不是替作者重寫報告。
| 論證層 | 要問的問題 | 例 |
|---|---|---|
| 主張 | 安全目標是否達成？ | AEB 在危害情境下進入安全狀態 |
| 策略 | 如何拆成可驗證部分？ | 需求、分析、測試三路論證 |
| 證據 | 是否適用且可重現？ | HARA、故障注入、目標環境報告 |
主張：雷達離線後系統在 200 ms 內安全。 現有證據：PC 模擬中逾時旗標可在 120 ms 觸發。 缺口：未證明目標 ECU 的排程、通訊與硬體中斷延遲。 補強：在目標 ECU 注入離線故障，保存時間戳與輸出 log， 並將結果連回 TSR、QT、問題單與確認措施紀錄。
安全案例的最後一頁不應只是簽名。簽署應代表檢查者看過主張、假設、限制與證據，並能指出尚未關閉的殘餘風險與接受決策。
安全案例完成後，團隊仍應能回答「如果這個假設不成立呢？」例如道路情境、硬體失效率、診斷延遲或測試環境改變。把限制與殘餘風險寫出來，不會削弱案例，反而讓安全主張的適用範圍清楚。後續變更要引用原案例，判斷哪些主張需要重新確認。
組織：Tier-1，已完成 CL2 評鑑，目標升級 CL3。
CL3 與 CL2 的核心差異：
┌────────────────────────────────────────────────────────────┐
│ CL2（Managed）：過程有管理地執行 │
│ • BP 完整執行 │
│ • WP 有組織地管理 │
│ • 過程可重複 │
│ │
│ CL3（Established）：過程在組織內制度化 │
│ • 過程標準化：建立組織級的過程標準 │
│ • 過程裁剪：可根據專案特性裁剪過程 │
│ • 過程推廣：過程可在多個專案間推廣 │
└────────────────────────────────────────────────────────────┘
CL3 增強的 BP（以 SWE.1 為例）：
BP.8：確認需求與客户需求的一致性
CL2：進行確認（Validation）
CL3：建立組織級的確認標準，並在多個專案間推廣
BP.9：與相關團隊協調需求
CL2：與相關團隊溝通
CL3：建立跨團隊的溝通機制（如定期協調會、共享需求倉庫）
BP.10：建立需求與工作產品的追溯性
CL2：建立追溯矩陣
CL3：建立組織級的追溯標準，並在多個專案間推廣
CL3 制度化的關鍵活動：
1. 建立「過程擁有者」（Process Owner）角色
2. 建立「過程審計」（Process Audit）機制
3. 建立「過程改進」（Process Improvement）循環
4. 建立「組織過程資產」（Organizational Process Assets）庫ISO 33020 定義「制度化」（Institutionalization）為 CL3 的核心特徵。 制度化意味著過程不僅在特定專案中執行，更在組織內形成標準化的做法—— 包含：標準化（Standardization）、裁剪（Tailoring）、推廣（Deployment）。
關鍵概念：「過程資產」（Process Assets）。 CL3 要求建立組織級的過程資產庫，包含：過程標準、模板、最佳實踐、經驗教訓。 這些資產必須在多個專案間共享和推廣，而非僅服務於單一專案。
| 症狀 | 可能原因 | 解決方案 |
|---|---|---|
| 過程標準過於僵化 | 標準未考慮專案特性差異 | 建立「裁剪指南」（Tailoring Guidelines），允許根據專案特性調整過程 |
| 過程資產庫無人維護 | 缺乏「過程擁有者」角色 | 指定專人負責過程資產庫的維護與更新 |
| 跨專案推廣困難 | 不同專案團隊文化差異 | 建立「過程推廣計畫」，包含培訓、試點、全面推廣三個階段 |