做交通仿真的朋友应该都有这种体会：模型调了一个多月，信号配时一轮一轮改，OD表反推了无数遍，终于有一天，Aimsun里的动画不再动不动就锁死，车辆流动也看着顺眼了。但这时候项目负责人问一句“新方案到底比现状好多少？”，你要是只会指着屏幕说“你看这里不堵了”，那这个仿真基本等于白做。模型跑完不是终点，动画再流畅也只是表象，流量、速度、延误、排队这些数据的分析结果，才是方案能不能落地的硬道理。仿真结果里随便挑几个指标出来对比，往往比几十版动画更有说服力，这也是我写这个系列绕不开的话题。

这篇是Aimsun系列笔记的第21篇，核心话题就是交通仿真里的数据分析。我会把Aimsun里能拿到哪些数据、怎么导出、怎么清洗、怎么计算GEH这类关键指标、怎么画图，一条龙讲清楚。适合三类人看：刚接触Aimsun的仿真工程师、做交通规划和咨询的从业者、以及写论文需要量化仿真结果的研究生。看完你会发现，数据分析其实不是仿真做完之后的收尾工作，而是贯穿整个项目的一条暗线。虽然不同项目用的版本可能不一样，但只要理解了一套数据处理和分析的思路，换到新版本也只是菜单名称变化，我尽量把原理和操作都讲到，方便你举一反三。

1. Aimsun的数据从哪来：三类输出先分清

1.1 检测器、路段/节点、网络/路径：三种数据各管什么

做数据分析第一步不是急着写代码，是先搞清楚手头有什么数据。Aimsun Next里的输出数据大致可以分成三类，每一类的字段口径和用途都不一样，混着用会出问题。

检测器数据的最大价值是能和实测数据对上。现实中我们在路上埋线圈、放视频检测器、用雷达微波设备，拿到的就是分方向的流量、速度、占有率；Aimsun里的检测器输出天然就是这套口径，所以模型校准环节拿检测器数据做比对是最方便的。也正是因为这一点，我每次建模都会花大量时间把检测器的位置、车道覆盖范围在模型里对齐——位置差一个路段，后面所有比对都白做。

路段和节点统计则是分析拥堵点的主力。路口延误、排队长度只能靠这部分数据看。我经常遇到有人拿网络级平均延误去解决一个具体路口的拥堵问题，那是找错尺子——网络平均值把几十个路口的差异全部抹平了，根本定位不到“哪个转向在哪个时间段开始排队”。想分析交叉口瓶颈，就把节点延误按转向拆开看，再把排队长度曲线叠到上游路段的密度曲线上，多组数据一起看。

网络和路径数据更多用在方案比选。比如“设置潮汐车道之后，整个路网总行程时间下降了多少”，看网络统计；“从A区到B区的通勤时间缩短了几分钟”，看路径统计。这类数据宏观、直观，适合给决策者汇报。另外路径行程时间数据还是验证路径选择模型的重要依据，如果仿真里某条路径的行程时间明显偏离实际，路径选择比例大概率也会偏。

1.2 数据分析不是“最后一步”：它贯穿仿真项目全流程

我在前面说了，数据分析是贯穿项目的暗线。一个标准的Aimsun仿真项目大概是这个流程：基础数据采集（流量、信号配时、公交线路）→ OD需求估计 → 模型构建 → 校准与验证 → 多方案仿真 → 方案评估与汇报。你在第一步采集回来的流量数据就要做异常值清洗；OD反推本身就是一轮大型数据分析；校准环节要将仿真输出和实测数据做GEH比较；最后的方案评估要对比多个场景的指标。所以千万别把数据分析理解成“仿真跑完顺手导个CSV”，它从一开始就参与。

尤其要提醒的是校准环节。校准不是“调几个参数让动画看起来通畅”，而是让仿真输出和实测数据在统计意义上接近。这里的差距用眼睛看不出来，必须用数据算，靠感觉判断也容易出错。如果你想学Aimsun仿真，第一个要掌握的量化工具就是GEH统计量，第二个是速度与行程时间的误差评价，这两个工具后文都会展开讲。我见过不少项目卡在校准阶段，不是模型太复杂，而是缺少一套清晰的数据比对流程。

2. 别急着看数：从项目目标推导评价指标

2.1 单方案评估的指标怎么选：从决策问题出发

