High Level Architecture

From Wikipedia, the free encyclopedia
  (Redirected from High-level architecture)
Jump to navigation Jump to search

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[3], which specifies ten architectural rules that the components or the entire federation shall adhere to.
  2. IEEE Std 1516.1-2010 Federate Interface Specification[4], 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 [5],which specifies the format that HLA object models, such as the FOM, shall use.


History and versions[edit]

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[edit]

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[edit]

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)[edit]

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[3]
  • IEEE 1516.1–2010 – Standard for Modeling and Simulation High Level Architecture – Federate Interface Specification[4]
  • IEEE 1516.2-2010 – Standard for Modeling and Simulation High Level Architecture – Object Model Template (OMT) Specification[5]

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)[edit]

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

Technical overview[edit]

The HLA standard consists of three parts:

  • Framework and Rules, which specifies ten architectural rules that federates or the entire federation shall adhere to.
  • 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.
  • Object Model Template Specification which specifies the format that HLA object models, such as the FOM, shall use.

Common HLA terminology[edit]

  • Run-time Infrastructure (RTI): Software that provides a standardized set of services, as specified in the HLA Federate Interface Specification. There are seven service groups.
  • Federate: A system, such as a simulation, a tool or an interface to live systems, that connects to the RTI. Examples of tools are data loggers and management tools. A federate uses the RTI services to exchange data and synchronize with other federates.
  • Federation: A set of federates that connect to the same RTI together with a common FOM.
  • Federation Execution: A session, where a set of federates execute together in a federation with a specific objective, using the same RTI and FOM.
  • Federation Object Model (FOM): A document that specifies object classes, interaction classes, data types and additional data that is used for the information exchange in a federation. A FOM is an XML file that follows the format of the HLA Object Model Template and the associated XML Schema. Different FOMs are used for exchanging data for different application domains. There are standardized FOMs, called reference FOMs, that are commonly used as a starting point for FOM development. A FOM can be developed and extended in a modular way using FOM modules.
  • Simulation Object Model (SOM): A document that specifies object classes, interaction classes, data types and additional data that a particular simulation publishes and/or subscribes to in a federation. A SOM is also an XML file that follows the format of the HLA Object Model Template and the associated XML Schema. SOMs can also be developed and extended in a modular way using SOM modules.
  • Object: Objects are used to represent data that is persistent over some period of time and that have attributes that can be updated. They are defined in the FOM/SOM using an Object Class.
  • Interaction: Interaction are used to represent instantaneous events with parameters. An interaction that has been sent cannot be updated (as opposed to object classes). They are defined in the FOM/SOM using an Interaction Class.
  • Datatypes: The representation and interpretation of attribute and parameter data is specified in the FOM/SOM using HLA Datatypes.
  • Publish: A federate that publishes an object class with a set of attributes can register and delete instances of that object class and update its attribute values. A federate that publishes an interaction class can send interactions of that interaction class, together with associated parameter values.
  • Subscribe: A federate that subscribes to an object class with a set of attributes will discover registrations and deletions of instances of that object class and receive updates of subscribed attributes. A federate that subscribes to an interaction class will receive interactions of that interaction class, together with associated parameter values.

Interface specification[edit]

The RTI services are defined in the HLA Interface Specification. They are grouped into seven service groups. In addition to these services, the Management Object Model (MOM) provides services that makes it possible to inspect and adjust the state of the federation programmatically.

Most RTIs consist of a Central RTI Component (CRC), which is an executable and Local RTI Components (LRCs), which are libraries that are used by the federates. Services are provided through a C++ or Java API and also using Web services. In the C++ and Java APIs, services are invoked using calls to an instance of the RTI Ambassador class. The RTI delivers information to a federate using callbacks, which are delivered using calls to an instance of the Federate Ambassador class. In the Web Services API, defined using WSDL, calls are made, and callbacks are fetched, by the federate using Web Services requests and responses.

The service group descriptions below focus on key services. Exceptions and advisories are not included.

Federation Management Services[edit]

The purpose of Federation Management services is to manage Federation Executions as well as federation-wide operations such as Synchronization Points and Save/Restore.

One set of Federation Management services manages the connection to the RTI, the federation execution and the set of joined federates. Key services are:

  • Connect and Disconnect from the RTI
  • CreateFederationExecution and DestroyFederationExecution that are used to create and destroy a federation execution
  • JoinFederationExecution and ResignFederationExecution that are used by a federate to join and resign a federation execution.
  • ConnectionLost, that is used by the RTI to inform a federate that it has lost its connection to the federation execution due to a fault
  • ListFederationExecutions that is used to retrieve a list of available federation executions for an RTI

Another set of services relates to synchronization points. These are federation-wide events where all, or selected federates are required to complete an operation, such as initializing a scenario, before the execution can continue. Key services are:

  • RegisterFederationSynchronizationPoint that is used to register a synchronization point
  • AnnounceSynchronizationPoint that is used by the RTI to inform federates that a synchronization point has been registered
  • SynchronizationPointAchieved that is used by a federate to indicate that it has achieved a synchronization point
  • FederationSynchronized that is used by the RTI to Inform federates that the federation is synchronized, i.e. all federates have achieved the synchronization point.

