CN1169049C - 基于互操作协议的层次式分布仿真运行支撑环境实现方法 - Google Patents

Abstract

本发明公开了一种基于互操作协议的层次式分布仿真运行支撑环境实现方法。目的是解决现有RTI服务器在大规模仿真中易成为影响系统效率的瓶颈、仿真规模受到限制的问题。采用本发明的RTI体系结构为层次式，在网络上部署1个中心RTI服务器，之下设置一组局部RTI服务器，涉及到全局操作的请求由中心RTI协调完成，各局部RTI负责一组仿真盟员的服务请求。RTI服务器及盟员均构建在CORBA中间件之上，RTI服务器之间的通信通过CORBA及内部互操作协议完成，属于不同局部RTI服务器的盟员之间的数据交换采用“精”“粗”两层匹配和过滤策略。本发明既解决了大规模仿真中集中式及功能分布式RTI服务器的瓶颈问题，减少了全局操作的延迟，也为各仿真盟员的时空一致性提供了保障。

Description

基于互操作协议的层次式分布仿真运行支撑环境实现方法

技术领域：本发明涉及分布仿真运行支撑环境的实现方法，尤其是广域网上支持大规模仿真的层次式分布仿真运行支撑环境实现方法。

背景技术：高层体系结构HLA(High Level Architecture)已于2000年9月被定为国际分布仿真通用标准IEEE1516，它为建模与仿真提供了一个通用的技术框架和开放的标准。在HLA中，为实现某种特定的仿真目的而组织到一起，并且能够彼此进行交互作用的仿真系统、支撑软件和其它相关的部件就构成了一个联盟(Federation)；每个参与到联盟中的应用系统称为盟员(Federate)。HLA标准主要由三部分组成：(1)对象模型模板(ObjectModel Templates)；(2)接口规范说明(Interface Specification)；(3)框架与规则(Framework and Rules)。HLA的具体实现为运行支撑环境RTI(RunTime Infrastructure)。RTI(RunTime Infrastructure)是HLA框架的核心，它实现了接口规范中定义的服务，目的是将仿真应用和底层通信等基本功能相分离。由RTI提供对底层通信等基本功能的支持，即在同一联盟执行过程中，所有的盟员按照HLA接口规范说明要求同RTI进行数据交换，实现盟员之间的互操作。RTI提供的功能对于盟员是透明的，盟员不必涉及网络编程，因而可将精力放在应用领域和有关的仿真开发上。同时遵循共同的RTI接口的仿真应用可以灵活地组成功能各异的联盟，有利于构件的重用以满足不同需要。RTI相当于一个分布式操作系统，它为多种类型的仿真间的交互提供了一组通用服务，这些服务主要包括联盟管理(FM)、声明管理(DM)、对象管理(OM)、所有权管理(OWM)、时间管理(TM)、数据分发管理(DDM)六个方面。但HLA只规定了RTI应提供哪些服务功能，并未具体规定应如何实现及部署RTI。作为一个软件整体，人们首先想到的最自然、最直接的实现及部署方式为集中式RTI。集中式RTI是在一个联盟中只部署一个RTI服务器，HLA的所有功能都集中在该RTI服务器上实现。由于HLA规定，盟员之间不能直接通信，盟员之间的所有通信都必须经过RTI，因此，集中式RTI服务器在大规模仿真中容易成为影响系统效率的瓶颈，不利于仿真规模的扩充，不适合大规模仿真的需要。为了解决集中式RTI的效率瓶颈，美国国防部建模与仿真办公室DMSO提出了功能分布式RTI的实现方法。所谓功能分布式RTI即是将RTI的实现分成两部分，一部分称为中心RTI部件CRC(Central RTI Component)，主要负责联盟管理、对象管理中的全局名及全局标识管理、所有权管理以及时间管理中的时间计算等工作，另一部分称为局部RTI部件LRC(Local RTI Component)，主要负责声明管理、对象管理中的对象发现、数据更新、交互等、时间管理中的逻辑时间、消息排序等、以及数据分发管理等功能；在一次分布式仿真中，系统部署一个中心RTI部件CRC，同时在每个盟员中部署一个局部RTI部件LRC，CRC部件、每个LRC部件之间都相互连接。使用功能分布式RTI仿真，要求在CRC和不同的LRC之间维护数据的一致性。随着仿真规模的增大，数据一致性维护十分困难；同时由于在功能分布式RTI的实现中要求CRC、每个LRC之间相互通信，因此以CRC、LRC为节点将组成一个全连通的通信拓扑结构，造成网络中大量的信息交互，导致节点数目受到网络通信的限制，因而仿真规模也受到限制。功能分布式RTI产品有DMSO的RTI 1.3NG-v5、瑞典Pitch公司研制的pRTI等。

