企业官网建设流程全解析

做交通仿真最忌讳的一件事，就是把模型当主角，把数据当配角。我在Aimsun项目里摸爬滚打的体会是：如果数据这关没过，后面调参数、看结果都是在自我安慰。本期继续Aimsun系列，专门聊透交通数据分析——从外场采集到OD反推，再到模型校准和结果解读，把整条数据链路串一遍，顺便把一些文档里不会写的东西也掏出来。这篇适用于正在做仿真项目但又觉得数据“脏、乱、难对齐”的同行，也适合刚接触Aimsun、想搞清楚数据到底怎么驱动模型的朋友。

1. 仿真之前，先想清楚数据这副牌怎么打

1.1 交通数据分析在仿真流程里的位置

很多人以为Aimsun建模型就是从画路网开始的，其实路网只是骨骼，数据才是血肉。一个完整的Aimsun仿真项目，流程大致是：明确分析目标、整理基础数据、构建路网、生成OD需求、标定参数、模型验证、输出指标、方案评估。数据分析不是其中某一个环节，而是从第二步贯穿到倒数第二步的隐形主线。

你想想，画路网要车道数和限速，这是几何数据；跑分配要OD矩阵，这是需求数据；校核模型要断面流量和行程时间，这是观测数据。哪一步离开数据都转不动。所以我的习惯是，接到项目先不急着打开Aimsun，而是先花两三天把所有能拿到的数据摆到桌面上，分类、比对、找矛盾，先理清楚“我们到底知道什么、不知道什么、哪些数据要凑合着用”。这个阶段决定了后面模型能调到什么精度。

1.2 数据体系的五大类别与优先级

按我自己的整理习惯，Aimsun交通数据分析涉及的数据可以归成五类，每一类的获取难度和影响程度都不同。

第一类是道路几何数据，包括路段数量、车道数、车道宽度、转向专用道、限速、坡度、渠化方式。这类数据决定路网的容量和运行规则，主要靠电子地图、航拍影像和现场踏勘。第二类是交通需求数据，最核心的是OD矩阵，分级别的有分时段的OD、分车型的OD，更精细的还有OD的路径偏好。这部分最难拿，通常是靠推算而不是靠实测。第三类是交通控制数据，包括信号配时方案、相位设置、周期、绿信比，以及停车让行、限行、禁左这些管理措施，直接从交管部门要，或者现场测信号机。第四类是交通运行观测数据，典型的是路段流量、车速、排队长度、行程时间，用来做模型校验。第五类是公交与慢行数据，如果你的模型要评估公交优先或慢行改善，就得把公交线路、班次、停站时间、站点上下客量、行人过街流量纳入进来。

优先级排序上，我的经验是：几何数据必须准，错一条车道容量就错一截；信号配时不能想当然，它直接影响交叉口延误；OD矩阵决定全局分配结果，宁可粗糙也不能拍脑袋；观测数据是用来“校准”和“挑错”的，至少要覆盖关键断面。几何和信号出错了，后面再怎么调都是补窟窿。

1.3 仿真精度取决于最弱的一块板

仿真模型精度不是由最准的数据决定的，而是由最弱的那块板决定的。木桶原理在交通仿真里体现得淋漓尽致。举个典型场景：如果路网几何画得很精细，信号配时也拿到了，但OD矩阵用的是拍脑袋估的总体流量，那最终分配出来的路径流量大概率对不上实测。你可能花大量时间调驾驶行为参数，结果发现怎么调都调不进去，最后回头一查，是OD总量本身就错了5%。

所以我一直强调一个工作原则：在数据准备阶段宁可多花一倍时间，也不要急着进建模环节。前期把每种数据的关键属性记下来，标注来源、时间、精度，后期就能快速锁定问题出在哪一类数据上。数据清单不仅是工作痕迹，更是排查问题的地图。

2. 外场数据从哪儿来：采集手段与预处理红线

2.1 流量数据的典型来源与口径差异

路段流量是最常用的观测数据，但它不是“一个数”，而是一串带时间、带口径、带误差的记录。不同来源的流量数据差异很大，必须先把口径对齐。

