SISO-STD DRAFT. Standard for Gateway Description Language. DD Month Version 0.7

Transcription

1 0 SISO-STD-0-00-DRAFT Standard for Gateway Description Language DD Month 0 Version 0. Prepared by: Gateway Description and Configuration Languages Product Development Group

2 0 Copyright 0 by the Simulation Interoperability Standards Organization, Inc. P.O. Box Orlando, FL -, USA All rights reserved. Permission is hereby granted for this document to be used for production of both commercial and noncommercial products. Removal of this copyright statement and claiming rights to this document is prohibited. In addition, permission is hereby granted for this document to be distributed in its original or modified format (e.g. as part of a database) provided that no charge is invoked for the provision. Modification only applies to format and does not apply to the content of this document. SISO Inc. Board of Directors P.O. Box Orlando, FL -, USA Copyright 0 SISO. All rights reserved. Page of

3 Revision History Version Section Date (MM/DD/YYYY) 0. All MM//DD/0 original Description Copyright 0 SISO. All rights reserved. Page of

4 Participants At the time this product was submitted to the Standards Activity Committee (SAC) for approval, the Gateway Description and Configuration Languages Product Development Group (PDG) had the following membership and was assigned the following SAC Technical Area Director: Jim Coolahan Dannie Cutts Lance Marrou Product Development Group Bob Lutz (Chair) Dannie Cutts (Vice-Chair) Kurt Lessmann (Vice-Chair) David Drake (Editor) Simone Youngblood (SAC Technical Area Director) The following individuals comprised the ballot group for this product. Member Name Member Name Member Name Ballot Group Angus (Thom) McLean Michael O Connor Felix Rodriguez..<continue with all the other Ballot Group member names and place all in alphabetical order> When the Standards Activity Committee approved this product on DD Month YYYY, it had the following membership: Grant Bailey Curt Blais Peggy Gravitz Kevin Gupton Standards Activity Committee Jeff Abbott (Chair) Marcy Stutzman (Vice Chair / Secretary) Jean-Louis Igarza Bob Lutz Lana McGlynn Thom McLean William Oates Simone Youngblood Copyright 0 SISO. All rights reserved. Page of

5 0 When the Executive Committee approved this product on DD Month YYYY, it had the following membership: Executive Committee Michael O Connor (Chair) James Coolahan (Vice Chair) Jane Bachman (Secretary) Jeff Abbott David Graham Roy Scrudder John Daly Paul Gustavson Robert Siegfried John Diem Shel Ocasio Eric Whittington Copyright 0 SISO. All rights reserved. Page of

6 0 Introduction This document defines a standard for describing the capabilities that gateways can potentially offer to user organizations. The Gateway Description Language (GDL) defines a machine-readable Extensible Markup Language (XML) schema that facilitates automated methods of mapping gateway user requirements to gateway products that can meet those requirements. GDL was originally developed in response to U.S. Department of Defense needs expressed in the Live-Virtual-Constructive Architecture Roadmap (LVCAR) effort. However, the GDL specification provided in this document provides a common language to address the broader, more general need in the international Modeling and Simulation (M&S) community to better link producers and consumers in the gateway marketplace. The data files associated with this SISO Standard may be downloaded from this URL: Copyright 0 SISO. All rights reserved. Page of

7 0 0 Table of Contents. Overview..... Scope..... Purpose..... Objectives..... Intended Audience.... References.... Definitions, Acronyms, and Abbreviations Definitions Acronyms and Abbreviations GDL Definition GDLDescription Section..... Capabilities Section..... PerformanceResults Section..... CapabilitiesDescription Schema..... UseCases Schema... Annex A Gateway Description Language Schema (Normative)... Annex B Gateway Description Language Instance Documents... Annex C Example of Gateway Description Language Document (Informative)... Annex D Bibliography (Informative)... Copyright 0 SISO. All rights reserved. Page of

8 Standard for Gateway Description Language. Overview Modeling and Simulation (M&S) is in wide use today within the international user community. While many M&S applications are standalone applications used in support of such areas as requirements development, concept exploration, and system design/development, the advent and increased maturity of technologies and standards for distributed simulation have led to much wider use of integrated live, virtual, and constructive (LVC) simulation environments in support of major Test and Evaluation (T&E) and training events. While most distributed simulation events apply a single underlying simulation architecture, such as Distributed Interactive Simulation (DIS), High Level Architecture (HLA), or Test and Training Enabling Architecture (TENA), sponsor requirements sometimes necessitate the selection of simulations whose external interfaces support different LVC architectures. This is what is known as a multi-architecture LVC environment. When more than one LVC architecture must be used in the same environment, interoperability problems are compounded by the architectural differences []. For instance, middleware incompatibilities, dissimilar metamodels for data exchange, and differences in the nature of the services that are provided by the architectures must all be reconciled for such environments to operate properly. A gateway is an intelligent translator designed to link simulation enclaves that use dissimilar architectures. A bridge is very similar to a gateway but links enclaves using the same underlying architecture such as two HLA federations. Gateways and bridges are ubiquitous in the LVC community today and continue to represent one of the most widely used means of addressing interoperability concerns in multi-architecture LVC environments. Just as there are multiple types of distributed simulation architectures, there are multiple types of gateways. Some gateways are general purpose and can be configured or programmatically extended to interface with not only different distributed simulation architectures, but also dissimilar metamodels. At the other extreme, some gateways are very specific in their capabilities with extreme limitations on the type of distributed simulation and metamodels with which they can interface. The other dimension of gateways is their capability to translate and filter metamodel communications [,,,, ]. This situation creates a need for a standard way to describe the capabilities of a gateway in a consistent manner. The Gateway Description Language (GDL) provides a common language for capturing both gateway user requirements and the capabilities that individual gateways can offer to users. Thus, GDL supports direct mappings between gateway requirements and capabilities, facilitating more informed user gateway selections. In addition to the translation capabilities defined by GDL, GDL also includes the specification of gateway performance requirements and capabilities. This is in recognition that some users will have low-latency requirements for their LVC environment, and thus, performance is a critical factor for gateway selection. This version of GDL addresses gateway translation capabilities and gateway performance. As additional experience is accumulated in the application of GDL in real applications, it is expected that modifications and extensions to the formal language will be necessary. Future revisions of this standard will be produced as needed to support the evolving needs of the gateway user community... Scope This specification defines the requirements for the GDL schema along with a detailed description of the formal language that addresses these requirements. The description includes graphical representations of GDL schema elements to illustrate the types of description capabilities supported. A full Extensible Markup Language (XML) schema for the GDL and an example are provided as annexes. This GDL applies to both gateways and bridges. Copyright 0 SISO. All rights reserved. Page of

9 Purpose The purpose of this Gateway Description Language specification is to specify a formal XML schema for identifying the capabilities that gateways can offer to users. GDL provides a common format and syntax for gateway developers to describe the capabilities of their products to potential users. Since GDL is machine-readable, users can search on these GDL descriptions to align their application requirements with the gateways that best suit their needs. It is believed that GDL, in conjunction with tools and repository capabilities that support GDL, will greatly streamline the process of gateway selection in future LVC events... Objectives The objective of GDL is to define a common mechanism for describing the capabilities of a gateway as well as the set of gateway requirements... Intended Audience The intended audience for this document includes: Exercise engineers who are not gateway experts can use this document to understand the kinds of capabilities a gateway may have and the scope of requirements that a user may request regarding the functional aspects of a gateway. Gateway developers can use this document to record the capabilities of a gateway in a machineand human-readable form and to describe each capability to other distributed simulation professionals. Resource developers can use this document to create tools to facilitate gateway selection, integration, and usage in support of LVC event planning, preparation, and execution.. References [] Live-Virtual-Constructive Architecture Roadmap (LVCAR) Final Report, Institute for Defense Analyses, September 00. [] Live-Virtual-Constructive Architecture Roadmap Implementation, Common Gateways and Bridges Task Gateways Capabilities Description, JHU/APL NSAD-R-00-00, November 00. [] Live-Virtual-Constructive Architecture Roadmap Implementation, Common Gateways and Bridges Task Gateway Performance Benchmarks, JHU/APL NSAD-R-0-0, January 0. [] Live-Virtual-Constructive Architecture Roadmap Implementation, Common Gateways and Bridges Gateways Configuration Model Report, JHU/APL NSAD-R-0-0, April 0. [] Live-Virtual-Constructive Architecture Roadmap Implementation, Common Gateways and Bridges Characterization Report, JHU/APL NSAD-R-00-0, May 00. [] Live-Virtual-Constructive Architecture Roadmap Implementation, SDEM Mapping Language (SML) Specification, JHU/APL NSAD-R-0-0, August 0. Copyright 0 SISO. All rights reserved. Page of

