前 言:

DDS作为一个在国防，航天，工控等安全性要求非常高的行业非常成熟的实时分布式通讯协议。个人一直认为其应该是在汽车行业能够有大规模的应用，特别是在以太网为主的EE架构下。

我想通过本文介绍DDS在AP AUTOSAR的集成和使用。至少，这绝对是SOME/IP的最好替换品。另外，网上讲在AUTOSAR中使用SOME/IP通讯协议比较常见。本文目的在于解析在AP AUTOSAR中使用DDS通讯协议。

注意

阅读本文需要对DDS和AP AUTOSAR ara::com (Communication Management)有基本的了解。这里只附带了最基本的DDS和ara::com简介方便理解本文。

背景知识

DDS是一个以数据为中心的通讯中间件。

以数据中心的模型 （来源：www.dds-foundation.org）

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

DDS和SOME/IP比较

和DDS类似，SOME/IP的协议栈也能算做通讯中间件。在AUTOSAR分层架构中的位置也一样，在Network Binding之下，网络协议栈之上。

SOME/IP只用在汽车行业，而DDS已经在其他对通讯的实时性，QoS质量要求的高的行业也有大规模应用。

SOME/IP的几种通讯方式（Dr. Lars Völker, BMW Group, Communication Protocols for Ethernet in the vehicle）

可以看出的是，SOME/IP主要还是请求/应答Request/Response的通讯方式。Fire&Forget可以算做一种特殊请求方式，不需要应答。Event和DDS的Topic比较接近，一般用来支持Pub/Sub的通讯方式。Field算是在Event的功能基础上：支持某一事件触发后，对订阅方Subscriber的通知。同时，又支持Getter/Setter的两种调用方式。我们从面向对象编程OOP这个角度来理解，这里一个Service比较像一个类，一个Field算做一个类成员。

SOME/IP这个模型很大程度上直接沿用到COM的服务接口当中。

DDS在AP AUTOSAR架构中的位置

如果套用AUTOSAR分层架构，使用DDS对应用层是透明的。ara::com抽象了DDS的技术细节。通过不同的network binding连接到DDS协议栈。因此，DDS属于和SOME/IP同一个层面。

DDS在AUTOSAR分层架构中的位置

DDS在AP AUTOSAR的集成

首先AP AUTOSAR一个App端，无论是服务提供方还是服务消费方，我们都可以把他理解为DomainParticipant。

AUTOSAR应用对应于DDS DomainParticipant

用DDS实现服务发现ServiceDiscovery

为了实现服务发现，解决方案为在服务提供方的QoS策略里使用USER_DATA这项定义服务的地址。地址的格式非常清晰：由Service ID和Service Instance ID组成。

回到上次Radar那个案例：

Radar的Service ID

Service Instance ID

对于DDS的配置，那么在Radar侧的服务接口，需要定义

USER_DATA：ara_com://99_19

在系统运行时， 服务提供方Radar调用OfferService()生成上面提到的USER_DATA。服务消费方fusion调用FindService() and StartFindService()这样就能寻找到对应的服务了。

DDS实现服务发现

用DDS实现Events, Methods, and Fields

实现Event的过程实际是把一个Topic和一个Event建立对应关系。

DDS实现Event

实现Method用到的是DDS-RPC。本质上讲，也是把一个Method拆开为两个不同方向的Topic。

DDS实现Method

前面我们提过，Field是在具有Event的功能基础上，附加两个Getter和Setter Methods。那这里不多解释，直接上图。

DDS实现Fields

总结

DDS已经能够比较好的集成在AUTOSAR环境里的。目前重要的应用场景为一套AP AUTOSAR的环境能直接和其他基于DDS的自动驾驶框架实现信息互通。