High Level Architecture (simulation)

From Wikipedia, the free encyclopedia

The High Level Architecture (HLA) is a general purpose architecture for distributed computer simulation systems. Using HLA, computer simulations can communicate to other computer simulations regardless of the computing platforms. Communication between simulations is managed by a Run-Time Infrastructure (simulation) (RTI).

Contents

[edit] Technical overview

The High Level Architecture (HLA) consists of the following components:

  • Interface Specification. The interface specification document defines how HLA compliant simulators interact with the Run-Time Infrastructure (simulation) (RTI). The RTI provides a programming library and an application programming interface (API) compliant to the interface specification.
  • Object Model Template (OMT). The OMT specifies what information is communicated between simulations and how it is documented.
  • HLA Rules. Rules that simulations must obey to be compliant to the standard.

Common terminology is used for HLA. A HLA compliant simulation is referred to as a federate. Multiple simulations connected via the RTI using a common OMT are referred to as a federation. A collection of related data sent between simulations is referred to as an object. Objects have attributes (data fields). Events sent between simulations are referred to as interactions. Interactions have parameters (data fields).

[edit] Interface specification

The interface specification is object oriented. Many RTIs provide APIs in C++ and the Java programming languages.

The interface specification is divided into service groups:

  • Federation Management
  • Declaration Management
  • Object Management
  • Ownership Management
  • Time Management
  • Data Distribution Management
  • Support Services

[edit] Object model template

The object model template (OMT) provides a common framework for the communication between HLA simulations. OMT consists of the following documents:

  • 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.

[edit] HLA rules

The HLA rules describe the responsibilities of federations and the federates that join.[1]

  1. Federations shall have a 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.

[edit] Base Object Model

The Base Object Model (BOM) is a new concept created by SISO to provide better reuse and composability for HLA simulations, and is highly relevant for HLA developers. More information can be found at Boms.info.

[edit] Federation Development and Execution Process (FEDEP)

FEDEP, IEEE IEEE 1516.3-2003, is a standardized and recommended process for developing interoperable HLA based federations. FEDEP is an overall framework overlay that can be used together with many other, commonly used development methodologies.

[edit] Standards

HLA is defined under IEEE Standard 1516:

  • IEEE 1516-2000 - Standard for Modeling and Simulation High Level Architecture - Framework and Rules
  • IEEE 1516.1-2000 - Standard for Modeling and Simulation High Level Architecture - Federate Interface Specification
  • IEEE 1516.1-2000 Errata (2003-oct-16)
  • IEEE 1516.2-2000 - Standard for Modeling and Simulation High Level Architecture - Object Model Template (OMT) Specification
  • IEEE 1516.3-2003 - Recommended Practice for High Level Architecture Federation Development and Execution Process (FEDEP)
  • IEEE 1516.4-2007 - Recommended Practice for Verification, Validation, and Accreditation of a Federation an Overlay to the High Level Architecture Federation Development and Execution Process

See also:

Prior to publication of IEEE 1516, the HLA standards development was sponsored by the US Defense Modeling and Simulation Office. The final version of the standard was known as HLA 1.3.

[edit] STANAG 4603

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

[edit] DLC API

SISO has developed a complementary HLA API specification know as the Dynamic Link Compatible (DLC) API. The DLC API addresses a limitation of the IEEE 1516 and 1.3 API specification, whereby federate recompilation was necessary for each different RTI implementation.

[edit] HLA-Evolved

The IEEE 1516 standard is currently being revised under the SISO HLA-Evolved Product Development Group. The revised IEEE 1516-200x standard is expected to include current DoD standard interpretations and the 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

[edit] See also

[edit] References

  1. ^ U.S. Defense Modeling and Simulation Office (2001). RTI 1.3-Next Generation Programmer's Guide Version 4. U.S. Department of Defense.