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. [1]

HLA is composed of three (3) parts: [2]

1. 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.
2. 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.
3. 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. [3]

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.

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)