High level architecture

from Wikipedia, the free encyclopedia

High-Level Architecture ( HLA ) is an architecture defined by the US Department of Defense (more precisely, the Defense Modeling and Simulation Office, DMSO for the US Department of Defense) for integrated and distributed simulation . This concept became the international standard in 2000 ( IEEE 1516). It is based on the idea of ​​dividing an overall simulation into several individual, small simulations that exchange information with one another. Communication takes place via a computer network. The individual simulations are managed by a central component, the so-called "Run-Time Infrastructure" (RTI). This monitors the simulation process and manages the distribution of the data between the individual simulations (federations). The totality of the individual simulations is referred to as a "federation".

Technical overview

The high-level architecture is based on three major areas of definition

  • Interface Specification : This defines the interface between the individual simulations and the RTI. Specifically, these are program libraries that contain the functions and data structures for communication between RTI and federations.
  • Object Model Template (OMT): The OMT defines which information is to be exchanged between the simulations and how it is to be documented.
  • HLA rules : Defines the rules that a simulation must adhere to in order to conform to the standards.

The data exchanged between HLA federations can either be objects or interactions. An object is a data structure that is available in a participating simulation and that distributes its data (attributes) in the network. An interaction can be equated with an event and has certain parameters. For example, an "anti-aircraft tank" object in simulation A has the attributes position, speed, acceleration, etc. An interaction can now e.g. B. the firing of a guided missile at a fighter aircraft in simulation B and have the type of warhead, the target fired or the firing object as parameters. Simulation B would now be able to react to the firing of the guided missile.

The data can be transmitted as unicast UDP / TCP or multicast . The HLA thus offers more flexibility in the area of ​​networked simulation than the DIS simulation protocol , which exchanges its data exclusively by broadcast .

Interface specification

The interface between simulation and RTI is usually object-oriented and implemented in a programming language such as C ++ or Java. The available objects and functions can be divided into the following groups (service groups):

  • Federation management
  • Declaration Management
  • Object management
  • Time management
  • Data distribution management
  • Ownership Management
  • Support Services

Object Model Template (OMT)

The OMT forms a common framework for communication between HLA federations. It is a standardized template for a data model and defines which data can be exchanged with other federations. The data model itself can be freely defined. There are two types of data models:

  • Federation Object Model (FOM): This defines the objects with attributes and the interactions with parameters that can be exchanged within a federation and is therefore known throughout the federation.
  • Simulation Object Model (SOM): Comparable to FOM, but defines the data that a single federate can exchange.

In order for data to be exchanged within a federation, the federates must support at least one common intersection of the FOM with their SOM.

HLA rules

The HLA rules describe requirements for federations and federations in the simulation process. Here u. a. defines the basis of communication.

Rules for federations:

  • Each federation must have a Federation Object Model (FOM) that is compatible with the Object Model Template (OMT) of the HLA.
  • All simulation-related object instances of a federation should be assigned to its federates, not to the RTI.
  • During a Federation Execution, the entire data exchange between its Federates must take place via the RTI.
  • All communication between a Federate and the RTI has to take place using the services of the Interface Specification of the HLA.
  • During a federation execution, there may only be at most one federate who owns the attribute for an attribute of an instance at any time.

Rules for Federates:

  • Each Federate must have a Simulation Object Model (SOM) that is compatible with the Object Model Template (OMT) of the HLA.
  • Federates should receive or update attributes of the objects defined in the SOM, as well as send and receive the interactions defined in the SOM.
  • Federates should be able to dynamically transfer attributes of the objects defined in the SOM to other Federates or take ownership of other Federates during Federation Execution.
  • Federates should be able to change conditions under which attributes of the objects defined in the SOM are updated.
  • Each Federate should be able to manage its local time so that the data exchange with other Federates specified in the SOM can be carried out correctly. (Time management)

The RTI checks compliance with the HLA rules, the degree of implementation varies depending on the RTI used. In particular, "Time Management" is not supported by all RTIs.

Standards

The HLA has been defined in IEEE Standard 1516 since 2000, which is divided into the following parts:

  • IEEE 1516-2000: High Level Architecture - Framework and Rules
  • IEEE 1516.1-2000: High Level Architecture - Federate Interface Specification
  • IEEE 1516.1-2000: Errata (Oct. 16, 2003)
  • IEEE 1516.2-2000: High Level Architecture - Object Model Template (OMT) Specification
  • IEEE 1516.3-2003: Recommended Practice for HLA Federation Development and Execution Process (FEDEP)

Web links