基于5G通信的車載數(shù)據(jù)轉(zhuǎn)儲系統(tǒng)

銀壯辰

當(dāng)檢修人員需要獲取列車車載數(shù)據(jù)時，需在每日地鐵運營結(jié)束后登乘列車，手動進行數(shù)據(jù)下載［1］，不僅工作危險性大、勞動強度高、工作壓力大，而且列車日間運行出現(xiàn)的問題，往往不能及時找到原因，導(dǎo)致次日運行時問題重復(fù)出現(xiàn)，影響運營服務(wù)質(zhì)量。為了降低檢修員工的檢修風(fēng)險，減輕檢修壓力，提高車載數(shù)據(jù)分析處理效率，快速定位列車故障點，控制運營維護成本，設(shè)計一種基于5G 通信的車載數(shù)據(jù)轉(zhuǎn)儲系統(tǒng)，將車載數(shù)據(jù)實時通過5G 網(wǎng)絡(luò)轉(zhuǎn)儲至地面服務(wù)器，供應(yīng)用終端智能運維系統(tǒng)進行數(shù)據(jù)解析、智能預(yù)警、故障診斷。

1 現(xiàn)狀分析

在軌道交通領(lǐng)域，車地通信主要通過Wi-Fi、LTE-M、毫米波、EUHT 等技術(shù)實現(xiàn)。各技術(shù)優(yōu)缺點如下。

1）Wi-Fi［2］。該技術(shù)較為成熟，在軌道交通車地通信領(lǐng)域應(yīng)用廣泛，通信帶寬較大，但由于每隔幾百米需要部署無線接入點（AP），費用較高，且存在小區(qū)切換鏈路不穩(wěn)定等問題。

2）LTE-M［3］。該技術(shù)鏈路穩(wěn)定性高，已廣泛應(yīng)用于軌道交通領(lǐng)域，但需全線部署漏纜，費用較高，且?guī)捿^小，只有5 Mb/s，傳輸數(shù)據(jù)量有限。

3） 毫米波。該技術(shù)以華為Airflash 技術(shù)為主，已在深圳地鐵11 號線、西安鐵路局等地進行試點應(yīng)用，帶寬可達1.7 Gb/s，但不支持列車高速移動，僅可在列車進出站、停站等低速場景下使用，無法做到全線路通信，且設(shè)備昂貴，部署成本高。

4）EUHT［4］。該技術(shù)為我國自主提出的通信標(biāo)準(zhǔn)，具有帶寬容量大、通信時延小等特點，但每隔幾百米就需要部署軌旁基站，設(shè)備較貴，費用較高。

上述傳輸技術(shù)各有其問題，而5G 通信技術(shù)具有大帶寬、廣連接、低延時等特性［5］，為此研發(fā)基于5G 通信技術(shù)的車載數(shù)據(jù)轉(zhuǎn)儲系統(tǒng)。目前該系統(tǒng)已在廣州地鐵5 號線進行試點應(yīng)用，取得良好效果。

2 系統(tǒng)方案

基于5G 的車載數(shù)據(jù)轉(zhuǎn)儲系統(tǒng)，是在列車上部署自主研發(fā)的5G 通信板，設(shè)計數(shù)據(jù)自動轉(zhuǎn)儲軟件，采用高效數(shù)據(jù)傳輸策略，利用5G 通信將在線運營列車數(shù)據(jù)自動轉(zhuǎn)儲到地面服務(wù)器。本方案通過FTP（文件傳輸協(xié)議）對車載數(shù)據(jù)進行下載，將運營商5G 通信網(wǎng)絡(luò)作為傳輸通道，采用網(wǎng)絡(luò)切片技術(shù)［6］保障傳輸數(shù)據(jù)的安全性，實現(xiàn)列車數(shù)據(jù)的高效、可靠轉(zhuǎn)儲。車載主機與地面數(shù)據(jù)服務(wù)器之間無法直接交互，須通過5G 通信板進行數(shù)據(jù)緩存中轉(zhuǎn)，實現(xiàn)安全可靠的數(shù)據(jù)轉(zhuǎn)儲功能。基于5G 的車載數(shù)據(jù)轉(zhuǎn)儲系統(tǒng)架構(gòu)見圖1。

