單元 3 · ASPICE 全景：過程群組與能力等級

SYS/SWE/SUP/MAN/PIM 過程群、CL0–5、評分 N/P/L/F

← 單元教學

3.1 ASPICE 是什麼

ASPICE（Automotive SPICE，汽車軟體過程改進與能力判定）是汽車產業評估軟體開發過程能力的標準，由 VDA（德國汽車工業協會）維護，源自 ISO/IEC 330xx（SPICE）。它不是評「程式寫得好不好」，而是評「開發過程有沒有能力」。

一句話：ASPICE 的評鑑對象是過程，不是產品。它透過證據（交付物、紀錄、訪談）判斷一個過程做到什麼能力等級。

3.2 五大過程群

過程群代表過程管什麼
SYS 系統工程SYS.1–SYS.5系統需求→系統資格測試
SWE 軟體工程SWE.1–SWE.6軟體需求→軟體資格測試
SUP 支持SUP.1,4,7,8,9,10QA、評審、文件、CM、問題、變更
MAN 管理MAN.3,5,6專案、風險、測量
PIM/REU/ACQ 其他PIM.3、REU.2 等過程改進、重用、供應

車廠最常稽核的是 VDA scope（約 32 個過程），其中 SWE 與 SYS 是核心。

3.3 能力等級 CL0–CL5

每個過程可用能力等級描述「做到多好」：

等級名稱含義
CL0不完全過程未執行或沒產出
CL1已執行達成過程目的（PA1.1 過程執行）
CL2已管理有規劃、監控、調整（PA2.1/2.2）
CL3已建立制度化、標準化、有資源（PA3.1/3.2）
CL4可預測量化管理（PA4.1/4.2）
CL5最佳化持續改進（PA5.1/5.2）
車廠要求：大部分量產專案要求 CL2–CL3。CL3 的關鍵是「制度化」——不靠特定個人，換人也能照流程走。

3.4 評分 N/P/L/F 與過程屬性

評鑑者對每個過程屬性（PA）給出四級評分：

評分達成度代表
N（Not achieved）0–15%幾乎沒做
P（Partially）16–50%部分達成
L（Largely）51–85%大部分達成，有些缺口
F（Fully）86–100%完全達成

例如 SWE.1 要達 CL2，需要 PA1.1 與 PA2.1/PA2.2 都評到 L 以上。評分靠證據：交付物、工具紀錄、訪談一致。

實務陷阱：稽核員最常抓「說一套做一套」——流程文件寫了但實際沒做，或做了沒紀錄。ASPICE 看的是一致性與可驗證性。

3.5 Worked Example：判斷一個過程的等級

範例
評估 SWE.1 軟體需求分析是否達 CL2：

證據 A：需求規格文件存在且有版本（✓）
證據 B：有需求評審會議紀錄（✓）
證據 C：需求變更有正式申請與批准（✓）
證據 D：無「實際用的需求清單」與規格比對（✗ 缺口）

判讀：PA1.1 過程執行 = L（有執行但追溯不完整）
      PA2.1 執行管理 = L（有規劃）
      PA2.2 產品管理 = P（規格與實際需求可能不一致）

結果：未達 CL2（PA2.2 只有 P），需補 D 的雙向追溯。

動手：拿你專案某個過程，試著列出「證據清單」，並判斷各 PA 落在 N/P/L/F。

3.6 深入原理：能力等級是證據鏈的成熟度

CL1 到 CL3 不是把文件數量逐級增加，而是把工作從「有人做過」提升到「可管理、可重複」。CL1 要證明目的達成；CL2 要能規劃、監控、調整並管理工作產品；CL3 再要求組織定義的標準流程、角色、資源與裁剪規則。評鑑員會把過程屬性與實際證據對照，若計畫、工具紀錄與交付物互相矛盾，即使文件看起來完整也不能穩定達標。

問題CL1 證據CL2/CL3 進一步證據
需求是否完成？規格存在審查、基線、變更紀錄
測試是否有效？測試結果計畫、環境版本、問題閉環
能否重複？個人經驗組織流程、範本、訓練與裁剪

