交通信号实时控制：数学建模与优化实战解析

简介：这份PDF收录了2008年全国研究生数学建模竞赛（华为杯）优秀论文，聚焦城市道路交通信号实时控制问题，适合数学建模竞赛备赛者、交通工程相关专业学生及对智能交通优化感兴趣的研究者参考。论文针对单个交叉路口、线状区域和网络区域分别建立实时配时模型，以总延误最小为优化目标，设计动态调整信号周期与绿信比的算法，并给出基于泊松分布的实时交通流序列生成方案。通过与传统韦伯斯特算法及固定配时方案比较，结果显示实时方案可将多个路口的等待时间分别缩短9.5%和11.3%，同时作者还提供了面向交通管理部门的咨询建议。资源包仅包含1个PDF文件，大小约782KB，内容完整清晰，便于直接阅读。目前已有92人学习下载，适合用来学习竞赛论文写作框架、模型构建思路和算法对比分析方法。

1. 一份2008年的交通信号控制优秀论文，为什么到今天还是参赛者的必读样本

2008年全国研究生数学建模竞赛的“城市道路交通信号实时控制问题”，是一道把工程现场和优化理论焊在一起的经典赛题：在给定路网结构和动态交通流的前提下，设计一套能随流量变化实时调整的信号配时方案。放在今天看，它的内核——多约束、非线性、在线优化——依然是华为杯研究生数学建模的高频方向，也是2026年全国大学生数学建模竞赛工程类赛题最爱出的类型。我每年带学生备赛都会把这类优秀论文翻出来重读，因为它的模型骨架和论文叙事，比很多新题示范得更清楚。适合三类人读：准备研究生数学建模竞赛的学生、想补交通建模基础的应用数学从业者，以及那些想知道“评审到底在一篇优秀论文里看什么”的写作者。

2. 把路口的交通流翻译成数学语言：排队模型、目标函数与一组约束

拿到这道题，最危险的动作是直接找算法。信号实时控制是一个离散时间、带约束的动态优化问题，前提是先把路口描述成计算机能算的对象。一个十字路口、四个进口方向、四个信号相位，这些几何和控制规则必须变成变量、参数和约束，后面才有“优化”可言。

2.1 先做路口拓扑与相位定义：没有几何就没有模型

先说单路口。一个十字路口有东西南北四个进口方向，每个方向有直行、左转和右转。实际控制中右转通常不受信号灯约束，所以模型里一般只考虑直行和左转，形成四个控制相位：东西直行、东西左转、南北直行、南北左转。这个相位划分是整道题的骨架，必须写进模型假设，否则后面的绿灯时长、黄灯时间全都对不上。

我一般用一套带单位约束的符号定义来落笔：

• 相位集合 P = {1,2,3,4}，每个相位对应一组互相不冲突的车流；
• 相位 i 的最小绿灯时间 g_min[i] 和最大绿灯时间 g_max[i]，单位秒。最小绿灯由行人过街时间决定，最大绿灯是为了防止某个方向长时间独占路口；
• 信号周期 C，是四个相位绿灯时间加黄灯时间的总和；
• 绿信比 λ_i = g_i / C，这是经典配时和实时控制里共同的核心参数；
• 车辆到达率 d_i(t)：相位 i 对应车流在 t 时刻的到达率，单位“辆/小时”；
• 排队长度 q_i(t)：停车线后等待的车辆数，单位“辆”；
• 饱和流率 s_i：绿灯期间该车道能够持续释放的最大车流率，通常取 1600～1900 辆/小时/车道。

这里最容易被参赛者忽略的是“车道”的粒度。一个进口方向如果画了两条直行车道，排队长度要除以车道数再进模型，否则延误会被放大两倍。2008年的优秀论文里，这个细节往往藏在表注里，但恰恰是它能区分“能用的模型”和“只停留在纸面的模型”。

如果要扩展到路网，还需要给每一条路段定义一个容量上限。排队溢出到上游路口是实时控制最怕的场景，所以路网模型里我习惯为每个路段加一个 max_queue 参数，这个参数到第5章会变成目标函数里的惩罚项。

