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
Proxy
-doSomething(int i)
-doSomethingElse(float f);
Real Object
-doSomething(int i)
-doSomethingElse(float f);
The proxy is a “stand-in” for the real object on another host. Methods are called by
a 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 the
computation 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.
TENA Objects
8
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)
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
10
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
11
have to be. These can be specified with in/
TENA Description Language
• You can also generate TENA TDL from a
UML diagram via MagicDraw
12
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
Vs DIS
VBS2
Combat XXI
Vendor A DIS
Vendor B DIS
Standardized Wire Format, Different APIs for DIS
23
Vs HLA
VBS2
Combat XXI
Vendor A HLA
Vendor B HLA
Standardized API, Different Wire Formats for Each Vendor
24
Vs TENA
VBS2
TENA
Middleware
Combat XXI
TENA
Middleware
One vendor for TENA middleware. The wire format is
whatever that single vendor specifies.
TENA APIs and wire formats are not officially standardized;
they are defacto standards
25
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)