企业官网建设流程全解析

做电力调度相关工作的朋友应该都有体会：晚上看负荷曲线，最不想看到的就是“晚高峰上又叠了一个充电高峰”。我最早接触这个课题，是在处理某地区配电网负荷分析时，发现电动车渗透率上来之后，19点到21点的峰段被明显抬升，而凌晨3点到5点的谷段几乎没人用电。浪费和紧张同时存在，这就是削峰填谷要解决的问题。

这篇博文完整梳理了一套基于削峰填谷的电动汽车多目标优化调度策略，并给出Matlab代码实现思路。它做的事情可以用一句话概括：在已知基础负荷、峰谷电价、每辆车的充电需求和可充电时间窗的前提下，通过优化每辆车每个时段的充放电功率，达到“电网负荷曲线更平、用户充电费用更低、电池寿命折损更小”三个目标之间的平衡。无论你是做电力系统方向的学生、刚入门微电网调度的工程师，还是想自己复现一个多目标优化项目的开发者，这篇内容都能帮你省下大量翻文献和调bug的时间。

1. 为什么要做削峰填谷：电动汽车充电与电网负荷的错位矛盾

1.1 从一条日负荷曲线看峰谷差的代价

先看一条典型的冬季日负荷曲线：凌晨4点前后是全天最低点，大概3000 kW，晚上19点到21点出现晚高峰，可以冲到5200 kW左右，峰谷差率算下来大约是42%。这个数字意味着什么？意味着配电网、变电站、线路都要按5200 kW这个“最坏情况”来配置容量，但一天里真正用到这么高负荷的时间其实只有两三个小时，剩下大部分时间里设备都在“大材小用”。

这就是峰谷差的核心代价：电力系统是按峰值投资的，却按平均值运行。为了顶住这一两个小时的尖峰，调度侧要投入成本更高的调峰机组，或者依赖抽水蓄能这类灵活性资源；而谷段机组利用小时数低，整体运行效率也跟着被拖累。对配电网来说，峰谷差越大，变压器和线路的重载时间越长，寿命折损和故障概率都会上升。所以“削峰填谷”一直是电网运行里的老话题，只不过以前调度的对象是火电机组，现在多了一个新的可调对象——电动汽车。

1.2 电动汽车充电需求的天生弹性

电动汽车和冰箱、空调这类刚性负荷最大的不同在于：它的充电需求在时间上是高度可平移的。一辆车晚上18点插上充电枪，用户真正在乎的往往是“第二天早上出门时电量够不够”，而不是“18点01分必须充到80%”。这个“只在乎终态、不在乎过程”的特性，就是调度可以发挥的空间。

进一步拆解，一辆电动汽车的充电需求可以用三个要素描述：一是可充电时间窗，也就是从接入电网到离开电网的这段时间；二是电量需求，由初始SOC和目标SOC决定；三是功率上限，交流慢充一般是7 kW，直流快充可以到60 kW甚至更高。只要在时间窗内、功率上限以内，把充电需求安排在哪个时段，对用户来说几乎没有体感差异。这也是为什么学术界和工程界都把它叫做“柔性负荷”——它不像数据中心那样不能停电，也不像工厂产线那样必须连续用电，调节空间非常大。

如果车辆支持V2G（车到网）双向充放电，那就更进了一步：它不只是可以“晚点充电”，还可以在晚高峰时段把电池里的电反向送回电网，相当于一台移动的小型储能。这等于把“削峰”和“填谷”两件事都交给了同一批车来干。

1.3 无序充电的连锁反应，以及“分时电价不是万能药”

那如果什么都不做，让车主到家就插枪、满功率开充，会发生什么？假设一个小区有100辆电动车，每辆车到家时间是18点到21点之间，且大部分集中在19点前后。这批车同时以7 kW功率充电，光这一个小区就会多出约500 kW的负荷，而且恰好叠加在系统晚高峰上，形成所谓的“峰上加峰”。

后果是连锁的：配电变压器负载率飙升，低压线路末端电压被压下去，严重的时候会触发开关保护；更隐蔽的问题是设备长期重载会加速老化，这部分成本最终还是会摊到所有用户头上。所以很多地区虽然推广了分时电价，但如果缺少有序调度，高峰期的问题依然存在。

