基于北斗短報文的特種車輛狀態信息壓縮傳輸方法研究

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

(海軍航空大學 岸防兵學院, 山東 煙臺 264001)

隨著裝備信息化建設的不斷推進，特種車輛的維修保障和管理信息化要求也不斷提高。車輛狀態信息作為表征車輛實時狀態的關鍵數據，對車輛的維修保障提供了有效支撐。通過調研發現，特種車輛常在特殊陸地、山區和海島執行野外作戰(駐訓)，當傳輸距離較遠時，車載通信電臺和天線的便攜性和可靠性極大下降，不能滿足車輛狀態遠程傳輸的需求。另一方面，雖然目前絕大部分輪式特種車輛配備了北斗衛星導航系統，該系統具有獨特的短報文收發功能[1]，但是，短報文服務主要用于簡單預置信息的傳遞，以常用的北斗SIM卡為例，單次報文長度僅為78.5 Byte，通信頻率為60 s/次，而且無通信回執。通過北斗短報文進行車輛狀態信息傳輸時必須進行分包，極大的降低了傳輸的實時性和可靠性。總之，現有車載通信方式與車輛狀態數據遠程傳輸需求之間的矛盾日益凸顯。

車輛狀態信息壓縮編碼屬于無損壓縮范疇，常用的算法有游程編碼RLE(run-length encoding)算法、字典編碼LZW(Lempel-Ziv-Welch)算法、Huffman編碼算法和算術編碼算法[2-3]等。通過研究發現，游程編碼RLE壓縮效果的好壞決定于原數據串的結構，數據串中如果存在大量連續相同字符，將獲得很高的壓縮比[4]。LZW編碼對于重復率較高的信號壓縮效果好[5]。Huffman編碼和算術編碼屬于基于統計特性的編碼方法，計算復雜度高，主要應用于圖像和視頻信號壓縮[6-8]。車輛狀態信息極少存在連續相同的字符，且數據動態性較強，以上四種算法均無明顯優勢。因此，為了在有限的報文長度范圍內對車輛狀態信息數據進行壓縮傳輸，本文從特種車輛狀態信息編碼入手，設計了一種適用于北斗短報文傳輸的動態索引碼表編碼方法。

1 北斗短報文空間分配策略

車輛狀態信息進行壓縮傳輸時，為了避免直接傳輸信息造成的空間浪費，需要根據北斗短報文傳輸協議對信息進行編碼。

1.1 北斗報文字節空間分配策略

根據“北斗用戶機接口協議4.0“版[9-10]內容，短報文信息傳輸格式如表 1所示，報文內容最長217 Byte。針對不同車載北斗設備通信能力的不同，考慮到北斗三代報文長度升級以后的兼容性問題，取現有特種車輛中北斗收發機報文長度最短的78 Byte，即表1中通信申請指令下信息內容的長度在本文中設定為78 Byte。

短報文空間劃分如表2所示,即對表 1中報文內容的細化。具體字節空間分配策略如下：

表2 短報文空間分配表

1) 數據包編號。數據包編號長度為8 bit，主要用于短報文丟包時，數據中心根據數據包編號申請數據采集終端重傳數據。

2) 是否連續數據包。針對特殊情況，一次數據傳輸不能發送全部數據的情況，分配2 bit進行標識，00表示獨立幀，11表示連續幀，接收機做好接收后續數據的準備，出現01或者10時可識別為丟幀。

3) 特種車輛類型。根據車輛任務種類和使用者需求自行編碼，考慮到擴展性便于添加和刪除種類，采用6 bit描述特種車輛種類。例如，1型導彈發射車編為000001，2型步戰車編為100001，以此類推。

4) 設備終端編號。車載信息采集終端中的設備唯一標識碼UUID，表征設備合法性和唯一性，綁定車輛牌照和編號，分配16 bit。

