对自动驾驶中间件的认识

自动驾驶中间件是一个很顶层的概念，它后面隐含了很多很多层其他概念，如果对这些隐含概念不清楚，是无法真正理解自动驾驶中间件的，所以我不想像写论文或写文档一样上来就总结出一个很准确的定义或概念，或者一步一步介绍发展历史，再分析不同情况或语境下的各种含义，或者广义和狭义的概念各会包含什么东西，我认为这种分析和记忆没有什么意义，这里会逐步给出我对自动驾驶中间件从”模糊但便于理解“到“清晰但不容易理解”的认识，每一个Part都会递进，从容易理解到更准确，前面的Part可能会有很多不对或不全面的地方，可以把这些看作我自己思考和认识的一个过程。

Part Ⅰ  中间件就是“中间”件

中间件的字面意思就是某两件事物之间的东西，这两件事物是什么呢？可以先不管三七二十一，给一个最便于理解的答案：下面是硬件，上面是应用。

这里硬件指传感器、执行器、计算平台，在自动驾驶中，是各种摄像头、雷达、IMU、底盘、座舱、IVI、MCU、CPU、GPU这些东西，应用就是大脑，可以简单理解为算法应用，例如一个前视的车道线识别应用。中间件就像一张网，把硬件和应用连接起来，让应用能够作为顶层使用者方便的使用传感器数据，或者控制车辆，从而实现各种自动驾驶功能。

Part Ⅱ  OS去哪了？

上面的Part有一个明显的bug，就是OS（操作系统，这里专指内核）没了，OS貌似被包进中间件里面了。

自动驾驶OS内核的开发者较为稳定，主要玩家为QNX（Blackberry）、Linux（开源基金会）、VxWorks（风河）。因打造全新OS需要花费太大的人力、物力，目前基本没有企业会开发全新的OS内核。

OS内核总不能直接包到中间件里吧？那好，把OS内核拆出来，那么中间件的上下两边就发生了变化，下面是OS内核，上面是应用。

OS内核又称为“底层OS”，提供操作系统最基本的功能，负责管理系统的进程、内存、设备驱动程序、文件和网络系统，决定着系统的性能和稳定性。

事实上，OS内核到硬件之间还有一层，即硬件抽象层。

硬件抽象层里包含BSP和Hypervisor。

Hypervisor——一种运行在基础物理服务器和操作系统之间的中间软件层，可允许多个操作系统和应用共享硬件,也可叫做VMM（ virtual machine monitor ），即虚拟机监视器。Hypervisors是一种在虚拟环境中的“元”操作系统。他们可以访问服务器上包括磁盘和内存在内的所有物理设备。

BSP(board support package)即板级支持包，也是介于主板硬件和操作系统之间的一层，主要目的是支持操作系统，使之能够更好的运行于硬件主板。

反正是在OS内核的下边，不和中间件直接接触，不管它。

Part Ⅲ  还有高手？

按照上一Part得出的结论，来研究一下目前市面上所谓的中间件。

AUTOSAR

在所有的中间件方案中，最著名的非AUTOSAR莫属了。

严格地说，AUTOSAR并非特指由某一家软件公司开发出来的某款操作系统或中间件产品，而是由全球的主要汽车生产厂商、零部件供应商、软硬件和电子工业等企业共同制定的汽车开放式系统架构标准。不过，在实践中，各公司基于AUTOSAR标准开发出来的中间件也被称“AUTOSAR”。

当前，AUTOSAR可分为Classic Platform和Adaptive Platform两个平台，两者分别被简称为AUTOSAR CP与AUTOSAR AP。

简单地说，AUTOSAR CP主要跑在8bit、16bit、32bit的MCU上，对应传统的车身控制、底盘控制、动力系统等功能，如果涉及到自动驾驶的话，AUTOSAR CP可能无法实现；而AUTOSAR AP主要跑在64bit以上的高性能MPU/SOC上，对应自动驾驶的高性能电子系统。

