K3-16 座舱 HVAC 请求源仲裁与人机接管：安全强制、AUTO 退出/恢复与设定记忆

课程代码 K3-16 · 板块 K 控制、软件与标定 / K3 控制策略与算法 时长 约 4.0 小时（5 讲 + 1 次「请求源优先级—抢占矩阵 + 记忆/复位分类表」实操） 适合对象 座舱空调控制/标定工程师（主修）· 热管理域控软件与人机交互接口负责人（必修）· 系统工程师与售后归因岗（选修） 前置 C6-01 双区/四区自动空调控制逻辑 双区/四区自动空调控制逻辑（TAO 链路、三张 MAP、夺权表的雏形）· C2-09 内外循环风门与新风控制 内外循环风门与新风控制 · C5-03 低温起雾机理与主动防雾控制 低温起雾机理与主动防雾控制（露点裕度 ΔT_margin）· K3-01 整车热管理控制策略总览与模式管理 整车热管理控制策略总览与模式管理（仲裁骨架、迟滞与最小驻留、限值横切通道） 本讲义定位 讲师授课蓝本 / 学员自学讲义。本课是座舱侧的权限立法：只立「谁能压过谁、被压过要不要告诉用户、压制结束回到哪一态、这一切怎么被看见」四件事。⛔ 本课不推任何判据本体、不给任何动作细节、不出任何标定数值

---

按任务导航

你手上的事	直接看	还要配
座舱侧到底有几路人在下指令，要列全	第 1 讲 1.1~1.2：五类请求源与六入口→四自由度	第 1 讲 1.4：三字段权限模型，缺一个就是悬空定义
有人问「防雾能不能违背用户刚按下的 A-C OFF」	第 2 讲 2.1：越权判据只判「能不能越」，⛔ 不重推判据本体	第 2 讲 2.3：越了之后要夺多少
强制介入范围定不下来，一派说全夺一派说只借风量	第 2 讲 2.3：最小充分介入量 H_min 的取法与分级	图3：三级夺权阶梯
要把热失控/烟气这一档加进优先级，不知道加在哪一层	第 2 讲 2.5~2.6：加在防雾之上，且是新加一层不是加一个第五档	图4：新旧两条阶梯对照
有人提「安全事件档照抄 AQS 的自动复位」	第 2 讲 2.7：三条特殊语义，缺一条就退化	图5：自锁与自动复位的两条时序对照
用户碰一下风量，整个空调就「变笨了」	第 3 讲 3.1~3.2：AUTO 是四个自由度不是一个开关	图6：夺权粒度矩阵
要定义「部分 AUTO」这一态该怎么显示、怎么判读	第 3 讲 3.3：部分 AUTO 是合法常驻态，必须写出定义	第 5 讲 5.2：不定义它，售后无从归因
要写回归 AUTO 的条件	第 3 讲 3.4：三条路径，超时收回须给白名单	图7：三条路径的状态图
SYNC 置位/解除时副驾设定该怎么办	第 3 讲 3.6：SYNC 与驾驶员优先权的可下发规则	图8：三种写法与各自的用户观感
要交一张「哪些设定记忆、哪些强制复位」的表	第 4 讲 4.1~4.3：分类表结构与逐行理由	图9：三档分类与三类不得记忆态
上电头几秒风门乱动	第 4 讲 4.5：设定项回放必须晚于执行器找零	图10：上电恢复次序
远程预调好了，上车瞬间以谁为准	第 4 讲 4.6：交接判据	D3-04 低温预热与出行预约热管理（预调侧的能量账止于上车前）
投诉「空调自己开 A-C」，要归因	第 5 讲 5.1~5.2：可观测三元组与三类根因	图11：归因链
要生成场景用例矩阵	第 5 讲 5.3：按「请求源 × 请求源」配对生成	图12：矩阵的空格＝待定义权限
要出标定量清单与验收口径	第 5 讲 5.4~5.5：清单 + 四个可测量	⛔ 数值不在本课 → K6-01 热管理标定流程与工具（INCA/CANape）

