汽车软件开发流程里的 ASPICE 是什么

做汽车软件项目时，尤其是给主机厂做量产项目，经常会听到 ASPICE。比如做域控、座舱、智驾、底盘、车身控制器相关软件时，客户很可能会问一句：你们 ASPICE 做到几级？听起来像在问资质，实际问的是过程能力：需求怎么管，设计怎么管，代码怎么管，测试怎么证明，问题怎么闭环，版本怎么追溯。

ASPICE，不能当它是一套文档模板，或者几张流程图，ASPICE 项目确实会留下很多文档、记录、矩阵和报告，但这些只是证据，它真正的目标是，一个汽车软件团队能不能稳定地把复杂项目做对。

1. ASPICE 是什么

ASPICE，全称一般写作 Automotive SPICE。SPICE 来自 Software Process Improvement and Capability dEtermination，中文可以理解为软件过程改进和能力判定。当然放到汽车行业里，ASPICE 就是面向汽车软件和系统开发的过程能力评估模型。

它不关心某个 ECU 功能具体怎么实现，它关心的是开发过程是否可靠。比如一个软件需求从客户那里进来以后，项目团队有没有分析？有没有分解成系统需求、软件需求？有没有评审？有没有设计支撑？有没有测试用例验证？测试失败后有没有问题单？问题修复后有没有回归？需求变化后，相关设计、代码、测试有没有同步更新？ASPICE 就是在检查这些事情。

从官方 PAM 4.0 的结构看，ASPICE 评估有两个维度：

• 一个是 过程维度：评估哪些过程，比如 SYS.2、SWE.1、SWE.6、SUP.8。
• 一个是 能力维度：这些过程做到什么能力等级，比如 CL1、CL2、CL3。

ASPICE 除了看过程目标有没有达成，还要看证据是否完整、过程是否被管理起来。其中能力等级一般从 CL0 到 CL5：

等级	含义
CL0	过程不完整，目标没有稳定达成
CL1	过程被执行了，能产出该有的结果
CL2	过程被项目管理起来，有计划、监控、资源和工作产品控制
CL3	组织级标准过程已经建立，项目能按标准过程裁剪执行
CL4	过程表现可以被量化管理
CL5	基于量化结果持续改进

现实项目里，主机厂对供应商常见要求是 CL2 或 CL3。CL2 更偏项目级执行和管理，CL3 更强调组织层面的标准过程。

其中需要注意的是，ASPICE 评估的是某些过程在某个评估范围内的能力。比如 SWE.1 可以是一个等级，SWE.6 可以是另一个等级，SUP.8 配置管理也可以单独评。日常说“我们公司 ASPICE 三级”，通常是简化说法，严格看还要看评估范围、过程集合和评估结论。

2. ASPICE 的作用是什么，为什么汽车厂都在用

汽车厂之所以关心 ASPICE，是因为汽车软件项目的协作链条太长，返工成本太高。一个座舱、智驾、车身、底盘项目，往往涉及主机厂、Tier 1、芯片厂、算法供应商、基础软件供应商、测试团队、标定团队等。需求从整车功能一路分解到控制器、软件模块、接口信号、测试用例等，中间任何一个环节有问题，后面都会变成集成问题。

汽车软件一旦进入量产阶段，问题成本会被放大：台架回归、实车验证、供应商协调、释放审批、售后风险、OTA 风险，甚至召回风险。所以主机厂除了关心供应商交付的软件包，还关心这个软件包是经过怎样的过程做出来的。ASPICE 在项目里的作用主要有几类。

降低供应商协作风险。 主机厂不可能完全进入供应商内部管理每一行代码，但可以通过 ASPICE 评估供应商的软件过程是否可靠。需求有没有受控，架构有没有评审，测试有没有覆盖等，都能反映供应商项目管理能力。

保证需求到测试的追溯。 一个客户需求应该能追到系统需求、软件需求、架构设计、详细设计、代码实现、测试用例、测试结果。

