SOME / IP是一种汽车中间件解决方案，可用于控制消息。 DDS还是用于通信的汽车中间件。 我想知道它们之间有什么区别？ 而且，为什么以及何时应该选择其中之一？
答案 0 :(得分：11)
SOME / IP和DDS都允许分布式应用程序使用发布/订阅模式和服务请求/回复模式（RPC）进行通信。但是也存在重大差异。
SOME / IP专为汽车行业设计。 SOME / IP是作为AUTOSAR的一部分开发的一系列规范，描述了其序列化协议，服务发现和用于与Classic集成的变压器 AUTOSAR。
DDS（数据分发服务）的目标是更广泛的工业物联网领域。它是对象管理小组（OMG）发布的一系列开放标准。它是专为分布式实时系统而设计的，并且在many industries中使用，包括交通，能源，医疗系统，工业自动化，航空航天和国防等。商业和开源都有许多独立的实现。 DDS系列的第一个规范于2004年发布，此后已发展为12 DDS standards的集合，其中包括标准的电线协议（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）。
从技术上和概念上来说，都有很多差异，因此我将它们分为不同的类别：
SOME / IP可以看作是基于对象的面向服务的体系结构。信息通过实例化服务对象提供给系统，客户端应用程序可以访问这些信息，而客户端应用程序会为其要访问的每个服务实例实例化相应的“代理”对象。客户端应用程序通过将代理对象附加到服务对象并使用它来监视事件和字段更改来订阅信息。他们还可以在服务对象上调用操作以执行远程过程调用或读取/写入特定字段。
DDS从根本上提供了一个分离的，以数据为中心的发布订阅模型。 Aso称为“数据总线”模式。应用程序参与对等的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引入了对大于1400字节的UDP载荷进行分段的支持。为了进行可靠的通信，SOME / IP会退回到TCP。
DDS使用一种称为RTPS（实时发布订阅）的有线协议，该协议在独立于平台的模型中定义，可以映射到不同的网络传输协议。大多数DDS（DDS-RTPS）实现至少支持UDP，TCP和共享内存。 RTPS实现了与传输无关的可靠性和分段协议，该协议可在任何传输之上运行，包括带有多播的UDP。因此，使用DDS，可以通过多播UDP处理大数据和可靠数据。 SOME / IP无法做到这一点。
许多DDS实现都提供“自定义传输” SDK，因此可以在不牺牲任何功能和QoS的情况下通过自己的自定义传输运行DDS。对于SOME / IP，这是不可能的，因为某些功能（如可靠性和分段性）必须由传输器实现。
通常来说，SOME / IP还依赖于传输来确保安全性。因此，要安全使用它，就必须在TLS或DTLS上运行。
也可以通过TLS或DTLS在传输上运行DDS，但这不是首选的解决方案。相反，对于DDS，最好使用DDS安全规范中定义的与传输无关的机制。 DDS安全性还提供了对安全性的更细粒度的控制以及一种用于进行访问控制的语言，因此可以分别保护DDS域和主题，并区分对主题的读写权限。而且，由于DDS安全性与传输无关，因此可以与任何传输一起使用，包括共享内存，多播或自定义应用程序定义的传输。
SOME / IP仅提供一种“可靠性” Qos设置，用于选择UDP与TCP。其他任何事情都必须使用自定义应用程序逻辑来实现，而这取决于QoS策略可能非常困难。而且，应用程序层代码不是那么可移植，并且要求所有应用程序都包含相同的代码，或者至少链接公共的非标准库。
DDS提供了许多QoS策略，使用户可以声明性地指定发布者和订阅者之间如何交换信息。 DDS标准定义了20多个单独的策略。这些策略不仅控制可靠性，还控制其他方面，例如资源使用，数据优先级，数据可用性和故障转移。例如，QoS设置提供了建立最后期限的功能，以在发布者或订阅者应用程序无法以特定速率发送或传递信息时提供通知；设置数据的耐久性，以便可以将其重新传输给在生成和发送信息后加入的订户应用程序；配置发布者和订阅者应用程序的历史深度；部署冗余系统，该系统根据所有权强度自动从众多资源中选择一种来源，配置自动 liveliness 消息以确定远程应用程序是否仍然有效并执行自动故障转移当应用程序没有响应时。您可以从DDS Specification的2.2.3节或其他实现的文档中获得更多详细信息（例如，请参见此Qos Cheat-Sheet from RTI Connext DDS）。
SOME / IP主要由AUTOSAR用于汽车应用。
DDS具有更横向的用途。它通常直接用作连接框架。实际上，它已被工业互联网联盟（IIC）确定为IIoT的“核心连接框架”之一（请参阅Industrial Internet of Things Connectivity Framework文档）。 它也用作其他标准和框架的一部分，例如OpenFMB，ROS2，MD PnP，FACE，并且它也包含在AUTOSAR Adaptive (starting in version 18.03)中。