1 SOME/IP 和 DDS是在不同的应用场景和不同的需求下诞生的技术，所以它们之间注定有很大的区别。

SOME/IP 和 DDS 均已被纳入AUTOSAR AP的平台标准中。

SOME/IP

SOME/IP的全称为：Scalable service-Oriented MiddlewarE over IP，是一种面向服务的传输协议。

严格地说，SOME/IP不是一款特定的产品，而是一种技术标准。

其最早由宝马在2012-2013年开发，并在2014年集成进AUTOSAR 4.2.1中。

当前，全球最大的商用SOME/IP产品供应商是Vector。开源版的SOME/IP则是由Genivi协会来维护的。

DDS

DDS的全称为Data Distribution Service（数据分发服务)，是由OMG发布的分布式通信规范，采用发布/订阅模型，提供多种QoS服务质量策略，以保障数据实时、高效、灵活地分发，可满足各种分布式实时通信的应用需求。

DDS将分布式网络中传输的数据定义为“主题”，

将数据的产生和接收对象分别定义为“发布者”和“订阅者”，从而构成数据的发布/订阅传输模型。

各个节点在逻辑上无主从关系，点与点之间都是对等关系，通信方式可以是点对点、点对多、多对多等，在QoS的控制下建立连接，自动发现和配置网络参数。

DDS最早应用于美国海军，用于解决舰船复杂网络环境中大量软件升级的兼容性问题，后来扩展至航空、航天、船舶、国防、金融、通信、汽车等领域，包括作战系统、船舶导航和控制系统、船舶防御系统、无人机驾驶系统和地面控制系统、装甲车辆控制系统、仿真和培训系统、雷达处理和空中交通管理系统、金融系统等。

2018年，DDS首次被引进AUTOSAR AP，作为可选择的通信方式之一。

2018年3月，DDS的主要提供者RTI公司宣布，AUTOSAR AP的最新版本（版本18-03）已经具有DDS标准的完整网络绑定。

2 DDS和someip在arxml建模的区别？

SOME/IP 是一种汽车中间件解决方案，可用于控制消息。SOME/IP 专为汽车行业设计。

SOME/IP 是作为 AUTOSAR 的一部分开发的规范集合，描述了其序列化协议、服务发现以及与 Classic AUTOSAR 集成的转换器。

DDS（数据分发服务） 也是用于通信的汽车中间件，针对更广泛的工业物联网领域。它是由对象管理组 (OMG) 发布的一系列开放标准。

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

1）通信模式不同

DDS 和 SOME/IP 之间的一个显着区别在于:

使用 DDS，应用程序不需要绑定到服务的特定实现。它简单地引用主题和服务，并且可以完全透明地进行一对一或一对多的通信，而无需对应用程序代码进行任何更改。

它确实需要跟踪单独对等点的存在或管理任何新对象以响应对等点的加入或离开。

这一切都是自动处理的。从这个意义上说，它比 SOME/IP 更具动态性。

2）应用程序编程接口（API）

SOME/IP 没有定义标准 API，实现通常提供 C++ API，但它们不能跨实现移植。

DDS 具有适用于多种语言的标准 API。对于 C++ 和 Java，这些都包含在 DDS-PSM-JAVA 和 DDS-PSM-CXX 规范中。因此，通常可以移植 DDS 应用程序并在 DDS 实现之间切换。

3）网络传输

SOME/IP 支持 UDP 和 TCP 进行数据传输。对于可靠的通信，SOME/IP 回退到 TCP。

使用 DDS支持RTPS（实时发布订阅）的有线协议，实现了与传输无关的可靠性和分段协议，该协议运行在任何传输之上，包括带有多播的 UDP。可以通过多播 UDP 处理大数据和可靠数据。Some/IP 无法做到这一点。

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

4）信息安全能力不同

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

对于 DDS，最好使用 DDS 安全规范中定义的机制，这些机制与传输无关。

DDS 安全性还提供了对安全性的更细粒度的控制以及用于访问控制的语言，因此可以分别保护 DDS 域和主题，并区分对主题的读取和写入权限。此外，由于 DDS 安全性与传输无关，因此它可以与任何传输一起使用，包括共享内存、多播或自定义应用程序定义的传输。

5）服务质量实现不同

SOME/IP 仅提供一种用于选择 UDP 与 TCP 的“可靠性”Qos 设置。

