-
創提部落格
希望我們能與您分享和探討成長中的點點滴滴
CANoe與DDS
創提科技
2023/08/28
分享到
“轉載自維克多汽車技術（上海）有限公司，作者Vector China”
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規範（“DDS規範”：https://www.omg.org/spec/DDS/）和DDSI-RTPS規範（“DDSI-RTPS規範”：https://www.omg.org/spec/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。
以下圖示例說明：
1. 定義結構體作為Topic Type（即HealthData）；
2. 在interface（即IMonitor）中將該結構體作為consumed value（也可作為provided value）並進行產生實體（即healthData），從而隱式聲明DDS DataReader，另顯式聲明名為“/Monitor/healthData”的Topic；
3. 最終對該interface（即IMonitor）分別產生實體為Monitor和Sensor，作為Subscriber和Publisher；
4. 其中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工程運行狀態