1 中间件的概念界定
1968年，德国举办了NATO软件工程大会，会后发表的一份报告中第一次出现了中间件这个术语。中间件是为应用提供通用服务和功能的软件。数据管理、应用服务、消息传递、身份验证和API管理通常都要通过中间件。
下文中讨论的是智能驾驶操作系统中用于消息传递的分布式通信中间件。分布式通信中间件在智能驾驶领域有着非常重要的地位。智能驾驶功能如算法及应用一般是多个自主模块独立运行，彼此通信实现各种等级的智能驾驶功能。同时，多种智能驾驶功能之间约束和优化、功能安全和信息安全等功能也多以自主模块形式提供。因此分布式通信是智能驾驶及其扩展功能的基础功能，也是系统实时性和可靠性的重要支撑之一。由于智能驾驶域控制器是异构、多芯片、甚至多板卡形式，分布式通信中间件也需要支持进程及线程之间、跨内核、跨芯片、跨板卡等通信，通信形式也包括可靠和非可靠、同步和异步等方法。
2 智能驾驶领域主流分布式通信中间件和其架构
目前应用在智能驾驶领域车载操作系统比较主流的分布式通信中间件有VSOMEIP、DDS、ICEORYX、ROS/ROS2、Apex.OS和AP AUTOSAR。
2.1 VSOMEIP
SOME/IP（Scalable service-Oriented MiddlewarE over IP）是车载以太网通信引入的一个概念，位于OSI 7层模型的层4之上。此中间件是为典型的汽车用例设计的，并且与AUTOSAR兼容。
VSOMEIP则是宝马公司基于SOME/IP协议实现的中间件，实现了服务发现以及通信功能，并在此基础上增加了少许的安全机制。
VSOMEIP通信示意图（来源https://github.com/COVESA/vsomeip/wiki/vsomeip-in-10-minutes）
如图所示，VSOMEIP不仅涵盖了设备之间的SOME/IP通信（跨机通信），还涵盖了内部进程间通信。两个设备通过所谓的通信端点进行通信，这些端点将使用的传输协议（TCP或UDP）及其参数确定为端口号或其他参数。所有这些参数都是可以在VSOMEIP配置文件中进行设置。内部通信是通过本地端点完成的，这些端点由UNIX域套接字使用Boost.Asio库实现。由于这种内部通信不通过中央组件，比如像D-Bus守护程序路由，因此非常快。
2.2 DDS（Data Distribution Service 数据分发服务）
数据分发服务DDS是由OMG组织发布的一个分布式实时系统发布/订阅模型的规范。这个规范定义了一个以数据为中心的发布/订阅模型，提供了一个独立于平台的中间件框架，为实时系统中数据发布、传递和接收的接口和行为提供统一标准。它允许应用程序实时地发布其所能提供的信息，并订阅所需要的信息。除此之外，DDS还支持许多QoS属性，如异步、松耦合、实时可靠数据分发等。DDS规范的目的是简化分布式系统中数据的有效发布，它适用于性能要求高、可预见性强的实时关键任务领域。
DDS域内通信示意图（来源eprosima.com）
目前常用的商用DDS实现有RTI的RTIDDS，开源DDS实现有eprosima公司的Fast-DDS，OCI公司的OpenDDS，eclipse公司的Cyclone DDS，Prismtech公司的OpendSplice DDS等。
Fast DDS和Cyclone DDS在延迟性能方面的比较表明，Fast DDS的平均延迟低于Cyclone DDS。此外， Fast DDS也是更稳定的DDS实现，随着有效载荷变大，延迟增加的速度会变慢。在吞吐性能方面的比较表明，Fast DDS的吞吐量对于每个有效载荷都是最高的，这意味着Fast DDS能够为每个有效载荷每秒发送更多给定大小的消息。但是Fast DDS也有不足之处，在多种厂商的DDS实现中，FastDDS不支持部分QoS策略。
SOME/IP和DDS都允许分布式应用程序使用发布/订阅和请求/响应的方式进行通信，但是也存在很大的差异。
SOME/IP作为AUTOSAR的一部分，开发了一系列规范，描述其序列化协议、服务发现以及集成在CP中的协议标准接口。而DDS应用在更广泛的工业物联网领域，是OMG发布的一系列标准，专门为分布式实时系统设计，应用在很多行业，包括航空航天、国防军工、医疗系统等，在商业和开源领域都有许多独立的实现。应用程序在使用DDS时，不用像SOME/IP一样要绑定到特定的服务实现，通过简单的引用主题和服务，就可以透明地实现一对一和一对多的通信，无需更改代码，比SOME/IP更加灵活。
DDS基于RTPS协议进行传输，可以映射到不同的网络传输协议，RTPS实现了与传输无关地可靠性与分段协议，该协议可以在任何传输之上运行，因此使用DDS可以通过多播UDP处理大数据和可靠数据，而SOME/IP无法做到这一点。
DDS提供了许多QoS策略，使用户可以声明性地指定发布者与订阅者之间如何交换性息，比如资源使用、数据优先级、数据可用性等。而SOMEIP仅提供一种用于选择UDP与TCP的可靠性QoS设置。
2.3 冰羚（ICEORYX）
冰羚实现了真正基于共享内存的“零拷贝”数据传输，将共享内存与发布/订阅架构、服务发现机制、C ++以及无锁算法（lock-free algorithms）相结合。通过添加避免复制的应用程序接口，实现了真正的零拷贝，即数据从“发布者”到 “订阅者”的端到端传输过程中，无需创建任何数据副本。
冰羚零拷贝示意图（来源GitHub - eclipse-iceoryx/iceoryx: Eclipse iceoryx™ - true zero-copy inter-process-communication）
在使用实现“零拷贝”的共享内存中间件冰羚后，系统的运行时间和延迟跟传输的数据量脱离关系。换句话说，系统可以在一定时间内实现几乎无限的数据传输。
但冰羚在使用上稍显复杂。首先，用户在使用订阅发布之前，必须启动一个守护进程，用于管理共享内存以及管理节点发现；其次，在发布数据之前需要先获得一块能够存放数据的内存地址，用户也只能使用定长数据进行传输；此外，冰羚跨机通信依赖于Eclipse公司的Cyclone DDS。
2.4 ROS1/ROS2（Robot Operating System）
ROS 名为机器人操作系统，但它并不是真正的操作系统。最好将其理解为用于开发机器人应用程序的软件开发工具包 (SDK)：它提供开发、调试、测试和最终部署机器人应用程序所需的软件、库和工具。
ROS1与ROS2的架构对比图（来源于网络）
ROS1与ROS2的架构如上图所示，ROS1中依赖Master注册获取节点信息，而ROS2实现了去中心化。ROS2 的应用框架总体分为三个部分，应用层、中间件层和操作系统层。RCL 是中间件层与用户层程序直接交互的接口。RMW 接口层抽象了 DDS的具体实现，可根据用户需求，切换不同的 DDS 实现。ROS2 根据通讯边界，分别做了不同的实现，进程内通讯由 ROS2 实现，际间通讯（进程间和跨机通讯）则采用 DDS实现。这样的通信策略是由于部分 DDS 的进程内通信仍使用回环地址的网络通讯方式，数据要进行用户态与内核态的拷贝，且通讯受限于协议栈，通讯效率低。
ROS的优势：
- 每个供应商提供的DDS接口都不同，如果要更换供应商，则需要更改代码，而ROS提供了一层中间层，使面向用户的接口不变，易于更换底层DDS供应商。
- ROS2为需要创建应用程序的用户提供了生态系统、文档和友好的框架，提供了比DDS更高级别的抽象，因此ROS2更侧重于应用程序开发，消除了不同DDS的复杂订阅发布应用程序编写的困难。
- ROS2不仅仅是实现了通信层的功能，它还提供了机器人技术中常用的包，从基本的座标系转换包到高级的生成环境地图并依此对机器人导航的应用程序；
- 提供了构建系统，从ROS1的catkin到ROS2的colcon，可以轻松的构建包，并指定各个包之间的依赖关系
- 提供了一个启动系统，可以轻松运行由多个互相依赖的应用程序组成的复杂系统，并提供一种更轻松的修改参数的方法；
- 提供了丰富的调试工具，包括回显工具、播包录包工具、以及可视化工具等。
但是，需要注意的是，使用ROS2而不是原生的DDS也会产生成本，ROS2只支持底层各个供应商DDS都支持的QoS策略子集，因此直接使用ROS2无法访问某些DDS的功能和QoS策略。DDS面向应用程序提供的功能要广泛得多，接口和QoS的使用也更加通用、灵活。
2.5 Apex.OS
与ROS一样，Apex.OS并不是真正的操作系统，而是一套软件开发框架，但Apex.OS是经过安全认证的软件开发框架。Apex.OS由Apex.AI公司推出，是为移动设备、智能机器和IoT准备的，基于ROS2开发的汽车操作系统。
Apex.OS对ROS2进行改造，修复了ROS2的一些bug，同时给上游提供监控节点；增强实时性、可靠性以及确定性；和ROS2未来的release同步，保持API兼容。Apex.OS Cert产品通过了ISO26262 Seooc功能安全认证，最高支持ASIL-D，基于Apex.OS可以开发安全相关应用。
Apex Middleware是由Apex.AI推出的能够满足汽车通信需求、支持机器内部通信、支持跨机器通信、支持云端通信的通信中间件。核心组件基于Eclipse Cyclone DDS™ 的高鲁棒性、高性能网络通信和 Eclipse iceoryx™的高效零拷贝通信，它们都是开源项目，并且在汽车和任务关键型分布式系统中得到验证。Apex Middleware和Apex.OS高度优化集成，也可作为一个独立产品。
Apex. Middleware的优势如下：
- 具有跨ECU/ECU内部通信完整的，集成化的解决方案；
- 已经集成到了通用的框架，比如ROS 2，Apex.OS，AUTOSAR Adaptive；
- 支持DDS和SOME/IP，当前汽车以太网最相关的协议；
- 支持发布/订阅和请求/响应通信；
- 能高效处理海量数据，满足驾驶辅助和智能驾驶应用的数据传输需求；
- 低运行时开销的高性能通信；
- 通信发现机制，用于支持现代化的SOA；
- 基于ISO26262的安全认证；
- 大量的QoS特性；
- 提供有效的桥接至网络协议，比如MQTT、AMQP、OPC-UA、Eclipse Zenoh。
2.6 AUTOSAR AP
AUTOSAR Adaptive Platform（AP） 是 ARA（AUTOSAR Runtime for Adaptive Applications）的实现。如下图所示为AP架构逻辑视图。
AP模块示意图（来源《AUTOSAR AP规范Platform Design》）
AP包含执行管理、通信管理、状态管理、诊断管理、网络管理等模块，我们这里重点讨论与通信管理相关的中间件模块。通信管理提供了机器内以及机器间面向服务的通信，包括Event、Method和Fields，可以在设计时，启动时或运行时建立通信伙伴之间的通信路径。该机制的重要组成部分是服务注册中心，它充当中介实例，并且也是通信管理软件的一部分。
AP面向服务示意图（来源《AUTOSAR AP规范Platform Design》）
提供服务的每个应用程序都在服务注册表中注册这些服务。要使用服务，应用程序需要通过查询服务注册表来找到请求的服务，此过程称为服务发现。
通信管理提供了标准化的手段，将定义的服务呈现给应用程序实现者（上层，语言绑定）以及网络上服务数据的相应表示（下层，网络绑定）。这确保了源代码的可移植性以及跨平台的不同实现的已编译服务的兼容性。
语言绑定定义如何通过使用目标编程语言的便捷功能将服务的Method，Event和Field转换为可直接访问的标识符。性能和类型安全性（就目标语言所支持的程度而言）是主要目标。因此，语言绑定通常由Service Interface定义提供的源代码生成器实现。
AP通信模块网络绑定示意图（来源《AUTOSAR AP规范Platform Design》）
网络绑定定义了如何将已配置服务的实际数据序列化并绑定到特定网络。可以基于通信管理配置（AUTOSAR元模型的接口定义），通过解释生成的服务特定配方或直接生成序列化代码本身来实现。当前，通信管理支持SOME / IP，DDS，IPC（进程间通信或任何其他自定义绑定）和Signal PDU（基于信号的网络绑定）。
AUTOSAR AP的优势在于层次化和模块化、配置化、接口标准化。
- 层次化和模块化：AUTOSAR将硬件依赖和非硬件依赖的软件进行了封装，同时模块的层次处理也收集了先进厂家的经验，分享出一个稳定可靠的算法模块框架；
- 配置化：如果使用工具链进行开发，目前的基础软件已做到通过配置参数实现功能剪裁，算法逻辑，提高了基础软件开发效率；
- 接口标准化：有利于降低软件的移植成本。
AP的劣势在于：工具链昂贵且不成熟，供应商不多，且在使用过程中不断发现、修改BUG。同时不同工具链厂商之间没有做好兼容性设计，影响了复用性和独立性。
3 中间件的关键技术
分布式通信中间件需要在分布式的环境中，实现各节点之间数据的正确、高效分发。单个节点需要保持较高的独立性，各个节点之间的耦合度降到最低，任何一个节点产生的异常不影响整个系统的运行。
一次数据的传输过程需要完成如下任务：用户消息的发布与订阅；消息的发现与识别；配对节点的选择与数据链路的建立；消息的高效传输；传输过程中对节点状态的实时监控；用户取消订阅或发布时，数据链路的释放与重建。
因此，分布式通信中间件需要实现链路动态管理、数据高效管理以及系统实时性等关键技术。对于链路管理，其难点主要体现在链路的动态建立及正确地释放；对于数据管理，其难点主要在于找到适当的消息组织方法，以解决消息的高效存取、消息优先级的实现、消息的本地零拷贝、多线程安全以及消息保存的问题；对于实时性的实现，其难点则主要在于攻克高效的本地消息组织方法、节点之间消息投递方式以及节点对消息的处理模式。
3.1 链路管理
链路管理难点主要体现在链路的动态建立及正确的释放。数据链路建立的过程就是发布订阅的配对过程。系统初始并不知道哪些节点会形成发布/订阅关系，而且发布订阅关系也是随节点运行情况动态变化的。这要求发布者/订阅者之间的数据链路必须根据节点运行状态动态建立，用来适应节点运行变化。可以采用询问/应答/确认（三次握手）、定时器技术以及超时重传解决链路建立的问题，如下图所示。
3.2 数据管理
数据管理难点主要在于找到适当的数据组织方式，解决数据的便利存取、优先级的实现、数据本地零拷贝、多线程的安全以及数据保存的问题.
3.2.1 内存数据组织
对于内存数据组织，可以采用队列技术、定时器技术以及锁机制实现一个高效的消息队列来对数据进行管理，满足了系统对消息管理的要求，其实现基于如下两个类：
Message_Node：代表队列中的一个节点，内部分配缓冲区用以保存需要管理的消息数据。一个Message_Node对象实例管理着一条消息数据。该类提供接口设置信息的优先级，用以实现在队列中根据优先级排队。
Message_Queue：消息队列，由很多Message_Node连接而成。内部采用了定时器技术来实现进队、出队的定时，进队、出队操作会一直阻塞到操作成功或者超时失败，从而避免了一直阻塞导致系统无法工作。采用互斥量技术或无锁操作来对多线程操作队列进行同步，保证进队、出队操作的多线程安全。同时提供了put_prior接口实现按优先级进队，操作会根据MessageNode实例的优先级将其插入到队列的合适位置，而不是始终插入到队尾，从而实现数据的按优先级排序。更重要的是队列不直接管理Message Node实例，而是管理Message_Node实例的指针，从而避免了进队出队的拷贝操作，实现了数据本地零拷贝，减小了系统开销。Message_Queue对Message_Block的管理如下图所示。
3.2.2 消息数据持久性
消息数据持久性策略主要解决节点之间时间耦合问题。对于每一个主题消息数据，均可以配置其持久性用以决定主题消息数据是否可重现，具体会存在四种策略：
- 实时消息数据：系统不保存消息数据，发布方生产出消息数据则直接交付系统投递，投递时在线的订阅者可获得该消息数据，不在线的节点则不能获取到消息数据，消息数据没有重现性。
- N条有效：系统在内存中保存最新的N条消息数据。后加入的订阅者可以获取到这N条历史消息数据，这里的N可以由用户设置。
- N秒有效：指的是消息数据从生产出来的时刻算起，有N秒的存活时间，一旦时间超过N秒，则消息数据失效。系统保存所有尚未失效的消息数据。后加入的订阅者可以获取到还存活的历史消息数据，这里的N可以由用户设置。
- 永久保存：即保存所有该主题消息数据，后加入的订阅者可以获取到所有的历史消息数据。
3.2.3 系统实时性
高实时性一直是分布式通信中间件系统的终极目标，衡量实时性的一个最直观的变量就是数据从生产者生产出数据到消费者获取到数据之间的时间间隔。
- 该时间间隔包括以下过程产生的时间开销：
- 数据封装、进入队列阻塞的时间开销；
- 出队的时间开销；
- 出队的数据进入到本地物理网络传输媒介的时间开销；
- 数据在两个节点之间的物理媒介传输的时间开销；
- 数据从本地物理媒介到操作系统用户空间时间开销；
- 从用户空间进入接收队列的时间开销；
- 在接收队列的等待时间
针对以上时间开销可以采取以下的优化措施：
- 采用简单应用层协议，减小封装和解封的时间开销；
- 采用多线程技术，减小数据入队出队的时间开销；
- 采用消息队列管理数据指针，减少数据在本地内存的拷贝；
- 消息数据进行点对点传送，不经过中间节点转发，避开广播，缓解网络拥塞从而减小数据在网络之间的传输时间；
- 采用优先级技术和消息数据质量衡量技术，对消息数据进行分级，过滤掉质量比较低的不符合用户需求的消息数据
4 AICC中间件的架构与实现
4.1 AICC中间件分层架构
AICC中间件分层架构图
AICC中间件分层架构图如上图所示，分为通信层、发现层和用户层。通信层的进程间与进程内通信是由基于共享内存的零拷贝技术实现的，跨机通信是基于DDS实现的，用于用户数据的传输；发现层是用来进行进程内、进程间、跨机通信的发布者/订阅者之间的数据链路建立；用户层用来定义中间件的对外接口。
4.2 AICC中间件实现的功能
AICC中间件实现的功能有订阅/发布、请求/响应两大功能，对两大功能的数据传输过程进行描述。
AICC中间件订阅/发布数据流传输过程表示
AICC中间件订阅/发布数据流传输过程如上图所示。在发现层中，会建立一个网络拓扑结构管理整个域内的节点、订阅者与发布者，他们可以主动加入或退出网络拓扑关系。假设订阅节点先于发布节点上线，当对应的发布节点上线时，会根据拓扑结构里订阅节点的位置，创建所需的真实发布传输通道。通信层的进程内与进程间通信都是通过零拷贝技术实现的，真正实现了基于共享内存的数据零拷贝。同时支持定长与变长数据的传输，传输速度在GB/s级，延迟在us级。而跨机通信是基于DDS实现的，同时实现了与ROS2的互联互通，因此可以利用ROS2的工具，比如ros2 topic list/hz/echo、ros2 bag record/play等。还通过开发一层简单的Adapter层，就可实现基于RVIZ的消息可视化功能，为后期调试提供便利。
AICC中间件请求/响应数据传输过程表示
同时，AICC中间件除了订阅/发布功能，还实现了请求/响应功能，如上图所示。请求响应功能是基于两对订阅/发布实现的，因此，与订阅发布功能采用的通信方式类似，根据Client和Server所处的位置，建立不同的传输协议，进程间与进程内的请求响应也可以实现基于共享内存的数据零拷贝，而跨机依旧依赖于DDS。
请求响应功能实现方式如下，Client端通过Request Topic将某种类型的请求消息传递给Server端，Server端收到请求消息后根据用户传入的处理方法，请求消息处理得到响应消息，并通过Reply Topic将消息传递到Client，至此用户请求操作之后获取到响应消息。
4.3 AICC中间件的优势
AICC中间件的优势有以下几个方面：
在发现层，基于主动拓扑实现链路管理机制。该机制主要用于监测节点的上下线，在DDS的参与者自动发现机制的基础之上，进行了完善， AICC中间件的订阅发布节点上线与下线时，主动调用相关接口，实现即时主动管理节点机制。
在通信层，针对进程间通信，AICC中间件实现了基于共享内存的零拷贝，使得进程间通信发布订阅的只是真实消息数据的地址，对于延迟和吞吐量的提升有一个质的改变，因此延迟时间在us级别，吞吐量在GB/s级别，性能提升很大。对于跨机通信，AICC中间件是基于DDS实现的，对于该实现也能够保证在每个机器部分能够实现消息数据的零拷贝，同时重写序列化与反序列化函数，把不同的数据类型均当作字节流来处理，因此跨机通信的性能也有一定的提升。
同时，在通信层的跨机通信中，AICC中间件通过提供与ROS2序列化与反序列化规则相同的序列化与反序列化函数，建立与ROS2通信的传输器，实现了与ROS2的互联互通。
在用户层，AICC中间件为用户提供的是C接口，方便用户更高层级的封装使用。同时，由于在通信层实现了与ROS2的互联互通功能，在用户层可以复用ROS2几乎全部的工具，比如ros2 topic、ros2 bag以及rviz可视化工具，大大方便了用户的使用。
作者阳阳，多年智能驾驶研发经验，硕士期间从事铰接矿用自卸车的环境感知工作，毕业后专注车载操作系统中间件的研发，擅长基于FastDDS、ICEORYX等中间件进行二次开发。