DDS（Data Distribution Service）是OMG組織（Object Management Group）最早在2004年發(fā)布的分布式實時通信中間件標準，旨在使用發(fā)布-訂閱模式實現(xiàn)可靠、高性能、互操作、實時、可擴展的數(shù)據(jù)交換。

圖1:DDS軟件示例架構(gòu)圖

在汽車領(lǐng)域，Adaptive AUTOSAR于2018年引用DDS作為可選擇的通信方式之一。DDS的實時性恰好適合于自動駕駛系統(tǒng)。因為在這類系統(tǒng)中，通常會存在感知、預測、決策和定位等模塊，這些模塊都需要非常頻繁地高速交換數(shù)據(jù)。借助DDS，可以很好地滿足這類系統(tǒng)的通信需求。憑借以數(shù)據(jù)為中心及豐富的QoS機制，DDS在汽車行業(yè)中逐漸受到青睞，汽車制造商及供應商將DDS作為系統(tǒng)中可選的通訊中間件之一，從而增強其產(chǎn)品的功能特性及可靠性。

DDS具有以數(shù)據(jù)為中心、即插即用、豐富的QoS等特性，這意味著DDS在網(wǎng)絡傳輸中對各層級數(shù)據(jù)需要提供豐富且冗長的Header信息，方便通訊雙方識別所需內(nèi)容，因此對硬件及網(wǎng)絡中的傳輸和數(shù)據(jù)處理性能提出了較高要求。因此在未來，DDS、SOME/IP等SOA通信中間件與車載總線類似，在車內(nèi)將會是多種中間件長期共存的狀態(tài)。

DDS有諸多協(xié)議規(guī)范，其中最核心的2個規(guī)范是：DDS規(guī)范和DDSI-RTPS規(guī)范。DDS規(guī)范描述了分布式應用通信和以數(shù)據(jù)為中心的發(fā)布-訂閱模型，定義了應用接口（API）和通信語義，從而實現(xiàn)“在正確的時間向正確的地點有效可靠地傳遞正確的信息”。DDS規(guī)范提供了DDS核心概念在與平臺無關(guān)模型（PIM）中的抽象定義，以及相對于平臺專用模型（PSM）中的映射，從應用開發(fā)者視角詮釋了DDS的核心定義。但是，單純依靠DDS規(guī)范使得各DDS中間件供應商對于具體通信傳輸介質(zhì)、行為和數(shù)據(jù)包結(jié)構(gòu)有著自己的理解，若通信系統(tǒng)中各設備來自不同的DDS中間件供應商，其互操作性可能會存在問題。

為解決這一問題，OMG隨后發(fā)布了DDSI-RTPS規(guī)范，對通信結(jié)構(gòu)、數(shù)據(jù)消息結(jié)構(gòu)、收發(fā)行為、服務發(fā)現(xiàn)進行了定義，從而保證來自不同廠商的DDS中間件的互操作性。目前納入DDSI-RTPS規(guī)范中的底層通訊協(xié)議為UDP/IP。OMG組織目前暫未對DDS的測試規(guī)范進行定義。

圖2:DDS數(shù)據(jù)交互簡化拓撲圖

DDS中重要概念：

>

Domain

連接所有能夠互相通信的應用程序的分布式概念，只有在同一個Domain下的Publisher和Subscriber能夠互相通信，不同Domain的應用程序不知道彼此的存在，Domain通過DomainID進行區(qū)分。Domain中包含了DomainParticipant，后者代表了同一個Domain下參與通訊的應用程序，同時也是Publisher、Subscriber、Topic的工廠。

>

Topic

Publisher和Subscriber互相通訊的數(shù)據(jù)本身，其名稱（Topic Name）在一個Domain中是唯一的。

>

DataWriter

基于綁定的Topic，由應用程序發(fā)送數(shù)據(jù)的實體。1個DataWriter隸屬于1個Publisher，同時1個DataWriter對應于1個Topic。

>

DataReader

可使應用程序聲明期望的Topic數(shù)據(jù)，以及訪問Subscriber收到的數(shù)據(jù)。1個DataReader隸屬于1個Subscriber，1個DataReader對應1個Topic。

>

Publisher

負責發(fā)布實際Topic數(shù)據(jù)的實體，可以創(chuàng)建及配置多個DataWriter并綁定相應若干Topic。

>

Subscriber

負責接收訂閱Topic數(shù)據(jù)的實體，可以創(chuàng)建及配置多個DataReader并綁定相應若干Topic。

>

QoS

服務質(zhì)量（Quality of Service）是控制DDS服務的一系列特性。Topic、DataWriter、DataReader、Publisher、Subscriber以及DomainParticipant各實體均可配置其各自的QoS規(guī)則，這些QoS互相存在兼容性檢查。若通信雙方QoS不兼容，則無法建立通信。目前DDS v1.4版本規(guī)范定義了Durability、LiveLiness、Reliability、LifeSpan、History等QoS機制。