DDS 提供了许多 QoS 策略，使用户能够以声明方式指定发布者和订阅者之间如何交换信息。我们开发SOA的服务架构中，通常dds通常重点在于传输数据类通信（比如传感器数据），SOMEIP更多是传输控制类信号通信（如加减速控制信号、车门车窗控制信号）。

小结

本文就基于SomeIp协议开发过程中可能出现的典型问题进行了比较详细的分析和解读，可以帮助读者或工程实践者进行部分问题规避，但是SomeIp协议的复杂度和可能出现的踩坑远不止于此，比如由于当前的 SOME/IP 协议不提供任何安全措施，如何提升Someip的信息安全能力，免受黑客攻击，就是业内比较关注的话题。协议制定过程中如果能够保留56 字节用户数据明确用于可能的安全扩展。只要安全协议每帧传输的附加数据不超过这 56 个字节，就可以在不更改标准和兼容实现的情况下保护 SOME/IP 通信。这一系列操作都有助于对Someip的能力扩展，当然这里无法穷举，希望后续可以通过抛砖引玉的方式在后续开发过程中获得更多的输入。

OpenDDS 和 FastDDS

自动驾驶领域比较有影响力的开源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中，在正常数据传输前，client需要与server建立网络连接并询问server是否提供所需服务，在这个层面上，节点间仍然具有一定耦合性。服务的订阅方需要知道server在哪里，服务的发布方需要告知server提供哪种服务；
•     在DDS标准下，每个订阅方或发布方只需要在自己的程序里面订阅或发布传感器数据就行了，不需要关心任何连接。可以理解为，在DDS中，服务订阅方和发布方的解耦更加彻底，需要什么数据，写一行代码就行了，不需要再去做绑定。

    服务策略不同
    SOME/IP只有一个QoS，即可靠性的定义；
    RTI DDS有50多个QoS、开源DDS里面分别有20多个QoS，这些QoS基本上能涵盖绝大多数可以预见到的智能驾驶场景。

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开始）。

 自动驾驶中间件之二：通信中间件，DDS与SOME/IP 谁主沉浮？ - 知乎 (zhihu.com)https://zhuanlan.zhihu.com/p/488457744

随着传感器的数量越来越多，数据来源越来越多、规模也会越来越大，那这些多源异构数据如何在芯片之间、在各任务进程之间高效、稳定地传递，确保“在正确的时间，传递正确的数据，并确保数据抵达正确的地点”呢？

会有哪些信息在模块之间共享？如何将这些信息发送编码到消息中？如何将消息从一个模块传递到另一个模块？如何在接收到消息后解码？各个模块间的通信分别花了多长时间？

在OTA的时候，进程如何不被打断？

这些问题，都需要通过“通信中间件”来解决。在自动驾驶领域，中间件的功能涉及到通信、模块升级、任务调度、执行管理，但其最主要的功能还是通信。当前市场上，无论是Cyber RT还是 ROS，基本上90%的功能就是通信，狭义上说它们就是通信中间件（又被称为“消息中间件”）。

那么，好的通信中间件应当具备哪些特征？通信中间件可分为哪些类型？常见的SOME/IP和DDS的优劣势各是什么？市场格局将会如何演变？接下来，我们将对这些内容做个简单的梳理。

一．自动驾驶需要怎样的通信中间件？

传统的网络通信中，在TCP协议下，信息发出后，接收方需要发出一个信号，告诉发送方“我收到了” ，如果没收到这个信号，那下一条信息就不能发出；在UDP传输方式下，不管接收方有没有收到，发送方都会一直发。

以往，在没有用通信中间件的时候，为了开发上层应用，开发者们需要自己去定义数据的格式、定义数据的发送方和接收方；但有了SOME/IP和DDS这种“以服务/数据为中心”的发布和订阅模式，开发者们只需明确我需要什么样的数据、数据传到哪儿，而无需知道数据是由谁发出的、怎样发出的。

以数据为中心，是相对于传统的“以消息为中心”而言的，其本质区别在于通信中间件知道它存储了什么数据、并能控制如何共享这些数据。

对传统的以消息为中心的中间件，程序员必须为发送消息编写代码，而对以数据为中心的中间件，程序员只需为如何及何时共享数据编写代码，然后就可以直接共享数据值。

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

点到点模式具有很强的时间和空间耦合性，使得通信灵活性受到很大限制；消息队列模式通过一个消息队列来传递消息，解决了通信双方时间和空间松耦合的问题，但不能实现消息消费者通信的异步，并且还存在服务器瓶颈和单点失效的问题，可靠性得不到保障；发布/订阅模型中，发布者和订阅者通过主题相关联，双方不必知道对方在何处，也不必同时在线，实现了通信双方在时间、空间和数据通信上的多维松耦合。

