K7-04 车队数据回流的车端实现：信号表定义、事件抓帧与带宽/存储预算

课程代码 K7-04 · 板块 K 控制、软件与标定 / K7 智能与软件定义 时长 约 3.5 小时（6 讲 + 1 次三表联出实操） 适合对象 控制 / 软件工程师，尤其是负责车端遥测上行、T-Box 数据通道与采集配置的岗位（选修）；云端与数据平台工程师、标定与诊断工程师可只听第 1、2、4、6 讲（通道划分、信号表评审、预算闸门与合规列填写） 前置 K2-02 CAN/LIN/CAN-FD 通信与整车 EEA 集成 CAN/LIN/CAN-FD 通信与整车 EEA 集成；K7-02 软件定义热管理与 OTA 迭代 软件定义热管理与 OTA 迭代 本讲义定位 讲师授课蓝本 / 学员自学讲义，是 K7-04 大纲的完整展开版

---

引言：一张信号表的合格证只有一条——拿它能不能在纸上把结论算到底

一版热管理标定随 OTA 发了出去，云端已经攒下几十万条行程，分析师坐下来要回答的问题只有一句：这一版在冬季长行程上到底有没有省电。写到第二行就卡住了——分子（电量或能量的累计）有，分母（里程）来自另一个节点、口径与分子那一路对不上；结论里写着「冬季」，可采回来的温度是座舱进风温不是环境温，分箱分不出来；而「充电中」「维修模式」「驾驶员手动干预」这几路压根没采，充电时段的能耗混在行程能耗里，谁也剥不出来。这时候团队几乎固定会做三个动作：多投几百台车、多采一个月、把上行采样率往上调一档。三件事都要花钱、都要占带宽、都要重新过一遍预算，而对上面那三个缺口一个都不解决——它们不是「数据不够多」，是这张表当初就不是按这个问题设计的。要补，只能等下一个下发窗口重改采集配置，代价是一个车型周期。

第二个场景更贵，因为它算得出结论。云端看到灰度组的百公里能耗优于对照组，团队准备据此扩大放量；复核时结论从两个方向同时塌了：采集配置与软件包捆在同一个版本里下发，灰度车换了新配置（新增一类抓帧事件、连续层采样率下调一档），对照组仍是旧配置——两组的能耗积分本身就来自两套采样口径，口径差被读成了版本收益；与此同时，新配置下低温长行程那批样本在缓存满时被协议栈优先丢弃，而每车每日的丢帧率从来没有进过云端看板——丢掉的正是最费电的那批行程，选择性偏差伪装成了改善。⚠ 这是一个合成案例（完整决策链见「典型案例详解」），⛔ 不含任何实测数值。它值得放在开头，是因为两条根因都在车端、都发生在写第一行采集代码之前，而按这个结论放量的代价，是把一个并不存在的收益推向全量车。

本课的输入是一句待回答的问题，加上一支已经在路上、能正常通信的车队（车内报文的字段定义、缩放、周期与总线负载归 K2-02 CAN/LIN/CAN-FD 通信与整车 EEA 集成，本课不重复）。输出只有四样，前三样都是可评审、可签署、带版本号的表：信号表（采哪几路、多快、多少位、属哪一层、按哪个语义版本解释、合规怎么判）、触发条件表（哪些事件值得抓帧、前后窗多长、配额多少、超了往哪降级）、带宽/存储预算表（这套口径一天传多少、一年花多少、砍哪一项最划算、砍完永久放弃了哪个问题），外加一套让不完美可判定的元数据约定（上行序号、原始时标与校正量两列、采集配置版本、补传标记、丢弃优先级声明）。交付边界一次写死、全课不越线：车端采什么、按什么触发、上行多少、以什么语义版本入库——到「干净时序样本按声明口径产生并入库」为止。往外的每一步都有主人：云端建模、特征工程、A/B 与影子模式评估去向 K7-03 数据驱动的能效自学习控制；灰度节奏、回滚门限、样本量与显著性判据、采集配置随灰度包下发的发布工程去向 K7-02 软件定义热管理与 OTA 迭代；诊断码、冻结帧与扩展数据记录的规格去向 K5-01 OBD/UDS 诊断与故障码（DTC）设计；台架侧的多通道硬件同步、抗混叠与预触发采集去向 L7-02 数据采集、台架搭建与自动化测试；配置下发链路的签名校验、权限分级与防篡改去向 K2-04 网络安全与 OTA 安全基础；缓冲落什么介质、掉电一致性与擦写寿命去向 K4-06 控制器非易失存储设计：学习值、诊断数据与累计量的持久化；数据合规的法源、制度、出境评估流程与产业侧责任划分去向 N6-01 预测性热管理的车云数据生态与产业路径，而车队数据那笔投入产出账的收益侧去向 N6-02 整车热管理数字孪生与在线优化——本课只负责交出它的分母。⛔ 这八条边界之外，本课一律只给类型与去向，不给限值、不给等级号、不给条款内容：顺手写一句限值，读者就会拿它当验收依据用，而本课根本没有核过那个数。

钉子①：信号表的入口是「待回答的问题」，⛔ 不是「车上能采什么」。动作只有一个：先写下一句可验证的结论，再逐路反推它要用到的量——目标指标的分子一路、分母一路、结论里每一个限定词对应的分层变量、用来剔掉不该进统计的样本的排除变量；判据也只有一条——拿这张表，能不能在纸上把目标指标算到底。四类里少任何一类，结论就算不到底，而这种缺失在数据回来之后都补不上，采回多少车、多少天都补不上。这根钉子一路管到底：每一路信号、每一个触发事件、每一档保留期，都必须当场答得出「它回答哪个问题」；答不出的那一路，⛔ 不是「留着以后可能有用」，而是下一个车型周期复盘时该被下线的对象——上行字节数对信号路数与上行采样率是线性的，一路无人使用的信号会按同样线性的方式转成车队级的年支出。而单车日上行字节数 B_day 这个算式，同时还是四件事共用的分母：上行带宽、蜂窝资费、云端入库量、断连缓存深度。⇒ 由此推出本课在流程上的硬要求：预算闸门必须卡在信号表评审这一步，不是上线之后——任何新增信号或新增触发事件的申请都要附三句话：回答哪个问题 / 增量多少字节（按 B_day 算式）/ 增量多少年成本，缺一项不受理；反向也要有闸，每个车型周期复盘一次「哪些路从没被任何分析用到」并下线。⛔ 全课不给任何单价、不给任何字节数结论、不给两层占比的百分比，只给算式、拆账方法与闸门该问的那三句话。

