联合作战仿真实验中仿真引擎运行策略研究

李江涛,张京涛,张 波,王 培

(国防大学联合作战学院,河北 石家庄 050084)

信息技术的飞速发展使科学实验方法、计算机仿真和战争实践相结合而产生的作战仿真实验成为模拟作战活动、仿真作战环境的一种新的科学方法。作战仿真实验以仿真实验系统为平台,通过对作战实体、作战行动、作战样式和基本战法等的建模与仿真,研究作战动态演变,揭示作战基本规律。仿真引擎是作战仿真实验系统的核心组件,独立于具体应用,是负责仿真运行控制、时间推进、数据存储、调度运行的软件功能集合的统称。

随着联合作战研究的深入以及相关仿真实验系统的复杂化和专业化,仿真实验系统往往不是从头开发,而是基于特定的仿真引擎进行架构,因此,仿真引擎成为仿真实验系统中最重要的环节,它是整个系统体系框架的枢纽,推进各个模块的运转,联动整个系统的推演。为提高大规模作战仿真系统的运行效率,学者们对仿真引擎技术与应用问题高度重视,并开展了大量研究。在军事应用领域,以美国为代表的西方国家研制出了SPEEDES、WarpIV、GTW、Warped等仿真引擎,用于支撑各类作战仿真系统的开发与应用。国内学者也相继提出了基于邮箱机制、基于实体模型、基于消息驱动、基于多视角系统分析、联合作战仿真引擎等仿真引擎理论、技术和方法,并应用于作战决策训练、联合作战研究、CISR系统仿真作战平台建设、装备效能评估等方面,这些成果对于促进我军仿真引擎深入研究发挥了重要的作用。但是,当前研究成果大多针对特定领域仿真需求开展专门研究,难以适应联合作战仿真复杂、开放、并行等新特点,并且有些仿真引擎产品的核心模块还是以国外产品为基础,无法完全实现自主可控。

本文结合联合作战仿真实验活动要求,重点针对仿真引擎所涉及的仿真控制、时间管理、数据交互和模型调度等内容进行深入研究,提出一套仿真引擎运行策略,即面向活动和事件的柔性混合仿真控制策略、基于标准时间的仿真时间推进和模型同步策略、基于消息中间件的动态数据交换策略、“仿真引擎+行动模型组件”的管理调度策略,力求从机制原理方面对仿真引擎运行进行系统设计,有效解决仿真实验过程中对各类对象、资源、数据和模型的生成、维护、管理、调度和运算问题,为更加深入地开展联合作战仿真实验仿真引擎研究提供借鉴,为联合作战仿真实验仿真引擎的高效运行提供技术和方法支撑。

1 仿真控制策略

仿真控制策略是对仿真模型进行控制和处理的基本指导原则和总体方法,决定了仿真进程的控制逻辑和仿真时间的推进机制,是仿真引擎运行的基础。

联合作战仿真实验中的仿真过程属于离散事件仿真范畴,仿真引擎的仿真控制策略应遵循离散事件系统仿真的基本原则和规律。目前,离散事件系统仿真的控制策略主要有三种,即面向事件调度策略(Event Scheduling)、面向活动扫描策略(Activity Scanning)和面向进程交互策略(Process Interaction)。这三种控制策略各有优缺点,在各自不同应用领域能够较好地实现仿真控制。但是,联合作战仿真实验涉及的实体繁多、事件复杂、活动频发,仿真引擎需要支持大规模复杂作战问题的实时仿真。考虑仿真引擎的适用性、实时性和可扩展性,采用单一控制机制无法满足不同层级、不同规模的仿真实验需求。为了较好解决这一问题,本文在已有方法的基础上,对仿真控制机制进行了柔性化处理,设计了一种更加灵活的面向活动和事件的柔性混合仿真控制策略。

事件和活动是仿真引擎运行的基本组成,确定性事件引发事件例程,条件事件则通过活动例程加以实现,两者共同完成对仿真时间的推进。该策略将影响系统或实体状态变化的确定性事件和条件事件分别进行处理。对于在某一时刻必然会发生的可以预知的确定性事件单独列出,用于实时反应系统的变化规律;对于无法预测的条件事件,则安排在相应活动例程中进行处理，从而使引擎既有面向活动扫描策略逻辑上的简洁、清晰,又有面向事件调度策略的高效、灵活。其逻辑控制过程如图1所示。

