构建数据闭环，提升自动驾驶系统的核心竞争力
要实现自动驾驶，必然要搞定大数据。利用并转化收集到海量的实际路况数据，可以帮助系统加速学习和升级，也意味着能够率先抢占高级别的自动驾驶技术高地，因此整个行业都极为重视并大力投入。
车辆要想在道路上实现完全自动驾驶，除了要依靠车辆本身的摄像头、毫米波雷达、激光雷达等传感器，还要依靠网联技术的支持。行驶时车辆依靠各种传感器“观察”道路，会产生大量数据，1.5小时的驾驶时间数据量达4TB，车端显然不适合处理和存储如此巨大的工作负载。而车端产生的大量数据，是提升自动驾驶体验、完善算法的关键资源，所以最好是共享到云端，再通过人工智能算法提供大量的训练数据来供机器学习，以搭建虚拟开发测试环境进行验证。
要想在复杂的场景中提升现阶段辅助驾驶/自动驾驶安全性，繁复的测试与验证工作必不可少，由于现实中的驾驶场景难以穷尽，极其复杂且不可预测，在开发和测试的过程中，业界一般通过采集大量的数据构建场景集，帮助汽车打造仿真环境以实现模拟测试。实际路测中，复现一次极端场景的接管可能需要1个月的时间，而依靠数据，不仅可以复现更多极端场景，还可以极大提升测试效率。
此外，在部署自动驾驶车辆之后，会产生大量的回传数据，自动驾驶系统也需要基于这些数据不断进行迭代升级，并通过OTA的方式为用户持续推送新的功能、适应更多的场景和提升体验。
由此可见，基于数据驱动的自动驾驶，在完成前期数据的收集、中间数据的存储与迁移之后，还要对后期核心数据进行训练与管理。因此，构建自动驾驶数据闭环，是自动驾驶产品研发的核心竞争力。
腾讯自动驾驶云平台驱动数据高效流转
腾讯凭借多年在大数据、AI等领域的深度积累，借助腾讯云强大的算力支持，结合本土化的交通场景和应用需求，成功研发出在工具链完整性、场景丰富性、场景真实性等方面行业领先的自动驾驶云平台，极大地提升了研发和测试效率，在云端高并发运行、真实有效性等方面实现了创新突破。
据悉，腾讯自动驾驶云平台基于云端海量存储空间与计算资源支撑，构建了数据采集管理、样本标注、算法训练评测、诊断调试、云端仿真、实车反馈闭环等全流程云服务，提供支撑自动驾驶研发的全链路云服务和开发平台。
在数据治理方面，腾讯自动驾驶云平台的样本标注服务采用国际顶级算法预标注，可在实现样本自动化生产，提升生产效率的同时，积累海量样本数据，包括全要素目标检测、跨相机目标跟踪、语义分割等图像标注、3D激光点云标注、以及精准图像与3D点云融合标注、变道标注等多种自动驾驶研发专用样本等。此外，该技术在计算节点中闭环运行全栈自动驾驶算法，支持一万个以上场景的并行计算，使得1000个测试场景的运行时间从2天大幅缩减至4分钟，并实现全自动化测评。在虚拟城市中数以千计的自动驾驶车辆不间断的持续行驶，并通过随机工况和激进交通流提升测试复杂度。
在数据应用层面，在测试工具之外，对于测试管理、政策制定等相关部门来说，仿真作为智能网联汽车最重要的测评工具,既可帮助企业掌握在车辆研发、测试和集成的不同阶段的安全边界和质量问题，也有利于相关标准制定和场景库的建设，通过信息化和标准化的手段提升智能网联汽车行业透明度。在产业互联网领域，腾讯致力于做数字化的连接器和工具箱，腾讯自动驾驶云平台也在和OEM厂商、测试场、政府机构、产业联盟乃至科研机构广泛合作，推动应用落地。
（图/文/摄： 石家庄01）@2019
计算平台相对系统的发展速度是落后的。
文 | 祥威
“整个行业的自动驾驶系统量产时间节点延迟了，因为在那个节点上要有一个车规级的域控制器。行业内原定的是2021年的第一季度（实现自动驾驶量产）。现在普遍都延后了一年或一年半。”比亚迪智能驾驶首席专家王欢近日接受新智驾专访时表示。
域控制器是指自动驾驶 汽车 的计算平台，相当于车载大脑。在王欢看来，近年来计算平台相对系统的发展速度是落后的，由于缺少满足车规级的自动驾驶域控制器，导致大部分主机厂和供应商在开发时只能暂时冷处理，将整个量产的时间节点向后推迟。
新智驾了解到， 汽车 产品标准分为消费规、工规和车规。其中车规是级别最高的，需要通过抗冲击性、振动性、防火和高低温等实验。同时作为智能驾驶功能安全， 汽车 产品必须满足ISO26262标准。
谁能率先推出车规级自动驾驶域控制器？关键或许在于客户群体。
王欢认为，由于大陆、博世拥有庞大客户群体，所以向客户推送时会更加方便。华为在做生态，由于体积大、联盟伙伴多，推起来可能也会更加容易，但创业公司面临的困难可能会比较多。
除了域控制器，实现自动驾驶量产还涉及到一些研发模式等问题。比如，对于许多公司采取的在改装量产车上进行方案论证的模式，主机厂会认为它并非量产的正确模式。
据王欢介绍，面对复杂的自动驾驶，主机厂需要有正向的开发模式、验证体系、自动驾驶系统架构等。
他在一次名为《自动驾驶开发升级》的主题演讲中重点介绍了这些量产要求。以验证体系为例，自动驾驶对于开放道路测试数据、人机交互、评价维度和系统架构均有着迫切需求。而且，这些需求与传统 汽车 有着根本区别。
附：
今天我站在主机厂的角度，分享一些自动驾驶开发升级过程中面临的问题。
众所周知，自动驾驶的开发模式主要分两种，一种是以Waymo为代表的 科技 公司主导的跨越式开发模式，一种是以特斯拉以及其他主机厂主导的渐进式开发模式。跨越式开发模式是指跨过L3，直接研究L4级自动驾驶。渐进式开发模式主要指以传统的ADAS技术为基础，慢慢过渡到L3、L4。这两大阵营在开发工作项目中也有紧密的合作，一些算法公司、传感器巨头都参与到了合作当中。
无论是L3还是L4，行业内都遵循着这样的原则：首先要找出自动驾驶的落地点，然后分析这些落地点的场景，基于场景开发功能。或者沿着反方向，从场景功能倒推落地点。
如果自动驾驶适合的场景非常少，边界非常窄，对 汽车 的安全贡献就会非常小，甚至由于运行过程中超出边界而发生危险，那么，它就是不安全的。同理，如果驾驶场景边界特别宽，现在的技术又不能全面分析它的安全性，那么，这种场景也是比较危险的。
总结看， 自动驾驶就是要确定合理的场景，并且设定科学的安全目标来进行开发，行业也都是按照这个流程来做的。大家会逐渐地把功能开发聚焦到几个方面，以L3和L4举例，它们包括HWP、TJP和AVP等，这个过程中有大量的方案论证，经过大量的验证，然后展示，再示范运营，最后收集数据进一步优化算法。
其实在主机厂看来，这种模式基本上量产不了，原因很简单，量产的过程比这复杂得多。因为量产自动驾驶是一项很庞大的工作，投入会很大，时间也会很长，车厂还要和一些公司建流程、出标准等等。所以说大家之前做的工作意义很大，但是还不够。
对于这种复杂的开发，我们迫切地需要对原始的开发流程进行升级，不仅要有一个正向的开发模式，还要有一个验证体系。此外，由于现在的开发都是类似于后装的车改制的方式，所以还需要一个自动驾驶系统架构。最后，人机交互和车辆平台也是非常重要的。
自动驾驶是以车为中心的车辆系统，所以还是要遵循V流程开发模式，在开发过程中要借鉴传统的标准。一些标准比如说ISO21448，它只针对L1、L2而不针对L3，但是没有关系，我们可以借鉴里面的思想，然后扩展标准里的开发流程。
主机厂更注重什么？首先是预期功能安全，它关系到能否解决场景的问题。甚至可以说，产生自动驾驶危险更多的是因为场景不足，而不是系统的不安全。预期功能安全这个标准主要关心四个范围。范围一是已知的安全场景。范围二是已知的不安全场景，范围三是未知的不安全场景，范围四是未知的安全的场景。
很明显，我们的重点是在范围二和范围三，怎么样用一切办法缩小它们的范围很重要。
首先，必须要有一个场景库，场景库是任何一个开发团队的核心数据库。通过场景库，找到一些不合理或者是不安全的场景，针对这些场景提供安全措施，通过验证安全措施的方式，最终达到安全目的。当安全目标都能够满足范围二的范围标准的时候，主机厂就可以接受了。针对范围三，对于未知的不安全的因素怎么考虑，其实对这个问题，可能到现在我们的行业都没有一个有效的方法，都是按照完整分析测试来实现的。所谓的完整分析，其实是对于一个基础场景进行排列组合的分析，对它所有的可能出现的状态进行分析。
然后是功能安全标准ISO26262，这个标准已经比较成熟，但在L3自动驾驶上的分析还是比较新颖的，可能目前来看，还没有更全面的分析经验。
针对L3级别以上的自动驾驶与传统的ADAS等级的功能安全的区别在哪？在L3的开发过程中，我们进行安全分析时目标和对象会更庞大。比如，基于V2X的HWP功能进行分析，当我们进行分析时，除了对车进行分析，还要对通讯接口、路边设备已经云端服务器进行分析，这是自动驾驶功能安全需要额外考虑的问题。
信息安全方面，自动驾驶要解决的问题是怎么抵抗黑客攻击和网络攻击。在整个行业内，信息安全几乎没有一家能够独自完成。为什么？因为一旦车联网以后，它能够被攻击的接口太多了，有网关、T-BOX、V2X、第三方的云、主机厂的云、手机APP、车机、充电桩等等，甚至包括自动驾驶传感器及系统本身，这些都会受到信息安全带来的挑战，所以需要各方合作。
无论信息安全还是功能安全，最终的落脚点都是车，如果车不动，发的信息车不执行，那就是安全的，所以功能安全和信息安全之间有某种联系。
在开发的过程中，怎么判断这种关系，将他们联系在一起？首先我们要定义一个安全指标，并且对这种安全指标进行策略分析，分别执行两件事，一个是功能安全，一个是信息安全，这一流程应该可以把功能安全和信息安全联系在一起。
以上这几个安全，包括V流程的一些开发，是主机厂面临开发升级所面临的挑战。
接下来谈一下验证过程。传统的ADAS开发有很多地方可供借鉴，但是它和自动驾驶的深度和广度完全不是一个数量级的。智能驾驶更关心的数据，或更难拿到的数据是开放道路测试数据，这是有实际意义的，而且是必须要有的。
然后是人机交互，这也是验证过程中的重头戏。整个验证过程的工作量是非常大的，是每个主机厂的核心工作。问题的关键点不仅在于怎么测试，还在于怎么通过一个评价体系把这些东西串在一起。
要引入我们虚拟测试的自动化，只有自动化才能够满足我们对这种工况的分析的条件。
分析结果后怎么评价，我在这里给出几个维度的建议，一是安全度，一是舒适度，车与车之间的交互等等一些因素。以安全度为例，主要是碰撞，碰撞的程度怎么样，碰撞之后车辆的表现如何。我们会发现，每个主机厂对自动驾驶的理解是不同的。
下面谈一下主机厂更关心的系统架构。
大家的前期开发都是基于量产车的改装，属于后装形式，成本也很高，这时就急需一种正常的智能驾驶架构。要搭建这种架构的前提是针对什么样的功能。基本上，功能可以分为两大类，一个是Fail-safe，一个是Fail-degrade，这些功能分别包括定位、感知、警醒等。
针对这些功能的架构，我们可以给出一个架构体系，就是传感器的输出到主辅控制器的工作模式，主辅控制器的工作受到安全监控这个模块的宏观调控，再决定是由主控制器来控制，还是辅控制器来控制，这是行业比较认可的一种架构。当然这里面没有提到通讯和电源的冗余，正常情况是要考虑到的。
这个功能集成是指控制器必须有L1和L2的功能，也包含L3的功能，现在的车上既然已经有了L1和L2的功能了，如果控制器只有L3的功能，意味着车的成本是增加的。那么，为什么不能用强大的计算力，在L3的控制器把L1和L2一起都做了呢？在项目的开发过程中，其实能够提供这种解决方案的人也比较少。
对于未来的OTA软件升级，包括降低成本和轻量化，其实主机厂对于这种体系架构有迫切的需求。
域的概念有一个好处就是功能集成。近年来行业里提出来一个架构，就是以车辆的物理空间为基础的域，比如它可以控制雷达、应急车灯。像这种域很明显，它的布线就比较简单，但是它对软件架构要求非常严，这种域在特斯拉的Motel3上已经量产了。
然后是人机交互。在L3上，已经不仅仅是人机交互那么简单的事情，而是和安全甚至控制有密切的关系。传统 汽车 的人机交互大部分基于人对 汽车 信息的监控，L3、L4之后， 汽车 要监控人的信息，这是有着天壤之别的。
所以针对人机交互的开发是不容小觑的。驾驶员在接管了自动驾驶之后的表现怎么样，他慌不慌张，他迷不迷茫。另外一点就是车在接管之后，它的功能表现怎么样，不同的车辆之间的替换，不同安全等级之间的切换，尤其是L2和L3，因为L2也控制纵向横向，L3也控制纵向横向，驾驶员容易混淆，以上的这几点加在一起，就需要有一个行业上统一的HMI标准，这正是我们需要的。
同时还有一些其他的标准，包括乘客上下车的交互和场景的交互等。场景的交互主要是指车和车，包括L4的远程控制等等。另外，人机交互还必须有关于漏报和误报的指标，不能总发生狼来了事件。
最后谈一下车辆平台，L3以上的自动驾驶开放平台和传统的车辆平台之间的差别在哪，我认为主要体现在，传统 汽车 上，驾驶员在驾驶的时候，要求舒适性、操控性和安全性，但是在自动驾驶系统控制时，问题就来了，我们称这个车是Fail-degrade的，是双备份冗余的。
这个双备份冗余指的是执行层面，包括制动、转向和电源等等，以及自动驾驶对车辆指令的响应，对响应性要求是很高的。另外就是车辆动力学的性能，发出一条指令之后的运动应该是线性的，不能是非线性的。
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）