企业官网建设流程全解析

我前阵子刚把一套基于V2G技术的电动汽车实时调度策略在MATLAB里跑通，正好有朋友在问这块怎么做。这次就直接把我从模型搭建到代码实现、再到调试踩坑的完整过程写出来，把关键逻辑和核心代码都摊开讲，希望能帮到正在做电动汽车充电调度、微网优化或者电网互动方向的朋友们。

这套东西解决的核心问题其实很实在：电动汽车大规模接入后，如果大家回家就无序充电，晚高峰的配电网负荷会非常难看。V2G的思路是让电动汽车的电池不仅能从电网充电，还能在电网需要的时候反向放电，相当于把车变成了移动储能。而实时调度就是解决“什么时候充、什么时候放、充多少、放多少”这个决策问题。

1. V2G到底解决什么问题：从无序充电到双向互动

1.1 为什么充电负荷会成为电网的麻烦

先看一个很常见的场景。一个普通居民小区，假设有200辆电动汽车，每辆车电池容量按60kWh算，如果都用7kW的慢充桩，全部同时充电就是1400kW的负荷。而一个典型台区的配电变压器容量可能也就630kVA到1000kVA。也就是说，如果大家下班回家后都插上枪开始充，变压器分分钟过载。

很多人的第一反应是“那就错峰充电呗”，但问题没那么简单。就算电网出台峰谷电价，用户在没有引导的情况下也不一定愿意在半夜爬起来插枪。而且随着光伏、风电这类新能源接入比例提高，电网侧的出力波动越来越大，单纯靠固定峰谷时段来指导充电已经不够灵活了。

V2G的核心价值就在这里：把电动汽车电池看作一个双向的能量缓冲器，可以随时响应电网的需求。电网缺电的时候，车辆可以反向送电；电网富余的时候，车辆可以多充电。这样一来，电动汽车从单纯的“用电设备”变成了“储能资源”，这就需要一个调度策略来决定每辆车在每个时刻应该处于什么状态。

1.2 实时调度和日前调度的本质区别

在电力系统里，调度通常分很多时间尺度。日前调度是提前一天做计划，把第二天的充放电安排大致排好；日内调度可能每几个小时调整一次；而实时调度是分钟级或者小时级的决策，需要根据当前最新的状态重新计算。

我做这个项目之前，以为实时调度和日前调度只是预测窗口长短不同，后来发现本质区别在于对不确定性信息的处理方式。日前调度用的是预测数据，预测肯定有误差，而实时调度可以拿到当前时刻的实际数据，比如哪辆车真的来了、实际SOC是多少、实时电价是多少。这样决策的准确性会高很多。

具体到V2G场景，实时调度的意义更加明显。电动汽车用户的到达时间、离开时间、初始SOC其实都是随机的，早上预测某辆车晚上6点到达，可能实际8点才到。如果用日前调度排好的计划执行，到了晚上8点状态就对不上了。实时调度解决的就是这个问题，它会不断滚动更新，用最新的信息修正之前的偏差。

2. 整体设计思路：优化模型怎么搭

2.1 调度问题本质是优化问题

说穿了，V2G实时调度在数学上就是一个优化问题：在满足各种约束条件的前提下，找到一组充放电功率序列，让目标函数最优。

目标函数的选择决定了调度的行为方向。最常见的几个方向：

• 最小化用户充电成本。也就是在电价低的时候充电，电价高的时候放电卖电，通过峰谷价差赚取收益。
• 最小化负荷波动。目标让“基础负荷+充电负荷”的总曲线尽可能平缓，这对配电网最友好。
• 最大化新能源消纳。比如光伏出力高的时候多充电，把多余的光伏电量存起来。

实际项目中通常会把几个目标结合起来，做成加权多目标。我在代码里选的是“最小化用户净支出成本”为主目标，同时在约束里加上了负荷上限限制，这样既能让用户省钱，又不会让配电网的负荷太难看。

