引言

廣州地鐵7號(hào)線列車制動(dòng)系統(tǒng)采用北京縱橫機(jī)電提供的國(guó)產(chǎn)架控系統(tǒng),列車控制及診斷系統(tǒng)采用時(shí)代電氣研發(fā)的列車分布式網(wǎng)絡(luò)通信和控制系統(tǒng)(DTECs平臺(tái))。二者的配合應(yīng)用為在廣州地鐵線網(wǎng)內(nèi)首次采用,當(dāng)在某些特殊情況下,會(huì)出現(xiàn)邏輯設(shè)定不嚴(yán)謹(jǐn)?shù)那闆r。

2019年1月7日,07043044車正線進(jìn)站前出現(xiàn)網(wǎng)絡(luò)通信故障,車輛屏黑屏,司機(jī)PM模式對(duì)標(biāo)停車后,列車未施加保壓制動(dòng)發(fā)生后溜,司機(jī)發(fā)現(xiàn)后立即施加快速制動(dòng),列車停止后溜并停穩(wěn)。該情況存在嚴(yán)重的行車安全隱患,若司機(jī)未能及時(shí)發(fā)現(xiàn)后溜并施加制動(dòng),列車后溜可能會(huì)導(dǎo)致司機(jī)夾傷。

本文從網(wǎng)絡(luò)控制邏輯及制動(dòng)控制邏輯方面著手,分別對(duì)網(wǎng)絡(luò)通信故障及車輛后溜原因進(jìn)行分析,并提出整改措施,有效避免了列車網(wǎng)絡(luò)癱瘓及后溜的風(fēng)險(xiǎn),提高了列車運(yùn)行的安全性。

1事件經(jīng)過

17:21,司機(jī)在謝村上行出站后報(bào):駕駛端07A043車車輛屏黑屏,3s后自動(dòng)恢復(fù),列車運(yùn)行正常。

17:32,該車在員崗上行進(jìn)站前車輛屏出現(xiàn)網(wǎng)絡(luò)通信故障信息后黑屏并自動(dòng)停車,行調(diào)組織司機(jī)以PM模式進(jìn)站對(duì)標(biāo)。

17:33:03,司機(jī)PM對(duì)標(biāo)停車,氣制動(dòng)施加燈未亮,司機(jī)起身開左側(cè)司機(jī)室側(cè)門。

17:33:12,司機(jī)發(fā)現(xiàn)列車后溜,立即施加快速制動(dòng),氣制動(dòng)施加燈亮,列車停止后溜并停穩(wěn)。

2網(wǎng)絡(luò)通信故障分析

2.1原因分析

廣州地鐵7號(hào)線列車MVB網(wǎng)絡(luò)采用通信線路雙通道冗余設(shè)計(jì),當(dāng)某一路通信線路出現(xiàn)故障時(shí),系統(tǒng)可以自動(dòng)切換到另一路通信線路。對(duì)于關(guān)鍵的車輛控制模塊VCMe,由于其主要實(shí)現(xiàn)重要的車輛控制、總線管理,因此在整個(gè)列車網(wǎng)絡(luò)中也對(duì)VCMe做了熱備冗余配置,正常情況下兩個(gè)VCMe通過底層協(xié)議芯片的競(jìng)爭(zhēng)機(jī)制自動(dòng)選取一個(gè)VCMe為總線管理主,另外一個(gè)VCMe為備用主,當(dāng)主VCMe出現(xiàn)故障時(shí),備用VCMe將接管主VCMe的職責(zé),行使所有的總線管理和控制功能。

讀取列車故障履歷、事件記錄儀數(shù)據(jù),故障時(shí)刻VCM故障記錄顯示07043044車"A2車VCMe通信故障""DCUVCM生命信號(hào)中斷"、整車主門控器"EDCU通信故障""HMI通信故障"等列車子設(shè)備通信故障,如圖1所示。

讀取事件記錄儀數(shù)據(jù),根據(jù)A1車1軸制動(dòng)軸速,判斷在17:32:56之前列車處于減速過程,直至列車速度至0,由于網(wǎng)絡(luò)卡死,列車的綜合速度一直處于故障時(shí)的列車速度64.2km/h,如圖2所示。

事件記錄儀顯示故障時(shí)刻,A1車VCM為主,VCM生命信號(hào)與列車綜合速度卡死,VCM未進(jìn)行切換。通過以上數(shù)據(jù)分析可以確認(rèn),兩個(gè)VCMe模塊均處于應(yīng)用程序停止運(yùn)行的狀態(tài)。

出現(xiàn)兩個(gè)VCM死機(jī)故障有以下兩種可能:列車控制網(wǎng)絡(luò)總線干擾、外部原因?qū)е耉CM死機(jī)。下面將進(jìn)行逐一排查:

列車控制網(wǎng)絡(luò)總線干擾與總線通信狀態(tài)及錯(cuò)幀率相關(guān)。使用CRT網(wǎng)絡(luò)終端仿真軟件,檢查發(fā)現(xiàn)故障時(shí)網(wǎng)絡(luò)狀態(tài)為A路與B路通信狀態(tài)OK,且無錯(cuò)幀增加,如圖3所示。

用MVB網(wǎng)絡(luò)協(xié)議分析儀采集此時(shí)的MVB總線數(shù)據(jù)如圖4所示,可以看出故障時(shí)刻兩路MVB通道均只有1個(gè)錯(cuò)誤幀,此時(shí)MVB總線狀態(tài)正常。因此網(wǎng)路總線受到干擾的原因可排除。

由于故障時(shí)刻列車控制MVB網(wǎng)絡(luò)狀態(tài)正常,列車控制網(wǎng)絡(luò)拓?fù)鋱D如圖5所示,可看出VCM外部?jī)H與PIDs以太網(wǎng)接口連接,故使用CRT軟件對(duì)VCM以太網(wǎng)任務(wù)進(jìn)行監(jiān)視。

對(duì)VCM以太網(wǎng)任務(wù)進(jìn)行監(jiān)視,監(jiān)視結(jié)果顯示VCM設(shè)備端以太網(wǎng)接口處于不斷重啟狀態(tài),如圖6所示。

觀察與VCM相連接的PIDs交換機(jī)對(duì)應(yīng)網(wǎng)口的通信指示燈狀態(tài)處于頻閃狀態(tài),斷開VCMe與PIDs交換機(jī)連接,通信故障消失。初步分析為PIDs以太網(wǎng)交換機(jī)與VCMe模塊以太網(wǎng)數(shù)據(jù)傳輸異常。

為了驗(yàn)證是否是以太網(wǎng)通信數(shù)據(jù)異常導(dǎo)致MVB通信故障,進(jìn)行了下面的模擬實(shí)驗(yàn):使用ostinato軟件模擬廣播數(shù)據(jù)幀,直接將網(wǎng)線連接到VCM模塊上,同時(shí)對(duì)兩端的VCM模擬大量數(shù)據(jù)通信。流量最大時(shí)設(shè)置為5萬包/s,持續(xù)時(shí)間最長(zhǎng)20min。期間出現(xiàn)大量打印信息"0xbc3b20(tNetTask):m5200FecPhyInitcheckcab1econnection",如圖7所示。

根據(jù)上述數(shù)據(jù)和現(xiàn)象分析,出現(xiàn)通信故障的原因確認(rèn)為PIDs與VCM模塊以太網(wǎng)數(shù)據(jù)傳輸異常導(dǎo)致模塊CPU負(fù)荷過大從而程序停止運(yùn)行。

2.2防范措施

(1)臨時(shí)將列車兩端VCMe(x9)與PIDs交換機(jī)通信的網(wǎng)線斷開,避免以太網(wǎng)通信數(shù)據(jù)異常,保障正常運(yùn)營(yíng):

(2)后續(xù)PIDs對(duì)VCMe接入交換機(jī)的端口進(jìn)行入口和出口的帶寬限制。

3后溜原因分析

3.1數(shù)據(jù)分析

讀取后溜時(shí)刻制動(dòng)數(shù)據(jù),如圖8所示,在17:33:02時(shí)牽引指令線失電,17:33:10時(shí)施加快速制動(dòng)。在此期間,車輛在前5s處于惰行至停車,后3s處于后溜,后溜時(shí)產(chǎn)生約0.22km/h的速度。

3.2原因分析

為防止列車靜止時(shí)不在坡道上溜車,廣州地鐵7號(hào)線列車設(shè)計(jì)有保持制動(dòng)功能,在網(wǎng)絡(luò)模式和臨時(shí)模式下,保持制動(dòng)的大小為80%最大常用制動(dòng)力,在緊急牽引模式下,保持制動(dòng)力大小為45%最大常用制動(dòng)力。

從解析出來的數(shù)據(jù)來看,在TCMs通信中斷后,BCU判斷出了通信失效,隨即在10個(gè)周期后轉(zhuǎn)入了臨時(shí)模式。此模式下BCU會(huì)根據(jù)硬線指令來施加制動(dòng)。通過制動(dòng)數(shù)據(jù)可以看出,后溜時(shí)刻制動(dòng)缸壓力為0,說明保持制動(dòng)未施加。因此車輛后溜的原因在于保持制動(dòng)未施加,車輛在坡道上由于重力原因發(fā)生溜動(dòng)。

保持制動(dòng)施加為BCU自行判斷,其施加的作用域如下:列車綜合速度小于10km/h且拖車速度小于10km/h且本架速度小于5km/h。

注釋:

(1)本架速度:1個(gè)轉(zhuǎn)向架有2根軸2個(gè)軸端速度傳感,根據(jù)兩根軸速最大值輸出本轉(zhuǎn)向架速度。

