4. 车载ATP与地面RBC的无线接口实战
在CTCS-3级列控系统中，车载ATP与地面RBC之间的无线接口是列车获得行车许可的关键通道。这条通道并非“一直在线”的固定链路，而是由车载ATP主动发起、按需建立、按会话管理的应用层连接。承载层可以是GSM-R电路域数据，也可以是LTE-R分组域数据，但无论承载如何变化，应用层交互遵循同一套会话逻辑：呼叫建立 → 注册（登录） → 会话保持与消息交互 → 注销（退出） → 释放连接。本节以一次完整的接口配置任务为主线，把这条链路上的关键消息、参数和判断依据讲清楚。
一、先看清接口的分层结构
车载ATP与RBC之间的通信在纵向上分为三层：承载层负责建立物理/逻辑通道，传输层保证数据可靠送达，应用层则承载列控业务消息。工程上最容易混淆的是“链路通了”和“注册成功”这两件事——前者只说明承载层可达，后者才说明应用层会话已建立、RBC已认可该车载ATP的身份。下图给出这条接口的分层关系与消息流向。
二、呼叫建立：先把通道打通
呼叫建立阶段的目标是让车载ATP与目标RBC之间具备可用的数据通道。在GSM-R承载下，车载ATP通过拨号方式发起电路域数据呼叫，使用RBC预先分配的呼叫号码（例如示例中配置为13000000123，实际号码以线路数据配置为准）；在LTE-R承载下，则通过分组域建立到RBC的IP连接，使用配置的IP地址与端口（示例：10.20.30.40:9000）。这一阶段需要确认三个参数：目标RBC标识、承载方式、本端车载ATP标识。三者必须与线路数据中的配置一致，否则后续注册会被拒绝。
工程上常见的误区是“拨号成功即认为接口正常”。实际上呼叫建立只完成承载层握手，此时应用层尚未交换任何业务报文。正确的观察点是：承载连接建立后，车载ATP应能收到RBC侧返回的链路确认，随后才进入注册流程。若呼叫建立反复失败，应优先排查号码/IP配置、无线覆盖质量和RBC端口状态，而不是去查应用层参数。
三、注册：让RBC认识这列车
注册是整条接口链路上最关键的一步。车载ATP向RBC发送注册请求，报文中携带本端标识、列车位置信息（如公里标、线路号、应答器组编号）以及当前工作模式。RBC收到后校验该车载ATP是否属于本RBC管辖范围、标识是否合法、位置是否合理，校验通过则返回注册接受报文，会话正式建立。
以一次教学示例配置为例，注册请求中的关键字段可整理如下（数值为示例假设，非实测）：
| 字段 | 示例值 | 作用 |
|---|---|---|
| 车载ATP标识 | ATP-0087 | RBC据此识别会话主体 |
| 线路号 | L-京沪-下行 | 确定管辖RBC与线路数据 |
| 当前位置公里标 | K1024+350 | RBC判断是否在本辖区 |
| 最近应答器组 | BG-1024-02 | 辅助定位与校验 |
| 工作模式 | CTCS-3 | 决定后续消息类型 |
注册被拒绝时，RBC通常返回拒绝原因码。工程排查应按“标识—位置—管辖”的顺序逐项核对：标识不匹配查车载配置，位置异常查应答器与公里标，管辖不符则说明列车尚未进入该RBC辖区，属于正常拒绝而非故障。注册成功后，车载ATP进入会话保持状态，周期性接收RBC下发的行车许可与线路参数。
四、注销：干净地退出会话
当列车驶出RBC管辖范围、退出CTCS-3级或结束任务时，车载ATP应主动发起注销。注销请求携带会话标识与注销原因，RBC确认后释放该会话资源并返回响应。这一步看似简单，却是工程上最容易遗漏的环节：若车载ATP直接断开承载连接而不注销，RBC侧会话会在一段时间内保持“已注册”状态，形成僵尸会话，可能影响后续同标识列车的注册。
五、一次完整配置任务的落地要点
把上述流程落到一次接口配置任务中，可按以下顺序执行并逐项确认：
- 核对线路数据：确认目标RBC标识、呼叫号码或IP端口、本端车载ATP标识三者与线路数据一致。
- 建立承载：发起呼叫或建立分组连接，确认承载层可达。
- 发起注册：发送注册请求，观察是否收到注册接受报文；若被拒，按原因码定位。
- 会话保持：注册成功后观察周期性消息交互是否正常，确认会话未超时。
- 主动注销：任务结束前发送注销请求，收到响应后再释放承载连接。
判断整条接口是否配置成功的依据不是“能拨通”，而是“注册被接受、会话稳定保持、注销有响应”这三个应用层事实同时成立。建议在配置完成后保留一份会话日志，记录注册请求与响应的时间戳、会话标识和注销结果，作为接口验收与故障回溯的依据。