K5-02 热管理故障处理与降级策略

课程代码 K5-02 · 板块 K 控制、软件与标定 / K5 诊断与故障管理 时长 约 4.0 小时（6 讲 + 1 次降级架构设计实操） 适合对象 热管理系统架构与控制工程师、功能安全工程师；项目里真正要动笔写降级策略与仲裁表的那个人（专家向，系统架构必修） 前置 K5-01 OBD/UDS 诊断与故障码（DTC）设计；K2-03 功能安全（ISO 26262）在热管理中的应用；K3-01 整车热管理控制策略总览与模式管理 本讲义定位 讲师授课蓝本 / 学员自学讲义，是 K5-02 大纲的完整展开版

---

引言：泵卡死了，车该怎么办

一辆车正在快充桩上，电池冷却泵的电流出现异常，诊断侧按自己的判据把这条失效判定成立、置了码。到这一刻为止，K5-01 OBD/UDS 诊断与故障码（DTC）设计 的活干完了。本课要讲的东西全在这一刻之后：这辆车接下来是继续充、降功率充、还是停下来；座舱正在用的那一份冷量要不要让出去；这一串动作必须在多久之内做完；做完之后，用户在屏上看到的是「车坏了」还是「正在保护电池」。四个问题里但凡有一个答不出来，前面那条判得再准的故障，落到车上就只剩两种表现——要么什么都没做，要么一步跳到最保守的那一档。

难处不在于「要不要降级」这个判断，而在于「降级」这个词本身太含糊。把它当成一个动词用，它就只能落成一张「什么故障 → 降到哪一级」的映射表；而这张表在两个方向上都是空的：它不说还剩多少能力、这份能力先给谁，也不说这一串动作必须在多久之内做完。本课要做的第一件事，就是把这个动词翻成一句可交付的话——降级是一次有时间预算的能力再分配。翻译做完，后面所有的结构（等级怎么分、仲裁表长什么样、时间怎么拆）才有一个共同的地基；翻译不做，各条降级路径就只能各写各的，写到第十条时它们已经互不相认。

学完这门课，你应当能做四件事：① 为典型部件失效（冷却泵卡死、EXV 卡滞、关键传感器丢失、跨节点报文失联）各写出一条降级路径，并说得清它为什么停在那一级；② 在电池、座舱、电驱、智能电子四路热需求冲突时，交出一张可标定的仲裁表，而不是把优先级写死在代码里；③ 定义一套降级等级体系（正常 / 性能降额 / 跛行 / 安全停机），并把每一级该填的格子填满，包括最容易空着的那两格——退出条件与回交那一拍；④ 把这套体系与功能安全的故障容错时间预算、以及整车的功率仲裁对接上——两头都接住了它才是一条策略，只接一头就还是一张表。

这门课在链条上的位置很窄，也正因为窄，它两头都容易落空。上游 K5-01 OBD/UDS 诊断与故障码（DTC）设计 交出来的是「什么坏了、置不置码」；下游各部件课交出来的是「这个件自己怎么保护自己、失效后本地退到哪里」（K1-02 执行器驱动：电子阀/泵/风扇/压缩机 PWM／K3-08 冷却侧执行器需求生成与协同仲裁：电子水泵/冷却风扇/AGS／C2-03 风门驱动电机与执行器（步进/有刷/PWM）选型）。中间这一段——把一个已判定成立的失效翻译成能力损失，再由能力缺口决定降到哪一级、由时间预算决定多久之内到位——若没有人做，两头就会各自合理地跑向对不上的结论：诊断覆盖率年年在涨，而车上真出事时，谁也说不出系统此刻处在哪一级、还剩多少冷量可分。六讲的动作全部发生在这一段里：第 1 讲立骨架（等级体系、触发来源、四种应对哲学与时间语义）；第 2 讲在能量通路侧兑现一次（冷却液、制冷剂、空气、电加热四域，外加高压绝缘下降与初始化失败这两类沿「运行中部件失效」枚举时会整类漏掉的）；第 3 讲是能力侧的合处（缺口驱动降级深度、四路仲裁、与整车控制器和电池管理系统的功率协同）；第 4 讲是时间侧的合处（预算怎么拆、拆到谁头上、哪两片最常被漏掉）；第 5 讲在信息侧兑现一次（信号丢失、报文失联、模型失准、场景语义判错）；第 6 讲把前五讲交出的东西送进验证、标定与售后闭环。其后的典型案例（高温环境下快充、电池冷却泵疑似堵转）把两根钉子合起来打一次——它既要算「还剩多少冷量、先给谁」，又要在预算之内把动作做完；小结收口。

第一根钉子（下文一律简称「钉子 1」）：降级的判据不是「坏了什么」，是「还剩多少能力、这份能力先给谁」。

热管理的失效模式有几十种。若每一种各写一条降级路径，路径条数会随失效模式数一起长；更要命的是多故障并发时几条路径互相打架，谁也说不出最终该停在哪一级。正确的走法是先做一次翻译：把所有失效都折成同一个量——可用能力 Q_avail 的损失；再由需求缺口 ΔQ = Σ_i Q_demand,i − Q_avail,degraded 决定降到哪一级。⇒ 这一步翻译定死了后面四件事：① 降级等级体系只需要一套，而不是每个部件一套；② 控制重构（用剩余自由度顶替失效的自由度——EXV 卡死改用压缩机转速守过热度、泵限速改提风扇并下调目标水温、温度门卡冷位用电加热配风量重建出风温度）之所以能与降级、冗余切换、直接停机并列成第四种应对哲学，而不是某个部件的特殊处理，正因为它改的就是 Q_avail 这一项，不是在既定能力上重新分配；③ 仲裁必须复用常态那一份请求—能力契约，Q_demand 与 Q_avail 在降级态与常态同口径——为降级另立一套接口，是仲裁表最常见的分叉源；④ 信息侧失效同样能进这套状态机：「看不见了」等价于能力估计的置信度掉了，折成 Q_avail 的一个保守折扣即可，⛔ 不必另起一套语法。

⚠ 钉子 1 有一句必须同时敲的下半句：缺口判据与降额曲线必须联立，缺哪一条都是漏判。只以温度为自变量的降额曲线 P_limit(T)，在「能力已经被打掉、而温度还没起来」这一段是全绿的——泵刚卡住、水温还没升上去，曲线上什么也不会发生，而那一段恰恰是留给系统响应的窗口；等温度真起来，留给检测与执行的时间已经不够了。反过来只看 ΔQ 不看温度，则接不上部件自身的热保护。两式各管一段：ΔQ 管「还剩多少、够不够分」，P_limit(T) 管「温度已经起来之后怎么连续地退」，两者给出不同等级时取更深的一档。这也是本课与「画一条降额曲线就算做完降级」这种常见做法的分水岭。

