Innovated communications solutions for your world

GET AHEAD

Virtual NTDS

VNTDS.png

Product Overview

Background

Naval Tactical Data Systems (NTDS) began with large, main-frame type computers supporting multiple NTDS channels. These channels were used by NTDS system applications to communicate with peripheral devices in order to gather sensor information or to provide data. The channels were point‑to‑point: one peripheral device per channel. These were specialized computers made specifically for the application at hand.

As technology advanced, COTS (Commercial Off The Shelf) computer systems began to be part of the NTDS environment. This brought the requirement for COTS NTDS systems to communicate with existing NTDS peripheral devices. As more COTS computer systems were integrated into NTDS systems, other communication protocols began to be utilized. As these communication protocols became faster and more reliable, they became the preferred standard, especially the Ethernet protocol. However, the NTDS peripherals did not advance in the same manner and still required NTDS interface communication channels. Thus, the advent of the NTDS over Ethernet converter systems. This allowed the growing Ethernet infrastructure to be utilized while still maintaining communication with legacy NTDS peripherals by placing the NTDS over Ethernet converter close to the peripheral device and communicating with the converter through the Ethernet system.

Now, legacy NTDS peripherals are being simulated or upgraded to include Ethernet interfaces. However, the programming methodology and application interface (API) for NTDS based communication differs from Ethernet communication. Countless hours would be required to rewrite the NTDS system applications to utilize these protocols.

GET Engineering has developed the V‑NTDS component to provide a seamless integration path to NTDS adapter elimination. The V‑NTDS component replaces the NTDS adapter and provides the NTDS adapter API used in the system application. There is no need to modify existing certified NTDS applications. It then transports the data through the Ethernet interface to the receiving device. For an application utilizing the GET Engineering Common User Interface (CUI), no modifications to the existing API calls are required. Other NTDS adapter APIs may be supported as well. The elimination of NTDS hardware and cabling removes the maintenance/repair and life cycle support issues normally associated with NTDS hardware. Mean time between failures (MTBF) of the system typically increases as the hardware components are reduced.

Design Basics

The V‑NTDS component provides an API translator layer which receives the NTDS API calls. This layer is designed to allow translation of third party APIs as well as GET’s CUI calls. The API layer passes the information to the function translator which takes NTDS specific functions and translates it into an application specific interface the component uses for communication negotiations. From there, the information traverses through the data layer which prepares it to be transported through the physical layer. The physical layer at this point is defined as the Ethernet interface but could be defined through alternative physical interfaces as the demand presents itself. Data coming back through the physical interface transitions through the data layer, back through the function layer which translates the data back the NTDS type information, and back through the API layer to be presented to the system application.

NTDS hardware emulation is rigorously defined in the V‑NTDS architecture. Separate channels for Data and External Interrupts are provided. Aborting conditions, timeouts, and other termination events are well supported.

An entirely new functionality provided by V‑NTDS is the ability to perform data transactions between different NTDS Types. With V‑NTDS, an NTDS Type A device can now communicate with other parallel types (Type B/C/H) or even with NTDS Serial data types (Type D/E). This technology has not been previously available and opens new realms for NTDS application development.

Key Features

  • No Dedicated NTDS Adapters

  • No NTDS Cables

  • No Specialized NTDS Converters

  • No need to modify existing certified NTDS applications

  • Seamless transition to Network Communication

  • MIL‑STD‑1397C Type A/B/C/H Serial Type D/E

  • Reduced maintenance, repair, and life cycle support

  • Higher MTBF