城軌列車4G 移動(dòng)通信性能優(yōu)化研究

李彥儒， 申 萍

（北京交通大學(xué) 北京 100044）

隨著近年來我國交通運(yùn)輸網(wǎng)絡(luò)的迅速發(fā)展，城市軌道交通建設(shè)取得了巨大的成就，然而城軌列車與地面控制中心的通信需求仍亟待滿足。 一方面，城軌列車需要向地面控制中心發(fā)送車輛狀態(tài)信息，以便地面控制中心能夠動(dòng)態(tài)地監(jiān)控車輛運(yùn)行狀態(tài)，例如當(dāng)前車速、輪軸溫度、蓄電池電壓、牽引單元狀態(tài)等；另一方面，城軌列車發(fā)生故障時(shí)需要及時(shí)向地面控制中心發(fā)送報(bào)告，以便地面控制中心能夠準(zhǔn)確、實(shí)時(shí)地診斷故障問題[1-2]。 4G 移動(dòng)技術(shù)的適時(shí)發(fā)展為城軌列車與地面控制中心的實(shí)時(shí)、大數(shù)據(jù)通信提供了理論基礎(chǔ)。本文在4G 移動(dòng)網(wǎng)絡(luò)的基礎(chǔ)上，應(yīng)用開源、安全且代碼風(fēng)格良好的嵌入式Linux 操作系統(tǒng)，對(duì)實(shí)現(xiàn)實(shí)時(shí)、高速、可靠的通信所需解決的部分關(guān)鍵性技術(shù)難點(diǎn)進(jìn)行了研究與分析，提供了相應(yīng)的解決策略。 對(duì)實(shí)現(xiàn)城軌列車與地面控制中心實(shí)時(shí)、高速、可靠的通信需求具有重要的意義。

1 城軌列車車地4G 通信關(guān)鍵技術(shù)分析

城軌列車與地面控制中心通信系統(tǒng)結(jié)構(gòu)如圖1 所示，分為車載通信系統(tǒng)與地面維護(hù)中心兩部分。 車載通信系統(tǒng)包括列車數(shù)據(jù)采集設(shè)備、嵌入式控制器以及4G 路由器。嵌入式控制器運(yùn)行Linux 操作系統(tǒng)，實(shí)時(shí)地通過RJ45 以太網(wǎng)接收列車數(shù)據(jù)采集設(shè)備發(fā)送的車輛常規(guī)及故障信息， 并通過4G 路由器將車輛信息發(fā)送到4G 移動(dòng)網(wǎng)絡(luò)。 地面控制中心采用Windows 服務(wù)器版本， 從4G 移動(dòng)網(wǎng)絡(luò)接收車輛信息并進(jìn)行分析，判斷車輛的運(yùn)行狀態(tài)，并對(duì)車輛信息進(jìn)行顯示、存儲(chǔ)。如有需要?jiǎng)t將分析結(jié)果反饋至城軌列車。

圖1 通信系統(tǒng)結(jié)構(gòu)Fig. 1 Structure of communication system

當(dāng)城軌列車發(fā)生故障時(shí)，嵌入式控制器必須快速地做出響應(yīng)，將故障信息發(fā)送至4G 移動(dòng)網(wǎng)絡(luò)，這就對(duì)操作系統(tǒng)的實(shí)時(shí)性有很高的要求。 然而常規(guī)Linux 是非實(shí)時(shí)操作系統(tǒng)[3]，因此必須對(duì)其進(jìn)行改進(jìn)，使其成為實(shí)時(shí)操作系統(tǒng)，然后將改進(jìn)后的實(shí)時(shí)Linux 操作系統(tǒng)移植到嵌入式Linux 控制器中。 同時(shí)，4G 移動(dòng)網(wǎng)絡(luò)采用動(dòng)態(tài)IP 地址分配策略，在規(guī)定的時(shí)間內(nèi)沒有通信數(shù)據(jù)則自動(dòng)解除已分配的IP 地址， 需要在通信是檢測(cè)網(wǎng)絡(luò)狀態(tài)。 在城軌列車高速運(yùn)行過程中，還可能會(huì)因?yàn)橥ㄐ判盘?hào)質(zhì)量問題導(dǎo)致數(shù)據(jù)發(fā)送中斷、 數(shù)據(jù)包錯(cuò)誤等情況。為了滿足可靠的通信需求， 必須對(duì)利用4G 移動(dòng)網(wǎng)絡(luò)通信時(shí)的通信策略進(jìn)行優(yōu)化，加入網(wǎng)絡(luò)連接狀態(tài)檢測(cè)機(jī)制、數(shù)據(jù)包校驗(yàn)機(jī)制、網(wǎng)絡(luò)故障重傳機(jī)制等。

