做光储充一体化充电站调度的朋友大概率都遇到过这种“按下葫芦浮起瓢”的时刻晚上电价低谷你高高兴兴把所有充电计划塞满结果第二天中午光伏大发变压器容量却被夜里充满电的车占得干干净净只能眼睁睁看着大太阳弃光更难受的是天气说变就变十分钟内光伏出力掉三成储能还按着昨天的计划慢吞吞地放电等你重新算完优化实时功率曲线已经不知道飞到哪里去了。这种场景拆开看其实是一组时间尺度完全不同的对象强行放在一起光伏出力跟着天气分钟级波动电动汽车插枪拔枪完全是随机事件储能既能秒级响应也能小时级平移而电网给你的功率申报窗口却基本按天和按小时计。把它们塞进同一个优化模型要么复杂到解不动要么简化到没人敢用。基于多时间尺度的电动汽车光伏充电站联合分层优化调度正是奔着这个矛盾去的。用Matlab把这套调度策略仿真出来是电力方向研究生、工程师切入这个方向最顺手的一步——模型不复杂到劝退又能完整覆盖“预测—优化—控制”全链路。下面我按自己做项目时的实际思路把这套东西从题面到代码完整拆开讲。1. 题目拆解多时间尺度、分层与“联合”背后是三个现实问题1.1 为什么说“多时间尺度”不是学术造词在充电站调度里时间尺度是一个非常物理的词。电网侧的购电计划、需量申报通常按小时甚至更粗的粒度确定光伏出力的预测误差在分钟级就会累积到不可忽视的程度EV充电行为更是随机到以秒为单位的插拔事件。不同设备、不同交互边界有各自的天然响应周期如果只用一种时间分辨率去描述必然会陷入两难用细分辨率建模决策变量爆炸混合整数问题直接算到天荒地老用粗分辨率建模光伏闪变和充电桩的瞬态变化又完全看不见。多时间尺度调度的思路本质上就是按决策紧迫性把问题拆成几个层级每层用自己的时间步长去处理自己该管的事。这个思想在电力系统里并不新鲜——传统调度就有年/月/日/实时分层但放到光储充充电站这个有随机性、有电力电子设备、有用户行为的小场景里它才有了新的施展空间。这里“多时间尺度”不是把不同粒度的数据硬拼在一起而是让每个调度层只负责与自己时间窗口匹配的决策变量各司其职后再通过指令串起来。1.2 “分层”解决的其实是规模与控制边界问题假设一个典型充电站20台快充桩、800kWp光伏、1MWh储能。如果要在每个5分钟决策点同时优化每台桩的功率、每组电池簇的充放电、总购电曲线变量规模会非常难看——现代求解器也许能硬解但工程上完全没有必要。因为EV用户关心的是“走的时候电够不够”站端关心的是“总功率不超配变”储能关心的是“SOC别越界”这些目标的嵌套结构天然适合分层。上层不需要知道每辆车具体在哪个桩位上充电它只需要知道这个站的聚合充电负荷带在哪里下层也不需要对明天的电价做判断它只需要执行上层给的功率参考并把实际功率分配到位。分层不是简单地把大模型拆小而是按控制边界把问题切对上层管经济和趋势下层管物理和执行。这也是我认为“分层优化”在工程上最核心的价值——不是数学上非要用双层而是现实系统的决策结构本来就长这样。1.3 题目里“联合”两个字的分量单独做储能调度的代码网上多如牛毛单独做EV有序充电的代码也不少但把光伏、储能、EV充电、电网交互功率放到一个框架里同时优化才叫联合。为什么必须联合因为约束条件是互相耦合的变压器容量就那么大光伏发得多储能就需要少充电或者多放电EV集中充电时储能就必须提前预留裕量电网不允许余电上网时光伏再多也只能看着弃。分开优化会得到各自最优但全局不可行的结果联合优化要的是在可行域里找全局较优。用Matlab做联合优化的一个直观好处是这种耦合关系可以用矩阵和线性约束非常直白地写出来调试的时候每个约束对应一个数组运算出问题很快能定位。比起某些通用编程语言从零写优化器MatlabYALMIP的路线让建模者把精力集中在物理问题和策略设计上而不是陷在求解器底层里。1.4 一个贯穿全文的算例场景为了让后面的模型和代码有落点我定一个典型场景某园区光储充一体化充电站光伏装机800kWp储能1MWh/500kW20台直流快充桩、单桩最大60kW变压器核定容量1000kVA。分时电价设定为峰1.2元/kWh10:00—15:00、18:00—21:00、平0.8元/kWh7:00—10:00、15:00—18:00、21:00—23:00、谷0.4元/kWh23:00—次日7:00。地方政策不允许光伏余电上网只允许站内自发自用。这个场景下弃光几乎必然发生储能和EV时序的配合就成了唯一增收手段——正好能完整体现多时间尺度调度的价值。如果允许余电上网模型里还要加一个售电决策变量和购售互斥约束逻辑会更复杂一点但核心框架不变。下面整个模型都围绕这个场景展开。2. 调度框架设计日前、日内、实时三级如何接力运行2.1 日前调度先给全天画一张“可行地图”日前调度的周期是未来24小时时间分辨率通常取1小时。它不负责应对突发只负责在预测光伏出力、EV充电需求和电价已知的前提下计算出全天各时段的购电功率、储能充放电功率和EV聚合充电功率的基准计划。这个计划的作用有几个一是给电网侧提供功率申报依据二是把储能SOC的运行区间提前画好三是确定EV充电的“可平移窗口”避免午间光伏大发时变压器却被夜间充满电的车占满。为什么日前层用1h而不是30min或15min这是工程经验和计算代价的权衡。对电网功率申报来说1h粒度已经足够求解24时段MILP通常几秒到几十秒就能完成。如果按15min把变量扩到96时段问题规模变成原来的4倍边际收益却不大——毕竟次日光伏预测的误差可能在20%以上把1h粒度做得再精细只是在优化一个可能跑偏的预测。所以日前层核心是建立“骨架”定下储能是否充电、是否放电、EV整体充电功率带而不是每台桩的精确功率。2.2 日内滚动修正用MPC思路吸收预测误差日内层我更喜欢把它理解成“戴着镣铐跳舞”。它的周期不是固定的一条24h曲线而是一个滚动窗口。典型配置是窗口长度4小时、步长15分钟每到一个新时刻就用最近刷新过的超短期预测重新求解一个有限时域优化问题只执行当前时刻那一列的最优指令然后窗口向后滚动。这正是模型预测控制MPC的核心思想。为什么窗口取4小时而不是整个24小时因为MPC本身是边滚动边修正的后面时段的结果本来就会被丢弃重算窗口太大会引入不必要的计算量窗口太小又看不到储能在未来几个小时内的合理排布。4小时是一个很接近储能在峰谷套利中“半个循环”时间的折中长度实际调参时可以按你的储能容量和电价曲线适当拉长或缩短。日内层最重要的职责是吸收日前预测误差——比如实际光伏出力比预测低了一截MPC会在下一轮滚动里自动多安排一点购电或者减少储能放电而不会傻等当天晚上再纠正。2.3 实时控制层处理分钟级波动的最后防线到了实时层问题就不再是“下周怎么买电”这种规划问题而是“下一分钟总功率逼近变压器上限了该怎么办”。实时控制层在几秒到几分钟的时间尺度上处理光伏的短时波动和EV接入时的功率突变通常由储能PCS的恒功率/下垂控制、充电桩的可中断机制共同完成。这层不一定非要再用优化求解器——很多现场实现就是一套规则表加PID/下垂控制检测到总功率越限先削充电桩功率再增加储能放电优先级由站内制度决定。在Matlab仿真里我一般把实时层简化为一个功率跟踪校正模块读入日内层下发的功率参考值模拟系统实际运行时SOC更新、充电桩分配、越限判断把“理论指令”和“物理可实现指令”之间的偏差记录下来。这个偏差就是评价预测和建模精度的重要依据。2.4 三层之间的指令流与反馈流三层不是一个单向流水线而是有闭环反馈的。指令流方向是用户充电需求与气象数据进入预测模块预测结果交给日前优化日前计划传给日内MPCMPC修正后的参考值再发给实时控制实时控制最终作用到PCS、充电桩和光伏逆变器。反馈流方向相反设备实测功率和SOC状态返回给日内MPC做下一轮滚动的初始状态当天实际运行数据又用来修正第二天的预测模型参数。每一层都在自己的时间尺度上做滚动或周期更新这是多时间尺度框架能真正落地的关键。我不建议做成一锤子买卖——只算一次日前计划就结束的“伪多时间尺度”在工程上意义很小。下面这张表可以比较直观地概括三层分工层级周期时间步长主要手段核心任务日前调度24小时1小时MILP全局优化制定购电曲线、储能SOC基线、EV充电窗口日内MPC4小时滚动15分钟有限时域MILP修正预测偏差、更新功率参考值实时控制连续运行秒~分钟规则/PID/下垂平抑波动、功率限值保护、功率分配3. 数学模型搭建目标函数、约束条件与上下层耦合逻辑3.1 上层模型以运行成本最小化为主线数学建模是这套代码的灵魂但没必要一上来就追求复杂。我习惯先写一个“最小可用版本”跑通后再逐步加细节。上层日前调度的目标函数可以写成这样min Σ_{t1}^{24} [ c_buy(t)·P_grid(t) − c_sell(t)·P_sell(t) λ_pv·P_pv_curtail(t) λ_sto·(P_ch(t) P_dis(t)) ]四项依次是购电成本、售电收益如果允许余电上网则有这一项、弃光惩罚、储能充放电等效损耗成本。弃光惩罚的作用是让模型“尽量把光伏用掉”但数值别设得离谱——如果比你最高购电价还高几倍模型就会为了不弃光而做出一堆反常识的调度。储能损耗项我一般折算成每充放1kWh约0.01~0.03元的小系数目的是防止储能被频繁浅充浅放延长电池寿命。它在数学上不是必须的但加了这个项后仿真出来的储能动作曲线会明显更干净也更贴近真实运行。3.2 上层约束每个式子都要对应到现场设备约束条件按设备类型划分基本就是下面这张清单功率平衡约束P_grid(t) P_pv_used(t) P_dis(t) P_load_base(t) P_ev(t) P_ch(t)。物理含义是站内每个时刻发用电必须相等。储能SOC递推SOC(t1) SOC(t) (η_ch·P_ch(t) − P_dis(t)/η_dis)·Δt / E_cap。充放电效率分开写不能用同一个η不然误差会悄悄累积。储能SOC上下限、充放电功率上下限、充放电互斥SOC_min ≤ SOC ≤ SOC_max0 ≤ P_ch ≤ P_sto_max·u_ch0 ≤ P_dis ≤ P_sto_max·u_disu_ch u_dis ≤ 1。互斥约束很重要不然求解器可能让储能一边充一边放——虽然物理上不禁止但运行上毫无意义且徒增损耗。光伏出力上限P_pv_used(t) P_pv_curtail(t) P_pv_forecast(t)。这个等式告诉模型光伏预测出力要么被消纳要么被弃掉。变压器容量与购电上限0 ≤ P_grid(t) ≤ P_limit。EV充电需求约束Σ_{t} P_ev(t)·Δt ≥ E_ev_total。这是把充电需求当成一个“日累计需要量”来处理具体哪个时段充由优化决定。注意这个约束是大于等于而不是等于给调度留一点灵活空间。我在功率平衡式子里故意没把弃光项写进去因为弃光本身不是一种“功率去处”而是一种“没被使用的能量”。实际建模时有两种习惯要么在平衡式左侧减掉弃光功率要么把它放在光伏出力约束里做差值。我推荐后一种写法逻辑更清晰排查问题也方便。3.3 下层模型功率分配到具体设备下层模型的决策变量是每台EV充电桩的实际功率、每台PCS的启停状态。它的目标通常是三部分的加权跟踪上层下发的聚合功率指令偏差尽可能小、保证充电公平性避免个别车等太久、满足每辆EV的离网SOC需求。下层问题通常不需要MILP用二次规划甚至简单规则就能完成。我在工程里常用的分配规则有三种依据现场情况选先到先得型按接入时间排序优先满足先来的车最大功率型适合快充需求紧急的客户直接怼满功率等比例分配型适合尽量让所有车同时离开适合商场类充电站。如果做学术仿真我建议用二次规划做功率分配因为它的目标函数里天然能写“公平性”的表达——比如最小化所有EV充电完成时间的方差。3.4 上下层如何“迭代咬合”上下层并不是离线各算各的它们的耦合关系在于“可行域”的传递。上层给出的是站级聚合功率指令这个指令对下层来说未必可执行——比如上层要求这个时段充电站总功率500kW但实际在桩的车辆总需求只有300kW硬件再优秀也执行不了500kW。所以实际流程是上层下发计划→下层做可行性校验→如果不可行把可执行范围反馈给上层并调整对应时段的约束→重新求解→再下发一般迭代两到三轮就能收敛。更严格的数学框架可以使用KKT条件把下层优化转化成上层约束形成数学规划均衡约束(MPEC)但这属于进阶玩法可读性和求解稳定性都差一些。工程实现里主从迭代、MPC滚动、鲁棒优化几种套路是最常见的选择。做项目时如果时间紧我建议先用主从迭代把仿真转起来后面再考虑数学上的严谨性。3.5 建模时最容易翻车的三个坑第一个坑是购电和售电同时为正。目标函数里如果没有相互排斥约束优化器可能在一个时段又买又卖账面不好看还白交过网费。解法是加一个0/1互斥变量或者干脆在模型里禁止售电。第二个坑是储能损耗项和SOC边界相互作用导致冷启动解不出来。我遇到过好几次设置SOC_min0.3、SOC_max0.9但损耗系数又很大时模型直接报不可行——本质上是因为约束太紧且目标函数鼓励储能“少动”可行域被挤成了一个点。解决办法是先把损耗系数设成0验证边界一致性再加损耗项。第三个坑是EV充电需求约束写反写成“每时段必须达到某个值”会让充电策略完全失去灵活性正确写法是“总充电量满足用户需求”把时间上的选择权交给优化器。4. Matlab代码实现工具箱选型、建模与求解完整流程4.1 环境配置YALMIP 求解器是主流组合如果你的Matlab版本是2020b以后官方optimproblem加intlinprog也能完成基本任务。但我个人更推荐YALMIP加CPLEX或Gurobi的组合理由很简单建模可读性和维护性。官方工具箱写混合整数问题不是不行但YALMIP可以用sdpvar直接声明变量约束和目标函数的写法几乎和数学公式一一对应后期换求解器只需要改一行代码。安装上YALMIP本质上是几个m文件加进Matlab路径就行CPLEX或Gurobi在学校或公司环境里一般都有学术许可实在没有的话先用intlinprog把流程跑通再切求解器这个路线最稳。有一点需要提醒YALMIP对Matlab版本兼容性整体很好但老版本偶尔在“二进制变量乘连续变量”这种需要自动引入辅助变量的情况下会有警告尽量用比较新的YALMIP版本能少很多莫名奇妙的问题。4.2 代码文件结构别把所有东西写进一个脚本我见过太多人把整个调度代码写成一个几百行的.m脚本参数、预测、建模、画图全堆在一起改一个参数跑一次全流程非常浪费时间。建议至少分成下面几个文件00_param.m % 参数定义与场景配置 01_load_forecast.m % 生成或加载光伏与EV负荷预测数据 02_day_ahead.m % 日前调度求解 03_intraday_mpc.m % 日内滚动优化 04_real_time_ctrl.m % 实时控制规则 05_plot_results.m % 结果绘图与指标统计参数文件单独放的好处是你做灵敏度分析时只需要改一个文件不用在代码里来回翻。预测模块独立出来因为后面换预测算法时不需要动优化代码。日志和结果保存建议在每层求解后写一行disp把目标值、求解器状态、求解时间记录下来排查问题的时候这些信息价值极大。4.3 日前调度建模代码示例下面这段YALMIP代码是我实际调试过的最小可行版本可以直接照着搭%% 参数 T 24; P_pv pv_forecast(1:T); % 光伏预测kW P_ev ev_forecast(1:T); % EV聚合充电功率预测kW P_grid_max 1000; % 变压器上限kW E_sto 1000; % 储能容量kWh P_sto_max 500; % 储能功率上限kW SOC_min 0.1; SOC_max 0.9; SOC_init 0.5; SOC_end 0.5; eta_ch 0.95; eta_dis 0.95; %% 决策变量 P_grid sdpvar(1, T); P_ch sdpvar(1, T); P_dis sdpvar(1, T); SOC sdpvar(1, T1); u_ch binvar(1, T); u_dis binvar(1, T); P_cut sdpvar(1, T); %% 约束 C []; C [C, P_grid 0, P_grid P_grid_max]; C [C, P_cut 0, P_pv - P_cut 0]; % 弃光非负实际光伏出力介于0和预测值之间 C [C, 0 P_ch P_sto_max*u_ch]; C [C, 0 P_dis P_sto_max*u_dis]; C [C, u_ch u_dis 1]; % 充放电互斥 C [C, SOC(1) SOC_init, SOC(T1) SOC_end]; C [C, SOC_min SOC SOC_max]; C [C, SOC(2:end) SOC(1:end-1) (eta_ch*P_ch - P_dis/eta_dis)*1/E_sto]; C [C, P_grid (P_pv - P_cut) P_dis P_ev P_ch]; % 功率平衡 %% 目标 cost_buy c_buy * P_grid; % c_buy是1x24的分时电价行向量 cost_sto 0.02 * sum(P_ch P_dis); % 储能损耗折算 cost_cut 0.8 * sum(P_cut); % 弃光惩罚 Obj cost_buy cost_sto cost_cut; %% 求解 optimize(C, Obj, sdpsettings(solver, cplex, verbose, 1)); P_grid_opt value(P_grid); P_ch_opt value(P_ch); P_dis_opt value(P_dis); SOC_opt value(SOC);几个细节说明SOC初始值和终点值都设成0.5这是充电站常见的“日循环约束”保证储能每天的起始状态一致不会在长时间仿真里出现SOC漂移。充放电互斥用u_ch u_dis 1而不是1允许储能待在“闲置”状态。功率平衡式子里没有单独加基础负荷项——我在这套算例里把园区基础负荷归并进了P_ev里实际用的时候把两部分分开更规范也更好解释曲线。4.4 日内MPC的代码结构日内MPC写成一个循环每次滚动只执行第一步这是MPC的基本特征。核心结构如下SOC_cur 0.5; for k 1 : 96 t_now k * 15 / 60; % 当前时刻单位小时 horizon 4; % 4小时预测窗口 % 取窗口内的超短期预测 [P_pv_w, P_ev_w] short_term_forecast(t_now, horizon); % 基于当前SOC和日前参考求窗口最优 [P_grid_w, P_ch_w, P_dis_w] mpc_opt(SOC_cur, P_pv_w, P_ev_w, ref_day_ahead); % 只执行窗口内第一个时段的指令 apply_to_device(P_grid_w(1), P_ch_w(1), P_dis_w(1)); % 更新储能SOC SOC_cur SOC_cur (eta_ch*P_ch_w(1) - P_dis_w(1)/eta_dis) * 0.25 / E_sto; end实现时不要把这个循环写在脚本里而是封装成一个函数输入是当前SOC、预测序列、日前参考值输出是当前时段指令。这样一旦你想换预测算法或者调整MPC窗口长度都不需要大改。mpc_opt内部和日前模型的区别在于目标函数里多了一项对日前计划的偏差惩罚比如λ_ref·|P_grid − P_grid_day_ahead|防止日内修正输出跳变太大——对硬约束设备来说频繁跳变比少量偏差更伤。因为MPC窗口短求解速度极快完全可以在仿真循环里反复调用。4.5 求解器调用与结果落盘如果使用CPLEX或GurobiYALMIP在optimize时会自动调用。建议用sdpsettings设置solver、相对gap比如1e-3、最大求解时间防止极端工况下求解器卡死。结果保存我建议统一存成一个结构体包含时间戳、各时段功率计划、SOC曲线、求解器状态再另存一份xlsx给非Matlab环境下的同事看。排查问题时时间戳字段能帮你快速定位是哪个仿真时刻的数据出了问题。5. 预测模块与场景数据处理决定优化上限的前置环节5.1 光伏出力预测精度到20%以内够用不必过度迷信深度学习优化调度算法的性能上限由预测精度决定——即使调度模型再漂亮光伏预测偏了30%实际运行也会一塌糊涂。但我不建议在这个环节过度设计。对日前调度来说数值天气预报加历史数据修正基本够用BP神经网络或LSTM这类模型可以用来做超短期预测但作为调度仿真输入预测误差在20%以内就完全能支撑多时间尺度调度策略的验证了。如果非要在Matlab里接一个神经网络预测模块流程其实是标准化的用mapminmax对光伏历史功率和气象特征做归一化划分训练集和测试集用Deep Learning Toolbox训练再反归一化得到预测功率曲线。但有个原则要守住训练集和测试集按时间顺序划分绝对不能打乱随机划分否则会引入“未来信息泄漏”让测试集指标好看到造假。我在实际项目里见过不少这种“成绩优异但现场一塌糊涂”的预测模型问题几乎都出在数据划分上。5.2 EV充电负荷用蒙特卡洛模拟代替拍脑袋EV负荷预测是整个模型里最不确定的一环。车主几点来、剩多少电、充多久走全是随机变量。业界常用蒙特卡洛模拟给每辆车抽取到达时间高峰期集中在早晚、起始SOC一般服从正态分布、目标SOC用户通常要求充到80%以上然后模拟充电过程聚合出站级充电功率曲线。如果你连历史数据都没有也可以用排队论做一个简单版本的抽样——这个阶段的目标是得到一条“看起来合理”的EV负荷曲线用于验证调度逻辑而不是做精准预测。等有真实运营数据后再用数据驱动的方法重新标定分布参数。这套“先用模型生成场景、再用场景驱动优化”的做法是充电站调度仿真的标准玩法。5.3 场景生成与缩减别让MILP被场景数量拖垮做多日仿真时不可能把每一天的光伏和EV数据都直接塞进MILP里算否则算力顶不住。更专业的做法是场景生成与缩减先用历史数据生成大量候选场景再用K-means聚类提取典型光伏日和典型EV负荷日每个典型场景附带一个概率权重优化时对这些代表性场景做期望值优化或者鲁棒优化。K-means聚类在Matlab里非常成熟一个kmeans函数就能搞定。缩减后的场景数量通常取3~5个既能覆盖晴、多云、阴雨等典型天气又不会让求解时间爆炸。这种“以场景代表现实”的做法其实是很多论文里所谓“多场景随机优化”的工程简化版用的工具依然是最基础的Matlab聚类函数。5.4 必须警惕的数据泄漏问题数据泄漏是仿真结果虚高的头号原因。具体表现很多归一化时用了全局最大值而测试集里出现了更大的值预测模型训练时混入了未来时段数据用当日实测光伏数据代替预测数据给调度模型使用。这些操作都会让仿真里的调度“开了天眼”结果自然好看到离谱但一到现场立刻现原形。一个朴素的检验方法把调度模型里的输入全部替换成“历史某一天的预测数据”看优化出的决策曲线是否还合理。如果出现完全依赖未来信息才能解释的决策比如提前几小时精准预知了光伏突变那基本可以断定数据泄漏了。仿真项目的价值恰恰在于它能在可控环境里给你一个“贴近现实但略偏乐观”的预期数据泄漏会让这个预期彻底失真。6. 仿真评价指标与图表可视化如何证明策略有效6.1 四个评价指标调度策略好不好不能只看一个成本数字。我常用的四个指标是日运行成本、光伏消纳率、最大需量/变压器负载率、储能日均等效循环次数。整理成表格更清楚指标名称定义说明日运行成本Σ购电成本 − Σ售电收益 惩罚项最核心的经济指标反映策略的增收节支能力光伏消纳率实际消纳光伏 / 理论光伏出力越高越好弃光严重时要重点检查调度策略是否给了光伏足够优先级最大需量/负载率max(P_grid) / P_limit评价对配电网的影响过高的峰值可能触发需量电费储能日均等效循环次数日累计充放电量 / (2·E_sto)辅助评价电池寿命消耗太高说明策略在频繁折腾电池这四个指标从经济、可再生能源利用、电网友好性、设备寿命四个维度刻画了调度方案的表现。如果你做的是学术项目这四个指标加上对比实验就足够撑起主要结论了。6.2 结果图怎么画才能说明问题画图不是走过场好的图能一眼看出调度策略的行为逻辑。功率平衡图的推荐做法是用area函数画堆叠面积图横轴是时间纵轴是功率光伏出力、储能放电、购电功率分别作为一个色块下面再叠EV充电负荷和储能充电。这样一看就知道每个时段能量从哪来到哪去还能明显看出午间光伏大发时段EV充电是否被集中安排在这个窗口。SOC曲线用stairs或plot画配合电价曲线放在同一张图的次坐标轴上能直观看出储能是不是在低价充电、高价放电。成本对比柱状图则适合把“无序充电”“仅日前调度”“日前日内MPC”“完整多时间尺度分层”四种方案放在一起比较横轴方案、纵轴成本一眼看出策略效果。画图脚本建议统一在05_plot_results.m里管理方便重复实验后批量出图。6.3 对比实验设计控制变量才能得出正确结论做对比实验时最容易犯的错误是各组实验的输入条件不一致。比如无序充电方案用的是实际光伏数据而优化方案用的是预测光伏数据那成本差异就说不清是策略带来的还是预测误差带来的。正确做法是所有对比方案共用同一套预测输入和同一套EV充电需求曲线保证唯一变量是“调度策略”。这样得到的成本差、消纳率差才是策略本身的贡献。我在项目里对比时会把基准方案、单时间尺度方案、多时间尺度分层方案分别运行然后输出同一组指标放在一张表里做比较。7. 实战踩坑记录从模型发散到求解器报错的完整修复过程7.1 报错Infeasible先怀疑约束再怀疑数据MILP报Infeasible是所有做调度优化的人都会遇到的坎。我第一次搭这套模型时连续调了一晚上都报不可行后来发现是SOC递推约束里的效率写反了——充电用了η_ch没问题但放电我写成了乘η_dis而不是除η_dis导致储能出力越大SOC反而越高约束直接自相矛盾。排查这类问题有一个固定套路先把所有二进制变量固定成一组可行值检查连续约束是否可解再单独检查功率平衡约束是否恒有解最后再看SOC边界和充放电互斥的组合是否太紧。每一步用YALMIP的check函数查看残差很快就知道是哪个约束在捣乱。7.2 二进制变量与连续变量相乘模型的“隐形非线性”这是新手最容易踩的模型错误也是我在Review别人代码时最常看到的问题。比如有人想表达“储能只能中午光伏大发时段放电”直接写P_dis u_sto * P_pv造成二进制变量与连续变量相乘MILP瞬间变成MIQP甚至MINLP。如果非线性规模小还能硬解但一旦变量多起来求解时间完全不可控。正确做法是用大M法线性化。以P_x u_sto * P_pv为例引入辅助变量P_x加四条约束P_x P_pv M*(1−u_sto) P_x P_pv − M*(1−u_sto) P_x M*u_sto P_x 0M取一个比P_pv物理上限略大的数就行不要为了保险取个天文数字不然数值病态会让求解器陷入莫名其妙的误差。记住这个套路90%的二进制变量连续变量相乘问题都能解决。7.3 求解太慢时怎么优化如果你发现24小时MILP求解超过几分钟第一件事不是怀疑电脑性能而是检查模型里整数变量的数量。一个常见的无效设计是把所有时段都引入储能“充电/放电/闲置”三状态二进制变量其实大部分时段开关状态完全可以用连续约束表达只有电价转折点附近才需要整数变量来精准切状态。减少整数变量数量是提速最有效的手段。其次可以给求解器设置一个相对容忍度gap比如1e-3或5e-4。对绝大多数应用场景MILP的最优值和一个gap1e-3的次优解在经济上没有可感知的区别但求解时间可能相差一个数量级。另外YALMIP支持把上一轮求解的整数解作为热启动初值传给下一轮这在日内MPC滚动仿真里特别有用因为相邻两个窗口的优化问题高度相似热启动可以省掉大量分支定界的搜索时间。具体设置是sdpsettings(usex0,1)配合assign函数赋初值。7.4 用户行为不确定性仿真里最容易失真的一环蒙特卡洛生成的EV负荷曲线再精美也只是“期望情况”。实际运行中车主提前拔枪、到了没车位、插枪不充电等行为随时发生会让日前预测的EV功率曲线彻底失真。应对办法分两个层面软件上日内MPC每一轮滚动都要读取当前实际在桩车辆数和SOC状态相当于闭环反馈校正用户行为偏差会被逐步吸收策略上日前模型给EV充电需求加一个上下浮动裕量比如预测需求是1000kWh约束写成950~1050kWh牺牲一点经济性换来对事件扰动的鲁棒性。这两招同时用仿真结果与现场执行的差距会小很多。7.5 关于Matlab环境与工程习惯的几条经验YALMIP安装后如果报“无法找到求解器”八成是路径没加对或者求解器license没配置好Matlab 2023b之后的YALMIP兼容性总体很好但老版本偶发警告建议直接升级。写代码时给每个运行步骤打印一条带时间戳的日志虽然是小事但排查问题省下的时间远超敲代码的时间。还有一条很实用仿真结果里的每一张图都加上case名称和参数版本号方便一周之后回来看图时搞清楚这到底是哪个方案的输出。别问我为什么强调这个——我在项目里吃过太多“这图是谁跑出来的”的亏。我个人做这类项目的体会是第一版永远选择单日、1小时分辨率、纯储能加光伏的最小模型跑通验证了约束和目标函数没问题再逐步加入EV负荷、MPC滚动和实时控制。这个递进顺序能让你快速区分“代码bug”和“模型设计问题”不至于调试一周连问题出在哪都不知道。这个项目跑通之后往实时电价响应、电池健康状态模型、多站协同这几个方向扩展都会顺理成章核心的三层框架不需要推翻重来。