Problems & Solutions

Problem	Solution
I have a stand alone simulation application (flight simulator, tank trainer, etc.), and I need it to interoperate with other simulation applications, so that my entities can interact with the entities simulated by the other systems in the same virtual world. How can I achieve this? My simulator is DIS-compliant, but now I need to support HLA. How can I migrate this application to HLA? I am running an exercise. Some of my simulation assets support DIS and some support HLA. I don’t have control over these applications, so I can’t convert the DIS applications to HLA, or vice-versa. How can I get them to communicate? I have a set of applications that need to interoperate in a federation. The applications are HLA-compliant, but they support different Federation Object Models (FOMs). How can I get them to communicate? I need some diagnostic tools to help me debug my distributed simulation applications. I want to be able to understand what simulation data is going over the network, so I can diagnose interoperability problems. I need to record and play back my simulation exercise for after-action review. What tools do I need? I have a man-in-the-loop simulator, and I need to provide targets, or additional computer-controlled entities to round out my simulation. I have some high-fidelity dynamics code, behavior models, or sensor code, and I want to plug it into an existing synthetic environment, so that it can be exercised in a virtual battle. I am developing a behavior editor, behavior engine, doctrine editor, or AI engine, and I would like to connect "brain" software to some existing "body" code - a physics-based model that my engine can drive. I’d like to create a concept demonstration for a new weapon system, vehicle, tactic, or sensor, either for simulation-based acquisition or for a proposal for a simulation program. I need a situation awareness tool that gives me a large-scale tactical or strategic view of a battlefield scenario, while also providing a 3D sense of perspective.	Most military simulation applications in the world adhere to one of two IEEE Standards for Simulation Interoperability - DIS (Distributed Interactive Simulation) or HLA (High-Level Architecture). So for your application to interoperate with other simulations, you will probably need to make your application DIS- or HLA-compliant. MÄK’s VR-Link^®is an object-oriented C++ toolkit that simulation developers use to quickly and easily build HLA and DIS-compliant applications. It provides a set of libraries that implement a stable, consistent, and documented API (Application Programmer’s Interface) to the HLA and DIS protocols ― an SDK (Software Developer’s Kit) for interoperability. A few calls to VR-Link’s functions replace thousands of lines of code that you would otherwise need to write yourself, saving time and money on development and maintenance. If you need to be able to speak both HLA and DIS (or might have to in the future), then VR-Link is doubly valuable. That is because VR-Link implements both DIS and HLA through largely the same API. This means that you can write code once, and switch between HLA and DIS just by recompiling and linking with the appropriate versions of the VR-Link libraries. The other MÄK tool that you might need is the MÄK RTI. An RTI, or Run-Time Infrastructure, is a required component of any HLA federation. According to the rules of HLA, various simulation applications, known as federates, use the RTI to exchange simulation data. (DIS is a wire-protocol and does not require an RTI). The MÄK High-Performance RTI is the industry’s leading RTI implementation. It has been verified by the Defense Modeling and Simulation Office as fully-compliant with both HLA 1.3 and the IEEE 1516 version of the HLA Standard, and has been proven and battle-tested in a variety of HLA federations throughout the world, both large and small. There are several ways to migrate DIS federates to HLA, and MÄK’s products can help you implement any of these strategies. First, if your federate already uses MÄK’s VR-Link for its DIS compliance, then migrating to HLA is usually trivial. VR-Link supports DIS and HLA with the same top-level API, so most VR-Link-based applications can be migrated to HLA by just changing a few lines of initialization code and recompiling. If your application does not use VR-Link yet, then using VR-Link is still the easiest way to make it natively HLA compliant. Your application makes calls to VR-Link’s C++ API, and VR-Link takes cares of sending and receiving data through the RTI, encoding and decoding it according to the rules of your Federation Object Model (FOM). Of course, VR-Link supports DIS as well, so once you have integrated with VR-Link for your HLA compliance, you may be able to eliminate the recurring expense of supporting a separate DIS interface. If you do not have source code for your application, or are not able to modify the code, then you will not be able to make your application natively HLA compliant. But you can still participate in HLA federations using a Gateway. The MÄK Gateway is a separate application that translates between the DIS and HLA protocols, allowing your existing DIS application to interoperate with HLA federates without any modification. Regardless of which approach you choose for supporting HLA, all HLA applications will need an RTI in order to communicate. The MÄK RTI is an excellent choice, due to its outstanding performance, fault tolerance, and ease of use. The MÄK Gateway is the right tool to use for translation between DIS and HLA. The Gateway is a separate application that listens for DIS traffic on the network, and translates it to HLA (and vice-versa). The MÄK Gateway has a graphical user interface that displays information about all of the objects and interactions on both sides of the Gateway, and how they relate. The Gateway is FOM-Agile, so that it can be tailored to support various FOMs on the HLA side. If the applications use MÄK’s VR-Link, you can take advantage of VR-Link’s FOM Mapping architecture to make all the federates natively support a common FOM. VR-Link uses an object called a FOM Mapper to map from the FOM-independent VR-Link API to a specific FOM. A FOM Mapper can be compiled into a DLL, and loaded by VR-Link as a plug-in. VR-Link’s default FOM Mapper supports the Real-Time Platform Reference FOM (RPR FOM), but users can build FOM Mappers for other FOMs that represent VR-Link concepts using different class or attribute names, data types, or data representations. You do not need to write a separate FOM Mapper for each application. A FOM Mapper can be written once, and plugged into any VR-Link application. In this way, a group of federates can all be made to support a common FOM. If some of the applications are not using a FOM-Agile architecture like VR-Link, then it may not be feasible to make all the federates natively support a common FOM. You will have to organize your system as a set of separate HLA federations connected through an "interoperability portal" application such as MÄK’s VR-Exchange. VR-Exchange is a universal translator for distributed simulation. Its architecture consists of a central Data Exchange in shared memory, and a set of Brokers to support a variety of protocols. When configured with two or more HLA Brokers, each configured with a FOM Mapper for a different FOM, VR-Exchange performs FOM-to-FOM translation, effectively bridging multiple HLA federations. Each Broker joins one federation, and translates data between that federation’s FOM and a lingua franca representation that is made available to the other Brokers through the central Data Exchange. MÄK has a variety of tools that help monitor and debug your exercises. The MÄK RTI’s RTIspy GUI dispells the notion that an RTI is a black box. The GUI provides a wide variety of information about the internal workings of the RTI, from the perspective of both the rtiexec and the Local RTI Components (LRCs). You can scan the list of known objects, find out what interactions have been sent and received, and view the current state of all FOM subscriptions and publications. The tool also helps to solve tricky timing problems by keeping a log of all federate-invoked and RTI-invoked services, and by displaying Time-Management parameters like current logical time, requested time, and LBTS for each federate. The network-monitoring panel allows you to plot bandwidth usage by object, both local and remote. Bar graphs show what percentage of CPU time is being used by the RTI and by FederateAmbassador callbacks. And the service instrumentation panel shows exactly how many microseconds each RTI call takes. If you want to view the contents of your DIS PDUs, and HLA updates and interactions, you can use the netdump or hlaNetdump diagnostic utilities that come with VR-Link. These applications listen to the DIS or HLA exercise, and print the decoded data to a console or file in human-readable form. It is easy to see that a federate is sending many more PDUs than you are expecting, or that an attribute value looks corrupt. The MÄK Stealth and MÄK Plan View Display (PVD) are also often used to debug federates, and diagnose problems. If your aircraft unexpectedly appears upside down in the Stealth’s 3D view, your federate might be sending incorrect orientation data. If a truck appears near the center of the Earth, you may not be doing coordinate conversions correctly. If an icon in the PVD is moving erratically, you may not be sending correct velocities and accelerations. The MÄK Stealth and MÄK PVD can also help you diagnose problems with electromagnetic emissions, aggregates, radios, and more. In addition to the graphical overlays that depict each of these concepts, you can also look at the current values for the various attributes in the Object Information windows. Finally, the MÄK Data Logger is a particularly valuable tool for diagnosing and debugging problems. Using the Data Logger, you can record a stream of traffic that crashes an application, and play it back repeatedly to reproduce the problem. The Logger can export HLA or DIS data to a SQL database for analysis in spreadsheets and tools like MATLAB. And the Logger File API allows you to programmatically search through recorded data, looking for specific problems. The MÄK Stealth (3D viewer), MÄK Plan View Display (2D Tactical Map Viewer), and MÄK Data Logger (Recording and Playback tool) are the key elements of an after-action review system. In fact, these tools are used together so frequently, that we offer them collectively as the ViewSuite at a reduced price compared to purchasing them separately. The MÄK Data Logger records the DIS (Distributed Interactive Simulation) or HLA (High-Level Architecture) traffic that is generated during an exercise to a quick-access binary file. When the exercise is over, the Logger can play back the file, effectively recreating the stream of data on the network. The MÄK PVD and MÄK Stealth receive this data, and draw the battlefield in 2D and 3D, respectively. From the PVD and Stealth’s perspective, data is coming in from the network just as if the simulated battle was live. During Logger playback, you can use the Data Logger’s GUI to pause time, play back slower or faster than real time, and jump to specific points in time. During playback, or even while the Logger is paused, you can take control of the Stealth’s eyepoint, view the world from any vantage point, or attach the eyepoint to any entity using a number of different view modes. Similarly, you can use the PVD’s interface to pan and zoom to any area of the battlefield, or have the map periodically re-center on an entity as it moves. Although the MÄK Stealth and MÄK PVD are separate applications, they work together as a well-integrated 2D/3D visualization solution. A "binoculars" icon is displayed on the PVD to indicate the location and orientation of the current Stealth eyepoint. The icon can be dragged or rotated, so that you can interactively control the Stealth’s 3D eyepoint from the 2D map. From the PVD, you can instruct the Stealth to attach to any entity, change view mode, or control the eyepoint from a Stealth navigation toobar. The PVD provides visual feedback on the state of the Stealth, including view mode and currently attached entity. Some MÄK customers have wanted to integrate the Stealth, PVD, and Logger into a single application, for example, with the 2D view on one tab, and the 3D view in another. Although we have not sold an integrated product like this, we have built custom AAR tools such as this under contract. Developers can do this integration as well, and create their own custom AAR tools using the Toolkit APIs provided with the Stealth, PVD, and Logger. VR-Forces^® is MÄK’s Computer-Generated Forces (CGF) application and toolkit. VR-Forces allows you to generate scenarios by placing entities, aggregates, and other objects into the scene using a 2D tactical-map interface. You can visually create waypoints, routes, and tactical graphics, and assign tasks and plans to the various entities. VR-Forces can then execute your scenario - performing physics-based simulation for each entity, and executing the statements in each entity’s plan. VR-Forces entities can automatically detect other entities, engage hostile forces, take damage, avoid collisions, and more. You can set up arbitrarily complex plans involving conditional statements, so that entities can alter their behavior based on the actions of the man-in-the-loop simulators that VR-Forces is interacting with. VR-Forces typically runs on a separate machine from the other applications in your exercise, and exchanges data with those applications via DIS or HLA. VR-Forces sends information on the network to describe the state of its locally simulated objects, so that they will appear in remote applications. It also listens for incoming DIS or HLA data from other applications, so that VR-Forces entities can interact with them, and display their icons on the GUI. Alternatively, you can build VR-Forces functionality directly into your simulation application. The Toolkit API allows you to initialize VR-Forces, and load and execute scenarios directly within your application. The API provides direct access to the state of all objects, allowing you to monitor and alter locations, plans, tasks, and other parameters. There are a few ways to accomplish this using MÄK’s tools. If your code is already part of a full simulation application that knows about terrain, world locations, etc., you might choose to just make your simulator DIS or HLA compliant using VR-Link. This will allow you to publish information about your entities onto the network, so that they can appear in other simulation applications, viewers, CGFs, etc. However, you may only have some standalone flight-dynamics, behavior, or sensor code (a model), and want to plug it into an existing simulation environment. You may want to drive your dynamics model from some existing behavior code, have your behavior model drive an existing physics-based model, or attach your sensor model to an existing entity. If this is your situation, the VR-Forces^® Toolkit API provides the perfect solution. Although VR-Forces includes a rich set of built-in vehicle models, every element of the product can be overridden through the API. The Toolkit makes it easy to register your own dynamics code, custom sensors, new behaviors, tasks, conditions, and entity types. When you use the VR-Forces API, you have access to VR-Forces’ terrain libraries, entity representations, and other objects and tactical graphics, and your model becomes part of an HLA- or DIS-compliant application. You will be able to create and task entities from the standard VR-Forces GUI, and add them to VR-Forces scenarios. When you execute the scenario, the code that you have plugged in will be executed, and will drive the behavior of the VR-Forces simulation. The VR-Forces^® toolkit is exactly what you need. VR-Forces is a modular Computer Generated Forces (CGF) toolkit that was built specifically with this use case in mind. We and our customers have successfully integrated VR-Forces with several different behavior engines. VR-Forces models are represented using independent sensor, controller, and actuator components. Actuators represent the physics associated with an entity, whereas controllers represent the driver or brain. VR-Forces actuators accept inputs such as steering, throttle, and brake values. Controllers can use whatever mechanism they want to decide how to control the entities, as long as they can generate appropriate inputs to the VR-Forces actuators. Several of MÄK’s tools can be used together to create a very compelling concept demonstration. Typically, you would start with VR-Forces, MÄK’s computer generated forces (CGF) toolkit, and extend the CGF with code to implement your new battlefield elements. You would then use the VR-Forces GUI to create a scenario that demonstrates the desired concepts. You would execute the scenario, and use the MÄK Data Logger to record the HLA or DIS traffic that VR-Forces generates. To show off your concept, you would play the Logger recording, while watching the replay of the battle in the MÄK Stealth or MÄK Plan View Display. To create a "hands-off" demo, in which the Stealth’s eyepoint automatically changes to focus on the critical aspects of your scenario, you can use VR-Link and the Stealth Control Toolkit to generate a stream of ViewControl PDUs or Interactions. You can then merge these into the Logger file, so that you have a single Logger file that includes the scenario data and ViewControl commands at the appropriate times. When you play the final Logger file, you will see the desired demonstration, rendered in real-time in the Stealth. If you want to record the Stealth’s output to an .avi file for video editing, a variety of 3rd-party video capture tools are available. Very often, the MÄK Stealth 3D viewer and MÄK Plan View Display (PVD) 2d viewer are used together to provide both a 3D perspective view and a big-picture tactical map-based display. The PVD's moving map display can be used ot view your entire terrain database, or to zoom into a particular area of interest. It depicts the position and orientation of all battlefield entities using MILSTD-2525B symbology, and includes overlay information that can be enabled and disabled dynamically (track histories, attacker-target lines, sensor coverage areas, aggregate bounding boxes, etc.). Meanwhile, the Stealth provides the 3D view that allows you to see th espatial relationships between entities, checkline of sight, or see the battle from the point of view of a pilot or driver. Alternatively, the StealthXR (Exaggerated Reality) add-on to the MÄK Stealth can provide a big picture view of the battle and an immense sense of perspective all in one tool. This "exaggerated reality" display delivers a common operating picture for simulation and command nad control environments that results in better decision-making and reduced uncertainty.