图1 面向活动和事件的柔性混合仿真控制策略

在活动例程的处理中,会伴随条件事件的发生,从而改变系统或实体的状态,并因状态的变化而开始另一项活动。因此,活动不能独立地确定系统推进的时间,但其存在又表现为一个时间过程,是与时间相关的。在仿真推进时,推进时钟通常是通过确定事件的发生时刻来确定下一个推进时刻。此时,对活动例程的扫描,应根据当前时刻和未来时刻确定扫描总时间,并将这个时间段细化成若干个迭代周期(时间步长),按此时间步长周期地扫描各个实体的不同活动例程,以使模型运算的结果具有一定的平滑性和连续性。迭代周期的长短,可根据实体运算精度的要求、系统运行速度的情况等因素综合考虑,由活动模型本身来决定其迭代周期的大小,引擎加载模型时再通知引擎,引擎将按这个周期来循环调度该活动模型。

在实际运行中,仿真引擎通过时间推进、模型调度、事件管理等协同完成仿真控制。时间推进,用于记录仿真的时间进程,确定下一事件开始发生的时刻,并维护扫描活动时的扫描迭代周期。模型调度,用于对事件例程和活动例程的定义和调用,主要是实现对实体行为与事件例程、活动例程的匹配对应,在事件和活动与实体之间搭起了一座桥梁,以使执行例程通过实体行为来实现。事件管理,用于对事件序列的增加、删除、检索、存取等管理,主要是把将要发生的事件的属性如事件类别、发生时间和发生的优先级权数等,合成完整的事件描述并插入事件表中。

2 时间管理策略

时间是协调、同步各种实体对象的重要依据,是引擎运行和交互的基础。仿真引擎对作战过程的仿真,实质上是以时间尺度来揭示作战的规律。

2.1 基于标准时间的仿真时间推进

在理想的仿真处理中,引擎以一定的时间步长向前推进,并在这个时间段内处理所有发生的事件和活动。而现实中,事件或活动在每个时间步长内分布是不均匀的,如果我们使用天文时间来衡量每个步长时间,仿真进程就会表现出很明显的“抖动”。系统通常根据仿真时间逻辑地分割仿真过程,这样仿真时间与天文时间就不能保证严格的线性关系。仿真引擎如果运用该方式产生和维护整个仿真进程内统一的作战时间,显然不能满足诸如模拟对抗等综合性的仿真实验需要。依据我们的要求,引擎要能够与外围系统一体化运行,它们之间必须有一个统一的、科学合理的、技术可行的时间标准。因此,为解决上述难题,本文提出了基于标准时间的仿真时间推进机制。

该机制的基本思想是:在仿真引擎外设立一个专门的标准时间发生器,该发生器将严格以天文时间为依据产生具有严格线性关系的作战时间,再由时统服务向位于不同计算机上的时统客户服务发布标准时间,时统客户服务本身也是一个时间源,它接收标准时间后将以标准时间为依据进行校准和同步,以维护本机时间与标准时间的一致性,各引擎和其他系统通过标准访问接口向本机的时统客户服务请求标准时间。

该机制由标准时间源、实验进程控制、时统服务、时统客户服务和仿真引擎等模块协同实现,如图2所示。其中,标准时间源是标准时间发生器,负责产生准确客观的物理时间信息,它可以是某台计算机的机器时间,或网络内的某个时间服务器,或GPS、原子钟等高精度物理时钟。实验进程控制负责设定实验内容、仿真时间步长、起始仿真时间等参数,控制仿真实验的开始、暂停、继续、停止、再现等,将控制信息传送给时统服务。时统服务接收到实验控制信息和标准物理时间后,根据网络情况进行时间校准和同步,产生统一的天文时间和仿真时间,并在整个环境内进行统一发布。位于终端的时统客户服务接到时统服务发布的信息后,进行时间校准,以保证其所维护的时间与标准时间同步。仿真引擎通过时统客户服务的标准接口取得时统信息,用时统信息同步其时间推进,驱动引擎按标准时间的节奏进行迭代计算，从而推动仿真实验活动进行。