2 Linux 操作系統(tǒng)內(nèi)核實(shí)時(shí)性能的優(yōu)化

2.1 Linux 操作系統(tǒng)實(shí)時(shí)性能約束因素

常規(guī)Linux 操作系統(tǒng)為非實(shí)時(shí)操作系統(tǒng)， 無法滿足本文中通信系統(tǒng)對(duì)實(shí)時(shí)性能的要求。 約束Linux 操作系統(tǒng)實(shí)時(shí)性能的因素主要包括以下3 個(gè)方面[4]：

1）內(nèi)核的不完全可搶占特性

優(yōu)先級(jí)高的進(jìn)程中斷優(yōu)先級(jí)低的進(jìn)程被稱為內(nèi)核搶占，Linux 系統(tǒng)沒有提供完整的搶占機(jī)制。

2）時(shí)鐘粒度粗糙

Linux 3.0 版本內(nèi)核的時(shí)鐘頻率小于1 200 Hz，時(shí)鐘周期大于0.8 ms，無法滿足實(shí)時(shí)任務(wù)調(diào)度需求。

3）中斷關(guān)閉

Linux 操作系統(tǒng)經(jīng)常為了保護(hù)系統(tǒng)關(guān)鍵數(shù)據(jù)而關(guān)閉系統(tǒng)中斷。 導(dǎo)致系統(tǒng)不能實(shí)時(shí)響應(yīng)外部中斷。

基于以上3 方面的原因，Linux 為非實(shí)時(shí)操作系統(tǒng)。 為了滿足城軌列車與地面控制中心的實(shí)時(shí)通信， 必須對(duì)Linux 操作系統(tǒng)內(nèi)核的實(shí)時(shí)性進(jìn)行改進(jìn)。

2.2 Linux 內(nèi)核實(shí)時(shí)性能優(yōu)化

目前對(duì)Linux 操作系統(tǒng)的實(shí)時(shí)性能改進(jìn)主要有兩類方法：

1）Linux 內(nèi)核源代碼級(jí)修改

對(duì)Linux 系統(tǒng)內(nèi)核中與調(diào)度方式、中斷處理、時(shí)鐘與定時(shí)等相關(guān)數(shù)據(jù)結(jié)構(gòu)進(jìn)行修改。 這種方式需要開發(fā)人員對(duì)內(nèi)核代碼有深入的了解，且改造工作量巨大[5-6]。

1）雙內(nèi)核法

將一個(gè)規(guī)模較小的實(shí)時(shí)內(nèi)核插入到底層硬件與Linux 操作系統(tǒng)內(nèi)核之間。 實(shí)時(shí)任務(wù)在實(shí)時(shí)內(nèi)核中運(yùn)行，當(dāng)有非實(shí)時(shí)任務(wù)時(shí)，Linux 內(nèi)核才會(huì)工作。 雙內(nèi)核法改造工作量小，能夠保證兩個(gè)內(nèi)核工作的穩(wěn)定性，能夠提供更為豐富的功能。 目前采用雙內(nèi)核法的實(shí)時(shí)內(nèi)核有Xenomai、RTLinux、RTAI 等[7]。

對(duì)比兩種方法，可以發(fā)現(xiàn)雙內(nèi)核法更容易實(shí)現(xiàn)，能夠提供的功能也更多。 故本文采用雙內(nèi)核法對(duì)Linux 的實(shí)時(shí)性改進(jìn)，最終選用Xenomai 實(shí)時(shí)內(nèi)核。加入實(shí)時(shí)內(nèi)核后的Linux 實(shí)時(shí)內(nèi)核結(jié)構(gòu)如圖2 所示：

