D3-04 低温预热与出行预约热管理

课程代码 D3-04 · 板块 D 电池热管理 BTMS / 低温加热与保温 时长 约 3.5 小时（6 讲） 前置 D3-01 电池加热策略：PTC / 热泵 / 液热；D3-03 电池包保温设计与静置热损；K3-03 电池温控策略（加热/冷却/保温切换） 本讲义定位 讲师授课蓝本 / 学员自学讲义，是 D3-04 大纲的完整展开版

---

引言：同一份热，取自哪一侧、在哪个时段，决定了它记在哪本账上

一月的清晨，气温在零下。一位用户前一晚设了预约出行，到点上车，暖风还没出来、仪表上的功率条也压着；另一位用户插了一夜的交流慢充，早上出门发现 SOC 反而比睡前更低。这两张售后单上多半会被归成同一类——「预热不好用」，而它们的真因分别落在本课的两端：前一件是时序算错了，后一件是能量与功率的账算错了。两件事都不是加热器不够强，也不是保温做得不好。

加热方式与加热器能力那一层的结论在 D3-01 电池加热策略：PTC / 热泵 / 液热，整包的静置降温常数 τ 与传热系数与面积之积 UA 的测法在 D3-03 电池包保温设计与静置热损，加热/冷却/保温的模式切换总策略在 K3-03 电池温控策略（加热/冷却/保温切换）。到本课手上时，硬件已经选完、模型参数已经有了来源，剩下的问题只有五句话：什么时候开、用谁的电、加到几度、能不能动，再加上一句最常被忘掉的——没做成的时候怎么告诉用户。这五句合起来就是预热的调度学，本课交的就是它；⛔ 不交加热硬件选型、不交保温设计、不交上电许可判据、不交静置期的热安全监控（十三条分界在第 1 讲逐条写死，不在这里预支）。

钉子①（能量层）：预热的成本不取决于加了多少热，取决于这份热是在哪个时段、从哪一侧取的电。把电池从起始温度 T_0 升到目标温度 T_target，物理上要灌进去的那份热是同一份；而它记在哪本账上截然不同——插枪时段取桩的电，账记在充电时长与电费上；离网时段取电池的电，账按同温同工况的百公里电耗直接折成里程扣掉；行驶中到桩预热则可以先花电机与电控本来就要被散掉的余热，边际成本最低，但可用量随工况变，⛔ 它不是一份恒定可得的免费热源。三笔账对应的用户可感知量分别是「充电要等多久」「表显里程掉多少」「几乎无感」。⇒ 这一条直接决定整门课的动作方向：如果成本只由热量大小决定，工程动作就是把加热做得更省（提保温、提加热效率）；而事实是同一份热换个时段取，代价就换了一本账，于是正确动作变成把这份热搬到有外部电或有废热的时段——预约出行、远程唤醒、到桩预热这些功能存在的全部理由都在这里。⚠ 两种最常见的反应都是错的：一是把「省电」当成预热的目标函数，把力气全花在抠加热效率上，收益上限被自己锁死；二是以为搬了时段就万事大吉——搬到插枪时段之后代价并没有消失，只是从里程换成了充电时长，而这正是下面那条最容易被读反的话。

钉子②（时序层）：预热是一道带硬截止时刻的开环预测题——启动时刻必须在信息最少的那一刻定死，而它依赖的每一个量都是预测量，没有一个是当场能测的。反推式 t_start = t_target − Δt_heat − t_margin 看起来只是一条减法，实际上在 t_start 那一刻就要求出全部三项：此时车是冷的、停着的、可能还没上高压，唯一能测的只有当前状态。三项各有各的毛病：t_target 会漂（用户改主意、预计到达时间变、桩被占）；Δt_heat 依赖预测的初温 T_0，以及随时可能被座舱、12V 侧或桩侧改写的可用加热功率；t_margin 里混着两种性质完全不同的东西——可测可标定的链路确定性耗时（唤醒、上电、通信往返、加热器起效，⚠ 它不为零，⛔ 不许在反推式里当零处理）与只能靠余量对付的模型不确定度。而加热一旦开始，能纠偏的手段只剩「加大功率」与「延后目标」两条：前者受硬件与功率预算限制，后者根本不由控制器决定。闭环控制可以靠反馈吃掉模型误差，开环截止时刻问题不行，它只能靠预测精度 + 分层裕量 + 失效兜底三件事共同兜住。⇒ 所以本课的交付物不是一条升温曲线，是四件东西：① 三个场景各自的触发条件、目标温度与退出条件，写成可标定的状态机；② 分层的 t_margin——哪一段是确定性耗时、哪一段是裕量，各自怎么来、各自怎么收敛；③ 三笔能量来源的账（电驱余热 / 桩电 / 电池电，另加一条方向相反的收益侧）与来源优先级规则；④ 三层前置条件清单与八条失效兜底路径。四件里少任何一件，策略都能跑起来，也都能在冬天的某个早晨把用户晾在零下的车里。

