甘 兵, 朱 毅, 王紅艷, 劉黎平

(1.成都信息工程學(xué)院,四川成都610225;2.中國(guó)氣象科學(xué)研究院災(zāi)害天氣國(guó)家重點(diǎn)實(shí)驗(yàn)室,北京100081)

0 引言

圖1是雙偏振雷達(dá)數(shù)據(jù)處理軟件系統(tǒng),包括雷達(dá)產(chǎn)品生成系統(tǒng)和產(chǎn)品顯示系統(tǒng)。

分布式雷達(dá)產(chǎn)品生成[1-2]軟件是一個(gè)由大量雷達(dá)氣象算法任務(wù)組成的軟件系統(tǒng),包括復(fù)雜的計(jì)算任務(wù),復(fù)雜的控制流和數(shù)據(jù)流,并且實(shí)時(shí)性要求高,是一個(gè)兼有計(jì)算密集和IO密集的系統(tǒng)。系統(tǒng)主要以后臺(tái)復(fù)雜氣象算法數(shù)據(jù)處理為核心,輔以簡(jiǎn)單的用戶控制界面。每個(gè)算法任務(wù)定義為一個(gè)CORBA對(duì)象,作為獨(dú)立進(jìn)程運(yùn)行,任務(wù)間通過(guò)COBRA的事件通道傳輸數(shù)據(jù),包括中間數(shù)據(jù)和最終產(chǎn)品。

事件通道[3]將所有的基本數(shù)據(jù)發(fā)送給所有的消費(fèi)者任務(wù)子模塊,每一個(gè)消費(fèi)者任務(wù)子模塊接收連接到同一個(gè)事件通道的提供者發(fā)來(lái)的所有的基本數(shù)據(jù)。事件通道將所有的基本數(shù)據(jù)發(fā)送給所有消費(fèi)者任務(wù)子模塊是對(duì)系統(tǒng)資源的一種浪費(fèi),因?yàn)楹芏嘞M(fèi)者任務(wù)子模塊會(huì)將大部分接收到的無(wú)關(guān)的基本數(shù)據(jù)進(jìn)行丟棄(通道發(fā)送大量與接收任務(wù)無(wú)關(guān)的數(shù)據(jù)之前被迫存儲(chǔ)一些基本數(shù)據(jù)并占用時(shí)間來(lái)連接發(fā)送)。這樣將導(dǎo)致在通道和其接收任務(wù)模塊之間有大量不必要的數(shù)據(jù)事件通信。每一種類型的數(shù)據(jù)通道只能處理一種類型的數(shù)據(jù),使用多個(gè)事件數(shù)據(jù)類型需要多個(gè)事件通道,事件在獨(dú)立的事件通道上是相同的(代碼必須由消費(fèi)者任務(wù)子模塊寫(xiě)不同的處理這些數(shù)據(jù)事件),CPU必須花費(fèi)時(shí)間判斷和丟棄不需要事件,影響消費(fèi)者任務(wù)的執(zhí)行效率。使用ANY類型的數(shù)據(jù)在通道中無(wú)法進(jìn)行分析,只有接收者任務(wù)接收到數(shù)據(jù)以后轉(zhuǎn)換成一般類型結(jié)構(gòu)后才可以處理,這對(duì)通道內(nèi)部復(fù)雜職能的實(shí)現(xiàn)造成了困難。

針對(duì)以上的不足,需要對(duì)通道進(jìn)行改進(jìn),增加任務(wù)模塊間通信的智能性,事件通道需要對(duì)發(fā)送給所有的消費(fèi)者任務(wù)子模塊的數(shù)據(jù)事件做一些過(guò)濾操作(對(duì)從提供者發(fā)給接收任務(wù)模塊的數(shù)據(jù)事件進(jìn)行解釋),這樣接收任務(wù)子模塊就不會(huì)接收到大量無(wú)關(guān)數(shù)據(jù)。

圖1 X波段雙偏振雷達(dá)數(shù)據(jù)處理系統(tǒng)結(jié)構(gòu)圖

