韓 軍 王永生

（海軍航空大學(xué) 煙臺 264001）

1 引言

傳感器數(shù)據(jù)是時效性很強的數(shù)據(jù)對象，對實時性具有很高的要求。將合適的傳感器數(shù)據(jù)在合適的時間分發(fā)給合適的用戶是傳感器數(shù)據(jù)分發(fā)系統(tǒng)設(shè)計的原則之一，其中合適的時間是指傳感器數(shù)據(jù)快速實時的分發(fā)，合適的傳感器數(shù)據(jù)和合適的用戶是指傳感器數(shù)據(jù)的按需分發(fā)［1］。

對象管理組織OMG于2004年發(fā)布了第一個基于發(fā)布/訂閱體系結(jié)構(gòu)的實時通信規(guī)范——數(shù)據(jù)分發(fā)服務(wù)［2］（Data Distribution Service，DDS）。DDS采用以數(shù)據(jù)為中心的設(shè)計思想，定義了大量的QOS策略，能夠解決高效、實時的數(shù)據(jù)分發(fā)問題，非常貼合傳感器網(wǎng)絡(luò)等應(yīng)用場景。

2 實時數(shù)據(jù)分發(fā)規(guī)范——DDS

2.1 數(shù)據(jù)為中心的發(fā)布/訂閱模型

傳統(tǒng)的客戶端/服務(wù)器模型以對象為中心，客戶端與服務(wù)器之間高度耦合，降低了系統(tǒng)的健壯性、靈活性和可擴展性，同時服務(wù)器端工作效率低，容易造成網(wǎng)絡(luò)阻塞。分布式對象模型是隨著網(wǎng)絡(luò)和面向?qū)ο蠹夹g(shù)逐漸完善起來的，主流實現(xiàn)模型有三種：COBRA、DCOM和 EJB［3］。其中COBRA最為完善，具有無關(guān)于操作系統(tǒng)、開發(fā)語言的獨立性，但其本質(zhì)上依然屬于C/S模型，不能滿足實時性的要求，不能對不同的數(shù)據(jù)類型進行實時性和可靠性的折中。以數(shù)據(jù)為中心的發(fā)布/訂閱（Data Centric Publish Subscribe，DCPS）模型實現(xiàn)了發(fā)布者和訂閱者在時間、空間和數(shù)據(jù)傳輸上的解耦，適用于節(jié)點可以隨意加入和退出的動態(tài)松耦合的網(wǎng)絡(luò)環(huán)境。

DCPS模型如圖1所示，一個節(jié)點上可以存在發(fā)布者、訂閱者，也可以兩者同時存在。標(biāo)以主題的數(shù)據(jù)通過數(shù)據(jù)域共享，具有相同主題的訂閱者和發(fā)布者才能建立發(fā)布/訂閱關(guān)系，服務(wù)質(zhì)量（Quality of Service，QoS）要求貫穿整個發(fā)布/訂閱過程。DCPS模型由域（Domain）、域參與者（DomainParticipant）、發(fā)布者（Publisher）、訂閱者（Subscriber）、數(shù)據(jù)寫入者（Publisher）、數(shù)據(jù)讀取者（DataWriter）和主題（Topic）等內(nèi)容組成［4］。

2.2 DDS體系結(jié)構(gòu)

DDS采用DCPS通信機制，提供了一個與平臺無關(guān)的數(shù)據(jù)模型。DDS規(guī)范分為兩層，DCPS層和數(shù)據(jù)本地重構(gòu)層（Data Local Reconstruction Layer，DLRL）。DCPS層是核心和基礎(chǔ)，提供了數(shù)據(jù)發(fā)布的基礎(chǔ)架構(gòu)和服務(wù)，DLRL層是可選層，建立在DCPS基礎(chǔ)之上，將DCPS層提供的服務(wù)進行了抽象，在DLRL層建立了與底層服務(wù)的映射關(guān)系［5］。目前，包括OpenDDS在內(nèi)的大多數(shù)實現(xiàn)僅實現(xiàn)了DCPS層，因此后面僅討論和研究DCPS層。DDS規(guī)范的層次結(jié)構(gòu)如圖2所示。

圖2 DDS的層次結(jié)構(gòu)

