（报告出品方/分析师：东方证券 浦俊懿 谢忱）

一、操作系统是汽车软件的核心，车企角力车载 OS

软件定义汽车时代下，汽车软件架构不断演进。

随着汽车不断向智能化、网联化方向发展，以单片机为核心的传统分布式电子电气架构已经很难满足未来智能汽车产品的开发需求。

因此，汽车电子电气架构从传统分布式架构正在朝向域架构、中央计算架构转变，而集中化的 EE 架构是实现软件定义汽车重要的硬件基础。软件层面上，由于软件迭代周期越来越短，汽车软件架构也逐步由面向信号的架构（Signal-Oriented Architecture）向面向服务的软件架构（Service-Oriented Architecture，SOA）升级，以更好实现软硬件解耦与软件快速迭代。

根据我们之前发布的报告《智能汽车深度系列之一：汽车软件的星辰大海》，目前汽车软件在智能汽车软硬件架构中自下而上可分为系统软件、功能软件、应用软件三类，软件已成为当前智能汽车差异化的关键。

车载操作系统是汽车软件的核心，可分为狭义 OS 和广义 OS：

1> 狭义 OS：指 OS 内核，又称为“底层 OS”，提供操作系统最基本的功能，负责管理系统的进程、内存、设备驱动程序、文件和网络系统，决定着系统的性能和稳定性，是系统软件层的核心。

2> 广义 OS：指控制和管理车载硬件和车载软件资源的程序系统集合，在汽车软件架构中起到承上启下的作用，不仅为上层应用的实现提供了高效、稳定环境的支持，也是各类应用调度底层硬件资源的“桥梁”。

在汽车软硬件架构中，广义 OS 指系统软件层（包括硬件抽象层、OS 内核、中间件组件）与功能软件组成的软件集合。

对于车企而言，自研 OS内核成本高，更多地是在现有内核的基础上开发形成各自研自动驾驶 OS。

目前自动驾驶OS内核竞争格局较为稳定，主要包括QNX、Linux、Android（基于Linux开发）、 VxWorks、WinCE 等。

因打造全新 OS 需要花费太大的人力、物力，目前基本没有企业会开发全新的 OS 内核。当前，无论是 Waymo、百度、特斯拉、Mobileye，还是一些自动驾驶初创公司、车企，所谓的自研自动驾驶 OS（属于广义 OS），都是指在上述现成内核的基础之上自研中间件和应用软件。

由于各内核存在差异，车企在选择 OS 内核时，主要考虑安全性、可靠性、开放性、可扩展性、易用性及成本等因素，再结合自己的需求及能力体系来做权衡。

例如，实时性、安全性好的 RTOS（Real-time OS，实时 OS），如 QNX、RT Linux 等，车企会优先考虑运用到对实时性、功能安全要求更高的驾驶域；而对应用生态丰富度要求高的座舱域，车企可以在 Linux、Android 等开放性好的内核基础上打造座舱域 OS。

根据对 OS 内核改造程度不同，车企自研车载操作系统可大致分为三类：

1> 定制型操作系统：

指在基础型操作系统之上进行深度定制化开发，覆盖系统内核层到应用程序层，最终（一般是 Tier1 和主机厂一起）实现座舱系统平台或自动驾驶系统平台。定制型操作系统研发成本高、开发难度大，一般需要车企进行大量、长期的投入，如特斯拉Version、大众 VW.OS、Google 基于 Linux 打造的 Android、华为鸿蒙 OS、AliOS 等均属于自研的定制型操作系统。

2> ROM 型汽车操作系统：

基于 Linux 或 Android 进行有限的定制化开发，不涉及系统内核更改，一般只涉及汽车服务、车辆服务以及应用程序等内容的修改。此类操作系统研发难度相对较低，大部分主机厂一般都选择开发 ROM 型操作系统，例如奔驰 MBUX、宝马 iDrive、蔚来 NIO OS、小鹏 Xmart OS 等。

3> 超级汽车 APP：

又叫手机映射系统，即把手机屏幕内容映射到中控大屏，通过整合地图、音乐、社交、语音等功能为一体来满足车主需求的 APP，如苹果 CarPlay、谷歌 Android Auto、百度 CarLife、华为 Hicar 等。

国内外厂商在选择底层 OS 方面存在差异。

从发展动向来看，主机厂一方面力图掌握智能汽车底层软件和硬件的控制权，更倾向中立的操作系统；一方面开展各种合作，利用开源软件组织，减少开发周期和成本。

Linux 基金会在 2012 年启动了开源项目 Automotive Grade Linux （简称 AGL），此项目的最终目标是提供满足安全关键系统的功能安全，从而服务自动驾驶应用。

