夏宝华

（1.北京福田汽车股份有限公司工程研究总院 北京市 102206 2.智博汽车科技(上海)有限公司 上海市 201101）

当前互联网络汽车正处于蓬勃发展期，车联网业务在汽车电子领域的应用越来越广泛，当用户在驾驶车辆的时候随时随地都能感受到汽车接入车联网后带来的各种便捷操作和驾驶车辆的舒适体验。虽然整车制造厂商生产的民用轿车对于接入互联网来说，国家虽然没有明确的标准和规范要汽车整车制造产商强制接入车联网系统，但是对于上市车辆接入车联网系统这已经是汽车整车制造厂商生产民用轿车的一个标准配置了。

中国汽车工程学会在2017年发布了学会标准《合作式智能运输系统车用通信系统应用层及应用数据交互标准》（TCSAE 53-2017）。在这份标准里，详细的定义了车载单元OBU 技术要求，定义了车载单元与他单元之间的通信V2X 协议接口标准规范，以及构筑车用通信系统的17 种主要应用场景定义与实现标准。

中国信通院在2019年发布了《车联网白皮书（C-V2X 分册）》，在这份白皮书里进一步阐述了C-V2X 演进与发展规划以及描述了5G 标准宽带使用场景。

2020年国家和发展改革委员会联合11 个部位制定了《智能汽车创新发展战略》，在这份战略规划书里重新定义了新一代智能汽车，以及展望了汽车智能产业。

因此迫切需要设计与实现新一代智能T-Box 来承载V2X 的功能，实现5G 标准宽带使用场景，迎接新一代智能汽车的诞生。

1 目前现状与本案目的

1.1 现状分析与传统T-Box说明

在现代车联网系统中，做为实现Telematics 功能的部件，T-Box处于一个非常关键的位置：

（1）T-Box 连接着远程信息服务供应商（Telematics Service Provider，TSP）、娱乐信息单元（Infotainment Head Unit，IHU）、车辆车身控制模块（Body Control Module, BCM）及电子控制单元（Electronic Control Unit, ECU），这样车辆通过T-Box 就接入了车联网系统中。

（2）对于IHU 来说，T-Box 本身管理的第二代移动通信（the 2nd Generation mobile communication technology，2G）/ 第三代移动通信（the 3rd Generation mobile communication technology，3G）/4G 模块可以共享上网给IHU，因此IHU 可以透过T-Box 提供的共享上网功能接入互联网，那么用户就可以使用语音识别、在线音乐、网络电台等各种互联网内容供应商（Content Provider, CP）服务。

图1：传统T-Box 系统框图

图2：4G T-Box 系统框图

（3）对于手机应用程序（Mobile Application, Mobile APP），TSP 将T-Box 与Mobile APP 紧密地连接在一起：用户可以使用Mobile APP 来查询车辆状况以及其他车辆信息，也可以使用Mobile APP 提供的远程操作按钮来发起车辆的远程控制，如用户可以用远程开启车辆空调／可以远程对车辆开锁闭锁操作等。

且T-Box 本身部署有全球定位系统（Global Positioning System, GPS），通过本身的移动模块可以方便的接入TSP 以及实现精准定位车辆所在位置。因此可以说T-Box 是构筑现代车辆网系统的重要组件：从TSP 的角度看，T-Box 就代表了接入车联网的车辆。

按照T-Box 装配的移动模块制式，可以将T-Box 划分为2G/3G/4G T-Box。

图3：硬件框架设计图

2G/3G 时代的T-Box，设计时大多是采用MCU+调制解调器（modem）解决方案[1]，我们称之为传统T-Box，其系统架构如图1。

图1 显示了传统T-Box 原型的系统框图：MCU 是T-Box 主要处理器，负责执行Telematics 功能；modem 负责无线网络数据收发；MCU 与modem 之间基于通用异步收发传输器（Universal Asynchronous Receiver Transmitter，UART）进行数据交换[3]。

