基于事件通知服務的雷達產品生成系統的數據分發改進

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

(1.成都信息工程學院,四川成都610225;2.中國氣象科學研究院災害天氣國家重點實驗室,北京100081)

0 引言

圖1是雙偏振雷達數據處理軟件系統,包括雷達產品生成系統和產品顯示系統。

分布式雷達產品生成[1-2]軟件是一個由大量雷達氣象算法任務組成的軟件系統,包括復雜的計算任務,復雜的控制流和數據流,并且實時性要求高,是一個兼有計算密集和IO密集的系統。系統主要以后臺復雜氣象算法數據處理為核心,輔以簡單的用戶控制界面。每個算法任務定義為一個CORBA對象,作為獨立進程運行,任務間通過COBRA的事件通道傳輸數據,包括中間數據和最終產品。

事件通道[3]將所有的基本數據發送給所有的消費者任務子模塊,每一個消費者任務子模塊接收連接到同一個事件通道的提供者發來的所有的基本數據。事件通道將所有的基本數據發送給所有消費者任務子模塊是對系統資源的一種浪費,因為很多消費者任務子模塊會將大部分接收到的無關的基本數據進行丟棄(通道發送大量與接收任務無關的數據之前被迫存儲一些基本數據并占用時間來連接發送)。這樣將導致在通道和其接收任務模塊之間有大量不必要的數據事件通信。每一種類型的數據通道只能處理一種類型的數據,使用多個事件數據類型需要多個事件通道,事件在獨立的事件通道上是相同的(代碼必須由消費者任務子模塊寫不同的處理這些數據事件),CPU必須花費時間判斷和丟棄不需要事件,影響消費者任務的執行效率。使用ANY類型的數據在通道中無法進行分析,只有接收者任務接收到數據以后轉換成一般類型結構后才可以處理,這對通道內部復雜職能的實現造成了困難。

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

圖1 X波段雙偏振雷達數據處理系統結構圖

1 通知服務、多線程技術和并行計算在雷達產品生成系統的應用

1.1 CORBA通知服務[4]技術原理

這部分簡單的描述核心部件的結構在標準CORBA通知服務。論文中,這些核心部件構成分布式雷達產品生成系統的數據流的基礎。

通知服務的體系結構如下:(1)通知發送者和通知接收者;(2)事件傳送模式;(3)事件通道;(4)供應者管理器和消費者管理器;(5)服務質量和過濾。

1.1.1 事件通道

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

1.1.2 過濾機制

過濾器[6]允許消費者任務訂閱特定的事件,CORBA通知服務中有兩種過濾機制,一種是普通過濾機制,另一種是映射過濾機制。分布式RPG系統主要使用的是普通過濾機制,普通過濾機制決定事件是否前轉,映射過濾機制不決定事件能否前轉,普通的過濾機制的一個過濾對象包含多個約束,每一個約束有兩部分組成:前一部分是事件類型的序列,給出了約束所適應的事件類型,后一部分是一個使用特定語法的布爾表達式字符串,給出了約束的內容。代理對象調用與其關聯的過濾器對象合適的match(匹配)操作決定是否是用戶希望得到的事件。具體來說一個代理對象可能會關聯多個過濾器對象,這些過濾器對象之間的關系直接影響到事件的轉發策略,通知服務規定它們之間的關系是邏輯與的關系。也就是說只要一個匹配為真代理就轉發這個事件,只有當所有的匹配為假,代理才會丟棄數據事件,通知服務的管理(admin)接口也可以關聯一組過濾器對象,這是因為它和代理接口一樣都繼承了CosNotifyFilter::FilterAdmin接口。

1.1.3 結構化事件

結構化事件[6-7]提供了良好定義的一個標準數據結構,可以映射到更多的數據類型,事件消息能存儲在這個結構事件中。在通知服務中明確定義了處理結構化事件的接口,這樣操作結構化事件算法就可以得到優化。結構化事件的格式包括事件頭和事件體,事件頭又分為固定域和變長域。事件體又分為可過濾部分和剩余部分。CORBA結構化事件吸收了無類型事件的通用和易用的特點,而且引入了一定的類型約束的機制[8]。數據事件消費者任務可以使用結構化事件給通道代理添加過濾條件,以說明數據事件是希望得到的。

1.2 多線程和OpenMP在TaskProdForecasts的應用

為了不讓負載過重的任務阻塞通道,文中應用多線程技術。接收數據和處理數據分解成兩個線程處理,避免阻塞通道的目的(避免了該任務影響整個系統的運行情況),從而提高系統的可響應性。

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

表1 在雙核CPU加速比

表1使用OpenMp和未使用OpenMp的比較性能注意事項:擁有正確且可執行的OpenMp程序之后,應該考慮其整體性能。可以利用一些常規技術和Sun平臺專有技術改善OpenMp應用程序的效率和可伸縮性。

1.3 采用過濾機制對系統數據分發進行改進

消費者任務子模塊給通道上的代理添加過濾條件,消費者任務子模塊把希望得到的數據以過濾條件的形式包裝在過濾對象中,然后把過濾對象和代理對象關聯起來。增加了任務子模塊間通信的智能性。使用過濾器訂閱特定基本數據事件代碼片段示例:

實驗證明,在通知服務4種數據傳輸模式中,Push-Push的效率最高,可靠性最好,系統也選用該模式。

數據接收代碼示例如下,任務子模塊首先需要從希望得到的結構化數據中提取事件數據。

采用了過濾機制的分布式雷達產品生成系統的優點是:

(1)按需發送數據事件

雷達觀測數據有回波強度、徑向速度、速度譜寬及偏振參量等多種基數據,不同產品、算法子任務需要輸入的基數據不盡相同,按需發送數據后,產品算法接收任務子模塊不會接收到大量無關的數據。通道和其接收任務模塊之間不存在大量不必要的數據事件通信。

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

使用CORBA通知服務可以減少通道的數目。系統的數據流是動態變化的。用戶可以動態增加或者刪除任務,從而極大的提高了系統的靈活性和擴展性,實現“即插即用”。

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

消費者任務子模塊可以給通道代理添加過濾條件,使用過濾器結合訂閱來精確的接收希望得到的基本數據事件。忽略判斷丟棄等等細節。

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

借助CORBA的成熟的標準,任務模塊間可以可靠的數據事件傳送,忽略重傳等等細節。數據事件實時傳輸的測試實驗中表明:所有數據均正常傳送,未出現數據丟失的現象。系統在處理數據量大的雙線偏振雷達數據時,仍能實時、穩定運行,具備與雷達掃描同步運轉的能力。

系統也具有檢測錯誤以及可以在任務子模塊發生和已經發生的錯誤中恢復的能力。某個任務模塊出錯對其他的任務模塊不會造成影響,系統照樣可以正常工作,不會因為一個模塊的錯誤或停止而造成整個產品生成系統的崩潰。當異常發生時,系統將會檢測到哪個任務子模塊發生異常,并將此異常任務退出,系統仍能正常工作。

(5)改善整個系統的數據處理效率

圖2顯示基于事件和通知服務的雷達產品生成系統每個體掃總的運行時間的對比。

圖2 總的運行時間對比

2 采用了過濾機制的分布式雷達產品生成系統的架構

整個雷達產品生成系統分成3層:基數據讀取層、產品生成層和和產品發布層。系統的各個任務子模塊定義統一的IDL接口,雷達產品生成系統監控界面通過接口進行任務控制,獲取和設置算法參數等。算法參數任務IDL接口定義如下:

interface Task:CosNotifyComm::StructuredPushConsumer{

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

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

oneway void ExecCmd(in Command cmd);

//修改任務運行狀態

void CheckStatus();

//系統監控界面定時查詢任務運行狀態

void get-status(out TaskStatus st);

//獲取任務運行狀態

};

通過命名服務獲取任務對象引用。任務的管理和任務間交互不需要知道任務的具體位置,只根據名字就可以獲取對象引用,實現了網絡的透明。算法任務名和對象引用的綁定通過命名服務。

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

其采用了過濾機制的基于CORBA通知服務的雷達產品生成系統架構如圖3所示。

TaskProductVCS,TaskTempCappi,TaskProdCldId,TaskProdForcast,TaskWeatherMod任務子模塊以及發布產品任務模塊TaskProdDistrib也是要和通道TaskStatusChance進行通信。

基于通知服務的雷達產品生成系統主要工作步驟如下:

(1)TaskDetectData任務遍歷指定的各個文件路徑的基數據文件,將文件名存儲到待處理文件列表中,接著讀取雷達基數據文件進行質量控制及統一格式化處理。然后將處理后的結果推到CommonPPIDataChannel數據通道上。

(2)注冊為CommonPPIDataChannel通道上的消費者任務將會被回調push-structured-event()如果這個基本數據事件滿足消費者任務設置的過濾條件(代理對象調用與其關聯的過濾器對象合適的match(匹配)操作決定是否是用戶希望得到的事件);從該通道上獲取一個結構化類型的事件,然后經過一系列的氣象算法,生成氣象產品或者中間產品。最后將處理的結果(產品)推到ProductDataChannel通道中。或者(中間產品)推到通道TempPpiDataChannel中。

(3)注冊為ProductDataChannel通道的消費者任務TaskProdDistrit將收到所有的產品數據(該任務不使用過濾器),然后分發給有請求該產品的連接的客戶端(PUP)。預報用戶使用PUP對氣象產品分析,進行研究和預報等工作。

圖3 基于通知服務的分布式雷達產品生成系統架構圖

這樣就完成了分布式處理大計算量任務的工作。系統充分利用了計算機的處理能力,由通知通道進行統一調度和管理。使用3個事件通道保證不同的事件之間不會相互影響,從而保證了通道的質量和系統的效率。通知服務實現保護提供者不受異常的影響。

3 結束語

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

[1] 楊愛軍,王紅艷,分布式雷達產品生成系統設計[J].山東農業大學學報(自然科學版),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] 鄭先容,陳強.CORBA構件模型的通告服務集成研究與實現[J].計算機應用研究,1996:104-113.

[6] 彭宏,韓仲平.基于CORBA的非耦合異步多點通訊[J].計算機工程與應用,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.