Live, Virtual, Constructive Architecture Roadmap Implementation - - PowerPoint PPT Presentation

▶
live virtual constructive architecture roadmap
SMART_READER_LITE
LIVE PREVIEW

Live, Virtual, Constructive Architecture Roadmap Implementation - - PowerPoint PPT Presentation

Sep 17, 2023 158 likes •349 views

Live, Virtual, Constructive Architecture Roadmap Implementation (LVCAR-I) - Improved Interconnectivity Using Gateways/Bridges 2011 ITEA Test Instrumentation Workshop May 9-12, 2011 The Johns Hopkins University Applied Physics Laboratory

slide-1
SLIDE 1

The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road Laurel, MD USA 20723-6099

Live, Virtual, Constructive Architecture Roadmap Implementation (LVCAR-I) - Improved Interconnectivity Using Gateways/Bridges

2011 ITEA Test Instrumentation Workshop May 9-12, 2011

slide-2
SLIDE 2

LVCAR-I Drivers

2

Growing Demand for LVC Interoperability Redundancy of Tools, Gateways & Repositories Numerous, Parallel Architectures (HLA, DIS, CTIA, TENA)

slide-3
SLIDE 3

3

  • Purpose:

“Develop a future vision and supporting strategy for achieving significant interoperability improvements in LVC simulation environments.”

  • Focus:
  • Technical Architecture
  • Business Models
  • Standards Evolution
  • Management Process
  • Precepts:
  • Do no harm
  • Interoperability is not free
  • Start with small steps
  • Provide central management

LVCAR Study Framework

slide-4
SLIDE 4

4

Net-Centric SOA Concept Pilot Tool Set Design -

  • Common Data Formats
  • Reuse & Repositories
  • Gateways & Bridges
  • Common Object Models

(FY09-10 ) (FY11-13 ) (FY08) Standards - FEAT & DSEEP Overlay Engagement Activities with M&S COIs LVCAR Study Recommendations Implementation

&

Transition

LVCAR Progression

slide-5
SLIDE 5

Gateways Background

  • Simulation is a critical enabler for system acquisition programs,

providing vital capabilities for such functional disciplines as analysis, test, and training

  • The advent of modern networking technology and the

development of supporting protocols and architectures has led to widespread use of distributed simulation

  • Facilitates efficient use of existing M&S assets
  • The number of distributed simulation applications that include

multiple simulation architectures and Simulation Data Exchange Model (SDEM) representations are increasing

  • Gateways provide the most widely used means of addressing

interoperability concerns in multi-architecture LVC environments

5

slide-6
SLIDE 6

Gateway Challenges

  • Despite the many documented success stories associated with the use of

gateways to facilitate LVC interoperability, there are also some significant issues that impact technical, schedule, and cost risk

  • Examples of known gateway issues include:
  • No central “marketplace” of gateways
  • Few mechanisms for user to determine what reuse opportunities are available
  • No mechanisms for direct comparisons of gateways
  • Integrators committing to building their own
  • Gateways built for specific needs
  • Increased intellectual expenditure on ad hoc solutions
  • Not built for reuse/not built for extensibility
  • Extensive duplication of existing gateway capabilities
  • Broad proliferation of gateways
  • Redundant maintenance costs
  • Developer or integrator lock-in
  • Expensive to exchange/upgrade/replace gateways
  • Increased lifecycle costs

6

slide-7
SLIDE 7

Addressing Gateway Challenges

  • The Live-Virtual-Constructive Architecture Roadmap (LVCAR) was

established in the spring of 2007, continuing for approximately sixteen months

  • DoD-sponsored
  • Intended to examine the differences among the major simulation

architectures from a technical, business, and standards perspective, and to develop a time-phased set of actions to improve interoperability within multi-architecture simulation environments in the future

  • Resulted in a final report and supporting documentation that

collectively totaled over a thousand pages

  • The implementation of LVCAR recommendations began in the

spring of 2009

  • Organized into three areas: “Common Capabilities,” “Architecture

Convergence,” and “Gateways and Bridges”

  • Gateway issues (on previous chart) were identified based on

community outreach during LVCAR development

7

slide-8
SLIDE 8

LVCAR Gateways Effort – Block 1 Activities

  • The Gateways component to the LVCAR Implementation

(LVCAR-I) project initially focused on two products:

  • Gateways Characterization Report
  • Designed to identify areas where gateway capabilities are not well

aligned with user needs

  • Identified capabilities offered by a wide range of different existing

gateways, based on on-line questionnaires and site visits to numerous user sites

  • Mapped user requirements to these capabilities to identify gaps
  • Final report delivered to the Modeling and Simulation Coordination