钉子②：「采到了」不等于「能用」——回流样本的可用性由四道门决定，四道门全部在车端关，云端一道也补不回来。① 可比：工况覆盖分箱要在信号表里声明清楚，因为两组样本的边际分布相同不等于联合分布相同；② 完整：丢帧要能被统计——车端不打序号或计数器，云端就算不出丢帧率，更看不出缺口落在哪几个分箱上；③ 可对齐：时标要能被判定——车端不同时留原始时标与校正量两列，事后无法判定哪批样本的跨报文时序还能用；④ 同口径：每条样本要盖版本号——车端不带信号语义版本与采集配置版本，云端只能把两种口径的样本拼在一起算。★ 这四件事有一个共同点，也是本课最要紧的一句话：它们不提升数据质量，它们让数据质量变得可判定。车端做不到「数据一定干净」——弱网、断连、缓存溢出、配额耗尽在量产车队里都是常态；车端必须做到的是「脏在哪里、脏多少、哪一批还能用」当场说得出。

两根钉子怎么合起来：钉子①管「这些字节花得值不值」，钉子②管「回来的这批数算不算数」。⚠ 两者⛔ 不可互推——预算过了闸，不代表样本可用；样本挑不出毛病，也不代表其中任何一路答得出它回答哪个问题。开头两个场景恰好各塌一侧：第一个场景是钉子①失守（表不是按问题设计的），第二个场景的采集配置每一项都通过了评审，塌的是钉子②的第 ① 与第 ④ 两道门。

★ 有一句话是本课最容易被读反的，先在这里点破：「结论存疑就多采一段时间、多上几台车——样本量上去了，结论自然就稳了。」读者会做错的那个具体动作很好认：看到灰度组与对照组的差异不显著或可疑时，去延长采集周期、扩大投放车数、调高上行采样率，而不去核真正该核的那三件——两组的采集配置版本是不是同一个？两组的丢帧率与缺口分布是不是同一个形状？两组的工况分箱分布重不重叠？为什么它是反的：增大样本量只压得住随机误差（按 1/√n 的方式衰减），⛔ 对系统性偏差一点作用都没有——偏差是一条不随样本量变化的水平线。⇒ 样本量增大之后，总误差趋近的不是零，而是那条偏差线，而置信区间照旧随样本量收窄：一个有偏的结论会被样本量推成「高置信」，让人更笃定地做错决定。⚠ 更坏的是方向——本课要列的三个采集侧偏差源（缓存满时的丢弃、触发配额耗尽后的降级、断连在特定路况上的聚集）三者同向，优先丢掉的都是最长、最极端、最费电的那批行程 ⇒ 多采一段时间，等于把同一个方向的偏差采得更牢（第 5 讲会把这两条曲线并排画出来看）。

同族还有两层，都会被读反，一起点破。第二层：「丢帧是随机的，所以是无偏的，总丢帧率低于门槛就行。」默认的丢弃根本不随机——协议栈按队列策略丢（尾丢弃，或整块丢最旧的），断连按路况聚集（地库、山区、隧道、长途高速段），配额按事件密度耗尽（异常最多的那台车最先被降级）。⇒ 一个「总丢帧率合格」的读数本身不说明任何事，要看的是缺口落在哪些工况分箱上；只在分析准入里设一条总率门槛，会放行一批总率漂亮、而低温长行程那一格整格为空的样本。第三层是前两层的根因：「数据质量是云端的事，车端只管把数据送上去。」这条把责任推错了地方——四道门在云端根本补不回来：不打序号就算不出丢帧率，不留原始时标与校正量就判不了可对齐，不带采集配置版本就无法切段，不按优先级丢弃就连「丢掉的是哪一类」都无从知道。⚠ 收口时反过来也不许走极端：正解不是「车端必须保证数据完美」——那做不到，也不必；正解是让不完美可见且可判：留序号、留原始时标与校正量两列、留采集配置版本号、把丢弃优先级写进需求而不是交给协议栈。⛔ 把这一条压缩成「车端要更可靠」就是把判据换掉了：本课要的不是更少的丢帧，是丢了能被算出来、能被定位到具体的工况分箱。

方法上有一条纪律，六讲反复用：凡是要「列一个清单」的地方，一律先画全集，⛔ 禁止沿单一线索枚举，并且每次都照做两问自检——我是沿什么线索数出来的？有没有不在这条线索上、但同属这个集合的？全课要画六个全集：车端数据通道（第 1 讲，按接收方 × 触发方式二维建集）、热管理事件（第 3 讲，按「谁让系统状态发生了不可由稳态外推的迁移」建集）、降字节手段（第 4 讲，按「在哪一层丢掉了什么」建集）、回流样本被弄脏的失效模式（第 5 讲，按「哪一环把样本弄脏了」建集）、车端采集侧的合规判定维度（第 6 讲，数据类型 × 粒度 × 处置三维核对表）、采集配置变更的影响面（第 6 讲，按「改了什么 × 谁会被静默毁掉」建集）。★ 两条配套规矩要先说死：其一，判定为「不设 / 不采 / 不上传」的格，也必须显式成表的一行并写出理由，⛔ 不许靠「没写就是没有」——默认值不会被测试覆盖，车端对「引用了一路不存在的信号」的默认行为是取默认值而不报错；其二，凡是本课在大纲之外补出来的项（云端按需拉取、本地留存不上行、缺席事件、少采与降精度这两类降字节手段、变化上报、聚合口径改动这个陷阱、τ_min 这个符号、断连时长取分位数这条口径、三表闭合校验），正文与图上一律标明是本课归纳，⛔ 不写成大纲或某标准既有。

