Aimsun交通仿真数据分析实战：取数、指标计算与可视化指南

1. 先起个底：Aimsun到底会输出哪些数据，哪些值得留

前阵子帮某市做一个片区信控优化项目，Aimsun模型跑一遍仿真，输出文件直接塞满了我的移动硬盘。20多个G的数据摆在面前，真正能写进报告里的结论其实只有几个数字：延误降了多少、排队长度缩短多少、路网平均速度提了多少。但为了把这几行结论抠出来，我硬是花了两天处理数据。

那次之后我彻底想明白一件事：在交通仿真这条链路里，建模花三周，数据分析花的功夫一点不比建模少。Aimsun这类微观交通仿真软件的强大之处，不只是它能模拟每一辆车的加减速和变道，更在于它源源不断吐出来的数据流——单次仿真可能涉及数万个时间步、上千个检测器、几百条路段，每一层都有数据可以挖。很多人第一次接触Aimsun，把精力全放在画路网、标定参数上，等模型跑通了一看输出傻了眼，不知道怎么把那些表格和轨迹文件变成决策依据。这篇就专门聊这块，把Aimsun数据分析从取数、算指标到可视化的完整路径捋一遍，顺手把我踩过的坑也摊开说。

如果你正在做交通仿真项目，或者刚接触Aimsun想搞清楚仿真结果怎么用，又或者你手头有别人的仿真输出文件不知道怎么处理，这篇都适合你。下面前三个部分偏基础，后面偏实操，建议按顺序看。

1.1 先分清Aimsun的数据家底：静态、动态、指标三类数据

Aimsun的数据要分三类理解。第一类是静态路网数据，包括路网的几何信息、车道数、路段限速、节点转向、信号配时方案、检测器布设位置等。这些数据描述的是“这条路长什么样”，不随时间变化，通常在建好模型导出时一次性拿全。分析阶段经常要用它做底图，比如把某条路段的限速和仿真速度放在一起对比，如果没有路网属性表，后面一切分析都缺个参照系。

第二类是动态仿真数据，这是大头。微观仿真里每辆车每个时间步的位置、速度、加速度、所在车道、当前路径都会被记录，中观和宏观层面则会输出路段流量、平均速度、密度、占有率、排队长度、延误、旅行时间等聚合值。Aimsun原生输出覆盖了从“每一辆车的微观轨迹”到“每条路段的宏观统计”的完整层级，这也是它比很多轻量级工具强的地方。

第三类是仿真运行自身的统计指标，比如路网总旅行时间、总延误、总行驶里程、平均速度、排放量。这类指标一般直接汇总在仿真的统计报表里，做方案比选时最省事，打开报表就能看到几个关键数字。

理解这三类数据的意义在于，不同的分析问题需要动用不同层的数据。举个例子，你要评估某个交叉口信号配时改后的效果，用第三类路网总指标就太粗了，得用第二类的按路段、按转向的延误数据。你要做排放分析，那就得细化到第一类路网的坡度、车型组成和第二类的逐秒速度序列。数据层级选错了，结论基本站不住。

1.2 数据的时间尺度和空间粒度，越细越贵

Aimsun数据分析里最容易翻车的就是粒度选择。同一份仿真结果，按宏观层面每15分钟输出一次流量，数据量也就几十KB；如果按微观层面每0.1秒记录一次所有车辆的位置和速度，一次几十分钟的仿真就能生成上亿行记录，直接把你的分析工具干崩。

我自己的习惯是：目标决定粒度。做路网整体运行评价，用宏观聚合数据，时间步长取5到15分钟即可；做瓶颈路段成因分析，用中观数据，路段断面按每分钟聚合，能看清排队扩散的过程；做信号配时优化或者网联车场景研究，才需要微观逐车数据，这时候也别全量存，只保留目标路段、目标时段的车辙数据就够了。

