企业官网建设流程全解析

1. 为什么先用SUMO之前，得先弄明白交通流理论

说实话，我第一次接触SUMO的时候，最大的坎不是软件本身，而是里面的参数完全看不懂。什么minGap、speedFactor、accel、decel，挨个查完文档还是不知道该怎么填。后来才想明白，这些参数背后全是交通流理论的东西，不把基础理论补上，调参就是纯靠猜。

这期文章是SUM0系列的第二篇，专门把交通流理论基础捋一遍。这篇东西不会塞一堆数学公式吓唬人，而是讲清楚三件事：交通流的三个核心参数是什么、它们之间怎么互相影响、以及这些理论在SUMO里到底对应哪些按钮和配置项。搞懂这些之后，你再回头看那些仿真案例，思路会清晰很多。

适合谁看呢？刚接触交通仿真的学生、想用SUMO做毕业设计或者科研的人、还有工作中需要做交通评估的工程师，只要你对仿真结果不是“跑出来就行”的态度，而是想知道结果为什么是这样，这篇内容都能帮你把地基打牢。

2. 交通流三参数：流量、密度、速度怎么互相牵制

2.1 流量和密度的定义：别被公式吓到

交通流理论里最基础的三个概念就是流量（Flow）、密度（Density）和速度（Speed）。这三者的关系用一句话概括就是：流量等于密度乘以速度，写成公式就是：

[ q = k \times v ]

这里的q代表流量，单位是辆每小时（veh/h），指的是单位时间内通过某个断面的车辆数量；k代表密度，单位是辆每公里（veh/km），指的是某段道路上每公里分布了多少辆车；v代表空间平均速度，单位是公里每小时（km/h）。

这个公式和电流的欧姆定律有点像，电压等于电流乘以电阻，三者的关系是绑定的。但要注意，这里的速度不是某辆车仪表盘上的瞬时速度，而是所有车辆在一段路或者一段时间内的平均速度，专业术语叫空间平均速度。瞬时速度一辆车一个样，不能直接拿来做宏观计算，这也是新手经常搞混的地方。

在SUMO里，这三者对应的输出都在fcd（浮点车辆数据）或者检测器数据里。流量可以从e1检测器拿到，密度可以通过e2检测器（行程时间检测器）间接算出来，速度则看车辆的平均速度输出。你不需要自己在Excel里手算这些，但知道它们怎么来、怎么换算，对理解结果非常重要。

2.2 速度-密度关系：为什么堵车是必然的

速度-密度关系是交通流理论里最核心的一条曲线。直观解释就是，路上车越少，每辆车都可以放开跑，速度接近自由流速度；随着密度增大，车辆之间相互干扰加剧，速度开始下降；当密度大到一定程度，车流停下来，速度趋近于零，这时候对应的密度叫堵塞密度。

这个关系画出来是一条近似线性的曲线，最早由Greenshields在1935年提出，公式是：

[ v = v_f \times (1 - \frac{k}{k_j}) ]

v_f是自由流速度，k_j是堵塞密度。这个模型虽然简单到有些“粗糙”，但它的意义在于把“拥堵是怎么形成的”这一个复杂现象压缩成了一条清晰的关系线。

在SUMO里设置每条路的最大速度时，你实际上就是在设定v_f。比如城市主干道限速60km/h，那这条路的v_f基本上就是60。而k_j则和车辆长度、最小跟车距离有关，SUMO里每辆车的长度默认是5米，加上minGap（最小停车间距），基本决定了这条路上最多能塞多少辆车。

我做过一个对比实验：同一段2公里的路，把限速分别设置成80、50、30，流量峰值出现的时间点完全不同。限速80的时候，流量可以冲到2200辆/小时左右；限速30的时候，流量峰值只有1100左右。原因就是速度降低导致车辆通过断面的时间变长，单位时间能过的车自然就少了。

2.3 流量-密度曲线：理解拥堵的关键图

把速度和密度的关系带入流量公式，就得到了流量-密度曲线。这条曲线一开始随着密度增加，流量单调上升，这也是为什么大家总觉得“车多说明路忙”；但密度超过临界密度之后，流量反而下降，因为每辆车都跑不起来了。

曲线的峰值点对应的就是道路的通行能力，也就是单位时间内能通过的最大车辆数。过了这个点，道路进入拥堵状态，流量下降，但密度还在上升，这就是典型的“堵死在路上”的情况。

