2022年汽车软件行业之汽车中间件专题分析

1、2022年汽车软件行业之汽车中间件专题分析1.汽车软件：汽车中间件是汽车软件中的重要基础软件观点一：汽车中间件重要性有望进一步提升汽车中间件独特的功能属性，满足汽车智能化需求。中间件的诞生与 IT 架构的变化紧密 相关，其在 IT 架构中的位置也决定了其独特的功能属性。从传统 IT 架构的角度看，中间 件的位于上层应用和底层操作系统之间，其起源与分布式架构下异构环境中的通信需求相 关，在功能上具有交互支持，公共服务两大类功能。在汽车领域，当前汽车以分布式架构 步入智能化阶段，存在大量的交互需求；在汽车智能化趋势下，多样的底层方案共同发展， 中间件交互支持，屏蔽底层复杂性的功能顺应了汽车智能化的

2、趋势。观点二：汽车中间件发展与汽车电子电气架构相关，功能或进一步丰富汽车中间件发展与汽车电子电气架构变革紧密相关。汽车电子架构变革与汽车中间件发展 具有紧密的联系。汽车电子架构从分布式到域架构的变革，背后反映出的是汽车从机械化 到电子化、智能化的变革，汽车以分布式架构步入智能化阶段，汽车中间件的需求持续显 现。在这一过程中，汽车中间件的代表 AutoSAR 从无到有，从 CP 发展到 AP，并且产生 了 ROS2 等多种顺应智能驾驶时代的中间件路线。未来汽车架构进一步集中，有望提供更 强的算力，中间件的功能也有望随之进一步丰富，体现为能力边界拓展。 中间件能力边界逐步拓展。从中间件的能力边界看

3、，中间件的能力边界逐步扩展，部分厂 商提供的中间件产品除了传统的中间件外，也包含了部分功能软件、操作系统层级的模块， 中间件厂商正逐步从中间件向操作系统、配置工具和解决方案领域拓展。观点三：AutoSAR 诞生与汽车电子化过程相关，具备生态优势0 到 AutoSAR CP：汽车电子化。随着汽车电子化的推进，AutoSAR 组织诞生并发展壮 大。AutoSAR CP 标准适用于车身控制、底盘控制、动力系统等场景，AutoSAR 标准定义 了模型、组件、接口的标准描述(ARXML 文件)，并且提供了基础软件(BSW)规范，使不同 环节得以衔接。这一阶段，AutoSAR 的出现形成了囊括主机厂、Ti

4、er1、中间件厂商等在 内的汽车软件开发流程，中间件供应商提供相应工具，为汽车软件开发的重要角色。观点四：AutoSAR 不断迭代以顺应智能化趋势，产业落地经验较多AutoSAR CP 到 AutoSAR AP：汽车智能化。进入智能化时代，智能汽车对于中间件提 出了更新的要求，AutoSAR AP 于 2017 年应运而生。在架构方面由三层架构简化为两层， 并通过支持基于 POSIX 的操作系统，提供对大规模编程与封装的良好支持，面向服务的 通信等变革，更好的支持汽车智能化应用。此外，机器人编程框架 ROS2 同样可适用于自 动驾驶场景。这一阶段，商业化 AP 产品在 AP 架构基础上提供多种

5、工具。中间件厂商加 速发展。观点五：汽车中间件或将呈现多技术路线并行的态势参与者众多，多个标准并行。从竞争格局看，OEM 厂商、传统 Tier1 厂商、平台供应商、 汽车电子厂商及第三方软件供应商在中间件领域均有所布局。多数厂商基于 AutorSAR CP 及 AutoSAR AP 标准开发中间件，以博世为代表的部分厂商可兼容 AutoSAR 与 ROS2 架 构，另一部分以 Apex.AI 为代表的厂商则完全基于 ROS2 标准。此外，百度 Apollo 等分别 基于自研的生态进行开发。2.为什么关注汽车中间件关注点一：汽车行业与其他智能终端相比具有特殊性。相比传统的 PC、移动智能终端领

6、域，汽车作为工业品和消费品的结合，具备双重的属性。一方面在工业品领域，汽车需要 满足运行稳定性、安全性的要求，另一方面需要满足消费品对于生态丰富性、功能完整性 的要求。工业品和消费品需求的差异性使得车内分工的进一步细化，汽车电子电气架构也 随之演化。关注点二：汽车行业电子电气架构变革带来发展机遇。从汽车电子电气架构的变化阶段看， 当前汽车以域集中架构进入智能化时代，汽车内部被划分为自动驾驶、智能座舱、车身、 底盘等不同的域。不同域由于在安全性，灵活性，算力需求等方面具有较大差异，形成了 不同的底层基础软硬件组合（包括操作系统、底层芯片、通信方式等）。与 PC 领域的分布 式系统类似，车内出现了

7、异构的环境，中间件的重要性随之显现。关注点三：异构环境+新通信类型的应用使通信交互功能重要性持续提升。通信交互是狭 义中间件最为重要的功能之一，异构环境使中间件的通信交互属性起到了重要的作用。在 汽车内部，跨域、跨核、跨操作系统、跨终端的各类通信需求持续显现；另一方面，以太 网等新型通信技术的使用，使得汽车内部的通信更加复杂多样，汽车中间件的通信交互功 能重要性持续提升。关注点四：底层异构环境使中间件为代表的基础软件重要性进一步提升。除了基础的通信交 互外，中间件还承载着屏蔽底层复杂性的功能，与移动智能终端中的核心框架层类似，中间 件的存在有助于屏蔽底层复杂的硬件状况，使得开发者专注于顶层应用

