车载应用项目（盘点车载中间件解决方案）

前言

软件定义汽车时代下，中间件的作用愈发重要。随着 EE 架构逐渐趋于集中化，汽车软件系统出现了多种操作系统并存的局面，这也导致系统的复杂性和开发成本的剧增。为了提高软件的管理性、移植性、裁剪性和质量，需要定义一套架构（Architecture）、方法学（Methodology）和应用接口（ApplicationInterface），从而实现标准的接口、高质量的无缝集成、高效的开发以及通过新的模型来管理复杂的系统，这就是我们所说的“中间件”。汽车行业中有众多的整车厂和供应商，每家 OEM会有不同的供应商以及车型，每个供应商也不止向一家OEM供货，中间件的存在尽可能地让相同产品在不同车型可重复利用或是让不同供应商的产品相互兼容，这样就能大幅减少开发成本。因此，可以说中间件在汽车软硬件解耦的趋势中发挥了关键的作用。

一、 AUTOSAR：目前应用范围最广的车载电子系统标准规范

目前，AUTOSAR拥有 ClassicPlatform和 AdaptivePlatform两大平台，分别对应传统控制类车辆电子系统与对应自动驾驶的高性能类车载电子系统。AUTOSAR（Automotive OpenSystem Architecture）指汽车开放架构，是由全球汽车制造商、零部件供应商以及各种研究、服务机构共同参与制定的一种汽车电子系统的合作开发框架，并建立了一个开放的汽车控制器（ECU）标准软件架构，规范了车载操作系统标准与 API接口。AUTOSAR拥有 Classic Platform和 Adaptive Platform两大平台：

1>Classic Platform（CP）：Classic Platform 是AUTOSAR针对传统车辆控制嵌入式系统的解决方案，具有严格的实时性和安全性限制。从架构来看，ClassicPlatform自下而上可大致分为微控制器、基础软件层、运行环境层和应用软件层。

2> AdaptivePlatform（AP）：AdaptivePlatform是 AUTOSAR面向未来自动驾驶、车联网等复杂场景而提出的一种新型汽车电子系统软件架构标准。Adaptive平台修改了大量Classic平台标准的内容，采用了基于 POSIX标准的操作系统，以面向对象的思想进行开发，并且可使用所有标准的 POSIXAPI，主要目的是为满足当前汽车自动驾驶、电气化和互联互通等趋势的需求。

AUTOSARClassicPlatform架构

数据来源：AUTOSAR 官网，东方证券研究所

AUTOSARAdaptivePlatform架构

数据来源：AUTOSAR 官网，东方证券研究所

相较 Classic Platform，AdaptivePlatform更适应高性能智能汽车的发展。随着通信技术的发展，汽车开始采用以太网通信，车载以太网为汽车ECU带来了更高的带宽，使数据的大量传输能够在短时间得以实现。而 AUTOSARCP是为了传统的车载通信技术 CAN设计的，不能很好地兼容以太网，难以支持基于车载以太网的通信。此外，随着汽车智能化程度提高，诸如自动泊车、环境感知、路径规划等高级功能对处理器的高算力需求远远高于对多核的需求。虽然 AUTOSAR CP已经应用于传统的多核处理技术，但依旧无法满足车辆对 ECU处理能力的需求；从处理器和半导体的技术角度来看，提高性能的唯一方法是多核并行运行，而并行运行以及所谓的异构计算也大大超出了 CP能够覆盖的范围。由于 AUTOSAR CP在通信速率及计算能力方面难以支持高性能智能汽车的发展，2017 年 AUTOSAR 联盟推出了通信能力更强、软件可配置性更灵活的 AUTOSAR AP平台。具体而言，AUTOSAR CP与 AUTOSAR AP主要区别如下：

