从单点校核到整车平衡：新能源热管理KULI一维系统仿真实践

先说一个我们项目组早先翻过车的场景。当时所有零部件级热管理仿真都报“合格”散热器校核没问题压缩机功耗核算没问题水泵流量也够。结果样车一到手跑城市拥堵加空调的工况冷却液温度一路往上顶风扇全开都压不住。复盘的时候才发现问题根本不在某个单件上而是系统耦合没算清楚——空调冷凝器排在冷却模块前面直接把这边的进风温度顶高了七八度水泵和风扇的控制时序又没配合好。从那以后我就形成了一个判断新能源项目的热管理如果不上到整车级别去做统一热模型光靠零部件级仿真去交差本质上是在赌运气。这轮项目我们把KULI作为主仿真工具搭了一整套整车级别的热管理热模型覆盖电驱、电池、空调、乘员舱把典型工况全部扫了一遍。整篇就当项目复盘报告来写重点讲清楚为什么这么搭、工况矩阵怎么设计、结果怎么用于工程决策以及中途踩过的那些坑。对正在做新能源热管理系统匹配尤其是一维系统仿真入门的工程师应该能省不少弯路。1. 为什么要做整车级热模型从“单点达标”到“全车平衡”1.1 单点校核的盲区在哪里以前我们做冷却系统校核习惯把每个换热器单独拎出来看散热器给定进风温度、风量、水流量然后算出口温度冷凝器单独给定冷凝温度和环境风量算换热量。这种思路的问题在于它默认所有边界条件是先验已知的但车辆实际运行时这些条件都是耦合出来的。举一个很典型的例子。低速爬坡加上空调最大制冷冷凝器排出的热量会直接进入冷却模块的进风气流。散热器入口的空气温度不是环境温度而是环境温度叠加冷凝器散热后的温升。我们实测中这一项有时能到8℃以上。单个散热器校核时如果设计输入用的是40℃环境温度算出来自然没问题但叠上冷凝器温升后实际进风温度已经接近48℃散热能力直接下降一截。这类问题只有把冷却模块和空调系统放在同一个模型里才能暴露出来。还有一个常见的盲区是控制策略。风扇什么时候开、开几档水泵转速怎么跟随温度变化电子节温器的开启过程是渐变的这些逻辑在单点校核里基本是被简化的。但正是这些暂态过程决定了实际工况下温度是平稳收敛还是反复振荡。我们第一版模型里风扇温控逻辑的迟滞窗口设得太窄结果仿真里风扇在20秒内连续启停十几次这在实际控制器里是不可能发生的。1.2 KULI这类一维系统工具在工具链中的位置整车热管理领域有三维CFD、一维系统仿真、台架试验三层工具。三维CFD能算清楚外流场、舱内流场、冷却模块的详细速度分布但算一个稳态点可能要跑好几天做不了长时间路谱工况扫描。试验最准确但成本高、周期长等到有样车再做系统级优化已经晚了。KULI这类一维热流体网络工具正好补中间这一段。它的计算思想跟电路网络很像把水泵当成流量源或压头源把管路和换热器当成流阻和热阻把散热器、冷凝器这些部件用NTU模型描述换热能力然后在同一个环境边界里把所有回路耦合起来求解。这样做最大的好处是计算快——一个稳态工况几秒钟就能出结果一个动态工况按真实时间几百秒来算也只要几分钟到十几分钟。这个速度允许我们在方案阶段做大批量参数扫描比如不同散热器尺寸、不同风扇map、不同水泵流量策略都可以快速比较。再加上KULI本身对冷却系统、空调系统、乘员舱这些领域建模有现成的部件库换热器实验数据可以直接以性能map形式导入控制逻辑也可以用查找表和事件触发来实现非常适合整车级模型搭建。1.3 整车级模型的合理预期我要先泼一盆冷水整车级KULI模型不是万能的它替代不了三维CFD也替代不了台架。它能解决的是“系统匹配和控制策略验证”这一类问题——散热器和冷凝器怎么布置、风扇和水泵怎么控制、电池和乘员舱的冷量分配怎么协调、某工况下哪个回路先到限值。这类问题要么试验做不起要么CFD算不动一维系统模型正好是性价比最高的解法。做之前团队里要统一预期。这个模型的目标不是给出某个散热器翅片片的温度分布而是回答“这套热管理系统在某些工况下能不能把各回路温度控制在限值以内哪些部件性能不够哪些控制参数需要调整”。一旦目标清楚了后面搭模型的颗粒度、数据需求、标定工作量就都清楚了。2. 模型架构与搭建流程从数据准备到一维热流体网络落地2.1 整车热管理系统拆解与模型边界现在的车型热管理系统已经不是一条冷却回路走天下了。我按当前主流的分法把系统拆成四个子部分子系统包含部件热源/冷源与外界换热路径电驱冷却回路电机、电机控制器、低温散热器、电子水泵、膨胀水壶铜耗、铁耗、开关损耗低温散热器直接排向环境空气电池热管理回路电池包、Chiller、加热器、电子水泵充放电欧姆热、极化热经Chiller与空调制冷回路换热或经加热器加热空调制冷回路压缩机、冷凝器、蒸发器、膨胀阀、Chiller乘员舱热负荷、电池冷负荷冷凝器向环境空气排热乘员舱采暖/制冷回路蒸发器、PTC/热泵冷凝器、鼓风机乘员舱热负荷通过风道送风到乘员舱如果项目是混动或者增程还要加一条发动机高温冷却回路和暖风芯体回路但建模逻辑是一样的。整车级模型的关键是“耦合”。上面四个子系统不是孤立的至少有四个耦合点冷凝器排热和散热器进风共用同一个冷却模块Chiller把电池热量搬进空调回路增加了冷凝器排热量乘员舱的热负荷直接影响蒸发器换热量进而影响压缩机功耗和冷凝器排热电池生热和乘员舱冷暖需求互相争抢空调能力。这些耦合关系必须在同一个模型里同时求解才能还原真实系统行为。2.2 数据准备是整车级模型最大的工作量做整车级热模型我个人经验里建模本身只占三成工作量数据准备、清洗、格式整理占七成。一开始以为KULI上手慢后来发现最卡进度的都是数据问题供应商给的散热器测试报告格式不统一风扇map缺少低背压区数据水泵外特性曲线没有覆盖目标转速段电池生热率数据只有25℃没有高温工况……每一项都可能让模型做不下去。我按经验整理了一份最小数据清单数据类别核心参数来源换热器性能数据液侧/气侧压降曲线、换热功率或UA值、尺寸供应商试验报告风扇数据不同电压/档位下的压升-风量曲线、功耗曲线供应商map或实测水泵数据不同转速下的扬程-流量曲线、功耗供应商map或实测管路数据管径、长度、局部阻力系数CAD/BOM电池生热不同SOC、温度、充放电倍率下的生热功率电芯实验标定压缩机数据不同转速、压比下的容积效率、等熵效率供应商map控制策略风扇档位切换温度、水泵转速跟随逻辑、压缩机转速控制控制部门/整车策略这里说一个容易被忽略的细节换热器性能数据必须明确测试标准工况。同一款散热器用不同风侧液侧温度组合测出来的UAmap可能细微不同如果拿来直接给KULI用高温工况外推时偏差会被放大。后面我会专门说这个坑。2.3 冷却模块风侧的建模逻辑整车级模型里最需要精细处理的是冷却模块因为它同时承担散热器、冷凝器、风扇、护风罩还有格栅开口的气流。KULI里风侧建模的思路是从入口环境条件出发空气依次流过格栅、冷凝器、散热器、风扇每经过一个部件空气温度和压降都会更新一次。最简单的递推思想是空调冷凝器把热量排入空气空气温度升高这个升温量等于冷凝器排热量除以空气质量流量和空气比热的乘积。下游散热器入口温度就是上游出口温度。所以风侧模型要同时满足两个方程换热方程决定每个换热器的进出风温差流动方程决定通过每个部件的气流流量即风扇压升等于整条风路的阻力。这个耦合在KULI里是自动求解的但建模时必须把风路阻力链建对。护风罩漏风、格栅局部阻力、风扇安装位置这些都会影响实际通过散热器的风量。我们后来对标台架数据时发现如果只建散热器加冷凝器不建格栅和护风罩阻力仿真风量会比实际偏高15%以上这个误差足以让水温结论从合格翻成不合格。2.4 控制策略的建模方式在KULI里做动态工况模拟控制策略不能省。你要把整车控制器的行为抽象成信号逻辑传感器读温度控制器比较温度和目标值输出PWM或档位信号给风扇、水泵、压缩机。KULI本身提供查找表、迟滞开关、PID等基础控制模块我的建议是先画一张“控制逻辑信号流图”把每个执行器的输入信号从哪个传感器来、判断逻辑是什么、输出怎么映射都列清楚再往模型里加。以电子风扇为例真实控制器通常是这样的冷却液温度超过92℃开一档低于88℃关一档超过95℃开二档低于92℃降回一档。一档和二档之间有一个迟滞区间防止频繁跳档。这个逻辑如果直接在KULI里写就是两个带迟滞的开关。不加迟滞的话仿真里风扇会高速振荡输出结果根本不收敛。压缩机在新能源车上通常转速可调控制目标往往是蒸发器出口温度或者电池Chiller出口温度中间串一个PID。KULI里做这种控制需要小心PID参数。我们后面会有专门一节讨论这个问题。2.5 从单部件标定到系统标定模型搭完不等于能直接出结果标定这关必须过。我自己的顺序是三步。第一步是单部件标定。散热器、冷凝器、中冷器这些部件单独拉出来用供应商试验报告里的工况点对标。每个换热器进口温度、流量给定看出口温度和换热量是否和试验一致。这一步通常能暴露换热器数据处理的问题比如UA曲线单位配错或者压降数据少了一个数量级。第二步是冷却模块风侧标定。把风扇、散热器、冷凝器、护风罩一起放进风洞测试数据里对比不同风扇档位下的风量。如果偏差大优先检查阻力设置和风扇map方向定义。第三步是整车回路标定。用一个标准工况比如40℃环境、120km/h巡航把系统所有回路跑起来对比整车试验数据。对标目标我一般卡在±2℃以内超过这个误差就要回头查是换热器数据问题还是控制逻辑问题。标定经验很重要。如果单部件都合格、整机却偏差大优先怀疑耦合位置冷凝器和散热器的间距、护风罩与风扇之间的间隙、回水管路的长度和弯曲造成的压降。这些在一个一维模型里都是可以修正的。3. 工况矩阵设计的关键逻辑严苛但不失真3.1 工况不是拍脑袋是一条一条论证出来的工况矩阵是我见过最多项目偷懒的地方。有人直接按“最高温、最大坡度、满载”拉了一个极限工况跑完发现温度超了就加散热器尺寸也不管这个工况是不是客户真实使用场景。也有人把所有整车路谱都搬进来让模型跑几天几夜最后输出一堆数据根本分析不过来。我的经验是把工况分成三类法规项、客户项、工程内部项。法规项必须满足国标或行标比如除霜除雾、空调降温性能客户项来自整车目标定义比如“45℃环境温度下连续爬坡12%坡度不掉功率”工程内部项是设计验证用的加速工况比法规更严苛但不要求作为交付承诺只是给自己留设计余量。3.2 一份完整的新能源热管理工况矩阵这是我们在项目里实际用过的工况矩阵模板新项目可以直接套工况编号工况名称环境温度车速坡度负载空调状态主要考核指标TM-01高温爬坡45℃40km/h8%满载最大制冷电机、电控、电池温度不降功率TM-02高温高速巡航40℃120km/h0%满载制冷各回路热平衡温度TM-03城市拥堵38℃0-30km/h循环0%满载制冷风扇最高档是否触发、电池峰值温度TM-04高温怠速45℃00%满载最大制冷冷凝器高压压力、压缩机能力TM-05低温冷启动-20℃0-60km/h0%半载采暖电池升温速率、乘员舱达标时间TM-06WLTC循环23℃动态0%满载随工况切换电池温度波动、空调能耗TM-07快充叠加行驶40℃动态0%50%SOC制冷电池最高温度、Chiller冷量分配这里面特别想强调TM-01和TM-07。高温爬坡是传统的热平衡极限考核考察系统持续散热能力。快充叠加行驶是新能源特有的严苛工况电池一边在快速充电产生大量热一边还要维持大功率放电同时乘员舱还要制冷整个空调系统的负荷是叠加的。这些工况在传统车里没有新能源热管理必须把它们加进来。3.3 动态边界条件怎么给定工况矩阵定的是宏观边界具体到模型里还需要定义动态输入车速随时间变化曲线、坡度随时间变化曲线、环境温度、光照辐射强度、乘员舱目标温度、电池初始SOC。特别要注意乘员舱热负荷。它不是简单的固定值而是随车速、日照、车外温度变化的。KULI里有乘员舱热模型可以直接算但如果没有乘员舱数据建议先按稳态热负荷给一个修正后的环境等效温度比如车内目标温度25℃、车外45℃、日照800W/m²等效换热系数对应一定的热负荷。这样至少能把空调负荷的影响抓准。电池生热率也要按工况区分。爬坡工况是大电流持续放电城市拥堵是间歇性放电加空调负荷快充工况是持续大倍率充电。生热率曲线建议直接从电芯测试数据转成电阻-温度-SOC三维查表而不是用固定值。否则电池温度动态特性会失真Chiller启停逻辑也验证不了。3.4 稳态工况的收敛判定与热平衡时间跑稳态工况时最怕的是模型看起来在波动其实没到真正平衡。我的习惯是设一个“观察窗口”来判断连续60秒模型时间内冷却液温度变化小于0.5℃判定为热平衡。然后记录平衡温度和达到平衡所需的时间。达到平衡的时间本身就是一个工程指标——如果热平衡温度在限值内但需要40分钟才稳定说明系统热惯性很大对实际驾驶体验也是负面影响。热平衡时间一定程度上取决于初始条件。做稳态工况时理想做法是把初始条件设得离预期平衡点近一点比如上一轮工况的终态作为下一轮初始值。这样能省很多计算时间但注意不要因此掩盖掉“从冷机开始升温是否会引起超调”这类冷态问题。冷起动工况就别偷懒必须从真实冷态初始值开始跑。4. 仿真结果解读与工程决策数据出来以后怎么用4.1 主控指标和辅助指标的区分KULI跑完一个工况可以输出几十个变量如果不提前分类分析时容易乱。我们项目里把输出分成三类。第一类是主控指标直接决定方案是否可行。比如电机控制器进水温度不得超过95℃电池最高温度不超过45℃不同电芯体系限值不同空调出风口温度在某个值以下冷凝器高压压力不超过限值。这些指标在模型里可以直接读曲线超标即判不合格。第二类是辅助诊断指标。包括散热器换热量、冷凝器排热量、风扇工作档位和功耗、水泵转速、压缩机转速、Chiller进出口温差。这些指标不直接决定合格性但能帮我们判断“为什么超标”。第三类是趋势指标。比如达到热平衡的时间、风扇全开时长占比、电池温度波动幅度。这些会影响耐久性和舒适性但不会让设计一票否决。4.2 超标的诊断顺序先分风侧水侧再查控制逻辑工况跑出来超标的处理顺序我总结了一个固定套路先锁定哪一个回路超再看回路的换热量和流量是否正常最后判断是部件能力不够还是控制策略不合理。以散热器出水温度超标为例。我会先看风侧散热器进风温度是多少是否显著高于环境温度说明冷却模块风路被上游排热影响通过散热器的风量是否达到设计值对比风扇map上的工作点。再看水侧冷却液流量是否足够水泵是否达到目标转速是否有旁通导致流量被分走。这两步走完超标原因是热源、换热、流量还是控制的问题基本能定位。这里有个工程直觉要分享如果散热器进风温度比环境高了很多第一优先级不是换大散热器而是先处理风路隔热问题。冷凝器排热混入散热器进风是新能源车前舱最常见的“隐形杀手”。通过调整冷凝器与散热器的间距、增加密封导流、改变风扇护风罩形状往往比单纯加大散热器更有效而且成本更低。4.3 两个实际案例的处理全过程高速爬坡风量不足案例。某次仿真发现TM-01高温爬坡工况下电驱控制器出口温度比限值高6℃。查曲线发现散热器换热量比设计值低了18%通过散热器的风量只有设计风量的82%。进一步查风扇map当前背压刚好落在风扇高效区边缘。最终调整护风罩开孔和风扇安装位置让风扇在相同转速下系统阻力降低风量提升到设计值的95%温度降回限值以内。这个方案没换任何散热器只是一个风路优化。电池快充Chiller旁通案例。TM-07快充工况电池温度峰值接近限值同时压缩机转速已经顶到上限。诊断发现Chiller和蒸发器是串联在空调回路里的电池热负荷和乘员舱热负荷叠加压缩机超能力了。后来在模型中加了一个Chiller旁通阀控制逻辑当乘员舱优先时让部分制冷剂绕过Chiller牺牲一点电池冷却能力保证乘员舱优先当电池温度逼近限值时再切换为电池优先。这个策略在KULI里验证了边界切换点最终压缩机转速降了12%电池温度也稳定在限值内。这两件事说明整车级热模型最大的价值在实物出来之前就能验证控制策略还能对系统参数做大批量快速比较。4.4 结果如何闭环到试验和策略标定仿真结果不能只停在模型里。两个出口必须做一是给试验部门一份“台架验证建议清单”明确哪个工况需要台架验证、测哪些位置、接受误差是多少二是给控制部门一份“标定参数建议表”比如风扇开启温度、旁通阀切换条件、水泵转速分段点。我们项目里实践下来把KULI模型跑完的精度和范围报告做成“数字原型基线”后续工程变更直接在这个基线上快速复算。例如散热器供应商建议把芯体厚度减薄10mm我们不需要重新做实验直接在模型里把换热器的几何参数改掉重跑一遍工况矩阵看哪些工况受影响。这个响应速度是试验台架完全做不到的。5. 踩坑记录整车级KULI模型最容易翻车的几个地方5.1 换热器性能曲线外推失真这是踩得最深的一个坑。散热器供应商给的测试报告通常只有标准工况数据——液侧80℃/60℃气侧40℃/30℃温差范围相对窄。我们在45℃高温工况里仿真散热器进出水温差很容易超出测试覆盖范围。一开始我们是直接把“换热量-流量”实验数据表塞给KULI查表结果高温工况误差很大因为同一张表外推到温差60℃时换热量的增长已经被平板效率模型修正了很多单纯查表会把换热量算虚高。后来改用NTU模型来描述换热器不再拿功率查表而是基于几何参数和物性计算UA值。UA值随流量的变化相对平滑外推可靠性高得多。现在KULI里做换热器建模我们一律用UA-map加压降-map的组合不再用功率-map。5.2 风扇map与风路阻力的匹配错误风扇供应商给的map是标准条件下的自由风量特性但真实使用环境里风扇装在散热器和冷凝器后面面对的背压远高于自由出风条件。如果直接把风扇map设置成“固定风量值”仿真风量会比实际高很多高温工况结论会偏乐观。正确做法是把风扇作为压升源处理不同转速下给出一条“压升-风量”曲线然后让KULI把这条曲线和风路阻力曲线求交点得到实际工作点。这个工作点才是通过冷却模块的真实风量。我们吃过亏之后现在每次拿到风扇map第一件事是确认有没有低背压区域数据没有就让供应商补测否则模型没法用。5.3 控制逻辑参数设置不当导致振荡整车级模型里控制参数不当最常见的现象就是温度曲线高频振荡。后来排查发现是PID控制器的输出没有做限幅或者温度传感器时间常数设得过小。KULI里的传感器模块如果不加一阶惯性滤波直接拿瞬时温度去控制风扇、水泵真实系统里传感器响应没那么快模型里就容易产生数值振荡。更隐蔽的一个问题是迟滞窗口太小。电子风扇切换温度差只有2℃的话仿真在稳态附近来回跳档风量时大时小热平衡温度反而不稳定。这个问题的解决方法是回到标定工况看实测的控制策略参数风扇开启温度和关闭温度之间至少要有4~6℃的迟滞压缩机PID要加输出饱和限制。建议先在开环模式下把执行器阶梯响应跑出来再闭环调PID参数能省很多时间。5.4 初始化与气穴模型处理整车级模型回路多初始化做得不好很容易跑出非物理结果。我们遇到过低温回路冷却液流量直接掉到0的情况排查后发现是初始时刻泵入口压力太低KULI的空化模型检测到气穴就把流量砍掉了。冷却液系统里有气体溶解和析出高温低压下确实会气穴但初始化时如果压力设置不对模型会误判成大幅气穴。解决办法有两个要么把膨胀水壶的初始压力设置到规范值让系统有个合理的静态压力要么先关闭空化选项做预运行等温度和流量稳定后再开启空化模型做精细计算。这个顺序很重要我们项目踩了一次之后现在初始化流程已经固化成标准操作。5.5 数据版本混乱问题最后说个不是技术问题的技术问题。整车级模型涉及一堆供应商数据散热器数据、风扇map、水泵曲线、电池生热率每个都在更新。有一次我们的模型突然从合格变成不合格排查了三天发现是供应商悄悄更新了散热器芯体数据而我们还在用旧版本。从那以后我们成立了数据管理规则每一版仿真报告上都写明所用数据的版本号和来源每次数据变更走变更申请在模型里存一个版本节点关键方案评审时先花十分钟核对敏感参数和上一版是否一致再讨论结果差异。这不是KULI软件的问题但整车级模型越做越大数据管理的好坏决定了仿真结果的可信度。这个项目做完之后我自己总结出一条工作纪律每次交付KULI模型之前先跑一遍基础健康检查——看各回路流量是否和泵map一致换热器效率是否落在合理范围温度曲线是否平滑有没有非物理振荡。有时候一张简单的水温-时间曲线比一百页报告都能说明问题。如果曲线本身是歪的后面再多的分析都是白搭。这套整车级热模型的流程现在已经沉淀成我们项目的标准做法新车型进来直接按这个框架复用数据一换工况一改结果就能出来。热管理这东西说到底就是系统匹配加控制逻辑KULI只是把这两件事放到一个模型里算清楚。