8、的开发，提升开发效 率。随着汽车底层算力基础的不断提升，更丰富的芯片组合，使得高级的算法，功能得实现 成为可能。中间件屏蔽底层复杂性，提升开发效率的功能，有助于加速应用生态的建设。3.汽车中间件：具备交互支持，屏蔽底层复杂性功能中间件介于应用与底层操作系统之间，具备两大功能从 IT 架构所处位置看，中间件位于应用与操作系统、数据库之间。中间件向下适配不同 的操作系统内核；向上提供统一的标准接口，负责各类应用软件模块之间的通信以及对底 层系统资源的调度。为上层屏蔽底层的复杂性，让开发人员能在不同平台上实现、迭代、 移植上层功能、算法。从功能角度看，中间件主要功能可分为交互支持，公共服务两大类。交

9、互支持功能指中间 件能够协调系统中不同组件之间的交互，对进程或线程、数据库连接、缓存对象等逻辑资 源进行调度，解决分布式环境下数据传输、数据访问、应用调度的问题。交互支持功能与 分布式系统的特点、通信技术紧密联系。公共服务功能则指中间件实现部分服务的复用， 涉及系统构建和系统集成、流程管理，支撑应用开发、运行和集成等问题。公共服务功能 不断完善，推动中间件向软件基础平台发展。汽车以分布式架构步入智能化阶段，中间件满足通信需求汽车以分布式的架构步入智能化阶段，存在大量交互需求。随着智能汽车功能和软件复杂 度的提升，对电子电气架构设计的算力、通讯能力等方面提出更高的要求。汽车电子架构 由分布式向域

10、架构转变，如极狐阿尔法 S 华为 HI 版车型、特斯拉 Model3 等均采用域架构 的设计。域架构依据 ECU 的功能将整车划分为不同的域，由单个控制器相对集中地控制 所在域内的各个功能，减少布线的复杂度，增强架构的灵活性。域架构在集中度上有所提 升，但仍然具备多个域，仍然呈现分布式的特点。当前汽车以分布式的架构步入智能化阶 段，对于中间件的需求应运而生。车内以太网和 5G 技术应用增加，中间件应用进一步丰富。车内通信技术包括总线技术、 以太网等技术。其中，常见的汽车总线技术包括 LIN 总线、CAN 总线等。随着车内数据量 的增长，在宝马等头部厂商的推动下，具备更高传输速率，支持更丰富通讯

11、协议的以太网 技术应用进一步增加。在信息娱乐系统、ADAS 等领域的应用不断增加。随着车内通信的 类型进一步丰富，与之相匹配的中间件领域的产品也进一步丰富。智能化推动架构变革，中间件有助于屏蔽底层复杂性汽车 IT 架构中存在多样的底层方案，汽车中间件有助于屏蔽底层复杂性。在智能汽车中 存在多个控制域（动力域、底盘域、座舱域、自动驾驶域、车身域），每一个领域对应的 底层芯片，操作系统内核也有区别，不同的车型所采用的底层硬件，操作系统层也有所不 同，应用开发时需要面对复杂的底层方案组合。汽车中间件有助于实现软硬件解耦，屏蔽 底层的复杂性。中间件具有提供公共服务的功能，即针对系统构建和系统集成、流程

12、管理， 支撑应用开发、运行和集成等问题，实现部分服务的复用。通过提供公共服务的方式，将 共性的部分进行抽象，有助于屏蔽底层的复杂性，帮助开发人员更加高效的实现应用开发。计算架构演变，中间件作为基础软件空间有望进一步打开。随着汽车电子架构向集中式及 中央计算的模式转变，ECU 的功能进一步集成到域控制器乃至中央计算单元。架构的变革 对软件开发的可移植、可迭代、可拓展特性提出更高的要求，以 ECU 为单元的开发模式 有望转变为以通用硬件平台、基础软件平台及各类应用软件为特点的新型开发模式。在这 一模式下，软硬件或逐步解耦。中间件作为重要的基础软件，通过屏蔽底层的复杂性，顺 应了软硬件解耦的趋势，未

13、来基础软件空间有望进一步打开。4.汽车中间件与汽车电子架构紧密相关汽车中间件发展与汽车电子架构变化紧密相关汽车电子架构从分布式到域架构，集中化程度提升。随着汽车电子化程度提升，辅助驾驶 功能的推广，ECU 数量不断提升，汽车电子架构逐步向集中化演变，随着奥迪、特斯拉等 厂商推出域集中架构，以划分不同功能域的方式来集中控制不同 ECU 的架构逐步兴起。 分布式架构阶段中 ECU 数量有限，多用于控制发动机，而随着汽车智能化、电子化程度 的提升，不同域之间的通信需求，交互需求逐步显现，对于能够实现跨域交互支持的中间 件的需求也随之出现。汽车中间件发展与车内通信、汽车电子架构的变化相关。汽车中间件的

14、主要框架包括 AutoSAR CP、 AutoSAR AP、ROS2。其中 AutoSAR 是由 AutoSAR 组织制定的汽车开 放式系统架构标准，ROS2 则是一个机器人编程框架，被运用于智能汽车中。从汽车中间 件的发展历程看，2006、2017 为两大重要节点。2006 年 AutoSAR CPV2.0 正式发布， 2017 年面向智能汽车时代的中间框架 AutoSAR AP、 ROS2 完整版陆续发布，与汽车步 入域集中电子电气架构、车内以太网通信运用增长的时间点较为一致。0 到 AutoSAR CP：汽车电子化AutoSAR 组织发展壮大AutoSAR 组织定义了汽车基本软件结构和外

