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

relatively conventional programming task. Additionally, there is the need to store data about remote objects in the local simulation tool. This is necessary because under HLA, such semantic information cannot be stored within the RTI; i.e., all object representation is maintained solely within the federates. Therefore a simulator has to somehow be able to receive updates and store them locally in order to make future use of them.

4 THE FOUR GENERAL SOLUTIONS Given the requirements discussed in section 3 we have identified four general possibilities for integrating existing simulation tools into the High Level Architecture.

1) Re-Implementation of the tool with HLA-

extensions

T his solution is, of course, the most obvious one. If the source code of a tool is available and well documented this is the most straightforward and probably the least complicated solution. Skopeo (Lorenz and Ritter 1997), a web-based animation tool developed at the University of Magdeburg, is an example of an animation tool for which HLA-compliance has been accomplished in this manner. 2) Extension of intermediate code

S ome simulation tools translate model descriptions written in a tool-dependent modeling language into another programming language (e.g. C++). This intermediate code is then compiled to an executable file. It is possible to modify this code to realize the HLA extensions. Since this code is compiler generated, an automated solution is desirable.

E xamples for tools that could theoretically be

extended in this way are ACSL, MODSIM, and JavaGPSS (Klein et al. 1998).

3) Usage of an external programming interface

T his solution is well suited for tools that offer an open and extensible architecture. The tool should offer a library interface (in Windows: a DLL interface) with the ability to call arbitrary functions or methods in these libraries. Additionally the tool should make it possible to to implement callback functions or methods.

S ection 5 of this paper describes a solution for the simulation tool SLX which is based on this approach.

4) Coupling via a gateway program

T he last solution for tools which can not be connected to the RTI by any of the prior methods is the development of a gateway program. The gateway program could communicate with the simulation tool via appropriate means (e.g. files, pipes, network)

depending on the capabilities of the simulation tool (Figure 3) .

Figure 3: Principle of the gateway solution

The gateway program would translate between the simulation tool and the RTI and therefore be the actual member (federate) in the HLA federation. Gateway programs are a common means for integrating existing applications (e.g. legacy applications such as DIS simulations) into HLA (Cox et al. 1996). A gateway could also be used for connecting older simulation tools for the DOS operating system such as GPSS/H to the RTI.

5 THE SOLUTION FOR SLX

SLX is a new discrete event simulation tool for the Windows 95/98/NT operating systems (Henriksen 1996). SLX has an open software architecture. It has a library interface which allows SLX programs to call functions in any standard Windows DLL. This is one of the basic prerequisites for connecting a commercial tool like SLX to the RTI without modifying the actual source code of the tool. In addition to this interface, SLX also offers the extraordinary feature of automatically generating C/C++ header files which describe the contents of SLX objects in C/C++ syntax. A C/C++ function which is placed in a DLL is easily called from SLX, and it can retrieve and modify the attributes of SLX objects.

Although SLX is a very open tool, not all of the requirements stated earlier can be fulfilled directly. For example, it is not possible to directly create instances of C++-objects inside SLX. Therefore it is not possible to call the methods of the RTI ambassador object directly from SLX. Furthermore it is not possible to directly implement the federate ambassador object with its callback methods inside SLX. In addition, there are some differences between SLX and C/C++ data types. Although SLX has a C-like syntax, there are differences between SLX and C in lowest-level data manipulation. For example, SLX protects users from many of the