什么是DDS

數(shù)據(jù)分發(fā)服務（DDS）[1]是一個來自對象管理組（OMG）的中間件協(xié)議和API標準。它將系統(tǒng)的組件集成在一起，提供低延遲的數(shù)據(jù)連接，極高的可靠性，和可擴展的架構(gòu)。

DDS中間件是一個軟件層，它將應用程序從操作系統(tǒng)，網(wǎng)絡傳輸，和低級數(shù)據(jù)格式的細節(jié)中抽象出來。底層的細節(jié)，例如數(shù)據(jù)線格式，發(fā)現(xiàn)，連接，可靠性，協(xié)議，傳輸選擇，QoS，安全等，都由中間件管理。

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

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

全局數(shù)據(jù)空間

DDS依賴于一個與平臺無關(guān)的數(shù)據(jù)模型。這個模型定義了全局數(shù)據(jù)空間，并指定了發(fā)布者和訂閱者如何引用這個空間的一部分。數(shù)據(jù)模型可以簡單到一組沒有關(guān)聯(lián)的數(shù)據(jù)結(jié)構(gòu)，每個數(shù)據(jù)結(jié)構(gòu)由一個主題和一個類型來標識。

主題提供了一個唯一標識全局數(shù)據(jù)空間中某些數(shù)據(jù)項的標識符。類型提供了結(jié)構(gòu)信息，告訴中間件如何操作數(shù)據(jù)。使用類型化接口意味著需要一個生成工具，將類型描述轉(zhuǎn)換為適當?shù)慕涌诤蛯崿F(xiàn)，填補類型化接口和通用中間件之間的差距。

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

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

發(fā)布者Publisher：這個對象負責數(shù)據(jù)分發(fā)。它可以發(fā)布不同數(shù)據(jù)類型的數(shù)據(jù)。

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

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

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

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

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

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

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

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

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

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

CP中的DDS模塊

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

序列化

反序列化

數(shù)據(jù)過濾

數(shù)據(jù)記錄

數(shù)據(jù)持久化

數(shù)據(jù)重傳

信息安全

E2E保護

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

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

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

傳輸層提供了一組適合于啟用Dds通信的連接。例如，讓我們考慮一個使用一些發(fā)布者/數(shù)據(jù)寫入器在一些域參與者下的簡單發(fā)布SW-C。如果本地域參與者不支持動態(tài)發(fā)現(xiàn)，那么對于每個數(shù)據(jù)寫入器，就有必要靜態(tài)配置適當?shù)倪h程數(shù)據(jù)讀取器可達性信息。接收端也應該發(fā)生類似的情況：本地數(shù)據(jù)讀取器應該知道與之相關(guān)的數(shù)據(jù)寫入器的可達性信息。這些信息應該用于適當?shù)呐渲玫讓觽鬏攨f(xié)議。

QoS管理

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

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

數(shù)據(jù)安全機制

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

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

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

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

功能安全機制

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

端到端保護的概念假定在運行時應保護與安全相關(guān)的數(shù)據(jù)免受通信鏈路內(nèi)部故障的影響。

DDS規(guī)范具有內(nèi)在的安全機制（計數(shù)器、CRC、QoS策略），可用于支持安全論證。

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

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

信息延遲和阻塞對通信通道的訪問：LATENCY_BUDGET、DEADLINE和LIFESPAN質(zhì)量服務策略，分別在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”節(jié)中定義的。在這個概念中，只能在DomainParticipant級別實現(xiàn)身份驗證，因為屬于同一DomainParticipant級別的所有實體共享相同的對稱密鑰。這可以防止屬于DomainParticipant之外的實體訪問DomainParticipant通信，但不能區(qū)分被授權(quán)在DomainParticipant內(nèi)部通信的兩個不同實體。

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

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

審核編輯：劉清