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

课程大纲

• 能枚举座舱侧五类请求源，并为每类填出可抢占性、抢占后是否需回执、同类内部冲突的处置，落成一张请求源优先级—抢占矩阵
• 能给出安全强制请求压过用户显式请求的判据、最小充分介入量与退出条件，并说明「整车安全事件」一档为何不可被用户显式请求抢占、为何不得自动复位
• 能把 AUTO 拆成风量/温度/出风模式/内外循环四个自由度，定义部分 AUTO 的合法态、三条回归 AUTO 的路径与 SYNC/驾驶员优先权的可下发规则
• 能交付热管理相关设定项的记忆 vs 强制安全复位分类表，并逐行给出理由，说明除霜强制态、整车安全事件置位态与跛行态不得记忆的原因
• 能定义当前生效请求源在测量口的暴露方式与场景用例矩阵，把「空调自己开 A-C」「风量自己往上跳」这类投诉归因到具体请求源
• 能列出本课的标定量清单与四项可测量验收口径（介入响应时延、回执出现率、误抢占次数、退出后设定值还原正确率）

1. 请求源清单与权限模型：座舱侧到底有几路人在下指令
   • 五类请求源必须显式枚举：显式用户请求（AUTO 键/A-C 键/循环键/风量/温度/模式）、AUTO 策略内生请求、安全强制请求（整车安全事件、除霜除雾、AQS/CO₂、蒸发器防冻结、部件热保护、功率降额）、远程与预约请求、诊断跛行请求；每类固定三列——可抢占性、抢占后是否需回执、同类内部冲突的处置。全库 `请求源`/`用户请求` 各 0 命中，这张表是本课第一件交付物而不是讲义插图
   • 显式用户请求要按夺权对象分列而不是按按键分列：六个人机入口最终只落到四个自由度（风量/温度/出风模式/内外循环），同一自由度被两个入口先后改写时以后到者为准；这条不写死，同平台不同车型的行为必然不一致
   • 权限模型只有三个字段就够，但一个都不能缺：谁能压过谁（优先级）、被压过后要不要给用户回执（可见性）、压制结束后回到哪一态（退出）。缺任一字段的请求源都是悬空定义——最典型是远程预调，能进来但没人定过上车后交给谁（交接判据见第 4 讲）
   • 与 K3-01 第 3 节划界：那里的机—机骨架 P_alloc = argmax(w·urgency) 解的是多子系统争抢同一执行器，本课解的是人—机权限；argmax 式、按权分摊式与 urgency 的折算一律引 K3-01，不重推
   • 与 K3-08 构成对偶：K3-08 做「多路热请求 → 冷却侧执行器需求」的机侧合成，本课做「人/安全/自动/远程 → 座舱设定」的人侧仲裁；两课共用 K3-01 的仲裁语言，但请求源清单与被仲裁对象完全不同
   • 同类内部冲突要落到实例：两名乘员同时改左右温区（属 SYNC 权限，第 3 讲展开）、预约与即时远控叠加及重复点击去重（覆盖还是排队的语义见 D3-04）、诊断例程期间用户请求如何挂起（非用户模式五要素见 K3-01）
   • 请求四元组不另起一套：本课每条请求沿用 K3-01 的〈请求源、目标量与量值、有效性、可让度〉，只把「请求源」这一列从整车四域枚举细化到座舱人机侧，避免两套字段在同一域控里并行
