Live-Virtual-Constructive Architecture Roadmap Implementation Project: Common Gateways and Bridges Task

- Enclosure to NSAD-L-2010-283 JHS01 NSAD-R-2010-100 Live-Virtual-Constructive Architecture Roadmap Implementation Project: Common Gateways and Bridges Task November 2010

- NSAD-R-2010-100 Live-Virtual-Constructive Architecture Roadmap Implementation Project: Common Gateways and Bridges Task November 2010 Prepared by: Robert Lutz, JHU/APL David Drake, JHU/APL Nathaniel Horner, JHU/APL Dannie Cutts, AEgis Technologies Group Kurt Lessmann, Trideum Corporation Michael O Connor, ITT Corporation

This page intentionally left blank.

TABLE OF CONTENTS EXECUTIVE SUMMARY... ES-1 1. INTRODUCTION... 1-1 2. REPORT FORMAT... 2-1 3. PROJECT APPROACH... 3-1 3.1 Development of the... 3-1 3.2 Advancement of the Gateways Characteristics Matrix... 3-1 3.3 Overview... 3-2 4. GATEWAY FUNCTIONAL CAPABILITIES... 4-1 4.1 SDEM Translations... 4-1 4.2 SDEM Behaviors... 4-4 4.3 Architectural Translations... 4-5 4.4 Architectural Behaviors... 4-6 4.5 Exercise Management Behaviors... 4-9 4.6 Fault Tolerance Behaviors... 4-10 5. GATEWAY OPERATIONAL CAPABILITIES... 5-1 5.1 User Interface... 5-1 5.2 Operation Modes... 5-4 5.3 Extension Modes... 5-5 5.4 Support... 5-6 6. APPLICABILITY OF THE CAPABILITIES LIST... 6-1 6.1 Rationale for Developing the... 6-1 6.2 for the End User... 6-1 6.3 Foundation for Other Products... 6-2 7. SUMMARY... 7-1 APPENDIX A: REFERENCES... A-1 APPENDIX B: GATEWAY-RELATED GLOSSARY OF TERMS... B-1 APPENDIX C: ABBREVIATIONS AND ACRONYMS... C-1 Page iii

LIST OF TABLES Table 4-1: Functional Capabilities - SDEM Translations... 4-1 Table 4-2: Functional Capabilities - SDEM Behaviors... 4-4 Table 4-3: Functional Capabilities - Architectural Translations... 4-6 Table 4-4: Functional Capabilities - Architectural Behaviors... 4-6 Table 4-5: Functional Capabilities - Exercise Management Behaviors... 4-9 Table 4-6: Functional Capabilities Fault Tolerance Behavior... 4-11 Table 5-1: Operational Capabilities User Interface... 5-1 Table 5-2: Operational Capabilities Operation Modes... 5-4 Table 5-3: Operational Capabilities Extension Modes... 5-5 Table 5-4: Operational Capabilities Support... 5-7 Page ES-iv

EXECUTIVE SUMMARY In 2009, the Modeling and Simulation Coordination Office (M&S CO) established a High Level Task (HLT) to implement the Live-Virtual-Constructive Architecture Roadmap (LVCAR) recommendations. Since that time, significant progress has been made on many of these tasks, some of which have already transitioned to standards development activities. One of the key areas of investigation is the improvement in distributed simulation gateways, concentrating on how to reduce the proliferation of gateways and reduce the production of singleuse gateways. In support of this objective, two key products were produced in the first year of this task: Gateways Characterization Report: An analysis of the capabilities provided by current gateways, intended to describe the current state of the gateway marketplace [Reference (a)] 1. Gateways Execution Plan: A description of the activities needed to improve the efficiency and effectiveness of gateway utilization in future years, along with supporting rationale [Reference (b)]. In the second year of this effort, the primary focus is on the development of intermediate products that will support the development of formalized gateway description and mapping languages in calendar year 2011 (CY11). One such product is a definitive list of gateway capabilities that will provide the necessary foundation for detailed side-by-side comparisons of candidate gateways, which will lead to better, more informed selection decisions by user programs in the future. The is defined in two main categories, Functional and Operational. The Functional capabilities tend to be concrete and testable. The Operational capabilities tend to be more descriptive of the gateway. These main categories are further divided to provide detail. Definitions for each capability are provided and an example is supplied to help with understandability. The subcategories under functional capabilities are: Simulation Data Exchange Model (SDEM) translations, SDEM behaviors, architectural translations, architectural behaviors, exercise management behaviors, and fault tolerance behaviors. The subcategories under operational capabilities are: user interface, operation modes, extension modes, and support. 1 References may be found in Appendix A. Page ES-1

The is an integral product in the overall effort to improve understanding of available gateway products and to provide a common standard for assessing the ability of a gateway to fulfill a particular use. It provides a means of completing standard functional testing on gateway applications, while the performance benchmarks report establishes a standard for performance testing. Taken together, these complementary products constitute a common framework enabling evaluation of gateways against both expected behaviors and desired performance levels. The and the performance benchmarks are the foundation for a community standard for gateway description and assessment. The is the basis for the more formal Gateway Description Language (GDL), which provides a standard way of describing gateway functionality. Once described by the GDL, each gateway can be assessed against the based on user requirements. Without the Gateways Capabilities List, equitable comparison of gateways would not be possible. Page ES-2

1. INTRODUCTION The integration of Live, Virtual, and Constructive (LVC) Modeling and Simulation (M&S) assets into a unified distributed simulation environment is commonplace today. The need for such environments is widespread within the Department of Defense (DoD), as applications like joint training exercises, joint experimentation, and distributed Test and Evaluation (T&E) events all require the ability to quickly compose new simulation environments from existing LVC assets. Unfortunately, these environments can be very resource-intensive to establish, and the time needed to design, develop, and test these environments can be excessive with respect to the schedules of operational users [Reference (c)]. Due to anticipated increases in the number of distributed simulation events in the future, the DoD sponsored an initiative to examine how supporting LVC simulation environments could be developed more efficiently in the future. This initiative was called the Live-Virtual-Constructive Architecture Roadmap (LVCAR). The more specific goal was to develop a time-phased set of actions to improve interoperability within multi-architecture simulation environments. While technical concerns were emphasized in the study, business and standards concerns were addressed as well. The first phase of this effort began in the spring of 2007 and continued for approximately sixteen months. The result of this activity was a final report and supporting documentation that collectively totaled over 1000 pages. The Roadmap itself defined a structured set of tasks that would collectively produce the various products identified as critical needs in the LVC community. Examples include a systems engineering process description for multi-architecture development and execution, a template for documenting federation agreements, and new language specifications to support automated search, discovery, and configuration of gateways and bridge applications. Other examples include tasks to develop software implementations, such as new or enhanced repositories under the LVCAR "Asset Reuse" task and new object model component libraries under the "Joint Composable Object Model (JCOM)" task. In addition, tasks to address emerging technologies (e.g., "Service-Oriented Architecture" and "LVC Futures") and longer-term management and business model concerns ("Management Organizations and Processes") are included in the Roadmap. In 2009, the Modeling and Simulation Coordination Office (M&S CO) established a High Level Task (HLT) to implement the LVCAR recommendations. Since that time, significant progress has been made on many of these tasks, some of which have already transitioned to standards development activities. One of the Page 1-1

