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

(1)

JHS01

NSAD-R-2010-100

Live-Virtual-Constructive

Architecture Roadmap

Implementation Project:

Common Gateways and

Bridges Task

Gateways Capabilities List

November 2010

(2)

(3)

NSAD-R-2010-100

Live-Virtual-Constructive

Architecture Roadmap

Implementation Project:

Common Gateways and

Bridges Task

Gateways Capabilities List

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

(4)

(5)

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 Gateways Capabilities List ... 3-1 3.2 Advancement of the Gateways Characteristics Matrix ... 3-1 3.3 Gateways Capabilities List 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 Gateways Capabilities List ... 6-1 6.2 Gateways Capabilities List for the End User ... 6-1 6.3 Gateways Capabilities List 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

(6)

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

(7)

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 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)]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 Gateways Capabilities List 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

(8)

The Gateways Capabilities List 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 Gateways Capabilities List and the performance benchmarks are the foundation for a community standard for gateway description and assessment. The Gateways Capabilities List 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 Gateways Capabilities List based on user requirements. Without the Gateways Capabilities List, equitable comparison of gateways would not be possible.

(9)

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

(10)

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

(11)

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.

(12)

(13)

3. PROJECT APPROACH

This section addresses the steps in the Common Gateways and Bridges project that led to the development of a Gateways Capabilities List and how the project migrated from a Gateways Characteristics document to the development of the Gateways Capabilities List.

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 commonly-employed 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.

(14)

The first hurdle is addressed utilizing the Gateways Capabilities List 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 Gateways Capabilities List 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.”

(15)

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 single-element enumeration to a multi-single-element enumeration.

Table 4-1: Functional Capabilities - SDEM Translations

Functional Capabilities SDEM Translations Reference

ID Capability Definition Examples ImplementationLevels of FC-ST-1 Capability to perform

unit conversion on a single attribute (SDEM element).

For example, if a 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

(16)

Table 4-1: Functional Capabilities - SDEM Translations (continued)

ID Capability Definition Examples ImplementationLevels of 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. For example, if a 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.

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 FC-ST-3 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.

For example, if a gateway can translate from Entity Health Status enumeration (healthy, sick, dead) to a different enumeration (mobility, firepower, total kill). 0 = No single enumeration mapping 1 = One-to-one enumeration mapping 3 = Many-to-one enumeration mapping 5 = Arbitrary enumeration mapping FC-ST-4 Capability to translate multi-component enumerations between SDEMs. For example, if a gateway can translate between a Distributed Interactive Simulation (DIS) seven-element entity-kind enumeration to a Modeling Architecture for Technology, Research, and Experimentation (MATREX) single-element entity-kind enumeration. 0 = No multi-component enumeration mapping 1 = 1 type of multi-component enumeration mapping 3 = 5 types of multi-component enumeration mapping 5 = Arbitrary multi-component enumeration mapping

(17)

Table 4-1: Functional Capabilities - SDEM Translations (continued)

ID Capability Definition Examples ImplementationLevels of FC-ST-5 Capability to

translate identifiers between SDEMs.

For example, if a gateway can translate between a DIS three-element 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.

0 = No translation of SDEM identifiers 1 = 1 specific translation 3 = 5 specific translations 5 = Ability to provide an arbitrary number of identifier translations FC-ST-6 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

For example, if a 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.

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 FC-ST-7 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.

For example, if a 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 dynamic information 1 = 1 defined dynamic translation 3 = 15 defined dynamic translations 5 = Arbitrary ability to add dynamic information

(18)

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 ImplementationLevels of FC-SB-1 Capability to provide

dead-reckoning between SDEMs that use different dead-reckoning

mechanisms.

For example, if a gateway can translate between one SDEM that uses the DIS-defined dead-reckoning

algorithms and another SDEM that uses a different set of dead-reckoning algorithms. Another example is where both SDEMs use DIS dead-reckoning schemes but use different algorithms.

0 = No dead-reckoning support

1 = Map between different DIS dead-reckoning

algorithms (up to 4) 3 = Map between all

DIS dead-reckoning algorithms 5 = Ability to map between arbitrary dead-reckoning algorithms FC-SB-2 Capability to provide dead-reckoning when required by one SDEM and not the other.

For example, if a 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 support for emulating dead-reckoning

3 = Provides support for emulating DIS dead-reckoning

algorithms

5 = Provides support for emulating arbitrary dead-reckoning algorithms

(19)

Table 4-2: Functional Capabilities - SDEM Behaviors (continued)

Functional Capabilities SDEM Behaviors Reference

ID Capability Definition Examples ImplementationLevels of FC-SB-3 Capability to publish

attributes based on updates exceeding thresholds.

This does not include thresholds associated with dead-reckoning, which is covered in FC-SB-1.

