An Overview of the HLA Evolved Modular FOMs

ABSTRACT: The HLA Federation Object Model (FOM) describes the information that is to be exchanged during the execution of a federation. When the federation execution is created, the RTI loads the FOM. This enables the participating federates to refer to the object model, for example when publishing and subscribing to information.

As in many other cases, a monolithic architecture restricts the speed, flexibility, and accuracy of the development process which in turn affects the resulting FOM. As part of HLA Evolved the concept of FOM modules have been added. The FOM is thus broken down into composable modules that can build upon each other. This allows a subset of federates to specify what data they need to exchange upon joining, in addition to the initially loaded FOM.

The main advantage is the increased flexibility during runtime and, not the least, during the development process. Federation developers can build new modules that extend reference FOMs without modifying them. Reference FOMs can be developed by several smaller communities in different domains or for different local or national extensions. Temporary additions will not result in a multitude of similar FOMs.

It will also now be possible to have long-running or persistent federations in virtual arenas where new capabilities and types of shared information can be added over time.

The modular FOMs are expected to revitalize a long needed development of shared information models. This is an important and necessary next step towards even higher degrees of interoperability that build on top of the High Level Architecture.

Authors: Björn Möller, Björn Löfstrand, Mikael Karlsson
Publication: Proceedings of 2007 Spring Simulation Interoperability Workshop, 07S-SIW-108, Simulation Interoperability Standards Organization, March 2007. 

Download the full paper (pdf)


Developing Web Centric Federates and Federations using the HLA Evolved Web Services API

ABSTRACT: The new Web Services API of HLA Evolved offers several new opportunities for federation developers, both from an architectural and a programming perspective. This paper provides an introduction and a number of recommended practices for federation designers and federate programmers, including some references to FEDEP.

The first and maybe most important step is to take a web-centric approach to the overall federation design. This includes deciding upon how the federation is to be provided as a service. How will executions and potential
participants be managed and how will authentication take place. When are federates allowed to join? Performance characteristics and fault tolerance need to be taken into considerations. It also includes determining reasonable update and interactions rates based on the expected available bandwidth. This in turn may introduce the need for deadreckoning
and similar methods.

The next step is to set up a productive development and debugging environment. A wide array of code generation and WSDL analysis tools are available. An RTI with a Web Service Provider component that follows the HLA WSDL standard is of course also needed.

When developing web services federates, some features may require special attention, including:

  • Connection and authentication
  • Session handling, time-outs and fault tolerance
  • Bandwidth management and tuning
  • Use of handles
  • Data encoding and time representation
  • Callback delivery
  • Support services
  • Long-haul deployment

    Finally the pros and cons of Web Services based federates versus C++ and Java API federates are discussed.

Authors: Björn Möller, Clarence Dahlin, Mikael Karlsson
Publication: Proceedings of 2007 Spring Simulation Interoperability Workshop, 07S-SIW-107, Simulation Interoperability Standards Organization, March 2007.

Download the full paper (pdf)