2. 安全强制压过用户显式请求：判据、最小充分介入量与整车安全事件那一档
   • 先写清「何种条件下可违背用户显式的 A-C OFF 或最低风量」：视野类以露点裕度 ΔT_margin 跌破阈值或除霜请求置位为判据（判据本体与玻璃温度估算见 C5-03），换气类以 CO₂/AQS 门限与最小新风量为判据（见 C2-09），防冻结与部件热保护类以各自限值层介入为判据（限值汇总表见 K3-01）——本课不重推任一条判据，只定它们能否越过用户
   • 最小充分介入量是本讲的核心量：只借风量、还是连 A-C 一起夺、要不要动内外循环门——取法是「能把判据量拉回裕度内的最小手柄集」，不是判据一成立就全夺；夺权范围越大，用户感知的「车不听话」越强
   • 持续时长与退出条件必须成对定义，且退出后把被夺自由度交还用户原设定值而不是交给 AUTO 默认值——这一点与故障态跛行的退出语法不同（跛行退出须经中间过渡档、降级等级重新裁决，见 K5-02）
   • 必须可见：强制介入要在用户可见处给出「正在做什么、为什么、大约多久」，静默改写是投诉高发写法。本课只定请求源被压过时的可见性触发点与内容要素——告知/静默的分级规则引 K3-07，非故障降级的提前预告范式引 C3-04，故障态提示分级引 K5-01/K5-03，均不重讲
   • 与 C5-03、C2-09 的分界写在同一页：C5-03 的「裕度不足时依次牺牲能耗、温度舒适、噪声，视野安全永远排第一」与 C2-09 的「视野 > CO₂ > 污染 > 能耗」排的都是自动侧请求的牺牲顺序，两处都没处理「用户显式说不」这一档，也都没处理可见性——本课补的正是这两块
   • 安全强制这一档内部还要再分层：整车安全事件（热失控、烟气、外部火烧、严重工质泄漏）置位压在除霜除雾之上。现有阶梯最高档只到防雾，等于热失控来了也压不过起雾逻辑，这是必须新加的一层而不是加一个第五档
   • 整车安全事件档的三条特殊语义：不可被用户显式请求抢占；不得沿用 AQS「污染解除即自动切回」那套自动复位；退出须由整车安全侧显式解除并带自锁，同时对乘员可见。三条缺一条，这一档就退化成普通高优先级请求
   • 座舱侧具体动作（强制内循环、关严外循环风门、鼓风机停转或降速）与 C2-09 新增的「安全事件强制置位」最高层对齐——动作细节引 C2-09 不重讲；触发源与烟气再侵入物理引 D5-02；整车安全响应链里的执行器归属与去激励默认位（循环风门与鼓风机在常规散热安全侧与烟气事件安全侧要求方向相反，须显式仲裁）引 I7-02
   • 事故态的门位要求是「压紧到密封」而非「关到位」，验收口径用漏风量（归 C2-09/C2-10）；本课只登记「该状态须对乘员可见」这一条，不接管门位验收
3. AUTO 的自由度分解与退出/恢复：把点题变成可下发规则
   • AUTO 不是一个开关而是四个自由度（风量/温度/出风模式/内外循环）的集合，夺权粒度按自由度定：改风量不应连带交出出风模式与内外循环的自动权——这是把 C6-01「手动/半自动/全自动的分界」那两行点题变成可下发规则，C6-01 已把夺权粒度与回归判据显式前指本课
   • 部分 AUTO 是合法态而不是过渡态，必须显式定义：哪几个自由度仍在自动、AUTO 指示是亮还是半亮、被夺自由度上 TAO 链路（见 C6-01）还算不算；不定义就会出现「看着是 AUTO、其实只有温度在自动」的黑箱，售后无法判读
   • 回归 AUTO 只有三条路径且必须都写：按键（用户显式）、下电再上电（结果由第 4 讲的记忆分类表决定）、超时自动收回（须给时长与「允许超时收回」的自由度白名单——风量可收、用户刚设的目标温度通常不可收）
   • SYNC / 驾驶员优先权要方法化而非口头约定：SYNC 置位时副驾设定是跟随主驾还是被冻结、解除 SYNC 后副驾回到哪个值、风量作为共用变量被两侧同时改写时以谁为准。C6-01 已把「把双区当两套独立空调」列为误区并指出风量共用、必须先定优先权，取值方法归本课（左右温区能力边界见 C2-08）
   • 切换去抖一律引用不重讲：迟滞带三项下界与最小驻留 t_dwell_min 引 K3-01 第 4 节，内外循环切换阈值/迟滞带/切换速率引 C2-09 讲义；本课只说明同一套手法作用在「请求源切换」上——被抖动的对象是生效请求源标识而非温度阈值，因此迟滞与最小驻留只加在生效请求源上，不给每个请求源各配一套（各路自带迟滞导致赢者交替甩动的冷却侧实例见 K3-08）
   • 退出 AUTO 的瞬态不许阶跃：被夺自由度的目标值走斜坡（x_target 斜坡式见 K3-01），并且 warm-up 抑制的继承状态要跟着走——预热已把热源拉起来时不应重新压风量，该继承判据见 C6-01 与 D3-04