1 通知服務(wù)、多線程技術(shù)和并行計(jì)算在雷達(dá)產(chǎn)品生成系統(tǒng)的應(yīng)用

1.1 CORBA通知服務(wù)[4]技術(shù)原理

這部分簡(jiǎn)單的描述核心部件的結(jié)構(gòu)在標(biāo)準(zhǔn)CORBA通知服務(wù)。論文中,這些核心部件構(gòu)成分布式雷達(dá)產(chǎn)品生成系統(tǒng)的數(shù)據(jù)流的基礎(chǔ)。

通知服務(wù)的體系結(jié)構(gòu)如下:(1)通知發(fā)送者和通知接收者;(2)事件傳送模式;(3)事件通道;(4)供應(yīng)者管理器和消費(fèi)者管理器;(5)服務(wù)質(zhì)量和過(guò)濾。

1.1.1 事件通道

在客戶和服務(wù)器之間加入事件通道,用CORBA通知服務(wù)實(shí)現(xiàn)事件信息的傳遞。事件通道使事件的提供者和消費(fèi)者關(guān)系變得松散,無(wú)需相互了解對(duì)方,而只是同事件通道通信,這也適應(yīng)了現(xiàn)在異構(gòu)環(huán)境的發(fā)展。事件對(duì)于提供方來(lái)說(shuō)擔(dān)任消費(fèi)者的角色,而對(duì)消費(fèi)方來(lái)說(shuō)擔(dān)當(dāng)了提供者的角色,這兩種角色都是有相關(guān)的接口完成。在通信過(guò)程中事件通道在提供方創(chuàng)建一個(gè)提供方管理器(SupplierAdmin),再由提供方管理器為本地提供方創(chuàng)建一個(gè)消費(fèi)者代理(ProxyConsumer);同樣在消費(fèi)方創(chuàng)建一個(gè)消費(fèi)方管理器(ConsumerAdmin),再由消費(fèi)方管理器為本地消費(fèi)方創(chuàng)建一個(gè)供應(yīng)者代理(ProvySupplier)。CORBA通知服務(wù)使事件通道中可以傳遞結(jié)構(gòu)化事件,此事件可以進(jìn)行過(guò)濾等優(yōu)化操作[5]。在事件的傳遞過(guò)程中,消費(fèi)者任務(wù)子模塊依照一定語(yǔ)法,描述過(guò)濾條件,形成過(guò)濾對(duì)象,可對(duì)事件提供者提供的事件和事件消費(fèi)者接收的事件進(jìn)行過(guò)濾,避免消費(fèi)者接收自己不希望得到的數(shù)據(jù)事件。消費(fèi)者類繼承自org.omg.CosNotifyComm.StructuredPushConsumer類中接口push-structured-event(),并實(shí)現(xiàn)該接口。當(dāng)有數(shù)據(jù)從事件通道上傳遞過(guò)來(lái)時(shí),可以通過(guò)該接口實(shí)現(xiàn)數(shù)據(jù)的接收和處理。

1.1.2 過(guò)濾機(jī)制