⚠ 五处口径先写死，全课统一——它们看起来琐碎，却是本课里最容易静默出错的地方，因为每一处的两种读法表面读数一模一样。① 「行程」：上电到下电算一次？点火周期算一次？停车超过多久算新行程？三种口径都在流通，而行程时长分箱、每行程触发配额、B_day 里的采集在线时长 T_on、按行程统计的丢帧率全部挂在这一个定义上；本课不替你选一套（那取决于本项目的整车上下电策略与远程唤醒设计），只要求在信号表的口径声明里写明取哪一套，并且全表、全课、全分析链统一。② 字节前缀两套：上行量、流量资费与云端存储一律用十进制前缀（kB = 10³ B、MB = 10⁶ B、GB = 10⁹ B，运营商流量与云存储按十进制计费），车端 RAM 与 Flash 侧一律用二进制前缀（KiB = 2¹⁰ B、MiB = 2²⁰ B、GiB = 2³⁰ B），⛔ 两侧符号不许混用；★ 这条口径是本课自立的（本课归纳），⛔ 不得写成某标准既有。③ 上行采样率 f_up ⛔ 不是车内报文频率 f_bus：后者由通信矩阵定（去向 K2-02 CAN/LIN/CAN-FD 通信与整车 EEA 集成），前者由待回答问题的时间尺度定，两者分列两个符号，全课不共用。④ 采集侧的环形缓冲 M_ring ⛔ 不是上行侧的断连缓存 M_buf：前者由前触发窗与检出延迟驱动、保的是事件发生前的基线，后者由断连时长驱动、保的是断网期间产生的所有待发数据；两者单位都是字节、形式都是「一个时间量乘一个字节率」，形式相似而含义无关，⛔ 不得合并成一笔「缓存预算」、⛔ 不得用一方的余量去论证另一方够用。⑤ 聚合字节比 r_agg 小于 1 表示省，⛔ 全课不用「压缩比」一词——该词在中文工程实务里两个方向都在流通。⚠ 还有一处分母口径要在第 5 讲写死：丢帧率的分母是「应产生的样本数」还是「已进入发送队列的样本数」，两者在缓存溢出场景下差得很远。

本课涉及的外部规范，一律只写标准号、只写它约束什么、只写去向，⛔ 不写数据项清单、不写周期数值、不写门槛与条款内容。GB/T 32960（电动汽车远程服务与管理系统技术规范）在本课只用三条性质：它约束的是远程服务与管理平台的上传数据项与上传周期；接收方是监管平台，项集与周期工程侧改不动、也不面向工程评估；有正常与故障两档周期。⇒ 它在本课的用途只有一个——作通道划分依据，并在预算表里作为「已占用」的一项先扣掉。《汽车数据安全管理若干规定（试行）》与 GB/T 41871（信息安全技术 汽车数据处理安全要求，推荐性国标）只作信号表合规列判据的来源指向，法源、制度与出境评估流程见 N6-01 预测性热管理的车云数据生态与产业路径。ISO/SAE 21434（道路车辆网络安全工程）与 ISO 24089（道路车辆软件更新工程）在本课只对应两条边界：下发链路的签名与防篡改见 K2-04 网络安全与 OTA 安全基础，采集配置随灰度包下发的发布工程见 K7-02 软件定义热管理与 OTA 迭代。⚠ 以上标准与法规本课均未取到原文，版次、部分号与实施日期一律以现行目录为准，具体适用范围与门槛引用前须核原文，⛔ 本讲义不把其中任何一项写成单值。

六讲就按这条主干排。第 1 讲先画「数据往哪去」这张全集并把射程圈死：接收方 × 触发方式九格逐格核过，本课射程只在工程回流的连续层与事件抓帧层两格（⛔ 两层不许合成一层设计），法定监管遥测只写性质与「已占用」的记法，诊断侧的冻结帧与按需读取两格各自写清验收判据；这一讲还补两样沿单一线索数不出来的东西——云端按需拉取（发起方在云端、不受车端配额约束的非计划流量）与本地留存不上行（占存储与合规、不占上行带宽），两者都是本课按二维格归纳补出的。第 2 讲把信号表从一句结论反推出来：四类量（最容易漏的是排除变量，因为它不出现在结论的字面上）、上行采样率怎么定、欠采样对两类量的后果方向不同（积分量的误差是双向的，峰值量只会被单向低估，⛔「误差可正可负、平均一下就没了」对峰值量不成立）、六列必填与权威来源唯一化、字长按用途反选（⛔ 别统一给 2 字节）、把「工况覆盖」从附注提成必填列，以及五方签署里最常缺的那一签。第 3 讲做事件抓帧与环形缓冲：稳态数据近乎无信息量这个立论前提、触发事件按「不可由稳态外推的迁移」建集（含本课补出的缺席事件——预期该发生却没发生，靠量的跳变根本检不出来）、前后窗各按各的判据反推、环形缓冲必须把触发检出延迟算进去（漏掉它的后果是缓冲看起来够、而缺口正落在起因段，方向偏危险）、触发风暴的配额与降级次序预先定死，以及「触发条件表是可下发配置而不是硬编码」。第 4 讲算账：先列 B_day 算式再谈省、封装开销的两种参数化只能取一、降字节手段是五类加一类降驻留（⚠ 变化上报与降频不是同一件事，积分重建方式完全不同）、选型判据只有一条「这份数据还会不会被重新算一次」（★ 聚合不可逆）、保留期分层在通道设计时就要落、年成本三项时间累积方式不同⛔ 不得直接比大小，以及一进一出两道预算闸。第 5 讲处理不完美：断连缓存与断连时长的分位数口径、缓存满时的丢弃优先级、限速补传与补传标记、时标漂移与可用性分级、丢帧率与缺口分布必须一起看，以及最易漏而后果最重的信号语义版本——改版会让历史与新数据成为两个口径，而云端会把它读成「模型漂移」并白白触发一轮再训练（去向 K7-03 数据驱动的能效自学习控制）。第 6 讲收在两件不属于代码的事上：合规列怎么逐路填出结论与签署人（含位置类数据的四档粒度阶梯——在车端就聚合，⛔ 不是上云再脱敏），采集配置件怎么走版本与变更管控（版本号、回滚路径、兼容矩阵三样，以及三个会静默毁掉结论的变更陷阱），以及那张每格都要有具名角色的责任表——缺「签合规」与「喊停」两格，是本课最常见的组织性缺陷。

