tena in a resource- constrained environment (trce) overview · 2012-01-06 · – apple ios 4.x...

TENA in a Resource-

Constrained Environment

(TRCE) Overview

ITEA Test Instrumentation Workshop

May 10-12, 2011 Las Vegas, NV

Tom Treakle [email protected]

DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited.

mailto:[email protected]



TENA in Resource Constrained Environments

(TRCE) Project Addresses These Issues

• Low Data Rate Networks – TENA must be able to establish and

maintain data connections on low data rate networks

– Need to optimize use of low data rate networks to support relevant operational scenarios

• Wireless Networks – Current range environments use

wireless links extensively for various systems under test

• Variable Quality Networks – T&E systems poorly tolerate high

loss, link failure, or heterogeneous links

– Need to provide data continuity for degraded or heterogeneous networks

• Specification of Interests – Subscribers must be able to specify

data “interests” to more efficiently use available & limited network resources

Non-TENA Applications

RangeResource

Application

Reusable

Applications

Reusable

Applications

Non-TENA Communications

TENATENA

Range ResourceApplication

Data

Collectors

HWILHWIL

RangeResource

Application

Repository

Utilities

TENAObject

TENAObjectTENA

Object

Infrastructure

Management and

Planning Utilities

Object Model

Utilities

TENA Utilities

TENA Common Infrastructure

TENA Applications

Non-TENA System

Non-TENA System

I S R F o r c e M i x S t u d y

S h a d i n g i s : P h a s e

TENA Tools

GatewayGateway

TENA MiddlewareTENARepository

TENA MiddlewareLogicalRangeData

Archive

- Improve TENA’s

support for

variable quality

and low data rate

network links

including wireless

networks

- Expand TENA’s

support for

handheld and

embedded

instrumentation

computational

platforms

DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited. 2

TRCE OV-1

3 DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited.

TRCE Phase 2 Overview

• Developed Link Node Controller (LNC) Application

– Bridge between 2 TENA executions across variable quality links

– Prototyping tool to investigate data reduction, QoS techniques, and smartphone

device connectivity

• Developed TENA RelayNode

– RelayNode 1.0 is a generalization of the LNC application that is integrated with the

TENA Object Model Compiler (OMC)

– RelayNode 2.0 is in development as an integral part of the TENA Middleware

• Demonstrated Full TENA Middleware port on hardware constrained devices

– Apple iOS 4.x (iPad, iPhone, iPod)

– Gumstix Overo computer on module with OpenEmbedded Linux

– Android 2.2 port initiated but not completed due to compiler issues. Port should be

completed during Phase 3.

• Demonstrated TENA connectivity over 802.11 a/b/g/n, 3G cellular, Harris

SeaLancet, Serial Port, and Benthos acoustic modem links

• Developed migration plan and design for Embedded Instrumentation System

Architecture (EISA) capabilities to be fully TENA enabled.


4

LNC & Relay Node

Phase 2 Accomplishments


Link Node Controller (LNC)

• Prototyping tool to study technologies and techniques

including Relay Node, wireless & low data rate protocols,

and link management

• Connects 2 LANs/TENA Executions separated by low bit

rate and/or variable quality links including wireless

• Shares TENA Stateful Distributed Objects (SDO) data

across the link

• Provides support for ACOMMS, SATCOM, and 3G link types

• Aggregates updates at nodes to reduce redundant data

transmissions

• Incorporates multiple data reduction and filtering techniques

• TENA Release 6.0.1 compatible


Develop TENA RelayNode

• Takes advantage of network topology to increase efficiencies

– Reduces redundant transmissions between LANs

– Allows less information to be transmitted over lower data rate links

– Core Framework that can support ancillary prototyped technologies such as

• Store & Forward

• Link specific protocols and management (wireless, SATCOM, Acoustic, etc.)

• Dead Reckoning

• Lossy and Lossless Compression techniques

• Heterogeneous link management and support

• Wire size minimization and update filtering techniques

