第2章：系统架构精讲——CBTC的层级结构

各位工程师朋友，咱们今天聊聊CBTC的系统架构。说实话，很多刚入行的同事一上来就被ATS、ZC、DSU、VOBC这些缩写搞晕了。我当年也一样，第一次看到系统框图时，感觉像在看天书。

但别急，咱们一层层拆开看。CBTC说白了就是一个“列车大脑+地面指挥”的分布式系统。它分四个层级：ATS、ZC、DSU、VOBC。每个层级各司其职，又紧密配合。

2.1 ATS——列车自动监控系统

ATS是系统的“眼睛”和“大脑皮层”。它负责监控全线列车运行状态，生成运行图，调度指挥。你可以把它理解成地铁控制中心的大屏幕——所有列车的位置、速度、门状态，都在上面实时显示。

我在项目中遇到过一件事：某条线路的ATS数据库突然崩溃，结果全线列车都停在原地不动。为什么？因为ATS一旦失联，ZC会默认进入降级模式，列车只能以25km/h限速运行。嗯，这里要注意：ATS不是“可有可无”的，它是整个系统的调度核心。

2.2 ZC——区域控制器

ZC是CBTC的“心脏”。它负责计算移动授权（MA），也就是告诉列车“你可以往前跑多远”。这个计算过程非常关键——它要考虑前车位置、道岔状态、线路限速、临时限速等等。

我个人习惯把ZC比作“交通警察”。它站在路口，给每辆车发通行证。但注意，ZC不是直接控制列车，它只是发指令，执行的是VOBC。

2.3 DSU——数据存储单元

DSU是系统的“记忆库”。它存什么？线路地图、列车参数、临时限速信息、版本号……说白了，所有需要持久化的数据都在DSU里。

你想想看，如果ZC重启了，它怎么知道线路长什么样？它得从DSU下载线路地图。如果VOBC重启了，它怎么知道自己的参数？也得从DSU下载。

DSU还有一个重要功能——版本管理。我记得有一次，某条线路升级了ZC软件，但DSU里的版本号没更新。结果ZC启动时发现版本不匹配，直接拒绝工作。嗯，这种低级错误其实挺常见的，大家一定要在升级流程里加上“版本校验”这一步。

子系统	存储内容	更新频率
DSU	线路地图、列车参数、临时限速	按需更新
ZC	移动授权、区域状态	实时（200ms周期）
VOBC	列车位置、速度、门状态	实时（100ms周期）

2.4 VOBC——车载控制器

VOBC是列车的“大脑”。它装在车上，负责测速、定位、执行ATP/ATO功能。说白了，ZC告诉它“你可以跑到下一站”，VOBC就自己算怎么加速、怎么减速、怎么停车。

VOBC的核心是“安全计算机”。它通常采用“二取二”或“三取二”架构——两个或三个CPU同时计算，结果一致才输出。为什么这么搞？因为一旦VOBC算错，列车可能闯红灯、追尾、超速……后果不堪设想。

2.5 各子系统功能边界

搞清楚了每个子系统做什么，还得知道它们之间的“边界”在哪里。说白了，就是“谁该干什么，谁不该干什么”。

• ATS vs ZC：ATS管调度，ZC管安全。ATS可以建议“让这列车快跑”，但ZC有权拒绝——如果安全条件不满足，ZC就不给MA。
• ZC vs VOBC：ZC管“能跑多远”，VOBC管“怎么跑”。ZC给目标点，VOBC自己算速度曲线。
• DSU vs 其他：DSU只管存数据，不参与实时控制。所有实时决策都在ZC和VOBC里完成。

我建议大家在设计接口时，一定要把边界划清楚。我曾经见过一个项目，ATS直接给VOBC发“紧急制动”指令——这明显越界了。紧急制动应该由ZC或VOBC自己判断，ATS没有这个权限。

2.6 系统接口定义

接口是CBTC的“血管”。数据怎么传？用什么协议？周期多长？这些都得定义清楚。

常见的接口类型有：

• ATS-ZC接口：采用TCP/IP，周期500ms。ATS发调度指令，ZC回报状态。
• ZC-VOBC接口：采用无线通信（WLAN或LTE），周期200ms。ZC发MA，VOBC回报位置。
• VOBC-DSU接口：采用文件传输协议，只在列车启动时使用。VOBC下载线路地图和参数。

嗯，这里还要提一句：接口测试是CBTC调试中最容易出问题的环节。我见过太多因为接口定义不清晰导致的联调失败。比如ATS发的“列车ID”是字符串，但ZC期望的是整数——这种低级错误，一旦上线就是事故。

好了，这一章的内容就到这儿。下一章咱们聊聊“移动授权计算”——这可是CBTC的核心算法，也是面试必考题。到时候我会拿一个真实案例来拆解，保证让你听完就能上手。