学完这门课，你要能对手上任意一项数据需求当场答出四件事。① 判通道：这项需求的接收方是监管平台、是到场的技师，还是云端的分析流程？接收方决定验收判据，验收判据决定通道——把法定监管遥测当工程数据源，拿到的是一份改不动、也不面向工程评估的数据；把工程需求塞进诊断通道，拿到的是单帧快照而不是带前后窗的时间序列。② 判口径：这一路上行多快、几个字节、属连续层还是事件抓帧层、权威来源取谁、语义版本是哪一版、合规列填什么；触发抓帧则要判事件值不值得花字节、前后两个窗各由哪条判据反推、缓存要留多深、触发风暴来了按什么次序降级。③ 算账并守住闸门：把这套口径的单车日字节数与年成本按算式拆开算出来，在降字节手段里选一个，并说清这一刀省下多少字节、永久放弃了以后还能回答哪个问题。④ 把不完美变成可判定的：判得出哪批补传样本能进时序分析、哪批只能进分箱统计，说得清丢帧统计缺失如何把选择性偏差伪装成指标改善，并把采集配置当成有版本、有回滚、有兼容矩阵的车端配置件来管。⚠ 这四件事在「动手做」里合成一次实操：给定一个评估目标产出三张表，并做一次闭合校验——触发条件表引用的每一路信号 ⊆ 信号表、每个事件的抓帧信号集 ⊆ 信号表、预算表的每一项都追得回前两张表的具体字段。⛔ 三表里的所有数值（含单价与车队规模）一律是学员自定的演算假设值，须在表头标明不对应任何平台；⛔ 本讲义不提供一份「参考答案表」的数值——给了就会被当成量级参考。

---

第 1 讲　先判「这份数据往哪去」：接收方不同，验收判据就跟着不同

这一讲不定一路信号，也不算一个字节。它只做一件事：把「车上的数据能往哪去」这张全集画出来，逐格核过，再决定哪几格归本课管、哪几格只给去向。

顺序为什么必须是这样。通道判错的后果不是「效率低一点」，是整件事做不成。把法定监管遥测当成工程数据源，拿到手的是一份改不动、也不面向工程评估的数据；把工程回流的需求塞进诊断通道，拿到手的是一张单帧快照，而不是一段带前后窗的时间序列。这两种错都不会报错——它们的表现形式是几个月之后有人发现「这批数据答不了我要问的那个问题」，而那时车已经跑完了，钱已经花完了，采集口径也已经写进了量产软件。

这一讲还要把本课的射程与边界一次写死。理由在后面五讲会反复看到：本课的每一条判据都会诱使人往外走一步——算完带宽就想算投资回报，讲完触发就想讲状态机，讲完版本就想讲再训练。边界不先写死，这门课会摊成一门什么都讲一点、什么都讲不透的课。

1.1 三条通道并行，接收方各不相同——本课只判第三条

是什么。一台量产车上，工程物理量能去的地方不止一处。按接收方分，实际在跑的是三条并行通道：

• 诊断通道——接收方是到场的人（技师、诊断仪、售后系统）。形态有两种：故障码置位时刻留下的冻结帧与扩展记录（事件触发），以及诊断仪现场按标识符取值（请求-应答）。
• 法定监管遥测通道——接收方是监管平台。形态是周期上报，数据项与上传周期由标准体系约束，工程侧改不动。
• 工程回流通道——接收方是云端工程数据平台。它内部还要再分两层（连续层与事件抓帧层，见 1.5），这一条是本课的射程。

为什么这个划分要按「接收方」而不是按「数据重要程度」或「采样率高低」来分。因为接收方决定验收判据，验收判据再决定字段集、采样率、保留期与触发条件，这是一条单向的推导链。诊断侧的读者是一个人、站在一台车前、要复现一次故障，所以它的合格证是「技师照这些字段能不能把工况复现出来」；工程侧的读者是一套云端流程、面对整支车队、要算一个统计指标，所以它的合格证是「云端照这段序列能不能把目标指标算出来」。两个判据不同，往下推出来的所有设计参数就没有任何理由相同。

反过来看这条链最能说明问题：如果先按「这个量重不重要」去分，得到的结论会是「重要的多采、不重要的少采」——而这句话在三条通道里每一条都对，因而对任何一条都没有指导作用；真正决定该不该采、采成什么形态的，是那个量要交给谁看。

工程量级。本课在这一层不给任何数——⛔ 不给周期、不给字节数、不给采样率。这一层的产出只有一句话：先把接收方认出来。第 2 讲往后才开始出现可算的量。

易错点。最常见的一种是把三条通道在脑子里合成一条——因为它们物理上确实共用同一批传感器、同一条总线、甚至同一个远程通信模块。共用硬件不等于共用口径：同一路水温在三条通道里可以有三种完全不同的采样率、三种不同的字长、三种不同的保留期，而且这三种全都是对的。

1.2 ⛔ 全集不许沿管线数：按「接收方 × 触发方式」二维建集，九格逐格核过