⛔ 本课不覆盖 · 栏一（每样带去向）：机—机仲裁骨架（P_alloc = argmax(w·urgency)、按权分摊式、urgency 折算、迟滞带 ΔT_hys 三项下界与最小驻留 t_dwell_min、目标值斜坡过渡、非用户模式五要素、限值保护层横切通道）→ K3-01 整车热管理控制策略总览与模式管理；冷却侧「多路热请求 → 执行器需求」的机侧合成 → K3-08 冷却侧执行器需求生成与协同仲裁：电子水泵/冷却风扇/AGS；露点裕度 ΔT_margin 的定义、玻璃温度估算与防雾手柄折算 → C5-03 低温起雾机理与主动防雾控制；CO₂/AQS 门限、最小新风量、内外循环切换阈值与迟滞、安全事件强制置位的座舱侧动作细节 → C2-09 内外循环风门与新风控制；蒸发器防冻结下限与压缩机侧取值 → K3-02 空调温控与压缩机转速/过热度控制（制冷与制热两模式）；TAO 链路、三张 MAP、warm-up 抑制的进入与解除 → C6-01 双区/四区自动空调控制逻辑；左右温区能力边界与串扰系数 → C2-08 温度分层（stratification）与左右温区控制；热失控/烟气的触发源与再侵入物理 → D5-02 隔热、泄压与排烟设计中的热管理边界；碰撞后应急响应链 → D5-04 碰撞后电池热管理应急响应；整车安全响应链里的执行器归属与去激励默认位方向冲突 → I7-02 失效安全（Fail-safe）与冗余设计；事故态门位的漏风量验收口径 → C2-09 内外循环风门与新风控制 / C2-10 空调箱密封与漏风（air leakage）控制；正常态舒适降级的告知/静默分级 → K3-07 能量最优的整车协调控制；非故障降级的提前预告范式 → C3-04 除霜循环与化霜策略（热泵）；故障态提示分级 → K5-01 OBD/UDS 诊断与故障码（DTC）设计 / K5-03 制冷剂泄漏检测与安全响应；run-on 续跑的可见化 → C2-12 冷凝水排放、防霉与蒸发器自清洁；降级等级体系、可用模式矩阵与跛行退出的中间过渡档 → K5-02 热管理故障处理与降级策略；NVM 校验与缺省回落机制 → K1-02 执行器驱动：电子阀/泵/风扇/压缩机 PWM；跨版本数据布局兼容性声明 → K4-04 软件版本、配置与变量管理；Init 端点态、上下电时序与唤醒许可判据 → K3-11 热管理域的上下电时序、run-on 编排与休眠期能耗预算；远程预约的能量账与 t_start 反推式 → D3-04 低温预热与出行预约热管理；预测输入（导航/云端/驾驶意图）→ K7-01 预测性热管理（导航/云端/驾驶意图协同）；在线学习与个性化偏好护栏 u_final = clip → K7-03 数据驱动的能效自学习控制；用例矩阵的完备性核对手法 → K4-05 模式状态机的完备性核对与可验证性设计；模式表与仲裁规则的静态体检（可达性、死锁、切换质量）→ K3-13 模式表/场景表与仲裁规则的静态体检：可达性、死锁与切换质量；标定落地方式与 DoE → K6-01 热管理标定流程与工具（INCA/CANape）；热泵多模式相关取值 → K6-07 热泵与多模式切换标定。

⛔ 本课不覆盖 · 栏二（真正不给的数）：① 任何安全强制档的进入/退出门限数值（露点裕度阈值、CO₂ 门限、蒸发器防冻结下限、部件热保护限值）——判据本体属被引用的那几门课，数值属标定，本课⛔ 一格不填，只写「这一档能不能越过用户」；② 标准条款的具体内容与限值——本课引用的标准件族只写「它在本课里承担什么角色」，版次与实施日期以现行目录为准，引用前须核原文；③ 各车型的实际优先级序号与手柄集配置——那是每个平台自己的立法结果，本课交出的是表的结构、每一格的判据类型与来源，不是别人家的表。

