What is 郭继舜带你读汽车科技?

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

Where can I listen to this podcast?

This podcast is available on 4 platforms including Apple Podcasts, Spotify, and more. You can also use the RSS feed directly.

郭继舜带你读汽车科技

Claim This Podcast

by 汽车之心

17 episodes

Updated Daily

Accepts GuestsHas SponsorsLocation 🇨🇳

Podcast Overview

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

Language

🇨🇳

Publishing Since

5/18/2020

Visit Website View on Apple Podcasts RSS Feed

1 verified contact email on file for 郭继舜带你读汽车科技

Pitch yourself as a guest, propose sponsorships, or reach out directly to the host.

See contact details

Recent Episodes

July 2, 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 声学仿真、车辆动力学仿真以及车辆控制算法仿真等等。 这些仿真技术的类型与应用各不相同，但是其核心原理仍然是计算机建模与应用，大致的过程可以抽象为以下几个步骤（如下图所示）： <img data-key="0" src="https://pic2.zhimg.com/80/v2-a894b56a67285d94c5249d80c105f439_1440w.jpg" /> 1）分解过程：根据业务过程闭环，将应用系统划分成为接口明确的子系统。具体到智能驾驶，就是把智能驾驶的各个功能和软硬件模块划分出来。 2）建模过程：根据应用需要，对子系统从原理与数据上进行计算机建模，建立子系统的仿真模型。具体到智能驾驶，就是把智能驾驶的某个功能或者零部件的原理或者特性在计算机上尽可能逼真地建立数字化模型。 3）仿真过程：根据测试需求，将部分子系统替换为虚拟的子系统模型，利用仿真引擎进行虚拟仿真下的业务闭环，必要时可以并发进行；具体到智能驾驶，就是在程序内部或者台架上对功能进行模拟，并且通过改变输入，观察输出是不是和我们预设的一样。 4）优化过程：针对虚拟仿真测试的结果优化被测对象的设计与实现，并通过真实测试来验证仿真系统的有效性，获得更多数据优化仿真模型，实现仿真模型与被测对象的共同进化。具体到智能驾驶，就是把虚拟仿真中发现的没做好的算法或者逻辑，修改后进行反复的迭代和优化，最终达到我们满意的结果。 以上步骤，是我们通过虚拟仿真系统来进行开发的通用的流程，而完整的仿真系统还需要做到对仿真模型、案例数据、仿真过程，输入输出接口的完善管理。 在自动驾驶虚拟仿真测试中，根据真实子系统与虚拟子系统的不同划分，可以分为： MIL（模型在环仿真）SIL（软件在环仿真）HIL（硬件在环仿真）VIL（车辆在环仿真）DIL（驾驶员在环仿真） 分别代表了真实子系统为模型、软件、硬件、车辆、驾驶员的情况下的虚拟仿真业务闭环过程。 需要说明一下，如果是我们全部自研算法的智能驾驶系统，从 MIL、SIL 开始到 VIL 都是可以完成的，但是如果你使用的是 Mobileye 的 EyeQ 系列芯片，比较封闭，拿不到代码或者中间数据，我们就只能从硬件在环和车辆在环层面去仿真。 一般来说上述过程闭环所需要的仿真模型通常包括：传感器物理模型，车辆动力学模型，静态虚拟场景模型，天气气候模型，动态虚拟对象模型，动态交通流模型，车辆驾驶行为模型、突发事件模型等等。 这些模型的建模与运算需要非常专业的背景知识技能以及数据积累，并且需要专业的厂商提供的相应的仿真引擎来实现。 例如：车辆动力学建模需要专业的车辆动力学引擎并且需要车厂提供详细的车辆参数，传感器物理建模需要传感器厂商提供电磁学模型，交通流与驾驶行为建模也需要专门的交通流仿真引擎以及更加真实详尽的数据来驱动。 而其中最难的还是如何构建这样的一个虚拟的世界，一方面需要像游戏公司一样进行 3D 模型设计。 虚拟世界中的物体对象，另一方面，需要类似底层的游戏引擎厂商甚至英伟达这样的硬件厂商提供类似于粒子引擎、RTX 实时光线追踪引擎等等底层渲染技术，才能够比较完美的构建一个视觉渲染像更真实，电磁信号反射特性与强度符合真实物理原则的虚拟世界。 目前业内主要通过虚拟游戏引擎来实现上述的功能，最常用的有UnrealEngine4和Unity3D，包括高逼真渲染、模型动作渲染、物理碰撞模拟、天气模拟等等功能，都能够通过这些游戏引擎直接来实现，开发人员可以更多的集中在场景实现与业务逻辑上，提高了开发的效率。 在上述的技术基础上，自动驾驶的虚拟仿真技术才可能通过对采样位置与采样模式的不同设置实现对摄像头、毫米波雷达，激光雷达等传感器输入信号的精确建模，让虚拟仿真系统具备可用行。 至于更进一步的交通流建模，驾驶行为建模，突发事件建模，则更加涉及到复杂系统交互、人类情感波动等等多种因素的影响，已经无法精确建模。 对此我们可以基于实际测试数据，以基本规则加上一定随机化的方式来模拟（例如 Waymo 的模糊化技术，见下图），以最大化测试更多的可能性。 或者直接通过对抗生成网络技术对真实数据的模式进行学习以生成更多接近真实的数据，用以穷尽所有的可能的边缘场景（当然目前看起来仍然遥遥无期）。 <img data-key="1" src="https://pic1.zhimg.com/80/v2-ad9485fa67677528b8c6412b8d61e224_1440w.jpg" /> 此外，虚拟仿真系统并不一定要完整的实现，而是需要根据具体的业务需求与测试目标来进行选择与应用。 例如，如果只测试控制算法，则仅仅需要车辆动力学仿真就可以了；只测试决策规划算法，则可以省略高逼真渲染的模型，仅仅使用事件模型，可以大大节约算力成本与事件成本，获得更好的效率。 由于建模毕竟是对真实世界的简化与抽象（越复杂的模型与真实世界的逼近程度越高，但是需要的算力与时间代价也越大），所以真实世界的数据与案例才是最具有价值的。 为了更好地优化模型以及训练算法，虚拟仿真建模必须支持从真实数据更新模型，优化模型，甚至要支持直接的数据的无损转换与重播，以弥补建模对信息的损失。 2、当前自动驾驶领域虚拟仿真工具以及应用场景 当前自动驾驶领域用到的仿真工具主要分成四类： 1）传统汽车仿真软件：包括CarSim、CarMaker、VTD、PreScan等，特点是与当前汽车 ASPICE 开发流程结合紧密，认证链比较完善，支持台架测试等等 HIL 测试验证，常用于功能验证与车辆动力学验证。 <img data-key="2" src="https://pic2.zhimg.com/80/v2-f77e545c769cdd8a8017ecd6e2cac2d5_1440w.jpg" /> 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. 具备完好的数据管理功能，辅助分析功能，具备并发仿真的性能，以及友好方便的操作界面与人机交互设计，能够为汽车产品全生命周期的开发人员提供一个全栈式的虚拟仿真测试验证解决方案。 预告：应读者群里的提问，我们将讲讲不同级别智能驾驶系统的传感器方案和相应的传感器融合的算法。

