基于软总线的电子靶场测控体系架构研究

张焱，周文硕，赵华敏

(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］! =‘’)

{

//收到控制指令，保存到全局内存中，供调用

EnterCriticalSection(＆m_CS);

strcpy(xmlbuffer，xml);

LeaveCriticalSection(＆m_CS);

}

else

{

//收到设备状态查询信息，返回设备状态信息

Char* _r=CORBA::string_dup(“status，good;”);

}

return_r;

}

设备代理启动后，设备自动注册服务通过JMS构件向监控构件发送注册信息后，在监控平台上就能够自动发现该设备。设备自动注册服务实现代码如下:

DWORD WINAPI StartReg(LPVOID lpParameter)

{

int argc=7;

//设备自动注册信息初值

char* argv▯ ={，“192.168.1.233”，“61616”，“目标指示 － 雷达”，“192.168.1.232”，“6001”，“5000”};

//与JMS构件建立连接

brokerDll－ ＞createConnection();

//定时循环向平台发送自动注册信息

while(true)

{

//构造注册消息字符串

ts=“reginfo;;”;

ts+=argv［3］;

ts+= “;”;

ts+=argv［4］;

ts+= “;”;

ts+=argv［5］;

ts+= “;”;

SYSTEMTIME st;

GetLocalTime(＆st);

//发送注册消息 brokerDll－ ＞send(“reginfo”，(char* )ts.c_str());

Sleep(100);//循环间隔

}

return 0;

}

5 原型系统试验验证

利用测控平台原型系统，对某型号低空超低空防空雷达的抗干扰能力进行实际测试，用以验证原型系统在实际的抗干扰能力测试过程中表现出来的实用性和灵活性。

操作员通过剧情开发平台给雷达定义3个工作时段并自动记录雷达的原始数据，在这3个工作时段设计信号源产生3种不同的电磁干扰信号。测试完成后，通过灵敏度评估构件对记录的数据自动进行统计运算，计算出该时段内信标机目标幅度信息平均值。通过对不同干扰时段的平均值作比较获得雷达接收灵敏度指标并送剧情监控平台显示。

图4为剧情开发平台剧情编辑界面。界面左上区域为模型库列表，右上区域为构件组装界面，下部为剧情动作设置界面。用户将模型列表中设备模型拖拽到组装区并添加需要的剧情动作后，与剧情控制图标进行关联。在实际运行时，该设备就能够在剧情控制构件的调度下完成相应剧情动作。

图4 开发平台剧情编辑界面图

在验证试验中，还同时进行了总线传输的性能测试。表1为传输性能测试结果。

表1 传输性能测试结果

通常测控信息系统的信息交互延迟指标为1秒以内。从表中可以看出，采用软总线方式进行信息的交互时效性是能够得到保证的。

6 结束语

本文主要论述电子靶场测控信息系统体系架构的研究。采用基于软总线+软构件的设计理念、方法和技术标准，对电子靶场测控领域信息系统进行归纳和总结，提出了该领域信息系统体系架构规范。参考该体系架构规范实现了原型系统，并进行了相关试验验证。这些研究工作可对今后电子靶场测控系统的研制起到积极的指导和借鉴作用。

［1］ 颜建平，张焱，陈路路.软总线技术发展与应用研究［J］.无线电工程，2008，38(11):61 －64.

［2］ 赵发刚，陈进，李毅.基于SOA的监测、诊断与预测系统架构［J］.计算机工程，2010，36(1):233－235.

［3］ 谷双春，李苒.软总线技术在无线电监测系统中的应用研究［J］.无线电通信技术，2005，31(6):48－50.