This page describes the architectural design of the EODiSP core software. Please refer to the General Architecture documentation for a description of the overall EODiSP architecture.

Manager Applications

The core package provides an implementation of two manager applications - the simulation manager application and the model manager application. The primary purpose of the two manager applications is to:

• Control the HLA implementation, and
• Extend the functionality provided by the HLA implementation.

The need to extend the functionality of the HLA stems from the fact that not all requirements for the EODiSP can be covered by the HLA implementation. In order to keep the HLA part of the EODiSP implementation compliant to the HLA standard, all these non-HLA requirements are implemented in the two manager applications.

Requirements that are not covered by the HLA are, for instance, a facility to remotely start and stop a federate, setting a simulation to a hold state, etc. In order to be able to fulfill these requirements, the two manager applications need to be able to directly exchange data. Therefore, the EODiSP remote package is not only needed on the level of the HLA, but also on the level of the manager applications. Figure 1 illustrates the connection between the two manager applications. In addition to extending the functionality, the other purpose of the manager applications is to control the HLA implementation. This is, for instance, to start the RTI, add federates to a simulation, retrieve informations about a running simulation, etc. These functionalities is covered directly on the level of the HLA.

The figure shows how the two manager applications are connected. Another important point that the figure illustrates are the virtual machines in which the applications run. As illustrated in the figure, the simulation and the model manager applications run in different virtual machines. These virtual machines could be located on one physical computer or on different computers. The EODiSP remote package works in both situations transparently.

The two manager applications do not implement any GUI-based functionality. The GUI part of the simulation and model managers are implemented in a separate software package (EODiSP GUI package). To each manager application, a GUI application is associated. Thus, to the simulation manager application, a GUI simulation manager application is associated and to each model manager application, a dedicated GUI model manager application is associated.

An important point to note is that the manager applications and their associated GUI implementations run in the same virtual machine. Since the EODiSP does not include a requirements to physically separate the GUI from the core implementation, this architecture is more effective. However, some data must be accessible to both, the GUI and the core implementation. In this situations, access blocks (indicated by dark green boxes in the figure) are created. All of these access blocks expose a well defined interface with which both the GUI and manager applications can work. This has been chosen as a baseline architecture since it is regarded as more effective, especially from the point of view of the GUI implementation.

As indicated in the figure, the simulation manager application can exchange data with the model manager application through a well defined interface, the 'Model Manager Remote API'. On the other side, the model manager application can exchange data with the simulation manager application through the 'Simulation Manager Remote API'.

As already mentioned, the manager applications do not have a graphical user interface but provide a management interface built on top of JMX. The manager applications are configurable and manageable by using this interface. However, a graphical user interface in Java Swing is implemented separately in the EODiSP GUI software package.

Repository

The model repository provides a facility to keep track of the simulation models (encapsulated as HLA federates) that have already been created and that are potentially available for inclusion in an EODiSP simulation. The repository also allow the model managers (the 'owners' of the simulation models) to restrict access to the their models to selected simulation managers.

Depending on the application, the repository serves different purposes. For the simulation manager, these are:

• Registering/unregistering itself in the repository as a simulation manager.
• Retrieving a list of all registered federates in order to integrate them in a simulation.
• Validate the federates and their interconnections for a particular simulation prior to starting a simulation experiment.

And for the model manager:

• Register/unregister the federates that are integrated in the model manager application as being available.
• Retrieving a list of simulation manager applications in order to restrict access to the federates.

Having such a repository has many advantages. The most prominent advantage is that a simulation manager can access information about federates even if they are not running. The only thing that needs to run and also needs to be accessible is the repository itself. This means that the repository needs to run on a machine that is publicly accessible. The next figure shows how the repository is accessed by the different applications.

Since both the manager applications and the GUI need to access the repository, a separate access block is implemented (the 'Repository Access'). This access code belongs to the core package implementation but exposes an interface which also the GUI can work with. As shown in the figure, all three components run in a different virtual machine. This usually means that they run on physically separated machines. But again, it is also possible to run them on a single machine.