過(guò)濾器[6]允許消費(fèi)者任務(wù)訂閱特定的事件,CORBA通知服務(wù)中有兩種過(guò)濾機(jī)制,一種是普通過(guò)濾機(jī)制,另一種是映射過(guò)濾機(jī)制。分布式RPG系統(tǒng)主要使用的是普通過(guò)濾機(jī)制,普通過(guò)濾機(jī)制決定事件是否前轉(zhuǎn),映射過(guò)濾機(jī)制不決定事件能否前轉(zhuǎn),普通的過(guò)濾機(jī)制的一個(gè)過(guò)濾對(duì)象包含多個(gè)約束,每一個(gè)約束有兩部分組成:前一部分是事件類型的序列,給出了約束所適應(yīng)的事件類型,后一部分是一個(gè)使用特定語(yǔ)法的布爾表達(dá)式字符串,給出了約束的內(nèi)容。代理對(duì)象調(diào)用與其關(guān)聯(lián)的過(guò)濾器對(duì)象合適的match(匹配)操作決定是否是用戶希望得到的事件。具體來(lái)說(shuō)一個(gè)代理對(duì)象可能會(huì)關(guān)聯(lián)多個(gè)過(guò)濾器對(duì)象,這些過(guò)濾器對(duì)象之間的關(guān)系直接影響到事件的轉(zhuǎn)發(fā)策略,通知服務(wù)規(guī)定它們之間的關(guān)系是邏輯與的關(guān)系。也就是說(shuō)只要一個(gè)匹配為真代理就轉(zhuǎn)發(fā)這個(gè)事件,只有當(dāng)所有的匹配為假,代理才會(huì)丟棄數(shù)據(jù)事件,通知服務(wù)的管理(admin)接口也可以關(guān)聯(lián)一組過(guò)濾器對(duì)象,這是因?yàn)樗痛斫涌谝粯佣祭^承了CosNotifyFilter::FilterAdmin接口。

1.1.3 結(jié)構(gòu)化事件

結(jié)構(gòu)化事件[6-7]提供了良好定義的一個(gè)標(biāo)準(zhǔn)數(shù)據(jù)結(jié)構(gòu),可以映射到更多的數(shù)據(jù)類型,事件消息能存儲(chǔ)在這個(gè)結(jié)構(gòu)事件中。在通知服務(wù)中明確定義了處理結(jié)構(gòu)化事件的接口,這樣操作結(jié)構(gòu)化事件算法就可以得到優(yōu)化。結(jié)構(gòu)化事件的格式包括事件頭和事件體,事件頭又分為固定域和變長(zhǎng)域。事件體又分為可過(guò)濾部分和剩余部分。CORBA結(jié)構(gòu)化事件吸收了無(wú)類型事件的通用和易用的特點(diǎn),而且引入了一定的類型約束的機(jī)制[8]。數(shù)據(jù)事件消費(fèi)者任務(wù)可以使用結(jié)構(gòu)化事件給通道代理添加過(guò)濾條件,以說(shuō)明數(shù)據(jù)事件是希望得到的。

1.2 多線程和OpenMP在TaskProdForecasts的應(yīng)用

為了不讓負(fù)載過(guò)重的任務(wù)阻塞通道,文中應(yīng)用多線程技術(shù)。接收數(shù)據(jù)和處理數(shù)據(jù)分解成兩個(gè)線程處理,避免阻塞通道的目的(避免了該任務(wù)影響整個(gè)系統(tǒng)的運(yùn)行情況),從而提高系統(tǒng)的可響應(yīng)性。

OpenMp[9]是一個(gè)并行程序的標(biāo)準(zhǔn)在共享內(nèi)存的環(huán)境里。提供一系列語(yǔ)法給編程者,很容易并行化代碼,程序員可以使用OpenMp提供的一系列語(yǔ)法并行化代碼。如在T REC算法中使用OpenMp后,CPU的最大使用率達(dá)到99%,充分使用了計(jì)算機(jī)的運(yùn)算能力,提高了多核CPU的利用率。在雙核CPU加速比如表1所示。

表1 在雙核CPU加速比

表1使用OpenMp和未使用OpenMp的比較性能注意事項(xiàng):擁有正確且可執(zhí)行的OpenMp程序之后,應(yīng)該考慮其整體性能?？梢岳靡恍┏Ｒ?guī)技術(shù)和Sun平臺(tái)專有技術(shù)改善OpenMp應(yīng)用程序的效率和可伸縮性。

1.3 采用過(guò)濾機(jī)制對(duì)系統(tǒng)數(shù)據(jù)分發(fā)進(jìn)行改進(jìn)

