康春农,王永良,张春娣
1.南京炮兵学院,南京211132
2.宣化科技职业学院 信息技术系,河北 宣化075100
计算机生成兵力(CGF)是指仿真战场环境中由计算机生成和控制的仿真实体,仿真实体可能对应一个分辨率较低的模型也可能分解成分辨率较高的多个模型[1]。这种多粒度(多分辨率)CGF 模型在分布交互式作战仿真中占有重要地位,可以通过模型高低分辨率之间的动态转换(聚合和解聚)实现对作战实体不同细节度的模拟,来满足不同作战规模仿真的需要,减少仿真节点,节省仿真资源。
CGF 系统中的模型可以看做具有不同功能的智能体(Agent)、聚合级的Agent 实体,除实体的物理行为仿真外,指挥决策仿真是其主要功能,最底层的Agent 则主要仿真实体的物理行为。Agent一般由6 部分组成[1]:感知模块、知识库、决策模块、学习模块、行动模块、通信模块,如图1。主体通过感知模块来感知外部环境,对环境信息做出一定的处理,并送到决策模块;决策模块在知识库的支持下,根据从感知模块得到的外部环境信息做出决策,将决策结果传送给行动模块与通信模块;行动模块则根据传入的动作命令做出相应的动作,对外部环境做出响应;通信模块主要用来处理Agent 之间的信息交换;学习模块的职责是从Agent的不断运行过程中总结经验,为知识库增加新的知识。
炮兵营是基本的火力执行单位,内部作战单位间交互信息繁杂而紧密,其与外部单位交互信息清晰可探查,应该以一个仿真节点模拟炮兵营作战行为。本文以某型火炮炮兵营为研究单位,给出了多Agent的聚合级炮兵营CGF体系结构,分析了重要作战单位模型间的信息交互方式和内容以及模型解聚的策略,在此基础上实现了一套仿真系统。
图1 Agent一般结构图
依据课题和实验室建设的需要,需要构建炮兵营CGF系统,为后续师团级炮兵作战对抗仿真系统搭建基础平台。炮兵营CGF 需要具备以下几项功能:
(1)能够模拟自行火炮、牵引火炮、火箭炮三类炮兵营的作战活动。
(2)能够在陆战场联合作战背景下模拟炮兵营战备等级转换、行军、开进展开、作战4 个阶段全过程的作战活动。
(3)能够训练炮兵营指挥人员对炮兵营的指挥能力,尤其是对突发情况的处理。
(4)保障仿真的真实性,利用面向对象的系统分析方法和系统设计方法,使用统一建模语言(Unified Modeling Language,UML)图形化语言建模,使用颁发的地理数据信息搭建地理信息平台,利用正则表达式解析文本格式的命令。
(5)能够验证军事运筹学科构建的各种算法,例如观察所、炮阵地的地域选择算法,对敌目标的侦察选择算法等。
为了给炮兵营CGF 提供一个陆战场的联合作战环境和展示平台,采用高层体系结构(HLA)技术搭建仿真结构[2-3],设计了5 个联邦成员,如图2 所示,每个联邦成员运行在一个节点机上,数据库运行在一台节点机上。联邦成员间的作战信息通过运行支撑环境(Run-Time Infrastructure,RTI)进行交互,仿真控制信息,例如仿真开始、结束等信息通过局域网套接字编程通信。各个联邦成员工作流程如下所示。
图2 炮兵营CGF 仿真系统结构图
(1)导调成员:与炮兵营CGF 成员通过局域网套接字编程通信协商启动仿真程序;从数据库中读取部署信息和模型设置信息,或在二维电子地图上重新编辑,将这些信息写入数据库进行存储以备下次应用,然后通过RTI 发送给其他联邦成员;启动仿真主线程,运行红蓝双方作战模型,导调这些模型的作战行为,为战场提供一些突发情况,例如卫星过顶等,将这些模型的行为结果和突发情况通过RTI 传送给其他联邦成员;模拟炮兵团指挥机关对炮兵营进行命令控制,下达的命令和收到的炮兵营报告信息通过RTI传送。
(2)炮兵营CGF 成员:与导调成员通过局域网套接字编程通信协商启动仿真程序;启动仿真主线程,生成红蓝双方作战模型的映像模型,运行炮兵营模型;依据接收到的命令指示,炮兵营模型确定作战阶段,必要时进行解聚,结合命令指示、地形信息、战术数据库、映像模型的信息进行行为决策,并进行动作,将动作结果通过RTI 发送给其他联邦成员,将阶段炮兵营整体模型状态存入数据库。
(3)数据记录分析成员:收集导调成员和炮兵营CGF成员发送的各种信息,读入数据库进行记录,分析本次仿真的记录数据,评估指挥员的指挥能力和水平。
(4)二维显示成员:依据上级颁发的数字地理数据生成二维电子地图,从导调方和炮兵营CGF 方接收信息,展现二维战场态势,包括二维作战模型的显示、移动、毁伤、射击等。
(5)三维显示成员:依据上级颁发的数字地理数据生成三维战场环境,从导调方和炮兵营CGF 方接收信息,展现三维战场态势,包括三维作战模型的显示、移动、毁伤、射击等。
考虑到作战实体数目较多,而且为了适应将来方便的增加作战模型,同时也为了降低各联邦成员间的耦合度,设计在RTI 网络上交互的信息只有4 类:模型信息、射击信息、命令指示和报告、辅助信息。
模型信息对应作战模型,为保障模型的一致性,采用了3 层身份鉴定方法。例如,蓝军机步营1 连机步排1 排ID是020101-J-1,020101 代表所属单位,02:蓝军,01:机步营,01:1 连,J 代表本身性质:机步排,最后一个1 代表标号:第1 排,这样可以在网络上唯一确定一个模型信息的归属。每个模型有3 个状态{appear,exist,disappear},分别代表出现、存在、消失,有了这些信息模型在各个节点上的维护就有了保障。
射击信息包括弹种、起点、终点等信息,各节点依据天气信息和地形数据对射击信息进行维护,这样可以减少网络上信息的流量。
命令指示和报告目前根据其特殊格式分别进行公布和订购,将来计划采用正则表达式对文本格式字符串进行解析。
辅助信息包括作战时间、仿真时间、时间推进比例、天气,这些信息由导调方生成并发送给其他联邦成员,作战时间、仿真时间由其他联邦成员自己在仿真循环中不断计算更新。
图3 某型火炮炮兵营多Agent的聚合级炮兵营CGF 体系结构图
炮兵营在不同作战阶段其仿真的粒度是不一样的,比如战备等级转换阶段,关注的是炮兵营的整体行为,且炮兵营各单位驻地在一起没有必要分开模拟,因此这个阶段只用炮兵营模型模拟即可。但开进展开阶段和作战阶段就有必要分解出侦察车辆、下级指挥车和单炮车等模型,因此炮兵营整体模型必然是聚合级的。无论是聚合级的炮兵营模型还是解聚开的各子单位模型,都具有自主决策能力、对外部环境感知能力、行动能力和与其他模型进行通信的能力[2-3],这些模型将综合应用天气、地形、战场环境、上级命令等信息进行决策,然后进行物理行为,与其他炮兵营单位协同作战,因此炮兵营整体模型又必然是多Agent 的,以某型火炮炮兵营为例搭建的多Agent 的聚合级炮兵营CGF 体系结构如图3 所示。该结构由6 部分组成,分别是CGF 操作员、界面Agent、信息管理器Agent、联邦管理器Agent、红蓝双方作战模型Agent、炮兵营整体模型,其中红蓝双方作战模型是导调方模型的映像,真实模型在导调方运行,运行结果由CGF 成员接收后更新,其目的是为炮兵营各模型提供一个联合作战的背景。
利用面向对象技术[4-5]构建某型火炮炮兵营各单位静态组织结构,如图4 所示。炮兵营各单位分别对应一个类,类间关系主要是组合关系(实心棱形箭头),例如炮兵营指挥车组合了各连指挥车,表示各连指挥车是营指挥车的一部分,是一种同生共死的关系,整体有创建和销毁部分的义务和权利,整体消亡部分必然消亡。在这里利用了指挥关系进行结构建模,而没有利用编制情况,主要是考虑到便于组织协同、解聚,以及减少模型个数。炮兵营指挥车是炮兵营的部分,在战备等级转换阶段和行军阶段,以炮兵营这个Agent 模型模拟整个炮兵营的行为,当接收到展开指令后,炮兵营模型创建子部分炮兵营指挥车,炮兵营指挥车创建它的子部分,模拟炮兵营的任务由炮兵营过渡到炮兵营指挥车为龙头的整个炮兵营模型中去,炮兵营模型具有控制台的功能,控制着解聚的过程。
图4 炮兵营整体模型的静态结构图
具体的解聚算法伪代码为:
炮兵营.circumvent(){
如果状态为日常训练
为保证消防车辆全力救灾,美丰加蓝积极行动、统筹协调,与当地经销商携手,迅速成立“美丰加蓝支持灾区建设服务队”,并携带美丰车用尿素及加注设备前往青州消防支队和救灾前线,为消防车辆提供美丰车用尿素及加注服务。
如果接收到战备等级转换命令
设置状态为战备等级转换;
否则执行日常训练工作;
如果状态为战备等级转换
如果接收到行军命令且战备等级转换工作已完成
设置状态为行军;
否则执行战备等级转换工作;
如果状态为行军
设置状态为开进展开;
否则执行行军工作;
如果状态为开进展开
如果炮兵营指挥车不存在
生成炮兵营指挥车及下属单位;//将开进展开状态和炮兵营参数数据传给营指挥车及下属
发送炮兵营指挥车及下属单位生成消息;
发送炮兵营模型消失消息;
如果炮兵营指挥车已存在
炮兵营指挥车.circumvent();//如果炮兵营指挥车感知到各子单位已展开完毕,发送战斗进行状态给炮兵营
如果状态为战斗进行
炮兵营指挥车.circumvent();
}
其中加粗的字体代表仿真模型,15、16、17、18 行代码为解聚过程,20、23 运行的是解聚开的模型。炮兵营模型控制着解聚的过程,且只是发送了自身消失的消息(18行),在这个仿真节点并没有真正删除该模型,但在其他节点看来该模型已由解聚开的模型替换掉了,这主要是为了减少模型个数,简化管理层级[2-3]。
由于多个Agent 组织在一起,Agent 间的通信内容和通信方式的建模是仿真设计的重点和难点,也是炮兵营CGF设计成败的关键[2]。炮兵营内部采用直接通信方式,炮兵营外部接口是炮兵营模型或炮兵营指挥车模型,他们与其他Agent 间的通信工作原理如表1(表中编号为图3 中数字序号)。
表1 所设计的通信原理能够保障如下几个功能:
(1)支持人在回路或人不在回路。来自9、10 的炮兵团命令可以直接驱动炮兵营整体模型,实现人不在回路的仿真,或者将9、10 信息通过11 反映到界面上,由操作员编辑命令,通过1、2 信息传递驱动炮兵营整体模型,实现人在回路的仿真。
(2)满足聚合模型和解聚模型的需求。炮兵营作为聚合模型,接收2、9 信息,解聚开之后,炮兵营指挥车接收10、13 信息,再传递给子模型,2 和13 信息格式和内容是一样的,9 和10 信息格式和内容是一样的,且都是采用的黑板通信,处理决定权只在炮兵营模型和炮兵营指挥车模型。
(3)为炮兵营各模型提供了充足的信息。来自2、9、10、13 的命令信息驱动仿真的进行,6、8 信息提供天气、作战模型等战场环境信息,另外还有来自数据库的战术数据库和地形数据库,保障了炮兵营各模型运行所需数据的充足。
表1 炮兵营CGF 模型Agent间的通信工作原理
(4)有利于仿真系统的稳定。炮兵营整体模型内部直接通信;利用黑板通信接收其他Agent的信息;通过15 向其他联邦成员发送模型信息、射击信息和上报报告信息,这些信息格式固定,而且只管发送不用维护。这样就将炮兵营内部复杂的交互与其他Agent 和其他仿真节点隔离开来,形成了高内聚和松耦合。
使用VC2005 开发工具、BCG 界面库、MGS 地理信息系统、项目组开发的GDI+绘图程序、HLA 技术、套接字局域网通信技术、多线程技术、视频播放技术、OGRE 三维渲染技术等[6],实现了导调方、炮兵营CGF 方、二维显示方、三维显示方4 个节点,导调方和CGF 方都以模型为中心,以领域驱动进行开发设计,以面向对象技术组织和建设这些模型。其中导调方运行着非炮兵营各单位的模型,维护着炮兵营整体模型的映像信息,展现二维态势和简易动画,向炮兵营发送命令,展现炮兵营整体模型和其他模型的动作状态报告。炮兵营CGF 方运行着解聚前和解聚后炮兵营各单位模型,维护着非炮兵营各单位的模型信息,接收导调方的导调信息和命令信息,展现炮兵营的动作状态,为二、三维显示成员提供数据。截取的运行界面如图5 和图6所示。从多次仿真运行的情况来看,导调方的命令和导调信息能够得到CGF 方及时的反应和回馈,各模型的毁伤计算、机动实施计算能够及时反映到界面上来,没有逻辑上的错误,而且仿真运行过程流畅,有很高的安全性和稳定性。总体上来看,能够支持炮兵营CGF 系统的需要,以及模拟整个4 个阶段的炮兵营活动。炮兵营各作战模型以及红蓝双方作战模型设计还比较简单,今后在本文设计的技术框架基础上,将丰富各个作战模型,力争将炮兵营CGF系统融入到师团以上级别的仿真系统中去。
图5 导调方运行时截图
将炮兵营内部各模型和外部模型都看做Agent,并给出它们的构成和组织关系,通过分析它们之间的通信内容和方式,确认了各Agent 的功能和职责。本文设计的多Agent 的炮兵营CGF 结构不仅能实现人在回路和人不在回路的仿真,也能够顺畅的实现解聚前模型运算到解聚后模型运算的切换,保障了炮兵营各作战单位模型运算数据的充足性,并且保障了炮兵营整体模型内部间的高内聚和与外部的松耦合。以该模型为中心实现了系统仿真,仿真运行结果表明本文的设计合理且有效,能够满足炮兵营CGF系统建设的需要。今后,将以本文设计为平台充实炮兵营各作战单位模型,在一个节点机上力争真实地模拟整个炮兵营的行为。
图6 炮兵营CGF 方运行时截图
[1] 郭齐胜,杨立功,杨瑞平.计算机生成兵力导论[M].北京:国防工业出版社,2006.
[2] 杨新颖,龚光红.聚合级CGF 关键技术的研究[J].系统仿真学报,2006,18(2).
[3] 谢永强,周保顺.聚合级CGF 仿真中仿真应用程序的管理[J].系统仿真学报,2006,18(2).
[4] Evans E.领域驱动设计[M].赵俐,盛海艳,刘霞,等译.北京:人民邮电出版社,2010.
[5] Gamma E,Helm R,Johnson R,et al.设计模式:可复用面向对象软件的基础[M].李英军,马晓星,蔡敏,等译.北京:机械工业出版社,2000.
[6] 耿卫东,陈为.计算机游戏程序设计[M].北京:电子工业出版社,2009.