基于軟總線的電子靶場測控體系架構研究

2011-03-13 06:11:32張焱周文碩趙華敏

中國傳媒大學學報(自然科學版) 2011年2期

張焱，周文碩，趙華敏

(1.西安電子科技大學，陜西西安 710071;2.中國電子科技集團公司第54研究所，河北石家莊 050081)

1 引言

電子靶場作為現代戰爭仿真試驗基地，在電子戰裝備采辦、戰術應用研究和操作人員訓練中具有不可替代的重要作用，是確保作戰部隊獲得高效可靠的電子作戰裝備、有效運用電子戰戰術和提高部隊生存能力的堅強保障。當前，電子戰已經由以往單一設備，單項領域的對抗，發展為系統對系統、體系對體系的綜合較量。為適應這種變化，電子靶場測控信息系統也應該走一條靈活擴展、隨需構建的道路，有效地管理各種資源，能夠按照測試的需要，靈活編排測試場景，有效地給出效能評估。這就要求現代武器的靶場測控系統具有一個開放式的、可實現設備擴展和功能更新的系統構架。

基于軟總線的體系結構具有可維護性好、可重用度高、擴展能力強及較強的通用性，并支持構件的“即插即用”和服務接口的動態配置，使目標系統具有良好的靈活性，在業務需求變化時，目標系統可快速重構進行適應。

本文介紹基于軟總線的電子靶場測控的架構設計，并參照該體系架構實現了原型系統。

2 電子靶場測控領域現狀

2.1 領域概況

電子靶場的目的是通過模擬出各種復雜的戰場電磁環境，并提供相應的評估技術，對武器及其配套的電子設備進行測試，客觀地、準確地評定現代武器裝備的作戰效能，對新研制的武器裝備系統進行合理全面的試驗鑒定。

從電子靶場系統組成上來看，主要包括監控計算機(含監控軟件)、測試設備(主要包括各種商用測試儀器)、模擬設備(包括各種干擾機等)、數據存儲設備(數據庫服務器等)、打印設備、配電及通信設備等。對于不同的應用需求，區別主要是測試和模擬設備的數量及種類多少問題。

從電子靶場的功能上來看，主要包括測試方案設計、設備控制、實時監視、自動測試、評估分析、數據管理及系統維護等幾大塊。

2.2 領域特征

通過對電子靶場測控領域進行分析，發現從整個靶場測控領域的應用模式來看系統需求和功能配置具有顯著的共性，同時不同的應用系統側重點又不盡相同。

它們的不同點體現在:系統的規模、結構不同，如體系結構級試驗，相對來說系統規模大、設備多、系統結構復雜;而對于單體設備級試驗，則相對規模較小、設備少、結構簡單。另外系統的測試內容及目標也不同，如雷達對抗、通信對抗以及光電對抗等。

它們的共性體現在:測控系統大部分功能模塊主要是通過對設備的控制，獲得各種測量數據，再基于不同的測試目的對測量數據進行相應的業務處理，并可對測量數據及結果進行保存，生成測試評估結果。還有一部分功能模塊是基于對數據庫存儲數據的分析、管理。

通過以上分析發現，電子靶場測控作為特定領域的應用，其業務方式和業務范圍相對比較規范、穩定，雖然隨著靶場測控技術的發展，會有一些新技術、新業務、新體制出現，但在業務流程及方式上基本上都是類似的，其應用模式具有非常大的相似性，這一點符合實施領域工程的前提，即領域特征的相對穩定性。基于靶場測控這一特定應用領域，完全可以建立一套合理、可行的關于軟件體系結構的解決方案，從而改變目前電子靶場測控系統軟件開發周期長、擴展能力差、維護困難等現實問題。

2.3 待解決問題

在進行新一代的電子靶場測控系統體系架構的設計時，需要解決以下幾個問題:

(1)電子靶場劇情控制、效能評估等系統與靶場的各種測試設備間的耦合問題，即實現各個業務系統、軟件或待測設備在空間、時間和傳輸協議解耦。如，在系統增加新的待測設備或者測控業務發生變化時，可以快速動態的響應，而不影響現有的系統或盡可能少的波及;

