NeTTS
Network-centric Test and Training System
NeTTS is a family of stimulation and instrumentation systems designed to support the D/OT&E of emerging
C4I systems via the creation of realistic virtual environments. NeTTS grew out of the ROCS test tool,
originally developed for the Marine Corp Operational Test Activity (MCOTEA) and used
in numerous DT and OT events. The development of ROCS and its successor systems led to the formation
of NeTTS in 2005. NeTTS includes: 
- ROCS: Stimulates IP-based data messaging systems. Includes support for Outlook email, VMF messages via the Command and Control PC (C2PC), file transfers via HTTP and FTP protocols, and track reports via C2PC and/or Track Database Manager (TDBM).
- VETT: Stimulates voice/video systems. VETT interfaces include push-to-talk (PTT) radio and intercom interfaces such as Single-Channel Ground-Air Radio System (SINGARS) and the General Dynamic (GD) MESHnet system, Tri-Services Tactical (Tri-Tac) / Mobile Subscriber Equipment (MSE) voice systems, Voice over Internet Protocol (VoIP) systems, Plain Old Telephone (POTS) systems, Ethernet-based or Integrated Services Digital Network (ISDN)-based video teleconferencing (VTC) systems and others.
- CADETT: A stand-alone tool built under contract to the Navy, CADETT adds an air track simulation component to NeTTS and was designed to evaluate the Area Air Defense Commander (AADC) system and other air defense systems in the context of imperfect, realistic air pictures. Track messages may be injected into the AADC directly or into Global Command and Control System-Maritime (GCCS-M) and Link-16 terminals using existing standard interfaces.
- ITAS: A stand-alone tool that emulates intelligence feeds into the Integrated Broadcast Service (IBS). The ITAS-generated message traffic consists of pre-recorded intelligence messages that are formatted into message sets designed to test a specific capability of the IBS. Message formats supported include TDIMF Rev E, Oilstock Bt and Bx, TAB 37, USMTF Tacelint, Tacrep, and Sensorep; TDDS TXT, USSID 369 and CMF.
The concepts behind the NeTTS design are based on GTRI's approach to C4I systems testing and the implementation concepts
are driven by years of field experience conducting tests in operational environments. NeTTS is decomposed into two top-level concepts: a backbone framework and plug-ins. The framework manages the definition, distribution, and processing of individual
events that constitute actions to be performed on C2 system under test (SUT) interfaces. The NeTTS schema abstracts these
top-level functions from the specifics of a particular SUT interface (protocols, message formats, physical layer, etc.).
The detailed content definition and mechanics for defining and interacting with a particular SUT interface are all wrapped
into a single conceptual package called a plug-in. A plug-in defines the specifics needed to stimulate and monitor the
interface and to reduce and manage data injected or recorded at the interface. Plug-ins for ROCS and VETT capabilities have been
generated, allowing for a fully coordinated test of IP-based data and voice/video systems.
GTRI's methodology for C4I system T&E focuses on generating operationally meaningful data with which to analyze that
system's performance. The two primary goals of this approach are to:
a) Decouple the definition of an operational scenario from the specific details of individual test networks and environments, and
b) Provide a quick and operationally meaningful representation of a wide variety of C4I system and network performance metrics.
To create the most realistic test environment, stimulation of actual operator interfaces (applications that tie into the
C4I network, radio/telephone interfaces, etc.) is the desired method of generating load on the system, as opposed to attempting
to model and merely simulate the type of traffic that operationally realistic use of the system would produce. By opting to
manipulate and drive these actual operator interfaces rather than simulate their network loading characteristics, the question
of whether or not the test event traffic generated on the C4I system-under-test (SUT) is operationally representative or not
is eliminated altogether.
The steps involved in a NeTTS analysis include:
- Build/Edit Test Scenario
During this step, a Scenario Editor is used to define the information exchange requirements for the test. Most NeTTS tools offer a world map through which one can graphically define/display paths taken by the scenario players.
- Define Test Network Configuration and Build Message Scripts
During this step, the specific hardware and software applications to be utilized during the test are defined. These assets include both NeTTS assets and SUT assets. This definition of test network is decoupled from the scenario definition of the prior step. A mapping process then merges the scenario with the test network by allowing the user to associate scenario players/messages with the test resources. Individual scripts are then generated for each machine/application participating in the test. - Run Message Scripts and Monitor Network Operation
A Test Manager/Run-Time Control component is then used to initiate, control, and monitor system operation during the actual test. It communicates with SUT Agents, commanding them to start and stop as desired. The SUT Agents are custom software components designed to stimulate other software applications, generating the message traffic specified in the script, and recroding receipt of message traffic. Communications between the Run Time Control and the SUT Agents are performed over a dedicated T&E network so as to be nonintrusive on the network-under-test. - Collect and Collate Logged Network Data
Once the test is complete, logged data is retrieved from the distributed systems and collated into a "run" database back on the Test Manager. - Analyze and Display Data
At the completion of the test, an Observables component is used to display and analyze test data. The systems plot a variety of measures (latency, message density over time, thread completion, etc.) that translate network performance into operationally meaningful results.
More detailed information on each NeTTS tool is available here. For additional assistance, or information on NeTTS in general, please contact Fred Wright.
Last Updated December 3, 2007