5.4 - Publishing and Subscribing to FOM Classes and Attributes

Table of Contents

• 5.4.1 Publishing Classes and Attributes
  • 5.4.1.1 Publishing Interactions
• 5.4.2 Subscribing to Classes and Attributes
  • 5.4.2.1 Subscribing to Interaction Classes

Before they send any data, HLA federates must tell the RTI the set of FOM classes and the set of attributes of object classes for which it is capable of sending data.

The HLA specification refers to this initialization activity as "publishing" a class, or "publishing" a class with a set of attributes. (Though some people refer to the act of sending interactions or sending attribute value updates as publishing, that is not the meaning of the word as defined by the RTI or HLA specification.)

Similarly, an HLA federate must indicate to the RTI the set of FOM classes and the set of attributes of object classes for which it is interested in receiving data from other federates. This initialization activity is called "subscribing".

Most VR-Link applications do not need to do anything special to fulfill the publishing and subscribing requirement; VR-Link takes care of this for you. However, if you want to alter the set of classes or attributes that get subscribed to or published, you can do so through VR-Link.

5.4.1 Publishing Classes and Attributes

When you create an instance of a particular kind of object publisher (for example, a DtEntityPublisher), VR-Link determines which object class from the FOM should be used to represent the object (typically by either using the class handle passed to the publisher's constructor, or by asking the FOM Mapper). Before registering the new HLA object with the RTI, we publish the object class if the federate has not already published the class or explicitly unpublished it. By default, the class's full set of valid attributes is published.

To publish only a subset of an object class's attributes, you must explicitly publish the object class, along with the desired attribute set, before creating the object publisher. This is done using DtObjClassDesc::publish(). When the object publisher is constructed, it sees that the class has already been published, and does not perform the default publication.

Note

Do not publish by directly using RTI services. The RTI API does not provide a way to find out which classes and attributes you have published. So if you publish directly through the RTI API, VR-Link cannot know that you have done so, and will perform the default publish with all attributes included.

For example, to publish only the EntityType and Position attributes of the GroundVehicle class:

#include <vlutil/vlStringUtil.h> // For DtToWString

DtExerciseConn  exConn(...);
...

#if DtHLA

   DtObjClassDesc *desc = exConn.fom()->objClassByName(
      "BaseEntity.PhysicalEntity.Platform.GroundVehicle");
   assert(desc);
   RTI::ObjectClassHandle classHand = desc->handle();

#if DtHLA_1516
   // In 1516 AttributeHandleSets are of type
   // std::set<RTI::AttributeHandle>
   RTI::AttributeHandleSet hSet;

   // Note that the parameters to getAttributeHandle have been reversed
   // in 1516. Also note that strings passed to the RTI are of type
   // std::wstring.
   hSet.insert(exConn.rtiAmb()->getAttributeHandle(
      classHand, L"EntityType"));
   hSet.insert(exConn.rtiAmb()->getAttributeHandle(
      classHand, DtToWString("Position")));
   desc->publish(hSet);
#else
   RTI::AttributeHandleSet *hSet =
      RTI::AttributeHandleSetFactory::create(2);
   hSet->add(exConn.rtiAmb()->getAttributeHandle(
      "EntityType", classHand));
   desc->publish(*hSet);
   delete hSet;
#endif

#endif

Attribute publications apply only to the class that you specify, not to subclasses or superclasses. So you will need to call publish() on multiple class descriptors to change the set of attributes published for a whole portion of a class hierarchy.

5.4.1.1 Publishing Interactions

Publishing interactions works a little differently from publishing objects. You cannot publish only a subset of the parameters of an interaction. You either publish an interaction class with all of its parameters, or not at all. When you send an interaction of a particular class using DtExerciseConn::send() or DtExerciseConn::sendStamped(), VR-Link publishes the interaction class if it is not currently published by the federate.

5.4.2 Subscribing to Classes and Attributes

Usually, a reflected object list's constructor subscribes to object classes. A particular kind of reflected object list (for example, a DtReflectedEntityList) determines which FOM classes it is interested in, typically by either using the class handles passed to the constructor, or by asking the FOM Mapper. Then, it subscribes to each of those classes to which the federate is not already subscribed.

Most reflected object lists in VR-Link take an optional handleList argument, which lets you specify exactly which FOM classes should be subscribed to (and managed by the reflected object list). If this argument to the DtReflectedEntityList constructor is omitted, it gets the set of classes to subscribe to from the FOM Mapper. (The default FOM Mapper says that BaseEntity and all of its subclasses except AggregateEntity should be managed by DtReflectedEntityList.)

HLA 1.3: The handleList is a DtList of RTI::ObjectClassHandles, cast to void*. HLA 1516: The handleList is a list of pointers to valid RTI::ObjectClassHandles.

The following example demonstrates the procedure for telling a DtReflectedEntityList to subscribe to and manage only the GroundVehicle and Munition FOM classes:

...

#if DtHLA

   DtList handleList;
#if DtHLA_1516
   std::wstring hName(
      L"BaseEntity.PhysicalEntity.Platform.GroundVehicle");
   handleList.add(new RTI::ObjectClassHandle(
      exConn.rtiAmb()->getObjectClassHandle(hName)));
#else
   // DtList holds pointers. Since we know that Handles in HLA 1.3
   // are just integer values, we store them as pointer values.
   // This doesnt work in 1516.
   handleList.add((void *) exConn.rtiAmb()->getObjectClassHandle(
      "BaseEntity.PhysicalEntity.Platform.GroundVehicle"));
   handleList.add((void *) exConn.rtiAmb()->getObjectClassHandle(
      "BaseEntity.PhysicalEntity.Platform.Munition"));
#endif

   // Create the Reflected Entity List
   DtReflectedEntityList(&exConn, &handleList);

   ...
#if DtHLA_1516
   // we are done with the handles we created, let's clean them up
   for (DtListItem *item = handleList.first(); item;)
   {
      DtListItem* next = item->next();
      RTI::ObjectClassHandle *hand =
         static_cast<RTI::ObjectClassHandle *>(item->data());
      handleList.remove(item);
      delete hand;
      item = next;
   }

#endif 

By default, when VR-Link subscribes to an object class, it subscribes to all attributes of the class. If you want to subscribe to only a subset of an object class's attributes, the procedure is the same as that for publishing a subset of an object class's attributes, except that you use the DtObjClassDesc::subscribe() function, instead of publish(). For more information, please see 5.4.1 Publishing Classes and Attributes.

Note

Do not subscribe by directly using RTI services. The RTI API does not provide a way to find out which classes and attributes you have subscribed to. If you subscribe directly through the RTI API, VR-Link will not know that you have done so, and will perform the default subscribe with all attributes included.

5.4.2.1 Subscribing to Interaction Classes

Subscription to interaction classes normally takes place when you register a callback function with a VR-Link interaction class. That action tells VR-Link that you are interested in a certain set of interaction classes, and VR-Link passes that information on to the RTI. Just as with publication, the RTI API does not let you subscribe to a subset of an interaction's parameters.

[<< Getting Information About the FOM] [Home] [Top of Page] [Managing HLA Objects >>]