N6-01 预测性热管理的车云数据生态与产业路径

课程代码 N6-01 · 板块 N 前沿与新技术 / N6 智能预测与数字孪生 时长 约 3.5 小时（6 讲 + 1 次架构实操） 适合对象 系统架构工程师、控制系统工程师、车云协同项目的技术骨干；以及要为「这套预测能力能不能立项、自建还是采购」出判断的技术管理者。选修，建议先修 K7-01 预测性热管理（导航/云端/驾驶意图协同） 前置 K7-01 预测性热管理（导航/云端/驾驶意图协同） 预测性热管理（导航/云端/驾驶意图协同）——提前量反推、四类时间量口径、置信度权重 w 只乘前馈支路这三件，本课直接沿用、⛔ 不重推。体系外前置需自备：对车联网/云平台基础架构（服务端、消息通道、API 调用）有基本了解；会读一条乘法式的敏感度 本讲义定位 讲师授课蓝本 / 学员自学讲义

---

按任务导航

你手上的事	直接看	还要配
有人说「我们上一套预测性热管理」，你要判它到底要建什么	第 1 讲：四层架构图＋上下行两个方向，先把「算法」和「生态」拆开	第 6 讲（成熟度现实）
评估「再接一个数据源」值不值	第 2 讲 2.1 的四格评估卡，逐路填延迟/更新周期/可用性/两条合规线	第 5 讲（合规线）
有人拿 V2X 说事，要判它现在能不能依赖	第 2 讲 2.5：A_V2X ＝ c_RSU × p_veh × i_proto，⛔ 先说清算的是 V2I 还是 V2V	第 6 讲 6.2
要写行程级意图识别的需求，或者判某个方案的指标合不合理	第 3 讲：先分清行程级与秒级（后者归 K7-01 预测性热管理（导航/云端/驾驶意图协同）），再看 Cov–Acc 工作点	第 3 讲 3.6（期望净收益）
判「这条链来不来得及」	第 4 讲 4.1：T_margin ＝ T_avail − (T_data + T_proc + T_exec)，⛔ 这是架构层的账	K7-01 预测性热管理（导航/云端/驾驶意图协同） 第 4 讲（单点反推）
判「这条链够不够稳」，以及该先改哪一环	第 4 讲 4.4：P_e2e ＝ ∏P_i，先找木桶最短板	第 4 讲 4.6（降级）
设计断网/弱网下的降级	第 4 讲 4.6～4.8：三级架构降级，⛔ 不是单点算法降级	K7-01 预测性热管理（导航/云端/驾驶意图协同） 第 6 讲
要做车队数据聚合，被问「合规吗」	第 5 讲 5.4：两条并行的合规线，触发判据不同、处置动作也不同	K7-04 车队数据回流的车端实现：信号表定义、事件抓帧与带宽/存储预算（工程落法）
要给「自建 TSP 还是采购」出一个数	第 6 讲 6.5：N* ＝ 年化自建投入 ÷ (采购单价 − 自运维单价)	第 6 讲 6.6（非成本维度）

⛔ 本课不覆盖——两栏，每样带去向：

栏一 · 不讲哪些题目：前馈-反馈融合结构、提前量 t_lead 反推、置信度权重 w 的接法与降级实现 → K7-01 预测性热管理（导航/云端/驾驶意图协同）；车端上行的信号表定义、事件抓帧、环形缓冲深度与带宽/存储预算 → K7-04 车队数据回流的车端实现：信号表定义、事件抓帧与带宽/存储预算；云端模型的训练、评价与自学习闭环 → K7-03 数据驱动的能效自学习控制；数字孪生底座与在线寻优 → N6-02 整车热管理数字孪生与在线优化；大模型在开发流程中的用法 → N6-03 AI 大模型在热管理开发中的应用；某个 AI 方向该不该立项的收益上限账（Q_shift ≤ C_eff·ΔT_margin）→ N6-04 热管理 × AI 全景图：什么时候该上、什么时候不该，以及各类应用各自会怎么失效；OTA 下发、灰度与回滚 → K7-02 软件定义热管理与 OTA 迭代；快充预热的温度窗口与产热建模 → D4-01 快充产热与温升预测建模；场景充分性与残余风险论证 → K2-05 预期功能安全（SOTIF/ISO 21448）与 AI 件安全论证在热管理的落法。