10 Definitions, Acronyms, and Abbreviations.. Definitions bridge: This refers to intelligent translators that link together enclaves of simulations that use the same underlying simulation architecture, such as a bridge between two existing HLA federations. Compare to gateway. filtering: This is the elimination of distributed simulation traffic from one Architecture/SDEM to another Architecture/SDEM, based on a criterion or criteria. Filtering is intended to reduce unneeded or unwanted communication between architectures. gateway: This is an integrated set of LVC resources that are employing the services of more than one architecture during a single execution, such as a gateway between simulations that use TENA as the external interface on one side of the translator and DIS on the other. Compare to bridge. multi-architecture LVC environment: This is a selection of LVC resources whose external interfaces support different architectures. Simulation Data Exchange Model (SDEM): This is a type of object model that provides a representation of persistent and transient objects shared during a distributed simulation execution... Acronyms and Abbreviations CRS Coordinate Reference System DIS Distributed Interactive Simulation DoD Department of Defense GCD Gateway Characterization Description (presented in reference []) GFL Gateway Filtering Language GML Geography Markup Language HLA High Level Architecture ID Identification JHU/APL The Johns Hopkins University Applied Physics Laboratory LVC Live-Virtual-Constructive M&S Modeling and Simulation SDEM Simulation Data Exchange Model T&E Test and Evaluation TENA Test and Training Enabling Architecture XML Extensible Markup Language. GDL Definition The requirements for GDL are as follows: A formal mechanism shall exist for efficient means to compare application requirements to gateway capabilities. A formal mechanism shall exist for an efficient, repeatable means to determine what gateways best meet the application requirements. The objective of GDL is to describe a common format, syntax, and content (i.e., language) for describing both gateway requirements and gateway capabilities. GDL addresses the first requirement (above) by facilitating a direct comparison of requirements to capabilities, removing the need for users to interpret (or guess) when the requirements and capability descriptions are not well aligned. Further efficiencies are achieved through the fact that GDL is machine-readable, allowing tools to be integrated into the gateway selection process for the first time. Copyright 0 SISO. All rights reserved. Page 0 of

11 As users execute the gateway selection process, several gateways may be discovered that meet all or most of the user requirements. The core differences among the candidate gateways may not be particularly obvious, and thus, user support is still needed to determine the best choice among multiple competing gateways. GDL addresses the second requirement by defining a standard description of all potential gateway translation capabilities (as defined in the Gateway Characterization Description [GCD] Report). Therefore, for the first time, gateway developers have a formal language (and supporting tools) for characterizing (and advertising) the capabilities of their products. As users access these GDL descriptions, side-by-side comparisons are now possible due to the common underlying capabilities template provided by GDL. While users can do these comparisons themselves, the machine-readable nature of GDL also allows for the development of automated gateway sorting/ranking algorithms to assist the user in identifying the gateways that best align with their defined requirements. These algorithms can be designed to be repeatable (i.e., no random factors) so that, if desired, the factors and calculations that drive the matching process can be reconstructed in future applications. Significant efficiencies and improvements to the quality of gateway selections are accordingly introduced by the proper application of GDL and supporting tools and repositories. GDL is implemented as an XML schema that allows users or developers to document their requirements or capabilities in a machine- and human-readable form. GDL is supported by two other schemas, CapabilitiesDefinition and UseCases. XML instantiations of these two schemas are required to create GDL documents. Future revisions to this specification will include the appropriate references for users to access these supporting XML files. The CapabilitiesDefinition schema allows for the machine-readable documentation of the GCD. This is the standard set of capabilities that a gateway may implement. The UseCases schema supports the documentation of use cases to support Gateways Performance Benchmarking. The GDL schema is composed of three sections: GDLDescription, Capabilities, and PerformanceResults. A GDL file has one GDLDescription section, one or more Capabilities section, and zero or more PerformanceResults sections... GDLDescription Section The GDLDescription section provides information on the creator of the GDL file and the purpose for which it was created. There are two types of creators: users and developers. A user is someone that needs a gateway to meet the needs of their federation. The user can specify the name of the federation and the purpose of the gateway. A developer can specify the name of the organization that controls the gateway, the gateway s name, and version number. The GDLDescription section also supports references. Each GDL depends on instantiations of the CapabilitiesDefinition schema and the UseCases schema. The references section allows the gateway user or developer to specify the names of the instantiations upon which they are basing their GDL file. The creator of the GDL file may also provide a link to an external reference for the GDL file... Capabilities Section The Capabilities section allows the users to specify their requirements or developers to document their capabilities. There is one entry for each capability either required by the user or provided by the developer. To support machine processing, an XML schema is used to document the capabilities that have been developed. This will be discussed in detail below. Each capability in the file is identified by a CapabilityID. This identifier is found in the XML file that instantiates the CapabilitiesDefinition schema. Each capability has an implementation level that is numeric (0-), yes/no, or text. The implementation level entered by gateway users specifies their requirement for the level that is numeric (0-), yes/no, or text. The implementation level entered by gateway developers specifies the level at which their gateway implements the capability. Users may also specify a priority level that is an enumerated value of either Low, Medium, or High indicating how important this capability is to them. This is used by tools that determine the best fit of user requirements to developer-provided capabilities. The final field is a Copyright 0 SISO. All rights reserved. Page of

12 0 0 0 comment. Both users and developers can exercise this field to provide additional information on their requirements or capabilities... PerformanceResults Section The PerformanceResults section provides information on the performance metrics for each use case the user is interested in, or for which the developer produced data. Each PerformanceResults has an identifier for the use case that is found in the XML file instantiation of the UseCases schema. The next two fields are the metrics based on the gateway s performance in the context of the specified use case. The user enters the desired performance, and the developer enters the measured performance. Gateway users may also assign a priority to the metric. Gateway users or developers may add a comment to the metric... CapabilitiesDescription Schema The CapabilitiesDescription schema is a machine-readable version of the GCD document. It contains all of the information provided in the document. The schema provides a field to specify the version of the GCD document used for GDL file creation. The schema allows for the specification of the primary and specific categories to which the capability belongs. The schema provides fields for the definition, example, and implementation levels. The implementation levels may be numeric (0-), yes/no, or text. If the capability is numeric, the definition for each level specified is provided. Some numeric levels do not have definitions. For text levels, the type of information required may be listed... UseCases Schema The UseCases schema provides a machine-readable version of the use cases specified in the Gateways Performance Benchmarks document. Each use case has a unique identifier and name. The use case also has a description. The actual definition of the use case is in the ScenarioParameters section of the schema. The parameters are Persistent Object Count, Transient Object Count, Update Rate, Traffic Pattern, Complexity of Translation, and Object Creation. Each of these is an enumeration. The schema defines the enumeration values for each parameter. An XML instantiation of the UseCases schema is needed to match the parameters specified in the Gateways Performance Benchmarks document. However, users desiring developers to perform custom benchmark testing may use the UseCases schema to document their needs. Copyright 0 SISO. All rights reserved. Page of

