特種車輛狀態監管系統中通信服務器的設計

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

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

0 引 言

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

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

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

1 特種車輛遠程狀態監管系統

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

圖1 特種車輛監控管理系統架構設計

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

2 通信服務器架構設計

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

圖2 通信服務器軟件架構

2.1 多優先級動態緩沖隊列

根據車輛遠程狀態監管系統中各類業務的誤碼率和時延要求不同,將北斗短報文分為三類:1) 故障報文;2) 消息報文;3) 狀態報文。

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

2.2 線程池管理

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

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

2.3 通信流程設計

線程調度通信時序如圖3所示,當出現高優先的報文時優先推送到相應級別的隊列中,并回復應答幀,過程中監聽線程對報文進行拆包分解,根據ID號區分優先級加載到相應緩沖隊列或者優先級隊列。

圖3 通信握手流程

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

3 通信服務器的實現

3.1 Java異步IO應用

在Java的異步IO框架中,異步任務的完成需要使用線程,線程的創建與銷毀要一定的時空開銷,為每一個任務創建一個新線程來執行可能會使通信服務器處于高負荷狀態最終崩潰,因此本文架構的監聽線程使用Java并發庫的Thread框架,數據處理線程使用Executor框架[14]。

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

圖4 監聽線程工作流程

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

圖5 處理線程工作原理

3.2 多優先級緩沖隊列實現

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

//+1操作

public final long getAndIncrement() {

while (true) {

long current=get();

long next=current+1;

if (compareAndSet(current,next))

return current;

}

}

//調用JNI實現CAS

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

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

}

4 實驗測試和分析

4.1 實驗環境

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

表1 通信服務器配置信息

4.2 RTT和丟包率比較

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

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

圖7 三種模式丟包率比較

4.3 故障信息時效性比較

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

圖8 每10分鐘丟包率統計圖

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

5 結 語

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