15、部接口。2003 年， 9 家汽车行业的巨头（宝 马、博世、大陆、戴姆勒、福特、通用、PSA、丰田、大众）建立 AutoSAR 组织。该组 织共同制定了汽车开放式系统架构标准 AUTOSAR(AUTomotive Open System ARchitecture，汽车开放系统架构)。AUTOSAR 标准定义了基本软件（BSW）的内部结构 和外部接口的定义，软件供应商根据 AUTOSAR 标准提供实现。产业分工不同，中间件厂商地位重要AutoSAR 架构中，软件服务、芯片厂商、OEM 及 Tier1 侧重分工不同。在 AutoSAR 架 构下，偏底层的微控制器抽象层包含各类驱动，作为上层软件与

16、MCU 寄存器的过渡层， 由 MCU 厂商提供；ECU 抽象层和 ECU 硬件相关，复杂驱动让应用直接访问特殊设备， 涉及严格的时序问题，抽象难度大，RTE 用于抽象 ECU 之间的通信，此部分主要由 OEM 或 Tier1 提供；服务层软件通常由第三方软件服务商提供，但部分 OEM 及 Tier1 同样进行 了服务层模块的自研开发。AutoSAR 实现软硬件解耦，汽车电子化趋势为重要推动力AutoSAR CP 架构通过分层实现软硬解耦，提升效率。AUTOSAR CP 架构分为服务层、 ECU 抽象层、微控制器抽象层、复杂驱动层等，服务层提供基础软件及标准化的系统功能 和功能接口；ECU 抽象

17、层提供统一的访问接口，实现对通信、存储器或者 I/O 的访问，使 ECU 层级与底层 MCU 解耦；微控制器抽象层包含多种驱动程序，实现了底层硬件的封装。 通过分层思想的体现，实现了顶层应用与底层硬件的解耦，通过提升标准化程度进一步提 升了开发效率。AutoSAR 革新软件开发流程，顺应汽车电子化趋势。AutoSAR 的出现革新了汽车软件的 开发流程，形成了囊括主机厂、Tier1、中间件厂商等在内的开发流程。其中， OEM 进行 逻辑系统和物理系统的设计（定义 EE 架构网络结构，总线配置，传输的信息单元，将整 车设计的不同功能分配到 ECU 上）并生成配置文件 arxml，提供 SWC 系统

18、模型和通信矩 阵，交付给 Tier1。Tier1 则基于 NCE 和 OEM 需求进行 ECU 的物理设计开发，包括根据 ECU 配置开发软件 SWC,对不同 ECU 的数据映射、生成 RTE,BSW,SWC Template 代码 等步骤。应用开发者则在生成代码框架基础上开发功能，调试。AutoSAR CP 到 AutoSAR AP：汽车智能化AutoSAR AP 采用两层架构，适应高性能计算需求AutoSAR AP 是针对高性能计算 ECU 的解决方案。AUTOSAR AP（自适应平台）正式发 布于 2017 年，是 AUTOSAR 针对高性能计算 ECU 的解决方案，用于为高度自动化和自

19、动 驾驶等用例构建安全相关系统。AP 支持自适应应用程序，提供服务和 API 两种接口。该平 台提供功能集群，封装了 AP 的功能，定义需求规范的聚类，从应用和网络的角度描述软件 平台的行为，不限制实现 AP 的架构的软件设计。与 AUTOSAR CP 相比，ARA 环境在运 行时动态的与服务和客户端连接。自 2017-2021 年，历经四年的更新迭代，功能逐步丰富。由 AutoSAR CP 的三层架构变为 AutoSAR AP 的两层架构。AutoSAR AP 在架构方面不 同于 AutoSAR CP，架构简化为两层。CP 架构内的基础软件层（BSW）、运行时环境 （RTE）层在 AP 架构

20、内统一为基础软件及中间件层（ARA）。CP 内基础软件层的各种服 务支撑上层应用，在 AP 架构内则由 ARA 中的功能集群（FC）支撑上层应用。功能集群 可分为提供基础服务的 API（Foundation）以及提供其他服务的接口（Service Interface）， 此外自适应应用（AA）也能够为其他应用提供非平台服务。在 AutoSAR 架构的演进过程 中，出现了部分服务向基础 API 的转化、基础 API 的变化，但总体的两层架构始终保持稳 定，是符合面向服务架构开发范式的中间件架构。AutoSAR AP 开发过程与 CP 类似。首先在设计阶段 OEM 负责系统、诊断、服务、应用 和

21、Manifest 设计，产出 arxml 文件。其中 Manifest 文件用于支持 AP 产品的配置，分为 Machine Manifest（描述运行 AUTOSAR AP 的机器）、Execution Manifest（描述应用程 序部署相关信息）、Service Instance Manifest（用于根据基础传输协议的要求，指定如何 配置面向服务的通信）。在 OEM 完成总体框架的设计后，将设计阶段的 arxml 文件通过代 码生成器和 Manifest 分别生成.cpp、.h 文件和 json 文件；最终集成代码运行在 ECU 上。AUTOSAR AP 与 CP 编程语言不同，AP

22、提供对大规模编程与封装的良好支持。CP 基于 C 语言面向过程开发，而 AP 基于 C+语言面向对象开发。在传统 ECU 领域，C 语言凭借 其简易的编译方式、较高的程序运行效率，能处理大部分系统问题，是汽车开发人员的主 要选择。但随着汽车设计日益复杂，自动驾驶、高级辅助驾驶等新功能的实现需要大量高 级代码。C+在处理大规模程序编程的优势使其取代 C 语言成为 AP 的标准语言，C+为 构造大型系统提供了更好的支持，并为数据封装提供了更好的机制。AUTOSAR AP 与 CP 应用领域的不同，应用领域从车控到智控软件。CP 一般应用在传统 车身控制领域，如引擎控制、制动系统等， AP 一般应用

