SOA通信中间件及其协议介绍

谈思实验室 2025-03-20 17:58 53浏览 0评论 0点赞

双天线智能切换+多协议并发传输方案详解 EPC专家实战拆解：机器人/无人机/电动汽车电机能效优化技巧

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

前言

SOA（面向服务的架构）的软件设计原则之一是模块化。模块化可以提高软件系统的可维护性和代码重用性，并且能够隔离故障。举例来说，自动驾驶系统可以分解为特定的任务模块，如数据采集、状态估计和任务规划等。为了完成各自的任务，这些模块需要相互交换信息。在现代操作系统中，将单个模块映射到独立的软件进程非常方便，这些进程可以位于同一计算设备上，也可以位于物理上独立的计算设备上。这使得进程间通信成为一个深入研究的问题，因为信息交换是通过进程间的通信来实现的。

通信中间件

在软件定义汽车中，应用程序之间的跨进程或跨核通信是一个需要解决的问题。模块化架构为开发人员提供了便利，但也引入了对通信中间件的需求。

在没有使用通信中间件的情况下，开发人员需要自己定义数据的格式、发送方和接收方。然而，使用基于服务/数据的发布和订阅模式（如SOME/IP和DDS），开发人员只需要明确需要什么样的数据以及数据应该传递到哪里，而无需关注数据的发送方和发送方式。

以数据为中心是相对于传统的以消息为中心而言的，其本质区别在于通信中间件知道存储了什么数据并能够控制如何共享这些数据。对于传统的以消息为中心的中间件，程序员必须为发送消息编写代码，而对于以数据为中心的中间件，程序员只需为如何共享数据编写代码，然后可以直接共享数据值。

通信中间件可以采用点对点、消息队列和发布/订阅三种工作模式，SOME/IP和DDS都采用了发布/订阅模式。

在发布/订阅模型中，发布者和订阅者通过主题进行关联，双方不需要知道对方在何处，也不需要同时在线。这实现了通信双方在时间、空间和数据通信上的多维松耦合。

此外，与面向信号的CAN相比，DDS和SOME/IP都是面向服务的通信协议。两者的区别在于面向信号的数据传输始终循环发送，而面向服务的通信方式不同，只有在客户端请求或服务器通知特定订阅者时，才在客户端-服务器配置中交换数据。这确保了永远不会浪费带宽，并且仅在需要的时间和地点进行数据通信/交换。因此，面向服务的通信协议可以大大减少网络负载，提高通信效率。

在软件定义汽车时代，车内的所有可调用功能都被视为服务，并提供不同类型的调用接口，这些接口可以按以下方式分类：

1、API接口：提供各类函数的调用接口，使应用程序能够调用系统内部的功能实现函数。应用程序可以通过调用相关的API接口来提供和使用功能服务。

3、系统原生服务：操作系统和基础类库提供的可操作能力，包括对系统CPU和内存的监测、应用程序的监控、系统资源的划分等。此外，还可以调用C++、boost等基础类库。

4、IPC接口：各种IPC机制提供系统内进程间的调用能力，包括使用套接字（socket）、共享内存等进程间通信方式，以及使用特定的跨核通信方式如IPCF。

5、协议栈接口：通过网络协议栈提供跨平台的调用能力，包括SOME/IP、DDS、MQTT、HTTP等网络协议的调度服务、接口封装和协议转换等。

尽管在互联网领域中SOA（面向服务的架构）已经被应用了很长时间，但在汽车行业中，它算是相对较新的概念。在Adaptive AutoSAR框架中，通信管理模块包括进程间通信和网络协议栈。

鉴于汽车应用场景和通信需求的特殊性，许多互联网的SOA技术并不能直接应用于汽车领域。一般来说，SOA通信中间件系统的各个层面需要满足以下要求：

1、本地服务和远程服务之间的通信应该使用统一的接口描述语言（IDL）定义的文件作为契约。IDL是一种中立的接口描述语言，与具体的操作系统和编程语言无关。

2、SOA框架的底层核心功能应具备以下特点：服务发现、消息序列化、内部事件/消息处理和传输功能。应用程序、服务和操作系统之间可以通过标准的通信协议或服务接口相互通信或访问，特别是要满足传感数据的大数据吞吐传输需求。必须支持典型的车内通信协议，如SOME/IP协议、DDS规范等。服务发现功能应具备访问控制功能，以防止未经授权的用户进行窃听和侵入；传输功能应具备数据加密和签名等功能，以确保通信数据的安全性。

