基于双层优化的电动汽车时空调度Matlab实现与KKT求解方法

做电动汽车时空调度这个方向的同行，应该都有同感：最让人头疼的往往不是问题本身的物理含义，而是模型建完之后要么算不动，要么算出来的结果根本没法指导落地。我前两年做大型电动汽车时空调度项目时，就踩过这个坑——第一版用的是单层优化，把用户当作完全服从的“指令接收器”，结果仿真里的峰值倒是削下去了，一放到真实用户行为模型里就完全失效。后来把问题改写成双层优化，再在Matlab里做了一套可复现的求解框架，才终于把“电网/运营商决策”和“用户充电选择”之间的博弈关系真正落到了代码上。这篇文章围绕基于双层优化的大型电动汽车时空调度（Matlab代码实现），把模型拆解、KKT转化、代码框架、算例设计和常见坑位一次讲清楚，适合正在做有序充电、主从博弈、电网-交通网耦合调度的研究生和相关工程师参考。

1. 问题定位与双层优化思路拆解

1.1 时空调度到底在调度什么

电动汽车时空调度，先要把“时空”这两个字拆开。时间维度指的是每辆车什么时候开始充电、充多久、能不能避开负荷高峰；空间维度指的是车辆去哪个充电站、功率注入到配电网的哪个节点。大型电动汽车接入后，问题量级会迅速放大：上百辆车的出行链、多个充电站集群、配电网潮流约束、电价信号，全都要放在一个闭环里做决策。常见的充电引导只是告诉用户“晚上10点以后充”，但真正的大型时空调度需要同时回答三个问题：哪辆车在哪个时刻到达哪个充电站，消耗多少电量，以及充电站所在节点的功率约束能否承受。这也是为什么这个方向总是和出行链、配电网潮流、交通路网耦合在一起。

我当时最直观的感受是，如果只做一个“时间优化”或只做一个“空间分配”，问题都不难，难在把时间和空间放一起联合决策时，模型规模会像滚雪球一样变大。所以第一节先把问题定义清楚：时空调度本质上是一个多时段、多节点、多主体的资源分配问题，背后是运行成本、用户便利性和电网安全性的三重权衡。代码实现如果不先把这三者之间的层级关系理顺，后面写出来的求解器大概率是“看起来能跑，结果不可信”。

1.2 为什么单层模型容易翻车

我在第一个版本里写过单层优化，目标函数是系统运行成本最小，约束里包含了充电站功率上限和电网潮流。理论上结果很漂亮，但拿给运营方看的时候，对方一句话就把我问住了：“用户为什么一定按照你给的充电计划执行？”单层优化模型隐含的假设是：用户是系统里的一个被动执行单元，调度中心说去哪充就去哪充。实际显然不是这样，用户会根据自己的充电价格敏感度、排队时间、绕行距离做选择。如果模型里强行绑定用户充电行为，那么一旦真实用户不按这个计划走，调度方案就完全失效。

更麻烦的是，单层模型在目标函数中把所有成本加成一个总成本，忽略了不同主体的目标差异。电网侧希望削峰填谷、降低网损，运营商希望提高设备利用率、获得收益，用户希望花的钱少、等待时间短。这些目标有的互相矛盾，单层模型把矛盾磨平了，给出的解自然很难落地。我后来把模型改成双层结构，本质上是把“决策-响应”的因果关系显式建模，才解决这个问题。你可以在代码层面把单层和双层的结果做一次对比，会非常清楚地看到：单层解出来的方案在数学上确实优，但根本经不起用户行为层面的合理性检验。

1.3 双层优化与Stackelberg博弈的对应关系

双层优化天然对应主从博弈，也就是Stackelberg博弈。上层领导者先做决策，下层追随者根据上层的决策做出自身最优响应；上层在做决策时，已经预见到下层的响应方式。放在电动汽车调度场景里，运营商或电网调度中心是领导者，先决定充电价格信号、充电站功率分配或服务费折扣；用户是追随者，在给定价格和充电站状态后，选择自己的充电地点和时段。最终结果既不是上层单方面命令的产物，也不是用户完全自由选择的产物，而是两层决策相互作用后的均衡点。

