为自动驾驶保驾护航—谈谈主流中间件设计
随着国内外新势力车厂的快速崛起，汽车智能化水平不断提升。整车中央计算平台，自动驾驶域控制器持续走热。
谈起自动驾驶，可能更多的人想到的是AI技术、如Mobileye视觉感知、地图、各类规划算法、控制、大数据。目前越来越多的主机厂聚焦于数据如何更高效和准确的通信，随着自动驾驶等级从L2向L2++甚至L3/L4过渡，对于数据传输要求越来越高。中间件开发和应用一下子被推到了风口浪尖。 谈到中间件，我们不得不先讲一下操作系统OS。
操作系统有广义和狭义之分。
狭义的操作系统大家都比较熟悉，手机设备上的ios、Android、车载系统中Linux、QNX都是狭义的操作系统，通常包括内核、文件系统、驱动以及部分协议栈整合在内核中。
广义的操作系统一般包含操作系统内核、硬件驱动层和中间件。在各家新能源车厂高谈软件定义汽车时代已到来时，真正能全面掌握芯片、操作系统、中间件、算法以及常用常新的应用才能走在技术最前沿。其中广义操作系统是核心中的核心，已成为国内外主机厂自主研发比拼的方向。 
图1广义和狭义OS框图
回头再来谈谈中间件。中间件是什么，按字面意思翻译过来就是中间一层组件。实际是介于操作系统/底层软件和应用软件之间的桥梁。整个系统软件可以通过中间件在不同的处理器架构和芯片间共享数据。
一套成熟的中间件给开发带来的收益往往是指数级别的进步，大大缩短开发周期和系统稳定度、屏蔽底层硬件差异性做到统一的API接口。
图2自动驾驶中间件应用
那么自动驾驶需要怎样的中间件？低时延、高带宽和多并发。
从整车功能域角度出发，自动驾驶是收集外部传感器数据量最大的模块，为了持续探测到车身四周各种复杂环境信息，需要毫米波、摄像头和激光雷达配合以达到360度无死角感知。并且为了保证安全，所有数据都需要接近实时的速度处理，为了保证大量数据的实时处理，较低的数据延迟需要由高性能的计算单元和高带宽的网络通信，数据可轻易在不同内核中共享。
图3 自动驾驶360度传感器感知示意图
传感器类型 | 典型带宽需求 |
3D毫米波 | 2M/s |
4D毫米波 | 100M/s |
8M摄像头 | 2G/s - 3G/s |
100线激光雷达 | 1G/s |
表1 传感器典型带宽
从上表中可以知道随着自驾功能不断升级，对于传感器的传输数据带宽和传输延迟要求也在不断提升。为了满足此需求，业界各家自驾公司也在开发自己的自动驾驶中间件以满足要求。
ICEORYX：
博世在量产ADAS领域装配率长期占据市场前三的份额，他们对于如何将自动驾驶数据高效流转的需求更为迫切，为此在大神Michael Pöhnl带领下，专门为自动驾驶开发了一套中文名叫“冰羚”，英文名ICEORYX的中间件。
如上面所说，大量自动驾驶相关的感知数据需要在整个系统内完成快速的流转，这里就不得不提一下进程间通信（Inter ProcessCommunication）这个概念。拿大家最常用的Linux系统举例，不同进程之间传播或交换信息，由于不同进程地址空间相互独立，传递数据时不停的来回拷贝数据，建立和释放堆栈，这个不生成任何价值的拷贝的过程浪费和占有了大量系统资源并产生了不期望的延迟。
图4 进程间通信
ICEORYX为了解决上面的问题，设计了一种“零拷贝”的内存共享技术来优化之前ADAS量产项目中遇到的困扰。
这种“零拷贝”通过事前定义好的通用接口，将需要消费的数据（图片原始RGB或者激光点云数据）放入由ICEORYX申请好的内存空间，然后引入“记数器”这个概念，来记录内存空间中各块数据是否被调用还是释放，当计数器为0时，就表示该块数据可以被释放。这样所有的数据调用都发生在共用的内存区域中，免去了各进程将数据拷贝到自己私有存储内，大大提高了数据通信的效率。
下面套用一张博世官方介绍材料中的图，基于共享内存的拷贝其实并不是一种创新的通信机制，但ICEORYX采用了发布/订阅架构、服务发现、和计数器相结合的机制。通过添加避免复制的应用程序编程接口，实现了所说的真正的零拷贝——一种从发布者到订阅者的端到端的方法，而无需创建一个拷贝。
图5 零拷贝通信（引用1）
发布者将数据写入事前申请好的内存块中，订阅者可以收到这些内存块的实时状态，并且知道哪些内存块正在处理中，哪些内存块将被释放。发布者可以在订阅者读取数据块的时候同时再次写入而不收到任何时间干扰和延迟，因为即使之前的内存块在被读取中，发布者也可以选择之前已经分配好的新的内存块中操作。
ICEORYX是开源的，遵从Apache-2.0许可证。任何个人或者团队都可以免费使用源代码，但如果需要过ASIL-B或ASIL-D等级功能安全认证，那还需要从博世购买相关的安全服务。
目前对于ICEORYX这套中间件来说最大的挑战还是需要有主机厂快速搭载量产车上市，来真正检验其价值。另外由于自动驾驶感知信息种类越来越多，激光点云数据、摄像头RGGB帧、3D毫米波雷达目标信息以及4D毫米波雷达点云信息，整车信号数据等，如何高效申请和分配内存块也是实现真正“零拷贝”的前提，这少不了在实际项目中不断打磨优化。
ROS2：
接下来我们再来看一下大名鼎鼎的ROS2。
说到ROS2不得不先聊一下ROS(Robot Operating System), ROS2正是从ROS发展升级过来的。ROS最早开发出来是去适配机器人的一套开源软件系统，里面包含3000多个基础库、灵活的进程间通信机制、底层驱动、硬件抽象等。
如前文所述，自动驾驶是非常复杂并对安全性要求很高，它包含了车道线检测、目标物检测、障碍物检测、决策、控制模块等；需要将这些功能各异的模块集成到一起，形成一个端到端系统。所以要找到一个适合的中间件框架很不容易，ROS在学术界和机器人届广泛使用、消息机制灵活开发以及丰富调试工具恰恰符合自动驾驶开发的需求。我们看到国内自动驾驶黄埔军校百度在早期Apollo1.0/2.0版本中正是选用了ROS框架。
但是在实际开发应用中，开发人员发现了ROS适配自动驾驶的不足之处。比如ROS通信延迟太大，数据从发布节点到订阅节点之间需要进行拷贝，在机器人设计中可能还不是一个Block点，但在自动驾驶系统中很显然会大大影响数据的传输效率。另外ROS的单Master节点机制也是一个瓶颈，所有的子节点通信都需要借助单一的通信主节点。万一主节点出现故障，整个系统也会受到影响。为了解决ROS的明显缺陷，百度Apollo在3.5版本后发布了自研的Cyber RT框架来取代ROS。
图6 以Master为中心的ROS交互机制
ROS社区和组织也意识到了不足之处，并于2016年底正式发布了ROS2 beta版，新一代的ROS之中，带来了整体架构的革新以解决前一代的不足。
ROS底层基于DDS（Data Distribution Service）通信机制，取消了ROS上Master模式。DDS遵从发布和订阅模式，创建全局的数据块。然后每一个数据的发布或者订阅者都是数据的参与者，可以读写全局的数据。同时也保留了ROS中Topic数据结构概念。
图7 基于Topic话题的发布/订阅流程
另外DDS一个重要特质是支持QoS（Quality ofService），满足在不同场景对于不同数据传输的实时性要求。每个数据传输都可以通过QoS策略选择不同的选项进行配置，ROS2中支持传输期限、可靠性传输、历史信息等策略。
图8 支持QoS策略的DDS机制
当然目前ROS2整体稳定度和应用案例还远不如ROS，但拥有了以上特性的ROS2系统，我们拭目以待。
极氪软件和电子中心，秉承平等、多元、共成长的价值观，对产品持续极致追求，为用户提供用心体验。从中央计算、智能区域控制器、整车OTA、智能车身控制、整车软件等领域出发，打造行业顶级的电子电气架构，为智能电动车保驾护航。
目前我们一直在开发中央计算和区控制器内高效IPC通信并应用在量产项目中，除了会包含上面提到的共享内存和DDS技术外，还会用到SOME/IP协议来加强不同服务数据之间的传输效率。
图9 极氪中间件框图
另外ZEEKR OS也正在热火朝天的开发测试中，作为中央计算SoC核心中间件，将管理整车服务（支持自动驾驶、车身电子控制、底盘、三电和智能座舱等功能持续迭代）、提供基础平台、高度分层解耦、分布式管理。 搭载ZEEKR OS的下一代3.0中央计算平台将采用全栈自研，专注打造一套高效稳定的整车软件中间件，为自动驾驶、SOA和整车OTA服务提供核心竞争力并持续赋能。