(2)分布在網絡環境中的大量專業化的業務處理服務的共享問題，即實現業務處理服務的跨語言和跨平臺的有效共享和接入，這樣電子靶場的測控范圍將不再局限在某一專業范圍，從而保證電子靶場測控平臺是一個具有通用性的平臺;

(3)應用軟件開發的重用性問題，即軟件代碼在共享代碼庫或對象的重用層次，提升到構件或服務層次進行重用，以提高大規模軟件系統開發的重用度，一方面減少新應用開發的投入，另一方面，也最大限度保護了前期應用系統投入;

(4)已有測控數據的重用問題，即通過建立武器裝備、電磁信號以及測試模型庫，可支持以全數字仿真的方式完成對武器裝備的測試，也可以通過調用模型庫的數據，支持實物或半實物電磁環境的產生和測試。

3 電子靶場測控平臺體系架構模型

通過分析抽象出三個基礎平臺作為電子靶場的支撐環境，即測控數據交互平臺、測控服務組裝平臺和可編程劇情控制平臺。這三個平臺，是電子靶場測控系統的基礎支撐平臺，是電子靶場測控系統的核心部件，具有內核穩定，對外易于擴展的特點。其設計原則遵循開放關閉原則(The Open Closed Principle，OCP)，即對擴展開放，對修改關閉，基于這三個平臺，能夠進一步研發各具特色的電子靶場測控應用。電子靶場測控平臺體系架構如圖1所示。

圖1 電子靶場測控平臺體系架構圖

這三個平臺共同組成了電子靶場測控的通用領域模型，或稱電子靶場測控的核心領域模型。

3.1 數據交互平臺

數據交互平臺，使電子靶場系統中的各個子系統、軟件或待測設備之間的通信松耦合，做到在空間、時間和傳輸協議解耦。

3.2 服務組裝平臺

服務組裝平臺，使分布在網絡環境中的大量專業化的業務處理服務實現跨語言、跨平臺的有效共享。

3.3 可編程劇情控制平臺

可編程劇情控制平臺，使在復雜多變的大規模的測控環境中，靈活機動的在測控模型和測控服務級重用，使得平臺能夠快速應對電子靶場靈活多變的測控場景。

4 電子靶場測控平臺原型系統

在體系架構研究的基礎之上，設計實現了測控平臺原型系統。

4.1 系統組成

原型系統是由開發平臺、監控平臺以及運行平臺組成。開發平臺負責實際劇情的可視化建模、以及對應服務構件組裝的生成。監控平臺在服務組裝部署運行后負責監控劇情的運行情況，并能夠實時的發送控制命令給某個特定的服務單元最終控制設備的運行狀態。運行平臺包括兩個部分:系統總線、設備代理。其中系統總線能夠提供規范化的消息交換和路由，提供服務構件生命周期管理和服務構件之間的組裝。設備代理是具體設備的抽象。原型系統的結構如圖2所示。

圖2 原型系統結構圖

為了提高開發效率，在原型系統中選用中創軟件商用中間件公司的中間件產品InforSIB和Infor-Bus共同構建核心基礎平臺。

InforSIB符合JBI規范，采用面向服務的體系架構、事件驅動的體系結構、提供即插即用的構件框架，是一個開放的基于構件的服務組裝和互操作平臺。原型系統中的開發平臺及運行平臺中的系統總線部分是基于InforSIB來實現的。

InforBus是一個遵循CORBA(Common Object Request Broker Architecture，公共對象請求代理結構)規范的分布式軟件計算平臺。原型系統中監控平臺、設備代理等與系統總線之間的交互均采用Corba方式實現。

4.2 業務流程

系統業務流程為電子靶場的相關管理人員確定所需要的劇情然后由技術人員實施。技術人員接收到劇情的需求后，使用開發平臺進行劇情的編排。不同的構件對應不同的屬性，用戶設置構件的屬性以及消息傳遞的關系后可以打包成服務組裝。處于運行狀態的服務組裝中的各個功能點在恰當的時機被調用，這是劇情控制的概念。每一個設備都有一個對應的設備代理，構件同設備代理通訊來控制和監視設備。

