自动驾驶中心件之二：通信中心件DDS与SOME/IP 谁主沉浮？_通讯_数据

会有哪些信息在模块之间共享？如何将这些信息发送编码到中？如何将从一个模块通报到另一个模块？如何在吸收到后解码？各个模块间的通信分别花了多永劫光？

在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中。

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

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的节点）以及工具链的角度来看，我们认为还是有待商榷的。
”