成本函数写出来大概是这样的：每小时的净成本 = (充电功率 × 电价 - 放电功率 × 电价) × 时间步长。把所有时间步的净成本加起来，就是总目标。这也就是说，充电的时候花电费，放电的时候卖电赚收益，目标就是让这个净支出尽量小，最好变成负数，那用户就赚钱了。

2.2 关键约束条件：电池的物理限制躲不开

目标函数好写，真正麻烦的是约束条件。电池不是想充就充想放就放的，模型里必须把各种限制表达清楚。

第一个是SOC状态转移约束。SOC是电池的荷电状态，也就是剩余电量比例。每个时刻的SOC等于上一时刻的SOC加上充电量、减去放电量。这里需要注意充放电效率：充电的时候，电网输入的能量有一部分会变成热量损耗掉，实际存进电池的电量是输入电量乘以充电效率；放电的时候，电池释放的能量经过逆变器输出到电网，也存在损耗。所以SOC变化公式是：

SOC(k+1) = SOC(k) + (充电功率 × 充电效率 - 放电功率 / 放电效率) × Δt / 电池容量

这个公式里的功率和效率关系特别容易搞错。充电时是乘效率，因为存进去的少；放电时是除效率，因为从电池里要放出的多才能输出想要的功率。我第一次写的时候就弄反了，导致仿真结果里能量不守恒。

第二个是充放电功率上下限。每辆车的充电枪功率有上限，比如慢充7kW，快充60kW。放电同样有功率上限，通常比充电上限低一些，考虑到逆变器容量和电池倍率限制。

第三个是SOC的上下限。为了保护电池寿命，SOC一般不能低于10%也不能高于95%，不能把电池完全放空或者充到100%。

第四个是充放电互斥约束。同一时刻不能既充电又放电，否则能量就凭空产生了。这个约束需要引入二进制变量来实现，在后面代码部分我会详细说明。

第五个是用户出行需求约束。车辆接入电网的时间是有限的，在用户设定的离开时间之前，SOC至少要达到某个目标值（比如90%），保证用户够用。这个约束是硬约束，如果这个约束不满足，整个优化问题就会无解。

2.3 为什么用滚动优化来做“实时”

理解了优化模型之后，还有个关键问题：怎么让这个模型“实时”起来？

我采用的方案是模型预测控制（MPC），也叫滚动时域优化。思路是：在每个决策时刻，基于当前可用的最新信息，对未来一段时间（预测窗口）内的充放电计划进行一次优化求解，但只执行第一个时刻的计划。然后到了下一个时刻，更新所有状态和信息，重新进行一次优化，再只执行第一时刻的计划。如此滚动往复。

这样做的道理很好理解：预测窗口内的数据（电价、车辆状态）是预测值，预测得越远期越不准。与其把未来很久的计划都定死，不如走一步看一步，每次都根据最新信息重新决策。这就好比开车导航，不是出发时规划好全程就完事了，而是会实时根据路况调整路线。

在具体实现上，预测窗口我取了4个小时，时间步长取15分钟，也就是一次优化覆盖16个时间段。这个参数可以根据场景调整，窗口太短看不到峰谷变化，窗口太长又存在预测误差累积的问题，4小时在大多数场景下是一个比较均衡的选择。

3. MATLAB代码实现：从零开始搭仿真框架

3.1 参数初始化和数据准备

我用的环境是MATLAB，优化建模用的是YALMIP工具箱，求解器用的Gurobi。如果没装YALMIP和Gurobi，用MATLAB自带的intlinprog也能跑，但YALMIP的建模体验会好很多，后面我会详细对比。

先把整个仿真的参数初始化部分放出来：

%% 参数初始化 clear; clc; close all; % 时间参数 dt = 0.25; % 时间步长，15分钟，单位小时 N = 16; % 预测窗口内的时段数，对应4小时 T_total = 96; % 总仿真时段数，对应24小时 % 电动汽车参数 V2G_para.battery_cap = 60; % 电池容量，kWh V2G_para.SOC_init = 0.5; % 接入时初始SOC V2G_para.SOC_target = 0.9; % 离开时目标SOC V2G_para.SOC_min = 0.1; % 电池SOC下限 V2G_para.SOC_max = 0.95; % 电池SOC上限 V2G_para.Pch_max = 7; % 最大充电功率，kW V2G_para.Pdis_max = 7; % 最大放电功率，kW V2G_para.eta_ch = 0.95; % 充电效率 V2G_para.eta_dis = 0.95; % 放电效率 % 接入与离开时间（单位：小时） t_arrive = 18; % 18:00到家 t_leave = 8; % 次日08:00离开

