交通仿真数据输入输出实战解析：以Paramics为例

1. 数据输入输出的全景认知

做交通仿真项目这几年，我用过VISSIM，也碰过TransModeler，但Paramics一直是我项目里的主力之一。尤其是做到中后期，你会有个很直观的感受：仿真软件里最能拉开效率差距的，往往不是建模画路网的手速，而是数据怎么进去、结果怎么出来。这期内容我单独把Paramics的“交通仿真数据输入与输出”拎出来聊，就是因为这个环节太容易被低估了。

Paramics的全称是Parallel Microscopic Simulator，微观交通仿真软件。听名字就知道，它擅长的是逐车模拟——每辆车有独立的加速、减速、变道逻辑，有自己的期望车速和驾驶员激进程度。但你想想，要让几千甚至上万辆车在路网里跑起来，首先得喂数据进去：路网长什么样、每条路几个车道、每个路口怎么转向控制、各个小区之间的出行需求是多少。仿真跑完之后，你又得把结果拿出来：每条link的流量、平均行程时间、排队长度、延误、停车次数。这套输入输出的组织能力，直接决定了一个项目能不能按期交付。

标题里写“交通仿真数据输入与输出”，其实覆盖了仿真工作流里最核心的两条链路：一条是“现状数据 → 输入文件 → 模型”，另一条是“模型运行 → 输出数据 → 方案评估”。我见过不少新手把精力全花在路网绘制和参数标定上，结果到了数据整理环节才发现，矩阵格式不对、输出统计没打开、重复运行的种子没设好，前期的努力全打折扣。这篇博客我就按照实际项目里的操作顺序，把Paramics的输入侧、输出侧、以及进阶的数据交换方式全部走一遍。

先放下工具本身，我给你一个整体认知框架。在一个完整的Paramics项目里，输入数据大致分四类：

输出数据则主要分三类：link/zone层面的流率统计、行程时间类指标、排队和延误类指标。往下走，我一层层拆开讲。

2. 输入侧实战：路网、矩阵与信号的三层体系

2.1 路网数据怎么进：几何、车道与连接器

Paramics里面没有像CAD那样“直接导入整个路网”的说法，它和多数微观仿真软件一样，采用的是“底图+手工描绘”的模式。你可以在建模器（Modeller）里导入DXF或图片格式的背景底图，然后在底图上画出link和node。这里有个很关键的认知：Paramics的link直译是“路段”，但它其实自带node概念。每条link有起点node和终点node，你把两条link接在一起，它们的公共node就形成了物理连接关系。

很多人第一次用的时候会栽在“link之间没有真正连接”这个问题上。Paramics判断两段路能不能通行，看的是node上的连接器（connector）。如果你只是把两条link画得首尾相接，但没让它们的几何端点完全重合到同一个node上，车辆到那儿就会“消失”或者直接报错。解决方法是画完路网后用编辑器的“合并节点”功能，确保交叉口处只有一个node，然后再到连接器窗口里检查各转向是否可用。

车道数和车道宽度的设置，我建议在输入阶段就按实测数据来，不要只凭直觉。Paramics里一条link的车道数可以分段设置，比如进口道从两车道变成三车道，你需要在相应位置打断link，然后分别设置不同段的车道属性。车道宽度会影响车辆跟车时的横向间距，但说实话，在宏观层面的方案比选里，车道宽度的敏感度没那么高，你按标准值3.5米或实测值设置就行，不用过度纠结。

区域（zone）是一个容易忽略但至关重要的输入项。Paramics里的zone代表出行起讫点，车辆从zone出发进入路网，也从路网上驶入zone“消失”。zone必须是一个闭合的多边形，而且要有一条或多条连接器把它和路网连起来。常见的错误是zone没有闭合、或多边形边界与link重叠，导致车辆生成报错。我习惯的做法是：把zone放在路网外围的支路末端，用短link接入，这样既不影响主路通行，又能让车辆有一个合理的生成和吸收位置。

输入路网数据的小技巧：把背景底图按比例缩放好再导入，不要等画完路网再调整比例。Paramics里修改整张底图的比例非常痛苦，而且容易导致link几何和底图对不上。你可以在导入DXF后先用“测量工具”量一段已知距离，确认比例是否正确，再往下画。别问我怎么知道的——我第一个项目就是底图比例差了1.2倍，整个路网的行程时间全偏了，最后只能返工。

2.2 需求矩阵的数据格式与导入细节

路网画完，接下来喂需求数据。Paramics的需求输入核心是OD矩阵，全称Origin-Destination矩阵，也就是起讫点矩阵。矩阵里的每个单元表示从某个zone到另一个zone的出行量。这个矩阵通常来自交通调查、居民出行OD调查或者宏观交通模型的输出，你拿到手里的格式大概率是Excel表格或CSV。

