Editing High Level Architecture (section)

== Interface specification ==
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 (programming language)|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===
The purpose of Federation Management services, described in chapter 4 of the HLA Interface Specification,<ref name="IFSPEC" /> 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===
The purpose of Declaration Management services, described in chapter 5 of the HLA Interface Specification,<ref name="IFSPEC" /> 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===
The purpose of Object Management services, described in chapter 6 of the HLA Interface Specification,<ref name="IFSPEC" /> 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===
The purpose of Ownership Management services, described in chapter 7 of the HLA Interface Specification,<ref name="IFSPEC" /> 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===
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, described in chapter 8 of the HLA Interface Specification,<ref name="IFSPEC" /> 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 time-regulating federate assigns a time stamp to messages (updates and interactions) when they are sent, indicating the scenario time at which the message is valid. 
* The RTI manages delivery of messages to time-constrained federates, with messages from time-regulating federates delivered at the appropriate time using a Time Stamp Order queue.
* Time-constrained federates request permission from the RTI to advance their time.
* The RTI grants a time advance to a time-constrained federates when it is sure that the federate cannot receive a message with a time stamp in its past.

Example of Lookahead, granted and advancing:
# A federate uses a fixed time step of 10 and has a Lookahead of 10.
# 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.
# The federate now has all the necessary data to correctly calculate and send messages for the granted time plus Lookahead, i.e. 60. 
# 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. 
# The RTI delivers all messages with timestamp less or equal to 60 to the federate. It then grants the federate to time 60.
# 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 (e.g., federations that do not require human interaction at runtime nor interfaces with systems that depend upon a real-time clock can run as fast as computing resources will allow).

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 (DDM)===
The purpose of DDM, described in chapter 9 of the HLA Interface Specification,<ref name="IFSPEC" /> is to increase scalability of federations by performing additional filtering of subscribed data beyond class and attribute subscriptions.<ref>{{cite journal |last1=Möller |first1=Björn |last2=Fredrik |first2=Antelius |last3=Martin |first3=Johansson |last4=Mikael |first4=Karlsson |title=Building Scalable Distributed Simulations: Design Patterns for HLA DDM |journal=Proceedings of 2016 Fall Simulation Interoperability Workshop |date=September 2016 |url=https://www.sisostds.org/DigitalLibrary.aspx?Command=Core_Download&EntryId=44863 |access-date=13 November 2019}}</ref> Filtering can be based on continuous values (like latitude and longitude) or discrete values (like car brand).

Key concepts of DDM are:

'''Dimension''': a named interval (0..n) used for filtering, with values starting with 0 and ending with an upper bound n. Data in the simulation domain is mapped to one or more dimensions. For example, dimensions for geographical filtering could be LatitudeDimension and LongitudeDimension. A dimension for filtering based on car brand could be CarBrandDimension.

'''Normalization function''': a function that maps input values to integer values to be used in a dimension. An example is that a normalization function for the LatitudeDimension could map a latitude value ranging from -90.0 to +90.0 to an integer in the range 0..179. A normalization function for the CarBrandDimension could map a set of car brands Kia, Ford, BMW and Peugeot to an integer in the range 0..3.

'''Range''': an interval on a dimension, specified by a lower bound (inclusive) and an upper bound (exclusive).

'''Region''': a set of ranges, each one relating to a particular dimension. In the above example, a region could consist of the range (3..5) for LatitudeDimension (55..65) for LongitudeDimension and (0..1) for the CarBrandDimension. At runtime Region Realizations (objects) are instantiated to represent regions. The ranges of a region can be modified over time.

'''Region overlap''': two regions overlap if, for all dimensions that they have in common, their ranges overlap.

At runtime, a federate can provide Regions when subscribing to object class attributes and interactions. Regions are also used when sending attribute updates and interactions. When DDM is used, attribute updates and interactions will only be delivered if there is a region overlap.

Key services for Regions are:
* CreateRegion that is used to create a region with a specified set of Dimensions.
* DeleteRegion that is used to delete a region.
* CommitRegionModifications that is used to change the ranges of a dimension for a Region.

Key services for exchanging attribute updates with DDM are:
* RegisterObjectInstanceWithRegions that is used to register an object instance with regions associated with its attributes.
* AssociateRegionsForUpdates that is used to associate regions with attributes of an object instance.
* SubscribeObjectClassAttributesWithRegions that is used to subscribing to attributes of objects where the regions used for subscription overlaps with the regions of the attributes.

Key services for exchanging interactions with DDM are:
* SubscribeInteractionClassWithRegions that is used to subscribe to interactions where the regions used for subscription overlaps with the regions of the interactions.
* SendInteractionsWithRegions that is used to send interactions with associated regions.

===Support services===
The HLA Support Services, described in chapter 10 of the HLA Interface Specification,<ref name="IFSPEC" /> provide a number of supporting services. These include:
* Getting Handles (references) to be used in the above service calls.
* Setting various runtime switches, in particular for advisories (notifications).
* Controlling the delivery of callbacks.

=== Management Object Model===
The purpose of the Management Object Model, described in chapter 11 of the HLA Interface Specification,<ref name="IFSPEC" /> is to provide services for managing a federation. This is performed using the MOM object and interaction classes. MOM objects are defined in a special FOM module called the MIM, that is automatically loaded by the RTI. Key MOM features include:
* List and inspect properties of federates.
* Inspect properties of the federation.
* Get the content of the current FOM and FOM modules.
* Inspect the state of Time management.
* Inspect and modify publications and subscriptions of federates.
* Inspect certain performance figures.
* Inspect which federate that calls which HLA services.
* Inspect status of synchronization points.