5) 位置信息。位置信息包括精度、緯度和高度，由北斗導航系統獲得的位置信息編碼格式如表3所示，位置信息精度要求較高，根據協議中規定的報文格式，選取時間、經度、緯度以及高度(H為高度數據，ζH為高度異常值對高度數據進行誤差修正)作為要素進行發送，此幀格式將北斗授時的時間結合到數據包中，增加準確性。

表3 位置信息協議格式

6) 開機時長。以分鐘為單位，記錄采集設備連續開機時長，采集設備工作時長與發動機工作時長相關，便于設備和車輛在定檢和修理計劃制定時參考，分配2個字節來表示，每次設備開機時將時間清零重計。

7) 車輛關鍵狀態信息。 車輛關鍵狀態信息主要包括車輛健康狀態(百分數)和武器系統狀態信息等，最長為56 Byte，取45 Byte，預留11 Byte作為用戶自定義。

1.2 車輛關鍵狀態信息編碼

根據1.1中前1～6的字節空間分配結果，解決問題的關鍵是如何在后續56 Byte的空間限制條件下，一次盡可能多的傳遞車輛狀態信息。車輛關鍵狀態信息編碼如表 4，各項數據的值用兩個字節足夠完全表示，考慮到誤碼的情況，將只有0和1的數據項用全0和全1表示。如武器系統狀態用65535表示良好，0表示故障，溫度值用最高位標志正負,車輛整體健康狀態用百分數表示，根據車載PHM系統計算得出。

表4 特種車輛關鍵狀態信息編碼

2 動態索引碼表編碼方案設計與實現

車輛狀態信息中連續相同的字符出現概率較低，而較短時間間隔的前后兩次采集到的數據中部分不變化，將被多次重復傳輸。因此，基于短報文字節空間的分析，考慮簡單易實現及可靠性的要求，提出了動態索引碼表編碼方案。

2.1 動態索引表編碼

該編碼方案只傳輸車輛關鍵狀態信息中變化的部分。這要求在車輛發送狀態信息時，標識哪些數據發生了變化，在傳輸車輛狀態信息之前，先傳輸索引碼表，標識哪些數據項發生了變化，再傳輸車輛狀態信息中時序上前后兩次發生變化的數據項。接收方數據中心通過索引碼表確定變化的數據，并進行分析處理。

假設有一組數據如表5所示，表中所列為較前一次發生變化的數據項，索引碼表和車輛關鍵狀態信息數據映射關系實例，如圖1所示。

表5 特種車輛關鍵狀態信息實例數據

圖1 索引碼表和實際數據項映射關系示意圖

索引碼表的字節空間分配為5個字節，共40位，最多一次可表征20項車輛狀態信息，基本滿足需求。從左起，首2位與第一項車輛狀態數據相關聯，其后2位與第2項車輛狀態數據相關，依次類推。與索引碼表的位對應，車輛狀態數據從左起，首2個字節表示第1項車輛狀態數據的低位字節和高位字節，接著2個字節表示第2項車輛狀態數據，依次類推。

因此，圖2所示的車輛狀態數據的索引碼表的5個字節，由左到右分別是：0C、40、00、00和03。車輛狀態數據中的10個有變化的字節分別是：80，3C，00，23，08，34，00，35，E6和3F。經過該方法壓縮后的編碼為

0C，40，00，00，03，80，3C，00，23，08，34，00，35，E6和3F

圖2 索引碼表示意圖

此時這條數據采用該模式后只需要15個字節，來表示一次傳輸的車輛狀態信息數據。由于索引碼表固定需要5個字節，假設項車輛數據都有，最大需要字節數為5+2β，最小需要字節為5+2。當β=10時，最大需要字節數為5+2β=25個字節。以此類推，當剛好等于20時，最大需要5+2β=45個字節，未超出最大字節空間45 Byte。

2.2 基于索引碼表的Huffman編碼方案

在圖2所示實例的索引碼表中，從最左邊開始，每相鄰的2個位有4種狀態：00、10、11和01，分別用S0、S1、S2和S3依次表示。若車輛狀態信息數據中包含很多兩次傳輸間不發生變化的字節，即為0的字節，相應地在索引碼表中也出現很多為0的位。

