郭继舜带你读汽车科技

About 郭继舜带你读汽车科技

《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，每周一至周五更新，每日一期，内容独家授权汽车之心发布。

Publisher

汽车之心

Category

business · news · technology

Language

zh

Explicit

No

First episode

18 May 2020

Latest episode

2 Jul 2020

Latest episodes

17 episodes in the feed.

1. 

   2 Jul 2020

   017 | 在智能驾驶的开发中，为什么仿真的作用越来越重要?

   编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，内容独家授权汽车之心发布。 各位朋友，有挺长一段时间没有更新了，因为这段时间我一直专注于处理一款量产车型的智能驾驶功能问题。 这款车型很快就要量产了，但是智能驾驶功能还有比较大的优化空间，至少还没有到让我们满意。 其实每当到了某个车型智能驾驶配置即将量产的前夕，都是最忙碌的时候，大量的道路测试会反馈回无数多的问题，每天都在不断解决算法 bug 和反复调试系统参数。 因为每款车型我都希望能搭载一些新研发的功能，这些技术的亮点在研发过程中也会是最难做好的问题，所以智能驾驶汽车的研发很像是西西弗斯，每个车型就是一块巨石，痛苦和成就感交替，周而复始。 而最近这款车型，是我从事智能驾驶量产这些年中，最狼狈的一次，因为想上尽可能多的新功能，所以见到了人生里最长的问题列表。 终于，到今晚为止，关闭了 94% 的遗留问题，功能和性能表现达到了不错的水平，赶快来录音频把这几天欠的债补上。 首先，我要把这几天调试的一部分心得给大家做一个梳理，以下主要针对智能驾驶量产的整车系统表现，不包括 L4 及以上智能驾驶： 1. 多传感器融合是非常不好做的，特别是在速度比较高的场景下，更是需要耐心的调教和测试； 2. 我记得 2018 年的 CVPR，在一个智能驾驶的 Workshop 中讨论过一个话题：现阶段什么技术是自动驾驶算法中最难的技术？众多业内大佬经过热烈探讨，结论是感知依然是当前自动驾驶最难做好的技术。 我当时有点不以为然，一群做深度学习和计算机视觉的专家，肯定说自己做的这部分技术含量最高。 经过这几天的历练，我越来越深刻地感受到，感知确实是现阶段最难解决的问题，感知不准确，我们在决策端做再多的算法补偿的效果都是有限的； 3. 行车场景下的各种大货车、模糊不清的车道线、新旧车道线交叠的场景，是最容易影响智能驾驶表现的场景. 泊车场景下，用不同颜色砖块表示泊车线的泊车位、地下停车场柱子旁边的泊车位，这些场景很考验融合泊车系统的鲁棒性； 4. 选择好的执行器件非常重要，特别是 EPS，死区过大往往会让你和工程师们有抱头痛哭的冲动； 5. 智能驾驶开发，仿真平台的作用愈发关键了，实车测试遇到典型场景的密度太低，造成测试效率数量级上的落后。 现阶段，我们在 L4 自动驾驶研发中使用了相对多比例的仿真测试，但因为量产的 ADAS 车型需要兼顾运动学和动力学的系统性能仿真，所以现阶段还不能把各种段整合得足够好。 量产层面，我们还是比较依赖实车的测试验证的。 但大趋势是，整车厂越来越需要智能驾驶仿真了。 其实我们很早就开始尝试使用侠盗猎车手 5、百度 Apollo 平台等来做智能驾驶算法的仿真。 量产上也会使用台架、车辆在环系统进行一部分的仿真工作，但真正让我有深刻触动的，是有一次针对一款旗舰车型的实验样车审批。 因为近年来智能驾驶、车联网功能量产搭载的比例非常大，样车需求也急剧增加，加上智能驾驶的很多功能在量产前的功能验证，动辄数万公里的验证里程，让智能驾驶成为了实验样车需求的大户。 举个例子，去年某款新能源汽车的 AEB 一个功能，我们就验证了 5 万公里。 最终这款旗舰车型的样车需求统计下来，数字惊人，加上实验样车因为量少，零部件成本非常昂贵，样车总计的成本几乎上亿。 所以大家以后在路上看到有伪装的实验样车，可别笑他们破破烂烂，每台车买一两台保时捷 718 是绰绰有余的。 前面讲到仿真的重要性，今天我们就来谈谈自动驾驶的仿真技术。 首先，简单总结自动驾驶为什么需要虚拟仿真技术： 1. 虚拟仿真能够以非常快的遍历速度和极高的场景密度让自动驾驶系统在更多场景下对算法逻辑和功能进行验证，其算法逻辑验证的效率是实车测试的数百、上千倍； 2. 虚拟仿真能够还原极少出现但理论上还是会遇到的 Conner case，甚至是车祸场景，在实际路上故意创造这样的场景的成本很高，也有危险性； 3. 虚拟仿真能够对所有交通参与者的行为进行定量的设定和改变，这样就能够创造出更多的场景，轻松验证场景的覆盖度； 4. 在未来使用量产车型众包的方式来收集场景的过程中，我们需要使用虚拟仿真还原众包数据的结果； 5. 全都用实车测试太贵，算法改进效率也很低； 6. 其实 MPI（Miles Per Intervention），也就是脱离里程，是非常不科学的评测自动驾驶系统能力的手段。 后续我们可以通过收集足够多的场景，使用虚拟仿真系统，快速客观地通过测试不同自动驾驶系统的场景覆盖度来评估优劣。 1、什么是自动驾驶虚拟仿真技术？ 实际上仿真技术从计算机诞生之初就已广泛应用在现代工业化大生产的体系中了，从计算机辅助设计（CAD）、计算机辅助工程分析（CAE）到计算机辅助生产制造（CAM），虚拟仿真技术在其中都起到了非常重要的作用。 仅以汽车行业为例，我们常见的就有空气流体力学仿真、车体碰撞仿真、发动机燃烧过程仿真、车身 NVH 声学仿真、车辆动力学仿真以及车辆控制算法仿真等等。 这些仿真技术的类型与应用各不相同，但是其核心原理仍然是计算机建模与应用，大致的过程可以抽象为以下几个步骤（如下图所示）： 1）分解过程：根据业务过程闭环，将应用系统划分成为接口明确的子系统。具体到智能驾驶，就是把智能驾驶的各个功能和软硬件模块划分出来。 2）建模过程：根据应用需要，对子系统从原理与数据上进行计算机建模，建立子系统的仿真模型。具体到智能驾驶，就是把智能驾驶的某个功能或者零部件的原理或者特性在计算机上尽可能逼真地建立数字化模型。 3）仿真过程：根据测试需求，将部分子系统替换为虚拟的子系统模型，利用仿真引擎进行虚拟仿真下的业务闭环，必要时可以并发进行；具体到智能驾驶，就是在程序内部或者台架上对功能进行模拟，并且通过改变输入，观察输出是不是和我们预设的一样。 4）优化过程：针对虚拟仿真测试的结果优化被测对象的设计与实现，并通过真实测试来验证仿真系统的有效性，获得更多数据优化仿真模型，实现仿真模型与被测对象的共同进化。具体到智能驾驶，就是把虚拟仿真中发现的没做好的算法或者逻辑，修改后进行反复的迭代和优化，最终达到我们满意的结果。 以上步骤，是我们通过虚拟仿真系统来进行开发的通用的流程，而完整的仿真系统还需要做到对仿真模型、案例数据、仿真过程，输入输出接口的完善管理。 在自动驾驶虚拟仿真测试中，根据真实子系统与虚拟子系统的不同划分，可以分为： MIL（模型在环仿真） SIL（软件在环仿真） HIL（硬件在环仿真） VIL（车辆在环仿真） DIL（驾驶员在环仿真） 分别代表了真实子系统为模型、软件、硬件、车辆、驾驶员的情况下的虚拟仿真业务闭环过程。 需要说明一下，如果是我们全部自研算法的智能驾驶系统，从 MIL、SIL 开始到 VIL 都是可以完成的，但是如果你使用的是 Mobileye 的 EyeQ 系列芯片，比较封闭，拿不到代码或者中间数据，我们就只能从硬件在环和车辆在环层面去仿真。 一般来说上述过程闭环所需要的仿真模型通常包括：传感器物理模型，车辆动力学模型，静态虚拟场景模型，天气气候模型，动态虚拟对象模型，动态交通流模型，车辆驾驶行为模型、突发事件模型等等。 这些模型的建模与运算需要非常专业的背景知识技能以及数据积累，并且需要专业的厂商提供的相应的仿真引擎来实现。 例如：车辆动力学建模需要专业的车辆动力学引擎并且需要车厂提供详细的车辆参数，传感器物理建模需要传感器厂商提供电磁学模型，交通流与驾驶行为建模也需要专门的交通流仿真引擎以及更加真实详尽的数据来驱动。 而其中最难的还是如何构建这样的一个虚拟的世界，一方面需要像游戏公司一样进行 3D 模型设计。 虚拟世界中的物体对象，另一方面，需要类似底层的游戏引擎厂商甚至英伟达这样的硬件厂商提供类似于粒子引擎、RTX 实时光线追踪引擎等等底层渲染技术，才能够比较完美的构建一个视觉渲染像更真实，电磁信号反射特性与强度符合真实物理原则的虚拟世界。 目前业内主要通过虚拟游戏引擎来实现上述的功能，最常用的有UnrealEngine4和Unity3D，包括高逼真渲染、模型动作渲染、物理碰撞模拟、天气模拟等等功能，都能够通过这些游戏引擎直接来实现，开发人员可以更多的集中在场景实现与业务逻辑上，提高了开发的效率。 在上述的技术基础上，自动驾驶的虚拟仿真技术才可能通过对采样位置与采样模式的不同设置实现对摄像头、毫米波雷达，激光雷达等传感器输入信号的精确建模，让虚拟仿真系统具备可用行。 至于更进一步的交通流建模，驾驶行为建模，突发事件建模，则更加涉及到复杂系统交互、人类情感波动等等多种因素的影响，已经无法精确建模。 对此我们可以基于实际测试数据，以基本规则加上一定随机化的方式来模拟（例如 Waymo 的模糊化技术，见下图），以最大化测试更多的可能性。 或者直接通过对抗生成网络技术对真实数据的模式进行学习以生成更多接近真实的数据，用以穷尽所有的可能的边缘场景（当然目前看起来仍然遥遥无期）。 此外，虚拟仿真系统并不一定要完整的实现，而是需要根据具体的业务需求与测试目标来进行选择与应用。 例如，如果只测试控制算法，则仅仅需要车辆动力学仿真就可以了；只测试决策规划算法，则可以省略高逼真渲染的模型，仅仅使用事件模型，可以大大节约算力成本与事件成本，获得更好的效率。 由于建模毕竟是对真实世界的简化与抽象（越复杂的模型与真实世界的逼近程度越高，但是需要的算力与时间代价也越大），所以真实世界的数据与案例才是最具有价值的。 为了更好地优化模型以及训练算法，虚拟仿真建模必须支持从真实数据更新模型，优化模型，甚至要支持直接的数据的无损转换与重播，以弥补建模对信息的损失。 2、当前自动驾驶领域虚拟仿真工具以及应用场景 当前自动驾驶领域用到的仿真工具主要分成四类： 1）传统汽车仿真软件：包括CarSim、CarMaker、VTD、PreScan等，特点是与当前汽车 ASPICE 开发流程结合紧密，认证链比较完善，支持台架测试等等 HIL 测试验证，常用于功能验证与车辆动力学验证。 2）机器人开发工具软件：主要包括 ROS 的 Gazebo，特点是开源，功能比较全面，生态好，但是没有进行优化，渲染效果一般，运行效率较低，没有通过行业认证，无法用于功能安全认证。 3）基于游戏引擎虚拟世界仿真软件：包括基于 Unreal 的 Carla、Airsim、腾讯 TAD Sim、51world 的 51Sim 等等，以及基于 Unity 的 LGSVL、DeepDrive 等等。 特点是构建了完善的虚拟世界，渲染效果好，支持插件的方式实现动力学、交通流、场景回放等等联合仿真，能够实现全栈自动驾驶方案的闭环仿真，具有较大的发展潜力。 4）交通流仿真软件：包括 VISSIM 与 SUMO 等等，主要用于决策算法开发，不支持全栈自动驾驶算法仿真测试。 由于各个仿真软件都有其各自的应用场景，这里不再详细说明。 3、未来自动驾驶需要什么样的虚拟仿真系统 由上面的分析我们可以总结一下，未来的自动驾驶需要的虚拟仿真系统需要具备以下的特点： 1. 能够构建完整的虚拟世界，能够整合多种仿真模型，并且支持高逼真的渲染，以实现全栈自动驾驶算法的仿真能力，支持真实与虚幻的场景融合。 例如，百度 Apollo 团队的论文中曾经提到基于 AR/MR 技术，在真实场景的数据中增加虚拟的交通参与者模型的渲染结果，以增加仿真场景的真实程度，这是一个值得探索的方向。 2. 支持场景数据直接转换为事件模型与交通流模型的建模案例，并且通过参数调整能够进行泛化，以实现更多边缘场景的覆盖。 3. 支持开放标准的输入输出接口，包括传感器接口、控制接口、地图数据接口、场景数据接口等等，支持多种引擎的集成与联合仿真，以实现与全栈自动驾驶方案的各个层级的算法与模块的测试。 4. 支持完整的功能安全认证链条，具备 ASPICE 开发流程的测试验证能力与资质，以便能够在实际量产开发中真正用到虚拟仿真技术节约开发成本。 5. 与客户开发的自动驾驶算法方案进行深入整合，简化系统应用难度，加快开发进度。 这就需要虚拟仿真平台拥有较好的生态，具备常用的开发框架的接口，包括 ROS、AutoSAR AP/CP，Apollo 的 Cyber 等等。 6. 具备完好的数据管理功能，辅助分析功能，具备并发仿真的性能，以及友好方便的操作界面与人机交互设计，能够为汽车产品全生命周期的开发人员提供一个全栈式的虚拟仿真测试验证解决方案。 预告：应读者群里的提问，我们将讲讲不同级别智能驾驶系统的传感器方案和相应的传感器融合的算法。

2. 

   19 Jun 2020

   016 | 软件定义汽车的核心是什么？谈谈特斯拉新一代电子电气架构

   编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，内容独家授权汽车之心发布。 郭继舜带你读汽车科技No.16 00:0011:32 今天来聊聊新一代电子电器架构，就是我们常说的 EEA3.0。 其实，最开始想到要谈电子电气架构，我是比较抗拒的，因为这是一个非常庞大而复杂的系统，其中涉及到的电子元器件至少数百起步，而且跨越了底盘、动力、车身、座舱、智驾等等多个系统领域，需要在汽车领域浸营多年的资深工程师才有可能窥得全貌。 而我仅仅对汽车领域新兴的智能驾驶有些了解，特别担心班门弄斧、贻笑大方 。 这次也只能够从智能驾驶的角度来对整车电子电气架构的演化过程与发展趋势尝试着做一个理解，还请各位专家多多指正。 我们先来回顾一篇旧闻： 2018 年美国《消费者报告》杂志指出，Model 3 在高速行驶状态下紧急刹车方面存在严重问题。具体来说，当 Model 3 在以 60 英里/小时（约 96.6 公里/小时）的时速行驶时，其制动距离约为 46.3 米，明显高于同级别的其他车型。 随后，Model 3 远程推送固件升级，让紧急刹车距离缩短了大约 6.1 米。 对此，《消费者报告》的汽车测试部门总监 Jake Fisher 不无震惊地说：「我在这岗位工作了 19 年，测试了上千款车型，第一次见识到有车能通过无线升级来大幅改善性能表现的。」 这篇报道中 Model 3 所体现出来能力的就是「软件定义汽车」的能力，而这个能力得以施展的基础就是特斯拉先进的电子电气架构设计。 首先，Model 3 的制动系统采用的是（博世）ibooster 制动机构，其电控软件是特斯拉自己开发的，可以通过 OTA 升级，实现对刹车踏板特性的调节。 这次升级就是通过调整刹车响应曲线来实现整个刹车过程中的制动力最优化的分配，从而减少刹车距离的。 上面的过程说起来很简单，但是却是目前大多数车厂完全无法实现的，其原因就是现有车辆的电子电气架构还是传统的分布式电子电气架构。 我们从下面这张著名的博世电子电气架构演化图可以看出： 当前大多数的汽车还处在从分布式的 Modular 阶段向初步集成的 Integration 阶段升级的过程中，少数先进的 OEM 则在新兴的比如智能座舱、智能驾驶等等需求的驱动下，开始了分功能域的 Centralization 阶段的尝试。 比如广汽、上汽、小鹏等等，而特斯拉则已经实现了基于区域融合的多个功能域控制器融合的 Fusion 阶段，甚至有进一步整合成为 Vehicle Computer（FSD）的趋势。 这样领先的电子电气架构设计，才能够让 OTA 升级功能渗透到刹车控制器上，实现对最底层执行件软件深度优化。 一方面，这需要整车上的 TBox 网关具备高速安全的外网连接能力与数据传输能力。 另一方面，也需要车辆内部具备高速可靠的总线连接，让网关下载的内容能够下发到最底层的执行件电子单元上面。 最后，还需要 OEM 具备强大软件开发能力，能够开发最底层执行件的控制软件，才能够真正实现用软件来定义汽车功能或者性能。 除了博世提出的上述软件架构演化路径以外，其他的先进 OEM 与 Tier1 也提出了各自对于新的电子电气架构的设计思路。 例如宝马就提出了一个基于分层的架构设计理念： 从底向上分别从传感器、执行件层，到标准通用的 ECU 层，再到功能集成的域控制器层，最后到集中式的中央计算平台层。 这是一个基于车内高速通信服务的功能逐步抽象聚类的设计思路，和博世的设计具有异曲同工之处。 本着第一性原理，我们可以来分析一下，驱动电子电器架构进化的要素究竟是什么，从而对于未来电子电器架构进化的形态做一个初步的预测。 首先，是智能化的需求。 早期的汽车主要用机械结构来满足最基本的驾驶需求，以一种机械唯物主义方法论来设计的车辆，所以后续产生的电子系统都以一种辅助机械功能执行的模式来设计实现的，彼此之间通过低速的 CAN、Lin 等等总线以进行简单的信息同步与交互。 而随着智能化时代的到来，未来的汽车对于智能座舱、智能驾驶、智能云服务、智能能源管理等等智能化需求越来越强烈，对算力的要求大大提高。 而个性化与情感化的需求又让车辆的功能迭代更加快速，因此要求新的电子电器架构能够提供更加高性能的运算能力，更加灵活的软件功能，更加快速的内部通信能力，从而催生了算力集中、软硬件分离、负载均衡、高速通信的新一代电子电器架构的演化趋势。 以特斯拉为例，在开发了对应的应用软件并释放的用户群体以后，以类似于互联网领域软件开发方式，通过用户使用应用软件中收集到的真实反馈与真实道路数据，不断优化其应用软件。 虽然在一开始可能会出现一些由于系统不完善而引发的安全事故，但是随着其应用软件不断升级与迭代，目前特斯拉在智能驾驶的开发中越来越成熟，并且可以以满足用户的需求为目标，不断地提供新的智能驾驶使用场景给到用户。 其中包括去年的智能召唤，以及今年预计会推出的反向智能召唤等。 其次，是开放互联的需求。 现在的车辆已经从一个独立的复杂机械变成了社会化信息网络中的一个节点，通过车路协同、车云协同等等互联模式，让车辆具备了与外部网络高速互联的能力。 这一方面对车辆电子电器架构的开放接口提出了标准化、高速度、可靠性、可扩展的要求，另一方面也对车辆的信息安全能力提出了更高的要求，这些在未来的电子电器架构设计中都是需要考虑的。 第三，是系统安全的需求。 由于智能驾驶、智能座舱、智能网联等等功能的实现，汽车的安全将更多的由车辆来主要负责。 为了保证车辆系统能够提供绝对的安全的服务，在电子电器架构设计中也要考虑更多的冗余备份，更高的关键零部件可靠性设计，更多的系统预期功能安全的设计。 以这样的开发思路，特斯拉 CEO 马斯克除了在汽车领域以外，在航天航空领域亦是如此。 近期 Space X 发送的运载火箭，通过用 3 个工业级的英特尔 X86 双核处理器做冗余，以不断同步 6 个核中数据的形式来保持数据同步，再加上基于 Linux 写的操作系统和 C++代码，取代了宇宙级的元器件，降低了运载火箭的发送成本。 可以说，这是通过更加先进的系统设计理念，使用工业级零部件完成航天级复杂系统的典范。 最后，是节能降本的需求。 由于车辆电子器件数量越来越多，布线越来越复杂，功耗越来越大，在设计新一代的电子电器架构的时候，就必然要考虑到相似功能的电子电器部件集中整合。 基于空间优化的器件接入与电源接入的区域控制器设计，更高算力能耗比的芯片的应用等等设计方案，从而实现减少器件数量，减少总线长度，基于功能与空间布局的控制器整合等等需求。 类似于特斯拉 Model 3，其整个电子电气架构主要由三大部分组成：中央计算模块（CCM）、左车身控制模块（BCM LH）、右车身控制模块（BCM RH）。 中央计算模块主要负责信息娱乐系统、驾驶辅助系统和车内外通信连接，左车身控制模块和右车身控制模块分别负责了车身便利性系统，底盘安全系统和动力系统的功能。 一方面可以更好地支撑更高级别的智能驾驶对算力的需求，另一方面极度简化了功能开发与集成部署的难度，同时也更有利于 OTA 的应用软件升级。 随着电子电气架构从分布式架构到域控制式架构，再到集中计算式架构的发展，车上的 ECU 控制器数量也在逐渐递减，同时减少了 ECU 控制器及其周边件的线束。 如特斯拉从 Model S 一共有 3000 米的线束到 Model 3 只剩下 1500 米，而今年年中计划推出的 Model Y 中预计线束只有 100 米。 在降低了车辆成本的同时，也对车辆的轻量化目标做出了贡献，OTA 过程中受到来自电子电器架构的限制也越来越少。 我们以特斯拉为例，主要是特斯拉确实有很多新的技术尝试和量产实践值得我们学习和思考。 如何将智能驾驶带来的安全、舒适与便利快速带给生活中的我们，如何能保障用户手中的智驾系统是时时刻刻让用户满意的，如何从零部件级的功能安全到系统级的功能安全做一个平衡，这些，都是需要我们长期思考的问题。 就我所知，中国的头部 OEM 都在积极开发下一代的电子电器架构，并且在 2022 年左右实现新一代电子电器架构的平台化，这使得国产品牌在功能持续迭代升级、新功能使用、实车数据维护、售后质量问题快速解决上都会有更大的优势。 另外一方面，也会让智能驾驶系统的测试和量产搭载变得更从容。 因为在整车的开发流程中，智能驾驶功能必须要等到底盘性能完全冻结才能开始进行标定、调教和测试，所以智能驾驶基本上是整车所有功能中最后冻结的。 一旦前面的某些开发出现了延期，在量产前最着急最痛苦的就是智能驾驶工程师，因为压缩的基本都是智能驾驶的性能提升和测试时间。 以后有时间我给大家讲讲整车开发流程，题目就叫：最痛苦的智能驾驶工程师。 我今天看到新闻，小鹏 P7 的智能驾驶功能延期交付，等测试验证充分了，通过 OTA 升级的方式交付给车主。这还真不是这些智能驾驶工程师不努力，我估计是给他们的测试验证时间太少了。 好在，还有 OTA 升级，这也是新一代电子电器架构的功劳。 往期回顾： Mobileye炫技，仅凭12摄像头穿越闹市区，一辆优秀的L4无人车该是怎样的 完成一套智能驾驶系统本土化需要多久？ 特斯拉撞上了侧翻的大货车，从台湾嘉义事故谈传感器融合 智能汽车的中国芯：华为MDC首发测评 字节跳动入局车联网，互联网应用上车要解决哪些难点？ 为什么欧美车企纷纷放弃L3，而中国车企热衷量产L3？ 传统车企为什么造不出Autopilot，特斯拉L4战略存在什么风险？ 本期制作 主讲：郭继舜 监制：王德芙 编辑：叶方 后期：陆非 设计：陈溪阳 运营：林芝芝 独家音频平台：喜马拉雅 在喜马拉雅搜索关注汽车之心 即可收听往期节目

