分布式仿真高层体系结构(HLA)核心RTI测试与分析

摘要

分布式交互仿真指采用协调一致的结构、标准、协议和数据库，通过局域网和广域网将分布在各地的各种仿真器互连，使人可参与交互作用的一种综合环境。经过几十年的发展，分布式仿真技术目前已成功地应用于医学、军事、航空、设计制造业、建筑、教育及娱乐等众多领域。同时对分布式仿真技术本身的研究也得到了广泛地开展，自从上世纪80年代以来逐步出现了SIMNET、ALSP、DIS、ADS等标准和技术，但是利用这些技术和标准开发的仿真应用只有有限的可重用性和互操作性，不能满足越来越复杂的作战仿真应用。因此为了提高各种仿真应用的可重用性和互操作性，美国国防部于1995年发布了建模与仿真计划，决定在国防部范围内建立一个通用的开放的仿真技术框架，而HLA（High Level Architecture，高层体系结构）是此技术框架的核心。在1996年8月美国国防部完成了HLA 标准的基础定义，并于2000年10月被IEEE接受为IEEE P1516、IEEE P1516.1、IEEE P1516.2系列标准。

HLA标准由规则、接口规范、对象模型模板三部分组成，而RTI（Run-Time Infrastructure，运行时底层结构）是实现HLA标准中接口规范的软件，它以类似于分布式操作系统为应用程序提供服务的方式给仿真应用提供了联邦管理、声明管理、对象管理、时间管理、数据分发管理、所有权管理和支持的服务等七组服务，但是RTI本身并不属于HLA标准。目前有很多研究团体和个人致力于开发RTI软件，现有较为典型的RTI软件包括DMSO RTI，pitch 公司pRTI1.3、pRTI1516，M?K RTI，以及北京航空航天大学的DVE_RTI等，但是这些RTI 软件往往不是共享或开放源代码的。为了满足扩展性的需求，我们根据HLA 1.3接口规范标准自行开发了具有高度可扩展性的RTI软件CADRTI。

CADRTI作为一个软件产品，和其它所有的软件类似，有必要对它进行功能测试从而发现软件本身中的错误和缺陷，CADRTI开发者可以根据功能测试结果来改进软件本身。同时由于CADRTI是根据HLA 1.3开发的软件，因此CADRTI功能测试的主要目的是验证CADRTI与HLA 1.3接口规范的一致性。为了对CADRTI进行功能测试，本文设计并实现了RTIfuncTest功能测试平台，同时为RTI中的每组服务都设计了一系列的测试流程。

在另外一方面HLA接口规范虽然定义了RTI应该实现哪些功能提供哪些服务，但是HLA标准并没有规定这些功能和服务的具体实现方式，因此RTI软件的开发者可以自由选择不同的实现方式（包括不同的网络拓扑结构、进程模型、时间管理算法、数据分发算法等）来实现他们的RTI软件。而不同的内部实现方式则会影响RTI软件的速度、资源需求、稳定性、可扩展性、用户性能等方面的性能指标，而不同的仿真应用具有不同的RTI性能指标要求，因此对RTI软件进行性能测试，提供一组性能指标测试结果，可以帮助RTI软件的用户根据他们的仿真需求选择不同的RTI软件产品。同时对RTI软件的开发者而言，通过对RTI本身进行性能测试和性能分析，可以发现他们的RTI软件产品的性能瓶颈，通过改进影响RTI性能的某些内部实现，可以达到最终提高性能的目的。本文设计了RTIperfTest 和RTIscalabilityTest测试平台，其中RTIperfTest测试平台主要用于测试RTI在延迟、吞吐量、丢包率、CPU资源需求、网络带宽需求以及稳定性等性能指标，而RTIscalabilityTest 测试平台则主要用于测试RTI在可扩展性方面的性能，利用这两个测试平台对DMSO_RTI、DVE_RTI和CADRTI进行了性能测试并得到了一组量化的性能测试结果，同时本文还从CADRTI的内部实现方式包括它所采用的网络拓扑结构、进程模型、时间管理算法、数据分发算法等方面出发，对CADRTI的性能进行了分析。

最后本文利用CADRTI开发了一个符合HLA标准的仿真应用FoodFight，此仿真应用使用了CADRTI提供的所有七组服务，因此这实际上也是对CADRTI进行了应用层次上的

测试，同时通过FoodFight的开发经验，也了解到基于HLA标准的仿真应用的具体开发流程。

关键词：分布式交互仿真，高层体系结构，接口规范，运行时底层结构（RTI），服务，功能测试，性能测试，仿真应用

Abstract

Distributed Interactive Simulation is one kind of synthesized environment which utilizes consistent structures, standards, protocols and databases. In this environment, all kinds of simulators distributed all over the world are connected with each other through local area network and global area network, and human beings can interact with these simulators. After several decades’development, the technology of distributed interactive simulation has been used successfully in various areas including physic, military affairs, education, entertainment and so on. And at the same time, the study of the technology itself has also been widely developed. Since 1980’s, the standards of SIMNET, ALSP, DIS, ADS have been established, but the simulations developed with these technologies have only limited reusability and interoperability, so these standards can not satisfy the requirements of complex simulations. In order to improve the reusability and interoperability of the simulations, the US Department of Defence launched the modelling and simulation plan in 1995 and aimed to construct an open and generalized framework of simulation technology, And High Level Architecture is the key of this framework. On August 1996, the definition of the HLA standard was finished, and on October 2000 it was adopted as the IEEE P1516、IEEE P1516.1、IEEE P1516.2 standards by IEEE.

The HLA standard is consisted of three components: HLA Rules, HLA Interface Specification and Object Model Template. And the software implementing the HLA Interface Specification is Run-Time Infrastructure, which provides the simulations with seven groups of services (Federation Management, Declaration Management, Object Management, Time Management, Data Distribution Management, Ownership Management and Support Services) at the same way as the Distributed Operation System provides services for applications. But the RTI itself is not one part of the HLA standard. At the present time, many researchers are devoted themselves to the development of the RTI software, and the DMSO RTI, pRTI 1.3, pRTI 1516 and M?K RTI are typical RTI software, but most of them are not free or source-opened. To meet the demands of scalability, we have developed our own RTI software: CADRTI which is based on HLA 1.3 and has high scalability.

