K6-05 · 控制、软件与标定 / 标定与匹配
待认领listed
→
众筹中recruiting
→
已开课open · Course 售卖
一课题可并存多讲师版本
课程大纲
学完能做什么
- 能设计一套标定数据（A2L/Hex/DCM）的版本管理与命名规则
- 能区分标定基线（baseline）、分支（variant）与冻结版本，管理平台化车型的标定复用
- 能建立标定变更的评审与追溯流程，明确谁能改、改了留什么记录
- 能识别标定数据管理中常见的版本对不上事故模式并给出预防措施
内容大纲
- 标定数据的构成与生命周期
- A2L描述文件与Hex/DCM参数值的对应关系（承接K6-01）
- 一个标定版本的生命周期：草稿→评审→冻结→量产→售后微调→回写主线——全程管的是**库侧**那份标定资产（A2L/Hex/DCM、分支合并、PLM 追溯）；**车上那份**（已写入控制器 NVM 的标定值，以及车辆自产的学习值/零点补偿/累计量）的结构版本、跨版本迁移与售后复位归 K4-06，两者不是同一份数据，也不共用版本号语义
- 软件版本与标定版本的耦合关系（对接K4-04软件配置管理）
- 标定数据与整车SOP节点的对齐
- 本课的管辖边界：出厂前的**离线标定参数集**（A2L/Hex/DCM）——车端运行期自己产生、要活过下一次上电的量（学习值、诊断计数、累计量）不归本课，归 K4-06，两者的版本管理机制完全不同
- 版本号语义、基线与变体分支
- 基线（baseline）与变体（variant）：平台化车型/多配置标定的复用与差异化
- 命名规则与版本号语义：哪一位表示软件、哪一位表示标定
- 分支合并的风险：不同子系统标定并行开发时如何避免冲突——冲突检测必须落到**标定量级**而非文件级（两条分支各改同一张 MAP 的不同轴点，文件级 diff 只会报「整个文件都变了」，本课 case 里那个互不知情的电池冷却启停阈值就是这样漏掉的）
- 先分清件的性质再定版本规则：随车型走的标定值是**受控发布件**（冻结、按车型追溯、随车型退役），跨车型可复用的性能基准是**参考件**（可迭代、按口径与置信度管理，见 Q3-04）——把基准值当发布件锁死会僵化，把发布件当基准值跨车型照抄会出事
- 标定量的归属与授权：责任矩阵、对外 A2L 裁剪与现场授权分级
- 标定量归属边界的提前划分
- 标定量归属边界能划清的前提，是标定量本身已有规格定义（类型/轴点/上下限/存储区/可标性等级）——规格层见 K6-10；规格没定就先分归属，只会把冲突推迟到合版那天爆发
- 标定量责任矩阵的建立：内部版与跨企业版两张——后者要与 SecurityAccess 权限等级、对外 A2L 的裁剪范围逐条对齐（见 K4-09）
- 对外发布的 A2L 裁剪与标定量对外授权分级：发给 Tier1/第三方标定商/售后的 A2L 不等于内部全量，须按标定量的安全等级与商业敏感度裁剪、按角色分级授权，并规定授权撤销与访问留痕；本体见 K4-09，本课只管裁剪版与内部全量之间的版本对应关系
- 售后/产线标定的权限分级与回写触发条件：哪类现场微调必须回写主线（涉及安全阈值、涉及批次共性问题的），哪类属一车一档不回写（单车适配、单件更换后的补偿），以及授权工具、人员分级与授权有效期；对应工位与售后场景见 K6-09、G8-05
- 变更管理与追溯
- 标定变更申请—评审—发布流程
- 安全相关标定量（对接K6-03的ASIL边界）的变更需要额外评审
- 变更记录应包含的最小信息集：谁改/为何改/影响范围/验证证据
- 台架临时调试与正式回写标定库的边界
- 仲裁表/优先级权重这类规则型标定量改一条，回归范围不能按标定量个数估——须从需求—场景矩阵反查该条规则参与过哪些冲突场景，据此圈定 HIL 回归子集（对接 K4-03 的组合场景矩阵、K5-02 的降级仲裁）；这类量默认按安全相关标定量走额外评审
- 标定量变更触发哪一档回归，与代码变更不是同一张表——判据与回归范围裁剪见 K4-08；分工写清：本课管标定值的版本与追溯，K4-08 管该变更引发的回归范围与执行
- 工具与数据库
- 专用标定数据管理系统 CDM（AVL CRETA / Vector vCDM 类）与 PLM 集成（承接K4-04）：CDM 区别于文件级配置管理的定义性能力，是依赖 A2L 解析标定量语义、做**标定量级**的分支/合并/冲突检测
- 与配置管理工具的协同：PTC Integrity（Windchill RV&S）一类平台管软件侧配置；Git 只吃 DCM、CDF/CDFX 等文本化标定数据且需标定量级 diff 工具配合，二进制 Hex 不能靠 Git 合版；需求管理工具（DOORS/Polarion）管的是需求条目与追溯矩阵，不管标定数据的版本与合并
- 自动化对比工具：新旧Hex/DCM差异比对
- 资产边界：本课管标定数据资产，CAE 仿真资产（模型、算例、可复现集）的版本与归档见 J7-07；两者版本号如何互相引用，按 K4-04 的三方分工表执行
- 常见事故模式与预防
- 台架上“临时改一下没保存回库”
- 多人并行标定不同子系统，最终合版时互相覆盖
- 售后/产线微调标定后没有回写主线，导致后续版本“退步”
- 平台化车型套用标定基线时漏改车型专属差异项
关键公式
Version = SW_ver.Cal_ver.Variant_id
三段式版本号语义：软件版本、标定版本、车型变体分段编号又可交叉追溯，是常见的命名法之一
变更覆盖率 = N_changed / N_total
本次标定变更涉及的标定量个数占标定量总数的比例，用于决定评审级别（局部微调 vs 全量评审）
追溯完整率 = N_traceable / N_total
有完整变更记录（谁改/为何改）的标定量占比，是衡量标定数据管理健康度的量化口径之一；这个口径连同「变更记录应包含的最小信息集」可直接迁移为跨车型性能基准库的入库门槛（见 Q3-04）
冲突概率 ∝ 并行标定人数 × 重叠标定量个数
定性关系：并行标定的人越多、标定量归属边界划得越模糊，合版冲突的概率越高，说明要提前划清责任矩阵
关键概念
A2L描述文件Hex/DCM参数集标定基线 baseline变体 variant标定冻结变更评审追溯记录版本号语义差异比对 diff配置管理标定量责任矩阵标定数据管理系统 CDM（标定量级 diff/merge/冲突检测）
推荐工具与标准
INCA/CANape工程库（承接K6-01） PTC Integrity / DOORS类配置管理工具 Git（部分车企标定文本化管理的尝试） 标定数据库/PLM系统 专用标定数据管理系统 CDM（Calibration Data Management，代表产品 AVL CRETA / Vector vCDM 类）——核心能力是标定量级而非文件级的分支/合并/冲突检测
ASAM MCD-2 MC / ASAP2（A2L标定描述文件标准，承接K6-01） ISO 26262（安全相关标定变更的评审要求） 企业级标定管理规范体系（以主机厂内部SOP为主） GB 44496-2024《汽车软件升级通用技术要求》（强制性，2024-08-23 发布 / 2026-01-01 实施）与 ISO 24089:2023《道路车辆 软件升级工程》——本课与它们只有一个接界点：当某个标定版本要以软件升级（OTA 或售后离线刷写）形式下发到车上时，其对软件/标定版本标识、可追溯性与升级前后一致性的要求会直接约束本课的版本号语义与追溯记录口径；升级在车端的实施与验证不在本课，见 K7-02（OTA 技术链路与 A/B 双分区刷写、刷写窗口热安全准入与回滚停位、灰度与回滚门限、软件×硬件变型×标定三维版本兼容矩阵）、K4-06（NVM 数据块布局的版本迁移与 OTA 后残留半套数据）；该标准要求的备案、涉安全变更审批与召回三档准入判定见 M4-08
工程案例
某车型平台化项目中两个衍生车型并行标定，量产前合版时发现两条分支各自改了同一个电池冷却启停阈值且互不知情；用差异比对工具揪出冲突项、倒查变更记录，事后补上标定量责任矩阵与合并前强制diff检查。
动手做
交付物 · 给定两个衍生车型并行标定后的差异比对结果（可自行假设合理的参数差异清单），①判断哪些差异是预期的车型专属差异、哪些是疑似冲突；②设计一版区分普通与安全相关两级的标定变更评审流程；③给出该项目标定数据版本号命名规则草案。
常见误区
- 台架上临时改参数调试，调完没有正式回写标定库，下次上车又是老版本
- 标定变更没留“为什么改”的记录，几个月后要复现问题却查不出当时依据
- 安全相关标定量改动走了普通评审通道而非功能安全评审，埋下风险
- 平台化车型直接复制基线，没检查车型专属差异项（如电池包容量、目标ΔT_pack不同）
- 售后/产线的现场微调标定没有回写主线，导致下一个量产批次“退步”到微调前的问题
- 平台套用基线时只比对标定值、没比对轴点定义：两边 MAP 的轴点取值或轴形态（是否共享 COM_AXIS）不同，值一一对上了、插出来的结果却对不上——这与「漏改车型专属差异项」是两码事，前者是规格层的坑（见 K6-10）
相关课题