Paramics导入矩阵的路径不算复杂：在Modeller的菜单里打开“矩阵”（Matrix）窗口，可以通过矩阵编辑器手动录入、从CSV文件导入，也可以用矩阵浏览器（Matrix Viewer）做可视化检查。但这里容易出问题的不是“怎么导入”，而是“单位是什么”。

Paramics的矩阵默认单位是每小时车辆数，但项目里拿到的OD需求往往是“早高峰小时总量”或“某时段总量”。如果你的数据是“7:30到8:30这一个小时的总量”，那直接填进去就是对的；但如果你的数据是“15分钟的小时当量”或者“两小时总量”，就得做换算。这个换算逻辑非常简单：要是15分钟流量，乘以4换算成小时流量；要是两小时总量，除以2。实际项目里我发现，矩阵单位错误是仿真结果离谱的最常见原因之一，排查半天路网问题，结果就是数据源少乘了一个系数。

除了总量换算，矩阵还有一个时间切片的问题。Paramics支持动态矩阵，也就是说你可以在一个仿真里定义多个矩阵，每个矩阵对应一个时段。比如早高峰你定义了7:00-8:00和8:00-9:00两个矩阵，那么仿真运行到8:00时，需求会自动切换成第二个矩阵。每个矩阵需要单独设置起始时间、持续时长。注意，不同矩阵之间的切换是“瞬变”的，Paramics不会自动做过渡平滑，如果你觉得这个切换太生硬，可以自己在矩阵里多定义几个中间时段，用插值逼近真实的需求变化曲线。

再补充一个批量操作经验：多矩阵文件导入时，注意zone编号的对应关系。很多项目里不同时段的OD矩阵来自不同表格，行列顺序可能不一致。Paramics是按zone编号读取的，不是按行名读取的。所以导入前务必检查矩阵的zone顺序是否与路网一致，一个最简单的方法是把矩阵导出成文本，然后用Notepad++或Excel打开检查第一行第一列的表头编号。

2.3 信号配时与公交输入的注意点

信号控制数据是另一类高频输入。Paramics里做信号控制，可以通过信号编辑器（Signal Editor）设置定时信号（Fixed Time）或车辆感应信号（Vehicle Actuated）。定时信号就是传统的红绿黄三色配时，你需要输入信号周期、各相位绿灯时间、黄灯时间和全红时间。这里容易出错的点是相位顺序和相位定义方式。

Paramics对信号相位的描述用的是“组”（Group），每个信号控制器包含若干个信号组，每个信号组对应一组link上的信号灯。实际操作中要把交叉口的每个进口方向分配到对应的信号组，并且设置它们之间的相位关系。如果你只是做常规的四相位信号控制，可以按照“东西直行 → 东西左转 → 南北直行 → 南北左转”的相位顺序来设计。但如果你是做自适应信号优化，那就得用API来动态控制信号灯了，这个我们后面讲。

公交输入在Paramics里是通过Transit（公交）模块实现的。你可以定义公交线路、公交站点位置、发车频率和停站时长。公交数据输入时最需要注意的是站点位置的设定和停站时长。Paramics里公交停站必须设置在link编辑器的公交站点标记上，如果站点位置不对，公交容易在站台附近出现非常诡异的急刹车或变道行为。停站时长建议用实测数据，不要统一填10秒，因为不同站点的上下客时间差异挺大，统一值会导致公交行程时间失真。

输入公交线路的同时，不要忘了设置公交专用道或混行规则。Paramics支持在link属性里选择公交专用（Bus Lane）或允许公交优先（Bus Priority），配合信号优先策略能模拟BRT或公交信号优先的效果。这块如果项目里有涉及，就值得专门建一组场景对比，省得来回改输入文件。

3. 输出侧拆解：从界面指标到文件导出

3.1 核心输出指标都藏在哪里

输入做好，跑完仿真，接下来就是“看数据”。Paramics的输出能力其实很丰富，但前提是你得知道指标藏在哪里。我把它分成三类：link指标、zone指标和路径指标，分类方式也决定了你后续怎么取数。

• link层面的流量与密度：点开link属性窗口，里面有流量（Flow）、密度（Density）、平均速度（Mean Speed）、行程时间（Travel Time）等指标。这些指标是按仿真时间累计并随时间变化的，可以导出成曲线或表格。
• zone层面的进出流量：zone属性里有驶入车辆数和驶离车辆数，适合用来核对OD矩阵是否完整执行，比如你会发现某条link的总流量和矩阵的zone吸收量对不上。
• 路径层面的指标：如果你设置了路径分配（Assignment），Paramics会生成路径统计数据，包括每条路径的流量、平均行程时间和总行驶距离。路径数据对做“多个方案比选”特别有用，你可以直接看出不同路径分担的比例。