图2 基于标准时间的仿真时间推进机制示意图

从图2中可以看出,标准时间源解决了时间来源的科学合理问题;实验进程控制解决了仿真实验进程统一控制问题;时统服务和时统客户服务解决了不同时间机制之间的转换、时间校准和标准时间发布问题;引擎解决了模型时间和标准时间的同步问题。采用该机制,能够实现位于不同地域的不同计算机上的仿真时间科学合理和高度一致,并且实现了仿真模型与总控的同步运转。该机制运用于模拟对抗等仿真实验,能够实现实验系统运行与实验部队行动保持高度一致,有效解决了仿真实验过程中引擎虚空间与部队行动实空间的协调一致。另外,该机制采用了独立的时统服务架构,保证了时统服务在接收、转换、发布和使用时间等过程不受其他事件影响,具有更好的准确性、实时性和一致性。

2.2 模型时间同步

模型时间的同步,是指在进行仿真运算处理时,模型时间要与标准时间相一致。由于模型的处理逻辑已从仿真引擎分离出去,每个模型的时间步长是不统一的,是模型根据自身的精度要求自定义的,因此模型时间不等于引擎仿真时间,各个模型的模型时间也可能不同。模型时间与引擎的仿真时间有以下关系:

模型时间=仿真时间+Δ模型步长+负载修正

式中,仿真时间是指由引擎提供给模型的仿真时间;Δ模型步长是模型自定义的迭代步长,它是一个常量;负载修正是由引擎提供的时间修正值,引擎在运行时会监控模型的运行负载情况,以保证模型每个计算周期内均能在指定的时间完成,当模型某个周期运算时间过长,其负载过大,仿真引擎将记录本周期的时间延迟,并在下一周期进行补偿修正,这样确保模型仿真时间的连续性,同时也保证模型时间与标准时间的一致性。

3 数据交互策略

数据是仿真引擎各部分联通与交互的基础和条件。数据交互管理,就是仿真引擎在运行时,对数据的适时获取、调用、传送的方法,目的是实现数据的合理组织、有效管理、高效使用,并为模型提供标准化的数据资源交互接口。根据数据在仿真引擎运行过程中的相对稳定性,可以分为静态数据交互管理和动态数据交互管理两类。

3.1 静态数据交互管理

静态数据是指在仿真引擎运行过程中相对不变的数据,数据具有一定的稳定性。这些数据,从实验开始到实验结束,基本保持不变。因此,这些数据的交互管理,根据其使用的频率,或使其常驻计算机内存,或者以文件方式调用,或者在使用时才从数据库读取。通常对使用频率高的数据,预先将其读入计算机内存,并提供标准的通用访问接口,通过这种方式可有效提高计算机CPU处理时对数据的响应速度。仿真引擎采用这种预先将数据从服务器数据库读入本地计算机内存的管理方式为模型提供数据资源,避免了在使用时通过网络远程频繁查询、调用服务器数据库,以内存空间换取了响应时间,从而提高了系统的运行效率。

3.2 动态数据交互管理

动态数据是指在仿真引擎运行过程中经常要发生变化的数据,如控制命令、实体行动信息、战损战果、情况报告等。这类数据通常用于参与系统应用程序间的数据交互,需要实时获取、快速处理和适时输出。动态交互数据是仿真引擎运行时处理的主体,对其管理和调度直接决定引擎的反应速度和灵敏度。在应用中,我们采用基于JBossMQ消息中间件的方式来实现仿真引擎的动态数据交换。

消息中间件(Message Oriented Middleware,MOM)又称为消息系统,是一种特定的中间件,它利用高效可靠的消息传递机制进行系统无关的数据交换,并基于消息通信来进行分布式系统的集成。JBossMQ是基于开源项目JBoss的消息服务器,所开发的消息应用符合JMS(Java Messaging Service,Java消息服务)中定义的消息中间件标准接口,因此,基于JBossMQ的应用程序具有很好的可移植性。消息中间件提供了一种引擎中多个应用程序或模型之间通信的方式,各个应用程序或模型运行过程中依赖消息系统发送消息进行动态数据交互,如图3所示。

