论文部分内容阅读
[摘要]为了将地域分布的单台飞行模拟器进行互联，建立基于高层体系结构的分布式交互飞行仿真， 以完成更加复杂的训练任务。开发针对大规模飞行仿真的联邦运行支撑环境。论述了该系统所采用的分层分布式体系结构，阐述了各个服务的数据流程；论述该系统所采用分层式软件结构，阐述基于多线程的接口服务层、基于动态内存的数据功能层和基于完成端口模型的网络服务层的实现，并着重阐述了网络服务层的实现。进而在该系统的基础上实现单台飞行模拟器的互联，完成基于高层体系结构的飞行仿真，证明该系统的可运行性。
[关键词]分布式交互飞行仿真 联邦运行支撑环境 分层分布式体系结构 完成端口模型
中图分类号：TP391 文献标识码：A 文章编号：1671－7597（2008）0320017－02
一、引言
随着计算机仿真技术的发展，飞行模拟器已经成为目前飞行训练中不可或缺的技术设备，它使得飞行员能够快速熟悉新机种的驾驶技术，提高操作水平。并且降低了训练风险和训练费用。随着训练任务要求的提高越来越迫切需要对地域分布的单台模拟器进行互联以完成更加复杂的训练任务。如编队飞行、空中对抗、对地攻击以及协同完成战术战役仿真演练等。这对于新机种和飞行员尽快形成战斗力具有重要意义。客观上提出了分布交互飞行仿真的需求。
高层体系结构（HLA）作为目前分布交互仿真的发展方向，能够很好的支持大规模仿真，能够很好的满足较大规模分布式交互飞行仿真的需求。同时，HLA的基本思想是在拥有联邦成员的基础上进行联邦集成，考虑如何设计联邦成员之间的交互以达到仿真的目的。恰好符合了在拥有单台飞行模拟器的基础上构建多机互联的分布式交互飞行仿真的特点。因此采用高层体系结构进行分布式交互飞行仿真成为大规模飞行仿真的首选。
鉴于以上情况，针对基于高层体系结构构建分布式交互飞行仿真的特点，开发了针对大规模飞行训练仿真的联邦运行支撑环境（FXFZ RTI）。
二、FXFZ RTI的体系结构
目前的RTI体系结构可分为集中式、分布式和层次式。其中集中式体系结构将所有功能都放在中心服务器中实现，系统性能取决于中心服务器的性能，当规模较大时中心服务器容易成为系统的瓶颈；分布式体系结构各应用节点之间是对等关系，各局部RTI通过协调通信完成功能，该结构解决了由于中心服务器而可能引起发瓶颈问题，但缺乏必要的全局操作管理，对维护数据的一致性带来困难；层次式综合了集中式和分布式的特点，将系统的功能分配到多个服务器上完成，中心RTI服务器负责完成全局性处理功能，其它功能由局部RTI服务器组件完成，能够较好的支持大规模分布式仿真[5]。但它增加了数据传输的环节，延长了传输时间，降低了系统效率。
本系统采用分层分布式体系结构。针对公布、订购等控制流数据和需要维护一致性的全局数据（所有权控制、时间同步等）采用层次式结构。针对更新与反射、发送与接受等数据流数据采用基于代理的分布式结构，局域网内部各个联邦成员之间直接通信，位于不同局域网的联邦成员之间通过代理机制实现通信，首先将数据发送给异地联邦成员的代理（异地联邦所属的局部RTI服务器），再转发给联邦成员。减少了先将数据发送给局部RTI服务器再转发的环节。从单个局部RTI服务器来看，其体系结构类似于功能分布式。
三、FXFZ RTI的软件构成
从软件构成上讲，整个RTI平台可分为三个部分：LRC、局部RTI服务器和中心RTI服务器，局部RTI服务器和中心RTI服务器共享同一份程序代码（RTI Server），根据配置的不同充当本地RTI服务器或中心RTI服务器。其中LRC是一个动态链接库，分布在每个运行仿真程序的计算机上，负责维护本主机上的数据；RTI Server为独立程序，可运行在独立的计算机上，也可运行在运行仿真程序的计算机上，负责维护本局域网内部联邦执行或整个联邦执行的数据。按照功能的不同RTI Server可分为两个部分，一个部分是全局执行进程（RtiExec），管理联邦执行的创建、结束以及管理多个不同的联邦执行，另一部分是联邦执行进程（FedExec），管理联邦成员的加入和退出，为联邦成员之间进行数据通信和协调运行提供支持。
四、分层分布式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服务器，完成数据交互。
五、FXFZ RTI的实现
本系统采用层次式软件体系结构，按功能划分为接口服务层、数据功能层和网络服务层，其中接口服务层负责提供RTI与仿真程序的编程接口；功能服务层负责实现联邦管理、声明管理和对象管理等六大管理服务，维护联邦执行所需维护的数据；网络服务层负责RTI各组成部分之间的相互通信。
（一）接口服务层的实现
接口服务层提供了仿真程序使用RTI服务的接口，被仿真程序调用，进而调用数据功能层函数完成HLA提供的功能，同时接受数据功能层函数的回调，将其他联邦成员或RTI Server的数据传递给仿真程序。
接口服务层只存在于LRC中，主要包括RTI大使类（RTI Ambassador）和联邦成员大使类（Federate Ambassador），其中RTI大使类实现了由RTI提供的供仿真程序调用的所有服务；联邦成员大使类是一个抽象类，定义了HLA接口规范中所有的回调函数，需要仿真程序根据实际情况进行实例化，联邦成员通过这些回调函数从RTI中接受数据。
从LRC与仿真程序的交互来看，LRC既需要接受仿真程序的调用，又需要回调仿真程序实现的回调函数，故本系统将接口服务层设计为双线程模式，其中一个线程用于接受仿真程序产生的调用，并根据调用类型调用数据功能层函数完成功能；另一个线程用于接受数据功能层调用进而调用仿真程序提供的回调函数。同样要求仿真程序采用双线程，其中一个线程调用LRC提供的接口函数向RTI发送请求，另一个线程接受LRC调用的回调函数，并根据回调函数处理仿真程序的状态。
（二）数据功能层的设计与实现
数据功能层位于接口服务层和网络服务层之间，接受接口服务层函数调用，对自己维护的数据进行处理，然后将数据发送到网络服务层进行传输；同时，接受网络服务层的函数调用，将数据进行处理后调用接口服务层函数将数据传递给仿真程序，进而控制仿真的运行。
针对LRC而言，需要维护以下数据：维护联邦成员类，记录该联邦成员的基本信息；维护对象类，记录该联邦成员公布和订购了哪些对象类的哪些属性以及RTI Server为其分配的组播通道信息；维护交互类，记录该联邦成员公布和订购了哪些交互类，以及该交互类的组播通道信息；维护对象实例列表，记录该联邦成员注册和发现的所有对象实例，维护对象实例状态。接受数据接口层的函数调用，修改注册实例状态，并调用网络服务层将更新发送给其他联邦成员；接受网络服务层函数的调用，修改发现对象实例状态，并调用接口服务层函数反射给仿真程序。另外LRC还负责解析FED文件，存储联邦执行中所有对象类和交互类信息，为联邦执行提供对象类句柄、对象类属性句柄、交互类句柄、交互类参数句柄等查询。
针对RTI Server而言，需要维护以下数据：维护联邦成员列表，记录联邦执行中所有联邦成员的通信地址等信息。维护对象类公布/订购列表，匹配每个对象类的公布/订购信息，建立有效订购表，为每个有效订购分配组播通道；维护交互类公布/订购列表，匹配联邦执行中所有交互类的公布/订购信息，为每个交互类有效订购建立组播通道；维护联邦执行中的对象实例，管理联邦执行中所有对象属性的所有权等信息。另外RTI Server还需维护联邦执行列表，以管理系统中得多个联邦执行。
（三）网络服务层的设计与实现
网络服务层是本系统的最底层，为RTI的数据传输提供网络支持。接受数据功能层的函数调用，将数据打包并传送给指定联邦成员或RTI Server，接受来自网络的数据 ，将数据解包并根据消息类型提交给数据功能层的不同模块进行处理。
在协议的选择上，本系统采用目前普遍应用的TCP/IP协议。在Windows系统下，采用Winsock这一网络编程接口。
在消息传输方式的选择上，根据不同的特征选择不同的传输方式，其中LRC与RTI Server之间、中心RTI Server与各局部RTI Server之间主要是少量且重要的控制流和状态流的传输，故采用可靠的点对点通信，以确保系统的正确运行；LRC与LRC之间主要是大量的数据流的传输，且它们之间多为一对多通信关系，故采用基于UDP的组播通信，针对不同的有效订购建立不同的组播组通道，以达到较高的效率。
在设计模式的选择上，采用完成端口（complete port）I/O模型。完成端口是一个异步I/O的API，它为应用程序提供了一种使用线程池处理异步I/O的机制。比在I/O请求时创建线程更快更有效，以及更好的可伸缩性。
在通常的网络服务器设计中，在主线程中开启监听端口，accept后线程被挂起，等待一个客户发出请求，而后创建新线程来处理请求。当新线程处理客户请求时，起初的线程循环回去等待另一个客户请求，处理客户请求的线程处理完毕后终结。该模型针对每个客户请求创建一个线程，增加了系统的并发性，但是多个线程意味着较多的开销。另外，由于网络速度相对于CPU而言速度很慢，使得工作线程长时间处于等待状态，线程的利用率较低，又由于多个线程间的上下文切换，进一步降低了系统的效率。
与通常的网络服务器设计模式不同，完成端口I/O模型不是为每个客户请求创建一个线程，而是引入线程池的概念，提前创建一个或多个服务线程阻塞与完成端口，运用完成端口关联多个套接字，当I/O完成时，系统将数据排序到完成端口，在完成端口上等待的线程池中的线程便依次读取并处理数据队列中的数据。该模式减少了线程的数量，减少了进程间上下文切换的开销，提高了线程利用率。
针对LRC而言，网络服务层负责与其他LRC进行通信，接受数据功能层函数调用，将更新数据和交互数据以组播方式发送给订购该对象类或交互类的联邦成员；接受来自其他联邦成员的更新或交互数据，调用功能服务层函数完成仿真更新。负责与RTI Server进行通信，根据数据功能层函数调用，将控制信息和全局数据以TCP方式传送给RTI Server，同时接受来自RTI Server的控制信息，完成创建组播通道等控制功能。
针对RTI Server而言，负责与LRC进行通信，接受LRC发送的数据请求，根据请求类型调用数据功能层函数完成仿真管理，并将处理结果反馈给LRC。负责中心RTI Server与局部RTI Server之间的通信，完成控制信息的交互。
六、小结
目前，FXFZ RTI完成了核心版，实现了联邦管理中联邦执行管理部分、声明管理和对象管理服务，针对其他管理提供了简单实现。并运用该联邦运行支撑系统成功的完成了实验室原有单台飞行模拟器的互联，证明了该系统的可运行性。
该平台还不完善，在今后仍有很多需要改进的地方，主要表现在：
（1）进一步完善IEEE1516标准中的其他服务。
（2）完成在NUIX/Linux环境下的实现.
（3）完成UNIX/Linux环境下实现与Windows环境下实现的互联。
参考文献：
[1]周彦、戴剑伟，HLA仿真程序设计[M].北京：电子工业出版社，2002.6.
[2]卿杜政、李伯虎，HLA 运行支撑框架（SSS-RTI）的研究与开发[J].系统仿真学报，2000，12（5）：490-493.
[3]周伯河、刘玉庆、王宝智，两层式RTI设计与实现[J].计算机仿真，2007，24（4）：23-25.
[4]姚益平、卢锡城、王怀民，层次式RTI服务器的设计与实现[J].计算机学报，2003，26（6）：716-721.
[5]刘步权、王怀民、姚益平，层次式仿真运行支撑环境StarLink中的关键技术[J].软件学报，2004，15（1）：9-16.
[6]黄显东，RTI仿真平台的体系结构研究与实现[D].北京：北京邮电大学硕士学位论文.2006.
[7]IEEE Standard for Modeling and Simulation （M&S） High Level Architecture （HLA）Federate Interface Specification （IEEE Std 1516.1-2000）. Institute of Electrical and Electronics Engineers， Inc， 2001.
作者简介：
齐连军，男，河北人，硕士研究生，研究方向：分布式交互仿真；刘春，男，沈阳人，硕士生导师，研究方向：虚拟现实及数字化制造。
[关键词]分布式交互飞行仿真 联邦运行支撑环境 分层分布式体系结构 完成端口模型
中图分类号：TP391 文献标识码：A 文章编号：1671－7597（2008）0320017－02
一、引言
随着计算机仿真技术的发展，飞行模拟器已经成为目前飞行训练中不可或缺的技术设备，它使得飞行员能够快速熟悉新机种的驾驶技术，提高操作水平。并且降低了训练风险和训练费用。随着训练任务要求的提高越来越迫切需要对地域分布的单台模拟器进行互联以完成更加复杂的训练任务。如编队飞行、空中对抗、对地攻击以及协同完成战术战役仿真演练等。这对于新机种和飞行员尽快形成战斗力具有重要意义。客观上提出了分布交互飞行仿真的需求。
高层体系结构（HLA）作为目前分布交互仿真的发展方向，能够很好的支持大规模仿真，能够很好的满足较大规模分布式交互飞行仿真的需求。同时，HLA的基本思想是在拥有联邦成员的基础上进行联邦集成，考虑如何设计联邦成员之间的交互以达到仿真的目的。恰好符合了在拥有单台飞行模拟器的基础上构建多机互联的分布式交互飞行仿真的特点。因此采用高层体系结构进行分布式交互飞行仿真成为大规模飞行仿真的首选。
鉴于以上情况，针对基于高层体系结构构建分布式交互飞行仿真的特点，开发了针对大规模飞行训练仿真的联邦运行支撑环境（FXFZ RTI）。
二、FXFZ RTI的体系结构
目前的RTI体系结构可分为集中式、分布式和层次式。其中集中式体系结构将所有功能都放在中心服务器中实现，系统性能取决于中心服务器的性能，当规模较大时中心服务器容易成为系统的瓶颈；分布式体系结构各应用节点之间是对等关系，各局部RTI通过协调通信完成功能，该结构解决了由于中心服务器而可能引起发瓶颈问题，但缺乏必要的全局操作管理，对维护数据的一致性带来困难；层次式综合了集中式和分布式的特点，将系统的功能分配到多个服务器上完成，中心RTI服务器负责完成全局性处理功能，其它功能由局部RTI服务器组件完成，能够较好的支持大规模分布式仿真[5]。但它增加了数据传输的环节，延长了传输时间，降低了系统效率。
本系统采用分层分布式体系结构。针对公布、订购等控制流数据和需要维护一致性的全局数据（所有权控制、时间同步等）采用层次式结构。针对更新与反射、发送与接受等数据流数据采用基于代理的分布式结构，局域网内部各个联邦成员之间直接通信，位于不同局域网的联邦成员之间通过代理机制实现通信，首先将数据发送给异地联邦成员的代理（异地联邦所属的局部RTI服务器），再转发给联邦成员。减少了先将数据发送给局部RTI服务器再转发的环节。从单个局部RTI服务器来看，其体系结构类似于功能分布式。
三、FXFZ RTI的软件构成
从软件构成上讲，整个RTI平台可分为三个部分：LRC、局部RTI服务器和中心RTI服务器，局部RTI服务器和中心RTI服务器共享同一份程序代码（RTI Server），根据配置的不同充当本地RTI服务器或中心RTI服务器。其中LRC是一个动态链接库，分布在每个运行仿真程序的计算机上，负责维护本主机上的数据；RTI Server为独立程序，可运行在独立的计算机上，也可运行在运行仿真程序的计算机上，负责维护本局域网内部联邦执行或整个联邦执行的数据。按照功能的不同RTI Server可分为两个部分，一个部分是全局执行进程（RtiExec），管理联邦执行的创建、结束以及管理多个不同的联邦执行，另一部分是联邦执行进程（FedExec），管理联邦成员的加入和退出，为联邦成员之间进行数据通信和协调运行提供支持。
四、分层分布式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服务器，完成数据交互。
五、FXFZ RTI的实现
本系统采用层次式软件体系结构，按功能划分为接口服务层、数据功能层和网络服务层，其中接口服务层负责提供RTI与仿真程序的编程接口；功能服务层负责实现联邦管理、声明管理和对象管理等六大管理服务，维护联邦执行所需维护的数据；网络服务层负责RTI各组成部分之间的相互通信。
（一）接口服务层的实现
接口服务层提供了仿真程序使用RTI服务的接口，被仿真程序调用，进而调用数据功能层函数完成HLA提供的功能，同时接受数据功能层函数的回调，将其他联邦成员或RTI Server的数据传递给仿真程序。
接口服务层只存在于LRC中，主要包括RTI大使类（RTI Ambassador）和联邦成员大使类（Federate Ambassador），其中RTI大使类实现了由RTI提供的供仿真程序调用的所有服务；联邦成员大使类是一个抽象类，定义了HLA接口规范中所有的回调函数，需要仿真程序根据实际情况进行实例化，联邦成员通过这些回调函数从RTI中接受数据。
从LRC与仿真程序的交互来看，LRC既需要接受仿真程序的调用，又需要回调仿真程序实现的回调函数，故本系统将接口服务层设计为双线程模式，其中一个线程用于接受仿真程序产生的调用，并根据调用类型调用数据功能层函数完成功能；另一个线程用于接受数据功能层调用进而调用仿真程序提供的回调函数。同样要求仿真程序采用双线程，其中一个线程调用LRC提供的接口函数向RTI发送请求，另一个线程接受LRC调用的回调函数，并根据回调函数处理仿真程序的状态。
（二）数据功能层的设计与实现
数据功能层位于接口服务层和网络服务层之间，接受接口服务层函数调用，对自己维护的数据进行处理，然后将数据发送到网络服务层进行传输；同时，接受网络服务层的函数调用，将数据进行处理后调用接口服务层函数将数据传递给仿真程序，进而控制仿真的运行。
针对LRC而言，需要维护以下数据：维护联邦成员类，记录该联邦成员的基本信息；维护对象类，记录该联邦成员公布和订购了哪些对象类的哪些属性以及RTI Server为其分配的组播通道信息；维护交互类，记录该联邦成员公布和订购了哪些交互类，以及该交互类的组播通道信息；维护对象实例列表，记录该联邦成员注册和发现的所有对象实例，维护对象实例状态。接受数据接口层的函数调用，修改注册实例状态，并调用网络服务层将更新发送给其他联邦成员；接受网络服务层函数的调用，修改发现对象实例状态，并调用接口服务层函数反射给仿真程序。另外LRC还负责解析FED文件，存储联邦执行中所有对象类和交互类信息，为联邦执行提供对象类句柄、对象类属性句柄、交互类句柄、交互类参数句柄等查询。
针对RTI Server而言，需要维护以下数据：维护联邦成员列表，记录联邦执行中所有联邦成员的通信地址等信息。维护对象类公布/订购列表，匹配每个对象类的公布/订购信息，建立有效订购表，为每个有效订购分配组播通道；维护交互类公布/订购列表，匹配联邦执行中所有交互类的公布/订购信息，为每个交互类有效订购建立组播通道；维护联邦执行中的对象实例，管理联邦执行中所有对象属性的所有权等信息。另外RTI Server还需维护联邦执行列表，以管理系统中得多个联邦执行。
（三）网络服务层的设计与实现
网络服务层是本系统的最底层，为RTI的数据传输提供网络支持。接受数据功能层的函数调用，将数据打包并传送给指定联邦成员或RTI Server，接受来自网络的数据 ，将数据解包并根据消息类型提交给数据功能层的不同模块进行处理。
在协议的选择上，本系统采用目前普遍应用的TCP/IP协议。在Windows系统下，采用Winsock这一网络编程接口。
在消息传输方式的选择上，根据不同的特征选择不同的传输方式，其中LRC与RTI Server之间、中心RTI Server与各局部RTI Server之间主要是少量且重要的控制流和状态流的传输，故采用可靠的点对点通信，以确保系统的正确运行；LRC与LRC之间主要是大量的数据流的传输，且它们之间多为一对多通信关系，故采用基于UDP的组播通信，针对不同的有效订购建立不同的组播组通道，以达到较高的效率。
在设计模式的选择上，采用完成端口（complete port）I/O模型。完成端口是一个异步I/O的API，它为应用程序提供了一种使用线程池处理异步I/O的机制。比在I/O请求时创建线程更快更有效，以及更好的可伸缩性。
在通常的网络服务器设计中，在主线程中开启监听端口，accept后线程被挂起，等待一个客户发出请求，而后创建新线程来处理请求。当新线程处理客户请求时，起初的线程循环回去等待另一个客户请求，处理客户请求的线程处理完毕后终结。该模型针对每个客户请求创建一个线程，增加了系统的并发性，但是多个线程意味着较多的开销。另外，由于网络速度相对于CPU而言速度很慢，使得工作线程长时间处于等待状态，线程的利用率较低，又由于多个线程间的上下文切换，进一步降低了系统的效率。
与通常的网络服务器设计模式不同，完成端口I/O模型不是为每个客户请求创建一个线程，而是引入线程池的概念，提前创建一个或多个服务线程阻塞与完成端口，运用完成端口关联多个套接字，当I/O完成时，系统将数据排序到完成端口，在完成端口上等待的线程池中的线程便依次读取并处理数据队列中的数据。该模式减少了线程的数量，减少了进程间上下文切换的开销，提高了线程利用率。
针对LRC而言，网络服务层负责与其他LRC进行通信，接受数据功能层函数调用，将更新数据和交互数据以组播方式发送给订购该对象类或交互类的联邦成员；接受来自其他联邦成员的更新或交互数据，调用功能服务层函数完成仿真更新。负责与RTI Server进行通信，根据数据功能层函数调用，将控制信息和全局数据以TCP方式传送给RTI Server，同时接受来自RTI Server的控制信息，完成创建组播通道等控制功能。
针对RTI Server而言，负责与LRC进行通信，接受LRC发送的数据请求，根据请求类型调用数据功能层函数完成仿真管理，并将处理结果反馈给LRC。负责中心RTI Server与局部RTI Server之间的通信，完成控制信息的交互。
六、小结
目前，FXFZ RTI完成了核心版，实现了联邦管理中联邦执行管理部分、声明管理和对象管理服务，针对其他管理提供了简单实现。并运用该联邦运行支撑系统成功的完成了实验室原有单台飞行模拟器的互联，证明了该系统的可运行性。
该平台还不完善，在今后仍有很多需要改进的地方，主要表现在：
（1）进一步完善IEEE1516标准中的其他服务。
（2）完成在NUIX/Linux环境下的实现.
（3）完成UNIX/Linux环境下实现与Windows环境下实现的互联。
参考文献：
[1]周彦、戴剑伟，HLA仿真程序设计[M].北京：电子工业出版社，2002.6.
[2]卿杜政、李伯虎，HLA 运行支撑框架（SSS-RTI）的研究与开发[J].系统仿真学报，2000，12（5）：490-493.
[3]周伯河、刘玉庆、王宝智，两层式RTI设计与实现[J].计算机仿真，2007，24（4）：23-25.
[4]姚益平、卢锡城、王怀民，层次式RTI服务器的设计与实现[J].计算机学报，2003，26（6）：716-721.
[5]刘步权、王怀民、姚益平，层次式仿真运行支撑环境StarLink中的关键技术[J].软件学报，2004，15（1）：9-16.
[6]黄显东，RTI仿真平台的体系结构研究与实现[D].北京：北京邮电大学硕士学位论文.2006.
[7]IEEE Standard for Modeling and Simulation （M&S） High Level Architecture （HLA）Federate Interface Specification （IEEE Std 1516.1-2000）. Institute of Electrical and Electronics Engineers， Inc， 2001.
作者简介：
齐连军，男，河北人，硕士研究生，研究方向：分布式交互仿真；刘春，男，沈阳人，硕士生导师，研究方向：虚拟现实及数字化制造。