第二根钉子（下文一律简称「钉子 2」）：降级不是一个动作，是一条有时间预算的链——t_FTTI ≥ t_detect + t_react，两段都必须有人认领、都必须可测。

一张「什么故障 → 降到哪一级」的映射表最大的问题是它不含时间。把时间加进来之后，四件事的答案全变：① 触发阈值不能卡在安全极限本身，必须从极限往回退一个裕量，而退多少不是拍脑袋，是由 t_detect + t_react 与被测量的最坏变化率算出来的（本课给的是 ΔT_余量 ≥ (dT/dt)|max × (t_detect + t_react) 这条下界，⛔ 不是一个可以直接填进标定表的数）；② 「重试—放弃—降级」必须有次数上限与总时限——无限重试等于把 t_react 写成无穷大，预算必破，而它在现场的表现是把一个本来可恢复的结冰卡滞做成了烧毁；③ t_react 里常被漏掉两片：跨控制器授权的那一个来回，与执行器的机械行程和到位确认——只算本域检测与软件执行，预算会被算宽，而算宽的预算在台架上永远不会报错；④ 有外层预算时本域必须落在它的内层——智能驾驶接管请求的时间预算由辅助驾驶侧给定，热管理侧的两段之和要落进去，⛔ 不是各自达标就算。⇒ 一条不含时间的降级路径，验证时每一次都能「演示成功」，因为演示从来不掐表。

先把本课最容易被读反的那句话摆到台面上：「降级就是把出问题的那条路关掉、让执行器退回失电安全位——方向是唯一的、全域统一的。」

这句话的前半截确实是对的：失效安全设计的通行做法正是「去激励之后停在一个已知位」，本课也确实要求每一个执行器都写明自己的失效位。反的是后半截，即「方向唯一、全域统一」这半句。正是这种「做法没看错、方向接反了」的组合让它成为本课最危险的一条：它听起来保守稳妥，做出来是把安全方向搞反，而且做反之后代码与评审都还是过得去的。它会让人做出一个很具体的错误动作——把硬件层那张三档失效安全位表（G12-03 执行器硬件接口与电气规格）原样抄成策略层的降级动作表，并在场景表里只写一条全局默认的回退方向。而方向至少在四处不同向：同一个冷却液温控阀，卡闭是安全相关（须限功率、风扇拉满、走时间预算），卡开只劣化暖机与冬季续航，正确处置是接受劣化而⛔ 不是限功率；空气侧的选位判据与液路侧相反——液路按「保护部件、保住回路」选位，空气侧直接撞视野与健康，须按「保住法规与视野」选位（鼓风机去激励是停转，而停转会让风暖干烧、除霜功能不可用）；硬件的失效位与策略该假设的位不是一回事——主动进气格栅的 fail-open 说的是断电时的机械倾向，结冰卡关时它实际停在关位，按「已回到 fail-open」算散热能力会把降额量算少一整档；还有整整一格常被忽略——无回位弹簧的执行器根本没有「去激励位」这个概念，步进电机式 EXV、多通阀与多数电动风门在去激励时通常停在当前位置，究竟是保持位置还是弹簧回位随所选件的机构而定，⛔ 须逐件查规格书写进失效安全表，不许按通则默认。⇒ 正确的方向由「这一次失效威胁了哪一个量」决定，逐场景、逐执行器声明；失电安全位是硬件在没有电时的兜底，⛔ 不是策略层的目标位。本课在第 2 讲讲空气侧选位判据时正面点破它，在第 5 讲讲场景语义判错时从「往哪个方向回退」这一侧再敲一次，常见误区节收口。

⚠ 同时要防住它的镜像误读：不能反过来认为「既然方向逐场景不同，那就没有通则、逐个拍就行」。通则有两条且全域适用——① 每一个场景、每一个执行器都必须显式声明回退方向与理由，⛔ 不许靠默认：默认值不会被写进用例，也就不会被测试覆盖；② 无论回退到哪一档，都必须向用户可见，⛔ 不得悄悄降。第二条与「策略性让路不置故障码」并不冲突：不置码说的是不点故障灯，不是不告知。

最后把边界划清——本课夹在诊断与部件之间，上下左右都有属主课；不在开篇把边界写死，这门课必然与它们重叠，或者整段落空。本课定六件事：① 一套降级等级体系及其每一级要填的五个格子（进入条件 / 退出条件 / 执行器动作集 / 对外声明 / 回交那一拍的预置）——★ 四级的名称与形状照体系原样，而「五个格子」这个填表格式、以及其中「回交那一拍」这一格，是本课归纳的，⛔ 不是既有体例；② 触发来源的分类与各自的语法（故障触发 / 非故障的策略让路 / 安全事件 / 部件本地控制器的隐性降额 / 本域请求被拒或超时 / 没有码可报的功能不足）——★ 其中后三类是本课把散在别处的触发源归进同一个轴，⛔ 不是既有分类；③ 各执行器域与信息侧失效的降级路径与选位判据；④ 四路热需求的仲裁表结构与能力缺口的用法；⑤ 时间预算怎么拆、拆到谁头上；⑥ 这套东西怎么验、怎么标、怎么在售后闭上环。