key areas of investigation is the improvement in distributed simulation gateways, concentrating on how to reduce the proliferation of gateways and reduce the production of single-use gateways. In support of this objective, two key products were produced in the first year of this task: Gateways Characterization Report: An analysis of the capabilities provided by current gateways, intended to describe the current state of the gateway marketplace [Reference (a)] 2. Gateways Execution Plan: A description of the activities needed to improve the efficiency and effectiveness of gateway utilization in future years, along with supporting rationale [Reference (b)]. In the second year of this effort, the primary focus is on the development of intermediate products that will support the development of formalized gateway description and mapping languages in calendar year 2011 (CY11). One such product is a definitive list of gateway capabilities that will provide the necessary foundation for detailed side-by-side comparisons of candidate gateways, which will lead to better, more informed selection decisions by user programs in the future. This report provides these gateway capability descriptions (Section 4 and Section 5), along with illustrative examples and defined levels of implementation. 2 References may be found in Appendix A. Page 1-2

2. REPORT FORMAT This report is constructed in four major parts: (a) the executive summary, introduction, and report format; (b) the description of the gateway functional and operational capabilities; (c) the applicability of the gateway characterization list; and (d) a summary of the conclusions. This report has three appendices: Appendix A is a list of referenced documents; Appendix B is a glossary of gateway-related terms; and Appendix C is a list of abbreviations and acronyms. Page 2-1

This page intentionally left blank. Page 2-2

3. PROJECT APPROACH This section addresses the steps in the Common Gateways and Bridges project that led to the development of a and how the project migrated from a Gateways Characteristics document to the development of the. 3.1 DEVELOPMENT OF THE GATEWAYS CAPABILITIES LIST In the Recommended Strategy section of the Gateway Execution Plan, the strategy that was promoted as having the most return on investment was the Enhance Strategy. The Enhance Strategy incorporated several of the fundamental elements that were defined in the Inform Strategy, but extending those elements were several products intended to make a more effective use of gateway capabilities that exist today. After analysis by the sponsor, a subset of these elements containing the high-priority activities for Year 2 was defined: updating and extending the Characterization Report for gateways, producing a Gateway Description Language, producing a Gateway Mapping Language (GML), and developing a Gateway Performance Benchmarks Report. 3.2 ADVANCEMENT OF THE GATEWAYS CHARACTERISTICS MATRIX The Gateways Characteristics Matrix Template was developed in Year 1 of this task to serve as a common communication mechanism to discuss gateway functionality and user needs. The characteristics that are described within that document were collected from developers and users of commonly used gateways and bridges. The desire was to capture an architecturally-neutral baseline of commonlyemployed gateway characteristics. This list of characteristics was sufficient for the initial Gateways Characterization Report; however, it lacked a full level of detail and maturity required to support many other gateway-related tasks. In particular, the long-term goal was to have a sufficiently complete description to allow those characteristics to be tested, definitively recognized as existing or not within a product, and provide direction to developers for potential improvements to their products, as needed. Currently there is no marketplace for users to find available gateways. Potential gateway users face at least the following two hurdles in selecting a gateway. How to identify which gateways claim to satisfy the requester s functional and performance requirements. How to compare gateways that claim to meet those requirements. Page 3-1

The first hurdle is addressed utilizing the to identify users requirements using the same format as used by the gateway developers to advertise their capabilities. This will allow a quick and efficient approach to matching capabilities and requirements to identify a set of gateways. The same capabilities list developed for available gateways will allow users to compare multiple gateways and determine which one best meets their requirements. Additionally, with a well-defined set of characteristics, a clear set of performance benchmarks against those characteristics can be defined. Without this, the overall system-level performance of a multi-architecture simulation cannot be predicted during the design phase due to the lack of known performance characteristics of the simulation s gateways. This forces the performance measurements to be performed after integration activities, which potentially increases risk and lengthens the schedule if the associated gateways demonstrate an inability to support performance requirements of the overall system. 3.3 GATEWAYS CAPABILITIES LIST OVERVIEW The defines a set of capabilities that a gateway might implement. The list is grouped to support understanding of the capabilities. There are two main categories, Functional and Operational, which are presented in Section 4 and Section 5 of this document. The Functional capabilities tend to be concrete and testable. The Operational capabilities tend to be more descriptive of the gateway. These main categories are further divided to support understanding. Each subsection of these two sections provides a definition for its associated capability. Each capability has three elements: Capability Definition, Examples, and Levels of Implementation. The Capability Definition provides a concise definition of the capability. The Examples provide context using a real-world example with which most readers would be familiar. Many of the capabilities can be implemented to different levels. The Levels of Implementation provide a defined set of possible implementations. The number of levels varies based on the capability. Generally a level of 0 means that the capability is not implemented, and conversely, a level of 5 generally means that the capability is fully implemented. Generally a level of 3 represents a partial implementation. Some of the levels do not have defined definitions. These may be selected to represent implementation between the defined levels. Some capabilities are either implemented or not. For these, the levels are a binary yes or no. Page 3-2

4. GATEWAY FUNCTIONAL CAPABILITIES Functional capabilities represent actions required by the gateway to meet Simulation Data Exchange Model (SDEM), architecture, or exercise management needs. These are considered the core capabilities of a gateway. The functional capabilities usually determine if the gateway meets the user functional needs when interfacing between multi-architectural LVC resources [References (d) through (h)]. There are six formal areas of gateway capabilities that are associated with functional translations. They are SDEM translations, SDEM behaviors, architectural translations, architectural behaviors, exercise management behaviors, and fault tolerance behaviors. Each of these areas is detailed in the six subsections below. 4.1 SDEM TRANSLATIONS SDEM Translations comprise the set of capabilities to convert data from one SDEM to another SDEM. This includes unit conversion, coordinate conversion, and enumeration mapping (see Table 4-1). This may require translating data stored in a single object in one SDEM to multiple objects in another SDEM. Examples of SDEM Translations would include unit conversion on a single attribute and singleelement enumeration to a multi-element enumeration. Table 4-1: Functional Capabilities - SDEM Translations Functional Capabilities SDEM Translations Reference ID Capability Definition Examples Levels of Implementation FC-ST-1 Capability to perform unit conversion on a single attribute (SDEM element). gateway can translate meters to feet, or a similar direct algorithmic conversion. 0 = No unit conversion 1 = Single attribute conversion for 5 or fewer defined types 3 = Single attribute conversion for fewer than 15 fixed types 5 = Conversion between arbitrary units Page 4-1

