做交通仿真的兄弟应该都有体会一套模型跑得好不好三分之一靠建模三分之一靠标定剩下三分之一其实是数据在兜底。之前几讲我们把路网、车辆行为、OD需求、信号控制分别拆开讲了一轮这一讲我把它们收拢到一条主线上专门聊 Paramics 的交通仿真数据输入与输出。项目名称里写着“交通仿真软件Paramics13”这第13讲不讲花哨的界面功能就讲数据怎么进去、怎么出来、怎么保证它没进错、出对。很多人拿到 Paramics 的第一反应是画路网、拖连接器觉得把路画出来就是仿真。实际上一开始就把数据输入输出框架理清楚后面会少折腾非常多。输入数据决定了模型能表达什么交通场景你给模型一个城市路网的几何它就能算路径你给一组 OD 矩阵它就能生成车辆并分配路径你给信号方案它才能还原交叉口的启停。没有这些输入Paramics 只是一个三维动画播放器。输出数据则决定了仿真结果能告诉我们什么路网跑完之后不仅仅是看小汽车动画完不完整更重要的是行程时间、延误、排队长度、流量、排放这些量化指标。这一讲适合刚接触 Paramics 的交通工程师、研究生也适合用了但不清楚输入输出机制、结果经常解释不清的同行。1. 数据流这条线先替大家捋一遍1.1 输入输出在Paramics里到底指什么在 Paramics 的语境里输入并不只是“把 OD 矩阵填进去”这么一件事。我习惯把输入分成三层。第一层是路网结构层包括道路中心线、车道数、连接器connector、交叉口转向关系、限制通行方向等。它是所有仿真的骨架。第二层是交通需求层包括不同时段的 OD 矩阵、车辆类型、流量构成比如小车、公交、货车比例、出发时间分布等。需求数据决定了“有多少车、从哪来、往哪去”。第三层是运行管理层包括信号配时、让行规则、公交线路、专用道、事件、施工区、检测器、可变信息标志等。这些输入作用在路网上让模型里的交通流响应真实世界的控制策略。有同行经常把第二层输入简单理解成“画个东西上去跑一跑”。但我们实际做项目时输入数据的来源非常杂OD 可能来自手机信令、牌照识别、问卷调查、线圈流量反推路网可能来自 OpenStreetMap、GIS 数据、CAD 设计图纸信号配时可能来自设计文件或交警记录。所以 Paramics 数据输入的第一问题不是软件操作问题而是数据格式转换问题。你手里可能有十几种格式的数据但它们要统一成 Paramics 能认的坐标系、单位、字段结构这一步才最耗时间。1.2 一次典型仿真项目的数据生命周期一个典型仿真项目的数据流大致经历六个环节基础数据采集、数据清洗与处理、数据转换与加载、模型标定与校核、仿真运行与情景设计、输出结果分析与可视化。每个环节都会产生中间数据而且越往后错误越难定位。很多人在最后一步发现结果异常回头查了半天才发现是最开始坐标系差了零点几公里这种教训我见得太多。我举个例子。你拿到一张 CAD 底图先在绘图软件里把道路边线、中线整理好输出 DXF然后导入 Paramics 作为背景在此基础上重新描路网这是第一步。第二步把调查 OD 做成一个矩阵文件矩阵里的每格对应起始小区和终点小区之间的需求量。第三步把信号周期、相位、绿信比做成控制方案配置到交叉口。第四步跑一段小时仿真用通行量、行程时间对比实测流量做标定没标住就回头改需求矩阵或路径选择模型参数。第五步跑方案比选输出结果。这整个链条里任何一步的数据口径不一致结果就解释不了。所以这一讲实际上是希望大家建立一种“数据流意识”从输入到输出的每一步都要问自己三个问题——数据从哪里来格式是什么统计口径是什么只要这三问能答清楚Paramics 就不难。后面实操部分我也会用同一个案例反复强调这一点。2. 输入数据准备源头没做对后面全是白费2.1 路网几何数据CAD、GIS与Paramics之间的语言转换路网数据是最基础也是最容易被低估的输入。很多人觉得路网输入就是“照着底图画线”其实画线背后有一堆几何细节会直接影响仿真连接器长度、车道数变化点、停车线位置、转向半径、坡度、控制区范围等。Paramics 是用节点和连接器表达路网的节点代表交叉口或路网边界连接器代表道路实际是一条由多个点组成的曲线带有车道属性。你画得越粗糙后续车辆换道、排队、转弯的行为就越失真。从 CAD 图纸导入时通常做法是把设计图纸中的道路中心线提取出来清理掉多余线层只保留几何与坐标信息然后在 Paramics 里设置背景图并校准比例尺与坐标原点。这里最关键的坑是坐标系。很多图纸采用了不同的坐标系或偏移量如果不校准路网会整体偏移甚至比例变形。用 GIS 数据时也要注意投影坐标系统一我用过的做法是先统一到同一个 UTM 坐标带再导入这样后续与实测 GPS 轨迹对齐也会方便。画路网时别偷懒每条路至少要有“两段连接器”的意识进口道和出口道。Paramics 中连接器的车道属性包括车道数、车道转向是否允许都会直接影响车辆换道行为和排队。实际项目中经常出现“路网看起来对但交叉口排队不真实”十有八九是连接器长度或车道属性没匹配实际。比如一个路口进口道只有 30 米却在 Paramics 里画了 100 米排队蓄车能力就被高估延误计算自然偏小。2.2 OD需求矩阵从调查数据到可加载的矩阵OD 矩阵是交通仿真的灵魂。在 Paramics 里需求通常以矩阵形式加载横轴是出发小区纵轴是到达小区中间数值是每小时或时段内的车辆数。矩阵可以分时段比如早高峰一小时一个矩阵平峰一小时一个矩阵也可以分车种比如小汽车矩阵、货车矩阵、公交矩阵分开设置后面再加总。这里我要强调一个容易混淆的概念OD 矩阵不是流量。OD 矩阵表示的是出行需求也就是“人们想从 A 到 B”的意愿真正路网上的断面流量是需求经过路径选择、容量限制之后的实际结果。初学者经常直接把调查得到的高峰小时流量当成 OD 矩阵填进去跑出来的流量往往偏大因为真实 OD 是起点到终点不是某一条路径上的观测流量。正确做法是用起点终点调查数据构建 OD或者用“流量反推 OD”工具。Paramics 本身也提供矩阵估计相关功能可以结合实测流量对 OD 进行校准。矩阵的粒度和精度也值得展开。一个城市级的仿真项目小区划分太粗路网加载到中间片区就很难精确划分太细矩阵稀疏、标定量大而且很多小区间交通量本来就是估计的反而增加噪声。实际使用中小区一般按主要的交通中区和 OD 调查习惯来划内部道路可以通过区域出入口连接器表达。矩阵时段建议和信号控制方案对应比如早高峰 7:30—8:30晚高峰 17:30—18:30并预留 15 分钟加载期。这样跑出来的流量曲线才和现实早晚高峰形状吻合。2.3 信号控制与事件输入管理型数据的加载方式交通需求有了路网有了但这只能算“自由流环境”。真实路口有信号灯、让行标志、公交专用道、临时的施工管制。Paramics 中信号控制方案属于独立的输入数据包括周期长度、相位顺序、各相位绿信比、黄灯时间、全红时间也可以定义协调控制的相位差。你可以把一套信号配时保存成一个方案文件在多套方案之间快速切换。信号输入这块我踩过最大的坑是相位顺序。画好交叉口后信号配时软件里看是东西直行、东西左转、南北直行、南北左转Paramics 里的相位排序必须和实际相位图完全一致否则会出现冲突放行或空放。举个例子如果实际先放东西左转但软件里设置成先放东西直行仿真里就会看到两股转向车流同时进入交叉口然后互相干扰结果和现实完全对不上。此外许多模型里信号配时用的是绿灯时间而不是有效绿灯时间如果直接拿信号配时表一字不改地输进去会导致仿真延误偏小或偏大。标定时需要按实际饱和流率换算有效绿灯。除了信号灯管理型输入还包括公交线路与站点、发车间隔、停车/让行控制、事件和应急车道关闭。这些数据通常不是一次到位而是随着方案情景变化而变化。我的建议是所有管理数据单独保存成可复用文件不要和路网长期绑死这样改方案时切换数据更方便也便于追踪版本。比如今天测试“信号优化方案”只需要替换信号方案文件其他输入不动就能快速对比。3. 输出数据解析原始仿真结果如何变成决策依据3.1 标准报表的核心指标与统计口径仿真跑完Paramics 不会只给你一段动画它会把路网上每个节点、连接器、检测器、OD 对小区的运行指标汇总成报表。常见的输出指标包括流量通过某断面的车辆数通常按小时或仿真时段累计行程时间车辆从起点到终点或通过指定路段的平均时间平均速度连接器或路线的平均行程速度排队长度交叉口进口道的平均排队或最大排队延误实际行程时间减去自由流行程时间后的差值停车次数、占有率等。这些指标可以从网络小区层面按 OD 对统计也可以按指定断面统计。统计口径是我特别想提醒的。同一指标在不同软件或不同版本里定义可能不一样。比如“排队长度”有的取时间平均有的取空间平均有的只算停车线前停车排队有的算整个连接器上车辆时距被压缩的队列。如果一份报告里不写清楚口径横向对比就完全失真。所以我在每次输出报表后会优先检查 Paramics 帮助文档里的指标定义再对标数据。尤其是延误一定要确认是“停车延误”还是“总延误”前后差的可能是十几秒。3.2 车辆轨迹、检测器与断面数据的价值除了标准报表Paramics 还可以输出车辆轨迹数据。轨迹是每一辆车在每个时间点的位置、速度、加速度相当于把整个路网内的车辆级微观行为都记录下来。轨迹数据特别有用做拥堵溯源时可以看哪一段形成瓶颈做排放模型时需要逐秒的加减速参数做自动驾驶或网联车仿真时也要在轨迹级接口上做控制逻辑。如果你想找“为什么这个路段总是突然慢下来”看轨迹比看聚合指标直观得多。检测器是另一个重要输出通道。在路网上设置虚拟线圈或断面检测器仿真的每一秒都会统计数据比如流量、时间占有率、速度并且可以按一定间隔导出。检测器数据可以和实际路侧设备数据做对比用来校核模型比仅仅依赖网络聚合指标更精细。实际项目中我会在每一个关键进口道和干道中间布上虚拟检测器用来输出 5 分钟粒度数据和真实线圈流量做散点图比对。不过轨迹数据和检测器高频输出会产生非常大的文件量。一个中大型路网跑一小时轨迹文件可能几个 GB 起步。所以我一般建议全路网轨迹只在需要专项分析时开常规方案比选开网络级报告和关键断面检测器就够了否则硬盘和读取时间都受不了。曾经有个项目最后输出数据接近 20GB电脑直接卡死后来改成“只有重点路段输出轨迹”后才解决。3.3 二次开发输出用API拿到想要的数据Paramics 提供了 API 接口允许用户通过外部程序在仿真运行中实时读取和设置数据。这个功能对做复杂项目的人来说几乎是必需品。你可以在 API 里读取某一辆车的坐标、速度、所在连接器也可以修改信号配时、改变需求矩阵或触发事件从而做动态交互仿真。输出侧最常用的是写自定义 CSV 或 Excel 报告按自定义条件统计。比如我可以只统计 7:30 到 8:30 之间每 5 分钟的进口道平均排队并把对应时间段的信号相位同时记录下来。我自己的一个典型场景是批量跑十个方案每个方案重复五次取均值同时从 API 里把每 5 分钟的交叉口平均排队长度和总延误写入数据库后面用 Python 做对比图。如果没有 API一个人工导出再手动整理效率非常低。所以要提前设计好输出文件的结构明确哪些字段是主键、哪些是变量防止不同方案的数据混在一起。文件命名也要规范比如“case_01_seed_03_link_01.csv”不然跑完一周你自己都分不清哪个文件是哪套方案的。除了结构化数据输出侧的另一个需求是可视化。交通仿真最终是为项目决策服务所以我通常会用 Python 读取 CSV 后画箱线图或柱状图也会把输出结果映射到 GIS 或直接用热力图层叠在地图上。看输出数据时图形化表达往往比一堆数字更容易发现问题比如某路段流量突然从 800 掉到 200很可能是路径选择参数或者连接器方向设置有问题。4. 实操一个路口级案例的输入输出全流程4.1 案例背景与输入文件准备为了把前面这些内容串起来我拿一个典型城市十字路口及周边 400 米范围的小型路网做样例。假设这个路口是东西向主干道和南北向次干道的交叉西进口有双左转加直行东进口有一个直行加专用左转南北进口各有一个直行车道和一个左转车道。我们要比较现状信号方案和优化信号方案所以需要准备两套信号数据。输入文件准备分三步。第一步在 CAD 里把道路中心线和边界线转到 DXF背景图导入 Paramics 后校准原点。第二步建立四个 OD 小区A西、B东、C北、D南用调查得到的高峰小时 OD 填入矩阵。第三步录入信号控制。现状方案周期 90 秒东西直行 35 秒、东西左转 15 秒、南北直行 25 秒、南北左转 10 秒黄灯 3 秒、全红 2 秒。OD 矩阵可以形成一个简单表格起点/终点ABCDA0620180150B5800130140C160120090D130170800这个矩阵的含义是每小时从西侧小区 A 出发到东侧 B 有 620 辆从 B 到 A 有 580 辆等等。注意这是需求不是每个进口道的观测流量。也就是说A 到 B 的 620 辆车可以选择多条路径虽然在这个小案例里主要路径就是一条直行但原理上依然要靠路径选择模型去分配。4.2 模型参数设置与仿真运行在 Paramics 中加载路网和矩阵后还需要设置一批运行参数仿真时长、随机种子、时间步长、车辆类型比例、路径选择模型参数等。通常仿真要跑“15 分钟加载 60 分钟统计 5 分钟清空”。为什么这样设置因为模型刚启动时路网是空的前 15 分钟车辆逐步释放数据没有代表性统计期要取稳定后的一小时。清空阶段是为了让已经进入路网的车辆全部离开方便统计完整行程。随机种子决定了随机数序列一个方案跑 5 个不同种子取平均可以降低随机波动。有些初学者只跑一次看到结果觉得很稳定但换一个种子后可能延误差出 20%这就是随机性在起作用。微观仿真的本质是随机过程单次运行只能算一个样本方案比选时必须做多次重复试验。我习惯在正式运行前先做一遍“快速检查运行”把时长设成 10 分钟观察路网有没有车辆卡死、信号相位是否对应、有没有断头或连接器方向错误。确认无误后再正式运行 60 分钟统计期。正式运行结束后导出交叉口的流量、平均延误、平均排队长度、行程时间报表。这里我也会检查一下车辆总数是否和 OD 矩阵输入总和一致有差异说明矩阵加载或路径分配有问题。4.3 输出指标整理与比选方案把现状方案结果导出到 CSV 之后我一般会做一个数据透视表。比如对比维度现状方案优化方案西进口平均延误(s)68.242.5东进口平均排队(m)11276南北向行程时间(s)9588路网总延误(veh-h)22.818.4这个表看起来简单但背后要对统计口径做统一。比如延误是仅指停车延误还是包括减速延误排队是最大排队还是平均排队我会在结果表中注明口径避免方案比选时被挑战。尤其要把“优化方案”的来源写清楚是提高了东西向绿信比还是加了协调相位差只写结论不写依据报告很难站得住脚。方案比选不仅仅是看延误降低多少还要关注是否把问题转移到了另一条路。比如优化东西向信号延长时间南北进口延误可能上升。所以输出数据至少覆盖所有方向的进出口道不要只看一个方向。如果只盯一个方向很容易做出“局部优化、整体恶化”的方案。我见过有的项目只提供主干道延误避开次干道恶化数据这种报告后期往往很难通过评审。5. 常见问题与排查技巧实录5.1 输入阶段最容易踩的坑常见问题一OD 矩阵总和比路网观测流量小很多模型跑出来流量偏低。原因往往是矩阵只包含外部进出交通忽略了内部穿越小区的穿越交通或者有些 OD 对缺失。解决办法是检查矩阵行列和观测断面流量尤其是边界路段。如果 A 到 B 有 620 辆但实际路径上的检测器流量只有 400说明有部分需求走了别的路径这是合理的但如果所有断面都偏低就要回头补矩阵。常见问题二导入 CAD 底图后路网位置对不上。这基本是坐标系没有校准或底图单位是英尺但模型设成了米。建议在导入后先在路网上放一个已知坐标的标记点用距离工具验证比例尺误差大于 1 米就不要继续。别以为差一米没什么交叉口间距的三维动画可能看起来像车祸现场。常见问题三连接器车道属性与地面标线不一致导致车辆频繁变道或无法转向。这个需要在实际路网中逐个交叉口核对转向箭头可以用背景图叠加检查。特别是新增拓宽路口如果连接器画了 3 条直行车道但地面只有 2 条直行仿真里就会出现车辆挤在一起却排队不真实的怪相。信号配时的相位顺序错误确实非常常见。我在实际操作中会把每个相位的放行方向和允许转向列一个表再和 Paramics 相位配置面板一项项核对避免凭记忆。尤其是有专用左转和直行同时放行的情况相位列表里必须严格区分。5.2 运行阶段数据异常排查运行中如果发现某些路段流量始终为 0先检查该连接器是否被禁行标志或连接器方向设置错误如果排队长度一直顶到上游交叉口除了分析真实溢出还要看连接器长度是否设置得过短。现实里 200 米排队长度不等于 50 米连接器内平均排队模型里的物理空间长度要和实际匹配否则蓄车能力会失真。模型卡死或车辆消失可以打开动画跟踪一辆车看它在哪一步路径选择失败比盲猜参数高效得多。有个现象是仿真结果每次都不一样觉得很奇怪。这不是 bug微观仿真带有随机性。原因包括随机种子、车辆生成时段的随机性、路径选择随机项。我们做方案比选时至少用多个随机种子跑重复试验并检查均值和标准差。如果差异过大说明模型对随机参数敏感要检查路径选择参数是否标定到位。我曾经遇到一个路口模型延误标准差达到 30 秒后来发现是随机种子变化导致车辆生成分布差异大调整矩阵释放规则后才稳定。还有一种情况是输出数据出现“跳变”比如某 5 分钟流量突增 500 辆。这通常是车辆在一条连接器上批量释放造成的而不是现实拥堵波。检查矩阵是否设置了不合理的到达分布或者是否把高需求时段压缩到了过短区间。流量曲线应该平滑渐变不应该出现锯齿状突变。5.3 输出结果可信度的快速检验清单我在交付报告前会过一遍检验清单也推荐大家养成这个习惯路网总 OD 加载量是否与输入矩阵一致偏差小于一定阈值。关键断面仿真流量与实测流量的误差是否在可接受范围内比如 10% 以内。排队长度和延误是否在合理量级没有异常大或异常小。自由流路段速度是否接近限速没有出现莫名低速。方案比选中至少有一个方案的结果和直观交通认知一致。随机种子重复试验的方差是否可接受。如果这些检查不过我不会直接输出报告而是回退到输入数据、标定参数、输出口径再次排查。数据输入输出不是一锤子买卖而是要反复迭代的闭环。每一次发现结果不可信都要先怀疑数据链路再从模型参数找原因这个顺序不能反。我在实际项目中还有一个习惯每次交付前把输出结果的元数据也一并写清楚包括仿真日期、软件版本、随机种子、统计时段、坐标系、矩阵来源。这样别人拿到报告能明白这些数字是在什么条件下产生的。别觉得这是形式主义项目验收时这些信息能省去大量解释成本。最后说一点个人体会。我做了多年仿真项目最大的教训就是别把“仿真输出的数字”直接当成“真相”。Paramics 只是一个计算工具输入数据质量、统计口径、模型参数共同决定输出的可信度。数据从哪来统计了什么模型怎么表达这三点理不顺再漂亮的动画也只是动画。养成“数据流审计”的习惯每跑一个方案都问自己一句——这些数据从哪来它到底统计了什么这会帮你少走很多弯路。下一讲如果有机会我可以继续聊聊 Paramics 的 API 二次开发把输出数据做到更极致的自动化和定制化。这一讲先到这实操中去体会数据的魔力吧。