K3-11 热管理域的上下电时序、run-on 编排与休眠期能耗预算

课程代码 K3-11 · 板块 K 控制、软件与标定 / 控制策略与算法 时长 约 3.5~4.0 小时（8 讲） 前置 K3-01 整车热管理控制策略总览与模式管理；K2-02 CAN/LIN/CAN-FD 通信与整车 EEA 集成；K4-01 热管理嵌入式软件架构与 AUTOSAR 基础（推荐先读（非硬前置）；本课是它明确前指的语义侧，先读机制侧更省力）；K2-06 热管理低压供电边界：DCDC 容量、多执行器同时率与 12V 能量保底（推荐先读（非硬前置）；本课的 12V 账从它的运行期负载侧接过来） 本讲义定位 讲师授课蓝本 / 学员自学讲义，是 K3-11 大纲的完整展开版

---

引言：车关不干净，和车停不住，是同一道题的两端

一台车真正处在「行驶」这个状态的时间，比多数人以为的少得多：一天两次上下电，其余二十来个小时它都待在整车电源模式 Sleep、周期唤醒，以及上下电前后那几段还没有名字的过渡里。热功能模式机管的是中间那一段——什么时候开热泵、什么时候给电池加热、几路请求打架了怎么仲裁——这一段 K3-01 整车热管理控制策略总览与模式管理 已经交付。本课要接的是它的两端：从没有模式到有模式（上电），和从有模式到没有模式（下电、续跑与休眠）。

两端没有人统一编排，暴露出来是两类客诉，而它们在售后端长得完全不像同一个问题。一类是「车关不干净」：熄屏了泵还在转、用户不知道它要转多久；或者反过来，标定好的续跑时长根本没走完就被切断，防沸腾等于没做。另一类是「停几天打不着、App 也唤不醒」。本课交付三样东西把这两端接起来：一张含 Init / Shutdown / Sleep 三个端点态的电源模式迁移表、一张上电与下电的次序表（带超时列），以及一本按保活档位分档的静置安时账。

本课全部的时间量与电流量都是平台相关量，正文一律不给推荐值——这不是回避，是这门课的判据本来就不在「取多少」，而在这个数该从哪本账里取。这就是下面两根钉子。

钉子 1：每一个「多久」「几次」，最后都必须落进两本账里的某一格

第一本是安时账：Q_park ＝ Σ_k (I_k · t_k)，判据是 Q_park ≤ ΔDoD_allow · C_12V,EOL。其中 Q_park 是整段停放期间累计放出的电荷量（A·h），I_k 是第 k 个保活档位下的整车静置电流（A）、t_k 是该档的年均停放时长（h），C_12V,EOL 是 12V 蓄电池寿命末期的可用容量（A·h），ΔDoD_allow 是允许亏电深度（无量纲）。第二本是时间窗账：上电侧要 t_ready + t_margin ≤ T_ready_req（上电就绪时间加工程裕量，不得超过跨域握手给本域的就绪窗口，单位均为 s）；唤醒侧要 t_eff ≥ t_action_min（单次唤醒的有效窗口，不得小于这次唤醒真要做完的事所需的最短时长，单位均为 s）。

落不进任何一格的数，就是拍出来的。这一句直接决定三件事：

① 谁有权定 run-on 窗口总时长上限、哨兵允许时长、每日唤醒次数配额——不是各自的功能负责人，是这两本账。三者共享同一个安时余量，一项调宽必须另一项让出预算，配额是守恒的（这三个量的名字与量纲全课一套，第 7 讲 7.2 与第 8 讲 8.8 反推出的正是它们；⛔ 不写成「周期唤醒间隔」——那是它的倒数、量纲也不同）； ② 一次唤醒值不值——把寿命收益与唤醒能耗折算到同一量纲上再比（收益侧的老化—温度机理前指 D1-04 电池老化、寿命与温度的耦合关系，本课不重讲），折不到同一量纲的唤醒，就是拍脑袋加进去的； ③ 上电自检次序为什么不能想怎么排就怎么排——被 12V 峰值电流逼成串行的那几段会把 t_ready 顶上去，而 t_ready 的上界由 T_ready_req 给定，那是别人给的窗口，不是软件自己说了算。

钉子 2：时序表里每一条先后、每一格去向，判据只有两个

一个是这一步会不会切断某个仍在被守护的物理过程的通路，另一个是这一件断电之后落在哪。⛔ 不是习惯次序，⛔ 不是「先关谁看起来更整齐」。它同样决定三件事：