圖1 基于5G的車載數(shù)據(jù)轉(zhuǎn)儲系統(tǒng)架構(gòu)

2.1 硬件設(shè)計

車載5G 通信板采用標(biāo)準(zhǔn)化設(shè)計，尺寸為3U，可插在車載主機空余槽位上，主要包括CPU 模塊、5G 模組模塊、PHY（物理層）芯片模塊、GPS 模塊。其中，CPU 模塊用于部署應(yīng)用程序，實現(xiàn)數(shù)據(jù)的自動轉(zhuǎn)儲；5G 模組模塊采用華為MH5000-31 芯片，負(fù)責(zé)5G 無線通信，該芯片向下兼容支持4G、3G 通信；PHY 芯片模塊進行以太網(wǎng)通信；GPS 模塊進行列車輔助定位。車載5G 通信板還包括內(nèi)存、FLASH、網(wǎng)口、串口、SIM 卡座、天線接口等模塊。車載5G 通信板硬件結(jié)構(gòu)見圖2。

圖2 車載5G通信板硬件結(jié)構(gòu)

2.2 軟件設(shè)計

車載主機文件包括各系統(tǒng)日志文件、視頻文件等，數(shù)據(jù)自動轉(zhuǎn)儲軟件實時對車載主機文件進行檢測，當(dāng)發(fā)現(xiàn)生成新的數(shù)據(jù)文件后，通過FTP 下載車載數(shù)據(jù)，將文件緩存到車載5G 通信板。完成數(shù)據(jù)下載后，根據(jù)業(yè)務(wù)需要對不同類型文件進行處理，然后上傳到地面服務(wù)器。對于實時性要求高的數(shù)據(jù)，即時上傳到地面服務(wù)器，以便地面終端智能運維系統(tǒng)及時進行數(shù)據(jù)分析、問題排查和預(yù)警；對于實時性要求不高的數(shù)據(jù)，按指定數(shù)量對下載文件進行壓縮、打包處理，提高了帶寬利用率；數(shù)據(jù)上傳到地面服務(wù)器的過程中，可根據(jù)當(dāng)前網(wǎng)絡(luò)狀況動態(tài)調(diào)整上傳速度，為實時性要求高的數(shù)據(jù)傳輸預(yù)留一定帶寬余量，保障實時性高的文件數(shù)據(jù)能夠即時上傳到地面服務(wù)器。車載數(shù)據(jù)轉(zhuǎn)儲軟件系統(tǒng)架構(gòu)見圖3。

圖3 車載數(shù)據(jù)轉(zhuǎn)儲軟件系統(tǒng)架構(gòu)

車載數(shù)據(jù)轉(zhuǎn)儲軟件包括系統(tǒng)主邏輯交互模塊、FTP 操作模塊、數(shù)據(jù)文件打包壓縮模塊、流量控制模塊以及日志模塊。

1）主邏輯交互模塊：通過解析配置文件完成系統(tǒng)初始化，并創(chuàng)建FTP 下載、FTP 上傳和文件打包壓縮3個線程。在上述3個線程中調(diào)用FTP 操作模塊、數(shù)據(jù)文件打包壓縮模塊相關(guān)操作，完成數(shù)據(jù)文件自動下載到5G 通信板，已下載數(shù)據(jù)文件根據(jù)需要進行打包壓縮，數(shù)據(jù)文件從5G 通信板轉(zhuǎn)儲到地面服務(wù)器。

2）FTP 操作模塊：主要完成獲取文件列表、文件下載、文件上傳等操作［7］，自動完成車載服務(wù)器相關(guān)文件的列表獲取、文件下載，以及將所需文件上傳到地面服務(wù)器等功能。

3）數(shù)據(jù)文件打包壓縮模塊：主要完成打包壓縮文件創(chuàng)建、待打包壓縮文件寫入、打包壓縮文件結(jié)束符寫入、關(guān)閉打包壓縮文件等功能，實現(xiàn)指定數(shù)量下載文件的自動打包壓縮。

