5.10 - Interoperability Between HLA 1.3 and IEEE 1516 Federates

In general, the MAK RTI, and various other MAK tools support run-time interoperability between HLA 1.3 federates and IEEE 1516 federates.

Federates that are using Federation Management, Declaration Management, Object Management, Time Management, and Data Distribution Management services should be able to interoperate across the 1.3-1516 boundary. For example, you can typically run the HLA 1.3 version of the VR-Vantage Stealth and the IEEE 1516 version of VR-Forces together in the same federation execution, provided you are using the MAK RTI, or another RTI that supports 1.3-1516 interoperability.

However, there note the following restrictions and requirements:

• MOM is not currently supported across the 1.3-1516 boundary, and must be disabled. (The 1.3 and 1516 specifications dictate completely different data representations for MOM attributes and parameters.)
• Ownership management is also problematic, and should be avoided. For object names, the 1516 RTI converts all strings from the wide char representation to a narrow character representation. So, the names supplied by the 1516 federates must allow this conversion (that is, only support the ASCII character set). For user supplied tags, the 1516 federates are restricted to the 1.3 string format. The 1.3 RTI cannot represent the complex data types allowed by 1516.
• Although federates might differ in the version of the HLA they use (1.3 versus 1516), they must agree on a common FOM representation to use. All federates must use either an HLA-1.3-style FED file, or an IEEE-1516-style XML file. (VR-Link and the MAK RTI allow you to use HLA-1.3-style FED files with IEEE-1516-based federates, and vice versa.)

The main reason that consistency in FOM format is necessary is that HLA 1.3 and IEEE 1516 use different names for the "Root" classes of the Object and Interaction class hierarchies. A 1.3-style FED file requires a Root class called "ObjectRoot", whereas a 1516-style XML files requires a Root class called "HLAObjectRoot". This is a problem because if a federate uses an HLA-1.3-based FED file, it might subscribe to a class called "ObjectRoot.Vehicle". On the other hand, a federate that is using an IEEE-1516-style XML file might publish a class that is meant to be the same class, but that is actually named "HLAObjectRoot.Vehicle". Neither the RTI nor the federates will realize that these classes were intended to be the same, and the subscribing federate will fail to discover any objects that the publishing federate registers.

[<< General HLA Issues] [Home] [Top of Page] [FOM Agility >>]