基于车载异构网络的数据聚合终端设计

陆建荣，石怀峰

(1.江苏航空职业技术学院 航空工程学院，江苏 镇江 212134；2.南京信息工程大学 电子与信息工程学院，江苏 南京 210044)

0 引言

近年来，机动车数量呈爆发式增长，由此引起的车辆管理问题、交通安全问题日趋严重。车联网[1-2]的出现为解决上述问题提供了新思路。它通过合理分配交通资源，实时管理入网车辆，极大地提高了交通运行效率。车载数据聚合终端[3-4]作为车联网系统采集层的核心单元，是车载异构网络[5-6]中数据交互的信息枢纽，为车联网系统提供了稳定、可靠的数据支持。但是异构网络中交互的数据复杂多样，对应的总线接口和通信协议各不相同，甚至与服务端对接的传输协议也会随场景变化而改变。传统的数据终端通信接口单一，难以满足复杂异构网络中数据交互的需求。因此，如何设计出一套能同时接入多种通信网络的数据聚合终端，已成为现阶段的研究热点。

王利辉等[7]在深入研究车载网络的基础上，基于Matlab软件搭建了CAN-FD总线网络的优化仿真平台，实现了对总线系统通信行为的动态显示。于海飞等[8]搭建了由感知层节点设备、物联网网关到服务器的完整通信链路，设计并实现了一种基于MQTT通信协议的物联网边缘计算网关，有效缓解了网络拥塞和服务器压力。杨楠等[9]设计了基于OBD和GPS的车载终端系统，实现了对行驶车辆运行参数的实时采集与显示，使车主能全面直观地了解车况，减少了潜在的安全隐患。聂雷等[10-11]在深入研究异构车载网络的基础上，基于多智能体Q学习提出了一种异构车载网络的选择方法MQSM，实现了最优的网络切换决策机制。

本文基于某型号车辆在车联网系统中的实际应用，终端对车载异构网络中的数据进行安全聚合，并上送至基于不同传输协议搭建的服务端，实现对运行车辆状态的实时监控。传统数据终端的网络通信接口单一，无法满足车载异构网络中数据接入的需求。本文设计了以CortexTM-A7为核心处理器的数据聚合终端。该终端提供了UART，CAN，Ethernet，4G，WiFi等多种通信接口，为车载异构网络中数据接入提供了硬件基础。此外，开发了数据聚合终端软件框架，并在此基础上设计了基于TCP/IP，UDP，HTTP，MQTT等不同传输协议的通信服务，提高了通用性，有效解决了异构网络中数据接入的问题。

1 总体结构

车联网系统的数据链路示意如图1所示。本数据聚合终端作为车辆与云服务端之间的数据交互媒介，不仅负责解析分布于车载异构网络中的运行数据，还需要按照GB/T32960协议[12-13]规定的机制将数据上传至云服务端，从而实现车辆定位、追踪、监控的目的。

图1 车联网数据链路示意

为了提高终端的网络兼容能力，使其能成功适配车载异构网络，首先设计了支持UART，CAN，Ethernet，4G，WiFi等通信接口的终端板卡，为数据接入提供硬件基础。然后，针对各通道开发了对应的接口驱动、通信协议以及数据交互服务，使得终端能自由访问分布在不同总线上车载仪表的检测数据，主要包括：位置信息、状态信息、里程信息、燃料信息、告警信息和车室环境信息等。

获取数据后，为了减轻服务端的运算压力，边缘计算服务充分运用终端自身的运算能力，对当前采样信息和历史存储数据进行了分析处理，实现了车辆能耗统计、行车历史追踪、车辆状态监控和车辆故障预警等功能。然后，网络通信服务将数据处理结果进行数据聚合后，按指定通信协议经4G网络上送至车联网服务端。但是在车辆移动过程中，4G信号强度难以始终保持稳定，终端掉线问题难以避免。为了有效解决终端掉线期间的数据丢失问题，在终端应用中嵌入了SQLite[14]数据库并开发了数据库服务，该服务能实时记录采样数据，以便链路恢复后，实现数据补发。

