充电与充满静置工况的电池热安全应急响应与桩车联动

课程大纲

• 能逐条说清充电与充满静置工况相对行驶、碰撞两个场景的三条边界差异（外部电源持续注入能量、车辆无人值守、外部电源反而可用于驱动热管理），并据此判断哪些行驶/碰撞场景下成立的动作在本场景失效或反向
• 能把 K5-04 的「等级 → 判据 → 整车动作 → 可接受误报频次」共维表填出充电列，并按插枪未充/充电中/充满仍插枪/拔枪后静置四段时间轴分别给出动作集
• 能定出「先加大冷却」与「先请求停充」的次序判据，说清请求桩停止输出与断主接触器的先后、不可颠倒的理由，以及桩不响应/握手超时时的车端兜底分支与其时限来源
• 能区分「温度降额中止」与「安全事件中止」两类请求的语义差别与优先级，并把桩车、站车两侧的接口需求写成「请求—确认—超时」三段（不写报文编号、不自拟时限）
• 能定出充满/停充后静置安全监控窗口的取值方向、起点定义与出处口径，并说明为什么不能沿用热扩散场景的报警后固定分钟数
• 能列出无人值守下的三类告警对象及各自失效模式，并说清告警链路自身的存活证明为什么必须与事件告警同等对待

1. 充电与充满静置工况的热安全边界重写
   • 三条边界差异要逐条对着写，不能笼统说「场景不同」：① 外部电源在持续注入能量——不请求停充就等于持续向故障点喂能量，这是碰撞场景没有的一项（碰撞后能量输入只减不增）；② 车辆通常无人值守，凡是依赖车内人配合的动作整条失效；③ 外部电源同时是可用资源——高压仍在位时电动压缩机、PTC/HVCH、高压电子水泵可继续工作，冷却能力不受整包剩余能量约束，可用动作反而比碰撞场景更多
   • 与碰撞场景（D5-04）的对照面：D5-04 已给出硬约束「高压一断，电动压缩机、PTC/HVCH、高压电子水泵全部失能，强化监测与主动通风只能靠低压侧支撑」；本场景在断高压之前多出一段「外部电源在位、冷却全能力可用」的窗口，动作链设计的第一件事就是判断这段窗口用来做什么、能持续多久。碰撞侧的方法层、供电冗余核算与碰撞下电时序前指 D5-04，本课不重讲
   • 与行驶场景（K5-04 的实例）的对照面：行驶中「立即断高压」本身会引入新的行车风险，动作要往可逆一侧让；本场景车辆静止、无行车风险，断高压的代价只剩「失去高压驱动的冷却能力」这一项——取舍天平的位置不同，所以同一张阶梯在两个场景下的动作列必然不同。分级阶梯与共维表的结构本身归 K5-04 第 3 讲，本课只做充电工况的重写
   • 口径纪律一条：「充电中与充满后静置」讲成热事件的**高发窗口之一**，不写成统计最值——公开监测平台口径逐年变动、行驶工况占比同样可观。这一条的正确用法是「值得单独立一套动作链」，不是「这是最危险的场景」
   • 场景边界要在时间轴上切成四段而不是一段：插枪未充、充电中、充满/停充后仍插枪、拔枪后静置。四段的能量输入、可用冷却能力、可用告警通道各不相同，动作链必须分段定义；其中拔枪后的残热导出与 run-on 编排本体见 K3-11 第 4 讲，本课只受理它作为本场景最后一段的边界条件
   • 触发源承接 K5-04 的输出而不重建：本课从「预警等级已经出来」这一点开始，特征信号选型、多信号融合、误报漏报权衡、提前量标定全部前指 K5-04；由部件与信号失效（泵/传感器/Chiller 不可用）触发的降级不属本课，见 K5-02——安全事件下「切断能量输入 + 保住监测供电」优先于恢复温控性能，两者优先序相反
   • 本课不碰结构侧：热扩散抑制、隔热、泄压与定向排烟的设计归 D5-01 / D5-02，本课只处理「事件已判定之后，热管理与充电接口这一侧做什么、按什么顺序」