本文選用Xenomai 2.4.4 穩(wěn)定版，Linux 內(nèi)核選用2.6.24版本。 對(duì)Linux 內(nèi)核的實(shí)時(shí)性改進(jìn)步驟如下：

1）增加ADEOS 可適應(yīng)域環(huán)境資源虛擬層。

在獲取源代碼的基礎(chǔ)上， 為L(zhǎng)inux 內(nèi)核加載arm 平臺(tái)下ADEOS 補(bǔ)丁文件，命令如下：

# $xenomai_root/xenomai -2.4.4/scripts/prepare -kernel.sh╞arch=arm ╞adeos=$xenomai/

_root/ksrc/arch/arm/patches/adeos-ipipe-2.4.4 -arm-* --linux=$linux_tree

2）配置實(shí)時(shí)內(nèi)核選項(xiàng)

成功加載ADEOS 補(bǔ)丁后，選擇以下Linux 內(nèi)核選項(xiàng)保證Xenomai 實(shí)時(shí)內(nèi)核正常使用：

Xenomai，實(shí)時(shí)內(nèi)核的主程序；

Nucleus，開啟實(shí)時(shí)內(nèi)核對(duì)多線程機(jī)制、線程搶占調(diào)度機(jī)制的支持；

Debug support，開啟實(shí)時(shí)內(nèi)核調(diào)試模式，方便系統(tǒng)運(yùn)行過程中出現(xiàn)錯(cuò)誤時(shí)調(diào)試；

Interfaces 子選項(xiàng)， 選擇需要的編程接口， 勾選POSIX API、Native API、Real-Time Driver Model， 確保在編寫應(yīng)用程序時(shí)能夠使用這些編程接口。

圖2 Xenomai/Linux 實(shí)時(shí)內(nèi)核結(jié)構(gòu)Fig. 2 Xenomai/Linux real-time kernel structure

2.3 嵌入式Linux 操作系統(tǒng)移植

嵌入式Linux 移植的關(guān)鍵在于內(nèi)核的配置與編譯， 并將配置好的內(nèi)核下載到嵌入式控制器中[8]。

1）設(shè)置目標(biāo)處理器

修改內(nèi)核源碼目錄頂層Makefile 文件的ARCH 及CROSS_COMPILE 字段，確保編譯后的內(nèi)核可以在ARM 架構(gòu)的處理器上運(yùn)行。

2）配置內(nèi)核

使用圖形化配置工具menuconfig 對(duì)內(nèi)核選項(xiàng)進(jìn)行配置，裁剪不需要的內(nèi)核功能及驅(qū)動(dòng)程序來盡量縮小內(nèi)核體積使其適應(yīng)嵌入式處理器。

3）配置開發(fā)板晶振頻率

本文應(yīng)用于嵌入式控制器上的三星S3C2440 處理器晶振頻率為12 MHz， 為了使內(nèi)核與之匹配， 對(duì)內(nèi)核文件arch/arm/mach-s3c2440/mach-smdk2440.c 進(jìn)行相應(yīng)配置：

s3c24xx_init_clocks（12000000）；

4）修改NAND Flash 分區(qū)表

NAND Flash 是程序運(yùn)行的內(nèi)存空間，嵌入式控制器配備64MB NAND Flash，通過修改內(nèi)核文件arch/arm/plat-s3c24xx/common-smdk.c 文件， 可以將NAND Flash 劃分為如表1 的3 個(gè)分區(qū)：

表1 NAND Flash 分區(qū)Tab. 1 The NAND Flash partition

5）內(nèi)核編譯及下載

對(duì)配置好的內(nèi)核進(jìn)行編譯， 生成名為uImage 的內(nèi)核文件，之后通過JTAG 及tftp 軟件將uImage 下載至嵌入式控制器中。

3 4G 移動(dòng)網(wǎng)絡(luò)通信策略優(yōu)化