让问题处理有闭环。 汽车软件项目里，bug 不能只写“已修复”。规范的问题单，通常要有现象描述、触发条件、影响范围、根因分析、修改方案、验证结果、关闭记录。ASPICE 评估会看这些记录是否真实存在，是否和代码变更、测试结果、版本释放对得上。

让版本和配置可复现。 一次软件释放，应该能包含以下内容：这版软件基于哪些需求？包含哪些代码提交？用了哪些配置和标定？对应哪些测试报告？还有哪些遗留问题？如果三个月后客户反馈现场问题，团队能不能重新拉起当时的版本环境？

给功能安全、网络安全提供工程底座。 ISO 26262 关注功能安全，ISO/SAE 21434 关注道路车辆网络安全，ASPICE 关注过程能力。安全需求、安全分析、安全测试、漏洞处理等，也要依靠需求管理、变更管理、配置管理和验证管理支撑。

3. ASPICE 的整体流程是什么

VDA QMC 的 Automotive SPICE PAM 4.0 把过程分成几大组。下面这张是官方过程参考模型总览图。

图里可以看到，ASPICE 4.0 覆盖系统工程、硬件工程、机器学习工程、供应、采购、确认、支持、管理、过程改进和复用。但如果从汽车软件开发项目角度看，常用的主线大概是下面这样，很像 V 模型。左边是需求和设计逐层展开，右边是验证和确认逐层收回来：

客户/利益相关方需求
  ↓
系统需求 SYS.2
  ↓
系统架构 SYS.3
  ↓
软件需求 SWE.1
  ↓
软件架构 SWE.2
  ↓
详细设计和单元实现 SWE.3
  ↓
单元验证 SWE.4
  ↓
软件组件验证和集成验证 SWE.5
  ↓
软件验证 SWE.6
  ↓
系统集成验证 SYS.4
  ↓
系统验证 SYS.5
  ↓
面向真实使用场景的确认 VAL.1

系统工程：先把整车/系统问题说清楚

SYS.1 Requirements Elicitation 讲需求获取，关注 stakeholder 的期望和请求怎么被收集、分析、跟踪，并形成 agreed requirements。这里的 stakeholder 可能是主机厂、法规、终端用户、系统集成方等。

SYS.2 System Requirements Analysis 把 stakeholder requirements 转成系统需求。重点是结构化、优先级、正确性、技术可行性、运行环境影响，以及和 stakeholder requirements 的双向追溯。

SYS.3 System Architectural Design 建立系统架构，定义系统元素、行为、接口、关系和交互。车载项目里，很多软件问题其实来自系统层接口没说清楚，比如信号定义、状态机边界、诊断交互、网络管理、上下电时序。

SYS.4 / SYS.5 分别对应系统集成验证和系统验证。前者看系统元素集成后是否符合系统架构，后者看完整系统是否满足系统需求。

软件工程：把系统需求落到软件，再验证回来

SWE 是多数软件团队最关心的一组过程。

过程	主要内容
SWE.1 软件需求分析	从系统需求和系统架构得到软件需求
SWE.2 软件架构设计	定义软件模块、接口、静态结构和动态行为
SWE.3 软件详细设计和单元构建	细化软件单元设计并实现代码
SWE.4 软件单元验证	验证软件单元是否符合详细设计
SWE.5 软件组件验证和集成验证	验证组件行为、接口和软件集成结果
SWE.6 软件验证	验证集成后的软件是否满足软件需求

这里 SWE.1 和 SWE.2 容易被忽视，很多团队把精力放在编码和测试，但软件需求和软件架构如果没分析清楚，后面测试阶段会不断补洞。比如一个车载语音功能，系统需求可能只写“倒车时降低媒体音量并优先播放提示音”。到了 SWE.1，软件需求就要拆到信号输入、状态判断、音频仲裁策略、音量衰减曲线、异常输入处理、恢复策略等层面。到了 SWE.2，还要说明这些逻辑落在哪些模块，接口怎么传，状态怎么同步。