发明内容：本发明的目的是针对现有集中式和功能分布式RTI服务器在大规模仿真中容易成为影响系统效率的瓶颈而提出的层次式分布仿真运行支撑环境实现方法，它的实现基于CORBA及内部互操作协议，国内外尚无基于CORBA及内部互操作协议的层次式RTI服务器的报道。所谓层次式RTI是根据仿真规模的不同，在局域网或广域网上部署多个RTI服务器，其中有一个负责全局操作的中心RTI服务器，在中心RTI服务器下设置一组局部RTI服务器，各局部RTI服务器负责一组盟员的服务请求，涉及到全局操作的请求则由中心RTI服务器协调完成。为了解决基于不同软、硬件平台的仿真软件特别是RTI服务器与RTI服务器之间、RTI服务器与RTI盟员之间的互操作性，本发明采用CORBA中间件技术，即RTI服务器及盟员均构建在CORBA中间件之上。CORBA标准是指国际对象管理组织OMG(ObjectManagement Group)发布的基于分布对象技术的公共对象请求代理体系结构(Common Object Request Broker Architecture)，它为分布异构环境下各类应用系统的开发和集成提供了良好的可资遵循的规范和技术标准，得到了包括IBM、SUN、HP、Oracle等大公司在内的800多家计算机厂商和研究机构的支持。CORBA为位于操作系统和应用程序之间的软件，通过“Internet互操作协议IIOP”实现了基于不同操作系统平台以及不同程序设计语言的应用程序之间的互操作。大多数RTI系统需要实现网络环境下的多个仿真盟员和多个RTI服务器之间的互操作，这些仿真盟员以及RTI服务器可能位于不同的操作系统平台(如Windows或Unix)，并且可能基于不同的程序设计语言(如C++或Java)，通过CORBA中间件，盟员和RTI服务器之间的调用关系如同在一台主机上的同一个应用程序中的多个子程序或函数之间的相互调用，因为网络之间具体的通信细节已经被CORBA中间件很好地解决了。具体说来，CORBA采用“代理”技术来实现分布式应用之间的互操作。代理是在分布环境下能使对象透明地提交请求并接收请求应答的软件。具体地说，本地程序与异地程序的互操作是通过异地程序在本地的代理完成的，对本地程序来说，通过代理调用异地程序就好像调用本地程序一样方便。代理中必须包含程序之间进行互操作的接口说明。本发明在盟员方设置一个RTI服务器的代理，在RTI服务器方设置一个盟员代理，RTI服务器代理与RTI服务器之间以及盟员代理和盟员之间的网络操作细节由CORBA技术自动实现，不需要盟员编写额外的实现代码，盟员和RTI服务器之间以及RTI服务器与RTI服务器之间的调用关系如同在一台主机上的同一个应用程序中的多个子程序或函数之间的相互调用。

本发明体系结构如下：整个系统由中心RTI服务器、局部RTI服务器、仿真盟员三个层次组成，在局域网或广域网上部署多个RTI服务器，其中一个为中心RTI服务器，负责全局操作，在中心RTI服务器之下设置一组局部RTI服务器，每个局部RTI服务器负责一组仿真盟员的服务请求；各局部RTI服务器与中心RTI服务器构成一个逻辑整体，对盟员来讲这个逻辑整体如同一个集中式RTI服务器。盟员只需向管理自己的RTI服务器请求服务，不必关心RTI服务器之间的内部通信。整个系统由一个中心RTI服务器和多个局部RTI服务器组成，每个局部RTI服务器负责处理若干个仿真盟员的请求并将请求的结果及时回调给盟员。每个盟员只看到一个RTI服务器，这个RTI服务器通常称作该盟员的“本地RTI服务器”。如果一个盟员需要与不同的RTI服务器上的盟员进行信息交换，则由这两个盟员的本地RTI服务器进行协商；与全局相关的信息状态和控制则与中心RTI服务器协商解决。本发明对RTI服务器的部署位置不作任何要求，多个RTI服务器可以运行在网络中的不同主机系统中，也可运行在同一个主机系统中，RTI服务器和仿真盟员软件也可以运行于相同或不同的主机系统中。不同RTI服务器可以并发执行，大大提高了整个仿真系统的效率。

