什么是DDS

數據分發服務（DDS）[1]是一個來自對象管理組（OMG）的中間件協議和API標準。它將系統的組件集成在一起，提供低延遲的數據連接，極高的可靠性，和可擴展的架構。

DDS中間件是一個軟件層，它將應用程序從操作系統，網絡傳輸，和低級數據格式的細節中抽象出來。底層的細節，例如數據線格式，發現，連接，可靠性，協議，傳輸選擇，QoS，安全等，都由中間件管理。

DDS提供了QoS控制的數據共享。應用程序通過發布和訂閱主題（topic）來進行通信，主題由它們的主題名和類型來標識。訂閱者可以通過時間和內容過濾器來獲取主題上發布的數據的一個子集。不同的DDS域彼此完全獨立。DDS域之間沒有數據共享。

DDS以數據為中心，這個特點保證了所有的消息都包含了應用程序需要理解數據的上下文信息。DDS知道它存儲了什么數據，并控制了如何共享這些數據。使用傳統的基于消息的中間件的程序員必須編寫發送消息的代碼。使用數據中心化的中間件的程序員編寫指定如何和何時共享數據的代碼，然后直接共享數據值。而不是在應用程序（用戶）代碼中管理所有這些復雜性，DDS直接為用戶實現了受控的，管理的，安全的數據共享。

全局數據空間

DDS依賴于一個與平臺無關的數據模型。這個模型定義了全局數據空間，并指定了發布者和訂閱者如何引用這個空間的一部分。數據模型可以簡單到一組沒有關聯的數據結構，每個數據結構由一個主題和一個類型來標識。

主題提供了一個唯一標識全局數據空間中某些數據項的標識符。類型提供了結構信息，告訴中間件如何操作數據。使用類型化接口意味著需要一個生成工具，將類型描述轉換為適當的接口和實現，填補類型化接口和通用中間件之間的差距。

以下定義可能有助于更好地理解DDS。

實體Entity：DDS的基本對象，幾乎所有其他對象都是它的特化。

發布者Publisher：這個對象負責數據分發。它可以發布不同數據類型的數據。

數據寫入DataWriter：應用程序必須使用數據寫入器來向發布者通知給定類型的數據對象的存在和值。當數據對象的值通過適當的數據寫入器傳遞給發布者時，發布者有責任執行分發（發布者將根據自己的QoS或附加到相應數據寫入器的QoS來執行此操作）。

訂閱者Subscriber：訂閱者負責接收發布的數據，并根據訂閱者的QoS使其可用于接收應用程序。它可以接收和分發不同指定類型的數據。

數據讀取DataReader：訂閱者使用數據讀取器來向應用程序提供特定類型的接收數據。

域Domain：域是一個分布式的概念，它連接了所有能夠相互通信的應用程序。它代表了一個通信平面：只有附加到同一域的發布者和訂閱者才能相互作用。

服務質量（QoS）：QoS（服務質量）是一個通用的概念，用于指定一個實體的行為。QoS由單個QoS策略（QosPolicy類型的對象）組成。影響不同實體的一個或多個QoS策略的特定值可以分組在QoS配置文件中。

主題Topic：一個主題對應于一個單一的數據類型。主題對象在概念上位于發布和訂閱之間。發布必須以一種訂閱可以明確引用的方式被知曉。主題的目的就是滿足這個需求：它將一個名字（在域中唯一）、一個數據類型和與數據本身相關的QoS關聯起來。除了主題QoS之外，與該主題相關的數據寫入器的QoS和與數據寫入器相關的發布者的QoS控制了發布者端的行為，而相應的主題、數據讀取器和訂閱者QoS控制了訂閱者端的行為。

DDS是一個以數據為中心的發布訂閱協議，這個協議定義了應用程序發布和訂閱數據對象的值的功能。它允許：

發布應用程序標識它們打算發布的數據對象，然后提供這些對象的值（它們使用一些在某些域參與者中定義的發布者/數據寫入器）。

訂閱應用程序標識它們感興趣的數據對象，然后訪問它們的數據值（它們使用一些在與它們想要接收數據的各個主題的發布者相同的域參與者中定義的訂閱者/數據讀取器）。

應用程序定義主題，將類型信息附加到主題，創建發布者和訂閱者實體，將QoS策略附加到所有這些實體，總之，使所有這些實體運行。

CP中的DDS模塊

DDS模塊實現實體管理，QoS等接口邏輯，還有DDSI-RTPS標準層，它是一個具備以下功能的協議棧：

序列化

反序列化

數據過濾

數據記錄

數據持久化

數據重傳

信息安全

E2E保護

從傳輸路徑的角度來看，DDS模塊只提供了一個基于PDU的接口，用于傳入（例如，上層PDU）和傳出（例如，下層PDU）的PDU。

基本上，在發送端，Dds數據是在應用層創建的，并直接傳遞給RTE（作為未序列化的數據），然后轉發給LdCom，PduR，然后作為一個PDU轉發給Dds模塊，沒有經過任何修改或轉換（在接收端也是如此）。RTE，LdCom和PduR（作為上層）只是簡單地充當透傳模塊。序列化是在Dds BSW內部執行的，對AUTOSAR堆棧完全不透明。Dds BSW應該知道復制數據的確切數據類型。