仿真跑完，输出文件一大堆，如果不知道自己要回答什么问题，打开数据就是两眼一抹黑。我自己的习惯是：在运行仿真之前，先把项目目标拆成可量化的指标，写在一张纸上，再去找Aimsun对应的输出项。这样既不会漏指标，也不会被无关数据带偏。

单方案评估常见四个维度：

• 通行能力与效率：看饱和度和吞吐量。关键指标是流量（veh/h）、V/C比（饱和度）、路段通行能力。
• 排队与延误：看服务水平。关键指标是节点延误（s/veh）、排队长度（veh或m）、排队溢出次数。
• 网络运行状态：看整体速度与密度。关键指标是平均行程速度、网络平均密度、拥堵里程比例。
• 行程时间可靠性：看通勤者感受。关键指标是行程时间、行程时间指数（TTI，等于实际行程时间除以自由流行程时间）、第95百分位行程时间。

举一个例子。之前做一个交叉口改造项目，业主最关心的是“早高峰北进口排队会不会回溢到上游路口”。对应到指标上，就应该重点看北进口的排队长度累计曲线、该进口道检测器的占有率和下游路段的密度，必要时还要看上游交叉口的拥堵扩散趋势。如果只看片区的平均延误，这个问题根本答不上来。这个案例也说明，指标选择必须从问题出发，指标不是越多越好，而是要能覆盖所有决策关注点。

再提醒一句：Aimsun默认输出的是平均值，但平均值的缺点是把峰值抹平了。我见过不少项目，早高峰延误平均只增加了2秒，但第95百分位行程时间暴涨了30%——对通勤者来说，极端情况才是真实的体感。所以有条件就多看分位值和频次分布，别只盯着均值。尤其是评价信号协调方案的时候，平均延误可能变化不大，但车流的行程时间波动会明显降低，这种可靠性改善恰恰是平均延误看不出来的。

2.2 多方案比选的关键：同口径、多次复现、相对变化率

做多方案比选时最常犯的错是口径不统一。比如现状方案跑了5个随机种子，新方案只跑1个，然后拿单次结果去对比平均值，这结论根本站不住脚。Aimsun是随机交通仿真，车辆生成、路径选择都和随机数有关，同一个方案换一个随机种子，延误可能差3%到5%。要对比，就要保证每个方案都用相同的种子集合、相同的仿真时长、相同的统计时段，起码跑3到5次取平均，必要的时候还要看标准差。

第二个原则是看相对变化率而不是只看绝对值。早高峰路网总延误从400小时降到370小时，下降7.5%，这个百分比比“少了30小时”更能说明缓解程度。尤其在汇报时，决策者关心的是“改善了多少比例”，这个量纲更直观。当然，如果方案评价的是排队的绝对长度或者某个路口的具体服务水平，那绝对值仍然是主角，要看场景灵活选择。

第三个原则是区分“系统效率”和“局部影响”。一个方案可能让全网总延误下降，却让某个转向的排队变长。所以多方案比选时，我会同时输出一套“双层指标”：上层看路网总行程时间、总延误、平均速度；下层看备选方案涉及的关键路口延误和排队长度。两层都过了，方案才敢下结论。

3. 实操：Aimsun导出数据的三种方式与批量处理模板

3.1 方式一：图形界面直接导出CSV

如果你只是临时看一个方案的数据，最简单的方式是在Aimsun里跑完实验后，打开对应的输出视图导出CSV。大体步骤是：实验属性 → Outputs → 勾选需要的检测器、路段、节点统计；运行结束后在左侧结果窗口找到对应表，右键Export，选CSV格式。

这里有两个关键设置容易被忽略。第一个是统计间隔（Statistics interval），默认可能是整个仿真时段聚合，但对于分析拥堵演变来说远远不够，一般设成5分钟或15分钟，早晚高峰更要精细。第二个是预热期（Warm-up period），仿真开始阶段路网是空载的，车辆是逐渐加载进去的，这部分流量是从0慢慢爬升的，不能参与统计，务必在实验设置里把预热期单独划出去，同时要保证预热时长足够路网达到稳定状态，否则后面的指标全都有偏。

导出CSV之后用Excel打开，经常遇到中文乱码或字段错位。Aimsun导出的CSV编码有时候是UTF-8带BOM，Excel打开不带BOM的文件时就会乱码。我的处理办法是先用Notepad++或VS Code把编码转成带BOM的UTF-8，或者直接在Excel里用“数据→自文本”导入并指定编码。这个操作很基础，但能省掉不少后续烦恼。

