科普向，一文详解V2X HIL测试

在智能网联的话题里，总是离不开V2X这个字眼，而在V2X的测试需求中又总是离不开HIL，不知你是否也经常听到以上这些，今天小K就抽丝剥茧，为你讲解V2X HIL测试的种种。

▼

目录

• 什么是V2X？

• 什么是HIL测试？

• 为什么需要C-V2X HIL测试？

• C-V2X HIL测试系统长什么样子？

• C-V2X HIL测试系统如何工作？

什么是V2X？

学一门学问要从概念开始，V2X的概念相信大家都不陌生，这里简单说一下，V2X是Vehicle to Everything的缩写，直译过来的意思是车联万物，具体指的是V2V，V2I，V2P和V2N，这几项可以在下方找到对应的解释。

V2I：指的是车辆与道路设施之间进行通信，例如，当汽车接近交叉路口时，信号灯可以告诉汽车交通信号会在什么时候切换。

V2N：指的是车辆与蜂窝网络交换数据，可以提供实时交通信息，比如施工区警告，通过 V2N 还可以提供 SOS 服务以及远程诊断和维修。

V2P：指的是车辆与行人和非机动车之间进行通信，以便在驾驶员视线受到妨碍时也能保障这些人的安全。

V2V：指的是车辆与车辆之间的通信，主要是车辆之间的短时延通信，避免车辆碰撞等安全性问题。

那这项技术是做什么用的呢？举个例子，当司机在开车时，需要手、眼、耳并用，随时注意车身附近的情况，那么我们知道为了实现高级辅助驾驶功能，车本身要逐渐代替驾驶员的作用，所以车本身也应该清楚它本身附近的情况，所以传感器技术正像是汽车本身的“眼睛”和“耳朵”，眼观六路，耳听八方，但这些就足够了吗？

传感器本身都是有视野范围的局限性，那些它们看不到的死角，或者是道路上有遮挡物又该怎么办呢？这时就该V2X发挥作用了，通过V2X技术，车辆得以发送和接收到其他车辆、道路等参照物的通信信号，得知那些视野范围外的路况信息，从而通知车辆本身，避免事故的发生。

关于V2X，此前我们还写过一篇更详细的文章，包括它的发展、竞争与优势，详细可参照：关于C-V2X的那些事！

什么是HIL？

说完了V2X，我们再来说说HIL，HIL全程Hardware-in-the-loop，中文翻译过来叫硬件在环。还有几个和它名字很像的“兄弟”，MIL，SIL和PIL，相信搞工程的同学们对此都不陌生，所以这里不详细解释每个词的含义，简单来讲，MIL和SIL只是在软件层面（模型和代码）进行测试，PIL在前两者的基础上引入了更贴近现实的编译环境，而hil测试则是在前面的基础上引入真实的待测物进行测试。

那么为什么需要HIL测试呢？由于汽车本身的零部件繁杂，很多系统硬件和软件也是在并行开发，HIL测试可以有效地对单个系统进行测试，避免集成后出现严重的bug，同时对于一些危险性比较高或者是极端的情况，也可以使用HIL来进行测试。在后续的文章中，我们也会为大家以V2X HIL系统为例，让大家了解HIL测试系统的架构。

为什么需要C-V2X HIL测试？

前面我们说过V2X的本质在于通信，在V2X测试中，测试的对象往往是OBU/RSU（车载单元/路侧单元），负责收发信号，怎样测试它是否符合标准呢？

当然是车上带着它在测试路段走一圈，针对不同场景来看看数据，但这说起来简单，实际上非常费时费力，搭建真实场景不仅费时费力，重复测试和极端情况测试也很难，安全性无法保证，测试周期长，效率也很低。所以在真正的路测之前，先进行HIL测试，安全，准确可重复地对OBU/RSU测试就很有必要。下面我们就来看一下，如何来进行V2X HIL测试吧。

C-V2X HIL测试系统长什么样子？

首先我们来看一下整个测试系统的架构。下图是由是德和怿星共同搭建的C-V2X HIL测试系统的方案架构，我们以此图为例，让大家来看看V2X HIL测试包含哪些部分，该方案的DUT为OBU，所以在下方的文案中，我们也从OBU的角度进行解释。

红色部分：红色部分是场景仿真软件，前面我们讲过，在路测之前，无法把OBU/RSU带到真实的环境中进行测试，所以为了解决这一难题，通常使用场景仿真软件来代替真实场景进行测试，常用的场景仿真平台如图中的PreScan，VTD和CarMaker等等。

典型的场景包括FCW（前向碰撞预警场景），DNPW（逆向超车提醒场景），LTA/ICW（左转和交叉路口盲区提醒场景）等等，还有一些典型场景可以参考中国汽车工程学会发布的T/CSAE 53-2017标准，当然有时也有用户自定义的一些场景，图中所示的这套系统也可以进行支持。

CSAE第一期V2X场景

（图片来源于中国汽车工程学会标准 T/CSAE 53-2017）

从场景中获取的数据有三类：

•

RV/RSU数据：远车，路侧单元数据

•

HV CAN/ETH数据：主车运动消息

•

HV GNSS数据：GNSS定位和授时信号

下面就这三类数据各自的部分进行架构的讲解：

RV/RSU数据传输包括：

RV Simulator/RSU simulator：此部分主要是ITS协议栈，它会负责接收场景中的RV（Remote Vehicle即场景中仿真的远车）以及RSU出数据，然后转换成报文的形式，为传递给物理层做准备，常见的报文包括BSM，SPAT，MAP，RSI等等。

注：关于V2X测试还有另外的一种测试涉及到ITS协议栈，名为一致性测试，是德科技在以往也发布过相关测试方案，本文篇幅有限不再详述，有兴趣的可以参考：是德科技联合中国信通院和东软集团成功完成C-V2X协议一致性测试

Keysight C-V2X软件和Keysight E7515B硬件：即是德科技的C-V2X测试平台，在此系统中用于射频信号测试，支持物理层的测试，E7515B单表是可以支持4G，5G信号的测试，在此系统中主要用于V2X的测试，在接收来自ITS协议栈的报文后，会通过PC5将信号传输到DUT。

HV CAN/ETH数据传输包括：

CAN卡/以太网卡：接收来自仿真场景中的车身运动信息，完成数据处理之后，发送给OBU。

HV GNSS数据传输包括：

GNSS模拟器平台：在此系统中使用的是GSG设备，负责接收来自场景中的仿真的GNSS信号作为自身的动态输入，在HIL系统中需要它来实现动态更新，GNSS模拟器在实际测试过程中与E7515B进行物理连接，完成时间的同步，然后发送射频信号给OBU，再完成与OBU的时间同步。

了解了图上的系统架构以及基本概念之后，让我们来看一下实际的测试系统长什么样子？

简要概括一下这套C-V2X HIL测试系统的特点：

整套系统由是德科技无线综测仪，GNSS模拟器和V2X场景仿真平台以及协议栈组成。

从物理层来讲，是德科技的UXM支持4G，5G和C-V2X的测试，在该系统中充当射频和接入层测试的主要设备，硬件计算资源强大，对于上层复杂场景如拥塞，多目标等都能轻松支持；接口开放，支持市面上成熟的C-V2X协议栈，满足协议一致性测试需求。

从上层来讲，整套系统支持各类成熟的商用仿真平台，同时可以仿真CSAE标准场景和自定义场景；协议栈方面，支持国标各类报文，以及集成了可支持安全策略的扩展接口。