Automotive SPICE（ASPICE）— 汽车软件流程评估

ASPICE = Automotive SPICE(SPICE = Software Process Improvement and Capability dEtermination),由德国汽车工业联合会 VDA QMC 的 Working Group 13 维护,是 ISO/IEC 330xx 系列(前身 ISO/IEC 15504)在汽车域的剪裁版。最新主版本 PAM 4.0 于 2023-11-29 发布(PAM 4.0 扉页);4.1 的 preview 版已于 2026-04 在 VDA QMC 官网公示,正式发布时间以 VDA QMC 为准。

它存在的因果链值得想清楚:OEM 与 Tier-1 之间存在结构性信息不对称——一个 ECU 项目几十万行代码,OEM 不可能逐行审,抽查代码也只能证伪不能证真。唯一可规模化的代理指标是"产生代码的过程是否成熟":一个需求有双向 traceability、单元测试有覆盖率准则、变更走 CCB 的组织,产出缺陷的概率显著低于作坊式开发。ASPICE 就是把这个代理指标标准化、可评分、可跨供应商比较。代价也随之而来——流程成熟是产品正确的必要非充分条件,这决定了它与 ISO 26262 的分工边界。

与隔壁框架的边界:

注意一个与 IATF 16949 的关键差别:ASPICE 没有"证书"。评估结果是一份 assessment report,只对"被评的那个项目 + 那个组织 + 那个时点"有效,不存在颁证机构,也没有法定有效期;OEM 之间互认与否、认几年,是各家采购政策(通行 2-3 年内的报告可被接受,属行业惯例而非标准条款)。把 ASPICE 当 ISO 9001 式证书去"考一次管三年",是商务谈判里最常见的误解。

ASPICE 4.0 的 PRM/PAM 共定义 32 个 Process,分布在 11 个 process group(PAM 4.0 §4 目录逐一可数;旧稿常写"8 组"是 3.1 时代口径加漏数)。工程上真正高频出场的是 SYS/SWE 两组 V 模型主干加 SUP/MAN 横切支柱,其余按项目性质选配。

一个 4.0 的更名细节要记牢,否则读 3.1 时代的材料会对不上号:右侧 V 的过程名从 "Test/Qualification Test" 全面改为 "Verification"——SYS.4 现名 System Integration and Integration Verification、SYS.5 现名 System Verification(3.1 叫 Qualification Test),SWE.5/SWE.6 同理。动机在 PAM 4.0 Annex C.7 写得很直白:系统/硬件级的验证手段不止测试(测量、计算、仿真、分析都算),原 SUP.2 Verification 因定位含混被整体删除,verification 语义下沉进各工程过程。

V 模型左右对称不是画着好看:每条左侧需求必须在右侧找到验证归宿,每个右侧测试用例必须挂回一条需求。这个双向闭环是 ASPICE 评估的最核心证据——assessor 现场抽一条需求往下追、抽一个测试用例往上追,断链直接反映到相应过程的 Consistency/Traceability BP 评分上。注意图中 SYS.1(Requirements Elicitation)虽在 PAM 之内,但不在经典 VDA Scope 16 个过程里(见 §4),多数评估不单独评它。

ASPICE 给每个 Process 单独打一个 Capability Level,而 Level 不是直接打出来的——它由 9 个 Process Attribute(PA) 的评分按固定规则推导。理解这套两层机制,才能理解为什么"一个短板拖死整个 Process"。

第一层:每个 Level 对应 1-2 个 Process Attribute(PAM 4.0 §5):

第二层:每个 PA 按 ISO/IEC 33020:2019 的 NPLF 分带评分(PAM 4.0 §3.2.2 原文转载):N = 0-15%、P = 大于 15% 至 50%、L = 大于 50% 至 85%、F = 大于 85% 至 100%;33020 还允许细分档 P-/P+(以 32.5% 分界)与 L-/L+(以 67.5% 分界),用于向被评方更精确反馈。

