DDS 和 SOME/IP 有什么区别？
What's the difference between DDS and SOME/IP?
SOME/IP是一种汽车中间件解决方案，可用于控制消息。
DDS也是一种用于通信的汽车中间件。
我想知道它们之间有什么区别？
而且，我为什么以及什么时候应该选择其中之一？
SOME/IP 和 DDS 都允许分布式应用程序使用 publish/subscribe 模式和服务 request/reply 模式 (RPC) 进行通信。但也存在显着差异。
SOME/IP 专为汽车行业设计。 SOME/IP 是作为 AUTOSAR 的一部分开发的规范集合，描述了其 序列化协议 、 服务发现 和 transformer 用于与经典 AUTOSAR 集成。
DDS（数据分发服务）面向更广泛的工业物联网领域。它是由对象管理组织 (OMG) 发布的一系列开放标准。它专为分布式实时系统而设计，用于 many industries including transportation, energy, medical systems, industrial automation, aerospace and defense, etc. There are many independent implementations both commercial and open source. The first specification in the DDS family was released in 2004 and since then has grown to a set of 12 DDS standards，其中包括标准 wire-protocol (DDS-RTPS)，APIs （DDS-PSM-CXX、DDS-PSM-JAVA 以及从 IDL 到 C、Ada 等的映射）类型系统 (DDS-XTYPES), 数据传输模式（DDS 用于以数据为中心的发布-订阅和 DDS-RPC 用于请求-回复），安全性（DDS-安全），系统描述（DDS-XML），数据建模（IDL），以及网关到其他通信框架（DDS-WEB、DDS-OPCUA 和 DDS-XRCE）。
技术上和概念上有很多差异，所以我将它们分为不同的类别：
- 通信模式
- 应用程序编程接口（APIs）
- 网络传输
- 安全方法
- 服务质量
- 使用其他规格
通信模式
SOME/IP可以看作是一种基于对象的面向服务的架构。通过实例化服务对象向系统提供信息，这些由客户端应用程序访问，客户端应用程序为他们想要访问的每个服务实例实例化相应的“代理”对象。客户端应用程序通过将代理对象附加到服务对象并使用它来监视事件和字段更改来订阅信息。他们还可以调用服务对象上的操作来执行远程过程调用或 read/write 特定字段。
DDS 从根本上提供了一个解耦的、以数据为中心的发布订阅模型。 Aso 被称为“数据总线”模式。应用程序参与 DataBus a peer 并且可以 publish/subscribe 任何数据（由 DDS 主题名称标识）以及调用或实现任何服务操作（由 DDS 服务名称标识）。 DDS 是完全点对点的——它不需要中间的任何代理。有一种发现机制可以不断 运行 检测引用相同主题名称的兼容发布者和订阅者应用程序；一旦检测到它们，它们就会开始直接交换信息。订阅者应用程序可以指定过滤器（基于内容或基于时间）来指示他们想要接收的信息。可以在发布者端进行过滤以减少传输的信息。
DDS 和 SOME/IP 之间的一个显着区别是，使用 DDS，应用程序不需要绑定到服务的特定实现。它简单地引用主题和服务，并且可以完全透明地进行一对一或一对多通信，而无需对应用程序代码进行任何更改。它确实需要跟踪单独的对等点的存在或管理任何新对象以响应对等点的加入或离开。都是自动处理的。从这个意义上说，它比 SOME/IP.
更具活力
应用程序编程接口
SOME/IP 没有定义标准 API，实现通常提供 C++ API，但它们不能跨实现移植。然而，通常 SOME/IP 用作 AUTOSAR 的一部分，它确实定义了一些标准 APIs.
DDS 有多种语言的标准 APIs。对于 C++ 和 Java，这些包含在 DDS-PSM-JAVA 和 DDS-PSM-CXX 规范中。标准的 C 和 ADA API 是从 IDL 到 C 和 ADA 规范派生的。最重要的是，对于 C# 和其他语言，有供应商特定的 APIs。因此，通常可以移植 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 处理大数据和可靠数据。 SOME/IP 不能那样做。
许多 DDS 实现提供“自定义传输”SDK，因此可以 运行 通过您自己的自定义传输进行 DDS，而不会牺牲任何功能和 QoS。这对于 SOME/IP 是不可能的，因为某些特性（如可靠性和碎片化）必须由传输实现。
安全方法
一般来说 SOME/IP 也依赖传输来保证安全。因此，为了安全地使用它，需要在 TLS 或 DTLS 上 运行。
也可以 运行 DDS over TLS 或 DTLS 作为传输，但这不是首选解决方案。相反，对于 DDS，最好使用 DDS 安全规范中定义的机制，这些机制与传输无关。 DDS 安全还提供了更细粒度的安全控制和一种访问控制语言，因此可以单独保护 DDS 域和主题，并区分对主题的读写权限。此外，由于 DDS 安全性与传输无关，因此它可以与任何传输一起使用，包括共享内存、多播或自定义应用程序定义的传输。
服务质量支持
SOME/IP 仅提供一个用于 select UDP 与 TCP 的“可靠性”Qos 设置。任何其他事情都必须使用自定义应用程序逻辑来实现，这取决于 QoS 策略，这可能非常困难。应用层代码也不是那么可移植，需要所有应用程序包含相同的代码或至少 link 一个通用的非标准库。
DDS 提供了许多 QoS 策略，使用户能够以声明方式指定发布者和订阅者之间如何交换信息。 DDS 标准定义了 20 多个独立的策略。这些策略不仅控制可靠性，还控制资源使用、数据优先级、数据可用性和故障转移等其他方面。例如，QoS 设置提供了建立 截止日期 的能力，以便在发布者或订阅者应用程序未能以特定速率发送或传递信息时提供通知；设置数据的 持久性 以便可以将其重新传输给在信息生成和发送后加入的订户应用程序；配置发布者和订阅者应用程序的历史深度；部署冗余系统，根据 所有权强度 自动 select 一个来源，配置自动 活跃度 消息以确定远程应用程序是否仍然可用存活并在应用程序无响应时执行自动故障转移。您可以从 DDS Specification or from the documentation of the different implementations (see for example this Qos Cheat-Sheet from RTI Connext DDS).
的第 2.2.3 节中获得更多详细信息
使用其他规范
SOME/IP 主要由 AUTOSAR 用于汽车应用。
DDS有更多的横向用途。它通常直接用作连接框架。事实上，它被工业互联网联盟 (IIC) 确定为 IIoT 的“核心连接框架”之一（参见 Industrial Internet of Things Connectivity Framework 文档）。
它也被用作其他标准和框架的一部分，例如 OpenFMB, ROS2, MD PnP, FACE, and its is also being included into AUTOSAR Adaptive (starting in version 18.03).
SOME/IP是一种汽车中间件解决方案，可用于控制消息。 DDS也是一种用于通信的汽车中间件。 我想知道它们之间有什么区别？ 而且，我为什么以及什么时候应该选择其中之一？
SOME/IP 和 DDS 都允许分布式应用程序使用 publish/subscribe 模式和服务 request/reply 模式 (RPC) 进行通信。但也存在显着差异。
SOME/IP 专为汽车行业设计。 SOME/IP 是作为 AUTOSAR 的一部分开发的规范集合，描述了其 序列化协议 、 服务发现 和 transformer 用于与经典 AUTOSAR 集成。
DDS（数据分发服务）面向更广泛的工业物联网领域。它是由对象管理组织 (OMG) 发布的一系列开放标准。它专为分布式实时系统而设计，用于 many industries including transportation, energy, medical systems, industrial automation, aerospace and defense, etc. There are many independent implementations both commercial and open source. The first specification in the DDS family was released in 2004 and since then has grown to a set of 12 DDS standards，其中包括标准 wire-protocol (DDS-RTPS)，APIs （DDS-PSM-CXX、DDS-PSM-JAVA 以及从 IDL 到 C、Ada 等的映射）类型系统 (DDS-XTYPES), 数据传输模式（DDS 用于以数据为中心的发布-订阅和 DDS-RPC 用于请求-回复），安全性（DDS-安全），系统描述（DDS-XML），数据建模（IDL），以及网关到其他通信框架（DDS-WEB、DDS-OPCUA 和 DDS-XRCE）。
技术上和概念上有很多差异，所以我将它们分为不同的类别：
- 通信模式
- 应用程序编程接口（APIs）
- 网络传输
- 安全方法
- 服务质量
- 使用其他规格
通信模式
SOME/IP可以看作是一种基于对象的面向服务的架构。通过实例化服务对象向系统提供信息，这些由客户端应用程序访问，客户端应用程序为他们想要访问的每个服务实例实例化相应的“代理”对象。客户端应用程序通过将代理对象附加到服务对象并使用它来监视事件和字段更改来订阅信息。他们还可以调用服务对象上的操作来执行远程过程调用或 read/write 特定字段。
DDS 从根本上提供了一个解耦的、以数据为中心的发布订阅模型。 Aso 被称为“数据总线”模式。应用程序参与 DataBus a peer 并且可以 publish/subscribe 任何数据（由 DDS 主题名称标识）以及调用或实现任何服务操作（由 DDS 服务名称标识）。 DDS 是完全点对点的——它不需要中间的任何代理。有一种发现机制可以不断 运行 检测引用相同主题名称的兼容发布者和订阅者应用程序；一旦检测到它们，它们就会开始直接交换信息。订阅者应用程序可以指定过滤器（基于内容或基于时间）来指示他们想要接收的信息。可以在发布者端进行过滤以减少传输的信息。
DDS 和 SOME/IP 之间的一个显着区别是，使用 DDS，应用程序不需要绑定到服务的特定实现。它简单地引用主题和服务，并且可以完全透明地进行一对一或一对多通信，而无需对应用程序代码进行任何更改。它确实需要跟踪单独的对等点的存在或管理任何新对象以响应对等点的加入或离开。都是自动处理的。从这个意义上说，它比 SOME/IP.
更具活力应用程序编程接口
SOME/IP 没有定义标准 API，实现通常提供 C++ API，但它们不能跨实现移植。然而，通常 SOME/IP 用作 AUTOSAR 的一部分，它确实定义了一些标准 APIs.
DDS 有多种语言的标准 APIs。对于 C++ 和 Java，这些包含在 DDS-PSM-JAVA 和 DDS-PSM-CXX 规范中。标准的 C 和 ADA API 是从 IDL 到 C 和 ADA 规范派生的。最重要的是，对于 C# 和其他语言，有供应商特定的 APIs。因此，通常可以移植 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 处理大数据和可靠数据。 SOME/IP 不能那样做。
许多 DDS 实现提供“自定义传输”SDK，因此可以 运行 通过您自己的自定义传输进行 DDS，而不会牺牲任何功能和 QoS。这对于 SOME/IP 是不可能的，因为某些特性（如可靠性和碎片化）必须由传输实现。
安全方法
一般来说 SOME/IP 也依赖传输来保证安全。因此，为了安全地使用它，需要在 TLS 或 DTLS 上 运行。
也可以 运行 DDS over TLS 或 DTLS 作为传输，但这不是首选解决方案。相反，对于 DDS，最好使用 DDS 安全规范中定义的机制，这些机制与传输无关。 DDS 安全还提供了更细粒度的安全控制和一种访问控制语言，因此可以单独保护 DDS 域和主题，并区分对主题的读写权限。此外，由于 DDS 安全性与传输无关，因此它可以与任何传输一起使用，包括共享内存、多播或自定义应用程序定义的传输。
服务质量支持
SOME/IP 仅提供一个用于 select UDP 与 TCP 的“可靠性”Qos 设置。任何其他事情都必须使用自定义应用程序逻辑来实现，这取决于 QoS 策略，这可能非常困难。应用层代码也不是那么可移植，需要所有应用程序包含相同的代码或至少 link 一个通用的非标准库。
DDS 提供了许多 QoS 策略，使用户能够以声明方式指定发布者和订阅者之间如何交换信息。 DDS 标准定义了 20 多个独立的策略。这些策略不仅控制可靠性，还控制资源使用、数据优先级、数据可用性和故障转移等其他方面。例如，QoS 设置提供了建立 截止日期 的能力，以便在发布者或订阅者应用程序未能以特定速率发送或传递信息时提供通知；设置数据的 持久性 以便可以将其重新传输给在信息生成和发送后加入的订户应用程序；配置发布者和订阅者应用程序的历史深度；部署冗余系统，根据 所有权强度 自动 select 一个来源，配置自动 活跃度 消息以确定远程应用程序是否仍然可用存活并在应用程序无响应时执行自动故障转移。您可以从 DDS Specification or from the documentation of the different implementations (see for example this Qos Cheat-Sheet from RTI Connext DDS).
的第 2.2.3 节中获得更多详细信息使用其他规范
SOME/IP 主要由 AUTOSAR 用于汽车应用。
DDS有更多的横向用途。它通常直接用作连接框架。事实上，它被工业互联网联盟 (IIC) 确定为 IIoT 的“核心连接框架”之一（参见 Industrial Internet of Things Connectivity Framework 文档）。 它也被用作其他标准和框架的一部分，例如 OpenFMB, ROS2, MD PnP, FACE, and its is also being included into AUTOSAR Adaptive (starting in version 18.03).