As a software product, we must carry out function test on CADRTI just like all other software products to find the bugs of it. The developers of CADRTI can ameliorate the software on the basis of function test’s results. And since CADRTI is the software founded on HLA 1.3, so the main purpose of the CADRTI’s function test is to verify the consistency of CADRTI and HLA 1.3 Interface Specification. To implement the function test of the CADRTI, we have realized an RTIfuncTest platform and designed several test flows for each group of services.

On the other side, though the HLA Interface Specification defines what services RTI should provide, it does not prescribed how these services should be implemented in RTI. So the developers of RTI software can choose different interior implementations freely. But different implementations will affect the speed, resource requirement, stability, scalability and user performance of the RTI software. The process and test results of RTI software’s performance test can not only help the users of RTI software to choose different RTI on the basis of the simulations’requirements, but also help the developers of RTI software to find the ways to improve the performance of their RTI software. We have implemented the RTIperfTest and RTIscalabilityTest platform to test RTI’s latency, throughput, loss rate, stability, scalability and so on. At the same

time, this paper analyses the performance of CADRTI from the aspect of the network topology, process model, time management algorithm, and data distributed algorithm.

Finally we have developed a simulation application FoodFight which uses CADRTI and tallies with the HLA 1.3 standard. This simulation has utilized most of the services CADRTI provides, so in fact the FoodFight application is the test of CADRTI on high level.

Keywords: Distributed Interactive Simulation, High Level Architecture, Interface Specification, Run-Time Infrastructure, Services, Function Test, Performance Test, Simulation Application

目录

摘要 (1)

ABSTRACT (3)

目录 (5)

1 第一章绪论 (7)

1.1 分布式交互仿真的发展和HLA的出现 (7)

1.2 HLA概述 (9)

1.2.1HLA的发展及现状 (9)

1.2.2HLA组成框架 (9)

1.2.3HLA的优缺点 (11)

1.3 HLA核心RTI (12)

1.3.1RTI简介 (12)

1.3.2对RTI进行功能性能测试的必要性 (13)

1.4 本文的主要工作 (14)

1.5 论文的组织结构 (14)

2 第二章CADRTI的实现框架 (15)

2.1 CADRTI简介 (15)

2.2 网络拓扑结构 (15)

2.3 软件结构 (16)

2.4 系统工作流程 (16)

2.5 系统模块组成 (18)

3 第三章CADRTI功能测试 (19)

3.1 功能测试简介 (19)

3.1.1功能测试目的 (19)

3.1.2功能测试内容 (19)

3.1.3功能测试方法 (19)

3.2 功能测试平台RTI FUNC T EST (20)

3.3 联邦管理 (21)

3.3.1简介 (21)

3.3.2测试流程与结果 (22)

3.3.3测试结论 (24)

3.4 支持的服务 (25)

3.4.1简介 (25)

3.4.2测试流程与结果 (25)

3.4.3测试结论 (26)

3.5 声明管理 (27)

3.5.1简介 (27)

3.5.2测试流程与结果 (28)

3.5.3测试结论 (29)

3.6 对象管理 (29)

3.6.1简介 (29)

3.6.2测试流程与结果 (30)

3.6.3测试结论 (31)

3.7 所有权管理 (32)

3.7.1简介 (32)

3.7.2测试流程与结果 (32)

3.7.3测试结论 (33)

3.8 时间管理 (34)

3.8.1简介 (34)

3.8.2测试流程与结果 (34)

3.8.3测试结论 (36)

3.9 数据分发管理 (37)

3.9.1简介 (37)

3.9.2测试流程与结果 (37)

3.9.3测试结论 (40)

3.10 CADRTI功能测试结论和经验 (40)

4 第四章CADRTI性能测试与分析 (41)

4.1 RTI性能测试简介 (41)

4.1.1性能测试目的 (41)

4.1.2RTI性能指标 (41)

4.1.3性能测试方法 (43)

4.2 RTI性能分析 (44)

4.2.1网络拓扑结构 (44)

4.2.2进程模型 (45)

4.2.3时间管理算法 (47)

4.2.4数据分发算法 (47)

4.3 CADRTI性能测试平台 (49)

4.3.1性能测试平台RTIperfTest的实现框架 (49)

4.3.2可扩展性测试平台RTIscalabilityT est的实现框架 (52)

4.4 CADRTI性能测试结果以及与DMSO_RTI、北航DVE_RTI 2.0的比较 (53)

4.5 CADRTI性能测试结论 (61)

5 第五章使用CADRTI开发的联邦应用FOODFIGHT (62)

5.1 F OOD F IGHT功能 (62)

5.2 F OOD F IGHT的实现 (62)

5.2.1FED文件 (62)

5.2.2系统工作流程 (63)

5.2.3运行结果 (64)

5.3 F OOD F IGHT开发经验 (65)

6 第六章结论及未来工作 (66)

参考文献 (67)

致谢 (68)

第一章绪论

1.1 分布式交互仿真的发展和HLA的出现

计算机仿真是指用计算机程序来模拟现实世界或虚拟世界的一门综合性技术，它以相似性原理、信息技术、系统技术等专业技术为技术基础，具有的经济、省时、安全、保密、可重用性等特点。同时随着计算机网络技术的快速发展，出现了分布式交互仿真的概念。分布式交互仿真指采用协调一致的结构、标准、协议和数据库，通过局域网和广域网将分布在各地的各种仿真器互连，使人可参与交互作用的一种综合环境。经过几十年的发展，分布式仿真技术已经渗透到了社会生活的各个方面，目前已成功地应用于医学、军事、航空、设计制造业、建筑、教育及娱乐等众多领域。同时对分布式仿真技术本身的研究也得到了广泛地开展，图1.1显示了分布式交互仿真的发展历史，如图所示，自从上世纪80年代以来逐步出现了SIMNET、ALSP、DIS、ADS、HLA等标准和技术，在本小节的剩余部分将简单介绍这些技术和标准并分析它们各自的特性。

图1-1分布式交互仿真发展历史

SIMNET（Simulation Network）：SIMNET是最早的一个分布式交互仿真系统。在二十世纪80年代中期，美国国防部高级国防研究项目组（DARPA，Defence Advanced Research Projects Agency）启动了SIMNET项目，目标是开发一个供军事训练使用的低价格、联网的分布式军用虚拟环境，主要用于仿真训练装甲部队及空军部队的协同作战能力。在SIMNET 中，每个仿真器模拟一架坦克、一架飞机或一辆战车，这些仿真器之间通过计算机网络互相连接，并且通过网络进行信息交互而共存在一个共享的仿真环境中。SIMNET采用了以下四个主要原则：（1）基于战争实体所有权的分布式计算；（2）避免单个关键资源竞争；（3）基于广播通讯方式；（4）所有仿真间共享一个有限的战争实体属性集。到1989年，SIMNET 已将分布于美国和德国的11个基地，包括260个M1A1坦克和布雷德利战车等的仿真器、指挥控制中心和数据处理设备互联，形成了世界上第一个分布式虚拟战场环境。