是什么。1.1 那三条通道不是数出来的，是建出来的。建法是一张二维表：

• 接收方三类：监管平台／售后与诊断／工程与研发；
• 触发方式三类：周期上报／事件触发／请求-应答（按需读取）。

三乘三得九格，逐格核过之后才决定哪几格归本课。核完的结果是这张表：

接收方 ＼ 触发方式	周期上报	事件触发	请求-应答（按需读取）
监管平台	法定监管遥测——预算里是已占用的一项，先扣掉（1.3）	法定通道内部的故障档周期切换——归上一格，不另设	本课在这一格没有落点；监管侧的取数由上一格的周期上报承担。⚠ 本项目所在市场若另有按单车调取的要求，须按现行版本核，本课不判
售后与诊断	⛔ 本课判定不设——理由：接收方是到场的人，不是常开的平台（1.8）	故障码与冻结帧——去向 K5-01 OBD/UDS 诊断与故障码（DTC）设计（1.4）	按需读取（诊断仪现场按标识符取值）——去向 K5-01 OBD/UDS 诊断与故障码（DTC）设计（1.4）
工程与研发	工程遥测连续层 ← 本课射程（1.5）	工程抓帧事件层 ← 本课射程（1.5）	★ 云端按需拉取（本课归纳）——非计划流量，须单独配额（1.6）

⚠ 这张表外面还有一整类：本地留存不上行（1.7）。它不属于任何一格，因为它的接收方不是一个平台。

为什么不许沿「车端 → 远程通信模块 → 云端」这条管线往下数。沿一条管线数，眼睛只跟着上行走；凡是不上行的东西，在这条线索上一次都不会出现。而它漏掉的方式最要命——不是「少了一条」，是「整类不出现」：清单看起来是完整的，每一条都对，没有任何一处显得可疑。本地留存不上行就是这样漏掉的：它占非易失存储、占合规结论，唯独不占上行带宽，于是在一张按上行链路建出来的表上完全隐形。

二维建集为什么能防住这一类：因为它不问「数据怎么流」，只问「谁收、什么时候发」。这两个维度是正交的，逐格核过时，每一格都必须被显式回答一次「这一格里有没有东西」，答「没有」也要写理由。⚠ 它不是万能的——二维表自己也会漏，漏的正是不属于这两个维度的整类（本地留存就是），所以核完九格之后还必须再问一次「有没有东西不在这两个维度上」。这一问是建全集的最后一步，⛔ 不许省。

工程量级。九格的分布是：本课射程 2 格（工程 × 周期上报、工程 × 事件触发）、明确给去向 3 格（法定监管遥测、故障码与冻结帧、按需读取）、本课归纳补出 1 格（云端按需拉取）、判定为不设 1 格（售后 × 周期上报）、归并到别格或本课无落点 2 格；表外另有 1 类（本地留存不上行）。⛔ 这几个格数是本课建集的结构事实，⛔ 不是任何标准规定的分类，换一组维度就会得到另一张表。

易错点。两个，都是这一节要防的：① 只数「上行的通道」，于是本地留存整类不出现；② 把「本课判定不设」当成「不存在」而不写进表——⛔ 没写进表的组合不会被任何人测试到，1.8 专门讲这一条。

1.3 法定监管遥测：项集与周期工程侧改不动，做预算时它是「已占用」的一项先扣掉

是什么。这一格对应的是 GB/T 32960（电动汽车远程服务与管理系统技术规范）体系。⛔ 本课未取到该标准原文，因此这里只写三条性质，⛔ 一个数据项、一个周期数值、一个字段长度都不写：

1. 它约束的是远程服务与管理平台的上传数据项与上传周期；
2. 接收方是监管平台，项集与周期工程侧改不动；
3. 上传周期有正常与故障两档，两档不同值。

⚠ 该标准存在多个版本，版次、实施日期与代替关系以现行目录为准，引用前须核；具体数据项与两档周期的数值同样按现行版本原文确认。⛔ 本课不转述任何一个具体值——转述值被当成标准值用，是这类引用最常见的一种出错方式。

为什么它不能当工程数据源用。它的设计目标是监管与安全监测，字段集与周期都不是为了回答「这一版热管理标定的收益有多大」而挑的。工程要问的问题一变（今天问冬季能耗、下季问除霜策略、明年问电池热管理边界），这条通道一个字节都改不了——因为改它需要的不是一次内部评审，而是标准与监管侧的口径变更。⇒ 工程回流必须另设通道，这是一条结构性的结论，与本项目的技术能力无关。

工程量级。这条通道在本课的账本里只出现一次，出现的方式是「已占用」的一项，先扣掉：它每天要占掉一部分上行字节与一部分蜂窝流量费，这部分不属于本课能优化的范围，但属于本车必须支付的范围。⇒ 做带宽与资费预算时，可用余量应当是「本车总预算 − 法定通道占用」，⛔ 不是「本车总预算」。⛔ 它占多少，本课不给数——那取决于按现行版本确认的项集与周期，须由本项目自行核算。

易错点。两个方向都错：① 「反正车上已经在传了，顺便拿来分析」——数据项与周期都对不上要回答的问题，分析做到一半会发现缺分层变量、缺排除变量，而这条通道里根本没有它们；② 把它的上行量整个漏出预算表——于是纸面上算出的单车日上行量比真实值低，等到运营侧收到账单才发现对不上，而那时采集口径已经上车。

1.4 诊断通道占两格：冻结帧与按需读取的读者是「到场的人」

是什么。诊断侧在九格里占两格，⛔ 不是一格：

• 【售后 × 事件触发】＝故障码置位时刻留下的冻结帧与扩展记录；它是单帧加扩展记录，⛔ 不带前后窗。
• 【售后 × 请求-应答】＝诊断仪现场按标识符取值；它是一次问一次答，⛔ 不面向车队统计。