4）流量控制模塊：在進行數(shù)據(jù)上傳過程中，供FTP 操作模塊調(diào)用，對數(shù)據(jù)進行流量控制，限制其最大上傳速度，預(yù)留部分帶寬供實時性高的數(shù)據(jù)上傳使用［8］。

5）日志模塊：主要記錄關(guān)鍵步驟、系統(tǒng)故障日志，便于維護人員查看。

2.3 數(shù)據(jù)轉(zhuǎn)儲策略

車載數(shù)據(jù)轉(zhuǎn)儲主要采用FTP 協(xié)議，通過二進制流進行數(shù)據(jù)交互。為了提升數(shù)據(jù)傳輸效率，采用數(shù)據(jù)打包、數(shù)據(jù)壓縮、多線程并發(fā)、FTP 斷點續(xù)傳等技術(shù)，保障數(shù)據(jù)高效轉(zhuǎn)儲。

2.3.1 數(shù)據(jù)打包

數(shù)據(jù)打包是為了將零散的數(shù)據(jù)文件打包為大文件，進行數(shù)據(jù)傳輸，其原理如下。

基于5G 網(wǎng)絡(luò)的車地通信帶寬為a字節(jié)，數(shù)據(jù)通信延遲為b，數(shù)據(jù)傳輸過程中擁塞累計時長為c，系統(tǒng)內(nèi)部交互處理時間為d［9］，則車地通信交互總時延Tdelay為

在進行文件傳輸過程中，數(shù)據(jù)文件打包在FTP 協(xié)議中，F(xiàn)TP 協(xié)議占用x字節(jié)，數(shù)據(jù)文件占用y字節(jié)，完成一次數(shù)據(jù)傳輸包括數(shù)據(jù)發(fā)送、數(shù)據(jù)接收和數(shù)據(jù)確認(rèn)，F(xiàn)TP 協(xié)議部分傳輸時間Tftp為

數(shù)據(jù)部分傳輸時間Tdata為

在網(wǎng)絡(luò)穩(wěn)定可靠的情況下，Tdelay可以看作一個常數(shù)。對于傳輸一個完整的文件，需要進行n次車地通信FTP 交互，則文件傳輸帶寬利用率f可表示為

顯然傳輸文件越大，F(xiàn)TP 交互時間越少，則文件傳輸帶寬利用率就越高。由于列車上數(shù)據(jù)多為1～2 MB 的零散數(shù)據(jù)文件，對于傳輸100 個1 MB 大小的文件，如果分開傳輸，一方面文件較小，帶寬利用率低，另一方面FTP 需進行多次文件操作，導(dǎo)致FTP 交互占用的時間較多，進一步降低了帶寬利用率；而將100 個1 MB 文件進行打包，組合為一個100 MB 的文件，不僅帶寬利用率高，而FTP 僅需進行少量的文件交互操作，F(xiàn)TP 交互占用時間相對于單獨進行100 次 1 MB 文件操作較少。

因此，將零散的小文件進行打包處理為大文件，可有效提升文件傳輸帶寬利用率。

2.3.2 數(shù)據(jù)壓縮

為了進一步提升文件傳輸帶寬利用率，本方案引入哈夫曼數(shù)據(jù)壓縮算法［10］，對數(shù)據(jù)文件進行壓縮。壓縮過程主要步驟如下。

1）統(tǒng)計：讀入源文件，統(tǒng)計字符出現(xiàn)的次數(shù)，并根據(jù)權(quán)重進行從大到小的排序。

2）建樹：以字符的權(quán)重（權(quán)重為0 的字符除外）為依據(jù)建立哈夫曼樹。

3）編碼：依據(jù)2）中的哈夫曼樹，得到每一個字符的編碼。

4）寫入：新建壓縮文件，寫入壓縮數(shù)據(jù)。

假設(shè)一個字符串是“abcabcabcabcabcabcddddddddd”，統(tǒng)計各字符出現(xiàn)的次數(shù)見表1。

表1 哈夫曼權(quán)重表