此外，相比于面向信号的CAN，DDS和SOME/IP都是面向服务的通信协议。两者的区别在于：面向信号的数据传输，不管网络需不需要，它始终会不断循环发送；而面向服务的通信方式则不同，仅当客户端请求或服务器通知特定订阅者时，才在客户端-服务器配置中交换数据，这就确保了永远不会浪费带宽，并且仅在需要的时间和地点进行数据通信/交换。

因此，面向服务的通信协议，能够大大减少网络负载，提高通信效率。

上汽工程师殷玮在一篇文章中说，通信中间件的引入整体上可以帮助开发人员提高工作效率。

SOME/IP和DDS均已被纳入AUTOSAR AP的平台标准中。

创景信息科技公司在官方微信公众号上的一篇文章中说道：“撇开商业利益不谈，从工程角度来看，将AUTOSAR和DDS结合起来的最大优势是功能域和网络拓扑不再是对手，而是车辆中的盟友。网络拓扑结构能够更好地适应车辆的物理约束，而功能域可以在物理车辆的顶部提供了一个灵活的覆盖层。”

通信中间件应该包括以下几个模块:数据类型规范语言、消息传递系统、日志/回放工具和实时分析工具。这些模块应具有如下特征：1.数据类型规范语言应独立于平台和具体的编程语言，以消除用户实现编组（Marshalling）代码的需要，同时保证运行时类型的安全性；2.消息传递系统需要在不同的进程之间传输消息，并提供低延时的消息传递功能，且消除对中央通信的依赖，从而使混合模拟、记录和实时数据源的工作更容易；3.需要提供大量的日志记录、回放和流量检查工具，以简化常见的开发和调试任务。

衡量一款通信中间件好坏的标准主要有如下几点：1.接口是否方便？接口方便是很多人喜欢用ros的原因。2.是否安全、稳定？安全，即通信的过程中不能出现数据丢失的问题；稳定，比如，发布订阅的进程连续开几天几夜也不能宕机。3.传输可支持多少节点、跨多少内核？4.在不同通信场景和通信需求下，是否可以进行灵活快速的配置？5.吞吐量、时延。发送同样大小的数据包，吞吐量是否更高，延迟是不是比用别的方法更低？

吞吐量，即单位时间内通过的数据量有多少；时延，即数据包传输的延迟性有多少。如果通信速度很慢，感知到的信息要经过200毫秒才能传递到执行系统，那感知做得再好也无济于事。

车速越高、数据量越大的场景，对中间件的数据吞吐能力和时延的要求就越高。某通信中间件厂商反应，他们的产品在乘用车市场上卖得特别好，但在商用车市场上反响就不行，一个原因就是商用车的驾驶场景简单，对中间件数据吞吐能力、时延的要求比较低。

二．常见的通信中间件

根据源代码是否开放，通信中间件可简单地分为闭源和开源两种。闭源的通信中间件主要有Vector公司的SOME/IP、RTI公司的DDS等;开源的通信中间件主要有OPEN DDS、FAST DDS、Cyclone DDS等。

下面，我们将对这几类通信中间件做个简单的介绍。

01 SOME/IP

SOME/IP的全称为：Scalable service-Oriented MiddlewarE over IP，是一种面向服务的传输协议。严格地说，SOME/IP不是一款特定的产品，而是一种技术标准。其最早由宝马在2012-2013年开发，并在2014年集成进AUTOSAR 4.2.1中。

02 DDS（Data Distribution Service）

提起DDS，就不得不提OMG组织。OMG是一个国际化的、开放的、非盈利的计算机行业标准协会，很多大家熟悉的标准(如uml)，都出自于OMG。DDS也是OMG组织推出的标准之一。

（图片来自创景信息科技公司）

DDS的全称为Data Distribution Service（数据分发服务)，是由OMG发布的分布式通信规范，采用发布/订阅模型，提供多种QoS服务质量策略，以保障数据实时、高效、灵活地分发，可满足各种分布式实时通信的应用需求。

DDS将分布式网络中传输的数据定义为“主题”，将数据的产生和接收对象分别定义为“发布者”和“订阅者”，从而构成数据的发布/订阅传输模型。各个节点在逻辑上无主从关系，点与点之间都是对等关系，通信方式可以是点对点、点对多、多对多等，在QoS的控制下建立连接，自动发现和配置网络参数。

