Client Workstation

User's desktop workstation, which can be any desktop that supports Sun Microsystems' Java Virtual Machine (JVM) 1.4.1.

Backend Server

Hosts most of the SWSI server applications; manages user login sessions, database storage, and the communications with NCCDS and DAS.

Open Server

Proxy server to allow Open IONet and Internet-based users to connect to SWSI and to access TUT.  User requests are directed to Backend Server through the NISN Secure Gateway using a single predefined set of rules.  This allows the addition of new customers and users without the need for adding new Secure Gateway rules.

Client

Executes on Client Workstation, provides Graphical User Interface (GUI) for performing SWSI client operations.

Application Server

Server process that the Client connects to in order to access SWSI services; keeps track of user requests and provides responses back to the Client.  The Application Server runs on both the Open Server and the Backend Server.

Isolator

Server process that provides an interface for the Client with the SWSI Database; processes user requests and generates responses; communicates with the Client through the Application Server.  A separate Isolator is required for each Application Server.

SWSI-NCCDS Interface (SNIF)

Server process that communicates with the NCCDS using the messaging protocol defined in the NCCDS/Mission Operations Center (MOC) Interface Control Document (ICD).  A separate SNIF is required to communicate with each NCCDS (operations and test).

SWSI-DAS Interface (SDIF)

Server process that communicates with the Demand Access System (DAS).  Only one SDIF is required since there is no test DAS.

Database

Backend data storage; holds all customer configuration and scheduling data; allows access to customer schedules from any Client Workstation from any IP network for any authorized user.

Open TUT Server

Web server that mirrors the TUT web service provided by NCCDS on the Closed IONet.  The Open TUT Server data is updated hourly.

Network Control Center (NCC) Data System (NCCDS) Operations

The NCC serves as the central control facility of the Spaceflight Tracking and Data Network (STDN), which consists of the Space Network (SN) and Ground Network (GN).  The SN includes the Tracking and Data Relay Satellites (TDRSs) and two ground terminals, the White Sands Ground Terminal (WSGT) and the Second TDRSS Ground Terminal (STGT).  The NCC schedules, controls, and ensures the reliability of the SN.  NCC is located within the Data Services Management Center (DSMC) at STGT.  The SWSI communicates with the operations NCCDS on behalf of SWSI customers through implementation of the NCCDS/MOC Interface Control Document (ICD) protocol.  All communications use Transmission Control Protocol (TCP) and are limited to those messages designated for full support customers.

Auxiliary Network Control Center (ANCC)

The ANCC serves primarily as a test facility for testing new NCCDS software releases and for performing Engineering Interface (EIF) tests with customer MOCs. ANCC is located at WSGT. SWSI interfaces with the ANCC to allow SWSI customers to perform interface testing and user training.

Service Planning Segment (SPS)

The SPS is the primary NCCDS subsystem used for performing SN service planning. SPS receives and validates customer service requests, generates and maintains the schedule, and disseminates the schedule to the appropriate SN elements and customers. The SPS also receives acquisition data from the Flight Dynamics Facility (FDF) and SN customers, stores the data, and disseminates acquisition data to WSGT and STGT.  The SWSI maintains TCP connections with SPS for performing scheduling and vector storage on behalf of each SWSI customer.

Communications and Control Segment (CCS)

The CCS is the primary NCCDS subsystem used for performing SN service control and service assurance.  Customers are able to perform real-time reconfiguration of an ongoing service through the use of Ground Control Message Requests (GCMRs).  CCS is used to monitor the performance of active events and passes this information to customers in the form of User Performance Data (UPD) messages.

NCCDS Protocol Gateway (NPG)

The NPG performs message protocol translation between legacy entities that communicate in 4800 BBs and newer entities that use TCP messages.  Since CCS communicates using 4800 BB protocol and the SWSI communicates using TCP, the SWSI establishes real-time connections with the NPG, using the NPG as a TCP proxy for the CCS.

NCCDS TDRSS Unscheduled Time (TUT) Server

The TUT World Wide Web (WWW) Server provides information about unscheduled TDRS resources.  It consists of start and stop times of unscheduled use of the Single Access (SA), Multiple Access Forward (MAF), and S-band Multiple Access Forward (SMAF) antennas, and Multiple Access Return (MAR) and S-band Multiple Access Return (SMAR) links for each TDRS.  This data is essentially the unused time in the schedule, with a few adjustments due to flexible events with flexible start and stop times and/or flexible resources. The NCCDS TUT Server provides this service only to customers located on the Closed IONET.

Demand Access System (DAS)

The DAS expands the existing TDRSS Multiple Access Return (MAR) capabilities by building upon the Third Generation Multiple Access Beamforming Subsystem (TGBFS).  The existing TDRSs provide pre-scheduled communication service to customers by using ground-based electronics to process signals emanating from customers that are relayed by the TDRS on-board phased array antenna systems. The TGBFS expands the capability of the TDRSs MAR system and allows service to be provided on a demand basis rather than on a pre-scheduled basis.

DAS Controller (DASCON)

DASCON is responsible for scheduling and controlling all DAS-related hardware at the White Sands Complex (WSC). The SWSI communicates with the DASCON on behalf of SWSI customers through implementation of the DAS/SWSI Interface Control Document (ICD) protocol.  All communications use Transmission Control Protocol (TCP).

NISN Secure Gateway

The NISN Secure Gateway is a rule-based firewall used to prevent penetration of hosts on the Closed IONET from less secure networks.  A small number of rules is used to allow connection between the Open Server and the Backend Server components.  All message traffic is channeled through this path.  The rule set is static, meaning that Secure Gateway changes are not required in response to SWSI customers being added or removed.