ALSP（Aggregate-Level Simulation Protocol）：ALSP也是由美国国防部提出的，它的目标是使现有的多个聚合级作战仿真应用可以通过局域网或广域网相互交互。在二十世纪90年代初，DARPA赞助MITRE开始研究如何设计已有的大规模聚合级作战仿真间的通用接口。ALSP系统是MITRE的主要研究成果之一，此系统吸取了SIMNET技术中的一些原则。另外由于聚合级仿真对时间和数据管理有特别的需求，ALSP提供了额外的时间管理服务和数据管理服务来满足这些需求。在ALSP中，有一系列的时间管理服务协调仿真时间并保证仿真事件的因果正确性，同时ALSP允许每个仿真自己选择内部数据表示方法，但是仿真间的共享数据以一种通用的表示方法表示从而确保每个仿真都能准确地使用这些共享数

据。ALSP也得到了广泛的应用，JTC（Joint Training Confederation）是基于ALSP最典型的应用。ALSP的缺点在于它的不灵活性，为了在一个仿真应用中增加一个仿真子系统，可能需要修改原仿真应用中的某些内容。

DIS（Distributed Interactive Simulation）：DIS是基于SIMNET开发的，但是DIS比SIMNET具有更大的通用性。在SIMNET中，仿真中的所有仿真设备都必须是使用相同技术的同一类型设备，但是DIS允许使用不同技术的不同类型仿真器同时存在于仿真中。在1993年，DIS被制定为IEEE 1278系列标准。DIS具有以下基本特点：（1）仿真中具有多个实体；（2）仿真中不存在中心节点；（3）每个仿真节点自治；（4）使用标准通讯协议；（5）仿真节点能对接收信息进行预测；（6）仿真节点在本地维护了其它节点状态。尽管和SIMNET 相比DIS有了很大的改进，但是把DIS应用于开发大规模仿真系统时，还是会出现以下问题：（1）大规模仿真系统对带宽和计算资源的需求很高；（2）在应用层需要对不同的媒体类型进行不同处理；（3）DIS缺少处理静态对象的有效方法；（4）在每个仿真实体上都必须复制所有模型数据和场景数据。

ADS（Advanced Distributed Simulation）：某些仿真应用对时间管理和数据传输率的要求很高，因此DIS并不适用于开发这种类型的仿真应用。ADS是对DIS的改进，它具有和DIS相同的一些基本特点，但是允许仿真运用使用没有包括在DIS标准内的另外一些协议和方法，它能同时支持虚拟、真实和构造性实体。和DIS相比，ADS更抽象化因此灵活性也更大，可以把DIS看成是ADS概念的一个实现，下面将提到的HLA也可以看成是ADS概念的另外一个实现。

SPLINE（Scalable Platform for Large Interaction Networked Environments）：MERL （Mitsubishi Electric Research Laboratories）研究人员设计和实现了SPLINE中间件系统，这个系统有以下这些特点：（1）支持多用户；（2）支持语音交互；（3）支持3D图形界面和声音；（4）支持在运行时动态修改环境配置；（5）在网络层和应用层都具有开发接口。但是由于SPLINE是基于SIMNET和DIS开发的，在DIS系统中存在的很多问题在SPLINE还是存在。

HLA（High Level Architecture）：SIMNET、DIS、ALSP都是同类功能仿真应用（武器平台、模拟仿真器、计算机生成兵力CGF、聚合级仿真模型）互联，只有有限的互操作性，不能满足越来越复杂的作战仿真需求。为此，美国国防部1995年发布了建模与仿真计划，决定在国防部范围内建立一个通用的开放的仿真技术框架，来保证国防部范围内的各种仿真应用之间的互操作性和重用性，以达到根据不同的仿真应用需求，快速、简单、低价地利用可重用仿真组件构建新的复杂仿真应用系统的目的。技术框架的核心是高层体系结构（High Level Architecture）。HLA在1996年8月完成HLA1.3基础定义，随后为北约各国采纳，并于2000年10月被IEEE接受为IEEE P1516、IEEE P1516.1、IEEE P1516.2系列标准。美国国防部规定2001年后所有国防部门的仿真必须与HLA相容。美国国防部开发的新一代联合模拟系统JSMIS（Joint Simulation System）就采用的是HLA框架。JSMIS提供了一个大规模的集成多军种联合作战模拟系统。目的是为了训练高层实战指挥官；建立和发展新的军事战略和战术理论；规范描述和评估作战计划；进行各种作战任务的多兵种实战演习；定义战时军需供应等等。

因此HLA是一个通用的技术框架，它的出现是分布式交互仿真技术不断发展以及分布式交互仿真应用对仿真技术的要求不断提高的结果，它能较好地满足现代仿真对互操作性、可重用性和可扩展性的需求。在HLA出现之后，美国国防部就把它作为所有DoD仿真的技术体系标准，虽然一开始HLA主要被应用于国防军事领域，但随着HLA的不断发展和HLA 技术的日趋成熟，HLA技术在交通、娱乐等其它领域也开始得到了广泛的应用。

1.2 HLA概述

1.2.1 HLA的发展及现状

图1-2简单描述了HLA标准的发展过程。其实HLA标准的开发可以追溯到1994年，当时DARPA组织项目组中的程序测试小组根据当时的分布式仿真技术需求对之前所使用的体系结构进行了评价性测试和回顾。参考了这些测试结论，程序测试小组在1995年3月提出了HLA标准的初始定义。此时体系管理组（AMG：Architecture Management Group）开始负责HLA标准的制定和开发，AMG组成员来自于各个DoD建模与仿真小组，他们通过在HLA环境下运行各种仿真程序以发现HLA标准初始定义中存在的问题，从而对这些定义进行修改。1996年8月，经过不断地修改和验证，AMG小组完成了HLA标准的基准定义，在同一年9月，DMSO规定之后所有的DoD仿真都必须和HLA相容。在随后的一年多时间中，HLA标准得到了不断的改进并在改进过程中形成了HLA v1.1、HLA v1.2和HLA v1.3标准，我们的CAD_RTI就是根据HLAv1.3标准进行开发的。在1997年6月HLA开始了IEEE标准化过程，并于2000年10月被正式采纳为IEEE P1516、IEEE P1516.1、IEEE P1516.2系列标准，其中IEEE P1516介绍了HLA标准的框架和规则，IEEE P1516.1介绍了HLA标准的接口规范，IEEE P1516.2介绍了HLA标准的对象模型模板。

