ASPICE Capability Level 评分实操
本质与导读
本质 ASPICE 评估不给"通过/不通过",而是给每个 Process Area 打 0-5 级 Capability Level——衡量的是过程成熟度,不是产品质量(Level 3 ≠ 代码更好,而是过程更稳)。多数 OEM 要 VDA Scope PA 至少 Level 2、制动/转向/ADAS 要 Level 3;而 Level 2 的硬门槛是 PA1(PA1.1)达 F(≥85%)、PA2(PA2.1/PA2.2)达 ≥ L(≥50%)。
主线坐标:方法 / 标准层(跨站支撑) · ↑ 全景主线
1. Level 0-5 阶梯
ASPICE Capability Level 由 ISO/IEC 33020 定义,共 6 级:
| Level | 名称 | 要求 | 评分 |
|---|---|---|---|
| Level 0 | Incomplete | 没跑或随便跑 | PA1 = N |
| Level 1 | Performed | BP 已实施,产生预期输出 | PA1 = L/F |
| Level 2 | Managed | + 计划 + 工件管控 + review | PA1 = F and PA2 = L/F |
| Level 3 | Established | + 标准化流程 + 部署到组织 | + PA3 = L/F |
| Level 4 | Predictable | + 量化度量 | + PA4 = L/F |
| Level 5 | Innovating | + 持续优化 + 创新 | + PA5 = L/F |
关键认知:
- Level 1 = "做过" (基本能跑)
- Level 2 = "管住" (有计划 + 资源 + 工件 + review)
- Level 3 = "组织标准" (流程文档化 + 全公司同一套)
- Level 4 = "数据驱动" (能量化预测)
- Level 5 = "持续改进" (主动找瓶颈优化)
实际工业界:Level 4-5 几乎不要求,因为成本太高。
2. Process Attribute (PA1-PA5)
每个 Level 由一个或多个 PA 组成——审计员评估的最小单位:
| PA | 名称 | 评估对象 |
|---|---|---|
| PA1.1 | Process Performance | BP 是否都跑了 + 是否产生预期 work product |
| PA2.1 | Performance Management | 流程是否有计划/资源/职责 |
| PA2.2 | Work Product Management | work product 是否管控 (版本/review/变更) |
| PA3.1 | Process Definition | 流程是否在组织级别定义 |
| PA3.2 | Process Deployment | 流程是否在项目中实际部署 |
| PA4.1 | Quantitative Analysis | 流程是否有量化目标 + 度量 |
| PA4.2 | Quantitative Control | 是否能用度量数据预测 |
| PA5.1 | Process Innovation | 是否识别并实施改进 |
| PA5.2 | Process Optimization | 改进是否带来量化效益 |
PA1 vs PA2 关键区别:
- PA1.1 检查 BP (Base Practice) 是否做了——产品/输出层面
- PA2.1/2.2 检查流程是否管理——计划/资源/工件层面
举例:SWE.4 单元测试——
- PA1.1: "测试是否跑了,覆盖率报告是否产出" → BP 输出
- PA2.1: "测试计划是否有,资源是否分配" → 流程管理
- PA2.2: "测试报告是否有版本号,review 是否签字" → 工件管控
3. N/P/L/F 四档评分
每个 PA (实际是 PA 下的 GP - Generic Practice) 都按 N/P/L/F 四档评分:
| 评分 | 全称 | 达成率 | 含义 |
|---|---|---|---|
| N | Not Achieved | < 15% | 几乎没做 |
| P | Partially Achieved | 15-50% | 部分做,有明显缺口 |
| L | Largely Achieved | 50-85% | 大部分做,小问题 |
| F | Fully Achieved | > 85% | 全部做,无明显缺口 |
判定方法:审计员根据证据数量 + 质量给分,不是"项目数 / 总数"机械计算。
4. Level 通过条件
一个 PA 要达到 Level N,必须前面所有 Level 都 F + 当前 Level PA ≥ L:
| 要达成 Level | 要求 |
|---|---|
| Level 1 | PA1.1 ≥ L (或 F) |
| Level 2 | PA1.1 = F + PA2.1 ≥ L + PA2.2 ≥ L |
| Level 3 | Level 2 全 F + PA3.1 ≥ L + PA3.2 ≥ L |
| Level 4 | Level 3 全 F + PA4.1 ≥ L + PA4.2 ≥ L |
| Level 5 | Level 4 全 F + PA5.1 ≥ L + PA5.2 ≥ L |
关键认知:Level 是"瓶颈级别"——任一 PA 没达到 → 整个 Level 不通过。
- PA1 = F,PA2 = P → Level 1 (不是 Level 2)
- PA1 = F,PA2.1 = F,PA2.2 = L → Level 2
5. 实际 OEM 评分案例
案例:某 Tier-1 PEU 项目,VDA Scope 16 PA 评分:
| PA | PA1.1 | PA2.1 | PA2.2 | PA3.1 | PA3.2 | 最终 Level |
|---|---|---|---|---|---|---|
| SYS.2 | F | F | L | P | N | Level 2 |
| SYS.3 | F | F | F | L | P | Level 2 (PA3.2 P,卡 Level 3) |
| SYS.5 | F | L | L | N | N | Level 2 |
| SWE.1 | F | F | F | L | L | Level 3 ✓ |
| SWE.4 | L | P | N | N | N | Level 1 (PA2 N → 卡 Level 2) |
| SWE.6 | F | F | L | N | N | Level 2 |
| MAN.3 | F | F | F | L | L | Level 3 ✓ |
| SUP.8 | F | F | F | F | L | Level 3 ✓ |
整体评价:平均 ~Level 2,SWE.4 短板拖累 → 需要整改后才能达成 OEM "Level 2 全 PA" 门槛。
6. OEM 评估流程
ASPICE Assessment 典型 3-6 月周期:
关键认知:Assessor 不是 audit 一两天就出报告——典型现场 5-10 天,深入查工件。自评不严 + 现场 finding 数 < 20 通常意味"流于形式"。
7. Assessor 资质
OEM 通常要求 Assessor 有第三方资质:
| 资质 | 颁发机构 | 含义 |
|---|---|---|
| iNTACS Certified Assessor | iNTACS (国际) | 国际通用,主流 OEM 都认 |
| VDA Certified Assessor | VDA QMC (德国) | 德系 OEM 优先 |
| iNTACS Provisional Assessor | iNTACS | 入门级,需要 Lead Assessor 在场 |
| Principal Assessor | iNTACS | 最高级,可独立做 Level 4/5 评估 |
典型 Assessor 公司:
- Kugler Maag CIE (德国,ASPICE 起家)
- SGS-TÜV Saar (国际)
- TÜV SÜD / TÜV Rheinland
- Method Park / UL (北美)
- 国内:中汽研 / 北汽 / Intertek
成本:典型一次完整 ASPICE Assessment ¥40-100 万,周期 3 月。
8. ASPICE Level 与 ASIL 的对应
OEM 实操中,ASIL 与 ASPICE Level 有事实上的对应:
| ASIL | ASPICE 推荐 |
|---|---|
| QM | Level 1 即可 |
| ASIL A | Level 2 |
| ASIL B | Level 2 |
| ASIL C | Level 2,大众 Audi 要 Level 3 |
| ASIL D | Level 3 强制 (主驱/制动/转向/ADAS) |
关键认知:ASPICE 不是 ISO 26262 的子集,但 ASIL D 项目 + ASPICE Level 3 是"双保险"——Safety Case 引用 ASPICE 报告作为"流程证据"。
9. 设计陷阱 Gotcha
ASPICE 评估失败的根因集中在流程成熟度认知偏差与工件管控疏漏,以下七条来自真实项目复盘。
G1 自评太松——现场大幅降级。项目自评 Level 23,iNTACS assessor 现场 3 天后给出 Level 01。根因:自评员既是"考生"也是"阅卷人",激励偏差不可避免。防范:正式 assessment 前 6 周委托具有 iNTACS Provisional Assessor 资质的第三方做 pre-assessment,认清真实 baseline。
G2 Traceability 双向断链——PA1.1 直接 P。SYS.2 用 DOORS 维护需求向下可追溯(SYS.2→SWE.1 forward trace 有),但 SWE.1 软件需求工件没有反向 link 指向 SYS.2(SWE.1→SYS.2 反向 0 覆盖),SWE.1 PA1.1 BP9 双向可追溯性 0 证据 → P。BP = Base Practice,一个 BP 缺失会将整个 PA1.1 从 F 拉至 P → Level 直降一档。预防:Polarion/DOORS 强制双向 link,并把"反向 trace 完整性"加入 Review Checklist。
G3 PA2.2 工件版本跳号——finding 直接 P。work product 版本号存在 v0.5→v0.9→v1.0 跳号,变更记录断档;assessor 问"v0.6~v0.8 的更新内容是什么"无法回答 → PA2.2 给 P 而非 L。根因:团队把 PA2.2 理解为"文件有版本号"而非"版本号变更有记录+review 签字"。
G4 Finding 关闭走形式——re-assessment 仍降级。一期 assessment finding 关闭记录格式为"已完成整改——×月×日",无工件截图、无 review 签字记录。6 个月后 re-assessment,assessor 要求现场调取对应工件:打不开版本历史 → re-assessment 结果与第一次相同。正确关闭:evidence = 工件路径 + 版本号 + review 会议纪要签字页截图,三项缺一不可。
G5 Assessor 无 iNTACS 资质——OEM 拒绝报告。供应商花 ¥20 万请了"ASPICE 咨询顾问"做评估,报告格式规范,但该顾问无 iNTACS Certified/Provisional Assessor 证书。OEM(保时捷、宝马)在供应商开发协议(DIA)中明确要求 Assessor 持有有效 iNTACS 证书,报告被整体拒绝,需重做。成本翻倍。
G6 PA3.1 有流程文档但 PA3.2 未实际部署——Level 3 卡死。组织级 SWE.1 分析流程模板已发布(PA3.1=L),但项目实际使用的是 2 年前的旧版本,新模板从未在项目中执行(PA3.2=P)。Level 3 要求 PA3.1 ≥ L 且 PA3.2 ≥ L,PA3.2=P → Level 3 不通过,只有 Level 2。根因:"发布"流程文档 ≠ "部署"到项目——项目启动 Kick-off 必须引用最新版本流程模板并留记录。
G7 SEooC 供应商 ASPICE scope 与 ASIL D Safety Case 范围不匹配。SEooC 驱动 IC 供应商仅被要求评估 SWE.16/SUP.1/8/10/MAN.3,SYS.25 排除在 scope 外(省钱)。ASIL D Safety Case 审计时,I3 独立安全评估要求验证 SYS.2 需求管理 Level 2,而该 PA 从未被评估 → Safety Case 缺口,需补充 SYS.2~5 范围的专项评估或 AoU 协议明确边界。提前在 DIA 中约定 ASPICE scope 覆盖 SYS.* PA。
10. 端到端 Worked Design — 某 Tier-1 EPS ECU Level 2 升 Level 3 整改
项目背景:某 Tier-1 ASIL D EPS ECU(TC397 主控,400V/100kW)在 OEM(国内合资)供应商开发协议中要求:VDA Scope 16 PA 全部达到 Level 2,SWE.1/SWE.3/MAN.3 需达到 Level 3。评估周期 6 个月,共两轮(初评 + 整改后 re-assessment)。
Step 1 基线评估(第 1-4 周,iNTACS Lead Assessor 现场 5 天)
VDA Scope 16 PA 初始 NPLF 评分(只列关键 PA),Part A — PA 属性评分:
| PA | PA1.1 | PA2.1 | PA2.2 | PA3.1 | PA3.2 |
|---|---|---|---|---|---|
| SYS.2 系统需求 | F | F | P | N | N |
| SYS.5 集成验证 | F | L | P | N | N |
| SWE.1 软件需求 | F | F | F | L | P |
| SWE.4 单元测试 | F | P | N | N | N |
| SWE.6 软件集成 | F | F | L | N | N |
| SUP.8 配置管理 | F | F | F | L | L |
| MAN.3 项目管理 | F | F | F | L | P |
Part B — 初始结论与 OEM 目标:
| PA | 初始 Level | OEM 要求 |
|---|---|---|
| SYS.2 系统需求 | Level 1 | Level 2 |
| SYS.5 集成验证 | Level 1 | Level 2 |
| SWE.1 软件需求 | Level 2 | Level 3 |
| SWE.4 单元测试 | Level 1 | Level 2 |
| SWE.6 软件集成 | Level 2 | Level 2 ✓ |
| SUP.8 配置管理 | Level 3 ✓ | Level 2 |
| MAN.3 项目管理 | Level 2 | Level 3 |
初始结果:16 PA 中 4 个 Level 1(未达 Level 2),2 个 Level 2(未达 Level 3 要求),造成6 个 Finding。
Step 2 Gap 分析(第 5-6 周)
3 个 Critical Finding(影响整体 verdict):
- CF-01:SYS.2 PA2.2 P → work product 版本跳号(上节 G3 根因),需补全 change log。
- CF-02:SWE.4 PA2.1 P → 单元测试计划未分配资源/时间表,测试工程师名单缺失。
- CF-03:SWE.1 PA3.2 P → 软件需求分析流程模板发布(PA3.1 L)但项目使用旧版本 SWE.1_template_v1.2,最新 v2.0 未部署。
3 个 Major Finding:PA1.1 Traceability / SWE.6 PA2.2 / MAN.3 PA3.2 同类问题,优先级次于 Critical。
Step 3 整改实施(第 7-18 周)
| 任务 | 负责人 | 工时 | 交付物 |
|---|---|---|---|
| SYS.2 change log 补全(v0.1→v1.3 所有版本) | 系统工程师 | 3 人周 | SYS.2-Requirements-v1.3 完整变更记录 |
| SWE.4 测试计划补写(含资源/时间/覆盖率目标) | 测试工程师 | 2 人周 | UT-Plan-v1.0,review 签字 |
| SWE.1 v2.0 模板部署到项目 + 历史工件归入 | 过程工程师 | 4 人周 | SWE.1-Tailoring-Record + 项目适裁文件 |
| MAN.3 PA3.2 部署证据(会议纪要 + 引用记录) | 项目经理 | 2 人周 | PM-Process-Deployment-Evidence |
总整改工时:11 人周 ≈ 3 个工程师 × 4 周。
Step 4 Pre-assessment 自查(第 19-20 周)
过程工程师逐条检查 6 个 Finding 的 evidence:CF-01/CF-02/CF-03 全部关闭,evidence 完整;Major Finding 4/3 关闭,1 个留作 Observation。
Step 5 Re-assessment(第 21-24 周,同一 Lead Assessor)
| PA | Re-assessment Level | 变化 |
|---|---|---|
| SYS.2 | Level 2 ✓ | ↑ from Level 1 |
| SYS.5 | Level 2 ✓ | ↑ from Level 1 |
| SWE.1 | Level 3 ✓ | PA3.2 F |
| SWE.4 | Level 2 ✓ | ↑ from Level 1 |
| MAN.3 | Level 3 ✓ | PA3.2 L→F |
最终:16 PA 全达 Level 2;SWE.1/SWE.3/MAN.3 达 Level 3——OEM 要求全满足。
总成本:Assessor 费用(初评 + re-assessment)¥32 万 + 整改工时 11 人周 × ¥3 万/人周 = ¥33 万 = 总计约 ¥65 万,周期 6 个月。
11. 工作极限 Corner
ASPICE 评估存在三个结构性高压角,通用评估经验不能直接套用。
C1 SEooC 组件供应商 scope 收窄角。SEooC 驱动 IC/SBC 供应商仅评估 SWE.1~6 + SUP.1/8/10 共 9 PA,SYS./MAN. 排除在外。当下游系统集成商(Tier-1)要求在 Safety Case 中引用供应商 ASPICE Level 3 证明时,OEM I3 发现 SYS.2(系统需求管理)、SYS.5(集成验证)从未被评估——Safety Case 中供应商 AoU 未涵盖系统层面流程成熟度。处置:在 SoD(Scope of Delivery)合同中明确 ASPICE scope 包含或排除的 PA 列表,并在 Safety Case 中说明 SYS.* PA 由 Tier-1 自担。
C2 多项目共用平台件 PA3 虚高角。某 Tier-1 产品线有组织级 SWE.1~6 流程手册(PA3.1=F for all PAs),但 EPS 项目实际裁剪文件显示对 SWE.3 架构过程的 13 个 Base Practice 中有 6 个被标记为"Not Applicable"——裁剪比例 46%,远超 Tailoring Guideline 允许的 20%。PA3.2"流程在项目中实际部署"中 SWE.3 = P,Level 3 不通过,只到 Level 2。教训:PA3.1(组织级标准存在)≠ PA3.2(项目实际按标准跑)——大范围裁剪就是 PA3.2 降级的直接证据。
C3 OEM 换代时 ASPICE scope 重扩展角。某 OEM 原要求 16 PA(VDA Scope A),2026 款车型要求改为 18 PA(VDA Scope A+MAN.5 变更管理 + ACQ.4 供应商监控)。已通过 16 PA Level 2 的供应商 verdict 自动失效——因为 verdict 与 scope 严格绑定,scope 变更 = 需重评估。重评仅针对新增 2 PA(约 2 天现场),但若 MAN.5 基线管控从未规范(变更 impact analysis 缺失),MAN.5 可能只有 Level 1,直接拖累整体 verdict。提前在项目立项时确认 OEM 的 ASPICE scope 版本并锁定在 DIA 附件中。
核心要点
- ASPICE Capability Level 0-5 阶梯——OEM 普遍要求 Level 2;ASIL D 通常要 Level 3。
- 每个 Level 由 PA (Process Attribute) 组成——Level 1 = PA1,Level 2 = PA1+PA2,以此类推。
- 评分 N/P/L/F 四档 (< 15% / 15-50% / 50-85% / > 85%)。
- Level 通过条件:前面 Level 全 F + 当前 Level PA ≥ L——任一 PA 短板 = 整体降级。
- PA1 检查"BP 做没做"(产品输出),PA2 检查"流程管没管"(计划+工件)。
- 评估周期 3-6 月,成本 ¥40-100 万,Assessor 需要 iNTACS / VDA 资质。
- 最常丢分:traceability 断 + PA2 工件管控乱——DOORS/Polarion + SUP.8 是底层基础设施。
- ASPICE Level 与 ISO 26262 ASIL 互补——ASIL D + Level 3 是事实上的双保险。
Engineering Objects
引用此页的结构化 Engineeri…
引用此页的结构化 Engineering Object(v2.0 Copilot 自动生成,不要手动编辑此段)。
- standard ·
standard_aspice— Automotive SPICE
Cross-references
- ← 索引
- Automotive SPICE — ASPICE 总览
- ASPICE PA 详解 — 16 PA 详细 reference
- TSC + DIA — TSR 进 SYS.2 双向 trace
- Confirmation Measures — ASPICE Assessment vs FSA 区别
- 功能安全 — ASIL 与 ASPICE Level 对应
- IATF 16949 — IATF Audit vs ASPICE Assessment
- PEU 全流程交付物 — Phase 4 ASPICE 正式评估