1. Gene Hudgins TENA Development Lead 4 March 2003 Test and Training Enabling Architecture (TENA) Test and Training Enabling Architecture (TENA) TheFoundationfor DoD Range Interoperability The Foundation for DoD Range Interoperability

2. Slide 2 Foundation Initiative 2010 Mission Enable Interoperability among Range systems, Facilities, Simulations, C4ISR systems in a quick, cost-efficient manner, and 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 Simulation-Based Acquisition Foster Test and Training Integration In the long term: SAVE MONEY! Support the Warfighter (Joint Vision 2010/2020) Enable Simulation-Based Acquisition Foster Test and Training Integration In the long term: SAVE MONEY!

3. Slide 3 Foundation Initiative 2010 Project Objectives Define a common Architecture for the test/training range community – called “TENA” (Test & Training Enabling Architecture) Define a common Object Model to be used across the ranges Define and build a common Software Middleware that will: Use the object model Enhance interoperability and reuse among the ranges Common understanding of range processes – the Logical Range Concept of Operations Define and prototype common Tools to configure and conduct multi-range, synthetic test events or training exercises Create distributed, synthetic battlespaces with real weapon systems Link multiple ranges together to form a larger, cohesive range Enable testing, assessment, experimentation, and training of weapon system interoperability, C4ISR, and system-of-systems

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 Stateful Distributed Objects An SDO is a combination of two powerful concepts: a distributed object paradigm (like the one used in CORBA) a distributed publish and subscribe paradigm. Benefits of this combination: A conventional distributed object-oriented system offers no direct support to the user for disseminating data from a single source to multiple destinations. A conventional publish-subscribe system does not provide the abstraction of objects with a set of methods in their interface. Interface to SDOs is a lot simpler and more usable than the combination of interfaces to their underlying technologies. ANY APPLICATION can act as a server of some SDO objects and a client of other objects AT THE SAME TIME TENA is a PEER-TO-PEER Architecture

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 Remote Method Invocation Proxy Object on Client Proxy for Object 27 Remote Interface Publication State Interface Publication State Cache Local Methods Interface Servant Object on Server Object 27 Remote Interface Publication State Local Methods Interface Client ProcessServer Process TENA Middleware Network User Application Remote Interface Implementation Local Methods Implementation User Application

13. Slide 13 Clients and Proxies, Servers and Servants Publication State Dissemination and Access Proxy Object on Client Proxy for Object 27 Remote Interface Publication State Interface Publication State Cache Local Methods Interface Servant Object on Server Object 27 Remote Interface Publication State Local Methods Interface Client ProcessServer Process TENA Middleware Network User Application Remote Interface Implementation Local Methods Implementation User Application “Set” Methods

14. Slide 14 Clients and Proxies, Servers and Servants Local Methods used on both Client and Server Proxy Object on Client Proxy for Object 27 Remote Interface Publication State Interface Publication State Cache Local Methods Interface Servant Object on Server Object 27 Remote Interface Publication State Local Methods Interface Client ProcessServer Process TENA Middleware Network User Application Remote Interface Implementation Local Methods Implementation User Application

15. Slide 15 TENA Middleware Platform / Language Support Release 4.0 Platform Support Windows 2000 sp4 with MSVC++ 7.0 Windows XP sp1 with MSVC++ 7.0 Linux Red Hat 8.0 (2.4.18 kernel) with gcc 3.2 Linux Red Hat 9.0 (2.4.20 kernel) with gcc 3.2.2 Sun Solaris 8 (SPARC) with gcc 3.2.3 Release 4.0 Language Support C++ support provided with current release OCX (COM) wrapper developed by one of the TENA Users (RTTC) Java wrapper methodology provided by one of the TENA Users (Eglin) Soon Support for Windows MSVC++ 7.1 on XP and 2000 Support for SGI with both gcc and MIPSPro compilers Support for VxWorks

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

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

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

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

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

21. Slide 21 JCIDEX03 – a JNTC Event Geography, Facilities, and Network JCIDEX03 – a JNTC Event Geography, Facilities, and Network Eglin AFB 3039N 8632W De Soto MOA South Ext. South Corridor 190 miles 150 miles 11 Mar 03 RGS Network Backbone Ground Basing / Ops Fixed-Wing Ops Ft Rucker Virtual/Constructive Simulation New Orleans Shelby Fixed-Wing Basing / Ops Gulfport CRTC