DDS最早应用于美国海军，用于解决舰船复杂网络环境中大量软件升级的兼容性问题，后来扩展至航空、航天、船舶、国防、金融、通信、汽车等领域，包括作战系统、船舶导航和控制系统、船舶防御系统、无人机驾驶系统和地面控制系统、装甲车辆控制系统、仿真和培训系统、雷达处理和空中交通管理系统、金融系统等。

2018年，DDS首次被引进AUTOSAR AP，作为可选择的通信方式之一。2018年3月，DDS的主要提供者RTI公司宣布，AUTOSAR AP的最新版本（版本18-03）已经具有DDS标准的完整网络绑定。

ROS 2和Cyber RT的底层都使用了开源的DDS，将DDS作为最重要的通信机制。与此相对应的是，Xaver、Orin等面向自动驾驶的SOC芯片上也都预留了DDS接口。

AUTOSAR CP的标准规范中是不支持DDS的，但做一些变通后，也可以在CP上集成DDS。

全球范围内，DDS市场份额最大的供应商（80%左右）的是成立于1991年的美国RTI公司（全称为Real-Time Innovations）。RTI作为OMG组织董事会的成员，主导了DDS标准的制定，从2004年开始负责主持DDS工作组的工作，目前已经成为这个行业的领导者，对DDS标准有足够的权威。

RTI开发的DDS品牌名为Connext,，因此又被称为Connext DDS。

03

开源DDS：FAST DDS与OPEN DDS

开源DDS，主要是相对于商用的RTI Connext DDS等而言的，其也是根据OMG官方标准开发的，但源代码开放。

在自动驾驶领域比较有影响力的开源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工具，那也没法互操作。

国内某中间件厂商负责人介绍，出于成本的考量，英伟达的Xavier自带的Driver.OS中便采用了FastDDS或OpenDDS这样的开源DDS。

RTI方面认为，开源DDS是其最大的竞争对手。

当然了，开源DDS的使用门槛也很高。比如，RTI DDS的服务策略有50多个，但开源DDS的服务策略只有23个，完整程度远不及前者。此外RTI的DDS已经通过了ASIL-D的认证，但开源DDS还没有。

而据华玉通软联合创始人毕晓鹏的解释，基于开源版本DDS研发的通信中间件存在“稳定性不足”的问题。

04 MQTT（开源）

MQTT是由IBM开发的即时通讯协议，其全称是Message Queuing Telemetry Transport （消息队列遥测传输）。MQTT协议也采用发布/订阅模式，所有的物联网终端都通过TCP连接到云端，云端通过主题的方式管理各个设备关注的通讯内容，负责将设备与设备之间消息的转发。

由于延时控制等方面功能较差、服务策略也比较少，MQTT不适用于高速项目和大型项目，但可用于低带宽、不可靠的网络场景，提供基于云平台的远程设备的数据传输和监控。在自动驾驶领域，MQTT比较典型的应用场景是V2X。

此外，MQTT在低速车领域也同样适用。它体积极小，并能提供简单的QoS保证，非常适合玩具车，扫地车等功能简单、硬件资源有限的项目。

MQTT也是开源的通信中间件。

三．SOME/IP & DDS

现阶段，SOME/IP和DDS是自动驾驶上用得最多的两类通信中间件。上文已经提到，两者的共同点主要有：都是面向服务的通信协议；都采用了“以数据为中心”的发布和订阅模式。那么，两者的主要区别又有哪些呢？

01 应用场景不同

SOME/IP是专为汽车领域而生的，它针对汽车领域的需求，定义了一套通信标准，并且，在汽车领域深耕的时间比较长；

DDS是一个工业级别的强实时的通信标准，它对场景的适应性比较强，但在用于汽车/自动驾驶领域时需要做专门的裁剪。

02 灵活性、可伸缩性不同

相较于SOME/IP，DDS引入了大量的标准内置特性，例如基于内容和时间的过滤、与传输无关的可靠性、持久性、存活性、延迟/截至时间监视、可扩展类型等。

当AUTOSAR AP与DDS一起构建一个通信框架时，该框架不仅可以与现有ara::com api及应用程序兼容，而且在可靠性、性能、灵活性和可伸缩性等方面，都可以提供重要的好处。

03 订阅方和发布方是否强耦合

在SOME/IP中，在正常数据传输前，client需要与server建立网络连接并询问server是否提供所需服务，在这个层面上，节点间仍然具有一定耦合性。

服务的订阅方需要知道server在哪里，服务的发布方需要告知server提供哪种服务，例如写一个程序，需要用到传感器数据，这个程序要去询问server是否可以提供传感器数据；

