楊 濤

（上海地鐵維護(hù)保障有限公司，上海200003）

1 平臺(tái)開發(fā)背景

上海地鐵的快速發(fā)展及列車運(yùn)營(yíng)可靠性要求的提高，需要車輛檢修人員第一時(shí)間獲知運(yùn)營(yíng)列車的實(shí)時(shí)信息。通過該信息的獲得，可在列車發(fā)生故障后，及時(shí)通知車輛巡檢人員上車確認(rèn)列車狀態(tài)，提高正線列車的故障處置效率，切實(shí)可行地確保列車的正常運(yùn)營(yíng)。

上海地鐵10號(hào)線列車按照無人駕駛設(shè)計(jì)，控制單元和各子系統(tǒng)都具備故障及狀態(tài)的本地儲(chǔ)存功能。列車運(yùn)營(yíng)時(shí)，MPU（列車主處理器）能將所接收到的列車控制單元和各子系統(tǒng)的實(shí)時(shí)信息傳輸至地面，為車輛檢修人員第一時(shí)間獲知運(yùn)營(yíng)列車的狀態(tài)創(chuàng)造了條件。

列車故障信息和狀態(tài)信息以代碼的形式傳輸至地面接收裝置后，需要搭建一個(gè)包含必要軟件的平臺(tái)，對(duì)所能接收到的信息代碼進(jìn)行處理、轉(zhuǎn)換，才能供車輛駐勤人員進(jìn)行查看。如何獲取、顯示列車的實(shí)時(shí)信息，并加以充分應(yīng)用，以滿足列車運(yùn)營(yíng)可靠性的高要求，成為亟需解決的問題。

圖1 列車MVB網(wǎng)絡(luò)構(gòu)架

2 平臺(tái)開發(fā)

2．1 信息傳輸

在上海地鐵10號(hào)線列車上，MPU作為列車主處理器通過MVB網(wǎng)絡(luò)（多功能車輛總線）控制，如圖1所示，采用 WEB＿EVT協(xié)議，在16ms周期內(nèi)依次循環(huán)連接在MVB網(wǎng)絡(luò)上的列車各子系統(tǒng)控制單元，向各子系統(tǒng)發(fā)出指令，并負(fù)責(zé)實(shí)時(shí)接收各子系統(tǒng)的故障信息和狀態(tài)信息。在獲得列車信息的同時(shí)，MPU又將所獲取的信息通過MVB網(wǎng)絡(luò)實(shí)時(shí)傳輸至車載ATC系統(tǒng)（列車自動(dòng)控制系統(tǒng)）。車載ATC系統(tǒng)在接收到列車信息后，負(fù)責(zé)將所獲得的信息經(jīng)過帶寬為6M的ATC通道，以無線通信方式傳輸至地面軌旁接收裝置。地面軌旁接收裝置負(fù)責(zé)將所接收到的信息經(jīng)WRF中心交換機(jī)，通過以太網(wǎng)傳輸至調(diào)度中心，并接入終端服務(wù)器，最終在終端服務(wù)器屏幕上實(shí)時(shí)顯示所上傳的列車信息。信息的傳輸途徑如圖2所示。

2．2 信息篩選

由于列車的信息量大，且所上傳的信息必須保證車輛駐勤人員能準(zhǔn)確、快速地判別列車的狀態(tài)，因此需要對(duì)車載ATC系統(tǒng)所能上傳的列車控制單元和子系統(tǒng)的實(shí)時(shí)信息進(jìn)行分析、匯總和評(píng)估。依據(jù)“重要的、對(duì)維持列車正常運(yùn)營(yíng)有影響”的篩選原則，將列車故障信息、相應(yīng)的故障環(huán)境信息和列車狀態(tài)信息所對(duì)應(yīng)的代碼全部篩選出來后，由車載ATC系統(tǒng)進(jìn)行上傳。表1是所篩選出來的代碼范例。

