K6-05 标定数据管理与版本控制

课程代码 K6-05 · 板块 K 控制、软件与标定 / 标定与匹配 时长 约 3.5 小时（7 讲） 前置 K6-01 热管理标定流程与工具；K4-04 软件版本、配置与变量管理 本讲义定位 讲师授课蓝本 / 学员自学讲义，是 K6-05 大纲的完整展开版

---

引言：合版那天要回答的，是「有没有标红」，还是「这两条分支到底动了什么」

前面几门课交出的是标定成果——一组一组标好的值。这门课接手的是它之后的那个问题：这些值怎么被管成一份能审计、能复现的资产。它听上去是流程课，但它真正难的地方不在流程图，而在一个很少被显式问出来的选择：你管住的最小单元，到底是一份文件，还是一个个能被点名的标定量。这个选择做错了，后面六讲讲的机制——版本号语义、基线与标定变体分支、责任矩阵、授权分级、变更记录、合版冲突检测——会同时退化成看起来在做、实际什么也没管住的形态，而且退化的过程不报任何错。

典型的现场是合版那一天。两条并行的标定分支要合到主线上，评审的做法是打开差异比对报告，看有没有标红的冲突项，没有就签字合并——一句「diff 跑过了，没有冲突，可以合」。这门课要说清的是：这句话在什么条件下成立，以及它不成立的时候，你手上那份干净的报告长什么样。答案不太舒服：它长得和成立的时候一模一样。

第一根钉子（全课下文一律简称「钉子 A」）：标定数据管理的最小单元是「标定量」，不是「文件」。本课要交付的六件事——库侧标定版本号的语义、基线与标定变体分支、责任矩阵、授权分级、变更记录、合版冲突检测——每一件只有落到标定量这一粒度才成立。停在文件级时，六件事会一起变形：文件级差异比对对一次合版只会报「这个 Hex 整个变了」，而一个 Hex 里的量分属好几个功能，人从字节与地址里读不出是哪个量动了（本课案例里那个被两条分支各自改过、彼此互不知情的电池冷却启停阈值，就是这样漏过去的）；文件级责任矩阵写得出「这个标定文件归某人」，却写不出「这个阈值谁能改」；文件级变更记录写「更新了一版标定」，半年后要复现当时的判断，等于没写。⇒ 全课第一条可执行动作：拿到任何一套标定数据管理方案，先看它的差异输出里印的是标定量的名字，还是文件的名字——印的是文件名，那么本课后面讲的机制在这套方案上一条都落不了地，⛔ 不要先去优化流程，先换粒度。这根钉子把七讲串成同一件事的七层：第 1 讲说明为什么资产清单要按「这组值能不能被重建、解读、追责、复用」建轴，而不是按文件列举；第 2 讲说明合版冲突为什么必须在标定量级检测；第 3 讲说明责任矩阵的行是标定量不是文件；第 4 讲说明对外裁剪版是逐量判「发还是不发」；第 5 讲说明变更覆盖率的分母是标定量个数；第 6 讲说明这正是标定数据管理系统区别于文件级配置管理工具的定义性能力；第 7 讲说明几类最贵的事故有一个共同根因，就是粒度停在文件级。

第二根钉子（简称「钉子 B」）：标定数据的版本管理是一条必须闭合的环——库 → 车/台架 → 库。本课最贵的几类事故看起来各不相同：台架上改完没有并回标定库、售后现场微调没有回写主线导致下一批车「退步」、平台复用把值搬走却没搬走它的工况包络。它们其实是同一个形态：标定值有一条出库路径，而那条路径没有配对的回来的路径。所以本课不把「出库」当成一件事，而当成一个要先画全的集合来处理——台架在线调试、产线写入、售后现场微调、跨车型复用搬值，四条路径各自单独定四件事：出库要不要授权、出库留什么痕、什么条件下必须回写主线、不回写主线的后果由谁承担。最后一件是四件里最容易被跳过、也最能暴露问题的一件：台架那条路径的代价当场落在自己头上（不导出、不入库，下电即失，人马上就知道），而售后那条路径的代价落在几个月后另一批车上——没有任何一个当事人有动机去闭合它，所以它只能靠机制，不能靠自觉。⇒ 第二条可执行动作：把手上这套流程的出库路径逐条列出来，凡是找不到配对回写主线判据的那一条，就是下一次「主线退步」的发生地。

⚠ 这根钉子带着一处必须先说清的写法约定。本课说的「回写主线」是库侧动作——把现场改动并回标定库；它与 K6-10 标定量规格定义：轴点、插值/外插保护、上下限与不可标量／K6-01 热管理标定流程与工具（INCA/CANape） 讲的「写回 Flash」（控制器里 RAM 标定页的值写回 Flash 页，车侧动作）是两件方向相反的事。两边原文都出现过单写两个字的形态，读者代错一次，就会去查一个根本不存在的问题。⇒ 全课禁止裸写「回写」二字，一律写全「回写主线」或「写回 Flash」。本课还有另外三对同名不同事的说法在体系内并流——基线与基准、软件变型与标定变体、四套不同语义的版本号——第 1 讲会把四对逐个钉死，正文此后一律按钉死的写法用词。