★ 本课最容易被读反的一条，先在这里点破：「插枪时用的是桩的电，所以插枪预热是免费的」。这句话在能量账这一端近似成立——插枪时段的加热用的是外部电，不从电池取，因此对续航里程近似中性（它还要再加两条限定才严格成立，第 2 讲给）。危险在于它一旦被拿去指导插枪场景的加热功率与目标温度，方向恰好反了：插枪时真正稀缺的不是能量而是功率预算。P_charge + P_heat,el ≤ P_pile_max 是一道硬约束，每多给加热一份功率，就从充电功率里扣掉同样一份，于是插枪预热的代价不记在里程上，记在充电时长上——而用户对充电时长的感知比对续航更直接。⚠ 更要紧的是：存在这样一档桩，它协商到的可用功率与整车加热的电功率同量级、甚至更小（交流慢充是典型形态）。在这一档上按「桩电免费」把加热开满，净充电功率会趋近于零甚至为负，于是出现开头那个现场：插了一夜的枪，早上 SOC 比昨晚还低；而在桩功率远大于加热需求的一档上，同一条策略几乎没有代价。同一条策略，结论随桩功率档位翻转，而策略里往往一个字都没写这件事。⇒ 读者会做错的那个具体动作：在慢充桩或功率受限的桩上，把插枪场景的目标温度按快充窗口拉满、加热功率不设上限，理由是「反正用的是桩的电」。正确动作是把加热当成功率预算里的一个申请者——先向桩要预算（握手协商到的可用功率减去充电所需），再按剩余预算决定加热功率、决定是否把这份热推迟到出发前再加，⛔ 而不是把它当成一条不占预算的旁路。

⚠ 第二条容易读反的：「预热老是不够热，那就把 t_margin 加大」。裕量对偏差无效，而且它对另一侧是单调恶化的。t_margin 只对付离散——同一工况下每次都不一样的那部分；如果 Δt_heat 系统性偏短，那是偏差，最常见的两个真因是拿上次断电温度当初温，以及外温读数被地面与机舱余热带着爬升导致 T_0 预测偏高。偏差加多少裕量都只是被掩盖住：分布整体平移了，同样比例的样本仍然偏在同一侧；而每加一分裕量就多烧一分漏热，并把「提前达标后干等」的那一段拉长，还要吃掉唤醒次数配额与驻车能耗额度。⇒ 正确动作是先分离偏差与离散：偏差回去修 T_0 预测与 UA、τ 的标定，裕量只留给离散。⚠ 这一条不发作在写反推式的时候，它发作在标定台架上一次次调不准之后——那时候手边最顺手的旋钮恰好就是裕量。