For example, if a 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. 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 FC-SB-4 Capability to support behaviors defined in one SDEM but not in the other.

For example, if a gateway could properly translate behaviors of the SDEM such as collision detection, damage assessment, radio communications degradation, or mobility. 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 FC-SB-5 Capability to support differing SDEM defined publication rates.

This does not include dead-reckoning or thresholding, which is covered in FC-SB-1.

For example, if a gateway could properly translate two different SDEMs that require higher or lower publication rates at which certain objects or attributes have to be updated. 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.

(20)

Table 4-3: Functional Capabilities - Architectural Translations

Functional Capabilities Architectural Translations Reference

ID Capability Definition Examples Levels of Implementation FC-AT-1 Capability to translate

identifiers between Architectures. For example, if a 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 ImplementationLevels of FC-AB-1 Capability to support architecture-defined publication rates. For example, if a 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

(21)

Table 4-4: Functional Capabilities - Architectural Behaviors (continued)

ID Capability Definition Examples ImplementationLevels of 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. For example, if a gateway can receive a partial update of an HLA object and

correctly translate it to a completely filled out DIS Protocol Data Unit (PDU).

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

FC-AB-3 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.

For example, a gateway receives a DIS PDU where only one element has changed and

updates the only changed attribute in HLA.

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 FC-AB-4 Capability to support responding to publication requests. For example, if a 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 respond to publication requests 5 = Can respond to publication requests

(22)

ID Capability Definition Examples ImplementationLevels of FC-AB-5 Capability to translate Remote Procedure Calls (RPCs) between architectures that support RPCs. For example, if a gateway correctly translates between two or more architectures that support some form of RPCs but not in the same manner.

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 FC-AB-6 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.

For example, if a gateway can convert a TENA Remote Method Invocation (RMI) to an HLA/Federation Object Model (FOM) specific interaction. 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 FC-AB-7 Capability to translate RPCs from an architecture that does not support RPCs to one that does.

For example, if a

gateway can support an HLA/FOM specific interaction to a TENA RMI. 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

(23)

ID Capability Definition Examples ImplementationLevels of FC-AB-8 Capability to

remove translated objects based on the rules of the original publisher architecture.

For example, if a 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.

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

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

ID Capability Definition Examples Levels of implementation 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

(24)

Table 4-5: Functional Capabilities - Exercise Management Behaviors (continued)

Functional Capabilities Exercise Management Behaviors Reference

ID Capability Definition Examples Levels of Implementation FC-EMB-2 Capability to filter

(i.e., not translate) specified objects between SDEMs based on their attributes or classes For example, a gateway that

supports filtering out all air platforms from being passed from one SDEM to another SDEM.

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

FC-EMB-3 Capability to filter updates from specified senders (i.e., simulations)

For example, a gateway with the ability to filter any updates published by a specific

sender/simulation.

0 = No ability to filter based on sender

3 = Can only filter all classes from sender

5 = Can filter selected classes from sender

FC-EMB-4 Capability to filter updates based on conditions or events

For example, a gateway that supports proximity filtering to ignore air platforms outside of a sensor's range.

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.

(25)

Table 4-6: Functional Capabilities – Fault Tolerance Behavior

Functional Capabilities Fault Tolerance Behavior Reference

ID Capability Definition Examples Levels of Implementation FC-FTB-1 Capability to handle invalid data in SDEM fields that is required for translation or conversion. For example, if a 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).

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 FC-FTB-2 Capability to handle missing SDEM data that is required for translation or conversion. For example, if a

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.

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 FC-FTB-3 Capability to handle invalid SDEM-defined identifiers. This includes duplicate identifiers or identifiers that do not exist. For example, if a 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.

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

(26)

Table 4-6: Functional Capabilities - Fault ToleranceBehaviors (continued)

Functional Capabilities Fault Tolerance Behaviors Reference

ID Capability Definition Examples Levels of Implementation FC-FTB-4 Capability to handle invalid architecture-defined identifiers; this includes duplicate identifiers or identifiers that do not exist. For example, if a gateway does not crash even though it

translates an HLA or TENA SDEM where an object references

another object by its architecture-defined identifier, and the reference is to a nonexistent object.

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

FC-FTB-5 Capability to handle the result of a simulation incorrectly using an architecture-defined service. For example, if a 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.

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

FC-FTB-6 Capability to handle incomplete enumeration mapping tables. For example, if a gateway does not crash even though the

enumeration mapping provided it does not provide a map for all enumeration values in use.

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

FC-FTB-7 Capability to handle data overflow.

For example, if a gateway does not crash even though the rate of incoming data exceeds the ability of the gateway to process.

0 = No ability to correct for data rates in excess of capability 3 = Gateway takes action to

prevent crashing

5 = Gateway follows a user-defined behavior to take actions

(27)

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 ImplementationLevels of 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 parameters

