SAECCE 2020 | 星云互联王易之：车路协同面向规模量产的通信与应用测试

2020中国汽车工程学会年会暨展览会（SAECCE 2020）于2020年10月27-29日在嘉定上海国际汽车城-上海汽车会展中心举办，汇聚汽车及相关行业的企业高层、技术领军人物、资深专家学者、广大科技工作者。10月28日，北京星云互联科技有限公司联合创始人、副总经理王易之在本次大会上发表了主旨演讲。

 以下为演讲实录：

各位尊敬的领导专家，各位老师，业界的朋友，早上好！非常荣幸能在这里跟大家做这样一个分享，题目是“车路协同面向规模量产的通信与应用测试”，讨论的议题是面向规模量产，这也是我们现在探讨V2X比较多的议题，分为两个部分，一个是通信，一个是应用，究竟应该如何测试，如何走到量产的级别。

    首先是规模化V2X终端通信测试，我们在大规模的终端部署环境下通信是否依旧可靠，在国内外类似的测试做的都很少，或者还是空白的状态，大家都想知道是什么样子。C—V2X技术目前可以说是迎来了发展和商业化的关键阶段，从最初的实验室到后来的小范围的开放道路，通过后装进行示范，现在已经开始讨论前装，开始讨论城市化基础设施的部署，包括开始考虑和智能驾驶的融合，需要规范的测试认证体系和测试工具的建立，大规模的测试也是为前装量产和大规模部署奠定一个基础。

    为了测试真实交通场景下的LTE—V2X在不同参数配置下的大规模通信性能，我们也找了一些合作伙伴，从去年年底开始立项，今年9月正是在北京海淀驾校展开了为期两周的测试。主要的场景是模拟了城市里拥堵的十字路口，在一个交叉口部署超过200辆车的情况，它的通信性能、V2X、V2I到底是什么样子，植入上我们部署模拟高速公路大密度的环境，看通信性能能达到什么样的情况。

    测试设计当中针对两种典型的场景提出了23种测试项目，包括对V2X、V2I之间的选择，信道的探索、拥塞控制的开启或者是关闭等等，都进行了测试项目的设计。在KPI评估指标方面，给出了七个评估指标，分别是信道繁忙率、时延、丢包、发包间隔、收包间隔、消息周期、位置跟踪误差，从定义上来看有的大家比较熟有的稍微陌生一点，是比较偏通信的评估参数，在测试当中也是收集了1万多份测试日志，总计200G的数据文件在进行统计。

    后面对测试关键的一些结果跟大家分享一下，讨论大规模测试首先就要讨论车辆密度，也就是通信节点的规模到底对它有什么影响？分别选取了198台、102和54台有效的通信终端，在300米的植入上采用10兆的信道以及开启拥塞的情况下来测试的，最高时候达到70%多的信道繁忙率，由此带来的左下角的密度导致的接收丢包率会增大。丢包率就是一个终端左右100米范围的丢包率，不讨论距离的丢包率是没有意义的，所以在拥堵的环境底下车辆是可能堵在路上更关心前后100米范围内的丢包，最多是在200辆车的时候是到9%点几的丢包率，其实也还可以。100台的时候大概是5%多，还有一个是3%多的丢包率。

    密度引发的拥塞控制的算法，导致发包间隔ITT增大，发包变慢，发包的间隔最大能到400多，接近500的发包间隔，时延三者没有太大的区别，因为发送端选择的时间可能会变长，所以时延在车速度越多的时候时延会偏大一点。

    交叉路口OBU之间的通信测试，总体上将200台设备部署在交叉口，100米范围内的丢包率平均维持在6%左右，从右边两张图的对比可以看到不同的位置，路口中心设备对于其他设备的丢包率是相对比较低的，而右下角处在路口其中的一条路段最边上的车对于所有这些设备来说，由于遮挡或者距离的问题丢包率还是比较高，尤其是在距离远的或者在相邻的路段上。

    直路OBU间的通信测试，一条300米的直路部署200个终端，开启拥塞控制，所有OBU设备在100米范围内的通信可靠性达90%以上，但是随着距离的变化也是非常显著的，植入一端的设备接收另一端的好几百米的设备丢包率就会上去，这个跟规模是非常有关系的，我们知道如果两个设备通信可能到500米丢包都几乎是0，但是由于是大规模的存在，空口中存在非常拥塞的通信信号，而且我们的测试小车一个小车上挂了六个设备，也就是说有五个人可能在你的耳朵边用很大的声音说话，那你再去听300米外的人说话这就是很困难的事情。我们通常讨论LTE通信距离300米、500米，但是我们讨论200个终端环境下的时候就是另外一回事了。

    拥塞控制对于通信的影响，我们做标准的同事了解这是现在在标准当中讨论的一个比较重要的议题，这里采用基于车辆密度的拥塞控制的算法，在右边可以看到它对于开启算法和关闭算法的时候它对发包的控制以及对PI的降低还是比较明显的，拥塞控制算法有效改善了IA，也就是说一个包发到了我这里，这个包在我这里维持的时长直到我收到你的下一个包，我能持续追踪你，而不是一段时间你给我连续发包，但是有一段时间隔五秒都不给我发，我就会把你给丢掉了，这种情况是非常危险的，所以这也是拥塞控制算法最有价值的一个地方。

    直路上面移动车通信测试，重点探讨的也是在拥塞控制算法里面的一个位置追踪误差的值，它其实是由设备A的实际位置和设备B推算出来的设备A的位置差，因为在设备B端要去进行一些应用场景，是对设备A的位置收到的消息以及里面的状态对它进行预测，所以存在这样一个误差。我们的结果会表明车辆的行驶速度越高车辆对于周围位置估计偏差也会越大，同时车辆的定位模块精度越低位置跟踪误差也会越大，这也是非常显然的一个结果，包括V2X在内需要定位模块，精度还是越高越好的，从技术上来讲越高越好。

