简介：这份资源面向铁路信号、轨道交通方向的学生、工程师及ATS系统研究者，围绕ATS模式下列车运行的模拟与仿真，覆盖CATS、LATS、沙盘控制、停车场计算机联锁等核心模块，可用于理解自动列车监控系统的调度逻辑与仿真实现。压缩包共161个文件，约11.89MB，以bmp地形与界面图像、cpp/h程序源码、obj中间文件、sbr及db数据文件为主，附带可执行程序和工程配置文件，便于直接查看与二次开发。资源提供了地形图、列车运行模型、控制逻辑代码以及用户交互界面的完整实现思路，能帮助读者掌握从模拟环境构建、列车运行仿真到ATS指令响应的全流程方法。已有744人学习下载，适合作为课程设计、毕业设计或轨道交通仿真入门参考。 提到ATS模式下列车运行的模拟与仿真，很多刚接触轨道交通信号系统的朋友第一反应是：这不就是拿仿真软件把列车跑一遍、出一张运行图吗？实际做下来你会发现，ATS这三个字母背后牵扯的进路逻辑、自动调整、运行间隔计算、故障降级处理，每一项都足以让仿真结果和现场实测差出十万八千里。
这篇文章我打算把自己在ATS模式仿真上踩过的坑、总结的套路、还有从建模到出结果的完整流程都摊开来讲。不管你是在做信号系统验证、调度策略研究，还是学生阶段想搞懂ATS到底怎么控制列车，这篇都能给你一个可以直接上手的参考。先说结论：ATS模式的仿真，本质上不是“画一条列车轨迹”，而是把调度员的隐性经验翻译成机器可执行的逻辑，再验证这套逻辑在复杂线路条件下能不能跑得通、跑得稳。
1. 项目背景与整体思路：为什么把ATS模式单独拎出来做仿真
1.1 ATS在信号系统里的定位
ATS全称是Automatic Train Supervision，也就是列车自动监控系统。它在整个信号系统里属于“大脑”级别的角色，负责根据运行图、线路条件、车组状态等信息，自动或半自动地为列车安排进路、调整停站时间、控制发车时机。和ATP（列车自动防护）、ATO（列车自动运行）不同，ATS管的是“走哪条路、什么时候走、按什么节奏走”，更偏向调度层面的决策，而不是单列车的安全防护和速度控制。
我在实际项目中见过不少刚入行的同事，把ATS想成一个简单的“运行图显示工具”，觉得它无非是把时刻表变成屏幕上的线条。但真正深入到进路冲突处理、列车早晚点自动调整、折返策略选择这些细节后，才会意识到ATS是所有信号子系统里逻辑最“软化”的部分，它不像ATP那样有硬性的安全边界，反而更像一个在复杂约束下不断做优化决策的调度员。
1.2 “ATS模式”和“非ATS模式”要区别对待
为什么仿真时要单独强调“ATS模式”？因为列车在线路上的运行状态，并不总是由ATS自动控制的。在系统降级、人工干预、调试阶段等情况下，列车可能由联锁系统按固定进路方式运行，甚至由司机以受限模式人工驾驶。这些非ATS模式下，列车运行逻辑相对简单：进路排好了就发车，到站就停，按固定时间走。
但ATS模式下，整个系统变成了闭环控制：ATS采集列车位置和状态，对比运行图判断早晚点，再计算出新的发车时刻、停站时间、进路触发时机，然后通过联锁系统下发指令。这意味着仿真中任何一步——哪怕只是站停时间的一个参数写错——都会在后续列车的追踪间隔和进路占用上被放大，形成连锁反应。所以做ATS模式仿真时，必须把“系统决策”和“列车运动”两条逻辑线同时建模，这比单纯跑一个列车动力学模型要复杂得多。
1.3 仿真方案的选型考量
做ATS模式仿真，方案上通常有两条路：一条是用OpenTrack、RailSys这类商用轨道交通仿真平台，它们内置了信号系统基础模型，通过配置能把ATS调度逻辑包进去；另一条是基于自己的运营场景写一套轻量级仿真脚本，比如用Python事件驱动模拟列车的移动、进路申请、进路锁闭和释放。
我个人的经验是，商业软件在可视化、报告生成上省力不少，但如果你重点研究的是ATS本身的决策逻辑——比如早发车策略、跳停策略、备用交路切换——商业软件的黑盒模型反而会限制你的参数调整空间。很多项目做到后面，都不得不“商业软件跑场景 + 自研脚本做参数敏感性分析”两条腿走路，这个组合实测下来最稳妥。关于工具选型，后面第3部分会更详细展开。
2. 仿真环境的搭建与数据准备
2.1 线路模型与信号设备数据
ATS模式仿真的地基是线路模型。线路模型不是你画一张CAD示意图就行，而是要把信号设备平面图转化成仿真引擎能识别和处理的结构化数据。核心要素包括：站台中心里程、道岔位置及开通方向、信号机类型与坐标、轨道区段划分、坡度曲线、限速区段等。
我在建模时踩过最大的坑是轨道区段划分粒度。区段切得太大，进路解锁、列车占用的模拟精度不够，晚点传播的仿真结果会偏乐观；区段切得太小，计算量成倍上涨，而且容易在区段边界上出现不必要的占用冲突。常规做法是站内按道岔区段逐一拆分，区间按闭塞分区划分，这样既能还原进路解锁的逻辑，又不会让模型失控。
2.2 列车动力学模型与运行曲线
有了线路，还得让列车能真实地“跑起来”。列车运行仿真里，最理想的方案是用牵引计算模型算出一条精确的速度-距离曲线，再叠加信号约束和ATS指令。但ATS模式仿真里，列车并不总是按照理论最佳曲线运行——因为ATS会在列车早、晚点时间超过阈值时，要求列车调整区间运行时间，比如通过延长站停或提高区间运行速度来恢复正点。
这里我建议把列车建模分成两层：底层是动力学层，负责计算最大牵引、常用制动、惰行状态下的速度和能耗；上层是运行调整层，由ATS的决策模块决定列车在区间内采用的“运行等级”。两个层级互相联动，才能模拟出列车晚点后越追越准、或者在一个区间追回来结果在下一个区间又晚点的那种真实运营感。动力学参数越细越好，但至少要把列车长度、编组数、空载/满载重量、最高运行速度、牵引制动减速度这几个核心值定准。
2.3 ATS调度逻辑的配置
ATS调度逻辑是整块仿真中最不直观、最容易出问题的部分。它不只是一个“什么时候发车”的开关，而是一组规则集合，包括：
- 列车按运行图触发进路申请的条件（到达某个触发点、提前一定时间、或是上一列车出清后）；
- 站停时间的正晚点调整策略（早到多停、晚到少停、超过阈值则调整区间运行等级）；
- 折返策略（站前折返、站后折返、交替折返）以及折返进路的自动触发时机；
- 扣车、跳停、列车回库/出场等特殊运营操作的处理逻辑。
配置这些逻辑时，最容易忽略的是“人工干预与自动控制的回切条件”。很多仿真里，只要加了人工干预事件，ATS后续就完全不管了，这跟现场不同。实际系统中，ATS会在满足一定条件后自动恢复对列车的控制，比如人工放行后列车重新进入自动调整模式。如果仿真里不把回切条件建模进去，长时段运营场景的结果会明显偏离实际。
2.4 仿真工具选型与脚本框架
如果你打算走脚本路线，我用得最顺手的组合是Python + 事件驱动仿真框架。列车、进路、区段占用都视为事件源，ATS决策模块作为事件处理器，在特定时间点触发检查与指令下发。架构上可以简单分成三层：
- 场景层：负责解析线路数据、运行图数据和列车数据；
- 逻辑层：实现ATS调度的核心规则，包括进路触发、调整决策、冲突检测；
- 仿真引擎层：维护事件队列和仿真时钟，推进列车状态更新。
用事件驱动而不是时间片轮询，最大的优势是仿真速度快，因为系统只在事件发生的时刻处理逻辑，而不是每隔一秒就全量扫描一次所有对象。缺点是调试起来没那么直观，需要在关键事件位置打日志。这个框架搭好之后，换线路、换运行图、换ATS参数都很快，非常适合做“多工况批量跑”的场景。
3. 核心细节：ATS模式下列车运行的规则与参数
3.1 进路控制与列车自动调整
ATS模式下，进路控制的核心不是“排一条进路”，而是“在正确的时间窗口内触发一条进路，并且不能影响其他列车的运行”。仿真中，进路触发时机的敏感性非常高：触发太早，进路长时间占用，道岔和轨道区段被锁死，其他列车无法通过；触发太晚，列车运行到信号机前才收到开放信号，会因制动等待而晚点。
你可以在仿真里设置一个进路提前量参数，表示列车距离信号机还有多少米或者多少秒时ATS开始申请进路。这个参数在不同站型下差异很大：侧向过岔进路由于道岔转动需要时间，需要给更多的提前量；而直股通过进路则可以压缩提前量。我建议在仿真启动阶段用一个多小时的高频场景做参数扫描，确定不同进路类型的最优提前量范围，而不是拍脑袋给一个全局固定值。
3.2 列车运行间隔、折返与道岔侧向限速
追踪间隔是ATS模式仿真里最核心的指标之一。它决定了系统在保证安全的前提下能跑多密间隔，直接影响线路运能。仿真时，间隔不是“相邻两列车在同一点的出发时间差”这个简单值，要区分站间追踪间隔、到达间隔、发车间隔，还有折返站最棘手的到发作业间隔。
折返场景最容易出问题。举个例子，站后折返的流程是：列车到达站台→乘客下车→列车驶入折返线→换端→驶回出发站台→乘客上车。这一整套流程如果都由ATS自动触发，那么列车在折返线的停留时间、换端时间、进路办理顺序都会直接影响整个系统的折返能力。仿真里我习惯把折返流程拆成若干个带约束条件的子事件，每个子事件的时间参数从现场实测统计值里取，而不是用理论值硬套。
道岔侧向限速这块经常被忽略。初学者做仿真时喜欢给所有道岔一个统一的速度限制，但侧向通过速度其实是根据道岔号确定。比如9号道岔侧向限速30km/h，12号道岔可以到45km/h，差别在仿真结果里会直接反映到站间运行时分和进路占用时间上。这一步省了，后面出结果再修就费劲了。
3.3 ATS模式下的“通过率”怎么定义和统计
行业里很多人聊到“ATS通过率”，其实不同场景下含义完全不同。我理解你在项目中听到这个词，大概率指的是“ATS模式下仿真实验的通过率”，也就是列车能够在ATS自动控制下、按运行图完成全部作业且没有异常事件干扰的比例。这个指标在仿真验收和方案对比中非常有用，能直观反映ATS调度策略在特定场景下的稳定性和有效性。
我在项目中会这样统计：跑完一个长时段仿真后，统计所有列车中“以ATS模式全程自动完成计划作业且无冲突、无人工介入”的列车数量，除以总开行列车数，得到ATS模式通过率。这个指标和信号系统验收里的“ATS可用率”不是一回事，但作为仿真输出指标，它对评估运行图质量和ATS参数合理性特别灵敏。如果你在调试中发现自己仿真的通过率长期低于90%，大概率不是随机事件多，而是某些进路触发时机或停站调整策略没调对。
3.4 参数计算示例：追踪间隔与停站时间
拿一个简单例子说明仿真参数怎么定。假设某站站间距1200米，区间最高运行速度80km/h，列车常用制动减速度取1.0m/s²，信号系统采用准移动闭塞，目标点间距按一个常用制动距离加安全余量计算。
先算理论追踪间隔。相邻两列车在区间内追踪运行时，后车跟随前车，两者之间的最小间隔时间可以近似按“前车尾部出清目标点的时间加上后车以最高速度运行到该目标点所需的时间”来估算。简化下来，当区间长度L、最高速度vmax、制动距离Sb、安全余量Ssafe时，追踪间隔t可以用下式估算：
t ≈ (L + Sb + Ssafe) / vmax，单位换算时注意把速度从km/h转成m/s。
带入数据：vmax = 80km/h ≈ 22.2m/s，制动距离Sb = vmax²/(2×a) ≈ 22.2²/(2×1.0) ≈ 247米，加上安全余量按50米计，若L=1200米，则t ≈ (1200+247+50)/22.2 ≈ 67秒。这就是为什么很多城市地铁高峰期追踪间隔能压到90秒甚至更低，而你如果直接把安全余量设为100米，间隔就会跳到72秒左右，直接少开两对车。仿真里这种参数敏感性分析做一两次，你就知道该把精力花在哪里调优了。
4. 实操过程：从建模到出结果的完整流程
4.1 七步完成一次ATS模式仿真
我每做一个新的ATS模式仿真项目，基本是固定七步流程，分享出来供参考：
- 整理线路基础数据：拿到信号平面图、线路纵断面、道岔型号与限速表，逐项核对后录入仿真模型。
- 配置列车参数：建立车组库，包含编组数、车长、空重载重量、牵引/制动性能曲线。
- 编制开行计划与运行图：导入或生成初始运行图，标注上下行交路、折返站、出入场时刻。
- 定义ATS规则：设置进路触发策略、站停时间调整规则、早晚点阈值、折返触发逻辑。
- 运行基础场景仿真：先用平峰时段数据跑通全流程，检查模型是否有报错和明显异常。
- 场景迭代与参数标定：加入晚点扰动、高峰大客流、设备故障等场景，微调参数。
- 输出结果并统计通过率：导出列车运行图、占用图、冲突报表，计算ATS模式通过率和晚点统计。
第5步经常被赶项目的人跳过去，我强烈不建议。基础场景不跑通，所有统计指标都是不可信的；哪怕只是一个小转辙机动作时间设置错误，整个折返能力的结论都会偏。
4.2 仿真结果怎么读：运行图、占用图、冲突点
ATS模式仿真最常见的输出是列车运行图和轨道占用图。运行图看整体节奏：线条斜率表示速度，平台段表示停站，线条交错密度反映区间占用紧张程度。我拿到运行图第一件事不是看正点率，而是看线条之间有没有肉眼可见的“压迫感”——就是后车线和前车线贴得太近、几乎平行甚至交叉。这种地方大概率存在进路等待或慢行，后续要重点查。
轨道占用图则是逐区段查看哪列车什么时间占用、何时释放。我最常用的排查思路是：找占用图上的“阶梯拉平”区域，说明列车在该区段前停车等待了，然后回查该时段对应进路是否在合适的时间窗口内办理。如果占用图上出现两个不同车次号在同一区段时间上重叠，那就是建模时区段锁闭逻辑没写对，属于数据错误，不是运营问题。
4.3 典型场景：高峰发车间隔压缩与故障降级恢复
实操中很常见的场景是压缩早高峰发车间隔。基准运行图间隔是3分钟，你把它压缩到2分钟，看ATS的自动调整还能不能兜住。这个场景能暴露出很多问题，比如站台乘客上下车时间饱和、折返站能力不足、区间追踪间隔接近理论极限。仿真结果常见的情况是：平均间隔确实压下来了，但某些车站会周期性出现后车等待前车离站的情况，ATS通过率明显下降。这时候你需要调整的是发车时刻的相位偏移，让上下行列车在共用折返轨时间上错开，而不是简单地把所有列车提前。
故障降级恢复场景则是另一套玩法。模拟某区段信号故障、列车区间停车后，观察ATS如何自动调整后续列车运行。我在这个场景里重点关注“恢复策略是否导致二次拥堵”。比如一个区间被临时封锁后，ATS把所有后续列车都扣在前方站，恢复后一次性全放出去，结果几列车在区间里形成新的连环阵。更好的策略往往是让前几列车先恢复运行，后续列车错峰投入，但这个逻辑在不同线路条件下效果差异很大，必须依靠仿真来验证。
5. 常见问题与排查技巧实录
5.1 ATS模式下仿真发车不按计划走
这个几乎是每个ATS仿真的“新人礼包”。明明运行图里排好了9:00发车，仿真到9:00列车就是不动。排查思路是先看列车状态：是进路没排、信号没开放，还是列车没收到发车指令？这三种原因对应的处理逻辑完全不同。
我见过最多的原因是进路触发条件不满足——比如列车虽然到了发车时刻，但前车尚未出清下一区段，ATS按“安全间隔优先”原则推迟了发车。这种情况其实不是bug，恰恰说明仿真逻辑是对的。如果确认前车已出清、进路也排了，列车还是不走，那就要检查ATS决策模块里发车指令判断条件是否写反，或者列车状态机在“停稳-开门-关门-发车”流转中卡住了。
5.2 列车运行曲线不平滑、速度波动大
运行曲线锯齿状明显，通常不是列车动力学模型的问题，而是ATS调整指令太频繁。比如列车刚进入区间，ATS因为晚点要求提速；速度还没起来，又因为前车占用了目标区段要求减速；减完之后晚点又上来了，再提速……往复几次，曲线就成锯齿状了。
解决办法是给ATS的调整指令加“死区”和“最小执行周期”。晚点小于10秒时不做调整，调整指令至少保持15秒不变，给列车一个稳定的执行窗口。这个机制加完，曲线会平滑很多，而且仿真结果也更接近现场，因为真实ATS本来就有类似的指令滤波机制。
5.3 仿真占用图出现“幽灵占用”
所谓幽灵占用，就是占用图上显示某个区段被占用，但实际上并没有任何列车经过或停留在那里。这个问题几乎都出在区段状态机逻辑上。常见原因有三种：区段解锁条件里少判断了列车尾部出清信号；进路取消时没有正确释放途经区段；列车仿真对象在某些异常分支下被销毁但没有回调释放区段。
排查幽灵占用时，我建议打开区段状态日志，跟踪出问题区段每次状态跳变的时间戳和触发事件，基本一两个来回就能定位。这个坑对仿真结果的影响很大，因为幽灵占用会让后续列车误判前方有车而减速，导致一系列连锁晚点，最后统计出的通过率也会显得异常偏低——我就因为这个浪费过整整两周。
5.4 提高仿真通过率和可信度的几个技巧
第一，参数不要全局统一。不同车站的乘客集散量不同，停站时间应该按车站类型分别配置，而不是一个平均值打天下。第二，合理设置随机种子。多场景仿真时固定随机种子可以保证可复现性，但做方案对比时应换多种子验证索引，避免偶然性主导结论。第三，定期校准模型。如果线路有实测的区间运行时分或停站数据，定期用实测值回代模型，保证仿真参数没有漂移。
6. 结尾：一点个人体会
做ATS模式的列车运行模拟与仿真，做到最后你会发现，难的不是仿真软件怎么操作、模型怎么搭建，而是怎么把一个充满人类经验智慧的调度过程，用诚实、完整的方式翻译成机器逻辑，再用仿真结果去反哺真实运营。这个过程很磨人，但每次看到仿真里列车按调整策略自动恢复正点、通过率曲线一点点往上拉的时候，成就感也是真的。
最后分享一个小习惯：每次跑完一轮仿真，我都会把调参记录、异常事件和当时设置的随机种子一起存档，文件名带日期和工况标记。这个习惯救过我很多次，因为过一个月你再回头看，可能完全想不起当时调了哪个参数才让通过率从85%升到93%。规范的实验记录，比任何高级仿真技巧都更能帮助你把ATS模式仿真这件事真正做好。
本文还有配套的精品资源，点击获取