最后是全课的读法约定，先立后用。① 加热功率有两个量，⛔ 全课禁止裸写 P_heat：P_heat,th 是进入电池的热功率（进 Δt_heat 的分母），P_heat,el 是从桩或电池取走的电功率（进桩功率预算式），两者之间隔着一整条加热链路，互算的后果是双向的且两个方向都错在不安全侧（第 3 讲分列并给出各自的定义与单位）。② T_target 与 T_min 是两个量：前者是本次预热要达到的目标（按场景取三档之一），后者是目标函数里不可越的可行域下界，⛔ 不得互换。③ 温度一律写 ℃、温差一律写 K，⛔ 不在同一式中混用。④ 本课的绝大多数量是平台相关量，一律不给数——三档目标温度、τ 与 UA、加热功率、桩功率、各类时长与 SOC 门槛都须由本项目实测与标定确定；正文不给，图上同样不给（包括刻度值与门槛竖线的位置），凡是画出来的判据一律用无量纲比表达。⚠ 「不给数」在本课是结论不是回避：一个抄来的门槛比没有门槛更危险，因为它看起来是可以直接拿去验收的。⑤ t_ref 是每张图各自的横轴归一化分母，⛔ 不是全课统一的一个量、⛔ 不得跨图搬用——它的定义写在该图自己的轴标题或图内口径行上，全课用到它的三处各不相同：图3 的 t_ref ＝ 从起加热到回路出水温首次到达目标带下沿的时间；图15 的 t_ref ＝ 曲线 A 首次到达 T_target 的时间；图19 的 t_ref ＝ 该图示意集总模型的热惯性时间常数 τ（归一化后取 1，示意选取）。⚠ 三者同名不同义，与上面 P_heat、T_target/T_min 两条纪律同理：读第 3 讲时 ⛔ 不得把第 1 讲那个定义原样带过去，读任何一张图前先看它自己的轴标题。

全课六讲就按这条主干排：第 1 讲把三个场景解的三道不同的题分开，把目标温度分成三级并钉死按哪个测点判，再把触发源的全集与本课的射程边界画出来；第 2 讲算三笔能量来源的账，落在桩功率预算这道硬约束与离网预热的 SOC 门槛上；第 3 讲把反推式三项拆开，讲初温预测、集总式的失效边界与 t_margin 的分层；第 4 讲回答「能不能动」——三层前置条件的判定顺序、安全一票否决，以及电池与座舱两侧口径不同的优先级；第 5 讲写远控与预约的接口契约：并发语义、结果的多态回传与过期预约的补执行；第 6 讲收在演进与验证上——到桩预热怎么从规则表走到更强的实现，寿命账怎么与充电时长收益分开记，以及验证手段的全集。最后的动手做要你交出三样东西：三个场景的状态机 · 一次初温预测与启动时刻反推 · 一版离网与插枪的能耗对比及硬约束清单；这三样凑齐了，才算一版能拿去评审的预热策略，而它们正好把两根钉子各验一遍。

第 1 讲　三个场景与各自的目标温度：预热在解的不是同一道题

「预热」这两个字听上去只有一个动作：把电池加热到某个温度。可一旦落到车上，你面对的其实是三道不同的题——车插在枪上停在车库里、明早八点要出门用车、正在高速上往超充站开。三者用的是同一套加热硬件、同一条液路、同一个加热器，却有三个不同的截止时刻、三条不同的能量来源、三种不同的失败样子。把它们塞进同一条逻辑里，是这门课里代价最高、也最常见的第一步错。

这一讲做五件事：把三个场景按「截止时刻从哪来、能量从哪来、失败了会怎样」摆开；把「加到几度」这个看似最简单的问题问到底——目标温度不是一个数，是三条各有出处的线；再往下追一层，问「按哪个测点判达标」；然后把触发源的全集画出来，看清按常见的三场景枚举会整类漏掉什么；最后把每一条触发的出口封死，并写清本课的射程边界。

1.1 三个场景的截止时刻分别来自设备、人与路况——⛔ 一套触发与退出条件覆盖不了三者

比较三个场景，看的不该是它们「叫什么」，而是四件事：截止时刻从哪来、能量从哪来、失败了是什么样子、中途还能不能改主意。

场景 A　插枪静置。车插在枪上，人不在。它的截止时刻由充电会话给出——目标是充电真正开始的那一刻，电池已经落在允许功率窗口里。能量来自桩。失败的样子是充电开始后有相当长一段时间功率被压得很低，用户看到的是「这桩怎么这么慢」。

场景 B　预约出行 / 远程唤醒。它的截止时刻由用户设定的出发时刻给出。能量来自电池；如果此刻恰好插着枪，则来自桩。失败的样子最直接——用户上车即感知：没有动力性能，也没有暖风。

场景 C　行驶中到桩预热。它的截止时刻由预计到达时间给出。能量来自电驱余热加电池电。失败分两种，方向相反：没热够，到桩后被限功率；热过头，白耗了路上的电。

