 |
VR-Forces 5.0.2 Developer's Guide
|
All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Properties Friends Macros Groups Pages
|
VR-Forces 5.0.2 Developer's Guide
|
The sim engine has a single instance of the DtNetworkInterfaceManager, which is created and owned by the DtCommunicationManager.
The DtNetworkInterfaceManager is responsible for managing all network interfaces used by the sim engine. Usually there is only a single network interface, but it is possible to have multiple. Each network interface represents the network connection to single exercise, in most cases either a DIS exercise or HLA federation. Each network interface is implemented as a subclass of the abstract base class DtNetworkManagerInterface. The primary example of a network interface is the DtVrlinkNetworkInterface, which manages the sim engine's VR-Link exercise connection.
The DtNetworkInterfaceManager listens for the addition state data from the DtStateDataManager. It then iterates over its list of network interfaces and informs each of them about the new state data. Each network interface then decides what type of new object network interface must be added to support the state data, if any. DtSimObjectNetInterface is an abstract base class from which local and remote network interfaces are derived. It is important to note that an object network interface is not owned by the sim object. It is maintained as a separate list, and there is not even necessarily a one-to-one mapping between sim objects and object network interfaces. However, creating a new entity will generally result in at least the generation of a DtSimEntityNetInterface instance, though it may also result in the creation of one more DtStateComponentNetInterface instances as well, depending on what DtStateComponent instances the sim object creates.
Network interfaces are created for both local and remote state data. If the state data is local, the network interface is responsible for updating a VR-Link publisher with data from the sim engine's state data each tick. If the state data is remote, the network interface updates the sim engine's state data with data from its VR-Link reflected object. The figure below illustrates local and remote object network interfaces within a VR-Forces application.
Local network interfaces send data over the network through VR-Link publishers. There are network interfaces for publishers such as DtEntityPublisher, DtAggregatePublisher, DtEnvironmentProcessPublisher, DtEmitterSystemPublisher, DtRadioTransmitterPublisher and more. Remote network interfaces, on the other hand, maintain a VR-Link reflected object such as DtReflectedEntity, DtReflectedAggregate, DtReflectedEnviromentProcess, DtReflectedIff, DtReflectedActiveSonar, and more.
A local network interface contains a VR-Link publisher and an associated VR-Link network state repository (not to be confused with the simulation state repository). Each tick, an object’s local network interface takes state information from the state data and copies it to its network state repository. The VR-Link publisher is responsible for sending updates, as necessary, in the form of DIS PDUs or RPR FOM object attribute updates.
A remote network interface contains a VR-Link reflected object and its associated VR-Link network state repository (not to be confused with the simulation state repository). Each tick, the network interface takes state information maintained in the VR-Link network state repository and updates the state data. Receipt of standard DIS/RPR FOM data is handled at the VR-Link level in the network interface’s reflected object member data.
While the creation of a sim object may result in the creation of multiple object network interfaces, there is generally one object network interface responsible for publishing the core object data to the network. You can configure this network interface for a type of object by editing its entry in the object parameter database. When you configure an object’s network interface, the string you enter determines the class that gets created when the object is instantiated, as listed in the following table. Network interface type strings are defined in vrfNetInterfaceTypes.h.
| Network Interface Classes | |
|---|---|
| String | Class |
| Individual platform-level entity | |
| individual-local-entity-net-interface-with-properties | DtSimIndividualLocalEntityWithPropertiesNetInterface |
| vrf-individual-remote-entity-net-interface-with-properties | DtVrfIndividualRemoteEntityWithPropertiesNetInterface |
| Unit | |
| pseudo-aggregate-local-entity-net-interface-with-properties | DtSimPseudoAggregateLocalEntityWithPropertiesNetInterface |
| vrf-aggregate-remote-entity-net-interface-with-properties | DtVrfAggregateRemoteEntityWithPropertiesNetInterface |
| Control object | |
| local-control-object-net-interface-with-properties | DtSimLocalControlObjectWithPropertiesNetInterface |
| vrf-remote-environmental-net-interface-with-properties | DtVrfRemoteEnvironmentalWithPropertiesNetInterface |
As described in Creating an Object's Subcomponents, each VR-Forces application has its own Local Object Manager. When the Local Object Manager creates a new simulation object (through the createAndInitVrfObject() function), it looks up the entry in the object parameter database for the object type to be created, and uses this data to direct the construction of the object.
For example, the following is an excerpt of the Ground_Vehicle.ope used by all ground vehicles in the EntityLevel SMS. It shows the local and remote objects lists.