• Configured pre-event and transparent to applications

– Will improve Reliable Communication efficiency since Publishing applications

won’t have to send updates to all subscribers on the WAN

– Reduced dependency on Multicast during events – testers prefer reliable data

transfer if possible.

• RelayNode 1.0 is an OM specific application auto-generated through the TENA

Object Model Compiler (OMC)

• RelayNode 2.0 will be fully integrated into the TENA Middleware


RelayNode 1.0

• Auto-generated application that will support a wide range of object models

• Can be deployed at strategic points geographically on the LAN/WAN

• Supports each device connection in separate thread

• Will eventually support Bluetooth and Zigbee devices


Relay Node 2.0 (in progress)

• Fully integrated in TENA Middleware

• May eliminate need for a separate TENA

Execution Manager

• Requires significant re-work of core TENA

Middleware

– Replacement of Distributed Interest-Based

Message Exchange (DIME)

– Progress on development is being made, but

this is a significant undertaking


LAN 2

LAN 1

TENA Release 6 Connectivity


Reliable Communication Mode

LAN 2

LAN 1

TENA RelayNode Connectivity


RelayNodes Facilitate Hub/Spoke Configurations

Sample Relay Node Deployment


Platform Ports of TENA

Middleware to Hardware

Constrained Devices


Hardware Constrained Ports

• Supported Platforms

– iOS (iPhone, iPad, iPod Touch)

– Overo (Gumstix)

• Android support pending

• Buildsys cross-compilation support


iOS TENA Port • Full Native TENA Port Complete

• Support

– iOS 4.x (will migrate to Latest)

– Xcode 3.2 (will migrate to 4.0 or Latest)

– Universal armv6/armv7

– Simulator x86

• Current Platform Designators

– ios40-xcode32-x86-d

– ios40-xcode32-x86

– ios40-xcode32-armv6-d

– ios40-xcode32-armv6

• TENA Standard OM Support – User requested OMs require manual build and delivery

• Developing exampleiOSapplication Object Model

Compiler (OMC) plug-in DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited. 15

iOS Platform Demo App

• Thin layer in application allows for runtime selectable support of TENA or LNC wire protocols

– LNC wire protocol necessary for 3G/4G connections without VPN due to cellular network topology

– TENA wire protocol supported on 3G/4G with VPN

• Supported Hardware

– iPhone OS 3.1.3 - iOS 4.2

– iPhone (3gs, 4), iPod, iPad

• Can support static and dynamic mapping tiles

• Support subscription to TENA Video Distribution System (TVDS) feeds

– Control of Pan/Tilt Cameras


iPad Demo App • Mapping and display of TENA

Platforms (static and dynamic

maps)

• Supports Pub/Sub of TENA-

Platform and EventTeam

AVStream, CameraControl,

RangeSafetyWarning OMs

• Display of TVDS Video Streams

• WiFi Connectivity

– Directly to TENA Execution

– Via RelayNodes (TENA/LNC)

• 3G/4G Connectivity

– Via RelayNodes using LNC

protocol

– When connected through VPN

• Directly to TENA Execution

• Via RelayNodes (TENA/LNC)


17

iPad Demo App


18

• Native iPad / iPhone

look & feel

– Pinch zoom

– Pin dialogues

– Google mapping

support

• Platform Listing with

zoom-on-select

• Popup dialogues

show detailed

Platform specifics

• Indicators for

“attached” video

feeds from TVDS

Gumstix Overo

• Computer on Module

– Arm Cortex A-8 CPU @ 600MHz

– 256 MB memory, MicroSD card, Bluetooth

and WiFi on the module

– Expansion boards:

• Summit: USB master, wired 100MB Ethernet,

HDMI out (can do 1024x768 60 HZ), stereo sound

in/out, GPS, 4.3 inch touch display

• Pinto: USB OTG port, solder connections for

GPIO and ADC input/output


Gumstix Overo

• OS/compiler – Openembedded Linux, kernel 2.6.35,

