1. Katherine L. Morse, PhD JHU/APL 5 November 2015
Live-Virtual-Constructive (LVC) Technologies – Distributed Interactive Simulation
Katherine L. Morse, PhD
JHU/APL
5 November 2015
This LVC technologies class is on the Distributed Interactive Simulation (DIS) protocol. It is an IEEE standard, the 1278 family.

2. Distributed Interactive Simulation (DIS) Protocol Purpose
Real time
“Soft” real time, i.e. events occur in the simulation when messages are delivered by the network
Not discrete event or time managed, i.e. simulated time advances at the same rate as actual time (wall clock time)
Entity level
Platforms, e.g. aircraft, ground vehicle
Individuals, e.g. dismounted infantry
Standardized
IEEE 1278 family maintained by the Simulation Interoperability Standards Organization (SISO)
Simulation interoperability protocol
The format and allowable content of messages is defined in Protocol Data Units (PDUs) that are delivered via best effort User Datagram Protocol (UDP)
With best effort, there are no guarantees that data is delivered or that a user is given a guaranteed quality of service level or a certain priority.
Analogous to transmitting a radio message in the blind; the message was sent, but there is no guarantee that anyone received it.
DIS originated from the DARPA SIMNET program that integrated virtual platform simulators for training. The protocols evolved to become the DIS family of standards. Because its original application was virtual training, the protocol focuses on real-time, entity-level applications.
The SISO Standards Activity Committee is the IEEE’s standards sponsor committee for simulation interoperability standards. This means that SISO maintains the standard although the copyright is held by the IEEE.
User Datagram Protocol (UDP) is a connectionless, best effort, "unreliable" protocol.
One of the key questions asked when developing an LVC environment is whether to use the High Level Architecture (HLA) or DIS. Some general guidance for this question:
If the development is new, consider HLA first because it offers many more features for controlling simulation execution and data filtering.
If the project is integrating with an existing LVC environment using HLA, give preference to also using HLA because this choice will maximize interoperability with the other simulations using HLA in the existing LVC environment.
If the project is integrating with an existing LVC environment using DIS exclusively, then choose DIS because the additional HLA features will go unused and integration will require the additional development or integration of a gateway.
For more detailed guidance, see the Distributed Simulation Engineering and Execution Process (DSEEP), activity Design Simulation Environment, which states, “A fundamental design choice for any distributed simulation environment is the underlying simulation architecture (e.g., HLA, DIS,..” The DSEEP Multi-Architecture Overlay provides amplifying guidance on performing this task for multi-architecture LVC environments.

3. Example DIS Architecture
Loggers
Non-DIS Simulation
Cockpit Simulator
ISR Simulation
Red Air CGF
Application-Specific LAN
Gateway
Filter Application
Exercise Air LAN
Exercise Ground LAN
Blue Ground CGF
Because there is no centralized management in DIS, a DIS-based simulation environment might be as simple as a local area network (LAN) connecting two simulations such as the two computer generated forces (CGFs) shown on this slide.<Next>It may also be very complex as shown here including connecting to other LANs, possibly through a gateway that translates the DIS protocol to another simulation protocol or architecture, or through a filter that reduces network traffic unnecessary to the other LAN. Some of the simulation components illustrated on this slide are explained on slide 19.
Red Ground CGF

4. DIS Design Principles Entity encapsulation in simulations
Autonomous simulation nodes
Transmission of “ground truth” information
Transmission of state change information
Use of “dead reckoning” algorithms to extrapolate entity states
The responsibility to model individual entities is encapsulated in individual simulations, not across multiple simulations. Nodes on which simulations run operate autonomously without external management. These simulation nodes are responsible for transmitting the actual state of their simulated entities to the rest of the simulation environment; receiving simulations are responsible for degrading that state based on effects such as sensor limitations. Simulation nodes are responsible for transmitting updated information when the state of the entities they model changes. DIS uses dead reckoning algorithms to reduce the frequency of sending these entity state updates.
Thanks to Margaret Loper of Georgia Tech Research Institute for her original perspective on these principles.

5. Entity Encapsulation in Simulations
Entities (platforms and individuals) are represented within simulations.
Simulations interact with each other through a series of events, which produce effects on entities and perhaps cause other events.
Fixed terrain and infrastructure features, e.g. buildings and roads, are known by all simulations.
They are usually pre-loaded or distributed at exercise initialization.
Information about non-changing features is assumed and is not transmitted.
Simulations keep each other informed of the locations and status of dynamic entities.
Entities (platforms and individuals) are represented within simulations.
Simulations interact with each other through a series of events, which produce effects on entities and perhaps cause other events.
Fixed terrain and infrastructure features, e.g. buildings and roads, are known by all simulations.
They are usually pre-loaded or distributed at exercise initialization.
Information about non-changing features is assumed and is not transmitted.
Simulations keep each other informed of the locations and status of dynamic entities.

6. Autonomous Simulations
All events are broadcast across the network so they are available to all interested entities.
Initiating simulations do not need to calculate what other simulations may be interested in, or whose entities may be affected by, an event.
Each receiving simulation is responsible for calculating the effects of an event on the entities it is simulating.
Effects may include the generation of new events.
Simulations can join or leave an exercise in progress.
Late joining simulations learn the state of the simulated world by receiving PDUs from other simulations.
Heartbeats, periodic entity state PDUs, inform other simulations that a simulation is still modeling entities.
If the sending simulation drops out, the loss of these heartbeats serves as a signal to other simulations.
On the last slide, I briefly discussed the autonomous nature of DIS simulations. That is, that DIS simulations are not directly connected to each other and don’t expressly communicate to each other. Rather, they broadcast all events. Analogously, they also receive all events broadcast. All the simulations in a DIS simulation environment are responsible for determining whether the PDUs they receive are of interest to them and responding accordingly. Simulations can join or leave an exercise that is already in progress, learning the state of the simulated world through the arrival of PDUs.

7. Transmission of “Ground Truth”
Each simulation transmits the absolute truth about the state of the entity(s) it represents.
Receiving simulations are responsible for determining whether their entities can perceive an event and whether they are affected by it.
Receiving simulations degrade information prior to presenting it to human crew members or automated crews in accordance with an appropriate model of sensor characteristics.
DIS has a design pattern dictating that simulations only transmit the ground truth, i.e. the absolute truth about the state of the entities they represent. It is the responsibility of receiving simulations to determine if that information should be degraded, for example, to simulate the “fog of war.”

8. Transmission of State Change
To minimize communications processing, simulations transmit only changes in the behavior of the entities they represent.
This approach minimizes the transmission (and processing) of redundant information.
If an entity continues to do the same thing (e.g., straight and level flight at a constant velocity), the update rate drops to a predetermined minimum level.
Because network bandwidth is a scarce resource, simulations transmit only changes in the behavior of the entities they represent. This also reduces the need for receiving simulations to process these PDUs only to discover that no information has changed. There are also mechanisms in DIS for reducing the rate at which updates are sent if an entity’s behavior continues in a constant manner. This is related to dead reckoning which will be discussed on the next slide.

9. Dead Reckoning
Each simulation maintains a simplified representation of the state of nearby entities, and extrapolates their last reported states until the next state update information arrives.
Simulations representing each entity are responsible for transmitting new state information before the discrepancy between its “ground truth” information and the extrapolated approximations being generated by the other simulations becomes too large.
Each simulation maintains a dead reckoning model of its own entities that corresponds to the model(s) being used by all other simulations, and it continuously compares its “ground truth” information with the approximations being used by the other simulations.
When a state update is transmitted, it includes externally “visible” information that can be used to initiate a new extrapolation:
Position, velocity, orientation
Turret azimuth (if any), gun elevation, etc.
Dust clouds, smoke column, muzzle flash, etc.
Thermal, electromagnetic emissions and countermeasures
Dead reckoning is one of the most complex features of DIS. However, it is important for reducing extraneous PDUs, so understanding it is critical to a basic knowledge of DIS. The central concept is that each simulation maintains simplified representation of the state of nearby entities, extrapolating their status until the next state update arrives based on well-defined algorithms. There are several different dead reckoning algorithms in the DIS standard. The next slide provides a step-by-step description of dead reckoning.

10. How Dead Reckoning Works
Simulation A’s understanding of position of vehicle modeled by simulation B
Vehicle’s position as actually modeled by simulation B
= True/DR Coincide
= True Position
= DR Position
Initial
state /
ground
truth
Constant
course &
speed
True & DR
diverge,
threshold not
exceeded
Threshold exceeded, B sends entity state PDU update
B corrects local position of vehicle based on entity state PDU and starts new DR
Simulations A and B use the same dead reckoning (DR) algorithm so B knows when the actual position of its vehicle has exceeded the DR threshold. 1 2 3 4 5
At the first time point, simulation A broadcasts its initial, ground truth position, so A and B agree about the position of A’s vehicle.
A’s vehicle continues on its previous course and speed. B projects the vehicle position using the agreed upon dead reckoning algorithm. A also dead reckons the vehicle’s position. Because of the constant course and speed, the ground truth position and dead reckoned position remain the same.
The vehicle’s course or speed change slightly. Because the difference between A’s ground truth position and dead reckoned position for the vehicle doesn’t exceed the algorithm’s threshold, A does NOT send out an entity state PDU about the vehicle.
The vehicle’s course or speed change to the point that the difference between A’s ground truth position and dead reckoned position for the vehicle DO exceed the algorithm’s threshold. A sends out an entity state PDU about the vehicle’s ground truth position.
B corrects its understanding of the vehicle’s position and begins dead reckoning from this position.
As the ground truth position begins to diverge from the dead reckoned position (between steps 2 and 5), there is a risk that a munitions fire from B targeting A’s vehicle will miss because B’s projection of the vehicle’s position is inaccurate.

11. Simple DIS Interaction Example
Send Fire PDU
Compute trajectory
Send Detonation PDU
Compute damage
Send Entity State PDU reflecting damage 1 2 3 4 5
This slide illustrates a simple DIS interaction example.
The simulation modeling the LAV-25 models the fact that it fires a M792 at the BTR-82 by sending a Fire PDU.
Although the BTR-82 is the target, the Fire PDU is broadcast to the entire simulation environment.
The BTR-82 simulation receives the Fire PDU and determines that it has been hit.
In response, the BTR-82 simulation broadcasts a Detonation PDU so other simulations can represent the event, possibly for visualization.
The BTR-82 simulation then calculates the damage inflicted by the M792 and broadcasts an Entity State PDU reflecting its damaged state.
BTR-82 image acquired from
M792 image acquired from

12. DIS PDUs (1 of 3) PDU Family Description # of PDUs
Entity Information/Interaction
Information associated with the appearance and location of an entity 5
Warfare
Information related to weapons, expendables, and to any type of explosion whether or not it is related to munitions 4
Logistics
Information associated with the representation of logistics support 6
Simulation Management
Simulation management and control, e.g. start / resume, data query 12
Distributed Emission Regeneration
Information related to active electromagnetic emissions, including radar and radar-related electronic warfare, e.g. jamming
Radio and Intercom Communications
Information associated with the simulation of both audio and data transmission by radio and Tactical Data Links (TDLs)
The DIS standard organizes the PDUs into 13 logical families. The next three slides identify each of these families, provide a brief description of the types of PDUs in the family, and lists the number of PDUs in each family. A large percentage of the PDU traffic in a DIS simulation is in the entity information PDU family. This is because this is the family that represents the appearance and location of entities. The other family of frequently used PDUs is warfare because this is information related to weapons and munitions. Simulation management differs from the other PDU families because it doesn’t represent the state of simulated entities; rather, it is used for simulation management and control such as starting or resuming a DIS simulation. This slide also shows other categories of military operations that can be represented including logistics, emissions, and communications.

13. DIS PDUs (2 of 3) PDU Family Description # of PDUs Entity Management
Protocols for controlling entity aggregation activities, communicating the state of grouped entities, transferring the ownership of an entity, and requesting a hierarchical linkage of separately hosted simulation entities 4
Minefield
Protocol for communicating information associated with the location, appearance, and other pertinent details of mines and minefields
Synthetic Environment
Protocol support for the simulation of environmental conditions that change during the life of a distributed simulation exercise 5
Simulation Management with Reliability
These PDUs are an alternative to the SIMAN PDUs when using reliable transport 15
Information Operations
Information associated with the representation of information operations 2
The PDU families shown on this slide are less frequently used. Entity management controls where and how some entities, especially aggregated entities, are represented. In this sense, entity management is more about simulation management that entity representation. This slide also shows simulation management with reliability, which is used when reliable network transportation is substituted for the best effort network transportation that is typically used in DIS. Minefields, environmental conditions, and information operations can also be represented in DIS. Switching to reliable transportation increases PDU traffic because of the requirement for acknowledgement traffic. This may reduce effectiveness for some intended uses of DIS that require reduced network traffic.

14. DIS PDUs (3 of 3) PDU Family Description # of PDUs Live Entity
Protocol for use in DIS applications where conservation of network bandwidth is a prime concern. Although created primarily for use by systems involving live entities communicating over bandwidth-limited communication mechanisms, it is available for other similar uses 5
Non-Real-Time Protocol
Protocol for a set of six time management services for non-real-time applications within a DIS exercise 1
The two PDU families on this slide are for simulation management. Live entity PDUs are used primarily to connect to live simulation entities with bandwidth limited-communication mechanisms. Although DIS is almost always used for real-time simulation applications, the standard does include time management services for non-real-time applications.

15. Enumerations Many fields in DIS PDUs take enumerated values.
These enumerations are maintained in a separate SISO reference document, “Enumerations for Simulation Interoperability.”
There are hundreds of enumerations covering everything from platform kind to underwater acoustics.
This includes enumerations for all known platforms by country of origin.
Most of the semantics that are representable in DIS are embedded in the PDUs. This makes it challenging to add new phenomena in between updates to the standard. This challenge is partially addressed by the use of enumerations for many fields and those enumerations being maintained separately in a SISO reference document. A SISO reference document can be updated more rapidly than an IEEE standard.

16. Components of the DIS Standard
Because DIS is a protocol, not an architecture or implementation, the “components” are the documents of the standard:
IEEE IEEE Standard for Distributed Interactive Simulation - Application Protocols
Definitions of DIS PDUs
IEEE IEEE Standard for Distributed Interactive Simulation - Communication Services and Profiles
Description of a connectionless information transfer that supports real-time, as well as non-real-time, exchange
SISO-REF  Enumerations for Simulation Interoperability 
Enumerated values for DIS PDUs fields
The 1278 family also includes IEEE Recommended Practice for Distributed Interactive Simulation - Exercise Management and Feedback which was reaffirmed in However, its functionality has been subsumed in the Distributed Simulation Engineering and Execution Process (DSEEP), IEEE which is architecture neutral. IEEE Recommended Practice for Distributed Interactive Simulation -- Verification, Validation, and Accreditation was also reaffirmed in 2010.

17. DIS Uses and Applications
Collective / unit training
Virtual Battle Space 2/3 (VBS2 / VBS3)
Combined Arms Command and Control Trainer Upgrade System (CACCTUS)
Joint Semi-Automated Forces (JSAF)
Combat Air Force (CAF) Distributed Mission Operations (DMO)
Experimentation – Air Force Research Laboratory (AFRL) Warfighter Readiness Research Division Federation
Experimentation - National Security Experimentation Laboratory (NSEL)
DT&E and OT&E
Architecture Management Integration Environment (AMIE)
Joint Distributed Engineering Plant (JDEP)
DIS is used primarily for training, especially in the Air Force. Not only does the Air Force use DIS for experimentation, but the DoD and Department of Homeland Security also have. The Marine Corps uses DIS for its collective/unit training system CACCTUS and applications such as the VBS series. There have been some applications of DIS to developmental and operational test and evaluation. The Navy has a DIS plug-in for the Architecture Management Integration Environment (AMIE) to enable integration of legacy DIS simulations for test and evaluation applications.
These are just a few of the many applications of DIS. Some of the examples are historical; DIS is now primarily applied to training.

18. DIS Supporting Technologies
Because DIS is a protocol, not an architecture or implementation, it only relies on internet protocols including UDP
Not any specific hardware, software, or OS
Many government organizations and commercial vendors have products that implement DIS interfaces
Viewers
Loggers
Computer Generated Forces (CGF)
DIS applications have been built on top of many hardware and operating systems. Viewers are available that allow visualization of entities on various maps. Data loggers listen to the network and record PDUs to support analysis and after action review. Many CGF systems, both government and commercial, support DIS interfaces.

19. DIS Individual Limitations
The use of best effort, i.e. UDP, underlying the bulk of the protocol means that DIS usually has to use other features to ensure delivery of data required to maintain exercise correctness, e.g. heartbeats
Without the addition of new filtering features, heartbeats and large PDUs, coupled with broadcast limit the size of exercises
Number of entities
Network, i.e. LAN
The use of real time means that the exercise can’t run faster during “slow” periods in the exercise.
Because DIS was originally designed to support a small number of virtual platform simulators on a LAN, it didn’t originally contain the features necessary to cope with wide area network (WAN) environments or simulation environment with high network demand. The most recent version of the standard is beginning to address these shortcomings, but legacy DIS simulations don’t necessarily implement them and tend to rely on proprietary, non-standardized solutions.

20. DIS Interoperability Limitations
Since the data model is in the standard, exercise semantics are limited to what’s in the standard:
Extending the data model and semantics requires an update to the standard, e.g. cyber attacks are not currently represented in the standard
Or using experimental PDUs and running the risk of interoperability issues with other DIS simulations:
That aren’t using the experimental PDUs or
Have defined their own experimental PDUs whose definitions collide
Simulations must be using the same version of the standard and / or the same PDU formats.
Simulations must be using the same enumerations or they will misinterpret PDUs, potentially representing entities incorrectly.
Because DIS does not implement run time name / type checking against its data exchange model as HLA does, there is a higher risk that one simulation will misrepresent entities in a PDU, causing inconsistencies between simulations and potentially fair fight issues.

21. DIS POCs DIS SISO Product Support Group (PSG)

22. DIS References
IEEE IEEE Standard for Distributed Interactive Simulation - Application Protocols
IEEE IEEE Standard for Distributed Interactive Simulation - Communication Services and Profiles
SISO-REF  Enumerations for Simulation Interoperability 
DIS Vision Document, DIS Steering Committee, May 1994
IEEE , Distributed Simulation Engineering and Execution Process (DSEEP)
IEEE , Distributed Simulation Engineering and Execution Process (DSEEP) Multi-Architecture Overlay (DMAO)