栏二 · ⛔ 真正不给的数：① 本课点名的每一份法规与标准只写它管什么、去向哪里，⛔ 不转述条款内容，版次与适用门槛一律以现行目录/现行版本为准 → 查原文正文；② 各类数据源的延迟、更新周期与可用率只给数量级的判读方法与评估表模板，⛔ 不给可照抄的验收值 → 由本项目对本项目实际用的那家供应商实测；③ 意图识别的准确率、覆盖率「达到多少算可用」→ 本课给的是工作点怎么选的算式，门槛由本项目的收益/代价定；④ V2X 的三个覆盖因子、云平台可用率、单车订阅单价、自建投入 → 全部是平台相关量与时点相关量，本课给区间与锚点、⛔ 不给验收依据。

---

引言：把「预测性热管理」这五个字拆成两件事

大多数关于预测性热管理的讨论，一开始就走错了一步：把它当成一段算法来谈。于是评审会上的问题全落在「模型用什么」「精度做到多少」上，而项目真正卡住的地方——数据从哪来、多久到、断了怎么办、谁有权处理、这套东西要不要自己建——一个都没问。

这门课要做的第一件事，就是把这五个字劈成两半：

• 执行层：拿到一份带置信度的前瞻信息之后，怎么反推启动时刻、怎么接进前馈-反馈、错了怎么退回来。这一半是 K7-01 预测性热管理（导航/云端/驾驶意图协同） 的射程，本课直接沿用它的结论、⛔ 一条都不重推。
• 支撑层：那份前瞻信息本身是怎么来的——谁产生、经过几跳、耗时多少、可用率多高、涉不涉及个人信息、这条通道该自建还是采购。这一半是本课。

⇒ 一句话记住分界：K7-01 预测性热管理（导航/云端/驾驶意图协同） 回答「拿到信息之后怎么用」，本课回答「那份信息凭什么会在需要它的时刻出现在车上」。

这个劈法不是文字游戏，它决定了三件事的归属，而这三件事恰恰是项目最常翻车的地方：

1. 算得再准也来不及——链路耗时吃掉了全部提前量。这不是算法问题，是时序预算问题（第 4 讲）。
2. 大多数时候能用，关键时候不能用——链路上四五个环节各自「99% 可用」，连乘之后就不是 99% 了。这不是可靠性口号，是一道乘法（第 4 讲）。
3. 上线前一个月被合规拦下——因为合规接口没在架构阶段留。这不是流程问题，是架构问题（第 5 讲）。

★ 还有一件事要在开头就说破，因为它是本课全部内容的结构性前提：这套生态是双向的。下行是第三方数据进车（地图、气象、桩况），上行是车端遥测出车（回流样本、验证证据、法定监管数据）。两个方向共用同一条 TSP 通道、共享同一批可用率短板。⇒ 只画下行的架构图，会让第 4 讲的时延预算和可用率核算都少算一半——而少算的那一半不会以「算错了」的形式暴露，它会以「上线后带宽账单超支」「补传把下行挤掉」这种形式在半年后出现。

全课六讲这样排。第 1 讲立架构与边界：四层怎么分、上下行怎么画、本课与 K7-01 预测性热管理（导航/云端/驾驶意图协同）／K7-03 数据驱动的能效自学习控制／K7-04 车队数据回流的车端实现：信号表定义、事件抓帧与带宽/存储预算 各管哪一段，并且把全课的符号一次钉死（这一节很重要，因为本课有三个符号与前置课长得极像而含义不同）。第 2 讲逐路过数据源：地图、气象、V2X、充电网络、上行遥测，每一路填同一张四格评估卡，其中 V2X 那一格要把 V2I 与 V2V 拆开算，否则可用性必然估歪。第 3 讲讲行程级意图识别：它要回答的问题、两条技术路线、Cov–Acc 工作点怎么选，以及它与 K7-01 预测性热管理（导航/云端/驾驶意图协同） 秒级驾驶风格前馈的分界线。第 4 讲把两笔账真算出来——时延预算 T_margin 与链路可用率 P_e2e——再据此设计三级架构降级。第 5 讲讲跨主体协作与合规：联邦学习为什么是可行路径、车-桩协同怎么做、两条合规线各自怎么触发、架构阶段要留哪四个开关。第 6 讲落到产业判断：哪些环节已规模化、哪些还在示范，自建 TSP 与采购的分界点怎么算，以及成本之外那三个真正定生死的维度。

