考虑不同充电需求的电动汽车协调充电调度复现指南

半年前我对着某篇期刊论文里的算法流程图，整整两天没跑出一条像样的充电功率曲线。最后发现问题根本不在算法实现，而在需求数据构造——当时我把几十辆车的到达时刻、离开时刻、目标SOC一股脑揉成了同一个优化模板。电动汽车协调充电调度这东西，论文里一句话带过的是“不同充电需求”，落到代码里却是完全不同的可行域、约束组和目标权重。

这篇博文就围绕“考虑不同充电需求的电动汽车协调充电调度方法”这条线，从需求分类、数学建模、Cvxpy代码实现到复现排错，完整走一遍。整个过程用开源求解器就能跑，不依赖商业License，适合正在复现充电调度论文、做电网或交通电气化方向毕设、以及想把手里的调度算法从“能跑”推进到“跑对”的同学。我尽量把那些论文不写、课堂不讲的细节都摊开说。

1. 需求不是字符串而是可行域：为什么分类决定了调度质量

1.1 一场充电调度本质上在解“并发任务的资源分配”

如果你只把“不同充电需求”理解成“有的车想充到80%，有的车想充到100%”，复现出来的代码一定走样。

我自己的经验是：把每一辆车当成一个独立任务来看。这个任务由六个参数唯一确定：

• 接入时刻（车什么时候插枪）
• 离开时刻（车什么时候必须走）
• 初始SOC（插枪时电池还剩多少电）
• 目标SOC（用户希望离开时达到多少）
• 额定充电功率（这辆车或这台桩最大能扛多少kW）
• 电池容量（kWh，决定每个SOC点对应的能量）

这六个参数一组合，一辆车在实际调度中的可行动作范围就定死了。同样是“我要充电”，一辆早上8点接入、下午5点取走的通勤车，和一辆下午2点接入、3点就必须走的应急车，在数学上完全不是同一个问题。前者的功率可以摊到低价时段慢慢充，后者即便电价再贵，也得在1小时内灌进尽可能多的电。

用并发资源的语言翻译一下：接入时刻是任务就绪时间，离开时刻是截止期，需要的充电电能量是任务的负载量，充电功率是处理速率，变压器和线路容量是共享资源，分时电价则是随时间波动的资源成本。整个调度问题，就是在这些并发任务之间分配功率这个稀缺资源，让总成本最低，同时尽量不违约。

这个视角一旦建立，后面写约束的时候就非常顺：每个任务的功率上下限由车辆和桩决定，时间窗口由接入和离开决定，累计能量由SOC演化方程决定，共享资源上限由变压器决定。

1.2 紧急度：把“不同充电需求”变成一个可计算指标

需求差异不能只停留在自然语言层面，要复现调度代码，必须把它量化成一个可比较、可参与计算的指标。我在复现里最常用的量化指标是紧急度θ：

θ = ΔE / (T_avail × P_max)

其中ΔE是目标SOC与初始SOC之间需要补入的能量（kWh），T_avail是可用充电时间（小时），P_max是额定充电功率上限（kW）。

这个指标的实际含义是：在理想情况下，按最大功率连续充电、刚好能完成需求所需的充电时长，占可用时长的比例。如果θ=0.5，说明这台车用一半的可用时间就能充满，很从容；如果θ=0.9，说明它几乎要从头到尾顶着最大功率充，稍有波动就完不成目标。

有了这个指标，我习惯把需求分成四个层级：

紧急度不直接出现在模型变量里，但它决定了三件事：一是目标函数里用户满意度惩罚项的权重，二是软约束的松弛范围，三是在模型无解时优先舍弃哪些需求。后面讲代码和排错时会反复看到这个影子。

2. 复现前必须吃透的三个数学点：目标项量纲、SOC更新、软硬约束

2.1 目标函数不要只写购电成本，满意度必须有明确的量纲

很多初学者复现时直接写：min Σ 电价 × 功率。这个目标本身没错，但只适用于“所有车辆需求都必须在离开时满足”的硬约束场景。一旦变压器容量不够，模型直接无解，目标函数再漂亮也白搭。更贴近论文做法的目标函数其实是两项：

min Σ_t price[t] × P_total[t] × dt + λ × Σ_i penalty_i

