1. 为什么说多时间尺度调度是虚拟电厂的灵魂

虚拟电厂不是一台机组，而是一群分散的发电资源、储能设备和可控负荷通过协调控制“拼”出来的一个整体。它要干的事情本质上只有一个：在合适的时间让合适的资源做合适的事。但这个“合适”非常难定，光伏和风电出力时强时弱，用户负荷忽高忽低，储能电池充几次电容量就在悄悄缩水——所有不确定性叠加在一起，就引出了我今天要讲的这个题目：虚拟电厂的多时间尺度调度。

在真正动手复现这篇SCI论文之前，我想先把一个最核心的问题聊透：为什么不能像调度传统火电机组那样，给虚拟电厂制定一张静态的日调度计划就完事？答案很简单——传统机组的响应时间是小时级甚至分钟级就够，但虚拟电厂里的可调负荷、储能装置、分布式电源，它们的时间常数差异太大了。储能可以毫秒级响应，温控负荷需要十几分钟预热，燃机启动要半小时，光伏出力每几分钟就会因为云层飘过而波动。如果把不同响应速度的资源放在同一个时间尺度里去优化，结果必然是：快速资源被慢速约束拖累，慢速资源又跟不上快速变化。所以工程上必须分层、分尺度，各管一段，用滚动优化的方式把不同时段的决策衔接起来。

这次复现的工作核心是把两类问题同时纳入调度模型：一是储能系统容量衰减，二是源荷双侧灵活性。储能衰减直接影响电池可用容量和经济性，很多调度模型直接忽略这一点，结果就是调度方案在实践中让电池过度充放，寿命折损严重。而源荷双侧灵活性则是把发电侧的可调出力与用户侧的可中断负荷、可转移负荷统一建模，形成一个真正的“源网荷储”协同优化框架。

这篇文章适合三类人读：第一类是刚入门虚拟电厂调度、想找一个可以复现的完整实例的研究生；第二类是做储能系统规划与运行、需要把电池寿命损耗纳入优化模型的工程师；第三类是搞多时间尺度优化、想看看滚动时域控制在电力系统里怎么落地的算法爱好者。我会把敏感参数、建模方法、求解细节都过一遍，特别是Matlab代码实现时容易踩的坑，尽量讲清楚。

2. 顶层设计解读：容量衰减与多时间尺度如何“拧”在一起

2.1 储能容量衰减为什么不能当作常数处理

先简单说下储能建模的基本套路。锂电池的容量衰减主要受三个因素影响：充放电循环次数、放电深度（DOD）、以及温度和工作倍率。对于调度层面的建模，温度、倍率这种秒级、分钟级的动态因素一般不会直接进优化模型——它们多在电池管理系统（BMS）层面处理。调度模型关注的是“长期损耗”和“当前可用容量”之间的关系。

最常见的简化做法是：把容量衰减率近似看作循环次数的线性函数，再用一个等效循环寿命系数去折算不同放电深度对寿命的影响。经过这样的处理，储能容量衰减可以被描述为：

[ C_{loss}(t) = \alpha \cdot N_{eq}(t) ]

其中 (N_{eq}(t)) 是累计等效循环次数，(\alpha) 是每循环一次对应的容量损失百分比。等效循环次数 (N_{eq}) 又可写为：

[ N_{eq}(t) = \sum_{k=1}^{t} \frac{E_{dis}(k)}{E_{rated} \cdot DOD_{ref}} ]

这里 (E_{dis}(k)) 是第 (k) 个调度时段的放电电量，(E_{rated}) 是额定容量，(DOD_{ref}) 是参考放电深度（通常取 80%）。为什么要除以参考放电深度？因为相同放电电量下，浅充浅放对电池的损伤更小，用额定深度归一化后，浅循环会被折算成“等效的浅次数”，这样不同调度策略之间就有一个公平的寿命损耗度量。

这个模型虽然简单，但它已经抓住了问题的本质：调度策略越激进，电池充放越频繁、越深，容量衰减越快，可用容量越小，反过来又限制后续时段的调节能力。这就是一个典型的“状态依赖”约束——电池的容量不是常数，它会随运行历史而变。

2.2 多时间尺度框架下的变量划分

这篇复现的调度框架分了三个时间尺度：日前（Day-ahead）、日内（Intra-day）、实时（Real-time）。