消費(fèi)者任務(wù)子模塊給通道上的代理添加過(guò)濾條件,消費(fèi)者任務(wù)子模塊把希望得到的數(shù)據(jù)以過(guò)濾條件的形式包裝在過(guò)濾對(duì)象中,然后把過(guò)濾對(duì)象和代理對(duì)象關(guān)聯(lián)起來(lái)。增加了任務(wù)子模塊間通信的智能性。使用過(guò)濾器訂閱特定基本數(shù)據(jù)事件代碼片段示例:

實(shí)驗(yàn)證明,在通知服務(wù)4種數(shù)據(jù)傳輸模式中,Push-Push的效率最高,可靠性最好,系統(tǒng)也選用該模式。

數(shù)據(jù)接收代碼示例如下,任務(wù)子模塊首先需要從希望得到的結(jié)構(gòu)化數(shù)據(jù)中提取事件數(shù)據(jù)。

采用了過(guò)濾機(jī)制的分布式雷達(dá)產(chǎn)品生成系統(tǒng)的優(yōu)點(diǎn)是:

(1)按需發(fā)送數(shù)據(jù)事件

雷達(dá)觀測(cè)數(shù)據(jù)有回波強(qiáng)度、徑向速度、速度譜寬及偏振參量等多種基數(shù)據(jù),不同產(chǎn)品、算法子任務(wù)需要輸入的基數(shù)據(jù)不盡相同,按需發(fā)送數(shù)據(jù)后,產(chǎn)品算法接收任務(wù)子模塊不會(huì)接收到大量無(wú)關(guān)的數(shù)據(jù)。通道和其接收任務(wù)模塊之間不存在大量不必要的數(shù)據(jù)事件通信。

(2)良好的靈活性和可擴(kuò)展性

使用CORBA通知服務(wù)可以減少通道的數(shù)目。系統(tǒng)的數(shù)據(jù)流是動(dòng)態(tài)變化的。用戶可以動(dòng)態(tài)增加或者刪除任務(wù),從而極大的提高了系統(tǒng)的靈活性和擴(kuò)展性,實(shí)現(xiàn)“即插即用”。

(3)不同任務(wù)子模塊良好的交互性

消費(fèi)者任務(wù)子模塊可以給通道代理添加過(guò)濾條件,使用過(guò)濾器結(jié)合訂閱來(lái)精確的接收希望得到的基本數(shù)據(jù)事件。忽略判斷丟棄等等細(xì)節(jié)。

(4)良好的可靠性和容錯(cuò)性

借助CORBA的成熟的標(biāo)準(zhǔn),任務(wù)模塊間可以可靠的數(shù)據(jù)事件傳送,忽略重傳等等細(xì)節(jié)。數(shù)據(jù)事件實(shí)時(shí)傳輸?shù)臏y(cè)試實(shí)驗(yàn)中表明:所有數(shù)據(jù)均正常傳送,未出現(xiàn)數(shù)據(jù)丟失的現(xiàn)象。系統(tǒng)在處理數(shù)據(jù)量大的雙線偏振雷達(dá)數(shù)據(jù)時(shí),仍能實(shí)時(shí)、穩(wěn)定運(yùn)行,具備與雷達(dá)掃描同步運(yùn)轉(zhuǎn)的能力。

系統(tǒng)也具有檢測(cè)錯(cuò)誤以及可以在任務(wù)子模塊發(fā)生和已經(jīng)發(fā)生的錯(cuò)誤中恢復(fù)的能力。某個(gè)任務(wù)模塊出錯(cuò)對(duì)其他的任務(wù)模塊不會(huì)造成影響,系統(tǒng)照樣可以正常工作,不會(huì)因?yàn)橐粋€(gè)模塊的錯(cuò)誤或停止而造成整個(gè)產(chǎn)品生成系統(tǒng)的崩潰。當(dāng)異常發(fā)生時(shí),系統(tǒng)將會(huì)檢測(cè)到哪個(gè)任務(wù)子模塊發(fā)生異常,并將此異常任務(wù)退出,系統(tǒng)仍能正常工作。

(5)改善整個(gè)系統(tǒng)的數(shù)據(jù)處理效率