• full X11, ssh, media encoding/decoding

– Compiler gcc 4.3.3 based cross compiler

• Native full TENA port complete – Platform and all its dependent OMs & PRITEC Measurand completed

– Tested with iPad, Mac

• Bluetooth Sensor Support – Connected to GPS & multiple IMUs via Bluetooth link

– Published values via TSPI and Measurand OMs

• Path forward – Support for all TENA standard OMs

• User requested OMs require manual build & delivery

– Develop exampleOveroapplication Object Model Compiler (OMC) plug-in

– Connect to other analog sensors and publish as TENA OMs

– Use as platform for Embedded Instrument (EI) Node and Data Acquisition Controller (DAC) to support EISA / OASIS concept transition (discussed later in briefing)


Android • Developed and demonstrated a native port of the LNC client

– Implemented LNC and app in Java

– Functionality matches capability on the iPhone/iPad

• Platform Mapping, control of missile launcher, missile launcher video

• Started native full TENA port Oct. 2010 – significant issues existed

– Native C++ compiler lags Java SDK – Google wants you to use Java

– Two major third party compilers

• Neither one supports exceptions and shared object libraries

• Static compilation ongoing – ACE and TAO compiled, build testing unsuccessful

– Native C++ apps not officially supported

• Currently executables can be built, but support may disappear in the future

• Must have a Java main using JNI to execute C++

• New Android NDK Revision 5b released Jan 2011

– Native C++ compiler still lags Java SDK – Google prefers that you use Java

• Latest compiler makes big advances, supports RTTI, STL, shared object

libraries and exceptions – just not all at the same time

• Native C++ apps now supported for most recent Android OS versions

• Should be sufficient for Vanderbilt to migrate ACE+TAO using static libraries

• Develop exampleAndroidapplication OMC Plug-in


Characterization Testing and

Testbed Enhancements

Phase 2 Accomplishments


TRCE Characterization Test Plan Overview

• Methodology – Time the sending of some significant number of updates

– Introduce varying numbers of publishers and subscribers

– Vary transport protocols (Best Effort or Reliable Mode)

– Vary link characteristics (latency, bandwidth, packet loss, etc.)

• Analysis – Performed for each test cycle before proceeding to the next test cycle

– Plot • Number of updates vs. time - line graph

• Histogram of updates vs. time

• Deltas

• Memory utilization (buffering one way?)

• CPU load

– Capture relevant metrics (dropped updates, failed discoveries, etc.)

• Populate Baseline TENA Test Matrix with collected results

• Ensure results can be explained

We want to characterize TENA throughput across a

range of hardware and software platforms.


Compare Baseline TENA Performance

with TENA RelayNode 1.0 Capability

• Compare Baseline TENA Characterization Test Matrix results with TENA RelayNode 1.0 Characterization Matrix results

• Identify key performance trade space matrix – Bandwidth thresholds

– Packet loss thresholds

– Latency thresholds

• Develop guidance on where RelayNode benefits outweigh performance penalty


TENA vs. LNC Protocol – Packet Sizes

TENA R6

(Reliable)

TENA R6

(Best Effort)

LNC (No

Compression)

LNC (Lossy

Compression)

Header (bytes) 78 42 42 42

Payload (bytes) 465 469 105 56

Total Update

Size (bytes)

543 511 147 98

Note: Lossy Compression technique reduces the resolution of TSPI information to ~10m

and does not retransmit data fields unless they have changed since the last update.

Average Update Size TENA-Platform-v4

LNC protocol provides a factor of 3.5 to 5.2 improvement in update size

• Takes advantage of Object Model specific characteristics – TENA MUST be

general in nature

• Reduces the required header information in each update because connection

is 1 to 1


TENA vs. RelayNode Using LNC Protocol

Performance Characterization

TENA R6

(Reliable)

TENA R6

(Best Effort)

RelayNode (No

Compression)

RelayNode

(Lossy

Compression)