23、在自动驾驶、高级辅助驾驶、车 载信息娱乐系统领域。POSIX 操作系统赋予了 AP 高计算能力、高度灵活性与可编程性， C+编程语言为构造复杂系统提供了更好的支持，面向服务的通信方式提供了低网络负载， 高通讯效率等诸多优势，FOTA 提供 AP 固件升级的能力，凭借这些方面的改变，AP 相比 于 CP 更能胜任对算力要求更高的场景以及追求较高自由度的场景中。ROS2：汽车智能化ROS2 是一个机器人编程框架，在机器人应用和计算机 OS 之间提供了通用的中间层框架 和常用软件模块（ROS Package）。ROS 基于 DDS 通信机制，支持实时性、嵌入式、分 布式、多操作系统，支持的系统包括

24、Linux、windows、Mac、RTOS 等。此外，ROS2 中 引入了 QoS 策略用于配置节点间通信，进而提升了 ROS2 适应于不同应用场景的灵活性。 ROS2 在车内可适用于自动驾驶场景，采用 RO2 架构的代表性中间件为 Apex.Middleware。ROS 2 对 ROS 1 的部分领域实现了改进和提升，包括系统架构中的 OS。ROS 1 主要构 建于 Linux 系统之上，支持 Ubuntu，而 ROS 2 支持多种系统，包括 Linux、windows、 Mac、RTOS 等。ROS 2 全面支持三种平台，包括 Ubuntu 16.04、Mac OS X 10.12、 W

25、indows 10，除了完全覆盖 ROS 1 所能支持的 OS 系统外，多操作系统让 ROS 2 可以兼 容更多的软件生态，在使用过程中，可以根据需求灵活调整对应的 OS。ROS 2 对 ROS 1 通讯架构进行了改进提升，支持 DDS 通讯系统。ROS 1 通讯系统基于 TCPROS/UDPRO，ROS 2 通讯系统基于 DDS。ROS 1 项目的初衷是为了给科研机器人 提供一个开发环境和相应的工具，当其运用于自动驾驶时，其为机器人开发的应用层和通 用的消息接口并不完全适用，其通讯系统 TCPROS/UDPRO 存在以下缺陷：无法满足实 时性、对于网络通信的重依赖。针对此类问题，ROS 2

26、采用基于 RTSP(Real-Time Publish-Subscribe)协议的 DDS 作为通讯系统，支持实时控制，支持非理想网络环境，使 ROS 2 在低质量高延迟等网络环境下系统仍然能够运作，适应了自动驾驶的需求。ROS 2 引入了 QoS (Quality of Service) 策略，并运用于节点间通信。ROS 2 通过配置 QoS 策略，并将其运用于节点间通信，ROS 2 有效提高了其适应于不同应用场景的灵活 性。相比于 ROS 1 仅支持基于 TCP 的通信，ROS 2 通过 QoS，可以同时表现出 TCP 的 可靠性和 UDP 的高实时性，用户可以通过选择不同的 QoS 配置

27、文件以实现不同的通信表 现。灵活的配置选择使 ROS 2 能够对通信的实时性、完整性等功能提供支持，更好适应 自动驾驶场景。AutoSAR CP 到 Cyber RT：自动驾驶Cyber RT 是针对无人驾驶的解决方案。Cyber RT 是百度 Apollo 开发的中间件，在 Apollo 3.5 中正式发布。CyberRT 具有轻量级、平台无关等特点。从底层组件看，其底层 使用了开源版本的 DDS，并在此基础上进行改良。Cyber RT 专为无人驾驶设计，基于无 人驾驶业务现状深度定制，目前百度已将 Cyber RT 开源供自动驾驶团队使用。Cyber RT 支持 DDS 通信。Cyber

28、RT 的底层通讯架构为面向自动驾驶汽车开发的 DDS （Data Distribution Service）分布式实时嵌入式系统，其可满足基于信道的通信 （Publish-Subscribe 模式），单向通信+无需实时应答，以及基于服务的通信（ServiceClient 模式），双向通信+实时应答。Cyber RT 还提供了不同的通信方式，以应对各类自动 驾驶需求，包括统一进程内通信、同主机进程间通信、跨主机通信。5.汽车中间件商业模式AutoSAR 阶梯式收取授权许可费用，并针对不同类型组织推出不同的订阅模式。 AutoSAR 参与者分为多个层级，不同层级的组织对应不同的订阅模式，各模式的管

29、理费用、 开放权限、服务内容及职责均存在一定差异。此外，AutoSAR 授权价格也不同，不同的价 格对应不同的限制 Tier1、限制 OEM 厂商、开发 ECU 产品数量、量产使用、限制芯片类 型等条件进行区分。在软件成本外，开发还需投入开发成本、人力投入及硬件成本等。竞争格局：Tier1，独立第三方共同参与从 MotionWise 到 iceoryx、ZF Middleware 等。TTTech 是较早发布汽车中间件产品的 厂商之一。2012 年，TTTech 参与奥迪 zFAS 项目并担任硬件设计及中间件开发的角色， 其后于 2017 年正式发布中间件产品 MotionWise，搭载于奥迪