Problem

Solution

I have a stand alone simulation application (flight simulator, tank trainer, etc.), and I need it to interoperate with other simulation applications, so that my entities can interact with the entities simulated by the other systems in the same virtual world. How can I achieve this?
My simulator is DIS-compliant, but now I need to support HLA. How can I migrate this application to HLA?
I am running an exercise. Some of my simulation assets support DIS and some support HLA. I don’t have control over these applications, so I can’t convert the DIS applications to HLA, or vice-versa. How can I get them to communicate?
I have a set of applications that need to interoperate in a federation. The applications are HLA-compliant, but they support different Federation Object Models (FOMs). How can I get them to communicate?
I need some diagnostic tools to help me debug my distributed simulation applications. I want to be able to understand what simulation data is going over the network, so I can diagnose interoperability problems.
I need to record and play back my simulation exercise for after-action review. What tools do I need?
I have a man-in-the-loop simulator, and I need to provide targets, or additional computer-controlled entities to round out my simulation.
I have some high-fidelity dynamics code, behavior models, or sensor code, and I want to plug it into an existing synthetic environment, so that it can be exercised in a virtual battle.
I am developing a behavior editor, behavior engine, doctrine editor, or AI engine, and I would like to connect "brain" software to some existing "body" code - a physics-based model that my engine can drive.
I’d like to create a concept demonstration for a new weapon system, vehicle, tactic, or sensor, either for simulation-based acquisition or for a proposal for a simulation program.
I need a situation awareness tool that gives me a large-scale tactical or strategic view of a battlefield scenario, while also providing a 3D sense of perspective.