本课不定的，逐项写明归谁、为什么归它：控制器自身的失效（微控制器、看门狗、电源、非易失存储、时钟）→ 本课只声明一条独立性要求（两条降级通道⛔ 不得共用同一路电源或同一颗微控制器），硬件架构与存储介质见 K2-01 热管理控制器（域控/ECU）硬件架构／K4-06 控制器非易失存储设计：学习值、诊断数据与累计量的持久化；热安全事件（热失控、碰撞后、充电静置起火）触发的应急动作链 → D5-06 充电与充满静置工况的电池热安全应急响应与桩车联动／D5-04 碰撞后电池热管理应急响应／D5-01 热失控热扩散抑制（热管理与结构协同），★ 这一格不是「更严重的降级」，它与本课的优先序相反——安全事件下「切断能量输入 ＋ 保住监测供电」优先于恢复温控性能，两者混用会在最危险的场合按本课的优先序办事；断高压与停车的决策权 → 属整车高压电气与整车安全，本域只交出请求与自己那几个执行器；分级告知规则（什么级别该说、说什么、在哪个界面说）→ 属人机交互与整车产品域，本课只交出「理由」与「等级」两个量；多故障并发时的主从抑制与根因仲裁 → K5-08 诊断使能窗口与故障抑制矩阵：多故障并发的根因仲裁（次序是硬的：抑制在前、降级在后，否则按码逐条降会过度降级）；可用能力估计器怎么构造、怎么整定、什么时候该退出 → G12-01 温度/压力/流量/湿度传感器选型与布置／K1-03 传感器布置、冗余与信号可靠性／K3-10 热管理在线状态与负荷估计：观测器整定、软测量置信度与退出条件，本课把它当输入用，只要求写清「这个数从哪来、什么条件下可信」；部件层自我保护的阈值排队与执行器需求生成 → K1-02 执行器驱动：电子阀/泵/风扇/压缩机 PWM／K3-08 冷却侧执行器需求生成与协同仲裁：电子水泵/冷却风扇/AGS；正常态的可用功率窗口 → K3-12 电池放电与回馈侧可用功率窗口：限值 map、热限功率与撑窗策略，充电态的功率协商 → D4-03 充电过程温控策略与充电功率协同，本课只管故障态与降级态；模式表与场景表的静态体检、状态机的可达性与查环 → K4-05 模式状态机的完备性核对与可验证性设计／K3-13 模式表/场景表与仲裁规则的静态体检：可达性、死锁与切换质量；台架与故障注入手段本体 → K4-03 MIL/SIL/HIL 验证流程；标定量的承载形式与变更评审级别 → K6-01 热管理标定流程与工具（INCA/CANape）／K6-05 标定数据管理与版本控制。⛔ 对不定的部分，本课一律只给类型与去向，不给限值与条款内容。

⚠ 由此有三种读法会落空。一是来找可以直接抄进标定表的数——本课涉及的故障容错时间及其两段、去抖周期与成熟度计数、重试次数与退避间隔、降额曲线的折点与斜率、四路优先级权重、缺口的分档阈值、泵与风扇的兜底转速、阀的应急开度，⛔ 全部不给数：它们随整车配置、部件机构与本项目的危害分析而变，抄上一代平台是实撞过的错误动作。本课给的是判据式与拆法，凡带代入值的算例，输入与结果一律是教学假设值，不对应任何平台，⛔ 禁止取用。二是把它当标准条文课读——本课未逐条核对 ISO 26262 / GB/T 34590 与 ISO 21448 的原文，对它们只写标准号、它管哪件事与去向（K2-03 功能安全（ISO 26262）在热管理中的应用／K2-05 预期功能安全（SOTIF/ISO 21448）与 AI 件安全论证在热管理的落法），⛔ 一个等级号、一条分解组合、一句条款内容都不写；版次与年份以现行目录为准，引用前须核。绝缘电阻的报警线同理——属整车高压电气与相关安全标准规定，本课只写去向。三是把它当部件故障手册读——本课不讲某个泵、某个阀、某个风门自己会怎么坏、坏了本地怎么保护，那些在各部件课里；本课只讲整车知道之后怎么降。⇒ 这门课能给你的不是那几个数，是把一次失效翻译成能力损失、再翻译成一条带预算的动作链的那套判据，以及判断这条链写没写全的核对法。

第 1 讲　先把失效翻译成「还剩多少能力」，再谈降到哪一级

一份降级策略评审，十有八九是从一张映射表开始的：左边一列失效模式，右边一列「降到哪一级」。表上每一行单独看都讲得通，麻烦出在表本身——它不回答两件事：这一行凭什么降到这一级而不是上一级或下一级，以及这个动作必须在多久之内做完。前一个空缺让多故障并发时几行互相打架，谁也说不出最终该停在哪一级；后一个空缺让整张表在台架上永远测不出毛病，到实车上才以「反应慢了半拍」的形式兑现。这一讲要做的就是把这张表拆开重装：先立一个统一的量，让所有失效都先翻译成它；再给整条链装上时间。

本讲交付六件：① 与上游诊断的责任边界——两侧的交接物是「一次翻译」，不是一张映射表；② 全课统一的术语口径，四对易混词分列；③ 降级等级体系的四级，以及每一级必须填满的五个要素；④ 触发来源的六类分法，与「置不置码是结果、不是分类轴」这条判断；⑤ 四种应对哲学与选它们的三问，含第四种——控制重构，它的交付物是一张模式可用性矩阵；⑥ 三类限值判据（绝对阈值 / 变化率 / 累积剂量）、降额曲线的形状要求与它的射程、统一的「重试—放弃—降级」规格，以及回交那一拍的预置要求。

本讲不交付：各类执行器与能量通路失效的逐条降级路径与选位判据（第 2 讲）；多子系统资源仲裁、需求缺口怎么驱动降级深度（第 3 讲）；故障容错时间预算怎么向下拆、触发裕量怎么算（第 4 讲）；信号丢失、报文失联与判断失准的降级路径（第 5 讲）；验证、标定与售后闭环（第 6 讲）。凡本讲写「见第 N 讲」或前指某门课的地方都是刻意的分工，不是漏讲。

1.1 上游交出的是「什么坏了」，本课的第一件事是把它翻译成「还剩多少能力」

先说清两侧各答什么。K5-01 OBD/UDS 诊断与故障码（DTC）设计 那一段的输出是三样东西：一个已判定成立的故障标志、一条（或几条）故障码、以及这次判定带的置信度标签。它回答的是「什么坏了、置不置码」。本课接手的正是这三样，输出则换成另外三样：降级等级、执行器动作集、对外声明。两侧的责任边界不划在「谁写这段代码」上，划在这次交接物上——而交接物的实质是一次翻译：把「某个件失效了」翻译成「哪一项可用能力掉了、掉了多少、掉下去还回不回得来」。

翻译的产物固定是三条：受影响的能力项（是这条回路的换热能力，还是某一路加热功率，还是某个被控量的可控性）、损失幅度的保守估计（估计要往不利侧取，理由见第 2 讲讲的最不利位姿）、这次损失是否可自恢复（决定了它走保护性降额的语义还是故障降级的语义，见 1.2 与第 3 讲）。