★ 最后立一条反钉子，它是本课最容易被读反的地方。本课案例给出的结论是：那次两条分支各改了同一个电池冷却启停阈值，用差异比对工具揪出了冲突项。这句话成立，但它成立有一个前提——两条分支动的是同一个标定量。读者最容易顺势滑到的下一步是：既然比对能揪出冲突，那么比对干净就说明可以合。

读者会做错的第一个具体动作：把合版评审做成「打开差异报告，看有没有标红的冲突项，没有就签字合并」。为什么这是读反：差异比对对合版冲突是必要不充分的。本课把合版冲突画成一个全集，得到四类，而只有第一类会在比对报告上显形——① 同量冲突（两条分支改同一个量），报红，就是案例里那一类；② 耦合冲突，两条分支改的是不同的量，但两个量在同一条控制链上（一条抬了冷却启停阈值、另一条压低了水泵最低转速），逐量比对两侧各自都干净、合并后也不报任何冲突，而合起来的行为已经变了；③ 轴与结构冲突，值一一对上而轴点取值或轴形态不同，插出来的结果对不上；④ 缺项冲突，一条分支新增了标定量、另一条没有，工具把它报成「新增」而不是「冲突」，合并后另一侧的那个功能拿到的是默认值。⇒ 后三类不是「比对漏报了几条」，而是它们整类不在比对的视野里：漏掉的那一类不以「少了一条」的形式暴露，所以那份报告看起来是完整的。⛔ 这条不能被读成「比对没用」——比对是必查项，只是它回答的是「我列出的这些量有没有变」，不是「有没有问题」。正确动作方向相反：合版评审的输入不是差异报告，而是「两条分支各自动过哪些功能」——先各自列出这一轮动过的功能，按功能反查它牵动的标定量清单（含耦合量与共享轴的连带表），把这份清单当作必查项，再回头看比对报告，让它退回「核对这份清单有没有漏」的角色。⚠ 顺带一条方向相同的自检：比对干净时更要问一句「这两条分支这一轮到底改了什么」；如果答不上来，那不是「没冲突」，是「没人知道改了什么」。

第二个形态，同样是读反，代价更隐蔽：「冻结」被读成「冻结之后就不会再变了」。它会导出两个方向都错的动作：① 冻结之后就不再维护回写主线的通道——而生命周期在冻结之后还有量产、售后微调、回写主线、退役四段（七段的划分见 1.7），现场的每一次微调都在生成一条没有归宿的分支，于是下一个量产批次编译出来的还是冻结那一版，把已经在现场修掉的问题原样带回来；这不是有人偷懒，是冻结被当成了终点，于是没有人去建那条回来的路。② 把「冻结」当成一个日历日期去承诺——冻结的正确形态是一组前置条件全部成立（各子系统标定已过各自的验证、验证矩阵的覆盖点齐、本轮变更的记录追溯完整、未决的变更申请已全部处置）；写成日期，到了那天条件没齐也照样宣布冻结，此后所有引用「已冻结基线」的判断——平台复用、放行签署、对外发放——全部建立在一个不成立的前提上，而且没有任何一步会重新检查它。⇒ 正确动作：冻结的是「这一份基线」这个客体，不是「这个车型的标定」这件事；冻结的同时必须一并定下「冻结之后允许谁在什么条件下改、改了怎么回来」，这两件是同一个动作的两半，⛔ 不许只做前一半。★ 两个形态与主反钉子同源：都是把一个只在特定条件下成立的结论，当成了无条件成立的结论。

还有一条贯穿全课的作业方式要先说明。本课凡是要「列一张表」的地方——一份标定资产由哪些件构成、标定值离开库有哪几条路径、合版冲突有哪几类、一条变更记录必须回答哪些问题、配置项清单一共有几张、事故有哪几种模式——都先把全集画出来，再逐项核本课的射程，而不是顺着最熟悉的那条线索往下数。原因很实际：沿单一线索枚举时，漏掉的那一类不会以「少了一条」的形式暴露，它是整类不出现，清单看起来仍然完整。上面反钉子里那三类看不见的冲突，就是这么漏的。⚠ 这六个全集的分类轴、以及由它们得出的几条结论（资产按四问分四类、配置项清单是四张不是三张、生命周期第七段「退役」、合版冲突四类划分与「比对干净是必要不充分条件」、出库四条路径、事故分执行断口型与机制缺口型两类），都是本课归纳的组织方式，⛔ 不是本课程体系大纲、也不是任何标准里既有的分类；正文每次用到都会再标一次，其中哪一部分来自大纲原文、哪一部分是本课加的，也会分开写明。

最后把边界划清。本课站在软件配置管理、标定执行与合规准入的中间，上下游都有属主课；不在开篇把边界写死，这门课要么与它们重叠，要么整段落空。⚠ 下面这份交付面是按下游各课在自己的边界句里对本课的声明反推出来的，⛔ 不是大纲已规定的。

