-
Notifications
You must be signed in to change notification settings - Fork 32
Home
Welcome to the DIS Tutorial wiki! This wiki is a collaborative effort to create and maintain a Missing Manual-style tutorial for Distributed Interactive Simulation, a defined infrastructure for linking different and disparate simulations for use in training, evaluation, and analysis.
Running simulation for military training is sometimes called remarkable. It is.
Imagine the following training scenario:
A battalion is at a coastal training area and is in the midst of operating. You run the training area's simulation management office. Your office's displays show friendly, hostile, and neutral vehicles on electronic maps or in 3D displays. Physical sensors are installed on the vehicles and used as a source for their correct position, orientation, and speed. The weapon data is passed to us by a network or radio device installed on the vehicles; that allows us to assess a "hit" or "miss" from a missile or cannon on the shooting vehicle. If a vehicle has been rated as destroyed by our software that replicates the operations of a direct fire cannon, our display shows the target vehicle burning. At the same time at the physical location of the vehicle an alarm light flashes and siren sounds on the target are started. Sometimes observers in the field will rate vehicles as destroyed from indirect artillery fire because the outcome of artillery combat fire can be inherently random, the observers from the training area assess the likely results themselves, and we use their assessments to feed our displays. The battalion command are shown helicopter assets, and the helicopters told of some simulated hostile anti-aircraft batteries. Simulated air strikes delivered by real Air Force flights are included in the training session. The simulation office uses "constructive models" to portray assets outside of the training area. The models are completely simulated, with no links to physical devices, and the simulated, constructive assets cause the battalion command to maneuver as if the distant friendly and hostile units really existed. There may exist long range artillery or rocket sites that belong to the battalion or those of their enemy. Actual commercial ships sailing by between third party nations are shown just off the coast; they are real commercial, peaceful nation ships passing by in the shipping lanes in real time. There are commercial flight paths 15,000 feet above the training session area that your simulation sees. There are several simulators generating multiple types of traffic--logistics, medical treatment, and more. Command, control, communications, computers, and intelligence (C4I) messages may be sent to the (simulated) brigade, of the battalion, and messages from the brigade sent to us.
On top of this, after the training event has ended we can display the logged position and speed of vehicles during the simulation. The unit being trained can be shown what exactly happened instead of only what they thought happened in chaos. Human memory is often imperfect, while data collected and logged regarding vehicles were exact and repeatable. It can be both exact and surprising.
There may be dozens of applications participating in this simulation. The position of commercial ships is reported using what is called Automatic Identification System, which can send out the name, position, and speed of live commercial ships every few seconds or every few minutes. Not all software agrees on what vehicles are what type; there are thousands of items that may be referred to including domestic and international weapons, vehicles, and aircraft. Many applications may use 2D or 3D, and often use different maps to place the items.
This seems complex because it can be complex. If you're running a large simulation training site there's a lot to understand and integrate. But at the same time, sometimes what is being done from the standpoint of a developer is a single organization writing a single application. Or perhaps what a group needs to do is play back log information. The single application writers or the logger playback developers are doing less complex information processing than what the simulation manager is up to, but at the same time we'd like to use an information format that makes it easier for our undertaking to extract.
Ultimately we want to exchange information between simulation elements. The major problem that we must solve is exchanging that information in understandable formats or methods.
Many sources exchange data. In the end, we usually want to integrate every bit of information we can move into the simulations. The tanks need to send their location and speed, we have to receive updates from officers doing exercise assessments, and real commercial flights can also provide exercise input data. We want to pass data between simulations, but each source often has a different set of data--commercial ships have different data than commercial aircraft. Also, what will be the format of messages exchanged? Every participant must know how to convert data to the correct format when leaving and decode from the expected format when receiving.
What we are trying to accomplish--agreeing to exchange information, decode its format, and the meaning (semantics) of the data--is challenging. The simplest possible way, including the position and orientation of entities in one application, written by a single team for one application written at a single point in time can be difficult. The reality is the applications cooperating in the exercise described above were often written by multiple teams years apart from each other, and may have never talked to each other. But we still want the applications to be able to communicate.
What is going on here? Imagine a single type of application running only about tanks. It's one application written by the same software development team, and this keeps the application as simple as possible. To know the position of the tanks we must send out data from the tanks, including where they are, which way they are pointing, and how fast they are traveling. The graphics section knows only how to draw tanks and terrain.
Now consider the commercial ships traveling nearby. Management has decided that the tank simulation should also see the real position of commercial ships passing the bay. The ships are not tanks, but they are sending out data that is similar in some ways, such as speed and orientation. The tank simulation needs to be changed so it can display commercial ships, and ship trainers will display cannon blast from tanks ashore.
The network messages using AIS and those using a traditional DoD simulation protocol are not in the same format. But we can translate between the messages, and that's what is largely done. In practice DoD networks often use the protocol Distributed Information Simulation (DIS) to describe the location of entities that we simulated ourselves, but also translate other messages to DIS as well. Our tank simulation accepted DIS messages, but also from AIS network traffic translated to DIS. Our simulation applications do not understand AIS, but we can change from the ship's AIS protocol format to something we do understand.
The same is true of dozens of other simulation applications we make use of at the simulation site. Many of the other simulation applications may be sending information that is very close to what the tank simulation chose, or not very close at all.
Distributed Interactive Simulation is a software standard used to help implement military simulation applications. The simulations that use DIS have hosts that have been connected to a network, and the DIS protocol helps exchange information about the combat units in the simulation. This includes what types of vehicles are used, how they interact, or how they are used in combat operations. DIS is used in many United States Department of Defense (DoD) applications, and has been for decades. DIS can be used in single applications that require no interaction with other applications, or DIS can be used to help other applications cooperate with each other.
The software standard DIS involves definitions for dozens of network messages that are exchanged between hosts, not just position information. The syntax and semantics of the messages, which are called Protocol Data Units (PDUs) in DIS, are carefully defined. The PDUs can be exchanged between CPUs of multiple designs, running many types of operating systems, and these operations can be done in multiple software languages. This helps make DIS flexible and effective.
To achieve its simulation operation objectives the DIS standard includes more than just message format issues. The syntax of messages is defined, but DIS also includes more information. Individual messages also include positions expressed in a particular global coordinate system, for example, and there are many other DIS rules that solve problems, such as detecting the presence of networked entities, or performing combat operations. The logical operations necessary to complete these operations becomes tricky and non-obvious. DIS simulation users must learn how to make use of the DIS operations, and this can become difficult unless the user knows something about the semantics of DIS how to use them. The IEEE-1278 series is the documentation providing the Institute of Electrical and Electronics Engineers' (IEEE) DIS Standards. However in any standard the primary emphasis is placed on achieving unambiguous and accurate definitions of the data being passed rather than helpful descriptions of how to make use of the defined features.
That is part of what this wiki site is intended to achieve: describe and teach the effective implementation of the features that DIS can implement. The DIS standard is useful, widely used, and at the same time those using it can find it difficult to implement real application features due to the complex nature involved. It's helpful to have clear explanations.
That's only part of it. DIS is flexible, and can be used in a range of applications. Simply listening to and saving the messages sent on the network from a live exercise can be very useful to analysts. They can later use the saved DIS messages to examine what real vehicles or people actually did and use the collected data to help evaluate the effectiveness of combat tactics, without using any 3D feedback at all.
The problem space of DIS is common in many ways to those that also appear in the commercial game entertainment world. It is very unusual for commercial entertainment games to use DIS, but the technological implementation problems faced by games are often similar to those faced by DIS. If you're a commercial game programmer, some of the issues discussed here can help your commercial implementations. However commercial applications can be involved in different problem domains. A game need not have a game area associated with actual real estate and the curvature of the earth, for example. Games often use the same technology with similar but different aims. Games are intended to supply entertainment, while simulations are intended to train users to accomplish specific and real training tasks. But much of the technology is similar.
There are other features of DIS that will be addressed in this document as well. From an practical or even academic standpoint the number of questions asked and answered through DIS can be enormous. It's helpful to have specialists cooperate on this DIS Tutorial project. The tutorial project's structure is, one hopes, helpful in allowing experts on a topic to supply their answers in this document while not causing issues with other sections of the tutorial. The writing is done in the Wiki format. Specialists can check out the wiki as a git repository using git clone https://github.com/open-dis/DISTutorial.wiki.git and submit their own additions.
Often the people who need to learn something about DIS are programmers who are thrown head-first into the problem. They're given some vague instructions, usually summed up as "Hey, we need to implement DIS in our application. Go make it work." Sometimes the programmers don't have prior experience with distributed simulations or virtual worlds. They often work on the project for a few weeks before moving on to something else, so they need to learn about the subject quickly. They're OK with coding, and often with network programming, but using DIS often involves a problem domain that is not clear to newcomers. For example, one would think that it is easy to direct an object in a virtual world to move one meter northwest. This is trickier than it may seem at first glance. What coordinate system is being used, and is that using metric or imperial units? How does one uniquely select an object so that it and it alone moves? Learning about each of these tasks can take a programmer days to unravel if he must rely on only the IEEE standard.
Another audience for this document is military or support personnel responsible for making existing DIS simulations work, or to DIS to let other applications exchange data. The managers usually have good understanding of the military problem domain and perhaps the basics of networking and software installation. While they are subject matter experts on the military actions in the simulation they may not be familiar with the nuts and bolts of how the simulation protocol works. An understanding of how things are done in DIS is often a great help in getting a full simulation working, or understanding the limitations and features that are difficult or impossible to implement in a simulation.
Those using simulations that instead of DIS use other DoD simulation protocols called High Level Architecture (HLA), Test and Training Enabling Architecture (TENA) or Web Live, Virtual, and Constructive (WebLVC) can also benefit from this manual. The HLA Real-time Platform Reference Federation Object Model (RPR-FOM) uses many of the concepts of DIS, and so can TENA. Sometimes HLA RPR-FOM simulations and DIS simulations communicate with each other via a protocol gateway, and the use of the gateway can be helped by users who appreciate the shared concepts between the protocols. Understanding DIS also helps HLA RPR-FOM and TENA users.
Studying the standard in isolation can be confusing if the reader has no familiarity with the problems inherent to distributed simulations. The IEEE-1278.1 standards document does not usually explain the "why" it choose to solve the problems it did, or even that the problems it solves are in fact problems. This document includes an overview of distributed simulations and the inherent issues faced when implementing them. In order to explain the issues, background information on distributed simulations and virtual worlds is presented. If you already know all this, you can safely skip it. But for most programmers and administrators it provides the context for features or data in DIS that may seem mysterious at first.
DIS consists of a few dozen types of network messages exchanged between simulations. Understanding the syntax of these messages and how to create and receive them is an easy part of DIS. A deeper understanding of what the semantic content of the messages are, and what problems they are trying to solve, is more difficult and more valuable.
If you just want to sling some code and skip all the throat-clearing and theory, you can start reading the "Protocol Data Units: Exchanging State Information" section.
DIS standardizes the format of network messages but has no formal programming API. If a programmer wants to create what is known as an "Entity State Protocol Data Unit", a network message that defines the location and orientation of an object in a simulation, the implementation of DIS is free to choose function calls of either
espdu.setLocation(newLocation);or
espdu.SetLoc(anotherLocation);Those who implement the DIS standard can use any API they choose. The code in this document primarily uses the open-dis implementation, which is available here. There are implementations for several languages, including Java, Javascript, C++, C#, Objective-C, and Python. There are other implementations of DIS, both open source and commercial. There are also many home-grown implementations of the standard that were created by simulation implementors. They just wrote their own DIS implementation, or the portions of the DIS standard they needed. This means that the code-writers out there are likely see differences in the source code of two applications that do the same thing. But if they understand DIS, the objective of this document, they should be able to overcome the implementation issues.
There are other features of DIS that will be assessed as well. From an practical or even academic standpoint the number of questions raised through DIS can be enormous. It's therefore helpful to have specialists cooperate on this DIS Tutorial project. The tutorial project's structure is, one hopes, helpful in allowing experts on a topic to supply their answers while not causing issues with other sections of the tutorial.
The graphics portion of a shared virtual world can be a subject unto itself because of the inherent complex nature of the the problem. The art that portrays the shared environment may also vary depending on the training objectives. In the commercial world, imagine the graphics of "Call of Duty" or other first person shooter entertainment games. Users who buy the games like good-looking and fast game graphics. In the DoD world, sometimes the training objectives also require high quality and quick graphics operations. Some flight simulators that replicate ground attack operations can also have such a need. Some applications based in the DoD can instead use 2D maps to portray a shared environment. The objective of the simulation in map displys is to provide users with information about where vehicles and units are, rather than individual vehicle appearance. A map-based graphics simulator may also require position updates once every few seconds rather than several times per second.
The choices about what graphics to include in a DIS application depend entirely on the training objectives. An implementor may be able to use Google Maps or Open Street Maps to portray vehicle positions. The map graphics in the display are not realistic 3D displays of vehicles, but may achieve the training objectives. Alternatively some applications can use 3D graphics in a manner reminiscent of modern commercial games. There are many ways to draw the 3D images we see on the screen, from OpenGL and Direct3D to higher level scene graphs, such as OpenInventor or X3D. At an even higher level of abstraction objects can be rendered with the aid of a 3D game engine such as Lumberyard or Unity. A DIS application may have rudimentary 3D graphics instead of photorealistic 3D graphics, depending on the training use. Again, the audience being trained may benefit from high quality graphics, or still be well trained by a graphics system that is simple but effective in accomplishing the training objective.
Computer graphics is a large and complex subject, and instruction or examples is DIS teaching often depend on the graphics standard chosen to describe the environment. We will discuss some graphics implementations for both for 2D maps and 3D applications. In some understandings, graphics use in simulations can be distinguished as being separate from DIS networking. The reality is that graphics are often used in simulations that use DIS, and from a practical standpoint a DIS tutorial has to at least mention how to use it.
Before the distributed simulation application can be implemented there needed to be a way to exchange _state_ _information_ between simulators. State information includes data about a participant in the simulation that is transmitted to other simulation hosts. In the case of a tank, the state information includes its position, the direction the vehicle is facing, how fast it is moving, whether it is on fire, and subjects such as which way the turret is pointing. It's this state information and the format that it is exchanged in that DIS standardizes. Once the state information is exchanged the graphics components we just described above can be used to draw the scene that the users see.
It is in the government's interest to have simulators interoperate with each other, in particular to prevent vendor lock-in. If the protocol for exchanging state information is owned by a company and that company can prevent simulator competitors from entering the market. A company (or military service!) that wanted to use the protocol to talk to their simulation would likely have to buy a copy, likely without source code and a limited number of operating environments. To be useful the DIS protocol had to be a *standard*, and an open one. Simply providing a language implementation that did the job without also specifying what was being exchanged was inadequate. So SISO refined the SIMNET network protocol and developed a formal description of it, then took it to the IEEE. IEEE approved it as an international standard (IEEE-1278.1). From that point on anyone could buy the IEEE standard document for a reasonable sum and then write their own implementation of the protocol. Or they could use an open, free implementation of DIS implemented by others.
As is inevitable with these things, the standard has to be maintained and updated in light of experience and new technology. From the late 80's until about 1995 the DARPA SIMNET protocol was used; this predated the adoption of DIS as an IEEE standard. The first major release of a standard DIS was DIS version 5, in 1995. It was updated with version 6, in 1998, when a few new network messages were added. Version 7 was adopted in 2012, and that version maintained an almost complete backwards compatibility to the DIS version 5 of 1995. At the same time it added a few new PDUs (network messages) related to directed energy weapons and also clarified the semantics of protocol. SISO continues to support and update DIS in working groups, today in parallel with the HLA RPR-FOM.
Sending the messages defined by DIS involves using, almost always, the TCP/IP networking system. That's simply because TCP/IP has become so widespread. Once upon a time there were other software networking standards, such as DECnet, IBM Systems Network Architecture (SNA), Open Systems Interconnection (OSI), or AppleTalk. Those high level network protocols are simply not in use to much of an extent these days. In the case of DIS, can be exceptions to the use of TCP/IP in radio alert applications, but this is somewhat rare.
Using TCP/IP to send DIS messages is useful. It is simple enough to use TCP, UDP, broadcast, and multicast. For the most part in this document the objective is to be as simple as possible when discussing the subject. Network programming is intended to stay at the highest levels possible, excluding, to the extent possible, such topics as the IP or lower levels.
Given the technology of the era, the architects of DIS were visionary. Even decades after it was developed and standardized it still holds up quite well. The research it prompted was trailblazing, and served as the starting point for many military simulations and then entertainment industry game applications. The ideas worked out in DIS are still widely used today.
Simulation Interoperability Standards Organization (SISO)
The IEEE DIS Standard, 1998 (Version 6)
DIS Wikipedia
DIS Plain and Simple, another document that provides information about DIS
SIMNET Wikipedia
SIMNET History (pdf)
Still More SIMNET History
A whole website devoted to SIMNET history
Networked Graphics: Building Networked Games and Virtual Environments, Steed and Oliveira
Networked Virtual Environments: Design and Implementation, Singhal and Zyda (out of print)