城轨车辆全列设备网络通信异常原因探究

唐亚峰，雒录录，赵煜杰

（中车成都机车车辆有限公司，四川成都 610051）

1 引言

列车控制与管理系统（TCMS）是一套分布式微机控制与监视系统，集列车控制系统、故障检测与诊断系统以及旅客服务控制系统于一体，以车载微机作为主要手段，通过多级列车网络总线实现系统、列车之间的数据信息交互，最终达到对车载设备的集中监视、控制以及管理的目的，实现列车控制的智能化、网络化与信息化，保证列车的行车安全。本文以成都地铁18 号线车辆调试阶段出现的多列车试验过程中各系统设备无规律通信异常问题为出发点，阐述列车网络通信逻辑和触发网络通信频繁异常的原因，并制定解决措施，提高列车控制与管理系统可靠性。

2 TCMS 网络通信原理

2.1 网络配置特征

列车通信网络划分为2 级：列车控制级和车辆控制级。2 级网络具有以下相同特性：均采用电气中距离（EMD）介质的多功能车辆总线（MVB）传输；均采用通信线路双通道冗余设计，当受信线受阻时可自动切换。每节车配置1 个中继模块（REP），用于实现列车级总线与车辆级总线数据转发以及物理隔离。

列车控制单元（VCU）承担车辆控制和总线管理的功能，头/尾车各配置1 台VCU，互为热备冗余。车辆控制功能是通过接收总线或硬线收集的数据，利用VCU 内程序实现，正常情况下，2 台VCU 中1 台为主控，1 台为从控热备，即按人机接口显示屏（HMI）上显示的主、从进行区分。

总线管理功能是2 台VCU 通过竞争机制自动选取1 个作为总线管理强主，负责MVB 总线的管理功能，另1 个VCU 自动处于弱主状态，实时监测强主状态，在标准规定周期内未收到强主发出的主帧信号，则自动转为总线管理强主。在本项目中，总线管理主从设置为被动切换模式，绑定了车控控制主控和总线管理强主，上电时默认1 车车端VCU 为主。只有在1 车车端VCU丢失且8 车车端VCU 信号满足条件时，8 车车端VCU才自动转为强主。

由于所有数据均通过总线传递，无论那边VCU 是否为强主，在实际车辆控制中均以司机钥匙激活端的控制指令为准，其主权交换及所在位置不会对控制指令下发造成影响。

2.2 总线管理逻辑

根据IEC 61375-3-2-2012《电子铁路设备.列车通信网络（TCN）第3-2 部分：MVB（多功能列车总线）》中的相关规定，列车MVB 网络中设置2 个总线管理（Master）设备，2 个设备在正常情况下互相监听，1 台处于总线管理主（regular master）状态，1 台处于总线管理备用主（standby master）状态。根据写入设备内的配置文件，2 台总线管理设备可按照配置主动交替总线管理主权，或通过监听被动交替总线管理主权。在实际应用中，2 种应用方式均被许可，并无优劣之分。

当配置文件被设置为主动交替状态时，2 台设备会按照配置文件内规定的周期，传递主帧令牌。当配置文件被设置为被动交替状态时，standby master 设备并不会主动传递主帧令牌，而是当standby master 设备无法监听到regular master 设备发出的主帧达到“备用设备”状态超时（T_standby）时，自动转为regular master 状态，担任总线管理主设备。

无论使用哪种配置，在regular master设备监测到总线上存在主帧时，均会放开主帧令牌，重新启用总线管理竞争机制，在该机制算法中，遵循的计算公式如下：对于一个已配置的总线管理器，T_standby=（T_alive×2×（1+rank_in_ba_list）；对于一个未配置的总线管理器，T_standby=（T_alive×2×（ba_adr+15）；对于一个禁用的总线管理器T_standby=无穷。其中，T_alive 为主帧之间的最大间隔时间；rank_in_ba_list 为此设备在总线管理器列表中的排列次序；ba_adr 为总线管理器设备地址。分配较低的设备地址给总线管理器将使其恢复速度更快。