3. 

   16 Jun 2020

   015 | 5G V2X将带来怎样的交通大变革？

   编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，内容独家授权汽车之心发布。 今天我们聊聊基于 5G-V2X 的路端建设。 我们讲过一期 5G 车路协同的解读（《为什么实现车路协同比造一辆特斯拉还难？》），后来读者群里（P.S.添加微信号 autobit101 加入读者群）有小伙伴留言想要了解基于 5G 通信的车联网场景技术落地的相关内容。 今天的音频向大家分享下我个人在这方面的理解。 因为 5G 和车路协同现阶段都是热门技术，发展很快，相关技术标准还没有成熟，我们现阶段也暂时是基于 5G 民用通讯网络的实验网进行相关的车载测试，如果有部分信息不够专业和准确，还请大家多多指正。 基于 5G 的车联网场景主要可概括为两大类：网联和智驾。 网联场景可以概述为以人为中心的车载互联系统，即依托 5G 网络，车辆将集成智能家居、语音识别、人脸识别、互联娱乐、网上购物等功能，使车辆成为家和办公室以外的第三空间。 网联场景的实现主要依赖于 T-BOX，在未来一到两年的时间里，可逐步用 5G T-BOX 替代现有的 4G T-BOX 来实现应用落地。 今年下半年 5G T-BOX 产品将陆续量产，今明两年，国内外主要 OEM 都计划推出 5G 的网联车辆，相信很快 5G T-BOX 将成为新车标配。 随着 5G 相关技术的提升，AR/VR、4K 视频等技术的逐步引入，网联场景也将逐步得到更加丰富的展现。 5G 车联网在网联场景的应用属于性能的提升，并不是大的功能的变化，落地应用路线明确，也相对简单。然后，咱们重点聊聊 5G 车联网在智驾场景的落地应用。 智驾场景可以概述为以车为中心的智能驾驶系统，即依托 5G 车联网，将单车智能升级为车路协同的多车智能。 我们在之前的音频中已经简单介绍过，车联网主要包括 V2V、V2I、V2N 以及 V2P 等四类。 V2V 方案的实现主要依赖于车载通讯设备，如 OBU、V-BOX 等产品。 由于 5G NR V2X 的相关标准 R16 尚未发布，适用于 5G 的 OBU/V-BOX 等车规级产品还没有量产。 R16 标准按计划今年发布，标准发布半年后，相关芯片、模组及终端产品将会陆续量产，预计明年下半年将开始车端的量产搭载。 V2P 方案的实现依赖于人们携带的移动穿戴设备，但也可通过 V2I 的方案间接实现。 我听到的一个好消息是，华为计划在下一代的手机用麒麟芯片中加入 V2P 模块，如果我们使用华为手机，就可以选择将自己的地理位置信息去隐私化后上传到云端，实时提醒我们周边的车辆注意行人。 这将很好地避免夜间或者处在视觉盲区的车辆对我们造成人身伤害。 V2I 和 V2N 方案是实现车路协同的核心，也是车联网基础设施的主体。 其中「I」为 Infrastructure，指路侧基础设施，包括通讯设备、感知设备、计算设备等； 「N」为 Network，指车联网云平台，包括边缘云、核心云等。车路协同主要涉及三个端口：车端、路端和云端，车端主要依赖 OBU/V-BOX。 下面我将重点分析路端和云端的建设。 路端设备主要包括： 1）路侧通讯设备，也就是 RSU，主要实现 V2I 通讯，将结构化的路侧数据通过无线通讯方式广播出来； 2）感知设备，包括摄像头、毫米波雷达、激光雷达等，主要用于道路环境的检测，包括道路信息、车辆、行人等，多传感器的融合可以弥补各自的感知缺陷； 3）路侧计算单元，如华为的边缘小站等产品，主要用于感知数据处理、融合等，将原始数据处理为标准的结构化数据； 4）辅助设备，如交换机、供电设施等。 云端的设备主要包括服务器、显示器及其辅助设备等，除了这些硬件，云端更重要的是软件，包括基础软件和应用层软件。 基础软件主要指云平台的底层操作系统、环境配置等，比较容易实现。 应用层软件包括数据管理系统，如数据接入、协议解析、数据分析、数据存储等；高精度地图等基础数据；设备及车辆监控系统；测试分析与仿真系统；车联网应用服务软件；大数据应用及算法训练；信息安全服务系统还有设备管理系统等。 因为 C-V2X 的车路协同技术是一个比较新兴的技术，而且欧美之前的 DSRC 车端通讯网络协议相较于我们国家现在倡导推行的 C-V2X 技术先进性差距较大，参考性并不强，所以针对车路协同云端的应用层软件需求缺口很大。 因为承担了广州智能网联先导示范区的建设和频段运营的工作，我们沟通了挺多的 SaaS（软件即服务）的合作伙伴，暂时还拿不出系统级的完善的解决方案。 所以，在新基础设施建设快速发展的大背景下，车路协同的云端应用层软件，以及系统整体的软件、数据整合，都是大有可为的技术领域。 除此之外，路端和云端等建设还需要 4G/5G 基站及光纤网络作为通讯纽带，以及智慧灯杆等作为安装载体，同时也涉及交通设施、电网设施的改造。 以 5G 车联网示范区建设为例，我介绍下 5G 车联网的应用落地，可主要概括为以下几个建设步骤： 第一步： 道路选择及道路类型分析。 综合示范区的路网规划、道路综合安全指数、交通流量、人口密度、服务设施（医院、学校等）等，选择车路协同建设的道路，该环节可联合相关政府部门，如省/市交通勘察设计院来完成； 然后对所选道路进行道路类型分析和统计，道路类型可初步划分为信号灯十字路口、信号灯 T 型路口、无信号的十字路口、无信号的 T 型路口、环岛、掉头、桥梁、直路等，并对数量和长度进行统计。 第二步：确定道路建设等级。 欧洲根据基础设施对自动驾驶的支持，将基础设施划分为 A~E 5 个等级。 国内业内也尝试将车联网划分为网联辅助信息交互、网联协同感知、网联协同决策与控制三个等级，与欧洲形式有所不同，但内涵一致。 以不同阶段的网联化建设为目标，根据道路覆盖度和路侧设备配置，将道路车联网建设等级划分为：顶配、高配、中配、低配。 如低配可以只考虑有信号灯的路口，路侧设备主要是 RSU 和摄像头等；顶配、高配则实现全路段道路覆盖，路侧设备也将面向 5G RSU 以及摄像头、毫米波雷达、激光雷达等多传感器配置。 第三步：方案设计。 根据道路类型和建设等级，设计车联网建设方案。 路口、环岛等特殊道路优先部署，普通直路可 200 米/套进行部署。 十字交叉路口可以部署 1 个 RSU、4 个枪机摄像头、4 个球机摄像头、4 个毫米波雷达、2 个激光雷达、1 个路侧计算单元等。 这样可以基本实现交叉路口的无盲区多感知融合探测，其它路口可根据十字路口方案进行删减。 直路包括 2 个枪机摄像头、1 个球机摄像头、2 个窄角毫米波雷达、1 个广角毫米波雷达、1 个路侧计算单元，其中，2 个枪机摄像头和 2 个窄角毫米波雷达一前一后部署，分别检测来向和去向车辆，相邻站点可共用一个 RSU，400 米/个。 设备数量可根据道路宽度增加。 感知设备通过网线与路侧计算单元相连，如果是多路设备，就需在中间增加交换机；RSU 也通过网线与路侧计算单元相连。 感知设备进行实时数据采集，传感器数据经网线传递给路侧计算单元进行数据处理、融合，并将融合后的结构化数据输出到 RSU 对外广播。 其中，多个感知设备可以共用一个路侧计算单元，相邻感知设备、路侧计算单元可共用一个 RSU。 云平台的建设可采用边缘云+核心云的方案，例如广州市车联网的建设，可以部署一个核心云和若干边缘云。 边缘云可大可小，按区域部署，实现局部数据的快速处理和分发。 一般来说，每 15-25 个路口共用一个边缘云平台。云端和路端设备之间通过光纤相连。 第四步：路侧设备选型。 RSU 应注重通讯距离、互联互通、可靠性等关键指标；感知设备应注重有效探测距离、精度、FOV、可靠性等关键技术指标；路侧计算单元应考虑软件可升级性能，支持 OTA。 路侧设备应根据场景应用需求进行选型，在满足性能要求的前提下再考虑已有设备的复用。否则会出现有些示范区设备利用率低，运维费用高等问题。 这一点，我举个例子，我看到有些建设方案，倡导充分利用现有的交通摄像头，但我在设计具体的技术方案中发现，由于现阶段已有的交通摄像头部署年限差距比较大、种类多、精度不一，需要设计复杂的图像处理算法来达到多摄像头数据拼接共用，技术实现上很麻烦，我个人觉得有点儿得不偿失。 第五步：施工方案协同设计及协同建设。 由政府部门协助，结合路网规划、现有交通/网络设施，与基站、智慧灯杆等协同设计，制定施工方案。 车联网系统是集路侧设施、云平台、4G/5G 网络、智慧灯杆、交通设施等一体的系统，所以要协同设计、协同建设。 以上，我相对系统地介绍了车路协同中路端设备的建设方法步骤，希望提出这个话题的读者群中的小伙伴满意。 因为时间和篇幅的限制，不能讲得太详细，欢迎微信或者电话和我联系，我们多多交流。 前几期的音频中，我们也提到车联网的基础设施建设需要投入大量的人力、物力和社会资源，是一个长期的建设过程，是个从点到面的扩展过程，也是一个从 4G 到 5G 的升级过程。 在这场由政府主导的交通大变革中，我坚定地认为：路端设施的改造增强，能够解决智能驾驶单车智能中很多天然的技术缺陷，智能驾驶技术将在 5G C-V2X 的加持下，最终实现人类出行零伤亡的终极目标。 往期回顾： Mobileye炫技，仅凭12摄像头穿越闹市区，一辆优秀的L4无人车该是怎样的 特斯拉撞上了侧翻的大货车，从台湾嘉义事故谈传感器融合 智能汽车的中国芯：华为MDC首发测评 字节跳动入局车联网，互联网应用上车要解决哪些难点？ 为什么欧美车企纷纷放弃L3，而中国车企热衷量产L3？ 本期制作 主讲：郭继舜 监制：王德芙 编辑：叶方 后期：陆非 设计：陈溪阳 运营：林芝芝 音频平台 喜马拉雅 | 蜻蜓 FM | 听伴 Podcasts | 小鹅通 在以上平台搜索关注汽车之心 即可收听全部节目

