A High-Level Architecture (HLA) is a family of related standards that together describe a unified approach and common architecture to constructing interoperable simulation systems. It contains major functional elements, interfaces, and design rules, pertaining to all DoD simulation applications, and providing a common framework within which specific system architectures can be defined.
High-Level Architecture (HLA) Objectives
The objectives of the HLA are to: [1,2]
- Establish a common development and execution architecture to facilitate the interoperability of all types of Modeling & Simulation (M&S) (including real-time, faster than real-time, event-driven simulations and command and control systems)
- Facilitate the re-use of M&S components
The HLA provides a general framework within which simulation developers can structure and describe their simulation applications. The use of runtime infrastructure software is required to support operations of a federation execution. The runtime infrastructure software provides a set of services, as defined by the federate interface specification, used by federates to coordinate operations and data exchange during runtime execution. 
HLA is composed of three (3) parts: 
- Rules: that simulations must obey in order to be compliant to the standard. Federates and Federations define relationships among federating compliant simulations.
- Federate: an HLA compliant simulation entity.
- Federation: multiple simulation entities connected via the RTI using a common OMT.
- Interface Specification: Describes the way compliant simulations interact during operation and with the Run-Time Infrastructure (RTI). The RTI provides a programming library and an Application Programming Interface (API) (API) compliant to the interface specification.
- Object Model Template: Specifies the form in which simulation elements are described
- Federation Object Model (FOM). The FOM describes the shared object, attributes, and interactions for the whole federation.
- Simulation Object Model (SOM). A SOM describes the shared object, attributes, and interactions used for a single federate.
DoD High-Level Architecture (HLA) Federate Compliance Testing
A HLA compliance testing process has been established as the means to ensure DoD simulations are compliant with the HLA specifications. Federate HLA Compliance Testing can be conducted at (http://hlatest.dod-msiac.org:8080/FTMS4). This site provides the federate developer with a simple means to ensure that a federate is compliant with the HLA standards. (See M&SCO HLA)
Current and in Development HLA Standards:
- IEEE 1516
- NATO Standardization Agreement (STANAG) 4603
- SISO-STD-004-2004:Dynamic Link Compatible HLA API Standard for the HLA Interface Specification Version 1.3
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.
AcqLinks and References:
- Modeling & Simulation Guidance for the Acquisition Workforce – Oct 208
- DoD Instruction 5000.61 “DoD M&S Verification, Validation, and Accreditation (VV&A)” – 9 Dec 2009
- DoD 5000.59 “DoD Modeling and Simulation (M&S) Management” – 8 Aug 2007
- DoD “M&S Body of Knowledge (BOK)” – June 2008
- DAU “Test and Evaluation Management Guide” – Chapter 14 – Jan 2005
- SMC “Systems Engineering Handbook” – 15 Jan 2004
- DoD 5000.59-M “M&S Glossary” – Jan 1998
- DoD “M&S Glossary” – 1 Oct 2011
- Acquisition Modeling and Simulation Master Plan – 17 April 2006
- White Paper: JHU APL “Best Practices for the Development of M&A” – June 10
- White Paper: Introduction to Modeling and Simulation by Anu Maria
- White Paper: Introduction to Modeling and Simulation
- Presentation: Manager’s Guide to the High Level Architecture (HLA) for M&S – 11 May 2009
- Website: Air Force Agency for Modeling and Simulation
- Website: Army Modeling and Simulation Office
- Website: DoD M&S Coordination Office (MSCO)
- Website: DoD M&S Catalog
- Website: Simulate Interoperability Standards Organization (SISO)