Skip to content

Department of Defense Simulation Protocol Standards

mcgredonps edited this page Nov 29, 2017 · 15 revisions

DIS is not the only standard used by contributors to the Department of Defense or defense contractors around the world. Other standards include High Level Architecture (HLA), Test and Training Enabling Architecture (TENA), and WebLVC. They all perform many of the same operations as DIS, and in fact copy some of the ideas of DIS.

Each of these protocols is discussed in their own section.

High Level Architecture

DIS was the first military standard for distributed simulations. Some time later it was believed that it could be improved upon by using different approaches than those of the 80’s, when DIS was begun. This resulted in High Level Architecture (HLA).

There are some important differences between DIS and HLA, but they often share important features as well, particularly when describing combat operations. The HLA architecture can cover a wider range of problems in addition to those addressed by DIS.

Off-Site Tutorials

There are several interesting tutorials about HLA already present. Rather than attempting to supply yet another, the approach in this section is to simply link to the existing HLA tutorials.

Here’s a list of some online HLA tutorials:

Pitch Technologies

Pitch Technologies HLA Tutorial

McGill University

McGill University, Roger MacFarlane

Center for Object Technology

How to become an HLA guru in a short(er) time

Georgia Institute of Technology, Computational Science and Engineering Division, Richard M. Fujimoto

The High Level Architecture: Introduction

HLA and DIS

RPR-FOM

HLA was designed and built to be more general than DIS, but at the same time it was very useful to have HLA configurations that did many of the same things as DIS. Readers of the tutorials above know something about Federation Object Modules (FOMs). The FOMs define the objects and attributes in an HLA federation.

SISO realized that it would be useful to define a FOM similar to that of DIS, and that’s exactly what happened. The Real-time Platform Reference Federation Object Model (RPR-FOM) defines a FOM that copies many DIS concepts. RPR-FOM makes it easier to work with DIS applications.

Consider the location of a simulation entity. In an application RPR-FOM object we can define an object attribute:

<field>
    <name>WorldLocation</name>
    <dataType>WorldLocationStruct</dataType>
    <semantics>-NULL-</semantics>
 </field>

The simulated object includes an attribute defining its location in the world. The format of this attribute is identical to that used by DIS. As we will see, the WorldLocationStruct defined in the RPR-FOM is exactly the same as that used in DIS.

<fixedRecordData>
                <name>WorldLocationStruct</name>
                <encoding>HLAfixedRecord</encoding>
                <semantics>Location of the origin of the entity's coordinate system shall be specified by a set of three coordinates: X, Y, and Z. The shape of the earth shall be specified using DMA TR 8350.2, 1987. The origin of the world coordinate system shall be the centroid of the earth, with the X-axis passing through the prime meridian at the equator, the Y-axis passing through 90 degrees east longitude at the equator, and the Z-axis passing through the north pole. These coordinates shall represent meters from the centroid of the earth.</semantics>
                <field>
                    <name>X</name>
                    <dataType>WorldLocationOffset</dataType>
                    <semantics>-NULL-</semantics>
                </field>
                <field>
                    <name>Y</name>
                    <dataType>WorldLocationOffset</dataType>
                    <semantics>-NULL-</semantics>
                </field>
                <field>
                    <name>Z</name>
                    <dataType>WorldLocationOffset</dataType>
                    <semantics>-NULL-</semantics>
                </field>

The closeness of RPR-FOM to DIS is quite useful for many applicatons.

HLA and Simulation Size

HLA can almost always create simulations that can include more entities than DIS-based applications.

Distributed simulations transmit simulation entity attribute values between hosts. This may include information such as position and orientation, and also describe the entity’s speed and acceleration. As we shall see later in descriptions of DIS’s entity state PDU, DIS will transmit all of these attribute values every few seconds even if they do not change. This increases the network use for every entity in the simulation. A simulated truck parked next to a road will send updates every few seconds for all of the attributes mentioned above, even though they did not change. The increased use of the network, which has a limited capacity, can reduce the number of entities the simulation can support.

