做交通仿真项目做到最后我越来越强烈的感受是建模本身只是起点交通仿真软件的价值最终落在数据分析上。拿Aimsun来说不管你是做微观仿真、中观仿真还是宏观仿真跑完一次仿真模拟后摆在面前的经常是动辄几个GB的输出文件里面密密麻麻记录着成百上千条路段的流量、速度、延误、排队数据。这个时候真正考验功力的不是把模型跑通而是能不能把这些数据读准、读透提炼成决策依据。这篇文章就围绕Aimsun仿真中的数据分析展开从输出数据的口径、模型标定中的GEH指标、多方案对比的显著性检验到瓶颈路段定位的实战流程把我这些年积累的做法和踩过的坑一并整理出来希望对正在做交通仿真项目或刚接触Aimsun数据模块的同行有帮助。1. Aimsun的数据输出体系先搞清楚数据从哪里来很多人一打开Aimsun的Output窗口就懵了里面的复选项实在太多Network、Section、Node、Path、Vehicle每个类别下面还有密密麻麻的子项。如果不理解这些数据的层级关系后续的分析很容易变成一堆数字的堆砌。我习惯先把Aimsun的数据家族梳理成下面这张表用的时候直接查表定位。1.1 六个层级的数据视图Aimsun的输出数据大致可以分成六个层级每个层级解决不同尺度的问题。数据层级典型输出项主要用途系统级全网总出行时间、总延误、平均速度、总行驶里程、总排放方案整体效果评价一张表搞定结论路段级各路段流量、平均速度、密度、行程时间、排队长度最常用层级用于路网瓶颈识别、流量校核节点级转向流量、节点平均延误、进口道排队交叉口分析信号配时方案对比路径级OD路径的出行时间、路径流量路径选择分析告诉用户这条路和那条路差多少检测器级线圈流量、占有率、平均速度与实测线圈数据对比、模型标定车辆级每辆车逐秒的位置、速度、加速度、车道变化轨迹级分析跟驰和换道行为微观复盘1.2 输出配置与存储方式在Aimsun里数据的存储方式有几种直接在图形界面里看动态图表、把统计数据写入文本文件、通过ODBC接口写入数据库或者通过API实时取数。文本文件是最常见的但要注意它的一个脾气默认情况下输出文件是按仿真复制Replication分开写的一个方案跑五个复制会生成五个独立的数据文件做均值、方差统计时要把它们按同一路段ID和时间片对应起来。输出间隔的设置也很关键。我一般遵循一个原则看宏观指标用15分钟聚合粒度看信号周期内的排队波动用5分钟甚至1分钟做逐秒轨迹就用最小输出间隔。但代价是文件体积指数级增长一个中等规模路网开车辆级输出跑上两小时仿真就能产生十几个GB的轨迹文件后面会专门讲这个坑。1.3 哪些数据该丢哪些数据该留做数据分析第一步不是算而是扔数据。仿真刚开始的预热阶段Warm-up里路网车辆密度很低流量、延误都在爬坡属于系统进入稳态前的过渡状态。这段数据如果混进统计平均速度被拉高、延误被拉低结论整体失真。Aimsun允许在实验设置里指定预热时间建议至少留出600秒10分钟等路网加载稳定后再开始统计。另一个容易忽略的是空数据的处理。某个路段在某个时间片里完全没车输出可能是0也可能是-1或空值。如果直接把0当成平均速度参与计算一个空片就能把十分钟的平均速度拉低一大截。正确做法是先过滤掉无效记录再按照后面章节提到的流量加权方式计算。2. 流量、速度、延误、排队四个核心指标的口径与使用边界Aimsun输出的指标名称和行业通用说法基本对得上但每个指标的具体算法都有讲究。同样的延误定义不同软件之间可能差出30%的结果。这里逐个拆开聊。2.1 流量断面计数背后的供需关系流量是断面型指标单位通常是veh/hAimsun在统计路段流量时会按车道汇总。做数据分析时要记住一个底层逻辑仿真流量不是直接输入的而是模型根据OD需求和路网供给能力涌现出来的结果。你给某条路输入了每小时1000辆车次的OD需求因为下游拥堵实际断面流量可能只能通过700辆剩下300辆滞留在排队里。这就是流量和需求的本质区别。解读流量数据时我最常嘱托团队的一件事是别只看数值要看趋势。把同一路段在不同情景下的流量时间序列画出来比对比单一平均值有意义得多。比如早高峰时段流量曲线出现平台期——持续在某个水平不再上升那往往是通行能力达到上限的信号而不是需求真的到了这个量级。2.2 速度与密度判断拥堵成因的雷达速度是最直观的运行状态指标Aimsun输出的路段平均速度通常更接近空间平均速度某一路段上所有车辆速度的平均值而不是线圈那种时间平均速度。两者在畅通状态下差距不大一旦出现拥堵空间平均速度会明显低于时间平均速度因为低速车辆占据路段的时间更长对时间均值的影响权重更大。密度veh/km/lane在Aimsun里可以由流量和速度通过基本关系式QK×V反推单位是每车道每公里车辆数。密度比速度更早反映拥堵的趋势速度还没降下来时密度可能已经悄悄升高了。我习惯把流量-密度-速度三张图放在一起看一旦发现某条路段流量下降但密度继续上涨说明该路段已经过了通行能力峰值进入拥堵状态这时候再去调信号配时或禁左措施才是对症下药。2.3 延误与排队评价方案优劣的裁判延误是方案比选中最常用的指标但不同情境下延误的定义差别很大。Aimsun里有行程时间延误实际行程时间与自由流行程时间的差值、加速/减速延误、停车延误等。做交叉口方案对比时我一般用总延误秒/车这类综合指标做路网级分析时则直接比较全网总出行时间或总延误这两个指标对模型参数不太敏感适合横向比方案。排队长度则要看清输出的是平均排队还是最大排队两者含义完全不同。平均排队反映日常运行水平最大排队则直接决定是否会发生溢出Spillback也就是队尾是否倒灌到上游交叉口。判断溢出的方法很简单用最大排队车辆数乘以平均车头间距一般按7米左右估算如果超过路段长度减去进口道长度就说明排队已经越过了路段边界这是微观测评里最严重的失败模式之一。3. 用数据做模型校准GEH指标与OD矩阵反推的实战方法模型标定是交通仿真项目中最枯燥但又最关键的环节。很多时候模型跑出来的结果差根本不是仿真软件的问题而是需求数据或路径选择参数没校好。这里只讲数据层面的处理思路。3.1 GEH统计量怎么算标准怎么定GEH指标是交通仿真界公认的流量拟合度统计量公式是GEH sqrt(2 × (M - C)² / (M C))其中M是仿真流量C是实测流量单位都用veh/h。GEH的优点在于它对流量绝对值做了归一化处理大流量路段允许更大的绝对误差小流量路段要求更高的相对精度不会因为某条支路流量小就放大误差。项目执行中我按这样的标准掌握关键干道和主节点的GEH必须小于5所有检测断面中超过85%的断面GEH小于5任何断面GEH大于10都必须查明原因。原因通常是三种OD总量偏差、路径选择比例不对、或者某些路段通行能力参数设置过低。校准顺序也明确先总量后结构、先流量后速度、先干道后支路。3.2 OD矩阵反推先总量后结构OD矩阵是交通仿真的燃料但现实项目里拿到的OD往往是规划模型输出或大样本调查推算的落到微观路网上时误差不小。Aimsun提供OD矩阵估计功能大致原理是以先验OD作为初始值利用检测器实测流量作为约束条件通过迭代调整OD值让仿真流量逐步逼近实测流量。实操时我建议先做一步粗调把先验OD的总需求量与实测进车流量总和比对。如果总量差超过20%任何精细调整都是白费力气。总量过了关再进入反推环节。反推时要控制迭代深度——过度拟合会让OD矩阵出现大量不符合常理的大数值例如某两小区之间被反推出每小时上万需求这东西在报告里根本没法解释。我的经验是限制迭代步数保持OD值的平滑性把重点放在主干流向的调整上。3.3 标定的优先级和常见顺序一个完整的交通仿真数据分析标定流程我建议按下述顺序走加载实测流量数据计算GEH找出超标断面检查OD总需求与全网观测进车量总和的偏差调整OD矩阵结构优先修正超标最明显的干道对应OD对重跑多个复制再看GEH是否收敛用行程时间或Floating Car数据校核速度指标相对误差控制在±15%以内最后微调驾驶行为参数反应时间、跟车间距、期望速度分布。速度校核是很多人跳过的步骤。流量拟合好了不代表模型可信曾经有项目流量GEH全部达标但行程时间实测值超过仿真值的30%原因就是仿真里的期望速度设得过高。这类问题只有把行程时间数据拉进来对比才能暴露出来。4. 方案对比别只看平均数随机种子与显著性检验我在评审会上见过太多次这样的对话方案A的平均延误是43秒方案B是39秒所以B更好。然后大家就准备签字。但实际上方案B的这组数据可能只是运气好只跑了一次复制就拿来比较噪声和方案差异完全混在一起。这是交通仿真数据分析里最容易被忽视的问题。4.1 同方案两次仿真为什么差10%Aimsun微观仿真模型是带随机性的。车辆生成不是按固定时刻发车而是按照泊松分布或类似随机过程生成每辆车的驾驶员期望速度、跟车参数也不完全相同这些随机性由一个随机种子Random Seed控制。只要你换了种子哪怕所有输入文件一个字都不改跑出来的流量、速度、延误也会有波动。这个波动有多大我实测过一条中等拥堵的城市主干道同一方案跑5个复制平均行程时间的标准差可以达到平均值的5%-10%。到了高饱和路网延误指标的标准差甚至可以超过均值的15%。单次结果拿来做方案比选约等于掷骰子定结论。4.2 多复制的平均与置信区间正确的做法是让每个方案跑多个复制用均值、标准差、置信区间来比较。常规做法是每个方案至少跑5个复制如果项目精度要求高可以跑到10个。计算上很简单对每个方案的某个指标求出平均值X̄和标准差s然后构建95%置信区间X̄ ± t₀.₀₂₅ × s/√n。两个方案的置信区间有明显分离结论才站得住区间有大幅重合就该老实承认当前样本量下无法区分两个方案的优劣建议加跑复制或引入其他指标再判断。如果两组数据不服从正态分布换Mann-Whitney非参数检验即可spss、Python里的科学计算库都能直接给出结果。4.3 独立种子和共享种子的抉择实际项目中还有一个小决策方案A和方案B应该用相同的随机种子还是各自独立的种子共享种子可以抵消部分随机噪声让方案差更容易显现适合做参数灵敏度测试——比如只改反应时间其他条件不变看指标变化趋势。但正式方案对比我建议用独立种子因为独立种子给出的结论更接近现实中需求随机波动下的真实表现报告也更有说服力。如果时间和算力有限可以采取折中策略初筛时每个方案跑3个独立种子进入评审的方案再扩到5个以上并把置信区间标进对比表里。5. 从数据表到决策结论瓶颈定位与汇报输出数据分析最终要服务于决策。这里分享一套我从Aimsun输出数据中定位瓶颈、生成汇报图表的完整流程这套方法在多个城市快速路和主干道项目中实测有效。5.1 三条筛选法则锁定瓶颈路段面对动辄几千行的路段数据表我不建议人工翻找。三步走第一步计算每条路段的V/C比流量/通行能力把V/C高于0.9的路段列为疑似瓶颈区 第二步查看这些路段的密度曲线如果密度持续升高且速度持续下降说明该路段处于拥堵成因区而非受尾随拥堵影响区 第三步对照节点转向流量确认瓶颈是否由某个进口道的转向流量过大引起把源头从路段下探到转向和信号相位。这条思路的要点是不要被最大排队或延误最大的路段带偏。拥堵像多米诺骨牌最堵的路段往往不是源头而是范围传播的结果。数据图上一眼看到速度最低的路段可能只是下游排队倒灌真正的源头反而是速度还没降到极值、但流量已经逼近极限的某个断面。5.2 时间-空间图比柱状图更会说问题汇报效果最好的图我首推时间-空间速度图。横轴是时间纵轴是道路里程网格颜色代表各时空分块的平均速度。这种图能直观看出拥堵从哪个断面开始、什么时候形成、向上游延伸了多远、什么时候消散——这些信息用普通的柱状图或折线图都很难表达清楚。Aimsun自带的图表模块可以直接出这类图也可以把Section数据导出后用Python的pandas读取再做热力图。下面给一个最简单可用的脚本骨架import pandas as pd import matplotlib.pyplot as plt df pd.read_csv(section_speed.csv, parse_dates[Time], index_colTime) pivot df.pivot_table(indexSectionID, columnsTime, valuesSpeed, aggfuncmean) plt.figure(figsize(14, 8)) plt.imshow(pivot.values, aspectauto, cmapRdYlGn_r, vmin0, vmax70) plt.colorbar(labelSpeed (km/h)) plt.xlabel(Simulation Time) plt.ylabel(Section ID) plt.show()出图后配合前面说的源头判定逻辑就能在评审会上把问题讲得清清楚楚。5.3 方案比选表要带上波动范围做汇报表格时我强烈建议每个指标不只给一个均值而是给出均值 ± 标准差或95%置信区间。例如平均行程时间方案A为412±23秒方案B为388±19秒这种表达能让评审专家一眼看出差异是否在噪声范围内也显得你的数据分析工作足够严谨。表格列法供参考第一列指标名称后面按方案分组每个方案下分均值、标准差、样本量最后加一列相对基准方案变化率。指标可以选择全网总出行时间、平均延误、平均速度、95%分位排队长度、溢出路段数等控制在6-8个指标太多会稀释重点。6. 输出数据分析的五个隐藏坑都是真实案例这里整理几个我在实际项目中踩过的数据层面的坑每一个都让团队付出过加班代价。6.1 时间单位换算一错延误数据全废Aimsun的仿真时间可以按照秒、分钟、小时作为单位输出和GUI里的仿真步长是两个概念。我曾经在一次项目中把模型仿真时长设成了1800以为是30分钟拿到数据后算出来的延误大得离谱排查半天发现仿真时长单位其实是步按步长1秒换算只有30秒。这种单位错位不会报任何错误提示只能靠人工检查。现在我的团队规则很简单拿到任何输出文件先检查Time列的最大值和最小值的差值再对比预设仿真时长差一个数量级就立即停止分析。6.2 零流量时段的平均速度会把指标拖入陷阱前面提到过路段在某时间片没有车时输出数据里的平均速度可能是0或空。如果不做过滤直接对全时段求平均一条畅通的支路可能因为夜间零流量时段被算成平均速度只有20km/h在热力图上显示为一片红色拥堵。更合理的做法是通过流量加权计算平均速度V Σ(Qᵢ·vᵢ) / ΣQᵢ即每个时间片的流量乘以该时间片速度求和后除以总流量。流量低的时段自动降低权重流量高时段的真实运行状态才不会被淹没。6.3 车辆级轨迹文件体积失控磁盘报警开Vehicle级输出之前一定要先算好文件体量。每辆车每秒至少记录位置、速度、加速度、车道、间距5个字段一个运行2小时、同时有2000辆车的模型轻轻松松生成20GB以上的轨迹文件。更麻烦的是写文件本身会拖慢仿真的速度IO瓶颈会让两次仿真的耗时差异达到一倍。我现在的习惯是默认只开聚合数据只在需要做微观行为的专项分析时按指定时间段或指定OD子集过滤输出轨迹。6.4 检测器位置不同同一路段读数却不同经常有团队拿Aimsun里检测器数据和实测线圈数据对比发现GEH一直不达标调了半天参数也没用。最后发现是检测器位置对应的断面根本不对。Aimsun的检测器可以放在路段任意位置但实测线圈的位置覆盖范围和感应长度与仿真检测器完全不同。做校准对比前先画示意图确认两方面一致检测器的横向覆盖是全部车道还是左转专用道以及纵向位置是在进口道上游还是出口道下游。位置差一个车道转向组流量可能差出15%这种误差再好的参数调整也救不回来。6.5 预热时间没设够早高峰数据虚胖最后说一个非常隐蔽的坑。如果预热时间设置过短仿真开始时路网几乎是空的前几分钟所有车辆都以自由流速度行驶统计出的平均速度会明显偏高。尤其做早高峰分析时这个偏高时段正好落在最核心的评价区间里。建议预热时间至少覆盖路网从空态到饱和态的主要加载过程常见做法是15分钟预热加统计时段。你在评审会汇报时如果被人问为什么仿真速度比实测高这么多先别急着改参数回去看一眼预热设置比盲目调参更高效。最后再聊几句个人感受。做仿真项目这几年越来越多的评审专家开始追问数据的置信区间、样本量、校验过程这些细节这说明交通仿真正在从画个好看的图走向真正的定量分析。Aimsun在数据输出上给的自由度已经很高能不能用好取决于分析者自己的方法论是否扎实。上面这些内容是我在实际项目里一步步趟出来的尤其是流量加权、多复制检验、检测器位置校验这几个点每一条都对应着一次真实复盘。希望同行们做Aimsun数据分析时少走几步弯路。