DCPS層建立了一個抽象的全局?jǐn)?shù)據(jù)空間GDS［6］（Global Data Space），發(fā)布者和訂閱者在該GDS中發(fā)布和訂閱自己需要的數(shù)據(jù)類型，通過中間件處理后進行數(shù)據(jù)傳送。DCPS層將用戶對資源的需求情況和資源的可用情況都轉(zhuǎn)化為服務(wù)質(zhì)量QoS，QoS參數(shù)貫穿整個DDS通信過程，通過設(shè)定QoS來程序化服務(wù)器的行為［7］。發(fā)布和訂閱是通過主題來關(guān)聯(lián)的，通過主題來關(guān)聯(lián)發(fā)布信息，創(chuàng)建發(fā)布和訂閱者實體，并為這些實體設(shè)定QoS參數(shù)。

2.3 QoS策略

DDS規(guī)范定義多個QoS策略，控制應(yīng)用程序間如何、何時發(fā)布數(shù)據(jù)的多個方面，應(yīng)用程序使用它指定其對服務(wù)質(zhì)量的要求。參與者指定它們需要服務(wù)的哪些行為，服務(wù)描述如何實現(xiàn)這些行為。這些策略可應(yīng)用于各個DCPS實體（主題、數(shù)據(jù)寫入者、數(shù)據(jù)讀取者、發(fā)布者、訂閱者、域參與者），但是并非所有策略對所有實體有效［8］。現(xiàn)對部分QoS的功能總結(jié)如下。

2.3.1 資源管理

1）Resource_Limits策略描述了有多少本地存儲可用于DDS基礎(chǔ)設(shè)施。在該策略中，max_samples成員指定單個數(shù)據(jù)寫入者或數(shù)據(jù)讀取者在其所有實例中可管理的樣本最大數(shù)量，max_instances成員指定數(shù)據(jù)寫入者或數(shù)據(jù)讀取者可管理的實例的最大數(shù)量，max_samples_per_instance成員指定單個數(shù)據(jù)寫入者或者數(shù)據(jù)讀取者中可為單個實例管理的樣本的最大數(shù)量。

2）Time_based_filter策略提供一種設(shè)置“最小間隔”時間段的方式，用于限制發(fā)布者發(fā)布的數(shù)據(jù)量，發(fā)布者使用該策略進行數(shù)據(jù)采樣后再發(fā)布，訂閱者使用該策略過濾接收的數(shù)據(jù)。

2.3.2 實時性控制

1）Deadline定義數(shù)據(jù)發(fā)送的最小速率，適用于主題、數(shù)據(jù)寫入者和數(shù)據(jù)讀取者。在數(shù)據(jù)寫入者和數(shù)據(jù)讀取者間創(chuàng)建關(guān)聯(lián)時，雙方的值必須兼容，即數(shù)據(jù)讀取者的Deadline值必須大于或等于數(shù)據(jù)寫入者的對應(yīng)值。該策略可用于設(shè)置傳感器數(shù)據(jù)分發(fā)系統(tǒng)的數(shù)據(jù)刷新率。

2）Latency_budget用來優(yōu)化并調(diào)節(jié)發(fā)布方在數(shù)據(jù)傳輸時訂閱者最大可接受時延。

2.3.3 通信控制

1）Reliability策略控制數(shù)據(jù)分發(fā)的可靠性，支持reliable和best effort兩種設(shè)置。如果將可靠性種類設(shè)置為盡力而為（best effort），則不會發(fā)生數(shù)據(jù)重傳。best effort的設(shè)置適合那些周期性強，且需要最新樣本的數(shù)據(jù)。如果要求給定信息的全部數(shù)據(jù)樣本，則該參數(shù)應(yīng)設(shè)置為reliable。

2）Ownership策略描述了多個數(shù)據(jù)寫入者是否能更新數(shù)據(jù)對象的同一實例。當(dāng)所有權(quán)設(shè)置為shared時，一個數(shù)據(jù)實例能被多個數(shù)據(jù)寫入者更新，當(dāng)設(shè)置為exclusive時，一個數(shù)據(jù)實例只能被一個數(shù)據(jù)寫入者更新。被選中的數(shù)據(jù)寫入者是由所有權(quán)強度參數(shù)決定的。

3 傳感器數(shù)據(jù)分發(fā)系統(tǒng)設(shè)計

3.1 傳感器數(shù)據(jù)格式

本文研究的傳感器為空中目標(biāo)探測雷達，傳感器數(shù)據(jù)格式如表1所示。其中傳感器類型有火控雷達、紅外雷達和遠程預(yù)警雷達等，目標(biāo)類型為直升機、運輸機和轟炸機。用戶終端可以通過獲取某一或某些傳感器生成的數(shù)據(jù)來滿足遠程預(yù)警和協(xié)同作戰(zhàn)的需要。

表1 傳感器數(shù)據(jù)格式

3.2 發(fā)布/訂閱框架

3.2.1 事件聲明

