EODiSP HLA Architecture
This page describes the architectural design of the EODiSP HLA software package. Please refer to the General Architecture documentation for a description of the overall EODiSP architecture.
The EODiSP HLA provides an implementation of the High Level Architecture (HLA). This page gives a very brief introduction to this standard. Please refer to the official IEEE 1516 standard documents for more information.
Contents
HLA components
The High Level Architecture's structure envisages two main components: The Runtime Infrastructure (RTI) and several federates. A federate is a part of one simulation which, in HLA terms, is called a federation. Thus a federation is made up of several federates that have agreed upon a common set of data to be interchanged between them. The RTI provides the infrastructure that allows federates belonging to the same federation to communicate with each other in a distributed environment. Figure 1 shows how the federates interact with the RTI. Federates do not directly communicate with each other but always through the RTI.
Figure 1: Basic structure of the High Level Architecture (HLA)
Federates communicate with the RTI through a well defined interface. This interface, the RTI Ambassador interface, defines several services which a federate can call upon the RTI. A federate is only allowed to communicate through this service interface with the RTI. Callbacks from the RTI to the federate are defined through the Federate Ambassador interface. The RTI can call services on this interface to interact with the federates. Figure 2 shows the communication channels between a federate and the RTI.
Figure 2: Communication Channels between a federate and the RTI
The EODiSP HLA implements a subset of the services defined in the HLA IEEE standard only. A separate page lists the HLA services that are supported by the EODiSP implementation.
The RTI
The runtime infrastructure (RTI) is implemented as a distributed component by itself, split into a Central RTI Component (the CRC) and one or more Local RTI Components (LRC). Figure 3 shows these components of the RTI.
Figure 3: Components of an RTI
Each of the RTI components (CRC and LRC) can run on a different node and each RTI component can communicate with any other component. This allows the LRC to directly communicate with another LRC but it also allows the CRC to communicate with any LRC. Note, however, that a federate never communicates with the CRC directly but always through the LRC. In practice this means that the LRC exposes the RTI Ambassador interface to the federate. Accordingly, the CRC does not communicate directly with a federate either but again through the LRC only. The LRC translates calls from the CRC to calls on the Federate Ambassador interface on the federate.
In the EODiSP, in order to make the RTI components manageable, both the LRC and CRC are instrumented with interfaces that correspond to the the Java Management Extension (JMX) standard.