Most military simulation applications in the world adhere to one of two IEEE Standards for Simulation Interoperability - DIS (Distributed Interactive Simulation) or HLA (High-Level Architecture). So for your application to interoperate with other simulations, you will probably need to make your application DIS- or HLA-compliant.

MÄK’s VR-Link^®is an object-oriented C++ toolkit that simulation developers use to quickly and easily build HLA and DIS-compliant applications. It provides a set of libraries that implement a stable, consistent, and documented API (Application Programmer’s Interface) to the HLA and DIS protocols ― an SDK (Software Developer’s Kit) for interoperability. A few calls to VR-Link’s functions replace thousands of lines of code that you would otherwise need to write yourself, saving time and money on development and maintenance. If you need to be able to speak both HLA and DIS (or might have to in the future), then VR-Link is doubly valuable. That is because VR-Link implements both DIS and HLA through largely the same API. This means that you can write code once, and switch between HLA and DIS just by recompiling and linking with the appropriate versions of the VR-Link libraries.

The other MÄK tool that you might need is the MÄK RTI. An RTI, or Run-Time Infrastructure, is a required component of any HLA federation. According to the rules of HLA, various simulation applications, known as federates, use the RTI to exchange simulation data. (DIS is a wire-protocol and does not require an RTI). The MÄK High-Performance RTI is the industry’s leading RTI implementation. It has been verified by the Defense Modeling and Simulation Office as fully-compliant with both HLA 1.3 and the IEEE 1516 version of the HLA Standard, and has been proven and battle-tested in a variety of HLA federations throughout the world, both large and small.