常见流量来源包括：地磁检测器、视频AI识别、微波雷达、浮动车GPS轨迹反推、电子收费门架数据。地磁和雷达给的是点断面的实时流量，时间粒度可以细到5分钟甚至1分钟，但设备可能故障、会漏检；视频识别能同时给流量和车型，但对光线和天气敏感；浮动车数据能覆盖路网，但样本率不稳定，高速上还好，城市次干路可能样本极少；电子收费数据主要覆盖封闭道路出入口，能算区间流量，但拿不到中间路段的连续流量。还有一类是人工调查，比如路口转向流量调查，精度取决于调查员水平和时段覆盖，通常只能做短时段抽测。

这里要注意单位口径：交通工程里常用pcu/h（标准小客车当量），但检测器原始输出往往是veh/h（自然车流量）。如果不折算，公交车、货车多的一条路，仿真容量会被高估或者低估。折算系数不是固定的，城市主干路一般小客车1.0、公交车1.5-2.0、货车看轴数从1.5到3.0都可能。我见过有人直接把自然车流量输进去当pcu/h用，结果模型路网饱和流量虚高，延误全线偏低，怎么标定都标不出实际拥堵——最后发现是单位没换算。

2.2 数据清洗的几个容易被忽略的步骤

采集回来的流量数据不能直接用，至少要做四步清洗。

第一步是异常值识别。单点流量突然跳零或者翻几倍，通常是设备故障、线缆被压坏或软件误判。我的做法是先把时间序列拉出来画图，肉眼扫一遍，再用简单的统计规则筛——比如某个时段流量超过前后三天同时间段均值的三倍，就要怀疑是异常。第二步是节假日处理。节假日流量模式和普通工作日完全不同，如果把周一早高峰和国庆节的数据混在一起标定模型，模型学不到任何稳定规律。模型用的观测数据，要么取典型工作日，要么把节假日单独建场景，不要混。第三步是天气筛选。大雨天流量和通行能力都下降，除非你专门建恶劣天气场景，否则别拿暴雨天的数据做基准。第四步是时空一致性核对。比如两个相邻断面，上游流量应该和下游流量在考虑了出入口后大致平衡，如果某个断面连续几天比下游还大，那一定有入口、出口或者检测器逻辑问题，得回头查。

还有一个非常容易被忽略的细节：检测器数据的时间基准。有些设备记录的是本地时间，有些是服务器时间，如果不同设备时间没对齐，你拿上游和下游断面做关联分析时，相位会错位，看起来就像车流“凭空消失”了一样。做数据分析前，先把所有数据统一时间戳，至少对齐到分钟级。

2.3 信号配时与几何数据的结构化整理

信号配时数据是交叉口延误计算的核心输入，但也是最容易输错的一类数据。一份信号配时方案通常包含周期时长、相位编号、各相位绿信比、黄灯时间、全红时间，以及相位之间的搭接关系。从现场拿到的原始资料可能是信号机厂商的二进制导出文件、Excel表、甚至手写记录。我的做法是先制作一个标准的信号配时录入模板，一个交叉口一张表，每行一个相位，记清相位编号、包含的进口道、起亮时刻、绿灯时长、黄灯时长、全红间隔，并和路网里的信号灯组编号一一对照。这样在Aimsun里设置时，直接按表录入，不容易漏。

几何数据方面，现在很多人直接从在线地图或开放街道地图拉路网然后导入Aimsun，快是快，但问题也不少。最大的坑是车道数和转向车道关系。在线地图数据里，一条路画成双黄线，但现场可能是中央隔离加左转待转区；地图上可能没画公交专用道，或者渠化岛的转向箭头和实际不一致。我的原则是：电子地图只用来搭骨架，车道数、限速、转向专用道必须以航拍图和现场核查为准。

几何数据还要注意坐标和单位。模型里建议统一用米制坐标，如果从地理坐标系导入，要确认投影方式，不然路网会出现莫名其妙的拼接错位。另外Aimsun路网里路段的“长度”必须是道路中心线长度，如果从地图导入后出现大量路段过长或过短，会影响后面的行程时间计算。

3. OD矩阵的“无中生有”：从断面流量反推需求

3.1 为什么OD比流量更难拿

OD矩阵是整个模型里最值钱也最难拿的一组数据。流量数据描述的是“某个断面上过去了多少车”，OD数据描述的是“这些车从哪儿来、到哪儿去”。前者是观测结果，后者是出行需求。你可以在路上架满检测器数出每一辆车的流量，但你数不出它的出发地和目的地。

