特種車輛狀態(tài)監(jiān)管系統(tǒng)中通信服務(wù)器的設(shè)計

樊輝錦 歐陽中輝 陳青華 胡道暢

(海軍航空大學(xué)岸防兵學(xué)院 山東 煙臺 264001) 2(92635部隊 山東 青島 266001)

0 引 言

隨著軍事裝備信息化和智能化的發(fā)展,特種車輛裝備作為遂行海陸作戰(zhàn)任務(wù)的重要機動平臺,其信息化水平也不斷提高[1]。在特種車輛狀態(tài)監(jiān)管系統(tǒng)中,由于其作業(yè)場所、時間和空間的限制[2],數(shù)據(jù)傳輸方式選用北斗短報文通信,而通信服務(wù)器作為監(jiān)管系統(tǒng)接收報文、解析數(shù)據(jù)和轉(zhuǎn)發(fā)指令的核心部件,其性能的優(yōu)劣影響整個系統(tǒng)。

目前,通信服務(wù)器架構(gòu)的研究文獻中:曾憲權(quán)等[3]是通過采.NET的SocketAsyncEventArgs類實現(xiàn)了高性能通信服務(wù)器,支持大規(guī)模并發(fā)訪問。胡曉喻等[4]設(shè)計的通信服務(wù)器基于UDP協(xié)議制定特有通信協(xié)議結(jié)構(gòu),并與Linux虛擬網(wǎng)卡技術(shù)相結(jié)合提高服務(wù)器性能。王溪波等[5]利用優(yōu)先級動態(tài)切換的多隊列線程池機制提高性能滿足高并發(fā)需求,并使用線程鎖機制保證了數(shù)據(jù)操作的一致性。吉利等[6]設(shè)計優(yōu)化線程池來解決通信中大量規(guī)模請求導(dǎo)致的服務(wù)器不穩(wěn)定。周文婷等[7]實現(xiàn)了用電信息的北斗短報文傳輸采集系統(tǒng),由于數(shù)據(jù)量較少和通信頻次很低并未考慮通信服務(wù)器的應(yīng)用和設(shè)計。顧振德等[8]和甄凱成等[9]利用異步非阻塞Netty框架設(shè)計了通信服務(wù)或設(shè)備接入系統(tǒng)。以上工作主要針對有鏈接的傳輸協(xié)議或基于UDP設(shè)計特定通信協(xié)議結(jié)構(gòu)來節(jié)約系統(tǒng)開銷提高并發(fā)能力,而北斗短報文通信屬于無鏈接方式且報文協(xié)議格式固定,因此上述方法無法滿足基于北斗短報文車輛遠程狀態(tài)監(jiān)管系統(tǒng)的數(shù)據(jù)傳輸需求。

為滿足現(xiàn)有特種車輛成建制作戰(zhàn)平臺的一對多監(jiān)控管理需要,本文設(shè)計了一種基于多優(yōu)先級緩沖隊列和線程池技術(shù)的北斗短報文通信服務(wù)器架構(gòu),多優(yōu)先級用于保證故障信息等需優(yōu)先處理數(shù)據(jù)的及時傳輸,線程池管理技術(shù)主要解決報文監(jiān)聽和數(shù)據(jù)拆包處理中系統(tǒng)資源優(yōu)化問題,設(shè)計的同時充分考慮握手時序影響。架構(gòu)實現(xiàn)時利用新版Java并發(fā)庫的豐富功能完成系統(tǒng)架構(gòu)的搭建和實驗測試。

1 特種車輛遠程狀態(tài)監(jiān)管系統(tǒng)

特種車輛遠程狀態(tài)監(jiān)管系統(tǒng)遵循物聯(lián)網(wǎng)應(yīng)用設(shè)計三層結(jié)構(gòu)[10],整個系統(tǒng)結(jié)構(gòu)如圖1所示。感知層中特種車輛車載信息采集終端通過安裝在車輛上的多種傳感器采集狀態(tài)信息和故障信息,各級匯聚節(jié)點從中提取出能夠反映出被監(jiān)測車輛實時狀態(tài)的數(shù)據(jù)。傳輸層利用配套的車載北斗衛(wèi)星導(dǎo)航設(shè)備的短報文通信能力,將數(shù)據(jù)發(fā)送到遠程的通信服務(wù)器,通信服務(wù)器經(jīng)過預(yù)處理和編解碼后,再與數(shù)據(jù)中心進行數(shù)據(jù)交互。應(yīng)用層中數(shù)據(jù)中心將接收到的實時狀態(tài)信息和故障信息存儲到數(shù)據(jù)倉庫,并進行數(shù)據(jù)挖掘、故障分析和預(yù)測提供給應(yīng)用服務(wù)器,按照用戶需求以圖表、文字等可視化方式將結(jié)果顯示。

