做了这么多年混动整车控制相关的东西我最大的体会是真正难的不是搞清楚发动机和电机各自的效率MAP而是怎么在每一秒都变化的工况里把什么时候用谁、各自出多少力这件事定下来。最近我在整理自己的一套并联式混合动力控制策略核心是模糊逻辑能量管理已经内置了WLTC、NEDC两种标准工况也留了自行添加自定义工况的接口。这篇就把这套方案的思路、FIS设计细节、工况导入方法和仿真评估的坑完整讲一遍想用来做论文仿真、课程设计或者做预研快速验证的人都可以直接参考。先交代清楚这不是能直接装上车的量产代码而是一套偏研究与方案预研的Simulink控制策略框架。我把整车动力性简化为纵向动力学重点放在能量管理层。它解决的问题很明确给定一个目标车速曲线和动力电池SOC状态实时决定发动机与电机之间的功率分配。跟基于动态规划的全局优化算法相比它不需要预知未来工况跟固定门限的规则控制相比它对不同工况的适应能力更好调起来也更直观。1. 并联混动为什么要用模糊逻辑这条技术路线的真实边界1.1 并联结构的控制难点不在单体而在两条动力路径怎么分并联式混合动力车辆的发动机和驱动电机通过机械耦合装置共同驱动车轮跟串联式那种发动机只发电、车轮始终由电机驱动的架构完全不是一回事。并联的优点是机械路径效率高、电池容量可以不用做得很大但代价是控制自由度变多了。在一个确定的行驶时刻驾驶员需求功率可以拆成两条路径一条由发动机从燃油里转化另一条由电池放电给电机转化。这两条路径各自效率不同发动机的高效区不在低负荷也不在全负荷而是一块类似马鞍形的区域电机则在较宽的转速转矩范围内都有不错效率但电池馈电和发热带来的限制又让能用电机不等于应该用电机。所以这里面的核心矛盾就出现了系统是强非线性的效率MAP不是线性的电池SOC约束也不是线性的而且整段驾驶工况的统计特性一直在变。用低速低负载的思路标定一组规则放到WLTC的高速段跑可能就很浪费用高速场景标定放到市区频繁起步又会出现发动机启停振荡或者电量维持不住的窘境。1.2 为什么不是纯规则、不是全局优化而是模糊逻辑我最早也想过直接用基于规则的策略最典型的做法就是设定几个SOC阈值和功率阈值低功率纯电、高功率混动、SOC偏低就启动发动机。这种办法的好处是程序简单、跑起来很快坏处也很明显阈值边界上的工况会非常敏感比如需求功率恰好卡在15kW附近那么很小的车速变化都可能让系统在纯电和混动之间来回切换驾驶性很差。另外阈值表格一般只能按固定的车速、功率、SOC做分段查表遇到没有标定过的边界区域输出就是生硬的跳变。动态规划一类的全局优化方法我也试过效果确实好作为离线基准非常有价值。但Dynamic Programming的结果依赖整个工况曲线已知也就是说我必须先把WLTC或者NEDC全部塞给算法它才能从后往前反推出最优路径。工程里整车跑在路上不可能预知未来的路况所以这类方法天然只能做离线评估不能做实时控制。模糊逻辑正好落在两者之间。它不需要精确的系统模型对参数漂移有鲁棒性能够用SOC偏低且需求功率较大时发动机要承担主要功率这种语言化规则去描述决策思路不存在硬阈值的突变。加上模糊推理输出的隶属度天然带有平滑过渡实际给出的扭矩分配指令比查表法稳定不少。从工程复用角度看它还能在后期做HIL测试甚至生成C代码部署到VCU环境里继续调。我的经验是不要纠结模糊逻辑是不是最先进要看它能不能在你的工作流里快速落地。并联混动的能量管理本身是模式决策加连续功率分配的耦合问题模糊逻辑适合拿来做连续功率分配的上层决策而离散的模式切换还得靠有限状态机来收尾两个结合起来才完整。2. 策略骨架怎么搭需求功率、SOC、一条扭矩分配轴线2.1 模糊控制器在整个Simulink模型里的位置这一套策略的顶层仿真模型大致分成五块目标循环工况、驾驶员模型、整车纵向动力学模型、能量管理策略、动力部件模型。目标循环工况提供车速曲线驾驶员模型按目标车速与实际车速的偏差输出踏板开度整车纵向动力学模型根据驱动力和行驶阻力算出实际车速动力部件模型包含发动机、驱动电机、电池、传动系统能量管理策略负责决策前两者之间怎么出力。很多刚开始做混动仿真的朋友容易把模糊控制器当成一个独立大模块直接接在车上忽略了它上下游的信号流。实际上模糊逻辑控制器的输出必须作用到发动机扭矩指令和电机扭矩指令这两个执行量上而执行量又会反过来改变车速和SOC最后再影响到下一帧的模糊输入。搞清楚这个反馈环建出来的模型才不会莫名其妙出现代数环问题。我常用的是一个简化但逻辑完整的信号流驾驶员模型输出需求扭矩再由当前车轮回转半径、主减速比和挡位传动比把需求扭矩折算到发动机与电机耦合点处的总需求转矩。模糊控制器的输入是SOC和标准化后的需求功率输出是一个无量纲的发动机功率占比系数u。执行层拿到u之后再结合当前模式生成具体的发动机扭矩请求和电机扭矩请求。2.2 输出u为什么允许大于1小于1又代表什么在并联混动策略里很多现成论文把模糊控制器输出定义为发动机扭矩占比论域限制在0到1之间。这个设定有一个明显缺陷如果SOC偏低且需求功率很低理论最优做法不应是纯电行驶继续让电池放电而是启动发动机运行并让发动机在稍高于需求功率的工况点工作把多余功率用来给电池充电。这种一边驱动一边充电的状态用0到1的占比根本表达不出来。所以我这套策略里把模糊控制器输出的u定义为发动机请求功率与当前驾驶员需求功率的比值论域放宽到0到1.2左右u约等于1表示发动机独立满足驾驶员需求功率u小于1表示发动机承担了需求的一部分缺口由电机补充u大于1表示发动机不仅要满足需求还要多输出一部分功率给电池充电前提是发动机外特性有富余u非常小表示发动机基本不输出或直接进入纯电状态。这个表达式的好处用一个例子就能说清楚车辆正在低速巡航驾驶员需求功率只有5kW但SOC已经掉到0.35模糊规则给出u1.15那么发动机的目标功率大约就是5.75kW比驾驶员实际需要的多出0.75kW这部分功率通过发电机回充到电池里。等于让发动机从本来可能低效运行的5kW点稍微挪到效率更合适的小负荷充电区避免电池继续走向深度馈电。3. FIS设计从纸面走向Simulink隶属度函数、规则表、去模糊是个系统工程3.1 输入变量不是越多越好两输入一输出的方案为什么更实用模糊控制器的输入量选择直接决定规则数量的规模。假设每个输入划分3个模糊子集两个输入就是3乘3等于9条规则三个输入会变成27条四个输入更是直接到81条。规则数量一多就需要在Simulink里一条一条核对还要保证每条规则之间的语义不冲突这在实际操作中相当痛苦。我的方案里只保留了SOC和需求功率两个主要输入。SOC反映动力电池的可用电量需要保持在安全窗内需求功率反映驾驶员在当前时刻的功率请求是所有控制决策的源头。有些同学会问车速信息为什么不让模糊控制器看到车速其实已经通过需求功率间接体现出来了——驾驶员模型本身就在跟随目标车速输出踏板和制动的行为已经包含车速信息不把车速单独作为输入并不会让策略失效。这样一来规则表就非常简洁9条核心规则互相之间肉眼可查。如果后期你想引入车速修正比如低速城市工况强制偏纯电、高速工况偏发动机直驱也完全可以再加一个车速输入。但入门阶段强烈建议先用两输入方案把整条链路跑通再逐步扩展输入维度。3.2 隶属度函数的论域、形状与重叠度设置SOC的论域我设置为0.3到0.9留出0.9以上给再生制动回收避免电池满了以后没有能力吸收回馈能量0.3以下是深度馈电区应该尽量避免。SOC划分成三个模糊子集Low、Medium、High用梯形加三角形组合。Low子集中心在0.35附近High子集中心在0.8附近中间Medium作为过渡区域。论域两端为什么用梯形而不是三角形因为SOC很低或很高时控制行为要保持在同一个方向比如SOC一旦低于0.35不管是不是0.31还是0.29发动机都应该积极承担输出梯形能让这个区域的隶属度饱和为1输出更稳定。需求功率的论域需要根据目标车型的功率等级来标定。在我这套示例模型里发动机最大功率约80kW驱动电机峰值功率约90kW综合驱动需求功率脉冲最高一般不超过110kW所以需求功率的论域按-20kW到110kW设置。负值代表制动回馈段但负功率区域我并不会放进模糊规则里仔细推理而是在控制逻辑上做一个前置判断只要总需求功率小于0先进入再生制动模式按电机回馈扭矩限制回收不足的部分由液压制动补充这个状态直接绕开模糊控制器避免模糊规则在正负功率切换边界上产生不自然的扭矩跳变。两个输入的重叠度同样需要细心调。重叠太少隶属度函数跟硬阈值没有本质区别重叠太多规则之间互相拉扯输出光有平滑但响应迟钝。我一般把相邻模糊子集的峰值间距控制在论域宽度的30%到50%之间两个子集交叉处的隶属度大致落在0.4到0.6实际调下来控制曲面比较柔顺。3.3 可以直接上手改的一套核心规则表我采用的模糊规则表输出值表示u也就是发动机请求功率与需求功率的比值具体见表。SOC \ 需求功率需求功率低需求功率中需求功率高SOC低1.151.051.00SOC中0.400.751.00SOC高0.050.400.85读这张表需要理解背后的意图。SOC低且需求功率低时u等于1.15意思是发动机启动并多输出15%功率给电池充电SOC低且需求功率高时发动机已经需要全力输出u等于1.0电机主要起辅助削峰作用这已经是电量偏低状态下比较合理的选择不能指望在这个工况边给电池充电边满足大功率请求。SOC高且需求功率低时u只有0.05意味着系统选择几乎纯电行驶把SOC的高电量先用掉SOC中等到高需求时u是0.85发动机承担大头电机补上剩余的15%功率因为单独让发动机硬扛极限功率的效率反而会下降。设计完规则表一定要做一致性检查。比如SOC下降时相同需求功率对应的u只允许上升绝不下降需求功率增大时相同SOC对应的u也应该上升。用MATLAB的控制面查看工具画出u关于SOC和需求功率的三维曲面如果看到有波浪形的局部下降说明某条规则跟邻居规则打架了需要回头调整规则或者隶属度函数。3.4 Mamdani推理、重心去模糊以及Simulink里的配置我使用的推理方式是Mamdani型去模糊方法选重心法用一句大白话解释就是每条规则被激活的程度相当于给对应输出模糊集合加了一个权重最后把所有这些输出模糊集合的加权形状叠在一起求一个重心作为数值输出。重心法不会像最大隶属度法那样产生跳跃适合作为连续执行的扭矩控制输出。在MATLAB里创建这套FIS时大部分工作可以用命令行完成。下面是一个示例片段方便你快速搭出基础结构fis mamfis(Name,P2_HEV_FIS); fis addInput(fis,[0.3 0.9],Name,SOC); fis addMF(fis,SOC,trapmf,[0.25 0.3 0.4 0.5],Name,LOW); fis addMF(fis,SOC,trimf,[0.45 0.6 0.75],Name,MED); fis addMF(fis,SOC,trapmf,[0.7 0.8 0.9 0.95],Name,HIGH); fis addInput(fis,[0 110],Name,P_req); % 在这里继续添加功率需求的隶属度函数 % addOutput定义u论域[0 1.2] % 然后使用addRule逐条添加规则例如 % fis addRule(fis,[1 1 1 1 1]);一个容易踩的坑是在Simulink里如果使用旧版的Fuzzy Logic Controller模块它默认读取工作空间里的某个变量名如果你把FIS存成.fis文件也最好用readfis先读进来生成mamfis对象再赋给模块参数。新版Simulink对字符型和结构体类型的FIS配置已经不太友好直接传mamfis对象最稳妥。4. WLTC与NEDC之外的工况接口我踩过的导入数据坑4.1 两种标准工况的区别决定你是测效率还是测适应性这套策略默认带了WLTC和NEDC两个工况文件。NEDC整体由低匀速、短加减速组成市区段速度低、稳态多总时长大约1180秒平均速度不高。WLTC的瞬态成分更多高速段占比较高加减速过程远比NEDC剧烈总时长约1800秒。这两组工况的差别会直接影响你对控制策略的结论同一套模糊参数在NEDC下面通常更容易做出好看的油耗因为发动机大部分时间能稳定在效率点附近放在WLTC下面功率请求频繁摆动规则表和隶属度参数的小瑕疵会被放大。所以我建议评估策略时至少两个工况都跑一遍不要因为NEDC省时间就只跑NEDC。4.2 自定义工况的数据格式与导入流程我设计工况接口时最常见也最省事的格式就是两列数据第一列时间单位是秒第二列车速单位是米每秒或者千米每小时你自己在导入脚本里统一换算。在MATLAB工作区里主要采用timeseries对象因为Simulink的From Workspace模块对timeseries的插值处理最友好模型换成不同采样率的自定义工况时不用改信号线。下面是我每次添加新工况时的标准处理步骤数据准备把文本文件、Excel表格或者实测数据统一整理成t和v两个列向量检查质量去掉NaN将负速度强制为0处理掉重复时间点插值重采样统一插值到需要的时间间隔我习惯用1秒如果模型仿真步长很小也可以用0.1秒构造timeseries对象确认起始时间是0否则Simulink信号源会从0时刻补一段默认值干扰仿真结果如果数据里的速度单位是千米每小时那么需要除以3.6换算成米每秒这个单位翻车率非常高。t [0; raw_t(:)]; vRaw raw_v(:); vRaw(vRaw 0) 0; v [0; vRaw / 3.6]; cycleTS timeseries(v, t);4.3 自定义工况时最容易出现的三个异常现象先说现象一新工况跑出来的车速曲线和目标曲线明显对不上仿真后期偏差越拉越大。这个问题多半不是控制策略的锅而是工况导入时间轴起始点不是0或者数据里有毛刺驾驶员模型跟随偏差被积分放大。处理方式是统一用上面那段脚本清洗数据观测一下timeseries对象第一个点的时间是否等于0。现象二仿真速度突然变得很慢。有些自定义工况会用0.01秒步长记录大量数据样点数多到几十万条输到Simulink里每个仿真步都要执行插值自然拖慢速度。我的解决办法是先把原始数据线性插值到0.1到1秒再做轻度的中值滤波把波动过快的噪声滤掉疲劳测试阶段不需要保留高频细节。现象三WLTC和NEDC能跑通自建工况却出现卡在某个时刻不往前走的现象。这通常是因为数据中存在两个完全一样的时间点Simulink的信号源不知道该按哪一个去插值。在脚本里用unique函数处理时间戳能快速解决。多次遇到之后我把清洗脚本写成了公共函数后面再加任何新工况都直接调用一步到位。5. 评价策略不能只看油耗表电量平衡与初始SOC敏感性问题5.1 油耗、SOC平衡、驾驶性这三件事怎么一起看仿真跑完之后直接看仪表盘或者Scope输出的油耗曲线远远不够。SOC作为储能器的状态是会随着控制策略和使用工况变化的。如果一个策略在NEDC下算出百公里5升的油耗但跑完SOC从0.7掉到0.4那这个油耗数据没有任何工程意义实际上是把原本该由燃油提供的能量提前从电池里挤出来了。所以我评估策略时固定看三个指标燃油消耗率折算成百公里油耗SOC始末差值要求结束SOC与初始SOC偏差不大一般允许3%到5%以内发动机启停次数和扭矩请求的抖动量这个能反映驾驶性好坏。三者互相制约。模糊控制器把SOC作为输入之后天然有调节作用SOC高了它会偏向耗电SOC低了它会偏向充电因此SOC发散的几率比固定规则策略小。但如果你起始SOC设在1.0已经超出输入论域上限车辆在制动时电池无法吸收回馈能量再生制动被强制关闭控制效果就不理想。5.2 初始SOC扫描实验不跑一遍不知道边界条件多敏感我在验证这套模糊策略时做了一个简单实验在同一WLTC工况下把初始SOC分别设成0.4、0.6、0.8其他参数完全不变对比最终的SOC曲线和油耗。结果其实符合预期但过程很值得注意。初始SOC等于0.4那次模型在第一个低速段就出现了比较长的发动机充电过程u的数值频繁触碰1.1到1.2上限一段工况下来SOC恢复到0.42附近但瞬时油耗明显升高初始SOC等于0.8那次前半程电机参与比例高等到后半程高速段SOC慢慢落到0.72附近整体油耗反而更平顺。这说明比较策略优劣时所有算例的初始SOC必须保持一致否则结论会被初始状态带偏。如果你只想验证模糊控制器的鲁棒性那可以刻意做一组不同初始SOC的对比观察SOC最终能否收敛到目标窗内。模糊逻辑由于规则里有SOC低值强制充电、高值强制消耗的设计收敛性通常比查表固定阈值好但收敛速度和瞬时驾驶性不一定总能兼顾。5.3 模式切换处的扭矩毛刺和抑制方法输出u虽然因为模糊推理的平滑效果基本不跳变但如果我在能量管理层后又套了一个模式切换逻辑比如把挡位或者驾驶模式从纯电切到混动那么发动机扭矩请求仍然可能在一个仿真步内出现从0跳到几十牛米的情况。扭矩突变对仿真结果影响小但对后续要做硬件在环或者实车策略预研的人来说是大问题。我的处理手段是在扭矩指令后面串联一个Rate Limiter把最大扭矩上升速率限制在每秒某个数值内同时给模式切换条件加滞回窗口。电池电量和需求功率同时满足一定条件时才允许从纯电切到混动切完之后需要持续一段时间才能切回来避免在规则边界上来回振荡。6. 调试中最容易忽略的几处细节从Simulink到VCU迁移的提前量6.1 新版Simulink与旧版FIS文件不兼容的应对项目里同时存在旧版.fis文件的情况很常见因为网上很多资源包是从不同版本导出后流传的。新版MATLAB打开旧FIS可能出现读取失败或者隶属度参数丢失而Simulink里的Fuzzy Logic Controller模块报错信息又往往很笼统。最直接的办法是统一用命令行处理先用readfis把旧文件读成mamfis对象然后运行showrule查看规则表是否完整再用writeFIS重存一份。仿真之前先单独在MATLAB命令行里执行evalfis看输入输出是否符合预期确认FIS本身没毛病再去排查Simulink连接问题。这样分层排错能省下一大半时间。6.2 代数环和仿真步长对模糊控制结果的影响并联混动Simulink模型出现代数环是常事链条往往是这样的电机扭矩影响整车加速度车速积分又反过来改变驾驶员需求扭矩而模糊控制器又根据需求扭矩决定电机扭矩其中若有一个模块没有延迟就会出现无法直接求解的代数环。模型能跑也算出结果可一旦求解器抽风仿真出来的控制效果就不稳定。我的经验是在能量管理模块的输出反馈路径上放一个Memory或Unit Delay模块把当前控制周期内需求的扭矩保持一个步长再参与下一轮计算。这和人脑实际控制整车也有点相似控制指令本身就有周期延迟不是连续瞬间完成的。仿真步长的选择同样重要。如果整车模型里包含电池和电机的微分方程发动机是查表模型建议使用ode15s这类变步长刚性求解器。模糊逻辑控制器的采样时间可以相对放慢比如10毫秒到100毫秒一个周期原因是SOC和驾驶需求功率变化相对缓慢但功率电子和驱动电机的响应要求更高整车机械部分又另说。给模糊逻辑模块单独设置一个离散采样时间通常能让仿真稳定性和速度同时有改善。6.3 给后续VCU整車控制策略迁移留的伏笔有人问这套只做仿真验证的策略跟真正整车控制器里跑的VCU策略差多远。简单说数学内核是同一套但量产环境下的整车控制策略还要处理上电唤醒、故障诊断、扭矩仲裁、安全监控这些非功能逻辑。模糊逻辑能量管理负责的是怎么省油、怎么维持电量而VCU真正必须保证的是无论什么情况下都不能给出违背安全意图的扭矩指令。如果后续打算把模糊控制策略生成C代码迁移到控制器硬件上去那在设计Simulink模型时就要提前想清楚所有模糊模块都应该是离散的不能依赖连续时间求解器不要使用只能在仿真环境工作的奇异模块输入信号在进入模糊控制器之前要做防跳变和滤波最后用Embedded Coder生成代码前还要对定点数做仔细转换。我这套策略目前是一个预研验证级别的东西但模型结构尽量按可生成代码的规范去搭后面衔接会轻松不少。在仿真调试这条路上走得久了我越发觉得控制策略好不好用差的往往就是那些发布资源帖不会告诉你的细节SOC论域为什么从0.3开始而不是0.1u为什么允许大于1工况导入为什么要先做时间戳清洗以及初始SOC不同为什么会导致完全不同的油耗结论。把这些细节都补齐以后模糊逻辑的并联混动策略才真正算是一套能反复复现、能支持你继续往更深方向做的东西。后面如果时间允许我打算继续写这个系列把注意力放到规则库的自动优化和基于模型生成C代码这两块上去。