Table 4-1: Functional Capabilities - SDEM Translations (continued) Functional Capabilities Reference Capability ID Definition FC-ST-2 Capability to perform complex data type conversions from single to multiple, multiple to single or different numbers of multiple attributes. This includes coordinate systems with different numbers of components. FC-ST-3 FC-ST-4 Capability to translate single component enumerations between SDEMs. This includes the cases where one SDEM has more than one enumeration value that maps to a single enumeration value in the other SDEM. Capability to translate multicomponent enumerations between SDEMs. SDEM Translations Examples Levels of Implementation 0 = No multiple attribute conversion 1 = Multiple attribute conversion for 5 or fewer fixed types 3 = Multiple attribute conversion for fewer than 15 fixed types 5 = Arbitrary multiple attribute coordinate conversion gateway can translate between coordinate systems with different numbers of components, such as Euler angles (3 elements) to quaternions (4 elements), or articulated parts versus single-frame reference. gateway can translate from Entity Health Status enumeration (healthy, sick, dead) to a different enumeration (mobility, firepower, total kill). gateway can translate between a Distributed Interactive Simulation (DIS) seven-element entity-kind enumeration to a Modeling Architecture for Technology, Research, and Experimentation (MATREX) singleelement entity-kind enumeration. 0 = No single enumeration mapping 1 = One-to-one enumeration mapping 3 = Many-to-one enumeration mapping 5 = Arbitrary enumeration mapping 0 = No multi-component enumeration mapping 1 = 1 type of multicomponent enumeration mapping 3 = 5 types of multicomponent enumeration mapping 5 = Arbitrary multicomponent enumeration mapping Page 4-2

Table 4-1: Functional Capabilities - SDEM Translations (continued) Functional Capabilities Reference Capability ID Definition FC-ST-5 Capability to translate identifiers between SDEMs. FC-ST-6 FC-ST-7 Capability to provide static default information that is required by one SDEM but not present in the other. Can the gateway provide the user a mechanism for specifying this information Capability to calculate dynamic information that is required by one SDEM but not present in the other. To perform this, the gateway must provide the user a mechanism for specifying this information. SDEM Translations Examples Levels of Implementation 0 = No translation of SDEM identifiers 1 = 1 specific translation 3 = 5 specific translations 5 = Ability to provide an arbitrary number of identifier translations gateway can translate between a DIS threeelement identifier and another architecture s single-element identifier. This does not refer to the object handle that is assigned by the architecture, for example, High Level Architecture (HLA) Run Time Infrastructure (RTI) object handle. gateway can translate from an SDEM that requires a specific attribute to an SDEM that does not require the attribute. This may be performed by adding values for attributes that are required in the translated from SDEM to the translated to SDEM. gateway can translate between an SDEM that calculates velocity from two points over time and another SDEM that calculates velocity using orientation based on position relative to the earth. 0 = No ability to add data 1 = Ability to add 1 fixed type of data 3 = Ability to add 15 fixed types of data 5 = Ability to add arbitrary data 0 = No ability to add dynamic information 1 = 1 defined dynamic translation 3 = 15 defined dynamic translations 5 = Arbitrary ability to add dynamic information Page 4-3

4.2 SDEM BEHAVIORS SDEM Behaviors comprise the capability to correctly represent behaviors, if required, by an SDEM (see Table 4-2). This may include representing a behavior in one SDEM that is present in the other SDEM. SDEM behaviors may require the gateway to maintain state. An example of a SDEM Behavior is dead-reckoning of positional attributes. Table 4-2: Functional Capabilities - SDEM Behaviors Functional Capabilities SDEM Behaviors Reference ID Capability Definition Examples Levels of Implementation FC-SB-1 Capability to provide dead-reckoning between SDEMs that use different deadreckoning mechanisms. FC-SB-2 Capability to provide dead-reckoning when required by one SDEM and not the other. gateway can translate between one SDEM that uses the DIS-defined dead-reckoning algorithms and another SDEM that uses a different set of deadreckoning algorithms. Another example is where both SDEMs use DIS dead-reckoning schemes but use different algorithms. gateway could properly translate between an SDEM that does not require dead-reckoning and an SDEM that does. In this example, the gateway might be able to emulate the required dead-reckoning. 0 = No dead-reckoning support 1 = Map between different DIS deadreckoning algorithms (up to 4) 3 = Map between all DIS dead-reckoning algorithms 5 = Ability to map between arbitrary dead-reckoning algorithms 0 = No support for emulating deadreckoning 3 = Provides support for emulating DIS deadreckoning algorithms 5 = Provides support for emulating arbitrary dead-reckoning algorithms Page 4-4

Table 4-2: Functional Capabilities - SDEM Behaviors (continued) Functional Capabilities Reference Capability ID Definition FC-SB-3 Capability to publish attributes based on updates exceeding thresholds. FC-SB-4 FC-SB-5 This does not include thresholds associated with dead-reckoning, which is covered in FC-SB-1. Capability to support behaviors defined in one SDEM but not in the other. Capability to support differing SDEM defined publication rates. This does not include dead-reckoning or thresholding, which is covered in FC-SB-1. Examples gateway could properly translate between DIS entity heart-beating or transmitter status and an architecture that did not require heart-beats, but did need updates when thresholds were exceeded. gateway could properly translate behaviors of the SDEM such as collision detection, damage assessment, radio communications degradation, or mobility. gateway could properly translate two different SDEMs that require higher or lower publication rates at which certain objects or attributes have to be updated. SDEM Behaviors Levels of Implementation 0 = No ability to publish attributes based on thresholds 3 = 5 fixed thresholds to publish attributes 5 = Ability to publish attributes based on arbitrary thresholds 0 = No capability to support required SDEM behaviors 1 = Capability to support 1 fixed behavior 3 = Capability to support 5 fixed behaviors 5 = Ability to support an arbitrary number of behaviors 0 = No support for SDEM publication rates 1 = Supported for 1 fixed publication rate 3 = Supported for 5 fixed publication rates 5 = Arbitrary SDEM publication rates 4.3 ARCHITECTURAL TRANSLATIONS Architecture Translations comprise the set of capabilities to convert architecture-defined data between different architecture executions. This covers translation of data not defined in the SDEM, but that is present in all architecture executions (see Table 4-3). Examples of Architecture Translations are translation of object identifiers and timestamps. Page 4-5