本课交付八件：① 标定资产的构成与四张配置项清单的对齐；② 库侧标定版本号的语义、基线与标定变体分支；③ 标定量级的合版冲突检测与四类冲突的识别动作；④ 标定量责任矩阵（内部版与跨企业版两张）；⑤ 对外裁剪版与内部全量之间的版本对应关系，以及现场授权分级（授权对象、档位、有效期、撤销与留痕）；⑥ 变更评审通道与变更记录的最小信息集，含规则型标定量按需求—场景矩阵反查的做法；⑦ 回写主线的触发判据与四条出库路径的闭环；⑧ 标定数据管理系统的定义性能力与三类工具的分工。

本课不交八件，一律给去向：车端自产数据（学习值、零点补偿、诊断计数与累计量）与非易失存储的布局迁移归 K4-06 控制器非易失存储设计：学习值、诊断数据与累计量的持久化；产线与售后的执行面（工位项、写入通道、按车辆识别码追溯、售后重学清单）归 K6-09 产线下线与售后标定：工位项清单、配置写入与学习值管理；每个标定量自己的规格（轴点、插值与超界保护、上下限与默认值、可标性等级）归 K6-10 标定量规格定义：轴点、插值/外插保护、上下限与不可标量；A2L 的对象模型与在线标定通路归 K6-01 热管理标定流程与工具（INCA/CANape）；软件配置管理与发布件构成归 K4-04 软件版本、配置与变量管理；一次标定变更触发哪一档回归、回归范围怎么裁剪与执行归 K4-08 控制软件回归验证：基线与激励库、回归范围裁剪、自动执行与失败分诊；跨企业的裁剪判据与访问权限的分发归 K4-09 热管理控制软件的跨企业交付边界：交付物形态、DIA/SEooC、权限分级与联合验证签署；软件升级的车端实施与合规准入归 K7-02 软件定义热管理与 OTA 迭代 与 M4-08 车用软件更新的准入与合规（R155/R156·GB 44495/44496·OTA 备案与召回）。⚠ 边界不是一串「本课不讲」的否定句：上面每一条都写明了去向，读者要往下走时按去向跳课，⛔ 不要在本课里等一个不会来的展开。

七讲是同一件事的七层。第 1 讲把词与边界钉死——四对同名不同事的说法、本课管的是出厂前的离线标定参数集（判据是「谁写的这个值」而不是「它存在哪」）、一份资产按四问分四类、配置项清单是四张、生命周期七段、软件版本与库侧标定版本的耦合是一个要显式声明的设计决定、冻结对齐的是一组前置条件。第 2 讲讲版本号语义与分支：三段式命名法是一种常见做法而不是任何标准规定的语义，版本号相等不等于同一套标定，基线与标定变体是两个不同的轴，软件变型与标定变体是两个正交维度，受控发布件与参考件的版本规则方向相反，合版冲突四类与评审的正确输入。第 3 讲讲归属：责任矩阵为什么必须提前划、划归属的维度要先选定并写明理由、内部版与跨企业版两张表、「名义上不给改、技术上改得动」怎么查，以及这张表自己也要有属主与版本。第 4 讲讲出库与回写主线：四条路径各自的授权、留痕、回写主线判据与后果承担者，哪一类现场微调必须回写主线、哪一类属一车一档（一车一档同样要留痕），台架临时调试与正式入库的边界，跨车型搬值这条「没有人修改任何值」的路径，对外裁剪版要记的那一格版本账。第 5 讲讲变更与追溯：申请—评审—实施—发布四步各有一道可判真假的闸，安全相关标定量的额外通道由规格属性驱动而不是由填表人选择，变更记录的最小信息集是下界不是全集，规则型标定量改一条时回归范围不能按标定量个数估，以及变更覆盖率与追溯完整率两个比值各自能用来干什么、不能用来干什么。第 6 讲讲工具：标定数据管理系统区别于文件级配置管理的定义性能力只有一条，通用版本控制工具能承担哪一段、不能承担哪一段，三类工具怎么分工与互引版本号，自动化差异比对要成立的三个前提（前提不成立时它的输出是错的而不是空的），以及工具链本身的版本也是配置项。第 7 讲收口：事故分执行断口型与机制缺口型两类，预防动作方向完全不同——前者靠闸门与默认动作，后者只能靠补机制，培训、提醒与「加强意识」对第二类完全无效，因为没有人做错任何一件被要求过的事；随后把常见事故逐条归到「缺的是哪一条机制、落在哪一讲」，并给出三个可观测量用来判这套机制是不是活着。

⚠ 最后交代本课在数字上的写法，免得读者到处找数却找不到：本课是治理类课题，它的量几乎全部由本项目的组织形态、排产节奏与风险偏好决定——标定量总数、变更覆盖率的评审分界值、追溯完整率的目标值、冻结点相对量产节点的提前量、授权有效期、回写主线的时限——这些量本课一律不给数，正文写的是「须由本项目按自己的统计确定」，⛔ 也不得抄上一代平台。这不是回避：给出一个没有来源的数，读者会把它当成可取用的参考值，而本课根本没有核过那个数。全课通篇不出现企业名与车型名，案例一律用「某纯电 SUV 平台的两个衍生车型」这类脱敏表述——⚠ 只有一处例外：工具的产品名可以写（第 6 讲那一批），因为那是公开的产品类目，⛔ 但仍不写它们的版本号、功能参数与性能指标；出现的标定量名只作类型举例，⛔ 不给它的取值与轴点。