把三者并排看，一件事会立刻跳出来：三个截止时刻分别来自「设备」「人」「路况」，可预测性依次下降。充电会话的开始时刻几乎完全在整车自己掌控之内；用户设定的出发时刻会被临时改；而预计到达时间在整个行程中每一秒都在变——导航改路线、路况突变、桩被占用，任何一件都会把它推走。

⇒ 三者需要的裕量结构完全不同。把三者写成一套触发与退出条件，等于用最不可靠那一路的裕量去伺候最可靠那一路（于是场景 A 天天早早开始加热、白烧漏热），或者反过来（于是场景 C 一遇 ETA 变化就整体不达标）。这不是「多写几个分支麻烦」的问题，是把一个可以做准的场景和一个做不准的场景绑在了同一个旋钮上，此后无论怎么调都有一侧是错的。

⚠ 本节到此一个时刻值、一个温度值都没有给，也不会给——三个场景的时长与目标温度全部是平台相关量，须按本平台实测与标定确定。本节交付的是结构差异，不是数。

两个常见的错法，值得单独点出来：

• 把场景 C 当成场景 B 的变体，以为只是「换了个触发条件」。后果是整条重规划路径在设计阶段就整类不存在——ETA 一变，策略没有任何动作可做，只能一路加热到底。C 与 B 的区别不在触发，在截止时刻会不会自己动。
• 把场景 A 的目标写成「加到某个舒适温度」。A 的目标根本不是暖——车上没有人，暖给谁看。A 的目标是进功率窗口，这一条在 1.2 里展开。

1.2 目标温度分三级，且三条线各由不同的体系给出——⛔ 一刀切不是过度加热就是不达标

「加到几度」是预热策略里被问得最多、也被答得最草率的一个问题。草率之处在于：多数需求文档给出的是一个数，而实际存在的是三条线，且三条线的出处彼此无关。

• 能放电——由电池管理侧的低温放电功率限制给出。低于这条线，车动不了，或者动力明显受限。
• 能满功率快充——由充电功率 map 给出。它是温度的函数（1.2 后半段会看到它还不止是温度的函数）。
• 用户体验最优——由整车标定给出，里面混着座舱采暖需求和用户对起步动力的主观感受。

三条线属于三个不同的判据体系，只是恰好都用温度表达。这是本节的题眼：它们长得像同一个量，实际分别归三个人管。

一刀切会在两个方向上各错一次。取最高那条：离网场景白白多花电，而且把电池长时间放在偏高的温度附近，寿命账那一侧要付钱（第 6 讲展开）。取最低那条：快充场景到桩就被限功率，整个到桩预热功能白做——热是加了，功能没有兑现。

⇒ 目标温度必须是场景的函数，写进状态机的每一个分支，而不是一张全局标定表里的一个格子。

⛔ 三档的取值本课一律不给：它们由电池体系、充电功率 map 与整车标定共同决定，是平台相关量，须由本项目实测与标定确定。⛔ 也不要把它们之间的差写成某个倍数或数量级——两侧都是本课不给数的量，用两个自己不肯给的数去支撑一个比较，得到的结论是空的。本课能给的定量关系只有次序：能放电 < 能满功率快充 < 用户体验最优。

三个易错点：

• 把「能放电」当成「能快充」。这两条线不是一回事，据此设计的到桩预热会整体不达标——策略以为自己热够了，桩那边照旧限功率。
• 把三档写成一张固定的标定表，却不写它们各自的来源。下一代平台换了电池体系，没有人知道该改哪一档、按什么改。表里的数会被原样抄过去，然后在新平台上默默地错。
• 用同一个温度门限同时管进入与退出，于是在门限附近反复起停。正确做法是设迟滞，而迟滞值本身也是要标定的量，不是随手给一个小数。

场景 A 的目标温度是查出来的，不是标定出来的一个数。接着 1.1 那句「A 的目标不是暖」往下说：插枪静置预热真正要交付的是「充电开始时，充电功率 map 允许的功率已经足够高」。而这张 map 通常至少是温度与 SOC 的二维函数（部分平台还含 SOH 维），因此同一个温度在不同 SOC 下对应的可用功率并不相同。

