什么是DDS

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

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

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

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

全局?jǐn)?shù)據(jù)空間

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

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

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

實(shí)體Entity：DDS的基本對(duì)象，幾乎所有其他對(duì)象都是它的特化。

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

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

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

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

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

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

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

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

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

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

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

CP中的DDS模塊

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

序列化

反序列化

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

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

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

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

信息安全

E2E保護(hù)

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

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

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

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

QoS管理

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

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

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

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

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

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

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

功能安全機(jī)制

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

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

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

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

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

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

信息偽裝或錯(cuò)誤尋址：DDS安全認(rèn)證插件，如DDS Security, Version 1.1 第8.3“Authentication Plugin”節(jié)中定義的。在這個(gè)概念中，只能在DomainParticipant級(jí)別實(shí)現(xiàn)身份驗(yàn)證，因?yàn)閷儆谕籇omainParticipant級(jí)別的所有實(shí)體共享相同的對(duì)稱密鑰。這可以防止屬于DomainParticipant之外的實(shí)體訪問DomainParticipant通信，但不能區(qū)分被授權(quán)在DomainParticipant內(nèi)部通信的兩個(gè)不同實(shí)體。

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

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

審核編輯：劉清