Level 达成规则(PAM 4.0 §3.2.4,直接决定评估策略):达成 Level N 要求本级 PA 至少 Largely,且所有更低级 PA 必须 Fully。展开说:

• Level 1 = PA 1.1 ≥ L
• Level 2 = PA 1.1 = F 且 PA 2.1/2.2 ≥ L
• Level 3 = PA 1.1/2.1/2.2 = F 且 PA 3.1/3.2 ≥ L

这就是"短板决定木桶"的精确形式:目标 CL2 的项目,PA 1.1 拿了 L(执行有实质弱点)就锁死在 CL1,哪怕管理属性全 F。也因此 mock assessment 的正确用法是找每个 Process 的最弱 Attribute 优先补,而不是平均使力。OEM 门槛方面,量产项目通行要求 VDA Scope 过程 CL2 起步,制动/转向/ADAS 等安全关键域不少 OEM 提到 CL3——这是采购条款层面的行业惯例,各 OEM 尺度不一,没有统一公开条文可引。

PAM 里 32 个过程不可能每次全评,评估范围的行业基线由 VDA《Automotive SPICE Guidelines》(蓝金书)给出,且 3.1 与 4.0 两个时代口径不同——读报告时先看它评的是哪套 scope。

3.1 时代(Guidelines 1st ed. 2017)定义的 VDA Scope 恰好 16 个过程,并明说它承接更早的 HIS scope(德国五大 OEM 的 Hersteller Initiative Software):

注意两个高频记错点:SYS.1 不在这 16 个里(需求获取被视为 SYS.2 的输入活动),MAN.5 风险管理和 MAN.6 度量也不在(它们是常见的 OEM 扩展项,不是基线)。

4.0 时代(Guidelines 2nd ed.,2023 起配套 PAM 4.0)把固定清单改成 Base + Plug-in + Flex 三层结构(Guidelines 图 1-1):

• Base(必评 5 个):MAN.3 + SUP.1/8/9/10;
• Plug-in(按开发域选配):System Engineering(SYS.2-5)加至少一个域插件——Software(SWE.1-6)/ Hardware(HWE.1-4)/ Machine Learning(MLE.1-4);
• Flex(按评估目的增补):ACQ.4、MAN.5、MAN.6、SYS.1、VAL.1、SPL.2、SUP.11、PIM.3、REU.2。

所以一个纯软件 ECU 项目的 4.0 推荐 scope = Base 5 + SYS 4 + SWE 6 = 15 个过程;外购 AUTOSAR 协议栈或转包 Tier-2 时 Flex 加 ACQ.4 回到 16 个。这套 plug-in 结构的直接工程后果:含硬件交付的项目再也没有"ASPICE 是软件团队的事"这个借口——HWE 插件入 scope 后,硬件的需求/设计/验证同样要上 traceability 工具链。

评估是人对证据的结构化抽样,不是文档考试。理解 assessor 的方法论,准备方向才不会跑偏。

谁有资格评:assessor 资质由 intacs(International Assessor Certification Scheme)体系认证,分 Provisional / Competent / Principal 三级,VDA QMC 是主要培训与考试运营方;正式的 VDA Scope 评估通常由 Competent 及以上等级担任 lead assessor。(旧稿写"IATF 认证 assessor"是错的——IATF 管 16949 审核员,与 ASPICE 无关。)

评估流程:先定 assessment scope(哪些过程、每个过程的目标 CL、process context),Guidelines 要求对 scope 选择给出书面 rationale,且 scope 内每个过程必须至少实际执行过一次才可评。现场阶段 assessor 按角色访谈(工程师本人,不是流程经理代答)+ 工作产物抽样:抽需求向下追到测试、抽变更单看 CCB 痕迹、抽计划看维护历史。典型量级(培训机构与咨询界通行口径,非标准值):VDA Scope CL2 评估 onsite 3-5 天、2 名 assessor;被评方备评投入常见 6-12 人月。

