This page uses content from Wikipedia and is licensed under CC BY-SA.

High-level architecture

The High-level architecture (HLA) is a standard for distributed simulation, used when building a simulation for a larger purpose by combining (federating) several simulations[1]. The standard was developed in the 90’s under the leadership of the US Department of Defense and was later transitioned to become an open international IEEE standard. It is a recommended standard within NATO through STANAG 4603[2]. Today the HLA is used in a number of domains including defense and security and civilian applications. The architecture specifies the following components.

Components of an HLA federation
  • A Run-time Infrastructure (RTI) that provides a standardized set of services through different programming languages. These services include information exchange, synchronization and federation management
  • Federates that are individual simulation systems using RTI services.
  • A Federation Object Model (FOM) that specifies the Object Classes and Interaction Classes used to exchange data. The FOM can describe information for any domain.

Together the above components form a Federation.

The HLA standard consists of three parts:

  1. IEEE Std 1516-2010 Framework and Rules, which specifies ten architectural rules that the components or the entire federation shall adhere to.
  2. IEEE Std 1516.1-2010 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.
  3. IEEE Std 1516.2-2010 Object Model Template Specification which specifies the format that HLA object models, such as the FOM, shall use.


History and versions

HLA was initiated in the early 1990’s 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”[1]. In 1995 DMSO formulated a vision for modeling and simulation and established a modeling and simulation masterplan, which included the High-level Architecture.

Two protocols for M&S interoperability already existed: Distributed Interactive Simulation (DIS), focusing on real-time platform level simulation with a fixed object model, and Aggregate Level Simulation Protocol (ALSP) focusing on simulation of aggregate with time management, ownership management and flexible object models, called confederation models. The purpose of HLA was to provide one unified standard that would meet the simulation interoperability requirements of all US DoD components.

The development of HLA was based on four prototypical federations: the Platform Prototype Federation, the Joint Training Protofederation, the Analysis Protofederation and the Engineering Prototype Federation. The HLA specification was prototyped and refined, until HLA 1.3 was finally released. To facilitate usage outside of the defense community, HLA was then transitioned into an IEEE standard, maintained by Simulation Interoperability Standards Organization (SISO). To facilitate the migration for DIS users, a Federation Object Model corresponding to the fixed object model of DIS was also developed as the Real-time Platform Reference FOM (RPR FOM).

The following HLA versions exist:

HLA 1.3

HLA 1.3 was published in March 1998 by DMSO. It consists of:

  • U.S. Department of Defense, Rules Version 1.3
  • U.S. Department of Defense, High Level Architecture Interface Specification Version 1.3
  • U.S. Department of Defense, High Level Architecture Object Model Template Version 1.3

The US DoD also published interpretations for HLA 1.3:

  • U.S. Department of Defense, Interpretations of the High Level Architecture Interface Specification Version 1.3, Release 3

HLA 1516-2000

HLA IEEE 1516-2000 was published in 2000 by IEEE. It consists of:

  • IEEE Std 1516–2000 – Standard for Modeling and Simulation High Level Architecture – Framework and Rules
  • IEEE Std 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

Major improvements in IEEE 1516-2000 included an XML-based FOM with detailed data type specifications, as well as an improved DDM design.

The IEEE 1516-2000 standard was also complemented by a recommended development process as well as a recommended VV&A process:

  • IEEE 1516.3-2003 – Recommended Practice for High Level Architecture Federation Development and Execution Process (FEDEP). This standard would later become IEEE Std 1730-2010 Distributed Simulation Engineering and Execution Process (DSEEP)
  • 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

It was soon found that the 1516-2000 standard had APIs that were slightly different for each RTI implementation. SISO produced a standard with alternate, dynamic link compatible (DLC) C++ and Java APIs:

  • SISO-STD-004.1-2004: Standard for Dynamic Link Compatible HLA API Standard for the HLA Interface Specification (IEEE 1516.1 Version)
  • SISO-STD-004-2004: Standard for Dynamic Link Compatible HLA API Standard for the HLA Interface Specification (v1.3)

The DLC APIs were later merged into the main standard.

HLA 1516-2010 (HLA Evolved)

The IEEE 1516-2010 standard was published in August 2010 by IEEE and is commonly known as HLA Evolved. 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 extra cost to SISO members or can be purchased from the IEEE shop.

HLA 1516-20XX (HLA 4)

The development of a new version of HLA started in January 2016 by SISO and is currently ongoing.

Technical overview

