2. 系统架构设计:ATP/ATO/ATS/DCS子系统边界划分、冗余架构设计、车地无线通信架构、轨旁设备布置原则

各位同学,大家好。今天我们聊聊系统架构设计。说实话,这是整个项目交付中最容易“扯皮”的环节。为什么?因为边界划不清楚,后面调试就是灾难。我见过太多项目,因为ATP和ATO的接口定义模糊,最后联调时互相甩锅。

好,我们直接进入正题。

2.1 四大子系统的边界划分

轨道交通自动驾驶系统,说白了就是四个核心子系统:ATP、ATO、ATS、DCS。它们各司其职,但又紧密耦合。

2.1.1 ATP(列车自动防护)—— 安全底线

ATP是“刹车系统”,是安全核心。它的职责很简单:保证列车不超速、不追尾、不闯红灯。我个人习惯把ATP看作“最后一道防线”。

  • 核心功能:速度监督、紧急制动、车门联锁、防滑行/空转
  • 输入:轨道占用信息、信号机状态、列车位置、限速指令
  • 输出:制动指令、允许速度、列车完整性状态
⚠️ 避坑指南:我曾经在一个项目里,ATP和ATO的“允许速度”计算逻辑不一致。ATO算出来是80km/h,ATP算出来是78km/h。结果列车频繁触发紧急制动。后来发现是ATP多考虑了一个安全余量。所以,ATP的限速必须严格低于ATO的推荐速度,这个差值要明确写在接口文档里。

2.1.2 ATO(列车自动驾驶)—— 舒适与效率

ATO是“司机”,负责平稳驾驶、精准停车、节能运行。它不负责安全,安全由ATP兜底。你想想看,ATO的任务就是让乘客感觉“这司机技术不错”。

  • 核心功能:自动驾驶、精准停车(±30cm)、节能优化、站台门联动
  • 输入:ATP允许速度、运行图、站台门状态、列车载荷
  • 输出:牵引/制动指令、车门控制、巡航/惰行策略

嗯,这里要注意:ATO的牵引指令必须经过ATP的“安全过滤”。说白了,ATO说“加速”,ATP得先检查“现在加速安不安全”。

2.1.3 ATS(列车自动监控)—— 调度大脑

ATS是“调度员”,负责监视全线列车运行、调整运行图、管理进路。它不直接控制列车,但通过下发指令给联锁和ATO来间接控制。

  • 核心功能:运行图管理、进路自动设置、列车追踪、报警管理
  • 输入:列车位置、信号设备状态、运行图偏差
  • 输出:进路请求、运行调整指令、时刻表更新

我记得有一次,ATS下发了一个“跳停”指令,但ATO没有正确解析,结果列车在站台直接开门了。后来排查发现是ATS和ATO的报文格式定义不一致。所以,ATS与ATO的接口协议必须经过三方会审

2.1.4 DCS(数据传输系统)—— 神经网络

DCS是“血管和神经”,负责把ATP、ATO、ATS、联锁、轨旁设备全部连起来。它不产生数据,只搬运数据。但一旦它出问题,整个系统就瘫痪。

  • 核心功能:车地无线通信、地面骨干网络、设备接入、网络安全
  • 组成:LTE-M/5G-R基站、地面交换机、车载无线单元、网管系统
  • 关键指标:时延(<100ms)、丢包率(<0.1%)、切换成功率(>99.9%)
💡 我的经验:DCS的边界最容易模糊。很多项目把“无线覆盖”划给土建,把“核心网”划给通信,把“车载终端”划给信号。结果信号弱了,三方互相推诿。我建议:DCS必须由信号系统总包统一负责,至少负责到天线端口。

2.2 冗余架构设计

轨道交通信号系统,安全等级是SIL4。说白了,就是“不能出错”。所以冗余是必须的。常见的冗余架构有两种:2乘2取2三取二

2.2.1 2乘2取2架构

这是目前最主流的架构,尤其适用于ATP和联锁。它的原理是:两套独立的“2取2”系统互为热备。

  • 工作方式:A系和B系同时运行,但只有一系输出控制指令。如果A系故障,B系无缝接管。
  • 内部逻辑:每一系内部有两个CPU,它们互相比较计算结果。只有两个CPU结果一致,才输出有效指令。
  • 优点:安全性高(单点故障不会导致危险),可用性好(一系故障不影响运行)。

为什么会这样设计?你想想看,如果只有一个CPU,它坏了怎么办?如果有两个CPU,但只有一个输出,那输出错了怎么办?所以,2乘2取2就是“双重保险”。

🔧 实战技巧:我在项目里遇到过A系和B系“同步失败”的问题。原因是两系的时钟偏差太大。后来我们强制要求两系使用同一个GPS时钟源,问题就解决了。所以,时钟同步是冗余架构的命门