分时电价能解决一部分问题，却解决不了全部。原因在于：当谷段电价在22点开始生效时，所有车主都会“理性地”把充电启动时间设在22点整，结果就是在23点到凌晨1点之间重新造出一个新的小高峰。这个现象在工程上有个形象的叫法——“峰谷迁移，谷中造峰”。电价信号只能引导大家往低价时段挪，却没办法协调“挪完之后大家别挤在一起”。要解决这个协调问题，就必须引入集中式或分布式的优化调度，给每辆车分配一个具体的充电时段和功率。这正是本文这套多目标模型要做的事。

2. 多目标调度模型：把电网、用户、电池三方诉求写进数学公式

2.1 目标函数一：最小化负荷方差，让曲线“压峰填谷”

削峰填谷最直观的数学表达，就是让“叠加了电动汽车充电负荷之后的总负荷曲线”尽可能平坦。常用做法是最小化总负荷的方差：

min f1 = Σᵗ ( P_load(t) + Σₙ [P_ch,n(t) − P_dis,n(t)] − P_avg )²

其中P_load(t)是t时段的基础负荷，P_ch,n(t)和P_dis,n(t)分别是第n辆车的充电和放电功率，P_avg是整个调度周期内总负荷的平均值。为什么选方差而不是直接选“峰谷差”？因为方差把整条曲线的波动都纳入了惩罚，优化结果会更平滑；而单纯缩小峰谷差可能出现“峰值虽然降了，但曲线在别的地方出现锯齿状波动”的情况。实际项目里也可以两个指标都算出来，方差做优化目标，峰谷差率做结果评价指标，二者搭配使用。

我个人的体会是：目标函数选方差还有一个好处，它对“平均负荷”这个量非常敏感，而平均负荷在我们这个模型里几乎是常数（总充电电量基本由用户需求决定），所以方差最小化本质上就是在压制曲线的波动幅度。数学性质上它是个凸二次函数，对后面选求解器非常友好。

2.2 目标函数二：最小化用户充电费用

第二个目标站在用户角度：在分时电价机制下，同样的电量，放在谷段充和在峰段充，电费能差出两三倍。以一组典型电价为例：峰段1.0元/kWh、平段0.6元/kWh、谷段0.35元/kWh，一辆车充50度电，峰段充要花50元，谷段充只要17.5元。这笔账用户自己也会算，但问题在于“每个人都会算”恰恰导致了谷段拥堵。

模型里把这个目标写成：

min f2 = Σₜ price(t) · [ Σₙ P_ch,n(t) − Σₙ P_dis,n(t) ] · Δt

注意放电功率前面是减号，意思是用户在峰段放电可以获得收入，相当于把电“卖”回给电网，用来抵扣自己的充电成本。这样处理之后，V2G行为在用户侧就有了经济动力——只要放电收益高于电池折损成本，用户就愿意在峰段放电、在谷段补电。

2.3 目标函数三：最小化电池寿命折损

第三个目标是对V2G行为的“刹车”。锂电池的循环寿命和充放电深度、吞吐电量强相关，如果模型里只看电网和用户两个目标，优化器会倾向于让电池拼命放电：峰段放出去、谷段充回来，一天两个循环，电池寿命快速衰减。这种结果对电网短期好看，长期却是“杀鸡取卵”。

工程上常用简化的线性折损模型来描述这个成本：

min f3 = c_bat · Σₜ Σₙ [ P_ch,n(t) + P_dis,n(t) ] · Δt

即电池折损成本与总吞吐电量（充入能量 + 放出能量）成正比，c_bat是单位吞吐电量的折损成本，单位是元/kWh。我仿真时一般取0.12～0.2元/kWh这个范围，这个数字大致对应“按电池全生命周期总吞吐量估算的折旧摊还”。关于c_bat怎么标定、取大取小有什么后果，后面第5章会专门展开讲，这里先记住它是个“成本系数”就够了。

2.4 约束条件逐个梳理：SOC递推、功率边界、时间窗、容量上限

目标函数定好了，约束条件才是真正决定模型“像不像现实”的部分。一个完整的单时段、多车辆调度模型，至少要有下面这几类约束：