June 19, 2020

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

<img data-key="0" src="https://mmbiz.qpic.cn/mmbiz_jpg/x2xSWpuvvDy5LlBywl9iaxXXicpIeMoesejZfjhTyfMkLE3CXZRFWPTcY0Bq1kL3J1YibjI9c9wUicoox3iaPG0pciag/640?wx_fmt=jpeg" /> 编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，内容独家授权汽车之心发布。郭继舜带你读汽车科技No.1600: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 升级，实现对刹车踏板特性的调节。 这次升级就是通过调整刹车响应曲线来实现整个刹车过程中的制动力最优化的分配，从而减少刹车距离的。 <img data-key="1" src="https://mmbiz.qpic.cn/mmbiz_png/x2xSWpuvvDwJSfHste2RODyNAr5BiaHFLM5Rxw92yKzZKDCE5lSVB3MaouDXrPnwFx5ic4YhfsEiaomBnLVYc4mnA/640?wx_fmt=png" /> 上面的过程说起来很简单，但是却是目前大多数车厂完全无法实现的，其原因就是现有车辆的电子电气架构还是传统的分布式电子电气架构。 我们从下面这张著名的博世电子电气架构演化图可以看出： 当前大多数的汽车还处在从分布式的 Modular 阶段向初步集成的 Integration 阶段升级的过程中，少数先进的 OEM 则在新兴的比如智能座舱、智能驾驶等等需求的驱动下，开始了分功能域的 Centralization 阶段的尝试。 比如广汽、上汽、小鹏等等，而特斯拉则已经实现了基于区域融合的多个功能域控制器融合的 Fusion 阶段，甚至有进一步整合成为 Vehicle Computer（FSD）的趋势。 这样领先的电子电气架构设计，才能够让 OTA 升级功能渗透到刹车控制器上，实现对最底层执行件软件深度优化。 一方面，这需要整车上的 TBox 网关具备高速安全的外网连接能力与数据传输能力。 另一方面，也需要车辆内部具备高速可靠的总线连接，让网关下载的内容能够下发到最底层的执行件电子单元上面。 最后，还需要 OEM 具备强大软件开发能力，能够开发最底层执行件的控制软件，才能够真正实现用软件来定义汽车功能或者性能。 <img data-key="2" src="https://mmbiz.qpic.cn/mmbiz_png/x2xSWpuvvDwJSfHste2RODyNAr5BiaHFLofy6Zyxc1JicO59myVADdoPY98rsTzWhNPDXhCTusZhp9Eqj6xHUEmg/640?wx_fmt=png" /> 除了博世提出的上述软件架构演化路径以外，其他的先进 OEM 与 Tier1 也提出了各自对于新的电子电气架构的设计思路。 例如宝马就提出了一个基于分层的架构设计理念： 从底向上分别从传感器、执行件层，到标准通用的 ECU 层，再到功能集成的域控制器层，最后到集中式的中央计算平台层。 这是一个基于车内高速通信服务的功能逐步抽象聚类的设计思路，和博世的设计具有异曲同工之处。 <img data-key="3" src="https://mmbiz.qpic.cn/mmbiz_png/x2xSWpuvvDwJSfHste2RODyNAr5BiaHFLwjW3luqVnicvjvxlnNnFrT6y0Of7bsU7KvKh10JKrbq4ibsbp8QFtAaQ/640?wx_fmt=png" /> 本着第一性原理，我们可以来分析一下，驱动电子电器架构进化的要素究竟是什么，从而对于未来电子电器架构进化的形态做一个初步的预测。 首先，是智能化的需求。 早期的汽车主要用机械结构来满足最基本的驾驶需求，以一种机械唯物主义方法论来设计的车辆，所以后续产生的电子系统都以一种辅助机械功能执行的模式来设计实现的，彼此之间通过低速的 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 升级，这也是新一代电子电器架构的功劳。 往期回顾： <a target="_blank" style="color:#4990E2;text-decoration:none;">Mobileye炫技，仅凭12摄像头穿越闹市区，一辆优秀的L4无人车该是怎样的</a> <a target="_blank" style="color:#4990E2;text-decoration:none;">完成一套智能驾驶系统本土化需要多久？</a> <a target="_blank" style="color:#4990E2;text-decoration:none;">特斯拉撞上了侧翻的大货车，从台湾嘉义事故谈传感器融合</a> <a target="_blank" style="color:#4990E2;text-decoration:none;">智能汽车的中国芯：华为MDC首发测评</a> <a target="_blank" style="color:#4990E2;text-decoration:none;">字节跳动入局车联网，互联网应用上车要解决哪些难点？</a> <a target="_blank" style="color:#4990E2;text-decoration:none;">为什么欧美车企纷纷放弃L3，而中国车企热衷量产L3？</a> <a target="_blank" style="color:#4990E2;text-decoration:none;">传统车企为什么造不出Autopilot，特斯拉L4战略存在什么风险？</a> 本期制作 主讲：郭继舜  监制：王德芙 编辑：叶方     后期：陆非     设计：陈溪阳  运营：林芝芝 独家音频平台：喜马拉雅 在喜马拉雅搜索关注汽车之心即可收听往期节目 <img data-key="4" src="https://mmbiz.qpic.cn/mmbiz_jpg/IhkM7N7mqwpjN8UliblvIUPibz2diazBcibedQ3PeLibyAdKExm2V8TaE7nnSXOqIamhVX7sjpWqHFPiaFQtREyZhnfQ/640?wx_fmt=jpeg" />

