Please download and try out this new capability and send us any feedback.

ftp://ftp.mak.com/vantage/vrvantage.tot.vc8.2010-09-02.exe

ftp://ftp.mak.com/vantage/vrvantage.tot.vc9.2010-09-02.exe

ftp://ftp.mak.com/vantage/vrvantage.tot.rh5.2010-09-02.tar.gz

Feel free to show this video around or even reproduce the demo live using VR-Vantage XR!

[There is a video that cannot be displayed in this feed. Visit the blog entry to see the video.]

1. Who do you want to interact with, and what are they using?
2. Is your current solution working for you?
3. How much will it cost to do the upgrade?
4. What are the technical benefits of HLA Evolved?

Answering these questions isn’t easy either. Lets examine these questions with a bit more detail. Lets also work in reverse order.

In a labor-is-free (let’s do technology for the sake of beauty), HLA Evolved is by far the best version of HLA. So, if you are new to HLA, with no legacy code or federates, then HLA Evolved is for you. Unless of course you want to buy commercial tools; in that case there aren’t a lot available for HLA Evolved (yet). HLA Evolved has a number of features going for it that really make Federation design easier. The biggest feature is Modular FOMs, but let’s not discount the fact that its the first working IEEE-HLA standard too.  The ability to programmatically detect what other Federates are connected to the RTI is a big plus, so are the encoding helpers, which will reduce the SLOC required to write a Federate. The fact that HLA Evolved offers a DLC API and all the major RTI vendors either do, or are committed to supporting it, is a big plus too.

As for the cost of the upgrade, this one is the hardest question. To answer it you need to understand what exactly you will be writing (or have written) in HLA. If you have already upgraded to HLA 1516, then the move to HLA Evolved is going to be easy. The API is extremely similar with only a few minor tweaks. Actually, if you have already written your Federates in HLA 1516, then you SHOULD upgrade to HLA Evolved. The HLA 1516 standard was broken: no standard working API (different RTI vendors implemented different APIs), and don’t we all hate the way name reservations work? If your code is HLA 1.3, you have a bunch of work cut out for you. The work is strait forward and highly mechanical, but there is a lot of it to do. Not to many concepts change; there is still an RTI Ambassador, and a Federate Ambassador. Most of the function calls have similar names and similar signatures with only minor changes. However, you are going to have to touch all your HLA Code. Figuring out exactly how much will change can likely be computed by grepping through your code for any call to the RTI Ambassador or Federate Ambassador classes. If you are working in 1516, most of that code will remain the same. If you are working in 1.3, it’s all going to change.

Is your current solution working for you? If it is, why are you reading this? If you want a beautiful (or at least more beautiful) HLA interface, go ahead with the upgrade. You will have more flexibility when you go to extend your FOM. It will benefit you someday, as more and more federates move to support HLA Evolved.

Finally, there should be strong preference given to the HLA version used by other Federates you plan to interact with. On this count HLA 1.3 win’s hands down in the US, while HLA 1516 is winning in Europe. My gut feeling is that most of the HLA 1516 Federates will convert quickly to HLA Evolved. Additionally, we have seen strong interest in the US market to upgrade. Given all that, moving up may make sense.

Of course, no matter what version of HLA you pick, you will always find federates you wish you could interact with which are using a different version. The best approach perhaps is to hedge your bet and build your federate using something like VR-Link, where a source compatable API will allow you to natively support all three protocols. A less powerful hedge would be to use the MAK RTI, where wire compatibility will allow you to develop (or upgrade) your Federate in HLA Evolved, while still inter-operating with an HLA 1.3 or HLA 1516 Federate.

Upon first arriving, we took a look at their Federation Object Model (FOM) to get an idea of what types of objects and interactions they were sending through the RTI and how much data was being used. They did not have a very large federation object model, but start-up times as high as 20 minutes were not acceptable for their test federation consisting of 200 federates. During initial test runs we saw that their gigabit LAN never carried a load higher than 30% so the network did not appear to be the bottleneck.

During the start-up procedures, we did find several bottlenecks that needed addressing. The first was the subscription and publication messages. We found that the federates were subscribing to every attribute and interaction but only needed a few. Any time a subscription message is sent, every other federate responded with a publication message. With each federate subscribing to every attribute and interaction, this caused a flood of messages any time a new federate joined. To complicate matters, these internal messages were needed to be sent reliably which really bogged down the RTI forwarder.

To alleviate this, we first changed the federates to only publish and subscribe the messages they actually needed. This single change greatly reduced the load on the forwarder and the start-up time. We also reviewed which messages needed to be sent reliably vs which ones could be sent best effort. By changing some of the messages to best effort, we were again able to reduce the load on the forwarders.

We also made several changes to the way the RTI was configured that greatly helped reduce the load on the forwarders as well as the improve the start-up time of the federation. We enabled packet bundling and reduced the maximum packet size to fit within the network MTU (minus the UDP packet header size) as well as increase the size of the network buffers to alleviate overflow. Since they were using dual and quad core machines, we also moved network processing into an asynchronous thread to keep the buffers processing even when there was a high CPU load for the simulation.

The final change that we made was to move to a distributed forwarder setup. We used one TCP forwarder per 50-100 federates and made sure that multicast forwarding was disabled. Since all the machines were on the same LAN, rebroadcasting multicast traffic would have had negative results. Using the multiple TCP forwarders spread the TCP message processing load across all the forwarders at the cost of 1 additional network message per forwarder. An excellent trade-off for this customer.