Table 4-3: Functional Capabilities - Architectural Translations Functional Capabilities Reference Capability ID Definition FC-AT-1 Capability to translate identifiers between Architectures. Architectural Translations Examples Levels of Implementation gateway supports the mapping between an HLA Object Handle to a Test and Training Enabling Architecture (TENA) Unique Identification (ID). 0 = No ability to translate architecture ids 1 = Ability for scheme based on 2 architectures/ implementations 3 = Ability for scheme based on 5 architectures/ implementations 5 = Arbitrary identifier translation 4.4 ARCHITECTURAL BEHAVIORS Architecture Behaviors comprise the set of capabilities to perform actions required by the architecture. These behaviors are required by the architecture and apply to all SDEMs using the architecture (see Table 4-4). An example of an Architecture Behavior is a request to publish attributes of a specified object. Table 4-4: Functional Capabilities - Architectural Behaviors Functional Capabilities Architectural Behaviors Reference ID Capability Definition Examples Levels of Implementation FC-AB-1 Capability to support architecturedefined publication rates. gateway can translate between one architecture that operates under one publication rate and another architecture that operates under a different rate or does not define a rate at all. 0 = Cannot support architecture publication rates 3 = Can support 5 fixed architecture publication rates 5 = Can support an arbitrary set of publication rates Page 4-6

Table 4-4: Functional Capabilities - Architectural Behaviors (continued) Functional Capabilities Reference Capability ID Definition FC-AB-2 Capability to publish all the attributes of an object in an Architecture that does not support partial updates when translating from an Architecture that permits partial updates. FC-AB-3 FC-AB-4 Capability to publish only changed attributes of an object in a Architecture that permits partial updates when translating from an Architecture that requires publication of all attributes for each update. Capability to support responding to publication requests. Architectural Behaviors Examples Levels of Implementation 0 = Cannot support publishing all attributes 3 = Can publish all attributes for 5 selected object types 5 = Can publish all attributes based on partial attribute update gateway can receive a partial update of an HLA object and correctly translate it to a completely filled out DIS Protocol Data Unit (PDU). For example, a gateway receives a DIS PDU where only one element has changed and updates the only changed attribute in HLA. gateway translates between TENA and HLA, and TENA makes a Request Attribute Update service call on an object, the gateway will request that the appropriate federates provide updated attribute values. 0 = Cannot publish only changed attributes 3 = Can publish only changed attributes for 5 selected objects 5 = Can publish only changed attributes for an arbitrary number of objects 0 = Cannot respond to publication requests 5 = Can respond to publication requests Page 4-7

Table 4-4: Functional Capabilities - Architectural Behaviors (continued) Functional Capabilities Reference Capability ID Definition FC-AB-5 Capability to translate Remote Procedure Calls (RPCs) between architectures that support RPCs. FC-AB-6 FC-AB-7 Capability to translate RPCs from architectures that support RPCs to an architecture that does not support RPCs. This may require translating RPCs to other types of SDEM elements for SDEMs/protocols that do not natively support RPCs. Capability to translate RPCs from an architecture that does not support RPCs to one that does. Architectural Behaviors Examples Levels of Implementation 0 = No support for RPCs when both architectures do not support 3 = Ability to translate 5 selected RPCs 5 = Ability to translate an arbitrary number and type of RPCs gateway correctly translates between two or more architectures that support some form of RPCs but not in the same manner. gateway can convert a TENA Remote Method Invocation (RMI) to an HLA/Federation Object Model (FOM) specific interaction. gateway can support an HLA/FOM specific interaction to a TENA RMI. 0 = No support for translating RPCs to a non-rpc architecture 3 = Ability to support translating 5 selected RPCs to a non-rpc architecture 5 = Unrestricted ability to support translating RPCs to a non-rpc architecture 0 = No support for translating RPCs from an architecture that does not support RPCs to one that does 3 = Ability to support 5 selected RPCs from an architecture that does not support RPCs to one that does 5 = Unrestricted ability to support translating RPCs from an architecture that does not support RPCs to one that does Page 4-8

Table 4-4: Functional Capabilities - Architectural Behaviors (continued) Functional Capabilities Reference Capability ID Definition FC-AB-8 Capability to remove translated objects based on the rules of the original publisher architecture. Architectural Behaviors Examples Levels of Implementation 0 = No ability to remove objects based on original publisher s rules 3 = Ability to remove a limited set of object types based on 5 selected rules 5 = Unrestricted ability to support removal rules gateway translates between HLA and DIS and an HLA object is deleted, it allows DIS to set the final PDU bit. A similar example is if a gateway could allow TENA to remove a Stateful Distributed Object (SDO) pointer. 4.5 EXERCISE MANAGEMENT BEHAVIORS Exercise Management Behaviors are capabilities that are not directly related to the SDEM or architecture. These capabilities are used to meet objectives of the overall exercise independent of the SDEM or architecture (see Table 4-5). These capabilities may not involve the translation of data or behaviors. An example of an Exercise Management Behavior is filtering to conserve bandwidth. Table 4-5: Functional Capabilities - Exercise Management Behaviors Functional Capabilities Exercise Management Behaviors Reference Capability Examples Levels of implementation ID Definition FC-EMB-1 Capability to set publication rates for object classes For example, a gateway that supports an exercise manager that might choose to reduce update rates from one side of the gateway to the other for a particular class of objects. 0 = No support for exercise management rates 1 = Support for setting publication rates for 1 type of object class 3 = Support for setting publication rates for 5 object classes 5 = Unrestricted support for setting publication rates for object classes Page 4-9