第一项是购电成本，第二项是用户满意度损失。关键问题在于：penalty_i 的量纲是什么，λ 怎么取才能和购电成本“同台竞技”。

我在代码里让 penalty_i 表示“车辆i在离开时刻的目标SOC与实际SOC之间的差额”。这是一个0到1之间的无量纲数，比如目标0.9、实际0.85，差额就是0.05。如果λ取2000，那么差5个百分点就对应100元的惩罚。这样设定后，λ就有了非常直观的物理含义：每差1个SOC点的价格。实际调参时，你可以先跑一遍纯成本模型，看哪些车无法满足目标，然后根据商业场景给“1个SOC点”定个价格，比如快充车辆每少1个百分点补偿20元，λ就取2000。

需要提醒的是：惩罚项必须作用在“无法满足的部分”，而不是全部目标差额。如果一个需求本来就能满足，这辆车不应该产生惩罚。所以要引入辅助变量u_i ≥ 0，并加约束：

v["soc_target"] - S[i, v["dep"]] ≤ u_i

这样u_i只在“实际SOC低于目标”时才会大于0。这个技巧比直接用 max(0, target - actual) 这类非光滑函数更适合求解器。

2.2 SOC演化：效率系数和能量单位是事故高发区

SOC演化方程是所有复现代码中错误率最高的地方。公式本身不复杂：

S[i, t+1] = S[i, t] + eff_i × P[i, t] × dt / cap_i

但这里几乎每个符号都能埋坑。先说效率eff：电池充电不可能100%把电网电能转成电池化学能，一般取0.9到0.95之间。有些人复现时把这个系数漏了，结果所有车辆的SOC虚高10%，调度结果看起来“全都能满足”，实际工程里根本充不到。再说能量单位：电池容量cap_i是kWh，功率P[i,t]是kW，时间dt是小时，三者相乘/相除之后才能得到无量纲的SOC增量。如果时间步长是15分钟，dt=0.25，忘了乘这个0.25，SOC增量直接放大4倍，一晚上能把电池充爆。

我见过一个最隐蔽的错误：把SOC方程写成 S[i,t+1] = S[i,t] + P[i,t] × dt / cap_i，看起来对，但P[i,t]用的是“桩侧交流功率”，而效率是0.9，结果每次迭代都高估SOC——小算例看不出来，一跑48辆车、24个时段的场景，误差会被累积到不可接受的程度。所以复现代码里，效率系数放哪一侧、以什么单位参与运算，必须在写代码前用计算器先验算一个单步过程。

2.3 硬约束与软约束的分界线，决定了模型会不会“假死”

这个点我是在被OSQP返回“infeasible”折磨了一下午之后才彻底想明白的。充电调度里的约束可以分成两类：

第一类是物理硬约束，比如充电功率不能超过额定值、总功率不能超过变压器容量。这些约束没有任何商量余地，必须写成硬约束。第二类是合约软约束，比如“用户希望在8点前充到90%”。这类约束看起来是硬性的，但它的本质是交易条款，在资源不足时是可以协商的——协商的结果就是赔钱或赔积分。

复现论文代码时，如果你把第二类约束也全部写成硬约束，典型后果是：变压器容量稍微紧张一点，整个优化模型直接无解。而论文里跑出来的漂亮的调度结果，大概率是用了软约束。所以我的建议是，一开始就把“离开时SOC不低于目标”写成带辅助变量u_i的软约束，让模型有退路。后文第4节还会专门讲这个问题。

3. 可复现的主干代码：从数据准备到曲线输出

3.1 数据准备：把需求画像翻译成参数字典

我用的是Cvxpy + OSQP这套免费开源组合，原因很简单：论文复现阶段，最重要的是模型逻辑正确、结果可解释，没必要一开始就被Gurobi的License卡住。Cvxpy的建模语法和论文公式几乎一一对应，后面想切Gurobi，只需要改求解器参数和个别接口。

先安装依赖：

pip install cvxpy numpy matplotlib

然后是核心数据定义。这里我把每辆车定义成一个字典，字段和论文里的“需求”一一对应：