SOC动态递推是整个模型的核心，它把每一辆车的“历史电量”和“当前充放行为”串起来。这里有个容易被忽略的细节：放电时能量从电池流到电网，中间经过电池放电效率ηd和逆变器效率，所以实际放出的功率要除以效率，也就是P_dis/ηd才是电池侧的真实出力。效率参数要不要分方向设，很多论文写得比较含糊，但你写代码时一定要分开，否则放电过程的能量守恒算出来是错的。

还有一个值得注意的点：SOC_req这个约束非常关键，它是“用户利益”在约束层面的底线。如果去掉它，优化器为了填谷可能让某些车一直充不满电，用户早上出门发现电量不够，模型再漂亮也没法落地。

2.5 三个目标互相打架：加权法与帕累托折中

三个目标放在一起，本质上是在三个方向上拉扯：

• 只最小化负荷方差，会让所有车在峰段放电、谷段充电，电池折损飙高，用户的电池“白打工”；
• 只最小化用户费用，会让所有车挤在谷段充电，谷段重新堆出高峰，削峰填谷变成“削峰造峰”；
• 只最小化电池折损，最激进的方案是“完全不调度”，回到无序充电，一切免谈。

所以不能只求某一个目标的最优，而是要求一组“折中解”。最常用的处理方法是加权求和法：

min F = w1·f1/f1* + w2·f2/f2* + w3·f3/f3*

其中f1*、f2*、f3*分别是每个目标单独优化时的最优值，用于归一化；w1、w2、w3是权重。改变权重组合，就能得到一组帕累托前沿上的解，比如w1大就偏向电网利益，w2大就偏向用户利益。需要提醒的是，归一化这一步不是可选项而是必选项——三个目标的量纲完全不一样，负荷方差是kW²量级（动辄几十万），充电费用是几十到几百元，电池折损成本更小，不归一化的话，小权重目标会被大数值目标直接“淹没”，这一点在第5章会细说。

如果想做更完整的帕累托分析，可以用NSGA-II这类多目标进化算法，一次性求出整个解集；但日常研究和工程验证，加权法加权重扫描已经足够，而且求解稳定、速度快、可解释性强。

3. Matlab代码实现：从求解器选型到模块化仿真框架

3.1 先选求解路线：精确求解器还是智能优化算法

拿到这个模型，第一步不是写代码，而是先回答一个问题：用什么算法来解？这个选择基本决定了后续代码的写法和求解速度。

这个模型在连续变量、线性约束、二次方差目标的设定下，是一个带约束的二次规划（QP）问题；如果再引入“同一时段不能同时充放电”这种互斥逻辑，就会变成混合整数二次规划（MIQP）。对这种问题，成熟的做法是用YALMIP建模，后台调CPLEX或Gurobi这类商业求解器求解，也可以用Matlab自带的intlinprog（线性化后）或quadprog来解。优点是解的质量有保证，速度快，适合做精确的仿真验证。

如果模型里加入了非线性效率曲线、电池老化非线性项，或者你想直接研究帕累托前沿，那就更适合用智能优化算法，比如粒子群（PSO）、遗传算法（GA）、NSGA-II。这类方法的优点是不挑模型形态，缺点是每次求解结果有随机性、需要多次运行取统计，而且在大规模场景下收敛速度会明显下降。

我的建议是：能用凸模型就不用黑箱进化算法。实际项目里我通常分两步走——先用凸优化＋加权法快速得到一组基准解，验证约束和参数设置没问题；再用NSGA-II去补充多目标分析。这样既保证了核心结果的可靠性，又能给论文或报告提供帕累托前沿图。

3.2 工程化代码结构：按“数据-建模-求解-画图”分层

很多新手写优化代码喜欢把所有的内容堆进一个脚本里，跑通一次就完事。但只要你需要换一组参数、换一个场景、或者扫一遍权重做敏感性分析，这种“大脚本”就会变得非常痛苦。我建议从一开始就按“数据、建模、求解、画图”四层去组织文件。

一个可参考的Matlab工程结构是这样的：