在未来，汽车将与更多的基础设施进行连接，为了实现与它们的连接，将需要使用不同的通信协议。

汽车SOA 通信架构

HTTP、MQTT、SOME/IP和DDS等协议都用于实现SOA架构中的通信，只是在不同的场景下承担不同的责任。例如，SOME/IP协议用于车内节点之间的服务通信，而HTTP和MQTT用于与互联网模块进行通信。尽管它们在实现机制上有些许差异，但它们可以相互切换使用。

MQTT、DDS、AMQP、REST和CoAP等协议都已被广泛应用，并且每种协议都至少有10种不同的代码实现。它们都宣称支持实时的发布/订阅物联网协议。然而，在具体的系统架构设计中，需要考虑实际场景中的通信需求，并选择适合的协议。各种协议的特点如表所示。

SOME/IP 介绍

2011年，宝马设计并提出了SOME/IP（Scalable Service-oriented Middleware over IP）协议。SOME/IP采用服务器-客户端的服务通信模式，并且具备高度可扩展性。SOME/IP协议是一种应用层协议，运行在TCP/UDP传输协议之上（车载以太网第四层以上）。它作为以太网通信的中间件，实现应用层与IP层之间的数据交互，使其不依赖于操作系统，并且兼容AUTOSAR和非AUTOSAR平台。因此，SOME/IP可以独立于硬件平台、操作系统和编程语言。

议架构

SOME/IP具备满足车用需求的特性，主要包括以下几个方面：基于服务的通信方式，占用空间小，与AUTOSAR兼容（其他中间件不具备兼容性），可伸缩性（适用于小型和大型平台），以及兼容性（可适用于车辆使用的各种操作系统，如AUTOSAR、OSEK、QNX和Linux）。

SOME/IP支持AUTOSAR CP、AUTOSAR AP以及非AUTOSAR平台之间的通信交互。宝马设计SOME/IP协议后，它被AUTOSAR纳入正式标准，并随着CP规范的发布而被广泛应用于车载以太网，因此可以说是AUTOSAR CP推动了SOME/IP的广泛使用。

在AUTOSAR架构中，SOME/IP-SD模块位于AUTOSAR BSW Mode Manager模块（BswM）和AUTOSAR Socket Adaptor模块（SoAd）之间。BswM模块提供了通用模式请求和服务请求之间的连接，而SoAd模块处理以太网堆栈和SD模块之间的服务请求。通过配置SoAd中的Socket Connection表，可以接收其他ECU的SD模块发送的单播和多播报文。

借助SOME/IP协议的高度平台扩展性，可以实现不同平台之间的数据交互，而统一的SOME/IP通信机制是不同平台通信的前提。为了在不同软件平台上运行SOME/IP，实现整车以太网上的SOA架构通信机制，AP规范中也同步引入了SOME/IP，因此在AUTOSAR系统中，CP和AP之间实现SOME/IP通信相对容易。

为了促进非AUTOSAR软件平台与车内CP和APECU之间的交互，GENIVI系统同样开发了一套开源的vSOME/IP软件源码，以便与CP/AP进行交互。然而，由于vSOME/IP是开源的，性能可能略有差异，因此需要统一的规范进行约束，以进行深度的二次开发。目前，全球最大的商用SOME/IP产品供应商是Vector，而开源版的vSOME/IP由GENIVI协会维护。

DDS 介绍

DDS（Data Distribution Service）是由OMG（Object Management Group）发布的分布式通信规范。OMG成立于1989年，是一个国际性、开放性、非营利性的技术标准联盟，由供应商、终端用户、学术机构和政府机构推动。OMG工作组致力于制定企业集成标准和开发可为数千个垂直行业提供现实价值的技术标准，其中包括统一建模语言SYSML、UML，以及中间件标准CORBA、DDS等。

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

DDS的特点：

1、数据中心（Data Centricity）

DDS最重要的特性是以数据为中心，这与其他许多通信中间件不同。DDS的数据共享以Topic为单元，应用程序能够通过Topic判断包含的数据类型，而不必依赖其他上下文信息。同时，DDS能够按照用户定义的方式自动地存储、发布或订阅数据，使应用程序能够像访问本地数据一样进行数据的写入或读取。

