High Level Architecture

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 • IEEE 1516.1–2025 – Standard for Modeling and Simulation High Level Architecture – Federate Interface Specification • IEEE 1516.2-2025 – Standard for Modeling and Simulation High Level Architecture – Object Model Template (OMT) Specification HLA 4 offers improved security, scalability, extensibility, cloud and container readiness, and full life-cycle support. Machine-readable parts of HLA 4, such as XML Schemas, C++, Java and Federate Protocol APIs as well as FOM/SOM samples can be downloaded from the IEEE 1516.1-2025 page of the IEEE web site. == Technical overview ==

The HLA standard consists of three parts: • Framework and Rules, which specifies ten architectural rules that federates or the entire federation shall adhere to. • 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. • Object Model Template Specification which specifies the format that HLA object models, such as the FOM, shall use. Common HLA terminology • Run-time Infrastructure (RTI): Software that provides a standardized set of services, as specified in the HLA Federate Interface Specification. There are seven service groups. • Federate: A system, such as a simulation, a tool or an interface to live systems, that connects to the RTI. Examples of tools are data loggers and management tools. A federate uses the RTI services to exchange data and synchronize with other federates. • Federation: A set of federates that connect to the same RTI together with a common FOM. • Federation Execution: A session, where a set of federates execute together in a federation with a specific objective, using the same RTI and FOM. • Federation Object Model (FOM): A document that specifies object classes, interaction classes, data types and additional data that is used for the information exchange in a federation. A FOM is an XML file that follows the format of the HLA Object Model Template and the associated XML Schema. Different FOMs are used for exchanging data for different application domains. There are standardized FOMs, called reference FOMs, that are commonly used as a starting point for FOM development. A FOM can be developed and extended in a modular way using FOM modules. • Simulation Object Model (SOM): A document that specifies object classes, interaction classes, data types and additional data that a particular simulation publishes and/or subscribes to in a federation. A SOM is also an XML file that follows the format of the HLA Object Model Template and the associated XML Schema. SOMs can also be developed and extended in a modular way using SOM modules. • Object: Objects are used to represent data that is persistent over some period of time and that have attributes that can be updated. They are defined in the FOM/SOM using an Object Class. • Interaction: Interaction are used to represent instantaneous events with parameters. An interaction that has been sent cannot be updated (as opposed to object classes). They are defined in the FOM/SOM using an Interaction Class. • Datatypes: The representation and interpretation of attribute and parameter data is specified in the FOM/SOM using HLA Datatypes. • Publish: A federate that publishes an object class with a set of attributes can register and delete instances of that object class and update its attribute values. A federate that publishes an interaction class can send interactions of that interaction class, together with associated parameter values. • Subscribe: A federate that subscribes to an object class with a set of attributes will discover registrations and deletions of instances of that object class and receive updates of subscribed attributes. A federate that subscribes to an interaction class will receive interactions of that interaction class, together with associated parameter values. == Interface specification ==

The RTI services are defined in the HLA Interface Specification. They are grouped into seven service groups. In addition to these services, the Management Object Model (MOM) provides services that makes it possible to inspect and adjust the state of the federation programmatically. Most RTIs consist of a Central RTI Component (CRC), which is an executable and Local RTI Components (LRCs), which are libraries that are used by the federates. Services are provided through a C++ or Java API and also using Web services. In the C++ and Java APIs, services are invoked using calls to an instance of the RTI Ambassador class. The RTI delivers information to a federate using callbacks, which are delivered using calls to an instance of the Federate Ambassador class. In the Web Services API, defined using WSDL, calls are made, and callbacks are fetched, by the federate using Web Services requests and responses. The service group descriptions below focus on key services. Exceptions and advisories are not included. Federation Management Services The purpose of Federation Management services, described in chapter 4 of the HLA Interface Specification, 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, provide a number of supporting services. These include: • Getting Handles (references) to be used in the above service calls. • Setting various runtime switches, in particular for advisories (notifications). • Controlling the delivery of callbacks. Management Object Model The purpose of the Management Object Model, described in chapter 11 of the HLA Interface Specification, is to provide services for managing a federation. This is performed using the MOM object and interaction classes. MOM objects are defined in a special FOM module called the MIM, that is automatically loaded by the RTI. Key MOM features include: • List and inspect properties of federates. • Inspect properties of the federation. • Get the content of the current FOM and FOM modules. • Inspect the state of Time management. • Inspect and modify publications and subscriptions of federates. • Inspect certain performance figures. • Inspect which federate that calls which HLA services. • Inspect status of synchronization points. ==Object model template (OMT)==

