1. 赛题回顾与核心价值剖析2023年的MathorCup高校数学建模挑战赛B题题目是“城市轨道交通列车时刻表优化问题”。乍一看这又是一个经典的“排班”或“调度”优化问题似乎了无新意。但当我带着队伍深入进去并和圈内几位负责过实际地铁运营规划的朋友交流后发现这道题远不止是纸上谈兵它精准地戳中了当前城市轨道交通运营中的一个核心痛点如何在提升运营效率与保障服务水平之间找到一个动态的、精细化的平衡点。这道题的价值在于它用一个高度简化的模型引导我们这些未来的工程师或研究者去触碰一个真实的、复杂的系统工程问题。题目给出了一个虚构的轨道交通线路包括车站数量、站间距、列车参数如最高速度、加速度、客流需求OD矩阵即从哪个站到哪个站有多少人以及运营成本单位时间能耗、停站时间成本等。要求我们设计一个列车时刻表优化目标是在满足客流需求的前提下最小化乘客的总等待时间和企业的总运营成本。这听起来像是一个多目标优化问题而难点恰恰在于这两个目标本质上是冲突的。多发车、高密度乘客等待时间短体验好但企业空驶率高能耗大成本飙升反之少发车、拉大发车间隔成本是降下来了但站台上乌泱泱的乘客和不断累积的等待时间又会引发服务投诉和潜在的安全隐患。所以评价这道题不能只看它用了什么算法遗传算法、模拟退火、线性规划更要看它通过这个场景考察了参赛者哪些核心能力。我认为它是一次对“系统思维”和“建模艺术”的集中检验。你需要把一个实际的运营问题抽象成数学语言你需要理解客流“潮汐性”早高峰进城方向客流大晚高峰出城方向客流大对时刻表的影响你需要在复杂的约束列车追踪间隔、车站折返能力、车辆段出入库限制中寻找可行解最后你还需要用合理的算法去求解这个大规模的组合优化问题。这几乎涵盖了数学建模竞赛考察的所有维度问题分析、模型建立、算法求解和结果阐释。2. 问题拆解与建模思路的多元选择面对这样一个问题第一步也是最关键的一步就是拆解。你不能一上来就想着套一个现成的算法模板。我们的思路是将整个“时刻表优化”问题分解为几个层次清晰、可逐步求解的子问题。2.1 第一层基础时刻表框架生成这是骨架。我们需要确定一天中不同时段如平峰期、早高峰、晚高峰的发车间隔。这里直接使用简单的“等间隔发车”是粗糙的但可以作为基准。更优的做法是根据每个时段的客流总量动态确定发车间隔。一个常用的启发式公式是发车间隔与客流强度的平方根成反比。也就是说客流越大发车应该越密但并非线性增加因为要考虑边际效益递减车太密了后车可能拉不到客空跑浪费。注意题目给出的OD客流是静态的全日总需求但实际建模时我们必须将其按比例分配到各个运营时段模拟出动态的客流需求曲线。这是模型是否“逼真”的第一个关键点。我们参考了历史地铁客流数据假设早高峰7:00-9:00和晚高峰17:00-19:00的客流占全天的60%并进一步区分了上行进城和下行出城的方向不均衡性。2.2 第二层列车停站方案设计这是血肉。不是所有列车都需要站站停。快慢车混跑是提升长距离乘客体验、减少列车总旅行时间的有效手段。这里就需要做决策哪些车是站站停的“慢车”哪些车是跳站停的“快车”快车的停站模式如何设定我们采用了“基于客流OD的贪婪筛选法”。具体步骤是计算每一段区间相邻两站的断面客流量即该区间上运行的乘客数量。计算每个车站作为起讫点的客流量。设定一个阈值对于断面客流量低于阈值的区间考虑让部分列车不停站通过对于作为起讫点客流量都很小的车站考虑让部分列车不停靠。设计2-3种固定的快车停站模式例如只停靠客流大站在时刻表中穿插安排。实操心得快车模式不宜过多过杂否则会给乘客记忆和实际调度带来混乱。一般不超过3种。并且快车前后最好安排站站停列车以服务被跳过的车站的乘客。这本质上是一种“损失局部效率换取全局收益”的权衡。2.3 第三层多目标优化模型建立这是灵魂。我们将问题形式化为一个多目标优化模型。决策变量每个车次的发车时间、使用的列车交路即运行路线含停站方案。目标函数1乘客等待时间这需要模拟乘客的到达。我们假设乘客到达服从泊松过程那么平均等待时间约为发车间隔的一半。但更精细的建模需要考虑乘客的换乘本题单线无需考虑和车厢内的拥挤度当一趟车无法容纳所有等待乘客时部分乘客会滞留等待时间增加。目标函数2企业运营成本主要包括列车运行能耗与运行时间、启停次数相关和列车使用数量固定成本。能耗可以简化为与运行时间成正比的模型。约束条件包括最小发车间隔防止追尾、最大发车间隔保证基本服务、列车折返时间、首末班车时间等。难点在于两个目标量纲不同直接相加不合理。我们采用了加权求和法将其转化为单目标但权重的选择极具主观性。更科学的做法是采用帕累托Pareto最优前沿分析即求出一系列解在这些解中任何一个目标的改进必然导致另一个目标的恶化。这样可以将权重选择的问题留给决策者地铁公司建模者只提供“最优解集”。3. 求解算法从精确到启发式的策略博弈模型建好了怎么解这是一个大规模的、混合整数非线性规划问题几乎不可能求出精确的全局最优解。竞赛中大家比拼的就是如何设计高效、智能的启发式算法。3.1 经典元启发式算法的应用与改良我们团队尝试并对比了三种主流算法遗传算法GA这是最自然的选择。我们将一个完整的时刻表编码成一条“染色体”。编码方式很关键。我们采用了“发车时间序列列车类型序列”的混合编码。例如一天的发车时刻用一串时间点表示每个时间点对应一个数字代表此时发出的列车是“站站停”还是“大站快车”。交叉和变异操作需要精心设计以保证生成的新时刻表仍然满足最小发车间隔等硬约束。模拟退火算法SA相比GASA实现更简单适合在局部进行精细搜索。我们的邻域操作包括随机微调一个车次的发车时间、随机交换两趟列车的停站方案、随机增加或删除一个车次。降温策略采用经典的对数降温。蚁群算法ACO我们将列车排班过程类比为蚂蚁寻找路径。每只“蚂蚁”从头到尾构建一个车次选择发车时间和停站模式时信息素浓度高的选择即历史上能带来好目标函数值的选择被选中的概率更大。ACO在解决这类顺序决策问题上表现出色。算法优点缺点我们的改进策略遗传算法(GA)全局搜索能力强易于并行收敛速度慢参数种群大小、交叉变异率敏感采用“精英保留”策略避免优秀个体丢失引入自适应交叉变异概率模拟退火(SA)结构简单避免陷入局部最优收敛速度慢对初始解和降温 schedule 依赖大初始解采用基于客流的不均匀间隔时刻表降温后期结合局部搜索蚁群算法(ACO)正反馈机制善于发现优质路径计算开销大初期信息素匮乏时搜索盲目信息素更新时同时考虑乘客等待时间和运营成本两个目标设置信息素挥发下限踩坑实录最初我们用GA随机生成初始种群结果很多个体根本不满足最小发车间隔约束导致前期进化效率极低。后来我们改为用启发式规则生成可行的初始时刻表作为种群种子算法收敛速度立刻提升了一个数量级。这告诉我们在运用智能算法前用领域知识这里是运营规则提供一个好的起点远比算法本身的“智能”更重要。3.2 两阶段求解框架分解与协同在实际求解中我们最终采用了一个两阶段框架感觉效果和效率最平衡上层模型时刻表框架以小时或半小时为时段确定各时段的发车间隔和快慢车比例。这个模型规模较小我们可以用整数规划如调用Gurobi、CPLEX或枚举法求出一个相对较优的粗粒度方案。下层模型精细排班在已知每个时段发车数量和各类型车比例后在分钟级别上具体安排每一趟车的发车时刻和停站模式。这个阶段采用改进的遗传算法进行搜索决策空间大大缩小搜索效率更高。这个“先宏观后微观”的思路符合实际运营管理的逻辑也极大地降低了问题的复杂度。4. 模型评估与结果分析不止于数字算出结果了怎么评价好坏不能光看目标函数值那几个数字。我们建立了几个维度的评估体系4.1 核心指标计算与解读乘客平均等待时间我们模拟了10万名乘客基于OD矩阵和生成的时刻表随机到达车站统计其实际等待时间。这个值比理论值间隔一半更有说服力。企业单日总成本分解为能耗成本和车辆购置/租赁的日均折旧成本。这里有一个关键转换需要根据高峰时段所需的最大同时在线列车数反推需要配置的车辆总数。列车满载率曲线我们绘制了全天各区间、各方向列车的满载率变化图。理想状态是高峰时段满载率在80%-100%之间既充分利用运力又不过度拥挤平峰期在30%-60%之间。如果出现平峰期满载率长期低于20%说明发车太密浪费严重如果高峰时段满载率持续超过100%说明运力不足需要增加发车。4.2 敏感性分析与方案稳健性测试模型依赖于很多假设和参数比如客流预测值、能耗系数、乘客时间价值用于加权两个目标等。我们需要测试当这些参数在一定范围内波动时我们的最优时刻表是否依然“较优”。我们做了如下敏感性分析客流波动将OD矩阵中的客流量整体上浮/下浮10%重新运行模型。观察最优发车间隔的变化幅度。我们发现模型结果对客流总量变化相对敏感但对客流分布OD结构的变化鲁棒性较强。这意味着时刻表框架可以根据预测的总客流量调整但快慢车停站模式一旦确定不宜频繁变动。成本权重变化改变乘客等待时间与企业成本的权重比得到一系列帕累托最优解。我们向决策者展示的是一个“权衡曲线”清晰地告诉对方“如果您愿意多承担1万元成本乘客总等待时间可以减少XX小时”。将经济学中的“边际效益”概念引入分析。4.3 与基准方案的对比我们设定了两个基准方案进行对比方案A均匀间隔站站停最简单的方案也是很多城市地铁的初始方案。方案B仅分时段调整间隔比方案A精细一些考虑了潮汐客流但所有列车仍站站停。将我们的优化方案动态间隔快慢车混跑与这两个基准方案对比在相同的客流和成本参数下我们方案在“加权总成本”目标上提升了约15%-25%。这个提升主要来自于快车减少了长途乘客的在途时间以及更精准的发车匹配了客流需求减少了空驶能耗。5. 竞赛启示与延伸思考做完这道题和队友复盘时我们觉得收获远超一个奖项。它给我们带来了几个更深层次的启示第一数学建模是连接理论与现实的桥梁。题目中的数据是理想的但约束是真实的。最小发车间隔、折返时间这些硬约束背后是信号系统、轨道电路、司机操作等实实在在的工程技术限制。忽略它们模型再漂亮也是空中楼阁。第二“最优解”往往是“满意解”。在工程和运营领域由于信息不完全、未来不确定追求数学上的全局最优常常不现实也没必要。我们的目标是找到一个在多种评价标准下都“足够好”、且易于理解和执行的“满意解”。快慢车模式的设计就体现了这一点它可能不是理论上效率最高的但却是运营上最稳健、乘客最容易适应的。第三数据驱动与专家经验必须结合。我们的模型严重依赖客流OD数据。在实际中这部分数据可以通过AFC自动售检票系统精准获得。但模型无法涵盖所有因素比如突发大客流、设备故障、天气影响等。最终的时刻表一定是基于模型输出的方案再由富有经验的调度专家进行人工微调和确认。这道题也引出了可以继续研究的方向例如考虑动态客流将OD矩阵从静态的全日总量升级为以15分钟为粒度的动态矩阵实现真正的“实时响应式”调度。考虑网络化运营单一线路是基础但乘客出行往往涉及换乘。如何协调不同线路的时刻表减少乘客换乘等待时间是一个更有挑战性的网络优化问题。引入弹性运输能力比如在高峰时段采用“大小交路”部分列车只在线路中间段折返或“不对称发车”上下行发车间隔不同进一步提升运力调配的灵活性。回过头看2023年MathorCup B题是一道非常“正”的赛题。它没有追求怪异刁钻而是扎实地考察了学生运用数学工具解决系统性工程问题的全过程。它告诉我们一个好的模型不在于用了多高深的算法而在于是否准确地抓住了问题的本质并在理想与现实之间做出了恰如其分的折衷。这份在约束中寻找最优的艺术或许才是数学建模乃至所有工程实践中最迷人的部分。