比亚迪王欢：自动驾驶卡在域控制器环节 量产或将延后至2022年 | CCF-GAIR 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，这些功能分别包括定位、感知、警醒等。

针对这些功能的架构，我们可以给出一个架构体系，就是传感器的输出到主辅控制器的工作模式，主辅控制器的工作受到安全监控这个模块的宏观调控，再决定是由主控制器来控制，还是辅控制器来控制，这是行业比较认可的一种架构。当然这里面没有提到通讯和电源的冗余，正常情况是要考虑到的。

其实在架构方面，主机厂更关注的不是架构怎么实施，而是更关心域的概念。为什么说域是未来趋势？因为L3的特点就是功能集成和信息共享。

这个功能集成是指控制器必须有L1和L2的功能，也包含L3的功能，现在的车上既然已经有了L1和L2的功能了，如果控制器只有L3的功能，意味着车的成本是增加的。那么，为什么不能用强大的计算力，在L3的控制器把L1和L2一起都做了呢？在项目的开发过程中，其实能够提供这种解决方案的人也比较少。

对于未来的OTA软件升级，包括降低成本和轻量化，其实主机厂对于这种体系架构有迫切的需求。

域的概念有一个好处就是功能集成。近年来行业里提出来一个架构，就是以车辆的物理空间为基础的域，比如它可以控制雷达、应急车灯。像这种域很明显，它的布线就比较简单，但是它对软件架构要求非常严，这种域在特斯拉的Motel3上已经量产了。

然后是人机交互。在L3上，已经不仅仅是人机交互那么简单的事情，而是和安全甚至控制有密切的关系。传统汽车的人机交互大部分基于人对汽车信息的监控，L3、L4之后，汽车要监控人的信息，这是有着天壤之别的。

所以针对人机交互的开发是不容小觑的。驾驶员在接管了自动驾驶之后的表现怎么样，他慌不慌张，他迷不迷茫。另外一点就是车在接管之后，它的功能表现怎么样，不同的车辆之间的替换，不同安全等级之间的切换，尤其是L2和L3，因为L2也控制纵向横向，L3也控制纵向横向，驾驶员容易混淆，以上的这几点加在一起，就需要有一个行业上统一的HMI标准，这正是我们需要的。

同时还有一些其他的标准，包括乘客上下车的交互和场景的交互等。场景的交互主要是指车和车，包括L4的远程控制等等。另外，人机交互还必须有关于漏报和误报的指标，不能总发生狼来了事件。

最后谈一下车辆平台，L3以上的自动驾驶开放平台和传统的车辆平台之间的差别在哪，我认为主要体现在，传统汽车上，驾驶员在驾驶的时候，要求舒适性、操控性和安全性，但是在自动驾驶系统控制时，问题就来了，我们称这个车是Fail-degrade的，是双备份冗余的。

这个双备份冗余指的是执行层面，包括制动、转向和电源等等，以及自动驾驶对车辆指令的响应，对响应性要求是很高的。另外就是车辆动力学的性能，发出一条指令之后的运动应该是线性的，不能是非线性的。

混动系统有隐患，丰田召回75.2万辆普锐斯

[爱卡汽车 科技频道原创]

随着新能源车的大量推广，想必大家现在已经对新能源汽车无故趴窝、失去动力的新闻见怪不怪了，市场上大部分车型都或多或少出现过这些问题。但让人没想到的是，丰田的混合动力车型竟然也会中招。近日，丰田宣布将在全球范围内召回2013-2015年间生产的Prius车型以及2014-2017年间生产的Prius V车型，总数达到了75.2万辆。

据丰田表示，问题主要出在混动系统。根据设计，普锐斯和普锐斯V在遇到混动系统故障时应进入故障安全模式（fail-safe mode）。但是丰田发现，在极少数情况下，车辆可能无法按预期进入故障安全模式，这将导致车辆失去动力并熄火。虽然转向系统和刹车依然可以正常工作，但车辆在高速行驶时突然熄火显然会增加发生事故的风险。在召回之后，丰田将通过软件升级来解决这个问题，必要的话还会更换逆变器。

丰田的第一代普锐斯车型在1997年实现了市场化，开始正式上市销售。到今年5月，丰田旗下各类混动车型的累计销量已经超过1500万辆。这些车没有出现过电池起火等重大事故，在安全性能方面应该说是非常可靠的，及时的召回有助于丰田延续其混动车型的安全记录。

汽车召回是一种很常见的售后措施，及时的召回也是厂商负责任的表现。随着汽车电子电气架构的更新，OTA空中升级功能将会逐渐普及，届时召回将会越来越少见，一般的软件故障只需要用户自行升级软件就可以解决，涉及到更换硬件的情况才需要召回。

编辑点评：召回不可怕，但是很麻烦。现在的新车都是机械和电子技术的结合体，软件故障越来越常见。以特斯拉为代表的新一代智能汽车能够更好地适应这种新形势。它们的软件升级不但能扩展功能、提升体验，也能解决软件故障，为厂商和消费者省去了召回的麻烦。

精彩内容回顾：

大众ID.4/比亚迪新e6 这期公告有看点

新平台+新动力 第十代索纳塔技术解析

不只改头换面 新款宝马5系/6系GT解析

丰田(进口) 普锐斯(海外)

请输入少于17字的页标题