After more than 15 years and 21 different drafts, RPR FOM 2 is finally a SISO standard! It’s been a long road with periods of intense activity and years with little progress, but it is here. The RPR FOM is an incredibly important standard in our industry. It embodies the most widely used object model in our community. It was originally designed to allow the concepts of DIS to be used in HLA federations. Now with RPR FOM 2, there is a single official standard that is supported by all the flavors of HLA and is consistent with DIS version 6. Having this standard provides a clear way for our customers to maximize their simulation investments — with minimal incremental cost, simulations built for a single purpose can be connected to other simulators to form larger and more valuable federations.
Last fall, MÄK introduced our FOM Editor, a web-based application for creating and extending HLA FOMs. The original goal of the tool was to make it easier for people to quickly develop their own HLA Evolved FOM modules to extend widely used existing FOMs, such as the RPR FOM. Once we had a tool that supported HLA Evolved FOMs, however, it was simple to add support for HLA 1516-2000 as well. Both 1516-2000 and 1516-2010 (as HLA Evolved is more officially known) use XML formats and contain a lot of the same information. The formats are a bit different and 1516-2010 added some new things, but there is a lot of overlap.
Until recently we have not had any support for HLA 1.3, but we just upgraded the FOM Editor to import 1.3 OMT and FED files for conversion to HLA 1516 formats. To try it you will need a valid 1.3 OMT file at a minimum, but a FED file is also recommended for a full import. Just drag your OMT file onto the Project page, and once that’s complete, follow it up with your FED file.
Things are a bit different in 1.3 than in 1516. The most obvious difference is that rather than using a single type of file, a 1.3 FOM is defined by a combination of an OMT file and a FED file (neither of which is in XML). That’s a fairly minor difference from the point of view of the FOM Editor, but there are more important differences that don’t become apparent until you delve into the content of the files. Datatypes just aren’t the same in 1.3 as in 1516, and the FOM Editor has to make some assumptions and choices when converting a 1.3 file to a 1516 file. Below is a list of some of the most notable differences between 1.3 and 1516 FOMs, as well as a brief description of how the FOM Editor handles each case.
SISO’s annual Simulation Interoperability Workshop (SIW) will soon be here and as always, a number of us MÄKers will be in attendance. There is a lot going on this year but one of the most notable " at least in my (admittedly biased) opinion " is the meeting of the RPR FOM PDG. Earlier this year RPR FOM 2.0 was successfully balloted, though with a number of comments. A small group of us has been working to resolve those comments and at SIW we’ll be holding a full PDG meeting to vote on final decisions (feel free to join us). That means we may soon have an official RPR FOM 2.0 standard!
Some of you are probably thinking, "What’s the big deal? I’ve been using RPR 2 for years." It’s true, many of us have been. Despite never being officially standardized, draft 17 of the FOM has become a de facto standard, used throughout the world in many important federations. But draft 17 had a number of issues which the RPR drafting group has been trying to address over the last couple of years. Perhaps the most glaring problem was the lack of support for HLA 1516-2000 or 1516-2010 (HLA Evolved). While a number of versions have been produced by different groups over the years, there was no one official version. On top of that we have fixed bugs, inconsistencies, poor datatype naming, and confusing descriptions and documentation. We now even have a modularized version for HLA Evolved. I am happy to say that I believe this is the best version of the RPR FOM yet. I encourage you all to check out draft 20 of both the FOM and the accompanying GRIM (Guidance, Rationale, and Interoperability Modalities) document.
If you are going to be at SIW and would like a higher level overview of RPR FOM history, what we’ve been up to lately, and where we think the FOM is headed in the future, I also encourage you to attend the presentation of a paper I co-authored with BjÃ¶rn MÃ¶ller of Pitch Technologies, Patrice Le Leydour of Thales, and RenÃ© Verhage of CAE titled "RPR FOM 2.0: A Federation Object Model for Defense Simulations."
For a number of years, the MÄK RTI has supported a useful feature called FDD (or FED if we’re talking about HLA 1.3) file distribution. The original idea was that often during federation development you might find the need to update your FDD file. This often meant going around to every machine you were using and updating the local copy of the file. Obviously, this is both tedious and error prone. With FDD file distribution, only the federate that created the federation execution needed to have a local copy. When the federation was created, the file was distributed through the RTI to the rtiexec, which then distributed it to every other joining federate. This guaranteed that everyone was using the most up to date file and there were no discrepancies. There was one obvious downside to this feature however: start-up times were slower.
Earlier this week MÄK released the latest version of the RTI, 4.1. One of the big features of this release was support for IPv6. For those that don’t know much about IPv6, it is the latest version of the Internet Protocol and replaces IPv4. The primary motivating factor behind the creation of IPv6 was the size of the IP address space in IPv4. IPv4 addresses are only 32 bits long. That’s enough for 4,294,967,296 different addresses, but it’s not enough for the size of the internet today.
This is the 6th and final part in my series of blog posts on RTI RID configuration tips. Each of these tips, unless otherwise noted, works in HLA 1.3, HLA 1516-2000, or HLA Evolved. If you’re interested in learning how to make better use of your RID file, check out the previous posts in this series as well.
Part 1: RID Consistency Checking
This is part 5 in my series of blog posts on RTI RID configuration tips. Check out the previous posts in this series, and stay tuned for more to come.
Part 1: RID Consistency Checking
Part 2: The Advantages of MTL
As mentioned by my fellow I/ITSEC bloggers, there’s quite a bit of buzz around the MAK booth! People seem to be instinctively drawn to all of our visualization products, streaming terrain features, and snazzy customer solutions, not only because of MAK’s hard earned reputation in simulation and visualization products, but also because of the eye catching displays and demos.
But (probably because of my role as technical product manager of link products) I just wanted to remind everyone attending I/ITSEC and those who aren’t able to attend that MAK is still going strong with our Link products! If anyone at the show is interested in learning more about MAK’s core products, Including the MAK RTI, VR-Link, VR-Exchange, and the Data Logger, come by our booth and talk to me! I’ve already spoken with a number of Link product users and gotten some great feedback: now it’s your turn! I want to hear what you’re currently using our products for and what we can do in the future to meet your Linking needs.
This is part 4 in my series of blog posts on RTI RID configuration tips. Each of these tips, unless otherwise noted, works in HLA 1.3, HLA 1516-2000, or HLA Evolved. Check out the previous posts in this series, and stay tuned for more to come.
Part 1: RID Consistency Checking
This is part 3 in my series of blog posts on RTI RID configuration tips. Each of these tips, unless otherwise noted, works in HLA 1.3, HLA 1516-2000, or HLA Evolved. Check out the previous posts in this series, and stay tuned for more to come.
This is part 2 in my series of blog posts on RTI RID configuration tips. Each of these tips, unless otherwise noted, works in HLA 1.3, HLA 1516-2000, or HLA Evolved. Take a look at part 1 HERE, and stay tuned for future posts in this series.
The RID file is written in MTL. MTL stands for MÄK Technologies Lisp. MTL is basically a limited form of the Lisp programming language. The primary purpose of the RID MTL file is to set specific variables which are parsed by the RTI’s MTL parser and loaded into configuration settings. The same goal could be achieved using other formats such as XML (another popular MÄK configuration file format), but there are advantages to MTL.
The first important thing to understand is the difference between the setq and setqb commands. The "b’ in the setqb command stands for "bound". This command is used to set the bound variables that are recognized by the RTI. So the only variables set using setqb should be those that are documented RID parameters that are accepted by the RTI. The setq command, however, can be used to set any temporary variables you want that can be used in RID processing. Why would you want to do this? Well, used in conjunction with other features of MTL, this can make your life just a little bit easier. Here’s an example:
Last week a couple of other MÄKers and I once again made the trip down to Orlando to attend the biannual Simulation Interoperability Workshop (SIW). I’m sure many of you are familiar with the workshop, but for those of you who don’t know it, SIW is where people in the simulation industry from around the world meet to discuss the work they’ve been doing in simulation interoperability and develop the standards that the industry uses. This is where standards such as HLA and DIS are developed.
The workshop consisted of the usual presentations and development group meetings. To me, one of the most interesting was the RPR FOM revival meeting. There is a new push right now to restart the RPR FOM Product Development Group (PDG) and finalize the RPR FOM 2 standard. There are currently several draft versions of the standard, but nothing official. As a result, different simulations will end up using slightly different versions of RPR 2. At MÄK, we’ve added support in our products for a few of the more popular RPR 2 drafts, but we are definitely interested in seeing the standard finalized. We’re excited to be part of the RPR FOM 2 standardization effort, and we hope that RPR will continue beyond that as well. After all, the new version of DIS is nearing completion, so the RPR FOM will need to keep up.
Occasionally we receive a support request asking for the latency of a message in the RTI. Answering these questions is difficult as there are many factors which can affect RTI latency. Not least of these is the network itself and the tick rate of the federate. These are probably the two largest factors in determining latency.