这里有一个务实的建议：在Aimsun里配置输出项的时候，只勾选当前项目真正需要的指标。一开始做项目时我习惯把能勾的都勾上，结果一次仿真的输出文件几个GB，后期清理和转换浪费了大量时间。后来改成了“最小够用”原则，跑完发现缺什么再补跑一次仿真，反而比处理超大文件更快。数据粒度不是越细越好，是越合适越好，想清楚分析目标再决定输出配置，能帮你省掉后面一大堆麻烦。

2. 数据怎么取才顺手：从报表导出到API自动化的完整路线

数据在Aimsun里躺好了，下一个问题是怎么把它拿到分析环境里来。这一步有不少人卡住过，Aimsun的输出分散在好几个地方，报表、日志、数据库、OD文件各管一摊，第一次接触容易找不到北。我把常用的三条路线理了一遍。

2.1 自带的统计输出与导出：第一次接触时的最快路径

如果你只是临时看几个数字，Aimsun自带的统计表格就够用。仿真跑完后，界面里的“统计”窗口会列出每个检测器、每条路段的流量、速度、占有率、排队等数据，还能按时间段切片查看。想把数据带出去做进一步处理，可以用导出功能输出成CSV或者通过ODBC写入数据库。

这条路径适合快速验证和生成报告附件，但只适合轻量使用。自带的统计报表格式是固定的，列名、单位、时间粒度都得迁就它，做多个方案对比时要手动一个个打开表格复制粘贴，效率很低。而且Aimsun界面表格在数据量大时滚动会卡，你也没法直接在表格里做筛选、透视或者画图。我的经验是把它当成“应急通道”而不是主通道。

2.2 Python API抽取检测器数据：写给脚本控们的方案

真正做数据分析，还是得走Aimsun的开放API。Aimsun的脚本接口比较特殊，它底层用ANGLan语言，但新版提供了Python绑定，可以让你在仿真运行时直接操作模型对象和读取数据。这是个非常强大的功能，相当于把整个仿真模型变成了一个可以编程访问的数据库。

举个最典型的场景：批量跑10个方案，每个方案都要提取某几个关键交叉口的转向流量和平均延误。用界面操作你得重复十遍“打开报表、找交叉口、记录数据”，用脚本则是一遍循环搞定。逻辑大概是这样：

# 以Aimsun的Python接口为例，逻辑示意 # 假设已经获取了model、simulation对象，并按检测器id遍历 import pandas as pd results = [] for det_id in detector_ids: detector = model.getDetector(det_id) flow = detector.getDataValue(simulation, "flow", aggregation="hour") speed = detector.getDataValue(simulation, "speed", aggregation="hour") results.append({"detector": det_id, "flow": flow, "speed": speed}) df = pd.DataFrame(results) df.to_csv("detector_summary.csv", index=False)

写脚本要适应Aimsun的API版本差异。老版本和新版本之间，函数名、参数类型都有些变化，最好先在交互环境里用dir()把对象的属性和方法摸一遍再动手。另一个技巧是：如果项目里有多个仿真场景，把数据提取脚本写成接受场景参数的函数，跑完一个方案就自动导出一份数据，这样分析流程就能和仿真流程并行起来。

2.3 数据落库与批量处理的标配流程

数据从Aimsun导出之后，我一般不会直接丢进分析脚本，而是先落一次库。普通项目用SQLite就够，单文件、零配置、pandas直接读；数据量到了千万行级别，就换DuckDB或者PostgreSQL。为什么要先落库？因为仿真数据天生适合用SQL来做筛选、聚合和关联分析，你常常需要“按路段查所有时段的流量”“按交叉口查所有转向的延误”，这些用SQL一条语句就出结果，用pandas写起来又绕又容易错。

至于热搜里常出现的Spark、Hive那套大数据方案，说实话在Aimsun分析里大部分场景用不上。我做过最大的项目，一次跑完的原始记录也就几千万行，单机DuckDB处理没压力。真到了需要分布式计算的地步，通常是你要对成百上千次仿真做批量留存和统计，这时候才值得考虑Spark。技术选型别跟风，先掂量数据量，再决定用多重的工具。

3. 拿到数据之后算点什么：标定、排队延误、方案对比三板斧