---

第 1 讲　从算法到生态：四层架构、双向链路与符号边界

本讲交付三件：① 一张能画出来的四层架构图，且上下行都在上面；② 本课与四门相邻课的射程分工，能逐条说出「这件事归谁」；③ 全课符号表——尤其是三个与前置课形近而义不同的符号，在这里一次性钉死。

本讲不交付：任何一路数据源的具体指标（第 2 讲）；任何一笔账的计算（第 4 讲）。

1.1 四层：车端感知 — 域控 — TSP 云平台 — 第三方数据源

是什么。把这套生态摊平，从车往外数，只有四层：

层	它是什么	它产出/消费什么	属主课
L1 车端感知与执行	传感器、执行器、整车网络上的报文	产出：车辆自身状态（SOC、电芯温度、水温、模式、可用功率包线）；消费：最终的控制指令	K1-01 热管理传感器信号处理与故障诊断 · K7-01 预测性热管理（导航/云端/驾驶意图协同）
L2 域控/车载计算	热管理域控制器或中央计算单元，跑本地预测与前馈-反馈控制律	产出：启动时刻与置信度权重；消费：L1 的状态 + L3 送下来的前瞻信息	K7-01 预测性热管理（导航/云端/驾驶意图协同）（控制律）· K4-01 热管理嵌入式软件架构与 AUTOSAR 基础（软件）
L3 TSP 云平台	主机厂或供应商的车联网服务端：连接管理、数据汇聚、模型服务、下发通道	产出：融合后的前瞻信息（下行）；消费：车端遥测（上行）	本课（架构与选型）· K7-03 数据驱动的能效自学习控制（云端建模）
L4 第三方数据源	地图/导航服务、气象服务、充电网络运营商、V2X 路侧设施	产出：路径与 ETA、天气预报、桩状态、路侧信息	本课

★ 为什么是四层而不是三层：最常见的画法把 L3 与 L4 合成一个「云」。这个合并会丢掉一件关键的事——L3 是你能改的，L4 是你只能选和买的。这两层的工程动作完全不同：L3 出问题你可以扩容、加缓存、改重试策略；L4 出问题你只能换供应商、加一路冗余源、或者接受它。⇒ 第 4 讲找短板时，短板落在 L3 还是 L4，处置动作差一个量级。

★ 为什么 L2 要单列而不并进 L1：因为断网时活下来的是 L2。第 4 讲的三级降级里，第二级就是「L3/L4 全断，L2 用本地历史与车端状态继续给一个降级的前瞻」。把 L2 并进 L1，这一级就没有位置放了。

易错点。① 把 L4 画成一个框。地图、气象、桩网、V2X 是四个互相独立的供应方，它们的可用率互不相关（这一点在第 4 讲的连乘里很重要——独立才能连乘），画成一个框会诱导人给它们一个统一的可用率。② 把 L3 默认成「我们自己的云」。采购方案里 L3 可能是供应商的，那么 L3 的可用率对你也是 L4 那种性质（只能选、不能改）——这正是第 6 讲选型判断的一个入口。③ 把「域控」理解成一个具体的硬件盒子。本课的 L2 是一个功能位置：谁在车上跑那段预测与控制逻辑，谁就是 L2，它可能是热管理域控、可能是中央计算单元的一个分区、也可能是车机。⛔ 不得据本课的分层去推任何 E/E 架构的物理拓扑。