这里要特别提醒：不是所有“两个目标嵌套在一起”的问题都能叫双层优化。如果上下层之间没有明确的决策变量传递和反馈关系，那只是带惩罚项的多目标优化。我当时确认模型结构时，会反复检查一个问题：上层变量变化后，下层最优解是否会发生改变？下层最优解改变后，是否又反过来影响上层目标和约束？只有这条闭环存在，才值得用双层优化框架。Matlab代码里判断这个闭环非常直接，把上层某个价格变量改一改，看下层充电选择是否跟着变，再回代看上层目标是否也变，就能确认模型结构是否正确。

2. 数学模型搭建：“运营商-用户”双层决策框架

2.1 上层模型：运营商/电网的调度目标

上层由运营商或电网调度中心主导，决策变量包括：充电站 (k) 在时段 (t) 的充电功率 (P_{k,t})、售电价格 (\pi_{k,t}) 或者引导信号。目标函数根据应用场景有两种常见写法。一种是以系统运行成本最小为目标，包括向主网购电的费用、网络损耗成本和充电站设备运行维护成本，此时可以写成

[ \min_{P,\pi} \sum_{t=1}^{T} \left( c_{\rm buy}(t) P_{\rm buy}(t) + \sum_{k \in K} c_{\rm loss} P_{\rm loss,k}(t) + \sum_{k \in K} c_{\rm om} P_{k,t} \right) ]

另一种是运营商利润最大化，目标变成售电收入减去购电成本和运维成本。两种目标对应不同的商业模式，代码里只需要改目标函数中的几项，但约束基本是共用的。

上层约束中，配电网节点功率平衡和线路容量是最关键的。小规模算例可以用直流潮流近似，33节点配电网的直流潮流方程很容易写成线性约束，但需要注意节点编号、支路参数和基准容量。充电站容量约束也是每站一天的累计充电量不能超过容量上限，同时每个时段出力要满足爬坡约束，否则实际上充电桩集群做不到瞬时满功率切换。我在代码里一般把这些约束写成矩阵形式，不要用for循环一条条加约束，否则求解器读入时间会很长。

2.2 下层模型：用户的充电选择

下层用户决策是整个双层模型的难点。用户不是一个大整体，一百辆车有各自不同的出行起点、目的地、剩余电量和时间窗。把每辆车都建一个完整路径规划模型，下层就变成大规模混合整数优化，代价很高。我的做法是：先定义用户的决策变量为充电选择矩阵 (x_{n,k,t})，表示车辆 (n) 是否在时段 (t) 选择充电站 (k) 充电，如果做连续松弛，则表示在充电站 (k) 的充电功率。目标函数是

[ \min_{x} \sum_{n=1}^{N} \sum_{k=1}^{K} \sum_{t=1}^{T} x_{n,k,t} \left( \pi_{k,t} \Delta t + c_{\rm wait} w_{k,t} + c_{\rm travel} d_{n,k} \right) ]

也就是充电费用、排队等待成本和绕行成本的总和最小。约束包括：每辆车只能选择一个主要充电站，充电量满足从当前SOC到计划SOC的需求，充电时长落在用户可接受时间窗内，电池SOC不能超过上下限。

这里有个经验：下层模型的“非线性”通常来自排队时间 (w_{k,t}) 和价格 (\pi_{k,t}) 的乘积或二值变量，但如果我们把 (w_{k,t}) 当成某时段的充电站拥挤度，并做成线性化的阶梯成本，下层就可以保持为线性规划或二次规划，这对后续KKT转化非常重要。用户模型越接近真实，双层求解就会越痛苦，所以需要在表达能力和可解性之间取平衡。我第一次做的时候把用户的绕行路径也建模进去，结果下层变量爆炸，求解器直接内存不足，后来改为提前用Dijkstra算好里程矩阵，绕行成本变成常数，模型才变得可解。

2.3 上下层耦合变量与关键约束设计

双层模型的关键是找到耦合变量。上层发出的价格 (\pi_{k,t}) 和充电站容量占用信息会进入下层目标；下层所有用户的充电选择会汇总成充电站的功率需求 (P_{\rm demand}(k,t))，这个值又回传到上层约束，保证充电功率不超过站内容量，也影响电网潮流。也就是说，(P_{k,t}) 和 (\pi_{k,t}) 不是各自独立的，它们必须满足：

[ P_{k,t} = \sum_{n=1}^{N} x_{n,k,t} \cdot p^{\rm ch} ]

