General Architecture

This page describes the overall architecture of the EODiSP. The intention is to give a description of what each of the EODiSP software package does and how these software packages interact and work together. This description is fairly high-level. Please refer to the documentation of each software package for a more detailed description of its architecture.

The EODiSP software packages are also referred to as EODiSP applications. This is because each EODiSP software package is an EODiSP application. In general, in this page, the term 'EODiSP' is used to refer to the set of applications that are required to configure and run a simulation. The EODiSP environment also provides a set of so-called 'support applications'. The support applications are intended to help users perform off-line tasks that are required prior to running a simulation (such as the generation of wrappers to transform generic simulation packages into HLA-compliant models ready to be integrated in the EODiSP) or after a simulation as terminated (such as post-processing of simulation data). This page does not document the support applications which are instead covered in a dedicated page.

Contents

Overall EODiSP Structure

The overall EODiSP structure is presented in the EODiSP overview page and in particular in the description of the conceptual structure and the HLA structure of a simulation instantiated from the EODiSP.

The EODiSP Software Packages

The EODiSP project consists of five major software packages. These software packages encapsulate major EODiSP functionalities and are intended to be decoupled from each other. The five software packages are: the EODiSP core, the EODiSP HLA, the EODiSP remote, the EODiSP GUI, and a package defining a set of wrapper applications. In addition, an EODiSP utility package is provided. This latter package is not regarded as a major software package since it implements low-level common tasks for all other software packages.

The first three packages - the core package, the HLA package, and the remote package - implement the EODiSP core framework. The GUI package and the wrapper package are support packages that facilitate the use of the EODiSP framework, but would, technically speaking, not be necessary. The figure shows all these packages and how they depend on each other.

Structure of a Simulator Instantiated from the EODiSP

Figure 1: Structure of a Simulator Instantiated from the EODiSP

The arrow in the figure indicate that a package uses or controls another one. The arrows should not be taken to mean that the data flow is uni-directional. It will be noted that all packages can make use of the utility package which includes an implementation of common code implementing low level functionalities like configuration, data conversions, etc.

These packages are described in the following sections.

EODiSP Core Framework

As mentioned earlier, the core framework of the EODiSP consists of three packages - the core package, the HLA package and the remote package. These three packages are kept separate because they implement logically distinct functionalities and because there may be a desire to use them independently of each other or to replace them within the EODiSP.

EODiSP HLA

The EODiSP is built as an implementation of the High-Level Architecture (HLA). The HLA is the most widely used simulation architecture and is formally defined in the IEEE standard 1516. Adherence to the standard allows interoperability and reusability of simulation models. The HLA is a modular architecture. It is defined as a bundle of services that support various aspects of a simulation. In general, a particular simulator will only need a subset of all the services defined by the HLA. The set of services supported by the EODiSP is defined on the HLA Services page. The selection of the services was done keeping in mind the intended usage of the EODiSP as a platform for earth observation end-to-end mission simulations.

the advantage of providing a dedicated HLA package is that, at least in principle, it gives developers the option to use this package sepaately from the other EODiSP packages as a self-standing implementation of the HLA standard. It also gives the option to developers to replace the HLA implementation provided with the EODiSP and to use an alternative HLA implementation.

As shown in the figure above, the HLA package uses the EODiSP remote package which implements the network infrastructure part of the EODiSP. Note that the HLA standard does not specify a network infrastructure for the HLA. Also for this reason, the network infrastructure for the EODiSP is implemented in a dedicated package leaving again open the option to replace it.

The HLA implementation is the central part of the EODiSP, since all other packages are built around it. It in particular specifies the interfaces to which simulation models must comply. Furthermore, it implicitly defines the minimal features supported by the EODiSP.

The implementation of the HLA services in the HLA package is split into a CRC (Central RTI Component) and a LRC (Local RTI Component). See the HLA Architecture for more detailed description.

EODiSP Core

This is the non-HLA part of the core of the EODiSP framework. Its purpose is:

  • To control the HLA implementation, and
  • To implement additional functionalities on top of the HLA implementation.

