地铁列车与地面数据接口故障研究

廖绍辉，李乾，姚风龙

（1.中车长春轨道客车股份有限公司，长春 130062；2.中车青岛四方车辆研究所有限公司，山东 青岛 266031）

0 引言

随着地铁列车网络控制及监控技术的发展，为了提高列车运营及检修效率，地面对列车状态的实时显示及监控越来越重要。同时为了发展和利用智能运维技术，地面也配置了对应的综合监控系统，用于对列车状态和故障数据的分析处理。因此列车网络控制及监控系统（TCMS）与地面综合监控系统的接口设计显得尤为重要，对其接口发生故障后的快速分析、处理提出更高的要求。本文基于某地铁线路列车控制及监控系统与地面综合监控系统的接口网关故障，深入分析、探讨故障的原因，并提出有效的故障处理措施，为后续列车与地面的数据传输接口设计提供参考。

1 故障情况

传统的故障数据下载的时间一般为每天列车运营结束、回库后进行。基于列车日常维护，人工下载数据将非常耗时且不方便操作[1]；为实现更加合理的检修操作，提高效率，并保证地铁列车运行的安全性，对正在运行的地铁列车进行状态监测变得越来越重要[2-4]。

为了保证某地铁线路列车数据的实时落地，方便运营和维护，地面配置综合监控系统，同时配置车载设备，车辆与地面综合监控系统数据传输接口采用422网关，通过422网关连接地面综合监控系统和列车控制及监控系统。但是开通运营后，综合监测系统离线故障频繁发生。

422网关模块是地面综合监控与车辆接口设备，车辆正线发生重要故障时会主动上传故障数据至地面综合监控系统；综合监控系统也可以通过主动轮询的方式查询车辆状态数据，车辆收到综合监控的轮询请求后，上传车辆部分的状态至地面综合监控系统。

列车故障发生时，通过422网关串口抓取数据，发现无任何数据输出，网关表现为死机状态，列车与地面数据通信中断。

2 列车车地接口设计及硬件配置

地铁列车TCMS系统采用符合EN61375标准[5-6]的MVB总线，地面综合监测系统未配置MVB接口，需通过422网关转换后与列车TCMS通信。该项目采用的422 网关模块配置如图1 所示。从左到右依次为电源板、两块422-CPU板及MVB通信板。422-CPU（Central Processing Unit）分为一主一从，其中靠近MVB板的为主板。

图1 422网关模块配置示意图

3 422网关模块通信设计原理

正常情况下，只有主板与422设备（地面综合监控系统）进行通信，从板热备；同时主板负责与MVB板进行通信，主板和从板之间通过CAN总线进行数据交互。如果主板在设定的时间内收不到422设备的数据，则自动切换到从板并尝试与422设备通信，从板如果与422设备成功通信后，数据仍然需要借助主板发送到MVB网络。

4 故障原因分析

MVB通信设备工作受环境影响，比如超出工作温度范围、电磁干扰（EMI）、供电质量等。如果MVB通信设备所处的工作环境超出了适用范围，可能会发生通信故障等问题[7]。

该项目的422网关模块配置的CPU主板与从板的程序基本完全一致，唯一的不同在于主板包含与MVB通信相关的功能。因此如果主板出现死机故障，则422网关与MVB网络的通信就会中断。根据该线路多次故障现象，所有的死机故障都发生在主板，从板未出现过死机故障，因此可以合理怀疑MVB相关的功能导致了死机故障的发生。

导致422网关死机的原因主要有硬件原因和软件原因两个方面。

4.1 硬件分析

硬件死机主要原因有：复位电路不稳定，电源不稳定，时钟不稳定。

复位电路不稳定：复位电路加有watchdog 电路，watchdog监测喂狗（WDI）信号，如复位电路不稳定，可能导致复位不规则和故障时无复位。看门狗电路原理如图2所示。

图2 看门狗电路原理图

电源不稳定：电源不稳定主要是内核电源不稳定，在同一块电路板上可能同时有多种芯片，因内核电压相同，而采用同一路电源供电，而在CPU有大负荷工作量时，造成工作电路继续增大，从而拉低内核电压，造成瞬时电压不足，从而可能造成CPU程序故障。

时钟不稳定：时钟信号幅度较小能量较弱，在常温工作时正常，长时间工作也没有问题；而在低温时，这时时钟信号可能已经弱到不能持续地给CPU工作，从而使CPU死机。

针对硬件原因，在实验室对422网关模块进行EMC试验测试，验证在某些场景下，网关是否会出现相同的故障现象。通过试验确定是否为硬件及外部环境原因导致的故障。搭建的EMC测试平台如图3所示。

图3 EMC测试平台

试验过程中，通过软件持续观测网关模块的运行情况，网关模块运行正常，未出现死机故障。根据试验结果，基本排除了外部环境原因导致网关模块故障。设备在装车前也已完成相关的电磁兼容测试，包括浪涌试验、静电放电试验、速变脉冲群抗干扰度试验、射频干扰试验、电源电压变化试验和电源中断测试。

4.2 软件分析