在遵循CORBA及内部互操作协议的技术前提下，本发明的具体实现方式可从三个方面来说明，即盟员和RTI服务器之间的互操作、盟员之间的互操作以及RTI服务器之间的互操作。盟员和RTI服务器之间的互操作通过RTI服务器代理和盟员代理来协同完成：盟员向本地RTI服务器代理提出请求，再由该RTI服务器代理将盟员的请求转交给远地RTI服务器，这样就实现了盟员对RTI服务器的请求；RTI服务器将回调的结果传送给盟员代理，再由盟员代理将结果回调给盟员，这样就实现了RTI服务器对盟员的回调。由于HLA规范要求盟员之间不直接通信，必须通过RTI服务器来完成，为了减少盟员开发的复杂性，本发明规定每个盟员只能与一个RTI服务器直接通信，使用同一个RTI服务器的所有盟员位于同一个“组”，同组内的盟员之间的数据交互由本地RTI服务器处理并完成，不同组内的任意两个盟员之间的数据交互则通过各自的本地RTI服务器来完成；盟员不与中心RTI服务器直接通信，所有的本地RTI服务器相对于中心RTI服务器而言都是“局部RTI服务器”。每个RTI服务器都定义了两套互操作接口，一套接口遵循IEEE1516标准，用于盟员和RTI服务器的之间的交互；另一套接口为完成局部RTI服务器与局部RTI服务器之间以及局部RTI服务器与中心RTI服务器之间的交互提供服务，主要包括对应联盟管理的相关接口、对应对象管理中的全局名及全局标识管理的相关接口、对应所有权管理的相关接口、对应时间管理中的时间计算的相关接口。

从仿真的过程来看，基于本发明的整个系统的工作流程可大致分为启动、执行和结束三个阶段。在启动阶段主要完成联盟的创建、盟员加入联盟、初始化数据、预先设定盟员能够公布的信息以及盟员需要定购的信息等工作。在整个系统中，只有最先参加仿真的盟员程序能够创建联盟，这个盟员通常是管理整个仿真的盟员，称为管理盟员。当一个盟员向本地RTI服务器请求创建联盟执行时，局部RTI服务器调用中心RTI服务器中的创建联盟执行服务在中心RTI上创建联盟执行，中心RTI服务器告知其它局部RTI服务器，联盟执行已经创建，这样其它的盟员就可以通过本地RTI服务器加入联盟执行。在创建联盟执行时，需要向RTI服务器提供此次仿真的初始化数据文件，每个RTI服务器都会根据同一个初始化数据文件生成全联盟一致的各类数据列表，例如，RTI服务器要为参加此次仿真的所有对象类生成一个对象类列表，所有RTI服务器的对象类列表完全一样，因此各个RTI服务器上的很多工作根据本地保存的数据信息就可以做出判断，不需要与其它RTI服务器协商，也不需要中心RTI服务器的协调，大大减少了广域网上局部RTI服务器与中心RTI服务器之间的通讯量及中心RTI服务器上的计算量。在RTI服务器完成初始化工作且盟员加入联盟之后，盟员就可以告知本地RTI服务器它能够公布的信息以及需要定购的信息，本地RTI服务器需要把盟员的“公布/定购”信息进一步告知其它的RTI服务器。启动阶段完成后，就进入仿真的执行阶段。仿真的执行阶段通常是一个循环执行的过程，盟员按照HLA接口规范提供的服务向RTI服务器发送请求，RTI服务器根据系统的当前状态对盟员的请求做出响应，并把请求的结果回调给盟员。整个过程是：盟员向RTI服务器请求时间的推进，如果RTI同意其推进，则盟员推进到相应的时间，否则盟员的推进请求被挂起，直到RTI服务器认为该盟员可以推进时才允许其推进。在时间推进被允许后，盟员能够做各类操作，除了完成本地的计算外，可以进一步要求“公布/定购”信息、可以登记或删除自己创建的对象、可以更新对象的属性值、可以发送特定的交互(例如“开火”等事件)。本地RTI服务器在接收到盟员的请求后，如果认为该请求能够自行解决，则把相应结果回调给本地盟员；如果本地RTI服务器认为该请求涉及到与全局状态相关的信息，则把请求传送给中心RTI服务器，由中心RTI服务器与局部RTI服务器协同解决；如果本地RTI服务器认为不需要中心RTI服务器参与，则可与请求相关的远地RTI服务器协同解决。当仿真任务完成后，联盟就进入结束阶段，盟员向本地RTI服务器请求退出联盟执行，当局部RTI服务器上所有盟员都退出联盟执行后，局部RTI服务器从中心RTI服务器中退出，同时删除局部RTI服务器上的联盟执行，当所有局部RTI服务器都从中心RTI服务器中退出后，删除中心服务器上的联盟执行。