按照 AGL 的设想，未来成员企业可以共享 70%的代码，另外 30%则是不同品牌厂商进行差异化开发，从而保障各自的商业化利益，目前 AGL 成员已超过 100 家。

由于 QNX 的高安全性以及 Linux 开源、免费等优势，国外车厂大多选择 QNX 与 Linux 作为底层操作系统进行开发；由于国内 Android 应用生态更好，国内车企以及造车新势力大多基于 Android 定制操作系统。

Android 内核相较 QNX 与 Linux 在某些方面具备独有的优势。

1> 从架构来看，Android 的硬件抽象层对 Linux 内核驱动程序进行了封装，把对硬件的支持分成了两层，一层放在用户空间（User Space），一层放在内核空间（Kernel Space），其中硬件抽象层运行在用户空间，而 Linux 内核驱动程序运行在内核空间。

Linux 作为宏内核，把对硬件的支持和管理全部放在内核空间中，而复杂的内核结构会带来稳定性较差的问题；QNX 作为微内核，内核中只有最基本的调度、内存管理，驱动、文件系统等，但频繁的系统调用与信息传递会使 OS 的运行效率较低。Android 内核居于 QNX 与 Linux 之间，较 Linux 有更好的稳定性，较 QNX 有更高的效率。

2> Android 之所以在用户空间新建一个 HAL 层（指硬件抽象层）来支持硬件设备，是由于 Android 使用的开源协议是 Apache License，此协议比较宽松，其允许开发者获取并修改了 源码之后，不用把源码公开出来。而 Linux 使用的开源协议是 GPL，它的要求和限制较多， 其中要求开发者添加或修改了源码之后，必须把添加或修改后的代码公开出来。

HAL 层保护了开发厂家的利益，但脱离了 Linux 的开源。安卓是开放的，但不是开源的，这也是为什么把安卓从 Linux 分出去的主要原因。

未来 Android 在座舱 OS 的占有率有望提升。目前座舱的操作系统可以分为三大类：

（1）QNX；

（2）Linux 类，包括像特斯拉这样的 Linux 直改、车规级 Linux 的 AGL、GENIVI 联盟（更名为 COVESA）；

（3）Android类，包括了国内Android直改，以及Google特别为车载推出的AAOS。

由于 Android OS 具备独有的优势，同时国内 Android 应用生态较好，未来在座舱 OS 的占有率有望提升。

根据佐思汽研预测，2026 年 Android 类 OS 在新车座舱操作系统的占有率将从 2021 年 的 25%提升到 50%。

由于 QNX 的定制修改都需要 Blackberry 来做，BSP 需要为硬件定制，具备 QNX 应用开发能力的开发者数量较少，未来 QNX 在座舱 OS 的占有率或将下降。

车载操作系统将逐步由座舱 OS 向整车 OS 演进。

很多汽车 OS 厂商是从车机 OS 入局的，如苹果 CarPlay、百度 CarLife、华为 Hicar 等，过去手机芯片、OS 和应用生态均优于汽车，因此将手机功能映射到汽车中控可以满足车主对娱乐的需求。

随着汽车芯片以及软件生态的发展，当前汽车操作系统已步入座舱 OS 阶段，未来随着座舱域与自动驾驶域的融合，座舱 OS 将进一步向整车 OS 迈进。

在 2020 年初，斑马智行提出了 AliOS 操作系统演进三部曲战略，即智能车机操作系统、智能座舱操作系统、智能整车操作系统。

如今斑马智行已经进入到了座舱 OS 阶段，下一阶段将重点布局智能整车 OS，以“OS AI 芯片”为智能汽车决策核心，在操作系统层面推进汽车分布式智能向整车智能逐渐迈进。根据佐思汽研预测，2024 年以后将迈向整车 OS 阶段。

车企加大自研操作系统投入力度，行业规模有望持续增长。

由于自研操作系统可以缩短中间件、应用软件等软件开发周期，并有助于生态的建立以及软件的持续迭代，各车企对实现车载 OS 自主可控的诉求愈发强烈。

今年年初丰田汽车宣布计划于 2025 年推出自研的 Arene 操作系统；大众集团计划到 2025 年将自研车载软件比例提升至 60%；梅赛德斯-奔驰预计将于 2024 年发布自研的 MB.OS 操作系统完整版。

根据麦肯锡数据，2020 年全球广义操作系统市场规模为 200 亿美元，到 2025 年约 370 亿美元，到 2030 年可达 500 亿美元，可见未来近 10 年内操作系统市场具有较大的增长空间。

随着智能汽车功能复杂度的不断提升，单车软件授权费价值有望持续提升。

智能汽车软件的商业模式是“IP 解决方案 服务”的模式，Tier1 软件供应商的收费模式包括：

（1）一次性研发费用投入，购买软件包，比如 ADAS/AD 算法包；