3.7 Worked Example：同一份 SWE.1 證據的差異

範例
CL1：SWR 文件存在，工程師能說明來源與內容。
CL2：有需求計畫、審查紀錄、版本基線、變更批准，
     並能由每條 SWR 找到測試或設計下游。
CL3：團隊使用組織標準範本，角色與審查門檻已定義，
     新成員依流程即可產出一致的 SWE.1 證據。

3.8 練習

  1. 以 SWE.4 為例，分別列出 CL1、CL2、CL3 各需要的一項證據。
  2. 找一個「做了但沒留紀錄」的活動，說明它會影響哪個 PA。
  3. 把一項團隊口頭慣例改寫成可裁剪的組織流程規則。
看完這單元你應該能說出：
  • 說出 ASPICE 的五大過程群與代表過程。
  • 解釋能力等級 CL0–CL5 的意義。
  • 說明 N/P/L/F 評分與過程屬性的關係。

延伸閱讀

3.A 進階真實情境 Worked Example

進階範例：自動緊急煞車（AEB）的功能安全概念
系統邊界定義：
┌────────────────────────────────────────────────────────────┐
│                    功能安全概念                              │
│ ┌──────────┐    ┌──────────┐    ┌──────────┐              │
│ │ 雷達感測 │───→│ 融合判斷 │───→│ 煞車執行 │              │
│ │ ASIL C   │    │ ASIL D   │    │ ASIL D   │              │
│ └──────────┘    └──────────┘    └──────────┘              │
│       ↑               ↑               ↑                    │
│   功能異常          判斷錯誤        執行失效                 │
│   (感測遮蔽)       (假陽性)        (液壓洩漏)              │
└────────────────────────────────────────────────────────────┘

功能安全需求分配：
  FSR-01：AEB 必須在 150m 內偵測到靜止車輛（ASIL C）
  FSR-02：AEB 必須在 80m 內偵測到行人（ASIL D）
  FSR-03：從偵測到煞車全壓力 ≤ 300ms（ASIL D）
  FSR-04：誤觸發率 ≤ 1 次/10,000 km（ASIL B）

安全概念設計：
  SM-01：雙雷達交叉驗證（24 GHz + 77 GHz），單一失效不觸發
  SM-02：攝影機辅助辨識，降低誤報率
  SM-03：煞車壓力感測回饋，驗證執行器回應

3.B 深入原理擴充

ISO 26262 Part 3 §7 要求從功能安全概念（Functional Safety Concept） 導出功能安全需求，並分配到系統架構元素。關鍵在於「功能異常」（Malfunctioning Behavior） 的定義——必須區分「功能缺失」（Loss of function）與「功能錯亂」（Degraded/Erroneous function）。

AEB 的核心挑戰：功能錯亂（誤觸發）比功能缺失（不觸發）更危險——誤觸發可能導致後方追尾。 因此安全需求必須同時規範「正向功能」（該觸發時觸發）與「負向功能」（不該觸發時不觸發）， 這在 ASPICE SWE.1 的需求規格中常被忽略。

3.C 診斷式疑難排解表

症狀可能原因解決方案
AEB 誤觸發率過高感測融合演算法未充分驗證邊界條件增加虛擬場景測試（Virtual Testing），覆蓋至少 100 種邊界場景
煞車回應時間超標液壓系統延遲未納入 FTTI 計算重新評估 FTTI，將液壓建延遲納入安全分析
安全需求無法分配到硬體需求粒度過粗將功能安全需求拆分為可驗證的硬體安全需求（Part 4 §7）

3.D 進階挑戰題

  1. 為 AEB 系統設計完整的 FSR→TSR（技術安全需求）追溯矩陣，至少涵蓋 5 條功能安全需求。
  2. 若 AEB 需支援夜間行人偵測，安全需求如何調整？重新評估 ASIL 等級。
  3. 比較「功能缺失」與「功能錯亂」的安全分析方法差異，各舉一例。
← 上一層
單元教學目錄
下一篇 →
單元 4 · 概念階段：Item 定義與 HARA