2. 充电工况的动作链与优先序：共维表的充电列
   • 「先加大冷却还是先请求停充」不能靠直觉定，判据是热输入速率与冷却能力**可增量**的相对量级：若外部注入的充电功率折成热流后已超过当前冷却能力还能增加的那一部分，先加大冷却只是把响应时间花掉；工程上的稳妥写法是两者并行下发，且停充请求不等待冷却生效的确认
   • 请求桩停止输出与断主接触器是**先后关系而非互斥关系**，且顺序不可颠倒：先请求桩停止输出、待电流落到安全水平再断主接触器，可避免带载分断损伤触点；但「先请求后分断」只在桩会响应的前提下成立，必须配一条超时兜底——超时后按最坏情况带载分断，用接触器的分断能力换时间
   • 桩不响应/握手超时的车端兜底是本讲最硬的一条，必须写成显式分支而不是丢给异常处理：兜底动作、允许等待的最长时限、分断后进入的降级状态三者一起定义。具体的中止报文类型、中止原因位与桩侧响应时限按 GB/T 27930 现行版本原文确认（本课不给编号、不自拟时限），报文通道与功率协商链路见 D4-03 第 5 讲、车端充电座 NTC 触发的握手中止见 E3-02
   • 断高压后驱动泵与风扇的供电来源必须在设计期答清而不是留到标定：要么在断高压前把该导出的热先导出，要么把冷却降到 12V 侧能支撑的档位；12V 侧能同时开几件、多请求并发时按什么顺序放弃，见 K3-11 第 4 讲与 K2-06，本课只提供「安全 > 部件不可逆损伤 > 寿命 > 舒适」这一优先序在本场景下的具体输入
   • 安全动作不遵守 derating 的三条约定，要在表里写死：不带迟滞带（不允许温度回落就自动恢复）、不做功率协商往返（不与桩讨价还价）、不以 10→80% 时间为目标函数——D4-03 已把「拿安全事件当 derating 曲线的最后一个拐点」列为误区并把动作链交给本课
   • 「不可自动恢复」是安全事件中止区别于温度降额中止的核心语义：解除必须由整车安全侧显式给出。这与 C2-09 对座舱侧强制置位所立的「自锁、不自动退出、须显式解除」是同一条规则的两个落点——座舱侧的执行落点（强制内循环、关严外循环门、鼓风机停转或降速）在 C2-09，本课不重讲风门与鼓风机动作
   • 本讲的产出物是 K5-04 共维表的**充电列**，不是一张新表：列头沿用「等级 → 判据 → 整车动作 → 可接受误报频次」，四列里只有「整车动作」与「可接受误报频次」需按本场景重填。各级阈值的取值方法学（分布分离度、误差预算、漏报与误报代价不对称）见 K5-07，分级结构见 K5-04，本课都不重复
   • 误报代价在本场景与行驶场景不同向：无人值守下误报不会打扰驾驶员，但会造成一次无人在场的充电中断与救援/运维出车——代价从「体验降级」变成「运营成本 + 车辆滞留」，所以「可接受误报频次」这一列必须按本场景重估，不能沿用行驶列的数