Table 4-5: Functional Capabilities - Exercise Management Behaviors (continued) Functional Capabilities Reference Capability ID Definition FC-EMB-2 Capability to filter (i.e., not translate) specified objects between SDEMs based on their attributes or classes FC-EMB-3 FC-EMB-4 Capability to filter updates from specified senders (i.e., simulations) Capability to filter updates based on conditions or events Exercise Management Behaviors Examples Levels of Implementation For example, a gateway that supports filtering out all air platforms from being passed from one SDEM to another SDEM. For example, a gateway with the ability to filter any updates published by a specific sender/simulation. For example, a gateway that supports proximity filtering to ignore air platforms outside of a sensor's range. 0 = No ability to filter 1 = Ability to filter based on 1 class or attribute 3 = Ability to filter based on 5 attributes or classes 5 = Unrestricted ability to filter objects based on their attributes or classes 0 = No ability to filter based on sender 3 = Can only filter all classes from sender 5 = Can filter selected classes from sender 0 = No ability to filter based on conditions or events 1 = Ability to filter based on 1 fixed events or conditions 3 = Ability to filter based on 5 fixed events or conditions 5 = Ability to filter on arbitrary conditions or events 4.6 FAULT TOLERANCE BEHAVIORS Fault Tolerance Behaviors are capabilities related to how a gateway handles anomalies in the use of the SDEM or architecture by Federates in the federation. These capabilities focus on how the gateways handle the receipt of anomalous data (see Table 4-6). This category does not address flaws in the gateway itself. Page 4-10

Table 4-6: Functional Capabilities Fault Tolerance Behavior Functional Capabilities Reference Capability Examples ID Definition FC-FTB-1 Capability to handle invalid data in SDEM fields that is required for translation or conversion. FC-FTB-2 FC-FTB-3 Capability to handle missing SDEM data that is required for translation or conversion. Capability to handle invalid SDEMdefined identifiers. This includes duplicate identifiers or identifiers that do not exist. gateway expects data received for a field to be a floating point value, and can detect that the data received does not represent a floating point value (i.e., data type mismatch). gateway translates from a SDEM that uses Latitude/Longitude/ Altitude for position to a SDEM that is using geocentric (GCC); if the Altitude field does not have a value then the gateway does not crash. gateway does not crash even though it translates an HLA or TENA SDEM where an object references another object by its SDEM-defined identifier, and the reference is to a nonexistent object. Fault Tolerance Behavior Levels of Implementation 0 = No ability to handle invalid data and the outcome is that the gateway crashes 1= Can handle some invalid fields, but crashes on others 3= Detects invalid data but does not translate update, and consequently does not crash 5= Detects invalid data and translates update using user-specified data 0 = No ability to handle missing data; gateway crashes 1 = Can handle some missing fields, but crashes on others 3 = Detects missing data and does not translate update; does not crash 5 = Detects missing data and translates update using user-specified data 0 = No ability to handle invalid identifiers, and crashes 1 = Detects some invalid identifiers, but crashes on others 3 = Detects invalid identifier - does not translate update and does not crash 5 = Corrects the identifiers based on user-defined scheme and translates the update Page 4-11

Table 4-6: Functional Capabilities - Fault Tolerance Behaviors (continued) Functional Capabilities Reference Capability Examples ID Definition FC-FTB-4 Capability to handle invalid gateway does not crash architecturedefined even though it translates an HLA or identifiers; TENA SDEM where an this includes object references duplicate another object by its identifiers or architecture-defined identifiers identifier, and the that do not reference is to a exist. nonexistent object. FC-FTB-5 FC-FTB-6 FC-FTB-7 Capability to handle the result of a simulation incorrectly using an architecturedefined service. Capability to handle incomplete enumeration mapping tables. Capability to handle data overflow. gateway does not crash even though it translates from the SDEM of a simulation that updates an object that does not exist. Note: This may imply that the underlying architecture middleware is not correctly implemented. gateway does not crash even though the enumeration mapping provided it does not provide a map for all enumeration values in use. gateway does not crash even though the rate of incoming data exceeds the ability of the gateway to process. Fault Tolerance Behaviors Levels of Implementation 0 = No ability to handle invalid identifiers, and crashes 1 = Detects some invalid identifiers, but crashes on others 3 = Detects invalid identifier - does not translate update and does not crash 5 = Corrects the identifier and translates the update 0 = No ability to handle and crashes 3 = Has the ability to handle some results of incorrect use of architecture services 5 = Handles and does not crash 0 = No ability to handle incomplete enumeration mapping tables, and crashes if translating using such a table 3 =Does not translate, and does not crash 5 = Makes a user-defined translation and does not crash 0 = No ability to correct for data rates in excess of capability 3 = Gateway takes action to prevent crashing 5 = Gateway follows a userdefined behavior to take actions Page 4-12

5. GATEWAY OPERATIONAL CAPABILITIES Operational capabilities describe features of the gateway not directly related to translation. These capabilities generally relate to the usability of the gateway. There are four areas of gateway capabilities in the operational capabilities category. They are user interface, operation modes, extension modes, and support. Each of these areas is detailed in the four subsections below. 5.1 USER INTERFACE This category comprises the set of capabilities that allows the user to interact with the operation of the gateway during pre-exercise, exercise, and post-exercise activities. This category includes display of runtime information to the user (see Table 5-1). One example of a User Interface capability is the ability to view the execution time required to translate objects. Table 5-1: Operational Capabilities User Interface Operational Capabilities User Interface Reference ID Capability Definition Examples Levels of Implementation OC-UI-1 Capability to configure the gateway via a Graphical User Interface (GUI). For example, if the user can define which objects are to be translated via a GUI. 0 = No GUI for configuration 3 = A GUI is provided for some configuration parameters 5 = A GUI is provided for all configuration OC-UI-2 Capability to guide the user in the setup of gateway via an interactive GUI. gateway configuration system has a wizard-like user interface that asks simple questions and then creates the gateway s configuration files. parameters 0 = No guided setup GUI 3 = Guided setup GUI for some options 5 = Full guided setup GUI Page 5-1

Table 5-1: Operational Capabilities User Interface (continued) Operational Capabilities Reference Capability ID Definition OC-UI-3 Capability to provide translation statistics during runtime. OC-UI-4 OC-UI-5 OC-UI-6 OC-UI-7 Capability to display gateway status during runtime. Capability to display anomaly detection and actions taken during runtime. Note: This assumes the gateway has the ability to detect the anomaly. See Fault Tolerant Behaviors. Capability to generate debug log and allow the user to specify its level of logging. Capability to allow a user to modify translation rules during runtime. Examples gateway has the ability to display the number of entities being translated, or the number of translation failures or dropped messages. gateway has the ability to display its memory utilization or its message queue sizes. gateway has the ability to display the anomaly of expecting floating point data for a field, but the data does not represent a floating point value. This is reported to the user and information about how the gateway handled the invalid data. gateway supports the generation of a log file of non-translatable objects. gateway allows a user to change filtering preferences during runtime, such as the blocking of any data from a simulation. User Interface Levels of Implementation 0 = No translation statistics provided during runtime 3 = 5 translation statistics provided during runtime 5 = 10 or more translations statistics provided during runtime 0 = no status provided during runtime 3 = 5 status indicators during runtime 5 = 10 or more status indicator during runtime 0 = No anomaly reporting during runtime 3 = Reports anomaly to the user 5= Reports anomaly to the user including error handling details 0 = No debug log generated 3 = Debug log generated 5 = Debug log generated with user-specified level of detail 0 = No ability to modify translation rules at runtime 3 = Ability to modify 5 translation rules at runtime 5 = Ability to modify 10 or more translation rules at runtime Page 5-2