为什么非要翻译这一道。不翻译，就只能从失效模式直接映射到动作。映射表的行数随失效模式数增长，热管理的失效模式本来就有几十种，而真正压垮这张表的不是行数，是并发：两三个故障同时成立时，几行各自指向不同的等级，表里没有任何东西能裁决最终停在哪一级。翻译成同一个量之后，这个问题消失了——多故障不过是同一个量被扣了几次，降到哪一级由「扣完之后还够不够用」这一个判断决定。这条判断的完整形式（需求缺口驱动降级深度）在第 3 讲展开，本讲只需要接受它的前提：所有失效必须先落到同一个量上。

工程量级。三条产物全部是平台相关量：哪些能力项、损失多少、能不能自恢复，都随架构、部件选型与冷却回路拓扑而变，⛔ 本课不给任何取值，只固定翻译的形式与「保守侧取值」这条要求。可用能力本身怎么在线估出来，本课把它当已知输入用，估计器的构造与整定前指 K1-03 传感器布置、冗余与信号可靠性、G12-01 温度/压力/流量/湿度传感器选型与布置 与 K3-10 热管理在线状态与负荷估计：观测器整定、软测量置信度与退出条件。

两个易错点：① 把「有没有码」当成「要不要降级」——两者不是一回事：策略性让路不置码但照样要降（见 1.5 的第二类触发），部件本地控制器自主限速也不置整车码而系统已经在降（见 1.13），反过来也有置了码但按缺口判下来根本不需要降的情形；② 把责任边界画在「谁写这段代码」上——一旦这么划，检测侧与控制侧会各判一次严重度、各排一套等级，最后交付物里有两套互不一致的等级定义，而它们在集成之前都自测通过。

1.2 四对易混词全课分列：降级不是降额，安全状态不是安全停机

这门课有一批词只差一层含义，实务里被混用得很厉害，而混用的代价不是措辞不严谨——是读者拿它们互推，推出一个自己都没意识到的错结论。先把口径钉死，此后全课统一。

一对	左边这个词的确切所指	右边这个词的确切所指	混用会推出什么错结论
降级 degradation ／ 降额 derating	等级体系上的一次状态迁移，必然带执行器动作集与对外声明	某个量（功率、转速、扭矩）的连续折减	「我已经限了功率，所以我已经降级了」——实际上等级没迁移、对外没声明、退出条件也没人写；降额可以是降级的动作之一，但不等于降级
保护性降额 ／ 故障降级	部件没坏，是工况把系统推到运行包络边界，可自行恢复	部件已失效，需要故障码与售后介入，不可自行恢复	整车侧无从判断该临时限功率还是该提示进站；售后侧把工况性让路当故障换件。两者共用同一条上报通道，但信号里必须带原因码与可自恢复标志（第 3 讲）
安全状态 safe state ／ 安全停机 safe stop	功能安全意义上的目标态，到达它可以有多条路径	到达安全状态的一种路径：主动停止	「已进入安全停机」被当成「已到达安全状态」。断高压之后热管理并没有结束——监测与必要的泵仍需供电，容量与时长约束前指 K2-06 热管理低压供电边界：DCDC 容量、多执行器同时率与 12V 能量保底 与 K3-11 热管理域的上下电时序、run-on 编排与休眠期能耗预算
故障检测时间间隔 FDTI（t_detect）／ 故障反应时间 FRTI（t_react）	从失效发生到判定成立的整段检测时间	从判定成立到执行器真的到位的反应段	只算了其中一段就宣布满足时间预算。两段之和才受故障容错时间约束，拆法见第 4 讲

⚠ 第四对的中文译名在实务里并不统一，本课固定用「故障检测时间间隔／故障反应时间」这一对写法，并在需要时用 t_detect ／ t_react 指代，⛔ 全课不再换别的叫法。

⛔ t_detect ⛔ 不是「两次诊断测试之间的间隔」——那是诊断任务的调度周期，是另一个独立的量，它只是 t_detect 里的一片。t_detect 是从失效物理发生到「故障成立」这个判定被置起来的整段，里面装着采样与滤波、去抖所需的连续周期数、成熟度计数所需的诊断周期，以及各类特殊确认窗（十片拆法见第 4 讲 4.1）。⇒ 按「一个诊断周期」去填 t_detect，去抖的 N 个周期与成熟度计数的 M 个周期会整段掉出预算，检测段算短、留给 t_react 的预算随之算宽——而算宽的预算在台架上永远不会报错。

其余术语在本课的所指，一并在此交代，此后正文不再重复注释：跛行 limp-home＝功能集收缩到最小可用子集、以「开到能修的地方」为目标的那一级；故障容错时间 FTTI＝从失效发生到必须已经到达安全状态的时间上限；仲裁 arbitration＝多路热需求争抢有限能力时的分配裁决；监控器-执行器架构 monitor-actuator＝把「执行」与「监控执行是否正确」分成两个互相独立的元素（第 4 讲）；降额曲线 derating curve＝把允许功率写成温度的连续函数（1.10）；单点失效 SPF＝单独一个元素失效即可导致违背安全目标；软测量替代＝用模型与其它可测量推算失去的那一路信号（第 5 讲）；功率限制协同＝热管理把自己的能力不足反馈成整车侧的限扭矩／限充放电请求（第 3 讲）；控制重构 control reconfiguration＝被控量不变、操纵变量换人（1.8）；模式可用性矩阵＝行为失效模式、列为模式集、格为可用性的那张交付表（1.8）；最小风险策略 MRM＝自动驾驶侧在无法维持功能时到达低风险状态的动作链（第 4 讲）。

⛔ 上述术语中凡属功能安全标准既有定义的（安全状态、故障容错时间、单点失效、故障反应时间等），本课未取标准原文：只用这里给出的中文工作口径，标准号与去向见第 4 讲与 K2-03 功能安全（ISO 26262）在热管理中的应用，条款内容、等级号与时间要求一律不在本课给出；引用前请按现行版本核，版次与年份也以现行目录为准。

1.3 等级体系的价值不在分了四级，在每一级的五个要素填满了没有

四级的语义先分清。正常＝满能力；性能降额＝能力打折但功能齐全，用户感到的是「慢一点、弱一点」；跛行＝功能集收缩到最小可用子集，目标从「保持体验」换成「开到能修的地方」；安全停机＝主动到达安全状态并停止。四级的形状与命名照行业通行分法，本讲不改。

真正决定这套体系有没有用的，是每一级都得填满一张固定的表。★ 下面这张五行表是本课归纳的填表格式，不是标准或行业既有条款：