但是，AUTOSAR CP包含了OS内核，定义了基本的上层任务调度、优先级调度等。

在基于分布式架构的ADAS功能中，AUOTSAR CP便是最常见的“操作系统”。在AUTOSAR的生态形成后，很多芯片厂商的MCU上标配的就是AUTOSAR CP，主机厂没有什么选择权。

由于分布式架构下的芯片主要是MCU，因此，便有了“AUTOSAR CP主要跑在MCU上”的说法。

在分布式架构下，不同的功能对应着不同的MCU，而每一个MCU上都需要跑一套AUTOSAR CP，若传感器的类型比较多，则仅ADAS相关功能就需要很多套AUTOSAR CP，那怎么收费呢？

常规的做法是：根据MCU的类型来收费——如果MCU是两个异构的MCU，那AUTOSAR CP就按两套来收费；如果MCU是同构的，那AUTOSAR CP就按一套来收费。

随着EE架构从分布式向集中式演进、芯片由MCU向SOC演进，计算量及通信量成数量级地上升，另外，多核处理器、GPU、FPGA以及专用加速器的需求，还有OTA等，都超出了AUTOSAR CP的支持范围。

2017年，为更好地满足集中式架构+SOC时代的高等级自动驾驶对中间件的需求，AUTOSAR联盟推出了通信能力更强、软件可配置性更灵活、安全机制要求更高的AUTOSAR AP平台。

需要强调的是，不同于AUTOSAR CP自身已经包含了基于OSEK标准的OS，AUTOSAR AP只是一个跑在Lunix、QNX等基于POSIX标准的OS上面的“中间件”——AUTOSAR AP并不包含OS。

完蛋，业内最有名的中间件产品，它们上下两边不一样，但他们毫无疑问都是中间件。

至此，似乎可以得出结论，“中间”一词是相对的，当有多层堆叠的时候，每一层都是其上下两层的中间层，因此，在用“中间件”这个词的时候，我们需要特别指明它究竟位于“哪两层之间”。

ROS/ROS2

ROS是机器人操作系统（Robot Operating System）的英文缩写，原生的ROS本是机器人OS，并不能直接满足无人驾驶的所有需求，用作自动驾驶中间件的是ROS 2。

ROS 2与ROS 1的主要区别如下：

（1）ROS 1主要构建于Linux系统之上，主要支持Ubuntu；ROS 2采用全新的架构，底层基于DDS(Data Distribution Service)通信机制，支持实时性、嵌入式、分布式、多操作系统，ROS 2支持的系统包括Linux、windows、Mac、RTOS，甚至是单片机等没有操作系统的裸机。

（2）ROS 1的通讯系统基于TCPROS/UDPROS，强依赖于master节点的处理；ROS 2的通讯系统是基于DDS，取消了master，同时在内部提供了DDS的抽象层实现，有了这个抽象层，用户就可以不去关注底层的DDS使用了哪个商家的API。

（3）ROS运行时要依赖roscore，一旦roscore出现问题就会造成较大的系统灾难，同时由于安装与运行体积较大，对很多低资源系统会造成负担；ROS2基于DDS进行数据传输，而DDS基于RTPS的去中心化的通信框架，这就去除了对roscore的依赖，系统的稳定性强，对资源的消耗也得到了降低。

(4)由于ROS 缺少Qos机制，topic的稳定性与质量难以保证；ROS2则提供了Qos机制，对通信的实时性、完整性、历史追溯等功能有了支持，这便大幅加强了框架功能，避免了高速系统难以适用等问题。

当我们说 AutoSar是中间件时，这个中间件处于计算机OS与车载ECU特定功能实现之间，为 ECU功能实现层屏蔽掉特定处理器和计算机OS相关的细节，并提供与车辆网络、电源等系统交互所需的基础服务；

