High-level architecture

The high-level architecture (HLA) is a general purpose architecture for distributed computer simulation systems. Using HLA, computer simulations can interact (that is, to communicate data, and to synchronize actions) with other computer simulations regardless of the computing platforms. The interaction between simulations is managed by a run-time infrastructure (RTI). HLA is an interoperability standard for distributed simulation used to support analysis, engineering and training in a number of different domains in both military and civilian applications and is the standard technical architecture for all US Department of Defense simulations.[1][2]

Technical overview

A high-level architecture consists of the following components:

Common HLA terminology

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 an 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:

Object model template

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

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.

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

Federation development and execution process (FEDEP)

FEDEP, 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.

Distributed Simulation Engineering and Execution Process (DSEEP)

In spring 2007 SISO started revising the FEDEP. It has been renamed to Distributed Simulation Engineering and Execution Process (DSEEP) and is now an active standard IEEE 1730–2010 (instead of IEEE 1516.3).

Standards

HLA is defined under IEEE Standard 1516:

Machine-readable parts of the standard, 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.

Previous version:

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

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

DLC API

SISO has developed a complementary HLA API specification known as the Dynamic Link Compatible (DLC) API for the IEEE 1516-2000 version of HLA. 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. Note that this API has since been superseded by the HLA Evolved APIs, informally known as Evolved DLC APIs (EDLC).

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:

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

Disadvantages

HLA is defined 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.

See also

References

  1. ↑ Knight, Pamela; Corder, Aaron; Liedel, Ron; Giddens, Jessica; Drake, Ray; Jenkins, Carol; Agarwal, Paul (October 2002). "Evaluation of Run Time Infrastructure (RTI) Implementations" (PDF). The Journal of Defense Modeling and Simulation: Applications, Methodology, Technology (Society for Modeling and Simulation International). Retrieved 3 March 2015.
  2. ↑ Fujimoto, Richard. "The High Level Architecture: Introduction" (PDF). Retrieved March 3, 2015.
  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. ↑ BOM info
  5. ↑ "High Level Architecture STANAG Development (MSG-033)". Retrieved March 3, 2015.
  6. ↑ SISO-STD-004-2004
  7. ↑ SISO-STD-004.1–2004
  8. ↑ Doshi, Rajiv; Castellote, Gerardo-Pardo (2006). "A Comparison of HLA and DDS" (PDF). Real-Time Innovations. Retrieved March 3, 2015.

External links

This article is issued from Wikipedia - version of the Tuesday, May 03, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.