1.2 上行必须画出来：同一条通道跑两个方向，而它们互相挤

是什么。下行链路（L4 → L3 → L2）送的是前瞻信息：路径与 ETA、目的地天气、桩的占用与协商功率。上行链路（L1 → L2 → L3）送的是车端遥测：连续层的信号流、事件触发的抓帧、以及法定监管遥测。

这两个方向在架构图上常被画成一条单向箭头，原因很朴素——讲预测性热管理时，人的注意力全在「数据进车」这一侧。而漏掉上行会带来三个后果，且它们出现的时间都比较晚：

1. 带宽预算少算一半。上行的字节量通常不小于下行——下行是几条结构化的短消息（一条路径、一个 ETA、一份预报），上行是连续采样的多路信号加事件抓帧。⇒ 只按下行做带宽规划，上线后账单会翻。
2. 可用率短板算错位置。上行的短板常常与下行不在同一环——下行卡在第三方 API 的限流上，上行卡在弱网区的重传上。只看下行会得出「链路很稳」的结论。
3. 模型迭代的证据没有来源。云端要改进预测模型，训练样本与验证样本只能从上行来。⇒ 上行没规划，模型上线之后就没有办法知道它准不准——这一条最隐蔽，因为它不表现为故障，表现为「一直没人说它有问题」。

★ 本课在这里只给落点，⛔ 不展开。上行侧的信号表怎么定、采样率怎么选、事件抓帧的缓冲要留多深、日上行字节怎么算、断连补传怎么限速——这一整套是 K7-04 车队数据回流的车端实现：信号表定义、事件抓帧与带宽/存储预算 的射程。本课要求的只有一件：在架构图上把上行画出来，并且在做时延与带宽预算时把它当成同一条通道上的另一半负载。

算例 1-1（教学假设值，⛔ 不对应任何平台）：只算下行会少算多少。

某项目做通道规划，下行侧列了三路：路径与 ETA 每 60 s 刷新一次、每次 2 kB；目的地天气每 600 s 一次、每次 1 kB；桩状态每 120 s 一次、每次 0.5 kB。上行侧因为「归 K7-04，先不管」而没列。

• 下行日字节（按每天 2 h 联网行驶计，即 7200 s）：
  • 路径与 ETA：7200/60 × 2 kB ＝ 120 × 2 ＝ 240 kB
  • 天气：7200/600 × 1 kB ＝ 12 × 1 ＝ 12 kB
  • 桩状态：7200/120 × 0.5 kB ＝ 60 × 0.5 ＝ 30 kB
  • 合计 282 kB/日/车
• 上行侧（同样是教学假设值）：连续层 30 路信号、上行采样 1 Hz、每路 2 B，则 7200 s × 30 × 2 B ＝ 432 kB；再加事件抓帧假设每日 3 次、每次 20 kB ＝ 60 kB；协议封装开销按 25% 计，上行合计 ≈ (432 + 60) × 1.25 ≈ 615 kB/日/车。

⇒ 真实总量 ≈ 897 kB/日/车，而只算下行得到 282 kB。少算了 68%，或者说按下行做的规划要乘上约 3.2 倍才够。

⚠ 这个算例说明什么、不说明什么。它说明的是「上行与下行不在一个量级上，漏掉上行的规划会系统性偏小」这个结构。它不说明「上行是下行的 2.2 倍」——这个比值完全取决于你上行采了几路、多快、抓不抓帧，换一组参数它可以是 0.5 也可以是 50。⇒ ⛔ 不得把 615/282 这个比值当成任何可引用的经验值；上行侧的正确算法（三段式算式、五类降字节手段）在 K7-04 车队数据回流的车端实现：信号表定义、事件抓帧与带宽/存储预算 第 4 讲。

