张剑：C-V2X商用化亟需明确运营主体 落地细节要聚焦验证、数据、软件三方面

张剑：C-V2X商用化亟需明确运营主体 落地细节要聚焦验证、数据、软件三方面k270 【】2020年10月27-29日，中国汽车工程学会年会暨展览会和第七届国际智能网联汽车技术年会在上海合并举办。大会以“汽车+，协同创新”为主题，围绕新能源汽车技术、智能网联汽车技术、

【】2020年10月27-29日，中国汽车工程学会年会暨展览会和第七届国际智能网联汽车技术年会在上海合并举办。大会以“汽车+，协同创新”为主题，围绕新能源汽车技术、智能网联汽车技术、汽车关键共性技术等话题深度探讨。搜狐汽车作为大会战略合作媒体，第一时间在现场带来专业报道，为您呈现这场技术与思想交锋的盛宴。

以下为电装智能科技上海有限公司移动电子软件开发部部长张剑题为“C—V2X技术商用化验证中的探讨”的演讲：

今天非常高兴能来到现场和大家一起分享我们在商用化验证中的一些想法。

在今天开始讨论商用化验证之前想和大家一起简单回顾一下中国到目前为止在商用化推进中的一些现状。我们到现在的标准体系趋于完成，芯片和产品的技术也不断的成熟，特别是OBU已经百花齐放，在应用方面有一些问题，但是我们已经在往协同服务这个方向不断演进。一致性方面有46家企业已经通过了一致性测试，我们认为可靠性已经进入了一个非常重要的阶段。

介绍之前先简单介绍一下C—V2X电装在中国的情况，全世界来说电装有很多的集团公司，V2X的研发地点有四个，北美、日本、中国、欧洲，这四个据点是一样的研发责任都是面向现地要提供比较适合当地场景要求的V2X产品。在中国主要是上海技术中心和我们公司一起来担当V2X的先期研发工作，这块我们也是欢迎和各个合作伙伴一起能够提供满足中国场景和交通环境的这种高质量的V2X产品。

V2X在电装内部的研究历史，最开始是日本、美国、欧洲在2004年以后开始了V2X研究，那个时候还是DSRC，日本是760兆赫兹，细节的情况刚才高通的李总也介绍了，C—V2X的技术路线的选择也越来越得到了重视。

我想给大家展开两个细节情报，目前这两个路线还是在博弈。在欧洲现在的基站DSRC有900个，马上计划要建6000个，美国C—V2X只有2个据点，但是它的DSRC基站有6000个，马上要建2000个，我们认为中国C—V2X的大力的演进会对这两个国家的技术路线选择产生非常重大的作用。特别是欧洲现在的N-CAP原本要在2024年作为V2X的评价机构被采用，但由于疫情可能会推迟。今年6月份有一个V2X评价方法的工作组项目，电装也加入里面开始参与推动，FCC也提了新的频谱分布方法，北美的汽车工会也提出了自己的频谱方案，这个都还是在观察和博弈之间的一个情况。

电装在中国是2011年进入中国市场，到目前为止最开始是做了一些V2V和V2I的验证，当时用的是DSRC WSU，V2V是和上海同济大学一起做的，V2I是和江苏的太仓市一起做的，关于公交无障碍智能通勤的项目，16、17年我们参加了新加坡30公里无人车队的V2X项目，当时也是用的DSRC技术，在18年年底完成。后面由于中国C—V2X技术的选定明确以后，我们开始转向做DSRC在中国把C—V2X作为我们的研发专电，去年参加了无锡的商业演示，一定要立足现地，和现地的伙伴一起才能打造真正有意义的产品。

日本是我们唯一一个已经商业化落地而且持续到现在量产的项目，大概在2015年推出市场，现在也有几万辆的市场出货量，同时还参加了日本的ITS Connect推进协议会的理事成员，致力于构建安心、安全的汽车社交，到目前为止大部分是预警类。

电装在中国C—V2X解决方案的思路，一开始我们在产品设计的时候同时都关注几个方面。比如高精度定位、高精度地图，我们把地图分为三类，导航地图、PD地图和高精度地图，根据不同的应用采取的地图也不一样。接下来是和ADAS系统的深度融合以及云端的联协和扩展，目前有一个用户体验和能够代表V2X最典型应用场景的打磨或者是寻找，这块是一个重中之重，安全是符合地域的法律法规来对应的。目前对于主流的通信平台都已经有了一个实验室提前的技术验证应用的一个试行，这里我列了两个在不同模组上的产品。

