广州地铁7号线列车网络通信故障后出现后溜问题分析

引言

广州地铁7号线列车制动系统采用北京纵横机电提供的国产架控系统,列车控制及诊断系统采用时代电气研发的列车分布式网络通信和控制系统(DTECs平台)。二者的配合应用为在广州地铁线网内首次采用,当在某些特殊情况下,会出现逻辑设定不严谨的情况。

2019年1月7日,07043044车正线进站前出现网络通信故障,车辆屏黑屏,司机PM模式对标停车后,列车未施加保压制动发生后溜,司机发现后立即施加快速制动,列车停止后溜并停稳。该情况存在严重的行车安全隐患,若司机未能及时发现后溜并施加制动,列车后溜可能会导致司机夹伤。

本文从网络控制逻辑及制动控制逻辑方面着手,分别对网络通信故障及车辆后溜原因进行分析,并提出整改措施,有效避免了列车网络瘫痪及后溜的风险,提高了列车运行的安全性。

1事件经过

17:21,司机在谢村上行出站后报:驾驶端07A043车车辆屏黑屏,3s后自动恢复,列车运行正常。

17:32,该车在员岗上行进站前车辆屏出现网络通信故障信息后黑屏并自动停车,行调组织司机以PM模式进站对标。

17:33:03,司机PM对标停车,气制动施加灯未亮,司机起身开左侧司机室侧门。

17:33:12,司机发现列车后溜,立即施加快速制动,气制动施加灯亮,列车停止后溜并停稳。

2网络通信故障分析

2.1原因分析

广州地铁7号线列车MVB网络采用通信线路双通道冗余设计,当某一路通信线路出现故障时,系统可以自动切换到另一路通信线路。对于关键的车辆控制模块VCMe,由于其主要实现重要的车辆控制、总线管理,因此在整个列车网络中也对VCMe做了热备冗余配置,正常情况下两个VCMe通过底层协议芯片的竞争机制自动选取一个VCMe为总线管理主,另外一个VCMe为备用主,当主VCMe出现故障时,备用VCMe将接管主VCMe的职责,行使所有的总线管理和控制功能。

读取列车故障履历、事件记录仪数据,故障时刻VCM故障记录显示07043044车"A2车VCMe通信故障""DCUVCM生命信号中断"、整车主门控器"EDCU通信故障""HMI通信故障"等列车子设备通信故障,如图1所示。

读取事件记录仪数据,根据A1车1轴制动轴速,判断在17:32:56之前列车处于减速过程,直至列车速度至0,由于网络卡死,列车的综合速度一直处于故障时的列车速度64.2km/h,如图2所示。

事件记录仪显示故障时刻,A1车VCM为主,VCM生命信号与列车综合速度卡死,VCM未进行切换。通过以上数据分析可以确认,两个VCMe模块均处于应用程序停止运行的状态。

出现两个VCM死机故障有以下两种可能:列车控制网络总线干扰、外部原因导致VCM死机。下面将进行逐一排查:

列车控制网络总线干扰与总线通信状态及错帧率相关。使用CRT网络终端仿真软件,检查发现故障时网络状态为A路与B路通信状态OK,且无错帧增加,如图3所示。

用MVB网络协议分析仪采集此时的MVB总线数据如图4所示,可以看出故障时刻两路MVB通道均只有1个错误帧,此时MVB总线状态正常。因此网路总线受到干扰的原因可排除。

由于故障时刻列车控制MVB网络状态正常,列车控制网络拓扑图如图5所示,可看出VCM外部仅与PIDs以太网接口连接,故使用CRT软件对VCM以太网任务进行监视。

对VCM以太网任务进行监视,监视结果显示VCM设备端以太网接口处于不断重启状态,如图6所示。

观察与VCM相连接的PIDs交换机对应网口的通信指示灯状态处于频闪状态,断开VCMe与PIDs交换机连接,通信故障消失。初步分析为PIDs以太网交换机与VCMe模块以太网数据传输异常。

为了验证是否是以太网通信数据异常导致MVB通信故障,进行了下面的模拟实验:使用ostinato软件模拟广播数据帧,直接将网线连接到VCM模块上,同时对两端的VCM模拟大量数据通信。流量最大时设置为5万包/s,持续时间最长20min。期间出现大量打印信息"0xbc3b20(tNetTask):m5200FecPhyInitcheckcab1econnection",如图7所示。