4. 记忆与上电恢复：设定项的记忆 vs 强制安全复位分类表
   • 交付一张分类表：热管理相关设定项（A-C 开关、内外循环、目标温度、风量、出风模式、预约/远程预调）逐行填「记忆 / 强制安全复位 / 记忆但带上限」，每行必须写出理由；没有理由的行一律划掉重填——这是本课第二件交付物
   • 三类态明确不得记忆，理由要能说出来：除霜强制态（下次上电应回常态，否则用户在无雾工况被强制全力除霜）、整车安全事件置位态（记忆等于把一次事故态带进下一个行程，且解除权在整车安全侧不在 NVM）、跛行态（致因可能已消失，降级等级须由 K5-02 重新裁决而不是回放）
   • 记忆值的存取只做确定性回放，三件事要定：写 NVM 的时机（下电前一次写 vs 变更即写）、校验失败或掉电丢失时回哪个具名缺省值、跨软件版本的布局兼容性。校验与缺省回落的实现手法引 K1-02（与执行器学习值同一套机制），NVM 数据布局兼容性声明引 K4-04，本课不重讲
   • 上电恢复的次序有硬前提：设定项回放必须晚于执行器找零与传感器有效性建立，否则目标值被下发给还没找零的风门执行器。Init 端点态、域级调度次序与超时预算见 K3-11 与 K3-01，本课只占「设定项回放插在哪一步」这一格
   • 远程预调/预约与上车后显式请求的交接判据是本讲的接口条款：D3-04 只讲到能量账与 t_start = t_target − Δt_heat − t_margin，止于上车前；本课定「上车瞬间以谁为准」——用户一旦对某自由度有显式动作即整体接管该自由度，无动作则预调设定继续生效至达标或超时，且抑制状态按第 3 讲继承、不重新压风量
   • 与 K7-01/K7-03 划清：本课只做确定性存取回放，不碰预测输入（导航/云端/驾驶意图属 K7-01）与在线学习（个性化偏好学习及其护栏 u_final = clip、退回条件、能耗劣化阈值属 K7-03）。把「记忆」实现成「学习」会立刻落进 K7-03 的验收要求，那是另一门课的证据链
   • 为什么这一层此前无人持有：全库 `复位` 3 门全指执行器找零、`上电` 18 门全指执行器自学习或高压上电流程，无一条讲的是用户设定项——分类表不写在本课，量产上就由实现者各自发挥
