Keith Poch Foundation Initiative 2010 Cadre 22 July 2003 Test & Training Enabling Architecture (TENA) NET3 Conference Orlando, Fl Interoperability at DoD.

Slides:



Advertisements
Similar presentations
--- IT Acumens. COMIT Acumens. COM SNMP Project. AIM The aim of our project is to monitor and manage the performance of a network. The aim of our project.
Advertisements

Database Architectures and the Web
ProtoCore Capability What need is the ProtoCore addressing? Legacy middleware architectures, used in many simulation environments, do not make use of modern.
Distribution A: Approved for public release; distribution is unlimited Get the right M&S technology to the right place, at the right time, for the Decision.
Connecting People With Information DoD Net-Centric Services Strategy Frank Petroski October 31, 2006.
Distributed components
CIM2564 Introduction to Development Frameworks 1 Overview of a Development Framework Topic 1.
Network Management Overview IACT 918 July 2004 Gene Awyzio SITACS University of Wollongong.
Chapter 17: Client/Server Computing Business Data Communications, 4e.
1 Quality Objects: Advanced Middleware for Wide Area Distributed Applications Rick Schantz Quality Objects: Advanced Middleware for Large Scale Wide Area.
1 ITC242 – Introduction to Data Communications Week 12 Topic 18 Chapter 19 Network Management.
Chapter 7: Client/Server Computing Business Data Communications, 5e.
Software Engineering Module 1 -Components Teaching unit 3 – Advanced development Ernesto Damiani Free University of Bozen - Bolzano Lesson 2 – Components.
Course Instructor: Aisha Azeem
Distributed Systems: Client/Server Computing
September 2011 At A Glance The API provides a common interface to the GMSEC software information bus. Benefits Isolates both complexity of applications.
Microsoft ® Application Virtualization 4.5 Infrastructure Planning and Design Series.
Enterprise Architecture
Microsoft ® Application Virtualization 4.6 Infrastructure Planning and Design Published: September 2008 Updated: February 2010.
Annual SERC Research Review - Student Presentation, October 5-6, Extending Model Based System Engineering to Utilize 3D Virtual Environments Peter.
Software Engineering Muhammad Fahad Khan
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
THE NEXT STEP IN WEB SERVICES By Francisco Curbera,… Memtimin MAHMUT 2012.
Microsoft ® Application Virtualization 4.6 Infrastructure Planning and Design Published: September 2008 Updated: November 2011.
PROJECT NAME: DHS Watch List Integration (WLI) Information Sharing Environment (ISE) MANAGER: Michael Borden PHONE: (703) extension 105.
Jaeki Song ISQS6337 JAVA Lecture 16 Other Issues in Java.
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 1 Component-based development l Building software from reusable components l Objectives.
1 06/00 Questions 10/6/2015 QoS in DOS ECOOP 2000John Zinky BBN Technologies ECOOP 2000 Workshop on Quality of Service in Distributed Object Systems
Enterprise Java Beans Java for the Enterprise Server-based platform for Enterprise Applications Designed for “medium-to-large scale business, enterprise-wide.
CS 390- Unix Programming Environment CS 390 Unix Programming Environment Topics to be covered: Distributed Computing Fundamentals.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 09. Review Introduction to architectural styles Distributed architectures – Client Server Architecture – Multi-tier.
High Level Architecture Overview and Rules Thanks to: Dr. Judith Dahmann, and others from: Defense Modeling and Simulation Office phone: (703)
Army Net-Centric Data Strategy Center Of Excellence (ANCDS) Army Data Harmonization and Integration Working Group (ADHIWG) Sever Ciorlian ANCDS Team Lead.
Role-Based Guide to the RUP Architect. 2 Mission of an Architect A software architect leads and coordinates technical activities and artifacts throughout.
BLU-ICE and the Distributed Control System Constraints for Software Development Strategies Timothy M. McPhillips Stanford Synchrotron Radiation Laboratory.
Headquarters U. S. Air Force I n t e g r i t y - S e r v i c e - E x c e l l e n c e © 2008 The MITRE Corporation. All rights reserved From Throw Away.
OOI CI LCA REVIEW August 2010 Ocean Observatories Initiative OOI Cyberinfrastructure Architecture Overview Michael Meisinger Life Cycle Architecture Review.
Instrumentation of the SAM-Grid Gabriele Garzoglio CSC 426 Research Proposal.
A Web-based Distributed Simulation System Christopher Taewan Ryu Computer Science Department California State University, Fullerton.
© 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering.
Middleware for FIs Apeego House 4B, Tardeo Rd. Mumbai Tel: Fax:
The High Level Architecture Introduction. Outline High Level Architecture (HLA): Background Rules Interface Specification –Overview –Class Based Subscription.
© 2004 Mercury Computer Systems, Inc. FPGAs & Software Components Graham Bardouleau & Jim Kulp Mercury Computer Systems, Inc. High Performance Embedded.
By: PHANIDEEP NARRA. OVERVIEW Definition Motivation.NET and J2EE Architectures Interoperability Problems Interoperability Technologies Conclusion and.
9 Systems Analysis and Design in a Changing World, Fourth Edition.
NA-MIC National Alliance for Medical Image Computing UCSD: Engineering Core 2 Portal and Grid Infrastructure.
9 Systems Analysis and Design in a Changing World, Fourth Edition.
Distribution and components. 2 What is the problem? Enterprise computing is Large scale & complex: It supports large scale and complex organisations Spanning.
Hwajung Lee.  Interprocess Communication (IPC) is at the heart of distributed computing.  Processes and Threads  Process is the execution of a program.
March 2004 At A Glance NASA’s GSFC GMSEC architecture provides a scalable, extensible ground and flight system approach for future missions. Benefits Simplifies.
GRID Overview Internet2 Member Meeting Spring 2003 Sandra Redman Information Technology and Systems Center and Information Technology Research Center National.
111/27/2015 User Education & Training End-to-End Cycle for NOAA's Satellite Program Anthony Mostek NOAA - NWS – OCWWS - Training Division Anthony Mostek.
Gene Hudgins TENA Development Lead 4 March 2003 Test and Training Enabling Architecture (TENA) Test and Training Enabling Architecture (TENA) TheFoundationfor.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Software Engineering Chapter: Computer Aided Software Engineering 1 Chapter : Computer Aided Software Engineering.
Extensible Modeling and Simulation Framework Extensible 3D Graphics (X3D) Don Brutzman MOVES Institute, Naval Postgraduate School Andreas Tolk VMASC, Old.
Distribution A: Approved for public release; distribution is unlimited Get the right M&S technology to the right place, at the right time, for the Decision.
25 April Unified Cryptologic Architecture: A Framework for a Service Based Architecture Unified Cryptologic Architecture: A Framework for a Service.
JNTC Joint Management Office
GRID ANATOMY Advanced Computing Concepts – Dr. Emmanuel Pilli.
Enterprise Computing Distribution and components.
March 2004 At A Glance The AutoFDS provides a web- based interface to acquire, generate, and distribute products, using the GMSEC Reference Architecture.
Why is Design so Difficult? Analysis: Focuses on the application domain Design: Focuses on the solution domain –The solution domain is changing very rapidly.
1 The XMSF Profile Overlay to the FEDEP Dr. Katherine L. Morse, SAIC Mr. Robert Lutz, JHU APL
Common Object Request Broker Architecture (CORBA)
Distribution and components
Testing in the Context of the Operational Mission Mike Toole Army Future Combat Systems System Of Systems Test 4 March 2003.
Chapter 17: Client/Server Computing
Quality Assurance for Component-Based Software Development
Demo for Partners and Customers
Presentation transcript:

Keith Poch Foundation Initiative 2010 Cadre 22 July 2003 Test & Training Enabling Architecture (TENA) NET3 Conference Orlando, Fl Interoperability at DoD Ranges Interoperability at DoD Ranges

Slide 2 Foundation Initiative 2010 Overall 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 integrated multi-range events

Slide 3 Foundation Initiative 2010 Mission 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 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 Lessons Learned User Feedback Lessons Learned User Feedback Lessons Learned Prototypes Test & Training Enabling Architecture (TENA)

Slide 5 Driving 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 a system-of-systems.

Slide 6 Achieving Interoperability, Reuse, 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 functionality for 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 Overview

Slide 8 Ways TENA Middleware Can Exchange 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 of TENA Beyond HLA Standard Object Model TENA 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 Reliability TENA 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 Streams TENA 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 Models TENA 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 HLA TENA Middleware marshals/demarshals data, rather than relying on individual applications to do so Significance: 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 software TENA supports remotely invoking “methods” (control commands, operations, processes) of another application Significance: Software interfaces can be designed more naturally and effectively for distributed test events

Slide 10 Test Control Station Simulation Logical Range Simple Example TENA specifies an architecture for range resources participating in logical ranges Communication Mechanism (Network, Shared Memory, etc.) Radar

Slide 11 Logical Range Simple 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 Test Control Station Communication Mechanism (Network, Shared Memory, etc.) Radar Simulation TENA Middleware TENA Application C User Application Code Servant Proxy Servant TENA Middleware TENA Application B User Application Code Proxy TENA Middleware TENA Application A User Application Code Servant