圖2顯示基于事件和通知服務(wù)的雷達(dá)產(chǎn)品生成系統(tǒng)每個(gè)體掃總的運(yùn)行時(shí)間的對(duì)比。

圖2 總的運(yùn)行時(shí)間對(duì)比

2 采用了過(guò)濾機(jī)制的分布式雷達(dá)產(chǎn)品生成系統(tǒng)的架構(gòu)

整個(gè)雷達(dá)產(chǎn)品生成系統(tǒng)分成3層:基數(shù)據(jù)讀取層、產(chǎn)品生成層和和產(chǎn)品發(fā)布層。系統(tǒng)的各個(gè)任務(wù)子模塊定義統(tǒng)一的IDL接口,雷達(dá)產(chǎn)品生成系統(tǒng)監(jiān)控界面通過(guò)接口進(jìn)行任務(wù)控制,獲取和設(shè)置算法參數(shù)等。算法參數(shù)任務(wù)IDL接口定義如下:

interface Task:CosNotifyComm::StructuredPushConsumer{

void GetTaskAlgParams(out ParamSeq params);//獲取任務(wù)算法參數(shù)

void SetTaskAlgParams(in ParamSeq params);//設(shè)置任務(wù)算法參數(shù)

oneway void ExecCmd(in Command cmd);

//修改任務(wù)運(yùn)行狀態(tài)

void CheckStatus();

//系統(tǒng)監(jiān)控界面定時(shí)查詢?nèi)蝿?wù)運(yùn)行狀態(tài)

void get-status(out TaskStatus st);

//獲取任務(wù)運(yùn)行狀態(tài)

};

通過(guò)命名服務(wù)獲取任務(wù)對(duì)象引用。任務(wù)的管理和任務(wù)間交互不需要知道任務(wù)的具體位置,只根據(jù)名字就可以獲取對(duì)象引用,實(shí)現(xiàn)了網(wǎng)絡(luò)的透明。算法任務(wù)名和對(duì)象引用的綁定通過(guò)命名服務(wù)。

template＜class T＞void BindTaskName(const CosNaming::NamingContext-var&naming-context,

T*taskptr){

CosNaming::Name name(1);

name.length(1);

name[0].id=CORBA::string-dup(″DRPG″);

try

naming-context-＞bind-new-context(name);

catch(const CosNaming::NamingContext::AlreadyBound&)

goto ok;

catch(CORBA::Exception&e){

cerr＜＜″CORBA exception raised!″＜＜e＜＜endl;

return;

}

ok:

name.length(2);

name[0].id=CORBA::string-dup(″DRPG″);

name[1].id=

CORBA::string-dup(taskptr-＞get-task-name());

//binding tasks'name by naming service

naming-context-＞rebind(name,taskptr-＞-this());

}//get-task-name();used to get tasks'name

其采用了過(guò)濾機(jī)制的基于CORBA通知服務(wù)的雷達(dá)產(chǎn)品生成系統(tǒng)架構(gòu)如圖3所示。

TaskProductVCS,TaskTempCappi,TaskProdCldId,TaskProdForcast,TaskWeatherMod任務(wù)子模塊以及發(fā)布產(chǎn)品任務(wù)模塊TaskProdDistrib也是要和通道TaskStatusChance進(jìn)行通信。

基于通知服務(wù)的雷達(dá)產(chǎn)品生成系統(tǒng)主要工作步驟如下:

(1)TaskDetectData任務(wù)遍歷指定的各個(gè)文件路徑的基數(shù)據(jù)文件,將文件名存儲(chǔ)到待處理文件列表中,接著讀取雷達(dá)基數(shù)據(jù)文件進(jìn)行質(zhì)量控制及統(tǒng)一格式化處理。然后將處理后的結(jié)果推到CommonPPIDataChannel數(shù)據(jù)通道上。