(2)拖車速度取拖車1架轉(zhuǎn)向架速度。

(3)列車綜合速度:列車綜合速度由列車網(wǎng)絡(luò)計(jì)算后傳給制動(dòng)系統(tǒng),計(jì)算方法采用冒泡算法,網(wǎng)絡(luò)對(duì)BCU上傳的2個(gè)拖車的8個(gè)軸速進(jìn)行有效判斷,剔除無效值后,對(duì)剩下的有效值進(jìn)行排序,取次大值和次小值,并計(jì)算去除最大值和最小值后的平均值。根據(jù)工況對(duì)速度進(jìn)行選擇,牽引時(shí)取次小值,制動(dòng)時(shí)取次大值,惰行時(shí)取平均值。

保持制動(dòng)施加條件如下:

(1)網(wǎng)絡(luò)模式下,網(wǎng)絡(luò)牽引指令無效且本架速度低于0.5km/h自動(dòng)施加。

(2)緊急牽引或臨時(shí)模式(網(wǎng)絡(luò)中斷但未進(jìn)入緊急牽引模式,發(fā)生溜車時(shí)處于該模式)下,硬線牽引指令無效,且本架速度小于0.5km/h自動(dòng)施加。

由于列車綜合速度的變量在突然失去網(wǎng)絡(luò)信號(hào)后沒有清零,造成BCU接收到的列車綜合速度一直保持在通信故障前的64.2km/h,即一直處于10km/h以上的情況,使得無法進(jìn)入保持制動(dòng)施加的邏輯判斷,造成了保持制動(dòng)未施加。

3.3后溜保護(hù)邏輯

后溜保護(hù)觸發(fā)邏輯為網(wǎng)絡(luò)模式下列車進(jìn)行車輛保護(hù)的一個(gè)措施,其通過如下邏輯對(duì)車輛后溜進(jìn)行判斷,當(dāng)檢測(cè)到車輛后溜之后,由網(wǎng)絡(luò)發(fā)出車輛的緊急制動(dòng):本車4個(gè)電機(jī)轉(zhuǎn)向同時(shí)與司控器方向不一致判斷為車輛后溜,當(dāng)車速超過1km/h且超過200ms或后溜超過0.4m或后溜持續(xù)10s,則由網(wǎng)絡(luò)發(fā)出緊急制動(dòng)。

而本次事件后溜時(shí)刻,網(wǎng)絡(luò)處于故障狀態(tài),無法由網(wǎng)絡(luò)出發(fā)車輛的緊急制動(dòng),因此后溜保護(hù)功能在此工況下無法進(jìn)行列車保護(hù)。

3.4防范措施

在網(wǎng)絡(luò)通信故障情況時(shí),列車在保持制動(dòng)未施加且無后溜保護(hù)的情況下,存在嚴(yán)重的行車安全隱患。

針對(duì)上述邏輯分析,可以對(duì)網(wǎng)絡(luò)故障后未清除列車綜合速度的這個(gè)問題進(jìn)行修正,即當(dāng)通信丟失以后,制動(dòng)系統(tǒng)清除保存的列車綜合速度值,不再考慮列車綜合速度,保留根據(jù)本CAN網(wǎng)段參考速度(拖車速度)和本架速度來進(jìn)行保持施加判斷。即臨時(shí)模式下的保持制動(dòng)作用域修改為與緊急牽引模式下一致:拖車速度小于10km/h且本架速度小于5km/h才會(huì)有保持制動(dòng)。

4結(jié)語(yǔ)

為保證列車運(yùn)行的安全性,現(xiàn)今的列車網(wǎng)絡(luò)系統(tǒng)在設(shè)計(jì)上已具備冗余功能,但通過本次網(wǎng)絡(luò)通信故障可看出,網(wǎng)絡(luò)上外掛的其他設(shè)備產(chǎn)生的數(shù)據(jù)仍會(huì)對(duì)網(wǎng)絡(luò)系統(tǒng)本身造成干擾甚至導(dǎo)致癱瘓,因此提高VCM的數(shù)據(jù)處理能力,或者增加對(duì)數(shù)據(jù)進(jìn)行篩選的功能,是今后列車網(wǎng)絡(luò)系統(tǒng)設(shè)計(jì)可優(yōu)化的地方。

通過本次車輛后溜事件,也可看出制動(dòng)系統(tǒng)最初的設(shè)計(jì)中,保持制動(dòng)施加邏輯并不嚴(yán)謹(jǐn),未考慮到車輛網(wǎng)絡(luò)通信故障后,列車綜合速度清零的問題。現(xiàn)對(duì)施加邏輯進(jìn)行了優(yōu)化,經(jīng)現(xiàn)場(chǎng)驗(yàn)證,已經(jīng)消除了網(wǎng)絡(luò)通信故障情況下車輛后溜的隱患,提高了列車運(yùn)行的安全性,可供國(guó)內(nèi)同行借鑒。