★ FEATURED ARTICLE 简介本资源为2022年电工杯数学建模竞赛B题「5G网络环境下应急物资配送问题」的完整解题资料包面向参加数学建模竞赛的高校学生、希望学习路径优化与启发式算法的进阶学习者也可作为课程设计、大作业或工程实训的参考案例。资源共18个文件以11个Python脚本为核心涵盖蚁群算法、车辆路径规划与无人机协同配送等求解模块另含3个xlsx数据附件、1份赛题PDF说明及README文档压缩包约272KB结构清晰便于按模块查阅。目前已有209人学习下载。读者可从中获取完整的赛题建模思路、算法实现代码与数据文件理解卡车与无人机联合配送的建模过程、参数配置与求解流程并借助多版本算法脚本对比不同实现方式快速复现结果并迁移到同类应急物资调度场景中。1. 应急物资配送遇上5G这道题到底在考什么2022年电工杯B题把「5G网络环境下应急物资配送」摆上台面很多人第一反应是套一个VRP车辆路径规划模型就完事。但真正做过应急调度系统的人知道这题的核心矛盾不在路径算法本身而在于5G带来的实时性把传统「先规划后执行」的静态调度逻辑彻底掀翻了。灾区路况每分钟都在变物资需求点随时新增通信延迟从4G的几十毫秒压到5G的几毫秒——这意味着你的调度算法必须能在秒级完成重规划而不是离线跑一次遗传算法就交差。这道题适合三类人正在做应急物流调度的工程师、想拿数学建模竞赛练手的同学、以及需要把5G低延迟特性落到实际业务场景的产品经理。它解决的不是「怎么算最短路径」这种老问题而是「当通信不再是瓶颈时调度系统应该长什么样」。下面我从建模思路、代码实现、参数调优到踩坑记录把这道题拆成能直接复现的方案。2. 从题目到数学模型应急物资配送的约束怎么翻译成代码2.1 先搞清楚5G在这题里到底改变了什么传统应急物资配送建模通信延迟通常被忽略或者当成固定常数。但在5G环境下这个假设不成立了。5G的三个特性直接改写约束条件增强移动宽带eMBB让高清路况视频能实时回传超可靠低延迟通信URLLC让车辆与调度中心的双向指令延迟降到10ms以内大规模机器通信mMTC让每个物资包装上传感器成为可能。落到数学模型上这意味着三件事。第一需求点的物资消耗速率可以实时上报不需要按天预估。第二车辆位置和路况信息可以秒级更新路径规划从静态VRP变成动态VRP。第三调度中心可以同时监控上百台车辆和上千个需求点计算规模上去了但通信不再是瓶颈。我一般会把问题定义成在时间窗约束下最小化总配送时间和物资短缺惩罚的加权和。目标函数长这样min Z α * Σ(车辆行驶时间) β * Σ(需求点缺货惩罚) γ * Σ(车辆超时惩罚)其中α、β、γ是权重系数需要根据实际场景调。灾区场景下β通常要设得很大因为缺货的代价远高于多跑几公里。2.2 约束条件的形式化时间窗、载重、动态需求把题目里的文字约束翻译成数学表达式是建模最关键的一步。我见过太多人直接跳到写代码结果约束漏了导致结果不可行。时间窗约束每个需求点i有一个可接受的服务时间窗[ei, li]车辆到达时间ti必须满足ei ≤ ti ≤ li。如果提前到了要等待迟到了要罚。载重约束车辆k在任意时刻的载重不能超过Qk且配送过程中载重单调不增假设不回收。动态需求约束在时刻t新需求点集合N(t)可能增加车辆需要在线重规划。这是5G环境下特有的传统离线VRP不需要考虑。用Python把约束写成可调用的形式# 需求点数据结构 class DemandNode: def __init__(self, id, x, y, demand, e, l, appear_time0): self.id id # 节点编号 self.x x # 横坐标 self.y y # 纵坐标 self.demand demand # 物资需求量(kg) self.e e # 时间窗最早开始 self.l l # 时间窗最晚结束 self.appear_time appear_time # 动态出现时刻(5G场景) # 车辆数据结构 class Vehicle: def __init__(self, id, capacity, speed, start_depot): self.id id self.capacity capacity # 载重上限(kg) self.speed speed # 平均速度(km/h) self.route [start_depot] # 已规划路径 self.load 0 # 当前载重 self.current_time 0 # 当前时刻这段代码的关键在于appear_time字段。传统VRP里所有需求点一开始就存在但5G场景下需求点可能在配送过程中才出现。调度算法必须支持增量式插入而不是从头重算。2.3 动态重规划的触发条件与算法选型什么时候触发重规划我的经验是设三个触发器新需求点出现、车辆实际到达时间偏离计划超过阈值、路况变化导致预计行驶时间增加超过20%。这三个条件满足任意一个就触发。算法选型上静态VRP用遗传算法或模拟退火都行但动态场景下我推荐大邻域搜索LNS。原因很简单LNS的destroy-repair机制天然适合增量更新不需要每次从头搜索。具体做法是保留当前解的大部分结构只对受影响的局部区域重新优化。def should_replan(current_solution, new_events, threshold0.2): 判断是否需要触发重规划 current_solution: 当前调度方案 new_events: 新事件列表(新需求/路况变化/时间偏差) threshold: 偏差阈值 for event in new_events: if event[type] new_demand: return True # 新需求必触发 elif event[type] time_deviation: if abs(event[deviation]) / event[planned_time] threshold: return True elif event[type] traffic_change: if event[delay_ratio] threshold: return True return False参数说明threshold默认0.2意思是偏差超过20%才重规划。设太小会导致频繁重算设太大响应不及时。实际调的时候可以按场景改灾区核心区域可以降到0.1外围区域0.3也行。3. 用Python把调度算法跑起来从数据生成到结果可视化3.1 构造测试数据模拟一个灾区配送场景没有真实数据的时候自己造。我一般会生成一个50个需求点、5台车的场景需求点坐标在100x100的区域内随机分布时间窗按正态分布生成。import random import math def generate_scenario(num_nodes50, num_vehicles5, seed42): 生成应急物资配送测试场景 random.seed(seed) nodes [] # 仓库作为0号节点 nodes.append(DemandNode(0, 50, 50, 0, 0, 999, 0)) for i in range(1, num_nodes 1): x random.uniform(0, 100) y random.uniform(0, 100) demand random.uniform(10, 50) # 10-50kg # 时间窗以到达时间为中心宽度60分钟 center random.uniform(30, 180) e max(0, center - 30) l center 30 # 20%的节点是动态出现的 appear random.uniform(0, 60) if random.random() 0.2 else 0 nodes.append(DemandNode(i, x, y, demand, e, l, appear)) vehicles [Vehicle(k, 200, 40, 0) for k in range(num_vehicles)] return nodes, vehicles def distance(n1, n2): 欧氏距离 return math.sqrt((n1.x - n2.x)**2 (n1.y - n2.y)**2)这段代码里appear字段控制动态节点比例20%是个合理值。实际灾区场景可能更高但测试用20%够了。demand范围10-50kg对应应急物资水、食品、药品的典型重量。3.2 大邻域搜索的核心逻辑destroy和repair怎么写LNS的骨架就两步destroy移除部分节点和repair重新插入。destroy策略我常用随机移除和最差移除结合repair用贪婪插入加后悔值修正。def destroy_random(solution, num_remove): 随机移除num_remove个需求点 removed random.sample(solution[assigned], min(num_remove, len(solution[assigned]))) for node_id in removed: solution[assigned].remove(node_id) return removed def repair_greedy(solution, removed, nodes, vehicles): 贪婪插入被移除的节点 for node_id in removed: best_cost float(inf) best_pos None node nodes[node_id] for v_idx, vehicle in enumerate(vehicles): # 尝试插入到路径的每个位置 for pos in range(1, len(vehicle.route)): prev nodes[vehicle.route[pos-1]] nxt nodes[vehicle.route[pos]] # 插入成本 新增距离 时间窗惩罚 cost (distance(prev, node) distance(node, nxt) - distance(prev, nxt)) # 检查载重约束 if vehicle.load node.demand vehicle.capacity: continue # 检查时间窗 arrival vehicle.current_time distance(prev, node) / vehicle.speed * 60 if arrival node.l: cost 1000 # 大惩罚 if cost best_cost: best_cost cost best_pos (v_idx, pos) if best_pos: v_idx, pos best_pos vehicles[v_idx].route.insert(pos, node_id) vehicles[v_idx].load node.demand solution[assigned].append(node_id) return solutiondestroy_random里num_remove一般取总节点数的10%-20%。太小了搜索不充分太大了退化成随机重启。repair_greedy里的惩罚系数1000是个经验值要保证时间窗违反的代价远大于距离增加。3.3 主循环与收敛判断什么时候停LNS的主循环就是不断destroy-repair接受更好的解偶尔接受差解来跳出局部最优。停止条件用最大迭代次数加无改进次数双重判断。def lns_solve(nodes, vehicles, max_iter500, no_improve_limit50): 大邻域搜索主循环 # 初始解按时间窗排序后顺序插入 solution {assigned: [], cost: float(inf)} current_cost evaluate_solution(vehicles, nodes) best_cost current_cost no_improve 0 for iteration in range(max_iter): # 动态调整移除数量 num_remove random.randint(3, max(3, len(solution[assigned]) // 5)) removed destroy_random(solution, num_remove) solution repair_greedy(solution, removed, nodes, vehicles) new_cost evaluate_solution(vehicles, nodes) # 模拟退火接受准则 temperature 100 * (1 - iteration / max_iter) if new_cost current_cost or random.random() math.exp( (current_cost - new_cost) / max(temperature, 0.1)): current_cost new_cost if new_cost best_cost: best_cost new_cost no_improve 0 else: no_improve 1 else: # 回滚 no_improve 1 if no_improve no_improve_limit: break return best_cost, vehicles温度参数从100线性降到0这是模拟退火的标准做法。no_improve_limit设50意思是连续50次没改进就停。实际跑的时候可以打印每轮cost观察收敛曲线。4. 参数调优与动态场景适配让算法在5G环境下真正可用4.1 权重系数怎么定缺货惩罚和行驶时间的权衡目标函数里α、β、γ三个权重直接决定调度策略的倾向。我的经验是分场景设场景类型α行驶时间β缺货惩罚γ超时惩罚紧急救援1.050.010.0常规配送1.05.02.0均衡模式1.020.05.0紧急救援场景下β设50意味着一个需求点缺货的代价相当于多跑50单位距离。这个值不是拍脑袋来的是拿历史数据回归出来的——缺货导致的二次配送成本大约是正常配送的50倍。调参方法固定α1然后网格搜索β和γ。步长先粗后细先按10的步长搜找到大致范围后再按1的步长细化。4.2 动态需求插入的响应时间优化5G环境下用户期望的响应时间是秒级但LNS跑一次完整迭代可能要几百毫秒。优化思路是局部重优化新需求出现时只对距离最近的3台车做destroy-repair而不是全局重算。def local_replan(new_node, vehicles, nodes, radius30): 局部重规划只调整新节点附近的车辆 # 找到距离新节点最近的车辆 nearby [] for v in vehicles: last_pos nodes[v.route[-1]] if distance(last_pos, new_node) radius: nearby.append(v) if not nearby: # 没有附近车辆选载重最轻的 nearby [min(vehicles, keylambda v: v.load)] # 只对这些车辆做destroy-repair for v in nearby: # 移除路径中最后2个节点 removed v.route[-2:] v.route v.route[:-2] # 重新插入包括新节点 repair_greedy({assigned: []}, removed [new_node.id], nodes, [v]) return vehiclesradius参数控制局部搜索范围默认30对应3公里左右。这个值要跟5G覆盖半径匹配城区可以设小一点郊区设大一点。4.3 用真实路网数据替换欧氏距离欧氏距离在建模阶段够用但实际部署必须换成路网距离。常见做法是调地图API获取实际行驶距离和预计时间。这里不展开具体API调用只说数据结构怎么改。class RoadNetwork: def __init__(self): self.cache {} # 缓存已查询的距离 def get_distance(self, n1, n2): 获取路网距离带缓存 key (min(n1.id, n2.id), max(n1.id, n2.id)) if key not in self.cache: # 实际项目中这里调地图API # 这里用欧氏距离乘以1.4作为近似(路网绕行系数) self.cache[key] distance(n1, n2) * 1.4 return self.cache[key] def get_travel_time(self, n1, n2, speed): 获取行驶时间(分钟) dist self.get_distance(n1, n2) return dist / speed * 60绕行系数1.4是城市路网的典型值郊区可以降到1.2山区可能到1.8。这个系数直接影响时间窗可行性判断设小了会导致实际配送迟到。5. 避坑指南这道题我踩过的五个坑5.1 时间窗约束写成硬约束导致无解现象算法跑了几百轮始终找不到可行解所有车辆路径都违反时间窗。原因把时间窗写成了硬约束违反就不可行但实际场景中时间窗是可以软化的。灾区配送不可能100%准时迟到10分钟和迟到1小时的性质完全不同。解决改成软约束用分段惩罚函数。迟到0-15分钟罚1015-30分钟罚50超过30分钟罚200。这样算法有梯度可循不会一开始就卡死。5.2 动态节点插入时忘记更新车辆载重现象重规划后车辆实际装载量超过容量但算法显示可行。原因repair_greedy里只检查了插入时的载重但destroy阶段移除节点后没有同步减少vehicle.load。解决destroy和repair必须成对更新载重。我一般在destroy后立即执行vehicle.load - node.demandrepair时再加回来。这个bug很隐蔽因为最终解的载重看起来是对的但中间过程可能超载。5.3 模拟退火温度设太高导致解震荡现象cost曲线剧烈波动始终不收敛。原因初始温度100对这个问题规模来说太高了。温度高意味着接受差解的概率大算法在解空间里乱跳。解决初始温度按T0 -ΔE / ln(P0)来算其中ΔE是初始解和随机解的平均cost差P0设0.7。实际调的时候可以先跑10轮取平均cost差再算T0。5.4 5G延迟参数设成0导致模型失真现象仿真结果显示调度指令瞬间到达但实际部署时车辆响应有明显延迟。原因建模时把5G延迟当成了0。虽然5G的URLLC能做到10ms以内但端到端延迟还包括服务器处理时间、协议栈开销实际可能在50-100ms。解决在时间计算里加一个固定延迟项comm_delay默认0.1秒。这个值对路径规划影响不大但对实时性要求高的场景比如避障必须考虑。5.5 需求点坐标用经纬度直接算距离现象距离计算结果偏差很大路径明显绕远。原因经纬度是球面坐标直接算欧氏距离在纬度高的地方误差可达30%以上。解决先用Haversine公式算球面距离或者把经纬度投影到平面坐标系UTM投影再算欧氏距离。小范围场景城市级用等距圆柱投影就够了。6. 进阶技巧用滚动时域策略处理持续动态场景前面讲的LNS加局部重规划适合需求点偶尔新增的场景。但如果需求持续不断出现——比如灾区每隔几分钟就有新的求救信号——就需要滚动时域策略。核心思想是不要等所有需求都到齐再规划而是每隔一个时间窗口比如5分钟做一次规划只考虑当前已知的需求执行第一个时间段的方案然后滚动到下一个窗口。具体实现上把时间轴切成T个窗口每个窗口内跑一次LNS但只锁定前一个窗口的决策后面的可以调整。这样既保证了实时性又避免了频繁重算。def rolling_horizon(nodes, vehicles, window_size5, total_time120): 滚动时域调度 all_routes [] current_time 0 while current_time total_time: # 获取当前时间窗口内已知的需求 active_nodes [n for n in nodes if n.appear_time current_time window_size] # 跑LNS求解 cost, planned_vehicles lns_solve(active_nodes, vehicles, max_iter100) # 只执行第一个window_size时段的决策 for v in planned_vehicles: executed [] for node_id in v.route: node nodes[node_id] if node.e current_time window_size: executed.append(node_id) all_routes.append((v.id, executed)) current_time window_size return all_routeswindow_size设5分钟是个经验值。设太小会导致规划频繁但每次信息不足设太大响应不及时。实际调的时候可以按需求到达率来定到达率高就设小一点到达率低就设大一点。验证滚动时域策略的效果我一般看两个指标平均响应时间从需求出现到车辆出发和总配送成本。好的策略应该在响应时间上明显优于全局重算而成本增加不超过10%。最后说个血泪教训这道题我第一版代码跑了三天才发现时间窗的单位搞错了——题目给的是分钟我按小时算的结果所有车辆都「准时」得离谱。后来养成了一个习惯所有跟时间相关的变量都在命名里带单位比如arrival_time_min、service_duration_min再也没翻过车。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