（2）单车的软件授权费用（License），Royalty 收费（按汽车出货量和单价一定比例分成）；

（3）一次性研发费用和单车 License 打包。若不考虑复杂度极高的自动驾驶软件，目前单车软件 IP 授权价值量大致在 2-3 千元左右。

未来随着智能汽车功能以及操作系统的复杂度不断提升，单车软件授权费价值有望持续攀升，这也为 Tier1 软件供应商带来了机遇。

二、中间件对于汽车软硬件解耦具有重要意义

2.1 车载中间件解决方案盘点

软件定义汽车时代下，中间件的作用愈发重要。随着 EE 架构逐渐趋于集中化，汽车软件系统出现了多种操作系统并存的局面，这也导致系统的复杂性和开发成本的剧增。

为了提高软件的管理性、移植性、裁剪性和质量，需要定义一套架构（Architecture）、方法学（Methodology）和应用接口（Application Interface），从而实现标准的接口、高质量的无缝集成、高效的开发以及通过新的模型来管理复杂的系统，这就是我们所说的“中间件”。

汽车行业中有众多的整车厂和供应商，每家 OEM 会有不同的供应商以及车型，每个供应商也不止向一家 OEM 供货，中间件的存在尽可能地让相同产品在不同车型可重复利用或是让不同供应商的产品相互兼容，这样就能大幅减少开发成本。

因此，可以说中间件在汽车软硬件解耦的趋势中发挥了关键的作用。

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

目前，AUTOSAR 拥有 Classic Platform 和 Adaptive Platform 两大平台，分别对应传统控制类 车辆电子系统与对应自动驾驶的高性能类车载电子系统。

AUTOSAR（Automotive Open System Architecture）指汽车开放架构，是由全球汽车制造商、零部件供应商以及各种研究、服务机构共同参与制定的一种汽车电子系统的合作开发框架，并建立了一个开放的汽车控制器（ECU）标准软件架构，规范了车载操作系统标准与 API 接口。

AUTOSAR 拥有 Classic Platform 和 Adaptive Platform 两大平台：

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

2> Adaptive Platform（AP）：Adaptive Platform 是 AUTOSAR 面向未来自动驾驶、车联网等复杂场景而提出的一种新型汽车电子系统软件架构标准。

Adaptive平台修改了大量Classic平台标准的内容，采用了基于 POSIX 标准的操作系统，以面向对象的思想进行开发，并且可使用所有标准的 POSIX API，主要目的是为满足当前汽车自动驾驶、电气化和互联互通等趋势的需求。

相较 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 中各服务模块独立，具有更高的安全性以及部署灵活性。

今后相当长一段时间内 AUTOSAR AP 都不可能彻底取代 AUTOSAR CP，二者应用领域不同。在某些方面，AUTOSAR AP 与 AUTOSAR CP 相比是有一些“劣势”，例如 AUTOSAR CP 的时延可低至微秒级、功能安全等级达到了 ASIL-D，硬实时；而 AUTOSAR AP 的时延则在毫秒级，功能安全等级则为 ASIL-B，软实时。

这也导致二者应用领域的不同：

AUTOSAR CP 一般应用在对实时性和功能安全要求较高、对算力要求较低的场景中，如引擎控制、制动等传统 ECU；而 AUTOSAR 则应用在对实时性和功能安全有一定要求，但对算力要求更高的场景中，如 ADAS、自动驾驶，以及在动态部署方面追求较高自由度的信息娱乐场景。由于 SOC MCU 组合的现象会长期存在，因此在今后相当长一段时间内，AUTOSAR AP 都不可能彻底取代 AUTOSAR CP。

最常见的分工是，需要高算力的工作交给 AUTOSAR AP,而需要高实时性的工作则交给 AUTOSAR CP。

2.1.2 ROS 2：可支持自动驾驶场景的中间件

ROS（Robot Operating System）指的是机器人操作系统，是一套开源的软件框架和工具集，用来帮助开发人员建立机器人应用程序，它提供了硬件抽象、设备驱动、函数库、可视化工具、消息传递和软件包管理等诸多功能。

ROS 系统是起源于 2007 年斯坦福大学人工智能实验室的 STAIR 项目与机器人技术公司 Willow Garage 的个人机器人项目（Personal Robots Program）之间的合作，2008 年之后就由 Willow Garage 来进行推动。

ROS 项目的初衷是为了给科研机器人 Willow Garage PR2 提供一个开发环境和相应的工具。

为了让这套软件在更多的机器人上运行， ROS 为机器人开发提供了一套相对完善的中间层、工具、软件乃至通用的接口和标准，机器人工业领域的开发者因此能快速开发系统原型并进行测试和验证。

