Fast DDS 介紹與使用

汽車電子與軟件 2021-05-04 00:00

KDES 2026上海峰會：定義下一代工程仿真 一杯咖啡的時間，搞懂行波測距新趨勢

在上一篇中，我們介紹了DDS，eProsima的Fast DDS是DDS規范的C++實現，Fast DDS的前稱是Fast RTPS，目前ROS2將Fast DDS作為默認的DDS中間件實現。Fast DDS主要包括以下內容：

DDS API

DDS采用的通信模型是一種多對多單向數據交換，其中產生數據的應用程序將數據發布到屬于使用數據的應用程序的訂閱者的本地緩存。信息流由負責數據交換的實體之間建立的服務質量(QoS)策略來控制。

作為一個以數據為中心的模型，DDS建立在所有感興趣的應用程序都可以訪問的“全局數據空間”的概念之上。提供信息的應用程序作為發布者，訪問部分數據空間的應用程序作為訂閱者。每當發布者向該空間發布新數據時，中間件就將該信息傳播給所有感興趣的訂閱者。

通信發生在多個域之間，即連接所有能夠相互通信的分布式應用程序的孤立抽象平面。只有屬于同一個域的實體才能進行交互，訂閱數據的實體和發布數據的實體之間的匹配通過主題進行中介。主題是明確的標識符，它將在域中惟一的名稱與數據類型和一組附加的特定于數據的QoS相關聯。

DDS實體被建模為類或類型化接口，后者意味著更有效的資源處理，因為在執行前了解數據類型允許提前分配內存，而不是動態分配。

Fast DDS-Gen

依賴接口意味著需要一個生成工具，將類型描述轉換為適當的實現，以填補接口和中間件之間的空白。這個任務由生成工具Fast DDS-Gen完成，這是一個Java應用程序，它使用接口定義語言(IDL)文件中定義的數據類型生成源代碼。

RTPS Wire Protocol

Fast DDS在標準網絡上交換消息所使用的協議是實時發布-訂閱協議(RTPS)，這是由OMG聯盟定義和維護的用于DDS的互操作性有線協議，參考上一篇介紹。該協議通過TCP/UDP/IP等傳輸協議提供發布者-訂閱者通信，并保證不同DDS實現之間的兼容性。

由于RTPS協議的發布-訂閱和它的規范是為滿足DDS應用程序域所解決的相同需求而設計的，因此RTPS協議映射到許多DDS概念。所有RTPS核心實體都與一個RTPS域相關聯，該域表示一個端點匹配的隔離通信平面。RTPS協議中指定的實體與DDS實體一一對應，因此允許通信發生。

Fast DDS的主要特點如下：

兩層API：提供上層DDS和下層RTPS；

實時性：提供可配置的實時功能，保證在指定的時間限制內響應；
服務發現：內置基于對現有發布者和訂閱者的動態發現，并且不需要聯系或設置任何服務器就可以持續執行此任務，同時也支持配置其他發現機制；
支持同步和異步數據發布模式；
傳輸層：實現了可插拔的體系結構，當前版本支持五種傳輸：UDPv4, UDPv6, TCPv4, TCPv6和SHM(共享內存)；
安全性：提供可配置的安全通信，實現了可插拔的安全配置，包括：遠程參與者的身份驗證、實體的訪問控制和數據加密；
流量控制：支持可配置的吞吐量控制，可限制在特定條件下發送的數據量；
即插即用連接：新的應用程序和服務能夠自動發現，可以在任何時候加入或離開網絡，而不需要重新配置；
可伸縮性和靈活性：DDS建立在全局數據空間的概念之上，中間件負責在發布者和訂閱者之間傳播信息，這使得分布式網絡可以適應重新配置，并可擴展大量實體；
可移植性：DDS規范包括到IDL的特定平臺映射，允許使用DDS的應用程序只需重新編譯就可以在DDS實現之間切換；
可擴展性：允許使用新的服務擴展和增強協議，不會破壞向后兼容性和互操作性；
可配置性和模塊化：提供了一種通過代碼或XML配置文件進行配置的直觀方式。模塊化允許簡單設備實現協議的子集，同時仍然參與網絡；
高性能序列化：基于eProsima的Fast Buffers序列化，官網說其性能要高于Protocol Buffers和Thrift：
低資源的消耗：允許預分配資源，減少動態資源分配，避免無限制使用資源，最小化數據復制的需要；
多平臺：默認情況下，該項目可以在Linux、Windows和MacOS上運行；
免費和開源：Fast DDS庫、Fast RTPS庫、Fast DDS-Gen、內部依賴項(如Fast CDR)和外部依賴項(如foonathan庫)都是免費和開源的。