圖2 信息傳輸途徑

表1 上傳代碼范例

2．3 界面開發(fā)

在將信息代碼轉(zhuǎn)換的過程中，由于所傳輸?shù)男畔⒘枯^大，列車數(shù)較多，若僅僅簡(jiǎn)單地以文字的形式進(jìn)行顯示，將不利于車輛駐勤人員獲知、查詢列車實(shí)時(shí)信息。因此，需要對(duì)信息代碼的顯示形式進(jìn)行圖形化設(shè)計(jì)。為了便于車輛駐勤人員能在較短時(shí)間內(nèi)熟悉界面，準(zhǔn)確、便捷地獲知列車實(shí)時(shí)信息，通過在列車上模擬車輛方與信號(hào)方接口定義的所能傳輸?shù)母鱾€(gè)信息代碼，查看并借鑒車輛駐勤人員所熟悉的司機(jī)室顯示屏準(zhǔn)備頁面上的圖標(biāo)顯示，來確定相應(yīng)信息代碼的圖標(biāo)；同時(shí)根據(jù)司機(jī)室顯示屏準(zhǔn)備頁面上的圖標(biāo)分布，對(duì)平臺(tái)界面上的各個(gè)圖標(biāo)進(jìn)行布局，如圖3所示。由于平臺(tái)界面空間有限，同時(shí)部分信息代碼無法通過圖標(biāo)的形式進(jìn)行顯示，因此在設(shè)計(jì)平臺(tái)界面的過程中，搭建了“當(dāng)前實(shí)時(shí)報(bào)警列表”，將所有列車實(shí)時(shí)發(fā)生的所有故障和狀態(tài)的具體描述以報(bào)警語句的形式進(jìn)行顯示。另外，為了便于車輛駐勤人員查詢列車信息，還搭建了“歷史報(bào)警列表”，可查詢包括“當(dāng)前實(shí)時(shí)報(bào)警列表”中的信息以及更早之前的列車信息?？紤]到車輛駐勤人員獲知報(bào)警信息的時(shí)效性，就需要將列車狀態(tài)和出現(xiàn)的故障以醒目的形式進(jìn)行顯示，因此在平臺(tái)界面上搭建了“車輛信息列表”。

2．4 界面介紹

列車實(shí)時(shí)信息傳輸平臺(tái)界面分為“當(dāng)前圖形顯示”和“歷史報(bào)警列表”2個(gè)部分。

（1）“當(dāng)前圖形顯示”菜單包括3部分：1）信息圖形化界面（圖3），包括當(dāng)前查看列車部分故障的圖形顯示，由于界面空間有限，不是所有故障都可用圖形化表示；2）當(dāng)前實(shí)時(shí)報(bào)警列表，如圖4所示，該列表共可顯示50條，包括所有列車實(shí)時(shí)發(fā)生的所有故障的具體描述；3）車輛信息列表，表示列車發(fā)生故障時(shí)的實(shí)時(shí)報(bào)警，顯示了列車運(yùn)營(yíng)或非運(yùn)營(yíng)情況（圖3左側(cè)）。列表中根據(jù)字體的不同顏色來區(qū)分代表列車發(fā)出報(bào)警信息、故障是否確認(rèn)、是否始終存在等，操作人員根據(jù)不同的提示來點(diǎn)擊相關(guān)列車號(hào)，可查看更為詳細(xì)的信息。同時(shí)為方便車輛駐勤人員了解列車運(yùn)營(yíng)信息，將列車號(hào)后的車次號(hào)用來表示列車運(yùn)營(yíng)與否，車次號(hào)由調(diào)度方給出，“0”代表列車未上線運(yùn)營(yíng)，非“0”代表列車運(yùn)營(yíng)中。

（2）“歷史報(bào)警列表”菜單，可查詢“當(dāng)前實(shí)時(shí)報(bào)警列表”以及更早之前的故障信息（圖5）。