直路双移动车通信测试，也是在200个终端的环境底下，这个结论比较有意思，我们对比SPS消息，也就是半静态调度模式发送的消息，提前预留空口资源，周期性的发送，我们设置300字节的数据包，包括紧急事件，比如紧急刹车、车辆故障，我们设置了450字节的方式，导致的结果非常有意思，它的丢包率反而不如SPS的丢包率，尽管它拥有更高的优先级。

数据分析出来是这样，结论尚有疑问，所以我们推测可能是跟200辆车的拥塞的环境非常相关，因为资源已经非常紧张了，这个车如果要紧急事件触发再去发一个数据的话，有没有资源让你选择，这是一个最大的前提。对于时延的对比还是比较显著的，当它拥有更高优先级的时候时延会显著比一般的消息低，低大概20个毫秒左右。对于时延我多补充一句，时延在我们的测试当中大概的均值是40—60之间，可能很多人会觉得LTEV时延不是宣称20毫秒以内吗，也可以做到，只不过在正常使用的时候芯片和模组这边会考虑整体的QOS，会把时延、设备接入数，对于数据包的支持都会考虑进去，综合下来我们认为，现阶段基础应用还是以100毫秒以内的要求，所以我们把它定格在40—60毫秒的时延。

    我们引入了RSU，执行道路上OBU和RSU之间的通信，也是选择200台设备，在路端中心部署了一个RSU，模拟了四个消息，也是现在标准制订当中的典型的四个RSU发送的，也是典型的字节数大小和发送优先级。从丢包率可以看到，数据包越长，字节数越多的丢得更多，但是总体上都会维持在10以下，大部分在4%以下，因为是RSU独占了10兆的信道，所以那200台车对它其实是没有什么影响的。RSU的时延也是一样，数据包越长时延会长一点，但是相差并不大。

    信道对通信的影响，刚才看到OBU是10兆信道，RSU也是10兆信道，因为我们知道美国给为V2X分配了75兆的信道，我们做了对比发现在测试条件下随着带宽的增加对于CBR的降低作用是显著的，约25%，对OBU而言，带宽的增加，有效降低了PER2—6%，对RSU的消息而言，与大量OBU竞争20M带宽，优化了近端局部的PER，但远端的PER升高显著。对于RSU这个结果非常有兴趣，RSU本来是独享10兆信道，本来是比较平的丢包率的曲线，变成20兆信道跟所有车进行竞争的时候在近端的PR会更好，而远端的会比较差，这个其实也是挺有意思的一个结果，对于远处现在标准草案当中定的结论也是为了优化RSU的表现，所以竞争之后导致的PER的增大也是很显然的。

    总结的外场测试报告，我们会在近期有完整的一个报告发布，我今天只是摘取了几个比较典型的结果跟大家分享，也非常感谢我们的合作伙伴高通、信通院、国汽智联，还非常感谢中关村委员会海淀驾校的支持。

    解决了通信的问题，我们还要做应用，量产阶段的应用如何进行开发和测试？包括这次“新四跨”可以在外场体验很多的应用。

    我们在F1封闭区在10月份已经做了大半个月大规模的测试，其中一个测试相就是在这种情况下去进行应用的一个测试，所以这里有两个典型的例子，都是最基础的FCW前景，前向碰撞。我们可以看到这个车辆在迅速接近前面的车，什么也没有发生，然后迅速的拐开，事实上咱们今天没有声音，它在拐出去的那一瞬间才触发了预警，这是一个非常晚的预警，基本上不起什么作用。这个是实际相对较晚，但是结果还可以，如果反应够快的话也还可以，其实也有语音在提示。

    对于应用场景虽然很基础，非常简单，过去这些年我们行业所有的研发企业事实上已经完成了我们的协议一致新，以及场景功能DEMO的阶段。再往下首先是数据一致性，这个也是我们面向量产必须要解决的问题，大家知道我们的“四跨”事实上也是提前了一段时间让大家过来这边做调试和测试，真实的量产车不可能让你开到社会道路上还要给你提前多长时间让你去调试，你应该到哪儿就能触发这些应用场景，所以这个就是存在于我们所有的这些研发的企业，企业在现行标准的部分要对他里面所有标准的结构、标准格式以及里面数据内容的一致性有非常一致的理解，这样才能做到随到随用，互相之间能完全的一致的理解。

    量产级的应用场景，这里的应用算法可以看到是有过晚的和相对较晚的，还有相对早就预警的，我们究竟如何去做？所以我们一直以来作为一个非常简单的DEMO开发，我们通常是做一个功能定义，然后开发，然后进行道路测试，直接进行算法的迭代。我们现在需要把它做细化的一个研发流程就应该是功能定义，做功能模型和算法的台架的测试，算法迭代，通过之后进入道路测试，道路测试的数据也需要采集回来形成V2X专用的场景库，我们一般会听搞自动驾驶的，搞智能驾驶的去讨论场景库，去建立什么样的场景库，实际上V2X也需要专用的场景库来帮助我们做算法的迭代和提升，做这样一个闭环研发的周期，才能实现量产的研发。

    什么是V2X专用的场景库？场景库肯定包含了若干个场景，每个场景对V2X来说是一个基于通信的一个系统，每个场景需要给它做标签，是什么样的一个城市，什么功能，面向什么场景，什么道路，所有的场景基于一个时间线，分成不同的场景帧，每一帧包含了自车数据、环境数据，这个环境数据不像搞自动驾驶的是视频的数据、雷达的数据，它是通信的数据，也就是我们所有的空中通信的这些消息的一个记录，存储在一系列标准的格式里面去做这样的一个测试。

    V2X场景库的流程，我们吸收场景库的采集分析工具，需要公开的数据集来制作，需要场景的描述，对于待测算法模块需要一套测试系统对它进行测试和结果的输出，然后生成一个测试报告。场景采集工具，这是我们在真实的研发过程中的一个需求，最后总结下来需要这样一个用来场景库录制，同时实时的数据分析实时进行场景的回放这样一个工具，我们搞V2X不光是有OBU和RSU，实际上还需要其他配套的很多其他东西才能把这个事情做好。有了场景库之后增加场景仿真的模拟器就可以对算法模型进行迭代，比如说对于FCW的算法的场景的迭代，事实上这样的算法跟我们在“新四跨”外场我们的终端里的算法是一模一样的，我们也是经过了这样一个算法的开发流程。包括交叉路口的碰撞也是一样，我们通过场景库回放，加载真实的应用算法的方式对它进行验证和标定。

    对模型做完了验证，因为所有的触发是需要经过整个终端系统的处理，当然里面可能还有一些对硬件的延迟，它的计算能力的要求，所以我们需要进一步做硬件在环的测试，对于V2X来说硬件在环就需要依赖场景库，依赖V2X的协议站，依赖测试仪表，也就是把这个消息给发出来，帮被测的终端去创造一个跟外场一样的网联环境，外场可能是有一大堆的网联消息，我就需要通过一个仪表加载上这样的一个协议站，把所有的环境给创造出来，然后帮你去做应用的触发，然后再进行结果的分析。

    如果都过了之后最后要去进行外场的测试，外场的测试也需要一套测试和评价的方法，这个也是我们跟上海淞泓这边的合作伙伴一起探讨，在我们平时的测试里面总结出来，我们希望在行业里面申请这样的一个立项，去对于V2X的这儿应用和系统进行测试评价，包括测试场景、测试要求、评价方法等等，细节的内容今天晚上我们有联盟V2X工作组会，也是会有淞泓的同事来给大家详细介绍。

    我今天的报告节到这里，非常感谢大家谢。

敬请关注“2020中国汽车工程学会年会暨展览会（SAECCE 2020）”直播专题：https://auto.gasgoo.com/NewsTopicLive/282.html

（注：本文根据现场速记整理，未经演讲嘉宾审阅，仅作为参考资料，请勿转载！）