June 16, 2020

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

<img data-key="0" src="http://wechatapppro-1252524126.file.myqcloud.com/image/ueditor/2867000_1592265647.cn/mmbiz_jpg/x2xswpuvvdy5llbywl9iaxxxicpiemoesejzfjhtyfmkle3cxzrfwptcy0bq1kl3j1yibji9c9wuicoox3iapg0pciag/640" /> 编者按：《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，内容独家授权汽车之心发布。 今天我们聊聊基于 5G-V2X 的路端建设。 我们讲过一期 5G 车路协同的解读（《<a target="_blank" style="color:#4990E2;text-decoration:none;">为什么实现车路协同比造一辆特斯拉还难？</a>》），后来读者群里（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 车联网，将单车智能升级为车路协同的多车智能。 <img data-key="1" src="http://wechatapppro-1252524126.file.myqcloud.com/image/ueditor/15297800_1592265647.cn/mmbiz_jpg/x2xswpuvvdx2grcuny3lnjwqh6ibqc2qycznhcfgkpfcvexqbogq9hmll9eic4wvk1wnxnrqcnuscfcrmocxcn3a/640" /> 我们在之前的音频中已经简单介绍过，车联网主要包括 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 的加持下，最终实现人类出行零伤亡的终极目标。 往期回顾： <a target="_blank" style="color:#4990E2;text-decoration:none;">Mobileye炫技，仅凭12摄像头穿越闹市区，一辆优秀的L4无人车该是怎样的</a> <a target="_blank" style="color:#4990E2;text-decoration:none;">特斯拉撞上了侧翻的大货车，从台湾嘉义事故谈传感器融合</a> <a target="_blank" style="color:#4990E2;text-decoration:none;">智能汽车的中国芯：华为MDC首发测评</a> <a target="_blank" style="color:#4990E2;text-decoration:none;">字节跳动入局车联网，互联网应用上车要解决哪些难点？</a> <a target="_blank" style="color:#4990E2;text-decoration:none;">为什么欧美车企纷纷放弃L3，而中国车企热衷量产L3？</a> 本期制作 主讲：郭继舜  监制：王德芙 编辑：叶方     后期：陆非     设计：陈溪阳  运营：林芝芝 音频平台 喜马拉雅 | 蜻蜓 FM | 听伴 Podcasts | 小鹅通 在以上平台搜索关注汽车之心即可收听全部节目 <img data-key="2" src="http://wechatapppro-1252524126.file.myqcloud.com/image/ueditor/26428900_1592265647.cn/mmbiz_png/x2xswpuvvdylibg0fcrayvrirnaiomp9xhdgvsffmc3kbg4qy9m6yiczkfwvpnzfhcc2y1qibcevynklwq4dsarga/640" /> <img data-key="3" src="http://wechatapppro-1252524126.file.myqcloud.com/image/ueditor/35232700_1592265647.cn/mmbiz_jpg/ihkm7n7mqwpjn8uliblviupibz2diazbcibedq3pelibyadkexm2v8tae7nnsxoqiamhvx7sjpwqhfpiafqtreyzhnfq/640" />

