High-level Architecture (HLA) versus Distributed Interactive Simulation (DIS)
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.
There is nothing in the HLA specification that says the RTI has to be centralized, although almost all RTIs are.
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