智能驾驶域控制器的软件架构及实现(二：支持L3+的软件架构及产品架构.docVIP

智能驾驶域控制器的软件架构及实现(二）：支持L3+的软件架构及产品架构 支持L3+的软件架构 Level 2 及以下级别的自动驾驶功能基本上都是属于“驾驶辅助”性质。各功能的场景，主要的驾驶行为是驾驶员主导，自动驾驶系统只在非常限定的条件约束内对车辆进行操作。而且这些约束条件所形成的场景基本上是各自独立的，这也就是各功能能够由不同供应商独立开发的原因之一。 从 Level3 开始逐步主导车辆的驾驶，与Level2 有了根本性的变化。L3级别就要求在良好的路况环境下，大多数操作将由汽车为主导，车辆将自动完成自适应巡航、车道居中保持、自动变道、自动驶入（驶出）高速匝道等一系列操作。驾驶员只需要在必要的时候对汽车进行干涉。当然这就对自动驾驶系统的硬件算力，传感器配置，各种感知、规划、控制算法都提出了更高的要求。 在自动驾驶技术中，比较受关注的如何提高硬件的算力，尤其是能支持深度学习的算法能力，如何开发更好的感知算法等等，然而如何让这些得到大大提升的各专项能力能协同工作却很少被特别提及。我们需要的不仅仅是车辆运行过程中，各种自动驾驶功能关联的技术模块能协同工作，还要考虑这些不同的技术模块在开发阶段如何能进行有效的分解，因为不同技术模块往往是完全不同的技术领域，需要不同的专业团队(或供应商)去完成。如果能把这些技术模块“拆得开”又“装得上”就是软件架构需要解决的问题。 正因为从 Level 2 到 Level 3 的跨越难度太大，所以人们在 L2的软硬件架构上修修补补，在不改变核心架构逻辑的基础上尽量增加一些新的功能，才有所谓的 Level2.5。然而 在Level2 原生架构上的修补能力终有尽头，必须有新的架构来支持 Level3及以上的自动驾驶。 Level2 软件架构的瓶颈 前面一篇文章提到了"多个独立功能的自动驾驶控制器 + 域控制器“ 的方案。多用于 Level2 和 Level2.5 的开发。其在软件架构上的瓶颈至少有以下几点： 1. 多个独立的控制器导致计算资源不能协调调度，导致算力浪费与匮乏并存。比如全自 动泊车辅助功能和 ACC/AEB 功能并不是同时启用的，速度超过20公里后，泊车辅助功能停止执行，ACC/AEB 可以启用。但是泊车辅助系统的算力并不能用于 ACC/AEB功能。低速情况下又恰好相反。 2. 智能驾驶域内的通讯延迟。多控制器之间只能通过总线进行通讯带来一定的数据延迟。如果使用高速 Can 总线(1Mbps), 一个毫米波雷达每周期传递30个目标，就能达到总线负载的50%。 3. 各控制器的自动驾驶功能没有一致性的架构设计，只能通过信号进行数据通讯，通过域控制器进行协调。当堆叠更多功能后，复杂度难以维护。 4. 基于功能(ACC,LKA,TJP等等)的设计方式，难于应对 Level3 以上需要的基于场景调度，实现功能越多，功能的边界越难定义，没有一致的架构设计，并行运行的功能会造成复杂度指数上升。 5. 各独立控制器之间无法有效的进行通用组件的共享，各自重复造轮子。 6. 各控制器的功能实现无法利用其它控制器计算的感知结果，造成资源的浪费。 正是在这些问题的背景下，智能驾驶的域控制器越来越集中化，也就是要将这些控制器集中到一个高性能的域控制器中。即使域内还有其他的控制器，那也基本上是低智能的，一般只做某个单项的感知，获取原始数据。但是感知算法仍然在域控器内完成。这样高度集中后，高性能的域控制器就需要有新的软件架构。 软件架构鸟瞰图 智能驾驶域控制器是一个非常复杂的系统，其软件架构涉及非常多的方面，从一个单一的维度很难准确理解整体结构。下图从三千米高空鸟瞰，从三个正交的维度描述整体的软件架构。 “正交”是一个数学概念，是垂直的泛化含义。这里表示两个分类的维度是独立不相关的。 图1 软件架构鸟瞰图 2.1 首先说“层级”这个维度 从左到右层级逐步升高，每一层依赖其左边的那一层才能完成工作。虽然本文是讲软件架构，但我把硬件也放在图里方便理解，毕竟软件依赖硬件。我们从两个角度理解每一层的作用： 1. 这一层做什么 2. 这一层不做什么 代号 层级 做什么 不做什么 L.HW 硬件 提供软件运行的硬件平台。包括各种芯片，总线、电源、时钟、物理传感器等等。 不做软件 L.OS 计算机OS 计算机科学与工程意义上的“操作系统”，管理硬件的计算、存储、IO等各种资源并提供访问硬件资源的驱动程序和API接口。调度各种工作任务(Process或 Task) 的执行，处理IO中断等等。 不做与“车”相关的工作，与“车”没有直接关系，作为通用的计算机操作系统，同样可以用在其他不同的行业。 L.BSW 车载控制器基础软件 汽车控制器非常复杂，控制器本身应该具有的应用功能外，为了让控制器能够装入车内使用，还有很大一部分软件是用于让