在HLA中，仿真盟员之间的信息交换通过“公布/定购”的方式来进行。如果一个盟员向RTI提供的公布信息正是另外一个盟员向RTI所定购的信息，那么这两个盟员之间就建立了“公布/定购”关系。当公布盟员向RTI提出需要更新所公布的信息时，RTI通过已建立的“公布/定购”关系能够正确地将更新后的信息告知定购盟员。信息的“公布/定购”方式有两种：一种是基于“区域”的方式；一种是基于“类”的方式。例如，在高射炮打飞机的仿真中，基于“类”的“公布/定购”方式是指如果高射炮定购了飞机的信息，那么不论飞机飞到什么位置，只要飞机向RTI服务器提供了新的更新信息(如位置、方向和速度等参数)，RTI服务器都必须告知高射炮；而在基于“区域”的“公布/定购”方式中，飞机只公布特定空间区域的信息，高射炮只定购周围有限区域(如方圆5km)的信息，只有当飞机的公布区域和高射炮的定购区域相交时，即飞机进入了高射炮的定购区域，RTI服务器才把飞机的更新信息告知高射炮，这样就大大减少了无关数据在网络中的传输，提高了系统的性能。在HLA中，将RTI计算公布区域和定购区域是否相交的过程称之为“匹配和过滤”策略，只有相交区域的信息才会返回给定购盟员，不相交区域的信息则被过滤掉了。

在运用了本发明的RTI系统中存在多个RTI服务器，一个盟员的公布区域的信息既可能是本地RTI服务器上的盟员所感兴趣的信息，也可能是远地RTI服务器上的盟员所感兴趣的信息。而每个盟员只能看到本地RTI服务器，因此，当本地盟员“公布”的信息由远地RTI服务器上的盟员“定购”时，则这个本地盟员的区域信息必须由本地的RTI服务器传递给远地的RTI服务器，由远地的RTI服务器进行区域的匹配和过滤。

本发明基于“区域”的“公布/定购”方式中属于不同局部RTI服务器的仿真盟员之间的数据交换采用“精”“粗”两层匹配和过滤策略，其过程是：当RTI服务器i上的若干公布盟员更新多个区域的信息时，这些更新了的“本地公布区域信息”首先与本地RTI服务器上的盟员提供的“本地定购区域”进行“精匹配”，如果匹配成功，则将更新信息告知本地的定购盟员。“精”相对于“粗”而言，“精”表示每个盟员的信息都能够加以区分，而“粗”则表示多个盟员的信息合并之后的结果，将多个盟员的信息合并为一个集合再传输到远地RTI服务器，可有效地减少信息的传输次数，从而提高系统的效率。远地RTI服务器j上的若干定购盟员提供的“本地定购区域信息”合并之后形成“粗定购区域信息”并通过网络传递给RTI服务器i。然后，RTI服务器i上的“本地公布区域信息”再与来自远地RTI服务器j上的“粗定购区域信息”进行“粗匹配”，如果粗匹配成功，则表示远地RTI服务器j上一定有盟员对RTI服务器i上的“本地公布区域信息”感兴趣，于是RTI服务器i将匹配成功后的“本地公布区域信息”传递给RTI服务器j，在RTI服务器j中，这些“匹配成功的远地公布区域信息”再与“本地定购区域信息”进行“精匹配”，并将匹配成功后的信息告知给RTI服务器j中的盟员。当某一盟员的订购区域发生变化时，重新合并订购信息，如果合并后区域没有发生变化，则不需进行粗匹配；否则，将合并后的订购区域通过网络传递给远地RTI服务器，与远地RTI服务器的公布区域进行匹配，即粗匹配，然后，只有匹配成功才将远地RTI服务器的公布区域发送到重叠的订购RTI服务器上进一步与其上的精确订购信息逐一匹配，并根据匹配结果确定其后属性更新的接收盟员。

本发明基于“类”的“公布/定购”方式中属于不同局部RTI服务器的仿真盟员之间的数据交换也采用“精”“粗”两层匹配和过滤策略，其过程是：当定购盟员向本地RTI服务器请求定购特定的信息时，本地RTI服务器将本地的各个盟员的定购信息合并成一个集合，称为“本地定购集合”；传递给远地RTI服务器，该集合就成为远地RTI服务器的“远地定购集合”。这样，当公布盟员向本地RTI服务器i请求更新信息时，本地RTI服务器i通过对“本地定购集合”进行精匹配和“远地定购集合”进行粗匹配，就可以知道有哪些本地盟员及远地RTI服务器需要获取更新后的信息，从而通过网络将更新后的信息传递给本地盟员及远地RTI服务器；远地RTI服务器j通过对自己的“本地定购集合”进行精匹配将更新后的信息传送给本地定购盟员。将多个公布或定购请求捆绑为一个集合，再从本地RTI服务器发送给远地RTI服务器，在匹配时先对“远地定购集合”进行粗匹配，匹配成功后再由远地RTI服务器根据自己的“本地定购集合”进行精匹配，这样大大减少了网络中的消息数。