3. 桩车与站车联动的安全语义接口
   • 车端发出的中止请求有两种语义，接口设计必须让桩侧能区分：温度降额中止（可恢复、走功率协商往返、由 derating 曲线驱动，归 D4-03）与安全事件中止（不可自动恢复、优先级高于一切冷量仲裁、不接受协商）。两者可以共用同一条通道，但**不能共用同一个标志位**——共用即等于把安全事件当成 derating 曲线的最后一个拐点
   • 接口需求要按「请求—确认—超时」三段写，而不只写请求：桩侧在多长时间内必须给出确认、确认收不到时车端算不算数、桩侧已停输出但车端未收到确认时以哪一侧状态为准——这三问的标准落点按 GB/T 27930 现行版本原文确认，本课只负责把它们列成必须回答的接口需求项，并要求每一项在桩兼容性测试矩阵里有对应用例
   • 站端通知与人工介入是两件事，时序也不同：通知可自动触发，要求是「发出即算数、不依赖有人接」；人工介入依赖站内是否值守，量级从分钟到小时不等。本课不自拟任何时序数字——顺序本体归站端运维规程，本课只交付「车/包端如何请求、请求语义与优先级、请求不被响应时车端怎么办」
   • 多枪站的邻位车处置是站端的责任而不是车端的：车端连站内拓扑都不知道，能交付的只是「事件等级 + 枪位/桩位标识 + 时间戳」。由此反推出的车端接口需求是「事件上报必须带枪位/桩位标识」，否则站端连要圈多大范围都算不出来
   • 换电站与储能舱内包在库充电时的热事件属站车两侧共同处置，分工必须写死：**站内多包隔离、机械手取出、消防介入的先后顺序本体归 D6-01 / D6-02**（站端设备与运维视角），本课只给包端/车端的请求语义、优先级与请求不被响应时的兜底。这一刀是为解掉 D6-02 §5 与 P2-03 / D6-01 之间对「顺序由谁给」的三方指引环，须在本课与 D6-02 两侧同时写死
   • 换电场景的接口需求若在 GB/T 40032 现行版本原文中找不到对应条款，就如实降级为「运营规程输入」并在设计文件里写明出处，**不得自拟人工介入时序**——这是本课残余不确定度最高的一处，评审清单里应单独标注为「出处待确认」而不是当成已闭环
   • 桩自身的散热与降额（桩内功率模块、液冷线缆温度、多枪分流、桩端降额门限）不属本课，见 N1-03；本课只把「桩可能因自身原因先降额或先停输出」这一事实当作兜底分支的输入之一——它意味着「电流已降」不等于「车端请求被接受」，两者必须分别判
4. 充满/停充后的静置安全监控窗口：时长出处、起点定义与唤醒预算
   • 监控窗口时长是**设计输入而不是可算量**，这条口径直接沿用 D5-04 第 3 讲：取值与出处（哪一版规范第几条、或引用哪本标准的哪项观察期、或企业规范编号）必须写进设计输入文档；写「法规要求 XX 分钟」却指不出条款，评审时按不合格处理
   • 不可移植的那一条要单独提醒：GB 38031 的「热事件报警后 N 分钟」属**热扩散场景**口径，D5-04 已明确警告不可移植到持续监测场景；本场景的窗口须另找出处，量级可参照碰撞后观察期与热扩散后观察期（小时量级），但必须说明为什么充满静置场景取这一档而不是那一档
   • 窗口起点定在「停充/充满时刻」还是「最后一次热异常判据复归时刻」，两种定法给出的总时长差别很大：前者实现简单但对慢性劣化不敏感，后者更安全但要求判据在整个窗口内一直有效、一直有供电。选哪一种是显式的设计决策，评审时必须能说出理由而不是默认取前者
   • 周期唤醒的机制、唤醒源与保活、唤醒次数配额、保活负载走哪条电，全部归 K3-11 第 4/5 讲；本课只定**安全侧的取值方向**：唤醒周期要短到能在热失控发展的时间尺度内抓到变化，同时单次唤醒的有效测量时间要够（t_eff = t_awake − (t_boot + t_bus + t_valid) 及其判据在 K3-11），两条同时满足才构成可行的取值区间
   • 安全侧的取值方向与省电侧**相反**，这一点要在评审里显式对账：K3-11 的配额母式 Q_park ≤ ΔDoD_allow·C_12V,EOL 会把唤醒次数往下压，本场景则要求把它抬上来。解法不是两边各让一步，而是把安全监控窗口从「常规静置」里拆出来单独记一档预算，否则它会在配额分配里被日常保活挤没
