特种车辆状态监管系统中通信服务器的设计

樊辉锦 欧阳中辉 陈青华 胡道畅

(海军航空大学岸防兵学院 山东 烟台 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框架相比更易于在北斗短报文传输相关系统中易于实现,具有一定推广意义。不足之处在并发量较大时,由于北斗通信终端的限制需要通过增加通信服务器数量来解决大规模并发问题。