ROS/ROS2 是作为机器人开发的应用框架，在机器人应用和计算机OS之间提供了通用的中间层框架和常用软件模块(ROS Package)，而且， ROS团队认为这个框架做得足够好，可以称作操作系统（OS）了。

ROS 2尽管在功能上跟AUTOSAR AP有不少重叠之处，但两者的思路是不一样的：

（1）从表现形式上看，AUTOSAR AP首先是一套标准，这个标准定义了一系列基础平台组件，每个平台组件定义了对应用的标准接口，但没有定义实现细节，和平台组件之间的交互接口（这些部分留给 AUTOSAR AP供应商实现）；ROS2则从一开始就是代码优先，每个版本都有完整的代码实现，也定义有面向应用标准API接口。

（2）AUTOSAR AP从一开始就面向ASIL-B应用；ROS 2不是根据ASIL的标准设计的，ROS 2实现功能安全的解决方案是，把底层换为满足ASIL要求的RTOS和商用工具链(编译器）。

CyberRT

Cyber RT是百度Apollo开发出来的中间件，在Apollo 3.5中正式发布。Cyber RT和ROS2是比较像的， 其底层也是使用了一个开源版本的DDS。

百度最早用的是ROS 1,但在使用的过程中逐渐发现了ROS 1存在“若ROS Master出故障了，则任何两个节点之间的通信便受到影响”的问题，所以就希望使用一个“没有中间节点”的通信中间件来代替ROS 1，那时还没有ROS2，所以自己去做了一个Cyber RT。

为了解决ROS 遇到的问题，Cyber RT删除了master机制，用自动发现机制代替，这个通信组网机制和汽车网络CAN完全一致。此外，Cyber RT的核心设计将调度、任务从内核空间搬到了用户空间。

Vector产品专家蔡守群的解释是：

“不需要很机械地去分类，你可以把AUTOSAR AP, ROS和Cyber RT都想象成一个提供一组中间件的超市，用户可以按需从不同的超市购买，并不是说从一个超市买过一个中间件，就不能从其他超市买了。

蔡守群说：AUTOSAR AP中也包含了对ROS接口的支持。说不准哪天ROS和Cyber RT就会加入AUTOSAR AP的组件，或者 AUTOSAR AP会引入Cyber RT的组件。

DDS

在自动驾驶领域，上述几个中间件的功能涉及到通信、模块升级、任务调度、执行管理，但其最主要的功能就是通信。当前市场上，无论是Cyber RT还是ROS，其最重要的功能就是通信。

这种专门用来做通信的，称之为通信中间件，通信中间件可以分成开源和闭源的两种。开源的为OPEN DDS、FAST DDS、Cyclone等，闭源的就RTI的DDS和Vector的SOME/IP。DDS的全称为Data Distribution Service ，指一种数据分发服务标准，由对象管理组织(OMG)制定。

要注意，这里DDS专指一种标准，而其开源/闭源实现，才可以称之为通信中间件。

DDS能够实现低延迟、高可靠、高实时性的数据融合服务，能够从根本上降低软件的耦合性、复杂性，提高软件的模块化特性。高等级自动驾驶现在基本上都在探索依靠DDS来解决异构通信、低时延等CP解决不了的挑战。

融合了DDS的汽车软件能够更好地运行在下一代汽车的体系架构中，更能降低开发的成本、缩短研发的时间，更快地将产品推向市场。

ROS 2和Cyber RT的底层都使用了开源的DDS，将DDS作为最重要的通信机制。

Part Ⅳ  总结一下

从功能上来讲，中间件没有具体的定义，它是某些功能的抽象，为了方便适配不同的上下层。

对于AUTOSAR等自动驾驶中间件最主要的作用是：对下，它能够去适配不同的OS内核和架构；对上，它能够提供一个统一的标准接口，负责各类应用软件模块之间的通信以及对底层系统资源的调度。也就是，为上层屏蔽底层的复杂性。