芯耀
与非AI
124
这张地图回答一个核心问题：汽车电子/软件研发到底怎么走、每一步落在哪、谁跟谁咬合。答案是一条横向（整车产品生命周期：概念→SOP→售后，管“走到哪”）叠加一条纵向（系统/软件研发 V 模型：ASPICE SYS/SWE，管“怎么做对”），再叠加 ISO 26262 功能安全、ISO 21448 预期功能安全（SOTIF）与 ISO 21434 网络安全作为横切主题。看懂这两条轴如何叠加，就梳理出整车开发流程的总纲。
概述与目的
本册是系列的开篇与总纲，给整车/电子电气研发、测试、功能安全、信息安全工程师与项目经理建立一张全流程地图：产品生命周期如何与研发 V 模型叠加、ASPICE 落在整车研发的哪一段、它与 ISO 26262 和 ISO 21434 如何联合评估。后文各册按这张地图逐级展开——从系统级 SYS、到软件级 SWE、及支持与管理 SUP/MAN、评估与改进、工程落地等。
两条轴：生命周期轴回答“项目走到哪一步”，以阶段推进 × 把关（Gate）双轨运行；V 模型轴回答“这一步怎么做对”，以需求分解 × 集成验证双向闭环。两条轴叠加在同一项目上，SOP 是研发到量产的物理分水岭。
整车产品生命周期：阶段、Gate 与输入输出
整车流程把研发切成八段、七个把关点。V 模型恰好落在“详细工程开发 → EP/PV 验证”段——EP/PP/PV/SOP 四级是距量产最近、把关最重的节点。
整车产品生命周期：从概念到量产售后
研发过程按“阶段推进 × 门径把关”双轨运行，SOP 是研发→量产的物理分水岭
系统/软件研发 V 模型（SYS · SWE）
V 模型是研发 V 轴的主干：左支把需求从系统逐级分解到软件单元，右支自底向上逐级集成验证，每级验证回溯对应需求级，形成可追溯闭环。
系统 / 软件研发 V 模型（ASPICE SYS · SWE）
左支逐级分解需求（自上而下），右支逐级集成验证（自下而上），左右同层镜像对齐，每一级验证都回溯对应需求级
V 模型两侧构成可追溯闭环：左支每级需求（SYS.1→SWE.3）都在右支有对应验证（SYS.5 回溯 SYS.2、SYS.4 回溯 SYS.3、SWE.6 回溯 SWE.1、SWE.5 回溯 SWE.2、SWE.4 回溯 SWE.3），同层左右镜像对齐，缺一级即出现追溯断链。
过程组全景（PAM 3.0，8 组 32 过程）：
| 组 | 全称 | 过程 |
|---|---|---|
| SYS | 系统工程 | SYS.1 需求引出 · SYS.2 需求分析 · SYS.3 架构设计 · SYS.4 集成测试 · SYS.5 合格性测试 |
| SWE | 软件工程 | SWE.1 需求 · SWE.2 架构 · SWE.3 详细设计/单元 · SWE.4 单元验证 · SWE.5 集成测试 · SWE.6 合格性测试 |
| SUP | 支持过程 | SUP.1 QA · SUP.2 验证 · SUP.4 联合评审 · SUP.7 文档 · SUP.8 配置管理 · SUP.9 问题解决 · SUP.10 变更请求 |
| MAN | 管理过程 | MAN.3 项目管理 · MAN.5 风险管理 · MAN.6 测量 |
| ACQ | 获取过程 | ACQ.3/4 · ACQ.11–15 |
| SPL | 供应过程 | SPL.1 供应商投标 · SPL.2 产品发布 |
| PIM | 过程改进 | PIM.3 过程改进 |
| REU | 复用 | REU.2 复用程序管理 |
能力等级（评“过程做得多好”）：
| 等级 | 名称 | 含义 |
|---|---|---|
| CL0 | Incomplete | 过程未实施或未实现目的 |
| CL1 | Performed | 已执行并实现过程目的（PA 1.1） |
| CL2 | Managed | 受控实施、工作产品被建立维护（PA 2.1/2.2） |
| CL3 | Established | 采用已定义过程（PA 3.1/3.2） |
| CL4 | Predictable | 定量预测与纠正（PA 4.1/4.2） |
| CL5 | Innovating | 持续改进响应组织变更（PA 5.1/5.2） |
NPLF 评分与塌级规则：评分用 N（0–15%）、P（15–50%）、L（50–85%）、F（>85%）区间；塌级指目标级全部过程属性须 ≥L 且其下所有低级过程属性必须全 F——CL3 被 PA2.1/2.2 任一个 P 直接塌回 CL2，不存在“平均达标”。日常口语的 0/1/2/3 只是序数速记，标准本体是百分比区间判定。
ASPICE 在整车研发中的位置与关键工件
ASPICE 的工程过程（SYS/SWE）落在“详细工程开发 → EP/PV 验证”段，是这段的节拍器；SUP/MAN 支持管理过程横切全程；ISO 26262 与 ISO 21434 在此段与 ASPICE 联合叠加。
ASPICE 在整车研发中的位置
整车流程管“走到哪”，V 模型管“怎么做对”，ASPICE 是详细工程段的节拍器，SUP/MAN 横切全程
关键工件（BP 级，后续逐项拆解）：
| 工件 | 对应过程 | 作用 |
|---|---|---|
| PDD 产品定义文档 | SYS.1/2 | 伞文档：外部接口 + 13 类产品需求，需求唯一 ID + ASIL |
| RAR 需求分析报告 | SYS.1/2 | 客户需求逐条分析，流经 BP 最多的活文档 |
| RTD 需求可追溯矩阵 | SYS.2 | 双向追溯，DOORS 里 PDD 的 view |
| SRD 软件需求文档 | SWE.1 | 软件需求 + 派生需求，PDD 的软件下钻 |
| SEMP 系统工程管理计划 | MAN.3 | 策略载体，15 过程域 × 七件套（Strategy/Objectives/…/Tools） |
| SyTS/SyTR · STS/STR | SYS.4/5 · SWE.6 | 系统/软件测试规范与结果报告 |
| Risk Register 风险登记册 | MAN.5 | 风险 P×I 评分、升级链、Plan A/B |
与其他过程/标准接口：四套标准联合评估
ASPICE、ISO 26262（功能安全）、ISO 21448（预期功能安全 SOTIF）、ISO 21434（网络安全）评的不是同一种东西，但都在同一项目、同一过程模型上取证，走向同一条评估，而非四套独立体系。
联合评估要点：
ASPICE × ISO 26262：在同一过程模型里用红色标注“附加的安全相关内容”一起评，不另跑两套评估；功能安全证据链为 HARA → Safety Goal → TSR 追溯 + FTA/DFA 报告 + Safety Case。
ASPICE × ISO 21434：TARA + 威胁模型 + Cyber Assurance Case 作为过程能力输入；早期实践（Delphi/Aptiv）早于 21434 正式版，参数陈旧只能当 checklist 起点。
裁剪：客户 SOW 要求 ASPICE/26262 才从全量起步；无要求或只要求 L1 允许裁，裁剪写进 SEMP/SDP，合规项目升 Chief Engineer 批准。
“过 ASPICE” 本质：各家裁剪不同 scope 的混合体——Ford 用 HIS scope +3 过程、Nissan 用约 90% 重合的 checklist、VW 用等级给供应商定级，没有一套固定标准答案。
ISO21448 预期功能安全（SOTIF）：补 26262 的空白——非故障、非网络攻击，而是功能本身性能不足导致的风险（感知/环境/ODD/触发条件）；证据为场景库分析 + SOTIF Case，与 26262 的 Safety Case 合并为完整安全论证，L3/L4 与在役安全（ISMR）尤其依赖它。
实战要点与常见问题
PAM不是 checklist：PAM 提供 indicator（证据线索），评分只能建立在“工作产品检查 + 过程执行者访谈”两类客观证据上，把 BP/WP 当强制清单逐条对着审是评估外行。
PRMv4.3 是 2007 旧版：不是 PAM 3.0 的升级版；ENG.1–10 旧编号 → SYS/SWE 新编号（ENG.5 拆成 SWE.2 + SWE.3）。
PAM3.0 无硬件与网络安全过程：HW.1–6、网络安全过程是 v3.1/v4.x 才进入 scope；用软件 SPICE 硬套硬件评估难以 1:1 支撑。
V 模型缺级即断链：任何一级右支验证缺失对应左支需求级，评估即出现追溯断链、该过程失分。
工具链与版本滞后是高频坑：需求管理工具迁移（DOORS→Polarion）、DFMEA 停在 AIAG 4.0 未跟 AIAG-VDA 2019、网络安全实践停在 2015 年前后——评估员会直接质疑版本一致性。
参考来源
- Automotive SPICE PAM 3.0（过程参考模型 + 评估模型，ISO/IEC 33020）Automotive SPICE PRM v4.3（2007 旧版参考模型）· v3.1 Pocket GuideISCN-Automotive-SPICE-and-Safety V1.1（SPICE 与 ISO 26262 联合评估）VDA QMC Automotive SPICE 官方出版物（4.1/4.0/3.1、Potential Analysis、Cybersecurity 2.0、SuSE 自评）小明师兄项目经验