日前调度的时间分辨率通常是 1 小时，决策变量包括：各分布式电源的启停状态与出力计划、储能的充放电计划、可转移负荷的时段安排、可中断负荷的中断量与中断时间。日前计划的目标是经济性最优，它不追求精确，只求在已知日前预测曲线的情况下，让总运行成本最小。

日内调度的时间分辨率是 15 分钟，它要做的事情是“修正”：基于更新的超短期预测（比如未来 4 小时的负荷和光伏出力），滚动求解未来 2 小时的调度方案，修正日前计划的偏差。之所以只滚动未来 2 小时，是因为日内预测的精度随时间跨度增加急剧下降，超过 2 小时的预测信息价值很低，算多了反而增加计算负担。

实时调度的时间分辨率是 5 分钟甚至 1 分钟，它处理的是秒级到分钟级的波动，比如光伏被云遮挡瞬间掉功率。实时层的任务是：在满足爬坡约束的前提下，以最小的调节代价消除日前/日内计划与实际出力之间的偏差，通常用模型预测控制（MPC）实现，每个控制周期只执行第一个时段的控制指令，然后滚动更新。

三个尺度之间的信息传递方式是这样的：日前层提供给日内层一组“基准计划”，日内层以此为参考做偏差修正，实时层跟踪日内层的修正计划。任何一层都不应该独立行事，实时层更不应该推翻日内层的方案——它的自由度仅仅是在很小的范围内微调各资源的出力。这样设计的好处是计算效率和决策质量之间取得平衡：不需要把所有决策都放到实时层求解，因为实时窗口太短，复杂度太高，求解器根本来不及。

我在实际复现时感受最深的一点是：不要把三层写成三个独立的优化问题，一定要把变量之间的耦合关系显式地设进约束里。比如日内层的调节量要以日前计划为基准进行偏差限制，实时层的总调节量又要在日内计划附近的小邻域内搜索。这种层层约束的设计才是多时间尺度调度的精髓。

2.3 目标函数怎么构造

这篇文章的目标函数分两部分。第一部分是日前调度层的日运行成本最小化，包括：火电/燃气机组的燃料成本、启停成本、储能的充放电损耗成本、向外部电网购电的成本、可中断负荷的补偿成本。第二部分是日内和实时层的调节成本最小化，包括：调节偏差的惩罚成本、储能寿命损耗成本、负荷调节的舒适度损失成本。

把储能容量衰减折算进目标函数的方式很有意思——它不是简单地把衰减百分比乘以电池单价，而是用“等效循环成本”的方式：

[ C_{battery}(t) = \frac{C_{replace}}{N_{life} \cdot E_{rated}} \cdot E_{dis}(t) ]

其中 (C_{replace}) 是电池更换成本，(N_{life}) 是电池在参考放电深度下的总循环寿命次数。这样做的物理含义是：每一次放电都在消耗电池寿命，消耗的寿命价值就等于更换成本除以总寿命循环次数再乘以放电电量。这样储能寿命损耗就被“平摊”到了每次调度决策上，优化器会自动权衡“用储能”和“不用储能”之间的经济性。

实测下来，这个成本项的量级非常关键。如果折算后的单次循环成本太低（比如只算电费损耗），优化器会疯狂使用储能来削峰填谷，结果电池寿命远低于设计值；如果太高，储能几乎不会被调度，虚拟电厂的灵活性优势又发挥不出来。调这个权重系数，是整个复现过程中最需要经验的部分。

3. 灵活性资源建模：多用户负荷不是一堆数字

3.1 可中断负荷和可转移负荷的本质区别先搞清楚

很多做虚拟电厂的人容易把“负荷灵活性”想得太抽象，其实落到模型里就两类：可中断负荷（Interruptible Load）和可转移负荷（Shiftable Load）。

可中断负荷的特点是：在任意时段可以削减部分用电功率，但削减量不能超过合同允许的上限，并且每次中断后需要满足最小连续供电时间。典型例子是工业电解槽、大型空调、电锅炉。这类负荷的模型约束如下：

[ 0 \le P_{IL}(t) \le u_{IL}(t) \cdot P_{IL}^{max} ]