30、 A8 车型。此后，各大厂商 相继布局汽车中间件领域。2019 年，Elektrobit 为大众 ID.3 纯电动车提供基于 AutoSAR AP 的中间件。2020 年，博世发布开源自动驾驶中间件 iceoryx，其采用宽松的 Apache2.0 许可证，允许任何个人或者开发团队将 iceoryx 用于商业用途而不必公开其衍生产品的 源代码。iceoryx 还实现了真正的零拷贝，其过程中无需创建任何数据副本。除博世外，采 埃孚也于 2020 年发布了中间件产品 ZF Middleware。AutoSAR CP 竞争格局国外企业占行业主导地位，国内企业中间件方案不断涌现。对于 AUTOSAR

31、CP 标准的基 础软件及工具链，国外主要供应商有 Vector、Etas、EB、Mentor 等。其中，第三方软件 公司 Vector 为头部企业，而 Etas、EB 分别是 Bosch、Continental 的子公司。国内厂商正 积极实现自主化研发，主要有东软睿驰、普华软件、经纬恒润、华为等。AutoSAR AP 竞争格局国内外企业积极布局 AUTOSAR AP 领域。AUTOSAR AP 是 AUTOSAR 于 2017 年发布 的新标准，国内外厂商均处于起步阶段。国外企业大陆 EB 与和大众合作将 AUTOSAR AP 和 SOA 平台应用于大众 MEB 平台 ID 系列纯电动车型上。

32、国内厂商也将 AP AUTOSAR 作为发力重点，推出相应的中间件及其工具链产品。国内 AUTOSAR AP 领域 的新兴软件供应商与国外老牌 AUTOSAR 供应商深入合作，如经纬恒润同 Vector 合作， 积累总线技术方面的技术经验。ROS2 竞争格局量产应用较少，APEX 为典型代表。相比较 AutoSAR AP，ROS 2 在安全支持、技术成熟 度和实时域方面尚有欠缺，其在自动驾驶量产车的应用较少，但随着相关技术的进一步成 熟，ROS 2 应用有望逐步丰富。目前，国内外厂商在 ROS 2 领域均处于起步阶段，致力 于 ROS 2 中间件方案研发的公司包括 Apex.AI，其所设计的中

33、间件 Apex.Middleware 为第 一个通过 ASIL D 认证的 ROS 2 方案，博世，其所设计的中间件冰羚基于零拷贝和共享内 存技术开发。除此之外，丰田、大陆、采埃孚等 OEM 以及 Tier 1 均积极布局 ROS 2 领域， 把握 ROS 2 发展机遇。产品布局中间件领域，OEM 厂商、传统 Tier1 厂商、平台供应商、汽车电子厂商及第三方软件供 应商均有所布局。 架构标准有所差异。从架构标准来看，多数厂商基于 AutorSAR CP 及 AutoSAR AP 标准 开发中间件，以博世为代表的部分厂商可兼容 AutoSAR 与 ROS2 架构，另一部分以 Apex.AI 为

34、代表的厂商则完全基于 ROS2 标准。此外，百度 Apollo、TTTech 等分别基于 自研的生态进行开发。从支持的技术点来看，博世的 iceoryx 专注于共享内存技术来优化 进程间通信，华为 MDC 平台支持的通讯方式更为广泛，包括 SOME/IP、DDS 及共享内 存。不同厂商产品的架构标准有所差异。6.中间件厂商梳理Tier1 及子公司Etas：提供 RTA-VRTE、RTA-BSW、iceoryx 等多种中间件产品提供遵循 AUTOSAR CP 与 AP 规范的多款中间件方案。RTA-VRTE 遵循 AUTOSAR AdaptiveR19-11 规范，提供车辆计算机的 AUTOSA

35、R 平台基础软件框架，使用 C+11 语 言和 Linux 操作系统，目前已实现多个组件，可满足当前最常见的基于 SOME/IP 通信和 基 于 DOIP 诊断的应用场景。 RTA-BSW 为汽车电子控制单元 (ECU)提供全面的 AUTOSAR R4.x 中间件，可提供一套全面的 AUTOSAR 堆栈，包括操作系统、运行时环 境、通信、内存、诊断协议、复杂驱动和校准，这些堆栈可为 ECU 应用开发提供 AUTOSAR R4.x 平台。该方案易于配置、集成和测试，支持将应用部署到真实的 ECU 硬 件和虚拟目标（例如，ISOLAR-EVE）上。两种方案皆通过基于 ISO26262 的安全认证，

36、 满足 ASIL-D 安全级别应用需求。 易特驰 RTA-VRTE AP。RTA-VRTE 采用 AutoSAR AP 架构，使用 C+11 语言和 Linux 操 作系统，已实现多个组件，可满足当前最常见的基于 SOME/IP 通信和基于 DOIP 诊断的 应用场景。Elektrobit：符合 AUTOSAR 标准的基础软件及可扩展平台EB tresos AutoCore 是基于最新的汽车开放系统架构 AUTOSAR 标准 4.X，专业面向汽 车电子控制单元（ECU）的汽车开放系统架构。EB tresos AutoCore 由独立硬件产品 (ACG)以及硬件相关的产品微控制器相关(ACM)组

37、成，其中 ACG 提供可扩展且高度优化的 汽车开放系统架构 AUTOSAR 运行时间环境(RTE)以及包含诊断特定的 AUTOSAR 汽车开 放系统架构模块，ACM 软件架构提供适合的 OS 以及微控制器抽象层（MCAL）。EB tresos AutoCore 遵循 AUTOSARICC3 分层结构的中间件，能够支持各类汽车通信网络如 CAN、CANFD、LIN、FlexRay 和以太网，还覆盖众多场景。在安全性方面， EBtresosAutocCore 通过质量和指标报告以及面向 OS 和 RTE 的安全应用指南支持 ASILB 级的安全等级。EBcorbos 是针对高级车辆架构的全新自适应

