基于PROTOBUF 的火力指揮報文編解碼的研究與實現

魏 鑫，陳 勇，邢 欣，劉 冬，吳曉寧

（北方自動控制技術研究所，太原 030006）

0 引言

戰術信息指揮系統是數字化戰場中重要的一環，它以網絡通信為基礎，信息處理為核心，采用無線通信裝備及數據通信規程，為戰場指揮信息、態勢信息的傳遞提供了有效的支持［1］。為了保證帶寬受限的情況下指揮信息的有效傳達，需要使用高效的編解碼方式提高戰術數據報文的編解碼效率，使得編碼后的報文盡量占用極少的帶寬就能傳達大量的指揮信息，從而滿足報文實時性及安全性的需求。

戰術數據報文作為戰場的信息載體，是指揮系統進行數據交互的核心。如今的火力指揮報文信息主要由不同的字段按照報文中規定的格式依照先后順序進行簡單的拼接。這種方式導致報文格式固定化，不具備報文自組能力，報文長度難以壓縮。為了讓報文更加靈活，我軍廣泛采用可變報文格式（VMF）來進行報文的編解碼，VMF 報文中重要的字段可以多次重復，冗余的字段可以有選擇性地剔除，這使得編碼后的報文中基本不含無用信息，是一種高效的報文格式。但其對于配置文件的依賴性及維護成本較高，平臺遷移能力較弱并且編解碼耗時較長，所以需要一種優秀的編解碼方式來提高其在未來復雜戰場環境中對指揮信息的快速編解能力。

本文以VMF 報文標準為基礎，以火力指揮信息為示例，擬定了多種模擬報文，分析比較了多種情況下3 種編解碼方式對擬定報文進行編解碼的結果，最終證明了PROTOBUF 編解碼應用于火力指揮報文信息編解碼上的可行性與相對于VMF 編解碼及對象化的編解碼的優勢。

1 VMF 報文標準

1.1 VMF 的來源

可變消息格式（VMF）在20 世紀80 年代由美軍提出，最初稱為Link-16 的J 系列消息［2］，由FMF及VMF 兩部分組成，主要供美軍陸軍使用。1984 年美軍陸軍/海軍陸戰隊脫離了Link-16，將VMF 作為自己特化的消息格式來進行使用，并逐步完善其覆蓋的功能域，形成了如今的K 系列消息。如今我軍使用的K 消息涵蓋了陸地作戰、海上作戰、空中作戰及火力支援作戰等11 個功能域，在防空、直升機、空中突擊部隊、地空協同作戰中有廣泛的應用。

1.2 VMF 的靈活性

可變消息格式的靈活性主要得益于報文內部的“字段指示器”及“字段編號”。其內部的“字段指示器”可以分為4 類：FPI（字段出現指示器）、FRI（字段重復指示器）、GPI（組出現指示器）、GRI（組重復指示器）?！白侄沃甘酒鳌睕Q定了報文格式的靈活性，“字段編號”決定了報文內容的靈活性。

VMF 消息的一般格式由消息編號、消息標題、目的及消息主體構成［3］。如表1 所示。

表1 VMF 中K 系列消息的一般格式

VMF 強大的靈活性決定了其占用較小的空間就可以表達大量的信息，保證了戰術數據報文在野戰場環境下的實時性與生存性。

1.3 VMF 的不足

VMF 近年來在戰場指揮中的表現展現了其優越性，被軍隊廣泛采用，但其在應用方面的不足之處也逐漸暴露出來。VMF 強大的靈活性建立在復雜的數據字典及腳本文件的基礎之上，數據字典包含了每個字段的詳細信息，腳本文件決定了報文的內部結構。其對數據字典及腳本文件的依賴性導致編解碼服務平臺遷移能力較弱；不同的軟件各自的腳本文件及數據字典文件使用不同加密方法，導致通用性較差，維護成本較高；由于編解碼時需要與數據字典進行大量的交互，導致編解碼時間較長。