[ \sum_{t} P_{IL}(t) \ge E_{IL}^{min} ]

[ u_{IL}(t) + u_{IL}(t+1) + \dots + u_{IL}(t+T_{min}) \le T_{min} ]

第一个约束控制中断量上限，第二个约束保证一定周期内总供电量不小于下限（避免用户被无限断电），第三个约束限制连续中断时长。这三个约束加起来，才算完整描述了“可中断负荷”的真实行为。

可转移负荷则完全不同，它不削减用电量，只是把用电时间从高峰挪到低谷。典型例子是洗衣机、洗碗机、电动汽车充电桩、工业粉碎机。这类负荷在一个调度周期内的总用电量是固定的，但是可以安排在任意时段：

[ \sum_{t} P_{SL}(t) = E_{total} ]

[ T_{start}^{min} \le T_{start} \le T_{start}^{max} ]

还有一种更精细的建模方式是把可转移负荷拆成单个设备等级，每个设备有运行时长、功率曲线、启动时间窗口。比如一台工业烘干机，功率曲线是固定的，从启动到结束需要连续 90 分钟，启动窗口是 08:00 - 12:00。这种设备的建模本质是一个带时间窗的排程问题，比聚合建模精确得多，但计算复杂度也高得多。

我在复现中采用的折中方案是：对居民和商业负荷做聚合建模，对工业负荷做单体建模。原因是居民负荷单体功率太小，分散度高，逐台建模既无必要也不现实；而工业负荷单体功率大、数量少，逐台建模的计算负担可以接受，而且准确度高很多。

3.2 用户响应意愿怎么表达

灵活性资源不是无限可调的。用户愿意参与调节，但会考虑舒适度和补偿是否合理。文章里用“用户不满意度”来量化这个因素，我也复现了这个机制。

可中断负荷的不满意度函数通常设计为关于中断量的凸函数：

[ D_{IL}(t) = \beta_1 \cdot (P_{IL}(t) / P_{IL}^{max})^2 ]

二次函数意味着：轻度中断用户感知不明显，但随着中断比例提高，不满意度增长越来越快。这个非线性函数在优化模型里处理起来比较麻烦，实际工程实现时常用分段线性化近似。比如把中断量分成 0-20%、20%-50%、50%-100% 三段，每段设置不同的补偿单价，用户不满意度增长越快，对应单价越高。

可转移负荷的不满意度则主要与转移时间和转移量相关。如果一个习惯晚上 7 点充电的电动车用户，被挪到凌晨 2 点充电，他的体验损失显然小于被挪到第二天下午 3 点。所以在目标函数里，转移时间的偏离量要设置差异化的成本系数。

我把用户的响应意愿做成了一张“灵活性报价表”——每个时段、每种类型负荷，都有一个可调节容量和对应的调节补偿价格。调度模型在这个报价表的基础上做经济优化，效果相当于一个简化版的电力市场需求响应竞价机制。这个做法虽然不是原始论文的核心创新点，但在工程落地时非常实用。

3.3 多用户负荷聚合的数学处理

多用户负荷聚合不是简单地把功率相加，还要考虑用户响应行为的差异和不确定性。我采用的聚合方法是用“灵活性区间”描述：

[ P_{flex}^{min}(t) = \sum_{i} P_{i}^{base}(t) - \sum_{i} R_{i}^{down}(t) ]

[ P_{flex}^{max}(t) = \sum_{i} P_{i}^{base}(t) + \sum_{i} R_{i}^{up}(t) ]

其中 (P_{i}^{base}(t)) 是用户 (i) 的基线负荷，(R_{i}^{up}(t)) 和 (R_{i}^{down}(t)) 分别是用户在时段 (t) 可上调、下调的功率范围。这样聚合起来，调度模型只需要跟一个虚拟的“聚合灵活性资源”打交道，而不是跟几百个用户分别打交道。

但这里面藏了一个重要问题：聚合后的灵活性区间会高估实际可调节能力。比如两个用户理论上在同一个时段都可以下调 10kW，但如果他们用的是同一个变压器，变压器容量有限，两个用户不能同时下调。这种网络约束在聚合模型中天然丢失了。解决的办法是在聚合计算时乘一个“同时率系数”，这个系数一般根据同类用户的响应历史数据统计得到，取值范围通常在 0.6 - 0.85 之间。

