自动驾驶技术栈——DDS分布式通信协议

DDS(Data Distribution Service)是一种以数据为中心的分布式通信协议，由OMG(Object Management Group)发布，最早应用在美国海军舰艇，后来在物联网场景中大量使用，最近由于自动驾驶技术的兴起，在车载软件的通信中间件开发中也使用了DDS。
DDS协议大致流程如下图所示：

*DDS采用的通信方式是多对多的单向数据交互，通信模型为分布式结构，没有中心节点，同一个数据空间任何两个节点之间都能直接通信。

Domain：
通信时的全域数据空间，由Domain ID唯一标识，只有处在相同空间内的通信实体才能相互通信。
DomainParticipant：
数据空间内的通信实体。
Topic
：
主题，可以理解成通信数据的载体，
主题将
相互
通信的发布者/订阅者
进行了关联。
Qos：
Quality of Service，使通信过程变得可靠。
Publisher：
发布者，发布主题数据。包含至少一个DataWriter。
Subscriber：
订阅者，订阅主题数据。包含至少一个DataReader。
DataWriter：
数据写入者，把需要发布的数据写入到主题。
DataReader：
数据读取者，从订阅的主题得到数据。

中间件是位于操作系统平台和应用程序之间的软件层，它屏蔽了一些通信协议的细节，使组件之间通信模块的代码逻辑变得更简洁。

通信中间件采用的模型一共经历过四代演变：

（1）点对点模型：
常见的服务器/客户端(Client/Server)模式。通信时，服务器和客户端直接连接，导致服务器和客户端的耦合程度过高，且服务器的异常会直接影响到客户端。
（2）Broker模型：
由Broker集中统一处理所有请求，解决了通信双方的耦合问题，当服务器地址发生变化时，客户端不受影响。但是一旦Broker出现异常，会影响整个系统，且当请求规模达到一定程度，会因为Broker处理速度慢而影响整体的性能，可靠性很低。
（3）广播模型：
通信双方不用单独连接，而是借助于一种总线——广播信道。只需借助广播信道发送和接收信号。由于所有的通信实体都可以从广播信道接收所有的信号，而无论该实体是否需要这个信号，这样会浪费传输带宽。
（4）以数据为中心的模型：
与广播模型类似，所有通信实体都可以往“总线”发布和订阅消息，但是这个“总线”根据数据不同划分了很多数据空间，每个通信实体在数据空间内只收到和自己关联的信号。

通信架构如图，以RTI Connext DDS官网提供的素材为例，在巧克力工厂中，可能有一个传感器可以测量和发布调温机的当前温度。其他应用程序则通过订阅标题为 “ChocolateTemperature”的Topic来获得调温机的温度，而不需要关注“ChocolateLoteState”。

虽然DDS定义了应用层接口和以数据为中心的发布订阅模式，但是它的通信机制不包含网络传输的定义。
DDS在网络传输层的数据通信上需要借助RTPS协议。RTPS协议还可以允许不同的DDS模块之间进行交互。

DDS域和RTPS域的交互方式如图

DDS实体与RTPS实体的交互关系如图

IDL是一种描述性语言，类似于XML，以独立于编程语言/操作系统/处理器平台的方式来定义用于交互的数据类型和接口。
IDL通常用于RPC(Remote Procedure Call远程过程调用)软件，此处用于定义DDS发送和接收的数据格式，以及生成发布者/订阅者的代码。

DDS通信协议配合使用IDL语言的大致开发流程如下： 

1.确定业务场景对应的Topic需要用哪些字段。
2.将主题用到的字段在IDL文件中定义。
3.借助开源的DDS编译工具，编译用于生成C++语言或Java语言的IDL文件，获得发布者/订阅者对应的头文件和源代码。
4.将发布者/订阅者的模块代码进行改造并嵌入到项目工程文件中进行通信。

*常见开源的DDS框架：FastDDS，CycloneDDS

参考阅读：