The OMT is a template used for describing Federation Object Models (FOMs) and Simulation Object Models (SOMs). FOMs and SOMs can be represented in a tabular format or using XML. The latter format is used when a FOM is loaded into the RTI. In earlier versions of HLA, FOMs were monolithic, but the current version of the standard supports modular FOMs, i.e. several modules, covering different aspects of the information exchange, can be provided to the RTI. A number of predefined classes, datatypes, dimensions and transportation types are provided in the standard. These are provided in the HLAstandardMIM.xml FOM module. Predefined concepts are prefixed with HLA, for example HLAobjectRoot and HLAunicodeString. There are three different XML Schemas for the OMT: • The OMT DIF XML Schema, that verifies that an OMT document follows the basic OMT format, but not that it is complete and has referential integrity. • The OMT FDD XML Schema, that verifies that an OMT document contains enough information to be useful by an RTI. Note that this schema is provided in the Interface Specification. • The OMT Conformance Schema that verifies that an OMT document is complete and has referential integrity. Identification Table The purpose of the identification table is to provide meta-data about the model, to facilitate reuse of the FOM/SOM or federates. The following fields are specified: • General: Name, Type (FOM/SOM), Version, Modification date, Security classification, Release restriction, Purpose, Application domain, Description, Use limitation and Use history • Keywords: Keyword values and Taxonomy used • Point of contacts (POC): Type (Primary author/Contributor/Proponent/Sponsor/Release Authority/Technical POC), POC name, POC organization, POC telephone, POC email • References: Type (Text document/Spreadsheet/Powerpoint file/Standalone FOM/Dependency FOM/Composed from FOM), Identification (document name or FOM name) • Other • Glyph (Icon) Object Classes Structure Table The purpose of the object class structure table is to specify the class hierarchy (subclass/superclass) of the object classes that are used to instantiate objects in an HLA federation. Object class attributes are inherited from superclasses to subclasses based on this hierarchy. The root of the object class tree is known as HLAobjectRoot. An example of a fully qualified name of an object class is HLAobjectRoot.Car.ElectricCar The following fields are specified for an object class in the hierarchy: • Name • Publication (Publish/Subscribe/PublishSubscribe/Neither) Attribute Table The purpose of the attribute table is to specify the attributes that are available for a given object class. Since attributes are inherited, an object class will have the union of all attributes that are locally defined on the object class or specified on any direct or indirect superclass. The following fields are specified for an attribute • Object class name, for which it is defined • Attribute name • Datatype, defined in the Datatypes Table (see below) • Update type (Static/Periodic/Conditional/NA) • Update condition • D/A (Divest/Acquire/NoTransfer/DivestAcquire): Whether the attribute can be divested and or acquired using the HLA Ownership Services • P/S (Publish/Subscribe/PublishSubscribe/Neither): Whether the attribute can be published and/or subscribed. In a SOM, this information relates to the Federate described, in a FOM it relates to the entire federation. • Available Dimensions • Transportation (Reliable/BestEffort/other transportations described in the Transportation table) • Order (Receive/TimeStamp): Delivery order for attribute updates. Interaction Class Structure Table The purpose of the interaction class structure table is to specify the class hierarchy (subclass/superclass) of the interaction classes that are used to exchange interactions in an HLA federation. Interaction class parameters are inherited from superclasses to subclasses based on this hierarchy. The root of the interaction class tree is known as HLAinteractionRoot. An example of a fully qualified name of an interaction class is HLAinteractionRoot.CarCommand.Start. The following fields are specified for an interaction class in the hierarchy: • Name • Publication (Publish/Subscribe/PublishSubscribe/Neither) Parameter Table The purpose of the parameter table is to specify the parameters that are available for a given interaction class. Since parameters are inherited, an interaction class will have the union of all parameters that are locally defined on the interaction class or specified on any direct or indirect superclass. Dimensions table The purpose of the dimensions table is to specify the DDM dimensions, used for attributes and interaction classes. Time representation table The purpose of the time representation table is to specify the datatypes used by the Time Management services. User-supplied tag table A user-supplied tag can be supplied when calling certain HLA services. The purpose of the user-supplied tag table is to specify the datatypes of these tags. Synchronization table The purpose of the synchronization table is to specify the synchronisation points used in a federation. Transportation type table The purpose of the transportation type table is to specify the available transportation types. There are two predefined transportation types: HLAreliable and HLAbestEffort. Update rate table The purpose of the update rate table is to specify the available maximum update rates. Switches table The runtime behaviour of the RTI can be controlled using a number of predefined switches. The purpose of the switches table is to provide initial values for these switches. Some of the switches can also be updated at runtime. Datatypes The purpose of the datatype tables is to provide specifications of the datatypes used for attributes, parameters, dimensions, time representation, user supplied tag and synchronization points. There are six categories of datatypes, with a separate tabular format for each of them. Basic Data Representation Table The purpose of the basic data representation table is to provide binary representations for use in other tables. A number of predefined basic datatypes are provided in the HLA standard: HLAinteger16BE, HLAinteger32BE, HLAinteger64BE, HLAfloat32BE, HLAfloat64BE, HLAoctetPairBE, HLAinteger16LE, HLAinteger32LE, HLAinteger64LE, HLAfloat32LE, HLAfloat64LE, HLAoctetPairLE and HLAoctet. The set of basic datatypes is usually not extended with user defined basic datatypes. Simple Datatypes Table The purpose of the simple datatypes table is to describe simple scalar data items. A number of predefined simple datatypes are provided in the HLA standard: HLAASCIIchar, HLAunicodeChar, HLAbyte, HLAinteger64time and HLAfloat64time. It is common to include user defined simple datatypes in a FOM. Enumerated Datatypes Table The purpose of the enumerated datatypes table is to describe data elements that can take on a finite discrete set of values. One predefined enumerated datatype is provided in the standard: HLAboolean. It is common to include user defined enumerated datatypes in a FOM. Array Datatypes Table The purpose of the enumerated datatypes table is to describe arrays of data elements (simple, enumerated, arrays, fixed records or variant records). A number of predefined simple datatypes are provided in the HLA standard: HLAASCIIstring, HLAunicodeString, HLAopaqueData and HLAtoken. It is common to include user defined array datatypes in a FOM. Fixed Record Datatypes Table The purpose of the fixed record datatypes table is to describe records with a fixed set of data elements (simple, enumerated, arrays, fixed records or variant records). Variant Record Datatypes Table The purpose of the variant record datatypes table is to describe records that may contain different, predefined sets of data elements. The different sets are called Alternatives. Which alternative that applies for a given variant record is indicated by a data element called the Discriminant. Notes table The purpose of the notes table is to provide annotations and additional descriptions of items in other tables. ==HLA rules==

The HLA rules describe the responsibilities of federations and the federates that join. • Federations shall have an HLA federation object model (FOM), documented in accordance with the HLA object model template (OMT). • In a federation, all representation of objects in the FOM shall be in the federates, not in the run-time infrastructure (RTI). • During a federation execution, all exchange of FOM data among federates shall occur via the RTI. • During a federation execution, federates shall interact with the run-time infrastructure (RTI) in accordance with the HLA interface specification. • During a federation execution, an attribute of an instance of an object shall be owned by only one federate at any given time. • Federates shall have an HLA simulation object model (SOM), documented in accordance with the HLA object model template (OMT). • 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. • Federates shall be able to transfer and/or accept ownership of an attribute dynamically during a federation execution, as specified in their SOM. • Federates shall be able to vary the conditions under which they provide updates of attributes of objects, as specified in their SOM. • 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). ==Related standards==

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==