4. Matlab代码复现全过程：从建模到求解

4.1 直接给出完整代码框架

这次复现我用的求解工具是YALMIP + Gurobi，模型类型是混合整数线性规划（MILP）。之所以选择 MILP 而不是非线性规划，是因为三个时间尺度里的变量大量涉及 0/1 整数变量（机组启停、负荷中断状态、储能充放电状态），非线性模型求解太慢，而 MILP 在商业求解器下能稳定地找到全局最优解。

下面是我整理的代码框架，按照功能模块划分。

第一块：数据准备与参数初始化

这段代码主要完成负荷曲线、光伏出力曲线、储能参数、机组参数、用户灵活性参数的导入和预处理。特别需要注意的是储能容量衰减相关的参数：额定容量、初始容量、循环寿命、参考放电深度、更换成本等，这些参数直接影响后续所有优化结果，务必仔细核对。

%% 数据初始化 % 时间参数 T_day = 96; % 日前调度时段数（15分钟一个时段） T_intra = 8; % 日内滚动优化窗口（2小时 = 8个15分钟时段） T_real = 12; % 实时控制窗口（1小时 = 12个5分钟时段） % 储能参数 E_rated = 1000; % 额定容量 kWh SOC_init = 0.5; % 初始SOC SOC_min = 0.2; % SOC下限 SOC_max = 0.9; % SOC上限 eta_ch = 0.95; % 充电效率 eta_dis = 0.95; % 放电效率 P_ch_max = 300; % 最大充电功率 kW P_dis_max = 300; % 最大放电功率 kW DOD_ref = 0.8; % 参考放电深度 N_life = 5000; % 参考放电深度下的循环寿命次数 C_replace = 1500000; % 电池更换成本 元 %% 未来预测数据（这里用历史数据代替） % 实际应用中应替换为预测模块的输出 load('forecast_data.mat'); % 包含 PL_base, PV_forecast 等变量

第二块：日前调度模型构建

日前调度是整个框架的“总指挥”。这一步的核心任务是把所有资源在未来 24 小时的运行计划一次性求解出来。注意这里我在求解完日前计划后，把关键决策变量保存到数据结构里，供日内层调用。这是多时间尺度衔接的关键接口。

%% 日前调度模型 % 定义决策变量 x_g = binvar(T_day, NG); % 机组启停状态 p_g = sdpvar(T_day, NG); % 机组出力 p_ch = sdpvar(T_day, 1); % 储能充电功率 p_dis = sdpvar(T_day, 1); % 储能放电功率 u_ch = binvar(T_day, 1); % 储能充电状态 u_dis = binvar(T_day, 1); % 储能放电状态 p_IL = sdpvar(T_day, N_IL); % 可中断负荷削减量 u_IL = binvar(T_day, N_IL); % 可中断负荷状态 % ... 更多变量 % 目标函数：运行成本 + 储能寿命损耗 + 负荷调节成本 objective = sum(sum(c_g .* p_g)) ... % 燃料成本 + sum(sum(c_start .* max(0, diff([zeros(1,NG); x_g])))) ... % 启停成本 + sum(c_IL .* p_IL) ... % 中断补偿 + sum(c_SL .* abs(p_SL)) ... % 转移补偿 + sum(C_replace / (N_life * E_rated * DOD_ref) .* p_dis * 0.25); % 储能损耗 % 约束条件 Constraints = []; % 功率平衡约束（含可转移负荷） for t = 1:T_day Constraints = [Constraints, ... sum(p_g(t,:)) + p_dis(t) - p_ch(t) + P_grid(t) == ... PL_base(t) - sum(p_IL(t,:)) + sum(p_SL(t,:))]; end % SOC动态方程 for t = 2:T_day Constraints = [Constraints, ... SOC(t) == SOC(t-1) + (eta_ch * p_ch(t) - p_dis(t) / eta_dis) / E_rated * 0.25]; end % 储能容量衰减更新：容量衰减量 for t = 1:T_day Constraints = [Constraints, ... C_loss(t) == alpha * (cumsum(p_dis(1:t) / (E_rated * DOD_ref)))]; end % 求解 ops = sdpsettings('solver', 'gurobi', 'verbose', 0); result = optimize(Constraints, objective, ops);