ROS 2 对 ROS 1 的部分缺陷实现了改进和提升，产品环境适用度更广。

ROS 推出以后被大量地应用于工业领域，包括科研机器人、工业机器人、轮式机器人、自动驾驶汽车乃至航天无人驾驶设备，其原来的功能设计已经不能满足海量应用对于某些性能（如实时性、安全性、嵌入式移植等）的需求，ROS 2 即在这样的背景下被设计和开发。

ROS2 与 ROS1 的主要区别包括：

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

2> ROS 1 的通讯系统基于 TCPROS/UDPROS，强依赖于 master 节点的处理；ROS 2 的通讯系统是基于 DDS，取消了 master，同时在内部提供了 DDS 的抽象层实现。

有了这个抽象层，用户就可以不去关注底层的 DDS 使用了哪个商家的 API，可以让开发者并行开发低耦合的功能模块，并且便于进行二次复用

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

4> ROS 2 新增了 QoS（Quality of Service，质量服务原则），主要对通信的实时性、完整性、历史追溯等方面形成了支持。

这大幅加强了框架功能，避免了高速系统难以适用等问题。ROS 1 缺少 QoS 机制，Topic 的稳定性与质量难以保证。

ROS 2 可用作自动驾驶中间件，实现与 AUTOSAR AP 中间件类似的功能，但二者存在差别：

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

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

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

Cyber RT 是百度 Apollo 开发出来的中间件，于 Apollo 3.5 中正式发布。

百度最早用的是 ROS 1，但在使用的过程中逐渐发现了 ROS 1 存在“若 ROS Master 出故障了，则任何两个节点之间的通信便受到影响”的问题，于是希望使用一个“没有中间节点”的通信中间件来代替 ROS 1，那时 ROS 2 还没有推出，因此自主研发出了 Cyber RT。

Cyber RT 和 ROS2 类似，其底层也是使用了一个开源版本的 DDS；为了解决 ROS 1 的问题，Cyber RT 删除了 master 机制，用自动发现机制代替，这个通信组网机制和汽车网络 CAN 完全一致。

此外，Cyber RT 的核心设计将调度、任务从内核空间搬到了用户空间。相较于其他中间件方案，Cyber RT 的一大优势是其专为无人架驶设计，包括基础库、通信层、数据层、计算层。

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

Iceoryx 是博世旗下子公司 ETAS 推出的中间件解决方案。ETAS（易特驰）成立于1994 年，是博世的全资子公司。

博世在量产 ADAS 领域装配率长期占据市场前三的份额，因此他们对于如何将自动驾驶数据高效流转的需求更为迫切。

2020 年 7 月，ETAS 推出了针对高级自动驾驶应用的中间件——Iceoryx （冰羚），Iceoryx 是一个适用于各种操作系统的进程间通信（IPC）的中间件，目前已支持 Linux、macOS 和 QNX，可兼容 ROS2 和 AUTOSAR AP 的接口，以满足不同开发阶段的需求。

传统的数据传输是通过复制副本传输数据，这样会消耗大量内存并产生延迟。

由于大量自动驾驶相关的感知数据需要在整个系统内完成快速的流转，此时进程间通信（ Inter-Process Communication，IPC）就需要发挥作用。

以 Linux 系统为例，不同进程之间传播或交换信息，由于不同进程地址空间相互独立，传递数据时不停的来回拷贝数据，建立和释放堆栈，这个不生成任何价值的拷贝的过程浪费和占有了大量系统资源并产生了不期望的延迟。

为了解决 IPC 低效率问题，Iceoryx 设计了一种“零拷贝”的内存共享技术。

“零拷贝”通过事前定义好的通用接口，将需要消费的数据（图片原始 RGB 或者激光点云数据）放入由 Iceoryx 申请好的内存空间，然后引入“记数器”这个概念，来记录内存空间中各块数据是否被调用还是释放。

当计数器为 0 时，就表示该块数据可以被释放。这样所有的数据调用都发生在共用的内存区域中，免去了各进程将数据拷贝到自己私有存储内，大大提高了数据通信的效率。

基于共享内存的拷贝并不是一种创新的通信机制，但 Iceoryx 采用了发布/订阅架构、服务发现、和计数器相结合的机制。

通过添加避免复制的应用程序编程接口，实现了所说的真正的零拷贝——一种从发布者到订阅者的端到端的方法，而无需创建一个拷贝。

Iceoryx 还需要更多的量产车型的验证以及持续的打磨优化。

Iceoryx 是开源的，遵从 Apache-2.0 许可证，任何个人或者团队都可以免费使用源代码。Iceoryx 取决于 POSIX API，由于不同操作系统的 API 会有细微差异，因此将 Iceoryx 移植到另一个基于 POSIX 的操作系统时，可能需要进行细微的改动。

