For those involved in distributed simulation, the High Level Architecture, or HLA, is a crucial component for enabling data exchange and interoperability. But what exactly is HLA and how does it work? In this article, we delve into the details of HLA, exploring the key concepts and processes that make it such a powerful standard. Whether you’re a policymaker, a developer, or just someone interested in cutting-edge technology, we hope you’ll find something of value in this comprehensive guide to HLA.
What is HLA?
HLA is an Open Standard, a standard that is openly and easily accessible and usable by anyone, maintained by the Simulation Interoperability Standards Organization (SISO) and published by the Institute of Electrical and Electronics Engineers (IEEE). The core purpose of HLA is to make it easy to connect multiple simulators together. The use case range from simple, small-scale operations such as connecting two flight simulators running in a single facility, to vast and extensive operations connecting hundreds of simulators and thousands of users spread across the world.
HLA is widely adopted and used all over the world in defense, space, medical and logistical applications. It’s also the framework of choice for organizations such as NATO where all participating nations have agreed that both procurement and new development of simulation systems should be compliant with the latest version of HLA. Some of the most notable recent projects built with HLA are NASA Artemis – a moon exploration program, RAF Gladiator – a joint aviation training program, and Viking 22 – a distributed computer-aided peace-keeping exercise.
How does HLA work?
At first glance the HLA information architecture can seem complex, but the way information is managed and exchanged is actually similar to many real-world applications. Let’s take a shipping harbor as an example:
The Harbor Analogy
A shipping harbor is a standardized way to manage ships and letting them exchange goods effectively. At the center of the operation is the harbor office, which manages docking, transfer of goods, and other vital tasks such as maintaining safety and security in the harbor.
When a boat wants to access the harbor, it contacts the harbor office, which guides the boat to the appropriate dock and provides information about the rules of the harbor. These rules cover aspects such as how to dock the boat, how to connect to the harbor infrastructure and how to safely unload and load goods in the harbor.
Once the boat arrives at the dock, it declares its intentions to the harbor office, stating what goods it wishes to unload and what goods it wants to acquire from other boats in the harbor. The harbor office acts as a middleman to facilitate a seamless flow of goods between boats.
In principle, HLA works the same way as a shipping harbor, but with a different terminology. HLA is based on the concept of Federates and Federations. A federate is an individual simulator (a boat). A federation is a connected group of simulators (a harbor), that can communicate with each other (exchange goods).
At the core of HLA sits the Run-Time-Infrastructure, the RTI (a harbor office), which manages the flow of data (goods) between federates in the simulation. When a federate wants to join a federation, it must agree to comply with a Federation Object Model, the FOM (the rulebook). The FOM defines the types of objects that can be used in the simulation and the interactions between them which ensures that all federates will understand each other.
For the exchange of information between different federates in the simulation, HLA uses a messaging pattern called publish and subscribe. When a federate connects to the federation, it tells the RTI what data it intends to publish (send) to the federation and what kinds of data it’s interested in subscribing to (receiving).
As soon as the federate has connected and declared its intentions, the RTI assumes the role of a middleman, delivering the published data to all federates that have subscribed to it. During runtime, each federate will continuously send and receive data via the RTI. This way, the federates that have subscribed to the data will receive updates automatically when new information becomes available, without having to manually request it.
In summary, the architecture of HLA allows simulation systems to connect, communicate and exchange information seamlessly – ultimately creating a more cohesive and more realistic simulation environment where hundreds of simulators can be connected.
What are the benefits of HLA?
Using HLA for a simulation system brings several important benefits:
Make all your systems work together
The first and most obvious benefit of using HLA is the ability to connect and make systems work together. By connecting simulators into larger contexts, the modeling and simulation can be made more realistic which will increase the ability to reach your organizations training goals.
Modular Simulation Systems
In HLA different components and simulators are functionally isolated with the RTI acting as a middleman managing the communication between them. This is a great way to make it possible to the switch out individual components or simulators without having to rebuild the whole system. This modular approach can also pave the way for more agile development processes where you can continuously adopt new innovations and technology to your system.
Avoid vendor lock in
As long as a new federate supplies the same functionality, the federation as a whole will not be affected by the change of a single federate. This means HLA is a great way to avoid vendor lock-in as the barrier to switch between different components and simulators is lowered. This also increases the incentive for suppliers to continuously provide and support competitive products and solutions.
Reuse simulation components
With the same logic as above, instead of always building a system from scratch, users can reuse components already developed, tested, and paid for in multiple simulation systems. This will often lead to both cost and time savings.
Gain access to an established ecosystem
Thanks to HLA being a long-running and established open standard in multiple industries, over the years a healthy ecosystem has formed with plenty of suppliers providing components needed in a modern simulator as commercial-off-the-shelf (COTS) products. These components cover a wide range of functions such as data transfer, recording, generation of forces, audio and video transfer, as well as debriefing solutions.
By utilizing pre-existing components, development teams can focus on improving their projects core capabilities rather than reinventing basic functionality. Depending on the specific priorities of the project, this can lead to lower costs, quicker time to market or increased capabilities of the finished product.
Scalable Information Architecture
In larger exercises, HLA offers a significant decrease of network load compared to frameworks such as DIS. This is due to HLA using a publish and subscribe messaging pattern instead of a broadcasting framework. So, instead of all federates broadcasting all data to everyone, HLA only sends the data that a federate has subscribed to. This makes HLA a more scalable option when building large scenarios over multiple training sites.
These are just some of the general benefits of implementing HLA in distributed simulations, and these can extend to more specific and nuanced benefits, depending on the use case.
Which are the most common object models in HLA?
HLA is not just about standardizing how data is managed and exchanged, to make it easy to connect simulators together there is also a standardization effort for the object models, FOMs, used in various domains. This standardization ensures that all participants in an HLA-based simulation speak the same language and have a shared understanding of the objects being simulated. Some of the most common object models in HLA include:
- RPR-FOM (Real-time Platform Reference Federation Object Model): A widely-used object model for military simulations that covers air, ground, and sea operations.
- NETN-FOM (Networked Training and Simulation Federation Object Model): An object model for training and simulation in the military and civilian sectors that covers a wide range of equipment and personnel.
- SpaceFOM: An object model for space and orbital simulations that includes spacecraft, satellites, and ground-based assets.
Other object models exist for specific applications and domains, and new object models are continually being developed as the need arises. Standardization of object models helps to ensure interoperability between different simulations and facilitates the reuse of simulation components. When the need arises, it’s however easy to extend and adapt object models to suit the need of your specific use case.
What challenges exist when implementing HLA?
While the use of HLA presents multiple benefits in simulations, users can sometimes face challenges in using HLA. One of the main challenges of using HLA is its perceived complexity—which can initially make if feel hard for users to set up and manage HLA simulations. This can often be remedied by partnering with a capable provider or taking up training courses specifically for HLA. Pitch’s free HLA tutorial is also a popular way to get you started!
Another possible challenge is the dependence of the performance of the whole simulation on the federates. This could potentially mean that a federate not performing up to par may possibly hinder the whole simulation. However, a proper architecture of your HLA simulations will make sure your system function as smoothly as possible.
In general, the benefits of implementing HLA far outweigh these perceived challenges, especially when executed properly.
The Future of HLA
Generally, the future of HLA builds upon what is already available and established. As technology advances, we can expect improved interoperability, as well as the use of modern technologies such as machine learning, artificial intelligence, and virtual reality. The use of cloud computing may also enable simulations to become even more scalable, while also being easier to manage and deploy. We can also expect to see HLA being used and implement more in different industries, such as healthcare.
HLA 4, the next version of High-Level Architecture for modeling and simulation, will provide a plethora of new features, such as more powerful modeling. With HLA 4, unreliable links such as 3G, 4G, and 5G will also see support. An increase in vendor independence will also be observed with this update with the introduction of the federate protocol, providing another standardized way to manage the communication between the RTI and the federates.
In summary, HLA is an Open Standard that enables interoperability among simulation systems. It is widely used in defense and space applications and has been utilized in notable projects such as NASA Artemis and RAF Gladiator. While the implementation of HLA may come with challenges, these can be remedied, and the benefits far outweigh the perceived hurdles.
Implementing HLA in your next simulator
Partnering with a capable and trusted provider will make your implementation of HLA as seamless as possible. For over 30 years, Pitch has supported the construction of thousands of distributed simulation systems within various industries and domains. All our solutions are built on the open HLA standard which guarantees an interoperable, secure, and scalable environment for all your simulation needs.
When you’re building your next simulator, you want to spend your resources fulfilling your goals, not reinventing the wheel. By using Pitch as a backbone for your system, you free time, money, and resources to invest in enhancing your training solutions.
Interested in working with us on your next simulator build? Contact us for a free consultation!
Read more about the HLA standard:
- IEEE Std 1516-2010 Framework and Rules – this specifies the architectural rules that the components, or the whole federation, shall follow.
- IEEE Std 1516.1-2010 Federate Interface Specification – this specifies the services provided by the RTI.
- IEEE Std 1516.2-2010 Object Model Template Specification – this specifies which format the HLA object models must use.