Yet another set of service relates to saving and restoring a federation execution. A save operation requires both the RTI and each federate to perform a save of their internal state. A restore operation requires both the RTI and each federate to perform a restore of their internal state. Key services are:

Save:

  • RequestFederationSave that is used to initiate a save of a federation
  • InitiateFederateSave that is used by the RTI to notify federates to start saving its state
  • FederateSaveComplete that shall be called by a federate when it has completed saving its state.
  • FederationSaved that is used by the RTI to notify federates that the federation is saved

Restore:

  • RequestFederationRestore that is used to initiate a restore of a federation
  • InitiateFederateRestore that is used by the RTI to notify federates to start restoring its state
  • FederateRestoreComplete that shall be called by a federate when it has completed restoring its state.
  • FederationRestored that is used by the RTI to notify federates that the federation is restored

Declaration Management Services[edit]

The purpose of Declaration Management services is to enable federates to declare what information they wish to publish (send) and subscribe to (receive) based on object and interaction classes in the FOM. The RTI uses this information to route updates and interactions to subscribing federates. For an object class, publishing and subscribing are performed for a specific set of attributes. For interaction classes, the entire interaction, including all parameters, is published and subscribed. Key services are:

  • PublishObjectClassAttributes that is used to publish a set of attributes for a given object class.
  • SubscribeObjectClassAttributes that is used to subscribe to a set of attributes for a given object class.
  • PublishInteractionClass that is used to publish an interaction class including all parameters
  • SubscribeInteractionClass that is used to subscribe to an interaction class including all parameters

Object Management Services[edit]

The purpose of Object Management services is to enable federates to share information about object instances and to exchange interactions.

Object instance names can be reserved or be automatically generated. Federates can register object instances of specified object classes, that are then discovered by subscribing federates. Attributes of these object instances can be updated. These updates will be reflected to subscribing federates. Interactions can be sent. These interactions will be delivered to subscribing federates. Key services are:

Objects:

  • ReserveObjectInstanceName that is used to reserve a name to be used for an object instance
  • RegisterObjectInstance that is used to register an object instance of a particular object class, either with a reserved name or an automatically generated name.
  • DiscoverObjectInstance that is used by the RTI to notify federates subscribing to particular object class that a new object instance has been registered.
  • DeleteObjectInstance that is used to delete an object instance
  • RemoveObjectInstances that is used by the RTI to notify federates that an object instance has been removed

Attributes:

  • UpdateAttributeValues that is used to provide updated attribute values for an object instance
  • ReflectAttributeValues that is used by the RTI to notify federates subscribing to particular attributes of updated values.

Interactions:

  • SendInteraction that is used to send an interaction of a particular interaction class, including parameter values.
  • ReceiveInteraction that is used by the RTI to deliver an interaction, including parameter values, to federates subscribing to a particular interaction class

Ownership Management Services[edit]

The purpose of Ownership Management services is to dynamically manage what federate that simulates what aspect of an object instance. In HLA, only one federate is allowed to update a given attribute of a given object instance. That federate is considered the owner of the attribute. A federate that registers a new object instance will automatically be the owner of all attributes it publishes. In some cases, attributes of an object instance may become unowned, i.e. not owned by any federate.

Ownership management provides services for transferring ownership of one or several attributes at runtime, which can include a federate Divesting the attribute and another federate Acquiring the attribute. There are two main patterns: “pull” that are initiated by the acquiring federate and “push” that are initiated by the divesting federate.

Key services for initiating “pull” ownership are:

  • AttributeOwnershipAcquisitionIfAvailable which is used by a federate that wishes to acquire ownership of unowned attributes.
  • AttributeOwnershipAcquisition which is used by a federate that wishes to request ownership of a potentially owned attribute

Key services for initiating “push” ownership are:

  • AttributeOwnershipDivestitureIfWanted which is used by a federate that wishes to divest attributes only if there is some other federate that is standing by to acquire ownership of these attributes.
  • NegotiatedAttributeOwnershipDivestiture, which is similar but may also cause the RTI to try to find a new owner.
  • UnconditionalAttributeOwnershipDivestiture, which is used by a federate that wishes to give up ownership, even if no new owner can be found.

All object instances have a predefined attribute called HLAPrivilegeToDeleteObject. Only the owner of this attribute for an object instance is allowed to delete the object instance. Ownership of this attribute can be transferred at runtime using the above operations.

Time Management Services[edit]

The information exchange in an HLA federation takes place in real-time with immediate (Receive Order, RO) delivery of messages, unless HLA Time Management has been enabled. The purpose of HLA Time Management is to guarantee causality and a correct and consistent exchange of time stamped messages (updates and interactions) in Time Stamp Order (TSO), no matter if the federation executes in real-time, faster-than-real-time, slower-than-real-time or as-fast-as-possible.

Some important concepts in HLA Time Management are:

Logical time: A time axis in HLA, starting at zero. Logical time is used for Time Management timestamps and operations. The logical time axis can be mapped to the scenario time of the federation. An example of such a mapping is to let zero represent the scenario time 8:00 of the 1-Jan-1066 and let an increment by one represent one second of the scenario.

