Multi-Simulation Interface (MSI)
The Multi-Simulator Interface (MSI) is a simulation interconnection engine. In other words it is a program that connects simulations together by synchronizing their clocks and data. The MSI serves the same purpose as HLA and supports much of HLA's key functionality (and some more). The MSI is an HLA alternative. The major motivating factors in the design of the MSI are speed, interoperability, and ease of use.
The MSI was written as a cutting edge distributed simulation component to connect multiple instances of CSIM's premiere simulation software, CSIM, but it can be used to interface any compatible simulations.
The MSI is distributed under the Library GNU Public License (LGPL). The MSI source, binary and user manual are available at the Sourceforge site.
Click here to Download MSI-CSIM Example. (32-kB) Simple complete and self-contained example of MSI federation with build & run instructions. Unpack with tar xvfz, see the READme.txt, Build.com, and Run.com scripts. Creates a simple interactive two simulation federation. Moving the sliders in one simulator causes their values to be displayed in the other.
The MSI was originally created to be just a light weight HLA RTI. However, as it was written, limitations in HLA were discovered. The MSI is an improvement on both the design and implementation of HLA. Some highlights include:
The concept behind MSI is the synchronized data broker. There are many connected software systems that posses state data that changes over the life of that system. In the case where these systems need to exchange this changing data with other systems and the other systems will exhibit the effects of this data on their own state, the synchronization of this data may need to be managed.
Historically the management of this data has been as simple as tagging it with the time of it's release. If there is any conflict in the data the most recent version of the data is used. If the data is late an extrapolation can potentially be used. In SQL relational databases transactions and locking are used to ensure data integrity. Many data brokering services offer little or no sychronization, only delivery.
The MSI uses a XML stream through a direct socket connection for communications. This enables the MSI to be used from any programming language that can use sockets (C, C++, Java, Ada, Lisp, Perl, etc.). Also, the MSI was written with cross-platform libraries that make it portable to all the major OS platforms (Linux, Solaris, Mac OS X, Microsoft Windows, IRIX, HPUX, etc.).
The MSI is a single executable file and is distributed with example code for the simulator/federate side interface.
The MSI time synchronizer can mix unconstrained with time constrained simulations. Each constrained simulation reports the time of the next event that will occur in that simulation/federate. This time may be artificially inflated to cause loose synchronization (less overhead but less guarantee of accuracy). The simulations/federates will advance to the announced time.
The MSI implements a publish/subscribe data broker. The MSI is presently not validating, therefore it does not require a separate data format specification (like the HLA FOM). When data format validation is implemented, it will be an optional feature and not written in Lisp. This greatly reduces MSI's setup time. Also, not being locked to a predetermined data format allows for dynamic data types.
There are five commands associated with the MSI data broker: publish, subscribe, update, unsubscribe, destroy (destroy is not implemented yet). Simulations/federates may subscribe to object names in addition to object types. This allows simulations to subscribe to specific objects of a type without needing to receive updates of all objects of that type. The update command is both an incoming and outgoing command. When a simulation/federate receives an update command, it is expected to reflect the new values of that object.
The MSI has a very flexible publish and subscribe system. A federate may subscribe to an object type or an object name. In addition a federate may specify particular attributes of an object or object type. For example, if an object has attributes 'name', 'x', 'y', and 'z', a federate that only considers two dimensions may choose to subscribe only to 'name', 'x', and 'y'.
The MSI also supports systems of systems and object hierarchy in simulations. A publishing federate may designate a parent object. Subscribers may then subscribe to the objects children.
The MSI allows simulations/federates to send messages (interactions in HLA) to each other. These messages can contain multiple attributes and be multicast to a specific group of simulations.