而在DDS标准下，每个订阅方或发布方只需要在自己的程序里面订阅或发布传感器数据就行了，不需要关心任何连接。

可以理解为，在DDS中，服务订阅方和发布方的解耦更加彻底，需要什么数据，写一行代码就行了，不需要再去做绑定。

04 服务策略不同

较好的QoS（服务策略）是DDS标准相比于SOME/IP最重要的特征。

SOME/IP只有一个QoS，即可靠性的定义；而RTI DDS和开源DDS里面分别有50多个和20多个QoS，这些QoS基本上能涵盖绝大多数可以预见到的智能驾驶场景。

QoS具体是个什么东西，它有何用途？举了几个例子：

（1）通信中的传输优先级、数据可靠性、资源限制、时间过滤等，都需要在QoS里面设置。

（2）数据传输过程中可能会出现丢帧现象，也就是说，不是每一帧都能达到接收端。针对这种现象，我们需要考虑场景需求。如果是关键信息（报警指令），我们需要发送方重发，如果是非关键信息（高频传感数据），系统就不必把丢失的部分都找回来，这些都只需配置QoS的reliability就可以了。

（3）在感知系统有冗余的情况下，一旦一个传感器宕机，就需要第二个传感器补上来。针对这种情况，QoS可以配置一个ownership，对两个传感器的数据做优先级高低的区分。配置之后也不需要重新编译，因为它是动态部署的，配置完之后就可以按照最新配置运行，去完成不同节点之间的发布订阅。

（4）DDS的解耦模式允许某一主题发布方在没有订阅方的情况下仍然发布数据，但后加入的订阅方也许对这一主题的历史记录感兴趣。例如，新节点上线后需要去监控其他节点的运行情况，这些节点也许每隔较长一段时间才发布一个信息说自己“运行正常”，那么这个新上线的节点就需要去了解其他节点发布的历史信息以确定其运行状态，也就是它希望能收到其上线之前其他节点发布的历史数据。这种情况，只需要简单配置QoS就可以实现，新节点可以获知上线之前多长时间、多长节点的数据流，去关注它的历史数据等等。

（5）负责监控的新节点上线后，需要去监控其他节点的运行情况。通常，这些节点每个小时发布一个信息说自己“运行正常”，但也有可能这个“运行正常”的节点先发布了，过半小时之后监控节点才发布，那这时候，监控节点是否还能收到其上线之前其他节点发布的数据？这种情况，也是需要通过QoS去配置的，QoS可以去配置订阅新节点上线之前多长时间、多长节点的数据流，去关注它的历史数据等等。

进一步说，QoS能够提供实时系统所要求的性能、可预测性和资源可控性，并且能够保证发布/订阅模型的模块性、可量测性和鲁棒性等。因此，DDS能够满足非常复杂、非常灵活的数据流要求。

相比之下，SOME/IP只解决了发布订阅问题，但由于没有这些QoS，结果便是，很多本来可用自动配置服务策略来实现的功能，都需要通过软件开发人员写代码才能实现，这会浪费大量的时间。

此外，由于没有QoS，SOME/IP在数据量大的时候，无法解决丢包的问题，进而造成指令被卡在某个地方发不出去，然后，整个系统就无法正常运作了。

05 应用场景不同

从应用场景的角度来看，SOME/IP比较偏向于车载网络，且只能在基于网络层为IP类型的网络环境中使用，而DDS在传输方式上没有特别的限制，对基于非IP类型的网络，如共享内存、跨核通讯、PCI-e等网络类型都可以支持。而且，DDS也有完备性的车联网解决方案，其独有的DDS Security，DDS Web功能可为用户提供车-云-移动端一站式的解决方案。

在商业落地中，DDS和SOME/IP是直接竞争关系。据一位RIT方面的代表透露,对用户而言，DDS和SOME/IP是“二选一”。但毕晓鹏及东软睿驰营销总经理茅海燕、均联智行首席架构师汪浩伟等均认为，DDS和SOME/IP尽管有很强的竞争关系，但也是可以共存的。

毕晓鹏说，有的OEM既用了DDS，也用了SOME/IP，只是使用的场景不一样——有时候是在一个核上的进程之间进行通信，有时候是核与核之间进行通信，有的时候是域控制器和其他的车载娱乐系统进行通信等等。“现在确实并不是非要‘二选一’，针对有的场景选择DDS，针对另一些场景选择SOME/IP，也是可以的。”