进入4G 时代的T-Box，为适应Telematics 业务的飞速发展，其系统框架有了很大的改进，演进为采用MPU+MCU 解决方案[2]。典型的系统架构如图2。

4G T-Box 与传统T-Box 比较，有下面的先进性：

（1）释放MCU，MCU 更专注于控制器局域网络（Controller Area Network，CAN）数据收发与处理；

（2）MPU 处理运算能力远高于MCU，功能规划上专门用来处理复杂Telematics 业务。

1.2 智能汽车对T-Box的基本要求

解读智能汽车定义对于车载终端T-Box 的技术基本要求：

（1）5G+车联网系统建设，统一的通信接口协议定义与实现；

（2）车用专属V2X 频谱使用，V2X 应用场景实现（包括车与车之间（Vehicle to Vehicle，V2V）、车与路之间（Vehicle to Infrastructure，V2I）、车与人之间（Vehicle to Pedestrian, V2P），实现车、基础设施、交通环境等数据融合应用；

（3）数据加密解解密与网络安全访问：安全管理联动机制，提升网络完全防护能力，加强数据安全监督管理；

1.3 传统T-Box的缺陷

基于智能汽车的定义，传统T-Box 和4G T-Box 囿于技术实现手段的困难和设计方法的落后，无论从硬件体系缺陷还是软件架构局限，特别是：

（1）5G 宽带网络的升级；

（2）V2X 应用场景的实现；

（3）网络安全与数据加密实现。

这些基本功能在单片机方式的程序代码中来构造实现，成功可能性几乎为零。在4G 时代的T-Box 靠软件升级也是无法实现V2X功能与5G 标准宽带应用的基本要求，所以目前传统T-Box 以及4G T-Box 是无法适应新一代智能汽车定义车载设备之要求。

1.4 本案的目的

本案在阐述了传统T-Box 以及4G T-Box 技术局限和设计落后的现状，提出：我们迫切需要设计一种全新的T-Box，继承4G T-Box的成熟稳定的硬件体系即采用MPU+MCU 解决方案（如图2 所示），硬件部件增加5G+V2X，使之既能继承传统T-Box 的全部功能，又能全部适应智能汽车的定义。

重新设计C-V2X 5G T-Box 技术方案，我们将使用高成熟度的模块化设计思想与实现方法，从硬件体系结构、软件构造框架两个基本层面深入与渗透模块化设计并切实实现。对于传统T-Box 的功能可以分化做为一个子模块集成到模块化的C-V2X 5G T-Box 中，这样对于传统T-Box 并非摒弃而是继承，继而拓展新的模块化功能，这样就可以“既能继承传统T-Box/4G T-Box 的全部功能，又能全部覆盖智能汽车之定义”。这也就是本案的最终目的。

2 C-V2X 5G T-Box之软硬方案

2.1 国内V2X标准首选

V2X 技术标准有两种，即专用短距离通信技术（Dedicated Short Range Communication，DSRC）和C-V2X。

V2X 早期主要是基于DSRC，目前使用场景如：电子收费系统（Electronic Toll Collection，ETC）专用通道，它就是实现车辆身份识别，电子扣费，实现不停车、免取卡，建立无人值守车辆通道的关键。另外，在小区停车场遇见的电子拦路口也有与之相同的技术应用。DSRC 的特点是：它的特点是对短程（数十米的距离）中，高速行驶的车辆进行识别和连接，从以上应用中也可看出来，它的技术是比较成熟的、稳定的，也是当前被广泛认可的。

C-V2X 是基于移动蜂窝网络的V2X 通信技术，就像是手机连入3G/4G 一样。长期演进（Long Term Evolution，LTE） V2X 针对车辆应用定义了两种通信方式：集中式（LTE-V-Cell）和分布式（LTE-V-Direct）。集中式也称为蜂窝式，需要基站作为控制中心。分布式也称为直通式，无需基站作为支撑。

