Concepts

vsTASKER will generate the code that combines the following items:

 

 

For that reason, it is important to understand what is generated, what is mandatory for the user to do and how things organize.

The following picture roughly describes the content of an HLA simulation engine produced by vsTASKER:

 

 

 

vsTASKER provides a way to connect to the RTI agent by use of a class (vsTaskerAmbassador) that inherits from BaseFederateAmbassador which provides the standard API to the HLA agent, as described by the HLA norm (vsTASKER choses the correct BaseFederateAmbassador class from include/hla according to the RTI provider and version selected by the user).

 

The vsTaskerAmbassador class is automatically generated and overwrite all callbacks to connect to the federation, setup all services, publish and subscribe and manage the RTI data flow.

The class also contains all items (see below) defined by the user.

 

When the simulation starts, one instance of the vsTaskerAmbassador class is created.

It joins the Federation (or create it) and is seen as a named vsTASKER federate.

Behind this federates, all the items are running.

 

 

 

 

 

From the outside, a vsTASKER simulation engine that is connected to the RTI is seen as a Federate.

From inside, the federate contains several items called Federate Items or FedItems.

 

These FedItems can be either Object or Interactions.

They can publish or/and subscribe.

 

Each FedItem is associated to a SOM.

The user must add the code to read or write the data for each attribute/parameter or the object/interaction associated with the FedItem.

vsTASKER provides some preprocessing capabilities to simplify the data transfer but cannot do all.

It is to the user to know what is the data that is carried thru the RTI and how to convert and use it.

 

The FedItem can also be associated with a DataModel that can exactly match the SOM definition, in order to reduce the data manipulation and storage.

 

A FedItem Object must be seen as a class that will create as many contexts as necessary, according to the number of real users.

For example, a FedItem Object that will publish the position (x,y,z) and the name (string) of an entity will create one context for each scenario entity that will use it, either to publish their positions to the Federation, or to update their position from a remove federate.

It will then be to the user to make sure that the FedItem will correctly get the data from the internal structures of the entity and publish or update them.