⇒ 场景 A 的目标温度必须按本次充电的起始 SOC 去 map 上反查得到。反查的方向是固定的：从「本次充电希望达到的功率」出发，在 map 上反查所需温度，把它作为 T_target 送进第 3 讲的启动时刻反推式。

把它简化成一个温度阈值，会在两端各错一次：高 SOC 起充时其实不需要加到那么热（充电功率本来就被 SOC 限着），白花桩电、白占充电时长；低 SOC 起充时那个阈值又可能根本不够。

⛔ 充电功率 map 的内容与目标温度一律不给数——它由电池管理侧给出，是平台相关量。本课给的是反查方向与「它是二维的」这个结构。三个易错点：① 用放电侧的低温门限当充电侧目标；② 忽略 SOC 这一维，导致高 SOC 起充时过度加热；③ 以为把电池加到窗口内、充电功率就一定上得去——功率还受桩侧、线缆与整车其它限制，温度只是必要条件之一。

场景 C 的目标温度是双侧有界的。到桩预热的正确终点是「在到达那一刻恰好落进快充窗口」，而不是越早越热越好。提前热到、然后在路上继续保温，多花的是离网电，直接从里程里扣；热过头则可能顶到充电功率 map 的高温侧限制，出现「加热加到被限流」的反效果。

这一条把 C 与 A、B 区分开：A 与 B 的目标是「达标即可，多了只是浪费」，而 C 的目标温度有下界也有上界——下界由快充窗口给出，上界由高温侧限流与寿命约束给出（寿命那一侧见第 6 讲）。有上界，就意味着 C 必须能重规划：ETA 变了要能加速、能减速，必要时中止，而不是一次算完执行到底。

⛔ 上界与下界的具体温度不给（由充电功率 map 的两侧给出，平台相关量）。三个易错点：① 把 C 做成「一旦触发就全功率加热直到到桩」，ETA 一变就热过头；② 只用余热就不设上限——余热在低温高速工况下可能持续供给，照样会把温度顶上去；③ 把「到桩即满功率」理解成「到桩即最高温度」，两者不是一回事，满功率对应的是窗口，不是极值。

1.3 「加热到 T_target」必须写明按哪个测点判——三个测点给出三个停机时刻

目标温度定完了，还剩一个问题没答：按哪个测点判达标。这个问题在需求文档里常常整句缺席，而它的后果比选错档位更隐蔽。

同一句「加热到 T_target」，按单体最低温判、按包平均温判、按回路出水温判，得到的实际停机时刻完全不同。原因是热的来路：液热或板式加热是从冷板与液路侧进热，这份热要穿过导热路径才到芯体。于是在加热过程中，出水温最高、包平均温居中、单体最低温最低，而三者之间的差恰恰在低温预热工况下达到全程最大——包越冷、进热越猛，这个差越大。

⚠ 这条方向结论有射程：它只在「从液路侧进热」这一类加热方式下成立。⛔ 不得反向套到从芯体侧自产热的场景（例如自加热或大电流脉冲加热）——那时热是从内部生出来的，三者的次序不再是这一个。加热方式本身管在 D3-01 电池加热策略：PTC / 热泵 / 液热。

★ 本课在这里归纳一条口径判据（它不是任何标准的条文，也不是从上游课直接搬来的结论）：目标温度的判据测点，必须与下游充电功率 map 的输入测点是同一个。这句话要写死在交付物里，而不是留给实现去猜。

不这样做的后果，是低温预热里最隐蔽的一类失效。低温下限制充电功率的是最冷的那只单体，因此充电功率 map 的输入侧常取单体最低温；而策略若用出水温判达标——它响应最快、最好看，也总是最先到——就会出现「策略认为已达标、电池管理侧认为仍在低温档」的系统性错配。现场表现是：预热跑完了，快充还是被限功率。没有故障码、没有超时、所有信号看起来都正常，只是没用。⚠ 本平台到底取哪个测点，必须去核实，⛔ 不得默认——本课要求的是两侧同测点，不是替你指定某一个测点。

⛔ 三个测点之间温差的任何数值本课不给：它取决于加热方式、冷板结构、流量与保温，是平台相关量，须由本项目实测。