ev_scheduling/ ├── main.m % 主流程：数据准备、调用建模与求解、汇总结果 ├── load_case_data.m % 设置基础负荷曲线、电价、变压器容量 ├── generate_ev_scenarios.m % 生成车辆样本：到达/离开时刻、初始SOC、目标SOC ├── build_optimization_model.m % 用YALMIP构建变量、约束和目标 ├── run_solver.m % 调求解器，返回最优解与求解状态 ├── plot_results.m % 画负荷曲线、SOC曲线、费用对比 └── evaluate_metrics.m % 计算峰谷差率、方差削减率、平均费用等指标

main.m只管流程编排，不懂模型细节；build_optimization_model.m只负责把数学问题翻译成YALMIP语句，不关心数据从哪来；plot_results.m只负责可视化。这样每层都可以独立替换——今天用100辆车，明天换300辆，只改generate_ev_scenarios.m的参数；今天用加权法，明天换NSGA-II，只动main.m里对求解器的调用方式。

3.3 核心代码片段：YALMIP建模的实际写法

下面这段代码是build_optimization_model.m的核心逻辑演示，我做了简化，便于你理解整体结构。注意这里的写法是基于常见实践的参考实现，具体到你自己的项目，需要把车辆参数改成按样本逐个赋值。

%% 基础参数（示意） T = 24; % 调度时段数，1小时分辨率 N = 100; % 车辆数 E_B = 60; % 电池容量 kWh P_ch_max = 7; % 最大充电功率 kW P_dis_max = 7; % 最大放电功率 kW eta_c = 0.95; % 充电效率 eta_d = 0.95; % 放电效率 SOC_min = 0.2; % 电池SOC下限 SOC_max = 0.9; % 电池SOC上限 %% 定义优化变量 P_ch = sdpvar(T, N, 'full'); % 充电功率 P_dis = sdpvar(T, N, 'full'); % 放电功率 SOC = sdpvar(T + 1, N, 'full'); % SOC状态，时间轴比功率多1个点 %% 构建约束 Constraints = []; for n = 1:N % SOC递推约束 for t = 1:T Constraints = [Constraints, ... SOC(t+1, n) == SOC(t, n) + ... (eta_c * P_ch(t, n) - P_dis(t, n) / eta_d) * 1 / E_B]; end % 功率边界与SOC边界 for t = 1:T Constraints = [Constraints, ... 0 <= P_ch(t, n) <= P_ch_max, ... 0 <= P_dis(t, n) <= P_dis_max, ... SOC_min <= SOC(t, n) <= SOC_max]; end % 时间窗外不可充放电（t_arr/t_dep为车辆接入与离开时段） for t = 1:T if t < t_arr(n) || t > t_dep(n) Constraints = [Constraints, P_ch(t, n) == 0, P_dis(t, n) == 0]; end end % 离网电量约束 Constraints = [Constraints, SOC(t_dep(n), n) >= SOC_req(n)]; end % 配电容量约束（可选） P_net = P_base + sum(P_ch - P_dis, 2); for t = 1:T Constraints = [Constraints, P_net(t) <= P_limit]; end %% 目标函数（三个目标加权，归一化系数norm1/norm2/norm3事先算好） P_net_all = P_base + sum(P_ch - P_dis, 2); obj_var = sum((P_net_all - mean(P_net_all)).^2); % 电网方差 obj_cost = sum(sum(P_ch .* price * 1 - P_dis .* price * 1)); % 用户费用 obj_bat = sum(sum(P_ch + P_dis)) * c_bat; % 电池折损 obj = w1 * obj_var / norm1 + w2 * obj_cost / norm2 + w3 * obj_bat / norm3; %% 求解 ops = sdpsettings('solver', 'cplex', 'verbose', 2); sol = optimize(Constraints, obj, ops); if sol.problem == 0 P_ch_opt = value(P_ch); P_dis_opt = value(P_dis); SOC_opt = value(SOC); else disp(['求解失败：', sol.info]); end

这段代码只有几十行，但麻雀虽小五脏俱全。你复现的时候重点检查三个地方：一是sdpvar的维度是不是T×N，二是时间窗约束里“t_arr/t_dep”的边界，三是price矩阵的维度要和P_ch对齐。这三个位置是我见过最容易出错的，报错信息五花八门，但根源基本都是“矩阵维度对不上”。

