2.2.1 The High Level Architecture (HLA)

HLA is required by the Department of Defense for use in all DoD simulations. In HLA, the types and formats of data to be exchanged among simulators are not standardized, as they are in DIS. Groups of simulators that want to play together must use the same Federation Object Model (FOM) and Run-Time Infrastructure (RTI). FOMs and RTIs are described in the next two sections.

2.2.1.1 The Federation Object Model (FOM)

Every federation execution requires a Federation Object Model (FOM), which defines the data model for the federation execution. Members of a federation execution can develop a FOM themselves, use an existing reference FOM, or build a FOM by starting with a reference FOM and modifying it.

A FOM is implemented through a Federation Execution Data (FED) file, which contains a subset of the FOM that is required by the RTI. VR-Link has extensive built-in support for the Real Time Platform Reference FOM (RPR FOM). More specifically, VR-Link supports the FOM defined within the FED file called VR-Link.fed, which is stored in the ./bin directory. VR-Link.fed represents the RPR FOM, plus a few extra classes that we have added.

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 available 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. An advantage of using the RPR FOM is that many simulation tools, including most VT MAK products, support this FOM.

Although VR-Link builds-in support only for the RPR FOM, it has features that allow you to work with new or modified FOMs and you can extend FOMs to meet your needs. The ability to work with a variety of FOMs is called FOM-agility.

You can configure VR-Link to work with other FOMs by using the VR-Link FOM Mapper to define mappings between VR-Link's protocol-independent interface and the objects, interactions, parameters, and attributes defined in the FOM.

For information about how VR-Link implements FOM-agility, please see 6 - FOM Agility. For a list of the RPR FOM versions supported by your version of VR-Link, please see VR-Link Release Notes. You can also view product version information on the MAK web site at http://www.mak.com/support/product-versions.html.

2.2.1.2 The Run-Time Infrastructure (RTI)

An RTI is an implementation of the HLA interface specification, that is, the services that make up the standard RTI application programmer's interface (API). An application can call the functions in the RTI's API either directly or through VR-Link. The HLA rules specify that federates must use the RTI to exchange all simulation data.

2.2.2 The DIS Protocol

The DIS protocol is a set of standards that govern how participating applications share information about a virtual world. The protocol specifies a set of packets, called Protocol Data Units (PDUs), that communicate this information. Each PDU identifies the sender and contains other information, depending on the PDU type. The DIS protocol also specifies when, and how frequently, PDUs are sent.

The table lists the DIS version numbers and their corresponding formal specifications.

DIS Versions
Version	Specification
0	Other
1	DIS PDU version 1.0 (May 1992)
2	IEEE 1278-1993
3	DIS PDU version 2.0 third draft (May 1993)
4	DIS PDU version 2.0 fourth draft (revised) (March16, 1994)
5	IEEE 1278.1-1995
6	IEEE 1278.1A-1998
7	IEEE 1278.1-2012 (DIS Evolved)

2.2.3 Protocol Independence

In this manual, the Protocol-Independent API refers to a set of classes that encompass most of the features of VR-Link and allow you to create applications that will work in both DIS and HLA without significant modification.

When you create a protocol-independent application, you do not create one executable that works with both protocols; you write one application and compile it for each protocol by specifying the protocol at compile time. In cases where a class uses different constructors or functions depending on the protocol, such as creating an exercise connection, you need to use #ifdef(s) so that your application compiles using the correct constructors.

2.2.4 Obtaining Further Information about HLA and DIS

The HLA 1.3 and IEEE 1516 specifications are copyrighted by their owners and MAK cannot distribute them to customers. You can get documentation for the RTI 1.3 and 1516 interface specifications at:

http://shop.ieee.org/store/ (IEEE 1516 specifications)
http://www.sisostds.org (SISO DLC HLA API 1516).

You can find general DIS information in the document library at the Simulation Interoperability Standards Organization (SISO) home page: http://www.sisostds.org/ProductsPublications/Standards.aspx

For the IEEE documentation of DIS, you can obtain the publications, IEEE Standard for Distributed Interactive Simulation, Application Protocols and Enumeration and Bit Encoded Values for Use with Protocols for DIS Applications at the IEEE World Wide Web site: http://shop.ieee.org/store/

Reference for Enumerations for Simulation Interoperability (SISO enumerations document) is also available at the SISO site.

Note: The URLs listed in this section were accurate at the time the manual was released. We cannot guarantee that they will be maintained in the future.

[<< VR-Link is a Multi-Layered Toolkit] [Home] [Top of Page] [A Conceptual Overview of VR-Link >>]