① 下电次序——先导通续跑、退出之后再隔断（隔断的同时也切断了残热导出路径）；加热器侧先断电、再延时停泵（通路要留到芯体残热被带走为止，这一对的取值本体归 G9-03 加热器功率控制与温度保护，本课只把它排进全域表并解决它与别的件的先后冲突）； ② 迁移表每一格必须有确定去向，「保持不动」也要显式写出来才算数，超时之后去哪同样要写——没有去向的格子，就是车卡在过渡态而无人捞； ③ 抢断瞬间该不该先把执行器驱到目标位再断电——由该件的断电落点决定（三档 fail-safe 的语义归 G12-03 执行器硬件接口与电气规格）。落点选得对，次序里那一步可以省；落点不对，次序做得再细也补不回来。

最容易被读反的一条

「这三个数各自取保守一点总没坏处——续跑久一点、哨兵开长一点、唤醒频一点，车更安全。」

这句话的现象部分没有错。单看每一项：续跑久一点确实更能带走残热，哨兵开长一点确实更能覆盖停车风险，唤醒频一点确实更早发现高温。所以在三项各自的评审里，把自己那一项往「更保险」的方向调，每一个评审都会通过。正是「每一项单独看都对、合起来方向反了」这个组合，让它成为本课最危险的一条。

它为什么是反的：这三项吃的是同一本 12V 安时账（就是钉子 1 里的 Q_park），而这本账被吃穿的后果是「停几天打不着、App 也唤不醒」——一个比它们各自要防的风险更严重、更难现场复现、且用户直接感知的失效。⛔ 没有任何一个单项评审会看到总账，于是三项加起来把停放能力吃穿，而每一项的负责人都能证明自己是「按更安全的方向取的」。

读者读反之后会做的那个具体动作：拿到「停放能力不足」这条问题单之后，去压纯休眠档的静态电流——因为那一档看起来最像「暗电流问题」；而不去限制哨兵允许时长，也不去把哨兵期间的全域唤醒改成部分网络。工程投入被放在对总账贡献最小的那一格上，改完再测，纯休眠档更干净了，可停放天数几乎没动。本课的案例正是这个形态：该车纯休眠档实测本来就很干净，而按单一静置电流算与按分档求和算，两种算法给出的可停放天数在工程决策上结论完全相反——一个判「可以放心长时间停放」，另一个判「必须给用户限时提示」。⚠ 引言这里只保留结论的方向：案例中的电流与时长均为演算量级，不代表任何具体车型实测值，⛔ 不得据它们写任何倍数或数量级关系（案例本体与它的完整声明见第 8 讲 8.3 与「典型案例详解」）。

同一条误读还有两个更极端的子形态，正文会分别点破：

1. 「兜底时长定长一点更保险」——若没有人在这段时间里持续发网络请求抑制总线休眠，总线会先睡、执行器提前断电；此时把兜底时长加到三倍一点用都没有，而工程师会误判「已经加长了，应该没问题了」。真正的约束是保活，不是时长。
2. 「唤醒频一点监控更及时」——有效窗口 t_eff ＝ t_awake −(t_boot + t_bus + t_valid)，即单次保活总时长扣掉控制器启动、总线建立、传感器有效性建立这三段开销之后剩下的部分，它可能为负。t_eff 为负时，唤醒得越频，每次读到的越是尚未有效的旧读数——频次买不到有效性，只买到了电量消耗。

正解一句话：这三项必须在同一张分档安时账上联立取值，先算总余量、再分配配额，⛔ 不许各自独立取保守值。

本课定什么、不定什么

本课交付的是该有哪些状态、每条边的判据是什么、每个数从哪本账里取。机制侧一律前指、本课不重讲：唤醒源校验、关机写入序列与网络管理的机制实现归 K4-01 热管理嵌入式软件架构与 AUTOSAR 基础，总线唤醒帧与 LIN 睡眠指令的发法归 K2-02 CAN/LIN/CAN-FD 通信与整车 EEA 集成；降级等级体系（正常 / 性能降额 / 跛行 / 安全停机）归 K5-02 热管理故障处理与降级策略，诊断服务与故障码归 K5-01 OBD/UDS 诊断与故障码（DTC）设计；执行器找零算法本体归 G4-01 电子膨胀阀（EXV）结构、控制与选型 / K1-02 执行器驱动：电子阀/泵/风扇/压缩机 PWM / C2-03 风门驱动电机与执行器（步进/有刷/PWM）选型，非易失载体与掉电写一致性归 K4-06 控制器非易失存储设计：学习值、诊断数据与累计量的持久化，状态机完备性与可达性核对的方法学归 K4-05 模式状态机的完备性核对与可验证性设计，水侧切换的三段式时序与断流窗口归 K3-09 冷却液回路模式切换的执行时序：泵—阀联动、断流窗口与切换序列表。功能安全体系的口径只在强制下电、超时降级与安全状态几处引用，版次以现行目录为准，⛔ 本课不写条款内容、也不给限值。