一般地，各車型一次發生變化的數據小于10種，即有(20-10)/20=50%以上概率是S0態。假設狀態出現概率從大到小的次序分別是：S0、S1、S2和S3。這種狀態出現概率不一樣的情況非常適合采用Huffman編碼。其方法是：S0 編碼為0，S1 編碼為10，S2 編碼為110，S3 編碼為111。

以圖2所示實例中的索引碼表為例，其狀態表為：S0、S0、S1、S1、S2、S0(25個)、S2和S0。按照Huffman編碼方法，其使用1×28+2×2+3×2=38 bit，而原索引碼表固定為40 bit，節省了2個字節。

但是字節空間的節約是以解碼端計算時間增加為代價的，在字節空間夠用的情況下，不建議采用Huffman編碼方案，增加時間開銷[11]。在用戶自定義編碼的方案下，索引碼表過長時可采用這種方法。

2.3 編碼方案的實現

車輛狀態信息采集端是基于STM32的編解碼終端，連接北斗接收機收發報文，接收端數據中心采用中型工作站連接接收機進行報文收發，計算處理能力較強，但并發性要求較高，其數據傳輸程序軟件設計一般流程如下：

1) 采集終端系統啟動，初始化數組，定義一個U8型數組Index[5]來記錄索引碼表；一個U8型數組Car_Info[40]存儲當前車輛關鍵狀態信息，Car_Info_Old[40]存儲上一次信息；根據不同信號的北斗接收機定義靜態SData作為發送緩沖區，靜態RData作為接收緩沖區。

2) 將采集得到的數據，賦值到Car_Info[40]，準備比較。

3) 檢測是否開機第一次發送，是的話Index[5]置1，Car_Info_Old[40]置0，并跳轉到5。

4) 依次比較Car_Info[40]與Car_Info_Old[40]的數據內容，有變化的將對應關聯位的Index[5]置1。

5) 根據上表1、2和4的數據格式，開始打包SData，封裝SData[0]～SData[11]數據包頭。

6) 在第一節的字節空間分配策略中，從SData[12]開始編寫，其中從12～33共22個字節的數據表示了電文內容前6項指定值，從SData[34]開始索引碼表，共5個字節，對應圖3進行封裝數據包。將Index[5]和Car_Info[40]對應需要發送的數據拼接，賦值到SData并發送。

7) 等待數據包接收到的回傳消息，并根據下次通信指令，循環到2)步。

圖3 報文幀格式和數組對應關系示意圖

3 驗證與分析

為驗證上述壓縮傳輸的方法，使用兩臺BNTRE-320B北斗車載一體機進行試驗，測試環境如圖4所示。為保證試驗的可靠性和有效性，采用的北斗設備滿足指標要求：BD2/BD3上行為L頻段下行為S頻段，BD3全球短報文下行為L頻段，一次報文長度BD2為120漢字，BD3在RDSS服務區域不大于1 000個漢字，在僅具有全球短報文服務區域不大于40個漢字，誤碼率不大于10-5等其他需求[12]。在實驗中，兩臺北斗一體機的SIM卡報文權限相同，通信服務頻率為60 s/次。

圖4 測試環境搭建

3.1 RTT測試

數據傳輸中的時延通常使用往返時間來(Round-Trip Time，RTT)評估，RTT由鏈路的傳播時間、終端處理時間和緩沖區排隊時間三部分組成[13]。現選取5組特種車輛執行任務過程中產生的真實連續狀態信息進行數據上傳RTT測試，數據均為未經過壓縮的原始數據。測試區域北斗衛星信號良好，天氣良好。對原始數據和經過編碼壓縮后的數據分別進行5次傳輸取平均值，并對結果進行分析。