图3 基于MOM的分布式动态数据交互

在应用程序或模型传送消息的过程中,消息数据被首先发送到一个消息队列,由消息系统负责维护,在线传递给连接到消息队列的消息接收方,或者以持久的方式保存,当有接收方连接到消息服务器时再通知接收方。引擎提供给开发者传递消息数据的这种方式,称为消息队列运行机制。该方式不仅使引擎内的各个应用程序或模型间的数据实现了“松耦合”交互,构建了动态、可靠和灵活的分布式系统,而且为系统集成提供了较好的解决方案,实现了系统内各仿真应用的互操作。

引擎提供了两种模式的消息服务：一种是点对点的消息模式,另一种是主题的消息模式。

点对点消息模式为两个客户端之间建立消息队列,使两个客户端之间通过队列实现点对点的消息传递。一个客户端作为消息生产者发送消息给消息服务器中的一个队列(Queue),另一个客户端作为消息消费者从这个队列取出消息。点对点消息模式仅允许一个消息传送给一个客户,一个发送者将消息放在消息队列中,接收者从队列中取走并得到消息,消息就会在队列中消失。通过引擎给模型所下达的各种控制指令便采用了点对点消息模式,以确保每一条指令均被可靠及时地处理。

主题消息模式又称为发布/订阅(Publish/Subscribe)模式,它是在消息中间件上建立一个主题(Topic),每个客户端都可以向这个主题发送消息和接收消息。消息生产者向消息服务器中的一个消息主题发送消息,对这个消息主题感兴趣的客户端均可以订阅这个消息主题,当主题中存在数据时,所有订阅过这个主题的消费者都会收到。引擎的仿真结果数据采用了主题消息模式统一向外部发布交互数据(可根据需要建立若干个主题),其他用户则通过有目的的订阅来“消费”这些仿真结果数据。

基于MOM的动态数据交互,相比于DIS(Distributed Interactive Simulation,分布式交互仿真),提供了更有效的数据传递机制,避免了数据广播风暴;相比于HLA(High Level Architecture,高层体系结构)和RTI(Run Time Infrastructure,运行时间支撑环境),提供了更加灵活和松耦合的系统架构,便于系统扩展和集成。

4 模型调度策略

模型作为系统的相似抽象,是仿真引擎的数据来源和动作行为的依据,是表现某一作战行动规律、反映某一事物本质的具体载体。仿真引擎的运行过程,就是对各类模型不断合理调用和执行的过程。引擎运行中的过程和结果数据,就是各类模型相互作用、协同运算所产生的。由于军事需求和实验目的的不同,仿真模型的设计经常发生变化,明确模型与引擎之间的关系,建立不依赖于双方的接口规范,以隔离模型和引擎的细节变化,达到仿真引擎复用的目的,是仿真引擎必须解决的问题,其中的关键就是引擎如何实现对各类模型的管理调度。

4.1 基于组件的仿真引擎架构

仿真引擎采用组件化方式管理调度仿真模型,能够实现仿真引擎与模型组件弱耦合,引擎通过定义好的接口来操纵和管理模型组件,而模型组件则可以单独进行开发、编码、编译、调试、测试。基于组件的仿真引擎架构简化模型如图4所示,主要由仿真实验系统仿真引擎、引擎接口、统一的若干组件接口和若干组件等部分组成。

图4 基于组件的仿真实验系统仿真引擎架构

仿真实验系统仿真引擎,负责实验系统的整体运行,为组件提供运行环境和管理调度的功能。引擎的组件管理调度功能主要包括组件注册和组件调度。组件注册是指按照某种机制在系统中搜索已安装组件,之后将搜索到的组件注册到引擎中,并对其生成相应的调用机制,如基础功能组件等。组件调度是指引擎按照用户的操作和系统的流程,安全地调用各组件所实现的功能。

引擎接口是组件使用引擎资源、调用引擎功能的通道,是引擎向组件提供服务的承诺,由引擎负责具体的实现。组件通过该接口可获取引擎提供的资源和数据,如系统句柄、系统数据等。

组件接口是引擎注册和调度组件的通道,引擎通过组件接口调用组件所实现的功能,读取组件处理数据等。组件只要按照组件接口进行实现,就能够注册到系统中并能正确调度和运行。

