基于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（组重复指示器）。“字段指示器”决定了报文格式的灵活性，“字段编号”决定了报文内容的灵活性。

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 系列报文为基础，包含多种类型的字段，长度各异，具有多层嵌套关系，主要包含位置信息、时间信息、火力打击信息及气象水文信息。现拟制如下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 编解码操作更为简单，维护成本更低，更加契合火力指挥系统的现实要求。