Distributed military simulation — linking multiple simulation systems across a network so they share a common synthetic environment — is one of the foundational technical requirements of large-scale collective training. When a ground forces command post simulator needs to interact with an air operations center simulator and a logistics management simulation simultaneously, the question is not whether to use an interoperability protocol, but which one. The two dominant standards are DIS (Distributed Interactive Simulation, IEEE 1278) and HLA (High Level Architecture, IEEE 1516). Understanding the difference, and knowing when each is appropriate, is essential knowledge for any team building distributed military simulation.
DIS vs HLA: Difference and When to Use Each
DIS is the older standard, developed in the early 1990s for linking vehicle simulators. It operates on a simple peer-to-peer model: each participant broadcasts Protocol Data Units (PDUs) containing entity state information to all other participants on the network. There is no central coordinator, no time management, and no concept of ownership — any participant can publish entity state data. DIS is straightforward to implement, runs well on local area networks, and has excellent tool support.
The simplicity of DIS is also its limitation. Because all entity state is broadcast to all participants, DIS does not scale to exercises with thousands of entities — the network bandwidth and processing load become prohibitive. DIS also has no native mechanism for time synchronization across simulation participants: entity positions are dead-reckoned between state updates, and there is no guarantee that different participants share the same view of simulation time. For exercises requiring tight temporal coordination — particularly those involving effects that must be computed across simulation boundaries — DIS is insufficient.
HLA addresses these limitations with a more sophisticated architecture. In an HLA federation, a central component called the Runtime Infrastructure (RTI) manages all communication between simulation participants (called federates). The RTI provides time management services, data distribution management (controlling which federates receive which data), ownership management (controlling which federate is authoritative for which object attribute), and federation management services. HLA scales to large exercises and provides the temporal coordination that DIS lacks.
The practical guidance: use DIS for exercises linking a small number of simulators on a reliable LAN where implementation simplicity is paramount and temporal precision is not critical. Use HLA for large-scale exercises, exercises requiring precise temporal coordination, or exercises that must federate systems across wide area networks with potentially unreliable connectivity.
HLA Runtime Infrastructure: Key Concepts
The RTI is the central technical component of an HLA federation. It is a middleware layer — typically a server process that federates connect to — that implements the HLA services defined in the IEEE 1516 standard. Understanding the RTI's service model is necessary for any developer implementing an HLA federate.
The RTI provides six service groups. Federation Management handles the lifecycle of the federation: creating and joining the federation, synchronizing federates at defined points, and destroying the federation at exercise end. Declaration Management allows federates to declare what object classes and interaction classes they publish (produce) and subscribe to (consume). The RTI uses these declarations to route data efficiently — a federate only receives data it has declared an interest in. Object Management handles the creation, update, and deletion of simulation objects across the federation. Ownership Management governs which federate is authoritative for each attribute of each object — a capability that allows object ownership to be transferred between federates as the exercise progresses. Time Management coordinates simulation time across federates, ensuring temporal consistency. Data Distribution Management allows subscription filtering based on regions of the simulation space, drastically reducing network traffic in geographically distributed exercises.
The Federation Object Model (FOM) is the schema that defines what objects and interactions exist in the federation, what attributes they have, and what data types those attributes use. The FOM is the key interoperability contract between federates — all federates in a federation must use a compatible FOM, and changing the FOM during federation development requires coordination across all federate developers. SISO (Simulation Interoperability Standards Organization) maintains the SISO-STD-001 RPR FOM (Real-time Platform Reference FOM), a widely used baseline FOM for military simulation that defines common object classes for platforms, weapons, sensors, and environmental effects.
Federation Management: Joining, Time Management, Data Distribution
Federation joining follows a defined sequence. Before any federate can join, the federation must be created — typically by a designated federation manager federate. Each federate then calls the RTI join service, providing its name and the name of the FOM modules it requires. The RTI verifies FOM compatibility and establishes the federate's connection to the federation.
Time management is the most technically demanding aspect of HLA implementation. HLA supports two time management schemes: time-constrained (a federate cannot advance its local time ahead of the RTI's granted time) and time-regulating (a federate contributes to the RTI's time advancement decisions). A federate that both produces time-stamped messages and must process them in order should be both time-constrained and time-regulating. The RTI's time advance mechanism — most commonly the Time Advance Request (TAR) service — coordinates time advancement across all time-regulating federates using a lookahead mechanism that ensures no federate receives a message with a timestamp in its past.
Data Distribution Management (DDM) reduces network load by allowing federates to define routing spaces — geometric regions in the simulation's geographic space — and express their publication and subscription interests relative to these regions. A ground forces federate interested only in entities within a 50 km radius of its area of operations can declare this as a subscription region; the RTI will not route it entity state updates for entities outside this region. For large exercises with thousands of entities spread across a continental-scale exercise area, DDM is essential for keeping network traffic manageable.
Implementation note: The single most common HLA implementation failure is incorrect time management configuration. Federates that declare themselves time-regulating but do not advance time correctly will deadlock the entire federation. Always implement and test time management in isolation before integrating with other federation components. Use the RTI's built-in diagnostic tools to verify lookahead values and time advance grant sequences.
Practical SDKs and Tools
Two RTI implementations dominate the professional military simulation market: Pitch pRTI (from Pitch Technologies) and VT MAK's MAKHLA. Both implement IEEE 1516-2010 (HLA Evolved) and provide C++, Java, and Python APIs. Pitch pRTI is more commonly used in European defense simulation programs and has strong support for the SISO RPR FOM. VT MAK's ecosystem is particularly strong in North American programs and includes additional tooling for federation development and debugging.
For development and testing, both vendors provide evaluation licenses and development tools. Pitch provides pRTI Developer, a graphical tool for FOM editing, federation monitoring, and time management visualization. VT MAK provides MAK RTI Developer with similar capabilities. Both tools significantly reduce the debugging time for federation integration issues.
For open-source HLA development, OpenRTI and portico provide free RTI implementations suitable for development and experimentation. They are not recommended for production use in defense programs due to certification and support requirements, but are valuable for initial development and proof-of-concept work.
On the DIS side, the open-dis library (available for Java, C++, Python, and JavaScript) provides a solid foundation for DIS federate development. For exercises using both DIS and HLA, gateway bridges such as VT MAK's DIS to HLA Bridge allow DIS-based simulators to participate in HLA federations without modification.