第 1 讲　先钉住说法与边界：标定数据是一份资产，不是几个文件

这一讲不讲流程，讲的是流程要作用在什么东西上。本课后面六讲要交付的六件事——版本号语义、基线与标定变体分支、责任矩阵、授权分级、变更记录、合版冲突检测——每一件都只有落到标定量这一粒度才成立；而在动手设计任何一件之前，还有四件事必须先定下来：本课说的每个词到底指什么、本课管的是哪一份数据、这份数据由哪些件构成、它从生下来到退出要走过哪几段。这一讲把这四件事逐个钉死，后面六讲都建在它上面。

1.1 动笔之前先钉住四对会撞名的说法

本课有四对同名不同事的说法在课程体系内并流。读者代错任何一对，后面六讲对他都是错的。全课统一写法如下，正文一律不写歧义形式。

第一对：回写主线 vs 写回 Flash。本课说的「回写主线」是库侧动作——把现场已经发生的改动并回标定库；K6-10 标定量规格定义：轴点、插值/外插保护、上下限与不可标量 与 K6-01 热管理标定流程与工具（INCA/CANape） 说的「写回 Flash」是车侧动作——控制器里 RAM 标定页上的值固化到 Flash 页。两者方向相反：一个把值往库里送，一个把值往车里固化。⛔ 全课不许把前者简写成两个字，每次出现都带全称。为什么值得为两个字立一条规矩：读者若把「这一类改动必须回写主线」代成「必须写回 Flash」，他会跑到控制器那一侧去查一个根本不存在的问题，而库里那条真正断掉的路径没有人管——本课最贵的几类事故正发生在那条路径上。

第二对：基线 vs 基准。本课的「基线（baseline）」是一组标定值在某个时点的冻结快照，属受控发布件：冻结之后不可迭代、按车型追溯、随车型退役。Q3-04 热管理数值型基准库治理：口径标注、跨源置信排序、退役与入库门槛 说的「基准」是跨车型可复用的性能参考值，属参考件：可迭代、按口径与置信度管理。两者的版本管理机制方向相反，而中文里这两个词长得太像 ⇒ 全课要求它们成对出现时各带限定词。混用的两种后果都是实的：把参考件当发布件锁死，本该随数据积累更新的参考值被冻在某一版；把发布件当参考值跨车型照抄，一组只在某个车型上验证过的值被原样搬进另一条分支，而它凭什么成立没有跟着搬。

第三对：标定变体 vs 软件变型。K4-04 软件版本、配置与变量管理 的「变型」指软件侧的特性组合（有没有热泵、几通阀）；本课与 K6-09 产线下线与售后标定：工位项清单、配置写入与学习值管理 的「变体 variant」指标定分支与变体配置字。本课统一写「标定变体」，并在这里点明一次：标定变体与软件变型是两个正交的维度——同一个软件变型下可以挂多个标定变体，同一个标定变体也可能跨若干软件变型。⛔ 引用 K4-04 软件版本、配置与变量管理 原文时不得让读者以为两者是同一个维度。

第四对：版本号。本课默认说的「版本号」是库侧标定版本。课程体系内另有三套语义：软件版本（K4-04 软件版本、配置与变量管理）、送检状态版本（M4-06 热管理强检项的认证与送检执行实务：准入链时序、送检状态冻结、检测机构与失败返工）、对外申报绑定的软件标识（M4-08 车用软件更新的准入与合规（R155/R156·GB 44495/44496·OTA 备案与召回））。四套各管各的事。⛔ 写法约定分两档，不是「一律加词」：① 凡指其它三套语义之一时，必须带限定词——写「软件版本」「送检状态版本」「对外申报绑定的软件标识」，⛔ 不许只写「版本号」；② 本课默认那一套（库侧标定版本）在每一讲首次出现处、以及与另外三套并列比较处带限定词，其余处按本节钉死的默认口径读。⚠ 为什么不定成「一律带限定词」：正文里大量出现的是「版本号语义」「版本号段数」「三段式版本号」这类泛指「版本号」这件事的用法，给它们加上「库侧标定」反而把话说错了——这条约定要挡的是四套语义互相顶替，⛔ 不是消灭这三个字。

另有三个不撞名、但极容易丢下标的量，在这里一并定义，全课禁止裸写 N：N_total＝本项目标定量总数（个），是后面变更覆盖率与追溯完整率的公用分母；N_changed＝本次变更涉及的标定量个数（个）；N_traceable＝有完整变更记录的标定量个数（个）。三个量一律以标定量个数计，⛔ 不按文件数——这是本课第一根钉子在算术上的形态。⚠ N_total 是平台相关量：它取决于功能范围与软件设计（一个量是不是被做成可标定对象，是软件设计阶段的决定，见 K6-01 热管理标定流程与工具（INCA/CANape） 与 K6-10 标定量规格定义：轴点、插值/外插保护、上下限与不可标量），须按本项目 A2L 实际统计 ⇒ 本课不给这个数，也不给任何由它派生的量级说法。

