ADAS/AD系统方案05-L3高阶智驾系统怎么设计

hudaren43

预告 | 解构自动驾驶大模型！8月17日，「生成式AI热潮下的自动驾驶」技术论坛将在上海举行，论坛将从主机厂入局、BEV感知、仿真数据闭环等多维度展开探讨，欢迎报名。

01

前言

分析过Mobileye的L4智驾方案后（如下面两篇文章），再来缕一缕L3高阶智能驾驶系统要怎么设计吧。
ADAS/AD系统方案04-Mobileye的L4智驾方案分析
ADAS/AD专题参考资料分享07-Mobileye 2021CES

02

正文

先回顾下L3和L4的定义。



图1 L3和L4的定义L3的特点就是具备MRM能力，且不支持脱脑（驾驶员要具备成为DDT-fallback-ready-user的能力，在系统呼叫你的一段时间里，能顺利接管车辆）。L4的特点就是具备完全自动的MRM能力，且支持用户脱脑（驾驶员不再需要成为DDT-fallback-ready-user），遇到问题，用户不响应的化，车辆自己执行MRM，达到MRC状态。需要澄清的是，L4的能力，虽然也有Fail-Operational，但不要求说完全复制两个系统，一个系统出问题，另一个系统仍旧在保证脱脑状态下，继续完成NOA剩下的旅程！只是说，遇到问题，驾驶员完全可以不理会系统，系统需要具备在驾驶员不介入的情况下，做好MRM（比如做好靠边停车）就行。也就是说，L4并等于开启NOA时，系统必须有能力将人从A点成功送达B点。L4完全可以不完成全程，只需要能够在你不参与的情况下，停到路边就行（自动执行MRM）。也就是说，L4的难度，还是在系统性能方面（尤其是感知），要求支持脱脑；但是在Fail-Operational，并不要求像飞机那样搞2oo3，必须飞完全程。只要能自动执行MRM就行。也就是说，到了L4，是不需要DMS了。澄清完L3和L4的定义，我们看看L3系统怎么配置。一、L3高阶智能驾驶系统需要满足的几个关键需求

功能层面，一方面：高速、城区、停车场，全场景要打通，保证系统在尽量多的路段能够开启，辅助用户驾驶；另一方面：尽量提升自动化程度，做到脱手/脱眼。【意味着需要构建比较强、鲁棒性也比较好的感知能力。其中，“比较强”这个要求，映射到了全场景，因此城区这种复杂场景，也要能够搞定；“鲁棒性也比较好”这个要求，映射到了做到脱手/脱眼。因此，Camera + Lidar + Radar/4D Radar + GNSS/RTK + IMU + HD Map + DMS全套传感器，默认要全上的，一方面来应对复杂场景，另一方面来确保鲁棒性。DMS上的原因在于，要识别驾驶员能够作为合格的DDT-fallback-ready-user】安全层面，受到图2的需求约束，需要构建一定的Fail-Operational的能力（但驾驶员还是不能脱脑，需要作为DDT-fallback-ready-user来监控）。另外，系统构建Fail-Operational能力的优先级不高，需要排在感知/预测能力之后。系统需要先具备较强的感知/预测能力，保证全场景智能驾驶的流畅性，以及足够优秀的可靠性保证脱手/脱眼，最后再考虑为了满足MRM需求而构建Fail-Operational系统。

图2 遇到系统失效情况，在驾驶员接管之前，仍旧需要独立运行一段时间二、L3系统配置梳理

