全流程走查、工具鏈、時間軸
本單元把一個虛構但完整的專案從頭走到尾：HARA → 安全需求 → 系統/軟體開發 → 驗證 → 安全案例，每個階段標出 ISO 26262 與 ASPICE 的對應交付物。
| 階段 | 關鍵交付物 | 對應 |
|---|---|---|
| 1. 概念 | Item 定義、HARA、SG | ISO Part 3｜SYS.1 |
| 2. 需求 | FSR/TSR、系統需求 | ISO Part 4｜SYS.2 |
| 3. 架構 | 系統架構、SWR、軟體架構 | Part 4/6｜SYS.3/SWE.1-2 |
| 4. 實作 | 詳細設計、程式碼 | Part 6｜SWE.3 |
| 5. 單元驗證 | 單元測試＋覆蓋率 | Part 6｜SWE.4 |
| 6. 整合 | 整合測試 | Part 6｜SWE.5 |
| 7. 資格 | 資格測試報告 | Part 6｜SWE.6 |
| 8. 系統 | 系統整合＋資格 | Part 4｜SYS.4-5 |
| 9. 安全 | FMEDA、FTA、安全案例 | Part 5/9/2｜SUP/MAN |
【階段1 概念｜ISO Part 3｜SYS.1】
Item：電動車窗（含防夾）。邊界：開關、馬達、位置感測、致動。
HARA 摘要：
H-01 防夾失效，車窗夾住孩童頸部
S3 E3 C3 → ASIL B
SG-01（ASIL B）：升起時偵測到阻力異常，必須在 200ms 內
停止並反轉 100mm，且單一感測器故障不延遲反應。
【階段2 需求｜Part 4｜SYS.2】
FSR-01（ASIL B）：窗上升時連續量測阻力。
TSR-01（ASIL B）：以馬達電流估阻力；採樣 ≥ 1kHz。
驗收：夾持力峰值 ≤ 100N（法規參考）。
【階段3 架構｜SWE.1-2】
SWR-011（ASIL B）：電流 → 阻力估測（低通濾波）。
SWR-012（ASIL B）：阻力超過閾值 → 反轉指令。
SWR-013（ASIL B）：感測器異常 → 200ms 內停止＋反轉。
架構：馬達驅動層（隔離）＋ 防夾邏輯層（ASIL B）。
【階段4 實作｜SWE.3】
寫碼：filter.c / anti_pinch.c / motor_ctrl.c
套用 MISRA C 子集＋輸入驗證（電流範圍檢查）。
【階段5 單元驗證｜SWE.4】
UT：阻力估測邊界、反轉時序、感測器故障。
覆蓋率：語句/分支 100%（ASIL B 至少語句）。
【階段6 整合｜SWE.5】
整合馬達驅動＋防夾邏輯，驗證中斷優先權與資源。
【階段7 資格｜SWE.6｜目標環境】
QT：夾持力測試（實測 ≤ 100N）、感測器故障注入
（200ms 內反轉）、500 次耐久迴歸。PASS。
【階段8 系統｜SYS.4-5】
裝上車門總成：整合測試＋整車資格（環境、電磁相容）。
【階段9 安全｜Part 2/5/9】
FTA：頂端「未反轉」→ OR（邏輯缺陷/感測器失效/馬達卡死）。
FMEDA：感測器診斷率達標。安全案例：全部證據＋簽署。
| 用途 | 工具例 | 對應 |
|---|---|---|
| 需求管理 | Polarion / DOORS / Jama | SWE.1、追溯 |
| 版本控制 | Git + GitLab/GitHub | SUP.8 |
| 問題/變更 | Jira + 流程 | SUP.9/10 |
| 靜態分析 | Polyspace / Cppcheck | SWE.4 |
| 單元測試 | Unity/Ceedling + gcov | SWE.4 |
| 測試執行 | Vector CANoe / HIL | SWE.6/SYS.5 |
| CI/CD | GitLab CI / Jenkins | 全部（自動化證據） |
全流程走查的重點不是記住活動順序，而是確認每個決策都能被後續證據驗證。HARA 的危害要產生安全目標；安全目標要分解成可實作需求；需求要落到架構、程式與測試；測試失敗要進問題與變更流程；最終安全案例要能引用所有關鍵證據。任何一條鏈只向下沒有向上，或只向上沒有測試，都代表論證不完整。
| 閉環檢查 | 起點 | 終點 | 失敗訊號 |
|---|---|---|---|
| 安全閉環 | 危害 | 安全狀態測試 | 安全目標沒有測試 |
| 需求閉環 | SG/FSR/TSR | QT 報告 | 孤兒需求或孤兒測試 |
| 變更閉環 | 問題/CR | 新基線與案例 | 修碼但未重評估 |
抽查安全目標 SG-01： ✓ 找到 HARA-01 與 ASIL 理由 ✓ 找到 FSR/TSR/SWR 與架構分配 ✓ 找到 SWE.4-6、SYS.5 的正常與故障測試 ✓ 找到 FMEDA/FTA/DFA 與確認措施 ✗ QT-042 使用的 ECU 軟體版本不在候選基線 結論：先阻擋放行，修正配置追溯並確認報告可重現， 不能因其他項目 PASS 就忽略這個證據斷點。
組織：已完成 ASPICE CL3 + ISO 26262 符合性確認，進入持續改進階段。 ┌─ 持續改進框架（PDCA）─────────────────────────────────────┐ │ Plan（計畫）： │ │ • 建立年度過程改進目標 │ │ • 識別改進機會（來自評鑑、客戶回饋、內部審計） │ │ • 制定改進計畫 │ │ │ │ Do（執行）： │ │ • 在試點專案中執行改進措施 │ │ • 收集執行數據 │ │ • 調整改進措施 │ │ │ │ Check（檢查）： │ │ • 評估改進效果 │ │ • 比較改進前後的過程績效 │ │ • 識別新的改進機會 │ │ │ │ Act（行動）： │ │ • 將有效的改進措施標準化 │ │ • 更新過程資產庫 │ │ • 在組織內推廣 │ ├─ 持續改進的數據驅動 ────────────────────────────────────┤ │ 過程績效指標（Process Performance Indicators）： │ │ • 缺陷密度（Defect Density）：目標 ≤ 0.5 缺陷/千行程式碼│ │ • 需求變更率（Requirement Change Rate）：目標 ≤ 10% │ │ • 測試覆蓋率（Test Coverage）：目標 ≥ 95% │ │ • 評鑑不符合項數（Non-conformances）：目標 ≤ 5 │ │ │ │ 數據收集： │ │ • 每月收集過程績效數據 │ │ • 每季分析趨勢 │ │ • 每年更新改進目標 │ ├─ 安全改進循環 ──────────────────────────────────────────┤ │ ISO 26262 Part 8 §10 要求： │ │ • 收集量產後的安全相關故障資料 │ │ • 分析安全相關事件的根因 │ │ • 評估是否需要修改設計 │ │ • 執行安全改進措施 │ │ • 驗證改進效果 │ │ • 更新安全相關文件 │ └────────────────────────────────────────────────────────────┘
ISO 33020 與 ISO 26262 Part 8 都要求「持續改進」—— 但改進的重點不同：ISO 33020 關注過程成熟度提升，ISO 26262 關注安全完整度提升。
關鍵概念：「數據驅動的改進」（Data-Driven Improvement）。 持續改進不能靠直覺——必須建立量化的過程績效指標（PPI），並基於數據做出改進決策。 例如：若缺陷密度持續上升，可能是需求品質下降或測試不足；若需求變更率過高， 可能是需求收集階段的客戶參與不足。
| 症狀 | 可能原因 | 解決方案 |
|---|---|---|
| 持續改進流於形式 | 缺乏量化的過程績效指標 | 建立 PPI 儀表板，每月追蹤，每季分析趨勢 |
| 改進措施無法推廣到其他專案 | 缺乏過程資產庫和推廣機制 | 建立過程資產庫，並指定「過程擁有者」負責推廣 |
| 安全改進措施與過程改進措施衝突 | 兩套改進體系未整合 | 建立統一的改進管理機制，協調安全改進與過程改進 |