前面这些指标在Paramics自带的Unified界面（也就是Modeller里各种统计图表窗口）里都能看，但真正常用的方式其实是导出文本数据来自己做分析。比如你要给业主汇报“晚高峰东西向干道平均行程时间从改造前18分钟降到12分钟”，你不可能截个软件图就完事，你得把每个时间切片下的link行程时间导出，然后在Excel或Python里做汇总、求均值、画曲线。

3.2 用Profile与文本输出做结果归档

Paramics的早期版本里有一个非常强大的功能叫Profile（剖面分析），现在这类功能在多个版本里都有体现。你可以对某条link或某个zone定义一组统计任务，仿真结束后生成文本格式的统计报告。这个文本文件里会按时间步长列出该link的流量、密度、速度，也会统计总延误和停车次数。

我实际项目里最常用的输出套路是这样的：在仿真运行前，先把需要统计的link、zone、路径都加进统计列表，设置好统计时间间隔（比如5分钟一个统计切片），然后运行仿真，最后导出文本文件。这个文本文件可以直接用Python的pandas库读取，做平均和对比。

做方案比选时，我通常会固定随机种子，跑多个方案。Paramics的仿真提供随机数种子（Random Seed）设置，同一个种子下，车辆生成和驾驶行为随机序列是确定的，这样不同方案之间的差异就纯粹来自路网或控制方案本身的改变，而不是随机波动。这里敲个重点：做多方案对比一定要固定种子，否则结果差异可能完全来自随机性，你会被误导。如果你要做稳健性分析，那反其道而行之，同一方案下跑5到10个不同种子，取输出指标的平均值和置信区间。

3.3 排队、延误与行程时间的导出技巧

排队长度是交通仿真输出里“最复杂也最容易被误解”的指标。Paramics里排队长度有多种定义方式：按link上停车等待的车辆数算，按车辆从link起点到当前位置的距离折算成排队长度，还有按时间积分的平均排队。实际项目里我遇到过一个问题：某个关键进口道的排队长度输出值忽大忽小，后来发现因为车辆排队超过了link长度，溢流到了上游link，导致上游link也被计入排队，而原link的排队反而“清零”了。这就是排队溢出问题，也是微观仿真软件的通病。

应对方法有两个：一是把多条相邻link设置成排队统计组，合并统计；二是利用Paramics的API或文本输出里的“溢出计数”辅助判断溢流导致的排放。这里我补充一句，做信号交叉口评价时，排队指标的单位最好是“平均每周期最大排队车辆数”或“第95百分位排队长度”，不要只用平均排队长度，因为平均值会被每周期清空时刻的零排队拉低很多。你可以在Paramics里把统计间隔设置成信号周期长度，然后再提取每个周期的最大值做百分位统计，这样更贴近实际感受。

延误指标需要区分停车延误（Stopped Delay）和行程时间延误（Travel Time Delay）。前者只算车辆速度为0的时间，后者则算实际行程时间与自由流状态下行程时间之差。做信号优化项目时，行程时间延误更直观地反映车主的体感；但做排队分析和饱和度评价时，停车延误更贴合HCM方法论的框架。Paramics的文本输出里这两类延误都有，关键是导出后自己做好筛选。

4. API与外部数据交互：进阶玩家的数据通道

4.1 API到底能做什么

如果只靠软件自带界面和文本导出，你已经可以完成大部分仿真项目了。但真要说“交通仿真数据输入与输出”的进阶形态，必须聊API。Paramics API是一组C/C++接口，它允许你在仿真运行时动态读取车辆信息、修改路网属性、改变信号控制、注入新的需求。这相当于给仿真模型开了一个“外部数据通道”，让数据不仅能进、能出，还能在仿真过程中实时交互。

举个我自己做过的例子：信号优先项目里，我需要模拟公交接近交叉口时请求绿灯延长的场景。用软件自带的定时信号功能完全做不了，因为定时信号是预先设定好相位时间，它不会根据公交的实时位置改变绿时。用了API之后，我可以在每个仿真时间步里扫描公交车辆的位置，一旦公交进入距离交叉口300米的感应区，就触发信号控制逻辑，为公交所在相位延长绿灯时间。这类“车路协同”或“信号优先”的项目，没有API基本没法做。

API还有一个大用途是外部数据注入。比如你手里有一份实时路况数据，想模拟“流量波动”对路网的影响，可以通过API每隔一定时间步调整矩阵或单条link的动态需求。你甚至能做动态交通分配（DTA）类的实验，让API根据路网状态实时调整路径选择。

4.2 数据交互的常见模式

从数据输入输出的角度看，API的交互模式可以分成三类：读取、写入、双向联动。