Total Update Size (bytes) 543 511 147 98

1 Publisher and 1 Subscriber

Baseline Rate (updates/s) 6,187 7,540 2,352 2,549

5 Publishers and 5

Subscribers Baseline Rate

(updates/s) 4,351 1 8,305 1,673 1,884

Minimum Supported

Throughput in Kbps for 5

Publishers and 5

Subscribers, 10 Hz rate &

100% Successful Updates

Through Link

1,250 250 75 40

• RelayNode with LNC Protocol reduces wire size & allows for operation on lower

bandwidth links than TENA R6 with the penalty of fewer updates per second supported

o All update rates are stated as the average over all Subscribers

o Tests performed with 100 Mbps link & switch

1 TCP Congestion reduction taking place during test

Highlights the update rate vs. wire efficiency trade space

3.5 x

3.2 x

3.3 x

5.0 x


Migration of Capabilities to TENA

Embedded Instrumentation System Architecture (EISA)

and

Open-Source Architecture for Software Instrumentation

of Systems (OASIS)


Embedded Instrumentation System Architecture

(EISA) High-Level Functional Architecture

Embedded Instrument (EI) Node Functions:

Sensor/transducer interface support

Physical data aggregation

Synthetic data aggregation

Data preprocessing and buffering

DAC/DAA Functions:

Data aggregation from multiple EI Nodes

Data access control and data storage

System configuration management

Interface with the outside world

TENA


EISA System of Systems Case Study


T

E

N

A

T

E

N

A

T

E

N

A

T

E

N

A

TENA

TENA

Objectives of Critical Actors in OASIS

30

• Software Probe: Collects application and system metrics autonomously or manually

• EINode: Regulates network transmission of collected metrics

• Data Acquisition Controller: stores collected metrics for later retrieval

• Test and Experimentation Manager: main entry for user applications to access

metrics collected by software probes

• Performance Analysis Tools: user-defined applications that analyze collected

metrics

TENA

EM

TENA

(GenericProbe

OM)

TENA (SpecificProbe OMs

Thermostat, Accel, strain, etc)


EISA / OASIS Layered Data

Acquisition Approach


Layering of DACs & EINodes allows for improved sensor management

EISA / OASIS Migration

Path with TRCE • Must Have Capabilities:

– EA and DAC Support for both hardware and software probes in the same architecture.

– Support for IEEE 1451 smart sensors is desired, but since none exist as COTS

products this is not a hard requirement.

– Must create an automatic translator that takes OASIS Probe Definition Language (PDL)

description and generates a TENA Definition Language (TDL) file for the Public facing

object models.

– Develop a TENA Version of the DataChannel interface to include command methods

such as setting update rate and start/stop probe.

• Modify the DAC software with the Private TDL interface to talk to the EI Node and

Data Channel.

– Develop a TENA Data Arbitration Adapter (DAA) attached to a DAC to include the

Public TENA TDL that contains all “sensors” in a single shared library (.so, .dll) that can

be loaded at run time.

• Develop an Object Model Compiler (OMC) plug-in to write the implementation to

extract sensor data and turn into TENA object attributes

• Nice to Have Capabilities: – Extend the DAC Software to include a generalized query interface and have a TENA

version of the query channel to support windowed query of locally stored data.

– Extend EI node to support multiple data channels


Initial Probe Support • Hardware Probe Implementations

– Thermometer

– Hall-Effect magnetic blade rate encoders

– Battery Voltage

– 6DOF IMU (compass, accelerometers, orientation)

• Software Probe Implementations – Network usage

– CPU usage (total and process)

– Memory Usage (total and process)


Phase 3 Outline

• Continue to Mature Technologies

– Build RelayNode 2.0

– Finalize, test, and transition TENA Middleware ports

– Migrate EISA/OASIS technologies

• Finalize TRL-6 Demonstration Plan for Single Range/Site

• Build and Document Demonstration Software Release

– Build a software release that incorporates the TENA Middleware, Phase 2 technologies, and appropriate sample applications