CANoe中開始支持DDS

隨著DDS開始在汽車電子領(lǐng)域的應用，Vector應客戶需求在CANoe 16 SP3版本中開始支持DDS的仿真、分析與測試。DDS的通訊模型基于CANoe中的Communication Concept（ComCo）實現(xiàn)。

基于CANoe建立DDS的仿真和解析工程環(huán)境，可以充分利用CANoe及其測試工具鏈現(xiàn)有的優(yōu)勢特性：

>

CANoe是汽車電子、IoT、航空航天等多領(lǐng)域仿真及測試的一站式整合平臺，支持CAN、CAN FD、CAN XL、LIN、FlexRay、SOME/IP、AUTOSAR PDU（CP/AP）、DoIP、CCP/XCP、NM網(wǎng)絡管理、UDS、Cyber Security（SecOC、TLS/DTLS、IPsec、MACsec等）、E2E、全球充電協(xié)議、MQTT、HTTP、WLAN、BLE等多種總線和協(xié)議；

>

采用用戶熟悉的CAPL、C#、Python語言實現(xiàn)；

>

支持SIL/HIL、通信路由、網(wǎng)絡仿真、數(shù)據(jù)分析/記錄、診斷/刷寫、電源管理、I/O控制等多種場景；

>

極具性價比的測試設計及測試腳本開發(fā)環(huán)境——vTESTstudio；

>

無縫耦合整車動力學模型及ADAS場景仿真模型工具DYNA4，或基于FMI/FMU、FDX、XIL API、COM、SIL KIT整合第三方測試工具鏈；

>

匹配汽車電子敏捷開發(fā)流程的CI/CT工具鏈體系。

如何在CANoe中創(chuàng)建DDS仿真及解析工程？通過下圖新建Distributed Objects工程：

圖3:新建CANoe DO工程

而后可在主界面中看到Communication Setup界面，該界面也可通過CANoe上方標簽頁Simulation下打開。隨后依據(jù)下圖指引新建DDS通信接口描述文件vCDL：

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

在選擇vCDL文件保存路徑及文件名后（注意路徑及文件名不能包含中文及特殊字符），依據(jù)下圖指引打開編輯：

圖5:編輯DDS通信接口描述文件

vCDL語言（Vector Communication Description Language）作為在CANoe Communication Concept中用于描述通信對象的語言，通過Distributed Objects（DO）對DDS的數(shù)據(jù)對象進行定義。DO的consumed value對應DDS DataReader；provided value對應DDS DataWriter。

以下圖示例說明：

定義結(jié)構(gòu)體作為Topic Type（即HealthData）；

在interface（即IMonitor）中將該結(jié)構(gòu)體作為consumed value（也可作為provided value）并進行實例化（即healthData），從而隱式聲明DDS DataReader，另顯式聲明名為“/Monitor/healthData”的Topic；

最終對該interface（即IMonitor）分別實例化為Monitor和Sensor，作為Subscriber和Publisher；

其中Sensor的類型為reverse，代表依據(jù)IMonitor中的consumed value（即healthData）反向作為provided value。

圖6:vCDL中對DDS的通信接口定義示例

vCDL DDS的結(jié)構(gòu)體中可以包含如下數(shù)據(jù)類型：uint或int（8、16、32、64bit），Bool，Double，F(xiàn)loat，String，Struct，Array，List，Bytes等，并在逐漸完善中。CANoe Help文檔中提供了DDS IDL數(shù)據(jù)類型與vCDL數(shù)據(jù)類型的詳細對應關(guān)系。

當前版本的vCDL中，可對consumed value（DDS DataReader）和provided value（DDS DataWriter）進行QoS規(guī)則設置，包括：Reliability、History、Durability、Lifespan、Liveliness，更多的QoS規(guī)則會在CANoe后續(xù)版本中完善。

其他對于DDS Binding時的屬性配置可參考詳情：CANoe 16 SP3 Help文檔中的“Distributed Objects (DOs) for Data Distribution Service (DDS)”頁面專題。

當完成DDS的通信接口描述文件創(chuàng)建后，CANoe會自動生成若干觀測事件及數(shù)據(jù)對象，包括DataWriter和DataReader的匹配/不匹配事件信息、服務發(fā)現(xiàn)信息、數(shù)據(jù)Sample信息、Built-in Topic信息等，以DO體現(xiàn)。

用戶可在“.. \Sample Configurations 16.3.110\Connectivity\DDS\DDSBasic”中了解DDS Demo示例工程。該工程運行后，在Trace窗口可查看詳細的DDS仿真和解析數(shù)據(jù)內(nèi)容。

圖7:CANoe中DDS工程運行狀態(tài)

由于DDS協(xié)議簇范圍廣，存在較多用戶自定義實現(xiàn)，除去當前針對ECU仿真及測試需要的DDS功能支持外，也滿足ROS2集成的功能。更多DDS功能將在后續(xù)CANoe版本中完善。