1. Katherine L. Morse, PhD JHU/APL 9 October 2015
Live-Virtual-Constructive (LVC) Technologies – High Level Architecture (HLA)
Katherine L. Morse, PhD
JHU/APL
9 October 2015
This LVC technologies class is on the High Level Architecture or HLA. HLA is the leading standard for distributed simulation. It was started in the early 1990s and is now in its third revision. It is an IEEE standard: IEEE , , , and is also the subject of a NATO standards agreement (STANAG). It has broad simulation functionality and many implementations provided through an open ecosystem of suppliers. It is in use in more than 40 nations for defense simulation and increasingly in civil applications.
Thanks to Björn Möller of Pitch Technologies for his contributions to the contents of some of the slides in this class that were developed over many years of teaching HLA tutorials together.

2. HLA Purpose
Standardized, functional simulation interoperability architecture.
Applicable to:
Broad range of functional areas, e.g. training, logistics planning, analysis, and simulation-based acquisition.
All permutations of LVC.
Real time and time managed.
Implementable through multiple physical architectures.
The HLA was designed to be a standardized, functional simulation interoperability architecture. Because it is a functional architecture rather than a protocol, it may be implemented through multiple physical architectures, and it has been and continues to be. This architecture is applicable to a broad range of functional areas that includes all permutations of live, virtual, and constructive. This includes both real time simulations, those that operate on wall clock time, and time managed simulations, those that run faster or slower than wall clock time.
One of the key questions asked when developing an LVC environment is whether to use the High Level Architecture (HLA) or DIS. Some general guidance for this question:
If the development is new, consider HLA first because it offers many more features for controlling simulation execution and data filtering.
If the project is integrating with an existing LVC environment using HLA, give preference to also using HLA because this choice will maximize interoperability with the other simulations using HLA in the existing LVC environment.
If the project is integrating with an existing LVC environment using DIS exclusively, then choose DIS because the additional HLA features will go unused and integration will require the additional development or integration of a gateway.
For more detailed guidance, see the Distributed Simulation Engineering and Execution Process (DSEEP), activity Design Simulation Environment, which states, “A fundamental design choice for any distributed simulation environment is the underlying simulation architecture (e.g., HLA, DIS,..” The DSEEP Multi-Architecture Overlay provides amplifying guidance on performing this task for multi-architecture LVC environments.

3. HLA Technical Overview
Federate A
Federate B
Federate C
Federation Object Model
<FOM>
<Shared object classes>
<Shared interaction classes>
<More>
</FOM>
Runtime Infrastructure (RTI)
Each participating member is called a federate.
Information is exchanged using a Runtime Infrastructure (RTI).
The information exchange follows a Federation Object Model (FOM).
The participating federates together with the FOM and RTI are called a federation.
This diagram is typically referred to as a “lollipop diagram.” It represents a canonical, logical HLA federation. Each participating member application is called a federate. The term “federate” is used rather than “simulation” because some federates may perform non-simulation functions. For example, a federate may be a map view display, a data logger, a management tool, or a mission command system interface among others. Information is exchanged between the federates over the Runtime Infrastructure (RTI). The RTI can be thought of as an information bus. The information to be exchanged through the RTI must be described in terms of a federation object model (FOM). The FOM describes the structure and data types for the information to be exchanged, but not the actual data. The FOM is specified using an XML schema. The participating federates together with their FOM and the RTI are called a federation.

4. Publish-Subscribe Design Pattern
In software architecture, publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers. Instead, published messages are characterized into classes, without knowledge of what, if any, subscribers there may be. Similarly, subscribers express interest in one or more classes, and only receive messages that are of interest, without knowledge of what, if any, publishers there are. [Wikipedia]
One of the keys to the HLA’s flexible interoperability and reuse is the application of the publish-subscribe design pattern. In this design pattern, message senders describe the types of data are capable of sending to some piece of infrastructure or middleware software. Analogously, message receivers describe the types of data they wish to receive. The infrastructure is responsible for matching publication and subscription requests. Based on matching requests, the infrastructure routes messages appropriately. This design pattern allows publishers and subscribers to join and leave a software architecture without impact to other members. It also means that publishers and subscribers don’t have to know about each other or connect directly to each other. In the HLA, the format of the data that can be published and subscribed is defined in the FOM.
The HLA uses the publish-subscribe design pattern to exchange data defined in the FOM between federates.

5. Objects vs. Interactions
The HLA shares data between federates via two mechanisms:
Objects
Persistent.
Usually represent long-lived entities in the federation.
State is represented by attributes.
State can be partially updated by owning federate.
Interactions
Not persistent.
Usually represent events in the federation.
State is represented by parameters.
Full state must be sent in the interaction.
The HLA shares data between federates using two mechanisms, objects and interactions. The primary difference between the two is that objects persist throughout some period of federation execution, while interactions represent instantaneous events. A federation’s allowable objects and interactions are described in its FOM. The details of objects are defined in their attributes; for interactions, their details are defined in their parameters. Attributes and parameters are technically similar in how they’re described and in terms of the data types they use. The HLA uses the different terms attributes and parameters to clearly differentiate when the standard is discussing objects versus interactions.
The examples on this slide are from SISO-STD Real-time Platform Reference Federation Object Model (RPR FOM) V2 [

6. Federate vs Federation View of the Simulated World
Federates model the simulated world internally.
The FOM is a model of the data federates must exchange to maintain the federation’s shared representation of the simulated world.
The federates’ internal model and the federation model of the simulated world may differ.
It is the responsibility of the federates to translate between object attribute updates and interactions received from the federation via the RTI and their internal representations.
And respond accordingly to this input.
Individual federates have different views of the simulated world being represented by federation. And, by extension, the true state of the simulated world being represented by the federation can only be seen through the collective, shared view the federates have of it. Federates have two perspectives on the simulated world. They have their internal, usually detailed, model. Their external view is composed of the data they receive from other federates via the RTI. Note that the data that a federate shares through the RTI may be less detailed or in another format than the data it maintains internally. By extension, this means that the data it receives from the RTI may also not be a completely accurate representation of the internal state of the other federates that sent the data.

7. Structure of the Formal Standard
Because HLA is a functional architecture, not a specific solution implementation, the “components” are the documents of the standard:
HLA Framework and Rules – For the federation and the federates.
HLA Federate Interface Specification – A standardized set of services for interoperability.
Also in C++, Java and Web Services format.
To be implemented in an RTI.
HLA Object Model Template – A standardized format for Information Exchange Data Model.
Because the HLA is a functional architecture, not a specific solution implementation, the components of the standard are documents. The first document is the HLA rules which specifies five rules for the behavior of federations and five rules for the behavior of federates. The HLA Federate Interface Specification, often referred to as the I/F spec, describes a standardized set of services for interoperability, i.e. the services used to exchange data between the federates. These are the services that are implemented by RTIs. In addition to the functional description of each of the services, the I/F spec includes technical interfaces for C++, Java, and web services, i.e. web service definition language (WSDL).

8. HLA Framework and Rules
5 Rules for Federations
Focused on transmission of data through the RTI and time management.
5 Rules for Federates
Focused on adhering to federate Simulation Object Models (SOMs), the federates’ “contract” with the federation.
The five rules for HLA federations are focused on the transmission of data through the RTI and time management. The five rules for federates are focused on adhering to federate simulation object models which are the federates’ contract with the federation. The next two slides show the actual content of the rules.

9. HLA 1516 Framework and Rules
5 Rules for Federations
Federations shall have an HLA Federation Object Model (FOM), documented in accordance with the HLA Object Model Template (OMT).
In a federation, all simulation-associated object instance representation shall be in the federates, not in the runtime infrastructure (RTI).
During a federation execution, all exchange of FOM data among federates shall occur via the RTI.
During a federation execution, federates shall interact with the RTI in accordance with the HLA interface specification.
During a federation execution, an instance attribute shall be owned by at most one federate at any given time.
The five rules for federations ensure the proper operation of a federation. Some of these rules are effectively enforced by the RTI. For example, if the federation does not have a FOM documented in accordance with the HLA object model template, an RTI will not allow a valid federation to be created. This rule ensures that RTIs are simulation independent. If the simulation associated object instance representations are in the federates and not in the RTI, then the RTI is usable for all types of simulations. Rule three ensures that federation data will be where the federates expect it to be. If data were described in the FOM, but sent through some other channel than the RTI, federates expecting to receive that data through the RTI would not receive it. As a result, they would not operate properly. This is not to say that a federation cannot have other communication channels, just that all data specified in the FOM must be exchanged through the RTI. Rule four requires that federates interact with the RTI in accordance with the HLA interface specification. In practice, most of this interaction is enforced by the RTI through the use of exceptions as will be illustrated in the next section on the Interface Specification. Rule five is also effectively enforced by the RTI; an exception will be thrown by the RTI if an attempt is made by a federate to gain ownership of an instance attribute owned by another federate.

10. HLA 1516 Framework and Rules
5 Rules for Federates
Federates shall have an HLA Simulation Object Model (SOM), documented in accordance with the HLA Object Model Template (OMT).
Federates shall be able to update and/or reflect any attributes and send and/or receive interactions, as specified in their SOMs.
Federates shall be able to transfer and/or accept ownership of attributes dynamically during a federation execution, as specified in their SOMs.
Federates shall be able to vary the conditions (e.g., thresholds) under which they provide updates of attributes, as specified in their SOMs.
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.
The essence of the five rules for federates focus on what is described in a federate’s simulation object model (SOM). A SOM is analogous to a FOM, but it only describes the data that an individual federate can send and receive. In practice, many federates do not have a SOM per se. Many federates simply adopt a well-known, broadly-used FOM. These rules do not imply that all federates must have all of the capabilities described in the I/F spec, but they must be able to perform all the functions that they claim to perform. This includes functions such as managing time within the federate and responding to callbacks from the RTI to vary the federate’s conditions or switches.

11. Object Models and the OMT
Object Model Template (OMT)
Provides a common framework for HLA object model documentation.
Prescribes the format for defining the types of data to be shared in the federation, but not the instances.
Federation Object Model (FOM)
A description of all shared information (objects, attributes, and interactions) essential to a particular federation.
Simulation Object Model (SOM)
Describes objects, attributes and interactions in a particular federate that can be used externally in a federation.
In practice, many federates use the FOM of the federation in which they regularly participate as their SOM.
The preceding slides have covered sending and receiving data. It’s important to remember that all of the types of data sent and received via the RTI are specified using the third specification in the HLA standard, the Object Model Template (OMT). The OMT provides a common framework for documenting HLA object models. Recall that this defines the types of data to be shared, but not the instances. The FOM for any federation is a description of all shared information required for that federation. As described earlier, an individual federate may have a SOM, but in practice many federates use the FOM of the federation in which they regularly participate as their SOM.

12. HLA Object Model Example
Object classes
Derived object classes
Object class attributes
This slide provides a visual illustration of some object classes from a common FOM, the RPR FOM that represents the translation of DIS PDUs to HLA. The OMT implements single inheritance; an object class or interaction class may be derived from another such class. A derived class inherits all the attributes of the class from which it’s derived.

13. HLA Federate Interface Specification
This document defines the service interface between federates (simulations, supporting utilities, or interfaces to live systems) and the RTIs that supports inter-federate communication.
Federate developers and federation engineers select the (subset of) services that meet the requirements of their federation.
The I/F spec defines the service interface between federates and the RTIs that support inter-federate communication. It’s very important to understand that the I/F spec is a functional specification; it defines the functions that must be implemented by an RTI, but not how they are implemented. In order for an RTI to be certified as compliant with a version of the HLA standard, it must accurately implement all of the services in the I/F spec. From the perspective of federate developers and federation engineers, the I/F spec represents services that may be selected to meet the requirements of their federation. Because the HLA was designed to support so many different types of federations, it’s not expected that any federation will use all of the services, but rather will select a subset of services that meet the federation requirements.

14. HLA I/F Spec Service Groups
Federation Management (31 services)
Declaration Management (12 services)
Object Management (20 services)
Ownership Management (18 services)
Time Management (23 services)
Data Distribution Management (12 services)
The Interface Specification also includes:
Support services (43 services)
Management Object Model and MOM Initialization Module
Programming language mappings
FOM Document Data (FDD) XML Schema Declaration
Application Programmers Interfaces (APIs) in C++, Java, and WSDL
The I/F spec is organized in service groups. There are six major groups of services as identified on this slide. The first three groups, federation management, declaration management, and object management, are often referred to as the “big three.” This is because they are required in order to build a federation that provides meaningful functionality. It is entirely possible to build many federations with just these three service groups, not using ownership management, time management, and data distribution management services, and many have been. Additionally, the I/F spec includes support services for simple functions like translation of strings to handles. It includes the Management Object Model (MOM) which is the object model for the RTI. The MOM provides a standard interface to the RTI for the purpose of getting information about how the federation is running. It is most commonly used to build tools such as federation management tools. The next set of slides describes the types of functions in each of the service groups.

15. Federation Management
Coordinate federation-wide activities throughout the life of a federation execution.
Connecting and disconnecting from RTI.
Creation and destruction of a federation execution.
Joining and resigning of a federate to a federation execution.
Coordination of federation synchronization points.
Coordination of federation Save and Restore.
Federation management is the one set of services absolutely required to build a federation. Federation management contains the services that coordinate federation wide activities throughout the life of the federation execution. This includes connecting and disconnecting from the RTI, creating and destroying a federation execution, and joining and resigning from the federation execution. It is typically feasible to create a valid federation execution using just federation management services, but that federation would not be able to exchange data. The next two slides explain how to use declaration management and object management to do so. Federation management also includes functions for synchronization points which are typically used to coordinate all federates in a federation reaching a pre-specified state of execution, for example successfully completing initialization. This is also where the coordination of federation save and restore is managed. Note that this is only the coordination, not the actual save and restore. Because the HLA rules specify that all simulation data has to be in the federates, the federates are responsible for actually saving and restoring the state of the federation. The RTI is responsible for coordinating that activity.

16. Declaration Management
Allow federates to specify the types of data they will send or receive by object class and attribute name and by interaction class from the FOM.
Interface functions include specification of:
Types of data to be sent (publication):
Object classes and attributes and interaction classes that the federate is able to update or send.
Types of data to be received (subscription):
Object class attributes and interaction classes that the federate is interested in receiving.
Rate at which the federate is interested in receiving data.
Notifications to federates of relevance of object and interaction classes within the federation:
Feedback to the federates from the RTI when registration of instance objects and sending of interactions should start or stop based on the subscriptions of other federates to those classes.
Declaration management allows federates to specify the types of data to send or receive through the RTI. HLA uses a publish – subscribe design pattern. This means that federates tell the RTI what types of data they will produce (publish) and wish to receive (subscribe). All of the types of data described in publication and subscription requests to the RTI must be in the FOM. The HLA has two basic types of data that it exchanges: object class attributes and interactions. Object are used to represent entities in the federation that persist over time, e.g. real-world objects such as people and war fighting platforms. Interactions are used to represent instantaneous, non-persistent events such as radio transmissions or weapons fire. Newer versions of the HLA standard include features for controlling the rate at which federates may receive data. These features are part of an overall approach to reduce the amount of extraneous data sent over the network and processed by federates. This is also the purpose of the types of services described in the last sub bullet by which federates receive feedback from the RTI indicating that some data is not currently needed by the federation and does not need to be produced.

17. Object Management
Supports life cycle activities of object and interactions.
Supports creation, modification, and deletion of object instances and their attributes, and sending and receiving interactions.
Interface functions include:
Registering and discovering object instances.
Updating and reflecting object instance attributes.
Sending and receiving interactions.
Deleting and removing object instances.
Changing default transportation preferences of instance attributes.
Notification of in-scope and out-of-scope instance attributes.
Requests for instance attribute value updates.
Notifications to federates to start/stop updating instance attributes.
Feedback to the federates from the RTI when attribute updates for a particular object instance should or should not be provided and at what rate, given the relevance of those instance attributes to other federates.
The final group of services in the big three is object management. Using federation management and declaration management, a valid federation can be created and federates can describe the type of data they will send and wish to receive, but no actual data can be exchanged using those services. Data is exchanged in an HLA federation using object management services. Object management includes the services for creating, modifying and deleting object instances and their attributes. It also includes sending and receiving interactions. The individual data elements of object instances are called attributes. The individual data elements of interactions are called parameters. This difference in terminology is used to make clear the distinction between objects and interactions when describing data exchange. One other key difference between objects and interactions is that objects are created and registered before their attributes are shared with the rest of the federation. This enables federates representing remote objects to create and maintain the data structures necessary to model that remote state. Because interactions are instantaneous and do not persist, there is no reason to notify other federates of their impending receipt. Additionally, because interactions are only sent once, all of the parameters of an interaction must be sent with the interaction. On the other hand, only the attributes of an object that have changed need to be updated. This is another case where the RTI is designed to minimize the sending and receiving of unnecessary data; there is no need to send the value of attributes that have not changed since the last update.

18. Ownership Management
Ownership is the privilege to provide a value for an object instance attribute.
Ownership Management services facilitate dynamic transfer of ownership.
Federates transfer ownership based on federation execution design plans.
RTI arbitrates transactions so that ownership is held by at most one federate at any time.
Offers both ‘push’ or ‘pull’ based transactions.
Acquisition requires current publication for class attribute.
Interface services include:
Attribute Ownership Divestiture.
Attribute Ownership Acquisition.
Query Attribute Ownership.
Ownership is defined as the privilege to provide a value for an object instance attribute. The ownership management services facilitate the dynamic transfer of ownership between federates. There are both push and pull methods for transferring ownership as arbitrated by the RTI. The RTI performs this function in order to enforce the rule that ownership is held by at most one federate at any time. Ownership transfer can also be unconditional or negotiated. Although ownership management is not frequently used, there are circumstances where it is valuable for accurate modeling. For example, in a joint federation, a Marine Corps aircraft being simulated constructively is dynamically re-tasked to support the Army area of responsibility being represented by an Army simulation.  In this case, it makes sense to transfer ownership of the aircraft to the Army simulation and only return it to the Marine Corps simulation once it has completed its mission.

19. Time Management Control advancement of each federate’s logical time.
Coordinated with object management services to support Timestamp Ordered Delivery (causal behavior) across the federation if desired.
Designed to support federates with different message ordering requirements.
Interface functions include:
Enable / Disable Time Regulation and/or Time Constrained
Query RTI for current values of time.
Time Advance Request, Next Message Request, Flush Queue Request, Time Advance Grant, and Retract services.
Modification of default ordering type for Object instance attributes.
Not all federations operate in real time or wall clock time. Some federations must run faster or slower than real-time. These federations will need to use time management services. Time management is also applicable to federations that require strict message ordering, usually in order to achieve repeatable causality. The HLA time management services are designed to support federates with different message ordering requirements even within the same federation. A federate that sends out time-stamped attribute updates and interactions is referred to as time regulating. A federate that receives time-stamped interactions and object class attribute updates, and modifies its behavior accordingly is called time constrained. The time management services include the functions necessary to enable and disable time regulation and time constraint, as well as all of the functions necessary to control the advancement of logical time and the delivery messages at the correct logical time.

20. Data Distribution Management (DDM)
Allow federates to specify the distribution conditions for the specific data they send or ask to receive.
RTI uses this information to route data from producers to consumers based on DDM declarations.
Not bound by FOM, data distribution can be managed based on other characteristics of objects important to particular federation execution.
Federation design creates dimensions for use during runtime; these are specified at federation creation time in the Federation Document Data (FDD) file.
Interface functions include:
Create, modify and delete regions.
Associate/unassociated regions with specific instance attributes.
Register Object instance attributes with regions.
Send interaction with regions.
Change the range within a dimension.
The final major service group in the I/F spec is data distribution management. As we have seen in the preceding slides, the HLA has many mechanisms for controlling the sending and receiving of extraneous data. DDM is the most detailed level of filtering provided by the HLA. It allows federates to specify the distribution conditions for the specific data they send or ask to receive. Unlike the other mechanisms for controlling data flow, the DDM mechanisms are not bound to the FOM. DDM uses separate characteristics or functions to further filter data. DDM does this by creating logical dimensions and specifying regions within those logical dimensions. If these regions overlap between sending and receiving federates, the data of interest is delivered to the subscribing federate. One of the most typical applications of DDM is geographic filtering. For example, a subscribing federate might define a region that represents the range of a sensor it models. Using this subscription region, the RTI will limit the delivery of data to the subscribing federate to data about objects or interactions that are within the range of that sensor. Another common example is defining a dimension that represents radio frequencies. Using this dimension, a federate representing a radio would set its region on the frequency dimension to the frequency to which the radio is tuned, ensuring that it only receives radio transmissions that were sent on that frequency.

21. DDM Radio Frequency Example
30 MHz
512 MHz
Frequency dimension
Update Region
Subscription Region
Because the update and subscription regions overlap in the frequency dimension, the subscribing “radio” will receive the ApplicationSpecificRadioSignal interaction.
This is a simple example of DDM using a single dimension, radio frequency. The dimension itself goes from 30 MHz to 512 MHz The radio on the left is tuned to a frequency between 30 and 90 MHz So, its federate has created an update region that spans those frequencies for the purpose of sending ApplicationSpecificRadioSignal interactions, illustrated in the middle of the slide. The radio on the right is tuned to a frequency between 60 and 120 MHz So, its federate has created a subscription region that spans those frequencies for the purpose of receiving ApplicationSpecificRadioSignal interactions. Because the update and subscription regions overlap in the frequency dimension, any ApplicationSpecificRadioSignal interactions sent from the radio on the left will be routed to the radio on the right. Note that the frequency is not specified in the interaction’s parameters. The calculation of the update and subscription regions is external to the sending and receiving of interactions.
Image of Falcon II® AN/PRC-150(C) radio downloaded from

22. HLA Evolved New Major Feature Overview
Develop
Deploy
Net-Centric
Quality
FOM Modules X
Extensible XML Format for OMT
Schemas for OMT Compliance Testing
Federate Conformance in OMT
Encoding Helpers
Web Services (WSDL API)
Dynamic Link Compatibility
Standardized Time Types
Fault Tolerance
Smart Update Rate Reduction
Improved Support for Data Logging
Evolved Transportation Types
List Federation Executions
Explicit Connect Statement
Object names can be reused
DoD Interpretations
The 2010 version of IEEE 1516, , and is colloquially referred to as HLA Evolved. HLA Evolved includes many advanced features not available in the 2000 IEEE version of the standard nor the DoD version 1.3. This slide summarizes those features and categorizes them according to their impact on improved federation / federate development, deployment, net centricity, and general quality, e.g. error prevention and detection. Slide 30 contains a list of technical papers describing these features in detail and their development.

23. Overview of Federation Execution Lifecycle
Federate
RTI
Create Federation Execution
Join Federation Execution
Establish Initial Data Requirements
via Publish and Subscribe
Startup
Register Object Instances
Update Attribute Values
Discover Objects
Update/Reflect Attribute Values
Send/Receive Interactions
Register/Discover (Late) Objects
Advance Time Request/Grant
Delete/Remove Objects
Operations
Up to this point we have described the individual elements of an HLA federation and the services provided for its use. This slide illustrates at the highest level, the overview of a generic federation execution. Not all federation executions follow this pattern strictly, but most do so substantially. <Next> At startup, <Next> some federate creates the federation execution and all federates join. <Next> This is usually followed by a phase of establishing initial data requirements via publish and subscribe, <Next> and then the registration of object instances, their discovery by subscribing federates, and the update and reflection of initial attribute values. Many federations establish synchronization points during or at the end of the startup processes. This is usually the case because these initial activities may overload the network. The purpose of the synchronization point is to ensure all of these activities have occurred and the network is relatively clear. <Next> During the normal operations of the federation, <Next> attribute values are updated and reflected for objects, and interactions are sent and received. Late arriving or newly created objects may be registered and discovered. If the federation is using time management, federates may make requests to advance time and receive grants to advance logical time. If objects are logically destroyed or no longer part of the federation, the owning federate may delete them which will cause the RTI to notify other federates to remove their local representations of the objects. Federates may still continue to join and leave the federation throughout this phase. <Next> When the federation has finished simulating its intended scenario, federates resign from the federation execution <Next> and one of the federates should destroy the federation execution. While these steps are not absolutely necessary, they are important for consistent conclusion of federation execution. This is particularly important in simulation environments where an RTI may be supporting multiple federations simultaneously.
Resign Federation Execution
Shutdown
Destroy Federation Execution

24. Runtime Infrastructure
Communications Between a Federate and the RTI – Federation Save Example
Step 2
Initiate
Federate
Save †
Federate’s
Simulation Code
Ambassador
Class
Runtime Infrastructure
RTI
Step 1
Request
Federation
Save
Step 4
Saved †
Step 3
Save Complete
This is an example of how a federate communicates with the RTI. The HLA standard defines two important software classes required for federates to communicate with the RTI: the RTI ambassador class, through which federates communicate to the RTI, and the federate ambassador class, through which the RTI communicates back to the federates. The RTI ambassador class is fully implemented by the RTI. The federate ambassador class consists of stubs. It is the responsibility of the federate developer to connect the RTI callbacks to the code in the federate that responds to the callbacks. In this example, the federate on the right wants to request that the federation be saved, so it calls the RTI through the RTI ambassador class. In response to this, the RTI calls back all the federates in the federation and requests that they save their internal state. Recall that it is a rule that the state of the federation is maintained within the federates, not in the federation. This is why the RTI must request the federates save their individual state. Once each federate has finished saving its state, the RTI notifies the original requester that the federation has been saved through a call back via the federal ambassador class.

25. HLA Previous Uses / Applications
Individual training – NATO NIREUS.
Collective / unit training - Joint Live Virtual Constructive (JLVC) Federation, Navy Continuous Training Environment (NCTE).
Staff training - Joint Land Component Constructive Training Capability (JLCCTC) / Ulchi Freedom Guardian (UFG).
Acquisition – Future Combat Systems (FCS).
Analysis - Preparedness and Catastrophic Event Response (PACER) Bioterrorism Crisis Management Simulation.
Experimentation – Distributed Continuous Experimentation Environment (DCEE).
Versions of the HLA standard have been in use for two decades. During that time, hundreds of federations, and perhaps thousands of federation executions, have been created. This slide lists just a few different applications and domains.
These are just a few of the many applications of HLA.

26. HLA Supporting Technologies
Because HLA is a functional architecture, not a specific solution implementation, it is supported for many hardware / software / OS configurations.
Many government organizations and commercial vendors have products that are HLA-compliant:
RTIs
Object model development tools
Viewers
Loggers
Computer Generated Forces (CGF)
Because HLA is a functional architecture, not a specific implementation, it is supported for many hardware, software, and operating system configurations. Additionally, many government organizations and commercial vendors have products that are HLA-compliant including RTIs, object model development tools, viewers, loggers, and computer-generated forces, among others.

27. HLA Limitations Individual
With the conclusion of RTI certification testing, there is no guarantee that any RTI claiming to be compliant with the standard correctly implements all the required functionality.
Interoperability
HLA was designed to achieve technical (interface) interoperability, not semantic interoperability.
All federates must be running the same RTI because HLA is a functional interoperability architecture, not a wire protocol.
The HLA was designed to achieve technical interface interoperability, not semantic interoperability. Technical interoperability means that simulations can exchange data accurately, e.g. one federate sends an interaction using the HLA API and another federate that receives it via the HLA API accurately interprets the type of the interaction and the correct values of the parameters of the interaction. Semantic interoperability addresses the accuracy of the federates’ shared models of the simulated world and whether those models are consistent and valid. For example, just because two federates receive the same interactions about precipitation, doesn’t mean that they both calculate trafficability of soil during rain. So, even with the same accurate, valid input, they would have different internal models of the terrain and produce inconsistent results. These federates are technically interoperable, but not semantically interoperable. Semantic interoperability continues to be a significant technical challenge and an open research topic.
Additionally, because HLA is a functional interoperability architecture, not a wire protocol, all federates in a federation must be running the same RTI in order to interoperate. This includes not only an RTI from the same vendor, but potentially an RTI implementing the same version of the HLA standard. Some vendors offer interoperability between different versions of the standard within their product line. Generally, interoperability between different RTIs requires the introduction of gateways. For a discussion of gateways, see the LVC federation engineering class.

28. HLA POCs
HLA Simulation Interoperability Standards Organization (SISO) Product Support Group (PSG)

29. HLA References
IEEE Standard Framework and Rules, 18 August 2010
IEEE Standard Federate Interface Specification, 18 August 2010
IEEE Standard Object Model Template (OMT) Specification, 18 August 2010

30. HLA Evolved New Feature Papers
SISO Papers (
“Getting Started with FOM Modules”, 09F-SIW-082
“HLA Evolved – A Summary of Major Technical Improvements”, 08F-SIW-064
“Early Experiences from Migrating to the HLA Evolved C++ and Java APIs”, 09S-SIW-083
“Making Your BOMs and FOM Modules Play Together”, 07F-SIW-069
“Use Cases for the HLA Evolved Modular FOMs”, 07E-SIW-040
“An Overview of the HLA Evolved Modular FOMs”, 07S-SIW-108
“Developing Web Centric Federates and Federations using the HLA Evolved Web Services API”, 07S-SIW-107
“A Management Overview of the HLA Evolved Web Service API”, 06F-SIW-024
“A First Look at the HLA Evolved Web Service API”, 06E-SIW-061
“Reducing Integration Time and Risk with the HLA Evolved Encoding Helpers”, 06S-SIW-042
“Developing Well-Balanced Federations Using the HLA Evolved Smart Update Rate Reduction”, 05F-SIW-87
“Developing the Fault Tolerance Support Extensions for HLA Evolved”, 05E-SIW-019
”Developing Fault Tolerant Federations using HLA Evolved”, 05S-SIW-048
“Towards Fault Tolerant RTIs, Federates and Federations”, 05S-SIW-129
“Design of the Dynamic-Link-Compatible C++ RTI API for IEEE 1516”, 04F-SIW-086
While the HLA Evolved Product Development Group (PDG) was developing the new features in the latest version of the standard, the members who were developing and experimenting on the features wrote several papers describing the features and the design decisions that went into them. All of these papers are available on the SISO website.