两格的规格（有哪些字段、扩展记录怎么组织、标识符怎么定义）⛔ 全部不在本课射程内，去向 K5-01 OBD/UDS 诊断与故障码（DTC）设计；三条通道之间的分工判据同样由 K5-01 OBD/UDS 诊断与故障码（DTC）设计 给出，本课承接它并只落后两条的车端实现。

为什么这两格必须与工程回流分开设计。还是那条链：接收方决定验收判据。诊断侧的合格证是「技师照这些字段能不能复现工况」——它要的是一个时刻的横截面尽可能全；工程侧的合格证是「云端照这段序列能不能算出目标指标」——它要的是一段时间的纵剖面尽可能连贯。一个求宽，一个求长，两者没有任何一方是另一方的子集。

更要紧的是触发条件也不该共用，这一条最容易被忽略。诊断侧的触发要稳：带去抖、带成熟计数，宁可晚报也不许误报，因为误报的代价是一次无谓的进厂；工程侧的触发要全：宁可多抓一次工况段，因为漏抓的代价是这一类工况在数据里永远缺席。两个方向相反的要求塞进同一套触发条件，结果是两边同时不合格——去抖调长了工程侧漏抓短事件，调短了诊断侧误报。

工程量级。⛔ 本课不给冻结帧的字段数、不给扩展记录的条数、不给去抖时长与成熟计数的取值（全部去向 K5-01 OBD/UDS 诊断与故障码（DTC）设计）。本课在这一层只给一张对照：三条通道在六个属性上各自是什么样（接收方、触发源、字段集形态、采样率、保留期、验收判据），这张对照在第 3 讲用它的完整形态出现。

易错点。拿冻结帧的字段集直接当工程抓帧的信号集用。字段可以重叠——同一路排气温度两边都要，这很正常；但触发条件不许共用（理由见上），窗形也不同（一个是单帧，一个是带前后窗的序列）。把两件事合并的动机通常是「省事、少写一份表」，代价是两边的验收判据都过不了。

1.5 工程回流必须分两层：连续层与事件抓帧层是两个独立的字节来源，⛔ 不许合成一层设计

是什么。本课射程内的那两格，是同一条工程回流通道的两层：

• 连续层（工程 × 周期上报）——回答「这台车这一天、这一段行程的工况分布与累计量是什么」。它只留低频的工况分箱量与累计量。
• 事件抓帧层（工程 × 事件触发）——回答「这次迁移是怎么发生的、系统有没有收敛回稳态」。它只在触发时留一段带前后窗的时间序列。

⇒ 因此信号表里的「所属层」是每一路都必须填的一列（第 2 讲讲六列必填时会再回到它）。

为什么两层必须分开设计，而不是「设一个采样率，忙的时候提上去」。三条理由，任一条都够：

1. 信息密度不同。热管理稳态段的信号自相关极高——这一秒的水温几乎完全可由上一秒预测出来，因此连续记录的边际信息随时长快速衰减，而字节数随时长线性增长。事件段恰好相反：信息密度高、持续时间短。两段的「信息／字节比」差别悬殊，用同一套参数去覆盖，必然在一头浪费、在另一头不够。
2. 验收判据不同。连续层的合格证是「分箱与累计量算得准」，它容得下降采样；事件层的合格证是「起因看得见、收敛看得见」，它容不下降采样但容得下低占空比。
3. 字节账要能拆开。两层在日上行字节算式里是两个独立的求和项：连续层是「路数 × 上行采样率 × 字长 × 在线时长」的求和，事件层是「事件次数 × 前后窗长 × 抓帧信号集字节率」的求和。⇒ 砍字节时，两层要拧的旋钮完全不同：连续层对路数与采样率是乘性的，事件层对窗长与抓帧信号集是乘性的。合成一层，就没法知道该砍哪一头。

工程量级。⛔ 两层各占多少比例，本课不给数、尤其不给任何可引用的百分比——它完全由信号表与触发配置决定，换一套配置比例会反过来。本课给的是算式与拆账方法（第 4 讲），以及上面那条稳定的结构性事实（两层各自对什么量是乘性的）。

易错点。两个方向对称地错：① 把事件抓帧当成「连续层临时提速」——那样它就没有前触发窗，判据成立之后才开始记，起因段永远看不到（第 3 讲会看到这个缺口的位置有多要命）；② 把连续层当成「低速的抓帧」——于是给它配了整套抓帧信号集，路数一下子上去，字节账被悄悄放大一个量级，而多出来的那些路一次都没被分析用到。

1.6 ★ 本课补出的第六格：云端按需拉取是非计划流量，日上行字节算式里没有它的位置

是什么。【工程 × 请求-应答】这一格——云端下发一次性取数指令，或按车辆标识拉取某段历史数据，车端按请求回传。⚠ 这一格是本课按二维格补出来的，⛔ 不是任何既有分类里的既有项；正文与图上都标明它是本课归纳。

为什么它必须单独立一格、单独记一笔账。前两格（连续层、事件层）有一个共同性质：它们的发起方在车端——车端按预置配置自主产生数据，因此字节率可预算，可以写进算式、可以设配额、可以在评审时被核。这一格发起方在云端，它的量取决于「这个月有几个分析师提了取数需求」，本质上不可由车端的算式预测。

⇒ 它是非计划流量：不受车端配额约束，一次批量取数就能把当月的流量预算打穿，而它在按车端配置写出来的日上行字节算式里根本没有位置。这就是它必须被补出来的全部理由——一个不在算式里的量，不会因为算式算得再准而消失。

工程量级。⛔ 本课不给它的量——那是平台相关量与组织行为的产物（取决于分析侧的人数、习惯与审批松紧）。本课只给做法三条：① 把它列进预算表的第三项，与连续层、事件层并列；② 设车队级月度配额并由云端侧记账（车端配额管不住它，因为触发不在车端）；③ ⛔ 不许把它摊进日上行字节算式当常态——摊进去等于把一个不可预测量伪装成可预测量，算出来的每一个数都带上了它的方差。

