HLA

Question 1

What is HLA?

Answer 1

High Level Architecture (HLA) is a general framework facilitating interoperability and reusability of distributed simulation components.

Where components might run on different computers, in different locations, and be implemented in different programming languages on different operating systems.

• A software architecture not an implementation.

Question 2

What is a Federate?

Answer 2

An application that supports the HLA and is capable of participating in a simulation

Question 3

What is Federation?

Answer 3

A declaration between federates describing how and what will be simulated

Question 4

What is Federation Execution?

Answer 4

A run-time instantiation of a Federation. i.e. actual simulation run.

Question 5

What is an Observer Pattern?

Answer 5

A messaging framework commonly used for asynchronous communication between services.

Question 6

What is the Object Model?

Answer 6

Object model defines the interactions in a federation in terms of:

Objects:
the entities with some temporal lifespan
the representation exists only in federates, not in the RTI.

Interactions:
events with zero temporal lifespan

Attributes:
of objects

Parameters:
of interactions

Question 7

What is Federation Object Model (FOM)?

Answer 7

The Federation Object Model (FOM) exists only one per federation.

It has the complete parameterisation of a Federation Execution where the RTI is the same for all Federation Execution and the FOM contains all information the RTI needs in order to perform a Federation Execution.

FOM specifies objects, interactions etc. that are used in federation.

It is passed as a parameter to the RTI when the federation execution starts, by the first federate to start.

Question 8

What is the Simulation Object Model (SOM)?

Answer 8

The Simulation Object Model (SOM) exists one per federate.

SOM specifies objects, interactions etc. that a federate publishes and/or subscribes to in a federation.

It is included in the FOM, defined documented by a federate but it is the FOM that is used at runtime, not the SOM.

Question 9

What is Management Object Model (MOM)?

Answer 9

Management Object Model is mandatory for FOM. It has predefined set of information.

MOM specifies the objects, interactions etc. created by the RTI itself.

It enables federates to access the RTI information during Federation Execution.

Question 10

How does HLA specifies Management Initialisation Module (MIM)?

Answer 10

Management Initialisation module (MIM) is supplied by the RTI.

The standard MIM can be replaced by a user-supplied
MIM.

MIM contains for example, predefined data types and the MOM.

Question 11

What is Object Model Templates (OMT)?

Answer 11

It is the format defined(allowed) of the FOM and hence the SOM and MIM(MOM).

Question 12

What are some IEEE standards?

Answer 12

HLA Rules:
* principles and conventions that must be followed for a proper federation execution
* design principles for the Object Model Template(OMT) and Interface specification
* responsibilities of federate/federation designers

Object Model Template(OMT) Rules:
* Every federation has a Federation Object Model(FOM)
* OMT defines the allowed structure for every FOM

Interface Specification:
* Specifies the interface between federates and the RTI

Question 13

What are HLA rules for Federation?

Answer 13

Every Federation shall have a FOM
* structured and documented according to the OMT

Representation of objects in the FOM is within the federates
* not in the RTI (apart from the MOM data)

During a federation execution:
* all exchange of data between federates occurs via the RTI
* federates must interact with the RTI according to the HLA interface specification
* an attribute of an object instance must be owned by only one federate at any time

Question 14

What are HLA rules for Federates?

Answer 14

Each federate must:
* have a SOM, structured and documented according to the OMT

… and be able to:
* update and/or reflect any attributes of objects in their SOM
* send and/or receive SOM interactions, as specified in their SOM
* transfer and/or accept ownership of attributes dynamically during a federation execution, as specified in their SOM
* manage local time in a way that allows them to coordinate data exchange with other members of a federation

Question 15

What is Run-Time Infrastructure (RTI)?

Answer 15

The RTI service provides the mechanisms required for managing a federation execution.

It does not impose a policy for their use.
It makes no assumptions about the software using that service.

Usually you will access an exisiting RTI and develop your own federate code.

One RTI can run multiple federation execution at the same time.

One federation execution can take place on a single server or multiple servers.

Question 16

What are RTI ambassador APIs?

Answer 16

HLA standardised APIs:
* the federate talks to the RTI through
the RTIambassador
* if the RTI must talk to your code, it
does so by executing “callbacks” in
your code, executed by the
FederateAmbassador

Question 17

What are the difference between different vendors and what are common in terms of the API?

Answer 17

different vendors will provide different implementations of the RTI
* HLA does not specify the format of the data interchanges on the network
* different RTIs from different vendors may use completely different formats.

