1.3 - Simulation Standards Supported

Table of Contents

• 1.3.1 Support for the HLA RTI 1.3 and RTI 1516 Specifications
  • 1.3.1.1 Compatibility of RTI 1.3 and RTI 1516 Applications
  • 1.3.1.2 Support for FED and FDD (XML) Files
• 1.3.2 HLA FOM Support
  • 1.3.2.1 RPR FOM Versions Supported
  • 1.3.2.2 Support for FOM Agility

VR-Link supports HLA and DIS.

For a list of the versions of the simulation standards supported by your release of VR-Link, please refer to your release documentation. You can also check the MAK web site for platform support updates at: http://www.mak.com/support/product-versions.html.

For a brief discussion of DIS and HLA, please see 2.2 - HLA, DIS, and Protocol Independence.

1.3.1 Support for the HLA RTI 1.3 and RTI 1516 Specifications

VR-Link supports the HLA 1.3 specification, the HLA 1516 specification (SISO DLC HLA API), and the HLA Evolved (IEEE 1516-2010) specification. VR-Link's protocol independent interface lets you create applications for use with any version of the HLA largely without regard to the details of the RTI. Any code that you have written for use with the RTI 1.3 specification should be usable with RTI 1516 or HLA Evolved with very few, if any, changes.

VR-Link supports the SISO DLC HLA API 1516 (SISO-STD-004.1-2004). This API supports dynamic link compatibility, which was problematic with the original IEEE 1516 API. The IEEE 1516 API only supports compile time compatibility (uses C++ templates and implementation-specific header files). VR-Link is compatible with any RTI written to the SISO DLC HLA API 1516.

HLA Evolved is the latest version of HLA. It builds on the work done by the SISO DLC HLA API group to provide a dynamic link compatible API. It includes additional features such as FOM modules and update rate reduction.

Note

In most cases, VR-Link's implementation of HLA Evolved is identical to HLA 1516. Therefore, any references to HLA 1516 in this manual should be considered to apply to HLA Evolved as well, unless noted otherwise.

1.3.1.1 Compatibility of RTI 1.3 and RTI 1516 Applications

If you use the MAK RTI, applications built using the VR-Link 1516 APIs can interoperate with applications built with the VR-Link 1.3 API. For example, if you build the listen example with the 1516 API and the talk example with the 1.3 API, they can interoperate. For more information, please see 5.11 - Interoperability Between HLA 1.3 and IEEE 1516 Federates.

1.3.1.2 Support for FED and FDD (XML) Files

VR-Link supports HLA configuration files in both the FED and FDD (XML) formats. When you create an exercise connection, you can specify a .fed file, .fdd file, or .xml file. You can use any of these formats with RTI 1516, HLA Evolved, and RTI 1.3.

If you do not pass a filename to the exercise connection, VR-Link uses the federation execution name as the filename. If you are building for RTI 1516, VR-Link looks for a file name federation_execution.xml. If it cannot find a file with this name, it looks for a file named federation_execution.fdd, then for federation_execution.fed. If you are building for RTI 1.3, VR-Link looks for a .fed file first, then an .xml or .fdd file.

1.3.2 HLA FOM Support

VR-Link provides extensive built-in support for the Real- Time Platform Reference FOM (RPR FOM). (For version information, please see release documentation.) The RPR FOM is a reference FOM developed by the SISO-sanctioned RPR FOM Standards Development Group, which consists of representatives from many companies that used the DIS protocol in the pre-HLA era.

The goal of the RPR FOM is to facilitate a priori interoperability (to about the extent we had in DIS) among HLA simulations that choose to use it. In other words, if you use the RPR FOM (either as is, or with your own extensions), then you know that you will be able to interoperate with anyone else who chooses to use this FOM. Another advantage of using the RPR FOM is that many simulation tools, including those offered by VT MAK, support this FOM.

1.3.2.1 RPR FOM Versions Supported

VR-Link 5.4.1 has built-in support for:

• RPR FOM 0.5, 0.7, 0.8, 1.0
• RPR FOM 2.0, drafts 6, 14, 17, and 20
• RPR FOM 2.

By default, all VR-Link examples use RPR FOM 2.0. The DtVrlApplicationInitializer class, however, still defaults to using RPR FOM 1.0.

VR-Link does not officially support RPR FOM 2 Draft 18. However, the draft appears to be similar enough to RPR FOM 2 Draft 17 that the 2.0017 FOM Mapper may be used for federates wishing to interoperate with RPR FOM 2 Draft 18.

If you want to use a version of the RPR FOM other than 1.0, pass the version number (0.5, 0.7, 0.8, 2.0006, 2.0014, 2.0017, 2.0020, 2.0) to the DtRprFomMapper constructor and pass the resulting object to the DtExerciseConn constructor. Also, make sure you are using a federation execution name that corresponds to the right FED file. For example:

DtExerciseConn conn("MAK-RPR20017-1-1.fed", "MyApp", new DtRprFomMapper(2.0017-1));

VR-Link examples like f18 and hlaNetdump have a command line option, –rprFomVersion, that you can use to choose a RPR FOM version, using one of the version numbers listed in the previous paragraph.

1.3.2.2 Support for FOM Agility

In addition to its built-in support for the RPR FOM, VR-Link can be configured to work with other FOMs, by using its FOM Mapper to define mappings between VR-Link's protocol-independent interface and the objects, interactions, parameters, and attributes defined in your FOM. For more information about VR-Link's FOM Agility, please see 6 - FOM Agility.

VR-Link has a FOM Mapper for the MATREX FOM. For details, please contact your MAK salesperson.

[<< VR-Link Features] [Home] [Top of Page]