There are several ways to migrate DIS federates to HLA, and MÄK’s products can help you implement any of these strategies. First, if your federate already uses MÄK’s VR-Link for its DIS compliance, then migrating to HLA is usually trivial. VR-Link supports DIS and HLA with the same top-level API, so most VR-Link-based applications can be migrated to HLA by just changing a few lines of initialization code and recompiling.

If your application does not use VR-Link yet, then using VR-Link is still the easiest way to make it natively HLA compliant. Your application makes calls to VR-Link’s C++ API, and VR-Link takes cares of sending and receiving data through the RTI, encoding and decoding it according to the rules of your Federation Object Model (FOM). Of course, VR-Link supports DIS as well, so once you have integrated with VR-Link for your HLA compliance, you may be able to eliminate the recurring expense of supporting a separate DIS interface.

If you do not have source code for your application, or are not able to modify the code, then you will not be able to make your application natively HLA compliant. But you can still participate in HLA federations using a Gateway. The MÄK Gateway is a separate application that translates between the DIS and HLA protocols, allowing your existing DIS application to interoperate with HLA federates without any modification.

Regardless of which approach you choose for supporting HLA, all HLA applications will need an RTI in order to communicate. The MÄK RTI is an excellent choice, due to its outstanding performance, fault tolerance, and ease of use.