Table 5-1: Operational Capabilities User Interface (continued) Operational Capabilities Reference Capability ID Definition OC-UI-8 Capability to use multiple gateway instances to partition and distribute the translation function. OC-UI-9 OC-UI-10 OC-UI-11 Capability to control one or more gateways during runtime remotely. Capability to remotely configure one or more gateways before runtime. Capability to remotely monitor one or more gateways during runtime. Examples For example, if two gateway instances are used where one performs the translation of objects of only one class and the other gateway instance performs the translation of all other SDEM data. For example, if during runtime, a gateway directs one or more gateways to filter updates from a specified sender, assuming the controlled gateway has this capability. gateway has the capability to push configuration files to multiple gateway instances before the start of the event. user can monitor the memory utilization of the gateway from a remote location. User Interface Levels of Implementation 0 = No capability to partition object class translations across gateway instances 3 = Ability to partition and distribute object class translations between 2 gateway instances 5 = Ability to partition and distribute object class translations across more than 2 gateway instances 0 = No ability to remotely control the gateway 1= Ability to remotely start and stop a gateway 3 = Ability to remotely control 5 functions 5 = Ability to remotely control all gateway functions 0 = No ability to remotely configure the gateway 3 = Ability to remotely configure 5 gateway parameters 5 = Ability to remotely configure all gateway parameters 0 = No ability to remotely monitor the gateway 3 = Ability to remotely monitor 5 gateway characteristics 5 = Ability to remotely monitor all gateway characteristics Page 5-3

5.2 OPERATION MODES This category comprises the set of possible operation modes for a gateway. A gateway may be able to operate in one or more modes. The modes are based on the ability of the gateway to perform translations between SDEMs and Architectures (see Table 5-2). An example of an Operation Mode is the restriction of a gateway to only perform translations between SDEMs on a single architecture. Table 5-2: Operational Capabilities Operation Modes Operational Capabilities Operation Modes Reference ID Capability Definition Examples Levels of Implementation OC-OM-1 Capability to translate between two different SDEMs that are using the same architecture (two-sided gateway). gateway translates between Realtime Platform Reference (RPR) FOM and MATREX FOM using Yes/No OC-OM-2 OC-OM-3 OC-OM-4 Capability to translate between two different SDEMs that are using two different architectures (two-sided gateway). Capability to translate between three different SDEMs that are using up to three different architectures (3-sided gateway). Capability to translate between more than three different SDEMs that are using more than three different architectures (nsided gateway). HLA. gateway translates between an HLA SDEM using the RPR FOM and TENA using the TENA Standard Object Model TENA-Platform DIS-EntityType-v1. gateway translates between DIS, an HLA SDEM using the RPR FOM, and TENA using TENA Standard Logical Range Object Model (LROM). gateway translates between DIS, an HLA SDEM using the RPR FOM, TENA using TENA Standard LROM, and Common Training Instrumentation Architecture (CTIA). Yes/No Yes/No Yes/No Page 5-4

Table 5-2: Operational Capabilities Operation Modes (continued) Operational Capabilities Operation Modes Reference ID Capability Definition Examples Levels of Implementation OC-OM-5 Capability to translate between different versions of an architecture using the same SDEM. gateway translates between TENA 5.2.2 and TENA 6.0. Yes/No OC-OM-6 Capability to translate between two different architectures using equivalent SDEMs. gateway translates HLA and TENA using the same SDEM. This example assumes a SDEM that has equivalent representations as a HLA FOM and TENA LROM. Yes/No 5.3 EXTENSION MODES This category includes the set of possible modes in which a gateway can be extended to support new SDEMs and architectures. A gateway may support more than one extension mode. Some gateways may be limited and only support a predetermined set of SDEM/architecture combinations (see Table 5-3). An example of an Extension Mode is requiring all translations to be hand-coded by the end user. Table 5-3: Operational Capabilities Extension Modes Operational Capabilities Extension Modes Reference ID Capability Definition Examples Levels of Implementation OC-EM-1 The gateway has a single code base and is extended by modifying that code. For example, a gateway that can be modified only by having access to its Yes/No OC-EM-2 The gateway has its core translations provided by the developer, where extensions can be made via an Application Programming Interface/Software Development Kit (API/SDK) plug-in. source code. gateway developer provides a base set of translations, and a capability is provided to the end user to implement new translations that are then linked in to the base capability. Yes/No Page 5-5

Table 5-3: Operational Capabilities Extension Modes (continued) Operational Capabilities Extension Modes Reference ID Capability Definition Examples Levels of Implementation OC-EM-3 The gateway has its core translations provided by the developer, and allows extensions that can be made via a developerprovided code generator. gateway developer provides a base set of translations, and the gateway developer also provides a code generator to the end user to extend Yes/No OC-EM-4 OC-EM-5 The gateway has all its translations created by a developer-provided code generator. The gateway allows a runtime translation to be performed using interpreted mapping files. the gateway s capabilities. gateway developer provides a codegenerator that the end user uses to configure the required translation for the gateway. gateway interprets a mapping file to perform translations at run time. Yes/No Yes/No 5.4 SUPPORT This category defines the different types of support available from the gateway developer, configuration manager, or sponsor (see Table 5-4). An example of a Support characteristic is the level of user documentation. Page 5-6