在SUMO里观察这条曲线有一个非常直观的方式：在一条路上逐渐增加车辆输入，从每小时500辆慢慢加到每小时2000辆，用e1检测器记录流量数据，再和密度数据画成散点图，你会看到典型的倒U形。我建议大家自己跑一次这个实验，五分钟左右就出结果，比看十篇论文都管用。

不过有一点要注意，SUMO里默认的跟车模型（Krauss模型）得到的流量-密度曲线和理论上的曲线还是会有些偏差的。因为SUMO的驾驶模型是离散时间步长的，车辆行为本身有随机性，曲线会更“碎”一些，但趋势是对的。不影响理解和应用。

3. SUMO里的车辆行为模型：微观仿真靠什么驱动

3.1 跟车模型（Car-Following Model）

SUMO最核心的微观模型就是跟车模型，它是决定“后车怎么跟着前车走”的规则集合。在SUMO里，默认的跟车模型叫Krauss模型，核心逻辑是：后车根据前车的速度和距离，计算出一个安全速度，让本车既不撞车，又能尽量保持较高速度。

Krauss模型的关键参数在SUMO的carFollowModel属性里配置。最常用的几个参数包括：

• accel：最大加速度，单位m/s²。默认值2.6，但城市公交车、货车这种大型车加速度低，要改成1.2左右。
• decel：最大减速度，单位m/s²。默认值4.5，这个参数决定了车辆刹车多猛，也直接影响仿真的“舒适感”。
• sigma：驾驶员的“不完美程度”，取值范围0到1，0表示完全完美驾驶，1表示随机性很大。默认值0.5，模拟的是现实里司机不会百分百精确跟车的情况。
• minGap：两辆车完全停止时的最小间距，默认2.5米，这决定了仿真里停车排队时车辆之间的空隙。

新手最容易踩的坑就是把accel和decel设置得特别夸张，比如把加速度调到10，以为这样仿真“更快”。实际上这会导致车辆起步猛、刹停更猛，车流变得极度不稳定，红绿灯路口经常出现幽灵堵车，仿真结果完全没有参考价值。我的建议是先保持默认值跑通，再根据研究目的微调，一次只动一个参数。

讲到数学模型，Krauss模型的核心思想是计算一个安全速度：

[ v_{safe} = v_{front} + \frac{gap - v_{front} \cdot t_{reaction}}{t_{reaction} + \frac{v_{front}}{2 \cdot decel}} ]

其中v_front是前车速度，gap是两车距离，t_reaction是驾驶员反应时间。SUMO里会在每个时间步长重新计算一次这个安全速度，然后车辆的实际速度就是min(当前最大速度, 安全速度)，同时加一点随机扰动。

3.2 换道模型（Lane-Changing Model）

除了跟车，车辆在高速上超车、在路口变道，都是靠换道模型驱动的。SUM0里默认的换道模型是LC2013，它综合考虑了换道的好处（能开更快）和风险（会不会撞车、会不会干扰后车）。

换道模型里有几个用户可调参数，比如lcStrategic（策略性换道的倾向），默认值4.0，越大车辆越倾向于提前换道为转弯做准备；lcCooperative（协作换道），默认值4.0，这个参数决定车辆是否愿意减速让其他车并线；lcSpeedGain（速度增益换道），默认值10.0，这个参数越大，车辆就越“急不可耐”地想换到快的车道上。

实际使用中，换道模型对仿真结果的影响往往比跟车模型更大。因为换道规则设置不当，会导致高速公路出入口区域严重堵塞，而现实中这个堵车并没有那么严重。在SUMO里检查换道是否合理，可以直接看fcd输出的车辆轨迹，观察车辆在匝道附近的行为是否符合常理。

另外一个要点是，SUMO不是每辆车都有相同的换道风格。你可以通过vType设置车辆的latAlignment参数来控制车辆在横向位置的选择习惯，比如大型车辆尽量靠右行驶。这种细颗粒度的控制在仿真大型货车混行场景时特别有用。

3.3 交通分配模型：车是怎么选路的

微观层面的跟车和换道解决了“单辆车怎么走”的问题，但还有一个更大的问题：每辆车为什么选择这条路线而不是另一条？

这就是交通分配模型解决的问题。SUMO里最常用的分配方法是DUARouter的“用户均衡”（User Equilibrium）模型，理论核心是：每位司机都会选择自己认为最短（或最快）的路径，最终达到一个状态——没有任何人能通过单独改变路线来减少自己的行驶时间。