13 Annex A Gateway Description Language Schema (Normative) The following structure defines the XML schema for Gateway Description Language (GDL). Readers should consult Section (GDL Definition) for descriptions of all GDL components. <?xml version=".0" encoding="utf-" standalone="no"?> <xs:schema xmlns:xs=" elementformdefault="qualified"> <xs:import namespace=" <xs:complextype name="gdl"> <xs:sequence> <xs:element ref="gdldescription"/> <xs:element ref="capability" maxoccurs="unbounded"/> <xs:element ref="performanceresults" minoccurs="0" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> <xs:element name="gdl" type="gdl"/> <xs:complextype name="gdldescription"> <xs:sequence> <xs:element ref="gdlcreator"/> <xs:element ref="gdltyperecord"/> <xs:element ref="references"/> <xs:element name="externalreference" type="xs:anyuri" minoccurs="0"/> </xs:sequence> </xs:complextype> <xs:complextype name="referencestype"> <xs:sequence> <xs:element name="capabilitiesfilename" type="xs:string"/> <xs:element name="usecasefilename" type="xs:string"/> </xs:sequence> </xs:complextype> <xs:element name="references" type="referencestype"/> <xs:element name="gdldescription" type="gdldescription"/> <xs:element name="gdlcreator" type="xs:string"/> <xs:complextype name="gdltyperecord"> <xs:choice> <xs:element ref="usertyperecord"/> <xs:element ref="developertyperecord"/> </xs:choice> </xs:complextype> <xs:element name="gdltyperecord" type="gdltyperecord"/> <xs:complextype name="usertyperecord"> <xs:sequence> <xs:element ref="federationname"/> <xs:element ref="gatewayuse" minoccurs="0"/> </xs:sequence> </xs:complextype> <xs:element name="usertyperecord" type="usertyperecord"/> <xs:element name="federationname" type="xs:string"/> <xs:element name="gatewayuse" type="xs:string"/> <xs:complextype name="developertyperecord"> <xs:sequence> <xs:element ref="developerorganization"/> <xs:element ref="gatewayname"/> <xs:element ref="gatewayversion"/> <xs:element name="productlink" type="xs:anyuri" minoccurs="0" maxoccurs=""/> Copyright 0 SISO. All rights reserved. Page of

14 </xs:sequence> </xs:complextype> <xs:element name="developertyperecord" type="developertyperecord"/> <xs:element name="developerorganization" type="xs:string"/> <xs:element name="gatewayname" type="xs:string"/> <xs:element name="gatewayversion" type="xs:string"/> <xs:element name="capabilityid" type="xs:string"/> <xs:complextype name="capability"> <xs:sequence> <xs:element ref="capabilityid"/> <xs:element ref="implementationleveltype"/> <xs:element ref="capabilityprioritylevel"/> <xs:element ref="capabilitycomment" minoccurs="0"/> </xs:sequence> </xs:complextype> <xs:element name="capabilitycomment" type="xs:string"/> <xs:element name="capability" type="capability"/> <xs:complextype name="implementationleveltype"> <xs:choice> <xs:element ref="numericimplementationlevel"/> <xs:element ref="yesnoimplementationlevel"/> <xs:element ref="textimplementationlevel"/> </xs:choice> </xs:complextype> <xs:element name="implementationleveltype" type="implementationleveltype"/> <xs:element name="yesnoimplementationlevel"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:enumeration value="yes"/> <xs:enumeration value="no"/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="textimplementationlevel" type="xs:string"/> <xs:element name="numericimplementationlevel"> <xs:simpletype> <xs:restriction base="xs:integer"> <xs:mininclusive value="0"/> <xs:maxinclusive value=""/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="capabilityprioritylevel" type="prioritytype" default="medium"/> <xs:simpletype name="prioritytype"> <xs:restriction base="xs:string"> <xs:enumeration value="low"/> <xs:enumeration value="medium"/> <xs:enumeration value="high"/> </xs:restriction> </xs:simpletype> <xs:complextype name="performanceresults"> <xs:sequence> <xs:element ref="usecaseid"/> <xs:element ref="latency"/> <xs:element ref="throughput"/> </xs:sequence> Copyright 0 SISO. All rights reserved. Page of

15 </xs:complextype> <xs:element name="performanceresults" type="performanceresults"/> <xs:element name="usecaseid" type="xs:string"/> <xs:complextype name="latencytype"> <xs:sequence> <xs:element name="latencyvalue" type="xs:double"/> <xs:element name="latencypriority" type="prioritytype" default="medium"/> <xs:element name="latencycomment" minoccurs="0"/> </xs:sequence> </xs:complextype> <xs:element name="latency" type="latencytype"/> <xs:element name="throughput" type="throughputtype"/> <xs:complextype name="throughputtype"> <xs:sequence> <xs:element name="throughputvalue" type="xs:double"/> <xs:element name="throughputpriority" type="prioritytype" default="medium"/> <xs:element name="throughputcomment" minoccurs="0"/> </xs:sequence> </xs:complextype> </xs:schema> <?xml version=".0" encoding="utf-" standalone="no"?> xs:schema xmlns:xs=" elementformdefault="qualified"> <xs:import namespace=" <xs:complextype name="capabilitiesdefinition"> <xs:sequence> <xs:element name="version" type="xs:string"/> <xs:element ref="capability" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> <xs:element name="capabilitiesdefinition" type="capabilitiesdefinition"/> <xs:complextype name="version" mixed="true"/> <xs:element name="version" type="version"/> <xs:complextype name="capabilitytype"> <xs:sequence> <xs:element ref="referenceid"/> <xs:element ref="category"/> <xs:element ref="capabilitydefinition"/> <xs:element ref="example"/> <xs:element ref="implementationlevels"/> </xs:sequence> </xs:complextype> <xs:element name="capability" type="capabilitytype"/> <xs:complextype name="categorytype"> <xs:choice> <xs:element ref="functional"/> <xs:element ref="operational"/> </xs:choice> </xs:complextype> <xs:element name="category" type="categorytype"/> <xs:complextype name="implementationlevelstype"> <xs:choice> <xs:element ref="numericalimplementationlevel"/> <xs:element ref="yesnoimplementationlevel"/> <xs:element ref="textimplementationlevel"/> </xs:choice> Copyright 0 SISO. All rights reserved. Page of

16 </xs:complextype> <xs:element name="implementationlevels" type="implementationlevelstype"/> <xs:complextype name="yesnoimplementationlevel"/> <xs:element name="yesnoimplementationlevel" type="yesnoimplementationlevel"/> <xs:element name="textimplementationlevel" type="xs:string"/> <xs:complextype name="numericalimplementationleveltype"> <xs:sequence> <xs:element ref="level0"/> <xs:element ref="level"/> <xs:element ref="level"/> <xs:element ref="level"/> <xs:element ref="level"/> <xs:element ref="level"/> </xs:sequence> </xs:complextype> <xs:element name="numericalimplementationlevel" type="numericalimplementationleveltype"/> <xs:element name="functional"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:enumeration value="sdem Translations"/> <xs:enumeration value="sdem Behaviors"/> <xs:enumeration value="architectural Translations"/> <xs:enumeration value="architectural Behaviors"/> <xs:enumeration value="exercise Management Behaviors"/> <xs:enumeration value="fault Tolerance Behaviors"/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="referenceid"/> <xs:element name="operational"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:enumeration value="user Interface"/> <xs:enumeration value="operation Modes"/> <xs:enumeration value="extension Modes"/> <xs:enumeration value="support"/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="numericimplementationlevel"/> <xs:element name="example" type="xs:string"/> <xs:element name="capabilitydefinition" type="xs:string"/> <xs:element name="level0" type="xs:string" default=""/> <xs:element name="level" type="xs:string" default=""/> <xs:element name="level" type="xs:string" default=""/> <xs:element name="level" type="xs:string" default=""/> <xs:element name="level" type="xs:string" default=""/> <xs:element name="level" type="xs:string" default=""/> </xs:schema> <?xml version=".0" encoding="utf-" standalone="no"?> <xs:schema xmlns:xs=" elementformdefault="qualified"> <xs:import namespace=" <xs:complextype name="usecases"> <xs:sequence> <xs:element ref="usecase" maxoccurs="unbounded"/> Copyright 0 SISO. All rights reserved. Page of