4. 

   11 Jun 2020

   014 | 滴滴杀入自动驾驶有哪些优势？未来的Robotaxi需要什么样的平台车？

   编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，内容独家授权汽车之心发布。 今天，我们聊聊滴滴的自动驾驶公司，顺便讲讲 L4 自动驾驶平台车的技术。 根据《晚点 LatePost》独家消息，滴滴旗下自动驾驶公司获得软银愿景基金（Vision Fund）二期领投的 5 亿美元融资。 这是滴滴自动驾驶业务独立拆分后的首轮融资，也是国内自动驾驶公司获得的单笔最大融资。 大家都知道，愿景基金一期的 1030 亿美元，因为投资了 Uber、滴滴、ARM 等著名科技公司名声大噪，但也因为投资 WeWork 等共享经济公司运营不利、上市失败而血亏。 愿景基金二期有 1080 亿美元的投资规模，但据了解，其中有将近 400 亿美元是软银集团出资，可以说，第二期孙正义投的是自己公司的真金白银。 以如此高的效率投资滴滴的自动驾驶公司，足见孙正义对这家公司及其商业模式的看好。 其实在此之前，因为工作和技术的交流，我们接触滴滴的自动驾驶团队有一年多时间了。 在这段时间里，关于滴滴 L4 自动驾驶的新闻很少，但是能清楚地感受到他们默默地飞速地积累技术能力和团队的厚度。 就我所知，滴滴自动驾驶公司马上还有更大的好消息，大家拭目以待。 今天的一开始，我们先要聊聊 L4 自动驾驶的商业模式。也许这是各位非常了解的内容了，但为了保持音频逻辑的连续性，还是允许我简要介绍一下。 之前我们提到过，L0-L3 智能驾驶的功能大都限制在高速公路上，到了 L4 以上，扩展到了城市道路，而且不需要人类驾驶员坐在驾驶位接管车辆了。 我们把 L4 做这样的总结： 1. 因为城市道路的交通环境非常复杂，自动驾驶汽车上需要安装高线数激光雷达，32 线保底，一般是 40 线、64 线甚至 128 线，十多个摄像头对车周身 360 度视角全覆盖等才能够满足感知的要求，同时对硬件系统的算力需求也很大，一般在 80-100Tops。 所以车辆的硬件成本飙升，现阶段改装一台 L4 自动驾驶汽车的成本在 10 万到 12 万美元左右，再加上车辆本身的成本，所以 L4 的单车成本还是很高的； 2. 车内不需要驾驶员了，车辆有足够的智能将乘客安全地从 A 点送到 B 点，正常情况下，全程不需要人类接管； 3. 配合城市道路的高精度地图，加上新能源汽车相对密集的充电站，基本可以实现 24 小时免人工保养。 综合以上特点：昂贵，绝大多数情况不需要人驾驶，全自动保养。人们就想出了一种全新的商业模式——Robotaxi，即自动驾驶出租车。 L4 之前的乘用车主要是卖给个人用户的，在大多数场景人开，少数高速场景车辆自己开，从而一定程度减缓人们的驾驶疲劳感。 但据统计，我们购买的个人汽车，每天有 90% 的时间是停在停车场的，只有 10% 的时间是行驶在路上。 L4 自动驾驶汽车，由于初期硬件成本较贵，个人用户购买的热情可能不高，更有可能是由滴滴这样的 B 方购买，通过高度自动化的自动驾驶出租车运营，快速赚钱收回高昂的硬件成本。 所以，L4 以上智能驾驶汽车的商业模式出现了转变，从把车辆卖给个人消费者变成共享化运营。 这样的商业化模式，能赚到钱吗？市场前景还是很可观的。 我从滴滴了解到，现阶段咱们打滴滴付出的费用中，有至少 60% 是直接付给了司机的，另外还有 5%-10% 是通过奖励或者红包方式补贴司机的。 这就意味着，我们的打车出行费用中，70% 左右是即时支付的人工成本，如果实现了无人驾驶出租车，我们打车的成本至少能下降 50%。 所以，以 Waymo 为代表的科技公司，把自动驾驶出租车作为商业化理想落地的载体。 那么，到底什么样的自动驾驶公司能在这场科技竞赛中获得巨大优势呢？ 我再给大家讲另一个概念：冷启动成本。 试想，在未来，如果你掌握了仅需要云端平台调度，完全不需要人工保养的高智能自动驾驶出租车技术，准备开一个 Robotaxi 公司。 你会面临一个棘手的问题，就是即使你只在中国一个城市里开展业务，为了能够让用户使用你的 APP 随时能打到车，你必须要保持你的 Robotaxi 在这个城市里的密度，就是不管任何时候用户拿出手机打车，最好都能在三分钟之内打到车，再过 3、5 分钟坐上车。 如果我们以北上广深这样的一线城市为例，为了保证你的自动驾驶出租车服务有可用性，用户不会因为你的平台车辆密度太低打不到车而一怒之下卸载 APP 相当长一段时间不会再用，你至少需要 2000-3000 台规模的车队。 按照现在的改装成本算，单个城市满足最低运营需求也要 30-45 亿元人民币的成本。 可以说，现阶段的硬件成本来说，Robotaxi 这样的商业模式天然就有很高的冷启动成本。 但，像滴滴、Uber、Left 这样的共享出行公司就不太一样，他们天然有一个庞大的由人类司机驾驶的车辆群体。 经过多年的发展，他们已经在各个城市保持了足够的运营车辆密度，初步满足了打车用户的需求。 如果滴滴、Uber 等研发出成熟的可运营的自动驾驶出租车，在法律法规允许的前提下，去掉驾驶员，让车辆完全自动驾驶。 即使只有十辆二十辆，滴滴也可以非常容易地把这少数自动驾驶出租车接入到滴滴打车平台，让用户先使用起来，因为还有足够大量的人类驾驶员的汽车保证运营的密度，乘客使用打车服务的体验丝毫没有受到影响，当打到无人驾驶的出租车的时候，反倒会觉得惊喜。 在后续的运营中，滴滴只需要持续把无人出租车的比例不断提高，就能实现商业模式上持续的降本和智能化。 从这个角度，滴滴在做 Robotaxi 技术研发和商业模式实现的时候，有一个天然的优势，就是冷启动成本几乎为零。 我们在讲 Mobileye 的音频中提到过，L4 大规模运营的重要前提是自动驾驶汽车前装量产。 但是现阶段，由于关键零部件无法过车规，全冗余的底盘执行器件由于成本太高，也很难大规模应用。 所以，现在的 L4 自动驾驶汽车，还是由车厂提供量产车型，经过一定的改装和优化，成为自动驾驶平台车，再由滴滴、小马智行、文远知行这样的自动驾驶科技公司添加传感器、运算硬件和算法软件，最终完成一辆 L4 自动驾驶汽车的开发。 我们大家都熟悉的，很多科技公司在使用的林肯 MKZ，就是经过优化后，性能很不错的自动驾驶平台车。 得益于DataSpeed 在自动驾驶风起之初，眼光独到地选择了林肯 MKZ 这样一款具备优良线控执行功能的车型进行改装，为其开发了标准化的 ADAS Kit 编程接口套件，以及 AutonomouStuff 公司在后续的商业推广过程中的出色表现，配合福特公司高瞻远瞩的默许配合。 这种 OEM+后装改车模式的林肯 MKZ 自动驾驶线控平台车在自动驾驶浪潮来临的早期风靡自动驾驶领域，一度成为了自动驾驶线控平台车辆的事实标准。 其拥有原车量产线控执行接口，冗余制动且制动性能良好，并且提供了 EPS 转角接口，加上符合程序员思维的 ADAS Kit 开发接口，让许多初创公司能够快速地将算法实车搭载测试，获得融资，进入方案迭代升级的良性循环中。 但是，林肯 MKZ 这样的后装改造的线控平台车对于自动驾驶进入深水区的 2020 年来说，已经不再适合产业的发展。 主要原因有三点： 1. 后装改造，成本高企：原车售价加上接近原车价格的改车费用，让 Robotaxi 的规模化应用难上加难； 2. 后装改造，改装部分没有经过车规安全认证，产品的质量与稳定性无法保证； 3. 并不是专为自动驾驶设计的，改装无法弥补，或者代价巨大。 那么，怎样才算是一辆好的智能驾驶平台车呢？科技公司怎样选择才能让自己的自动驾驶算法发挥最大化的优势呢？ 综合与滴滴、华为、小马、文远、禾多、轻舟等行业伙伴交流的经验，我从实现技术角度分析了几个现阶段优秀自动驾驶平台车所需要达到的硬指标。 1. 具备冗余安全且性能卓越的线控执行系统。 除了转向冗余因为技术发展的限制，暂时没有量产产品。 优秀的平台车需要具备冗余驱动系统（电机+发动机或者双电机，驱动响应时间不大于 200ms），冗余制动系统（ESP + iBooster，制动响应时间不大于 250 毫秒），转向系统的响应时间不大于 200 毫秒，转向扭矩最大支持 5N 以上，以保证较小的转弯半径。 2. 开放易用的车辆控制接口设计。 通过线控网关设计，自动整合车辆内部各个执行件的响应模式，平抑执行器件性能参数波动，为外部提供统一且线性的车辆控制参数，以及开放易用的控制接口（提供 CAN DBC 矩阵协议或者基于协议开发的 SDK 等等，提供方向盘转角/转矩、加减速度/阀门开度等接口模式，适配 APOLLO、ROS 等等常见的开发平台），让平台车的客户不需要关心平台车内部具体的执行逻辑，方便易用，大大减少了开发的周期。 3. 提供高续航的供电。 自动驾驶的计算单元和传感器功率消耗较大，电源系统需要增加低压供电功率，智能驾驶将会新增工控机、传感器等负载，因此参考目前主流自动驾驶芯片功耗，需要 DCDC 额外提供 1000-2500W 输出功率，这对线控车辆的电池的容量、输出电压及电压纹波等指标都提出了更高的要求。 4. 良好的散热管理系统。 由于自动驾驶的 ECU 和传感器功率消耗较大，相对应的应按量产开发要求增加散热措施，从域控制器的放置位置到热量的回收利用等方面综合考量车辆的热量管理，形成一套与车辆电子系统有机结合的散热系统。 5. 具备自主开发的能力，能够提供持续而周到的技术支持服务，保证平台车升级支持的一致性。 通常这是由改车公司来提供的服务，但是优秀的平台车 OEM 也具备自主开发的技术实力，与改车公司一起提供更加优质的底层技术支持。 可以说优秀的自动驾驶平台车，是车厂为了 L4 高级别自动驾驶发展，专门优化改造，送给行业的一个礼物，能够很大程度地推动智能驾驶技术的发展和大规模商业化落地。 预告：下一期，我们来讲在《郭继舜带你读汽车科技》读者群里提出的话题：V2X 车路协同的路端建设在技术上到底怎么实现的。敬请期待。 往期回顾： Mobileye炫技，仅凭12摄像头穿越闹市区，一辆优秀的L4无人车该是怎样的 完成一套智能驾驶系统本土化需要多久？ 特斯拉撞上了侧翻的大货车，从台湾嘉义事故谈传感器融合 智能汽车的中国芯：华为MDC首发测评 字节跳动入局车联网，互联网应用上车要解决哪些难点？ 为什么欧美车企纷纷放弃L3，而中国车企热衷量产L3？ 传统车企为什么造不出Autopilot，特斯拉L4战略存在什么风险？ 本期制作 主讲：郭继舜 监制：王德芙 编辑：叶方 后期：陆非 设计：陈溪阳 运营：林芝芝 音频平台 喜马拉雅 | 蜻蜓 FM | 听伴 Podcasts | 小鹅通 在以上平台搜索关注汽车之心 即可收听全部节目

5. 

   10 Jun 2020

   013 | Mobileye炫技，仅凭12摄像头穿越闹市区，一辆优秀的L4无人车该是怎样的

   我把这次试乘的感受试着向大家总结一下： 1. 路感异常平顺，加速减速都很稳健，红绿灯路口没有出现急刹，启停颇有点老司机的意思； 2. 在展现识别算法高层语义信息的显示屏上，我看到，所有的车辆和行人，不光做了识别分类，给出了 3D 的 Bounding Box，还预测了每辆汽车和行人的路径； 3. 我们路试的时间是下午 4、5 点，阳光的斜射已经非常明显了，可能是多个角度的摄像头的原因，感觉阳光斜射对自动驾驶的影响不大； 4. 全程大概 30 分钟的时间，绕着耶路撒冷城区转了一圈，遇到非常多异常工况，但没有一次接管，而且在一个进入下穿隧道的场景，车辆还猛然加速，感觉很像是一个对道路非常熟悉的老朋友开车载你去机场赶飞机。安全员告诉我，这一段是故意设定的，就是为了显示一下 Mobileye 的技术能力。 坐在快速行驶的自动驾驶汽车上，看着路边拿着圣经，带着黑色礼帽赶去哭墙朝圣的行人，前沿的科技和古老的圣城，在夕阳下的金色庙宇，那种感觉真的很奇妙。

6. 

   8 Jun 2020

   012 | 特斯拉在华组Autopilot开发团队，完成一套智能驾驶系统本土化需要多久？

   编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，内容独家授权汽车之心发布。 最近身边的不少朋友在讨论，特斯拉在中国准备招聘研发人才和软件人才，这其中智能驾驶团队是非常重要的招聘目标。 今天我们就着特斯拉招聘中国本土技术团队的事情，来聊聊智能网联技术的本土化。 我先简要把这个新闻的内容向大家介绍一下，在 5 月 26 日央视新闻的校园招聘直播活动上，特斯拉对外事务副总裁陶琳表示： 包括 Autopilot（自动辅助驾驶系统）团队在内，特斯拉需要很多本土化研发和软件人才，研发更多贴近中国本土消费者需要的功能，以及车上的应用。 特斯拉中国可能会增加其自动驾驶研发人数，为中国市场单独成立一组自动驾驶团队，来满足中国的道路场景、法规政策要求。 今年年初，特斯拉上海的超级工厂正式投产，仅仅半年左右，特斯拉中国区又推出新战略，招聘本土化研发团队，真的是有全面开拓中国市场的架势。 我向一位在特斯拉负责招聘的朋友了解了更加确切的情况： 特斯拉确实是计划壮大中国本土的技术团队，一开始团队规模小幅扩张，主要是应对智能驾驶、车联网等技术的本土化工作，后续不排除把更多的研发工作交给中国技术团队的可能性，特斯拉的中国技术团队在未来很可能成为特斯拉技术突破的新引擎。 回到我们今天讨论的智能网联技术本土化问题。 每个不同的国家和地区，语言文字，法律法规，文化习俗不同，导致用车习惯、人机交互界面、智能驾驶系统有非常大的不同，汽车技术的本土化是我们在扩展国际化市场必然要面对的问题。 以往本土化的常规操作，包括更换前后保（前后保险杠）造型、加长轴距、两厢改三厢等等，特别是欧美 OEM 为了符合中国市场的审美倾向，往往会专门推出轴距加长版，奥迪 A4L、A8L、凯迪拉克 ATS-L 等。 在性能优化上，比如应对俄罗斯市场对于低附着路面的底盘性能优化车型，应对中东市场砂石路面的高强度版等。 随着智能网联技术的搭载量产，车载娱乐和智能驾驶成为本土化工作量的大头。 一方面，新闻中的特斯拉，还有奥迪、宝马等国际 OEM 都在开发面向中国的本土化车型；另一方面，自主品牌也积极拓展海外市场。 在我个人的研发经历里，我觉得东南亚、非洲、俄罗斯甚至是欧洲的本土化适配都还好，但是设计研发美规的车，真的是异常痛苦。 可能是为了保护美国本土汽车业的发展，美规车辆的要求比较独特和严格，对于胎压监测、防抱死系统、车身稳定系统等安全配置强制性要求安装都算是简单的（还有比这更难的）。 我举个例子大家就明白了。 我们曾经为了设计完全符合美规的油箱，在国内寻找过十几家供应商也没有找到可以适配的，最后还是选了一家美国供应商。所以看看美国满大街跑的思域、普锐斯，丰田本田的研发体系真的是值得我们国内车企好好学习的。 我们先讲讲车载娱乐系统的本土化有哪些工作要做，其实 AVN 或者 AVNT 的硬件基本上是可以迁移使用的，但是软件系统的改动量就比较大了。 总结有一下三点： 1. 语言文字的翻译工作； 2. 车载系统所使用的 APP、导航地图数据等需要根据不同国家做适配； 3. 一些文化习惯的系统性适配。 第三点我还是专门说一下，比如有些阿拉伯国家，车机的操作交互习惯和我们稍有不同，这个因为牵涉到修改系统底层的交互逻辑，工作量比较大，一般第三点各个出海 OEM 改动得不太多。 重点讲讲智能驾驶，接下来我们从自动驾驶的感知、决策、控制三大系统入手，分析下三大系统本土化分别需要做些什么工作。 因为时间关系，我们这次先讲如何把国外智能驾驶技术在中国做本土化迁移。 在感知方面，相比于欧美道路，中国的道路构成复杂、交通设施特殊、交通参与者的复杂行为决定了中国的道路场景特殊性。 我记得今年年初看过一个文远知行的技术报告，他们统计 L4 级别智能驾驶开发过程中，中国开发团队收集交通场景的效率是美国团队的 6 倍左右，足以见得中国的路况复杂程度。 另外的一个例子，是小马智行刚刚把总部搬到广州南沙的时候，楼教主跟我说，在加州跑得非常欢畅的自动驾驶系统，刚到国内的时候完全不能应对如此复杂的场景，车辆会愣在十字路口。 当然，三年过去了，现在 Pony.ai 应对复杂场景已经非常专业顺畅了。 在量产层面，我要吐槽一下 Mobileye EyeQ3 等芯片的算法是在欧美和以色列的数据库上训练的，对一些富有中国特色的场景的识别有不小的问题。 比如：我国南方的丘陵地区经常会出现的鱼骨线，我在文稿中加了鱼骨线的照片，这个交通标志的意思是道路复杂，请驾驶员保持注意力。 但在智能驾驶开发中，一遇到鱼骨线，EyeQ3 的车道线识别算法拟合出的车道线就飘来飘去极不稳定，造成一系列功能的不稳定。 另外，我们很多高速桥的限重标志，比如 30t（30 吨）类的标志，因为我们这个标志不是国际标准，所以包括 Mobileye 在内的很多算法在做 OCR 识别的时候会漏掉那个小「 t」。 这个看起来还好，但是在用户使用的时候，这个识别结果会和另一个功能，限速识别的限速数据搞混。 比如在一个 120km/h 限速的高速公路上，过了一个桥，系统会很容易以为现在限速是 30。 还有类似老人代步车、装满快递包裹的电动车/三轮车等中国特色交通工具等，很多都无法被 Mobileye 很好地识别。 因此，本土化的第一个工作是要建立自有的中国道路场景库。 感知算法基于本地化的场景，建立本地化的感知模型，有针对性地优化感知的全面性、实时性，对场景内涉及到的关键目标提高识别的准确度。 我们也一直在和以色列团队沟通，希望尽快解决这个问题，以上这些问题在 EyeQ4 上有了初步的优化，希望 EyeQ5 会更好。 我忽然想起一个很好玩的例子，我们曾经和一个瑞典团队合作开发 DMS，驾驶员状态监控系统，这个系统的算法模型都是在瑞典当地收集人脸特征训练的。 在我们联合测试过程中，我们团队有一位小伙伴，因为眼睛偏小，系统对他的识别率无论怎么调整参数都识别不了，最后这个国外的合作伙伴毕恭毕敬地把我们这位工程师请过去专门做数据采集，奉若珍宝，享受了 VIP 待遇。 没过多久，这个瑞典公司就开始针对亚洲人的面部特征做专门的数据库了。 在决策方面，也需要根据本土的场景进行适配性的开发工作。 对于 L1-L2 级别的功能，其决策模型较为简单，本土化的工作可能需要重新判定某些临界值的参数，比如感知模块判定前方是快递电动车，那么决策模块就需要将跟车速度降下来。 同时，考虑到快递车有随时停车的可能性，决策模块还需要输出拉大跟车距离的命令。 另外，对于电动车、自动车的行为预测和路径决策，是一直困扰我们的问题。 所以合资品牌新车型即使在深圳广州这种禁摩的城市 ADAS 测试非常顺畅，到了北京、天津就频繁 AEB 触发，就是对两轮车的预测太不准确了。 涉及到 L3 以上的高阶功能，某些连续的行为可能会代表特殊的意义，决策模块需要根据事件发生的概率做出行为判定，其决策模型较为复杂，本土化工作可能不只是参数修改这么简单，可能是模型优化甚至模型新建类的工作。 例如，中国特色的「加塞」行为，决策模块需要判定侧方车辆的意图，如果判定该车有 Cut in 的意图，那本车需要根据前后车的距离、相对车速情况来综合判定是否需要降速让侧方车辆 Cut in 进来。 很多欧美车企在设计 TJC 功能，也就是高速公路辅助驾驶功能的时候，是不考虑 Cut in 的情况的。 我有一次在跟德国系统工程师讨论，他们对于高速拥堵时候还加塞的行为特别不可思议。在我们做技术迁移和本土化的时候，这些都是我们要专门加强的部分。 控制模块本土化的工作相对系统，主要是应对上层决策层的需求，适配不同的车辆，调节算法参数适应不同的工况等。 还有，高精地图 HDMap 也是我们中国企业才能够参与的技术，和地图数据的适配也是高级别智能驾驶中国本土化的工作重点之一。 本土化的参数、算法模型需要这么大的工作量，后续的整车级、系统级、单元级的测试验证还涉及到大量的工时投入。 技术上完成一个本土化的周期我们来粗略的估算一下时间： 采集相关数据，训练数据和模型，保守估计 3 - 6 个月； 场地内功能测试，预计 8 - 12 周时间； 路试，积累足够里程数，周期在 77 天 - 120 天不等； 仅仅对自动驾驶做本土化的技术更新，粗略估计需要 1 年左右的时间，当然这都是在组建好成熟的团队的情况下。 所以，我们至少还需要等待一年以上的时间才能看到特斯拉中国技术团队的本土化成果，很值得期待。 P.S.预告：明天和后天，我们想讲两个非常硬核的话题，分别是：什么是好的 L4 智能驾驶汽车，以及什么是好的 L4 智能驾驶平台车。欢迎大家关注。 往期回顾： 特斯拉撞上了侧翻的大货车，从台湾嘉义事故谈传感器融合 智能汽车的中国芯：华为MDC首发测评 字节跳动入局车联网，互联网应用上车要解决哪些难点？ 为什么欧美车企纷纷放弃L3，而中国车企热衷量产L3？ 传统车企为什么造不出Autopilot，特斯拉L4战略存在什么风险？ 本期制作 主讲：郭继舜 监制：王德芙 编辑：叶方 后期：陆非 设计：陈溪阳 运营：林芝芝 音频平台 喜马拉雅 | 蜻蜓 FM | 听伴 Podcasts | 小鹅通 在以上平台搜索关注汽车之心 即可收听全部节目 「汽车之心·行家说」预告