面向商用化其实有很多问题，包括清华张教授说的群体控制智能，包括还有商业模式不明晰，投资运营主体不明确，基础设施规模化部署，应用的丰富和ADAS系统的一些重叠等等怎么办？这些我稍微聚焦一下，聚焦到今天一些具体技术落地时环节的打磨上面，一个是关于星云互联网模式提到的验证环节，第二个是数据环节，第三个是软件环节。

关于大规模通信拥塞控制技术验证手法是非常重要的，这是产生系统最优解的过程，首先要相互谦让避免产生通信拥塞，第二如何保证自车开启拥塞控制以后能够满足场景时候自己的发信需求。刚才王博士展开的数据里面通过车辆密度的控制算法开启以后最大的算力时延会降低到400—500毫秒，非常感谢我们能够利用信通院包括星空互联和很多伙伴提供的实车场景做了应用测试，我们在里面看到的数据是当背景也开启了拥塞通信控制以后，它的时延是150毫秒—200毫秒，这个和我们的预测稍微有一点出入，我们自己降到了300—400毫秒，就是从自测方发信的角度。

场景是固定场景，可能能够调整的是车速、车辆密度这些等的参数，我们认为这种情况下可以把一些典型主要的参数应用都进行一个验证，但是交通场景的类别非常多，我们认为70%—80%可以在实验室里通过一些硬件在环的手法来验证，从成本上可以得到有效的降低，特别是在商用化运作前期。

这是简单的硬件在环的示意图，我们开发了一些实验工具，搭载的环境里面我们可以模拟哪些数据呢？可以模拟发信频率和所有背景车的自己的位置，也可以模拟车辆数量，100多台车，通过一个OBU大概模拟4—5辆车，受限于通信模组伙伴他们那里的频率的一个受限，再往下降不太好，20毫秒发送一次，这个是比较平衡的，如果降到更低可能就会产生一些预想之外的参数干扰。

右边是一个简单的仿真状态，可以在右边看到我们当时设置的发信频率，包括车辆密度，各辆车的位置等等。下面可以看到收信状态和效果，从刚才王博提到的那些数据也可以看到，特别是作为产品落地的时候一个很重要的点，就是自己系统的负载，当自己的拥塞开启以后这个算法首先对不对，对的，这是一个利他行为。

拥塞控制就是在一个固定场景下有限的信道资源被大量的车一起使用的时候，大家如何寻求一个系统最优解，牺牲自己，要符合集体利益，我进行了自己的通信拥塞的算法控制，这个时候你剩下的系统，包括你的系统负载和周围的情况还能不能正常的让你的应用和谐？我们非常期待把后续的试验成果整理出来和业内的伙伴一起分享。

第二，讨论一下数据的问题，数据一致性和数据的可信度问题，到目前的阶段离商用化一个很大的问题就是设计差异，还有各个不同交通环境包括天气等各种情况会导致取得的数据最后到OBU终端的时候使用起来是不是开车要开到上海，到了北京市，甚至了西藏都是一致的？这个其实是不透明的，现在得出的5%和6%是怎么判断出来的？每家公司都有自己的思考。自己收到以后如何去判断数据可不可用，就对OBU的商用化落地提出了考验。

还有一个很现实的问题，V2V的时候如果应用预警出了问题出的问题可以很容易进行责任划分，不管是哪个厂提供的，但是是这辆车产生的问题我们会去找主机厂，这点大家都是有一个终端认定的。但是V2I比较麻烦，路侧所有的提供，如果是信息问题导致的应用失效产生的事故，这个认定机制是去找部品提供厂还是找总机商，这都是细节问题，到落地的时候需要讨论。

我们首先把焦点聚焦到高可靠信上，第一个是统一标准、低延迟、数据精度。这次所有都要做一致性测试，还要过入厂测试，将来路侧这块是否会遵循一定的标准，由统一的机构进行标准认证以后才统一部署，这样的话大家都会比较放心，不管开到什么地方，各个区域都是会获得一致性的数据精度和自己的判断。低延迟这块比较微妙，我们在考虑商用化早期是让终端用户最快去感受到V2X给自己带来的价值，这些边缘云计算的部署长远来说是对的，但是会面临一个比较高的成本，而且政府和投资方愿不愿意在所有的地方做这样一个部署？

