The EODiSP proper consists of the set of applications that are required to configure and run a simulation. Typically, prior to running a simulation, a number of off-line tasks need to be performed. Some of these tasks can be partially or fully automated. A support application is an EODiSP-provided application that helps users in performing these off-line tasks.

The automatic generation of an EODiSP wrapper is a typical task that may be covered by a support application. This page accordingly gives an overview of the EODiSP wrapping approach and of how the wrapper generation process can be automated.

At present, only one support application is provided. This application is called the HLA Wrapper Generator. Its purpose is to automate the generation of the skeleton of an EODiSP wrapper. This page also gives an overview of this application.

EODiSP Wrappers

The EODiSP is intended to integrate simulation packages, namely pieces of software that implement part of the functionalities required for a simulation run and that are delivered as a single unit. The EODiSP provides an infrastructure to connect together simulation packages and to allow them to interact with each other to implement a complete simulation.

The EODiSP is built as an implementation of the HLA standard. The HLA defines the interface between the entities participating in a simulation (the HLA federates) and the simulation infrastructure. Hence, in order to be integrated with the EODiSP infrastructure, simulation packages must comply with this HLA interface.

It is unrealistic to expect all developers of simulation packages in the scientific and engineering community to provide HLA-compliant packages. For this reason, the EODiSP supports the concept of wrapper. A wrapper is a piece of code the transforms a given simulation package into an HLA-compliant federate. The wrapper typically adapts the external interface of a simulation package to make it comply with the HLA requirements.

Wrappers obviously depend on the structure of the model they wrap. For this reason, it is not possible to provide a 'universal wrapper'. The skeleton of the wrapper - the part of the wrapper that interfaces to the EODiSP infrastructure - does however have a fixed structure. The EODiSP accordingly provides an application that can automatically generate this skeleton. This application is called the HLA Wrapper Generator. The generator takes as an input an XML-based description of the HLA interface of the target model and automatically generates the Java source code that implements the wrapper's skeleton.

Although it is not possible to define a fixed structure for a generic HLA wrapper, it will often happen that wrappers that are targeted at similar models to be used in a certain simulator (or, perhaps, in a family of related simulators) do have a fixed structure. In such cases, it may be advantageous to develop a domain-specific wrapper generator.

In addition to making simulation packages HLA-compliant, the EODiSP wrappers may also serve a secondary purpose. In an HLA simulation, each simulation package publishes its outputs and it subscribes to the outputs of other packages. When a simulation package is thus linked to another simulation package, the need often arises to perform some simple data conversions. There may for instance be a need to add a bias to the output of a package, or to re-scale it, or to cast it to some new type. These operations are referred to as data conversions. Simple data conversions are best implemented in the simulation package wrapper and EODiSP wrappers may support some basic kinds of data conversions.

Wrapper Structure

In general, an EODiSP wrapper may serve two purposes:

• Language Bridge: the EODiSP is Java-based but simulation packages may be implemented in other languages (C/C++ and Fortran). The wrapper allows non-Java packages to be integrated in the EODiSP.
• HLA Bridge: the EODiSP is based on the HLA concept but simulation packages are not necessarily implemented as HLA federates. The wrapper is used to adapt the package interface to conform to the interface specified by the HLA standard.

In the EODiSP, these two functions of a wrapper are implemented in three separate elements. The resulting wrapper architecture is shown in the figure. Block 3 and 4 in the figure implement the HLA bridging function and block 2 implements the language bridging function.

The architecture in the figure covers the most general kind of wrapper. In many cases, simpler structures can be used. Block 2, in particular, can often be omitted. This will be most obviously the case when the simulation package is implemented in Java but it could also happen if the simulation package consist of an executable whose execution can be directly controlled from the connector code in block 3.

The choice of the architecture in the figure is driven by the desire to facilitate the automation of the wrapper generation process. The part of the HLA bridge that communicates with the EODiSP environment (Block 4) needs to implement the HLA Federate Interface Specification. This code is the same for all federates and only depends on the SOM the federate wants to expose. Therefore, the code implementing the federate interface can be generated in the same way for any HLA federate. The EODiSP offers a code generator to automatically generate this skeleton. Markers are placed in the generated code to tag the places where code needs to be added to connect this implementation to a simulation package (this is indicated by the two "holes" in block 4 in the Figure). The inputs for the generation of the block 4 code are the object class attributes the federate wants to publish or subscribe to. A SOM contains exactly this information and therefore serves as the input to the code generator.

The HLA Federate Interface Specification also contains the code implementing the data conversions. This point is discussed below.

In summary, the EODiSP wrappers have the structure shown in the figure above. In order to assist users in the construction of the wrappers for their simulation packages, the EODiSP at present provides two kinds of facilities:

• HLA Federate Interface Implementation Generator: this is an application that automatically generates the HLA federate interface implementation of a wrapper (block 4 in the figure).
• Sample Wrappers: these are complete wrappers for particular simulation packages. They are intended to be used as blueprints for the construction of user-specific wrappers.

In the future, it is expected that users that operate in a certain domain where models have a common structure may define wrapper generator applications that automatically generate the entire wrapper for simulation packages in that domain.

Data Conversion

Data conversions are implemented in the HLA Federate Interface layer (block 4 in the figure above). Data conversion is performed on the data as it is being received by a federate. This is illustrated in the next figure:

In the figure, federate A publishes data item x. Federates B and C subscribe to data item x but need to apply two different data conversions to it: federate B wants to add a bias of 1.4 to it, whereas federate C wants to perform a 10% rescaling on it. If the data conversion were applied at the point where the data item is published (i.e. on federate A), this double data conversion would not be possible. It becomes possible if instead the data conversion is applied on federates B and C.

The EODiSP wrapper generator support three types of default data conversions:

• Applying an additive bias to the input of a federate. The value of the applied bias is user-defined.
• Rescaling the input of a federate by multiplying it by a scaling factor. The value of the applied scaling-factor is user-defined.
• Casting the type of the input of a federate to a new type. The target type is user defined but is restricted to be type-compatible with the source type.

Data conversion is implemented as follows. For each federate input, the HLA Federate Interface Implementation Generator generates, as part of the HLA interface skeleton, a convert method. This convert method takes as an input the input value for the federate and returns the converted value. The implementation of the method is generated automatically. Four possible types of implementations can be specified by the user for this method:

• Bias: the convert method applies a fixed bias to its argument.
• Scaling: the convert method applies a rescaling using a fixed multiplicative factor to its argument.
• Type_Casting: the convert method performs a type cast on its argument. Type casting is performed in accordance with the rules of the Java language (recall that the HLA Federate Interface is implemented in Java).
• User_Defined: the convert method is empty and it returns the input value unchanged. This option is useful when the user wishes to implement some very specific data conversion. The conversion algorithm must then be hand-coded in the body of method convert.

Users who wish to perform data conversions more complex than those covered by default by the HLA Federate Interface Implementation Generator have two options.

• They can implement their own version of method convert as indicated above.
• They can implement the data conversion in a dedicated federate that acts as a "bridge" between the source of the unconverted data and the consumer of the converted data.
The second option is recommended for the case where non-trivial data conversions need to be performed. Note that the sample federates provided with the EODiSP include examples of federates performing complex data conversions. They can be used as templates for user-defined data conversion federates.

HLA Wrapper Generator

The HLA Wrapper Generator is an EODiSP support application that generates parts of the code of an HLA federate. The part of the code it generates is marked as block 4 in the first figure in this page. The input to the generator is the HLA interface description in the form of a SOM. The mode of operation of the generator is shown in the figure:

The HLA Interface generator also generates the code implementing the data conversion. It therefore needs information about what kind of data conversions (if any) should be applied to each federate input and about the values of the conversion parameters. The source for this information is still TBD.

The table below lists the types of services for which the HLA Interface generator generates code:

Service	Description
Startup	A startup method is generated that calls appropriate HLA services to initialize the federate and join it to a federation execution.
Shutdown	A shutdown method is generated that calls appropriate HLA services to cleanly shutdown and resign the federate from a federation execution.
Publishing	For each HLA object class with sharing set to "Publish" a helper method is generated that publishes all its attributes.
Subscription	For each HLA object class with sharing set to "Subscribe" a helper method is generated that subscribes to all its attributes.
Update Attributes	For each attribute with sharing set to "Publish" an update method is generated to update a particular attribute in the federation.
Reflect Attributes	For each attribute with sharing set to "Subscribe" a callback method is generated that is invoked whenever the attribute value is updated by the federation.
Data Conversion	For each attribute with sharing set to "Subscribe" a method is generated to apply a user-defined data conversion algorithm.

The generator also generates markers that identify the hooks where user-defined code has to be inserted.

Wrapper Generators

As indicated above, in some cases it may become advantageous to develop additional support applications that implement wrapper generators capable of generating the complete wrapper code for selected types of simulation packages. Such wrapper generators would generate both the HLA Interface Implementation Code and the Connector Code (blocks 3 and 4 in the figure at the top of this page) for the target simulation packages. The generators would be typically implemented as XSL programs and would have a structure as shown in the figure:

For clarity, the figure shows two separate generation processes, one for the HLA Interface code and one for the connector code. The wrapper generators however would be seen by the user as single generators.

The structure of the mapping files must obviously be specific to a particular category of simulation packages.

Supported Models

For all kinds of wrappers, an HLA Federate Interface Implementation Generator is provided to automatically generate the HLA Interface skeleton code. For selected types of simulation packages, further support may be provided in two forms: provision of sample wrappers, or provision of a generator for the connector code. The table below lists the types of simulation packages for which this additional support is currently available. The third column indicates whether support through sample wrapper ('S') or through connector code generator ('G') is provided. Note that at the time of writing no decision has yet been taken as to which kind of simulation packages (if any) should be covered with a code generator. This explains why in the last column all entries are 'S'.

Package	Description	Support
Matlab Simulation	A running Matlab simulation.	S
Excel Spreadsheet	Simulation package consisting of a Microsoft Excel file containing one or more spreadsheets to encapsulate databases holding simulation parameters or models coded as VBA macros.	S
Source Code	Simulation package consisting of a self-contained simulation program available as source code in C, C++, Java or Fortran.	S
Stand-Alone Executable	Simulation package consisting of self-contained simulation program available as an executable for one of the following platforms: Windows, Linux or Unix and using files for input and output.	S
Data Processing Package	Predefined software package (commercial packages, public domain package, etc) to perform standard data processing functions (data visualization, data logging, data analysis, etc).	S
SMP2	Simulation package consisting of the SimSat 2000 SMP2 simulation environment. The simulation environment may include one or more SMP2 compliant models.	S