7. 

   5 Jun 2020

   011 | 什么是智能汽车操作系统？为何大众、戴姆勒都在投入重金研发？

   编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，内容独家授权汽车之心发布。 写在前面：昨天我断更一天没有录音，因为临时出差晚上一直在飞机上，错过了录音的时间，在此向大家道歉。 自从开了这个音频栏目后，我差不多每天傍晚 7 点半左右下班，就开始想今天要录点什么内容。晚上 9 点半将文稿的提纲写好，然后对文稿信息的准确性查阅相关资料确认，大约 10 点半左右录音完成，再请编辑小伙伴制作和整理文稿。所以大家会发现，这个音频节目都是差不多接近 12 点的时候才制作完成上线的。 我发现这个制作机制太脆弱了，万一出差（或其他原因）就会断更，我本周末要多录几段儿囤着，也不能老让编辑小伙伴凌晨时候着急忙慌做音频和排版。 在此，对所有为这个小栏目付出辛劳的小伙伴表示衷心感谢。 今天分享的内容源自德国汽车制造商戴姆勒 CEO Ola Kallenius（康林松）在接受德国《商报》采访时提到： 戴姆勒计划为汽车开发软件操作系统（Windows for Cars），同时戴姆勒将开发用于导航、语音控制、音乐、电话通讯，刹车系统、安全气囊控制等一系列的汽车软件。 其实早在今年 1 月拉斯维加斯 的 CES 展上，戴姆勒已经介绍了自家操作系统 MB.OS。 戴姆勒希望在公司内部建立软件开发自研的能力，来替换来自外部的供应商的技术服务。 大概在 2024 年至 2025 年，戴姆勒车辆上的软件操作系统将完成向 MB.OS 的转换。 大家可能对「汽车软件操作系统」这个概念还比较陌生，但是对操作系统本身，应该是比较熟悉。 比如我们日常在电脑上使用的 Windows 操作系统，Linux 操作系统，又或者在手机上使用的 iOS 和安卓。 严谨一点说，操作系统是管理和调度计算机硬件与软件资源的计算机程序。 操作系统需要处理很多的任务，比如，管理与配置内存、决定系统资源供需的优先次序、控制输入设备与输出设备等等。同时，操作系统也能够提供一个让用户与系统交互的界面。 类似的，以目前智能驾驶辅助系统开发流程为例，主要包含了硬件开发、软件开发、系统集成、功能标定测试等等，在这之中软件开发中又分为应用层软件开发、中间件和系统级基础软件平台。 而戴姆勒目前计划开发的部分，几乎涵盖了软件开发中的所有部分。 可以这么讲，戴姆勒的野心是要为行业打造一个跨域的真正为智能汽车量身定制的系统。 而现阶段，我们在量产中广泛使用的 QNX 是黑莓公司当年为黑莓手机研发系统的改进版。 戴姆勒计划开发的车载操作系统 MB.OS 并不是像有些主机厂，仅仅基于安卓做 UI 的修改，通过改变用户的交互界面和操作逻辑体现个性化，它更类似于从底层创建一个汽车的安卓或者 iOS，将软件部分与硬件部分进行解耦，从而减少后期应用软件在适配不同硬件时复杂的重复性工作。 除了戴姆勒，大众集团于 2018 年宣布正在为整个产品线开发新的软件操作系统 vw.os，并从 2020 年起，大众品牌的电动汽车都将采用该操作系统。 理想汽车目前也在内部孵化一个 LiOS 项目，开发自主软件操作系统。 斑马智行基于 AliOS 系统开发了斑马智行车载操作系统，而 AliOS 系统实际的内核是 Linux。 当然，还有大家都熟悉的华为的鸿蒙操作系统。 为什么这么多企业都关注于在车载操作系统的开发呢？ 科技公司做系统开发还有情可原，戴姆勒、大众这样的主机厂有必要做车载操作系统的开发吗？ 我个人从技术的观点出发，认为戴姆勒、大众目前开展的软件操作系统开发是十分有必要的。 原因简要总结为以下三点： 第一，随着操作系统自主化开发，硬件和软件之间的可解耦性也变得越来越清晰。 每一个车型都会存在传感器型号不同、控制器芯片与架构不同等问题，之前部署应用软件在不同的车型中时，会针对每一款车型的硬件平台做定制化的软件适配与部署。 如果软件与硬件可以实现解耦，只需通过调整操作系统与不同硬件平台的适配，就可以将应用软件部署在新的硬件平台中，同时操作系统与不同硬件平台的适配工作量是远远小于应用软件直接和硬件平台进行适配的工作量的。 第二，未来的软件定义汽车的趋势可期。 如果车载操作系统是由主机厂主导设计的，在推向市场后会更容易对汽车进行 OTA 升级。 在功能应用场景新增与扩展，使用逻辑、人机交互策略更新时，则更容易由主机厂主导进行，而不是完全依赖于不同的供应商。 第三，数据在未来的智能驾驶上，扮演着越来越重要的角色。 主机厂如果需要保证用户在车辆使用过程中数据的所有权，车载操作系统在这其中扮演的至关重要的一环。 汽车的车载操作系统开发，只有对其内核、运转机理等研究得越深，主机厂在后续部署其应用软件时能参与的部分才越多，对应主机厂软件开发的自由度才越高。 比如说目前在研究 L4 级别的自动驾驶时，一般是选择 Linux 操作系统，在上面通过 ROS 来搭建一种信息交互的通信框架，这样在开发过程中，应用软件开发工程师可以更聚焦在节点上功能的实现。 由于 ROS 的开源、松耦合运行设计、支持多种开发语言，目前使用 ROS 进行自动驾驶开发时有着很大的便利性。 但是在真正量产的时候，因为 ROS 并没有解决数据实时性传输、数据加密以及数据传输量等问题，所以在实际使用过程中采取 Linux 和 ROS 这样的搭配较少，行业确实需要更加简单、易用、可靠、科学的车载操作系统。 除此之外，Linux 并没有拿到行业功能安全的认证，而如果使用黑莓的 QNX 车载操作系统，其虽已经获得功能安全认证，但是作为未来支持更高级别自动驾驶的系统，还是会存在信息安全、算法多核调度的优化空间。 一方面我们在等待 QNX 系统的升级，另外一方面，各个大厂开始寻找更加彻底的解决方案——自研操作系统，逐步支持未来智能座舱、车载娱乐、L2.9/L3/L4 乃至更高级的自动驾驶的软件开发。 正如大众汽车集团在 2019 年宣布将成为一家软件驱动的汽车公司，其计划通过组建一个 5000 人以上数字化专家团队来负责车辆内的软件开发，并在 2025 年实现内部车辆软件开发占比从 2019 年不足 10% 提高到至少 60%。 传统的汽车主机厂正在试图借助智能驾驶的发展，从车辆销售转变为车辆服务销售。而车辆本身更多的是一个技术的载体。 我们拿手机做类比，手机生态的利润，有不少是通过销售手机软件应用来实现的。 而汽车的利润模式，在未来很可能变成主要提供软件和数据服务，而车辆本身，不过是实现服务的场景罢了。 参考目前特斯拉的销售模式，Autopilot 的售价在中国区为 56000 元人民币，用户购买 Autopilot 后，系统的性能表现在不断地通过 OTA 升级变强，用户的购买意愿和对 Autopilot 的可感知价值都是非常可观的。 我想起 2018 年特斯拉通过 OTA 的升级，将其高速行驶时紧急制动的制动距离缩短了约 6 米。 我当时是非常震惊的，这对整车电子电器架构的支持，和底盘的一致性调教的要求是非常高的。 特斯拉能做到这一点，也是基于其内部拥有大量的软件工程师和软件开发平台的自主化。 在之前的音频中我也提到，特斯拉计划在今年打造一个类似 Uber、滴滴的智能手机应用，用户可以通过该应用呼叫 Robotaxi 自动驾驶出租车服务，并支持特斯拉车主将其车辆加入 Robotaxi 网络。 这也是软件和服务商业化的典型案例。 做一个简短的总结：从车辆制造商到移动出行提供商，未来留给车辆制造企业的想象空间还是很大的。新一代电子电器架构、域控制器的发展、车载软件操作系统等，都在技术层面让未来的汽车和商业模式更值得期待。 往期回顾： 特斯拉撞上了侧翻的大货车，从台湾嘉义事故谈传感器融合 智能汽车的中国芯：华为MDC首发测评 字节跳动入局车联网，互联网应用上车要解决哪些难点？ 为什么欧美车企纷纷放弃L3，而中国车企热衷量产L3？ 传统车企为什么造不出Autopilot，特斯拉L4战略存在什么风险？ 为什么实现车路协同比造一辆特斯拉还难？ 本期制作 主讲：郭继舜 监制：王德芙 编辑：叶方 后期：陆非 设计：陈溪阳 运营：林芝芝 音频平台 喜马拉雅 | 蜻蜓 FM | 听伴 Podcasts | 小鹅通 在以上平台搜索关注汽车之心 即可收听全部节目

8. 

   2 Jun 2020

   010 | 特斯拉撞卡车问题有解吗？谈谈自动驾驶感知前融合架构的优势和难点

   编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，内容独家授权汽车之心发布。 前情提要：由于昨天（6 月 1 日）台湾嘉义的特斯拉 Autopilot 事故，我们对 Autopilot 感知系统的安全性以及虚拟激光雷达进行了初步的探讨，同时对自动驾驶多传感器感知后融合的架构进行了一些介绍。 今天，我们来谈谈自动驾驶的感知前融合技术。 同样是特斯拉的新闻，根据外媒报道：2019 年 10 月，特斯拉收购自动驾驶感知创业公司 DeepScale。 DeepScale 的优势主要有两个： 第一，感知前融合（Early Fusion），在做目标检测前利用传感器的原始数据（RAW Data）而不是目标数据（Object Data）做感知融合，大大提高感知系统的鲁棒性； 第二，在不牺牲性能的前提下，通过重新设计神经网络来提升感知系统的效率，使深度学习模型在有限算力的嵌入式设备上运行成为可能。 除了 DeepScale，国内自动驾驶圈曾经的知名创业公司 Roadstar 也把感知前融合技术作为他们解决方案中重要的技术优势，相比于上一期我们提到过的后融合的感知方案，前融合的确具备一定的先进性。 在这里可能需要解释一下：虽然多传感器融合技术从上个世纪 70 年代开始，就已经随着声纳信号处理的需求被美国军方提出来了。 后来在 80 年代，又发展出了多传感器数据融合 MSDF (Multi-sensor Data Fusion) 技术，并且后续理论逐步完善，发展出了包括卡曼滤波、贝叶斯估计、D-S 证据推理、神经网络等等多种理论方法，但是其应用领域更多是信号处理方面。 由于算力不足以处理海量的数据，所以更多的是从信息论与概率论的角度来对观测值求取统计学上的一致无偏最优估计。 但在现在算力爆发的条件下，在自动驾驶的应用背景下，我们在工程实践上更多地会根据实际需要解决的问题，来对技术框架进行梳理，包括后融合与前融合这些行业内的常用说法，可能并不是严谨的学术术语。 回到前融合技术，相比于后融合，前融合具有很大的优势，简要总结为三点： 1.后融合感知框架中，每个传感器单独识别物体。 对于大型物体（如货车），单传感器识别只能识别到物体的一部分，从而容易导致大小及分类识别错误。 前融合通过将所有传感器原始信息有机组合，形成较完整的空间占据数据后，通过数据之间的互补能有效降低因部分识别造成的误判。 2.后融合感知框架中，不同的传感器因自身能力限制，特定条件下可能发生漏检或误检。 上述错误会直接输入后续的融合框架中，后融合对于已经引入的错误的过滤与纠错能力有限，可能无法识别与跟踪特殊物体或者小物体。 而前融合的数据，在融合后能够将数据维数扩展到更加高维的空间，包含的信息更加丰富，能够让算法的分类边界更加易于训练与实现，同时对于小目标的识别率有很大的提升。 3.后融合感知框架中，需要针对不同的传感器训练不同的感知算法，最终的感知结果取决于每个算法的性能，难以调优。 前融合感知框架则能够通过一个单一的识别算法模型对融合后的数据进行统一处理，优化起来更加方便。 当前的数据前融合感知的主要手段有两种： 1.传统的基于三维空间理论分析方法。 首先将图像和激光雷达或者毫米波雷达的信息统一坐标系，即空间同步。 其次对传感器每帧的数据进行校准，进行时间同步。 然后寻找空间之间最佳的线性变换矩阵，将图像标定后每个像素的距离信息与点云进行配准，或者利用点云和摄像头像素的共线原理将点云投射到摄像头图像中进行融合。 融合得到的结果是具备颜色信息的点云数据，或者是具备深度信息的图像数据。 最后再基于融合的结果进行后续的识别操作。 这种方法的优点是可解释性强，对数据的依赖较小，标注工作量小，缺点就是需要极强的标定能力，一旦传感器的种类与位置稍有变化，就需要重新进行标定。 基于视觉染色点云 2.基于神经网络/深度学习的方法。 该方法不会进行点云与像素之间的相互映射，而是直接以端到端的形式输出检测的目标、车道线以及其他的预期目标。 首先对图像和点云进行时间空间同步，然后根据预期的输出目标将图像和点云进行分别标注，将标注好的图像和点云数据输入到神经网络。 通过神经网络去学习图像和点云之间的对应关系和点云和图像的相关性，使得输出结果更加准确。 这种方法对于标定的能力要求大大降低了，可以容忍一定的传感器变化，但是对标注工作量需求大增，因为引入了深度学习模型，可解释性比较差，且对算力的要求更高，目前还是处于探索阶段。 RoadStar 所采用的感知前融合架构 （来源：RoadStar 分享资料） DeepSense 网络结构 （来源：DeepSense: A Unified Deep Learning Framework for Time-Series Mobile Sensing Data Processing） 但是，虽然前融合感知技术能够提高感知系统的准确性与鲁棒性，但在当前还主要面临下面几个难点，造成这个技术并没有被广泛的采用，简要总结为四个难点： 1.数据来源问题：前融合需要对传感器的原始数据进行融合，所以需要各个传感器都能够给出原始的 Raw Data。 但是受限于产品接口与商业协议等等问题，有些传感器无法获得原始数据（例如我们在量产中使用的博世毫米波雷达，EyeQ4 的智能摄像头等），对于这些传感器无法适用前融合感知框架。 2.时间同步问题：通过统一的主机给各个传感器提供基准时间，各传感器根据已经校准后的各自时间为各自独立采集的数据加上时间戳信息，可以做到所有传感器时间戳同步。 但由于各个传感器各自采集周期相互独立，无法保证同一时刻采集相同的信息。时间误差需要在 1 微秒以内，当前是比较难以达到的。 3.空间同步：将不同传感器坐标系的测量值转换到同一个坐标系中，其中激光传感器在高速移动的情况下需要考虑当前速度下的帧内位移校准。100 米外的物体距离精度要在 3 厘米以内。 这对于标定测量提出极高要求。同时，由于在使用过程中传感器的参数与相对位置可能也会发生一些改变，出厂时的标定参数不一定能够使用，所以如何实现在线重标定也是一个难以解决的问题。 4.算力需求：前融合神经网络通过全面接收整车所有传感器数据，通过超大规模神经网络运算识别出障碍物位置、大小及分类信息。这对于硬件的 AI 算力提出极大要求。 当然，不管是前融合还是后融合，白猫黑猫，抓住老鼠才是好猫。 在现在这个阶段，自动驾驶需要的是更加安全与鲁棒的感知系统，最终还是需要根据当前的软硬件条件来选择最适合自己的感知系统实现方案。 我们上一期讲到，特斯拉的虚拟激光雷达可能是一个非常好的探索，由于摄像头的被动感知模式，通过特殊设计的车灯和特定波长的滤镜（参考激光雷达）或许能够在一定程度上改善摄像头失效的问题。 但是，基于功能安全的分析和考虑，自动驾驶所需要的感知方案最终必然是一个足够异构冗余的多传感器融合方案，才能够真正的保证自动驾驶系统的安全性。 还是那句话，虽然我很喜欢特斯拉的电动车，虽然我连续两个晚上熬夜看 SpaceX 的载人火箭发射热血沸腾，但在高级别智能驾驶方面，我依然是激光雷达坚定的支持者。 往期回顾： 特斯拉撞上了侧翻的大货车，从台湾嘉义事故谈传感器融合 自主品牌向上突围，中国车企推出高端品牌的逻辑 智能汽车的中国芯：华为MDC首发测评 字节跳动入局车联网，互联网应用上车要解决哪些难点？ 为什么欧美车企纷纷放弃L3，而中国车企热衷量产L3？ 传统车企为什么造不出Autopilot，特斯拉L4战略存在什么风险？ 为什么实现车路协同比造一辆特斯拉还难？ 本期制作 主讲：郭继舜 监制：王德芙 编辑：叶方 后期：陆非 设计：陈溪阳 运营：林芝芝 音频平台 喜马拉雅 | 蜻蜓 FM | 听伴 Podcasts | 小鹅通 在以上平台搜索关注汽车之心 即可收听全部节目 「汽车之心·行家说」预告 华为智能座舱的野心：HiCar上车，为鸿蒙OS铺路 千倍成本压缩！特斯拉开发虚拟激光雷达，替代最贵自动驾驶传感器 蜂巢能源抢先落地，无钴电池的第一次出击