1>支持的芯片平台不同：AUTOSARCP 主要跑在 8bit、16bit、32bit的 MCU上，对应传统的车身控制、底盘控制、动力系统等功能，如果涉及到自动驾驶的话，AUTOSAR CP 可能无法实现；而 AUTOSARAP主要跑在 64bit以上的高性能MPU/SOC上，对应自动驾驶的高性能电子系统，能够更好地支持多核、多 ECU、多 SoCs并行处理，从而提供更强大的计算能力。

2>定义不同：AUTOSARCP并不只是“中间件”，而是“OS内核 中间件”的一套完整的 “操作系统”，定义了基本的上层任务调度、优先级调度等。分布式架构下的芯片主要是 MCU，每一个 MCU上都需要跑一套 AUTOSARCP，例如在基于分布式架构的 ADAS功能中，AUOTSARCP便是最常见的“操作系统”。不同于 AUTOSARCP自身已经包含了基于OSEK标准的 OS，AUTOSARAP只是一个跑在Lunix、QNX等基于POSIX标准的 OS上面的中间件，因此它自身并不包含 OS，进一步地推进了软硬件解耦进程。

3>架构、通信方式、连接方式不同：（1）AUTOSARCP 采用的是 FOA 架构，而 AUTOSAR AP采用的则是SOA架构；（2）AUTOARCP采用的是基于信号的静态配置通信方式（CAN/LIN等），而AUTOSARAP采用的是基于服务的SOA动态通信方式（SOME/IP）；（3）在 AUTOSARCP中，硬件资源的连接关系受限于线束的连接，而在AUTOSARAP中，硬件资源间的连接关系虚拟化，不局限于通信线束的连接关系。基于SOA通信使得 AP中 ECU 可以动态地与其他ECU进行连接，此外 AP 中各服务模块独立，具有更高的安全性以及 部署灵活性。

ClassicPlatform与 AdaptivePlatform的对比

数据来源：CSDN，东方证券研究所

今后相当长一段时间内 AUTOSAR AP 都不可能彻底取代AUTOSAR CP，二者应用领域不同。在某些方面，AUTOSARAP 与 AUTOSARCP 相比是有一些“劣势”，例如 AUTOSARCP 的时延可低至微秒级、功能安全等级达到了ASIL-D，硬实时；而 AUTOSARAP的时延则在毫秒级，功能安全等级则为ASIL-B，软实时。这也导致二者应用领域的不同：AUTOSAR CP 一般应用在对实时性和功能安全要求较高、对算力要求较低的场景中，如引擎控制、制动等传统ECU；而 AUTOSAR 则应用在对实时性和功能安全有一定要求，但对算力要求更高的场景中，如 ADAS、自动驾驶，以及在动态部署方面追求较高自由度的信息娱乐场景。由于 SOC MCU组合的现象会长期存在，因此在今后相当长一段时间内，AUTOSARAP都不可能彻底取代 AUTOSARCP。最常见的分工是，需要高算力的工作交给 AUTOSARAP,而需要高实时性的工作则交给 AUTOSAR CP。

二、 ROS2：可支持自动驾驶场景的中间件

ROS（RobotOperating System）指的是机器人操作系统，是一套开源的软件框架和工具集，用来帮助开发人员建立机器人应用程序，它提供了硬件抽象、设备驱动、函数库、可视化工具、消息传递和软件包管理等诸多功能。ROS 系统是起源于 2007 年斯坦福大学人工智能实验室的 STAIR项目与机器人技术公司WillowGarage的个人机器人项目（PersonalRobotsProgram）之间的合作，2008年之后就由 WillowGarage来进行推动。ROS项目的初衷是为了给科研机器人WillowGaragePR2 提供一个开发环境和相应的工具。为了让这套软件在更多的机器人上运行， ROS为机器人开发提供了一套相对完善的中间层、工具、软件乃至通用的接口和标准，机器人工业领域的开发者因此能快速开发系统原型并进行测试和验证。