但如果需要过 ASIL-B 或 ASIL-D 等级功能安全认证，那还需要从博世购买相关的安全服务。

目前，对于Iceoryx这套中间件来说最大的挑战是需要有主机厂快速搭载量产车上市，来真正检验其价值。另外由于自动驾驶感知信息种类越来越多，激光点云数据、摄像头 RGGB 帧、 3D 毫米波雷达目标信息以及 4D 毫米波雷达点云信息、整车信号数据等，如何高效申请和分配内 存块也是实现真正“零拷贝”的前提，这也需要在实际项目中不断打磨优化。

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

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

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

2> 开源的通信中间件主要有 OPEN DDS、FAST DDS、Cyclone DDS 等。

SOME/IP 严格来说，SOME/IP 不是一款特定的产品，而是一种技术标准。

2011 年，BWM 设计和提出了 SOME/IP，SOME/IP 全称为 Scalable Service-oriented Middleware over IP，拆分起来理解就是以 Server-Client 服务形式进行通信，并且服务具备高度可扩展性。

在传统以太网中，OSI 将以太网分层七层，但汽车行业将 OSI 5-7 层统称为应用层，因此车载以太网只有 5 层。

SOME/IP 协议是一种应用层协议，运行在 TCP/UDP 传输协议之上（车载以太网第四层以上），作为以太网通信中间件来实现应用层和 IP 层的数据交互，使其不依赖于操作系统，同时又能兼容 AUTOSAR 和 非 AUTOSAR 平台。因此 SOME/IP 可以独立于硬件平台、操作系统和编程语言。

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 和 AP ECU 更好地交互，GENIVI 系统同样也开发了一套开源 vSOME/IP 软件源码，以便和 CP/AP 交互。

但 vSOME/IP 是开源的，所以性能会差一些，因此需要统一的规范来做约束，从而做一些深层次的二次开发。

当前，全球最大的商用 SOME/IP 产品供应商是 Vector，开源版的 vSOME/IP 则是由 GENIVI 协会来维护的。

DDS DDS（Data Distribution Service）指的是数据分发服务，是由 OMG 发布的分布式通信规范。

OMG（Object Management Group）成立于 1989 年，是一个国际性、开放性、非盈利性技术标准联盟，由供应商、终端用户、学术机构、政府机构推动，到现在已有 30 多年历史。

OMG 工作组会针对各种技术和行业制定企业集成标准，并开发可为数千个垂直行业提供现实价值的技术标准，其中包括统一建模语言 SYSML、UML，以及中间件标准 CORBA、DDS 等。

DDS 最早应用于美国海军系统，用于解决军舰系统复杂网络环境中大量软件升级的兼容性问题。随着 DDS 被ROS 2以及AUTOSAR引入，目前DDS已被广泛应用于航空、航天、船舶、国防、金融、通信、 汽车等领域。

DDS 采用发布/订阅模型，提供多种 QoS 服务质量策略，以保障数据实时、高效、灵活地分发， 可满足各种分布式实时通信的应用需求。

DDS 将分布式网络中传输的数据定义为“主题”，将数据的产生和接收对象分别定义为“发布者”和“订阅者”，从而构成数据的发布/订阅传输模型（Data-Centric Publish-Subscribe，DCPS）。

各个节点在逻辑上无主从关系，点与点之间都是对等关系，通信方式可以是点对点、点对多、多对多等，在 QoS 的控制下建立连接，自动发现和配置网络参数。

目前 DDS 已被多个车载中间件平台引入。

2018 年，DDS 首次被引进 AUTOSAR AP，以作为可选择的通信方式之一。

2018 年 3 月，DDS 的主要提供者 RTI 公司宣布，AUTOSAR AP 当时的最新版本（版本 18-03）已经具有 DDS 标准的完整网络绑定。此外，AUTOSAR CP 的标准规范中是不支持 DDS 的，但做一些变通后也可以在 CP 上集成 DDS。

如前文所述，ROS 2 和 Cyber RT的底层也均使用了开源的 DDS，将 DDS 作为最重要的通信机制。

与中间件相对应，Xavier、Orin 等面向自动驾驶的 SOC 芯片上也都预留了 DDS 接口。

目前，全球 DDS 最大的供应商是美国的 RTI（Real-Time Innovations）公司，约占据市场 80%的份额。

RTI 作为 OMG 组织董事会的成员，也主导了 DDS 标准的制定，在行业内有足够的权威。

开源 DDS 是相对于商用的 RTI DDS 等而言的，其也是根据 OMG 官方标准开发的，但源代码开放，主要包括 Fast DDS 或 Open DDS 等。尽管开源 DDS 会对 RTI 的商用 DDS 形成一定竞争，但开源 DDS 也存在不足：

