SOME/IP 和 DDS 均已被纳入AUTOSAR AP的平台标准中。
SOME/IP的全称为：Scalable service-Oriented MiddlewarE over IP，是一种面向服务的传输协议。
严格地说，SOME/IP不是一款特定的产品，而是一种技术标准。
其最早由宝马在2012-2013年开发，并在2014年集成进AUTOSAR 4.2.1中。
当前，全球最大的商用SOME/IP产品供应商是Vector。开源版的SOME/IP则是由Genivi协会来维护的。
DDS的全称为Data Distribution Service（数据分发服务)，是由OMG发布的分布式通信规范，采用发布/订阅模型，提供多种QoS服务质量策略，以保障数据实时、高效、灵活地分发，可满足各种分布式实时通信的应用需求。
DDS将分布式网络中传输的数据定义为“主题”，
将数据的产生和接收对象分别定义为“发布者”和“订阅者”，从而构成数据的发布/订阅传输模型。
各个节点在逻辑上无主从关系，点与点之间都是对等关系，通信方式可以是点对点、点对多、多对多等，在QoS的控制下建立连接，自动发现和配置网络参数。
DDS最早应用于美国海军，用于解决舰船复杂网络环境中大量软件升级的兼容性问题，后来扩展至航空、航天、船舶、国防、金融、通信、汽车等领域，包括作战系统、船舶导航和控制系统、船舶防御系统、无人机驾驶系统和地面控制系统、装甲车辆控制系统、仿真和培训系统、雷达处理和空中交通管理系统、金融系统等。
2018年，DDS首次被引进AUTOSAR AP，作为可选择的通信方式之一。
2018年3月，DDS的主要提供者RTI公司宣布，AUTOSAR AP的最新版本（版本18-03）已经具有DDS标准的完整网络绑定。
自动驾驶领域比较有影响力的开源DDS是由RTI原核心团队成员在欧洲创办的eProsima公司推出的FastDDS。
在eProsima将FastDDS的源代码开放出来后，用户可以直接在github上免费下载。
但FastDDS使用起来比较麻烦，这个时候，用户就需要通过向eProsima支付费用来取得支持。
OpenDDS 由位于圣路易斯和凤凰城的的Object Computing的 ACE/TAO 团队开发，它和FastDDS具有一定的相似性——两者都是基于RTPS实现的，面向数据的通信框架，遵循的是同一标准。这类框架的典型特征是去中心化，支持QoS机制，支持实时通信。通常会绑定如protobuf等序列化工具。
在许多情况下，FastDDS 、OpenDDS可以跟RTI的Connnext DDS互操作/通信。
当然，具体还得看场景。
比如开源DDS 的QoS（服务策略）有 23个，大家都用这23个QOS交互，那就能互操作；
如果Connext用的是超出这23个自定义范围的QoS，那么开源DDS就解析不了。
此外，如果用的是OMG没开源的DDS工具，那也没法互操作。
DDS VS Some/Ip
现阶段，SOME/IP 和 DDS是自动驾驶上用得最多的两类通信中间件。
共同点主要有：
都是面向服务的通信协议.
都采用了“以数据为中心”的发布和订阅模式.
对于数据吞吐量，从有效数据的占比来看，DDS和SOME/IP的性能没有明显的差别。
- 资源占有大小不同：
SOME/IP强调通信，体量比较小.
DDS功能更多，但体量比较大，需要裁剪后才能用于自动驾驶.
- 使用场景不同：
DDS是一套面向数据的访问系统，适合多节点、大数据交互的应用场景；
SOME/IP是一套面向服务的访问系统，可以很方便地用于RPC（远程过程调用）以及变更通知。
- 灵活性、可伸缩性不同：
相较于SOME/IP，DDS引入了大量的标准内置特性，例如基于内容和时间的过滤、与传输无关的可靠性、持久性、存活性、延迟/截至时间监视、可扩展类型等。
订阅方和发布方是否强耦合
服务策略不同
SOME/IP只有一个QoS，即可靠性的定义；
RTI DDS有50多个QoS、开源DDS里面分别有20多个QoS，这些QoS基本上能涵盖绝大多数可以预见到的智能驾驶场景。
DDS适用于自动驾驶域，而SOME/IP则可以延伸到整车域。
实际运用过程中，二者可以共存在一套系统中。
感觉原文作者是一个DDS的扈拥，字里行间都在贬低SOME/IP。所以，看看就好。
| SOME/IP | DDS | Notes | |
| 概念 | 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）。 | |
| 通讯方式 | 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实现之间进行切换。 | 译者案：这个说法不太客观。如果从IDL角度来谈的话，SOME/IP和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也可以通过TP-Message实现大数据广播。当然，可能DDS提供了更安全的策略？ |
| 安全 | 一般来说，SOME/IP还依赖于传输来保证安全性。 因此，要安全使用它，就必须在TLS或DTLS上运行。 | 也可以在TLS或DTLS上作为传输运行DDS，但这不是首选的解决方案。 相反，对于DDS，最好使用DDS安全规范中定义的与传输无关的机制。 DDS安全性还提供了对安全性的更细粒度的控制以及一种用于进行访问控制的语言，因此可以分别保护DDS域和主题，并区分对主题的读写权限。 而且，由于DDS安全性与传输无关，因此可以与任何传输一起使用，包括共享内存，多播或自定义应用程序定义的传输。 | |
| QoS支持 | SOME/IP仅提供一种用于选择UDP与TCP的“可靠性” QoS设置。 其他任何事情都必须使用自定义应用程序逻辑来实现，而这取决于QoS策略，这可能非常困难。 而且，应用程序层代码不是那么可移植的，并且要求所有应用程序都包含相同的代码，或者至少链接公共的非标准库。 | DDS提供了许多QoS策略，使用户可以声明性地指定发布者和订阅者之间如何交换信息。 DDS标准定义了20多个单独的策略。这些策略不仅控制可靠性，还控制其他方面，例如资源使用，数据优先级，数据可用性和故障转移。例如，QoS设置可以确定发布者或订阅者应用程序未能以特定速率发送或传递信息时提供通知的截止日期的功能；设置数据的持久性，以便可以将其重新发送给在生成和发送信息之后加入的订户应用程序；配置发布者和订阅者应用程序的历史深度；部署冗余系统，该系统根据所有权强度自动在众多资源中选择一种来源，配置自动实时消息，以确定远程应用程序是否仍然有效，并在应用程序无响应时执行自动故障转移。您可以从DDS规范的2.2.3节或其他实现的文档中获得更多详细信息（例如，请参见此来自RTI Connext DDS的Qos速查表。 | |
| 在其他需求中使用 | SOME/IP主要被AUTOSAR应用于车载应用领域。 | DDS具有更横向的用途。 它通常直接用作连接框架。 实际上，它已被工业互联网联盟（IIC）确定为IIoT的“核心连接框架”之一（请参阅工业物联网连接框架 文件）。 它也被用作其他标准和框架的一部分，例如OpenFMB、ROS2， MD PnP，FACE，并且它也被包含在AUTOSAR Adaptive（从版本18.03开始）。 |
