| 编辑推荐: |
本文主要来跟大家聊聊ASPICE v3.1 与 ASPICE v4.0新版与旧版之间的主要差异，希望对您的学习有所帮助。
本文来自于微信公众号 电力电子系统应用智库，由火龙果软件Alice编辑、推荐。 |
|
目录
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 草稿版。
本文章，笔者就以目前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个流程）
关于 支持流程 的变更，总计增加了一个流程：
- 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. 针对未满足的承诺应定义事态升级机制 |
中 |
| 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个）。
值得一提的是，机器学习模型的开发属于软件开发的一部分; 因此机器学习相关的需求，将从既有的软件工程延展而出，机器学习需求将从软件需求及软件架构展出，并再更进一步区分成模型需求与数据需求，分别再展开成机器学习架构及其数据管理。
 | 
