企业官网建设流程全解析

SUMO这个老牌开源交通仿真软件，我第一次把它当成“排放计算器”来用，还是在某城市一个信号配时优化项目里。当时要评估不同信号方案的空气污染物减排效果，结果发现很多现成工具要么只能算宏观总量，要么压根不考虑驾驶行为。后来把SUMO的逐车逐秒排放输出接进来，整个项目的说服力立刻不一样了。这篇文章就系统梳理一下，怎么用SUMO做交通排放与环境影响评估，从场景搭建、排放模型配置，到结果分析和容易踩的坑，全部按我实际跑通的经验来写，适合刚上手SUMO的交通专业同学，也适合想给方案加一层环境评估维度的工程师。

1. 为什么用SUMO做排放评估：它比宏观工具到底多看了什么

1.1 微观驾驶行为对排放的决定性影响

交通排放这件事，表面看是“车流量 × 排放因子”的简单乘法，但真正较真起来，插队、急加速、等待信号、走走停停这些微观行为对排放的影响极其显著。同样是1公里路程，匀速60公里每小时开过去，和一脚油门一脚刹车地蹭过去，油耗和氮氧化物排放可以差出一倍以上。宏观模型通常用平均速度查排放因子表，把整条路或整个道路等级当成一个均匀的整体，结果就是信号配时优化带来的“速度波动变化”完全反映不出来。

SUMO的核心价值就在这：它用跟车模型和换道模型逐秒模拟每一辆车的速度、加速度和位置，再把这些逐秒的工况数据输入到排放模型里，得到一条随时间变化的瞬时排放曲线。这种微观层面的敏感性，是评估“绿波带”“限速”“信号优化”这类策略时最需要的能力。

1.2 SUMO排放模型的内置能力与扩展性

SUMO并不是从零造排放模型，而是在软件内部嵌入了两套主流排放计算逻辑：一套是HBEFA基础版本，另一套是PHEMlight实时仿真模型。HBEFA全称是“道路运输排放因子手册”，覆盖了大量欧洲车型和不同行驶工况，SUMO把它简化成了一系列与速度、加速度相关的函数；PHEMlight则是格拉茨工业大学开发的瞬态排放模型，能根据车辆每秒的速度和加速度曲线实时计算排放率和燃油消耗。

实际使用中你不需要纠结哪个“更准”，而是看项目需求。欧洲项目或者已经有当地HBEFA因子表的时候，可以直接用HBEFA类；想评估某项新技术对瞬态工况的影响，例如混动和电动公交的加速策略，那么PHEMlight会更适合。SUMO还支持第三方通过TraCI接口实时读写车辆排放相关参数，等于把排放计算从“后处理”提升到了“在线闭环控制”的层面，可以做到实时监控，也可以做动态的限速控制实验。

1.3 什么样的项目适合用SUMO做排放评估

不是所有项目都适合上SUMO。如果你只想知道某条快速路全年总排放量，用COPERT之类的宏观工具就够了，成本低、参数少、结果也直观。但如果你的项目里出现了这几个词：信号配时优化、限速差异化、公交优先策略、货车禁行时段、拥堵收费方案，或者需要对比几种交通管理方案在污染物排放上的差异，那么SUMO就比宏观工具有明显优势。

这时候SUMO的价值在于“控制变量”做情景比较：保持路网、需求和车队参数不变，只改动一个管理策略参数，然后观测排放总量的变化趋势。虽然绝对数值不一定和实测完全吻合，但方案之间的相对优劣是比较可信的。我在某项目里就靠这个逻辑说服了业主：不是把排放总量报得多么精确，而是把“优化方案相对现状能减多少氮氧化物”算清楚，这才是决策者真正关心的东西。

2. 仿真场景搭建：路网、流量和驾驶行为参数的排放敏感度

2.1 从地图到SUMO路网：构建网络的最短路径

SUMO自带的netedit可视化网络编辑器支持手工建路，但从头画路网太不现实，常规做法是直接从开源地图数据里拉取路网，再用netconvert转换成SUMO格式。

我常用的流程是：先用netedit打开已有的OpenStreetMap导出数据，或者直接在OSM里选择一片区域导出，然后执行类似下面的命令：