如果不用YALMIP，也可以直接用Matlab的optimproblem（基于问题的优化）接口，把约束和目标翻译成optimvar、optimconstr的写法，调用intlinprog或quadprog求解。功能稍弱一些，但可以避免额外配环境。

4. 仿真案例与结果解读：三组对照实验验证调度效果

4.1 典型参数设置：负荷、电价、EV出行数据

仿真案例的价值在于“可复现”。我下面用的是一组我自己构造的典型参数，不是某个电网的真实数据，但量级上非常接近实际工程场景，你可以直接拿来当初始值跑。

基础负荷取24点曲线，凌晨低谷3000 kW，晚高峰5200 kW，用一条带双峰的曲线插值生成。电价按三段式设置：峰段08:00-11:00、18:00-21:00为1.0元/kWh；平段11:00-18:00、21:00-22:00为0.6元/kWh；谷段22:00-08:00为0.35元/kWh。变压器容量上限设为5600 kW，给基础负荷留10%左右的裕量。

车辆参数：100辆电动车，电池容量60 kWh，交流充电桩额定功率7 kW，放电功率同样按7 kW算。每辆车的接入时间按正态分布采样，均值19:00、标准差1.5小时，截断在17:00-23:00之间；离开时间集中在次日07:00左右。初始SOC在0.2～0.5之间均匀分布，离网时目标SOC不低于0.3（如果用户要求充满，就把SOC_req设为0.9）。

4.2 三组场景对比：无序充电 vs 单目标削峰 vs 多目标调度

我做了三组仿真对照，分别对应三种“调度观”：

• 场景A：无序充电。车辆到家立即以7 kW功率充电，充满即停，不参与任何优化；
• 场景B：单目标削峰。只优化负荷方差这一个目标，不关心用户费用和电池损耗；
• 场景C：多目标加权调度。权重取w1=0.5、w2=0.3、w3=0.2，三个目标一起优化。

三组实验跑完之后，把关键指标汇总起来看，差异非常明显：

单目标削峰的“削峰填谷”效果确实最好，峰谷差率从43.5%压到19.2%，但代价是车辆在峰段大量放电、谷段大量充电，电池吞吐电量被拉得很高。多目标调度为了兼顾电池寿命，主动减少了一部分V2G行为，峰谷差率只降到26.8%，但用户费用最低，电池折损也温和得多。这就是三个目标互相博弈的最直观体现——所谓“最优调度”，本质上是在三个诉求之间找一个大家都愿意接受的折中。

4.3 结果指标怎么算，以及曲线怎么画

跑完优化之后，别急着截图。先把指标体系定义清楚，否则你没法跟别人解释“为什么你这个调度好”。

常用的评价指标有三个：

• 峰谷差率 = (P_max − P_min) / P_max × 100%，衡量曲线极限波动；
• 负荷方差削减率 = (方差无序 − 方差优化) / 方差无序 × 100%，衡量整体平滑程度；
• 用户费用节省率 = (费用无序 − 费用优化) / 费用无序 × 100%，衡量用户经济收益。

画图方面，我最常用的是一张“四曲线图”：基础负荷、无序充电总负荷、单目标优化总负荷、多目标优化总负荷，四条线放在同一个坐标系里，一眼就能看出“峰被压下去、谷被填起来”的过程。再配一张某辆典型车辆的SOC曲线图，展示它的充放电行为如何随时间变化。输出图片时记得把Figure的Renderer设为painters，线宽统一到2.0以上，导出成矢量图放进论文里才会清晰。

5. 复现过程中的坑与调参经验

5.1 权重没归一化，优化等于白做

这是新手最容易踩的坑，我甚至可以说，十个跑这个模型的人里至少有五个会在这里卡住。假设你直接写obj = 0.5*obj_var + 0.3*obj_cost + 0.2*obj_bat，不除以各自的基准值，会发生什么？负荷方差是kW²量级，100辆车场景下方差随便就是几十万甚至上百万；用户费用是几十块钱；电池折损成本可能只有几块钱。这种量级差距下，哪怕权重只有0.1，方差项的数值也把其他两项碾压得干干净净。你以为你在做多目标，实际上优化器眼里只有一个目标：压方差。