（1）开源 DDS 的使用门槛高，例如 RTI DDS 的服务策略有 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 引入了大量的标准内置特性，例如基于内容和时间的过滤、与传输无关的可靠性、持久性、存活性、延迟/截至时间监视、可扩展类型等。当 AUTOSAR AP 与 DDS 一起构建通信框架时，该框架不仅可以与现有 API 及应用程序兼容，并且在可靠性、性能、灵活性和可伸缩性等方面，都可以提供重要的好处。

3> 订阅方和发布方是否强耦合：在SOME/IP中，在正常数据传输前，订阅方需要与发布方建立网络连接并询问发布方是否提供所需服务，在这个层面上，节点之间仍然具有一定耦合性。

在 DDS 标准下，每个订阅方或发布方只需要在自己的程序里面订阅或发布传感器数据就行了，不需要关心任何连接。因此在 DDS 中，服务订阅方和发布方的解耦更加彻底。

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

5> 应用场景不同：从应用场景的角度来看，SOME/IP 比较偏向于车载网络，且只能在基于网络层为 IP 类型的网络环境中使用；而 DDS 在传输方式上没有特别的限制，对基于非 IP 类型的网络，如共享内存、跨核通讯、PCI-E 等网络类型都可以支持。

而且，DDS 也有完备性的车联网解决方案，其独有的 DDS Security、DDS Web 功能可为用户提供车-云-移动端一站式的解决方案。

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

2.2 车载中间件有望成为国内汽车软件供应商的机遇点

车企在中间件方案上有多种选择，AUTOSAR AP 目前或难以“一枝独秀”。随着 EE 架构逐渐 由分布式向集中式演进，MCU 也将逐步被 SoC 取代， AUTOSAR CP 被 AUTOSAR AP、ROS 2、CyberRT 等中间件方案替代也是大势所趋。

然而，并不是所有的车企都选择了 AUTOSAR AP， 主要原因包括：

1> 使用成本高：AUTOSAR AP的费用可达几百万元，此外对于不同的域控制器、不同的芯片需要重复收费，这会给小型车企带来很大的成本压力。其次，AUTOSAR 的学习难度大、学习成本高，有时企业需要专门培训或招聘相关人才，这也会增加车企的费用开支。

2> 存在效率不高的问题：AUTOSAR AP 的配置很多，它是通过配置加上一部分代码去实现自己的功能。但配置多了之后，会存在代码臃肿以及低效的问题。

3> 静态部署与动态部署的理念的冲突：AUTOSAR AP 是从 AUTOSAR CP 发展而来的。 AUTOSAR CP 是静态部署，只适用于相对简单的业务逻辑和功能，其代码是固化的，功能是无法改变的，类似于过去的功能手机；AUTOSAR AP 则类似现在的智能手机，APP 可以跨平台、跨机型部署。这种动态部署的理念和之前的静态部署概念不甚相同，而其方法论却是基于静态部署衍生而来的，因此在实践层面会存在不少问题。

4> 当前无法满足智能网联的需求：云端跟车端所使用的操作系统不一样，而 AUTOSAR 只能负责车内的通信，不能支持车端到云端的通信，因而无法支持车路协同场景（车端跟云端的通信是通过 MQTT、Kafka 等中间件来实现的）。

除此之外，AUTOSAR 能否兼容车辆网联化中需要用到的数据平台、通信平台和地图平台也存在疑问。由于当前 AUTOSAR AP 还存在如上的一些问题，越来越多的 OEM 不太想完全用 AUTOSAR 去 解决智能驾驶操作系统的问题。

特斯拉没有用 AUTOSAR AP，国内的几大造车新势力也没有用（他们用的是 AUTOSAR CP DDS），奥迪和 TTTech 合作做的通信中间件 zFAS 也没有采用 AUTOSAR AP，甚至一些正在转型的传统车企也没打算用 AUTOSAR AP。

安波福、采埃孚、大 陆等公司提供的方案，仍然是基于 AUTOSAR CP 标准的接口。不同于已经非常标准化的 AUTOSAR CP，AUTOSAR AP 目前标准还不是很完善，标准每年在更新，因此很多主机厂也采取了观望的态势，毕竟 AUTOSAR AP 成本较高。

在这个背景下，ROS 2、Cyber RT 等其他中间件方案也有望得到更多车企的青睐。

车企自研中间件难度较大，由软件供应商提供中间件方案或与供应商共同开发中间件更具性价比。

中间件技术更加偏底层，目的是帮助主机厂降低上层软件的开发难度，提高开发效率。但终端用户并不关注自动驾驶的底层技术，他们更多地关注的是应用层，因此主机厂应该把更多的精力聚焦在那些可以向消费者展示竞争力的地方。

