K4-04 · 控制、软件与标定 / 嵌入式软件与开发
待认领listed
→
众筹中recruiting
→
已开课open · Course 售卖
一课题可并存多讲师版本
课程大纲
学完能做什么
- 能设计一套软件版本号方案，清楚区分接口变更/功能新增/缺陷修复三类变更
- 能搭建变型管理方案，用参数化/特性开关而非复制代码来支撑多车型复用
- 能建立需求-模型-代码-标定数据的基线关系，支撑变更影响分析
- 能设计一套变更管理流程（CR提出-评审-实施-验证-发布），避免“改了没人知道”
- 能区分软件配置管理与标定数据版本管理各自管什么、边界在哪（衔接K6-05）
- 能把本课的产出物逐条对上软件过程参考模型的过程域（架构文档→SWE.2、模型与生成代码→SWE.3、验证与测试→SWE.4~SWE.6、基线与配置项→SUP.8、CR 与影响分析→SUP.10、需求追溯→SWE.1），并说清过程评估看的是过程有没有被执行、被管理，证据能不能重复取到，而不是技术水平高低
内容大纲
- 为什么软件也要配置管理：配置项清单与追溯目的
- 一套ECU软件要供多个车型/多个硬件版本复用，代码分叉管理不好会“改一个坏三个”
- 配置管理对象：需求（控制域里「需求」这一配置对象的载体就是控制功能规格文档，其基线冻结时点与触发 CR 的条款粒度见 K4-07）、模型、生成代码、标定数据、测试证据（测试规程、结果记录、覆盖率报告——ASPICE SUP.8 与 SWE.4~SWE.6 的双向追溯要求测试件一并进基线，覆盖率定义本体见 K4-03）、诊断描述文件（CANdela CDD / ASAM ODX）与 DTC 清单（它既是软件实现的一部分、又是售后诊断仪的输入件，不纳管就会出现车上的码与诊断仪库对不上）、工具链版本本身，缺一不可
- 与传统机械件图纸版本管理类比，但软件的分支/合并复杂度更高
- “能追溯”是核心目的：出了问题能定位到具体是哪个版本、哪次变更引入的
- 版本号、分支策略与基线
- 语义化版本：主版本（不兼容接口变更）/次版本（新增功能）/补丁版本（缺陷修复）
- 分支策略：主干开发 vs 特性分支，release分支冻结后只进缺陷修复
- 基线（Baseline）：某个时间点一组关联产物（需求+模型+代码+标定+测试证据+工具链版本）的固定快照
- 合并冲突的高发点：多人同时改同一个Simulink模型文件
- 变型管理：一套架构支撑多车型
- 变型的来源：硬件差异（不同传感器/执行器配置）、功能差异（有无热泵/多通阀数量）
- 变型编码：用参数/特性开关而非复制整个代码库来区分变型（呼应K4-01架构设计）
- 变型爆炸问题：特性数量增多时组合数指数增长，需靠模块化/参数化收敛而非穷举分支
- 变型矩阵的维护：哪个特性组合对应哪个车型/硬件，谁来维护这张表；变型编码不是止于代码基线——它最终要在整车 EOL 工位由诊断仪按 VIN 写入 ECU 并回读校验，写错就是装错车（产线写入流程、错写表现与拦截手段见 K6-09），配置管理侧要保证的是「变型矩阵—可写配置字—发布件」三者一一对应、可追溯
- 变更管理流程：CR、影响分析与追溯矩阵
- 变更请求（CR）的提出、影响分析、评审、实施、验证、关闭全流程
- 影响分析要覆盖的维度：功能安全等级是否变化；是否影响已发布车型；需重新做哪一层级的验证（单元/集成/合格性）与哪种在环形态（MIL/SIL/PIL/HIL）——回归范围怎么裁、凭什么判据裁见 K4-08，本课不自造判据；本次变更是否新增/删除 DTC 或改变其触发条件与语义，若是则须同步更新诊断描述文件、售后码表与诊断仪数据库并通知售后端；是否改变 NVM 数据布局或学习值语义（数据结构与迁移机制本体见 K4-06）
- 紧急缺陷修复（Hotfix）与常规迭代release的流程差异
- 变更记录与追溯矩阵：谁改的、为什么改、改了影响哪些下游
- 发布件构成与刷写完整性
- 发布件的构成：可执行代码+标定数据集+诊断描述文件/售后码表（须与软件同批次发布、版本号对齐）+版本标识+校验和，缺一不可；对供应商交付、自供应商接收时还要加上跨企业那几项：交付形态标识（源码/目标码/受保护模型/FMU/SWC+ARXML 哪一档）、随件的可标定量清单与其授权等级、验证证据包（覆盖率报告/HIL 报告/安全分析工作产物）、以及该形态下 OEM 可改动范围的声明——判据与形态谱见 K4-09，照纯内部视角的清单验收跨企业交付必漏
- 软件完整性校验：发布产物的校验和/签名机制，防止现场刷错版本；另外发布件还必须声明它对上一版本车端 NVM 数据布局的兼容关系（可直接沿用／需迁移／需清除重学三档），以及新增或重排标定量时旧布局的迁移规则与默认值填充策略——前面那几件套只覆盖「出厂前资产」，刷进车后与车上那份自产数据的兼容性无人声明，正是「升级失败残留半套参数、执行器行为异常难定位」的直接来源（数据结构与迁移机制本体见 K4-06）
- 配置管理的职责边界与工具链版本贯通
- 三方分工边界：软件配置管理（本课，管代码/模型/需求，需求的载体见 K4-07）、标定数据版本管理（K6-05，管标定参数值）、CAE 资产管理（J7-07，管仿真模型/网格/求解设置/物性 map/后处理脚本）——三张配置项清单既不许重叠、也不许留空档，否则三门课互相踢皮球
- 工具生态：需求管理、代码版本控制、标定数据管理三套工具怎么互相引用版本号；版本标识还得能从车上读回来才算闭环——软件版本/硬件版本/标定版本与零件号分别落在 UDS 的标识类 DID 上（ISO 14229-1 在 F180–F1FF 区段定义了整车厂与供应商的软/硬件版本号、零件号等标识符，本项目具体分配以诊断规范为准），下线与售后用 0x22 读出后与刷写文件（ODX/Hex）内的版本块做一致性比对，服务与 DTC 机制本体见 K5-01
关键公式
Version = MAJOR.MINOR.PATCH
语义化版本号：主版本号变化代表不兼容接口变更，次版本号代表新增功能，补丁号代表缺陷修复
N_变型组合(最坏情况) = 2^n_特性开关
变型数随二元特性开关数量指数增长，说明为什么不能靠穷举分支应对多车型复用，只能靠参数化收敛
追溯覆盖率 = 已建立追溯关系的需求数 / 总需求数
衡量需求-模型-代码-标定这条追溯链的完整度，是变更影响分析能否做准的前提
发布件 = {可执行代码, 标定数据集, 诊断描述文件/售后码表, 版本标识, 校验和}
一个可交付的软件版本由这五部分共同定义，缺一个都不能算完整发布件；诊断描述文件与售后码表决定车上置出的 DTC 能不能被诊断仪正确解读，漏发即等于该版本的故障码在售后端失明。表达构成关系而非数值公式
关键概念
语义化版本基线Baseline分支策略变型编码变型爆炸变更请求CR影响分析追溯矩阵发布件校验和/签名配置管理对象过程参考模型与能力等级标识类DID与版本块比对NVM数据布局兼容性声明交付形态标识
推荐工具与标准
Git/GitLab（代码与模型版本控制） PTC Integrity / IBM ClearCase（配置管理平台） DOORS/Polarion（需求管理与追溯） Jira/禅道（变更请求流程）
ISO 26262-8（支持流程，含配置管理与变更管理条款） Automotive SPICE 过程参考/评估模型（本课的正文落点：基线与配置项清单→SUP.8 配置管理、CR 流程与影响分析→SUP.10 变更请求管理、软件架构文档→SWE.2、模型与生成代码→SWE.3、验证与测试工作产物→SWE.4~SWE.6（本体见 K4-03）、需求追溯→SWE.1；⚠ 3.1 与 4.0 两版并行流通，4.0 调整过过程域名称与工作产物编号，引用时必须显式声明所依版本、不得混引） IATF 16949（质量管理体系，含变更管理要求）
工程案例
某平台化车型软件同时支撑有热泵/无热泵两种配置，早期靠复制代码库分别维护，一次共性缺陷修复只改了一份，另一份车型带着老缺陷流入市场。后改为变型编码+统一主干开发，修复一次覆盖所有变型，靠追溯矩阵确认受影响车型并安排修复。
动手做
交付物 · 给定当前版本V2.3.1，要新增电池预热策略（不改接口）并修复多通阀切换缺陷：① 给出下一版本号并说明理由；② 设计CR记录要素（变更内容/影响分析/需回归范围——回归范围的裁剪判据出自 K4-08，按其判据填，不自造判据）；③ 列出发布件完整性构成清单。交付版本方案+CR模板+发布清单。
常见误区
- 靠复制代码库应对多车型变型，共性缺陷修复容易漏改某个分支，且长期维护成本指数增长
- 版本号随意升级，看不出这次发布是接口变更还是纯缺陷修复，下游标定/测试团队不知道要不要重新验证
- 需求变更了没有同步触发模型/代码/测试用例的重新评审，追溯链断掉，变更影响分析靠人工回忆
- 标定数据和代码耦合在同一个版本号里管理，标定工程师微调一个参数却要走完整代码发布流程
- 紧急Hotfix直接在release分支改完就发，没有合并回主干，下次常规迭代又把这个缺陷带回来
- 过程评估里的典型掉分点：文档在但没有评审记录；追溯只做单向；变更记录与实际提交对不上、Hotfix 未合回主干；工具链版本没纳入配置项；测试用例没随需求变更更新——每一条都是「事做了、证据不成链」，评级掉的是过程属性不是技术水平
相关课题