1. 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

2. 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

3. 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!

4. 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)

5. 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.

6. 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

7. Slide 7 TENA Architecture Overview

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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++ 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)

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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 22-24 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

20. 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

21. 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