(2)注冊(cè)為CommonPPIDataChannel通道上的消費(fèi)者任務(wù)將會(huì)被回調(diào)push-structured-event()如果這個(gè)基本數(shù)據(jù)事件滿足消費(fèi)者任務(wù)設(shè)置的過(guò)濾條件(代理對(duì)象調(diào)用與其關(guān)聯(lián)的過(guò)濾器對(duì)象合適的match(匹配)操作決定是否是用戶希望得到的事件);從該通道上獲取一個(gè)結(jié)構(gòu)化類型的事件,然后經(jīng)過(guò)一系列的氣象算法,生成氣象產(chǎn)品或者中間產(chǎn)品。最后將處理的結(jié)果(產(chǎn)品)推到ProductDataChannel通道中?；蛘?中間產(chǎn)品)推到通道TempPpiDataChannel中。

(3)注冊(cè)為ProductDataChannel通道的消費(fèi)者任務(wù)TaskProdDistrit將收到所有的產(chǎn)品數(shù)據(jù)(該任務(wù)不使用過(guò)濾器),然后分發(fā)給有請(qǐng)求該產(chǎn)品的連接的客戶端(PUP)。預(yù)報(bào)用戶使用PUP對(duì)氣象產(chǎn)品分析,進(jìn)行研究和預(yù)報(bào)等工作。

圖3 基于通知服務(wù)的分布式雷達(dá)產(chǎn)品生成系統(tǒng)架構(gòu)圖

這樣就完成了分布式處理大計(jì)算量任務(wù)的工作。系統(tǒng)充分利用了計(jì)算機(jī)的處理能力,由通知通道進(jìn)行統(tǒng)一調(diào)度和管理。使用3個(gè)事件通道保證不同的事件之間不會(huì)相互影響,從而保證了通道的質(zhì)量和系統(tǒng)的效率。通知服務(wù)實(shí)現(xiàn)保護(hù)提供者不受異常的影響。

3 結(jié)束語(yǔ)

重點(diǎn)討論了應(yīng)用CORBA通知服務(wù)為任務(wù)子模塊提供高效、可靠、靈活的數(shù)據(jù)傳送,提高任務(wù)子模塊間交互性,并可以使該系統(tǒng)獲取良好的擴(kuò)展性。并行計(jì)算和多線程技術(shù)在TaskProdForecasts的應(yīng)用可以改善通道的阻塞情況并且提高多核CPU利用率。CORBA通知服務(wù)在分布式雷達(dá)產(chǎn)品生成系統(tǒng)應(yīng)用方面的實(shí)際應(yīng)用中具有推廣的價(jià)值。

[1] 楊愛(ài)軍,王紅艷,分布式雷達(dá)產(chǎn)品生成系統(tǒng)設(shè)計(jì)[J].山東農(nóng)業(yè)大學(xué)學(xué)報(bào)(自然科學(xué)版),2011,42(4):543-545.

[2] Zabrai A,Zhongqi Jing.A distributed architecture for the WSR-88D(NEXRAD)radar productgenerator(RPG)[C].Aerospace and Electronics Conference,Proceedings of the IEEE 1997 National,1997,1:302-307.

[3] Miehi,Henning.Steve V'moski.Advanced CORBA Programming with C++[M].Addison-wesley,1999.

[4] Object Management Group.CORBAservices:Common Object Services Specification[EB/OL].http://www.omg.org1997-07-04.

[5] 鄭先容,陳強(qiáng).CORBA構(gòu)件模型的通告服務(wù)集成研究與實(shí)現(xiàn)[J].計(jì)算機(jī)應(yīng)用研究,1996:104-113.

[6] 彭宏,韓仲平.基于CORBA的非耦合異步多點(diǎn)通訊[J].計(jì)算機(jī)工程與應(yīng)用,2000,36(7):47-50,70.

[7] Object Management Group.Notification Service Specification[S].OMG Document telecom,1999.

[8] Pradeep Gore,Ron Cytron.Designing and Optimizing a Scalable CORBA Notification Service[M].2006.

[9] Kang Su Gatlin,Pete Isensee.OpenMP and C++[EB/OL].http://www.viva64.com/go.php?url=113.