Table 5-4: Operational Capabilities Support Operational Capabilities Reference Capability Examples ID Definition OC-S-1 Available For example, if user documentation manuals, training for the materials, podcasts, gateway installation guides, release notes, and/or programming guides are provided as part of the acquisition of the OC-S-2 Help Desk / Support available OC-S-3 OC-S-4 OC-S-5 Feature request form or process Problem report form or process Sustainment or maintenance process gateway. phone number is supplied to gateway users for a fee that gives normal business day support for bug fixes, usage questions, and troubleshooting. For example, the gateway has an associated web page allowing users to request new features in an informal manner to an email address of the development team. For example, the gateway has an associated web page allowing users to report problems in an informal manner to an email address of the development team. For example, the gateway was developed for a single use, and has no sustainment or maintenance process or plan. Support Levels of Implementation 0 = No documentation 1 = Informal documentation (i.e., some slides or notes) 3 = 3 formal documents (user manual, training package, or online help) 5 = More than 5 formal documents 0 = No Help Desk 1 = E-mail, but no funded support to answer questions 3 = E-mail-only response that is funded 4 = E-mail and telephone support manned during normal business hours 5 = Funded onsite support 0 = No feature request process 3 = Informal feature request process 5 = Formal feature request process 0 = No problem report process 3 = Informal problem reporting 5 = Formal problem report process 0 = No sustainment or maintenance process 3 = Informal sustainment or maintenance process 5 = Formal sustainment or maintenance process Page 5-7

Table 5-4: Operational Capabilities Support (continued) Operational Capabilities Reference Capability Examples ID Definition OC-S-6 Ownership For example, if the model development of the gateway has been funded by the United States (US) government, making it a Government Off- The-Shelf (GOTS) OC-S-7 OC-S-8 OC-S-9 OC-S-10 Licensing requirement What architectures are supported List of SDEMs supported Operating systems that are supported by the gateway product. For example, the end user may have to buy a license based on the number of simulation components that communicate to the gateway. For example, the gateway may support a DIS-to-HLA communication. For example, the gateway may support RPR FOM, TENA Standard Platform Object Model For example: Windows, Linux, OS X, Solaris, VX Works, etc. Support Levels of Implementation Select: GOTS Commercial Off-The-Shelf (COTS) Open Source Mixed GOTS/COTS Select: No License required No-cost end user license required License required at a cost to the end user Select all that apply: DIS HLA TENA CTIA Other Developer provides a list of SDEMs supported Developer provides a list of operating systems on which the gateway can operate Page 5-8

6. APPLICABILITY OF THE CAPABILITIES LIST This section describes the value of the to the user. The is also the foundation of other products of this task. This section also describes how other products use the list. 6.1 RATIONALE FOR DEVELOPING THE GATEWAYS CAPABILITIES LIST The is an integral product in the overall effort to improve understanding of available gateway products and to provide a common standard for assessing the ability of a gateway to fulfill a particular use. It also provides a means of defining a set of standard functional test metrics for gateway applications via the stratums provided in the Levels of Implementation columns in Table 4-1 through Table 5-4. The planned performance benchmarks report, using these stratums, will establish a standard for performance testing. Taken together, these complementary products constitute a common framework enabling evaluation of gateways against both expected behaviors and desired performance levels. As such, the and the performance benchmarks are the foundation for a community standard for gateway description and assessment. The is the basis for the more formal Gateway Description Language (GDL), which provides a standard way of describing gateway functionality. Once described by the GDL, each gateway can be assessed against the based on user requirements. Without the, equitable comparison of gateways would not be possible. 6.2 GATEWAYS CAPABILITIES LIST FOR THE END USER The provides a common gateway-independent mechanism for describing gateways. As with much of the simulation world, a primary issue with discussing gateways is the lack of a well-defined terminology. Gateways implement a number of concepts; however, there are not generally agreed-upon names for these concepts. This lack of a common understanding hinders users and developers in communicating capabilities and requirements. The provides this common terminology. Gateway users, developers, and assessors will use the Gateways Capabilities List. Gateway users will utilize the list to filter the universe of available gateways based on the functional requirements of their simulation applications. Page 6-1

Gateway developers will use the list to assess the capability of their products and may also view the list as a basic requirements framework for new gateways. Finally, the maintainers of a future gateway clearing house or independent assessment body will evaluate the gateways against this common, standard list of capabilities. 6.3 GATEWAYS CAPABILITIES LIST FOUNDATION FOR OTHER PRODUCTS In the Recommended Strategy section of the Gateway Execution Plan, the strategy that was promoted as having the most return on investment was the Enhance Strategy. The Enhance Strategy incorporated several of the fundamental elements that were defined in the Inform Strategy, but extended those elements were several products intended to make a more effective use of gateway capabilities that exist today. After analysis by the sponsor, a subset of these elements were determined to be the high-priority activities for Year 2: updating and extending the Characterization Report for gateways, producing a Gateway Description Language, producing a Gateway Mapping Language, and developing a Gateway Performance Benchmarks Report. The SDEM Translation capabilities are used as part of the Gateway Mapping Language. The types of transformations that are required between SDEMs are based on the. The Gateway Mapping Language uses Exercise Management Behaviors capabilities to define exercise specific parts of the language. Page 6-2

7. SUMMARY In modern multi-architecture distributed simulation environments, gateways play an important role in reconciling the various differences among the different simulation architectures. Despite the success many programs have achieved with respect to their gateway implementations, the results of LVCAR Implementation Year 1 have helped to identify several problems and inefficiencies with respect to how gateways are applied in today's LVC simulation applications, which result in undesirable increases in cost and technical risk. The objective of the LVCAR Implementation Year 2 Gateways and Bridges task is to examine these perceived problems and offer solutions that will allow multi-architecture distributed simulation environments to be built better, faster, and cheaper in the future. In the second year of this effort, the primary focus is on the development of intermediate products that will support the development of formalized gateway description and mapping languages in CY11. One such product is a definitive list of gateway capabilities, which will provide the necessary foundation for detailed sideby-side comparisons of candidate gateways, which will lead to better, more informed selection decisions by user programs in the future. The is an integral product in the overall effort to improve understanding of available gateway products and to provide a common standard for assessing the ability of a gateway to fulfill a particular use. It provides a means of completing standard functional testing on gateway applications, while the performance benchmarks report establishes a standard for performance testing. Taken together, these complementary products constitute a common framework enabling evaluation of gateways against both expected behaviors and desired performance levels. As such, the and the performance benchmarks are the foundation for a community standard for gateway description and assessment. The is the basis for the more formal Gateway Description Language (GDL), which provides a standard way of describing gateway functionality. Once described by the GDL, each gateway can be assessed against the based on user requirements. Without the, equitable comparison of gateways would not be possible. Page 7-1

This page intentionally left blank. Page 7-2