随着HLA标准的完善，DMSO把工作重点从开发HLA标准逐步转移到HLA的实现上。在这个过程中，DMSO开发了很多软件，包括对象建模工具，RTI软件等。在下一小节中将介绍HLA标准的组成框架。

1.2.2 HLA组成框架

图1-3是一个典型的基于HLA仿真应用的体系结构。在图中我们可以看到HLA涉及的几个重要基本概念，在HLA中，把为实现某个特定仿真目的而组织在一起并彼此进行交互作用的仿真系统、支撑软件和其它相关部件总称为Federation即联邦，而把组成联邦的各个仿真应用子系统称为federate即联邦成员。HLA由三部分组成：（1）规则；（2）HLA接口规范；（3）对象模型模板。其中联邦规则确保同一联邦中的联邦成员即仿真实体能进行正确的交互，同时描述了联邦成员的责任。接口规范定义了RTI应该提供的服务，同时也定义了每个联邦成员必须提供的“回调”服务。对象模型模板提供了一个记录信息的通用方法，它主要规定了联邦对象模型、仿真对象模型以及管理对象模型的格式。

图1-3 HLA仿真应用的体系结构

规则：HLA规则一共十条，它们描述了联邦成员的责任以及联邦成员和RTI之间的关系，其中五条是联邦规则，另外五条是联邦成员规则。

五条联邦规则如下：

1. 每个联邦都应该具有一个用HLA对象模型模板描述的HLA联邦对象模型；

2. 在联邦中，所有FOM对象的表示应该由联邦成员来实现，而不是由RTI实现；

3. 在联邦运行过程中，联邦成员间FOM数据的交换应该通过RTI实现；

4. 在联邦运行过程中，联邦成员和RTI之间的交互应该符合HLA接口规范；

5. 在联邦运行过程中，在某个时刻，某个对象实例的某个属性的所有权只能属于一个

联邦成员。

五条联邦成员规则如下：

1. 每个联邦成员都应该具有一个用HLA对象模型模板描述的HLA仿真对象模型；

2. 联邦成员能够按照SOM中规定来更新和反映SOM中实体的任何属性值，并且能

够向外部发送和从外部接收SOM交互；

3. 在联邦运行过程中，联邦成员能够根据SOM中的规定动态地传递和接收属性的所

有权；

4. 联邦成员能够根据SOM中的规定动态地改变提供对象属性更新值时的环境；

5. 联邦成员能够管理它们的本地时间来协调与同一联邦中其它联邦成员间的数据交

换。

任何一个符合HLA标准的联邦应用中的联邦和联邦成员都必须满足这十条规则，因此在联邦应用设计开发实现过程中，开发人员应该严格遵守这十条规则。在图1-3中我们可以看到联邦A必须遵守HLA标准中的五条联邦规则，而联邦A中的所有联邦成员则必须遵守HLA标准中的五条联邦成员规则。

接口规范：HLA接口规范规定了联邦中的联邦成员之间如何进行交互。接口规范包含了两方面的内容：它既定义了HLA的核心即RTI应该提供的服务接口，又定义了联邦成员应该提供的回调服务接口，这些回调服务提供给RTI调用，联邦成员之间的所有交流都通过

调用RTI的服务来实现。在图1-3中我们可以看到每个联邦成员都通过调用RTI软件提供的服务进行交互，从而完成仿真任务，而每个联邦成员同时也提供了一组回调服务给RTI调用，RTI提供的服务和联邦成员提供的回调服务接口都必须和HLA接口规范标准吻合。按照功能划分，接口规范中定义的所有服务接口可以分为七组，即：联邦管理服务接口、声明管理服务接口、对象管理服务接口、所有权管理服务接口、时间管理服务接口、数据分发管理服务接口、以及一些支持的服务接口。在随后的章节中，会对这七组服务进行详细地介绍。

对象模型模板OMT：对象模型模板提供了一个表示HLA对象模型信息的通用方法。在HLA中，对象模型分为三种：联邦对象模型、仿真对象模型和管理对象模型。每个联邦具有一个联邦对象模型，这个模型描述了联邦内所有联邦成员的共享信息（如公共的对象类、交互类等），同时也定义了在此联邦内联邦成员都遵守的一些规则（如数据编码方式等）。每个联邦成员具有一个仿真对象模型，这个模型不仅描述了联邦成员所具有的特有特征和它所能提供给外部的对象和交互，还描述了联邦成员的内部操作过程。管理对象模型是一个通用的模型，它定义了管理一个联邦所需的对象类和交互类。对象模型模板是一种建模的标准化的方法和技术，它使得模型的建立、修改、生成和管理变得更方便，从而这也增强了仿真资源的可重用性。在图1-3中我们可以看到整个联邦A具有一个联邦对象模型，而联邦中的每个联邦成员都具有一个仿真对象模型。

1.2.3 HLA的优缺点

很多大规模的复杂仿真应用系统往往是由几个相对简单的仿真子系统组成，在很多情况下，往往会发现已经存在某些仿真子系统，虽然这些仿真子系统本来是被开发应用于其它的仿真需求。如果能重复利用这些仿真子系统，则在开发新的大规模仿真应用系统时，不必一切都重新开发，而通过充分利用这些已有资源从而达到快速、高效开发的目的。但是在早期的分布式仿真体系下，仿真资源的可重用性和互操作性往往很差。所谓仿真资源的可重用性，指的就是仿真资源在不同的应用环境和应用目的中被重复利用的可能性，而仿真资源的互操作性则和仿真资源的可重用性息息相关，它指的是被重复利用的仿真资源和其它仿真资源组合时不需要对这些仿真资源本身的属性如它们的源代码等进行修改。对于一组互操作性较高的仿真资源，能够很容易地被重新组合在一起组成一个新的仿真应用系统。