SWE.4、SWE.5、SWE.6 则把验证分层。单元测试、组件集成测试、完整软件验证都要分别进行，并且每一层验证对象、验证措施、结果记录和追溯关系都要清楚。

支持过程：横跨整个项目

SUP.1 Quality Assurance 讲质量保证。QA 要独立、客观地确认工作产品和过程是否符合定义准则。不符合项要记录、跟踪、解决，必要时升级。

SUP.8 Configuration Management 讲配置管理。需求、架构、代码、测试用例、测试结果、配置文件、标定文件、发布包，都可能是配置项。没有配置管理，版本一多就说不清“这次到底交付了什么”。

SUP.9 Problem Resolution Management 讲问题解决管理。问题要唯一标识、分类、分析、处理、跟踪到关闭，并向相关方报告状态和趋势。

SUP.10 Change Request Management 讲变更管理。变更要记录、分析影响、审批、实施、确认，并和受影响工作产品建立双向追溯。

管理过程：项目不是只靠工程师往前推

MAN 过程组关注项目管理、风险管理和度量。

MAN.3 Project Management 要求定义项目范围，评估可行性，估算活动和资源，识别项目接口，制定并维护计划，跟踪进展和偏差。

MAN.5 Risk Management 要求定期识别风险来源，分析风险优先级，定义处理措施，并持续跟踪风险状态。

MAN.6 Measurement 讲度量。它的目标不是做漂亮报表，重点在于收集和分析与开发结果、过程执行有关的数据，支撑管理决策。

这些内容看起来像项目管理常识，但 ASPICE 评估会追问证据：计划在哪里，偏差怎么处理，风险怎么关闭，度量数据有没有被用来做决策。

机器学习、硬件和复用：ASPICE 4.0 的扩展视角

Automotive SPICE 4.0 里新增或强化了机器学习相关过程。MLE.1 到 MLE.4 覆盖 ML 需求、ML 架构、训练、模型测试。因为智能驾驶、座舱感知、语音、视觉、预测类功能越来越多，传统软件流程管不住数据集、训练过程、模型版本、部署模型测试这些问题。

HWE 过程组覆盖硬件需求、硬件设计、基于硬件设计的验证、基于硬件需求的验证。对只做应用软件的团队，HWE 未必进入评估范围；但对 ECU、域控、传感器和控制器项目，硬件和软件往往一起影响系统行为。

REU.2 讲复用产品管理。平台软件、基础软件、公共组件、模型库、配置模板都可能复用。ASPICE 关心的是复用对象有没有经过选择、分析、验证和批准，限制条件有没有说明清楚。

官方附录里的 plug-in concept 很适合理解 ASPICE 4.0 的层次结构：系统工程在 system level，软件、硬件、机器学习作为 domain level 插进去，管理和支持过程横跨不同层级。

4. ASPICE 具体怎么进行流程管理

ASPICE 落地到项目里，通常有一条工具链：ALM 平台做主干，需求、架构、代码、测试、缺陷、CI、发布工具围绕它协同。

需求链路

客户需求进入需求管理工具，经过分析后形成系统需求，再分解成软件需求。每条需求要有编号、状态、版本、责任人、评审记录和变更历史，并且需求都能够被追溯。常见工具包括 IBM DOORS / DOORS Next、Siemens Polarion、PTC Codebeamer、Jama Connect。主机厂和供应商之间还经常通过 ReqIF 交换需求。

设计链路

系统架构、软件架构、详细设计要能覆盖需求。软件架构要说明模块职责、接口关系、数据流、时序、资源约束、错误处理策略。常见工具包括 Enterprise Architect、Cameo Systems Modeler、Rhapsody、Simulink、System Composer、SystemDesk。以前我以为Visio 是不是也可以，但它更适合作为设计附件，不适合承担追溯、评审、版本和变更管理。

实现链路

