HLA Evolves Again
By Jim Kogler, VP of Products (originally posted on LinkedIn)
The HLA standard has advanced once more—perhaps without much fanfare, but in a significant way. The latest version, IEEE HLA 1516-2025, is being referred to as HLA 4, to distinguish it from IEEE 1516-2010, which was nicknamed HLA Evolved. The "4" signifies that this is essentially the fourth major revision of the standard. It has been a large, collaborative effort involving coordination across the industry. MAK’s own Doug Wood, a Principal Engineer on our Link team, was deeply involved in this latest revision—as he has been with previous ones—but the work was carried out by a team of outstanding individuals from many organizations, including competitors, coming together to improve interoperability.
You can find many write-ups online detailing all the changes in the standard—there’s a lot of good material out there. But instead of covering everything, I want to focus on one relatively minor change to HLA 4 that is part of a larger trend making HLA more distinct and cost-effective as an interoperability solution. This essay is also a response to a recurring issue in HLA’s history—people trying to reinvent the wheel without understanding the problems HLA has already solved.
Specifically, I want to talk about FOM Attribute Merging. While there are many reasons to move from HLA Evolved to HLA 4, I argue that this feature is one of the most important.
What is a FOM, and Why Is It Key to Interoperability?
FOM stands for Federate Object Model. Its format is defined in the HLA standard and has evolved over the years. At its core, the FOM is a way to separate the object model—the description of the things you are simulating—from the interoperability infrastructure at runtime. For those familiar with HLA, this is basic stuff. This separation was a key reason HLA was created in the 1990s. The prevailing standard at the time, DIS (IEEE-1278), had a rigid object model embedded in the protocol. If you wanted to modify it for whatever reason, you had to break from the standard.
This runtime separation between the object model and the interoperability infrastructure was powerful but also problematic. While it enabled better interoperability, it was also easy to misuse. Since HLA doesn’t define a standard object model, everyone could create their own—sometimes for political reasons or due to siloed development. When incompatibilities emerged, people blamed HLA: “HLA is hard to use!” or “We moved to HLA for interoperability and now nothing works together!” But the real issue was a lack of engineering discipline and understanding.
Fortunately, many people in the modeling and simulation community worked together over the years to define common object models. The most notable is the RPR FOM (Real-Time Platform Reference FOM), standardized by SISO to mirror the DIS object model in HLA. While some ignored this effort—often at their peril—the RPR FOM has become a solid base for typical entity-level military simulations. It’s a reference FOM, designed to be extended, yet still providing core commonality. NATO MSG efforts like the NETN FOM, now openly available on GitHub, have furthered this concept.
FOMs as a Runtime Format
A key feature of HLA is that the FOM is a runtime-parsable file, meaning it doesn't need to be compiled into the application. Other protocols like CORBA and its predecessor DDS use compile-time object models defined in IDL files. Recent efforts like MSSV follow similar paths for extension but often lack openness or true interoperability.
With HLA, reading the FOM at runtime allows simulators (HLA calls them federates) to remain flexible in the face of object model changes. At MAK, we’ve developed a FOM Mapper capability, which lets applications adapt to changes in the object model after deployment with a simple C++ plugin, with minimal modifications to the actual application—saving potentially millions in contract changes. Other vendors could have similar tools. This runtime flexibility is one of HLA’s greatest strengths—if you understand it and build your federate correctly.
That said, the runtime model has a learning curve. Some in the community prefer using tools like Protocol Buffers (protobuf) to define packets and avoid complexity. These approaches try to encode the object model into the interoperability layer interface to "make it easier." But compile-time models require code generation before building the application. HLA, with a little effort, offers the benefits of both worlds: runtime flexibility and high-level abstraction. Understanding this flexibility seems unimportant to many building simulators for contracts at the lowest cost, but for those who worry about long term viability of simulators and applications this should be intuitive and critical.
The Introduction of FOM Modules
HLA was founded on the concept of a runtime-parsable, external FOM separate from the network infrastructure. The RPR FOM gave everyone a common base, reducing object model wheel reinvention. But early HLA versions lacked a sustainable (some may say clean) way to extend the FOM for some federates but not others.
For example, suppose you simulate tanks and aircraft. You later want to enhance your air simulation with new sensor and communication capabilities. This means extending the FOM—but do you have to rebuild all federates?
HLA always allowed FOM extensions, but it required careful management and was messy. Things got worse (to the extent of not being possible) when multiple groups added unrelated extensions (e.g., one adds weather, another adds TDL/EW). The single-FOM-file structure became a bottleneck.
To solve this problem HLA Evolved (IEEE-1516.2010) introduced FOM Modules. This was a way to take the external to HLA runtime-parsable object model and break it into sections. Then HLA and any federate could decide what they wanted to use from a list of modules. Does your simulator need an EW capability? If not, you don’t need to worry about it. Does your simulator need the new logistics model? If not, don’t worry about it. This capability allowed multiple parties to integrate new functionality, often significant, into existing systems without having to rebuild federates.
This extension wasn’t revolutionary. Protocols like DIS were often extended with new network messages. Compile time solutions, depending on the solution, would allow new executables to extend if the base object model remained unchanged, though managing this efficiently could be problematic.
The HLA Evolved solution was elegant and clean, but not without issues.
HLA 4 Brings Us Attribute Merging
The problem with FOM Modules in HLA Evolved was their reliance on object-oriented inheritance. If the RPR FOM Tank object has 45 attributes, and you want to add temperature for EO/IR simulation, you must subclass it (e.g., Tank-Thermal). This is fine—until another group needs to add some new attribute for Blue Force Tracking data. Now you have competing subclass branches: Tank-Thermal and Tank-BFT. Applications that don’t care about either still must deal with the changes—meaning higher costs.
HLA 4 solves this with Attribute Merging. Now, you can add attributes directly to existing FOM objects without subclassing. The EO/IR team can add temperature to the Tank object. The BFT team can add their attributes too. Legacy systems remain unaffected—they just ignore the new attributes.
This makes extension easier, reduces the need for coordination, and keeps costs down. It’s a huge win for both interoperability and maintainability.
Why HLA 4 Shines
While FOM Modules solved a problem with HLA that other interoperability protocols could manage, HLA 4 added a capability that is uniquely possible due to the runtime parsing of the FOM.
When you design your object model around network messages and packets, there are really only two ways to extend the data in the object:
- You can append the data to the end of the packet so that existing tools just ignore it.
- Or you can define a new packet type.
The first option—extending the packet—doesn't really work well. DIS tries to do this with attribute extensions, and while it’s technically possible, you’re guaranteed a collision if multiple parties make different extensions without coordination. Group A adds “heat” at the end of the Tank packet, while group B adds “Radio Channel”—result: collision and failure.
DIS attempts to manage this with enumerations—each extension gets a unique ID—but if that’s not carefully managed, you still end up with collisions, often leading to crashes and buffer overruns.
Creating new packet types works, but once you’ve added enough attributes this way, you’re left with a mess of packet types on the network. And as we all remember from Networking 101, lots of small packets fragment the network and reduce throughput.
When you compile your interface into your interoperability system, there is no alternative but to recompile everything when your object model changes.
HLA 4 solves all of this in a very elegant way by injecting the data in runtime into the object. The object model looks coherent and is organized and the RTI has the ability to bundle the attributes intelligently if required. Bundling attributes intelligently has been a hallmark of HLA since the beginning. Attribute merging works in HLA 4 because the object model has been runtime-parseable since the beginning. Without that, it's extremely difficult to inject new attribute data into an object model without rebuilding—or at the very least touching—everything, sometimes at significant cost.
In fact, the way most protocols outside of HLA end up solving this problem is by gradually changing their protocol to look more and more like HLA. In my 25 years in this industry, I’ve seen it happen again and again—someone will likely be doing that soon.
But in our world of growing exercises and constrained budgets, we should take a moment to recognize something: HLA got it right. The team that created the HLA standard, and has continued to evolve it over the years, did an outstanding job. They've built a foundation that remains relevant and impactful in the modeling and simulation community to this day.
This article was originally posted on LinkedIn by MAK's VP of Products, Jim Kogler. If you have questions about HLA 4, reach out to us anytime at
