DDS概述
DDS是OMG在2004年釋出的中介軟體協議和應用程式介面（API）標準，它為分散式系統提供了低延遲、高可靠性、可擴充套件的通訊架構標準。DDS目前在工業、醫療、交通、能源、國防領域都有廣泛的應用。OMG（Object Management Group）成立於1989年，是一個開放性的非營利性的計算機行業標準聯盟。OMG多年來致力於為工業分散式系統提供可互操作的，可移植的，可複用的軟體標準。它的成員包括IT行業的裝置供應商，終端使用者，政府部門，以及學術組織等。很多我們熟知的標準都來自OMG，比如UML（Unified Modeling Language），CORBA（Common Object Request Broker Architecture）等。
在去年關於SOME/IP的文章中我們曾簡單解釋過中介軟體的概念，即在分散式系統中，中介軟體是位於作業系統和使用者應用程式之間的軟體層，它將作業系統提供的資源進行抽象和封裝，為應用程式提供各種各樣的高階的服務和功能，比如通訊或資料共享。中介軟體的存在簡化了應用程式開發者的工作，這使他們能夠將注意力放在應用程式本身上，而不必在不同應用程式之間或不同系統之間的資料傳輸上花太多精力。
DDS最重要的特性是以資料為中心，這是與其他很多通訊中介軟體不同的地方。DDS的資料共享以Topic為單元，應用程式能夠通過Topic判斷其所包含的資料型別，而不必依賴其他的上下文資訊。同時，DDS能夠按照使用者定義的方式自動地進行儲存、釋出或訂閱資料，使應用程式能夠像訪問本地資料一樣去寫入或者讀取資料。
DDS實現的資料共享可以理解成一個抽象的“全域性資料空間”，任何應用程式，不論開發語言，或者執行的作業系統型別，都可以通過相同的方式訪問這個“全域性資料空間”，就好像訪問本地的儲存空間一樣。當然“全域性資料空間”僅僅是一個抽象的概念，在實現時仍然是分別儲存在每個應用程式的本地空間當中。在系統執行時，資料是按需傳輸或儲存的，資料的釋出者僅僅傳送對方需要的資料，而訂閱者僅接收並儲存本地應用程式當前需要的資料。
DDS還提供了非常靈活的QoS（Quality of Service）策略，以滿足使用者對資料共享方式的不同需求，比如可靠性，故障處理等等。針對資料安全性要求比較高的系統，DDS還提供了細顆粒度的資料安全控制，包括應用程式身份認證，許可權控制，資料加密等等。
類似於SOME/IP-SD，DDS提供了對資料釋出者和訂閱者的動態發現機制，這意味著使用者不必去配置通訊節點的地址或其他屬性資訊，因為他們在執行的過程中會自動發現對方，並自動完成相關配置，即實現了“即插即用“。
DCPS模型
DCPS（Data-Centric Publish-Subscribe）是DDS標準中定義的以資料為中心的訂閱-釋出模型。在這個模型中，向“全域性資料空間“寫入資料的一方稱為Publishers和DataWriter，同樣地，在”全域性資料空間“中讀取資料的一方稱為Subscriber和DataReader，下圖中展示了它們之間的邏輯關係。除了DCPS模型，DDS標準中還定義了一套完整的應用程式介面（API），該介面標準是與平臺無關的，這意味著不論應用程式使用什麼開發語言，或執行在什麼平臺之上，只要DDS中介軟體的實現符合DDS標準，那麼相關的應用程式即可實現不同平臺間的移植。
Figure 1 DCPS模型
資料的傳送過程，簡單來說就是應用程式呼叫DataWriter物件提供的write方法，把資料傳遞給Publisher物件，而Publisher負責將資料在網路上傳送出去。
資料的接收過程，簡單來說就是Subscriber負責從網路上接收資料，並把它儲存在對應的DataReader中。應用程式可以為對應的DataReader註冊一個回撥函式，或者使用DataReader提供的read和take方法來輪詢DataReader中的資料。
具體來說，DataWriter在邏輯上從屬於Publisher，並受Publisher管理。一個DataWriter只能從屬一個Publisher，而Publisher可以擁有多個DataWriter。每一個DataWriter都繫結一個Topic，所以同一個應用程式中可能存在多個DataWriter和Topic，此外還可以為同一個Topic繫結多個DataWriter。
同理，DataReader在邏輯上從屬於Subscriber，並受Subscriber管理。一個DataReader只能從屬一個Subscriber，而Subscriber可以擁有多個DataReader。每一個DataReader都繫結一個Topic，所以同一個應用程式中可能存在多個DataReader和Topic，此外還可以為同一個Topic繫結多個DataWriter。
這個DSCP模型的工作過程實際上很像日常生活中報紙的發行過程。我們以《人民日報》為例，其中Topic就是“人民日報“，資料即報紙中的文字或者圖片，DDS中介軟體負責報紙發行的所有中間環節和渠道，包括報紙的印刷，儲存，運輸等等。
QoS策略
使用者可以通過設定QoS策略來控制資料在應用程式之間共享的方式，每個DCPS實體，包括Topic，DataWriter，Publisher，DataReader，Subscriber等，都能夠獨立配置相應的QoS策略。
下面是幾種常用的QoS策略：
DEADLINE
如果希望某個Topic能夠週期更新，可以設定DEADLINE屬性。在資料的釋出方設定DEADLINE，這意味著應用程式必須以小於DEADLINE的週期去更新Topic；而在資料的訂閱方設定DEADLINE，這意味著資料的釋出方必須以小於DEADLINE的週期去釋出Topic。
LIFESPAN
通過設定LIFESPAN，可以使DataWriter寫入的每個資料樣本都有一個關聯的“到期時間”，超過該時間後，該資料樣本不再傳送給任何應用程式，並且這些資料將從DataReader快取中清除。
HISTORY
設定HISTORY屬性可以讓DataWriter儲存併傳送舊的取樣資料，新的DDS節點如果訂閱了相關的Topic，它不僅能夠接收到資料的當前值，也能收到一部分歷史值，從而瞭解資料近期的變化趨勢
RELIABILITY
為DataWriter設定RELIABILITY屬性，可以使資料實現“可靠”的傳輸，當出現通訊錯誤導致資料取樣沒有被接收到時，DataWriter會持續重傳，直到所有資料被正確接收。
RTPS協議
DDS的標準中並不包含傳輸層協議，所以不同的DDS實現可能使用不同的訊息互動方式，甚至使用不同的傳輸協議，這就可能導致來自不同廠家的DDS實現是不能互操作的。而隨著DDS在大型分散式系統中的應用越來越廣泛，制定統一傳輸層標準的需求越來越強烈。
RTPS（Real-Time Publish Subscribe）就是在此背景下誕生，它主要為了滿足工業自動化領域大規模分散式系統的需求，也能夠很好的契合DDS協議特點。規範中定義了訊息格式，各種使用場景下的訊息互動方式等。它的主要特點包括：
- 提供容錯機制，避免單點故障
- 高擴充套件性，支援“即插即用”
- 模組化設計，針對計算能力較弱的平臺，可只實現RTPS的一個子集功能，並且不會出現相容性問題
Figure 2 RTPS 示例
RTPS基於多播、無連線的傳輸模型，這個模型可以對映到不同的傳輸協議上，如UDP/IP（這也是目前RTPS標準中唯一被標準化的傳輸協議）。除此之外，基於TCP的傳輸，以及基於TSN（Time-Sensitive Networks）的傳輸的相關標準也在制定中。很多DDS的實現支援除UDP/IP之外的多種傳輸協議，但並沒有遵循統一的標準，因此不同供應商的DDS實現之間可能存在互操作問題。
DDS與SOME/IP
DDS與SOME/IP存在諸多不同，但是需要強調的是，二者的設計需求不同，目標應用場景不同，所以我們不能簡單的判定孰優孰劣。在選取技術方案時，應考慮具體的應用場景，結合各個方案的功能，效能，成本等多個維度，才能做出合理的選擇。我們可以從以下幾個方面進行對比，為讀者提供參考。
通訊模式
SOME/IP是面向服務的通訊，服務端將方法和資料以服務的形式暴露給其他節點。而DDS最大的特點是以資料為中心，側重資料的分發，這種模式其實很像傳統的面向訊號的通訊，只不過DDS更靈活，功能更強大。
應用程式介面
SOME/IP協議標準中沒有定義標準API，所以基於不同SOME/IP實現的應用程式一般是不能互相移植的。DDS制定了多種程式語言的標準API，因此DDS應用程式理論上能夠在不同的DDS實現上進行移植。
傳輸協議
SOME/IP支援UDP和TCP，此外，從AUTOSAR 4.3開始支援對大於1400位元組的UDP資料進行分段傳輸，即SOME/IP-TP。DDS則使用前面提到的RTPS協議，至少支援UDP/IP，而很多DDS實現還支援其他傳輸協議，如TCP。 RTPS實現了與傳輸無關的可靠性和分段協議，理論上可在任何傳輸形式之上執行。
安全性
SOME/IP本身並不提供資料安全的控制，所以它的安全性依賴於傳輸協議，比如基於IPsec或TLS上執行。DDS當然也可以在IPsec或TLS上執行，但這並不是首選的方式。DDS提供多種外掛，實現了對安全性的更細粒度的控制，比如資料的加密傳輸，讀寫許可權控制，應用程式身份認證等，並且DDS安全機制與傳輸協議無關，因此使用任何傳輸協議都不影響安全機制的實現。
QoS支援
DDS提供多種QoS策略，而SOME/IP本身不提供QoS的支援，因此只能在傳輸協議或者應用程式中實現。
資源需求
DDS在諸多方面提供了更豐富的特性，這自然就導致了在資源需求上，比如記憶體佔用，比SOME/IP要大得多。
AUTOSAR平臺支援
AUTOSAR Adaptive平臺從2018年起開始支援對DDS的繫結，Classic平臺目前還並沒有支援DDS繫結的規劃。而SOME/IP是針對汽車應用定製的，可以無縫部署在AUTOSAR Adaptive和Classic平臺中。
DDS測試
OMG組織並不提供DDS軟體實現，各廠商可以根據該標準實現自己的DDS。我們可以在DDS官網（https://www.omg.org/dds-directory/）查詢DDS的供應商列表，使用者可以按照自己的具體需求進行選擇。這種由第三方供應商提供的預構建軟體，一般稱為商業現貨軟體（COTS）。對於COTS軟體，我們在測試策略的選擇上與自行開發的軟體是不同的。一般來說，COTS軟體往往是經過市場和時間驗證的產品，其核心部分是比較穩定的，並且已由供應商進行了單元和功能測試。因此我們可以減少對COTS軟體本身功能的重新測試，應該更側重在系統整合測試或效能測試等測試型別上。
下面為大家展示了一個簡單的DDS硬體在環（HiL）測試環境。
Figure 3 DDS 測試環境示例
為了保證ECU的正常執行環境，並監測或觸發ECU的某些行為，我們需要模擬ECU的外圍IO訊號或者匯流排訊號，這時我們可以藉助Vector提供的豐富的IO激勵和測量板卡，如VT系統，以及匯流排介面卡，如VN系列硬體等工具。在測試環境中，我們還需要模擬DDS Writer或者Reader，來發布或訂閱ECU的DDS資料，以此來驗證被測節點的變數範圍，非法值的錯誤處理機制等。由於CANoe暫不支援DDS節點的模擬功能，我們可以使用開源或者DDS廠商提供的庫，如pydds，RTI Connector等，來快速搭建DDS應用程式，並在CANoe中編寫介面來控制模擬節點。
Figure 4 使用vTESTstudio進行測試用例的設計和管理
測試用例方面，可使用vTESTstudio進行測試用例的設計和管理。vTESTstudio不但提供了圖形化和圖表化的測試用例設計方式，而且提供多種基於測試引數自動生成測試用例的功能，並支援模糊測試，能夠極大的提高測試用例的開發效率和測試覆蓋度。
Figure 5 測試報告展示
總結
自從汽車在十九世紀末被發明以來，技術的創新就從未停止過。汽車作為一種消費產品，已經從最初的交通工具變成了一種生活方式，正如今天的智慧手機不再僅僅是一個打電話的工具而已。通過持續的技術創新和融合，汽車變得更安全，更人性化，更智慧，更互聯。DDS的引入，無疑是在汽車和互聯世界之間開啟的另一扇大門。至於DDS能否在汽車行業內得到更廣泛的應用，還需要更全面和更細緻的評估，但我們期待DDS以其豐富的特性和功能，能夠為汽車應用領域帶來更多可能性，幫助應對汽車智慧化和互聯化道路上的更多挑戰。
北匯資訊專注汽車電子測試，擁有多年的專案實踐經驗，提供一站式的測試解決方案。本篇文章簡單介紹了DDS中介軟體技術以及測試方案，但由於篇幅有限，未能將更多內容展現給大家，期待感興趣的讀者能聯絡到我們，進行更進一步的交流。
參考文獻：
[1] Data Distribution Service (DDS) Version 1.4
[2] DDS Security Version 1.1
[3] The Real-time Publish-Subscribe Protocol DDS Interoperability Wire Protocol (DDSI-RTPSTM) Specification Version 2.3