楊 濤
(上海地鐵維護保障有限公司,上海200003)
上海地鐵的快速發展及列車運營可靠性要求的提高,需要車輛檢修人員第一時間獲知運營列車的實時信息。通過該信息的獲得,可在列車發生故障后,及時通知車輛巡檢人員上車確認列車狀態,提高正線列車的故障處置效率,切實可行地確保列車的正常運營。
上海地鐵10號線列車按照無人駕駛設計,控制單元和各子系統都具備故障及狀態的本地儲存功能。列車運營時,MPU(列車主處理器)能將所接收到的列車控制單元和各子系統的實時信息傳輸至地面,為車輛檢修人員第一時間獲知運營列車的狀態創造了條件。
列車故障信息和狀態信息以代碼的形式傳輸至地面接收裝置后,需要搭建一個包含必要軟件的平臺,對所能接收到的信息代碼進行處理、轉換,才能供車輛駐勤人員進行查看。如何獲取、顯示列車的實時信息,并加以充分應用,以滿足列車運營可靠性的高要求,成為亟需解決的問題。
圖1 列車MVB網絡構架
在上海地鐵10號線列車上,MPU作為列車主處理器通過MVB網絡(多功能車輛總線)控制,如圖1所示,采用 WEB_EVT協議,在16ms周期內依次循環連接在MVB網絡上的列車各子系統控制單元,向各子系統發出指令,并負責實時接收各子系統的故障信息和狀態信息。在獲得列車信息的同時,MPU又將所獲取的信息通過MVB網絡實時傳輸至車載ATC系統(列車自動控制系統)。車載ATC系統在接收到列車信息后,負責將所獲得的信息經過帶寬為6M的ATC通道,以無線通信方式傳輸至地面軌旁接收裝置。地面軌旁接收裝置負責將所接收到的信息經WRF中心交換機,通過以太網傳輸至調度中心,并接入終端服務器,最終在終端服務器屏幕上實時顯示所上傳的列車信息。信息的傳輸途徑如圖2所示。
由于列車的信息量大,且所上傳的信息必須保證車輛駐勤人員能準確、快速地判別列車的狀態,因此需要對車載ATC系統所能上傳的列車控制單元和子系統的實時信息進行分析、匯總和評估。依據“重要的、對維持列車正常運營有影響”的篩選原則,將列車故障信息、相應的故障環境信息和列車狀態信息所對應的代碼全部篩選出來后,由車載ATC系統進行上傳。表1是所篩選出來的代碼范例。
圖2 信息傳輸途徑
表1 上傳代碼范例
在將信息代碼轉換的過程中,由于所傳輸的信息量較大,列車數較多,若僅僅簡單地以文字的形式進行顯示,將不利于車輛駐勤人員獲知、查詢列車實時信息。因此,需要對信息代碼的顯示形式進行圖形化設計。為了便于車輛駐勤人員能在較短時間內熟悉界面,準確、便捷地獲知列車實時信息,通過在列車上模擬車輛方與信號方接口定義的所能傳輸的各個信息代碼,查看并借鑒車輛駐勤人員所熟悉的司機室顯示屏準備頁面上的圖標顯示,來確定相應信息代碼的圖標;同時根據司機室顯示屏準備頁面上的圖標分布,對平臺界面上的各個圖標進行布局,如圖3所示。由于平臺界面空間有限,同時部分信息代碼無法通過圖標的形式進行顯示,因此在設計平臺界面的過程中,搭建了“當前實時報警列表”,將所有列車實時發生的所有故障和狀態的具體描述以報警語句的形式進行顯示。另外,為了便于車輛駐勤人員查詢列車信息,還搭建了“歷史報警列表”,可查詢包括“當前實時報警列表”中的信息以及更早之前的列車信息??紤]到車輛駐勤人員獲知報警信息的時效性,就需要將列車狀態和出現的故障以醒目的形式進行顯示,因此在平臺界面上搭建了“車輛信息列表”。
列車實時信息傳輸平臺界面分為“當前圖形顯示”和“歷史報警列表”2個部分。
(1)“當前圖形顯示”菜單包括3部分:1)信息圖形化界面(圖3),包括當前查看列車部分故障的圖形顯示,由于界面空間有限,不是所有故障都可用圖形化表示;2)當前實時報警列表,如圖4所示,該列表共可顯示50條,包括所有列車實時發生的所有故障的具體描述;3)車輛信息列表,表示列車發生故障時的實時報警,顯示了列車運營或非運營情況(圖3左側)。列表中根據字體的不同顏色來區分代表列車發出報警信息、故障是否確認、是否始終存在等,操作人員根據不同的提示來點擊相關列車號,可查看更為詳細的信息。同時為方便車輛駐勤人員了解列車運營信息,將列車號后的車次號用來表示列車運營與否,車次號由調度方給出,“0”代表列車未上線運營,非“0”代表列車運營中。
(2)“歷史報警列表”菜單,可查詢“當前實時報警列表”以及更早之前的故障信息(圖5)。
為了充分應用所獲得的列車實時信息,需要制訂對應的管理辦法。列車實時信息傳輸平臺的管理主要分為信息處置總則和平臺日常維護兩個部分。
圖3 平臺界面
圖4 當前實時報警列表
圖5 歷史報警列表
車輛駐勤人員通過列車實時信息傳輸平臺獲得列車實時信息后,根據信息的類別和對列車運營影響的程度,來決定是否通知相關車輛人員登車檢查及與其他單位、部門溝通解決。對于列車狀態信息,可以作為獲知列車信息的形式進行處理,但對于異常的狀態信息,需要結合司機回復、車載視屏監控系統,并安排巡檢人員上車確認列車的狀態。對于列車故障信息,需要根據風險等級,即結合故障嚴重程度和出現頻率,分情況進行處理,如表2所示,并開具故障報單,在駐勤日志上做好交班記錄。
其中,Ⅰ級故障為需要列車清客救援或存在重大安全隱患,Ⅱ級故障為需要列車運行至終點站后退出運營,Ⅲ級故障為列車能夠運行至當天運營結束,Ⅳ級故障為不影響列車運營。風險等級為R1時,處理方式為向調度建議該列車立刻進行清客作業,必要時實施救援,并安排巡檢人員就近上車保駕;風險等級為R2時,處理方式為向調度建議該列車運行至終點站后退出運營,并安排巡檢人員就近上車保駕;風險等級為R3時,處理方式為安排巡檢人員就近上車確認,按照相關應急預案進行處置,若故障為瞬態故障或上車時列車狀態正常,需要跟車2~3站,確認故障未再重現后,方可下車;風險等級為R4時,做好記錄,列車運營結束后回庫進行確認和處理。
表2 風險等級
車輛人員在檢修作業時,按規程要求檢查每列車的MVB網絡工作情況,確保列車各子系統的故障信息和狀態信息能夠傳輸順暢;同時車輛人員還要負責該平臺所在的主機工作正常,每晚運營結束后,進行重啟主機的維護保養工作,并負責該平臺上日志的下載。
通過列車實時信息傳輸平臺的應用,最大程度上避免了列車故障對運營造成大間隔的事件發生。該平臺啟用后,2013年上海地鐵10號線在運營時發生的清客、救援等事故的數量較2012年同期大大降低。2013年7月23號,1015車龍溪路站上行平臺上顯示車門釋放故障,駐勤人員獲得該故障信息后,建議調度人員將該列車運營至終點站后退出運營,并就近通知巡檢人員上車查看列車開關門狀態,通過簡單的操作,保駕至終點站,避免了1015車清客事件的發生。2013年8月2號,1027車新江灣城站折返時由于兩端司機同時轉動鑰匙,導致出現“兩端司機室同時被激活”的故障。車輛駐勤人員通過平臺上的圖標顯示得到該故障信息后,通知巡檢人員在最短時間內趕到列車上,通過切復DDUCB等簡單操作,處理了該故障,并保駕至終點站后退出運營,避免了1027車救援事件的發生。
通過列車實時信息傳輸平臺的應用,解決了列車運行過程中實時信息監測難的問題,提高了正線列車的故障處置效率。但是,列車信息無線傳輸系統還有待進一步優化,主要包括以下4個方面:
(1)根據實時信息傳輸平臺應用情況,開始著手研究、制訂信息傳輸系統的相關技術指標及標準,為既有其他線路和后續新線推廣提供依據。
(2)根據駐勤實際應用,結合列車日常運營及維護,進一步優化實時信息傳輸平臺的管理辦法及流程,形成一套切實可行的管理體系。
(3)對實時信息傳輸平臺進行二次開發,使得列車實時信息可多點傳輸。當正線列車發生故障時,方便技術人員及更多的人查看,便于指導巡檢人員進行處置。
(4)待上海地鐵10號線無人駕駛開通運營后,還需要研究并驗證增加更多的信息代碼,從而更有效地獲得列車上的實時信息。
[1]上海地鐵10號線連接到MVB上的裝置通用接口要求規范[Z]
[2]上海地鐵10號線列車自動控制系統MVB接口描述[Z]
[3]李剛,申萍.列車故障信息無線傳輸的實現[J].現代電子技術,2004(19)
[4]馬小玲.列車運行控制系統中地—車信息傳輸方式的探討[J].鐵路通信信號工程技術,2002(2)
[5]黃國輝,余立建.基于GPS/GIS的列車實時監控系統設計[J].鐵路計算機應用,2008(9)