三个易错点：① 用出水温判达标——它最先到，看起来最漂亮；② 用包平均温判达标，却把最低温的那只单体留在窗口外，而限功率的正是它；③ 以为「预热之后包内温差自然会均匀」——均匀化需要额外时间，那段时间也要计入 Δt_heat，它不是免费的。

1.4 触发源不止这三个场景：按「车此刻在哪」数，会整类漏掉

到这里我们数出了三个场景。现在停下来问两句话——这两句话是本课后面每一个全集都要先问的：① 我刚才是沿什么线索数的？② 有没有不在这条线索上、却同属这个集合的？

第一问的答案是：三个场景是按「车此刻在哪」排的——插着枪 / 停着待发 / 正在路上。凡是不落在「车的位置」这条轴上的触发源，在这条线索上会整类不出现，而且清单看起来还是完整的。

第二问的答案是六整类。把九类一起列出来（编号与本讲后面、以及配图上的编号一致，⛔ 不要重排）：

沿「车此刻在哪」数出的三支：① 插枪静置预热；② 预约出行与远程唤醒预热；③ 行驶中到桩预热。

不在这条线索上、却同属「谁会请求加热」这个集合的六整类（★ 这六类是本课归纳补齐的）：

• ④ 非用户触发的自动预热——车辆按学习到的出行规律自行发起，没有任何显式预约动作。它属于「非需求驱动」的一整类，最容易在需求文档里整类缺席。
• ⑤ 电池自保护类加热请求——低温下为保证放电功率、或为抑制低温析锂风险，由电池管理侧发起。它的目的不是用户体验而是保护，因此优先级与退出条件都与 ①②③ 不同。
• ⑥ 为恢复能量回收能力而加热——低温下回收受限，长下坡或高速工况前把电池拉进可回收窗口，收益记在回收电量上，不记在充电时长上。
• ⑦ 充电过程中的补热与保温——它不是预热，但共用同一套功率预算与仲裁逻辑。
• ⑧ 服务与工厂模式的强制加热——诊断仪或产线工位触发，绕过部分用户侧前置条件。
• ⑨ 系统耦合触发——热泵在极低温下需要电池侧余热做低温热源，或整车为别的目的要求电池升温。

为什么 ④ 值得单独加粗。这类触发在需求文档里缺席，后果不是「少一个功能」，而是默认行为未定义：它同样要占 SOC、占唤醒次数配额、占驻车能耗额度。一旦某个版本的云端策略把它打开，前面所有按「只有三个场景」设计的配额与仲裁全部失效，而现场表现是「车停了一夜莫名其妙掉电」，查不到任何人下过指令。⇒ ⛔ 未列入的触发源不得默认当成不存在——不存在的东西不会被测试覆盖，而它会照样发生。「本平台暂不做自动预热」这个决定，正确的写法是在表里显式占一行并写明为何禁用，不是把这一行删掉。

逐项核射程：①②③④ 在本课射程内（④ 要讲清它的授权、可退出与能量额度）；⑤⑥ 本课只给类型与去向——加热硬件与加热请求的生成去 D3-01 电池加热策略：PTC / 热泵 / 液热，低温析锂机理去 D1-01 动力电池产热机理与产热速率建模；⑦ 去 D4-03 充电过程温控策略与充电功率协同，充满静置那一侧去 D5-06 充电与充满静置工况的电池热安全应急响应与桩车联动；⑧⑨ 只给类型与去向。

⛔ 唤醒次数配额与驻车能耗额度的任何数值本课不给——它们的属主在 K3-11 热管理域的上下电时序、run-on 编排与休眠期能耗预算 与 C6-05 暴晒后快速降温专项设计，本课只把「够 / 不够」这个结论当作输入用。

两个易错点：① 把「本平台暂不做」当成「不用为它留位置」（上面已说，留位置才是防线）；② 把电池自保护类请求与用户请求塞进同一条优先级链——于是用户的一个取消动作就能把保护请求关掉。

1.5 触发条件与退出条件必须成对定义：四个出口缺一，「加热中」就是吸收态

九类触发源列完了，还差另一半。只写「什么时候开」而不写「什么时候必须停」，等于把一个能烧到天亮的加热器交给一条没有下限的逻辑。