Appendix A: References APPENDIX A: REFERENCES The following documents were the sources for the technical details in this report. (a) (b) (c) (d) (e) (f) (g) Lutz, R. R., Drake, D. L., Bergin, D., Cutts, D., Lessmann, K., and O Connor, M. Live-Virtual-Constructive Architecture Roadmap Implementation: Common Gateways and Bridges Characterization Report, The Johns Hopkins University Applied Physics Laboratory (JHU/APL), May 2010. Lutz, R. R., Drake, D. L., Bergin, D., Cutts, D., Lessmann, K., and O Connor, M. Live-Virtual-Constructive Architecture Roadmap Implementation: Common Gateways and Bridges Execution Plan, JHU/APL, June 2010. Richbourg, R. and Lutz, R. R. Live Virtual Constructive Architecture Roadmap (LVCAR) Comparative Analysis of the Architectures, Alexandria, VA: Institute for Defense Analyses, September 2008. Simulation Interoperability Standards Committee. Standard for Modeling and Simulation High Level Architecture - Framework and Rules, Institute of Electrical & Electronics Engineers, Inc. (IEEE) Std IEEE1516-2000. HLA Working Group, December 11, 2000. Simulation Interoperability Standards Committee. Standard for Modeling and Simulation High Level Architecture - Federate Interface Specification, IEEE Std IEEE1516.1-2000. HLA Working Group, March 9, 2001. Simulation Interoperability Standards Committee. Standard for Modeling and Simulation High Level Architecture - Object Model Template Specification, IEEE Std IEEE1516.2-2000. HLA Working Group, March 9, 2001. TENA Software Development Activity. TENA: The Test and Training Enabling Architecture - Architecture Reference Document, Version 2005, February 2005. (h) CTIA-ID-0128, CTIA DoD Architecture Framework Documentation Version 1.3. Orlando, Lockheed Martin Simulation, Training and Support, July 2008. Page A-1

Appendix A: References This page intentionally left blank. Page A-2

Appendix B: Gateway-Related Glossary of Terms APPENDIX B: GATEWAY-RELATED GLOSSARY OF TERMS The following terms were defined in this document based upon the gateway characteristics presented. These terms are provided in this appendix to simplify retrieval and look-up. Term Definition Example Simulation Data Exchange Model (SDEM) The set of data exchanged during the execution of a federation. RPR FOM, MATREX FOM, and TENA Standard Object Model Architecture The mechanism to transfer data DIS, HLA, TENA, CTIA SDEM Translations SDEM Behaviors Functional Capabilities Categories Architecture Translations between simulations. The set of capabilities to convert data from one SDEM to another SDEM. This includes unit conversion, coordinate conversion, and enumeration mapping. This may require translating data stored in a single object in one SDEM to multiple objects in another SDEM. The capability to correctly represent behaviors required by the SDEM. This may include representing a behavior in one SDEM that is present in the other SDEM. SDEM behaviors may require the gateway to maintain state. Functional capabilities represent actions required by the gateway to meet SDEM, Architecture, or exercise management needs. The set of capabilities to convert architecture-defined data between different architecture executions. This covers translation of data that is not defined in the SDEM, but is present in all architecture executions. Unit conversion on a single attribute, singleelement enumeration to a multi-element enumeration. Dead-reckoning of positional attributes. SDEM Translations, SDEM Behaviors Object identifiers, timestamps Page B-1

Appendix B: Gateway-Related Glossary of Terms Term Definition Example The set of capabilities to perform actions required by the architecture. These behaviors are required by the architecture and apply to all SDEMs using the architecture. Architecture Behaviors Exercise Management Behaviors User Interface Performance Operation Modes The set of capabilities that are not directly related to the SDEM or architecture. These capabilities are used to meet objectives of the overall exercise independent of the SDEM or architecture. These capabilities may not involve the translation of data or behaviors. The set of capabilities that allow the user to interact with the operation of the gateway during pre-exercise, exercise, and postexercise activities. This category includes display of runtime information to the user. The set of performance metrics that is relevant for gateway users. There are no correct or better values for these capabilities. The values are based on the needs of the federation using the gateway. The set of possible operation modes for a gateway. A gateway may be able to operate in one or more modes. The modes are based on the ability of the gateway to perform translations between SDEMs and Architectures. Requests to publish attributes of a specified object Filtering for bandwidth Runtime view of translated objects Translated attributes per second Translation between SDEMs on a single architecture Page B-2

Extension Modes LVCAR Implementation Project: Common Gateways and Bridges Appendix B: Gateway-Related Glossary of Terms Term Definition Example The set of possible modes in which All hand-coded a gateway can be extended to translations support SDEMs and Architectures. A gateway may support more than one extension mode. Some gateways may be limited and only support a predetermined set of SDEM/architecture combinations Architecture combinations. Operational Capabilities Categories Platform Documentation/ Support Maturity Operational capabilities describe features of the gateway not directly related to translation. The set of hardware and software configurations to support the gateway. Some gateways may have multiple variable configurations. The different types of support available from the gateway developer, configuration manager, or sponsor. The different levels of software maturity and use of the gateway. Operation Modes, Extension Modes Supported operating systems Level of user documentation Number of user organizations Page B-3

Appendix B: Gateway-Related Glossary of Terms This page intentionally left blank. Page B-4

Appendix C: Abbreviations and Acronyms APPENDIX C: ABBREVIATIONS AND ACRONYMS API COTS CTIA CY DIS DoD FOM GCC GDL GML GOTS GUI HLA HLT ID IEEE JCOM JHU/APL LROM LVC LVCAR M&S M&S CO MATREX OM PDU Application Programming Interface Commercial Off-The-Shelf Common Training Instrumentation Architecture Calendar Year Distributed Interactive Simulation Department of Defense Federation Object Model Geocentric Gateway Description Language Gateway Mapping Language Government Off-the-Shelf Graphical User Interface High Level Architecture High Level Task Identification Institute of Electrical & Electronics Engineers, Inc. Joint Composable Object Model The Johns Hopkins University Applied Physics Laboratory Logical Range Object Model Live-Virtual-Constructive Live-Virtual-Constructive Architecture Roadmap Modeling and Simulation Modeling and Simulation Coordination Office Modeling Architecture for Technology, Research, and Experimentation Object Model Protocol Data Unit Page C-1

Appendix C: Abbreviations and Acronyms RMI RPC RPR RTI SDEM SDK SDO T&E TENA US Remote Method Invocation Remote Procedure Call Realtime Platform Reference Run Time Infrastructure Simulation Data Exchange Model Software Development Kit Stateful Distributed Object Test and Evaluation Test and Training Enabling Architecture United States Page C-2

NATIONAL SECURITY ANALYSIS DEPARTMENT THE JOHNS HOPKINS UNIVERSITY APPLIED PHYSICS LABORATORY Johns Hopkins Road, Laurel, MD 20723 6099