import numpy as np import cvxpy as cp T = 24 # 离散时段数 dt = 1.0 # 每个时段的小时数 # 分时电价，单位：元/kWh # 0-6点低谷0.3元，6-18点高峰1.5元，18-24点平段0.8元 price = np.array([0.3]*6 + [1.5]*12 + [0.8]*6) # 车辆集群 vehicles = [ {"arr": 0, "dep": 24, "soc0": 0.2, "soc_target": 0.9, "pmax": 7, "cap": 60, "eff": 0.92}, {"arr": 0, "dep": 24, "soc0": 0.5, "soc_target": 1.0, "pmax": 6, "cap": 40, "eff": 0.92}, {"arr": 8, "dep": 20, "soc0": 0.4, "soc_target": 0.85, "pmax": 11, "cap": 80, "eff": 0.93}, ] cap_limit = 200.0 # 变压器/线路容量上限，单位kW N = len(vehicles)

这里有个非常容易出错的地方：dep=24表示第24个时段的起点，也就是一天结束时。在时间离散语义里，充电活动发生在 [arr, dep) 这个半开区间，即arr时刻之后、dep时刻之前。如果dep=8，说明车在第8小时开始时离开，那么最后一个可充电时段是 [7, 8)，对应索引7。很多复现代码错在把dep当“最后可充时刻”，结果多充了一个小时。这个坑在第4节展开。

3.2 用Cvxpy构建优化问题：变量、约束、目标一次说清

核心代码分四步：定义变量、拼约束、写目标、求解。我直接给出可以跑的完整版本，注释尽量详细。

# 1. 定义优化变量 # P[i, t] 表示第i辆车在第t个时段的充电功率，非负 P = cp.Variable((N, T), nonneg=True) # S[i, t] 表示第i辆车在第t个时段初的SOC，维度T+1是为了覆盖dep时刻 S = cp.Variable((N, T + 1)) # u[i] 表示第i辆车离开时未满足的目标SOC差额，非负 u = cp.Variable(N, nonneg=True) constraints = [] for i, v in enumerate(vehicles): # 初始SOC constraints.append(S[i, 0] == v["soc0"]) # 充电功率只能在车辆接入期间存在，且不超过额定值 mask = np.zeros(T) mask[v["arr"]:v["dep"]] = 1.0 constraints.append(P[i, :] <= v["pmax"] * mask) # SOC演化方程：必须带效率系数和dt for t in range(T): constraints.append( S[i, t + 1] == S[i, t] + v["eff"] * P[i, t] * dt / v["cap"] ) # 离开时刻的目标差额，软约束 constraints.append(v["soc_target"] - S[i, v["dep"]] <= u[i]) # 变压器容量约束，物理硬约束 constraints.append(cp.sum(P, axis=0) <= cap_limit) # 目标函数：购电成本 + 满意度惩罚 cost = sum(price[t] * cp.sum(P[:, t]) * dt for t in range(T)) lambda_penalty = 2000.0 penalty = lambda_penalty * cp.sum(u) prob = cp.Problem(cp.Minimize(cost + penalty), constraints) prob.solve(solver=cp.OSQP, eps_abs=1e-8, eps_rel=1e-8) print("求解状态:", prob.status) print("总成本(元):", round(cost.value, 3)) print("不满意惩罚(元):", round(penalty.value, 3))

说几个代码里容易被忽略的细节：

第一，S变量的维度是(N, T+1)，不是(N, T)。因为要记录第0时刻的初始SOC和之后T个时段的转移结果，S[i, dep]这个值必须存在。维度少一，约束就写不进去。

第二，mask那边用 v["arr"]:v["dep"]，保证半开区间语义。这个切片写法对应的是“arr到dep之前的时段”。如果你用数字手搓索引，比如写 range(arr, dep+1)，模型就会允许车辆在离开时刻之后多充1个小时。短时段场景看不出问题，全天24小时场景下总负荷曲线会多处一小截功率，削峰效果直接被污染。

第三，OSQP默认容差比较松，对于SOC量级0到1、功率量级几十到几百、成本量级几千的混合问题，默认容差可能返回假可行。我在solve里显式设了eps_abs和eps_rel到1e-8。这个数值经验在论文复现里特别重要，很多“结果怪怪的”其实不是模型错，是求解器容差在作怪。

3.3 结果提取与可视化：看图检查，不能只盯数字

