The High Level Architecture (HLA) is a standard for distributed simulation, used when building a simulation for a larger purpose by combining (federating) several simulations. The standard was developed in the 1990s under the leadership of the US Department of Defense and was later transitioned to become an open international IEEE standard. It is a recommended standard within NATO through STANAG 4603. Today the HLA is used in a number of domains including defense and security and civilian applications.

The purpose of HLA is to enable interoperability and reuse. Key properties of HLA are:

  • The ability to connect simulations running on different computers, locally or widely distributed, independent of their operating system and implementation language, into one Federation.
  • Ability to specify and use information exchange data models, Federation Object Models (FOMs), for different application domains.
  • Services for exchanging information using a publish-subscribe mechanism, based on the FOM, and with additional filtering options.
  • Services for coordinating logical (simulation) time and time-stamped data exchange.
  • Management services for inspecting and adjusting the state of a Federation.

HLA forms the basis for developing standardized and extendable FOMs in different communities, for example in aerospace and defense.

The architecture specifies the following components.

thumb|right|Components of an HLA federation

  • A Run-time Infrastructure (RTI) that provides a standardized set of services through different programming languages. These services include information exchange, synchronization and federation management
  • Federates that are individual simulation systems using RTI services.
  • A Federation Object Model (FOM) that specifies the Object Classes and Interaction Classes used to exchange data. The FOM can describe information for any domain.

Together the above components form a Federation.

The HLA standard consists of three parts:

  1. IEEE Std 1516-2025 Framework and Rules, which specifies ten architectural rules that the components or the entire federation shall adhere to.
  2. IEEE Std 1516.1-2025 Federate Interface Specification, which specifies the services that shall be provided by the RTI. The services are provided as C++ and Java APIs as well as Web Services.
  3. IEEE Std 1516.2-2025 Object Model Template Specification, which specifies the format that HLA object models, such as the FOM, shall use.

History and versions

HLA was initiated in the early 1990s when Dr. Anita K. Jones, the Director of Defense Research and Engineering within the US Department of Defense, gave the Defense Modeling and Simulation Office (DMSO) the task of “assuring interoperability and reusability of defense models and simulations”. It consists of:

It consists of:

  • IEEE 1516–2010 – Standard for Modeling and Simulation High Level Architecture – Framework and Rules,
  • IEEE 1516.1–2010 – Standard for Modeling and Simulation High Level Architecture – Federate Interface Specification,
  • IEEE 1516.2-2010 – Standard for Modeling and Simulation High Level Architecture – Object Model Template (OMT) Specification,

Major improvements in IEEE 1516-2010 include Modular FOMs, incorporation of the DLC APIs in C++ and Java, a Web Services API and Fault Tolerance.

Machine-readable parts of this version of HLA, such as XML Schemas, C++, Java and WSDL APIs as well as FOM/SOM samples can be downloaded from the IEEE 1516 download area of the IEEE web site. The full standards texts are available at no cost to SISO members or can be purchased from the IEEE shop.

HLA 1516-2025 (HLA 4)

IEEE 1516-2025 (HLA 4) was approved by IEEE in February 2025 and published in August 2025. It consists of:

  • IEEE 1516–2025 – Standard for Modeling and Simulation High Level Architecture – Framework and Rules Filtering can be based on continuous values (like latitude and longitude) or discrete values (like car brand).

Key concepts of DDM are:

Dimension: a named interval (0..n) used for filtering, with values starting with 0 and ending with an upper bound n. Data in the simulation domain is mapped to one or more dimensions. For example, dimensions for geographical filtering could be LatitudeDimension and LongitudeDimension. A dimension for filtering based on car brand could be CarBrandDimension.

Normalization function: a function that maps input values to integer values to be used in a dimension. An example is that a normalization function for the LatitudeDimension could map a latitude value ranging from -90.0 to +90.0 to an integer in the range 0..179. A normalization function for the CarBrandDimension could map a set of car brands Kia, Ford, BMW and Peugeot to an integer in the range 0..3.

Range: an interval on a dimension, specified by a lower bound (inclusive) and an upper bound (exclusive).

Region: a set of ranges, each one relating to a particular dimension. In the above example, a region could consist of the range (3..5) for LatitudeDimension (55..65) for LongitudeDimension and (0..1) for the CarBrandDimension. At runtime Region Realizations (objects) are instantiated to represent regions. The ranges of a region can be modified over time.

Region overlap: two regions overlap if, for all dimensions that they have in common, their ranges overlap.

At runtime, a federate can provide Regions when subscribing to object class attributes and interactions. Regions are also used when sending attribute updates and interactions. When DDM is used, attribute updates and interactions will only be delivered if there is a region overlap.