9. 

   2 Jun 2020

   009 | 特斯拉撞上了侧翻的大货车，从台湾嘉义事故谈传感器融合

   编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，内容独家授权汽车之心发布。 最近这段时间，关于特斯拉的新闻很多，我们今天讲其中两个。 第一个新闻发生在今天：2020 年 6 月 1 日，在台湾嘉义，一辆 Model 3 在高速公路上撞上了一辆侧翻的大货车。 我仔细看了下这条视频特斯拉车主估计开启了 Autopilot 功能，早晨 6 点 44 分，可能车主昨晚没睡好，在车上打瞌睡分神了。 车载摄像头和毫米波雷达没有识别出前方的箱式大货车，车头撞进了货箱箱体。 初步估计，这可能是货车白色箱体有比较强烈的阳光反射，影响了这辆 Model 3 的摄像头识别；或是因为视觉算法训练数据的局限性，一般训练的都是识别车辆后部、侧面、车辆头部，工程师可能没想过有一天需要识别货车的箱体顶部。 深度学习模型不能对这个物体分类，也就是说，算法不支持识别货车白色箱体这样的障碍物，造成了此次事故。 可能有人会问，即使摄像头没有识别，车载的 77G 毫米波雷达也应该能识别障碍物。 这与传感器的融合机制有点关系。 一般来说，1R（毫米波雷达）的 AEB （自动紧急制动）系统，只用一个毫米波雷达作为传感器的紧急制动系统，是能够对静态障碍物识别且正常制动的。 但在类似特斯拉这样的 1V1R （1 个摄像头+1 个毫米波雷达）的方案中，也就是一个前项摄像头加一个前项 77G 毫米波雷达的传感器方案。 为了减少 AEB 误触发，往往会用算法滤掉毫米波雷达对静态物体的信号，用摄像头识别多个目标，跟踪目标，同时用毫米波雷达对已识别物体进行检测和跟踪。 所以，因为传感器融合逻辑的问题，在这个案例中，毫米波雷达也没有及时给系统报警。 第二个新闻，是这几天，国内的一些媒体报道了今年 2 月在 Scaled ML 大会上，特斯拉 AI 高级总监 Andrej Karpathy 对外分享的特斯拉训练 AI 的方法，同时也首次对外分享了特斯拉如何借助摄像头就能实现激光雷达的探测精度。 这也让我们看到了 Elon Musk 坚持不使用激光雷达的技术底气。 目前，特斯拉 AI 团队已经掌握了名为「虚拟激光雷达」（pseudo-LiDAR）的新技术，它弥合了传统计算机视觉和激光雷达强大的点云世界之间的界线。 在 Scaled ML 大会上，特斯拉放出了一系列有激光雷达形式的 3D 地图，这些地图看起来就像是激光雷达采集到的信息，但是是用摄像头图像生成的。 Andrej Karpathy 说：「我们走了一条『虚拟激光雷达』的路径，只需简单预测单个像素的深度，找到它们直接的距离，就能得出结论。」 人类有很多得到物体距离（即景深）的方法，除了双眼创造的立体视觉之外，人类还能借助「动态视差」跟踪物体的运动方式，从而得出其他可以参考的线索。 比如人类驾驶员，经过短时间的适应，闭上一只眼睛，也一样能够好好驾驶。 初看这个技术报道，我感觉有些震惊，以为特斯拉又发布了什么黑科技。 但是仔细研究了新闻中提到的「虚拟激光雷达」的技术原理和效果图，也查阅了相关的资料后，我基本可以确认，这就是视觉感知中的经典的「单目视觉深度估计」问题，只不过将数据的展示形式用类似激光雷达点云的方式进行展示。 我的印象中，在 MobilEye EyeQ4 芯片和地平线 J2 芯片的视觉感知方案中已经发布了类似的功能，只是精度上与激光雷达有较大的差距。 在这个新闻中，我们并没有看到特斯拉发布精度的数据，所以也无法评论其算法的先进性与实用性。 借着今天这两个新闻，我给大家讲讲自动驾驶系统对于异构传感器的融合。 由于内容比较多，也比较技术，为了防止信息量过载，我们今天讲后融合，前融合等放在明天讲。 现阶段自动驾驶系统认识世界的唯一方法，就是通过传感器来接收外部的各种物理量并转换成电信号，再通过采样编码等方式变成原始数据，然后通过感知算法识别为目标信息，最后通过理解算法还原成对真实世界的抽象模型。 根据检测的物理量与采样编码方式的不同，我们大致可以将自动驾驶中的传感器分为： 使用被动环境光的视觉传感器-摄像头； 使用主动编码红外激光的激光雷达； 使用主动高频电磁波的毫米波雷达； 以及使用主动式超声波的超声波传感器。 除了上述直接对环境进行探测的传感器以外，还有一类设备，能够通过通信方式，直接获得外界编码好的事件信息，比如 V2X、GPS、IMU、RTK、轮速计等等，这些可以看作广义上的传感器。 各种传感器由于信号来源不同、原理不同、处理方式不同，在感知外部环境信息的时候具备不同的特性，我们把上述的这些差异称为传感器的「异构性」。 摄像头的感知数据是图片，也就是 RGB 像素的二维矩阵，分辨率高，但由于是被动式传感器，成像结果受强光、弱光影响较大。 一般的 24G 或 77G 毫米波雷达的感知数据是一条扫描线上的距离以及多普勒效应相应所表征的相对速度，是一维数组。 有些先进的毫米波雷达，在普通毫米波雷达的基础上增加了垂直方向的分辨率，同时频率也上升到了 79-81G，从而能够输出带相对速度信息的三维点云数据，也被成为 4D 毫米波雷达。 但是因为电磁波的特性，对于金属敏感度过高，对于人体等非金属目标敏感度不足，信号的噪声比较高，且由于波长远大于光波，衍射现象造成了分辨率不高，需要较多的滤波和后处理过程。 激光雷达通过主动红外激光扫描的方式，通过反射时间测距原理得到的是带反射率的三维点云信息。 由于激光频率高，波长短，光束能量密度大，因此具备分辨率高、距离精准，受外界影响小、信噪比高等特点，是非常理想的环境传感器。 但是缺点就是成本高、难维护，以及相比摄像头缺失了色彩信息，数据仍然不够稠密。 从上述分析可以知道，摄像头由于分辨率、帧率、信息丰富程度、算法适配度、产品成熟成本低等等多种优势成为了现阶段自动驾驶感知设备的首选。 但是，由于其原理的局限性，仍然无法解决自动驾驶感知中的所有问题： 首先，摄像头的透镜成像原理本质上是将三维空间坐标系投影到二维齐次坐标系的变换，损失了距离信息，所以单摄像头的单帧图像无法直接还原三维空间的距离信息，这是摄像头的本质缺陷。 虽然多摄像头或者单摄像头的多帧图像是可以利用多个齐次坐标系之间的相关性求解方程恢复深度信息的，也就是双目视觉感知技术和单目视觉 SLAM 技术。 但是即便如此，由于摄像头的检测方式是被动接收外界光线，所以仍然解决不了受外界强光干扰严重的问题，在逆光下失效可能很大。 所以，用摄像头虚拟激光雷达来替代实际的激光雷达，在目前看来，至少在精度还是鲁棒性上，都还是不太现实的。 现阶段，我依然是 L4 激光雷达解决方案的坚定支持者。 由于上述传感器都有各自的优缺点，现阶段自动驾驶感知系统使用的是混合异构传感器组合架构，以实现感知信息的互补融合。 根据智能化程度从低到高，对于传感器异构冗余的要求就越高： L2 辅助驾驶通常包括摄像头和毫米波雷达至少两种传感器； L2+ 自动驾驶会在摄像头和毫米波的数量和部署位置上进行增加； L3-L4 以上更高级别的自动驾驶则会在此基础上增加激光雷达传感器，用以覆盖更多的盲区，增加更多的可靠性与置信度。 在当前的自动驾驶工程实践中，我们通常采用感知结果后融合（Later Fusion）的方式来重建真实世界的模型。 也就是多种传感器采集原始数据后，各自单独使用算法进行目标的识别和分类，再根据对各个传感器结果的置信度不同，通过概率模型将可能是相同目标的观测结果融合起来，获得统一的世界模型。 我们回到第一条新闻，以视觉和毫米波雷达的融合 AEB 系统为例： 由于毫米波雷达受到光照的干扰相对较少，视觉感知算法漏检率太高，早期的 AEB 设计倾向于以毫米波结果为准。 后来发现毫米波雷达对金属敏感度太高，噪声太多，造成了虚警和鬼影太多，而视觉算法的准确度也越来越高，所以现阶段 AEB 系统对毫米波雷达的置信度权重下降，感知结果以视觉感知为主，通过一段时间内的置信度投票的方式获最终的感知输出。 这就是为什么那辆 Model 3 视觉失效了，毫米波雷达也不能很好地起作用的原因。 顺便说一下，目前通用的后融合框架主要有卡曼滤波与非线性优化方法，主要讲的是时间更新与测量更新，如何在算法层面形成数据闭环。 但是，后融合有一个较大的缺点，就是结构化信息的融合是各个传感器识别后的结果，对原始数据的信息损失量大，数据信息量低，这些损失的信息往往能够通过原始数据的融合而提高利用率，发现更多的微小有用信息。 所以传感器信息前融合的方法就逐渐受到了人们的关注。明天，我们将讲讲前融合。 往期回顾： 智能汽车的中国芯：华为MDC首发测评 字节跳动入局车联网，互联网应用上车要解决哪些难点？ 为什么欧美车企纷纷放弃L3，而中国车企热衷量产L3？ 传统车企为什么造不出Autopilot，特斯拉L4战略存在什么风险？ 为什么实现车路协同比造一辆特斯拉还难？ 本期制作 主讲：郭继舜 监制：王德芙 编辑：叶方 后期：陆非 设计：陈溪阳 运营：林芝芝 音频平台 喜马拉雅 | 蜻蜓 FM | 听伴 Podcasts | 小鹅通 在以上平台搜索关注汽车之心 即可收听全部节目 「汽车之心·行家说」x 思必驰专场预告

10. 

    29 May 2020

    008 | 自主品牌向上突围，中国车企推出高端品牌的逻辑

    编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，每周一至周五更新，每日一期，内容独家授权汽车之心发布。 昨天，我们讨论的是一个非常硬核和技术的话题，在表述上难免会因为太多技术名词而不太易懂。 考虑到明天又是一个很硬核的算法技术的介绍，今天，我们稍微聊一点儿偏品牌战略的软课题：自主品牌的品牌向上战略。 近期，行业内 2 大自主品牌都有一些战略性的动作： 本月初，也就是 2020 年 5 月 6 号，东风汽车集团有限公司董事长、党委书记竺延风对 h 事业部员工发表了一封公开信。 竺延风在这封信中表示：h 品牌承载着整个东风品牌向上的重任，并将拥有全新的组织、全新的机制和全新的商业模式，同时 h 品牌致力于成为「中国新能源汽车产业的引领者」。 5 月 10 日，上汽荣威「双标战略」正式发布，官方新闻是这么说的：全新的 R 标作为荣威中高端新能源专属；新狮标积极部署「年轻化战略」，将以焕新的品牌形象深耕传统燃油车领域，做时代的弄潮者。 从大环境来看，自主车企在品牌能力提升、品牌形象提升方面都在不断出拳。 我们常说「国产手机的今天，就是国产汽车的明天」。 放眼汽车行业，各自主品牌车企紧抓「智能网联」这个弯道超车的机会，都在尝试走出自己的特色路径。 接下来，我们大概归纳出国产品牌向上的几个特点，然后为大家分析一下其背后的技术和产品逻辑。 1. 智能网联配置的广泛应用，是自主品牌实现品牌向上的基石。因为智能化和网联化产品的用户可感知价值更大。 性价比高，一直是自主品牌在广大用户心目中的印象。 用相对低廉的价格，却能买到相比于合资品牌和外资品牌具有更多高端配置的汽车，这一点，我们打开汽车资讯网站的功能配置表就会有强烈的感受。 精准整合供应链中的每一个环节，最大化地压榨整车成本中的不必要的开销，压低车辆售价的同时搭载高级配置，用高性价比的产品打动用户的心。这是自主品牌的拿手绝活。 从配置表上看，自主品牌在智能化、网联化等科技配置的搭载率上远超合资，可谓是下足了血本。 其背后的产品逻辑是，网联功能通过车载 OS 和定制化 APP 的生态级整合，智能驾驶功能通过给用户新的驾乘体验和人机交互逻辑，能极大地提升用户的可感知价值。 车厂将有限的成本花在用户可感知价值更大的配置上，花 1000 元钱的零部件成本却让产品有了几千元甚至更多的成色，品牌的性价比自然就凸显出来了。 这也是为什么智能网联功能在这几年受到市场关注的底层逻辑。 顺便吐槽一下，智能驾驶相关零部件的成本还是挺高的。 暂且不说几万、几十万一个的激光雷达，我记得几年前一个 77G 毫米波雷达的厂家进货成本也在大几千块。 随着这几年出货量的增加，成本得到降低，1V1R（1 个摄像头+1 个毫米波雷达） 这样的配置才慢慢在高配或者中配上搭载使用。 相信随着技术的不断发展迭代，在未来会有更大的软硬件降价空间。 自主车企在如此高成本的压力下仍坚持推出低价产品，那么其背后一定在降本增效工作上下足了苦工。 就自动驾驶领域而言，想要降本何其不易，从传感、感知到决策、执行，任何一个阶段的功能实现都和软硬件有极高关联性，想要高性能，那必然意味着需要高级的软硬件配置。 现在大家如何在技术层面实现降本呢？ 可能的途径大概有以下几种： 1） 硬件方面，控制器高度集成，以域控制器的形式承载多个自动驾驶功能，减少 ECU 数量，在降低了 ECU 硬件成本的同时还减少了整车线束成本； 2） 软件方面，自主研发软件、应用层算法，不再强依靠供应商投喂，在功能定义方面掌握更多议价权和主动权； 3） 系统集成方面，坚持硬件平台化，有计划地实现硬件预留，尽量降低硬件的二次开发成本，充分发挥软件定义汽车的软件端的个性化，用软件的独特性凸显品牌个性，尽可能地发挥硬件的所有能力； 4） 多车型联合定点，品牌间合作平摊研发费用实现降本。 2. 推出高端品牌，突破自主品牌原有的定价天花板，才能为新技术、新功能的应用提供更多的成本空间。 近年来，自主品牌凭借高性价比的优势，在销售市场份额占比呈逐年攀升之势。 去年、前年虽有小幅度回落，但总体占比依然在一个较大的体量。 靠着「高性价比」的优势自主品牌分得了较大的市场蛋糕，但利润率低、品牌档次不高、价格天花板明显等问题逐渐暴露，极大地限制了自主品牌在价格上的上涨空间。 以 ADAS 产品为例，ADAS 产品的成本较高，占据单车成本的百分就高，为了能更好的配置整车成本占比，车型定价自然需要有比较高的整车定价空间。 这就对自主品牌的整体品牌向上提出了更高的要求。 作为智能驾驶开发的工程师，压缩 BOM 成本，是我们经常面对又无比痛苦的一个课题，有时候甚至为了达到单车降成本的要求，即使智能驾驶、车联网等功能开发好了，也不得不忍痛放弃搭载上车。 一切的目的，都是为了给用户呈现最具性价比的整车产品。 后来，越来越多的汽车企业意识到一个问题，通过减少核心技术配置来一味降本，打价格战并不是可持续发展的市场策略。 如果想要提升产品力，提升性价比，增配置，练内功，注重产品质量品质才是王道。 为此，自主品牌纷纷推出高端品牌试水市场，其中长城旗下的 WEY 、吉利旗下的领克、奇瑞的星途等，都是自主品牌高端化的代表。 与这些品牌不同的是，包括一汽红旗、广汽 AION 以及最近东风 h 品牌、上汽荣威推出的 R 品牌，则从高端电动车领域切入。 目前来看，推出高端品牌不失为一个好的战略。 这几家高端品牌的每款车型发布，都会吸引行业目光，各大车企纷纷购买新车进行零部件级别的深入对标工作。 自主品牌有了高端的「形」，还需要高端的「魂」来支撑。 想要长久发展，品牌的技术沉淀是关键。 此前自主品牌被人诟病的质量问题多、可靠性差、做工粗糙等问题，还需要在高端品牌上打磨改善才行。 近几年我们也看到了不少口碑很好的高端自主品牌车型面市，比如：长城 WEY 的 VV7、小鹏的 P7、广汽的 AION S 等车型。 3. 跨品牌的优势融合和跨界的生态对接，都是为了提高用户的可感知价值，合作为品牌向上提供持续的动力。 李书福曾经指出，未来的车企要与客户、行业内外的供应商，甚至竞争对手建立新型的伙伴关系，以共赢代替对抗性的竞争。 由产业的生命周期性质决定，产业链条上会出现「归核化」。 自主品牌的「归核化」之路，除了自主创新的助力之外，多方合作能很好地增强企业核心竞争力。 当前行业内的合作可以大致可以分为以下两类： （1）车企之间的合作。 所谓背靠大树好乘凉，自主车企想要向上还可选择与国际大佬积极合作。 比如：吉利与沃尔沃联手推出领克品牌，沃尔沃向领克输出了 Drive-E 涡轮增压发动机技术和 CMA 架构平台。 其中 Drive-E 是沃尔沃现阶段主流的发动机，新的 XC40 首先搭载 Drive-E 引擎，而且在 V40 上也有相关技术的支持。 CMA 架构平台号称全球最安全的中级车平台，其研发主要由位于瑞典哥德堡、吉利汽车和沃尔沃汽车联合建立的中欧汽车技术中心来完成。 有沃尔沃的技术作为背书，领克的技术成长起点可以说是非常高了。 （2）车企与科技公司的合作。 传统车企依托硬件基础研发软件系统，科技公司依托软件技术优势进行硬件整合，两者的合作能为自主品牌带来更丰富的技术血液。 比如：百度的阿波罗计划与多家车企合作、腾讯的车辆网业务与各大车企合作、阿里的斑马操作系统植入各大车机系统等。 这些都是跨行业合作的典范。 不论是跨品牌还是跨界的合作，其内在的核心都是技术的引进与革新。合作才能共赢。 最后，照例做一个总结: 自主品牌的品牌向上战略，会为自主品牌带来新的生命力，也为自主品牌的新技术应用，新功能整合提供了更好的平台。 智能化、网联化、电动化、情感化等的品牌力提升，需要我们在积极研发智能网联技术，提升品质的同时，获得更多搭载新技术的成本空间。 只有品牌持续向上，才能够从增量到存量的消费市场持续获得用户认可和品牌忠诚度。 作为研发领域的一员，提升自主品牌技术能力和品牌竞争力，是我们永远不变的目标。

