High-Level Model (HLM) Overview
- High-Level Models (HLMs) are modular abstractions that decompose Federation Object Models into composable simulation components, improving system agility.
- They employ modular FOMs in HLA Evolved to enable dynamic federation configuration through clear module definitions and systematic merging processes.
- The merging process ensures non-redundant and valid compositions by detecting duplicates and resolving equivalences, fostering seamless simulation integration.
A high-level model (HLM) is an architectural and methodological abstraction employed to capture, organize, and compose the main information exchange, behavioral, or statistical components in complex systems—especially in simulation and modeling frameworks. The term arises across multiple domains but is most precisely formalized in the context of the High Level Architecture (HLA) Evolved standard for simulation interoperability, where the HLM concept is embodied by the modular Federation Object Model (modular FOM) (0909.1364). HLMs function as a composable, extensible representation of a simulation’s conceptual and runtime elements, designed to improve agility, reusability, and composability while addressing the rigidity inherent in traditional monolithic models.
1. Modularization Principles and Model Structure
High-level models in the HLA Evolved sense decompose a Federation Object Model (FOM) into coherent modules, each encapsulating some or all of the tables prescribed by the Object Model Template (OMT). An FOM or Simulation Object Model (SOM) module contains a subset of the overall model; it may define full or “scaffolding” versions of object/interaction superclasses needed to anchor contained subordinate elements. Scaffolding definitions contain only identifiers (e.g., class names, publish/subscribe markers), serving as lightweight proxies and ensuring proper linkage with canonical definitions elsewhere.
A special module, the Management Object Model and Initialization Module (MIM), comprises mandatory HLA management elements: object roots, datatype definitions, transportation/dimensions, and initialization constructs. At federation startup or when federates join, the “Current FOM” is realized as the union of all supplied FOM modules and one MIM, representing a dynamically evolving information model.
2. Impacts on HLA Standards and Object Model Specification
The introduction of modular HLMs precipitated major extensions to the HLA standard:
- The HLA federation framework allows the federation to be initialized with multiple FOM modules (with one mandatory MIM), fundamentally altering Rule 1 and Rule 6 to reflect modular FOMs rather than monolithic ones.
- The OMT specification now supports multi-module object models. Each module’s identification tables are extended with reference fields indicating type—Standalone, Dependency, or Composed From—documenting compositional status and origin.
- The federate interface specification is updated for modularity: federates may provide multiple module references during federation creation/join, with the Run-Time Infrastructure (RTI) tracking and managing FOM extensions atomically. Additional MOM interactions (e.g., HLArequestFOMmoduleData, HLAreportFOMmoduleData) facilitate dynamic awareness.
3. FOM Extension and Merging Processes
HLMs in the modular FOM sense enable extendable and composable models. Four extension principles are considered: addition of new root classes; adding subclasses to existing classes; adding new attributes to existing classes; and adding new interaction parameters. The framework adopts option (b)—permitting new subclasses to existing classes—as the optimal trade-off, facilitating federation-wide extensions with minimal runtime complexity and minimal impact on compatibility.
The merging process constructs the Current FOM by top-down traversal: at each hierarchy level, classes from new modules are merged unless a duplicate (by name/attributes/datatypes) is detected. Duplicates are ignored or resolved by equivalence checking; unique classes and all their sub-elements (attributes, parameters, datatypes) are recursively attached. Certain global tables (e.g., FOM switches, time representations) require strict elementwise equivalence. This regimented process maintains cross-module consistency and ensures that resulting FOMs are valid, non-redundant compositions.
4. Permitted and Restricted Module Combinations
Permitted combinations are strictly hierarchical:
| Allowed | Restricted | |
|---|---|---|
| Module Types | Standalone modules + MIM | Dependent without standalone |
| Dependencies | Dependent modules build on standalone | Standalone on standalone or dependent |
| Compositionality | Multiple dependents on base | External refs undefined in base modules |
A Standalone module (with MIM) forms the required base; dependent modules may be layered but never without foundation. Each referenced entity in a dependent module must be resolvable higher up.
The model can be depicted schematically as:
5. Relationship to the Base Object Model (BOM)
The Base Object Model (BOM) and modular FOM serve complementary but distinct roles. BOMs, developed under the SISO standard, encapsulate conceptual model components (e.g., mapping, lexicon), focusing on high-level interoperability and conceptual reuse. Modular FOMs, in contrast, directly address implementation: defining runtime object/interaction classes, attributes, and operational information exchange. While BOMs provide upper-level design abstractions, modular FOMs enable composable, plug-and-play instantiation within RTI-managed federations.
Hybrid strategies—mapping BOMs to modular FOM modules—allow conceptual design and software implementation to co-evolve, enhancing both reuse and systematic federation building.
6. Applications, Significance, and Tooling
Modular HLMs are now foundational for:
- Composable reference FOMs, supporting distributed model development with independent module integration.
- Reusable federation agreements, disaggregated into interchangeable modules rather than monolithic artifacts.
- Long-running dynamic federations, where new federates with novel capabilities may extend the FOM at runtime via approved modules, avoiding federation restart.
- Commercial RTI platforms (including Pitch and MAK RTI) that offer direct modular FOM support.
Significance includes improvements in composability, reusability, and agility, fostering on-demand simulation assembly and supporting net-centric applications and wargames. The framework also informs academic research into modular simulation design and composability theory.
7. Future Directions
Ongoing work addresses:
- Deployment and robustness enhancements in RTI implementations (open-source and proprietary).
- Full integration of modular FOM principles into related HLA standards (e.g., FEDEP, federation verification, accreditation).
- Automated mapping and conversion between BOM and modular FOM representations, towards seamless conceptual-to-runtime design chains.
- Integration with web services, XML Schema, fault-tolerant and service-oriented architectures, as well as composable simulation approaches (e.g., DEVS, ontologies, MDA).
- Development of tools for after-action review, dynamic extension management, and modular federation lifecycle control.
This evolving ecosystem aims to advance modular composability and runtime adaptability, ultimately supporting rapid federation configuration and systematic model evolution.
In summary, high-level models (in the HLA Evolved sense) modularize federation object models into extensible, composable components, embedding explicit extension and merging semantics, defined composition rules, and compatibility with both conceptual (BOM) and implementation (modular FOM) frameworks. This approach has redefined the standards landscape for distributed simulation by enabling agile, dynamic, and reusable federation architectures across academia and industry (0909.1364).