数据取出来了，下一步就是分析本身。Aimsun数据分析虽然有无数种玩法，但落地到实际交通项目，九成需求集中在三块：验证模型准不准、评估运行状态好不好、比较方案哪个更优。这三块分别对应标定指标、延误排队分析、多方案对比，下面一个个说。

3.1 模型标定必算的GEH与误差指标

很多人在标定阶段只盯着“看起来像不像”，这个习惯得改。Aimsun模型跑出来的流量分布和实测值接近，不代表模型真的可靠，你得用统计指标说话。当前行业内最常用的就是GEH统计量，它由英国公路局提出，专门用来衡量仿真流量与实测流量的吻合程度。

GEH的公式是：

GEH = sqrt(2 * (Sim - Obs)^2 / (Sim + Obs))

其中Sim是仿真流量，Obs是实测流量，单位都是veh/h。如果Sim和Obs都为0，直接令GEH为0，避免除零。这个公式的巧妙之处在于，它同时考虑了绝对误差和相对误差，流量大的路段允许更大的绝对偏差，流量小的路段要求更精确，不会出现“高流量路段一个小偏差就报警、低流量路段误差好几倍却通过”的怪现象。

行业通常的做法是按GEH < 5作为通过标准，且要求至少有85%的检测断面满足这个条件。在计算时要注意时段对齐，实测数据是早高峰7:00到9:00，仿真数据也要取同一个时段，不能拿全天平均去和高峰小时比。除了GEH，还可以配合计算流量误差百分比和速度误差来交叉验证。我见过一个项目，GEH全达标了，但每条路的平均速度都比实测低8%以上，后来排查发现是自由流速度参数没标定好，说明只看一个指标容易漏掉系统性问题。

3.2 延误、排队与行程时间的拆解分析

延误是最能直观反映道路运行质量的指标，但也最容易被算错。Aimsun里延误有好几种口径：控制延误（control delay）指车辆受信号控制影响的延误，停车延误（stopped delay）指车辆真正停下来等待的时间，行程延误则是实际行程时间与自由流行程时间之差。写报告时如果不注明口径，数据之间没法横向比较，和甲方扯皮的风险也高。

实践中最常用的是控制延误。Aimsun在每个信号交叉口的进口道上通常会有对应的延误检测数据，可以直接读取。但要注意，如果你只取平均值，可能会掩盖一个严重问题——某个进口方向延误特别高，但平均下来看起来还过得去。所以分析延误数据时，我习惯按转向分开看，再叠加一个时间序列图观察延误在高峰时段内的变化趋势。排队长度同理，不光看最大排队，还要看排队是否溢出到了上游交叉口，这往往是路网拥堵连锁反应的第一信号。

行程时间的分析也有讲究。Aimsun可以按OD路径输出旅行时间，分析时要区分“平均行程时间”和“95分位行程时间”。前者反映整体效率，后者反映可靠性。在公交优先或者预约出行这类场景里，可靠性比平均值更重要。把这两个指标同时列出来，报告的说服力会提升不少。

3.3 多方案横向对比与敏感性分析

做方案比选，最容易犯的错是拿单次仿真的结果直接下结论。Aimsun的微观仿真里面有随机性，每次运行的种子（seed）不同，车辆的发车时刻、路径选择都会有些差异，单次运行的指标可能碰巧偏高或者偏低。正确的做法是每个方案至少跑3到5次不同随机种子，取平均值做对比，有条件的话再做统计检验。

对比时不要只盯路网总延误这一个数。我习惯把每个方案的关键指标整理成一张表，包括路网总旅行时间、平均速度、总延误、关键交叉口的排队长度、行程时间可靠性等。然后画分组箱线图，看分布的重叠情况。如果两个方案的平均值差了2%，但箱线图完全重叠，那这个差异大概率是随机波动，不能算有效改善；如果箱子分开得很明显，即使平均值差距不大，也说明方案确实产生了系统性的影响。