本发明的核心是基于CORBA和内部互操作协议实现层次式RTI，采用本发明可达到以下有益效果：

1、由于层次结构中的不同RTI服务器可以并发执行，提高了仿真系统的效率，解决了大规模仿真中集中式及功能分布式RTI服务器的瓶颈问题；

2、由于设置了中心RTI服务器，时间管理中的时间计算等工作由中心RTI服务器统一完成，为广域网上各仿真盟员的时间一致性提供了保障；

3、由于采用CORBA及内部互操作协议，无须考虑网络通信细节，可以集中精力设计和实现系统的功能，大大减少了分布式应用系统开发的工作量，提高了分布式应用系统的开发效率，适合于大规模、多层次的分布式仿真需要，而且整个系统具有很好的可重用性、移植性和互操作性，可极大提高分布式应用系统的开发效率。

4、属于不同局部RTI服务器的仿真盟员之间的数据交换采用的“精”“粗”两层匹配和过滤策略，大大减少了网络中的消息数，节约了网络带宽并且节省了时间，提高了效率。

本发明可以有效地解决大规模仿真中集中式及功能分布式RTI服务器的瓶颈问题，减少全局操作的延迟，同时也为广域网上各仿真盟员的时间一致性提供保障。

附图说明：

图1是集中式RTI体系结构图；

图2是功能分布式RTI体系结构图；

图3是本发明体系结构图；

图4是本发明基于CORBA中间件技术的总体逻辑结构图；

图5是本发明工作流程图；

图6是本发明基于“区域”的“公布/定购”方式示意图；

图7是本发明基于“类”的“公布/定购”方式示意图。

具体实施方式：

图1描述了集中式RTI体系结构：整个系统部署一个中心RTI服务器，中心RTI服务器需要实现HLA的所有功能。由于HLA规定，盟员之间不能直接通信，因此盟员之间的所有通信都必须经过中心RTI服务器。集中式RTI服务器在大规模仿真中容易成为影响系统效率的瓶颈，不利于仿真规模的扩充，不适合大规模仿真的需要。

图2描述了功能分布式RTI体系结构：整个系统没有一个完整的RTI服务器，RTI的功能被分解为中心RTI部件和局部RTI部件两个组成部分。参加仿真的每个盟员都有一个局部RTI部件，所有盟员的局部RTI部件与中心RTI部件组合在一起构成一个逻辑上的RTI服务器。中心RTI部件和所有局部RTI部件必须两两互连，从而构成一个全连通的网络拓扑结构图。数据一致性维护需要中心RTI部件和所有局部RTI部件协同完成，因而功能分布式RTI容易造成网络中大量信息交互，导致节点数目受到网络通信的限制，从而仿真规模受到限制。

图3描述了本发明体系结构：整个系统由一个中心RTI服务器和多个局部RTI服务器组成，每个局部RTI服务器负责处理若干个仿真盟员的请求并将请求的结果及时回调给盟员。仿真盟员n1～仿真盟员nk只看到局部RTI服务器n，RTI服务器n称作盟员n1～nk的“本地RTI服务器”。盟员n1～nk之间的信息交换由RTI服务器n解决；如果盟员ni需要与RTI服务器1上的盟员li进行信息交换，则本地RTI服务器n和远地RTI服务器1进行协商；与全局相关的信息状态和控制则由局部RTI服务器n与中心RTI服务器协商解决。RTI服务器的部署位置不作任何要求，多个RTI服务器可以运行在网络中的不同主机系统中，也可以运行在同一个主机系统中；RTI服务器和仿真盟员软件也可以运行于相同或不同的主机系统中。

图4描述了本发明基于CORBA中间件技术总体逻辑结构：网络环境下有多个仿真盟员和多个RTI服务器，这些仿真盟员以及RTI服务器可能位于不同的操作系统平台(如Windows/Unix)，并且可能基于不同的程序设计语言(如C++/Java)，这些仿真盟员和RTI服务器之间都通过网络进行互操作。CORBA中间件为位于操作系统(如Windows/Unix)和应用程序(如C++/Java)之间的软件。通过CORBA中间件，盟员和RTI服务器之间的调用关系如同在一台主机上的同一个应用程序中的多个子程序或函数之间的相互调用，因为网络之间具体的通信细节已经被CORBA中间件很好地解决了。