17 </xs:sequence> </xs:complextype> <xs:element name="usecases" type="usecases"/> <xs:complextype name="usecase"> <xs:sequence> <xs:element ref="usecaseid"/> <xs:element ref="usecasename"/> <xs:element ref="usecasedescription"/> <xs:element ref="scenarioparameters"/> </xs:sequence> </xs:complextype> <xs:element name="usecase" type="usecase"/> <xs:complextype name="scenarioparameterstype"> <xs:sequence> <xs:element ref="persistentobjectcount"/> <xs:element ref="transientobjectcount"/> <xs:element ref="updaterate"/> <xs:element ref="trafficpattern"/> <xs:element ref="complexityoftranslation"/> <xs:element ref="objectcreation"/> </xs:sequence> </xs:complextype> <xs:element name="scenarioparameters" type="scenarioparameterstype"/> <xs:element name="objectcreation"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:enumeration value="static"/> <xs:enumeration value="dynamic"/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="persistentobjectcount" type="lmhtype"/> <xs:element name="usecaseid" type="xs:string"/> <xs:element name="trafficpattern"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:enumeration value="continuous"/> <xs:enumeration value="burst Mode"/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="updaterate" type="lmhtype"/> <xs:element name="transientobjectcount" type="lmhtype"/> <xs:element name="usecasedescription" type="xs:string"/> <xs:element name="complexityoftranslation" type="lmhtype"/> <xs:element name="usecasename" type="xs:string"/> <xs:simpletype name="lmhtype"> <xs:restriction base="xs:string"> <xs:enumeration value="low"/> <xs:enumeration value="medium"/> <xs:enumeration value="high"/> <xs:enumeration value="veryhigh"/> <xs:enumeration value="extremelyhigh"/> </xs:restriction> </xs:simpletype> </xs:schema> Copyright 0 SISO. All rights reserved. Page of

18 Annex B Gateway Description Language Instance Documents In addition to the schemas, instance documents for use cases and capabilities were developed based on community input. Those instance documents are included here as they are critical to the creation of compatible Gateway Description Language (GDL) files. <UseCases xmlns:xsi= xsi:nonamespaceschemalocation="schemas/usecases.xsd"> <UseCase> <UseCaseID>Case </UseCaseID> <UseCaseName>Small Virtual Application</UseCaseName> <UseCaseDescription><![CDATA[Consists of translating between two federations with a low number of persistent and transient objects with a high update rate. The message traffic would be continuous. The complexity of the translations would be low, implying simple objects and minimal translations. No new persistent objects would be created or deleted during the execution. Profile might be characterized by a hardware-in-the-loop or a human-in-the-loop virtual simulator with small numbers of federates.]]></usecasedescription> <ScenarioParameters> <PersistentObjectCount>Low</PersistentObjectCount> <TransientObjectCount>Low</TransientObjectCount> <UpdateRate>High</UpdateRate> <TrafficPattern>Continuous</TrafficPattern> <ComplexityOfTranslation>Low</ComplexityOfTranslation> <ObjectCreation>Static</ObjectCreation> </ScenarioParameters> </UseCase> <UseCase> <UseCaseID>Case </UseCaseID> <UseCaseName>Small LVC Event</UseCaseName> <UseCaseDescription><![CDATA[Consists of a federation with a low number of persistent objects and a medium number of transient messages. The update rate would be very high with a continuous traffic pattern. The translations would be of medium complexity. No new objects would be created during the execution of the simulation and all objects would be deleted at the end of the execution cycle.]]></usecasedescription> <ScenarioParameters> <PersistentObjectCount>Medium</PersistentObjectCount> <TransientObjectCount>Medium</TransientObjectCount> <UpdateRate>VeryHigh</UpdateRate> <TrafficPattern>Continuous</TrafficPattern> <ComplexityOfTranslation>Medium</ComplexityOfTranslation> <ObjectCreation>Static</ObjectCreation> </ScenarioParameters> </UseCase> <UseCase> <UseCaseID>Case </UseCaseID> <UseCaseName>Medium LVC Event</UseCaseName> <UseCaseDescription><![CDATA[Consists of a medium number of persistent objects but a high number of transient messages. The update rate would be medium not exceeding hertz. The traffic patterns would be ÒburstyÓ (more than 0% above the average numbers). The simulation would have a great number of updates in a short time period, followed by a lull. The translation complexity would be medium (more than direct algorithmic translations). Objects will be created and destroyed dynamically during the execution.]]></usecasedescription> <ScenarioParameters> <PersistentObjectCount>Medium</PersistentObjectCount> <TransientObjectCount>High</TransientObjectCount> Copyright 0 SISO. All rights reserved. Page of

19 <UpdateRate>Medium</UpdateRate> <TrafficPattern>Burst Mode</TrafficPattern> <ComplexityOfTranslation>Medium</ComplexityOfTranslation> <ObjectCreation>Dynamic</ObjectCreation> </ScenarioParameters> </UseCase> <UseCase> <UseCaseID>Case </UseCaseID> <UseCaseName>Large Constructive Application</UseCaseName> <UseCaseDescription><![CDATA[Consists of a high number of persistent objects (greater than 0,000) and a medium number of transient messages (00 per second). The update rate would be low (0 persistent objects updated per second). The traffic pattern would be bursty. The translation complexity would be high. Objects will be created and destroyed dynamically during the execution.]]></usecasedescription> <ScenarioParameters> <PersistentObjectCount>High</PersistentObjectCount> <TransientObjectCount>Medium</TransientObjectCount> <UpdateRate>Low</UpdateRate> <TrafficPattern>Burst Mode</TrafficPattern> <ComplexityOfTranslation>High</ComplexityOfTranslation> <ObjectCreation>Dynamic</ObjectCreation> </ScenarioParameters> </UseCase> <UseCase> <UseCaseID>Case </UseCaseID> <UseCaseName>Large LVC Event</UseCaseName> <UseCaseDescription><![CDATA[Consists of a high number of persistent and transient objects with a medium update rates. Bursty traffic would be used. The required translation complexity would be high. No new objects will be created during the execution and all objects would be destroyed at the end of the execution.]]></usecasedescription> <ScenarioParameters> <PersistentObjectCount>High</PersistentObjectCount> <TransientObjectCount>High</TransientObjectCount> <UpdateRate>Medium</UpdateRate> <TrafficPattern>Burst Mode</TrafficPattern> <ComplexityOfTranslation>High</ComplexityOfTranslation> <ObjectCreation>Static</ObjectCreation> </ScenarioParameters> </UseCase> <UseCase> <UseCaseID>Case </UseCaseID> <UseCaseName>High Count Event</UseCaseName> <UseCaseDescription><![CDATA[Consists of a very high number of persistent and transient objects, medium update rate with bursty traffic patterns. Translation complexity would be medium with dynamic object creation and deletion. This is an Òextreme caseó beyond the normal large LVC event to address a hypothetical future application that gateways might be expected to support.]]></usecasedescription> <ScenarioParameters> <PersistentObjectCount>VeryHigh</PersistentObjectCount> <TransientObjectCount>VeryHigh</TransientObjectCount> <UpdateRate>Medium</UpdateRate> <TrafficPattern>Burst Mode</TrafficPattern> <ComplexityOfTranslation>Medium</ComplexityOfTranslation> <ObjectCreation>Dynamic</ObjectCreation> </ScenarioParameters> Copyright 0 SISO. All rights reserved. Page of

