韓 軍 王永生
(海軍航空大學(xué) 煙臺 264001)
傳感器數(shù)據(jù)是時(shí)效性很強(qiáng)的數(shù)據(jù)對象,對實(shí)時(shí)性具有很高的要求。將合適的傳感器數(shù)據(jù)在合適的時(shí)間分發(fā)給合適的用戶是傳感器數(shù)據(jù)分發(fā)系統(tǒng)設(shè)計(jì)的原則之一,其中合適的時(shí)間是指傳感器數(shù)據(jù)快速實(shí)時(shí)的分發(fā),合適的傳感器數(shù)據(jù)和合適的用戶是指傳感器數(shù)據(jù)的按需分發(fā)[1]。
對象管理組織OMG于2004年發(fā)布了第一個(gè)基于發(fā)布/訂閱體系結(jié)構(gòu)的實(shí)時(shí)通信規(guī)范——數(shù)據(jù)分發(fā)服務(wù)[2](Data Distribution Service,DDS)。DDS采用以數(shù)據(jù)為中心的設(shè)計(jì)思想,定義了大量的QOS策略,能夠解決高效、實(shí)時(shí)的數(shù)據(jù)分發(fā)問題,非常貼合傳感器網(wǎng)絡(luò)等應(yīng)用場景。
傳統(tǒng)的客戶端/服務(wù)器模型以對象為中心,客戶端與服務(wù)器之間高度耦合,降低了系統(tǒng)的健壯性、靈活性和可擴(kuò)展性,同時(shí)服務(wù)器端工作效率低,容易造成網(wǎng)絡(luò)阻塞。分布式對象模型是隨著網(wǎng)絡(luò)和面向?qū)ο蠹夹g(shù)逐漸完善起來的,主流實(shí)現(xiàn)模型有三種:COBRA、DCOM和 EJB[3]。其中COBRA最為完善,具有無關(guān)于操作系統(tǒng)、開發(fā)語言的獨(dú)立性,但其本質(zhì)上依然屬于C/S模型,不能滿足實(shí)時(shí)性的要求,不能對不同的數(shù)據(jù)類型進(jìn)行實(shí)時(shí)性和可靠性的折中。以數(shù)據(jù)為中心的發(fā)布/訂閱(Data Centric Publish Subscribe,DCPS)模型實(shí)現(xiàn)了發(fā)布者和訂閱者在時(shí)間、空間和數(shù)據(jù)傳輸上的解耦,適用于節(jié)點(diǎn)可以隨意加入和退出的動(dòng)態(tài)松耦合的網(wǎng)絡(luò)環(huán)境。
DCPS模型如圖1所示,一個(gè)節(jié)點(diǎn)上可以存在發(fā)布者、訂閱者,也可以兩者同時(shí)存在。標(biāo)以主題的數(shù)據(jù)通過數(shù)據(jù)域共享,具有相同主題的訂閱者和發(fā)布者才能建立發(fā)布/訂閱關(guān)系,服務(wù)質(zhì)量(Quality of Service,QoS)要求貫穿整個(gè)發(fā)布/訂閱過程。DCPS模型由域(Domain)、域參與者(DomainParticipant)、發(fā)布者(Publisher)、訂閱者(Subscriber)、數(shù)據(jù)寫入者(Publisher)、數(shù)據(jù)讀取者(DataWriter)和主題(Topic)等內(nèi)容組成[4]。
DDS采用DCPS通信機(jī)制,提供了一個(gè)與平臺無關(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ù)進(jìn)行了抽象,在DLRL層建立了與底層服務(wù)的映射關(guān)系[5]。目前,包括OpenDDS在內(nèi)的大多數(shù)實(shí)現(xiàn)僅實(shí)現(xiàn)了DCPS層,因此后面僅討論和研究DCPS層。DDS規(guī)范的層次結(jié)構(gòu)如圖2所示。
圖2 DDS的層次結(jié)構(gòu)
DCPS層建立了一個(gè)抽象的全局?jǐn)?shù)據(jù)空間GDS[6](Global Data Space),發(fā)布者和訂閱者在該GDS中發(fā)布和訂閱自己需要的數(shù)據(jù)類型,通過中間件處理后進(jìn)行數(shù)據(jù)傳送。DCPS層將用戶對資源的需求情況和資源的可用情況都轉(zhuǎn)化為服務(wù)質(zhì)量QoS,QoS參數(shù)貫穿整個(gè)DDS通信過程,通過設(shè)定QoS來程序化服務(wù)器的行為[7]。發(fā)布和訂閱是通過主題來關(guān)聯(lián)的,通過主題來關(guān)聯(lián)發(fā)布信息,創(chuàng)建發(fā)布和訂閱者實(shí)體,并為這些實(shí)體設(shè)定QoS參數(shù)。
DDS規(guī)范定義多個(gè)QoS策略,控制應(yīng)用程序間如何、何時(shí)發(fā)布數(shù)據(jù)的多個(gè)方面,應(yīng)用程序使用它指定其對服務(wù)質(zhì)量的要求。參與者指定它們需要服務(wù)的哪些行為,服務(wù)描述如何實(shí)現(xiàn)這些行為。這些策略可應(yīng)用于各個(gè)DCPS實(shí)體(主題、數(shù)據(jù)寫入者、數(shù)據(jù)讀取者、發(fā)布者、訂閱者、域參與者),但是并非所有策略對所有實(shí)體有效[8]?,F(xiàn)對部分QoS的功能總結(jié)如下。
2.3.1 資源管理
1)Resource_Limits策略描述了有多少本地存儲(chǔ)可用于DDS基礎(chǔ)設(shè)施。在該策略中,max_samples成員指定單個(gè)數(shù)據(jù)寫入者或數(shù)據(jù)讀取者在其所有實(shí)例中可管理的樣本最大數(shù)量,max_instances成員指定數(shù)據(jù)寫入者或數(shù)據(jù)讀取者可管理的實(shí)例的最大數(shù)量,max_samples_per_instance成員指定單個(gè)數(shù)據(jù)寫入者或者數(shù)據(jù)讀取者中可為單個(gè)實(shí)例管理的樣本的最大數(shù)量。
2)Time_based_filter策略提供一種設(shè)置“最小間隔”時(shí)間段的方式,用于限制發(fā)布者發(fā)布的數(shù)據(jù)量,發(fā)布者使用該策略進(jìn)行數(shù)據(jù)采樣后再發(fā)布,訂閱者使用該策略過濾接收的數(shù)據(jù)。
2.3.2 實(shí)時(shí)性控制
1)Deadline定義數(shù)據(jù)發(fā)送的最小速率,適用于主題、數(shù)據(jù)寫入者和數(shù)據(jù)讀取者。在數(shù)據(jù)寫入者和數(shù)據(jù)讀取者間創(chuàng)建關(guān)聯(lián)時(shí),雙方的值必須兼容,即數(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ù)傳輸時(shí)訂閱者最大可接受時(shí)延。
2.3.3 通信控制
1)Reliability策略控制數(shù)據(jù)分發(fā)的可靠性,支持reliable和best effort兩種設(shè)置。如果將可靠性種類設(shè)置為盡力而為(best effort),則不會(huì)發(fā)生數(shù)據(jù)重傳。best effort的設(shè)置適合那些周期性強(qiáng),且需要最新樣本的數(shù)據(jù)。如果要求給定信息的全部數(shù)據(jù)樣本,則該參數(shù)應(yīng)設(shè)置為reliable。
2)Ownership策略描述了多個(gè)數(shù)據(jù)寫入者是否能更新數(shù)據(jù)對象的同一實(shí)例。當(dāng)所有權(quán)設(shè)置為shared時(shí),一個(gè)數(shù)據(jù)實(shí)例能被多個(gè)數(shù)據(jù)寫入者更新,當(dāng)設(shè)置為exclusive時(shí),一個(gè)數(shù)據(jù)實(shí)例只能被一個(gè)數(shù)據(jù)寫入者更新。被選中的數(shù)據(jù)寫入者是由所有權(quán)強(qiáng)度參數(shù)決定的。
本文研究的傳感器為空中目標(biāo)探測雷達(dá),傳感器數(shù)據(jù)格式如表1所示。其中傳感器類型有火控雷達(dá)、紅外雷達(dá)和遠(yuǎn)程預(yù)警雷達(dá)等,目標(biāo)類型為直升機(jī)、運(yùn)輸機(jī)和轟炸機(jī)。用戶終端可以通過獲取某一或某些傳感器生成的數(shù)據(jù)來滿足遠(yuǎn)程預(yù)警和協(xié)同作戰(zhàn)的需要。
表1 傳感器數(shù)據(jù)格式
3.2.1 事件聲明
事件聲明方式是指發(fā)布條件和訂閱條件對事件的描述方式,目前有三種事件聲明方式:主題方式、內(nèi)容方式和類型方式[9]。
主題是發(fā)布和訂閱應(yīng)用程序間互動(dòng)的基本方法,發(fā)布者和訂閱者的主題相匹配才能建立通信。主題方式以關(guān)鍵字(keyword)的方式描述事件,表達(dá)能力較弱,但是實(shí)現(xiàn)簡單,目前許多成熟發(fā)布/訂閱中間件均采用這種方式。
基于內(nèi)容的方式事件描述能力很強(qiáng),可以將有關(guān)于事件的元數(shù)據(jù)或是對事件進(jìn)行封裝的數(shù)據(jù)結(jié)構(gòu)來作為事件屬性。但是這種方式匹配算法復(fù)雜、效率低,因此不適用于大規(guī)模分布式系統(tǒng)。
類型方式利用數(shù)據(jù)結(jié)構(gòu)來區(qū)分、刻畫事件,但是由于不同質(zhì)的事件可能具有相同的數(shù)據(jù)結(jié)構(gòu),不能單獨(dú)使用。本文將采用類型與主題相結(jié)合的方式。
3.2.2 匹配模式
發(fā)布/訂閱包括兩種匹配模式,即分布注冊匹配模式和集中注冊匹配模式[10]。
分布式注冊匹配模式難以保證系統(tǒng)的完整性,不易掌握系統(tǒng)中存在的所有發(fā)布者和訂閱者。同時(shí)發(fā)布者和訂閱者的信息資源的查找和路由會(huì)占用額外的帶寬資源。
本文注冊服務(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ā)布者和訂閱者進(jìn)行點(diǎn)對點(diǎn)的數(shù)據(jù)傳送,大大提高了通信效率。即使注冊服務(wù)器失效也不會(huì)影響正在進(jìn)行的通信,因此系統(tǒng)具有很強(qiáng)的可靠性。
傳感器數(shù)據(jù)分發(fā)系統(tǒng)諸要素之間的交互順序如圖3所示。要實(shí)現(xiàn)數(shù)據(jù)實(shí)時(shí)按需分發(fā),關(guān)鍵是注冊匹配算法match(),其次是數(shù)據(jù)分發(fā)過程,分別由注冊服務(wù)、注冊匹配服務(wù)、發(fā)布服務(wù)和訂閱服務(wù)實(shí)現(xiàn)。
圖3 實(shí)體交互順序圖
3.3.1 注冊服務(wù)
注冊包括傳感器代理注冊和用戶終端代理注冊,傳感器代理注冊對應(yīng)圖中的advertise()。傳感器代理接收傳感器數(shù)據(jù)后生成發(fā)布條件,用戶終端代理解析用戶終端的數(shù)據(jù)請求生成訂閱條件,然后分別將發(fā)布條件和訂閱條件發(fā)送給注冊服務(wù)器進(jìn)行注冊。
3.3.2 注冊匹配服務(wù)
注冊服務(wù)器通過調(diào)用match()實(shí)現(xiàn)注冊匹配服務(wù),為已注冊的發(fā)布者尋找符合發(fā)布條件的訂閱者,并通過MatchNotify()將匹配結(jié)果返回給發(fā)布者,這是發(fā)布/訂閱模型服務(wù)實(shí)現(xiàn)自動(dòng)發(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ù)的消費(fèi)者,通過Datareader實(shí)現(xiàn)訂閱數(shù)據(jù)的接收。
OpenDDS是由OCI組織開發(fā)的符合OMG DDS規(guī)范的發(fā)布/訂閱中間件,實(shí)現(xiàn)了DCPS層的主要功能和部分QoS,使用OpenDDS可以方便快速開發(fā)高效實(shí)時(shí)的數(shù)據(jù)分發(fā)系統(tǒng)[12]。另外,OpenDDS的源代碼完全公開,便于根據(jù)需求進(jìn)行改造。因此,本文通過移植ACE、TAO和OpenDDS中間件,構(gòu)建了傳感器數(shù)據(jù)分發(fā)軟件的中間件層。
在DDS規(guī)范中,發(fā)布條件和訂閱條件是用主題Topic來描述的,通過對發(fā)布條件和訂閱條件中各數(shù)據(jù)項(xiàng)的分析,本文將傳感器類型作為topic的劃分標(biāo)準(zhǔn)。topic的命名方案如表2所示。
表2 Topic規(guī)劃表
根據(jù)表1所示傳感器數(shù)據(jù)格式,DDS數(shù)據(jù)類型的IDL定義如下:
OpenDDS執(zhí)行一種獨(dú)立式的服務(wù),叫做DCPSInfoRepo,以便發(fā)布者和訂閱者以集中式發(fā)現(xiàn)彼此,它作為一個(gè)CORBA服務(wù)器進(jìn)行實(shí)現(xiàn)。DCPSInfoRepo運(yùn)行方式如下:
DCPSInfoRepo-ORBListenEndpoints iiop://localhost:12345-d domain_id
-ORBListenEndpoint iiop://localhost:12345 指定注冊服務(wù)器監(jiān)聽注冊信息的地址和端口。
-d domain_id指定注冊服務(wù)器工作的域。
傳感器代理使用發(fā)布服務(wù)實(shí)現(xiàn)傳感器數(shù)據(jù)分發(fā),首先創(chuàng)建participant實(shí)體和Publisher實(shí)體,然后Publisher實(shí)體根據(jù)發(fā)布條件創(chuàng)建Topic,最后創(chuàng)建與Topic對應(yīng)的Datawriter。為簡單起見,所有實(shí)體均采用默認(rèn)的QoS策略。
至此生成了所有需要通過注冊線程向服務(wù)器注冊的實(shí)體。
用戶終端代理使用訂閱服務(wù)實(shí)現(xiàn)傳感器數(shù)據(jù)的訂閱,首先創(chuàng)建participant實(shí)體和Subscriber實(shí)體,然后根據(jù)訂閱條件創(chuàng)建設(shè)置Topic,最后創(chuàng)建與Topic對應(yīng)的Datareader。訂閱端各實(shí)體的實(shí)現(xiàn)方式與發(fā)布端類似,具體代碼不再贅述。
本文的應(yīng)用情形設(shè)計(jì)如下:發(fā)布端發(fā)布兩種主題,一種是目標(biāo)信息主題,另一種是雷達(dá)狀態(tài)主題,包括雷達(dá)開機(jī)(RADAR_OPENED)和雷達(dá)關(guān)機(jī)(RADAR_CLOSED)事件。訂閱端同時(shí)訂閱兩種主題,并實(shí)時(shí)打印接收到的目標(biāo)信息。當(dāng)訂閱者收到雷達(dá)關(guān)機(jī)事件時(shí),將停止接收雷達(dá)數(shù)據(jù)。
要運(yùn)行這個(gè)程序,必須先啟動(dòng)DCPSInfoRepo進(jìn)程,運(yùn)行方法見4.3節(jié)。
運(yùn)行訂閱者和發(fā)布者方法如下:
subscriber-DCPSConfigFile dds_tcp_conf.ini
publisher-DCPSConfigFile dds_tcp_conf.ini其中配置文件dds_tcp_conf.ini指定訂閱者和發(fā)布者的注冊服務(wù)器和數(shù)據(jù)傳輸協(xié)議等。
程序運(yùn)行結(jié)果如圖4所示。
圖4 訂閱端
DDS標(biāo)準(zhǔn)提出了以數(shù)據(jù)為中心的設(shè)計(jì)思想和技術(shù)規(guī)范,被歐美等國大量運(yùn)用于民航、國防等諸多領(lǐng)域,且已形成相對完善的商業(yè)產(chǎn)品。將DDS技術(shù)應(yīng)用于傳感器數(shù)據(jù)分發(fā)系統(tǒng),可以很好地滿足戰(zhàn)場數(shù)據(jù)對實(shí)時(shí)性、可靠性和靈活性的要求,實(shí)現(xiàn)數(shù)據(jù)的按需分發(fā),有效地減少了網(wǎng)絡(luò)負(fù)載。目前國內(nèi)DDS的相關(guān)研究和應(yīng)用范圍還非常有限,應(yīng)加強(qiáng)該技術(shù)的研究,拓寬應(yīng)用范圍。