netconvert --osm-files input.osm.xml --output-file network.net.xml \ --geometry.remove \ --roundabouts.guess \ --ramps.guess \ --junctions.join

转换之后务必在netedit里检查一遍：信号灯位置、车道方向、渠化是否正确，特别是交叉口的转向连接。排放计算是按车道逐段进行的，如果路网拓扑有问题，比如明明该停的车直接“瞬移”过去了，那么瞬时加速度会异常，排放数据直接失真。

2.2 OD需求与交通流量的加载

路网搭好之后就要往里塞交通需求。SUMO支持两种流量输入：静态路由文件里的车辆或流量标签、以及动态的OD矩阵。小型项目里，直接在routes.rou.xml里定义若干flow元素就足够了：

<routes> <vType id="car_petrol" emissionClass="HBEFA3/PC_G_EU4" accel="2.6" decel="4.5" maxSpeed="50"/> <flow id="f_ab" from="edgeA" to="edgeB" begin="0" end="3600" numberPerSec="0.08" type="car_petrol"/> </routes>

这里有个容易忽略的点：需求量的时间分布。很多新手只给一个全天总量，忽视了早晚高峰的时变规律。排放评估对拥堵程度极其敏感，高峰期的低速走走停停，和畅通时段的巡航，排放数据差异非常大。所以至少要把早高峰、平峰、晚高峰分开建三个仿真时段，分别做排放统计，再按小时加权得到全日结果。

2.3 容易被低估的驾驶行为参数：加速曲线和跟车模型

路网和流量都对了，排放还是可能差很多，问题往往出在驾驶行为参数上。SUMO默认的车辆类型里有accel、decel、maxSpeed、sigma等参数，这些直接影响了模拟中的速度曲线。

举个例子：一辆车在交叉口绿灯起步时，如果加速度预设为0.5米每平方秒，那它提速非常慢，后面的车跟着停停走走，排放自然上去；如果设置为3.0，起步猛加速，氮氧化物又会飙升。真实道路上是驾驶员行为分布综合的结果。SUMO提供了一个办法：在vType里设置不同的驾驶行为分布，例如CFM参数、速度分布和加速度分布，让车队呈现多样性。

我通常会做一次“驾驶行为敏感性测试”：把加速度参数从1.5到3.0分档跑一遍，观察排放总量的变化范围。如果某个策略的相对减排结论在不同驾驶行为参数下仍然保持方向一致，说明结论比较稳健；如果方向都变了，那说明这个策略本身的排放效应很脆弱，需要谨慎下结论。

2.4 一个排放评估基准场景的配置示例

做一个标准的基准场景，至少需要三个文件：network.net.xml（路网）、routes.rou.xml（需求）、sumo.cfg（配置）。配置文件里除了输入文件路径，还要挂上排放输出参数：

<configuration> <input> <net-file value="network.net.xml"/> <route-files value="routes.rou.xml"/> </input> <time> <begin value="0"/> <end value="7200"/> <step-length value="1"/> </time> <emission> <emission-output value="emissions.xml"/> </emission> </configuration>

仿真跑完之后，emissions.xml会把每辆车在每秒的速度、加速度、油耗和污染物排放全部记录下来。注意这个文件会非常大，一个中等路网跑两个小时仿真就能生成几GB的XML。所以实际项目里我一般不是直接全量输出，而是先把仿真跑通，确认路网好了需求对了，再打开排放输出做正式计算。

3. 排放模型接入与配置：HBEFA和PHEMlight之间的选择

3.1 SUMO中的排放模型体系：简化模型和微观模型

SUMO自带的排放模型大致可以分成两个层次：一个是基于HBEFA简化系数表的模型，它把排放率表示为速度和加速度的二次或三次多项式，查表快速但精度有限；另一个是PHEMlight这类微观瞬态模型，它把每一辆车的发动机功率请求、转速和扭矩计算出来，再映射到污染物排放率上，计算更精细但同时要求车辆参数更完整。

