青島地鐵2號(hào)線車地上傳數(shù)據(jù)解析技術(shù)的研究與應(yīng)用

尹星、左元堃、劉祖聰、于浩

（青島地鐵運(yùn)營(yíng)有限公司，山東 青島 266000）

1 技術(shù)背景

車地上傳是一項(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ì)稱，延誤處置。

2 系統(tǒng)原理

2.1 車地上傳系統(tǒng)實(shí)現(xiàn)方式

列車控制與監(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]。

2.2 車地上傳系統(tǒng)運(yùn)行原理

實(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

2.3 車地上傳系統(tǒng)功能實(shí)現(xiàn)原理

地面工作站通過(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)了查詢接口，檢索歷史故障。

3 系統(tǒng)應(yīng)用

該系統(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)主界面圖

4 結(jié)語(yǔ)

青島地鐵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ǔ)