易错点。① 把「上行归 K7-04」当成「上行不用出现在我的架构图上」。射程划分说的是「谁负责把它算清楚」，⛔ 不是「谁可以当它不存在」。② 把法定监管遥测漏掉。GB/T 32960 约束的正是上行这条链路（远程服务与管理平台的上传数据项、上传周期与平台接入要求），它是已占用的一份预算，做规划时应当先扣掉、⛔ 不是最后再加上去——⚠ 本课只写这份标准管什么与去向，具体的数据项、周期与接入要求⛔ 不转述，须查现行版本原文，工程落法归 K7-04 车队数据回流的车端实现：信号表定义、事件抓帧与带宽/存储预算。③ 以为下行的 API 调用不占上行。每一次向第三方拉数据都是一次请求，请求本身走上行；轮询频率高时这部分不可忽略——这正是第 2 讲要区分「推送」与「轮询」的原因。

1.3 射程分工：这五件事分别归谁

是什么。预测性热管理这个题目横跨五门课，边界不写清楚，读者会在两个方向上出错：要么以为本课会给控制律（不会），要么以为「架构」这两个字包含了车端实现（不包含）。逐条钉死：

这件事	归谁	本课怎么处理
提前量怎么反推、启动时刻怎么定	K7-01 预测性热管理（导航/云端/驾驶意图协同） 第 4 讲	直接引用它的结论，本课只在架构层另立一笔时序预算（4.1，与它不是同一笔账）
置信度权重 w 怎么接进控制律、降级怎么实现	K7-01 预测性热管理（导航/云端/驾驶意图协同） 第 5、6 讲	本课第 3 讲交出「意图置信度」作为 w 的一路输入，⛔ 不管它接进去之后的事
秒级驾驶风格特征与短时功率前馈	K7-01 预测性热管理（导航/云端/驾驶意图协同） 第 3 讲	本课第 3 讲只讲行程级，并在 3.1 把两者的分界线画死
车端上行的信号表、抓帧、带宽与存储预算	K7-04 车队数据回流的车端实现：信号表定义、事件抓帧与带宽/存储预算	本课只要求把上行画进架构、当成同一条通道的另一半负载（1.2）
云端模型怎么训练、怎么自学习、怎么评价	K7-03 数据驱动的能效自学习控制	本课第 5 讲只讲参数聚合的架构形态（联邦学习为什么可行），⛔ 不讲算法
某个 AI 方向值不值得立项（收益上限账）	N6-04 热管理 × AI 全景图：什么时候该上、什么时候不该，以及各类应用各自会怎么失效 第 4 讲	本课第 6 讲讲的是生态与平台的选型，与那笔收益账是两件事，6.1 会说清

★ 本课与 K7-01 预测性热管理（导航/云端/驾驶意图协同） 的关系要说得再具体一点，因为这是最容易读混的一处。K7-01 预测性热管理（导航/云端/驾驶意图协同） 的输入里有一项叫「一路来自车外或车内的前瞻信息」，它把这一路当成已经在车上了，然后讨论怎么用。本课做的事正是把那句「已经在车上了」展开成一条有耗时、有失效、有成本、有归属的链。⇒ 两课在同一个位置对接，接口就是三样东西：一个量、一个时间戳与有效期、一个置信度——这正是 K7-01 预测性热管理（导航/云端/驾驶意图协同） 5.1 要求的接口形态。

1.4 ⛔ 符号先钉死：本课有三个符号与前置课形近而义不同

是什么。这一节必须放在全课最前面，否则读过 K7-01 预测性热管理（导航/云端/驾驶意图协同） 与 N6-04 热管理 × AI 全景图：什么时候该上、什么时候不该，以及各类应用各自会怎么失效 的人会在第 4 讲踩坑。先立表：

时间量（全部单位 s，架构层）