三个易错点：① 写到现场微调那一讲时顺手把「回写主线」简写掉；② 引用 K4-04 软件版本、配置与变量管理 原文时把它的「变型」直接抄进本课语境；③ 把 N_total 写成 N，而同一段里另一个 N 指的是变更条数。

1.2 管辖判据是「谁写的这个值」，不是「它存在哪」

本课的管辖对象是出厂前的离线标定参数集：描述文件 A2L、二进制映像 Hex、参数值文件 DCM。判据是一条二问：

① 这个值是人在库侧定下来、随发布件下发的吗？是 ⇒ 离线标定参数集，本课射程之内。 ② 这个值是控制器自己在运行中算出来、并要活过下一次上电的吗（学习值、零点补偿、诊断故障码的老化计数与冻结帧、运行小时与累计量）？是 ⇒ 车端自产数据，归 K4-06 控制器非易失存储设计：学习值、诊断数据与累计量的持久化，本课一条不重讲。

⚠ 判据必须落在谁写的这一侧，不能落在存在哪这一侧：两类值完全可以躺在同一块非易失存储器里，沿「它存在哪」这条线索去分，必然把两类混成一类。

为什么这条边界要在第 1 讲就划：两类数据的版本管理机制不共用任何一条。离线参数集有版本号、有分支、有合并、有评审，一份可以下发给整批车；车端自产值一车一份、没有版本号可言，它的「版本」问题是数据块布局的跨版本迁移，那是 K4-06 控制器非易失存储设计：学习值、诊断数据与累计量的持久化 的题目。把两者混在一张表里管，直接后果是「标定版本」这个词在同一份文件里指两件事，追溯链就断在这一格上。

三个易错点：① 把产线写入的变体配置字当成本课的标定量——它由工位写、按车辆识别码追溯，执行面归 K6-09 产线下线与售后标定：工位项清单、配置写入与学习值管理，本课只管它的合法值域来自哪一个发布件；② 认为「都在控制器里、都要管版本，所以是一件事」——那正是相邻几张配置项清单互相踢皮球的起点（见 1.6）；③ 反过来把边界写成「本课不管非易失存储器」——那是按载体划界，会漏掉存放位置在 Flash 标定段之外的离线参数。

1.3 本课交出去的八件，与一律只给去向的八件

本课在课程体系里是一个被大量引用的枢纽，边界不写清就必然与邻课重叠或落空。本课交出去的八件：

① 标定资产的构成，以及与四张配置项清单的对齐；② 库侧标定版本号语义、基线与标定变体分支；③ 标定量级的合版冲突检测与四类冲突判据；④ 标定量责任矩阵（内部版与跨企业版两张）；⑤ 对外裁剪版与内部全量之间的版本对应关系，以及现场授权分级（授权工具、人员分级、有效期、撤销与留痕）；⑥ 变更评审通道与变更记录的最小信息集，含规则型标定量的需求—场景矩阵反查法；⑦ 回写主线的触发判据，与四条出库路径的闭环；⑧ 标定数据管理系统区别于文件级配置管理的定义性能力，以及三类工具的分工。

本课不交、只给去向的八件：车端自产数据与非易失存储数据块布局的跨版本迁移 ⇒ K4-06 控制器非易失存储设计：学习值、诊断数据与累计量的持久化；产线与售后标定的执行面（工位项清单、写入通道、按车辆识别码追溯、售后重学清单）⇒ K6-09 产线下线与售后标定：工位项清单、配置写入与学习值管理；每个标定量自己的规格（轴点、插值与超界保护、上下限与默认值、可标性等级）⇒ K6-10 标定量规格定义：轴点、插值/外插保护、上下限与不可标量；A2L 对象模型与在线标定通路 ⇒ K6-01 热管理标定流程与工具（INCA/CANape）；软件配置管理与发布件构成 ⇒ K4-04 软件版本、配置与变量管理；标定变更引发的回归范围裁剪与执行 ⇒ K4-08 控制软件回归验证：基线与激励库、回归范围裁剪、自动执行与失败分诊；跨企业裁剪判据与访问权限分发 ⇒ K4-09 热管理控制软件的跨企业交付边界：交付物形态、DIA/SEooC、权限分级与联合验证签署；软件升级的车端实施与合规准入 ⇒ K7-02 软件定义热管理与 OTA 迭代 与 M4-08 车用软件更新的准入与合规（R155/R156·GB 44495/44496·OTA 备案与召回）。

⚠ 这份交付面是本课按下游课程各自的声明反推出来的，⛔ 不是上游给定的既有划分——所以它在小结那一节还要再声明一次，那一次答的是「这件事不归本课，你该去哪门课」。