ROS2对 ROS1的部分缺陷实现了改进和提升，产品环境适用度更广。ROS推出以后被大量地应用于工业领域，包括科研机器人、工业机器人、轮式机器人、自动驾驶汽车乃至航天无人驾驶设备，其原来的功能设计已经不能满足海量应用对于某些性能（如实时性、安全性、嵌入式移植等）的需求，ROS2即在这样的背景下被设计和开发。ROS2与 ROS1的主要区别包括：

1>ROS 1 主要构建于 Linux系统之上，主要支持 Ubuntu；ROS 2 采用全新的架构，底层基于DDS（DataDistributionService，是一种专门为实时系统设计的数据分发/订阅标准）通信机制，支持实时性、嵌入式、分布式、多操作系统，ROS2支持的系统包括Linux、windows、 Mac、RTOS，甚至是单片机等没有操作系统的裸机。

2>ROS1 的通讯系统基于 TCPROS/UDPROS，强依赖于master节点的处理；ROS2 的通讯 系统是基于 DDS，取消了 master，同时在内部提供了 DDS的抽象层实现。有了这个抽象层，用户就可以不去关注底层的 DDS 使用了哪个商家的 API，可以让开发者并行开发低耦合的功能模块，并且便于进行二次复用。

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

4>ROS 2新增了 QoS（Quality of Service，质量服务原则），主要对通信的实时性、完整性、历史追溯等方面形成了支持。这大幅加强了框架功能，避免了高速系统难以适用等问题。ROS1 缺少 QoS机制，Topic的稳定性与质量难以保证。

ROS2较 ROS1提升了在产品环境的适用度

数据来源：CSDN，东方证券研究所整理

1>AUTOSAR AP是严格意义上的中间件，即处于计算机 OS与车载ECU特定功能实现之间，为 ECU功能实现层屏蔽掉特定处理器和计算机 OS相关的细节，并提供与车辆网络、电源等系统交互所需的基础服务；ROS2 是作为机器人开发的应用框架，在应用和 OS之间提供了通用的中间层框架和常用软件模块（ROSPackage），某种意义上可以称作操作系统了。

2>AUTOSARAP是一套标准，定义了对应用的标准接口，但没有定义实现细节，平台组件间的交互接口是需要 AUTOSAR AP供应商实现的；ROS 2则是代码优先，每个版本都有完整的代码实现，也定义有面向应用标准 API 接口。

3> AUTOSARAP从一开始就面向 ASIL-B应用；ROS2不是根据 ASIL的标准设计的，ROS2实现功能安全的解决方案是要把底层换为满足ASIL要求的RTOS和商用工具链（编译器）。例如，Apex.AI基于 ROS2定制开发的Apex.OS就已经通过了最高等级的 ASIL-D认证，这实际上是基于 ROS 2的架构去实现一套 AUTOSAR AP 规范。

CyberRT 是百度 Apollo 开发出来的中间件，于Apollo3.5 中正式发布。百度最早用的是ROS 1，但在使用的过程中逐渐发现了 ROS1存在“若ROSMaster出故障了，则任何两个节点之间 的通信便受到影响”的问题，于是希望使用一个“没有中间节点”的通信中间件来代替 ROS 1，那时 ROS 2 还没有推出，因此自主研发出了Cyber RT。Cyber RT 和 ROS2 类似，其底层也是使 用了一个开源版本的 DDS；为了解决 ROS1 的问题，CyberRT 删除了master 机制，用自动发 现机制代替，这个通信组网机制和汽车网络CAN完全一致。此外，Cyber RT的核心设计将调度、任务从内核空间搬到了用户空间。相较于其他中间件方案，Cyber RT 的一大优势是其专为无人架 驶设计，包括基础库、通信层、数据层、计算层。

CyberRT架构

数据来源：CSDN，Apollo，东方证券研究所

三、 Iceoryx：博世自主研发的针对高级自动驾驶应用的通信中间件