符号	它是什么	⚠ 与谁形近
T_avail	可用提前量：从「此刻」到 ETA 给出的到达时刻之间还剩多长	与 K7-01 预测性热管理（导航/云端/驾驶意图协同） 的 t_lead 不是同一个量，见下方钉子
T_data	数据侧耗时：外部数据在源头生成 → 车端可用（含源头生成周期、API 调用与排队、云端融合、下发与网关排队）	—
T_proc	处理侧耗时：数据在车端可用 → 决策产出（含意图判定、置信度评估、目标计算）	—
T_exec	执行侧耗时：决策产出 → 预处理动作完成到位	对应 K7-01 预测性热管理（导航/云端/驾驶意图协同） 的 Δt_precon 加上它那两笔死区 τ_transport 与 θ_info
T_margin	时序余量 ＝ T_avail − (T_data + T_proc + T_exec)	⚠ 与 N6-04 热管理 × AI 全景图：什么时候该上、什么时候不该，以及各类应用各自会怎么失效 的 ΔT_margin 完全不是一回事，见下方钉子

无量纲量

符号	它是什么
P_e2e	端到端链路可用率，＝ ∏ᵢ P_i，取值在 0～1；⛔ 它不是功率
P_i	第 i 个环节的可用率，取值在 0～1
A_V2X	V2X 有效覆盖 ＝ c_RSU × p_veh × i_proto
c_RSU	路侧单元覆盖率 · p_veh 车端渗透率 · i_proto 协议互通率
Cov	意图识别覆盖率：给出了判定的行程数 ÷ 总行程数
Acc	意图识别条件准确率：在给出了判定的那些行程里，判对的比例

模型参数

符号	它是什么
θ_k	第 k 个节点本地训练得到的模型参数向量
θ_global	云端聚合后的全局参数向量
n_k / n	第 k 个节点的样本数 / 全体样本数

★★ 三根钉子，本课全篇照此读写：

钉子一：T_avail ⛔ 不是 K7-01 预测性热管理（导航/云端/驾驶意图协同） 的 t_lead。K7-01 预测性热管理（导航/云端/驾驶意图协同） 把 t_lead 定义为 t_arrival − t_precon，即「预处理实际获得的那段提前量」，它是反推之后的结果。本课的 T_avail 是「从此刻算，还剩多少时间可用」，它是反推之前的输入。⇒ 两者量纲相同、含义相反方向：一个是已经拿到的，一个是可以争取的。⛔ 不得互相代入。这也是本课不写 T_lead 这个符号的原因——写了必然被读成 t_lead 的大写体。

钉子二：本课 ⛔ 不使用 t_precon 这个符号。K7-01 预测性热管理（导航/云端/驾驶意图协同） 的 t_precon 是一个时刻（预处理启动时刻），而本课要说的是一段时长（执行耗时）。同名不同类型是最难查出来的一种错——量纲对不上时公式还能写得出来，只是意思全变了。⇒ 本课那段时长一律写 T_exec。

钉子三：T_margin ⛔ 不是 N6-04 热管理 × AI 全景图：什么时候该上、什么时候不该，以及各类应用各自会怎么失效 的 ΔT_margin。后者是可用温差裕度，单位 K，只进那门课的收益上限账 Q_shift ≤ C_eff·ΔT_margin。本课的 T_margin 是时序余量，单位 s。两者量纲不同、所属账不同，⛔ 不得互相代入，也⛔ 不得放在同一个式子里。⚠ 另外希腊字母 θ 在本课指模型参数向量（θ_global、θ_k），而 K7-01 预测性热管理（导航/云端/驾驶意图协同） 的 θ_info 是信息侧滞后（单位 s）——只是同一个字母，⛔ 没有任何关系。

易错点。① 看到 P 就当功率。P_e2e 与 P_i 都是可用率，无量纲、取值 0～1；本课凡是功率一律写全（P_pile、P_heat 等）并在当地标明。② 把 T_exec 当成「压缩机开起来到吹出冷风」那一段。它是完整的执行耗时，含 K7-01 预测性热管理（导航/云端/驾驶意图协同） 的输运纯滞后 τ_transport 与信息侧滞后 θ_info——后者尤其容易漏，因为它不在热路上。③ 把本课的 T_margin 与 K7-01 预测性热管理（导航/云端/驾驶意图协同） 第 4 讲的反推混为一笔账。K7-01 预测性热管理（导航/云端/驾驶意图协同） 算的是「该几点开始动手」，本课算的是「这条链路撑不撑得起这个提前量」——同一件事的两个不同层次，4.1 会把这两笔账并排放一次。

