lc故障代码是什么故障（CBTC 信号系统智能化故障分析）

摘 要: 传感器、摄像扫描、温度感知、电压电流模块等技术发展已日臻成熟，后续若运用至信号系统中，可全面、准确地采集信号状态感知层数据；云储存、大数据的高速发展，已具备针对每天数万亿数据元的信息传输及存储处理能力。信号系统日志能详细记录设备运行中硬件、软件等信息，结合系统日志的时间维度、密度和种类特征、空间维度和时序特征及设备报警等级，论证信号系统智能化分析的可行性和必要性，阐述信号智能化维护系统模型及后续模型搭建的要点及注意事项。

关键词: 轨道交通；数据采集；日志特征；可行性分析；智能化维护系统模型

01

CBTC 信号系统的故障处理方式

基于通信的列车运行控制系统(communication based train control system，CBTC)作为城市轨道交通的

“大脑”和“中枢神经”，目前已成为列车控制的主流制式，CBTC 从大的方面来看，可以分为列车控制和信息传输两大部分。笔者调查了目前主流的设备厂商得知，列车控制部分主要由 ZC(zone controller，区域控制器)、LC (line controller，线路控制器)、联锁子系统、车载 CC(carborne controller，车载控制器)子系统、ATS (automatic train supervision，列车自动监控)子系统构成，信息传输部分采用无线通信系统，常见的系统架构如图 1 所示。

列车在正常运行过程中，控制各子系统各司其职，按照分工进行信息流的交互及处置，共同确保列车的安全稳定运行。但是，各子系统自身有独立的处理逻辑，同时相互之间又具备极强的关联性，运行过程中一旦发生因信息处理冲突等导致的故障，在各子系统上可能会出现不同的故障显示，很难在短时间内确定为哪个子系统导致，故障定位难度大，需对各子系统

均精通的人员进行处理；再加上调度、站务、司机等设备使用人员对故障信息获取较少，上报存在片面，而信号集中监测系统(MSS)主要监测硬件类的设备报警，各子系统日志较少，故障处理人员更擅长处理硬件故障，信息来源少且片面，导致故障处理效率低下。因此，亟需从 CBTC 层面研究，按照各子系统的功能和信息流走向，通过软件判断设备或者软件故障发生的根本原因，并快速排除。

02

信号设备状态感知层的采集能力

2.1 环境情况监控

目前，针对监控设备的温湿度、漏水、灯光控制、玻爆、烟雾粉尘等的监测能力已经具备，后续可将设备室的环境情况通过串口服务器或信号采集器传送至监测系统中作为底层数据[1]。

2.2 状态感知层监控

硬件管理方面，目前在行业内是利用传感器、监测设备、摄像扫描、温度感知等技术，将道岔、信号机、计轴/轨道电路、电源设备、ZC、LC、车载 CC 等设备硬件的电压、电流、灯位显示、温度变化、开关量/模拟量变化等进行综合采集，后续也可通过网络传送至智能化维护系统中作为底层数据，为后续综合分析并给出报警信息、处理建议和行车影响预警打下基础[2]。

2.3 信号设备监控

信号设备中有大量的设备工作站、交换机、服务器等，目前行业内已具备对工作站、交换机的 CPU、内存、磁盘占用率、网络端口流量、包错误率、包丢失率、温度、风扇转速、各模块工作状态等的监控能力，后续对操作记录、事件、日志等运行情况进行监控，形成大数据后作为信号设备的底层数据。

03

信号设备智能诊断的可行性分析

随着云储存、大数据的高速发展，已具备对状态感知层每天采集的数万亿数据元的信息传输及存储处理的能力。信号各子系统在设计阶段和功能描述中，系统日志详细记录了设备运行中硬件、软件的各种状态信息，因信号系统网络的封闭性和高安全性，为发生设备故障后快速通过 IP 地址和 MAC 地址追溯故障原因创造了条件。信号各子系统在信息传递时具备明显的逻辑时序，可通过各子系统信息流之间的横向对比，快速实现日志在空间维度中的异常检测；通过对单个子系统日志中的数据信息与历史数据的对比，能快速实现日志中时间维度的异常检测功能。

3.1 日志的时间特征

举个典型故障案例：某线路信号 ATS 子系统在执行计划下发、调取运行图、报表信息等命令时，频繁出现卡死现象，其他功能均正常；而该线路运行图、报表信息的存储和调阅，以及用户权限的核对等功能，由数据库服务器负责。通过对其 A、B 机 oraagent.log 日志进行查看，发现故障的发生时段均会出现故障语句 ([ora.LISTENER_SCAN2.lsnr][8000]{1:56041:268}[check] clsnUtils::error Exception type=2 string=CRS- 5014: 代理在启动进程 "D:\app\11.2.0\grid\bin\lsnrctl.exe"以执行操作"check"时超时)。因故障出现的随机性，维护人员很难及时发现故障代码并处理故障。