3.2 方式二：批处理多个Replication，别手动折腾

跑多方案、多随机种子的时候，手动一个个导出太慢。Aimsun实验里可以设置复现次数（Replications），比如每个方案跑5次，系统会生成多份结果。这里的技巧是：在给方案命名时就把场景信息写进文件名，比如“base_rep1”“planA_rep1”，后续用脚本批量读取时，文件名就是你最重要的分类字段。千万别起“新建方案最终版3”这种名字，也别把全部replication混在一个文件里，不然数据处理的成本比仿真本身还高。

我踩过的坑是，默认输出路径如果包含中文或空格，Python的glob匹配容易出问题。建议项目中不管操作界面是中文还是英文，把Aimsun的项目工作目录和输出路径都设成纯英文、无空格，省掉一堆编码和路径问题。另外Aimsun导出的CSV如果有固定的表头格式，建议先导一个模板文件放在脚本目录里，每次数据清洗前先对比表头有无变化，防止软件版本升级后字段名变更导致脚本失效。

还有一点：Aimsun批处理运行可以在排队模式下连续跑多个实验，但中途不要手动打开任务管理器去清理缓存，我遇到过因为外部干预导致结果文件只写了一部分的情况。让软件跑完再碰其他步骤。如果跑的是几十个replication，建议定时看一眼输出目录里文件数量是否在增长，早发现早止损，别等跑了一晚上才发现某个实验卡住了。

3.3 方式三：Python批量汇总，一份模板走天下

多次运行结束之后，你手上可能有一堆CSV文件，靠Excel拼不现实。我习惯用pandas写一个小脚本，一次性把所有replication读进来，按场景聚合出平均值和标准差。类似这样：

import pandas as pd import glob files = glob.glob("results/*_detectors.csv") frames = [] for f in files: df = pd.read_csv(f, encoding="utf-8-sig") # 假设列里包含场景名、检测器ID、流量、速度、占有率 df["scenario"] = f.split("/")[-1].split("_")[0] frames.append(df) all_data = pd.concat(frames, ignore_index=True) summary = (all_data.groupby(["scenario", "detector_id"]) .agg(mean_flow=("flow", "mean"), std_flow=("flow", "std"), mean_speed=("speed", "mean"), mean_occ=("occupancy", "mean")) .reset_index()) summary.to_csv("summary_by_scenario.csv", index=False, encoding="utf-8-sig")

这段代码先把所有CSV读进来，再从文件名前面截取场景名作为新列，最后按场景和检测器聚合。你实际用的时候，列名要按Aimsun导出的真实表头去改，但思路是一样的。把脚本存成固定模板，每次跑完仿真直接拖进去运行，两分钟出汇总表。需要注意，如果不同replication之间流量差异大，别只输出平均值，把标准差也一起输出，后面对比方案可靠性时你会感谢自己多写了这一行。

4. GEH统计量：校准阶段最实用的数据分析工具

4.1 GEH公式与判断阈值

做交通仿真的人不可能绕开GEH统计量。它是校准模型时比对实测流量和仿真流量的行业标准，全称是Geoffrey E. Havers统计量，公式长这样：

GEH = √( 2 × (sim - obs)² / (sim + obs) )

其中sim是仿真流量（veh/h），obs是实测流量（veh/h）。注意两个都用小时当量，别拿15分钟流量直接算。

为什么这个指标好用？因为它同时照顾了绝对误差和相对误差。单纯算百分比误差在小流量路口会失真——实测200辆、仿真220辆，偏差10%，看上去很大，但绝对值只有20辆；用GEH算出来只有1.3，非常温和。反过来，实测2000、仿真2200，偏差同样是10%，GEH大约是3.1，比小流量时更敏感。换句话说，GEH天然地把“流量基数”考虑进去了。

普遍接受的标准是：85%以上的观测点GEH小于5、所有点GEH小于10，模型就算校准通过。如果GEH大于10，说明这个位置的流量差得离谱，必须回头查原因。有些项目会采用更严格的90%标准，具体以项目要求为准，但思路是一样的：GEH是对流量误差做体检的尺子。

4.2 用Python自动算GEH并生成校准报告

我每次校准都要处理几十上百个检测点，人工逐项看根本不现实。用Python可以这样处理：