上述服务构成了完整的终端应用，为了使其能在基于单核处理器的硬件载体上稳定运行，本文设计了一套能应对系统多并发的软件框架。该框架能高效调度系统服务，严格保证服务间消息传递的次序性。采用了基于权重的线程轮调机制，既保证了系统消息的处理效率，还有效防止了低优先级服务饿死的问题。

2 硬件设计

本文硬件载体采用核心板配备功能底板的组合方式，不仅可以节省成本、方便维修，还有利于后期功能升级和更换。核心板上搭载了系统运行所需的处理器、SDRAM、FLASH以及电源管理芯片等模块。其中，处理器选用基于ARM CortexTM-A7内核架构的NXP i.MX6UL，资源丰富、性能优越，可提供快速的数据处理和流畅的界面显示[15-16]。满足了系统在应对并发能力、数据处理效率、网络通信速率等多方面的需求。

功能底板上集成了系统运行所需的外围电路，主要包括基于mini-PCIE(EC20)接口的4G模块、基于SDIO接口的WiFi模组、用于GPS模块接入的串口电路、实现车载仪表数据采集的CAN电路、存储原始数据所需的SD卡等模块。车载终端硬件结构框图如图2所示。

图2 车载终端结构

车载终端能否在严苛的工作环境下长时间稳定运行，很大程度上取决于电源管理单元的可靠性。本车载终端的输入电压为12 V，而板卡上各电子器件的工作电压存在较大差异。为了提高电源转换效率，降低电源热损耗,系统选用DC-DC转换器[17-18]方案实现分级降压。先由12 V降压至5 V，为CAN模块、RS485模块和核心板模块供电；再将5 V降压至3.3 V，为RTC时钟模块、USB模块和4G模块供电。系统供电框图如图3所示。

图3 系统供电框图

3 软件设计

3.1 软件框架设计

基于实际应用需求，本车载终端不仅需要完整接收ms级的车辆数据，还需基于报文协议解析数据内容；不仅需要将车辆信息实时上传至服务端，还需要对原始数据进行30 d周期的本地循环存储；同时终端需要支持多种数据接入方式，以及通过掉线检测、断线重连、丢包续传和组包发送等机制保证数据交互的稳定性。因此，基于单核处理器的硬件载体，设计出一套能够应对系统高并发的软件框架是本文软件设计的核心内容。设计的车载终端软件框架如图4所示。

图4 车载终端软件框架

由图4可知，软件框架由服务、消息队列、线程3部分组成。服务负责指定业务的逻辑处理，默认不执行，只有当其他业务向它推送消息时才运行处理。系统为每个服务分配了唯一私有的消息队列，服务间的数据交互(请求、响应和转发等)均通过消息队列完成。

系统中消息队列分为2级：全局消息队列和次级消息队列。次级消息队列负责服务消息的管理，通过绑定服务句柄实现与指定服务建立关联。全局消息队列中的每个成员记录了次级消息队列的地址，从而实现对次级消息队列的管理。

本软件框架共包含3类线程：负责定时管理的Time线程、负责网络数据收发的Socket线程以及负责调度消息队列的Worker线程。系统线程的软件流程如图5所示。

(a)Timer线程流程

在消息调度过程中，单个Worker线程单次只能从全局消息队列中pop出一个次级消息队列，并从中pop出一条消息交由对应服务处理。运行在Worker线程内的单元在执行业务逻辑的同时，还会向指定服务推送消息。因此它既是消息消费者也是消息生产者。而运行在Time线程和Socket线程中的单元不处理任何业务逻辑。它们作为消息生产者，仅为系统任务提供定时触发消息和数据接收消息，从而保证系统定时的准确性和数据响应的实时性。

3.2 数据采样服务设计

实时监测运行车辆的状态、位置、报警等数据是车载终端数据采样单元的主要工作。本单元基于车载终端软件框架，创建了CAN服务和UART服务，分别实现对各自通道数据的解析和本地存储。CAN通信和UART通信的Socket套接字均通过Epoll实现管理。它运行在Socket线程中，一方面监听各套接字上的读写事件，使系统数据交互过程变得更加稳定高效；另一方面实时感知各套接字的通断状态，提高了系统对相关事件的响应速度。数据采样流程如图6所示。