选择哪一层，取决于你能获取到的车辆参数和项目的精度需求。做区域交通策略评估时，HBEFA简化版已经够用；做隧道口、交叉口附近局部热区分析时，我更倾向PHEMlight，因为它在低速高负荷工况下的氮氧化物排放变化更灵敏。SUMO文档里的Emission模块完整列出了两种模型对应的排放类别命名规则，例如HBEFA类下的HBEFA3/PC_G_EU4，PHEMlight类下的PHEMlightDemo/PC_G_EU4，实际配置时只要把这串代码填到车辆或vType的emissionClass属性里即可。

3.2 车辆类型、燃料类型和排放标准的对应关系

排放模型里最核心的是“车辆类型到底属于哪一行”。同样一辆小客车，汽油和柴油的排放差异巨大。甚至同样是汽油车，欧洲四号和欧洲六号标准的氮氧化物限值相差好几倍。SUMO的排放类别代码统一表达了这些信息：

• 小客车：PC_G_EU4（汽油，欧4）、PC_D_EU6（柴油，欧6）
• 轻型货运车：LDV_G_EU5、LDV_D_EU5
• 重型货车：HDV_D_EU4、HDV_D_EU5
• 公交车：BUS_D_EU6
• 摩托车：Moped、Motorcycle

我在项目里一般不会给所有车辆只设一个默认类型，而是先做一次路侧调查或者参考当地统计年鉴，得出汽油车、柴油车、轻型货车、重型货车的比例，然后按比例分配到不同的vType里。别小看这个步骤，重型货车比例从5%调到15%，氮氧化物总量可能翻倍。官方示例里有个“RealWorldScenario”就是基于真实车队构成的，非常适合当参照来设计自己的车队结构。

3.3 命令行配置与XML输出字段的实操解读

配置好车队类别后在命令行启动仿真，SUMO会根据配置文件自动生成排放数据。如果不想改配置文件，也可以直接加参数启动：

sumo -c sumo.cfg --emission-output emissions.xml

输出文件的字段很直白，一个时间步内每辆车一条记录：

<timestep time="120.00"> <vehicle id="veh_12" eclass="HBEFA3/PC_G_EU4" CO2="2.31" CO="0.02" HC="0.001" NOx="0.008" PMx="0.0004" fuel="0.96" electricity="0.00"/> </timestep>

字段含义按照单位说明是克每秒：CO2是二氧化碳排放速率，CO是一氧化碳，HC是碳氢化合物，NOx是氮氧化物，PMx是颗粒物，fuel是燃油消耗速率，electricity是电耗速率。注意这些数值都基于当前仿真秒的真实工况，不是平均因子。

首次看到这类数据的人容易问：为什么同一辆车起步时的CO2突然跳到6克每秒，巡航时只有1克每秒？因为这是瞬时排放率，对应的是一秒钟内变化的排放质量，不是行驶一段路的平均排放。做后续分析时，要么把瞬时值加总求总量，要么按行驶里程换算成平均排放因子。

3.4 用TraCI读取实时排放：动态控制的接口路径

排放输出文件适合离线分析，但如果你想做“实时”的控制策略，例如根据当前排放水平动态调节信号灯或者限速值，那就得用TraCI。TraCI是SUMO的Python接口，可以在仿真运行时读取车辆状态和排放数据，也可以改变信号灯相位、车辆限速等。

用TraCI逐秒读取所有车辆排放会带来不小的性能损耗，我一般只在关键路段的少数车辆上做订阅，或者用批量接口在特定时间点汇总全市路网的排放量。示例思路是：

import traci traci.start(["sumo", "-c", "sumo.cfg"]) for step in range(3600): traci.simulationStep() # 订阅特定车辆 if step % 10 == 0: veh_id = "veh_12" co2 = traci.vehicle.getEmission(veh_id, traci.constants.VAR_CO2EMISSION) speed = traci.vehicle.getSpeed(veh_id) # 根据排放和速度决定是否调整信号配时

代码里的getEmission取的是当前秒的排放率，单位同样是克每秒。把这个值接进控制逻辑时一定要算清楚时间步：如果用10步取一次值，但每步是1秒，那结果就等于取了10秒的平均排放，而不是瞬态值。

4. 排放量分析与环境影响评估：从原始数据到决策结论

4.1 数据解析与单位换算