每一条预热触发，都必须同时给出四件事：

1. 触发条件——什么情况下这条触发成立；
2. 目标——达标判据，以及 1.3 里那个必须写明的判据测点；
3. 正常退出条件——达标之后停机还是转保温（两者的能量账不同）；
4. 异常退出条件——超时、前置条件在执行中失守、用户取消、能量额度耗尽。

★ 把它们归并成「一个正常出口 + 三类异常出口」这四个出口，是本课归纳的一种写法（不是某个标准的要求）；它的用处是给出一个可以当场执行的检查动作：拿任何一条触发去状态机图上找它的四个出口，找不齐就是缺陷。⛔ 四件缺一，状态机里就有一个吸收态——进得去，出不来。

为什么预热对这件事格外苛刻？因为它的执行环境是「无人、长时间、可能在密闭空间」。这与行车中的热管理动作有本质区别：行车时有人在旁边看着，而且下一个驾驶动作（换挡、下电、拔枪）迟早会自然打断它；预热没有这样的自然终点。⇒ 正常退出与异常退出都必须是显式写出的状态迁移，而不是指望某个别的模块恰好把它关掉。

⛔ 超时阈值与能量额度是平台相关量，本课一个数都不给；超时的三个计时起点各管哪一类失效、怎么分档，在第 4 讲展开。密闭空间与「无人在车时热管理能不能自主动作」的通用原则去 C6-04 智能座舱：人员感知与按需送风（露营/休息模式）。

三个易错点：

• 只写「达到目标温度后停止」，漏掉「永远达不到目标温度」这一支。环境过冷、或加热功率被别处限走时，这一支就成立——第 3 讲会说明它在数学上是「方程无解」，而程序照样能算出一个时刻然后一直加热下去。
• 把退出条件写在别的模块里，比如靠整车休眠逻辑顺带关掉。那个模块改一次版本，预热就再也停不下来，而改它的人完全不知道自己动了谁。
• 达标即停机而不写迟滞，于是在门限附近反复起停——每一次起停都要唤醒、上电、通信，配额就是这么被吃掉的。

1.6 本课交什么、不交什么：先把射程边界写死

这一讲的最后一节不讲预热本身，讲边界。原因很实际：本课的每一条判断都建立在别门课的结论之上——加热功率、UA 与 τ、上电许可、充电功率窗口、座舱侧的判据，没有一样是本课自己核出来的。边界不划死，会出现两种坏结果：要么整段重讲别课已经在讲的内容，要么把别课的结论当成本课自己核过的数用出去——后者更贵，因为读者会拿它当验收依据。

★ 下面这张分界表是本课自建的边界声明（这一层在课程体系里原本是空的，本课在自己的射程内把它补上）。⚠ 它十三行，是本课边界的全集——⛔ 凡本课正文反复依赖的相邻课都必须在表里占一行，末两行（C6-01 双区/四区自动空调控制逻辑 与 B3-03 二次回路 vs 直接回路架构对比）正是按这条自检补进来的。表里对每一门相邻课只写两件事：本课向它要什么结论、本课不重讲什么。⚠ ⛔ 一律不写「某某课已经讲透了 X」——那是一句本课没有核过的话。