传统上拿OD靠居民出行调查、驾驶员询问或者车牌识别配对，成本高、周期长，而且经常覆盖不全。实际操作中，做现状模型时OD矩阵大部分是靠“反推”出来的——用观测路段流量，反推一个OD矩阵，让这个矩阵在分配后的模拟流量尽量接近实测流量。这个过程有个专业名字叫OD矩阵估计，听起来高大上，本质上就是解一个大型方程组，只不过变量太多、方程不够，需要加各种约束才能得到唯一解。

3.2 静态OD反推的流程与参数标定

在Aimsun里做OD反推，大体分四步。

第一步是准备初始OD矩阵。即使没有实测OD，也得给一个合理的初始猜值，比如按各交通小区的土地利用、人口岗位数按比例估算。完全不设初始矩阵直接反推，结果往往发散得很离谱。第二步是选择约束路段。把有检测器、流量可信的断面挑出来作为反推的约束条件。这些断面最好覆盖穿越性交通、内部交通和主要的进出通道，让每个交通小区至少有几条路径被观测到。第三步是设置反推参数。Aimsun的OD估计模块里要设迭代次数、收敛阈值、还有对初始矩阵的信任程度。信任程度这个参数很关键，如果设为0.8，意味着反推结果比较保守，偏向初始矩阵；如果设为0.2，则更偏向拟合观测流量。第四步是迭代分配-反推，每次反推完重新分配流量，再比较模拟流量和观测流量的误差，反复迭代直到GEH值达标。

整个过程不是一键完成的。我的经验是分时段做，早高峰、午平峰、晚高峰分别建OD场景，不要用一个OD矩阵打天下。高峰时段出行目的构成不同，OD时空分布差别很大。混合用一个OD，普遍会出现早高峰某些路段分配不足、某些路段过饱和的现象。

3.3 动态OD与基于大数据的补充

静态OD反映的是一个时段内的平均需求，但如果项目要看排队溢出、信号联动、动态诱导这类问题，静态OD不够用，得考虑动态OD估计。动态OD的复杂度更高，它要用检测器的时间序列流量反推出每个时间间隔（比如15分钟）内的OD变化。Aimsun支持基于微观仿真的动态OD估计，计算量大且参数敏感，做之前一定要确认项目需求和计算资源是否匹配。

现在还有一个趋势，是用手机信令数据、网约车订单数据、导航地图的路径数据进行OD补充。这类数据覆盖广、样本大，但偏差也很明显——手机信令会把过境车辆、非机动车混进来，网约车订单则天然缺少货车和公交。我的做法是把它当作辅助数据，用来校正OD的空间分布形态，再结合断面流量反推绝对量级。简单说，大数据告诉你“车都往哪儿去、大致走什么路径”，流量计告诉你“到底有多少车在路上”，两者结合，才能得到相对可靠的OD矩阵。

4. 用数据喂饱模型：校准与验证的数据分析闭环

4.1 GEH指标：我是怎么看模型有没有调“准”的

模型建好、OD跑完，下一步就是校准。校准的核心是比较模拟流量和实测流量的吻合度。业界最常用的指标是GEH统计量，公式很简单：GEH等于2倍（模拟流量减实测流量）的平方除以（模拟流量加实测流量），再开根号。这个指标的好处是它平衡了绝对误差和相对误差，车流量大的路段允许大一点的绝对偏差，车流量小的路段偏差要求更严。

评判标准一般这么看：GEH小于5算合格，小于4更好，85%以上的校验点要达到这个水平，才算模型通过校验。如果某个断面GEH大于10，基本可以判定这个区域的数据或者路网结构出了问题，不只是调参数能解决的。

我实际工作中遇到最多的场景是：整体GEH都不错，但个别关键节点的GEH就是下不来。这种时候不要急着调驾驶行为参数，先回查数据——是不是这个节点的流量检测器数据和OD矩阵之间本来就有冲突？是不是这个进口道有违停、事故等异常情况没反映在模型里？先把数据问题排除掉，再谈调参。

4.2 分组校准与敏感度分析

模型校准不是拿一个全局参数调到底，而是分组、分层做。我的流程是先做全局校准，调反应时间、车头时距、速度-流量关系等宏观参数，把整体误差降下来；再分走廊校准，比如东侧干线、西侧快速路分别查验，看看是哪条走廊的系统性偏差大；最后做局部微调，针对个别高误差交叉口处理转向流量、进口道车道划分。