20 </UseCase> </UseCases> <?xml version=".0" encoding="utf-"?> <CapabilitiesDefinition xmlns:xsi=" xsi:nonamespaceschemalocation="schemas/capabilitiesdefinition.xsd"> <Version> 0. </Version> FC-ST- <Functional>SDEM Translations</Functional> 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. No Unit Conversion <Level> Single attribute conversion for or fewer defined types </Level> <Level> </Level> <Level> Single attribute conversion for fewer than fixed types </Level> <Level> </Level> <Level> Conversion between arbitrary units </Level> FC-ST- <Functional>SDEM Translations</Functional> 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 ( elements) to quaternions ( elements), or articulated parts versus Copyright 0 SISO. All rights reserved. Page 0 of

21 single frame reference. No multiple attribute conversion <Level> Multiple attribute conversion for or fewer fixed types </Level> <Level> </Level> <Level> Multiple attribute conversion for fewer than fixed types </Level> <Level> </Level> <Level> Arbitrary multiple attribute coordinate conversion </Level> FC-ST- <Functional>SDEM Translations</Functional> 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). No single enumeration mapping <Level> One-to-one enumeration mapping </Level> <Level> </Level> <Level> Many-to-one enumeration mapping </Level> <Level> </Level> <Level> Arbitrary enumeration mapping Copyright 0 SISO. All rights reserved. Page of

22 </Level> FC-ST- <Functional>SDEM Translations</Functional> 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. No multi-component enumeration mapping <Level> type of multi-component enumeration mapping </Level> <Level> </Level> <Level> types of multi-component enumeration mapping </Level> <Level> </Level> <Level> Arbitrary multi-component enumeration mapping </Level> FC-ST- <Functional>SDEM Translations</Functional> 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. Copyright 0 SISO. All rights reserved. Page of

23 No translation of SDEM identifiers <Level> Specific translation </Level> <Level> </Level> <Level> specific translations </Level> <Level> </Level> <Level> Ability to provide an arbitrary number of identifier translations </Level> FC-ST- <Functional>SDEM Translations</Functional> 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. No ability to add data <Level> Ability to add fixed type of data </Level> <Level> </Level> <Level> Ability to add fixed types of data </Level> <Level> </Level> <Level> Ability to add arbitrary data </Level> Copyright 0 SISO. All rights reserved. Page of

24 FC-ST- <Functional>SDEM Translations</Functional> 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. No ability to add dynamic information <Level> defined dynamic translation </Level> <Level> </Level> <Level> defined dynamic translations </Level> <Level> </Level> <Level> Arbitrary ability to add dynamic information </Level> FC-SB- <Functional>SDEM Behaviors</Functional> 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. Copyright 0 SISO. All rights reserved. Page of

25 No dead-reckoning support <Level> Map between different DIS dead-reckoning algorithms (up to ) </Level> <Level> </Level> <Level> Map between all DIS dead-reckoning algorithms </Level> <Level> </Level> <Level> Ability to map between arbitrary dead-reckoning algorithms </Level> FC-SB- <Functional>SDEM Behaviors</Functional> 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. No support for emulating dead-reckoning <Level> </Level> <Level> </Level> <Level> Provides support for emulating DIS dead-reckoning algorithms </Level> <Level> </Level> <Level> Provides support for emulating arbitrary dead-reckoning algorithms </Level> FC-SB- Copyright 0 SISO. All rights reserved. Page of

26 <Functional>SDEM Behaviors</Functional> Capability to publish attributes based on updates exceeding thresholds. This does not include thresholds associated with dead-reckoning, which is covered in FC-SB-. 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. No ability to publish attributes based on thresholds <Level> </Level> <Level> </Level> <Level> fixed thresholds to publish attributes </Level> <Level> </Level> <Level> Ability to publish attributes based on arbitrary thresholds </Level> FC-SB- <Functional>SDEM Behaviors</Functional> 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. No capability to support required SDEM behaviors <Level> Capability to support fixed behavior </Level> <Level> </Level> <Level> Copyright 0 SISO. All rights reserved. Page of

27 Capability to support fixed behaviors </Level> <Level> </Level> <Level> Ability to support an arbitrary number of behaviors </Level> FC-SB- <Functional>SDEM Behaviors</Functional> Capability to support differing SDEM defined publication rates. This does not include dead-reckoning or thresholding, which is covered in FC-SB-. 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. No support for SDEM publication rates <Level> Supported for fixed publication rate </Level> <Level> </Level> <Level> Supported for fixed publication rates </Level> <Level> </Level> <Level> Arbitrary SDEM publication rates </Level> FC-AT- <Functional>Architectural Translations</Functional> Capability to translate identifiers between Architectures. Copyright 0 SISO. All rights reserved. Page of

28 For example, if a gateway supports the mapping between an HLA Object Handle to a Test and Training Enabling Architecture (TENA) Unique Identification (ID). No ability to translate architecture ids <Level> Ability for scheme based on architectures/ implementations </Level> <Level> </Level> <Level> Ability for scheme based on architectures/ implementations </Level> <Level> </Level> <Level> Arbitrary identifier translation </Level> FC-AB- <Functional>Architectural Behaviors</Functional> 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. Cannot support architecture publication rates <Level> </Level> <Level> </Level> <Level> Can support fixed architecture publication rates </Level> <Level> </Level> <Level> Can support an arbitrary set of publication rates </Level> Copyright 0 SISO. All rights reserved. Page of

29 FC-AB- <Functional>Architectural Behaviors</Functional> 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). Cannot support publishing all attributes <Level> </Level> <Level> </Level> <Level> Can publish all attributes for selected object types </Level> <Level> </Level> <Level> Can publish all attributes based on partial attribute update </Level> FC-AB- <Functional>Architectural Behaviors</Functional> 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. Copyright 0 SISO. All rights reserved. Page of

30 Cannot publish only changed attributes <Level> </Level> <Level> </Level> <Level> Can publish only changed attributes for selected objects </Level> <Level> </Level> <Level> Can publish only changed attributes for an arbitrary number of objects </Level> FC-AB- <Functional>Architectural Behaviors</Functional> 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. Cannot respond to publication requests <Level> </Level> <Level> </Level> <Level> </Level> <Level> </Level> <Level> Can respond to publication requests </Level> FC-AB- Copyright 0 SISO. All rights reserved. Page 0 of

31 <Functional>Architectural Behaviors</Functional> 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. No support for RPCs when both architectures do not support <Level> </Level> <Level> </Level> <Level> Ability to translate selected RPCs </Level> <Level> </Level> <Level> Ability to translate an arbitrary number and type of RPCs </Level> FC-AB- <Functional>Architectural Behaviors</Functional> 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. No support for translating RPCs to a non-rpc architecture <Level> </Level> <Level> </Level> <Level> Ability to support translating selected RPCs to a non-rpc architecture Copyright 0 SISO. All rights reserved. Page of

32 </Level> <Level> </Level> <Level> Unrestricted ability to support translating RPCs to a non-rpc architecture </Level> FC-AB- <Functional>Architectural Behaviors</Functional> 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. No support for translating RPCs from an architecture that does not support RPCs to one that does <Level> </Level> <Level> </Level> <Level> Ability to support selected RPCs from an architecture that does not support RPCs to one that does </Level> <Level> </Level> <Level> Unrestricted ability to support translating RPCs from an architecture that does not support RPCs to one that does </Level> FC-AB- <Functional>Architectural Behaviors</Functional> 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 Copyright 0 SISO. All rights reserved. Page of

