Test Enabled and Training Architecture (TENA)

Don McGregor

Research Associate

MOVES Institute

mcgredo@nps.edu

TENA

• TENA is used in range environments, often in the L portion of LVC

• Slightly different emphasis; small devices, real-time-ish, sometimes embedded, high performance in the sense of low overhead required, multiple unusual platforms

• Government-owned source built for multiple platforms

Live, Virtual, constructive

TENA

• Large-ish user support network• https://www.tena-sda.org• Available to international militaries with

permission (used in Sweden)• “Schedule A” software

Remote Objects

• There’s a popular concept in computer science called “remote procedure calls” or “distributed objects.” You’ve got a piece of code on one host, and you want to call it from another

• You can create and send a message from the client to the server to make this call happen, but it’s popular to make it appear as if the object is “really” on the client. This is done via a proxy object

Proxy Objects

-doSomething(int i)-doSomethingElse(float f);

-doSomething(int i)-doSomethingElse(float f);

Proxy Real Object

The proxy is a “stand-in” for the real object on another host. Methods are called bya user on the proxy, which does no computation itself. Instead, it passes the request(along with any parameters) to the real object on a server. The server does thecomputation and passes back the return value

Proxy and Servant

• The object on the client side is called the proxy, while the “real” object on the server side is called the servant

• This means the proxy and servant need to agree on how messages are passed back and forth, ports for passing messages over sockets, etc. The good news is that this can be automated by appropriate code, so the user doesn’t have to write any of it

• Typically you write a interface file in a special language, then the proxy code and servant interface is generated for you

• The infrastructure can use a variety of technologies for message passing: multicast, tcp, udp, etc.

8

TENA Objects

TENA Description Language

The TDL/CORBA IDL below is run through a compiler to generate the proxy objects and to create the server-side connectors. (TDL and IDL are very similar)

10

TDL

• TDL is a way to write something like a Java interface—it’s like a class, and it defines methods. It also defines instance variables

• It’s written in a language that is very much like C++ or Java, but isn’t. Same concepts of classes and inheritance. No code logic, just interfaces and variables

• Note that this is different from HLA—HLA had only classes with data values, no methods

• Once written you compile the TDL to Java or C++ language implementations

11

TDL

• Distributed programming has more things that can go wrong than normal programming, and more issues to deal with– Sometimes you might not want to wait for a

return value from a method. You can define “oneway” methods that are “fire and forget”, and may or may not work.

– You may not care if objects in the method arguments are modified on the server side are passed back—you can specify that they don’t have to be. These can be specified with in/

12

TENA Description Language

• You can also generate TENA TDL from a UML diagram via MagicDraw

Dangers

• While this is nice, always remember that the proxy object is not the same thing as the real object. Calls are being made across the network, so they’ll be much slower and less reliable than using a “real” object

for(int idx = 0; idx < 1000; idx++{ proxy.doSomething(idx);}

TENA Remote Objects

• Remote objects are the approach that TENA takes

• Clients have proxies that connect to the servant objects running on other hosts, so we may have a radar object instance running on a device on the range being called from a host in the lab, and the radar object being shown in a DIS application via a gateway

Stateful Distributed Objects

• TENA adds “stateful distributed objects” to regular distributed objects

• With distributed objects you need to call a method to discover state

• With SDOs the state is pushed to subscribed listeners periodically (often at state change points)

• So for example a Radar object instance might tell listening objects that it has turned on rather than waiting for other objects to ask its state, or having other objects poll its state

TENA

• So a TENA application can consist of– Objects that that application publishes (for

example, a radar or tank)– Objects that that application is listening to (for

example, helicopters published by other applications)

– Your own application logic

• TENA has gateways to allow operation with other standards, for example DIS or HLA

TENA

• TENA uses something called CORBA in the background, specifically the TAO realtime CORBA ORB

• But all this is hidden from the user, and as a result is never seen directly

• Multiple language bindings: C++ is primary, C# also, Java

CORBA

• CORBA provides the infrastructure for many things:– Publishing objects– Handling parameter serialization, object

serialization, response serialization– Object lookup– The interface description language (IDL)– Generating proxy and servant interfaces

• You provide the servant logic, CORBA does most of the rest

Object Serialization

• What if you pass an object as a parameter to a method on a servant? Eg, Position with attributes of floats (x,y,z). Or what if you want an object returned as a method result?

• The attributes of the object need to be placed in a format that can be passed in a message to the servant; this is all done automatically, but it needs to be done

• How to you find published objects?

TENA

TENA App

Cooperating TENA Apps

23

Vs DIS

VBS2

Vendor A DIS

Combat XXI

Vendor B DIS

Standardized Wire Format, Different APIs for DIS

24

Vs HLA

VBS2

Vendor A HLA

Combat XXI

Vendor B HLA

Standardized API, Different Wire Formats for Each Vendor

25

Vs TENA

VBS2

TENA Middleware

Combat XXI

TENA Middleware

One vendor for TENA middleware. The wire format iswhatever that single vendor specifies. TENA APIs and wire formats are not officially standardized;they are defacto standards

JMETC

• Joint Mission Environment Test Capability • Classic government behavior: every time we

run a live exercise, set up a network, then tear it down afterwards

• Takes months to approve the security paperwork

• Better government behavior: set up a network on the ranges once, then have all subsequent exercises use that network. This is the JMETC idea

JMETC

JMETC

• Always-on, monitored 24/7• Security dweebs do their thing for you

Overall

• TENA uses a hidden implementation of CORBA

• Adds “stateful distributed objects”, which pushes state information to subscribed listeners

• High performance, hides most network details

• Gov’t-provided middleware for most architectures (Linux/Windows/IOS/32/64)