The need for the former purpose is obvious since there must be a component which can control the HLA functionality and which implement functions such as creating and managing a simulation. The latter purpose stems from the fact that not all requirements for the EODiSP can be covered by an HLA implementation. For instance, the EODiSP needs to be able to find other applications that participate in a currently running simulation. This - and other - functionalities cannot be covered at HLA level and are therefore provided by the core package.

The fact that there is additional functionality on top of the HLA led to the decision to decouple this package from the HLA implementation. Decoupling these two packages has the further advantage that the HLA implementation remains a self-contained package that complies to the HLA standard which can, at least potentially, be used separately from the EODiSP.

The core package provides the code implementing three separate applications - the simulation manager application, the model manager application, and the repository application. The simulation manager and model manager applications are provided to allow a user to configure and control the execution of a simulation (see the description of the EODiSP user interface). Note that GUI-based front-end for these two applications is defined in the GUI application package. The repository application encapsulates and provides access to a centralized repository holding the description of all the simulation models potentially accessible to the EODiSP users.

Additionally, the core package includes several modules that allow the simulation manager, model manager, and repository applications to exchange information and to control each other. Note that these three applications must be able to communicate with each other directly without the HLA package. This architecture is necessary because the simulation manager, model manager, and repository applications must provide functionalities on top of the HLA.

A detailed explanation of the core package is given in the EODiSP core Architecture documentation.

EODiSP Remote

As its name suggests, this package is responsible for transferring simulation data over a network. The network can be local, a LAN (local area network), or the Internet. The remote package is built on top of a JXTA network infrastructure and implements a remote method invocation mechanism (similar to the RMI implementation in Java). Note that the JXTA infrastructure can be used to establish a connection between two nodes even if they are behind a firewall or a NAT server. This allows the creation of distributed simulations where some of the simulation nodes are located behind firewalls.

Since both the core and the HLA packages can send data over a network, both packages use the remote package. They do not have any network code directly integrated within them. This also ensures that the remote package could, in principle, be replaced with another package providing a different implementation of the networking infrastructure.

EODiSP GUI Applications

The EODiSP core application is operated through two GUI applications: the simulation manager and the model manager applications.

The simulation manager GUI can only be instantiated once. It controls the simulation environment. The model manager GUI is instantiated at least once for every distribution node that participates in a simulation.

A model manager application controls a set of simulation models (or HLA federates) that reside on the same node. The model managers act as clients to the simulation manager (the server).

The two GUI applications work tightly together with the corresponding applications in the core package. The GUI application and its counterpart in the core package run on the same node without any need for a remote connection in order to communicate with each other. The communication between the two applications is through the Java interfaces that they expose. This implies that the simulation manager (from the EODiSP core package) and the simulation manager GUI (from the EODiSP GUI package) cannot run on different nodes. The same is true for the respective model manager applications. In principle, it would be possible to separate these applications and let them run on different nodes but this would add considerable complexity and it was therefore decided to keep these applications tightly coupled.

Most of the functionality to run a simulation experiment is implemented in the core package application. The GUI applications are primarily aimed at providing an environment where the use can set up a simulation and control its execution. The two most important features of the GUI applications therefore are:

  • To assemble a simulation experiment through a graphical user interface, and
  • To control the core application through a graphical user interface

The two GUI applications share certain common features and it is desirable they should have a similar look and feel. For this reason, a small GUI framework has been built as a common basis from which the two GUI applications are instantiated. This is described in the GUI Architecture documentation.

EODiSP Wrapper Applications

The HLA, among other things, defines the interface between the simulation models and the simulation infrastructure (i.e. the EODiSP core). Hence, in order to be integrated with the EODiSP core, simulation models must comply with an HLA interface.

The EODiSP explicitly supports the concept of model wrappers. A wrapper is a piece of code that transforms a given simulation model into an HLA-compliant model. The wrapper typically changes the external interface of a model to make it comply with the HLA interface requirements. Wrappers obviously depend on the structure of the model they wrap. For this reason, it is not possible to provide a wrapper for every possible kind of model.

However, the EODiSP recognizes that there are some types of models that are more likely to occur in earth observation missions and, for these types of models, it provides predefined wrappers. It additionally provide a number of support applications that can automatically generate all or part of the wrappers. The EODiSP Wrapper Application package contains the code that implements the wrapper generators. Note that most of this code is XSL-based rather than Java-based as for the rest of the EODiSP.