data-distribution-service - DDS 和 SOME/IP 有什么区别？

SOME/IP 和 DDS 都允许分布式应用程序使用发布/订阅模式和服务请求/回复模式 (RPC) 进行通信。但也存在显着差异。

SOME/IP 专为汽车行业设计。SOME/IP 是作为 AUTOSAR 的一部分开发的规范集合，描述了其序列化协议、服务发现和与 Classic AUTOSAR 集成的转换器。

DDS（数据分发服务）针对更广泛的工业物联网领域。它是由对象管理组 (OMG) 发布的一系列开放标准。它专为分布式实时系统而设计，应用于交通、能源、医疗系统、工业自动化、航空航天和国防等众多行业。有许多商业和开源的独立实现。DDS 系列的第一个规范于 2004 年发布，从那时起已发展为一组12 个 DDS 标准，其中包括标准有线协议(DDS-RTPS)、API (DDS-PSM-CXX、DDS-PSM-JAVA以及从 IDL 到 C、Ada 等的映射）类型系统（DDS-XTYPES）、数据传递模式（DDS 用于以数据为中心的发布-订阅和 DDS-RPC 用于请求-回复）、安全性(DDS-SECURITY)、系统描述(DDS-XML)、数据建模(IDL) 和其他通信框架的网关(DDS-WEB 、DDS-OPCUA 和 DDS-XRCE）。

在技术和概念上存在许多差异，因此我将它们分为不同的类别：

沟通模式
应用程序编程接口 (API)
网络传输
安全方法
服务质量
从其他规格使用

沟通模式

SOME/IP 可以看作是一种基于对象的面向服务的体系结构。信息通过实例化服务对象提供给系统，这些由客户端应用程序访问，客户端应用程序为他们想要访问的每个服务实例实例化相应的“代理”对象。客户端应用程序通过将代理对象附加到服务对象并使用它来监视事件和字段更改来订阅信息。他们还可以调用服务对象上的操作来执行远程过程调用或读/写特定字段。

DDS 从根本上提供了一个解耦的、以数据为中心的发布订阅模型。也称为“数据总线”模式。应用程序参与 DataBus 一个对等点，可以发布/订阅任何数据（由 DDS-Topic 名称标识）以及调用或实现任何服务操作（由 DDS-Service 名称标识）。DDS 是完全点对点的——它不需要任何中间人。有一种发现机制不断运行以检测引用相同主题名称的兼容发布者和订阅者应用程序；一旦检测到它们，它们就开始直接交换信息。订阅者应用程序可以指定过滤器（基于内容或时间）来指示他们想要接收的信息。过滤器可以发生在发布者端，以减少在线上传输的信息。

DDS 和 SOME/IP 之间的一个显着区别在于，使用 DDS，应用程序不需要绑定到服务的特定实现。它简单地引用主题和服务，并且可以完全透明地进行一对一或一对多的通信，而无需对应用程序代码进行任何更改。它确实需要跟踪单独对等点的存在或管理任何新对象以响应对等点的加入或离开。这一切都是自动处理的。从这个意义上说，它比 SOME/IP 更具动态性。

应用程序编程接口

SOME/IP 没有定义标准 API，实现通常提供 C++ API，但它们不能跨实现移植。然而，通常 SOME/IP 用作 AUTOSAR 的一部分，它确实定义了一些标准 API。

DDS 具有适用于多种语言的标准 API。对于 C++ 和 Java，这些都包含在 DDS-PSM-JAVA 和 DDS-PSM-CXX 规范中。标准 C 和 ADA API 源自 IDL 到 C 和 ADA 规范。除此之外，还有针对 C# 和其他语言的供应商特定 API。因此，通常可以移植 DDS 应用程序并在 DDS 实现之间切换。

网络传输

SOME/IP 支持 UDP 和 TCP 进行数据传输。AUTOSAR 4.3 引入了对通过 UDP 分割大于 1400 字节的有效负载的支持。对于可靠的通信，SOME/IP 回退到 TCP。

DDS 使用一种称为 RTPS（实时发布订阅）的有线协议，该协议定义在一个独立于平台的模型中，可以映射到不同的网络传输协议。大多数 DDS (DDS-RTPS) 实现至少支持 UDP、TCP 和共享内存。RTPS 实现了与传输无关的可靠性和分段协议，该协议运行在任何传输之上，包括带有多播的 UDP。因此，使用 DDS，可以通过多播 UDP 处理大数据和可靠数据。有些/IP 无法做到这一点。

许多 DDS 实现提供了“自定义传输”SDK，因此可以在您自己的自定义传输上运行 DDS，而不会牺牲任何功能和 QoS。这对于 SOME/IP 是不可能的，因为某些特性（如可靠性和分段）必须由传输实现。

安全方法

一般来说，SOME/IP 也依赖于传输来保证安全。因此，要安全地使用它，就需要在 TLS 或 DTLS 上运行。

也可以通过 TLS 或 DTLS 运行 DDS 作为传输，但这不是首选解决方案。相反，对于 DDS，最好使用 DDS 安全规范中定义的机制，这些机制与传输无关。DDS 安全性还提供了对安全性的更细粒度的控制以及用于访问控制的语言，因此可以分别保护 DDS 域和主题，并区分对主题的读取和写入权限。此外，由于 DDS 安全性与传输无关，因此它可以与任何传输一起使用，包括共享内存、多播或自定义应用程序定义的传输。

服务质量支持

SOME/IP 仅提供一种用于选择 UDP 与 TCP 的“可靠性”Qos 设置。其他任何事情都必须使用自定义应用程序逻辑来实现，这取决于 QoS 策略，可能非常困难。此外，应用层代码也不是那么可移植，并且要求所有应用程序都包含相同的代码，或者至少链接一个通用的非标准库。

DDS 提供了许多 QoS 策略，使用户能够以声明方式指定发布者和订阅者之间如何交换信息。DDS 标准定义了 20 多个独立的策略。这些策略不仅控制可靠性，还控制资源使用、数据优先级、数据可用性和故障转移等其他方面。例如，如果发布者或订阅者应用程序未能以特定速率发送或传递信息，QoS 设置提供了建立最后期限以提供通知的能力；设置数据的持久性，以便在信息生成和发送后可以将其重新传输给加入的订阅者应用程序；配置历史深度发布者和订阅者应用程序；部署冗余系统，根据所有权强度自动从众多源中选择一个，配置自动活跃消息以确定远程应用程序是否仍然活跃，并在应用程序无响应时执行自动故障转移。您可以从DDS 规范的第 2.2.3 节或不同实现的文档中获得更多详细信息（例如，参见RTI Connext DDS 的此 Qos Cheat-Sheet）。

从其他规格使用

SOME/IP 主要由 AUTOSAR 用于汽车应用。

DDS 有更横向的用途。它通常直接用作连接框架。事实上，它被工业互联网联盟 (IIC) 确定为 IIoT 的“核心连接框架”之一（参见工业物联网连接框架文档）。它还被用作其他标准和框架的一部分，例如OpenFMB、ROS2、MD PnP、FACE，并且它也被包含在AUTOSAR Adaptive（从版本 18.03 开始）中。