求解完之后不要只打印总成本，一定要把功率曲线和SOC曲线画出来。我习惯的检查顺序是：先看每辆车的SOC曲线是否单调上升、离开时刻是否到达目标，再看总功率曲线是否在任何时刻超过变压器容量。两张图都干净，才能说代码基本跑对了。

P_opt = np.round(P.value, 4) S_opt = np.round(S.value, 4) total_load = P_opt.sum(axis=0) # 每辆车离开时刻的SOC print("车辆离开SOC:") for i, v in enumerate(vehicles): print(f" 车{i}: 实际 {S_opt[i, v['dep']]:.3f}, 目标 {v['soc_target']}") # 总负荷曲线峰值 print("总负荷峰值(kW):", total_load.max()) print("变压器容量(kW):", cap_limit) import matplotlib.pyplot as plt t_axis = np.arange(T) fig, (ax1, ax2) = plt.subplots(2, 1, figsize=(10, 6), sharex=True) ax1.plot(t_axis, total_load, marker="o", label="总负荷") ax1.axhline(cap_limit, color="red", linestyle="--", label="容量上限") ax1.set_ylabel("功率/kW") ax1.legend() ax1.grid(True) for i, v in enumerate(vehicles): ax2.plot(np.arange(T + 1), S_opt[i, :], marker=".", label=f"车{i}") ax2.set_xlabel("时段") ax2.set_ylabel("SOC") ax2.legend() ax2.grid(True) plt.show()

如果SOC曲线出现下降或锯齿，优先检查效率和dt；如果总功率贴上限很久很久，说明调度确实在压着容量跑；如果某辆车全程零功率，大概率是mask切片把可充时段全屏蔽了。这些结果层面的“意外”，个个都指向模型或数据的问题。

4. 复现路上的五个真实翻车点

4.1 接入与离开时刻的“半开区间”语义错位

这个坑我在3.1已经提过，这里专门说清楚。假设某辆车8点接入、17点离开，时间粒度为1小时。它真正能充电的时段是8点到16点59分，也就是 [8, 17) 这个半开区间。在Python切片里，mask[8:17] = 1正好覆盖索引8到16共9个时段。很多人习惯写成mask[8:18]，甚至直接用range(8, 17+1)，这就会多给1个小时的充电窗口。

多给1小时看起来只影响一个时段，但优化器是“贪”的——它会把这个多出来的窗口安排在电价最低的时段。如果那个时段恰好在凌晨低谷末尾，结果就是所有车都往那个时段挤，变压器容量直接爆炸，然后你反过头来怀疑约束写错了，其实错的只是区间边界。

我的排查方法是：打印每辆车的可充电窗口起点和终点，和原始车辆参数逐条核对。不要相信自己的记忆，切片这种东西差一个数字，视觉上根本看不出来。

4.2 功率、容量、时间步的数值错配

复现公文里最常见的数据单位组合是：功率kW，容量kWh，时间小时。三个单位看着统一，但实际代码里时间步长很可能不是1小时。如果你把原始数据从15分钟粒度重采样成1小时，功率数值没问题，但dt必须跟着改；反过来，如果你拿到的是15分钟粒度的电价和功率曲线，却让dt=1，那SOC增量会被高估4倍。

这类错误有个典型特征：SOC曲线在短时间内冲到1.0并保持平顶。一旦看到平顶SOC，第一反应不是“电池满了”，而是检查“dt乘了吗”“效率乘了吗”“容量单位对吗”这三个问题。用计算器算一遍：60kWh电池，7kW功率，1小时应该增加7×0.92/60=0.107个SOC点。如果代码跑出来的每小时SOC增长超过这个值，单位链一定断了。

4.3 变压器容量不足时的infeasible：硬约束的假死与软约束的救场

一旦多辆车同时接入且需求都比较紧，变压器容量约束和“离开时SOC不低于目标”的硬约束会直接打架，求解器返回infeasible。此时很多人会去调节能器参数、换求解器，其实问题在模型设计。

正确做法在第2.3已经埋了伏笔：把“目标SOC”从硬约束改成软约束。具体操作就是代码里的辅助变量u_i，让“无法满足”这件事变成一个可量化的成本，而不是一个不可行的区域。这不是投机取巧，而是论文里常见的“需求响应”“可削减负荷”建模：用户允许在极端场景下降低充电目标，但需要获得补偿。