设备日志信息具备明显的时间维度特征，故障前后记录的日志数据均大致相同，只是在故障时段会出现异常数据。因此，通过已发生事件的时间间隔变化，可以快速获取事件的变化模式。通过日志信息中提取的多种特征信息进行相似性检测、回归分析和机器学习，建立检测模型，可快速实现异常检测。

3.2 日志的密度和种类特征

通常，设备在正常状态下可能不定期地产生少量的日志记录。当设备异常时，设备可能会打破记录的模式，产生大量的日志记录，即故障时段设备日志的密度明显增加。例如，某线路信号系统试运营阶段，某 ZC 控制区域内正在运行的列车全部触发 EB 停车，且 CBTC 模式不可用，后对该时段 ZC 日志进行分析发现，此时某列车进入该 ZC 区域，在与 ZC 通信时出现了大量的延时报文(cc_zc_synchro_obsolete)，ZC自锁，从而导致列车全部触发 EB 停车。

3.3 日志的严重等级

信号各子系统异常日志具备明显的等级划分，如根据严重程度，将报警分为了一级报警、二级报警和三级报警，并针对不同报警，使用了如声光报警、弹出式报警、红色显示报警等方式。维护人员可通过不同报警信息，快速实现故障定位和判断。

3.4 日志的空间维度和时序特征

各子系统之间虽相互独立，但具备明显的关联关系和逻辑时序，此种故障用如下案例加以说明。

3.4.1 典型故障案例 1

ATS 折返进路与联锁防护区段 overlap 触发冲突[3]：如图 2 所示，在正常运营过程中，DG5110 区段突发白光带。

• 1) ATS 日志分析：列车占用小交路折返站折返轨时，ATS 自动触发 S5115-X5106、S5104-X5102 进路，进路按照从远端至近端开放的原则，联锁先正常办理了 S5104-X5102 进路，接着办理 S5115-X5106 进路，对 DG5110 区段进行了锁闭(此时 P5110 道岔反位)。此时开往上行方向的大交路车因开放 S5302-S5108 进路触发了 O_S5108，需将 P5110 道岔放置在定位，P5110 道岔向定位转换，导致已锁闭的 DG5110 区段故障，显示白光带。
• 2) 联锁日志分析：按照联锁系统的处理逻辑，进路办理可简化为选择组电路确保道岔在正确的位置、执行组电路进路锁闭、执行组电路信号开放三个部分。查看联锁日志可知，因 P5110 道岔本身在反位，联锁不发送驱动道岔动作命令，只驱动 P5106-P5108 道岔向反位动作；而此时 O_S5108 发送命令，联锁驱动P5110 道岔向定位动作，因命令刚刚发出，此时 P5110道岔第一启动继电器尚未励磁，P5110 道岔仍处在反位表示状态。ATS 开始预排列进路 S5115-X5106，将相关区段锁闭。此时 P5110 道岔继续按照联锁命令转换至定位，导致已锁闭的区段出现白光带。两种命令处理冲突的过程如表 1 所示。

由上述分析可知，按照 ATS 和联锁子系统空间维度的日志对比和联锁子系统时序特征，可快速判断故障原因为 ATS 折返进路与联锁防护区段overlap 触发冲突所致。因此，后续 ATS 触发时可增加两条命令的冲突判断处理机制，从源头避免故障的发生。

3.4.2 典型故障案例 2

列车以ATP模式在小交路站使用站前P5101道岔折返时，产生紧急制动，行调组织司机以 RM 模式动车后恢复 ATP 模式运行，如图 3 所示。