DDS 数据中心

2、全局数据空间（Global Data space）

DDS实现的数据共享可以被理解为一个抽象的全局数据空间，无论应用程序是用哪种开发语言编写，或者在哪种操作系统上运行，都可以以相同的方式访问这个全局数据空间，就像访问本地存储空间一样。当然，全局数据空间只是一个抽象概念，在实际实现中，数据仍然被分别存储在每个应用程序的本地空间中。在系统运行时，数据是按需传输或存储的，数据的发布者只发送订阅者需要的数据，而订阅者只接收并存储本地应用程序当前所需的数据。

全局数据空间

3、服务质量（Quality of service）

DDS还提供了高度灵活的QoS（Quality of Service）策略，以满足用户对数据共享方式的不同需求，例如可靠性和故障处理等。对于对数据安全性要求较高的系统，DDS还提供了精细的数据安全控制，包括应用程序身份认证、权限控制和数据加密等。

4、动态发现（Dynamic Discovery）

类似于SOME/IP-SD，DDS提供了数据发布者和订阅者的动态发现机制，这意味着用户无需手动配置通信节点的地址或其他属性信息，因为它们在运行过程中会自动发现对方并自动完成相关配置，实现了即插即用的功能。

5、可扩展架构（Scalable Architecture）

DDS可应用于边缘计算、雾计算和云计算领域。在边缘计算中，DDS可以实现高速实时的设备间通信。在中间系统中，DDS提供健壮可靠的QoS和内容感知的信息流。DDS提供可扩展的信息访问和数据分发手段，用于集成信息系统，将各系统接入云端。

OMG DDS的适用范围广泛，涵盖了从小型设备到云计算系统等超大型系统。DDS能够以超高速传输数据并同时管理数千个数据对象，提供极高的可用性和安全性，非常适用于物联网。通过提供一个标准的通信层，DDS屏蔽了底层复杂性，简化了分布式系统的开发。

可扩展架构

6、安全（Security）

DDS为关键任务的工业物联网环境提供了全面的安全保护机制，跨系统、跨供应商，覆盖从边缘设备到云端的安全性需求。

DDS提供了身份验证、访问控制、数据加密和数据完整性等安全机制，以确保数据分发的安全性。这些安全机制是在点对点对等架构上实现的，不会影响实时通信的性能。

目前，DDS已被多个车载中间件平台引入。AUTOSAR AP已完整地集成了DDS标准的网络绑定。另外，虽然AUTOSAR CP的标准规范本身不支持DDS，但通过一些变通方法也可以在CP上集成DDS。ROS2和CyberRT的底层都使用了开源的DDS作为最重要的通信机制。针对自动驾驶领域的SOC芯片，如Xavier和Orin，也都预留了DDS接口。RTI作为OMG组织董事会的成员，领导了DDS标准的制定，并开发了名为Connext的DDS品牌，因此也被称为Connext DDS。

开源DDS相对于商用的RTI DDS等来说，是根据OMG官方标准开发的，但源代码是开放的，主要包括Fast DDS和Open DDS等。

在自动驾驶领域，由RTI原核心团队成员在欧洲创办的eProsima公司推出了影响力较大的开源DDS，名为Fast DDS。在eProsima将Fast DDS的源代码开放后，用户可以直接在GitHub上免费下载。使用Fast DDS需要向eProsima支付费用以获得支持。

Open DDS由位于圣路易斯和凤凰城的Object Computing的ACE/TAO团队开发，与Fast DDS有一定的相似性，两者都基于RTPS实现，都是面向数据的通信框架，并遵循同一标准。这类框架的典型特征是去中心化、支持QoS机制和实时通信，并通常与序列化工具如protobuf进行绑定。

SOME/IP 与 DDS 对比

SOME/IP和DDS是目前在域控最常用的两类通信中间件，它们都是面向服务的通信协议，并采用以数据为中心的发布/订阅模式。

然而，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类型的网络，例如共享内存、跨核通信、PCIe等。此外，DDS还提供了完备的车联网解决方案，其独有的DDS Security和DDS Web功能为用户提供了一站式的“车-云-移动端”解决方案。