import numpy as np import pandas as pd def calculate_geh(sim_flow, obs_flow): denom = sim_flow + obs_flow geh = np.where(denom > 0, np.sqrt(2 * (sim_flow - obs_flow)**2 / denom), 0.0) return geh # sim_data / obs_data 分别包含每个检测器的仿真流量和实测流量 sim_data = pd.read_csv("sim_flows.csv") # 列: detector_id, flow obs_data = pd.read_csv("obs_flows.csv") # 列: detector_id, flow merged = sim_data.merge(obs_data, on="detector_id", suffixes=("_sim", "_obs")) merged["GEH"] = calculate_geh(merged["flow_sim"], merged["flow_obs"]) merged["status"] = np.select( [merged["GEH"] < 5, merged["GEH"] < 10], ["PASS", "WARN"], default="FAIL" ) print(merged["status"].value_counts()) merged.to_csv("geh_report.csv", index=False)

这段代码先合并实测和仿真流量，再计算每个检测器的GEH，再按阈值打标。我拿到GEH报告后，第一件事是先看FAIL的检测器分布在哪条路、哪个方向，然后回到模型里查对应的OD路径和通行能力设置。

这里有个很关键的实操细节：仿真统计间隔和实测统计间隔必须对齐。实测流量如果是15分钟一个点，你在Aimsun里也设15分钟统计间隔，然后把15分钟流量乘以4换算成小时当量再算GEH。间隔不一致，GEH几乎肯定失真。另外检测器的位置和覆盖车道也要逐一核对，不能用“大概在路口附近”的检测器数据，位置偏100米，流量可能就不一样。

另外，校准不能只看流量。流量对上了，速度、行程时间不一定对。业内常用的补充指标还有：平均速度的相对误差（建议控制在±10%以内）、行程时间的MAPE（平均绝对百分比误差，建议小于15%）。如果你手头有浮动车数据，对比行程时间比对比流量更有效，因为它直接反映路网运行质量。速度校准的重点在慢速段，如果你仿真出来的速度曲线在中度拥堵区间跟实测差很多，大概率是跟驰模型或换道模型参数需要调整。

5. 可视化分析：曲线、散点图、热力图与方案对比

5.1 流量-时间曲线看图查问题

数据表能告诉你“结果是什么”，但很难告诉你“问题出在哪”。流量-时间曲线是最基础也最常用的图，横轴是时间，纵轴是流量。把同一个检测器的实测流量和仿真流量画在一起，能一眼看出峰值形状是否吻合。

有一次我仿真一个快速路入口匝道，单看GEH都在5以内，但画曲线发现仿真早高峰峰值比实测早了半小时。后来排查了很久，发现是出行需求的时间分布文件没更新，还是用的上一版数据。这种问题光靠GEH表根本看不出来，一画图就露馅。所以我现在每次拿到新的OD或需求时间分布，都会第一时间在项目备注里写清楚版本号，避免又栽在数据版本上。流量-时间曲线除了对比早晚高峰峰值，还要看双峰形态是否吻合，有些城市的午间小高峰很容易被忽略，这些细节在表格里不显眼，图形上一目了然。

画法上我建议：早高峰单独画、平峰期单独画，不要挤在一张图里，因为流量尺度不一样，放在一起会把峰值段的细节压平。横轴用统计间隔的起始时间，纵轴用veh/h，标注清楚方向和检测器位置，图例里写清楚“实测”和“仿真”。

5.2 速度-流量散点图与时空热力图

如果你想分析路段的拥堵机理，速度-流量散点图很直观。横轴流量、纵轴速度，理想状态下流量增加时速度下降，形成一条类似“倒钩”的曲线，后半段就是拥堵态。多时段数据叠上去之后，你能看出这条路段在什么流量条件下开始崩溃，这对设置限流策略很有帮助。

时空热力图适合看拥堵在路网上的蔓延过程。横轴是空间位置（从上游到下游），纵轴是时间，颜色代表速度或密度。施工占道、事故封闭这类场景，热力图能把拥堵上游排队、下游消散的全过程展示得非常清楚。Aimsun里可以用多个检测器的时间序列数据拼出来：把每个检测器的速度按时间对齐，用matplotlib的pcolormesh直接画。

import matplotlib.pyplot as plt import numpy as np # data 为二维数组，行=时间点，列=检测器位置，值=速度 fig, ax = plt.subplots(figsize=(10, 6)) im = ax.pcolormesh(data, cmap="RdYlGn_r") ax.set_xlabel("检测器位置（上游→下游）") ax.set_ylabel("时间") plt.colorbar(im, label="速度(km/h)")