敏感性分析同样重要。交通模型里OD需求是最大的不确定因素，我通常在基准需求的基础上按0.9、1.0、1.1、1.2倍做几档灵敏度测试，看路网平均速度怎么变化。如果需求从1.0提到1.1时路网速度断崖式下跌，说明路网正处在容量临界点，项目报告里要特别提示这个风险。这类分析用API批量跑，配合脚本自动汇总，是高效且规范的做法。

4. 可视化让仿真结论落地：时空图、路网热力和自动化报告

数据分析的最后一公里是表达。Aimsun自带的三维动画适合演示，但真到写报告、开评审会的时候，静态的、清晰的、带结论指向的图往往更有说服力。仿真数据量大、维度多，可视化做好了能省掉大量文字描述。

4.1 时空图：速度、密度、排队的最直观表达

时空图是我最推荐的可视化形式。横轴是时间，纵轴是空间位置，用颜色或等高线表示速度，一张图就能看出整条路从畅通到拥堵再到消散的完整过程。拥堵形成的位置、向上游传播的波速、消散的时机，全都一目了然。

用Python画时空图并不复杂。假设你已经从Aimsun导出了某个路段上按时间和位置切片的速度矩阵，Excel透视或者pandas整理成长表之后，直接画填充等高线：

import pandas as pd import matplotlib.pyplot as plt # 假设df包含四列：section_id, time_step, position, speed df = pd.read_csv("speed_space_time.csv") pivot = df.pivot_table( index="position", columns="time_step", values="speed", aggfunc="mean" ) plt.figure(figsize=(12, 6)) cf = plt.contourf( pivot.columns, pivot.index, pivot.values, levels=20, cmap="RdYlGn" ) plt.colorbar(cf, label="速度 (km/h)") plt.xlabel("时间 (s)") plt.ylabel("位置 (m)") plt.title("路段速度时空图") plt.tight_layout() plt.savefig("space_time_diagram.png", dpi=200)

出图之后要做的不是直接贴进报告，而是先看图找结论。比如图上深红色区域斜向延伸的边界，那条斜线就是拥堵波向上游传播的速度，可以在图上标出来，配一句文字说明。这种“有标注的图”比单纯一张热力图更有分析价值。

4.2 地图路网着色与Web化展示

需要把分析结果落到路网上时，地图着色是最直观的表达。Aimsun本身有GIS图层导出功能，你可以把路网导出为GeoJSON或者Shapefile，然后在Python里把仿真指标关联到每条路段，用folium生成一个可交互的Web地图，按速度或者V/C比给路段着色。

这个方案特别适合给甲方交底。打开HTML文件就能看到整个路网上哪些路段是绿的、哪些是红的，点击某条路还能看到具体的流量、速度和延误数据。相比静态图片，这种交互式展示在评审会上的效果明显更好。实现成本其实很低，核心就是“路网GeoJSON + 仿真指标DataFrame”做一个merge，再传给folium的Choropleth图层。

有一点要注意：路段编码必须在两个数据源里保持一致。Aimsun导出的路段ID和你分析用的路段ID如果对不上，地图上一片空白。我一般直接用Aimsun内部的section ID做关联键，导出GeoJSON时就把这个ID带出来，不要在中间环节重新编号，省得对表时出问题。

4.3 用自动化脚本出报告，减少重复劳动

仿真项目有一个特点：分析流程高度重复。今天是10个方案，明天可能是20个方案，画图、算表、做汇总的套路是完全一样的。所以从第一次开始，就应该把分析流程固化成一个脚本，而不是每次手工作业。

我现在的标准流程是：Aimsun跑完仿真后自动导出CSV，然后一个Python脚本依次完成数据清洗、指标计算、图表绘制和Excel报告生成，一套下来十几分钟，产出物直接就是一份带图、带表的初步分析报告。用了这套流程之后，我在一个连续跟踪了三个月的项目里，每次更新方案数据只要跑一次脚本，节省的时间非常可观。

自动化报告里有一项容易被忽略但很出效果的内容：动态对比表。把每个方案在不同时间段的指标并排列成一个透视表，再配上同比变化率，一眼就能看出某个方案是不是只在某一时段有效、其他时段反而恶化。这种“具体时段具体分析”的表达方式，比给一个全天平均值专业得多。