2.2 目标函数选择：平均延误、排队长度还是通行能力

目标函数决定了整篇论文的优化方向。表里列的是三种最主流的定义：

2008年前后的优秀论文绝大多数选平均延误，因为它量纲清晰、仿真器可以直接输出。我在做同类赛题时也默认先看延误，但会额外加一个硬约束：任意相位预测排队长度不得超过路段容量。这等于逼优化器不能靠牺牲某条车道来换取整体数值好看。

延误的计算还有一个容易出错的地方。平均延误不是“红灯时间均值”，而是排队长度对时间的积分除以车辆数，即 D = ∫ q(t) dt / N。在离散仿真里，这个积分退化成每个步长的排队长度累加。很多队伍把延误直接写成“红灯秒数”，结果优化目标跟没优化一样。

2.3 一段可以直接改着用的模型定义代码

下面这段是我在类似赛题里最常用的建模骨架，用 Python 的 dataclass 定义信号相位，然后写一个最小化总延误的目标函数：

from dataclasses import dataclass @dataclass class SignalPhase: name: str # 相位名：如 'EW_直行' min_green: float # 最小绿灯时间（秒） max_green: float # 最大绿灯时间（秒） yellow: float = 3.0 # 黄灯时间（秒） arrival_rate: float = 0.0 # 到达率（辆/小时） sat_rate: float = 1800.0 # 饱和流率（辆/小时/车道） def objective_delay(greens, phases, C, queue_init): """计算一个周期内的总延误（单位：辆秒）""" total_delay = 0.0 for g, phase in zip(greens, phases): # 绿灯期间能放行的车辆数 release = min(queue_init[phase.name], phase.sat_rate * g / 3600) # 红灯期间排队车辆累计等待时间 red = C - g - phase.yellow total_delay += (queue_init[phase.name] - release / 2) * red return total_delay

逻辑说明：release用饱和流率乘以绿灯时间，再除以 3600 把小时单位换算成秒。red是红灯加黄灯的等待时间。queue_init[phase.name] - release / 2表示在红灯开始时排队车辆近似线性消散，取一个平均排队长度。这套算法在流量平稳时精度够用，突发波动时偏保守，但作为赛题初版模型没有大问题。

参数说明：min_green一般设在 5～15 秒，代表行人过街最短时间；max_green设在 30～60 秒，防止某一个相位垄断路口。arrival_rate和sat_rate的单位必须一致，都写“辆/小时”，我在命名里加_rate就是为了提醒自己别把单位混掉。

到这里，模型已经有完整的变量、约束和目标：变量是四个绿灯时间，约束是 g_i 的上下界以及周期 C 固定，目标是最小化延误。但“实时控制”这四个字还没体现，因为上面的目标函数是一锤子买卖。真正的实时性来自反复求解，也就是下一章要说的滚动时域优化。

3. 实时控制在数学上是什么：滚动时域优化与配时搜索算法

“实时”这两个字，是这道题和普通配时优化题最大的分水岭。很多队伍第一版模型做的是离线优化：给定一天里每个时段的平均流量，算出一套固定配时。这在流量稳定的场景里完全够用，但只要上游发生事故、天气变化或临时管制，固定配时立刻失效。实时控制要做的，是每个控制周期根据当前排队状态重新算一遍绿灯时长，而不是抄历史均值。

3.1 为什么静态绿信比会在交通流突变时翻车

我见过一个很典型的翻车案例。某路口早高峰左转流量从 300 辆/小时突然涨到 600 辆/小时，固定配时里左转相位只给 18 秒绿灯，结果左转车道排队不断溢出，左转车辆堵住直行车道，整个路口通行能力下降接近三成。这是静态配时的硬伤：绿信比按历史均值标定，没有反馈回路，流量一旦偏离假设就只能在原地等绿灯。