3 應(yīng)用管理

為了充分應(yīng)用所獲得的列車實(shí)時(shí)信息，需要制訂對(duì)應(yīng)的管理辦法。列車實(shí)時(shí)信息傳輸平臺(tái)的管理主要分為信息處置總則和平臺(tái)日常維護(hù)兩個(gè)部分。

圖3 平臺(tái)界面

圖4 當(dāng)前實(shí)時(shí)報(bào)警列表

圖5 歷史報(bào)警列表

3．1 信息處置

車輛駐勤人員通過列車實(shí)時(shí)信息傳輸平臺(tái)獲得列車實(shí)時(shí)信息后，根據(jù)信息的類別和對(duì)列車運(yùn)營(yíng)影響的程度，來決定是否通知相關(guān)車輛人員登車檢查及與其他單位、部門溝通解決。對(duì)于列車狀態(tài)信息，可以作為獲知列車信息的形式進(jìn)行處理，但對(duì)于異常的狀態(tài)信息，需要結(jié)合司機(jī)回復(fù)、車載視屏監(jiān)控系統(tǒng)，并安排巡檢人員上車確認(rèn)列車的狀態(tài)。對(duì)于列車故障信息，需要根據(jù)風(fēng)險(xiǎn)等級(jí)，即結(jié)合故障嚴(yán)重程度和出現(xiàn)頻率，分情況進(jìn)行處理，如表2所示，并開具故障報(bào)單，在駐勤日志上做好交班記錄。

其中，Ⅰ級(jí)故障為需要列車清客救援或存在重大安全隱患，Ⅱ級(jí)故障為需要列車運(yùn)行至終點(diǎn)站后退出運(yùn)營(yíng)，Ⅲ級(jí)故障為列車能夠運(yùn)行至當(dāng)天運(yùn)營(yíng)結(jié)束，Ⅳ級(jí)故障為不影響列車運(yùn)營(yíng)。風(fēng)險(xiǎn)等級(jí)為R1時(shí)，處理方式為向調(diào)度建議該列車立刻進(jìn)行清客作業(yè)，必要時(shí)實(shí)施救援，并安排巡檢人員就近上車保駕；風(fēng)險(xiǎn)等級(jí)為R2時(shí)，處理方式為向調(diào)度建議該列車運(yùn)行至終點(diǎn)站后退出運(yùn)營(yíng)，并安排巡檢人員就近上車保駕；風(fēng)險(xiǎn)等級(jí)為R3時(shí)，處理方式為安排巡檢人員就近上車確認(rèn)，按照相關(guān)應(yīng)急預(yù)案進(jìn)行處置，若故障為瞬態(tài)故障或上車時(shí)列車狀態(tài)正常，需要跟車2～3站，確認(rèn)故障未再重現(xiàn)后，方可下車；風(fēng)險(xiǎn)等級(jí)為R4時(shí)，做好記錄，列車運(yùn)營(yíng)結(jié)束后回庫進(jìn)行確認(rèn)和處理。

表2 風(fēng)險(xiǎn)等級(jí)

3．2 平臺(tái)維護(hù)

車輛人員在檢修作業(yè)時(shí)，按規(guī)程要求檢查每列車的MVB網(wǎng)絡(luò)工作情況，確保列車各子系統(tǒng)的故障信息和狀態(tài)信息能夠傳輸順暢；同時(shí)車輛人員還要負(fù)責(zé)該平臺(tái)所在的主機(jī)工作正常，每晚運(yùn)營(yíng)結(jié)束后，進(jìn)行重啟主機(jī)的維護(hù)保養(yǎng)工作，并負(fù)責(zé)該平臺(tái)上日志的下載。

4 應(yīng)用效果