易错点。两个：① 以为「按需拉取只是偶尔用一下」——恰恰相反，一旦分析侧发现能拉，它会迅速成为默认动作（「先拉一个月看看」比「重新过一遍信号表评审」便宜太多）；② 把它记进事件层——于是事件层的字节账被污染，第 4 讲砍窗长的时候会发现怎么砍都对不上，因为大头根本不在窗长上。

1.7 ★ 本课补出的另一类：本地留存不上行——它不出现在任何一格里

是什么。车端记录仪式的本地日志或本地留存的抓帧：数据产生了、落了盘，但不上行，事故后由人取回，或在下次连接时按需上传。⚠ 这一类同样是本课补出来的，⛔ 不写成任何既有分类的既有项。

为什么它一定会被沿管线的线索漏掉，而漏掉之后又一定会出问题。它的接收方不是一个平台，而是「以后可能来取它的人」——所以「接收方 × 触发方式」这两个维度容不下它，任何一格都不是它的位置。这正是 1.2 说的那句「二维表本身也会漏」的具体形态。

而它对本课的两件事有实际影响，漏掉就是两侧同时出错：

• 它占非易失存储配额——与环形缓冲、学习值、诊断数据抢同一块空间（存储介质选型、掉电一致性与擦写寿命去向 K4-06 控制器非易失存储设计：学习值、诊断数据与累计量的持久化，本课只声明需求）；
• 它同样要过合规列——采了就要有采集粒度、保留期与处置结论，⛔ 「没上传」不等于「没采集」（合规列的填法在第 6 讲）。

工程量级。⛔ 本课不给任何容量数与保留期数。本课只声明一条落点判据：它必须出现在合规列与存储预算里，而不该出现在上行带宽账里。

易错点。正好两种方向相反的错，而且都很常见：① 把它算进上行流量账——成本算高了，还挤掉了真正需要上行的那几路；② 完全不记账——存储侧发现空间莫名其妙不够，合规侧发现有一批数据没有保留期结论，两边都查不到源头。

1.8 ★ 判定「不设」也必须成表的一行：默认值不会被测试覆盖

是什么。全集里判定为「不设」「不采」「不上传」的格，必须显式写成表的一行，带上判定理由与判定人，⛔ 不许让它以「表里找不到」的形式存在。本课的实例是【售后 × 周期上报】：本课判定不设，理由是它的接收方是到场的人，不是常开的平台——诊断不做常态周期上报。

为什么「没写就是没有」不成立。因为默认值不会被测试覆盖。一个没写进表的组合，在车端的表现不是报错，而是取到一个默认值并继续跑下去。两个具体形态：

• 触发条件表里引用了一路不在信号表里的信号——判据会拿默认值（零，或者上次值）去比较，而且一声不吭。表现出来是这类事件「从来不触发」或者「一上电就触发」，而查判据本身怎么看都是对的。
• 抓帧信号集里列了信号表没有的信号——抓下来的帧会有一列空列，云端读到的是「有这一列，但整列缺失」。它与「这一列真的没有数据」在库里长得一模一样。

⇒ 由此推出一条必须做的闭合校验：触发条件表引用的信号 ⊆ 信号表，抓帧信号集 ⊆ 信号表。这两条包含关系要在表评审时逐条核，它是动手做那一步里第三张表的自查项。

工程量级。⛔ 本课不给「这张表该有多少行」这种数——行数由本项目的全集决定。本课给的是上面那条闭合校验，以及一条格式要求：判定不设的格，理由与判定人两栏不许空。理由栏留空的后果是下一轮评审时没人记得为什么不设，于是它要么被重新讨论一遍，要么被某个人顺手设上。

易错点。两个：① 把「不设」理解成「不用管」——它恰恰是最需要写下来的一格，因为它是唯一一个没有任何产物能证明自己存在过的判定；② 只在信号表这一侧做闭合校验，忘了触发条件表那一侧——两张表分属两个人维护时，这件事必然发生：改信号表的人不会去翻触发条件表，反之亦然。

1.9 一项数据需求该落在哪条通道：入口第一问是「接收方是谁」

是什么。把前面八节收成一条可执行的分流链。给定一项数据需求，按顺序问三问：

• 问① 接收方是谁？——监管平台／到场的人／云端分析流程。
  • 监管平台 ⇒ 终点【法定通道】：项集与周期由标准体系定，工程侧改不动。
  • 到场的人 ⇒ 进问②。
  • 云端分析流程 ⇒ 进问③。
• 问② 要单帧快照还是带前后窗的序列？
  • 单帧 ⇒ 终点【冻结帧】，去向 K5-01 OBD/UDS 诊断与故障码（DTC）设计。
  • 序列 ⇒ 回到问①。⚠ 这条回边不是画错了：若确实要序列，那么这个需求的接收方其实是云端而不是到场的人——它被问错了对象。
• 问③ 这个量要回答的问题是「分布与累计」还是「一次迁移是怎么发生的」？
  • 分布与累计 ⇒ 终点【工程遥测连续层】。
  • 一次迁移 ⇒ 终点【工程抓帧事件层】。
  • 都不是，是一次性取某段历史 ⇒ 终点【云端按需拉取】（★ 本课归纳）＋单独配额。

为什么第一问是「接收方是谁」而不是「这个量重不重要」。因为「重不重要」在三条通道里都答「重要」，它分不开任何东西；而接收方决定验收判据、验收判据决定通道（1.1 那条链）。把顺序颠倒过来的实际后果是：一项重要的需求被塞进「最方便的那条通道」——通常是已经在跑的那条——然后在几个月后被发现口径不对。

工程量级。⛔ 这条链上不出现任何数值：不写周期、不写字节数、不写条款内容，每个终点下面只挂两样——通道名与这条通道的验收判据。它是入口分流，⛔ 不是完整设计流程：每个终点之后各自还有一整套设计动作（第 2 讲到第 6 讲），本链只到分流为止。