此外，随着中间件越来越成熟，最终有望形成一套被广泛应用的标准化软件，对于主机厂而言没必要投入大量人力、物力去自研中间件，由中间件供应商提供更具性价比。

当然也有主机厂认为，中间件的功能对于实现自动驾驶有重要意义，例如数据通信、资源管理、任务调度等，同时中间件对应用功能的实现也会有影响，因此中间件还是需要存在差异性的，此时部分主机厂会选择自研中间件。

百度、蔚来、小鹏等厂商的自研自动驾驶 OS，都是在基础内核之上进行中间件和应用软件自研（ROM 型操作系统）。

但对于主机厂而言，对软件及中间件 Know-how 积累较浅，也没有太多成功的案例，即使通过大规模地招聘，若没有软件公司的思维也难以协调好众多的软件人才。

对于软件/中间件供应商而言，他们更加容易与多家主机厂达成合作，从而扩大软件和中间件应用的范围和场景，对 Know-how 的积累是显著优于主机厂的。

因此对于主机厂而言，更可行的道路还是跟专业的中间件厂商合作，以此保证自己开发的个性化软件可以顺利地与通用化软件组合起来，而供应商也可以在提供标准产品的基础上再为主机厂提供半定制化的服务。

尽管目前海外厂商及开源中间件依旧为主流，但本土中间件解决方案提供商的机会正在来临。

对于通信中间件而言，购买国外产品可能会遇到“卡脖子”问题，因为核心技术由外方掌握，应用于某些关键业务场景就可能存在隐患。

此外，国外的通信中间件一开始不是以智能驾驶领域为目标，基本上是以军工和工业互联网为目标开发的，最近几年才慢慢被 AUTOSAR 引入。

因此，对于车厂而言，在国外产品上进行针对智能驾驶场景的开发难度比较大，成本也非常高。

另一方面，海外的厂商在国内没有庞大的技术支持团队，因此大多情况下只是给车企提供基础软件或一揽子解决方案，难以提供定制化开发服务。而且部分海外厂商收费是与项目绑定的，如果更换了车型，AUTOSAR 相关费用可能会重复收取，这也会增加成本。

本土中间件解决方案提供商的优势在于，可以为车厂提供定制化开发的服务，服务相应也会比国际厂商及时，并且在收费上更具弹性。在智能汽车差异化竞争的时代下，车厂大多具有旺盛的定制化需求，这也为本土厂商带来了机遇。

三、相关公司介绍

3.1 中科创达：深耕操作系统底层技术多年，具备提供全栈式

解决方案的能力公司在操作系统底层技术上积累深厚。成立初期，公司聚焦智能终端操作系统的开发，并与产业内的移动芯片、智能终端、应用软件等厂商建立起了坚实的合作关系，逐步在底层系统领域取得了优势。

上市之后，公司通过连续的收购加强了视觉技术及车载系统的技术积累，同时凭借着多年底层系统开发经验顺利地切入车载及 IoT 操作系统领域，并逐步实现了底层 OS 到应用层的延 伸，而各业务支撑的核心依旧是公司的操作系统能力以及视觉、AI 等方面长期的算法积累。

目前，公司在 Android、Linux、RTOS、ROS、鸿蒙等操作系统，以及智能视觉、智能语音、UI 引擎等领域已有深厚积累，其核心技术涵盖通信协议栈、深度学习、图形图像算法、操作系统优化和安全技术等多个方面。

公司具备提供从底层系统软件、中间件再到上层应用的全栈式解决方案的能力。

从公司 TurboX Auto 4.5 智能座舱平台架构来看：系统软件方面，公司具备 BSP 开发能力，解决方案支持多个主流芯片平台（高通、瑞萨、NXP 等），基于 Hypervisor 技术平台可支持 QNX、Linux、Android 等 OS 内核，并可对 OS 性能进行优化；

功能软件方面，平台具备提供音频及图像处理、传感器融合、车内网络等模块的能力；

上层应用方面，基于 Kanzi，平台提供信息娱乐系统、智能仪表、ADAS 和影音集成等产品，提供 5G、云服务并支持 FOTA 升级；

平台提供的中间件方案可实现软硬件接口的标准化，进而支持 SOA 架构汽车的持续迭代升级。

总结来看，公司的智能座舱方案实现了场景和服务的解耦，可快速完成场景服务的开发变更及升级迭代。

3.2 光庭信息：国内领先的智能汽车软件服务商

公司致力于构建以车载操作系统为核心的基础软件平台，具备全栈式软件开发能力。

公司自成立以来一直专注于汽车电子软件先端技术的研发与创新，可以从用户体验（UX）设计阶段参与产品设计全流程，具备提供人机交互软件开发、应用软件、中间件以及底层驱动开发的全栈式软件开发能力。