正确的做法是先把每个目标单独优化一遍，记录各自的单目标最优值作为归一化基准f1*、f2*、f3*，再在加权目标里用f_i / f_i*。我在3.3的代码片段里预留了norm1/norm2/norm3这三个变量，就是为了干这个。权重扫描之前，先把它们算好存成常量，后面每次调权重都不用重新算。

5.2 电池损耗系数：V2G用多用少的“生死线”

c_bat这个系数直接决定了模型对V2G的态度。我做过一组敏感性实验：c_bat从0.05元/kWh一直变到0.4元/kWh，结果非常有意思——系数低于0.15左右时，优化器会让车辆尽可能多地参与峰段放电，V2G吞吐量非常大；系数高于0.3时，放电行为基本消失，调度退化成“只有充电的谷段错峰”。中间那段区间，V2G吞吐量随系数变化非常陡峭。

这说明电池损耗系数不是随便拍脑袋定的。工程上标定它有两种思路：一种是从电池循环寿命出发，按照“总吞吐电量对应循环次数，循环次数决定报废时间”来折算；另一种是从更换成本出发，把电池更换费用摊到总吞吐电量上。两种方法算出来的数量级通常在0.1～0.25元/kWh之间。我建议你至少做一组敏感性分析，把c_bat作为横轴、V2G总吞吐量作为纵轴画条曲线，这样既能证明你的模型对参数是“可解释”的，也能告诉读者你的结论在什么参数范围内成立。

5.3 时间分辨率、随机场景与求解器降级

时间分辨率从1小时改成15分钟（T从24变成96）之后，模型能更准确地捕捉充电过程的变化，但变量数直接翻4倍，求解时间可能增加一个数量级。对毕业论文或小规模验证，1小时分辨率足够；但如果你要做工程级别的调度方案，建议至少用15分钟分辨率，并且注意SOC递推约束里的Δt要跟着改。

还有一个容易被忽略的问题：单次确定性场景的优化结果往往过于乐观。如果所有车辆都假设19点接入、7点离开、初始SOC都取中值，那么优化器相当于“看到了未来的全部信息”，结果自然漂亮。但现实中车辆接入时间、初始SOC都有随机性。我的做法是跑蒙特卡洛：生成20组不同的车辆出行样本，分别求解，把结果的均值和标准差都报出来。这样你的结论就不是“碰运气”出来的，而是具有统计意义的。

如果你没有商业求解器的授权，也别着急。模型线性化之后（把二次方差目标改成线性化处理，或者直接调用quadprog处理二次项），用Matlab自带的quadprog或intlinprog一样能跑。我试过在T=24、N=100的规模下，自带的求解器虽然比CPLEX慢一些，但一两分钟以内也能出结果，完全够用。

5.4 车辆规模大了怎么办：聚合建模思路

当车辆数从100辆变成1000辆甚至更多时，T×N的变量矩阵会让求解器直接“吃不消”。这个问题的标准解法是“聚合分群”：把出行行为相近的车辆聚成几个集群，比如晚归+短途、晚归+长途、全天在场等类型，每个集群用一辆“等效车”代表，等效车的电池容量和功率是集群内所有车的累加，初始SOC取平均值。

聚合之后，N从1000降到5～10，模型规模瞬间回到可控范围。代价是丢失了车辆之间的个体差异，但如果你关心的是“总负荷曲线”而不是“某辆车几点几分充了多少电”，这个精度损失完全可以接受。实际工程中，聚合调度加实时修正，是很主流的落地思路。

整套模型从搭框架到调通参数，我花时间最多的地方反而不是写代码，而是不断问自己“这个约束漏了没有”“这个参数取多少才合理”。优化结果不会告诉你它自己有多可信——只有当你把每个数字背后的物理含义都想通了，结果才真正属于你。最后再分享一个小建议：先把N设成5辆、T设成24跑通全流程，确认负荷曲线和SOC曲线看起来“符合直觉”之后，再逐步扩大规模。这样你能更快定位是算法问题还是参数问题，比自己闷头调一个上千变量的模型高效得多。