评分有成文规则约束,不全凭 assessor 手感——Guidelines 定义了大量 rating rules(RL)与 recommendations(RC),几条改变备评策略的:

• GEN.RL.1:过程 X 的 PA 1.1 评了 P/N,不得据此连带降过程 Y 的 PA 1.1——过程间唯一的"传染点"是显式跨过程的 Consistency/Traceability BP。mock audit 时别自己吓自己搞株连。
• TAC.RL.1/2:traceability 在"信息簇"级(而非原子级)建立、或用人工快照方式(而非自动化工具)维护,均不得因此降级——工具化是强烈建议,不是评分硬性要求;真正致命的是抽样追不通。
• TAC.RL.3/4:一致性证据不限于正式 review record,结对工作、修订历史、变更注释都可作证;未入 baseline 的信息间建立的一致性同样有效。
• 覆盖率指南(Guidelines §3.11):code coverage 本身不是验证目标,它是"所选测试用例是否覆盖了它该覆盖的代码"的伴随信息——与 ISO 26262-6 clause 9.4.4 的定位一致。拿"覆盖率 100%"当 SWE.4 达标证据、却拿不出测试用例与验证准则的映射,照样降。

4.0 不是修订,是结构性改版——按 PAM 4.0 Annex C.7 与正文对照,工程影响最大的六条:

其中 Work Product → Information Item 值得多说一句为什么:3.1 的 WP 清单在实践中退化成"文档对照表",供应商照清单补文档、assessor 照清单点名,背离了"评过程是否真实发生"的初衷。4.0 的 Information Item 明确是结果导向的判断辅助(PAM 4.0 §3.3.2:II 的 characteristics 不得被解读为对文档结构的要求)——证据可以活在 ALM 工具的字段、CI 流水线的日志里,不必是一份份 Word。这对用 Codebeamer/Polarion + Jenkins 这类工具链的团队是实质利好。

另外注意:网络安全不是 4.0 新增的 SUP.11(旧稿此处有误,SUP.11 是 Machine Learning Data Management)。网络安全走的是独立的 Automotive SPICE for Cybersecurity(黄皮书,1st ed. 2021、2.0 版 2024),见 §7。

四个体系不是替代关系而是并行约束——ASPICE 管流程,ISO 26262 管安全产物,ISO 21434 管网络安全产物,PPAP 管硬件量产。OEM SOR 同时把项目挂到这几条线上,SOP 签字要条条都过。工程上最大的浪费是同一份产物在各条线各做一次;正确做法是让一份 SwRS 同时满足 ASPICE SWE.1 与 ISO 26262 Part 6 的软件安全需求,字段拓展即可复用。

实务建议:项目计划同时挂 ISO 26262 与 ASPICE 的 milestone,把 26262 的 work product(如 Software Safety Requirements)直接作为 ASPICE SWE.1 的证据输入。但要意识到两者审的东西不同——ASPICE assessor 看"需求过程是否受控",safety assessor 看"这条需求对不对、confirmation 独立性够不够",一份文档过了前者不等于过了后者(边界展开见 §10.3)。

用一个具体项目把前面的机制串起来:Tier-1 为 OEM 开发 48V EPS(电动助力转向)ECU——硬件平台与本 wiki topic-voting-redundancy §8 的 1oo2D worked design 同源(TC397 lockstep 主通道 + TLE9263 SBC 监控通道,SG-01 无非预期转向力矩,ASIL D,FTTI 100 ms)。OEM sourcing 条款要求:SOP 前 6 个月完成 VDA Scope 评估,目标 CL2,按 PAM 4.0 + Guidelines 2nd ed. 执行。以下编号(SysRS-047 等)均为示例编号,数值为该类项目的典型量级。

以下七条按出现频率与代价排序,每条都能挂回前面某个机制。

• standard · standard_aspice — Automotive SPICE