1. CBTC列车自动监控子系统通信中断故障定位

故障场景与定位思路

某站ATS维护终端弹出告警：“ATS-外部系统通信中断（接口：列车自动监控—旅客信息系统/时钟/无线）持续 30 s”。此时列车仍在自动运行，但PIS到站信息不刷新、中央时钟不同步。排障目标不是立刻重启服务，而是先用三类证据把故障域收敛到物理链路、协议配置、对端服务之一，再执行对应恢复动作。

三类证据的判读逻辑如下：

• 网络端口状态：本端交换机端口 up/down、光功率、CRC 错包、双工协商。端口 down 或 CRC 持续增长 → 物理链路方向。
• 协议报文收发计数：在ATS接口进程侧统计 TCP 建链次数、收发字节数、请求/响应配对。能建链但收 0 或请求无响应 → 协议配置或对端服务方向。
• 日志时间戳：对比ATS侧最后一条正常收发时间与对端日志首条异常时间。时间戳连续、无重连记录 → 对端进程挂死；时间戳出现周期性重连 → 配置或心跳参数不匹配。

关键证据的采集与判读

以下命令与字段均为通用做法，具体命令名以现场设备为准；重点是采集同一时间窗内的三组数据，避免用不同时刻的数据互相矛盾。

# 1) 交换机端口状态（以常见CLI为例）
show interface GigabitEthernet 0/12
# 关注：line protocol is up/down、input errors、CRC、duplex

# 2) ATS接口进程侧收发计数（示例字段）
ats_ifstat --if pis_link
# 输出示例：
#   connect_attempts = 37   connect_success = 0
#   rx_bytes = 0            tx_bytes = 0
#   last_rx_ts = 2024-06-11 09:12:03
#   last_tx_ts = 2024-06-11 09:12:03

# 3) 日志时间戳比对
grep -i "pis_link" /var/log/ats/interface.log | tail -n 20

判读要点：若 connect_attempts 持续增长而 connect_success=0，且端口为 up，则优先怀疑协议配置（IP/端口/协议版本）；若建链成功但 rx_bytes 长期为 0，则优先怀疑对端服务；若端口 down 或 CRC 快速增长，则先处理物理链路。

恢复操作与验证

1. 物理链路：清洁/更换尾纤与光模块，确认端口 up、光功率在门限内、CRC 不再增长；随后观察接口进程自动重连。
2. 协议配置：核对对端 IP、端口号、协议版本与心跳周期，修正后仅重启接口进程，确认建链一次成功。
3. 对端服务：在对端侧检查进程与资源，按规程重启对端服务，确认ATS侧收到响应且告警清除。

验证通过条件：告警清除，rx_bytes/tx_bytes 持续增长不少于 5 min，请求/响应配对无缺失，日志中无新的重连记录。