需要注意的是，在RTE，即使對于復合數據類型，也不會進行任何轉換或序列化：數據會從應用層復制到ISignal（在LdCom緩沖區中），然后PduR將信息路由到DDS模塊，數據到達Dds時完全沒有修改。Dds模塊能夠通過其映射到PDU的類型來處理數據。下層PDU包含了DDSI-RTPS協議包，準備好交付給傳輸層。

傳輸層提供了一組適合于啟用Dds通信的連接。例如，讓我們考慮一個使用一些發布者/數據寫入器在一些域參與者下的簡單發布SW-C。如果本地域參與者不支持動態發現，那么對于每個數據寫入器，就有必要靜態配置適當的遠程數據讀取器可達性信息。接收端也應該發生類似的情況：本地數據讀取器應該知道與之相關的數據寫入器的可達性信息。這些信息應該用于適當的配置底層傳輸協議。

QoS管理

Dds BSW可以支持一部分（甚至為空）的QoS策略。沒有必須實現的QoS。哪些QoS策略實際上是支持的，這是由供應商決定的。

對于DDS的TRANSPORT_PRIORITY QoS，由SoAdSocketFramePriority實現，但具體Dds模塊在運行時需要自己選擇發送PDU送到哪個優先級的SoAd connection上。

數據安全機制

在AP和CP之間，甚至在CP和非AUTOSAR平臺之間，建立通信路徑可能會涉及安全風險，因此可能需要使用一些安全機制。Dds BSW模塊通過使用DDS安全規范來[2]保證一些安全機制。使用這個規范是為了保證與其他DDS系統的互操作性，無論是與AP（其中已經使用了DDS數據安全）還是與非AUTOSAR系統。然而，實現這個規范可能會非常消耗資源，特別是在一個慢速的微控制器上使用，這些功能需要硬件加速。為了克服這個問題，選擇了一個DDS數據安全功能的子集，它能保證最低的安全級別。

在這個階段，實現DDS數據安全的目的是為了保證消息認證，數據完整性和組認證。安全機制可以在配置時啟用或禁用。如果啟用，所有的安全參數必須在預編譯時靜態配置。

如果配置了，整個RTPS消息的消息認證碼（MAC）會被添加。AUTOSAR CSM用于密鑰管理和MAC計算，要使用的算法是可配置的（從支持的算法中選擇）。

用于哈希算法的密鑰是對稱密鑰，它們在與域參與者相關的實體之間共享，所以認證是在域參與者級別進行的（不是單個發布者/訂閱者，不是單個數據寫入器/數據讀取器）。要使用的對稱密鑰應該由CSM直接管理，它應該提供一個handler給DDS，以便使用它的服務。為了上述目的，使用了DDS加密插件，它提供了一個接口來保護整個RTPS消息。在應用安全后，結果RTPS消息如下圖所示。

功能安全機制

根據ISO 26262，在執行不同軟件分區或ECU中的發送器和接收器之間的通信鏈路上的一組故障需要被考慮。

端到端保護的概念假定在運行時應保護與安全相關的數據免受通信鏈路內部故障的影響。

DDS規范具有內在的安全機制（計數器、CRC、QoS策略），可用于支持安全論證。

以下是在追求功能安全時需要解決的可能故障列表，以及DDS提供的支持它們的機制：

重復、丟失、插入、不正確的順序、僅由接收器子集接收到的來自發送方的信息以及阻塞對通信通道的訪問：子消息64位序列號，如DDS Interoperability Wire Protocol, Version 2.2第8節3.5.4“SequenceNumber”中定義的，以及在第8.3.7“RTPS Submessages”中定義的額外的SequenceNumber類型字段。這些機制僅對在接收器端檢測丟失有用；如果還需要在發送器端進行檢測，則應結合使用DDS QoS。

信息延遲和阻塞對通信通道的訪問：LATENCY_BUDGET、DEADLINE和LIFESPAN質量服務策略，分別在Data Distribution Service (DDS), Version 1.4的2.2.3.8“LATENCY_BUDGET”、2.2.3.7“DEADLINE”和2.2.3.16“LIFESPAN”中定義的部分。

信息偽裝或錯誤尋址：DDS安全認證插件，如DDS Security, Version 1.1 第8.3“Authentication Plugin”節中定義的。在這個概念中，只能在DomainParticipant級別實現身份驗證，因為屬于同一DomainParticipant級別的所有實體共享相同的對稱密鑰。這可以防止屬于DomainParticipant之外的實體訪問DomainParticipant通信，但不能區分被授權在DomainParticipant內部通信的兩個不同實體。

信息損壞、從發送方發送到多個接收器的不對稱信息（僅對導致無效CRC的情況有效）：位于HeaderExtension子消息下的rtpsMessageChecksum（[RTPS 2.5或更高版本]）。在沒有此功能的情況下，DDS Security, Version 1.1 還提供了內置于其消息認證協議中的消息完整性驗證。對于CRC計算，使用AUTOSAR CRC庫。

對這些故障條件錯誤的通知：在發生任何通信錯誤或故障（甚至是超時錯誤）時，Dds BSW應通知Det模塊。

審核編輯：劉清