provides a standardized interface for distributed simulations. The recent advent of HLA has greatly increased interest in the use of distributed, interoperable simulation model components. To date, most models using HLA have been developed in conventional

pitfalls of C (e.g. freeing memory although there still is a pointer pointing to it, exceeding the boundaries of arrays, mismatched types, etc.). SLX strings are different from those of C. SLX internally keeps track of the current and maximum length of strings and does not use the zero-termination of C.

These examples illustrate that some data type conversion is unavoidable when data are manipulated by both SLX and C/C++. Since the RTI is C++ based, some type conversions are necessary to use RTI functions from an SLX program. It is therefore not possible to directly access the ambassador objects. Given these shortcomings, we must ask whether they outweigh the gains of using SLX as a modeling tool.

Fortunately, the solution to the problems stated earlier is very straightforward: a simple “wrapper”library callable from SLX can be developed to wrap around the RTI (Figure 4).

Figure 4: Connecting SLX to the RTI using a wrapper library

Communication between SLX and RTI

The methods of the RTI ambassador object (C++ functions) that have to be called from SLX are wrapped by “normal“C-functions which can be called by SLX. This is done on a 1:1 basis for each HLA function required. The wrapper functions perform the necessary conversions between SLX data types and RTI data types. They also simplify RTI programming efforts for the SLX user. The process of dealing with the somewhat confusing RTI types (attribute handle set, attribute value pair set, ...) is hidden from the SLX user.

Communication between RTI and SLX

Another task that the wrapper library has to perform is the implementation of the federate ambassador object. The federate ambassador is responsible for receiving all kind of data from the RTI. This reception process is handled internally by the wrapper library. Since the wrapper library cannot call SLX to tell that something has happened, a mailbox-principle is used: The federate ambassador stores the data that were received in an SLX object in a fixed structure. The SLX model can then access this object to query the things that happened outside. This is both straightforward and suitable for performing the required tasks.

In addition to this static object, our solution introduces dynamic structures for the actual objects that are being modeled. When a simulation models certain objects and interactions according to its HLA simulation object model, these HLA logical structures are mapped into real SLX objects which can be accessed from SLX and the wrapper DLL. This simplifies the process of sending and receiving attribute updates or interactions. The problem with this approach is that the wrapper library does not know the structure of these SLX objects at compile time. Therefore the DLL has to calculate the address of each object attribute at runtime. However, the SLX run-time environment provides C/C++ callable library routines which the DLL wrapper uses to retrieve attribute address information using attribute names or pointers. This guarantees error-free mapping into SLX objects.

Synchronization Issues

The HLA programming paradigm expects a federate to tick the RTI to trigger the reception of any currently pending callback invocations by calling the tick-method of the RTI ambassador. This is usually done during the interval between requesting a time advance and waiting for the according time advance grant. As a simplification for the SLX user, this is handled internally by the wrapper library. The SLX user simply requests to advance to the next logical event time and then (after a while) receives a time advance grant.

forever

{

NextEventTime= next_imminent_time();

grantTime = RTI_NextEventRequest( NextEventTime);

wait until (time == grantTime);

... // query any external events

yield; // hand over control to other simulation threads }

Figure 5: Code fragment of the synchronization thread used in SLX corresponding to the general shown in structure figure 2