In contrast HLA can send updates oof the same attributes to other hosts only when they are changed. A parked truck does not change its position or orientation, and its speed and acceleration remain at zero while parked. HLA can send no updates at all to the other participants in the simulation. This drives down network use by letting HLA applications use less bandwidth. In the end, HLA can suppport more simulated entities because it reduces network use for each simulated entites.

Network Message Formats

HLA took some fundamentally different technical approaches when compared to those of DIS. DIS made the choice to standardize the syntax and semantics of a few dozen messages sent on the network. All programming languages that can read and send binary data messages are capable of decoding and sending DIS messages. This includes C, C++, Java, Javascript, Objective-C, Python, and dozens of others. Sometimes simulation application programmers like to use specific languages for various reasons. Python and Javascript have been interesting and powerful programming languages of late.

HLA took a different approach. Rather than define the format of messages, it uses standardized Application Protocol Interface (API) for a limited set of languages. The list of APIs for HLA is at SISO. Every API is, by definition, specific to a programming language.

The API defines a set of function calls, and the function calls must be language-specific. The primary APIs for HLA are C++ and Java. (There’s also a rarely used API called “Web Services.” Web services refers to a technology that seems not very usable in distributed simulations due to its high latency rates, though it is still supported by SISO. There are today better performing web technologies which will be discussed.)

The full APIs defined are available at SISO. For example, a function in the API for a Java version of the HLA API looks like this:

virtual void discoverObjectInstance (
 ObjectHandle theObject, // supplied C1
 ObjectClassHandle theObjectClass, // supplied C1
 const char * theObjectName) // supplied C4
throw (
 CouldNotDiscover,
 ObjectClassNotKnown,
 FederateInternalError) = 0;

There is also a C++ API function that performs the same operation, but the syntax of that function call in C++ API element is of course compliant with the C++ language.

Developers who want to use other languages, such as Python or Javascript, may run into problems. If in the end a call must be made to the Java or C++ APIs for Python or Javascript to access HLA things are likely to get difficult. In contrast the developer can directly decode the DIS messages in the language he prefers to use.

Another interesting problem is how the HLA API function calls are actually achieved. The API defines the names of function calls and what they do, but do not define how the function works. In the end, messages must be exchanged between hosts, and HLA does not define the message format used to accomplish this. The message format to achieve the result of discoverObjectInstance is determined by the vendor that implements the HLA API.

At the abstract level the function above is a call to search for an object instance. But at the practical level the API is silent about how to accomplish some things. The messages exchanged between hosts may contain data in the big or little endian format, and there may be several messages passed between simulation hosts. Since HLA defines the API, but not the nature of messages necessary to implement the API, in practice every implementation of HLA has different binary messages issued on the network.

The lack of a network standard can make multiple applications working together difficult. Imagine two HLA applications that use exactly the same HLA Federation Object Model (FOM). The simulation’s FOM is a configuration component that defines the simulation’s entities and the entity attributes they have. TankApp uses a vendor of HLA that sells a product called SuperHLA, while the application we want it to workk with, called AircraftApp, uses an HLA implementation product named AwesomeHLA. The two vendors use exactly the same API, but the format of messages they put on the network are different from each other, unknown, and incompatible. SuperHLA cannot receive messages sent by AwesomeHLA, and AwesomeHLA cannot receive messages sent by SuperHLA. Perhaps the programmers for SuperHLA decided to use little endian messages, while AwesomeHLA developers chose to use big endian formats. The HLA implementations have no idea about how they should decode the binary messages of the other HLA implementation.

If the two appliations are to interoperate one option is to use the same HLA implementation, either SuperHLA or AwesomeHLA, in both applications. HLA adopted a strong interoperability standard, and it should be possible to point the application at a different HLA library and run it without error or recompiling. In the case of the TankApp and AircraftApp simulations we should be able to pick one of the HLA implementation libraries, use it in both applications, and start the applications again without recompilation. (In practice there seems to be some reluctance by program managers to do this without a good deal of testing.)

Another option is for each application to share its data in DIS format. In addition to using HLA internally the application may issue a feed to the network about entity movement in DIS format. Perhaps the other application that can then receive the DIS feed and share it into its own HLA implementation. The TankApp uses SuperHLA and also issues DIS traffic; AircraftApp uses software to read the DIS issued by TankApp and feed the information into AwesomeHLA.