38、 AUTOSAR 标准的可扩展软件平台。EB corbos 产品系列包括用于安全可靠的高性能控制单元的基础软件（EB corbos Adaptive Core）、虚拟机监控程序（EB corbos Hypervisor）、基于 Linux 的高性能操作系统（EB corbos Linux）以及集成式开发环境（EB corbos Studio）。（1）EB corbos AdaptiveCore： 基于 POSIX 的汽车造作系统的多操作系统支持，能够在多个硬件平台（如 Intel、Nvidia、 Renesas 等）上使用。（2）EB corbos Hypervisor：能够在单个 CPU 上

39、提供一台或多台 虚拟机，以支持安全关键、安全相关和实时的应用系统。（3）EB corbos Linux：提供满足 功能安全（ISO26262）以及信息安全（ISO21434）要求的车载 Linux 操作系统。（4）EB corbos Studio：基于自适应 AUTOSAR 自适应平台开发和集成应用程序的通用工具。该平 台支持各种汽车软件操作系统、虚拟化和自适应 AUTOSAR 软件中间件，具有实现汽车自 动驾驶保障的最高级别（L5）的安全性、降低复杂性、节省时间和成本优势。采埃孚：ZF MiddlewareZF Middleware 提供可以集成到整车制造商软件平台的模块化解决方案。2020

40、 年 12 月， 采埃孚推出新款开源软件平台 ZF Middleware，该中间件方案以 AUTOSAR AP 为架构， 通过基于 ISO26262 的安全认证，满足 ASIL-D 安全级别应用需求。该项技术可在车辆的 整个生命周期内按需选用及更新，具体涉及自主驾驶、集成式安全系统、车辆运动控制以 及电驱动系统等领域。Middleware 将作为软件应用及车辆硬件的连接器，尽可能缩小界面， 确保该系统的各部分能够实现快速通信，有助于简化车企系统整合的复杂性。ZF Middleware 预计将于 2024 年开始搭载于量产车辆上。华阳集团 AAOP：开放式、可定制的软硬分离平台五大亮点赋能互联网

41、生态。华阳开放平台 ADAYO Automotive Open Platform (AAOP) 通 过分层分类技术架构与模块化、标准化的 SDK 化封装，实现硬件生态与车联生态的软硬 解耦，解决了如今 Tier 1 面临着硬件与车联网生态适配工作量、沟通成本成倍增加的难题。 AAOP 聚焦智能座舱平台化，通过车规级标准器件、丰富硬件配置、统一软件接口、高效 研发模式、完善诊断系统，为车联网生态打造一个开放式、可定制的软硬分离平台，推进 行业专业化分工。产品具备性能稳定、配置丰富、接口统一、诊断快速、研发高效、车联 网生态丰富等特点。软硬分离，满足更多定制化需求。AAOP 采用硬件抽象封装与软件

42、标准化模块化设计。在 硬件方面，把芯片模块驱动、音视频解码、传感器、数据传输等硬件驱动进行抽象标准化 封装，同时也对车身 ACC/B+、大灯/车门/诊断等检测进行车身抽象标准化封装，再根据 行业需求细分低、中、高三种级别的车规级硬件配置，满足客户不同产品定位的需求。在 软件方面，遵循 Android Automotive 标准规范的分层及接口，同时在数据服务方面，打通 DVR/T-BOX/AVM/4G、仪表/HUD 等设备通信并做标准化封装。通过硬件抽象封装与软件 标准分层设计，实现应用与硬件的隔离。OEM 及子公司Tata Elxsi AUTONOMAI：自动驾驶汽车平台兼具深度学习及人工智

43、能两大功能。AUTONOMAI 是 Tata Elxsi 的一款自动驾驶汽车平台， 兼具深度学习及人工智能两大功能。基于实验室的虚拟驾驶方案，AUTONOMAI 可验证自 动驾驶算法，支持各类传感器模拟，还能提供整套基于摄像头及传感器的算法框架，可被 用于 ADAS 及驾驶辅助用例。平台为汽车制造商和一级汽车供应商提供了涵盖感知、GNC 和线控驱动的全面模块化解决方案，以快速构建、测试和部署自动驾驶汽车。该解决方案 支持传感器与从摄像头到雷达和激光雷达的各种传感器的融合，并利用复杂的人工智能和 基于深度学习的算法来提供无人驾驶汽车预期的复杂用例场景。AUTONOMAI 还通过其预 先集成的验证

44、数据集以及 AI 和深度学习功能，允许快速适应特定区域。上汽集团：汽车行业首个全栈技术解决方案零束银河 4+1 作为汽车行业首个全栈技术解决方案，提供中央集中式电子架构、SOA 软 件及开发者平台、全栈 OTA 和网络安全以及智能车数据工场四大基础解决方案以及端到 端的智能化场景服务平台。1）中央集中式电子架构：以车载主从 HPC 为核心，能够应用 于 SOA 软件平台和数据工厂，为智能车端到端提供解决方案。2）SOA 软件平台：由 SOA 软件及开发者平台组成，将车云能力服务化，提供车端、云端整体软件解决方案。3） 全栈 OTA 和网络安全：实现整车全生命周期内应用、软件及数据的可持续迭代、