5. 可观测性、标定与投诉归因
   • 当前生效请求源必须在测量口暴露：active request source ID + 生效时长计数 + 被压过的请求清单。不暴露这三样，「空调自己开 A-C」「风量自己往上跳」这类投诉无法归因——这与 K3-01/K3-08 的 active limiter ID 是同一手法在人机侧的实例化
   • 归因链要能闭合到三类根因：上游策略让路（低 SOC 收紧、快充把冷量优先给电池、化霜期制热让位，表现与机理见 C6-01）、安全强制介入（第 2 讲）、用户自己改过设定后停在部分 AUTO 态（第 3 讲）。三类现象接近而处置完全不同，缺可观测量就只能猜
   • 场景用例矩阵按「请求源 × 请求源」配对生成而不是按功能列：每一对至少一条用例，写清谁赢、要不要回执、退出后回到哪个值；矩阵里的空格就是一处待定义的权限。完备性核对手法引 K4-05，模式表与仲裁规则的静态体检（可达性、死锁、切换质量）引 K3-13
   • 标定量清单：各安全强制档的进入/退出门限与去抖时间、最小充分介入量的手柄集配置、超时收回 AUTO 的时长与白名单、可记忆项开关、告知触发阈值。落地方式与 DoE 引 K6-01，热泵与多模式切换相关取值引 K6-07——本课只交出清单与每项的判据来源，不给数值
   • 验收要给可测量而不是主观描述，四个量：强制介入的响应时延、回执出现率（每次抢占是否都伴随一次回执）、误抢占次数（判据未成立却发生抢占）、退出后设定值还原正确率。用户口中的「车不听话」必须能落到这四个量之一，否则无法闭环
   • 本课两张交付表（请求源优先级—抢占矩阵、记忆/复位分类表）是 K6-01 标定量清单与 K4-05 完备性核对的共同输入，也是售后归因的判读依据；它们的最终数值不在本课产出

• 以为安全强制只要「功能上正确」就够了，其实用户刚关掉的 A-C 被悄悄打开、风量自己往上跳，功能没错、体感是「车不听话」——强制介入必须给最小充分介入量并在用户可见处可解释（C5-03 已把无提示的全覆盖列为投诉高发写法）
• 以为现有「视野 > CO₂ > 污染 > 能耗」阶梯已经覆盖了安全强制，其实那条阶梯排的只是自动侧请求的牺牲顺序、最高档只到防雾——热失控/烟气来了也压不过起雾逻辑，必须另加「整车安全事件」一层压在其上
• 以为安全事件强制置位可以照搬 AQS 的自动复位，其实「污染解除即自动切回」用在热失控/烟气上等于让座舱自行退出安全态；该档必须自锁、由整车安全侧显式解除并对乘员可见
• 以为 AUTO 是一个开关，其实它是四个自由度的集合——改一下风量就整体退出 AUTO，会连带交出出风模式与内外循环的自动权，投诉表现为「碰一下风量整个空调就变笨了」
• 以为部分 AUTO 是个过渡态不用定义，其实它是量产上最常驻的一态；不定义哪几个自由度仍在自动、指示怎么显示，就会出现「看着是 AUTO、其实只有温度在自动」的黑箱，售后无从判读
• 以为记忆做得越全越贴心，其实除霜强制态、整车安全事件置位态与跛行态一旦被记忆，就把上一个行程的异常态带进下一个行程，而这几类态的解除权本不在 NVM 手里
• 以为「设定记忆」和「偏好学习」是一件事，其实前者是确定性存取回放、可用用例穷举验收，后者一落地就要满足 K7-03 的幅值/变化率护栏、独立监督通道、学习使能与退出条件清单——按记忆的口径做验收会漏掉学习件该交的全部证据
• 以为给每个请求源各加一套迟滞就不会抖，其实抖动出现在赢者交替的窗口里，单看每一路都「没抖」；迟滞与最小驻留只能加在生效请求源标识与合成输出上（冷却侧同类实例见 K3-08）
• 以为不给可观测量也能靠复现定位投诉，其实「空调突然不给力」至少有上游让路、安全强制介入、用户自己改过设定三类根因，现象几乎相同；不暴露当前生效请求源，标定与售后只能猜
• 以为上电时先回放用户设定最快最好，其实设定项回放必须晚于执行器找零与传感器有效性建立，否则目标值被下发给还没找零的风门执行器，表现为上电头几秒的风门乱动
• 以为远程预调把车预热好就算交付完成，其实上车瞬间「以谁为准」没写死时，用户的第一次显式动作会与预调设定互相拉扯（预调侧的能量账止于上车前，见 D3-04）

需求区 · 想听众筹

想听/点名均为需求登记，不涉及任何付款（意向金仅登记不收款）。满 5 人点名 → 自动向平台专家发邀约。