在智能座舱方面，公司实现了采用“一芯多屏”架构并基于瑞萨 R-CAR 芯片及 Hypervisor 技术的智能座舱软件解决方案。

该解决方案基于瑞萨单个高性能核心车载处理器，利用 Hypervisor 虚拟化技术，同时运行 QNX 和 Android 两套操作系统，以不同的中间件、人工智能算法、应用软件为核心，实现液晶仪表、抬头显示（HUD）、信息娱乐以及多屏互动等功能；

在智能驾驶方面，公司深度融合摄像头、超声波雷达与毫米波雷达的感知数据，并结合车辆特性构造包含高实时性的驾驶地图、安全舒适的智能驾驶路径计算及车辆控制算法等功能或技术的智能驾驶软件解决方案。

3.3 东软集团：东软睿驰是国内领先的操作系统及中间件解决

方案提供商东软睿驰专注于汽车基础软件的研发，NeuSAR 产品达到国际先进水平。东软睿驰成立于 2015 年 10 月，是东软集团的原子公司。

东软睿驰在创建之初就成立了基础软件团队，参与 AUTOSAR 组织，不断将发展中积累的对新兴软件平台和工具的认识，进行总结提炼，融合到自主研发的基础软件平台产品 NeuSAR 之中。

NeuSAR 获颁 ISO26262 产品认证证书，标志着东软睿驰已建立起符合功能安全最高 ASIL-D 级别的产品开发流程体系，同时产品已经达到国际先进水平。

NeuSAR 提供了丰富的基础软件、中间件和开发工具。

NeuSAR 产品兼容最新版 AUTOSAR 标准，既支持传统的 ECU 开发，同时对基于域控制器和新 EE 架构的软件开发提供丰富的基础软件、中间件和开发工具，可广泛应用在新一代架构下的自动驾驶、智能座舱、底盘动力、车身控制等域控制系统。

NeuSAR 产品主要由 cCore、aCore、中间件和工具链组成，其中 NeuSAR cCore 基于 AUTOSAR Classic Platform 标准开发，主要针对传统控制系统等实时性要求较高的汽车产品开发场景。

aCore 则基于 AUTOSAR Adaptive Platform 标准、面向自动驾驶等高性能计算需求场景，适应更加多变的通信模式，满足汽车互联、高度自动化和自动驾驶领域的应用。

3.4 经纬恒润： 在 AUTOSAR 软件产品方面具有深厚积累

3 月，公司正式升级为 AUTOSAR 高级合作伙伴。

公司于 2009 年与 AUTOSAR 联盟结缘，成为 AUTOSAR 组织的 Associate Partner，是国内首家加入 AUTOSAR 组织的基础软件供应商。

经过十几年的耕耘和自主研发，凭借在 AUTOSAR 方面的贡献，以及与 AUTOSAR 组织的多轮合作，最终 AUTOSAR 组织批准经纬恒润正式成为高级合作伙伴。

未来，公司将积极参与并领导各个工作组的相关工作，提出技术建议和想法，并积极参与评审会议。

公司自主研发的 EAS 是符合 AUTOSAR 标准的软件产品。

作为国内 AUTOSAR 自主产业的重要参与者，经纬恒润结合相关业务经验，自主研发了适应当前智能网联汽车技术发展趋势、符合 AUTOSAR 标准、稳定可靠且便捷易用的 AUTOSAR 软件产品——INTEWORK-EAS（ECU AUTOSAR Software，EAS）。

EAS 产品包括 Classic AUTOSAR Platform 以及 Adaptive AUTOSAR Platform 两个平台，解决方案涵盖了嵌入式标准软件、AUTOSAR 工具链、集成服务和培训等相关内容，旨在为国内的 OEM 和供应商提供稳定可靠、便捷易用的 AUTOSAR 平台。

2020 年 3 月，EAS 获得了 ISO26262 产品功能安全 ASIL-D 证书。

风险提示

汽车智能化落地不及预期

由于自动驾驶软件及算法开发难度及测试难度较大，同时目前政策法规方向尚不完善，因此自动驾驶的整体的市场成熟度仍然不高。目前，海内外众多厂商纷纷开始布局更高级别的自动驾驶，若自动驾驶技术演进与相关政策落地不及预期，将会对行业发展产生不利影响。

芯片短缺持续

智能汽车对高算力芯片有刚性的需求，若芯片短缺的问题得不到解决，将直接影响从域控制器到智能汽车整车的出货量，对行业整体产生不利影响。

——————————————————

请您关注，了解每日最新的行业分析报告！

报告属于原作者，我们不做任何投资建议！

如有侵权，请私信删除，谢谢！

获取更多精选报告请登录【远瞻智库官网】或点击：远瞻智库|文库-为三亿人打造的有用知识平台