• 1) 车载日志分析：故障发生时，列车车头所在区段为 B_67，即 X5105 信号机至 P5101 道岔，列车车头进入 X5105 信号机内方后，列车移动授权丢失，发生紧急制动。
• 2) ATS 日志分析：501 次工程车一直停留在车站下行站台，ATS 正常开放 X5105 信号机黄灯后，列车进入 X5105 信号机内方，ATS 未发现异常，司机反馈列车紧急制动停车。
• 3) ZC 日志分析：501 为非通信车，其 NIAP(非识别自动防护)区域为 WG5119 处。为确保行车安全，系统在 NIAP 与 AP 之间会设计一个出清的区域(buffer zone)，其区段为 B_68，即 P5101 道岔至 S5107 处。因 B_67、B_68、B_225 均为同一轨道区段 DG5101，当车头一进入 X5105 信号机内方时，DG5101 被占用，ZC 处于安全考虑，将 buffer zone 扩延至 B_67 区域，导致列车产生紧急制动，故非信号设备故障。
• 4) 故障处理难度：因 X5105 信号可正常开放，所以列车运行过程中突发紧急制动很难立即锁定故障原因，列车回库后下载车载日志再分析会浪费大量时间，且车载日志分析也并未发现异常；而 ZC 日志分析，因各设备厂商之间不同设计理念的差异，想要打破技术壁垒、弄懂设计人员的初衷难度很大，维护人员很难在短时间内通过大量数据判断出故障原因，需设备厂商的专业技术人员提供技术支持。
• 5) 智能化分析探索：因信号可正常开放，能判断出 ATS 子系统、联锁子系统均功能正常。ZC 系统通过 CC 发送的列车移动的相关信息，可迅速判断出紧急制动是否因空转、打滑、定位丢失等原因造成；在排除车载故障原因后，ZC 可迅速判断无法给出移动授权的原因，给行车指挥人员提供正确的组织行车建议。

04

信号智能化维护系统模型的建立

分析状态层数据和信号各子系统的日志特征可知，CBTC 信号系统具备智能化维护的可行性，而信号设备故障影响大、故障定位困难，信号专业人员培养周期长、难度大，已成为各地铁公司安全、稳定运行的制约因素，所以亟需由人工传统的状态修、故障诊断向智能化转变。经过上述可行性分析与案例论证，智能化发展可从 3 个方面入手：

1) 全面、准确地收集原始数据，因信号设备受风霜雨雪等恶劣天气和温度、湿度影响较大，所以建议源数据包含环境状态和气象信息等数据。此外，监测状态感知层在数据采集时标准应统一，因道岔、信号机等信号设备继电器电路均采用同样的定型组合，为确保分析的可靠性，新增的电流、电压采集点应在定型组合的统一位置，建议提前编制技术标准，确保监测内容、监测点、监测量程、监测精度、采样速率等一致，确保后续数据剥离、加工后的报警方式等一致[4]。

2) 数据预处理阶段，因监测数据量大、杂乱且来源复杂，针对数万亿的数据元，可通过重复值、缺失值、异常值等形式进行数据质量的检查，并通过数据抽取、转换、检查、数据调度等方式，对数据进行预处理，筛选出关键数据[5]。

3) 机器学习建模阶段，一是结合不同的数据特性研发不同的分析方法，实现数据的全量智能分析，如针对各子系统连续的数据日志记录进行波形分析，针对道岔、信号机等使用事件型曲线进行特征分析，针对综合型多数据及多接口数据，利用专家知识库进行综合分析推理，利用故障树、事故树等推理故障影响或故障原因，确保数据挖掘的深度和有效性[6]；二是通过各子系统的日志解析软件，对区域控制器(ZC)、线路控制器(LC)、联锁子系统、车载 CC 子系统、ATS 子系统的运行过程进行全程监控，并诊断分析行车运行过程中存在的问题，针对历史故障开展机器语言学习，自动更新故障库[7]；三是通过各子系统的逻辑关系，分析 CBTC 信号系统运行过程中存在的软硬件问题，最终构建集设备监测、维护、诊断、管理、预警及应急处置指导于一体的智能化维护系统[8]。

4) 模型发布和模型应用阶段，因各地铁公司应急预案、行车组织规则、故障处理细则均有自身特点，数据模型发布应用时，可结合各公司运营管理的要求进行使用，给出设备故障、大雪天气时智能行车组织、故障处理、健康度评价、应急指挥处理、启动预案的建议。譬如，小交路站道岔故障后立即全部智能改开大交路行车，若确定为室内故障，立即要求维护人员更换故障元器件，启动信号故障应急预案等[9]。智能化维护系统模型如图 4 所示。

5) 信号智能化系统宜采用自动分析、智能判断、智慧信号逐步推进，按照站机、线网、全网化逐步建设，通过大数据分析人员行为特征，AI 预测人员行为动向，虚拟现实培训，基于 BIM 的设备全生命周期管理，AI 预测维修及施工，最终实现信号智能运维体系的建设[10]。

05

结语

计算机软件开发、机器语言学习、人工智能等技术的飞速发展，为信号智能化维护系统的发展创造了有力的条件；信号各子系统的日志和明确的逻辑处理关系，为故障定位及行车影响判断打下了基础。为确保行车设备安全稳定运行，急需各设备厂商及信号维护人员共同开展研究，攻克难关，共同出台信号智能化维护系统标准，开发出安全可靠的智能化维护系统，提高信号故障处理的速度和准确性[11]。