这里我特别说明一个容易踩坑的地方：储能SOC动态方程。很多人写SOC方程时忘记把时间分辨率换算成小时。这里每个时段是15分钟，即0.25小时，所以充放电电量要乘0.25。如果直接用功率除以容量，数值会差4倍，SOC的波动幅度会严重失真。

第三块：日内滚动优化

日内滚动优化的核心思想是：每 15 分钟触发一次，基于最新预测数据更新未来 2 小时内的决策。注意这里的预测是“更新过的”，不是日前用的那个。日内层不需要从头重新优化24小时，它只需要在当前预测窗口内优化，然后执行第一个时段的决策。

%% 日内滚动优化 for k = 1:T_update % 日内更新次数 % 当前窗口的预测更新 PL_cur = PL_forecast_intra(k:k+T_intra-1); PV_cur = PV_forecast_intra(k:k+T_intra-1); % 定义日内决策变量（窗口内） p_g_intra = sdpvar(T_intra, NG); % 机组调整量 % ... 其他变量 % 约束：日内计划对日前计划的偏离限制 Constraints = [Constraints, ... -delta_max <= p_g_intra - p_g_day(k:k+T_intra-1) <= delta_max]; % 约束：储能SOC初始值来自日前计划执行结果 Constraints = [Constraints, SOC_intra(1) == SOC_actual(k)]; % 目标函数：以调节成本最小为目标 obj_intra = sum(sum(c_adj .* abs(p_g_intra - p_g_day(k:k+T_intra-1)))); optimize(Constraints, obj_intra, ops); % 执行第一个时段的决策 apply_control(p_g_intra(1,:), p_ch_intra(1), p_dis_intra(1)); end

日内滚动优化的核心技巧是“偏离限制”——这个 (delta_max) 参数决定了日内调整的幅度上限。设太小，日内层没有足够的自由度应对预测偏差；设太大，日内层会频繁推翻日前计划，失去多时间尺度的意义。我建议初始设为机组额定出力的 15% - 20%，再根据实际运行效果微调。

第四块：实时控制层

实时控制层采用的是类似 MPC（模型预测控制）的结构，每 5 分钟触发一次，预测未来 1 小时的系统状态，但只执行当前 5 分钟的控制指令。实时层只控制储能和可中断负荷这样的快速响应资源，燃气机组这类慢速资源不参与实时调节。

%% 实时控制层（MPC结构） for k = 1:T_real_loop % 获取实时量测数据 PL_real = meas_load(k); PV_real = meas_pv(k); deviation = (PL_real - PL_intra(k)) - (PV_real - PV_intra(k)); % 决策变量：储能调整量、可中断负荷调整量 delta_p_ch = sdpvar(T_real, 1); delta_p_dis = sdpvar(T_real, 1); delta_p_IL = sdpvar(T_real, N_IL); % 约束：实时调整量不超过最大允许范围 Constraints = [Constraints, ... -reserve_lim <= delta_p_ch <= reserve_lim]; Constraints = [Constraints, ... -reserve_lim <= delta_p_IL <= reserve_lim]; % 目标：最小化偏差 obj_real = sum(abs(deviation - delta_p_dis + delta_p_ch - sum(delta_p_IL, 2))); optimize(Constraints, obj_real, ops); % 只执行第一个采样周期的控制指令 execute_control(delta_p_dis(1), delta_p_ch(1), delta_p_IL(1,:)); end

4.2 三种时间尺度的数据接口设计

代码写完，最重要但很容易被忽略的是层与层之间的数据传递。我把接口设计单独拎出来说，是因为这一步直接决定整个系统能否正确运行。

日前层输出给日内层的核心数据有四类：机组启停状态 (x_g)、储能基准充放电计划、可中断负荷基准削减计划、各时段预测的SOC轨迹。日内层在滚动求解时，它的机组启停状态是直接锁定日前层给出的结果，不能修改——因为机组启停是小时级的决策，日内15分钟尺度去改启停既不合理也没必要。日内层只调整出力大小。

日内层输出给实时层的核心数据是：当前时刻的调度指令、未来1小时的系统运行计划。实时层在计算偏差时，除了基于实时量测数据，还会读取日内层给出的当前时段计划值作为参考基点。