顺带把本课的三条自我约束摆在这里，读者读全课时可以拿它当验收：① 案例一律脱敏，用「某纯电 SUV 平台的两个衍生车型」这类表述，⛔ 不写企业名、供应商名与车型名——⚠ 只有一处例外：工具的产品名可以写（第 6 讲那一批），因为那是公开的产品类目，⛔ 但仍不写它们的版本号、功能参数与性能指标；② 讲义里出现的任何标定量名（例如「电池冷却启停阈值」）只作类型举例，⛔ 不给它的取值与轴点；③ 凡本课判为平台相关的量，正文、图、图注一律不给数，包括图上的刻度值与门槛线位置。⚠ 第三条不是谦虚：本课是治理类课题，说服力来自判据而不是数字，而一旦写出一个具体阈值，读者就会把它当成可取用的参考值——本课根本没有核过那个数。

1.4 A2L 给结构与地址，Hex/DCM 给值——库里管的是这一对

一套标定数据其实是两件互相依存的东西：A2L 描述有哪些标定量、每个量是什么类型、在内存的哪个位置、原始值怎么换算成物理值；Hex/DCM 只承载这些位置上放的数。⇒ 库里管一份标定资产，管的是这一对，⛔ 不是其中任何一件。

这一层是本课全部机制的物理前提。只有 A2L 在，差异比对才能把两个 Hex 的字节差翻译成「哪一个标定量变了」——这就是本课第一根钉子的技术根据：粒度不是流程偏好，是有没有那份描述文件。反过来，A2L 与软件不同源时，工具要么连不上，要么把地址解释错，读出一堆看起来完全合理的值而不报任何错——正因为这种失效不会报错，1.5 才要把「产生这组值的那一版软件的标识与发布件指纹」列进资产清单。

来源要说清：A2L 的标准是 ASAM MCD-2 MC（ASAP2）。本课只用「结构与地址 vs 值、两者必须同源同版本」这一层结论，⛔ 不引条款号、⛔ 不写版次；对象语义与版次须按现行 ASAM 目录核。对象模型本身归 K6-01 热管理标定流程与工具（INCA/CANape），每个量的规格怎么写归 K6-10 标定量规格定义：轴点、插值/外插保护、上下限与不可标量，本课到「认得出这一对必须同源」为止。

两个易错点：① 把 DCM 当成「文本版的 Hex」而以为两者可以互换——A2L、DCM 与 CDF/CDFX 是文本，Hex 是刷进控制器的二进制映像（常见记录格式名为 Intel HEX 与 Motorola S-record，本课只用格式名与「文本还是二进制」这一条属性，⛔ 不写任何格式细节，也⛔ 不把它读成一份封闭清单）。文本能被逐量比对、二进制不能，这个差别决定了后面工具选型的一半结论；② 在本课展开可标定对象的类型枚举与轴形态——那是 K6-01 热管理标定流程与工具（INCA/CANape） 的射程。

1.5 一份标定数据资产由四类件构成，判据是「缺了它，这组值还能不能被用」

一份「标定数据资产」不是三个文件。判据是四问：缺了它，这组值能不能被重建 / 解读 / 追责 / 复用？四问对应四类件：

① 不能被重建的——产生这组值的那一版软件的版本标识与发布件指纹（校验和），加上与之同源的 A2L。② 不能被解读的——A2L 里的结构、地址与换算口径，以及轴点定义（值一样、轴不同就不是同一件事）。③ 不能被追责的——变更记录、评审记录、授权与发放留痕。④ 不能被复用的——验证证据与它的工况包络（在哪些工况点上验过、证据存在哪）。四类齐了，这组值才是「资产」；缺任一类，它降级成「一组数」。⚠ 这里再钉死一处写法：全课一律写「工况包络」，⛔ 不写「验证包络」——两者指的是同一件东西，而它与 K6-01 热管理标定流程与工具（INCA/CANape） 三件套里的那个词也是同一个，⛔ 不许在本课里出现两个名字。

⚠ 这条判据的价值在于它不靠列举：换一个工具链、换一种文件格式，四问照旧成立，而按文件名列举的清单换一次工具就得重写。

沿「我能从系统里下载到的文件」往下数会漏掉什么：这条线索数到 A2L + Hex + DCM 三件就停了，而它漏掉的不是少了一条，是整整四类：（a）软件版本标识与发布件指纹——它本身不是标定文件，但没有它，「A2L 与 Hex 同源」这句话无从证明，而不同源的表现不是报错，是读出一堆看似合理的值；（b）变更记录与评审记录本身——它常被当成流程的副产品扔在工单系统里，而追溯完整率这个量就定义在它上面；（c）验证证据与它的工况包络——它决定这组值能不能被另一个车型引用，是跨车型复用这条路径唯一的把关依据；（d）对外裁剪版 A2L 及其与内部全量的对应关系——它不是内部全量的一份副本，而是一件独立资产：有自己的发放对象、有效期与撤销条件，且「发出去的那一版是从哪个基线裁的」是本课必须记账的一格（裁剪判据本体归 K4-09 热管理控制软件的跨企业交付边界：交付物形态、DIA/SEooC、权限分级与联合验证签署）。

