★ FEATURED ARTICLE 做交通仿真这些年Aimsun算是我用得最频繁的工具之一。很多人一开始觉得这个软件的学习曲线陡峭路网画起来要一个个节点一条条边去磨信号方案调来调去也麻烦。但说实话这些都不是最难的部分。真正让一批人卡在中间的往往是“交通数据分析”这个环节——模型跑起来了一大堆数字摆在面前却不知道该提取什么、该信什么、该怎么把结果变成有说服力的结论。这篇文章我就从自己实操的角度把Aimsun从仿真前到仿真后涉及的数据分析流程完整过一遍聊聊OD矩阵怎么校核、检测器怎么布、输出指标怎么挑、方案对比怎么做以及那些常规文档里不会写、但实际项目里一定会遇到的坑。想认真拿Aimsun做项目的规划工程师、交通咨询人员或者准备拿仿真做课程设计的同学这篇应该能帮你少走不少弯路。1. Aimsun里“交通数据分析”到底指什么1.1 数据分析贯穿仿真流程的三个阶段我的经验是Aimsun里的交通数据分析从来不是一个独立的按钮而是嵌在仿真全流程里的三条线。第一条线在建模之前也就是需求侧数据分析你需要把调查来的交通流量、OD数据、交叉口转向比例整理成模型能用的输入参数这步直接决定仿真靠不靠谱。第二条线在仿真运行过程中需要事先在路网布设观测点、行程时间区段等采集工具让模型在跑的过程中把中间状态数据记录下来。第三条线在仿真运行之后也就是输出侧分析延误是多少、排队排多长、哪条路饱和度高通过一系列指标来判断路网运行状态给多个方案做横向比选。很多初学者只盯着第三条线认为“跑完出图”就是数据分析。这是理解上的偏差。做实际项目久了你会发现真正拉开差距的是前面两条线——数据校核做得扎实后面分析自然顺理成章输入数据本身就是乱的输出的图表再漂亮也只能忽悠外行。1.2 需求数据与输出数据不能混为一谈这里特别想说清楚一个问题。Aimsun里的“交通数据分析”涉及两类性质完全不同的数据流。一类是需求数据也就是OD矩阵、交通小区之间的出行量、进出网络的流量它们描述的是“有多少车想上路”另一类是运行数据比如路段流量、行程时间、排队长度、延误、密度它们描述的是“这些车上了路之后跑得怎么样”。这两类数据在Aimsun里操作路径也完全不同。需求数据主要在OD和交通模块里处理比如OD矩阵调整、基于观测流量的OD反推、动态用户分配下的需求加载运行数据则要依赖检测器、行程时间统计区段、输出变量配置等功能。我见过不少人把OD调整和仿真校核混成一锅粥调了半天不知道在调什么。记住一个原则需求决定总量路网和信号决定分布。数据出了问题先判断是哪一层再动手修。2. 仿真前的需求数据分析OD矩阵、观测点与路网校核2.1 把外业调查数据整理成模型能吃的输入在Aimsun里做交通数据分析第一步往往是处理源数据。实际项目里拿到的通常是交通调查公司的Excel统计表甚至还有纸质记录扫描件。我一般会先统一按“小区编号、时段、O、D、流量”五列整理成标准CSV再导入到Aimsun里生成OD矩阵。这里有一个关键设置必须注意Aimsun的OD矩阵要对应具体时段和具体需求角色早晚高峰要分开建矩阵不然后面所有分析时段都会被污染。导入的时候Aimsun提供的OD Matrix Browser面板可以直接检查二维矩阵形态有经验的工程师会先扫一眼矩阵的对角线——如果对角线流量占比异常高通常是数据录入出了问题比如把“区内出行”误标成了其他小区之间的出行。还有一个我自己常用的习惯导入前先做一次累加核对所有小区发生量和吸引量加总差距超过5%就回去查原始数据。原因很简单OD总量和路网实测流量如果从一开始就不在一个量级后面再怎么标定都白搭。2.2 流量校核的核心指标GEH统计量到底怎么用说到路网校核必须把GEH统计量拿出来讲透。GEH来源于一个经验公式用来衡量仿真模型输出流量和实测流量之间的差异程度比单纯看相对误差要科学因为它在低流量时更敏感、高流量时更宽容。计算公式是GEH sqrt(2 × (M - C)^2 / (M C))其中M是模型输出的流量C是实测流量。判定标准业内一般是这样GEH小于5说明该断面模型输出与实测基本一致校核通过GEH在5到10之间说明有偏差但可以接受需要留意GEH大于10说明这个断面差异已经到必须干预的程度了。我做一个项目通常会把全路网观测断面GEH小于5的比例达到85%以上作为校核完成的标准。曾经做过一个区域模型15个观测断面里6个GEH都在10以上查来查去发现是某个货运通道的OD被调查数据低估了调整之后才把整体比例拉回到合格线。这个经验说明GEH只是一个症状指标真正的病因往往要回到OD矩阵和路径选择里去找。2.3 检测器和行程时间区段的布设细节布设检测器这件事看着简单其实门道很多。我的经验是检测器不能放在交叉口停止线附近否则排队车辆反复碾压检测器统计出来的是“排队等待车辆数”和真正通过的流量混在一起的数据毫无参考价值。比较稳妥的做法是把检测器布设在两个相邻交叉口之间、车辆运行相对稳定的路段中段并且离上游停车线至少80到100米。行程时间区段则要单独说明。Aimsun里有两种行程时间采集方式一种是基于点对点的行程时间检测器另一种是基于路径的行程时间输出。实操时我建议尽量用路径类检测器因为城市路网中存在转向延误和信号等待点对点测的是瞬时行程时间路径法才能反映驾驶员真实感受到的延误。布设完成后要预留至少一个信号周期的预热时间这组数据才算稳定。很多人在这个细节上吃亏因为第一组数据往往包含了模型加载的“启动毛刺”。3. 仿真后的输出数据分析KPI提取与方案比选3.1 Aimsun输出数据的几个主要入口Aimsun跑完仿真后输出数据分散在几个地方。最常用的是Network Object Results窗口它按对象类型路段、节点、检测器等列出统计结果Excel式表格可以直接排序和过滤。第二个入口是图形化数据窗口比如时间序列图、速度-流量散点图、排队长度逐时变化图等适合初判用。第三个入口是扩展的Data Viewer以及通过脚本API提取自定义指标——项目要求高的时候我一般会用后者因为自带界面有时候满足不了深度分析的需求。新手最容易把时间序列图和汇总表搞混。时间序列图展示的是每个仿真间隔比如每300秒的指标变化用来观察拥堵形成和消散过程比如判断早高峰从几点开始排队累积、几点开始消散汇总表则是整个仿真时段平均下来的一个数比如平均行程时间、平均延误。两者场景不同汇报时尤其要分清说“高峰小时延误XX秒”用的是平均值说“延误曲线在7:45有个拐点”用的是时间序列。混淆这两类数据在专家评审会上会很尴尬。3.2 最常用到的几个指标到底该怎么看延误指标要看细。Aimsun里至少有三种延误路段延误、节点延误和总延误。路段延误是车辆在路段上因为加减速和排队而损失的时间节点延误是车辆在交叉口范围内因为信号等待而损失的时间。这两个指标在方案比选时应该拆开来看只报一个总延误容易掩盖真实问题——比如某个方案平均延误没变化但实际上是“路段延误降了、节点延误涨了”这说明拥堵位置发生了转移。排队长度要看百分位。交通仿真里排队是一个动态变化的随机量单看平均值不够。我习惯同时取平均排队和95百分位排队两个维度。平均排队反映出总体压力95百分位则表达最不利状态。做信号配时需要关注95百分位因为一旦某条转向车道的最大排队溢出到上游交叉口排队长度的意义就完全变了——那已经不是排队指标而是路网锁死的信号。行程时间适合做通道级评价。如果项目要评价一条主干路的行程时间改善只盯一个断面没用要看整条通道多个行程时间区段拼起来的联动结果。我常用的做法是分别统计早晚高峰时段起点到终点全程行程时间再看各路段占比找出延误集中路段。这样汇报时既能看到“总改善多少秒”也能看到“到底改善在哪里”。3.3 多次运行的平均与随机种子有一个很多刚接触仿真容易忽略的问题Aimsun的微观仿真每次运行结果并不完全一样。原因是仿真过程中存在大量随机因素比如车辆驶入路网的时刻、驾驶员的路径选择感知误差、信号控制中的随机成分。软件用随机种子来控制这些随机性。单次运行的结果只是众多随机场景中的一次抽样不能直接当作最终结论。正确的做法是用同一套模型、不同的随机种子重复运行N次一般至少5到10次把每次运行的KPI记录成表最后取平均值。我习惯在Aimsun里配置多组replication每次运行改变随机种子然后对多次运行的结果做均值和样本标准差统计。更专业的项目还会进一步计算95%置信区间用统计显著性来判断方案之间的差异到底成不成立而不是靠图上两根柱子高低就说A方案优于B方案。3.4 方案比选场景下怎么快速输出对比报表Aimsun的Scenario机制非常适合做方案对比。你可以在一个交通模型下建立多个实验场景每个场景对应不同的信号方案或路网结构分别运行后通过比对工具汇总成对比报表。我实际项目里最常用的做法是建立“现状基础”“优化方案1”“优化方案2”三个场景每个场景跑10次然后提取总出行时间、平均延误、最大排队长度、关键通道行程时间、排放估算这几个指标整理到一张汇总表里。这里有一个容易踩的坑不同场景的车辆加载方式必须一致。如果现状场景用的是50%加载、方案场景用了100%加载对比就完全失真。也不要只给最终均值最好把标准差一并列出来评审专家看到你连波动性都考虑了可信度会明显提高。汇报表格我通常按“指标名、现状均值、方案1均值、方案2均值、变化量”的格式整理附上标准差这样够清楚也够专业。4. 实操案例某片区路网改造项目的完整数据分析流程4.1 项目背景与建模准备前阵子做一个片区路网改造评估项目模拟对象是南方某城市核心区内一个由三条主干路和若干次干路组成的局部路网早晚高峰拥堵严重。我们接到的工作是评估两种改善方案的影响方案A是调整三个关键交叉口的信号配时方案B是在方案A的基础上对某个畸形路口做局部几何渠化改造。任务要求输出延误、排队、行程时间三项关键指标的对比。建模阶段我们使用Aimsun的微观仿真级别。路网从GIS基础底图描出节点数和路段数控制在合理规模需求数据来源是之前的OD调查和路段流量调查按早晚高峰分别建立两个OD矩阵。建模完成后第一件事就是在全路网布设了12个观测断面做流量校核另外设置了4条路径行程时间检测区段用来覆盖三条主干路的主要通行方向。整个校核过程花了两天比建模还久但这一步扎实了后面方案结论才有底气。4.2 校核阶段的GEH迭代过程第一批仿真跑完我导出各观测断面流量和实测流量逐一算GEH。结果不太好看12个断面里只有6个GEH小于5有3个断面在5到10之间另外3个断面直接爆表GEH超过10。这些超差的断面全部集中在路网西侧。一开始我怀疑是OD矩阵总量低估但核对了发生量和吸引量总量没问题。反复排查后发现是西侧有一条次干路在仿真里承担了过少的流量而实测中很多驾驶员为了避开前面交叉口排队会选择这条路绕行。问题定位后调整了这部分路径选择的感知系数同时修正了那条次干路和相邻交叉口的转向比例。再跑一轮GEH小于5的断面增加到了10个剩下2个在5到7之间整体合格比例超过了85%达到了我们内部校核标准。这里也要补充一句GEH指标只能告诉你断面流量是否对得上它不告诉你为什么对不上。真正定位原因还得靠现场对路径选择、信号相位和OD分布逐项排查。4.3 方案对比阶段的数据提取与统计校核完成后进入正式方案对比。三个场景分别标定为现状基础、方案A、方案B每个场景设置10次随机重复仿真时段取早高峰7:00到9:00。数据提取时我按小时划分区间做细分重点看7:30到8:30这个最拥挤的时段窗口。用Excel汇总结果核心指标落在表格里路网总出行时间、平均路网延误、三个关键交叉口的最大排队长度、三条主干路通道行程时间。结果很清楚方案A把路网平均延误从大约68秒降低到56秒最大排队长度明显收缩但有一个交叉口的北进口排队反而变长了原因是信号配时调整后该进口的绿灯时间被压缩排队向上游转移。方案B在方案A基础上通过渠化增加了一条专用左转车道把该进口的延误和排队都压了下去。从数字上看方案B的整体指标略优于方案A但方案B工程量更大。我们最后建议业主如果短期解决拥堵问题方案A已经有效若考虑长期效应和上下游协同方案B更值得投入。4.4 汇报时怎么讲清楚数据分析结论仿真数据汇报这件事很多技术底子不错的人反而做不好。我的体会是汇报不是甩数据而是讲因果链。我会先给一张“现状问题分布”的图指出延误和排队集中在哪些节点然后讲方案为什么能解决这部分问题接着再给优化前后的对比表最后强调方案之间的差异点。图表选择上空间分布用路网染色图最适合展示拥堵位置时间趋势用折线图适合展示排队累积变化方案对比用柱状图或表更直观。提醒一句交报告的时候一定要把统计口径写清楚尤其是“平均延误”是算哪个时段、哪种延误类型口径不一致的数字没有任何可比性。我甚至在报告里专门列一个“指标定义”页把每个KPI的计算方式、统计时段、统计范围写明白避免评审时被人问住。5. 常见问题与排查技巧实录5.1 OD估算不收敛可以怎么办Aimsun里做OD矩阵估算时偶尔会遇到迭代不收敛的情况具体表现是每次迭代后观测站点的流量误差震荡不降甚至越迭代偏差越大。我遇到时一般先检查初始OD矩阵是否严重偏离真实量级初始值太差估算算法会陷入局部震荡。其次检查观测断面是否过少只有两三个观测站的条件下要反推一个复杂OD矩阵数学上就是一个欠定问题不收敛是正常的。这种情况下要么增加调查断面数量要么降低需要估算的小区数量把相邻小区合并后再估。5.2 仿真流量和检测器实测流量对不上这个问题在校核阶段最常见。排查顺序我建议按这样来先确认检测器布设位置对应的是模型哪条路段很多项目里实测断面位置和模型路段节点位置对应错位导致单位都不一致。再看加载进入路网的OD需求是否和实际调查时段一致早高峰矩阵应用到晚高峰仿真自然对不上。最后看路径选择参数如果模型允许车辆自由选择路径但实际该路段除了最短路径外还有很强的固定路径选择就会造成仿真流量偏离实测。5.3 随机种子和数据的波动性微观仿真的随机性影响远比想象中大。有一次我做信号优化同一个方案跑10次平均延误的标准差占均值的15%这时候如果你只跑一遍仿真就修信号配时等于在噪音里找信号。我在做小规模交叉口时甚至会把重复次数提高到20次虽然耗时但对于关键决策数据更稳妥。如果是宏观或中观仿真随机性会小很多但微观项目不能省这一步。5.4 交通数据分析常见问题速查表问题现象可能原因排查与解决建议GEH普遍偏高OD矩阵总量不准或时段划分不对先核验OD发生/吸引总量再核对时段矩阵加载某个断面GEH单独爆表检测器位置偏移或路径选择异常检查检测器所在路段量化该路段路径流量来源OD估算不收敛观测点过少或初始矩阵偏差过大增加观测数据合并小区调整迭代参数排队溢出反复发生信号绿信比不足或上游来车过多检查相邻交叉口联动可能需要协调控制仿真流量波动大随机种子不足、加载率不当增加重复次数取平均值统一加载方式行程时间与实测差太多路径检测区段覆盖不合理核对区段起终点改用路径类行程时间检测器这个速查表并不是题库而是我自己反复踩坑后沉淀下来的排查顺序。做数据分析时遇到异常指标别急着改参数先按表里的顺序从源头排查能省下大半天时间。最后说点体会做了这么多年交通仿真我的一个深刻感受是Aimsun里的数据分析本质上不是软件操作技能而是一种交通工程判断力。软件给你千百个指标但真正有价值的是你对路网问题的诊断能力——知道该信哪组数据、该把哪组数据当噪音知道数字背后反映的交通现象是不是符合现场经验。最忌讳的就是跑完模型、看到输出窗口里有几组数字就抄进报告那样做仿真跟做假数据没什么区别。另外分享一个小习惯每次项目做完我会把当时的OD矩阵、校核结果和最终KPI汇总表单独打包存好。后续如果要复盘模型或者做类似片区的新项目这些历史数据非常有价值。仿真模型可以重建但实测校核数据不是随时都能再采的。这也是交通数据分析里容易被低估的一部分——数据资产的沉淀。如果你正在用Aimsun做项目建议从一开始就养成记录校核过程的习惯后面你会感谢这个决定的。
阅读完成 · 觉得有帮助？