易错点。在问②那一支上「用冻结帧硬凑一段序列」——做法通常是「多存几帧扩展记录，拼起来当序列用」。它过不了任何一边的验收：帧与帧之间没有等间隔保证、没有前触发窗、没有序号，云端既算不出丢帧率也做不了时序对齐。⇒ 遇到这一支，正确动作是回到问①重新认接收方，⛔ 不是在诊断通道里想办法。

1.10 本课的射程与八条边界一次写死：不在射程内的只给类型与去向，⛔ 不给限值

是什么。本课的射程一句话：车端采什么、按什么触发、上行多少、以什么语义版本入库——到「干净时序样本按声明口径产生并入库」为止。这句话既是起点也是终点：入库之前的每一件事本课都要给出可评审的做法，入库之后的每一件事本课一律只给去向。

八条边界，各自的去向写死在这里：

#	这件事	去向
①	车内报文的字段定义、缩放与周期，总线负载	K2-02 CAN/LIN/CAN-FD 通信与整车 EEA 集成
②	台架侧的多通道硬件同步、抗混叠滤波与预触发采集	L7-02 数据采集、台架搭建与自动化测试
③	故障码、冻结帧与扩展数据记录的规格；三通道分工判据的来源	K5-01 OBD/UDS 诊断与故障码（DTC）设计
④	灰度节奏、回滚门限、样本量与显著性判据；采集配置随灰度包下发的发布工程	K7-02 软件定义热管理与 OTA 迭代
⑤	云端建模、特征工程、影子模式与对照评估、再训练	K7-03 数据驱动的能效自学习控制
⑥	配置下发链路的签名校验、权限分级与防篡改	K2-04 网络安全与 OTA 安全基础
⑦	缓冲落什么介质、掉电一致性与擦写寿命	K4-06 控制器非易失存储设计：学习值、诊断数据与累计量的持久化
⑧	数据合规的法源、制度、出境评估流程与产业侧责任划分	N6-01 预测性热管理的车云数据生态与产业路径；投资回报的收益侧去向 N6-02 整车热管理数字孪生与在线优化

★ 还有一条边界不在上表里，因为它划的不是「归哪门课」，是「这批数据能用来干什么」——⚠ 这一条是本课归纳，⛔ 不是任何标准或既有体系既有的说法。

车队数据替代的是标定台架，⛔ 不替代定尺寸台架。

理由只有一句，但它是结构性的：设计临界工况按定义就是罕见的，而还没发生过的工况，再多车也采不到。⇒ 车队规模上去之后，增加的是内点密度（常见工况的样本更多、分箱更细），⛔ 不是边界覆盖（极端角落该空还是空）。

两件事因此分开：

• 标定看的是常见工况下参数取多少合适 ⇒ 车队数据在这里确实能替代大量台架时间，而且比台架更有说服力（真实分布，不是工程师设想的分布）；
• 定尺寸看的是最恶劣那一角能不能扛住 ⇒ 它要的恰好是采不到的那部分，只能靠设计出来的极端工况（B1-01 整车热平衡与全工况热负荷谱分析 的全工况热负荷谱就是干这个的）与环境舱实测（K6-04 环境舱与整车热平衡标定）。

⛔ 最容易犯的读法是「等车队数据攒够了，极限工况试验就可以少做」——它把「样本多」当成了「覆盖全」。判据是可当场自查的：问一句「本课定的这批信号，能不能采到设计工况点附近的样本？」如果那个点在你的工况分箱里常年是空的，那这批数据对定尺寸就是零信息，⛔ 无论它有多少 TB。

⚠ 与这几条边界相关的外部规范，本课只写标准号与去向，⛔ 不写条款内容、⛔ 不写等级号、⛔ 不写版次与年份：ISO/SAE 21434（道路车辆网络安全工程）对应边界 ⑥；ISO 24089（道路车辆软件更新工程）对应边界 ④；《汽车数据安全管理若干规定（试行）》与 GB/T 41871（信息安全技术 汽车数据处理安全要求，推荐性国家标准）对应边界 ⑧，它们只作为信号表合规列判据的来源指向。⛔ 上述各件的适用范围、门槛与版次一律按现行版本原文确认，本课未取原文，⛔ 不给任何限值。

为什么边界要在第 1 讲就写死，而不是用到哪讲哪。因为本课的每一条判据都自带一个往外走的诱因：算完单车日字节数，下一步自然想算这笔投入值不值（那是收益侧，去向 N6-02 整车热管理数字孪生与在线优化）；讲完触发判据，下一步自然想讲状态机与去抖（那是控制与诊断的活）；讲完信号语义版本，下一步自然想讲版本变了模型怎么办（那是云端的活）。这些「下一步」每一步单独看都合理，合起来就是把课摊平。⇒ 边界写死之后，后面五讲每次碰到这些诱因，只需要指一次去向。

工程量级。⛔ 八条边界之外，本课一律不给限值、不给等级号、不给条款内容。这条禁令没有例外，包括「顺手写一句」的情形——因为读者看到一个数就会拿它当验收依据用，而本课根本没有核过那个数。

易错点。把「给去向」写成「给结论」。典型形态是：本该写「这项由某标准管，去向某课」，结果顺手多写了半句「（通常不超过某某）」。那半句的杀伤力比整段漏写还大——它看起来像是核过的，而写它的人自己知道没核过，读它的人不知道。⇒ 本课的写法固定为两样：类型（它是一件什么事）与去向（谁管、去哪门课），⛔ 没有第三样。

这一讲的收口。到这里，本课要处理的对象已经缩到两格：工程遥测连续层与工程抓帧事件层；另有三样必须记账但不进日上行字节算式的东西（法定通道的已占用量、云端按需拉取、本地留存不上行）。⇒ 从第 2 讲起，全部工作都在这两格里展开，第一件事是回答「连续层的那张信号表，是从哪里推出来的」——⛔ 不是从「车上能采什么」推出来的。