盘点车载中间件解决方案
The following article is from 智能汽车设计 Author 东方证券
前言
软件定义汽车时代下，中间件的作用愈发重要。随着E/E架构逐渐趋于集中化，汽车软件系统出现了多种操作系统并存的局面，这也导致系统的复杂性和开发成本的直线上升。为了提高软件的管理性、移植性、裁剪性和质量，需要定义一套架构（Architecture）、方法学（Methodology）和应用接口（ApplicationInterface），从而实现标准的接口、高质量的无缝集成、高效的开发以及通过新的模型来管理复杂的系统，这就是我们所说的“中间件”。汽车行业中有众多的整车厂和供应商，每家OEM会有不同的供应商以及车型，每个供应商也不止向一家OEM供货，中间件的存在尽可能地让相同产品在不同车型实现可重复利用或是让不同供应商的产品相互兼容，这样就能大幅减少开发成本。因此，可以说中间件在汽车软硬件解耦的趋势中发挥了关键的作用。
01
AUTOSAR：目前应用范围最广的
车载电子系统标准规范
目前，AUTOSAR拥有ClassicPlatform和AdaptivePlatform两大平台，分别对应传统控制类车辆电子系统与对应自动驾驶的高性能类车载电子系统。AUTOSAR（Automotive Open System Architecture）指汽车开放架构，是由全球汽车制造商、零部件供应商以及各种研究、服务机构共同参与制定的一种汽车电子系统的合作开发框架，并建立了一个开放的汽车控制器（ECU）标准软件架构，规范了车载操作系统标准与API接口。AUTOSAR拥有Classic Platform和Adaptive Platform两大平台：
1、Classic Platform（CP）：Classic Platform是AUTOSAR针对传统车辆控制嵌入式系统的解决方案，具有严格的实时性和安全性限制。从架构来看，ClassicPlatform自下而上可大致分为微控制器、基础软件层、运行环境层和应用软件层。
2、AdaptivePlatform（AP）：Adaptive Platform是AUTOSAR面向未来自动驾驶、车联网等复杂场景而提出的一种新型汽车电子系统软件架构标准。Adaptive平台修改了大量Classic平台标准的内容，采用了基于POSIX标准的操作系统，以面向对象的思想进行开发，并且可使用所有标准的POSIXAPI，主要目的是为满足当前汽车自动驾驶、电气化和互联互通等趋势的需求。
AUTOSAR Classic Platform架构
数据来源：AUTOSAR官网，东方证券研究所
AUTOSAR Adaptive Platform架构
数据来源：AUTOSAR官网，东方证券研究所
相较Classic Platform，Adaptive Platform更适应高性能智能汽车的发展。随着通信技术的发展，汽车开始采用以太网通信，车载以太网为汽车ECU带来了更高的带宽，使数据的大量传输能够在短时间得以实现。而AUTOSAR CP是为了传统的车载通信技术CAN设计的，不能很好地兼容以太网，难以支持基于车载以太网的通信。此外，随着汽车智能化程度提高，诸如自动泊车、环境感知、路径规划等高级功能对处理器的高算力需求远远高于对多核的需求。虽然AUTOSAR CP已经应用于传统的多核处理技术，但依旧无法满足车辆对ECU处理能力的需求；从处理器和半导体的技术角度来看，提高性能的唯一方法是多核并行运行，而并行运行以及所谓的异构计算也大大超出了CP能够覆盖的范围。由于AUTOSAR CP在通信速率及计算能力方面难以支持高性能智能汽车的发展，2017年AUTOSAR联盟推出了通信能力更强、软件可配置性更灵活的AUTOSAR AP平台。具体而言，AUTOSAR CP与AUTOSAR AP主要区别如下：
1、支持的芯片平台不同：AUTOSAR CP主要跑在8bit、16bit、32bit的MCU上，对应传统的车身控制、底盘控制、动力系统等功能，如果涉及到自动驾驶的话，AUTOSAR CP 可能无法实现；而AUTOSAR AP主要跑在64bit以上的高性能MPU/SoC上，对应自动驾驶的高性能电子系统，能够更好地支持多核、多ECU、多SoCs并行处理，从而提供更强大的计算能力。
2、定义不同：AUTOSAR CP并不只是“中间件”，而是“OS内核+中间件”的一套完整的“操作系统”，定义了基本的上层任务调度、优先级调度等。分布式架构下的芯片主要是MCU，每一个MCU上都需要跑一套AUTOSAR CP，例如在基于分布式架构的 ADAS功能中，AUOTSAR CP便是最常见的“操作系统”。不同于AUTOSAR CP自身已经包含了基于OSEK标准的OS，AUTOSAR AP只是一个跑在Lunix、QNX等基于POSIX标准的OS上面的中间件，因此它自身并不包含OS，进一步地推进了软硬件解耦进程。
3、架构、通信方式、连接方式不同：
（1）AUTOSAR CP采用的是FOA架构，而 AUTOSAR AP采用的则是SOA架构；
（2）AUTOAR CP采用的是基于信号的静态配置通信方式（CAN/LIN等），而AUTOSAR AP采用的是基于服务的SOA动态通信方式（SOME/IP）； （3）在AUTOSAR CP中，硬件资源的连接关系受限于线束的连接，而在AUTOSAR AP中，硬件资源间的连接关系虚拟化，不局限于通信线束的连接关系。
基于SOA通信使得AP中ECU可以动态地与其他ECU进行连接，此外AP中各服务模块独立，具有更高的安全性以及部署灵活性。
Classic Platform与Adaptive Platform的对比
数据来源：CSDN，东方证券研究所
今后相当长一段时间内AUTOSAR AP都不可能彻底取代AUTOSAR CP，二者应用领域不同。在某些方面，AUTOSAR AP与AUTOSAR CP相比是有一些“劣势”，例如AUTOSAR CP的时延可低至微秒级、功能安全等级达到了ASIL-D，硬实时；而AUTOSAR AP的时延则在毫秒级，功能安全等级则为ASIL-B，软实时。这也导致二者应用领域的不同：AUTOSAR CP一般应用在对实时性和功能安全要求较高、对算力要求较低的场景中，如引擎控制、制动等传统ECU；而AUTOSAR AP则应用在对实时性和功能安全有一定要求，但对算力要求更高的场景中，如 ADAS、自动驾驶，以及在动态部署方面追求较高自由度的信息娱乐场景。由于SoC+MCU组合的现象会长期存在，因此在今后相当长一段时间内，AUTOSAR AP都不可能彻底取代AUTOSAR CP。最常见的分工是，需要高算力的工作交给AUTOSAR AP，而需要高实时性的工作则交给AUTOSAR CP。
02
ROS2：可支持
自动驾驶场景的中间件
ROS（Robot Operating System）指的是机器人操作系统，是一套开源的软件框架和工具集，用来帮助开发人员建立机器人应用程序，它提供了硬件抽象、设备驱动、函数库、可视化工具、消息传递和软件包管理等诸多功能。ROS系统是起源于2007年斯坦福大学人工智能实验室的STAIR项目与机器人技术公司WillowGarage的个人机器人项目（PersonalRobotsProgram）之间的合作，2008年之后就由 WillowGarage来进行推动。ROS项目的初衷是为了给科研机器人WillowGaragePR2提供开发环境和相应的工具。为了让这套软件在更多的机器人上运行，ROS为机器人开发提供了一套相对完善的中间层、工具、软件乃至通用的接口和标准，机器人工业领域的开发者因此能快速开发系统原型并进行测试和验证。
ROS2对ROS1的部分缺陷实现了改进和提升，产品环境适用度更广。ROS推出以后被大量地应用于工业领域，包括科研机器人、工业机器人、轮式机器人、自动驾驶汽车乃至航天无人驾驶设备，其原来的功能设计已经不能满足海量应用对于某些性能（如实时性、安全性、嵌入式移植等）的需求，ROS2即在这样的背景下被设计和开发。ROS2与ROS1的主要区别包括：
1、ROS1主要构建于Linux系统之上，主要支持Ubuntu；ROS2采用全新的架构，底层基于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、ROS2新增了QoS（Quality of Service，质量服务原则），主要对通信的实时性、完整性、历史追溯等方面形成了支持。这大幅加强了框架功能，避免了高速系统难以适用等问题。ROS1缺少QoS机制，Topic的稳定性与质量难以保证。
ROS2较ROS1提升了在产品环境的适用度
数据来源：CSDN，东方证券研究所整理
1、AUTOSAR AP是严格意义上的中间件，即处于计算机OS与车载ECU特定功能实现之间，为 ECU功能实现层屏蔽掉特定处理器和计算机OS相关的细节，并提供与车辆网络、电源等系统交互所需的基础服务；ROS2是作为机器人开发的应用框架，在应用和OS之间提供了通用的中间层框架和常用软件模块（ROSPackage），某种意义上可以称作操作系统了。
2、AUTOSAR AP是一套标准，定义了对应用的标准接口，但没有定义实现细节，平台组件间的交互接口是需要AUTOSAR AP供应商实现的；ROS2则是代码优先，每个版本都有完整的代码实现，也定义有面向应用标准API接口。
3、AUTOSAR AP从一开始就面向ASIL-B应用；ROS2不是根据ASIL的标准设计的，ROS2实现功能安全的解决方案是要把底层换为满足ASIL要求的RTOS和商用工具链（编译器）。例如Apex.AI基于ROS2定制开发的Apex.OS就已经通过了最高等级的ASIL-D认证，这实际上是基于ROS2的架构去实现一套AUTOSAR AP规范。
03
业内主要中间件：
CyberRT和Iceoryx
CyberRT
CyberRT是百度Apollo开发出来的中间件，于Apollo3.5 中正式发布。百度最早用的是ROS1，但在使用的过程中逐渐发现了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系统为例，不同进程之间传播或交换信息，由于不同进程地址空间相互独立，传递数据时不停的来回拷贝数据，建立和释放堆栈，这个不生成任何价值的拷贝过程浪费和占有了大量系统资源并产生了不期望的延迟。
Iceoryx设计的“零拷贝”通信机制
数据来源：TheEclipseFoundation，东方证券研究所
Iceoryx还需要更多的量产车型的验证以及持续打磨优化。Iceoryx是开源的，遵从 Apache-2.0许可证，任何个人或者团队都可以免费使用源代码。Iceoryx取决于 POSIX API，由于不同操作系统的API会有细微差异，因此将Iceoryx移植到另一个基于 POSIX的操作系统时，可能需要进行细微的改动。但如果需要过ASIL-B或 ASIL-D等级功能安全认证，那还需要从博世购买相关的安全服务。目前，对于Iceoryx这套中间件来说最大的挑战是需要有主机厂快速搭载量产车上市，来真正检验其价值。另外由于自动驾驶感知信息种类越来越多，激光点云数据、摄像头 RGGB帧、3D毫米波雷达目标信息以及4D毫米波雷达点云信息、整车信号数据等，如何高效申请和分配内存块也是实现真正“零拷贝”的前提，这也需要在实际项目中不断打磨优化。
04
其他通信中间件：
SOME/IP与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可支持AUTOSAR CP、AUTOSAR AP以及非AUTOSAR平台之间的通信交互。BWM设计SOME/IP协议之后，SOME/IP被AUTOSAR纳入其正式标准，并随着CP规范发布而被广泛用于车载以太网，因此可以说是AUTOSAR CP推动了SOME/IP的广泛使用。借助SOME/IP协议的高度平台扩展性，可以实现不同平台的数据交互，而统一的SOME/IP通信机制是不同平台通信的前提。为了在不同软件平台上运行SOME/IP，使得整车以太网上实现SOA架构通信机制，所以AP规范中也同步引入了SOME/IP，因此对于AUTOSAR系统，CP和AP之间实现SOME/IP 通信，是比较容易的。为了使非AUTOSAR软件平台和车内CP和APECU更好地交互，GENIVI系统同样也开发了一套开源vSOME/IP软件源码，以便和CP/AP交互。但vSOME/IP是开源的，所以性能会差一些，因此需要统一的规范来做约束，从而做一些深层次的二次开发。当前，全球最大的商用SOME/IP产品供应商是Vector，开源版的vSOME/IP则是由GENIVI协会来维护的。
AUTOSAR推动了SOME/IP协议的广泛使用
数据来源：CDSN，东方证券研究所
DDS
DDS（Data Distribution Service）指的是数据分发服务，是由OMG发布的分布式通信规范。OMG（Object Management Group）成立于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接口。
SOME/IP与 DDS的不同
SOME/IP与DDS是目前自动驾驶上用得最多的两类通信中间件，二者的共同点主要有：
（1）都是面向服务的通信协议； （2）都采用了“以数据为中心”的发布/订阅模式。
当然SOME/IP与DDS在很多方面也存在不同，主要区别如下：
1、主要应用领域不同：SOME/IP是专为汽车领域开发出来的，它针对汽车领域的需求定义了一套通信标准，而且在汽车领域深耕的时间比较长；DDS是一个工业级别的强实时的通信标准，它对场景的适应性比较强，但在用于汽车/自动驾驶领域时需要做专门的裁剪。
2、灵活性、可伸缩性不同：相较于SOME/IP，DDS引入了大量的标准内置特性，例如基于内容和时间的过滤、与传输无关的可靠性、持久性、存活性、延迟/截至时间监视、可扩展类型等。当AUTOSAR AP与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、DDS Web功能可为用户提供车-云-移动端一站式的解决方案。
在商业落地中，SOME/IP与DDS是直接竞争关系，但由于二者在应用领域、灵活性、服务策略等方面存在差异，因此整车厂可以按需进行选择合适的通信中间件，二者甚至是可以共存的。这也是为什么AUTOSAR AP既支持SOME/IP也支持DDS。