有两条边界要在这里先说清，否则读者会走空：其一，本课的 12V 账与 K2-06 热管理低压供电边界：DCDC 容量、多执行器同时率与 12V 能量保底 是同一本账的两个切面——负载表、同时率与 C_12V,EOL 的取值一律从那门课接过来，本课只做分档求和与配额反推，⛔ 不重做负载表与 DCDC 校核；两门课若各建一本，同一台车会算出两个不一致的可停放时长。其二，K2-06 热管理低压供电边界：DCDC 容量、多执行器同时率与 12V 能量保底 把「低温起动的瞬时电压跌落」指向本课，而本课只给 12V 防亏电门槛的反推方法，跌落机理与起动系统属整车电源域、不在本体系内，从那边跳过来的读者请就此转向。

还有一点要提前交代：本课有几处内容是在既有材料之外补上的——过渡态这一整类状态的命名、插枪与本域硬线触发这两类唤醒源、把 KL30 冷启动从「唤醒」里分出来、以及「唤醒源优先级与续跑放弃顺序共用同一把排序尺」这条约定。正文出现时会逐处标明它是本课补的，⛔ 不冒充成既有结论。

八讲怎么走

第 1 讲立电源模式机：先把三个「睡」分成整车电源模式 Sleep、域控自身低功耗、总线休眠三层（判据不同、发生时刻不同，⛔ 不许互相当作对方的判据），再把状态×事件迁移表、过渡态命名、抢断瞬间的执行器交接、以及「强制下电与降级不同轴」一次讲透；本课全篇的符号约定也钉在这一讲。 第 2 讲做唤醒源：按「信号从哪条物理通路进来」把源列全，每源五列（是否需唤醒校验、误唤醒的能耗代价、优先级、单次保活时长上限、撤回方），并给出部分网络的取舍表与逐源的注入手段——列不出注入手段的源，等于从来没被验证过。 第 3 讲排域内上电：一次上电内的动作按「这件事要等谁」分类，讲清峰值电流如何把本可并行的段逼成串行，按关键路径求出 t_ready，给每段配超时预算与三选一的超时动作，并处理非正常掉电后的状态恢复。 第 4 讲做跨域上电握手四段链，重点是把「TMS 就绪」这个位写成一组可判真假的条件，以及某一段迟到时降到哪一档、由谁裁决。 第 5 讲列续跑请求源与退出判据：按「这段时间要守护的是哪个物理过程」列全，每源给「温度判据 + 定时兜底」双保险，讲清兜底时长估算式只给量级下界、以及断湿型请求为什么不能套带热型的模板；拔枪后的电池残热导出这一段也在这里接上。 第 6 讲排全域停止次序：按动作发生在哪一层列全（制冷剂侧 / 冷却液侧 / 空气侧 / 软件与对外侧），用钉子 2 的两条判据消解阀与泵的次序冲突，并把「阀路隔断还是保持导通」做成时序化分段的取舍。 第 7 讲算续跑窗口的资源账：先答清这一段靠谁供电，再按 12V 可用功率分配预算、定放弃顺序，说清谁发网络请求抑制总线休眠、何时撤回，并把执行器动作次数另立一本按时长计的账。 第 8 讲收口到休眠与配额：休眠判据的与条件组、分档安时账、防亏电门槛的反推、配额守恒，以及周期唤醒的有效窗口与「这次唤醒值不值」的判法。

读完这八讲，你手上应该有三张能拿去评审的表和一本能算的账；而更要紧的是那把尺——看到任何一个时长、次数、先后，第一反应是问它落在哪本账的哪一格、它切断了谁的通路。

第 1 讲　电源模式机：三个端点态、五个过渡态与一张说得清的迁移表