5G 的到来不仅对于手机是一场革命性风暴，对于LTE V2X 也是最关键的一步。5G 时代除了下载速度快以外还有最重要的一点，延时性短，5G 强大的通信能力可以让汽车更安全、更高效的运行。

C-V2X 技术标准的优点：

（1）基于蜂窝网络，与目前的4G 成熟网络和试运行中的5G网络可以复用，部署成本低。

（2）网络覆盖广，网络运营盈利模式清晰。

（3）三代合作伙伴计划（3rd generation partnership project，3GPP）标准制定，全球通用，使用单一LTE 芯片组，模块成本大幅降低。

（4）C-V2X 将作为5G 的重要组成部分持续演进。

从C-V2X 演进的技术优势来看，我国拥有全球最大的LTE 网络现状，C-V2X 应该是国内V2X 技术标准的首选。

基于此硬件体系是要基于C-V2X 标准，且一定要使用5G 基带。

2.2 硬件设计方案

本案硬件设计框图如图3。

本案硬件之优势：

图4：软件框架设计图

（1）硬件设计采用模块化设计思想，内部自定义总线接口，现在使用C-V2X 模组与5G 模组一体集成模块，减少分体C-V2X模组与5G 模组设计耦合风险，也节省布版空间。一体集成模块节硬件设计成本比较低，极大地减小了硬件设计的风险。

（2）硬件设计中考虑到了无线局域网（Wi-Fi）和低功耗蓝牙（Bluetooth Low Energy，BLE），未来若车辆规划蓝牙智能钥匙，有硬件体系的支撑，软件系统很方便地就能实现智能蓝牙钥匙等业务需求。

（3）本案设计了车载以太网，支持以太网物理层收发器（PHY）和交换机（switch），以适应未来车载以太网技术。

（4）主模块使用5G 全网通modem，支持2G/3G/4G/5G 网络制式。全网通完全兼容中国三大运营商，运营管理将不受运营商身份识别卡（Subscriber Identity Module，SIM）卡和网络制式限制，方便了集团公司对于Telematics 业务运营管理。

2.3 软件设计方案

本案软件设计框图如图4。

本案软件之优势：

（1）本案软件设计时定义了三个设计原则：即软件适应之兼容性原则、软件配置之灵活性原则以及软件运行之稳定性原则。兼容性原则可以保证软件编码实现时可以不断地迭代升级，既能兼容以前的代码也可以不断地扩张新的功能。灵活性原则可以保证软件有很好的柔软度和最好的开放性，可以保证各个模块可以很好的耦合，同时开放性也方便未来其他软件模块的植入，也可以开放接口给其他部门或第三方软件植入。稳定性考验设计方案的成熟度与健壮性，可以有效地保证软件模块长时间运行，也是保证软件产品耐用性的有效手段。

（2）自定义与实现的日志（log）记录管理系统，实时记录软件模块每时每刻执行轨迹，方便测试人员完成软件模块的单元测试、台驾测试与实车测试记录软件全面执行的情况，为出现的运行问题提供最好的分析数据。产品装车后，也是运营维护人员分析问题设备的最真实可靠的基础。

（3）完善的软件升级实现策略，全面支持空中升级（Over The Air，OTA），设计有整车OTA 的框架，除了T-Box 本身OTA的实现，同时也支持智能汽车其他ECU 的OTA 实现。OTA 对于车辆的远程技术支持是最便捷的设计。

（4）软件有非常强大的自适应框架，对于CAN 矩阵（Matrix）以及各种车型的匹配，软件可以通过一定的策略自动匹配CAN Matrix 以适配所有车型。这样设计方案产品化，不局限与某台车辆或某种型号绑死关系充分体现了软件设计的自适应性。

3 MCU与MPU数据通信实现

3.1 数据传输一致性需求

从本案的硬件框图图3 中，MCU 与MPU 之间使用是串行外设接口（Serial Peripheral Interface，SPI）进行数据通信。数据通信的主要内容就是CAN 报文。正确处理CAN 报文，是MPU 与MCU实现互联互通的首要问题。从计算机系统数据存储格式角度看，同样的数据在MCU 与MPU 的存储格式不一样。如下：