事件聲明方式是指發(fā)布條件和訂閱條件對事件的描述方式，目前有三種事件聲明方式：主題方式、內(nèi)容方式和類型方式［9］。

主題是發(fā)布和訂閱應(yīng)用程序間互動的基本方法，發(fā)布者和訂閱者的主題相匹配才能建立通信。主題方式以關(guān)鍵字（keyword）的方式描述事件，表達能力較弱，但是實現(xiàn)簡單，目前許多成熟發(fā)布/訂閱中間件均采用這種方式。

基于內(nèi)容的方式事件描述能力很強，可以將有關(guān)于事件的元數(shù)據(jù)或是對事件進行封裝的數(shù)據(jù)結(jié)構(gòu)來作為事件屬性。但是這種方式匹配算法復(fù)雜、效率低，因此不適用于大規(guī)模分布式系統(tǒng)。

類型方式利用數(shù)據(jù)結(jié)構(gòu)來區(qū)分、刻畫事件，但是由于不同質(zhì)的事件可能具有相同的數(shù)據(jù)結(jié)構(gòu)，不能單獨使用。本文將采用類型與主題相結(jié)合的方式。

3.2.2 匹配模式

發(fā)布/訂閱包括兩種匹配模式，即分布注冊匹配模式和集中注冊匹配模式［10］。

分布式注冊匹配模式難以保證系統(tǒng)的完整性，不易掌握系統(tǒng)中存在的所有發(fā)布者和訂閱者。同時發(fā)布者和訂閱者的信息資源的查找和路由會占用額外的帶寬資源。

本文注冊服務(wù)器采用集中注冊匹配模式，接受傳感器代理和用戶終端代理的注冊。其中傳感器代理是傳感器數(shù)據(jù)的發(fā)布者，用戶終端代理是傳感器數(shù)據(jù)的訂閱者。傳感器代理和用戶終端代理將發(fā)布條件和訂閱條件直接發(fā)送給注冊服務(wù)器，由注冊服務(wù)器返回匹配結(jié)果。

3.2.3 通信架構(gòu)

傳感器數(shù)據(jù)分發(fā)系統(tǒng)采用非中心直連通信架構(gòu)［11］，注冊服務(wù)器在完成注冊匹配之后，不再發(fā)布者和訂閱者之間的通信，由發(fā)布者和訂閱者進行點對點的數(shù)據(jù)傳送，大大提高了通信效率。即使注冊服務(wù)器失效也不會影響正在進行的通信，因此系統(tǒng)具有很強的可靠性。

3.3 數(shù)據(jù)分發(fā)流程

傳感器數(shù)據(jù)分發(fā)系統(tǒng)諸要素之間的交互順序如圖3所示。要實現(xiàn)數(shù)據(jù)實時按需分發(fā)，關(guān)鍵是注冊匹配算法match（），其次是數(shù)據(jù)分發(fā)過程，分別由注冊服務(wù)、注冊匹配服務(wù)、發(fā)布服務(wù)和訂閱服務(wù)實現(xiàn)。

圖3 實體交互順序圖

3.3.1 注冊服務(wù)

注冊包括傳感器代理注冊和用戶終端代理注冊，傳感器代理注冊對應(yīng)圖中的advertise（）。傳感器代理接收傳感器數(shù)據(jù)后生成發(fā)布條件，用戶終端代理解析用戶終端的數(shù)據(jù)請求生成訂閱條件，然后分別將發(fā)布條件和訂閱條件發(fā)送給注冊服務(wù)器進行注冊。

3.3.2 注冊匹配服務(wù)

注冊服務(wù)器通過調(diào)用match（）實現(xiàn)注冊匹配服務(wù)，為已注冊的發(fā)布者尋找符合發(fā)布條件的訂閱者，并通過MatchNotify（）將匹配結(jié)果返回給發(fā)布者，這是發(fā)布/訂閱模型服務(wù)實現(xiàn)自動發(fā)現(xiàn)的關(guān)鍵。

3.3.3 發(fā)布服務(wù)和訂閱服務(wù)

發(fā)布服務(wù)扮演數(shù)據(jù)服務(wù)提供者的角色，對應(yīng)于圖中的Dissemination（）。發(fā)布服務(wù)將應(yīng)用數(shù)據(jù)按照訂閱條件按需分發(fā)給數(shù)據(jù)訂閱者，具體由Datawriter完成。訂閱服務(wù)是數(shù)據(jù)服務(wù)的消費者，通過Datareader實現(xiàn)訂閱數(shù)據(jù)的接收。

4 傳感器數(shù)據(jù)分發(fā)系統(tǒng)實現(xiàn)

4.1 中間件層實現(xiàn)