5. 仿真数据处理的真实战场：问题复盘与避坑清单

Aimsun数据分析看着流程清晰，真正跑起来还是处处有坑。下面这些是我在项目里实际遇到过的问题和对应的处理办法，也算一份应急手册，按顺序排的，越往后越是容易被忽略的隐形问题。

5.1 输出文件太大、内存爆掉怎么处理

微观测数据是数据量爆炸的重灾区。有一次我按0.5秒粒度记录了全路网车辆轨迹，仿真时长一小时，导出的文本文件压缩前接近30GB，pandas一读就内存溢出。后来改成“分时段、分路段”的条件导出，只保留早高峰前15分钟和关键走廊上的数据，文件瞬间缩到几百MB，分析照样做。

你还可以用高效格式替代CSV，Parquet格式压缩率高、读取快，处理同样数据量比读CSV省一半时间。另一个技巧是能选列就别全选，很多输出文件里包含对当前分析没用的字段，导入时直接用usecols参数只加载需要的列，可以明显降低内存峰值。真碰上超大文件的聚合统计，就用DuckDB这种列式数据库，它可以直接在压缩数据上做GROUP BY，不用把数据全塞进内存。

5.2 随机种子不固定，一切对比都是耍流氓

这个坑我踩得很实在。有次对比两个信号方案，第一次跑出来方案A明显优于方案B，我差点就写结论了。但第二天重新跑了一遍，两个方案的优势居然反过来了。原因就是两次仿真使用的随机种子不同，车辆随机发车的时间序列不一致，把这个差异全掩盖了。

从那之后我定了一条规矩：凡是做方案对比，必须固定随机种子，而且每个方案最少跑3个不同种子做重复实验，取平均值并记录波动范围。在写数据分析脚本时，直接把种子作为参数传进去，循环跑完自动汇总。做完这些再对比，方案差异是否来自真实效果，心里就有底了。

5.3 口径不一导致指标对不上，先统一定义再开始分析

Aimsun里的“延误”“排队长度”在不同版本和不同输出选项下，定义可能不完全一样。有个很典型的情况：Aimsun某类输出里排队长度用的是“最大后排队尾距停车线的距离”，另一个模块里用的却是“平均排队车辆数”，单位都不一样，放一起对比必然出错。还有速度指标，有的是时间平均速度，有的是空间平均速度，两者数值上有系统性差异。

所以在开始任何分析之前，先把所有指标的定义、单位、统计方式列一张表，对照Aimsun的文档逐项确认。这一步看起来繁琐，但能避免后面返工。遇到跨版本项目更要注意，版本升级后某些输出字段的默认口径可能变了，老项目里写的SQL重新跑一遍前，先检查口径是否一致。

5.4 常见问题速查表

5.5 最后说一个被忽略的细节

数据分析还有一个很容易被忽略的细节：时间基准线。Aimsun仿真的时间起点是仿真时钟的0秒，但实际项目里我们关心的是早高峰7点到9点，中间还有15分钟的预热加载时间。如果直接取仿真时间0到7200秒的数据，会把预热期的空路网状态也算进去，平均旅行时间会被明显拉低，延误会被低估。正确的做法是先确认模型的“预热时间”设定，在分析时把这一段数据排除掉。

另外，Aimsun输出的时间戳一般是从仿真开始算起，不是真实世界时间。要和你采集的实测数据对齐，需要先把仿真时间换算成“仿真开始时刻 + 经过秒数”，这一步换算没做好，后面所有时间维度上的对比分析都会错位。这些细节单个看起来不起眼，但在实际项目里它们往往是数据对不对得上、结论站不站得住的根因。

我个人在实际操作中的体会是：仿真模型再精细，如果数据分析这关过不了，项目交付就始终差一口气。把数据流程想清楚、工具链搭顺手，把随机性、口径、时间基准这些基础问题按规矩处理干净，Aimsun这套仿真工具才能真正变成决策支持的可靠依据。希望这篇里写的思路和坑，能让你在下一个项目里少熬几个夜。