The DIS solution becomes more practical as the two applicatons start becoming more differing. For example imagine TankApp has a slightly different FOM than AircraftApp. After that four other applications are added to the interaction pool with the intention of all six applications working with each other. The applications use slightly different FOMs, and three differnet versions of HLA by default. For a situation such as that described above, DIS can be a useful tool. Examples of this include that of Interservice/Industry Training, Simulation and Education Conference I/ITSEC, called Operation Blended Warrior.

Conclusions

HLA provides a number of advances over DIS, but also has some language-based restrictions.

There are several guides to HLA that are better than what I could write. You should read them.

Test and Training Enabling Architecture (TENA)

Test and Training Enabling Architecture (TENA) is another simulation standard. It’s a very interesting and powerful technology.

TENA was developed by the US Department of Defense, and was intended to include test and training systems on the range.

TENA Web Site

The TENA Website is maintained by the United States Office of the Secretary of Defense Test Resource Management Center (TRMC), which runs the TENA program.

TENA License

According to wikipedia,

“The TENA software was developed for use by the United States Government with unlimited rights. The software is provided freely for the purpose of promoting interoperability among United States Department of Defense systems. There are no International Traffic in Arms Regulations (ITAR) or export restrictions in using the TENA middleware and related TENA products at an international site, although any restrictions for user provided object models, software, or documents are the responsibility of the author(s) of those products. Use of the TENA software (source code and binary code) by individuals is permitted only upon acceptance of terms and conditions available at the TENA web site after login.”

Access

TENA requires an account to download the runtime components, but the TENA organization is open to DoD and DoD vendors. Users who register with TENA can download the runtime software for no charge. Some free implementation software is also available for download. It’s strongly suggested that you register at the TENA-sda site.

TENA Tutorial

One of the things that makes TENA fascinating and powerful is its simularity to Common Object Request Broker Architecture (CORBA). CORBA is, among other things, a form of remote objects. Use of remote objects often greatly increases programmer productivity.

An introduction to TENA is available.

An image of the TENA implementation:

TENA

TENA Networking

In addition to the TENA software the DoD supports network implementations at many training and evaluaton sites. This is called Joint Mission Environment Test Capability JMETC. Documents explaining JMETC are available at the TENA web site.

WebLVC

Web-based technology has become highly compelling in the last few years. Readers can confirm this by noting the degree to which the applications they use themselves today are web-based rather than compiled desktop applications. Vendors often make services available via the web rather than compiled, downloaded applications. Web applications often work across multiple operating systems and hosts with little extra work.

SISO runs a WebLVC development group.

As the SISO group mentions, the WebLVC effort includes

• An object-model independent section, which defines the common message headers and object-model-independent administrative messages, and defines a template for the kinds of messages that express object-model-specific data.

• A Standard WebLVC Object Model section, which defines specific AttributeUpdate and Interaction messages (expressed in the JSON format), based on the semantics of the DIS protocol and the Real-time Platform Reference (RPR) FOM. The Standard WebLVC Object Model is designed to allow a-priori interoperability between web applications, and federates that are built on these common, existing simulation standards.

• A section describing the process and rules for hand-authoring new WebLVC messages based on extended or alternative object models.

• A section describing rules for automatically generating WebLVC messages directly from an HLA FOM.

In the end, WebLVC helps define the network messages normally sent by HLA or DIS in JSON terms. This makes network simulation network messages easy to interpret in Javascript.

WebLVC is interesting, but remember that it also possible to send standard DIS messages to Javascript running inside the web page. The open-dis implementation of Javascript DIS can decode the binary PDU and turn it into a Javascript object. WebLVC in some ways resembles HLA messages, however, and can send out only the attributes of objects that have changed. This means that it can often use less bandwidth in a simulation, despite using text for the message format. JSON is also highly optimized; a lot of attention is paid to it.

See jsperf for an interesting comparison in performance between binary messages and JSON. Still, on a laptop running a web browser it is claimed that over 50K messages per second can be decoded. That’s more than can be used in a simulation. Also, note the extend to which different webbrowsers achieve different results.

Clone this wiki locally