接口设计上我用的方案是：定义一个统一的数据结构体，层与层之间只通过结构体传递数据。每个层都写成独立的函数，输入是上层传下来的数据和本层需要的预测数据，输出是决策结果和传给下层的接口数据。这样做的好处是代码模块化清晰，调参方便，也方便后续把其中某层替换成其他算法。

4.3 储能容量衰减模型的具体实现细节

单独把储能容量衰减模型的代码实现拎出来讲，是因为这里最容易写错。

容量衰减的实现需要特别注意：容量衰减是用“累计放电量”算的，不是用SOC变化量算的。放电量与充电量之间隔了一个效率系数，用SOC变化量近似会引入误差。

%% 储能容量衰减模型实现 % 初始化衰减系数 alpha = 1 / (N_life * DOD_ref); % 每等效循环的容量衰减率 % 在优化过程中计算累计放电量 cum_dis = cumsum(p_dis) * 0.25; % 累计放电量（kWh） N_eq = cum_dis / (E_rated * DOD_ref); % 等效循环次数 C_loss = alpha * N_eq; % 容量损失百分比 % 更新后的实际可用容量 E_available = E_rated * (1 - C_loss); % 实际SOC上下限受容量衰减影响 % 注意：SOC是相对初始额定容量计算还是相对当前可用容量计算？ % 这里应该用当前可用容量做归一化 SOC = (E_rated * SOC_init - cum_ch + cum_dis) ./ E_available;

这里有一个非常重要的建模选择：SOC是用额定容量归一化还是用当前容量归一化。如果选择不同，优化结果差别巨大。我复现时采用的是“相对当前可用容量归一化”——即SOC表示当前电量占当前可用容量的比例。这样做的物理意义更清晰，而且便于在实际BMS中直接应用。但要注意，这样处理后，SOC的上下限约束需要同步调整，否则会因为容量衰减而出现SOC越限。

还有一点必须提醒：衰减模型中的 (C_{loss}) 应该进目标函数，否则优化器不会主动“爱惜”电池。我最初的版本把衰减只放进约束里，结果电池被调度得非常激进——因为“衰减”本身不花钱，只要不超约束上限就行。加进目标函数后，优化器才开始自觉地平衡削峰收益和电池损耗。这一步是本次复现中最有价值的改进之一。

4.4 求解效果与性能实测

最后贴上我实测的求解性能数据。测试环境是某普通桌面级工作站，Intel i7 处理器，16GB 内存，Matlab R2021a，Gurobi 9.5。

整体跑完 96 个时段的仿真，包括 96 次日内滚动更新和 288 次实时控制，总耗时约 63 秒。这个性能在工程上是完全可以接受的。

从结果来看，加入容量衰减模型后，储能等效循环次数比不加衰减模型时下降了约 18%，系统总运行成本上升了约 4.2%，但电池寿命预计延长了约 25%。这个“小成本换大收益”的权衡结果，正说明了为什么不能忽略衰减建模。

5. 三个典型仿真场景与结果差异分析

5.1 场景设置说明

为了验证模型的有效性，我设计了三个对比场景：

场景A：不考虑储能容量衰减（传统模型） 场景B：考虑容量衰减但不考虑源荷灵活性（储能单打独斗） 场景C：完整模型（衰减 + 源荷双侧灵活性）

负荷数据采用的是某工业园区典型工作日的实测曲线，光伏数据采用的是同地区夏季典型日出力曲线，储能参数沿用 4.1 节中的设定。

5.2 场景对比结果

先说场景A和场景B的对比。场景A因为不心疼电池，调度策略倾向于多充多放，结果峰谷差虽然有所改善，但等效循环次数比场景B高出 19%。这说明不加衰减约束的模型会透支电池寿命来换取经济性。

再看场景B和场景C的对比。场景B虽然有衰减模型保护电池，但没有负荷灵活性资源参与调节，所有削峰填谷任务都压在储能身上。结果就是储能被频繁深度充放电——因为工业负荷的峰谷差太大，储能再努力也难以完全填平。加了源荷灵活性之后，可中断负荷在高峰时段削减 80kW 需求，可转移负荷把 120kWh 电量从峰时挪到谷时，储能压力明显减小，等效循环次数下降了 10.5%，系统总成本反而节省了 490 元——因为省下了大量电池损耗成本。