说白了，这就是数学里的“均衡”概念：每个人都在为自己优化，最终谁都不愿意改变选择了。这个状态在交通规划里叫Wardrop用户平衡。你和“马克思主义政治经济学”里说的“每个人都追求利益最大化，社会达到某种均衡”有点像，但交通领域是物理意义上的均衡，可以通过迭代算法收敛到数值解。

在SUMO里跑duarouter时，--router-iterations这个参数控制迭代次数，默认是20次。车流需求越大、道路网络越复杂，需要的迭代次数越多。设置太小会导致流量分配不均，某些道路明明有空余，但车全挤在另一条路上；设置太大则计算时间暴涨，性价比极低。我个人的经验是一般40到60次就够用了，特殊场景再往上调。

4. 从理论到落地：SUMO里怎么把交通流模型配置出来

4.1 创建路网前的理论准备

在SUMO里搭一个仿真场景，很多人上来就画路网，然后往里面塞车流。但基于交通流理论，正确的做法是先问自己几个问题：

• 这条路的设计通行能力是多少？
• 我期望仿真的交通需求是多大？是欠饱和、饱和还是过饱和？
• 路段限速是多少，和交通流理论里的自由流速度怎么对应？

这些问题的答案会直接决定路网参数的设置。举个例子，假设你要仿真一个城市交叉口，南北向道路设计通行能力是每车道每小时1400辆车，那你给这条路输入的车流量就不能是3000，因为理论上游超饱和了，结果就会是路口排队越来越长，最后蔓延到上游道路，整个区域瘫痪。

SUMO里创建路网的方式有三种：用netedit手动画（适合小范围场景）、用netconvert导入OpenStreetMap数据（适合城市级路网）、或者直接用netgenerate生成抽象路网（适合快速验证理论）。

我强烈建议新手先试试netgenerate，因为它可以快速生成方格路网或者放射形路网，配合--grid.number之类的参数，几秒钟就能出来一个测试环境。在这些抽象路网上验证跟车模型、路口信号控制逻辑，比在真实路网上调试高效得多。

4.2 车流输入:从需求建模到流量设置

车流生成在SUMO中叫“交通需求”，核心形式是描述车辆出发时间、出发地点、到达地点的OD矩阵。最简单的形式是直接在rou.xml文件里写车：

<routes> <vType id="car" accel="2.6" decel="4.5" maxSpeed="16.67" sigma="0.5" /> <vehicle id="veh0" type="car" depart="0.00"> <route edges="edgeA edgeB edgeC" /> </vehicle> </routes>

但手动一辆一辆写车显然不现实，实际都是通过flow标签批量生成：

<flow id="flow_north_south" from="edgeA" to="edgeC" begin="0" end="3600" vehsPerHour="600" />

这里的vehsPerHour就是流量，单位是辆每小时。还记得前面的理论吗？600辆每小时对应到一条城市主干道单车道，大约是饱和通行能力的一半，属于比较顺畅的交通状态；如果你填1800，那基本上就是堵死状态。

有一点要特别注意：SUMO产生的车不一定刚好是vehsPerHour指定的那个数。因为flow标签的车辆到达时间是有随机性的，默认服从泊松分布，所以实际流量会有浮动。如果你要做严格的数值对比实验，建议把随机数种子固定下来，在netconvert或duarouter里设置--random的种子值，这样每次跑出来的结果才可复现。

4.3 检测器：怎么把理论参数变成可视化数据

在仿真里放检测器，就像是在真实道路上安装交通调查设备。SUM0提供了三种主要检测器：

• 点检测器（e1）：监控某个断面的流量、速度，相当于真实世界的线圈检测器。
• 区间检测器（e2）：监控某一段路的车辆数和平均速度，适合计算路段密度。
• 行程时间检测器（e3）：监控一个区域内的车辆旅行时间和延误，适合评估路网服务水平。

结合前文理论，如果你需要画出流量-密度曲线，就应该用e2检测器，因为它同时输出车辆数和平均速度，可以用车辆数除以路段长度得到密度。如果想要流量数据，用e1检测器就可以直接输出每小时通过多少辆车。

检测器配置要在额外文件（.add.xml）里写：

<additional> <e2Detector id="e2_west" lane="edgeA_0" length="500" freq="60" file="e2_output.xml" /> <e1Detector id="e1_north" lane="edgeC_1" freq="60" file="e1_output.xml" /> </additional>

运行SUMO时，通过--additional-files参数加载这个文件：

sumo-gui -n osm.net.xml.gz -r osm.rou.xml -a detector.add.xml

仿真跑完之后，检测器的输出是一个XML文件，里面记录了每个统计间隔的流量、平均速度、车辆数。建议直接把它导入Excel或者Python的pandas库里做二次处理，画图之后你会对交通流理论有非常直观的感受。