和其它的分布式仿真体系相比，HLA能很好地提高仿真资源的可重用性和互操作性。HLA标准中的三个组成部分（即HLA规则、接口规范和对象模型模板）保证了基于HLA 体系开发的仿真子系统会具有较高的可重用性和互操作性，这进一步会增强资源的重复利用，因此这最终能达到提高开发仿真应用系统效率的目的。

但是作为一项新技术，HLA并不是十全十美的。首先，RTI作为HLA的核心，虽然HLA标准中对RTI接口规范有了彻底全面的定义，但是对于仿真应用开发人员即RTI软件的使用者而言，RTI的易用性并不强，如在某个仿真应用中为了更新某对象实例的属性值，必须首先得到此对象实例句柄，接着需要得到所需更新的属性的句柄，然后需要对属性值进行编码，进行一系列的处理之后最终才能调用RTI的updateAttributeValues服务正式发布更新请求。而且RTI软件往往象一个黑盒，仿真应用开发者不知道里面是如何具体运行的，因此也增加了仿真应用调试的复杂度。最近有很多研究人员致力于增强HLA的易用性，某些RTI软件如pRTI现在具有了图形用户界面并能记录RTI内部操作日志，因此用户能更方便地使用RTI软件和对仿真应用进行调试。

其次，现在有很多不同的公司和研究人员致力于RTI软件的开发，推出了DMSO RTI，pRTI，M?K RTI等RTI软件版本，但是由于HLA标准中并没有关于不同RTI软件间互操作性的定义，因此不同开发者开发的RTI软件，甚至是同一开发团体开发的不同RTI版本之间往往不能实现互操作，所以使用不同RTI软件的仿真应用系统间往往不能实现互相通

讯，对于这个问题现在有很多研究者提出了通用消息协议、RTI桥等解决方案。

除了技术上的缺点，由于现在还不存在完全开发源码的且完全实现HLA接口规范的RTI 软件，这在某种程度上限制了HLA不能得到更广泛的应用。

1.3 HLA核心RTI

1.3.1 RTI简介

RTI（Run-Time Infrastructure）是实现HLA标准中接口规范的软件，它以类似于分布式操作系统为应用程序提供服务的方式给仿真应用提供各种服务，但是RTI本身并不属于HLA 标准。联邦中的联邦成员通过调用RTI提供的服务实现联邦成员之间的互相通讯，同时RTI 也要求联邦成员提供一组回调服务，在HLA接口规范中对这些回调服务的接口和具体功能也进行了定义。

HLA接口规范把它定义的所有服务划分为联邦管理、声明管理、对象管理、时间管理、数据分发管理、所有权管理和支持的服务等七组服务，一个完全符合HLA接口规范的RTI 软件必须实现这七组中的所有服务，下面对这七组服务的功能作简单介绍。

联邦管理：联邦管理提供一系列管理联邦的服务，包括联邦运行的创建、修改、删除以及对联邦运行的动态控制等服务。在一个联邦成员能加入到联邦运行中之前，必须存在一个联邦运行。联邦运行的创建、删除以及联邦成员加入和退出联邦运行等服务是联邦管理中最常用的几个服务。

声明管理：联邦成员通过调用声明管理服务声明它们可以产生哪些信息和愿意接收哪些信息即对哪些信息感兴趣。在联邦成员注册对象实例、更新实例属性和发送交互信息前，联邦成员必须调用声明管理提供的publishObjectClass和publishInteractionClass等服务声明它能产生什么信息，类似地，在联邦成员能够发现对象实例、反映实例属性和接收交互信息前，它也必须调用声明管理提供的subscribeObjectClass和subscribeInteractionClass等服务声明它对哪些信息感兴趣。因此通过声明管理模块，RTI向联邦成员提供了一种发布/订阅模式，通过充分利用这种模式，联邦成员可以减少所需发送和所需接收处理的消息总量，从而在整体上能减少整个联邦运行所需处理的消息量。而在下面将介绍到的数据分发管理是对这种发布/订阅模式的进一步扩展。

对象管理：在基于HLA的仿真应用中，所有信息都以事件的形式表示，事件又分为对象实例或交互实例，对象实例表示的是持久性的信息，在对象实例被注册直到它被删除为止，它所表示的状态信息一直存在，而交互实例表示的是短暂性的信息，在联邦成员发送完某个交互实例之后，在这个联邦成员中即不再存在此交互实例。对象管理服务提供了注册、修改、删除对象实例以及发送和接收交互实例等服务，若某个联邦成员需要表示某些持续性的信息，则它可以调用registerObjectInstance服务注册一个对象实例来表示这些信息，在完成对象实例注册之后，它可以调用updateAttributeValues和deleteObjectInstance服务来更新实例状态属性或删除此对象实例，此外，如果某个联邦成员想发布一个短暂性的信息，它可以调用对象管理提供的sendInteraction服务发送一个交互实例，任何对这种信息感兴趣的联邦成员都会收到一个receiveInteraction?回调服务发现这个交互实例。

所有权管理：联邦成员可以调用所有权管理服务传递对象实例属性的所有权。根据HLA 标准，每个对象实例属性都具有所有者，而且在某个特定时刻只能有一个联邦成员拥有它的所有权，只有具有这个对象实例属性所有权的联邦成员才能更新这个对象实例属性值。每个对象实例都具有一个特殊的属性即privilegeToDelete属性，只有具有这个属性的所有权的联邦成员才能删除这个对象实例。

时间管理：在基于HLA的仿真应用系统中，联邦具有一个全局时间，同时每个联邦成

员都具有一个局部时间，为了协调每个联邦成员的时间前移，同时为了保证联邦运行中所有发生的事件的因果以及顺序正确性，RTI必须提供一系列时间管理服务来控制每个联邦成员的时间前移以及为联邦运行过程中所发生的事件加上时间戳。时间管理服务把联邦成员分为以下几类：即管制联邦成员、受限联邦成员、既管制又受限的联邦成员、和既非管制又非受限的联邦成员，管制联邦成员能发送带有时间戳的事件，受限联邦成员能够接收带有时间戳的事件，既管制又受限的联邦成员则既能发送带有时间戳的事件又能接收带有时间戳的事件，既非管制又非受限的联邦成员则两者都不行。时间管理提供一系列服务来协调管制和受限联邦成员间的时间，而既非管制又非受限的联邦成员则不受到任何限制，同时联邦成员也可以在运行过程中通过调用某些时间管理服务动态地修改它的管制和受限状态。