这里有一个基本判断：如果到达率稳定，固定配时已经接近最优；如果到达率在半小时内波动超过 20%，离线优化就基本失效。参赛题目要你做的，恰恰是后一种情形。实时控制的数学本质就是加一个负反馈：测量排队 → 计算最优配时 → 执行 → 再测量。

3.2 滚动时域优化的三个参数：预测步长、控制步长与更新周期

实时控制最常见的落地框架是模型预测控制，也就是俗称的滚动时域优化。核心思想很朴素：不要一次性把未来一小时的配时全算出来，而是只算未来 N 个周期的配时，执行第一个周期，然后看新的排队状态，再重新优化。每一轮都在用最新数据修正模型误差，这就是“滚动”二字的来源。

三个参数直接决定控制效果：

• 预测步长 N_p：往前预测多少个信号周期，通常取 3～5。太短看不到排队的远期后果，太长计算量爆炸而且预测不准；
• 控制步长 N_c：本次优化要决策几个周期的绿灯时间，我一般取 1～2，并强制 N_c ≤ N_p。控制步长越大，配时越平滑，但对预测误差越敏感；
• 更新周期 T_u：每多久重新优化一次。可以和信号周期相等，也可以半个周期更新一次。更新太快会拿同一组排队数据算重复结果，更新太慢就退化成周期级配时了。

这三个参数配在一起，控制逻辑就是：读排队长度 → 预测下一段到达 → 优化未来的配时序列 → 只执行第一个周期的绿灯 → 再读排队。这个循环每 T_u 秒转一次，就是评审口中“实时”的证据。

3.3 配时搜索怎么搜：从穷举到遗传算法的一个最小实现

模型有了，剩下的是怎么搜。绿灯时间是整数秒，单路口四相位的搜索空间其实不大：固定周期 C 后，四个绿灯时间只需要枚举三个，另一个由周期约束补齐，组合数大约几千到几万，穷举完全可行。但一旦进入干线或多路口协调，组合数会爆炸，这时候遗传算法或粒子群就派上用场了。

我写过一个通用遗传算法骨架，专门用来搜路口配时。它依赖第2章的objective_delay，适应度是负延误，外加排队溢出惩罚：

import random def fitness(greens, phases, C, queue_init, lane_cap=40): """总延误越小适应度越高，溢出按每辆100分重罚""" delay = objective_delay(greens, phases, C, queue_init) for g, phase in zip(greens, phases): # 预测本周期结束后的剩余排队 q_pred = max(0, queue_init[phase.name] - phase.sat_rate * g / 3600) if q_pred > lane_cap: delay += (q_pred - lane_cap) * 100 return -delay def ga_search(phases, C, queue_init, pop_size=50, gens=40): # 初始化种群：每个个体是一条四元绿灯配时 pop = [] for _ in range(pop_size): ind = [random.randint(p.min_green, p.max_green) for p in phases] # 最后一个相位的绿灯时间由总周期扣掉黄灯后补齐 ind[-1] = max(phases[-1].min_green, C - sum(ind[:-1]) - sum(p.yellow for p in phases)) pop.append(ind) for _ in range(gens): scored = sorted(pop, key=lambda x: -fitness(x, phases, C, queue_init)) pop = scored[:10] # 精英保留 while len(pop) < pop_size: p1, p2 = random.sample(scored[:20], 2) cut = random.randint(1, 3) child = p1[:cut] + p2[cut:] # 单点交叉 if random.random() < 0.2: i = random.randint(0, 3) child[i] = random.randint(phases[i].min_green, phases[i].max_green) pop.append(child) return scored[0]

逻辑说明：ind[-1]那一行很关键，它保证四个绿灯加上黄灯和时间刚好等于周期 C，避免搜出一组物理上不可执行的配时。适应度里的溢出惩罚用的是绝对量，(q_pred - lane_cap) * 100，这一百倍是把排队溢出折算成延误的经验设定，数值可以按仿真结果调。遗传算法的pop_size=50和gens=40是单路口够用的经验值；做干线协调时，种群调到 100 以上，迭代次数翻倍，否则很容易早熟。