这门课从一张表开始。不是从代码，也不是从某个配置工具的截图，而是从一张任何人都能逐格核对的迁移表——行是车此刻处在哪个状态，列是这一刻可能发生什么事，格里写「那就去哪」。听上去像是把简单的事复杂化，但两类最常见的客诉恰恰长在这张表的空白处：「车关不干净」与「停几天打不着」。这一讲要做四件事：说清本课在整个控制体系里站在哪一环；把全课要反复往里填数的两本账和四对容易撞名的量一次钉死；把状态全集画全（包括那些通常没有名字的过渡态）；再把「一条迁移边合格长什么样」定下来。这一讲不出现任何数值——本课全部的时长量与电流量都是平台相关量，取值方法在后面几讲，而取值的容器必须先在这里造好。

1.1 本课接的是两端：K3-01 整车热管理控制策略总览与模式管理 管稳态中段，这门课管「从没有模式到有模式、从有模式到没有模式」

先把本课的输入与输出摆清楚。输入是一台已经有完整热功能模式机的车——模式集合、互斥表、仲裁规则由 K3-01 整车热管理控制策略总览与模式管理 交付，本课不重做。输出是三样东西：一张含 Init（上电初始化与自检）、Shutdown（下电收尾）、Sleep 三个端点态的电源模式迁移表；一张上电与下电的次序表，带超时列；以及一本分档的静置安时账。三样交付物分别在这一讲、第 3 讲与第 6 讲、第 8 讲落地。

为什么两端要单独成课？因为 K3-01 整车热管理控制策略总览与模式管理 的模式全集里，Init/Shutdown/Sleep 只占一格，并明确前指本课；而车在实际使用里，绝大部分时间恰恰处在这三个端点态或它们之间的过渡里——一天两次上下电，其余二十来小时在 Sleep 与周期唤醒之间来回。中段的模式仲裁讲得再细，两端没有人持有，表现出来就是那两类客诉：一类是下电时该做的事没做完或没告知用户，另一类是停放期把 12V 电量吃穿了。

工程量级要说明白：本课的时间量与电流量一律不给数，它们取决于执行器行程、传感器时间常数、总线报文周期、电池选型与目标市场的停放行为，须由实测与整车协议确定。但「两端编排缺失」的代价是可判的——静置账算错一次，后果不是单车故障而是整批车的停放能力承诺不成立，属上市后集中客诉级别（本课案例正是这个形态，见收尾的案例小结）。

最后划两条边界，免得这一讲被读成别的东西：

• 它不是 K3-01 整车热管理控制策略总览与模式管理 的重复。以为「模式管理已经讲完了」是本课点名的第一条误区——那门课覆盖的是稳态中段，两端在它那里只是一格与一条前指。
• 它也不是一本嵌入式软件配置手册。机制侧一律不在本课：关机写入序列的编排、唤醒源校验的实现、网络管理报文与休眠指令的发法归 K4-01 热管理嵌入式软件架构与 AUTOSAR 基础 与 K2-02 CAN/LIN/CAN-FD 通信与整车 EEA 集成。本课借用了通行软件体系的状态命名与「请求—释放」这套语义来表达保活与休眠判据——注意那是体系名，不是条款号，其规范版次以现行目录为准，引用前须核。本课交付的是另外三件事：该有哪些状态、每条边的判据是什么、每个数从哪本账里取。

1.2 先钉住两本账和四对会撞名的量

这一节没有图，也没有一个数字，但它是全课最该先读的一节。后面七讲里所有的「多久」「几次」「先关谁」，最后都要落回这里立的两个容器。

第一本：12V 静置安时账。

Q_park ＝ Σ_k ( I_k · t_k )，判据 Q_park ≤ ΔDoD_allow · C_12V,EOL

各量的含义与单位在这里一次钉死，全课统一：Q_park 是整个停放期的 12V 电荷消耗总量，单位 A·h；I_k 是第 k 个保活档位的静置电流（单位 A），按该档醒着的节点集合计，不按休眠值计；t_k 是第 k 档的年均停放时长，本符号按小时（h）入账；C_12V,EOL 是 12V 蓄电池寿命末期的可用容量（A·h）；ΔDoD_allow 是允许亏电深度，无量纲。分档的档位清单、各档谁醒着、以及由这条判据反推配额，都在第 8 讲。

这本账有两条口径规定，现在就要立住，因为一旦在后面某一讲里破了例，两讲的结论就再也对不上：

• 容量一律取寿命末期值，不取新车值；寒区还须按所选电池的低温放电曲线再扣一次容量折减。
• 这个判据只有一个方向：它用来判「最坏情况下够不够」。⛔ 不得反过来拿它论证「新车能停更久」当卖点——那是把一个保底判据当成了性能承诺。