常規(guī)網(wǎng)絡(luò)通信采用客戶端—服務(wù)器方式，服務(wù)器運(yùn)行并等待客戶端連接。 客戶端有數(shù)據(jù)傳輸請(qǐng)求時(shí)與服務(wù)器建立連接并發(fā)送數(shù)據(jù)。 根據(jù)4G 移動(dòng)網(wǎng)絡(luò)IP 自動(dòng)分配的機(jī)制特點(diǎn)，并考慮到城軌列車在運(yùn)行過程中通信信號(hào)質(zhì)量的變化，必須對(duì)城軌列車在運(yùn)行時(shí)與地面控制中心的通信策略進(jìn)行優(yōu)化。優(yōu)化后的通信策略如圖3 所示。

圖3 優(yōu)化后的通信策略Fig. 3 Communication strategies after optimization

本文優(yōu)化策略的實(shí)現(xiàn)基于Linux 操作系統(tǒng)下的Internet domain socket 網(wǎng) 絡(luò) 通 信 庫，遵 循POSIX 標(biāo) 準(zhǔn)[9]。 采 用 流 式socket 通信模型。

1）網(wǎng)絡(luò)狀態(tài)檢測(cè)

為了確保車載通信系統(tǒng)與地面維護(hù)中心通信時(shí)已建立連接，在嵌入式控制器調(diào)用write（）函數(shù)將信息發(fā)送到4G 網(wǎng)絡(luò)后，如果函數(shù)返回錯(cuò)誤值-1，且錯(cuò)誤代碼為EAGAIN，則表示本次數(shù)據(jù)傳送不成功，刪除當(dāng)前建立的socket，重新調(diào)用connect（）函數(shù)建立與地面控制中心的連接，之后再次發(fā)送信息。

2）數(shù)據(jù)包校驗(yàn)

流式socket 的特點(diǎn)是不存在信息邊界。 在傳送常規(guī)/故障信息時(shí)， 必須顯式地在信息前加入信息總長(zhǎng)度以及校驗(yàn)值信息。 為了盡量減少對(duì)嵌入式控制器的資源占用，同時(shí)最大情況地保證數(shù)據(jù)的可靠性，本文采用CRC 校驗(yàn)算法。地面控制中心在接收到信息后，需要對(duì)信息再次進(jìn)行校驗(yàn)計(jì)算，并與信息中的校驗(yàn)值相比較，如果不同則向車載通信系統(tǒng)反饋錯(cuò)誤。

3）網(wǎng)絡(luò)故障重傳

車載通信系統(tǒng)通過write（）函數(shù)向地面控制中心發(fā)送常規(guī)/故障信息后， 如果地面控制中心反饋信息顯示發(fā)送成功，則立即調(diào)用read（）函數(shù)接收地面控制中心的反饋信息；如果反饋信息顯示發(fā)送不成功，則重新調(diào)用write（）函數(shù)發(fā)送信息。 本文規(guī)定重新傳送的次數(shù)為5 次，如果最終傳輸仍不成功，表示當(dāng)前通信信號(hào)質(zhì)量太差，程序返回錯(cuò)誤值，并等待一段時(shí)間后再次發(fā)送信息。

4 通信實(shí)驗(yàn)及結(jié)果分析

本文采用用運(yùn)行服務(wù)器版Windows 的工控機(jī)平臺(tái)作為地面控制中心， 采用運(yùn)行Linux 的嵌入式控制器及4G 路由器作為車載通信系統(tǒng)。 通信配置如表2：

表2 實(shí)驗(yàn)通信配置Tab. 2 Experimental configuration for communication

通信實(shí)驗(yàn)平臺(tái)如圖4，圖中框1 代表地面維護(hù)中心，框2代表嵌入式控制器，框3 為4G 路由器。

圖4 實(shí)驗(yàn)平臺(tái)Fig. 4 Experimental platform

本實(shí)驗(yàn)分如下情況進(jìn)行測(cè)試：

1） 網(wǎng)絡(luò)傳輸速率測(cè)試

車載通信系統(tǒng)分5 次向地面控制中心傳送300 MB 的單個(gè) 文 件， 測(cè)得 傳 輸 時(shí) 間 分 別 為112 s、121 s、131 s、125 s 及122 s。 平均傳輸速率為2.45 MB/s， 經(jīng)校驗(yàn)傳輸前后文件的MD5 值相同。