软件导致死机的原因主要有：堆栈溢出；数组溢出；访问指向空地址的指针；未声明的函数调用故障。

堆栈溢出：程序运行的堆与栈的空间大小都是由软件设计定义分配大小的。通常出现问题就是为软件运行设置的堆或栈的空间太小，而导致程序不能正常运行。

数组溢出：数组溢出就是定义数组的空间大小，而通过数组下标访问时，下标超过了数组的边界，这样可能改写其他地址的数据，造成程序跑飞。

访问指向空地址的指针：访问未初始化的空指针也可能出现CPU跑飞的情况；或者将指针作为函数参数传递时，指针未指向具体的地址，而在函数中使用，可能出现死机的情况。

未声明的函数调用故障：如果一些函数没有显式声明，而直接调用，则可能达不到函数预期的效果，或者就是故障。

针对软件原因，网关模块本身具备在程序故障时重启设备的功能。该功能通过看门狗电路实现，程序正常运行时会不断“喂狗”，一旦跑飞，不再“喂狗”，正常情况下看门狗电路便会复位网关程序，但是列车实际情况是通信故障发生时，网关并没有重启，据此推测可能是由于程序运行过程中在某处陷入死循环，但是“喂狗”代码所在的中断程序仍能够正常进入，因此表现为网关死机，但是没有重启。

通过硬件和软件两方面的分析和测试，因此初步锁定是网关程序陷入死循环导致离线故障。

5 改进方案

针对上述硬件和软件的分析，改进主要在软件方面，通过以下方式对程序进行优化，排查造成程序陷入死循环的隐患。

数组和堆栈溢出问题是造成程序崩溃的常见原因，可能导致程序在某处陷入死循环，因此对该项目的422网关代码进行了全面梳理，消除类似隐患。在程序中增加打印语句，方便确认故障时刻各代码模块的运行情况。

根据网关生命信号，对“喂狗”程序进行判断，当网关程序在某处陷入死循环，此时生命信号不再变化，则经过一段时间即停止“喂狗”，重启设备，这样能够保证即使故障再次出现，也能够及时重启设备，保证设备正常运行。

6 初次测试分析与验证

根据上述初步分析，制定改进方案：升级422网关模块软件，软件在通过实验室测试验证后，选择部分列车进行现车验证。

升级的程序在现车验证试验期间，仍然频繁出现422网关死机故障，根据现场故障情况以及软件升级整改时增加的打印语句分析发现，故障板卡全部为422网关主板卡，网关从板卡均正常运行。

因此从主从板卡程序差异方面入手进行再次分析。422网关模块的主从板卡程序本身并无差异，二者主要依靠配置文件进行区分。根据该模块的通信设计原理，网关主板卡与MVB进行通信，而从板卡不直接与MVB通信，因此通过配置文件的设置，从板卡在程序中没有运行MVB初始化相关的代码，这也是主从板卡程序运行中的主要差异。因此可以将故障原因定位在MVB初始化方面，并从此方面进行再次分析和研究。

根据初步整改试验分析的结果，将故障原因定位在MVB初始化方面。因此与MVB板卡硬件厂家进行沟通，共同对初始化代码进行分析，对初始化代码进行更新。

初始化代码主要整改内容如下：一是删除之前MVB初始化代码中的无用代码块，精简代码，防止多余代码影响程序运行；二是增加MVB配置初始化之前的时间延迟，确保CPU启动完成，MVB网络通信正常后，网关模块再进行相应初始化；三是梳理MVB初始化的运行流程，每次初始化时，先进行端口清理，再进行设备配置和端口配置；四是将看门狗程序移植到主程序当中，防止出现主程序陷入死循环的故障。

7 再次测试分析与验证

通过对初次分析和现车验证出现问题的分析，根据初次整改失败分析结果，对422网关模块程序进行再次梳理升级，避免出现如上分析的故障因素。

二次整改后的程序同样经过实验室测试后，初期同时选择在数列车进行现车验证。通过1个月验证周期内的跟踪，未再次出现类似网关故障，可以确定二次修订后的整改措施有效。

根据二次软件整改的现车试验情况，可以初步判定网关死机故障由网关MVB初始化不完善造成，从目前实际运用情况来看，二次整改后的新程序稳定性较好，未出现故障。因此最后对该项目列车的422网关模块程序进行批量升级；同时持续关注422网关模块后续的运行情况。在网关模块软件升级后，经过1年多的跟踪观察，未出现类似通信故障，说明整改措施有效。

8 结语

对系统之间存在不同通信接口的设计，因双方内部采取的通信方式不同，势必需要对转换模块进行匹配选型及通信接口软件分析和优化。通过对实际项目列车车地数据传输接口故障的分析、处理、现场测试和再分析优化，总结出接口转换模块设计，在硬件和软件方面需要注意的关键项点。对类似接口转换模块故障的分析，应从硬件和软件方面同时着手，对硬件配置进行性能测试，对软件进行逻辑优化；对新项目的接口设计，需充分考虑硬件配置和软件优化，减少运营后的通信故障。