(更新2024/03/05) ASPICE v4.0 版本已經正式發布囉！ASPICE Guideline v2.0 也正式發布了！本篇文章來跟大家聊聊，ASPICE v4.0建議的流程導入範圍
ASPICE v4.0 範圍概述
本文，筆者將綜合ASPICE v4.0 版及ASPICE Guideline v2.0(正式版) 的內容，提供最新的ASPICE 導入範圍資訊及建議。
ASPICE v4.0 將流程分成三種類型，分別是基礎(Base)、插件(Plug-ins)及彈性可選(Flex/Optional)，請參考下圖。
屬於基礎(Base)的流程有：
- MAN.3 專案管理 (Project Management)
- SUP.1 品質保證 (Quality Assurance)
- SUP.8 建構管理 (Configuration Management)
- SUP.9 問題解決管理 (Problem Resolution Management)
- SUP.10 變更請求管理 (Change Request Management)
屬於插件(Plug-ins)的流程有：
- 系統工程模組 (共計4個流程):
- SYS.2 系統需求分析 (SYS Requirements Analysis)
- SYS.3 系統架構設計 (SYS Architectural Design)
- SYS.4 系統整合及整合驗證 (SYS Integration and Integration Verification)
- SYS.5 系統驗證 (SYS Verification)
- 軟體工程模組 (共計6個流程):
- SWE.1 軟體需求分析 (SW Requirements Analysis)
- SWE.2 軟體架構設計(SW Architectural Design)
- SWE.3 軟體細部設計及單元開發 (SW Detailed Design and Unit Construction)
- SWE.4 軟體單元驗證 (SW Unit Verification)
- SWE.5 軟體組件驗證及整合驗證 (SW Component Ver. and Integration Ver.)
- SWE.6 軟體驗證 (SW Verification)
- 硬體工程模組 (共計4個流程):
- HWE.1 硬體需求分析 (HW Requirements Analysis)
- HWE.2 硬體設計 (HW Design)
- HWE.3 硬體設計驗證 (Verification against Hardware Design)
- HWE.4 硬體需求驗證 (Verification against Hardware Requirements)
- 機器學習工程模組 (共計5個流程):
- MLE.1 機器學習需求分析 (ML Requirements Analysis)
- MLE.2 機器學習架構 (ML Architecture)
- MLE.3 機器學習訓練 (ML Training)
- MLE.4 機器學習模組測試 (ML Model Testing)
- SUP.11 機器學習之資料管理 (ML Data Management)
屬於彈性可選(Flex/Optional)的流程有：
- SYS.1 需求獲取 (Requirements Elicitation)
- VAL.1 確效 (Validation)
- ACQ.4 供應商監控 (Supplier Monitoring)
- SPL.2 產品發布 (Product Release)
- MAN.5 風險管理 (Risk Management)
- MAN.6 量測 (Measurement)
- PIM.3 流程改善 (Process Improvement)
- REU.2 管理產品之重用 (Management of Products for Reuse)
縮寫備註 SYS- System SW - Software HW- Hardware ML - Machine Learning Ver. - Verification
推薦導入範圍
根據 ASPICE Guideline v2.0(正式版)的推薦，新的VDA Scope將會根據最新發布的ASPICE v4.0的流程來進行挑選，而且會更具彈性。請參考下圖:
如圖所示，VDA Scope將必須搭配基礎(Base)的5個流程，並從插件(Plug-ins)中的4個模組中，至少挑選一個模組；至於其他流程，則可以從彈性可選(Flex/Optional)中挑選。
範圍是否會沿用舊版的16個流程? 根據筆者的研究，ASPICE v4.0中針對舊版既有流程的BP及GP做了很大程度的精簡。這是為了讓評鑑師減少針對既有流程的評鑑時間。因此，當VDA Scope範圍因應新版標準被擴大挑選時，評鑑師仍有足夠的時間進行評鑑。 舉例子來說： ASPICE v3.1 VDA Scope CL2 評鑑，共計需要評估的BP: 127個；GP: 176個 ASPICE v4.0 同樣的Scope CL2評鑑，共計需要評估的BP: 91個; GP: 160個 除此之外，筆者在這幾年間，看到許多車廠及Tier1，除了要求ASPICE之外，亦有要求HW SPICE、Data Management 等標準及流程。 綜上所述，車廠調整範圍的可能性大增！ 實際狀況，還是要請各位讀者參考客戶的要求來決定。 筆者的建議： 1. 保守作法，沿用之前的VDA Scope先以16個流程為主，後續伺機再追加其他流程 2. 積極做法，沿用之前的VDA Scope(16個流程)，額外追加硬體工程的四個流程 3. 其他做法，根據公司的業務範圍來決定範圍(如下圖所示)
額外的問題: 關於 Cybersecurity
為了因應ECE R155，VDA QMC於2021年7月16日發布了一份專注於網絡安全的ASPICE擴充標準：”ASPICE for Cybersecurity”。
這個標準加入了許多與網絡安全開發相關的流程。雖然有傳言稱這些流程會被整合進ASPICE v4.0的新版本中，但在最新的版本裡，我們並未見到網絡安全的相關流程。
這表示VDA QMC不再重視Cybersecurity嗎?
其實不然，VDA的官方網站上依然提供著”ASPICE for Cybersecurity”的資訊，並且許多評鑑師的培訓課程也在積極進行中。我甚至在很多汽車製造商的需求文件裡看到了對這項標準的明確要求。
但是，除了現有的網絡安全開發流程之外，國際標準如ISO/SAE 21434還要求建立一套完整的企業網絡安全管理系統，這不僅包括持續的監控、TARA方法，還有其他後開發階段的流程，這與ECE R155的要求更為相符。
ISO/SAE 21434標準的不足，由ASPICE for Cybersecurity補足
然而，ISO/SAE 21434標準在開發流程的描述上顯得不足，這正是ASPICE for Cybersecurity發揮作用的地方。
事實上，若你細讀ISO/SAE 21434標準，會驚訝地發現其對開發流程的描述十分有限，許多細節需要透過其他標準來補充。因此，在2023年底至2024年初，我聽到許多車廠和Tier 1供應商在專案評鑑中越來越多地轉向要求ASPICE for Cybersecurity。
這一轉變意味著，ISO/SAE 21434標準將更多地被視為一個管理標準，而專案開發則更傾向於整合ASPICE和ASPICE for Cybersecurity。
到目前為止，台灣已經有許多廠商接到了ASPICE for Cybersecurity的評鑑要求。所以，即便已經實施了ISO/SAE 21434，還是需要特別關注來自客戶的特定要求。
關於ASPICE for Cybersecurity標準 讀者可以在VDA QMC網站中取得這份標準，請點選取得ASPICE for Cybersecurity標準