校准时要特别注意参数的实际意义，不能为了拟合数据而把参数调到物理上不合理。比如反应时间调到0.5秒以下，在现实交通里是不可能的安全距离；最大加速度调得过高，会让仿真里的车辆像赛车一样拥堵时频繁急加速，看起来流量对得上，实际运行特征完全不对。参数校准的目标是“在合理范围内逼近观测值”，而不是“无条件把误差降到零”。

敏感度分析也是校准的一部分。做法很简单：把OD总量上下浮动10%，看模型的行程时间、排队长度等输出变化多大。如果总量浮动10%导致延误翻倍，说明系统处于临界饱和状态，模型对需求非常敏感，这时候结论要写清楚适用范围；如果浮动10%几乎没变化，可能是路网容量冗余，或者OD分布有问题。

4.3 验证阶段要对比哪些实际数据

校准用的数据和验证用的数据必须是两批独立的。常见错误是拿同一天的同一批流量既做校准又做验证，这样只能证明模型“记住了”那天的流量，不能证明它能预测未来。正确做法是：用某周的检测器数据标定模型参数，再用另一周、或者另一个不参与校准的时段数据去验证模型输出。

除了断面流量，验证阶段还应该对比行程时间。Aimsun里可以自由流车速和实际行程时间计算往返路径行程时间，拿这些数据和浮动车实测行程时间对比，看模型里走完某条走廊要多久。排队长度也是一个重要验证指标，特别是饱和交叉口。如果你模型里某个交叉口的平均排队长度是150米，现场实测是300米，即便流量对上了，模型也没校准好。

把校准和验证当成一个“闭环”：数据分析发现问题，修正数据或模型，再验证，直到输出合理。绝对不要一跑完就急着出结论图表——我在项目里见过太多因为跳过验证，最后被评审专家一眼看穿模型失真的情况。

5. 仿真输出数据怎么读：从指标到瓶颈诊断

5.1 Aimsun结果数据体系概览

Aimsun跑完仿真后会输出海量数据，但并不是所有数据都有用，先搞清楚每一类数据解决什么问题，再下手处理，才不会迷失在Excel的海洋里。

常用结果数据包括：路段流量、密度、平均速度、行程时间、延误、排队长度、停车次数、公交等待时间、排放和油耗。路段流量和平均速度是基础，密度能反映服务水平，延误直接对应路口运行效益，排队长度决定是否溢出到上游，排放则用于环境评估。还有一类是路径层面的指标，比如按OD对统计的路径行程时间、路径流量和路径平均速度，适合做走廊级分析。

我拿到一批仿真结果后，不会直接看汇总表，而是先看空间分布图。把路网的密度或速度用色阶画出来，一眼就能看到哪里红、哪里绿——红的地方就是潜在瓶颈，再去对应的路段和交叉口调详细数据定位原因。如果一开始就埋头看表格，很容易被平均数糊弄过去。

5.2 识别排队与溢出的分析套路

瓶颈识别的关键指标是排队长度、密度和速度的组合。单纯看流量会骗人：一条路段流量不大，但速度很低，说明这里不是流量大造成的拥堵，而是下游交叉口排队回溢，或者车道缩减、临时施工引起的瓶颈。

我习惯按三步定位问题。第一步看网络层面的速度/密度热图，找出“红色区域”。第二步看红色区域里的交叉口和路段，调出每个进口道的排队长度，判断是哪个流向的车辆堵住了。比如一个十字路口，东进口排队特别长，但西进口很畅通，可能是东进口直行和左转流量冲突大，或者放行时间分配不合理。第三步检查上游路段，如果排队长度接近甚至超过路段长度，就说明产生了溢出，车辆堵到了上游交叉口，问题已经从单点扩展成区域连锁反应。

排队溢出在Aimsun里不好直接“看”，我是通过设置队列检测器（queue detector)统计排队长度和持续时间，再结合路段密度判断。如果一条路段的密度持续接近饱和密度且时间很长，而上游路段也在同步拥堵，基本可以判定发生了溢出。

5.3 方案比选时别被平均数骗了

做方案比选最容易犯的错误，就是只拿“平均延误”一个数来定方案。平均延误是单点指标，它把每辆车的延误拉平，掩盖了极端劣化。比如某方案把平均延误从80秒降到60秒，看起来很漂亮，但可能95分位的排队从100米涨到500米，导致溢出风险大增——这种方案实际运行一塌糊涂。

我的做法是同时看四类指标：平均延误、95分位排队长度、溢出发生次数和持续时间、公交行程时间波动。前两类反映总体效益和极端状况，第三类反映系统稳定性，第四类反映对弱势交通方式的影响。方案比选的结论至少要给出效益和风险两个维度，不能只报喜不报忧。

