ASPICE v3.1 與 ASPICE v4.0 差異概述

(更新2024/4/24) ASPICE 的最新版本 (v4.0) 已經於2023年12月15日正式發布囉！本篇文章來跟大家聊聊新版與舊版之間的主要差異。

Table of Contents

ASPICE v4.0 概述

目前最新版的ASPICE標準為4.0版，該版本是在2023年12月15日，發布於VDA QMC網站。與之共同發布的還有一份ASPICE Guideline 2.0 的正式版。

額外說明: 
ASPICE v4.0的前一個版本是v3.991版(黃色草稿版)，該版本於2023年6月6日發布於VDA QMC網站，與之共同發布的還有一份ASPICE Guideline 2.0 草稿版。

備註：
目前這兩份文件在VDA QMC網站，已經無法取得。讀者如果有興趣，歡迎來信詢問 :)

本文章，筆者就以目前ASPICE v4.0版中的內容與ASPICE v3.1版進行比較，並提出綜合對照的觀點，期望本篇文章的內容能夠提供給大家參考。

ASPICE v4.0 共計有32個流程，新版標準共移除10個舊流程，額外新增了10個流程。請參考下圖。

關於工程流程的變更，總計增加了三個模組：

硬體工程模組 (共計4個流程):
- HWE.1 硬體需求分析 (HW Requirements Analysis)
- HWE.2 硬體設計 (HW Design)
- HWE.3 硬體設計驗證 (Verification against Hardware Design)
- HWE.4 硬體需求驗證 (Verification against Hardware Requirements)
機器學習工程模組 (共計4個流程)
- MLE.1 機器學習需求分析 (ML Requirements Analysis)
- MLE.2 機器學習架構 (ML Architecture)
- MLE.3 機器學習訓練 (ML Training)
- MLE.4 機器學習模組測試 (ML Model Testing)
確效流程模組 (共計1個流程)
- VAL.1 確效 (Validation)

關於支援流程的變更，總計增加了一個流程：

SUP.11 機器學習之資料管理 (ML Data Management)

其他被移除的流程，分別條列如下：

ACQ.3 合約協議 (Contract Agreement)
ACQ.11 技術性需求 (Technical Requirements)
ACQ.12 合規及管理需求 (Legal and Administrative Requirements)
ACQ.13 專案需求 (Project Requirements)
ACQ.14 需求建議書 (Request for Proposal)
ACQ.15 供應商資格 (Supplier Qualification)
SPL.1 供應商招標 (Supplier Tendering)
SUP.2 驗證 (Verification)
SUP.4 聯合審查 (Joint Review)
SUP.7 文件管理 (Documentation)

額外說明 -- 被移除流程與其他標準之對應關係

本次被移除的標準中，有許多流程過去並未列在VDA Scop範圍中，這些流程將與現有的標準進行整合，並提供相應之證據。

例如: ACQ.3, 11, 12, 13, 14, SPL.1
將整合於品質管理系統之「供應商-採購管理程序」

例如: ACQ.15
將整合於品質管理系統之「供應商管理程序」
供應商資格之管理在ISO 26262及ISO/SAE 21434均有提到

例如: SUP.7 
將整合於品質管理系統之「文件管理程序」
文件管理在ISO 26262及ISO/SAE 21434均有提到

其他: SUP.2, SUP.4
將與公司現有之會議、審查等程序整合
「審查」在ISO 26262有提到

ASPICE v4.0 與ASPICE v3.1版比較概述

筆者針對新舊兩個版本的標準中，相同之流程進行比較分析，其比較概述條列如下：

流程 ID	主要差異概述	變化程度
MAN.3	1. 針對每個里程碑的發布內容應詳細定義 2. 針對未滿足的承諾應定義事態升級機制	低
ACQ.4	1. 針對供應商開發過程發現的問題，增加協議變更的選項	低
SYS.1	1. 不須針對這個階段的需求進行基準(Baseline)	低
SYS.2	1. 撰寫的需求格式嚴格度提高 2. 不須撰寫驗證準則(Verification Criteria) 3. 針對系統全景影響分析 (與ISO 26262/ ISO 21434關聯提高)	中
SYS.3	1. 強調靜態與動態架構之定義 2. 不須評估多個候選架構 3. 需要分析系統架構 (與ISO 26262/ ISO 21434關聯提高)	中
SYS.4	1. CL1 不須制定計畫 (整合策略、整合驗證策略不須定義) 2. CL2 根據專案實際需求制訂計劃 3. 測試改驗證	中
SYS.5	1. CL1 不須制定計畫 (驗證策略不須定義) 2. CL2 根據專案實際需求制訂計劃 3. 測試改驗證	低
SWE.1	1. 撰寫的需求格式嚴格度提高 2. 不須撰寫驗證準則(Verification Criteria)	中
SWE.2	1. 強調靜態與動態架構之定義 2. 不須評估多個候選架構 3. 需要分析系統架構 (與ISO 26262/ ISO 21434關聯提高)	中
SWE.3	1. 強調靜態與動態架構之定義 2. 不須評估細部架構 (6面向評估被移除，讀者需在CL2 根據專案需求自行制訂需要評估之準則)	低
SWE.4	1. CL1 不須制定計畫 (單元驗證策略不須定義) 2. CL2 根據專案實際需求制訂計劃	低
SWE.5	1. CL1 不須制定計畫 (整合策略、整合驗證策略不須定義) 2. CL2 根據專案實際需求制訂計劃 3. 增加與細部設計之間的整合驗證 4. 強調組件個別驗證 5. 強調組件之間的整合驗證 6. 測試改驗證	高
SWE.6	1. CL1 不須制定計畫 (驗證策略不須定義) 2. CL2 根據專案實際需求制訂計劃 3. 測試改驗證	低
SPL.2	1. CL1 不須制定計畫 (發布計畫不須定義) 2. CL2 根據專案實際需求制訂計劃 3. 許多發布細節被移除 (發布媒體、包材、撰寫發布說明書、等)	中
SUP.1	1. CL1 不須制定計畫 (品質保證計畫不須定義) 2. CL2 根據專案實際需求制訂計劃 3. 更強調品質保證執行人員的獨立性與客觀性	低
SUP.8	1. CL1 不須制定計畫 (建構管理計畫不須定義) 2. CL2 根據專案實際需求制訂計劃 3. 移除分支與合併的條文 (改根據專案需求自行定義) 4. 強調資料管理的有效性 (備份與還原演練)	中
SUP.9	1. CL1 不須制定計畫 (問題解決管理計畫不須定義) 2. CL2 根據專案實際需求制訂計劃	低
SUP.10	1. CL1 不須制定計畫 (變更請求管理計畫不須定義) 2. CL2 根據專案實際需求制訂計劃 3. 分析變更請求時不再需要定義驗證準則(Verification Criteria) 4. 變更請求結束後的溝通對象	低