我在实际复现中会做一个对比实验：同一组数据，分别用硬约束和软约束跑一遍。硬约束返回infeasible，软约束会给出一个带惩罚成本的最优解。这个对比本身就是论文里非常有说服力的图表素材。

4.4 OSQP默认容差太大：假可行与假不可行

Cvxpy背后默认调用OSQP求解凸二次规划。OSQP是ADMM类算法，收敛判据是残差小于容差。默认eps_abs和eps_rel为1e-5，对很多问题够用，但充电调度目标函数的数值跨度比较大：成本项几千、SOC量级0到1、惩罚项系数2000，约束矩阵的条件数偏高。默认容差下，可能出现两种恶劣情况：

• 假不可行：明明有可行解，求解器报infeasible。
• 假可行：状态说是optimal，但S[i, dep]和目标SOC差了好几个百分点，检查约束时又对不上。

我后来养成的习惯是，任何论文复现的求解调用都显式指定eps_abs=1e-8, eps_rel=1e-8，必要时把max_iter提高到200000。别小看这组参数，它能把一堆莫名其妙的“玄学问题”直接变成确定性错误。如果你坚持用Gurobi，那默认容差反而偏严，可以适当放宽，但一定要知道自己在改什么。

4.5 电价曲线与负荷曲线的时间轴没对齐

最后一个坑，不是模型问题，是数据对齐问题。分时电价通常以“0-6点低谷、6-18点高峰、18-24点平段”这样的自然时间划分。但如果你的调度起点不是0点，或者车辆数据里的时间基准和电价时间基准有偏移，就会出现“低谷充电却按高峰电价计费”的诡异结果。

我踩过一次很实际的坑：某份数据里的负荷曲线起点是上午10点，电价表按0点开始排列，两个时间轴错位10小时，结果优化器疯狂在“看起来便宜”的时段充电，实际对应的是电网高峰。这个错位不报错，也不影响可行性，只是成本计算结果完全失真。复现任何带分时电价的调度论文，第一步永远是画一张时间轴对照表，把电价时段和调度时段的起始点对齐，再进模型。

5. 从“能跑”到“跑对”：手算验证与自动校验

5.1 一个能拿计算器验证的最小算例

代码跑通之后，最重要的事是用一个手算能算清的小例子做验证。我推荐从单台车起步。构造这么个场景：一辆车0点接入、24点离开，初始SOC 0.2，目标SOC 0.9，额定功率7kW，电池容量60kWh，充电效率0.92，电价谷段0.3元（0-6点）、峰段1.5元（6-18点）、平段0.8元（18-24点）。

需要补入的能量：ΔSOC=0.9-0.2=0.7，对应0.7×60=42kWh的电池侧能量，折算到电网侧是42/0.92=45.65kWh。低谷时段6小时，按7kW能充42kWh电网侧能量，只差3.65kWh。所以最优策略是低谷期全速充6小时，然后在高峰开始后继续以大约3.65kW再充1小时（因为功率可以低于额定值，所以不必凑满7kW）。手算的结论：前6个时段功率为7kW，第7个时段功率约3.65kW，之后为0，总成本=42×0.3+3.65×1.5=12.6+5.475=18.075元。

拿这个手算结果去对照代码输出，如果功率曲线、总成本都和手算一致，说明SOC演化方程、电价累加、目标函数的单位链全部正确。我从不让代码直接去跑几十辆车的复杂场景，必须先过这一关。

5.2 自动校验清单：把正确性检查写进代码

手算只能验证极小算例，复杂场景必须靠程序自动校验。我通常在求解之后加一段断言代码，作为复现的“最后防线”：

# 校验1：任何时段总功率不超过变压器容量 assert np.all(total_load <= cap_limit + 1e-4), "总负荷越限" # 校验2：任何车辆的充电功率不超过额定值 assert np.all(P_opt <= np.array([v["pmax"] for v in vehicles])[:, None] + 1e-4), "功率越限" # 校验3：非接入时段不允许充电 for i, v in enumerate(vehicles): mask = np.zeros(T) mask[v["arr"]:v["dep"]] = 1 assert np.all(P_opt[i, mask == 0] <= 1e-4), f"车{i}在非接入时段充电" # 校验4：SOC终值不低于目标（软约束允许小误差，但差距必须在惩罚范围内） for i, v in enumerate(vehicles): assert S_opt[i, v["dep"]] >= v["soc_target"] - 1e-3 or u.value[i] > 0, f"车{i}未达目标且无惩罚" print("所有自动校验通过")

