未动科技：支持L3+自动驾驶的软件架构及产品架构

　　[第一车市 新闻]L2 及以下级别的自动驾驶功能基本上都是属于“驾驶辅助”性质。各功能的场景，主要的驾驶行为是驾驶员主导，自动驾驶系统只在非常限定的条件约束内对车辆进行操作。而且这些约束条件所形成的场景基本上是各自独立的，这也就是各功能能够由不同商独立开发的原因之一。

　　作为早期赋能自动驾驶行业的汽车智能化科技企业，未动科技自成立以来始终专注于打造高级别汽车自动驾驶的视觉感知算法、高实时性与高可靠性的系统软件平台及异构计算引擎。高级别自动驾驶即L3 开始逐步主导车辆的驾驶，与L2 有了根本性的变化。L3级别就要求在良好的路况环境下，大多数操作将由汽车为主导，车辆将自动完成自适应巡航、车道居中保持、自动变道、自动驶入(驶出)高速匝道等一系列操作。驾驶员只需要在必要的时候对汽车进行干涉。当然这就对自动驾驶系统的硬件算力，传感器配置，各种感知、规划、控制算法都提出了更高的要求。

　　未动科技作为一家汽车智能化科技企业，在自动驾驶技术中，更加关注如何提高硬件的算力，尤其是能支持深度学习的算法能力，如何开发更好的感知算法等等，然而如何让这些得到大大提升的各专项能力能协同工作却很少被特别提及。我们需要的不仅仅是车辆运行过程中，各种自动驾驶功能关联的技术模块能协同工作，还要考虑这些不同的技术模块在开发阶段如何能进行有效的分解，因为不同技术模块往往是完全不同的技术领域，需要不同的专业团队(或商)去完成。如果能把这些技术模块“拆得开”又“装得上”就是软件架构需要解决的问题。

　　正因为从 L2 到 L3 的跨越难度太大，所以人们在 L2的软硬件架构上修修补补，在不改变核心架构逻辑的基础上尽量增加一些新的功能，才有所谓的 L2.5。然而在L2原生架构上的修补能力终有尽头，必须有新的架构来支持 L3及以上的自动驾驶。

　　L2 自动驾驶软件架构的瓶颈

　　多个独立功能的自动驾驶控制器 + 域控制器的方案，多用于 L2 和 L2.5 的开发，其在软件架构上的瓶颈至少有以下几点：

　　1. 多个独立的控制器导致计算资源不能协调调度，导致算力浪费与匮乏并存。比如全自动泊车辅助功能和 ACC/AEB 功能并不是同时启用的，速度超过20公里后，泊车辅助功能停止执行，ACC/AEB 可以启用。但是泊车辅助系统的算力并不能用于 ACC/AEB功能。低速情况下又恰好相反。

　　2.自动驾驶域内的通讯延迟。多控制器之间只能通过总线进行通讯带来一定的数据延迟。如果使用高速 Can 总线(1Mbps), 一个毫米波雷达每周期传递30个目标，就能达到总线负载的50%。

　　3. 各控制器的自动驾驶功能没有一致性的架构设计，只能通过信号进行数据通讯，通过域控制器进行协调。当堆叠更多功能后，复杂度难以维护。

　　4. 基于功能(ACC,LKA,TJP等等)的设计方式，难于应对 L3 以上需要的基于场景调度，实现功能越多，功能的边界越难定义，没有一致的架构设计，并行运行的功能会造成复杂度指数上升。

　　5. 各独立控制器之间无法有效的进行通用组件的共享，各自重复造轮子。

　　6. 各控制器的功能实现无法利用其它控制器计算的感知结果，造成资源的浪费。

　　正是在这些问题的背景下，自动驾驶的域控制器越来越集中化，也就是要将这些控制器集中到一个高性能的域控制器中。即使域内还有其他的控制器，那也基本上是低智能的，一般只做某个单项的感知，获取原始数据。但是感知算法仍然在域控器内完成。这样高度集中后，高性能的域控制器就需要有新的软件架构。

　　L3+自动驾驶软件架构鸟瞰图

　　未动科技创新的L3+软件架构基于满足高性能域控制器的需求而提出。自动驾驶域控制器是一个非常复杂的系统，其软件架构涉及非常多的方面，从一个单一的维度很难准确理解整体结构。下图从三千米高空鸟瞰，从三个正交的维度描述整体的软件架构。

　　“正交”是一个数学概念，是垂直的泛化含义。这里表示两个分类的维度是独立不相关的。

　　图1未动科技软件架构鸟瞰图

　　2.1未动科技L3+软件架构：“层级”维度

　　从左到右层级逐步升高，每一层依赖其左边的那一层才能完成工作。虽然本文是讲软件架构，但把硬件也放在图里方便理解，毕竟软件依赖硬件。首先，从两个角度理解每一层的作用：

　　1. 这一层做什么

　　2. 这一层不做什么

　　表格 1未动科技软件架构层级

　　2.2 未动科技L3+软件架构：“实时域”和“性能域”的分工

　　自动驾驶中，越是到末端的，规划和控制的实时性要求就越高。硬实时要求在确定的时间内响应、确定的时间内完成。这需要由硬件和计算机OS一起基础的保证。一般采用在 MCU上运行相对简单的实时系统来实现。MCU的计算能力有限，其算力资源对于基于机器学习的视觉算法需求差了几个数量级。所以需要集成了高性能CPU和 AI 算力资源的 SoC来满足高性能计算的需求。这样就被划分出来了“实时域”和“性能域”。在性能域，运行的计算机OS一般达不到硬实时要求，而是尽量满足软实时要求。比如Linux 就有支持实时性的内核补丁。但也并不是打了实时补丁就具备了实时性，还需要基于 Linux 的应用程序利用实时补丁了的能力。

　　在上面的三维度图中，“分工”与“层级”这两个坐标轴是正交关系。也就是说“层级”轴上的每一段在“实时域”和“性能域”都有对应的标的物。每一个标的物往往对应于一个具体的软件产品。下表列出了一些组合例子：

　　表格 2 产品划分示例

　　Classic AutoSar 比较特殊，它属于实时域，但是在层级轴上横跨了两层。

　　2.3 未动科技L3+软件架构：切面

　　切面“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 关于L3+自动驾驶"中间件"

　　顾名思义，“中间件”一定是在两层中间，为上层屏蔽底层的复杂性。计算机软件架构中有一句名言：“计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决” 。这是软件架构设计的一个主要的设计哲学，用在了无数地方，也解决了无数的问题。而且“中间”一词也是相对的，当有多层堆叠的时候，每一层都是其上下两层的中间层。所以我们说“中间件”的时候，需要指明其上下文，否则容易出现表达与理解的不一致。

　　当我们说 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。

　　未动科技对于自动驾驶中间件如何更好地支持上层应用有准确、透彻的理解，结合多年的视觉感知的研发落地积累，可以更好地配合主机厂进行汽车本身功能的优化，提升用户驾乘体验。