组件是遵循组件接口的具体功能实现。组件实现什么以及怎么实现,完全是组件自己负责,但必须遵循接口的规定和约束。

基于该架构设计的仿真引擎具有显著的优点,并且解决了引擎运行中各类模型的调度问题。首先,把复杂繁多的模型组件从引擎中剥离出去,降低了引擎的复杂度,使引擎更易于实现。其次,增强了引擎的扩展性,如果在系统应用后需要对模型进行扩充和修改,就不必重新编译整个系统,只需要增加或修改相应的模型组件。第三,有利于引擎的稳定,各个功能模块以组件形式在系统中驻留和运行,某个模块的错误不会影响其他模块的运行,更不会影响整个引擎的运转。最后,有利于团队开发,模型组件与仿真引擎以松散的方式进行耦合,两者在保持接口不变的情况下,可以独立开发和发布。

4.2 行动模型组件

1)作战行动建模

作战行动的主体是作战实体。作战实体是作战系统中执行作战任务的作战单位和保障单位,是兵力兵器结合的有机整体。作战行动就是作战实体的行动,是作战实体为了完成某项作战任务,实现某种作战意图,而采取的具有作战意义的举动。作战行动()可以用一个四元组来表示:

::=<,,,>

其中，表示行动的执行实体;表示行动影响实体的集合,如果为空集,表示行动只影响战场环境;表示行动效果集合,是实体采取行动后对自身、其他实体以及环境产生的所有影响;表示实体自身、其他实体和环境影响行动效果的因素集合。

为了达到仿真要求的建模分辨率,通常对作战行动以仿真分辨率为依据进行分解。分解后的最小分辨率行动称为基本行动,也称为元行动。其特点:具有一定的作战意义,是作战实体可以独立执行的一个作战行动;具有可描述性,能用相对固定的、结构化的格式予以描述;具有独立性,行动和行动之间没有包含关系、从属关系或上下层关系;具有原子性,行动的执行过程要么成功,要么失败,不会中间中断执行而其他后续行动继续执行。基于以上分析,我们对基本行动进行建模,设计了基本行动模型格式化描述。

<基本行动>::=<行动名称><行动标识符><行动含义>[<行动优先级>][<行动状态>][<行动开始时间>][<行动结束时间>][<行动参数*>]+<行动过程模型>

2)作战任务建模

作战任务是作战实体在作战中所要达到的目标及承担的责任,由一个以上具有作战资源(人力、装备、弹药等)的作战实体执行相应的作战行动来实现。从仿真实验角度讲,作战任务是由一个或多个基本行动组成的具有明确目标的作战行动过程。在实际军事活动中,部队通过接受作战任务来开展作战行动;在引擎中,任务模型通过接口接收外部计划指令或干预指令来驱动行动模型。作战任务对主体、目标和执行过程都进行了详细规定,指出了由谁执行、执行的目标以及明确无误的意图要求,其内容完整明确,且具有非常强的可操作性。

作战任务的推进过程就是作战行动的执行过程,因此作战任务与作战行动之间具有一定的对应关系。为了实现与基本作战行动一一对应,依据仿真要求的建模分辨率,我们对作战任务进行分解,分解后的最小分辨率任务称为基本任务,也称为单元任务。其特点是:要有明确具体的执行实体，是一个有具体行动意义的独立过程，是可描述性的，能用相对固定的、结构化的格式予以描述，要能够落实到具体的基本作战行动上。基于以上分析,我们对基本任务进行建模,设计了基本任务模型格式化描述,实现了基本任务模型与基本行动模型的一一对应。

<基本任务>::=<任务标识><基本行动标识><优先级><执行实体><执行状态><开始时间><结束时间><参数*>

3)任务解释模板

由上可知,作战行动能够进行组件化表示,可以设计为行动模型组件;作战任务能够采用任务模型进行规范化描述;作战任务与作战行动具有一定的对应关系,任务可以转化为若干顺序执行的基本行动过程。

