尹星、左元堃、劉祖聰、于浩
(青島地鐵運(yùn)營(yíng)有限公司,山東 青島 266000)
車地上傳是一項(xiàng)使用計(jì)算機(jī)技術(shù)將列車關(guān)鍵信息發(fā)送至地面進(jìn)行解析的技術(shù),其中車指的是城軌車輛,通常以列為單元。地指的是地面用于數(shù)據(jù)接收與解析的工作站,通常部署在調(diào)度中心、運(yùn)維中心等場(chǎng)所。上傳指的是列車數(shù)據(jù)發(fā)送至地面的過(guò)程,因地面工作站往往是一臺(tái),在通信過(guò)程中擔(dān)任服務(wù)器角色,而列車數(shù)量為多列,擔(dān)任客戶端的角色,所以列車至地面的數(shù)據(jù)發(fā)送稱為上傳。
列車數(shù)據(jù)以列車通信網(wǎng)絡(luò)(TCN)上傳輸?shù)臄?shù)據(jù)為主,以青島地鐵2 號(hào)線電客車為例。列車通信網(wǎng)絡(luò)采用多功能車輛總線(MVB),MVB 硬件層及鏈路層遵循IEC61375 標(biāo)準(zhǔn),列車各個(gè)系統(tǒng)間均使用MVB 進(jìn)行數(shù)據(jù)交互,并具有良好的信號(hào)屏蔽,傳輸速率為1.5Mbit/s[1],數(shù)據(jù)格式因機(jī)車廠與車型的不同均有差別,但所有MVB 數(shù)據(jù)均包含列車關(guān)鍵的運(yùn)行信息,若MVB 網(wǎng)絡(luò)癱瘓則將直接導(dǎo)致列車無(wú)法正常運(yùn)行。
由于MVB 網(wǎng)絡(luò)數(shù)據(jù)具有重要意義,所以列車運(yùn)行中就需要對(duì)其內(nèi)容進(jìn)行解析,常見(jiàn)的方法為使用司機(jī)顯示器(DDU),DDU 將MVB 中的故障數(shù)據(jù)、狀態(tài)數(shù)據(jù)進(jìn)行圖形化處理并顯示,司機(jī)通過(guò)DDU 內(nèi)容可了解列車當(dāng)前狀態(tài)。但這一方法存在局限性,列車相對(duì)于地面高速運(yùn)動(dòng),運(yùn)行距離較遠(yuǎn),且通常一列車配備一名司機(jī),列車在正線運(yùn)營(yíng)過(guò)程中出現(xiàn)故障的概率較大,司機(jī)無(wú)法全面地了解列車狀態(tài),所以在列車遇到突發(fā)情況時(shí),司機(jī)處置往往無(wú)法做到迅速準(zhǔn)確。車輛專業(yè)工程師也無(wú)法及時(shí)地了解車輛狀態(tài),這樣就容易導(dǎo)致信息不對(duì)稱,延誤處置。
列車控制與監(jiān)控系統(tǒng)(TCMS)主要對(duì)MVB 數(shù)據(jù)進(jìn)行管理,人機(jī)交互仍通過(guò)DDU 進(jìn)行,同時(shí)列車TCMS因穩(wěn)定性需要,性能受到限制,通常只處理列車運(yùn)行邏輯,并對(duì)部分狀態(tài)量、模擬量進(jìn)行監(jiān)控,想要實(shí)現(xiàn)列車MVB 數(shù)據(jù)全面監(jiān)控則需要引入一套獨(dú)立于列車控制系統(tǒng)的計(jì)算設(shè)備,該設(shè)備需要具備單向傳輸?shù)奶匦?,即設(shè)備僅接受MVB 數(shù)據(jù)并不參與控制,這套計(jì)算設(shè)備可稱為服務(wù)器、工作站。
為了全面地掌握上線列車的運(yùn)行狀態(tài)、所有列車數(shù)據(jù)應(yīng)集中管理,處理數(shù)據(jù)的工作站設(shè)置在地面控制中心。但列車MVB 網(wǎng)絡(luò)數(shù)據(jù)通過(guò)雙絞線傳輸,列車位置不固定,無(wú)法直連到地面,這就需要引入一種無(wú)線傳輸方式。過(guò)去射頻通信方式穩(wěn)定性較差,民用移動(dòng)以太網(wǎng)帶寬不高,但隨著4G 等無(wú)線通信技術(shù)的普及,使用4G 技術(shù)實(shí)現(xiàn)高速、大帶寬以太網(wǎng)通信成為解決這一問(wèn)題的最佳方案[2]。
實(shí)現(xiàn)車地上傳的第一步是建立MVB 與以太網(wǎng)的通道,青島地鐵2 號(hào)線列車使用信號(hào)系統(tǒng)網(wǎng)絡(luò)通道傳送數(shù)據(jù),PIDS 系統(tǒng)MVB 板卡接入列車MVB 網(wǎng)絡(luò),接收MVB 網(wǎng)絡(luò)上特定端口的數(shù)據(jù)。參考《列車控制監(jiān)控系統(tǒng)(TCMS)與乘客信息系統(tǒng)(PIS)通信接口協(xié)議》,2 號(hào)線PIDS 系統(tǒng)與TCMS 系統(tǒng)通信共使用18 個(gè)端口,端口地址詳見(jiàn)表1。
表1 TCMS 系統(tǒng)(CCU)與PIS 之間通信端口分配表
以0x0A0 端口為例,A0 端口數(shù)據(jù)長(zhǎng)度為32 字節(jié),輪詢周期為256 毫秒,輪詢周期決定數(shù)據(jù)的刷新速度。
A0 端口數(shù)據(jù)含義見(jiàn)圖1,此處注意區(qū)分?jǐn)?shù)據(jù)類型,上表內(nèi)字偏移指的是雙字偏移,雙字(WORD16)又稱DWORD,長(zhǎng)度為兩個(gè)字節(jié)(BYTE),字偏移起始0,結(jié)束15,共16 個(gè)雙字,32 個(gè)字節(jié)。表中BitNo 為二進(jìn)制偏移,一個(gè)雙字有16 個(gè)二進(jìn)制位,每一位可表示不同的數(shù)據(jù)。高位在前二進(jìn)制位偏移見(jiàn)表2。
圖1 TCMS 發(fā)送給PIS 數(shù)據(jù)圖
表2 二進(jìn)制位偏移數(shù)據(jù)
通過(guò)二進(jìn)制偏移可提取每個(gè)二進(jìn)制位的含義,提取、存儲(chǔ)、分析數(shù)據(jù)的過(guò)程稱為數(shù)據(jù)的解析。在此之前MVB 板卡還需將數(shù)據(jù)發(fā)送至以太網(wǎng),數(shù)據(jù)組合(打包)的過(guò)程由MVB 板卡內(nèi)部程序負(fù)責(zé),本文不再敘述。
MVB 板施工以太網(wǎng)接口將數(shù)據(jù)發(fā)送至車載信號(hào)交換機(jī),交換機(jī)使用無(wú)線方式接入整個(gè)信號(hào)網(wǎng)絡(luò),車地網(wǎng)絡(luò)通道拓?fù)鋱D2如下:
圖2 車地網(wǎng)絡(luò)通道拓?fù)鋱D
地面工作站通過(guò)解析軟件進(jìn)行數(shù)據(jù)包解析,同時(shí)進(jìn)行圖形化顯示與存儲(chǔ)。解析軟件主要實(shí)現(xiàn)以下幾個(gè)功能:
2.3.1 列車數(shù)據(jù)本地定義
解析軟件需要判斷數(shù)據(jù)來(lái)源,即列車號(hào),通常使用兩個(gè)方式進(jìn)行判斷,一是通過(guò)數(shù)據(jù)包內(nèi),MVB 總線上的ATC Train ID 數(shù)據(jù)進(jìn)行判斷,二是通過(guò)來(lái)源IP地址進(jìn)行判斷,列車數(shù)據(jù)包是以UDP 廣播的形式發(fā)送,接收端可識(shí)別到發(fā)送端的IP 地址通過(guò)IP 地址,可區(qū)分?jǐn)?shù)據(jù)的來(lái)源。通過(guò)本地?cái)?shù)據(jù)庫(kù)(SQLite)預(yù)先定義車號(hào)與IP 地址的關(guān)聯(lián),解析軟件啟動(dòng)后加載到內(nèi)存鏈表內(nèi),在接收數(shù)據(jù)時(shí)按車號(hào)進(jìn)行數(shù)據(jù)包分類。
2.3.2 關(guān)鍵字定義
解析軟件在接收到某一列車數(shù)據(jù)后,會(huì)對(duì)數(shù)據(jù)包進(jìn)行解析,解析過(guò)程依賴數(shù)據(jù)位置與數(shù)據(jù)含義的對(duì)照關(guān)系,正如《列車控制監(jiān)控系統(tǒng)(TCMS)與乘客信息系統(tǒng)(PIS)通信接口協(xié)議》中定義的那樣,數(shù)據(jù)含義以端口、雙字偏移、位偏移共同組成。以門全關(guān)閉信號(hào)為例,該信號(hào)數(shù)據(jù)定義見(jiàn)圖3,數(shù)據(jù)解釋名為“1 車DIM1列車門全關(guān)閉狀態(tài)”,端口號(hào)為10,數(shù)據(jù)包狀態(tài)為1,雙字偏移為2,比特偏移為7,需要查詢“1 車DIM1 列車門全關(guān)閉狀態(tài)”這個(gè)狀態(tài)量時(shí),可讀取端口10,第1狀態(tài),第2 個(gè)雙字節(jié)的第7 個(gè)比特位,因?yàn)樵摂?shù)據(jù)是二進(jìn)制存儲(chǔ),1 代表有效,0 表示無(wú)效。
圖3 1 車DIM1 列車門全關(guān)閉狀態(tài)數(shù)據(jù)定義圖
如果該數(shù)據(jù)為故障數(shù)據(jù),則需要特別表示以司機(jī)室多主控故障為例,該信號(hào)數(shù)據(jù)定義見(jiàn)圖4,0 或1 兩種狀態(tài)必須設(shè)定何為故障狀態(tài),何為正常狀態(tài),在本地?cái)?shù)據(jù)庫(kù)中需要定義其故障標(biāo)識(shí)位,F(xiàn)ault 字段為1 則表示數(shù)據(jù)為故障數(shù)據(jù),F(xiàn)aultValue 為故障值亦為1,表示該數(shù)據(jù)為1 時(shí)故障,0 表示正常,沒(méi)有該故障。
圖4 司機(jī)室多主控故障數(shù)據(jù)定義圖
解析軟件啟動(dòng)時(shí)加載關(guān)鍵字定義表到內(nèi)存鏈表,在查找指定數(shù)據(jù)的值時(shí),程序可通過(guò)解析名直接獲取。以獲取車號(hào)為例,調(diào)用find_target 函數(shù),函數(shù)內(nèi)部進(jìn)行查表,如圖5所示。
圖5 find_target 函數(shù)程序示例圖
2.3.3 故障處理原理
在讀取關(guān)鍵字時(shí),每種數(shù)據(jù)就可以根據(jù)Fault 值判斷是否為故障數(shù)據(jù),以及判斷是否發(fā)生故障的FaultValue 數(shù)據(jù)。故障數(shù)據(jù)約為2000 個(gè)以上,每秒都會(huì)接收到列車數(shù)據(jù),數(shù)據(jù)包大小為520 字節(jié),到達(dá)后逐位進(jìn)行IF 判斷則會(huì)消耗大量性能。所以程序在加載時(shí)首先篩選全部故障數(shù)據(jù)的位置,并生成掩碼,在接收數(shù)據(jù)后首先將數(shù)據(jù)與掩碼進(jìn)行與計(jì)算,剔除無(wú)用的數(shù)據(jù)位,隨后仍為1 的位與FaultValue 進(jìn)行異或計(jì)算,從而篩選出有效的故障位。目前普遍采用的64 位CPU 與64 位系統(tǒng)可高效地進(jìn)行故障判斷,一條運(yùn)算指令可處理8 字節(jié)即4 個(gè)雙字,一個(gè)32 字節(jié)的端口數(shù)據(jù)最少執(zhí)行4 次就可以判斷是否存在故障,使用合理的算法提高了處理性能。隨后將故障顯示在界面上,并伴隨語(yǔ)音提示,同時(shí)將故障數(shù)據(jù)存儲(chǔ)在數(shù)據(jù)庫(kù)內(nèi),此時(shí)SQLite 數(shù)據(jù)庫(kù)性能已無(wú)法滿足要求,需要使用性能更好的MySQL 數(shù)據(jù)庫(kù),故障數(shù)據(jù)存儲(chǔ)后,程序?qū)崿F(xiàn)了查詢接口,檢索歷史故障。
該系統(tǒng)已在青島地鐵2 號(hào)線投入使用,車輛專業(yè)工程師可根據(jù)系統(tǒng)主界面顯示,獲取當(dāng)日所有上線列車的運(yùn)行狀態(tài)、當(dāng)前故障等信息,主界面如圖6所示。當(dāng)列車發(fā)生故障時(shí),會(huì)觸發(fā)彈窗提醒工程師第一時(shí)間關(guān)注,縮短了故障信息以各種形式上報(bào)至車輛專業(yè)、乘務(wù)專業(yè)的時(shí)間。雙擊主界面可進(jìn)入單列車界面,單列車界面可分類顯示列車各系統(tǒng)的故障、狀態(tài)。
圖6 系統(tǒng)主界面圖
青島地鐵2 號(hào)線電客車通過(guò)運(yùn)用車地上傳數(shù)據(jù)解析技術(shù),將列車關(guān)鍵運(yùn)行數(shù)據(jù)同步至地面終端,縮短了故障響應(yīng)時(shí)間,提高了故障處置效率,驗(yàn)證了該線路電客車向數(shù)字化、智能化運(yùn)維過(guò)渡的可行性,為后續(xù)數(shù)據(jù)深度運(yùn)用奠定基礎(chǔ)