支持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. 各控制器的功能实现无法利用其它控制器计算的感知结果，造成资源的浪费。 正是在这些问题的背景下，智能驾驶的域控制器越来越集中化，也就是要将这些控制器集中到一个高性能的域控制器中。即使域内还有其他的控制器，那也基本上是低智能的，一般只做某个单项的感知，获取原始数据。但是感知算法仍然在域控器内完成。这样高度集中后，高性能的域控制器就需要有新的软件架构。
软件架构鸟瞰图
智能驾驶域控制器是一个非常复杂的系统，其软件架构涉及非常多的方面，从一个单一的维度很难准确理解整体结构。下图从三千米高空鸟瞰，从三个正交的维度描述整体的软件架构。 “正交”是一个数学概念，是垂直的泛化含义。这里表示两个分类的维度是独立不相关的。
2.1 首先说“层级”这个维度
从左到右层级逐步升高，每一层依赖其左边的那一层才能完成工作。虽然本文是讲软件架构，但我把硬件也放在图里方便理解，毕竟软件依赖硬件。我们从两个角度理解每一层的作用：
代号
层级
做什么
不做什么
L.HW
硬件
提供软件运行的硬件平台。包括各种芯片，总线、电源、时钟、物理传感器等等。
不做软件
L.OS
计算机OS
计算机科学与工程意义上的“操作系统”，管理硬件的计算、存储、IO等各种资源并提供访问硬件资源的驱动程序和API接口。调度各种工作任务(Process或 Task) 的执行，处理IO中断等等。
不做与“车”相关的工作，与“车”没有直接关系，作为通用的计算机操作系统，同样可以用在其他不同的行业。
L.BSW
车载控制器
汽车控制器非常复杂，控制器本身应该具有的应用功能外，为了让控制器能够装入车内使用，还有很大一部分软件是用于让控制器满足汽车的电源管理标准，网络管理标准，诊断标准，刷写规范。
不做与“自动驾驶”相关的工作，一样可以用于开发其它车载控制器。
L.FW
自动驾驶软件框架及基础组件
这一层需要理解自动驾驶相关的语义，了解自动驾驶各类算法的语义概念和执行特点。能够根据自动驾驶语义分隔出不同的软件框架模型。
自动驾驶软件框架不做具体的“自动驾驶功能“的实现，不做具体自动驾驶算法的实现。
L.APK
自动驾驶应用
分析具体的自动驾驶场景，分解为框架层定义的不同组件类型，组合或扩展现有组件，实现新的组件，装入到框架中执行。形成完整的自动驾驶功能或场景的支持能力。
表格 1 软件架构层级
2.2 “实时域”和“性能域”的分工
智能驾驶中，越是到末端的，规划和控制的实时性要求就越高。硬实时要求在确定的时间内响应、确定的时间内完成。这需要由硬件和计算机OS一起提供基础的保证。一般采用在 MCU上运行相对简单的实时系统来实现。MCU的计算能力有限，其算力资源对于基于机器学习的视觉算法需求差了几个数量级。所以需要集成了高性能CPU和 AI 算力资源的 SoC来满足高性能计算的需求。这样就被划分出来了“实时域”和“性能域”。在性能域，运行的计算机OS一般达不到硬实时要求，而是尽量满足软实时要求。比如Linux 就有支持实时性的内核补丁。但也并不是打了实时补丁就具备了实时性，还需要基于 Linux 的应用程序利用实时补丁提供了的能力。
在上面的三维度图中，“分工”与“层级”这两个坐标轴是正交关系。也就是说“层级”轴上的每一段在“实时域”和“性能域”都有对应的标的物。每一个标的物往往对应于一个具体的软件产品。下表列出了一些组合例子：
D.P + L.OS
Linux或 QNX
D.P + L.BSW
Adaptive AutoSar
D.R + L.OS
FreeRTOS
D.R + L.OS + L.BSW
Classic AutoSar
Classic AutoSar 比较特殊，它属于实时域，但是在层级轴上横跨了两层。
3.2.3 切面
切面“Aspect”是软件架构中的一个概念。编程范式中有一个概念叫“面向切面的编程”(AOP, Aspect Oriented Program)。其基本含义在软件架构上把软件的功能分为“核心业务”和“周边业务”： 核心业务是指完成实际业务逻辑的功能体系，比如算法执行，场景切换等等。 周边业务是指那些即使没有实现，也不会影响核心业务执行的功能。比如说性能统计，信息安全等。并不是说这些功能不重要，而是说将它从核心业务逻辑中区分出来后，方便更好的理解和实现核心业务。同时可以把相同切面的的周边业务能够以更全局的视角进行统筹设计和实现，能为对应切面设计合适的专有架构，再与核心业务整合。 在上面的三维度图中，D 轴和 L 轴 构成的平面中的每一个交叉点是一个产品，这个交叉在A 轴上映射就是这个产品在对应切面需要实现的功能。比如 D.R + L.HW 代表的硬件MCU，在 A.FuSa 平面需要达到 ASIL-D 等级。因为 D 轴和 L 轴的每一个交叉点涉及的软件技术差别很大，其投影在 A 轴上每一个平面上的需求点，采用的技术方案也差别非常大。 所以我们在系统开发时(V 模型左上角的系统开发阶段)，可以对某一个切面提出整体的设计要求。但是落实到每一个 DL轴交叉点时，应该由该交叉点对应的产品开发团队分别实现。不可能由一个团队实现一个完整切面的所有功能。
ROS/ROS2 与“中间件”
因为 ROS/ROS2 经常用来自动驾驶系统的原型开发，所以结合上面的三维度图，我们讨论一下 ROS/ROS2 的位置，以及它能否用于智能驾驶量产的问题。 首先先澄清一下OS的概念，ROS 是机器人操作系统，虽然名字中有 OS的字母，但此 OS 非彼OS。一般我们讲 OS，狭义上是专指计算机操作系统，如 Windows, Linux, MacOS, RTOS 等等。为避免歧义，本文中都不用简写，都完整地写作“计算机OS”或“计算机操作系统”。广义的OS，为某一个专业领域提供了一套软件的解决方案和应用接口，该专业领域的用户可以基于此接口简化领域相关的开发，那么可以把这个解决方案软件体系称为领域特定的OS。ROS 就是用于解决机器人软件开发的领域特定OS。但实际上，使用ROS或ROS2写的应用程序只是运行在计算机OS之上的进程，但是链接了 ROS/ROS2 提供的库。ROS/ROS2也提供了方便机器人开发的软件包，比如某些算法或者坐标转换的工具库。 因为一辆自动驾驶的汽车，从某种意义上来说，也是一个自动驾驶的机器人，所以可以使用 ROS/ROS2 来做自动驾驶的原型开发，而且ROS/ROS2 的生态中有很多方便的工具能够给开发提供很多便利。 在上面的三维度图 中，ROS/ROS2的位置在 （D.P + L.BSW） 的交叉区域内并向（D.P + L.FW） 区域有一定扩展。但是，它只是覆盖了这个两个区域的一小部分。而且在 A 轴上几乎没有实现什么特性。
3.1 ROS/ROS2 在 (D.P + L.BSW)中的地位
在上表中详细描述了 L.BSW（车载控制器基础软件）层需要做的工作，与通讯网络设备的概念相映射，很大一部分是管理平面的工作，然后还很重要的一点就是要提供通讯的能力。一般还会提出基于 L.BSW的功能开发应用的框架形式的规范。ROS/ROS2 实际上主要提供了 L.BSW 层中的通讯支持能力，通过发布订阅模式能让各个应用节点解耦合。车载控制器需要的基础管理能力 ROS/ROS2中都很少有实现。 有些人以为 ROS2 不能用于工业化量产的车载控制器是因为通讯实时性不够。这是一个理解上的误区。ROS2本来就不是为实时域设计的，如果一定要把实时性要求高的车辆控制算法运行在 ROS2中，那是软件设计的错误（原型系统没关系，量产不行），而不是ROS2的问题。ROS2能否用于量产的智能驾驶控制器？答案是可以，前提是补齐 L.BSW层所需要完成的所有功能，补齐 A 轴所有切面要求的特性。这实际上是基于 ROS2的架构去实现一套 AP AutoSar 规范。这可以成为一个单独的产品，投入时间+人+钱可以开发出来，只是看有没有必要，值不值得。
3.2 ROS/ROS2 在 (D.P + L.FW)中的地位
ROS/ROS2 确实实现了一个机器人开发的应用框架并提供了很多基础组件，大大便利了机器人应用的开发。但是目前的机器人应用都是在一个很小的区域内移动。一般范围比较大的是仓库机器人，运动范围也就在百米数量级，场景也比较单一。所以 ROS/ROS2对机器人开发的支持映射到智能驾驶，多体现在分形递归的 EPX 模型的最内层。即短距离内单一场景的感知、规划和控制执行。其并没有对复杂的场景的调度(S)和多场景并行下的执行仲裁(A)机制。毕竟还没有机器人需要从北京走到广州。 所以作为智能驾驶的软件开发框架，ROS/ROS2仍然有很多欠缺，但是作为快速原型工具仍然是非常好的选择。
3.3 关于'中间件'
顾名思义，“中间件”一定是在两层中间，为上层屏蔽底层的复杂性。计算机软件架构中有一句名言：“计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决” 。这是软件架构设计的一个主要的设计哲学，用在了无数地方，也解决了无数的问题。而且“中间”一词也是相对的，当有多层堆叠的时候，每一层都是其上下两层的中间层。所以我们说“中间件”的时候，需要指明其上下文，否则容易出现表达与理解的不一致。 当我们说 AP AutoSar 或 CP AutoSar 是中间件时，这个中间件是很明确的 L.BSW 层语义。即处于计算机OS与车载ECU特定功能实现之间，为 ECU功能实现层屏蔽掉特定处理器和计算机OS相关的细节，并实现与车辆网络、电源等系统交互所需的基础服务。 当我们称 “ROS/ROS2 为中间件”时，其含义与 “AP AutoSar为 中间件”并不是对等的关系。ROS/ROS2 是作为机器人开发的应用框架，在机器人应用和计算机OS之间提供了通用的中间层框架和常用软件模块(ROS Package)。而且 ROS团队认为这个框架做得足够好，可以称作操作系统（OS）了。 L.FW 层在 L.BSW 和 L.APK 层之间，它为自动驾驶功能或场景的开发提供软件框架和基础组件。对于其上层来说，它也是中间件。如果做得好，也可以称为OS，那就是“自动驾驶OS”。Anyway，一切都是相对的。 为了避免歧义，本文一般不使用“中间件”术语，如果使用也会明确指出是代表哪两层的中间。多数情况下，我们使用“车载控制器基础软件”代表任何汽车电子ECU都需要实现的基础软件功能，是计算机OS系统之上，ECU实际功能层(FW+APK)之下的中间层。代号 L.BSW。 第二篇内容分享到这里，下一篇将分享：《支持Level3 以上功能的自动驾驶软件框架及基础组件》 ，欢迎大家关注！
作者介绍
肖猛，北京未动科技有限公司研发VP