1. 全场景&脱手/脱眼：全场景+脱手/脱眼，首先考验的是感知性能。比如，驾驶员想脱手脱眼，首先是系统能把该检测到的场景都检测完整，并不会出错，不要让系统因检测不出来异形车、锥桶、施工区域、他车close cut-in等场景，导致发生事故。有了以上的底气，智驾系统才能放心的让驾驶员进行脱手/脱眼。但是，感知很难做，目前也是L3高阶智能驾驶的瓶颈，因此到底需要什么样的传感器配置，目前不完全清楚。为了保险期间，只能将最先进的传感器都配置上。比如国内比较流行的11V-5R-1or2L-12USS-1DMS。有人会说，这种配置会不会有些浪费？但是更多人会担心，即便“11V-5R-1or2L-12USS-1DMS”全配上，感知性能仍旧不一定能支持得了脱手/脱眼。然而，“11V-5R-1or2L-12USS-1DMS”却已经是目前最先进的传感器配置了。最终，这个问题当前变成了一个命题作文，只能假设“11V-5R-1or2L-12USS-1DMS ”全配上，是能够实现脱手/脱眼的（就是假设state-of-the-art的传感器装上车后，是能够实现L3自动驾驶的）。最终，传感器配置的选定上，反而“简单”了，全上就完事了。得出假设等式：11V-5R-1or2L-12USS-1DMS都配上 = 能够搞定全场景智驾&脱手/脱眼。2. MRM和Fail-Operational：系统故障，还需要能撑一段时间，那么整个L3智驾系统就不能有唯一的一个计算单元，比如不能只有一个域控制器；需要额外的一个控制器在主域控制器故障后，仍旧能够驱动全部（或部分）传感器，支持MRM的运行。这里我们一起盘点下，实现不同复杂度MRM的Fail-Operational设计的合理性。2.1 正常行驶MRM（完全正常行驶）：某个部件失效后（比如控制器失效），L3系统完全不受影响，正常进行“全场景&脱手/脱眼”驾驶（仍能够完成A-B点的任务）。这其实已经超出了L4系统的要求了，极不合理了。我们不妨按照之前假设，硬着头皮往下拆解下：只有state-of-the-art的传感器配置，才能保证“全场景&脱手/脱眼”。意味着，哪个传感器或控制器都不能失效，一失效就搞不定“全场景&脱手/脱眼”了。这种系统，最简单的，要保证失效后，功能仍旧保持在“全场景&脱手/脱眼”的状态，理论上需要两套“11V-5R-1or2L-12USS-1DMS-1DCU”系统，也就是22V-10R-2or4L-24USS-2DMS-2DCU的配置。这样，哪个系统的任何一个传感器或控制器坏掉，还有另一个完整的“11V-5R-1or2L-12USS-1DMS-1DCU”系统在运行。但是，以目前整车上传感器的安装位置定义来看，是无法实施所有传感器都Double的。22V-10R-2or4L-24USS-2DMS，得多可怕。那么就要退回来，传感器是不可能Double了，只能控制器Double下。但是话又说回来，光控制器Double又有什么用呢？毕竟只要有个传感器失效了，即便是两个控制器，也无法支撑起“全场景&脱手/脱眼”的功能状态呀！（别忘了我们上面的假设：哪个传感器或控制器都不能失效，一失效就搞不定“全场景&脱手/脱眼”了）。因此，不仅这种要求超出了L4定义的要求，也受限于传感器全部Double的荒谬性，搞正常行驶MRM完全是荒谬的。2.2 降速行驶MRM（服务区停车）：这其实也已经超出了L4系统的要求了，不合理。我们仍旧迎着头皮往下推演下。如果完整的“11V-5R-1or2L-12USS-1DMS-1DCU”系统能搞定全场景+脱手/脱眼，那么理论上，只要域控制器别搞单点失效（只配一个DCU作为中央大脑），传感器那么多，失效一个，系统感知性能不至于降低很多。因此，逻辑上，“11V-5R-1or2L-12USS-1DMS”的传感器配置，搭配上两个域控制器（避免控制器作为中央大脑，单点失效后造成系统完全瘫痪），做降速行驶MRM，是可行的。但是这种方式，两个控制器都必须是“全功能的”，就是每个域控制器，都要在物理上全接入“11V-5R-1or2L-12USS-1DMS”的豪华传感器配置，且都能在另一个DCU坏掉后，能够独立驱动这“11V-5R-1or2L-12USS”的豪华传感器配置，如图3所示。假设图2中的Input Data代表“11V-5R-1or2L-12USS-1DMS”的这29-30个传感器，上面的ECU1，会全部接入这29-30个传感器并都能处理；下面哪个ECU2，同样也会接入这29-30个传感器并都能处理。