代码很简单，但数据对齐是个体力活。建议在整理数据时把检测器位置的顺序固定下来，用编号而不是名字排序，不然画出来的横坐标顺序会乱。

5.3 方案对比图：柱状图带误差条、雷达图做初筛

多方案比选的时候，柱状图是最常用的。但我要特别提醒：柱状图一定要带误差条。你有5次replication的数据，可以算出均值和标准差，把标准差画成误差条，这样方案之间的差异到底是真的还是随机波动，一眼就能分辨。

如果评价维度多、方案也多，我推荐用雷达图做一轮“初步筛选”。把延误、行程时间、排队、速度这些指标做归一化处理后画成雷达图，哪个方案在哪个维度上有短板，图形上非常明显，适合在项目组内部快速对齐讨论方向。不过雷达图只适合内部讨论，不适合正式汇报——正式汇报还是用带误差条的分组柱状图更严谨，毕竟决策者要的是具体数值和可靠性范围。

可视化工具上，我用得最多的是Matplotlib和Seaborn，备选是Power BI和Tableau。仿真分析阶段代码画图够用，到了给业主做汇报材料阶段，把整理好的数据导入Power BI做交互看板，反而省事。

6. 常见问题与排查技巧实录：那些踩过的数据坑

6.1 导出NaN、负值怎么处理

我遇到过几种情况：部分检测器在无车通过时输出NaN；排队长度在没有任何排队时可能输出0；偶尔还有速度为负数的情况，大概率是车辆变道或仿真输出异常。处理原则是：先判断数据是否合理，再决定是剔除还是填充。无车通过的NaN可以填0，但如果是路段中途的检测器，无车时间很长就得检查是不是车辆根本没走那条路，而不是简单填0掩盖问题。另外Aimsun导出的时间戳格式偶尔会带毫秒，读进来之后先统一转换成标准时间格式，再做聚合，不然时间对齐会错位。

6.2 校准对不上：先查数据，再调模型

按我自己的经验，校准时发现仿真流量和实测流量差10%以上，先别急着调参数。排查顺序是：先检查检测器位置是否对应准确，Aimsun里检测器放在哪个路段、哪个车道，实测线圈覆盖范围是否一致；然后检查时间口径，15分钟实测和5分钟仿真不能直接比；再检查OD矩阵，尤其是高峰时段的需求总量；最后才考虑调整路径选择参数和通行能力。我经手的项目里，80%的“对不上”其实是数据口径问题。

6.3 随机种子影响大：多跑几次取平均

随机种子是微观仿真的重要特性，车辆生成、换道决策都带着随机性。如果两个方案的差异小于多个replication之间的波动，结论就是“无显著差异”。正确做法是：每个方案至少跑3到5个replication，取平均值做对比，同时汇报标准差或95%置信区间。对结果不放心的时候，可以用简单的t检验判断两个方案指标是否有显著差异，Excel和Python里都能做。另外注意，Aimsun实验设置里可以固定随机种子，比较方案时最好保持相同种子编号，单独看方案差异；如果要做可靠性分析再放开种子。

6.4 一张速查表：常见数据问题排查路径

下面这张表是我平时排查数据的起点，遇到问题先照着过一遍，能解决大部分常见的异常。

写到这，这套从导出到清洗再到GEH计算和可视化的分析流程算是闭环了。我自己这些年做Aimsun项目最大的体会是：别迷信动画，也别迷信单一指标。动画只是辅助判断，单一指标容易把方案带偏——延误降了但排队还是溢到上游，行程时间降了但速度分布更不均匀，这些都是只盯一个数看不出来的。现在我做仿真，方案跑完先不急着截图，先把数据导出到本地，用脚本把关键指标过一遍，确认没有问题后再回头看动画。这个小习惯帮我挡掉了不少测试时没暴露的问题。

最后再分享一个小技巧：把常用的分析脚本、字段映射表、GEH计算函数攒成一套自己的工具模板，每次新项目直接改路径就能用。仿真项目的周期本来就长，能自动化处理的环节一定不要手工做。数据这块省下来的时间，足够你多跑两轮方案对比，方案质量自然就上来了。如果你刚开始做Aimsun，也建议先建立一个简单的检测器信息登记表，把检测器编号、位置、车道、对应实测文件的关系固定下来，后面每次校准都能省一半力气。