相邻课	本课向它要什么结论	本课不重讲什么
D3-01 电池加热策略：PTC / 热泵 / 液热	加热方式与加热器能力（含加热链路效率的量级形态）	加热器选型与硬件方案
D3-03 电池包保温设计与静置热损	整包 UA 与热时间常数 τ 的定义与取值	保温结构设计与静置热损的测法
K3-03 电池温控策略（加热/冷却/保温切换）	加热 / 冷却 / 保温的模式切换总策略	模式仲裁的总体框架
K3-11 热管理域的上下电时序、run-on 编排与休眠期能耗预算	上电许可的结论（准 / 不准）与唤醒次数配额、暗电流额度的「够 / 不够」结论；以及唤醒与上电这条链路的耗时（进 t_margin 的确定性那一层）	上电许可的判据本身、唤醒源清单、上电许可怎么裁决、配额怎么定
K2-06 热管理低压供电边界：DCDC 容量、多执行器同时率与 12V 能量保底	低压侧能量边界与 DCDC 容量的结论	12V 能量账本身
G12-03 执行器硬件接口与电气规格 · K1-02 执行器驱动：电子阀/泵/风扇/压缩机 PWM	高压上电四步链与执行器驱动的耗时结论（进第 3 讲的链路耗时）	上电四步链与驱动电路本体
C6-04 智能座舱：人员感知与按需送风（露营/休息模式）	无人在车时热管理能不能自主动作、能动多久的通用原则	该原则的推导与人员感知实现
C6-05 暴晒后快速降温专项设计	唤醒时序与驻车能耗预算	预算怎么分、唤醒怎么排
D4-03 充电过程温控策略与充电功率协同	充电过程中的温控与功率协同结论	充电过程本身的温控策略
D5-06 充电与充满静置工况的电池热安全应急响应与桩车联动	充电与充满静置工况的热安全应急响应	静置期的热安全监控
G12-04 座舱与空气侧传感器：外温/内温/日照/蒸发器温度的误差机理、布置与补偿	可信化后的外温读数，以及它的误差方向	传感器误差机理、布置与补偿方法
C6-01 双区/四区自动空调控制逻辑	座舱侧的达标判据（出风温度门槛、warm-up 抑制是否已解除）与抑制状态继承规则的结论（4.3 用）	座舱空调控制逻辑、继承规则本身怎么定
B3-03 二次回路 vs 直接回路架构对比	回路能不能把电驱余热引到电池侧、两侧是否共用热源这一架构输入（2.6、4.7、6.5 用）	回路架构本身的对比与选型

那么本课自己交什么？四件，都是别处没有的净新增：

1. 三个场景各自的触发条件、目标温度与退出条件，写成可标定的状态机；
2. 分层的 t_margin——哪一段是确定性耗时、哪一段是裕量，各自怎么来、各自怎么收敛（第 3 讲）；
3. 三笔能量来源的账（电驱余热 / 桩电 / 电池电，另加一条方向相反的收益侧）与来源优先级规则（第 2 讲）；
4. 三层前置条件清单与八条失效兜底路径（第 4 讲与第 5 讲）。

⛔ 边界之外不给限值——只给类型与去向。这一条要具体到什么程度？举个反例：读者问「12V 电量低到多少就不许预热」，本课的正确回答是「这个门槛的属主在 K2-06 热管理低压供电边界：DCDC 容量、多执行器同时率与 12V 能量保底 与 K3-11 热管理域的上下电时序、run-on 编排与休眠期能耗预算，本课只把它的判定结论当输入」，⛔ 而不是顺手给一个数。因为本课根本没有核过那个数，而一旦写下来，它就会被抄进某份验收表。

两个易错点：① 把前指写成「某课已讲透 X」，却没有核过那门课到底讲没讲——这句话是替别人做的承诺，本课没有资格做；② 在边界之外顺手给一个限值，理由通常是「读者总要有个数才好开工」。这个理由是真的，而正确的做法是把去向写清楚，让读者去有属主的地方拿数。

本讲小结：预热不是一个动作，是三道题——插枪静置、预约出行、到桩预热，它们的截止时刻分别来自设备、人与路况，可预测性依次下降，⛔ 一套触发与退出条件盖不住三者。「加到几度」不是一个数而是三条各有出处的线（能放电 < 能满功率快充 < 用户体验最优），且必须是场景的函数：场景 A 的目标要从充电功率 map 上按起始 SOC 反查，场景 C 的目标双侧有界因而必须能重规划。再往下一层，「加到 T_target」还要写明按哪个测点判——★ 本课归纳的口径判据是：判据测点必须与下游功率 map 的输入测点是同一个，否则会得到那类没有故障码、没有超时、只是没用的失效。触发源按「车此刻在哪」只数得出三支，全集是九类，其中非用户触发的自动预热最容易整类缺席；⛔ 未列入的触发源不得默认当成不存在。每一条触发都要配齐四个出口，缺一就是吸收态。最后，本课的射程只到「调度」为止：加热硬件、保温、上电许可、传感器补偿都在别门课，⛔ 边界之外只给去向、不给限值。下一讲进能量账——同一份热，取自桩、取自电池、取自余热，是三笔完全不同的账。