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版本中完善。