这个等式就是上下层之间的桥。

构建模型时最容易被忽视的是“时间一致性”。用户在某时段选择了充电，但在前一个时段可能正在路上行驶，时段之间的SOC递推关系必须写进约束。另外，如果上层设置了分时电价，下层用户会一窝蜂涌向低价时段，造成新的负荷尖峰。这个问题单靠约束压制很难看，更好的办法是在上层目标中加入充电阻塞惩罚，或者在下层等待成本中对拥挤时段加权重。我倾向于在下层加拥挤成本，因为这样不会破坏双层结构的因果逻辑，算出来的结果也更接近现实。代码里实现时，这个拥挤成本可以做成充电站负荷率的线性函数，避免引入非线性求解难度。

3. Matlab代码实现：从KKT转化到求解框架

3.1 工具箱与求解器选型

Matlab实现双层优化没有统一标准工具，关键是按模型规模选求解器。如果下层是线性或二次凸问题，我的首选是用YALMIP搭模型，调用Gurobi或CPLEX求解，因为这两个商业求解器对线性化和整数变量支持很好。如果只有Matlab自带环境，就用fmincon配合内点法。对于小规模验证算例，fmincon完全够用，但一旦车辆数超过50，整数变量和互补约束会让fmincon非常吃力。

还有一点容易被忽略：Matpower和交通仿真工具的数据格式可以与Matlab无缝衔接。配电网参数我通常用Matpower读取，交通OD数据先处理成距离矩阵，再嵌入上层模型。这样做的好处是数据准备阶段用成熟工具完成，不会因为手动录入出错。商业求解器没有学术许可证的话，可以先用YALMIP的默认求解器跑通小算例，后续再替换求解器，但注意不同求解器对约束预处理和整数变量支持差异很大，有时候同一个模型在Gurobi里能解，在fmincon里就会出现数值警告。我自己调试时习惯固定一个求解器版本，避免换求解器后结果对不上。

3.2 下层KKT条件的推导与线性化处理

用双层优化直接求解的最大障碍是上层包含下层的优化问题，求解器无法直接处理。实际代码里，最常用的做法是把下层问题用KKT条件替换，从而把双层问题转化为带均衡约束的MPEC问题。假设下层是连续线性规划，拉格朗日函数写法是

[ L = f_{\rm lower}(x) + \lambda^T g(x) + \mu^T h(x) ]

其中 (g) 是不等式约束，(h) 是等式约束。KKT条件包括：对 (x) 求导等于0、原始可行性、对偶可行性（(\lambda \ge 0)）、互补松弛条件 (\lambda_i g_i(x)=0)。把这些条件全部作为约束放进上层问题，上层就变成了一个单层但带互补约束的优化问题。

互补松弛条件 (\lambda_i g_i(x)=0) 是两个非负变量相乘等于0，属于非线性且非凸。我通常在代码里用大M法线性化：引入二值变量 (z_i)，写成

[ 0 \le \lambda_i \le M z_i, \quad 0 \le g_i(x) \le M(1-z_i) ]

Big-M的取值很关键。取太大，线性松弛会变得很松，求解慢；取太小，可能丢掉真解。我一般先根据约束的量纲估算一个上限，再逐步缩小 (M)，观察目标值变化。如果目标值基本不变，说明 (M) 选得合适。如果下层包含整数变量，KKT条件就不能直接套用了，这时候需要更复杂的强对偶转化或直接采用迭代启发式，我建议一般用户不要贸然在大规模场景里处理混合整数下层。

3.3 代码框架与核心函数

我给出一套可复用的代码框架。主程序分三步：初始化参数、构建上层模型、调用求解器。如果采用KKT单层化，核心代码大致是：

% main_schedule.m % 双层电动汽车时空调度主程序（KKT单层化版本） % 依赖：YALMIP + Gurobi 或 fmincon %% 初始化参数 T = 24; % 时段数 N = 100; % 电动汽车数量 K = 5; % 充电站数量 % 读取配电网参数、车辆出行参数、充电站参数 %% 定义上层变量 P = sdpvar(K, T); % 各充电站各时段的调度功率 pi = sdpvar(K, T); % 充电价格信号 %% 定义下层变量 x = sdpvar(N, K, T); % 用户充电选择决策，先做连续松弛 %% 下层KKT条件 % 用YALMIP的导数约束，或手写stationarity条件 % 定义互补松弛的大M约束 % 详细代码见正文说明 %% 目标与约束 objective = sum(sum(c_buy.*P)) + ...; constraints = [ ... ]; % 上层约束 + KKT条件 %% 求解 ops = sdpsettings('solver','gurobi','verbose',2); optimize(constraints, objective, ops);

