智能汽车软件架构为什么需要中间件?|EEA系列研究笔记2026

01 智能汽车软件架构为什么需要中间件？

智能手机，作为单一设备，软件规模最庞大。

但手机只有一个核心计算单元，传感器和执行器充分解耦，并形成了关键的产业标准，各领域的成熟组件能轻松协同运行。

开发者在开发应用时，无需深入了解底层操作（如访问摄像头或确保通信安全性等），只需调用接口获取所需功能即可。

开发者因此能专注于应用程序的创新。

对于汽车开发者而言，如果要想获得同样的便利性，是一件非常困难的事情。

过去，传统的“基于信号通信机制”电子电气架构下，汽车控制器的每一个功能的升级，可能都需要供应商的配合。

然而，面对动辄过百的控制器，涉及诸多供应商的配合，其开发和管理已经变成了“几乎不可能”的任务。

同时，不同功能之间互相耦合的特性，更是会“牵一发而动全身”，让功能并不需要升级的控制器供应商被“牵连”进来。

所以，智能汽车的电子电气架构，要像智能手机一样实现「控制集中」、「软硬解耦」和「软软解耦」才行。

如今，汽车电子电气架构逐渐演进至“中央计算+区域控制”，「控制集中」于几个少数的控制器已在逐步实现。剩下的「软硬解耦」和「软软解耦」就需要在软件架构上下足功夫来。

在介绍SOA软件风格时，就已经提到，其目的是为了实现软件的复用，尤其是应用软件。

SOA通过软件功能（服务）单元的接口标准化、功能的抽象化与无状态化等，改变了传统软件系统中业务单元之间的依赖。也即实现了「软硬解耦」和「软软解耦」。

这意味着，OEM对控制器的软件进行OTA升级时，便可以自己掌控大局，也不再会“牵一发而动全身”了。

那么，帮助SOA实现软件功能（服务）单元的接口标准化、功能的抽象化与无状态化的中间件，已成为关键。

02 什么是智能汽车软件架构的中间件？

中间件，抽象整车基础硬件和系统、覆盖不同功能域的通信框架、为上层应用提供平台。中间件，是在各个域控制器上都可以使用的、与业务无关的软件组件，是开发平台最基础、最核心的部分。

在汽车电子电气系统中实现SOA，目前较成熟的中间件方案有SOME/IP（Scalable Service-Oriented Middlewar Eover IP,运行于IP之上的可伸缩的面向服务中间件）和DDS（Data Distribution Service，数据分发服务）。

它们都允许分布式应用程序使用“发布/订阅”模式和“服务请求/应答”模式进行通信，但也有显著的差异。

03 两类中间件的区别有哪些？

SOME/IP，是专门为汽车行业设计的一系列中间件规范，属于AUTOSAR的一部分（AUTOSAR AP要靠ARACOM层，AUTOSAR CP要靠RTE、COM），把数据从A传到B。SOME/IP，能够传输的数据量较少，适合于控制类的命令传输，适用于如摄像头、传统AUTOSAR的控制器等小型设备。

DDS，是完整的中间件，包含标准API、QoS、序列化、Security等等。DDS被工业互联网联盟认定为工业物联网的核心链接框架之一，在汽车行业也已被包括在AUTOSAR AP中，而AUTOSAR CP中的诸多参数都可以map到DDS里相关的参数。DDS，更适合大数据量的可靠传输，对智驾系统来说尤为重要。

1）通信模式

SOME/IP，可以被视为一种基于对象（信息以对象的形式存在和传递）和面向服务（系统中的各个组件通过提供和调用服务来交互）的架构。

客户端：需要使用服务的一方。

服务端：提供服务的一方。

服务：系统提供的功能单元，它封装了一组特定的操作，通过方法来定义。

服务对象：提供服务的对象，有特定的属性（服务ID、方法列表）和方法（给外部的接口）。

代理对象：客户端为了方便调用远程服务，会创建一个本地代理对象，它与远程服务对象具有相同的接口。客户端通过本地代理对象调用服务，实际上是在调用远程服务。

DDS，提供了一个解耦的、以数据为中心的“发布-订阅(Publish–Subscribe)”模型，可以称为Data Bus模式。应用层程序可以通过DDS-Topic名称标识发布或订阅任何数据，也可以通过DDS-Service名称标识调用或实现任何服务，是peer to peer（去中心化的一种方式），不需要代理（“中心化”）。

2）网络传输

SOME/IP支持UDP和TCP两种数据传输方式。AUTOSAR 4.3引入了对UDP上大于1400字节的有效负载分段的支持。

DDS使用RTPS(Real Time Publish and Subscriber)协议。RTPS定义在一个独立于平台的模型中，可以映射到不同的网络传输协议。RTPS支持UDP、TCP、Share Memory、Zero-Copy，实现了一个与传输无关的可靠性和分片协议，可以运行在任何传输路径上，包括带组播的UDP（组播，也称为多播，是UDP的一种特性，允许多个接收者同时接收到相同的数据包）。

3）QoS

SOME/IP提供一个可靠性QoS设置（Quality of Service, QoS，一种应用于网络传输的技术，用以在有限的网络容量下可靠地运行高优先级应用程序和保证高优先级数据的传输），用于选择UDP和TCP，其他功能必须由自定义应用程序的逻辑来实现。

这难度较大，要求所有的应用程序都包含相同的代码，或者至少连接一个通用的非标准库，从而导致应用层代码的可移植性不高。

DDS提供了20多个单独的QoS策略，允许用户以声明的方式指定发布者和订阅者之间如何交换信息。这些策略不仅可以控制可靠性，还可以控制资源使用、数据优先级、数据可用性和故障转移等。

4）API

SOME/IP，本身没有定义标准API，通常会提供基于C++的API，移植较难。但SOME/IP被用作AUTOSAR的一部分实现时，通常会定义一些标准API，从而提供基于AUTOSAR的可移植性。

DDS，有可用于多种语言的标准API。对于C++和Java，API被包含在DDS-PSM-CXX和DDS-PSM-JAVA规范中，还有针对C#和其他语言的特定于供应商的API。

5）Security

SOME/IP，一般都依赖于传输层的安全性，为了保证使用安全，需要在TLS或DTLS上运行。

DDS，可以使用与传输层无关的DDS安全规范中定义的机制，而且还提供了更细颗粒度的安全控制和访问执行控制，可以用于任何数据传输，包括多播UDP、Share Memory或自定义应用程序定义的数据传输。

Source: 《智能汽车电子电气架构详解》

– 基于行业研究，解读产业趋势，分享研究笔记

– 新能源汽车行研报告及咨询需求，请留言联系