B4-04 整车能量管理与热管理的协同优化

课程代码 B4-04 · 板块 B 整车热管理系统架构 / B4 能量流与整车能效 时长 约 4 小时（5 讲 + 1 次优化算例） 适合对象 热管理系统 / 控制 / 能量管理工程师；做协调控制与预测性策略的人（专家级） 前置 B4-01 整车能量流与热量流协同分析；K3-01 控制策略总览与模式管理；J7-02 模型降阶（ROM）与控制导向建模 本讲义定位 讲师授课蓝本 / 学员自学讲义，是 B4-04 大纲的完整展开版

引言：热不是要立刻扑灭的火，是可以调度的负荷

大多数热管理策略的默认心智是「温度超了就开风扇、就上 PTC」——一个事后灭火的被动执行器。这套逻辑不会出安全事故，但它把一整块能量优化的空间白白扔掉了。

扔掉的是时间。热系统有惯性，温度不会瞬间跳变，这意味着一个热负荷可以被推迟——现在不加热、晚几分钟再加热，只要不越温度红线，结果一样。凡是能在时间上挪动而不违约的负荷，在能量管理里就是一块可调度的资源，和电网里的可延迟负荷（热水器、充电桩）是一回事。

这门课要做的思维转变，是把热管理从「能量流末端的执行器」提升成「能量管理里一块可被优化器调度的负荷」。要实现它，得把三样东西喂给优化器：热惯性（负荷能延迟多久）、余热可用性（哪里有免费的热可借）、路径先验（未来会发生什么），再用预测和全局最优把每一度电花在刀刃上。但优化器是复杂软件、会挂，所以在追求上限之前，必须先给它铺好一张「挂了也不会更坏」的安全网。这门课从头到尾都在这两件事之间走：既要把上限逼出来，又要把下限焊死。

第 1 讲　从被动响应到主动调度

被动到主动，不是加几行预判代码那么简单，它要求你先看清「哪里有调度空间、空间的边界在哪、这块空间归谁管」。这一讲把这三件事讲清楚。

1.1 热惯性 τ = m·c_p/(UA)：可调度空间从哪来

热惯性时间常数 τ = m·c_p/(UA) 是整门课的物理地基。分子 m·c_p 是这坨热质量的储热能力，分母 UA 是它和外界换热的通道能力（换热系数×面积）。τ 的物理含义是：给一个阶跃扰动后，温度大约走完到新平衡点约 63% 所需的时间。

关键在于怎么读这个数。τ 大，意味着温度变化慢、系统"迟钝"——通常工程师把迟钝当缺点，但在调度视角里，迟钝恰恰就是调度空间：温度变得慢，就说明你有一段时间可以不动作而系统不出格。电池包热质量巨大，τ 在分钟到几十分钟的量级（具体值随包体设计而定），所以电池是调度空间最大的负荷；而座舱空气热质量小、τ 小、响应快，可挪动的余地就小。τ 越大的负荷，越值得调度；τ 越小的负荷，越接近被动跟随。

这条也直接决定了后面所有事：预测视野要多长（第 4 讲）、控制步长可以多粗（第 2 讲），全都由 τ 定标。τ 是把「热的物理」翻译成「调度的语言」的那把尺。

1.2 哪些可调度，哪些是碰不得的硬约束

有了调度空间，下一步是分清空间的边界。可调度的手段有四类：预热（提前把冷的东西热起来）、预冷（提前把要发热的东西压下去）、蓄热（把余热存起来待用）、降额（临时牺牲一点功率能力，换热管理的喘息）。这四类都是在时间轴上腾挪。但其中「蓄热」有一个前提常被跳过：车上得真存在一个能存下该量级热、且放得出该功率的载体。蓄热是容量与功率两个指标同时受限的——一个能存下 1 kWh 热、却只放得出 1 kW 的载体，对一个需要 5 kW 的预热请求就等于不存在。所以可延迟余量的上限并不是由 τ 单独决定的，它还被蓄热体的定容卡着；载体全集（专用件如保温水箱、相变蓄热器，以及电池包热质量、冷却液回路、内饰这些「既有件」）与「到底加不加这块硬件」的判据，见 N4-03 车载蓄热与热量时移：蓄热体全集、容量/功率解耦定容与「加不加硬件」判据。

而碰不得的是硬约束：电池温度窗口（下界防析锂，上界防衰减与热失控）、与视野安全相关的除雾除霜（既是安全也是法规）、热失控红线。这里有一条必须钉死的原则——调度只能在硬约束留出的自由度里做，绝不能拿硬约束去换能量。这就引出了软硬之分：舒适度是软的（可以作为带权重的目标项，容许偏差），安全是硬的（必须写成约束，一步都不能越）。把这两者混为一谈，是第 2 讲之后反复要防的错误——优化器只认你写进约束的东西，你不写成硬约束，它就敢去动。

1.3 与 VCU / BMS / 座舱控制的接口与仲裁优先级

热优化器不是孤岛，它在整车里要和 VCU（整车控制）、BMS（电池管理）、座舱控制抢同一份东西——功率。当总可用功率受限时（冷电池限放电、快充限功率），谁先拿到瓦特？这就是功率仲裁。

仲裁必须有明确的优先级栈，从高到低大致是：热失控/安全底线 → 法规与安全相关的舒适（除雾） → 能量最优调度 → 纯舒适性锦上添花。这个顺序不是拍脑袋，它对应的正是 1.2 的软硬之分：硬约束占顶，软目标排在能量之后。接口上，热管理向 VCU 申请功率、VCU 分配，两边共用一张优先级契约。契约不清会出两种典型故障：要么死锁（谁都不让），要么震荡（功率在几个请求方之间来回甩）。所以协同优化的第一个工程动作，往往不是写优化器，而是把这张仲裁契约谈定。还要补一句边界：整车层给出的只是定性的优先级栈与「申请—分配」这套契约形态；栈内每一条请求的量化取值——申请功率多少 kW、紧迫度 urgency 怎么打分、可延迟窗口 t_defer 有多长、这条请求多久过期——属于控制层的输入契约，出处见 K3-01 整车热管理控制策略总览与模式管理。其中 t_defer 的物理依据正是 1.1 的 τ = m·c_p/(UA)：τ 决定了这个请求最多能被压多久而不出格。整车层定谁先谁后，控制层定各人报多少，两张表对不上，仲裁一样会震荡。

1.4 软件定义热管理：策略结构上车后靠 OTA 迭代

最后一条是开发范式的变化。传统热管理是一张冻结的标定表，上车即定终身。协同优化的做法是把结构（优化器、模型、约束框架）设计一次，把参数（权重、阈值、裕度）留成可标定、可 OTA 迭代的量。车队跑出来的数据回流，改进先验、改进权重，再 OTA 推下去。

这就是「软件定义热管理」：你交付的是一个能被调优的结构，而不是一张写死的查表。但这里有一道必须守的闸——对安全相关控制的 OTA 变更，要走功能安全治理（ISO 26262）。你不能随手推一个新权重，让优化器把电池饿到窗口边上。结构可迭代，安全边界不可迭代。这条和第 5 讲的降级安全网是同一套哲学的两个侧面。

本讲小结：调度空间来自热惯性 τ（τ 越大越可调度）；调度只能在硬约束的自由度里做，软（舒适）硬（安全）必须分清；热优化器要和 VCU/BMS 按优先级栈仲裁功率；结构可 OTA 迭代，但安全边界不可。