Iceoryx是博世旗下子公司ETAS推出的中间件解决方案。ETAS（易特驰）成立于 1994年，是博世的全资子公司。博世在量产 ADAS 领域装配率长期占据市场前三的份额，因此他们对于如何将自动驾驶数据高效流转的需求更为迫切。2020年 7月，ETAS推出了针对高级自动驾驶应用的中间件——Iceoryx （冰羚），Iceoryx是一个适用于各种操作系统的进程间通信（IPC）的中间件，目前已支持Linux、macOS 和 QNX，可兼容 ROS2和AUTOSAR AP的接口，以满足不同开发阶段的需求。

Iceoryx可兼容 AUTOSAR和 ROS2

数据来源：BOSCH，东方证券研究所

传统的数据传输是通过复制副本传输数据，这样会消耗大量内存并产生延迟。由于大量自动驾驶相关的感知数据需要在整个系统内完成快速的流转， 此时进程间通信（Inter-Process Communication，IPC）就需要发挥作用。以 Linux系统为例，不同进程之间传播或交换信息，由于不同进程地址空间相互独立，传递数据时不停的来回拷贝数据，建立和释放堆栈，这个不生成任何价值的拷贝的过程浪费和占有了大量系统资源并产生了不期望的延迟。

传统的数据传输会造成系统的低效率

数据来源：TheEclipseFoundation，东方证券研究所

为了解决 IPC低效率问题，Iceoryx设计了一种“零拷贝”的内存共享技术。“零拷贝”通过事前定义好的通用接口，将需要消费的数据（图片原始 RGB 或者激光点云数据）放入由 Iceoryx申请好的内存空间，然后引入“记数器”这个概念，来记录内存空间中各块数据是否被调用还是释放。当计数器为 0 时，就表示该块数据可以被释放。这样所有的数据调用都发生在共用的内存区域中，免去了各进程将数据拷贝到自己私有存储内，大大提高了数据通信的效率。基于共享内存的拷贝并不是一种创新的通信机制，但 Iceoryx 采用了发布/订阅架构、服务发现、和计数器相结合的机制。通过添加避免复制的应用程序编程接口，实现了所说的真正的零拷贝——一种从发布者到订阅者的端到端的方法，而无需创建一个拷贝。

Iceoryx设计的“零拷贝”通信机制

数据来源：TheEclipseFoundation，东方证券研究所

Iceoryx还需要更多的量产车型的验证以及持续的打磨优化。Iceoryx是开源的，遵从 Apache-2.0许可证，任何个人或者团队都可以免费使用源代码。Iceoryx 取决于 POSIX API，由于不同操作系统的 API会有细微差异，因此将Iceoryx移植到另一个基于 POSIX的操作系统时，可能需要进行细微的改动。但如果需要过 ASIL-B或 ASIL-D等级功能安全认证，那还需要从博世购买相关的安全服务。目前，对于Iceoryx这套中间件来说最大的挑战是需要有主机厂快速搭载量产车上市，来真正检验其价值。另外由于自动驾驶感知信息种类越来越多，激光点云数据、摄像头 RGGB帧、 3D毫米波雷达目标信息以及 4D毫米波雷达点云信息、整车信号数据等，如何高效申请和分配内存块也是实现真正“零拷贝”的前提，这也需要在实际项目中不断打磨优化。

四、其他通信中间件：SOME/IP与 DDS等

根据源代码是否开放，通信中间件可简单地分为闭源和开源两种：

1>闭源的通信中间件主要有Vector公司的SOME/IP、RTI公司的DDS等；

2>开源的通信中间件主要有OPENDDS、FASTDDS、CycloneDDS等。

SOME/IP