---

1.5 本讲收口：把一句「云端会给我们数据」拆成一张可评审的表

是什么。本讲的全部价值可以压成一个动作：下次听到「云端会给我们数据」这句话，把它展开成四层、两个方向、一个交接点。展开之后，评审上能问出来的问题就从「模型准不准」变成了六个具体的问题——而这六个问题正好是后面五讲：

1. 这一路数据是谁产生的、多久产生一次、我拿到它要多久？（第 2 讲）
2. 这一路的可用性怎么样，它出问题时长什么样？（第 2 讲 + 第 4 讲）
3. 我要判断的是「会不会按这条路走」，这件事的判定准确率和覆盖率各是多少，工作点选在哪？（第 3 讲）
4. 整条链加起来来不来得及、稳不稳？（第 4 讲）
5. 这些数据涉不涉及个人信息、涉不涉及重要数据识别与出境评估？（第 5 讲）
6. L3 这一层，我自己建还是买？（第 6 讲）

算例 1-2（教学假设值，⛔ 不对应任何平台）：轮询与推送在上行侧差多少。

接续算例 1-1 的场景。桩状态那一路，两种接法：

• 接法甲 · 轮询：车端（或云端代车端）每 30 s 向桩网 API 拉一次。每次请求含请求头与鉴权信息，按 0.4 kB 计。日联网 7200 s ⇒ 7200/30 ＝ 240 次请求，上行请求字节 ＝ 240 × 0.4 ＝ 96 kB/日/车。
• 接法乙 · 推送（订阅）：车端订阅一次，之后由桩网在状态变化时推送。假设一次行程订阅 1 次、每日 3 次行程，每次订阅请求 0.4 kB ⇒ 上行请求字节 ＝ 3 × 0.4 ＝ 1.2 kB/日/车。

⇒ 单这一路，轮询比推送在上行侧多出 94.8 kB/日/车；对照算例 1-1 里下行总量 282 kB，一路数据的轮询开销就相当于全部下行数据量的三分之一。而如果按「下行 0.5 kB/次 × 60 次 ＝ 30 kB」去看，这一路在下行账上看起来是最小的一路。

★ 这个算例真正说明的事：一路数据源在下行账上的分量，与它在整条链上的真实开销，可以差一个量级，而差的那部分全在上行侧。⇒ 第 2 讲的评估卡里，「推送还是轮询」是必填的一格，⛔ 不是实现细节。

⚠ ⛔ 不得由本例推出「推送总是更好」：推送要求供应方支持长连接或回调，它把复杂度移到了连接保活与消息可靠性上（消息丢了没有重试机会，而轮询天然自带重试）。⇒ 这是一个权衡，两种接法的失效形态不同，第 4 讲会再碰一次。

易错点。① 只在下行账上比较数据源的「轻重」。本例已经给了反例。② 把订阅当成零成本。长连接的保活心跳本身有字节，弱网下重连更是频繁；本例为了突出结构把它略去了，实际做预算时必须计入（算法归 K7-04 车队数据回流的车端实现：信号表定义、事件抓帧与带宽/存储预算）。③ 把「每 30 s 拉一次」直接当成「数据新鲜度是 30 s」。拉取周期只是你这一端的动作频率，数据的真实新鲜度由源头生成周期决定——源头 5 min 才更新一次，你拉得再勤也没用，只是白白消耗上行字节。这一条是第 2 讲 2.1 要把「更新周期」与「拉取周期」分成两格的原因。

本讲小结。四层里 L3 与 L4 必须分开，因为一个可改一个只能选；上行必须画出来，因为它是同一条通道上的另一半负载，而且是模型迭代唯一的证据来源；本课与 K7-01 预测性热管理（导航/云端/驾驶意图协同） 在「车上拿到一份带置信度的前瞻信息」这个点交接，接口是量、时间戳与有效期、置信度三样；三个形近符号在 1.4 钉死——T_avail ≠ t_lead、本课不写 t_precon、T_margin ≠ ΔT_margin。