跑完仿真拿到XML，第一件事不是急着画图，而是清洗数据。我喜欢直接用Python的pandas读取XML，把车辆ID、时间、速度、排放率整理成一张表，然后做聚合：

import pandas as pd import xml.etree.ElementTree as ET tree = ET.parse("emissions.xml") root = tree.getroot() rows = [] for timestep in root.findall("timestep"): t = float(timestep.attrib["time"]) for vehicle in timestep.findall("vehicle"): rows.append({ "time": t, "veh_id": vehicle.attrib["id"], "CO2": float(vehicle.attrib["CO2"]), "NOx": float(vehicle.attrib["NOx"]), "fuel": float(vehicle.attrib["fuel"]), "speed": float(vehicle.attrib.get("speed", 0)), }) df = pd.DataFrame(rows)

得到这个表之后，单位换算要谨慎。XML里排放率是“克每秒”，时间步长是1秒，所以直接把某一列数值加起来，就是该仿真时段内以“克”为单位的排放总量。如果你把时间步长设置成了0.5秒，那就得乘0.5倍的时间权重，否则数值会放大一倍。这是实测中最容易犯的低级错误。

4.2 环境评估常用的指标计算

排放总量是基础，但环境评估中更常用的是“排放因子”和“温室气体当量”。排放因子可以这样计算：

1. 统计路网中所有车辆的总行驶里程。SUMO的输出里不一定直接给总里程，但你可以通过traci.vehicle.getDistance或者在路由文件里按路径长度加权得到。
2. 用总排放量除以总行驶里程，得到克每千米的排放因子。
3. 如果做道路等级分时段统计，就按起点路段和目标路段分桶聚合。

举个例子，某条主干道早高峰一小时的总NOx是320克，所有车累计行驶里程是4200公里，那这条道路的NOx排放因子就是0.076克每公里。把这个因子和当地实测数据对比，能很快发现模型参数是否合理。

温室气体当量的计算则把不同污染物折算到CO2等价值。主要污染物有CO2、CH4、N2O，SUMO的HBEFA输出可能只覆盖CO2和燃料消耗，必要时可以用燃料消耗量乘以排放系数估算CH4和N2O，再按IPCC的100年全球增温潜势折算。注意在报告中务必标明采用的具体GWP值，否则别人无法复现你的结果。

4.3 情景对比评估：信号优化、限速和禁货策略的减排测算

做完基线场景，开始做方案场景。每套方案都在同一个路网和需求基础上改一个变量，然后计算排放总量变化率。我常用的三个场景如下：

信号配时优化：基线用现状定时信号，优化方案用过渡高峰期更明显的绿信比分配，重点看NOx和CO2变化。由于起步停车次数减少，通常HC和NOx降幅会比CO2更明显。

差异化限速：把某快速路限速从80降到60，看起来最高速度降了，但如果减少了拥堵振荡，排放总量反而可能下降。SUMO可以方便地设置Edge限速，也可以通过TraCI实时改。

禁货时段：在早高峰时段把货车流量降为零，再评估污染物降幅。这时候重型柴油车比例对排放结果的影响会被放得很明显。

每个场景最少跑3到5个随机种子，消除路网中随机驾驶行为带来的波动。场景之间的差值应该计算置信区间，如果两个方案的排放差异小于随机波动，那么它们实际上没有统计意义上的区别，决策时就不该把减排当主要依据。

4.4 可视化展示与报告产出的经验

环境评估结果给业主或公众看的时候，光丢一张Excel表不够直观。我常用的可视化有三种：

第一种是路网热力图：把每条边每小时的NOx排放量聚合出来，在SUMO-GUI里用“颜色按数值显示”的功能看路段排放强度，也可以导出数据后在QGIS或Python里画地图热力层。这种图特别适合展示“排放热点集中在哪些交叉口”。

第二种是时间序列曲线：把全路网总CO2或NOx按1分钟粒度画出来，叠加信号优化前后两条曲线，能很清晰看到优化后峰值下降、谷值平滑。

第三种是累计减排量柱状图：用每个小时的减排量做柱状图，再算整个评价期内的累计减排量，这是最能直接支撑战略决策的图。

