No cookie for

How MÄK’s FOM Editor Handles Differences between HLA 1.3 and 1516 FOMs

Posted by on MÄK Products

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.

We hope this new capability proves useful. Give it a try and let us know what you think!

An HLA 1.3 OMT file does not define simple or array datatypes.

The only datatypes explicitly defined in a 1.3 FOM are complex datatypes (aka fixed records or structs) and enumerations. 1.3 also has basic data representations (e.g. double, unsigned long, or char), but they are defined in the Object Model Template Specification and not in the FOM, which is again different from 1516. Important fields that help understand a datatype in a 1516 FOM such as units, resolution, and cardinality are instead defined for individual attributes and parameters. As a result, the FOM Editor must create a new simple datatype for each attribute and parameter. To prevent a long list of duplicate datatypes, the FOM Editor tries to reuse datatypes if it determines that two attributes could be defined with the same type.

There is no one-to-one mapping between all basic data representations in 1.3 and the standard datatypes in 1516.

HLA 1.3 has a number of basic data representations. Many map directly to HLA 1516 standard basic representations, and the FOM Editor easily handles these conversions. However there are a few data representations in 1.3 that have no equivalent standard datatype in HLA 1516. For example, 1.3 includes unsigned integers and 1516 does not. To handle this case, the FOM Editor turns to another common standard: the RPR FOM. RPR FOM 2.0 does define unsigned integer datatypes, and the FOM Editor takes advantage of this. Another issue is that 1516 defines both big endian and little endian datatypes, which 1.3 does not specify. In this case the FOM Editor has an option which allows you to choose which endian encoding to use.

There are multiple ways to encode an array, and 1.3 FOMs do not specify which to use.

The standard 1516 encoding for arrays is HLAvariableArray, a 32 bit integer indicating the size followed by an array containing that many items. But 1516 allows other encoding types to be defined. Some FOMs, including the RPR FOM, do have alternate encodings. RPR uses a lengthless array encoding. No size field is encoded, and the number of items in the array can be inferred by the number of bytes in the array and the number of bytes in each element. 1.3 FOMs have no encoding specification, so the FOM Editor must choose an encoding itself. We have made this an option and you can choose to use either of these two standard encoding types.

The 1.3 and 1516 standards disagree on how strings should be encoded.

The 1.3 Object Model Template Specification says that a string is an array of "chars" terminated with a null value (0). The 1516 standard string encoding is HLAASCIIstring, which uses the HLAvariableArray encoding described above. As a result, we have made this an option as well.

Enumerations are not defined with a data representation in 1.3.

In 1516 all enumerated datatypes specify a data representation such as HLAinteger32BE or HLAoctet. This is not present in 1.3, so the FOM Editor needs to determine what data representation to use. In an effort to encode data in the smallest reasonable size, the FOM Editor looks at the number of possible values in the enumerated datatype and uses the smallest possible standard integer representation.

Last modified on
Trackback URL for this blog entry.

Comments

  • No comments made yet. Be the first to submit a comment

Leave your comment

Guest
Guest 12 November 2019