This page presents the detailed design description of the HLA Wrapper Generator application.

Objective

The EODiSP provides a platform for integrating HLA federates into an HLA federation. The interface between the user-provided federates and the EODiSP infrastructure is defined by the RTIambassador and FederateAmbassador HLA interfaces. Programming directly to these interfaces is is complicated and error-prone. The two main drawbacks are the lack of type-safety and the lack of a direct relationship between HLA object classes and Java classes.

The HLA Wrapper Generator application solves these problems by automatically generating a Java skeleton that implements the part of the federate that is independent of the simulation package that the federate wraps and that provides hooks where users can hang package-specific code.

Structure of Generated Code

The HLA Wrapper Generator takes as its input the SOM of the target federate and generates four kinds of items.

The first kind of generated items are Java interfaces. For each object class defined in the SOM, a matching Java interface is created. This Java interface defines the attributes of the object class as getter and setter methods. These methods are type-safe in the sense that they don't define their parameters and return types as a Java byte array (as in the RTIambassador interface), but directly as Java types. The interface also defines an updateAttributes method. This method should be called by the federate when it wishes to start the update cycle for all or some of the attributes defined in the interface.

The object class attributes are typed. The HLA defines a set of basic types. The generator maps these types to Java types according to the table below. Note that, for numerical types, the HLA distinguishes between 'little endian' and 'big endian' types. The mapping to Java is the same for both kinds of types and hence the distinction is not made in the table.

HLA Type	Java Type
HLAinteger16	short
HLAinteger32	int
HLAinteger64	long
HLAfloat32	float
HLAfloat64	double
HLAoctetPair	short
HLAoctet	byte
HLAASCIIchar	char
HLAunicodeChar	char
HLAboolean	boolean
HLAunicodeString	String
HLAASCIIstring	String
(all other types)	byte[]

Thus, for instance, for an object class attribute 'name' of type HLAunicodeString the following setter and getter methods are generated:

• String getName()
• void setName( String name )

The second kind of generated items are Java classes that implement the the interface that defines the object class attributes. These classes encapsulate the attribute values and are responsible for tranferring these values to the HLA RTI by using the methods defined by the RTIambassador and FederateAmbassador HLA interfaces.

The third kind of generated items are Java listener interfaces. For each object class to which the federate subscribes, two listener interfaces are generated. One listener interface covers the notification of an attribute update. The second listener interface covers the notification of the creation of an object class on the part of the federate that publishes the object class. These listener interfaces must be implemented by the user.

The fourth kind of generated item is a class that is called <name>Federate. This federate class contains a factory method for each object class that can be instantiated and a method that does all the publications and subscriptions of object class attributes as defined in the SOM.

Sample Federate Structure

The user code that implements the rest of the federate would normally call the methods provided by the generate federate class to create the object classes that it needs and to manage the federate's attribute publication and subscription. Users are free to implement this code as they think best but the EODiSP provides two templates that can facilitate the task of linking the code generated by the HLA Federate Generator to the user code.

The first template class is called <name>FederateMain. As its name implies this code defines the main method for the federate (recall that in the EODiSP each federate is wrapped in its own JVM and therefore constitutes a self-standing application).

The second template class is called <name>FederateConfigure. This is a helper class that is responsible for managing the federate configuration process.

The <name>FederateMain and <name>FederateConfigure classes are called template classes because they are intended to be completed by the user. The points where the user should insert his code are clearly marked through comments in the class bodies.

The federates used in the EODiSP demonstrator are built using the template classes. Their source code is available through the demonstrator web site and can be used as blueprint of how EODiSP federates can be built.