⚠ 栏二之外的平台相关量（强制介入的响应时延、生效请求源切换的去抖时间、强制介入持续时长上限、AUTO 超时收回时长、回执出现率与还原正确率的合格线、误抢占次数）本课照给典型区间与常见值锚点，逐条标「⚠ 典型值、⛔ 不是验收依据，须实测确认」与拿到它的路。汇总表在 5.6。

---

引言：功能全对，用户说「这车不听话」

一台纯电 SUV 上市第二年，冬季雨天投诉集中爆出来。用户的原话高度一致：我明明关了 A-C，车过几分钟自己又开了；风量我压到最低，它自己往上跳；仪表上什么都没写。另一批投诉是另一句：上一趟车除过霜，这一趟上车又是满风对着玻璃吹。

工程侧第一轮排查的结论是「功能正常」——防雾策略按露点裕度介入，判据成立、介入正确、玻璃确实没起雾。这个结论没有错，但它答的不是用户问的那个问题。用户问的是权限：我作为车里唯一的人，刚刚显式地说了「不要 A-C」，凭什么这句话可以被推翻？推翻了为什么不告诉我？什么时候还给我？

这就是本课的位置。整个座舱空调的控制链上，「谁算出多少」这一层已经有课了——TAO 怎么算、三张 MAP 怎么派、防雾要抬几 K 裕度、CO₂ 门限怎么定、多子系统抢同一个执行器怎么分配。缺的是上面那一层：这一帧的指令到底该听谁的。而这一层不是一个算法问题，是一部法——它由一张表构成，表里每一格都是一次立法，格子空着，量产上就由实现者各自发挥。

钉子①（贯穿全课）：本课的对象不是「量」，是「权」。每一条请求都有一个来源，本课只处理来源之间的四件事——优先级（谁能压过谁）、可见性（被压过要不要给用户回执）、退出（压制结束回到哪一态）、可观测（这一帧到底是谁在写）。凡是「这个量该取多少、这条判据怎么推、这个动作怎么执行」，一律引用不重讲。判断一句话该不该写进本课，只用一个自检：把它里面所有的数字与物理都删掉，它还剩下东西吗？剩下的那部分才是本课的。

钉子②：一条请求的完整身份是四元组，⛔ 不是一个数。本课沿用 K3-01 整车热管理控制策略总览与模式管理 的请求四元组〈请求源、目标量与量值、有效性、可让度〉，只把「请求源」这一列从整车四域枚举细化到座舱人机侧的五类——⛔ 不另起一套字段，两套字段在同一个域控里并行是后患。这条钉子在第 1 讲落地成表、第 5 讲落地成可观测量。

钉子③：只要用户可以被推翻，就必须有回执。本课把「必须可见」写成硬条款而不是体验建议，理由是可核对的：静默改写让投诉不可归因——用户说「空调突然不给力」，而上游让路、安全强制介入、用户自己停在部分自动态这三类根因的现象几乎相同（第 5 讲展开）。不暴露当前生效请求源，标定与售后就只能猜；能猜对是运气，猜错的代价是把一次权限缺口改成一次标定补丁，从此再没人能从表里看出这本账当初记错了。

本课的两件交付物先摆出来，五讲都是围着它们转的：请求源优先级—抢占矩阵（第 1、2 讲立结构，第 5 讲给用例与验收）与记忆/复位分类表（第 4 讲）。它们的最终数值不在本课产出——本课交出表的结构、每一格的判据类型与来源。

---

第 1 讲　请求源清单与权限模型：座舱侧到底有几路人在下指令

这一讲不做任何优先级排序，只做三件事：把请求源枚举全、把人机入口翻译成被夺权的对象、把权限模型的三个字段钉死。顺序不能倒——先排优先级再枚举来源，必然漏掉那些「平时不出现、出现时最要命」的路（诊断跛行与整车安全事件正是这两路）。

1.1 五类请求源必须显式枚举，每类固定三列

座舱侧的指令来源不是「用户和自动」两类，是五类。下面这张表是本课第一件交付物的骨架，⛔ 它不是一张讲义插图，是要被填出来、评审掉、进设计文档的东西。