以上大部分內容都是官網翻譯+一點自己理解，下面我來具體講一下如何使用Fast DDS。其實，Fast DDS對開發者非常友好，不僅有框架文檔、API文檔，還自帶了豐富的示例代碼，不止HelloWorld那么簡單，基本上所有主要的功能點都能在示例代碼中找到，可以說很容易上手。

但是，我還是決定從零跑個HelloWorld看看，事實上，真的也碰到了一些問題，所以呀，絕知此事還是要躬行的。

關于下載和安裝，還是寫在了README里，回復“演示代碼”就可以看到鏈接。官方的示例中已經用HelloWorld.idl生成了代碼，而當我用Fast DDS-Gen，相同的idl，卻生成了不一樣的代碼，而我并不知道官方代碼是用了哪個版本的工具生成的，或者用的命令是不是不一樣，這是我遇到的第一個問題。

一開始，當我使用如下命令：

fastddsgen HelloWorld.idl

只生成了四個文件，比官方少了好幾個：

    
     ├── HelloWorld.cxx --> 實際存儲數據的結構
     ├── HelloWorld.h
     ├── HelloWorldPubSubTypes.cxx --> 繼承自eprosima::fastrtps::TopicDataType
     └── HelloWorldPubSubTypes.h

后來發現，可以通過“-example”選擇生成某一個平臺下的示例代碼：

    
     fastddsgen -example CMake HelloWorld.idl

這樣就生成了更多的代碼文件：

    
     ├── CMakeLists.txt
     ├── HelloWorld.cxx
     ├── HelloWorld.h
     ├── HelloWorldPublisher.cxx --> 發布者的實現
     ├── HelloWorldPublisher.h
     ├── HelloWorldPubSubMain.cxx --> 主程序
     ├── HelloWorldPubSubTypes.cxx
     ├── HelloWorldPubSubTypes.h
     ├── HelloWorldSubscriber.cxx --> 訂閱者的實現
     └── HelloWorldSubscriber.h

但這仍然和官方示例看起來不大一樣，事實上，發布者和訂閱者的實現真的就不一樣！而且，即使改了CMakeLists，編譯能過，運行時還是會crash，查了問題發現，用老一點版本的工具生成的就和官方示例差不多了，猜測官方示例并不是用最新工具生成的，所以我覺得保險的做法是只生成前面四個文件，可以參考官方示例實現發布者和訂閱者。

其實我理解在實際項目應用中，發布者和訂閱者的實現部分本來也是要自已寫的。前幾天在后臺收到了一條小伙伴的消息，說想了解如何使用Fast DDS的Log，其實代碼可以參考：test/unittest/logging/LogTests.cpp，但是我還是想在HelloWorld中簡單嘗試了一下，結果發現即使設置了日志級別，Info日志還是沒顯示出來：

查了源碼和文檔，發現需要在編譯階段，打開Debug模式和關閉LOG_NO_INFO開關，才可以顯示Info級別的日志(前方預警：Log會多到你懷疑人生，個人感覺這種方式并不是很合理，因為我想要的其實只是第一句而已)：

最后，結合個人體會和網上各路大神的回答(比如：知乎&Stack Overflow)，對比一下SomeIP和DDS：

特性

SomeIP

DDS


通信模式	請求/響應+訂閱發布	訂閱發布
架構風格	面向服務	以數據為中心
傳輸協議	TCP/UDP	默認為UDP，也支持TCP、共享內存
動態發現	是	是
Qos策略	依賴于TCP/UDP	提供豐富的Qos策略
AUTOSAR	支持CP、AP	CP 占用較大資源，支持AP
云端	不支持	需要DDS Web轉換
安全性	TLS	DDS Security安全規范，支持細粒度的安全規則，也支持TLS
應用領域	汽車	工業、航空、汽車等