After these changes, we were starting a federation of 300 federates in 5 minutes with a solid plan to scale to 500 federates by the end of the year and 1000 the year after.

New compilers are being created all the time. We try to trail “bleeding edge” by a version or two so that we limit our exposure to nasty compiler bugs in the newest releases. We’ll be adding support for MSVC 9 (32 and 64 bit) as well as adding 64 bit linux support (GCC 4.1). Unfortunately, this means we’ll be dropping support for MSVC 7 and Red Hat Enterprise Linux 4. It’s expensive to maintain endless amounts of platforms so we choose the most common platforms our customers are using and stick with those.

So in summary, the next version of VR-Vantage will be supported on the following platforms/ compilers:

• MSVC 8 (32 bit)
• MSVC 9 (32/ 64 bit)
• RH5 (GCC 4.1, 32/64 bit)

As always, if you have a special circumstances, we will try to oblige as best we can. Just contact us and let us know.

Version 4.0 supports the full C++ HLA Evolved API, and customers under active maintenance can download it and use it with no additional license right away.

Please contact your sales representative for the download link, or request a link here.

To do this, you would write something like this. Note, the only difference is that wide strings (std::wstring)  are used for the Object class handle.

HLA 1.3

   RTI::ObjectClassHandle theClassHandle = rtiAmb.getObjectClassHandle("BaseEntity");

HLA 1516 & Evolved

   RTI::ObjectClassHandle theClassHandle = rtiAmb.getObjectClassHandle(L"BaseEntity");

Now we need to get the Attribute Handles for all the attributes we will be publishing and subscribing to. In this example the list of attributes is the same, but that isn’t always true in real federates. Here is a big difference between HLA 1.3 and 1516 (and Evolved): as of 1516 the HLA standard API starts using C++ iterators, instead of non-standard container classes. In HLA 1.3, you need to create a class RTI::AttributeHandleSet which has a HLA specific interface. In HLA 1516, and Evolved, the  RTI::AttributeHandleSet is defined as:

typedef std::set< AttributeHandle > AttributeHandleSet;

This usage of C++ STL is a common change throughout the HLA standard in 1516 (and Evolved) which makes things slightly less verbose, and much more familiar to a C++ developer otherwise unfamiliar with HLA. Additionally, you will notice the order of the arguments changes. An annoying, but simple change.

HLA 1.3

   std::map<std::string, RTI::AttributeHandle> theAttrNameHandleMap;
   theAttrNameHandleMap["AccelerationVector"] = rtiAmb.getAttributeHandle("AccelerationVector", theClassHandle);
   ...
   RTI::AttributeHandleSet* hSet =  RTI::AttributeHandleSetFactory::create(theAttrNameHandleMap.size());
   for (DtAttrNameHandleMap::iterator iter = theAttrNameHandleMap.begin();
   iter != theAttrNameHandleMap.end(); iter++)
   {
      hSet->add(iter->second);
   }

   rtiAmb.publishObjectClass(theClassHandle, *hSet);
   rtiAmb.subscribeObjectClassAttributes(theClassHandle, *hSet);

HLA 1516 & Evolved

   RTI::AttributeHandleSet hSet;
   typedef std::map<std::wstring, RTI::AttributeHandle>  theAttrNameHandleMap
   theAttrNameHandleMap[L"AccelerationVector"] =  rtiAmb.getAttributeHandle(theClassHandle, L"AccelerationVector");
   hSet.insert(theAttrNameHandleMap[attrName]);

   ...
   rtiAmb.publishObjectClassAttributes(theClassHandle, hSet);
   rtiAmb.subscribeObjectClassAttributes(theClassHandle, hSet);

With Declaration Management Service, making an exception for the use of using STL to manage lists, maps, and sets, there are very few differences between HLA 1.3 and 1516. Each of the publish/subscribe calls has a matching unsubscribe call.

Additionally, each of these calls throws a number of exceptions. The exception list hasn’t change significantly except to add NotConnected to HLA Evolved, which will throw if the RTI has lost connectivity with its forwarder: typically if a network cable has been unplugged.

If you are using VR-Link, all this will be done for you when you create your Object Publisher class, or Reflected List:

 DtEntityPublisher myEnt;

or

 DtReflectedEntityList myEntList;

In each case VR-Link will register interest in all attributes (or publish all attributes). However, VR-Link supports the ability to change which attributes you will publish or subscribe to. For more information on this, please see the VR-Link documentation.

In my next posting I will discuss Object Management Services.

We saw this as a great opportunity to demonstrate that MÄK isn’t just about military scenarios and that the combination of our off-the-shelf COTS products and in-house expertise lets us quickly respond to the needs of our customers.

There was one minor problem. We didn’t have any train stations. Not to worry. After a brief kick-off meeting that provided general direction for the project, Petr Kyn, our Art Director, created a small subway station. In a day and a half, he had a prototype that was good enough to start scenario development in VR-Forces. It had a terminal area, turnstyles, a platform, and a four-car train. The station had path data, which allowed us to use the AI capabilities in the B-HAVE Module for VR-Forces to control entity movement. Another day or two and the station was complete with tile, translucent windows in the train and kiosks, and artwork on the walls.

