ASPICE VDA Scope 16 PA 详解

功能安全L1别名 ASPICE PA · VDA Scope PA · SYS PA · SWE PA · SUP PA · MAN PA · 16 PA 详解

本质与导读

本质 ASPICE 不是"做产品"标准而是"管过程"标准——每个 Process Area 只问"你的工作 process 有没有定义、跟没跟、validate 没"。评估的最小颗粒是 Base Practice (BP):审计员对每个 BP 答 Yes/No,所有 BP Yes 才达成 PA1 (Process Performance);OEM 评估主看 16 个 VDA Scope PA。

主线坐标:方法 / 标准层(跨站支撑) · ↑ 全景主线

1. VDA Scope 16 PA 全景

ASPICE 4.0 共 32 个 PA,OEM 评估主要看 VDA Scope 的 16 个:

ASPICE VDA Scope V 模型 — 16 PA 分布于 V 两侧 + 横向支撑

组PA 编号名称
ACQACQ.4Supplier Monitoring (供应商监控)
SYSSYS.1Requirements Elicitation (需求获取)
SYS.2System Requirements Analysis (系统需求分析)
SYS.3System Architectural Design (系统架构设计)
SYS.4System Integration & Test (系统集成与测试)
SYS.5System Verification (系统验证)
SWESWE.1Software Requirements Analysis (软件需求分析)
SWE.2Software Architectural Design (软件架构设计)
SWE.3Software Detailed Design & Unit Construction (软件详设 + 单元实现)
SWE.4Software Unit Verification (软件单元验证)
SWE.5Software Integration & Integration Test (软件集成与集成测试)
SWE.6Software Verification (软件验证)
SUPSUP.1Quality Assurance
SUP.8Configuration Management
SUP.9Problem Resolution Management
SUP.10Change Request Management
MANMAN.3Project Management
MAN.5Risk Management
MAN.6Measurement

说明:虽然官方算 16 个 VDA Scope PA,实际有的版本算 21 个 (含 MAN.5/MAN.6/SUP.1 等),OEM 偶有差异。国内主流按 16 PA 核心。

2. SYS 系统工程组

2.1 SYS.1 Requirements Elicitation

SYS.1 的核心目的是把 OEM SOR + VOC 翻译成内部需求。具体 BP / work product / 陷阱如下:

  • 目的:把 OEM SOR + VOC 翻译成内部需求
  • BP1:获取相关方需求
  • BP2:理解相关方期望
  • BP3:相关方需求达成共识
  • BP4:建立相关方需求基线
  • BP5:管理相关方需求变更
  • 典型 work product:Requirements Specification、SOR Trace Matrix
  • 关键陷阱:把 OEM SOR 直接复制,没翻译成"我们能交付的语言"

2.2 SYS.2 System Requirements Analysis

SYS.2 的核心目的是从相关方需求 → 系统级需求。具体 BP / work product / 陷阱如下:

  • 目的:从相关方需求 → 系统级需求
  • BP1:指定系统需求
  • BP2:分析系统需求 (完整性 / 一致性 / 可测试性)
  • BP3:分析对系统的影响
  • BP4:确保一致性 + 建立双向 traceability ↔ SYS.5
  • BP5:相关方达成共识
  • BP6:沟通已同意的系统需求
  • 典型 work product:System Requirements Spec (SyRS)、需求 review 记录
  • traceability:SYS.2 ↔ SYS.5 (验证回链)

2.3 SYS.3 System Architectural Design

SYS.3 的核心目的是把系统需求分解到子系统/组件 (硬件 + 软件)。具体 BP / work product / 陷阱如下:

  • 目的:把系统需求分解到子系统/组件 (硬件 + 软件)
  • BP1:开发系统架构 (功能 + 非功能)
  • BP2:分配系统需求到架构元素
  • BP3:定义元素接口 (HSI、API、协议)
  • BP4:描述动态行为
  • BP5:评估替代架构方案
  • BP6:建立 traceability ↔ SYS.4
  • 典型 work product:System Architectural Design (SyAD)、HSI Spec、接口控制文档
  • 关键认知:SYS.3 是 HSI 文档的产出地 (topic-tsc-dia)