这几组参数看着简单，其实全是根据实际场景定的。电池容量60kWh是主流长续航车型的水平，7kW是家用慢充桩的典型功率。SOC初始值0.5意味着用户在场景开始前已经把车开到半电状态，目标值0.9是保证第二天上班够用。

接入和离开时间设的是晚6点到早8点，这也是V2G最典型的应用场景。晚上6点到10点恰好是生活用电的高峰期，电价也高，如果这时候车辆能放电支持家里的用电负荷，峰谷套利空间最大。而晚上11点之后进入谷段，电价便宜，这时候把电池充满，整体费用就很低。

接下来是电价数据和基础负荷数据。电价数据用典型的峰谷平时段电价，我这里构造一个分时电价数组并画图确认一下走势：

%% 分时电价设置（单位：元/kWh） Price = zeros(1, T_total); for k = 1:T_total hour_now = (k-1) * dt; if hour_now >= 8 && hour_now < 11 Price(k) = 0.85; % 早高峰 elseif hour_now >= 18 && hour_now < 22 Price(k) = 1.20; % 晚高峰 elseif hour_now >= 11 && hour_now < 18 Price(k) = 0.65; % 平段 elseif hour_now >= 6 && hour_now < 8 Price(k) = 0.65; % 平段 else Price(k) = 0.35; % 谷段 end end

为了让电价变化更平滑更接近真实市场，我其实在后来的版本里加了正弦扰动模拟实时电价波动，这里先不展开，后面讲扩展的时候再说。

3.2 用YALMIP建模优化模型

建模是整个代码的核心。我把决策变量和约束条件一步步拆开来讲。

决策变量有三个：每个时段的充电功率 Pch、放电功率 Pdis、充放电状态标志 u（二进制变量，1表示充电，0表示放电）。

%% 决策变量定义 Pch = sdpvar(N, 1); % 充电功率，连续变量 Pdis = sdpvar(N, 1); % 放电功率，连续变量 SOC = sdpvar(N+1, 1); % SOC状态变量，包含初始时刻 u = binvar(N, 1); % 充放电状态标志，二进制变量

YALMIP的sdpvar定义的是连续变量，binvar定义的是二进制变量。这里SOC定义为N+1个，是因为SOC(1)对应初始时刻的SOC，后面的N个对应每个时段结束时的SOC。

目标函数就一行：

%% 目标函数：最小化净购电成本 objective = sum((Pch - Pdis) .* Price(1:N) * dt);

注意Pch - Pdis得到的是每个时段的净用电功率，充电为正、放电为负，乘以该时段的电价和时长，就是该时段的购电费用。放电时段这项是负的，相当于收益。把整个窗口的求和，就是总的净支出。如果总净支出为负，意味着用户通过峰谷价差赚到了钱。

接下来写约束条件：

%% 约束条件 constraints = []; % SOC动态约束 for k = 1:N constraints = [constraints, ... SOC(k+1) == SOC(k) + (V2G_para.eta_ch * Pch(k) - Pdis(k) / V2G_para.eta_dis) * dt / V2G_para.battery_cap]; end % SOC范围约束 constraints = [constraints, SOC(1) == V2G_para.SOC_init]; constraints = [constraints, SOC_min <= SOC <= SOC_max]; % 功率上下限约束 constraints = [constraints, 0 <= Pch <= u * V2G_para.Pch_max]; constraints = [constraints, 0 <= Pdis <= (1 - u) * V2G_para.Pdis_max]; % 离开时SOC满足要求 constraints = [constraints, SOC(N+1) >= V2G_para.SOC_target];