11. 

    28 May 2020

    007 | 智能汽车的中国芯：华为MDC首发测评

    编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，每周一至周五更新，每日一期，内容独家授权汽车之心发布。 今天我们来聊聊华为的智能驾驶域控制器 MDC。 这段时间关于华为的新闻非常多：一方面美国政府对华为的打压力度不断加重，限制令也越来越严苛；另一方面，华为发布的下一代"四无"生态型摄像机，展现自己在机器视觉方面强大研发能力。 在智能驾驶领域，华为在软硬件以及系统上的技术突破也一直受到大家关注。 上个星期，华为在官方微博上宣布，华为自动驾驶操作系统内核，也就是大家所熟知的鸿蒙内核，已获得了功能安全领域最高等级功能安全认证——ISO 26262 ASIL D 认证，华为的鸿蒙内核成为了我国首个获得 ASIL D 认证的操作系统内核。 另外，鸿蒙内核还在 2019 年 9 月获得了信息安全领域最高等级信息安全认证，CC EAL 5+认证。这样，华为自动驾驶操作系统鸿蒙内核已成为业界首个拥有信息安全与功能安全双最高认证的商用 OS 内核。 除此之外，华为的自动驾驶全栈解决方案、MDC 智能驾驶计算平台都先后获得了 ISO 26262 功能安全 ASIL D 级的认证。 华为 OS 内核 刚才我提到的 ISO 26262 汽车功能安全标准是国际标准化组织在 2011 年制定的一项全球性的标准，并且在 2018 年 12 月正式发布了更新版本。 这个标准涵盖了汽车功能性安全需求规划、设计、实施、集成、验证、确认和配置的方方面面，目的是希望通过完善开发流程，将汽车电气或电子系统故障的风险降到最低，是全球电子零部件供应商进入汽车行业的准入门槛之一。 我们在前面的音频里曾经讲过，对于 L3 及以上级别的智能驾驶系统，系统整体必须达到 ASIL-D 的功能安全等级。 我们该如何去理解 ASIL-D 的系统有多安全呢？ 我给大家举一个例子。因为汽车功能安全的分析非常复杂，我就简单拿硬件的失效概率这个典型特征给大家举例。 如果我们把华为 MDC 这种满足 ASIL-D 功能安全的控制器量产装车，在大于 10 的 8 次方个小时才会有一次随机硬件失效。 我们按照每天有 3 个小时处在智能驾驶功能开启状态来计算，每年我们用车大约 200 天，这款智能驾驶汽车在全国有 10 万名用户正常使用，配合合理的人机交互机制，这个域控制器每 1667 年才会有一次因为硬件失效造成的严重安全风险。 当然，汽车的功能安全机制是非常复杂的，为了方便大家理解，我在此把它大大简化了。 但从分析结果可以看到，这样高稳定性的硬件系统是非常让人放心的。 回到我们今天讨论的主角，MDC 智能驾驶计算平台，就是华为自动驾驶全栈解决方案中的硬件平台，鸿蒙内核的系统未来是运行在 MDC 硬件上，再与智能驾驶软件算法紧密配合，最终形成可以量产搭载的智能驾驶核心域控制器。 机缘巧合，我有幸在 MDC300 发布没多久就拿到了尚在开发和完善中的华为 MDC300 域控制器的样件。 在半年的时间里，我在这个硬件平台上进行了比较深入的测试与开发工作。今天，咱们就来聊聊华为的智能驾驶域控制器 MDC。 如果不出意外，我们应该是行业内第一个对华为 MDC 公布详细测试结果的。 为此，我专门打电话给华为 MDC 开发的负责人——李振亚老师，获得了他的授权。 接下来的分享可能会非常技术和极客，我会努力把这些信息用相对易懂的方式表达出来。 首先，说说我手里这款华为 MDC300 的硬件。 半年前拿到手的第一印象就是，这是一个完成度很高的车载运算设备：黑色的 MDC300 主机、接口转接模块，一些连接线缆，细节上继承了华为一贯的做工精良。 但可能是样件的原因，仍然采用的是主动风扇散热，以及非密封防水防震的普通接插件，还没有达到车规级的标准，但相信后续在量产车型上使用的时候应该都是车规级状态了。 我针对华为 MDC 主要做了功能和性能上的测试，包括： Adaptive AutoSAR 的通讯框架验证测试、CAN 总线通讯测试、神经网络加速测试、摄像头驱动测试、激光雷达驱动测试、深度学习模型运算效率等等基础功能测试，并且用量产级代码做了 LKA、ACC、TJA 等功能集成与 SLAM 功能集成等等集成测试，用来验证华为 MDC 设备样机的功能、性能、接口丰富程度、运行稳定性、开发支持生态、工具链易用性这一系列指标。 目的是看看华为 MDC 是否适合作为 L3 甚至是 L4 高级别自动驾驶域控制器的候选方案。 在此，我先要给大家做一个有关智能驾驶域控制器的介绍，你可以简单地把智能驾驶域控制器理解为智能驾驶汽车的大脑。 它主要负责对感知到的信息进行融合、识别、分类，然后对车辆进行规划和决策，最终还要完成对车辆的精确控制，从而达到智能安全地驾驶车辆的目的。 在软件层面，域控制器有系统层、中间件、应用层算法等。 在硬件层面，一个域控制器上往往有三颗，或者说三组芯片。 第一颗芯片有非常大的算力，往往是 GPU 或者 TPU，主要是做感知信息的融合、识别、分类等，这颗芯片擅长做大规模的低精度浮点型运算，也承担了域控制器上大多数的算力需求； 第二颗芯片是一块 ARM，主要是集成系统，同时进行规划决策等逻辑运算，一般擅长进行高精度浮点型串型运算，这块芯片非常类似我们熟悉的 CPU 处理器； 第三颗芯片往往是一个高可靠性 MCU，主要负责车辆的控制，这块芯片的特点是高可靠性，但是算力可以不那么大，一般要达到 ASIL-D。 我手上的这个华为 MDC 样件，感知部分由四颗华为昇腾芯片组成，每颗芯片 16 Tops 的算力，第二颗芯片是华为的鲲鹏芯片，第三颗是 TC397。 这样算下来，这颗 MDC300 的算力在 64 Tops 左右，完全满足了 L3 为代表的高级别智能驾驶功能的需求。 我的初步估算，未来量产的 L3 级别智能驾驶，如果考虑算力冗余和硬件预留，需要差不多 30 Tops 的算力，L4 需要 60 到 100 Tops 的算力。 这半年的测试过程中，我亲眼看着华为的开发工具链快速完善，变得越来越好用。 现阶段，对于面向量产的智能驾驶域控制器开发来说，已经有非常完备的工具链支持了。 包括：Adaptive AutoSAR 的配置工具 ARTOP、代码开发/部署工具 MDC Development Studio、神经网络模型转换运行工具 Mind Studio，以及支持 Classic AutoSAR 的 Tasking 编译工具和配套的 MCU 二次开发包等等。 经过半年的努力，计划的测试和验证都顺利完成了，并且取得了比较好的技术指标，尤其是在接口丰富程度和神经网络加速性能上达到了我们设计的指标。 其中值得一提的是，华为 MDC 对于稀疏的深度学习模型的效率依然保持的很高。 可以推测，华为针对最近大家常用的 MobileNet 等深度学习网络运算进行了针对性的优化。 另外在工具链的易用程度上，由于支持通过引入 Matlab 头文件编译 Simulink 模型，所以能够比较快地将我们原有的量产级智能驾驶算法模型部署到 MDC300 设备上。 从拿到设备到实现 MDC300 设备上实车运行 LKA、ACC 等功能，只花了 1 个半月的时间。开发效率还是很高的。 说完了我们对华为 MDC 设备的测试情况，再说说华为 MDC 在市场上的竞争者，这也让我们能够有更多的选择。 由于特斯拉的 FSD 控制器（已发布）以及英伟达的最新 DRIVE 平台的车载设备（未发布）我们并没有获得实际设备，以下对比分析仅以公开渠道获得的信息为准： 1．特斯拉 HW3.0 FSD 控制器。 作为特斯拉车辆的部件，不单独销售，资料较少。 根据目前的信息，FSD 的 HW3.0 有两个相同的计算单元构成，每个计算单元上面有 2 块运算芯片，每块算力位 36 Tops，设备总算力位 4 x 36 Tops = 144 Tops。但是由于采用的是双机热备的运行方式，实际可用的算力是 72 Top。 在功能安全上，FSD 的 2 个计算单元每 20ms 同步一次运行状态与处理数据，通过交叉验证以保证故障冗余安全。 相比早期的 Autopilot HW2.0 方案，安全性能得到很大的提升。但目前我们并没有得到 FSD 关于功能安全认证的相关消息。 2. NVIDIA DRIVE 平台的车载智能驾驶控制器，支持芯片级方案销售。 目前上市的只有 Xavier 系列，最新的基于 Orin 的 Drive AGX 到目前为止还没有上市。 根据公开的资料，Xavier 系列控制器的 AI 算力是 30 Tops，Orin 系列控制器的 AI 算力是 200 Tops，对比华为 MDC300 的公开 AI 算力是 80 Tops，MDC600 的公开 AI 算力是 160 Tops，可以说是处于同一个产业生态位的。 通过对华为 MDC300 设备的一系列测试，以及对于竞品域控制器之间的对比分析，可以得出以下结论： 1. 华为 MDC300 设备是华为面向智能驾驶推出的对标特斯拉 FSD、英伟达 DRIVE 的高级别自动驾驶域控制器系列，主要主打全自研芯片，高算力、高可靠的车规级别自动驾驶域控制器。 这半年的测试，验证了华为 MDC300 在功能上与性能上可用性。 从功能上，能够支持目前 L3+以上可能需要的传感器类型的接入以及整车网络接入，内部支持 ROS 与 AutoSAR AP 软件架构，具备较好的跨域通信能力。 从性能上，具备较好的模型加速性能，以及总线传输性能，具备作为后续 L3 以上级别自动驾驶功能开发的域控制器应用能力。 2. 华为 MDC300 的工具链主要遵循 Adaptive AutoSAR 标准体系架构，兼容 MBD（Model-Based-Develop：基于模型的开发）开发工作流，开发生态更加贴近域传统主机厂软件开发人员所熟悉那一套，能够与现有的 ASPICE 软件开发流程更好地整合，便于通过功能安全认证，具有一定生态优势。 作为对比，NVIDIA 的开发生态更加接近人工智能开发领域的习惯，与汽车软件开发领域差异较大。 而特斯拉完全抛弃了传统主机厂的软件开发模式与人工智能研究人员的开发模式，走出了一条属于自己的全新道路。 3. 华为 MDC300 在功能安全与可靠性方面，依靠通信领域与移动终端领域的开发经验，在可靠性与确定性低延时方面具备较大的优势，产品更加工程化。 在安全认证方面，华为的自动驾驶全栈解决方案、MDC 智能驾驶硬件平台、车载操作系统鸿蒙内核近期都已经获得了 ASIL-D 功能安全认证，在功能安全设计领域走在前面。 后续只要华为的 Adaptive AutoSAR 架构、开发工具链以及自动驾驶算法能够通过 ASIL-D 功能安全认证，那么基于华为 MDC 的自动驾驶系统将成为世界首个符合 ISO26262 ASIL-D 标准的商用自动驾驶系统。 4. 在商业化合作模式上，华为坚持自主芯片方案，所采用的昇腾系列芯片与鲲鹏系列芯片都只能够用在 MDC 系统产品上，不提供芯片级别的解决方案。 这与华为的手机商业模式很像，不卖裸片，硬件开放程度相对较低。但是在软件合作模式能够提供系统级开放接口，方便合作伙伴整合自己的算法到设备中。 这种合作模式开放程度具有一定的局限性，但是一定程度上能够增加华为对于硬件的控制力。 而对于合作伙伴而言，则有利有弊。 一方面华为 MDC 将自动驾驶开发中最难的功能安全与芯片算力问题给解决了，让客户可以集中精力在智能驾驶算法的开发上面，能够更快实现方案的量产与落地应用。 另一方面，客户也只能够在华为 MDC 所限制的平台上进行开发，话语权与灵活性都会相应削弱。 个中利弊，关键就看如何权衡了。 整体来说，在测试华为 MDC300 的过程中，我是非常自豪的，即使我们用最高标准来审视这款硬件平台，即使我们用全世界最先进的硬件来做对标，它依然有很好的竞争力和量产可用性。 这也让我更加坚定了对中国自主知识产权的芯片和系统的信心，更加对整车级的技术自主可控充满期待。 我相信，很快就会有搭载强大中国芯的智能驾驶汽车成为市场的佼佼者，以华为为代表的中国科技力量，会在世界的产业舞台上，一直熠熠发光。 往期回顾： 字节跳动入局车联网，互联网应用上车要解决哪些难点？ 为什么欧美车企纷纷放弃L3，而中国车企热衷量产L3？ 传统车企为什么造不出Autopilot，特斯拉L4战略存在什么风险？ 为什么实现车路协同比造一辆特斯拉还难？ 本期制作 主讲：郭继舜 监制：王德芙 编辑：叶方 后期：陆非 设计：陈溪阳 运营：林芝芝 音频平台 喜马拉雅 | 蜻蜓 FM | 听伴 Podcasts | 小鹅通 在以上平台搜索关注汽车之心 即可收听全部节目 华为MDC：中国的自动驾驶大脑是怎么炼成的？ 解密华为智能汽车芯片版图 华为徐直军：全球不缺汽车制造商，缺的是部件和技术提供商

12. 

    27 May 2020

    006 | 字节跳动入局车联网，互联网应用上车要解决哪些难点？

    编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，每周一至周五更新，每日一期，内容独家授权汽车之心发布。 今天这篇新闻解读的新闻源，是来自 36 氪的独家消息。（来源：字节跳动进军车联网，锤子团队将负责抖音上车 https://36kr.com/p/708910060362244）这篇报道的作者是我的一位朋友：李勤老师，我在此向他表示衷心的感谢。 这篇报道的作者是我的一位朋友：李勤老师，我在此向他表示衷心的感谢。 报道中提到，抖音和今日头条的母公司「字节跳动」正悄然组建车联网团队，计划推出自己的车载信息娱乐系统方案，实现旗下抖音、今日头条等移动互联网产品在汽车终端的落地。 字节跳动内部研究过各种车联网路线，目前的策略是想先试水抖音视频等内容上车。而车联网产品的技术实施团队，来自字节跳动早些时候收购的锤子科技。 对于上述信息，字节跳动方面回应：消息属实，他们确实正在做一些探索，满足车载场景的用户体验。 今天，我们就来聊聊互联网公司在汽车领域布局的这个行业趋势。 首先，互联网公司进军车联网领域并不是新鲜事。 在字节跳动之前，腾讯、阿里和百度都已经面向车联网行业做了深度布局。 阿里旗下有高德地图、斑马网络和天猫精灵等车联网业务线。 腾讯也推出了车载微信，并结合小程序、腾讯语音、腾讯地图和腾讯音乐等服务，和车企联合打造车联网生态解决方案。 百度也基于 DuerOS 推出了小度车载 OS 系统。他们在汽车行业内掀起了一股「互联网风潮」。 在桌面互联网、移动互联网等等传统流量入口资源已经被瓜分殆尽，而高级别自动驾驶开发如火如荼的大背景下，车联网作为一个新兴的流量入口，可以在未来让用户更轻松地享受汽车这个除了家、公司之外的第三空间。 虽然，互联网公司与车企因为市场、技术、人员构成的差异，不论是思维方式、工作流程还是产业链布局、用户使用场景等都很不相同。 这一点，我从互联网公司到车企的初期，感触是非常深刻的。但是，这些都架不住一句「用户有需求」。 有需求就有市场，有市场就能催生企业甚至行业级别的大力投入。 近年来，在车联网大热的趋势引领下，不少车企纷纷与互联网公司合作，通过组建公司、战略合作、资本投入等形式来把握住自己在车联网方面的企业技术优势。 比如：比亚迪宣布和 360 达成战略合作、双方将在车联网、汽车信息安全解决方案、移动互联、IOT、大数据及 AI 等领域整合相关资源。 腾讯与宝马签署了战略合作备忘录，双方将在智慧出行展开合作，还计划探讨在信息娱乐和服务等其他领域的合作机会。 百度与戴姆勒宣布在自动驾驶和车联网等领域深化战略合作，未来双方将启动一项全新的车联网领域合作项目，百度车联网技术将搭载在梅赛德斯-奔驰的智能人机交互系统中。 相较于互联网企业，车企在整车开发、座舱集成、车辆控制、车辆安全等方面有不可替代的优势。同时，对车辆用户的需求与使用场景都有丰富的经验。 但弱点也很明显，由于车辆开发流程、法规、安全考量等方面的的限制，加上人才知识结构更偏向复杂系统集成和工业制造，车企工程师在代码实现、快速迭代思维和能力方面较之互联网速度稍显落后。 而互联网公司在迭代速度方面表现突出，同时坐拥庞大的生态布局和用户资源，在丰富用户场景、优化用户体验、提升用户粘性等方面能为车企带来思维层面的颠覆性提升。 但，互联网公司不掌握硬件终端，在车规级软硬件集成方面能力和经验尚浅。 很多车企基于更好地整合系统的考虑，选择自己组建软件团队进行开发，由车企来整合行业资源，以车企，而不是互联网公司为中心，组建软件生态圈。 这是为什么大众在欧洲组建了软件中心，现在团队规模已经超过了 5000 人，还在满世界寻找开发汽车软件的工程师。 就我一个在保时捷德国总部做技术研发的朋友透露，大众软件团队的目标是 1 万人。 即使现在大众的 vw.os 因为技术难度太大，进展不太顺利，但车企想要通过软件提升下一代汽车的科技含量和用户体验的决心可见一斑。 软件定义汽车，这是这段时间业内经常被提及的理念，正在快速而深刻地改变汽车行业。我们在后续的音频里可以找机会聊聊软件定义汽车。 现阶段，车企与互联网公司的合作，能更好地发挥出各自的优势，达到跨产业融合，形成更好的产品，同时也让用户从各种层面受益。 车联网市场前景可期，但当前阶段互联网公司与车企合作后，也会面临一些亟待解决的难题，我在这里总结了 4 点： 1. 互联网公司对汽车市场的切入本质上仍是其各自线上业务的延伸，其切入的形式与手段受限于各自的独有的基因。 互联网公司目前主要通过几种形式切入汽车市场： （1）开发 OS 操作系统，作为车企的供应商提供车机操作系统。例如：阿里旗下的 AliOS、百度的小度车载 OS。 （2）集成自身生态资源，以超级 APP 的形式植入车机。主动放弃与车厂竞争 OS 的开发权，例如：苹果的 CarPlay。 （3）用户通过 USB 连接手机后可使用超级 APP 体系内生态应用。但需要在车机端和手机端进行一系列设置，操作较为繁琐。 在如今车辆可通过 3G/4G 连网之后点开屏幕即可享受网络应用的便利情况下，这种超级 APP 已不具有明显优势。 以单个 APP 的形式提供生态服务，把用户手机上的使用习惯延伸到车上，例如：腾讯的微信上车、高德的车载地图。 根据车上用户使用习惯和特定的使用场景，利用自身生态优势，为车端用户定制化开发车上使用产品。 2.软件如果想要实现持续迭代，平台化延续，软硬件解耦是前提。 车企的整车开发流程比较长，一个车型的开发周期往往 2 年到 5 年不等，整车的零件选型需要考虑车规要求、功能安全、行业标准、反复验证等因素。 车企呢，往往倾向于定义一个属于自己的硬件平台，在芯片、架构等方面还要考虑硬件可迭代，以延长硬件平台的生命周期。 所以让不同的车企去为软件和系统适配硬件是非常困难的。互联网公司如果想要合作更多的车企来实现规模化的生态协同效应，一定要注意实现软件和硬件的充分解耦，尽量提升软件的通用性。 比如说，某个 OS 系统，能够在高通的 820A、8155 平台上运行得非常顺畅，也要考虑在恩智浦、瑞萨的硬件上运行，尽量地软硬件解耦。 同时，在 OTA 升级变得越来越重要的今天，软件的迭代升级要充分考虑不同级别硬件的流畅性和兼容性。这个我们可以看看斑马花了多大经历在构建 OS 系统的通用性就知道其重要性了。 3. 如何保证驾驶安全的第一原则。 安全永远是车辆用户的第一刚需，字节跳动等互联网公司的软件生态服务需要在确保行车安全的情况下进行。在 L4 自动驾驶还没有完全到来之前，用户是为车辆安全负责的第一法律主体。 音乐、视频、新闻以及其他 LBS（location based service）服务在车上的呈现形式、切入时间、使用场景都需要以避免影响驾驶安全为第一原则。 这需要功能设计工程师、功能安全工程师、互联网产品设计工程师团队进行深度合作，以安全为前提，研究用户场景，打磨功能。 4. 非刚需的应用，如何保证用户使用率。 用户在手机上使用影音娱乐 APP 的习惯已根植大脑，车机端的娱乐信息服务并不是用户的刚需，至少需要花时间培养用户的使用习惯。 当前阶段，娱乐信息服务在车端使用率仍然很低，车端服务需根据车端特殊的使用场景、车端特殊的安全考量、车端用户特殊的需求进行定制开发，而不能是简单的功能堆砌。 车端入口作为一个十分特殊的流量入口，非刚需的生态服务如何提高用户的活跃度，如何整合使用率是车联网产品需要考虑的重要因素。 在如今「互联网+」概念整合各大行业的形势下，汽车行业的变化、合作、竞争都是必经的良性发展过程。 新技术的应用、跨行业的碰撞，带来产业的深刻变革，也是我辈躬身入局的良好契机。 以字节跳动为代表的互联网公司，充分利用自身的优势，切入汽车行业，车企是抱着开放合作，各自发挥优势的态度的。 以上提到的这些问题，也会在合作过程中逐渐解决。 我看好互联网行业和汽车企业的合作，毕竟所有的成功都源于大胆的尝试。 往期回顾： 为什么欧美车企纷纷放弃L3，而中国车企热衷量产L3？ 传统车企为什么造不出Autopilot，特斯拉L4战略存在什么风险？ 为什么实现车路协同比造一辆特斯拉还难？ 本期制作 主讲：郭继舜 监制：王德芙 编辑：叶方 后期：陆非 设计：陈溪阳 运营：林芝芝 音频平台 喜马拉雅 | 蜻蜓 FM | 听伴 Podcasts | 小鹅通 在以上平台搜索关注汽车之心 即可收听全部节目