2.4 SYS.4 System Integration & Integration Test

SYS.4 的核心目的是把组件集成成完整系统并测试集成功能。具体 BP / work product / 陷阱如下:

  • 目的:把组件集成成完整系统并测试集成功能
  • BP1:开发系统集成策略
  • BP2:开发集成测试规约 (从 SYS.3 推导)
  • BP3:集成系统元素
  • BP4:选择测试用例
  • BP5:执行集成测试
  • BP6:traceability ↔ SYS.3
  • 典型 work product:Integration Test Plan、Integration Test Results
  • traceability:SYS.4 ↔ SYS.3 (设计 ↔ 集成测试)

2.5 SYS.5 System Verification

SYS.5 的核心目的是验证系统是否满足 SYS.2 需求。具体 BP / work product / 陷阱如下:

  • 目的:验证系统是否满足 SYS.2 需求
  • BP1:开发系统验证策略
  • BP2:开发系统验证测试规约
  • BP3:选择测试用例
  • BP4:执行系统测试
  • BP5:测试结果与需求对比
  • BP6:traceability ↔ SYS.2
  • 典型 work product:System Verification Plan、System Verification Report
  • 关键认知:SYS.5 是 V 模型右上,与 SYS.2 双向 trace 是 ASPICE 评估高频丢分项

3. SWE 软件工程组

3.1 SWE.1 Software Requirements Analysis

SWE.1 的核心目的是从系统需求 → 软件需求 (功能 + 非功能 + 验收)。具体 BP / work product / 陷阱如下:

  • 目的:从系统需求 → 软件需求 (功能 + 非功能 + 验收)
  • BP1:指定软件需求
  • BP2:分析软件需求
  • BP3:分析对软件的影响
  • BP4:确保一致性 + traceability ↔ SWE.6 + ↔ SYS.3
  • 典型 work product:Software Requirements Spec (SwRS)

3.2 SWE.2 Software Architectural Design

SWE.2 的核心目的是软件架构,分解到 unit。具体 BP / work product / 陷阱如下:

  • 目的:软件架构,分解到 unit
  • BP1:开发软件架构 (分层 / 组件)
  • BP2:分配软件需求到架构元素
  • BP3:定义元素接口 (API)
  • BP4:描述动态行为
  • BP5:评估资源消耗 (CPU / RAM / Flash)
  • BP6:traceability ↔ SWE.5
  • 典型 work product:Software Architectural Design (SwAD)

3.3 SWE.3 Software Detailed Design & Unit Construction

SWE.3 的核心目的是详细设计 + 单元代码实现。具体 BP / work product / 陷阱如下:

  • 目的:详细设计 + 单元代码实现
  • BP1:开发软件详细设计
  • BP2:定义内部数据 + 接口
  • BP3:描述动态行为
  • BP4:开发单元代码
  • BP5:traceability ↔ SWE.4
  • 典型 work product:Detailed Design、Source Code

3.4 SWE.4 Software Unit Verification

SWE.4 的核心目的是单元测试 + 静态分析。具体 BP / work product / 陷阱如下:

  • 目的:单元测试 + 静态分析
  • BP1:指定单元验证策略 + 准则
  • BP2:选择单元验证方法 (单元测试 + 静态分析 + 代码审查)
  • BP3:执行单元验证
  • BP4:验证单元设计 + 代码与需求一致
  • BP5:traceability ↔ SWE.3
  • 典型 work product:Unit Test Plan、Coverage Report (ASIL D 强制 MC/DC ≥ 90%)、Static Analysis Report

3.5 SWE.5 Software Integration & Integration Test