数据分发管理：数据分发管理是对声明管理的进一步扩充，联邦成员通过使用数据分发管理服务可以进一步减少所需传输和所需接收的数据。声明管理通过提供发布/订阅服务机制可以让联邦成员声明它能产生哪种类型的数据和对那种类型的数据感兴趣，而数据分发管理进一步拓展了这个概念，它可以让联邦成员声明它能在哪些区域内产生哪种类型的数据和对哪些区域内的哪种类型数据感兴趣，通过区域匹配和类型匹配从而进一步减少所需传输和接收的数据量。

支持的服务：根据HLA标准，基于HLA的仿真应用中每个概念都具有两种表示方法，即名字和句柄，如每个联邦成员都具有一个联邦成员名和联邦成员句柄，所谓名字是指用户能轻易识别的一种表示方法，而句柄则是让机器能方便识别的表示方法。RTI应该提供了一组支持的服务，联邦成员可以调用这组服务来实现以下功能：（1）根据名字得到这个名字对应的句柄；（2）根据句柄得到此句柄对应的名字；（3）打开/关闭各种开关。

1.3.2 对RTI进行功能性能测试的必要性

RTI作为实现HLA接口规范的软件，需要对它进行功能测试以验证它是否完全与HLA 接口规范标准保持一致。和其它所有的软件产品一样，通过对RTI软件进行功能测试能发现软件本身中的错误和缺陷，把测试结果反馈给RTI软件开发者以让他们对软件本身进行改进，从而最终达到提高软件质量的目的。而HLA用户在使用一个通过验证的RTI软件产品时，对软件本身的信心自然会比较高。因此作为RTI软件产品的开发者，非常有必要对所开发的RTI产品首先进行功能测试，以验证它与HLA接口规范的一致性，我们的CADRTI软件是根据HLA接口规范1.3标准开发的，本文的第三章将详细介绍对CADRTI软件的功能测试过程。在1998年，DMSO组织了一个RTI验证团体开始设计RTI验证软件，迄今为止通过DMSO验证的RTI软件产品包括pitch公司的pRTI1.3、pRTI1516以及DMSO开发的RTI-NG等。

在另外一面，HLA接口规范虽然定义了RTI应该实现哪些功能提供哪些服务，但是HLA 标准并没有规定这些功能和服务的具体实现方式，因此RTI软件的开发者可以自由选择不同的实现方式（包括不同的网络拓扑结构、进程模型、时间管理算法、数据分发算法等）来实现他们的RTI软件。而不同的内部实现方式则会影响RTI软件很多方面的性能指标，对于RTI软件用户即仿真应用的开发者来说，他们可能根据他们所要开发的仿真应用特性，对RTI软件的某些方面的性能指标要求较高，如一个实时仿真应用则需要RTI软件具有较低的延迟和较大的吞吐量。因此对RTI软件进行性能测试，提供一组性能指标测试结果，可以帮助RTI软件的用户根据他们的仿真需求选择不同的RTI软件产品。同时对RTI软件的开发者而言，通过对RTI本身进行性能测试和性能分析，可以发现他们的RTI软件产品的性能瓶颈，通过改进影响RTI性能的某些内部实现，可以达到最终提高性能的目的。

因此综上所述，对RTI软件进行功能和性能测试分析是一项非常有意义的工作，本文的第三第四章将会具体介绍对我们的CADRTI软件进行功能测试和性能测试分析的详细过程，

同时在这过程中也会和其它现有的RTI软件产品如DMSO_RTI 1.3v5（1998年12月发布）、北京航空航天大学的DVE_RTI 2.0（2004年最新版本）等进行一些比较。

1.4 本文的主要工作

经过对RTI软件进行功能测试和性能测试必要性的分析，我们意识到非常有必要对开发的CADRTI软件进行这两方面的测试和分析。

为了对CADRTI进行功能测试，本文设计并实现了了RTIfuncTest功能测试平台，同时为RTI中的每组服务都设计了一系列的测试流程，通过操作RTIfuncTest平台执行这些测试流程，本文根据HLA接口规范1.3标准对CADRTI的进行了完整的功能测试。

同时为了对CADRTI进行性能测试分析和比较，本文设计了RTIperfTest和RTIscalabilityTest测试平台，其中RTIperfTest主要用于测试RTI在延迟、吞吐量、丢包率、CPU资源需求、网络带宽需求以及稳定性等方面的性能，而RTIscalabilityTest主要用于测试RTI在可扩展性方面的性能，本文利用这两个测试平台对美国国防部的DMSO_RTI 1.3 V5、北京航空航天大学开发的DVE_RTI 2.0、以及我们实验室开发的CADRTI进行了性能测试并得到了一组量化的性能测试结果，同时本文还从RTI的内部实现方式包括RTI可以采用的网络拓扑结构、进程模型、时间管理算法、数据分发算法等方面出发，对RTI的性能进行了分析。

最后本文开发了一个使用CADRTI且符合HLA标准的仿真应用FoodFight，此仿真应用使用了CADRTI提供的所有七组服务，因此这实际上也是对CADRTI进行了应用层次上的测试，同时通过FoodFight的开发经验，了解到基于HLA标准的仿真应用的具体开发流程。

1.5 论文的组织结构

本文的组织如下：

本文第一章中首先介绍了分布式交互仿真的发展过程，接着对HLA标准的发展过程和现状、HLA标准的组成框架进行了介绍，同时分析了HLA的优缺点，接着又对HLA核心RTI进行了介绍并分析了对RTI软件进行功能测试和性能测试的必要性，最后列出了本文的主要工作以及本文的组织结构。

本文第二章中简单介绍了CADRTI软件的实现框架。

本文第三章介绍了对CADRTI进行功能测试的整个过程，首先介绍了功能测试的目的、内容和方法，接着对所开发的RTI功能测试平台RTIfuncTest的实现框架进行了简单介绍，在本章的剩余部分中描述了对CADRTI的七组服务即联邦管理、声明管理、对象管理、时间管理、数据分发管理、所有权管理和支持的服务的测试流程和测试结果，并最后叙述了CADRTI的功能测试结论。

本文第四章首先介绍了RTI性能测试的目的和衡量RTI性能的各个指标，接着从RTI 的各种内部实现方式（包括网络拓扑结构、进程模型、时间管理算法和数据分发算法）的特点出发分析这些实现方式对RTI性能的影响，接下来介绍了为了对CADRTI进行性能测试而实现的RTIperfTest和RTIscalabilityTest测试平台的框架，最后对CADRTI的测试结果和DMSO_RTI、DVE_RTI的测试结果进行了比较并叙述了CADRTI性能测试结论。