请求源类别	它包含什么	可抢占性（能被谁压过）	抢占后是否需回执	同类内部冲突的处置
① 显式用户请求	AUTO 键、A-C 键、循环键、风量、温度、出风模式六个人机入口	可被 ③ 压过；⛔ 不可被 ② 压过；与 ④ 的关系由交接判据定（4.6）	必须——被压过的是人，人有权知道	同一自由度被两个入口先后改写，以后到者为准（1.2）
② AUTO 策略内生请求	自动空调链算出的风量/温度/模式/循环目标（TAO 链路见 C6-01 双区/四区自动空调控制逻辑）	可被 ①③④⑤ 中任一压过	⛔ 不需要——机器让位给人不是事件	单一策略源，无同类冲突
③ 安全强制请求	整车安全事件、除霜除雾、AQS/CO₂、蒸发器防冻结、部件热保护、功率降额	档内分层（第 2 讲）；最高档⛔ 不可被 ① 抢占	必须，且要写明「做什么、为什么、大约多久」	档内按第 2 讲的阶梯，同档并发取手柄集并集而非二选一
④ 远程与预约请求	手机远控即时预调、预约出行预热/预冷（能量账见 D3-04 低温预热与出行预约热管理）	上车前可被 ③ 压过；上车后由交接判据交给 ①（4.6）	上车后被 ① 接管时需在车内可见	预约与即时远控叠加、重复点击去重（1.6）
⑤ 诊断跛行请求	诊断例程占用期间的请求、降级/跛行态下的可用集收缩（等级体系见 K5-02 热管理故障处理与降级策略）	可被 ③ 的最高档压过；对 ①② 是限制而非竞争	必须——用户会先感到「变弱」再看到故障灯	多个降级并发时取最严，⛔ 不取最近发生的那个

三件事值得就地说破：

（a）「可抢占性」这一列填的是关系，⛔ 不是一个布尔值。写「可抢占 = 是」等于什么都没写——必须写清能被谁抢占。一张只有「是/否」的表在评审桌上永远吵不完，因为每个人心里的「谁」都不一样。

（b）②「不需要回执」是一条正面的规定，不是省略。自动策略让位给用户是这台车该有的行为，为它弹提示只会训练用户忽略所有提示。把它显式写成「不需要」，下一个改这段代码的人才知道这里被想过。

（c）⑤ 对 ①② 是限制而不是竞争。跛行不是「跟你抢风量」，是「风量的可用集本身缩小了」。这个区分决定了它在实现上落在哪一层：限制走的是横切的钳位通道（这条通道的结构见 K3-01 整车热管理控制策略总览与模式管理），⛔ 不作为一路加权需求参与求和。混在一起的后果是被权重摊薄——该按住的时候没按住。

1.2 显式用户请求按夺权对象分列，⛔ 不按按键分列

这是最容易写反的一步。人机侧有六个入口（AUTO 键、A-C 键、循环键、风量旋钮/滑条、温度旋钮/滑条、出风模式键），但它们最终只落到四个自由度：风量、温度、出风模式、内外循环。按按键列表，你会得到一张六行的表，而其中两行（AUTO 键与 A-C 键）根本不对应任何一个自由度——AUTO 键改的是「谁来写这四格」，A-C 键改的是热源侧的使能。

正确的做法是列一张「入口 → 自由度」的映射，并允许多对多。

人机入口	它直接改写的自由度	它顺带改变的东西
风量	风量	触发该自由度退出自动（3.2）
温度	温度（本质是改 T_set，进而改 TAO，链路见 C6-01 双区/四区自动空调控制逻辑）	触发温度自由度退出自动
出风模式	出风模式	触发该自由度退出自动
循环键	内外循环	触发该自由度退出自动；可能与安全强制正面冲突（第 2 讲）
A-C 键	⛔ 不直接改写四个自由度中的任何一个	改的是制冷/除湿能力的使能，它是「用户显式说不」的最典型载体
AUTO 键	⛔ 不改写任何自由度的值	改的是这四格的写权归属（一次把四格全交回控制器）