圖1 特種車輛監(jiān)控管理系統(tǒng)架構(gòu)設(shè)計

車載采集終端與后方數(shù)據(jù)中心之間的數(shù)據(jù)傳輸鏈路是兩者之間連接的橋梁,是系統(tǒng)實現(xiàn)特種車輛的遠程監(jiān)控管理的關(guān)鍵。上述系統(tǒng)架構(gòu)實現(xiàn)了一對多的監(jiān)控管理,隨著裝備數(shù)據(jù)和種類的增多,特種車輛數(shù)量不斷增加,確保車輛狀態(tài)信息較為實時到達后方數(shù)據(jù)庫是整個系統(tǒng)的關(guān)鍵,傳輸層中通信服務(wù)器的搭建是處理并發(fā)解決I/O阻塞確保通信實時的關(guān)鍵。

2 通信服務(wù)器架構(gòu)設(shè)計

由于北斗短報文的信息量很小,目前裝備采用的北斗定位系統(tǒng)短報文長度最短為78 Byte,且為類似UDP的無鏈接傳輸過程,當多臺北斗接收機同時與一臺接收機通信時易產(chǎn)生很高的丟包率,本文設(shè)計的通信服務(wù)器通過多優(yōu)先級動態(tài)緩沖隊列和線程池異步IO的方法來減少并發(fā),降低丟包率,架構(gòu)如圖2所示。北斗設(shè)備的不同通信接口種類有RS232/RS422/RS485,采用多通信板卡適配不同類型的接口提高通信服務(wù)器兼容性;線程池管理技術(shù)既能保證監(jiān)聽的實時性又提高報文拆解包的資源利用率;多優(yōu)先級動態(tài)隊列保證車輛故障信息能第一時間被處理推送[11]。

圖2 通信服務(wù)器軟件架構(gòu)

2.1 多優(yōu)先級動態(tài)緩沖隊列

根據(jù)車輛遠程狀態(tài)監(jiān)管系統(tǒng)中各類業(yè)務(wù)的誤碼率和時延要求不同,將北斗短報文分為三類:1) 故障報文;2) 消息報文;3) 狀態(tài)報文。

故障報文為車輛發(fā)生故障時將產(chǎn)生的故障碼信息,需要迅速做出處理,該類消息最為重要優(yōu)先級最高;消息報文為緊急狀態(tài)下車輛向后方技術(shù)陣地傳遞的預(yù)置信息或自定義內(nèi)容,通常為戰(zhàn)術(shù)或維修保障需要,優(yōu)先級中等;狀態(tài)報文是反映車輛實時狀態(tài)信息的數(shù)據(jù),為車輛大數(shù)據(jù)分析提供基礎(chǔ),可在采集終端緩存待信道空閑時傳輸,優(yōu)先級最低。每種報文通過報文ID規(guī)則區(qū)分,便于監(jiān)聽線程區(qū)分種類推送至不同優(yōu)先級緩沖隊列,處理線程根據(jù)隊列優(yōu)先處理0級隊列中報文信息。三類報文的優(yōu)先級為:故障報文(0級)>消息報文(1級)>狀態(tài)報文(2級),分別表示為P0、P1、P2,三種報文業(yè)務(wù)集合為P={P0,P1,P2}。通信服務(wù)器主線程優(yōu)先處理0級隊列中的報文,0級隊列中空時再處理1級隊列中報文。同時優(yōu)先級隊列的個數(shù)根據(jù)用戶報文ID規(guī)則動態(tài)生產(chǎn),當用戶增加報文優(yōu)先級時優(yōu)先級隊列數(shù)量隨即動態(tài)增加,增強系統(tǒng)擴展性。

2.2 線程池管理

通信服務(wù)器中共設(shè)計三類線:程監(jiān)聽線程、數(shù)據(jù)處理線程和存儲線程。服務(wù)啟動時主線程同時啟動多個監(jiān)聽線程,每個監(jiān)聽線程對應(yīng)一臺北斗接收機來處理車輛北斗衛(wèi)星定位系統(tǒng)發(fā)來的短報文,當監(jiān)聽到報文時,創(chuàng)建數(shù)據(jù)處理線程對報文數(shù)據(jù)進行拆包,負責存儲操作的線程則對多優(yōu)先級緩沖隊列中的數(shù)據(jù)按優(yōu)先級進行處理。過程中,應(yīng)用Java并發(fā)庫的Executor框架,利用其線程池的功能來管理線程。