The MÄK Gateway is the right tool to use for translation between DIS and HLA. The Gateway is a separate application that listens for DIS traffic on the network, and translates it to HLA (and vice-versa). The MÄK Gateway has a graphical user interface that displays information about all of the objects and interactions on both sides of the Gateway, and how they relate. The Gateway is FOM-Agile, so that it can be tailored to support various FOMs on the HLA side.

If the applications use MÄK’s VR-Link, you can take advantage of VR-Link’s FOM Mapping architecture to make all the federates natively support a common FOM. VR-Link uses an object called a FOM Mapper to map from the FOM-independent VR-Link API to a specific FOM. A FOM Mapper can be compiled into a DLL, and loaded by VR-Link as a plug-in. VR-Link’s default FOM Mapper supports the Real-Time Platform Reference FOM (RPR FOM), but users can build FOM Mappers for other FOMs that represent VR-Link concepts using different class or attribute names, data types, or data representations. You do not need to write a separate FOM Mapper for each application. A FOM Mapper can be written once, and plugged into any VR-Link application. In this way, a group of federates can all be made to support a common FOM.

If some of the applications are not using a FOM-Agile architecture like VR-Link, then it may not be feasible to make all the federates natively support a common FOM. You will have to organize your system as a set of separate HLA federations connected through an "interoperability portal" application such as MÄK’s VR-Exchange. VR-Exchange is a universal translator for distributed simulation. Its architecture consists of a central Data Exchange in shared memory, and a set of Brokers to support a variety of protocols. When configured with two or more HLA Brokers, each configured with a FOM Mapper for a different FOM, VR-Exchange performs FOM-to-FOM translation, effectively bridging multiple HLA federations. Each Broker joins one federation, and translates data between that federation’s FOM and a lingua franca representation that is made available to the other Brokers through the central Data Exchange.