Key services for Regions are:

  • CreateRegion that is used to create a region with a specified set of Dimensions.
  • DeleteRegion that is used to delete a region.
  • CommitRegionModifications that is used to change the ranges of a dimension for a Region.

Key services for exchanging attribute updates with DDM are:

  • RegisterObjectInstanceWithRegions that is used to register an object instance with regions associated with its attributes.
  • AssociateRegionsForUpdates that is used to associate regions with attributes of an object instance.
  • SubscribeObjectClassAttributesWithRegions that is used to subscribing to attributes of objects where the regions used for subscription overlaps with the regions of the attributes.

Key services for exchanging interactions with DDM are:

  • SubscribeInteractionClassWithRegions that is used to subscribe to interactions where the regions used for subscription overlaps with the regions of the interactions.
  • SendInteractionsWithRegions that is used to send interactions with associated regions.

Support services

The HLA Support Services, described in chapter 10 of the HLA Interface Specification,

  1. Federations shall have an HLA federation object model (FOM), documented in accordance with the HLA object model template (OMT).
  2. In a federation, all representation of objects in the FOM shall be in the federates, not in the run-time infrastructure (RTI).
  3. During a federation execution, all exchange of FOM data among federates shall occur via the RTI.
  4. During a federation execution, federates shall interact with the run-time infrastructure (RTI) in accordance with the HLA interface specification.
  5. During a federation execution, an attribute of an instance of an object shall be owned by only one federate at any given time.
  6. Federates shall have an HLA simulation object model (SOM), documented in accordance with the HLA object model template (OMT).
  7. Federates shall be able to update and/or reflect any attributes of objects in their SOM and send and/or receive SOM object interactions externally, as specified in their SOM.
  8. Federates shall be able to transfer and/or accept ownership of an attribute dynamically during a federation execution, as specified in their SOM.
  9. Federates shall be able to vary the conditions under which they provide updates of attributes of objects, as specified in their SOM.
  10. Federates shall be able to manage local time in a way that will allow them to coordinate data exchange with other members of a federation.

HLA Evolved

The IEEE 1516 standard has been revised under the SISO HLA-Evolved Product Development Group and was approved 25-Mar-2010 by the IEEE Standards Activities Board. The revised IEEE 1516–2010 standard includes current DoD standard interpretations and the EDLC API, an extended version of the SISO DLC API. Other major improvements include:

  • Extended XML support for FOM/SOM, such as Schemas and extensibility
  • Fault tolerance support services
  • Web Services (WSDL) support/API
  • Modular FOMs
  • Update rate reduction
  • Encoding helpers
  • Extended support for additional transportation (such as QoS, IPv6,...)
  • Standardized time representations

Federation Conformance

In order to ensure the proper interaction between simulations, a way of testing federate conformance is defined. This involves ensuring that every class and interaction listed in the SOM for a particular federate is used according to the usage described, "PublishSubscribe", "Publish", "Subscribe" or "None".

STANAG 4603

HLA (in both the current IEEE 1516 version and its ancestor "1.3" version) is the subject of the NATO standardization agreement (STANAG 4603) for modeling and simulation: Modeling And Simulation Architecture Standards For Technical Interoperability: High Level Architecture (HLA).

Base Object Model

The Base Object Model (BOM), SISO-STD-003-2006 is a related standard by SISO to provide better reuse and composability for HLA simulations. It provides a way to specify conceptual models and how to map them to an HLA FOM.

Alternatives

In regards to the Distributed Modeling and Simulation (DM&S) industry the most often used alternative to the HLA, for real-time simulation of military platforms, is Distributed Interactive Simulation (DIS), IEEE 1278.1-2012, a simulation protocol. Most HLA RTI vendors also feature DIS in their products. As for middleware applications that most closely match HLA features, such as

the publish and subscribe feature (P&S) see Data Distribution Service (DDS) which shares many of the same characteristics but having an open on-the-wire protocol for system interoperability.

Criticism

HLA is a Message-oriented middleware that defines as a set of services, provided by a C++ or Java API. There is no standardized on-the-wire protocol. Participants in a federation must use RTI libraries from the same provider and usually also of the same version, which in some cases is perceived as a drawback. Most current tools also provide interconnectivity through sockets.

See also

  • List of commercial and non-commercial RTIs
  • Computer simulation
  • Distributed computing
  • Simulation Interoperability Standards Organization

References

  • The HLA Tutorial: a free tutorial (PDF)
  • Errata to IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) — Federate Interface Specification
  • Department of Defense (DoD) Interpretations of the IEEE 1516–2000 series of standards, Release 2 (2003-jul-01)