报告里我建议永远放三样内容：方法描述（什么时候、什么路网、什么车队构成）、结果表格（各类污染物总排放量和排放因子）、不确定性说明（模型偏差、车队比例假设、天气影响因素）。

5. 真实仿真中的失真风险与参数调优实战

5.1 车队构成和排放类别分配不准，总量会偏得离谱

这是我踩过最重的坑。有一个项目里我图省事，把所有车辆都设成了同一种汽油小客车，结果跑出来的NOx总量异常低，后来查了当地统计才发现货车占比接近20%。把重型货车按比例加进去之后，NOx总量直接翻了将近三倍。车队构成这件事，不是“大概就行”的细节，而是决定排放量量级的核心输入。

操作上，建议先做一个车队矩阵：每个车型乘上各自的排放类别、燃料类型、排放标准、平均载重。如果项目没有实测数据，可以参考地区车辆注册统计中的排放标准分布，按比例分配。要是连编号都不知道，就先用SUMO示例里的欧盟常见车队结构作为默认模板，再在报告中声明这个假设。

5.2 坡度、海拔和温度参数的默认值与修正

很多人在跑仿真时完全忘了SUMO是可以设置路段坡度的。平路和3%上坡路段的排放差异非常大，尤其是重型货车在上坡时发动机负荷剧增，NOx排放可能翻倍。SUMO的路网文件里每条Edge可以加slope属性，Netconvert转换OSM数据时也能从高程数据推断坡度。

温度影响同样不能忽视。HBEFA的冷启动排放和热稳定工况排放差异很大，SUMO的排放模型里面有系数可以调。我在做冬季北方城市项目时，会把冷启动比例和环境温度的影响单独考虑：先模拟一次热车状态下的排放，再按比例叠加冷启动附加排放。这个思路比硬调排放系数要可靠得多。

5.3 跟车模型参数对瞬态排放的放大效应

SUMO默认的跟车模型是Krauss模型，它本质上是个安全驾驶模型，追求的是不撞车，而不是模拟真实司机的激进性。在拥堵排队场景里，Krauss默认参数可能让车辆之间距离保持得过于保守，导致每条车道的通行能力偏低、车辆反复减速次数偏多，因此排放总量往往会被高估。

调参建议从三个参数入手：sigma代表驾驶员不完美程度，值越高越容易波动；tau代表反应时间，默认1秒，可以按驾驶风格调成0.8到1.2；minGap代表静止时最小车间距，影响排队长度。每调一次参数，都要重新对比路网最大排队长度和实测数据，不要只看排放数值是否“合理”，因为排放合理也可能是错误抵消的结果。

5.4 与实测数据校验的正确姿势

仿真模型的校验是评估可信度的唯一标准。但排放实测数据并不容易获取，最实际的做法是先校验交通流参数，再验证排放量级。我会分两步：

第一步，校验路段流量、平均速度和排队长度。在仿真里布几个检测断面，对比真实检测器的15分钟粒度流量和速度。如果这都对不上，后续任何排放输出都是无意义的。

第二步，用宏观排放清单做交叉验证。把SUMO算出的排放因子与当地环境监测站反推的、或者同类城市文献里的排放因子对比，看是否在同一量级内。偏差在30%以内通常可以接受；如果超过50%，优先检查车队构成和驾驶行为参数。

需要特别提醒：SUMO的排放总量是理想工况下的热排放，不包含空调、冷启动和路况摩擦等附加因素。在用它估算“实际环境影响”时，一定要用修正系数把附加排放补上，否则你给决策者的评估结果往往会偏于乐观。

再分享一个折腾过好多次的经验：SUMO的排放模型输出对路网细节非常敏感，同一个策略方案换个路网转换参数跑出来的结果可能完全不同。所以我在正式开展环境评估之前，都会先把路网、车队和驾驶行为参数固定下来，做一个基准版本存档，后面所有方案都从这一套固化好的输入出发。交通排放仿真不是追求绝对数值的游戏，它的核心价值在于提供一套可复现的、可比较的分析框架，让不同交通管理策略在同样的条件下比出高低。只要抓住这个本质，SUMO就能成为环境决策里一个相当好用的工具。