ABSTRACT: One of the most important new features of HLA Evolved is FOM Modules. The FOM is used to describe the information that is exchanged in a federation. By making the FOM modular it is possible to focus on certain aspects of the data exchange. This makes it possible to identify, develop and isolate more general or more specific aspects of the data exchange. Examples of more general and thus more reusable modules are commonly used data types or federation management interactions. Less reusable FOM modules are for example project-specific platform extensions to the RPR-FOM.
The first part of the paper covers processes for the development and maintenance of reusable FOM modules.
These can be developed and reused in a “top-down” manner within domains (i.e. defense, space, industry, etc), groups of organizations (e.g. SISO, NATO), organizations (i.e. companies, defense components) and individual projects. Important success factors here are a well-defined lifecycle process, proper management support and a use case and test driven development approach.
It is also possible to develop reusable FOM modules from a more technical “bottom-up” perspective. Useful components like FOM elements are sometimes reused within and across federations, often even beyond the
planned life span. The main reusability criteria here is “the survival of the fittest”.
The second part of the paper describes how a specialized tool can be used to develop and maintain a project consisting of several FOM modules for use in a particular federation.
These modules need to be inspected, understood and verified both against the HLA Evolved standard and against each other. Since FOM modules can build upon each other it is important that a tool can help the user
maintain compatibility and avoid undesirable dependencies between modules.
When managing FOM modules it is important to understand what role each FOM module plays from a reuse perspective. Is it a highly standardized module or a temporary project development? This affects which modules that should be adjusted when consistency and compatibility issues are discovered. It affects several aspects
of refactoring across modules. Last but not least it affects how a tool can provide “best practices” assistance to a new user. A comparison is also made between maintaining FOM modules using general-purpose XML
tools versus a specialized FOM module tool.
Finally some thoughts on the above processes and tools are given, based on the on-going work with the NATO Snow Leopard federation and other practical applications.
Authors: Björn Möller, Fredrik Antelius, Martin Johansson, Björn Löfstrand, Åsa Wihlborg
Publication: Proceedings of 2011 Spring Simulation Interoperability Workshop, 11S-SIW-069, Simulation Interoperability Standards Organization, April 2011.