1. 进入条件——什么成立时进入这一级。⚠ 它的来源不止「诊断置位」一种，1.5 会把六类触发来源一并列出，1.13 那一类最容易整类漏掉。
2. 退出条件——什么成立时允许离开这一级。必须含迟滞与确认帧数，⛔ 不许只写「故障消失」。
3. 执行器动作集——这一级里每个相关执行器具体走到哪、维持什么。⚠ 各执行器该走到哪一位不是全域同一个方向，这一条留到第 2 讲正面讲，本讲只要求「必须逐件写明」。
4. 对外声明——向整车与用户交出的原因码，以及「是否可自恢复」这个标志。缺了它，整车侧无从判断该临时限功率还是该提示进站（1.2 第二对）。
5. ★ 回交那一拍——退出这一级时怎么把控制权交回自动回路。这一格在多数项目的等级表里是空白的，1.12 单独讲。⚠ 口径钉死：这一格全课统一叫「回交那一拍」，⛔ 不再换别的叫法；正文里单说「回切」时指的是动作本身（从降级态切回自动态），⛔ 不是这一格的名字。

为什么非要填满。只写等级名不写这五格，等级就退化成一个显示标签：没有退出条件就出不来，没有动作集就没人知道具体做什么，没有对外声明整车就只能猜，没有回交那一拍用户会在恢复瞬间被顶一下。这五格里任何一格空着，后果都不会在「等级表看起来不完整」这个形式上暴露——表看起来是齐的。

⚠ 还有一格不属于这四级中的任何一级：初始化未完成／带病可用。它发生在系统还没进入任何工作模式之前，因此「从当前模式降一级」这条语法在它身上根本不成立，必须单列并单独定义自己的进入、重试与可用性规则。这一类的完整处置在第 2 讲。

工程量级。⛔ 各级的阈值、迟滞带与延时全部是平台相关量，随被保护对象的温限与本项目的性能取舍而定，本课不给数、也不给参考区间；本课只给等级的形状与这五格的填法。

三个易错点：① 只做了跛行一级，中间没有性能降额缓冲——用户体验断崖式下降，而工程上本来有一整段可以平滑过渡的空间；② 反向的错同样要防：把降额曲线切成很多档、每档给一个等级，档与档之间的进入退出条件重叠，系统就会在边界上来回跳；③ 退出条件写成「故障消失」而不写迟滞与确认帧数——一个间歇故障足以把系统抖成周期性的升降级，而这种抖动在故障注入台架上很难复现，它要的是真实工况下的间歇性。

1.4 故障严重度决定「多快必须到位」，⛔ 不决定「降到哪一级」

是什么。这里有两条各自独立的链，实务里经常被压成一张表：

• 链一（速度）：严重度 → 故障容错时间的上限 → 分给 t_detect 与 t_react 的预算 → 诊断周期、去抖、执行器行程都得塞进去。
• 链二（深度）：需求缺口有多大 → 降到哪一级；同时与温度侧的降额曲线联立取更深的一档（第 3 讲）。

为什么不能合并。合成一张「严重度 → 等级」表，会在两个方向同时出错：高严重度但缺口很小的场合（例如一路冗余泵失效而此刻热负荷本来就低）被过度降级，白丢一整档性能却没换来任何安全；低严重度但缺口很大的场合（例如高温快充下风扇降速，件没坏、码也不严重，可冷量缺口是实打实的）反而降得不够。两个方向的错都会在标定阶段被解释成「阈值再调调」，而它们的根因是分类轴选错了，调阈值调不好。

工程量级。严重度分级本身来自本项目的功能安全分析（危害分析与风险评估），⛔ 本课不给等级号、不给分级与时间预算的对应关系、不复述任何条款内容，方法与去向前指 K2-03 功能安全（ISO 26262）在热管理中的应用。

易错点：把「响应要快」执行成「立刻跳到最深的那一级」。快的是到位时刻，不是深度——严重度高恰恰意味着必须尽快到达某个安全状态，而那个状态可能就是「限着功率继续跑到能安全停车的地方」。这条错与第 4 讲要讲的「触发阈值卡在安全极限本身」是同一族：都是把时间维度上的要求，误算到能力维度上去了。

1.5 降级按触发来源分六类，语法不同——「置不置码」是结果，⛔ 不是分类轴

先说分类轴。把降级按「置不置故障码」分成两堆，是最常见的分法，也是错的：置不置码是这一类触发处理完之后的结果，不是它的成因。按结果分类，同一条链会被切到两边去；按触发源是什么分类，六类才闭合。前三类是行业通行分法，★ 后三类是本课把散在别处的三种情形归进同一个轴，使这个集合闭合，它们不是既有的标准分类：

(a) 故障触发——本课主线：检测 → 降级 → 置码 / 点灯。

(b) 非故障策略触发——车没坏，系统按设计意图让路：低荷电状态下收紧舱内制冷与制热、快充期间冷量优先给电池、除霜化霜期间制热短暂让位、高负荷时前端风量优先给电驱。⛔ 不置故障码、不点故障灯——否则用户每遇到一次策略让路就看见故障灯。但「不置码」⛔ 不等于「不交代」：必须有一组独立于故障码的可读状态量，至少含 {触发源、当前生效等级、进入与退出时刻、预计持续时长}，字段承载前指 K5-01 OBD/UDS 诊断与故障码（DTC）设计，它依据的资源账前指 B2-03 纯电（BEV）整车热管理架构设计 与第 3 讲。

(c) 安全事件触发——同一套方法论换一个触发源即可复用。典型如座舱内活体遗留的响应：它的触发源来自感知置信度而不是故障诊断，退出条件来自人的生存时限而不是部件恢复，但等级、迟滞与退出的语法完全一样。本课只讲这层复用关系，实例前指 C6-04 智能座舱：人员感知与按需送风（露营/休息模式）。

(d) ★ 隐性触发：部件本地控制器的自主降额或限速——系统已经在降，而整车不一定知道。这一类单独在 1.13 展开。

(e) ★ 资源不足触发：本域向动力域提出的请求被拒绝或超时——不是部件失效，但可用能力照样不够，须复用同一套等级体系并带上区分标志位。展开在第 3 讲，协议本体前指 F4-02 发动机与电驱热源的协同与切换。

(f) ★ 功能不足触发：没有故障码可报的性能指标越界——1.6 单独讲。

六类共用同一套等级、迟滞与退出语法，只有仲裁输入不同：故障侧输入的是失效模式，策略侧输入的是资源账，功能不足侧输入的是性能指标的越界情况。⛔ 不要因为触发源不同就为其中某一类另起一套等级定义——那会在集成时长出两套互不兼容的状态机。