What is standardised?
* the RTIambassador and FederateAmbassador APIs
* the OMT and FOM/SOM specifies the object model; you should be able to carry these between RTIs

Question 18

What does the RTI manage?

Answer 18

manages:
* the federation execution
* joining, leaving, pausing, resuming of federates; federation management
* simulation time
* synchronisation between federates
* possibly synchronisation of simulation with real time
* data distribution between federates
* efficient data transmission
* declaration
* publish/subscribe model
* objects
* lifecycle and message passing
* ownership
* of objects and their attributes
* support services
* e.g. RTI startup and shutdown

Question 19

What are the steps that federates go through in execution (federate lifecycle)?

Answer 19

each federate goes through distinct phases of execution:
* joins the federation execution
* registers its FederateAmbassador with the RTI
* preliminaries
* sets time parameters
* register publications and subscriptions
* populating
* registers and initialises data instances
* running
* advances through simulation time
* post-processing
* stops advancing through simulation time
* tidies itself up
* resigns the federation execution
* and shuts down

with multiple federates in one
federation execution we need
some way of coordinating these
phases

Question 20

What do you use to synchronise the federation execution and how?

Answer 20

To synchronise a federation execution we use a synchronisation point:
* a federate registers a synchronisation point
* the RTI announces a new synchronisation point to all federates; the synchronisation point is now awaiting synchronisation
* as each federate achieves the synchronisation point it informs the RTI
* what this means is up to the federation designer, but it should mean getting to an unambiguous state
* when all federates have achieved the synchronisation point, the RTI announces this to all federates
* the RTI removes the synchronisation point from its registry

Question 21

State two characteristics of synchronisation point.

Answer 21

There can be multiple synchronisation points registered at any one time
* each is identified by a unique name, established at registration time

They might not apply to all federates in a federation execution
* each synchronisation point has a synchronisation set, established at registration time
* the registration set lists which federates must synchronise for the RTI to conclude that
the synchronisation is complete

Question 22

What is the role of Manager federate?

Answer 22

*starts the federation execution
*makes sure all the expected federates have joined
*synchronises the federates’ execution phases
*shuts down the federation execution

Question 23

Explain the declaration management of the RTI in terms of publish/subscription.

Answer 23

a federate
* registers an intent to publish
* some or all attributes of a class
* some or all parameters of an interaction

publish
“I am going to create and
update things of this class”

and subscribes to
* some or all attributes of a class
* some or all parameters of an interaction

subscribe
“I want to be told when
things of this class have
been created/updated and
be sent the changes”

publications/subscriptions can change over time
i.e. during a single federation execution

Question 24

What are two examples of interactions?

Answer 24

Federate sends an interaction to the RTI
* with data for some or all parameters set

Federate receives an interaction from the RTI
* with the sent parameters’ data

Question 25

Explain the process of the object being registered, updated, and removed through RTI.

Answer 25

Register/discover A federate registers a new instance of some class of object with RTI Federates that have subscribed to some or all attributes of that object class are informed of the registration by the RTI Subscribing federates discover the new instance Update/reflect Registering federate sets some or all attributes of the new instance; it updates the attributes Subscribing federates are informed of the updates by the RTI Subscribing federates reflect the new values Delete/Remove Registering federate signals the RTI to delete the instance Subscribing federates are informed of the deletion by the RTI Subscribing federates remove the instance

Question 26

Describe the properties of object owenership.

Answer 26

* an object attribute can only be owned by one federate at a time * only the owning federate can update an object attribute * that federate has authoritative information about that object and sends updates to other federates when the attributes change * other federates can subscribe to the object attribute * they are sent updates when the subscribed-to attributes change * an object attribute can have its ownership passed to another federate

Question 27

What are the two ways to achieve the ownership of an object?

Answer 27

two different approaches: * federate requests ownership * “ownership pull” * federate relinquishes ownership * “ownership push” RTI keeps track of who owns what

Question 28

Explain the process of how a federate requests (pull) ownership.

Answer 28

Federate attribute ownership acquisition to the RTI RTI request attribute ownership release to the owner Federate 2 Federate 2 send attribute ownership release response/denial to the RTI If accepted, RTI send attribute ownership acquisition notification If declined, attribute ownership unavailable

Question 29

Explain the process of how a federate relinquishes (push) ownership.

Answer 29

the owning federate informs the RTI that it wishes to divest itself of that ownership the RTI informs all federates that publish that attribute that ownership is available If no federate accept the attribute, the attribute becomes orphan (no more update available) If one federate accept the attribute, the ownership is transferred. If more than one federate accepts the attribute, then the RTI applies priority policy to select one. Ownership transferred.