Office (MSCO) sponsor in May 2010

  • Gateways Execution Plan
  • Identification of viable strategies to address gateway issues and

capability gaps

  • Final report delivered to the MSCO sponsor in June 2010

8

slide-9
SLIDE 9

Strategy Dimensions

Looking for the “sweet spot” that addresses the issues in a timely fashion, for reasonable cost, enacts positive change that is long- lasting, and has a credible business model

9

E d u c a t e Enhance Create

  • Tutorials
  • Classes
  • Help Desk
  • Machine-readable gateway

languages

  • Architecture-neutral SDEM

representation

  • Performance Benchmarks
  • Fund existing & enhance
  • Fund new
  • New business models

Current State

E d u c a t e Enhance Create

  • Tutorials
  • Classes
  • Help Desk
  • Machine-readable gateway

languages

  • Architecture-neutral SDEM

representation

  • Performance Benchmarks
  • Fund existing & enhance
  • Fund new
  • New business models

Current State

slide-10
SLIDE 10

LVCAR Gateways Effort – Block 2 Activities

  • Develop a Gateways Capability Description document, which

formally delineates the various capabilities that individual gateways can offer to user programs, along with specific levels

  • f implementation for each unique capability
  • Assess the Architecture-Neutral Data Exchange Model (ANDEM),

developed by the Joint Composable Object Model (JCOM) Program, to support Simulation Data Exchange Model (SDEM) mapping and/or translation in gateways

  • Develop a set of Gateway Performance Benchmarks (GPBs) to

identify specific gateway performance measures, along with use cases that describe how and where these measures should be applied

10

slide-11
SLIDE 11

Gateways Capability Description - Example

11

Functional Capabilities SDEM Translations Reference ID Capability Definition Examples Levels of Implementation FC-ST-1 Capability to perform unit conversion on a single attribute (SDEM element). 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 less defined types 3 = Single attribute conversion for less than 15 fixed types 5 = Conversion between arbitrary units 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 number of components. For example, if a gateway can translate between coordinate systems with different number of components, such as Euler angles (3 elements) to quaternions (4 elements),

  • r articulated parts verses

single frame reference. 0 = No multiple attribute conversion 1 = Multiple attribute conversion for 5 or less fixed types 3 = Multiple attribute conversion for less than 15 fixed types 5 = Arbitrary multiple attribute coordinate conversion Functional Capabilities SDEM Translations Reference ID Capability Definition Examples Levels of Implementation FC-ST-1 Capability to perform unit conversion on a single attribute (SDEM element). 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 less defined types 3 = Single attribute conversion for less than 15 fixed types 5 = Conversion between arbitrary units 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 number of components. For example, if a gateway can translate between coordinate systems with different number of components, such as Euler angles (3 elements) to quaternions (4 elements),

  • r articulated parts verses

single frame reference. 0 = No multiple attribute conversion 1 = Multiple attribute conversion for 5 or less fixed types 3 = Multiple attribute conversion for less than 15 fixed types 5 = Arbitrary multiple attribute coordinate conversion Functional Capabilities SDEM Translations Reference ID Capability Definition Examples Levels of Implementation FC-ST-1 Capability to perform unit conversion on a single attribute (SDEM element). 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 less defined types 3 = Single attribute conversion for less than 15 fixed types 5 = Conversion between arbitrary units 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 number of components. For example, if a gateway can translate between coordinate systems with different number of components, such as Euler angles (3 elements) to quaternions (4 elements),

  • r articulated parts verses

single frame reference. 0 = No multiple attribute conversion 1 = Multiple attribute conversion for 5 or less fixed types 3 = Multiple attribute conversion for less than 15 fixed types 5 = Arbitrary multiple attribute coordinate conversion

slide-12
SLIDE 12

ANDEM

  • Defines a format for SDEM representation that is independent of

the underlying metamodels associated with major simulation architectures (e.g., HLA, DIS, TENA, & CTIA)

  • The original purpose of ANDEM was to define an intermediate

format for storage of SDEM components

  • ANDEM has now been extended to support a broader set of

requirements, which includes the use of ontologies to support machine reasoning and improved semantic-level interoperability

  • The Resource Description Framework (RDF)/Extensible Markup

Language (XML) representation of ANDEM was assessed as a potential common intermediate format for defining the SDEM mappings necessary to meet LVC interoperability requirements

  • Major finding was that it worked well in this context, and could be

useful for gateway configuration purposes as well

12

slide-13
SLIDE 13

Gateways Performance Benchmarks – Example