当然有人提出会根据各个场景或者不同的交叉口来部署不同的设备，初期的时候是不是可以把一些传感器拿来的数据直接进行广播，而且这个时候可以最大限度把延迟变得透明化，因为传感器到终端发送设备再到车机之间这个时延还没有哪个机构进行详细的测量，在核心网这块我们的通信运营商这边已经进行了自己的优化和验证。

最后是数据精度带来设计方面的问题，来自于不同的第三方情报，作为车机要做多少的冗余设计，这个冗余设计比如所有的OBU之间要做校时，两个OBU的时间必须是同步以后我对你的消息才会做一定的可信和不可信的判断，但是有的OBU是直接从NME的时间里拿到的，在硬件设计里面随着时间的推移可能会出现一定的时间误差，有的OBU厂商除此以外还用一个GPI口取得一个EP的时间进行校时，他的时间更精确。

两个不同厂商提供的OBU之间在进行时间同步时应该相信谁，怎么判断？我们自己肯定要做一些冗余设计进行可信度判断。这一块我认为最难的点不是在设计，而是在边界，我到底要做到什么程度。根据时间序列我来判断可不可信，或者根据逻辑相关性来判断它可不可信，这个也是在商用化落地，在做产品设计的时候需要思考的。

接下来是软件设计时延的问题，刚才高通李总提到底层模组在发信的时候有两种模式，一种是定周期的，100毫秒，还有一种是高优先级的，高优先级的反而会大一点，这个值得我们讨论。

我们认为，所有的设计都要符合安全标准，底层也是遵守LTEV信道调度标准的模组厂商提供的发送机制，在上层软件部分，我们也充分考虑系统负载平衡，遵守100毫秒以内的消息往下送信依赖，结果发现大概是在万分之几的比例下，还是会出现超过100秒的送信延迟。

就像左边可以看到送信端是数据2，在极端的数据调度还有软件自身消耗时间的前提下，最后送信出去的时候到接收端会产生一个98+5，多了3毫秒的一个极端情况。可能有人问这个几万分之几对最后的应用不一定产生什么影响，所有的应用其实是可以跑的。但是作为一个产品打磨来说，一开始的环节可能必须把所有最基础的参数和指标要做到多少个9，我们至少要把所有能够发现的失败率和异常都进行解读。

我们提了两个思路，一个是缩短上层的应用设计，标准设定的100，是可以把100毫秒进行缩短，但是缩短以后对内部的软件运行负载产生什么变化也需要做验证。第二个就是利用新的软硬件接口做简单的向上事件触发握手，在底层模组送信之前会向上端确认一下是否有新的数据，给它一定的缓冲，因为误差也是毫秒级的。但是由于每家厂商设计的思路不一样，包括硬件组成，这个是需要大家根据自己的情况进行验证和更深一步探讨的。

总之，针对中国C—V2X商用化推进我认为主要待解决的课题还是商业运营主体的落实。是由政府、运营商、还是第三方来做投资、运营？谁受益谁来分配。再就是针对车辆，不光是OBU级别的，管理要求要细则化，明确化。最后就是基本设施的大规模的部署，我们一直非常担心的一点是A地已经做了先行示范应用，B地也做了，A地的是否能够拷贝到全国？不可能到每个所有有示范应用的地方都去做技术的详细对接，我的车可能也是面向全国或者更大的范围。

第二就是电装的关键字，电装也是V2X的一个先行者之一，当然它的大部分的技术积累在DSRC，如果它们之间有很多的相通性，我们会把全球经验拿过来，在中国的场景下积极探索和定义符合中国需求的高附加值应用，这个也是我们主机厂的伙伴最关心的一点。

第三，我刚才举了一部分典型例子，分别从验证、软件、数据角度来说，其实在落地之前会碰到很多，特别是在日本量产车辆已经在市面上跑了好几年，那里面有很多可以参照的一些Know-How或者是有借鉴的例子。最终能够推向市场实现大规模的商用化，是不可能靠单一的企业解决所有问题的，需要和业界伙伴进行充分交流，一起来推动这个市场的前行。

我的发言到此结束，非常欢迎会后和所有的C-V2X验证的伙伴进行后续的交流和开展合作。