射程边界：分级告知规则本身（什么级别该说、说什么、在哪个界面说、用什么措辞）属人机交互与整车产品域，⛔ 不在本课射程内。本课只交出两个量：理由（原因码）与等级。

两个易错点：① 用「置不置码」当分类轴，前面已说；② 把告知规则也揽进本课，结果热管理域的降级策略文档里长出一堆界面文案要求，而真正该定的两个量反倒没写清。

1.6 没有故障码可报的「功能不足」，同样要能进降级状态机

是什么。功能不足指的是：件没坏，软件也按设计跑了，但在这个工况下它给出的结果不够用。热管理里的三种典型形态是预警漏报、感知或场景判断误判、模型预测持续失准。它们的共同点是没有任何一条电气诊断会置位——阻值正常、报文正常、合理性校验也过。

判据换一种写法。这一类不能用故障位当进入条件，只能用性能指标越界并持续若干个诊断周期：残差超出容许带、置信度跌破门限、预测偏差持续偏向同一侧。架构上不必另起炉灶，直接复用本课的监控器-执行器结构（第 4 讲）——监控器盯的对象从「电气量对不对」换成「性能量够不够」，其余不变。

为什么必须补这一类。只对硬件故障设降级，这一整类失效就完全没有兜底，而它的现场表现最迷惑：不置码、系统自称健康，却在做对了错的事——按一个错的场景标志位去执行一套本身完全正确的策略。第 5 讲会把这一类里最难查的一种（场景语义判错）单独拆开讲。

工程量级。⛔ 残差带、置信度门限与持续周期数全部是平台相关量，须由本项目的实测或系统仿真给出，本课不给数。这一类失效的论证方法属预期功能安全范畴，本课未取相关标准原文，只写标准号与去向：ISO 21448，方法前指 K2-05 预期功能安全（SOTIF/ISO 21448）与 AI 件安全论证在热管理的落法；版次与年份以现行目录为准，引用前须核。⚠ 同样地，⛔ 不得拿预期功能安全那一侧的条款去管纯电子电气失效那一侧，两者射程不同。

两个易错点：① 拿「有没有码」当降级的必要条件，于是这一类永远进不了状态机；② 把功能不足的门限直接抄自故障诊断的门限——两者的分布形状根本不同，一个是电气量的突变、一个是性能量的缓慢劣化，门限不可互套。

1.7 选哪一种应对哲学看可行性，⛔ 不看严重度——三问定四支

三种通行的应对哲学是：降级（降能力保运行）、冗余切换（切到备份）、直接停机。它们各自的成立前提不同：

• 降级要求剩余能力仍能维持一个可接受的运行点——剩不下这个点，降级就是自欺；
• 冗余切换要求真的存在一条独立的备份路径，独立到不与失效件共用同一路供电、同一个传感器输入、同一段回路；
• 直接停机是前两者都不成立时的兜底。

★ 选择的次序是本课归纳的三问，按序问：① 这个失效之后还剩不剩一条排热路？② 剩的话，有没有独立的备份路径？③ 没有备份的话，有没有能顶替这个自由度的剩余执行器（第四种哲学，见 1.8）？三问都答否，才轮到停机。第一问的校核法可以直接沿用 B3-04 热泵型整车热管理架构（多通阀一体化方案） 在多通阀集成架构里用的那套——对每一个可能的卡死阀位，逐个问「这时候关键部件还剩不剩一条把热排出去的路」——本课把它从多通阀推广到全执行器域。

为什么不能按严重度选。把严重度当选择轴，会得出「严重就停机」这种听起来负责、实际有害的结论。严重度高的真正含义是必须尽快到达某个安全状态，而那个安全状态是什么，取决于还剩什么能力——它可能是「限功率继续跑」，而不是「立刻断电」。严重度只决定要多快到位（1.4），⛔ 不决定选哪一支。

工程量级。⛔ 剩余能力的具体数值是平台相关量，不给数；本课只给三问的次序与「不算独立」的判别形态。冗余硬件要不要上、上几路，属架构与成本决策，⛔ 不在本课射程内——本课只给「有备份时怎么切、切换本身要计入反应时间」。

两个易错点：① 把「有备份件」当成「有冗余」——两路水泵挂在同一路低压供电上、两路水温传感器插在同一个接插件上、两条控制路径跑在同一颗微控制器里，都不是冗余；这条判别在第 4 讲还会从独立性论证的角度再讲一次；② 把停机当成最安全的选择——断高压之后热管理并没有结束，监测与必要的泵仍需供电，这部分的容量与时长约束前指 K2-06 热管理低压供电边界：DCDC 容量、多执行器同时率与 12V 能量保底 与 K3-11 热管理域的上下电时序、run-on 编排与休眠期能耗预算。

1.8 第四种哲学是控制重构：被控量不变，操纵变量换人

是什么。控制重构＝用剩余的自由度顶替失效掉的那个自由度，被控量保持不变，只是换一个执行器去守它。三个立得住的实例：

• 电子膨胀阀卡死后，改用压缩机转速去守过热度；
• 水泵被限速后，改提风扇转速并下调目标水温，用另一条路把同样的热排出去；
• 温度门卡在冷位后，用加热器功率配合风量重建出风温度。

三者的共同点是同一句话：被控量不变，操纵变量换人。

为什么它是并列的第四类，而不是降级的一个子类。因为它改变的是可用能力本身，而降级改变的是「在既定能力上怎么分配」。不承认它是独立的一类，重构就会以「某某部件的特殊处理」的形式散落在各个部件章节里：同一套思路被写十遍，十遍互不一致，而且没有任何一处能回答「重构之后这个模式还算不算可用」。承认它是一类之后，它就有了统一的交付物。

交付物是一张模式可用性矩阵：行＝失效模式，列＝K3-01 整车热管理控制策略总览与模式管理 已经定义好的模式集，格＝该模式仍可用 / 降级可用 / 下架三选一。⛔ 矩阵不另起炉灶——列直接复用 K3-01 整车热管理控制策略总览与模式管理 的模式表，⛔ 不许在本课重新定义一套模式名；行由本项目关心的失效模式清单给出。矩阵的规模就是模式数乘以关心的失效模式数。

工程量级。⛔ 格里填什么是平台相关的判断结果，本课只给矩阵的形式与填法，不给任何平台的填充值。重构后各执行器能顶到多少，仍要靠 1.1 那次翻译给出的保守估计。