有了搜索算法，单路口的闭环就转起来了。但很多队伍在这里就停住，直接把单路口模型往路网上套，结果发现相邻路口的相位差完全没有建模，绿波带自然无从谈起。这是下一章要解决的问题。

4. 从单路口到干线协调：相位差建模与绿波带约束的落地细节

如果赛题只要求单路口实时控制，前两章已经足够。但“城市道路交通”这四个字意味着路网，而路网上最典型的控制场景就是干线协调：让主干道上连续几个路口的绿灯按时间错开，使车队能一路绿灯通过。错开的这个量叫相位差，它是干线控制里真正的灵魂参数。

4.1 相位差是什么：两个路口绿灯起点的时间差

假设路口 A 和路口 B 相距 400 米，设计车速 40 km/h，那么车队从 A 到 B 大约需要 36 秒。如果 B 路口主干道相位的绿灯起点比 A 晚 36 秒，车队到达时正好赶上绿灯。这个“晚 36 秒”就是相位差。

相位差的数学定义写出来很短：offset_AB = (g_start_B - g_start_A) mod C。但在实时场景里，这个值不是固定不变的，因为每个路口的周期可能不同。为了让干线协调成立，第一条约束是所有路口必须使用同一个公共周期 C_common。这等于给每个路口的独立优化套上一层紧箍：有的路口单独算最优周期是 90 秒，为了配合整条干线只能调成 100 秒。这个损失换来的，是整条干线的连续性收益。

计算相位差时最容易错的是方向。干线控制里车队有两个方向（上行和下行），A 到 B 的相位差和 B 到 A 的相位差不相等，除非两个方向行程时间完全一致。我习惯先把单向行程时间算清楚，再决定以哪个方向为基准，否则绿波带会在某个方向上彻底消失。

4.2 绿波带建模：带宽才是干线控制的核心指标

绿波带指的是主干道上两个方向连续绿灯时段重叠出来的时间窗口。设每个路口主干道相位的绿灯区间为 [s_i, e_i]，那么整条干线能形成绿波的最大带宽，是所有路口绿灯区间的交集宽度。建模通常用线性规划：

• 决策变量：每个路口主干道相位绿灯起点 s_i 和绿灯时长 g_i；
• 约束1：绿灯时长落在 [g_min, g_max]；
• 约束2：相邻路口相位差等于行程时间，s_j - s_i = travel_time_ij + k × C_common；
• 目标：最大化所有路段带宽的最小值。

我对“带宽”的认知，是它不能太窄。带宽如果只有 5 秒，意味着车队只要稍有波动就会吃红灯，这种绿波带是中看不中用的。所以优秀论文里通常把带宽当作一条连续的可行域，而不是一个单值。评审看到“双向绿波带宽达到 18 秒”这样的结果，会比看到“延误降低 12%”更信任模型，因为带宽直接刻画了控制方案的鲁棒性。

4.3 多路口耦合后计算量暴增：分层控制是唯一现实路径

一旦把四个路口放进同一个优化问题，决策变量就不是四个绿灯时间了，而是每个路口的绿灯起点、绿灯时长和相邻路口相位差，总数轻松超过 20 个。用单路口的遗传算法参数直接搜，十有八九要跑十几分钟才收敛，而实时控制要求在几秒内给出配时。这个矛盾不是靠换一台好电脑能解决的。

我的习惯是分两层：上层做干线协调，只优化相位差和公共周期，频率低，比如每 5 分钟一次；下层做单路口实时控制，在满足上层给定相位差的前提下微调绿灯时长，频率高，比如每个周期一次。下层优化的可行域里加一条相位差约束，相当于把干线绿波固定成外部条件，路口只能在这个范围内做局部优化。这样既保住绿波，又保留单路口的实时灵活性。这也是很多华为杯优秀论文里出现“协调层-控制层”结构的根本原因，不是为显得高级，而是计算量真的不允许所有变量同时在线求解。

我用一张表来表达这种分工：