（1）MCU：CAN 数据采集部件，本地数据格式是大端格式（Big endian）；

（2）MPU：CAN 数据解析、打包并发送包数据到平台的部件，本地数据格式是小端格式（Little endian）；

从以上说明中，我们可以看到MCU 把数据通过SPI 发送到MPU 时，原始的CAN 报文是大端格式，MPU 对于CAN 数据进行解析时，需要将大端格式的数据转换为MPU 本地存储的小端数据格式才可以进行处理。而当MPU 需要发送CAN 报文到MCU 时，也需要将本地小端格式的数据转换为大端格式数据，然后通过SPI发送到MCU，MCU 才能正确解析来自MPU 的CAN 报文。

因此在MPU 端需要对数据完成一致性处理：对收到来自MCU的大端格式的CAN 报文转换为小端格式，对发送到MCU 的报文需要先转换为大端格式数据再发送到MCU。

3.2 大小端数据转换计算公式

通常定义大端与小端转换公式如下（以uint8_t 一个字节长度数据为例说明）：

式中，VB是8 比特大端格式输入值，VL是8 比特小端格式输出值。

其中：＞＞表示计算机位右移操作， ＜＜表示计算机左移操作。

“式（1）”里完成一次转换：做了8 次右移操作，做了8 次与操作，做了8 次左移操作，做了7 次加法运算。虽然右移操作、与操作以及左移操作CPU 执行起来非常高效，但是看起来是蛮花时间的。

3.3 优化大小端数据转换计算公式

现在对“式（1）”做一个优化：因为一个字节占用8 比特位，一个字节也就有256 种有限的具体数据表示值。我们制定一个大小端对应常量数据表，转换时直接拿字节内容做索引下标，查表换算对应的大小端实际值，这样就可以一次查表操作完成转换。具体实现如下：

优化后的计算公式如下：

式中，VB是8 比特大端格式输入值，VL是8 比特小端格式输出值。

因为只有一次查表操作，看起来这样优化后的“式（2）”明显比“式（1）”有很大优化与提升。

3.4 定义完成全部数据转换计算公式

现在定义两字节整形大小端对应的转换公式如下：

式中，VB是16 比特大端格式输入值，VL是16 比特小端格式输出值。

进而定义四字节整形大小端对应的转换公式如下：

式中，VB是32 比特大端格式输入值，VL是32 比特小端格式输出值。

以上定义完成了大小端数据转换所需要的全部计算公式“式（2）”（fuint8_t）、“式（3）”（fuint16_t）、“式（4）”（fuint32_t）。这些基础计算公式对于输入值本身并不区分大小端格式，则是按照推导设计的公式完成相应的高低位位数据转换、完成高低字节字节数据转换：若输入是大端数据，则输出是小端数据；反之亦然（若输入是小端数据，则输出是大端数据）。

3.5 实验验证

接下来，我们在某ARM 芯片上对fuint8_t 优化前“式（1）”后“式（2）”所消耗的中央处理器单元（Central Process Unit，CPU）的时钟（clock）做了实际验对比，10 次随机调用统计分析如表1 所示。

从表1，可以明显地看出优化后“式（2）”节省CPU 消耗clock 一半。通常在有限的嵌入式系统设计开发中，这样优化效果是非常可观的，可以节省宝贵的CPU 资源，让其他重要的应用程序（Application，APP）得到均衡的调度。

3.6 注解

（1）大端格式（Big endian），一种计算机系统数据存储与表示格式：是指数据的高字节保存在内存的低地址中，而数据的低字节保存在内存的高地址中。

表1：消耗CPU clock 统计表

表2：FCW 运算主要数据项表

表3：消耗CPU clock 统计表

表4：V2X 场景覆盖范围表