通過列車實(shí)時(shí)信息傳輸平臺(tái)的應(yīng)用，最大程度上避免了列車故障對(duì)運(yùn)營(yíng)造成大間隔的事件發(fā)生。該平臺(tái)啟用后，2013年上海地鐵10號(hào)線在運(yùn)營(yíng)時(shí)發(fā)生的清客、救援等事故的數(shù)量較2012年同期大大降低。2013年7月23號(hào)，1015車龍溪路站上行平臺(tái)上顯示車門釋放故障，駐勤人員獲得該故障信息后，建議調(diào)度人員將該列車運(yùn)營(yíng)至終點(diǎn)站后退出運(yùn)營(yíng)，并就近通知巡檢人員上車查看列車開關(guān)門狀態(tài)，通過簡(jiǎn)單的操作，保駕至終點(diǎn)站，避免了1015車清客事件的發(fā)生。2013年8月2號(hào)，1027車新江灣城站折返時(shí)由于兩端司機(jī)同時(shí)轉(zhuǎn)動(dòng)鑰匙，導(dǎo)致出現(xiàn)“兩端司機(jī)室同時(shí)被激活”的故障。車輛駐勤人員通過平臺(tái)上的圖標(biāo)顯示得到該故障信息后，通知巡檢人員在最短時(shí)間內(nèi)趕到列車上，通過切復(fù)DDUCB等簡(jiǎn)單操作，處理了該故障，并保駕至終點(diǎn)站后退出運(yùn)營(yíng)，避免了1027車救援事件的發(fā)生。

5 后期計(jì)劃

通過列車實(shí)時(shí)信息傳輸平臺(tái)的應(yīng)用，解決了列車運(yùn)行過程中實(shí)時(shí)信息監(jiān)測(cè)難的問題，提高了正線列車的故障處置效率。但是，列車信息無線傳輸系統(tǒng)還有待進(jìn)一步優(yōu)化，主要包括以下4個(gè)方面：

（1）根據(jù)實(shí)時(shí)信息傳輸平臺(tái)應(yīng)用情況，開始著手研究、制訂信息傳輸系統(tǒng)的相關(guān)技術(shù)指標(biāo)及標(biāo)準(zhǔn)，為既有其他線路和后續(xù)新線推廣提供依據(jù)。

（2）根據(jù)駐勤實(shí)際應(yīng)用，結(jié)合列車日常運(yùn)營(yíng)及維護(hù)，進(jìn)一步優(yōu)化實(shí)時(shí)信息傳輸平臺(tái)的管理辦法及流程，形成一套切實(shí)可行的管理體系。

（3）對(duì)實(shí)時(shí)信息傳輸平臺(tái)進(jìn)行二次開發(fā)，使得列車實(shí)時(shí)信息可多點(diǎn)傳輸。當(dāng)正線列車發(fā)生故障時(shí)，方便技術(shù)人員及更多的人查看，便于指導(dǎo)巡檢人員進(jìn)行處置。

（4）待上海地鐵10號(hào)線無人駕駛開通運(yùn)營(yíng)后，還需要研究并驗(yàn)證增加更多的信息代碼，從而更有效地獲得列車上的實(shí)時(shí)信息。

［1］上海地鐵10號(hào)線連接到MVB上的裝置通用接口要求規(guī)范［Z］

［2］上海地鐵10號(hào)線列車自動(dòng)控制系統(tǒng)MVB接口描述［Z］

［3］李剛，申萍．列車故障信息無線傳輸?shù)膶?shí)現(xiàn)［J］．現(xiàn)代電子技術(shù)，2004（19）

［4］馬小玲．列車運(yùn)行控制系統(tǒng)中地—車信息傳輸方式的探討［J］．鐵路通信信號(hào)工程技術(shù)，2002（2）

［5］黃國(guó)輝，余立建．基于GPS／GIS的列車實(shí)時(shí)監(jiān)控系統(tǒng)設(shè)計(jì)［J］．鐵路計(jì)算機(jī)應(yīng)用，2008（9）