OpenDDS是由OCI組織開發(fā)的符合OMG DDS規(guī)范的發(fā)布/訂閱中間件，實現(xiàn)了DCPS層的主要功能和部分QoS，使用OpenDDS可以方便快速開發(fā)高效實時的數(shù)據(jù)分發(fā)系統(tǒng)［12］。另外，OpenDDS的源代碼完全公開，便于根據(jù)需求進行改造。因此，本文通過移植ACE、TAO和OpenDDS中間件，構(gòu)建了傳感器數(shù)據(jù)分發(fā)軟件的中間件層。

4.2 注冊條件描述

在DDS規(guī)范中，發(fā)布條件和訂閱條件是用主題Topic來描述的，通過對發(fā)布條件和訂閱條件中各數(shù)據(jù)項的分析，本文將傳感器類型作為topic的劃分標(biāo)準(zhǔn)。topic的命名方案如表2所示。

表2 Topic規(guī)劃表

根據(jù)表1所示傳感器數(shù)據(jù)格式，DDS數(shù)據(jù)類型的IDL定義如下：

4.3 注冊服務(wù)器

OpenDDS執(zhí)行一種獨立式的服務(wù)，叫做DCPSInfoRepo，以便發(fā)布者和訂閱者以集中式發(fā)現(xiàn)彼此，它作為一個CORBA服務(wù)器進行實現(xiàn)。DCPSInfoRepo運行方式如下：

DCPSInfoRepo-ORBListenEndpoints iiop：//localhost：12345-d domain_id

-ORBListenEndpoint iiop：//localhost：12345 指定注冊服務(wù)器監(jiān)聽注冊信息的地址和端口。

-d domain_id指定注冊服務(wù)器工作的域。

4.4 傳感器代理實現(xiàn)

傳感器代理使用發(fā)布服務(wù)實現(xiàn)傳感器數(shù)據(jù)分發(fā)，首先創(chuàng)建participant實體和Publisher實體，然后Publisher實體根據(jù)發(fā)布條件創(chuàng)建Topic，最后創(chuàng)建與Topic對應(yīng)的Datawriter。為簡單起見，所有實體均采用默認的QoS策略。

至此生成了所有需要通過注冊線程向服務(wù)器注冊的實體。

4.5 用戶終端代理實現(xiàn)

用戶終端代理使用訂閱服務(wù)實現(xiàn)傳感器數(shù)據(jù)的訂閱，首先創(chuàng)建participant實體和Subscriber實體，然后根據(jù)訂閱條件創(chuàng)建設(shè)置Topic，最后創(chuàng)建與Topic對應(yīng)的Datareader。訂閱端各實體的實現(xiàn)方式與發(fā)布端類似，具體代碼不再贅述。

5 程序運行示例

本文的應(yīng)用情形設(shè)計如下：發(fā)布端發(fā)布兩種主題，一種是目標(biāo)信息主題，另一種是雷達狀態(tài)主題，包括雷達開機（RADAR_OPENED）和雷達關(guān)機（RADAR_CLOSED）事件。訂閱端同時訂閱兩種主題，并實時打印接收到的目標(biāo)信息。當(dāng)訂閱者收到雷達關(guān)機事件時，將停止接收雷達數(shù)據(jù)。

要運行這個程序，必須先啟動DCPSInfoRepo進程，運行方法見4.3節(jié)。

運行訂閱者和發(fā)布者方法如下：

subscriber-DCPSConfigFile dds_tcp_conf.ini

publisher-DCPSConfigFile dds_tcp_conf.ini其中配置文件dds_tcp_conf.ini指定訂閱者和發(fā)布者的注冊服務(wù)器和數(shù)據(jù)傳輸協(xié)議等。

程序運行結(jié)果如圖4所示。

圖4 訂閱端

6 結(jié)語

DDS標(biāo)準(zhǔn)提出了以數(shù)據(jù)為中心的設(shè)計思想和技術(shù)規(guī)范，被歐美等國大量運用于民航、國防等諸多領(lǐng)域，且已形成相對完善的商業(yè)產(chǎn)品。將DDS技術(shù)應(yīng)用于傳感器數(shù)據(jù)分發(fā)系統(tǒng)，可以很好地滿足戰(zhàn)場數(shù)據(jù)對實時性、可靠性和靈活性的要求，實現(xiàn)數(shù)據(jù)的按需分發(fā)，有效地減少了網(wǎng)絡(luò)負載。目前國內(nèi)DDS的相關(guān)研究和應(yīng)用范圍還非常有限，應(yīng)加強該技術(shù)的研究，拓寬應(yīng)用范圍。