同一自由度被两个入口先后改写时，以后到者为准。这条规则本身没有争议，但它不写死就会不一致——同一平台不同车型，只要人机层由不同团队实现，就会出现「风量滑条能盖过语音、语音盖不过滑条」这类不对称。⇒ 这条要写进表里，作为①类内部冲突的处置。

为什么 A-C 键必须单列。因为本课第 2 讲整讲要处理的那个问题——「安全强制能不能违背用户显式的 A-C OFF」——的对象就是它。若把 A-C 折进「温度」这一格，这个问题会在表上消失，而它在车上不会消失。

1.3 权限模型只有三个字段，但一个都不能缺

优先级 — 回执 — 退出。三个字段，各回答一个问题：

• 优先级：这一路能压过谁、被谁压过。⇒ 缺了它，两路同时来时结果由代码写的先后顺序决定，而那个顺序没有人评审过。
• 回执（可见性）：被压过之后要不要给用户一个交代、交代什么。⇒ 缺了它，功能正确而体感是「车不听话」，且投诉不可归因。
• 退出：压制结束之后，被夺的那一格回到哪一个值。⇒ 缺了它，是本课见过最隐蔽的一类缺陷：介入正确、退出也发生了，但交还的是 AUTO 默认值而不是用户原来那个设定值，用户的感受是「它把我的设置吃了」。

缺任一字段的请求源都是悬空定义。最典型的悬空定义是远程预调：几乎每台车都能远程把座舱预热好，而「用户开门上车的那一瞬间，这套预调设定交给谁」——这一格在很多平台上是空的。空着不会报错，只会在用户第一次伸手调温度时表现为拉扯（交接判据见 4.6）。

三个字段的自检法（当场可做）。拿你手上那张表，随便指一行，问三句话：它被谁压过？被压过时用户看到什么？压制结束后那一格是几？三句里有一句答不上来，这一行就是悬空的。⚠ 这个自检的价值在于它不需要任何数值——不必等标定，设计阶段就能做。

1.4 与 K3-01 划界：那是机—机，这是人—机

K3-01 整车热管理控制策略总览与模式管理 第 3 节给的是机—机骨架：多个子系统争抢同一个执行器时，按 P_alloc = argmax(w·urgency) 或按权分摊式分配。它解的是「几个都是机器的请求怎么排队」。

本课解的是人—机权限。差别不在算法上，在被仲裁对象的性质上：机—机那一侧，输的那一路只是拿不到资源，它不会「觉得车不听话」；人—机这一侧，输的那一路是坐在车里的人，因此多出两件机—机侧根本不存在的义务——回执与退出还原。

⇒ 本课沿用而不重推：argmax 式、按权分摊式、urgency 的折算方式、迟滞带 ΔT_hys 的三项下界、最小驻留 t_dwell_min、目标值的斜坡过渡、非用户模式的五要素、限值保护层的横切通道——全部引 K3-01 整车热管理控制策略总览与模式管理。本课在它之上只加两列：回执与退出还原。

1.5 与 K3-08 构成对偶：机侧合成 vs 人侧仲裁

K3-08 冷却侧执行器需求生成与协同仲裁：电子水泵/冷却风扇/AGS 做的是「多路热请求 → 冷却侧执行器需求」的机侧合成：电驱、电池、加热器、除霜各自把原生量折算成同一量纲，再高选/低选合成出泵转速、风扇转速、格栅开度。本课做的是「人/安全/自动/远程 → 座舱设定」的人侧仲裁。

两课共用同一套仲裁语言，但被仲裁对象与请求源清单完全不同——这句话必须写在两课之间，否则读者会把一课的表直接搬到另一课上。

⚠ 跨课口径提醒（本课与 K3-08 冷却侧执行器需求生成与协同仲裁：电子水泵/冷却风扇/AGS 的符号衔接，动手核过）：K3-08 冷却侧执行器需求生成与协同仲裁：电子水泵/冷却风扇/AGS 在需求合成的输出上定了一个三元组 ⟨n_out, i*, j*, t_active,j⟩——n_out 是这一帧下发的转速，i* 是赢者需求标识，j* 是生效限值标识，t_active,j 是这个压制者连续压了多久。本课在人机侧沿用同一结构，但把标识的取值域换掉：

	K3-08 冷却侧执行器需求生成与协同仲裁：电子水泵/冷却风扇/AGS（机侧）	本课（人机侧）