2）實(shí)時(shí)Linux 內(nèi)核性能測(cè)試

在車載通信系統(tǒng)上分別采用常規(guī)Linux 內(nèi)核及改進(jìn)后的實(shí)時(shí)Linux 內(nèi)核， 以512 ms 為時(shí)間間隔， 周期性的發(fā)送100 Byte 數(shù)據(jù)進(jìn)行50 次本地回環(huán)測(cè)試。 測(cè)試結(jié)果如圖5所示。

3）常規(guī)/故障信息發(fā)送測(cè)試

圖5 本地回環(huán)測(cè)試Fig. 5 Local loopback test

車載通信系統(tǒng)采用實(shí)時(shí)Linux 內(nèi)核及優(yōu)化后的通信策略，與采用常規(guī)Linux 內(nèi)核及常規(guī)通信策略進(jìn)行對(duì)比測(cè)試，以5 min 為最大時(shí)間間隔隨機(jī)向地面控制中心發(fā)送4096Byte數(shù)據(jù)，所傳送的數(shù)據(jù)大小足以表示常規(guī)/故障信息。 測(cè)試結(jié)果如圖6 所示。 圖6 曲線中的斷點(diǎn)代表本次發(fā)送失敗。

圖6 信息發(fā)送測(cè)試Fig. 6 Information transmission test

5 結(jié) 論

本文對(duì)Linux 操作系統(tǒng)進(jìn)行了實(shí)時(shí)性，優(yōu)化了城軌列車與地面控制中心的通信策略，并進(jìn)行實(shí)驗(yàn)驗(yàn)證，得出如下結(jié)論：

1）采用4G 移動(dòng)通信網(wǎng)絡(luò)完全能夠滿足高速通信的需求。

2）改進(jìn)后的實(shí)時(shí)Linux 操作系統(tǒng)在實(shí)時(shí)性能方面有了很大的提升，能夠?qū)崟r(shí)響應(yīng)采集車輛數(shù)據(jù)采集設(shè)備的信息發(fā)送請(qǐng)求。

3）采用改進(jìn)后的實(shí)時(shí)Linux 操作系統(tǒng)與優(yōu)化的通信策略，明顯的縮短了信息發(fā)送時(shí)間，同時(shí)有效地保證了通信的可靠性。 完全能夠滿足城軌列車與地面控制中心實(shí)時(shí)、高速、可靠的通信需求。

[1] 劉永超. 基于Web的高速列車故障診斷專家系統(tǒng)關(guān)鍵技術(shù)研究[D]. 大連：大連交通大學(xué)，2012.

[2] 邵位. 列車故障診斷專家系統(tǒng)智能技術(shù)研究[D]. 大連：大連交通大學(xué)，2014.

[3] 韓守謙， 裴海龍，王清陽. 基于Xenomai的實(shí)時(shí)嵌入式Linux操作系統(tǒng)的構(gòu)建[J].計(jì)算機(jī)工程與設(shè)計(jì)，2011，32（1）:98-102.

[4] BI Chun-yue，LIU Yun-peng，WANG Ren-fang. Research of key technologies for embedded Linux based on ARM[C].International Conference on Computer Application and System Modeling，2011:1231-1240.

[5] 劉勝，王麗芳. 基于多核PC的Linux系統(tǒng)實(shí)時(shí)性改造[J]. 微電子學(xué)與計(jì)算機(jī)，2013，30（8）:120-123.

[6] 嚴(yán)麗萍，宋凱，鄧胡濱. 基于嵌入式應(yīng)用的Linux內(nèi)核實(shí)時(shí)性改進(jìn)研究[J]. 計(jì)算機(jī)工程與設(shè)計(jì)，2011，32（1）:121-124.

[7] 王濤. 基于交換式以太網(wǎng)的列車通信網(wǎng)絡(luò)實(shí)時(shí)性研究[D].北京交通大學(xué)，2014.

[8] 李文，張建澤. 基于S3C2440的嵌入式Linux系統(tǒng)移植[J]. 化工自動(dòng)化及儀表，2010，37（9）:88-92.

[9] Michael Kerrisk. The Linux Programming Interface [M].Beijing:Post & Telecom Press，2014.