33 Object (SDO) pointer. No ability to remove objects based on original publisher's rules <Level> </Level> <Level> </Level> <Level> Ability to remove a limited set of object types based on </Level> <Level> </Level> <Level> Unrestricted ability to support removal rules </Level> FC-EMB- <Functional>Exercise Management Behaviors</Functional> 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. No support for exercise management rates <Level> Support for setting publication rates for type of object class </Level> <Level> </Level> <Level> Support for setting publication rates for object classes </Level> <Level> </Level> <Level> Unrestricted support for setting publication rates for object classes </Level> Copyright 0 SISO. All rights reserved. Page of

34 FC-EMB- <Functional>Exercise Management Behaviors</Functional> 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. No ability to filter <Level> Ability to filter based on class or attribute </Level> <Level> </Level> <Level> Ability to filter based on attributes or classes </Level> <Level> </Level> <Level> Unrestricted ability to filter objects based on their attributes or classes </Level> FC-EMB- <Functional>Exercise Management Behaviors</Functional> 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. No ability to filter based on sender <Level> </Level> Copyright 0 SISO. All rights reserved. Page of

35 <Level> </Level> <Level> Can only filter all classes from sender </Level> <Level> </Level> <Level> Can filter selected classes from sender </Level> FC-EMB- <Functional>Exercise Management Behaviors</Functional> 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. No ability to filter based on conditions or events <Level> Ability to filter based on fixed events or conditions </Level> <Level> </Level> <Level> Ability to filter based on fixed events or conditions </Level> <Level> </Level> <Level> Ability to filter on arbitrary conditions or events </Level> FC-FTB- <Functional>Fault Tolerance Behaviors</Functional> Capability to handle invalid data in SDEM fields that is required for translation or conversion. Copyright 0 SISO. All rights reserved. Page of

36 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). No ability to handle invalid data and the outcome is that the gateway crashes <Level> Can handle some invalid fields, but crashes on others </Level> <Level> </Level> <Level> Detects invalid data but does not translate update, and consequently does not crash </Level> <Level> </Level> <Level> Detects invalid data and translates update using user-specified data </Level> FC-FTB- <Functional>Fault Tolerance Behaviors</Functional> Capability to handle missing SDEM data that is required for translation or conversion. 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. No ability to handle missing data; gateway crashes <Level> Can handle some missing fields, but crashes on others </Level> <Level> </Level> <Level> Detects missing data and does not translate update; does not crash </Level> <Level> </Level> <Level> Copyright 0 SISO. All rights reserved. Page of

37 Detects missing data and translates update using user-specified data </Level> FC-FTB- <Functional>Fault Tolerance Behaviors</Functional> 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. No ability to handle invalid identifiers, and crashes <Level> Detects some invalid identifiers, but crashes on others </Level> <Level> </Level> <Level> Detects invalid identifier - does not translate update and does not crash </Level> <Level> </Level> <Level> Corrects the identifiers based on user-defined scheme and translates the update </Level> FC-FTB- <Functional>Fault Tolerance Behaviors</Functional> 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. Copyright 0 SISO. All rights reserved. Page of

38 No ability to handle invalid identifiers, and crashes <Level> Detects some invalid identifiers, but crashes on others </Level> <Level> </Level> <Level> Detects invalid identifier - does not translate update and does not crash </Level> <Level> </Level> <Level> Corrects the identifier and translates the update </Level> FC-FTB- <Functional>Fault Tolerance Behaviors</Functional> 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. No ability to handle and crashes <Level> </Level> <Level> </Level> <Level> Has the ability to handle some results of incorrect use of architecture services </Level> <Level> </Level> <Level> Handles and does not crash </Level> Copyright 0 SISO. All rights reserved. Page of

39 FC-FTB- <Functional>Fault Tolerance Behaviors</Functional> 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. No ability to handle incomplete enumeration mapping tables, and crashes if translating using such a table <Level> </Level> <Level> </Level> <Level> Does not translate, and does not crash </Level> <Level> </Level> <Level> Makes a user-defined translation and does not crash </Level> FC-FTB- <Functional>Fault Tolerance Behaviors</Functional> 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. No ability to correct for data rates in excess of capability <Level> </Level> Copyright 0 SISO. All rights reserved. Page of

40 <Level> </Level> <Level> Gateway takes action to prevent crashing </Level> <Level> </Level> <Level> Gateway follows a user-defined behavior to take actions </Level> OC-UI- <Operational>User Interface</Operational> 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. No GUI for configuration <Level> </Level> <Level> </Level> <Level> A GUI is provided for some configuration parameters </Level> <Level> </Level> <Level> A GUI is provided for all configuration parameters </Level> OC-UI- <Operational>User Interface</Operational> Capability to guide the user in the setup of gateway via an interactive GUI. Copyright 0 SISO. All rights reserved. Page 0 of

41 For example, if the user can define which objects are to be translated via a GUI. No guided setup GUI <Level> </Level> <Level> </Level> <Level> Guided setup GUI for some options </Level> <Level> </Level> <Level> Full guided setup GUI </Level> OC-UI- <Operational>User Interface</Operational> 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. No translation statistics provided during runtime <Level> </Level> <Level> </Level> <Level> translation statistics provided during runtime </Level> <Level> </Level> <Level> 0 or more translations statistics provided during runtime </Level> Copyright 0 SISO. All rights reserved. Page of

42 OC-UI- <Operational>User Interface</Operational> 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. no status provided during runtime <Level> </Level> <Level> </Level> <Level> status indicators during runtime </Level> <Level> </Level> <Level> 0 or more status indicator during runtime </Level> OC-UI- <Operational>User Interface</Operational> 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. No anomaly reporting during runtime Copyright 0 SISO. All rights reserved. Page of

43 <Level> </Level> <Level> </Level> <Level> Reports anomaly to the user </Level> <Level> </Level> <Level> Reports anomaly to the user including error handling details </Level> OC-UI- <Operational>User Interface</Operational> 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. No debug log generated <Level> </Level> <Level> </Level> <Level> Debug log generated </Level> <Level> </Level> <Level> Debug log generated with user-specified level of detail </Level> OC-UI- <Operational>User Interface</Operational> Copyright 0 SISO. All rights reserved. Page of

44 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. No ability to modify translation rules at runtime <Level> </Level> <Level> </Level> <Level> Ability to modify translation rules at runtime </Level> <Level> </Level> <Level> Ability to modify 0 or more translation rules at runtime </Level> OC-UI- <Operational>User Interface</Operational> 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. No capability to partition object class translations across gateway instances <Level> </Level> <Level> </Level> <Level> Ability to partition and distribute object class translations between gateway instances </Level> <Level> </Level> <Level> Ability to partition and distribute object class translations across more than gateway instances Copyright 0 SISO. All rights reserved. Page of

45 </Level> OC-UI- <Operational>User Interface</Operational> 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. No ability to remotely control the gateway <Level> Ability to remotely start and stop a gateway </Level> <Level> </Level> <Level> Ability to remotely control functions </Level> <Level> </Level> <Level> Ability to remotely control all gateway functions </Level> OC-UI-0 <Operational>User Interface</Operational> 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. Copyright 0 SISO. All rights reserved. Page of

46 No ability to remotely configure the gateway <Level> </Level> <Level> </Level> <Level> Ability to remotely configure gateway parameters </Level> <Level> </Level> <Level> Ability to remotely configure all gateway parameters </Level> OC-UI- <Operational>User Interface</Operational> 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. No ability to remotely monitor the gateway <Level> </Level> <Level> </Level> <Level> Ability to remotely monitor gateway characteristics </Level> <Level> </Level> <Level> Ability to remotely monitor all gateway characteristics </Level> OC-OM- <Operational>Operation Modes</Operational> Copyright 0 SISO. All rights reserved. Page of