根据以上机制，结合本项目中不主动传递主帧令牌的设置，在2 台作为总线管理主的VCU 同时上线时，1 车车端VCU 由于具有更小的总线设备地址，会成为regular master 设备。而当1 车车端VCU 异常，8 车车端VCU 由standby master 切换为ragular master，反之亦然。除非regular master 设备监测到主帧碰撞或辞职（如设备异常或掉电），否则不会放出主权。其主权转移状态，如图1 所示。

3 故障描述

成都地铁18 号线第02、05 列列车在试验过程中，出现1 车车端VCU 断电后，子系统设备重复批量掉线的问题。针对此现象，对调1 车、8 车车端MVB 板卡并重刷对应VCU 程序后问题仍存在，经检查作业记录可知，近期牵引系统进行了软件升级，随后进行VCU整车冗余控制时，发现当1 车车端VCU 作为总线管理主时，各设备通信正常，当将1 车车端VCU 断电后，总线管理主切换至8 车车端VCU 时，各设备通信异常，车门、制动等系统偶发性的报通信丢失。

4 故障调查及分析

4.1 故障排查

4.1.1 硬件排查

为明确故障原因，首选对硬件设备进行逐一排查，经对列车接线及接插件进行检查、对设备件对调验证后，初步排除接线及硬件导致故障发生的可能性。

4.1.2 对比排查

对所有列车进行排查对比，已更新牵引系统软件的列车均存在不同程度的全列设备网络通信异常，各设备无规律闪粉，未更新牵引系统软件的列车未发现该现象。另外当断开牵引系统控制器电源后或将牵引控制器软件版本退回上一版本后，故障消除。由此，将排查方向定位在牵引系统新版程序方面。

4.1.3 借助仪器排查

使用示波器、TCN分析仪等专业设备对列车所有设备系统的MVB 通信数据的波形、数据帧进行细致排查、对比、分析，发现新版牵引程序增加了在传输总线上发送消息数据的功能。进一步对通信波形进行采集分析，发现列车总线传输的数据中存在消息数据，以及由于消息数据的存在而导致的偶发性通信异常的情况。同时，经牵引系统技术人员确认，新版软件相比之前的所有版本软件除增加必要的控制程序外，还增加了用于数据存储的消息数据功能，和现车实际测量数据情况一致。具体测试情况如下。

（1）消息数据的存在。通过TCN 分析仪发现，在列车状态正常或异常时，断开某个牵引系统空开，模拟牵引系统故障时，现车会出现大量的消息数据，消息数据显示界面如图2 所示，图中标红列为采用TCN 分析仪获取的主帧（F_CODE），其中F_CODE=C 代表有消息数据收发。

图2 总线存在消息数据（F_CODE=C）

（2）偶发数据传输异常。通过TCN 分析仪对正常时刻、故障时刻的列车总线和车辆总线进行波形采集发现，列车状态正常时，当存在单个牵引系统出现消息数据传输请求时，此时消息数据的收发均正常，且不影响整车数据的通信，总线中主帧、从帧的收发均能按照既定的周期扫描表进行轮询，未发现异常现象，轮询周期扫描表正常状态显示界面如图3 所示，消息数据收发正常状态显示界面如图4 所示。

图4 消息数据收发正常

列车状态异常时，即当有2 个或2 个以上牵引系统出现消息数据传输请求时，发现由于消息数据的启用，列车总线会出现数据帧的碰撞以及偶发性短周期的寂静，寂静持续时间大约5 ms，从而导致部分通信数据的丢失，但由于丢失频率较低，暂不影响现车的控制，现车波形如图5、图6 所示。

图5 多消息数据引发的碰撞

图6 总线偶发的寂静

4.2 故障分析