两个易错点：① 重构后忘了改约束——压缩机转速原本就同时守着过热度、排气温度与高压保护，让它再去顶替膨胀阀的自由度，等于用一个操纵变量去满足更多约束；原来的约束不会因为顶替而自动消失，可行域会被压得很窄甚至变空，这一点必须在矩阵里体现为「降级可用」而不是「可用」；② 把「格里填可用」当成「性能不变」——矩阵必须严格区分「可用」与「降级可用」两格，合并之后仲裁会按满能力去分配，缺口要到下一拍才暴露。

1.9 限值判据有第三类：累积型剂量——在线触发与离线定寿是两种用法，⛔ 数值不得互取

三类判据并列。① 绝对阈值：被测量越过限值即触发，抓的是「已经到了不该到的地方」；② 变化率阈值：变化率超限即触发，抓的是快速异常，它能在越限之前动作；③ ★ 累积型剂量：对被测量做加权积分（∫f(T)dt 这一类形式），积分量越过预算即触发，抓的是「瞬时从不越线、但长期待在高位」。

为什么第三类不能省。只装前两类，有一整类工况完全不触发保护：长期在高温段徘徊却始终不越线。它对寿命的消耗是真实的，而两类瞬时判据在结构上就看不见它——不是阈值调得不对，是判据的形式里没有时间这一维。

它与离线定寿的关系，是本条最容易错的地方。在线剂量与离线寿命折算共用同一套算账方式：把一段历程按某个加权函数累积成一个损耗账，越过预算即判定。加权函数常取阿伦尼乌斯型（温度越高，单位时间计入的账越重）。但两者用法完全不同：离线那一支用它折算等效老化、据以定限值，在线这一支用它触发保护。⛔ 两者的加权参数、基准态与时间窗定义各不相同，数值一律不得互相取用——离线折算出来的等效老化小时数，⛔ 不能直接当成在线的剂量预算。离线那一侧前指 D1-04 电池老化、寿命与温度的耦合关系、G2-07 换热器芯体强度、耐压与热疲劳设计、I6-01 振动、热冲击与压力脉冲耐久设计。

本行的一个实例，补在电池与功率器件之外：传动与机油的油温超温剂量累积。油品劣化速率对温度高度敏感，因此「在多高的温度下待了多久」比「峰值到过多少」更能刻画损耗。在线实现就是对油温做阿伦尼乌斯加权积分，越过预算即请求降扭。举这个例子有两个用意：一是证明第三类判据不是电池专用（只举电池会让人误以为它是电化学的特殊性），二是它恰好也有一支离线用法——同一条加权被用来折算等效老化以确定油温上限，那一侧前指 F3-04 润滑失效判据与油温上限的推导：动压/弹流油膜、λ 膜厚比、齿面胶合与氧化寿命线。同一条加权，两种用法，参数不通用。

工程量级。⛔ 加权函数的参数、剂量预算、时间窗与衰减因子全部是平台与介质相关量，随被保护对象与油品或电芯配方而定，须由本项目的加速老化对标确定，本课不给数、不给参考区间。

两个易错点：① 在线剂量必须定义时间窗与衰减（滑动窗或带遗忘因子），⛔ 不能做成不可复位的单调累积——否则一辆开了三年的车会永久停在降额态，而这个后果在开发期的任何一次测试里都看不到；② 把剂量判据的触发当成「故障」置码——它在语义上更接近保护性降额，是否置码按 1.2 第二对的分层判，第 3 讲展开。

1.10 降额曲线只管温度这一条自变量——它的射程必须当场说清

是什么。降额曲线把允许功率写成温度的连续函数：P_limit(T) = P_max · f(T)，温度升高时降额因子 f 减小。工程实现通常是分段线性或查表加插值。对它的形状要求有三条：f 单调不增、无阶跃、带迟滞。

为什么要连续。阶跃式降额在用户侧的表现是「突然没劲」；更糟的是它在阈值附近会与迟滞不足叠加成反复跳变，一次工况波动就能让车在两个功率档之间来回切。连续降额把同一件事摊开在一段温度带上，代价是同样的，感受完全不同。

⚠ 但必须同时把它的射程说清，这是本讲最容易被读漏的一句。降额曲线以温度为唯一自变量，因此对「能力已经被打掉、而温度还没来得及起来」这一段是全绿的——泵坏了，冷量当场没了，可水温还得过一会儿才升上来；等它升上来触发降额时，留给检测与执行的时间可能已经不够了。⇒ 只画一条降额曲线不等于做完了降级：它必须与需求缺口那一支联立，两式各管一段，缺哪一段都是漏判。缺口那一支怎么写、两式怎么联立取更深的一档，是第 3 讲的内容。

工程量级。⛔ 折点温度、斜率与迟滞宽度全部是平台相关量，取决于被保护对象的温限与本项目的性能取舍，须由本项目标定，本课不给数。

三个易错点：① 拿它一条就当降级做完了（上一段）；② 迟滞只在进入侧做而退出侧不做，结果系统沿着曲线来回滑；③ 在图上给折点标一个具体温度——判为不给数的量，在正文不给、在图与图注里同样不给，正确画法是画成一条可沿温度轴平移的带并标明「位置由本项目标定给出」，否则读者会把示意图上的刻度当成可取用的取值。

1.11 「重试—放弃—降级」要有三条终止线，谁先到就停

是什么。执行器动作失败之后（阀走不到位、风门顶不动、泵起不来），普遍要先试着自救：正反转解卡、退避再试。这条自救逻辑必须写成一个有终点的规格，本课把它固定为三条终止线：

1. 次数用完——限次 N；
2. 总时限到——退避间隔逐次拉长时，次数没用完而时间早就超了，这条线专管这种情形；
3. 累计热预算用完——重试期间线圈或绕组的温升累计，接执行器本体的过温降额，本体前指 K1-02 执行器驱动：电子阀/泵/风扇/压缩机 PWM。

任意一条先到即放弃，随即置码并进入对应的降级等级。

为什么三条都要有。缺它的后果是双重的，而且两个后果的形态完全不同：无限重试等于把反应时间写成无穷大，时间预算必破，可这件事在功能测试里看不出来（每一次重试都"正常"）；反复堵转会把一个可恢复的结冰卡滞做成永久烧毁——本来停一会儿化开就能用的件，被自救逻辑烧成了必须更换的件。第三条线（热预算）恰恰是最常被漏掉的一条，而低温结冰解卡正是它最先到的工况。