根据上述数据和现象分析,出现通信故障的原因确认为PIDs与VCM模块以太网数据传输异常导致模块CPU负荷过大从而程序停止运行。

2.2防范措施

(1)临时将列车两端VCMe(x9)与PIDs交换机通信的网线断开,避免以太网通信数据异常,保障正常运营:

(2)后续PIDs对VCMe接入交换机的端口进行入口和出口的带宽限制。

3后溜原因分析

3.1数据分析

读取后溜时刻制动数据,如图8所示,在17:33:02时牵引指令线失电,17:33:10时施加快速制动。在此期间,车辆在前5s处于惰行至停车,后3s处于后溜,后溜时产生约0.22km/h的速度。

3.2原因分析

为防止列车静止时不在坡道上溜车,广州地铁7号线列车设计有保持制动功能,在网络模式和临时模式下,保持制动的大小为80%最大常用制动力,在紧急牵引模式下,保持制动力大小为45%最大常用制动力。

从解析出来的数据来看,在TCMs通信中断后,BCU判断出了通信失效,随即在10个周期后转入了临时模式。此模式下BCU会根据硬线指令来施加制动。通过制动数据可以看出,后溜时刻制动缸压力为0,说明保持制动未施加。因此车辆后溜的原因在于保持制动未施加,车辆在坡道上由于重力原因发生溜动。

保持制动施加为BCU自行判断,其施加的作用域如下:列车综合速度小于10km/h且拖车速度小于10km/h且本架速度小于5km/h。

注释:

(1)本架速度:1个转向架有2根轴2个轴端速度传感,根据两根轴速最大值输出本转向架速度。

(2)拖车速度取拖车1架转向架速度。

(3)列车综合速度:列车综合速度由列车网络计算后传给制动系统,计算方法采用冒泡算法,网络对BCU上传的2个拖车的8个轴速进行有效判断,剔除无效值后,对剩下的有效值进行排序,取次大值和次小值,并计算去除最大值和最小值后的平均值。根据工况对速度进行选择,牵引时取次小值,制动时取次大值,惰行时取平均值。

保持制动施加条件如下:

(1)网络模式下,网络牵引指令无效且本架速度低于0.5km/h自动施加。

(2)紧急牵引或临时模式(网络中断但未进入紧急牵引模式,发生溜车时处于该模式)下,硬线牵引指令无效,且本架速度小于0.5km/h自动施加。

由于列车综合速度的变量在突然失去网络信号后没有清零,造成BCU接收到的列车综合速度一直保持在通信故障前的64.2km/h,即一直处于10km/h以上的情况,使得无法进入保持制动施加的逻辑判断,造成了保持制动未施加。

3.3后溜保护逻辑

后溜保护触发逻辑为网络模式下列车进行车辆保护的一个措施,其通过如下逻辑对车辆后溜进行判断,当检测到车辆后溜之后,由网络发出车辆的紧急制动:本车4个电机转向同时与司控器方向不一致判断为车辆后溜,当车速超过1km/h且超过200ms或后溜超过0.4m或后溜持续10s,则由网络发出紧急制动。

而本次事件后溜时刻,网络处于故障状态,无法由网络出发车辆的紧急制动,因此后溜保护功能在此工况下无法进行列车保护。

3.4防范措施

在网络通信故障情况时,列车在保持制动未施加且无后溜保护的情况下,存在严重的行车安全隐患。

针对上述逻辑分析,可以对网络故障后未清除列车综合速度的这个问题进行修正,即当通信丢失以后,制动系统清除保存的列车综合速度值,不再考虑列车综合速度,保留根据本CAN网段参考速度(拖车速度)和本架速度来进行保持施加判断。即临时模式下的保持制动作用域修改为与紧急牵引模式下一致:拖车速度小于10km/h且本架速度小于5km/h才会有保持制动。

4结语

为保证列车运行的安全性,现今的列车网络系统在设计上已具备冗余功能,但通过本次网络通信故障可看出,网络上外挂的其他设备产生的数据仍会对网络系统本身造成干扰甚至导致瘫痪,因此提高VCM的数据处理能力,或者增加对数据进行筛选的功能,是今后列车网络系统设计可优化的地方。

通过本次车辆后溜事件,也可看出制动系统最初的设计中,保持制动施加逻辑并不严谨,未考虑到车辆网络通信故障后,列车综合速度清零的问题。现对施加逻辑进行了优化,经现场验证,已经消除了网络通信故障情况下车辆后溜的隐患,提高了列车运行的安全性,可供国内同行借鉴。