图3 同一套传感器配置，在两个Full-Size的域控制器全接入后，做降速行驶MRM（也是朝纲课题，L4/L5都没这个要求）2.3 路边停车MRM（变道靠边停车）：路边停车的难度要远远低于降速行驶，也更合理。只要保证有个360°感知正常工作就可以（支持安全变道），因此在降速行驶MRM的基础上，两个域控制器不需要“全功能的”了。这个时候，Mobileye那个Ture Redundancy的设计就比较给力了。比如，“11V-5R-1or2L-12USS-1DMS”的传感器配置，摄像头全接入DCU1中，形成Camera-only子系统，且DCU1无需考虑处理Lidar/Radar的资源，只要搞定Camera就行；Lidar/Radar全接入DCU2中，形成主动传感器子系统，且DCU2也无需考虑Camera的接入，有足够资源处理Lidar/Radar点云就行。完全不需要像“降速行驶MRM”中的“全功能的”DCU配置。如此一来，两个子系统结合在一起，形成性能更完整的能支撑“全场景&脱手/脱眼”功能；由单个子系统失效（不管是传感器还是控制器），都有另外一个完全独立/隔离的子系统，保证做好路边停车MRM。性能好一些，能做到脱脑的话，那就是L4了。做的不好，不能脱脑，关键时刻还需要驾驶员接管，但是至少靠边停车的MRM能力都在，也算不错。逯建枫：ADAS/AD系统方案04-Mobileye的L4智驾方案分析2.4 自车道停车MRM：该MRM不牵涉到变道，理论上传感器上，只要有1V（检测车道线+前方车辆），就能够完成；顶多防一手自车刹停过程中有他车会closed cut-in，需要侧前传感器工作（比如侧前相机、侧前毫米波等）。整体上，对传感器依赖很小，因此在主系统为“11V-5R-1or2L-12USS-1DMS-1DCU”情况下（搞定全场景&脱手/脱眼），单独搞个Smart Camera做back-up就可以了。但是需要质疑的是，明明是能够完成“全场景&脱手/脱眼”的“11V-5R-1or2L-12USS-1DMS-1DCU”的L3高端智能驾驶系统，却仅仅因为设计的不合理（比如用了一个”全功能的“DCU，而不是用两个类似上文中做"靠边停车MRM"系统的不全功能的DCU），再搭上一个Smart Camera的成本，却只做到了自车道停车的MRM，你不觉得不合适吗？3. Fail-Operational只做到2个Channel（1oo2D）原因见2018年的两篇文章。一般地，为了平衡性能和成本，汽车上主要采用1oo2D的Fail-Operational设计。ADAS/AD开发11- 安全角度
ADAS/AD资料分享06-从FailSafe到FailOperational4. 总结整个第二节梳理了做到L3高阶智驾的功能定义（全场景+脱手/脱眼），以及L3高阶智驾所需的传感器配置（11V-5R-1or2L-12USS-1DMS全上），以及针对不同复杂度的MRM所需构建的Fail-Operational系统配置。针对不同的MRM我们做个分析。首先，从技术/工程/成本角度，否定了“正常行驶MRM”和“降速行驶MRM”（实质已超纲，L4/L5系统都没要求必须顺利完成A to B点完整NOA旅程的要求）的合理性。只是说，驾驶员不搭理系统的情况下，系统遇到故障，无需人介入的情况下自动执行DDT，并通过执行MRM，把车搞到MRC状态就行。但是自动执行DDT，不等于需要能自动完成从A点到B点的旅程。如果按照飞机那种2oo3的Fail-Operational设计，要求必须系统故障后，能顺利完成从A点到B点的旅程，属于对L3/L4/L5定义的严重误解，以及功能范围蔓延。第二，证明了路边停车MRM的合理性。对的，路边停车这种操作，是真正合理的MRM。成本低，系统出了问题，您还一时半会没来得及接管，车辆能帮忙把车安全的停好（停在路边），就是最合适的操作。您再打个火，自己开车就行了。找个时间修下车，修好了继续使用智驾系统。完美！最后，证明了自车道停车MRM的不合理性。除了上面分析的自车道停车MRM在L3高阶智驾系统上的不合理性（记住，只是高阶智驾系统哦！低阶的系统，搞自车道停车MRM可能很“香”哦）。自车道停车，不管是在高速上，还是在城区里，都不是个好的MRM，只能说是有些系统配置过低，搞不定路边停车MRM，就直截了当给你扔路中央了。多危险啊！后面车速度那么快，把你追尾了怎么办？结论，用户视角（产品视角），L3系统只做到自车道停车MRM，不合理。否定。好了，高阶智驾系统的Fail-Operational做到什么程度，就回答清楚了。只有唯一答案：做到路边停车MRM的Fail-Operational设计，是最合理的。这种方案的特点就是：完全独立的两个子系统，一部分传感器固定接DCU1（DCU1不需要有11V-5R-1or2L-12USS的全传感器处理能力），另一部分固定接DCU2（DCU2也不需要有11V-5R-1or2L-12USS的全传感器处理能力）。DCU规模小了，传感器也完全独立接了。一个子系统坏了，立马用另外一个子系统做MRM，系统简单明了。最佳案例，Mobileye的Camera-Only子系统，加Lidar/Radar子系统的Ture Redundancy系统。而且这个系统在L3和L4系统上都成立。做L3系统：如果像本人一样，对state-of-the-art传感器配置的感知/预测性能比较悲观，认为所有传感器加在一起，才能实现“全场景&脱手/脱眼”的L3功能，如图3。逻辑很顺，因此不管是Camera-only系统，还是Lidar/Radar系统，都是有360°感知能力，做变道和靠边停车，问题不大。加在一起，又是个完整的“11V-5R-1or2L-12USS-1DMS-2DCU”系统，预期能做“全场景&脱手/脱眼”，装个DMS需要驾驶员做DDT-fallback-ready-user，没问题吧？

图4 加在一起，毕竟集齐了所有传感器，因此能做全场景&脱手/脱眼
做L4系统：如果采用Mobileye对感知性能的乐观假设，可以做到脱脑，去掉DMS，不需要驾驶员做DDT-fallback-ready-user。