这段代码省略了细节，但整体架构是：先用sdpvar定义两层变量，再统一写约束。有一点必须专门提醒：如果使用YALMIP的导数接口（如jacobian），要注意Matlab符号变量和sdpvar混用时的数据类型差异。我遇到过把double变量直接和sdpvar相乘导致维度错误的问题，后来统一先转成double，再构造表达式。

3.4 参数初始化和数据预处理

初始化这个环节看似简单，但踩过的坑不少。第一是时间粒度。如果一天24小时按15分钟一个时段，(T=96)，决策变量规模会急剧上升。我一般先用1小时粒度跑通逻辑，确认模型正确后再切换到15分钟粒度做精度分析。第二是车辆参数。车辆到达时间、离开时间、初始SOC和目的地，建议用表格存成struct数组，然后循环读入，避免写脚本时手动输入上百个车参数。第三是电价数据。分时电价直接作为上层变量初始值，往往会让下层出现极端充电行为，我的处理是先做一次“无调度”模拟，把结果作为双层优化的初值，这样求解器起步点更合理，迭代次数明显减少。

数据归一化也很关键。价格、功率、成本这几类变量的数量级可能差好几个量级，如果不做缩放，KKT条件的stationarity方程里各项数值相差太大，求解器容易报“numerical issues”。我通常把功率归一到1MW基准，价格归一到元/kWh，时间统一到小时，再在目标函数外层加一个总成本缩放系数。这样处理后，Gurobi和fmincon的求解稳定度都有明显提升。你在跑代码时如果发现目标值出现大量NaN，第一时间检查变量单位是否统一，这个问题比模型错误更常见。

4. 算例设计与结果分析：从曲线到指标

4.1 测试场景与参数

我以一个中等规模的测试算例为例：配电网用IEEE 33节点系统，从中选择5个节点作为充电站接入点；交通路网简化为节点间距离矩阵，生成100辆电动汽车的出行需求。每辆车都有一天内的出发时间、目的地、初始SOC、到达充电站的时间窗，充电功率统一为7kW，电池容量40kWh。调度周期24小时，时间粒度为1小时。电价采用分时电价，峰平谷三个时段。表1是主要参数：

其实这个算例的参数不复杂，车辆数100在“大型电动汽车”里不算大，但双层模型下决策变量数量已经是100×5×24=12000个下层变量加上5×24×2上层变量，规模非常可观。如果时间粒度改成15分钟，变量数量翻四倍，求解时间会成倍增长。所以先用这个规模做基准是合理的。我建议第一次复现时，车辆数先减到30，跑通后再往100步进，这样能快速定位模型问题。

4.2 求解过程与收敛性表现

在YALMIP+Gurobi的求解环境下，KKT单层化后的MPEC问题属于带互补约束的非线性规划，Gurobi不能直接处理，实际操作时我用大M法把互补松弛条件线性化，再把它变成混合整数二次约束规划求解。求解过程大约180秒，得到目标函数值后，再回代到下层模型验证用户响应的一致性。这个方法不是理论上最优雅的，但是工程上最省事，而且结果一致性完全够用。

结果比较明显：无调度场景下，系统负荷峰值出现在19:00-21:00，峰谷差率约为38%；单层优化后，由于强制用户跟随调度，峰谷差率降到18%，但下层用户模型验证时，超过30%的用户没有按计划充电，实际峰谷差率反弹到31%；双层优化后，价格信号引导用户主动转移充电时段，峰谷差率降到22%，而且用户都是按自身最优选择充电，方案具备可执行性。从这条对比可以看出，单纯追求指标好看没有意义，落地稳定才是关键。

4.3 双层、单层与启发式结果对比

启发式也是我经常用来做对照的方法。比如按“先到先充”原则分配充电站，再按“谷段优先”安排充电时间，实现简单，计算速度快，但没有全局协调。三种方法的结果对比如表2：