（2）小端格式（Little endian），一种计算机系统数据存储与表示格式：是指数据的高字节保存在内存的高地址中，而数据的低字节保存在内存的低地址中。

（3）对于3.1“从以上说明中……这里需要将大端格式的数据转换为MPU 本地存储的小端数据格式才进行处理。”，此处MPU从MCU 拿到CAN 报文是大端格式，因为MPU 本地是小端格式，因此从CAN 报文解析数据时是要经过由大端格式转换为小端格式才能进行解析并处理，否则数据就要出错了。举个例子比如车辆水温，换算成摄氏度的计算公式为：

式中，Tc是温度自然表达式，Tv是从车辆发送过来的CAN 数据。

假设Tv采集到的值是140，计算机内大端格式数据表示为16 进制是0x31，换成10 进制就是49。在MPU 端开始解析车辆水温，如果不转换为小端格式，那么计算出来的车辆水温为Tc=Tv-40=49-40=9℃。很明显地，MPU 这样解析出来的9℃是个错误值。

正确的计算方式为：先将大端格式数据表示为16 进制是0x31转换为小端数据格式表示，16 进制是0x8C，换成10 进制就是140，这样计算出来的车辆水温为Tc=Tv-40=140-40=100℃。100℃才是正确的车辆水温。

4 V2X场景实现

4.1 高精度GPS模组

V2X 场景的实现，是需要高精度GPS 模组支持：定位精度要求是纳米级，且上报GPS 的频率是10 赫兹（Hertz，Hz）。

根据本案硬件设计，如图3 硬件框图所示：MPU 外接高精度GPS 模组，GPS 模组通过UART 把美国国家海洋电子协会 （National Marine Electronics Association，NMEA）数据发送到MPU，另外有秒脉冲（Pulse Per Second，PPS）接入MPU 中断处理信号。

图5：V2X 数据发送流程

图6：V2X 数据接收流程

图7：FCW 处理流程

GPS 模组定位后：

（1）以每秒10Hz 频率发送NMEA 数据到MPU，满足V2X场景每秒接收10 次NMEA 数据；

（2）GPS 触发PPS 信号对MPU 进行精确授时处理，精度可达纳秒级。

4.2 V2X数据收发

MPU 模组内嵌直接通信（PC5）协议栈，软件开发工具（Software Develop Kit，SDK）提供有PC5 协议栈收发API，因此V2X 应用程序可以很方便地实现V2X 数据的收发处理。

在《合作式智能运输系统车用通信系统应用层及应用数据交互标准》里定义了V2X 数据的收发时采用抽象语法标记（Abstract Syntax Notation One，ASN.1）进行编解码器对原始数据进行处理，V2X 应用程序要将ASN.1 编解码器集成到程序里来使用。

图5 显示了本案发送V2X 数据的处理流程。

说明：

（1）图5 V2X 数据发送流程是实现一次完整的V2X 消息集合（MessageSet）数据包发送过程，实际运行中由GPS 接收NMEA回调函数触发该流程。因为GPS 上报NMEA 数据频率是10Hz，所以当GPS 模组定位后每秒会触发10 次该流程。即本案T-Box 每秒会使用该发送流程向周围其他V2X 设备发送10 帧本设备V2X MessageSet 数据。

（2）V2X 应用程序在启用数据发送流程前，首先要注册高精度GPS 接收NMEA 数据回调函数，这样当高精度GPS 定位后就会向V2X 应用程序发送收到GPS 有效数据信号，即本流程过程调用步骤2。

（3）过程调用步骤3，这里是采集CAN 数据。在从MCU采集CAN 信号时，需使用本案式（2）、式（3）和式（4）完成MCU 的大端CAN 数据格式向MPU 的小端CAN 数据格式转换。

（4）图5 V2X 数据发送流程步骤7，这里是将本设备V2X MessageSet 数据发送给V2X 应用程序引擎（如图4，V2X engine）。V2X 应用程序引擎会将本设备数据与收到的其他设备的数据进行运算处理，来实现各种V2X 场景应用。