严格来说，SOME/IP 不是一款特定的产品，而是一种技术标准。2011年，BWM设计和提出了 SOME/IP，SOME/IP全称为ScalableService-oriented Middleware over IP，拆分起来理解就是以 Server-Client服务形式进行通信，并且服务具备高度可扩展性。在传统以太网中，OSI将以太网分层七层，但汽车行业将 OSI5-7层统称为应用层，因此车载以太网只有 5层。SOME/IP协议是一种应用层协议，运行在 TCP/UDP 传输协议之上（车载以太网第四层以上），作为以太网通信中间件来实现应用层和IP层的数据交互，使其不依赖于操作系统，同时又能兼容AUTOSAR和非 AUTOSAR 平台。因此SOME/IP可以独立于硬件平台、操作系统和编程语言。

SOME/IP是一种面向服务的传输协议

数据来源：CDSN，东方证券研究所

SOME/IP运行在车载以太网第四层以上

数据来源：CDSN，东方证券研究所

SOME/IP可支持AUTOSARCP、AUTOSAR AP以及非AUTOSAR平台之间的通信交互。BWM 设计 SOME/IP 协议之后，SOME/IP被 AUTOSAR纳入其正式标准，并随着 CP 规范发布而被广泛用于车载以太网，因此可以说是 AUTOSARCP 推动了 SOME/IP 的广泛使用。借助SOME/IP协议的高度平台扩展性，可以实现不同平台的数据交互，而统一的SOME/IP通信机制是不同平台 通信的前提。为了在不同软件平台上运行 SOME/IP，使得整车以太网上实现 SOA 架构通信机制，所以AP规范中也同步引入了SOME/IP，因此对于AUTOSAR系统，CP和AP之间实现SOME/IP 通信，是比较容易的。为了使非 AUTOSAR软件平台和车内 CP 和 AP ECU 更好地交互，GENIVI系统同样也开发了一套开源vSOME/IP 软件源码，以便和CP/AP交互。但vSOME/IP 是开源的，所以性能会差一些，因此需要统一的规范来做约束，从而做一些深层次的二次开发。当前，全球 最大的商用 SOME/IP 产品供应商是 Vector，开源版的vSOME/IP则是由GENIVI 协会来维护的。

AUTOSAR推动了SOME/IP协议的广泛使用

数据来源：CDSN，东方证券研究所

DDSDDS（DataDistributionService）指的是数据分发服务，是由OMG发布的分布式通信规范。OMG（ObjectManagementGroup）成立于1989年，是一个国际性、开放性、非盈利性技术标准联盟，由供应商、终端用户、学术机构、政府机构推动，到现在已有30多年历史。OMG工作组会针对各种技术和行业制定企业集成标准，并开发可为数千个垂直行业提供现实价值的技术标准，其中包括统一建模语言SYSML、UML，以及中间件标准CORBA、DDS等。DDS最早应用于美国海军系统，用于解决军舰系统复杂网络环境中大量软件升级的兼容性问题。随着DDS被ROS2以及AUTOSAR引入，目前DDS已被广泛应用于航空、航天、船舶、国防、金融、通信、汽车等领域。DDS采用发布/订阅模型，提供多种 QoS服务质量策略，以保障数据实时、高效、灵活地分发，可满足各种分布式实时通信的应用需求。DDS将分布式网络中传输的数据定义为“主题”，将数据的产生和接收对象分别定义为“发布者”和“订阅者”，从而构成数据的发布/订阅传输模型（Data-Centric Publish-Subscribe，DCPS）。各个节点在逻辑上无主从关系，点与点之间都是对等关系，通信方式可以是点对点、点对多、多对多等，在 QoS的控制下建立连接，自动发现和配置网络参数。

DDS采用发布/订阅模型

数据来源：DDS Foundation，东方证券研究所

