（ 告出品方/分析师：东方证券 浦俊懿 谢忱）
一、操作系统是汽车软件的核心，车企角力车载 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中，在正常数据传输前，订阅方需要与发布方建立 络连接并询问发布方是否提供所需服务，在这个层
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！