Upload
alfredo-kitts
View
215
Download
0
Tags:
Embed Size (px)
Citation preview
Keith PochFoundation Initiative 2010 Cadre
22 July 2003
Test & Training Enabling Test & Training Enabling Architecture (TENA)Architecture (TENA)
NET3 Conference
Orlando, Fl
Interoperability at DoD Ranges Interoperability at DoD Ranges
Slide 2
Foundation Initiative 2010Foundation Initiative 2010Overall VisionOverall Vision
Design and prototype a technological infrastructure to enable interoperability and reuse within the range community
Seamless environments that integrate test ranges and facilities, training ranges, laboratories, and modeling and simulation (M&S) assets
Improve the scope and scale of testing and training the increasingly complex systems and missions in a cost-effective manner
Recognize that our solutions need to be more than quality software, we need to:
Elegantly solve key usability issues Satisfy the core operational and
performance requirements Work with the range community
so the solutions are implemented
Lay the groundwork for full support for integratedmulti-range events
Slide 3
Foundation Initiative 2010Foundation Initiative 2010MissionMission
Enable Interoperability among Range systems, Facilities, Simulations, C4ISR systems in a quick, cost-efficient manner
Foster Reuse for Range asset utilization and for future developments
Currently, range systems tend to be non-interoperable, “stove-pipe” systems
The purpose of TENA is to provide the architecture and the software implementation necessary to:
Lay the Foundation for Future Test and Training Range Instrumentation
Support the Warfighter (Joint Vision 2010/2020) Enable SBA, STEP, CEE, JSB, and JDEP Foster Test and Training Integration In the long term: SAVE MONEY!
Support the Warfighter (Joint Vision 2010/2020) Enable SBA, STEP, CEE, JSB, and JDEP Foster Test and Training Integration In the long term: SAVE MONEY!
Slide 4
Overall Development StrategyOverall Development Strategy
TENA was revised based on user feedback and lessons learned from working software prototypes
TENA will be revised in the future based on future prototypes
TENA is based on real-world tests at real ranges
User Feedback
LessonsLearned
User Feedback
LessonsLearned
User Feedback
LessonsLearned
PrototypesPrototypesPrototypesPrototypes
PrototypesPrototypesPrototypesPrototypes
PrototypesPrototypes
PrototypesPrototypes
Test & Training Enabling
Architecture(TENA)
Slide 5
Driving Technical RequirementsDriving Technical Requirements
1. Interoperability The characteristic of a suite of independently-developed components,
applications, or systems that implies that they can work together, as part of some business process, to achieve the goals defined by a user or users.
2. Reusability The characteristic of a given component, application, or system that
implies that it can be used in arrangements, configurations, or in system-of-systems beyond those for which it was originally designed.
3. Composability The ability to rapidly assemble, initialize, test, and execute a system
from members of a pool of reusable, interoperable elements. Composability can occur at any scale — reusable components can be
combined to create an application, reusable applications can be combined to create a system, and reusable systems can be combined to create asystem-of-systems.
Slide 6
Achieving Interoperability, Achieving Interoperability, Reuse, and ComposabilityReuse, and Composability
Interoperability requires: A common architecture An ability to meaningfully communicate
A common language A common communication
mechanism A physical connection between the
two systems A common context
A common understanding of the environment
A common understanding of time A common technical process
Reuse and Composability require the above, plus
Well defined interfaces and functionalityfor the application to be reused
TENA OM, TENA Middleware
TENA
TENA Object Model (OM)
TENA Middleware
Network, shared memory
TENA Object Model(Environment)
TENA Technical Process
Reusable Tools,Repository
Slide 7
TENA Architecture OverviewTENA Architecture Overview
Non-TENA Applications
RangeResource
Application
RangeResource
Application
Management andMonitoring Apps
Management andMonitoring Apps
Analysis andReview Apps
Analysis andReview Apps
Non-TENA Communications
TENATENATENA
TENARepository
Range ResourceApplication
Range ResourceApplication
DataCollectors
DataCollectors
HWILHWIL
RangeResource
Application
RangeResource
Application
TENA Middleware
Repository Utilities
Repository Utilities
TENAObject
TENAObjectTENA
Object
Logical Range Planning Utilities
Logical Range Planning Utilities
Object Model Utilities
Object Model Utilities
LogicalRangeData
Archive
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
6 .26 .05 .44 .84 .23 .63 .02 .41 .81 .20 .60 .0
TENA Tools
GatewayGateway
Slide 8
Ways TENA Middleware CanWays TENA Middleware CanExchange DataExchange Data
TENA presents to the range user a unification of several powerful inter-application communication paradigms
Publish/Subscribe Similar in effect to HLA, DIS, or other PDU-based communication
systems Each application publishes certain types of information (the publication
state) which can be subscribed to by any other application
Remote Method Invocation Similar to CORBA or Java RMI Each object that is published may have methods that can be remotely
invoked by other applications
Messages Individual messages that can be sent from one application to one or
more other applications
Data Streams Native support for audio, video, and telemetry
Slide 9
Key Functionality ofKey Functionality ofTENA Beyond HLATENA Beyond HLA
Standard Object ModelTENA provides for the managed evolution of a standardized Object Model (interfaces, data formats, data definitions, control commands, etc.)
Significance: Range-community-wide agreed upon data formats, definitions, etc. promotes interoperability to a greater degree than the HLA specification
Manages Persistent Data TENA provides for the management and standardization of database information throughout the range event lifecycle, including scenario information and data collected during an exercise
Significance: Interoperability is achieved before, during, and after a range event, leading to easier setup, initialization, and analysis, saving both time and money
High Performance and ReliabilityTENA Objects are “compiled-in” when the application is made TENA-compliant
Significance: Higher performance, plus higher reliability since any errors in data formats will be discovered during software compiling (pre-mission) rather than during the test mission (at run-time)
Support for Data StreamsTENA supports real-time delivery and storage of data stream information (audio, video, and telemetry)
Significance: A substantial amount of test information is streaming data. Fully integrating data streams into TENA provides high-performance management of this type of information in a standard, reusable, interoperable fashion
Support for More Complex, Meaningful, User-Defined Object ModelsTENA allows for objects to be composed of other objects (objects can contain other objects)Significance: Small “building block” objects (Time, Position, Orientation, etc.) can be standardized and reused to efficiently define other more complex objects, yielding more interoperability quickly and at less cost than with the HLATENA Middleware marshals/demarshals data, rather than relying on individual applications to do soSignificance: Middleware marshaling makes it easier to integrate different computer platforms (Windows, Linux, Sun, etc.) in a distributed test event and avoid integration errors due to inconsistent user-written softwareTENA supports remotely invoking “methods” (control commands, operations, processes) of another applicationSignificance: Software interfaces can be designed more naturally and effectively for distributed test events
Slide 10
TestControl Station
Simulation
Logical RangeLogical RangeSimple ExampleSimple Example
TENA specifies an architecture for range resources participating in logical ranges
Communication Mechanism (Network, Shared Memory, etc.)
Radar
Slide 11
Logical RangeLogical RangeSimple ExampleSimple Example
TENA specifies a peer-to-peer architecture for logical ranges Applications can be both clients and servers simultaneously In their role as servers, applications serve TENA objects called “servants” In their role as clients, applications obtain “proxies,” representing other
applications’ servants. Only servers can write to their servant objects’ publication state
The TENA Middleware, the TENA objects, and the user’s application code are compiled and linked together
TestControl Station
Communication Mechanism (Network, Shared Memory, etc.)
RadarSimulation
TENA Middleware
TENA Application C
UserApplication
Code
Servant Proxy
Proxy ProxyServant
TENA Middleware
TENA Application B
UserApplication
Code
Proxy Proxy
Proxy Proxy Proxy
TENA Middleware
TENA Application A
UserApplication
Code
Servant
ServantServant
Slide 12
Clients and Proxies;Clients and Proxies;Servers and ServantsServers and Servants
When objects are distributed across multiple processes or machines One object is the “real” object – the one with the implementation All the others are “proxies”
Proxy Object on ClientProxy for Object
27
Remote Interface
Cache of Publication
State
Servant Object on Server
Object 27
Remote Interface
Publication State
Client Process Server Process
TENA Middleware TENA Middleware
Network
ClientObject
RemoteInterface
Implementation
Slide 13
TENA Middleware TENA Middleware Platform/Language SupportPlatform/Language Support
Release 3.0 Platform Support Windows NT 4.0 / 2000 / XP with MSVC++ 6.0sp5 (to be retired) Windows NT 4.0 / 2000 / XP with MSVC++ 7.0 Linux Red Hat 7.2 with gcc 3.0.3 Sun Solaris 8 (SunOS 5.8) with gcc 3.0.3
Additional Platforms To Be Supported Sun Solaris 8 with SunPro 5.4 compiler SGI IRIX 6.5.12 with gcc 3.0.3 on SGI hardware VxWorks 5.5, Motorola MPC7XXX PowerPC, Tornado 2.2 with gcc
3.0.3
Programming Language Support C++ support provided with current release OCX (COM) wrapper developed by one of the TENA users (RTTC) Java application layer developed by one of the TENA users
(Eglin)
Slide 14
Range Integration in Millennium Range Integration in Millennium Challenge 2002 (MC02)Challenge 2002 (MC02)
Joint Training, Analysis, and
Simulation Center
Global Command &
Control System
IntegratingSoftware
TENA Gateway
Joint Joint NetworkNetwork
Command, Control, Communications, Computers, Intelligence Feed
Blue Forces
Opposing Forces
• Aircraft & air targets• Ships• Ground forces
• Ships• Ground forces• Aircraft
Electronic Combat Range/China Lake
Nellis AFB
National Training Center/Ft. Irwin
Land Range/China Lake
Sea Range/Point Mugu
TENA Gateway
TENA Gateway
TENA Gateway
TENA Gateway
TENA Gateway
US Marines/So. CaliforniaLogistics Airfield
Model & SimulationFeed
Slide 15
Gulf Range VAST/IMPASSGulf Range VAST/IMPASS
Acoustic ProcessingGPSCommunication Link
Shipboard ProcessingMap RenderingVirtual Target
Repeater
Shot 1
Shot 2
FFE 3,4,5
Slide 16
VAST/IMPASSVAST/IMPASSNetwork ConnectivityNetwork Connectivity
EGLINAFB
400 Miles
200 Miles
Eglin Central Eglin Central Control FacilityControl Facility
CSSCSS Panama City, FLPanama City, FL
CDSACDSADam Neck, VADam Neck, VA
Eglin Range Site A-15Eglin Range Site A-15
TENA on NIPRNET
TENA on MicrowaveTENA on Fiber
Slide 17
TENA Compliancy LevelsTENA Compliancy Levels
Uses the TENA Middleware
Defined as TENA Objects
TENA Level 1
Uses the TENA Middleware
Defined as TENA Objects
Standard use and definition of Time
Only uses the TENA Middleware
Data Archiving Uses RCC Objects (whenever possible)
Standard Control
TENA Level 3
Uses the TENA Middleware
Defined as TENA Objects
Standard use and definition of Time
Only uses the TENA Middleware
TENA Level 2
Slide 18
Other sites
New TENA Application
Existing Range
Application
Existing Range
Application
Existing Range
Application
Existing Range
Application
Existing Range
Application
Existing Range
Application
NowRange Protocols
TENA-Range
Gateway
Event-ually
Existing Range
Application
Re-architected TENA-compliant
Application
Re-architected TENA-compliant
Application
Re-architected TENA-compliant
Application
New TENA Application
New TENA Application
New TENA Application
Range ProtocolsOther sites
TENA-Range
Gateway
New TENA Application
Existing Range
Application
Existing Range
Application
Existing Range
Application
Existing Range
Application
Re-architected TENA-compliant
Application
New TENA Application
Re-architected TENA-compliant
Application
A Few Years Range Protocols
Other sitesTENA-Range
Gateway
Gradual Deployment of TENAGradual Deployment of TENA
Slide 19
Common Test & Training Range Common Test & Training Range Architecture (CTTRA)Architecture (CTTRA)
CTTRACTTRA
Systems engineers & software developers in the DoD Range and Facility community (both T&E and Training)
13 three-day workshops held (usually every 6-9 months)
CTTRA XIV workshop was held Jan 22-24
Test RangesTest RangesWSMREPGPMRFAFFTCMC AVTBAFWTFYPGRTTC
NAWCADNAWCWDAACAEDCATCNUWCAUTEC
TrainingRepresentatives
TrainingRepresentatives
STRICOMAF XOMPMA-248
NTTRNAWC-TSD
NWADUSATSC
UTTR
Other DoDOther DoDDARPAMDA
JFCOMDMSOJITC
NAVAIRHPCMO
JNIC
Test FacilitiesTest FacilitiesPRIMESACETEF
ATICGWEF
EOTASEL/EOSFELWAFSTAF
Test AgenciesTest AgenciesOPTEVFOR
AFOTECATEC
Army DTCArmy OTCMCOTEA
Slide 20
Architecture Management Architecture Management Team (TENA AMT)Team (TENA AMT)
System Engineers & Technical Leads for the current major stakeholders of TENA
AAC, Eglin AFB FL NUWC, Newport RI NAWC-AD, Pax River MD WSMR, White Sands NM RTTC, Huntsville AL EPG, Fort Huachuca AZ NAWC-WD, China Lake & Point Mugu CA Virtual Proving Ground (VPG) Common Training Instrumentation Architecture (CTIA) PMRF Synthetic Range National Unmanned Underwater Vehicle T&E Center (NUTEC)
Design Decisions / Trade-offs / Status
TENA Use Cases / Prototype Test Strategies
Technical Exchanges of Lessons Learned
Issues & Concerns Identification, Investigation, & Resolution
Meetings every 4-6 weeks
Meetings every 4-6 weeks
Slide 21
Summary of What We HaveSummary of What We Have
A Working Implementation of the Architecture TENA Middleware currently works on Windows, Linux, and Sun
A Process to Develop and Expand the Architecture CTTRA Workshops, AMT Meetings, and RCC Coordination
A Technical Strategy to Deploy the Architecture Gateways provide interim solutions as TENA interfaces
A Definition of Compliancy Levels of compliancy to enhance communication among
systems engineers and investment decision makers
An Architecture for Ranges, Facilities, and Simulations to Interoperate, to be Reused, to be Composed into greater capabilities
An Architecture for Ranges, Facilities, and Simulations to Interoperate, to be Reused, to be Composed into greater capabilities