SWE.5 的核心目的是集成软件单元为软件,并测试。具体 BP / work product / 陷阱如下:

  • 目的:集成软件单元为软件,并测试
  • BP1:开发软件集成策略
  • BP2:开发集成测试规约
  • BP3:集成软件单元
  • BP4:执行集成测试
  • BP5:traceability ↔ SWE.2
  • 典型 work product:Integration Test Plan、Results

3.6 SWE.6 Software Verification

SWE.6 的核心目的是验证软件是否满足 SWE.1 需求。具体 BP / work product / 陷阱如下:

  • 目的:验证软件是否满足 SWE.1 需求
  • BP1:开发软件验证策略
  • BP2:开发软件验证测试规约
  • BP3:执行软件验证
  • BP4:traceability ↔ SWE.1
  • 典型 work product:Software Verification Plan、Report

4. SUP 横向支撑组

4.1 SUP.1 Quality Assurance

SUP.1 的核心目的是确保 work product 质量。具体 BP / work product / 陷阱如下:

  • 目的:确保 work product 质量
  • BP1:开发 QA 策略
  • BP2:确保产品质量
  • BP3:确保流程质量
  • 典型 work product:QA Plan、Audit Reports

4.2 SUP.8 Configuration Management

SUP.8 的核心目的是配置项管理 (基线、版本、组成)。具体 BP / work product / 陷阱如下:

  • 目的:配置项管理 (基线、版本、组成)
  • BP1:建立配置管理策略
  • BP2:识别配置项
  • BP3:建立配置 baseline
  • BP4:控制变更
  • BP5:报告配置状态
  • 典型 work product:CM Plan、Configuration Status Report

4.3 SUP.9 Problem Resolution Management

SUP.9 的核心目的是跟踪和解决 bug。具体 BP / work product / 陷阱如下:

  • 目的:跟踪和解决 bug
  • BP1:开发问题解决策略
  • BP2:识别问题
  • BP3:记录问题
  • BP4:分析问题
  • BP5:授权问题解决
  • BP6:跟踪 + 关闭
  • 典型 work product:Problem Reports、Bug Tracker

4.4 SUP.10 Change Request Management

SUP.10 的核心目的是变更管理。具体 BP / work product / 陷阱如下:

  • 目的:变更管理
  • BP1:开发变更管理策略
  • BP2:记录变更请求
  • BP3:分析影响
  • BP4:授权 + 实施
  • BP5:跟踪 + 关闭
  • 典型 work product:Change Request Database、Impact Analysis

5. MAN 项目管理组

5.1 MAN.3 Project Management

MAN.3 的核心目的是项目计划 + 跟踪。具体 BP / work product / 陷阱如下:

  • 目的:项目计划 + 跟踪
  • BP1:定义工作范围
  • BP2:定义项目生命周期
  • BP3:可行性评估
  • BP4:定义所需活动 + 任务
  • BP5:定义需求 (资源/时间/成本)
  • BP6:定义接口 (内部/外部)
  • BP7:决策评估
  • BP8:授权 + 实施
  • BP9:监控项目
  • BP10:Take corrective action
  • 典型 work product:Project Plan、Status Reports

5.2 MAN.5 Risk Management

MAN.5 的核心目的是项目级风险管理。具体 BP / work product / 陷阱如下:

  • 目的:项目级风险管理
  • BP1:建立风险管理范围
  • BP2:定义风险管理策略
  • BP3:识别风险
  • BP4:分析风险
  • BP5:评估优先级
  • BP6:定义风险响应
  • BP7:监控风险
  • 典型 work product:Risk Register

5.3 MAN.6 Measurement

MAN.6 的核心目的是度量驱动管理。具体 BP / work product / 陷阱如下:

  • 目的:度量驱动管理
  • BP1:建立度量目标
  • BP2:定义度量指标
  • BP3:数据采集 + 存储
  • BP4:分析 + 沟通
  • 典型 work product:Measurement Plan、Metrics Reports