47 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. <YesNoImplementationLevel/> OC-OM- <Operational>Operation Modes</Operational> 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 using the RPR FOM and TENA using the TENA Standard Object Model 'TENA-Platform DIS-EntityType-v.' <YesNoImplementationLevel/> OC-OM- <Operational>Operation Modes</Operational> Capability to translate between three different SDEMs that are using up to three different architectures (- sided gateway). For example, if a gateway translates between DIS, an HLA using the RPR FOM, and TENA using TENA Standard Logical Range Object Model(LROM). <YesNoImplementationLevel/> OC-OM- Copyright 0 SISO. All rights reserved. Page of

48 <Operational>Operation Modes</Operational> 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 using the RPR FOM, TENA using TENA Standard LROM, and Common Training Instrumentation Architecture (CTIA). <YesNoImplementationLevel/> OC-OM- <Operational>Operation Modes</Operational> Capability to translate between different versions of an architecture using the same SDEM. For example, if a gateway translates between TENA.. and TENA.0. <YesNoImplementationLevel/> OC-OM- <Operational>Operation Modes</Operational> 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. <YesNoImplementationLevel/> OC-EM- <Operational>Extension Modes</Operational> Copyright 0 SISO. All rights reserved. Page of

49 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. <YesNoImplementationLevel/> OC-EM- <Operational>Extension Modes</Operational> 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. <YesNoImplementationLevel/> OC-EM- <Operational>Extension Modes</Operational> 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. <YesNoImplementationLevel/> OC-EM- <Operational>Extension Modes</Operational> Copyright 0 SISO. All rights reserved. Page of

50 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. <YesNoImplementationLevel/> OC-EM- <Operational>Extension Modes</Operational> 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. <YesNoImplementationLevel/> OC-S- <Operational>Support</Operational> 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. No documentation <Level> Informal documentation (i.e., some slides or notes) </Level> <Level> </Level> <Level> formal documents (user manual, training package, or online help) </Level> <Level> </Level> Copyright 0 SISO. All rights reserved. Page 0 of

51 <Level> More than formal documents </Level> OC-S- <Operational>Support</Operational> 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. No Help Desk <Level> , but no funded support to answer questions </Level> <Level> </Level> <Level> -only response that is funded </Level> <Level> and telephone support manned during normal business hours </Level> <Level> Funded onsite support </Level> OC-S- <Operational>Support</Operational> 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 address of the development team. Copyright 0 SISO. All rights reserved. Page of

52 No feature request process <Level> </Level> <Level> </Level> <Level> Informal feature request process </Level> <Level> </Level> <Level> Formal feature request process </Level> OC-S- <Operational>Support</Operational> Problem report form or process For example, the gateway has an associated web page allowing users to request new features in an informal manner to an address of the development team. No problem report process <Level> </Level> <Level> </Level> <Level> Informal problem reporting </Level> <Level> </Level> <Level> Formal problem report process </Level> Copyright 0 SISO. All rights reserved. Page of

53 OC-S- <Operational>Support</Operational> Sustainment or maintenance process For example, the gateway was developed for a single use, and has no sustainment or maintenance process or plan. No sustainment or maintenance process <Level> </Level> <Level> </Level> <Level> Informal sustainment or maintenance process </Level> <Level> </Level> <Level> Formal sustainment or maintenance process </Level> OC-S- <Operational>Support</Operational> 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. <TextImplementationLevel> Select: * GOTS * Commercial Off-The-Shelf (COTS) * Open Source * Mixed GOTS/COTS </TextImplementationLevel> Copyright 0 SISO. All rights reserved. Page of

54 OC-S- <Operational>Support</Operational> 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. <TextImplementationLevel> Select: * No License required * No-cost end user license required * License required at a cost to the end user </TextImplementationLevel> OC-S- <Operational>Support</Operational> What architectures are supported For example, the gateway may support a DIS-to-HLA communication. <TextImplementationLevel> Select all that apply: * DIS * HLA * TENA * CTIA * Other </TextImplementationLevel> OC-S- <Operational>Support</Operational> List of SDEMs supported Copyright 0 SISO. All rights reserved. Page of

55 0 0 0 For example, the gateway may support RPR FOM, TENA Standard Platform Object Model <TextImplementationLevel> Developer provides a list of SDEMs supported </TextImplementationLevel> OC-S-0 <Operational>Support</Operational> Operating systems that are supported by the gateway For example: Windows, Linux, OS X, Solaris, VX Works, etc. <TextImplementationLevel> Developer provides a list of operating systems on which the gateway can operate </TextImplementationLevel> </CapabilitiesDefinition> Copyright 0 SISO. All rights reserved. Page of

56 Annex C Example of Gateway Description Language Document (Informative) The following XML text is a valid Gateway Description Language (GDL) document utilizing the schemas from Annex A and the instance documents from Annex B. <GDL> <GDLDescription> <GDLCreator>John Doe</GDLCreator> <GDLTypeRecord> <DeveloperTypeRecord> <DeveloperOrganization>Anonymous Org</DeveloperOrganization> <GatewayName>Generic Gateway</GatewayName> <GatewayVersion>..0</GatewayVersion> </DeveloperTypeRecord> </GDLTypeRecord> <References> <CapabilitiesFileName>Default</CapabilitiesFileName> <UseCaseFileName>Default</UseCaseFileName> </References> </GDLDescription> <CapabilityID>FC-AB-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to support architecture-defined publication rates.</capabilitycomment> <CapabilityID>FC-AB-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>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.</capabilitycomment> <CapabilityID>FC-AB-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>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.</capabilitycomment> <CapabilityID>FC-AB-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to support responding to publication requests.</capabilitycomment> <CapabilityID>FC-AB-</CapabilityID> Copyright 0 SISO. All rights reserved. Page of

57 <NumericImplementationLevel>0</NumericImplementationLevel> <CapabilityComment>Capability to translate Remote Procedure Calls (RPCs) between architectures that support RPCs.</CapabilityComment> <CapabilityID>FC-AB-</CapabilityID> <NumericImplementationLevel>0</NumericImplementationLevel> <CapabilityComment>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.</CapabilityComment> <CapabilityID>FC-AB-</CapabilityID> <NumericImplementationLevel>0</NumericImplementationLevel> <CapabilityComment>Capability to translate RPCs from an architecture that does not support RPCs to one that does.</capabilitycomment> <CapabilityID>FC-AB-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to remove translated objects based on the rules of the original publisher architecture.</capabilitycomment> <CapabilityID>FC-AT-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to translate identifiers between Architectures.</CapabilityComment> <CapabilityID>FC-EMB-</CapabilityID> <NumericImplementationLevel>0</NumericImplementationLevel> <CapabilityComment>Capability to set publication rates for object classes.</capabilitycomment> <CapabilityID>FC-EMB-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to filter (i.e., not translate) specified objects between SDEMs based on their attributes or classes.</capabilitycomment> <CapabilityID>FC-EMB-</CapabilityID> Copyright 0 SISO. All rights reserved. Page of

58 <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to filter updates from specified senders (i.e., simulations).</capabilitycomment> <CapabilityID>FC-EMB-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to filter updates based on conditions or events.</capabilitycomment> <CapabilityID>FC-FTB-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to handle invalid data in SDEM fields that is required for translation or conversion.</capabilitycomment> <CapabilityID>FC-FTB-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to handle missing SDEM data that is required for translation or conversion.</capabilitycomment> <CapabilityID>FC-FTB-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to handle invalid SDEM-defined identifiers. This includes duplicate identifiers or identifiers that do not exist.</capabilitycomment> <CapabilityID>FC-FTB-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to handle invalid architecture-defined identifiers; this includes duplicate identifiers or identifiers that do not exist.</capabilitycomment> <CapabilityID>FC-FTB-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to handle the result of a simulation incorrectly using an architecturedefined service.</capabilitycomment> <CapabilityID>FC-FTB-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> Copyright 0 SISO. All rights reserved. Page of