在故障排查过程中，发现并确定出现故障状态为整车完成启动后，断开1 车车端VCU 电源，8 车车端VCU 由standby master 切换为regular master。通过HMI网络状态监测发现，子系统出现批量的瞬时掉线、上线状态，即子系统各设备成片闪粉，进一步观察相关子系统心跳，发现掉线子系统并非所有MVB 通信端口丢失。由此可基本判定掉线的子系统设备并未处于非正常状态，而是总线中存在干扰或有其他设备在总线上发送主帧。由于此时按照VCU 中的MVB 配置文件，8 车车端VCU 不会收到1 车车端VCU 发来的主帧，所以不会改变自己的MVB 总线管理主状态。将1 车车端VCU 上电启动后，通过HMI 网络状态监测，子系统成片闪粉状态消失，8 车车端VCU 状态由regular master 转变成standby master。根据标准中规定的主权状态逻辑和本项目配置文件，在没有设备异常的情况下，只有主帧碰撞时，regular master 才会放开主权，重新启动主权竞争。

故障状态下，通过断开子系统设备进行筛查，发现仅当断开全列车牵引设备电源后，总线通信异常状态消除。

由此，牵引系统设备发出了主帧，引起子系统设备应答混乱，表现现象为批量掉线/上线（闪粉），牵引系统设备正常工作时主帧（消息数据）传输较少，而故障时刻传输更为频繁。

5 故障结论及整改

5.1 故障原因

网络控制系统判断系统通信故障的逻辑为：本系统任意一个端口中的生命信号（一般为协议的第一个字）停止跳动时间超过8 个端口的通信周期时，则判断该系统与网络控制系统通信异常。因此，故障状态下，由于偶发的总线寂静，导致某端口的生命信号停止跳动时间一旦超过本端口传输周期的8 次以上的时长时，现车就会在显示器上显示本系统通信异常。

新版牵引系统程序增加了消息数据功能，当牵引系统发生故障时，牵引系统与牵引系统记录单元（CCU-D）之间会传递消息数据，用于对故障发生时环境变量的记录，从测试结果来看，短时冲突的消息数据会导致总线出现主帧偶发缺失的工况，从而影响过程数据的传输。

设计初期根据要求牵引系统和网络系统完成了过程数据的接口测试，但消息数据一直未做接口测试，同时由于IEC 61375-3-2-2012 中规定的消息数据传输、调度方式存在多种形式，因此双方的匹配需要根据地面接口测试的实际情况进行适配。

5.2 结论

根据以上的故障排查及分析，通过对现车的测试、对比、分析，造成本次故障的主要原因是由于牵引系统和网络系统在消息数据处理方式上不匹配，导致总线处于偶发的寂静状态，即某个系统端口的数据无法正常的收发，影响到总线数据的正常传输，整车表现出某些系统偶发的通信异常状态，HMI 屏通信界面闪粉。

5.3 整改

牵引系统和网络系统完成相应消息数据的接口测试工作，并针对双方消息数据的处理机制做进一步的确认，修改牵引系统或网络系统的配置文件解决消息数据调度的问题。本项目通过优化VCU 中MVB 配置文件并更新MVB 板卡固件的方式，配合牵引系统消息数据的发送，消除总线通信异常的现象，从而解决车辆HMI屏通信界面设备闪粉故障。

6 结语

列车控制与管理系统（TCMS）集列车控制系统、故障检测与诊断系统以及旅客服务控制系统于一体，负责对列车牵引、制动、转向架、辅助电气、车门、空调等系统的控制、监视和诊断。同时在列车自动驾驶中一方面及时向行车控制中心（OCC）报告工作状态，另一方面接收控制中心下达的控制命令。健康的网络系统对于列车的安全、可靠运行至关重要，部分车辆相关设备的软、硬件变更直接影响车辆网络系统的可靠与否，变更过程及结果的卡控直接决定变更后网络系统的可靠性，因此变更中的沟通及试验验证尤为重要，运营中的车辆直接面对乘客，更加需要专业人员的层层把关，提高产品可靠性。