茅海燕说，AP AUTOSAR中，CM提供的一些标准框架可同时兼容DDS和SOME/IP。 “SOME/IP和DDS我们都用过。总体而言，SOME/IP强调通信，体量比较小；DDS功能更多，但体量比较大，需要裁剪后才能用于自动驾驶。”

汪浩伟指出，DDS适用于自动驾驶域，而SOME/IP则可以延伸到整车域。

Vector产品专家蔡守群说：“在我们接触过的一些项目上，DDS和SOME/IP都有用到。”蔡守群甚至认为，DDS跟SOME/IP不是竞争关系，存在即合理，用户可以按需选择。

那么，在实践中，谁的市场占有率更高？

毕晓鹏说：“由于SOME/IP本身就是为汽车行业制定的通信标准，因此，SOME/IP在之前的使用率会稍微高一些，DDS也是近两年才慢慢被多家的造车新势力和OEM所采纳。但从趋势来看，未来，DDS的市场占有率是要大于SOME/IP的。”

当然，“DDS优于SOME/IP”主要是DDS厂商的说法，为避免本文观点被厂商们的立场左右，笔者又带着这些质疑向Vector蔡守群求证。对此，蔡守群的解答如下——

“现在很多人说DDS优于SOME/IP，很大程度上是从功能丰富性的角度去考虑的。确实，DDS包含的功能是多于SOME/IP的，但仅仅因为这个原因就说DDS优于SOME/IP是不合适的。这就如同拿一部车去跟一个发动机进行对比一样：

SOME/IP是AUTOSAR CP的产物， AUTOSAR的设计原则就是将功能模块化，通过提高模块颗粒度的方式来实现模块的高度可复用性；然后再通过不断复用、不断测试的方式来提高模块的质量，因此，SOME/IP产生之初就没考虑要不断增加功能。比如，跟SOME/IP结合使用的SD就是一个单独的模块。

相比之下，DDS额外提供的QoS，在AUTOSAR CP中是基于VLAN实现在以太网控制器驱动中的；数据则保存在AUTOSAR中有单独的存储管理模块；Security在AUTOSAR中也有对应的通信安全和加密管理模块。

“DDS厂商们认为，相比于SOME/IP，DDS除了提供了一个通信协议之外，还有其他可用的功能。但实际上，这些功能无论在CP还是在AP中，是有其他功能模块进行补充的，可以基于系统需求进行选择部署的，SOME/IP也只是CP/AP中一部分。

“另一方面，DDS丰富的功能必然导致它需要占用更多的资源。在车载MCU领域，资源是一个非常敏感的话题，要在MCU（包括SoC芯片的实时性内核）中运行DDS，只能人为地进行项目级功能裁剪，很难做到跨项目、跨平台的复用，因而很难做到成熟的产品化；并且，开发阶段的工程化裁剪以及后续的测试都会大幅度增加项目成本。

“当然，这也只是我个人看到的当前状况，不知道商业版的DDS是否已经在考虑进行DDS内部的功能模块化、工具可配置化，以弥补这方面的不足。（九章智驾在向RTI代理商创景科技方面求证后得到的反馈是：从我们目前已量产应用的项目来看，有多位客户在多代含MCU的产品中都部署了DDS，DDS在复用性方面并未出现“不成熟”的问题。）

“此外，DDS还有一个问题就是当前还无法完美接入进现有的车载电子电气设计、开发、测试工具链中。虽然说我们已经着手在设计（PREEvision）、测试（CANoe）中去支持DDS，但这方面的工作也才刚刚开始，双方的工具都需要不断测试磨合，短期内是做不到无缝兼容的。

“从协议上看，DDS是一套面向数据的访问系统，适合多节点、大数据交互的应用场景；SOME/IP是一套面向服务的访问系统，可以很方便地用于RPC（远程过程调用）以及变更通知。对于数据吞吐量，从有效数据的占比来看，DDS和SOME/IP的性能没有明显的差别。

“所以，我一直认为DDS和SOME/IP是会并存于车载通信中的，APP可以基于应用场景选择合适的通信通道。这也是为什么在AUTOSAR AP中是既支持DDS又支持SOME/IP的。

“我们也知道，目前确实有一些OEM在考虑用DDS充当唯一的主干网（中央计算平台+方位域控制器）通信协议，但是从成熟度、资源占用（主干网上肯定有基于MCU的节点）以及工具链的角度来看，我们认为还是有待商榷的。”

参考资料：

面向服务架构的中间件方案

https://zhuanlan.zhihu.com/p/43