图5 去掉DMS做L4系统

03
其他事项澄清

1. Fail-Operational与功能安全的区别Fail-Operational，主要是在设计自动驾驶系统时，考虑的一种系统设计思想，限定在自动驾驶系统中，为了支持MRM功能。功能安全，主要是从危害分析触发，根据O、C、E的程度，去定ASIL等级，然后指导一个汽车电子系统（包括智驾系统，不管是fail-safe的还是fail-operational的；也包括转向系统、制动系统等等汽车电子零部件）的设计开发。可能由于FuSa在ASIL分解时，经常有类似ASIL B + ASIL B = ASIL D这种策略，分配到不同元器件，然后也牵涉到了“冗余”的实施措施。此“冗余”（FuSa）对上了彼“冗余”（自动驾驶的Fail-Operational），容易搞糊涂。2. 全场景智能驾驶 vs 脱手/脱眼，哪种功能推出策略会更优？ADAS/AD系统方案02-L2+功能定义变迁方向回顾
根据过往的分析，可以得到两种主流的智能驾驶功能推出策略。策略1：基于场景多样性的思路，推出从高速NOA到城区NOA的roadmap策略。目前以特斯拉和国内主机厂，以及对应的国内舆论场为主。核心逻辑是：L3以上高阶智驾难度高/成本高，先长期搞L2+，让用户对智能驾驶有体感（兼顾教育市场的作用），能够经常用（所以强调高速+城区+停车场等全场景可使用），逐步让用户的驾驶习惯迁移到人机共驾的状态。习惯养成后，再开其他没有NOA功能的车，感觉不习惯，就像AirPods逐步替代有线耳机、智能门锁逐步替代传统钥匙门锁一样。这种策略，有三个小问题：1. 前几年过度宣传导致的后遗症，原来一直宣传的是自动驾驶，试驾一次，发现还要人来操心，用户预期非常高，从而感觉不好用，不愿开启，导致“培养用户人机共驾习惯”的策略打折扣。2. 用户体验只能体现在大部分路段能开启带来的“实惠感”（好多场景我这个系统都能开启，你看多实惠呀），实际使用过程中谈不上很棒的用户体验（可能更多是为了盘算第1个问题，假设了“培养用户人机共驾”的前提下，能够帮助用户减轻一些驾驶负担？）；3. 防不住有些“大胆”的用户，在人机共驾时，过度依赖系统，导致事故发生。始终会伴随一些舆论上的讨伐。事件多了后，监管可能也不得不采取一些措施。策略2：几年前的老路子，做好ODD，在相对简化的限定场景里，提高自动化程度，做脱手/脱眼。这里面的关键，就是限定场景的选择。貌似国外的OEM更青睐这条路子？比如奔驰搞的TJP。只搞高速场景（排除行人、自行车、三轮车等复杂的道路用户），但是这个功能一旦开启，就不能让人负责，必须是车负责，让人卸下防备，吃个汉堡，喝瓶奶茶，玩会手机。这也是一种用户体验，但是这个“用户体验”的获得，与策略1的逻辑完全相反，还是要搞ODD（限定场景），来降低感知复杂度，以达到整体功能可以做到脱手/脱眼。而且，这个很难，个人认为这个策略有点“闭关修炼憋大招”的感觉，不容易做好。总结来看，策略1赌的是策略2中脱手/脱眼搞不出，所以策略1可以慢慢培养用户的习惯；策略2赌的是，如果真的能在ODD限定范围内做出一些脱手/脱眼功能，减少用户监管车辆环境的带宽。假设一种具体功能场景：在给普通用户兜售“带ODD限定的可脱手/脱眼的TJP” vs “全场景L2+NOA”时，用户到底会怎么选呢？对于没有尝试过“全场景L2+NOA”功能的大多数司机，会更倾向选脱手/脱眼的TJP。逻辑是：在没有习惯“人机共驾”的普通司机面前，自己开车天经地义，不存在习惯使用“全场景L2+NOA”人机共驾状态的那一点的获得感。这个时候，再看到TJP，他的思路可能是：平时反正我自己开车，到了拥堵路段，能顾脱手/脱眼，让我该开会开会，该看书看书，交通它爱堵不堵，这种功能太香了。对于尝试过“全场景L2+NOA”功能、并习惯了人机共驾的少数司机，已经上了“人机共驾”的船，养成了习惯，那可能会纠结一下，毕竟在享受了全场景“人机共驾”的甜头后，再退回去，只能去享受“限定场景脱手/脱眼”功能，确实会有纠结的可能性。因为对比过后，有些人可能会有“失去感”。经过了11篇文章的分析，面向高阶智驾系统的拆解就告一段落了。主要从功能层、系统层、算法层进行了一些粗浅的分析。后面可能会写一些机器人相关的东西。拜拜~
技术论坛预告