还有一点，结果是多个随机种子的平均，不要拿单次仿真输出当结论。Aimsun的微观仿真带随机性，同一个方案换随机种子跑出来的数据会有波动。规范做法是每个场景跑至少5到10个随机种子，取均值、方差和置信区间，再对比方案。项目紧的话最少也要跑3个，否则方案之间的差异可能被随机噪声淹没。

6. 我踩过的数据坑，和现在养成的处理习惯

6.1 五个典型的“数据坑”案例

做Aimsun数据分析这么久，我踩过的坑可以列一长串，挑五个最有代表性的说说。

第一个是车道数弄错导致容量失真。某次项目里，电子地图显示某路段双向六车道，现场实际上是双向四车道加两条路侧停车带。模型按六车道建，通行能力高出一大截，怎么校核流量都对不上。后来拿着航拍图重新数了一遍才修正。从那以后我定了一条规矩：任何路段的车道数，必须有航拍或现场记录做二次确认，不轻信单一来源。

第二个是单位口径混用。之前提到过，流量单位veh/h和pcu/h一旦混用，模型整体就歪了。我吃过一次亏以后，在数据录入表的每一列都标注单位，并且项目开始时统一做一次单位换算检查。

第三个是信号配时输错相位。有一次把两个相位的黄灯时间漏了，模型里损失了黄灯清空时间，交叉口通行能力莫名下降，延误比实测大很多。排查了半天发现是对照表里漏了行。现在我对信号数据要做“双重录入验证”——两个人分别录入，再自动比对。

第四个是仿真时长不够。模型设置跑1小时仿真，但没有设置充填时间（warm-up），路网从空载开始跑，前30分钟都处于“填路”状态，后面的数据根本不稳定。后来我统一设置至少15-30分钟的加载期，加载期的数据不计入统计，才算解决问题。

第五个是随机种子跑太少。有一阵子为了省时间，每个方案只跑两次取平均，结果方案的延误波动巨大，连排序都定不下来。后来项目评审被专家问了随机性处理，才老老实实把种子数提到8个，结论一下就稳了。

6.2 我现在做Aimsun数据分析的固定流程

踩了足够多的坑之后，我给自己定了一套固定的数据分析流程，现在分享出来，可以直接抄作业。

第一步，建数据清单。项目一开始就建立一张总表，列出所有数据的名称、来源、时间、格式、负责人、状态，后面每次开会对进度都能快速对齐。第二步，做单位与坐标核验。所有几何坐标统一到一个投影系，所有流量单位统一到pcu/h，所有时间戳统一到同一时区，列一个“单位换算表”贴在项目文档首页。第三步，数据清洗与时段划分。把异常值、节假日、雨天数据筛掉，确定模型要模拟的典型时段。第四步，制作输入文件模板。信号配时表、检测器流量表、OD反推约束表都做成固定格式，减少手工录入错误。第五步，分阶段校准验证。按“全局—走廊—局部”的层次调，用独立数据做验证，所有校准结果记录在案。第六步，多场景多种子运行并统一导出结果，形成标准化的指标对比报表。

这套流程不一定是最快的，但能保证每个项目的数据底板是干净的。数据底板干净了，模型输出才有讨论价值。

6.3 给刚入门的朋友几句实在话

如果你是刚接触Aimsun交通数据分析的新人，我建议先放下好奇心和炫技冲动，老老实实做好两件事：读数据和画图。读数据不是看平均值，而是看趋势、看波动、看异常；画图不是做汇报，而是让空间分布告诉你问题在哪儿。Aimsun这种专业软件，操作层面的东西学起来很快，真正拉开差距的是你对交通数据本身的理解、以及对模型的判断力。

再补一句，别迷信仿真结果的“精确”。仿真模型是对复杂现实的简化，它的价值不是给你一个精确数，而是给你一个可以对比的“如果怎样、就会怎样”的工具。数据分析的目标是让这个工具的底数尽量可靠，判断结论的方向尽量可信。

我个人现在有个执念：任何模型结论拿出来之前，先问自己一句，喂给这个模型的数据本身站得住脚吗？如果站得住，再谈方案；站不住，先回去把数据洗干净。这个习惯帮我挡掉了无数场本来会翻车的汇报，也希望它能帮你少走一段弯路。