计算机行业专题研究：汽车中间件迎发展机遇.docx

《计算机行业专题研究：汽车中间件迎发展机遇.docx》由会员分享，可在线阅读，更多相关《计算机行业专题研究：汽车中间件迎发展机遇.docx（49页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

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

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

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

4、等在 内的汽车软件开发流程，中间件供应商提供相应工具，为汽车软件开发的重要角色。观点四：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 等分别 基于自研的生态进行开发。为什么关注汽车中间件关注点一：汽车行业与其他智能终端相比具有特殊性。相比传统的 PC、移动智能终端领 域，汽车作为工业品和消

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

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

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

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

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

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

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

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

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

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

16、由 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 负责系统、诊断、服务、应用 和 Manifest 设计

21、，产出 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 通信机制，支持实时性、嵌入式、分 布式、多操作系统，支持的系统包括 Linux、windo

24、ws、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、 Windows 10，除

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

26、eal-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 RT 的底层通讯架构为

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

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

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

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

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

33、dleware 为第 一个通过 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 及共享内 存。不同厂商产品的架构标准有所差异。中间件厂商梳理Tier1 及子公司 Etas：提供 RTA-VRTE、RTA-BSW、iceoryx 等多种中间件产品 提供遵循 AUTOSAR CP 与 AP 规范的多款中间件方案。RTA-VRTE 遵循 AUTOSAR AdaptiveR19-11 规范，提供车辆计算机的 AUTOSAR 平台基础软件框架，

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

36、安全级别应用需求。 易特驰 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)组成，其中 ACG 提供

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

38、的可扩展软件平台。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 Middleware ZF Middleware 提供可以集成到整车制造商软件平台的模块化解决方案。2020 年 12 月， 采

40、埃孚推出新款开源软件平台 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：自动驾驶汽车平台 兼具深度学习及人工智能两大功能。A

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

44、I 和深度学习功能，允许快速适应特定区域。上汽集团：汽车行业首个全栈技术解决方案 零束银河 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 轮融资，至此随着安波福 的加入，安波福与奥迪、三星电子、英飞凌等一起成为 TTTec

47、h 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 Adaptive

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