Lookahead: A time interval specifying the lowest time in the future for which a federate will produce messages. For a federate with a fixed time step, this is usually the length of the time step.

Granted: A federate is granted (allowed to advance) to a particular logical time by the RTI, when all time-stamped messages up to that time have been delivered. The federate can then safely start calculating messages with a timestamp in the future. This timestamp may not be earlier than the granted time plus the federates lookahead.

Advancing: When a federate has finished producing data for the granted time plus the lookahead, it may request to be advanced to a later time, which also means that it promises not to produce any more messages with a time stamp less than the requested time plus the lookahead. The federate is now in the advancing state.

Time Regulating: A federate that sends time stamped events is considered Time Regulating since the time advance by other federates may be regulated by this.

Time Constrained: A federate that receives time managed events is considered Time Constrained since the reception of time stamped messages, constrains its time advance.

The main principles of HLA Time Management are that:

  • Each federate assigns a time stamp to messages (updates and interactions) when they are sent, indicating for which scenario time the message is valid.
  • Federates request permission from the RTI to advance their time.
  • The RTI manages delivery of messages and grants federates time advance so that messages are delivered in Time Stamp Order and that federates don’t get any messages with a time stamp in their past.

Example of Lookahead, granted and advancing:

  1. A federate uses a fixed time step of 10 and has a Lookahead of 10.
  2. The federate is granted to logical time 50 by the RTI. The RTI thus guarantees that all messages with time step less or equal to 50 have been delivered to the federate.
  3. The federate now has all the necessary data to correctly calculate and send messages for the granted time plus Lookahead, i.e. 60.
  4. When the federate has sent all messages with timestamp 60, it requests to be advanced to time 60. It thereby promises not to send any messages with a timestamp less than 70.
  5. The RTI delivers all messages with timestamp less or equal to 60 to the federate. It then grants the federate to time 60.
  6. Etc

If at least one federate in the federation performs pacing, i.e. correlates their time advance requests with a real time clock, the federation may run in real time or scaled real time. Without pacing, the federation will run as fast as possible, which is used for example in Monte Carlo simulation.

Key services include:

  • EnableTimeConstrained and EnableTimeRegulating that enables theses modes for a federate
  • TimeAdvanceRequest whereby a federate requests to be advanced to a specified logical time
  • TimeAdvancedGrant whereby the RTI informs a federate that it is granted to a specified logical time.
  • EnableAsynchronousDelivery that enables delivery of Receive Order messages both when a federate is in the granted and advancing state.

For event driven simulation it is also possible for a federate to request to be advanced to the next event using the following service:

  • NextMessageRequest whereby a federate requests to be advanced to the timestamp of the next message due for delivery to the federate, or a specified logical time, whichever has a lower timestamp.

Another important concept is Greatest Available Logical Time (GALT). The greatest time that each federate can be granted to, depends on the time that other federates have been granted to as well as their lookahead. The GALT for a federate specifies how far a federate can be granted, without having to wait for other federates to be granted. This is particularly interesting for a federate that joins late into a time managed federation.

Key services for GALT are:

  • QueryGALT that returns the GALT for the calling federate.

More advanced services include:

  • FlushQueueRequest whereby a federate can request delivery of all queued, timestamped messages, no matter how far in the future their timestamp is.
  • Retract whereby a federate can request that an already sent message is retracted. This is useful in optimistic simulation.

Data Distribution Management Services[edit]

Support services[edit]

Management Object Model[edit]

Object model template[edit]

Federation Conformance[edit]

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[edit]

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[edit]

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

  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[edit]

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[edit]

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

Base Object Model[edit]

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

Alternatives and Disadvantages[edit]

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

Alternatives[edit]

In regards to the Distributed Modeling and Simulation (DM&S) industry the most often used alternative to the HLA is 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 having an open on-the-wire protocol for system interoperability.[9]

Disadvantages[edit]

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

See also[edit]

References[edit]

  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. ^ a b IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA)— Framework and Rules. IEEE Computer Society. 18 August 2010. ISBN 978-0-7381-6251-5.
  4. ^ a b IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA)— Federate Interface Specification. IEEE Computer Society. 18 August 2010. ISBN 978-0-7381-6247-8.
  5. ^ a b IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA)— Object Model Template (OMT) Specification. IEEE Computer Society. 18 August 2010. ISBN 978-0-7381-6249-2.
  6. ^ U.S. Defense Modeling and Simulation Office (2001). RTI 1.3-Next Generation Programmer's Guide Version 4. U.S. Department of Defense.
  7. ^ "High Level Architecture STANAG Development (MSG-033)". Retrieved March 3, 2015.
  8. ^ SISO BOM Standard
  9. ^ Doshi, Rajiv; Castellote, Gerardo-Pardo (2006). "A Comparison of HLA and DDS" (PDF). Real-Time Innovations. Retrieved March 3, 2015. Cite journal requires |journal= (help)
  10. ^ Granowetter, Len. "RTI Interoperability Issues - API Standards, Wire Standards, and RTI Bridges". Retrieved 14 March 2018.

External links[edit]