Automotive SPICE（ASPICE）— 汽车软件流程评估
本质 ASPICE 解决的核心问题是 "OEM 怎么相信 Tier-1 写出来的代码能上车？"——它不审代码本身（那是 ISO 26262 的事），而是审"写代码这件事的过程是否成熟到能稳定产出靠谱代码"。具体做法是把汽车软件开发拆成 16~32 个 Process Area（流程域），按 V 模型左右对称展开（需求 ↔ 验证、架构 ↔ 集成）。每个 PA 评 Capability Level 0~5，OEM 通常要求关键 PA 至少 Level 2 (Managed Process)。ASPICE 与 PPAP 并行：硬件走 PPAP 18 要素，软件走 ASPICE 评估，两条独立通道都要过，OEM 才签 SOP。
学习目标
读完本页后，你应该能够：
- 画出 ASPICE 的 V 模型与 16 个核心 Process Area 的对应关系
- 区分 Capability Level 0~5 各自要求什么（BP / GP）
- 说出 VDA Scope 是哪一组 PA，以及为什么 OEM 几乎只审这些
- 解释 ASPICE 4.0 相比 3.1 的关键变化（HWE / MLE / SUP.11 加密）
- 区分 ASPICE 与 ISO 26262 / ISO/SAE 21434 各自的边界
- 说出 ASPICE 评估常见的 5 个翻车点
- 把 ASPICE 评级结果挂回 PPAP element 17
1. ASPICE 是什么
ASPICE = Automotive SPICE（汽车专版 SPICE，SPICE = Software Process Improvement and Capability dEtermination）。它由德国汽车工业联合会 VDA QMC 维护，本质是 ISO/IEC 33020 在汽车软件领域的剪裁版。最新主版本 4.0 于 2023 年发布。
与隔壁框架的边界：
| 框架 | 管什么 | 颗粒度 | 强制方 |
|---|---|---|---|
| ASPICE | 软件流程是否成熟 | 流程 | OEM 审 Tier-1 |
| ISO 26262 | 安全相关产品正确性 | 产品 + 流程 | 监管 + OEM |
| ISO/SAE 21434 | 网络安全正确性 | 产品 + 流程 | 监管 + OEM |
| PPAP | 硬件零件量产符合性 | 产品 | OEM |
| CMMI | 通用软件流程成熟度 | 组织级 | 自愿 / 部分军工 |
ASPICE 自身不判断代码安全或正确——它只能说"这个组织写代码的过程足够 disciplined"。OEM 之所以要 ASPICE，是因为代码审计成本不可承受，只能转去审"产线"。
2. V 模型与 Process Area 全景
ASPICE 4.0 共有 32 个 Process Area，分布在 8 个 Process Group。但绝大多数 OEM 实际审计只盯 VDA Scope 的 16 个（详见 §4）。下图按 V 模型展开 VDA Scope 的核心 PA：
| Process Group | 缩写 | 全称 | 包含 PA | 用途 |
|---|---|---|---|---|
| Acquisition | ACQ | Acquisition | ACQ.4 | 与上游/供应商接口 |
| System Engineering | SYS | System Engineering | SYS.1 ~ SYS.5 | 系统级 V 模型左右两侧 |
| Software Engineering | SWE | Software Engineering | SWE.1 ~ SWE.6 | 软件 V 模型左右两侧 |
| Hardware Engineering | HWE | Hardware Engineering（4.0 新增） | HWE.1 ~ HWE.4 | ECU 硬件流程 |
| Machine Learning | MLE | Machine Learning Engineering（4.0 新增） | MLE.1 ~ MLE.4 | AI/ADAS 模型流程 |
| Supporting | SUP | Supporting | SUP.1/8/9/10/11 | 配置/变更/QA/网络安全 |
| Management | MAN | Management | MAN.3/5/6 | 项目管理 |
| Process Improvement | PIM | Process Improvement | PIM.3 | 流程优化 |
关键判别：ACQ/SYS/SWE 是 V 模型的"主干"，SUP 和 MAN 是横切支柱。审计时主干每条都要 traceability 双向闭环——少一条就降级。
3. Capability Level 0~5
ASPICE 给每个 PA 单独打一个 Level。Level 不是"分数"而是能力台阶——每一级要求做对前面所有级 + 多做一类事。
| Level | 名称 | 关键 GP（Generic Practice） | 工程含义 |
|---|---|---|---|
| 0 | Incomplete | — | 该 PA 没做或乱做 |
| 1 | Performed | BP（Base Practice）做齐 | 该做的事都做了 |
| 2 | Managed | 计划 + 监控 + 工作产物管控 + 接口管理 | 项目管得住 |
| 3 | Established | 标准流程 + 剪裁规则 + 度量数据 | 组织级标准，不是项目临时拼 |
| 4 | Predictable | 量化目标 + 统计控制 | 用数据说话 |
| 5 | Innovating | 持续改进 + 创新 | 业界领先 |
OEM 实际门槛：
- 量产项目 VDA Scope 关键 PA → Level 2 起步
- ISO 26262 ASIL D 项目 → 部分 PA 要求 Level 3
- 中国新势力 OEM → 普遍只查 Level 2（部分头部车厂查 Level 3）
评级机制：每个 PA 拆成多个 Process Attribute (PA1.1, PA2.1, PA2.2, ...)，每个 Attribute 评 N (Not) / P (Partially) / L (Largely) / F (Fully)。整 PA 的 Level 取所有 Attribute 中的最低值——有一个掉到 P 全 PA 就降级。所以 ASPICE 是"短板决定木桶"。
4. VDA Scope — OEM 实际审什么
VDA QMC 在 2017 年发了《VDA Scope》（俗称蓝皮书 / 黄皮书），把"OEM 实际有用的 PA"圈定在一个子集，避免 Tier-1 在不重要的 PA 上耗费资源。这是 ASPICE 工程实践的真正基线。
| Process Group | VDA Scope PA | 备注 |
|---|---|---|
| ACQ | ACQ.4（供应商监控） | 仅当转包给 Tier-2 |
| SYS | SYS.1, SYS.2, SYS.3, SYS.4, SYS.5（5 个全审） | 系统级 V 模型必审 |
| SWE | SWE.1, SWE.2, SWE.3, SWE.4, SWE.5, SWE.6（6 个全审） | 软件 V 模型必审 |
| SUP | SUP.1（QA），SUP.8（CM），SUP.9（变更），SUP.10（联合评审） | 4.0 新增 SUP.11（网络安全）按需 |
| MAN | MAN.3（项目管理），MAN.5（风险），MAN.6（度量） | 项目管理三件套 |
典型 VDA Scope 审 16 个 PA（少数 OEM 增减）。审计准备的工作量约 6~12 人月，正式审计 3~5 天，由 IATF 认证的 principal assessor 主导。
5. SYS 与 SWE 详解（PE 工程师最常涉及的）
PE 工程师做硬件出身，但 PEU 项目里要协助软件团队提供 traceability 证据，所以至少要看懂 SYS 和 SWE 这 11 个 PA 在做什么。
5.1 SYS Process Area
SYS 5 个 PA 是 V 模型左右两侧的系统级骨架——左侧 SYS.1~SYS.3 把 OEM SOR 一路细化到能交给软件团队和硬件团队的输入,右侧 SYS.4/SYS.5 把交付物逐层往上集成验证回 SOR。两侧通过 traceability ID 互相绑定：每条左侧需求必须在右侧能找到一个测试用例验证它,反之每个测试用例必须挂回某条需求。
| PA | 名称 | 关键 BP | 工作产物 |
|---|---|---|---|
| SYS.1 | Requirements Elicitation | 与利益相关方一起把 SOR 拆成 stakeholder requirements | 需求清单 + 评审记录 |
| SYS.2 | System Requirements Analysis | stakeholder reqs → system reqs（量化、可测） | 系统需求规格 SyRS |
| SYS.3 | System Architectural Design | 分配到硬件 / 软件 / 机械组件 + 接口定义 | 系统架构 + HSI |
| SYS.4 | System Integration & Test | 把 HW + SW + 机械集成到 PEU 整机 + 测试 | 集成报告 + 测试覆盖 |
| SYS.5 | System Qualification Test | 用 SyRS 反向验证 PEU 整机 | 系统验证报告 |
双向 traceability：SYS.1 → SYS.2 → SYS.3 → SWE 是左侧链；右侧 SWE.6 → SYS.4 → SYS.5 是反链；每条左侧需求都要在右侧能找到验证证据，反之每条测试用例都要追到一个需求。断一根 ASPICE 立刻降级。
5.2 SWE Process Area
SWE 6 个 PA 与 SYS 5 个 PA 在结构上对称——SWE.1SWE.3 是软件 V 模型左侧需求/架构/详细设计,SWE.4SWE.6 是右侧单元/集成/验证。区别在颗粒度：SYS 看系统级输入输出,SWE 看代码级实现。SYS.3 → SWE.1 是关键交接点：系统架构把责任分配给软件后,SWE.1 把软件该做的事独立细化,这是软件团队真正的起跑线。
| PA | 名称 | 关键 BP | 工作产物 |
|---|---|---|---|
| SWE.1 | Software Requirements Analysis | 把 SYS 分配给软件的部分细化 | SwRS |
| SWE.2 | Software Architectural Design | 软件组件 + 接口（如 AUTOSAR Runnable） | SwAD |
| SWE.3 | Software Detailed Design & Construction | 模块/函数级设计 + 编码 | 详细设计 + 源代码 |
| SWE.4 | Software Unit Verification | 单元测试 + 静态分析 | 单元测试报告（覆盖率） |
| SWE.5 | Software Integration & Test | 模块集成 + 集成测试 | 集成测试报告 |
| SWE.6 | Software Qualification Test | 用 SwRS 反向验证软件 | 软件验证报告 |
SWE.4 单元测试是审计高频翻车点：覆盖率门槛因 ASIL 而异——ASIL D 通常要求 MC/DC 覆盖率 ≥ 90%（Modified Condition / Decision Coverage）。Statement / Branch coverage 不够。
6. ASPICE 4.0 vs 3.1 的关键变化
ASPICE 4.0（2023 发布）相比 3.1（2017）有三个工程上影响最大的变化：
| 维度 | 3.1 | 4.0 | 工程影响 |
|---|---|---|---|
| 硬件流程 | 单独 HWE 模块草案 | 正式 HWE.1~HWE.4 入主标准 | PEU 硬件团队也要按 ASPICE 走 |
| AI/ML | 无 | 新增 MLE.1~MLE.4 | ADAS / 智驾项目必跑 |
| 网络安全 | 无 | 新增 SUP.11 Cybersecurity Risk Management | 与 ISO 21434 + UN R155 对接 |
| 评级 | NPLF 4 档 | 同 + 给 PA1.1 更细 | 评估趋严 |
| Process Group | 7 | 8（加 PIM 和 MLE） | 范围扩大 |
关键判断：4.0 把硬件也纳入，所以 PEU 项目硬件团队不能再说 "ASPICE 是软件团队的事"。HWE 和 SYS / SWE 共用同一套 traceability 工具链。
7. 与 ISO 26262 / ISO 21434 / PPAP 整合
四个体系不是替代关系而是并行约束——ASPICE 管流程,ISO 26262 管安全产物,ISO 21434 管网络安全产物,PPAP 管硬件量产。OEM SOR 同时把项目挂到这四条线上,SOP 签字要四条都过。工程上最大的浪费是同一份产物在四条线各做一次——实际可以让一份 SwRS 同时满足 ASPICE SWE.1 和 ISO 26262 Part 6 的 SW Safety Req,需求字段拓展即可。
| 组合 | 主管 | 详细见 |
|---|---|---|
| ASPICE × ISO 26262 | ASPICE 管"流程",ISO 26262 管"安全产物" | topic-functional-safety.md |
| ASPICE × ISO 21434 | ASPICE SUP.11 与 ISO 21434 紧耦合（4.0 版） | — |
| ASPICE × PPAP | ASPICE 报告挂 PPAP element 17（客户特殊要求） | topic-ppap.md §4.2 |
| ASPICE × IATF 16949 | ASPICE 是 IATF 16949 在软件域的具体化 | topic-peu-development.md §4 |
实务建议：项目计划同时挂 ISO 26262 和 ASPICE 的 milestone。把 ISO 26262 的 work product（如 Software Safety Requirements）作为 ASPICE SWE.1 的输入证据，一份产物两条线复用——避免重复造轮子。
8. 5 个常见翻车点
ASPICE 评估失败 90% 不是技术问题而是流程理解错——下面五条是高频退回。每一条都对应到前面某条核心约束(traceability / 覆盖率门槛 / QA 独立性 / 4.0 范围 / 短板木桶)未落实。
| 翻车点 | 表现 | 根因 | 预防 |
|---|---|---|---|
| Traceability 断链 | 测试用例追不到需求或反之 | 需求改了测试没同步；用了 Excel 而非工具链 | DOORS / Polarion / Codebeamer + 强制双向 ID |
| 单元测试覆盖率不够 | SWE.4 评 P 拉低整 PA | 只跑 statement coverage，没做 MC/DC | 工具链（VectorCAST / Tessy）+ ASIL 对应阈值 |
| QA 与项目混 | SUP.1 评 N | 项目经理兼 QA，独立性不足 | 独立 QA team / 至少不在同一 chain of command |
| 4.0 HWE 没落地 | HW 团队照旧 V 模型而无文档 | 硬件团队还认为 ASPICE = 软件 | 4.0 升级时硬件 leader 同步进 ASPICE 培训 |
| Level 评估单 PA 短板 | 整体 Level 1 但目标是 2 | 一个 Attribute 掉 P 全 PA 降级 | 评估前 mock audit 找短板优先补 |
核心要点
- ASPICE 审流程不审代码——它是 OEM 用来代理判断"代码靠谱度"的工具，与 PPAP（硬件）平行。
- VDA Scope 16 个 PA 是工程基线，量产项目 OEM 通常要求关键 PA Level 2 起；ISO 26262 ASIL D 部分 PA 要 Level 3。
- V 模型双向 traceability 是 ASPICE 评估的最核心证据——任何一条断链立刻降级。
- PA Level = 所有 Attribute 最低值——短板决定木桶，评估前必须 mock audit 找最弱 Attribute 补上。
- ASPICE 4.0 三大新增：HWE 硬件流程入主标准 + MLE 机器学习 + SUP.11 网络安全；硬件团队不能再袖手旁观。
- ASPICE × ISO 26262 复用一份产物——同一个 SwRS 文档既满足 SWE.1 也满足 ISO 26262 Part 6，项目计划要把两者 milestone 对齐。
- ASPICE 报告挂 PPAP element 17（客户特殊要求），但两条通道独立通过，OEM 才签 SOP。
Cross-references
- ← 索引
- PEU 开发流程与测试矩阵 — §6 ASPICE 概述、与 PPAP 并行关系、术语速查
- PPAP 与汽车零部件开发阶段 — element 17 客户特殊要求挂 ASPICE 报告
- DV 与 PV 详解 — V 模型右侧验证、Cpk 门槛
- 功能安全（ISO 26262） — Part 6 软件 V 模型，与 ASPICE 复用
- 汽车 MCU — AUTOSAR、AURIX、单元测试工具链
- 整车 E/E 架构 — AUTOSAR Classic / Adaptive，ASPICE SWE.2 输入
- 失效模式速查 — 软件失效与安全机制对应