读取模式：在仿真循环的每一步里，遍历路网中的车辆，读取每一辆车的当前link、速度、位置、目的地。这种模式适合做“仿真状态监测”，比如你想统计某条link上每辆车的燃油消耗，就需要实时读取每辆车的速度和加速度，然后根据排放模型计算。Paramics API里提供车辆列表的遍历函数，你只需要在循环里加一个统计累加器就行。

写入模式：修改仿真参数，比如实时调整信号灯状态、修改link的最大限速、关闭某条link，甚至直接改变某辆车的预期路径。这种模式适合做“事件模拟”：例如事故发生后封闭一条车道，你可以让API在仿真运行到第10分钟时把某条link的车道数从3改成2，看看路网后续怎么拥堵。

双向联动：一边读取仿真状态，一边根据读取结果做决策，再把决策写回仿真模型。这是最复杂的模式，也是最有价值的工作模式。我前面提到的公交信号优先就是典型——读取公交位置、判断是否接近交叉口、执行信号延长策略、输出延长后的信号状态。这类模式的API代码量不大，但需要你熟悉网络对象模型，知道怎么定位link、node、信号控制器和车辆。

这里提醒一下，Paramics API的开发环境通常是Visual Studio + C/C++，编译成DLL插件后在Modeller里加载运行。如果你之前没做过插件开发，建议先从“只读不写”的简单插件入手，比如每秒钟打印一次路网里的车辆数量。跑通了再逐步加复杂度。API调试很考验耐心，因为仿真运行中一旦插件崩溃，整个仿真直接中断，你连“部分结果”都拿不到，所以一定要做好日志输出和异常捕获。写完插件，先跑一个只有几十辆车的小路网验证，不要一上来就全域大路网，否则崩溃了排错会排到怀疑人生。

5. 数据输入输出的避坑清单

5.1 高频问题速查表

这部分整理一下我实际项目里遇到过的、以及身边同行踩过的高频问题，做成速查表。每一个都是朴素但真实的坑，值得收藏。

这个表里面，“固定种子”和“队列溢出”是最常见的两个坑。我建议你在项目一开始就建立统一的种子管理规则，比如“方案比选用种子100，敏感性分析用种子200-209”，这样后面写报告的时候逻辑清晰，不容易说不清数据是怎么来的。

5.2 独家经验：数据管理的工艺化

最后说一点个人经验，也是我觉得在数据输入输出这个环节最值得总结的：要像管代码一样管数据。很多仿真项目做到后面，会出现“这个矩阵是哪个版本的”“这个输出结果对应的是哪一版路网”这类混乱。交通仿真本质上是一个迭代过程——方案A改了三版路网，跑了五轮仿真，矩阵数据也调整过两轮。如果你不在每个矩阵文件、每个输出目录里做好命名和注释，最后写报告时成本会非常高。

我自己常用的做法是：每个项目建一个标准目录结构，inputs目录下按版本建子目录，比如inputs/v1.0_rural_network、inputs/v2.0_with_bus_lane；输出目录则按方案和种子命名，比如outputs/plan_A_seed100_5min_stats.csv。Paramics本身不强制你做这些事情，但这样做之后，你每次打开仿真项目，看到输入和输出文件，能立刻知道它是干什么的、对应哪一版，这对交付质量是决定性的。

另外还有一个容易被忽略的点：仿真预热（Warm-up）时间。Paramics路网刚加载时，路网上几乎没有车，输出统计如果从第0秒开始算，会包含一段“车辆逐渐填满路网”的过渡期，导致平均行程时间偏低、流量偏小。我的做法是在正式统计开始前加10到15分钟的预热时间。具体数值取决于路网规模和车辆生成分布，没有绝对标准，但你可以在预览运行里看路网流量什么时候开始趋于稳定，然后把这个时间定为预热时长。这个操作虽然简单，但对数据质量的影响非常大，尤其在做饱和度和通行能力评价时，预热时间不够会让交叉口的排队评价结果“虚低”。

写在最后的实践经验

Paramics这套软件的数据输入输出，表面上看是“填表格、点按钮、看结果”，但实际做项目时会发现，真正决定项目质量的是你对数据语义的理解。输入侧要理解每个参数背后的物理意义，输出侧要理解每个指标是怎么统计出来的。只有两头都吃透了，你才敢放心地用仿真结果去支撑方案决策。我在实际项目里最深的体会是：仿真结果对数据的“脏”非常敏感——单位没换算对、种子没固定、预热没留够，任何一个小问题都可能让结论直接站不住脚。这也是为什么我建议每个用Paramics做项目的人，都专门花一点时间，系统地整理一遍自己的输入输出流程，把它“工艺化”。这一套流程弄顺了，后面做任何项目都能又快又稳。