本文第五章具体描述了一个使用CADRTI开发的联邦应用FoodFight的功能、实现框架以及在开发过程中得到的基于HLA标准的联邦应用的开发经验。

本文第六章对本文所做的工作进行了总结并提出了将来可以继续的工作。

2 第二章CADRTI的实现框架

2.1 CADRTI简介

CADRTI是根据HLA 1.3接口规范开发的RTI软件，它基本上提供了接口规范中定义的联邦管理、声明管理、对象管理、所有权管理、时间管理、数据分发管理以及支持的服务这七组服务中的大部分服务，并且每个服务的实现都严格根据HLA 1.3标准中的定义。和其它现有的RTI软件相比，CADRTI设计的本旨在于提高使用此软件的仿真应用系统的可扩展性。本章将从使用CADRTI的系统的网络拓扑结构、软件结构图、系统工作流程图、系统模块组成结构出发简单介绍CADRTI软件的组成和实现框架，以及此软件在仿真应用系统中的地位。

2.2 网络拓扑结构

图2-1：网络拓扑结构

如图2-1所示，使用CADRTI的仿真应用系统由目录管理器、组管理器和用户组成，系统采用的是多用户多组管理器的结构即分组管理的结构。其中目录管理器负责：（1）用户登录管理（2）根据用户的请求创建联邦运行，并在组管理器上运行相应的组管理程序（3）根据负载平衡原理将用户分配给相应的组管理器；组管理器负责：（1）管理跟踪一组用户即一组联邦成员（2）帮助本组内以及各组间的联邦成员之间进行数据通讯（3）处理各种交互数据；用户节点负责：（1）与用户进行交互（2）运行模拟仿真程序（3）与组管理器间进行通讯。

由于采用了多组管理器的结构，仿真应用的设计者可以根据仿真用户的数量选择组管理器的数量，同时目录管理器会根据特定的负载平衡算法实现组管理器间的负载平衡，从而避免出现某个组管理器成为通讯瓶颈的情况。组管理器数量的灵活性大大增强了仿真应用系统的用户数量即联邦成员数量的可扩展性。在性能分析这一章中将对CADRTI软件提供的可扩展性进行量化的测试与分析。

2.3 软件结构

图2-2：软件结构图

如图2-2所示，网络拓扑图中的目录管理器上运行的是目录管理程序，组管理器上运行的是组管理程序，用户机器上运行的是联邦成员即仿真模拟程序。在图2-2中实线表示的是经常性通讯，虚线表示的是非经常性通讯。如图所示，联邦成员在启动时会首先和目录管理程序进行通讯，目录管理程序负责验证联邦成员身份并根据请求创建联邦运行，同时会让组管理程序开始运行并根据负载平衡把联邦成员分配给某个组管理程序进行管理。联邦成员和联邦成员之间的所有通讯都通过组管理程序实现，即任何两个联邦成员之间不会有直接通讯的情况，而每个联邦成员所有的对外通讯都是通过CADRTI所提供的服务实现的。当同时属于某个组管理程序管理的两个联邦成员之间要交流某些交互信息或更新信息时，消息的发送联邦成员首先把消息内容发送给组管理程序，组管理程序在把此消息转发给需要接收此消息的联邦成员，而当不同组间的联邦成员需要进行通讯时，则需要组管理程序之间实现通讯。

综上所述，联邦成员中运行的CADRTI是局部的运行时底层结构，而组管理程序中也需要运行类似的程序，负责全局的管理和处理。因此在一个使用CADRTI的仿真应用系统中，CADRTI是整个系统的核心，所有仿真实体间的消息通讯都通过它来实现，因此CADRTI 让仿真应用系统中的通讯更为规范化，从而在提高了仿真实体的可重用性和互操作性。

2.4 系统工作流程

通过2.2节和2.3节的介绍我们可以看到，在一个基于CADRTI的仿真应用中，目录管理器和组管理器是系统的重要组成部分，在某个仿真实体即联邦成员能够正常运转之前必须首先启动目录管理程序和组管理程序，因此在本节的工作和数据流程图中，都将省略这两个步骤。下面将简单介绍联邦成员创建联邦运行的流程、联邦成员加入联邦运行的流程、以及整个系统的数据流程。

图2-3a ：创建联邦运行 图2-3b ：加入联邦运行

如图2-3a 所示，在某个基于CADRTI 的仿真应用中，第一个试图加入仿真应用的联邦成员的工作流程如下：（1）联邦成员通过CADRTI 向目录管理器发送创建联邦运行的请求；

（2）目录管理器向运行在每台组管理器上的组管理程序发送启动联邦运行的请求；（3）组管理器在启动完联邦运行之后，向目录管理器发送反馈消息；（4）目录管理器通知联邦成员负责管理此联邦成员的组管理器的信息；（5）联邦成员和管理它的组管理器间进行通讯。而一旦存在了某个联邦运行，则此后加入联邦运行的过程就相对比较简单，图2-3b 中显示的是联邦成员加入联邦运行的工作流程：（1）联邦成员通过CADRTI 向目录管理器发送加入联邦运行的请求；（2）目录管理器根据负载平衡原理把此联邦成员分配给某个组管理器管理，并通知联邦成员负责管理此联邦成员的组管理器的信息；（3）联邦成员和管理它的组管理器间进行通讯。

在联邦成员加入到联邦运行中之后，同一联邦运行中的联邦成员之间可以互相交换属性更新信息和交互信息，但是这些信息交互不是在联邦成员之间直接进行，而是联邦成员通过调用CADRTI 提供的相应服务

并最终通过组管理器进行的。图2-4中显示的是联邦成员间互相进行通讯的流程：

图2-4：系统数据流程

如图2-4所示，两个联邦成员间数据交互的流程如下：（1）发送数据的联邦成员通过CADRTI 把更新数据发送到管理此联邦成员的组管理器；（2）组管理器根据指定算法找到需要接收此更新数据的联邦成员；（3a ）若接收数据的联邦成员和发送数据的联邦成员被同一个组管理器管理，则此组管理器直接把更新数据发送给接收数据的联邦成员，数据交互过程结束；（3b ）若接收数据的联邦成员和发送数据的联邦成员被不同的组管理器管理，则组管理器1首先把更新数据发送给组管理器2；（4）组管理器2把更新数据发送给目标联邦成员，数据交互过程结束。

2.5 系统模块组成