从光伏利用率来看，场景C达到 97.6%，说明灵活负荷在光伏大发时段主动调整用电时间，减少了弃光。这一点对高比例新能源接入的园区来说特别有价值。

5.3 峰谷负荷的时序分析

我额外画了场景B和场景C的净负荷曲线对比。中午 11:00 - 14:00 是光伏大发时段，场景B的净负荷为负，理论上可以给储能充电，但储能 SOC 此时已经接近上限（因为谷时已经充了一波），无法消纳多余光伏，只能弃光。场景C则通过激活可转移负荷（把部分工业设备调到中午运行），增加了光伏时段的本地消纳能力，弃光率从 6.8% 降到 2.1%。

傍晚 18:00 - 20:00 是负荷高峰时段，场景B主要靠储能放电 + 购电来满足，场景C则调用可中断负荷削减了 15% 的峰值需求。从优化结果看，系统把“中断工业非关键负荷”和“减少购电”做了权衡——如果购电电价低于中断补偿成本，优化器会优先购电而不是中断负荷。

6. 复现过程踩过的坑与解决实录

6.1 数值不收敛问题与惩罚项设置

第一次跑完整模型时，Gurobi 提示模型不可行。排查了整整一天，最后发现是 SOC 约束写得有冲突——当 SOC 接近下限 0.2 时，储能其实已经没有足够的能量支撑最小放电功率的约束。也就是说，(SOC_{min}) 和 (P_{dis}^{max}) 之间存在隐性约束冲突：要求能放出最大功率，但电量不允许。

解决办法有两个：一是把最小放电功率约束从 (P_{dis}(t) \le P_{dis}^{max}) 改成 (P_{dis}(t) \le \min(P_{dis}^{max}, SOC(t) \cdot E_{rated}))，让最大放电功率跟随 SOC 变化；二是引入松弛变量和惩罚项，允许模型在极端情况下轻微违反 SOC 下限，对应一个高额惩罚成本。我最终采用了第二种方案——因为第一种方案引入了非线性项，会破坏 MILP 的线性结构。

惩罚项设置有个经验技巧：惩罚系数不能太大，否则它会在约束满足和惩罚成本之间制造数值病态（超大系数导致求解器内部数值精度问题）；但也不能太小，否则模型会频繁“借用”约束违反空间来降低成本。我最终取的是系统边际电价的 50 倍左右，既保证了约束优先级够高，又不至于引发数值问题。

6.2 滚动优化中的漂移效应

日内滚动优化跑久了会出现一个现象：实际执行的 SOC 轨迹与日前计划的 SOC 轨迹偏差越来越大，到第二天早上偏差能到 0.15 甚至 0.2。这个现象本质上是因为实时扰动不断累积，日内层每次只修正短期偏差，长期偏差被“遗忘”了。解决这个问题的标准做法是在日内层目标函数里加一条“SOC 轨迹跟踪项”，强制日内计划尽量靠近日前计划的 SOC 轨迹：

[ J_{track} = \lambda \cdot \sum_{t=1}^{T_{intra}} (SOC_{intra}(t) - SOC_{day}(k+t-1))^2 ]

我实测发现，这个跟踪项权重系数 (\lambda) 设为 100 左右效果最好。太大会让日内层完全变成“执行机”，失去应对预测偏差的灵活性；太小则漂移抑制不住。

6.3 求解精度设置与松弛容差

这里还有一个很多人会忽略的细节：Gurobi 默认的 MILP 求解精度是 (10^{-4}) 相对误差。在较大规模的调度模型中，这个精度会导致一些奇怪的“非物理”结果——比如储能同时充电和放电（数值上两个变量都不为0），或者可中断负荷状态变量在 0.9 附近而不是 1。这些现象不是模型写错了，是求解器的数值容差造成的。

解决办法是：在 Gurobi 设置中把 MIPGap 调整为 (10^{-6})（或者更保守的 (10^{-5})），同时在模型里显式添加充电放电互斥约束 (u_{ch} + u_{dis} \le 1)，把状态变量限定为严格 0/1。虽然计算时间略有增加（约 8%），但求解结果的物理可解释性大幅提升。

6.4 预测误差对整体调度效果的影响