另外,在將報文數(shù)據(jù)寫入后方優(yōu)先級隊列時,緩沖區(qū)是必須,若只設(shè)計一個緩沖區(qū),所有線程共享使用,會造成擁堵,各線程搶占資源,容易增加丟包率。若將緩沖區(qū)分散到每一個線程內(nèi)部,在代碼實現(xiàn)時,發(fā)現(xiàn)這種做法會增加程序耦合度,系統(tǒng)擴展性也會降低,在向后方隊列寫入數(shù)據(jù)時同樣會造成擁堵。因此,應(yīng)用多隊列同步緩沖隊列作為數(shù)據(jù)存儲以及處理的緩沖區(qū),為每三個監(jiān)聽線程分配一個緩沖隊列,可以避免程序耦合以及丟包率高等問題[12]。同時,監(jiān)聽線程獨享緩沖區(qū)確保監(jiān)聽實現(xiàn)性,數(shù)據(jù)處理線程和IO操作線程利用由Executor框架管理共享緩沖區(qū)提高資源利用。

2.3 通信流程設(shè)計

線程調(diào)度通信時序如圖3所示,當出現(xiàn)高優(yōu)先的報文時優(yōu)先推送到相應(yīng)級別的隊列中,并回復(fù)應(yīng)答幀,過程中監(jiān)聽線程對報文進行拆包分解,根據(jù)ID號區(qū)分優(yōu)先級加載到相應(yīng)緩沖隊列或者優(yōu)先級隊列。

圖3 通信握手流程

由于北斗短報文的通信是不可靠鏈接,沒用通信回執(zhí),發(fā)送方無法確定接收方是否開機,是否發(fā)送成功,在車輛狀態(tài)監(jiān)管系統(tǒng)中,對于故障信息這類高優(yōu)先級,采用丟包反饋重傳機制,當線程監(jiān)聽到P0類報文時,給需要接收方北斗一體機的不同應(yīng)答幀加以區(qū)分,接收方收到ACK-P時向發(fā)送方發(fā)送確認收到報文[13]。在通信流程上進行區(qū)分和預(yù)判,保證了在系統(tǒng)數(shù)據(jù)處理任務(wù)繁重時也能及時確保高優(yōu)先級信息及時準確地傳遞,并且不占用其他系統(tǒng)資源,不打斷其他線程的忙碌狀態(tài),解決了以往為保證重要信息傳遞造成的線程生命周期系統(tǒng)開銷大以及資源不足的問題。

3 通信服務(wù)器的實現(xiàn)

3.1 Java異步IO應(yīng)用

在Java的異步IO框架中,異步任務(wù)的完成需要使用線程,線程的創(chuàng)建與銷毀要一定的時空開銷,為每一個任務(wù)創(chuàng)建一個新線程來執(zhí)行可能會使通信服務(wù)器處于高負荷狀態(tài)最終崩潰,因此本文架構(gòu)的監(jiān)聽線程使用Java并發(fā)庫的Thread框架,數(shù)據(jù)處理線程使用Executor框架[14]。

為了滿足性能要求,監(jiān)聽線程采用Thread框架實現(xiàn)與北斗接收機的一一對應(yīng),這部分線程不會多次創(chuàng)建和撤銷,確保不被阻塞達到實時的監(jiān)聽,實現(xiàn)過程如圖4所示。

圖4 監(jiān)聽線程工作流程

當監(jiān)聽線程通過串口通信板卡收到北斗短報文到達時,主線程創(chuàng)建對象實現(xiàn)Runnable或者Callable接口,工具類Executors把一個Runnable對象封裝為一個Callable對象,然后可以把Runnable對象直接交給ExecutorService執(zhí)行ExecutorService.execute(Runnable command);或者也可以把Runnable對象或Callable對象提交給ExecutorService執(zhí)行ExecutorService.submit(Runnable task)或ExecutorService.submit(Callabletask)。如果執(zhí)行ExecutorService.submit,ExecutorService將返回一個實現(xiàn)Future接口的對象。由于FutureTask實現(xiàn)了Runnable,也可以創(chuàng)建FutureTask,然后直接交給ExecutorService執(zhí)行。最后,主線程可以執(zhí)行FutureTask.get()方法來等待任務(wù)執(zhí)行完成,至此完成了處理線程的動態(tài)創(chuàng)建,數(shù)據(jù)處理線程根據(jù)任務(wù)的多少和決定是否創(chuàng)建新的線程提高效率。具體工作原理如圖5所示。

圖5 處理線程工作原理

3.2 多優(yōu)先級緩沖隊列實現(xiàn)

