【文章转载】CANoe与DDS

DDS（Data Distribution Service）是OMG组织（Object Management Group）最早在2004年发布的分布式实时通信中间件标准，旨在使用发布-订阅模式实现可靠、高性能、互操作、实时、可扩展的数据交换。

图1:DDS软件示例架构图

在汽车领域，Adaptive AUTOSAR于2018年引用DDS作为可选择的通信方式之一。DDS的实时性恰好适合于自动驾驶系统。因为在这类系统中，通常会存在感知、预测、决策和定位等模块，这些模块都需要非常频繁地高速交换数据。借助DDS，可以很好地满足这类系统的通信需求。凭借以数据为中心及丰富的QoS机制，DDS在汽车行业中逐渐受到青睐，汽车制造商及供应商将DDS作为系统中可选的通讯中间件之一，从而增强其产品的功能特性及可靠性。

DDS具有以数据为中心、即插即用、丰富的QoS等特性，这意味着DDS在网络传输中对各层级数据需要提供丰富且冗长的Header信息，方便通讯双方识别所需内容，因此对硬件及网络中的传输和数据处理性能提出了较高要求。因此在未来，DDS、SOME/IP等SOA通信中间件与车载总线类似，在车内将会是多种中间件长期共存的状态。

DDS有诸多协议规范，其中最核心的2个规范是：DDS规范和DDSI-RTPS规范。DDS规范描述了分布式应用通信和以数据为中心的发布-订阅模型，定义了应用接口（API）和通信语义，从而实现“在正确的时间向正确的地点有效可靠地传递正确的信息”。DDS规范提供了DDS核心概念在与平台无关模型（PIM）中的抽象定义，以及相对于平台专用模型（PSM）中的映射，从应用开发者视角诠释了DDS的核心定义。但是，单纯依靠DDS规范使得各DDS中间件供应商对于具体通信传输介质、行为和数据包结构有着自己的理解，若通信系统中各设备来自不同的DDS中间件供应商，其互操作性可能会存在问题。

为解决这一问题，OMG随后发布了DDSI-RTPS规范，对通信结构、数据消息结构、收发行为、服务发现进行了定义，从而保证来自不同厂商的DDS中间件的互操作性。目前纳入DDSI-RTPS规范中的底层通讯协议为UDP/IP。OMG组织目前暂未对DDS的测试规范进行定义。

图2:DDS数据交互简化拓扑图

DDS中重要概念：

>

Domain

连接所有能够互相通信的应用程序的分布式概念，只有在同一个Domain下的Publisher和Subscriber能够互相通信，不同Domain的应用程序不知道彼此的存在，Domain通过DomainID进行区分。Domain中包含了DomainParticipant，后者代表了同一个Domain下参与通讯的应用程序，同时也是Publisher、Subscriber、Topic的工厂。

>

Topic

Publisher和Subscriber互相通讯的数据本身，其名称（Topic Name）在一个Domain中是唯一的。

>

DataWriter

基于绑定的Topic，由应用程序发送数据的实体。1个DataWriter隶属于1个Publisher，同时1个DataWriter对应于1个Topic。

>

DataReader

可使应用程序声明期望的Topic数据，以及访问Subscriber收到的数据。1个DataReader隶属于1个Subscriber，1个DataReader对应1个Topic。

>

Publisher

负责发布实际Topic数据的实体，可以创建及配置多个DataWriter并绑定相应若干Topic。

>

Subscriber

负责接收订阅Topic数据的实体，可以创建及配置多个DataReader并绑定相应若干Topic。

>

QoS

服务质量（Quality of Service）是控制DDS服务的一系列特性。Topic、DataWriter、DataReader、Publisher、Subscriber以及DomainParticipant各实体均可配置其各自的QoS规则，这些QoS互相存在兼容性检查。若通信双方QoS不兼容，则无法建立通信。目前DDS v1.4版本规范定义了Durability、LiveLiness、Reliability、LifeSpan、History等QoS机制。

CANoe中开始支持DDS

