共享储能电站日前优化调度及工业用户应用的Matlab+Yalmip实现

干过储能调度的人基本都有同感储能电站建起来不难难的是让这座电站真正“跑起来”还把经济账算清楚。尤其是当储能不是给某一个用户专用而是同时服务于多个工业用户的时候问题就从“什么时候充、什么时候放”升级成了更麻烦的一层怎么在多个用户之间分配容量才公平怎么调度才能整体成本最低。我之前用Matlab把一套“共享储能电站日前优化调度及工业用户应用”的程序完整落过地从数学建模、Yalmip建模、求解器联调到结果分析都过了一遍今天把设计和踩坑过程拆开聊聊。这套程序的核心是把第二天的负荷预测、分时电价、光伏预测等数据作为输入基于储能动态模型和并网约束求解出未来24小时或96个时段内每个工业用户从共享储能获得的最佳充放电计划。本质上它是一个典型的优化问题用Matlab配合Yalmip工具箱可以很清晰地把目标函数和约束条件表达出来再交给商业求解器比如Cplex、Gurobi去算。适合正在做储能经济调度、综合能源系统优化、光储充项目评估的在校学生和工程师参考。1. 共享储能模式与日前调度问题定位1.1 共享储能解决了谁的痛点传统模式里一个工厂要配储能要么自建要么合同能源管理。自建的问题很真诚——贵。一个中等规模的工商业储能项目按2小时配置每千瓦时投资成本大约在1000到1500元左右几万千瓦时的项目一次性投入就是几千万很多制造企业根本拿不出这笔钱或者说投资回收周期长到不敢掏钱。共享储能就是把“自建”改成“租用”储能电站由运营方集中建设多个工业用户按需购买容量或者按充放电量付费相当于把储能的固定投资变成了可变成本。这个模式对工业用户的好处很明显初始投资为0不需要承担电池衰减和设备折旧风险用电大户按需租用容量用多少付多少账目灵活如果接入的多个用户负荷特性不同还能利用“错峰”效应提高电池利用率对运营方来说也有利可图同一个电池可以服务多个用户使用率上去了成本自然摊薄。但问题也随之而来——容量怎么分充放电功率怎么调度总不能一个用户想充就给充得有一个全局的“指挥中心”来制定充放电计划这个“指挥中心”就是日前优化调度模型要做的事。1.2 日前调度为什么是“日前”“日前”这个词刚接触的人可能会懵。它是指以未来24小时为调度窗口在当天之前制定好第二天的运行计划。工业现场的调度往往需要提前安排生产储能充放电计划也一样——需要提前知道明天每个时段电价多少每个用户的负荷大概多少光伏能发多少然后在这个基础上做优化。获取方式主要有三种数据类型来源典型时间粒度分时电价电网公布的价格表1小时或更细用户负荷预测历史负荷预测算法15分钟/1小时光伏出力预测气象数据光伏模型1小时为什么不在当天实时调度因为求解需要时间。如果考虑用户侧负荷的不确定性最合理的做法是“提前一天算好计划当天根据实际情况微调”。这也是日前优化调度在实际工程中最常见的使用方式第一天晚上基于预测数据求解出全天的储能充放电计划第二天执行并配合实时的偏差修正。这种“预测-优化-执行”的框架把复杂的实时控制转化成了一个可求解的数学优化问题是储能经济调度的主流做法。2. 数学建模把调度问题变成可计算的表达式2.1 目标函数成本最小化还是收益最大化建模的第一步是确定优化目标。共享储能场景里有多个参与者储能运营商、多个工业用户、电网。如果追求全局最优通常选择“系统总运行成本最小化”如果突出运营商的利益可能会选择“运营商收益最大化”。我程序里选择的是系统总运行成本最小化把储能运营成本和用户购电成本合在一起。这样做的好处是模型相对简单也方便后续做费用分摊。目标函数大致长这样min F Σ_{t1}^{T} [ price_buy(t) * P_grid(t) ] * Δt Σ_{t1}^{T} c_om * (Pc(t) Pd(t)) * Δt Σ c_service * P_discharge_user(t) * Δt其中price_buy(t) 是 t 时段从电网购电的分时电价P_grid(t) 是所有用户从电网购电的总功率Pc(t)和Pd(t)是储能电站的总充放电功率c_om 是单位充放电量的运维成本c_service 是用户使用储能放电服务的服务费率或者说租赁单价P_grid(t) 是所有工业用户各自电网购电功率之和这部分是购电成本储能充放电过程有损耗运维成本体现了“电池衰减”的经济损耗服务费这一项是运营商的收入从系统总成本角度看是内部转移支付加入它主要是为了后续便于进行用户侧费用结算。目标函数里每一项都有明确的实际含义不是什么花架子。理解这一层会对于后面的程序调试很有帮助——有时候求解出来的结果不好看很可能是目标函数里某项的权重和量纲出现了问题。2.2 储能与用户侧关键约束光有目标函数不行没有约束的优化等于没有规矩。约束要能真实反映储能的物理特性和用户的用电边界。我梳理了几个必须写进去的核心约束。第一个是储能电池的SOC荷电状态动态方程。这是储能的“物理灵魂”也是优化模型里最容易出错的一个环节。它的连续时间表达式是SOC(t1) SOC(t) [ η_c * Pc(t) - Pd(t) / η_d ] * Δt / E_cap其中η_c和η_d分别是充放电效率E_cap是储能额定容量。需要注意的是充放电效率乘除的位置别搞反了——充电时是“充进去的功率×效率”放电时是“放出去的功率÷效率”。我在早期版本里曾经把放电效率的表达式写反导致SOC越放越高那是典型的逻辑错误。第二个是充放电功率限制包括功率上下限和状态互斥。所谓互斥就是同一时刻不能同时充电又放电这是物理上不允许的。在优化模型里引入两个0-1变量来分别表示充电状态和放电状态并且要求两者之和小于等于10 ≤ Pc(t) ≤ Pc_max * u_c(t) 0 ≤ Pd(t) ≤ Pd_max * u_d(t) u_c(t) u_d(t) ≤ 1这三个式子配合起来就实现了“同一时刻只能充或者只能放”的限制。第三个是SOC的上下限约束以及一天结束时的SOC回位。电池不能过充过放一般限制在0.1到0.9之间日末SOC需要回位保证第二天有同样的调度基础SOC_min ≤ SOC(t) ≤ SOC_max SOC(0) SOC(T) SOC_init2.3 时间粒度和预测数据的处理模型的时间粒度直接决定问题规模。24小时如果每个时段是1小时T24问题很小如果每个时段15分钟T96决策变量扩大4倍求解时间也会增加不少。实际项目中怎么选如果重点是分析经济性1小时的粒度就够如果电池容量较小、储能动作频繁建议15分钟粒度如果研究的是调频等秒级场景那就不是“日前”的问题了负荷预测数据和电价数据的对齐是另一个坑。电价表通常给出的是整点价格而负荷预测数据来自不同的系统有时是整点有时是半点需要统一成同一个时间轴。我在程序里专门写了一个数据对齐的函数先把原始数据插值、对齐到统一的调度时段再做优化求解。3. Matlab程序实现从零搭起一个调度内核3.1 环境与工具选型Matlab写优化模型有两个常用方案一是纯Matlab的linprog、intlinprog适合线性规划和整数线性规划二是Yalmip工具箱它是一款建模层工具把模型描述变得非常直观求解时再指定调用哪个求解器。我个人强烈建议用Yalmip原因就两条一是代码可读性高约束条件的表达和数学公式几乎一一对应二是换求解器非常方便今天用Cplex明天想换Gurobi只需要改一行选项设置不需要重写模型。安装上提个醒Yalmip不是Matlab官方工具箱需要从官网下载后手动添加到Matlab路径。下载解压后在Matlab里执行addpath(genpath(D:\Tools\yalmip)); savepath;求解器方面如果用的是学生版或者没有商业求解器可以先装一个免费的Gurobi学术版或者用Matlab自带的intlinprog作为临时替代——注意用intlinprog时要把模型转换成系数矩阵形式Yalmip会帮你自动做这一步转换非常省心。另一个常见的坑是Matlab打开已有工程时出现中文注释乱码。这个问题基本都出在文件编码不一致上脚本文件是UTF-8但Matlab旧版本默认用GBK读取。解决的办法是把脚本用UTF-8另存或者统一在代码最开始加一行%#ok*SABS不过最省事的做法还是一次性把整个工程的文件编码统一好免得每次打开都乱。我的习惯是新建脚本前先“另存为UTF-8”代码注释全部用英文关键术语的中文对照说明这样在任意版本Matlab里都不会出问题。3.2 数据结构设计程序的第一步是整理输入数据。我推荐用结构体或者表格来组织避免散落一堆变量。% 基础参数 params.T 24; % 调度时段数24小时 params.dt 1; % 时间间隔小时 params.Pc_max 500; % 储能最大充电功率kW params.Pd_max 500; % 储能最大放电功率kW params.E_cap 1000; % 储能额定容量kWh params.eta_c 0.95; % 充电效率 params.eta_d 0.95; % 放电效率 params.SOC_min 0.1; % 荷电状态下限 params.SOC_max 0.9; % 荷电状态上限 params.SOC_init 0.5; % 初始荷电状态 params.c_om 0.02; % 运维成本元/kWh % 用户数据这里假设有3个工业用户 num_users 3; P_load zeros(num_users, params.T); % 每个用户的24h负荷功率 % 电价数据 price_buy [0.32, 0.32, ...]; % 24小时购电电价元/kWh用结构体存参数的好处是传给子函数时只需要传一个变量不用堆一大堆输入参数调试时变量管理也干净。用户负荷数据读进来之后最好统一转成行向量格式保证后续矩阵运算维度匹配这个看似小事实际经常出bug。3.3 核心约束代码接下来就是用Yalmip定义决策变量和约束。决策变量包括储能总充放电功率、每个用户的放电分配功率、SOC以及充放电状态0-1变量。% 决策变量 Pc sdpvar(1, params.T, full); % 储能充电功率 Pd sdpvar(1, params.T, full); % 储能放电功率 u_c binvar(1, params.T); % 充电状态0-1 u_d binvar(1, params.T); % 放电状态0-1 SOC sdpvar(1, params.T1, full); % 荷电状态多一个元素用于末时段 % 用户侧从储能获取的功率分配 P_discharge sdpvar(num_users, params.T, full); % 用户侧电网购电功率 P_grid_user sdpvar(num_users, params.T, full);约束条件按照数学模型一条条写进去。这里有一个地方要特别注意如果储能总放电功率等于各用户放电分配功率之和这条约束可以写成Cons []; Cons [Cons, sum(P_discharge, 1) Pd]; % 总放电功率等于各用户分配之和而每个用户的负荷平衡约束是Cons [Cons, P_grid_user(i, :) P_discharge(i, :) P_load(i, :)];这代表每个用户要么从电网买电要么从共享储能取电两者必须满足它的负荷需求。目标函数里用P_grid_user来算用户侧购电成本这样每个用户的购电成本和储能放电获益都可以分别统计出来。SOC动态方程写成Cons [Cons, SOC(2:end) SOC(1:end-1) ... (params.eta_c * Pc - Pd / params.eta_d) * params.dt / params.E_cap];充放电互斥约束和SOC边界约束Cons [Cons, Pc 0, Pc params.Pc_max * u_c]; Cons [Cons, Pd 0, Pd params.Pd_max * u_d]; Cons [Cons, u_c u_d 1]; Cons [Cons, SOC params.SOC_min, SOC params.SOC_max]; Cons [Cons, SOC(1) params.SOC_init, SOC(end) params.SOC_init];把目标函数和约束全部组装好之后指定求解器求解ops sdpsettings(solver, gurobi, verbose, 1, showprogress, 1); optimize(Cons, Objective, ops);如果Gurobi没装把solver改成intlinprog也能勉强跑只是大型问题求解速度会明显慢一些。3.4 结果输出与绘图求解完成后第一件事是检查求解状态if optimize(Cons, Objective, ops) 0 Pc_opt value(Pc); Pd_opt value(Pd); SOC_opt value(SOC); else disp(求解失败); end绘图推荐直接画四个子图储能的充放电功率曲线、SOC曲线、各用户放电分配曲线、各用户的购电成本柱状图。这些图能直观地验证调度策略是否合理放电高峰是否落在电价尖峰时段充电是否在电价低谷时段SOC曲线是否在上下限范围内平滑变化各用户的放电分配是否和它们的负荷大小、电价敏感度匹配这些图最好一次性生成方便后面做结果分析。用Matlab自带的figure和subplot足够我不建议引入太多画图库保持程序轻量运行一次几秒钟出图才是舒服的开发节奏。4. 工业用户的应用场景与收益测算4.1 峰谷套利和需量电费工业用户为什么要用共享储能核心是两个字省钱。省在哪里主要有两大块。第一块是峰谷套利。很多省份的工业分时电价尖峰时段和低谷时段价差能到0.8元/kWh以上。储能晚上充、白天放一度电一个来回就能赚几毛钱差价。第二块是需量电费。这个很多人容易忽略但它往往比峰谷套利更值钱。工业用户的基本电费有两种计费方式按变压器容量计或者按最大需量计。如果工厂的负荷波动大、瞬时峰值高按最大需量计费就会非常吃亏。储能的作用在这里就是“削峰”——在负荷尖峰时放电压低从电网取电的最大功率从而减少每月的需量电费。我做过的一个注塑厂案例它的最大负荷是1200kW峰值每年只出现十几次大部分时间负荷在700kW左右。配上储能后把最大需量从1200kW压到了900kW一个月的基本电费就省了将近一万元。这种收益不需要复杂计算一算账就能打动老板。4.2 容量分配与结算机制共享储能和单个用户自建储能最大的区别在于它必须考虑“怎么分配”的问题。我在模型里用的是“放电分配”模式——储能总放电功率由调度中心分配分配到每个用户多少功率该用户就享受多少储能服务。实际结算可以这样设计储能电量的“能量费”按峰谷价差受益来分摊需量电费的节省按各自削峰的贡献度来分配服务费按放电电量来计费这种结算机制的好处是“谁受益、谁付费”用户参与意愿高。我在程序里额外输出了一张用户侧费用明细表包括每个用户的购电成本、节省的需量费用、储能服务费、净节省额。这种细化输出对项目谈合作特别有用直接拿着表就能给用户算经济账。4.3 一个简化的算例参数为了验证模型的有效性我做了一组简化测试参数如下参数数值储能容量1000 kWh储能功率500 kW充放电效率0.95SOC范围0.1 - 0.9调度时段数24工业用户数3分时电价峰值1.1元/kWh平时0.65元/kWh谷值0.3元/kWh三个用户的负荷曲线我分别做了设置用户A白天负荷高典型的单班制工厂负荷集中在8点到18点用户B夜间负荷高24小时连续生产夜班占大头用户C负荷相对平稳但总体量较小在共享储能模式下三个用户用电特性互补让储能的利用率明显提升。优化结果显示储能会在凌晨低谷时段充电白天两个高峰时段放电。尤其值得注意的是用户B夜间负荷高但夜间电价偏低它本身的储能需求不大用户A白天负荷峰谷差明显对储能的依赖度更高。调度模型自动把更多放电配额配给用户A这非常符合逻辑——谁能在高价时段消纳放电、谁的收益更大储能服务就倾向分配给谁。这个结果也说明了共享储能的一个核心优势用户之间的负荷错峰能显著提高电池的周转率和使用价值这是单用户储能很难做到的。5. 实际调试中的问题与处理记录5.1 求解器与YALMIP的坑跑这类程序最容易卡死的环节不在建模而在环境。我见过太多人在交流群里问“为什么我的Yalmip用不了”答案几乎都是环境变量没配对。常见表现是运行时报错“No solver specified”或“Failed to find a solver”。Yalmip不会自动帮你找求解器它只是建模层。需要先安装求解器然后在代码里显式指定。另外Yalmip自带一个“solver report”可以用yalmiptest来测试当前环境有哪些可用求解器建议装好环境后先跑一下这个命令。还有一个容易被忽视的问题Matlab是64位但装的求解器是32位版本导致接口无法调用。特别是某些老版本的Cplex32位和64位版本不兼容这个问题十分隐蔽。检查方式很简单在Matlab命令窗口执行which cplex which gurobi如果结果显示空的说明求解器路径根本没加进来。在Windows下Gurobi需要先设置环境变量GUROBI_HOME然后在Matlab里用gurobi_setup完成配置不要漏掉这一步。5.2 模型不可行排查用Yalmip写约束模型最头疼的是运行得到“infeasible problem”也就是优化问题无解。这个报错含义很直白——约束条件之间自相矛盾了。排查思路我总结了一套固定的顺序第一步检查SOC动态方程有没有写错。充放电效率方向弄反、初始SOC和末端SOC设置冲突是最常见的两个原因。比如SOC_init0.9但SOC(end)要求是0.1如果储能容量又小可能一天之内根本放不完电就会导致不可行。第二步检查功率边界。如果Pc_max设置得太小而负荷波动又大储能“有心无力”系统会找不到满足全部负荷的充电计划。第三步检查互斥约束。u_c和u_d的约束有时会和目标函数联动产生数值问题可以尝试把“u_cu_d1”改成“u_cu_d1”强制每时段必须有明确状态。第四步是把约束逐个注释掉跑一次看看哪里导致不可行这种二分排查法是效率最高的。如果模型本身没问题还可以调整求解器的容差设置。默认的MIP gap有时候太严格在工程上没必要可以放宽一些比如设置成0.01求解时间会显著下降结果差异极小。5.3 结果不合理的检查顺序比起直接崩溃更折磨人的是模型能跑、结果却很离谱。比如储能整晚不充电、一天到头SOC纹丝不动或者充电功率和放电功率在相邻时段反复跳变像得了帕金森。第一种情况基本可以断定是目标函数里没写对电价传导。用户购电成本没有正确计入总目标优化器觉得“充不充电无所谓”自然不动。检查办法是把目标函数里的每一项分别打印出来看数值量级是不是合理。第二种情况是储能功率频繁波动这是典型的“未考虑调度连续性”。解决办法是在目标函数里增加充放电功率变化的惩罚项或者对充放电状态变化次数做约束。实际操作中我通常会把功率变化量的绝对值乘一个很小的惩罚系数加进目标函数这能有效平滑充放电曲线Objective Objective penalty_lambda * sum(abs(Pd(2:end) - Pd(1:end-1)));可能有人会觉得多个惩罚项会影响经济性结果但实际上penalty_lambda取一个很小的值就能明显改善曲线且对总成本影响极小。这个技巧在处理工程实际数据时非常实用。最后给正在跑这类程序的朋友一个建议第一次写Data别上来就用96个时段。先把模型时域缩到24个点、去掉0-1二进制变量用线性规划跑通整个流程再逐级引入整数变量和更细的时间粒度。不要问我为什么知道——我也是在一堆不可行报错和求解器报错里泡出来的。这样一步步验证才是让程序保持稳定、结果可信的关键。