1. 换电站选址定容到底在解决什么先想清楚再动手做规划类项目最怕的不是算法写不出来而是目标都还没定义清楚就开始跑代码。我在接到换电站选址与定容这个需求时第一反应不是打开Matlab而是先问三个问题站建在哪里建多大总量建多少这三个问题就是换电站规划的全部核心。选址解决的是空间维度定容解决的是规模维度两者不能拆开独立做。比如你先把站址拍板定下来发现旁边需求不够扩容又受用地限制这就被动了。反过来先定容量再找位置可能整个片区都找不到一块地来安放一个重型换电站。所以业内一般叫这个问题的全称是“选址-定容联合优化”英文里叫location-sizing problem属于设施选址问题facility location problem的一个经典细化分支。先说说这个问题的实际业务背景。电动出租车、电动网约车、电动重卡这些运营类车辆是换电模式最主要的用户群体。原因很简单换电的补能时间只有3到5分钟和加油差不多而充电哪怕用快充也要40分钟到1小时。对运营车辆来说时间就是钱所以换电模式在商用车和运营乘用车市场里有明确的需求支撑。但换电站的建设和运营成本都非常高一座换电站的投资往往在200万到500万元之间除了设备本身还有电池储备、场地租金、电力接入改造成本。在这个前提下站建得太多资产利用率低赚不回来站建得太少用户换电要跑很远排队时间拉长体验变差导致用户流失。选址与定容就是要在这两头之间找到一个最优解。用规划的语言来说我们要做的是给定一个区域内的换电需求分布给定一批可以建设换电站的候选位置确定哪些位置建站、每个站的容量配置多大、需求点如何分配到各个站让总成本最小化同时保证服务质量和用户体验。Matlab在这个问题上的优势很明显。第一它的优化工具箱Optimization Toolbox内置了intlinprog这个混合整数线性规划求解器选址定容问题天然是一类带整数决策变量的问题很对路。第二Matlab的数据处理和可视化一体化能力很强从需求点坐标导入、距离矩阵计算到最终的地图打点和容量气泡图展示全部可以在同一个环境里完成。第三Matlab的代码调试和教学演示成本低适合快速构建原型、跑敏感性分析这在方案汇报阶段尤其有用。有一点必须提前说明复杂的大规模路网级选址问题生产环境通常会上Gurobi或CPLEX这类商用求解器配合Python或者C来工程化落地。但Matlab版本的核心价值在于——用最低的时间成本把算法逻辑跑通把模型验证做扎实。我下面要拆解的就是这条用Matlab从建模到实现、再到结果分析验证的完整路径。目录结构和代码框架都是可以直接迁移到你自己的数据上去的。2. 数学模型才是真正的主心骨目标函数与约束条件的推导很多人在这一步会跳过数学直接写代码结果就是改约束的时候逻辑混乱、求解器报错都不知道去哪里查。我建议无论时间多紧都要先把下面这个模型在纸上写一遍代码是模型的翻译模型错了代码再漂亮都没有意义。2.1 相关参数与集合的定义先把要用的集合和参数列清楚需求点集合$I {1, 2, ..., N}$每个需求点 $i$ 代表一个交通小区或需求聚合中心带有换电需求 $q_i$次/天。候选站址集合$J {1, 2, ..., M}$每个候选点 $j$ 有单位建设成本固定成本$C_j$万元包含场地与设备基础投资。换电需求点到候选站点的距离$d_{ij}$公里通常是路网距离但规划阶段可以用欧氏距离乘以绕行系数来近似。最大服务半径$R$公里超过这个距离通常认为用户不愿意去换电是服务质量约束。单站容量上限$Q_{max}$块/天受限于用地面积和电力容量。单站固定建设成本$C_j^{fix}$建站就必须花的钱。单站单位容量成本$C_j^{cap}$每增加一块电池/一个充电位的边际成本。运输成本系数$\alpha$元/公里表示用户绕行去换电站的時間和电耗折算。2.2 决策变量怎么设计这是建模的核心步骤很多人对这里模糊。第一个是选址变量 $x_j$0-1变量$x_j 1$ 表示在候选点 $j$ 建站否则为0。第二个是定容变量 $y_j$表示候选点 $j$ 的换电站容量每日可服务的换电次数。它有两个选择把它建模成连续变量后面取整或者建模成整数变量。我实际做下来的经验是当候选点数量在几十个以内时直接把 $y_j$ 定义为整数变量更干净不会出现算出来 2.7 块电池这种尴尬结果也方便和实际设备数量对接。第三个是分配变量 $z_{ij}$表示需求点 $i$ 的换电需求中分配到候选站 $j$ 的部分。这个变量对应服务的“归属关系”对用户行为建模来说很重要——你要知道每个站服务哪些需求点才能评估站的服务负荷和交通流向。分配变量可以定义为0-1变量一个需求点全部由某一个站服务也可以定义为连续变量0到1之间一个需求点按比例由多个站服务。前者逻辑简洁但是在大需求点情况下会出现“强制就近”的失真问题后者允许分担但会让结果的可解释性稍微下降。我在常规项目中都用连续分配变量原因后文会说。2.3 目标函数总成本最少不只是建站成本目标函数是总成本最小化这是所有选址问题的出发逻辑。但它绝对不只是“建站投资最小”如果只算建站投资最优解就是全不建、成本为零那用户完全没法换电模型没有约束。所以目标函数要同时纳入投资成本和使用成本。我用的是这个形式$$ min \quad Z \sum_{j \in J} C_j^{fix} \cdot x_j \sum_{j \in J} C_j^{cap} \cdot y_j \alpha \cdot \sum_{i \in I} \sum_{j \in J} d_{ij} \cdot z_{ij} $$拆开来看第一项是固定建设成本。只要建站就产生这笔费用包括场地租金、基础设施、设备购置的折旧分摊。第二项是容量相关的成本。容量越大电池储备越多、充电车位越多对应投资越高。这里用了一个线性化假设实际中容量成本的边际变化可能是阶梯式的比如设备有标准规格但在规划阶段用线性近似是最常见也最稳妥的做法。第三项是用户端成本或者叫出行成本。需求点 $i$ 的需求被分配到候选点 $j$ 后用户要从 $i$ 开到 $j$产生时间和电耗折算为成本。$\alpha$ 把距离转换为经济成本通常取每公里电耗成本加上时间机会成本的和。这一项就是把用户体验纳入目标函数的关键。2.4 约束条件怎么拆目标函数定下来后约束条件是真正让模型“立得住”的关键。我总结了五个必须加的约束缺一个模型都会跑出荒谬的结果。第一个是需求满足约束。每个需求点的需求必须被完全服务$$ \sum_{j \in J} z_{ij} q_i, \quad \forall i \in I $$这个约束保证每个街区、每个交通小区的换电需求都有人接盘。注意这里如果某个需求点距离所有候选站都超过了最大服务半径模型就会陷入无解状态处理办法是放宽该点的半径限制或者在候选点选择阶段就规避这种情况。第二个是容量约束。每个站的分配量不能超过其建设容量$$ \sum_{i \in I} z_{ij} \le y_j, \quad \forall j \in J $$这个约束把定容变量 $y_j$ 和分配变量 $z_{ij}$ 耦合在一起有了它定容才不是拍脑袋的独立数值。容量上限约束$y_j \le Q_{max}$也在这里一并处理。第三个是逻辑约束。只有当某候选点建站了才能被分配需求$$ z_{ij} \le q_i \cdot x_j, \quad \forall i \in I, j \in J $$或者更紧凑的写法$$ y_j \le M \cdot x_j, \quad \forall j \in J $$其中 $M$ 是一个足够大的数比如总需求量的上限。这个约束的背后含义是你不建这个站就不可能有任何分配量给它也不可能有容量配置。这是把选址变量 $x_j$ 和定容变量 $y_j$、分配变量 $z_{ij}$ 绑定的桥梁。第四个是覆盖约束。如果需求点 $i$ 的某部分需求分配给了候选点 $j$那么 $i$ 和 $j$ 之间的距离不能超过最大服务半径$$ z_{ij} \le q_i \cdot \mathbb{1}(d_{ij} \le R) $$首先在代码层面提前筛掉距离超过半径的候选点不在优化变量里生成那一项即可这样既减少了变量数量又天然满足约束。第五个可选约束是建设数量上限。区域规划和预算经常会给定建设上限 $P_{max}$$$ \sum_{j \in J} x_j \le P_{max} $$如果业务方明确说了“一期最多建5座站”这个约束就非常实用。2.5 两种常用模型变体现实项目中上面这套完整模型可能不是一次就上。我接触过两类变异版本很值得说明。第一类是集合覆盖模型set covering model。当需求点数量巨大、候选点也很多的时候先忽略容量维度只做“最少建站数覆盖所有需求点”的选址得到站址集合再在选定的站址上单独做定容优化。这个方式把联合优化拆成两步求解压力大大下降适合超大规模的路网级规划。它的问题在于站址的选择没有考虑容量成本差异可能出现整体次优。我的建议是超过200个候选点、1000个需求点的大区域规划先用集合覆盖做粗选址再用联合优化在缩小的候选集合上做精修。第二类是需求聚类预处理的扩展模型。原始模型里需求点 $i$ 是出行小区级别的但是实际拿到手的换电需求可能是高精度GPS轨迹数据有几十万个点。这时要先对需求点做空间聚类比如用kmeans按坐标聚成50到100个需求簇把每簇的总需求当成一个需求点。这一步同时解决了数据量和用户隐私问题是工业界的标准预处理手段。后面在Matlab代码部分我会给出聚类接口的具体用法。把模型说清楚接下来就是怎么用Matlab一步步把它翻译成代码。这里有个小提醒数学变量和代码变量名尽量保持一致比如q不要写成demand再写个dem变量名混乱是代码后期维护的头号杀手。3. Matlab代码实现全流程从数据预处理到求解器调用这一章是实际操作的部分。我会把整体代码框架、核心函数接口、以及intlinprog求解器的使用方式完整讲一遍。你可以拿自己的数据直接替换我给出的示例数据文件结构完全不用动。3.1 代码的整体架构设计整个项目代码按照下面的模块划分每个模块一个.m脚本或函数。project/ |-- data/ | |-- demand_points.csv % 需求点坐标和需求量 | |-- candidate_sites.csv % 候选站址坐标 |-- src/ | |-- load_data.m % 数据读取与预处理 | |-- compute_distance.m % 距离矩阵计算 | |-- build_model.m % 构建优化模型最核心的模块 | |-- solve_model.m % 调用intlinprog求解 | |-- plot_results.m % 结果可视化 |-- run_main.m % 主程序入口分层设计的好处是后续调参数不需要动整个流程。比如只换一个成本系数只需要改build_model.m里的对应常数只换一个数据集只需要替换data/下的CSV文件。我在多个项目里验证过这个结构的可复用性即使在数据格式不统一的情况下也只需要改load_data.m这个入口脚本。3.2 数据读取与预处理需求点和候选点的数据结构一般是这样组织的。需求点文件至少包含三列经度、纬度、日换电需求次数。候选点文件包含两列坐标外加候选点对应的固定建设成本和单位容量成本。% load_data.m function [demand_pts, candidate_sites, q, C_fix, C_cap] load_data() % 读取需求点lon, lat, demand_per_day demand_table readmatrix(data/demand_points.csv); demand_latlon demand_table(:, 1:2); q demand_table(:, 3); % 读取候选点lon, lat, fix_cost, cap_per_unit site_table readmatrix(data/candidate_sites.csv); site_latlon site_table(:, 1:2); C_fix site_table(:, 3); C_cap site_table(:, 4); % 投影转换经纬度不适合直接算距离先转平面坐标 % 这里用简化的等距投影更精确的做法是用工具箱的projfwd函数 % 如果区域不大直接用经纬度差值乘上对应的公里系数也能凑合 demand_pts [demand_latlon(:,1) * 85.28, demand_latlon(:,2) * 111.0]; candidate_sites [site_latlon(:,1) * 85.28, site_latlon(:,2) * 111.0]; end这里有个非常重要的细节距离计算千万不能用经纬度直接做欧氏距离。在经度方向1度的距离在赤道附近是111公里但到了北纬40度就只有85公里左右纬度方向每度基本稳定在111公里。如果项目在中小尺度范围城市级可以用一个平均系数简单折算但如果你处理的是省域级别的大范围规划建议采用投影转换把经纬度转换到UTM平面坐标系再算距离。Matlab的Mapping Toolbox里有projfwd这是最标准的方法。没有这个工具箱的话也可以用网上流传的墨卡托投影简化代码精度对于选址问题来说已经足够。3.3 距离矩阵的计算与候选点预筛距离矩阵是整个模型里最占用内存的部分。假设有1000个需求点、50个候选点距离矩阵大小是1000乘505万个元素Matlab完全没压力。但如果你有10万个GPS点做需求这个矩阵就直接到几百万浮点数存储没问题但后续约束构建会慢很多。所以大规模场景务必先做需求点聚类。% compute_distance.m function [dist, feasible_mask] compute_distance(demand_pts, site_pts, R) n_demand size(demand_pts, 1); n_site size(site_pts, 1); % 直接计算两两距离矩阵 dist zeros(n_demand, n_site); for i 1:n_demand diff site_pts - demand_pts(i, :); dist(i, :) sqrt(sum(diff.^2, 2)); end % 预筛超过最大服务半径R的分配关系直接置为不可行 feasible_mask dist R; dist(~feasible_mask) inf; % 不可行的距离设无限大 end注意这里把不可行距离设为inf而不是删掉是为了保持矩阵维度一致后续在约束构建时可以直接利用这个信息跳过生成对应的变量项。如果直接把不可行的位置删掉矩阵索引会乱排列组合的映射关系容易出错。实际项目中我踩过这个坑当时排查了很久才发现是删列导致的索引混乱。如果你的数据里既有道路网格dist还可以换成路网距离矩阵。计算方式是在GIS软件里做个OD矩阵分析导出CSV再在compute_distance里读取。这个改动不影响模型和求解流程只替换距离来源。3.4 构建优化模型的完整代码这是整个项目中最核心的模块。我先把变量编码方式说清楚不然代码很难看懂。决策变量向量x_opt的结构是一个分块拼接[x_1, x_2, ..., x_M, % 选址变量长度M0-1 y_1, y_2, ..., y_M, % 容量变量长度M整数或连续 z_11, z_21, ..., z_N1, % 需求点对站1的分配变量长度N z_12, z_22, ..., z_N2, % 需求点对站2的分配变量长度N ..., z_1M, z_2M, ..., z_NM] % 需求点对站M的分配变量长度N总变量数量 M M N * M。假设50个候选点、500个需求点总共是50 50 25000 25100个变量其中二进制变量50个整数变量50个连续变量25000个这个规模对intlinprog来说是小菜一碟。% build_model.m function [f, intcon, Aineq, bineq, Aeq, beq, lb, ub] build_model(dist, q, C_fix, C_cap, alpha, Q_max, R, P_max) n_demand length(q); n_site size(dist, 2); % 变量数量 n_vars n_site n_site n_demand * n_site; % 变量索引辅助用偏移量计算各个段落的起始位置 idx_x 1:n_site; % 选址变量索引段 idx_y n_site (1:n_site); % 容量变量索引段 idx_z n_site n_site; % z变量的起始偏移 % 目标函数系数向量 f zeros(1, n_vars); f(idx_x) C_fix; % 固定建设成本 f(idx_y) C_cap; % 容量成本 % 分配变量系数alpha * dist(i,j) for j 1:n_site z_indices idx_z ((j-1)*n_demand (1:n_demand)); f(z_indices) alpha * dist(:, j); end % 整数约束变量索引 intcon [idx_x, idx_y]; % 选址和容量变量为整数 lb zeros(1, n_vars); ub ones(1, n_vars); ub(idx_y) Q_max; % 容量上限 % z变量上限设为1真实的分配量由需求满足约束和容量约束牵引 % 不等式约束Ax b % 约束1容量约束 sum_i z_ij y_j, 对每个j n_ineq n_site; % 先给容量约束分配行数 % 约束2建设逻辑约束 z_ij q_i * x_j, 对每个i,j n_ineq n_ineq n_demand * n_site; % 约束3建设数量约束 sum x_j P_max n_ineq n_ineq 1; Aineq zeros(n_ineq, n_vars); bineq zeros(n_ineq, 1); row 0; % 容量约束 for j 1:n_site row row 1; % 每个需求点的z分配给这个站 z_indices idx_z ((j-1)*n_demand (1:n_demand)); Aineq(row, z_indices) 1; Aineq(row, idx_y(j)) -1; % y_j - sum z_ij 0 等价于 -y_j sum z_ij 0 bineq(row) 0; end % 建设逻辑约束z_ij q_i * x_j % 这里只对feasible分配关系生成约束不可行的距离已经为inf for j 1:n_site for i 1:n_demand if isfinite(dist(i, j)) row row 1; z_index idx_z (j-1)*n_demand i; Aineq(row, z_index) 1; Aineq(row, idx_x(j)) -q(i); bineq(row) 0; end end end % 建设数量约束 row row 1; Aineq(row, idx_x) 1; bineq(row) P_max; % 截断多余行 Aineq Aineq(1:row, :); bineq bineq(1:row); % 等式约束每个需求点的分配总和 q_i Aeq zeros(n_demand, n_vars); beq q; for i 1:n_demand % 对该需求点所有站的z变量系数为1 for j 1:n_site z_index idx_z (j-1)*n_demand i; Aeq(i, z_index) 1; end end end这个代码块里有几个值得重点解释的设计容量约束写成sum(z_ij) y_j而不是sum(z_ij) Q_max这是为了把容量变量真正纳入优化逻辑。如果容量只给一个固定上限那定容问题就被降级成单纯的选址问题了。建设逻辑约束采用了z_ij q_i * x_j而不是更宽松的y_j M * x_j。前者的精度更高直接从分配端锁死了“未选中的站不会有任何需求分配”这个逻辑。后者的M取值太大会导致数值稳定性问题太小又会误砍可行解。能精确建模的地方尽量用精确形式。3.5 intlinprog求解器的调用方式模型构建完成后求解本身其实是最轻松的环节。把参数喂给intlinprog即可。% solve_model.m function [x_opt, fval, exitflag, output] solve_model(f, intcon, Aineq, bineq, Aeq, beq, lb, ub) options optimoptions(intlinprog, ... Display, iter, ... MaxTime, 300, ... % 最长求解时间300秒 IntegerTolerance, 1e-5, ... ConstraintTolerance, 1e-6, ... Heuristics, rss, ... % 启发式策略找初始可行解 BranchingRule, strong, ... % 分支策略加速求解 CutGeneration, advanced); % 高级割平面 [x_opt, fval, exitflag, output] intlinprog(f, intcon, Aineq, bineq, Aeq, beq, lb, ub, options); end求解器返回的x_opt是一个很长的向量需要从里面把三种变量重新拆出来。% 从结果中提取核心决策信息 n_site length(C_fix); n_demand length(q); x_selected x_opt(1:n_site); % 选址结果 y_capacity x_opt(n_site1:2*n_site); % 容量结果 z_allocation x_opt(2*n_site1:end); % 分配结果 selected_sites find(x_selected 0.5); fprintf(选中了 %d 个站址\n, length(selected_sites)); for k 1:length(selected_sites) j selected_sites(k); fprintf( 候选点 %d容量 %d 次/天\n, j, round(y_capacity(j))); end关于exitflag这个返回值我之前遇到很多同学直接忽略它这是不对的。当exitflag为0或负值时求解器可能没找到最优解此时对结果做任何分析都是没有意义的。我的习惯是exitflag 1找到最优解时直接输出结果exitflag 0达到时间限制时警告用户继续分析当前可行解但注明非最优exitflag -2无可行解时返回模型参数的合理性排查——可能是最大服务半径设得太小、候选点太稀疏、或需求超出了所有候选点容量总和。3.6 结果可视化的实用技巧可视化不仅是给客户看的也是你自己验证模型输出的第一道关卡。我一般画三张图。第一张是规划底图把所有需求点和候选点的分布画出来。% plot_results.m 中的第一部分 figure; scatter(demand_pts(:, 1), demand_pts(:, 2), 10, q, filled); colorbar; title(需求点分布与需求量); hold on; scatter(candidate_sites(:, 1), candidate_sites(:, 2), 80, k^, filled); legend(需求点, 候选站址);第二张是选址结果图把选中的站和未选中的站用不同颜色区分容量大小用气泡半径表示。% 选址与容量结果展示 figure; scatter(demand_pts(:, 1), demand_pts(:, 2), 5, [0.7 0.7 0.7], filled); hold on; for j 1:n_site if x_selected(j) 0.5 % 选中站点气泡大小按容量比例 scatter(site_pts(j, 1), site_pts(j, 2), y_capacity(j)*3, r, filled); else scatter(site_pts(j, 1), site_pts(j, 2), 30, k^); end end title(选址与定容结果);第三张是分配关系图把每个需求点和它对应的主服务站点用线连起来。这个图能帮你看清有没有需求点被分配到了明显更远的站点——如果有多半是容量约束在起作用需要关注是否需要增加容量或者新增站点。实际项目里我还会加一个表格输出table类型罗列每个选中站点的坐标、容量、服务需求点数量和总分配量。这个表格是汇报材料里最有说服力的部分。4. 参数敏感性分析与多场景对比验证模型的可靠性模型跑通只是第一步更重要的是验证结果在参数扰动下是否稳定。换电站选址涉及的成本参数、需求参数存在大量不确定性如果结果对某个参数极其敏感那决策的可靠性就要打问号。我在每个项目中都必做敏感性分析。4.1 权重系数 alpha 的影响$\alpha$ 代表单位距离的用户出行成本这个系数直接决定了目标函数里“用户体验”和“投资成本”之间的权重平衡。取一组合理的参考值假设固定建设成本 $C_{fix} 300$ 万元单站容量上限 $Q_{max} 200$ 次/天$q_i$ 从需求数据来。把 $\alpha$ 从0.1元/公里逐步调整到1.0元/公里观察结果变化alpha元/公里选址数量座总容量次/天平均配给距离km总成本万元0.134208.712500.345006.914300.555505.816100.866404.918401.066804.52015可以看到一个明显的规律当 $\alpha$ 从0.1升高到0.5时选址数量从3座增加到5座平均配给距离从8.7公里下降到5.8公里但当 $\alpha$ 从0.8继续升到1.0时选址数量不再增加只是单站容量微涨。这说明在给定候选点分布和需求空间结构的条件下5到6座站已经能基本满足空间覆盖需求继续加站的边际收益很低。这个拐点信息本身就有决策意义。从业务角度解释如果换电站的投资方是承运公司自己用户体验提升能直接转化成客户留存和车辆运行时长那 $\alpha$ 应该定高一点。如果换电站是第三方投资运营按次收费那 $\alpha$ 只代表用户绕路带来的隐性流失风险定位可以保守一些。这个取舍没有绝对的对错但模型能帮你把两种策略下的成本结构差异量化出来。4.2 容量上限 Q_max 和半径 R 的联动关系容量上限 $Q_{max}$ 受场地条件限制但也是规划人员可以争取的变量。我在项目中常把 $Q_{max}$ 和 $R$ 联合起来做一个二维扫描输出一个比较矩阵这比单独分析一个参数更有说服力。举一个实际跑过的场景样例固定 $\alpha 0.5$RkmQ_max 100Q_max 200Q_max 4003不可行不可行7座站总成本18205不可行6座站总成本16805座站总成本152088座站总成本19505座站总成本14304座站总成本1280107座站总成本17805座站总成本13404座站总成本1210读这张表要注意几个点。从左下角看当 $R3$、$Q_{max}100$ 时模型无解原因可能是候选点之间间距过大3公里半径内需求无法被任意3个候选点覆盖同时100次/天的容量上限又太小总容量可能低于总需求。这说明如果物理约束太紧那无论算法多优秀都不可能给出可行方案现实中的应对策略是减小半径内需求集中度或增加候选点数量。再看同一行 $R8$ 时$Q_{max}$ 从100提高到400站数从8座下降到4座总成本下降约34%。这说明在半径允许的前提下提高单站容量是更经济的方案——固定建设成本被摊薄了。但是容量超过200以后成本下降幅度就不明显了说明继续扩容的意义不大。这个“甜点区间”就是规划时优先争取的目标参数。这种联动分析的实际价值在于它不是单纯告诉你“最优方案是什么”而是告诉你“哪些约束是最值钱的”。如果候选站点能突破某个容量限制整体方案的成本能降低多少一目了然。汇报时有了这张表业务部门很容易理解他们应该优先协调的是哪块资源。4.3 敏感性分析后要做的一个补充实验做完敏感性分析我会额外做一个稳健性验证把需求数据加上扰动比如在原始 $q_i$ 上加随机波动正负10%重复求解多次看选址结果是否稳定。由于需求预测本身就带误差如果需求量变化10%导致选址方案完全跳变那这个模型对预测误差过于敏感决策风险就很高。这个实验在Matlab里做起来很自然在load_data之后加一个函数perturb_demand(q, ratio)对每个需求乘上1 ratio * (rand - 0.5) * 2然后重复调用build_model和solve_model20到30次统计每个候选点被选中的频率。如果某个候选点在大多数扰动场景下都被选中那么它在需求不确定性下具有稳健性属于“必选项”。如果有的候选点在部分场景被选中、部分场景被淘汰那它的优势比较微弱实际决策时要谨慎。这个方法花费的计算时间不多但对决策质量的提升非常明显强烈建议当作标准流程的一部分来做。5. 实际项目中的坑与经验总结这些弯路你别再走了最后一部分聊点代码和模型之外的实战经验。我做过不止一个选址类项目踩过的坑比看过的文献多这些经验用文字整理出来希望对你有用。5.1 数据的坑比算法多得多第一个项目我拿到的是模拟数据天然很干净跑起来一切顺利。到了真实项目发现数据质量才是真正的瓶颈。主要遇到过三类问题坐标缺失或漂移、需求量的时间分布不均衡、候选点的用地条件不统一。坐标漂移问题很好理解GPS打点有时候会偏出去几百米甚至几公里在清洗阶段就要用路网匹配或者缓冲区过滤做修正千万别直接用原始坐标。需求量要注意的是换电需求是分时段的早晚高峰和平时的需求强度差好几倍。如果建模时只用了日均需求那定容结果在高峰期大概率不够用。所以在真实项目中我会在建模前做一次需求的时间断面分析分别用“平日均值”和“高峰小时需求”两个场景跑两遍模型取保守解作为推荐方案。这个细节直接影响换电站的使用体验也是投资方最关心的问题之一。候选点的用地条件这一块实际规划中经常出现的情况是模型算出来某候选点应该在位置A建站但到了实地一勘探位置A的地是基本农田或者规划绿地根本拿不到。解决思路是在模型里加一个候选点分类的惩罚项或者干脆把不可用的候选点从集合里摘掉重新求解。另外我强烈建议提前收集候选点的产权、用地性质、电力容量条件这些在实际落地时都是硬约束越早进入模型越好。不要让模型浪费算力在一个不可能建站的点上。5.2 求解器参数调优的实战心得intlinprog默认参数对大多数小规模问题都够用但遇到大规划问题候选点超过100个、需求点和候选点的逻辑约束超过几万条时求解时间可能从几秒暴增到几分钟甚至更久。我总结出几个调优方向设置Heuristics参数为rss或round让求解器先快速找一个初始可行解。有一个可行解兜底非常重要即使后续求解超时你至少能交出一个可执行的方案而不是两手空空。好的初始解还能大幅加速分支剪枝的过程。设置BranchingRule为strong或pseudocost用更精细的分支策略换取分支次数减少。适合模型不是特别庞大但难求解的中等规模场景。不过对于几千个二值变量的超大问题强分支本身的计算开销也会上升需要实际测试权衡。设置CutGeneration为advanced在根节点多生成一些割平面可以显著收紧LP松弛的边界。对选址模型效果尤其明显因为这类模型的LP松弛解往往非常分数化割平面能有效提升收敛速度。如果求解时间还是不够理想回头检查约束规模。一个常见的无意识浪费是建设逻辑约束z_ij q_i * x_j对每一对(i,j)都生成但如果某个点在满足距离约束的候选站之外就不该生成约束。我们前面在compute_distance里把不可行距离设为inf并在build_model里用isfinite跳过了这一对这一步就能减少大量无效约束。5.3 模型结果的可解释性比最优解本身更重要做项目不是发论文不是给出一个最优解就完事。我每次把求解结果摆到决策者面前都会被问“为什么这里要建座站”“为什么那里不建”。这时候把分配关系图、需求热力图、容量利用率这些辅助结果一起拿出来解释比直接报一个总成本数字有说服力得多。我的固定动作是把每个站的容量利用率计算出来展示在汇报表格里。利用率过低的站比如低于60%要主动说明理由通常是覆盖偏远需求点的战略布点而非高负荷站点。利用率过高的站在模型中已经被容量上限锁住但在实际运营中要关注是否接近饱和可能需要预留扩容空间。这一层信息只有将模型结果和业务逻辑结合起来才能呈现出来也是方案能否顺利通过评审的关键。5.4 后续沿着这个项目还可以继续做哪些方向如果你把上面的流程完整跑通了恭喜你已经掌握了一个可以复用到多种设施选址问题的工具箱。顺着换电站选址这个场景还能继续扩展的方向包括在模型中引入时间维度把高峰期和平时的容量统筹优化或者在定容变量中加入充电桩的功率选择让每个站点在换电和充电之间按需调配。这个扩展的现实背景是很多换电站实际上是“换电站快充站”的混合场站利用率更高、收益结构也更稳健。另外如果把模型从单目标扩展到多目标比如同时考虑企业投资成本最小化和用户平均等待时间最小化可以做Pareto前沿分析。用intlinprog配合加权法或epsilon约束法循环求解能画出目标权衡曲线这为决策层提供的视角更完整。我个人的深刻体会是这类规划项目真正拉开差距的不是求解器的变量规模而是建模的颗粒度选择和数据分析的深度。一个把业务约束吃透的简化模型往往比一个数学上完美但脱离现实的复杂模型更受欢迎。把今天这套Matlab代码跑通之后你会慢慢形成自己的建模节奏——先建立数据体检意识再打磨模型边界条件最后用敏感性分析验证方案稳健性到这一步就已经能交出非常完整的工程成果了。 
长河君 · 2026/9/10 19:42:29 · 阅读 1.2k 基于Matlab的换电站选址定容优化建模与求解
1. 换电站选址定容到底在解决什么先想清楚再动手做规划类项目最怕的不是算法写不出来而是目标都还没定义清楚就开始跑代码。我在接到换电站选址与定容这个需求时第一反应不是打开Matlab而是先问三个问题站建在哪里建多大总量建多少这三个问题就是换电站规划的全部核心。选址解决的是空间维度定容解决的是规模维度两者不能拆开独立做。比如你先把站址拍板定下来发现旁边需求不够扩容又受用地限制这就被动了。反过来先定容量再找位置可能整个片区都找不到一块地来安放一个重型换电站。所以业内一般叫这个问题的全称是“选址-定容联合优化”英文里叫location-sizing problem属于设施选址问题facility location problem的一个经典细化分支。先说说这个问题的实际业务背景。电动出租车、电动网约车、电动重卡这些运营类车辆是换电模式最主要的用户群体。原因很简单换电的补能时间只有3到5分钟和加油差不多而充电哪怕用快充也要40分钟到1小时。对运营车辆来说时间就是钱所以换电模式在商用车和运营乘用车市场里有明确的需求支撑。但换电站的建设和运营成本都非常高一座换电站的投资往往在200万到500万元之间除了设备本身还有电池储备、场地租金、电力接入改造成本。在这个前提下站建得太多资产利用率低赚不回来站建得太少用户换电要跑很远排队时间拉长体验变差导致用户流失。选址与定容就是要在这两头之间找到一个最优解。用规划的语言来说我们要做的是给定一个区域内的换电需求分布给定一批可以建设换电站的候选位置确定哪些位置建站、每个站的容量配置多大、需求点如何分配到各个站让总成本最小化同时保证服务质量和用户体验。Matlab在这个问题上的优势很明显。第一它的优化工具箱Optimization Toolbox内置了intlinprog这个混合整数线性规划求解器选址定容问题天然是一类带整数决策变量的问题很对路。第二Matlab的数据处理和可视化一体化能力很强从需求点坐标导入、距离矩阵计算到最终的地图打点和容量气泡图展示全部可以在同一个环境里完成。第三Matlab的代码调试和教学演示成本低适合快速构建原型、跑敏感性分析这在方案汇报阶段尤其有用。有一点必须提前说明复杂的大规模路网级选址问题生产环境通常会上Gurobi或CPLEX这类商用求解器配合Python或者C来工程化落地。但Matlab版本的核心价值在于——用最低的时间成本把算法逻辑跑通把模型验证做扎实。我下面要拆解的就是这条用Matlab从建模到实现、再到结果分析验证的完整路径。目录结构和代码框架都是可以直接迁移到你自己的数据上去的。2. 数学模型才是真正的主心骨目标函数与约束条件的推导很多人在这一步会跳过数学直接写代码结果就是改约束的时候逻辑混乱、求解器报错都不知道去哪里查。我建议无论时间多紧都要先把下面这个模型在纸上写一遍代码是模型的翻译模型错了代码再漂亮都没有意义。2.1 相关参数与集合的定义先把要用的集合和参数列清楚需求点集合$I {1, 2, ..., N}$每个需求点 $i$ 代表一个交通小区或需求聚合中心带有换电需求 $q_i$次/天。候选站址集合$J {1, 2, ..., M}$每个候选点 $j$ 有单位建设成本固定成本$C_j$万元包含场地与设备基础投资。换电需求点到候选站点的距离$d_{ij}$公里通常是路网距离但规划阶段可以用欧氏距离乘以绕行系数来近似。最大服务半径$R$公里超过这个距离通常认为用户不愿意去换电是服务质量约束。单站容量上限$Q_{max}$块/天受限于用地面积和电力容量。单站固定建设成本$C_j^{fix}$建站就必须花的钱。单站单位容量成本$C_j^{cap}$每增加一块电池/一个充电位的边际成本。运输成本系数$\alpha$元/公里表示用户绕行去换电站的時間和电耗折算。2.2 决策变量怎么设计这是建模的核心步骤很多人对这里模糊。第一个是选址变量 $x_j$0-1变量$x_j 1$ 表示在候选点 $j$ 建站否则为0。第二个是定容变量 $y_j$表示候选点 $j$ 的换电站容量每日可服务的换电次数。它有两个选择把它建模成连续变量后面取整或者建模成整数变量。我实际做下来的经验是当候选点数量在几十个以内时直接把 $y_j$ 定义为整数变量更干净不会出现算出来 2.7 块电池这种尴尬结果也方便和实际设备数量对接。第三个是分配变量 $z_{ij}$表示需求点 $i$ 的换电需求中分配到候选站 $j$ 的部分。这个变量对应服务的“归属关系”对用户行为建模来说很重要——你要知道每个站服务哪些需求点才能评估站的服务负荷和交通流向。分配变量可以定义为0-1变量一个需求点全部由某一个站服务也可以定义为连续变量0到1之间一个需求点按比例由多个站服务。前者逻辑简洁但是在大需求点情况下会出现“强制就近”的失真问题后者允许分担但会让结果的可解释性稍微下降。我在常规项目中都用连续分配变量原因后文会说。2.3 目标函数总成本最少不只是建站成本目标函数是总成本最小化这是所有选址问题的出发逻辑。但它绝对不只是“建站投资最小”如果只算建站投资最优解就是全不建、成本为零那用户完全没法换电模型没有约束。所以目标函数要同时纳入投资成本和使用成本。我用的是这个形式$$ min \quad Z \sum_{j \in J} C_j^{fix} \cdot x_j \sum_{j \in J} C_j^{cap} \cdot y_j \alpha \cdot \sum_{i \in I} \sum_{j \in J} d_{ij} \cdot z_{ij} $$拆开来看第一项是固定建设成本。只要建站就产生这笔费用包括场地租金、基础设施、设备购置的折旧分摊。第二项是容量相关的成本。容量越大电池储备越多、充电车位越多对应投资越高。这里用了一个线性化假设实际中容量成本的边际变化可能是阶梯式的比如设备有标准规格但在规划阶段用线性近似是最常见也最稳妥的做法。第三项是用户端成本或者叫出行成本。需求点 $i$ 的需求被分配到候选点 $j$ 后用户要从 $i$ 开到 $j$产生时间和电耗折算为成本。$\alpha$ 把距离转换为经济成本通常取每公里电耗成本加上时间机会成本的和。这一项就是把用户体验纳入目标函数的关键。2.4 约束条件怎么拆目标函数定下来后约束条件是真正让模型“立得住”的关键。我总结了五个必须加的约束缺一个模型都会跑出荒谬的结果。第一个是需求满足约束。每个需求点的需求必须被完全服务$$ \sum_{j \in J} z_{ij} q_i, \quad \forall i \in I $$这个约束保证每个街区、每个交通小区的换电需求都有人接盘。注意这里如果某个需求点距离所有候选站都超过了最大服务半径模型就会陷入无解状态处理办法是放宽该点的半径限制或者在候选点选择阶段就规避这种情况。第二个是容量约束。每个站的分配量不能超过其建设容量$$ \sum_{i \in I} z_{ij} \le y_j, \quad \forall j \in J $$这个约束把定容变量 $y_j$ 和分配变量 $z_{ij}$ 耦合在一起有了它定容才不是拍脑袋的独立数值。容量上限约束$y_j \le Q_{max}$也在这里一并处理。第三个是逻辑约束。只有当某候选点建站了才能被分配需求$$ z_{ij} \le q_i \cdot x_j, \quad \forall i \in I, j \in J $$或者更紧凑的写法$$ y_j \le M \cdot x_j, \quad \forall j \in J $$其中 $M$ 是一个足够大的数比如总需求量的上限。这个约束的背后含义是你不建这个站就不可能有任何分配量给它也不可能有容量配置。这是把选址变量 $x_j$ 和定容变量 $y_j$、分配变量 $z_{ij}$ 绑定的桥梁。第四个是覆盖约束。如果需求点 $i$ 的某部分需求分配给了候选点 $j$那么 $i$ 和 $j$ 之间的距离不能超过最大服务半径$$ z_{ij} \le q_i \cdot \mathbb{1}(d_{ij} \le R) $$首先在代码层面提前筛掉距离超过半径的候选点不在优化变量里生成那一项即可这样既减少了变量数量又天然满足约束。第五个可选约束是建设数量上限。区域规划和预算经常会给定建设上限 $P_{max}$$$ \sum_{j \in J} x_j \le P_{max} $$如果业务方明确说了“一期最多建5座站”这个约束就非常实用。2.5 两种常用模型变体现实项目中上面这套完整模型可能不是一次就上。我接触过两类变异版本很值得说明。第一类是集合覆盖模型set covering model。当需求点数量巨大、候选点也很多的时候先忽略容量维度只做“最少建站数覆盖所有需求点”的选址得到站址集合再在选定的站址上单独做定容优化。这个方式把联合优化拆成两步求解压力大大下降适合超大规模的路网级规划。它的问题在于站址的选择没有考虑容量成本差异可能出现整体次优。我的建议是超过200个候选点、1000个需求点的大区域规划先用集合覆盖做粗选址再用联合优化在缩小的候选集合上做精修。第二类是需求聚类预处理的扩展模型。原始模型里需求点 $i$ 是出行小区级别的但是实际拿到手的换电需求可能是高精度GPS轨迹数据有几十万个点。这时要先对需求点做空间聚类比如用kmeans按坐标聚成50到100个需求簇把每簇的总需求当成一个需求点。这一步同时解决了数据量和用户隐私问题是工业界的标准预处理手段。后面在Matlab代码部分我会给出聚类接口的具体用法。把模型说清楚接下来就是怎么用Matlab一步步把它翻译成代码。这里有个小提醒数学变量和代码变量名尽量保持一致比如q不要写成demand再写个dem变量名混乱是代码后期维护的头号杀手。3. Matlab代码实现全流程从数据预处理到求解器调用这一章是实际操作的部分。我会把整体代码框架、核心函数接口、以及intlinprog求解器的使用方式完整讲一遍。你可以拿自己的数据直接替换我给出的示例数据文件结构完全不用动。3.1 代码的整体架构设计整个项目代码按照下面的模块划分每个模块一个.m脚本或函数。project/ |-- data/ | |-- demand_points.csv % 需求点坐标和需求量 | |-- candidate_sites.csv % 候选站址坐标 |-- src/ | |-- load_data.m % 数据读取与预处理 | |-- compute_distance.m % 距离矩阵计算 | |-- build_model.m % 构建优化模型最核心的模块 | |-- solve_model.m % 调用intlinprog求解 | |-- plot_results.m % 结果可视化 |-- run_main.m % 主程序入口分层设计的好处是后续调参数不需要动整个流程。比如只换一个成本系数只需要改build_model.m里的对应常数只换一个数据集只需要替换data/下的CSV文件。我在多个项目里验证过这个结构的可复用性即使在数据格式不统一的情况下也只需要改load_data.m这个入口脚本。3.2 数据读取与预处理需求点和候选点的数据结构一般是这样组织的。需求点文件至少包含三列经度、纬度、日换电需求次数。候选点文件包含两列坐标外加候选点对应的固定建设成本和单位容量成本。% load_data.m function [demand_pts, candidate_sites, q, C_fix, C_cap] load_data() % 读取需求点lon, lat, demand_per_day demand_table readmatrix(data/demand_points.csv); demand_latlon demand_table(:, 1:2); q demand_table(:, 3); % 读取候选点lon, lat, fix_cost, cap_per_unit site_table readmatrix(data/candidate_sites.csv); site_latlon site_table(:, 1:2); C_fix site_table(:, 3); C_cap site_table(:, 4); % 投影转换经纬度不适合直接算距离先转平面坐标 % 这里用简化的等距投影更精确的做法是用工具箱的projfwd函数 % 如果区域不大直接用经纬度差值乘上对应的公里系数也能凑合 demand_pts [demand_latlon(:,1) * 85.28, demand_latlon(:,2) * 111.0]; candidate_sites [site_latlon(:,1) * 85.28, site_latlon(:,2) * 111.0]; end这里有个非常重要的细节距离计算千万不能用经纬度直接做欧氏距离。在经度方向1度的距离在赤道附近是111公里但到了北纬40度就只有85公里左右纬度方向每度基本稳定在111公里。如果项目在中小尺度范围城市级可以用一个平均系数简单折算但如果你处理的是省域级别的大范围规划建议采用投影转换把经纬度转换到UTM平面坐标系再算距离。Matlab的Mapping Toolbox里有projfwd这是最标准的方法。没有这个工具箱的话也可以用网上流传的墨卡托投影简化代码精度对于选址问题来说已经足够。3.3 距离矩阵的计算与候选点预筛距离矩阵是整个模型里最占用内存的部分。假设有1000个需求点、50个候选点距离矩阵大小是1000乘505万个元素Matlab完全没压力。但如果你有10万个GPS点做需求这个矩阵就直接到几百万浮点数存储没问题但后续约束构建会慢很多。所以大规模场景务必先做需求点聚类。% compute_distance.m function [dist, feasible_mask] compute_distance(demand_pts, site_pts, R) n_demand size(demand_pts, 1); n_site size(site_pts, 1); % 直接计算两两距离矩阵 dist zeros(n_demand, n_site); for i 1:n_demand diff site_pts - demand_pts(i, :); dist(i, :) sqrt(sum(diff.^2, 2)); end % 预筛超过最大服务半径R的分配关系直接置为不可行 feasible_mask dist R; dist(~feasible_mask) inf; % 不可行的距离设无限大 end注意这里把不可行距离设为inf而不是删掉是为了保持矩阵维度一致后续在约束构建时可以直接利用这个信息跳过生成对应的变量项。如果直接把不可行的位置删掉矩阵索引会乱排列组合的映射关系容易出错。实际项目中我踩过这个坑当时排查了很久才发现是删列导致的索引混乱。如果你的数据里既有道路网格dist还可以换成路网距离矩阵。计算方式是在GIS软件里做个OD矩阵分析导出CSV再在compute_distance里读取。这个改动不影响模型和求解流程只替换距离来源。3.4 构建优化模型的完整代码这是整个项目中最核心的模块。我先把变量编码方式说清楚不然代码很难看懂。决策变量向量x_opt的结构是一个分块拼接[x_1, x_2, ..., x_M, % 选址变量长度M0-1 y_1, y_2, ..., y_M, % 容量变量长度M整数或连续 z_11, z_21, ..., z_N1, % 需求点对站1的分配变量长度N z_12, z_22, ..., z_N2, % 需求点对站2的分配变量长度N ..., z_1M, z_2M, ..., z_NM] % 需求点对站M的分配变量长度N总变量数量 M M N * M。假设50个候选点、500个需求点总共是50 50 25000 25100个变量其中二进制变量50个整数变量50个连续变量25000个这个规模对intlinprog来说是小菜一碟。% build_model.m function [f, intcon, Aineq, bineq, Aeq, beq, lb, ub] build_model(dist, q, C_fix, C_cap, alpha, Q_max, R, P_max) n_demand length(q); n_site size(dist, 2); % 变量数量 n_vars n_site n_site n_demand * n_site; % 变量索引辅助用偏移量计算各个段落的起始位置 idx_x 1:n_site; % 选址变量索引段 idx_y n_site (1:n_site); % 容量变量索引段 idx_z n_site n_site; % z变量的起始偏移 % 目标函数系数向量 f zeros(1, n_vars); f(idx_x) C_fix; % 固定建设成本 f(idx_y) C_cap; % 容量成本 % 分配变量系数alpha * dist(i,j) for j 1:n_site z_indices idx_z ((j-1)*n_demand (1:n_demand)); f(z_indices) alpha * dist(:, j); end % 整数约束变量索引 intcon [idx_x, idx_y]; % 选址和容量变量为整数 lb zeros(1, n_vars); ub ones(1, n_vars); ub(idx_y) Q_max; % 容量上限 % z变量上限设为1真实的分配量由需求满足约束和容量约束牵引 % 不等式约束Ax b % 约束1容量约束 sum_i z_ij y_j, 对每个j n_ineq n_site; % 先给容量约束分配行数 % 约束2建设逻辑约束 z_ij q_i * x_j, 对每个i,j n_ineq n_ineq n_demand * n_site; % 约束3建设数量约束 sum x_j P_max n_ineq n_ineq 1; Aineq zeros(n_ineq, n_vars); bineq zeros(n_ineq, 1); row 0; % 容量约束 for j 1:n_site row row 1; % 每个需求点的z分配给这个站 z_indices idx_z ((j-1)*n_demand (1:n_demand)); Aineq(row, z_indices) 1; Aineq(row, idx_y(j)) -1; % y_j - sum z_ij 0 等价于 -y_j sum z_ij 0 bineq(row) 0; end % 建设逻辑约束z_ij q_i * x_j % 这里只对feasible分配关系生成约束不可行的距离已经为inf for j 1:n_site for i 1:n_demand if isfinite(dist(i, j)) row row 1; z_index idx_z (j-1)*n_demand i; Aineq(row, z_index) 1; Aineq(row, idx_x(j)) -q(i); bineq(row) 0; end end end % 建设数量约束 row row 1; Aineq(row, idx_x) 1; bineq(row) P_max; % 截断多余行 Aineq Aineq(1:row, :); bineq bineq(1:row); % 等式约束每个需求点的分配总和 q_i Aeq zeros(n_demand, n_vars); beq q; for i 1:n_demand % 对该需求点所有站的z变量系数为1 for j 1:n_site z_index idx_z (j-1)*n_demand i; Aeq(i, z_index) 1; end end end这个代码块里有几个值得重点解释的设计容量约束写成sum(z_ij) y_j而不是sum(z_ij) Q_max这是为了把容量变量真正纳入优化逻辑。如果容量只给一个固定上限那定容问题就被降级成单纯的选址问题了。建设逻辑约束采用了z_ij q_i * x_j而不是更宽松的y_j M * x_j。前者的精度更高直接从分配端锁死了“未选中的站不会有任何需求分配”这个逻辑。后者的M取值太大会导致数值稳定性问题太小又会误砍可行解。能精确建模的地方尽量用精确形式。3.5 intlinprog求解器的调用方式模型构建完成后求解本身其实是最轻松的环节。把参数喂给intlinprog即可。% solve_model.m function [x_opt, fval, exitflag, output] solve_model(f, intcon, Aineq, bineq, Aeq, beq, lb, ub) options optimoptions(intlinprog, ... Display, iter, ... MaxTime, 300, ... % 最长求解时间300秒 IntegerTolerance, 1e-5, ... ConstraintTolerance, 1e-6, ... Heuristics, rss, ... % 启发式策略找初始可行解 BranchingRule, strong, ... % 分支策略加速求解 CutGeneration, advanced); % 高级割平面 [x_opt, fval, exitflag, output] intlinprog(f, intcon, Aineq, bineq, Aeq, beq, lb, ub, options); end求解器返回的x_opt是一个很长的向量需要从里面把三种变量重新拆出来。% 从结果中提取核心决策信息 n_site length(C_fix); n_demand length(q); x_selected x_opt(1:n_site); % 选址结果 y_capacity x_opt(n_site1:2*n_site); % 容量结果 z_allocation x_opt(2*n_site1:end); % 分配结果 selected_sites find(x_selected 0.5); fprintf(选中了 %d 个站址\n, length(selected_sites)); for k 1:length(selected_sites) j selected_sites(k); fprintf( 候选点 %d容量 %d 次/天\n, j, round(y_capacity(j))); end关于exitflag这个返回值我之前遇到很多同学直接忽略它这是不对的。当exitflag为0或负值时求解器可能没找到最优解此时对结果做任何分析都是没有意义的。我的习惯是exitflag 1找到最优解时直接输出结果exitflag 0达到时间限制时警告用户继续分析当前可行解但注明非最优exitflag -2无可行解时返回模型参数的合理性排查——可能是最大服务半径设得太小、候选点太稀疏、或需求超出了所有候选点容量总和。3.6 结果可视化的实用技巧可视化不仅是给客户看的也是你自己验证模型输出的第一道关卡。我一般画三张图。第一张是规划底图把所有需求点和候选点的分布画出来。% plot_results.m 中的第一部分 figure; scatter(demand_pts(:, 1), demand_pts(:, 2), 10, q, filled); colorbar; title(需求点分布与需求量); hold on; scatter(candidate_sites(:, 1), candidate_sites(:, 2), 80, k^, filled); legend(需求点, 候选站址);第二张是选址结果图把选中的站和未选中的站用不同颜色区分容量大小用气泡半径表示。% 选址与容量结果展示 figure; scatter(demand_pts(:, 1), demand_pts(:, 2), 5, [0.7 0.7 0.7], filled); hold on; for j 1:n_site if x_selected(j) 0.5 % 选中站点气泡大小按容量比例 scatter(site_pts(j, 1), site_pts(j, 2), y_capacity(j)*3, r, filled); else scatter(site_pts(j, 1), site_pts(j, 2), 30, k^); end end title(选址与定容结果);第三张是分配关系图把每个需求点和它对应的主服务站点用线连起来。这个图能帮你看清有没有需求点被分配到了明显更远的站点——如果有多半是容量约束在起作用需要关注是否需要增加容量或者新增站点。实际项目里我还会加一个表格输出table类型罗列每个选中站点的坐标、容量、服务需求点数量和总分配量。这个表格是汇报材料里最有说服力的部分。4. 参数敏感性分析与多场景对比验证模型的可靠性模型跑通只是第一步更重要的是验证结果在参数扰动下是否稳定。换电站选址涉及的成本参数、需求参数存在大量不确定性如果结果对某个参数极其敏感那决策的可靠性就要打问号。我在每个项目中都必做敏感性分析。4.1 权重系数 alpha 的影响$\alpha$ 代表单位距离的用户出行成本这个系数直接决定了目标函数里“用户体验”和“投资成本”之间的权重平衡。取一组合理的参考值假设固定建设成本 $C_{fix} 300$ 万元单站容量上限 $Q_{max} 200$ 次/天$q_i$ 从需求数据来。把 $\alpha$ 从0.1元/公里逐步调整到1.0元/公里观察结果变化alpha元/公里选址数量座总容量次/天平均配给距离km总成本万元0.134208.712500.345006.914300.555505.816100.866404.918401.066804.52015可以看到一个明显的规律当 $\alpha$ 从0.1升高到0.5时选址数量从3座增加到5座平均配给距离从8.7公里下降到5.8公里但当 $\alpha$ 从0.8继续升到1.0时选址数量不再增加只是单站容量微涨。这说明在给定候选点分布和需求空间结构的条件下5到6座站已经能基本满足空间覆盖需求继续加站的边际收益很低。这个拐点信息本身就有决策意义。从业务角度解释如果换电站的投资方是承运公司自己用户体验提升能直接转化成客户留存和车辆运行时长那 $\alpha$ 应该定高一点。如果换电站是第三方投资运营按次收费那 $\alpha$ 只代表用户绕路带来的隐性流失风险定位可以保守一些。这个取舍没有绝对的对错但模型能帮你把两种策略下的成本结构差异量化出来。4.2 容量上限 Q_max 和半径 R 的联动关系容量上限 $Q_{max}$ 受场地条件限制但也是规划人员可以争取的变量。我在项目中常把 $Q_{max}$ 和 $R$ 联合起来做一个二维扫描输出一个比较矩阵这比单独分析一个参数更有说服力。举一个实际跑过的场景样例固定 $\alpha 0.5$RkmQ_max 100Q_max 200Q_max 4003不可行不可行7座站总成本18205不可行6座站总成本16805座站总成本152088座站总成本19505座站总成本14304座站总成本1280107座站总成本17805座站总成本13404座站总成本1210读这张表要注意几个点。从左下角看当 $R3$、$Q_{max}100$ 时模型无解原因可能是候选点之间间距过大3公里半径内需求无法被任意3个候选点覆盖同时100次/天的容量上限又太小总容量可能低于总需求。这说明如果物理约束太紧那无论算法多优秀都不可能给出可行方案现实中的应对策略是减小半径内需求集中度或增加候选点数量。再看同一行 $R8$ 时$Q_{max}$ 从100提高到400站数从8座下降到4座总成本下降约34%。这说明在半径允许的前提下提高单站容量是更经济的方案——固定建设成本被摊薄了。但是容量超过200以后成本下降幅度就不明显了说明继续扩容的意义不大。这个“甜点区间”就是规划时优先争取的目标参数。这种联动分析的实际价值在于它不是单纯告诉你“最优方案是什么”而是告诉你“哪些约束是最值钱的”。如果候选站点能突破某个容量限制整体方案的成本能降低多少一目了然。汇报时有了这张表业务部门很容易理解他们应该优先协调的是哪块资源。4.3 敏感性分析后要做的一个补充实验做完敏感性分析我会额外做一个稳健性验证把需求数据加上扰动比如在原始 $q_i$ 上加随机波动正负10%重复求解多次看选址结果是否稳定。由于需求预测本身就带误差如果需求量变化10%导致选址方案完全跳变那这个模型对预测误差过于敏感决策风险就很高。这个实验在Matlab里做起来很自然在load_data之后加一个函数perturb_demand(q, ratio)对每个需求乘上1 ratio * (rand - 0.5) * 2然后重复调用build_model和solve_model20到30次统计每个候选点被选中的频率。如果某个候选点在大多数扰动场景下都被选中那么它在需求不确定性下具有稳健性属于“必选项”。如果有的候选点在部分场景被选中、部分场景被淘汰那它的优势比较微弱实际决策时要谨慎。这个方法花费的计算时间不多但对决策质量的提升非常明显强烈建议当作标准流程的一部分来做。5. 实际项目中的坑与经验总结这些弯路你别再走了最后一部分聊点代码和模型之外的实战经验。我做过不止一个选址类项目踩过的坑比看过的文献多这些经验用文字整理出来希望对你有用。5.1 数据的坑比算法多得多第一个项目我拿到的是模拟数据天然很干净跑起来一切顺利。到了真实项目发现数据质量才是真正的瓶颈。主要遇到过三类问题坐标缺失或漂移、需求量的时间分布不均衡、候选点的用地条件不统一。坐标漂移问题很好理解GPS打点有时候会偏出去几百米甚至几公里在清洗阶段就要用路网匹配或者缓冲区过滤做修正千万别直接用原始坐标。需求量要注意的是换电需求是分时段的早晚高峰和平时的需求强度差好几倍。如果建模时只用了日均需求那定容结果在高峰期大概率不够用。所以在真实项目中我会在建模前做一次需求的时间断面分析分别用“平日均值”和“高峰小时需求”两个场景跑两遍模型取保守解作为推荐方案。这个细节直接影响换电站的使用体验也是投资方最关心的问题之一。候选点的用地条件这一块实际规划中经常出现的情况是模型算出来某候选点应该在位置A建站但到了实地一勘探位置A的地是基本农田或者规划绿地根本拿不到。解决思路是在模型里加一个候选点分类的惩罚项或者干脆把不可用的候选点从集合里摘掉重新求解。另外我强烈建议提前收集候选点的产权、用地性质、电力容量条件这些在实际落地时都是硬约束越早进入模型越好。不要让模型浪费算力在一个不可能建站的点上。5.2 求解器参数调优的实战心得intlinprog默认参数对大多数小规模问题都够用但遇到大规划问题候选点超过100个、需求点和候选点的逻辑约束超过几万条时求解时间可能从几秒暴增到几分钟甚至更久。我总结出几个调优方向设置Heuristics参数为rss或round让求解器先快速找一个初始可行解。有一个可行解兜底非常重要即使后续求解超时你至少能交出一个可执行的方案而不是两手空空。好的初始解还能大幅加速分支剪枝的过程。设置BranchingRule为strong或pseudocost用更精细的分支策略换取分支次数减少。适合模型不是特别庞大但难求解的中等规模场景。不过对于几千个二值变量的超大问题强分支本身的计算开销也会上升需要实际测试权衡。设置CutGeneration为advanced在根节点多生成一些割平面可以显著收紧LP松弛的边界。对选址模型效果尤其明显因为这类模型的LP松弛解往往非常分数化割平面能有效提升收敛速度。如果求解时间还是不够理想回头检查约束规模。一个常见的无意识浪费是建设逻辑约束z_ij q_i * x_j对每一对(i,j)都生成但如果某个点在满足距离约束的候选站之外就不该生成约束。我们前面在compute_distance里把不可行距离设为inf并在build_model里用isfinite跳过了这一对这一步就能减少大量无效约束。5.3 模型结果的可解释性比最优解本身更重要做项目不是发论文不是给出一个最优解就完事。我每次把求解结果摆到决策者面前都会被问“为什么这里要建座站”“为什么那里不建”。这时候把分配关系图、需求热力图、容量利用率这些辅助结果一起拿出来解释比直接报一个总成本数字有说服力得多。我的固定动作是把每个站的容量利用率计算出来展示在汇报表格里。利用率过低的站比如低于60%要主动说明理由通常是覆盖偏远需求点的战略布点而非高负荷站点。利用率过高的站在模型中已经被容量上限锁住但在实际运营中要关注是否接近饱和可能需要预留扩容空间。这一层信息只有将模型结果和业务逻辑结合起来才能呈现出来也是方案能否顺利通过评审的关键。5.4 后续沿着这个项目还可以继续做哪些方向如果你把上面的流程完整跑通了恭喜你已经掌握了一个可以复用到多种设施选址问题的工具箱。顺着换电站选址这个场景还能继续扩展的方向包括在模型中引入时间维度把高峰期和平时的容量统筹优化或者在定容变量中加入充电桩的功率选择让每个站点在换电和充电之间按需调配。这个扩展的现实背景是很多换电站实际上是“换电站快充站”的混合场站利用率更高、收益结构也更稳健。另外如果把模型从单目标扩展到多目标比如同时考虑企业投资成本最小化和用户平均等待时间最小化可以做Pareto前沿分析。用intlinprog配合加权法或epsilon约束法循环求解能画出目标权衡曲线这为决策层提供的视角更完整。我个人的深刻体会是这类规划项目真正拉开差距的不是求解器的变量规模而是建模的颗粒度选择和数据分析的深度。一个把业务约束吃透的简化模型往往比一个数学上完美但脱离现实的复杂模型更受欢迎。把今天这套Matlab代码跑通之后你会慢慢形成自己的建模节奏——先建立数据体检意识再打磨模型边界条件最后用敏感性分析验证方案稳健性到这一步就已经能交出非常完整的工程成果了。