神州普惠

分布仿真实验管理系统中HLA代理的设计及实现

  分布仿真实验管理系统(DSEMS)[1]是对分布仿真实验全过程全系统进行管理的分布式系统,包括实验软硬件环境管理、实验的设计、部署、调度和监控等管理功能。DSEMS的研究和投入使用极大简化了分布仿真系统运行过程和使用程序,提高了自动化程度和效率。

  DSEMS管理着分布仿真系统的运行,但并不受限于具体的仿真体制,理论上可以管理任何一种分布式系统的实验或运行;另一方面DSEMS也需要获取其管理的分布式系统内部的信息以便进行更精确的控制,特别是在多次自动重复运行系统的情况。因此需要在DSEMS内部建立一个与分布式系统通信的渠道。

  目前应用最广泛的是基于HLA标准的分布式系统,基于HLA的仿真应用系统(联邦,Federation)由运行的多个仿真程序(成员,Federate)组成,它们分布在通过网络互联的多个计算节点上并加入到同一个联邦中运行。DESMS在内部嵌入一个HLA代理模块,其任务就是在DSEMS和仿真系统联邦之间建立一个通信渠道,获取仿真程序作为联邦成员的相关参数和状态以及直接向成员发布联邦层面的控制命令和获取反馈。HLA代理在DSEMS中的位置及作用

  如图1所示。

  

 

 

  论文首先总结了对于HLA代理的基本要求,然后详细研究了HLA代理中两个重要支撑技术的细节,最后结合嵌入运行控制工具[2]的要求给出了HLA代理程序模型的设计

  1、 HLA代理的基本要求

  1.1实现方式

  HLA代理本质上是一个成员,同时又是DSEMS的一部分,所以在实现方式上应该是动态库而不能是常见的应用程序方式的成员,而且动态库的接口要满足DSEMS的需求和能够嵌入运行控制工具运行。

  1.2代理的成员模型

  HLA代理的成员模型包括内部处理逻辑和公布定购关系。HLA代理本身并不仿真任何实体模型,其主要任务是获取所有其它成员的状态信息和报告,推进自身的仿真时间,将所有信息报告给DSEMS并在其操作下向其它成员发布命令。HLA代理的公布定购关系包括标准的MOM和作为DSEMS标准FOM组成部分的管理控制命令交互,这些交互必须作为应用DSEMS的仿真系统FOM的一部分,并且其它成员必须对其进行接收、处理和响应。

  1.3成员参数和状态的获取

  获取成员的参数和状态可以使DSEMS了解成员的运行情况,并根据其运行情况实时进行管控。关键的成员状态包括:成员的加入和退出、成员的初始化状态。关键的成员参数主要是成员的时间,其时间随仿真过程的推进而递增。成员的这些状态和参数的获取通过定购相应的对象类和交互类获得,这些数据的发送源包括各成员自身和成员的RTI本地组件(LRC)。

  1.4联邦时间的获取

  在HLA仿真系统中并不存在统一的联邦时间的概念,每个成员都可以有自己不同的时间,这些时间与成员各自的时间管理策略的设置保证了在任何时刻任何成员都是满足时间因果关系的。但用户往往又需要一个大致的仿真时间,特别是用以衡量系统运行速度。为了满足这个需求,HLA代理必须以一定的步长推进时间,将自身的时间和通过MOM获取的其它各成员的时间报告给DSEMS,由DSEMS综合各时间估算当前联邦时间。

  1.5代理的实例化

  理论上DSEMS可以拥有多个代理实例,这些代理可以来自不同的代理类,并且指向不同的联邦。除了在程序模型上对每个代理实例进行区分之外,在代理内部必需获取本次实验中本代理所负责部分的联邦的名称、所有成员的名称及成员的初始化信息,这些信息必需在代理实例化时传递给代理对象。

  2、管理对象模型的应用

  2.1基本使用

  Management Object Moda(lMOM)管理对象模型是HLA标准中为了对联邦和成员进行运行时监控所设立的对象模型标准,由交互类和对象类组成。MOM对象类由RTI负责维护,其所有实例的注册、删除、更新属性都由RTI完成而无需用户干预。MOM对象类的使用与普通的对象类并无不同,也包括初始化句柄、定购、发现实例、反射属性和删除实例等过程[3]。MOM对象类包括联邦和成员类,代理中使用成员类。

  2.2成员对象实例的注册和删除

  MOM成员对象类的每个实例代表加入联邦的每个成员,在成员加入时由RTI创建,成员退出时由RTI删除,运行中根据设置的报告周期定时更新成员相关属性。通过定购MOM成员对象类,可以由该类对象实例的发现和删除回调函数实时获取联邦中成员的加入退出情况,并进一步通过请求和接收该类的“成员名称”属性更新确定是哪个成员加入和退出。实验方案[4]描述了组成实验的各进程的信息,包括这些进程由哪个节点上的哪个应用程序的运行代表以及这些进程对应的成员名称等,通常将实验进程称为仿真任务,在HLA系统中任务与成员通过成员名称一一对应。DSEMS在调度实验启动停止时需要了解各仿真任务的进程创建和退出,以确定实验是否正确进行。另一方面还需要了解组成实验联邦的各仿真成员是否正确加入和退出,例如仿真启动命令要在所有成员都加入且正确初始化之后才能发布,这就必须要通过对成员对象类实例的监视来获取相关信息。由于实验联邦的名称是可变的,而HLA中多个联邦运行之间通过名称来区分,如果仿真任务对应的成员加入的联邦名称与代理所使用的联邦名称不同,则两者实际上会加入到不同的联邦,从而无法通过RTI通信导致不正确的实验运行。因此要求在实验方案中描述实验所使用的联邦名,并且在所有仿真任务包括代理之间共享联邦名。代理使用的联邦名在代理实例化时由DSEMS传递,而各任务使用的联邦名则通过实验运行控制工具[2]向节点守护端[5]传递启动参数,并由守护端在创建仿真任务进程时通过命令行参数传递给成员,最终由成员程序解析命令行参数并用于加入联邦。这里对成员的命令行参数也提出了标准化要求,默认的标准是:联邦名成员名FED文件名成员特有参数。

  2.3属性更新的使用

  MOM成员对象类属性更新有两种方式:请求更新和设置自动更新。在第一次发现一个成员对象实例时一般要做一次请求更新以获取成员的名称、句柄、节点等属性,在获取这些属性之后可以设置自动更新,由LRC按照设置的自动更新周期定时发送成员属性以便于获取变化的属性,设定的周期以墙钟时间而不是逻辑时间为单位。获取的信息将反馈给DSEMS,后者通过成员的时间等来计算系统时间和推进速度,还可以通过成员、节点、任务

  的匹配关系进行错误检查。

  DSEMS可以控制实验方案中所描述的所有节点上的任务的运行和结束,而且按照成员设计要求,所有成员必须根据DSEMS所给定的参数加入联邦,这样就可以基本保证成员和任务的一一对应。但对于设计错误的成员(如:不接收初始化参数而使用固定的成员名),或者对于有多个操作控制入口的运行环境(除了DSEMS之外还有其它节点可以运行成员),很可能发生运行的系统其组成与方案描述不同的情况,导致实验运行失败甚至发生错误。为此,在成员名称之外还需要进一步明确成员与任务之间的关系。任务描述中指定任务所运行的节点IP地址与MOM成员对象类中的成员主机(host)属性必须一致,通过检查两者对应关系可以将成员与方案中仿真任务的对应错误锁定在每个节点范围。

  3、管控交互的设计和使用流程

  几乎所有的分布仿真系统都需要在运行过程中对成员进行控制,典型的控制动作包括加载想定、启动、停止、暂停、继续等,这些控制动作一般以交互的方式定义和实施。在没有DSEMS的时候,这些控制一般由操作人员通过特定的运行管理工具来发布。在DSEMS控制的系统运行中,特别是在要求多次自动重复运行的设计情况下,这些控制动作必须自动完成,才能保证整个过程的自动化。所以管控交互也是DSEMS的一部分,并且只能由HLA代理来实现。管控交互本身的定义并无特殊之处,只是其触发过程必须尽可能自动化以简化管理系统本身的设计,从大的流程以及多次运行自动化的角度出发,管控运行的流程如图2所示。

  

 

 

  管控交互中初始化脚本交互里的想定内容来源必须由DSEMS提供。由于方案设计中引用并保存了想定的内容[4],而DSEMS又是通过加载方案来启动实验,所以必须由DSEMS向HLA代理提供成员初始化内容。

  另外正如2.2中所述,成员名称是成员和仿真任务之间的关联,管控交互作为DSEMS通过HLA代理发送到成员的控制命令,成员名称必须是交互中的参数并且是处理交互时区分接收方和发送方的重要信息,所有接收到管控交互的成员必须通过交互中的目标成员名称与自身成员名称的匹配来确定是否是发给自己的命令,而HLA代理所接收到的各成员的管控报告也必须通过成员名称来确定是哪个成员所发并由此判断仿真任务状态。

  4、代理的程序模型设计经过上述分析可以得到HLA代理的结构如图3所示。