Test and Training Enabling Architecture TENA The Foundation
Test and Training Enabling Architecture (TENA) The Foundation for Do. D Range Interoperability Gene Hudgins TENA Development Lead 4 March 2003
Foundation Initiative 2010 Mission Currently, range systems tend to be noninteroperable, “stove-pipe” systems. The purpose of TENA is to provide the architecture and the software implementation necessary to: n n Enable Interoperability among Range systems, Facilities, Simulations, C 4 ISR systems in a quick, cost-efficient manner, and Foster Reuse for Range asset utilization and for future developments. l l Support the Warfighter (Joint Vision 2010/2020) Enable Simulation-Based Acquisition Foster Test and Training Integration In the long term: SAVE MONEY! Lay the Foundation for Future Test and Training Range Instrumentation Slide 2
Foundation Initiative 2010 Project Objectives n Define a common Architecture for the test/training range community – called “TENA” (Test & Training Enabling Architecture) n n Define a common Object Model to be used across the ranges Define and build a common Software Middleware that will: n Use the object model n 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 n n n 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, C 4 ISR, and system-of-systems Slide 3
Overall Development Strategy Test & Training Enabling Architecture (TENA) n n Prototypes Prototypes User Feedback Lessons Learned 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 Slide 4
Driving Technical Requirements 1. Interoperability n 2. Reusability n 3. 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. The characteristic of a given component, application, or system that implies that it can be used in arrangements, configurations, or in system-ofsystems beyond those for which it was originally designed. Composability n n 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 5
Achieving Interoperability, Reuse, and Composability n Interoperability requires: n n A common architecture An ability to meaningfully communicate n A common language n A common communication mechanism n A physical connection between the two systems A common context n A common understanding of the environment n A common understanding of time n A common technical process TENA Object Model (OM) TENA Middleware Network, shared memory TENA Object Model (Environment) TENA OM, TENA Middleware TENA Technical Process Reuse and Composability require the above, plus n Well defined interfaces and functionality for the application to be reused Reusable Tools, Repository Slide 6
TENA Architecture Overview Slide 7
Ways TENA Middleware Can Exchange Data n TENA presents to the range user a unification of several powerful inter-application communication paradigms n Publish/Subscribe n n n Remote Method Invocation n Similar to CORBA or Java RMI Each object that is published may have methods that can be remotely invoked by other applications Messages n n 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 Individual messages that can be sent from one application to one or more other applications Data Streams n Native support for audio, video, and telemetry Slide 8
Stateful Distributed Objects n An SDO is a combination of two powerful concepts: n n n Benefits of this combination: n n a distributed object paradigm (like the one used in CORBA) a distributed publish and subscribe paradigm. 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 n TENA is a PEER-TO-PEER Architecture Slide 9
Logical Range Simple Example TENA specifies an architecture for range resources participating in logical ranges Test Control Station Radar Simulation Communication Mechanism (Network, Shared Memory, etc. ) Slide 10
Logical Range Simple Example n TENA specifies a peer-to-peer architecture for logical ranges n n 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 TENA Application A User Test Application Control Code Station TENA Application B TENA Application C User Application Simulation Code Application Code Proxy Servant Proxy User Radar Servant Proxy Servant Proxy TENA Middleware Communication Mechanism (Network, Shared Memory, etc. ) Slide 11
Clients and Proxies, Servers and Servants n Remote Method Invocation Client Process Proxy Object on Client User Application Proxy for Object 27 Remote Interface Publication State Cache Local Methods Interface Local Methods Implementation TENA Middleware Network Server Process Servant Object on Server Object 27 User Application Remote Interface Implementation Publication State Local Methods Interface Local Methods Implementation TENA Middleware Slide 12
Clients and Proxies, Servers and Servants n Publication State Dissemination and Access Client Process Proxy Object on Client User Application Proxy for Object 27 Remote Interface Publication State Cache Local Methods Interface Local Methods Implementation TENA Middleware Network Server Process Servant Object on Server User Application Object 27 Remote Interface Implementation Publication State “Set” Methods Local Methods Interface Local Methods Implementation TENA Middleware Slide 13
Clients and Proxies, Servers and Servants n Local Methods used on both Client and Server Client Process Proxy Object on Client User Application Proxy for Object 27 Remote Interface Publication State Cache Local Methods Interface Local Methods Implementation TENA Middleware Network Server Process Servant Object on Server Object 27 User Application Remote Interface Implementation Publication State Local Methods Interface Local Methods Implementation TENA Middleware Slide 14
TENA Middleware Platform / Language Support n Release 4. 0 Platform Support n n n Release 4. 0 Language Support n n Windows 2000 sp 4 with MSVC++ 7. 0 Windows XP sp 1 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 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 n Support for Windows MSVC++ 7. 1 on XP and 2000 Support for SGI with both gcc and MIPSPro compilers Support for Vx. Works Slide 15
TENA Compliancy Levels TENA Level 3 TENA Level 2 n TENA Level 1 n n Uses the TENA Middleware Defined as TENA Objects n n n Standard use and definition of Time Only uses the TENA Middleware Uses the TENA Middleware Defined as TENA Objects n Data Archiving n Uses RCC Objects n Standard Control n n (whenever possible) Standard use and definition of Time Only uses the TENA Middleware Uses the TENA Middleware Defined as TENA Objects Slide 16
Gradual Deployment of TENA Existing Range Application Now Range Protocols Existing Range Application A Few Years Range Protocols Existing Range Application Range Protocols TENARange Gateway Re-architected TENA-compliant Application Existing Range Application Other sites New TENA Application TENARange Gateway Re-architected TENA-compliant Application Existing Range Application Eventually Existing Range Application New TENA Application Other sites Re-architected TENA-compliant Application New TENA Application TENARange Gateway Other sites New TENA Application Re-architected TENA-compliant Application New TENA Application Slide 17
Range Integration in Millennium Challenge 2002 (MC 02) Blue Forces Nellis AFB Joint Training, Analysis, and Simulation Center TENA Gateway Land Range/China Lake TENA Gateway • Ships • Ground forces • Aircraft Opposing Forces National Training Center/Ft. Irwin Joint Network Integrating Software TENA Gateway Global Command & Control System Electronic Combat Range/China Lake TENA Gateway Model & Simulation Feed Sea Range/Point Mugu • Aircraft & air targets • Ships • Ground forces TENA Gateway US Marines/So. California Logistics Airfield Command, Control, Communications, Computers, Intelligence Feed Slide 18
Gulf Range VAST/IMPASS Repeater Shipboard Processing Map Rendering Virtual Target FFE 3, 4, 5 Acoustic Processing GPS Communication Link Shot 1 Shot 2 Slide 19
VAST/IMPASS Network Connectivity Eglin Central Control Facility TENA on Fiber TENA on NIPRNET CDSA Dam Neck, VA TENA on Microwave Eglin Range Site A-15 CSS Panama City, FL EGLIN AFB 200 40 Miles 0 M ile s Slide 20
JCIDEX 03 – a JNTC Event Geography, Facilities, and Network Shelby RGS De Soto MOA 190 miles h Sout RGS Gulfport CRTC Ground Basing / Ops Fixed-Wing Ops Ft Rucker Virtual/Constructive Simulation RGS Ext. Eglin AFB 3039 N 8632 W South Corridor New Orleans Fixed-Wing Basing / Ops 11 Mar 03 150 miles Network Backbone Slide 21
JCIDEX 03 / TENA Activity 767 Live Infrastructure Gulfport/Shelby/Camden MOA SA/AAR Display Router ARDS GPS Pods Camp Shelby MS TACTS Pods JTIDS Terminal - PCDS - JECG Display CRTC Rangeview TACTS GND STN CRTC LAN JTIDS TENA IF Gateway ARDS Ft. Rucker (opt) GND STN JCIET TACTS ARDS TENA IF Router SA/AAR Display JECG Display ADNET Gateway Router Gulfport CRTC JECG Display -Rangeview – ( Analysis Eglin AFB TENA Display SA/AAR Display Casualty Assessment Workstation - PCDS - (A/G, G/G, A/A geo-pairing) (TSPI) Router Rangeview (AMO, TSPI, JTIDS, Instrumentation) SA/AAR Display Slide 22
JNTC Horizontal Thrust Event – Jan 04 Range Integration & Instrumentation Solution DIS DIS ITM NTC-IS (CIS) TENA Rangeview Display NTC DBST Hub TENA NTC-IS TENA Gateway NTSC Video ARDS Ground Station AW CSS Metrics Capture PCDS Display TENA File/Chat Server NTSC Video VBrick NTC Ft. Irwin T-1 from Tierfort Mtn. to 930 thru 988 Existing Air Warrior T-1 Rangeview Display (GW Control) Rangeview Display NTC WRC Event Network TENA Rangeview Display (CAOC) TENA PCDS Display (CAOC) WRC Horizontal Event DISA DATMS Network TENA HLA TENA/HLA Gateway (GOTH) TENA PCDS Display TENA Server JTASC WRC Event Network JTASC TENA Nellis WRC Event Network Air Warrior TENA Gateway Nellis TENA IGRS Unclassified TENA Gateway & Server TENA IGRS TENA Proxy Rangeview Display PCDS Display TENA 29 Palms WRC Event Network ARDS TENA Gateway ARDS Ground Stations NTSC Video VBrick Twentynine Palms Slide 23
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) Meetings every 4 -8 weeks ing, e o B eon, h t LL, y T a I R M PL, A , C I RL, & N SA , O DMS tend & , C T I J so at l a C AT ate p i c i t r pa Design Decisions / Trade-offs / Status TENA Use Cases / Prototype Test Strategies Technical Exchanges of Lessons Learned Issues & Concerns Identification, Investigation, & Resolution Slide 24
Key Elements of TENA Revisited n TENA lowers the cost to integrate systems together n n TENA decreases the time to integrate systems together n n n Auto-code generator generated 50 K+ 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 n n n Some systems made TENA-compliant <$20 K for MC-02 Examples include VAST/IMPASS reusing pre-existing TENA capability Will be better realized in future JNTC events TENA improves flexibility of integrating systems together n Range applications can be optimally configured for the particular test event Slide 25
Key Elements of TENA Revisited (cont. ) n TENA improves reliability of integrating systems together n n TENA eases Deployment at the Do. D Ranges n n n 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 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 n n 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 Slide 26
Summary of What We Have An Architecture for Ranges, Facilities, and Simulations to Interoperate, to be Reused, to be Composed into greater capabilities n Working Implementations of the Architecture n n A Process to Develop and Expand the Architecture n n CTTRA Workshops, AMT Meetings, and RCC Coordination A Technical Strategy to Deploy the Architecture n n TENA Middleware currently works on Windows, Linux, and Sun Gateways provide interim solutions as TENA interfaces A Definition of Compliancy n Levels of compliancy to enhance communication among systems engineers and investment decision makers Slide 27
Important Contact Information n n n FI Program Web site, links to Middleware, help desk: http: //www. fi 2010. org Get the TENA 2002 Document: http: //www. fi 2010. org/documents/tena 2002. pdf FI 2010 Program Topics: fipmo@jcs. mil Questions, comments, feedback about the TENA architecture or the TENA Middleware: TENA-feedback@fi 2010. org TENA user community: TENA-users@fi 2010. org TENA Object Model technical team: TENA-om-team@fi 2010. org Slide 28
- Slides: 28