The Long Journey of the MAK Gateway Family

VR-Exchange 1.6 is just finishing up Quality Control testing and should be released any day, if it isn’t already by the time you read this. VR-Exchange version 1.6 is a bit of a milestone for MAK: it is the first release of VR-Exchange which contains all the functionality of the MAK FOM Agile Gateway.

The FOM Agile Gateway (Let’s call it the VRL Gateway for a reason I will make clear shortly) is the second generation MAK Gateway product and will be replaced by VR-Exchange as the third generation of the MAK Gateway. The MAK Gateway product line holds a special place in my heart as I architected and wrote both the 2^nd and 3^rd generation of it (VRL and VRX respectively). As I was thinking about this release, I decided to do some software archeology and I figured I would share. For those Gateway customers out there who have been with us for a long time -- there are quite a few of you -- this blog will hopefully be a fun trip down memory lane.

 

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

h t

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)