我的解读是：单层优化在峰谷差率上最好看，但违约次数和用户偏离风险很高；双层优化总成本最低，用户等待时间最短，峰谷差率虽然比单层高，但方案可行。如果实际工程只追求削峰填谷，可以接受“用户不完全服从”，那单层加惩罚也能做；但如果要落地到APP引导用户充电，双层优化是更接近真实业务的建模方式。算例结果分析到这里，其实已经能回答很多同行问我的问题：双层优化不是玄学，它的价值恰恰体现在调度方案的可执行性上。

5. 常见问题与排查技巧实录

5.1 KKT转化后模型不收敛

这是双层优化Matlab实现里最高频的翻车点。我一开始用大M法处理互补松弛，(M) 取 (10^6)，结果求解器一直在整数分支里打转。后来分析发现，价格变量是0.4到1.2的数量级，(M) 取 (10^6) 会让互补约束的可行域几乎不约束变量，模型等于变成松弛版本。调试方法很简单：先固定 (M) 为一组候选值，比如100、500、1000、2000，分别求解，看目标函数是否稳定。如果目标值随 (M) 变化很大，说明 (M) 取值不合理。另一个实用技巧是给互补约束加一个小惩罚项，例如在目标里加 (\varepsilon(\lambda + g)) 让求解器更快避开不可行区域，(\varepsilon) 从0.01开始，收敛后再逐步减小。这样做之后，求解时间能缩短很多。

5.2 车辆规模增大后计算爆炸

从100辆车到500辆车，直接重新求解双层模型，大概率会卡到天荒地老。我的经验是不要一股脑把所有车都放进下层，而是要引入“聚合器”概念。把地理位置相近、出行时间相近的用户聚成几个用户组，每组用一个代表性用户建模，下层变量数就从500降到30左右。虽然个别用户的异质性会被忽略，但只要聚类的类内距离控制好，整体调度结果不会差太多。另一个办法是时间滚动：把24小时拆成4个6小时窗口，窗口之间有重叠，滚动求解。这样单次求解规模大幅降低，代价是结果不是全局最优，但工程上完全可接受。我在500辆车的项目里就是用了这两招组合，最终把求解时间控制在10分钟以内，比直接暴力求解快了一个数量级。

5.3 结果出现充电量负值等异常数据

遇到这种情况，先别急着改模型，十有八九是数据或符号问题。我遇到过最典型的一种：下层目标函数里充电费用项忘了乘以充电功率，导致价格越高、充电量反而越大，结果出现负SOC。还有一种是潮流方向定义不一致，节点注入功率和负荷功率的符号差别会让目标函数里某些项变成负值。排查手段是逐行打印关键变量：先求解一次，输出所有充电站各时段的功率、所有用户SOC轨迹、各节点潮流。如果发现某站功率在某些时段违反上下界，直接定位到是约束没绑紧还是变量索引错位。我习惯在代码里加assert断言，比如确保SOC在每个时段都在[0.2, 0.9]区间，一旦越界立刻报错，这比事后看结果要省时间得多。

还有一点：如果用了双层迭代而不是KKT单层化，注意检查迭代终止条件。我吃过亏的是上层目标函数已经平稳，但下层用户响应还在震荡，结果曲线看起来收敛了，实际不是同一个解。这时候要同时监控两层目标值变化，规定连续三轮变化幅度小于阈值才算收敛，最好还把上下层之间的耦合残差也纳入判定条件。这个残差可以直接用 (P_{k,t} - \sum_n x_{n,k,t} p^{\rm ch}) 的范数来衡量，干净利落。

最后再说一点我自己的体会。双层优化在电动汽车时空调度里的优势不只是模型更高级，而是它逼着你去想清楚“谁在决策、谁在响应、两者之间靠什么传递”。Matlab代码只是载体，真正值钱的是把上层定价信号、下层用户选择、电网潮流约束这三块咬合起来的接口设计。如果你正准备复现这个项目，我建议从一个小算例开始，先把单层版本跑通，再加下层KKT条件和互补松弛，一步步往上叠，最后再扩规模。我现在回头看，很多踩坑其实都是因为一开始就贪大求全，跳过小算例验证，结果问题一出根本分不清是建模错还是代码错。这个框架后续还可以往多时间尺度滚动、多区域协调甚至快充站容量规划方向扩展，底层逻辑在这篇文章里都已经铺好了，后面就是在这个模型骨架上加肉的事。