2 編解碼方式的比較

本文將比較面向字符的對象化的編解碼（與當前火力指揮報文編解碼類似），面向比特的VMF 編解碼以及PROTOBUF 編解碼3 種方式各自的優劣以及在不同的環境下的適用性，以此來分析與火力指揮報文編解碼的契合度。

2.1 對象化的編解碼方法

對象化的編解碼方式將實體對象，對象動作，對象動作的詳細說明信息放在數據庫中，通過將3類信息進行拼接，形成一條報文數據。借助類XML格式將報文信息進行存儲以及發送，其信息組合的靈活性極強，報文成文的可讀性較高，對于配套文件的依賴性較弱，但其每條報文所占比特較多，在帶寬較充裕時是一種方便的報文傳遞方式，在云端有著良好的應用。

圖1 對象化編解碼流程

2.2 VMF 編解碼方法

VMF 編解碼相對于對象化的編解碼更為復雜高效，同時需要的依賴項也更多。

首先編解碼服務讀入報文腳本文件，然后根據標簽的順序及比特長度確定結構體信息的順序及所占位數，然后按照數據字典中為字段定義的編碼規則，將用戶值壓制為編碼值后排列在編碼結果的二進制序列中。最終形成“標志位+信息主體+標志位+信息主體……”的序列。解碼原理即為編碼原理的逆操作［4］。

其編解碼流程如下：

首先選擇需要使用的報文，獲得報文標識號，編寫報文格式的腳本文件及報文結構體，將需要添加的字段添加在字段數據庫中并生成相應的字典文件，至此生成一條新報文的前期工作全部完成。

在完成準備工作后，應用軟件需要將合法的信息填入報文結構體中。在完成結構體的編寫后需要使用編解碼服務提供的報文結構校驗功能來對結構體進行校驗，當校驗正確后才可進行編碼［5］。

圖2 VMF 編解碼流程

2.3 PROTOBUF 編解碼方法

XML 以及JSON 是使用最為廣泛的兩種數據格式，由于其可識別標簽的存在，可以輕易地解讀其存儲的信息，在不要求加密、不限制帶寬的情況下是優秀的信息存儲結構。但由于標簽的存在，信息中的非標簽核心信息所占的比例相對較低，這樣的數據結構對于信道的浪費程度較高，在帶寬受限的情況下無法與VMF 等報文格式相提并論。所以本文以JSON 為信息模板，將其轉化為報文對象信息，使用PROTOBUF 方式進行編解碼，PROTOBUF 編解碼的核心思想便是在編碼后的報文中削減非核心信息所占的比例，通過使用極少的字節表示標簽信息來提高對核心信息所占的比例，與VMF 的“字段指示器”有異曲同工之妙。

圖3 PROTOBU 編解碼流程

2.4 編解碼方式比較

在使用體驗方面，對象化的編解碼方式需要準備對象數據庫，編碼過程簡單，依賴較少，可移植性較強，維護成本較低，可擴展性較強，但編碼結果所占比特較大。VMF 編解碼需要準備數據庫、數據字典文件、數據結構腳本文件、結構體文件，依賴較多，可移植性一般，維護成本較高，可擴展性強，編碼結果優秀。PROTOCOL 編解碼需要準備對象協議文件、編解碼文件，依賴較少，可移植性極強，維護成本較低，可擴展性強，編碼結果優秀，如表2 所示。

表2 編解碼方式綜合性能比較

3 PROTOBUF 編解碼原理及實現

3.1 PROTOBUF 編解碼原理

PROTOBUF 是一種高效的序列化字節信息的協議，本文在其基礎上進行了向結構化報文信息編解碼方向的應用，并且以指揮系統及火力平臺通信報文為基礎進行了實現。

