A Generalized Approach To Networked Systems Interoperability

1
A Generalized Approach To Networked Systems
Interoperability

• Martin Tapp (martin.tapp_at_cae.com)
• Brian Pages
• Gabriela Nicolescu
• El Mostapha Aboulhamid

2
Overview

• Introduction
• Generalized Interoperability Approach
• Prototype
• Results
• Conclusions

3
Introduction

• Distributed simulation environments share object
  model definitions as their communication software
  foundation
• IEEE specification for DIS (Paper specification)
• HLA 1.3 IEEE 1516.2 OMT (Format syntax
  specified)
• Interoperability examples
• HLA 1.3 HLA 1.3 (FOM Interoperability)
• DIS HLA IEEE 1516 (Network Interoperability)

4
Interoperability

• Interoperability ? Software development
  maintenance
• Adapt existing applications
• Use a gateway
• To achieve interoperability
• Represent object models in software from their
  description
• Object Model Representation (OMR)
• Transform data from one object model to another
• Object Model Interoperability (OMI)

5
Generalized Interoperability Approach
Net Unity Architecture
HLA OMT
RTI - Federate Ambassador
C O MM
Network 1
OMR 1
HLA DIS
OMI 1-2
HLA Federation
L A Y E R
DIS Exercise
Network 2
OMR 2
Application Domain
UDP Socket
DIS
6
Net Unity Architecture

• Goal
• Achieve interoperability between
• Networked systems
• Regardless of
• Object model representation used
• Communication technology involved
• Minimize
• Software development maintenance
• Hypothesis
• OMR OMI descriptions are available
• In a specific format syntax usable by software

7
Interoperability Building Blocks

• Maximize software reuse ? Reduce soft. dev.
  maint.
• Interoperability Building Blocks OMR OMI
• CAEs .NET RD demonstrated
• Rapid prototyping application development
• Reduced software development time costs

Applications
Gateway
Object Model Interoperability
FOM 1 FOM 2
FOM 1 DIS
Object Model Representation
FOM 1
FOM 2
DIS
.NET Framework
.NET
8
Microsofts .NET Framework

• Makes it easy to build distributed applications
  on a wide variety of platforms D. Fay
• Cross-language interoperability approach
• 20 programming languages supported (C, C, VB,
  )
• Assembly Portable Managed Library (.NET DLL)
• Base class library (IO, Threading, UI, Security,
  GC, )

9
Net Unity .NET Foundations

• .NET Reflection
• Metadata access (type, field method
  information)
• Services for dynamic type creation invocation
• Runtime compiler services (C, VB, JScript)
• Runtime metadata emitting services (Emit byte
  code)
• Net Unity Reflection
• Generate interoperability building blocks as
  assemblies
• From OMR OMI descriptions (Hypothesis)
• Just-In Time Interoperability (JITI)
• Gain interoperability at runtime Edit
  Continue
• Focus on interoperability, not on software
• Describe OMR OMI instead of programming them
• Equivalent to manually programming the
  interoperability
• For .NET ? Zero performance impact

10
Net Unity Prototype Context

• RD effort at CAE
• To connect STRIVE? CGF to OTB/OOS
• To achieve interoperability with reduced software
  development maintenance
• To expand .NET knowledge in distributed
  simulation environments
• In conjunction with
• CAE Montreal
• CAE Tampa
• Ecole Polytechnique of Montreal
• University of Montreal

11
Prototype JVB STRIVE? FOMs Interoperability
Gateway
OMR description
HLA Monitor
JVB OMR
JVB Federation
OMI description
OMI Engine
1.8 GHz DMSO NGv6 512Mb, Linux
STRIVE Federation
STRIVE OMR
Network Adapter
3.0 GHz DMSO NGv6 1GB, Win2000
Network Adapter Generator
12
Prototype Results Reflection of OMR
Descriptions

• FOMs reflected as assemblies from HLA 1.3 OMT
  files
• Software development required for
• Enumeration sizes (omitted in OMT specification)
• 0-1 cardinality (pseudo-variant data types)
• any data type
• NameCharacter construct (allows , , for
  names)
• All resolved with HLA IEEE 1516.2 except
• Some constructs are susceptible to human
  interpretation (Ex. encoding attribute ? Fixed
  encoding or description)
• Generic software killer
• Addressed by software development
• Net Unity not used at full potential
• Extend to suit object models other than HLA like
  DIS

13
Prototype Results OMI Description Generation

• ini files used to represent type
  (class/interaction) and field (attribute/parameter
  ) mapping
• No standard format exists to express
  interoperability
• Pre-defined list of transformations
• Software development required to expand list
• Proposed OMI description
• XSLT based format (eXtensible Stylesheet Language
  Transformations, http//www.w3.org/TR/xslt)
• Describes how to transform XML into another
  format
• OMI Describe how to transform one object model
  into another
• XSLT template concept Interoperability
  processing distribution (Scalable
  Interoperability Processing)
• XML based
• Multitude of tools available to construct XSLT
  documents

14
XSLT-like OMI Description

• ltomitransform matchA paramagt
• ltomiwith-param typeB nameb /gt
• ltomiassign seta.x selectb.x /gt
• ltomiassign seta.y selectb.y /gt
• ltomiassign seta.z selectb.z /gt
• lt/omitransformgt

OMI 1-2
OMR 1 A.x A.y A.z
OMR 2 B.x B.y B.z
T1
T2
T3
15
Prototype Results JVB STRIVE? FOMs
Interoperability

• Extensive tests with various scenarios
• HLA Monitor primary network validation tool
• OTBs internal debugging features used
• Interoperability demonstrated
• Phase 1 Partial Interoperability
• Aircraft types only
• Phase 2 Full Interoperability
• Entity level only (entity classes interactions)
• Compared to single CGF application
• Partial JITI (Just-In Time Interoperability)
  demonstrated
• OMR pre-generated by HLA Monitor
• OMI Engine feed at runtime with ini files

16
Prototype Results Software Development Effort

• TTAPI Total Time taken to Achieve Partial
  Interoperability
• TTAI Total Time taken to Achieve
  Interoperability
• TTSI Total Time Spent on Interoperability only
• Very low
• 60 direct mapping or simple type cast

17
Prototype Results .NET Distributed Simulation
Environments

• Gateway uses 30-35 CPU (3.0 GHz)
• 50 entities total (25 per fed.)
• Runs on same PC as STRIVE? federation
• No optimizations
• Hyper-threading capable CPU not used
• Garbage collection spikes were never encountered
• At 50 entities
• 500ms for an entity to be discovered on its
  target federation
• DMSO NGv6 RTI
• 1-15 ms in/out of gateway with CAE RTI

18
Summary

• Hypothesis (OMR OMI descriptions available)
• OMR Extend HLA IEEE 1516.2 ? DIS,
• OMI Requires standard XSLT-like format to be
  defined
• Interoperability building blocks
• OMR Demonstrated (HLA Monitor)
• OMI Partially demonstrated (OMI Engine ini
  files)
• Prototype Gateway
• Required minimal software development (HLA 1.3
  OMT special cases Transformations)
• .NET performances
• Prototype Gateway More than acceptable
• Entity discovery time Need to change RTI

19
Conclusions

• Net Unity Architecture
• Generalized networked systems interoperability
• With interoperability building blocks
• Just-In Time Interoperability (JITI)
• With .NETs Reflection
• Scalable Interoperability Processing
• With XSLT-base OMI description
• Interoperability minimally achieved with
• 2 OMR 1 OMI descriptions
• Possibly no software development involved

• Focus is on interoperability

20
Questions?

• Thank you!