第二本：时间窗账。它有两条判据，分别管上电这一端和唤醒这一端。

上电端：t_ready ＋ t_margin ≤ T_ready_req，其中 t_ready ＝ Σ_{j∈关键路径} t_j（可并行的段取最大值，被 12V 峰值电流逼成串行的段取和）

唤醒端：t_eff ≥ t_action_min，其中 t_eff ＝ t_awake −（t_boot ＋ t_bus ＋ t_valid）

t_ready 是上电就绪时间（s）；t_j 是上电第 j 段的最坏耗时（s，取值口径与算法在第 3 讲）；t_margin 是这本账的工程裕量（s），它覆盖各段耗时自身的分散性，⛔ 不是「算完再补一点」；T_ready_req 是跨域握手给本域的就绪窗口（s），由整车与电池侧给出，本课不代它定。⚠ 这里的大写 T 表示时间窗，与后面几讲里的温度量（例如 run-on 的退出阈值 T_exit）同字头不同量纲，正文每次首现都要带定义。

唤醒端那条里，t_awake 是单次唤醒的保活总时长，t_boot 是控制器启动耗时，t_bus 是总线建立耗时，t_valid 是传感器有效性建立耗时，t_eff 是真正能用来测量或干预的有效窗口，单位都是 s；定义式与算例在第 8 讲，这里只需要先知道它的形状与一个关键性质——t_eff 可能为负。判据右端的 t_action_min ⚠ 须分列两个量：只监测型唤醒要的是「读数稳定所需的驻留时长」，监测加动作型要的是「干预时长」，两者不是同一个量、量级也不同，⛔ 不许用同一个数（分型在第 8 讲）。

记账单位的口径。静置账一律用 A·h 记（因为 12V 电池的容量与允许亏电量本来就以 A·h 计），run-on 与保活期的瞬时负载用 W 记。两者之间靠两条换算对齐：E[W·h] ＝ Q[A·h] × U[V]，以及 1 A·h ＝ 3600 A·s。这是单位定义、与任何平台无关，可以放心用；但同一段里既要算能量又要算电流时，必须把中间那步换算写出来，⛔ 不许把 W·h 与 A·h 当同一个量直接相加。全课凡出现这条换算的地方，写法与符号完全一致。

四对会撞名的量，现在分列清楚。并发写作与并行评审最常见的事故不是算错，是两个人用同一个字母指两件事，而两边都没发现：

容易撞的写法	本课的两个量各是什么	硬规定
Q	Q_park ＝ 12V 静置安时账，电荷量，A·h（本讲）／ Q_res ＝ 残热量，停机时刻蓄热体可交出的显热，kJ（第 5 讲）	量纲不同，⛔ 不可互算、不可比大小；全课不许裸写 Q，残热量优先写全称或展开式
C	C_12V,EOL ＝ 12V 寿命末期可用容量，A·h（本讲）／ 热容，kJ/K（第 5 讲的残热估算里出现）	分列两行、各带单位；⛔ 不许裸写 C
duty	间歇 duty ＝ 保温期泵的开停比，分钟级时间尺度（第 6 讲）／ PWM 占空比 ＝ 驱动层脉宽调制占空比，微秒至毫秒级，归 K1-02 执行器驱动：电子阀/泵/风扇/压缩机 PWM	两者量纲相同而物理含义完全不同；全课不许裸写 duty，必须写「间歇 duty」；PWM 占空比本课不展开，此处并列只为防混
时间常数 τ	保温时间常数属保温侧，归 D3-03 电池包保温设计与静置热损；另有传感器时间常数、滤波时间常数	本课引用时一律带下标并写明是保温侧的那一个，⛔ 不与另外两个共用裸写形式

还有一对不是符号而是术语的撞名，同样在这里预告：本课所说的「暗电流」指整车静置低压电流，而 E5-02 激光雷达、摄像头的温控与防凝露 里的同名词指摄像头感光元件的 dark current，两者同名异义、判据不可混用。本课全文优先写「整车静置电流」这一写法（第 8 讲还会再点一次）。

1.3 状态全集：端点态之外，必须给过渡态命名

先把状态列全，再谈边。这里⛔ 不沿「正常上电 → 行驶 → 下电」这条时间单线枚举——那条线会整类漏掉最需要命名的那几个状态。按「端点 / 中段 / 过渡 / 特殊」四组画：