更細部的比較分析

由於本文章的篇幅有限，筆者將額外撰寫文章逐一介紹各流程之間的差異，請參考ASPICE v4.0 與ASPICE v3.1版比較目錄

ASPICE v4.0 新增流程概述

確效流程(VAL.1) 概述

本次新增的流程VAL.1，其目的是確認最終產品(允許與最終使用者直接互動)，在其目標運作環境下，能滿足預期使用者的期望。

在ASPICE Guideline v2.0中說明：VAL.1流程主要是為了確認產品的「預期使用」，從而滿足產品的最終使用者需求，因此，本流程僅是適用於具備與最終使用者存在介面的產品；純粹的嵌入式軟體產品(Pure embedded software)、軟體驅動程式(Driver)、或ECU等…，這些產品都不提供直接的最終用戶介面，因此，並不包含在本流程的範圍內。

額外補充

所謂的「預期使用者的期望」屬於利益相關者需求的一部分，因此可以進一步解釋為，根據利益相關者需求進行最終產品之確效。

如果專案開發之產品，具備與最終使用者互動之介面，則最終該產品適用於本流程。

硬體工程(HWE)流程概述

過去ASPICE被認為只有軟體部門才需要參與，但是在車用的許多標準，都可以清晰地看到軟體與硬體共同開發的流程。經過了ASPICE標準制定小組的討論，本次新版的ASPICE終於把硬體工程流程整併進來了！

本次加入的硬體工程流程共計有四個，硬體工程流程將延續過去軟體工程流程的做法，從系統需求及系統架構往下展開硬體需求分析，並進一步進行硬體設計，與之相應的驗證流程，分別針對硬體設計及硬體需求進行驗證。

過去曾有純軟體開發之專案，同樣的狀況也將適用於硬體開發流程。未來，如果有純硬體開發專案，亦適用於ASPICE標準範圍。

ASPICE V-model將最終將由系統、硬體、軟體共同組成，請參考下圖。

機器學習工程(MLE)與之資料管理(SUP.11)流程概述

各種車用系統 (如: 先進駕駛輔助系統ADAS)，均開始加入以人工智慧為基礎的功能。而人工智慧領域中，深度類神經網路(DNN)常被用來實現駕駛環境中的各種感知、預測及規劃等任務。

為此，新版的標準加入了5個與機器學習相關的流程，分別是機器學習工程流程(5個)，及機器學習之資料管理流程(1個)。

值得一提的是，機器學習模型的開發屬於軟體開發的一部分；因此機器學習相關的需求，將從既有的軟體工程延展而出，機器學習需求將從軟體需求及軟體架構展出，並再更進一步區分成模型需求與資料需求，分別再展開成機器學習架構及其資料管理。

AI相關法規

歐洲議會(EU )在2023年6月14日，通過了人工智慧法案（Artificial Intelligence Act，AI Act）的草案。該法案目的是確保在歐洲開發及使用的AI可完全符合歐盟的權利與價值觀，包括人類監督、安全、隱私、透明化、非歧視，以及社會與環境福址。

有趣的是，在目前的草案中並沒有明確的點到「自動駕駛車輛」，僅若有似無的提到「道路交通」屬於「高風險（high risk）的AI系統」，這可能意味著自駕車將被歸類為高風險。

相關原文如下：
(34) As regards the management and operation of critical infrastructure, it is appropriate to classify as high-risk the AI systems intended to be used as safety components in the management and operation of road traffic and the supply of water, gas, heating and electricity, since their failure or malfunctioning may put at risk the life and health of persons at large scale and lead to appreciable disruptions in the ordinary conduct of social and economic activities.

與法規之相對應標準，可以參考：
* ISO/IEC 42001 : 一份簡單好讀的AI的管理系統
* ISO 8800：一份邏輯清楚的Safety與AI的標準

請參考筆者關於ISO/IEC 42001的介紹


關於EU AI ACT草案之內容
請參考筆者的《另一篇文章中的EU AI ACT 介紹》

ASPICE 標準解讀