这张表放到论文里，比用三百字描述“两级优化”要直观得多。评审一眼就能看到你的方案把计算压力分到了哪一层，也不会追问“这么多变量在线求解怎么来得及”。

4.4 一个容易被忽略的约束：公共周期的取值范围

公共周期不是随便定的。它既要大于每个路口的最小周期，又要小于最大周期，否则某个路口的绿灯时长会突破边界。我一般先单独求解每一个路口的自由最优周期，再取所有周期值的加权平均作为初值。如果初值导致某个路口绿灯时间下限被突破，就把公共周期上调 10 秒再试。这是试出来的经验，没有太高深的道理，但能省去后面一堆返工。

5. 从模型到论文的5个避坑实录：那些让评审扣分的隐藏细节

这一章都是血泪经验。优秀论文读起来很顺，但自己动手写就会发现每个段落后面都藏着坑。以下五条是我在指导参赛时反复遇到的，按“现象 → 原因 → 解决”的格式写，可以直接对照检查自己的论文和代码。

5.1 流量单位错乱：把“辆/小时”当“辆/秒”，延误差出 3600 倍

现象：复现模型时算出的平均延误只有 0.03 秒，怎么看都不合理，但程序语法完全正常。 原因：到达率用“辆/小时”，饱和流率却写成“辆/秒”，两个量在目标函数里直接相乘，没有单位检查。 解决：所有流量统一用“辆/小时”，release = sat_rate * g / 3600里的 3600 是小时到秒的换算。我在第2章的代码里把字段名写成arrival_rate和sat_rate，就是为了在命名层面逼自己保持单位一致。更保险的做法是在函数开头加一句assert phase.arrival_rate < 10000，如果哪个数大得不合理，会在运行早期暴露。

5.2 相位顺序没写清楚：黄灯和全红损失时间被忽略

现象：仿真跑出来每个周期都有几秒“真空期”，没有相位亮绿灯，路口总通行量明显偏低。 原因：模型里只定义绿灯时间，没把黄灯和全红清空时间算进周期。实际信号控制中，相位切换之间一般有 3 秒黄灯，有的还带 1 秒全红，这些时间车辆不能正常通行，属于损失时间。 解决：在目标函数里把有效绿灯时间定义为g_i - loss_i，或者更直接，在周期约束里加一项sum(yellow_i) = L，让 C = sum(g_i) + L。这样搜索出来的绿灯才是真正能放行的时间，而不是名义绿灯。第3章遗传算法里ind[-1]那一行的sum(p.yellow for p in phases)就是在做这件事。

5.3 只优化平均延误：某方向排队溢出被完美掩盖

现象：算法报告平均延误下降 20%，但实际仿真里东西向左转车道的排队已经堵到上游路口。 原因：平均延误是全局指标，会把局部溢出平均掉。优化器发现只要牺牲一条车道，其他三个方向都能获得绿灯收益，于是它在数值上做出了“正确”的局部最优，但这不是交通上能接受的解。 解决：把排队溢出写进目标函数或约束条件。我在第3章的适应度函数里已经示范了：预测排队超过车道容量后，每超一辆加 100 分惩罚。这相当于给优化器画了一条高压线，让它不敢把某条车道逼近极限。

5.4 灵敏度分析范围给太窄：评审追问“为什么只扫 ±5%”

现象：论文里的灵敏度分析只给了到达率 ±5%，评审当场质疑现实中流量波动可能超过 30%，结论还能不能成立。 原因：把灵敏度分析做成了形式，参数范围挑得恰好能让结论不变，这样写出来的图再漂亮也没有说服力。 解决：至少对三个关键参数做宽范围扫描：到达率达到率 ±30%、饱和流率 ±15%、黄灯时间 ±1 秒。画出目标函数随参数变化的曲线，把参数失效的边界标出来。如果结论在某个区间不成立，就把它写成“本文方案在 30% 流量波动以内有效，超出后建议切换到协调层重新标定”，这反而是一条更可信的结论。