Slide 12 Clients and Proxies; Servers 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 Client Proxy for Object 27 Remote Interface Cache of Publication State Servant Object on Server Object 27 Remote Interface Publication State Client ProcessServer Process TENA Middleware Network Client Object Remote Interface Implementation

Slide 13 TENA Middleware Platform/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 Linux Red Hat 7.2 with gcc Sun Solaris 8 (SunOS 5.8) with gcc Additional Platforms To Be Supported Sun Solaris 8 with SunPro 5.4 compiler SGI IRIX with gcc on SGI hardware VxWorks 5.5, Motorola MPC7XXX PowerPC, Tornado 2.2 with gcc 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 Challenge 2002 (MC02) Joint Training, Analysis, and Simulation Center Global Command & Control System Integrating Software TENA Gateway JointNetwork 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 US Marines/So. California Logistics Airfield Model & Simulation Feed

Slide 15 Gulf Range VAST/IMPASS Acoustic Processing GPS Communication Link Shipboard Processing Map Rendering Virtual Target Repeater Shot 1 Shot 2 FFE 3,4,5

Slide 16 VAST/IMPASS Network Connectivity EGLIN AFB 400 Miles 200 Miles Eglin Central Control Facility CSS Panama City, FL Panama City, FL CDSA Dam Neck, VA Eglin Range Site A-15 TENA on NIPRNET TENA on Microwave TENA on Fiber

Slide 17 TENA 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 Now Range Protocols TENA- Range Gateway Event- ually Existing Range Application Re-architected TENA-compliant Application New TENA Application Range Protocols Other sites TENA- Range Gateway New TENA Application Existing Range Application Re-architected TENA-compliant Application New TENA Application Re-architected TENA-compliant Application A Few Years Range Protocols Other sites TENA- Range Gateway Gradual Deployment of TENA

Slide 19 Common Test & Training Range Architecture (CTTRA) CTTRA 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 Test Ranges WSMR EPG PMRF AFFTC MC AVTB AFWTF YPG RTTC NAWCAD NAWCWD AAC AEDC ATC NUWC AUTEC Training Representatives Training Representatives STRICOM AF XOM PMA-248 NTTR NAWC-TSD NWAD USATSC UTTR Other DoD DARPA MDA JFCOM DMSO JITC NAVAIR HPCMO JNIC Test Facilities PRIMES ACETEF ATIC GWEF EOTASEL/EOSFEL WAF STAF Test Agencies OPTEVFOR AFOTEC ATEC Army DTC Army OTC MCOTEA

Slide 20 Architecture Management 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

Slide 21 Summary 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