OC-UI-2 Capability to guide the user in the setup of gateway via an interactive GUI.

For example, if a gateway configuration system has a wizard-like user interface that asks simple questions and then creates the

gateway’s configuration files.

0 = No guided setup GUI 3 = Guided setup GUI

for some options 5 = Full guided setup

(28)

Table 5-1: Operational Capabilities – User Interface (continued)

ID Capability Definition Examples ImplementationLevels of OC-UI-3 Capability to provide

translation statistics during runtime.

For example, if a gateway has the ability to display the number of entities being translated, or the number of translation failures or dropped messages. 0 = No translation statistics provided during runtime 3 = 5 translation statistics provided during runtime 5 = 10 or more translations statistics provided during runtime

OC-UI-4 Capability to display gateway status during runtime.

For example, if a gateway has the ability to display its memory utilization or its message queue sizes. 0 = no status provided during runtime 3 = 5 status indicators during runtime 5 = 10 or more status indicator during runtime

OC-UI-5 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.

For example, if a 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.

0 = No anomaly reporting during runtime 3 = Reports anomaly to the user 5= Reports anomaly to the user including error handling details

OC-UI-6 Capability to generate debug log and allow the user to specify its level of logging.

For example, if a gateway supports the generation of a log file of non-translatable objects.

0 = No debug log generated

3 = Debug log generated 5 = Debug log generated

with user-specified level of detail

OC-UI-7 Capability to allow a user to modify translation rules during runtime.

For example, if a

gateway allows a user to change filtering

preferences during runtime, such as the blocking of any data from a simulation. 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

(29)

Table 5-1: Operational Capabilities – User Interface (continued)

ID Capability Definition Examples ImplementationLevels of OC-UI-8 Capability to use

multiple gateway instances to partition and distribute the translation function.

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.

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

OC-UI-9 Capability to control one or more gateways during runtime remotely.

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.

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

OC-UI-10 Capability to remotely configure one or more gateways before runtime.

For example, if a gateway has the capability to push configuration files to multiple gateway instances before the start of the event.

0 = No ability to remotely configure the gateway 3 = Ability to remotely configure 5 gateway parameters 5 = Ability to remotely configure all gateway parameters

OC-UI-11 Capability to

remotely monitor one or more gateways during runtime.

For example, if a user can monitor the memory utilization of the

gateway from a remote location.

0 = No ability to

remotely monitor the gateway

3 = Ability to remotely monitor 5 gateway characteristics 5 = Ability to remotely

monitor all gateway characteristics

(30)

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 ImplementationLevels of OC-OM-1 Capability to translate

between two different SDEMs that are using the same architecture (two-sided gateway). For example, if a gateway translates between Realtime Platform Reference (RPR) FOM and MATREX FOM using HLA.

Yes/No

OC-OM-2 Capability to translate

between two different SDEMs that are using two different architectures (two-sided gateway).

For example, if a gateway translates between an HLA SDEM using the RPR FOM and TENA using the TENA Standard Object Model “TENA-Platform DIS-EntityType-v1.”

Yes/No

OC-OM-3 Capability to translate between three different SDEMs that are using up to three different architectures (3-sided gateway).

For example, if a gateway translates between DIS, an HLA SDEM using the RPR FOM, and TENA using TENA Standard

Logical Range Object Model (LROM).

Yes/No

OC-OM-4 Capability to translate between more than three different SDEMs that are using more than three different architectures (n-sided gateway).

For example, if a gateway translates between DIS, an HLA SDEM using the RPR FOM, TENA using TENA Standard LROM, and Common Training Instrumentation Architecture (CTIA).

(31)

Table 5-2: Operational Capabilities – Operation Modes (continued)

Operational Capabilities Operation Modes Reference

ID Capability Definition Examples ImplementationLevels of OC-OM-5 Capability to translate

between different versions of an architecture using the same SDEM. For example, if a 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.

For example, if a 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 ImplementationLevels of 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 source code.

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.

For example, if a 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.

(32)

Table 5-3: Operational Capabilities – Extension Modes (continued)

Operational Capabilities Extension Modes Reference

ID Capability Definition Examples ImplementationLevels of OC-EM-3 The gateway has its core

translations provided by the developer, and allows extensions that can be made via a developer-provided code generator.

For example, if a gateway developer provides a base set of translations, and the gateway developer also provides a code generator to the end user to extend the gateway’s capabilities.

Yes/No

OC-EM-4 The gateway has all its translations created by a developer-provided code generator.

For example, if a gateway developer provides a code-generator that the end user uses to configure the

required translation for the gateway.

Yes/No

OC-EM-5 The gateway allows a runtime translation to be performed using

interpreted mapping files.

For example, if a gateway interprets a mapping file to perform translations at run time.

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.

(33)

Table 5-4: Operational Capabilities – Support