在一个使用CADRTI的仿真应用系统中，主要由目录管理器模块、组管理器模块、联邦成员模块组成，下面将这三大模块的组成和功能。

目录管理器模块：目录管理器模块的主要功能是负责用户管理和负载平衡计算，由侦听子模块、用户验证和添加子模块、负载计算和用户分配子模块、组管理器验证和添加子模块组成。在联邦成员能够正常运行之前，此联邦成员必须首先通过目录管理程序的身份验证。

组管理器模块：每个组管理器模块中相当于一个中心运行时底层结构组件（Center RTI Component），它也可以划分为联邦管理、声明管理、对象管理、所有权管理、时间管理、数据分发管理以及支持的服务这七大模块。任意两个联邦成员之间的消息通讯都通过组管理器实现，因此组管理模块相当于整个仿真系统中信息通讯的枢纽。

联邦成员模块：联邦成员模块主要模拟仿真操作并和用户之间进行交互，它由仿真子模块和局部运行时底层结构组件子模块组成。如图2-5所示，其中仿真代码负责模拟仿真实体的行为如模拟某架飞机的飞行过程等，同时仿真代码还必须提供一系列回调函数给RTI调用。图中的LRC指的是局部运行时底层结构组件，它为联邦成员提供了联邦管理、声明管理、对象管理、所有权管理、时间管理、数据分发管理以及支持的服务这七大组服务，每个联邦成员所有的对外通讯都是通过RTI所提供的服务而实现的。

图2-5：联邦成员模块

3 第三章CADRTI功能测试

3.1 功能测试简介

3.1.1 功能测试目的

Grenford J. Myers在《The Art of Software Testing》中提到：（1）软件测试是为了发现错误而执行程序的过程；（2）测试是为了证明程序有错，而不是证明程序无错误；（3）一个好的测试用例在于它能发现至今未发现的错误；（4）一个成功的测试是发现了至今未发现的错误的测试。在信息技术快速发展的今天，软件产品被应用到了社会的各个领域，软件产品的质量也成为了人们关注的焦点，软件产品的开发者和使用者都把软件质量作为重要目标，而软件测试是发现软件产品的错误，从而让软件开发者通过改正这些错误提高软件质量的重要方法。

通过第二章中对CADRTI软件实现框架的介绍可以看到，CADRTI是根据HLA 1.3接口规范标准实现的一个RTI软件，它以类似于分布式操作系统为应用程序提供服务的方式给仿真应用提供各种服务，联邦运行中的联邦成员通过调用CADRTI提供的服务实现联邦成员之间的互相通讯。CADRTI基本实现了HLA标准中定义的联邦管理、声明管理、对象管理、时间管理、数据分发管理、所有权管理和支持的服务这七组服务中所有功能。为了验证CADRTI的实现与HLA 1.3接口规范标准的一致性，必须对CADRTI进行功能测试，看它是否如HLA接口规范标准所描述提供了所有的服务和每个服务的行为是否和标准中所定义的一致。通过对CADRTI进行功能测试，可以发现软件本身存在的错误和缺陷，CADRTI 的开发者通过参考功能测试结果可以改正软件内部的错误，从而达到提高软件质量的目的。同时通过对测试过程中发现的错误进行分析和总结，可以让RTI软件的开发者对错误产生的原因和错误的分布特征有相当的了解，从而帮助提高他们开发新版本RTI的效率。

3.1.2 功能测试内容

由于CADRTI是根据HLA 1.3接口规范标准实现的软件，而在HLA 1.3接口规范标准中定义了联邦管理（11个服务）、声明管理（8个服务）、对象管理（8个服务）、时间管理（19个服务）、数据分发管理（12个服务）、所有权管理（9个服务）和支持的服务（29个服务）七组共96个服务，因此对CADRTI进行功能测试的内容为验证CADRTI实现中每个服务的行为与接口规范标准中定义的一致性，测试每个服务在正确的测试环境即给定正确的参数和在正确的上下文环境中是否能返回正确值，同时也测试在错误的测试环境下是否返回相应的异常信息。

3.1.3 功能测试方法

根据测试过程是否针对软件产品的内部结构和具体实现算法，软件测试可以分为黑盒测试和白盒测试。黑盒测试也称功能测试或数据驱动测试，它是指在已知软件产品所应具有功能的情况下，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盒子，测试者完全不考虑程序内部结构和内部特性，而只对程序接口进行测试。而白盒测试也称结构测试或逻辑驱动测试，它指的是在知道软件产品内部工作过程的情况下按照程序内部的结构测试程序，检验程序中的每条通路是否能正常运行。对于CADRTI软件的测试，本文采用了黑盒测试和白盒测试相结合的测试方法，即既设计了一系列的测试案例

来测试CADRTI提供的每个服务接口的运行情况，并把运行结果和HLA 1.3接口规范标准中的定义进行对照，从而验证CADRTI的实现与HLA标准的一致性，同时在设计测试案例时又考虑了CADRTI提供的每个服务的内部工作过程，从而保证能测试程序中每条通路的运行情况。为了对CADRTI的功能进行方便地测试，本文设计并实现了功能测试平台RTIfuncTest，在3.2节中将详细介绍此平台的实现框架和功能。

3.2 功能测试平台RTIfuncTest

为了给CADRTI软件的功能测试提供一个便利的测试环境，本文设计并实现了RTIfuncTest功能测试平台，通过此测试平台提供的图形用户界面，测试者可以方便地执行所设计的测试案例和流程，并且此测试平台会在文本文件中和图形用户界面上同时显示每个测试案例的测试结果，因此CADRTI的测试者和开发者都可以方便地获取测试结果，从而参照HLA 1.3接口规范标准和测试案例对测试结果进行分析。图3-1中显示了RTIfuncTest 测试平台的框架。

如图3-1所示，RTIfuncTest测试平台主要由两层模块组成，最上层的模块为图形用户界面模块，此模块主要负责与此平台的用户即RTI测试者进行交互，测试者可以通过操作图形用户界面方便地执行测试流程，同时也可以方便地获取测试结果。第二层模块为测试联邦成员模块，它不仅通过调用CADRTI提高的服务模拟一个仿真实体的行为，为图形用户界面层提供程序接口，而且根据HLA 1.3接口规范中的定义实现了所有的回调服务，从而让CADRTI能调用这些回调服务，保证仿真模拟程序的正常运行。

图3-1：RTIfuncTe st测试平台框架图