随着DDS开始在汽车电子领域的应用，Vector应客户需求在CANoe 16 SP3版本中开始支持DDS的仿真、分析与测试。DDS的通讯模型基于CANoe中的Communication Concept（ComCo）实现。

基于CANoe建立DDS的仿真和解析工程环境，可以充分利用CANoe及其测试工具链现有的优势特性：

>

CANoe是汽车电子、IoT、航空航天等多领域仿真及测试的一站式整合平台，支持CAN、CAN FD、CAN XL、LIN、FlexRay、SOME/IP、AUTOSAR PDU（CP/AP）、DoIP、CCP/XCP、NM网络管理、UDS、Cyber Security（SecOC、TLS/DTLS、IPsec、MACsec等）、E2E、全球充电协议、MQTT、HTTP、WLAN、BLE等多种总线和协议；

>

采用用户熟悉的CAPL、C#、Python语言实现；

>

支持SIL/HIL、通信路由、网络仿真、数据分析/记录、诊断/刷写、电源管理、I/O控制等多种场景；

>

极具性价比的测试设计及测试脚本开发环境——vTESTstudio；

>

无缝耦合整车动力学模型及ADAS场景仿真模型工具DYNA4，或基于FMI/FMU、FDX、XIL API、COM、SIL KIT整合第三方测试工具链；

>

匹配汽车电子敏捷开发流程的CI/CT工具链体系。

如何在CANoe中创建DDS仿真及解析工程？通过下图新建Distributed Objects工程：

图3:新建CANoe DO工程

而后可在主界面中看到Communication Setup界面，该界面也可通过CANoe上方标签页Simulation下打开。随后依据下图指引新建DDS通信接口描述文件vCDL：

图4:新建DDS通信接口描述文件

在选择vCDL文件保存路径及文件名后（注意路径及文件名不能包含中文及特殊字符），依据下图指引打开编辑：

图5:编辑DDS通信接口描述文件

vCDL语言（Vector Communication Description Language）作为在CANoe Communication Concept中用于描述通信对象的语言，通过Distributed Objects（DO）对DDS的数据对象进行定义。DO的consumed value对应DDS DataReader；provided value对应DDS DataWriter。

以下图示例说明：

定义结构体作为Topic Type（即HealthData）；

在interface（即IMonitor）中将该结构体作为consumed value（也可作为provided value）并进行实例化（即healthData），从而隐式声明DDS DataReader，另显式声明名为“/Monitor/healthData”的Topic；

最终对该interface（即IMonitor）分别实例化为Monitor和Sensor，作为Subscriber和Publisher；

其中Sensor的类型为reverse，代表依据IMonitor中的consumed value（即healthData）反向作为provided value。

图6:vCDL中对DDS的通信接口定义示例

vCDL DDS的结构体中可以包含如下数据类型：uint或int（8、16、32、64bit），Bool，Double，Float，String，Struct，Array，List，Bytes等，并在逐渐完善中。CANoe Help文档中提供了DDS IDL数据类型与vCDL数据类型的详细对应关系。

当前版本的vCDL中，可对consumed value（DDS DataReader）和provided value（DDS DataWriter）进行QoS规则设置，包括：Reliability、History、Durability、Lifespan、Liveliness，更多的QoS规则会在CANoe后续版本中完善。

其他对于DDS Binding时的属性配置可参考详情：CANoe 16 SP3 Help文档中的“Distributed Objects (DOs) for Data Distribution Service (DDS)”页面专题。

当完成DDS的通信接口描述文件创建后，CANoe会自动生成若干观测事件及数据对象，包括DataWriter和DataReader的匹配/不匹配事件信息、服务发现信息、数据Sample信息、Built-in Topic信息等，以DO体现。

用户可在“.. \Sample Configurations 16.3.110\Connectivity\DDS\DDSBasic”中了解DDS Demo示例工程。该工程运行后，在Trace窗口可查看详细的DDS仿真和解析数据内容。

图7:CANoe中DDS工程运行状态

由于DDS协议簇范围广，存在较多用户自定义实现，除去当前针对ECU仿真及测试需要的DDS功能支持外，也满足ROS2集成的功能。更多DDS功能将在后续CANoe版本中完善。