Question 30

Describe the HLA time management.

Answer 30

* the order in which events happen might be important for a simulation * to maintain ordering, a federation need some concept of time * federates only communicate via the RTI * time synchronisation is only required with respect to those communications

Question 31

Where does the time ordering is being used?

Answer 31

* each federate keeps an internal simulation clock * each event is timestamped * when the federate has finished its processing for the current time, it asks permission from the RTI to advance its clock * the clock in each federate only advances when authorised by the RTI * events are transmitted by the RTI to the federates in order of their timestamps

Question 32

Where does the time ordering is not used?

Answer 32

* events are not timestamped * events are transmitted by the RTI to the federates in the order they are received

Question 33

What is simulation time and what are the properties?

Answer 33

Simulation time might not be the same as real time * human-in-the-loop simulations (e.g. aircraft pilot training) need real time * many simulations want to operate at accelerated time * some simulations (e.g. CFD) run much slower than real time Federates on different servers * maybe some fast servers and some slow * maybe some fast network connections to the RTI and some slow * some will operate more computationally quickly (they have less to do) * it may be that their real-time clocks are not showing exactly the same time federates can operate in either a time-managed or a non-time-managed mode

Question 34

Federates interact with each other by sending events, describe it.

Answer 34

A federate might do lots of other things internally, but it only interacts with other federates by sending events through the RTI: * synchronisation points * interactions * object management * ownership transfer * time management * RTI exceptions The relative order in which events are actioned may or may not be important to the federation or to individual federates.

Question 35

Describe the properties of HLA time.

Answer 35

* HLA is event-driven * this does not mean it can only support discrete event simulations * simulation clock changes are treated as events * so HLA supports discrete time simulations, not just discrete event simulations * it supports discrete time and discrete event simulations in the same federation

Question 36

Describe the properties of events in a time-managed simulation.

Answer 36

In a time-managed simulation: * timestamps are used to determine the order and timing of events across all federates * when a federate generates and sends an event to other federates it applies a timestamp to that event * the timestamp represents the logical (simulation clock) time at which the event should be considered to occur within the simulation * time-managed federates share a logical time

Question 37

Describe does time-regulating and time-constrained mean and explain their properties.

Answer 37

Federates can declare themselves as time-regulating, time-constrained, or both: Time-regulating * can timestamp events * can prevent other federates advancing their logical time Time-constrained * can receive timestamped events * logical time advance is constrained by other federates the RTI: * schedules and delivers events to time-constrained federates in the right time order * only grants time advance requests if it can ensure that there will be no out-of-order events

Question 38

Show a example of time-regulating, time-constrained, both and neither

Answer 38

Time-regulating only * radar federate in an air traffic control simulation regulates time * a federate whose only role is to synchronise simulation time with real time Time-constrained only * weather forecasting federate receives simulated sensor data and updates its forecast * it does not care what the time is, but sensor data must be processed in time order Time-regulating and time-constrained * federate simulating a self-driving car's motion is both time-regulating (to control time progression for sensors or decision-making systems) and time-constrained (ensuring it processes traffic signals and obstacles in chronological order) Neither time-regulating nor time-constrained * passive data-logger federate

Question 39

What is a lookahead mechanism?

Answer 39

Each federate specifies a lookahead value * lookahead represents the minimum time interval between the federate’s current logical time and the time of any event it can generate * in discrete time simulation, the lookahead value is the time-step interval, ∆t The RTI uses this lookahead to synchronise federates * it ensures that a federate cannot schedule an event in the "past" relative to other federates’ logical times

Question 40

Describe different types of time advancement requests

Answer 40

Federates advance their logical time by making specific time advance requests to the RTI: * Time Advance Request: a federate asks to advance to a specific logical time. * Next Event Request: a federate requests to advance time to the time of the next scheduled event (if any) The RTI processes these requests and then issues * Time Advance Grant: to requesting federates in a way that ensures time advances do not violate event ordering

Question 41

Describe the two types of time synchronisation approaches

Answer 41

Conservative synchronization * prevents a federate from advancing its logical time until it can guarantee no out-of-order events will be received * suitable for simulations where maintaining strict causality is critical Optimistic synchronization * allows federates to tentatively advance time while potentially receiving out-of-order events * federates can “roll back” if they detect a causality violation HLA does not natively implement optimistic synchronization, it can be supported by specific federate designs within the HLA framework * remember that RTI provides facilities; how you choose to use them is up to you