13. 

    25 May 2020

    005 | 为什么欧美车企纷纷放弃L3，而中国车企热衷量产L3？

    编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，内容独家授权汽车之心发布。 今天，我们来聊聊高级别智能驾驶量产中的一个热点问题，L3 智能驾驶到底该不该放弃。 近日，以 Automotive News 为代表的部分外国媒体报道： 为了避免 L3 在 SAE（即美国汽车工程师协会）所推出的智能驾驶分级标准中的尴尬定位和自动驾驶的问责机制，有不少车企在这段时间干脆直接放弃了 L3，更加关注 L2、L2+功能的舒适感、成熟度和人机交互。 同时，这些车企将更多的精力放在更高级别自动驾驶，也就是 L4 级系统的研发中。 除了我们已知的 Waymo、Cruise 等科技公司采用变革式的技术路线外，奥迪、福特、丰田、沃尔沃等主流车企先后宣布放弃 L3，直接跳跃至研发 L4 级完全自动驾驶功能。 而电动汽车领域的标杆特斯拉，自始至终没有表达过要发展 L3 自动驾驶，而是从 L2，L2+功能的 Autopilot 直奔 L4 而去。 （注：我们在上周的音频里介绍过相关信息：传统车企为什么造不出Autopilot，特斯拉L4战略存在什么风险？） 说了这么多，我们还是要明确一下智能驾驶的分级概念。 我尝试用最简单易于理解的方式来向大家解释，相信你听一遍就对复杂的智能驾驶分级有明晰的了解。 智能驾驶系统在 SAE 中共有 6 个分级，分别是 L0 到 L5。 L0：你可以理解为所有的信息预警功能，但不直接控制车辆的功能； L1：系统能够控制车辆，但是只能在横向或纵向中的一个单一维度控制车辆，比如我们非常熟悉的 ACC（自适应巡航），LKA（车道保持），AEB（紧急制动）等功能。 需要说明的是，除了 AEB 是在任何工况下都要激活外，其他的功能仅限制在高速公路上使用。 L2：系统对车辆的横向控制和纵向控制做了耦合，出现了 TJA（高速公路拥堵功能）、HWA（高速公路辅助功能） 等功能，系统第一次将制动系统 ESP 和转向系统 EPS 协同控制。 在这个级别，需要驾驶员的眼睛时刻直视前方观察路面状况，同时双手要时刻握在方向盘上准备随时接管车辆。 现阶段大家如果去 4S 店买车，2019 年以后推出的新车型的顶配版，基本都具备L2 级功能； L2+：可以理解为从 L2 到 L3 的一个中间状态。 L2+有两个不同的路径： 一是以特斯拉为代表的路径：依然需要驾驶员将双手放在方向盘上，但通过 OTA 升级的方式拓展更多的功能； 另一个路径是老牌的 OEM，如沃尔沃，宝马等车企所坚持的 L2+的方案：在没有系统冗余的情况下，允许用户解放双手，长时间不用将手放在方向盘上，但驾驶员的眼睛依然要直视前方。 在 2020 年下半年到 2021 年上半年，在不少车企新车型的顶配版本中，将可以看到 L2+这样的脱手功能量产。 接下来讲今天的重点——L3。 注：图为长安 L3 自动驾驶演示 这一级别的自动驾驶更多的解放人们的感官：双手可以不用双方放在方向盘上，双脚也不用长时间踩着踏板，眼睛也可以不用长时间直视前方，不用将注意力长时间放在路况上。 这里有两点需要专门提出来： 第一，从 L3 开始，智能驾驶状态下的交通结果责任主体由驾驶员变为了车辆。换句话说，智能汽车需要为智能驾驶状态下的交通事故负责； 第二，L3 是所有级别中唯一一个需要人类驾驶员和智能驾驶系统频繁交接车辆的控制权的系统。 说到 L4，我们终于可以把它叫自动驾驶系统了。L4 自动驾驶的驾驶位可以不坐人，同时行驶工况也扩展到了城市道路。 在不远的将来，我们可以在城市中像使用滴滴一样地打到一辆没有司机的 RoboTaxi，这就属于 L4 级别技术的商业化应用。 业界一个普遍的观点是，在 2023-2025 年期间，RoboTaxi 会有区域性的商业化运营落地。 最高级别 L5，把车辆行驶的场景从高速公路、城市道路进一步扩展到了没有车道线、交通标志牌的乡村道路，戈壁沙漠，飞扬的土路等。 这对于车辆的感知、规划、决策、控制算法等都是巨大的挑战。这也是我们智能驾驶领域不懈追求的终极目标。 好了，经过以上介绍，我们可以总结出，L3 智能驾驶若干个核心点： 1.L3 以上的智能驾驶系统，在智能驾驶状态下，为交通结果负责的主体，已经从驾驶员变为了车辆； 2.L3 智能驾驶系统，允许驾驶员解放双手、双脚、双眼，重要的是，还有注意力。只要不完全丧失注意力，驾驶员具备在 10 秒中内接管车辆的能力，都是符合 L3 系统要求。 这就意味着，驾驶员在高速公路上看手机、回微信、追电影，甚至是开一局吃鸡游戏都是可行的，只要你不睡着，只要你有能力在车辆报警提醒十秒钟内接管车辆就行； 3.L3 需要驾驶员和智能汽车频繁地交换车辆的控制权，这个人机交互的过程非常复杂，充满偶然性。 4.L3 需要车辆系统有足够好的稳定性和安全性； 5.L3 智能驾驶系统能够对车辆当前的状况进行诊断和预测。 奥迪研发部门负责人汉斯最近在接受《Automotive News Europe》采访时表示「奥迪将不会在全球范围内为现款 A8 引入 TJP 功能。」这意味着奥迪不会在 A8 这款车型上搭载 L3 级别自动驾驶系统了。 奥迪放弃在 A8 车型引入 L3 级自动驾驶，原因有三个： 其一，从技术层面来说，现阶段的智能驾驶算法还不足够在所有的高速公路场景保证 100% 的安全，还需要进行更多的优化和升级。 其二，从监管角度看，目前还没有适用于 L3 级自动驾驶汽车的法律框架。另外，全球范围内的 L3 级量产车，各个国家会有不同的法规政策的限制； 其三，L3 频繁复杂的人机切换模式让工程师们感到力不从心。 就连福特北美总裁 Raj Nair 也表示：「我们放弃驾驶辅助技术的过渡阶段，决定直接提供 L4 级别全自动驾驶的车辆，原因是不知道在 L3 级别如何从机械操控切换到人工操控。」 但在国内，包括长安、东风、广汽新能源、一汽红旗、长城、吉利、小鹏、威马在内的中国整车厂商，均计划推出 L3 量产车型。 为什么？原因有以下几个： 1. 相比于欧美的消费者，中国民众对于智能化、智能驾驶系统的接受程度更高，也更愿意尝试新的系统和新的功能； 2. 相比于欧美，我国政府在法规政策层面，对高级别智能驾驶量产有更好的支持。 据行业内消息，工信部等部委正在制定高级别智能驾驶量产的准入标准，该标准会在近期向公众发布。这意味着高级别智能驾驶特别是当前的 L3 功能的应用有了政策和法规的支撑； 3. 中国的新基础设施建设，能够为未来的车路协同 V2X 应用提供强有力的路端保障，这是欧美的车企享受不到的真切的基础设施支持。 V2X 车路协同技术的使用，能为 L3 为代表的智能驾驶技术带来数倍的安全性能提升； 4. 中国车企的研发实力，特别是智能驾驶系统的设计实力，在近年来不断增强，已经具备了设计和推动复杂系统大规模应用的能力； 5. 相比于部分南欧国家、美国中部地区，中国的高速公路较好的路况更适合智能驾驶技术的落地应用； 6. 中国汽车产业的上下游产业链也逐步完整，中国企业在智能驾驶关键零部件上的自主研发水平提升，也为 L3 智能驾驶的落地提供了必不可少的核心技术。 智能驾驶技术的发展本身就是充满了艰辛的探索之旅，以上提到的关键技术、核心难题，都需要通过逐渐迭代的方式来解决。 从整车的系统角度，L3 所遇到的技术问题，几乎是无法逃避的。 相信通过这两年的不断努力，中国制造的 L3 智能驾驶汽车，会成为中国智能工业发展的标志。 我们坚定地继续研发 L3为什么，不是因为它简单，而是因为正确。 相关阅读：广汽研究院郭继舜：智能驾驶量产的困难与希望 | 行家说 本期制作 主讲：郭继舜 监制：王德芙 编辑：叶方 后期：陆非 设计：陈溪阳 运营：林芝芝 音频平台 喜马拉雅 | 蜻蜓 FM | 听伴 Podcasts | 小鹅通 在以上平台搜索关注汽车之心 即可收听全部节目

14. 

    23 May 2020

    004 | 传统车企为什么造不出Autopilot，特斯拉L4战略存在什么风险？

    编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，每周一至周五更新，每日一期，内容独家授权汽车之心发布。 今天的新闻解读，我们聊聊特斯拉的完全自动驾驶。 2020 年 5 月 18 日，特斯拉 CEO 埃隆·马斯克（Elon Musk）在推特上宣布： 「特斯拉的完全自动驾驶能力（FSD）将在 7 月 1 日后的全球市场中再次涨价 1000 美元」。 此次涨价后，特斯拉 FSD 功能的价格将达到 8000 美元（约合人民币 5.6 万元）。 后续，马斯克在周一的一系列推文中又说道： 「随着软件在获得监管部门批准后接近完全自动驾驶功能，FSD 价格将继续上涨。到那个时候，FSD 的价值可能超过 10 万美元。」 上述新闻提到的 FSD 是特斯拉推出的完全自动驾驶选装功能，即 Full Self-Driving 的缩写，相比于特斯拉当前的 Autopilot 功能，FSD 的功能更加先进。 根据官网资料显示，FSD 能够实现自动泊车、高速公路自动辅助变道、自动辅助导航驾驶、停车场智能召唤、即将推出的识别停车信号灯和停车标志并作出反应以及在城市街道中自动辅助驾驶等功能。 今天，我们来讲讲 Elon Musk 的 L4 级别自动驾驶功能 FSD。 去年（2019 年），Elon Musk 在推特上宣布，即将通过 OTA 升级的方式，将 100 万辆量产的特斯拉车辆变成 RoboTaxi 自动驾驶出租车，并在今年（2020 年) 打造一个拥有 100 万辆车的 Robotaxi 网络。 具体方案就是：特斯拉将会打造一个类似 Uber、滴滴的智能手机应用，用户可以通过该应用呼叫 RoboTaxi 自动驾驶出租车服务，而这个网络中的车辆则来自于加入这个 RoboTaxi 网络的特斯拉 FSD 车辆的车主。 车主可以指定一天中他们希望自己的车辆加入服务网络的时间，使车辆可以在空闲时间提供 RoboTaxi 服务供其他用户使用，车主可以从中赚钱。 有机构预测，如果不考虑运营成本，自动驾驶汽车每年可以为车主带来 1 万美元的收入，能够帮车主很快还清购车成本，并且带来额外的持续收入。 另一方面，在技术落地应用方面，特斯拉又要把 L4 无人驾驶分成三步落地： 第一步，推出完整的自动驾驶功能软件，实现从 A 点到 B 点的全自动驾驶。 但是，这个过程还需要人类驾驶员监管，同时通过车内虚拟游戏让车主帮忙生产更多标注数据。 第二步，通过自动驾驶出租车网络即 Tesla Network，尝试取消人类驾驶员的监管。 通过自动驾驶实现车辆调度与共享，并通过保险与分成协议等等方式，重新划分特斯拉与车主之间的权责与收益分成。 根据国外咨询机构 ARK Invest 的测算，从 2022 年开始，到 2026 年，特斯拉可以实现 Robotaxi 网络车队规模达到 275 万辆，产生 920 亿美元的收入和 310 亿美元的利润，而车主总共可以获得 210 亿美元的收入。 这对车主无疑是非常具有吸引力的。当然前提是 FSD 的自动驾驶性能真的能够达到特斯拉所宣称的水平，并且解决了相关的法律法规等风险。 第三步，完全去除人类驾驶员。 通过完全自动驾驶功能提供完整的 RoboTaxi 服务。但是马斯克也强调：这个功能也只能够在小部分地区实现。 在现阶段看起来，这个目标更多的是马斯克动员消费者购买特斯拉的一个口号。 那么，对于特斯拉上述全自动驾驶功能以及应用规划，是否真的能够实现？ 对此，我的观点是谨慎乐观。 首先，基于现阶段特斯拉的摄像头加毫米波雷达，不使用激光雷达的传感器组合方式开发 L4 全自动驾驶是非常困难的。 虽然特斯拉现在研发新的芯片和算法，但我们从传统汽车所强调的功能安全分析看，特斯拉的感知系统是不能达到 L4 全自动驾驶所需的 ASIL-D 级别功能安全要求的。 一个自动驾驶系统要达到 ASIL-D 安全等级，需要让传感器在任意时候都要有足够的异构冗余能力。 在自动驾驶车辆的前向和后向，尤其在前向的区域，需要至少有三个异构冗余传感器进行感知覆盖，以保证系统的数据来源具备互补性，同时设备的故障来源没有相关性，以及一定的失效容错能力。 而特斯拉使用同构的摄像头加上毫米波雷达，可能造成某种类型的传感器同时失效，或者失效后没有足够的容错处理能力。 因此需要增加另外一个维度的传感器（实现直接的空间位置测量）——激光雷达。 由于 L4 自动驾驶没有安全员，车辆完全自主控制，据我的分析，感知系统需要让车身周围的 360 度范围内都能够达到 ASIL-D 的安全级别（对比 L3 自动驾驶，只要求前向区域的感知安全等级达到 ASIL-D）。 为了达到这样的安全级别，我们更加看好近期推出的混合固态激光雷达，部署在车身四周，实现 360 度的三相冗余感知覆盖。 至于固态激光雷达是否能够通过车规级别认证，这可以交给时间去解决。 总而言之，对自动驾驶传感器的布置，在现阶段——其实不是摄像头多少的问题，而是一个传感器的信息结构是否是足够完备与合理。 其次，通过 OTA 升级的方式来进行 RoboTaxi 功能升级，这个事情还是存在一定的风险。 必须得承认，特斯拉这种先建硬件基础，后建行业生态，最后升级软件的方式，是目前实现自动驾驶最具想象力与可行性的一种方式。 但其中最大薄弱环节，也是最大的风险——是特斯拉的车辆平台与硬件基础是否能够承载后续的功能需求，以及如何保证升级功能的正确性与可靠性。 我们先说 OTA 本身可能存在的风险。 汽车不同于手机，是一个全面而复杂的系统，由于其中电子部分需要升级的节点比较多，升级的数据量比较大，在升级过程中可能出现的数据错误是可能存在的，即使有一定的校验机制也不能够完全排除这种可能性。这是第一个风险。 另外一个风险是，当车辆终端的数量大到一定的数量级的时候： 针对车辆的差异性的调教与适配需要投入更多的工作量，而且这也是一个非常需要经验的工作； 是否可以通过一个通用化的 OTA 版本，推送升级实现全车型的适配，也将是一个非常具有挑战性的工作。 针对车辆平台与硬件平台功能的承载能力上，前面已经分析感知系统可能存在失效风险以及可能导致的严重后果，这已经被现实的事故验证过了。 事实证明，不解决数据来源异构与冗余的问题，上述系统的漏洞与风险是无法避免的。 除了感知系统以外，对于特斯拉车辆的其他系统方面是否具有类似的风险呢？ 根据我的分析，这的确是存在的。 据我所知，特斯拉是没有做系统冗余的。它的电源部分，车辆转向和制动系统是没有冗余的。 当然我们又回到了功能安全分析。 以这样的系统去做 RoboTaxi 可能会出现失效的情况。尤其是取消安全员以后，乘客坐在后排，在短时间是没有办法去接管车辆的，存在较大的风险。 当然我们相信特斯拉有足够优秀的营销团队与法务团队将这些风险可能造成的后果很好地解决掉，这也是在过去的事实中被证明的。 前面我们讨论的是特斯拉的 L4 RoboTaxi 战略，但是不可否认特斯拉现阶段的自动驾驶系统 AutoPilot 是做得非常非常好的，有很好的用户体验性，以及可延展的能力（通过 OTA 实现）。 那么我们需要反思的一点是什么呢？特斯拉这套自动驾驶系统，戴姆勒、宝马每年投入那么多的经费，真的做不出来吗？ 我觉得，还是因为在软件定义汽车的环境下，大家的思路与出发点不一样。 首先，传统 OEM，尤其是老牌的欧系车厂，还是以功能安全分析作为主要的思考方向来设计汽车。 这个过程就存在一个问题：如果所有的设计都是基于功能安全分析来探讨，没有功能安全冗余的时候，我们就不能够让车具有更好的自主性。 这也由此造成的一系列的限制，包括他们整体打破现有的 EEA 架构去做域控制器，而更多去做 ECU 的叠加。 这样就会造成一个困境：很难会有一个思想的解放或者是一个功能的长远规划，结果就是，只能够被特斯拉这样的新造车势力远远甩在身后，直到在高级自动驾驶阶段，大家再次站在功能安全这一个终极考核面前。 其次，传统的汽车工业都是成本导向、盈利导向的，一切都要做到刚刚好，不考虑后续的预留空间，就如同诺基亚之于手机。 但是在面临苹果、特斯拉这样的新兴挑战者的竞争时，往往就会后继乏力。这就是思路的不一样。 另外一方面，我们要思考一个问题：到底我们是否要真的基于 ISO 26262 或者 21448 这样的功能安全分析作为我们完成车辆设计最主要的红线？ 现在看起来，用户们更加期望的是，或者说用户体验更好的就是通过 OTA 这样的方式来升级，在系统性能不稳定的时候，我们可以先去测试，先去收集大量的数据，然后再不断升级，持续迭代，交付中间的成果与产品，往往能够在竞争中抢占先机。 但是这与我们传统意义上 OEM 做的那种：足够完美的最终系统产品的方式是相悖的。 那么，我们在未来是不是需要去转变？这是我们要思考的一个战略性问题。 我们能够看到的是，至少像大众，组建了一个软件团队来去研发平台化的软件系统。他们现在就处在从传统化 OEM 开发方式向新一代 OEM 开发方式转变。 这样一个路径是值得我们思考和学习的。 本期制作 主讲：郭继舜 监制：王德芙 编辑：叶方 后期：陆非 设计：陈溪阳 运营：林芝芝 音频平台 喜马拉雅 | 蜻蜓 FM | 听伴 Podcasts | 小鹅通 在以上平台搜索关注汽车之心 即可收听全部节目