A high-level architecture consists of the following components:

  • Interface specification, that defines how HLA compliant simulators interact with the run-time infrastructure (RTI). The RTI provides a programming library and an application programming interface (API) compliant to the interface specification.
  • Object model template (OMT), that specifies what information is communicated between simulations, and how it is documented.
  • Rules, that simulations must obey in order to be compliant to the standard.

Common HLA terminology

  • Federate: an HLA compliant simulation entity.
  • Federation: multiple simulation entities connected via the RTI using a common OMT.
  • Object: a collection of related data sent between simulations.
  • Attribute: data field of an object.
  • Interaction: event sent between simulation entities.
  • Parameter: data field of an interaction.

Objects and Interactions

Much of the interactions between federates involve objects and interactions which work in a publish-subscribe model. A federate can register an object, which is instance of a class, and then change the values of the attributes of the object. Other federates that are subscribed to the class can discover the object and then receive attribute value updates. Interactions work in a similar way, except that an interaction is only used once with a specified set of parameters values and then discarded.

Interface specification

The interface specification is object oriented, with specifications for both C++ and Java programming languages plus Ada and FORTRAN for the 1.3 specification.

The interface specification is divided into service groups:

  • Federation management: Defines how federates can connect to the RTI, create, join and manage federations, save and restore federation states and defines a system to synchronize federates to the same time.
  • Declaration management: Defines how federates declare their intentions with regard to publication and subscription of classes and interactions.
  • Object management: Defines how federates can utilize objects and interactions once they have ownership of them.
  • Ownership management: Defines how federates divest and acquire ownership of registered objects.
  • Time management: Defines how time is used in a federation and how it affects object and interaction updates, federate saves and other services.
  • Data distribution management: Defines the various ways that object and interaction data is transferred from and to federates through the RTI.
  • Support services: Defines various services to retrieve information about the current federation, such as classes and interactions.

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.

In 1.3 the FOM passed to the RTI by means of a file, called an FDD, in a Lisp-like syntax. In 1516 and 1516-2010 the file is an XML file.

Management Object Model

Each FOM must contain a copy of the HLA standard Management Object Model, or MOM, which is a collection of classes and interactions

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

Evolved FOM Modules and MIM

For HLA 1516-2010, instead of a single FDD that describes the entire FOM, the specification describes FOM modules which are merged to form the full FOM. By default, a federation is created by merging the HLAstandardMIM.xml FOM module with the module(s) provided by the federate that creates the federation. The standard MIM (MOM and Initialization Module) contains the MOM classes and the basic default data types. Any joining federate can add one or more FOM modules to extend the existing FOM.

In principle, nothing changes for the federates. They call the same functions of the RTI as before. The difference is that elements of a FOM that are not needed do not have to be loaded and managed. In addition, if a federate joins late the additional information exchange requirements can be added when modular FOMs are used.

HLA rules

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.

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

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).[4]

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, and is highly relevant for HLA developers. It provides a way to specify conceptual models and how to map them to an HLA FOM.[5]

Alternatives and Disadvantages

Virtually all means of interconnecting Distributed Modeling and Simulation (DM&S) applications have alternatives and or disadvantages and the HLA is no exception.

Alternatives

In regards to the Distributed Modeling and Simulation (DM&S) industry the most often used alternative to the HLA is clearly Distributed Interactive Simulation (DIS), IEEE 1278.1-2012, a recently updated 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 with the distinct advantage of having an open on-the-wire protocol for system interoperability.[6]

Disadvantages

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 in order for applications to interoperate [7].

See also

References

  1. ^ a b Kuhl, Frederick; Weatherly, Richard; Dahmann, Judith (October 18, 1999). Creating Computer Simulation Systems: An Introduction to the High Level Architecture (1 ed.). Prentice Hall. ISBN 0130225118.
  2. ^ STANAG 4603: Modelling and Simulation Architecture Standards for Technical Interoperability: High Level Architecture (HLA). NATO.
  3. ^ U.S. Defense Modeling and Simulation Office (2001). RTI 1.3-Next Generation Programmer's Guide Version 4. U.S. Department of Defense.
  4. ^ "High Level Architecture STANAG Development (MSG-033)". Retrieved March 3, 2015.
  5. ^ BOM info
  6. ^ Doshi, Rajiv; Castellote, Gerardo-Pardo (2006). "A Comparison of HLA and DDS" (PDF). Real-Time Innovations. Retrieved March 3, 2015.
  7. ^ Granowetter, Len. "RTI Interoperability Issues - API Standards, Wire Standards, and RTI Bridges". Retrieved 14 March 2018.

External links