图5描述了本发明的工作流程：整个工作流程可分为启动、执行和结束三个阶段。启动阶段主要完成联盟的创建、盟员加入联盟、初始化数据、盟员能够公布的信息以及盟员需要定购的信息等工作。其中一个非常重要的工作是所有RTI服务器都将按照与仿真任务相关的同一个初始化数据文件生成全联盟一致的各类数据列表。这样各个RTI服务器上的很多工作根据本地保存的数据信息就可以做出判断，不需要与其它RTI服务器协商，也不需要中心RTI服务器的协调，大大减少了广域网上局部RTI服务器与局部RTI服务器、局部RTI服务器与中心RTI服务器之间的通信量及中心RTI服务器上的计算量。仿真的执行阶段通常是一个循环执行的过程，盟员按照HLA接口规范提供的服务向RTI服务器发送请求，RTI服务器根据系统的当前状态对盟员的请求做出响应，并把请求的结果回调给盟员。盟员只能向本地RTI服务器发送请求，并由本地RTI服务器与其它RTI服务器协同完成盟员的请求。当仿真任务完成后，联盟就进入结束阶段。在结束阶段，盟员向本地RTI请求退出联盟执行，局部RTI服务器必须等到所有本地盟员都退出联盟执行后才能够退出；所有局部RTI服务器都退出联盟执行后，中心RTI服务器才能够退出联盟执行，从而结束整个仿真任务。

图6描述了本发明基于“区域”的“公布/定购”方式示意图。它示意了RTI服务器i上的公布盟员和RTI服务器j上的定购盟员之间的信息交互过程：当RTI服务器i上的若干公布盟员更新多个区域的信息时，这些更新了的“本地公布区域信息”首先与本地RTI服务器上的盟员提供的“本地定购区域”进行“精匹配”，如果匹配成功，则将更新信息告知本地的定购盟员。“精”相对于“粗”而言，“精”表示每个盟员的信息都能够加以区分，而“粗”则表示多个盟员的信息合并之后的结果，将多个盟员的信息合并为一个集合再传输到远地RTI服务器，可有效地减少信息的传输次数，从而提高系统的效率。远地RTI服务器j上的若干定购盟员提供的“本地定购区域信息”合并之后形成“粗定购区域信息”并通过网络传递给RTI服务器i。然后，RTI服务器i上的“本地公布区域信息”再与来自远地RTI服务器j上的“粗定购区域信息”进行“粗匹配”，如果粗匹配成功，则表示远地RTI服务器j上一定有盟员对RTI服务器i上的“本地公布区域信息”感兴趣，于是RTI服务器i将匹配成功后的“本地公布区域信息”传递给RTI服务器j，在RTI服务器j中，这些“匹配成功的远地公布区域信息”再与“本地定购区域信息”进行“精匹配”，并将匹配成功后的信息告知给RTI服务器j中的盟员。当某一盟员的订购区域发生变化时，重新合并订购信息，如果合并后区域没有发生变化，则不需进行粗匹配；否则，将合并后的订购区域通过网络传递给远地RTI服务器，与远地RTI服务器的公布区域进行匹配，即粗匹配，然后，只有匹配成功才将远地RTI服务器的公布区域发送到重叠的订购RTI服务器上进一步与其上的精确订购信息逐一匹配，并根据匹配结果确定其后属性更新的接收盟员。由此可知，本发明所采用的“精”“粗”两层匹配和过滤策略，有效提高了系统的效率。

图7描述了本发明基于“类”的“公布/定购”方式示意图。它示意了RTI服务器i上的公布盟员和RTI服务器j上的定购盟员之间的信息交互过程：当定购盟员向本地RTI服务器j请求定购特定的信息时，本地RTI服务器j将本地的各个盟员的定购信息合并成一个集合，称为“本地定购集合”，传递给远地RTI服务器i，该集合就成为远地RTI服务器i的“远地定购集合”。这样，当公布盟员向本地RTI服务器i请求更新信息时，本地RTI服务器i通过对“本地定购集合”进行精匹配和“远地定购集合”进行粗匹配，就可以知道有哪些本地盟员及远地RTI服务器需要获取更新后的信息，从而通过网络将更新后的信息传递给本地盟员及远地RTI服务器；远地RTI服务器j通过对自己的“本地定购集合”进行精匹配将更新后的信息传送给本地定购盟员。将多个公布或定购请求捆绑为一个集合，再从本地RTI服务器发送给远地RTI服务器，在匹配时先对“远地定购集合”进行粗匹配，匹配成功后再由远地RTI服务器根据自己的“本地定购集合”进行精匹配，大大减少了网络中的消息数。