PROTOBUF 定義了協議對象文件，文件中的每個字段由修飾符、字段類型以及域號3 部分組成。在編碼時，PROTOBUF 按照“Tag-Value-Length”的格式來編碼每一個字段，其中，Tag 是數字標簽，Value 是數據內容，Length 是數據的長度，如果字段是整型會將Length 部分省略。編碼后的信息是與VMF 報文信息類似的二進制字符串，其結果為“數字標簽+數據內容+數字標簽+數據內容…”。

數字標簽的編碼格式是將協議對象文件中給每個字段定義的域號與字段類型進行轉換而成，其轉換公式為：

（域號＜＜3）|字段類型

其對應關系如表3 所示。

表3 域號與字段類型對應關系表

數據內容的編碼方式要根據數據類型來進行選擇，其選擇方式如下頁圖4 所示。

圖4 PROTOBUF 數據處理流程

當數據內容是int32 類型的數據時，采用可變長的Varint 編碼方式，只用一個字節來表示數據內容。Varint 中每個字節的最高位bit 表示此byte 是否為最后一個byte。1 表示后續的byte 也表示該數字，0 表示此byte 即為最后一個byte，與VMF 重復標簽使用方式相同。例如264 使用Varint 編碼方式為1000 1000 0000 0010。詳解如圖5 所示。

圖5 Varint 算法圖示

其特殊之處在于解析時首先將兩個byte 位置互換，因為字節序采用了little-endian 方式。在這種編碼方式下如果有符號數出現，那么符號數的最高位通常表示正負的特性，會導致Varint 表示一個帶符號數無論大小都需要用5 個byte，例如-2 的Varint 編碼會變成010 010。由于對于有符號的數Varint 的編碼效果較差，所以引入了Zigzag 編碼來解決有符號數的編碼問題。

《Huffman 編碼》證明了壓縮編碼應該滿足：高概率的碼字字長應不長于低概率的碼字字長［6］。一般情況下，指揮數據傳輸使用較多的是小整數，那么較小的整數應該使用更少的byte 來編碼。Zigzag編碼將數字按照其絕對值進行升序排序，將整數通過一個hash 函數：

（如果是長整型則使用h（n）=（n＜>63））

將整數轉換為遞增的bit 流。Zigzag 編碼在進行負數的編碼的時候，會將其補碼的第一位放在最后一位，在這種情況下，越小的數字補碼的高位就會有越多的1，為了處理這種情況，Zigzag 會將所有負數的數據位按位求反，符號位保持不變，這樣的話，越小的數字其高位就會有越多的0，編碼時會將0舍棄掉，最終達成以較少的位來存儲絕對值較小的負數的目標。數據通過轉換之后便可以再次通過Varint 編碼形成序列化的字符串，最終對數字類型的數據全部完成編碼。

在報文信息中，為了壓縮報文的長度，漢字信息一般使用枚舉值來表示，將漢字信息轉換為枚舉值后，便可按照整數型數據的編碼方式對其枚舉值進行編碼。最終完成對整條報文信息的編碼［7］。

3.2 PROTOBUF 編解碼實現

首先按照報文內容編寫對應的對象協議文件，本文件的主要作用是對報文中字段的類型、數據類型、字段名以及域號進行編寫，然后用于后續編解碼文件的生成。其字段類型主要分為3 類：Optional（其信息可為空值）、required（其信息不可為空）、repeated（其信息會重復出現），與VMF 報文中字段出現標志作用相同［8］。

以下部分為火力指揮模擬報文對象協議文件實現片段實例：

標簽的選擇性使用決定了一條報文模板可以衍生出多種不同的報文，滿足不同使用條件下對報文字段的靈活選擇。在編寫完成對象協議文件之后需要使用protoc 命令對其進行編譯，編譯的結果是對象協議文件對應的頭文件（.pb.h）及代碼實現文件（.pb.cc）。