这四条断言能抓住绝大多数“看起来能跑、实际是错的”情况。第四条写得比较宽，如果你用的是硬约束版，可以直接收紧为S[i, dep] >= target - 1e-4。我个人更推荐输出所有车辆的“目标SOC vs 实际SOC”表格，肉眼扫一遍比断言更能发现模式性的偏移。

5.3 没有削峰项时解不唯一：为什么同样代码结果不同

复现多车协调调度时，另一个让新手困惑的现象是：同一份代码、同一份数据，不同机器上跑出来结果不一样，但总成本又一样。这很可能是“目标函数不含削峰项”导致的解不唯一。

举一个真实的算例。两辆车都0点接入、24点离开。A车初始0.2、目标0.9、7kW、60kWh；C车初始0.5、目标1.0、6kW、40kWh。变压器容量10kW，电价同前。A需要电网侧45.65kWh，C需要13.04kWh，总需求58.69kWh。低谷6小时变压器最多供给60kWh，理论上都塞进低谷也能完成。

但两车同时满功率是7+6=13kW，超过10kW容量。可行的分配方案非常多：A跑6kW、C跑4kW，或者A跑5kW、C跑5kW，只要6小时内总能满足总需求，购电成本都是0.3×58.69=17.6元，没有差别。于是优化器返回的功率曲线是“众多最优解之一”，而不是唯一答案。这也是为什么很多论文里目标函数除了成本，还会加一个负荷方差或峰值惩罚项——不为别的，就是为了让解唯一、让调度曲线可复现、可比较。

如果你复现的论文里没写削峰项，只看功率曲线形状，自然很难跟原论文完全一致。这属于目标函数设计层面的正常差异，不是代码bug。

6. 复现之后还能往哪走：从离线调度到工程落地

6.1 滚动时域调度：别把24小时当成铁板一块

上面所有代码都是离线优化，把全天24小时一次性算完，假设所有车辆需求提前已知。真实场景里，车辆是陆续接入的，初始SOC也在实时变化。更贴近工程的做法是滚动时域调度（MPC）：每15分钟或每小时重新跑一次优化，只执行当前时段的功率指令，后面的时段作为预测窗口。这样做的好处是能吸收新接入车辆和SOC测量误差，代价是每次重新求解的耗时必须压到分钟级以下——好在Cvxpy+OSQP对这个规模的凸问题非常快。

我在扩展代码时会保留离线模型的全部约束，只把“接入时间窗”改成“从当前时刻到预测窗口终点”，再把每辆车的初始SOC换成最新遥测值。这套MPC框架和本文的模型几乎完全复用，改动量很小。

6.2 从功率曲线到真实的充电桩：通信协议层的考虑

调度代码算出来的是功率参考值，真正要执行，还得把功率指令下发到充电桩。这个环节就绕不开通信协议了——常见的有充电桩与充电站控制器之间的CAN报文，以及部分场景下的Modbus RTU寄存器读写。功率调度值和实际执行值之间的偏差、报文解析时的字节序、寄存器地址映射，都是工程落地的经典问题。

不过我的态度是：复现论文阶段先把优化模型做对，通信协议是后话。如果你只是为了复现算法、跑通实验，Cvxpy这一层就够了；如果要做真桩测试，再考虑CAN报文解析或Modbus协议栈，那是另一个完全不亚于调度的深坑。

复现这类调度代码，我的核心建议一直只有一个：先让单台车在计算器层面验证SOC演化，再加多车、加变压器容量、加各种花式需求。上面这套框架，把需求画像、数学建模、代码实现和常见排错串起来之后，我已经用它复现过三篇不同期刊的充电调度论文，每篇的“需求差异”处理方式不同，但底层模型几乎都是这篇文章讲的东西。把这条主线吃透，你手里的调度代码就不会再“玄学”了。