13

Performance Metric Element Definition Possible Means of Measure

Resource Utilization Loading levels for system resources:  Memory Percent of available megabytes or number of pages input and output  Central Processing Unit (CPU) Percentage used for both average and maximum, and number of instructions per second required  Disk Percentage used, and number of access

  • perations required

 Input / Output (I/O) Number of operations for both input and

  • utput

 Database Number of database accesses per second  Network Percentage of bandwidth used Speed / Response Time / Latency Time required to process inputs Input/output response time and queue lengths (#messages/tasks waiting) Throughput System processing capability Processing rate for messages, data streams, or packets Scalability Ability for multiple system components to process data flow efficiently Multiple system tested using parameterized filtering Endurance / Robustness / Stability System component reliability and uptime Mean time between failures Performance-Related Accuracy Minimizing output errors that are due to performance characteristics Percentage of correct output data

slide-14
SLIDE 14

LVCAR Gateways Effort – Block 3 Activities

  • Develop a Gateway Configuration Model that identifies an explicit set of

gateway requirements, and discusses how the emerging gateway products and processes will address those requirements

  • Develop a common Gateway Description Language (GDL), in a machine-

readable format/syntax, for describing both user gateway requirements and the capabilities that individual gateways can offer

  • Supports user discovery of needed gateway capabilities
  • Develop a common Gateway Mapping Language (GML) to formalize format

and syntax of mappings between different SDEMs

  • Reduces number of required mappings, and supports reuse of mapping data
  • Develop initial repository for GDL-based gateway descriptions.

Incorporate applicable search and requirements-to-capabilities matching algorithms

  • Develop initial tools for GDL and GML file creation/editing
  • Socialize draft GPBs with gateway developer organizations. Incorporate

feedback and prepare formal specification

  • Develop Gateways tutorial

14

slide-15
SLIDE 15

* Based on Performance Benchmarks Specification

Gateway Requirements

GW-N GW-3 GW-2 GW-1

Search & Discover GDL File

SDEM Translations Architecture Behaviors Operation Modes Performance*

GW-Z GW-A

Best Matches Gateway Assessment

Perform SDEM Mapping

SDEM Mapping Library

Reuse Existing Mapping? Build New GML File

MAP-3 MAP-N MAP-2 MAP-1

Yes No

Perform SDEM Mapping

SDEM Mapping Library

Reuse Existing Mapping? Build New GML File

MAP-3 MAP-N MAP-N MAP-2 MAP-2 MAP-1

Yes No

Perform GW Configuration

GW Configuration Library

Reuse Existing Config? Build New GCL File

CON-3 CON-N CON-N CON-2 CON-2 CON-1

Yes No

Selected Gateway

GML Editor GCL Editor

Reevaluate

Prepare Gateway

Exercise Gateway Configuration File Mapping File

Search For Gateways

Complete Gateway Configuration

Select Gateway

* Based on Performance Benchmarks Specification

Gateway Requirements

GW-N GW-N GW-3 GW-3 GW-2 GW-2 GW-1 GW-1

Search & Discover GDL File

SDEM Translations Architecture Behaviors Operation Modes Performance*

GW-Z GW-A

Best Matches

GW-Z GW-Z GW-A GW-A

Best Matches Gateway Assessment Gateway Assessment

Perform SDEM Mapping

SDEM Mapping Library

Reuse Existing Mapping? Build New GML File

MAP-3 MAP-N MAP-2 MAP-1

Yes No

Perform SDEM Mapping

SDEM Mapping Library

Reuse Existing Mapping? Build New GML File

MAP-3 MAP-N MAP-N MAP-2 MAP-2 MAP-1

Yes No

Perform GW Configuration

GW Configuration Library

Reuse Existing Config? Build New GCL File

CON-3 CON-N CON-N CON-2 CON-2 CON-1

Yes No

Selected Gateway

GML Editor GCL Editor

Reevaluate

Prepare Gateway

Exercise Gateway Configuration File Mapping File

Search For Gateways

Complete Gateway Configuration Complete Gateway Configuration

Select Gateway

LVCAR Process View

slide-16
SLIDE 16

LVCAR Gateways Effort – Future Activities

16

FY12:

  • Develop a Gateway Configuration Language (GCL) which

standardizes the format and structure of gateway configuration files

  • Supports reuse of gateway configuration files
  • Continue development of supporting automated tools
  • Capability demonstrations with “early adopter” gateway
  • rganizations

Potential:

  • Gateway Testing Laboratory (GTL)
  • Gateway language standardization
slide-17
SLIDE 17

Questions and Feedback

17