6. ASPICE 4.0 新增 PA

ASPICE 4.0 相比 3.1 新增 9 个 PA——主要扩展到硬件和机器学习:

PA名称关注
HWE.1Hardware Requirements Analysis硬件需求 (从 SYS.3 推导)
HWE.2Hardware Design硬件设计
HWE.3Hardware Detailed Design & Production硬件详设 + 量产工艺
HWE.4Hardware Verification硬件验证 (含 DV)
MLE.1ML Data ManagementAI 训练数据管理
MLE.2ML TrainingAI 模型训练
MLE.3ML Model TestingAI 模型测试
MLE.4ML DeploymentAI 模型部署
SUP.11Machine Learning EngineeringAI 横向支撑 (含 ACE for Cybersecurity)

关键认知:HWE 把硬件流程也纳入 ASPICE,很多 OEM 在 2024 后强制 HWE Level 2——以前硬件只走 PPAP/AEC-Q,现在也要 ASPICE。

7. 双向 Traceability 全图

ASPICE 评估最容易丢分的就是 traceability——下面这张表展示 16 PA 间的双向链:

左侧 (设计/需求)右侧 (验证/测试)trace 类型
SYS.2 (System Requirements)SYS.5 (System Verification)一对一
SYS.3 (System Architecture)SYS.4 (System Integration)一对一
SWE.1 (Software Requirements)SWE.6 (Software Verification)一对一
SWE.2 (Software Architecture)SWE.5 (Software Integration)一对一
SWE.3 (Detailed Design)SWE.4 (Unit Verification)一对一

实操:用 DOORS / Polarion / Jama 等需求工具,每条需求 ID 必须在左右两侧都有 entry,且每个 entry 互相引用。

8. 16 PA 与 ISO 26262 / ASIL 的关系

ASPICE PA 与 ISO 26262 高度互补:

ASPICE PAISO 26262 对应
SYS.2Item Definition + Safety Goal + FSC
SYS.3TSC + HSI (topic-tsc-dia)
SWE.1Software Safety Requirements
SWE.2Software Architecture (Part 6 §7)
SWE.3Software Detailed Design (Part 6 §8)
SWE.4Software Unit Testing (Part 6 §9, MC/DC)
SYS.4/5Item Integration & Testing (Part 4 §9)
SUP.8Configuration Mgmt (Part 8 §7)
SUP.10Change Mgmt (Part 8 §8)

关键认知:ASPICE 提供"流程证据"作为 topic-safety-case 的章节——ASPICE Capability Level 2 通常被视为 ASIL B/C 的最低要求,ASIL D 通常要求 Level 3。

核心要点
  • VDA Scope 16 PA 分 5 组:ACQ.4 / SYS.1-5 / SWE.1-6 / SUP.1,8,9,10 / MAN.3,5,6。
  • 每个 PA 由若干 BP (Base Practice) 组成,评估时审计员对每个 BP 问 Yes/No。
  • V 模型左右两侧通过双向 traceability 闭环——SYS.2 ↔ SYS.5,SWE.1 ↔ SWE.6 等。
  • SYS.3 是 HSI 文档产出地——也是 topic-tsc-dia 里 TSC 的对接点。
  • SWE.4 单元验证 ASIL D 要求 MC/DC 覆盖率 ≥ 90%。
  • ASPICE 4.0 新增 HWE 1-4 (硬件) + MLE 1-4 (机器学习) + SUP.11——硬件也要 ASPICE。
  • 评估最常丢分是 traceability——每对需求 ID 必须双向引用,工具 (DOORS/Polarion) 强制。
  • ASPICE 与 ISO 26262 互补:ASPICE Level 2 = ASIL B/C 最低,Level 3 = ASIL D 推荐。

Engineering Objects
引用此页的结构化 Engineeri…

引用此页的结构化 Engineering Object(v2.0 Copilot 自动生成,不要手动编辑此段)。

Cross-references