以往仿真系统运行时,指挥人员向某个实体所下达的作战任务(计划指令或干预指令)是系统事先定义好的,具有明确的内部格式,依据该格式在系统开发时进行硬编码,来实现作战任务到行动模型的解释匹配和驱动执行。这种硬编码方式使仿真系统存在任务格式不能变动、任务条目不能增加、行动模型不能更改等诸多问题。为了解决“定格式+硬编码+硬匹配”存在的问题,我们提出了“标准格式+编码模板+自动匹配”的任务解释模板解决方案,实现了模型与引擎的松耦合和引擎对模型的灵活调度。

任务解释模板是关于基本任务关联行动模型组件运算逻辑和规范的定义,是由一个或多个基本任务解释模板组成的序列。其格式化描述为:

<任务解释模板>:=<任务解释模板标识><基本任务解释模板*>

基本任务解释模板是组成任务解释模板的基本单元,格式化描述如下所示。引擎运行时将依据基本任务解释模板生成能够驱动行动模型的事件。

<基本任务解释模板>::=<行动模型组件标识><优先级><执行实体标识><开始时间解释表达式><结束时间解释表达式><参数解释表达式*>

4.3 “仿真引擎+行动模型组件”管理调度机制

仿真引擎的模型调度就是对作战行动模型组件的依次扫描和执行过程。通过将基本行动模型设计成“即插即用”的行动模型组件,运用任务解释模板方案,在仿真实验系统仿真引擎架构指导下,设计了“仿真引擎+行动模型组件”的管理调度机制,其基本框架如图5所示。

图5 “仿真引擎+行动模型组件”管理调度框架

1)仿真引擎

仿真引擎由若干组件构成,为其提供基础功能服务,并通过引擎接口将基础功能传递到模型组件,模型组件与引擎以及模型组件之间的调度就是通过引擎接口和这些功能组件来完成的。

模型调度组件是引擎运行的发动机,用于提供模型组件注册和调度管理功能,用于运行时协调各个组件,使引擎按仿真实验的内在规律运行。

时间管理组件用于实现引擎的时间推进和时间同步功能。

数据服务组件用于提供数据查询、存取、调用和动态数据发布等服务,实现对数据交互进行统一管理,为整个系统提供数据服务。

实体管理组件用于对作战实体进行统一管理,向模型组件提供行动执行实体、行动目标实体的属性信息,以及对实体状态变化进行管理等操作。

任务解释组件用于将以计划指令、干预指令形式表现的任务数据按任务解释模板进行表达式解释,生成可以触发行动模型组件运行的消息事件序列。

日志服务组件用于提供引擎运行时日志信息的记录和输出。

2)引擎环境接口

引擎环境接口是行动模型组件使用引擎资源、调用引擎功能的通道,通过该接口，行动模型组件可获取和操纵引擎的各种资源和功能,以满足其仿真计算的需要。引擎环境接口与模型组件接口共同组成了引擎与模型组件之间各种消息交互的通道,其组成如图6所示,这些接口由引擎的各个组件负责实现,满足了模型组件运行时仿真运算以及与引擎交互的需求。

图6 引擎环境接口组成

3)模型组件接口

模型组件接口是引擎注册和调度组件的通道,引擎通过模型组件接口调用组件,实现相应功能。模型组件的设计和实现必须遵循该接口的规范,其结构定义如图7所示。

图7 模型组件接口结构定义

4)仿真引擎与模型组件的调度流程

模型组件的物理表现形式是Windows标准DLL,通常具有两个加载接口,即创建新对象接口用于创建基本模型组件对象,验证接口用于验证基本模型组件对象的合法有效性。引擎启动后,按模型集成组装逻辑,引擎搜索到某一模型组件,通过组件加载接口,将符合规定的组件加载到引擎中,以实现仿真功能,具体流程如图8所示。

图8 仿真引擎与模型组件管理调度流程

5 结束语

为了满足各种仿真实验的不同需求,快速构建并稳定运行仿真实验系统,本文通过对仿真实验仿真引擎运行中的仿真控制、时间管理、数据交互和模型调度等关键内容进行深入研究,从基本思想、技术与方法体系以及设计、开发与实际运行等方面,提出一套满足联合作战仿真实验需求的仿真引擎运行策略,供仿真实验系统设计和研发人员进行扩展完善,并可按实际需求实现不同目的的仿真实验系统。