5. 常见问题与排查技巧实录

5.1 仿真的流量和设置值对不上

现象：在flow里设置了vehsPerHour="600"，跑完一看e1检测器统计的流量只有530，莫名其妙少了70多。

原因：车辆是从起始边的起点开始产生的，但如果起始边比较短，或者前车占位，新的车可能因为“找不到位置”而被延迟或者丢弃。另外，车辆不会像流水一样均匀到达，而是随机到达的，短时间内的统计值波动在理论上是正常的。

排查方法：先看--start和--end参数设置对不对，再看起始边长度是否足够容纳车辆排队，最后确认流量统计的时间间隔足够长（建议至少10分钟以上），如果间隔太短，统计噪声会很明显。

5.2 车辆突然紧急刹车导致全路堵死

现象：仿真跑了几百秒之后，一段路上所有车都停下来，像多米诺骨牌一样向后蔓延。

原因：这个现象在交通流理论里叫“幽灵堵车”，本质是局部扰动在后车放大效应下形成停-走波（stop-and-go wave）。在SUMO里，常见触发条件有两个：某个位置的maxSpeed突变，或者sigma值设置过大导致驾驶随机性太强。

排查方法：用fcd输出查看车辆轨迹图，找到速度骤变的位置。通常就是两段道路限速差异过大的接缝处，或者是出口匝道附近换道冲突集中区。解决方法是平顺速度变化，比如在两段道路之间插入一段过渡性的限速路段。另外，把sigma从0.5调低到0.2，车辆行为会更稳定。

5.3 路口排队溢出的判断和处理

现象：交叉口某个方向的左转车道排队太长，已经排到了上游路口，导致其他方向的车流也被堵住。

原因：这已经属于过饱和交通状态，理论上的通行能力已经不够用了。本质上是信号配时给的绿灯时间不足，或者输入流量超出了路口的承载力。

处理方法：从交通流理论的角度，先算清楚进口道的饱和流量，再根据绿灯时间验算通行能力，最后对比需求流量看是否超过。SUM0里可以通过e2检测器持续监控排队长度数据，配合信号配时工具（如TLSControlAPI）做自适应信号优化。不过这是进阶内容，先把基础的跑通再说。

5.4 路网导入后限速和车道数不对

现象：从OpenStreetMap导入的路网，在SUMO里跑出来的速度明显偏慢，某些路段车流不畅。

原因：OSM上的道路分类和限速信息在导入时会被SUMO映射成默认值。比如一条城市次干道可能被映射成了限速50km/h，但实际上这段路的物理限速可能只有30或者本身就是步行街，这就是路网属性的问题，不是仿真模型的问题。

建议：用netedit检查导入后的道路类型和限速设置。对于关键路段，手动修正限速。如果研究的是宏观路网特征，建议统一设定道路限速，避免不同道路类型之间速度差异过大导致的假拥堵。

6. 一些亲测有效的实操经验

最后分享几个我实际做仿真项目时攒下的经验：

第一，参数记录要规范化。每次修改任何模型参数，都记录下来：改了什么、为什么改、原来是多少、改完是多少。看起来麻烦，但当你回头看两个星期前跑的仿真结果时，这套记录能救你的命。很多人仿真结果对不上，就是因为不记得当初调过什么参数，只能全部推翻重来。

第二，先复现经典场景再研究新问题。SUMO自带的教程案例（比如docs/tutorials里的快速入门和高速公路案例）一定要亲手跑一遍。这些案例虽然简单，但能让你明确看到仿真结果和理论之间的对应关系。很多人一上来就导入真实城市路网，结果被各种细节问题淹没，两周过去连一个完整的仿真都没跑出来，就是因为基础知识没在手。

第三，多用netedit的“检查器”功能。点击任何一条边或者一个节点，右边会弹出属性面板，所有和交通流理论相关的参数都在里面。你可以直接修改speed、numLanes、priority这些属性并保存，然后重新仿真。这种方式比直接手改XML文件直观很多，适合新手。

说实话，交通流理论容易让人觉得远离实际，但SUM0恰恰是一个能把理论和现象连接起来的桥梁。当你看到仿真里一辆辆车因为跟车距离过近而减速，然后引发后面的连锁反应，你才能真正理解什么是交通流的“不稳定性”。建议每个想学好SUMO的人，都亲手跑一次“堵塞密度附近的小扰动传播”实验——这个过程比任何论文都能让你更直观地把握交通流的本质。