这两年我接手过好几款商用车混动项目从12米公交到4.5吨物流车都有。最让我印象深刻的是一次满载爬坡测试发动机转速已经被逼到最大扭矩区间驾驶员把油门踩到底车速依然往下掉记录仪上的SOC表还在一个劲儿往下滑。后来我们给这台车加了一套P2并联混合动力系统再跑同样的坡道电机在低转速段贡献的扭矩帮发动机稳住了转速整车从坡底到坡顶的时间缩短了约20%。这就是商用车P2并联混合动力的价值。它不追求彻底消灭发动机而是让发动机和电机各干各最擅长的事。今天我把这套系统的控制器功能规范编写过程和HCU控制策略的设计思路完整梳理一遍重点讲那些规范文档里不会写、但实车标定一定会遇到的工程问题给正在做商用车混动或者准备入行的朋友一个参考。1. 商用车混动选型P2并联凭什么成为最务实的过渡方案1.1 P2架构的定义与物理布置P2架构的定义其实很直观电机布置在发动机和变速箱之间电机的前端通过一个K0离合器与发动机曲轴相连后端直接耦合变速箱输入轴。这样一来K0离合器分离时电机可以单独驱动车轮实现纯电行驶K0离合器闭合时发动机和电机可以同时出力扭矩在变速箱输入轴处叠加。对比其他混动架构P2有几个明显的工程优势。我们先看一张架构对比表架构电机位置能否纯电行驶传统动总改动量商用车适配度P0发动机前端皮带轮不能只能启停和微混小较低P1发动机曲轴直接连接不能中低P2发动机与变速箱之间能中高P3变速箱输出端能中中P4驱动桥能大较低为什么P2在商用车上更吃得开核心在于保留二字。商用车发动机和变速箱的寿命周期长产线投资大P2方案不需要推倒现有的动力总成只需要在发动机飞轮端加装一个电机模块和离合器总成原变速箱原样保留整车的开发风险和生产切换成本都控制得住。对主机厂来说这是用最低的代价把一款传统燃油商用车的油耗和排放指标拉下来。1.2 商用车工况对P2的特殊需求商用车和乘用车的混动需求差别很大。乘用车追求的是起步加速感和油耗平衡商用车更看重的是重载爬坡的持续性、长时间怠速的燃油浪费、制动能量的回收量以及系统在高温、高寒、多尘环境下的可靠性。P2架构在应对这些需求时有几个天然匹配点。电机布置在变速箱输入端处于传动链的高扭矩侧可以用较小的电机获得较明显的轮端扭矩提升。商用车发动机怠速时间长P2的电机可以作为发电机在驻车或滑行状态下给动力电池补电从而减少发动机长时间低效怠速的工况。第三点是P2电机可以做得比P1的集成式电机功率大满足商用车频繁启停和市区工况下的电机助力需求。有一点容易忽略商用车空调、气泵等附件耗能很大很多纯电方案在冬季低温环境下电池续航崩得厉害而P2混动因为没有完全脱离发动机电池能量不足时发动机可以直接带动附件、同时发电整车不会有趴窝焦虑。1.3 为什么不一步到位做更复杂的混动架构我在跟很多团队交流时都会被问到P2只是过渡方案为什么不直接上双电机混联或者增程这个问题要分场景回答。双电机混联在乘用车上已经很成熟但商用车尤其是重卡和中卡的布置空间有限双电机方案的成本翻倍而且控制复杂度指数上升——两个电机加上发动机的扭矩协调模式数量翻一倍标定工作量也翻一倍。增程方案在公交场景确实有优势但如果整车经常跑长途高速增程的燃油经济性反而不如并联混动因为高速工况下发动机直驱的效率明显高于发电-电动机-再驱动的串联路径。P2并联方案本质上是一个抓大放小的策略只解决商用车最痛的城市工况、爬坡工况和怠速工况用最低的复杂度拿到最大的收益。这也是为什么国内不少主机厂的油改电平台和混动卡车项目都从P2切入。2. 功能规范怎么写边界、接口、安全等级一个都不能少2.1 先画系统拓扑再定义信号接口写功能规范最容易犯的错是上来就写策略逻辑。HCU混动控制器在整个动力域网络里到底扮演什么角色必须先理清楚。HCU不是直接执行器它是一个仲裁者接收驾驶员意图和整车状态经过策略计算后向发动机控制器ECM、变速箱控制器TCU、电机控制器MCU和电池管理系统BMS发出扭矩请求或模式请求。I/O接口的定义是功能规范的地基。我通常把接口分成硬线和CAN两类。硬线信号包括点火开关ON挡和START挡信号、刹车灯开关双通道、驻车开关、档位信号D/N/R、加速踏板两路模拟信号用于冗余校验。这些信号直接参与驾驶意图判断一旦失效必须要有明确的缺省值设计。比如加速踏板两路信号不一致超过阈值规范里必须写明进入跛行模式请求扭矩限制为最大值的30%。CAN信号则是策略运行的数据来源。HCU需要从ECM读取发动机实际扭矩、允许扭矩上限、发动机转速、水温、机油压力从TCU读取当前挡位、目标挡位、换挡状态、变速箱输入轴转速从BMS读取SOC、允许放电功率SOP、允许充电功率、电池温度、单体最高/最低电压从MCU读取电机转速、电机实际扭矩、电机温度和故障码。这里有商用车特有的坑各主机厂和零部件供应商的CAN协议差异很大。有的发动机ECM上报扭矩是2字节带符号数单位0.5Nm有的是4字节单位0.1Nm。功能规范里如果不写明每个信号的长度、单位、精度和有效范围到联调阶段就会出现扭矩数值差一倍还找不出原因的尴尬局面。另一个必须写明的是信号超时处理策略。例如发动机转速信号如果在200ms内没有更新HCU应当认为信号超时进入发动机状态未知保护模式此时禁止K0离合器结合避免在发动机实际转速未知的情况下强行耦合造成飞车或齿轮冲击。2.2 功能清单和模式定义的分层方法一份合格的功能规范功能清单要分层写清楚。我习惯分三层整车级功能、系统级功能、部件级功能。整车级功能描述用户在驾驶层面能感知到的功能包括钥匙起动、纯电起步、联合驱动、行车发电、驻车发电、能量回收、蠕行、跛行、自动停机。系统级功能是HCU为实现上述整车功能需要具备的内部能力包括模式仲裁、扭矩分配、K0离合器控制、换挡协调、SOC管理、故障降级。部件级功能则是对每个部件控制器的详细指令要求比如对MCU的扭矩指令格式、对ECM的起动请求信号、对TCU的换挡许可释放信号。模式定义建议用状态机方式表达。一个典型的HCU状态机如下模式名称功能描述进入条件退出条件OFF整车上电前状态钥匙OFFON挡有效STANDBY系统自检ON挡有效自检完成无A类故障READY系统就绪可驱动自检完成驱动条件不满足EV纯电驱动车速低于限值SOC高于下限油门需求超限或SOC低于下限HEV发动机电机联合驱动油门需求大或SOC过低油门需求回落CHARGING行车/驻车发电SOC低于充电阈值挡位允许SOC达到充电上限或停车RECUP制动能量回收刹车信号有效车速高于阈值刹车信号释放或车速低于阈值FAULT故障模式A类故障触发故障恢复且满足复位条件状态机设计最关键的是优先级仲裁。比如CHARGING模式下驾驶员突然深踩油门系统必须先切到HEV模式再进行扭矩提升而不是在CHARGING模式下直接把发动机扭矩拉高——否则发电功率和驱动功率会打架电池可能同时接受充电和放电请求BMS会直接报警。2.3 安全策略与故障降级的分级设计功能规范里的安全策略需要参考功能安全的思路来设计即使项目没强制要求ASIL等级扭矩安全监控也绝对不能少。我参与的项目里HCU内部至少要有两条并行的扭矩计算路径路径A是常规策略计算目标扭矩路径B是独立监控用简单的物理模型估算允许扭矩上限。当路径A的输出超过路径B的上限时HCU必须在50ms内把目标扭矩清零并置位故障标志。故障分级我用三类。A类故障是立即停机级包括K0离合器严重打滑、电机控制器过温超限、加速踏板两路信号不一致且持续500ms、CAN通信完全中断。A类故障触发后HCU应执行最保守的降级电机扭矩立即置零发动机扭矩请求置零变速箱回空挡点亮故障灯。B类故障是降功率级包括电机温度偏高但未超限、电池SOP受限、冷却系统效率下降。B类故障触发后HCU限制当前模式不允许切换到大功率模式比如禁止进入HEV联合驱动只能EV或CHARGING。C类故障是提示级比如SOC估算精度低、某传感器信号偶发超时但已恢复这类故障只记录不干预策略。我在实际项目里遇到过一个真实案例电机控制器报过一次瞬时过流后自动恢复由于故障恢复机制设置得太积极恢复时间只有50msHCU还没来得及降级电机又重新输出扭矩导致整车出现了一次明显的冲击。后来把方案改成瞬态故障必须连续累计3次才允许降级单次瞬态故障只做记录和提示不触发降级路径。这类细节如果功能规范里没写清楚到实车阶段就是很难复现的偶发闯动。3. HCU控制策略拆解从模式仲裁到扭矩协调的完整链路3.1 模式仲裁逻辑的工程化设计模式仲裁不是简单的条件满足就切换它需要考虑滞回区间和切换仲裁优先级。滞回区间是防止模式抖动最基础的手段。举个例子SOC低于20%时允许切入充电模式但充电模式的退出阈值不能设成20%要设到22%~23%否则SOC在20%附近波动时充电模式会反复切入切出。我踩过的一个典型坑是SOC抖动导致动力波动。某台测试车上行车发电模式下发动机一直在多喷油发电状态当SOC达到退出阈值45%时切回HEV但HEV模式下整车负载上升SOC很快又掉到44.7%系统再次切入CHARGING。驾驶员感受到的是每20秒左右一次明显的动力波动。解决方法是两件事叠加退出阈值提高到46%再加上一个退出充电模式后5分钟内的定时锁双重防抖。模式仲裁还要考虑整车网络里其他控制器的请求。比如TCU在换挡过程中会请求降扭此时HCU的模式仲裁必须优先响应降扭请求不能出现TCU正在换挡、HCU正好切入HEV并增大扭矩的低级冲突。仲裁顺序我通常定为安全降级 外部请求TCU/ECM 驾驶员意图 经济性模式选择。这个优先级关系必须在规范里明确写死不然联调时各方扯皮没完没了。3.2 扭矩分配策略规则查表还是实时优化扭矩分配是HCU最核心的计算逻辑。学术界动不动提动态规划、等效燃油消耗最小策略但商用车工程上很少直接跑实时优化算法——因为算力资源有限控制周期通常只有10ms跑复杂优化会吃掉太多CPU时间而且优化算法的鲁棒性在恶劣工况下难以验证。商用车主流的做法是规则查表。我的做法是先拿发动机的万有特性曲线划出一条发动机最优工作线OOL。这条曲线上的每个转速点对应一个发动机最经济的扭矩输出值。HCU实时计算驾驶员需求扭矩和当前车速、挡位下的发动机转速然后按以下规则分配工况整车需求扭矩发动机输出电机输出低负荷巡航小于发动机经济区下限最小经济扭矩或停机补足剩余扭矩或纯电行驶经济区行驶在发动机经济扭矩范围内按OOL输出不输出重载急加速大于发动机经济扭矩按OOL最大值输出补足缺口制动/滑行负扭矩不输出执行能量回收举例某款发动机转速1400rpm时的经济扭矩上限是850Nm整车此时需求1000Nm那么HCU让发动机请求850Nm、电机请求150Nm。如果整车需求只有300Nm发动机在这个转速下单独工作效率太低系统会倾向让电机多出力或者直接判断可以切入EV模式。这里有个容易被忽略的细节扭矩分配要留出电池SOP的动态约束。电池在低温或低SOC状态下允许放电功率会掉到很低的水平如果规则表里固定电机补150Nm但BMS给出的SOP只允许80NmHCU必须实时把缺口转移回发动机让发动机超出发经济区工作。这个SOP感知的自适应分配需要在功能规范里以约束条件的方式写明而不是在策略里写死一个比例。3.3 K0离合器与换挡过程的扭矩协调P2架构最考验功力的是两个动态过程EV和HEV之间的模式切换、变速箱换挡过程中的扭矩协调。先说EV切HEV。当驾驶员深踩油门触发HEV模式HCU要完成K0离合器闭合、发动机起动、扭矩接管三个动作。具体时序是HCU先命令电机增加扭矩同时控制K0离合器开始向结合方向移动当离合器压紧力达到一个临界值时利用电机把发动机拖到怠速以上转速比如800rpm发动机点火成功后开始输出扭矩K0离合器逐渐完全锁止锁止完成后由发动机接管主要驱动扭矩电机逐步撤出。这个过程中如果K0离合器的滑磨控制不好就会出现起步窜车的感受因为电机拖着发动机的时候传动链上多了一个旋转惯性体。再说换挡协调。商用车AMT换挡时间长、扭矩中断明显P2架构恰恰能弥补这一点。TCU发出换挡请求后HCU的控制目标不是简单降扭而是要接力——在发动机降扭的同时让电机立刻输出一个补偿扭矩来维持轮端驱动力等变速箱完成挂挡后发动机恢复扭矩、电机同步退出。这个过程要求HCU从TCU拿到提前换挡预告信号因为TCU的上一步是摘挡摘挡瞬间才收到请求就晚了。我在实车上调试时发现换挡补偿扭矩不能直接等于发动机降掉的扭矩因为换挡过程中变速箱输入轴转速会产生波动补偿值要给一个比例系数我常用的初值是0.7后续根据换挡平顺性评估微调。补多了会感觉动力弹一下补少了还是感觉断了一下。这部分的参数标定在台架上要反复做没有捷径。4. 实车标定与故障排查规范之外的真实工程问题4.1 起步时K0离合器结合点漂移的根治方法商用车干式离合器在频繁起步状态下磨损比乘用车快得多K0离合器的结合点咬合位置会随磨损和温度漂移。如果功能规范里写死了一个固定结合点参数冬季低温工况起步时往往出现整车闯动。原因是低温下摩擦片材料刚度和摩擦系数变化实际结合点位置偏移了标定值。我们当时的解决思路是给规范里增加一项K0动态学习逻辑每次K0处于分离状态且满足安全条件时车速零、发动机处于转速稳定区间HCU主动给离合器执行器一个小的结合位移扫描指令同时监测发动机转速变化。当发动机转速出现可识别的下降瞬间说明离合器摩擦片刚刚触碰到飞轮端记录此时的位置信号作为当前结合点写入标定表并做滤波更新。这个动态学习逻辑实测效果好但注意不要在发动机高负荷时做学习否则误判会把结合点学偏。4.2 SOC死区设置不当引发的充电模式高频切入切出前文已经提到过这个案例这里把完整的排查链路写出来供大家参考。现象驾驶员反馈行驶过程中整车有周期性的动力波动大约每20秒一次每次持续约2秒。排查过程第一步读取CAN总线日志确认波动期间发动机扭矩和电机扭矩确实有周期性跳变。第二步把跳变时间和模式切换事件对齐发现每次跳变前1秒左右HCU都发生了一次CHARGING模式到HEV模式的切换。第三步检查SOC曲线发现SOC在44.5%~45.5%之间往复波动而规范里写的进入充电阈值是44.8%、退出阈值是45%。第四步确认问题根源SOC在阈值附近抖动导致模式反复切换每一次切换必然伴随扭矩重新分配。修复方案把退出阈值从45%提高到46%并增加退出充电模式后5分钟定时锁。锁的作用是即使SOC再次跌破进入阈值也至少等待5分钟才允许再次进入充电模式。这个定时锁的值要根据整车电池容量和平均行驶工况来定太短治标不治本太长可能导致电一直充不满。4.3 能量回收与机械制动衔接的前冲感商用车的气压制动系统从踩下刹车到制动力完全建立有几百毫秒的延迟。混动系统的能量回收扭矩响应快得多一踩刹车回收扭矩可能在几十毫秒内达到设定值。这就有个衔接问题如果回收扭矩在刹车松开时瞬间撤销而机械制动力还撑着就会出现整车被踹一脚的前冲感。处理手法是给回收扭矩加斜坡控制——回收扭矩的上升斜率和下降斜率都要按标定表来设。上升斜率要在回收效率和乘员舒适性之间取舍太高了点头感明显太低了回收能量少。我通常在初版标定时把上升斜率设为120Nm/s下降斜率设为100Nm/s然后根据整车主观评价微调。另外一条经验如果整车配了EBS电子制动系统建议让HCU通过CAN从EBS读取制动需求值而不是只用刹车灯开关的硬线信号。前者的信息量丰富得多可以做更精细的回收-机械联合控制。4.4 一次偶发动力丢失的完整排查链路这个案例很典型值得展开。测试车辆出现偶发性动力丢失仪表没有任何报警车辆大概每月出现一两次突然动力中断约1秒后自行恢复。这种问题在实车排查看似毫无头绪但按链路走并不复杂。排查链路第一步是给整车CAN日志打点特别标注HCU的指令值和实际反馈值。经过近一周的路试抓到一次复现发现动力丢失瞬间MCU上报了瞬时过流故障故障码P0503MCU按照自身逻辑将扭矩清零由于MCU只清了电机扭矩发动机还在按原指令输出整车实际驱动力骤减。第二步调取MCU内部故障记录确认过流发生在电机转矩指令最高的时刻电流峰值超过了MCU的保护阈值但只持续了约10ms。第三步在HIL平台上复现过流条件。用同样的电机模型和相同的控制参数发现过流点始终出现在特定转速区间内的扭矩阶跃处。第四步检查电机旋变零位标定发现零位偏差约4.2度。就是这4.2度的偏差导致特定工况下电流环解算出现瞬时振荡电流峰值突破保护线。这个问题的本质不是MCU误保护而是旋变零位标定漂移。根因找到后校准了零位重新标定问题消失。这次排查让我意识到功能规范里要明确规定故障恢复的次数冗余不能被单次瞬态故障触发降级同时所有执行器控制器的内部故障码必须能通过诊断仪读取并留存时间戳否则排查这种偶发问题真的要靠运气。5. 从模型到量产功能规范的落地验证与工具链建议5.1 基于模型开发让规范变成可执行的设计我现在做HCU策略开发标准路径是MATLAB/Simulink/Stateflow建模仿真、代码自动生成、HIL验证、台架验证、实车标定。功能规范的文字描述要能对应到模型里的每一个模块。我给团队立过一条规矩规范里的每一条需求都必须有对应的模型路径和测试用例编号做成需求—模型—测试三层关联表。不然到后期规范更新了模型没更新或者模型改了规范没同步问题非常隐蔽。Simulink建模时特别要注意Stateflow状态机的可读性。模式仲裁逻辑用Stateflow写很直观但一旦模式多了状态图会乱成一团。我的习惯是每个模式单独画一个子状态图状态转换条件统一用Simulink Signal不直接在Stateflow里写魔术数字magic number。比如充电阈值这个标定量应该在模型里定义为可标定参数用标定工具如INCA可以在线修改而不是在Stateflow里写成常数。这个习惯能省掉后面大量的标定返工时间。5.2 HIL测试的覆盖面故障注入必须比正常工况多硬件在环测试是HCU策略验证的主力手段。HIL测试最容易走入的一个误区是测试用例全部围绕正常工况故障注入用例只覆盖A类故障触发这么浅浅一层。真正要补的故障用例包括信号超时CAN信号周期性丢失、信号漂移传感器数值缓慢偏离真值、信号跳变某帧报文数值瞬间跳变到上限、通信总线单节点失效、总线负载过高导致延迟增大。这些场景在实车上可能以极低概率出现但出现了就会带来安全风险。我曾经在HIL测试里发现过一个很深的BugHCU在BMS的SOC信号报文超时后进入了电池状态未知模式把电机可用功率降为零。这个逻辑本身合理但HIL测试发现当BMS报文只是偶发丢帧、并未长时间中断时如果超时判断窗口设置太短用了200ms会导致EV模式下频繁地功率受限-恢复-功率受限驾驶员感觉动力一喘一喘的。后来把超时判断改成连续3帧丢失才进入降级问题解决。这个参数就是在HIL测试阶段压出来的靠实车去发现要浪费很多时间。5.3 标定数据与软件版本管理量产售后最大的坑商用车混动项目量产后售后问题很大比例跟软件和标定版本错配有关。HCU策略软件、ECM标定、MCU固件、TCU软件任何一个部件升级后都和整车不匹配就会出千奇百怪的现象。我吃过一次亏某台售后车辆反馈充电异常检查半天最后发现是MCU固件被刷成了新版本而HCU侧的电机控制参数还按旧版本标定两个不匹配导致电机在发电模式下一直有微小的功率振荡。现在我们的做法是每次软件发布必须带一个整车系统级版本号所有控制器软件和标定数据的版本组合必须在这个版本矩阵里登记过才能出厂。HCU上电自检阶段通过CAN总线读取其他控制器的软件版本号如果跟当前整车的版本矩阵不匹配直接在仪表上报版本不一致故障不允许进入混动模式。这个策略在一开始被标定工程师抱怨太繁琐但跑过一年售后数据后大家都承认是值得的。5.4 冬夏季标定电池SOP决定切换策略上限电池的允许放电/充电功率SOP随温度变化极大。常温下BMS可能给到120kW的放电功率零下20度可能只有40kW。这意味着同一个HCU策略在夏季标定好的模式切换条件冬季很可能是失效的——比如EV模式下电机需要输出80kW但电池只允许40kW如果不提前做针对性的SOP限制逻辑电机会直接请求扭矩超标BMS强制限功率整车动力性大打折扣。所以冬夏季标定是商用车混动项目必做的环节。冬季标定的重点不是一个标定值打天下而是验证HCU策略在电池SOP受限这个边界条件下是否仍然能保持模式切换的稳定性。我的建议是功能规范里专门加一节SOP工况下的扭矩分配约束当BMS上报的可用放电功率低于当前EV模式需求功率时HCU应提前切入HEV模式并降低电机请求扭矩而不是等到BMS限功率动作后再被动降级。提前量和滞后量的标定冬季高温场地跑一圈就有结论了。写到最后想说说心里话。HCU的功能规范不是写出来给评审专家看的是写给三年后接手这个项目的工程师看的——他们在标定现场遇到一个不可思议的故障时翻规范如果能找到对应的约束条件和故障处理策略就有可能在两小时内定位问题而不是用两周时间重新踩一遍我们踩过的坑。P2并联混合动力的技术路线在商用车领域还会存在相当长一段时间它的每一次优化、每一个bug修复都应该沉淀成规范里的条文和注释。你手上的这张扭矩分配表格、那组K0结合点学习参数就是整个团队经验的结晶。工程的价值往往不在那些高大上的算法里而在这一个又一个被写进规范的真实细节里。 
长河君 · 2026/10/24 4:34:19 · 阅读 1.2k 商用车P2并联混动HCU控制策略与功能规范深度解析
这两年我接手过好几款商用车混动项目从12米公交到4.5吨物流车都有。最让我印象深刻的是一次满载爬坡测试发动机转速已经被逼到最大扭矩区间驾驶员把油门踩到底车速依然往下掉记录仪上的SOC表还在一个劲儿往下滑。后来我们给这台车加了一套P2并联混合动力系统再跑同样的坡道电机在低转速段贡献的扭矩帮发动机稳住了转速整车从坡底到坡顶的时间缩短了约20%。这就是商用车P2并联混合动力的价值。它不追求彻底消灭发动机而是让发动机和电机各干各最擅长的事。今天我把这套系统的控制器功能规范编写过程和HCU控制策略的设计思路完整梳理一遍重点讲那些规范文档里不会写、但实车标定一定会遇到的工程问题给正在做商用车混动或者准备入行的朋友一个参考。1. 商用车混动选型P2并联凭什么成为最务实的过渡方案1.1 P2架构的定义与物理布置P2架构的定义其实很直观电机布置在发动机和变速箱之间电机的前端通过一个K0离合器与发动机曲轴相连后端直接耦合变速箱输入轴。这样一来K0离合器分离时电机可以单独驱动车轮实现纯电行驶K0离合器闭合时发动机和电机可以同时出力扭矩在变速箱输入轴处叠加。对比其他混动架构P2有几个明显的工程优势。我们先看一张架构对比表架构电机位置能否纯电行驶传统动总改动量商用车适配度P0发动机前端皮带轮不能只能启停和微混小较低P1发动机曲轴直接连接不能中低P2发动机与变速箱之间能中高P3变速箱输出端能中中P4驱动桥能大较低为什么P2在商用车上更吃得开核心在于保留二字。商用车发动机和变速箱的寿命周期长产线投资大P2方案不需要推倒现有的动力总成只需要在发动机飞轮端加装一个电机模块和离合器总成原变速箱原样保留整车的开发风险和生产切换成本都控制得住。对主机厂来说这是用最低的代价把一款传统燃油商用车的油耗和排放指标拉下来。1.2 商用车工况对P2的特殊需求商用车和乘用车的混动需求差别很大。乘用车追求的是起步加速感和油耗平衡商用车更看重的是重载爬坡的持续性、长时间怠速的燃油浪费、制动能量的回收量以及系统在高温、高寒、多尘环境下的可靠性。P2架构在应对这些需求时有几个天然匹配点。电机布置在变速箱输入端处于传动链的高扭矩侧可以用较小的电机获得较明显的轮端扭矩提升。商用车发动机怠速时间长P2的电机可以作为发电机在驻车或滑行状态下给动力电池补电从而减少发动机长时间低效怠速的工况。第三点是P2电机可以做得比P1的集成式电机功率大满足商用车频繁启停和市区工况下的电机助力需求。有一点容易忽略商用车空调、气泵等附件耗能很大很多纯电方案在冬季低温环境下电池续航崩得厉害而P2混动因为没有完全脱离发动机电池能量不足时发动机可以直接带动附件、同时发电整车不会有趴窝焦虑。1.3 为什么不一步到位做更复杂的混动架构我在跟很多团队交流时都会被问到P2只是过渡方案为什么不直接上双电机混联或者增程这个问题要分场景回答。双电机混联在乘用车上已经很成熟但商用车尤其是重卡和中卡的布置空间有限双电机方案的成本翻倍而且控制复杂度指数上升——两个电机加上发动机的扭矩协调模式数量翻一倍标定工作量也翻一倍。增程方案在公交场景确实有优势但如果整车经常跑长途高速增程的燃油经济性反而不如并联混动因为高速工况下发动机直驱的效率明显高于发电-电动机-再驱动的串联路径。P2并联方案本质上是一个抓大放小的策略只解决商用车最痛的城市工况、爬坡工况和怠速工况用最低的复杂度拿到最大的收益。这也是为什么国内不少主机厂的油改电平台和混动卡车项目都从P2切入。2. 功能规范怎么写边界、接口、安全等级一个都不能少2.1 先画系统拓扑再定义信号接口写功能规范最容易犯的错是上来就写策略逻辑。HCU混动控制器在整个动力域网络里到底扮演什么角色必须先理清楚。HCU不是直接执行器它是一个仲裁者接收驾驶员意图和整车状态经过策略计算后向发动机控制器ECM、变速箱控制器TCU、电机控制器MCU和电池管理系统BMS发出扭矩请求或模式请求。I/O接口的定义是功能规范的地基。我通常把接口分成硬线和CAN两类。硬线信号包括点火开关ON挡和START挡信号、刹车灯开关双通道、驻车开关、档位信号D/N/R、加速踏板两路模拟信号用于冗余校验。这些信号直接参与驾驶意图判断一旦失效必须要有明确的缺省值设计。比如加速踏板两路信号不一致超过阈值规范里必须写明进入跛行模式请求扭矩限制为最大值的30%。CAN信号则是策略运行的数据来源。HCU需要从ECM读取发动机实际扭矩、允许扭矩上限、发动机转速、水温、机油压力从TCU读取当前挡位、目标挡位、换挡状态、变速箱输入轴转速从BMS读取SOC、允许放电功率SOP、允许充电功率、电池温度、单体最高/最低电压从MCU读取电机转速、电机实际扭矩、电机温度和故障码。这里有商用车特有的坑各主机厂和零部件供应商的CAN协议差异很大。有的发动机ECM上报扭矩是2字节带符号数单位0.5Nm有的是4字节单位0.1Nm。功能规范里如果不写明每个信号的长度、单位、精度和有效范围到联调阶段就会出现扭矩数值差一倍还找不出原因的尴尬局面。另一个必须写明的是信号超时处理策略。例如发动机转速信号如果在200ms内没有更新HCU应当认为信号超时进入发动机状态未知保护模式此时禁止K0离合器结合避免在发动机实际转速未知的情况下强行耦合造成飞车或齿轮冲击。2.2 功能清单和模式定义的分层方法一份合格的功能规范功能清单要分层写清楚。我习惯分三层整车级功能、系统级功能、部件级功能。整车级功能描述用户在驾驶层面能感知到的功能包括钥匙起动、纯电起步、联合驱动、行车发电、驻车发电、能量回收、蠕行、跛行、自动停机。系统级功能是HCU为实现上述整车功能需要具备的内部能力包括模式仲裁、扭矩分配、K0离合器控制、换挡协调、SOC管理、故障降级。部件级功能则是对每个部件控制器的详细指令要求比如对MCU的扭矩指令格式、对ECM的起动请求信号、对TCU的换挡许可释放信号。模式定义建议用状态机方式表达。一个典型的HCU状态机如下模式名称功能描述进入条件退出条件OFF整车上电前状态钥匙OFFON挡有效STANDBY系统自检ON挡有效自检完成无A类故障READY系统就绪可驱动自检完成驱动条件不满足EV纯电驱动车速低于限值SOC高于下限油门需求超限或SOC低于下限HEV发动机电机联合驱动油门需求大或SOC过低油门需求回落CHARGING行车/驻车发电SOC低于充电阈值挡位允许SOC达到充电上限或停车RECUP制动能量回收刹车信号有效车速高于阈值刹车信号释放或车速低于阈值FAULT故障模式A类故障触发故障恢复且满足复位条件状态机设计最关键的是优先级仲裁。比如CHARGING模式下驾驶员突然深踩油门系统必须先切到HEV模式再进行扭矩提升而不是在CHARGING模式下直接把发动机扭矩拉高——否则发电功率和驱动功率会打架电池可能同时接受充电和放电请求BMS会直接报警。2.3 安全策略与故障降级的分级设计功能规范里的安全策略需要参考功能安全的思路来设计即使项目没强制要求ASIL等级扭矩安全监控也绝对不能少。我参与的项目里HCU内部至少要有两条并行的扭矩计算路径路径A是常规策略计算目标扭矩路径B是独立监控用简单的物理模型估算允许扭矩上限。当路径A的输出超过路径B的上限时HCU必须在50ms内把目标扭矩清零并置位故障标志。故障分级我用三类。A类故障是立即停机级包括K0离合器严重打滑、电机控制器过温超限、加速踏板两路信号不一致且持续500ms、CAN通信完全中断。A类故障触发后HCU应执行最保守的降级电机扭矩立即置零发动机扭矩请求置零变速箱回空挡点亮故障灯。B类故障是降功率级包括电机温度偏高但未超限、电池SOP受限、冷却系统效率下降。B类故障触发后HCU限制当前模式不允许切换到大功率模式比如禁止进入HEV联合驱动只能EV或CHARGING。C类故障是提示级比如SOC估算精度低、某传感器信号偶发超时但已恢复这类故障只记录不干预策略。我在实际项目里遇到过一个真实案例电机控制器报过一次瞬时过流后自动恢复由于故障恢复机制设置得太积极恢复时间只有50msHCU还没来得及降级电机又重新输出扭矩导致整车出现了一次明显的冲击。后来把方案改成瞬态故障必须连续累计3次才允许降级单次瞬态故障只做记录和提示不触发降级路径。这类细节如果功能规范里没写清楚到实车阶段就是很难复现的偶发闯动。3. HCU控制策略拆解从模式仲裁到扭矩协调的完整链路3.1 模式仲裁逻辑的工程化设计模式仲裁不是简单的条件满足就切换它需要考虑滞回区间和切换仲裁优先级。滞回区间是防止模式抖动最基础的手段。举个例子SOC低于20%时允许切入充电模式但充电模式的退出阈值不能设成20%要设到22%~23%否则SOC在20%附近波动时充电模式会反复切入切出。我踩过的一个典型坑是SOC抖动导致动力波动。某台测试车上行车发电模式下发动机一直在多喷油发电状态当SOC达到退出阈值45%时切回HEV但HEV模式下整车负载上升SOC很快又掉到44.7%系统再次切入CHARGING。驾驶员感受到的是每20秒左右一次明显的动力波动。解决方法是两件事叠加退出阈值提高到46%再加上一个退出充电模式后5分钟内的定时锁双重防抖。模式仲裁还要考虑整车网络里其他控制器的请求。比如TCU在换挡过程中会请求降扭此时HCU的模式仲裁必须优先响应降扭请求不能出现TCU正在换挡、HCU正好切入HEV并增大扭矩的低级冲突。仲裁顺序我通常定为安全降级 外部请求TCU/ECM 驾驶员意图 经济性模式选择。这个优先级关系必须在规范里明确写死不然联调时各方扯皮没完没了。3.2 扭矩分配策略规则查表还是实时优化扭矩分配是HCU最核心的计算逻辑。学术界动不动提动态规划、等效燃油消耗最小策略但商用车工程上很少直接跑实时优化算法——因为算力资源有限控制周期通常只有10ms跑复杂优化会吃掉太多CPU时间而且优化算法的鲁棒性在恶劣工况下难以验证。商用车主流的做法是规则查表。我的做法是先拿发动机的万有特性曲线划出一条发动机最优工作线OOL。这条曲线上的每个转速点对应一个发动机最经济的扭矩输出值。HCU实时计算驾驶员需求扭矩和当前车速、挡位下的发动机转速然后按以下规则分配工况整车需求扭矩发动机输出电机输出低负荷巡航小于发动机经济区下限最小经济扭矩或停机补足剩余扭矩或纯电行驶经济区行驶在发动机经济扭矩范围内按OOL输出不输出重载急加速大于发动机经济扭矩按OOL最大值输出补足缺口制动/滑行负扭矩不输出执行能量回收举例某款发动机转速1400rpm时的经济扭矩上限是850Nm整车此时需求1000Nm那么HCU让发动机请求850Nm、电机请求150Nm。如果整车需求只有300Nm发动机在这个转速下单独工作效率太低系统会倾向让电机多出力或者直接判断可以切入EV模式。这里有个容易被忽略的细节扭矩分配要留出电池SOP的动态约束。电池在低温或低SOC状态下允许放电功率会掉到很低的水平如果规则表里固定电机补150Nm但BMS给出的SOP只允许80NmHCU必须实时把缺口转移回发动机让发动机超出发经济区工作。这个SOP感知的自适应分配需要在功能规范里以约束条件的方式写明而不是在策略里写死一个比例。3.3 K0离合器与换挡过程的扭矩协调P2架构最考验功力的是两个动态过程EV和HEV之间的模式切换、变速箱换挡过程中的扭矩协调。先说EV切HEV。当驾驶员深踩油门触发HEV模式HCU要完成K0离合器闭合、发动机起动、扭矩接管三个动作。具体时序是HCU先命令电机增加扭矩同时控制K0离合器开始向结合方向移动当离合器压紧力达到一个临界值时利用电机把发动机拖到怠速以上转速比如800rpm发动机点火成功后开始输出扭矩K0离合器逐渐完全锁止锁止完成后由发动机接管主要驱动扭矩电机逐步撤出。这个过程中如果K0离合器的滑磨控制不好就会出现起步窜车的感受因为电机拖着发动机的时候传动链上多了一个旋转惯性体。再说换挡协调。商用车AMT换挡时间长、扭矩中断明显P2架构恰恰能弥补这一点。TCU发出换挡请求后HCU的控制目标不是简单降扭而是要接力——在发动机降扭的同时让电机立刻输出一个补偿扭矩来维持轮端驱动力等变速箱完成挂挡后发动机恢复扭矩、电机同步退出。这个过程要求HCU从TCU拿到提前换挡预告信号因为TCU的上一步是摘挡摘挡瞬间才收到请求就晚了。我在实车上调试时发现换挡补偿扭矩不能直接等于发动机降掉的扭矩因为换挡过程中变速箱输入轴转速会产生波动补偿值要给一个比例系数我常用的初值是0.7后续根据换挡平顺性评估微调。补多了会感觉动力弹一下补少了还是感觉断了一下。这部分的参数标定在台架上要反复做没有捷径。4. 实车标定与故障排查规范之外的真实工程问题4.1 起步时K0离合器结合点漂移的根治方法商用车干式离合器在频繁起步状态下磨损比乘用车快得多K0离合器的结合点咬合位置会随磨损和温度漂移。如果功能规范里写死了一个固定结合点参数冬季低温工况起步时往往出现整车闯动。原因是低温下摩擦片材料刚度和摩擦系数变化实际结合点位置偏移了标定值。我们当时的解决思路是给规范里增加一项K0动态学习逻辑每次K0处于分离状态且满足安全条件时车速零、发动机处于转速稳定区间HCU主动给离合器执行器一个小的结合位移扫描指令同时监测发动机转速变化。当发动机转速出现可识别的下降瞬间说明离合器摩擦片刚刚触碰到飞轮端记录此时的位置信号作为当前结合点写入标定表并做滤波更新。这个动态学习逻辑实测效果好但注意不要在发动机高负荷时做学习否则误判会把结合点学偏。4.2 SOC死区设置不当引发的充电模式高频切入切出前文已经提到过这个案例这里把完整的排查链路写出来供大家参考。现象驾驶员反馈行驶过程中整车有周期性的动力波动大约每20秒一次每次持续约2秒。排查过程第一步读取CAN总线日志确认波动期间发动机扭矩和电机扭矩确实有周期性跳变。第二步把跳变时间和模式切换事件对齐发现每次跳变前1秒左右HCU都发生了一次CHARGING模式到HEV模式的切换。第三步检查SOC曲线发现SOC在44.5%~45.5%之间往复波动而规范里写的进入充电阈值是44.8%、退出阈值是45%。第四步确认问题根源SOC在阈值附近抖动导致模式反复切换每一次切换必然伴随扭矩重新分配。修复方案把退出阈值从45%提高到46%并增加退出充电模式后5分钟定时锁。锁的作用是即使SOC再次跌破进入阈值也至少等待5分钟才允许再次进入充电模式。这个定时锁的值要根据整车电池容量和平均行驶工况来定太短治标不治本太长可能导致电一直充不满。4.3 能量回收与机械制动衔接的前冲感商用车的气压制动系统从踩下刹车到制动力完全建立有几百毫秒的延迟。混动系统的能量回收扭矩响应快得多一踩刹车回收扭矩可能在几十毫秒内达到设定值。这就有个衔接问题如果回收扭矩在刹车松开时瞬间撤销而机械制动力还撑着就会出现整车被踹一脚的前冲感。处理手法是给回收扭矩加斜坡控制——回收扭矩的上升斜率和下降斜率都要按标定表来设。上升斜率要在回收效率和乘员舒适性之间取舍太高了点头感明显太低了回收能量少。我通常在初版标定时把上升斜率设为120Nm/s下降斜率设为100Nm/s然后根据整车主观评价微调。另外一条经验如果整车配了EBS电子制动系统建议让HCU通过CAN从EBS读取制动需求值而不是只用刹车灯开关的硬线信号。前者的信息量丰富得多可以做更精细的回收-机械联合控制。4.4 一次偶发动力丢失的完整排查链路这个案例很典型值得展开。测试车辆出现偶发性动力丢失仪表没有任何报警车辆大概每月出现一两次突然动力中断约1秒后自行恢复。这种问题在实车排查看似毫无头绪但按链路走并不复杂。排查链路第一步是给整车CAN日志打点特别标注HCU的指令值和实际反馈值。经过近一周的路试抓到一次复现发现动力丢失瞬间MCU上报了瞬时过流故障故障码P0503MCU按照自身逻辑将扭矩清零由于MCU只清了电机扭矩发动机还在按原指令输出整车实际驱动力骤减。第二步调取MCU内部故障记录确认过流发生在电机转矩指令最高的时刻电流峰值超过了MCU的保护阈值但只持续了约10ms。第三步在HIL平台上复现过流条件。用同样的电机模型和相同的控制参数发现过流点始终出现在特定转速区间内的扭矩阶跃处。第四步检查电机旋变零位标定发现零位偏差约4.2度。就是这4.2度的偏差导致特定工况下电流环解算出现瞬时振荡电流峰值突破保护线。这个问题的本质不是MCU误保护而是旋变零位标定漂移。根因找到后校准了零位重新标定问题消失。这次排查让我意识到功能规范里要明确规定故障恢复的次数冗余不能被单次瞬态故障触发降级同时所有执行器控制器的内部故障码必须能通过诊断仪读取并留存时间戳否则排查这种偶发问题真的要靠运气。5. 从模型到量产功能规范的落地验证与工具链建议5.1 基于模型开发让规范变成可执行的设计我现在做HCU策略开发标准路径是MATLAB/Simulink/Stateflow建模仿真、代码自动生成、HIL验证、台架验证、实车标定。功能规范的文字描述要能对应到模型里的每一个模块。我给团队立过一条规矩规范里的每一条需求都必须有对应的模型路径和测试用例编号做成需求—模型—测试三层关联表。不然到后期规范更新了模型没更新或者模型改了规范没同步问题非常隐蔽。Simulink建模时特别要注意Stateflow状态机的可读性。模式仲裁逻辑用Stateflow写很直观但一旦模式多了状态图会乱成一团。我的习惯是每个模式单独画一个子状态图状态转换条件统一用Simulink Signal不直接在Stateflow里写魔术数字magic number。比如充电阈值这个标定量应该在模型里定义为可标定参数用标定工具如INCA可以在线修改而不是在Stateflow里写成常数。这个习惯能省掉后面大量的标定返工时间。5.2 HIL测试的覆盖面故障注入必须比正常工况多硬件在环测试是HCU策略验证的主力手段。HIL测试最容易走入的一个误区是测试用例全部围绕正常工况故障注入用例只覆盖A类故障触发这么浅浅一层。真正要补的故障用例包括信号超时CAN信号周期性丢失、信号漂移传感器数值缓慢偏离真值、信号跳变某帧报文数值瞬间跳变到上限、通信总线单节点失效、总线负载过高导致延迟增大。这些场景在实车上可能以极低概率出现但出现了就会带来安全风险。我曾经在HIL测试里发现过一个很深的BugHCU在BMS的SOC信号报文超时后进入了电池状态未知模式把电机可用功率降为零。这个逻辑本身合理但HIL测试发现当BMS报文只是偶发丢帧、并未长时间中断时如果超时判断窗口设置太短用了200ms会导致EV模式下频繁地功率受限-恢复-功率受限驾驶员感觉动力一喘一喘的。后来把超时判断改成连续3帧丢失才进入降级问题解决。这个参数就是在HIL测试阶段压出来的靠实车去发现要浪费很多时间。5.3 标定数据与软件版本管理量产售后最大的坑商用车混动项目量产后售后问题很大比例跟软件和标定版本错配有关。HCU策略软件、ECM标定、MCU固件、TCU软件任何一个部件升级后都和整车不匹配就会出千奇百怪的现象。我吃过一次亏某台售后车辆反馈充电异常检查半天最后发现是MCU固件被刷成了新版本而HCU侧的电机控制参数还按旧版本标定两个不匹配导致电机在发电模式下一直有微小的功率振荡。现在我们的做法是每次软件发布必须带一个整车系统级版本号所有控制器软件和标定数据的版本组合必须在这个版本矩阵里登记过才能出厂。HCU上电自检阶段通过CAN总线读取其他控制器的软件版本号如果跟当前整车的版本矩阵不匹配直接在仪表上报版本不一致故障不允许进入混动模式。这个策略在一开始被标定工程师抱怨太繁琐但跑过一年售后数据后大家都承认是值得的。5.4 冬夏季标定电池SOP决定切换策略上限电池的允许放电/充电功率SOP随温度变化极大。常温下BMS可能给到120kW的放电功率零下20度可能只有40kW。这意味着同一个HCU策略在夏季标定好的模式切换条件冬季很可能是失效的——比如EV模式下电机需要输出80kW但电池只允许40kW如果不提前做针对性的SOP限制逻辑电机会直接请求扭矩超标BMS强制限功率整车动力性大打折扣。所以冬夏季标定是商用车混动项目必做的环节。冬季标定的重点不是一个标定值打天下而是验证HCU策略在电池SOP受限这个边界条件下是否仍然能保持模式切换的稳定性。我的建议是功能规范里专门加一节SOP工况下的扭矩分配约束当BMS上报的可用放电功率低于当前EV模式需求功率时HCU应提前切入HEV模式并降低电机请求扭矩而不是等到BMS限功率动作后再被动降级。提前量和滞后量的标定冬季高温场地跑一圈就有结论了。写到最后想说说心里话。HCU的功能规范不是写出来给评审专家看的是写给三年后接手这个项目的工程师看的——他们在标定现场遇到一个不可思议的故障时翻规范如果能找到对应的约束条件和故障处理策略就有可能在两小时内定位问题而不是用两周时间重新踩一遍我们踩过的坑。P2并联混合动力的技术路线在商用车领域还会存在相当长一段时间它的每一次优化、每一个bug修复都应该沉淀成规范里的条文和注释。你手上的这张扭矩分配表格、那组K0结合点学习参数就是整个团队经验的结晶。工程的价值往往不在那些高大上的算法里而在这一个又一个被写进规范的真实细节里。