17 total episodes available

Deep-dive analytics for 郭继舜带你读汽车科技

Frequently asked questions

Have a different question and can't find the answer you're looking for? Reach out to our support team by sending us an email and we'll get back to you as soon as we can.

What is 郭继舜带你读汽车科技?: 《郭继舜带你读汽车科技》旨在从第一性原理出发，尝试拨开迷雾，解读热点背后的汽车科技真相。 本栏目由智能驾驶专家郭继舜博士与汽车之心联合出品，每周一至周五更新，每日一期，内容独家授权汽车之心发布。
How often does this podcast release new episodes?: This podcast updates daily.
Where can I listen to this podcast?: This podcast is available on 4 platforms including Apple Podcasts, Spotify, and more. You can also use the RSS feed directly.
Does this podcast accept guests?: Information about guest appearances is not available.

Legal Disclaimer

Pod Engine is not affiliated with, endorsed by, or officially connected with any of the podcasts displayed on this platform. We operate independently as a podcast discovery and analytics service.

All podcast artwork, thumbnails, and content displayed on this page are the property of their respective owners and are protected by applicable copyright laws. This includes, but is not limited to, podcast cover art, episode artwork, show descriptions, episode titles, transcripts, audio snippets, and any other content originating from the podcast creators or their licensors.

We display this content under fair use principles and/or implied license for the purpose of podcast discovery, information, and commentary. We make no claim of ownership over any podcast content, artwork, or related materials shown on this platform. All trademarks, service marks, and trade names are the property of their respective owners.

While we strive to ensure all content usage is properly authorized, if you are a rights holder and believe your content is being used inappropriately or without proper authorization, please contact us immediately at hey@podengine.ai for prompt review and appropriate action, which may include content removal or proper attribution.

By accessing and using this platform, you acknowledge and agree to respect all applicable copyright laws and intellectual property rights of content owners. Any unauthorized reproduction, distribution, or commercial use of the content displayed on this platform is strictly prohibited.