45、可升级 更新以及智能汽车网络安全保障。4）智能车数据工厂：基于物联网 IOT 方案搭建，实现 智能汽车全生命周期自学习、自成长和进化。5）端到端的智能化场景服务平台：基于四 大基础技术，实现跨域融合应用以及端到端的数字体验。海外独立软件公司TTTech Auto： 提供 MotionWise 中间件产品MotionWise 基于量产验证的高性能自动驾驶软件平台。MotionWise 于 2017 年 7 月在奥 迪 zFAS 的首个量产项目 A8 中问世，是一个经过系列验证的用于自动驾驶的安全软件平 台。MotionWise 通过基于 ISO26262 的安全认证，满足 ASIL-D 安全级别

46、应用需求，支持 Linux/QNX 操作系统。凭借其智能架构设计和周边工具，MotionWise 有助于发挥自动驾 驶解决方案的能力，同时提供面向多场景的服务能力，如具有故障操作性能的实时功能、 设计安全、服务保证、尖端的开放式集成平台等。目前全球搭载 TTTech MotionWise 产品 已有 25 个以上车型 SOP 量产。TTTech Auto 受到多家 OEM 投资青睐。2022 年 2 月 3 日，全球汽车中间件软件方案供应 商 TTTech Auto 宣布获得来自奥迪和安波福的合计 2.85 亿美元 C 轮融资，至此随着安波福 的加入，安波福与奥迪、三星电子、英飞凌等一起成为

47、TTTech Auto 的蓝筹股股东，凸显 了 TTTech Auto 凭借其安全软件平台在新兴的汽车用软件定义移动性领域的地位以及为市 场带来的价值。而在完成本轮融资之后，TTTech Auto 的估值超过了 10 亿美元，成为汽车 软件领域的一家新独角兽。除此之外，TTTech Auto 还拿下了大众、宝马、戴姆勒、现代等 OEM 及大陆集团、瑞萨等公司的量产订单，已经实现全球范围 200 万辆新车的前装量产。Vector：提供动态软件解决方案和嵌入式软件MICROSAR Adaptive 是 Vector 为基于 AUTOSAR Adaptive 平台搭建电子电器架构的车 辆提供的软件解

48、决方案。它为 Adaptive 应用程序(ARA)提供 AUTOSAR 实时运行环境，并 提供集成在 Eclipse 环境中的高效开发工具。Adaptive MICROSAR 面向高性能 ECU，如车 载应用服务器，ADAS ECU 和信息娱乐系统。Vector 可以提供从 Hypervisor,POSIX 操作系 统到 ARA 实时运行环境的整体解决方案，该方案最高可达到功能安全 ASIL D 等级。 MICROSAR Adaptive 应用众多领域，例如用于 ADAS，多媒体和通信应用的高性能 ECU， 适用于高度自动价值领域的带有功能安全需求的复杂系统，基于 C+语言的 AUTOSAR

49、Adaptive 应用程序的开发以及独立于车辆平台的应用程序开发，不仅能够用于量产项目如通 信（ara：com）、执行管理（ara：exec）、诊断（ara：diag）等，还能够用于 SOME/IP 协议映射，包括 E2E 保护功能配置、为 UDP 帧提供缓冲区以减少网络负载率等具体项目。MICROSAR Classic 是一个对 AUTOSAR Classic ECU 的嵌入式软件。由运行时环境 MICROSAR.RTE 和 MICROSAR 基本软件模块(BSW)组成，涵盖了整个 AUTOSAR Classic 标准以及许多扩展。DaVinci Configurator Pro 的用户界被

50、面用于配置 MICROSAR Classic 模 块，该工具包括有用的功能，例如参数的自动推导和广泛的验证功能。MICROSAR Classic 提供来自单一来源的 4.x 和 3.x 的完整的 AUTOSAR 的解决方案，适用于众多硬件平台和编 译器，能够支持不同的数据格式，例如 AUTOSAR-XML,DBC,LDF,FIBEX,CDD,ODX。其中， veHypervisor 基础软件组件实现在单个控制器上运行多个独立的虚拟机，遵循 ISO26262 开 发，且达到 ASIL D 等级，确保虚拟机安全高效运行。Apex. Middleware：高性能数据传输Apex.Middleware

51、 集成汽车通信需求。Apex Middleware 是 Apex.AI 推出的能够满足汽车 通信需求、支持机器内部通信、支持跨机器通信、支持云端通信的通信中间件。核心组件 基于 Eclipse Cyclone DDS和 Eclipse iceoryx的集成、Eclipse iceoryx 的高效零拷贝功 能以及 Eclipse Cyclone DDS 的高度稳健的实施和高性能网络通信。Apex Middleware 集 成了汽车通信需求，服务于从 ADAS 上的动力传动系到自动驾驶的所有应用，并针对单个 SOC 上进程间通信的最低延迟和与数据量无关的延迟进行了优化。Wind River：AUT

52、OSAR Adaptive 软件平台Wind River 提供立足于自研操作系统 VxWorks、Wind River Linux 的中间件方案。 VxWorks 是适用于开发安全关键应用软件的实时操作系统（RTOS），可被客户用于系统 开发并达到全球认证机构认可的最高安全等级，已被各行各业 350 多家客户用于 550 多个 安全认证项目中。Wind River 于 2019 年 10 月推出其中间件方案，该方案立足于 AUTOSAR 平台，发挥 VxWorks 实时操作系统（RTOS）和 Wind River Linux 等基础操作 环境的功能，为互联自动驾驶汽车应用提供灵活且可扩展的面向

