High-level Architecture (HLA) versus Distributed Interactive Simulation (DIS)

Question

Is there a high-level overview of HLA versus DIS simulation frameworks? Can one host the other and vice-versa?

Answer 1

I currently (though only for another week or so) work in the simulation industry - I apologize in advance for any errors, I will correct them if I am remembering incorrect information.

DIS

• The standard specifies the layout of data on the wire, i.e. your packets/data PDUs are laid out exactly as defined in the DIS specifications

• Relies on best-effort networking (i.e. UDP protocol, broadcasting)

• Entities have to heartbeat at certain intervals (default: 5 seconds) to notify everyone else that it is still part of the exercise

• No central server managing the various applications joined to the exercise

• Simulation applications can join the simulation at any time, leave at any time

HLA

• Uses a central manager, called the RTI (Run Time Infrastructure), that receives data from various applications and sends them to other applications in the simulation (in the context of HLA, these are called Federates and a set of Federates is a Federation)

• All federates must join and leave the simulation by going through the RTI

• Unlike DIS, HLA specification does not specify the layout of data packets, but instead defines a set of API functionality that applications use. The RTI is what implements the API.

• HLA federates publish data according to a FOM (Federation Object Model) which defines what the data in a simulation represents. This allows people to create new FOMs that define new object and interaction types, unlike in DIS, where adding new types of data PDUs goes through a committee (SISO). For example, most simulations running under HLA utilize the RPR FOM, which pretty much mirrors the DIS standard entities and interactions.

• HLA adds additional features DIS does not support, such as Data Distribution Management (DDM), wherein federates notify the RTI that they are only interested in certain types of data.

• Supports subscription services, wherein federates notify the RTI that they are only interested in receiving certain object or interaction data (i.e. an application only wants data about ships)

• Supports the feature of ownership transfer, where objects under the control of one federate are given to another federate to manage.

Can DIS host HLA and Vice Versa?

Due to these fundamental differences, it should be clear that DIS and HLA can not host each other.

However, what this really means is that for simulations in DIS to interact with simulations in HLA is that you need some type of network broker that acts as an adapter between the two protocols. Examples of such brokers are MAK VR-Exchange or GMU Gateway.

For even further reading:

• http://www.mak.com/products/standards.php
• http://www.siaa.asn.au/get/2395379411.pdf
• http://dss.ll.mit.edu/dss.web/96.14.103.RTI.Introduction.html

Answer 2

Here is some lessor-known history regarding HLA.

The design of HLA is actually based on something called the Aggregate Level Simulation Protocol (ALSP) which was led in the early 90's by the same Mitre folks that developed HLA. ALSP was designed to link together large-scale constructive simulations used for Corps/Division Command Post Training. The requirements for ALSP interoperability involved larger numbers of objects, conservative time snchronization and exchange of simulation events. We could not afford to periodically broadcast entity updates as that would cause scalability problems.

In my later years of involvement we reached as many as 1 million battlefield objects per one of the Ulchi Focus Lens exercise. The fundamental difference between HLA and DIS is that HLA is designed to handle constructive large-scale, variable fidelity, conservative time managed simulations whereas DIS was born from a networked simulator environment and is focused on near-real-time, platform-level simulators.

HLA can help make these two classes of simulations interoperate to a degree but will always be limited by inherent differences in the types of simulations being linked.

For example, if a conservative time-managed simulation federate gets bogged down with calculations the HLA time management will cause the federation to stop moving time forward until the slowest simulation moves forward. DIS does not support this. To a DIS-driven platform, all the time-managed entities will appear to move in slow motion or stop altogether and periodically would appear to be moving faster than real-time as the federation tries to catch up to real-time.

Answer 3

There is nothing in the HLA specification that says the RTI has to be centralized, although almost all RTIs are.

Answer 4

The HLA 1516 Standard only defines the API between the simulator and the RTI. Not between RTIs. The protocol used to exchange data between RTIs is proprietary. Therefore only RTIs from the same vendor or government agency are able to interoperate. A major flaw. If you are using a different RTI you will need a "bridge" to translate between the proprietary protocols. This can be expensive.

Answer 5

One thing to keep in mind if you plan to bridge DIS and HLA is that you will possibly lose simulation fidelity on both sides depending on how your FOM is organized. DIS to RPR FOM is straightforward but there are other FOMs out there that may not map well at all to DIS. In some situations you may be unable to translate a PDU field to an HLA object attribute or interaction parameter (or vice versa). You will have to use your best judgment as to what kinds of default values to use in these situations. Other times the HLA FOM object hierarchy may be structured very differently from DIS. In this case the translation may require combining data from multiple DIS PDUs to form one HLA message. This means you will have to write code in the bridge to preserve some form of message state.

Also, at runtime you will get your HLA attributes piecemeal. After object discovery you will have to wait to translate an object instance until you have received enough attributes to populate the DIS PDU properly.

Another issue is that HLA can provides time management services. You would have a lot of synchronization problems to deal with if you tried to integrate a DIS application into a HLA federation using time management.

If you have a purchasing budget my advice would be to go with MAK VR-Exchange.