(a)初始化

3.3 网络通信服务设计

为了丰富终端的网络连接能力，本车载终端支持基于TCP/IP,UDP,HTTP,MQTT多种协议的互联网通信，能同时接入基于不同网络协议搭建的车联网服务端。二者之间的数据交互机制和通信报文帧格式均基于GB/T32960《电动汽车远程服务与管理系统技术规范》[12-13]进行设计，此处不再赘述。入网终端通过车架号码(Vehicle Identification Number，VIN)进行标识，以此实现与服务端之间的点对点通信。网络通信服务的软件流程如图7所示。

(a)初始化

4 测试验证

4.1 软件框架压力测试

在本设计中，软件框架是车载终端的核心，所有服务都通过软件框架调度实现运行，框架的性能直接影响着车载终端的执行效率。在测试终端功能之前，先通过压力测试，综合评估框架的各项性能，定位框架中潜在的运行瓶颈，为后续的功能开发和性能优化提供借鉴。本测试针对框架系统在应对密集数据上报的压力下进行，测试指标主要包括系统吞吐量、可靠性和响应能力3个方面。测试场景设计如图8所示。

图8 测试场景

终端通过4G模块与本地PC服务端建立连接，并通过串口和CAN口连接测试仪。其中2路CAN口的波特率均设置为500 kb/s，串口波特率设置为115 200 b/s。测试仪按照指定速率向终端发送数据报文，验证终端的数据处理能力。服务端向终端下发数据请求，检验终端的数据响应能力。表1记录了终端在数据存储功能启动和关闭2种场景下，基于不同负载压力，单位时间内完成的报文解析数量和系统响应时间。

表1 压力测试数据表

由表1可知,在数据存储功能关闭的情况下，虽然随着发包速率的不断加快，系统响应时间逐渐变慢，CPU利用率也有所升高，但系统基本能处理接收到的所有数据，相关性能参数也均在指标要求范围内。而开启数据存储功能后，频繁的文件操作对系统开销影响较大。速率超过512 kb/s后，系统各项性能参数就难以满足指标要求。在本应用中，车载终端收包速率低于256 kb/s，因此本软件框架能满足实际应用的要求。

4.2 车载终端综合测试

为验证各项需求和功能是否完整实现，合理评估终端的质量、性能和运行效率，本设计基于实际应用场景，参照技术指标要求，对车载数据聚合终端进行了综合测试。图9为终端安装在现场后基于实际应用的测试场景。

图9 应用场景

第1路CAN口的波特率设置为250 kb/s，第2路CAN口的波特率设置为500 kb/s，串口波特率设置为9 600 b/s。终端接入车载网络后，通过CAN网络、UART网络读取车载仪表的检测数据，通过4G通信或接入WiFi热点实现与云服务端的数据交互。通过云服务端平台实时查看运行车辆的工作状态。系统功能测试数据如表2所示。

表2 功能测试数据表

由表2可知，本车载终端完整实现了数据聚合、数据存储、数据交互和数据计算4个方面的相关功能。但车辆在移动过程中，很难长时间保持信号强度稳定,掉线、重连的情况时有发生，导致丢包率过高而达不到指标要求[19-20]。

为解决丢包率高的问题，本文通过心跳机制实时检测终端的链路状态。一旦发生链路中断，上送服务端的报文便按照时间戳顺序存储进本地数据库中。待链路恢复后，进行补发。通过机制优化，系统的丢包率显著降低。系统性能测试数据如表3所示，各项参数均满足指标要求。

表3 性能测试数据

5 结束语

本文基于CortexTM-A7处理器设计了车载数据聚合终端，具体内容包括终端硬件板卡设计、终端软件框架设计以及终端应用服务设计3个方面。该终端具备丰富的通信接口，通用性强，能完全满足车载异构网络中数据交互的需求，解决了传统终端接入能力差的问题。所设计的软件调度框架通过了系统压力测试，各项性能参数均满足指标要求。基于该软件框架开发的应用服务实现了数据聚合、数据交互和数据存储等功能。目前该终端已投入实际使用，运行稳定。