22. Slide 22 JCIDEX 03 / TENA Activity 767 ARDS GPS Pods JTIDS Terminal ARDS GND STN 767 JTIDS TENA IF Gateway ARDS TENA IF JECG Display -Rangeview – ( Analysis (AMO, TSPI, JTIDS, Instrumentation ) Casualty Assessment Workstation (A/G, G/G, A/A geo-pairing) Router SA/AAR DisplayJECG Display Rangeview JECG Display Camp Shelby MS Ft. Rucker (opt) Gulfport CRTC Live Infrastructure Gulfport/Shelby/Camden MOA Router TENA Display Rangeview Eglin AFB CRTC TACTS GND STN TACTS TENA IF Gateway SA/AAR Display - PCDS - (TSPI ) Router JCIET ADNET TACTS Pods SA/AAR Display - PCDS - SA/AAR Display CRTC LAN

23. Slide 23 JNTC Horizontal Thrust Event – Jan 04 Range Integration & Instrumentation Solution DIS TENA 29 Palms WRC Event Network IGRS TENA Proxy PCDS Display TENA Twentynine Palms ARDS ARDS TENA Gateway TENA Nellis TENA JTASC WRC Event Network TENA/HLA Gateway (GOTH) PCDS Display TENA HLA JTASC TENA Server TENA Existing Air Warrior T-1 TENA Nellis WRC Event Network PCDS Display (CAOC) Air Warrior TENA Gateway Rangeview Display (CAOC) Rangeview Display (GW Control) TENA Rangeview Display TENA Rangeview Display TENA NTC-IS TENA Gateway PCDS Display NTC DBST Hub ITM NTC-IS (CIS) AW CSS Rangeview Display T-1 from Tierfort Mtn. to 930 thru 988 TENA File/Chat Server WRC Horizontal Event DISA DATMS Network Unclassified TENA Gateway & Server NTSC Video NTSC Video

24. Slide 24 Architecture Management Team (TENA AMT)  System Engineers & Technical Leads for the current major stakeholders of TENA  AAC, Eglin AFB FL  NUWC, Newport RI  RTTC, Huntsville AL  PMRF Synthetic Range  EPG, Fort Huachuca AZ  WSMR, White Sands NM  NAWC-AD, Pax River MD  Virtual Proving Ground (VPG)  Joint National Training Center (JNTC)  NAWC-WD, China Lake & Point Mugu CA  Common Training Instrumentation Architecture (CTIA)  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-8 weeks Raytheon, Boeing, SAIC, APL, MIT LL, JITC, DMSO, NRL, & ATC also attend & participate

25. Slide 25 Key Elements of TENA Revisited TENA lowers the cost to integrate systems together Some systems made TENA-compliant <$20K for MC-02 TENA decreases the time to integrate systems together Auto-code generator generated 50K+ SLOC in a few hours from a 4 pg interface definition document Legacy display system made TENA-compliant in 4.5 days for MC-02 Hydrophone instrumentation system made TENA-complaint in 2 days HLA-compliant display system gateway made TENA-complaint in 1 day TENA lowers the cost to reuse systems in future events Examples include VAST/IMPASS reusing pre-existing TENA capability Will be better realized in future JNTC events TENA improves flexibility of integrating systems together Range applications can be optimally configured for the particular test event

26. Slide 26 Key Elements of TENA Revisited (cont.) TENA improves reliability of integrating systems together Auto-code generator ensures that every system has same baseline of source code Standard, validated algorithms (such as coordinate translations or unit conversions) can be embedded in TENA rather than burden software applications of managing and performing translations TENA Middleware performs data marshalling/demarshalling rather than burden software applications TENA eases Deployment at the DoD Ranges TENA can be deployed gradually (system by system) rather than requiring all systems be redesigned Providing on-site training at a number of ranges TENA has a process to follow for sustainment/improvement Leveraged CTTRA workshops and the Architecture Management Team (AMT) Established on-line User Help Desk system to capture feedback from TENA users Pursuing RCC standards, and investigating OMG standards Working with T&E CTTRAP to determine TENA policy among Services

27. Slide 27 Summary of What We Have Working Implementations 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

28. Slide 28 Important Contact Information FI Program Web site, links to Middleware, help desk: http://www.fi2010.org Get the TENA 2002 Document: http://www.fi2010.org/documents/tena2002.pdf FI 2010 Program Topics: fipmo@jcs.mil Questions, comments, feedback about the TENA architecture or the TENA Middleware: TENA-feedback@fi2010.org TENA user community: TENA-users@fi2010.org TENA Object Model technical team: TENA-om-team@fi2010.org