5. 无人值守下的告警对象、通道分工与告警链路存活证明
   • 无人值守下的告警对象至少列三类并各写失效模式：站端（最近，但依赖站内有人或有联动能力）、云端/远程平台（覆盖最广，依赖通信可用且 12V 供电还在）、用户手机（依赖用户在线且愿意响应，不能作为唯一通道）。K5-04 第 4 讲图 5 预设的「提示用户靠边停车 / 疏散乘员」在本场景整条失效，不能拿来兜底
   • 法定监管遥测与工程/告警通道是两条通道，不能合并：GB/T 32960 体系约束的是远程服务与管理平台的上传数据项与上传周期（正常/故障两档，具体项与数值按现行版本确认），通道划分、带宽与存储口径归 K7-04（其边界已明写不讲报文层），诊断冻结帧与三条通道的分工判据归 K5-01。本课只取「哪一级事件该告给谁」这一层的场景语义
   • 告警链路自身要有存活证明：无人值守场景下「静默地不报」是最危险的失效（K5-04 第 4 讲已把这类失效列为三类中最危险的一类），因为系统看上去一切正常、防线实际已不存在。窗口期内的心跳/自诊断上报必须与事件告警走同一套可用性判据，否则「一直没告警」与「告警链路早就死了」在外部无法区分

• 以为把 K5-04 的三级预警阶梯照搬到充电场景就够了；其实那张表的动作列是按行驶场景填的——「提示用户靠边停车 / 疏散乘员」在无人值守充电场景整条失效，动作列与误报频次列必须按本场景重填（分级结构本身不用改，见 K5-04）
• 以为安全事件中止就是 derating 曲线的最后一个拐点；其实两者语义不同：安全中止不带迟滞、不做功率协商往返、不可自动恢复，共用一张曲线会让安全动作被迟滞带拖住，甚至因温度回落而被自动解除（D4-03 已把这条列为误区并把动作链交给本课）
• 以为断主接触器就万事大吉；其实高压一断，电动压缩机、PTC/HVCH、高压电子水泵全部失能（D5-04 第 2 讲已给出这条约束），而本场景恰恰是「外部电源在位、冷却能力最强」的时刻——断早了等于主动放弃最强的散热手段，该导出的热还没导出
• 以为「请求桩停止输出」是个必然成功的动作；其实它是一条会失败的外部依赖：桩可能不响应、可能因自身原因先降额、也可能确认在链路上丢失。没有超时兜底分支的动作链在桩兼容性测试里必然翻车，且「电流已降」不等于「请求被接受」，两者必须分别判
• 以为充满/停充后热事件风险随充电结束而结束；其实静置期仍需一段安全监控窗口，且窗口时长是设计输入而非可算量——写「法规要求 XX 分钟」却指不出条款，是这一条最常见的翻车形式（口径沿用 D5-04 第 3 讲）
• 以为把 GB 38031 的「热事件报警后 N 分钟」搬来当静置监控窗口就行；其实那个口径属热扩散场景，D5-04 已明确警告不可移植到持续监测场景，本场景的窗口必须另找出处并说明为什么取那一档
• 以为把安全监控窗口的唤醒需求塞进日常静置的唤醒配额里就行；其实两者取值方向相反——K3-11 的配额母式会把唤醒次数压下去，安全侧要求抬上来，共用一个配额的结果是安全窗口在分配中被日常保活挤没，正确做法是单独记一档预算
• 以为告警上了云就算有告警；其实云端通道依赖通信可用与 12V 供电还在，任一条断了就是静默失效——告警对象要列站端/云端/用户手机三类并各写失效模式，且窗口期内要有心跳证明链路还活着，否则「一直没告警」与「链路早就死了」在外部无法区分
• 以为多枪站的邻位车处置该由车端来做；其实车端连站内拓扑都不知道，能交付的只是「事件等级 + 枪位/桩位标识 + 时间戳」，是否停、按什么半径停归站端。同理，站内多包隔离与消防介入的顺序本体归 D6-01 / D6-02，本课不给顺序本体

需求区 · 想听众筹

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