表6中可看出：原始數據傳輸過程中由于漢字未編碼和壓縮需要進行分包傳輸，傳輸延遲嚴重，也產生了較為嚴重的丟包，平均丟包率在33.04%，平均時延在16.055 s，甚至出現一組數據的傳輸失敗。表7是利用通信用戶機編解碼終端對原始數據編碼并壓縮后進行的數據傳輸測試，平均丟包率在8.50%左右，平均時延在3.812 s，無傳輸失敗數據。可知，原始數據的分包直接傳輸易導致數據不完整，一次傳輸數據量少時丟包數較少，驗證了編碼可以大大提高數據的傳輸效率。

表6 原始數據傳輸測試結果

表7 壓縮數據傳輸測試結果

3.2 編碼壓縮和解壓測試

表8是原始數據傳輸、Huffman編碼后傳輸、LZW算法傳輸、索引碼表方法壓縮后傳輸的測試結果比較。壓縮率是數據壓縮的重要指標，表示數據的無損壓縮程度；傳輸出錯率是指經過壓縮、傳輸、解壓后無法解析的數據占機載終端傳送數據的比例；傳輸丟包率是解壓后未接收到的數據總量占機載終端傳送數據的比例[13]。按照車載數據采集終端與傳輸標準要求，取3組特種車輛狀態數據作為測試數據源，將原始數據傳輸與3種壓縮后傳輸的數據結果進行比較。實驗重復操作100次，綜合各種環境條件(包括低溫、高溫、高海拔、異常位置等)取平均值。考慮到應用地點多為山區或海灘，其在接收北斗信號時數據質量可能受到一定的影響，連續在多地進行測試[14-15]。

表8 數據壓縮測試結果

由表8可知，動態索引碼表編碼壓縮方式具有計算量少、壓縮效率較高的優勢，適合車輛狀態信息在北斗短報文方式中進行數據傳輸。LZW算法在全局或局部相關性好的數據有較好的壓縮率，但由于車輛狀態信息數據字段之間相關性較小，使其壓縮效率相對索引碼表編碼算法并無優勢。

為了進一步驗證數據壓縮方法，說明數據傳輸前后數據的完整性情況，本文對比了解壓數據與原始數據。本文車輛狀態信息中的車速數據為例，比較經過編碼壓縮傳輸與原始數據的差異，讀取服務器收到的數據文件后進行解壓和反量化，實現數據對比。需要說明的是，所用的測試數據為某特種車輛從早上8∶00—10∶00執行任務期間的車速數據，采集周期為60 s，所產生的數據為117條(理論值應為120 條，存在3條錯誤、丟失以及沒有采集的數據樣本)。

從圖5可以看出：除極少速度數據由于編碼、傳輸等原因造成速度值存在誤差外，大部分速度數據均與傳輸前保持一致。車載采集終端所發送的120條速度數據中，共有117條數據能夠準確解析，準確傳輸并解析的數據比例達97.50%，基本滿足實際應用要求。3條錯誤、丟失以及沒有采集的數據樣本中，丟失數據1條，丟包率占總量的0.008 3%，由于各種原因沒有采集數據為2條，占應采數據總量的0.016 7%。以速度數據為例驗證壓縮、傳輸算法的可用性試驗結果表明，該算法具有較高的效率以及傳輸完整性。

圖5 原始數據與壓縮傳輸并解壓后數據對比

4 結論

設計了數據包幀格式，研究了采用索引碼表的方式對數據壓縮率和傳輸成功率的影響，給出了在采集端和數據接收端軟壓縮方法的實現流程，在有限短報文空間中傳輸具備一定特點的特種車輛關鍵狀態信息。實驗結果表明：在一般實驗環境下，準確傳輸并解析的數據比達97.50%，證明壓縮傳輸方法減小了數據包長度，提高了數據壓縮率和傳輸效率，該方法可為特種車輛關鍵狀態信息“全天候、全地域、全過程”的監控管理提供支撐。下一步計劃采用北斗通信指揮機作為接收端模塊，配合“并發”數據采集與傳輸設備實現同時對多個特種車輛編隊進行狀態監控。