按照一般的存儲方法，1個字符占用1個字節(jié)，那 么 共 花 費 （6 ＋ 6 ＋ 6 ＋ 9） × sizeof（char） ＝27 B。但如果對其建立哈夫曼樹，將各字符出現(xiàn)的次數(shù)當(dāng)做權(quán)重，出現(xiàn)次數(shù)越多，越靠近根節(jié)點，其編碼越短，其哈夫曼樹見圖4。

圖4 哈夫曼樹

因此，“abcabcabcabcabcabcddddddddd”就可以轉(zhuǎn)化為“0001， 1000， 0110， 0001， 1000，0110， 0001， 1000，0110，1111，1111，1111，1111，11”，注意這里采用按位存儲，即0 和1 都是位，而非char 型。那么之前的27 B 就轉(zhuǎn)換成了7 B（字節(jié)不足就補零），這就達到了數(shù)據(jù)壓縮的效果。

將原本打包好的數(shù)據(jù)進行壓縮，使得在單位時間內(nèi)能夠傳送更多的數(shù)據(jù)，提升了系統(tǒng)的帶寬利用率。

2.3.3 多線程并發(fā)

采用多線程技術(shù)，創(chuàng)建多個線程分別進行數(shù)據(jù)下載、數(shù)據(jù)打包壓縮、數(shù)據(jù)上傳等操作，使系統(tǒng)各功能并發(fā)運行，提升數(shù)據(jù)轉(zhuǎn)儲效率。

2.3.4 FTP斷點續(xù)傳

當(dāng)網(wǎng)絡(luò)延遲發(fā)生數(shù)據(jù)傳輸中斷時，系統(tǒng)采用FTP 斷點續(xù)傳技術(shù)【11】，對于下載的數(shù)據(jù)，通過向服務(wù)器發(fā)送“REST ＋本地文件長度”命令，進行文件斷點下載；對于上傳的數(shù)據(jù)，通過服務(wù)器發(fā)送“APPE ＋文件名”命令，通知服務(wù)器后續(xù)發(fā)送的內(nèi)容附加到文件末尾。斷點續(xù)傳技術(shù)，減少了已下載或已上傳部分文件內(nèi)容的重復(fù)傳輸，提升了數(shù)據(jù)轉(zhuǎn)儲效率。

3 關(guān)鍵流程

系統(tǒng)關(guān)鍵流程包括：文件自動下載、文件打包壓縮、文件轉(zhuǎn)儲上傳3個流程。

3.1 文件自動下載

系統(tǒng)支持?jǐn)?shù)據(jù)文件自動下載到5G 通信板，其交互流程見圖5。

圖5 文件自動下載交互流程

3.2 文件打包壓縮

根據(jù)下載文件的類型，對文件進行打包壓縮，以提高帶寬利用率，其交互流程見圖6。

圖6 文件打包壓縮交互流程

3.3 文件轉(zhuǎn)儲上傳

系統(tǒng)支持將5G 通信板下載的文件自動轉(zhuǎn)儲上傳到地面服務(wù)器，以供數(shù)據(jù)終端進行分析、處理，其交互流程見圖7。

圖7 文件轉(zhuǎn)儲上傳交互流程

4 結(jié)束語

基于5G 通信的車地轉(zhuǎn)儲系統(tǒng)充分利用5G 網(wǎng)絡(luò)特性，通過設(shè)計車地轉(zhuǎn)儲硬件平臺及轉(zhuǎn)儲軟件，并制定高效的轉(zhuǎn)儲策略，實現(xiàn)了車載數(shù)據(jù)自動、高效地轉(zhuǎn)儲到地面服務(wù)器，解決了地鐵列車數(shù)據(jù)孤島問題。本方案在減少列車檢修人員作業(yè)的同時，實現(xiàn)列車從計劃修到狀態(tài)修的轉(zhuǎn)變，提高了列車的上線率。基于本方案的技術(shù)優(yōu)勢，必將會在列車車載數(shù)據(jù)轉(zhuǎn)儲領(lǐng)域擁有良好的應(yīng)用前景。