– Installation instructions for software release and applications

• Demonstration of Capabilities in Single Range/Site Event

– Demonstrate developed technologies according to demonstration plan

– Collect all data necessary to determine effectiveness of Phase 2 technologies

• Documentation

– Develop user manuals, installation instructions, and a demonstration & recommendation report


Phase 3 Demo: Aberdeen Proving Ground Current Test Configuration


Phase 3 Demo: Aberdeen Proving Ground TRCE Proposed Test Configuration


Phase 3 Demo: Data Comparisons

• Goal

– Collect relevant TSPI metrics

• GPS: time, position

• 6 DOF IMU: heading, accelerations, and

orientation

– Compare current ADMAS system data with

TRCE technology collected data

– Collect link characterization metrics for lab

use (Shunra)

– Document and present results


Bluetooth

Sensor

Links TENA

Wireless

LAN

TENA Booth Demonstrations

3 Axis IMU

6DOF IMU

Key Ring

GPS

Pressure

Switch

Thermometer

Hall-Effect

Sensor

Gumstix

Overo

• All devices battery powered with exception of WiFi access point

• “Instrumented” small R/C vehicle DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited. 38

TRCE Phase 3 Path Forward

• Transition RelayNode 1.0 capability to TENA community via Tools page on

Wiki

• Continue developing full implementation of TENA RelayNode 2.0 in branch

of the Middleware

• Develop, test, and transition direct ports of TENA Middleware in iOS 4.x

(iPhone, iPad, iPod) and OpenEmbedded Linux (Overo)

– Include Android 2.2 when complete

– Develop sample applications for devices

• Work with Aberdeen Test Center to demonstrate TRCE in TRL-6

environment

– Connectivity to 3G enabled devices on vehicles

– Collect TSPI and possibly other T&E data for comparison to ADMAS system

• Migrate Embedded Instrumentation Systems Architecture (EISA) concepts

and relevant software to use TENA Middleware and Object Models

– Use Embedded Linux port of TENA Middleware on Gumstix devices

– Implement TENA Embedded Instrument (EI) Node and Data Acquisition

Controller (DAC) Applications

– Support DataChannels over Bluetooth, Zigbee, USB, Serial, and IEEE 1394 links


Wrap Up

• TRCE will provide technologies for use in the TENA Middleware to support low data rate, variable quality, and wireless networks – The TENA RelayNode 1.0 application provides a robust interim solution that

can be quickly leveraged by the T&E community.

– Accelerated RelayNode 1.0 testing in a TRL-6 environment and generalization to support most TENA Object Models will make this into a transitional capability quickly

– TENA fully integrated RelayNode 2.0 as a core component of the Middleware will provide a long term capability with integrated link management functionality

• TRCE is developing a TENA Middleware ports that will operate natively on small form factor devices like smartphones and embedded instrumentation computers – Apple iPhone OS, Android, and OpenEmbedded Linux support

– The goal is to support all required platforms on single TENA code base

• TRCE Smartphone support fills T&E need for range safety use case (personnel tracking and safety fan violation) at ranges

• TRCE technologies will enable full TENA interoperability throughout the entire mission based testing domain


The authors would like to thank the Test Resource

Management Center (TRMC) Test and

Evaluation/Science and Technology (T&E/S&T) Program

for their support. This work is funded by the T&E/S&T

Program through the Netcentric System Test (NST) focus

area under contract with PEO STRI, Orlando, FL, contract

W900KK-09-C-0013.

Any opinions, findings and conclusions or

recommendations expressed in this material are those of

the author(s) and do not necessarily reflect the views of

the Test Resource Management Center (TRMC) Test and

Evaluation/Science & Technology (T&E/S&T) Program

and/or the U.S. Army Program Executive Office for

Simulation, Training & Instrumentation (PEO STRI)

Acknowledgement


tena in a resource- constrained environment (trce) overview · 2012-01-06 · – apple ios 4.x...

Documents