59 <CapabilityComment>Capability to handle incomplete enumeration mapping tables.</capabilitycomment> <CapabilityID>FC-FTB-</CapabilityID> <NumericImplementationLevel>0</NumericImplementationLevel> <CapabilityComment>Capability to handle data overflow.</capabilitycomment> <CapabilityID>FC-SB-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to provide dead-reckoning between SDEMs that use different deadreckoning mechanisms..</capabilitycomment> <CapabilityID>FC-SB-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to provide dead-reckoning when required by one SDEM and not the other.</capabilitycomment> <CapabilityID>FC-SB-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to publish attributes based on updates exceeding thresholds. This does not include thresholds associated with dead-reckoning, which is covered in FC-SB-.</CapabilityComment> <CapabilityID>FC-SB-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to support behaviors defined in one SDEM but not in the other.</capabilitycomment> <CapabilityID>FC-SB-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to support differing SDEM defined publication rates. This does not include dead-reckoning or thresholding, which is covered in FC-SB-.</CapabilityComment> <CapabilityID>FC-ST-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> Copyright 0 SISO. All rights reserved. Page of

60 <CapabilityComment>Capability to perform unit conversion on a single attribute (SDEM element).</capabilitycomment> <CapabilityID>FC-ST-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>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.</capabilitycomment> <CapabilityID>FC-ST-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>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.</CapabilityComment> <CapabilityID>FC-ST-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to translate multi-component enumerations between SDEMs.</CapabilityComment> <CapabilityID>FC-ST-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to translate identifiers between SDEMs.</CapabilityComment> <CapabilityID>FC-ST-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>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</capabilitycomment> <CapabilityID>FC-ST-</CapabilityID> <NumericImplementationLevel>0</NumericImplementationLevel> <CapabilityComment>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.</capabilitycomment> Copyright 0 SISO. All rights reserved. Page 0 of

61 <CapabilityID>OC-EM-</CapabilityID> <YesNoImplementationLevel>Yes</YesNoImplementationLevel> <CapabilityComment>The gateway has a single code base and is extended by modifying that code.</capabilitycomment> <CapabilityID>OC-EM-</CapabilityID> <YesNoImplementationLevel>Yes</YesNoImplementationLevel> <CapabilityComment>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) plugin.</capabilitycomment> <CapabilityID>OC-EM-</CapabilityID> <YesNoImplementationLevel>Yes</YesNoImplementationLevel> <CapabilityComment>The gateway has its core translations provided by the developer, and allows extensions that can be made via a developer-provided code generator.</capabilitycomment> <CapabilityID>OC-EM-</CapabilityID> <YesNoImplementationLevel>No</YesNoImplementationLevel> <CapabilityComment>The gateway has all its translations created by a developer-provided code generator.</capabilitycomment> <CapabilityID>OC-EM-</CapabilityID> <YesNoImplementationLevel>Yes</YesNoImplementationLevel> <CapabilityComment>The gateway allows a runtime translation to be performed using interpreted mapping files.</capabilitycomment> <CapabilityID>OC-OM-</CapabilityID> <YesNoImplementationLevel>Yes</YesNoImplementationLevel> <CapabilityComment>Capability to translate between two different SDEMs that are using the same architecture (two-sided gateway).</capabilitycomment> <CapabilityID>OC-OM-</CapabilityID> <YesNoImplementationLevel>Yes</YesNoImplementationLevel> <CapabilityComment>Capability to translate between two different SDEMs that are using two different architectures (two-sided gateway).</capabilitycomment> Copyright 0 SISO. All rights reserved. Page of

62 <CapabilityID>OC-OM-</CapabilityID> <YesNoImplementationLevel>Yes</YesNoImplementationLevel> <CapabilityComment>Capability to translate between three different SDEMs that are using up to three different architectures (-sided gateway).</capabilitycomment> <CapabilityID>OC-OM-</CapabilityID> <YesNoImplementationLevel>Yes</YesNoImplementationLevel> <CapabilityComment>Capability to translate between more than three different SDEMs that are using more than three different architectures (n-sided gateway).</capabilitycomment> <CapabilityID>OC-OM-</CapabilityID> <YesNoImplementationLevel>Yes</YesNoImplementationLevel> <CapabilityComment>Capability to translate between different versions of an architecture using the same SDEM.</CapabilityComment> <CapabilityID>OC-OM-</CapabilityID> <YesNoImplementationLevel>Yes</YesNoImplementationLevel> <CapabilityComment>Capability to translate between two different architectures using equivalent SDEMs.</CapabilityComment> <CapabilityID>OC-S-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Available documentation for the gateway</capabilitycomment> <CapabilityID>OC-S-0</CapabilityID> <TextImplementationLevel>Linux</TextImplementationLevel> <CapabilityComment>Operating systems that are supported by the gateway</capabilitycomment> <CapabilityID>OC-S-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Help Desk / Support available</capabilitycomment> <CapabilityID>OC-S-</CapabilityID> Copyright 0 SISO. All rights reserved. Page of

63 <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Feature request form or process</capabilitycomment> <CapabilityID>OC-S-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Problem report form or process</capabilitycomment> <CapabilityID>OC-S-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Sustainment or maintenance process</capabilitycomment> <CapabilityID>OC-S-</CapabilityID> <TextImplementationLevel>GOTS / Government Open Source</TextImplementationLevel> <CapabilityComment>Ownership model</capabilitycomment> <CapabilityID>OC-S-</CapabilityID> <TextImplementationLevel>No License Required</TextImplementationLevel> <CapabilityComment>Licensing requirement</capabilitycomment> <CapabilityID>OC-S-</CapabilityID> <TextImplementationLevel>DIS, HLA, TENA, CTIA, SISO J, SIMPLE, GCCS, VMF, KML, AIS</TextImplementationLevel> <CapabilityComment>What architectures are supported</capabilitycomment> <CapabilityID>OC-S-</CapabilityID> <TextImplementationLevel>NASMP (..0,...,..,..), NTF., LVC ERF (.0,.), JNTC (JLVC v.), TENA (v.. JNTC-00), DIS (v, v, v), CTIA (.0)</TextImplementationLevel> <CapabilityComment>List of SDEMs supported</capabilitycomment> <CapabilityID>OC-UI-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to configure the gateway via a Graphical User Interface (GUI).</CapabilityComment> Copyright 0 SISO. All rights reserved. Page of

64 <CapabilityID>OC-UI-0</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to remotely configure one or more gateways before runtime.</capabilitycomment> <CapabilityID>OC-UI-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to remotely monitor one or more gateways during runtime.</capabilitycomment> <CapabilityID>OC-UI-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to guide the user in the setup of gateway via an interactive GUI.</CapabilityComment> <CapabilityID>OC-UI-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to provide translation statistics during runtime.</capabilitycomment> <CapabilityID>OC-UI-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to guide the user in the setup of gateway via an interactive GUI.</CapabilityComment> <CapabilityID>OC-UI-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>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.</CapabilityComment> <CapabilityID>OC-UI-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to generate debug log and allow the user to specify its level of logging.</capabilitycomment> Copyright 0 SISO. All rights reserved. Page of

65 0 0 <CapabilityID>OC-UI-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to allow a user to modify translation rules during runtime.</capabilitycomment> <CapabilityID>OC-UI-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to use multiple gateway instances to partition and distribute the translation function.</capabilitycomment> <CapabilityID>OC-UI-</CapabilityID> <NumericImplementationLevel></NumericImplementationLevel> <CapabilityComment>Capability to control one or more gateways during runtime remotely.</capabilitycomment> </GDL> Copyright 0 SISO. All rights reserved. Page of

66 Annex D Bibliography (Informative) The following documents used for generating this standard. [D] The Open Geographic Information System Filter Encoding Standard ( Copyright 0 SISO. All rights reserved. Page of