5.5 摘要写成数学模型目录：没有数值结果就没有记忆点

现象：摘要里通篇列模型名称，评审看完整段不知道方案到底把延误降了多少，也不知道模型在什么场景下有效。 原因：把摘要当“目录”，以为把方法列全就算交代清楚，这是很多参赛论文的通病。 解决：摘要里必须出现至少三个数字：基础配时延误、优化后延误、提升百分比。即使是仿真结果，也比“建立了某某模型”这种空话有力量。对华为杯研究生数学建模优秀论文的评审尤其如此，评委一天要看几十本，能记住的就是摘要里那几组数字。写摘要的顺序应该是：问题是什么 → 我们做了什么 → 结果提升了多少 → 结论在什么范围内成立。

6. 用今天的工具链复现2008年赛题：从仿真对比到答辩准备

最后说一条能立马上手的复现路径。2008年那会儿开源交通仿真器不像今天这么普及，但现在的 Python 生态已经把整套流程简化了很多。我的建议是不要停留在手算公式，直接把模型跑进仿真器里，用结果倒逼模型修正。

6.1 用 Python 接 SUMO 搭一个实时控制闭环

SUMO（Simulation of Urban MObility）是开源交通仿真器，它的 TraCI 接口允许 Python 在仿真运行中读排队长度、改信号灯时长。下面是最小的一段控制循环：

import traci traci.start(["sumo-gui", "-c", "my_intersection.sumocfg"]) step = 0 phase_ids = ["0", "1", "2", "3"] # 四个信号灯组ID while step < 3600: # 仿真1小时 traci.simulationStep() queued = {} for lane_id in traci.lane.getIDList(): queued[lane_id] = traci.lane.getLastStepVehicleNumber(lane_id) # 每100秒重新算一次配时，模拟滚动时域 if step % 100 == 0: new_greens = ga_search(phases, C=100, queue_init=queued) for i, g in enumerate(new_greens): traci.trafficlight.setPhaseDuration(phase_ids[i], g) step += 1 traci.close()

逻辑说明：traci.lane.getLastStepVehicleNumber拿到的是每个车道当前停留的车辆数，直接用整数排队长度喂给优化器。step % 100 == 0是滚动时域的更新节奏，这里等价于每 100 秒调一次配时，刚好对应一个信号周期。真正比赛时可以把更新周期改到 50 秒，观察结果变化，判断哪个更新频率最适合你的路网。

6.2 结果对比的三个指标：延误、停车次数与排队溢出

对比方案时不要只看延误。我建议至少输出三项：平均延误随时间的变化、最大排队长度随时间的变化、路段吞吐量的累计曲线。固定配时与实时控制的最大差别往往不在平均延误，而在排队溢出的次数和持续时间。

这张表是典型的论文结果表。注意把对比的场景写清楚：用的是早高峰流量，还是随机扰动流量。没有场景说明的数字，评审会认为结论不完整。

6.3 把方案讲成一个故事：答辩准备的叙事主线

最后一件容易被忽略的事，是把论文讲成故事。我见过很扎实的论文在答辩时翻车，因为学生只会念公式，说不清楚“你的模型和经典 Webster 配时法到底差在哪”。控制主题的叙事主线应该是这条：历史数据告诉我们流量不稳定 → 固定配时在突变场景下失效 → 我们引入滚动时域反馈，配合干线协调 → 仿真验证在流量突增场景下延误降低多少、溢出减少多少。这条主线里有对比、有数字、有可复现的仿真，比罗列十个算法要强得多。

我做了这些年竞赛辅导，最后形成的习惯是：拿到任何一道赛题，先写一个最笨但能跑的模型，再谈优化。2008年这道题的价值恰恰在于它提醒我，实时控制的核心不是算法炫技，而是把闭环反馈做扎实。只要你在自己的方案里把“测量-优化-执行”这个循环完整走一遍，再把这个循环讲清楚，就已经超过了相当一部分参赛队伍。希望帮到你。

本文还有配套的精品资源，点击获取