姚青锋,冯少冲,邸彦强,朱元昌
(军械工程学院电子与光学工程系,河北 石家庄 050003)
HLA是美国国防部建模与仿真办公室(DMSO)提出的分布式仿真体系结构,其目标是实现仿真互操作和重用。它是IEEE的标准,是当前分布式交互仿真领域的首选体系结构[1]。随着基于HLA的仿真研究的深入,如何实现基于HLA的联邦成员的“通用性”成为了各方关注和研究的热点。文献[2]指出HLA就是要解决联邦成员设计实现中“与具体仿真应用的无关性”和“仿真过程中与具体仿真过程相关性”之间的矛盾。
为了实现联邦成员的通用性,国内外相关科研机构对此进行了大量的研究。纵观这些研究成果,实现联邦成员通用性主要有两方面:即基于对象模型(FOM/SOM)的联邦成员框架代码自动生成法和自适应法。
在联邦成员框架代码自动生成研究方面,国外已经开发出多种工具,如美国AEgis公司开发的Lab-Works FedProxy等;国内在这方面研究相对起步较晚,国防科技大学在这方面研究较为深入,应用较为广泛。联邦成员框架代码自动生成的优点在于联邦成员与RTI之间的信息交换代码可以根据对象模型(FOM/SOM)自动生成,只要对象模型(FOM/SOM)改变,生成的联邦成员代码也就改变了,这样就使得生成的联邦成员能够严格的满足联邦的要求,具有一定的灵活性[3]。其缺点是在每次对象模型改变时,都需要重新生成一个联邦成员,并且需要重新编译,增加了工作量。另外联邦的不同,可能需要对数据结构进行大的改动。
自适应法基本的思路是在联邦成员和RTI之间建立一个中间件层或者语义层,在不修改联邦成员代码的情况下,实现联邦成员的通用[4]。通过该方法,联邦成员能够适应多个不同联邦。文献[5]提出了一种基于对象模型(FOM/SOM)映射的自适应成员设计方法。该方法在原有成员SOM和FOM之间建立了一个中间层,这个中间层负责成员SOM和联邦FOM间的映射。每一次FOM改变,就需要开发这样一个中间件,以DLL动态链接库的形式供仿真系统调用。这种方法的优点是能够做到联邦成员的通用,但是需要针对每一个SOM/FOM做一个中间件,工作量较大。文献[6-8]研究了基于HLA仿真成员通用性问题,提出了动态公布/订购、HLA接口模型等办法解决通用性问题。这种方法的优点是工作量少,成员通用性较强。缺点是在联邦运行速度上较慢。本文充分吸收了前人研究的优点,同时对不足之处进行了优化,提出了基于映射的态势显示成员通用性实现方法。
考虑到本文中态势显示成员主要针对防空作战领域,涉及多种防空武器,当前的主流模拟训练方式是为每种防空武器设计一个联邦,然后可以根据需求将这些联邦进行多联邦互联。所以要实现态势显示成员的通用性,实现在任意一个单武器联邦中的通用性是问题的关键,所以本文将通用性研究的范围限定在针对任意一种防空武器单联邦。这些防空武器需要描述的内容和数据结构具有一定的相似性,特别是在二维态势显示成员中这种相似性更突出,如不管什么类型的武器,在二维态势成员中,都需要描述位置,方向,队形等信息。所以这也说明了通用态势显示成员的可能性。正如文献[5]所述,任何一种理论和方法都建立在一定的条件和范围下。只有在态势显示成员面对的联邦是同一应用领域的并且联邦结构存在局部差异的条件下,联邦成员与联邦之间才可以建立映射关系,从而实现成员的通用。
要实现态势显示成员通用性目标,需要从以下两个方面做工作。
1)需要从系统工程的角度出发,在联邦和态势显示成员设计阶段之初,就需要充分分析不同武器平台在二维态势显示成员中需要展示的共性内容,对成员潜在的能力和今后可以适用的联邦有一个清晰的认识。在设计SOM时,对一些在态势显示成员中可能会用到的对象类、交互类进行科学的归类、命名,在设计之初,就为今后成员的通用奠定一个基础。另外对成员中用于接收、存储数据的实体类进行梳理、归纳,建立一个按属性分类的通用的实体数据模型。
2)充分分析HLA机制下数据的收发机制,对影响联邦成员通用性的各数据接口和数据处理环节进行梳理,并针对每一个环节,设计相应的模块,解除与具体系统的耦合[9-10]。通用防空作战态势显示成员各模块构成及相互关系图如图1所示。
防空作战态势显示成员需要显示仿真开始前的初始态势信息以及仿真过程中的态势演变。不管是态势的初始化还是态势演变主要体现在作战实体相关属性的改变。所以本文在充分分析防空装备属性共性的基础上,对这些属性进行分类、归纳,设计一系列的属性类,每一个类对应着一种需要描述的功能。表1是实体数据模型模块中的各类及其属性说明。在这些类中,有些是静态类,有些是动态类。最后将这些类进行组合,得到实体数据模型模块。实体数据模型模块是介于态势显示成员中仿真模型和HLA/RTI数据接口之间的模块,主要负责在发送前和接收后对数据进行存储和管理,以便业务逻辑对其进行操作。在设计通用的SOM时,要与数据模型在形式上保持一致,方便实现数据模型类中的属性与公布订购的属性、参数对应,减少映射的工作量。只要把握这个原则即可,本文不再对FOM进行设计。
图1 通用防空作战态势显示成员各模块构成及相互关系
配置模块中的配置文件记录了态势显示成员中涉及的对象类(对象类属性)、交互类(交互类参数)等信息。配置模块主要完成以下工作。
1)解析通用SOM形成类列表:SOM它包含了联邦成员中所有的数据信息,如对象类(对象类属性)、交互类(交互类参数)。配置模块解析SOM,并将所有的对象类、交互类在可视化界面上以列表的方式表示出来,供用户对态势显示成员所关心的内容进行选择。
2)选取需要公布、订购的对象类、交互类:用户根据列表中的类,选择需要公布、订购的对象类、交互类,配置模块将根据这些用户选择的公布、订购的对象类(对象类属性)、交互类(交互类参数)以及它们的数据结构和数据类型自动填入配置文件中,供动态公布、订购模块读取使用。
表1 实体数据模型模块中的各类及其属性说明
3)记录数据类型、数据结构和数据模型信息:一一对应记录步骤2)中选取的对象类(对象类属性)、交互类(交互类参数)的数据类型和数据结构。并记录成员中用于接收、存储、处理数据的数据模型信息,主要是用到了模型中多少个类,每个类中的哪几个属性,每个属性的数据类型等内容。其目的是为后面的数据耦合/解耦、映射做准备。
4)将配置信息以XML格式配置文件的形式保存起来。
按照建筑建设过程中使用的材料来说,一般有钢筋混凝土建筑、砖瓦建筑等。相对于传统民居使用的砖瓦建筑来说,一些现代化的城市高层建筑多数都是采用钢筋混凝土构建而成的。钢筋混凝土建筑要比砖瓦结构的建筑更容易发生冷桥现象。
在一般的HLA仿真系统中,联邦成员的公布、订购关系是静态的,即公布、订购源代码是固定的。编译以后,成员的公布、订购关系便无法更改。动态公布、订购模块摆脱了这种静态模式,它通过读取配置文件的方式改变原本静态的公布订购关系。这样就使得成员灵活性大大增强,也为通用奠定了一个重要的基础。动态公布订购模块实现的流程如下。
1)读取配置文件:读取配置文件,获取需要公布、订购的对象类(对象类属性)、交互类(交互类参数),数据类型等实现通用成员的重要信息。
2)获取对象类(对象类属性)、交互类(交互类参数)句柄:依据从配置文件中读出的对象类(对象类属性)、交互类(交互类参数)名称,利用RTI代理函数获得相应的句柄。
3)动态公布、订购:利用RTI代理函数根据得到的句柄对对象类、交互类等进行公布、订购。
在HLA机制下,数据的发送主要通过对象类的更新和交互类的发送实现。考虑到通用成员的特殊性,以及其公布的对象类、交互类及其数目是动态改变的,所以所更新对象类和发送交互类的代码也应该是动态可变的。与传统情况下HLA机制中数据的发送相比,通用态势显示成员中数据发送模块主要完成以下工作。
1)数据映射:由于态势显示成员需要适用于多个不同的联邦,每个联邦中支持态势显示的数据虽然在大体上具有相似性,但也有特殊性。所以在发送数据之前,需要对配置文件中对象类属性、交互类参数与数据模型中类的属性进行按序比较,包括名称、数据类型等。由于在配置模块生成的配置文件中已经详细记录了这些信息,所以对比工作比较容易实现。比如数据模型中关于位置的属性是用x,y,z三个属性表示的,在公布的对象类属性中只有一个位置属性,那么就需要对数据模型中的数据进行聚合操作,采用一定的规则将三个属性聚合成一个属性,然后完成该属性与对象类属性的对应,并做记录。最后将所有的记录以XML格式输出,该文件就是所谓的映射文件。设计相应的XML解析器对这些记录进行解析,并调用相关程序进行映射处理,完成数据匹配。
2)数据聚合:在数据模型中属性(数据)与对象类属性或者交互类参数的映射过程中,有一种情况,如果数据模型中的多个属性(数据)对应一个已公布的对象类属性或者交互类参数,那么就需要对数据模型中的属性(数据)进行聚合,然后再与公布的对象类属性进行匹配。由于在配置模块生成的XML格式的配置文件中详细记录了实体数据模型信息和对象类、交互类的信息,所以开发一个可视化工具解析这些信息,并在这个工具的界面上对需要进行聚合的数据模型中的属性进行选择,并指定聚合后得到的属性名称和类型(一般为与之对应的对象类属性或者交互类参数名称)。只要约定好了分割的符号,在订购的成员中,就可以利用这个规则去解聚。另外,如果不在可视化工具上进行聚合设置,那么说明在本次映射过程中不需要做聚合,系统将跳过聚合操作。
3)数据打包:因为一般情况下,一个对象类中有多个属性,一个交互类中有多个参数,所以为了使程序更加简洁紧凑,需要采用类似于2)中所述的聚合的方法,首先将同一个对象类中的属性以及同一个交互类中的参数进行“压缩”,即添加到一个atrributes或者parameters数组中,然后再一次性发送。采用这样的方法,可以减少发送的次数,简化代码,提高效率。
4)数据发送:数据的发送采用RTI代理函数,如果发送的是对象类属性,利用registerObjectInstance()函数对对象类实例进行注册,然后态势显示成员收到turnUpdatesOnForObjectInstance()或者provideAtrributeValueUpdate()回调函数通知,态势显示成员调用updateAtrributeValues()服务来更新指定的实例属性值;如果发送的是交互类参数,那么则采用sendInteraction()服务向联邦发送交互实例。
需要指出的是,数据映射、数据聚合、数据打包三个过程并不是必须的,系统会根据配置文件和用户具体的操作进行相应处理。
数据接收是与数据发送对应的过程。在HLA机制中,数据的接收通过对象类的反射和交互类的接收实现。考虑到通用成员的特殊性,其公布的对象类、交互类及类数目是动态改变的,所以所反射对象类和接收交互类的代码也应该是动态可变的。与通用态势显示成员中数据发送相对应,数据接收模块主要完成以下工作。
1)数据接收:数据接收是与数据发送相对应的过程,所以数据接收和数据发送一样,采用RTI代理函数,如果接收的是对象类属性,态势显示成员在收到reflectAtrributeValues()回调函数之前会先收到discoverObjectInstance()回调函数并发现相应的对象实例。然后reflectAtrributeValues()反射对象类实例的属性值,完成属性值的接收。如果接收的是交互类参数,需要通过receiveInteraction()回调函数来完成。
2)数据解包:数据解包过程与数据打包过程对应。态势显示成员收到的数据是经过打包的,所以收到数据以后需要根据打包的规则,把数据从数组中提取出来,然后将数据交给下一步处理。
3)数据解聚:数据解聚过程与数据聚合过程相对应。态势显示成员收到数据后,根据语义映射中的记录,将一个属性解聚成多个属性。
4)数据映射:数据映射功能是将收到的数据经过解包、解聚之后,数据就与数据模型类中的属性基本对应了,但是在顺序、名称方面仍存在差异,需要映射功能利用匹配规则实现接收数据和模型类属性的完全匹配。匹配的实现,关键在于配置模块的配置文件信息。
需要指出的是,数据解包、数据解聚、数据映射三个过程也不是必须的,系统会根据用户具体的设置进行相应处理。
态势显示成员是面向防空作战领域的通用显示成员,通过语义映射,实现与具体防空武器模拟训练联邦的互联和交互。本节的应用实例来自于态势显示成员与某型自行高炮模拟训练联邦的互联,为其提供战场态势的实时显示服务。如图2所示是态势显示成员SOM对象类交互类选择界面。用户针对该型自行高炮模拟训练联邦实际需要显示的二维态势数据和数据结构,选择SOM中的对象类和交互类,并且生成映射文件,实现通用态势成员与该型高炮联邦的互联和分布交互。
图2 对象类、交互类选择界面
图3所示是联邦运行过程中,态势显示成员的运行效果。实际的运行效果说明,态势显示成员具有较强的通用性以及较大的使用价值。
图3 通用态势显示成员在某型自行高炮模拟训练联邦中的应用
与传统的成员通用性实现方法相比,本文的方法工作量更小且效率更高。但是联邦成员所面对的联邦需要具备一定的相似性,即“映射、聚合、打包、解聚、解包”的工作量越小越好,否则映射的工作量会大大增大,程序的复杂度也会指数上升,并且联邦运行速度也会大大降低。
[1]周彦,戴剑伟.HLA仿真程序设计[M].北京:电子工业出版社,2002.
[2]陈彬,张国强,黄柯棣.一种基于HLA的通用仿真数据收集方法[J].计算机仿真,2006,23(5):127-130.
[3]蒲玮,孙少斌.联邦成员应用程序的一种模板实现[J].计算机工程与设计,987-989.
[4]Ronald Sell,Jim Towers,Gary Ballard,etc.Extended Air Defense Testbed(EADTB)Migrates Toward High Level Architecture(HLA)Compatibility.
[5]张琦,黄柯棣.自适应性成员与对象模型映射[J].计算机仿真,2005,22(10):115-118.
[6]陈彬.HLA仿真系统的联邦观测方法研究及工具设计[D].长沙:国防科学技术大学,2005.
[7]王晓华,柴旭东,张田文,等.一种接收仿真数据的通用高层体系结构的接口研究[J].计算机集成制造系统,2007,13(9):1787-1794.
[8]杨占龙,陈航,杨虎.通用鱼雷模拟器适应性软件开发[J].计算机工程,2011,37(24):290-292.
[9]宋辉,刘晓建,金士尧.HLA环境下基于聚合属性的数据采集方法[J].计算机仿真,2004,21(4):60-62.
[10]王学慧,张磊,黄柯棣.联邦成员框架代码的自动生成技术研究[J].计算机仿真,2005,22(9):126-129.