列车网络通信故障分析与解决

列车网络通信故障分析与解决

李存栓    ,徐锦鹏

中车南京浦镇车辆有限公司      江苏   南京  211800

摘要：随着高速列车技术的快速发展，传统的列车通信网络难以满足大容量信息数据传输的需要。高带宽、低成本的以太网能较好地解决列车通信网络这一瓶颈问题。深圳地铁12号线列车网络就是基于以太网研究和设计的，在列车开通正线运营时频繁报出子系统通讯故障，本文通过现场调查及地面搭建试验台模拟验证，最终明确故障点并提供网络通信故障的处置措施。

关键词：以太网；城市轨道交通；网络通信故障

1绪论

包括地铁和高铁在内的列车轨道交通系统是我国百姓出行的主要交通方式之截至2020年底，全中国已有43个城市开通了地铁线路，运营里程共计7775公里，2020年中国内地的地铁总客运量为175.27亿人次，日均客运量4803.35万人次。

列车通信网络是连接列车车厢和设备的数据通信中枢。随着列车网络的软硬件结构复杂度不断提升以及音视频等流媒体数据的加入，传统列车通信网络所使用的MVB、WTB等总线技术正被传输速率更高、时延更低、成本更低廉的以太网技术所取代。列车通信网络能够通过信息的交互来实现对列车各种车载设备的管理，各种车载设备之间的通信等。因此列车通信网络在整个列车的运行中发挥着无可替代的作用。列车通信网络的性能直接影响到整个列车的性能。

深圳12号线项目自2022年11月起，到段列车正线运营时频繁报出子系统通讯故障（EDCU、BMS、LGT）。根据PHM地面数据进行的故障信息统计，自运营至今，几乎每天都会报车门、蓄电池监测及照明系统的通讯故障，且有故障出现的时间、位置上的随机性。本文通过现场调查及在实验室搭建测试平台，寻找此类故障发生的可能原因，从而提出解决办法。

2 网络通信通用要求

深圳地铁12号线项目列车控制与监测系统采用基于分组交换技术的编组以太网网络（ECN）。其中列车级网络采用的是双环形结构、终端设备双归属架构，任一环网单点故障不影响整个网络的通信。其中红色环网（以下简称红网）用于控制数据的传输；蓝色环网（以下简称蓝网）用于控制和维护数据的传输。本地车辆级网络采用的是星型结构，任一终端设备的故障不影响其他终端设备的通信。列车级以太网采用1000BASE-T，车辆级以太网采用100BASE-TX。

一列车设置两个VCU，热备冗余，当其中一个故障时，另外一个将自动接替它的工作，实现无缝切换，保证列车的正常运行。VCU通过以太网络能够监视、控制整列车，同时将诊断的信息发送到HMI上，帮助司机进行驾驶操作。设置独立硬件的大容量数据记录仪（EVR）实现故障记录和事件记录的功能。

所有具备以太网接口的子系统设备分别通过dual-homing(双归宿)的方式通过两根控制以太网线分别连接两个编组交换机接入到红网和蓝网ECN，如：TCU、ACU、EDCU、RIOM等。通过实时以太网连接到TCMS的子系统设备，需要完全按照IEC61375-2-3、IEC61375-3-4标准最新版本去设计开发以太网通信模块，需采用双以太网板卡，支持双归属技术。

3 故障调查

3.1 故障情况现场调查

通过收集车载独立事件记录仪数据、VCU记录的EVR和FDL数据进行分析，仍然无法准确定位引起此类故障的具体原因。分别在三列车上部署用于抓取VCU以太网接口报文的工业计算机（IPC）以进一步收集故障时刻以太网报文，从而进一步排查故障原因。

其工作原理为在VCU的T4/T5以太网接口和交换机之间分别设置一个LANTap，工业计算机通过LANtap的监听接口同时收取以太网线路上的Tx和Rx报文，并生成报文记录文件。LANtap是一个无源的报文监听工具，原理图如下图所示。

图2 LANTap原理图

通过工业计算机记录的以太网报文数据，结合车辆故障信息（FDL）进行子系统闪报通讯故障问题的定点分析。

经过一段时间的跟踪，列车多次闪报车门网关通信故障，确认故障现象复现。经过对工业计算机所记录报文文件的分析，可以确认此次故障发生时段，交换机转发出的报文时序正常，不会由于交换机转发时序问题导致通信故障。

3.2 故障可能原因

TCMS统包含多个子设备，网络拓扑比较复杂，整体而言，有多种原因可以导致该类型故障：

1.终端设备或交换机工作不正常。在故障情况下获得的wireshark报文证明这些终端设备和交换机工作正常。

2.Codesys应用程序。应用程序中的问题也可能会错误地触发故障。该故障模式的可能性最低，因为应用程序清晰简单，可能的原因只有内存异常。

3.CodesysTRDP驱动程序内部故障。该驱动程序在多个既有的项目中使用而没有导致问题，因此这不太可能是该故障的原因。

4.SDTV2库，该库是来自庞巴迪并经过SIL2认证的库，并且工作正常。对故障情况的数据进行了分析，来自故障子系统的所有帧都是正确的，数据中没有crc、时间或计数器错误。

5.TRDP协议驱动程序。这部分软件被视为最有可能导致故障出现的原因。在其上层可以正确处理协议，如果在这个层面上帧丢失，那么上层应用也会失效。

通过分析，在实验室主要针对第5部分进行了测试。

3.3试验室搭建试验台测试

测试环境如图所示。这是实验室的测试环境。该测试的数据是现场列车上抓取到的故障时刻wireshark报文，通过Python程序库scapy注入测试系统中。通过将数据注入系统中来尝试复现故障情况。

通过测试脚本send_data_dup.py可将从列车上抓取的wireshark报文数据注入到系统中。单独运行该脚本并没有触发故障。原因是与列车产生故障时刻完全相同的VCU运行状态是不可复制的。通过操纵脚本使相同的数据发送两次（重复），故障可以被触发。在这种情况下，故障现象可以被稳定的触发。因为数据量大幅增加，使故障触发的频率比在列车上更高。

4 故障分析与解决

通过排查TRDP协议驱动程序，注意到程序中接收TRDP报文的线程的优先级较低，在某些时间片下，没有足够的时间处理所有TRDP帧，导致正常TRDP报文未能传递给应用程序。导致VCU诊断出网络通信故障。

5 实施效果和结论

通过更新TRDPD程序，来提高接收TRDP报文的线程优先级可以消除故障情况。在实验室验证优化后，即使使用脚本注入双倍流量，接收线程仍然有足够的能力处理所有报文，不再丢失任何报文导致的故障。优先级提高使系统CPU空闲时间下降了约5%，这表明优化后TRDP接收线程获得了更多的系统资源，从而有能力处理了更多的TRDP报文。

将新版TRDPD程序更新到列车跟踪观察一个月，列车未在出现子系统闪报通信故障的情况，且列车其他功能工作正常，证明该优化措施可有效解决子系统闪报通信故障的问题。降低了地铁列车运营安全风险，对地铁运营安全有着重要意义。