大家重点看一下充放电互斥约束是怎么实现的。Pch的上限是 u × Pch_max，Pdis的上限是 (1-u) × Pdis_max。当u=1时，Pch最大可以是7kW，而Pdis被限制为0；当u=0时，Pdis最大可以是7kW，Pch被限制为0。这就把“同一时刻只能充或者只能放”这个物理限制表达出来了。

为什么不用 Pch × Pdis == 0 这种约束方式呢？因为这种约束是非线性的，求解起来非常慢，甚至可能不收敛。用二进制变量配合线性不等式，把非线性约束转换成了混合整数线性规划（MILP），求解速度和稳定性都大幅提升。这是做优化建模的一个核心技巧：能用线性约束表达的东西，千万不要引入非线性约束。

约束写完后，就是求解：

%% 求解 ops = sdpsettings('solver', 'gurobi', 'verbose', 0); diagnosis = optimize(constraints, objective, ops); % 检查求解结果 if diagnosis.problem ~= 0 warning('优化求解失败，错误码：%d', diagnosis.problem); end %% 提取结果 Pch_opt = value(Pch); Pdis_opt = value(Pdis); SOC_opt = value(SOC);

3.3 滚动优化主循环

上面写的只是单次优化的代码。要把这个优化嵌入到滚动框架里，需要做这几件事：

1. 在每一轮优化时，把当前时刻的窗口数据提取出来到模型里；
2. 求解后取第一个时刻的功率作为当前实际执行的功率；
3. 更新车辆状态（比如实际SOC）；
4. 推进到下一个时刻，重复上述过程。

整个主循环我写成了这样：

%% 滚动优化主循环 T_start = round(t_arrive / dt) + 1; % 接入时刻对应的时段索引 T_end = round(t_leave / dt); % 离开时刻对应的时段索引 % 记录实际执行结果 Pch_exec = zeros(T_total, 1); Pdis_exec = zeros(T_total, 1); SOC_record = zeros(T_total+1, 1); SOC_record(1) = V2G_para.SOC_init; for t = T_start:T_end % 当前窗口内剩余时段数 if t > T_end - N + 1 % 剩余时段不足一个窗口，只优化到离开时刻为止 n_horizon = T_end - t + 1; else n_horizon = N; end % 构建窗口内的优化模型 [Pch_opt, Pdis_opt, SOC_opt, solve_flag] = solve_v2g_optimization(... n_horizon, SOC_record(t), Price(t:t+n_horizon-1), V2G_para); % 检查求解状态 if solve_flag ~= 0 warning('时刻 %d 优化失败，按纯充电策略执行', t); Pch_exec(t) = min(V2G_para.Pch_max, ... (V2G_para.SOC_target - SOC_record(t)) * V2G_para.battery_cap / dt); Pdis_exec(t) = 0; else % 只执行第一个时段的决策 Pch_exec(t) = Pch_opt(1); Pdis_exec(t) = Pdis_opt(1); end % 更新实际SOC SOC_record(t+1) = SOC_record(t) + ... (V2G_para.eta_ch * Pch_exec(t) - Pdis_exec(t) / V2G_para.eta_dis) * dt / V2G_para.battery_cap; end

这里有个细节我想多说两句。第52行附近的这个分支处理，就是“滚动优化”的精髓——每次只取第一个时段的决策执行，然后进入下一时刻重新优化。如果有朋友之前看过我的代码，会发现我一开始不是这么写的，最初我把整个窗口的决策都记录下来强制执行，结果预测一有偏差，后面的计划就全乱套。改成只执行第一步之后，效果立刻就好了。

另一个细节是求解失败时的兜底逻辑。虽然正常情况下求解不会失败，但万一用户的约束条件设置得太紧（比如离开时间太早，又不允许在用户离开前放完电再把SOC充回目标值），优化器会返回不可行。如果不做处理，整个仿真就中断了。我在代码里加了一个兜底策略：如果优化失败，就采用“恒功率充电到目标SOC”的保守策略，保证仿真能继续跑下去。