图6 显示了本案接收V2X 数据的处理流程。

说明：

（1）图6 V2X 数据接收流程是实现一次完整的V2X MessageSet 数据包接收过程，实际运行中由PC5 注册回调函数触发。

（2）V2X 应用程序在启用数据接收流程前，首先要注册PC5注册回调函数，这样当V2X 模组收到其他设备的MessageSet 数据立即触发V2X 应用程序调用数据接收流程完成数据接收处理，即本流程过程调用2。

（3）图6 V2X 数据接收流程步骤4，这里是将其他设备V2X MessageSet 数据发送给V2X 应用程序引擎。这样V2X 应用程序引擎会将本设备数据与收到的其他设备的数据进行运算处理，来实现各种V2X 场景应用。

4.3 V2X应用程序引擎

V2X 应用程序引擎体现在本案软件设计方案如图4 所示。其主要功能是：

（1）实时采集本设备的MessageSet 数据，实时采集其他设备MessageSet 数据；

（2）快速运算MessageSet 数据，计算结果若有V2X 场景如前向碰撞预警、交叉路口碰撞预警等场景）定义的结果出现，则向V2X 应用程序发送相关的预警信号，再由V2X 应用程序将预警结果通知到相关的设备人机交互界面（Human Machine Interface，HMI）（如车机、仪表等）对车辆驾驶员进行碰撞预警；

那V2X 应用程序引擎的运算能力的主要性能指标，在标准里定义其延时要＜100 毫秒（millisecond，ms）。

接下来的章节以前向碰撞预警（Forward Collision Warning，FCW）为例。

4.3.1 FCW 计算公式

FCW 的定义为：主车（Host Vehicle，HV）在车道上行驶，与正前方车道的远车（Remote Vehicle，RV）存在追尾碰撞危险时，FCW 应用将对HV 驾驶员进行预警。

接下来本案以FCW 场景为例，主要论述一下提高V2X 应用程序引擎的运算能力的设计要点。

首先定义计算公式如下。

式中，Mh是HV 本次HV 的MessageSet, Mr是RV 的MessageSet。输出值Mfcw是有前车碰撞预警的MessageSet。

参与FCW 运算的MessageSet 主要数据如表2 所示。

使用表2 里的数据项来描述Mh、Mr其公式如下：

接下来要定义一个满足FCW 的数据集合，如下。

对于“式（5）”使用“式（6）”、“式（7）”和“式（8）”进行推导如下：

首先计算出ΔM。

接着计算Mfcw。

V2X 应用程序引擎采集到有效HV 和RV 数据后，调用“式（5）”就可以完成本次前向预警计算：

（1）若Mfcw=[0, 0, 0, 0]则表示HV 与RV 处于安全状态；

（2）=Mr则表示HV 将要追尾RV，此时V2X 应用程序引擎应发出预警信号到应用程序进一步处理。

4.3.2 FCW 处理流程

V2X 程序引擎使用“式（5）”进行数据处理流程如图7。

4.3.3 FCW 计算公式效率

对于“式（5）”、“式（6）”、“式（7）”和“式（8）”我们做了模拟代码，并在C-V2X 5G T-Box 原型机上进行了实际运行验证，其统计结果如表3 所示CPU 消耗clock。

从表3 可以看出执行1 次“式（5）”消耗时间不超过1ms，那么在标准定义的最大延时＜100ms 内，V2X 应用程序engine 可以完整的处理100 笔以上FCW 数据计算运算。目前这样的结果满足标准定义以及与实车运行的需要。

4.3.4 FCW 计算公式注解

对于“式（8）”中取值范围说明：

（1）δt,因为标准定义FCW 最大延时＜100ms，所以对于参与运算的两笔数据时刻差＜100ms 内算有效值，否则对于V2X 应用程序引擎来说认为数据无效；

