High Level Architecture Overview and Rules These slides

High Level Architecture Overview and Rules These slides were borrowed, for the most part, directly from DMSO Thanks to: Dr. Judith Dahmann, and others from: Defense Modeling and Simulation Office phone: (703) 998 -0660 FAX: (703) 998 -0667 jdahmann@msis. dmso. mil

HLA Motivation: M&S Critical to Do. D’s Ability to Meet its Mission Continuing squeeze on Do. D resources • shrinking, dispersed force structure • competition for O&M funds limits field exercises • need to carefully examine every investment More demanding operational requirements • • • new, more complex missions vastly expanding mission space increased complexity of systems and plans increasing demand for joint training security challenges (e. g. , information warfare) no traditional way to address Advanced M&S offers a cost-effective and affordable solution Much more technical capability at less cost • • • communications computers advanced software technology displays/human-machine interfaces data storage and management 2

Do. D M&S Master Plan Objective 1 -1 • Establish a common high-level simulation architecture to facilitate the interoperability of all types of models and simulations among themselves and with C 4 I systems, as well as to facilitate the reuse of M&S components - Simulations developed for particular Do. D Components or Functional Areas must conform to the High Level Architecture - Further definition and detailed implementation of specific simulation system architectures remain the responsibility of the developing Component The Common Technical Framework, and specifically the High Level Architecture, represents the highest priority effort within the Do. D modeling and simulation community 3

What is an Architecture? • An “architecture” defines the major functional components, design rules, and interfaces for a computer-based simulation system. It specifies (conceptually) how they hook together and work together as a whole • An architecture is NOT the software which is required to implement it 4

High Level Architecture • Major functional elements, interfaces, and design rules, pertaining to all Do. D simulation applications, and providing a common framework within which specific system architectures can be defined • HLA is the Technical Architecture for Do. D Simulations 5

Rationale for HLA Design • Basic premises - No single, monolithic simulation can satisfy the needs of all users - All uses of simulations and useful ways of combining them cannot be anticipated in advance - Future technological capabilities and a variety of operating configurations must be accommodated • Consequence - Need composable approach to constructing simulation federations • Resulting design principles - Federations of simulations constructed from modular components with well-defined functionality and interfaces - Specific simulation functionality separated from general purpose supporting runtime infrastructure 6

Federates and Federations From the HLA Glossary: • Federate - A member of a HLA Federation. All applications participating in a Federation are called Federates. In reality, this may include Federate Managers, data collectors, live entity surrogates simulations, or passive viewers. • Federation - A named set of interacting federates, a common federation object model, and supporting RTI, that are used as a whole to achieve some specific objective. The underlined words are references to other glossary entries… 7

Other Glossary Terms • Simulation - A method for implementing a model over time. Also, a technique for testing, analysis, or training in which realworld systems are used, or where real-world and conceptual systems are reproduced by a model [Do. D 5000. 59] • Runtime Infrastructure (RTI) - The general purpose distributed operating system software which provides the common interface services during the runtime of an HLA federation. 8

Defining the HLA • HLA Rules - A set of rules which must be followed to achieve proper interaction of simulations in a federation. These describe the responsibilities of simulations and of the runtime infrastructure in HLA federations. • Interface Specification - Definition of the interface functions between the runtime infrastructure and the simulations subject to the HLA. • Object Model Template - The prescribed common method for recording the information contained in the required HLA Object Model for each federation and simulation. 9

Functional View of the Architecture Live Participants Support Utilities Simulations Live Player Interfaces Interface Runtime Infrastructure Federation Management Declaration Management Object Management Ownership Management Time Management Data Distribution Management 10

HLA Object Models and OMT • Federation Object Model (FOM) - A description of all shared information (objects, attributes, associations, and interactions) essential to a particular federation • Simulation Object Model (SOM) - Describes objects, attributes and interactions in a particular simulation which can be used externally in a federation • Object Model Template (OMT) - Provides a common framework for HLA object model documentation - Fosters interoperability and reuse of simulations and simulation components via the specification of a common representational framework 11

HLA Rules • Ten basic rules that define the responsibilities and relationships among the components of an HLA federation - Five rules apply to federations - Five rules apply to federates 12

Federation Rules • Rule 1: - Federations shall have an HLA Federation Object Model (FOM), documented in accordance with the HLA Object Model Template (OMT). • Rule 2: - In a federation, all object representation shall be in the federates, not in the runtime infrastructure (RTI). • Rule 3: - During a federation execution, all exchange of FOM data among federates shall occur via the RTI. 13

Federation Rules • Rule 4: - During a federation execution, federates shall interact with the runtime infrastructure (RTI) in accordance with the HLA interface specification. • Rule 5: - During a federation execution, an attribute of an instance of an object shall be owned by only one federate at any given time. 14

Federate Rules • Rule 6: - Federates shall have an HLA Simulation Object Model (SOM), documented in accordance with the HLA Object Model Template (OMT). l l Each simulation must describe the functionality it is able to provide to a federation in OMT terms All SOM objects, attributes and interactions may not be used in any given federation – SOM describes the array of options available 15

Federate Rules • Rules 7 - 9: Federates have to abide by the provisions of their SOM - Federates shall be able to update and/or reflect any attributes of objects in their SOM and send and/or receive SOM object interactions externally, as specified in their SOM. (Rule 7) - Federates shall be able to transfer and/or accept ownership of attributes dynamically during a federation execution, as specified in their SOM. (Rule 8) - Federates shall be able to vary the conditions (e. g. , thresholds) under which they provide updates of attributes of objects, as specified in their SOM. (Rule 9) 16

Federate Rules • Rule 10: Time Management - Federates shall be able to manage local time in a way which will allow them to coordinate data exchange with other members of a federation. u u Simulations in a federation must manage time so that there appears to be one clock Internally, a simulation manages time any way it wishes, as long is it meets commitments to other simulations in the federation 17