最后测试了预测误差敏感性。我把光伏预测误差的标准差从 3% 调到 10%，发现系统总成本仅上升了 2.1%。这是一个令人惊喜的结果——说明三时间尺度框架对预测误差有很强的鲁棒性，日内修正和实时控制已经吸收了绝大部分不确定性。但储能等效循环次数却上升了 7.3%，因为在预测误差变大时，实时层会更频繁地调用储能来消除偏差。

如果你的实际项目里预测误差很大，建议在实时层增设一个“储能保护”逻辑：当 SOC 低于 0.3 时，实时层优先调用可中断负荷来消除偏差，把储能留作最后手段。这相当于给电池加了一个“自动保护罩”。

7. 完整运行流程与代码实践建议

7.1 从论文到代码的翻译思路

复现一篇 SCI 论文的调度模型，我建议你按这个顺序走，能省大量时间。

第一步，把论文里的数学模型公式先读懂，特别是目标函数中的每一项、约束条件中每一个不等式的物理含义。不要急着写代码，先抽出几个关键公式，在草稿纸上手推一遍量纲是否一致。比如 SOC 方程里的时间分辨率换算、容量衰减模型里的功率与能量换算，这些细节在论文里往往是一笔带过，但代码里错了就是错。

第二步，把论文模型格式化为标准数学表达式，明确决策变量、常数、目标函数、约束条件的完整列表。这一步骤推荐用 LaTeX 或者 Word 表格写清楚，方便后续对照代码检查。

第三步，先写一个最简单版本的模型（不含衰减、不含灵活性），跑通之后逐步增加复杂度。每增加一个模块，就跑一遍对比，确认结果变化符合直觉。我最开始直接照论文全量建模，模型不可行时连排查都无从下手。改为渐进式添加后，定位问题效率提升了不止一个量级。

7.2 工程部署时的数据接口建议

如果要把这套代码接到实际项目里，数据接口值得提前规划。我推荐的接口设计是用标准 CSV 或 Excel 导入预测数据和设备参数，输出决策结果也导出为标准表格，方便前后端对接。预测数据模块建议单独封装成函数，实际部署时替换成真实预测系统的输出即可。

调度指令下发方面，日前计划在每天 00:30 之前生成，下发到各终端执行；日内滚动每 15 分钟触发一次，指令通过标准通信协议下发；实时控制层建议部署在边缘计算节点上，保证 5 分钟级的响应延迟。

7.3 代码运行的硬件要求与依赖

运行环境方面，Matlab 2019b 及以上版本都可以，需要安装 YALMIP 工具包和 Gurobi 求解器。YALMIP 的安装非常简单，下载后添加到路径即可；Gurobi 需要申请学术许可证，官网直接申请，一般 1 小时内就能批下来。

如果手头没有 Gurobi，也可以先用 GLPK 或 CBC 这两个开源求解器顶替。但注意性能差异比较大——同样的模型，Gurobi 只需要 3 秒，CBC 可能要 30 秒，大规模场景下差距更明显。我建议有条件还是用 Gurobi，开发调试体验会好很多。

8. 复现完成后我的几点体会

整套代码从阅读论文到完全复现，我前后花了两周时间。回头总结，最核心的收获不在代码本身，而是对多时间尺度调度这个系统性工程的理解。每个时间尺度有它存在的物理意义，因为每种资源有不同的响应速度；每层之间的耦合方式决定了系统的稳定性与经济性；而每个参数的设置，背后都有着现实的工程考量。

特别想再强调一次储能容量衰减这件事。很多初始版本只把它当作电池管理系统的内部问题，实际上在调度层面就应该纳入考量。调度的每一次充放指令都在消耗电池寿命，如果优化模型里没有这个成本项，得到的“最优”方案在实际运行中往往既不优也不经济。这是我复现这篇论文最大的启发，也是我认为最值得迁移到其他项目的一个建模思路。

代码是我用标准格式写的，注释也比较全，有需要的可以在此基础上改你自己的算例。如果遇到模型不可行或者结果不符合预期的情况，优先检查三件事：SOC 方程里的时间系数有没有漏乘、功率和能量的单位是否一致、容量衰减项有没有进目标函数而非只进约束——这三处是我实战中最常出问题的地方，大概率也能覆盖你的情况。