53、服务架构，目前已通过基 于 ISO26262 的安全认证，满足 ASIL-D 安全级别应用需求。2022 年 1 月，全球汽车行业 零部件巨头安波福对外披露，宣布以 43 亿美元收购智能边缘软件服务商 Wind River。Mentor Graphics：Capital VSTAR、Volcano VSTARVSTAR 系列软件方案提供汽车级安全解决方案。Mentor Graphics 公司是电子硬件和软件 设计解决方案(EDA)的提供者，是西门子的全资子公司，其于 2014 年 5 月推出 VSTAR 系 列软件。VSTAR 系列软件是业内有一定竞争力的以 AUTOSAR 为基础的设计、分析

54、、验 证、虚拟集成及测试软件套件。VSTAR 系列软件使用 AUTOSAR 格式的输入数据以生成 软件平台，通过基于 ISO26262 的安全认证，满足 ASIL-D 安全级别应用需求。基于其车 载通信经验，提供了对多种通信协议的支持，包括 CAN、CAN-FD、以太网、LIN、 FlexRay，以及支持 AUTOSAR 标准的多域架构或网关 ECU 的实施。2016 年 11 月 30 日， 丰田汽车公司已批准其 Volcano VSTAR 基本软件栈用于所有丰田汽车。Real-Time Innovations：Connext DDS：信息实时共享的智能架构通过实时共享信息实现智能架构。DD

55、S 是一个分布式实时系统发布/订阅模型的规范，定 义了一个以数据为中心的发布/订阅模型，提供了一个独立于平台的中间件框架，为实时系 统中数据发布、传递和接收的接口和行为提供统一标准。RTI Connext 基于 DDS 标准，通 过实时共享信息实现智能架构，使大型应用程序作为一个整体协同工作。Connext 是第一 个用于高度分布式自治系统的连接软件，可以提供低延迟、高可靠性、可扩展性和安全性， 对于跨平台和系统的复杂数据分发至关重要。基于 Connext 数据总线，RTI 的软件允许应 用程序实时交换数据，并提供任务关键型系统所必需的不间断可用性和安全性。KPIT：KSAR Adaptive

56、Tier1 采埃孚与 KPIT 技术公司宣布开发一套行业领先的中间件解决方案。2021 年 10 月， KPIT 与采埃孚达成战略合作，双方将共同开发模块化中间件解决方案 KSAR Adaptive。 KSAR Adaptive 立足于 AUTOSAR 平台，支持 POSIX 操作系统，如 Linux 和 QNX，支持 SOME/IP 通信。采埃孚通过与 KPIT 合作开发的产品，可以为汽车客户提供更加全面的软 件解决方案，包括高性能计算、软件、智能传感器和智能执行器，并与采埃孚软件定义汽 车的系统组合衔接。KPIT 在中间件开发过程中利用在多个生产项目中的经验、架构咨询 和软件集成方面的专业

57、知识，以及其在基于云的连接服务方面的优势，为客户提供全面的 软件解决方案。eProsima：Fast DDSeProsima 是一家专注于网络中间件的企业，提供网络中间件解决方案，基于 OMG 的 DDS 标准开发了 Fast DDS。Fast DDS 是一个独立的 Cpp 中间件，符合 OMG DDS 1.4 和 OMG RTPS 2.2 可互操作的有线协议标准。作为一款免费和开源软件（Apache License 2.0），该框架具备多种功能和工具，提供商业支持选项以及使用接口定义语言（IDL）从主 题定义生成发布/订阅代码，使开发人员能够专注于其应用程序逻辑。Fast DDS 能够在多平

58、 台集成，如 Windows，Linux，Mac OS，QNX，VxWorks，iOS，Android，Raspbian / Debian Buster，以及适用于机器人、物联网、汽车、关键应用等领域。Object ComputingOpenDDSOpenDDS 是一个开源且广泛采用并且基于标准的分布式系统的实时发布-订阅解决方案。 它实现了标准化的接口，实现了应用程序的连接性和可移植性，并得到了 Object Computing 的服务和支持。OpenDDS 符合面向实时系统的数据分法服务（DDS）v1.4、 DDS 互操作线协议（DDS-RTPS）v2.2 和 DDS-Security v

59、1.1，目前支持 TCP/IP、 UDP/IP、IP 组播、共享内存和 RTPS_UDP 传输协议。项目提供了一组 QoS 策略来控制 底层连接和数据通信的行为，满足分发、可靠性及时性和安全性等领域的非功能性要求和 约束，支持各种操作系统、编译器和硬件平台。OpenDDS 具备灵活性、可预测性等优势， 能够支持航天航空、IIOT、汽车、机器人和国防等行业。HighTec：提供 MCALHighTec 为英飞凌和意法半导体提供 MCAL 支持。对英飞凌 AURIX 和的 AURIX2G AUTOSAR MCAL，提供客户应用程序框架的 MCAL 配置、审查和集成；AUTOSAR 复杂 驱动程序开

60、发以及 MCAL 与多核实时操作系统集成。HighTec 帮助意法半导体的 AURIX 和 Safe TPack AURIX2G 产品在 AUTOSAR 应用中集成 ST MCAL 和第三方组件。Hitex：提供 MCALHitex 为成熟的 AUTOSAR 项目以及有特殊要求的工业项目提供 MCAL 驱动程序。在这 两种情况下，能够帮助节省时间和精力，并使用经过批准和测试的技术进行安全操作，驱 动程序部分由 Hitex 开发和质量测试。就 AUTOSAR 项目而言，Hitex 为其提供 AUTOSAR MCAL 层的 MC-ISAR 低级驱动程序。关于 TraveoII AUTOSAR 软件