-
Notifications
You must be signed in to change notification settings - Fork 32
Department of Defense Simulation Protocol Standards
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. But there are substantial advantages to using the other standards.
There are four major network standards in DoD modeling and simulation: Distributed Interactive Simulation (DIS), High Level Architecture (HLA) and Test and Training Enabling Architecture (TENA), and WebLVC.
Each has evolved to serve different niches in Modeling and Simulation (M&S). While this document focuses on explaining DIS, the reader should also understand the overall role DIS and the other standards play in the DoD M&S world.
Ultimately distributed simulations are exchanging state information, often about entities--vehicles, persons, ships, or aircraft. If a simulation wants to display a tank from another simulation it needs to know something about that tank--its position, which direction it's facing, how fast it's traveling, and other information. The data needs to be sent across the network from one host to any other hosts that may need to know about the tank. The receiving host must know how to decode the message, called the message's syntax and must also know what the meaning of the data in the message is, called the semantics. The syntax may specify that so many bytes into the data sent across the network there are three floating point numbers. If we know the syntax, we can retrieve and decode those numbers. But the semantics of those numbers are a trickier business. Do they describe a position in the world? An entity's orientation? The direction in which a tank's turret is pointing? Participating hosts must know both how to decode messages and what the contents of the message mean.
DIS, TENA, HLA, and WebLVC can be used in roles other than describing the position of entities in the world. DIS can be used to carry voice data, which allows simulated radio traffic can be passed over the network. All three protocols can be used to describe other phenomena, such as electromagnetic emissions, but most classical military training applications are focused on describing the position of things in the world and their interactions.
DIS was the original standard for modeling and simulation. It consists of
- A set of standardized messages for exchanging state information
- Agreements about semantics. This includes what coordinate system to use, units of measurement, and enumerated values that provide a compact way to describe agreed-upon meaning
- Agreements for handling information, the sequence in which messages are exchanged, discovery of simulation entities as they appear, and other procedures
There are dozens of individual DIS messages, called Protocol Data Units (PDUs). Each PDU exactly describes the position and format of data in the message. For example, one PDU, called the Entity State PDU (ESPDU), transmits the position and orientation of an entity, along with other information. The entity's position is 48 bytes from the start of the PDU, and consists of three double precision floating point numbers for the X, Y, and Z values. A simulation that wants to transmit the position of an entity needs to construct the entity state PDU message in exactly the format specified by the standard. This part of the problem relates to the message's syntax.
The host that receives the message can decode the Entity State PDU (ESPDU) according to the agreed-upon syntax and get three double precision floating point numbers, but if the message is to be made use of both the sender and receiver should understand the coordinate system and the same units of measurement used in the message. Are the three floating point numbers a latitude, longitude, and altitude? Are the latitude and longitude in decimal degrees or decimal radians? Or are the floating point numbers Military Grid Reference System (MGRS) coordinates and an altitude? Is the altitude in meters or feet? Is the altitude measured from sea level or ground level? Agreements about the semantics of the three floating point numbers are specified by the DIS standard, but not in the contents message being transmitted. It is assumed that the floating point numbers in the message are using the coordinate systems and units specified by the standard.
Not all message exchanges consist of simple and atomic state updates. Simulating a shooting event in DIS can require that multiple messages be transmitted with the shooter, target, and the munition being fired. The sequence in which the messages must be exchanged is also specified by the DIS standard.
Many simulations using DIS only partially implement the full DIS standard. If a simulation makes no use of electromagnetic warfare PDUs then the implementation of DIS used in that application may well not implement them. This means that they will be deaf to any of the PDUs with information about electromagnetic operations that were sent by other simulation participants--if the application receives a PDU that describes an electromagnetic happening it may simply ignore the PDU.
What DIS standardizes is straightforward: the format of PDUs, the semantics of their contents, and how they are exchanged. This is a popular way to standardize network traffic and was used in the 80's and 90's for the many Internet Engineering Task Force (IETF) Requests for Comment (RFCs) that form the backbone of the internet today. The Domain Name Service (DNS) protocol, the HTTP protocol, and the TCP protocol are defined in similar ways. As we'll see, HLA and TENA made different choices about how to standardize their protocols.
DIS has been through several revisions. The proto-DIS version was SIMNET, a DARPA research project from prior to the standardization of DIS. In 1995 the SIMNET protocol was updated and standardized with a major standards group, IEEE, as DIS version 5. The standards approval process is painstaking and painful. The desired outcome is for two or more different programmers to read the standard and write completely interoperable implementations despite not communicating with each other. This is a tall order--getting all the syntax and semantics agreed upon is difficult, and requires very specific and detailed descriptions in the standards document.
In 1998 the DIS standard was updated in a forward-compatible way to version 6. The 1998 standard added a few new PDUs and clarified some semantics, so that DIS version 5 traffic can mostly be handled by DIS version 6 implementations. The reverse is not necessarily true--if a DIS 6 application sends messages to a DIS version 5 application then it is possible to send messages that will not be recognized. DIS version 6 is probably the most widely used version of the DIS protocol.
In 2012 version 7 of DIS was approved. The standard's descriptive text was expanded to clarify the semantic meaning of messages, and a few new PDUs were added, primarily related to directed energy weapons. Version 7 of DIS is again mostly backward-compatible with earlier versions.
DIS can be broadly classified into generations. Generation 1, from before DIS was standardized, can be thought of as SIMNET messages. Generation 2 covers the IEEE-standardized DIS versions 5, 6, and 7. Generation 2 is not compatible with the syntax and semantics of generation 1. Work on DIS continues. DIS version 8 is being mooted as this is written. It may well choose to break backwards binary compatibility in order to take advantage of new features, in which case it could be described as generation 3.
Generation 1 applications are almost entirely dead and gone. (Though you never know about these things. Some bozo has doubtless backed up an application from 1991 on his 5-1/4" floppy disk, and will start sending PDUs on your network without your knowledge.) Generation 2 applications predominate, mostly DIS version 6.
While generation 3 applications (the mooted DIS version 8 and beyond) may not be binary-compatible, any realistic implementation will be able to operate with the aid of gateways or bridges that act as translators. The gateway would receive a DIS version 6 PDU and translate it to DIS version 8 format.
It's not at all unusual to see incomplete DIS implementations. Many DIS applications use positions, others use voice applications, and a few use a use a Directed Energy (DE) PDU. Some DIS applications may use the skill of the programmer for a few applications. On the other hand, DIS doesn't demand a certain style of code, nor care about the type of applications code. It can be C++, Java, C-Sharp, and more.
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).
The features that DIS and HLA standardize are different. While DIS specifies the format and semantics of data on the wire, HLA is an API standard. HLA specifies a set of function calls that simulations can use in conjunction with the developer-defined FOM to exchange messages. An HLA simulation must also comply with a set "HLA rules" that all HLA applications must follow.
If two HLA simulation participants ("federates") are to exchange data they must share a FOM (or if you want to be picky some subset of the FOM.) Without this the simulation participants don't have agreed-upon semantics about the data being exchanged.
There has been work done to standardize FOMs, most notably in the Real-Time Reference Platform FOM (RPR-FOM). When HLA was first introduced there was already a large installed base of DIS simulations. To make the planned transition to HLA easier, RPR-FOM replicated many of the semantics and even syntax of DIS. The same coordinate system was used, and the same semantics for identifying entities, the same dead reckoning algorithms, and more. DIS had already worked out solutions to the major problems encountered in distributed virtual environments, and re-inventing the wheel did not make sense. If an existing application using DIS was to be ported to the HLA standard to exchange data instead, it made sense to use many of the same DIS concepts in RPR-FOM. The HLA RPR-FOM standard reused concepts that had already been painfully discovered by DIS, and this made a transition to HLA by existing applications easier. Because of this a firm understanding of DIS semantics will go far in helping you work with HLA RPR-FOM applications.
The application programming interface that programmers use to interact with HLA is called the RTI (Run-Time Infrastructure). Simulation authors can choose to buy an RTI implementation to use for their application, or use a free and open source RTI. The Modeling and Simulation Coordination Office (MSCO) maintains a suite of tests that can be applied to RTIs that can flag any noncompliance, so some RTIs are certified compliant.
While HLA standardizes the API, the standard is silent about the format of messages exchanged between host RTIs on the network. An RTI implementer can choose to use any format he likes. This means that two simulations, both using HLA, and both using RPR-FOM, but using RTIs from different vendors cannot directly communicate with each other. They are using different network message formats that contain the same information, ultimately, but are in completely different formats. There is no attempt to standardize the syntax of HLA messages on the wire. The thinking is that because HLA has a standard API HLA this makes it easy to switch between RTI vendors, so a standard wire format was less important. This also allows RTI vendors to innovate under the API with a number of technologies and formats, and compete with each others on a basis of performance.
The HLA standard has gone through a number of revisions over the years. The first published standard, from the Defense Modeling and Simulation Office, was made available in 1998 as HLA 1.3. Subsequent versions were promulgated through SISO and, eventually, IEEE. The first IEEE-promulgated standard was IEEE-1516. HLA was adopted by NATO as STANAG-4603. HLA was further updated in 2010 in an updated IEEE standard, IEEE-1516-2010. As of this writing this is the latest version.
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 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.
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.
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 is a solid HLA tutorial. There's a small HLA training software that's free, and runs C++ and Java. It makes it a very good thing to learns HLA from
McGill University, Roger MacFarlane is a PDF about HLA is set up.
Georgia Institute of Technology, Computational Science and Engineering Division, Richard M. Fujimoto
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) 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.
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.
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.”
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.
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 was developed to serve the needs of the live range community. DIS uses a fixed set of messages to exchange state information, and HLA uses an API, while TENA adopted a remote objects architecture. While DIS and HLA can exchange state information, TENA adds the ability to reuse code.
Users of Common Object Request Broker Architecture (CORBA) will be immediately at home in TENA. The basic concept is that developers write classic language objects, such as those seen in C++ or Java. These objects can be published by applications and accessed remotely via proxies, or stand-ins for the actual object.
Suppose we have an object representing a tank in one participating simulation. That simulation publishes the tank object instance. Other simulation participants can call methods in that object instance, called a servant, via a proxy on their own host. The proxy has the same interface as the servant--the set of publicly accessible methods--as the object on the original simulation. When a local application calls a method in the proxy, perhaps including some arguments with the method call, the proxy does no actual computation itself. Instead it packages up the method call, including any arguments, and sends it across the network to the host with the servant. That host runs the code in the servant object's method, then returns the result to the calling proxy.
From the standpoint of the caller, it looks as if the user is directly calling a method on an object residing on another host.
HLA and DIS pass state information between cooperating hosts. TENA does this as well, for example by using method arguments in a method call, or by causing object state information to be automatically published to interested participants. It provides the ability to run code associated with an object on a remote host as well. Most coders are familiar with the paradigm of calling methods on objects, and TENA (and CORBA) make that work in what seems to the programmer a familiar and straightforward way.
TENA also provides a repository of reusable TENA objects at its web site.
TENA has not been approved by a standards organization, and the current implementation is not open source. TENA is organized by the United States Office of the Secretary of Defense Test Resource Management Center (TRMC) and a steering committee controls features added to TENA and the development of TENA. The TENA Middleware, which implements the basic plumbing of TENA, is freely available for download from the TENA-sda.org site with a login. Software that is free though not necessarily standardized or open source software is important to the range community. It was felt that licenses and the problems inherent with keeping them current did not work well with the very long and often convoluted product life cycles seen in the DoD range environment. TENA sidestepped the license problem by simply giving away the software.
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 web browsers achieve different results.
There isn't a single simulation standard; there are several, including DIS, HLA, TENA, and WebLVC. It's a challenge to make them work together. They have different strengths, but it's not impossible.