城軌車輛全列設備網絡通信異常原因探究

唐亞峰，雒錄錄，趙煜杰

（中車成都機車車輛有限公司，四川成都 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）報告工作狀態，另一方面接收控制中心下達的控制命令。健康的網絡系統對于列車的安全、可靠運行至關重要，部分車輛相關設備的軟、硬件變更直接影響車輛網絡系統的可靠與否，變更過程及結果的卡控直接決定變更后網絡系統的可靠性，因此變更中的溝通及試驗驗證尤為重要，運營中的車輛直接面對乘客，更加需要專業人員的層層把關，提高產品可靠性。