HLA Run Time Infrastructure: A Comparative Study

Distributed computer simulation systems use a general-purpose architecture known as HLA (High Level Architecture). HLA aims to provide common architecture for all types of distributed modeling and simulations by providing interoperability and reusability among simulations. A middleware known as RTI (Run Time Infrastructure) provides distributed simulation services under HLA. RTI offers a communication framework which is necessary for federates to interact during simulation process. Many RTI implementations are available commercially and are open source to achieve reusability and interoperability by implementing HLA. However, functionality and performance of RTI is based on its structure. This review presents the performance analysis of multiple RTI implementations, so that the best suitable RTI can be selected for a given simulation scenario and provides the structural comparison of central and service distributed RTI. It also presents the performance analysis of multiple RTI implementations and provides the structural comparison of CeRTI (Central Run Time Infrastructure) and SDRTI (Service Distributed Run Time Infrastructure). Many simulations use HLA, and RTI as basic part of these simulations. This comparative study describes characteristics of different RTIs, their comparisons and implementations that will help the reader to select suitable RTI according to environment and requirements.

Distributed systems are introduced to solve complex computational problems that by dividing them into many components. Each of them is solved by one or more computers which communicate with each other through message passing. HLA [1] presents an architecture for distributed modeling and simulation. The main purpose of this architecture is to make possible the reuse of RTI is responsible for the communication (data exchange) between federates during execution [5].
There are three parts of the HLA. First is Interface Specification [6] that defines the process of how middleware [7] interacts with the HLA simulation RTI.
Second part is HLA Rules [2], the simulation must follow the rules in order to meet the standard. Third and last part is Object Model Template [8] that specifies the rules for message exchange between simulations and defines what kind of information should be communicated [9]. FDK (Federated Development Kit) [10] is based on modules. These modules can be composed and used for different RTI's build. FDK is designed, so the developers can choose the most appropriate FDK module for the development of their RTI implementation [11].
There are many RTIs available in the market but their functionality and performance differs based on the structure and approach of RTIs. Structure of RTIs will be reviewed based on different parameters later in the article which can help to understand the differences of different RTIs. Moreover two different approaches/architecture SDRTI and the CeRTI will be analyzed for better understanding of RTIs. The purpose of this review is to simplify the selection of RTIs to a certain type of simulation based upon particular requirements. For example, if a simulation needs high speed or real time communication among components then it can be done based on provided review.

SIMULATION
System Simulation [12] means regenerating the behavior of the system over time.

Parallel and Distributed Discrete Event Simulation
Multiple processors are called in parallel for distributed discrete event simulations in discrete event simulation program. [15]. These types of simulations are executed on tightly coupled computer systems such as shared memory multiprocessors (clusters) in case of parallel discrete event simulations [16]. All processors connected with each other use high-speed switches. The advantage of using high-speed switches is low communication latencies. Loosely coupled computer systems are required in order to execute distributed discrete event simulations.

Workstations, interconnected via LANs (Local Area
Network) or WANs (Wide Area Network), are example of this type of system [17][18]. In loosely coupled systems, communication latencies are higher than the tightly coupled systems [19].

HIGH LEVEL ARCHITECTURE
The HLA has been developed by the United States Department of Defense as a standard for common architecture of distributed modeling and simulation [3].
HLA is an integrated technique to provide a common framework for the inter connection of different interacting simulations. The basic purpose of HLA is to provide a common simulation infrastructure that can support interoperability and reusability for simulations. HLA is used in a number of simulation application areas such as education and training, engineering and analysis.
The HLA consists of three parts

Interface Specification
There are ten HLA Rules the must be followed by

HLA Run Time Infrastructure: A Comparative Study
The interface specification describes standards for RTI.
It provides a generic communication interface for RTI.
Interface Specification ties with federate during model execution [6].  [24][25]. Declaration Management is for subscribing and publishing object attributes and interactions [26]. Object Management is responsible for sending object attribute updates and interactions, creation and deletion of object instances and object reflections [9]. The Time

RUN TIME INFRASTRUCTURE
Management service is used to coordinate the advance simulation time and relationship between the real time and the advance simulation time [27]. Data Distribution Management service is responsible to rout data efficiently between federates or federations [28]. To increase the scalability, common techniques are used including hierarchies and reduction networks that are standardized with the architecture by components. The RTI architecture is able to adopt the changes and ready to adopt changing requirements and technologies [29].

COMPARISON
HLA implementations (RTI) support interoperability and reusability as their basic purpose [51][52]. Currently available implementations of RTI respond differently to HLA exercises. All RTIs perform same task that is acting like a middleware during simulation. However, all have some distinct features, for example, some preform best in small-scale simulation and some in large-scale simulations. Some have specific best implementation of one or two RTI services, which makes them unique.
Selection of a RTI is strictly based upon your simulation nature. If simulation demands faster communication between federates you probably select the RTI with the best implementation of data distribution management service.
RTIs can be compared with one another on the basis of their basic features like HLA compliance, presence of RTI Executive process and the transportation mode of data that has been used to interact with federates [53]. HLA compliance means that the RTI implementation is Compliant with the HLA evolved standards. With respect to RTI's functionality, many aspects required some centralized knowledge. To manage this centralized knowledge there are two strategies. One is to make RTI LRC (Local Component) that is responsible for one federate and the other is to make a central server application known as RTI Executive or rtiexec.
Transportation mode can be the best effort, reliable or both. In Best effort transport mode federates data obtains unspecified variable bit rate and delivery time depending on the current traffic load, but the reliable transport mode built on top of best-effort possibly without latency.
The comparison of RTI implementations based on the features they provided shown in Table 2. The performance of federates in a simulation also depends upon many factors like type of network, hardware platform, operating system and the chosen RTI's capability.

Service-Distributed Run Time Infrastructure vs. Central RTI
The structure of a RTI can be central, distributed or hierarchical. Most RTIs are based on central structure.
Services are provided through an interface as a special programming language binding and platform binding as shown in Fig. 2 Fig. 3. The other advantage is that it overcomes the drawbacks of central RTI and provides effective load balancing solution on the internet.

CONCLUSION
All HLA implementations provide interoperability and reuse facility, as it is a basic purpose of HLA. Each implementation has its own pros and cons. As RTI provides services to federates in runtime execution so performance and stability of federates depends upon the selection of RTI.