2.2.2 三取二架构

三取二架构常见于欧洲的ETCS系统,国内也有应用。它的原理是:三个CPU同时计算,输出结果进行“三取二”表决。

  • 工作方式:三个通道独立运行,输出结果送到表决器。只要有两个通道结果一致,就输出该结果。
  • 优点:容错能力强(一个通道故障,系统仍能正常工作)。
  • 缺点:维护复杂(三个通道必须完全同步),成本高。

我个人习惯:对于ATP这种安全关键系统,我更倾向于2乘2取2。为什么?因为三取二虽然容错好,但一旦出现“两个通道同时故障”,系统就完全失效了。而2乘2取2至少还有一系可以工作。

特性 2乘2取2 三取二
安全性 高(单点故障不危险) 高(单点故障不危险)
可用性 高(一系故障可降级) 高(一通道故障可降级)
维护复杂度 中等
成本 中等
典型应用 ATP、联锁 ETCS、部分车载设备

2.3 车地无线通信架构

车地无线通信,是DCS的核心。目前主流方案是LTE-M,未来是5G-R

2.3.1 LTE-M(轨道交通专用LTE)

LTE-M是4G的轨道交通定制版。它解决了传统WLAN的覆盖差、切换慢的问题。

  • 频段:1.8GHz(专用频段,不受干扰)
  • 带宽:单载波20MHz,可扩展
  • 时延:端到端<50ms(满足CBTC要求)
  • 覆盖:单基站覆盖1-2公里(隧道内需泄漏电缆)

嗯,这里要注意:LTE-M虽然叫“LTE”,但它和公网LTE不完全一样。它支持高速移动(最高500km/h),并且有QoS保障。说白了,就是给信号系统留了一条“专用车道”。

2.3.2 5G-R(未来趋势)

5G-R是5G的轨道交通版本。它比LTE-M更快、时延更低、容量更大。

  • 优势:时延<1ms(URLLC场景)、带宽>1Gbps、支持海量连接
  • 应用场景:列车视频监控实时回传、车载数据高速下载、远程驾驶
  • 挑战:覆盖成本高、终端生态不成熟、与既有LTE-M的互操作

我记得有一个项目,客户非要上5G-R。但当时5G-R的芯片还没量产,最后只能先用LTE-M顶着。所以,技术选型要务实,不要盲目追新

📡 架构建议:车地无线通信采用“双网冗余”设计。即:两套独立的LTE-M网络,分别覆盖不同的频段。如果一套网络故障,另一套自动接管。我曾经在一条地铁线上,因为一套基站的电源模块坏了,导致全线无线中断。从那以后,我坚持所有基站必须双电源、双回传。

2.4 轨旁设备布置原则

轨旁设备,包括信号机、应答器、计轴器、无线基站、站台门等。它们的布置直接影响系统性能。

2.4.1 信号机布置

  • 原则:信号机应布置在司机视线最清晰的位置。一般位于轨道右侧(中国标准)。
  • 间距:根据闭塞分区长度确定。一般不超过1.5km。
  • 防护:信号机前方应设置“预告信号机”,提前告知司机前方信号状态。

2.4.2 应答器布置

  • 用途:用于列车定位校准、点式信息传输。
  • 间距:一般每1-2公里布置一组。在站台、道岔、信号机处必须布置。
  • 安装:应答器应安装在轨道中心,距轨面高度约50mm。注意避开钢轨接头和道岔转辙机。
⚠️ 避坑指南:我曾经在一个项目里,应答器安装位置离钢轨接头太近。列车经过时,振动导致应答器松动,数据读取失败。后来我们规定:应答器距离钢轨接头至少5米

2.4.3 计轴器布置

  • 用途:检测轨道区段是否被列车占用。
  • 布置:每个闭塞分区的边界必须设置计轴器。道岔区段需要额外增加。
  • 注意事项:计轴器应远离牵引回流线,避免电磁干扰。我见过一个项目,计轴器频繁误报“占用”,最后发现是牵引电流干扰。

2.4.4 无线基站布置

  • 覆盖:隧道内采用泄漏电缆,覆盖距离约500-800米。地面段采用定向天线,覆盖距离约1-2公里。
  • 重叠:相邻基站覆盖区应有20%的重叠,保证切换不中断。
  • 安装:基站天线应高于列车顶部,避免遮挡。隧道内泄漏电缆应安装在隧道壁上方。

好了,关于系统架构设计,今天就讲到这里。记住一句话:边界清晰、冗余可靠、通信稳定、布置合理,这十六个字是项目交付的基石。下一章我们聊聊“接口设计与数据流”,那是真正考验细节的地方。