目前 DDS已被多个车载中间件平台引入。2018年，DDS首次被引进 AUTOSAR AP，以作为可选择的通信方式之一。2018年3月，DDS的主要提供者RTI公司宣布，AUTOSARAP当时的最新版本（版本18-03）已经具有DDS标准的完整网络绑定。此外，AUTOSAR CP的标准规范中是不支持 DDS的，但做一些变通后也可以在 CP上集成DDS。如前文所述，ROS2和 CyberRT的底层也均使用了开源的 DDS，将 DDS 作为最重要的通信机制。与中间件相对应，Xavier、Orin等面向自动驾驶的 SOC 芯片上也都预留了 DDS 接口。目前，全球DDS最大的供应商是美国的 RTI（Real-TimeInnovations）公司，约占据市场 80%的份额。RTI 作为 OMG组织董事会的成员，也主导了 DDS 标准的制定，在行业内有足够的权威。

RTI是全球 DDS最大的供应商

数据来源：RTI，东方证券研究所

开源 DDS是相对于商用的 RTI DDS等而言的，其也是根据 OMG官方标准开发的，但源代码开放，主要包括 FastDDS或 OpenDDS等。尽管开源 DDS会对 RTI的商用DDS形成一定竞争，但开源 DDS也存在不足：（1）开源 DDS的使用门槛高，例如 RTIDDS的服务策略有 50多个，但开源 DDS的服务策略只有 23个，完整程度远不及前者；（2）RTI的DDS已经通过了ASIL-D的认证，但开源DDS还没有。

SOME/IP与 DDS的不同

SOME/IP与DDS是目前自动驾驶上用得最多的两类通信中间件，二者的共同点主要有：（1）都是面向服务的通信协议；（2）都采用了“以数据为中心”的发布/订阅模式。当然 SOME/IP 与DDS在很多方面也存在不同，主要区别如下：

1>主要应用领域不同：SOME/IP 是专为汽车领域开发出来的，它针对汽车领域的需求定义了一套通信标准，而且在汽车领域深耕的时间比较长；DDS是一个工业级别的强实时的通信标准，它对场景的适应性比较强，但在用于汽车/自动驾驶领域时需要做专门的裁剪。

2>灵活性、可伸缩性不同：相较于 SOME/IP，DDS引入了大量的标准内置特性，例如基于内容和时间的过滤、与传输无关的可靠性、持久性、存活性、延迟/截至时间监视、可扩展类型等。当 AUTOSARAP与 DDS一起构建通信框架时，该框架不仅可以与现有API及应用程序兼容，并且在可靠性、性能、灵活性和可伸缩性等方面，都可以提供重要的好处。

3>订阅方和发布方是否强耦合：在 SOME/IP中，在正常数据传输前，订阅方需要与发布方建立 网络连接并询问发布方是否提供所需服务，在这个层面上，节点之间仍然具有一定耦合性。 在 DDS标准下，每个订阅方或发布方只需要在自己的程序里面订阅或发布传感器数据就行了，不需要关心任何连接。因此在DDS中，服务订阅方和发布方的解耦更加彻底。

4>服务策略不同：较好的QoS是 DDS标准相比于 SOME/IP最重要的特征。SOME/IP只有一个 QoS；而 RTIDDS和开源 DDS里面分别有 50多个和20多个QoS，这些 QoS基本上能涵盖绝大多数可以预见到的智能驾驶场景。

5>应用场景不同：从应用场景的角度来看，SOME/IP比较偏向于车载网络，且只能在基于网络层为 IP类型的网络环境中使用；而DDS在传输方式上没有特别的限制，对基于非IP类型的网络，如共享内存、跨核通讯、PCI-E 等网络类型都可以支持。而且，DDS也有完备性的车联网解决方案，其独有的 DDSSecurity、DDSWeb功能可为用户提供车-云-移动端一站式的解决方案。

在商业落地中，SOME/IP与 DDS是直接竞争关系，但由于二者在应用领域、灵活性、服务策略等方面存在差异，因此整车厂可以按需进行选择合适的通信中间件，二者甚至是可以共存的。这也是为什么 AUTOSAR AP既支持 SOME/IP也支持DDS。

,