输出量	n_out：某个执行器的转速/开度	u_out：某个自由度的生效设定值
赢者标识	i*：取值域＝各路热请求（电驱/电池/加热器/除霜…）	s*：取值域＝本课的五类请求源及其档内细分
压制者标识	j*：取值域＝各条限值	本课不另设——安全强制在人机侧就是一路请求源，落在 s* 的取值域内
连续生效计数	t_active,j	t_active,s*

⛔ 两个标识不可互代：i* 与 s* 都叫「赢者」、都是枚举量、都是每帧一个值，而取值域根本不是同一个集合。把冷却侧的 i* 直接接到座舱屏上，你会看到「电驱」这样的字样出现在一次防雾介入里。⇒ 实现上两者必须是两个独立信号，各自带自己的枚举定义。

1.6 同类内部冲突要落到实例，⛔ 不能只写「按规则处置」

「同类内部冲突的处置」这一列如果只写四个字「按规则」，它就是空的。下面四个实例是量产上真会撞的，逐条给处置口径：

（a）两名乘员同时改左右温区。这属 SYNC 权限，第 3 讲 3.6 展开。要点：风量是共用变量，两侧同时改它必须先定优先权；温度左右可以真独立，但能力边界（能拉开多大温差）不在本课，见 C2-08 温度分层（stratification）与左右温区控制。

（b）预约与即时远控叠加。用户设了 7:30 预约，6:50 又用手机点了一次即时预调。两条语义都成立：覆盖（后者取代前者）或排队（先跑即时的，到点再跑预约的）。本课不替平台选，但要求显式选一个并写进表——两者的用户观感差别很大，而代码默认行为通常是「谁最后写的变量谁生效」，那既不是覆盖也不是排队，是巧合。

（c）重复点击去重。用户在手机上连点三次「立即预热」。去重窗口的时长属标定量（5.4 清单），但去重的语义属本课：三次点击是「一次请求」还是「三次覆盖同一目标」——若目标值相同则等价，若中间改过目标温度就不等价。⇒ 去重必须按目标值分组，⛔ 不能只按时间窗。

（d）诊断例程期间用户请求如何挂起。诊断例程占用执行器时，用户的请求既不能丢也不能立即执行。处置只有两种：挂起后回放（例程结束后把最后一次请求补上）或直接拒绝并给回执。⇒ 选哪一种取决于例程时长——短例程挂起回放，长例程必须拒绝并告知，否则用户会连按数次，例程一结束就连着执行好几个动作。非用户模式的五要素（谁能进、进的条件、退出条件、用户可见性、超时兜底）见 K3-01 整车热管理控制策略总览与模式管理，本课只填「座舱侧这一路的挂起语义」这一格。

1.7 请求四元组不另起一套

本课每一条请求沿用 K3-01 整车热管理控制策略总览与模式管理 的四元组：〈请求源、目标量与量值、有效性、可让度〉。

• 请求源：本课把这一列从整车四域枚举细化到座舱人机侧的五类（1.1 的表）。⇒ 这是本课对四元组的唯一改动。
• 目标量与量值：座舱侧取值域是四个自由度之一及其量值。
• 有效性：这条请求还算不算数（远程预调超时、诊断例程已结束、安全事件已由整车侧解除）。
• 可让度：这一路愿意让多少。⚠ 人机侧有一个机侧没有的特例——显式用户请求的可让度不是一个连续量：用户说「A-C OFF」，没有「让一半」这回事，它要么被推翻要么不被推翻。⇒ 实现上①类的可让度是二值的，而②类是连续的。这一条不写清，加权求和会把用户请求做成一个可以被稀释的权重项，那正是「功能全对、用户说不听话」的机制来源。

⛔ 别在同一个域控里并行两套字段。座舱侧另起一套字段名（哪怕语义完全一样）的直接后果是：跨模块的信号无法直接接、诊断工具上出现两套枚举、而写这两段代码的人各自都认为自己是对的。