4.3 系統接口

原型系統總體接口關系如圖3所示。

圖3 原型系統接口關系圖

可以看到在業務層構件與構件之間的交互是通過系統總線，，我們稱之為系統控制總線。設備注冊消息和測控數據是通設備代理傳輸到JMS構件后，通過系統總線發送到監控構件，我們稱之為系統數據總線。應用層軟件和接入設備正是在控制總線和數據總線的共同作用下實現系統功能。下面對系統主要內部接口設計進行描述。

(1)模型庫與開發平臺間接口

模型庫采用XML標記語言描述各個構件模型。開發平臺讀取構件模型后提供用戶進行各種構件的服務組裝。

XML文檔由一系列元素構成，這些元素形成一種樹型的結構。一個XML元素是由開始標記、結束標記、以及標記之間的數據構成。開始和結束標記用來描述標記之間的數據。標記之間的數據被認為是元素的值。在XML中，沒有一定的標記，完全可以根據應用領域的需要來定義和使用標記。利用XML的上述特性，對模型進行結構化的表示。如下是用XML表示的某雷達設備模型相關數據片段，它清楚地描述了數據、對數據含義的說明、以及數據之間的相互關系。

〈equipment name=“XX雷達” package=“武器裝備庫”〉

〈recieves－ xml name=“inPort”/〉

〈function name=“開機”value=“雷達開始工作”〉

〈params〉

〈/params〉

〈/function〉

〈function name=“關機”value=“完雷達停止工作”〉

〈params〉

〈/params〉

〈/function〉

〈/equipment〉

在模型庫中添加新模型時僅需要在模型文件中按照格式添加〈equipment〉〈/equipment〉之間的字段。〈equipment〉屬性“name”代表模型的名稱;“package”代表該模型屬于哪類模型庫;〈function〉〈/function〉中間的字段表示該設備可供操作的方法。其中“name”屬性表示方法名，“value”屬性表示方法的描述，〈params〉〈/params〉表示操作的參數值。

(2)開發平臺與劇情控制構件間接口

開發平臺根據用戶操作對服務進行組裝和打包，生成劇情控制文件。劇情控制構件負責對劇情控制文件進行解析執行，實現預設劇情控制。因此開發平臺與劇情控制構件之間的主要接口為劇情控制打包文件。劇情控制打包文件基于XML形式實現，下面內容為劇情控制文件實例。

〈command index=“1” preindex=“0”delay=“15”parameter=“60”matchname=“StartWork”mode=“7”〉

〈service〉引導－雷達〈/service〉

〈function name=“StartWork”〉

〈param〉60〈/param〉

〈/function〉

〈/command〉

其中“command index”字段表示設備劇情動作序列號;“delay”字段表示該動作為相對時間執行方式，取值單位為秒;“time”字段表示該動作為絕對時間執行方式;“service”字段表示該動作設備名稱;“function name”字段表示該動作名稱;“param“字段為該動作所跟參數項，在該實例中表示雷達轉速。

(3)監控平臺與監控構件間接口

監控平臺通過Corba接口與系統總線上的監控構件進行交互，實現設備監視數據、劇情狀態數據的接收和設備控制指令的發送。監控平臺與監控構件之間通過Corba遠程調用的方式實現通信，具體接口如下:

·獲取狀態信息函數

long getMonitorInfor(in long type，inout string infor);

其中type為信息獲取類型參數，0:獲得所有的設備名稱及類型;1:獲得設備名稱為infor的設備狀態信息;2:獲得設備名稱為infor的劇情狀態信息;3:獲得劇情下所有設備的狀態;4:獲得劇情下所有設備的劇情狀態。

·設備控制函數

long setDeviceStatus(in string name，in string commandxml);

向名稱為name的設備發送控制指令，通過向設備發送commandxml命令，完成控制。

·劇情控制信息函數

long setScenarioStatus(in long index，in long type);

對劇情編號為index的劇情進行控制，其中type為控制類型參數，0:表示立刻執行;1:表示暫停執行;2:表示恢復原始狀態。