本发明可以作为大规模分布式交互应用的基础支撑平台，如网上军事演习、战术演练、新概念武器效能评估、网上游戏、远程教育等。本发明实现IEEE1516标准规定的所有功能，具有效率高、延迟小、使用方便、可扩展性好等特点，采用本发明实现的系统能支持广域网上大规模分布式交互仿真，并支持异构平台的互联互通。

Claims (3)

1.一种基于互操作协议的层次式分布仿真运行支撑环境实现方法，用于分布仿真标准高层体系结构HLA(High Level Architecture)的运行支撑环境(RunTime Infrastructure)RTI的实现，实现时多个RTI服务器和仿真盟员通过网络互连，各RTI服务器实现IEEE1516标准规定的管理功能，仿真盟员之间的信息交换通过“公布/定购”的方式来进行，包括基于“区域”的方式和基于“类”的方式，其特征在于采用本发明的RTI体系结构是层次式的，即整个系统由中心RTI服务器、局部RTI服务器、仿真盟员三个层次组成，根据仿真规模的不同，在局域网或广域网上部署多个RTI服务器，其中一个为中心RTI服务器，负责全局操作，在中心RTI服务器下设置一组局部RTI服务器，每个局部RTI服务器负责一组仿真盟员的服务请求，涉及到全局操作的请求则由中心RTI服务器协调完成；各局部RTI服务器与中心RTI服务器构成一个逻辑整体，对盟员来讲这个逻辑整体如同一个集中式RTI服务器，每个盟员只看到该盟员的本地RTI服务器；如果一个盟员需要与不同的RTI服务器上的盟员进行信息交换，则由这两个盟员的本地RTI服务器进行协商；与全局相关的信息状态和控制则与中心RTI服务器协商解决；RTI服务器及盟员均构建在CORBA中间件之上，RTI服务器之间、RTI服务器与盟员之间的通信通过CORBA中间件及内部互操作协议完成，运用CORBA的代理技术实现盟员和RTI服务器之间的相互访问；属于不同局部RTI服务器的仿真盟员之间的数据交换采用“精”“粗”两层匹配和过滤策略：

1.1 基于“区域”的“公布/定购”方式中属于不同局部RTI服务器的仿真盟员之间的数据交换采用“精”“粗”两层匹配和过滤策略：当RTI服务器i上的若干公布盟员更新多个区域的信息时，这些更新了的“本地公布区域信息”首先与本地RTI服务器上的盟员提供的“本地定购区域”进行“精匹配”，如果匹配成功，则将更新信息告知本地的定购盟员；“精”相对于“粗”而言，“精”表示每个盟员的信息都能够加以区分，而“粗”则表示多个盟员的信息合并之后的结果；远地RTI服务器j上的若干定购盟员提供的“本地定购区域信息”合并之后形成“粗定购区域信息”并通过网络传递给RTI服务器i；然后，RTI服务器i上的“本地公布区域信息”再与来自远地RTI服务器j上的“粗定购区域信息”进行“粗匹配”，如果粗匹配成功，则表示远地RTI服务器j上一定有盟员对RTI服务器i上的“本地公布区域信息”感兴趣，于是RTI服务器i将匹配成功后的“本地公布区域信息”传递给RTI服务器j，在RTI服务器j中，这些“匹配成功的远地公布区域信息”再与“本地定购区域信息”进行“精匹配”，并将匹配成功后的信息告知给RTI服务器j中的盟员；当某一盟员的订购区域发生变化时，重新合并订购信息，如果合并后区域没有发生变化，则不需进行粗匹配；否则，将合并后的订购区域通过网络传递给远地RTI服务器，与远地RTI服务器的公布区域进行粗匹配，然后，只有匹配成功才将远地RTI服务器的公布区域发送到重叠的订购RTI服务器上进一步与其上的精确订购信息逐一匹配，并根据匹配结果确定其后属性更新的接收盟员。

1.2 基于“类”的“公布/定购”方式中属于不同局部RTI服务器的仿真盟员之间的数据交换采用“精”“粗”两层匹配和过滤策略：当定购盟员向本地RTI服务器j请求定购特定的信息时，本地RTI服务器j将本地的各个盟员的定购信息合并成一个集合，称为“本地定购集合”；传递给远地RTI服务器i，该集合就成为远地RTI服务器i的“远地定购集合”；当公布盟员向本地RTI服务器i请求更新信息时，本地RTI服务器i通过对“本地定购集合”进行精匹配和“远地定购集合”进行粗匹配，就可以知道有哪些本地盟员及远地RTI服务器需要获取更新后的信息，从而通过网络将更新后的信息传递给本地盟员及远地RTI服务器；远地RTI服务器j通过对自己的“本地定购集合”进行精匹配将更新后的信息传送给本地定购盟员。