MÄK has a variety of tools that help monitor and debug your exercises. The MÄK RTI’s RTIspy GUI dispells the notion that an RTI is a black box. The GUI provides a wide variety of information about the internal workings of the RTI, from the perspective of both the rtiexec and the Local RTI Components (LRCs). You can scan the list of known objects, find out what interactions have been sent and received, and view the current state of all FOM subscriptions and publications. The tool also helps to solve tricky timing problems by keeping a log of all federate-invoked and RTI-invoked services, and by displaying Time-Management parameters like current logical time, requested time, and LBTS for each federate. The network-monitoring panel allows you to plot bandwidth usage by object, both local and remote. Bar graphs show what percentage of CPU time is being used by the RTI and by FederateAmbassador callbacks. And the service instrumentation panel shows exactly how many microseconds each RTI call takes.

If you want to view the contents of your DIS PDUs, and HLA updates and interactions, you can use the netdump or hlaNetdump diagnostic utilities that come with VR-Link. These applications listen to the DIS or HLA exercise, and print the decoded data to a console or file in human-readable form. It is easy to see that a federate is sending many more PDUs than you are expecting, or that an attribute value looks corrupt.

The MÄK Stealth and MÄK Plan View Display (PVD) are also often used to debug federates, and diagnose problems. If your aircraft unexpectedly appears upside down in the Stealth’s 3D view, your federate might be sending incorrect orientation data. If a truck appears near the center of the Earth, you may not be doing coordinate conversions correctly. If an icon in the PVD is moving erratically, you may not be sending correct velocities and accelerations. The MÄK Stealth and MÄK PVD can also help you diagnose problems with electromagnetic emissions, aggregates, radios, and more. In addition to the graphical overlays that depict each of these concepts, you can also look at the current values for the various attributes in the Object Information windows.