根據對象協議文件的格式，本文采用JSON 作為報文數據存放結構，在開發時擁有較高的可讀性，降低了二次開發難度，并且與基于WEB 的B/S架構軟件具有較高的兼容性，利于火力指揮系統軟件的平臺遷移及前后端信息交互，通過轉換工具將JSON 數據信息賦值到message 對象中即可開始編碼。當然，本編解碼方式亦可直接將信息寫入message 對象進行編解碼。

4 實驗結果

4.1 火力指揮報文特點及需求

火力指揮報文與態勢圖報、定位報、狀態報等報文相比，其報文結構較為簡單，報文內容復雜度低，便于戰場上進行實時傳輸以及并發處理。

在當前指揮系統的傳輸條件下，256 B 以下的報文可以實現近等時的傳送延遲，能夠保證不同接收端接收到報文所需要的延遲近似相等，并且可以進行雙點高并發實時傳輸，所以短報文長度在編碼后應盡量低于256 B，大多數情況下編解碼時間應在10 ms 以內。面對1 000 次/s 的高并發處理的極端情況，編解時間需要降低至1 ms 以下。

對于長度為1 kB 以下的中等長度報文傳輸時延在50 ms 以內，此時要求編解碼時間應在50 ms內。對于長度為1 kB～10 kB 的長報文傳輸時間在2 s以內，此時對于編解碼時間的要求更為寬泛，在500 ms 以內即可。

4.2 實驗過程及結果

為了對3 種編解碼的實際應用效果進行比較，擬制了4 種模擬報文并進行編解碼測試［9-10］。模擬報文以VMF-K 系列報文為基礎，包含多種類型的字段，長度各異，具有多層嵌套關系，主要包含位置信息、時間信息、火力打擊信息及氣象水文信息?，F擬制如下4 條報文：

報文1：結構長度較短，不包含重復信息，所有信息不為空。主要驗證短報文使用的可行性，與現實使用方式類似。

報文2：結構長度中等，包含重復信息，空信息與實信息交叉存在。主要驗證報文長度適中狀況下編解碼方式的表現。

報文3：結構長度較長，包含大量重復信息，重復信息大量為空。主要驗證編解碼方式對無用信息的處理效果。

報文4：結構長度較長，包含大量重復信息，重復信息不為空。主要驗證編解碼方式在處理長報文時的表現。

編碼方式1：對象化編解碼

編碼方式2：VMF 編解碼

編碼方式3：PROTOBUF 編解碼

報文1 測試結果：

表4 報文1 測試結果

報文2 測試結果：

表5 報文2 測試結果

報文3 測試結果：

表6 報文3 測試結果

報文4 測試結果：

表7 報文4 測試結果

圖6 壓縮比例對比圖

圖7 表示相同信息需要的報文大小對比圖

通過實驗發現，經過VMF 編解碼方式及PROTOBUF 編解碼方式處理過的報文在大小方面相差無幾，可以滿足火力指揮報文信息帶寬受限條件下的使用。在編解碼時間方面，三者均在ms 級，可以滿足正常情況下的使用，由于PROTOBUF 編解碼耗時較VMF 編解碼更短，在應對大批量報文方面有著更好的表現。綜上所述，目前的對象化編解碼無法勝任火力指揮報文信息在野戰場的編解碼，VMF編解碼與PROTOBUF 編解碼在戰場環境中的生存性較強。結合本文2.4 節中的比較結果，PROTOBUF編解碼的綜合性能更加契合火力指揮報文信息的需求。

5 結論

本文將JSON 與PROTOBUF 編解碼相結合，通過分析其編譯原理，提出了不同于現有方式的輕量化的戰術數據報文編解碼實現方式，并將其應用在火力指揮信息的報文處理中。解決了火力指揮報文模板固化，內容過長的問題，并且支持復雜戰場環境高并發的報文編解碼。編碼后報文信息安全性極高，文件依賴性較弱，平臺遷移能力極強，只需要將編譯后的編解碼文件部署在新設備上即可對報文進行編解碼，相比于VMF 編解碼操作更為簡單，維護成本更低，更加契合火力指揮系統的現實要求。