(4)設備通用構件與設備代理間接口

為了保證系統的靈活性設備通用構件與設備代理軟件只提供一個 corba接口，string Command(string xml)，其中xml為輸入參數包含需要調用的函數以及參數。構件需要根據代理軟件的編寫人員提供的設備功能說明文件，產生內含xml內容的string發起調用請求。設備代理軟件可以根據傳入的xml文檔解析后調用相應的接口，完成功能。傳入的為XML文本，可以一次調用多個功能。以調用獲得run類型的業務信息的接口為例XML格式如下:

〈getBusinessData〉

〈type＞run＜ /type〉

〈/getBusinessData〉

4.4 程序設計

在原型系統軟件實現方面主要涉及JBI構件開發和Corba應用開發兩個技術點。下面結合原型系統主要組成部分劇情控制構件和設備代理軟件介紹相關內容。

(1)劇情控制構件

劇情編排后的運行過程需要有流程的概念，主要是時間控制的問題。例如，A時刻啟動設備甲，B時刻啟動設備乙。劇情控制構件即為完成此項功能而設計。

劇情控制構件遵循JBI構件開發規范。在具體實現上采用開源工具maven進行構件框架的開發，maven為開發JBI構件所需的大部分接口提供了基礎的實現，使構件的開發者可以更多的關注構件所提供的服務的業務邏輯。在構件框架中添加入自己的業務邏輯后，構件的開發工作即結束。

劇情控制構件的主要業務邏輯為劇情控制函數。劇情控制函數定時從劇情文件中讀取劇情執行時間信息，當有劇情的執行時間與當前時間吻合，則向該劇情的執行設備發送劇情信息。劇情控制函數的實現代碼如下:

/＊＊

＊劇情控制線程

public void run()

{

while(status!=JQTimer.STOP)//定時器未停止

{

//設置劇情控制定時間隔，單位毫秒

Thread.sleep((long)(100));

//劇情信息列表

List＜String＞ scenariosStringList=Collections.synchronizedList(new ArrayList());

//循環遍歷劇情列表，判斷是否有滿足條件的劇情

for(Iterator＜ Scenario ＞ it=cenariosList.iterator();it.hasNext();)

{

Date date=new Date();

Scenario scenario=(Scenario)it.next();

if(((0==scenario.getStatus()＆＆scenario.get-Time().before(date))))//劇情狀態正常，并且時間到。

{

//設置劇情狀態，1:表示執行成功

scenario.setStatus(1);

//構造向具體設備發送的劇情信息包

MessageExchangechange=endpoint.createProperMessageExchange();

NormalizedMessagemsg= exchange.createMessage();

//從劇情文件中獲取劇情信息內容，并復制到消息中

msg.setContent(new StringSource(scenario.getXmlActionFile()));

exchange.setMessage(msg，“in”);

//設置目標設備

endpoint.setTargetService(scenario.getService());

//設置目標節點

endpoint.setTargetEndpoint(scenario.getEndpoint());

//設置消息路由信息

endpoint.setRoutingInfo(exchange);

exchange.setProperty(“index”，scenario.getIndex());

scenario.setMessageId(exchange.getExchangeId());

//發送消息

endpoint.getProcessor().send(exchange);

}

else

{

//不執行任何動作

}

(2)設備代理軟件

設備代理程序由三部分構成:設備驅動的實現、Corba代理服務、設備自動注冊服務。其中設備驅動主要負責與具體設備進行交互，控制設備運行，采集設備運行數據，并提供Corba調用的接口。

Corba代理服務主要負責封裝設備驅動，提供通用設備構件與設備之間的接口映射。開發Corba代理服務模塊首先需要編寫IDL接口文件。該文件描述了代理端能夠提供何種類型服務給通用設備構件。設備代理程序中的IDL接口文件基本格式如下，其中的Command為設備代理程序暴露給通用設備構件的接口。

module dzbc

{interface PrefixComputer

{

string Command(in string xml);

};

在設備代理端的Command實現代碼如下:

char*dzbc::PrefixComputer_impl::Command(const char* xml)

throw(CORBA::SystemException)

{

if(xml［0］! =‘