2.如权利要求1所述的基于互操作协议的层次式分布仿真运行支撑环境实现方法，其特征在于RTI服务器及盟员均构建在CORBA中间件之上，所述盟员、局部RTI服务器、中心RTI服务器之间的互操作遵循CORBA及内部互操作协议，并运用了CORBA的代理技术实现盟员和RTI服务器之间的相互访问：在盟员方设置一个RTI服务器代理，在局部RTI服务器方设置一个盟员代理，盟员向本地RTI服务器代理提出请求，再由本地RTI服务器代理将盟员的请求转交给RTI服务器以实现盟员对RTI服务器的请求；RTI服务器将结果交给盟员代理，再由盟员代理将结果转交给盟员以实现RTI服务器对盟员的回调；每个盟员只与一个RTI服务器直接通信，使用同一个RTI服务器的所有盟员位于同一个“组”，同组内的盟员之间的数据交互由本地RTI服务器处理并完成；不同组内的任意两个盟员之间的数据交互则通过各自的本地RTI服务器来完成；盟员不与中心RTI服务器直接通信，所有的本地RTI服务器相对于中心RTI服务器而言都是“局部RTI服务器”；每个RTI服务器在实现时都定义了两套互操作接口，一套接口遵循IEEE1516标准，用于盟员和RTI服务器之间的交互(中心RTI服务器可不提供该接口)；另一套接口为完成局部RTI服务器与局部RTI服务器之间以及局部RTI服务器与中心RTI服务器之间的互操作提供服务，主要包括对应联盟管理的相关接口、对应对象管理中的全局名及全局标识管理的相关接口、对应所有权管理的相关接口、对应时间管理中的时间计算的相关接口。

3.如权利要求1所述的基于互操作协议的层次式分布仿真运行支撑环境实现方法，其特征在于所述层次式RTI工作流程可分为启动、执行和结束三个阶段，在启动阶段主要完成联盟的创建、盟员加入联盟、初始化数据、预先设置盟员能够公布的信息以及盟员需要定购的信息等工作；在运行盟员程序之前首先启动管理盟员，管理盟员启动后向本地局部RTI服务器请求创建联盟执行，本地局部RTI服务器调用中心RTI服务器中的创建联盟执行服务在中心RTI上创建联盟执行，中心RTI服务器告知其它局部RTI服务器，联盟执行已经创建，这样其它的盟员就可以通过本地RTI服务器加入联盟执行；在创建联盟执行时，需要向RTI服务器提供此次仿真的初始化数据文件，每个RTI服务器都根据同一个初始化数据文件生成全联盟一致的各类数据列表，各个RTI服务器上的很多工作根据本地保存的数据信息就可以做出判断；在RTI服务器完成初始化工作且盟员加入联盟之后，盟员就可以告知本地RTI服务器它能够公布的信息以及需要定购的信息，本地RTI服务器需要把盟员的“公布/定购”信息进一步告知其它的RTI服务器；执行阶段通常是一个循环执行的过程，盟员按照HLA接口规范提供的服务向RTI服务器发送请求，RTI服务器根据系统的当前状态对盟员的请求做出响应，并把请求的结果回调给盟员，具体过程是：盟员向RTI服务器请求时间的推进，如果RTI同意其推进，则盟员推进到相应的时间，否则盟员的推进请求被挂起，直到RTI服务器认为该盟员可以推进时才允许其推进；在时间推进被允许后，盟员能够做各类操作，除了完成本地的计算外，可以进一步要求“公布/定购”信息、可以登记或删除自己创建的对象、可以更新对象的属性值、可以发送特定的交互；本地RTI服务器在接收到盟员的请求后，如果认为该请求能够自行解决，则把相应结果回调给本地盟员；如果本地RTI服务器认为该请求涉及到与全局状态相关的信息，则把请求传送给中心RTI服务器，由中心RTI服务器与局部RTI服务器协同解决；如果本地RTI服务器认为不需要中心RTI服务器参与，则可与请求相关的远地RTI服务器协同解决；当仿真任务完成后，联盟就进入结束阶段，盟员向本地RTI服务器请求退出联盟执行，当局部RTI服务器上所有盟员都退出联盟执行后，局部RTI服务器从中心RTI服务器中退出，同时删除局部RTI服务器上的联盟执行，当所有局部RTI服务器都从中心RTI服务器中退出后，删除中心服务器上的联盟执行。

Images