Finally, the MÄK Data Logger is a particularly valuable tool for diagnosing and debugging problems. Using the Data Logger, you can record a stream of traffic that crashes an application, and play it back repeatedly to reproduce the problem. The Logger can export HLA or DIS data to a SQL database for analysis in spreadsheets and tools like MATLAB. And the Logger File API allows you to programmatically search through recorded data, looking for specific problems.

The MÄK Stealth (3D viewer), MÄK Plan View Display (2D Tactical Map Viewer), and MÄK Data Logger (Recording and Playback tool) are the key elements of an after-action review system. In fact, these tools are used together so frequently, that we offer them collectively as the ViewSuite at a reduced price compared to purchasing them separately.

The MÄK Data Logger records the DIS (Distributed Interactive Simulation) or HLA (High-Level Architecture) traffic that is generated during an exercise to a quick-access binary file. When the exercise is over, the Logger can play back the file, effectively recreating the stream of data on the network. The MÄK PVD and MÄK Stealth receive this data, and draw the battlefield in 2D and 3D, respectively. From the PVD and Stealth’s perspective, data is coming in from the network just as if the simulated battle was live. During Logger playback, you can use the Data Logger’s GUI to pause time, play back slower or faster than real time, and jump to specific points in time. During playback, or even while the Logger is paused, you can take control of the Stealth’s eyepoint, view the world from any vantage point, or attach the eyepoint to any entity using a number of different view modes. Similarly, you can use the PVD’s interface to pan and zoom to any area of the battlefield, or have the map periodically re-center on an entity as it moves.

Although the MÄK Stealth and MÄK PVD are separate applications, they work together as a well-integrated 2D/3D visualization solution. A "binoculars" icon is displayed on the PVD to indicate the location and orientation of the current Stealth eyepoint. The icon can be dragged or rotated, so that you can interactively control the Stealth’s 3D eyepoint from the 2D map. From the PVD, you can instruct the Stealth to attach to any entity, change view mode, or control the eyepoint from a Stealth navigation toobar. The PVD provides visual feedback on the state of the Stealth, including view mode and currently attached entity.

Some MÄK customers have wanted to integrate the Stealth, PVD, and Logger into a single application, for example, with the 2D view on one tab, and the 3D view in another. Although we have not sold an integrated product like this, we have built custom AAR tools such as this under contract.

Developers can do this integration as well, and create their own custom AAR tools using the Toolkit APIs provided with the Stealth, PVD, and Logger.

VR-Forces^® is MÄK’s Computer-Generated Forces (CGF) application and toolkit. VR-Forces allows you to generate scenarios by placing entities, aggregates, and other objects into the scene using a 2D tactical-map interface. You can visually create waypoints, routes, and tactical graphics, and assign tasks and plans to the various entities. VR-Forces can then execute your scenario - performing physics-based simulation for each entity, and executing the statements in each entity’s plan. VR-Forces entities can automatically detect other entities, engage hostile forces, take damage, avoid collisions, and more. You can set up arbitrarily complex plans involving conditional statements, so that entities can alter their behavior based on the actions of the man-in-the-loop simulators that VR-Forces is interacting with.

VR-Forces typically runs on a separate machine from the other applications in your exercise, and exchanges data with those applications via DIS or HLA. VR-Forces sends information on the network to describe the state of its locally simulated objects, so that they will appear in remote applications. It also listens for incoming DIS or HLA data from other applications, so that VR-Forces entities can interact with them, and display their icons on the GUI.

Alternatively, you can build VR-Forces functionality directly into your simulation application. The Toolkit API allows you to initialize VR-Forces, and load and execute scenarios directly within your application. The API provides direct access to the state of all objects, allowing you to monitor and alter locations, plans, tasks, and other parameters.

