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

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

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

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

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

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

圖2:DDS數(shù)據(jù)交互簡化拓?fù)鋱D

DDS中重要概念：

>

Domain

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

>

Topic

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

>

DataWriter

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

>

DataReader

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

>

Publisher

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

>

Subscriber

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

>

QoS

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

CANoe中開始支持DDS

隨著DDS開始在汽車電子領(lǐng)域的應(yīng)用，Vector應(yīng)客戶需求在CANoe 16 SP3版本中開始支持DDS的仿真、分析與測試。DDS的通訊模型基于CANoe中的Communication Concept（ComCo）實(shí)現(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)絡(luò)管理、UDS、Cyber Security（SecOC、TLS/DTLS、IPsec、MACsec等）、E2E、全球充電協(xié)議、MQTT、HTTP、WLAN、BLE等多種總線和協(xié)議；

>

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

>

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

>

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

>

無縫耦合整車動力學(xué)模型及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上方標(biāo)簽頁Simulation下打開。隨后依據(jù)下圖指引新建DDS通信接口描述文件vCDL：

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

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

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

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

以下圖示例說明：

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

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

最終對該interface（即IMonitor）分別實(shí)例化為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ù)類型的詳細(xì)對應(yīng)關(guān)系。

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

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

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

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

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

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