Operational Capabilities Support Reference

ID Capability Definition Examples Levels of Implementation OC-S-1 Available

documentation for the

gateway

For example, if user manuals, training materials, podcasts, installation guides, release notes, and/or programming guides are provided as part of the acquisition of the gateway.

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

OC-S-2 Help Desk / Support available

For example, if a phone number is supplied to gateway users for a fee that gives normal business day support for bug fixes, usage questions, and troubleshooting.

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

OC-S-3 Feature request form or process

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.

0 = No feature request process 3 = Informal feature request

process

5 = Formal feature request process

OC-S-4 Problem report form or process

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.

0 = No problem report process 3 = Informal problem reporting 5 = Formal problem report

process

OC-S-5 Sustainment or

maintenance process

For example, the gateway was developed for a single use, and has no sustainment or maintenance process or plan. 0 = No sustainment or maintenance process 3 = Informal sustainment or maintenance process 5 = Formal sustainment or maintenance process

(34)

Table 5-4: Operational Capabilities – Support (continued)

Operational Capabilities Support Reference

ID Capability Definition Examples Levels of Implementation OC-S-6 Ownership

model For example, if the development of the gateway has been funded by the United States (US) government, making it a Government Off-The-Shelf (GOTS) product. Select:  GOTS  Commercial Off-The-Shelf (COTS)  Open Source  Mixed GOTS/COTS OC-S-7 Licensing

requirement For example, the end user may have to buy a license based on the number of simulation components that communicate to the gateway. Select:  No License required

 No-cost end user license required

 License required at a cost to the end user

OC-S-8 What

architectures are supported

For example, the gateway may support a DIS-to-HLA

communication.

Select all that apply:

 DIS

 HLA

 TENA

 CTIA

 Other

OC-S-9 List of SDEMs

supported For example, the gateway may support RPR FOM, TENA Standard Platform Object Model

Developer provides a list of SDEMs supported OC-S-10 Operating systems that are supported by the gateway For example: Windows, Linux, OS X, Solaris, VX Works, etc.

Developer provides a list of operating systems on which the gateway can operate

(35)

6. APPLICABILITY OF THE CAPABILITIES LIST

This section describes the value of the Gateways Capabilities List to the user. The Gateways Capabilities List 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 Gateways Capabilities List 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 Gateways Capabilities List and the performance benchmarks are the foundation for a community standard for gateway description and assessment. The Gateways Capabilities List 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 Gateways Capabilities List based on user requirements. Without the Gateways Capabilities List, equitable comparison of gateways would not be possible.

6.2 GATEWAYS CAPABILITIES LIST FOR THE END USER

The Gateways Capabilities List 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 Gateways Capabilities List 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.

(36)

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 Gateways Capabilities List. The Gateway Mapping Language uses Exercise Management Behaviors capabilities to define exercise specific parts of the language.

(37)

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 side-by-side comparisons of candidate gateways, which will lead to better, more informed selection decisions by user programs in the future.

The Gateways Capabilities List 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 Gateways Capabilities List and the performance benchmarks are the foundation for a community standard for gateway description and assessment. The Gateways Capabilities List 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 Gateways Capabilities List based on user requirements. Without the Gateways Capabilities List, equitable comparison of gateways would not be possible.

(38)

(39)

APPENDIX A: REFERENCES

The following documents were the sources for the technical details in this report.

(a) 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.

(b) 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.

(c) 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.

(d) 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.

(e) 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.

(f) 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.

(g) 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.

(40)

(41)

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

between simulations. DIS, HLA, TENA, CTIA SDEM

Translations 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.

Unit conversion on a single attribute, single-element enumeration to a multi-element

enumeration.

SDEM

Behaviors 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. Dead-reckoning of positional attributes. Functional Capabilities Categories

Functional capabilities represent actions required by the gateway to meet SDEM, Architecture, or exercise management needs.

SDEM Translations, SDEM Behaviors Architecture

Translations 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.

Object identifiers, timestamps

(42)

Architecture

Behaviors 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. Requests to publish attributes of a specified object Exercise Management Behaviors

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.

Filtering for bandwidth

User Interface The set of capabilities that allow 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.

Runtime view of translated objects

Performance 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.

Translated attributes per second

Operation

Modes 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.

Translation between SDEMs on a single architecture

(43)

Extension

Modes The set of possible modes in which a gateway can be extended to 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. All hand-coded translations Operational Capabilities Categories

Operational capabilities describe features of the gateway not directly related to translation.

Operation Modes, Extension Modes

Platform The set of hardware and software

configurations to support the

gateway. Some gateways may have multiple variable configurations.

Supported operating systems

Documentation/

Support The different types of support available from the gateway developer, configuration manager, or sponsor.

Level of user documentation

Maturity The different levels of software

(44)

(45)