VR-Exchange Capabilities

VR-Exchange is not limited to only two connections at a time. It can be configured with several connections at once, allowing it to exchange data among three or more simulation environments. Each connection passes data that it receives from its own environment to the portal where it is made available to all of the other connections.

Historically, most distributed simulations have been more or less homogeneous. People have typically put together exercises where everyone used DIS, or where everyone used HLA through a particular RTI implementation and FOM. In those cases where both DIS and HLA federates needed to coexist, a DIS/HLA Gateway has been used. But federations that involved more than one RTI implementation, more than one FOM, or more protocols than just HLA and DIS have been rare.

In the last couple of years, things have changed: distributed simulations are more often being put together from existing assets, which have been built, tested, and verified against some set of pre-existing protocol choices. There is more integration between Live, Virtual, and Constructive assets. In addition, large exercises are becoming more common, with multiple sites connected over a Wide Area Network. These exercises are widely distributed not only in the sense of geography and network topology; the program management and organizational responsibility is also more likely than in the past to be distributed among many organizations. Each site manager might have his own budget, and might want to make his own decisions about what protocols to use.

The bottom line is that more and more people are thinking of these large distributed exercises as a "system of systems", or "Federations of Federations" problem. Each site wants to get their "sub-federation" built and tested independently, but they still want to be able to easily integrate with other sites on short time and money. Rather than spending time and money getting all of the sites, and all of the simulation assets to agree on a single architecture, it is often viewed as cheaper and easier to use an "Interoperability Portal" such as VR-Exchange to connect the sites. (This approach is often referred to as a "Mixed Architecture" design.

In many cases, the way this is done is by defining a "central" or backbone federation and requiring that each site use a portal like VR-Exchange to convert from their site's local federation, to the protocol, FOM, and RTI choice dictated by the central federation.

For example, the US Army's Electronic Proving Grounds' DTE5/MSDE experiment in September 2005 defined a central federation based on the MAK RTI and RPR FOM. Each site had the choice of connecting their federates directly to the central federation, or using a Gateway or interoperability portal to join. Several sites used the MATREX RTI and MATREX FOM, for example, but bridged into the central federation using VR-Exchange, which was configured to convert between the MATREX RTI / MATREX FOM and the MAK RTI / RPR FOM.

The US Air Force Distributed Mission Operations (DMO) program uses a similar "Federation of Federations" system architecture, as does the Canadian DND's War In a Box Program. (The latter uses MAK's VR-Exchange).

Pros and Cons of Using a "Federation of Federations"

From the technical side, getting everyone to agree on a common protocol, RTI, or object model is still usually the best approach. Your federates will be more tightly coupled, and you can take advantage of optimizations that in HLA, for example, only the RTI can provide (based on its knowledge of your overall network topology). For example, you lose some of the benefits of HLA DDM (Data Distribution Management) when going through a bridge. Ownership management and Time Management become more problematic. The MOM (Management Object Model) does not necessarily give you the answers you would expect, because no single RTI knows about all of the federates in the larger exercise. If your desire is really to achieve the "look and feel" of all federates participating in one, unified federation, then we recommend trying to use one, consistent RTI and FOM, if at all possible.

However, there are many situations where a distinct separation between different sets of federates is actually desirable! For example, in a "hierarchical federation", a group of federates might use an intra-simulator FOM to exchange data among components of a single vehicle simulator, but might want only "external" data such as position, velocity, and orientation to be available to other applications or sites. Perhaps different sub-federations are running at different levels of security, but still need to share some common data. Perhaps you would like to implement filtering at the site level, so that you have a single place from which to control what data can go between sites. Perhaps you want to be able to bring a running sub-federation in and out of a larger exercise. For these situations, a "Federation of Federations" system architecture is often the best solution.

Then there are the organizational benefits. As described above, the federation of federations approach often makes large-scale exercises easier to manage. Sub-federations on each site are free to choose their own interoperability architecture and object model, and can be independently developed, tested and verified. The integration effort to bring the sub-federations together becomes more manageable.

The bottom line is that if you feel that these improvements to the process of setting up an exercise outweigh the technical advantages of putting together a single large-scale federation on top of a common RTI and object model, then the Federation of Federations or "Mixed Architecture" approach (based on an interoperability portal like VR-Exchange) is the right choice.

VR-Exchange provides an architecture and implementation that are directly in line with JFCOM's Live, Virtual, and Constructive Data Translator concept. VR-Exchange has built-in support for HLA and TENA. Its architecture is flexible enough to support Brokers for Link-16 and various C4I protocols; and the ability to support simulation-to-C4I interoperability was one of VR-Exchange's key design criteria.

VR-Exchange supports the following PDUs (listed by protocol families):

• Entity Information and Entity Interaction PDUs
  • Entity State PDU
  • Collision PDU
• Warfare PDUs
  • Fire PDU
  • Detonation PDU
• Simulation Management PDUs
  • Start/Resume PDU
  • Stop/Freeze PDU
  • Acknowledge PDU
  • Action Request PDU
  • Action Response PDU
  • Data Query PDU
  • Set Data PDU
  • Data PDU
  • Event Report PDU
  • Comment PDU
  • Create Entity PDU
  • Remove Entity PDU
• Radio Communications PDUs
  • Transmitter PDU
  • Signal PDU
  • Receiver PDU
• Distributed Emission Regeneration PDUs
  • Electromagnetic Emission PDU
  • Designator PDU
  • IFF PDU
• Logistics PDUs
  • Service Request PDU
  • Resupply Offer PDU
  • Resupply Received PDU
  • Resupply Cancel PDU
  • Repair Complete PDU
  • Repair Response PDU
• Entity Management PDUs
  • Transfer Control Request PDU
• Synthetic Environment PDUs
  • Environmental Process PDU
  • Gridded Data PDU
  • Areal Object PDU
  • Linear Object PDU
  • Point Object PDU.
• Logger Control PDUs (for MAK Logger)

If you need to extend the set of object or interaction classes that VR-Exchange can handle, the VR-Exchange API allows you to do this. You can extend VR-Exchange's lingua franca (the protocol-independent data representation defined by libPortal), to add new kinds of DtPortalObjectPublishers, DtPortalReflectedObjects, and DtPortalReflectedObjectManagers. In the newest version of VR- Exchange, you can also add new attributes to existing kinds of objects without needing to create one. The API uses C++ templates to ease the job of adding new types. You can define a new kind of DtPortalObject in one place, and use template instantiation to generate the publisher, reflected object, and reflected object list for the new type. Once you've extended the Data Exchange in this way, you can extend both the built-in and custom brokers, so that they can pass the new types through the Data Exchange.

When there are many objects listed in the Objects window, it can be difficult to find a particular object that you want to examine. You can search the objects list to quickly find particular objects. VR-Exchange searches the Name, Entity ID, and Marking Text columns in sequence to find the search string.

You can filter out entire classes of objects. You can also filter individual objects. You might do this if you are interested in particular objects and want to reduce network traffic by filtering out the objects you are not interested in. You can filter objects by name, entity type, and marking text. Filtering by entity type and marking text only applies to entities and aggregates.

Display Details about the Shared Memory Queue

You can display details about the shared memory queue.

View Statistics

You can display a graph of the number of packets being processed by VR-Exchange and internal VR-Exchange messages.

Monitor Translation on a Per-Object Basis

You can monitor translation on a per-object basis. When you monitor an object, VR-Exchange shows the most recent input and output for the object. This information can be useful for debugging brokers.