多優(yōu)先級緩沖隊列選擇用Java并發(fā)庫中的ConcurrentLinkedQueue的非阻塞方法來實現(xiàn),過程中用CAS(compare and swap)算法代替隊列鎖,CAS在鎖的實現(xiàn)上只需要一步原子操作,性能損耗少,效率高[14]。實現(xiàn)代碼如下:

//+1操作

public final long getAndIncrement() {

while (true) {

long current=get();

long next=current+1;

if (compareAndSet(current,next))

return current;

}

}

//調(diào)用JNI實現(xiàn)CAS

public final boolean compareAndSet(long expect,long update) {

return unsafe.compareAndSwapLong(this,valueOffset,expect,update);

}

4 實驗測試和分析

4.1 實驗環(huán)境

為保證實驗的可靠性和有效性,實驗測試采用普通PC和Java語言實現(xiàn)通信服務(wù)器搭建,硬件環(huán)境選取酷睿i7處理器,3張串口通信板卡(1張RS232接口、1張RS422接口、1張RS485接口),每張板卡三路接口如表1所示。軟件環(huán)境采用操作系統(tǒng)CentOS7.0,Java語言(JDK1.8版本)進行編程。北斗接收機采用18臺BNTRE-320B北斗車載一體機,設(shè)備滿足指標要求:BD2/BD3上行為L頻段下行為S頻段,BD3全球短報文下行為L頻段,一次報文長度BD2為120漢字,BD3在RDSS服務(wù)區(qū)域不大于1 000個漢字,在僅具有全球短報文服務(wù)區(qū)域不大于40個漢字,誤碼率不大于10-5等其他需求,通信服務(wù)頻率為60 s/次[15]。

表1 通信服務(wù)器配置信息

4.2 RTT和丟包率比較

測試一組北斗接收機工作和九組同時工作時的采用單線程通信模式、Netty框架模式和本文通信服務(wù)器模式的延遲和丟包率,實驗結(jié)果如圖6、圖7所示。在一組接收機工作時,由于北斗短報文通信頻度(60 s/次)的限制,單線程的工作效率更高時延684 ms,采用本文模式的方法時延較長為783 ms,兩者丟包率接近,但隨著通信服務(wù)器上工作的接收機變多時,單線程方法傳輸時延和丟包率也明顯提高。在九組接收機同時工作時,單線程方法時延為9 425 ms,丟包率為3.48%,本文架構(gòu)的方法時延為1 267 ms,丟包率為0.5%,在性能上好于單線程方法,能夠滿足遠程監(jiān)管系統(tǒng)的時延需要。另外,可以看出Netty框架兩項數(shù)據(jù)較為穩(wěn)定,在只有一組通信終端時延時較高。

圖6 三種模式通信時延比較

圖7 三種模式丟包率比較

4.3 故障信息時效性比較

固定頻率在每組通信報文中傳遞故障碼報文來測試三種方法在故障報文時效性和準確性上的差別。固定每100組消息報文或狀態(tài)報文后發(fā)送一次故障信息報文,測試在9組通信終端同時工作的情況下故障信息的丟包率(每10分鐘計算一次),測試時間為60 h。從圖8的測試結(jié)果可知,隨著時間增長,傳統(tǒng)單線程方法表現(xiàn)出不穩(wěn)定性,丟包率較高,甚至出現(xiàn)四次10分鐘未收到報文的情況,Netty框架模型和本文架構(gòu)基本持平。

圖8 每10分鐘丟包率統(tǒng)計圖

經(jīng)過對時延和丟包率的綜合測試,本文架構(gòu)與傳統(tǒng)單線程方式和Netty框架相比數(shù)據(jù)傳輸時延降低了54.9%和5.2%,丟包率降低了69.2%和6.3%,傳統(tǒng)單線程模式性能較差,采用Netty框架實現(xiàn)較為復(fù)雜在9組終端的通信實驗中體現(xiàn)不出優(yōu)勢,反而時延較大,本架構(gòu)基本可以滿足車輛遠程車輛監(jiān)管系統(tǒng)的需要。

5 結(jié) 語

本文嘗試設(shè)計的通信服務(wù)器架構(gòu)經(jīng)過實驗驗證既能保證緊急報文及時達到,又解決了一對多的監(jiān)控和管理,通信時延較傳統(tǒng)方法有大幅度降低,與Netty框架相比更易于在北斗短報文傳輸相關(guān)系統(tǒng)中易于實現(xiàn),具有一定推廣意義。不足之處在并發(fā)量較大時,由于北斗通信終端的限制需要通過增加通信服務(wù)器數(shù)量來解決大規(guī)模并發(fā)問題。