In the meantime, Fred Wersan, our technical writer, got to work on the scenario. Most of the scenario was essentially background activity – lots of people moving off of and onto the train and moving through the station. In the middle of this activity, something had to happen. The basic scenario had a person carry a duffel bag onto the platform, drop it under a bench, and then walk away. Thirty seconds later the duffel bag explodes, leading to a panicked exodus from the station. Alternative versions have the bag detected and the station evacuated before it explodes, or is disarmed.

The basic scenario and background activity took just a few hours. Creating entities takes a matter of minutes. Creating plans so that they don’t all do the same thing, at the same time, in the same place, is time consuming, but not difficult, since you can copy plans from one entity to the next and then individualize them. With B-HAVE controlling entity movement, you just have to tell an entity to go someplace, wander, or flee, and don’t have to plot their individual movements.

Fred had to make a few modifications to VR-Forces and VR-Vantage. VR-Forces doesn’t come with an exploding duffel bag or park benches that can burn. However, by creating new entities in VR-Forces’ Entity Editor, and mapping them to the proper models in VR-Vantage, everything looked just the way it had to. All of these changes are accessible to any end-user of these products. No programming was needed.

After some feedback from our sales staff and a few iterations of scenario development, the project was done – less than a week after the kick-off meeting.

The customer was pleased.

Some background before I get started: For most of my code I will use RTI Simple, the sample federate which is distributed with the MAK RTI. If you are interested in the complete source for a similar federate, you can get it by downloading the RTI. I will also be ignoring most of the basic format structure which is integral to C++ design. No need to discuss or even show:

int main(int argc, char** argv)
{

Additionally, I assume the reader has a good understanding of HLA in general; the reader has strong familiarity with HLA 1.3, but perhaps may not be familiar with HLA 1516 or HLA Evolved.

In this first Blog I will discuss connections: how to get a basic federate to create a federation, connect to, and join a federation.  I will skip over the implementation of the Federate Ambassador for the moment.

Before we create or connect to anything, we need to create an RTI Ambassador and a Federate Ambassador. The steps for creating the RTI Ambassador are different between HLA 1.3 and 1516, but have not changed in Evolved:

RTIambassador* rtiAmb = 0;

HLA 1.3

rtiAmb = new RTIambassador;

HLA 1516

RTIambassadorFactory* rtiAmbFactory = new RTIambassadorFactory();
std::auto_ptr < RTIambassador > rtiAmbAP = rtiAmbFactory->createRTIambassador(args);
rtiAmb = rtiAmbAP.release();

HLA Evolved

RTIambassadorFactory* rtiAmbFactory = new RTIambassadorFactory();
std::auto_ptr < RTIambassador > rtiAmbAP = rtiAmbFactory->createRTIambassador();
rtiAmb = rtiAmbAP.release();

Once you create the RTI Ambassador, you need to create the Federate Ambassador, a class written by the federate developer. The Federate Ambassador has changed quite a bit between versions of the RTI, but I will focus on that at some later point.

At this point, HLA Evolved differs from the other HLA versions a bit. In HLA Evolved, there is now a concept of Connection. This represents the physical connection to the RTI from the LRC. To connect you do this:

HLA Evolved (only)

rtiAmb.connect(fedAmb, HLA_EVOKED);

After you have successfully connected (HLA Evolved Only), you need to try to create the Federation. While you could skip this step if you know the federation is already created, it’s better to do it just the same.

HLA 1.3

char * fedName;
char * fedFile;

HLA 1516

std::wstring fedName;
std::wstring fedFile;

HLA Evolved

std::wstring fedName;
std::wstring fedFile;

ALL

try
{
   rtiAmb.createFederationExecution(fedName, fedFile);
}
catch(RTI::FederationExecutionAlreadyExists& ex)
{
   cout  << "Could not create Federation Execution: "
   << "FederationExecutionAlreadyExists: "
   <<  ex._name << " "
   << ex._reason << endl;
   // intentionally continue, as this exception just indicates
   // that this federate isn’t the first joiner.
}

The code to join all looks the same, but there are differences behind the scenes.  In HLA 1.3 you get what you see, but in Evolved you have options.  Here is where FOM Modules kick in. For this example, since we are targeting the process of updating a federate, we will ignore the changes, except to mention that there is a defect in the RTI Ambassador API here:

// variation 1
virtual void createFederationExecution (
   std::wstring const & federationExecutionName,
   std::wstring const & fomModule,
   std::wstring const & logicalTimeImplementationName = L"")
   throw (…

// variation 2
virtual void createFederationExecution (
   std::wstring const & federationExecutionName,
   std::vector<std::wstring> const & fomModules,
   std::wstring const & logicalTimeImplementationName = L"")
   throw (…

// variation 3
virtual void createFederationExecution (
   std::wstring const & federationExecutionName,
   std::vector<std::wstring> const & fomModules,
   std::wstring const & mimModule,
   std::wstring const & logicalTimeImplementationName = L"")
   throw (…

Depending on your usage, variation 2 and 3 are ambiguous. Consider the following code:

createFederationExecution( L"FedExName", vectorOfFomModules, L"" );

It is not clear whether you are using variation 2 or 3, and the compiler will throw an error. To avoid this error you should always use variation three. If you do not want to specify a mimModule, then pass in an empty string.

Now that you have created your Federation, you need to join it:

HLA 1.3

char* federateType;
char* federationName;
…

theFederateHandle = rtiAmb.joinFederationExecution(federateType,   federationName, fedAmb);

HLA 1516

std::wstring federateType;
std::wstring federationName;
….

theFederateHandle = rtiAmb.joinFederationExecution(federateType, federationName);

HLA Evolved

std::wstring federateType;
std::wstring federationName;
std::wstring federateName;
…

theFederateHandle = rtiAmb.joinFederationExecution(federateName, federateType,  federationName);

Here, besides the familiar conversion from char* to std::wstring for all strings, HLA Evolved allows you to specify a name for your federate. This is likely to be confusing, as frequently the type has been historically used as the name.  HLA Evolved fixes thing: the name is just that, a unique name for an instance of a Federate. The type is not required to be unique and can describe the class of the Federate.  If you don’t choose a name, the RTI will choose one for you. In HLA Evolved, there are multiple version of joinFederationExecution which will provide source compatibility with HLA 1516.

There is one more major addition to the Join call in HLA Evolved: If you are using FOM Modules you can now specify additional FOM Modules to load:

virtual FederateHandle joinFederationExecution (
   std::wstring const & federateType,
   std::wstring const & federationExecutionName,
   std::vector<std::wstring> const & additionalFomModules=std::vector<std::wstring>())
   throw (…

virtual FederateHandle joinFederationExecution (
   std::wstring const & federateName,
   std::wstring const & federateType,
   std::wstring const & federationExecutionName,
   std::vector<std::wstring> const & additionalFomModules=std::vector<std::wstring>())
   throw (…

If you get this far, and I apologize because this is a long Blog, you have a federate which has successfully fully connected to the RTI and you are ready to begin publishing/reflecting objects.

For those of you using VR-Link: You will need to make no changes to the way you connect to the RTI. The following code will still work:

int main(int argc, char **argv)
{
   DtVrlApplicationInitializer appInit(argc, argv, "VR-Link Talk");
   DtExerciseConn exConn(appInit);



Have you built something cool using VR-Vantage? Or maybe even a great scenario using VR-Forces that looks great when viewed with VR-Vantage applications like VR-Vantage XR?

Just go check out the contest information at http://www.mak.com/vrvcontest and enter to win!

[There is a video that cannot be displayed in this feed. Visit the blog entry to see the video.]

Currently the RTI team is done with development and working through the Quality Assurance process. At the moment, it looks like the release is about two weeks away. For RTI customers wishing to use HLA Evolved: your RTI is coming up. For those of you who will continue to use HLA 1.3 and HLA 1516, this release of the RTI will provide a number of bug fixes so we recommend you upgrade also. Like all RTI releases the upgrade process should be painless. However, for developers there will be one minor change: Because the C++ header files have the same names for both HLA 1516-2000 and HLA Evolved, we have had to change the structure of the include directory. This minor change will mean people developing HLA Federates will need to change the include file path in their development environment. Additionally, we have renamed some of the RID parameters to make things more consistant with HLA Evolved Switches (Also to make configuration easier in general). More detailed information about these changes can be found in the release notes of the release. As is the MAK way, we want to encurrage interoperability between HLA Evolved and other HLA versions. Therefore, our wire standard remains compatible between all three versions of HLA. We call this a mixed mode federation.  That means you will be able to run HLA Evolved Federates with HLA 1.3 Federates and HLA 1516 Federates. Some restrictions will apply, but as with HLA 1.3 and HLA 1516 mixed mode federations, they are limited.

VR-Link 4.0 is currently in development. We actually have most of the work done, but need to do a lot more testing and greatly improve our examples. We expect a release in September with full support for HLA Evolved. The good news is, we believe we can preserve source compatibility between releases. This means you should really be able to just recompile your federate with new C++ preprocessor flags to build an HLA Evolved federate.  Migration of a VR-Link federate to HLA Evolved should take you about as long as it takes you now to compile your existing federate.  If you want to take advantage of some of the new features of HLA Evolved, like modular FOMs, or Update Rate Reduction, that’s going to take a bit longer. However, using the easy to use VR-Link API, even that will be fairly trivial.

Starting now, logged in users can comment on any new Blog post. Unfortunately, because we live in a world of SPAM, users need to log-in to verify that you are a real person. Additionally, we will moderate all posted comments. That said, we will likely approve all comments that are respectful and on-topic, no matter what the viewpoint. So comment away!

If you have any additional feed back on ways we can improve communications with you, please feel free to write to support@mak.com, or comment on this post

We’re planning lots of stuff in this release: visualization of aggregates, visualization of feature data, sensor volumes, inter-visibility lines, radio communication lines and much more. And all those features are being built for both 2D and 3D!

During our development cycle, we will release “Top Of Tree” (TOT) development snapshots when features are completed. These will be installable releases that customers can download and try out (or use) at their own discretion. Theses snapshots are unsupported releases that didn’t go through QA, however we still want to give our users access to let them preview new features and submit feedback during the development cycle. We’ll post the links  here when they are ready.

While federate design is by far the largest factor, there are several RID parameters that will certainly have an impact:

RTI_fomDataReliableWhenUsingRtiexec: To be fully compliant this parameter should be enabled. However, sending data best effort is certainly faster. Of course sending data best effort also means you run the risk of dropping messages.

RTI_forceFomDataReliable: Similar to the above parameter. The above parameter only tells the RTI it can send data reliably if the FED file says it should be. This parameter forces data to be sent reliably, regardless of the FED file.

RTI_processingModel: This can definitely have an impact. Processing models 1, 2, and 3 definitely have more overhead than processing model 1. However, processing model 3 also means that the federate will receive callbacks in a separate thread without having to tick. This certainly has the potential to reduce latency if used correctly, but this choice must be considered when designing your federates.

RTI_enableLrcWebservice: I would recommend disabling the LRC RTIspy web service if you are trying to maximize performance. This definitely increases overhead.

RTI_notifyLevel: Increasing the notify level also slows things down a bit as the RTI spends more time printing messages to the display and/or to the log file. If you would like to generate a log file but have as little impact on performance as possible, I would suggest dropping RTI_detachNotifyLevelFromStdOut down to 0. This will prevent the RTI from printing anything to std::out.

RTI_tcpNoDelay: Sets the TCP_NODELAY socket option.

RTI_enableTcpCompression & RTI_enableUdpCompression: Compression helps to optimize bandwidth utilization, but it will also increase latency and CPU utilization as the RTI will have to compress and uncompress each message.

RTI_enablePacketBundling: Bundling will reduce bandwidth and CPU utilization, but will also increase latency as the RTI waits for additional messages to fill the bundle before sending.

RTI_enableMessageThrottling: Specifically affects internal messages, not updates or interactions. Helps with congestion, but will result in delaying the sending of messages.

RTI_smartForwardingLevel: Can help save CPU utilization if used properly, but requires more overhead in the forwarder.

These are the RID parameters which have the largest effect; others may have a smaller but still significant effect.

The easiest way to tell what is taking the most time is to use the MAK RTI’s built in latency test found in the RTI Assistant. By clicking on a Federate in the RTI Federations View, you can see all the round trip times between that federate and every other federate. In the example below, you can see that the majority of the latency occurred when the message was sitting in a queue waiting for the receiving federate to read it.

The truth is, there are a lot of terms used with RTIs and HLA in general, they can be confusing for a newcomer, and what’s worse, people who know better frequently use terms which further confuse the issue.

Today I wanted to post a table of RTI/HLA terms and definitions. My hope is this table will make someone’s life easier.

Additionally, people are frequently confused about the terms used for the various versions of HLA. Here is a small table which describes each of them:

We intend to add better sound capability to VR-Vantage in the future, one that is aware of multiple observers and different channels, but this was just too easy to do we couldn’t let our customers wait.

No worries, those of you who have used the rtiexec recently know you can still control it from the command line using the “rti” command.

And, of course all the information formerly displayed in the rtiexec GUI is now displayed by the RTI Assistant with the Federation View Dialog, and the Network Component View Dialog. But why did we do it?

We made all the changes for one simple reason: Reliability. Many years ago I heard a customer complain: “If I run the rtiexec without the GUI it will run forever; if I run the rtiexec with the GUI it will crash after a few days.” That hurt. With or without the GUI we want the rtiexec to just run forever. The problem is twofold:

1. Complexity: Adding all that GUI code to the rtiexec executable made it complex, which meant there was a higher probability of bugs. The GUI code more than doubled the size of the rtiexec. Additionally, we were using 3rd Party libraries which we didn’t always have the source code to, meaning we were susceptible to other developer’s bugs.
2. Performance: Not only was the rtiexec processing packets in your federation, but it was also monitoring and updating the GUI.

By moving all the user interface functionality to a separate process several advantages unfolded:

1. We designed the RTI Assistant to handle all UI tasks, it’s the single UI code base. Yes, the ‘rti’ command from above is just the assistant without a GUI. By having a single user interface we greatly simplified the code path for user interaction.
2. We also designed the RTI Assistant to be able to crash and not bring down a federation. Go ahead. Kill it from the task manager and you will see the rtiexec and RTI Forwarder will stay running. Additionally, they will try to restart the RTI Assistant.
3. The rtiexec now can run on a separate processor from all the GUI components, allowing it to do its job of managing federations while not being bogged down displaying information on the screen and reacting to user input. Information is still passed to the RTI Assistant, but it’s a very small and well controlled process. Additionally, information is passed to the RTI Assistant at controlled times. Now the rtiexec picks when it can send status; the RTI Assistant stores all this information and displays it when the users request it.
4. The code base for the rtiexec is extremely compact and simple. It means a lower probability of bugs and therefore increased stability. Further, we at MAK now keep it running ALL THE TIME on our desktops. Mine runs until I reboot my machine which is sometimes months. This is possible because it doesn’t contribute to screen clutter (in fact, it’s hard to know it’s even running if you don’t think about it)
5. We have broken the administration of the RTI into something (somewhat) similar to a Model View Controller design. Information (the View) is available anywhere on your network, not just on your local machine. It means you can run only the rtiexec on machine X and view its output from machine Y. The rtiexec is the “model” and the RTI Assistant is the viewer and the controller.
6. Remote start: If you are running the RTI Assistant on machine X, you can start an rtiexec on machine X from anywhere on the network.

Now hopefully you agree: the rtiexec without a user interface is a beautiful thing.

When adding features to a product we frequently need to make design decisions. Often these decisions come after many hours of sometimes heated arguments. Today I want to write about one of the design decisions we made with the RTI, and what its implications for the future are. I want to talk about the two main information dialogs in the RTI Assistant: the Federations View, and the Network Component View. We call them the FCV (for Federations Component View), and the NCV(Network Component View).

Both of these dialogs can be found next to each other in the RTI Tray menu. For those who don’t know, the tray menu is part of the RTI Assistant, which was introduced in RTI Version 3.2.

In many respects these two dialogs appear to have similar functions, each lists the currently connection federates for a given connection. If you have the RTI running as you read this, feel free to pull up the dialogs.

You will notice a few quick differences. First, the NCV will list an rtiexec, and an RTI Forwarder (if you choose a connection with an rtiexec), the FCV will not show these components. Additionally, the NCV may just list “Federate” and not give the Federate’s name.

These dialogs are showing two different views of the same connection. The NCV is responsible for showing network connection information, and the FCV is responsible for showing simulation level connection information. Think about it this way: at the NCV level everything is just RTI packets, and the FCV level there are objects, and interactions.

Let’s look at the differences in a little more detail. The NCV contains information about the RTI Forwarder, RTI Exec, components which have very little to do with the simulation of an exercise. In fact, there is no requirement in the HLA Spec for an rtiexec; it’s possible to implement reliable transport without using TCP (it’s harder, but it’s possible). Think of this as the quiet infrastructure which federates require for communication; just like your router on your LAN. At the RTI Forwarder level and the RTI Exec level, you don’t need to think about a federation name, or a federate name, you just want to make sure packets get from one LRC to the next. The FCV is different; the FCV is reporting information about your simulation. What federates talk to what other federates. At this level the RTI Exec isn’t important. You just want to make sure vehicle X sees vehicle Y.

When you think about this, it all makes sense, when you write an application that links to the RTI LRC, the application is running before it has joined a federation or given the RTI its Federate Name; it’s connected to the RTI before its even a federate. In HLA Evolved this is partially referred to as the Connection. It means applications are connected to the RTI infrastructure before they are connected at the simulation level. When a Federate resigns, it doesn’t mean the application has exited. In this context the NCV will report errors and information from applications which are running but still haven’t joined a federation (or who have already resigned).

Now that you know the fundamental difference between the NCV and the FCV, you can see where new features will be added. We plan to add information about the application which is running (like the command lines used etc.) to the NCV. Any information about objects, or interactions will be added to the FCV. Currently most of this information is displayed in the Web Spy, but who knows what the future has in store.

HLA Evolved is the working term for the latest version of IEEE-1516 and offers some pretty cool features. For background on the standard there are a number of papers and FAQs about what is new in HLA Evolved. Links to these papers can be found at the MÄK web site here (http://www.mak.com/community/whitepapers.php). I’d like to share MÄK’s plans to support HLA Evolved.

As many of you know, MÄK has been heavily involved with the development of the HLA Evolved Standard. We view HLA Evolved as an important milestone and have committed to releasing our RTI with full HLA Evolved support once the standard was finalized. We are pleased to announce that the MÄK RTI version 4.0 will be released this July with full support for the HLA Evolved C++ API.

Of course, what good is HLA Evolved without a suite of tools to help you use it? To compliment the RTI, we will simultaneously release VR-Link 4.0 with HLA Evolved support. This will allow customers who have relied on VR-Link to provide them with the latest updates to interoperability standards (like DIS, HLA, and the RPR FOM) to upgrade federates with minimal code changes to the new HLA Evolved Standard.

Additionally, we are committing to upgrading the other MÄK Link products throughout the rest of 2010. That means upgrades for VR-Exchange and the MÄK Data Logger will occur later this year.

We do not currently have a schedule for VR-Forces or VR-Vantage upgrades. If you are interested in support for HLA Evolved for these products please let your sales representative know (sales@mak.com).

Finally, I would like to thank everyone at MÄK who has worked so hard to make this possible: Len Granowetter, Doug Wood, and Ben Watrous who spent many hours working on the HLA Evolved Standard as well as the original SISO DLC API which started us on this road. Thanks also go to Rob Farraher, Aaron Dubois, Nils Reker, Doug Armstrong, and Anthony Merrill who have worked hard on implementation, testing, and API verification.

As we have grown into a fairly large company, we have maintained a support process of a small company. We don’t have support engineers, when you write to support@mak.com, or call us, you will talk to an engineer who is a member of the team for the product you have a question about. That means, if you call with a VR-Forces question, you’re going to talk to someone on the VR-Forces team; it could be the lead engineer. On smaller projects it will be the lead engineer.

Essentially, our process works like this: when you write to support, the entire engineering team, sales team, and management team see the message. Each engineering team is responsible for responding to questions about their products. Frequently you speak to someone who designed the feature in the first place. However, the entire MAK team is encouraged to respond if they know the answer. Sometimes this leads to customers receiving multiple simultaneous responses. When this happens we hope you get two of the same answer!

We follow this process for a few reasons: First, we want our customers to feel like they can talk to an “engineer down the hall.” That means you get the best answer you can as fast as you can. We want to help you work on your project just like it’s our project. Additionally, we want our engineers to interface with customers. We want the whole team to know what our customers are doing, what problems they are having, and then become advocates for making things easier for our customers. If 100 customers call because doing X is difficult, then darn it, we need to make it easier.

For those of you who like this process, and we believe that is almost all of you, rest assured, we like it to. It works, and we are going to keep it. How we implement it is going to change slightly. Currently, when you write to support, it goes into a shared email account which all engineers log-into and check. We manage support email by shuffling around email messages between several shared folders. Unfortunately, with our current volume of support sometimes this mechanism causes questions are get lost; this is what is going to change.

Over the next few weeks we will be moving to a ticket tracking system, where incoming support is automatically assigned a ticket number and then placed in a database. Everyone, just like before, will use a web (or desktop) client to claim tickets and respond to them. This will probably prevent multiple people from responding at the same time, but everyone will still see it. Additionally, this means that customers will get a ticket number when you write to support for the first time. All correspondence with regards to the particular issue will use the ticket number.

If you write to us with a multiple questions about different products, we may break your email up into multiple threads, so that multiple engineers can work on it at the same time. While this may sometimes be slightly more cumbersome, we just want to make sure we answer all the questions as fast as possible, and don’t accidently miss one.

Additionally, later this summer we will be rolling out some form of customer web interface. We don’t have all the details worked out on this yet, but the goal is to provide a way for customers to log-in and see the progress on all the support questions they have submitted. This will be 100% in complimentary to the support phone number and email address. If you prefer to communicate via email or phone, you will always be able to do that too. Rather, our goal is to increase the number of ways you can communicate with us so you can pick the one that suites your situation best!

Finally, I would like to add. Please keep writing to us! We really like to hear from our customers. While some companies use their support system as only a channel for reporting bugs, we like to hear what you want to say. If you think things work well, please let us know. If you think we could do something better, we really want to hear from you. If you just need some advice on how best to proceed, give us a ring. If you have a strong opinion about this blog, don’t hesitate to write.

Thanks! I look forward to hearing from you at support@mak.com .

When you have a problem, and write to support, we will frequently ask you to send two things: your license file and your license server log. Sending these with your initial inquiry will typically save a lot of time.

First, it’s important to understand what’s in your license file. Also please note you may have one or more license files. I will use the license file below as an example; this file contains one license for the MÄK Data Logger, and one license for VR-Link.

SERVER oak 000bdb511138
DAEMON maklmgrd ./maklmgrd
PACKAGE vrl maklmgrd 2010.113 ccccD081E2C6CD700000 COMPONENTS="hvl1 \
	hvl2 dvl1 dvl2 vl3"
PACKAGE logger maklmgrd 2010.113 ccccC0B11111C4900000
	COMPONENTS="hlog1 dlog1 log1"
INCREMENT vrl maklmgrd 2010.113 permanent 1 cccc3111118085500000 \
	PLATFORMS=i86_n
INCREMENT logger maklmgrd 2010.113 permanent 1 cccc11111B3770A00000 \
	PLATFORMS=i86_n

If a customer sent us this license file with a problem there are a few important things we would take note of:

1. It’s a server based license which needs to be run on a machine named “oak” with a lmhostid (it’s your mac-address on the server machine) of “000bdb511138”.
2. The PACKAGE’s are important: “logger” and “vrl” mean the customer is entitled to VR-Link and the Logger.
3. The maintenance expiration date is 2010.113. That means the license is good for all the versions which were released before the 113^thday of 2010.
4. The COMPONENTS part is seldom relevant. It’s machine generated and pretty much never wrong.

Item #3 is important and often a large source of confusion. Knowing the maintenance date will allow you to look at our web site (http://www.mak.com/products/productversions.php) to determine which versions of products you are entitled to. Problems with the maintenance date will show up with a FlexLM Error dialog (or in the Log) saying something like:

License server system does not support this version of this feature.

That error means you have a license to use the product, but your maintenance isn’t up-to date and therefore you aren’t entitled to use this version of the product. It typically means your maintenance isn’t up to date. However, you should only pay attention to this error when your MAK application does not actually work.

Here’s the catch: many users see this error in their license file but don’t have any problems running the actual application. A customer will run into this “error” when they are trying to figure out a different problem or are just looking through the license server. Careful inspection of the license log will show something like this:

7:14:38 (maklmgrd) DENIED: "rti5" jim@oak  (License server system
does not support this version of this feature. (-25,334))
7:14:38 (maklmgrd) OUT: "rti5" jim@oak

Typically the DENIED keyword catches people’s attention. However, in this situation the “problem” is benign. This line will occur because there are actually two entitlements in the license file (or files): The original license which has expired and an upgrade when maintenance was renewed. You should be able to confirm this by looking for INCREMENT and UPDATE lines which will be listed when the license server starts (at the top of the file). This is entirely expected behavior. The license server tries to check out a license from the first license file it finds. If it doesn’t succeed, it tries the second. These types of errors can be safely ignored. So sleep well tonight!

When I joined MAK we were selling a Gateway product called “The MAK Gateway.” It was a great product. Its user interface looked like this:

If you wanted to use it, you had to know an arcane gateway language which looked something like this:

h b <Enter>

h t <Enter>

h b” started the gateway, and “h t” started translation. I don’t know what the “h” command was, and I assume “b” was for Begin.

Other commands included “h p[u] o [class] *”. Using it was somewhat like finding your home directory in VMS: about as intuitive as booting from a tape. I, of course, was assigned to support the product, which was only slightly harder than using it. The code base came from a larger and older SAF system and finding anything in the code was difficult to say the least.

The real cause of the 1^stgeneration Gateway’s demise was its lack of FOM-Agility. At the time of its demise the RPR FOM was undergoing heavy revisions toward version 2 and customers were using more and more divergent FOMs. Expanding the codebase for the Gateway was going to be expensive and we wanted to provide a mechanism for customers to do it themselves. Hence, the VR-Link Gateway was born.

The VRL Gateway was built with VR-Link, hence the ‘VRL’ part of its name. VR-Link already had support for DIS and HLA in a FOM Agile way. Additionally, VR-Link readily supported newer versions of the RPR FOM. It also had a decent customer base writing FOM Mappers. VR-Link would prove to be a simple architecture for building a Gateway. There was just one problem: VR-Link was designed with different libraries for different protocols containing classes with the same symbol names. For example there were two versions of the DtExerciseConn class: one for DIS and one for HLA. It was almost impossible to link both libraries into the same application. To fix this, we ended up rebuilding the VR-Link libraries with modified symbols… something like DIS_DtExerciseConn and HLA13_DtExerciseConn. This worked great but prevented us from ever releasing a toolkit for the Gateway. It meant customers with custom PDUs and FOM extensions could never use the VRL Gateway.

The VRL Gateway looked like this:

Given its new FOM Agility the VRL Gateway was named the MAK FOM Agile Gateway version 4.0. It showed you much of what was going through it. It was FOM Agile, so it worked with various FOMs which weren’t the RPR FOM. Additionally it quickly expanded to support 1516. In pretty much every way it was a huge success. Sales went up and a large customer base developed. Initially many of its tasks were to bridge two DIS networks across a WAN with no HLA Federates (other than the VRL Gateway) involved. Time progressed and as HLA caught on more and more people used the VRL Gateway with actual HLA Federates.

One of the most surprising things we discovered about the VRL Gateway was that some customers were using it as a network monitoring tool. The GUI provided a useful way to see what was on your DIS or HLA network. It was a capability that many customers didn’t have apparently. I always found this usage quite surprising.

Over the years the VRL Gateway was continually updated to support more complex simulation environments. We added many ‘features’ to correct for broken federates, and on the way we learned that almost every exercise interpreted the DIS and RPR FOM specifications slightly differently. In each case we extended the VRL Gateway to support both interpretations. In the end the VRL Gateway had a tremendous number of configuration options. Yet, while the VRL Gateway presented data in a useful GUI interface, the configuration was always done using LISP (MTL).

Sometime in 2005 we realized there was a growing market need to bridge different RTI’s and to connect new protocols together (think Link-16 and DIS, or TENA and DIS). This bridging involved translation too. We knew what we were doing would ultimately cut into the VRL Gateway’s role as MAK’s DIS to HLA Bridge. We also knew the VRL Gateway’s lack of a toolkit was a major hindrance to some of our customers. We decided to take some of the key components that worked in the VRL Gateway add a bit of new architecture, and produce a translation/bridge tool which contained a framework for bridging new protocols as they were developed. From this VR-Exchange was born.

VR-Exchange contained an architecture where individual protocol translators could be plugged into a shared memory core to communicate. If you wanted to add a new protocol all you had to do was write a new plug-in. Originally the working name for this product was ‘MIP’ (the MAK Interoperability Portal) which consisted of the Portal (the core) and Adapters(the plug-ins). Eventually we settled on a working name of VR-Exchange with a Broker being the plug-ins. Get it? Brokers exchange information at an Exchange; we like the stock market over here.

The original VR-Exchange looked like this:

There were no built-in “Adapters,” you had to modify everything in a configuration file. In general the look was very similar to the VRL Gateway.

Today VR-Exchange has advanced a long way. It’s just as flexible as the old Gateway. However, much of that flexibility is available through a few clicks of the GUI, including adding new Brokers. The GUI now displays even more information about the data which is going through it, helping users better understand their simulation environment.

We now have more customers writing their own Brokers using the VR-Exchange API. Overall, it appears that VR-Exchange has grown up quite a bit and entered into its new role as MAK’s Gateway solution quite nicely. Who knows what MAK’s Gateway Solution will be in 10 years from now? I am sure our current solution will continue to grow and evolve to meet our industries ever changing needs. I can’t wait!

~ Jim Kogler. Product Manager for Link products (and MAK Gateway Architiect)

Yesterday in the VDC Display Systems booth, which has a completely enclosed room, we tried out VR-Vantage generating four channels of video to make one seamless display. VDC supplied the display and the MARQUEE projectors and Scalable Display Technologies provided the EasyBlend image warping and edge blending technology.

In theory we knew it would work, but there’s nothing like putting it to the test.

The picture was taken from my iPhone through the optics of the NVG, Otherwise it was completely dark in the room.

Four VR-Vantage channels projected onto a VDC Display System

A view through the Night Vision Goggle (taken with my iPhone)

Presenting at the Innovation Showcase

You can read the release here: http://mak.com/pr/pr_entity_boost.html

MÄK Booth #1819

Booth #1819

I/ITSEC Set Up - 8:30 am Friday Morning

I/ITSEC Set Up - 2 pm Friday Afternoon - It's Coming Together

Checking us out at the show? Be sure to stop by Booth #1819 to enter the drawing for the Garmin GPS and to see the latest from MÄK.

Are you registered?

Access to blog content is limited to registered users. But if you register before December 1, you’ll be entered into a drawing for a Garmin nuvi GPS. So sign up now!