There are a few ways to accomplish this using MÄK’s tools. If your code is already part of a full simulation application that knows about terrain, world locations, etc., you might choose to just make your simulator DIS or HLA compliant using VR-Link. This will allow you to publish information about your entities onto the network, so that they can appear in other simulation applications, viewers, CGFs, etc.

However, you may only have some standalone flight-dynamics, behavior, or sensor code (a model), and want to plug it into an existing simulation environment. You may want to drive your dynamics model from some existing behavior code, have your behavior model drive an existing physics-based model, or attach your sensor model to an existing entity. If this is your situation, the VR-Forces^® Toolkit API provides the perfect solution.

Although VR-Forces includes a rich set of built-in vehicle models, every element of the product can be overridden through the API. The Toolkit makes it easy to register your own dynamics code, custom sensors, new behaviors, tasks, conditions, and entity types. When you use the VR-Forces API, you have access to VR-Forces’ terrain libraries, entity representations, and other objects and tactical graphics, and your model becomes part of an HLA- or DIS-compliant application. You will be able to create and task entities from the standard VR-Forces GUI, and add them to VR-Forces scenarios. When you execute the scenario, the code that you have plugged in will be executed, and will drive the behavior of the VR-Forces simulation.

The VR-Forces^® toolkit is exactly what you need. VR-Forces is a modular Computer Generated Forces (CGF) toolkit that was built specifically with this use case in mind. We and our customers have successfully integrated VR-Forces with several different behavior engines. VR-Forces models are represented using independent sensor, controller, and actuator components. Actuators represent the physics associated with an entity, whereas controllers represent the driver or brain. VR-Forces actuators accept inputs such as steering, throttle, and brake values. Controllers can use whatever mechanism they want to decide how to control the entities, as long as they can generate appropriate inputs to the VR-Forces actuators.

Several of MÄK’s tools can be used together to create a very compelling concept demonstration. Typically, you would start with VR-Forces, MÄK’s computer generated forces (CGF) toolkit, and extend the CGF with code to implement your new battlefield elements. You would then use the VR-Forces GUI to create a scenario that demonstrates the desired concepts. You would execute the scenario, and use the MÄK Data Logger to record the HLA or DIS traffic that VR-Forces generates. To show off your concept, you would play the Logger recording, while watching the replay of the battle in the MÄK Stealth or MÄK Plan View Display. To create a "hands-off" demo, in which the Stealth’s eyepoint automatically changes to focus on the critical aspects of your scenario, you can use VR-Link and the Stealth Control Toolkit to generate a stream of ViewControl PDUs or Interactions. You can then merge these into the Logger file, so that you have a single Logger file that includes the scenario data and ViewControl commands at the appropriate times. When you play the final Logger file, you will see the desired demonstration, rendered in real-time in the Stealth. If you want to record the Stealth’s output to an .avi file for video editing, a variety of 3rd-party video capture tools are available.

Very often, the MÄK Stealth 3D viewer and MÄK Plan View Display (PVD) 2d viewer are used together to provide both a 3D perspective view and a big-picture tactical map-based display. The PVD's moving map display can be used ot view your entire terrain database, or to zoom into a particular area of interest. It depicts the position and orientation of all battlefield entities using MILSTD-2525B symbology, and includes overlay information that can be enabled and disabled dynamically (track histories, attacker-target lines, sensor coverage areas, aggregate bounding boxes, etc.). Meanwhile, the Stealth provides the 3D view that allows you to see th espatial relationships between entities, checkline of sight, or see the battle from the point of view of a pilot or driver.

Alternatively, the StealthXR (Exaggerated Reality) add-on to the MÄK Stealth can provide a big picture view of the battle and an immense sense of perspective all in one tool. This "exaggerated reality" display delivers a common operating picture for simulation and command nad control environments that results in better decision-making and reduced uncertainty.

Products

Problems & Solutions