• 端点态：① Init（上电初始化与自检）② Shutdown（下电收尾）③ Sleep。三者射程内，是本课主交付；K3-01 整车热管理控制策略总览与模式管理 只把它们声明为模式集合的成员并前指本课。
• 中段：④ 稳态热功能模式机——射程外，归 K3-01 整车热管理控制策略总览与模式管理。本课只用它的一条优先关系：电源模式跳变可无条件抢断任何热功能模式（见 1.7）。
• 过渡态：⑤ Init 中 ⑥ Shutdown 中 ⑦ run-on 中 ⑧ 强制下电中 ⑨ 唤醒校验中。射程内。⚠ 这一整类是本课补的——大纲原文只写到端点态与「超时后的去向」，把中间那一段升格成有名字的状态是本课归纳的做法。
• 特殊态：⑩ 诊断保持态（诊断会话阻止休眠，会话本体归 K5-01 OBD/UDS 诊断与故障码（DTC）设计，射程内但只作休眠判据的一项）⑪ 运输 / 长期停放态（射程内但只在静置账里占一档，模式语义归 K3-01 整车热管理控制策略总览与模式管理）。

为什么非要给过渡态起名字。故障分析时第一个要回答的问题永远是「车当时在哪个状态」。没有过渡态，日志里只能看到「上一个稳态是 A、下一个稳态是 B」，中间卡了多久、卡在第几步全部看不见。更实际的一点是：过渡态是唯一能挂超时的地方——稳态不需要超时，边在建模上是瞬时的，只有过渡态才有「已经待了多久」这个量可以判。这一条同样是本课补的。

两个易错点：其一，把过渡态当成「实现细节、不进模式表」，于是它在互斥表与可达性核对里全部缺席（完备性核对的方法学归 K4-05 模式状态机的完备性核对与可验证性设计）。其二，沿时间单线枚举时，除了漏掉这五个过渡态，还会整类漏掉「从 Sleep 被唤醒、只做一件事就回睡」的短程往返——周期唤醒、远程指令都是这个形状，它们根本不经过中段；而只数「有名字的模式」则会漏掉那条可以从任意状态无条件发出的强制下电边。

各过渡态的最长驻留时长都是平台相关量、不给数；但它们与时间窗账的关系是确定的——「Init 中」的驻留时长上界就是 t_ready 的一部分（第 3 讲展开）。

1.4 三个「睡」是三层，判据与发生时刻都不同

这是本课口径分层里最要紧的一处：需求文档里那个含混的「休眠」，实际上是三件事。

• 整车电源模式 Sleep：顶层输入，由整车控制器产生，域控只订阅（这条责任线 K3-01 整车热管理控制策略总览与模式管理 已立）。
• 域控自身进入低功耗：这一个控制器停止运行、只留唤醒电路，判据是本域自己那一组与条件（第 8 讲）。
• 总线休眠：网络上所有节点都不再持有网络请求之后总线才睡，判据在网络管理层。

把三层分开，是为了挡住两个方向相反的错误动作。第一个是因果颠倒：拿「总线已经睡了」当成「可以停止发 run-on 保活请求」的判据——真实的因果是保活请求撤回了总线才睡，反过来用，就变成了「等一个由自己决定的条件」。第二个是范围搞错：拿「本域控制器已经睡了」当成「整车静置电流已经落到纯休眠档」的判据——别的域可能还醒着，静置电流必须按醒着的节点集合算，这正是第 8 讲分档账的立足点。

三者之间的时间差与各自的电流台阶都是平台相关量、不给数；但三层的先后顺序是结构性的、与平台无关，所以它可以写成一条可核对的规则：本域撤回网络请求 → 总线上最后一个请求也撤回 → 总线睡 → 各节点进低功耗；而整车电源模式 Sleep 可能更早就置位了。

⇒ 由此得到一条写作与评审纪律：正文与需求文档里写「休眠」时必须点名是哪一层，⛔ 不许裸写。K3-01 整车热管理控制策略总览与模式管理 已经点出「Sleep 既像一个模式又像一个电源态、谁抢断谁说不清」这个含混处，本课到此把它彻底分层，后面几讲不再留一个笼统的「休眠」。

1.5 迁移表的形态是「状态 × 事件」矩阵：每一格都要有确定去向

状态列全之后，边怎么落地？答案是一张矩阵，而不是一张状态图。行是当前状态（含 1.3 里的端点态、过渡态与特殊态），列是事件（唤醒源、各类指令、超时），格里填「迁移到哪个状态」或「保持不动」。