⚠ 这套「四问四类」是本课自建的组织方式，⛔ 不是任何外部标准既有的分类，引用时请照此标注。它与 K6-01 热管理标定流程与工具（INCA/CANape） 的「三件套」（软件版本 + 同源 A2L + 工况包络）是同一件事的两侧：那边说的是「拿到一组值的人怎么判它能不能用」，本课说的是「库要存哪些东西，才让那三问答得出来」；本课在它之上多出第③类追责，因为库侧要回答的是「半年后谁能说清这个值当初为什么是这个数」。

三个易错点：① 把变更记录当成流程的副产品留在工单系统里、不入库——那么追溯完整率根本无从计算；② 把对外裁剪版 A2L 当成内部全量的一份副本、不单独记版本——出问题时「外面那份是从哪个基线裁的」答不出来；③ 把车端自产数据也塞进这份清单（见 1.2 的判据）。

1.6 与本课相邻的配置项清单是四张，不是三张

围绕一台控制器，配置项清单一共四张，各自的主语不同：软件（K4-04 软件版本、配置与变量管理）管代码、模型、需求、测试证据与工具链版本；标定数据（本课）管 A2L / Hex / DCM 与它们的变更与验证证据；CAE 仿真资产（J7-07 仿真任务的输入、交付与模型资产管理）管仿真模型、算例、网格与求解设置、物性与部件特性表、后处理脚本；车端自产数据（K4-06 控制器非易失存储设计：学习值、诊断数据与累计量的持久化）管学习值、零点补偿、诊断故障码状态与冻结帧、累计量。

四张之间要做的是逐行对齐：每一行只能落在一张表里（不重叠），且不许有哪一类产物四张表都不认领（不留空档）。三处接界各要交代一件事：软件↔标定＝两侧版本号如何互相引用；标定↔CAE＝被两库共同引用的数值型基准归哪一侧（治理口径见 Q3-04 热管理数值型基准库治理：口径标注、跨源置信排序、退役与入库门槛）；标定↔车端＝基线换代时车上那一份要不要迁移、要不要清除重学。

沿「软件 / 标定 / CAE 三方分工」这条线索往下数，只会数出三张——漏掉的那一整张是车端自产数据。它不在那条线索上，因为它由控制器自己写、活在非易失存储器里，没有人把它当成「某个团队产出的配置项」。而它与本课有一条真实的接界：K4-04 软件版本、配置与变量管理 已把「发布件必须声明它对上一版本车端数据布局的兼容关系」写成硬要求，而三张表的框架里没有一格装这条声明。⚠ 「是四张不是三张」是本课的归纳，⛔ 不得写成 K4-04 软件版本、配置与变量管理 已有；第四张的本体仍归 K4-06 控制器非易失存储设计：学习值、诊断数据与累计量的持久化，本课只是把它列进对齐表，不重讲非易失存储那一层。

三个易错点：① 把 CAE 侧的物性与部件特性表当成标定数据（它们的治理归 Q3-04 热管理数值型基准库治理：口径标注、跨源置信排序、退役与入库门槛，本课只是引用方之一）；② 以为「不重叠」就够了——空档比重叠更危险：重叠会在评审时吵起来，空档没有人会提；③ 把第四张写成「本课也管非易失存储」。

1.7 一个标定版本的生命周期是七段，不是六段

课程体系原有的口径把生命周期写到「回写主线」为止：草稿 → 评审 → 冻结 → 量产 → 售后微调 → 回写主线。本课在它后面补上第七段：退役。⚠ 这一段是本课归纳补上的，⛔ 不得写成上游既有。

每一段都要写清三件事：进入这一段的前置条件、这一段里谁有权改、离开这一段留下什么记录。第七段「退役」要回答的是：车型退市之后这套标定基线怎么处置——还要不要留、留多久、留给谁、之后有人来查售后件时按哪一版答。

为什么非补不可：前六段是一条向前的链，读者容易把它读成「走完就结束」；而标定基线在车型退市之后仍然要为在保车辆与售后件负责，它的存续期比车型的销售期长。⚠ 这里正好用得上 1.1 那对术语：Q3-04 热管理数值型基准库治理：口径标注、跨源置信排序、退役与入库门槛 确实写了「退役规则」，但它管的是跨车型性能基准库（参考件）的退役，判据是「换代零件的老数据什么时候不能再引用」；本课这一段管的是一套受控发布件在车型退市后怎么处置——两者不是同一件事，把它们当成一件，就会拿参考件的退役判据去处理一份还要给在保车辆兜底的基线。

三个易错点：① 把「冻结」当成生命周期的终点（下一节专讲）；② 把退役理解成「删掉」——退役的正确形态是打作废标记并写明被谁取代，删掉会让在保车辆的追溯链断掉；③ 把七段读成一条只能向前的链——第五段与第六段之间实际上是一个回路，那正是本课第二根钉子：标定值有一条出库路径，就必须有配对的回写主线路径。

