K3-11 · 控制、软件与标定 / 控制策略与算法
待认领listed
→
众筹中recruiting
→
已开课open · Course 售卖
一课题可并存多讲师版本
课程大纲
学完能做什么
- 能画出热管理域电源模式状态机(含 Init/Shutdown/Sleep 三个端点态),并为每条迁移写出触发事件、守卫条件与超时后的去向
- 能列出本域唤醒源清单并给出优先级、单次保活时长上限与撤回条件,并判断某个唤醒事件该走全域唤醒还是部分网络
- 能排出一次上电的域级自检与执行器初始化次序表,给每段配超时预算与超时后动作,并算出 t_ready
- 能把跨域上电四段链(12V 上电 → 高压上电许可 → TMS 就绪置位 → BMS 允许充电/允许大功率放电)的先后约束、各段超时与超时降级档位写成一张表
- 能列出 run-on 请求源清单,为每源给出「温度判据 + 定时兜底」双保险的取值依据,并排出全域停止次序表与跨部件冲突的消解规则
- 能对下电时「阀路隔断 vs 保持导通」给出时序化判据,说清先导通续跑、退出后再隔断的分段条件与保温期泵间歇 duty 的定法
- 能在给定 12V 可用功率下为多个 run-on 请求分配预算并定放弃顺序,说清谁发网络请求抑制总线休眠、何时撤回、撤回后多久必须放行休眠
- 能用分档安时账(保活档位 × 停放时长)算出静置能耗并与 12V 允许亏电量比对,据此反推唤醒次数配额、哨兵允许时长与 run-on 总时长上限
- 能判断一次周期唤醒「值不值」——把寿命收益与唤醒能耗折成同一量纲,并核算唤醒与上电耗时是否已吃光有效监测窗口
内容大纲
- 热管理域电源模式状态机:Init/Shutdown/Sleep 三个端点态与唤醒源清单
- 热功能模式机只是中段:K3-01 覆盖的是「稳态有哪些模式、冲突怎么仲裁」,两端的 Init(上电初始化/自检)、Shutdown(下电收尾)、Sleep 在那门课里只占模式全集里一格并明确前指本课;本讲把三个端点态与迁移条件补全,落成一张状态×事件迁移表,每格必须有确定去向(含「保持不动」要显式写)。
- 每条迁移必须同时写清三件事:触发事件(KL15 电平跳变/远程指令/总线唤醒帧/本地定时器/插枪)、守卫条件(12V 电压与 SoC 双门槛、无高压故障、车速为零)、以及迁移超时后的去向。只写状态不写超时,车就会卡在过渡态而无人捞。
- 唤醒源清单按「谁能把域控叫醒」逐条列表并排优先级:本地定时器、总线唤醒帧、KL15/端子电平、LIN 从节点唤醒脉冲、外部远程指令(TSP 下发);每条标明是否需要唤醒校验(wakeup validation)以及误唤醒的能耗代价。机制侧(EcuM 唤醒源校验、NM 报文、LIN go-to-sleep 的发法)见 K4-01 与 K2-02,本讲只定「该有哪些源、各源判据与优先级」。
- 部分网络(partial networking)的取舍要落成一张表:某唤醒事件下让哪些节点醒、哪些保持休眠。判据是「该事件必须操作的执行器集合」,不是「顺手都醒着方便」——全域唤醒省配置但静态电流按整车算,部分网络省电但要求执行器节点支持、报文与配置更复杂。这张表是讲 5 分档安时账里最能省电的一项变量。
- 保活时长预算:每个唤醒源给一条最长保活时长上限与撤回条件(谁发的请求谁撤回),并写明超时与故障时的强制下电条件。强制下电与降级不同轴——降级等级体系(正常/性能降额/跛行/安全停机)归 K5-02,强制下电是电源模式机上的一条无条件迁移,可以在完全无故障的情况下仅因保活超时触发。
- 电源模式跳变可无条件抢断任何热功能模式(这条优先关系 K3-01 已声明);本讲要补的是抢断瞬间的执行器交接规则——正在走行程的阀、正在爬升的压缩机各停在哪、由谁负责驱到落点。落点本身由三档 fail-safe(带电失联/断电/上电恢复)与选型决定,见 G12-03 §5.4,本讲只定「抢断时该不该先驱位再断电」。
- 上电编排:域级自检次序、执行器初始化与跨域上电握手
- 上电自检的域级调度次序表把一次上电内要做的动作分四类:传感器有效性建立(含 NTC 自热消退与合理性互校)、执行器找零/止点自学习、总线关键报文新鲜度达标、非易失学习值读取与合法性校验。本讲交付的判定表要回答「哪些必须在本次上电内完成、哪些可延后到条件满足时再做」。
- 找零动作本身不在本课:EXV 归零与运行期重同步见 G4-01,驱动层步数下发与保持扭矩见 K1-02,三档 fail-safe 语义与断电落点选型见 G12-03,风门止点自学习与失电位见 C2-03。本讲只排域级次序与逐段超时预算。
- 多执行器同时顶止点找零会打穿 12V 峰值预算(这条约束 K1-02 已按驱动层视角给出,并要求排队错时);本讲把它反过来用——先由 K2-06 的同时率与峰值电流包络定出「同一时刻允许几个执行器动作」,再据此把本可并行的自检段串行化,并把串行化带来的 t_ready 增量算进超时预算。
- 每段配超时预算,超时后的动作只有三选一:重试(限次 + 退避,语义引 K5-02 的「重试—放弃—降级」模式)、放行并标降级(该执行器本次上电按位置未知处理、只许下发保守缺省动作)、阻止进入首个可运行模式。不给超时预算的自检等于永久等待。
- 跨域上电握手的四段链要讲清先后约束与各段超时:12V 上电 → 高压上电许可 → TMS 就绪置位 → BMS 允许充电/允许大功率放电。本课只讲热管理域给出上电许可的前置条件侧——哪几项自检必须过、水路必须每条回路闭合且有泵有定压点、加热器使能前必须先建流;高压上电四步链(预充→绝缘监测→HVIL 确认→使能)只引 G12-03 §4.3 不重讲,主从不颠倒。
- 某一段超时未就绪时由谁降级、降到哪一档要写成表,例如 TMS 就绪迟到 → 只允许小功率充电、或禁止大功率放电。职责切分本身(哪个量谁算、谁复核、失效时谁兜底)引 K3-01 的 BMS–TMS 功能分配矩阵,插枪/充电中/充电结束的桩侧三方协商引 D4-03 第五节,两者均不在本课重讲。
- 非正常掉电后的状态恢复:上电时先判「上次是不是正常下电」(正常下电应留有收尾完成标志),据此决定阀位/步数是沿用存值还是强制重寻零。存值只能把归零从「每次上电必做」降级为条件触发并提供合法性校验基准,不能免除归零(G4-01 已把「上电不做归零」列为误区);载体选型、掉电写一致性与上电有效性校验归 K4-06,初始态判定与异常复位恢复路径的完备性核对归 K4-05 第 4 讲。本讲只定恢复动作在上电次序里的位置与它吃掉多少 t_ready。
- 下电与 run-on 编排:触发/退出判据、全域停止次序、阀路取舍
- run-on 请求源清单先列全再谈编排:带热型(电驱/电控停机后的热回渗、快充结束后的电池余温、水暖 HVCH 芯体残热、chiller 侧局部沸腾风险)与非带热型(蒸发器吹干断湿,见 C2-12)目的不同——一个是导出余热、一个是断湿防霉——但抢的是同一个 run-on 窗口与同一本 12V 预算。
- 每个请求源给「温度判据 + 定时兜底」双保险:温度判据管正常退出,定时兜底管传感器失效或残热量估计偏差。单靠定时会过短(残热没带走)或过长(白耗电),单靠温度在传感器失效时永不退出。冷却侧执行器(泵/风扇/AGS)自身的续转转速与时长取值归 K3-08 第四块,发动机侧泵 after-run(热浸防沸腾)只引 F1-03 作跨架构对照,不重述。
- 全域停止次序表是本课主交付物之一。加热器—泵这一对的「开机先建流再通电、关机先断电再延时停泵」已由 G9-03 §3.5 持有(延时量级几秒到几十秒、须实测标定),本讲要做的是把它与压缩机停机、阀路切换、风扇停转、鼓风机停转排进同一张表,并解决相互冲突。
- 冲突的典型形态:阀要切到隔断位、泵却还要续跑带残热——先切阀会把续跑流量堵在错误支路。次序判据是「先保住残热导出路径的连通,再动隔断」。水侧切换的三段式时序与允许断流/憋压窗口上限见 K3-09,本讲只定跨部件的先后与放弃顺序。
- 下电时阀路隔断 vs 保持导通是一道能量—安全取舍:隔断才保得住温(D3-03 的案例里停机后冷板管路未隔断是主要漏热源,隔断后 τ 明显拉长),保持导通才导得出残热、也才防得住局部沸腾。判据要时序化——按残热量是否已降到不会局部沸腾分段:先导通续跑、退出后再隔断;保温期泵间歇 duty 的定法也在这一段(D3-03 明确把这三问交到本课,它只交付 UA/τ/热桥的物理侧、不讲控制)。
- 断电落点决定次序有没有意义:无弹簧的步进阀断电就地保位、AGS 断电必须 fail-open(卡在关闭位会挡死前端进风)、风门看自锁蜗轮蜗杆还是弹簧复位。三档 fail-safe 语义见 G12-03,本讲只回答「按这个落点,下电次序里该不该先把它驱到目标位再断电」。
- 用户可见性是下电编排的硬约束不是锦上添花:熄屏前若不告知「正在干燥蒸发器/正在导出余热,约 X 分钟后自动停」,用户会判定「车没关干净」(C2-12 已把这条列为体验坑并指出根因是 run-on 与下电时序未可视化)。本讲把「告知」列为 run-on 编排的输出项之一,与时长、放弃顺序并列。
- run-on 窗口的资源账:12V 功率预算分配、放弃顺序与抑制总线休眠的代价
- 窗口内的供电来源必须先答清:整车已下电,泵/风扇/鼓风机是靠 12V 蓄电池还是仍由 DCDC 从高压补电——两条路的能量上限差一个量级,也决定「拔枪后整车已下电时靠谁供电」这一问的答案(D4-03 把这问明确交到本课)。答不清这一句,后面的预算分配全是空算。
- 多部件同时请求 run-on 时按预算分配并给放弃顺序:先按 12V 可用功率算出能同时开几件(运行期负载侧的同时率、峰值电流包络与 DCDC 容量校核见 K2-06),再按「安全 > 部件不可逆损伤 > 寿命 > 舒适与体验」定放弃顺序,总时长上限与能否并行一并写死(C2-12 把这三问明确交到本课)。
- 抑制总线休眠的落点是 NM 网络请求(Network Request):执行器还要动作就持续发、动作收尾后释放,否则总线先睡、执行器停在半路(F1-03 已把「只定了时长、没定谁保持唤醒」列为误区,后果是泵在标定时长走完前就断电、防沸腾等于没做)。机制配置见 K4-01,LIN 侧的 go-to-sleep 与唤醒脉冲见 K2-02;本讲只定「谁发、发到什么条件撤回、撤回后多久必须放行休眠」。
- 抑制休眠是要付账的:run-on 期间总线不休眠,静态电流须按「醒着的节点集合」算而不是按休眠值算,这笔账要并进讲 5 的分档安时账。压这笔账的手段是讲 1 的部分网络(只醒必需节点),代价是报文与配置复杂度上升——这是一道明确的取舍题,不是免费优化。
- 快充结束/拔枪后的电池残热导出是快充链条的断点:D4-03 五节止于充电结束,停充瞬间产热归零但包内仍有余温与温度梯度,泵/Chiller 该续跑多久、按什么判据退出、靠谁供电,本讲把这一段接上,并区分两种起始条件——「拔枪但未下电」(仍可用高压与 DCDC)与「拔枪且已下电」(只剩 12V 或需重新请求上电),两者的次序与时长上限不同。
- run-on 也吃执行器动作次数配额:驻车、充电、休眠与续跑期间的动作不产生里程却实打实消耗 N_life,只按里程折算会系统性漏计(K3-01 已在动作次数配额公式的失效边界里点明这条,并要求另立按时长计的配额)。本讲把 run-on 与周期唤醒的动作数按「次/小时 × 该态年均时长」折进配额并与行驶段合并对账。
- 休眠判据、静置能耗预算与算力保活分档
- 休眠判据要写成一组必须全部满足的与条件:所有 run-on 请求已撤回、所有执行器已到落点、待写非易失数据已写完(关机写入序列由 EcuM 在 SHUTDOWN 阶段编排,机制见 K4-01、数据侧见 K4-06)、无阻止休眠的诊断会话(服务与会话本体见 K5-01)、无待处理唤醒请求。缺任一条就不该报休眠就绪——报早了就是执行器停在半路,报不出来就是不睡觉的暗电流。
- 静置电流账必须分档求和,不能全程取单一静置电流:纯休眠档、驻车哨兵档、OTA 升级档、预约充电档各一档,按「保活档位 × 停放时长」分档算。这是此前各课都未列的一类负载——智能电子(AD 域控与中央计算 SoC)在整车下电后算力仍在跑,把暗电流基线整体抬高,量级上足以让「可停放天数」结论差一个数量级。
- 保活负载走哪条电是关键分支,方案评审必须先问这一句:若由 12V 直供,它直接吃亏电门槛;若由 DCDC 从高压补电,12V 账好看但高压 SoC 在掉,且 DCDC 的效率损失与自身待机功耗也要计入。两条路对「能停几天」的结论不同,也决定这笔账记在哪本预算里。
- 保活负载的部件侧热画像见 E5-01(驻车哨兵/OTA 升级/预约充电的时变特征,以及非行驶态冷源可用性的最坏组合),共用回路入口水温目标的可用时段见 E4-02(智能电子是回路里唯一在非行驶态仍持续产热并索取低温冷源的成员)。本讲只讲它折进电源模式与安时账的那一侧,不重讲部件散热与回路温度协调。
- 12V 防亏电门槛按「保底能力」反推,不是拍一个电压值:门槛要保住起动/唤醒能力与一次完整上电所需能量,且 12V 容量须取寿命末期(EOL)可用值、寒区还要扣低温容量折减。术语防混:本讲的「暗电流」指整车静置低压电流,与 E5-02 里摄像头 CMOS 的 dark current 同名异义,两套判据不可混用。
- 高温停放期的周期唤醒监控要答全四问:唤醒门槛(温度与 SoC 的组合;寿命收益侧的机理见 D1-04,它明确只交付老化—温度—SOC 机理、不给控制动作)、监测量及其有效性建立时间、单次唤醒能耗、多日静置账。判据是「这次唤醒省下的日历老化收益 ≥ 唤醒能耗折成同一量纲的代价」——折不到同一量纲,这个唤醒就是拍脑袋加的。
- 远程预降温/预约预热这类用户触发的唤醒,其上电许可由「电源模式 + 12V/SoC 双门槛 + 唤醒次数配额」三者共同裁决——配额算法在本讲,场景应用与用户可见规则见 C6-05 §4.2/§4.4,预约时刻表反推见 D3-04,充满/停充后静置期安全监控窗口的安全侧取值方向见 D5-06。本讲只给机制与配额,不重写场景。
关键公式
Q_park = Σ_k (I_k · t_k);判据 Q_park ≤ ΔDoD_allow · C_12V,EOL
判「这台车能停多少天还唤得醒、起得来」;反解可得唤醒次数配额、哨兵允许时长与 run-on 总时长上限,是讲 4/讲 5 所有配额的母式
t_eff = t_awake − (t_boot + t_bus + t_valid);判据 t_eff ≥ t_action_min
判周期唤醒「测不测得准」;同时给出单次唤醒能耗 E_wake ≈ P_awake · t_awake 的时长输入,回接式一的分档安时账
t_runon ≳ Σ_i m_i c_p,i (T_i,0 − T_exit) / (ṁ · c_p · ΔT̄)
定 run-on 的定时兜底时长,并给出 run-on 期 12V 能耗 ≈ (P_pump + P_fan) · t_runon 的时长输入,回接式一的安时账与讲 4 的放弃顺序
t_ready = Σ_{j∈关键路径} t_j(可并行段取 max、被峰值电流逼成串行的段取和);判据 t_ready + t_margin ≤ T_ready_req
排上电自检次序表并核对 TMS 就绪能否赶上 BMS 的允许充电/允许大功率放电窗口;不满足时用来定超时降级档位
关键概念
电源模式端点态(Init/Shutdown/Sleep)迁移守卫条件与超时去向唤醒源清单与唤醒校验(wakeup validation)部分网络(partial networking)网络请求(Network Request)抑制总线休眠保活时长预算与撤回条件强制下电域级自检次序表TMS 就绪置位与上电许可t_ready 与逐段超时预算run-on 窗口带热型 run-on 与断湿型续跑温度判据 + 定时兜底双保险放弃顺序全域停止次序表先建流再通电 / 先断电再延时停泵阀路隔断 vs 保持导通保温期泵间歇 duty休眠判据(与条件组)静态电流/暗电流分档保活档位驻车哨兵12V 防亏电门槛与允许亏电量唤醒次数配额周期唤醒监控非正常掉电恢复与正常下电标志
推荐工具与标准
INCA / CANape(电源模式迁移、上电 t_ready 各段与 run-on 时序的标定与录制;时间戳须与总线记录同源时基) CANoe / CANalyzer(NM 休眠唤醒、部分网络配置与唤醒源注入的总线级验证,含误唤醒复现) 可编程直流电源 + 高精度电流分流器与数据记录仪(静置电流分档实测:须同时覆盖 mA 级与 A 级,量程切换不能丢段;并做 12V 跌落与欠压边界的上下电复现) 环境舱 + 多点温度记录(run-on 退出判据与高温停放周期唤醒判据的实测标定;T_exit 与定时兜底值须在同一次试验里对齐) 诊断仪 / UDS 工具(验证诊断会话对休眠的阻止行为,以及正常下电标志与非易失恢复路径;服务本体见 K5-01)
ISO 26262(功能安全体系名):本课仅在强制下电、超时降级与安全状态处引用其口径,版本按现行确认;方法本体见 K2-03,降级等级体系见 K5-02 AUTOSAR Classic Platform 的 EcuM / BswM / NM 规范(体系名,非条款号):本课只用其状态名与请求/表决语义,机制侧见 K4-01 整车静置电流(暗电流)限值与测量方法、12V 蓄电池起动/唤醒能力保底判据:多为主机厂企业标准,相关国标/行标按现行版本确认——本课不给标准号,也不给限值数值
工程案例
某纯电 SUV 上市后集中出现两类客诉,根因同源于「静置账与 run-on 窗口没人统一编排」。现象①:用户反馈「停三天车打不着、App 也唤不醒」。查暗电流:按纯休眠档实测只有数十 mA 量级,看着很干净;但该车默认开启驻车哨兵,哨兵档电流是安培量级,且哨兵触发后 AD 域控保活期间全域总线不休眠、静态电流按醒着的节点集合算。按单一静置电流做的账把停放能力算成十几天,改成分档求和后只剩两三天,与客诉吻合。现象②:少数车快充拔枪后半小时内电池包温度反弹、日历老化加速。查下电时序:拔枪即整车下电,run-on 请求未被受理,包内余温只靠自然散热导出——D4-03 的充电态策略止于充电结束,拔枪后这一段无人承接。整改三条:一、静置账改成「保活档位 × 停放时长」分档求和,并给哨兵加限时与 SoC 双门槛;二、哨兵期间的全域唤醒改为部分网络,只醒必需节点;三、把「拔枪后残热导出」补进 run-on 请求源清单,给温度判据 + 定时兜底双保险,并按「拔枪未下电 / 拔枪已下电」两种起始条件分别定供电来源与停止次序。(文中电流与时长均为演算量级,不代表任何具体车型实测值)
动手做
交付物 · 给定一台纯电 SUV 的执行器清单、12V 蓄电池 EOL 容量与四个保活档位的电流量级(数值按演算假设值给):① 画出热管理域电源模式状态机(含 Init/Shutdown/Sleep 三端点),交付状态×事件迁移表——每格必须有确定去向(含「保持不动」要显式写),每条迁移带守卫条件与超时后的去向;② 排一次上电的自检与初始化次序表,标出哪几段可并行、哪几段被 12V 峰值电流约束逼成串行,算出 t_ready 并与给定的 BMS 就绪窗口 T_ready_req 比对,超了就写出降级档位(降到哪一档、由谁裁决);③ 列 run-on 请求源清单(至少四源,须含一个非带热型),为每源给出温度判据与定时兜底的取值依据,并在给定 12V 可用功率下排出放弃顺序与窗口总时长上限;④ 用分档安时账算出该车可停放天数,与允许亏电量比对,反推每日唤醒次数配额与哨兵允许时长;⑤ 对「拔枪后残热导出」这一源,写出它在「拔枪未下电」与「拔枪已下电」两种起始条件下的供电来源与停止次序差异。交付物:迁移表 + 上电次序表(带超时列与并行/串行标注)+ run-on 请求源与放弃顺序表 + 静置安时账算式与结论页。
常见误区
- 以为 K3-01 已经把模式管理讲完了,其实它只覆盖稳态中段——Init/Shutdown/Sleep 三个端点态在那门课里只占模式全集一格并明确前指本课;「从没有模式到有模式、从有模式到没有模式」这两段才是本课的活。
- 以为静置能耗账取一个整车静置电流乘停放时长就行,其实驻车哨兵/OTA 升级/预约充电期间智能电子算力仍在跑、把暗电流基线整体抬高;不按「保活档位 × 停放时长」分档求和,可停放天数会算高一个量级。
- 以为 run-on 只要定好时长就完事,其实还得定谁在这段时间持续发网络请求抑制总线休眠——总线先睡,泵在标定时长走完前就断电,防沸腾等于没做(F1-03 已把这条列为误区)。
- 以为下电时把阀路隔断保温总是对的,其实隔断的同时也切断了残热导出路径;正确做法是分段——先导通续跑带走残热、退出后再隔断,判据是残热量是否已降到不会局部沸腾。
- 以为把阀位/步数存进非易失存储就免了上电归零,其实存值只能把归零从「每次上电必做」降级为条件触发并提供合法性校验基准;断电期间的丢步与机械变化让存值不可全信(G4-01 已把「上电不做归零」列为误区)。
- 以为多执行器上电自检可以全并行以压短 t_ready,其实同时顶止点找零的峰值电流叠加会打穿 12V 供电预算、上电噪声也集中成一声「咔」;被迫串行化的那部分必须算进超时预算,否则 t_ready 的承诺兑不了。
- 以为「暗电流」在热管理体系里是一个词,其实本课的暗电流指整车静置低压电流,E5-02 里的暗电流是摄像头 CMOS 的 dark current,同名异义;查资料时混用会把两套判据搅在一起。
- 以为强制下电就是降级的最高一级,其实两者不同轴——降级等级体系(正常/性能降额/跛行/安全停机)归 K5-02,强制下电是电源模式机上的一条无条件迁移,可以在完全无故障时仅因保活超时触发。
- 以为周期唤醒设个定时器就能监控高温停放,其实控制器启动、总线建立与传感器有效性建立三段耗时可能把有效窗口吃光甚至吃成负值,测到的是旧液温;不核 t_eff 的周期唤醒是花了电什么也没测到。
- 以为「run-on 期间的动作不算里程所以不消耗寿命」,其实驻车、充电、休眠与续跑期间的执行器动作实打实吃 N_life 配额(K3-01 已在动作次数配额公式的失效边界里点明),只按里程折算会系统性漏计。
相关课题