代码要进入配置管理系统。分支、提交、评审、标签、发布版本要可查。代码提交最好能关联需求、缺陷或变更请求。常见工具包括 GitLab、GitHub Enterprise、Bitbucket、Azure Repos、Perforce、SVN。代码评审常用 GitLab MR、GitHub PR、Gerrit 等机制。

验证链路

测试不能等到末期再补报告。需求分析阶段就应该考虑验证方式：哪些需求用单元验证，哪些用软件集成验证，哪些用系统验证，哪些需要实车或 HIL 环境确认。单元测试常见工具有 VectorCAST、Tessy、Cantata、GoogleTest、CppUTest、Simulink Test。集成和系统测试常见工具有 Vector CANoe、vTESTstudio、dSPACE AutomationDesk、NI TestStand、pytest。测试管理可以用 Polarion QA、Codebeamer Test Management、Jama、dSPACE SYNECT、TestRail。

问题、变更和发布链路

问题单要有现象、影响范围、根因、修复方案、验证结果和关闭记录。变更请求要有影响分析、审批、实施和确认。发布包要从受控配置项组装出来，有发布说明、测试状态、遗留问题和批准记录。常见工具包括 Jira、Polarion、Codebeamer、Azure DevOps、GitLab Issues、GitLab Release、Artifactory、Nexus、Teamcenter、Windchill。

举个例子，如果用一条简化证据链表示，ASPICE 大概包括以下内容：

客户需求 CR-001
  -> 系统需求 SYSREQ-023
  -> 软件需求 SWREQ-105
  -> 软件架构 SWARCH-018
  -> 代码提交 commit abc123
  -> 单元测试 UT-087
  -> 集成测试 IT-044
  -> 软件验证 SV-032
  -> 缺陷 BUG-219
  -> 变更 CRQ-056
  -> Release 1.2.0

官方附录里的追溯关系图也说明，需求、设计、验证、问题、变更之间要连起来，追溯矩阵只是表现形式，真正重要的是工程事实可检查。

5. 小结

做 ASPICE 过程管理有时候有几个误区，比如：项目快审核了，大家开始补需求、补评审、补测试报告、补追溯矩阵，短期可能能应付一部分检查，但团队并没有真的变得更可控；流程和工程脱节，流程文件写得很完整，项目实际还是靠口头沟通；只盯等级，CL2、CL3 当然重要，但等级只是评估结果，对项目真正有帮助的是过程管理：需求说清楚，接口管住，测试覆盖能查，问题闭环，版本能复现。

比较健康有效的 ASPICE 落地方式，是从真实痛点出发。比如需求变更经常漏改测试，那就先把需求-测试追溯和变更影响分析做好；集成阶段问题多，那就把接口定义、集成策略、集成验证往前拉；版本经常说不清，那就先把配置项、基线和释放记录管住。工具不追求越多越好，关键是要：需求能追到测试，问题能闭环到版本，发布包能回溯到配置基线。

资料来源

1. VDA QMC: Automotive SPICE Guidelines. Process assessment using the Automotive SPICE PAM 4.0, 2nd revised edition, November 2023
   https://webshop.vda.de/QMC/de/publikationen?pagenumber=4&pagesize=3

2. VDA QMC: Automotive SPICE Process Assessment / Reference Model, Version 4.0, 2023-11-29
   https://vda-qmc.de/wp-content/uploads/2023/12/Automotive-SPICE-PAM-v40.pdf

3. IBM Engineering Requirements Management DOORS
   https://www.ibm.com/products/requirements-management

4. Siemens Polarion ALM
   https://www.sw.siemens.com/en-US/technology/application-lifecycle-management-alm/

5. PTC Codebeamer
   https://www.ptc.com/en/products/codebeamer

6. MathWorks Automotive SPICE
   https://www.mathworks.com/discovery/automotive-spice.html

7. dSPACE SYNECT
   https://www.dspace.com/en/ltd/home/products/sw/datenmanagement/synect.cfm