2. 从CBTC到FAO的演进逻辑

要理解FAO（全自动运行）为什么不是"另一个信号系统"，而必须回到CBTC（基于通信的列车控制）这条技术主线来看。CBTC解决的核心问题是"车—地之间连续、双向、大容量的信息交互"，它把传统基于轨道电路的固定闭塞，变成了以列车精确定位为基础的移动闭塞。FAO则是在这套已经具备连续通信与精确控车能力的基础上，把原本由司机承担的那部分职责，系统地转移到地面与车载的自动化功能上。因此，本节的重点不是罗列两套系统的功能清单，而是看清"哪些能力CBTC已经具备、哪些是FAO新增的、新增能力又对协同提出了什么要求"。

CBTC的基本组成与职责边界

典型的CBTC系统可以按"控制闭环"来理解，由四个层次构成：

• 车载ATP/ATO：ATP负责超速防护、移动授权接收与安全制动；ATO负责在ATP保护下按运行计划牵引与制动。列车定位（应答器校正+测速测距）是车载侧的关键输入。
• 地面ATP（区域控制器ZC）：根据联锁提供的进路状态、前方列车位置，为每列车计算移动授权（MA），是移动闭塞的核心计算单元。
• 联锁（CI）：负责道岔、信号机、计轴/轨道区段的安全联锁逻辑，向ZC提供进路与区段占用信息。
• ATS（列车自动监控）：负责运行图、进路自动触发、列车调整与人工监控，是"运营层"的指挥中枢。

再加上数据通信系统（DCS，通常为骨干环网+车地无线）作为承载，这五部分构成CBTC的最小完整闭环。需要强调的是，CBTC的自动化程度止步于"自动驾驶（GoA2）"：列车能自动运行、自动停车，但开关车门、处理障碍物、应对火灾与紧急事件、以及发车前的整备确认，仍由司机承担。这条职责边界，正是FAO的起点。

FAO新增的不是"更快的车"，而是"被接管的人"

把司机职责逐项拆开，就能看清FAO的功能增量。以GoA4（无人值守全自动运行）为目标，新增能力大致落在四类：

1. 车门与站台的自动协同：车门/站台门联动控制、间隙探测（激光或红外）、障碍物检测与再开闭逻辑，替代司机瞭望确认。
2. 列车唤醒与休眠：每日运营前自动上电、自检、静态测试、出库；运营结束后自动回库、断电。这要求车辆与信号、通信、供电、车库门禁深度联动。
3. 障碍物与脱轨检测、火灾报警联动：车载或轨旁感知触发紧急制动，并自动向OCC（控制中心）上报位置与状态。
4. 远程控制与后备降级：OCC设置远程控制台，可在故障时远程驾驶、远程复位、远程开关车门；同时保留降级到GoA2甚至人工驾驶的路径。

可以看到，FAO的增量大多不在"控车"本身，而在"感知—判断—联动"。这也解释了为什么FAO项目里，车辆、信号、通信、站台门、供电、综合监控（ISCS）的接口数量会显著多于同规模CBTC项目。

演进逻辑：从"控制闭环"到"运营闭环"

下面的图把CBTC与FAO放在同一张图上对比：CBTC闭合的是"位置—授权—控车"的控制环；FAO在此基础上，把车门/站台门、唤醒休眠、障碍物感知、远程控制接入，形成一个覆盖"整备—运行—应急处置—回库"的运营环。

协同需求：接口即安全边界

从图右侧可以看到，FAO把原本集中在司机身上的职责分散到了多个子系统，这就必然产生大量跨系统接口。工程上最需要提前厘清的是三类协同：

• 车门/站台门协同：信号系统发出开门允许，站台门与车门须在时间窗内完成联动；间隙探测报警时，必须禁止发车。这里的接口时序与故障导向（fail-safe）定义，直接决定运营安全。
• 车辆—信号协同：唤醒、自检、休眠、火灾报警、障碍物检测等状态需通过车辆网络与信号接口传递，接口协议与状态字定义必须逐条对齐。
• OCC—现场协同：远程控制台的操作权限、与现场人员的作业互锁（如进入轨行区必须封锁），是FAO运营规程的核心内容。

一个可对照的演进判断示例

假设某线路现状为CBTC/GoA2，计划升级到GoA4。可按"职责转移"逐项核对，形成如下判断表（示例参数为教学假设，非实测）：

这张表的价值在于：它把"FAO升级"从笼统的系统替换，转化为一条条可核查的职责转移项。凡是标为"需新增"的行，就是接口设计、试验验证与运营规程必须重点覆盖的对象；标为"已具备"的行，则说明CBTC阶段积累的自动控车与自动进路能力可以直接复用。理解了这条"职责转移"的主线，后续学习FAO的具体功能、接口与运营场景时，就能始终清楚每一项能力是从哪里来的、又为什么必须与其它系统协同。