规格通用，取值不通用。这套形状对阀类、风门、鼓风机一律适用，⛔ 各部件课只给自己的参数取值，⛔ 不许各写一套语义——空气侧执行器的重试口径与本课必须对齐，部件侧的本体前指 C2-03 风门驱动电机与执行器（步进/有刷/PWM）选型。

工程量级。⛔ 次数上限、退避间隔、总时限与热预算全部是平台与部件相关量，随机构与失效机理而定，本课不给数、也不给参考区间；本课只固定规格的形状与这三条终止线。热预算那一条须查所选件的绕组热模型与过温降额门限，并与本项目的两层阈值排队对齐（前指 K1-02 执行器驱动：电子阀/泵/风扇/压缩机 PWM）。

三个易错点：① 只写次数不写总时限；② 忘掉热预算这条线；③ 语义分叉——同一件事在部件课与本课各写一套，集成时才发现两边对「一次尝试」的定义都不一样。

1.12 「退出条件满足」只等于允许回切——回切那一拍必须预置

是什么。降级期间，控制器多半处在限幅或开环状态：积分器要么被冻结、要么已经饱和，前馈基准也停在降级态那一套。退出条件满足的那一刻，如果直接把自动回路接回来，积分项与前馈基准都不对应当前的实际输出，输出就会跳一下。预置＝在回切那一拍，用当前实际的执行器输出反算出积分项应有的初值，把它写进去再接管。

为什么这一格值得单独讲。把整个生命周期摊开看——上电初始化 → 运行 → 降级 → 恢复回切 → 下电 → 售后清除——各级定义普遍写了进入条件和退出条件，没有一级写了回交那一拍。这个空白格不是被判断错了，是从来没有被列入过要填的格子里（这也正是 1.3 把它补成第五要素的原因）。而用户对恢复瞬间的冲击比对降级本身更敏感：降级时他知道车有点问题，恢复时他以为已经好了，这一下顶就成了新的抱怨。

工程量级。⛔ 预置的具体反算式随控制结构而定（比例积分、串级、带前馈的形式各不相同），本课只给要求与去向，无扰切换的具体手法前指 K3-05 PID/前馈/增益调度控制实战。

两个易错点：① 把「退出条件满足」直接当成「已经回切」——中间还差预置这一拍与一段过渡；② 把回切与迟滞混为一件事——迟滞防的是反复进出（时间维度上的抖动），预置防的是切换那一拍的阶跃（幅值维度上的跳变），两件事都要做，做了其中一件不能替代另一件。

1.13 部件本地控制器的自主降额是隐性触发：不消费状态字，就有一个「系统已在降级、整车不知情」的空档

是什么。电动压缩机、电子水泵、高压加热器这类带本地控制器的件，普遍有自己的过温、过流、堵转保护。触发之后它们自主降转速或限功率，而且不一定向整车报故障——在它自己看来这是正常的自我保护，不是失效。⇒ 它们的本地降额必须被明确列入整车降级等级的进入条件来源之一，而不是当成附注。

不消费它的状态字，会同时出现三个后果，而且是叠加的：① 等级判不出来——系统实际已经在降级，等级体系里却还是「正常」，于是对外声明是错的；② 仲裁仍按满能力分配——分下去的那份冷量根本不存在，缺口要等到下一拍温度起来才暴露；③ 诊断抓不到——没有码、没有记录，售后拿不到任何线索，最后以「查无故障」结账。

要消费的状态字至少含四项：当前是否已在本地限值内、限到多少、限的原因、是否可自恢复。⚠ 各供应商的状态字语义先要统一——这与第 3 讲讲的「执行器回传能力上限」是同一条通道，⛔ 不要为它另开一路接口。

工程量级。⛔ 各件的本地保护门限、降额斜率与恢复条件都由部件规格决定，本课不给数；部件层保护的归属与两层阈值怎么排队前指 K1-02 执行器驱动：电子阀/泵/风扇/压缩机 PWM，功能分配矩阵与仲裁的输入要求前指 K3-01 整车热管理控制策略总览与模式管理。

两个易错点：① 只订阅了转速反馈而没订阅状态字——转速掉下来看得见，为什么掉下来看不见，于是被误判成「指令没跟上」，接着去查控制环、查总线，方向从第一步就错了；② 责任边界越界——本课管的是「整车知道之后怎么降」，⛔ 不管部件内部该怎么保护自己。

1.14 射程边界：热安全事件不走这条链，两者的优先序是相反的

最后把本课的射程明写在正文里，免得整门课被当成「热管理出任何事都归它」的总纲。

射程内：部件与信号失效——泵、风扇、阀、传感器、报文、模型估计不可用。它们的共同点是系统还想继续工作，只是能力变差了，本课的目标函数是「保住温控性能、尽量少降、降了要能回来」。

射程外：热失控、碰撞后、充电与充满静置期间起火这一类热安全事件触发的应急动作链。它们的目标函数已经从「工作」换成「止损」：切断能量输入、保住监测供电优先于恢复温控性能——与本课的优先序正好相反。⛔ 两套策略不能合并进同一个仲裁器，否则会在最危险的场合按本课的优先序办事。这一类的判据、阈值与动作链本课一律不给，只写去向：前指 D5-06 充电与充满静置工况的电池热安全应急响应与桩车联动（充电与充满静置工况的应急响应与桩车联动）、D5-04 碰撞后电池热管理应急响应（碰撞后应急响应）、D5-01 热失控热扩散抑制（热管理与结构协同）（热失控与热扩散抑制）。

同样在射程外的还有两格，一并说清：控制器自身（微控制器、看门狗、电源、非易失存储、时钟）的失效——本课只声明一条独立性要求「降级逻辑不得与被监控对象共用同一颗微控制器或同一路供电」（第 4 讲），硬件架构与存储介质前指 K4-06 控制器非易失存储设计：学习值、诊断数据与累计量的持久化；整车层的断高压与停车决策——决策权属整车高压电气与整车安全，本域只交出请求与自己的执行器。

两个易错点：① 把「电池温度很高」当成热安全事件——高温是本课射程内的能力不足，热失控有它自己的判据，两者混了会让通用降级链去处理一件它接不住的事；② 反过来把热失控标志位只当成一个降级触发源接进本课状态机——那会让最该走专用链路的事件走了通用链路，而通用链路的第一动作是「尽量保住温控性能」。