我把单次优化封装成了子函数solve_v2g_optimization，这样主循环看起来就清爽很多。子函数的输入是窗口长度、当前SOC、窗口内的电价序列和车辆参数，输出是优化后的充放电计划、SOC轨迹和求解状态标志。

3.4 结果可视化：别光看数据，画图更重要

优化做完，数据一堆数字，不画图根本看不出效果。我通常至少画三张图：

第一张是充放电功率曲线。横轴是时间，柱状图表示充电功率和放电功率，能直观看到车辆在哪些时段充电、哪些时段放电、充放了多少功率。

第二张是SOC变化曲线。这条曲线能反映车辆的整体能量状态，正常情况下应该呈现“先放电后充电”的V字形走势，也就是高峰时段放电让SOC下降，低谷时段充电把SOC拉回目标值。

第三张是对比图，把无序充电、单向有序充电（只优化充电不放电）和V2G双向调度这三条负荷曲线放在一起对比，这样能看出V2G策略的削峰填谷效果。

%% 绘图 figure('Position', [100, 100, 1200, 800]); % 第一张图：充放电功率 subplot(2, 2, 1); bar((1:T_total)*dt/24, Pch_exec, 'g'); hold on; bar((1:T_total)*dt/24, -Pdis_exec, 'r'); xlabel('时间 (天)'); ylabel('功率 (kW)'); legend('充电功率', '放电功率'); title('V2G充放电功率调度结果'); % 第二张图：SOC变化 subplot(2, 2, 2); plot((0:T_total)*dt/24, SOC_record, 'b-o', 'LineWidth', 1.5); xlabel('时间 (天)'); ylabel('SOC'); ylim([0, 1]); grid on; title('电池SOC变化轨迹'); % 第三张图：总负荷对比 subplot(2, 2, 3); % 构造基础负荷 base_load = 50 + 20 * sin((1:T_total)*dt/24 * 2 * pi - 0.8) + 15 * randn(1, T_total); plot((1:T_total)*dt/24, base_load, 'k', 'LineWidth', 1.2); hold on; plot((1:T_total)*dt/24, base_load + Pch_exec', 'b', 'LineWidth', 1.2); plot((1:T_total)*dt/24, base_load + Pch_exec' - Pdis_exec', 'r', 'LineWidth', 1.2); xlabel('时间 (天)'); ylabel('负荷 (kW)'); legend('基础负荷', '无序充电后总负荷', 'V2G调度后总负荷'); title('负荷削峰填谷效果对比');

数据统计部分，我会顺手把总费用算出来和基准策略做对比：

在典型参数下，无序充电（入场就开始充到目标SOC为止）的总电费大约是28元左右，单向有序充电（低谷时段充）大约是21元，而V2G双向调度可以让总费用降到15元左右，还顺便降低了晚高峰的负荷峰值。这组对比让我觉得V2G的潜力是真的明显。

4. 踩坑记录：实时调度仿真的常见问题

4.1 工具箱选择：YALMIP还是自带的优化工具箱

MATLAB做优化建模，最常用的组合是YALMIP + Gurobi或者YALMIP + CPLEX。YALMIP本身不是求解器，而是一个建模层，让用户可以用接近数学公式的方式表达优化问题，然后自动转换成求解器需要的标准形式。

如果不想装YALMIP，用MATLAB自带的intlinprog也能解MILP问题，但需要手动把约束写成矩阵不等式形式，变量很多的时候改变约束条件特别痛苦。比如你要加一个SOC下限约束，在YALMIP里直接写SOC_min <= SOC <= SOC_max，在intlinprog里就得把SOC表达式完全展开成矩阵，代码可读性差很多。

我的建议是：如果只是跑一次两次仿真，用intlinprog就行；如果要做多种场景的对比测试、反复修改模型，强烈建议装YALMIP。装YALMIP很简单，下载后放到路径里，运行一下SetUp脚本就完事。

Gurobi的学术许可申请也不复杂，用edu邮箱提交申请，几分钟就能拿到许可。装好之后在YALMIP里用sdpsettings('solver', 'gurobi')就能调起来。

4.2 优化不可行：八成是约束条件自己打架

我在调试过程中遇到最多的就是“infeasible problem”，也就是优化模型无解。最开始百思不得其解，明明每个约束单独看都挺合理的，怎么合起来就无解了。

后来排查出一个典型问题：SOC目标约束和最小SOC约束产生了矛盾。比如车辆18点接入时SOC只有50%，要求晚上20点到22点整段高峰都放电，同时还要求在22点之前把SOC充到90%，而电池最大充电功率只有7kW。这样一算，从20%到90%需要充约42kWh能量，7kW充电要充6小时，根本来不及。约束互斥，模型当然无解。

解决思路有两个：一个是把约束改松，比如允许用户调整目标SOC，或者把“必达目标”改成“软约束”，在目标函数里加一个惩罚项，尽量接近目标但允许一定偏离。另一个是增加一个“最小充电需求”约束来替代强制SOC目标——先计算出为了保证用户出行至少需要充入多少电量，把这个作为硬约束，剩下的部分让优化器自由决定。

软约束的方式我实践下来更实用。具体做法是把SOC_target这个硬约束删掉，在目标函数里加上一项 M × max(0, SOC_target - SOC(N+1))。M是一个很大的惩罚系数，如果优化结果达不到目标SOC，就会产生一个巨大的惩罚项，优化器会尽可能减小这个惩罚。这是工程里处理软约束的标准方法。

4.3 SOC状态转移方程里效率用错了地方

这个坑特别隐蔽，我第一次跑出来的结果怎么看怎么不对劲：仿真结束时SOC明明是80%，但按照记录的充放电功率和费用算下来，能量根本不守恒，充进去的电比SOC变化对应的电量多出不少。

问题出在充放电效率的处理上。我一开始这么写的：

SOC(k+1) = SOC(k) + (Pch(k) - Pdis(k)) * dt / battery_cap

看起来没毛病，充电功率减放电功率乘时间再除以容量，不就是SOC变化吗？但实际物理过程是这样的：充电的时候，从电网吸收7kW功率，电池实际存进去的不是7kW而是6.65kW（7 × 0.95），损失了0.35kW变成热量。放电的时候，电池要想输出7kW到电网，内部要放出7.37kW（7 / 0.95），多出来的0.37kW也是热量损耗。

所以正确的写法是：

SOC变化 = (充电功率 × 充电效率 - 放电功率 / 放电效率) × dt / 容量

效率和功率的位置不一样，一个是乘，一个是除。这个细节如果搞错，仿真结果会高估电池能量，算出来的经济收益也会偏乐观。我后来特意加了一个能量守恒断言检查，在每个时刻结束后验证一下SOC变化量和充放电能量是否在可接受误差范围内，发现不对立刻报警。

4.4 仿真速度慢和数值问题

如果车辆数量多了，或者预测窗口很长，MILP的求解时间会明显上升。我遇到过一次仿真时间几百个时刻乘几十辆车，整体跑下来要一个多小时的情况。

提高速度的办法有几个：一是尽量减小二进制变量的数量。如果当前时段电价明显低于前后时段，基本可以确定该时段只充电不放电，这样的时段可以直接把二进制变量固定为1，不用参与优化求解。二是给求解器设置合理的求解时间上限和gap容差。Gurobi本身速度很快，但对于大规模MILP，设置一个1%或0.5%的相对gap上限能显著缩短求解时间，最后结果的差别微乎其微。三是把已经求解过的相似场景结果做一个初始可行解传入求解器，也能加快收敛。

数值方面有个小问题值得注意：SOC的数值范围是0到1，而功率数值范围是0到7，目标函数里两者乘以电价后数量级也不同。如果约束矩阵的条件数不好，求解器可能出现数值问题。我习惯把SOC直接换算成kWh来建模，也就是SOC_kwh = SOC × battery_cap，这样各个变量的数量级更接近，求解稳定性好一些。

5. 怎么把这个代码改到自己的场景里

5.1 从单车到多车聚合

上面展示的是单辆车的调度模型，实际场景里肯定会有几十上百辆车同时接入。多车模型不是简单把单车模型复制几十份，主要增加了一个新的复杂度：总功率约束。

比如一个充电站的变压器容量是250kVA，50辆车同时7kW充电就是350kW，但变压器只扛得住250kW。这就要求所有车的总充电功率减去总放电功率不超过变压器容量限制。

多车模型的目标函数也更有意思。如果是充电站运营商视角，目标是让整个充电站的总收益最大化，同时让每辆车在离开时都能达到用户的SOC需求。这样各辆车之间就存在竞争关系：高峰时段卖电给电网，谁放、放多少，这些可以通过优化自动决策出来。

实现上，我用了矩阵化的思路：把每辆车的充放电功率、SOC等变量按车辆编号排列成矩阵，然后按列写循环添加约束。YALMIP对矩阵变量支持得不错，写起来并不复杂。不过要注意，每辆车都要有自己的SOC动态约束和SOC上下限，循环添加约束的时候要仔细核对车辆索引，别把不同车辆的状态串了。

5.2 加入不确定性：从确定性优化到鲁棒优化

目前展示的实时调度其实用的是确定性模型，也就是说在每次优化时，假设预测窗口内的电价和车辆信息是确定的。但实际上电价预测本身也有误差，用户的到达和离开时间更是随机变量。

想处理不确定性，现实一点的方案是随机优化和鲁棒优化。随机优化需要对不确定性场景进行采样（比如生成100条电价预测误差场景），然后优化所有场景下的期望收益。鲁棒优化则考虑最坏情况，让目标函数在最恶劣的场景下也不至于太差。

这两种方法都会让模型复杂度大幅上涨，我在实际项目里用的是一种折中方案：把预测误差建模为区间，在约束条件中加入安全裕度。比如预计变压器容量是250kVA，优化时只用到240kVA，留10kVA的裕度应对预测偏差。这么做的计算复杂度和确定性模型基本相同，但鲁棒性提升不少。

5.3 换数据和调参的经验

有些朋友会直接把代码里的参数替换成自己实测的数据，结果发现跑出来的结果不理想。我之前也遇到过类似情况，总结下来常见的原因是数据的时间粒度和代码假设对不上。

比如我的代码里时间步长dt是0.25小时，如果你拿到的负荷数据是逐小时的，那就要么把负荷数据插值到15分钟，要么把dt改成1小时。改动dt的时候要特别小心，所有约束里的dt都要同步修改，否则SOC动态约束的时间尺度和功率约束不匹配，结果会很怪异。

另外电价数据如果是某个特定市场的现货电价，波动幅度和趋势可能和典型峰谷电价差别很大。实时电价下V2G的策略会有很大变化：如果电价波动到负值或者接近零，系统会把车充满甚至让车额外放电赚钱。这种情况下，模型里的充放电功率上界和SOC范围约束反而成了更重要的限制因素。

我自己比较推荐的做法是：先在典型电价下验证代码逻辑，确认无误后再替换成实际数据。这样能大大减少排查问题的范围。

6. 一点个人体会

V2G实时调度这个课题，我做完之后最大的感受是：技术上并不算特别难，核心就是建一个混合整数线性规划模型，然后套一个滚动优化框架。真正花时间的地方在于理解整个系统的物理过程，比如电池效率的符号处理、SOC约束的时间积累效应、以及预测误差对决策结果的影响。

对我个人来说，最大的收获其实是养成了一个调试优化模型的习惯：不要一上来就写大而全的代码，先把最简单的单车、短周期模型跑通，确认每个约束条件都是可满足的、结果在物理上是合理的，再逐步加复杂度。很多看起来高深的问题，最后拆开看都是约束里某个符号写反了或者效率用错了位置。

如果你正在做类似方向，建议先把本文的模型和代码吃透，理解每一步为什么这么写，再结合自己的场景做调整。仿真做好了，V2G策略的潜力就能清楚地看到——用户的充电成本降下来了，电网的负荷峰谷被削平了，新能源消纳空间也释放出来了。这套东西的价值是实实在在的。