为什么是矩阵而不是状态图。状态图画得再漂亮，也只画出了有人想到的那些边；矩阵则逼着人逐格回答。没有填的格子在代码里就是一个隐含的缺省行为，而隐含缺省不会被测试覆盖——测试用例是照着写下来的需求生成的。真实事故的形态很具体：某个唤醒源在某个过渡态里被收到，没人定义过这一格，于是它要么被丢掉（车该醒没醒），要么触发一次非预期迁移（车在 Shutdown 中途又被拉回 Init）。

这里有一条容易被当成小事的规定：「保持不动」也要显式写出来才算数。理由就在上一段——把它当成不用写的缺省，它在表上就与「这一格还没想过」长得一模一样，而这两者的性质完全相反。同理，不会发生也不能留空，要写成显式的「不可达」并给出为什么。这条做法背后是一条通用的完备性原则：一个项没有被列进表里，不等于它被禁止，也不等于它不存在——所以只能逐格列全。

第三件必须写进格里的事是超时。只写状态不写超时，车就会卡在过渡态而无人捞；而「在过渡态里继续等待」不是一个合法的缺省——不给超时预算的自检等于永久等待。这条判定是本课立的，超时之后到底走哪一条（重试 / 放行并标降级 / 阻止进入首个可运行模式）在第 3 讲展开。

工程量级：矩阵规模由状态数与事件数决定，本课不给推荐格数。状态数怎么收敛归 K3-01 整车热管理控制策略总览与模式管理；矩阵的完备性核对、可达性与死锁分析的方法学归 K4-05 模式状态机的完备性核对与可验证性设计。本讲交付的是记号体系与「每一格都必须有确定去向」这条要求。

1.6 每条迁移必须同时写清三件事：触发事件、守卫条件、超时后的去向

矩阵解决了「哪些格要填」，还剩「一格填成什么样才算填完」。答案是三样，缺一样这条边就不可验证。

触发事件取自唤醒源与指令全集——KL15 电平跳变、远程指令、总线唤醒帧、本地定时器、插枪等（⚠ 完整的唤醒源全集按「信号从哪条物理通路进来」枚举，在第 2 讲列全，本讲只把它当作触发事件的来源，不在这里列表）。守卫条件回答「事件来了，还得满足什么才真的迁移」——典型的有 12V 电压与荷电状态双门槛、无高压故障、车速为零。超时后的去向回答「这条边走了一半没走完时去哪」。

三样各挡一类失效，这是它们必须同时在场的理由：

1. 没有触发事件＝一条永远走不到的边。它在评审里最难被发现，因为表上看起来是满的。
2. 没有守卫条件＝会在电量不足、或车还在动的时候执行上电与续跑。注意这一步的性质变化：它把一个电量问题升级成了一个安全问题。
3. 没有超时去向＝过渡态里的死等，也就是 1.5 末尾那条。

守卫条件还有一条写法上的硬要求：必须写成可判真假的形式。「电压足够」不是守卫条件，因为它在实车上无法复现——电压是瞬时量、随负载变，同一台车在不同负载下测到的值不同。正确的写法是把三样一起写出来：在什么负载条件下、测到的什么量、超过什么门槛。荷电状态那一侧还要多一句：它是估计量、带误差，门槛要留出误差裕量。⚠ 门槛的具体取值是平台相关量、本讲⛔ 不给数——它由第 8 讲的分档安时账反推得到，须按平台实测标定。

最后一个易错点：把守卫条件写进代码的 if 里，却不写进表。那样它就无法被静态核对，而表与代码谁对谁错、谁是权威，在下一个版本上就说不清了（静态核对的方法学归 K4-05 模式状态机的完备性核对与可验证性设计）。

1.7 电源模式跳变可无条件抢断热功能模式——本课补的是抢断瞬间的执行器交接

外层的电源模式一跳，内层的热功能模式无条件退出到对应端点态。⚠ 这个抢断不参与优先级仲裁——它不是一路请求在跟别人比大小，而是外层状态本身变了。这条优先关系 K3-01 整车热管理控制策略总览与模式管理 已经声明，本课直接沿用。

本课要补的是抢断发生那一瞬间的执行器交接规则：正在走行程的多通阀停在哪、正在爬升的压缩机怎么收、正在做止点自学习的风门算不算完成，以及由谁负责把它们驱到落点。⚠ 这一条是本课补的，大纲在优先关系之外没有给交接规则。

为什么它必须有人管：抢断是随时可能发生的（用户拔钥匙、碰撞信号、保活超时都能触发），而执行器的行程是有物理时间的。不写交接规则，结果就是阀停在两个位置中间——它既不是隔断位也不是导通位，下一次上电时它的位置是未知的，于是逼出一次强制重寻零，把 t_ready 顶上去。⇒ 这一讲的一个疏漏，代价会落在第 3 讲的时间窗账上。

