在理论篇，我们介绍了理论上车辆模拟仿真的情况，那么为了实现车载拥塞场景的仿真，我们需要一些相应的测试仪表、仿真平台和测试用例来实现拥塞场景的模拟工作，整个平台的逻辑示意图如图1所示，有如下几个部分组成和相应的功能模块：
V2X仿真平台CMW500
1. 多车环境接入层模拟
2. PC5 ITS消息的收发，并且控制不同车辆的功率以及物理层资源调度
3. 物理层基带信号衰落模拟
实时卫星模拟器SMBV100B
1. PC5时序同步
2. 产生并实现OBU的路点信息
Canoe.Car2x仿真平台
1. 交通场景编辑以及场景运行，测试结果分析统计
2. V2X传输层以及应用层协议实现
3. 通过CAN/Ethernet实现DUT的HIL测试
车载待测件OBU
1. 测试结果状态分析以及统计
2. ECU HIL监控- Optional
图1. 拥塞测试逻辑框架
基于上述的仿真方案，我们以一个150辆车的仿真实例来看一下如何进行大规模车辆仿真实测。首先我们需要配置Canoe.Car2x跟CMW500的接口进行配置。Canoe.Car2x将通过R&S公司和Vector公司定义的KAA550接口发送UDP数据将上层协议数据通过CMW500发送出去。下图即KAA550的适配接口。
图2. 仪表接口以及连接配置
在Sidelink PC5界面，我们可以对物理层参数以及Fading进行配置。
图3. 仪表接口部分物理层配置
Canoe.Car2x测试平台在完成了Canoe.Car2x，CMW500，SMBV100B的配置之后，就可以在Canoe中进行软件相关配置，场景编辑，场景开发以及测试运行了。如下窗口显示了相关配置信息：
图4. Canoe.Car2x运行界面
消息发送统计：消息发送分析，这里我们可以在图五中看到消息发送是以100ms为周期进行的，即每100ms会完成150辆车的消息发送。在图六中我们可以看到 8.523时刻时，发送150辆车到21次，第21次中，发送到id的值为34。
由此计算8.523时刻时共发送了：20 × 150 + （34 + 1） = 3035次BSM消息。
图5. Graphics窗口 时间 vs 车辆ID发送
图6. Graphics窗口记录BSM消息发送的个数
DUT端的HIL分析我们可以同时在OBU的操作软件中同步分析OBU收到的ITS消息的情况，这里记录了在同样的状态下，待测OBU收到了150辆车发送的消息。
图7. OBU打印log数据
总结
本文介绍的仿真方案和平台可以提供多种功能，例如针对V2X不仅可以实现共计30个基本的DAY1，DAY2的交通模拟场景，也可以支持自定义的场景来进行算法验证，同样也可以稳定支持我们在未来面临拥塞场景的测试挑战。
