随着装备信息化建设的不断推进，特种车辆的维修保障和管理信息化要求也不断提高。车辆状态信息作为表征车辆实时状态的关键数据，对车辆的维修保障提供了有效支撑。通过调研发现，特种车辆常在特殊陆地、山区和海岛执行野外作战(驻训)，当传输距离较远时，车载通信电台和天线的便携性和可靠性极大下降，不能满足车辆状态远程传输的需求。另一方面，虽然目前绝大部分轮式特种车辆配备了北斗卫星导航系统，该系统具有独特的短报文收发功能[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中报文内容的细化。具体字节空间分配策略如下：
表1 外设至用户机信息传输格式
指令长度用户地址信息内容校验和定位申请$DWSQ16 bit24 bit信息类别8 bit高程数据和天线高32 bit气压数据32 bit入站频度16 bit8 bit通信申请$TXSQ16 bit24 bit信息类别8 bit用户地址24 bit报文长度16 bit是否应答8 bit报文内容(最长1 680 bit)8 bit
表2 短报文空间分配表
电文内容数据包编号是否连续数据包特种车辆类型设备终端编号位置信息(包含时间戳)开机时长车辆关键状态信息(本文取56 Byte)8 bit2 bit6 bit16 bit128 bit16 bit45 Byte
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 位置信息协议格式
T32 bithms0.01 sL32 bit°'″0.1″B32 bit°'″0.1″H16 bit±MζH16 bit±M88888888888821488
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 特种车辆关键状态信息编码
数据项序号数据内容值说明1任务执行状态(0,9)按任务分类2武器系统状态(0,1)0故障1良好3关键部位温度(轮毂、轴承)(-100,+100)4胎压(0,20 000)5车速(0,200)6发动机转速(0,20 000)7燃油量(0,200)8备品备件数量(0,3 000)9发动机单次工作时长H10车辆整体健康状态(0,100)百分数︙︙︙︙
2 动态索引码表编码方案设计与实现
车辆状态信息中连续相同的字符出现概率较低，而较短时间间隔的前后两次采集到的数据中部分不变化，将被多次重复传输。因此，基于短报文字节空间的分析，考虑简单易实现及可靠性的要求，提出了动态索引码表编码方案。
2.1 动态索引表编码
该编码方案只传输车辆关键状态信息中变化的部分。这要求在车辆发送状态信息时，标识哪些数据发生了变化，在传输车辆状态信息之前，先传输索引码表，标识哪些数据项发生了变化，再传输车辆状态信息中时序上前后两次发生变化的数据项。接收方数据中心通过索引码表确定变化的数据，并进行分析处理。
假设有一组数据如表5所示，表中所列为较前一次发生变化的数据项，索引码表和车辆关键状态信息数据映射关系实例，如图1所示。
表5 特种车辆关键状态信息实例数据
序号内容高字节位低字节位备注3关键部位温度(轮毂、轴承)1000000000111100+60 ℃5车速000000000010001135 km/h6发动机转速00001000001101002 100 r/min7燃油量000000000011010153 L20用户自定义数据1110011000111111
图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 原始数据传输测试结果
序号测试项Ping最大值/msPing最小值/msPing平均值/ms接收数丢包数丢包率/%120 97012 14316 55745614431.58221 00810 08715 54843116939.21321 72611 20616 46644915133.63418 70511 07514 89046713328.48520 32913 29816 81445214832.74平均20 54811 56216 05545114933.04
表7 压缩数据传输测试结果
序号测试项Ping最大值/msPing最小值/msPing平均值/ms接收数丢包数丢包率/%15 5712 2873 929556447.9125 4472 3473 8975366411.9435 1692 2143 6925297113.4244 6022 5863 594577233.9955 8912 0023 946567335.82平均5 3362 2873 812553478.50
3.2 编码压缩和解压测试
表8是原始数据传输、Huffman编码后传输、LZW算法传输、索引码表方法压缩后传输的测试结果比较。压缩率是数据压缩的重要指标，表示数据的无损压缩程度；传输出错率是指经过压缩、传输、解压后无法解析的数据占机载终端传送数据的比例；传输丢包率是解压后未接收到的数据总量占机载终端传送数据的比例[13]。按照车载数据采集终端与传输标准要求，取3组特种车辆状态数据作为测试数据源，将原始数据传输与3种压缩后传输的数据结果进行比较。实验重复操作100次，综合各种环境条件(包括低温、高温、高海拔、异常位置等)取平均值。考虑到应用地点多为山区或海滩，其在接收北斗信号时数据质量可能受到一定的影响，连续在多地进行测试[14-15]。
表8 数据压缩测试结果
序号数据类型数据集编号压缩传输数据长度Byte压缩率/%数据传输出错率/%数据传输丢包率/%1原始118706.038.302原始215605.848.453原始313304.857.814Huffman1167115.635.365Huffman213414.104.504.966Huffman31219.024.604.067LZW113726.743.594.148LZW212420.514.372.749LZW311315.043.353.0910索引码表编码16664.711.591.1811索引码表编码25564.741.210.6212索引码表编码34367.671.160.24
由表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%，证明压缩传输方法减小了数据包长度，提高了数据压缩率和传输效率，该方法可为特种车辆关键状态信息“全天候、全地域、全过程”的监控管理提供支撑。下一步计划采用北斗通信指挥机作为接收端模块，配合“并发”数据采集与传输设备实现同时对多个特种车辆编队进行状态监控。
[1] 信方硕.基于北斗短报文的卫星远程教育系统资源订阅协议[D].呼和浩特：内蒙古大学,2019.
[2] 吕炳赟.常用无损数据压缩算法的分析及研究[J].电子世界,2019(04):5-6.
[3] 蒋鹏，吴建峰，吴斌，等.基于自适应最优消零的无线传感器网络数据压缩算法研究[J].通信学报,2013,34(02)：1-7.
[4] 罗坚,蒋国荣,姜勇强,等.海洋格点数据的无损压缩新方法[J].海洋预报,2011,28(03):55-61.
[5] 刘委.基于LZW算法的发动机参数实时采集系统的实现[D].镇江：江苏大学,2016.
[6] KALAIYARASI D,KALPALATHA R T.Design and implementation of Least Mean Square adaptive FIR filter using offset binary coding based Distributed Arithmetic[J].Microprocessors and Microsystems,2019(71)：102884.
[7] 王翾,谢廷俊,陆建华.一种二进制算术码的软解码算法[J].电子学报,2007(02):283-286.
[8] 杨可.一种具有随机存取能力的压缩编码技术[D].合肥：中国科学技术大学,2019.
[9] 柯秋立,苏凯雄.北斗通信终端软件的设计与实现[J].微型机与应用,2017,36(10):15-17+22.
[10] 黄柏铭.卫星数据压缩[M].哈尔滨：哈尔滨工业大学出版社,2015:1-5.
[11] 陈勇.基于北斗短报文通信的过程数据压缩方法[D].秦皇岛：燕山大学,2017.
[12] 辛洁,陈茜,郭睿,等.北斗三号与北斗二号基本导航电文参数比较[J/OL].测绘科学，2020(01):1-9.
[13] 杨敬锋,张南峰,李勇,等.基于改进Huffman编码的农机作业数据传输压缩方法[J].农业工程学报,2014,30(13):153-159.
[14] 刘春玲,张自豪.北斗接收机在干扰下的性能研究[J].计算机科学,2017,44(02):163-166,170.
[15] 颜晓星,车明,高小娟.基于北斗卫星的可靠远程通信系统设计[J].计算机工程,2017,43(03):62-68.