（2）δlng,通常取-50 米到50 米的经度度值，这里计算方法以上海地区为例：上海位于北纬30 度处，纬线周长为34668千米，即1 米对应的经度度值等于360 度/34668 千米，即1 米≈0.00001038 度。

（3）δlat,通常取-50 米到50 米的纬度度值，这里计算方法：经线周长为40076 千米，即1 米对应的维度度值等于360 度/40076千米，即1 米≈0.00000898 度。

（4）δv,HV 与RV 车速比较计算δv：

=0 表示vh=vr

＜0 表示vh＜vr

＞0 表示vh＞vr。

4.4 V2X场景覆盖范围

本案覆盖了标准定义的17 种应用场景，如表4 所示。

对于表4，其中：

（1）1-12 项为安全应用场景。

（2）13-16 项为效率应用场景。

（3）17 项为信息服务应用场景。

5 实车测试问题解决与优化

依据本技术方案我们完成了C-V2X T-Box 原型机的开发：

（1）硬件印刷电路板（Printed Circuit Board，PCB）电子设计与制板；

（2）软件进行了重构，继承了4G T-Box 的全部功能，新加入了V2X 应用程序与engine。

实车实验部署了原型机进行了V2X 应用场景验证，出现如下问题：

（1）起初实车测试验证中发现HV 与RV 距离超过50 米时，数据丢包率非常高。通过对于基于车辆移动性V2X 链路连通性能分析[4]：空旷的测试路面，没有遮挡物，直线视野非常好，车流速率，车辆速度，车辆密度等影响链路连通性能的条件都非常好，那么理论上V2X 链路连通性能应该是最佳状态。实际的丢包率高反应了超过50 米时V2X 链路连通性能就非常差，分析问题应该是V2X模组无线信道衰落引起的。继续跟进V2X 模组收发天线发射功率，发现硬件板卡天线附近有磁珠影响天线发射功率。移除磁珠后，继续进行实验测试，HV 与RV 直线距离可达200 米。问题得以解决。

（2）V2X 模组工作半小时后，容易出现大量的丢包情况。问题（1）已经排除出了天线收发功率衰减引起的问题，那么现在出现的问题应该是V2X 模组长时间运行后，HV 与RV 之间通信信道稳定性与路径路由长时间运行失效，以至于不能持续长时间支持V2X 海量数据收发引起的。基于此，我们请模组供应商对V2X 路由协议进行了优化处理，用链路连接失效时间（LET）和有效带宽建立双重约束，通过选用LET 构建最优通信路由路径[5]。后续测试验证中，超过两小时的行车测试未出现大量丢包现象，实际证明问题得以优化解决。

6 结论

本技术方案，完全覆盖了《合作式智能运输系统车用通信系统应用层及应用数据交互标准》所定义的V2X 应用场景，也充分诠释了来自于《智能汽车创新发展战略》定义的智能汽车概念。

对于传统T-Box 方案以及4G -Tbox 方案，本案并非完全摒弃已经成熟的设计思想，而是很好地体现了设计思想的继承与发展，创造性地延长了现代T-Box 产品的演进之路。本案的原型机：硬件上集成了V2X 模组与车载以太网模组以及BT BLE 模组，无线移动基带无缝地升级到了5G，这样不但兼容了2G/3G/4G 移动互联网，也一步跨入了5G 移动互联网；软件上，全部地继承了上代产品的所有Telematics 功能，在此基础上又成功地部署了V2X 应用程序与engine。因为硬件体系支撑了车载以太网以及BT BLE，未来本案软件功能在智能汽车平台上将有很大舞台：如实现整车OTA，实现智能蓝牙钥匙，实现基于车载以太网的诊断协议（Diagnostic Communication over IP, DoIP）功能，实现基于BT 网（Mesh）和BT 信标（Beacon）的车辆近场操控功能等。

从智能汽车概念的角度看，本T-Box 技术方案是对现有车联网设备设计方案颠覆性地换代更迭，也是一次非常成功的技术方案创新。