⛔ 各段的时长、冻结相对量产启动节点的提前量、退役后基线的保存年限，全部取决于本项目的节点表与所在市场的法规要求，本课一个数都不给，须由本项目确定，⛔ 也不许照抄上一代平台。

1.8 冻结对齐的是一组前置条件，不是一个日历日期

「冻结」这两个字最容易被读成两件错事，两件都会直接导出错误动作。

读法一：冻结之后就不会再变了。——上一节的七段图已经反驳了它：冻结之后还有量产、售后微调、回写主线、退役四段。若按这个读法办事，冻结之后就没有人再去维护那条回写主线的通道，于是现场的每一次微调都在生成一条没有归宿的分支；下一个量产批次编译出来的还是冻结那一版，把已经在现场修掉的问题原样带回来。⚠ 这类「后续版本退步」不是有人偷懒，是冻结被当成了终点、于是没有人去建那条回来的路。⇒ 正确动作：冻结的是「这一份基线」这个客体，不是「这个车型的标定」这件事；冻结的同时必须一并定下冻结之后允许谁在什么条件下改、改了怎么回来——这两件事是同一个动作的两半，⛔ 不许只做前一半。

读法二：冻结是一个可以在日历上承诺的日期。——冻结的正确形态是一组前置条件全部成立，至少四类：① 各子系统标定已过各自的验证（判据归 K6-02 空调与制冷系统标定 与 K6-03 电池热管理标定，本课不重讲）；② 验证矩阵的覆盖点齐（这一层的收口与放行归 K6-04 环境舱与整车热平衡标定）；③ 本轮全部变更的记录追溯完整（判据见第 5 讲）；④ 未决的变更申请已全部处置——批准、驳回，或明确推迟到下一基线，⛔ 不许留在「审批中」状态跨过冻结点。⇒ 与整车节点对齐的正确做法是倒排出这四类条件各自的完成点，⛔ 不是在日历上标一个「标定冻结日」。写成日期的代价是：到了那天条件没齐也照样宣布冻结，而后面所有引用「已冻结基线」的判断——平台复用、放行签署、对外发布——全部建立在一个不成立的前提上，而且没有任何一步会回头重新检查它。

⚠ 再分清一对容易混的动作：冻结是库侧动作（这一份基线不再接受普通变更），放行是项目动作（整车级验收与签署，归 K6-04 环境舱与整车热平衡标定），两者的前置条件与签署人都不同。⛔ 冻结点相对量产启动节点的提前量取决于本项目的节点表与验证矩阵规模，本课不给数，也⛔ 不许抄上一代平台。

1.9 软件版本与标定版本耦合到多紧，是一个设计决定

很多项目从来没有决定过这件事，它是被工具的默认行为决定的。本课要求把「耦合」拆成两个各自可判的问题，并显式声明两个答案：

① 版本号层面——库侧标定版本是不是软件版本号里的一段？（分段写法与语义见第 2 讲。） ② 发布层面——改一个标定量要不要重新走一次完整的软件发布？

两个问题的答案可以不同：版本号上耦合、发布流程上解耦，是常见且合理的一种组合。

两个方向的代价都是实的。耦合过紧：标定工程师微调一个参数却要走完整的代码发布流程，于是人会绕开流程——「台架上临时改一下没保存回库」这类事故有相当一部分是被这条逼出来的，它的根在流程成本，不在人的自觉。耦合过松：版本标识回不到车上，车上读得回软件版本、读不回标定版本，售后拿到一台车说不出它的标定是哪一版。

⇒ 所以判据不是「松还是紧」，而是这一条：车上读回来的那组标识，能不能唯一确定库里的一份基线。⚠ 这一层的实现（标识类诊断数据标识符与刷写文件版本块的一致性比对）归 K4-04 软件版本、配置与变量管理，本课只用它的结论；本课未独立核对相关诊断标准的原文，具体标识符分配以本项目诊断规范为准，引用前须核原文。

⛔ 本项目选哪种耦合方式、库侧标定版本占版本号的哪一段，是平台相关的决定，须由本项目软件与标定两侧共同确定，本课不给推荐取法。

两个易错点：① 把「解耦」理解成「标定改了不用告诉软件侧」——解耦的是发布流程，不是追溯关系；② 认为版本号里留了一段给标定就等于闭环了——那一段能不能从车上读回来是另一件事。

本讲小结：这一讲把后面六讲要用的地基全部铺完——四对撞名说法各自钉死写法（回写主线／写回 Flash、基线／基准、标定变体／软件变型、四套版本号语义），管辖判据落在「谁写的这个值」而不是「它存在哪」，交付面八交八不交显式声明一次；再往下是三条结构性结论：一份标定资产由四类件构成（判据是能不能被重建、解读、追责、复用），相邻的配置项清单是四张不是三张，一个标定版本的生命周期是七段不是六段。最后两节各拆掉一个最容易读反的地方：冻结对齐的是一组前置条件而不是日历日期，软件与标定版本耦合到多紧是一个必须显式声明的设计决定。⇒ 记住一句话带进第 2 讲：这一讲定的是「管什么」，第 2 讲开始定「怎么编号、怎么分支」。