What's HLA?

HLA (High Level Architecture) is a general purpose architecture for building distributed simulations. In other words. HLA is not a library, but a series of concepts and rules for defining how piece of simulation communicate each other.

The HLA standard defines following things:

• RTI: Run-Time Infrastructure, it's a library that provides a specific interface for communicating with the simulation. The API is standard and it's defined in specifications. Every library HLA compliant must provide this interface. In theory it should be possible to change the implementation of HLA used in our simulator by simply replacing the library with the new one;
• OMT: Object Model Template, it describes the data that must be exchanged in the simulation;
• Rules: This is the set of rules that must be satisfied by all parts of the distributed simulation in order to exchange data properly.

In other words, HLA does not specify a layout for data packet that must be exchanged though the network (like DIS or CIGI), but it defines a set of API that must be used by programs that uses HLA. This allows different vendors to create different implementation of HLA for the network level, but for a user is transparent, since the API remains the same. RTI is that implements this API.

Who had the idea?

The first version of HLA was developed by the Defense Modeling and Simulation Office (DSMO), that wanted to create a new standard more flexible than DIS. The first standard was born from this work.

Then the HLA entered in the IEEE, that was revised and standardized in a new standard, with more features than the original one.

The next standard is in an advanced stage of development, and some companies have already implementing the current draft in their products.

So, there are three versions of HLA that are currently used:

• HLA 1.3: This is the standard defined by the DSMO;
• HLA 1516: This is the revised standard by the IEEE, and the last official one;
• HLA Evolved: This is the next release, stable but not yet official.

In our articles we'll try to be independent from the version. If we cover parts of a particular version, it will be specified.

Structure

The distributed simulation in HLA is defined by different parts:

• Federate: This is a single process that is linked to the simulation through the RTI infrastructure. It can be an executable, a library, or an entire simulator. It's identified by the single interface.
• Federation: This is a set of federates that communicates each other. For example in a company, in the same network there can be different simulators. These simulator are separated by the logical point of view, so they can set different federations so their federates does not interfere (especially if they exchange the same set of data). It can be useful also in a single simulator, if a part of it (for example, the avionics system) is a system that work in HLA. In this case it should be seen as a single federate, so the system will live in a single federation, with a process that will be a gateway between federations.
• FOM: The Federation Object Model is a file that specify the data structure that must be exchanged between federates. It's a file in which every structure is defined. All federates of a federation must share the same FOM.
• RTI: This is the infrastructure of the HLA simulation. It's the API used for exchanging data in HLA and contains the implemented logic for sending and receiving data through the network. The low-level implementation is not specified, but a federate that's full-compliant to HLA can change implementation by simply changing the libraries of HLA implementation.

RTI is an infrastructure defined by different components:

• Federation Management: A federate can join or leave a federation in any moment. This component allows to handle the federate connection, handling when it joins, when it leave, when it's paused or resumed, and other task related on how federates are connected;
• Time Management: All federates of a federation must be synchronized in time, in order to work properly. This component allows to handle the time synchronization along the simulation;
• Data Distribution Management: In the simulation  usually there are a lot of data that are exchanged. Think about a simulation with one hundred of virtual players, explosions, weapons and so on. This component has the responsibility to optimize the data connection. For example, if a data sent by one federate is needed only from another one, it sends packets only to that one. This and other rules are applied;
• Object Management: Data that are exchanged can be grouped into object. For example, a projectile is an object, like a car or an airplane. When an object is created, or destroyed this must be notified to the simulation. This components handles the object life cycle;
• Declaration Management: A federation uses a FOM that contains all data structure used, but it's not necessary that all federates must send/receive all the data. Often federates needs to subscribe only to a few structures of the FOM. This component is responsible of the registration of these data;
• Ownership Management: When a federate creates an object, it's usually responsible for it. If it's an airplane, the federates that creates it it's responsible for updating status, position and so on. There are circumstances in which instead is necessary that a federate can have the possibility to update the data of an object created by another federate. For example, in a radar simulation, there can be a federate that creates a player with a radar handled by a simulation engine. Then, a radar simulator wants to take the ownership of that radar, in order to command it. This is a case in which the ownership must be transferred. This way the radar simulator became the responsible for publishing its data. This is transparent for the rest of the federation, that will see always a radar and its data updated (they don't care who update them).

 Conclusion

In this article we had a brief introduction of what's HLA and how it works. In next articles we'll see how to work with them and we'll see some neat example. See you later!

Add comment