15. 

    20 May 2020

    003 | 为什么实现车路协同有时比造一辆特斯拉还难？

    编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由广汽研究院智能驾驶技术部部长，广汽 L3/L4 无人驾驶技术总监郭继舜博士与汽车之心联合出品，每周一至周五更新，每日一期，内容独家授权汽车之心发布。 今天的汽车科技解读，我们来聊聊 5G 和 V2X。 5G 在智能交通和智能城市上的应用正变得炙手可热。 前段时间，上海发布新基建行动方案，首批重大项目 3 年投资 2700 亿元。 其中，洋山港「5G 自动驾驶重卡」项目已经在 2019 年成功开展示范运营。 今年 4 月 20 号，江苏省交通运输厅公布《江苏省智能交通建设实施方案》，到 2022 年，江苏建成一批智慧交通基础设施试点示范工程并加快推广；完成南京、苏州等一批智慧公交试点，全面实现 5G 在南京禄口机场等重要交通枢纽的覆盖与应用。 本月，2020 年 5 月 8 日上午，广州举办首批数字新基建重大项目签约及揭牌活动。73 个总投资规模约 1800 亿元的重大数字新基建项目集中签约、揭牌。 其中，南沙区签约的 18 个新基建项目建成后，将成为粤港澳大湾区首个全自动化码头和全国 5G 应用示范工程。 回到智能驾驶的角度来看 5G。 今年 2 月份，发改委、科技部、工信部等十一部委联合发布了《智能汽车创新发展战略》，战略中较为明确地把车路协同、C-V2X 作为我国智能汽车发展的重要技术方向之一。 前些天，2020 年 5 月 6 号，交通运输部发布了《关于深入推进公路工程技术创新工作的意见（征求意见稿）》，新基础设施建设成为大交通行业炙手可热的话题，BIM 信息化技术、人工智能、智能感知、5G 通信、路端传感器、车路协同和边缘计算等技术。 以我工作的广汽研究院为例，我们在 2018 年年底部署了三大运营商的 5G 试验网，实现了实时远程驾驶、车路协同无人驾驶典型工况等技术内容。 前两年省市区领导来交流指导工作，主要关注的是智能驾驶的量产技术、L4 无人驾驶的示范运营政策支持等，但今年调研的重点就是 5G 的智能驾驶应用。 政策的支持对于一个技术的发展是非常重要的，所以我非常坚定地认为，中国 5G V2X 一定会走出自己的特色。 5G 技术大家都比较熟悉了，经过这段时间的媒体信息轰炸，我们基本都能说出 5G 的一些技术特点，大带宽、低时延、高可靠性、多并发数。 相较于 4G，5G 具有更高的网络速率，峰值网络速率可达到 10Gbps，网络传输速度比 4G 快 10-100 倍。 智能驾驶的更多非结构化信息可以利用大带宽这个特点进行实时传输。 5G 还有更低的网络延迟，空口时延理论值从 4G 的 50 毫秒缩短到了 1 毫秒，当然，现阶段因为和 4G 共用了主干网，会对整体的信号延迟率有影响。 测试现阶段在我们研究院部署的 5G 试验网的空口时延在 20-30 毫秒，初步能满足研发的需求。 体现 5G 大带宽和低时延的典型应用是远程驾驶，驾驶者使用 5G 网络传输车载高清摄像头画面，实时操纵一辆远在千里的车辆。 这个地方我要专门强调一下，并不是 4G LTE-V 网络不能做信息的传输，只是由于时延等性能限制，我们现在基于 LTE-V 网络的研发主要还是集中在车辆信息预警上，真正要操作车辆行驶，5G 网络才能满足一系列严苛的信息传输要求。 高可靠性就使得信息传输在量产车型上更容易满足车规和功能安全的要求，多并发数让单车智能能够扩展为超大规模的群体智慧的智能汽车集群，这个很像蜂群或者蚁群。 简单地说完 5G，再跟大家聊聊车路协同。 车路协同，简单理解就是智慧的车+聪明的路。在路端部署多种传感器设备，摄像头、毫米波雷达、激光雷达等。车路协同和智能驾驶所使用的车载传感器是同构的。 将路上的信息结构化之后，把信息传输到边缘计算端、云端和附近的车上。车路协同， 在解决方案上被称为 V2X，包括车对车（V2V），车对路/基础设施（V2I），车对云（V2N），以及车对人（V2P）等四类。 某种程度上，由于各方参与者身份的多样性及工程的复杂性，远远超过想象，车路协同的实现难度甚至比造一辆 L4 级无人车的难度还要大，至少比造一辆特斯拉难多了。 换句话说，当商业产品与交通基础设施发生了业务碰撞，就变得异常严肃和不那么性感了。 譬如，在我们向一些无人驾驶公司与车联网软件公司提及「车路协同」这个概念时，他们的第一反应往往是「这应该是政府牵头主导的事情」，或是「网络运营商是不是应该承担更多责任」。甚至是——「为什么这个好几年的老掉牙的话题，又一次被重拾起来了？」 这个老话题有另一段故事，就是美国政府搞了 20 年的 DSRC，我们后续有机会可以好好讲讲。 一般来说，车路协同主要涉及三个端口：车端、路端和云端。 其中路端和云端因为车路协同环境下计算节点下沉至边缘层，也就是经常说的部署在路上的边缘计算单元。 再考虑到三个端口间信息传输渠道的重要性，对于车路协同系统平台是由以下三个核心部分组成： 智能车载系统(车端)、智能路侧系统 (路端+云端) 和通信平台。 其中，智能车载系统负责车载端的海量数据实时处理和多传感器数据融合，保证车辆在各种复杂的情况下稳定、安全行驶； 智能路侧系统负责路况信息搜集与边缘侧计算，完成对路况的数字化感知和就近云端算力部署； 通信平台负责提供车-车、车-路间实时传输的信息管道，通过低延时、高可靠、快速接入的网络环境，我们现在使用的就是 5G 网络，保障车端与路侧端的信息实时交互。 三者恰好构成智慧交通场景下协同感知与协同决策的闭环。 为什么智能驾驶需要车路协同呢？ 第一个原因，车载传感器视距比较短，往往只有 200 米，遮挡、恶劣天气等对于单车传感器感知能力影响明显。 「单车视角」不如「车+感知基站的上帝全知视角」更快更全面地感知到路面异常情况。 其实也可以这么理解： 单车采集到的数据量、数据类别以及数据质量，要远远逊色于车与路况信息打通后的数据。而反过来看，多样化数据对于单车自动驾驶软件与高精地图质量的进一步优化，也有重要的推动作用。 第二个原因，如果未来路段设施健全了，那些相对昂贵的车载传感器可以去掉，用相对简单的车载传感器实现基本安全，用路端传感器和边缘计算实现智能性。这样能极大降低智能汽车的普及成本。 第三，刚才讲到了，单车智能容易陷入局部最优，群体智慧的实现才能使全局效率最大化。举两个例子，在高速公路上行驶的重卡，如果能够实现编队行驶，编队后部的车辆由于风阻减小，能够节省最高 16% 的燃油消耗。 我们曾经做过仿真，如果在十字路口实现车路协同技术，十字路口的通过能力将提高至少 3.8 倍。 当然，车路协同技术也不乏反对者。 譬如无人驾驶技术领域毋庸置疑的领袖级公司——Waymo 的现任 CEO John Krafcik 就曾在一次汽车论坛上直率而又不失礼貌地表达了对 V2X 的拒绝态度： 「虽然我们挺喜欢 V2X 或 V2V 的这些想法，这对我们很有帮助。但是如果你依赖 V2X，你就不可能拥有一辆真正的自动驾驶汽车。要等待的时间太长了，我们真的不依赖外部基础设施来让车完成周游世界的使命。」 欧美大多数企业还是坚持单车智能的技术路线，其背后原因，更多是对欧美政府进行基础设施建设的效率没信心。 我们不否认，围绕车路协同的新基础设施建设确实需要投入大量的人力物力和社会资源，短时间内的商业模式也在探索，路端设备逐渐完善也是一个长期的事情。 我的理解，我们可以分三步逐渐完成路端的建设和应用。 未来一到两年，在关键的十字路口、丁字路口、环岛建设路端传感器和边缘计算单元，实现对人类驾驶员的信息预警功能，初步提升关键交通路段的通过能力； 未来三到五年，在关键的十字路口、丁字路口、环岛使用 5G 网络加上完备的路端传感器，实现对关键路段车辆的协同控制，实现关键交通路段的局部智能驾驶； 未来十年，实现在高速公路、城市道路的网络部署，传感器部署，边缘计算单元部署，实现全交通场景的车路协同。 对于车路协同，我们用一句话作总结：实现车路协同，特别是涉及到基础设施的改造，仍然必须是一场由政府主导的交通大变革。 在中国做这件事有中国的特色，各级执行力都特别强，我们会走出一条更安全稳定的智能驾驶之路。 往期回顾： 如何看待硅谷自动驾驶独角兽Cruise、Zoox纷纷裁员？| 郭继舜带你读汽车科技 英伟达为自动驾驶引入了性能怪兽？| 郭继舜带你读汽车科技 关于主讲人郭继舜博士：高级工程师，广汽研究院智能驾驶技术部部长，广汽 L3/L4 无人驾驶技术总监。 中国电子科技大学本科，台湾清华大学、苏黎世联邦理工学院硕士，斯坦福大学博士。加入广汽研究院前，先后在 Google X-Lab，EMC2 中国研究院，百度深度学习研究院从事人工智能技术研发，2017 年广州市高层次引进人才。 ACM/ICIP 亚洲区金牌，日本文部科学省学者奖，Erasmus Mundus 全额奖学金，海峡两岸杰出学者奖等。先后主持和参与 973 国家重点基础研究项目、国家重大基础研究专项、教育部新世纪优秀人才项目等，在 CVPR，ICCV，IJCAI 等国内外顶级期刊和会议上先后发表论文二十余篇，获得中美发明专利共 32 项。 本期制作 主讲：郭继舜 监制：王德芙 编辑：叶方 后期：陆非 设计：陈溪阳 运营：林芝芝

16. 

    19 May 2020

    002 | 自动驾驶行业为何出现了裁员潮？

    编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由广汽研究院智能驾驶技术部部长，广汽 L3/L4 无人驾驶技术总监郭继舜博士与汽车之心联合出品，每周一至周五更新，每日一期，内容独家授权汽车之心发布。 北京时间 5 月 15 号，也就是上周五，Cruise 宣布裁员 150 个人，这个消息震惊了业内。 因为这家累计融资 72.5 亿美元的美国自动驾驶公司，是全球自动驾驶行业里面的融资王，资金非常的充裕，被认为是仅次于 Waymo 的最不差钱的自动驾驶公司，连他们都进行了裁员。 我们可以想象，现在疫情和汽车行业整体不景气，对于美国自动驾驶公司的影响。 我印象里面 Cruise 的人员规模差不多有 1900 个人，是现在全球规模最大的自动驾驶团队，这个人员的规模比 Waymo 的 1500 个人还多了不少。 这次 Cruise 裁员裁掉了公司总人数的差不多 8%。 同样在这个月，也就是 2020 年的 5 月，美国另外一家 L4 级别的自动驾驶的标杆企业，曾经创下独立初创公司单轮融资最高纪录的 Zoox，他们单轮的融了 5.3 亿美元，也被媒体报道，正在寻求被收购。 再加另外一个消息，重卡领域里面的自动驾驶公司 Starsky Robotics 在今年 3 月份宣布停止运营了。 原因就是 2019 年 11 月份他们在寻求一轮 2000 万美元融资失败了，这家公司累计融资 2030 万美元，花完之后资金链断裂了，不得不寻求破产保护。 2020 年，我们现在看到美国的自动驾驶公司出现了裁员、卖身倒闭等等这样的困境。 但另外一方面，自动驾驶领头羊 Waymo 高调宣布完成了一轮外部投资累计 30 亿美元的融资。 就单轮融资额而言，创下了全球自动驾驶公司里单轮融资的最高纪录。 美国的自动驾驶领域呈现出了冰火两重天的状况，我们可以从中间得到两条基本的逻辑。 第一条逻辑，就是作为一个人才密集型的领域，以 Robotaxi 作为主要商业模式的 L4 级别自动驾驶公司，人才成本运营成本都是比较高的。 在如今自动驾驶车队规模也在越来越大的时候，更需要大笔的资金的投入。 但由于法律、技术、场景积累等等相关的原因，其显性的商业模式还需要一段时间才能够成立。 就我个人估计，L4 自动汽车安全合法的成为我们的出行工具，大约还需要 3-5 年的时间。 关于 L4 自动驾驶技术规模化应用的前提条件，我们可以在以后的节目里面好好的讲一讲。 当前 Cruise 是唯一的一个详细的公布了财务状况的自动驾驶公司。 根据通用汽车的财报，Cruise 烧钱的速度是非常惊人的。从 2016 年、2017 年、2018 年 Cruise 分别亏损了 1.71 亿美元，6.13 亿美元和 7.28 亿美元，总体亏损额达到了 15.12 亿美元。 前段时间我看到一个报道，通用汽车董事兼 CEO 玛丽·博拉在电话会中提到，说从 2018 年第四季度的开始，Cruise 的投入就达到了 2 亿美元。随着人力人员规模的不断扩大，Cruise 的开支每一年维持在 10 亿美元的水平。 这么大的投资额，这也是为什么很多自动驾驶的初创企业在单轮融资的时候，也差不多达到了 10 亿美元的级别。 这样的军备竞赛是全行业的，融资很难的公司就会被淘汰掉。 曾经雄心勃勃的 Zoox，原本要自己造车，还要推动 Robotaxi 服务的大规模的应用，无论哪一个都是极度烧钱的方向。 但是 Zoox 自从从 2019 年 2 月份宣布获得了 5.3 亿美元的投资，累计融资额超过 8 亿美元之后，就再也没有新的融资进来了。 时隔一年零三个月之后，今天我得到了一个最新的消息，Zoox 很可能会完成新一轮的一轮融资，投资方可能是一家车企。 这都让我们得到了一个新的可能性，就是 Zoox 很可能会被一家车企收购，成为它的下属的子公司。 另外就关于我们刚才讲到的 Starsky，做重卡的自动驾驶公司一共只融到了 2300 万美元，这对于一个智能驾驶公司来说是远远不够的。 在新一轮融资失败之后，他们就只能宣布倒闭了。 作为一个初创公司，因为他们的时间太短了，所以积累的技术还不够系统，也没有太多的实体的资产，再加上核心的技术人员已经不断的流失了。连寻求被收购 都成了奢望。 第二方面，我把它总结为头部效应显现。随着 Waymo 开启了针对于外部投资人的融资模式，可能会加剧其他自动驾驶公司融资困难的问题。 原因两有两个： 一方面，在投资人看来，既然有机会能投全球的自动驾驶的领头羊 Waymo，是一个非常好的选择。因为除了赚钱之外，可能会有更好的盈利预期。 另外，就是对一个基金来说，投如此好的标的，那是一个能够扩大其资金的影响力的。 另一方面，越往后所需要的资金链会变得越来越大，投入的资金会越来越多，但是能投得起的投资人就会越来越少。 这就从 2016-2017 年那个时候，满世界都在找各种各样好的自动驾驶公司到现在完全处于买方市场，就是少数的头部企业已经聚集了，然后投资人开始关注头部的效应。 那么市场的其他的融资会变得更加的困难，叠加疫情的影响，融资难会成为未来的主旋律。 美国的自动驾驶公司会进入到淘汰赛，其实中国自动驾驶公司也是这样的，预计在 2020 年也会进入到淘汰赛的阶段。 在这个时候，一定要注意控制成本，延长企业周期生命力。那么这就是未来我们的智能驾驶公司所面临的最大的困难。 不过，因为未来自动驾驶的前景我还是非常看好的，所以短暂的困难是存在的。但是熬过了这个冬天，我相信那些真正能够生存下来的成长起来的自动驾驶公司，一定是伟大的公司。 在未来，我们相信智能驾驶依然是人工智能改变整个世界光辉的起点。 好了，这是今天的《郭继舜带你读汽车科技》，我们明天见。 往期回顾：英伟达为自动驾驶引入了性能怪兽？| 郭继舜带你读汽车科技 关于主讲人郭继舜博士：高级工程师，广汽研究院智能驾驶技术部部长，广汽 L3/L4 无人驾驶技术总监。 中国电子科技大学本科，台湾清华大学、苏黎世联邦理工学院硕士，斯坦福大学博士。加入广汽研究院前，先后在 Google X-Lab，EMC2 中国研究院，百度深度学习研究院从事人工智能技术研发，2017 年广州市高层次引进人才。 ACM/ICIP 亚洲区金牌，日本文部科学省学者奖，Erasmus Mundus 全额奖学金，海峡两岸杰出学者奖等。先后主持和参与 973 国家重点基础研究项目、国家重大基础研究专项、教育部新世纪优秀人才项目等，在 CVPR，ICCV，IJCAI 等国内外顶级期刊和会议上先后发表论文二十余篇，获得中美发明专利共 32 项。 本期制作 主讲：郭继舜 监制：王德芙 编辑：李笠 后期：Tom 设计：陈溪阳 运营：林芝芝 音频平台 喜马拉雅 | 蜻蜓 FM | 听伴 Podcasts | 小鹅通 在以上平台搜索关注汽车之心 即可收听全部节目

17. 

    18 May 2020

    001 | 英伟达为自动驾驶引入了性能怪兽？

    本文摘要：英伟达准备借助 Orin 和英伟达 DRIVE AGX 平台通吃高中低端的市场。 今天我们来讲一讲英伟达。 受疫情的影响，上周四北京时间 2020 年 5 月 14 号晚，英伟达创始人兼 CEO 黄仁勋把 2020 年 GTC 的演讲舞台搬到了自家的厨房里。 此前英伟达的显卡造型被网友们吐槽像煤气灶。可能是想回应这个梗吧，GTC 召开前一天的预热视频里，黄教主一本正经地从烤箱里搬出了新的产品：1 个装有 8 个 GPU 的服务器主板。 黄仁勋此次线上演讲主题的核心是英伟达的下一代图形处理器的架构 Ampere（安培）。 基于安培架构的第一款 GPU A100 的技术参数让人眼花缭乱：7 纳米的工艺，540 亿个晶体管，3D 堆叠技术，加上高达 826 平方毫米的芯片面积，同时支持 TF32 和 BF16 格式，拥有 438 个第三代 Tensor Core，支持虚拟成为 77 个 GPU 来执行不同的任务。 这个听起来真的是一个非常厉害的跨时代的新的架构平台。 虽然 GPU A100 有 2000TOPS 的算力，但其功耗也达到了 800 瓦。如果满负载使用在新能源汽车上，将对新能源汽车的续航造成比较大的影响。 举个例子，NEDC 工况续航在 600 公里的新能源汽车，如果满负载使用 GPU A100 这样的运算架构，其续航里程将下降到大约 200 公里出头。 所以，大算力大功耗的运算单元在未来很可能不是使用在单车上，而是使用在车路协同，V2X 的路端单元成为核心的运算器。 那么车载运算单元呢？当然 SoC 是一个很好的选择。 去年 12 月，英伟达推出了面向 ADAS 和自动驾驶领域的新一代 SoC Orin。当时发布的时候是这么说的：Orin SoC 具有 170 亿个晶体管，搭载英伟达的下一代 GPU。 现在我们知道了它是名字叫作安培架构的 GPU。 安培 GPU 和 ARM 架构的 CPU 核心，一起可以提供最多 200 的 TOPS 的运算能力，是上一代 Xavier SoC 的 7 倍，功耗只有 45 瓦，20222 年交付，面向的是 L2+及以上的自动驾驶场景。 可以看到，Xavier 是 Orin 的上一代自动驾驶芯片。 值得一提的是，虽然发布了很多年了，但是 Xavier 作为核心智能驾驶芯片，首次出现在量产车型上，还是最近发布的小鹏的 P7，它使用的是 Xpilot 3.0 的系统。 在性能和功耗方面，Xavier 有 30 个 TOPS 的算力和 30 瓦的功耗。它的设计就是面向 L2+的 ADAS 系统的，这个很类似于 Super Cruise 和特斯拉的 Autopilot。 小鹏 P7 在智能驾驶方面的可扩展性，强大的算力，出色的智能驾驶功能让我记忆犹新。 其实我们在两年前也很认真地评估过 Xavier 这款芯片，做了大量的测试，30 个 TOPS 的等效算力是当时智能驾驶领域域控制器的大杀器。无奈芯片的成本确实是太高了，最终还是忍痛放弃了。 但作为智能驾驶的从业者，我为小鹏汽车在智能化上的决心和投入感到钦佩和羡慕。 好，我们回到 Orin。前段时间我和英伟达的专家就新一代的智能驾驶芯片 Orin 进行了非常详细的讨论，我发现英伟达转换了战略思路，Orin 在保证强大的算力和性能的基础上，所预计的单片价格让我两眼放光。 看得出来，英伟达准备借助 Orin 和英伟达 DRIVE AGX 平台通吃高中低端的市场。 英伟达的中国区总裁张建中告诉我： 除了 L2 级别的智能驾驶，我们的客户还要求英伟达提供 Robotaxi 或者更高级别的智能驾驶的解决方案。对于客户来说，专门为不同级别的自动驾驶开发独立的架构成本实在太高了，但我们可以怎么做？我们可以利用 Orin 这个平台，从 ADAS 直接打通到 Robotaxi。 这是一个多么好的具有一致性的平台，所以我现在非常期待 2022 年 Orin 大规模量产的时候，给智能驾驶领域带来了新的生命力。 说到车载的芯片，英伟达的主要对手就是英特尔旗下的 Mobileye，这家以色列公司公司几乎占据了全世界车载的智能芯片 70% 的市场份额。 现阶段我们用的非常多的就是它的 EyeQ4 这款芯片，性能和算力都是非常不错的，在未来还有 EyeQ5、EyeQ6 等等一系列的产品。 除了 Mobileye，我们还应该关注特斯拉的 Autopilot 所使用的硬件平台。 另外，还有就是华为 MDC 300 系列的域控制器。这个我们都会在后续的节目中，我找个时间进行详细的解析。 但我必须提一句，华为的 MDC 300 系列域控制器在最近我们的评测中发现：它的性能非常强大，而且其工具链和运算效率都有着非常好的让我满意的结果。 我相信华为的平台将很快在量产车型中出现，并且为高级别智能驾驶提供足够好的算力和足够好的未来的想象空间。 说到 Robotaxi，其实现阶段很多的科技公司在开发平台的时候，依然还是使用工控机，像电脑一样使用英伟达的 GPU 加上英特尔的 CPU。 使用工控机开发的好处，当然就是开发非常简单，在开发的时候我们不用太多地顾忌算力的消耗，但坏处是它的不稳定性。在进行大规模量产的时候，我们必须把系统从工控机转换成嵌入式的系统，这个代码的转换量都是非常大的。 所以我认为：我们去评判一个 L4 甚至更高级别智能驾驶系统，在未来是不是具有非常好的量产可能性，其中有一个重要的指标就是看它能不能够在英伟达或者是华为这样的域控制器平台上更好地展现它的功能，而不仅仅是使用在工控机上。 英伟达这一系列芯片的卖点，就是开发人员可以使用通用的架构，从最初的基准开发到仿真再到路测，重要的是虽然说新款芯片在不断地问世，但是它们依然保留着非常好的兼容性，因此更老的平台运行的代码可以直接在新的芯片上使用。 对于未来的产品线，英伟达将推出一系列的 SOC，基于不同的算力和不同的 ADAS 级别，有一些甚至可以和摄像头和雷达一起安装在前挡风玻璃的外壳上。 这种入门级的芯片功耗只有 5 瓦，却能提供大约 10 个 TOPS 的算力，驱动现在的 ADAS 功能是绰绰有余的。 我之前在一些媒体或者论坛上都讲到，人工智能芯片的算力不足和成本高起，一直是制约智能驾驶发展和大规模应用的因素。 随着英伟达、Mobileye、华为、地平线等等公司纷纷推出了非常具有竞争力的产品，我相信在近几年智能驾驶硬件和算力的发展会极大地加速更多高级别智能驾驶功能量产落地来到我们的身边。 好了，这是今天的《郭继舜带你读汽车科技》，我们明天见。 相关课程：广汽研究院郭继舜：智能驾驶量产的困难与希望