两个易错点，都关于射程：

• 把「该驱到哪个位置」当成本课的题。落点本身由该件的三档 fail-safe 语义与选型决定，归 G12-03 执行器硬件接口与电气规格；阀的全行程时间、压缩机的降速斜坡时限同样是平台相关量、由部件侧给出（风门止点与失电位另见 C2-03 风门驱动电机与执行器（步进/有刷/PWM）选型）。本课只回答一个时序问题：抢断时该不该先驱位再断电。这个问题的完整判据在第 6 讲的停止次序表里展开，本讲只立「必须有人回答它」。
• 以为抢断只发生在下电。强制下电、保活超时、诊断结束都能触发它——⛔ 它是一条可以从任意状态发出的边（图1 里那条粗线）。

1.8 强制下电与降级不同轴：它可以在完全无故障时触发

最后一条，是这一讲里最容易被合并错的一对概念。降级等级体系（正常 / 性能降额 / 跛行 / 安全停机）是故障处理轴上的东西，归 K5-02 热管理故障处理与降级策略；强制下电是电源模式轴上的一条无条件迁移。两者不在同一根轴上，⛔ 不可换算也不可互推。

强制下电的触发条件里，最典型、也最高发的一条是「保活时长超过上限而请求方没有撤回」——此时系统可能一个故障都没有。把它塞进降级体系，两个方向的错都很贵，而且症状相反：

• 混成一轴：强制下电被写成「最高一级降级」，于是它继承了降级的全套流程——报故障码、点故障灯、进跛行。而一次正常的保活超时下电本来不该报任何故障，结果是售后端积累一批查不出根因的记录，反过来污染真实故障的分析。
• 挂错前置：把强制下电挂在故障判据后面，变成「没故障就不强制下电」。于是一个忘了撤回的保活请求可以把车一路停到亏电——而这恰恰是保活请求最典型的失效形态（它不是「没发」，是「发了没撤」，第 2 讲会把撤回责任落到表上）。

⇒ 由此得到需求写法上的一条提醒：⛔ 不要只写「严重故障时强制下电」。漏掉的那条「保活超时时也强制下电」，才是最高发的那一条。保活时长上限是平台相关量、本讲不给数，它同样落在第 8 讲那本安时账上：判据是单次超时多醒的那一段，其代价必须能被这本账吸收（第 2 讲 2.5 展开）。⚠ 它不是 8.8 反解出的那三个配额（哨兵允许时长 · 每日唤醒次数配额 · run-on 窗口总时长上限）之一——那三个是同一次分配的三个结果，而这一列是逐源填的上界，两者判法不同、⛔ 不可互相顶替。

关于标准的引用，这里说清一次并全课通用：功能安全体系（ISO 26262 是体系名，不是条款号）在本课只于强制下电、超时降级与安全状态三处引用其口径；版次与年份以现行目录为准，引用前须核。方法本体归 K2-03 功能安全（ISO 26262）在热管理中的应用，降级等级体系归 K5-02 热管理故障处理与降级策略。⛔ 本课不写条款内容、不给任何限值，也不得把它的条款跨射程用到本课的能耗账或时序取值上。

本讲小结：这一讲交出的是全课的容器，不是取值。四件事——① 本课接的是两端，K3-01 整车热管理控制策略总览与模式管理 管稳态中段，机制侧归 K4-01 热管理嵌入式软件架构与 AUTOSAR 基础 与 K2-02 CAN/LIN/CAN-FD 通信与整车 EEA 集成；② 两本账（安时账 Q_park ≤ ΔDoD_allow · C_12V,EOL 与时间窗账 t_ready ＋ t_margin ≤ T_ready_req、t_eff ≥ t_action_min）以及四对撞名量（Q / C / duty / 时间常数）在此一次钉死，后面七讲往里填数；③ 状态要按端点、中段、过渡、特殊四组列全，其中五个过渡态是本课补的，而过渡态是唯一能挂超时的地方；④ 迁移落成「状态 × 事件」矩阵，每一格必须有确定去向（含显式的「保持不动」与「不可达」），每条边必须同时写清触发事件、守卫条件与超时后的去向。另立两条本讲的判定：抢断瞬间的执行器交接必须有人负责；强制下电与降级不同轴，它可以在完全无故障时仅因保活超时触发。